Managed hosting door True

'Capgemini verbood contact met Indiërs'

 

'De regierol in het ontwikkeltraject lag bij Capgemini en niet bij mij. Mijn medewerkers mochten niet eens contact opnemen met de Capgemini-ontwikkelaars in India. Dus hoezo lag de regievoering bij ons?'. Dat stelt Kenneth Berkleef, oud-eigenaar van het failliete softwarebedrijf Equihold, in een reactie op het standpunt van de automatiseerder dat Equihold de regierol had bedongen. Beide bedrijven zijn in conflict geraakt over het faliekant mislukken van een sportmanagementsysteem.

Berkleef heeft naar aanleiding van het mislukte project, waardoor zijn bedrijf failliet ging, bij Capgemini een claim neergelegd van 43 miljoen euro. In een reactie daarop liet de automatiseerder weten daarover verbaasd te zijn. Equihold had zelf de regierol opgeëist en had gedurende het traject nooit geklaagd over de kwaliteit van de door de Cap-Indiërs ingeklopte softwarecode, aldus Capgemini.

Volgens Berkleef lag de regie met betrekking tot de ontwikkelwerkzaamheden weldegelijk bij Capgemini. In een schriftelijke reactie laat hij weten dat Equihold zich beperkt heeft tot het bewaken van de ontwikkelrichting - voor welke sport moest een applicatie worden ontwikkeld - en het functioneel toetsen van de applicatie. 'Capgemini hield zich bezig met de werving en selectie van het 'ontwikkel'-personeel, het toezicht houden op dit personeel, het ter beschikking stellen van software, hardware en communicatiemiddelen aan dit personeel en het beoordelen van dit personeel. Capgemini hanteerde, op papier, de zogenaamde RUP-methode om tot productontwikkeling te komen en zou er derhalve op toegezien moeten hebben dat deze methode door het personeel ook daadwerkelijk werd toegepast.'

Verboden

De oud-directeur wijst er op dat directe communicatie tussen Equihold en Capgemini-medewerkers in India tot 1 januari 2007 verboden was. Communicatie bleek bovendien sowieso niet mogelijk omdat Capgemini in India niet beschikte over internetcommunicatiesoftware zoals Skype of Teamviewer en Equihold geen directe telefoonnummers van de India-medewerkers had. Communicatie met India vanaf 2007 was slechts mogelijk via de door Cap aangewezen 'liason officers'. E-mailen met individuele programmeurs vond bij zeer hoge uitzondering plaats. 'Van door Equihold gevoerde regie in deze kan dan ook geen sprake zijn', concludeert Berkleef.  

Niet werd gewaardeerd

Opmerkelijk is verder zijn opmerking dat het eigenlijk niet mogelijk was het ontwikkelwerk uit India kritisch te beoordelen. Berkleef kreeg, naar eigen zeggen, van Roel van Schaik, de toenmalige vice president Capgemini Nederland, te horen dat een lagere beoordeling dan 4.3 (op een schaal van 1- 5) niet werd gewaardeerd en mogelijk tot repercussies zou leiden voor de mensen in India. 'De vervolgbeoordelingen mochten ook niet lager zijn dan de eerste beoordeling en gemakshalve werden deze door Capgemini-medewerkers zelf ingevuld. E-mails die deze gang van zaken bevestigen zijn ingebracht in de gerechtelijke procedure. Deze beoordelingen kunnen derhalve niet gelden als door Equihold in volledige onafhankelijkheid zelf gegeven uitingen van tevredenheid', aldus Berkleef.

Verdraaiing

De constatering van Capgemini dat de door Equihold ingediende claim van 43 miljoen euro dertig keer hoger is dan de maximale schadevergoeding uit het contract, pareert Berkleef met de opmerking dat, indien er in de gerechtelijke procedure wordt vastgesteld dat er sprake is van grove schuld, opzet of onrechtmatig gedrag van Capgemini, de rechter de beperking van de aansprakelijkheid ter zijde kan schuiven.

Hij meent dat daarvoor zeer goede gronden aanwezig zijn en wil in de procedure aan de hand van de source code en de beschikbare documentatie aantonen dat er sprake was van spaghetticode, misleiding van de klant over de kwaliteit van programmeren en het verdraaien van de werkelijkheid binnen de Capgemini-organisatie op diverse niveaus, met name van de klantbeoordelingen en het standpunt van de automatiseerder dat Equihold pas voor het eerst klaagde over de software na het faillissement.

Rijkaard

Berkleef is tevens verbaasd over de opmerking van Capgemini dat het niets weet van de betrokkenheid van ex-profvoetballer Frank Rijkaard en/of zijn zaakwaarnemer bij de claim. 'Frank Rijkaard heeft via zijn investeringsvennootschap een belang van 8 procent in Equihold BV. Hierdoor heeft hij uiteraard belang bij het verdere verloop van de procedure. Op 27 mei, de dag voordat de zaak bij de Rechtbank werd ingediend, is de zaakwaarnemer van Rijkaard door mij op de hoogte gebracht', beweert Berkleef.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5107022). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

Het meeste werk wat in India (of elders) is uitgevoerd, heeft bij de meest Nederlandse bedrijven NOOIT beoogde wist opgeleverd.

De Multinationals (zoals ABN Amro en ING) hebben veel geld verloren aan dit soort projecten. Het lijkt dat het opgelopen verlies in deze projecten zijn verhaald op de Nederlandse burgers, door hun diensten en producten duurder te maken.

Tevens zijn er duizenden werknemers uit India gehaald ter vervanging van de Nederlandse ingezetenen. Terwijl duizenden Nederlandse ingezetenen werkloos zijn.

Ook zijn er duizenden werknemers uit Oostbloklanden opgehaald ter vervanging van de Nederlanders (helaas zijn de allochtonen het meest getroffen).

@Peter:
"Tevens zijn er duizenden werknemers uit India gehaald ter vervanging van de Nederlandse ingezetenen. Terwijl duizenden Nederlandse ingezetenen werkloos zijn."

Dagelijks rijden er duizenden mensen van Utrecht naar Noord-Holland, terwijl er in Noord-Hooland duizenden bewoners werkloos zijn. Tja, zo zit de wereld in elkaar, het is aan werknemers en werkgevers om elkaar te vinden en een voor beiden gunstige arbeidsovereenkomst met elkaar te sluiten. In sommige staatsvormen is zoiets te voorkomen, maar hoe aangenaam en welvarend zijn die?

Die hele outsourcing-hype gaat nu steeds nadrukkelijker zijn wrange vruchten afwerpen. Na de onverstaanbaar Engels brabbelende Indiaase en Pakistaanse 'helpdesk-medewerkers', blijkt nui ook meer een meer dat ook hier de communicatie een breekpunt kan zijn.
Net zoals die doorgeschoten cloud-hype straks dezelfde ellende zal gaan opleveren. Ook hier wordt zonder er voldoende over na te denken maar voetstoots aangenomen dat de cloud 'de' universele oplossing en toekomst van de IT is. In een aantal gevallen zal dat zeker ook het geval zijn, maar het is zeker geen Haarlemmer-olie tegen alle kwalen en haaruitval...
Het wordt tijd dat we binnen de IT inzien dat hypes niet altijd tot het gewenste resultaat leiden en dat we moeten blijven nadenken over toegevoegde waardes, pros en cons.
Maar ja, zolang snelle jongens dit wereldje regeren en gretig en met marketinggeweld op dit soort hypes duiken om er optimaal munt uit te kunnen slaan, zal er weinig aan die kortzichtigheid veranderen, vrees ik...

Met dit artikel is een cruciaal punt aangestipt, namelijk wat is regie? Velen nemen het woord regie in de mond zonder dat ze weten wat het betekent. In 2010 hebben Wortmann en Kremer regie als volgt gedefinieerd:

In tegenstelling tot het managen is regievoering het beïnvloeden, verleiden, motiveren en ondersteunen van betrokkenen bij een programma of een project om ze datgene te laten doen dat volgens een vooraf bepaald en overeengekomen scenario is vastgelegd en dat op een manier waarop de verschillende verwachtingspat ronen op elkaar afgestemd zijn. Direct betrokkenen zijn (voor een deel) eigenaar van een proces waar het programma of het project op van invloed is

Uiteraard zijn er meerdere vormen van regie, ook in de ICT. Belangrijk is om welk scenario het gaat in bovenstaand artikel. De conclusie van Berkleef is dan ook wel erg kort door de bocht.

Zonder partij te kiezen voor Berkleef, omdat ik hier niet het fijne van weet, moet ik wel constateren dat de verklooimethode Capgemini na decennia blijkbaar nog steeds bestaat. Er worden steeds weer nieuwe Muppets gevonden.

Het kan bij Capgemini goed misgaan als de hotemetoten op het Capgemini-kantoor zich bemoeien met de projecten en opdrachten. Ze sturen alleen maar op geld en niet op inhoudelijke voortgang en manipuleren daarbij de communicatie. Ze zijn niet capabel om projecten aan te sturen. En als het misgaat, dan laten ze het gewoon verder misgaan zolang de cashflow goed is en geven ze aan dat alles goed verloopt. Bij klachten geven ze de opdrachtgever de schuld, die had dan eerder aan de bel moeten trekken. Zo nodig branden ze ook nog eens eigen lager personeel af. Het is jammer, want op zich weet Capgemini uitstekende mensen aan te trekken.
Kent één van de lezers een groot Capgemini-project dat goed is afgerond?

Je moet bij dit soort bedrijven pas uitbesteden als:
- Je precies weet wat je wilt en dit goed op papier zet;
- De opdrachtnemer kan aantonen dat deze capabel is om de opdracht uit te voeren;
- Je een gedegen contract weet op te stellen, waarbij de opdrachtnemer een flinke boete moet betalen bij het niet nakomen van de afspraken.
Daarbij kan je zo nodig een outsourcingadviseur inzetten.

In andere gevallen kan je het beter zelf doen, of zelf mensen inhuren en die door eigen mensen laten aansturen. Want anders wordt uitbesteden alles behalve ontzorgen, vooral als de outsourcing ook nog eens gepaard gaat met offshoring.

Ben benieuwd hoe dit afloopt.

Outsourcing kost niet alleen geld, maar brengt zich mee veel hoofdpijn....... en vaak verlopen dit soort trajecten dramatisch.

Laat de snelle jongs dit maar weten.......
deze snelle jongens zijn nu gewaarschuwd...

Wat opmerkelijk hieraan is dat steeds duidelijker wordt dat Capgemini en dochter Sogeti op het verkeerde paard hebben gewed (ze zijn overigens niet de enige). De grote mannen in Parijs, en de lokale directies in Nederland, stuurden de organisaties op het verkopen van "India" want dat moest groeien, dat zou de toekomst zijn. Ze hebben nooit willen zien dat de voordelen niet zo groot zijn, cultuurverschillen en taalproblemen moeilijk of niet te overwinnen zijn, de kwaliteit (veel) lager is, ze soms niets van onze business begrijpen en het (de klant) per saldo meer kost dan dat het oplevert.
Daarnaast is het fenomeen offshoring voor de IT grotendeels achterhaald. Je kunt vandaag de dag steeds meer met software oplossen. Kort door de bocht; in het analysedeel kun je steeds meer kwijt en aan de hand daarvan wordt de applicatie gegenereerd. Het programmeren wordt steeds minder en het analysedeel meer.

In mijn ogen is het opzetten van grote offshoringfabrieken in India een strategische blunder.

@Brian de Bruin, 03-06-2014 16:26

"In mijn ogen is het opzetten van grote offshoringfabrieken in India een strategische blunder."

U heeft ongetwijfeld gelijk.
Echter, de multinationals zullen alles aan doen om te bewijzen dat blijven ontwikkelen applicaties in India de beste oplossing is en vrij goedkoop. Daar de managers die verantwoordelijk zijn voor de offshoring hun gezicht niet willen verliezen bij hun topmanagers.

Dus het blijft voorlopig "blunderen" bij multinationals zoals bij AbnAmro en ING om de applicaties in India/Oostbloklanden te ontwikkelen.


@Peter Boom ... leuke stelling, en ik denk dat er ook wel een kern van waarheid in zit.

Maar het is zo makkelijk om, vanuit hier, de Indiërs de schuld te geven, want die snappen het Nederlands toch niet en zullen niet in verweer gaan.

Menig project, bedrijf en ofshoring traject zijn al ter ziele gegaan doordat managers geen gezichtsverlies willen lijden en/of vooral voor eigen gewin gaan in plaats van bedrijfsbelang

Geloof ook niet dat het aan de kwaliteit van de ICT-ers van ver ligt maar wel aan de manier waarop zo een project in elkaar steekt als je het zo leest. De afstand tussen gebruikers/klant en de ontwikkelaars is letterlijk en figuurlijk erg groot. Teveel ertussen. Dat kan eigenlijk niet goed gaan als je zo je projecten uitvoert.

Als Zorgware BV heb ik, samen met mijn Oekraiens team, in 2007 een applicatie gebouwd voor het ministerie van Defensie, dat 6 jaar onafgebroken en zonder één enkele foutmelding heeft gefunctioneerd. Helaas moest het vervangen worden door een SAP applicatie. Ondanks alle bemoeienissen van de afdeling zelf is men nu al 2 jaar bezig om iets te bouwen waar men ook wel mee zou kunnen werken. Echter is volgens mijn info SAP absoluut ongeschikt om als webapp in een oorloggebied goed te functioneren. Recentelijk hebben we het bouwen van een applicatie gestart met een bedrijf in India. Dat gaat goed mits alle regie en kennis uit Nederland komt. Laat men daar dan maar de code kloppen en testen. Maar wel ontwikkelen op een dermate flexibele manier dat we daarna nog zelf kunnen instellen, afregelen en fijnslijpen zonder de noodzaak van kennis uit India. Het is dus een kwestie van een kleine organisatie met een voldoende kennis van zaken in Nederland houden en dan kan het klaarblijkelijk wel goed gaan.

Aan de Computable topics kan nu definitief het topic 'Insourcing' worden toegevoegd.... Nu de experts nog zien te vinden.

Eindverantwoordelijkheid kun je niet uitbesteden.
Zelfs als je een televisie koopt ben je zelf verantwoordelijk voor het vaststellen van de specificaties en het controleren of aan de specificaties wordt voldaan. Ook de plaatsing in een bepaalde ruimte, de stroomvoorziening en het onderhouden - schoonhouden, garantie afsluiten, e.d. - zul je zelf moeten regelen.
Voor software kun je een analogie schrijven (applicatielandschap, verantwoord gebruik, professioneel onderhoud, etc). Bij maatwerk software is het nog wat complexer dan bij een standaard off-the-shelf-product, omdat de opdrachtgever dan ook een verantwoordelijkheid TIJDENS de realisatie heeft (status-/kwaliteitscontrole, risico management, contract management, communicatie naar interne stakeholders, etc.).

Zeker als je software zo bedrijfskritisch is moet je een slimme(re?) contractvorm kiezen, waarbij je de opdrachtnemer (bijvoorbeeld in een joint venture) deelgenoot maakt van falen/succes. Waarschijnlijk kom je dan niet bij CapGemini uit: de schaalgrootte (en dus het risico) is simpelweg niet vergelijkbaar met die van de opdrachtgever.
Als je dat bij contractering goed doet, hoef je niet jaren later rechtszaken te voeren over het verdelen van de pijn.

Deze discussie (en rechtszaak) gaat dus over - gecontracteerde - verantwoordelijkheid en niet over regievoering.

Er zijn in India ook zeer goede programmeurs, dus laten we ze niet allemaal over 1 kam scheren. Als we Nederlandse programmeurs met weinig ervaring inzetten is de kans op slechte software net zo groot.
Wat wel vaak voorkomt, is dat het voordeel van de lagere kostprijs in India weer te niet wordt gedaan doordat meer mensen of meer uren nodig zijn dan dat het in Nederland zou worden gebouwd. Komt nog bij kosten voor vertalingen van specificaties van Nl naar Engels en weer terug, reiskosten, communicatiemiddelen en het oplossen van fouten door miscommunicatie. Dus je moet je wel goed afvragen of outsourcing een goede oplossing is voor jouw project. Kleine, co-located cross-functional Agile teams met face-to-face contact met de klant en eind-gebruikers kan zomaar veel meer opleveren.

@Els

Het probleem zit niet in de kwaliteit van de programmeurs, het probleem zit hem in de ingewikkelde communicatie en de extra management lagen die noodzakelijk zijn. Tel daarbij op de dat de ontwikkelaars geen enkele materie kennis hebben en de grote cultuur verschillen en het wordt duidelijk waarom al die geoutsourcde projecten mislukken.

Uiteraard begrijp ik dat Cap blijft volhouden dat jullie offshoring met Agile, co-locatie etcetera vanuit Utrecht echt voordelen hebben maar geef dan ook een paar geslaagde voorbeelden. Welk project heb jij afgelopen jaren succesvol afgerond waarbij alle partijen tevreden waren en jullie niet over budget gegaan zijn en ere achteraf niet allelei problemen de kop opstaken? Hoe kan jij goede programmeurs in India vinden met een lagere kostprijs dan ontwikkelaars in loondienst?

Het is bijzonder lastig van afstand over iets te oordelen als je de in's en out's niet kent. Assumption still is the mother of all fuck ups..... in the end.

Wat ik wel weet is dat het niet moeilijk is uiteindelijk uit te leggen waar en waarom het fout is gegaan. Dat heeft alles te maken dat bepaalde wetmatigheden in en rond IT niet werden gevolgd met alle gevolgen van dien.

http://bit.ly/1xaIhGP laat zien wat ik bedoel. Wanneer je gewoonweg niet goed signaleert en controleert, geen vinger aan de pols hebt, loop je al snel hopeloos achter de feiten aan. En dan loop je in discussies als deze.

Datzelfde geld voor de positie van Berkleef. Men had het kunnen weten. Sterker nog, wanneer de processen op orde waren had men het domweg moeten weten.

@Els

"Kleine, co-located cross-functional Agile teams met face-to-face contact met de klant en eind-gebruikers kan zomaar veel meer opleveren."


Als het 'zomaar' veel meer 'kan' opleveren, kan het dus ook 'zomaar' veel minder opleveren. Tja.

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

×
×