Wanneer een automatiseringsproject mislukt, ligt dat zelden aan de techniek. Het is bijna altijd iets wat maanden eerder misliep, in de analyse of in de afspraken eromheen. Zes patronen komen daarbij telkens terug: het proces werd geautomatiseerd zoals het beschreven staat en niet zoals het loopt, de uitzonderingen kwamen pas na de oplevering boven, niemand was eigenaar, het project begon te groot, de mensen die ermee moeten werken zijn nooit gevraagd, en er stond geen meetpunt in. Hieronder staat per patroon waaraan je het vooraf herkent en wat je eraan doet.
Het proces werd geautomatiseerd zoals het beschreven staat, niet zoals het loopt
Bij de start van een project komt er een beschrijving op tafel: een schema, een procedure uit het kwaliteitshandboek, of het verhaal van de zaakvoerder over hoe een order door het bedrijf gaat. Daarop wordt gebouwd.
Het echte proces bevat stappen die in geen enkele beschrijving staan. Iemand belt eerst even naar de klant, omdat aanvragen zelden volledig binnenkomen. Er is een kolom in een rekenblad die officieel niet bestaat maar wel bepaalt in welke volgorde er geleverd wordt. De goedkeuringsstap wordt bij spoed stilzwijgend overgeslagen, en spoed is allang geen uitzondering meer.
Automatiseer je de beschrijving, dan klopt het systeem voor het geval dat op papier staat. Bij het eerste geval dat afwijkt, werken mensen eromheen. Vanaf dan draait de automatisatie naast het echte proces in plaats van erin.
Wat je eraan doet: laat iemand meekijken terwijl het werk gebeurt, niet terwijl het uitgelegd wordt. Wij gaan in de blueprintweek een dag naast de uitvoerder zitten en vragen of die gewoon doorwerkt. Hoe dat verloopt, staat op de pagina over onze aanpak van screening tot oplevering.
De uitzonderingen kwamen pas boven nadat het systeem in productie stond
De normale gang van zaken bouwt iedereen goed. Een project loopt stuk op de klant die per deellevering factureert, op het artikel dat altijd per twee besteld moet worden, op de leverancier die zijn bevestiging als afbeelding in de mail plakt.
Die gevallen staan in geen enkele handleiding. Ze zitten in het hoofd van de persoon die ze al jaren opvangt. Vraag je hoe het proces verloopt, dan hoor je ze niet. Vraag je wanneer het misloopt, dan komen ze meestal wel boven.
Uitzonderingen melden zich pas wanneer het systeem draait. In de eerste weken na de oplevering komt er dus een golf van dingen die niemand voorzien had. Dat is geen teken dat het project mislukt is. Het echte probleem is dat er in de planning geen tijd voor gereserveerd staat.
Wat je eraan doet: reken van bij het begin op een periode na de oplevering waarin er nog aan de workflow gewerkt wordt. Wij plannen daar twee weken testen voor in.
Er was niemand die eigenaar was van de workflow
Een automatisatie die van iedereen is, is van niemand. Zolang alles draait, valt dat niet op. Het valt op de dag dat de maker van je boekhoudpakket het formaat van een export wijzigt.
Op dat moment moeten er drie dingen gebeuren: iemand moet merken dat het misloopt, iemand moet beslissen wat er nu moet, en iemand moet het laten aanpassen. Zonder eigenaar gebeurt geen van de drie. De workflow valt stil, iemand doet het werk een tijdlang met de hand, en een paar maanden later is dat de nieuwe werkwijze geworden.
Eigenaar zijn is geen technische rol. Het is iemand binnen jouw bedrijf die weet waarvoor de workflow dient, die de meldingen krijgt wanneer er iets vastloopt, en die mag beslissen of een uitzondering erbij komt. Dat kan de kantoorverantwoordelijke zijn, de planner, of bij een kleine ploeg de zaakvoerder zelf.
Aan de kant van de bouwer hoort daar een afspraak tegenover te staan over wie je belt en binnen welke termijn er iets gebeurt. Wat daarin thuishoort, staat op de pagina over Care en vastgelegde reactietijden.
Het project begon te groot en er draaide maandenlang niets
Het orderproces, de planning, de facturatie en een klantenportaal, allemaal in één traject. Op papier logisch, want die dingen hangen samen. In de praktijk betekent het dat er maanden voorbijgaan zonder dat iemand in het bedrijf iets ziet werken.
In die maanden gebeurt er van alles. Er vertrekt iemand, er komt een drukke periode, een andere prioriteit duwt het project naar achteren. Een project dat nog niets opgeleverd heeft, wordt dan gepauzeerd. En een gepauzeerd project start zelden opnieuw op, want intussen klopt de halve analyse niet meer.
Wat je eraan doet: kies één workflow en zet die in productie voor je aan de volgende begint. Geen prototype en geen demo, maar iets waar je mensen mee werken. Bij ons duurt dat ongeveer een week per workflow. Het hele traject wordt daar niet veel langer van, want er komt elke week een workflow bij. Wat je in die eerste workflow leert over hoe jullie werkelijk werken, verbetert meteen het ontwerp van de tweede.
De mensen die ermee moeten werken zijn nooit gevraagd
Dit patroon herken je aan een zin die bij de oplevering valt: dat hadden we graag eerder geweten. De beslissing is bovenaan genomen, de analyse is met het management gedaan, en de mensen die het systeem elke dag moeten gebruiken zien het voor het eerst tijdens de opleiding.
Er gaan dan twee dingen mis. Je mist de kennis, want de uitzonderingen en de tussenstapjes zitten bij hen. En je mist de welwillendheid: een systeem dat iemand overkomt, wordt anders gebruikt dan een systeem waar die persoon iets aan mocht veranderen.
Het gevolg is een schaduwproces. Het oude rekenblad blijft naast het nieuwe systeem doorlopen voor de zekerheid, en na een paar maanden is dat rekenblad weer de waarheid. Dan heb je er een systeem bij in plaats van een systeem minder.
Wat je eraan doet: spreek de uitvoerders tijdens de analyse en niet erna, en laat hen de eerste versie afkeuren. Kritiek in week drie is een aanpassing. Dezelfde kritiek een halfjaar later is een nieuw project.
Er stond geen meetpunt in, dus niemand kon aantonen dat het werkte
Dit patroon doet een project niet mislukken maar doodbloeden. De workflow draait, er is niets mis mee, en toch komt er nooit een tweede. De reden: niemand kan zeggen wat de eerste heeft opgeleverd.
Zonder cijfer van voor de start wordt het een gevoelskwestie. De ene zegt dat het vlotter loopt, de andere dat er ander werk bij gekomen is, en allebei hebben ze een beetje gelijk. Wie daarna nog een stap wil zetten, heeft niets in handen.
Een meetpunt hoeft niet ingewikkeld te zijn. Hoelang het duurt voor een aanvraag beantwoord is. Hoe vaak een order gecorrigeerd moet worden. Hoeveel uur er per week naar het samenvoegen van bestanden gaat. Eén cijfer volstaat, zolang je de waarde van vandaag kent.
Bij ons krijgt elke workflow een logboek en een meetpunt mee, en zit dat in de opzet in plaats van erna. Hoe we die uren tellen in de blueprint, staat op de pagina over tijdwinst en hoe we die meten.
| patroon | waaraan je het vooraf herkent | de tegenmaatregel |
|---|---|---|
| Het proces op papier | De analyse gebeurde in een vergaderzaal, niet op de werkvloer | Een dag meekijken terwijl het werk gebeurt |
| Uitzonderingen te laat | Iedereen beschrijft het proces als één rechte lijn | Vragen wanneer het niet werkt, en tijd na de oplevering plannen |
| Geen eigenaar | Op de vraag wie er straks over gaat, kijkt iedereen naar iemand anders | Eén naam binnen het bedrijf, met meldingen en beslissingsrecht |
| Te groot begonnen | Het plan raakt meerdere afdelingen en de eerste oplevering ligt ver weg | Eén workflow tot in productie, dan pas de volgende |
| Gebruikers niet gevraagd | De uitvoerders horen ervan via de planning van de opleiding | Uitvoerders in de analyse, en zij keuren de eerste versie af |
| Geen meetpunt | Niemand kan zeggen hoeveel tijd het proces vandaag kost | Eén cijfer meten voor de bouw begint |
Onze werkwijze vangt vijf van de zes patronen op
De fasen die wij aanhouden, staan niet los van dit lijstje. Ze zijn eruit ontstaan. Een screening van twee uur met de mensen die het werk doen vangt het eerste en het vijfde patroon. Eén week bouwen tot er iets in productie staat, vangt het vierde. De twee weken testen daarna vangen het tweede en het zesde.
Die twee weken zijn geen nazorg. Het is het deel waarin de workflow pas echt gaat passen. Elke week zitten we 30 minuten met de mensen die ermee werken: wat loopt goed, waar wringt het, welke uitzondering kwam er deze week boven. Wat daaruit komt, verwerken we diezelfde week.
Wat die weken niet oplossen, is het derde patroon. Eigenaarschap kan je niet inbouwen. Dat is een keuze aan jouw kant, en het enige van de zes waar wij weinig aan kunnen doen, behalve erop aandringen. Wat wij wel en niet bouwen, staat op de pagina over AI-automatisaties in de praktijk.
Wat je doet wanneer een automatiseringsproject al mislukt is
De reflex is helemaal opnieuw beginnen. Dat is bijna nooit nodig en het gooit het meeste weg. Vijf stappen die meestal meer opleveren:
- Meet wat er vandaag werkelijk gebeurt, en dan vooral hoe vaak er iets met de hand rechtgezet wordt.
- Vraag de gebruikers welke stappen ze omzeilen en waarom. Daar zit de lijst met uitzonderingen die in de analyse ontbrak.
- Scheid wat stuk is van wat nooit gepast heeft. Het eerste is een herstelling, het tweede een ontwerpvraag. Ze door elkaar halen is de reden dat herstellingen blijven terugkomen.
- Kies de kleinste stap die iets oplevert en zet die in productie. Eén zichtbare verbetering doet meer dan een nieuw plan.
- Zet er een naam op. Zolang er geen eigenaar is, herhaalt hetzelfde zich met de volgende leverancier.
Soms is de conclusie dat het onderliggende pakket niet meer past. Wanneer vervangen het antwoord is en wanneer je beter naast het bestaande bouwt, lees je op de pagina over software op maat.
Een gestrand project is bijna nooit weggegooid werk. Het is meestal een analyse die niet af was.
Waar je begint als je hier iets in herkent
Wij zitten op de Corda Campus in Hasselt en werken voor KMO's in Limburg en Vlaanderen. In gesprekken over een nieuw project gaat het bij ons daarom eerst over de vorige poging. Wat er toen gebouwd is, telt minder dan waarom het niet gebruikt wordt.
Herken je twee of drie van de zes patronen in je eigen huis, dan is de eerste stap niet een offerte vragen maar kijken. Twee uur aan tafel met de mensen die het werk doen, levert meer op dan een demo van een pakket. Wat daaruit komt, is een rapport dat je ook zonder ons kan gebruiken.
Veelgestelde vragen
Waarom mislukken automatiseringsprojecten zo vaak?
Meestal niet door de techniek maar door de analyse ervoor. Het proces wordt vastgelegd zoals het beschreven staat en niet zoals het werkelijk loopt, de uitzonderingen komen pas na de oplevering boven, en er is niemand aangeduid die er daarna over gaat. Die drie samen zijn genoeg om een technisch correct systeem ongebruikt te laten.
Wat is de grootste valkuil bij digitalisering in een KMO?
Te groot beginnen. Een traject dat meerdere afdelingen tegelijk aanpakt, levert maandenlang niets zichtbaars op, en in die maanden gebeurt er altijd iets: een vertrek, een drukke periode, een andere prioriteit. Projecten zonder iets werkends worden dan gepauzeerd, en gepauzeerde projecten starten zelden opnieuw op.
Hoe weet je vooraf of een softwareproject fout gaat lopen?
Stel twee vragen voor de bouw begint. Wie heeft er meegekeken terwijl het werk gebeurde, en wie is straks de eigenaar van deze workflow binnen het bedrijf. Kan niemand die twee vragen met een naam beantwoorden, dan is de kans groot dat je na de oplevering opnieuw begint.
Kan je een gestrand automatiseringsproject nog redden?
Vaak wel, en meestal zonder alles opnieuw te bouwen. Begin met meten wat er vandaag echt gebeurt en vraag de gebruikers welke stappen ze omzeilen. Daarna scheid je wat stuk is van wat nooit gepast heeft, want dat vraagt om verschillende oplossingen. Helemaal opnieuw beginnen is de zwaarste weg en zelden de juiste.
Hoe lang duurt het voor een automatisatie echt past?
Langer dan de bouw zelf. Bij ons staat een workflow na ongeveer een week in productie, en daarna volgen twee weken testen, met elke week een overleg van 30 minuten met de mensen die ermee werken. Pas in die weken komen de uitzonderingen boven die niemand vooraf had bedacht.
Begin met een screening
In een screening van twee uur zitten we bij jou aan tafel met de zaakvoerder en de mensen die het werk doen, en brengen we je processen in kaart. Achteraf weet je waar de kansen liggen, welke weg past en hoeveel workflows of modules je nodig hebt. Je krijgt een bevindingenrapport en we nemen het samen door in een call van 30 minuten.
