Event log

Wat is een event log?

Een event log is een tabel waarin elke regel één ding zegt: op dit tijdstip gebeurde deze stap voor deze case. Zet je al die regels op volgorde, dan krijg je het werkelijke verloop van een proces zoals het in je systemen zit opgeslagen.

Het is de grondstof waar process mining op werkt. Een tool leest de event log en reconstrueert daaruit de procesplaat: welke stappen volgen elkaar op, welke paden komen vaak voor, waar blijven cases hangen. Zonder event log geen process mining, zo eenvoudig is het.

Vergelijk het met de GPS-geschiedenis van je auto. Elke afslag, elke halte en elk tijdstip staat geregistreerd. Uit die rij punten kan je achteraf de volledige rit reconstrueren, ook al heb je er zelf niet op gelet tijdens het rijden.

Wat staat er in een event log?

Elke regel heeft drie vaste velden. De literatuur rond process mining noemt dit de basis, en zowel de IEEE XES-standaard als de grote tools (Microsoft Power Automate Process Mining, Celonis, Fluxicon Disco) vertrekken vanuit dezelfde drie.

• Case ID: de unieke sleutel van één procesdoorgang. In de praktijk is dat vaak een ordernummer, factuurnummer, ticketnummer of patiëntdossier. Alle events met dezelfde case ID horen bij elkaar.

• Activity: de naam van de stap die gezet is, bijvoorbeeld "order aangemaakt", "factuur goedgekeurd" of "ticket gesloten".

• Timestamp: het tijdstip waarop die stap gebeurd is. Eén timestamp per regel is voldoende voor de meeste analyses. Werk je met activiteiten die tijd vragen, dan kan je ook een start- en eindtijdstip meegeven.

Daarnaast kan je de log verrijken met optionele velden die je analyse dieper maken:

• Resource: wie de stap uitvoerde, een medewerker of een systeem.

• Case-attributen: info die voor de hele case geldt, zoals klantsegment, business unit of factuurbedrag.

• Event-attributen: info die per regel verschilt, zoals de afdeling die de stap deed of de financiële waarde van die specifieke actie.

De drie verplichte velden bepalen of je analyse kan starten. De extra velden bepalen hoe fijn je kan filteren en segmenteren eens ze draait.

Waar komt een event log vandaan?

Elk bedrijfssysteem dat acties registreert is een potentiële bron. In de praktijk zien we vooral:

• ERP-systemen zoals SAP, Microsoft Dynamics of NetSuite voor financiële en operationele processen.

• CRM-systemen zoals Salesforce of Dynamics 365 voor verkoop- en klantprocessen.

• Ticketsystemen zoals ServiceNow, Jira of Zendesk voor support en IT.

• Applicatie-logs van eigen software of workflow engines die elke stap wegschrijven.

• Sensordata en machine-logs in productie en logistiek, waar elke scan of meting een event wordt.

Zelden is de event log kant-en-klaar aanwezig. Meestal moet je hem samenstellen, en dat is het werk waar de meeste tijd in kruipt. Je haalt stukken uit een orders-tabel, stukken uit een goedkeuringen-tabel, stukken uit een facturentabel, en plakt ze aan elkaar via de case ID. Microsoft Learn waarschuwt daar expliciet voor: de data zit vaak in één log-tabel die nog gejoind moet worden met andere tabellen om de juiste ID's of namen binnen te krijgen.

In Dynamics vind je de acties terug in de tabel Activities, in SAP en Salesforce bestaat er een vergelijkbaar concept onder een andere naam. Het is meestal de IT-collega die dat systeem beheert die weet waar de goede data zit.

Wat maakt een event log bruikbaar voor process mining?

Een event log die op papier klopt kan in de praktijk nog altijd onbruikbaar zijn. Vier punten bepalen of je analyse hout snijdt.

Geen lege velden op de verplichte kolommen. Celonis is daar hard in: geen enkele rij mag een lege case ID, activity of timestamp hebben. Eén leeg veld op honderdduizend regels kan je procesplaat uit balans trekken, want die regels vallen buiten de analyse of komen op de verkeerde case terecht.

Eén activiteit per regel, op het juiste detailniveau. Ga je te fijn, dan wordt de procesplaat een warboel. Ga je te grof, dan verlies je de stappen waar het om draait. Een goedkeuring van drie handtekeningen kan één activiteit zijn, of drie, afhankelijk van wat je wil analyseren.

Tijdstippen die kloppen en vergelijkbaar zijn. Eén systeem schrijft in UTC, een ander in lokale tijd. Eén tabel heeft seconden, een andere enkel de datum. Zet alles om naar dezelfde tijdzone en hetzelfde formaat, en gebruik een sorteringskolom als twee events dezelfde timestamp hebben.

De juiste case ID voor je vraag. Een event log voor order-to-cash met het factuurnummer als case ID vertelt een ander verhaal dan dezelfde data met het ordernummer als case ID. De keuze bepaalt wat de tool als één stroom behandelt.

Voorbeeld: event log voor order-to-cash

Zo ziet een minimale event log eruit voor één order die via SAP loopt, case ID ORD-10042:

• ORD-10042 | Order aangemaakt | 2026-03-14 09:12

• ORD-10042 | Kredietcheck uitgevoerd | 2026-03-14 09:47

• ORD-10042 | Order goedgekeurd | 2026-03-14 14:03

• ORD-10042 | Goederen verzonden | 2026-03-17 11:20

• ORD-10042 | Factuur verstuurd | 2026-03-17 16:45

• ORD-10042 | Betaling ontvangen | 2026-04-08 10:02

Zes regels, één case, zes timestamps. Voeg daar duizenden andere orders aan toe en de tool kan de varianten groeperen, de doorlooptijd per stap berekenen, en tonen waar cases structureel blijven hangen (bijvoorbeeld tussen goedkeuring en verzending, of tussen factuur en betaling).

Event log versus audit-log en applicatie-log

Drie soorten logs die op elkaar lijken maar een ander doel dienen.

Een database-audit-log registreert wie welk veld wanneer gewijzigd heeft, voor compliance en forensisch onderzoek. Het niveau is technisch: UPDATE op tabel X, kolom Y, door user Z. Je krijgt er een perfecte audit trail uit, maar geen leesbare proceskaart.

Een applicatie-log legt vast wat de software zelf aan het doen was: errors, waarschuwingen, aanroepen van andere diensten. Nuttig voor IT-beheer, maar zelden op het niveau van een bedrijfsproces.

Een event log voor process mining zit ertussenin. Hij spreekt de taal van het proces ("factuur goedgekeurd" in plaats van "UPDATE invoice SET status=2"), en groepeert alle stappen rond een case. Vaak bouw je hem door een audit- of applicatie-log te vertalen naar businesstermen, aangevuld met data uit je ERP of CRM.

De drie zijn complementair. Voor process mining heb je de derde nodig, en als die er niet is, zijn de eerste twee vaak de bron waaruit je hem samenstelt.