Cap Gemini moet miljoenen vergoeding betalen

Bij de Computable is te lezen dat Cap Gemini Ernst & Young in een 14 jaar oud rechtzaak tegen Stichting Kerk in Nood in ongelijk is gesteld. Hierdoor moet het automatiseringsbedrijf een schadevergoeding van ruim 2,1 miljoen betalen aan de stichting voor een mislukt automatiseringsproject. Ook moet de automatiseerder over 14 jaar rente betalen en de schade die de stichting heeft opgelopen.

Een woordvoerster laat weten dat Cap Gemini onaangenaam verrast is. "Via onze advocaat onderzoeken wij of we in cassatie kunnen gaan." De uitspraak valt het automatiseringsbedrijf rauw op het dak, omdat de rechtbank in Utrecht het bedrijf in 1994 juist in het gelijk stelde. Kerk in Nood ging daarna in hoger beroep, met succes blijkt nu na zeven jaar procederen.

Reacties (34)

[Verwijderd]

Haha dit is de eerste keer dat ik hoor dat een automatiseringsdienst aangeklaagd werd weet niet of dit vaker zicht heeft voorgedaan. Maar dit zal wel een goede stimulans zijn voor andere bedrijven om ook een rechtzaak te beginnen, wanneer de autamatisering niet geslaagd is.

Het gebeurt namelijk redelijk vaak, dat een nieuwe IT infrastructuur helemaal niet de juiste keuze is (achteraf) voor een bepaald bedrijf, dat betekend een enorme verlies post. net als IT planningen die vaak ver over hun oorspronkelijke budget schieten

[mr_a]

De IT heeft een zeer slechte staat van dienst, heel veel klanten zijn erg ontevreden en veel projecten mislukken. Klanten hebben onlogische, of irreële verwachtingen van IT en leveranciers onderschatten altijd de complexiteit en dus de kosten...

[memphis]

Klanten mogen wel onmogelijke wensen hebben maar als de softwarefabrikanten dergelijke wensen kunnen leveren en achteraf door combinaties met ander soft/hardware het toch blijkt niet te werken is dan nog de vraag wie schuldig is.

[Verwijderd]

'Klanten hebben onlogische, of irreële verwachtingen van IT en leveranciers onderschatten altijd de complexiteit en dus de kosten....
Yep en hoe komt die klant aan die irreële verwachting? Ik kan je uit ervaring vertellen dat die verwachting merendeel ontstaan door verkopers van IT-projecten/systemen. Die doen er alles voor om een project binnen te krijgen en gooien er bijna altijd nog ff een schepje bovenop en natuurlijk wil een klant alles (zelfs als ie het niet gebruikt). Hierdoor worden de ontwikkelaars meestal voor't blok gezet en moeten het dan maar weer zien te maken.
leveranciers onderschatten altijd de complexiteit
Meeste projecten zijn vrij simpel van aard maar door toedoen van allerlei regeltjes/IT-geneuzel/standaarden etc, maakt men het meestal veel moeilijker dan het hoeft te zijn en zet men veel te veel mensen op een project. Meestal onder de noemer, beheersbaarder, modulair, lego like, componentbased, etc. Men doet heel veel moeite om het te standaardiseren maar wordt dan meestal weer overtroeft door een volgende 'standaard', waardoor al die oudere weer aangepast/overboord gezet moeten worden. En dat wordt dan het volgend project, mooiste vb daarvan is natuurlijk het millenium geweest en de euro is dat nu. Daar gaan al die valuta projectjes uit het verleden, hoppa to the drain.

[Verwijderd]

Je hebt gelijk dat veel standaarden/ontwerp principes mislukken, dat is vaak de reden dat een project mislukt. Maar om het af te doen als geneuzel is ook onzin. De voorbeelden die jij aanhaalt (euro, millenium) zijn juist problemen wegens een gebrek aan een standaard hiervoor.

Mijn ervaring is meestal dat er juist te weinig aandacht aan een ontwerp wordt besteedt.
Zeker als het project op stoom is, vindt men het veel belangrijker dat iets werkt en zo snel mogelijk af is, dan dat het ook echt goed is opgezet en goed is doorgetest.

[Pietervs]

Maar dit zal wel een goede stimulans zijn voor andere bedrijven om ook een rechtzaak te beginnen, wanneer de autamatisering niet geslaagd is.
En jij denkt dat de automatiseringsbedrijven zich hier niet voor gaan indekken?
Ik zie nu al automatiseringsbedrijven offerte uitbrengen waarin zo'n aantal standaard-disclaimers is opgenomen, dat je geen poot hebt om op te staan al zou je hele netwerk afbranden!

[Bobco]

Heb je de EULA van een standaard pakket als Windows wel eens gelezen? Bijna de enige garantie die daarin gegeven wordt is dat je op het moment van lezen de EULA aan het lezen bent

Maar even serieus: dit is een probleem dat de hele branche raakt. Elk bedrijf dat biedt op een project moet natuurlijk met een prijs komen die 'concurrerend' is. Vaak is de afgesproken prijs helemaal niet realistisch en wordt er vanuit gegaan dat via allerlei 'aanpassingen en uitbreidingen' de door de klant te betalen prijs alsnog fors verhoogd wordt en het project dus kostendekkend wordt.

Cap is natuurlijk geen kleine speler en dit zal veel mensen aan het denken zetten. Overigens is er ook nog een zaak tussen een Haags accountantskantoor en Exact.

[PowerFlower]

Ik zie nu al automatiseringsbedrijven offerte uitbrengen waarin zo'n aantal standaard-disclaimers is opgenomen, dat je geen poot hebt om op te staan al zou je hele netwerk afbranden!

En jij denkt dat je in Nederland daarmee je aansprakelijkheid kunt uitsluiten? Eerdere jurisprudentie heeft al uitgewezen dat zelfs wanneer geleverd wordt wat de klant vraagt, een IT bedrijf als expert een plicht heeft beter te adviseren (de klant weet er immers niet veel van). Zelfs het leveren van "wat in de branche gebruikelijk is" is dan niet genoeg!

edit:
wat is een post zonder een smiley

[Verwijderd]

Haha dit is de eerste keer dat ik hoor dat een automatiseringsdienst aangeklaagd werd

Dit is echt niet de eerste hoor, een paar jaar geleden is er een softwarehuis (bijna) falliet gegaan aan zo'n claim, multihouse dacht ik, die aandelen waren ineens niets meer waard. Het gebeurt wel vaker maar daar hoor je niet zoveel van.
Cap is alleen veel groter, is opgebouwd uit fusies van meerdere oorspronkelijk grote bedrijven zoals pandata, volmac, ernst&young, cap nederland etc, en heeft ook nog eens een aantal dochterbedrijven, dat maakt het dus interssanter (hoge bomen).
Ik vraag me alleen af welk van die oorspronkelijke bedrijven die puinhoop heeft geleverd...

[zwahiel]

Gewoon een paar van die lease wagen de deur uit en wat van die "pak"-mensen weg en hoppa, 2,1 miljoen is zo bij mekaar... (wat aandelen verkopen misschien! >

Maar ik vraag me af waar de 2,1 miljoen op gestaaft wordt, en hoe je in godshemelsnaam een automatiseringsproject überhaubt kunt laten mislukken!

Knappe prestatie hoor voor Cap Gemini

[Verwijderd]

Wat dacht je van het uurloon van Cappers? En als men het als een 'groot' project aantekend, worden er de wereld aan functies uit de kast getrokken die 'nodig' zijn om een project uit te voeren (projectmanagers, projectleiders, FO'ers,TO'er,programmeurs,testers, etc). Ga uit van een uurloontje boven de 200 piek, men gaat natuurlijk uit van een project van een halfjaar, ..... tsingtsing kassa.
Het mislukken van een automatiseringsproject is trouwens makkelijker dan het er laten slagen van 1. Samenwerking tussen bovengenoemde 'functies' is meestal belabberd gezien hoog gehalte aan ego en een hoog gehalte 'belangrijk' vergader geneuzel, waar niemand wat aan heeft en een godsvermogen kost.

[NightOwlNL]

je vergeet overigens dat bij automatisering binnen kerkgebeuren er ook het nodige aan kabels zal moeten worden getrokken, installaties gebouwd, en dat kost ook nog es geld... en inderdaad, dat stomme vergadergeblaat

[10us]

Er mislukken meer automatiseringsprojecten dan dat er slagen. Ze vallen in iedergeval altijd duurder uit.

Vergeet ook even niet dat ze over 14 jaar rente moeten betalen dat bedrag zal ook in de 2 miljoen liggen.

[KeX]

Vergeet ook even niet dat ze over 14 jaar rente moeten betalen dat bedrag zal ook in de 2 miljoen liggen.

Nee de 2,1 miljoen gulden is "slechts" het directe resultaat van de veroordeling zoals deze door de rechter uitgesproken is. De indirecte kosten in de vorm van rente komt hier nog bovenop. Dit kan het totaal te betalen bedrag tot miljoenen brengen zoals in de bron beschreven. Alleen het bedrag in rente is al 2.3 miljoen gulden en daar komen de "overige" schadeposten nog bovenop, welke de advocaat zo al gauw op enkele miljoenen guldens schat. Als laatste is Cap gemini ook nog verantwoordelijk voor de proceskosten van enkele tonnen.

* 786562 klerkx

[zomertje]

Dat is helemaal niet zo moeilijk. Soms zijn de mensen gewoon niet capabel genoeg, soms zijn er gewoon essentiele dingen over het hoofd gezien of is er onvoldoende getest.

Ik moet zeggen dat het ook best ingewikkeld kan zijn, er moet met een hele hoop dingen vaak rekening gehouden worden. Daarnaast is testen soms best moeilijk, bijvoorbeeld als je applicatie door 5000 mensen verspreid over heel nederland gebruikt gaat worden.

Voorbeelden zal ik je besparen, maar ik kan er zo een paar geven...

[metaal]

Hoe je een automatiseringsproject kan laten mislukken??? Makkelijk dus, zoals de mensen hierboven al zeiden.

Voor dat ik aan de opleiding Hogere Informatica begon had ik ook ongeveer die opvatting. Veel mensen denken dat automatiseren ff een programmatje ontwerpen en daarna de boel inkloppen is. Mooi niet dus. Voordat iemand ook maar begint met het ontwerpen wordt er een requirements analis (ofzo, hoe spel je het?) gemaakt, waarin precies staat wat het product moet gaan doen, wat de kwaliteit is, wie de gebruikers zijn, bblablaablabla..

Dit is het punt waar de meeste projecten op stuk lopen. Vaak denken de heren programmeurs en technici: Ow... ik snap het probleem al, ff een programmaatje zus en een databeestje zo . (en de requirements analis wordt dus niet goed uitgevoerd) Achteraf als het programma wordt geimplementeerd blijkt dat de klant eigenlijk iets heel anders in zijn hoofd had, of de applicatie maar half snapt. Vaak is er ook geen rekening gehouden met de organisatiestructuur, die ineens helemaal omgegeooid moet worden, omdat de applicatie dat vereist.

Makkelijk zat dus, zon projectje verknoeien.

edit:
spelvoud

[Verwijderd]

Dit is het punt waar de meeste projecten op stuk lopen. Vaak denken de heren programmeurs en technici: Ow... ik snap het probleem al, ff een programmaatje zus en een databeestje zo . (en de requirements analis wordt dus niet goed uitgevoerd) Achteraf als het programma wordt geimplementeerd blijkt dat de klant eigenlijk iets heel anders in zijn hoofd had, of de applicatie maar half snapt. Vaak is er ook geen rekening gehouden met de organisatiestructuur, die ineens helemaal omgegeooid moet worden, omdat de applicatie dat vereist.

Mijn ervaring met Cap is dus dat ze deze analyse wel doen. Probleem is echter dat soms analyses worden gemaakt die niet kloppen met de werkelijkheid (door gebrek aan inzicht in een bedrijf) of dat juist het bedrijf niet in staat is om aan te geven wat ze nu dus daadwerkelijk willen. Dus als er al een draft versie van de analyse op tafel ligt, dan zijn sommige bedrijven nog geen eens in staat om aan te geven of hun eigen bedrijfsprocessen wel goed in kaart zijn gebracht. En dan wordt er een prototype afgeleverd wat niet voldoet aan de eisen van de klant. Of nog erger, er wordt op dat moment nog steeds niet aan de bel getrokken en pas na invoering van het hele systeem geklaagd. Of projecten mislukken, omdat tijdens het bouwen de bedrijfsprocessen veranderen en deze niet in de software worden meegenomen.

* 786562 plok

[Verwijderd]

Dit soort zaken verbaast mij niets. Ik heb inmiddels een aantal bedrijven gezien welke 'geautomatiseerd' zijn door 'de cap'. Ze zullen best dingen goed doen, ze prutsen echter ook veel. Er worden mensen vers van school (of een eigen opleiding) gewoon aan een project gezet. Als het project eenmaal loopt is het devies 'als het werkt, werkt het', ongeacht hoe rommelig/slecht onderhoudbaar de code ook is.

Men moet ook in het achterhoofd houden dat het 14 jaar geleden is. De tijd van gouden bergen, de it-sector beloofde iedereen een soort van 'totaaloplossing', nogal logisch dat dit frustraties opwekt als het niet uitkomt.

Ik vraag mij af hoe een stichting (kerk in nood) het uberhaupt in z'n hoofd haalt dergelijke bedragen aan automatisering uit te geven.

[Verwijderd]

Ik heb inmiddels een aantal bedrijven gezien welke 'geautomatiseerd' zijn door 'de cap'. Ze zullen best dingen goed doen, ze prutsen echter ook veel. Er worden mensen vers van school (of een eigen opleiding) gewoon aan een project gezet. Als het project eenmaal loopt is het devies 'als het werkt, werkt het', ongeacht hoe rommelig/slecht onderhoudbaar de code ook is.

Waar heb je die info vandaan? Mijn ervaring is juist 100% anders.
En over die schoolverlaters; zijn die dan per definitie slecht? Jij hebt toch ook je vak ergens moeten leren?

[brammus]

En over die schoolverlaters; zijn die dan per definitie slecht? Jij hebt toch ook je vak ergens moeten leren?

Op een school leer je geen vak... je leert de basis...

Pas als je gaat werken, ga je het vak leren...
Toen ik van school kwam ging ik in een lab aan de slag..., alles wat ik geleerd had kon ik weer vergeten, of gebruikte ik niet, ik kon dus weer opnieuw beginnen...

Dus jongetjes/meisjes die net van school komen (ookal hebben ze een jaar stage gelopen), zijn per definitie 'slecht'...
Net als met een autorijbewijs, pas na een jaar of 5 á 10 kan je zeggen dat je kan rijden...

[_mitch_]

maar je kon beginnen in ieder geval...

nou zo begint bij elk bedrijf in elke sector iemand die geen werkervaring heeft. Iedereen is ooit ergens begonnen. Dat wil niet zeggen dat starters geen goed werk af kunnen leveren. Bij een eventuele (korte) interne opleiding en gericht werk aan een onderdeel onder toezicht van een ervaren werknemer kan elke starter fatsoenlijk werk afleveren.

Dat projecten mislukken is inherent aan werken op zich. We zijn allemaal mensen en waar mensen werken... juist ja.

Neemt niet weg dat er een bepaalde standaard door ervaring gegarandeerd kan worden en wanneer DIE standaard niet gehaald wordt je kunt spreken van een slecht project. De oorzaken kunnen daarbij overigens op verschillende vlakken liggen die niet altijd afgetikt kunnen worden (zoals daar zijn: nieuwe technieken waar geen ervaring mee is, onvoorziene toepassingen die er wel in moeten maar niet in de oorspronkelijke opdracht zitten en het prject daarmate verstoren dat de uitgangspositie niet correct is... ACHTERAF etc etc.)

Gegroet...

[Verwijderd]

Waar heb je die info vandaan? Mijn ervaring is juist 100% anders.

Tsja, zoals ik al aangaf.. ze doen ook dingen goed..

En over die schoolverlaters; zijn die dan per definitie slecht? Jij hebt toch ook je vak ergens moeten leren?

Nee dat is niet per definitie slecht. Echter ga eens kijken op een gemiddelde HIO oid en zie met je eigen ogen wat voor prutsers daar rondlopen (sorry heren/dames hio, uitzonderingen die de regel bevestigen zijn er altijd).

Daarnaast levert het direct ongecontroleerd aan het werk zetten van een schoolverlater vaak wazige constructies op (codetechnisch).

[Verwijderd]

Waarschijnlijk is dit bedrag grotendeels gebaseerd op de schade die "kerken in nood" heeft geleden en niet op de prijs die afgesproken is voor het bouwen van de IT-infrastructuur.

[10us]

hmm, dit schept een precedent wat nog behoorlijk vervelend kan zijn voor heel veel IT bedrijven.

ps: wel behoorlijk oud nieuws trouwens

[Oscar Mopperkont]

Of het is juist een voordeel voor veel IT bedrijven. Op deze manier kunnen bedrijven die maar wat aanprutsen eindelijk aangepakt worden. Deze bedrijven gaan dan misschien over de kop en dat zorgt ervoor dat er minder concurrentie komt en dat de consument meer vertrouwen krijgt in de bedrijven die over blijven.

[LaitSolaire]

Ahem, als ik je goed begrijp zijn er dus bedrijven die aanprutsen en bedrijven die dat niet doen. Op welke gegevens baseer je dat?

Ik heb uit andere artikelen begrepen dat een groot deel van alle IT-projecten mislukt, maar uit die artikelen kon ik niet opmaken dat het ging om een bepaalde groep bedrijven, maar eerder dat het een algemeen verschijnsel was.

[Guardian Angel]

Als het is gegaan in de stijl van "dit willen wij bereiken en jullie moeten zorgen dat dat kan" en CG heeft dit geaccepteerd, dan is het vrij logisch en dus terecht dat CG moet bloeden voor een gammel opgeleverd pakket.

Ik spreek uit ervaring (kleinschalig) dat men meestal de truuk uithaalt om de klant te laten beschrijven wat men wil zodat men als leverend bedrijf geen buil kan vallen als er iets ontbreekt. Daarnaast kan men in dat geval extra rekeningen sturen voor meerwerk want de klant heeft immers gekregen wat hij oorspronkelijk wilde?

[ziekloon]

Een algemeen gangbare methode is om op basis van een beschrijving van de gewenste functionaliteit, opgesteld door (of i.s.m.) de klant, een ontwerp te maken, dit te laten goedkeuren door de klant en dan te gaan ontwikkelen. Als er dan zaken ontbreken of anders moeten -en vergis je niet in de eigenwijsheid van klanten die soms lijnrecht tegen je deskundig en door ervaring ingegeven advies ingaan- dan is het toch volledig normaal dat de klant daar zelf voor opdraait?? Natuurlijk moet je in een geval dat de klant iets wil wat niet kan, heel nadrukkelijk iets anders adviseren en dat ook opnemen in notulen van de besprekingen. Als zij het dan toch per se willen... dan moet dat ook voor hun eigen risico gebeuren.

[PowerFlower]

Zie mijn post hierboven: dat zal je niet redden, want jij wordt als expert geacht de klant uit te kunnen leggen wat hij nodig heeft!

[Verwijderd]

Misschien beetje offtopic maar als je de titel van dit stuk leest begin je te twijfelen of Cap Gemini een miljoenenvergoeding moet betalen of dat Cap Gemini miljoenen (dat ze mij en wat vrienden wat uit hun omzetpotje geven ) vergoeding moet betalen.

Ik vind het taalkundig gezien erg raar hoe tegenwoordig bepaalde woorden opgebroken worden zodat er een totaal andere betekenis kan ontstaan.

[vooghel]

Het zal niet veel vaker gaan voorkomen. De leveringsvoorwaarden van de toenmalige brancheorganisatie waren verschillend van korte tijd later opgericht FENIT. Hierdoor zijn de laatste (10?)jaren alle projecten met duidelijkere leveringsvoorwaarden opgeleverd. Duidelijker voor zowel klant als leverancier, en dus minder gauw reden voor een >10 jaar durende rechtzaak

[Verwijderd]

Ik vind als het project is mislukt dan Cap gemeni gewoon moet betalen, of het project alsnog afmaken.
Als iemand zijn huis laat bouwen teken je toch ook niet voor de overdracht voordat alle problemen zijn opgelost?

[wielhelm]

haleeeeeeeeeeluja