"Het staat er toch gewoon in?" Die vraag valt meestal een paar weken na de livegang. Het systeem kan alles wat is afgesproken. Toch houdt de planning een eigen lijstje bij en loopt de magazijnchef liever even langs.
Er is dan iets misgegaan, maar het is geen storing. In onze ervaring mislukt een ERP-implementatie zelden op de software. Ze loopt vast op het moment dat iemand iets opgeleverd noemt omdat het is ingericht, terwijl het nog niet in gebruik is.
Een ERP-implementatie mislukt zelden op de software
Ingericht betekent: het systeem kan het. In gebruik betekent: de mensen doen hun werk er aantoonbaar mee. Tussen die twee zit het gat waar de meeste trajecten in wegzakken. Dat geldt voor elk ERP, ook voor Odoo.
Je herkent het aan symptomen die op techniek lijken, maar het niet zijn:
- meldingen over bugs die bij nader inzien geen bugs zijn
- collega's die terugvallen op hun eigen lijstjes en mailtjes
- een projectplanning op groen terwijl de werkvloer kreunt
Elke week dat een team naast het systeem werkt, betaal je twee keer: voor het systeem en voor de omweg ernaast.
Wie zoekt waarom ERP-implementaties mislukken, vindt lange lijsten. Wij houden het bij vier patronen. Het zijn valkuilen die we ook uit ons eigen werk kennen.
Patroon 1: live zonder aantoonbare test
De testfase staat in de planning, maar zonder eigen datum, zonder scenario's en zonder naam eronder. Bij de oplevering staat er dan een zinnetje dat er weinig tijd was om te testen.
Wat er dan gebeurt: alles wat niet klopt, komt pas in productie boven. Bij mensen die het systeem nog niet kennen, op een moment dat er klanten wachten.
Wat ervoor in de plaats komt: per hoofdproces een testscenario, uitgevoerd door een key-user uit je eigen organisatie, met naam en datum. Geen testverslag betekent geen livegang. Dat gesprek voer je vooraf, niet achteraf.
Patroon 2: training als sluitpost
Training staat als één regel aan het eind van de begroting. Wie de key-users zijn, is nog niet benoemd. De kennis landt dan bij de twee of drie mensen die toch al meedachten, en niet bij het team dat het werk doet.
Maak training daarom een voorwaarde in plaats van een kostenpost:
- per proces een key-user met naam
- een werkinstructie die je eigen mensen hebben doorgenomen en goedgekeurd
- geen ingebruikname zonder die instructie, ook niet bij nieuwe functies na de livegang
Hoe je die eigenaren vindt en meekrijgt, lees je bij change management.
Patroon 3: alles in één keer
Het nieuwe systeem gaat in één keer live, maar het werkproces blijft wat het was. Vaak met een begrijpelijke reden: "onze mensen werken niet met een scanner" of "we willen geen twee manieren van werken". Het oude proces en de logica van het systeem gaan dan met elkaar vechten. Dat gevecht komt terug als meldingen die op storingen lijken.
Het omgekeerde gaat ook mis: de software wordt leidend en het hele bedrijf buigt in één keer mee, omdat het pakket ongeveer past. Tot er van wat je onderscheidend maakte weinig over is.
Wat wel werkt:
- bij de start benoemen welke werkwijze meeverandert, en wat het gevolg is als dat niet gebeurt
- zo standaard als het kan, zo maatwerk als het nodig is
- gefaseerd in gebruik nemen in plaats van alles op één dag
Patroon 4: afvinken bij ingericht
In de lijst met eisen staat iets op opgeleverd, terwijl de oplossing ernaast niet draait, niet meer bestaat of iets anders doet dan gevraagd. Het project sluit op papier. Jij houdt een gat.
Geef elke eis daarom drie standen in plaats van twee:
- ingericht: het systeem kan het
- in gebruik: het team doet het werk ermee
- vervallen of gewijzigd: de eis is herschreven, met de reden erbij
Alleen in gebruik telt als opgeleverd. Wijkt de oplossing af van de eis, herschrijf dan de eis en niet alleen de opmerking. Hoe je een eis toetsbaar opschrijft, lees je bij behoeftes en functionaliteit.
De toets in vier vragen
Leg deze vier vragen naast elke oplevering en elke fase-afsluiting:
- Ligt er een testverslag met namen en datums onder de livegangdatum?
- Is er per proces een key-user met naam, en heeft die de werkinstructie goedgekeurd?
- Is vastgelegd welke werkwijze meeverandert, en wat er gebeurt als dat niet lukt?
- Staat elke afgevinkte eis op in gebruik, of alleen op ingericht?
Is één antwoord nee, dan schuift de datum. Dat voelt streng.
Maar alle vier de patronen komen voort uit goede bedoelingen: elkaar ontzien, tempo houden, niet moeilijk doen over een formaliteit. Beter opletten helpt daar niet tegen. Een toets die blokkeert op een moment dat het nog niets kost, wel.
Wat je vóór de start al kunt doen
Veel oorzaken van een mislukte ERP-implementatie liggen vóór de eerste instelling. Drie dingen helpen dan het meest:
- Zoek de vraag achter de vraag. "We hebben een nieuw systeem nodig" is een oplossing, geen probleem. Vraag eerst waarom je denkt dat dit de oplossing is, voordat iemand gaat rennen.
- Begin bij het knelpunt. Een keten is zo sterk als de zwakste schakel. Wie eerst het proces aanpakt dat de doorstroom bepaalt, ziet sneller effect dan wie overal een beetje verbetert.
- Ga klein en snel live. Het meest prangende proces eerst, per kwartaal het volgende. Elk onderdeel telt pas als het in gebruik is.
Zo werkt het iAi-model: eerst begrijpen, dan inrichten, daarna bouwen. De procesanalyse vooraf wijst het knelpunt aan waar je begint. Of een ERP-implementatie succesvol is, meet je daarna niet aan de livegangdatum, maar aan de vierde vraag van de toets.
Veelgestelde vragen
Hoeveel ERP-implementaties mislukken?
Je vindt percentages in alle soorten en maten, en de bron is vaak niet te herleiden. Wat een mislukking is, verschilt bovendien per onderzoek: te laat, te duur of niet in gebruik. Nuttiger dan een gemiddelde is weten op welk van de vier patronen jouw traject risico loopt. Die vraag kun je vandaag beantwoorden.
Wat is het verschil tussen ingericht en in gebruik?
Ingericht betekent dat het systeem het kan: de instellingen staan en de functie werkt in een test. In gebruik betekent dat de mensen hun werk er aantoonbaar mee doen, met een goedgekeurde werkinstructie en een key-user die erop aanspreekbaar is. Pas in gebruik is iets opgeleverd. Alles daarvoor is nog onderweg.
Kun je een vastgelopen implementatie nog redden?
Vaak wel. Gebruik de vier vragen als nulmeting op wat er nu staat.
Herstel eerst testen en training op de processen die al draaien, voordat er iets nieuws bij komt. Beslis daarbij op wat nu nodig is, niet op wat er al in zit. Een garantie vooraf kan niemand geven, een eerlijk beeld van de stand wel.
Zit je in een traject dat schuurt, of sta je voor een nieuwe start? Plan een kennismaking en leg de vier vragen naast jouw situatie.
