Het stoppen van het mislukte multiregelingensysteem (mrs) levert de Sociale Verzekeringsbank (SVB) een strop op van 43,7 miljoen euro. Afgelopen mei lagen de kosten nog op 32,3 miljoen, maar door de beëindiging groeit de kostenpost door afschrijvingen op de balans tot 43,7 miljoen. Hergebruik van delen zou de schadepost nog kunnen beperken. De Sociale Verzekeringsbank (SVB) zegt naar aanleiding van het debacle het contract met bouwer Capgemini op. In de komende maanden volgt de financiële afwikkeling ervan. Of dit betekent dat er ook een schadeclaim bij de automatiseerder wordt ingediend, kan een woordvoerster van de uitvoeringsinstantie nog niet zeggen.
De SVB schrijft middels een brief aan de Tweede Kamer dat het met de ontwikkeling van het Multiregelingensysteem (mrs) is gestopt, naar aanleiding van een tussenrapportage van twee externe deskundigen. Dat zijn Johan Hakkenberg, deskundige op het gebied van ict-implementaties bij de overheid, en Lieneke Sneller, hoogleraar toegevoegde waarde it bij Nyenrode Business University. Hieruit blijkt dat zij het ongewijzigd doorgaan van het mrs als ‘zeer problematisch’ inschatten. Deze twee deskundigen hebben op verzoek van Jette Kleinsma, de staatssecretaris van Sociale Zaken en Werkgelegenheid de status van het mrs in kaart gebracht.
Het Multi-regelingen-systeem (mrs) maakt deel uit van het SVB Tien-veranderprogramma. De totale kosten bedragen 121,8 miljoen euro. Dit bestaat uit het nu gestaakte herontwerp MRS/BR2 Kindregelingen (43,7 miljoen euro), een deel organisatorische kosten en het wel in productie genomen Multi-regelingen-systeem rond vrijwillig verzekerden (44,9 miljoen euro) én een algemeen deel ict-kosten voor de versterking van de ict-infrastructuur en Oracle-softwarelicenties (33,2 miljoen euro). De woordvoerster van de SVB kon nog niet aangeven of en hoeveel er van deze laatste post ook nog in de boeken moet worden afgeschreven. Het programma heeft tot op heden wel 158 miljoen euro aan besparingen opgeleverd en zal jaarlijks structureel dertig miljoen euro opleveren, beweert de Sociale Verzekeringsbank.
Hergebruik
Als vervolg op het stopzetten van het mrs zegt de SVB de huidige ict-infrastructuur verder te willen versterken. Daarmee moet de dienstverlening voor tenminste vijf jaar worden gewaarborgd. De huidige systemen, waarmee de SVB de betalingen uitvoert, zoals aow en kinderbijslag, stammen uit de jaren tachtig. Hoe deze kunnen worden versterkt zodat ze een langere levensduur krijgen, weet de woordvoerster nog niet. Wel stelt ze dat de verzekeringsbank zal bekijken welke onderdelen van het Multiregelingensysteem nog voor hergebruik in aanmerking kunnen komen.
Het mrs vormde het sluitstuk van het veranderprogramma SVB Tien. Kern daarvan is dat de SVB-medewerker de clïenten integraal (over meerdere regelingen) van dienst kan zijn. De ontwikkeling van het mrs stuitte echter op problemen. Ook is de omgeving van de SVB sinds de start van SVB Tien in 2006 sterk veranderd door bezuinigingen, wetswijzigingen en mondiger geworden burgers die om een betere dienstverlening vragen, waardoor de ict-vraag complexer werd.
Veranderprogramma SVB Tien
Het veranderprogramma SVB Tien is gestart in 2005. Toen de geplande invoering van het systeem in november 2013 niet door kon gaan is aan KPMG de opdracht gegeven een analyse naar de kwaliteit van het systeem te maken. Mede naar aanleiding van deze analyse heeft staatssecretaris Klijnsma de Auditdienst Rijk in maart 2014 gevraagd advies uit te brengen over het verloop en de implementatie van het multiregelingensysteem.
Op basis van dit advies hebben de bewindsvrouw en de raad van bestuur van de SVB in juni twee externe deskundigen gevraagd om een extra onderzoek te doen. Uit een nu opgeleverde tussenrapportage van de twee externe deskundigen blijkt dat het beoogde mrs zo complex en omvangrijk is, dat ze afraden hier ongewijzigd mee door te gaan. Verder adviseren zij de contractuele relatie met de implementatiepartner Capgemini te beëindigen en geven zij de SVB het advies om zich te heroriënteren op de dienstverlening. Een van de eerste maatregelen is het aanstellen van een chief information officer (cio).
1- te grote ambitie,
2- lange doorlooptijden (8 jaar!),
3- omgeving die flink door de wetgeving aan het veranderen is,
4- rare begroting (32 mil???)
5- geen cio,
5- geen gatereview?? Waarom zijn eigenlijk deze externe deskundigen niet ingeschakeld om het programma (b.v. 1x per jaar) te reviewen?
……en nog meer
Als ik deze opsomming aan mijn collega junior helpdesk voorleg dan weet hij al dat dit een grote mislukking gaat worden!
Wat had je als SVB nodig om van tevoren in te zien dat dit project gaat vastlopen?
Reza, je lijstje klopt. Bij punt 1 gaat het al volledig mis. De bla-bla programmamanager en zijn volgelingen hebben na punt 1 de andere risico’s niet meer willen zien. Zo’n quasi stoere can-do houding komt wel meer voor, vooral in (semi)overheidsland. Alles kon en prioriteren op basis van MoSCoW o.i.d. was niet nodig, en dus werd Prince 2, PINO.
Maar de buitenwacht heeft ook zitten te slapen. Het is het ministerie aan te rekenen dat er jaarlijks miljoenen zijn uitgeven zonder dat er concrete vorderingen waren. In 2010 is na vijf jaar het toezicht eindelijk geïntensiveerd door de Inspectie SZW. Er kwam een extern rapport met vernietigende conclusies. Slechts een deel hiervan is meteen door de SZW overgenomen. In 2012 was de Inspectie nog zeer optimistisch, en vooral vaag. Men verdoezelde dat de eerste zeven jaar te weinig vorderingen zijn gemaakt en te veel was beloofd. De Inspectie gaf wel aan dat de SVB niet slechts moest sturen op de einddatum van het programma, maar ook op de kwaliteit van de tussentijdse producten. In 2013 geeft de SVB aan nog dat de planning van SVB Tien op schema ligt en de implementatie nog in 2013 zou beginnen (drie jaar na de oorspronkelijke datum). En op 25 juni 2014 stond het project op het rijksdashboard op groen ondanks de zoveelste vertraging (fail Rijks CIO).
Maar nu blijkt dat na vier jaar verscherpt extern toezicht het nog steeds niet duidelijk is of het programma het benodigde kan opleveren. De functionaliteit, de onderhoudbaarheid en de algehele kwaliteit van de software blijkt te laag voor implementatie. Dit lijkt veel op de klassieke valkuil waar men volgens opgeleukte rapportages de geplande vorderingen maakt, totdat men moet toegeven dat op de opleverdatum wellicht nog niet eens de helft is opgeleverd.
N.b. de ontwikkeling en het testen van de software door Capgemini vond plaats in India, omdat de goedkopere software ontwikkelaars daar de maximale CMM score van 5 zouden halen i.t.t. de duurdere ontwikkelaars in Europa die gemiddeld maar op CMM 3 zouden zitten. Pas in 2013, het jaar van de geplande implementatie, is de software ook hier getest en toen bleek wat de CMM certificaten werkelijk waard waren.
Gezien het voorafgaande zou een groot deel van de kosten op Capgemini verhaald kunnen en moeten worden.
Ik vermoed dat er niet genoeg managers en ruim te weinig PION- (kent U die term nog?) geschoolden bij betrokken zijn (geweest).
Johan,
Wat een mooi overzicht en samenvatting. Dank!
Dus:
– het programma is niet juist ingeschat (de inhoud, budget, fases en producten etc),
– De regie was er niet of niet correct,
– Review en controle waren er niet of wat er was, was niet betrouwbaar,
– Partners en hun kwaliteiten waren niet betrouwbaar,
en nog meer……
Leuk dat we een rijksdashboard hebben. Iets wat we vanaf het begin ook op deze site aangegeven hebben dat het nergens op slaat!
Maar goed, ik ben benieuwd hoe dit verder afloopt, wie gaat bloeden, wat gaan we doen met de huidige legacy en de investering die gedaan is bij SVB en nog verdere zaken richting afsluiting.
@John van Voren “omdat de goedkopere software ontwikkelaars daar de maximale CMM score van 5 zouden halen”, ja, en daar gaat het ook mis. Dit betekent gewoon dat de opdrachtgevende organisatie ook CMM niveau 5 moet halen, ik vraag mij af of ze niveau 2 wel zouden halen. Ook is het de vraag of CMM niveau 5 überhaupt wel wenselijk is in dit geval.
Men vergeet wel eens dat de opdrachtgevende organisatie ook deel uit maakt van het ontwikkelproces. Hier moeten tenslotte de specificaties vandaan komen, die cruciaal onderdeel van dit proces zijn. Ik heb dat wel eens eerder gezien en opgemerkt. Als je niet op een gelijkwaardig niveau kan communiceren gaat het gewoon mis.
Ik heb geen kennis van dit project, dus of dit hier heeft gespeeld, dat weet ik niet. Het lijkt mij in ieder geval wel een issue.
John van Voren, mooie reactie!
@John, als het een troost kan zijn, dergelijke scenario,s zijn geen exclusiviteit van overheidsbedrijven. Bij overheid is de belastingbetaler de dupe, bij private sector komt dit bij de loonkost, dus verzwakte competitie, uiteindelijk ook belastingbetaler als een bedrijf het niet overleeft.
Beste IT-er. Wat steeds maar weer overal over het hoofd wordt gezien is dat de leverancier ook als taak heeft om de opdrachtgever te ondersteunen in het smart formuleren van de requirements. Een Capgemini is een consultancy bedrijf en dan mag je een andere houding verwachten dan enkel op te leveren conform is beschreven door een minder ‘volwassen’ opdrachtgever. Is wel lekker je zakken vullen zo en profiteren van het meerwerk omdat gedurende het verloop de requirements veranderen. Maar leidt bijna altijd tot een ontevreden opdrachtgever en veel negatieve publiciteit (fijn voor je imago).
En een project dat langer dan een jaar duurt leidt zelden tot een tevreden resultaat. Knip projecten op in kleinere brokken of werk agile. Dan heb je veel eerder resultaat en de mogelijkheid om sneller bij te sturen of eerder de stekker eruit te halen. Scheelt zo een hoop verloren miljoenen.
@EddieICT ik zie een lager level niet als waardeoordeel. Je kan in level 1 zitten en altijd prima software opleveren of in level 5 zitten en bagger leveren, zoals blijkbaar in dit geval. Het is slechts een constatering waar rekening mee moet worden gehouden. Zeker als dat level zo verschillend is, dan heb je namelijk grote kans op bagger.
Het is inderdaad aan de ICT dienstverlener om de juiste match te maken. Als deze met level 5 aan de slag wil, omdat dit goedkoper is, en/of er meer winst op kan worden gemaakt, dan moet deze er ook voor zorgen dat specificaties op dit niveau aangeleverd kan worden. Ik trek de keuze voor level 5 zelfs in twijfel. Wel is het zo dat de opdrachtgever met deze propositie akkoord is gegaan, dat had men wellicht niet moeten doen. Toch denk ik dat er veel van de verantwoordelijkheid bij de leverancier zal liggen.
Lange duur van projecten is een groot risico. Het project opknippen in kleinere brokken, lijkt mij inderdaad belangrijk. Daarbij moet elk blok wel een concreet resultaat opleveren.
Niet gelijk alle regelingen in één systeem, maar telkens een regeling er aan toevoegen. Niet de gehele regeling dynamisch maken, maar misschien slechts gedeeltelijk dynamisch op basis van de wijzigingen die gepland staan. Later verdere dynamiek toevoegen indien nodig, of kiezen voor vaste reken/regel modules welke voor een tijdsvak gelden en die op basis van dit tijdsvak geladen kunnen worden.
Er zijn volgens mij genoeg mensen die de belangrijkste problemen met MRS hadden kunnen voorkomen, maar de de lijn- en HR-managers kiezen steeds weer voor de verkeerde programma- en projectmanagers en die starten de verkeerde projecten op met partners met de verkeerde mentaliteit. Het wordt tijd dat instellingen zoals de SVB en bedrijven zoals Cap de verkeerde HR-managers gaan aanpakken. Dan kan de bemanning van beide zijden ook structureel verbeterd worden.
@MartijnH, dat lijkt me ook wel interessant. Het is ook een mooie afstudeeropdracht. Maar het kost wel veel tijd want je moet niet alleen de politiek-ambtelijke documenten die reeds op het internet staan maar vooral ook al die PINO-documenten doornemen.
@Bas de Natris, de oorspronkelijke duur van het project was 4 jaar, dus niet eens zo heel lang. Na een paar jaar kwam er drie jaar bij (toen was het eigenlijk al misgegaan) en vlak voor de implementatie nog een jaar. Nu houdt men rekening met een periode van nog eens vijf jaar na de herstart van het programma.
@Christian, aanbesteden hoeft op zich geen probleem te zijn, maar aanbesteden is ook een vak en heel veel aanbesteders kunnen het niet (en ze verdommen het om dat goed uit te besteden). Na de aanbesteding heb je te maken met relatiemanagement. Dat sommige leveranciers daar moeite mee hebben, laat Cap zien.
@Henri, je hebt gelijk, “als de klant niet precies weet wat ie wil, dan moet je dat achterhalen. Eerder ga je niet bouwen.”
@AlbertRomeo, het blijkt dat bazen van grote bedrijven en instellingen liever voor grote projecten kiezen en daarom voor grote opdrachtnemers, met het grote risico op grote mislukkingen.
@Ad Gerrits, Pascal, volgens mij heeft men gekozen om de zaak nu bekend te maken en niet onder de pet te houden vanwege de Tijdelijke kamercommissie ICT. Nu valt het minder op tussen de andere grote missers.
@Pascal, politici hebben vaak moeite met grote projecten, maar hun persoonlijke assistenten en ambtenaren kiezen ervoor omdat er grote problemen opgelost moeten worden. Politici durven niet nee te zeggen, omdat ze niet weten wat het alternatief zou moeten zijn. Helaas wordt door mismanagement de oplossing vaak weer een nieuw groot probleem.