Prestaties van process mining: benchmarks en tips

De prestaties van process mining hangen van meer af dan alleen het aantal events. Ook de bestandsgrootte, het aantal cases, de query en de netwerksnelheid bepalen hoelang je moet wachten. De benchmarks hieronder zijn gebaseerd op datasets met 100K tot 100M events. Ze zijn in maart 2026 uitgevoerd op AWS-infrastructuur voor productie, met de bestandsindelingen en testomstandigheden die hier worden beschreven.

Wat bepaalt de prestaties van process mining?

Vier factoren bepalen de prestaties: de hoeveelheid data, de structuur van het event log, de query en de omgeving waarin je de data overdraagt en verwerkt.

• Aantal events en cases: Meer events betekenen meestal meer data om te uploaden en te verwerken. Het aantal cases bepaalt hoeveel procesinstanties je analyse omvat.
• Queryvorm: Voor een samenvattend statistisch cijfer zijn andere berekeningen nodig dan voor een processtroom. Queries die overgangen tussen activiteiten berekenen, kunnen langer duren dan queries op vooraf geaggregeerde data.
• Aantal activiteiten en caselengte: Meer verschillende activiteiten en langere cases vragen meer rekenwerk voor het berekenen van stromen en varianten.
• Bestandsgrootte en netwerksnelheid: Deze bepalen de uploadtijd. Een breed CSV-bestand met lange tekstvelden kan veel groter zijn dan een compact kolomgeoriënteerd bestand met dezelfde events.

Alleen het aantal events is niet genoeg om te voorspellen hoe lang een dataset nodig heeft. Gebruik de benchmarks als richtlijn en test daarna het event log en de queries die je wilt gebruiken. Zo krijg je het bruikbaarste beeld van de prestaties van process mining in jouw omgeving.

De datapipeline: waar gaat de tijd naartoe?

Een dataset doorloopt drie fases: upload, voorbewerking en herberekening als je het procesmodel wijzigt.

1. Upload: Je bestand wordt via internet naar de cloudinfrastructuur van ProcessMind overgedragen. De netwerksnelheid en bestandsgrootte bepalen hoelang dat duurt. Een CSV-bestand met 50 miljoen events en een grootte van 11 GB duurt bijvoorbeeld ongeveer 2 minuten bij 1 Gbps, 18 minuten bij 100 Mbps of meer dan 3 uur bij 10 Mbps. Dezelfde data in een Parquet-bestand van 1,7 GB duurt bij die snelheden ongeveer 19 seconden, 3 minuten of 28 minuten.
2. Voorbewerking: Na de upload zet het systeem de data om naar geoptimaliseerde kolomopslag, indexeert het events, berekent het overgangen tussen activiteiten en procesvarianten en maakt het samenvattende statistieken. In de benchmarks hieronder duurt dit 35 seconden voor 100K events en maximaal 2,5 minuut voor 100M events.
3. Modelwijzigingen: Als je activiteitstoewijzingen wijzigt of activiteiten toevoegt of verwijdert, werkt ProcessMind de berekeningen bij die van het model afhangen. In de benchmarks hieronder duurt dit ongeveer 14 seconden voor 1M events en 52 seconden voor 100M events. Filterwijzigingen zijn meteen zichtbaar.

Bij grote datasets is het verkleinen van het bestand vaak de beste manier om de eerste wachttijd te verkorten. Na de voorbewerking hangt de querysnelheid af van wat je dashboard moet berekenen.

Hoe verschillen queryprestaties?

Niet elke query kost evenveel rekenwerk. Deze kenmerken helpen je te begrijpen wat je kunt verwachten en hoe je je data kunt indelen.

• Aantal activiteiten: Modellen met 10 tot 20 verschillende activiteiten zijn makkelijker te analyseren en weer te geven. Bij meer dan 50 activiteiten duurt het berekenen van processtromen langer en kan het lastiger worden om ze te lezen. Groepeer stappen die bij elkaar horen als dat het proces goed weergeeft.
• Variatie in varianten: Een proces waarin de meeste cases een beperkt aantal paden volgen, is doorgaans sneller te analyseren dan een proces waarin elke case een ander pad volgt. Veel variatie kan betekenisvol zijn, maar de query kan er langer door duren.
• Aantal kolommen: Voor procesanalyse zijn de basisvelden CaseId, Activity en Timestamp nodig. Extra attributen helpen bij filteren en categoriseren, maar vergroten de hoeveelheid data die moet worden overgedragen en doorzocht.
• Caselengte: Een case met 50 events vraagt meer rekenwerk dan een case met 5 events. Queries op processen met cases van honderden events kunnen langer duren.

Reactietijden van dashboards

Dit zijn medianen van meerdere benchmarktests. Elk dashboardonderdeel voert een eigen query uit en wordt parallel geladen.

De statistieken bleven bij alle geteste groottes rond de 0,6 seconde. Processtroom duurde langer naarmate het aantal events toenam, omdat de query overgangen tussen activiteiten berekent. Varianten en categorieën schaalden redelijk mee, terwijl de Databrowser vlot bleef dankzij paginering. De animatietijd hing af van het aantal weergegeven actieve cases.

Bij 1M tot 10M events varieerden de gemeten reactietijden van 0,6 tot 3,4 seconden, afhankelijk van het onderdeel. Bij 50M events duurden Processtroom en Categorieën ongeveer 5 tot 6 seconden. Dit zijn benchmarkresultaten, geen garantie voor elke dataset of omgeving.

Benchmarkdata: onder welke omstandigheden zijn de tests uitgevoerd?

Deze benchmarks zijn in maart 2026 uitgevoerd op AWS-infrastructuur voor productie. De upload- en voorbewerkingstijden zijn gemiddelden van meerdere tests. De reactietijden van dashboards zijn medianen van meerdere tests. Per datasetgrootte zijn meer dan 50 querytypen getest.

De aantallen hieronder zijn de werkelijke aantallen events in de testbestanden. De bestandsgroottes gelden voor ongecomprimeerde CSV-bestanden met een gebruikelijk event logschema: CaseId, Activity, Timestamp en 5 tot 8 bedrijfsattributen. De bestandsgrootte en resultaten kunnen verschillen door het aantal kolommen, de inhoud, de netwerkomstandigheden, de afstand tot het datacenter en de actuele belasting.

Upload- en voorbewerkingstijden

De gemeten overdrachtssnelheid van 1 Gbps was 88 MB/s naar AWS eu-central-1. De andere snelheden zijn berekend op basis van praktische doorvoersnelheden: ongeveer 5 MB/s bij 50 Mbps, 10 MB/s bij 100 Mbps en 1 MB/s bij 10 Mbps. De werkelijke doorvoersnelheid hangt af van je netwerk en de omstandigheden.

In deze test duurde de voorbewerking 35 seconden tot 2,5 minuut. De uploadtijd nam toe met de bestandsgrootte en vormde bij grote bestanden het grootste deel van de wachttijd.

Bestandsindeling: Parquet en ORC vergeleken met CSV

ProcessMind ondersteunt CSV, Parquet, ORC, Excel en XES. Voor deze vergelijking van bestandsgroottes zijn dezelfde aantallen events en hetzelfde schema gebruikt als in de benchmark hierboven.

In deze tests waren Parquet-bestanden ongeveer 85% kleiner dan CSV-bestanden en ORC-bestanden ongeveer 82% kleiner. Beide zijn kolomgeoriënteerde indelingen met ingebouwde compressie. Datatools zoals Spark, Databricks, dbt en BigQuery ondersteunen mogelijk export naar deze indelingen.

De voorbewerkingstijden waren vergelijkbaar voor Parquet, ORC en CSV. Bij grotere aantallen events duurde CSV.GZ langer, omdat gzip-bestanden niet kunnen worden opgesplitst voor parallelle decompressie.

De totale tijd bestaat uit de upload en de voorbewerking. Deze voorbeelden gaan uit van een verbinding van 100 Mbps.

Bij grote datasets verkorten Parquet en ORC de overdrachtstijd doordat de bestanden kleiner zijn. CSV blijft een eenvoudige keuze voor kleinere datasets of als je exportproces geen kolomgeoriënteerde indelingen ondersteunt. CSV.GZ kan de overdrachtstijd bij een trage verbinding verkorten, maar de decompressie kost meer tijd naarmate de dataset groter wordt.

Welke querypatronen kunnen de analyse vertragen?

Sommige data- en dashboardpatronen vragen meer rekenwerk dan andere. Gebruik deze punten om mogelijke oorzaken van tragere queries op te sporen.

• Te veel activiteiten: Een processtroom met meer dan 50 verschillende activiteiten kan langer duren om te berekenen en lastig te interpreteren zijn. Groepeer stappen die bij elkaar horen als dat past.
• Veel unieke varianten: Als cases veel verschillende paden volgen, is er meer rekenwerk nodig om de varianten te berekenen. Veel variatie kan ook wijzen op procesgedrag dat nader onderzoek verdient.
• Lange cases: Cases met veel events vragen meer verwerking dan korte cases.
• Onnodige kolommen: Extra attributen vergroten het bestand en kunnen extra werk opleveren bij queries. Behoud alleen de velden die je voor je analyse nodig hebt.
• Grote, volle dashboards: Elke grafiek of tegel voert een eigen query uit. Behoud de onderdelen die een duidelijke vraag beantwoorden en zet andere weergaven op een apart dashboard.
• Zware visualisaties: Bij grote datasets kunnen grafieken met veel categorieën langer nodig hebben om weer te geven. Gebruik een samenvatting als je geen gedetailleerde uitsplitsing nodig hebt.
• Animatie met veel actieve cases: De animatietijd hangt af van het aantal weergegeven cases. Verlaag de snelheid of schakel staartlijnen en effecten uit als je alleen de processtroom wilt bekijken.

Hoe kies je de juiste datagrootte?

Begin met de kleinste dataset waarmee je je vraag kunt beantwoorden. Een gerichte dataset is sneller te uploaden en makkelijker te controleren. Breid de dataset uit als je een groter deel van het proces, zeldzame events of trends over een langere periode wilt onderzoeken.

Stel je model in en controleer het met een kleinere dataset

Begin met een recente steekproef, stel je model in en controleer de data voordat je opschaalt.

1. Begin met een steekproef. Haal bijvoorbeeld 1M events uit een recente periode van drie maanden. In de benchmark duurde de upload 3 seconden bij 1 Gbps of 22 seconden bij 100 Mbps, gevolgd door 55 seconden voorbewerking.
2. Bouw je model op. Stel activiteiten, filters en weergaven in. Modelwijzigingen duurden ongeveer 14 tot 20 seconden voor de geteste datasets van 1M tot 10M events.
3. Controleer de bevindingen. Ga na of de activiteitennamen en procespaden kloppen en los problemen met de datakwaliteit op.
4. Voeg indien nodig meer data toe. Verhoog het aantal events als je zeldzame cases wilt onderzoeken of langere perioden wilt vergelijken.

De tabel vergelijkt de eerste wachttijd bij verschillende aantallen events en een verbinding van 100 Mbps.

Het juiste aantal events hangt af van je vraag. Een kleinere dataset is misschien voldoende voor veelvoorkomende procespatronen. Voor onderzoek naar zeldzame events of als je alle gevallen moet meenemen, heb je mogelijk meer data nodig.

Splits de data op als je een gerichte vraag hebt

Onderzoek je één land, afdeling of productlijn, begin dan met die groep in plaats van niet-gerelateerde groepen samen te voegen. Door data op te splitsen kun je vergelijkingen duidelijker maken en de hoeveelheid te verwerken data beperken.

De benchmark beschrijft bijvoorbeeld een Europese logistieke dataset met 42M verzendevents uit 8 landen:

• Alle landen: 42M events, 9,3 GB, 16 minuten uploadtijd bij 100 Mbps en 2 minuten voorbewerking.
• Duitsland: 8,5M events, 1,9 GB, 3 minuten uploadtijd en 1,5 minuut voorbewerking.
• Nederland: 3,1M events, 690 MB, 1 minuut uploadtijd en 1 minuut voorbewerking.

Je kunt de groepen vergelijken nadat je elke groep hebt gecontroleerd. Handige dimensies zijn onder meer geografie, organisatie, product, periode en klantsegment.

Filter op de cases die je nodig hebt

Onderzoek je uitzonderingen, dan kun je de dataset flink verkleinen door alleen relevante cases te exporteren. De benchmark beschrijft bijvoorbeeld een purchase-to-pay-proces met 1,2 miljoen inkooporders en 8,4M events. Volgens de benchmark waren er uitzonderingen bij 96.000 orders, oftewel 8%. Voorbeelden zijn afwijzingen, retouren, dubbele facturen en ontbrekende goedkeuringen.

Voor die analyse verkleint de export van de uitzonderingscases de dataset van 8,4M naar 670K events. De gerapporteerde bestandsgrootte daalt van 1,9 GB naar 150 MB. Bij 100 Mbps daalt de uploadtijd van 3 minuten naar 15 seconden. In de benchmark duurt het minder dan 2 seconden om dezelfde data als een Parquet-bestand van 15 MB te uploaden.

Filter op status, activiteit, caselengte, periode of bedrijfseenheid als die velden aansluiten op de vraag die je onderzoekt.

Selecteer alleen de kolommen die je nodig hebt

Elke kolom draagt bij aan de bestandsgrootte. Lange tekstvelden, dubbele identificatiegegevens, auditvelden en technische metadata zijn mogelijk niet nodig voor je analyse.

De benchmark beschrijft een SAP-export met 1,8M inkooporderevents en 45 kolommen. Door dit terug te brengen tot 12 essentiële kolommen daalde de bestandsgrootte van 2,1 GB naar 380 MB. Exporteren van die kolommen als Parquet verkleinde het bestand verder tot 58 MB. De gerapporteerde uploadtijd bij 100 Mbps daalde van 3,5 minuten naar 6 seconden.

Houd de velden die je nodig hebt voor je analyse, zoals CaseId, Activity, Timestamp en relevante bedrijfsattributen zoals status, bedrag, categorie of regio. Verwijder persoonsgegevens als je ze niet nodig hebt voor de analyse.

Wanneer heb je een grotere dataset nodig?

Een groter aantal events kan nodig zijn als je vraag afhangt van de dekking of de periode die je onderzoekt.

• Zeldzame events: Om uitzonderingen te vinden die één keer per 100.000 cases voorkomen, heb je een populatie nodig die groot genoeg is om ze te bevatten. Komt een uitzondering in 0,01% van de gevallen voor en wil je er 50 onderzoeken, dan heb je ongeveer 500.000 cases nodig.
• Varianten die weinig voorkomen: Varianten die in 0,1% van de gevallen voorkomen, zijn mogelijk niet zichtbaar in een steekproef van 1 miljoen events, maar wel goed meetbaar in een populatie van 50 miljoen events.
• Compliance en audits: Sommige vereisten vragen om dekking van de volledige populatie in plaats van een steekproef.
• Trends op lange termijn: Om Q1 2024 met Q1 2025 en Q1 2026 te vergelijken, heb je data uit alle drie de perioden nodig. Met delta loading bouw je die dekking stap voor stap op.

Voor datasets met meer dan 50 miljoen events adviseert de benchmark Parquet, uploaden via de API en waar mogelijk een snelle netwerkverbinding. Het CSV-bestand met 50 miljoen events uit de test was 11,1 GB, tegenover 1,7 GB voor Parquet.

Hoe houd je het model en de interface snel?

De hoeveelheid data is maar een deel van het verhaal. Ook het procesmodel en het ontwerp van het dashboard bepalen hoe vlot je kunt werken.

• Houd het model leesbaar: Deel grote processen op in modulaire Subprocesses. Een canvas met veel zichtbare elementen kan langer nodig hebben om te laden en is lastiger te navigeren. Gebruik auto-layout na structurele wijzigingen.
• Kies dashboardonderdelen zorgvuldig: Elke grafiek en tegel vraagt om een berekening. Houd alleen de weergaven die antwoord geven op je huidige vragen.
• Kies grafieken die passen bij de data: Bij grote datasets kan een visualisatie met veel categorieën langer nodig hebben om te berekenen. Gebruik een samenvatting als je geen gedetailleerde uitsplitsing nodig hebt.
• Beperk filters tot wat je wilt weten: Met filters kun je een analyse afbakenen. Combineer geen filters die niets toevoegen aan de vraag die je onderzoekt.
• Pas de animatie-instellingen aan: De animatie vraagt meer rekenkracht naarmate er meer actieve cases zijn. Verlaag de snelheid of schakel staarten en effecten uit als je alleen de flow wilt bekijken. Lees meer over Procesanimatie.
• Bereken alleen opnieuw wat is gewijzigd: Wijzigingen in het model werken door in de berekeningen die ervan afhankelijk zijn, zonder dat de volledige voorbewerking opnieuw hoeft. In de benchmark duurde dit ongeveer 14 seconden voor 1 miljoen events en 52 seconden voor 100 miljoen events.

Hoe verkort delta loading de uploadtijd?

Met delta loading voeg je nieuwe events toe aan een bestaande dataset, in plaats van de volledige dataset opnieuw te uploaden. Zo wordt er minder data overgedragen wanneer je een groeiend event log ververst.

Na een delta-upload wordt de gecombineerde dataset opnieuw voorbewerkt. In de benchmark duurde dat 1 tot 2,5 minuten. De tijdwinst bij het uploaden komt doordat alleen de nieuwe events worden overgedragen.

Een delt bestand moet hetzelfde bestandsformaat en dezelfde kolomstructuur hebben als de oorspronkelijke upload. Lees de gids voor incrementeel laden van data voor meer informatie.

Wanneer kun je het best uploaden via de API?

Bij terugkerende uploads of bestanden van meerdere gigabytes is uploaden via de API vaak eenvoudiger te beheren dan via de browser. Een script of opdrachtregelprogramma past in een ETL-pipeline, ondersteunt geplande uploads en toont de voortgang van de overdracht.

ProcessMind biedt vooraf ondertekende URL’s voor rechtstreekse uploads naar cloudopslag. Je kunt de upload-URL kopiëren via het instellingenmenu van de dataset in de ProcessMind-interface.

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

Bekijk de API-documentatie voor voorbeelden in Bash, JavaScript en Python. Daar lees je ook hoe je vooraf ondertekende URL’s ophaalt en delt bestanden uploadt.

Wanneer kun je een dataset het best opsplitsen?

Splits een dataset op als een specifieke analyse maar een deel van de data nodig heeft, of als je groepen afzonderlijk wilt vergelijken. Je kunt segmenteren op regio, afdeling, productlijn, periode of casetype en elke dataset daarna apart analyseren.

Houd de data bij elkaar als je groepen wilt vergelijken of het volledige proces over die groepen heen wilt volgen. Controleer vóór het opsplitsen of de indeling de betekenis van de case verandert of events weglaat die nodig zijn om het verloop te begrijpen. Bij een indeling op periode moet je bijvoorbeeld rekening houden met cases die in de ene periode beginnen en in een andere eindigen.

Test de prestaties met je eigen data

Benchmarks helpen je bij de planning, maar voorspellen niet hoe elk event log, netwerk of elke query presteert. Test de dataset die je wilt gebruiken en controleer daarna de uploadtijd, voorbewerkingstijd en reactietijden van de dashboardweergaven die voor jou belangrijk zijn.

Lees eerst de richtlijnen voor datavoorbereiding als je hulp nodig hebt bij het samenstellen van je event log. Bekijk ook hoe je je proces analyseert en hoe je je proces continu monitort.

Laad je grootste dataset en test ermee

Test met de hoeveelheid data die je zelf gebruikt