Process mining-eventlog maken: zo doe je dat

Dit leer je

In deze gids leer je hoe je helemaal zelf een eventlog voor process mining maakt. We behandelen de drie onmisbare kolommen die elk eventlog nodig heeft, lopen een praktijkvoorbeeld door en laten zien hoe je je eerste eventlog opzet in Excel én SQL.

Wat is een Process Mining eventlog?

Gerelateerd: Lees meer over procesverbetering en bekijk datatemplates voor jouw systeem. Lees ook waarom we out-of-the-box connectors overslaan en kiezen voor eenvoudige datatemplates.

Een eventlog voor process mining is simpelweg een tabel met data die vastlegt wat er in je bedrijfsproces is gebeurd. Zie het als een logboek dat elke stap van elke case in je systeem bijhoudt. Process mining-software leest dit logboek en maakt visuele diagrammen die laten zien hoe je proces écht werkt.

Elk eventlog heeft per rij drie essentiële gegevens nodig:

KolomBetekenisVoorbeeld
Case IDUnieke aanduiding die bij elkaar horende events groepeertBestelling #12345
TimestampWanneer het event plaatsvond2025-01-15 09:30:00
ActivityWat er gebeurde”Bestelling geplaatst”

Dat is alles. Met alleen deze drie kolommen kun je al aan de slag met process mining. Alles daarbovenop – zoals klantnamen, orderwaarden of medewerker-id’s – zijn optionele extra’s (“attributen”) die je analyse verdiepen.

Het verschil: events vs. activiteiten

Voordat we dieper ingaan, halen we eerst een veelvoorkomende verwarring weg.

Een activiteit is een type handeling, zoals “Order verzonden” of “Betaling ontvangen.” Zie het als een categorie of label.

Een event is een concrete gebeurtenis van die activiteit. Wanneer Order #12345 op 15 januari om 14:30 uur wordt verzonden, is dat een event.

Je eventlog bevat events, maar elk event heeft een activiteitsnaam. In de praktijk gebruiken mensen deze termen vaak door elkaar, en dat is prima. Onthoud vooral: activiteiten zijn het “wat” en events zijn het “wanneer en bij wie.”

Ons voorbeeld: het ordersysteem van Pizza Palace

Om het praktisch te maken werken we met een fictief systeem. Stel: je beheert Pizza Palace, een lokale pizzeria met een online bestelsysteem. Klanten plaatsen bestellingen via de website, het team bereidt de pizza’s en bezorgers leveren ze af.

Het Pizza Palace-systeem heeft meerdere databasetabellen die delen van het orderproces vastleggen:

  • orders - Basisinformatie over bestellingen (order-id, klant, besteltijd)
  • order_items - Wat er besteld is (pizza’s, bijgerechten, drankjes)
  • kitchen_queue - Wanneer bestellingen de keuken in gaan en eruit komen
  • delivery_assignments - Toewijzing van bezorgers en tracking van bezorging
  • payments - Registraties van betalingen

Je doel: een eventlog maken dat de volledige reis van elke bestelling laat zien, van plaatsen tot en met bezorgen.

Soorten events: direct versus afgeleid

Bij het bouwen van een eventlog kom je twee soorten events tegen:

Directe events

Directe events worden expliciet in je systeem vastgelegd. Iemand klikt op een knop of het systeem logt een actie; er staat dan direct een timestamp in de database.

Voorbeelden uit Pizza Palace:

  • Order placed (timestamp in de orders-tabel)
  • Payment received (timestamp in de payments-tabel)
  • Delivery completed (timestamp in de delivery_assignments-tabel)

Afgeleide events

Afgeleide events hebben geen eigen timestamp, maar aan andere data kun je zien wanneer ze hebben plaatsgevonden.

Voorbeelden van Pizza Palace:

  • “Order toegewezen aan bezorger” heeft misschien geen eigen timestamp, maar in de tabel delivery_assignments staat een veld created_at dat aangeeft wanneer de toewijzing is gemaakt
  • ”Pizza klaar” kun je afleiden op het moment dat de status van de keukenwachtrij op “completed” is gezet

Het verschil in het kort: directe events worden expliciet vastgelegd, afgeleide events leid je af uit andere datavelden. Beide zijn geldig en nuttig voor process mining.

Je eventlog plannen

Bedenk vóór je data gaat extraheren welke events je wilt vastleggen. Voor Pizza Palace volgen we deze activiteiten:

  1. Bestelling geplaatst - Klant verstuurt de bestelling
  2. Betaling ontvangen - Betaling is succesvol verwerkt
  3. Bestelling naar keuken - Bestelling komt in de voorbereidingswachtrij
  4. Bestelling klaar - Keuken markeert de bestelling als voltooid
  5. Toegewezen aan bezorger - Een bezorger wordt toegewezen
  6. Bezorging afgerond - Bestelling is bij de klant afgeleverd

Bepaal per event:

  • In welke tabel de data staat
  • Welk veld de timestamp bevat
  • Wat de Case ID is (in ons geval de order-id)

Onze mapping:

ActiviteitBrontabelTimestampveldCase ID-veld
Bestelling geplaatstorderscreated_atid
Betaling ontvangenpaymentspayment_timeorder_id
Bestelling naar keukenkitchen_queuequeue_entry_timeorder_id
Bestelling klaarkitchen_queuecompleted_timeorder_id
Toegewezen aan bezorgerdelivery_assignmentsassigned_atorder_id
Bezorging afgeronddelivery_assignmentsdelivered_atorder_id

Case- en eventattributen toevoegen

Case ID, Timestamp en Activity zijn vereist, maar attributen maken je analyse veel krachtiger. Het zijn extra kolommen die context toevoegen.

Case-attributen

Case-attributen beschrijven de volledige case (order) en zijn voor alle events in die case gelijk:

  • Klantnaam
  • Totale orderwaarde
  • Bezorgadres
  • Aantal bestelde items

Eventattributen

Eventattributen zijn specifiek per event:

  • Naam van de bezorger (alleen relevant voor bezorg-events)
  • Betaalmethode (alleen relevant voor betaal-events)
  • Keukenstation (alleen relevant voor keuken-events)

Pro tip: Het is helemaal prima om alle attributen in elke rij op te nemen, ook als sommige niet van toepassing zijn. Zo kan de rij ‘Order Placed’ gewoon een kolom ‘Driver Name’ hebben die leeg is. Zo blijft je event log een eenvoudige, platte tabel waar process mining-tools dol op zijn.

Het eventlog opbouwen: de eenvoudige structuur

Je uiteindelijke eventlog is één tabel waarin elke rij één event is. Zo ziet het eventlog van Pizza Palace eruit:

Case IDTimestampActiviteitKlantBestelwaardeBezorgerBetaalmethode
10012025-01-15 18:30:00Bestelling geplaatstJohn Smith45.99
10012025-01-15 18:30:15Betaling ontvangenJohn Smith45.99Creditcard
10012025-01-15 18:31:00Bestelling naar keukenJohn Smith45.99
10012025-01-15 18:45:00Bestelling klaarJohn Smith45.99
10012025-01-15 18:46:00Toegewezen aan bezorgerJohn Smith45.99Maria Garcia
10012025-01-15 19:05:00Bezorging afgerondJohn Smith45.99Maria Garcia
10022025-01-15 18:35:00Bestelling geplaatstJane Doe28.50
10022025-01-15 18:35:20Betaling ontvangenJane Doe28.50PayPal

Let op: case-attributen (Klant, Bestelwaarde) worden bij elk event in dezelfde case herhaald. Die duplicatie is bewust en maakt de data makkelijk om mee te werken.

Methode 1: Een eventlog maken in Excel

Als je je data kunt exporteren naar spreadsheets, kun je handmatig een eventlog opbouwen. Deze methode werkt prima voor kleine datasets of wanneer je nog aan het leren bent.

Stap 1: Exporteer elk type event naar een apart werkblad

Maak één werkblad per activiteitstype:

Werkblad 1: Order geplaatst

Case IDTimestampActiviteitKlantBestelwaarde
10012025-01-15 18:30:00Order geplaatstJohn Smith45.99
10022025-01-15 18:35:00Order geplaatstJane Doe28.50

Werkblad 2: Betaling ontvangen

Case IDTimestampActiviteitKlantBestelwaardeBetaalmethode
10012025-01-15 18:30:15Betaling ontvangenJohn Smith45.99Creditcard
10022025-01-15 18:35:20Betaling ontvangenJane Doe28.50PayPal

Stap 2: Standaardiseer de kolommen

Zorg dat alle werkbladen dezelfde kolommen in dezelfde volgorde hebben. Voeg waar nodig lege kolommen toe:

Werkblad 1: Order geplaatst (bijgewerkt)

Case IDTimestampActiviteitKlantBestelwaardeBezorgerBetaalmethode
10012025-01-15 18:30:00Order geplaatstJohn Smith45.99

Stap 3: Alle werkbladen samenvoegen

Maak een nieuw werkblad “Event Log”. Kopieer en plak alle rijen van elk activiteitenblad na elkaar in dit gecombineerde werkblad.

Stap 4: Sorteren op Case ID en daarna Timestamp

Selecteer al je gegevens en sorteer op:

  1. Case ID (oplopend)
  2. Timestamp (oplopend)

Zo staan de events per case in chronologische volgorde en kun je het verloop van elke bestelling makkelijk volgen.

Stap 5: Exporteren naar CSV

Sla je gecombineerde werkblad op als CSV-bestand. Dit formaat werkt met vrijwel elke process mining-tool.

Excel-tips:

  • Gebruik VERT.ZOEKEN of X.ZOEKEN om case-attributen (zoals klantnaam) vanuit je orders-werkblad op te halen
  • Gebruik een consistente datum- en tijdnotatie (YYYY-MM-DD HH:MM:SS werkt het best)
  • Verwijder eventuele dubbele events voordat je exporteert

Methode 2: Een eventlog maken met SQL

Voor grotere datasets of periodieke extracties is SQL efficiënter en beter herhaalbaar. De kerntechniek is UNION ALL: daarmee combineer je meerdere queries tot één resultset.

UNION ALL uitgelegd

UNION ALL stapelt de resultaten van meerdere SELECT-instructies onder elkaar. Elke SELECT wordt een set rijen in je eindresultaat. Alle SELECT-instructies moeten hetzelfde aantal kolommen hebben en compatibele datatypen.

Volledig SQL-voorbeeld

Hier staat een SQL-query die het event log van Pizza Palace opbouwt:

-- 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;

Zo breid je deze query uit

Zo voeg je extra events toe aan je log:

  1. Kopieer een van de SELECT-blokken als sjabloon
  2. Vervang de tabelnaam door je brontabel
  3. Pas het timestamp-veld aan naar de juiste kolom
  4. Wijzig de activiteitsnaam zodat die het event beschrijft
  5. Pas de attributen aan waar nodig
  6. Voeg passende WHERE-voorwaarden toe om de data te filteren

Voorbeeld: zo voeg je een ‘Delivery Attempted’-event toe:

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'

Best practices voor het maken van een eventlog

1. Begin eenvoudig, voeg later complexiteit toe

Start met de drie verplichte kolommen en een paar kernactiviteiten. Heb je een basis-eventlog succesvol opgebouwd en geladen in een process mining-tool, voeg dan stap voor stap meer events en attributen toe.

2. Valideer je data

Voordat je in de analyse duikt, controleer je event log op veelvoorkomende problemen:

  • Ontbrekende timestamps - Events zonder timestamp maken process mining onmogelijk
  • Dubbele events - Hetzelfde event dat twee keer is vastgelegd, vertekent je resultaten
  • Events in verkeerde volgorde - Een ‘Order Ready’ vóór ‘Order Placed’ wijst op problemen met de datakwaliteit
  • Wees-events - Events met case-ID’s die in geen enkele andere activiteit voorkomen

3. Documenteer je extractie

Noteer het volgende:

  • Welke tabellen je hebt gebruikt
  • Welke filters je hebt toegepast
  • Wanneer de extractie is uitgevoerd
  • Welke aannames je hebt gemaakt

Die documentatie is goud waard als je je event log later wil bijwerken of problemen moet oplossen.

4. Hanteer consistente naamgeving

Houd activiteitsnamen consistent in al je extracties:

  • ‘Order Placed’ is beter dan de ene keer ‘Order Created’ en de andere keer ‘New Order’ gebruiken
  • Kies een duidelijke naamgevingsconventie en houd je daaraan

5. Ga goed om met tijdzones

Als je data uit meerdere systemen of regio’s komt, zorg er dan voor dat alle timestamps in dezelfde tijdzone staan. UTC is vaak de veiligste keuze voor consistentie.

Veelvoorkomende uitdagingen en oplossingen

Uitdaging: hetzelfde event uit meerdere bronnen

Soms wordt hetzelfde event in meerdere tabellen vastgelegd. Zo kunnen zowel je ordersysteem als je ERP registreren wanneer een order wordt verzonden.

Oplossing: Kies één bron als ‘source of truth’ en gebruik alleen die. Leg je keuze vast.

Illustratie van veelvoorkomende uitdagingen bij het maken van process mining eventlogs

Uitdaging: events zonder timestamp

Sommige events hebben geen eigen timestamp. Een ‘Order Approved’ kan bijvoorbeeld alleen als boolean flag zijn opgeslagen.

Oplossing: Zoek naar gerelateerde timestamps. Misschien bestaat er een veld ‘approved_at’, of gebruik de ‘modified_at’-timestamp van het moment waarop de ‘approved’-flag werd gewijzigd.

Uitdaging: zeer hoog eventvolume

Als je miljoenen events hebt, kunnen je queries traag worden of crashen tijdens de extractie.

Oplossing:

  • Voeg datumfilters toe om de extractieperiode te beperken
  • Extraheer in batches (één maand per keer) en voeg de bestanden later samen
  • Overweeg dedicated ETL-tools voor grootschalige extracties

En nu? Laad je eventlog in een process mining-tool

Heb je je eventlog als CSV of database-export klaar, dan kun je het in een process mining-tool laden. Zo gaat het meestal:

  1. Upload je bestand of koppel de tool aan je geëxtraheerde data.
  2. Map je kolommen (Case ID, Timestamp, Activity)
  3. Configureer eventuele extra attributen
  4. Genereer je proceskaart

Moderne process mining-tools zoals ProcessMind maken dit eenvoudig. Upload je eventlog en de tool visualiseert je proces automatisch, inclusief knelpunten, varianten en verbetermogelijkheden.

Conclusie

Een process mining-eventlog maken vereist geen specialistische tools of diepe technische kennis. In de kern orden je je data in een tabel met drie essentiële kolommen: Case ID, Timestamp en Activity.

Of je nu Excel gebruikt voor kleinere datasets of SQL voor grotere, complexere extracties, de principes blijven gelijk:

  1. Bepaal welke events je wilt volgen
  2. Zoek de juiste timestamp bij elk eventtype
  3. Voeg alles samen in één tabel
  4. Voeg attributen toe om je analyse te verrijken

Het lastigste is niet de technische extractie, maar je proces zó goed begrijpen dat je weet welke events ertoe doen. Begin met de voor de hand liggende events (bestelling geplaatst, bestelling afgerond) en voeg gaandeweg meer detail toe naarmate je ziet welke inzichten je process mining-tool oplevert.

Verder de diepte in? Bekijk onze pagina’s over continue procesverbetering met uitgebreide info over activiteiten en datavereisten voor processen als Purchase to Pay, Order to Cash en Accounts Payable. Je vindt er ook data-templates voor bekende systemen zoals SAP, Oracle en Microsoft Dynamics, zodat je sneller aan de slag kunt met je eventlog.

Vandaag nog aan de slag

Wacht niet op het perfecte eventlog. Begin met wat je hebt, leer van de proceskaarten die je maakt en verbeter stap voor stap. Zelfs een eenvoudig eventlog met basisactiviteiten kan verrassende inzichten geven in hoe je processen écht lopen.

Gerelateerde Blogposts

Ontvang expertinzichten over process mining en workflow optimalisatie in je inbox
Waarom we out-of-the-box connectors overslaan (en wat we dan wél doen)

Waarom we out-of-the-box connectors overslaan (en wat we dan wél doen)

Standaard connectors beloven makkelijke data-extractie voor process mining, maar leveren vaak complexiteit, vertraging en vendor lock-in. Zo doen wij het simpel…

Strategische Gids voor Data-Driven Procesverbetering

Strategische Gids voor Data-Driven Procesverbetering

Een praktische gids om met data processen te verbeteren en je organisatie te versterken.

Celonis alternatieven: waarom ProcessMind slimmer is

Celonis alternatieven: waarom ProcessMind slimmer is

Vergelijk Celonis process mining met ProcessMind voor 2025. Ontdek welke oplossing bij jouw organisatie past.

Disco vs. ProcessMind: Beste Process Mining Platform 2025

Disco vs. ProcessMind: Beste Process Mining Platform 2025

Vergelijk Disco en ProcessMind en vind het beste process mining platform voor 2025. Ontdek functies, prijzen en use cases.

Daag jezelf uit en verbeter je processen in minder dan 30 dagen!

Direct toegang, geen creditcard, geen wachttijd. Ervaar hoe mapping, mining en simulatie samenwerken voor slimmere en snellere beslissingen.

Ontdek alle features, krijg diepgaande inzichten en verbeter je operations vanaf dag één.

Start je gratis trial en ontdek de kracht van Process Intelligence – zie resultaat in minder dan 30 dagen!