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.
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.
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.
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.
@ 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.
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.
@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.
@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.