Wanneer automatisering niet het juiste antwoord is

De meeste artikelen over automatisering gaan ervan uit dat het besluit al genomen is. Dit artikel niet. Ongeveer een derde van de processen die mensen bij ons aandragen zou niet geautomatiseerd moeten worden, in elk geval nog niet. Dat ontdekken tijdens een scopinggesprek is aanzienlijk goedkoper dan het ontdekken na een build.

Zo herkent u het verschil.

Het proces verandert om de paar maanden

Automatisering legt een proces vast. Beweegt het proces nog, dan legt u een bewegend doel vast, en elke wijziging in de werkwijze wordt een wijzigingsverzoek op het systeem.

Het signaal waar u op let is niet hoe vaak het proces op papier verandert, maar hoe vaak de mensen die het uitvoeren het oneens zijn over de stappen. Vraag drie mensen het proces te beschrijven. Krijgt u drie verschillende antwoorden, dan heeft u nog geen proces maar een gewoonte. Een gewoonte automatiseren levert een systeem op dat de versie van één persoon vastlegt en voor de rest stilletjes misgaat.

Zet het proces eerst recht, op papier, samen met de mensen die het uitvoeren. Automatiseer daarna de versie waar iedereen het over eens is.

Het volume rechtvaardigt het onderhoud niet

Een build kent twee kosten: die u eenmalig betaalt en die u blijvend betaalt. De tweede ontbreekt meestal in de businesscase.

Een koppeling die drie externe systemen raakt, gaat stuk zodra een van die drie verandert. Iemand moet dat opmerken, uitzoeken en herstellen. Dat is geen eenmalige kostenpost maar een doorlopende verplichting, en die schaalt niet mee omlaag bij lage volumes. Een workflow die elf keer per maand draait, kost al snel meer om in de lucht te houden dan hij bespaart.

De vuistregel: kan één persoon het maandvolume in een dag wegwerken, dan gaat automatisering waarschijnlijk over gemak en niet over geld. Dat is een legitieme reden om iets te bouwen, maar presenteer het dan ook zo en niet als besparing.

Niemand is eigenaar van de uitkomst

Geautomatiseerde systemen falen stil. Iemand die achterloopt met facturen laat dat weten. Een pijplijn die drie weken geleden ongemerkt stopte met wegschrijven laat niets weten, en u komt erachter wanneer iemand vraagt waarom de cijfers vreemd zijn.

Wijs voordat u iets automatiseert de persoon aan die het merkt als het stopt. Niet de aanvrager en niet de leverancier. Iemand binnen de organisatie die vaak genoeg naar de uitkomst kijkt om te zien wanneer die afwijkt. Kunt u die persoon niet noemen, dan bent u er nog niet klaar voor, want een automatisering zonder eigenaar faalt erger dan het handmatige proces dat hij verving: u krijgt onjuiste gegevens in plaats van late gegevens, en onjuiste gegevens vallen minder snel op.

Het moeilijke zit in het oordeel, niet in het werk

Sommige taken lijken repetitief maar zijn dat niet. Een contract beoordelen is mechanisch tot de bepaling die ertoe doet ongebruikelijk geformuleerd is. Een lead kwalificeren is mechanisch tot de prospect een vreemde eend blijkt die een mens meteen herkent.

Zit de waarde van het werk in de uitzonderingen in plaats van in het volume, dan verplaatst automatisering uw kosten in plaats van ze weg te nemen. U bespaart de makkelijke 80% en levert uw team een wachtrij met de lastige 20% zonder context, wat vaak trager is dan alles achter elkaar afhandelen.

Wat hier wel werkt is human in the loop: het systeem handelt de heldere gevallen af en escaleert de rest met alles wat de beoordelaar nodig heeft om snel te beslissen. Dat is een andere, duurdere build dan volledige automatisering, en zo hoort hij ook begroot te worden.

Het helpt ook om vooraf helder te hebben wat u koopt. Het onderscheid tussen een agent en een automatisering bepaalt het grootste deel van de kosten, en de twee worden door elkaar verkocht.

De vragen die u eerst stelt

Voordat u budget vrijmaakt, zorg voor eerlijke antwoorden op deze vragen:

1. Beschrijven drie mensen dit proces op dezelfde manier?
2. Hoe vaak draait het per maand, en wat kost één keer werkelijk aan tijd?
3. Wie merkt binnen een dag dat het niet meer werkt?
4. Welk deel van de gevallen vraagt een oordeel, en wat gebeurt daarmee?
5. Wat gaat verderop stuk als de uitkomst onjuist is in plaats van afwezig?

Hebben vraag één tot en met drie geen helder antwoord, dan is het probleem nog niet technisch.

Wat u in plaats daarvan doet

Niet automatiseren is zelden het einde van het gesprek. Meestal is een van deze stappen beter:

• Standaardiseer voordat u bouwt. Leg het proces vast en volg het een kwartaal consequent. Houdt het stand, dan automatiseert u het. Zo niet, dan heeft u een build uitgespaard.
• Automatiseer één stap, niet de hele workflow. Documentextractie is vaak het werkelijk mechanische deel van een proces waarvan de beslissingen dat niet zijn. Pak dat stuk en laat de rest.
• Repareer de invoer. Opvallend veel automatiseringsvragen zijn eigenlijk datakwaliteitsproblemen. Wordt er overgetypt omdat de export erboven onbruikbaar is, dan is die export repareren goedkoper dan een systeem bouwen dat ermee omgaat.

De overige gidsen over workflow-automatisering gaan ervan uit dat u deze filter al heeft doorlopen. Laat u dat liever samen met iemand doen, dan is daar de AI readiness audit voor: de oplevering is een shortlist van wat het bouwen waard is, en die komt soms leeg terug.

Veelgestelde vragen

Hoe weet ik of mijn proces stabiel genoeg is?

Vraag drie mensen die het uitvoeren om de stappen los van elkaar te beschrijven. Komen de antwoorden overeen, dan is het stabiel. Zo niet, leg dan de gewenste versie vast, draai die een kwartaal handmatig en kijk er opnieuw naar.

Is een proces met laag volume ooit de moeite waard?

Ja, wanneer de kosten niet in tijd zitten. Compliancecontroles die nooit overgeslagen mogen worden, of stappen waar een menselijke fout duur uitpakt, rechtvaardigen een build bij laag volume. Onderbouw dat op risico, niet op bespaarde uren.

Wat als we al iets gebouwd hebben dat niet gebruikt wordt?

Dat is meestal een eigenaarschapsprobleem en geen technisch probleem. Zoek uit of iemand ooit verantwoordelijk was voor de uitkomst. Opnieuw bouwen zonder dat op te lossen levert twee keer dezelfde uitkomst op.

Kunnen we klein beginnen en later uitbreiden?

Dat is de juiste reflex, en daarom scopen we prototypes voordat we volledig bouwen. Wat u wilt voorkomen is een prototype dat stilletjes productie wordt zonder dat iemand dat besloten heeft.