Drie valkuilen (en tips) bij de start van een ERP implementatie

De kogel is door de kerk. Jouw organisatie heeft besloten om de huidige systemen te vervangen en te starten met een ERP implementatie. Iedereen kent wel een verhaal van zo’n implementatie die tergend lang heeft geduurd of de nodige bedrijfsellende heeft veroorzaakt toen ze eenmaal overgingen. Zelden hoor je verhalen over een ERP implementatie die precies volgens het initiële plan en budget verloopt. Hoe komt dat? In dit artikel gaan wij in op drie valkuilen die vaak al in het begin van het ERP traject worden gemaakt.

Resource beschikbaarheid

Met stip op nummer 1 van de valkuilenlijst staat beschikbaarheid van de mensen in het project team. Bij zo goed als alle ERP implementaties wordt er voortvarend gestart met mensen uit de operatie aan te wijzen voor het interne project team. Het is van belang om duidelijke afspraken te maken over de tijd die de projectleden aan het ERP project zullen spenderen. Er van uitgaan dat ze dit naast hun bestaande werkzaamheden zullen doen, is dodelijk voor een ERP project.

Het management laat vaak na om backfill te organiseren voor deze mensen. Zeker aan het begin van het project lijkt de inzet vaak mee te vallen en slagen mensen er nog in om het met hun dagelijkse operationele taken te combineren. Echter, naarmate een ERP project vordert, worden ze steeds dieper in de materie getrokken en is absolute focus noodzakelijk. Het continu moeten schakelen tussen operatie en het project zorgt vaak voor veel snijverlies maar vooral ook frustratie  bij de betrokken medewerker omdat hij/zij op beide vlakken voelt alsof hij steken laat vallen (en dat is ook vaak zo).

Eén van de randvoorwaarden voor een succesvolle ERP implementatie begint dan ook bij het management. Zorg dat er vanaf de start van het project backfill wordt geregeld voor die afdelingen waar de projectleden ook in de operatie een onmisbare rol vervullen. Wacht daar niet mee tot het daadwerkelijk escaleert, want het kan vaak best enige tijd duren voordat je een goede kandidaat hebt gevonden. Daarnaast kost het inwerken van zo’n backfill ook tijd en dat besteed je liever in het begin van het traject, dan op het moment dat iemand al in een squeeze zit.

En ja, we horen je denken dat backfills het budget aanzienlijk gaan verhogen. Dat is zeker zo. Echter, het moeten implementeren van een ERP systeem zonder een goed project team leidt gegarandeerd tot aanzienlijke vertraging en waarschijnlijk mislukking van het project. Het behoeft geen rekensom om het belang te zien van dit goed regelen aan de start van het project.

Duidelijke scope

Een tweede valkuil is de scope van het project. Wat zal de ERP software omvatten maar vooral, wat zal het niet omvatten? Een duidelijke functionele omschrijving is nodig om aan het begin van het traject scherp te hebben wat er uiteindelijk opgeleverd wordt. Dat is van belang voor verschillende redenen.

Enerzijds is een duidelijke scope de leidraad tijdens het traject om discussies rondom functionaliteit te kaderen. Is de vraag tot deze functionaliteit onderdeel van de scope omschrijving? Zoniet, dan zal er een change request (veranderverzoek) ingediend moeten worden zodat de project stuurgroep duidelijk akkoord geeft voordat er verder tijd aan wordt gespendeerd. De impact op tijd, inzet en planning moet helder zijn. Dat is de enige manier om te voorkomen dat er wildgroei plaatsvindt aan functionaliteit en de planning onbeheersbaar wordt.

Anderzijds is een duidelijke scope omschrijving cruciaal om de impact op de organisatie goed te kunnen bepalen. Wat betekent deze scope voor het bedrijf? Welke processen veranderen, welke blijven hetzelfde? Wat houdt dat precies in voor de mensen in de organisatie? Met deze kennis kan al vroeg in het ERP traject gekeken worden naar de verandering voor de organisatie. Op basis daarvan kan een veranderaanpak worden opgesteld.

Verder zien we ook vaak gebeuren dat de scope misschien wel helder is, maar dat er onduidelijkheid is of de optimalisatie van de processen onderdeel is van de ERP implementatie. Met andere woorden, zorgen we ervoor dat onze huidige manier van werken straks op dezelfde wijze in het ERP project wordt afgedekt, of zorgen we ervoor dat we onze huidige processen verbeteren en deze nieuwe werkwijze in het ERP pakket inbouwen. Dat is een fundamenteel andere aanpak in de implementatie. In het laatste geval moet het project team (vaak samen met een externe partij) de huidige processen evalueren en tot het optimale proces komen. Daar moet intern overeenstemming over zijn voordat er gestart wordt met de ERP implementatie.

Ook als het uitgangspunt is dat er geen procesoptimalisatie zal plaatsvinden, laat de praktijk zien dat het toch vaak gebeurt.  Sommige processen worden aangepast omdat de software niet in staat is om met de bestaande werkwijze om te gaan. Dat is op zich prima zolang er expliciet wordt gemaakt wat dit betekent voor de bestaande afdelingen. Zijn er organisatie aanpassingen nodig of niet? Hier moet voldoende aandacht voor zijn om niet aan het einde van het traject voor verrassingen komen te staan.

Kortom: werk aan een duidelijke scope omschrijving en wees expliciet over welke processen je wel / niet wil optimaliseren voordat je de ERP implementatie start.

Het is géén IT project!

Simpel. Een ERP project is geen IT project. Het dekt vaak zo goed als alle bedrijfsprocessen af in je organisatie en dus zijn mensen uit de business diegene die betrokken moeten zijn en keuzes moeten maken. Natuurlijk heeft een ERP project een IT component in zich. Het pakket moet straks beheerd worden, er kunnen afspraken nodig zijn over release management, over het beheer van de omgevingen. Er zal ook kennis gevraagd worden over hoe de huidige systemen en aanpalende pakketten werken om de integraties goed te krijgen. Echter, de IT afdeling kan en mag nooit in de lead zijn bij een ERP project.  Als dat wel zo is, dan worden de keuzes niet vanuit een business bril gemaakt maar vanuit een IT bril. Dat zal leiden tot een organisatie die zich niet herkent in het systeem, wat onvermijdelijk leidt tot een mislukking van het project.

Management betrokkenheid is dan ook een randvoorwaarde. Vanuit alle relevante bedrijfsprocessen dient een management lid in de stuurgroep te zitten. Daarnaast is actieve betrokkenheid en communicatie cruciaal om het doel van deze ERP implementatie helder over de bühne te krijgen bij de medewerkers. Alleen op die manier begrijpt de organisatie dat het “not just another project” is maar het cruciaal is voor de bedrijfsvoering, nu en in de toekomst.

Conclusie

Kortom, “bezint eer u begint”! Besteed aan de start van het traject voldoende tijd aan het inrichten van een goed project team en vul de randvoorwaarden goed in om dit team succesvol te kunnen laten zijn. Zorg dat het management actief is betrokken en last but not least, neem de tijd om een heldere scope afbakening te doen. Drie uitermate belangrijke tips om goed van start te gaan met een ERP implementatie.