Wanneer een implementatie wordt opgeleverd, begint het echte werk pas

Mijn werk begint opvallend vaak op hetzelfde moment. Niet bij de start van een implementatie, maar erna. Organisaties hebben een AFAS-implementatie achter de rug. Alles is netjes opgeleverd, de processen staan beschreven, de inrichting klopt technisch en het project is binnen scope afgerond. Op papier is het een succes.

En dan vertrekken de consultants.

Wat achterblijft is een organisatie die het ineens zelf moet doen. Dagelijks werken met het systeem, wijzigingen doorvoeren, nieuwe vragen beantwoorden en omgaan met veranderingen die vooraf niet waren te voorspellen. Dat is het moment waarop een systeem zijn echte waarde moet bewijzen.

Een inrichting die stilstaat, terwijl de organisatie doorontwikkelt

Vijf jaar later zie ik vaak nog exact dezelfde inrichting. Niet omdat die zo goed is, maar omdat niemand er echt aan durft te komen. In de tussentijd is de organisatie veranderd. Processen zijn gegroeid, rollen zijn verschoven en uitzonderingen zijn langzaam de norm geworden.

Het systeem functioneert technisch nog steeds. Er zijn geen grote storingen en alles doet wat het ooit moest doen. Tegelijkertijd sluit het steeds minder aan op hoe er daadwerkelijk gewerkt wordt. Medewerkers passen zich aan het systeem aan, in plaats van andersom. Dat kost tijd, energie en vooral vertrouwen in het geheel.

Van omwegen naar afhankelijkheid

In het begin ontstaan kleine oplossingen. Een extra handmatige stap omdat dat sneller voelt. Een Exceloverzicht om grip te houden. Een controle buiten het systeem om, “voor de zekerheid”. Dat is begrijpelijk en vaak zelfs logisch.

Na verloop van tijd ontstaat er iets anders. Mensen weten niet meer waarom bepaalde keuzes ooit zijn gemaakt. Aanpassingen voelen risicovol, omdat niemand het totale effect nog overziet. Elke wijziging wordt een project op zich en voor elke stap is externe hulp nodig. Wat begon als flexibiliteit, eindigt in afhankelijkheid.

Wat mij hierin frustreert, is dat dit zelden te maken heeft met slechte software of onkunde binnen de organisatie. Het ontstaat omdat consultancy te vaak stopt bij opleveren. Er wordt gebouwd wat gevraagd wordt, binnen planning en scope, en daarna is het klaar. Terwijl dat juist het moment is waarop de echte vragen beginnen.

Hoe ontwikkel je door zonder alles opnieuw te hoeven doen? Wie is eigenaar van het proces? Wie durft keuzes te maken wanneer belangen botsen? En hoe zorg je ervoor dat het systeem meebeweegt, zonder dat elke wijziging een nieuw traject wordt?

Processen als vertrekpunt, niet de inrichting

Mijn overtuiging is dat processen leidend moeten zijn. Software is een middel, geen doel. Het hoort te ondersteunen, te versterken en mee te bewegen wanneer een organisatie verandert. Dat vraagt zelden om een nieuwe implementatie, maar bijna altijd om inzicht.

Inzicht in hoe er in de praktijk gewerkt wordt. Waar frictie ontstaat. Waar mensen omwegen nemen en waarom dat logisch is vanuit hun perspectief. Pas wanneer dat helder is, ontstaat ruimte voor verbetering die rust brengt in plaats van extra complexiteit toevoegt.

Daarom begin ik nooit bij de inrichting zelf. Ik begin bij luisteren, observeren en doorvragen. Waarom is iets zo gegroeid? Welke keuzes waren destijds logisch, maar knellen nu? En welke aanpassingen blijven ook over een paar jaar nog werken?

Regie terugpakken zonder alles om te gooien

Dit is het punt waarop ik organisaties begeleid. Niet om alles opnieuw te bouwen, maar om weer regie te krijgen. Om processen expliciet te maken, eigenaarschap te beleggen en het systeem opnieuw ondersteunend te laten zijn in plaats van leidend.

Een goed ingericht systeem is geen eindpunt. Het is een fundament waarop je moet kunnen doorbouwen. Wanneer dat fundament meebeweegt met de organisatie, ontstaat rust. Niet omdat alles perfect is, maar omdat je begrijpt waarom het zo werkt en weet hoe je het kunt aanpassen wanneer dat nodig is.

En precies daar begint voor mij het echte werk.