Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

'Capgemini 1-2Focus: ravioli of spaghetti?'

Capgemini heeft voor Equihold een .Net-versie gemaakt van hun sport erp-programma 1-2Focus. Equihold is vanaf het begin niet tevreden over de software en spreekt uiteindelijk over slechte spaghetticode. Dat wordt ten stelligste ontkent door Capgemini. In mijn vorige artikel, ‘Capgemini 1-2Focus: installatietest’, heb ik beschreven dat het installeren van de 1-2Focus software weliswaar mogelijk is, maar het meestal moeizaam gaat en het niet iedereen zal lukken om de software te installeren. Maar als die horde is genomen, hoe stabiel en gebruiksvriendelijk is de software dan verder?

In het contract met Capgemini en bijbehorende documenten zijn voor 1-2Focus onder andere de volgende eisen en uitgangspunten vastgelegd.
-     Het programma moet gebruiksvriendelijk zijn (be easy to deploy, be easy to upgrade).
-     De software functionaliteit moet modulair in de markt gezet kunnen worden. Een versie waarbij niet alle modules geleverd zijn, moet dus gewoon kunnen werken.
-     De software moet van hoge kwaliteit (high quality) zijn.

Bij het testen is bekeken of de software globaal voldoet aan de algemene eisen die aan software gesteld mogen worden.

De applicatie

De applicatie ziet eruit als een typische Microsoft Windows XP applicatie. Dat is te verwachten omdat het om een .Net-applicatie gaat, die met Microsoft tools gemaakt is. Er is een behoorlijke handleiding van 91 pagina's. Bovendien kun je via de frequently asked questions (faq) een bijbehorend instructiefilmpje starten, zoals bij veel erp-programma's.

Het hoofdmenu volgt grotendeels de bedoelde modulaire opbouw. De trainer krijgt de modules 'Management' voor rapporten en contacten, 'Sport' voor onder meer competitie, team(samenstelling), trainingen, agenda, wedstrijden, activiteit spelers en spelersevaluatie, 'Wedstrijden' voor onder andere video bibliotheek, actieschema ten behoeve van wedstrijdevaluatie, wedstrijden, presentatie van geselecteerde fragmenten en 'Admin' voor bijvoorbeeld het maken/aanpassen van formulieren, de back-up en rapportages.

Irriterende bugs

Je ziet meteen veel slordigheidjes als je door de menu's heen loopt. Bij het programma was Nederlands als taal ingesteld, maar op veel delen van het programma moet je met de Engelse taal werken zonder dat dit voor de hand ligt. Zo is de submodule 'Agenda' grotendeels in de Engelse taal. De submodule 'Training' is ook grotendeels in het Engels. Het aanmaken van personeelsgegevens gaat deels in het Engels. Ook zijn er wat typefouten.

Als je eenmaal met de applicatie gaat werken, dan zie veel meer foutjes. Datums kun je niet altijd rechtstreeks intypen, maar moet je geheel of gedeeltelijk aanpassen via het bekende MS de mini agenda. Als je de geboortedatum moet invullen van iemand die decennia oud is; dan ben je even bezig met scrollen.

De submodule 'Agenda' laat je niet meteen een team selecteren waarvan je een activiteitenoverzicht wilt hebben. Je moet eerst de optie 'Training Selectie' afvinken en weer aanvinken, voordat je één of meerdere teams kunt selecteren.

Bij de submodule 'Spelersactiviteit' kun je aangeven dat een speler absent is vanwege ziekte. Maar je moet daarvoor een reden opgeven voordat dit opgeslagen kan worden. Als je niet weet waarom iemand ziek is, verzin dan maar wat.

De 'Bibliotheek' met standaard trainingssessies is leeg of niet benaderbaar. Dat was eerder niet zo.

Irritant is ook dat sommige foutmeldingen worden herhaald en sommige foutmeldingen ten onrechte worden getoond. Veel van die fouten staan in clusters. Bijvoorbeeld, het type actie (event) van een speler kan worden gedefinieerd via het 'Actieschema' (in de applicatie Event schema). Wijzig je een actietype in het actieschema, dan krijg je vier keer achter elkaar dezelfde foutmelding 'Opslaan van het event is mislukt', ook als achteraf blijkt dat de actieomschrijving wel is vastgelegd. De foutmelding moet je vier keer wegklikken. Één keer waarschuwen is voldoende zou je zeggen en uiteraard alleen als het echt nodig is. Bij het wijzigen van de voor- of achtergrondkleur in het actieschema krijg je dezelfde foutmelding en ook vier maal. Dat geldt ook voor het koppelen van een tegenactie (zoals storen) aan een actie. Ook het koppelen van een bepaalde standaardactie aan een hot key geeft ten onrechte weer vier keer de bekende foutmeldingen.

Het opslaan van een mutatie kan de ene keer via een te verschijnen opslaan button en de andere keer alleen via de menubalk. Dat is allemaal niet bepaald bevorderlijk voor de acceptatie van de software, maar het zijn nog geen echte afknappers. Die zijn er helaas wel.

Blocking bugs

De 'Rapportageontwerper' (Report Builder in de applicatie) van de managementmodule start niet op; meteen een blocking bug.

Bij jeugdvoetbal zijn er afwijkingen ten opzicht van de normale regels voor volwassenen, bijvoorbeeld qua aantal spelers (maximum en minimum), aantal te wisselen spelers en de speeltijd. Voor een oefenwedstrijd moet je vrijheid krijgen. En dus moet je de tijd zelf kunnen instellen. Maar dat lukt niet.

Als je een oefenpotje wilt agenderen, dan hoef je niet voldoende spelers ter beschikking te hebben, zoals bij een competitiewedstrijd, maar dat lukt niet.

Spelanalyse van wedstrijden en oefeningen is in de topsport van groot belang. Dat betekent dat acties aan videofragmenten gekoppeld worden, bij voetbal van aftrap, doelpunt of een rode kaart van spelers. Die acties worden in het actieschema vastgelegd. Je hebt standaard acties en lege acties die men zelf kan definiëren, de 'Eigen acties'. Ik heb bijvoorbeeld de 'Swalbe' toegevoegd. Dit lukt niet bij elke installatie. Toen ik de volgende eigen actie toevoegde, ging de veldwaarde terug naar de oorspronkelijke staat. Toevallig kwam ik er achter dat als ik eerst de voorgrondkleur aanpaste, ik daarna alsnog een extra 'Eigen actie' kon definiëren voor 'Op de voet trappen'. Ik wilde daarna nog eens op die manier 'Tijdrekken' toevoegen, maar dat lukte niet meer. Dus werking van deze bug is niet te voorspellen.

De actie die je aan een spelmoment wilt koppelen kun je aanklikken op een Notatiebord (in de applicatie Notation board) onder het venster voor het afspelen van de video. Dat is handig voor spelanalyse. En je kunt dit uiteraard ook doen met hotkeys die je zelf kunt definiëren. Maar hot keys aanpassen voor een 'Eigen actie', kan weer niet, net als nog een aantal andere opties ook niet bij zo'n actie aangepast kunnen worden.

De acties die je koppelt aan een speelmoment kunnen ook aan de plek van het speelveld worden gekoppeld. Ook dat is handig voor spelanalyse. Daarvoor wordt er een schema van het speelveld getoond. In de voetbalversie wordt echter een hockeyveld getoond en die heeft een duidelijk andere indeling dan een voetbalveld.

Voor de liefhebbers, de filmpjes van de genoemde bugs zijn te zien op de website van Capclaim, de juridische entiteit die strijd voert tegen Capgemini.

Voor de gebruikers waren niet alleen de bugs een groot probleem, de leading costumers hebben moeten ervaren dat sommige bugs na een update weer verschenen. Of dit komt door slecht versiebeheer van de source of door de complexiteit van spaghetticode, dat weet ik niet.  Het zou niet mogen voorkomen.

Eindconclusie vanuit de gebruiker gezien

Versie 9 is de beste versie die door Capgemini is gemaakt. Toch blijkt het programma in de praktijk niet geschikt te zijn door vele hinderlijke fouten en doordat belangrijke functionaliteit niet beschikbaar is door technische fouten. Die fouten zijn vooral in de submodule  'Actieschema' te vinden. Zoveel ernstige fouten bij elkaar kun je als leverancier bij het testen onmogelijk over het hoofd hebben gezien. Capgemini heeft dus niet volgens afspraak de technische tests en functionele tests uitgevoerd. Het had moeten gebeuren en daar is ook voor betaald. De software is slechter dan alle Bèta software die ik in de loop der jaren heb getest. Versie 9 komt over als een Alfa-release, om aan een klant te laten zien wat de software kan gaan worden. Het is gewoon absurd dat Capgemini bij release 9 nog steeds geen stabiele en volledig functionele software heeft weten te bouwen.

Jaap van Belkum, zzp'er

ICT Faalindustrie?

Diverse experts hebben  inzake het 1-2Fcousproject zich reeds eerder negatief uitgelaten over de kwaliteit van de code, de toepassing van Rational Unified Processing (RUP) in het ontwikkeltraject en het door Capgemini gevoerde project- en kwaliteitsmanagement en de bijbehorende transparantie van de communicatie. Achteraf is de mislukking goed te verklaren; een contract dat op twee tegenstrijdige gedachten stoelde, slecht projectmanagement, slecht kwaliteitsmanagement, slechte en verhullende communicatie, slechte invulling van de zorg naar de klant. Het eindresultaat is kreupele software waarmee niet gewerkt kan worden. En Capgemini eist nog meer geld voordat zij de bugs oplossen.; in die zin mag 1-2Focus crippleware genoemd worden.

Is dit een voorbeeld van falen, nee het gaat verder dan dat. Zo complex was de opdracht niet voor een bedrijf als Capgemini. Capgemini had meer dan voldoende expertise, capaciteit en ervaring in huis. Natuurlijk, Capgemini had nog heel weinig ervaring met offshoring, maar vanuit projectmanagement hadden die risico's adequaat gedekt kunnen worden.

Helaas hebben ze de problemen naar het onervaren en kleine Equihold doorgeschoven. Tenslotte, wat wist Equihold van Rup en offshoring en hoeveel mankracht hadden zij om Capgemini te controleren? Dat was te weinig en daar is gebruik van gemaakt. De contractuele afspraken met betrekking tot Rup, softwarearchitectuur, kwaliteit, werkverdeling en dergelijke zijn niet of grotendeels niet nagekomen. Capgemini heeft de klant een lange tijd laten betalen voor producten en diensten die ze maar voor een deel hebben geleverd. Het is een keten van fouten.

Het hoogste management van Capgemini zegt dat de geleverde kwaliteit voldoet aan de norm van gemiddelde software, terwijl er aantoonbaar nog steeds blocking bugs inzitten. Misschien moeten zij zich eens afvragen, What business am I in? Het huidige verdienmodel van Capgemini werkt nog wel, maar hoe lang nog na al die negatieve publiciteit als je kampioen  mislukte projecten bent? Om je bedrijf te kunnen continueren, heb je goodwill nodig. Een goede naam kun je niet kopen, maar moet je verdienen en blijven verdienen, zoals generaties van Capgemini Sogeti-medewerkers dat eerder hebben gedaan.

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

 

Reacties

Interessant artikel Jaap.
Cap is dus een meester in .net niet applicaties.

Dank je Johan. Je gaf een wel heel bondige samenvatting. Triest genoeg klopt het.

Requirement: "Het programma moet gebruiksvriendelijk zijn (be easy to deploy, be easy to upgrade)."
Als je zo'n requirement leest moet de reflex zijn:
Hoe easy to deploy?
Hoe easy to upgrade?
Als je dit niet kwantitatief en meetbaar vastlegt, dan krijg je altijd problemen.

Requirement: "De software moet van hoge kwaliteit (high quality) zijn."
Als je zo'n requirement leest moet de reflex zijn:
Hoe hoge kwaliteit?
Als "Het hoogste management van Capgemini zegt dat de geleverde kwaliteit voldoet aan de norm van gemiddelde software." is dit al een blijk van niet voldoen aan het requirement. "Normale kwaliteit" is immers niet "hoge kwaliteit".
Maar als je dit niet kwantitatief en meetbaar vastlegt, dan krijg je altijd problemen.

Zoals zo vaak zijn niet kwantitatief en meetbaar vastgelegde requirements weer de oorzaak waardoor de Caps van deze wereld weg denken te kunnen komen met software die niet naar behoren werkt (reflex: definieer 'naar behoren').

Men zou zo langzamerhand toch beter moeten weten.

Beste lezers en lezeressen, het stukje bij "ICT Faalindustrie?" dat in een apart kader staat, is ook door mij geschreven. "De inhoud vertegenwoordigt dus niet het redactionele gedachtegoed van Computable." Blame it on me.

@ Jaap: uw artikel ICT-Faalindustrie ook zo goed van toepassing voor andere dan overheidsopdrachten, namelijk bij meerdere ERP projecten, waar naast de basisproblemen die reeds in de basispakketten aanwezig zijn, het nodige add-on en nog meer maatwerk met nog meer problemen gecreerd worden. Omdat het in samenspraak is met de gebruikers worden die dan als schuldige voorgesteld. Ik ben zo vrij geweest een link naar uw artikel op te nemen in mijn blog, waarin ook heel wat minder fraaie aspecten aan bod komen.

@Niels, je hebt groot gelijk als je zegt dat je SMART moet definiëren. In de juridische documenten (raamcontract, raamcontractbijlagen en formele opdrachten) en het Vision document wordt vooral verwezen naar te behalen doelen en industriestandaarden (ook naar de Quality Assurance van Capgemini en naar de ontwikkelmethode RUP). Maar dat is nog steeds wel kadergevend en bindend.
De eisen worden verder uitgewerkt in algemene RUP documenten zoals het Software Architecture Document, Software Development Plan. Uiteindelijk wordt de werking en het uiterlijk van de applicatie per onderdeel nauwkeurig omschreven in de schriftelijke (e-mail)opdrachten, Use Cases en bijbehorende Print Screens. Bovendien had Capgemini ook de oude VB applicatie als voorbeeld. Wat in de oude VB applicatie werkt, dat moet nog steeds in de .Net versie werken, tenzij anders is afgesproken.
Capgemini wist dus in dit geval heel goed wat de bedoeling was en kan daar niet onderuit.

De Frontoffice van Capgemini moest de Backoffice adequaat op de hoogte houden van de requirements. Of dit goed is gegaan, dat mag natuurlijk betwijfeld worden. De RUP documentatie werd al snel een puinhoop en het contact tussen Equihold en de Backoffice werd al net zo snel gesmoord vanwege zogenaamde technische problemen. Toen er een Liaison Officer uit India kwam, was het kwaad al geschied omdat de basis van de applicatie spaghetticode was, maar dat wist men toen nog niet bij Equihold.

Wellicht is het goed/nuttig om op drie zaken te wijzen:

1.
Het upgraden van een oude, werkende applicatie van Visual Basic naar .Net is een puur technische klus, redelijk vergelijkbaar met het Y2K werk waar de "India route" groot mee is geworden. Er is een bestaande applicatie die dient als referentiekader/scherprechter bij de beoordeling van de werking van de upgrade dus materiekennis is niet nodig.

2.
Ik vermoed sterk dat Equihold niet de discipline heeft opgebracht om een puur technische upgrade te doen. Equihold wilde natuurlijk ook functioneel verder en is dus ook met functionele veranderingen aangekomen. De fout blijft dan overigens bij Capgemini liggen want zij hebben de expertise en de daaraan verbonden zorgplicht. Equihold is een klein clubje dat een grote ICT broer zocht.

3.
Dat het Capgemini product niet werkbaar is staat als een paal boven water. Zie de Zembla uitzending. Het is fascinerend dat Capgemini op weg naar de rechtbank doet alsof haar neus bloedt wanneer de bewijzen op tafel liggen. Dat zien we elders echter ook. Zo zaten de e-mails die Zembla liet zien van Capgemini-managers die Equihold afpersten om goede beoordelingen voor de programmeurs te verkrijgen ook in het juridische dossier. Dat weerhoudt Capgemini er echter niet van om naar de rechter toe te schermen met de door Equihold afgegeven goede rapportcijfers.

De interessante vraag blijft natuurlijk hoe het gaat bij overheidsorganisaties als SVB. Worden die ook gechanteerd? Bij de SVB was dat vermoedelijk niet nodig omdat ze de twee programmabazen al (in)direct op de loonlijst hadden. De directe schade voor Equihold was "slechts" enkele miljoenen; die voor de belastingbetaler bij UWV en SVB loopt in de honderden miljoenen.

@Rene, Equihold had een schade van 'slechts' enkele miljoenen en een faillissement aan overgehouden. Dit heeft eigenaar Kenneth Berkleef op meerdere manieren persoonlijk geraakt en hier zijn lessen uit getrokken. Dit zal hem de volgende keer niet nogmaals overkomen.

Een SVB gaat (helaas?) niet failliet en van enige persoonlijke impact lijkt ook geen sprake te zijn. 'Lessons learnt' lijkt hier niet van toepassing te zijn en is het wachten op een volgend schandaal met belasting geld.
Het aantrekken van regels, BIT, registratie als betrouwbaar, nog meer controles, zijn hier niet het antwoord op. Wat wel?

Jaap, kan je 1 2Focus spaghetticode SMART omschrijven?

@Jos De Clercq, je reactie klopt helemaal. Zelfs als het gekozen standaard ERP-pakket wel een goede technische basis is, dan nog kan het goed misgaan. Vaak komt het zover omdat het pakket veel te veel biedt, of te veel aangepast moet worden (men wil de oude functionaliteit en look and feel behouden) en/of omdat het pakket beter past bij het gebruik in een andere branche (een vrindje van de golfbaan “was er anders wel heel tevreden over”). Men komt er snel achter dat men eigenlijk een ander pakket had moeten hebben, maar men blijft doorgaan. Dan gaat men te veel maatwerk maken en komt men in de problemen bij bijvoorbeeld de updates. Uiteindelijk komt men er achteraf achter dat alleen maatwerk wellicht beter was geweest, of het pragmatisch aanpassen van de bedrijfsprocessen aan de mogelijkheden van een standaard ERP-pakket voor de branche.

Maar, hier is geen standaard ERP-pakket gebruikt; en dan nog kan het misgaan. Ben benieuwd welke parallellen jij verder gaat trekken.

@ martin, Spaghetticode vertoont een ongeremd gebruik van GOTO-statements. Prof. Dijkstra suggereerde het GOTO-statement helemaal niet meer te gebruiken. Jackson beval het aan voor twee situaties: programma-inversie en backtracking; verder niet gebruiken.
Je kunt dus van spaghetticode spreken wanneer er GOTO's in voorkomen - dan hoor je bij de "preciezen" - of wanneer er GOTO's worden gebruikt voor andere doeleinden dan programma-inversie en backtracking - dan hoor je bij de "rekkelijken".

Overigens heb ik GOTO-less programma's gezien waar geen touw aan vast te knopen was. Geen of weinig GOTO's zegt nog niet alles over de kwaliteit (juistheid, onderhoudbaarheid) van een programma.

@Rene, ben het met je eens. Een paar aanvullingen van mij.

1 De productie van de eerste 4 releases van 1-2Focus hadden een technische klus moeten zijn, waarbij ook de architectuur vervangen werd door een Three Tier architectuur. Dus wel echt programmeerwerk (en niet alleen de source door een tool halen en gaan debuggen). Toch bleek dat er materiekennis nodig is, die in India onvoldoende aanwezig was. Zo ontstonden er functionele fouten, wat niet werd voorkomen door slecht project management en testen vanuit Capgemini Nederland.

2 De technische upgrade en de functionele aanvulling hadden na elkaar moeten plaatsvinden. In release 5 had de oude functionaliteit compleet moeten zijn verwerkt, plus de eerste nieuwe functionaliteit. Die release had ook op de markt gebracht moeten kunnen worden om de oude VB versie te kunnen gaan vervangen (die release had geld moeten gaan opbrengen). Helaas zaten er nog steeds heel veel cruciale fouten in en was de Three Tier architectuur een zooitje. Capgemini had inzicht in die fouten, zoals te zien is in onder meer het lange tijd achtergehouden Capgemini rapport uit 2006. Capgemini had toen Equihold goed moeten inlichten over de problemen en nader onderzoek moeten doen. Dan had Equihold een beslissing kunnen nemen op basis van de juiste informatie. Dat heeft Capgemini nagelaten.

3 Het klopt dat Capgemini Equihold heeft gemanipuleerd. En als ik kijk naar wat jij zo al gepubliceerd hebt over Capgemini, dat het ieder geval in Nederland een onderdeel van hun modus operandi is geworden.

Waarom reageert de SVB anders dan Kenneth Berkleef? Waarschijnlijk omdat het niet om hun eigen geld gaat en de direct betrokkenen allemaal zo hun redenen hebben om de kostbare grote fouten achter zich te laten (zonder er van te hebben geleerd). En steeds meer mensen worden betrokken door de doofpotconstructie, ook politici. Men wil elkaars handen wassen, maar maakt alleen meer vuile handen. En de politieke meerderheid pikt het, zoals ik al eerder op de Computable heb aangegeven. Daar maken de grote ICT-bedrijven en niet alleen Capgemini, gebruik van.

@Karel
Het GOTO-statement is uit de periode dat BASIC, FORTRAN en COBOL de belangrijkste talen waren. Nu, in het web- / .NET- / J2EE- / Swift-tijdperk, zijn de gebruikte talen een afgeleide van C++, waar GOTO's misschien wel mogelijk zijn, maar tegelijk zeer ongebruikelijk zijn.

Maar, gelukkig, een slechte programmeur (of een goede die haastwerk af moet leveren) heeft helemaal geen GOTO's nodig om spaghetticode op te leveren!

Een goed programma kun je onder andere herkennen aan structuur, eenvoud en leesbaarheid, en de code komt overeen met het ontwerp. Dat maakt het onderhoudbaar.

@Kurt, gelijk en gelijk. Wat dan wel? Een goede vraag, al weet ik ook niet precies het antwoord. Maar een juiste vraag is een goed begin. Naast foute opdrachtgevers, heb je ook machtige foute opdrachtnemers, dat zijn vaak 4-5 per sector, meestal in een bijna-monopolypositie.
Misschien zouden de politieke partijen een massaal door ICT'ers ondertekende verklaring (petitie of handvest) moeten krijgen. Dit als aanvulling op hun eigen Eindrapport tijdelijke commissie ICT-projecten. In de verklaring zou (nogmaals) duidelijk gemaakt moeten worden dat er onnodig, heel veel geld verspild wordt via ICT-gerelateerde projecten en waarom dat zo vaak kan gebeuren. M.i. kan hiervoor een goede basis zijn, een samenvatting van wat Rene Veldwijk zoal geschreven heeft over ICT en overheid.
Maar misschien zijn er andere en betere ideeën om door te dringen bij de dames en heren politici.

@Martin, waarom wordt de code van Capgemini spaghetticode genoemd? De code is slecht leesbaar. De SQMI en Ndepend metingen zijn hierin nogal duidelijk.
– Een release waarbij 63 % van de broncode regels meer dan één keer voorkomt (lastig bij het bijwerken).
– Broncode waarbij 26 % van de routines uit eenheden van meer dan 50 regels bestaat (algemeen wordt 30 als maximum gezien voor leesbaarheid).
– Broncode 54,8 % van de regels langer dan 120 posities is, 1,0% zelfs meer dan 160 posities (algemeen wordt 80 als maximum gezien voor leesbaarheid).
– Broncode waarvan 10 % van de datasets untyped zijn (vul maar wat in en zie maar wat er van terecht komt).
– Meer dan de 17% van de regels had een obstakel voor onderhoud (F-rating IfSQ Level-2: tussen 100 en de 200 obstakels voor onderhoud per 1000 regels code). Net als bij voetbal is een F-je nog niet van professioneel niveau.
– Bovendien zijn de software modules gemaakt met een Two Tier architectuur die via een trucje als de afgesproken Three Tier architectuur modules werd aangeboden. Tier één is Tier één plus Tier twee. Daarbij is de tweede laag is alleen doorgeefluik voor laag drie.

Het gevolg was een broncode waarvan diverse deskundigen hebben gezegd dat ze 5% van de routines als zeer complex beschouwden. Kan dergelijke software nog wel goed functioneren laat staan goed onderhouden worden? Het lukt Capgemini duidelijk niet, zoals iedereen op de website van capclaim ook zelf kan zien.
De deskundigen uit de Zembla gingen nog verder. Zo wordt gesteld dat de software niet geschikt is als basis voor verdere ontwikkeling; het verhelpen van de fouten zou meer dan het herschrijven van de software!
Dat Capgemini de kwaliteit van de geleverde software als marktgemiddeld zien, dat zegt meer over hen dan over de markt. Waarom ging het nog goed bij Brunel en niet meer bij Capgemini?

De definitie zoals hier gegeven wordt van onderhoudbaarheid: Structuur, eenvoud en leesbaarheid, is precies wat Software Improvement Group (SIG) blijkbaar toch heeft teruggevonden, want zij classificeren de software als ‘gemiddeld onderhoudbaar’ toen ze namens Cap de software hebben onderzocht. Nu is ‘gemiddeld onderhoudbaar’ niet iets om trots op te zijn als Cap voor nieuwe software waarbij de benchmark van SIG waarschijnlijk uit kreupele software bestaat. Tenslotte, flitsende software zal minder vaak aan SIG worden aangeboden dan ‘moeilijke’ gevallen.

SIG een gerenommeerde organisatie op dit vlak en heeft namens de SVB de CAP software onderzocht. Hun oordeel was toen aanzienlijk negatiever. Hoe komt het dan dat ze in dit geval tot ‘gemiddeld onderhoudbaar’ zijn gekomen en niet tot spaghetti? Ze zullen sig toch niet hebben laten beïnvloeden door de opdrachtgever?

@KurtdeKoning Grappig, ik zat er net naar te zoeken, de SIG. Herinnerde me dat zij de 1-2-Focus applicatie onderzocht hadden. Ik ben toch heel benieuwd hoe dit gaat aflopen voor de rechter, ik denk dat het uiteindelijk zal uitdraaien op gesteggel over contracten, kleine lettertjes en verantwoordelijkheden. En niet of de software werkt of de code eventueel spaghetti is. Want inderdaad, Jaap van Belkum heeft een negatieve oordeel over de kwaliteit van de software, de Software Improvement Group komt tot een heel ander oordeel. De SIG is een bedrijf met een niet kinderachtige bemanning. Wat zou een rechter daarmee moeten?

@ Karel van Zanten, over foutief gebruik van GOTO statements heb ik niks gelezen in de SQMI en Ndepend metingen (zou binnen C# kunnen en die taal is gebruikt). Maar zoals Frank Heikens zegt, “een slechte programmeur (of een goede die haastwerk af moet leveren) heeft helemaal geen GOTO's nodig om spaghetticode op te leveren”. Jezelf en andere programmeurs het leven moeilijk maken kan ook zonder (al te veel) GOTO's.

De twee laatste zinnen van Franks commentaar geven het heel goed aan: “Een goed programma kun je onder andere herkennen aan structuur, eenvoud en leesbaarheid, en de code komt overeen met het ontwerp. Dat maakt het onderhoudbaar.“. Bijvoorbeeld 46% van de classes bij 1-2Focus hadden meer dan 500 regels code en dat is behoorlijk complex.

Tja, best link van een software leverancier om bij dergelijke bagger software te zeggen "dit is onze standaard kwaliteit". Weet je gelijk waar je aan toe bent... Wisten we eigenlijk al als je de pers over de overheids ICT faalprojecten een beetje bijgehouden hebt. Maar blijkt wonderlijk genoeg toch geen belemmering te zijn om gewoon nieuwe projecten binnen te halen.

En wat betreft de non-smart kwalificaties "easy to deploy" en "easy to upgrade": normaliter is dat niet nauwkeurig genoeg, tenzij je als leverancier op deze aspecten zo miskleunt dat het ineens wel voldoende gespecificeerd is...

Ik ben wel heel benieuwd naar de uitkomst van dit verhaal.

@Kurt, SIG was in een eerdere zaak inderdaad nogal kritisch over Capgemini. Ze zijn nu eigenlijk ook niet erg tevreden over Capgemini, maar dat moet je tussen de regels door lezen. SIG was in wezen het niet oneens met SQMI. Ook SIG stelt bijvoorbeeld dat het 99% zeker is dat er tussen de 96 en 318 obstakels zijn per 1000 regels code. En ook SIG stelt dat 5% van de C#-code erg complex is.

Maar wie betaalt, die bepaalt de opdrachtformulering en gebruikte ijkschaal. SIG heeft het amper over fouten, maar over onderhoudbaarheid (één van de kwaliteitsaspecten). Hierbij is 1-2Focus vergeleken met gemiddelde software (incluis slecht onderhoudbare legacy) en zou dan op een aantal gebieden marktgemiddeld zijn. Maar ja, als ik een gloednieuw huis laat bouwen of koop en het huis heeft in nieuwstaat de kwaliteit van een gemiddeld huis, dan is er toch wel wat aan de hand zou je zeggen.
Zo heeft SIG het ook niet over de fake Three Tier architectuur bij 1-2Focus. De belangrijkste reden voor de keuze van een echte Three Tier architectuur, is een betere onderhoudbaarheid van de applicatie en daarmee een hogere kwaliteit bij lagere onderhoudskosten. En daarover was een overeenkomst gesloten

Capgemini zegt dat je de cijfers ook anders kan bekijken en dat je je mag afvragen waarom juist de experts van Equihold tot bepaalde conclusies zijn gekomen. Theoretisch gezien hoeft de conclusie van SQMI niet te kloppen (en andere FUD).
Ja, theoretisch hoeft niet elke onnodig complexe regel code tot een fout te leiden en hoeft een fout in de code ook niet te leiden tot een fout in de werking. Dat is de reden dat ik ook nog eens gekeken heb of de bugs bij 1-2Focus reproduceerbaar zijn en dat zijn ze, stuk voor stuk en niet alleen theoretisch. En Capgemini had die bugs bij het testen ook moeten opmerken.

Zoveel mensen zoveel meningen, en als wat geld heb, dan koop je er wel wat meningen bij. Al dat getier met percentables over goto's en een soort boolean algebra waarbij 2 + 1 = 2.. En hoeveel is dan C++, alsof dat er wat toe doet in de common business oriented langage. Richt zich op geld blijkbaar en van Gordon Ramsay's methoden is ook niet iedereen fan. Daarna kijken we rijdende rechter die er straks geen bal van snapt en daar zult u het mee moeten doen.

@Louis Kossen, zoals ik Kurt al heb aangegeven, gaat het niet om een echt verschil van mening tussen SIG en SQMI. SIG heeft de IfSQ meting uit het oorspronkelijke SQMI report bekrachtigd. Er wordt om de resultaten van Ndpend meting heengelopen. Het is vooral een kwestie van niet reageren, niet rechtstreeks ingaan op argumenten.

Wat zou een rechter daarmee moeten? De rechter zal wel een deskundige hebben ingeschakeld om de vele ICT-argumenten te wegen om de juridische waarde daarvan te kunnen bepalen.
Maar de rechter zou als de rijdende rechter eens zelf kunnen gaan kijken naar de werking van 1-2Focus. Hoeft deze niet eens voor te gaan rijden. Een demonstratie van 1-2Focus, zou een destructie van Capgemini zijn.

@Felix, ik ben wat positiever over de kans dat de rechter de zaak juridisch adequaat kan beoordelen. De centrale stukken voor de rechtbank zijn door juristen opgesteld en het aantal verwijzingen naar de code is beperkt. En de rechtbank kan een deskundige inhuren; ze hebben wel vaker de inbreng van een of meer deskundigen nodig. Die deskundige(n) moet(en) de juiste deskundigheid hebben en neutraal zijn. Verder moet de rechter, in overleg met de deskundige, de juiste adviesopdracht meegeven.

@Jaap
Adviesopdracht?

Dat klinkt alsof er voorgesorteerd wordt op mediation, niet echt een duidelijke uitspraak en de Pyrrhus overwinning lijkt opeens aan de horizon op te komen. Daarmee komt dus de gewetensvraag naar boven wie nu uiteindelijk wie chanteert, vanuit alle analyses krijg ik de indruk dat de schuldvraag nog niet zo makkelijk te beantwoorden is en de eis betreffende vermeende winstderving ronduit exorbitant is.

@Ewout, waarom opeens wel mediation na al die keren / jaren dat dit niet acceptabel / mogelijk was. Capgemini wilde niet samen met Equihold kijken naar wat er mis is gegaan. Dat had een opmaat naar mediation kunnen zijn. Ik heb wel een idee waarom; Rene zal wel eens hetzelfde idee hebben.
Capgemini stelde juist dat er eerst circa driekwart miljoen aan (ingehouden) betalingen en rente betaald moet worden voordat er over het oplossen van de bugs gesproken kon worden (wat overigens niet meer ter zake doen is). Dat lijkt me geen goede basis voor mediation. Klinkt eerder naar Ransomeware.

Adviesopdrachten van de rechtbank voor deskundigen op het gebied van software-ontwikkeling en winstderving, acht ik wel mogelijk. Bij het laatste alleen nadat de rechter besloten heeft dat er door Capgemini een onrechtmatige daad is gepleegd; wat de laatste uiteraard ontkent.

Komt nog eens bij dat de software complexiteit klinkt alsof het een afstudeerproject van een handjevol informaticastudenten zou kunnen zijn maar de benchmarks aantonen dat zelfs dat niveau nog niet wordt gehaald.

@Jaap
Gezien je opmerking dat eerder al een poging tot mediation is gedaan neem ik aan dat door Equihold een ingebrekestelling is opgesteld waarin helder en specifiek alle geconstateerde tekortkomingen zijn opgesomd. Dit uiteraard op basis van een objectieve beoordeling van alle vooraf opgestelde criteria aangaande de kwaliteit.

Het Barbertje moet hangen aangaande de parallellen die telkens getrokken worden naar de maatschappelijke verontwaardiging over verspillingen van belastinggeld met ICT projecten bij de overheid is tenslotte een vorm van emotionele chantage. Het is niet mijn intentie om als advocaat van de duivel op te treden maar ondertussen leren ervaringen dat er sprake is van een systemische misvatting aangaande ICT.

Rene heeft het over 'ontzorgen' wat natuurlijk wel gekaderd moet worden, het uitvoerig stil blijven staan bij de onderhoudbaarheid van de code is namelijk irrelevant als je precies dat deel van de bedrijfsvoering uitbesteed hebt. Equihold ging met haaien zwemmen en moest zelf gehaaid genoeg zijn om tekortkomingen in de kennis aan te vullen. Afname van vlees bij dezelfde slager leidt tot een voor de hand liggend gezegde.

@Ewout, er is onder meer een ingebrekestelling ingediend. Er zijn diverse soorten gebreken geconstateerd. Het gaat onder meer om fouten op het gebied van de uitvoering van RUP, software architectuur, juistheid van de code, onderhoudbaarheid van de software en informatievoorziening/-plicht (deels werkzaamheden die ten onrechte niet zijn gedaan, deels werkzaamheden die verkeerd zijn uitgevoerd). Zijn de lijstjes compleet? Nee, want het kost te veel tijd om dat allemaal volledig uit te zoeken. Bijvoorbeeld de ene bug kan zich bijvoorbeeld achter de ander verschuilen. Dan moet je de grotendeels slecht leesbare code geheel gaan uitspitten. Er zijn zo'n 320.000 regels aan code, die veelal te lang zijn om goed leesbaar te zijn. Ga er maar aanstaan.

Maar je hoeft volgens de juristen ook niet alles 100% te documenteren; het beeld moet voor de rechter duidelijk zijn. Op Amerikaanse toestanden, met dossiers van meters hoog, zit niemand te wachten. Naar mijn mening heeft Equihold een goed overzicht geleverd, veel nauwkeuriger dan Capgemini. Wil de rechter meer materiaal, dan kan die dat krijgen.

Ten aanzien van de onderhoudbaarheid. Het is niet zo dat het onderhoud voor een bepaald bedrag is uitbesteed aan Capgemini. Dan zouden de fouten in de code en de slechte onderhoudbaarheid ten koste gaan Capgemini. Er was alleen een uurtje factuurtje contract voor de bouw. Equihold betaalde voor het verhelpen van de codefouten.

@Johan, volgens SIG kan per release 1/4 tot 1/3 deel van de code er uitgesloopt worden wegens duplicatie.

Als mij wordt gevraagd software te reviewen wil ik in eerste instantie de code niet eens zien.
Geef met eerst het design.

Als je het design reviewt, vind je al zoveel inconsistenties dat de code toch moet worden aangepast (om het vriendelijk te zeggen). Reviewen van de code voordat het design acceptabel is bevonden, is dan ook een zinloze tijdverspilling.

Het enige probleem is dat er meestal geen design is, omdat veel softwarici lijken te denken dat je de code zo wel kan intypen.

Veel documenten produceren à la RUP levert veel gespendeerde uren op, maar zegt niets over de kwaliteit van het design. Onlangs kreeg ik een design document van 47 pagina's voor communicatie tussen twee apparaten. Absoluut onleesbaar, en door de vele cut-and-paste inconsistent in zichzelf, en nog inconsistenter met de design spec van de leverancier van een van de twee apparaten. Ik kon het document van 47 pagina’s samenvatten in een diagram op één A4-tje. Aan de hand van dit diagram is de software verder ontworpen, en het werkte vervolgens in één keer.
Als je software ontwerpt-en-reviewt totdat met erover tevreden is, en vervolgens codeert-en-reviewt totdat men tevreden is, dan is mijn ervaring dat de testers niets meer vinden. Maar waar gebeurt dat nog?

Ik las onlangs dat in de nucleaire en medische industrie software niet eens gecodeerd mag worden. Het moet in modellen worden ontworpen, vanwaaruit vervolgens de code wordt gegenereerd. Dit om zeker te zijn dat de documentatie consistent is en blijft met de code.

Als simpele regel voor de kwaliteit van de design documentatie stel ik altijd voor: "Als iemand een jaar later het systeem moet aanpassen (of reviewen), dan helpt de documentatie ons binnen 1 dag 'up-and-running" te zijn."

Wat betreft RUP: dit behandelt de performance requirements (-ilities zoals usability, availability, reliability, security, etc) als ‘supplemantary requirements’, die er ook nog bij horen, terwijl de performance requirements eigenlijk de essentie van het ontwikkelproject zijn.

De functionele requirements zijn alleen maar interessant om de scope van het project aan te geven. De functies worden immers allang door de gebruikers uitgevoerd. De enige reden waarom we een software ontwikkeling plegen, is om de gebruikers dat wat ze al doen, sneller, prettiger, betrouwbaarder, en dergelijke te doen uitvoeren. En RUP noemt dit de ‘bijkomende’ requirements (“O Ja, die moeten we ook nog opschrijven”).
De belangrijkste requirements zijn dus deze performance verbeteringen, die we altijd kwantitatief kunnen bepalen.
Voorbeeld: Nu kost het een gebruiker 1 uur om iets uit te zoeken, en met het nieuwe systeem kost het 15 sec. Daar kun je naar ontwerpen, en je kunt meten of het requirement is gehaald of niet. Als de essentiële requirements op deze wijze zijn opgesteld, dan is het eenvoudig om te bepalen of is geleverd of niet.

@Niels, wat je zegt, kan tegenwoordig bij veel software projecten toegepast worden. Met 4GL tools inclusief code generators kan je er voor zorgen dat documentatie consistent is en blijft met de code, mist op de juiste wijze toegepast. Duplicatie van de code, en dergelijke, hoeven dan geen probleem te zijn.

In de zaak 1-2Focus ligt het anders. Niet alleen is het project 10 jaar geleden gestart, maar er is destijds gekozen voor een vergaande uitbesteding. De relatie tussen Capgemini en Equihold was toen nog gebaseerd op vertrouwen. Equihold zorgde voor de functionele specs, controleerde de Use Cases, deed de acceptatietests en nog wat zaken met de markt. De rest was voor Capgemini. Het was dus absoluut niet de bedoeling dat Equihold de technische en alle functionele tests zou uitvoeren, noch dat zij voor quality assurance / quality control zouden zorgen. En zo dat had ook kunnen functioneren. (Ik wil de niet de gehele industrie afbranden alleen omdat bedrijven zoals Capgemini Nederland in de fout gaan. Eerlijke uitbesteding is mogelijk.)

Het Rightshoring concept van Capgemini leverde een black box op, waar in de loop van de tijd steeds minder controle- en stuurinformatie uit kwam, omdat Capgemini technische problemen had met de Rational tool environment suite en met de verbindingen met Nederland. (Nee, dat geloof ik ook niet.) De managementrapportages vanuit Capgemini waren misleidend. Ze gaven alleen heel precies aan hoeveel er betaald moest worden. Equihold kreeg niet de kans om te zien welke documentatie er was, laat staan om te zien of die klopte. De meeste toegezegde RUP-documenten zijn nooit geleverd en wellicht ook nooit gemaakt. Toen uitkwam dat er slecht was gepresteerd, zei Capgemini publiekelijk dat ze bij dit project alleen leverancier van mensen waren en dus niet van diensten (zoals PM, QA/QC) en ook niet van producten (zoals code en documentatie).

@Jaap: ben wel gepensioneerd, heb daardoor meer tijd om het ERP wereldje te verkennen, gekoppeld aan mijn eigen ervaringen. -- VOORBEELDEN UIT ERP :Een rijkelijk voorzien ERP pakket kan ook zeer eenvoudig zijn als het eerder door DATA gestuurd is. Afhankelijk van wat je invult krijg je meer diepgang. Het volstaat de diepste level te testen om de fouten er uit te halen.
Wat licht in deze nog duistere uitspraak: in een bepaald ERP-pakket ( mag geen reclame maken, ook al heb ik er geen belang in) kan ik de bewerkingen definiëren vanaf een instel- en een runtijd ( deze laatste in tijd of in rate) op een werkcenter, zolang er maar 1 stap betroffen is. Wil je meer, dan ga je naar de Routing DB waarin je optionele werkcenters en normtijden kan ingeven, met aantal operators voor ieder, met skills, serieel en parallel. Overlap in aantal, tijd, percent, transfertijden, met individuele kalenderafwijkingen. Niet alleen voor een werkcenter, bv. Een pers, maar ook een matrijs, en belangrijke hulpmiddelen. Ieder van die definities zijn verbonden met 'effectivity date', vanaf... tot... En kunnen beinvloed worden door randvoorwaarden in een basic-achtige logica, je hoeft alleen uw proces goed te kennen om het te beheersen, geen ICT skill nodig.
Als kers op de taart wordt de INFINITE scheduling aangevuld met een FINITE oplossing dmv. een TOC variant vlg. prof. Wiendahl. Als de complexte definitie functioneert is er geen twijfel voor de eenvoudiger.Als buitenstaander ga je geen kegels omgooien door aanpassingen in een complexe constructie die je niet zelf beheerst, dan ga je hoogstens aanmodderen. In nu bijna 20 jaar had ik niet het genoegen ook maar 1 bug te kunnen melden aan de auteurs, of een data repair te moeten laten uitvoeren. Beperkt maatwerk rond de toepassing, nooit in de basis.
De duidelijk principes waaraan ieder ICT project zou moeten volstaan, ik moet ze niet opsommen, ben ik hier tegen gekomen. Een zeldzame rots in de branding. De auteurs hadden gewoon inzicht en een duidelijke visie in de materie, ze hebben geen symptomen nagejaagd.

Ik mis iets in bovenstaande discussie. Uit bovenstaande wordt niet duidelijk wat de kwaliteit was van de VB-code die als input diende. Als je een VB-programma converteert naar .NET en je vat dit op als een puur technische klus waarvoor geen domeinkennis gebruikt mag worden (dus: geheel in India), dan zou het .NET-programma zoveel mogelijk de structuur van het VB-programma moeten volgen: spaghetti in, spaghetti out. Dan kun het je Cap en "India" niet verwijten als de output spaghetti is.

In het algemeen heb ik wel vaker gezien dat technische klussen toch niet zo technisch bleken te zijn, en dan kun je flink in de problemen raken als je geen toegang hebt tot domeinkennis.

Verder heeft Cap zich in deze kwestie verweerd met de stelling dat Equihold het project-management zou doen en dus zelf had moeten toezien. Maar dat is nu net de essentie van de Faalindustrie: akkoord gaan met een slechte projectopzet om flink uren te kunnen schrijven.

Na zeer relevante opmerkingen van Niels ("Geef me eerst het design") en Hans ("wat was de kwaliteit van de VB-code die als input diende?") wil ik met name ingaan op de 3 genoemde punten van René Veldwijk.

In een eerdere reactie stelde ik al de vraag over het uitgangspunt van dit project: Visual Basic naar .Net? René noemt het een puur technische klus. Maar dit artikel beschrijft ook de testen waarin gekeken werd of de software voldoet aan de eisen die daaraan gesteld mogen worden. Wat was er op tegen geweest om vanuit het design de applicatie opnieuw te bouwen?

In (zijn) punt 2. voegt René hier aan toe dat Equihold waarschijnlijk ook functioneel verder wilde. Dat kan niet in een puur technische klus. Hoe kan de IT dienstverlener dat dan oplossen met "zorgplicht"?

Punt 3 gaat in op de beoordelingsmethodiek van de IT dienstverlener. Misschien leidt deze wat ongelukkige methodiek tot het gevoel dat er gesjoemeld wordt, maar beoordeling van medewerkers is eigenlijk een puur interne aangelegenheid voor de IT dienstverlener. Het klant oordeel wordt echter wel als cruciaal gezien en dan bestaat het risico dat de klant "belang" heeft bij een beoordeling. Dit levert ook wel eens het omgekeerde effect op.

Belangrijkste is echter om aan te geven dat we 1 2 Focus en bijvoorbeeld het project bij de SVB absoluut niet met elkaar moeten vergelijken. Net zo goed als een vergelijking tussen 1 2 Focus en het SPEER project bij defensie niets met elkaar te maken hebben. Het één is een technische conversie van een VB applicatie, het ander een mega SAP implementatie met onderliggend veranderingstraject.

Tot slot de belangenverstrengeling. Zie de reacties bij:

http://www.computable.nl/artikel/nieuws/overheid/5593567/1277202/zembla-capgemini-deelde-de-lakens-uit-bij-svb.html

Met name de reactie van Machteld ("Het is op zich niet uitzonderlijk dat de projectleider wordt geleverd door de softwareleverancier") herken ik. Zoals ik al stelde zou het beter zijn om de (ICT management) kennis aan de kant van de overheid te verbeteren, in plaats van in te huren. En ik ga er zeker niet zonder meer van uit dat de door Capgemini ingehuurde ZZP-er's niet onafhankelijk zouden kunnen zijn. Als SVB deze rol zelf had in kunnen vullen dan was daar in ieder geval geen discussie over geweest. En laat dat nou net de crux van de Zembla uitzending te zijn.

@ Hans van Leijen, de kwaliteit was van de VB-code is niet bepalend geweest voor die van de Dot.Net versie omdat het geen 1 op 1 technische conversie was. Er is migratie geweest naar een andere architectuur (Thee Tier) en andere taal (vrijwel geheel C#) en bijbehorende MS tooling voor de skins. De VB6-versie was een voorbeeld voor Capgemini die in Nederland de Use cases en dergelijke maakten, die door Equihold goedgekeurd moesten worden. Daarvoor was er heel veel contact met de Capgemini-mensen in Nederland. Mumbai India had ook de beschikking over die VB-applicatie.
Ik weet niet hoe de kwaliteit van de VB-code is getest en wat daar uit is gekomen, maar de VB-software (grotendeels gemaakt door via Brunel gedetacheerde mensen) was voor de klanten wel acceptabel, in tegenstelling tot de DotNet versie. Dat zegt mij genoeg.

Hans, Equihold zou de regie doen (richting, prioriteit, goedkeuring van de deliverables) en Capgemini de rest, incluis het projectmanagement. Capgemini had dan ook vele managers rondlopen in Nederland en uiteraard in Mumbai India. Dat Capgemini opeens het verschil niet weet tussen regie en projectmanagement is volstrekt ongeloofwaardig.
Equihold had twee contactpersonen die de deliverables van Capgemini moesten goedkeuren. Toen Capgemini wist dat het vreselijk misging, probeerden ze aapjes op de schouders van Equihold te zetten en kregen die contactpersonen van Capgemini mooie management titels, waar Cap zo sterk in is. Achteraf heeft Capgemini zelfs gezegd dat Equihold het projectmanagement heeft gedaan en dat “Capgemini leverde mankracht en bouwde op aanwijzing van Equihold de gewenste functionaliteit.”

Als het bovenstaande íets duidelijk maakt dan is het wel dat het niet duidelijk is, en wellicht vanaf het begin ook niet was.
Ik vermoed echter dat het - zoals zo vaak - niet ingewikkeld was, maar ingewikkeld werd gemáákt/

Het gaat hier in essentie om de combinatie van uitbesteding door een Opdrachtgever aan een Opdrachtnemer. De Opdrachtnemer maakt bij de uitvoering van zijn opdracht gebruik van een sourcingsvorm naar India.

Goede regievoering is dan essentieel, in opzet en in uitvoering. Managen van eisen en randvoorwaarden, alsmede een solide QA is daarbij fundamenteel. Het projectmanagement is daarvan een uitwerking.

Hier spelen derhalve 2 zaken : de regievoering en de sourcing naar India.
Daartussen hoort echter een 'Chinese Wall' te staan.

Vraag is dus of men zich hieraan gehouden heeft.
Het heeft de schijn van niet, zoals ik dat in legio gevallen van nabij heb gezien.

Ik zou er niet bij voorbaat op vertrouwen dat de rechter de contractcasus op waarde zal weten te schatten, ondanks ongetwijfeld vele aan hem aangeleverde deskundigenrapporten. Iets dat Capgemini ongetwijfeld beseft. Overigens is de civiele rechter in hoge mate lijdelijk.
Wellicht een idee om een kortgeding te beginnen en Capgemini te dwingen de eis van voldoen van (ingehouden) betalingen en rente te laten vallen en open te staan voor mediation?

@Jos , hoe Capgemini het allemaal intern geregeld heeft, dat weet ik niet. Bij uitbesteding, waarvoor door Equihold gekozen is, is de keuze voor methoden en technieken aan de opdrachtnemer en is het aan de opdrachtnemer om ja of nee te zeggen tegen het totaalpakket.
Ik vind je verhaal heel interessant gezien de vele problemen met ERP/CRM en vul maar in trajecten. Zou over deze manier van werken artikel graag een artikel lezen.

@P.J Westerhof, je vermoeden dat het niet ingewikkeld was, maar ingewikkeld werd gemáákt, die deel ik. Er is een duidelijk vermoeden dat de de accountmanager van Capgemini niet wist wat voor een soort contract er moest komen. Daarover heb ik op 6 maart geschreven. Dat komt wellicht door een mol die de verkeerde informatie heeft verstrekt.

Goede regievoering is essentieel, daar ben ik het ook mee eens. Maar Equihold was een kleine startup, die één keer een applicatie in house heeft laten maken en tevreden was over hoe dat ging met gedetacheerden die je direct kon spreken. Met de vervolgstap van Rightshoring hadden ze geen enkele ervaring. En, wat belangrijker bleek te zijn, Capgemini had dat toen ook niet. Ze waren maar wat blij een miljoenenproject te hebben binnengesleept om hun concept van Rightshoring uit te testen. De Chinese Wall was er wel, maar een adequate communicatie en taakverdeling tussen Front- en Backoffice was niet. Een Indiase Liaison Officer heeft de communicatie verbeterd met India, maar toen was het al te laat; het fundament was slecht. De communicatie op commercieel vlak heeft nooit gedeugd en werd alleen maar slechter. In plaats van zorgplicht koos men voor te optimistische rapportages en uiteindelijk voor rapportages die Equihold op het verkeerde been heeft gezet.

Over de Quality Assurance heb ik reeds op 2 maart geschreven. Die was slechter dan daar waar men niet aan QA doet.

@Jaap : dat 'soort contract' is in dit geval een no-brainer : standaard out-of-the-box raamovereenkomst + nadere overeenkomst(en).
Dat lijkt - ik heb het contract niet gelezen, alleen eróver gelezen - ook gewoon gebeurd te zijn. Ook de daarbij behorende wederzijdse rollen, taken en verantwoordelijjkheden lijken benoemd te zijn.

De Chinese Wall hoort tussen Opdrachtgever en Opdrachtnemer te staan. De 'rightsourcing', 'rightshoring, whatever is de verantwoordelijkheid van de Opdrachtnemer, de overall controlemomenten daarvan horen in de raamovereenkomst et al te staan.
Ervaring met 'rightsourcing', 'rightshoring, whatever bij de Opdrachtgever is dus verder niet relevant. De 'Indiase Liaison Officer' is een herkenbaar fenomeen, maar evenzeer verantwoordelijkheid en risico van Capgemini, niet die van Equihold.

Ook het communicatie-aspect is een herkenbaar fenomeen, incl., watermeloen-rapportages en beïnvloeding.
Hierop had de Opdrachtgever *vanuit de regierol* wél alert moeten zijn en moeten ingrijpen, maar dat verstoord (uiteraard) al snel de prettige verstandhouding.

Zoals ik elders al zei : als je buiten je rol gaat meemanagen wordt je medeverantwoordelijk. De rollen, taken en verantwoordelijkheden worden diffuus, en je kunt je contract vervolgens wel in de prullenbak gooien.

@ EddieK, vanaf release 5 wilde Equihold functioneel verder. Maar de zorgplicht had al vanaf het begin goed moeten zijn, juist bij kleine onervaren klanten. Ik weet uit ervaring dat hoe beter je voor de opdrachtgever zorgt, des te beter functioneren die als opdrachtgever en dat geldt vooral voor kleine en voor onervaren opdrachtgevers. En dat kan een hoop misvattingen, teleurstellingen, gehakketak en financiële ellende voorkomen.
Er zijn duidelijke verschillen, maar ook veel parallellen te zien tussen het mislukken van de ontwikkeling van 1-2Focus en MRS/SPEER/Trekkingsrechtsysteem, et cetera. Dat laatste is dan ook gedaan in de aanklacht van Equihold.

@P.J Westerhof, er was geen One Size Fits All Out-Of-The-Box raamovereenkomst met bijlagen. Het standaard raamcontract dat Capgemini heeft gebruikt voor 1-2Focus, was eigenlijk bedoeld voor detachering. Door bijlagen (maatwerk) is dit confectiecontract weer aangepast voor een outsourcing opdracht, maar zaken zoals regie en allerlei vormen van management werden niet beschreven in het hoofdstuk Definities. In bijlage C zijn de rollen en de t.b.v's wel omschreven. De accountmanager had een ander sjabloon moeten pakken en de definitielijst goed aanvullen. Dat er zo met sjablonen is omgesprongen, lijkt achteraf een voorbode te zijn, hoe Capgemini met de RUP-sjablonen om zou gegaan.

De Chinese Wall behoort inderdaad tussen opdrachtgever en opdrachtnemer te staan. Dus 'Capgemini verbood contact met Indiërs'. Helaas leek er in de praktijk ook een Chinese Wall te staan tussen Back- en Frontoffice van Capgemini. Ik denk dat Capgemini hoopte dat Equihold zou gaan meemanagen, met de gevolgen die je hebt genoemd.

@Jaap: op gevaar van beschouwd te worden als reclame, ik heb er als gepensioneerde niets aan, het beste wat ik kan aanbevelen is het concept in zijn geheel te bekijken in een van de kantoren van het sw-huis Oxaion, Dusseldorf is waarschijnlijk de kleinste verplaatsing. Kan je het grondig aan de tand voelen en oordelen dat ik niet overdrijf. Mijn vroegere contactpersoon is Rene Broekman, een senior consultant en Nederlander van oorsprong.

@Jaap, bij het doornemen van deze bijlage C kom ik tot een aantal andere bevindingen dan jij hier noemt. Zo wordt in bijlage C als uitgangspunt van de overeenkomst genoemd: het overeengekomen aantal uren voor ontwikkelcapaciteit wat Equihold vooraf bij Cap Gemini inhuurt voor een bepaalde tijdsperiode (3 maanden).
Daarnaast is er een overzicht van een blended uurtarief die omlaag gaat wanneer er meer uren worden afgenomen. Daarnaast kan Equihold extra capaciteit inhuren tegen een volgend uurtarief: PL €…., Testmanager €…., Development capaciteit India €…., etc.
Op al deze tarieven gelden opslagen voor reis, en verblijfskosten en additionele kosten zoals visa.
Dit zijn zaken die ik niet direct associeer met een resultaatverplichting.

Ook de taken, verantwoordelijkheden en bevoegdheden kom ik niet zo expliciet tegen (wellicht dat ik er overheen lees). Wel wordt genoemd welke partij welke werkzaamheden gaat uitvoeren (taken) maar er wordt niet expliciet genoemd wie verantwoordelijk is voor het resultaat en wat de bijbehorende bevoegdheden zijn. Of men kiest voor het uitgangspunt dat degene die de werkzaamheden gaat doen ook automatisch verantwoordelijk is voor het resultaat tenzij anders genoemd. Uiteindelijk was Equihold wel eindverantwoordelijk volgens bijlage C maar was in het begin weer niet bevoegd om direct in contact te treden met de programmeurs in India.

Opmerkelijk is dat in bijlage C de betalingseisen wel heel exact zijn uitgewerkt compleet met betaalschema zodat misverstanden en risico’s voor Cap Gemini uitgesloten werden. Zoals eerder vermeld moest Equihold vooraf aangeven hoeveel uren men wilde afnemen. Twee maanden van te voren werd dan vanuit Cap Gemini een factuur verstuurd met een betalingstermijn van 30 dagen zodat de betaling binnen was, een maand voordat de werkzaamheden zouden aanvangen.

Regie en andere vormen van management en control worden wel genoemd in het Software Development Plan (SDP) welke de basis vormt voor het project volgens de inleiding. Hier wordt oa. gewag gemaakt van de stuurgroep en de deelnemers (naam en rugnummer), project deliverables, voortgangsrapportages, bezetting in India in FTE, wekelijks voortgangsoverleg en deelnemers, verantwoordelijkheden (hier wel) van front-, en backoffice team. Zo is de Cap Gemini manager verantwoordelijk voor het overall project resultaat volgens het SDP.
Echter, verder dan versie 0.75 (3 mei 2006) is dit document nooit gekomen en heeft ondertekening ook niet plaatsgevonden.

@Kurt : mijn geheugen liet mij even in de steek.
In het artikel van 02-03-2015 'Capgemini 1-2Focus: falen Quality Assurance' kwamen Jaap en ik al tot een aantal conclusies tav. het contract.

Op FaillissementsDossier.nl lees ik dat de meest recente stap in de rechtszaak voor 19 augustus 2015 op de rol stond (Conclusie van Dupliek in reconventie door Capgemini)

@Jos, als je onder eigen naam reageert of publiceert, dan maak je altijd reclame of je nu wilt of niet (en positief of negatief). Methoden, concepten en producten die interessant zijn, worden regelmatig in de Computable besproken. Wat is mooier dan dat dit gedaan wordt door iemand die veel praktische ervaring heeft? Dan kan die persoon ook in de diepte gaan als er vragen worden gesteld. Dat kan een commercieel persoon meestal niet.

@Kurt, het klopt dat het verwarrend is. Enerzijds is er sprake van contractuele afname van uren bij een blended (pre pay) uurtarief, dat later aangepast is richting nacalculatie. Typisch uurtje factuurtje, zoals dat normaal is in de detachering en niet bij een resultaatsverplichting. Anderzijds is er sprake van opdrachten voor Capgemini, in het kader van Outsourcing waarbij Capgemini in de planning aangeeft wanneer en wat zij aan deliverables opleveren bij een afgesproken bezetting. Capgemini geeft dus aan hoeveel uren en centen de afgesproken deliverables gaan kosten. Capgemini is ook expliciet verantwoordelijk voor de kwaliteit (met later zelfs een veto recht). Verder bepaalt Capgemini wie aan hun deliverables werken en levert Capgemini de managers die de andere medewerkers aansturen. Verder bepalen zij de projectmanagement methode, vullen ze QA/QC in, verzorgen zij de interne communicatie en de managementrapportages, et cetera. Capgemini schrijft dan ook in een eigen evaluatie van 14 augustus 2006 dat zij managen. Dat wilden ze toen veranderen, maar dat is nooit gebeurd.

De summiere beschrijving van taken, verantwoordelijkheden en bevoegdheden moet je inderdaad her en der in de diverse stukken lezen. Dan zie je wie wat doet, via wie wordt geleverd, wie problemen moet oplossen en wie mag beslissen. Dat is niet zoals je van een bedrijf als Capgemini mag verwachten. Dat is één van de redenen waarom ik in mijn audit nogal kritisch ben,; een deel van de andere redenen heb je zelf ook al in jouw mooie Zesluik beschreven.

Equihold had alleen de regie voor het bepalen van ontwikkelrichting, de functionaliteit (leverde de functionele omschrijving en materiekennis van de sportwereld) en uiteraard voor het goedkeuren van de deliverables. Equihold onderhield ook de contacten met de sportwereld, inclusief de co-developers van het 1-2Focus concept.

De afspraken en de aantoonbare de facto manier van werken, geeft aan dat er een resultaatverplichting was. Het hoofdresultaat had moeten zijn, een van scratch opgebouwde applicatie volgens het vernieuwde 1-2Focus model van Equihold waarmee Equihold aan had kunnen verdienen.

De meeste van deze grote organisaties zijn veel tijd kwijt aan lullen en specificaties schrijven die niemand leest, inclusief zijzelf niet.

Op basis van mooie plaatjes en grafieken weten ze dit te verkopen, want dat zijn mannen in stropdassen, niet de .NET nieters die het moeten implementeren en dan achterkomen dat wat er is gespecificeerd, niet deugt, dus wat ze mooi zeggen is dat de specificaties een 'levend document' zijn. Met andere woorden, een soort poging om agile te werken. Maar toch duurt het uiteindelijk altijd langer en kost het altijd meer, niet 2x, niet 3x, nee ...

En dan de .NET-nieters... Het mooie van .NET is dat het makkelijker is geworden om iets te bouwen zonder iets te snappen, dus dat is handig met al die junior ontwikkelaars die al .NET kunnen programmeren nog voordat ze ooit hebben geleerd hoe een computer werkt en wat memory management is.

Lijkt op de motto "waarom een boekhouder nemen als je weet hoe een rekenmachine werkt?"

Dit lijdt vrijwel altijd tot performance issues, security problemen en torenhoge kosten, om te bouwen en om te onderhouden.

Vaak is duurkoop gewoon duurkoop en had je net zo goed kunnen gaan voor goedkoop.

@Frank, Equihold heeft de Use Cases en Use Case diagrammen, et cetera, gelezen. In hoeverre Capgemini de specificaties die ze hadden opgeschreven, ook zelf goed hebben gelezen, dat is de vraag. De informatie van veel specificaties, ook cruciale, lijkt niet of niet goed bij de ontwikkelaars in India terecht te zijn gekomen.

Je hebt wel een punt dat grote ICT-leveranciers vaak slecht omgaan met opdrachtgevers. Vooral kleine opdrachtgevers en ambtelijke organisaties hebben daar last van. Een geschil met een kleine klant of een ambtelijk apparaat, dat vindt sales niet interessant. Er uitgegooid worden bij een groot bedrijf, dat is pas slecht nieuws voor sales, vooral publiekelijk. Als je, namens een groot bedrijf, aangeeft ze eruit te gooien en dat tegen iedereen te gaan vertellen, dan bellen ze meteen met zweterige handen het hoofdkantoor op. Dan kan opeens alles; gratis herstel, excuses van de hoofddirectie en het luxe etentje dat je beter kan weigeren.

Helaas heeft een grote opdrachtgever van Equihold hen destijds het advies gegeven om naar Capgemini te kijken, niet wetende wat dit zou gaan betekenen.

@Jaap
Je opmerking over 'naming & shaming' om zodoende je gelijk te behalen is nogal typerend, de emotionele chantage spreekt ondertussen dan ook duidelijk uit je analyse. Beeldvorming die je hebt aangaande het 'verwachtingsmanagement' klopt trouwens niet en daarmee trek ik je eerdere antwoord aangaande de vraag over de ingebrekestelling in twijfel.

Reden hiervoor is dat ik het beeld dat je schetst wel herken maar dat je hierin wel eenzijdig bent, het eigenaarschap van de problemen wordt dus vaak afgeschoven zodat er eindeloos door gegaan kan worden met workarounds. Dat is dan ook het enige vergelijk dat ik zie met de constant aangehaalde referenties naar overheidsprojecten. En contradiction in terminis zit dan ook in het 'calimero-syndroom' want ik krijg sterk de indruk dat Kenneth Berkleef gewoon een ambtenaar was die droomde over het ondernemerschap.

Aangaande je laatste opmerking over het kijken naar Capgemini denk ik dat dit dus ook wel opgaat voor de use cases, ik kijk naar mooie vrouwen maar daar blijft het dan bij omdat ik weet wat mijn beperkingen zijn. Hele klucht heeft namelijk wat weg van een dame van lichte zeden die achteraf roept dat ze onzedelijk betast is als ze merkt dat het aangenomen geld vals blijkt te zijn;-)

@Ewout, hoezo “je opmerking over 'naming & shaming'om zodoende je gelijk te behalen is nogal typerend“? De naming & shaming opmerking maak je wel vaker op Computable, maar ik kan deze niet in een context plaatsen. Er worden geen namen van betrokken Capgemini mensen genoemd en zij willen ook niet aan 1-2Focus gekoppeld worden. Dat zegt misschien wat over het punt shaming.

De enige naam die veelvuldig wordt genoemd is die van de heer Kenneth Berkleef, waarover jij expliciet en impliciet steeds weer een nogal laatdunkende menig verkondigd zonder dat je deze man kent, noch wat hij precies meegemaakt heeft. Kenneth Berkleef is niet “gewoon een ambtenaar was die droomde over het ondernemerschap”. Hij is een jurist die als zodanig een succesvolle ondernemer is geworden en onder andere voor topsporters heeft gewerkt. Zo is hij in contact gekomen met mensen die het 1-2Focus concept bedacht en ontwikkeld hebben. Hij weet mensen bij elkaar te brengen en zo is de eerste versie van 1-2Focus van Equihold ontstaan, in goede samenwerking met een ICT-bedrijf (Brunel). Die versie maakt zoveel indruk, dat men in de sportwereld meer wilde. Kenneth Berkleef is met veel enthousiasme aan de volgende stap begonnen, maar hij hij kende niet wereld van de grote jongens zoals Capgemini. Als hij de opdracht bijvoorbeeld aan een beunhaas had gegeven, dan had je een punt, maar dat is Capgemini niet. Nu sla je, voor de zoveelste keer, de plank mis.

Ik vind je opmerkingen vaak grof op de man spelend, vooral als jij die rond middernacht produceert. Deze post van jou pas niet bij een Computable expert, is zelfvernederend en completely out of line.

@Jaap
Als eerste is de constatering van middernachtelijke uren suggestief, misschien zit ik nu wel in een andere tijdszone. Het 'offshoring' probleem vraagt een aanpassing aan de realiteit als we kijken naar de 24/7 economie.

Best hilarisch trouwens dat je met steeds meer onthullingen komt die tegenstrijdig zijn aan je analyses, stop je zoveel moeite in het bewijzen dat Capgemini een beunhaas is en zeg je vervolgens weer dat ze dat niet zijn. Misschien sla ik de plank mis maar raak ik de spijker?

computablecommune vs individu
dictator vs democratie
ravioli vs spaghetti
valt het artikel dan wel de reacties nog enigzins te verteren ?

maar t.a.v. op de man spelen, simplificeren, polariseren, olie op vuur, uit context halen, selectief citeren.. ik kan jullie uit eigen ervaring wel vertellen. is nog niet zo eenvoudig dat allemaal steeds weer in 1 reactie mee te nemen :-P

@ Ewout, ik ga niet in op elk onlogisch, onnavolgbaar en vals argument van jouw zijde; dan kan ik wel bezig blijven. Maar ook jij moet snappen dat er een verschil is tussen een beunhaas zijn en ondermaatse producten leveren terwijl je het beter kan. Misschien is dat voor jou niet belangrijk, maar wel voor de rechter, de klant en de leverancier. Het één betekent een aangegaan ondernemersrisico, het ander een recht op vergoeding van gelede schade.

Voor de diesel-motor-sjoemel sofware staat de wereld bijna in vuur en vlam, wie vindt een oplossing voor de misleiding van de andere soort? Die kost meer geld aan belastingen en aan de burger want dat wordt in het product verder berekend.

@Jaap
Faillissementsverslag 1-2Focus Holding, 1-2Focus Automation en Equihold B.V:

"Second opinion ten aanzien van de Vordering op Capgemini Nederland B.V. bevestigt dat het treffen van rechtsmaatregelen opportuun is."

Aangaande mijn vraag over een ingebrekestelling denk ik dat ik uit bovenstaande dus mag concluderen dat je niet geheel waarheidsgetrouw verslag doet. Onlogisch, onnavolgbaar en valse argumentaties omschrijven dan ook prima je opinies en reacties welke opportuun zijn.

Voordat je mij de schuld gaat geven van de 'resultaatverplichting' die je aangegaan bent, het gebalk over de code is als 'eastereggs' zoeken waardoor er inderdaad sprake is van een heleboel hazen. Nu weet je natuurlijk nooit hoe een koe een haas vangt maar ik denk dat de sector niet geholpen is met dit soort emotionele chantage.

@ Ewoud, ik ken het verslag van Höcker advocaten. En als een jurist schrijft “Vordering op Capgemini Nederland B.V.: er is een second opinion ten aanzien van de Vordering verkregen die bevestigt dat het treffen van rechtsmaatregelen opportuun is”, dan bedoelt deze dat er goede rechtsgronden zijn om vorderingen in te dienen bij Capgemini, wat gedaan is. En dat was de opinie op 14 januari 2015. Inmiddels is de bewijslast alleen maar groter geworden.

Ewoud, uit de wijze waarop je citeert en uit de derde alinea van je reactie, krijg ik het idee dat je niet het verschil kent tussen opportuun (doelmatig, gepast, gunstig, geschikt, gelegen, et cetera) en opportunisme. Dat laatste kan (maar hoeft niet) negatief opgevat worden (handelen zonder principes, voordeel zoeken waarbij ethiek geen rol speelt).

Met betrekking tot de code. Diverse specialisten hebben de broncode onderzocht en zij komen tot de conclusie dat deze in het algemeen niet bepaald goed is. Naarmate men de code meer diepgaand is gaan onderzoeken, is het bewijs steeds sterker geworden dat de code veel fouten bevat, de Three Tier architectuur gefaked is en de code bovendien moeilijk te onderhouden is. Het verweer van Capgemini tot nu toe, vind ik op dit punt ook niet sterk. Die bewijzen voor spaghetticode zijn een goede verklaring voor:
a: het hoge aantal bug fixes / hot fixes dat Capgemini heeft moeten leveren,
b: het feit dat ook de laatste releases van 1-2Focus zo buggy waren, dat de klanten van Equihold deze software niet wilden accepteren en
c: de vele (en deels kritische) bugs die ik zelf heb kunnen constateren en voor een deel op de Capclaim site te zien zijn.

Samenvattend, je bent nogal opportunistisch eclectisch bezig met logica en dialectiek, zonder enige vorm van degelijke retorica :-)

@Jaap
Mooi opgezocht, maar ik wees op opportuniteitsbeginsel welke bedoeld is om niet van elke m(b)ug een olifant te maken.

@ Ewout, als je partijen in een civielrechtelijk geschil een “seponeringsrecht” wil geven, dan komt het de gedupeerden toe.

Of in dit geschil een m(b)ug een olifant is, dat mag primair door de opdrachtgever Equihold en diens klanten (de betrokken sportorganisaties) bepaald worden. In deze zaak van uiteindelijk alleen verliezers, moet ik hen achteraf gelijk geven. De 1-2Focus pudding met pastasliertjes en lange vingers smaakte mij ook niet. Het is echter aan de rechter om te bepalen wie “Foutje, bedankt!” mag zeggen.

@Jaap

Civiel rechtelijk ligt het inderdaad wat lastiger omdat er twee partijen zijn die elkaar ervan beschuldigen dat ze de aangegane verplichtingen niet zijn nagekomen. En betreffende die verplichtingen wordt het ronduit verwarrend, beetje als de code zelf zullen we maar zeggen.

Of Capgemini nu wel of niet geleverd heeft wat afgesproken is laten we aan de rechter over maar waar ik tegen ageer is het 'ontzorgen' sprookje, als ondernemen zo makkelijk was dan hadden we 16 miljoen 'softwarehuisjes' en niet genoeg indiaantjes. In dezelfde lijn ligt mijn bezwaar aangaande het idee van een 'softwarefabriek' die wonderen op bestelling levert.

Zeker heeft Capgemini fouten gemaakt maar ze zijn niet de enigen, de medaille heeft nog een keerzijde. En het is die keerzijde die me verontrust aangezien de contracten steeds dikker worden, requirements tegenstrijdiger en specificaties steeds dunner. Achteraf het resultaat daarvan in de code concluderen is dan niet zo moeilijk.

Ewout, je toont wel steeds een erg negatieve houding tegenover klanten. Als klanten een auto kopen met een dieselmotor met slechte software, dan is het ook hun eigen schuld? Hadden ze maar meer verstand van motormanagement moeten hebben, toch?

@Ewout, je kan wel steeds weer klagen over die domme klanten, die maar niet weten wat ze willen enzovoorts, maar de opdrachtgever heeft minimaal een net zo belangrijke rol in het commerciële traject. Zij hebben meestal meer specifieke expertise dan de klant. Als er een garbage opdracht in gaat, wat komt er dan weer uit?

Het kwaliteitssysteem van de leveranciers, moet er voor zorgen dat vaag en vlug babbelende commerciële figuren niet zomaar een opdracht over de schutting met hun collega's gooien. Voorafgaande aan grote en/of complexe opdrachten moet een offerteteam, met daarin (potentiële) uitvoerders, gedegen naar de opdracht hebben gekeken en de inhoudelijke kant van de offerte hebben geschreven.

De opdrachtnemer moet net zo goed helder voor ogen hebben wat de opdracht inhoudt als de opdrachtgever en wat bijvoorbeeld de verdeling van de taken, bevoegdheden en verantwoordelijkheden zijn. Als leverancier moet je ook weten of een bepaald product of dienst goed aansluit bij de behoefte van de klant, of je bij de opdracht wel een geschikte leverancier bent (hoeveel ervaring en capaciteit heb je), of de medeopdrachtnemers en subcontractors wel betrouwbaar zijn, of de opdracht wel tot voldoende winstmarge leidt, of de klant wel kan betalen, et cetera. De leverancier moet ook met de opdrachtnemer blijven praten in verband met voortschrijdend inzicht bij beide partijen, over draagvlak, nieuwe omstandigheden, et cetera.

En op die punten is Capgemini bij Equihold veelal de mist ingegaan.
Equihold heeft al vrij snel aan de bel getrokken en is ook met voorstellen gekomen, maar van de andere kant werden de alarmsignalen eerst te veel genegeerd en daarna werd er gebokt, omdat de focus zo op het innen van de facturen lag. En zij zijn niet de enige leverancier die dat doen.

@martin
Software van Volkwagen deed precies wat het moest doen en dus gaat de vraag hier alleen om wie daartoe de opdracht gaf.

@Jaap
De klant is koning dacht Capgemini ook en dus leverden ze precies wat gevraagd werd. Het antwoord is JA, laten we nu eens kijken naar de vraag. Zeker zijn er nog meer leveranciers die dezelfde werkwijze hanteren, volgens Henri is de skillset adaptability tenslotte dus meer gevraagd dan integriteit;-)

@Ewout, zo te lezen klopt zowel de expliciete als de impliciete (veronder)stelling van Martin over jou.

Hoezo heeft Capgemini (of VW) geleverd wat gevraagd werd. Heb jij de stukken bij Berkleef opgevraagd om de vraag /behoefte van Equihold te kennen? Nee, je kletst maar wat. Dat klanten vragen om hidden agendas en buggy software, is een testimonium paupertatis.

@Jaap
Prima, de klant is koning:-)

Tenslotte doe je dus weer precies waar ik je eerder al van beschuldigde, het overnemen van een beeld dat niet getoetst is aan de werkelijkheid, een testimonium paupertatis doordat de kennis ontbreekt om de feiten van de fabels te kunnen onderscheiden.

Klanten vragen misschien niet expliciet om een verborgen agenda en buggy software maar ze impliceren het wel als ze alleen nog maar de papieren tijgers te temmen. Hele industrie van emissie-rechten is tenslotte ook een windhandel.

Voordat je de VW software dood gaat analyseren misschien handig om eerst even te kijken naar de krachten in het veld, de machtige Amerikaanse autoindustrie lobby heeft zelf niet voor auto's gezorgd die schoner zijn.

In de derde helft de gemiste strafschoppen er nog in proberen te lullen is precies als de natte scheet van Marin in een netje, On-topic had hij dus beter Blatter c.s. kunnen noemen omdat het probleem in het toezicht zit.

Ewout wat diepgravend jou diagnose. Wat zijn jouw curative en preventieve remedies?

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

×
×