De Sociale Verzekeringsbank (SVB) heeft definitief de stekker uit het project met Capgemini getrokken voor de bouw van het multi-regelingen-systeem (mrs). Dit systeem – begroot op 32 miljoen euro – zou eind 2013 worden opgeleverd, maar kan niet wegens technische mankementen in productie worden genomen. Capgemini is over dit besluit vandaag in kennisgeving gesteld, bevestigt een woordvoerster van de automatiseerder. Vanmiddag stuurt de SVB een brief hierover naar de Tweede Kamer.
De zegsvrouw van Capgemini verwijst voor een inhoudelijke reactie naar de SVB, maar die was nog niet in staat te reageren op een verzoek om terug te bellen. Naar aanleiding van de problemen bij de ontwikkeling van het multi-regelingen-systeem (mrs) werd een externe commissie onder leiding van Lieneke Sneller, hoogleraar toegevoegde waarde it, ingesteld die moest onderzoeken of het huidige systeem voldoet aan de technische kwaliteitsnormen. Onduidelijk nog is of de resultaten van dit onderzoek de directe aanleiding zijn voor het definitief stopzetten van mrs of dat de SVB zelf dit besluit heeft genomen.
In 2005 ging het project voor de bouw van het mrs van start. Eind 2013 leverde Capgemini, dat in 2009 na een aanbesteding als ontwikkelaar werd geselecteerd, volgens de geplande termijn het systeem op, maar SVB meldde afgelopen mei dat het systeem door onvoldoende kwaliteit niet in productie genomen kon worden.
Opsouperen
Volgens ingewijden zou Capgemini het systeem in drie ‘business releases’ worden opgeleverd. Na business release 1 was van het budget van 32 miljoen reeds 80 procent opgesoupeerd. Van de talloze ‘best practices’ die deze release bevatten, werd er uiteindelijk maar één door de SVB geaccepteerd. Die best practice ging om het invoeren van rekeningnummer.
De SVB meldde in mei dat het voornemens is om de implementatie en het beheer van het systeem in eigen hand te nemen. Dat voornemen lijkt nu op losse schroeven te staan, nu het project is gestopt. De dienst stelde toen ook dat de problemen geen gevolgen hebben voor de lopende systemen: de kinderbijslag en AOW kunnen gewoon worden uitgekeerd doordat het nieuwe systeem buiten de productie-ontwikkeling om wordt ontwikkeld.
.
@Reza : kijken mag toch wel? Iemand houdt dat ding bij, en er zijn mensen die in dashboards geloven. l-J
‘Leugens – Grote Leugens – Statistieken – Excel – Dashboards’ ?
Ik ben vooral getriggerd door het feit dat de verwachting en perceptie van de eindgebruikers significant bleek af te wijken van wat er door consultants (functioneel en technisch) is ontworpen en gebouwd. Hoe kan dit? Geen adequaat testprogramma? Geen Agile aanpak waarbij business (staande organisatie) en bouwteam ( projectorganisatie) volledig samenwerken en geaccepteerde en werkende deelfunctionaliteit opleveren in sprints? Traditionele waterfall aanpak waar de tijd tussen goedgekeurd ontwerp en werkelijke realisatie dermate lang heeft geduurd waardoor de ‘business’ werkelijk geen idee had wat er was afgesproken? Zinvolle vragen om een diepte onderzoek te starten. Andere valkuilen: onvoldoende uitgewerkte visie en stretegie, geen veranderstrategie, teveel focus op techniek. Dit soort aanpakken leiden in 80% tot falen. Lees ook Beenker ‘Lead IT or loose IT’. Kennelijk is deze studie uit 2006 nog niet door elke grote organisatie gelezen (zowel opdrachtgever als systeemintegrator
Ik ben benieuwd of er net als bij het Equihold drama door Cap ook in India is geprogrammeerd voor dit project?
Bij Capgemini werken misschien nagenoeg geen mensen die in staat zijn boter-kaas-en-eieren te bouwen in een programmeertaal waarin hun baas claimt “best in class” of “best of breed” te zijn.
Cap is altijd goed in projectleiding en testen, zeker als de oorzaak van het niet tijdig gereed komen van het produkt aan anderen geweten kan worden….
Eerder onderzoek pleitte de aanbestedende organisatie volgens mij ook niet vrij van schuld:
http://www.inspectieszw.nl/Images/De-Sociale-Verzekeringsbank-Veranderprogramma-SVB-Tien_tcm335-342981.pdf
Krijg ondertussen de indruk dat Computable een ‘naming and shaming’ campagne is begonnen tegen Cap Gemini, als er ook maar iets negatiefs te roepen valt dan is de redactie er als de kippen bij.
SVB meldde…., SVB meldde…., SVB meldde……
Grappige is trouwens idee van multidisciplinaire teams, zoiets als een keeper strafballen laten nemen in plaats ze hem tegen te laten houden om even terug te komen op SAP-er-de-flap. Om nog maar niets te zeggen over het altijd aanwezig idee bij de overheid dat ICT de organisatorische problemen oplost.
Aanbestedingen nodigen uit tot prijsonderdrijven met prijsoverschrijding in het gegunde project als te nemen risico. Hangt van de projectmanager af of de stekker er op tijd uit gaat als de business case nooit meer gehaald kan worden. Ondanks het feit dat de rekening vast ergens bij de belastingbetaler komt te liggen: chapeau om het lef te hebben het project te stoppen om en nog veel groter debacle te voorkomen. (En het kost nu maar 17 euro per Nederlander).
Verbazingwekkend hoe er na zoveel jaren dit uit kan komen. Misschien dat de geaccepteerde de best practice “die ging om het invoeren van rekeningnummer” nog gebruikt kan worden?
@Ewout: ik ben het wel met je eens dat er soms te gemakkelijk wordt geoordeeld, maar het imago van Cap begint langzamerhand wel behoorlijk wat deuken op te lopen (http://www.nrcq.nl/2014/06/05/capgemini-vaakst-betrokken-bij-te-dure-ict-projecten-van-de-overheid)
Ewout,
Mee eens wat betreft Cap en Computable. Lees mijn reactie hierboven om 16:43
Ad,
Dat is waar! We zien inderdaad heel vaak dat de naam van Cap bij mislukte overheidstrajecten voorbij gaat.
Is het niet een soort vriendjes politiek waardoor grote trajecten naar Cap gaan? Worden de aanbesteding niet zo opgezet dat niemand anders met cap kan concurreren? Wat gebeurd er als Cap enige tijd niet aan de overheidsaanbestedingen mag meedoen? Zouden anderen grote bedrijven zoals Atos het beter doen dan Cap?
De kern van het probleem ligt naar mijn mening bij
– te grote omvang van dit soort projecten, dus meer risico`s en minder betrouwbaarheid in een zeer instabiele omgeving waar wetgeving per xx verandert,
– hoe dit soort grote projecten tot stand komen en hoe ze verder ontwikkeld/uitgevoerd/begeleid worden,
– de geschiktheid van de opdrachtgever
en nog meer …
Jammer dat er geen framework komt voor het opstellen, begeleiden en uitvoeren van dit soort grote trajecten. We hebben toch genoeg mislukking gehad bij Belastingdienst, UWV, IND en nog meer andere overheidsinstellingen/organen. Wanneer gaan we daar iets van leren?
De reactie van S.E. Bowen hierboven geeft de kern van het probleem juist weer. Gecombineerd met een aanbesteding (op basis van EMVI) en semi-overheid is het een recept om te mislukken.