Process mining-prestaties: benchmarks en tips

Wat bepaalt de prestaties van process mining?

De prestaties van process mining hangen af van drie factoren: hoeveel data je uploadt, hoe je die structureert en hoe het systeem die verwerkt. In deze gids behandelen we ze alle drie, met echte benchmarks en praktische manieren om resultaten te verbeteren.

We publiceren al onze cijfers. Vergelijk ze met elke process mining-tool op de markt.

De datapijplijn: waar gaat de tijd naartoe?

Wanneer je data naar ProcessMind uploadt, gebeuren er drie dingen. Dit is precies waar de tijd naartoe gaat:

1. Uploaden, bepalend voor de totale tijd. Je bestand gaat via internet naar onze cloudinfrastructuur. Bij grote bestanden is dit het knelpunt. De natuurkunde wint: een CSV met 50 miljoen events, 11 GB, duurt 2 minuten via gigabit, 18 minuten via 100 Mbps en ruim 3 uur via 10 Mbps. Dezelfde data in Parquet is slechts 1,7 GB. Daarmee worden die tijden 19 seconden, 3 minuten en 28 minuten. Dit is de belangrijkste reden om kolomindelingen zoals Parquet of ORC te gebruiken, of kleinere datasets te kiezen.

2. Voorbewerking, eenmalige kostenpost van ongeveer 30 seconden tot 2,5 minuut. Na het uploaden zetten we je data om naar geoptimaliseerde kolomopslag: events worden geïndexeerd, activiteitsovergangen vooraf berekend, procesvarianten herkend en samenvattende statistieken berekend. Dit duurt 30 seconden voor kleine datasets en maximaal 2,5 minuut voor 100M events. Je betaalt deze kosten één keer per upload en profiteert er daarna van.

3. Modelwijzigingen, gedeeltelijke herberekening van 6–52 seconden. Als je het procesmodel wijzigt door activiteiten toe te voegen of te verwijderen of mappings aan te passen, worden alleen de modelafhankelijke berekeningen bijgewerkt. Dit duurt 6 seconden voor kleine datasets en maximaal 52 seconden voor 100M events, veel sneller dan volledige voorbewerking. Filterwijzigingen zijn direct zichtbaar.

Queryprestaties begrijpen

Zodra je data is geladen, bepalen verschillende kenmerken de snelheid van queries. Als je die begrijpt, kun je betere exports maken en realistische verwachtingen hebben.

Het aantal activiteiten telt. Procesmodellen met 10–20 verschillende activiteiten zijn optimaal. Boven de 50 activiteiten duurt het langer om de process flow te berekenen en wordt die moeilijker te begrijpen. Te veel nodes en edges zorgen voor visuele ruis. Bevat je export veel activiteiten, overweeg dan om verwante stappen te groeperen.

De variatie in varianten beïnvloedt de berekening. Een proces waarin 80% van de cases vijf varianten volgt, is sneller te analyseren dan een proces waarin elke case een uniek pad neemt. Veel variatie is niet per se slecht en wijst vaak op echte problemen, maar houd rekening met iets langere querytijden.

Meer kolommen betekent meer scanwerk. Elk attribuut dat je toevoegt, wordt geïndexeerd en bevraagd. De kernkolommen, CaseId, Activity en Timestamp, zijn altijd nodig. Extra kolommen helpen bij filteren en categoriseren, maar voegen elk extra verwerking toe.

Lange cases duren langer. Een case met 50 events vraagt meer rekenwerk dan een case met 5 events. Als je proces cases bevat met honderden events, worden queries naar verhouding trager. Dat hoort bij process mining en ligt niet aan een specifieke tool.

Benchmarkdata uit de praktijk (maart 2026)

Als je weet wat je kunt verwachten, kun je beter plannen. Deze benchmarks draaien op productie-infrastructuur van AWS, met echte netwerklatentie, en zijn gemiddelden van meerdere testruns. We hebben per datasetgrootte meer dan 50 querytypen getest.

Upload- en voorbewerkingstijden

De tabel hieronder laat zien wat je per datasetgrootte realistisch kunt verwachten. Bij grotere bestanden bepaalt de uploadtijd de totale wachttijd, vooral bij tragere verbindingen. Dit is de belangrijkste factor in de totale wachttijd.

De bestandsgroottes gelden voor ongecomprimeerde CSV met een gangbaar event log-schema (CaseId, Activity, Timestamp en 5–8 bedrijfsattributen). Je bestanden kunnen groter of kleiner zijn, afhankelijk van het aantal kolommen en de inhoud.

De uploadtijden bij 1 Gbps zijn gemeten met een effectieve doorvoer van 88 MB/s naar AWS eu-central-1. De andere snelheden zijn geëxtrapoleerd op basis van praktische doorvoer: 50 Mbps → ongeveer 5 MB/s, 100 Mbps → ongeveer 10 MB/s en 10 Mbps → ongeveer 1 MB/s. De werkelijke doorvoer hangt af van je netwerk, de afstand tot het datacenter en de huidige belasting.

De belangrijkste conclusie: De voorbewerking blijft ongeacht de schaal tussen 1 en 2,5 minuut. De uploadtijd groeit lineair met de bestandsgrootte. De bestandsgrootte verkleinen is de meest effectieve optimalisatie die je kunt uitvoeren.

Kies het juiste bestandsformaat

Het bestandsformaat dat je uploadt heeft veel invloed op de uploadsnelheid en de voorbewerkingstijd. ProcessMind ondersteunt CSV, Parquet, ORC, Excel en XES. Bij grote datasets presteren Parquet en ORC veel beter dan CSV, zowel qua bestandsgrootte als verwerkingssnelheid.

Bestandsgrootte vergelijken

Parquet-bestanden zijn 85% kleiner dan CSV. ORC-bestanden zijn 82% kleiner. Beide zijn kolomformaten met ingebouwde compressie, dus een extra stap is niet nodig. Je ETL-tool of dataplatform, zoals Spark, Databricks, dbt of BigQuery, ondersteunt waarschijnlijk al export naar Parquet of ORC.

Voorbewerking per formaat

Bestandsgrootte is maar de helft van het verhaal. Na het uploaden doorloopt je data formaatafhankelijke inname en analytische berekeningen, waaronder eventindexering en berekeningen van overgangen en varianten. De analytische stap bepaalt de totale tijd en is voor alle formaten gelijk. CSV.GZ is het enige formaat dat aanzienlijk extra tijd kost, omdat gzip-bestanden niet kunnen worden opgesplitst voor parallelle decompressie.

De voorbewerkingstijd is vrijwel gelijk voor Parquet, ORC en CSV, omdat de analytische berekening ongeacht het invoerformaat de meeste tijd kost. Bij CSV.GZ loopt de verwerkingstijd bij grotere datasets sterk op, van ongeveer een minuut bij 1M events tot meer dan 4 minuten bij 100M. Met gzip gecomprimeerde bestanden kunnen niet worden opgesplitst en parallel worden verwerkt. Daardoor komt er vóór de analyse een steeds langere decompressiestap bij.

Het totaalbeeld

Als je zowel de uploadtijd als de voorbewerking meeneemt, wordt de keuze voor een formaat duidelijk:

Op schaal zijn Parquet en ORC duidelijk de beste keuze, omdat hun bestanden veel kleiner zijn. De uploadtijd is het belangrijkste knelpunt. De voorbewerking duurt voor alle formaten ongeveer even lang, behalve bij CSV.GZ, waar de extra decompressietijd steeds verder oploopt.

Delta loading: data toevoegen zonder opnieuw te uploaden

Als je eenmaal een basisdataset hebt geladen, hoef je bij nieuwe data niet alles opnieuw te uploaden. ProcessMind ondersteunt delta loading, oftewel incrementele uploads, zodat je nieuwe events aan een bestaande dataset kunt toevoegen.

Zo werkt het:

1. Upload je eerste dataset, bijvoorbeeld inkooporders uit Q1 2026 met 2,3M events
2. Wanneer de data uit Q2 binnenkomt, upload je alleen de nieuwe events als delta-bestand, bijvoorbeeld 800K nieuwe events
3. ProcessMind voegt de bestanden automatisch samen en verwerkt ze opnieuw

Het effect op de prestaties is groot. In plaats van je groeiende dataset telkens opnieuw te uploaden, upload je alleen wat nieuw is:

Na een delta-upload wordt de gecombineerde dataset opnieuw voorbewerkt, met dezelfde kosten van 1–2,5 minuut. Maar je bespaart alle uploadtijd voor data die al was geüpload.

Delta loading is ideaal voor:

• Wekelijkse of maandelijkse data-updates: voeg nieuwe transacties toe zodra ze beschikbaar zijn
• Continue procesmonitoring: houd dashboards actueel zonder grote uploads
• Groeiende event logs: voeg nieuwe events toe uit ERP, CRM of andere bronsystemen

Delta-bestanden moeten hetzelfde bestandsformaat en dezelfde kolomstructuur hebben als de oorspronkelijke upload. Bekijk de gids voor incrementeel data laden voor meer informatie.

De API gebruiken voor grote of geautomatiseerde uploads

Bij datasets van meer dan enkele gigabytes of terugkerende uploads zijn scripts of commandlinetools betrouwbaarder dan uploads via de browser. Browsers kunnen een time-out krijgen, te veel geheugen gebruiken of voortgang verliezen als de netwerkverbinding wordt onderbroken.

Waarom de API beter werkt voor grote bestanden:

• Betrouwbare overdracht. Als je verbinding wegvalt, kun je opnieuw proberen zonder opnieuw te beginnen.
• Geen geheugenlimieten van de browser. Browsers hebben moeite met bestanden van meerdere gigabytes. Commandlinetools verwerken ze zonder problemen.
• Automatisering. Plan nachtelijke uploads, koppel ze aan ETL-pijplijnen of start uploads vanuit CI/CD.
• Voortgang volgen. Tools zoals curl tonen de overdrachtsvoortgang in realtime.
• Delta-uploads. Voeg volgens een vast schema programmatisch nieuwe data toe.

Voorbeeld met curl:

# Upload a Parquet file directly using a presigned URL
curl -X PUT "$PRESIGNED_URL" --upload-file data.parquet

ProcessMind levert presigned URL’s waarmee je rechtstreeks naar cloudopslag kunt uploaden. Naast je API-key zijn geen andere inloggegevens nodig. Je kunt de presigned upload-URL ook rechtstreeks kopiëren uit het instellingenmenu van de dataset in de ProcessMind-interface.

Bekijk de API-documentatie voor complete voorbeelden in Bash, JavaScript en Python, waaronder het ophalen van presigned URL’s, het uploaden van delta-bestanden en het programmatisch verwerken van grote datasets.

Snelheid van modeliteraties

Als je je procesmodel verfijnt door activiteiten te hernoemen, mappings aan te passen of groeperingen toe te voegen, hoeven alleen de modelafhankelijke berekeningen te worden bijgewerkt. De basisdata blijft staan:

Modelwijzigingen zijn snel, omdat de eerste stap voor het laden van data, die meegroeit met de datasetgrootte, al klaar is. Alleen de modelafhankelijke aggregatiestap wordt opnieuw uitgevoerd, inclusief activity mappings, overgangen en varianten. Bij datasets tot 20M events zijn modelwijzigingen binnen 25 seconden klaar. Zelfs bij 100M events duurt dit minder dan een minuut, veel sneller dan volledige voorbewerking.

Responstijden van dashboards

Zodra je data is geladen, zijn dit de responstijden tijdens de analyse. De tijden hieronder zijn medianen van meerdere benchmarkruns. Elke dashboardcomponent voert onafhankelijk een query uit en wordt parallel geladen:

Patronen om op te letten:

• Statistieken, waaronder totalen en doorlooptijden, blijven met ongeveer 0,6 seconde gelijk, ongeacht de omvang. Deze queries zijn sterk geoptimaliseerd.
• Process flow, het process diagram, schaalt mee met de datasetgrootte, omdat overgangen tussen alle activiteiten worden berekend.
• Varianten en categorieën schalen gematigd. Vooraf geaggregeerde data houdt ze snel.
• Databrowser blijft snel dankzij paginering. Met filters duurt dit minder dan 1 seconde.
• Animatie varieert met het aantal actieve cases dat wordt gevisualiseerd.

De conclusie: Bij de aanbevolen datasetgrootte van 1–10M events reageert elke dashboardcomponent binnen 3,5 seconden. Zelfs bij 50M events duren de meeste queries met filters 2–4 seconden. Alleen ongefilterde process flows en categorieoverzichten op datasets van 50M+ events komen uit op 5–6 seconden.

Begin klein, schaal later op

Dit is het belangrijkste advies in deze gids: begin niet met je grootste dataset.

De cijfers spreken voor zich:

De meeste organisaties merken dat 1–5M events ruim voldoende is voor inzichten waar je mee aan de slag kunt. Het procesgedrag stabiliseert al ruim vóór 10M events. Daarna voeg je vooral duplicaten toe van patronen die je al hebt gezien.

Als je Parquet-bestand met 1M events, 34 MB, in 3 seconden wordt geüpload en je dezelfde process map oplevert als 50M events, waarom zou je dan 18 minuten wachten?

Datastrategie: de juiste omvang bepalen

De cijfers hierboven vertellen een duidelijk verhaal: bij 1–5M events duurt uploaden seconden, de voorbewerking minder dan 2 minuten en reageren dashboards in 1–2,5 seconden. Bij 50M wacht je bij 100 Mbps 20 minuten op een upload en reageren dashboards trager, in 3–6 seconden. Dat maakt een groot verschil in de praktijk.

De echte vraag is dus niet: “Hoe snel is de tool?” Maar: “Hoeveel data heb ik echt nodig?” Het antwoord is bijna altijd minder dan je denkt.

Segmenteer eerst, aggregeer later

Analyseer eerst één land, één afdeling of één productlijn.

Dit gaat niet om beperkingen, maar om duidelijkheid. Analyse per segment levert scherpere inzichten op dan wereldwijde gemiddelden.

Waarom segmentatie werkt:

• Processen verschillen per regio. De bedrijfsvoering in Duitsland volgt andere goedkeuringsketens dan die in de VS. Franse arbeidswetten leiden tot andere HR-workflows. Als je ze samen analyseert, ontstaat ruis.
• Andere stakeholders, andere prioriteiten. De VP van EMEA is geïnteresseerd in EMEA. Laat die persoon EMEA-data zien. Het wereldwijde overzicht kan later komen.
• Snellere iteraties. De data van één land kan uit 500K events bestaan in plaats van 10M. Je itereert in minuten, niet in uren.
• Ingebouwde benchmarking. Zodra je Duitsland hebt geanalyseerd, doe je hetzelfde voor Frankrijk. Dan kun je vergelijken.

Voorbeeld: Een Europees logistiek bedrijf met 42M verzendevents uit 8 landen:

• Alles analyseren: 42 miljoen events, 9,3 GB, 16 min. uploaden (100 Mbps), 2 min. voorbewerking
• Alleen Duitsland analyseren: 8,5 miljoen events, 1,9 GB, 3 min. uploaden, 1,5 min. voorbewerking
• Alleen Nederland analyseren: 3,1 miljoen events, 690 MB, 1 min. uploaden, 1 min. voorbewerking
• Delta loading gebruiken: upload eerst Duitsland en voeg Nederland toe zodra het klaarstaat

Filter het standaardpad eruit

Sluit het standaardpad uit voordat je uploadt. Met deze techniek kun je datasets met 90 tot 95% verkleinen.

De meeste bedrijfsprocessen volgen de 80/20-regel. Het overgrote deel van de cases volgt het standaardpad en verloopt goed. Zoek je naar uitzonderingen, compliance-overtredingen of procesafwijkingen, dan heb je die data niet nodig.

Voorbeeld: Een purchase-to-pay-proces met 1,2 miljoen inkooporders (8,4 miljoen events):

• 1,1 miljoen orders (92%) volgen het standaardpad: PO aanmaken → Goedkeuren → Goederenontvangst → Factuur → Betaling
• 96.000 orders (8%) bevatten uitzonderingen: afwijzingen, retouren, dubbele facturen en ontbrekende goedkeuringen

Analyseer je complianceproblemen, exporteer dan alleen de uitzonderingscases. Dat is een reductie van 92%, van 8,4 miljoen events (1,9 GB) naar 670.000 events (150 MB). Op een verbinding van 100 Mbps daalt de uploadtijd van 3 minuten naar 15 seconden. Exporteer als Parquet (15 MB) en je kunt het bestand in minder dan 2 seconden uploaden.

Kolommen selecteren: minder is meer

Elke kolom die je exporteert kost bandbreedte, opslagruimte en verwerkingstijd. Door kolommen zorgvuldig te kiezen, kun je een van de grootste optimalisaties doorvoeren.

Wat je kunt weglaten:

• Lange tekstvelden. Orderomschrijvingen, opmerkingen, notities en vrije tekstvelden. Een omschrijvingsveld van 500 tekens voor 5 miljoen events voegt 2,5 GB aan je bestand toe.
• PII (persoonlijk identificeerbare informatie). Namen, e-mailadressen en telefoonnummers. Door PII te verwijderen, verklein je het bestand, voorkom je privacyrisico’s en vereenvoudig je compliance.
• Overbodige identificatiegegevens. Heb je OrderId, dan heb je OrderGUID, OrderReference of LegacyOrderNumber niet nodig.
• Auditkolommen. CreatedBy, ModifiedBy, CreatedDate en ModifiedDate. Laat ze weg, tenzij je ze specifiek analyseert.
• Systeemkolommen. Interne vlaggen, partitiesleutels en technische metadata.

Voorbeeld: Een SAP-export van 1,8 miljoen inkooporder-events met 45 kolommen werd teruggebracht naar 12 essentiële kolommen:

• Bestandsgrootte: 2,1 GB → 380 MB (82% reductie)
• Als Parquet: 380 MB → 58 MB (nog eens 85% reductie)
• Uploadtijd (100 Mbps): 3,5 min. → 6 seconden
• Dezelfde analytische waarde

De kolommen die ertoe doen: CaseId, Activity, Timestamp en enkele bedrijfsattributen, zoals status, bedrag, categorie en regio. Al het andere is waarschijnlijk ruis.

Wanneer schaal belangrijk wordt

Voor sommige analytische vragen heb je echt grote datasets nodig. Als je weet wanneer dat zo is, kun je de juiste keuze maken:

• Zeldzame gebeurtenissen opsporen. Als je edge cases wilt vinden die één op de 100.000 keer voorkomen, heb je een populatie nodig die groot genoeg is voor bruikbare steekproeven. Wil je 50 gevallen van een zeldzame uitzondering analyseren en komt die 0,01% van de tijd voor, dan heb je 500.000 cases nodig.
• Paden met een lage frequentie meten. Procesvarianten die 0,1% van de tijd voorkomen, zijn misschien onzichtbaar in een steekproef van 1 miljoen events, maar wel relevant in een populatie van 50 miljoen events.
• Compliance en audit. Sommige regels vereisen dekking van de volledige populatie. Steekproeven zijn dan niet toegestaan.
• Trends over meerdere jaren analyseren. Als je Q1 2024 met Q1 2025 en Q1 2026 vergelijkt, heb je data uit alle drie de perioden nodig. Gebruik delta loading om dit stap voor stap op te bouwen.

Heb je 50 miljoen events of meer nodig, bereid je daar dan op voor: gebruik Parquet-formaat, waarmee je een CSV-bestand van 11 GB terugbrengt naar 1,7 GB en de voorbewerking versnelt; gebruik de API voor betrouwbare overdracht; en gebruik indien mogelijk een snelle netwerkverbinding. Na die eerste upload blijven dashboards snel.

Het model en de interface snel houden

De bovenstaande secties gaan over datavolume. De andere helft van een snelle interface zit in de manier waarop het model en de dashboards zijn opgebouwd:

• Vereenvoudig het model. Deel grote processen op in modulaire subprocessen. Een canvas met duizend zichtbare elementen wordt traag weergegeven en is niet te lezen. Voer auto-layout uit na structurele wijzigingen.
• Wees selectief met dashboards. Elke grafiek en tegel moet worden berekend. Houd de grafieken waarop iemand actie onderneemt en verplaats de rest naar een eigen dashboard in plaats van alles in één weergave te stapelen.
• Stem de grafiek af op de dataset. Vermijd bij grote datasets visualisaties die veel rekenwerk vragen, zoals gedetailleerde cirkeldiagrammen en uitsplitsingen met veel categorieën. Kies in plaats daarvan grafieken die samenvatten.
• Gebruik filters met mate. Filters zijn afzonderlijk goedkoop maar samen duur. Houd de set die je vraag beantwoordt en verwijder die daarna.
• Bekijk de animatie. De kosten van animatie nemen toe met het aantal actieve cases. Verlaag de snelheid of schakel staarten en effecten uit als je alleen de flow nodig hebt. Bekijk Procesanimatie.
• Archiveer en kijk later opnieuw. Verplaats oude datasets en processen uit de actieve workspace en gebruik simulatie met de tijdmetrieken om te bepalen welke bottlenecks je moet aanpakken, in plaats van alles tegelijk te optimaliseren.

Volgende stappen

De beste manier om de prestaties van process mining te begrijpen, is door het met je eigen data te ervaren.

1. Begin met een sample. Exporteer 1 miljoen events uit een recente periode in Parquet-formaat. Upload ze. Bouw je eerste model. Ervaar hoe snel je kunt itereren.

2. Pas de technieken uit deze gids toe. Gebruik kolomgebaseerde formaten. Filter op uitzonderingen. Segmenteer per regio. Verwijder overbodige kolommen. Elke optimalisatie bouwt voort op de vorige.

3. Schaal bewust op. Zodra je je proces met 1 miljoen events begrijpt, bepaal je of je meer nodig hebt. Meestal is dat niet zo. Heb je wel meer data nodig, gebruik dan delta loading om data toe te voegen in plaats van alles opnieuw te uploaden.

Start je gratis proefperiode en bekijk deze benchmarks in de praktijk. Hulp nodig bij het bepalen van de juiste datasetgrootte of het optimaliseren van je exports? Neem contact met ons op. We hebben honderden organisaties geholpen de juiste balans te vinden tussen datavolume en analysesnelheid.