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 hebt, lopen een praktijkvoorbeeld door en laten zien hoe je je eerste eventlog opzet in Excel én SQL.
Gerelateerd: Lees meer over procesverbetering en bekijk data templates voor je systeem . Lees ook waarom we out-of-the-box connectors overslaan en kiezen voor eenvoudige data templates.
Een process mining event log is simpelweg een tabel met data die vastlegt wat er in je bedrijfsproces gebeurt. Zie het als een logboek dat elke stap van elke case in je systeem bijhoudt. Process mining-software leest dit logboek en bouwt diagrammen die laten zien hoe je proces echt werkt.
Elk event log heeft per regel drie essentiële gegevens nodig:
| Kolom | Betekenis | Voorbeeld |
|---|---|---|
| Case ID | Een unieke ID die samenhangende events groepeert | Order #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, is optioneel: deze “attributes” maken je analyse rijker.
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.
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:
Als je je event log als CSV-bestand of database-export heeft aangemaakt, kun je het laden in een process mining-tool. De meeste tools volgen een vergelijkbaar stappenplan:
Moderne process mining-tools zoals ProcessMind maken dit proces eenvoudig. Upload je event log en de tool visualiseert je proces automatisch, met inzicht in knelpunten, varianten en verbeterkansen.
Voor het opzetten van een process mining event log heb je geen specialistische tools of diepgaande technische kennis nodig. In de kern zet je de data in één 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 hetzelfde:
Het lastigste is niet de technische extractie, maar je proces zo goed begrijpen dat je weet welke events echt tellen. 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.
Klaar voor de volgende stap? Bekijk onze pagina’s over continue procesverbetering met uitgebreide toelichting op activiteiten en datavereisten voor populaire processen zoals Purchase to Pay , Order to Cash en Accounts Payable . Deze bronnen bevatten data templates voor bekende systemen zoals SAP, Oracle en Microsoft Dynamics, zodat je sneller aan de slag kunt met je event log.
Begin vandaag nog
Wacht niet op het perfecte event log. Begin met wat je heeft, leer van de proceskaarten die je maakt en verbeter stap voor stap. Zelfs een eenvoudig event log met basisactiviteiten kan verrassende inzichten opleveren in hoe je processen echt werken.
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 Disco en ProcessMind en vind het beste process mining platform voor 2025. Ontdek functies, prijzen en use cases.
Vergelijk Celonis process mining met ProcessMind voor 2025. Ontdek welke oplossing bij jouw organisatie past.
Direct toegang, geen creditcard, geen wachttijd. Ervaar hoe mapping, mining en simulatie samenwerken voor slimmere en snellere beslissingen.
Ontdek alle functies, krijg grondige inzichten en verbeter je processen vanaf dag één.
Start je gratis trial en ontdek de kracht van Process Intelligence – zie resultaat in minder dan 30 dagen!
We gebruiken cookies om je ervaring te verbeteren, gepersonaliseerde inhoud te tonen en het verkeer op onze site te analyseren. Door op "Alles accepteren" te klikken, ga je akkoord met ons gebruik van cookies.