In het persbericht dat de SVB op 2 september 2014 uitgaf wordt niet gerept over tekortschieten van de implementatiepartner, zoals Capgemini in de brief van de minister systematisch wordt aangeduid. Maar de brief die de minister op 2 september aan de Tweede Kamer zond toont wel degelijk dat Capgemini een totale wanprestatie heeft neergezet.
Dit blijkt zowel uit de brief zelf, als uit het deskundigenrapport dat als bijlage twee was bijgevoegd als ook uit het KPMG-rapport. Die documenten vormen in beginsel een goede basis voor kansrijke schadeclaims. Voor het indienen van een claim door de overheid moet natuurlijk wel enige politieke wil aanwezig zijn en daar lijkt het in het onderhavige geval aan te ontbreken. Daarvoor presenteer ik hierna wellicht een verrassende verklaring.
Allereerst het verslag van de beide deskundigen op 29 augustus 2014. Dat meldt op bladzijde twee: ‘Op bepaalde punten is nog nader onderzoek nodig (onder andere SIG- onderzoek naar de kwaliteit van de opgeleverde programmatuur).’
Maar zelfs zonder dit onderzoek af te wachten constateren de deskundigen dat het zinloos is om met het project door te gaan. Op bladzijde vier van hun rapport vermelden de deskundigen dat het opgeleverde systeem vanuit de optiek van de SVB veel overeenkomsten heeft met een ‘black box’: ‘Men kende de kwaliteit niet, men wist niet of het systeem volledig was[!] en het heeft lang geduurd voordat men in staat was om het testen van de opgeleverde programmatuur op te starten.’ Deskundigen vervolgen logischerwijs: ‘Er bestaat een groot verschil van inzicht over de kwaliteit van de opgeleverde software tussen de SVB en Capgemini.’
Nu de brief zelf die de minister op 2 september 2014 aan de Tweede Kamer schreef. Daaruit blijkt het volgende: De vraag van de SP-fractie, wat de oorzaak was van de kennelijk slechte kwaliteit van opgeleverde software en op welke punten deze tekort schoot wordt als volgt beantwoord. ‘Bij nadere beschouwing bleek de software onvolkomenheden te bevatten en op sommige onderdelen complex en moeilijk onderhoudbaar te zijn. Dit werd bevestigd in de risico gerichte analyse van het kwaliteitsonderzoek door KPMG, de SVB en de implementatiepartner.’
Capgemini gaf deze essentiële tekortkoming toe. De slechte kwaliteit van de software, de nodeloze ingewikkeldheid en het moeilijk onderhoudbaar zijn komen meer klanten van Capgemini bekend voor. Dat is niet alleen het geval bij de SVB maar was ook het geval bij Equihold, waar ikzelf inmiddels als adviseur van de Capclaim betrokken bij ben. Kenneth Berkleef heeft hiervoor mede namens Equihold een rechtszaak aangespannen tegen Capgemini. Bij de SVB was dit bovendien een essentiële tekortkoming omdat de hele operatie rond het MRS-systeem als bedoeling had het systeem makkelijk te kunnen aanpassen aan nieuwe wetgeving.
India
Ook wordt in de brief van de minister vermeld dat in India veel software ontwikkelaars de maximale score 5 voor kwaliteit van hun software behalen terwijl in Europa dergelijke organisaties doorgaans een 3 halen. Dat was helemaal niet gevraagd door de SP-fractie , dus een overbodige reactie. Het lijkt een ongevraagde verdediging van de personeelspolitiek van Capgemini. In ieder geval is deze stelling in strijd met waarnemingen van René Veldwijk over de SVB en van een andere Capgemini-klant, Equihold, over dezelfde jaren (vanaf 2005).
De eerste contracten met Capgemini en de SVB stammen uit 2005 (ongeveer de tijd waarin Capgemini zijn ontwikkelaars in India begon aan te werven). Het eerste falen blijkt voor de buitenwereld in 2008. Nadat men al drie jaar bezig was werd besloten het oude SVB systeem niet te vervangen maar in plaats daarvan een schil te bouwen om de bestaande systemen heen. Over de verwerkingssnelheid en de toekomstige onderhoudbaarheid van het op voorhand al uiterst complexe systeem hoeft men zich bij deze besluitvorming in deze hoogtepunten van ICT architectuur geen illusies te maken.
In maart 2010 meldt de SVB aan de minister dat de SVB en Capgemini van mening zijn dat de huidige aanpak van de vernieuwing meer risico’s met zich meebrengt dan voorzien. De professionele ict-organisatie Capgemini is dus kennelijk niet in staat om binnen vijf jaar factureren en incasseren te ontdekken dat het vernieuwingsplan meer risico’s met zich brengt dan was voorzien. Na deze ‘slow scan’ besluiten Capgemini en SVB af te zien van het bouwen van de schil om de oude bestaande systemen.
Terug bij af
In 2010 is men dus weer terug bij af. De in 2005 tot 2010 betaalde facturen zijn dus voor een totale wanprestatie betaald en zouden in beginsel terug gevorderd moeten worden. In mei 2010 meldt de SVB dat het ‘ambitieniveau’ wordt bijgesteld. De schil wordt niet toegepast en de migratie gaat per regeling plaatsvinden. In augustus 2010 krijgt de minister er kennelijk tabak van want dan vergroot zij het mandaat van haar inspectie. Die kan dan meer zelfstandig onderzoek verrichten.
In februari 2011 deelt de SVB aan de minister mee dat de gehele ict-architectuur wordt heroverwogen. Dat gebeurt dus niet na een voorlopige oriëntatie maar pas na zes jaar factureren en incasseren. Wederom een ultieme wanprestatie. Van een professionele software ontwikkelaar mag verwacht worden dat hij bij de start van een project de ict-architectuur ontwerpt en niet na het neerzetten van zes jaar amateuristische wanprestaties.
Een maand later, in maart 2011, blijkt dat het besluitvormingsproces rondom de ict-vernieuwing zodanige vertraging oplevert dat planningen herhaaldelijk bijgesteld moeten worden en vragen rijzen over vroegtijdige uitputting van het budget.
Nieuwe aanbesteding
In juni 2012 schrijft de SVB aan de minister dat het met Capgemini een nieuw mantelcontract heeft getekend. Onduidelijk is waarom de SVB met Capgemini een nieuw contract heeft getekend. Ook is niet duidelijk waarom er niet opnieuw een Europese aanbesteding heeft plaatsgevonden. Hoewel de schadeclaim op Capgemini wegens zeven jaar wanprestatie staalhard lijkt te zijn, is het niet uitgesloten dat in het nieuwe raamcontract contract is overeengekomen dat geen claims tegen Capgemini worden ingesteld voor de wanprestaties gedurende 2005 tot juni 2012. Wanneer die juridische blunder zou zijn gemaakt, zou over die periode inderdaad geen schadeclaim tegen Capgemini meer ingesteld kunnen worden. Weten doe ik het niet, want ik heb het nieuwe raamcontract niet ingezien. In ieder geval lijkt het erop dat met het nieuwe raamcontract een nieuwe geldstroom voor Capgemini is gecreëerd en wellicht ook een juridische vrijwaring voor de zeven verstreken jaren. Nader onderzoek met betrekking tot de nieuwe raamovereenkomst is zeer aan te bevelen!
Als buitenstaander zou je denken dat in juni 2012 alsnog enige ict-architectuur ontworpen is. In juli 2012 start de bouwfase onder het nieuwe raamcontract. De SVB schrijft aan de minister dat de software in het eerste kwartaal van 2013 zal worden getest, circa negen maanden na het tekenen van de nieuwe raamovereenkomst. In april 2013 meldt de SVB aan de minister dat enkele onderdelen van SVB Tien worden getest.
In juni 2013 constateert de it-afdeling van SVB dat er problemen zitten in de opgeleverde software. Maar omdat Capgemini de software had goedgekeurd wordt besloten een tweede test uit te voeren. Tijdens deze tweede test blijkt het systeem instabiel te zijn, dus storingsgevoelig met hoge uitvalkansen.
In augustus 2013 blijkt dat ook de top van de SVB twijfelt aan de kwaliteit van de door Capgemini opgeleverde software. De tekortkomingen zijn zodanig dat implementatie in het vierde kwartaal 2013 niet haalbaar is. Er wordt wederom een extra testfase ingelast. Ook wordt besloten de kwaliteit van de opgeleverde software te laten onderzoeken.
In november 2013 geeft de SVB aan dat het systeem nog niet gereed is voor de implementatie van MRS. De SVB schrijft aan de minister: ‘De belangrijkste oorzaken hiervoor zijn de latere oplevering door de implementatiepartner [Capgemini], de kwaliteit van de oplevering door de implementatiepartner, de nog beperkte voortgang bij het testen, instabiele ict-omgevingen en de complexiteit van het datamigratietraject.’
Toch maar stoppen
Het heeft echter nog tot zomer 2014 geduurd voordat aan twee externe deskundigen om een totaal advies werd gevraagd, het advies dat op 29 augustus 2014 werd uitgebracht en waarin geadviseerd werd om het gehele project maar te stoppen.
De meest essentiële tekortkomingen van Capgemini bij de SVB moeten ook bij Equihold geconstateerd worden, in dezelfde tijd en met dezelfde gevolgen namelijk geen bruikbare software opleveren maar wel factureren en incasseren. Het zou heel toevallig zijn wanneer de SVB en Equihold de twee enige bedrijven zijn aan wie door Capgemini software is geleverd van bedenkelijke kwaliteit dat mede is veroorzaakt door een zeer gebrekkige basis ICT architectuur. Wanneer de lezer vergelijkbare ervaring heeft en hierover met mij zou willen praten dan is dat natuurlijk mogelijk.
Pieter Lakeman, voorzitter Sobi
Pieter Lakeman, ben verbaast dat je hier een forum hebt gekregen om te pleiten namens je cliënt. Ben daarom benieuwd of Capgemini hetzelfde zal doen.
Je argumenten deel ik grotendeels. Capgemini lijkt me flink in de fout te zijn gegaan en als meest deskundige partij ook vergaand verantwoordelijk te zijn voor de mislukking. Maar je cliënt is ook in gebreke geweest (richting zijn investeerders).
Ik heb als projectleider net zoiets meegemaakt met een groot ICT-bedrijf. Dat had eerder voor ons een paar klussen goed geklaard en mocht mede daarom een nieuwe klus gaan doen. Maar bij die opdracht werden er producten afgeleverd die onvoldoende bruikbaar waren. Wel bleven ze rekeningen sturen. Aan de eigen goedkeuring van hun producten had ik als klant geen boodschap. De accountmanager reageerde niet op mijn klachten. Ik heb vrijwel meteen de betaling stil gelegd en binnen het half jaar heb ik de samenwerking ook formeel opgezegd. Uiteindelijk heeft het bedrijf maar een fractie van het geld gekregen. Ze kregen geen opdrachten meer van ons, laat staan een raamcontract en ze konden ons van de referentielijst schrappen. En dat deed pijn, want wij waren een redelijk grote partij.
Zoiets had je cliënt ook kunnen en moeten doen. Hij had iemand met voldoende ICT-expertise moeten aanwijzen/inhuren die de oplevering in de gaten hield. Mensen met die expertise zijn er volop te vinden. Ook vraag ik me af waarom je cliënt, een jurist nota bene, zich niet beter heeft ingedekt.
In het begin wordt ‘wellicht een verrassende verklaring’ beloofd voor het niet indienen van een claim door de overheid. Ik neem dat bedoeld wordt ‘een wellicht verrassende verklaring’. Hoewel ook dat niet juist is. Er wordt een ‘mogelijke verklaring’ voor de periode 2005 tot juni 2012 gegeven. Ik laat het aan eenieder om te beoordelen of deze ‘wellicht verrassend’ is. Speculatief en van geen betekenis voor de periode vanaf juni 2012.
Wel interessant, dat wel. Niettemin zijn er zeker andere verklaringen te verzinnen, die niet zo logisch kunnen klinken. En wellicht zelfs verrassend zijn.
Soortgelijke problemen in de UK bij de belastingdienst aldaar :
http://www.nao.org.uk/report/managing-replacing-aspire-contract/
Cap Gemini original bid (2007): £4.1 billion
Verwachting totale kosten 2017: £10.4 billion
ondertussen in de backoffice :
http://www.in.capgemini.com/careers/recruitment-events/walk-in-drive-for-certified-oracle-plsql-freshers-on-16th-august
Zo kan het ook :
http://www.theregister.co.uk/2014/09/09/nhs_spin2_rips_out_oracle/
NHS in UK vervangt de Oracle patient database (80 million patient dossiers) door een open source database.
Iedereen die wat langer meedraait in de ICT kent deze verhalen toch wel? Door het zelf te ervaren of via collega’s of vrienden gehoord. Sowieso grote (ICT) projecten heeft altijd een politieke lading. Alle spelers weten precies hoe het speelveld in elkaar steekt en speelt het spel gewoon mee. En de spelbedervers worden met de nek aangekeken.
Het zal pas veranderen als er mensen of bedrijven echt pijn gaan lijden als het fout gaat en verantwoordelijk worden gesteld.
Tsja, na vele jaren ervaring klinkt mij dit als een bekend probleem in de oren. Niet alleen in deze zaak, maar in meerdere aangelegenheden. Het probleem zit er in dat men niet de meest geschikte mensen voor een opdracht zoekt, maar het meest geschikte bedrijf. Zo kan bijvoorbeeld Cap misschien de perfecte projectleider kunnen leveren, maar niet de perfecte functioneel analist. Door grote projecten aan te besteden aan één bedrijf loopt men dus een risico dat men op bepaalde facetten niet de juiste persoon krijgt. Mijns inziens is dit een vorm van gemakzucht die, zeker in dit geval, alleen maar geld kost. Meer aandacht in de voorbereiding en meer inventarisatie van welke mensen men nu werkelijk nodig heeft zou een oplossing voor het probleem kunnen zijn. Nu lopen er veel, met name freelancers, met wel de juiste kennis rond, die niet aan de bak komen vanwege de genoemde gemakzucht om slechts met één bedrijf in zee te willen gaan.
Het is natuurlijk makkelijk om altijd de schuld bij het bedrijf neer te leggen. Laten we wel wezen, zulke contracten die vaak fixed worden gevraagd kunnen helemaal niet fixed worden uitgevoerd. Deze projecten duren vaak te lang en ook de klant heeft gedurende de rit vaak ook nog andere inzichten. Ik wil daarmee zeker niet zeggen dat er geen fouten worden gemaakt door bedrijven, maar de waarheid ligt wel in het midden.
De overheid kan net zo makkelijk fout opdrachtgeverschap worden verweten, en gezien het kennis niveau is dat helemaal niet vreemd.