De 5 redenen waarom software-implementaties mislukken (en hoe je ze voorkomt)
Herken de 5 valkuilen die ERP-, CRM- en WMS-implementaties doen ontsporen - en wat je er vóóraf aan doet. Praktisch advies voor directeuren.
Je hebt de keuze gemaakt. Het contract getekend. De kick-off gehad. En nu begint de implementatie - het deel waarover iedereen wist dat het zwaar zou worden, maar waarover niemand je goed had voorbereid.
De meeste implementaties mislukken niet door technische problemen. Ze mislukken door besluiten die weken of maanden eerder al verkeerd waren genomen - of helemaal niet waren genomen. En tegen de tijd dat het zichtbaar wordt, is de schade al opgelopen.
Ik zie dit regelmatig. Niet eén keer, maar als een terugkerend patroon bij bedrijven van 30 tot 150 mensen in productie, logistiek en groothandel. Altijd anders, altijd herkenbaar. Hieronder de 5 redenen die ik het vaakst tegenkom.
Waarom dit zo vaak misgaat
Een implementatie is geen IT-project. Het is een verandering in hoe jouw bedrijf werkt - en die verandering vraagt regie vanuit de directie, niet alleen uitvoering vanuit de leverancier.
Het probleem: de meeste directeuren geven die regie op het moment dat het contract getekend is. Begrijpelijk. Je hebt maanden geïnvesteerd in de keuze. Je bent blij dat het besluit gemaakt is. En nu mag de leverancier het uitvoeren.
Dat is precies het moment waarop het mis begint te gaan.
Reden 1 - De leverancier stuurt, de directeur volgt
De leverancier heeft belang bij een snelle go-live. Zijn projectmanager is er van zijn omzet afhankelijk. Zijn consultants worden betaald per uur of per mijlpaal.
Dat maakt hem geen slechte partij - maar het maakt hem ook niet jouw neutrale adviseur. Toch laten de meeste directeuren de regie volledig bij de leverancier. Ze tekenen het projectplan goed. Ze accorderen de planning. En ze merken pas dat ze de controle zijn kwijtgeraakt als er vertragingen zijn, kosten oplopen, of onderdelen worden "geparkeerd voor fase 2" - die er nooit komt.
"Wij dachten dat de leverancier het allemaal zou regelen. Dat deden ze ook - alleen op hun manier, niet de onze."
Wat je kunt doen: Benoem vóór de start iemand intern die namens jou de regie voert. Dat hoeft geen IT'er te zijn - het moet iemand zijn die beslissingen kan nemen, escalaties doorzet, en wekelijks bijhoudt of het project gaat zoals afgesproken. Als die persoon er intern niet is, is dat het moment voor externe implementatie-regie.
→ Weet je niet of je implementatie op schema ligt? Doe de Software Gereedheidscheck - gratis, in 10 minuten.
Reden 2 - Niemand weet wat "klaar" betekent
In de offerte staat iets als "implementatie van het CRM-systeem inclusief migratie van bestaande klantdata". Maar wat betekent "klaar"? Klaar om te testen? Klaar om live te gaan? Klaar als alle medewerkers ermee werken?
Als dat niet op papier staat - concreet, meetbaar, afgesproken - dan heeft de leverancier zijn eigen definitie van klaar. En die valt bijna altijd net iets ruimer dan die van jou.
Dit is geen onwil. Het is het gevolg van een scopediscussie die nooit is gevoerd. In de verkoopfase praat iedereen over mogelijkheden. In de implementatiefase moet je het hebben over begrenzingen.
Wat je kunt doen: Stel vóór de start drie vragen die je schriftelijk laat beantwoorden: (1) Welke processen werken op go-live-dag volledig in het nieuwe systeem? (2) Welke processen worden pas later gemigreerd, en wanneer? (3) Wat zijn de acceptatiecriteria - hoe weten we dat het goed genoeg is? Als de leverancier die vragen niet concreet kan beantwoorden, is dat het gesprek dat je nú moet voeren.
Reden 3 - Het projectteam is er half bij
Implementaties vragen tijd van je mensen. Niet een uurtje per week - maar structureel, over een langere periode. Sleutelmensen moeten requirements aanleveren, testen, terugkoppelen, collega's begeleiden.
Wat bijna altijd gebeurt: die mensen worden aangewezen als "projectlid", maar hun gewone werk loopt gewoon door. Er is geen tijdsvrijstelling. Er is geen duidelijkheid over prioriteiten. En dus wordt het implementatiewerk er tussendoor gedaan - met alle kwaliteitsconsequenties van dien.
Een Brabantse machinebouwer met 85 mensen zag dit twee jaar geleden fout gaan bij de implementatie van een nieuw WMS. De logistiek manager - sleutelfiguur in het project - moest tegelijk een grote klantorder begeleiden. De testfase werd ingekort. De go-live verliep chaotisch. Drie maanden later draaiden ze nog steeds op halve capaciteit.
Wat je kunt doen: Maak vóór de start een realistisch beeld van wie hoeveel uur per week vrijgemaakt moet worden. Leg dat naast de werkplanning. Als dat niet past: verschuif de go-live, of verschuif ander werk. Beide zijn beter dan doorgaan met een onderbezet projectteam.
