Managed hosting door True

Zembla: Capgemini deelde de lakens uit bij SVB

 

De Sociale Verzekeringsbank (SVB) nam bij de ontwikkeling van een nieuw computersysteem voor de uitbetaling van de kinderbijslag en aow ‘extreme risico’s met gemeenschapsgeld’. Verder werd interne kritiek geweerd en leed het management aan een ‘tunnelvisie’. Leverancier Capgemini liet in India krakkemikkige software bouwen en kreeg daarvoor gewoon betaald zonder dat de SVB de code had bekeken. Uit onderzoek van tv-programma Zembla blijkt dat de verantwoordelijke projectmanager bij SVB een ingehuurde zzp'er was die door het automatiseringsbedrijf werd betaald.

Dat blijkt uit interne documenten die in het bezit zijn van Zembla en uit beëdigde verklaringen van oud SVB-werknemers. Per jaar zou met het computersysteem veertig miljard euro aan aow en kinderbijslag worden uitbetaald. De Zembla- uitzending ‘De Spaghetticode’ toont ook aan dat één SVB-manager werd betaald via de leverancier van het computersysteem, Capgemini. Dat wekte wantrouwen bij personeel van de SVB over de onafhankelijkheid van deze programmamanager.

Tijdens de ontwikkeling en bouw werden kritische SVB'ers 'weg gemarginaliseerd', zo stelt Berl Sijes, oud-werknemer van de SVB. 'Mensen waren bang', aldus Sijes in de tv-uitzending van het Vara-onderzoeksprogramma Zembla. Er heerst volgens diverse bronnen een angstcultuur binnen de SVB. 'Alleen mensen die het geluid van Capgemini lieten horen, bleven over', stelt een it-specialist die voor de SVB werkte.

MRS

Vorig jaar trok de SVB de stekker uit het MultiregelingenSysteem (MRS) na een investering van ruim 43 miljoen euro, zonder dat het maar een moment had gefunctioneerd. Leverancier Capgemini liet de software op zijn kantoor in India bouwen. Een oud SVB'er die een bezoek bracht aan de Capgemini-vestiging in Mumbai zegt in Zembla: 'Het was echt triest om te zien dat er niet professioneel gewerkt werd (...) Na lang doorvragen zeiden ze, dit gaat nooit werken'. De oud SVB'er zag bij Capgemini in India vooral veel onervaren programmeurs aan het werk die weinig begrepen van de Nederlandse regels omtrent de kinderbijslag en aow. Zijn waarschuwingen vonden bij het Nederlandse management geen gehoor, stelt hij.

Ondertussen kreeg Capgemini de rekeningen gewoon betaald, verklaart een andere oud-werknemer: 'De rekeningen van Capgemini werden betaald terwijl de programmatuur nog helemaal niet door de SVB bekeken was.'

Schijn van belangenverstrengeling

Uit onderzoek van Zembla blijkt dat SVB-manager G., die verantwoordelijk was voor MRS, werd betaald via Capgemini. De SVB huurde hem in als zzp'er en gebruikte Capgemini als zogenaamd mantelbedrijf. Deze constructie is niet strafbaar, maar volgens oud-SVB'ers bestonden er vraagtekens over de onafhankelijkheid van de manager. Manager G. verklaart hierover tegenover Zembla: 'Ik snap dat de schijn van belangenverstrengeling kan ontstaan, maar ik heb schriftelijk vastgelegd dat ik geen sturing van Capgemini zou accepteren'.

Ict-deskundige, ondernemer en Computable-opiniemaker René Veldwijk is onthutst over deze constructie. 'Je eet van Capgemini, Capgemini eet van jou. En die situatie wordt gecreëerd door de SVB en niemand anders. Het is natuurlijk volstrekt onbestaanbaar dat de persoon die het bedrijf Capgemini controleert, zelf zijn rekeningen naar Capgemini stuurt. Dat is ongehoord!'

Zembla ontdekt ook dat de facturen van manager G. werden gecontroleerd door onder meer SVB- ambtenaar R. die naast zijn werk voor de SVB tegelijkertijd zakenpartner blijkt te zijn van G. Ze hebben samen een bedrijfje gespecialiseerd in ict-projecten.

De uitzending is vanavond te zien om 20.25 bij NPO 2.

Lees ook de opinie 'Marktleider in de ICT faalindustrie' van René Veldwijk/


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

7,2


Lees meer over



Lees ook


 

Reacties

Dat met die mantelovereenkomsten is wel geloofwaardig. Dat gebeurt overal om binnen de regels zelfstandigen in te huren of mensen van buiten de mantel. Dat zegt niet zo veel. Het is echt administratief, en meer niet. Veldwijk (en wellicht Zembla) moeten zo'n administratief detail niet opblazen tot een vette suggestie.

De vraag is meer of Capgemini de hand heeft gehad in de keuze van de ZZP-er. Je ziet vaak bij organisaties dat er geen harde muur wordt gehandhaafd tussen advies en uitvoering. Zo krijg je "wij van WC-Eend adviseren WC-Eend" en ook de belangenverstrengeling. En dat is een serieus probleem.

Tot slot: het niet controleren van code die een leverancier levert is sowieso amateuristisch. Op zijn minst laat je er toch een onafhankelijke IFSQ audit o.i.d. op los die je ook vooraf met de juiste levels in het contract zet? Doe je dat niet dan ben je als opdrachtgever toch wel een knoeier.

Dit is niet het eerste schandaal bij overheidsprojecten waar Capgemini bij betrokken is. Hoeveel zouden er nog volgen?

Ja, eh, uitzendingen, uitzendingen en nog eens uitzendingen.
Wordt er ooit nog iemand opgepakt, aangeklaagd en veroordeeld (met hardhandige terugvordering van zijn/haar illegaal verkregen voordeel)?

Dit heeft wederom te maken met het lerend vermogen van de overheid en de kennis van IT. Toch blijft de overheid obv marktplaatsen de goedkoopste mensen uitzoeken voor belangrijke IT projecten of wordt de verantwoordelijkheid teveel bij de leverancier gelegd. Governance, kwaliteit, kennis en ervaring doen er echt toe en zijn beschikbaar in NL; alleen niet obv het proces dat de overheid voert. Verder is dit een schande van CG dat ze zo willen werken.

@Gerben Wierda.
Dus u noemt de inhuur van een programmamanager van de leverancier "zo'n administratief detail niet opblazen tot een vette suggestie"?

Dat zou het kunnen zijn. Ware het niet dat deze ingehuurde programma manager werd gecontroleerd door zijn eigen (!) zakenpartner, toevallig ambtenaar bij de SVB. Dan houdt voor mij alle geloofwaardigheid op.

Duidelijke belangenverstrengeling naar mijn idee! De oplossing voor dit alles is dat Cap de 43 miljoen terug betaalt. Er is immers niets geleverd. Misschien is het ook nog eens aardig om te bekijken wat G. aan vergoeding van Cap heeft ontvangen, zijn er bijvoorbeeld extra bonussen uitgekeerd?

Iedereen lijkt ervan uit te gaan dat het de bedoeling was dat hier daadwerkelijk een werkend informatiesysteem werd opgeleverd. Terwijl het toch vrij evident is dat in dit geval het doel was om zoveel mogelijk geld uit de waardeketen te trekken: een bereidwillige betaler (de overheid) met als extra verzekering iemand die de facturen zonder probleem accodeerde, ondanks het geleverde werk. Onderaan de keten een goedkope partij die het daadwerkelijke werk moest verzetten.

En in het midden een ingehuurde manager G die, samen met zijn rijksmaatje R zoveel mogelijk geld uit de keten trok.

Maar het betreft hier de overheid en een moeilijk onderwerp als ICT (zie Elias) dus er gaat echt niemand veroordeeld worden.

Daar is niemand anders op aanspreekbaar dan het senior management van de SVB. De onkunde bij de selectie van het projectmanagement, de angst cultuur en het gebrek aan feeling met de praktijk, allemaal management.

Verbaasd ons dit nu heus? We hebben net het PGB debacle aan ons voorbij zien trekken. Dat project moest in drie/vier maanden tijd eventjes geklaard worden, en op 1 januari 2015 draaien. In plaats daarvan wordt het nu 1 januari 2016 dat alles pas goed draait.

Ik kan mij goed voorstellen wat voor type management daar zit. Dat zijn van die managers die roepen dat er iets moet gaan gebeuren binnen een bepaald tijdsbestek, en dan verwachten dat het ook gaat gebeuren, want zij hebben immers gezegd dat het moet gebeuren. Specialisten die zeggen dat het niet kan, zijn zeurpieten die de grote lijnen van hun magistrale beleid niet begrijpen. Al die technische problemen zijn details, die moeten oplosbaar zijn tenslotte. Dan zet je er maar wat meer mensen aan.

Dat soort figuren tref je overal aan en je moet ze direct lozen. Weg er mee, ze zijn funest voor elk bedrijf of instelling.

Voeg Zembla nog even in die waardeketen toe. Ook die jongens en meisjes eten - als het feest voorbij is - nog graag even mee. Alle zakken gevuld, leuk programmaatje over gemaakt (allemaal kijken ICT-ers!), en dat was het dan.

Soms vraag ik me af of de overheid het expres doet. ICT budgetten 'over de balk smijten', Maar wat ik kwalijker vind is dat de ontvangende partij van dit verspilde belastinggeld steeds vaker Capgemini blijkt te zijn.
Vriendjespolitiek?

Waarom noemen we het beestje niet bij zijn naam: corruptie

Wat mij opvalt is het onderdeel "India". "Leverancier Capgemini liet in India krakkemikkige software bouwen". Tuurlijk. 3e wereld SOF(t)ware. 4sure! Net als overal waar die mensen ook bij ons onshore(!) worden ingezet. Zo is het fenomeen 'structured programming' in Indiase kringen totaal onbekend. Als ze er al iets mee doen, dan is het puur cosmetisch zonder enig begrip van de achterliggende filosofie b.v. dat een component wordt beschreven door de onderliggende componenten bij een datadriven structuur. Een volkomen onbekend fenomeen bij die boys en girls, terwijl hier het VSP en JSP gebeuren toch echt wel redelijk in zwang is geweest. We hadden hier vooral in financiële kringen een aardige programmeer-cultuur. Menigeen zal zich dat herinneren. Omhooggevallen graaimanagers hebben kwaliteit als niet zinvol en duur weggegooid. Dit is het trieste resultaat. Leergeld. Doe er wat mee!

... en er zijn alweer miljoenen onderweg: http://www.computable.nl/artikel/wie_gunt_wat/5591305/3152533/logius-kiest-partners-voor-miljoenenklussen.html

Ik vermoed dat ze inmiddels teveel verstrengeld zijn met incompetente beslissers - die niet anders meer kunnen dat Cap betrekken bij hun projecten. Iets met angst voor beerputten en deksels misschien?

Als het project succesvol was, had niemand er over geklaagd.

Als de geleden schade daadwerkelijk 43 miljoen is en als VSB deze niet terug kan krijgen middels een claim, dan heeft ook SVB het ook fout gedaan als slechte opdrachtgever.

Helaas is het allemaal niet zo simpel... Ik ken de details niet, al ziet het er allemaal niet goed uit, maar ik stel me de volgende situatie voor:

- SVB maakt een tender en vraagt om een systeem met bepaalde specificaties. Een aantal partijen doet schrijft zich in op de aanbesteding. De projectwaarde is zo'n 20 miljoen, maar Cap Gemini biedt aan om het voor 10 miljoen te doen. Zwaar onder de kostprijs en dat werkt prima om de tender binnen te halen, want zo weten ze, zo'n complexe aanbesteding zit vol met fouten en voortschrijdend inzicht en als snel wordt dit na het winnen duidelijk. Nu zijn beide partijen te houden aan dit contract, maar SVB gaat geen tien miljoen betalen voor iets wat ze eigenlijk niet willen hebben dus wordt het contract soort van open gebroken en komt er een "vrije na calculatie". Logisch want SVB moet steeds de requirements aanpassen naar nieuwe inzichten en fixed price is dan niet meer mogelijk. De opdrachtgever maakt er echte zo'n potje van dat het product een draak is geworden en SVB geen enkele claim meer kan neerleggen omdat de Cap jongens wel professionals hebben in contractenmanagers (waren hun programmeurs maar zo goed).

Dan nog even inhoudelijk. Er staat dat de mensen uit India de NL regels niet goed begrepen, maar ook dat lijkt me een verkeerde aanpak. Je kunt prima een systeem laten ontwikkelen met als doel op basis van input en dossier betalingen te verrichten. De business rules zouden echter niet in India gemaakt moeten worden, alleen het generieke systeem. De inrichting zou in NL moeten gebeuren... maar goed, dat is een detail.

Een verhaal heeft altijd twintig kanten, dus schieten vanuit de heup is ook niet sjiek. Maar dit zijn geen unieke verhalen en dat baart me zorgen.

@Henri & @CobolCrox Maar om het nu bij de programmeurs hier of in India neer te leggen, dat is wel heel eenvoudig. Programmeurs zitten aan het einde van de lijn en die moeten gewoon doen wat de gevraagd wordt, er zullen uiteraard goede en slecht in zitten maar dat is niet de kern van het probleem. Denk alleen dat op grote afstand werken en alleen op basis van specificaties (worden die nog gemaakt tegenwoordig? alles is toch een grote aaneenschakeling van user stories?) niet gaat werken net zoals hoe meer mensen je er tegenaan gooit hoe grote de puinhoop wordt.

Wel eens met Henry dat ik ook bang ben dat dit soort praktijken veel meer voorkomt, onderhandse handeltjes bij inhuur van personeel en een ons kent ons cultuur bij aanbestedingen. Of je elkaar nu van Nijenrode, het corps, de hockeyclub, een politieke partij een vorige job of wat dan ook kent, ergens in die hoek zit het. Het is zo oud als de weg naar Rome. Je kan maar een ding doen, het zo inrichten dat de kans op deze constructies minimaal is. Dus, in dit geval stoppen met het uitbestedingscircus. Gelegenheid maakt de dief.

Je kunt naar Capgemini kijken maar was er laatst niet een rapport Elias over slecht opdrachtgeverschap bij de overheid? Zembla is altijd vooringenomen en uit op een scoop. Had liever een objectievere bron gezien. Maar goed we wachten de reacties wel af.

@Ruud: zou een professionele partij als Cap, die al jaren zaken doet met die slechte opdrachtgever, daar dan niet allang lering uit getrokken moeten hebben om er voor zorgen dat projecten alsnog tot een goed einde worden gebracht?

En of Zembla het nu onderzoekt of een ander, dat maakt niet uit; als het maar onderzocht wordt, want dit loopt de spuigaten uit - en jij/ik/wij maar belasting betalen...

De hele overheids-ICT staat sowieso stijf van de ZZP'ers, die elkaar ook nog eens regelmatig de bal toespelen. Definieer 'corruptie' daar maar eens. Cap Gemini fungeerde volgens mij alleen als 'framework' opdrachtnemer, en daar komt dan het salaris van die programma-manager vandaan. Denkt iemand overigens nou echt serieus dat het probleem is ontstaan door 'slechte programmeurs'....? Laat me niet lachen.

Heeft de overheid geen goede projectmanagers en functioneel analisten op de eigen loonlijst staan? Lijkt me veel verstandiger en goedkoper.

Volgens mij had Capgemini tijdens de aanbesteding aan SVB beloofd om alles met Oracle spullen, namelijk OPA en Siebel te doen. De belofte was dat je dan geen enkel maatwerk meer nodig had, en al je business rules makkelijk in OPA kon intiepen. Programmeren was dus helemaal niet nodig zo was de belofte.
Vreemd dus wel dat nu die arme jongens in India de schuld krijgen omdat zij onleesbare en niet werkende code schrijven waar de Nederlandse regels niet inpassen. Dat was toch ook helemaal niet de bedoeling?

Het is op zich niet uitzonderlijk dat de projectleider wordt geleverd door de softwareleverancier. Bij gebrek aan beter binnen de klantorganisatie. Maar dat dat meestal tot problemen leidt is ook een gegeven.
Makkelijk toch: je bent als klant nooit verantwoordelijk.
Ik hoop dat Zembla dan ook de zwarte piet neerlegt bij de opdrachtgever, de SVB dus.

-Machteld Meijer.
Er is maar één partij EINDverantwoordelijk en dat is CapGemini. Ze hebben niet geleverd wat er werd uitbesteed. Makkelijker kunnen we het niet maken. De software heeft toch nooit gewerkt?
Ze hebben gekozen voor een krakkemikkige oplossing om te gaan prutsen in India. Vervolgens alles onder het tafellaken vegen door je eigen programma manager die werd gecontroleerd door een zakenpartner, tja...
En wat betreft Zembla, don't blame the messenger.

Ik vind de reactie van Henri Koppen het meest passend bij de waarheid. Vaak worden in de directie board de plannen en de beslissingen gemaakt. Totaal in isolement met de rest van de organisatie, bedrijfsvoering ,administratieve organisatie (AO) en de interne controle (IC). Echter bij de overheid, Belastingdienst, UWV, SVB en Defensie spreken alleen de rangen en schalen. Ik heb in mijn diensttijd altijd geleerd dat rang en kennis is en blijft een constante.
Dus je hebt kennis nodig die bij jezelf ontbeert. Op het moment dat een grote partij bij de beleidsmaker aan tafel zitten een KPN, IBM, CAPGEMINI, gaan er andere processen en belangen spelen. Meestal na de grote opdracht komt de bonus voor de overheids programma manager, een plaatsing bij FOX-IT, SAP, Thales, Dame en/of IMTECH ( bij die laatste moet je nu even niet zo blij mee zijn).
Het programma SPEER, natuurlijk geheel buiten de scope van Tijd en Geld, is de grootste fout dat ze het veranderingsproces niet hebben geassimileerd in de bedrijfsprocessen van Defensie, het functioneel beheer van SAP bij een consortium neergelegd en het technisch beheer bij de IV-ICT afdeling van Defensie. ( Die op punt stond ge-outsourced te worden naar hetzelfde consortium). Gelukkig greep de Minister van Defensie in en vele (dure) externe adviseurs schreven voor een sterke regie functie ( Business and IT aligment) en veel Governance ( wie beslist er nu in een organisatie, bij Defensie weten ze dit nog steeds niet ?). Maar het belangrijkste advies was vooral: zoek een sterke regie partner !!! Wellicht heeft CapGemini na vanavond hier nog wat tijd voor.

Ach. Gaan ze het volgende projectje via Sogeti doen. Bouwen en testen binnen dezelde holding...geen probleem.

Cap Gemini is eigenlijk een uitzendbureau voor IT-ers. Er lopen heel goede mensen rond, maar ook bijzonder matige. Mijn punt is: in dit geval is het bedrijf is zo goed als de source code die het uiteindelijk oplevert. Als die prut is dan heb je de klant niet goed bediend en heb je als bedrijf gefaald.

Cap Gemini had de middelen om haar medewerkers in India te controleren maar heeft dat nadrukkelijk nagelaten. De SVB bank is duidelijk niet kritisch genoeg geweest en heeft nagelaten om tijdens de bouw Cap te controleren. Toch vind ik Cap meer fout dan de SVB omdat je in mij ogen als softwareleverancier (of als leverancier in het algemeen) de plicht hebt om je klant te helpen. Cap werd ingehuurd voor een taak die de SVB zelf niet kon uitvoeren.

Ik vind het van Cap immoreel om na zo'n mislukt project toch gewoon de Euro's te houden. En ik ben er van overtuigd dat je een dergelijk systeem ook voor een tiende van de prijs kunt maken mits je een klein aantal getalenteerde mensen inhuurt.

Cap Gemini, een frans bedrijf heeft de afgelopen jaren vele duizenden medewerkers ontslagen en laat nu in lage lonen landen software ontwikkelen zonder veel toezicht. Hun onderdeel Volmac ging ook steeds goedkoper produceren en is dus beeindigd.

Klopt wat André schrijft. Ik heb zelf ook bij dit bedrijf gewerkt en merkte iedere keer weer dat marge belangrijker is dan klanttevredenheid. Er werd maar continu gehamerd op meer Rightshore naar India (is meer winst) en als je dat niet haalde werd je erop afgerekend. Er wordt daar gewerkt met flat fees dus voor een Indier betaal je als klant net zo veel als voor een Nederlander. Alleen krijg je er minder kwaliteit voor terug en en ze doen er vaak ook nog eens 3 keer zo lang over. Als klant zou ik vooraf eisen dat deze bedrijven gebruik maken van Nederlandse resources en anders kiezen voor een andere leverancier. Positief neveneffect is dat dit ook beter is voor de Nederlandse arbeidsmarkt.

Vroegah, toen alles beter was, begonnen we met een design.
Een programmastructuur diagram, zo leerde ik het op school.
Tegenwoordig plakken ze wat Post-it's en gaan aan de slag.
Hoe kan de overheid zich daar in mee laten slepen...

Ok dan.

Langere tijd (jaren) lees ik hier nu mee over mislukkende ICT projecten waarin miljoenen aan belastingeld verspild worden. Zembla was misschien de spreekwoordelijke druppel om maar eens te reageren. Het is namelijk moeilijk te begrijpen dat het gemiddelde ICT kennis niveau in Nederland zo enorm is toegenomen de afgelopen decennia (we hebben toch allemaal een smartphone?), maar dat dit soort projecten nog steeds regelmatig op een groot fiasco uitdraaien. Hebben we dan niets geleerd? Was de commissie ICT / Elias al niet tot dezelfde conclusie gekomen? Het is namelijk niet zo moeilijk om te begrijpen waar het mis gaat.

Mijn stelling: er is niet voldoende (ICT) kennis binnen de overheid om dit soort mega-projecten goed te kunnen "managen".

Voorop gesteld dat dit uiteraard puur mijn persoonlijke mening is, maar ik ben ooit in een project bij de SVB betrokken geweest en ken dus enigszins de cultuur. Als ex-Capgemini medewerker ben ik ook bekend met de cultuur daar en heb ik de "India-component" in de praktijk meegemaakt. Vanuit die achtergrond, zonder verder enige kennis van de huidige projecten bij de SVB, maar afgaande op de informatie hier en in andere media, heb ik een aardig beeld. Eigenlijk zijn er te veel zaken die ik hier zou willen noemen, dus om maar een begin te maken:

In mijn optiek kent de SVB een goede ICT organisatie en beschikken zij over betrokken medewerkers die prima weten hoe hun "bussiness" in elkaar steekt. Wat ik niet begrijp is dat het MRS project is gestart omdat de voorganger verouderd zou zijn. Hoezo is 20 jaar oud? Voor een mainframe applicatie (wat de voorganger is) is 20 jaar wat mij betreft niet oud. In het smartphone-tijdperk waarin de ontwikkelingen elkaar in rap tempo opvolgen is het misschien niet te begrijpen, maar de huidige applicatie kan nog wel even mee. Maar hier alvast het eerste probleem: de gemiddelde Nederlander denkt misschien dat deze applicatie vervangen moet worden, terwijl de experts er vast anders over denken. Dus: we hebben gedegen ICT kennis nodig om bij de SVB goed af te wegen of die vervanging nu wel nodig is.

Capgemini is een bekende speler in de ICT markt (net zoals Ordina die er ook al een keer negatief is uitgelicht door Zembla, maar volgens mij ook niet heel anders is dan de overige grote spelers). In de kern is het een commercieel bedrijf dat dus, anders dan de overheid, wil dat projecten winstgevend zijn. En als het om grote overheidsprojecten gaat komen we sowieso altijd uit bij steeds weer dezelfde bedrijven. Alleen zij kunnen een dergelijk groot project aan en zijn in staat een Europees Aanbestedingstraject te doen. Het liefst zou ik hier dus niet meer willen lezen over andere partijen die graag mee willen dingen in dit soort trajecten.

Volgens mij is het vooraf nooit de intentie van SVB (of andere overheidsinstantie) of Capgemini (of andere grote ICT speler) om een project te laten mislukken (duh). Het gaat mij te ver om te denken dat Capgemini willens en wetens miljoenen binnen wilde harken zonder een werkend product op te leveren. Ook aan de kwaliteit van Capgemini twijfel ik niet, maar het is wel van wezenlijk belang dat de SVB controleert dat er wordt opgeleverd wat er is gevraagd. En werkt het? Is het niet raar dat tijdens het project al geconstateerd wordt dat het "nooit gaat werken", maar dat er niet aan de handrem wordt getrokken? Dit hebben we al veel vaker gezien in vergelijkbare projecten, maar blijkbaar is er in dit krachtenveld nog steeds niet voldoende ICT kennis aanwezig om de trein te stoppen.

Kortom: Kijk nog eens goed of er voldoende ICT kennis aanwezig is aan de kant van de overheid om grote projecten te "managen". Vul de kennis (die er daar al is) aan met meer specialisten die inhoudelijk beter begrijpen wat er speelt in het ICT werkveld en durven in te grijpen. Dit zijn dus geen programmeurs of managers, maar juist de ervaren consultants die vaak nou net bij Capgemini zitten of voor zichzelf begonnen zijn.

In 2011/2012 gewerkt als Service Manager bij V&D BV, die per maand zo'n EUR.500.000,00 betalen aan CapGemini voor ondermaatse software en systemen, die in India geproduceerd worden!

Ook daar is door ondergetekende, die als een "whip" door de contracten van CapGemini ging (en zelfs dreigde het contract op te zeggen), meerdere malen bedreigd door (Directie) CapGemini dat men absoluut niet meer met ondergetekende wilde samenwerken en V&D is destijds gezwicht voor de kracht van CapGemini!

Er moesten voldoendes gegeven worden voor de werkzaamheden vanuit India, ondergetekende weigerde dat, waarop bepaalde bonussen voor managers binnen CapGemini op de tocht kwamen te staan! Toen is men maar druk gaan uitoefenen bij de CFO van V&D destijds, ene C.V. en de CIO van V&D destijds, P.v/d.V.

Alle documentatie hiervan heb ik uiteraard nog!

Wat een onzinrapportage van Zembla. SVB heeft de zak met geld dus zij zijn in de lead en bepalen wat er gebeurt. Cap is dus niet verantwoordelijk. Fout ligt bij de inrichting en projectmanagement van SVB. Je kunt ook scrum toepassen, enz., enz., enz.

@Rik De meeste mensen (en ook Zembla suggereert dat) denken bij dit soort verhalen dat de redenen er achter wel corruptie en dergelijke moeten zijn. Voor zover ik het heb ervaren is het vooral veel incompetentie (zowel bij opdrachtgevers als opdrachtnemers).

Die administratieve plaatsing onder de mantelovereenkomst is vrij gebruikelijk en zegt niet zo veel. De overheidspartijen (maar bedrijven doen het ook) sluiten grote contracten met zo scherp mogelijke tarieven met de dienstverleners. Daar zetten de dienstverleners dan exclusiviteit van levering tegenover. Dus zo'n partij als SVB is juridisch (volgens het contract) *verplicht* om zo'n onafhankelijke ZZP-er dan via zo'n mantelpartij in te huren. Meestal zijn er meer mantelpartijen voor elk kavel (en als dat het geval is dan is het wel zo handig om het via een andere partij te doen) maar soms kun je niet anders.

Dat wil niet zeggen dat al die partijen als Cap heilig zijn. In dit geval toont dat voetbalvoorbeeld wel aan dat ze enorme bagger hebben opgeleverd (IFSQ is een prima methode voor het meten van code-kwaliteit). Maar zodra de incompetentie aan het licht komt worden er vaak (zowel aan opdrachtgeverszijde maar ook vanuit de leveranciers) bully-tactics gebruikt om criticasters de mond te snoeren. SVB is duidelijk incompetent geweest als opdrachtgever. Maar ja, zoals meer mensen constateren: de kennis is dun gezaaid.

Die link tussen de SVB-opdrachtgever en de ZZP-er (samen in een bedrijfje) is wel foute boel. Dat is wat mij betreft een vette belangenverstrengeling.

Wil je de "waarheid" boven water halen, controleer dan de geldstromen van SVB naar Cap Gemini en vergelijk deze met de facturen. Controleer vervolgens de facturen met de onderliggende werkzaamheden die zijn gefactureerd.

Als er gefraudeerd is:
- alle gelden terugvorderen die niet onderbouwd zijn op de facturen;
- beboet de daders;
- registreer deze personen in een 'ethisch register';
- herijk de procedures van het toezicht;
- ontsla personeel oneervol dat zich heeft ingelaten met de fraude.

Zembla heeft het naar mijn mening wat tendentieus gebracht, en de werkelijkheid is wat complexer dan je in zo'n korte uitzending naar voren kunt brengen.

Wat de uitzending wel duidelijk maakt is dat er bij dit soort projecten vaak sprake is van belangentegenstelling, gebrek aan binding met het gewenste resultaat en overmatige complexiteit van watervalgedreven, monolitische systeemontwikkeling.

In mijn blog vertel ik graag hoe het anders kan, want dat het anders moet, is duidelijk: https://technology.amis.nl/2015/09/04/stap-voor-stap-telkens-verder-vooruit/

@Andre Ik heb het niet voorbij horen komen monolitisch en watervalgedreven maar ik heb even de site van Cap Gemini bekeken en daar is helemaal niets mis mee. Ze doen aan agile ontwikkeling, devops is een vanzelfsprekendheid en ook voor de clouddiensten kun je bij ze terecht. Kortom, een bedrijf wat de taal van deze tijd spreekt.

Op linked-in is er ook een reactie uit India:

https://www.linkedin.com/pulse/zembla-documentary-failed-software-project-learning-from-shrivastava

zembla-documentary-failed-software-project-learning-from-shrivastava : nogal simplistisch artikel, ofschoon illustratief voor de Indiase visie alsook voor de Nederlandse aanpak voorafgaand en corrigerend.

Capgemini is het vaakst betrokken geweest bij grote automatiserings-projecten van het Rijk die financieel uit de hand lopen. volgens onderzoek door NRC.
Capgemini werkte aan 12 van 34 dure projecten. In totaal zijn aan die projecten ongeveer 930 miljoen euro meer uitgegeven dan was begroot.

De belangen van de leverancier zijn erg groot, daar moet dus ook een onafhankelijke toezichthouder op toezien.

De India route die CAP was ingeslagen moest perse doorgevoerd en als succes verkocht, hingen reputaties vanaf, dus alle ballen op India. Zoals overal in bedrijfsleven en politiek houdt men de schijn van eigen succes overeind. Druk om toch iets te doen is dermate groot dat slechte ideeën als fantastisch verkocht worden, zoals gebruik maken van zeer matige niet communicatieve Indianen voor functioneel lastige systemen die veel eindgebruikers begrip vragen.

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

×
×