De 5 redenen waarom software-implementaties mislukken (en hoe je ze voorkomt)
Wat er misgaat tijdens een implementatie, wordt beslist in de weken tussen de handtekening en de kick-off. Dit zijn de vijf besluiten.
In dit artikel:
Je hebt getekend. De kick-off staat over drie weken in de agenda. Dat is het moment waarop de meeste implementaties al grotendeels bepaald zijn, en precies het moment waarop bijna niemand nog iets doet.
De meeste implementaties mislukken niet door techniek. Ze mislukken door vijf besluiten die in de weken tussen de handtekening en de kick-off genomen hadden moeten worden, en die toen niemand heeft genomen. Tegen de tijd dat je ze mist, liggen de planningen er al omheen.
Dit artikel is voor de ondernemer die net getekend heeft en nog niet begonnen is. Zit je er al middenin en voelt het niet goed, dan komt dit artikel voor jou te laat. Lees dan hoe onafhankelijke regie werkt bij ERP, CRM of WMS.
Waarom juist die weken bepalend zijn
Omdat je in die weken nog invloed hebt op afspraken die daarna vastliggen.
Er gebeurt iets voorspelbaars zodra het contract getekend is. Je hebt maanden in de keuze gestoken, het besluit is genomen, en de opluchting is echt. Vanaf dat moment mag de leverancier het uitvoeren. Dat voelt logisch en het is precies waar het 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.
Na de kick-off wordt elke afspraak duurder om te veranderen. Er ligt een planning, er staan mensen ingeroosterd, en wie dan nog iets wil bijstellen krijgt te horen dat het meerwerk is. In de weken ervoor kost hetzelfde besluit je een gesprek.
Reden 1: de regie is nooit belegd
Zonder iemand die namens jou de regie voert, voert de leverancier hem.
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 ondernemers de regie volledig bij hem liggen. Ze keuren het projectplan goed, ze accorderen de planning, en ze merken pas dat ze de controle kwijt zijn als er 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."
Het besluit: wijs voor de kick-off iemand intern aan 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 loopt zoals afgesproken. Is die persoon er intern niet, dan is dit het moment om regie van buiten te halen.
Reden 2: niemand heeft afgesproken wat "klaar" betekent
Zonder een gedeelde definitie van klaar geldt die van de leverancier, en die valt bijna altijd net iets ruimer uit dan die van jou.
In de offerte staat iets als "implementatie inclusief migratie van bestaande klantdata". Maar wat is klaar? Klaar om te testen? Klaar om live te gaan? Klaar als alle medewerkers er dagelijks in werken?
Dit is geen onwil. Het is het gevolg van een scopegesprek dat nooit is gevoerd. In de verkoopfase praat iedereen over mogelijkheden. Vanaf nu moet je het hebben over begrenzingen, en dat gesprek voert niemand uit zichzelf.
Het besluit: laat drie vragen schriftelijk beantwoorden voordat je begint. Welke processen werken op go-live-dag volledig in het nieuwe systeem? Welke pas later, en wanneer? Waaraan zien we dat het goed genoeg is? Kan de leverancier die vragen niet concreet beantwoorden, dan is dat het gesprek dat je nú voert.
Reden 3: de uren van je mensen zijn nooit echt vrijgemaakt
Een implementatie vraagt structureel tijd van je sleutelmensen, en die tijd komt nergens vandaan als je hem niet weghaalt bij hun gewone werk.
Wat bijna altijd gebeurt: mensen worden aangewezen als projectlid en hun normale werk loopt gewoon door. Geen vrijstelling, geen duidelijkheid over prioriteit. Het implementatiewerk wordt er tussendoor gedaan.
Dit is het patroon dat ik het vaakst zie: de sleutelfiguur in het project krijgt tegelijk een grote klantorder op zijn bord. De testfase wordt ingekort omdat er geen ruimte is. De go-live verloopt rommelig, en maanden later draait de afdeling nog op halve kracht. Niemand heeft een fout gemaakt. Er was gewoon geen tijd ingepland.
Het besluit: zet op papier wie hoeveel uur per week vrijgemaakt wordt, en leg dat naast de werkplanning. Past het niet, dan verschuif je de go-live of je verschuift ander werk. Allebei is beter dan doorgaan met een onderbezet team.








