Vrijwel iedere organisatie kent processen waarvan medewerkers zeggen dat ze efficiënter kunnen. Informatie wordt overgetypt tussen systemen, een Excel-bestand moet handmatig worden bijgewerkt, controles worden dagelijks opnieuw uitgevoerd of een medewerker verricht bij iedere order dezelfde reeks handelingen.
De oplossing lijkt dan vaak voor de hand te liggen: automatiseren. Zeker nu AI de mogelijkheden daarvoor in hoog tempo vergroot, is het verleidelijk om direct naar de oplossing te kijken. Welke software is beschikbaar? Kan er een koppeling worden gebouwd? Kan AI een deel van het werk overnemen? Hoeveel handelingen kunnen verdwijnen?
De interessantere vraag komt wat mij betreft eerder: wat kost het huidige probleem eigenlijk?
Procesverbetering begint voor mij bij die vraag. Een commerciële onderneming moet uiteindelijk geld verdienen. Vanuit dat uitgangspunt moet een investering in procesautomatisering in de basis bijdragen aan lagere kosten, hogere opbrengsten of het creëren van capaciteit waarmee één van die twee mogelijk wordt.
Daar bestaan uitzonderingen op. Veiligheid, compliance, continuïteit of een onacceptabel bedrijfsrisico kunnen voldoende reden zijn om een proces aan te passen zonder dat daar een klassieke positieve ROI tegenover staat. Maar bij de meeste automatiseringsprojecten is het helemaal niet vreemd om te willen weten welke bedrijfswaarde met de investering wordt gecreëerd. Die vraag klinkt financieel. In werkelijkheid dwingt hij een organisatie vooral om eerst te begrijpen welk probleem ze probeert op te lossen.
Tijd besparen is nog geen businesscase
Een van de meest gebruikte argumenten voor automatisering is tijdsbesparing. Stel dat binnen Finance een proces jaarlijks ongeveer 500 arbeidsuren kost. Een automatisering kan dat werk grotendeels overnemen. Wanneer een medewerker inclusief werkgeverslasten bijvoorbeeld €40 per uur kost, lijkt de rekensom eenvoudig: 500 uur maal €40 betekent een jaarlijkse besparing van €20.000.
Als de automatisering €15.000 kost, lijkt de investering binnen een jaar terugverdiend. Alleen is die conclusie vaak te snel. Wanneer na implementatie exact dezelfde medewerkers hetzelfde aantal contracturen blijven werken en de totale salariskosten niet veranderen, heeft de organisatie niet ineens €20.000 minder uitgegeven. Er zijn 500 arbeidsuren vrijgemaakt. Dat is iets anders.
Die capaciteit kan buitengewoon waardevol zijn. Een medewerker kan werkzaamheden uitvoeren die eerder bleven liggen, meer klanten bedienen, analyses verbeteren, achterstanden wegwerken of extra groei verwerken waarvoor anders een nieuwe medewerker nodig zou zijn. Maar die tweede stap moet wel plaatsvinden.
Daar gaat het bij businesscases voor automatisering naar mijn idee regelmatig mis. Het aantal bespaarde uren wordt vermenigvuldigd met een uurtarief en vervolgens rechtstreeks als financiële besparing gepresenteerd, zonder te bepalen waar de vrijgekomen capaciteit uiteindelijk terechtkomt.
Dat betekent niet dat een project zonder directe verlaging van de loonkosten geen waarde creëert. Het betekent wel dat de waarde nauwkeuriger moet worden beschreven. Wanneer een afdeling door automatisering een toekomstige uitbreiding met één FTE kan voorkomen, wordt de financiële impact redelijk concreet. Wanneer medewerkers door de tijdswinst meer omzetgenererende werkzaamheden kunnen uitvoeren, kan eveneens waarde ontstaan. En wanneer capaciteit wordt gebruikt voor werkzaamheden die eerder structureel bleven liggen, kan dat operationeel belangrijk zijn zonder dat de volledige waarde direct op één regel van de resultatenrekening zichtbaar wordt. Maar het is essentieel om dat onderscheid vooraf te maken.
Meten voordat er wordt geïnvesteerd
Om dat überhaupt te kunnen beoordelen, moet eerst duidelijk zijn hoeveel tijd en geld het huidige proces daadwerkelijk kost. Daar ben ik vrij principieel in: meten is weten.
Mensen zijn bijzonder goed in het maken van aannames. Een proces dat dagelijks irritatie veroorzaakt, voelt al snel als een groot probleem. Een handeling die maar enkele minuten duurt, wordt juist gemakkelijk als onbelangrijk gezien. Beide conclusies kunnen volledig verkeerd zijn.
Een proces van twintig minuten dat één keer per maand wordt uitgevoerd, zal financieel meestal weinig voorstellen. Een handeling van twee minuten die twintigduizend keer per jaar plaatsvindt, kan honderden arbeidsuren vertegenwoordigen. Het gevoel dat een proces inefficiënt is, is daarom een prima aanleiding om onderzoek te doen. Het is geen onderbouwing voor een investering.
Dat betekent overigens niet dat ieder proces maandenlang onderzocht moet worden. Ook meten moet proportioneel blijven. Bij een orderproces kan bijvoorbeeld een representatieve steekproef worden genomen. Hoeveel handelingen vinden plaats? Hoeveel minuten kost iedere stap? Welke medewerkers zijn erbij betrokken? Waar ontstaan correcties? Hoe vaak komen uitzonderingen voor?
Die gegevens kunnen vervolgens worden gecombineerd met het werkelijke ordervolume. Op dat moment verandert de discussie. Niet langer: “Dit proces voelt omslachtig.” Maar: “Deze handeling kost gemiddeld zes minuten, vindt 5.000 keer per jaar plaats en vraagt daarmee ongeveer 500 arbeidsuren.” Dat is informatie waarop een investeringsbesluit kan worden gebaseerd.
Niet iedere vorm van waarde hoeft fictief in euro’s te worden vertaald
Wanneer een proces eenmaal is gemeten, ontstaat een volgende vraag: welke kosten worden meegenomen? Mijn voorkeur is om de direct toerekenbare kosten zo volledig mogelijk vast te leggen. Arbeidsuren die rechtstreeks met het proces samenhangen, externe kosten, transport, herstelwerk, licenties en andere concrete uitgaven kunnen meestal redelijk goed worden bepaald.
Indirecte kosten vragen meer voorzichtigheid. Een inefficiënt proces kan frustratie veroorzaken, managementtijd vragen, klanttevredenheid beïnvloeden of ervoor zorgen dat facturatie later plaatsvindt. Dat zijn reële effecten, maar dat betekent nog niet dat ieder effect betrouwbaar in euro’s kan worden uitgedrukt.
Wanneer een leidinggevende aantoonbaar iedere week enkele uren bezig is met begeleiding of herstelwerk dat rechtstreeks uit een procesprobleem voortkomt, kan die tijd prima onderdeel zijn van de businesscase. Maar zodra begrippen als medewerkerstevredenheid, klantbeleving of extra omzet zonder voldoende onderbouwing worden gemonetariseerd, ontstaat het risico dat een businesscase vooral wordt gebruikt om een al gewenste investering financieel aantrekkelijk te laten lijken.
Daar moet de businesscase juist tegen beschermen.
Van irritatie naar investeringsvraagstuk
Neem opnieuw de fictieve handelsorganisatie Delta Trading B.V., een aantal jaar later dan in de eerdere analyses. De onderneming realiseert in deze fictieve situatie ongeveer €20 miljoen omzet en heeft circa 35 medewerkers. Binnen Operations bestaat al langere tijd het gevoel dat het orderproces onnodig veel handmatig werk bevat. Gegevens worden gecontroleerd, informatie wordt tussen systemen overgenomen en bij uitzonderingen zijn meerdere afdelingen betrokken.
De eerste reflex is om naar automatisering te kijken. Voordat een oplossing wordt gekozen, wordt het proces eerst gemeten. Uit een steekproef blijkt dat de relevante handelingen gemiddeld zes minuten per order kosten. Bij 5.000 orders per jaar vertegenwoordigt dat ongeveer 500 arbeidsuren. Daarnaast moeten jaarlijks circa 150 fouten worden hersteld. Daarbij zijn Operations, Sales en Finance betrokken en ontstaan concrete kosten door correcties en extra transport.
Nu ligt er ineens een ander vraagstuk. De vraag is niet meer of het proces technisch geautomatiseerd kan worden. De vraag is welke economische waarde ontstaat wanneer een deel van die werkzaamheden verdwijnt.
Stel dat een oplossing 80 procent van het handmatige werk elimineert. Dan worden ongeveer 400 arbeidsuren vrijgemaakt. Die uren mogen niet automatisch als cashbesparing worden gepresenteerd. Delta Trading moet eerst bepalen wat met de nieuwe capaciteit gebeurt.
Wanneer de onderneming verwacht verder te groeien en daardoor geen extra medewerker hoeft aan te nemen, ontstaat een relatief harde financiële waarde. Wanneer de vrijgekomen tijd wordt gebruikt om achterstanden structureel weg te werken of controles te verbeteren, is de waarde eveneens aanwezig, maar moeilijker rechtstreeks te vertalen naar lagere kosten. De foutkosten zijn anders. Wanneer correcties, retouren of extra transport daadwerkelijk verdwijnen, is daar wel een directe financiële besparing zichtbaar.
De businesscase bestaat daarmee uit verschillende vormen van waarde. Dat is realistischer dan alle effecten onder één noemer “bespaarde uren” plaatsen.
Een businesscase hoeft niet ingewikkeld te zijn
Een serieus automatiseringsproject moet naar mijn idee vrijwel altijd een businesscase hebben. Dat betekent niet dat er voor iedere verbetering een document van vijftig pagina’s nodig is. De kern kan relatief eenvoudig blijven.
Daarbij zijn scenario’s belangrijk. Wanneer een automatisering volgens het basisscenario 1.000 uur per jaar vrijmaakt, zou ik ook willen weten wat er gebeurt wanneer uiteindelijk maar 750 of 500 uur wordt gerealiseerd.
Een project waarvan de ROI uitsluitend positief is wanneer iedere aanname exact uitkomt, heeft een heel ander risicoprofiel dan een investering die zelfs bij de helft van de verwachte verbetering nog aantrekkelijk blijft. Scenarioanalyse voorkomt daarmee een vorm van schijnzekerheid.
Niemand weet vooraf exact hoeveel tijdswinst een nieuwe werkwijze uiteindelijk gaat opleveren. Dat hoeft ook niet. Een investeringsbesluit kan prima onder onzekerheid worden genomen, zolang zichtbaar is hoe gevoelig de uitkomst voor die onzekerheid is. Daarmee wordt een businesscase meer dan een berekening. Het wordt een manier om de aannames achter een project expliciet te maken.
Tabel 1 · Een eenvoudige businesscase voor procesautomatisering.
| Onderdeel | Kernvraag | Wat wil je vastleggen? |
|---|---|---|
| IST | Wat gebeurt er nu? | Volume, tijd, fouten en directe kosten. |
| SOLL | Wat moet anders? | De gewenste werkwijze en het concrete effect. |
| Doel | Waarom doen we dit? | Lagere kosten, meer opbrengst, capaciteit of risicoreductie. |
| Kosten | Wat investeren we? | Implementatie, licenties, interne uren en structurele kosten. |
| Opbrengsten | Wat krijgen we terug? | Harde besparingen en aantoonbaar inzetbare capaciteit. |
| ROI | Is het rationeel? | Basisscenario plus scenario’s met lagere tijdswinst. |
De beste proceskennis zit vaak op de werkvloer
Daarmee ontstaat ook de vraag wie verantwoordelijk is voor procesverbetering. Voor mij ligt het eigenaarschap uiteindelijk bij de leidinggevende. Die is verantwoordelijk voor de prestaties van een afdeling en daarmee ook voor de manier waarop processen binnen die afdeling functioneren.
Dat betekent niet dat procesverbeteringen van bovenaf moeten worden bedacht. Integendeel. De medewerker die dagelijks in het proces werkt, ziet vaak als eerste waar onnodige handelingen ontstaan, waar systemen niet goed op elkaar aansluiten en waar uitzonderingen structureel tot extra werk leiden. Die kennis is onmisbaar.
Ik zou alleen niet verwachten dat iedere operationele medewerker vervolgens zelfstandig een uitgebreide businesscase gaat bouwen. Dat zou procesverbetering zelf al snel onnodig zwaar maken.
Een medewerker moet kunnen aangeven: “Ik voer deze handeling vijftig keer per dag uit en volgens mij kan dit slimmer.” Dat is waardevolle input. Vervolgens is het aan de leidinggevende of projecteigenaar om samen met de juiste mensen vast te stellen hoe groot het probleem daadwerkelijk is, het proces te meten en de financiële vertaling te maken.
De operationele medewerker brengt daarmee de hypothese en praktijkkennis in. De leidinggevende draagt de verantwoordelijkheid om te bepalen of daar een investering uit voortkomt.
De businesscase stopt niet zodra het project wordt goedgekeurd
Ook de investering zelf wordt gemakkelijk te simplistisch voorgesteld. Stel dat een inefficiënt proces aantoonbaar €50.000 per jaar aan kosten veroorzaakt en een automatisering uiteindelijk €30.000 kost. Op papier lijkt de vergelijking eenvoudig.
Maar automatiseringsprojecten verlopen vaak gefaseerd. Kosten worden per maand of per oplevering gemaakt en tegelijkertijd kunnen de eerste onderdelen van de oplossing al waarde gaan opleveren voordat het project volledig is afgerond.
Wanneer na twee maanden 25 procent van het handmatige werk verdwijnt, wordt vanaf dat moment capaciteit vrijgemaakt. Wanneer een volgende oplevering de foutkans reduceert, ontstaan daar eveneens direct baten. Kosten en opbrengsten lopen tijdens het project dus naast elkaar.
Dat maakt de timing relevant. De vraag is niet alleen hoeveel de totale oplossing kost en hoeveel zij uiteindelijk jaarlijks oplevert, maar ook wanneer de verschillende investeringen plaatsvinden en vanaf welk moment de eerste voordelen ontstaan.
Een gefaseerde aanpak maakt daarnaast toetsing mogelijk. Wanneer na de eerste oplevering aanzienlijk minder tijd wordt bespaard dan vooraf verwacht, kan de businesscase worden bijgewerkt voordat opnieuw geld wordt geïnvesteerd. Daarmee zou een businesscase eigenlijk niet alleen vóór een project gebruikt moeten worden. Hij moet ook tijdens het project de meetlat blijven.
De houdbaarheid van technologie wordt onderdeel van de ROI
Naast kosten en opbrengsten speelt tegenwoordig nog een factor steeds nadrukkelijker mee: technologische houdbaarheid. Een vaste maximale terugverdientijd voor automatisering vind ik niet bijzonder zinvol. Een project met een lange terugverdientijd kan aantrekkelijk zijn wanneer de voordelen voldoende zeker zijn en de oplossing vervolgens jarenlang gebruikt kan worden.
Maar juist die tweede aanname is minder vanzelfsprekend geworden. Technologie ontwikkelt zich bijzonder snel. Vooral AI verandert de snelheid en kosten waarmee softwarefunctionaliteit kan worden ontwikkeld en bestaande processen kunnen worden geautomatiseerd.
Daardoor zou ik momenteel terughoudend zijn met grote maatwerksoftware-investeringen wanneer vergelijkbare functionaliteit waarschijnlijk via bestaande software, integraties of AI gerealiseerd kan worden. Dat betekent niet dat maatwerksoftware geen bestaansrecht meer heeft. Er zullen altijd processen zijn waarvoor specifieke functionaliteit essentieel is en standaardsoftware onvoldoende aansluit.
Maar een investering die over vier of vijf jaar moet worden terugverdiend, wordt minder aantrekkelijk wanneer er een serieuze kans bestaat dat een groot deel van dezelfde functionaliteit over relatief korte tijd veel goedkoper beschikbaar is. Technologische ontwikkeling verandert daarmee de klassieke ROI-discussie.
Niet alleen de vraag hoeveel een oplossing oplevert is relevant. Ook de vraag hoe lang het voordeel waarschijnlijk standhoudt. Een businesscase voor automatisering zou daarom steeds vaker rekening moeten houden met de economische levensduur van de gekozen oplossing.
AI verandert niet de economische logica
Die ontwikkeling maakt AI bijzonder interessant voor procesverbetering. Mijn eigen voorkeur zou op dit moment eerder liggen bij het onderzoeken hoe bestaande processen met AI en bestaande systemen kunnen worden verbeterd dan bij het direct ontwikkelen van grote maatwerkoplossingen.
Maar daarbij geldt dezelfde discipline. AI maakt een slechte businesscase niet goed.
Wanneer een AI-toepassing ervoor zorgt dat een Finance-medewerker een taak die eerst twintig uur per week kostte in tien uur kan uitvoeren, zijn tien uur aan capaciteit vrijgekomen. Wanneer die medewerker vervolgens structureel tien uur niets doet, is dat niet het falen van de AI-toepassing. Dan is het een managementvraagstuk.
De leidinggevende moet nadenken over wat er met die capaciteit gebeurt. Misschien ontstaat ruimte voor betere analyses, extra controles, nieuwe verantwoordelijkheden of groei zonder uitbreiding van de afdeling. Daarmee raakt automatisering ook aan organisatiedesign.
Hoe efficiënter processen worden, hoe belangrijker het wordt om opnieuw te bepalen welk werk medewerkers eigenlijk zouden moeten doen. Een automatisering kan technisch perfect functioneren en toch nauwelijks bedrijfswaarde creëren wanneer niemand nadenkt over wat er na de automatisering verandert.
Niet veranderen heeft ook een prijs
Wanneer een businesscase eenmaal goed is onderbouwd, moet ook worden voorkomen dat alleen naar de investeringskosten wordt gekeken. Een organisatie kan bijvoorbeeld vaststellen dat een proces aantoonbaar geld en capaciteit kost en dat een automatisering daar een positief rendement op kan leveren.
Het besluit om de investering niet te doen is dan evenzeer een keuze. Dat hoeft niet per definitie verkeerd te zijn. Misschien is beschikbare cash op dat moment nodig voor een belangrijker project. Misschien is de technologie nog onvoldoende volwassen of zijn andere investeringen aantrekkelijker.
Maar “de investering kost geld” is op zichzelf geen argument. De bestaande inefficiëntie kost immers eveneens geld. En zoals bij een gefaseerd project geldt, begint een investering vaak al tijdens de implementatie een deel van die bestaande kosten weg te nemen.
Daarom moet niet uitsluitend naar het totaalbedrag van het project worden gekeken. Een goede businesscase laat zien hoe kosten en baten zich gedurende de looptijd ontwikkelen. Het voorkomt dat een organisatie alleen ziet wat veranderen kost en vergeet wat niets veranderen blijft kosten.
Het grootste probleem hoeft niet als eerste opgelost te worden
Zelfs wanneer processen financieel zijn gemaakt, betekent dat niet automatisch dat het duurste proces als eerste moet worden geautomatiseerd. Stel dat proces A jaarlijks €40.000 kost om uit te voeren en voor €35.000 grotendeels kan worden geautomatiseerd. Proces B kost slechts €20.000 per jaar, maar een eenvoudige oplossing van €3.000 kan vrijwel alle inefficiëntie verwijderen. Het tweede project kan dan economisch veel aantrekkelijker zijn.
Daarom vind ik processen pas echt interessant wanneer zichtbaar is wat ze kosten. Niet omdat kosten automatisch bepalen welk proces moet worden aangepakt, maar omdat ze nodig zijn om verschillende investeringen met elkaar te vergelijken.
Een organisatie heeft altijd beperkte capaciteit, beperkt investeringsbudget en beperkte managementaandacht. Procesverbetering is daardoor uiteindelijk ook een vorm van kapitaalallocatie.
Welke verbetering levert per geïnvesteerde euro de meeste waarde? Welke verbetering kan snel worden gerealiseerd? Waar is het risico klein? En welke processen moeten juist eerst fundamenteel opnieuw worden ontworpen voordat automatisering überhaupt zinvol wordt?
Pas wanneer die vragen worden gesteld, verandert automatisering van een technisch project in een managementbesluit.
Automatisering is niet het doel
Daarmee kom ik uiteindelijk terug bij de vraag waarmee veel procesprojecten beginnen: wat kunnen we automatiseren?
Ik zou die vraag zo lang mogelijk uitstellen. Begin bij de operatie. Waar wordt aantoonbaar tijd verloren? Waar ontstaan fouten? Waar zijn medewerkers structureel bezig met repetitief werk? Waar ontstaat managementtijd door herstel en begeleiding? En waar voorkomt een bestaand proces dat de organisatie verder kan groeien?
Meet vervolgens hoe groot dat probleem werkelijk is. Vertaal het naar bedrijfswaarde. Beschrijf de huidige situatie en de gewenste situatie. Maak de kosten zichtbaar. Bepaal welke opbrengsten worden verwacht. Test meerdere scenario’s en kijk vervolgens welke oplossing het beste past.
Pas daarna wordt technologie interessant. Dat kan klassieke automatisering zijn. Het kan een aanpassing in bestaande software zijn. Het kan AI zijn. En soms blijkt de beste oplossing helemaal geen technologie te zijn, maar een eenvoudiger proces.
De technologie is daarmee slechts een middel. Een proces dat irritant is, is nog geen businesscase. Een proces dat handmatig is, is nog geen businesscase. En zelfs een proces waarin honderden uren kunnen worden bespaard, vormt op zichzelf nog geen businesscase.
Pas wanneer duidelijk is wat het huidige proces kost, welke waarde een verbetering creëert en waar die waarde uiteindelijk in de organisatie terechtkomt, kan worden bepaald of investeren rationeel is.
Bronnen en methodiek
Delta Trading B.V. is volledig fictief. De omzet, het aantal medewerkers, ordervolumes, tijdsbesteding, foutaantallen, kosten en automatiseringsscenario's in deze analyse zijn modelaannames die uitsluitend dienen om de financiële en operationele mechanismen inzichtelijk te maken. De vermelding dat de onderneming in deze case een aantal jaar later wordt bekeken, is bedoeld om de hogere fictieve omzet ten opzichte van eerdere Delta Trading-analyses consistent te duiden.
De berekeningen zijn illustratief en moeten in de praktijk worden gebaseerd op gemeten procesdata, direct toerekenbare kosten en onderbouwde aannames. Indirecte effecten worden alleen meegenomen wanneer daar een redelijk aantoonbaar verband met het proces of project voor bestaat.