Process mining voor AI-automatisering
Process mining laat zien hoe werk in werkelijkheid door systemen loopt: niet zoals het proceshandboek het beschrijft, maar zoals gebeurtenissen in systeemlogs ze vastleggen. Je leest welke inzichten bruikbaar zijn om automatisering te kiezen en waarom logdata alleen nooit het hele procesverhaal vertelt.
Wat process mining uit systeemlogs haalt
Process mining gebruikt gebeurtenisgegevens uit bedrijfssoftware om te reconstrueren welke stappen een proces doorloopt. Een gebeurtenis is bijvoorbeeld het aanmaken, goedkeuren of afsluiten van een bestelling. Als zulke gebeurtenissen aan hetzelfde dossier of dezelfde bestelling gekoppeld zijn en een tijdstip hebben, kunnen ze samen een procespad vormen. Dat pad maakt zichtbaar welke activiteiten vaak voorkomen, in welke volgorde ze plaatsvinden en hoeveel tijd ertussen zit.
Dat verschilt van een procesbeschrijving op basis van interviews of workshops. Medewerkers beschrijven doorgaans de bedoelde werkwijze, terwijl systeemgegevens laten zien wat binnen de gekozen systemen daadwerkelijk is geregistreerd. Een analyse kan bijvoorbeeld aantonen dat een factuur geregeld teruggaat naar een eerdere goedkeuringsstap, of dat bepaalde dossiers veel langer blijven liggen dan andere. Ook uitzonderingen en alternatieve routes worden zichtbaar, zelfs als niemand ze als officieel proces heeft beschreven.
De uitkomst is geen automatische diagnose van de oorzaak. Een lange pauze kan wijzen op een wachtrij, maar ook op een stap die buiten kantooruren plaatsvindt of op een tijdstempel die pas later wordt vastgelegd. Process mining helpt dus eerst het patroon te zien. Daarna is aanvullend onderzoek nodig om te begrijpen waarom het ontstaat en of verandering wenselijk is. Juist dat onderscheid voorkomt dat een opvallende grafiek meteen wordt vertaald naar een automatiseringsopdracht.
Eventlogs bruikbaar maken met cases, activiteiten en tijdstippen
Een eventlog is pas bruikbaar als gebeurtenissen aan een herkenbaar procesobject gekoppeld kunnen worden. Zo’n object heet vaak een case: bijvoorbeeld een klantaanvraag, order, retour of factuur. Daarnaast is per gebeurtenis minimaal een activiteit en een tijdstip nodig. Zonder een betrouwbare case-ID kunnen gebeurtenissen van verschillende dossiers door elkaar raken. Zonder duidelijke activiteitennamen is niet vast te stellen of twee registraties dezelfde stap voorstellen of iets wezenlijk anders betekenen.
In de praktijk staan deze gegevens verspreid over systemen en tabellen. Een CRM-pakket kan de aanvraag bevatten, een ERP-systeem de order en een ticketsysteem de uitzondering. Koppelen op één gedeeld nummer is ideaal, maar dat nummer ontbreekt geregeld of verandert tijdens de overdracht. Dan zijn samengestelde sleutels nodig, zoals klantnummer, documentnummer en een tijdvenster. Zulke koppelingen vragen controle: een te ruime match kan verschillende cases samenvoegen, terwijl een te strenge match gebeurtenissen juist kwijtraakt.
Ook tijdstippen verdienen aandacht. Is een registratie de tijd waarop iemand handelde, waarop een systeem de actie opsloeg of waarop een batch de gegevens verwerkte? Tijdzones, correcties en vertraagde synchronisatie kunnen de volgorde vertekenen. Maak daarom expliciet welke timestamp leidend is en controleer steekproeven tegen dossiers in de bronsystemen. Een praktisch begin is vaak een afgebakend proces, één objecttype en een beperkte periode. Dat levert sneller een toetsbaar beeld op dan een poging om meteen alle systemen en varianten in één model te verenigen.
Procesvarianten onthullen waar de standaardroute afwijkt
Een procesmodel toont niet alleen de meest voorkomende route, maar ook de varianten eromheen. Een bestelling kan bijvoorbeeld rechtstreeks worden verwerkt, extra goedkeuring nodig hebben, worden aangepast of na een fout opnieuw worden aangemaakt. Die varianten zijn niet automatisch verspilling. Een afwijkende route kan nodig zijn bij een hoog bedrag, een nieuwe leverancier of een wettelijke controle. De eerste vraag is daarom niet hoe je alle varianten verwijdert, maar welke varianten verklaarbaar en waardevol zijn.
Om patronen te beoordelen, kun je cases uitsplitsen naar kenmerken zoals productgroep, kanaal, klanttype, regio of bedrag. Daarmee wordt zichtbaar of een afwijking samenhangt met een specifieke situatie. Let wel op dat een segment met weinig dossiers grillige percentages kan opleveren. Een route die in een kleine steekproef vaak voorkomt, hoeft op jaarbasis niet belangrijk te zijn. Bekijk daarom zowel het aandeel cases als het absolute volume en onderzoek of de periode representatief is, bijvoorbeeld voor seizoenspieken.
Een veelgemaakte fout is het model zo sterk vereenvoudigen dat alleen de dominante route overblijft. Dan verdwijnen juist de uitzonderingen die automatisering kwetsbaar kunnen maken. Het omgekeerde gebeurt ook: ieder verschil in systeemregistratie wordt als een eigen procesvariant behandeld. Kleine verschillen in benaming of logging kunnen zo een onleesbaar model opleveren. Groepeer activiteiten pas nadat duidelijk is wat ze betekenen en houd uitzonderingen zichtbaar wanneer ze gevolgen hebben voor risico, klantbehandeling of benodigde beslissingen. Zo wordt variatie informatie voor ontwerpkeuzes in plaats van ruis die weggepoetst moet worden.
Doorlooptijd en wachttijd uit elkaar houden
Doorlooptijd is de tijd tussen het begin en einde van een case, maar zegt op zichzelf weinig over waar de vertraging ontstaat. Een dossier kan in totaal vijf dagen duren, terwijl medewerkers er slechts een halfuur actief aan werken. Process mining kan tussen geregistreerde activiteiten grote tijdsintervallen laten zien. Die intervallen zijn aanwijzingen voor mogelijke wachttijd, bijvoorbeeld doordat een dossier wacht op informatie, capaciteit of een besluit. Ze bewijzen niet vanzelf dat er gedurende die hele periode niets gebeurde.
Om wachttijd goed te duiden, vergelijk je cases met vergelijkbare kenmerken en controleer je de betekenis van de gebeurtenissen. Denk aan werkdagen versus kalenderdagen, openingstijden, feestdagen en overdrachten naar externe partijen. Een stap kan ook pas worden gelogd nadat werk al is uitgevoerd. In dat geval lijkt de voorafgaande wachttijd langer dan hij werkelijk was. Combineer daarom loggegevens waar mogelijk met roosters, statusvelden, servicetijden of dossieronderzoek. Een gesprek met medewerkers die de overdracht uitvoeren kan verklaren waarom een ogenschijnlijk eenvoudige stap blijft liggen.
Niet elk lang interval is bovendien een geschikte automatiseringskans. Als een aanvraag drie dagen op ontbrekende informatie wacht, kan een automatische herinnering helpen. Als de vertraging ontstaat doordat een specialist een inhoudelijk risico beoordeelt, is versnellen misschien niet verantwoord. Kijk ook naar spreiding: gemiddelde tijden verbergen vaak een kleine groep cases met zeer lange vertraging. Percentielen, zoals de mediaan en de negentigste percentielwaarde, geven een genuanceerder beeld. Zo voorkom je dat een interventie wordt ontworpen voor het gemiddelde dossier terwijl de grootste problemen juist bij uitzonderingen zitten.
Van procesinzicht naar geschikte automatiseringskandidaten
Een zichtbaar knelpunt is nog geen goede kandidaat voor AI-automatisering. Begin met de aard van het werk: is de stap herhaalbaar, zijn de benodigde gegevens beschikbaar en is de uitkomst voldoende voorspelbaar? Een regelmatige statusoverdracht met vaste voorwaarden kan geschikt zijn voor gewone workflowautomatisering. Het uitlezen van uiteenlopende documenten vraagt mogelijk om AI voor documentverwerking. Een stap waarin informatie wordt samengebracht en een voorstel wordt gedaan, kan passen bij een AI-agent, maar vraagt doorgaans om expliciete grenzen en menselijke controle.
Gebruik process mining om te achterhalen waar een stap plaatsvindt, hoe vaak die voorkomt en welke cases erdoorheen gaan. Combineer dat met informatie over fouten, herstelwerk en gevolgen voor klanten. Een activiteit die duizenden keren terugkomt maar zelden problemen veroorzaakt, kan meer waarde opleveren dan een zeldzame stap met veel handwerk per geval. Omgekeerd kan automatisering van een laagvolumeproces belangrijk zijn als fouten grote financiële of juridische gevolgen hebben. Frequentie alleen is dus geen volledige prioritering.
Leg vóór het ontwerp vast wat de automatisering moet veranderen en hoe je dat meet. Denk aan minder handmatige invoer, kortere wachttijd of minder herstelwerk, maar benoem ook grenzen zoals foutpercentage en het aantal gevallen dat naar een medewerker gaat. Als het proces veel uitzonderingen kent, kan ondersteuning in plaats van volledige afhandeling verstandiger zijn: AI verzamelt gegevens of doet een voorstel, terwijl een medewerker beslist. Zo leidt procesinzicht niet tot de aanname dat alles wat vaak voorkomt volledig zelfstandig kan worden afgehandeld.
Waar logdata een onvolledig beeld van het proces geeft
Systeemlogs registreren wat software vastlegt, niet noodzakelijk alles wat medewerkers doen. Een medewerker kan informatie controleren in een e-mail, een spreadsheet gebruiken of telefonisch afstemmen zonder dat die handelingen in het centrale systeem verschijnen. In een procesmodel lijkt het dan alsof een dossier rechtstreeks van de ene systeemstap naar de volgende gaat. In werkelijkheid kan er veel handwerk tussen zitten. Andersom kan een automatisch systeem meerdere gebeurtenissen registreren voor één handeling, waardoor het proces drukker oogt dan het is.
Ook informele routes vallen gemakkelijk buiten beeld. Een manager kan een besluit mondeling geven, waarna iemand het pas later registreert. Een gedeelde inbox kan werk verdelen zonder dat duidelijk wordt wie welke taak heeft opgepakt. Wanneer process mining alleen de formele applicaties gebruikt, blijft de menselijke afhandeling dus deels verborgen. Dat is belangrijk bij automatisering: juist het niet-geregistreerde werk kan bestaan uit uitzonderingen, interpretatie of overleg dat niet eenvoudig in een vaste workflow past.
Maak de grenzen van het model daarom expliciet. Beschrijf welke systemen, teams en periode zijn meegenomen en welke werkzaamheden buiten de analyse vallen. Toets opvallende routes met medewerkers en vergelijk steekproeven met volledige dossierhistorie, e-mails of andere bronnen voor zover dat toegestaan en proportioneel is. Het doel is niet om elk menselijk detail te registreren, maar om te weten welke blinde vlekken de analyse beïnvloeden. Een procesmodel dat zijn beperkingen benoemt, is bruikbaarder dan een ogenschijnlijk compleet model dat informele stappen stilzwijgend als afwezig behandelt.
Datakwaliteit, privacy en interpretatie beheersen
De kwaliteit van process mining hangt af van de kwaliteit van de onderliggende registraties. Dubbele gebeurtenissen kunnen een activiteit vaker laten lijken dan zij voorkomt. Ontbrekende eindmomenten vertekenen doorlooptijden, terwijl een verkeerde case-ID twee dossiers kan samenvoegen. Ook wijzigingen in software of werkwijze kunnen plotselinge sprongen in de data veroorzaken. Controleer daarom op ontbrekende waarden, dubbele regels, onmogelijke tijdsvolgordes en veranderingen in volumes. Leg aannames vast, zodat een analyse later opnieuw kan worden uitgevoerd en verschillen verklaarbaar blijven.
Privacy vraagt om een doelgerichte aanpak. Voor veel procesvragen zijn namen of directe identificerende gegevens niet nodig. Pseudonimiseer waar mogelijk, beperk de dataset tot relevante velden en bepaal wie toegang krijgt. Als analyse op medewerkersniveau wordt overwogen, vraagt dat extra zorg: verschillen kunnen samenhangen met taakverdeling, casemix of systeemtoegang en zijn niet zonder meer een maat voor individuele prestaties. Betrek privacy- en medezeggenschapsverplichtingen vroeg, niet pas nadat gegevens al zijn samengebracht.
Interpretatie verdient dezelfde discipline als techniek. Een correlatie tussen een bepaalde route en een lange doorlooptijd toont niet automatisch dat die route de vertraging veroorzaakt. Misschien komen juist de complexste cases op die route terecht. Vergelijk waar mogelijk gelijksoortige dossiers en bespreek alternatieve verklaringen met proceseigenaren. Documenteer ook definities: wat telt als een afgeronde case, welke gebeurtenissen zijn samengevoegd en hoe zijn ontbrekende tijdstippen behandeld? Daardoor kunnen teams beslissingen baseren op inzicht in de onzekerheid, in plaats van op cijfers die preciezer lijken dan de registratie rechtvaardigt.
Automatisering gecontroleerd toetsen aan de praktijk
Voordat een proceswijziging breed wordt ingevoerd, is het verstandig de veronderstellingen achter de automatisering te toetsen. Selecteer een afgebakende groep cases of een beperkt procesonderdeel en vergelijk de uitkomsten met een passende referentie. Meet niet alleen of de verwerking sneller gaat, maar ook of dossiers vaker worden teruggestuurd, fouten ontstaan of medewerkers extra herstelwerk krijgen. Als de cases tijdens de proef verschillen van de normale instroom, bijvoorbeeld doordat uitzonderingen ontbreken, kan het resultaat een te rooskleurig beeld geven.
Leg vooraf vast wanneer de automatisering zelfstandig mag handelen en wanneer een medewerker moet ingrijpen. Dat kan afhangen van ontbrekende gegevens, lage modelzekerheid, afwijkende bedragen of een onbekend documenttype. Registreer vervolgens ook deze overdrachten en de redenen ervoor. Zonder die gegevens blijft onduidelijk of de menselijke controle zelden nodig is, of dat het systeem juist veel moeilijke gevallen doorstuurt. Een controlepad is bovendien alleen bruikbaar als medewerkers weten welke informatie zij moeten beoordelen en hoe zij een fout of uitzonderingssituatie terugmelden.
Na invoering kan het proces veranderen: nieuwe regels, veranderde klantvragen of aanpassingen in bronsoftware beïnvloeden de routes en de kwaliteit van voorspellingen. Volg daarom relevante indicatoren en vergelijk nieuwe procesdata met de uitgangssituatie, maar onderzoek afwijkingen voordat je conclusies trekt. Een stijging in uitzonderingen kan bijvoorbeeld komen door betere registratie in plaats van slechtere automatisering. Beheer ook versies van prompts, modellen, beslisregels en koppelingen, zodat duidelijk is welke inrichting bij welke resultaten hoorde. Zo wordt de evaluatie een toets van het echte werkproces, niet alleen van de technische werking van een automatiseringscomponent.
Veelgestelde vragen
Wat is het verschil tussen process mining en task mining?
Process mining analyseert gebeurtenissen die in bedrijfssoftware zijn vastgelegd; task mining brengt handelingen op het scherm van individuele gebruikers in kaart. Process mining geeft vooral inzicht in de volgorde en samenhang van processtappen over meerdere cases. Task mining kan juist laten zien welke klik-, kopieer- of invoerhandelingen binnen een taak plaatsvinden.
- Kies process mining als je de route en prestaties van een proces wilt onderzoeken.
- Kies task mining als je wilt begrijpen hoe mensen een specifieke taak uitvoeren.
- De methoden kunnen elkaar aanvullen, maar task mining vraagt extra aandacht voor privacy en de manier waarop werk wordt gemonitord.
Is process mining hetzelfde als RPA?
Nee, process mining is een analysemethode en RPA is technologie die repetitieve taken automatiseert. Process mining kan helpen bepalen waar werk verloopt zoals bedoeld en waar verder onderzoek nodig is. RPA voert vervolgens vooraf ingerichte handelingen uit, bijvoorbeeld gegevens overzetten tussen systemen. De ene technologie vervangt de andere dus niet.
- Gebruik process mining om een proces te onderzoeken en mogelijke verbeteringen te onderbouwen.
- Gebruik RPA wanneer een taak voldoende stabiel en voorspelbaar is om volgens vaste regels uit te voeren.
- Een analyse kan ook uitwijzen dat procesaanpassing of een andere vorm van automatisering geschikter is dan RPA.
Hoe bereken je de ROI van process mining?
Bereken de ROI door de aantoonbare opbrengsten van een process-miningproject te vergelijken met alle kosten ervan. Maak vooraf een nulmeting en bepaal welke resultaten je verwacht, zodat je na invoering dezelfde definities en periode kunt gebruiken. Neem niet alleen tijdwinst mee, maar ook eventuele veranderingen in fouten, herstelwerk en klantimpact.
- Breng kosten in kaart, zoals software, implementatie, datavoorbereiding en beheer.
- Schat opbrengsten op basis van gemeten volumes en realistische besparingen per case.
- Vergelijk de uitkomst met de situatie vóór de verandering en vermeld onzekerheden, zoals seizoenseffecten of veranderde volumes.
Hoe lang duurt een process-miningproject?
De duur van een process-miningproject hangt vooral af van de beschikbaarheid en kwaliteit van de gegevens, de complexiteit van het proces en de gewenste reikwijdte. Een afgebakende verkenning met één proces en een beperkt aantal bronnen kan sneller inzicht geven dan een organisatiebreed traject. Er is daarom geen vaste doorlooptijd die voor elk project geldt.
- Begin met een concrete procesvraag en bepaal welke gegevens daarvoor nodig zijn.
- Plan tijd in voor gegevenskoppeling, kwaliteitscontroles en toetsing van de uitkomsten met proceseigenaren.
- Neem ook de tijd mee die nodig is om bevindingen om te zetten in een verandering en het effect daarvan te meten.
Welke soorten process mining zijn er?
De drie gangbare soorten process mining zijn process discovery, conformance checking en enhancement. Ze beantwoorden verschillende vragen: discovery maakt een procesmodel op basis van gegevens, conformance checking vergelijkt de praktijk met een bestaand model en enhancement verrijkt een model met extra informatie. Samen kunnen ze inzicht geven in zowel de procesroute als de prestaties ervan.
- Discovery: welk procesmodel blijkt uit de beschikbare gebeurtenissen?
- Conformance checking: waar wijkt de geregistreerde uitvoering af van afspraken of een referentiemodel?
- Enhancement: hoe kan een bestaand model worden aangevuld, bijvoorbeeld met informatie over doorlooptijden of prestaties?