Bedrijfsprocessen automatiseren: waar begin je?

Bedrijfsprocessen automatiseren betekent: handelingen die nu door mensen worden gedaan, laten doen door software. Niet omdat mensen het slecht doen, maar omdat het werk is dat niets toevoegt — gegevens overtypen, een export bijwerken, wachten tot iemand iets doorgeeft.

Dat is de definitie. De rest van dit artikel gaat over de vraag die daarop volgt en die veel lastiger is: wélk proces, en waar begin je.

De meeste automatiseringsgesprekken beginnen bij een tool. Dat is de verkeerde kant.

De bruikbare eerste vraag is niet "wat kunnen we automatiseren" maar "waar loopt het vast". Die twee lijken op elkaar en leiden tot verschillende projecten. Op de eerste vraag komt een lijst van alles wat technisch kan; op de tweede komt een korte lijst van dingen waar mensen dagelijks last van hebben. Die tweede lijst is korter, en hij is meer waard.

Een goede test: als niemand in de organisatie het proces mist wanneer het morgen anders loopt, was het het automatiseren waarschijnlijk niet waard.

In vrijwel elke organisatie die we binnenkomen, zitten dezelfde vier.

Dezelfde gegevens worden twee keer ingevoerd. Een order in de webshop én in het ERP, een klant in het CRM én in de boekhouding. Elke dubbele invoer kost tijd én is een plek waar twee systemen uit elkaar gaan lopen. Dit is meestal geen automatiseringsvraagstuk maar een koppeling.

Er bestaat een terugkerende export. Wekelijks of maandelijks, met de hand bijgewerkt en gemaild. Dat is al een geautomatiseerd proces — alleen draait het op een mens, en het staat stil zodra die er niet is.

Klanten bellen voor informatie die al bestaat. "Waar staat mijn order?" is een vraag waarvan het antwoord in een systeem staat waar de vrager niet bij kan. Dat is eerder een klantportaal dan automatisering, maar het is dezelfde soort verspilling.

Excel is het echte systeem. Als de waarheid in een spreadsheet staat die niemand durft aan te raken, heb je al maatwerk — alleen ongedocumenteerd, zonder rechten en zonder back-up.

Dit deel ontbreekt in de meeste stukken over dit onderwerp, en het is het deel dat geld bespaart.

Een proces dat niet klopt. Automatiseren maakt een slecht proces sneller, niet beter. Als een goedkeuringsstap er ooit is ingeslopen zonder dat iemand meer weet waarom, is hem weghalen goedkoper dan hem automatiseren.

Een handeling die één keer per kwartaal voorkomt. De bouw- en onderhoudskosten lopen door, de besparing niet.

Een beslissing die oordeel vraagt. Software is uitstekend in het voorbereiden van een beslissing — alles bij elkaar zetten, uitzonderingen markeren — en slecht in het nemen ervan wanneer de afweging elke keer anders is.

Het proces dat je nog gaat veranderen. Automatiseer wat stabiel is. Wat volgend kwartaal anders werkt, bouw je twee keer.

Het duidelijkste voorbeeld uit ons eigen werk is Keana, planningssoftware voor stadslogistiek waarvan wij het volledige engineeringteam zijn.

Het proces: transportorders komen binnen bij een hub en moeten ritten worden. Welk voertuig, welk tijdvenster, welke stops, in welke volgorde. Klinkt overzichtelijk tot je gaat rekenen. Een rit is pas bruikbaar als hij aan alles tegelijk voldoet — het tijdvenster van elke stop, want een ontvanger die dicht is telt niet als bezorgd; het laadvermogen; de actieradius, wat bij elektrisch vervoer een harde grens is in plaats van een detail; en temperatuurklassen, want gekoelde en droge lading passen niet zomaar in dezelfde bak.

Elk van die eisen op zich is te overzien. Bij elkaar is het precies het soort probleem waar een planner op handkracht op vastloopt. Dat is waar automatiseren het verschil maakt: niet bij het simpele werk, maar bij het werk waar te veel voorwaarden tegelijk gelden.

En let op wat het oplevert. Niet "een strakkere planning" — minder busjes door binnensteden die daar nooit voor gebouwd zijn. Een automatiseringsproject dat zijn opbrengst niet in dat soort termen kan uitdrukken, mist waarschijnlijk zijn doel.

Hetzelfde patroon zit in CyberCloud Voice Analytics: elk telefoongesprek gaat automatisch door transcriptie, zodat niemand hoeft te luisteren, te labelen of samen te vatten. Zolang een archief uit audio bestaat is het een stapel; zodra het uit tekst bestaat is het een index.

De uitzondering die 80% van het werk blijkt. Het hoofdproces is in een week gebouwd, en dan komen de gevallen die "bijna nooit voorkomen" maar in de praktijk de helft van de tijd. Vraag daar vroeg naar, niet laat.

Alles tegelijk. Een project dat pas na maanden iets oplevert, levert vaak iets op wat inmiddels niet meer past. Wij werken Agile en zetten liever iets werkends neer dat je kunt gebruiken.

Niemand is eigenaar. Een geautomatiseerd proces heeft iemand nodig die merkt dat het stuk is. Zonder die persoon ontdek je het als een klant belt.

Het draait op één iemands macro. Vaker dan je denkt is de bestaande automatisering een script van een collega die er niet meer werkt.

Neem het proces dat het vaakst terugkomt en het minst oordeel vraagt. Meet eerst hoe vaak het gebeurt en hoe lang het duurt — dat kost een week en het voorkomt dat je iets bouwt waarvan de opbrengst niet aantoonbaar is.

Bouw daarna het kleinste stuk dat op zichzelf al bruikbaar is, en zet het in gebruik. Wat je daarvan leert, bepaalt het volgende stuk beter dan een ontwerp vooraf.

In de praktijk komt de oplossing meestal neer op één van drie dingen: een koppeling tussen systemen die elkaar nog niet kennen, een klantportaal waarmee mensen zelf vinden wat ze zoeken, of maatwerk software voor een proces dat te specifiek is voor een pakket. Welke van de drie het wordt, blijkt uit de eerste vraag — niet uit de laatste.

Benieuwd welk proces bij jullie het meeste oplevert om aan te pakken? Daar denken we graag een uur over mee voordat er iets gebouwd wordt.