ERP-implementatie als vliegwiel voor verandering

Een ERP-implementatie wordt zelden als project op zichzelf gezien, en toch wordt hij meestal als project op zichzelf gemanaged. De business case is geschreven voor deze migratie en het succescriterium is de geslaagde uitrol ervan. Zodra die go-live er is, valt de aandacht weg en gaat het team terug naar zijn dagelijkse werk.

Dat is begrijpelijk, want zo zijn de meeste organisaties georganiseerd. Tegelijkertijd zien we dat hier ook een gemiste kans zit. Een ERP-implementatie kan namelijk veel meer opleveren dan alleen een werkend systeem, mits je dat van tevoren als doel benoemt.

Waarom dit moment zo waardevol is

In de gesprekken die wij voeren met opdrachtgevers gaat het bijna altijd over deze ene implementatie, met begrijpelijke vragen over het pakket, de planning en de kosten. Wat zelden expliciet aan tafel komt, is dat een organisatie die met SAP of Microsoft Dynamics 365 begint, daarmee niet één transformatie aangaat. Die gaat een meerjarige reeks aan veranderingen in.

Want na de eerste migratie volgt namelijk de uitrol naar andere afdelingen, met daarna een procesharmonisatie die nodig blijkt om afdelingen op één lijn te krijgen. De upgrade-cyclus die elke achttien maanden iets nieuws van de organisatie vraagt, een acquisitie die geïntegreerd moet worden in het bestaande landschap, een module die in de eerste ronde was overgeslagen en uiteindelijk een AI-laag die over het bestaande systeem komt te liggen. De ene transformatie is daarmee de eerste in een lange reeks.

In dat licht is de cruciale vraag bij een ERP-implementatie niet alleen of dit project slaagt. De cruciale vraag is of de organisatie er beter in wordt om verandering aan te kunnen, zodat de volgende implementatie minder moeite kost. Daar zit waarde die over meerdere projecten meebeweegt, en dat is waar grip op verandering over gaat.

Concreet betekent dat een paar dingen. Het succes wordt gedefinieerd op programma-niveau, niet alleen op projectniveau. Een geslaagde migratie is een mooi resultaat, maar het is niet hetzelfde als een geslaagde transformatie. Voor de transformatie hoort er een laag bovenop te komen, die meet of de organisatie ook daadwerkelijk beter wordt in veranderen.

De keuze van de oplossing voor het eerste project houdt rekening met wat erna komt. Dat klinkt als een open deur, maar in de praktijk wordt het zelden zo gedaan. Organisaties optimaliseren hun ERP-keuze voor de eerste migratie en lopen vast als de tweede afdeling andere eisen blijkt te hebben.

En de mensen die ermee gaan werken, worden niet alleen ondersteund tijdens deze migratie. Ze worden onderdeel van een verandernetwerk dat ook na de migratie blijft bestaan, met sponsoren en key users die het volgende project op gang helpen brengen omdat ze al weten hoe het werkt. Dat netwerk is waardevoller dan welke individuele training ook, omdat het materialen, methodes en mensen klaarzet voor de volgende verandering.

Wat een ontwerpfout in de praktijk doet

Een voorbeeld om dit tastbaar te maken. Een organisatie kiest in de selectiefase voor een ERP-pakket dat in de standaardconfiguratie uitgaat van één centrale werkwijze. Voor de meeste afdelingen is dat geen probleem en zelfs een verbetering. Voor één afdeling, die historisch met een afwijkende werkwijze werkt om goede redenen die te maken hebben met klantcontact en tijdsdruk, betekent het dat ze straks anders moeten gaan werken op een manier die niet past bij hun dagelijkse praktijk.

Die afdeling komt pas in beeld in de uitrolfase, als er nog weinig ruimte is om iets fundamenteels aan te passen. Bij standaardpakketten als SAP of Dynamics 365 is een fundamentele aanpassing in deze fase ook moeilijk en duur, omdat je dan tegen de logica van het pakket in werkt. Dan is er een keuze tussen het doorzetten van de oorspronkelijke configuratie, met als gevolg dat de afdeling een tijd lang minder goed functioneert, of alsnog improviseren met workarounds die niet voorzien waren in de planning. Beide opties kosten geld en goodwill, en beide zijn vermijdbaar.

De vraag die in zo'n geval eerder gesteld had moeten worden is niet wat er nodig is om de afdeling mee te krijgen, maar wat dit systeem doet met hoe deze afdeling werkt. Dat klinkt als een nuance, maar het verschil zit in wanneer je het vraagt en aan wie. Het wordt dan een ontwerpkeuze vooraf, waarbij nog ruimte is om te kijken naar de geschiktheid van het pakket, de scope van de implementatie of het werkproces van de afdeling zelf.

Een voorbeeld uit de praktijk

In een recent traject bij een groot Rotterdams havenbedrijf werd een SAP-migratie ingezet als eerste verandering binnen een meerjarig transformatieprogramma. Het programmateam koos er bewust voor om deze eerste migratie te gebruiken om iets op te bouwen dat verder reikte dan dit ene project.

Concreet betekende dat een medewerker journey die niet alleen voor deze migratie werd uitgewerkt, maar als sjabloon voor toekomstige veranderingen kon dienen. Daaromheen werd een veranderaanpak ingericht met onderzoeksmaterialen, workshops en hulpmiddelen die hergebruikt kunnen worden in volgende trajecten. Ook de meetmethode was zo opgezet dat hij niet alleen achteraf liet zien dat de migratie was gelukt, maar vooraf liet bepalen of de uitrol kon doorgaan.

Voor de migratie liet een meting onder de medewerkers zien dat 89 procent zich goed geïnformeerd voelde, dat 92 procent meerwaarde zag in de nieuwe oplossing en dat 97 procent verwachtte hun werk goed te kunnen blijven doen. Op basis van die meting werd een formeel go-besluit genomen voor de uitrol. Na go-live bleek 91 procent van de SAP-gebruikers daadwerkelijk goed door te kunnen werken. De ondersteuning kreeg een 9.1 op 10.

Die cijfers zijn op zichzelf goed. Maar het belangrijkste is wat er werd nagelaten. De aanpak was vastgelegd als blauwdruk en het verandernetwerk bleef in stand, zodat de volgende verandering binnen het programma kon profiteren van wat in deze migratie was opgebouwd. Daar zit de echte opbrengst.

Waarom dit zo zelden gebeurt

Programmadenken is moeilijker dan projectdenken. Een project is afgebakend in tijd, scope en budget. Een programma is dat ook, maar het vraagt bovendien om investeringen die pas in een volgende fase renderen. In een organisatie die op kwartaalresultaten stuurt, krijgt zo'n investering structureel te weinig aandacht.

Daarnaast wordt de meerwaarde van hergebruik vaak niet expliciet gemaakt in een business case. De hergebruikswaarde van wat dit traject voor toekomstige trajecten oplevert wordt zelden gekwantificeerd, en valt daarom buiten elke business case. Wie achteraf de tijd telt die niet besteed hoefde te worden aan het opnieuw uitvinden van een aanpak, ziet dat zelden terug in een resultaatrapportage.

Tot slot is er een blinde vlek in hoe veel organisaties hun veranderkracht zien. De hogere niveaus van verander-volwassenheid, waarin veranderen iets is wat de organisatie standaard kan in plaats van iets waar bij elk traject opnieuw aan moet worden gewerkt, voelen voor veel teams als ver weg. Toch begint de weg ernaartoe vrij eenvoudig: met de keuze om elk project niet alleen voor het project zelf te doen.

Tot slot

Onderzoek van McKinsey laat al jaren zien dat ongeveer 70 procent van de organisatieveranderingen niet de vooraf gestelde doelen haalt. Dat cijfer wordt vaak aangehaald als argument voor betere change management binnen één traject. Het is waarschijnlijk eerlijker om te zeggen dat het percentage ook iets vertelt over hoe organisaties met de stapeling van veranderingen omgaan. Wie elke transformatie als een op zichzelf staand project doet, blijft geconfronteerd worden met dezelfde percentages.

De andere benadering vraagt vooraf meer geduld en meer denkwerk. Wat het oplevert staat in geen enkel projectplan: een organisatie die structureel beter wordt in veranderen. Voor ons is dat de eigenlijke opbrengst van vijftien jaar werk bij meer dan honderd organisaties.