Event log voor process mining: zo maak je er een

Voor process mining heb je maar één tabel nodig: activiteiten met een timestamp, gegroepeerd op case-ID. In deze gids maak je die tabel op basis van systeemdata, aan de hand van een fictief restaurantbestelproces. Je ziet twee manieren: een paar rijen in Excel of één SQL-query die de activiteiten met UNION ALL samenvoegt. Vergelijk tussendoor je werk met het voltooide voorbeeldeventlog.

Event log voor process mining: de drie benodigde kolommen

Een event log is een gestructureerd overzicht van wat er in een proces is gebeurd. Elke rij staat voor één gebeurtenis, zoals een bestelling plaatsen of een betaling ontvangen. De Case-ID koppelt gebeurtenissen aan elkaar, de timestamp geeft aan wanneer elke gebeurtenis plaatsvond. Samen maken deze gegevens zichtbaar hoe cases door het proces lopen.

Een activiteit is een type, een gebeurtenis is een concrete keer dat die plaatsvindt. Een activiteit is een soort handeling, zoals ‘Bestelling verzonden’. Een gebeurtenis is een specifiek voorval: bestelling 12345 is op 15 januari om 14.30 uur verzonden. Je log registreert gebeurtenissen en elke gebeurtenis heeft een activiteitsnaam. De woorden worden vaak door elkaar gebruikt, maar het onderscheid is belangrijk bij het voorbereiden van data. De activiteit geeft aan wat er gebeurde; de gebeurtenis legt vast dat dit bij deze case op dit moment gebeurde.

Een eenvoudig event log voor process mining heeft drie kolommen nodig:

Controleer deze drie velden voordat je verdergaat:

Deze drie velden vormen de basis. Ontbreekt er een of is die niet consistent, dan geeft de procesweergave de volgorde van het werk verkeerd weer. De rest is optioneel. Een event log dat tools voor process mining kunnen lezen, is altijd één tabel met cases en gebeurtenissen. De drie kolommen die een event log bruikbaar maken, blijven hetzelfde. Bekijk de documentatie over data voor process mining voor ondersteunde formaten en voorbereidingsstappen.

Een uitgewerkt voorbeeld: het bestelsysteem van Pizza Palace

Om de stappen concreet te maken, gebruiken we het fictieve restaurant Pizza Palace. Klanten plaatsen online bestellingen, medewerkers bereiden het eten en bezorgers leveren het af. Het voorbeeld bevat geen klantdata.

Stel dat het systeem informatie opslaat in deze tabellen:

• orders: order-ID, klant en besteltijd
• order_items: pizza’s, bijgerechten en drankjes per bestelling
• kitchen_queue: wanneer een bestelling de keuken in- en uitgaat
• delivery_assignments: toewijzing aan bezorgers en bezorgstatus
• payments: gegevens over betalingsverwerking

Het doel is één event log te maken dat elke bestelling volgt vanaf het plaatsen tot en met de bezorging. De order-ID wordt de Case-ID. Elke relevante timestamp en handeling wordt een rij. Download het voorbeeldlog van Pizza Palace als voorbeeld van een event log voor process mining en vergelijk de kolommen met je eigen extractie.

Bepaal vóór de extractie welke activiteiten je opneemt. De bestelling bij Pizza Palace bestaat uit zes stappen:

1. Bestelling geplaatst: De klant plaatst de bestelling.
2. Betaling ontvangen: De betaling is succesvol verwerkt.
3. Bestelling naar keuken gestuurd: De bestelling komt in de bereidingswachtrij.
4. Bestelling klaar: De keuken markeert de bestelling als afgerond.
5. Toegewezen aan bezorger: Er wordt een bezorger toegewezen.
6. Bezorging afgerond: De bestelling is bezorgd.

Zoek voor elke activiteit de brontabel, het timestampveld en het Case-ID-veld. Controleer of de Case-ID de gebeurtenis aan de juiste bestelling koppelt.

Houd directe en afgeleide gebeurtenissen apart. Een directe gebeurtenis heeft een expliciet record en timestamp in een bronsysteem. Bestelling geplaatst komt van de timestamp op de orders-rij, Betaling ontvangen van payments en Bezorging afgerond van delivery_assignments. Deze gebeurtenissen zijn meestal eenvoudig op te halen, zolang de timestamp overeenkomt met de gebeurtenis die je wilt analyseren.

Een afgeleide gebeurtenis heeft geen eigen record. Je leidt het tijdstip daarom af uit een ander veld. Toegewezen aan bezorger bestaat misschien alleen als aanmaaktijd van de bezorgtoewijzing. Bestelling klaar kan alleen worden vastgelegd als het moment waarop de status van de keukenwachtrij veranderde in ‘afgerond’. Afgeleide gebeurtenissen kunnen nuttig zijn, maar leg vast hoe je ze hebt afgeleid. Een statuswijziging of aanmaaktijd betekent niet altijd precies wat de activiteitsnaam suggereert. Controleer daarom de betekenis van het veld bij mensen die het bronsysteem kennen, voordat je het als timestamp van een gebeurtenis gebruikt.

Deze koppeling is een plan, geen bewijs dat elk veld geschikt is. Controleer of de timestamps zijn ingevuld en of je elke tabel aan de order-ID kunt koppelen zonder dubbele rijen te maken.

Case- en gebeurtenisattributen

Attributen geven context aan je analyse. Het zijn de kolommen naast Case-ID, Timestamp en Activiteit. Voeg ze alleen toe als ze een duidelijke betekenis hebben en aan de juiste case of gebeurtenis kunnen worden gekoppeld.

Case-attributen beschrijven de hele case en blijven meestal gelijk voor alle gebeurtenissen: klantnaam, totaalbedrag van de bestelling, bezorgadres en aantal bestelde artikelen. In een plat event log herhaal je de waarde op elke rij van die case. Daardoor kun je later gebeurtenissen filteren of vergelijken op basis van informatie over de case.

Gebeurtenisattributen beschrijven één gebeurtenis: de bezorger bij een bezorggebeurtenis, de betaalmethode bij een betalingsgebeurtenis of het keukenstation bij een keukengebeurtenis. Zo’n kolom is niet op elke rij van toepassing. Laat de waarde leeg waar dat zo is, maar houd de kolom in de tabel zodat elke rij dezelfde structuur heeft.

Je uiteindelijke event log is één platte tabel met één gebeurtenis per rij. Dit is het log van Pizza Palace:

De klant en bestelwaarde worden bij elke gebeurtenis van dezelfde case herhaald. Dat is bewust: zo blijft het log een eenvoudige tabel die tools voor process mining kunnen lezen.

Methode 1: maak het event log in Excel

Excel werkt goed voor een kleine extractie of een eerste oefening. Exporteer elk type gebeurtenis, maak de kolommen gelijk en voeg de rijen samen in één werkblad. Met de data van Pizza Palace kosten de vijf stappen hieronder ongeveer een uur.

Stap 1: exporteer elk type gebeurtenis naar een apart werkblad. Maak voor elk type activiteit een werkblad. Bijvoorbeeld:

Werkblad 1: bestelling geplaatst

Werkblad 2: betaling ontvangen

Maak op dezelfde manier extra werkbladen voor keuken- en bezorggebeurtenissen.

Stap 2: maak de kolommen gelijk. Gebruik op elk werkblad dezelfde kolomnamen in dezelfde volgorde. Voeg lege kolommen toe voor attributen die niet van toepassing zijn. Het werkblad Bestelling geplaatst kan bijvoorbeeld alle kolommen bevatten:

Controleer of de waarden compatibele notaties gebruiken. Zorg er vooral voor dat timestamps als datum en tijd zijn opgeslagen, en niet als tekst die er alleen uitziet als een timestamp.

Stap 3: voeg de werkbladen samen. Maak een nieuw werkblad met de naam Event Log en kopieer de rijen met gebeurtenissen uit elk activiteitenblad. Gebruik één kopregel en één gebeurtenis per rij.

Stap 4: sorteer op case en timestamp. Sorteer de samengevoegde data eerst oplopend op Case-ID en daarna oplopend op Timestamp. Zo kun je de volgorde van gebeurtenissen per case makkelijker controleren. Sorteren herstelt geen onjuiste timestamps. Controleer gebeurtenissen met dezelfde of onverwachte tijden voordat je op de volgorde vertrouwt.

Stap 5: exporteer naar CSV. Sla het samengevoegde werkblad op als een CSV-bestand met een event log voor process mining dat je tool kan lezen. Open het geëxporteerde bestand om te controleren of de kopregels, scheidingstekens, datumnotatie en lege waarden kloppen.

Excel-tips:

• Gebruik VLOOKUP of XLOOKUP om case-attributen, zoals de klantnaam, toe te voegen vanuit het werkblad orders.
• Gebruik één vaste datum- en tijdnotatie, zoals YYYY-MM-DD HH:MM:SS.
• Controleer vóór het exporteren op dubbele rijen.
• Bewaar een ongewijzigde kopie van de oorspronkelijke extracties, zodat je correcties kunt herleiden.

Methode 2: maak het event log met SQL

SQL is handig als je data in een database staat, de extractie groot is of je volgende maand dezelfde extractie opnieuw wilt uitvoeren. Meestal gebruik je één SELECT per activiteit en voeg je de resultaten samen met UNION ALL.

Zo werkt UNION ALL. Hiermee voeg je de rijen uit meerdere SELECT-instructies samen. Elke instructie moet hetzelfde aantal kolommen in dezelfde volgorde opleveren, met compatibele datatypen en consistente aliassen, zodat de uiteindelijke kolommen duidelijke namen hebben.

De query. In het voorbeeld hieronder gebruiken we de fictieve tabellen van Pizza Palace. Controleer je eigen tabelnamen, veldnamen, de betekenis van timestamps en SQL-dialect voordat je de query aanpast.

-- Event Log Extraction for Pizza Palace
-- This query combines multiple event types into a single event log
-- Each SELECT block represents one activity type

-- Event 1: Order Placed
-- Source: orders table
-- This captures when customers submit their orders
SELECT 
    o.id AS case_id,                          -- The order ID is our case identifier
    o.created_at AS timestamp,                -- When the order was placed
    'Order Placed' AS activity,               -- The activity name (hardcoded)
    o.customer_name AS customer,              -- Case attribute: who ordered
    o.total_amount AS order_value,            -- Case attribute: order value
    NULL AS driver,                           -- Not applicable for this event
    NULL AS payment_method                    -- Not applicable for this event
FROM orders o
WHERE o.created_at >= '2025-01-01'            -- Filter to your desired date range

UNION ALL

-- Event 2: Payment Received
-- Source: payments table
-- This captures successful payment processing
SELECT 
    p.order_id AS case_id,
    p.payment_time AS timestamp,
    'Payment Received' AS activity,
    o.customer_name AS customer,              -- Join to get case attributes
    o.total_amount AS order_value,
    NULL AS driver,
    p.payment_method AS payment_method        -- Event-specific attribute
FROM payments p
JOIN orders o ON p.order_id = o.id            -- Join to get order details
WHERE p.payment_time >= '2025-01-01'
  AND p.status = 'successful'                 -- Only include successful payments

UNION ALL

-- Event 3: Order Sent to Kitchen
-- Source: kitchen_queue table
-- This captures when the kitchen starts working on the order
SELECT 
    k.order_id AS case_id,
    k.queue_entry_time AS timestamp,
    'Order Sent to Kitchen' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.queue_entry_time >= '2025-01-01'

UNION ALL

-- Event 4: Order Ready
-- Source: kitchen_queue table (different timestamp field)
-- This is an inferred event based on when the kitchen marked it complete
SELECT 
    k.order_id AS case_id,
    k.completed_time AS timestamp,            -- Different timestamp than entry
    'Order Ready' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.completed_time >= '2025-01-01'
  AND k.completed_time IS NOT NULL            -- Only include completed orders

UNION ALL

-- Event 5: Assigned to Driver
-- Source: delivery_assignments table
-- This captures when a driver is assigned to deliver the order
SELECT 
    d.order_id AS case_id,
    d.assigned_at AS timestamp,
    'Assigned to Driver' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,                  -- Event-specific attribute
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.assigned_at >= '2025-01-01'

UNION ALL

-- Event 6: Delivery Completed
-- Source: delivery_assignments table (different timestamp field)
-- This captures when the order was delivered to the customer
SELECT 
    d.order_id AS case_id,
    d.delivered_at AS timestamp,
    'Delivery Completed' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.delivered_at >= '2025-01-01'
  AND d.delivered_at IS NOT NULL              -- Only include completed deliveries

-- Final ordering: by case, then by time
-- This makes the event log easy to read and follow
ORDER BY case_id, timestamp;

De query gebruikt de order-ID als case-ID en geeft voor elke activiteit dezelfde zeven kolommen terug. De waarden NULL zorgen voor een consistente kolomstructuur als een attribuut niet van toepassing is. Het datumfilter en de voorwaarde voor een geslaagde betaling zijn voorbeelden. Kies filters die passen bij het proces en de periode die je wilt analyseren.

De query uitbreiden. Zo voeg je een activiteit toe:

1. Kopieer een SELECT blok als uitgangspunt.
2. Gebruik de brontabel waarin de gebeurtenis wordt vastgelegd.
3. Selecteer het veld met de timestamp.
4. Kies een activiteitsnaam die aansluit bij de andere rijen.
5. Neem de case-ID en relevante attributen op.
6. Voeg filters toe die passen bij je analyse.

Zo kun je bijvoorbeeld een bezorgpoging toevoegen, als je systeem de benodigde tabel en velden bevat:

UNION ALL

-- Event 7: Delivery Attempted
-- Add this to track failed delivery attempts
SELECT 
    d.order_id AS case_id,
    d.attempt_time AS timestamp,
    'Delivery Attempted' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_attempts d
JOIN orders o ON d.order_id = o.id
WHERE d.attempt_time >= '2025-01-01'

Controles voordat je het event log analyseert

Voer deze controles uit voordat je het event log analyseert. Samen helpen ze de meest misleidende fouten in event logs voor process mining op te sporen: dubbele gebeurtenissen, ontbrekende timestamps, instabiele case-ID’s en statusvelden die ten onrechte als activiteiten worden gezien.

1. Begin met de verplichte kolommen. Maak een klein event log met Case-ID, Timestamp en Activiteit voordat je meer gebeurtenissen of attributen toevoegt.
2. Gebruik stabiele case-ID’s. Elke gebeurtenis voor dezelfde case moet dezelfde identificatie gebruiken. Gebruik geen waarde die tijdens het proces verandert.
3. Houd activiteitsnamen consistent. Kies één label, zoals ‘Order geplaatst’, en wissel dat niet af met ‘Order aangemaakt’ of ‘Nieuwe order’.
4. Controleer de timestamps. Controleer of ze het tijdstip van de gebeurtenis weergeven, dezelfde tijdzone gebruiken en als datum en tijd kunnen worden gesorteerd.
5. Controleer op dubbele en ontbrekende waarden. Onderzoek herhaalde gebeurtenissen en rijen zonder case-ID, timestamp of activiteit.
6. Leg de data-extractie vast. Noteer de brontabellen, velden, filters, extractiedatum en aannames. Zo kun je het event log later makkelijker bijwerken en problemen opsporen.
7. Voeg attributen zorgvuldig toe. Neem velden op die helpen een vraag te beantwoorden en controleer of joins geen extra gebeurtenisrijen opleveren.

Veelvoorkomende dataproblemen, van dubbele gebeurtenissen tot ontbrekende case-ID’s, worden beantwoord in de FAQ onderaan deze pagina. ETL voor process mining gaat in op dezelfde werkzaamheden voor terugkerende data-extracties.

Wat kun je doen als je de data niet hebt?

Je hebt geen voorgebouwde connector nodig om een event log samen te stellen. Kijk eerst wat je systeem kan exporteren en of die export de drie verplichte velden bevat.

1. Bepaal welk proces en welke case-ID je wilt volgen.
2. Controleer of het systeem de gebeurtenisgeschiedenis, auditgegevens of statuswijzigingen met timestamps kan exporteren.
3. Gebruik een datatemplate om de beschikbare velden te koppelen aan Case-ID, Timestamp en Activiteit.
4. Kun je geen kant-en-klare gebeurtenissentabel exporteren? Vraag je datateam dan om een database-export of rapport met één rij per gebeurtenis.

Een systeemexport kan uit meerdere tabellen bestaan of andere namen gebruiken voor hetzelfde veld. Je kunt de data in Excel of SQL samenvoegen en de veldnamen aanpassen, zolang de betekenis van elk veld behouden blijft en je kunt achterhalen waar het vandaan komt. Waar haal je data voor process mining vandaan? laat zien op welke andere plekken bruikbare brondata te vinden is. De gidsen voor procesverbetering hebben stap 1 tot en met 3 al uitgewerkt voor je systeem, met een datatemplate per proces.

Wil je een ander voorbeeld van een event log voor process mining bekijken om formaten te vergelijken? De verzameling voorbeeldbestanden en templates voor event logs bevat een kant-en-klaar spreadsheet. Op de pagina template voor event logs vind je de verplichte en optionele kolommen. Bekijk je eerste dataset laden voor een uitleg van de eerste dataset.

Laad het event log dat je hebt samengesteld

Is het event log klaar? Laad het bestand en koppel de drie verplichte kolommen. ProcessMind leest Excel-, CSV- en databasebestanden rechtstreeks in.

1. Upload het bestand of selecteer de database-export.
2. Koppel de kolommen Case-ID, Timestamp en Activiteit.
3. Controleer eventuele aanvullende attributen.
4. Genereer de procesweergave en controleer of de cases en de volgorde van gebeurtenissen kloppen.

Een overzicht van de datasetkolommen en hun rollen als activiteit, case en attribuut in ProcessMind

Een procesweergave helpt je ontbrekende activiteiten, onverwachte volgordes en punten voor nader onderzoek te vinden. De brondata wordt er niet door aangepast en de manier waarop het werk wordt uitgevoerd verandert niet. Komt er in het eerste resultaat een dataprobleem naar voren? Pas dan de export aan en laad die opnieuw. Je eerste dataset laden legt het uploaden en koppelen stap voor stap uit.

Laad het event log dat je net hebt samengesteld