Stichting Capclaim strijdt onder leiding van Kenneth Berkleef van het failliete Equihold tegen ict-dienstverlener Capgemini. Inzet is het terugvorderen van 43 miljoen euro schade. Capclaim heeft de afgelopen maanden documentatie aan kenners uit de markt beschikbaar gesteld om hen over deze zaak te laten oordelen. Ook Computable-experts kregen inzage en zullen de komende tijd via deze website hun bevindingen delen. Deze tweede bijdrage uit het vijfluik van Kurt de Koning gaat over de kwaliteit van de door Capgemini opgeleverde software.
De kern van de Capclaim welke Kenneth Berkleef heeft uitstaan betreft de kwaliteit van de door Capgemini aan Equihold geleverde software. Kwaliteit kan op verschillende manieren bepaald worden en is vaak moeilijk objectief te maken. Om kwaliteit objectief te kunnen beoordelen moet het meetbaar zijn en onderzoeken naar kwaliteit verifieerbaar: iemand anders moet tot dezelfde conclusie komen als deze het onderzoek op dezelfde wijze uitvoert.
In totaal hebben acht (!) onderzoeken plaatsgevonden naar de kwaliteit van de software. Doordat deze onderzoeken betaald en geïnitieerd zijn door één van de partijen is het zaak om extra goed te kijken hoe de onderzoeken zijn uitgevoerd om zo de objectiviteit van de bevindingen uit het onderzoek juist te kunnen duiden.
Business layer
De eerste twee onderzoeken vonden plaats in januari 2007 en zijn uitgevoerd door medewerkers van Capgemini. De aanleiding hiertoe was door Equihold geuite twijfels en klachten over de kwaliteit van de opgeleverde software en specifiek het ontbreken van de business-layer.
Het ontbreken van de business layer betekent dat het parameter-gestuurd maken van de software om zo verschillende sporten (niet alle sporten hebben elf veldspelers, twee helften en 45 minuten speeltijd) te ondersteunen, onmogelijk werd.
Ook heeft het FXCop compiler-rapport een rol gespeeld. Deze kwam tot meer dan elfduizend waarschuwingen in de opgeleverde software, wat een indicatie is van de kwaliteit van de software.
Aanbevelingen
In de managementsamenvatting van dit rapport wordt de kwaliteit beoordeeld als ‘over het algemeen goed’, hoewel de kwaliteit niet consistent is. Dit betekent dat voor delen van de software een verbeterslag kan worden gemaakt. Hiertoe zijn concrete aanbevelingen genoemd:
• Creëer geen onnodige objects.
• Verwijder files uit de software die niet worden gebruikt.
• Maak meer gebruik van comments.
• Zorg dat alle gebruikers events en error-afhandeling hebben.
Het rapport geeft voorbeelden op basis waarvan de aanbevelingen zijn gegeven. Daarnaast wordt aangegeven dat de splitsing van de verschillende layers goed en conform de technische specificaties is uitgevoerd. In het rapport wordt niet duidelijk of deze laag aanwezig is en functioneert als zodanig of alleen aanwezig is zonder verdere functies. Dat dit een essentieel verschil is, zal uit een vervolgonderzoek nog blijken. Een nadere onderbouwing waarom de software ‘over het algemeen goed’ is, wordt niet gegeven.
In dit zelfde rapport wordt verwezen naar een eerder onderzoek, ook door Capgemini uitgevoerd, waarbij specifiek is gelet of er volgens de richtlijnen is geprogrammeerd. Dit tweede rapport is niet gedeeld, ook niet na aandringen van Equihold.
Een lege business layer
In januari 2008 wordt door een medewerker van Equihold de software opnieuw bekeken, waarbij de business layer wel aanwezig is, doch ‘leeg’ en daarmee zonder functie. Dit is in tegenspraak met het eerste Capgemini-rapport van januari 2007 waarin de aanwezigheid van deze business layer wel wordt gemeld zonder verdere aanvulling of voorbehoud.
In 2010, Equihold heeft begin 2009 zijn activiteiten noodgedwongen moeten staken, wordt de software wederom door dezelfde Equihold-medewerker beoordeeld. Dit rapport is in feite een aanklacht tegen de werkwijze van Capgemini en bekritiseert de opgeleverde software, welke in zijn ogen onbruikbaar is. Meerdere zaken worden als zwaar onvoldoende beoordeeld waarvan voorbeelden worden gegeven. Wederom wordt geconstateerd dat de business layer wel aanwezig is maar in feite geen functie heeft.
Extern onderzoek naar de kwaliteit
In oktober 2010 heeft Equihold gevraagd aan Software Quality Measurement and Improvement (SQMI) om de opgeleverde software te onderwerpen aan een onderzoek. SQMI hanteert een methodische aanpak waarbij het aantal coderegels met een defect worden geteld en gegroepeerd in categorieën. Gemiddeld kwam men op 175 foutieve regels per duizend regels code wat een F-rating opleverde, een drie op een schaal van één tot tien. De één na laagste score in de geschiedenis van SQMI.
Op basis van dit onderzoek is de eindconclusie dat de onderhoudskosten voor dit product onnodig hoog zijn en de software als platform voor verdere ontwikkeling ongeschikt is. Opmerkelijk hierin is dat zaken zijn teruggevonden die in 2007 als aanbeveling zijn aangedragen door Capgemini. Bij mij rijst dan gelijk de vraag wat er met de aanbevelingen is gedaan. Genegeerd, wel uitgevoerd maar niet geborgd of iets anders?
Wederom een intern onderzoek
In februari 2013 heeft Capgemini een zeer uitgebreid intern onderzoek uitgevoerd naar de gang van zaken. Uit de samenvatting wordt ten aanzien van de softwarekwaliteit opgemerkt dat er fouten in zitten doch niet van dien aard dat dit het functioneren van de software in de weg staat. Deze bevinding staat haaks op de ervaring met de software door Equihold en (pilot-)klanten.
Nog een extern onderzoek naar de kwaliteit
In 2014 heeft Capgemini de Software Improvement Group (SIG) gevraagd om de software te onderzoeken op onderhoudbaarheid. Zij hebben hiertoe de methode SIC/TUViT-kwaliteitsmodel voor Trusted Product Maintainability (april 2009) gehanteerd. Ook dit is een methodische aanpak op basis van tellingen en een normenkader.
Afgelopen juni hebben zij dit rapport gepresenteerd met als belangrijkste conclusie dat de onderhoudbaarheid ‘marktgemiddeld’ is, afgezet tegen de benchmark die SIG hanteert. Dit hoeft natuurlijk niet dezelfde benchmark te zijn die SQMI hanteert en waarop het tot een F-rating komt. Let wel dat SIG direct de onderhoudbaarheid van de software heeft onderzocht en SQMI de software in het algemeen en daarbij als afgeleide heeft geconcludeerd dat de onderhoudbaarheid onnodig duur is.
Vragen
SIG/Capgemini hanteert hierbij het principe dat de kwaliteit van software wordt bepaald door de mate van onderhoudbaarheid. Ik vraag me dan gelijk af of dit een correct principe is. Want hoe moeten we deze rapporten interpreteren? De rapporten doen uitspraken die (schijnbaar) in tegenspraak met elkaar zijn. In sommige gevallen mist de onderbouwing en wordt een uitspraak gedaan die niet te kwantificeren is. Tijdens de rechtszaak zullen deze rapporten ook worden besproken. Welk gewicht zou de rechter aan deze rapporten afzonderlijk en in het geheel toekennen?
Ook vraag ik me af of de acht uitgevoerde onderzoeken voldoende zijn om een uitspraak te kunnen doen over de kwaliteit van de software. De onderzoeken zijn vooral gericht op onderhoudbaarheid, programmeertechnische en technische requirements (met focus op de business layer), terwijl stabiliteit en performance een enkele keer worden genoemd. Of de software voldoet aan de opgestelde functionele requirements komt terug in een vervolgartikel waarbij het testen (FAT) nader wordt bekeken.
Om een oordeel te vellen over de kwaliteit van de software zijn de genoemde kwaliteitskenmerken dan volledig? Ter volledigheid, in het verweer noemt Capgemini dat de onderzochte software niet de meest actuele versie is en dat de meest recente software (vrijwel) vrij is van gebreken. In meerdere (Equihold-)onderzoeken is het aantal en ernst van de gebreken dusdanig dat corrigeren op korte termijn niet mogelijk wordt geacht en dat opnieuw bouwen de enige manier is om de software te laten voldoen aan de verwachtingen.
Er blijven dus veel vragen vooralsnog onbeantwoord.
Serie
In deze serie van zes artikelen van Kurt de Koning volgen nog vier delen. Het eerste deel ging over de aanbesteding, hierna volgen nog bijdragen over de inspannings- of resultaatverplichting, de governance en hoe dit heeft kunnen gebeuren. Vervolgens zullen verschillende andere Computable-experts hun mening geven over de beschikbare documentatie.
Ergens heeft het hele verhaal veel weg van de modus operandi van overheid, onderzoek op onderzoek stapelen omdat de verantwoordelijkheid ontlopen wordt, aangaande de geconstateerde manco’s in de business layers krijg ik de indruk dat dit falen geheel verwijtbaar is aan Kenneth Berkleef zelf. Als je niet weet wat je vraagt dan kun je ook niet oordelen over wat je krijgt want even terug naar het voorgaande artikel waarin ingegaan werd op gekozen ontwikkelmethodiek, RUP is bij mijn weten geen bottom-up aanpak. Het is een methodiek welke veel aandacht geeft aan de businesscase en bedoeld is om te voorkomen dat de klant een eindproduct krijgt dat niet aan zijn wensen en eisen voldoet. Mede hierom zijn dan een aantal specifieke rollen binnen de methodiek aan de opdrachtgever toebedeeld, zoals het nemen van de GO/NO GO beslissingen bijvoorbeeld.
Rightsourcing is namelijk exact het tegenovergestelde van outsourcing doordat je strategische en tactische activiteiten binnen de IT niet uitbesteed of zelfs weer terugneemt, lastig natuurlijk als je er de ballen verstand van hebt. Zou het misschien kunnen dat businesslaag niet gevuld was omdat eigenlijk het hele datamodel nog niet bekend was, zou het misschien kunnen dat het hele datamodel nog niet aanwezig was omdat het verhaal steeds meer gelijkenis gaat vertonen met de IT-entrepeneurs uit jaren 80 die vooral goed waren in het schuiven van lege dozen. Hier lijkt huid namelijk niet alleen verkocht te zijn voordat de beer geschoten was maar is niet eens bekend hoe een beer er eigenlijk uit ziet. In reactie op voorgaande artikel gebruikte ik term stroman en dat wordt steeds toepasselijker in verhaal als ik overweeg dat fenomeen gebruikelijk is in betaalde voetbal, het is meer een spel van poppetjes dan een vraagstuk over kwaliteit van de code en de daarbij gebruikte methodieken.
E.e.a. is ook geconcludeerd door Elias c.s. hoewel zijn aanbevelingen dus precies het tegenovergestelde gaan bereiken wat er gewenst is door eveneens stromannetjes aan te stellen in plaats van bestuurlijke veranderingen door te voeren. We hebben het hier over de ‘loketautomatisering’ uit de jaren 80 waarin een bestuurlijke laag onveranderlijk is gebleven en ik wil CapGemini dan zeker niet vrijpleiten van schuld maar als je alle rollen uit handen geeft dan heb je ook geen regie meer. Waar ik dus benieuwd naar ben is de governance zelf, de rest is namelijk alleen maar het gevolg ervan en de spreekwoordelijke koe in de kont kijken. Maar ja, een oud boeren gezegde luidt dat wie geld wil winnen met stront moet beginnen……
Arme rechter dacht ik na het lezen van dit stuk, 8 onderzoeken, verschillende resultaten en daar nog over moeten oordelen ook, wie er nu schuldig is aan wat. En dan moet je ook nog lezen door begrippen als bussiness layer, onnodige objecten en 175 foutieve regels code per 1000 regels (werkt het dan wel?). Dit zegt mij al IT-er al erg weinig moet ik eerlijk zeggen. Wat is een bussiness layer? (pas-toe-leg-uit!)
@Ewout, ik ben het met je eens, het is als eerste aan de opdrachtgever om duidelijk te hebben wat je wil maar dat ligt ook niet altijd voor de hand bij ICT oplossingen en dat is ook iets waar je in samenspraak met de opdrachtnemer uit zou moeten komen. Het is een beetje een overheidsproject in het klein!
Er zijn van 2007 t/m 2009 onderzoeken naar de kwaliteit gedaan. Waarom niet eerder? Het project is in 2005 gestart.
En is er niet meteen naar de hele keten gekeken waarom er niet aan de verwachtingen voldaan is? De meeste problemen zitten meestal niet bij de bouwers, maar in het afstemmingsproces binnen en tussen partijen. Daarom stelt Kurt terecht de vraag wat Capgemini met haar eigen adviezen heeft gedaan.
Na het barsten van de samenwerking in begin 2009 zijn er van 2010 t/m 2014 opnieuw onderzoeken naar de kwaliteit gedaan. Maar hier ging het om de schuldvraag en niet meer om het alsnog leveren van wat de klant nodig had. In haar eigen rapport stelt Capgemini dat de fouten niet van dien aard zijn dat dit het functioneren van de software in de weg staat, terwijl de klanten en gebruikers hier niet mee eens zijn? Was dat de te laat opgeleverde versie en snapt Capgemini wel dat het product uiteindelijk voor de gebruikers bedoeld is?
Als de helft van de gemelde (vermeende) fouten reëel is (vrees dat het er veel meer zijn) en ik naar het projectmanagement kijk (als black box), dan zie ik aan beide kanten te veel “Can Do” houding en veel te weinig kunnen. Ik vraag me af hoeveel interne e-mails van Equihold en Capgemini gedeletet zijn of nog moeten worden i.v.m. het proces?
@Louis, je noemt een belangrijk punt. Er zijn diverse rapporten genoemd. Die gaan over de beoordeling van de producten van Capgemini in verschillende stadia en vanuit verschillende gezichtspunten. De producten zijn verder volgens verschillende maatstaven beoordeeld. Sommige rapportages zijn opgesteld door de strijdende partijen en andere door ingehuurde derden. De gemiddelde rechter kan daar weinig mee, de gemiddelde advocaat dito. Voor hen is het appels met peren vergelijken en de slager die het eigen vlees keurt. Maar ICT-specialisten kunnen de rapporten en andere ingediende stukken in samenspraak met de advocaten analyseren en (schriftelijk) toelichten. De partijen moeten de feiten aandragen en argumenten van de bij de rechter ingediende stukken moeten inhoudelijk kloppen en juridisch zinvol zijn. Wat de rechter niet kan volgen of niet relevant vindt, zal deze terzijde leggen. Wat door de tegenpartij niet voldoende wordt betwist, wordt voor waar gehouden.
Daarom denk ik dat ICT-specialisten in het juridische proces een belangrijke ondersteunende rol zullen gaan spelen. Hier gaat het vooral om de beoordeling van de kwaliteit van de producten (in verband met een oordeel over de beschuldiging van wanprestatie) en van het gevolgde proces (in verband met een oordeel over de verantwoordelijkheid) in relatie tot de gemaakt afspraken. Voor de discussie over de schadeomvang zijn andere specialisten aan zet.
“175 foutieve regels code per 1000 regels” dat is veel, maar alleen ICT-specialisten en testgebruikers kunnen beoordelen of dit veel en regelmatig voor problemen zorgt. Het kan ook om nog ongebruikte regels gaan of om oude regels die nog opgeschoond hadden moeten worden.
@Ewout, volgens mij had de keuze voor rightsourcing moeten betekenen dat Equihold zelf een ervaren overall projectmanager had moeten inhuren.