Er wordt een demo geboekt, een budget vrijgemaakt, en stiekem hopen we dat het nieuwe systeem de rommel meeneemt in de verhuisdozen en gewoon achterlaat.
Soms klopt dat. Vaak niet.
Bill Gates vatte het jaren geleden al samen: "Automatisering van een efficiënte werking vergroot de efficiëntie, automatisering van een inefficiënte werking vergroot de inefficiëntie."
Een tool versterkt dus wat er al is. Heb je structuur, dan zet hij die in de hoogste versnelling. Heb je chaos, dan krijg je snellere chaos.
Daar zit meteen het venijn. Een tool lost geen procesvraag op, hij voert gewoon uit wat je hem geeft.
Giet je een rommelig proces in workflows, dan krijg je geautomatiseerde rommel, nu alleen moeilijker terug te draaien. Werkt je team niet met propere data, dan rapporteert dat dure platform vrolijk je slechte data terug. En een kennisbank die niemand onderhoudt, blijft een kerkhof van verouderde artikels, hoe strak de interface er ook uitziet.
Wat het extra verraderlijk maakt, is dat het in het begin net wél goed voelt. Een nieuwe implementatie ziet er fris uit, alles staat op zijn plek, en de eerste weken lijkt het te werken. Maar je hebt gebouwd op hetzelfde wankele fundament. Anderhalf jaar later duiken dezelfde frustraties weer op, nu in een duurder systeem. De wittebroodsweken gaan voorbij, de onderliggende problemen niet.
Een deel van de verklaring zit in een oneerlijke vergelijking die we onbewust maken. We zetten een glanzende demo van een nieuwe tool naast onze eigen tool op zijn slechtst, na jaren van achterstallig onderhoud en workarounds. Natuurlijk oogt de nieuwe beter. Maar dat verschil zegt weinig over de tool en veel over de staat waarin we onze eigen werking hebben laten wegzakken. Zet je diezelfde nieuwe tool op diezelfde rommelige basis, dan sta je binnen het jaar weer waar je begon.
Het lastigst wordt het wanneer een tool wordt ingezet om een ander probleem te ontwijken. Onduidelijk ownership, te weinig mensen, een team dat verzuipt: geen enkele licentie lost dat op. De tool wordt dan het verhaal, terwijl de echte oorzaak blijft liggen. Erger nog, het geeft iedereen het comfortabele gevoel dat er iets gedaan wordt, terwijl het echte werk wordt uitgesteld.
En past de tool niet bij hoe het team echt werkt, dan gebeurt het voorspelbare. Mensen bouwen hun eigen workarounds of haken af. Een werkwijze die ver van de frontlinie bedacht is, overleeft de frontlinie zelden.
Betekent dit dat een nieuwe tool nooit het antwoord is? Nee, en dat is belangrijk om er eerlijk bij te zeggen. Er zijn situaties waarin overstappen wel degelijk terecht is. Wanneer je leverancier zijn product niet meer verder ontwikkelt of gewoon stopzet. Wanneer je organisatie zo gegroeid of veranderd is dat je huidige systeem simpelweg niet meer meekan. Wanneer je vastzit in zoveel maatwerk dat elke update een nachtmerrie wordt. Wanneer je werk versnipperd zit over een handvol losse tools die niet met elkaar praten. Of wanneer de kosten van je huidige leverancier de pan uit swingen zonder dat er waarde tegenover staat. In die gevallen is een nieuwe tool geen vlucht, maar een gezonde beslissing.
Het verschil zit in de vraag die je stelt. "Deze tool is oud en vervelend, laten we iets nieuws kopen" is de verkeerde vraag. "Wat willen we bereiken, en waarom lukt dat vandaag niet" is de juiste. Soms is het antwoord op die tweede vraag inderdaad een nieuwe tool. Vaker is het antwoord: eerst orde op zaken, en dan pas kijken.
Wanneer helpt een tool dan wél?
Als de basis eronder klopt. Als helder is wie wat oppakt, wanneer je escaleert en wat je wil meten. Als het repetitieve werk in kaart staat, zodat automatisering net tijd vrijmaakt voor het werk waar mensen het verschil maken.
En besluit je toch om over te stappen, doe het dan met dat fundament eerst. Kijk je processen kritisch na voor je ze automatiseert, in plaats van je oude gewoontes klakkeloos over te zetten. Betrek het team dat er elke dag mee zal werken, want wie niet mee mocht denken, denkt vooral aan tegenwerken. Test op kleine schaal voor je alles omgooit. En spreek vooraf af waaraan je je succes zal afmeten. Een tool live zetten is niet het einde van het werk, het is het begin.
Kort gezegd: een tool is een versterker, geen fundament.
Daarom kijken wij tool-onafhankelijk. We beginnen bij je processen, je ownership en wat je écht wil bereiken, en we betrekken het team dat er elke dag mee werkt. Pas daarna komt de vraag welke tool daarbij past, of dat wat je al hebt eigenlijk volstaat. Vaak is dat laatste het geval, en dan hebben we je een dure, slopende migratie bespaard.
Wat was bij jullie de echte winst: de nieuwe tool, of het werk dat eraan voorafging?
