Waarom het beste ERP-systeem ter wereld faalt (als je niet weet hoe je moet luisteren)

(Deel 1 van 5 van de serie "De menselijke code van ERP")

Je kunt je ERP-systeem perfect configureren. Maar als een magazijnmanager je niet vertrouwt, is je miljoenenproject al bij voorbaat gedoemd te mislukken. Dit is de harde, onuitgesproken waarheid over ERP-implementaties.

De echte reden waarom gebruikers nee zeggen

Enkele jaren geleden, tijdens de ontwerpfase bij een klant, zag ik een bekende blik in de ogen van een van de gebruikers. Het was die klassieke mix van scepsis en verveling, alsof iemand voor de honderdste keer hetzelfde oude bedrijfsverhaal hoorde.

Na een tijdje gepraat te hebben, pauzeerde ik en vroeg of hij nog iets wilde toevoegen. Hij kruiste zijn armen, een klassiek teken van ontkenning in de gedragspsychologie, en verklaarde botweg dat het nieuwe ERP-systeem nooit zou werken. Het was "te generiek", betoogde hij, en negeerde volledig de talloze specifieke kenmerken die hun bedrijf uniek maakten.

Ik besefte toen meteen dat zijn kritiek gericht was op de enorme, overweldigende verandering die achter de software schuilging.

En op dat moment werd ik herinnerd aan de gouden regel van de consultancy: slechte psychologie legt meer ERP-projecten plat dan slechte code ooit zal doen.

Welkom bij het eerste deel van De Menselijke Code van ERP, een serie die volledig is gewijd aan de mensen die daadwerkelijk op de toetsen moeten drukken, en die verder kijkt dan de bits, bytes en API's van ons werk. Vandaag hebben we het over de moeilijkste barrière om te doorbreken bij elke softwaremigratie: de muur van "zo hebben we het altijd al gedaan".

Het verdriet van het Legacy-systeem

Wanneer een bedrijf besluit zijn ERP-systeem te vervangen, ziet het management een verbetering. Ze zien realtime data, AI-functionaliteit en gestroomlijnde processen.

Voor de eindgebruiker voelt de overstap naar een ander ERP-systeem als een ingrijpend verlies van identiteit. In het beste geval zien ze het als tijdverspilling, omdat ze alle benodigde stappen in het oude systeem al uit hun hoofd kennen. De gedachte alleen al dat ze iets compleet nieuws vanaf nul moeten leren, wordt eerder als een straf ervaren dan als een echte manier om hun dagelijkse workflow te verbeteren.

Denk er eens over na. De ervaren key user uit mijn verhaal had twintig jaar lang de eigenaardigheden van het oude systeem onder de knie gekregen. Hij wist precies welke sneltoetsen hij moest gebruiken om een ​​systeemvergrendeling te omzeilen. Hij wist hoe hij een rapport kon genereren waar zijn collega's dol op waren.

Zijn expertise, zijn waarde voor het bedrijf en zijn dagelijkse zelfvertrouwen waren onlosmakelijk verbonden met die verouderde software.

Wanneer wij, de consultants, de ruimte binnenkomen en aankondigen dat het management heeft besloten om de nieuwe functionaliteiten van een moderner ERP-systeem te gaan gebruiken dan het huidige, brengen we hun competentieniveau direct terug naar nul en veranderen we tegelijkertijd hun tools. We veranderen de onbetwiste meester van de afdeling in een verwarde beginner.

Dit roept een reactie op die identiek is aan de fasen van rouwverwerking:

  1. Ontkenning: "Dit nieuwe systeem is slechts een modegril, het management zal het afschaffen zodra ze de kosten zien."

  2. Woede: "Deze interface is waardeloos! Je moet drie keer klikken in plaats van één keer!"

  3. Onderhandelen: "Kunnen we het nieuwe systeem gewoon zo aanpassen dat het er precies hetzelfde uitziet als het oude?"

  4. Depressie: "Ik weet niet meer hoe ik mijn werk moet doen."

  5. Acceptatie: "Oké, laat me zien hoe dit nieuwe dashboard werkt."

Naast het in kaart brengen van gegevenstabellen, is het onze taak als ERP-consultants om gebruikers zo snel en probleemloos mogelijk door deze vijf fasen te begeleiden. We zijn veranderingspsychologen vermomd als ERP-experts.

De 20/80-regel voor luisteren

De grootste fout die veel consultants maken, is dat ze een vijandige gebruiker proberen te overtuigen door zich te veel te richten op de technische kenmerken van de software in plaats van op de daadwerkelijke bedrijfsprocessen.

Ze openen de software, projecteren deze op het scherm en beginnen te vertellen hoe de nieuwe, uniforme logistieke oplossing voor meerdere locaties aanzienlijk beter is. Vol trots leggen ze uit hoe het een enkele, uniforme container voor stamgegevens creëert, waardoor het niet meer nodig is om telkens in en uit te loggen bij verschillende bedrijven.

De gebruiker dwaalt af. Ze geven niets om uw masterdata-architectuur. Het enige waar ze om geven, is dat ze om 17:00 uur weg moeten om hun kinderen op te halen, en uw nieuwe systeem lijkt ervoor te zorgen dat ze tot 19:00 uur op kantoor moeten blijven.

Om weerstand te overwinnen, moet je de 20/80-regel van ERP-workshops:

  • Besteed 20% van de tijd aan het uitleggen hoe het nieuwe systeem werkt.

  • Besteed 80% van de tijd aan zwijgen en luisteren naar hoe ze daadwerkelijk te werk gaan.

Voordat je een oplossing voorstelt in Infor LN of een ander ERP-systeem, moet je vragen stellen. Wat is het meest frustrerende onderdeel van je maandagochtend? Waarom exporteer je deze lijst elke week naar Excel? Welke informatie ontbreekt er op dit scherm waardoor je de magazijnafdeling moet bellen?

Wanneer een gebruiker beseft dat je oprecht geïnteresseerd bent in de pijn van hun dagelijkse routine en hun perspectief wilt begrijpen, beginnen hun verdedigingsmechanismen af ​​te brokkelen. Ze zien je niet langer als een indringer, maar als een partner.

De ultieme bugfix: vertrouwen

In mijn vorige serie over datamigratie sprak ik over het principe 'garbage in, disaster out' met betrekking tot datakwaliteit. Hetzelfde geldt voor menselijke relaties. Als de relatie vanaf dag één giftig is, zal de implementatie een ramp worden.

Hier is een niet-geheim dat iedereen altijd moet onthouden: als gebruikers je vertrouwen, zullen ze de gebreken van de software vergeven. Als ze een hekel aan je hebben, zullen ze elke kleine bug tegen het project gebruiken.

Tijdens een implementatie zullen misgaan. Er zullen fouten optreden. Processen zullen even stilvallen. Als de magazijnmanager je vertrouwt omdat je urenlang naast hem op een heftruck hebt gezeten om zijn processen te begrijpen, zal hij naar een foutmelding kijken en zeggen: "Hé, hier is een probleem, laten we het oplossen."

Maar als je arrogant te werk gaat, zijn input negeert en hem een ​​standaardprocedure opdringt, zal hij naar precies hetzelfde foutscherm kijken, zijn armen over elkaar slaan, de CEOen schreeuwen: "Ik zei toch dat dit ERP-systeem waardeloos was!"

Vertrouwen is de ultieme schokdemper voor de livegang. En vertrouwen kun je niet instellen in een softwaremenu. Je moet het opbouwen, persoonlijk, maanden vóór de overstap.

De muur doorbreken

Hoe bouw je in de praktijk vertrouwen op en overwin je de weerstand van de meest lastige Key Users? Hier zijn drie concrete stappen die je in je volgende project kunt implementeren:

1. Schaduwen maken vóór het maken van een blauwdruk

Begin nooit een project in een vergaderruimte met een PowerPoint-presentatie. Ga naar de werkplek van de gebruiker. Ga twee uur lang naast hem of haar zitten terwijl diegene daadwerkelijk aan het werk is met het verouderde systeem. Let op de handen. Merk op wanneer ze zuchten. Let op wanneer ze iets op een Post-it schrijven omdat het systeem daar geen veld voor heeft. Je leert meer over de werkelijke processen van het bedrijf door ze twee uur lang aan het werk te zien dan door 50 pagina's officiële documentatie te lezen.

2. De vijf waarom-vragen voor absurde aanpassingen

Wanneer een gebruiker een zeer kostbare, niet-standaard aanpassing eist (bijvoorbeeld: " Dit scherm moet rood knipperen als een specifiek onderdeel ontbreekt!"), zeg dan niet zomaar "Nee, dat staat de cloud niet toe". Speel het spelletje van de vijf waarom-vragen, zoals een peuter dat zou doen.

Waarom moet het rood knipperen? "Omdat ik vergeet het te controleren voordat ik de productieorder vrijgeef." Waarom vergeet je dat? "Omdat de stuklijst te lang is om handmatig te controleren." Waarom is het een probleem als je de order vrijgeeft terwijl deze ontbreekt? "Omdat de productiemedewerkers de productie starten en vervolgens stoppen, waardoor er tijd verloren gaat."

Opeens realiseer je je dat ze geen knipperend rood scherm nodig hebben. Ze hebben alleen maar nodig dat je de MRP-uitzonderingsberichten correct configureert, zodat het systeem hen waarschuwt voor materiaaltekorten nog voordat ze de order proberen vrij te geven.

Je hebt met succes een bedrijfsprobleem opgelost en voorkomen dat je onnodige code schreef.

Onthoud dat vragen stellen, en veel vragen stellen, absoluut juist en heilig is. Niemand zit te wachten op een consultant die binnenkomt alsof hij alle absolute waarheden in zijn zak heeft. Als het je helpt het echte proces te begrijpen, laat dan je ego varen en vraag, vraag, vraag.

3. Maak hen de hoofdrolspelers van de verandering

Presenteer het nieuwe ERP-systeem altijd als de tool die hen eindelijk in staat stelt zich te concentreren op taken met hoge toegevoegde waarde, in plaats van een systeem dat ze gedwongen worden te gebruiken. Het ERP-systeem is immers slechts een hulpmiddel dat is ontworpen om mensen in de beste positie te brengen om slimmer te werken. Door de juiste benadering te gebruiken, zoals: " Met jouw diepgaande kennis van deze toeleveringsketen, stel je eens voor wat je zou kunnen bereiken als je niet drie uur per dag hoefde te besteden aan handmatige gegevensinvoer?", verhoog je hun status. Dit maakt hen de hoofdrolspeler in de verandering in plaats van het slachtoffer ervan, en ze zullen jouw systeem omarmen.

De mens achter het scherm

De tools die we gebruiken veranderen snel. We stappen over van servers op locatie naar cloudarchitecturen, van handmatige gegevensinvoer naar kunstmatige intelligentie en agents.

Maar terwijl de technologie zich razendsnel ontwikkelt, blijft het menselijk brein precies hetzelfde. We zijn nog steeds bang voor verandering. We haten het nog steeds om ons incompetent te voelen. We verlangen er nog steeds naar om gehoord te worden.

De ware waarde van een ERP-consultant schuilt in het vermogen tot emotionele intelligentie om de angsten binnen de organisatie te doorgronden, veel verder dan het uit het hoofd leren van elke technische parameter van de software. Het gaat erom een ​​traumatische softwaretransitie om te zetten in een eensgezinde stap voorwaarts.

Een perfect systeem dat niet wordt gebruikt, is immers niets meer dan een dure screensaver.

Volgende onderwerp: Hoe maak je een einde aan de eeuwige oorlog en bouw je een echte alliantie op tussen functionele consultants en ontwikkelaars?

Geschreven door Andrea Guaccio 

30 april 2026