Een ERP-implementatie begint vaak met dezelfde vraag: welke risico's kunnen het succes van dit project in de weg staan?
Als implementatiepartner van Odoo doen we al jarenlang implementaties van verschillende omvang en complexiteit. In de praktijk zien we steeds dezelfde projectrisico's terugkomen.
Een ERP-implementatie gaat namelijk niet alleen over software. De grootste risico's ontstaan vaak in de organisatie zelf: medewerkers worden onvoldoende betrokken, de scope groeit tijdens het project en taken worden niet op tijd gevalideerd.
1. Medewerkerbetrokkenheid
Het implementeren van een ERP-systeem is vaak niet de keuze van de medewerkers die ermee moeten werken.
Ze zijn gewend aan het huidige pakket. Ze kennen de dagelijkse werkzaamheden en hebben vaak eigen workarounds gevonden om hun werk gedaan te krijgen.
Een nieuw systeem kan daarom onzekerheid oproepen. Medewerkers vragen zich af wat er verandert en of ze straks nog even goed kunnen werken.
Daarom begint betrokkenheid bij een duidelijke visie van de directie. Er is een reden om nieuwe software te kiezen. Het is belangrijk dat de directie uitlegt waarom die keuze is gemaakt en hoe het nieuwe systeem de toekomst van het bedrijf ondersteunt.
Wie medewerkers wil betrekken bij een ERP-implementatie, wacht daar dus niet mee tot de training. Betrek key-users al tijdens de pakketselectie en vraag hun inbreng bij belangrijke keuzes.
Breng ook de sterke punten van het huidige pakket in beeld. Die informatie helpt om tijdens de inrichting en training beter aan te sluiten bij wat medewerkers belangrijk vinden.
Weerstand komt bovendien vaak voort uit onzekerheid. Iemand kan zijn of haar werk vandaag goed uitvoeren en moet ineens werken met software die nog onbekend is.
Het is dan niet verstandig om het oude systeem volledig na te bouwen. Medewerkers moeten leren werken met de nieuwe software en begrijpen waarom bepaalde processen veranderen.
Daarom besteden we veel aandacht aan training en overdracht. In onze aanpak gebruiken we onder meer het train-the-trainer-principe. Zo is er binnen de organisatie iemand die eerstelijns ondersteuning kan geven aan collega's.
Als een key-user een proces aan een collega kan uitleggen, weten we bovendien dat de kennis goed is overgedragen. Het is verstandig om al vroeg te beginnen met werkinstructies die door en voor medewerkers worden geschreven.
Een acceptatietest, ondersteuning tijdens de livegang en begeleiding na de livegang helpen medewerkers om met vertrouwen te starten. Wie medewerkers pas op het laatste moment informeert, maakt de overgang onnodig lastig.
2. Scope en maatwerk
Voor de start van een implementatie proberen we een realistisch budget af te geven. Dat budget is gebaseerd op de gesprekken en keuzes die vooraf zijn gemaakt.
Tijdens het project ontstaan bijna altijd nieuwe wensen. Voortschrijdend inzicht en feedback van medewerkers kunnen zorgen voor veranderende requirements.
Dat is op zichzelf niet verkeerd. Het risico ontstaat wanneer iedere nieuwe wens direct aan het project wordt toegevoegd.
Door met alle wensen mee te gaan, krijg je al snel budgetoverschrijdingen. Dat betekent niet automatisch dat je ook een beter systeem krijgt.
Daarom starten we bij voorkeur met een zo klein mogelijke implementatie. We blijven dicht bij de standaard en richten eerst de applicaties in waarmee jouw bedrijf geld verdient.
We gaan niet zomaar mee met iedere wens. Eerst willen we begrijpen waarom een aanpassing nodig is en welk probleem ermee wordt opgelost.
Door eerst te leren werken met het nieuwe pakket zoals het bedoeld is, worden toekomstige wensen beter zichtbaar. Zo voorkom je dat je het oude pakket opnieuw aan het bouwen bent.
Ook maatwerk proberen we tot een minimum te beperken. Dat maakt het systeem goedkoper en beter beheersbaar. Het wordt eenvoudiger om medewerkers te trainen en een toekomstige versie van Odoo te gebruiken.
In onze ervaring blijkt na drie tot zes maanden werken met het systeem dat ten minste 50% van het gemaakte maatwerk overbodig wordt gevonden. Daarom adviseren we om de standaard eerst een goede kans te geven.
Meer over deze afweging lees je in onze blog over de voor- en nadelen van maatwerk.
Maatwerk kan natuurlijk de juiste oplossing zijn. Maar dan moet duidelijk zijn waarom standaard Odoo of een andere werkwijze niet voldoende aansluit. De vraag is niet alleen of iets technisch mogelijk is, maar ook wat het jarenlang kost om de oplossing te onderhouden, testen en ondersteunen.
3. Projecttaken valideren
Wanneer we starten met een project, maken we een projectplan op basis van de offerte. Dat plan vormt de basis voor de implementatie.
Het projectplan geeft inzicht in de voortgang, maakt duidelijk welk werk nog openstaat en helpt om het budget te bewaken. Het is ook een belangrijk communicatiemiddel tussen de klant en de implementatiepartner.
Een projecttaak is pas afgerond wanneer de klant het resultaat heeft gevalideerd en goedgekeurd. Het werk van de consultant kan klaar zijn, maar daarmee is de taak nog niet automatisch opgeleverd.
Juist daar ontstaat in de praktijk een belangrijk risico. Wanneer iemand akkoord geeft op een resultaat, neemt die persoon ook verantwoordelijkheid voor die keuze.
Dat kan best spannend zijn. Medewerkers kunnen daardoor het valideren van taken uitstellen. Zo ontstaat een lange lijst met openstaande taken waarvan niet duidelijk is hoeveel werk er nog achter zit.
Om dit te voorkomen, leggen we tijdens het project veel nadruk op validatie. Soms voeren we tests samen met de betreffende medewerker uit. Wanneer validatie uitblijft, moet er worden geëscaleerd.
De leden van het projectteam moeten voldoende kennis hebben om de processen te testen. Ze moeten daarnaast genoeg mandaat hebben om beslissingen te nemen en akkoord te geven.
Ook een goede projectleider bij de klant is belangrijk. Deze persoon begeleidt de implementatie intern en motiveert projectleden om te testen en te valideren.
De projectleider moet bovendien voldoende mandaat hebben om actie te vragen wanneer taken blijven liggen. Deze persoon is het centrale aanspreekpunt, ofwel de SPOC: de single point of contact.
In onze Odoo-projectaanpak leggen we daarom vooraf vast wie beslist, wie test en wie verantwoordelijk is voor de validatie. Zo blijft het project niet alleen bij de implementatiepartner liggen.
Beperk projectrisico's voordat ze problemen worden
De drie grootste projectrisico's zijn goed te herkennen:
onvoldoende betrokkenheid van medewerkers;
een scope die steeds verder groeit met wensen en maatwerk;
projecttaken die niet op tijd worden getest en gevalideerd.
Door hier vooraf rekening mee te houden, krijgt een ERP-implementatie een veel betere kans van slagen.
Zorg voor een duidelijke visie van de directie. Betrek key-users en medewerkers op tijd. Begin met een beheersbare scope en geef de standaard eerst een eerlijke kans.
Maak daarnaast duidelijk wie verantwoordelijk is voor testen, beslissingen en goedkeuring. Een ervaren implementatiepartner kan helpen om deze risico's zichtbaar te maken, maar het project blijft een gezamenlijke verantwoordelijkheid.
Een ERP-implementatie is pas succesvol wanneer niet alleen de software is ingericht, maar medewerkers ermee kunnen werken en de organisatie het resultaat heeft gevalideerd.
