Waarom mislukken zoveel ERP-projecten? De 7 grootste faalfactoren

Onderzoek na onderzoek laat hetzelfde beeld zien: tussen de 55 en 75% van de ERP-implementaties loopt uit op teleurstelling: over budget, over tijd, of ze leveren simpelweg niet op wat vooraf beloofd was. Na 25 jaar ERP-projecten leiden en begeleiden bij diverse bekende organisaties herken ik in vrijwel elk mislukt traject dezelfde patronen terug.

Het goede nieuws: deze faalfactoren zijn voorspelbaar. En wat voorspelbaar is, is te voorkomen. Hieronder de zeven oorzaken die ik het vaakst tegenkom, en wat je er zelf aan kunt doen.

1. Onrealistische planning

De planning van een ERP-project wordt bijna altijd gemaakt vóórdat de organisatie echt weet hoe complex het traject is. Leveranciers presenteren een planning die “haalbaar” is als alles meezit. En er zit bijna nooit iets mee.

Wat je hieraan kunt doen: bouw de planning “bottom up” op, nagenoeg ieder ERP project wordt vanuit de leverancier “hoog-over” gepland. Dat is natuurlijk een prima begin, maar in de meeste gevallen niet haalbaar. Door een gedetailleerde planning te maken met een realistische inschatting van het werk (in mandagen), de beschikbare medewerkers en de taakafhankelijkheden krijg je een haalbare planning.

Plan expliciet momenten in om de planning te herijken op basis van voortschrijdend inzicht. Een planning die nooit wordt aangepast is geen planning, het is een wens.

2. Onvoldoende betrokkenheid van de business

ERP-projecten worden vaak gezien als IT-projecten met een “Finance” achtergrond en dus overgelaten aan de IT- en Financeafdeling. Maar een ERP-systeem verandert hoe mensen op de werkvloer hun werk doen. Als de brede business pas bij de testfasen voor het eerst echt meekijkt, is het al te laat.

Wat je hieraan kunt doen: zorg dat proceseigenaren uit de business vanaf dag één in de stuurgroep en werkgroepen zitten. Niet als vinkje op een presentielijst, maar met echte beslissingsbevoegdheid.

3. Scope creep

Tijdens een implementatie ontstaan voortdurend nieuwe wensen: “kunnen we deze rapportage er ook nog bij doen?”, “zou het niet handig zijn als…” Elke wens op zich lijkt klein. Bij elkaar opgeteld ontsporen ze de planning en het budget.

Wat je hieraan kunt doen: richt een lichte maar strikte change-procedure in vanaf de start. Elke scopewijziging krijgt een impactanalyse op tijd, budget en risico voordat hij wordt goedgekeurd. Geen uitzonderingen, ook niet voor “kleine” verzoeken.

4. Zwakke data governance en migratie

Data-migratie wordt structureel onderschat. Organisaties gaan er vaak vanuit dat data “gewoon overgezet” kan worden, terwijl in de praktijk data verspreid over meerdere systemen staat, inconsistent is, of simpelweg niet meer klopt.

Wat je hieraan kunt doen: start de data-opschoning ruim vóór de eigenlijke migratie, niet pas in de weken ervoor. Wijs een eigenaar aan per databron die verantwoordelijk is voor de kwaliteit van die data.

5. Onderschatting van change management

Een ERP-systeem kan technisch perfect werken en toch mislukken, simpelweg omdat medewerkers het niet gebruiken zoals bedoeld, of star vasthouden aan hun oude manier van werken. Change management wordt vaak behandeld als bijzaak, terwijl het net zo bepalend is voor succes als de techniek zelf.

Wat je hieraan kunt doen: zorg voor een goede change management aanpak met zichtbaar sponsorship vanuit het management als volwaardig onderdeel van de projectplanning, met voldoende budget en concrete mijlpalen.

6. Onduidelijke rolverdeling

Wie is verantwoordelijk voor wat? In veel ERP projecten wordt ervan uitgegaan dat de leverancier het grootste deel van het werk voor zijn rekening neemt en sturing geeft. Dit is helaas maar deels waar; de klant zal minstens zoveel (en vaak méér) uren aan het project moeten besteden als de leverancier.

Wat je hieraan kunt doen: leg rolverdeling en verantwoordelijkheden expliciet vast, inclusief een RACI-matrix (wie is Responsible, Accountable, Consulted, Informed) voor de belangrijkste opleveringen met daarbij een inschatting van de “effort” die nodig is.

7. Te veel vertrouwen op de leverancier in plaats van eigen regie

Dit is misschien wel de meest onderschatte faalfactor: organisaties leunen volledig op hun ERP-leverancier voor advies over de aanpak, planning en risico’s. Maar een leverancier heeft belang bij het verkopen van het project, en niet per definitie bij een aanpak die het beste bij jouw organisatie past.

Wat je hieraan kunt doen: houd zelf de regie over projectaanpak en planning, en haal waar nodig onafhankelijk advies binnen dat geen commercieel belang heeft bij een specifiek pakket of module. Je kunt ERP niet zien als een “kant en klare” service die je koopt, ondanks de belofte van standaard “best practices”.

Wat deze factoren gemeen hebben

Geen van deze zeven punten gaat over techniek. Ze gaan allemaal over projectaanpak, sturing en organisatie. Precies het gebied waar een standaard projectmanagementaanpak vaak tekortschiet, omdat ERP-implementaties hun eigen specifieke dynamiek hebben.

Wil je deze valkuilen structureel vermijden in plaats van ze pas te herkennen als het al misgaat? In de Basis ERP Projectmanagement Training behandelen we elk van deze zeven punten met concrete templates, checklists en een realistische planningsaanpak, gebaseerd op 25 jaar praktijkervaring bij implementaties die wél slaagden.

Meer over de Basis ERP Projectmanagement Training