Als implementatiepartner van Odoo doen wij al 12 jaar implementaties van allerlei soorten en maten in verschillende industrieën en variërende complexiteit. Bij de start van ieder project krijgen wij altijd dezelfde vraag “wat zijn de risico’s die het succes van dit project in de weg staan?”. Om deze vraag te beantwoorden zetten we in deze blog de 3 belangrijkste risico’s voor het succes van een project op een rijtje.
1. Medewerker betrokkenheid
Het implementeren van een ERP-systeem is vaak niet de keuze van de medewerkers die ermee moeten gaan werken. In veel gevallen zijn deze medewerkers gewend aan het pakket dat vervangen gaat worden en weten zij nu hun dagelijkse werk (vaak met een hoop “workarounds”) te doen. Er bestaat in de ogen van deze medewerkers een risico dat dit gaat veranderen en dat zij daarop afgerekend gaan worden. In onze implementaties proberen wij hier vanaf het offertestadium al rekening mee te houden.
Het start met een sterke visie van de directie. Er is met een reden gekozen om met nieuwe software te gaan werken en het is belangrijk dat de directie naar de medewerkers uitdraagt dat dit de toekomst is van het bedrijf. Als de medewerkers het belang van de implementatie begrijpen en weten dat de keuze is gemaakt, leid dit vanzelf tot meer betrokkenheid van de medewerkers.
Als we het hebben over betrokkenheid zullen mensen altijd harder werken voor iets waar ze zelf onderdeel van zijn en een belang in hebben. Als iets opgelegd wordt zonder dat er input is gevraagd zal dit altijd tot weerstand leiden. Probeer in de pakketselectie een aantal key-users al om inbreng te vragen en breng voor de gebruikers de positieve punten van het huidige pakket goed in beeld. Dit zijn de punten waar wij bij de training en implementatie rekening mee kunnen houden door zo veel mogelijk de vragen voor te zijn en de nadruk te leggen op deze aspecten van de software.
Als laatste is het heel vaak zo dat de weerstand eigenlijk voortkomt uit onzekerheid. Iemand kan op dit moment heel goed zijn of haar werk uitvoeren en moet nu ineens met software gaan werken die zij helemaal niet kennen. Het is altijd een fout om het oude systeem na te gaan maken, dus de medewerkers zullen moeten wennen aan het nieuwe systeem. Dit is ook de reden dat wij enorm veel nadruk leggen op de training en de overdracht naar de medewerkers. Wij hanteren hierbij het “train the trainer” principe. Dit heeft als voordeel dat er binnen de organisatie in ieder geval 1 persoon is die de eerstelijns ondersteuning kan doen en als deze persoon het aan een collega kan uitleggen hebben wij ook gevalideerd dat de kennis vanuit ons goed is overgedragen. Daarbij is het aan te raden om vroeg te beginnen met het schrijven van werkinstructies door en voor de medewerkers. Een acceptatietest, go-live support op locatie en ondersteuning na de go-live zijn allemaal onderdeel van de implementatie waardoor de medewerkers met vertrouwen kunnen starten in het nieuwe systeem.
2. Uitbreiden van de scope en maatwerk
Voor de start van de implementatie proberen wij altijd een realistisch budget af te geven. Dat budget is gebaseerd op de gesprekken vooraf, maar er komen ongetwijfeld tijdens de implementatie nieuwe wensen naar voren. Voortschrijdend inzicht en feedback van medewerkers kunnen bijvoorbeeld zorgen voor veranderende requirements. Door mee te gaan met alle wensen krijg je altijd budgetoverschrijdingen, maar niet per se een beter systeem.
Als eerste starten wij altijd met een zo klein mogelijke implementatie. We blijven dicht bij de standaard en implementeren de applicaties waar jouw bedrijf het geld mee verdient. Wij zullen niet zomaar meegaan met de wensen, maar willen overtuigd worden van de noodzaak. Door eerst te leren om gebruik te maken van het nieuwe pakket zoals het bedoeld is kunnen toekomstige wensen veel beter geïdentificeerd worden en kan worden voorkomen dat we het oude pakket aan het namaken zijn.
Vervolgens zal onze insteek altijd zijn om het maatwerk tot een minimum te beperken. Een uitgebreide toelichting hierop kun je hier vinden in ons blog, waar we de voors en tegens van maatwerk beschrijven. Een beknopte versie is dat het goedkoper, beter beheersbaar, makkelijker te trainen en beter te migreren is naar een toekomstige versie.
Na een periode van 3-6 maanden werken met het systeem is onze ervaring dat ten minste 50% van het gemaakte maatwerk als overbodig wordt gezien, daarom adviseren wij altijd om eerst zo veel mogelijk de standaardversie een kans te geven en later verder uit te breiden.
3. Valideren van de projecttaken
Wanneer wij starten met een project maken wij een projectplan op basis van de afgegeven offerte. Dit projectplan vormt de basis voor de implementatie. Het dient als communicatiemiddel tussen de partijen, als registratie van de voortgang, als leidraad voor het overgebleven werk en speelt een belangrijke rol in de budgetbewaking. Wanneer alle taken zijn afgerond houdt dit in dat het project is opgeleverd.
Het afronden van de taken is niet wanneer de consultant klaar is met het werk, maar wanneer de klant het werk heeft gevalideerd en akkoord heeft gegeven op het resultaat. Hier zit ook meteen een van de grootste risico’s voor het project.
Wanneer er gevraagd wordt aan iemand om akkoord te geven op het werk dragen zij ook een bepaalde verantwoordelijkheid voor dit resultaat. Dit is voor ons enorm belangrijk, maar voor sommige medewerkers ook best wel spannend. Dat kan ervoor zorgen dat er een opbouw aan taken staat die nog gevalideerd moeten worden waar potentieel dus een grote hoeveelheid werk in kan zitten die onmogelijk te plannen is.
Om dit te voorkomen proberen wij zo veel mogelijk de nadruk op de validatie van de taken te leggen. Dat houdt soms in dat we samen met de betreffende medewerker de tests uitvoeren, of escaleren wanneer de validatie niet gebeurt. Het is dus enorm belangrijk dat de leden van het projectteam capabel zijn om de validatie uit te voeren en voldoende mandaat hebben om beslissingen te nemen.
Daarbij is het ook aan te raden om een goede projectleider aan te stellen bij de klant. Deze is verantwoordelijk voor het begeleiden van de implementatie en om intern de projectleden te motiveren om te testen en te valideren. Deze persoon moet ook voldoende mandaat hebben binnen de organisatie om te kunnen escaleren wanneer er actie moet worden ondernomen. Deze persoon noemen wij ook wel de SPOC of “single point of contact”.
Door voor de start van de implementatie goed na te denken over deze risico’s en de juiste mensen in het projectteam te zetten en de implementatie te doen met een ervaren partner als Odoo Experts, krijgt het project de beste kans van slagen.
De drie grootste projectrisico's