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.