Managed hosting door True

Equihold en Capgemini schikken niet

Rechter: Met chocolade heipalen leg je geen goed fundament

Even leek een schikking in zicht. Maar na kortstondig beraad kwamen Equihold en Capgemini er toch niet uit, gisteren in de rechtbank in Amsterdam. De rechter verwacht nu vonnis te vellen op uiterlijk 25 mei aanstaande. Het kan om een tussenvonnis gaan waarbij een externe deskundige wordt benoemd om de kwaliteit van de door Capgemini ontwikkelde software te onderzoeken. Equihold stelt de automatiseerder namelijk aansprakelijk voor het mislukken van het bouwen van een sportinformatiesysteem.

De rechter stuurde aan het eind van de zitting op een schikking aan. Hij wees er op dat er bij beide kampen risico's liggen omtrent het juridisch gelijk krijgen van hun aangevoerde stellingen. Zo vindt Capgemini dat Equihold gedurende het traject en Kenneth Berkleef na afloop te laat zijn met klagen. Maar, zo stelde de rechter, de jurisprudentie rond de klaagplicht en leveranciers is complexer geworden, waardoor het niet meer zo is dat niet tijdig klagen over de prestaties van een leverancier automatisch betekent dat een klacht niet meer geldig is.

Ook gaf de rechter Berkleef mee dat het niet makkelijk is om aan te tonen dat het exoneratiebeding (de vrijwaringsclausule bij schade in het contract), waar Capgemini zich op kan beroepen, niet op gaat omdat dit beging in dit project naar de maatstaven van redelijkheid en billijkheid onaanvaardbaar zou zijn. Pas als dit beding niet op gaat, kan Berkleef schadevergoeding eisen. Bovendien is er bij dit beding een maximale schadevergoeding van 1,25 miljoen euro opgenomen, dat in schril contrast staat met de 43 miljoen die Berkleef aan schade en gederfde inkomsten claimt.

Knopen tellen

De rechter vroeg beide partijen hun knopen te tellen en te overleggen over een minnelijke schikking met als uitgangspunt die 1,25 miljoen 'plus opslag'. Berkleef en Capgemini kwamen er opnieuw niet uit, er zijn al eerdere pogingen geweest, waarbij ook meespeelt dat de belangen van de curator van Equihold (met huisbankier Rabobank als grootste schuldeiser) meespelen.

Nu de schikking niet is gelukt trekt de rechter twaalf weken uit om tot een oordeel te komen in deze zaak. Dat kan ook een tussenoordeel worden; de advocaat van Berkleef vroeg in zijn pleidooi om de inschakeling van een onafhankelijke partij die nogmaals de kwaliteit van de geleverde software gaat onderzoeken. Beide kampen hebben de software door diverse partijen laten onderzoeken. Daar waar Berkleef vindt dat hem belabberde software is geleverd, meent Capgemini dat de softwarecode van marktconforme kwaliteit is.

Echec

De oud-eigenaar van het failliete softwarebedrijf Equihold, Kenneth Berkleef, startte op 28 mei 2014 een procedure tegen Capgemini Nederland waarin hij 43 miljoen van de ict-dienstverlener eist. Capgemini was in het verleden verantwoordelijk voor de oplevering van het softwarepakket 1-2Focus voor Equihold. Met dit systeem zouden sportclubs inzage kunnen krijgen in de prestaties van hun sporters. Er kwam echter geen goed werkend pakket van de grond, waardoor het project spaak liep. Gevolg: potentiële klanten, met name uit de voetbal- en hockeywereld, haakten af. Equihold kwam in geldnood en werd 21 februari 2013 failliet verklaard.

Nadat partijen elkaar al de afgelopen anderhalf jaar schriftelijk van repliek en dupliek hadden gediend was er op 2 maart 2016 dan eindelijk een zittingsdag. Bedoeld als een mogelijkheid om nog eens mondeling pleidooi te voeren. De raadsman van Berkleef benadrukte daarin nogmaals dat de door Capgemini ontwikkelde software van bedroevende kwaliteit was, aan de hand van diverse onderzoeken van deskundigen. Ook wees de advocaat er op dat Capgemini niet heeft ingegrepen op het ontwikkelingstraject, terwijl het bedrijf daarin een vetorecht zou hebben gehad.

Slechte opdrachtgever

Voor Capgemini had de mondelinge toelichting in de rechtszaal niet gehoeven, zo verklaarde een van de advocaten van de it-dienstverlener. Tekenend was dan ook dat er geen directeuren van de Nederlandse organisatie aanwezig waren; de afvaardiging bestaande uit een juridisch adviseur, een aantal medewerkers die bij het project verbonden waren en een paar experts van SIG (Software Improvement Group) die de software hadden onderzocht, volstond kennelijk in de ogen van het automatiseringsconcern.

De verdediging van Capgemini bleek dan ook in hoofdlijnen niet af te wijken van de eerdere aangevoerde argumenten. De it-dienstverlener staat op het standpunt dat Equihold de volledige regierol heeft gespeeld en daarbij slecht opdrachtgeverschap heeft getoond. Daarbij gaat het zowel om het aanleveren van de juiste specificaties, het niet goed testen van geleverde functionaliteit, het te laat goedkeuren van functionaliteit, het stellen van onredelijke deadlines, het steeds stellen van nieuwe eisen en het reeds verkopen van software aan sportclubs terwijl het product nog niet af was. Bovendien kampte Equihold met betalingsachterstanden, zo voerde Capgemini aan.

Volgens een van de advocaten zou Equihold in de veronderstelling zijn dat er een overeenkomst was gesloten voor de ontwikkeling van een kant-en-klaar-softwareproduct met resultaatsverplichting van de kant van Capgemini. Maar het ging juist om een raamovereenkomst waarbij Equihold ict-ontwikkelcapaciteit inhuurde en Capgemini dit in India regelde. Omdat Equihold op een gegeven moment zelf de contacten wilde voeren met India, ontstonden er afstemmingsproblemen.

Heien met chocola

Voor deze zienswijze stak de rechter echter een stokje. Hij wees er op dat de klacht van Berkleef is dat hij software heeft gekregen waarvan de kwaliteit zo bedenkelijk is dat de daaruit voortkomende functionaliteit niet of nauwelijks werkte. Of deze klacht terecht is, is een van de kernpunten van de rechtszaak. Daarnaast speelt ook de vraag mee wie de leiding had over het ontwikkeltraject. Beide partijen wijzen daarbij naar elkaar.

De rechter merkte wel op dat als Capgemini zegt dat het opdrachtgeverschap in zijn geheel bij Equihold berustte er natuurlijk ook sprake moet zijn geweest van goed opdrachtnemerschap. Hij maakte een vergelijking met een aannemer die de opdracht voor het bouwen van een huis aanneemt, terwijl hij weet dat de opdrachtgever heipalen van chocolade heeft laten plaatsen. Dan mag je van een aannemer verwachten de opdrachtgever op de hoogte te stellen dat er bij oplopende temperaturen problemen in het fundament van het bouwwerk gaan ontstaan. Het komt er op neer dat, ook al vindt Capgemini dat alle schuld van Equihold ligt, het bedrijf als deskundige automatiseerder de plicht heeft in een ontwikkeltraject op te treden als de basis niet goed blijkt te zijn.

SIG spreekt zich tegen

Saillant is nog de rol van SIG. Capgemini heeft SIG in de arm genomen om de kwaliteit van de software te meten; volgens een eigen methodiek is de geleverde software marktconform. Daarbij sprak het SIG bevindingen van de door Berkleef gebruikte onderzoekers tegen, waaronder het bureau Software Quality Measurement & Improvement (SQMI). SIG publiceerde echter een studie over software en onderhoud, waarbij het eigenlijk de eigen conclusies in het Cap-traject onderuit haalt. Dit punt werd door de advocaat van Berkleef in de zitting ingebracht als extra argument om de rechter te overtuigen een onafhankelijke deskundige aan te stellen.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5714028). © Jaarbeurs IT Media.
7,4

 

Reacties

Rik, mooi verslag. Hierbij nog een paar opmerkingen.

Over tijdig klagen; de heer Berkleef heeft ter zitting wederom aangevoerd dat Equihold al in het begin van het project heeft geklaagd over de kwaliteit van de software. Alleen is de klacht na het faillissement uitgebreid omdat inmiddels diverse experts naar de zaak hebben gekeken en meer bekend werd over het falen van Capgemini. Die uitbreiding en verzwaring van de klacht probeert Capgemini nog steeds tegen te gaan.

Als bewezen wordt dat Capgemini ondeugdelijke software heeft geleverd en of een onrechtmatige daad heeft gepleegd, dan is een vergoeding mogelijk binnen de grenzen van het exoneratiebeding. De bovengrens van 1,25 miljoen euro in het exoneratiebeding kan komen te vervallen. Dan moet tevens bewezen worden dat Capgemini bijvoorbeeld al veel eerder wist dat de software “chocolade heipalen“ zijn voor het verdere project en dat ze deze kennis hebben achtergehouden.

Opvallend is dat Capgemini zich nu beroept op betalingsachterstanden; die zouden slecht zijn geweest voor de ontwikkeling. Maar de betalingsproblemen zijn pas ontstaan nadat de “chocolade heipalen“ door Capgemini al gebouwd waren en Capgemini de ene na de andere bug fix moest opleveren.

De eerste jaren van het project zei Capgemini dat de heer Berkleef de klachten van zijn eigen mensen moest relativeren, want zij zouden gefrustreerd zijn door de leidende rol van Capgemini. Cynisch genoeg stelt Capgemini nu dat Berkleef meer naar die eigen mensen had moeten luisteren (en dus minder afgaan op het te positieve beeld in de voortgangsrapportages van Capgemini). Berkleef zou daarmee slecht opdrachtgeverschap getoond hebben. Capgemini wijst daarbij naar het rapport van de commissie Elias, over de vele grote mislukte automatiseringsprojecten bij de overheid waar vooral Capgemini bij betrokken was. Een flinke sneer naar de SVB en andere opdrachtgevers van Capgemini!

Gisteren heeft Capgemini voor het eerst erkent dat zij in het begin van het project de projectleiding had. Dit hebben zij daarvoor expliciet ontkent; ze waren slechts leverancier van handjes. Nu zeggen ze echter dat de projectleiding naar Equihold zou zijn gegaan toen de projectmanager van Capgemini plotseling opstapte (zonder iets om over te kunnen dragen!) en er een Capgemini liaison manager uit India naar Equihold kwam. Hierdoor werden de contacten tussen Equihold en de back-office directer. Volgens Capgemini werden de afstemmingsproblemen daardoor juist groter.

Capgemini zei gisteren dat Equihold verantwoordelijk was voor de use cases en daarmee voor eventuele slechte functionaliteit. Met tegenzin heeft Capgemini tegenover de rechter moeten toegeven dat zij de concept use cases moesten opleveren.

Afgrijselijk hoe een bedrijf als Cap het imago van software ontwikkeling schaadt door dit soort verwerpelijke acties. Ze weten donders goed dat wat ze geflikt hebben niet deugd en nu proberen ze zich als een gladde aal zich eruit te wringen. Bah bah!

De kolom 'Gerelateerde artikelen' hier links op de pagina is verre van compleet. Zoeken op 'Capclaim' en '1-2focus' levert een groot aantal andere artikelen op.
Daarin valt vooral het grote aantal inhoudelijke reacties op m.b.t. een breed scala van diverse aspecten en vakgebieden. Reacties die voor het overgrote deel getuigen van een méér dan gemiddelde kennis en ervaring m.b.t. de onderhavige materie.

Het is ernstig te hopen dat de betrokken rechter hiermee bekend is en zich de tijd gunt kennis te nemen van deze artikelen + inhoudelijke reacties.
Dan zal binnen één uur snel duidelijk zijn dat niet kan worden gesproken van een simpel contractdispuut over IT-kwaliteit en dat niet kan worden volstaan met het benoemen van "één externe deskundige".

Maar dat sprake is van een full-blown IT-project, met een separate IT-contractenset, met een onduidelijke onderlinge samenhang, en met een breed scala van aspecten en vakgebieden.
Waarbij van het laatste sprake is van een 'wisselende' kwaliteit van samenhangende invulling in projectdocumenten en business-/IT-contract, om het maar politiek te verwoorden.
Dat de concrete uitvoering vervolgens afweek van projectdocumenten en business-/IT-contract vereist een zelfstandige deskundige waardering.

De Equihold-affaire past overigens probleemloos in de lange rij IT-faalprojecten die de afgelopen vele jaren in de openbaarheid zijn gekomen. En waaraan de o.a. Cie. Elias een boekwerk heeft gewijd. En waarop het BIT een 'Toetskader' heeft opgesteld van 'boerenverstandregels' voor IT-projecten.

Waar ik al eerder op wees is dat de civiele rechter in hoge mate lijdelijk is. Hetgeen inhoudt dat deze zich in beginsel zal beperken tot hetgeen wederzijdse partijen op tafel brengen.
Dat zal in ieder geval Equihold duidelijk zijn.
Een leesmap met Computable-artikelen + reacties, een overview van het Rapport Cie. Elias + aanbevelingen, en het BIT-toetskader, zou voor de rechter op één avond tot helder inzicht kunnen leiden.

Zonder op de stoel van de rechter te gaan zitten....

Klassieker
In alle opzichten is deze zaak niet uniek omdat in tal van dit soort trajecten, niet alleen bij Cap maar ook bij anderen, steeds dezelfde scenario's plaats vinden waardoor het steeds vaker, heel voorspelbaar een heel duur falen word.

Klant en opdracht
Stelselmatig is het een gegeven dat 'een klant', commercieel veel wordt voor gehouden, zonder ook maar enig idee of wat word 'gepretendeerd' uiteindelijk ook zal worden opgeleverd. In allereerste aanzet is natuurlijk het binnenhalen van de opdracht een gegeven. Daarna? Same old story. Heel veel hiaten in menig voorgestelde processen met heel veel escapes en exits waardoor het vragen is om problemen.

Opdrachtnemer en opdracht
Wat ik hier jammer genoeg niet belees is dat de rechter ook iets anders had kunnen zeggen. Wanneer die namelijk had beseft dat de materie IT ICT, volkomen afhankelijk is van 'Predestined values', constanten, die aan wetmatigheden dienen te voldoen, in elke IT ICT discipline en niveau, dan had Cap niet aan een deelverantwoordelijkheid kunnen worden onttrokken. Immers, als je je opdrachtgever niet goed genoeg weet te informeren over het gegeven op welke wijze IT zich beweegt, hoe daar mee om te gaan, dan benadeel je tegelijkertijd die afnemer.

@PJ Westerhof
Het is volkomen voorspelbaar hoe dergelijk scenario's verlopen en juist vanuit IT oogpunt volkomen verklaarbaar maar ook, voor 100% te voorkomen. Vandaar dat ik dit, en dat heb ik al eerder zo benoemt in deze casus, een blamage van de bovenste plank vind en een aanslag op het aanzien van IT als geheel.

Van Ton Elias heb ik dan weer niet zo'n hoge pet op want hij heeft op geen enkele manier inzichtelijk weten te maken waarom de fails kunnen voorkomen en voor zullen blijven komen. De impotentie, wat mij betreft, zit hem in het gegeven dat 'BIT' gewoon 'CAB' had moeten zijn waardoor je, als je daar 'talentvolle' IT professionals positioneert, je miljardenfalen voorkomt.

Politiek en Commerce zijn twee zeer grote vijanden van een goed werkend IT.

Dat maakt deze publicatie maar weer eens duidelijk. Op naar de volgende fail. Gegarandeerd.

@P.J Westerhof, de zaak is inderdaad complex en in een civiel proces zijn rechters afhankelijk van wat wederzijdse partijen aanvoeren (lijdelijk). Maar de rechters (het gaat om een meervoudige kamer) stellen zich niet lijdzaam op. Als ze geconfronteerd worden met bijvoorbeeld een herhaling van vage insinuerende beweringen uit de dupliek, dan eisen ze ter plekke helderheid van die partij. En die krabbelt dan meteen terug.
Ik heb de indruk dat de rechters zich goed hebben ingelezen. En ze hebben heel wat te lezen gehad, niet alleen vanwege de vele bijlagen, maar ook vanwege de omvang van sommige bijlagen. Daarin staat wat ook in de Computable-artikelen beschreven is en nog heel veel meer.

@René Civile, ik ben het eens dat commercie op dit niveau vaak een kwestie is van een plat halen, hebben en houden. En de zorgplicht wordt daarbij vaak slecht ingevuld of geheel niet; uiteindelijk ten nadele van alle partijen. Dat heeft Capgemini nu ook wel door. En dat is inderdaad ook slecht voor de sector. De rechter heeft aangegeven goed naar de invulling van de zorgplicht te kijken vanwege een claim die verder gaat dan de grens van de exoneratiebeding.
Het is opgevallen dat Capgemini tijdens de zitting voor het eerst aangeeft Equihold keer op keer hebben gewaarschuwd voor een falen van het project. Maar als dat zo is, waarom hebben ze dan in hun dupliek daar dan geen bewijs voor aangeleverd als antwoord op de claim van de heer Berkleef en mijn auditrapport?

De zaak is dus inderdaad niet zozeer 'complex' alswel (enigszins) 'gecompliceerd'.
Je kunt de casus uiteen trekken in zijn onderdelen en aspecten en elk onderdeel en aspect beoordelen op zijn inhoud en kwaliteit. Daarbinnen echter is voor elk onderdeel specifieke expertise vereist.
Dat de onderdelen onderling verband houden doet daar niets aan af, dat is op zichzelf weer een te beschouwen onderdeel (Governance/regie/opdrachtgeverschap/opdrachtnemerschap).

IT-faalprojecten lijken hun eigen wetmatigheden te hebben.
'Het is zelden ingewikkeld, het wordt ingewikkeld gemáákt'.
Als je dat van voldoende afstand bekijkt komen die wetmatigheden vanzelf naar voren.
Dus niet 'één deskundige' die in de warboel duikt, maar een team van deskundigen dat vanuit de juiste overview onderdelen en aspecten onderscheidt en vervolgens waardeert.

Gegeven die wetmatigheden is een faalproject inderdaad voorspelbaar.
Dat is nu juist de essentie van wat ik hier en elders betoog(de).
In hoeverre de oorzaak bij partijen ligt is nu juist weer doel van het beoordelen van elk onderdeel en aspect op zijn inhoud en kwaliteit.

Het gaat mij niet om de persoon Elias maar om het rapport van de commissie.
Ik heb daar eerder al mijn mening over gegeven, maar feit blijft dat het een bijbel is van projectfaalfactoren. Kwestie van lezen 'hoe het niet moet in IT-projecten'.
Het BIT-Toetskader betreft ook slechts een lijstje met 'boerenverstandregels' voor IT-projecten.
Beiden beschrijven de basale ondergrens van IT-projecten, als je daar al niet aan voldoet dan staat de uitkomst grotendeels vast.

De rechter zal zeker niet lijdelijk zijn ten aanzien van de procesvoering.
Ik bedoel hier echter het belang te benadrukken van het aan de rechter helder stellen van de 'overview' en daarbinnen van de diverse onderdelen en aspecten.
Dat is een kwestie van op enkele pagina's objectief formuleren. Daartegen kan geen der partijen bezwaar maken.

Het artikel stelt dat de klacht over de functionele kwaliteit van de software één van de kernpunten is van de rechtszaak en daarnaast dat 'de vraag meespeelt' wie de leiding had over het ontwikkeltraject.
Als dat niet gebeurt vanuit een 'overview' incl. onderdelen/aspecten (offshoring, regievoering, opdrachtgeverschap, kwaliteitsnormen, requirements, testen, etc. etc.) en met achtergrondinformatie (Cie. Elias, BIT, etc.) dan zal het m.i.. de rechter lastiger worden gemaakt het juiste vervolgtraject te bepalen c.q. zonodig wat minder lijdelijk op te treden.
Indien inzichtelijk gemaakt wordt dat de diverse onderdelen/aspecten elk specifieke expertise vereisen - en dat dóen ze - dan zal de rechter aansluitend kunnen beslissen over te gaan tot aanstellen van méérdere deskundigen.

In het Computable-artikel van exact één jaar geleden ('Capgemini 1-2Focus: falen Quality Assurance' - Computable 02-03-2015) gaf ik al mijn inschatting van de rechtszaak.
Mijn 'donkerbruin vermoeden' is ongewijzigd.

@P.J Westerhof, zoals je weet zal de rechtbank een beslissingsboom gebruiken die gebaseerd is op het toepassen van het recht. De indeling van ingebrachte hoofddocumenten zijn grotendeels op zo’n beslissingsboom gebaseerd. Op heel veel punten zal de rechtbank na lezing van de stukken snel een mening kunnen vormen (en waarschijnlijk nu al hebben) omdat bijvoorbeeld de partijen op een punt het met elkaar eens zijn, of omdat de ene partij de argumentatie van de andere partij inhoudelijk niet kan weerleggen (en het meestal ook niet eens probeert). Een deel van de ingebrachte argumentatie kan terzijde geschoven worden. Bijvoorbeeld als in het dupliek de andere partij een aantal standpunten/beweringen wordt toedicht die door hen niet zijn ingebracht, dan kan de rechter zo’n schijndispuut van bij elkaar vele pagina’s negeren.
In verband met het werk door de partijdeskundigen, kan in deze zaak het raadplegen van een of meer onafhankelijke deskundigen heel beperkt zijn. Dat geldt zeker nu het rapport van SIG door een lesboek van SIG onderuit is gehaald en SIG zelf liever over een classificatie spreken, dan over een waardeoordeel. Zie ook mijn artikel “Equihold en Capgemini eindelijk voor de rechter.

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×