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…
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.
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:
| Kolom | Betekenis | Voorbeeld |
|---|---|---|
| Case ID | Unieke aanduiding die bij elkaar horende events groepeert | Bestelling #12345 |
| Timestamp | Wanneer het event plaatsvond | 2025-01-15 09:30:00 |
| Activity | Wat 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.
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.”
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:
Je doel: een eventlog maken dat de volledige reis van elke bestelling laat zien, van plaatsen tot en met bezorgen.
Bij het bouwen van een eventlog kom je twee soorten events tegen:
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:
orders-tabel)payments-tabel)delivery_assignments-tabel)Afgeleide events hebben geen eigen timestamp, maar aan andere data kun je zien wanneer ze hebben plaatsgevonden.
Voorbeelden van Pizza Palace:
delivery_assignments staat een veld created_at dat aangeeft wanneer de toewijzing is gemaaktHet 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.
Bedenk vóór je data gaat extraheren welke events je wilt vastleggen. Voor Pizza Palace volgen we deze activiteiten:
Bepaal per event:
Onze mapping:
| Activiteit | Brontabel | Timestampveld | Case ID-veld |
|---|---|---|---|
| Bestelling geplaatst | orders | created_at | id |
| Betaling ontvangen | payments | payment_time | order_id |
| Bestelling naar keuken | kitchen_queue | queue_entry_time | order_id |
| Bestelling klaar | kitchen_queue | completed_time | order_id |
| Toegewezen aan bezorger | delivery_assignments | assigned_at | order_id |
| Bezorging afgerond | delivery_assignments | delivered_at | order_id |
Case ID, Timestamp en Activity zijn vereist, maar attributen maken je analyse veel krachtiger. Het zijn extra kolommen die context toevoegen.
Case-attributen beschrijven de volledige case (order) en zijn voor alle events in die case gelijk:
Eventattributen zijn specifiek per event:
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.
Je uiteindelijke eventlog is één tabel waarin elke rij één event is. Zo ziet het eventlog van Pizza Palace eruit:
| Case ID | Timestamp | Activiteit | Klant | Bestelwaarde | Bezorger | Betaalmethode |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Bestelling geplaatst | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:30:15 | Betaling ontvangen | John Smith | 45.99 | Creditcard | |
| 1001 | 2025-01-15 18:31:00 | Bestelling naar keuken | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:45:00 | Bestelling klaar | John Smith | 45.99 | ||
| 1001 | 2025-01-15 18:46:00 | Toegewezen aan bezorger | John Smith | 45.99 | Maria Garcia | |
| 1001 | 2025-01-15 19:05:00 | Bezorging afgerond | John Smith | 45.99 | Maria Garcia | |
| 1002 | 2025-01-15 18:35:00 | Bestelling geplaatst | Jane Doe | 28.50 | ||
| 1002 | 2025-01-15 18:35:20 | Betaling ontvangen | Jane Doe | 28.50 | PayPal | |
| … | … | … | … | … | … | … |
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.
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.
Maak één werkblad per activiteitstype:
Werkblad 1: Order geplaatst
| Case ID | Timestamp | Activiteit | Klant | Bestelwaarde |
|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Order geplaatst | John Smith | 45.99 |
| 1002 | 2025-01-15 18:35:00 | Order geplaatst | Jane Doe | 28.50 |
Werkblad 2: Betaling ontvangen
| Case ID | Timestamp | Activiteit | Klant | Bestelwaarde | Betaalmethode |
|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:15 | Betaling ontvangen | John Smith | 45.99 | Creditcard |
| 1002 | 2025-01-15 18:35:20 | Betaling ontvangen | Jane Doe | 28.50 | PayPal |
Zorg dat alle werkbladen dezelfde kolommen in dezelfde volgorde hebben. Voeg waar nodig lege kolommen toe:
Werkblad 1: Order geplaatst (bijgewerkt)
| Case ID | Timestamp | Activiteit | Klant | Bestelwaarde | Bezorger | Betaalmethode |
|---|---|---|---|---|---|---|
| 1001 | 2025-01-15 18:30:00 | Order geplaatst | John Smith | 45.99 |
Maak een nieuw werkblad “Event Log”. Kopieer en plak alle rijen van elk activiteitenblad na elkaar in dit gecombineerde werkblad.
Selecteer al je gegevens en sorteer op:
Zo staan de events per case in chronologische volgorde en kun je het verloop van elke bestelling makkelijk volgen.
Sla je gecombineerde werkblad op als CSV-bestand. Dit formaat werkt met vrijwel elke process mining-tool.
Excel-tips:
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 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.
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 voeg je extra events toe aan je log:
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'
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.
Voordat je in de analyse duikt, controleer je event log op veelvoorkomende problemen:
Noteer het volgende:
Die documentatie is goud waard als je je event log later wil bijwerken of problemen moet oplossen.
Houd activiteitsnamen consistent in al je extracties:
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.
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.

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.
Als je miljoenen events hebt, kunnen je queries traag worden of crashen tijdens de extractie.
Oplossing:
Heb je je eventlog als CSV of database-export klaar, dan kun je het in een process mining-tool laden. Zo gaat het meestal:
Moderne process mining-tools zoals ProcessMind maken dit eenvoudig. Upload je eventlog en de tool visualiseert je proces automatisch, inclusief knelpunten, varianten en verbetermogelijkheden.
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:
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.
Standaard connectors beloven makkelijke data-extractie voor process mining, maar leveren vaak complexiteit, vertraging en vendor lock-in. Zo doen wij het simpel…
Een praktische gids om met data processen te verbeteren en je organisatie te versterken.
Vergelijk Celonis process mining met ProcessMind voor 2025. Ontdek welke oplossing bij jouw organisatie past.
Vergelijk Disco en ProcessMind en vind het beste process mining platform voor 2025. Ontdek functies, prijzen en use cases.
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!