Mislukt automatiseringsproject, wat nu?
Bij voortduring treffen we publicaties aan waarbij er weer melding wordt gemaakt van een mislukt automatiseringsproject. De meldingen
betreffen vaak grote en complexe maatwerkprojecten en de implementatie van ERP- en CRM-software. Wanneer we de onderzoeksbureaus
mogen geloven, dan mislukt ruim 60% van de ICT-projecten. Hierbij dient dan wel gedefinieerd te worden wat verstaan wordt onder
mislukken. Er zijn drie criteria waarin het mislukken zich kan manifesteren, namelijk tijdsoverschrijding, budgetoverschrijding en
gebrekkige functionaliteit. En uiteraard combinaties van de drie voornoemde criteria.
Oorzaken
De dagelijkse praktijk leert dat er een veelheid aan oorzaken aanwijsbaar kunnen zijn voor het niet-welslagen van een
automatiseringsproject. Als mogelijke oorzaken kunnen benoemd worden:
- onvoldoende maken van het huiswerk;
- te hoog geschapen verwachtingen door de leverancier geschapen;
- onvoldoende commitment van het hoger management;
- onvoldoende projectmanagement;
- onvoldoende betrokkenheid van de gebruikers bij de implementatie;
- gebrekkige communicatie;
- onvoldoende financiële middelen;
- onvoldoende mankracht;
- overambitieus (prestigeproject);
- incompetente leverancier;
- bedrijfsprocessen bij klant zijn slecht georganiseerd.
De bovenstaande opsomming is geen limitatieve opsomming, daar er nog meer redenen kunnen zijn waardoor een automatiseringsproject kan
mislukken. Echter wel zijn genoemde de belangrijkste redenen.
Huiswerk maken
Echter onderzoek van mislukte automatiseringsprojecten leert dat bij meer dan de helft van de projecten het huiswerk onvoldoende gemaakt
wordt. De leverancier heeft juridisch gezien een inventarisatieplicht en dient er zich te van overtuigen dat hetgeen de klant wenst ook
mogelijk moet zijn met het gereedschap dat de leverancier wil gaan leveren. De klant heeft echter de plicht om de juiste informatie te
verstrekken, zodat de leverancier ook kan bepalen of zijn gereedschap geschikt is voor het doel. In de praktijk blijkt dat bij veel
automatiseringsprojecten te weinig diepgang wordt gelegd in het expliciet boven tafel krijgen van de functionaliteitseisen en –wensen.
Dit fenomeen doet zich heel vaak voor bij MKB-organisaties, omdat zij over onvoldoende expertise beschikken om hun huiswerk volledig te maken.
Enerzijds ligt dit bij leveranciers die feitelijk verplicht zijn om een 100% sluitende inventarisatie te maken. Doch dit is uiterst moeilijk,
wanneer een doorsnee MKB-gebruiker onvoldoende kan aangeven wat precies gewenst is. In dit geval belanden partijen vaak in een spagaat en
zullen leveranciers vaak roepen dat hun oplossing de haarlemmerolie is voor de gebruikersorganisatie. Helaas de praktijk is vele malen
weerbarstiger, daar de implementatie van de software een keiharde confrontatie is met de bedrijfsprocessen die men wenst te automatiseren.
Wel dient er een onderscheid aangebracht te worden naar de grootte van organisaties en de omvang van automatiseringsprojecten. Het kleine
MKB-bedrijf kan zich veelal geen omvangrijke maatwerkprojecten permitteren en beschikt ook over onvoldoende kennis om precies te kunnen
aangeven wat in detail de eisen en wensen zijn. Dit in tegenstelling tot een grote opdrachtgever die hiervoor specialisten in dienst heeft,
zodat de rol van de opdrachtgever in het onderhandelings- en realisatieproces ook een geheel andere is. Wanneer bij het kleine MKB-bedrijf
een automatiseringsproject misgaat en de zaak uiteindelijk wordt voorgelegd aan een rechter. Dan zal deze de meest zwakke partij, in casu
het MKB-bedrijf, in bescherming nemen en de leverancier (c.q. het softwarehuis) is dan de meest deskundige partij.
Agile
Door steeds meer leveranciers van maatwerkprogrammatuur (ook website-applicaties vallen hieronder) roepen dat zij middels een agile-methode
hun programmatuur vervaardigen. Hiermee willen zij aangeven dat de programmatuur wordt ontwikkeld op basis van een summiere inventarisatie
en men vervolgens middels schermen iteratief doorontwikkelt. Op deze wijze komt men tot eenzelfde resultaat als bij de traditionele
watervalmethode (SDM-methode). Het agile-ontwikkelen is een stap in de goede richting, indien er twee professionele partijen (opdrachtgever
en softwarehuis) over voldoende materie- en automatiseringskennis beschikken. Dit laatste geldt veelal voor grote opdrachtgevers die omvangrijke
automatiseringsprojecten laten realiseren. Wanneer echter kleine opdrachtgevers met onvoldoende automatiseringskennis in een dergelijk
project stappen, dan worden de risico’s voor het welslagen van een dergelijk project allengs veel kleiner (dit getuige de onderstaande casus).
Casus
Kleine opdrachtgever wil een innovatieve webapplicatie laten bouwen voor het maken van begrotingen, die complexe berekeningen uitvoert voor
de bezoeker van de webapplicatie. Door de opdrachtgever is een globaal programma van eisen opgesteld, waarin duidelijk beschreven zijn de te
volgen berekeningstructuur en de geldende rekenregels. Ook is er door hem gezorgd voor een grafisch ontwerp, zodat de look and feel
duidelijk zijn vastgelegd. Echter omtrent de overige functionaliteit, behoudens nog wat opmaaktechnische en autorisatiefunctionaliteit,
heeft de opdrachtgever geen flauw benul van automatiseringszaken. Partijen komen tot elkaar en het project start. Door het softwarehuis
wordt een beginnend programmeur gezet op het project, die gecoacht zal worden door een meer ervaren programmeur. Er wordt echter onvoldoende
en onduidelijk gecommuniceerd, hetgeen veelal leidt tot meningsverschillen. Om een lang verhaal kort te maken is het resultaat, dat na één
half jaar er programmatuur wordt opgeleverd die slechts vijf procent van de gewenste functionaliteit beschikt. Er veelvuldig foutmeldingen
(errors) optreden en deze applicatie ver is van het gebruik door bezoekers van de webapplicatie. De kleine opdrachtgever is inmiddels meer
dan € 100.000,- verder en heeft een product dat bij lange na niet geschikt is om omzet mee te genereren. Op dit moment is de zaak helaas
onder de rechter. Kortom spijtig om te constateren dat er forse kapitaalvernietiging heeft plaatsgevonden.
Voorkomen
Van belang is dat alle gelopen risico´s in kaart gebracht worden, zodat hiervoor tijdig maatregelen getroffen kunnen worden. Het uitvoeren
van een dergelijke risicoanalyse dient uitgevoerd te worden door een functionaris die ervaring heeft op dit gebied. Zodat alle risico´s
onderkend worden en er tijdig de juiste maatregelen zullen worden getroffen. Voorts is bij dergelijke projecten noodzakelijk om als
opdrachtgever bijstand te vragen van gespecialiseerde consultants die vele malen meer ervaring hebben in dit metier. Waarbij een onderscheid
gemaakt dient te worden in de verschillende fasen van dergelijke projecten:
- aanbestedingsfase;
- bouw- en realisatiefase;
- installatiefase;
- implementatiefase;
- nazorgfase.
Elke fase heeft zo zijn specifieke aandachtspunten, waarin cruciale fouten gemaakt kunnen worden die leiden tot het mislukken van het
automatiseringsproject. Naast de reguliere advisering kan het ook zinvol zijn om een second opinion uit te laten voeren door een derde
partij. In grotere automatiseringsprojecten worden ook veelvuldig audits uitgevoerd, zodat de vinger wordt gelegd op bepaalde punten waar
een automatiseringsproject dreigt mis te gaan. Voorts is het van belang dat er met een vaktechnische en juridische expertise gekeken wordt
naar de voorliggende contracten. De praktijk leert dat in de MKB-wereld meer dan 90% van de contracten ongelezen worden getekend! Zeker
wanneer zoveel projecten misgaan is het dubbel zuur wanneer je als opdrachtgever geconfronteerd wordt met een slecht contract. Of wanneer
de opdrachtgever denkt auteursrechten te hebben verworven, die in het contract geheel anders staan beschreven en dus niet verworven zijn.
Acceptatie
Dit is een heel belangrijk moment voor elke van de vijf voornoemde fasen, omdat het accepteren leidt tot het uitspreken van een
instemming met hetgeen is aangeboden dan wel geleverd is. Voor een opdrachtgever moet duidelijk zijn, dat dit een moment is fikse
importantie. Hij kan hierbij aangeven of hij het eens is dan wel oneens is met hetgeen de leverancier heeft gepresteerd. Juridisch is
dit heel belangrijk evenement, daar een rechter de vraag zal stellen in een rechtszaak of de opdrachtgever niet geprotesteerd heeft bij
de leverancier over de levering. Uit den boze is zeker dat een opdrachtgever een (deel)betaling doet als deze het niet eens is met de
levering. In veel algemene voorwaarden van leveranciers is geen acceptatieartikel opgenomen (bij ICT~Office voorwaarden wordt geacht te
zijn geaccepteerd een aantal na oplevering) en laat staan dat zij een acceptatieprocedure hanteren.
Consultant
De eisen die aan een consultant gesteld moeten worden zijn:
- communicatief sterk in woord en geschrift;
- kennis hebben van de markt;
- beschikken over proceskennis;
- juridische kennis;
- veel ervaring in soortgelijke projecten.
Dit alles is bittere noodzaak om de zoveelste zeperd te voorkomen, die wederom op de loer ligt. Kortom zoek een betrouwbare consultant die
voldoet aan de vijf bovengenoemde criteria zodat mislukking voorkomen kan worden of een gestrand automatiseringsproject weer vlot getrokken
kan worden.
Dit artikel downloaden
In de rubriek
'
Contract management ICT/SLA
'
vindt u meer artikelen over dit onderwerp.