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 eerste bijdrage uit het vijfluik van Kurt de Koning gaat over de aanbesteding van Equihold aan Capgemini.
Deze case begint in 2005 en om de juiste relevante context in deze tijdspanne te schetsen, de ict-branche herstelt zich weer uit een dip na de millennium bug en euroconversie. Budgetten waren even op en iedereen heeft nieuwe apparatuur staan. Mondjesmaat beginnen opdrachten weer binnen te komen. Banken zijn druk bezig om te kijken hoe ze meer bonussen kunnen krijgen en de huizenprijzen stijgen nog steeds. Geld in overvloed lijkt de norm.
Op dat moment is offshoring vooral naar India erg hot. Na wat schoorvoetend proberen, besluiten meerdere grote ict-leveranciers om rond 2005 fors in te zetten op eigen afdelingen in India met Bangalore als bruisend middelpunt. Modellen en processen zijn er, praktijkervaring van op grote schaal toepassen van offshore moet nog worden opgebouwd.
Sport ERP
Equihold heeft dan al besloten om zijn sportapplicatie 1-2Focus om te laten zetten naar .Net. Hierbij moet rekening worden gehouden met de mogelijkheid om deze applicatie parameter-gestuurd te maken zodat ook andere sportbonden deze applicatie kunnen gebruiken.
Zo heeft een voetbalteam elf spelers in het veld maar dit geldt niet voor andere sporten. Ook wordt invulling gegeven aan andere aanvullingen, zodat een brede groep van sportverenigingen gebruik kan maken van de applicatie.
Anno 2014 zouden we in dat geval zeker zoeken naar een tool die een automatisch conversie kan uitvoeren.
Offshoring naar India
In ieder geval heeft Equihold gekozen voor Capgemini als partner voor het uitvoeren van deze conversieopdracht. Een opdracht die zeker niet bovenaan de schaal van moeilijkheid staat en dus goed door elke ict-leverancier binnen tijd en budget moet kunnen worden uitgevoerd.
Om ook financieel aantrekkelijk de opdracht uit te voeren, maakt Capgemini gebruik van zijn workforce in India. Indiërs zouden de feitelijke conversie uitvoeren (in India) door handmatig op basis van de bestaande functionaliteit de applicatie te programmeren. In India was men bekend met RUP en zou dit ook toepassen, wat als zodanig in de mantelovereenkomst is vastgelegd. Doordat er ook onshore/front office-medewerkers waren, dit zijn Nederlands sprekende consultants die werkzaam zijn in Nederland, zo nodig op locatie, spreekt Capgemini van een rightshoring-concept.
Alarmbellen
Een niet ongebruikelijke constructie wat ook met de kennis van nu, niet direct zal leiden tot het afgaan van alarmbellen. Het valt moeilijk te bepalen in welke mate deze constructie heeft bijgedragen aan het falen van het project. Falen in die zin dat het project niet heeft opgeleverd wat Equihold heeft verwacht.
Uit andere offshoring-projecten weten we dat gebrek aan businesskennis nogal eens tot misverstanden en vertragingen leidt. In deze case: India is een cricketland en geen voetballand. Ook weten we dat Indiërs uit respect voor de kant niet om opheldering gaan vragen bij onduidelijkheden, maar zelf een passende oplossing bedenken. De kans dat deze exact is wat de klant voor ogen heeft, is zeer klein. Of rightshoring een goed concept is, kan alleen bewezen worden door voldoende succesvolle cases.
Groot, groter, grootst
Op het gebied van leverancierselectie valt direct op dat Capgemini uit een selectie grote ict-leveranciers is gekozen. Ook Brunel, Accenture, IBM en Macaw waren in de race voor de opdracht. Afgezien van Macaw, zijn dit (zeer) grote organisaties met naam en faam die door hun omvang veel mogelijkheden hebben.
Equihold had minder dan tien medewerkers zodat de vergelijking van ‘olifanten doen het ’t liefst met olifanten’, volledig mank gaat. Hierdoor zijn de risico’s die beide organisaties lopen bij dit project volledig scheef. Het participeren met de risico’s had dit kunnen rechttrekken.
Vragen
Bij het bestuderen van de aanbesteding van Equihold aan Capgemini doemen er allerlei vragen bij me op. Had de grootte van een organisatie mee moeten wegen in de besluitvorming en met welke mate, of is het zelfs een knock out-criteria? Zijn er positieve ervaringen waarbij een grote leverancier naar volle tevredenheid zijn maatwerkdiensten aan een zeer kleine organisatie heeft aangeboden? Zo ja, zijn er dan nog essentiële randvoorwaarden? Is participeren in het risico hierin een oplossing en zijn hier ervaringen in? Vragen die tot op de dag van vandaag onbeantwoord zijn gebleven.
Serie
In deze serie van zes artikelen van Kurt de Koning volgen nog vijf delen. Deze gaan over de kwaliteit van de software, 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.
Ik hoop dat Kurt een trage starter is, want inhoudelijk wordt vooralsnog nergens op ingegaan. Algemeenheden over hoe Indiërs (blijkbaar allemaal) zouden zijn en dat muizen olifanten zouden moeten mijden, dragen niet bij aan een analyse van deze case.
In dit betoog zitten een groot aantal zinnen die niet alleen irrelevant zijn maar ook veelzeggend, bijvoorbeeld idee van ‘one-size-fits-all’ SportERP applicatie terwijl we het hier dus vooral over niches hebben. Helemaal hilarisch wordt het als breedte je doel is maar je vervolgens valt over feit dat India een cricketland is, alsof Nederland 16 miljoen bondscoaches betaald voetbal heeft. En ook de opmerking aangaande Indiërs die eigen oplossingen kiezen kan ik niet plaatsen ten opzichte van RUP methodiek waarvan voor- en nadelen van methodiek al voor aanbesteding bekend waren:
https://www.computable.nl/artikel/achtergrond/development/1287375/1277180/projecten-hebben-baat-bij-combinatie-van-rup-en-dsdm.html
In dat kader vraag ik dan ook me af wat het doel is van een vijfluik waarin ‘stromannetjes’ iets mogen roepen over details van de uitvoering zoals code en ontwikkelmethodiek terwijl er vragen zijn te stellen over de businesscase. Als we het over de ‘huid verkopen voordat de beer geschoten is’ gaan hebben binnen aanbesteding dan valt hier nog wel wat te vragen, wanneer we het dan toch over olifanten gaan hebben dan lijkt kleur me hiervan roze.
Ik heb moeite met deze artikelen over Capclaim/Equihold. Waarom kan de analyse niet wachten tot na de zitting op 20 januari, of nog beter tot na de uitspraak van de rechter? Dan kennen we namelijk ook het verhaal van CapGemini en hebben we ook een juridische uitspraak waar we het mee eens/oneens kunnen zijn…
In dit eerste stuk van Kurt mis ik de expert-analyse en de SMART vragen. Wanneer is een organisatie groot of klein? Ja, de grootte maakt uit en zou zeker meegenomen kunnen worden in de sourcing strategie. Ja, er zijn voorbeelden van kleine organisaties die succesvol een grote partij hebben ingeschakeld. Ja, er zijn randvoorwaarden en die zijn hetzelfde als bij iedere outsourcing, wellicht aangevuld met interne eisen zoals continuiteit binnen je project- en demand organisatie. Risico participatie is zeker een mogelijke mitigatie strategie, maar dat is een aansprakelijkheidsclausule ook en agile/incrementeel ontwikkelen ook. Kende Equihold dat al in 2005?
Kortom: allemaal vragen en antwoorden die niet relevant zijn voor de case van Capclaim/Equihold, want daar is niet gekozen voor een supplier met vergelijkbare grootte (waarom niet? dat antwoord moet je halen bij Equihold en wellicht Macaw) en ook niet voor risico participatie.
Kurt, helaas wordt in dit artikel weinig ingegaan op de selectiewijze van Equihold. Ook wordt er niet aangegeven wat de contractvoorwaarden zijn waarvoor Equihold uiteindelijk getekend heeft. Wat heeft Capgemini via de aanbesteding beloofd te leveren en onder welke voorwaarden. Nu blijft de analyse erg vaag en kunnen de lezers moeilijk meedenken over de aspecten van het onstaan van de schade, laat staan er iets van leren.
Bij de schadeafhandeling is er een algemene civielrechtelijke kant en een specifieke contractuele kant. Equihold tekende voor de voorwaarden van het samenwerkingscontract. Wat zegt het contract bijvoorbeeld over de regierol van Equihold versus het projectmanagement van Capgemini en hoe werd dit in de praktijk toegepast? Tijdens een project wil de sluwste partij nog wel eens de rollen onopgemerkt veranderen zonder het contract aan te passen.
In hoeverre was Equihold de keurmeester en welke expertise werd daarbij van Equihold verwacht (en was dat wel redelijk)? Wat is er afgesproken over meerwerk en -kosten, over arbitrage, et cetera?
Verder tekende Equihold tijdens het project ook voor de acceptatie van deelopleveringen en gaf het beoordelingen van Capgemini en de Indiase subcontractor.
Capgemini stelt “Uitgerekend in deze belangrijke fase waardeerde Equihold ons werk met het cijfer 4,65. Op een schaal van 0 tot 5 is dat een score waarvoor we ons allerminst hoeven te schamen.”. In hoeverre heeft Equihold tijdens het project aangegeven tevreden te zijn? Immers niet elk gebrek mag een verborgen gebrek genoemd worden.
Dit soort informatie is belangrijk om te kunnen beoordelen of de claim 30 keer hoger mag zijn dan de contractueel afgesproken maximale schadevergoeding (naast een te bewijzen wanprestatie van Capgemini).
De analyse zal veel dieper moeten gaan wil Capclaim er iets aan hebben.
Beste redactie,
Als term stromannetjes misplaatst is dan geldt dat ook voor de titel, tenminste als ik eerdere berichtgeving van jullie er even bij neem:
“Op een door mij gegeven workshop op de Hogeschool van Amsterdam kwam ik in contact met een cursist die bij Capgemini werkte en enthousiast was over het product. We raakten aan de praat en via hem ben ik met Capgemini in contact gekomen en koos ik uiteindelijk voor dit bedrijf.”
https://www.computable.nl/artikel/achtergrond/erp/5136834/1276992/equiholds-kruistocht-tegen-capgemini.html
In mijn rol als advocaat van de duivel wil ik Capgemini niet vrijpleiten maar een opdracht als “maak eenzelfde product in .Net, zoals we hebben in VB6” klinkt als reversed engineering en dat gevoel krijg ik ook steeds meer bij hele Capclaim. Zeker als je oude schoenen weggegooid hebt voordat je nieuwe hebt, een werkende oplossing in VB6 verdient misschien niet de schoonheidsprijs maar veldervaringen van gebruikers waren zeker in dit traject ook veel waard.