Process-Mining-Performance: Benchmarks und Tipps

Was bestimmt die Performance von Process Mining?

Die Performance von Process Mining hängt von drei Faktoren ab: von der Menge der hochgeladenen Daten, ihrer Struktur und der Verarbeitung durch das System. Dieser Leitfaden behandelt alle drei Aspekte mit konkreten Benchmarks und praxisnahen Möglichkeiten zur Verbesserung der Ergebnisse.

Wir veröffentlichen alle unsere Zahlen. Vergleichen Sie sie mit jedem Process-Mining-Tool auf dem Markt.

Die Datenpipeline: Wo die Zeit bleibt

Wenn Sie Daten in ProcessMind hochladen, geschehen drei Dinge. Hier sehen Sie genau, wofür die Zeit benötigt wird:

1. Upload (nimmt den größten Teil der Gesamtzeit ein). Ihre Datei wird über das Internet in unsere Cloud-Infrastruktur übertragen. Bei großen Dateien ist dies der Engpass. Die Physik setzt Grenzen: Eine CSV-Datei mit 50 Millionen Events und 11 GB benötigt bei Gigabit-Geschwindigkeit 2 Minuten, bei 100 Mbit/s 18 Minuten und bei 10 Mbit/s mehr als 3 Stunden. Dieselben Daten belegen im Parquet-Format nur 1,7 GB. Dadurch sinken die Zeiten auf 19 Sekunden, 3 Minuten beziehungsweise 28 Minuten. Das ist der wichtigste Grund, Spaltenformate wie Parquet oder ORC beziehungsweise kleinere Datensätze zu verwenden.

2. Vorverarbeitung (einmaliger Aufwand, etwa 30 Sekunden bis 2,5 Minuten). Nach dem Upload wandeln wir Ihre Daten in einen optimierten Spaltenspeicher um: Events werden indexiert, Aktivitätsübergänge vorab berechnet, Prozessvarianten identifiziert und zusammenfassende Statistiken ermittelt. Bei kleinen Datensätzen dauert dies 30 Sekunden, bei 100 Millionen Events bis zu 2,5 Minuten. Dieser Aufwand fällt pro Upload nur einmal an. Danach profitieren Sie davon.

3. Modelländerungen (teilweise Neuberechnung, 6 bis 52 Sekunden). Wenn Sie das Prozessmodell ändern, indem Sie Aktivitäten hinzufügen oder entfernen oder Zuordnungen anpassen, werden nur die modellabhängigen Berechnungen aktualisiert. Bei kleinen Datensätzen dauert dies 6 Sekunden, bei 100 Millionen Events bis zu 52 Sekunden und damit deutlich weniger als eine vollständige Vorverarbeitung. Änderungen an Filtern werden sofort übernommen.

Abfrage-Performance verstehen

Sobald Ihre Daten geladen sind, bestimmen mehrere Eigenschaften die Geschwindigkeit von Abfragen. Wenn Sie diese verstehen, können Sie bessere Exporte erstellen und realistische Erwartungen festlegen.

Die Anzahl der Aktivitäten ist entscheidend. Prozessmodelle mit 10 bis 20 unterschiedlichen Aktivitäten sind optimal. Bei mehr als 50 Aktivitäten dauert die Berechnung des Prozessflusses länger und die Darstellung wird unübersichtlicher. Zu viele Knoten und Kanten erzeugen visuelles Rauschen. Wenn Ihr Export viele Aktivitäten enthält, sollten Sie zusammengehörige Schritte gruppieren.

Die Vielfalt der Varianten beeinflusst die Berechnung. Ein Prozess, in dem 80 % der Cases fünf Varianten folgen, lässt sich schneller analysieren als ein Prozess, bei dem jeder Case einen eigenen Pfad nimmt. Eine hohe Varianz ist nicht grundsätzlich problematisch und weist oft auf reale Probleme hin. Rechnen Sie jedoch mit etwas längeren Abfragezeiten.

Mehr Spalten bedeuten mehr Scanaufwand. Jedes enthaltene Attribut wird indexiert und abgefragt. Die Kernspalten CaseId, Activity und Timestamp werden immer benötigt. Zusätzliche Spalten erleichtern Filterung und Kategorisierung, erhöhen aber jeweils den Verarbeitungsaufwand.

Lange Cases benötigen mehr Zeit. Ein Case mit 50 Events erfordert mehr Berechnungen als ein Case mit 5 Events. Wenn Ihre Prozesse Cases mit mehreren hundert Events enthalten, werden Abfragen entsprechend langsamer. Das liegt in der Natur von Process Mining und nicht an einem bestimmten Tool.

Benchmark-Daten aus der Praxis (März 2026)

Wenn Sie wissen, was Sie erwartet, können Sie besser planen. Diese Benchmarks wurden auf produktiver AWS-Infrastruktur mit realer Netzwerklatenz durchgeführt und über mehrere Testläufe gemittelt. Wir haben mehr als 50 Abfragetypen pro Datensatzgröße getestet.

Upload- und Vorverarbeitungszeiten

Die folgende Tabelle zeigt realistische Erwartungen für jede Datensatzgröße. Bei größeren Dateien nimmt der Upload besonders über langsamere Verbindungen den größten Teil der Zeit ein. Er ist der wichtigste einzelne Faktor für Ihre gesamte Wartezeit.

Die Dateigrößen beziehen sich auf unkomprimierte CSV-Dateien mit einem typischen Event-Log-Schema (CaseId, Activity, Timestamp sowie 5 bis 8 geschäftliche Attribute). Ihre Dateien können je nach Spaltenanzahl und Inhalt größer oder kleiner sein.

Die Upload-Zeiten bei 1 Gbit/s wurden gemessen, mit einem effektiven Durchsatz von 88 MB/s zu AWS eu-central-1. Die anderen Geschwindigkeiten wurden anhand praxisnaher Durchsätze hochgerechnet: 50 Mbit/s → etwa 5 MB/s, 100 Mbit/s → etwa 10 MB/s, 10 Mbit/s → etwa 1 MB/s. Der tatsächliche Durchsatz hängt von Ihrem Netzwerk, der Entfernung zum Rechenzentrum und der aktuellen Auslastung ab.

Die wichtigste Erkenntnis: Die Vorverarbeitungszeit bleibt unabhängig vom Umfang zwischen 1 und 2,5 Minuten. Die Upload-Zeit steigt linear mit der Dateigröße. Die Dateigröße zu reduzieren, ist die wirkungsvollste Optimierung.

Das passende Dateiformat wählen

Das von Ihnen hochgeladene Dateiformat beeinflusst Upload-Geschwindigkeit und Vorverarbeitungszeit erheblich. ProcessMind unterstützt CSV, Parquet, ORC, Excel und XES. Bei großen Datensätzen sind Parquet und ORC CSV deutlich überlegen, sowohl bei der Dateigröße als auch bei der Verarbeitungsgeschwindigkeit.

Vergleich der Dateigrößen

Parquet-Dateien sind 85 % kleiner als CSV-Dateien. ORC-Dateien sind 82 % kleiner. Beide Formate speichern Daten spaltenbasiert und verfügen über integrierte Komprimierung, sodass kein zusätzlicher Schritt erforderlich ist. Ihr ETL-Tool oder Ihre Datenplattform, etwa Spark, Databricks, dbt oder BigQuery, unterstützt den Export nach Parquet oder ORC wahrscheinlich bereits.

Vorverarbeitung nach Format

Die Dateigröße ist nur die halbe Wahrheit. Nach dem Upload durchlaufen Ihre Daten eine formatabhängige Aufnahme und analytische Berechnung, einschließlich Event-Indexierung sowie der Berechnung von Übergängen und Varianten. Der Analyseschritt nimmt den größten Teil der Zeit ein und ist bei allen Formaten gleich. CSV.GZ ist das einzige Format mit deutlich höherem Zusatzaufwand, da gzip-Dateien nicht für die parallele Dekomprimierung aufgeteilt werden können.

Die Vorverarbeitungszeit ist bei Parquet, ORC und CSV nahezu identisch, weil die analytische Berechnung unabhängig vom Eingabeformat den größten Anteil ausmacht. Bei CSV.GZ verschlechtert sich die Leistung deutlich mit zunehmendem Umfang: von etwa einer Minute bei 1 Million Events auf mehr als 4 Minuten bei 100 Millionen Events. Gzip-komprimierte Dateien können nicht aufgeteilt und parallel verarbeitet werden. Die Dekomprimierung fügt daher einen zusätzlichen, mit der Dateigröße wachsenden Schritt vor Beginn der Analyse hinzu.

Das Gesamtbild

Wenn Sie Upload-Zeit und Vorverarbeitung gemeinsam betrachten, wird die Wahl des Formats deutlich:

Bei großen Datensätzen sind Parquet und ORC eindeutig die beste Wahl, weil ihre Dateien deutlich kleiner sind. Die Upload-Zeit ist der wichtigste Engpass. Die Vorverarbeitung dauert bei allen Formaten ungefähr gleich lange, mit Ausnahme von CSV.GZ, bei dem der Aufwand für die Dekomprimierung mit zunehmender Größe steigt.

Delta Loading: Daten ohne erneuten Upload hinzufügen

Nachdem Sie einen Basisdatensatz geladen haben, müssen Sie bei neuen Daten nicht alles erneut hochladen. ProcessMind unterstützt Delta Loading beziehungsweise inkrementelle Uploads. So können Sie neue Events an einen bestehenden Datensatz anhängen.

So funktioniert es:

1. Laden Sie Ihren ersten Datensatz hoch, etwa Bestellungen aus Q1 2026 mit 2,3 Millionen Events
2. Wenn die Daten für Q2 vorliegen, laden Sie nur die neuen Events als Delta-Datei hoch, etwa 800.000 neue Events
3. ProcessMind führt die Dateien automatisch zusammen und verarbeitet sie erneut

Die Auswirkungen auf die Performance sind erheblich. Statt Ihren wachsenden Datensatz jedes Mal erneut hochzuladen, übertragen Sie nur die neuen Daten:

Nach einem Delta-Upload wird der kombinierte Datensatz erneut vorverarbeitet, mit demselben Aufwand von 1 bis 2,5 Minuten. Sie sparen jedoch die gesamte Upload-Zeit für Daten, die bereits übertragen wurden.

Delta Loading eignet sich besonders für:

• Wöchentliche oder monatliche Datenaktualisierungen: Hängen Sie neue Transaktionen an, sobald sie verfügbar sind
• Kontinuierliche Prozessüberwachung: Halten Sie Dashboards ohne große Uploads aktuell
• Wachsende Event Logs: Fügen Sie neue Events aus ERP-, CRM- oder anderen Quellsystemen hinzu

Delta-Dateien müssen dasselbe Dateiformat und dieselbe Spaltenstruktur wie der ursprüngliche Upload verwenden. Einzelheiten finden Sie im Leitfaden zum inkrementellen Laden von Daten.

Die API für große oder automatisierte Uploads verwenden

Bei Datensätzen von mehreren Gigabyte oder regelmäßigen Uploads sind Skripte und Kommandozeilentools zuverlässiger als Uploads über den Browser. Browser können Timeouts verursachen, übermäßig viel Arbeitsspeicher belegen oder bei einer Netzwerkunterbrechung den Fortschritt verlieren.

Warum die API bei großen Dateien besser geeignet ist:

• Zuverlässige Übertragungen. Wenn Ihre Verbindung abbricht, können Sie den Vorgang fortsetzen, ohne von vorn zu beginnen.
• Keine Speichergrenzen des Browsers. Browser haben Schwierigkeiten mit Dateien von mehreren Gigabyte. Kommandozeilentools verarbeiten solche Dateien problemlos.
• Automatisierung. Planen Sie nächtliche Uploads, integrieren Sie sie in ETL-Pipelines oder lösen Sie Uploads aus CI/CD-Prozessen aus.
• Fortschrittsüberwachung. Tools wie curl zeigen den Übertragungsfortschritt in Echtzeit an.
• Delta-Uploads. Hängen Sie neue Daten programmgesteuert nach einem festen Zeitplan an.

Beispiel mit curl:

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

ProcessMind stellt vorab signierte URLs bereit, die direkte Uploads in den Cloud-Speicher autorisieren. Außer Ihrem API-Schlüssel sind keine weiteren Zugangsdaten erforderlich. Sie können die vorab signierte Upload-URL auch direkt im Menü für die Datensatzeinstellungen der ProcessMind-Oberfläche kopieren.

Vollständige Beispiele für Bash, JavaScript und Python finden Sie in der API-Dokumentation. Sie zeigen unter anderem, wie Sie vorab signierte URLs abrufen, Delta-Dateien hochladen und große Datensätze programmgesteuert verarbeiten.

Geschwindigkeit bei Modelliterationen

Wenn Sie Ihr Prozessmodell durch das Umbenennen von Aktivitäten, das Ändern von Zuordnungen oder das Hinzufügen von Gruppierungen verfeinern, müssen nur die modellabhängigen Berechnungen aktualisiert werden. Die Basisdaten bleiben erhalten:

Modelländerungen sind schnell, weil der anfängliche Ladevorgang, dessen Dauer mit der Datensatzgröße steigt, bereits abgeschlossen ist. Nur der modellabhängige Aggregationsschritt wird erneut ausgeführt, einschließlich Aktivitätszuordnungen, Übergängen und Varianten. Bei Datensätzen mit bis zu 20 Millionen Events sind Modelländerungen in weniger als 25 Sekunden abgeschlossen. Selbst bei 100 Millionen Events dauert dies weniger als eine Minute und damit deutlich weniger als eine vollständige Vorverarbeitung.

Antwortzeiten des Dashboards

Sobald Ihre Daten geladen sind, erleben Sie während der Analyse die folgenden Antwortzeiten. Die angegebenen Werte sind Mediane aus mehreren Benchmark-Läufen. Jede Dashboard-Komponente führt ihre Abfrage unabhängig aus und wird parallel geladen:

Diese Muster fallen auf:

• Statistiken, einschließlich zusammenfassender Anzahlen und Durchlaufzeiten, bleiben unabhängig von der Größe bei etwa 0,6 Sekunden. Diese Abfragen sind stark optimiert.
• Prozessfluss, also das Prozessdiagramm, skaliert mit der Datensatzgröße, weil Übergänge zwischen allen Aktivitäten berechnet werden.
• Varianten und Kategorien skalieren moderat. Voraggregierte Daten halten die Antwortzeiten kurz.
• Datenbrowser bleibt durch die Seitennavigation schnell. Mit gesetzten Filtern sinkt die Antwortzeit auf unter 1 Sekunde.
• Animation variiert mit der Anzahl der aktiven Cases, die visualisiert werden.

Die wichtigste Aussage: Bei den empfohlenen Datensatzgrößen von 1 bis 10 Millionen Events reagiert jede Dashboard-Komponente in weniger als 3,5 Sekunden. Selbst bei 50 Millionen Events werden die meisten Abfragen mit gesetzten Filtern in 2 bis 4 Sekunden beantwortet. Nur ungefilterte Prozessflüsse und Kategorieansichten auf Datensätzen mit mindestens 50 Millionen Events erreichen 5 bis 6 Sekunden.

Klein anfangen, groß werden

Das ist der wichtigste Rat in dieser Anleitung: Beginnen Sie nicht mit Ihrem größten Datensatz.

Die Zahlen sprechen für sich:

Die meisten Unternehmen stellen fest, dass 1 bis 5 Millionen Events für verwertbare Erkenntnisse mehr als ausreichend sind. Das Prozessverhalten stabilisiert sich deutlich vor 10 Millionen Events. Darüber hinaus fügen Sie meist nur weitere Fälle bereits bekannter Muster hinzu.

Wenn Ihre Parquet-Datei mit 1 Million Events 34 MB groß ist, in 3 Sekunden hochgeladen wird und Ihnen dieselbe Prozesslandkarte wie 50 Millionen Events liefert, warum sollten Sie 18 Minuten warten?

Datenstrategie: Die richtige Größe finden

Die Zahlen oben zeigen ein klares Bild: Bei 1 bis 5 Millionen Events dauern Uploads Sekunden, die Vorverarbeitung weniger als 2 Minuten und Dashboard-Antworten 1 bis 2,5 Sekunden. Bei 50 Millionen Events warten Sie bei 100 Mbit/s 20 Minuten auf den Upload, während Dashboards 3 bis 6 Sekunden benötigen. Der Unterschied in der Nutzung ist erheblich.

Die entscheidende Frage lautet also nicht: „Wie schnell ist das Tool?“ Sondern: „Wie viele Daten benötige ich tatsächlich?“ Die Antwort lautet fast immer: weniger, als Sie denken.

Zuerst segmentieren, später aggregieren

Analysieren Sie zunächst ein Land, eine Abteilung oder eine Produktlinie.

Dabei geht es nicht um Einschränkung, sondern um Klarheit. Eine segmentierte Analyse liefert präzisere Erkenntnisse als globale Durchschnittswerte.

Warum Segmentierung funktioniert:

• Prozesse unterscheiden sich je nach Region. Deutsche Abläufe folgen anderen Genehmigungsketten als Abläufe in den USA. Französische Arbeitsgesetze führen zu anderen HR-Workflows. Eine gemeinsame Analyse erzeugt unnötiges Rauschen.
• Andere Stakeholder haben andere Prioritäten. Der VP für EMEA interessiert sich für EMEA. Zeigen Sie ihm EMEA-Daten. Die globale Sicht kann später folgen.
• Schnellere Iterationen. Die Daten eines einzelnen Landes können 500.000 statt 10 Millionen Events umfassen. Sie iterieren in Minuten statt in Stunden.
• Integrierte Vergleichsmöglichkeiten. Analysieren Sie zunächst Deutschland und anschließend Frankreich. So können Sie beide Länder vergleichen.

Beispiel: Ein europäisches Logistikunternehmen mit 42 Millionen Versand-Events aus 8 Ländern:

• Alles analysieren: 42 Millionen Events, 9,3 GB, 16 Minuten Upload (100 Mbit/s), 2 Minuten Vorverarbeitung
• Nur Deutschland analysieren: 8,5 Millionen Events, 1,9 GB, 3 Minuten Upload, 1,5 Minuten Vorverarbeitung
• Nur die Niederlande analysieren: 3,1 Millionen Events, 690 MB, 1 Minute Upload, 1 Minute Vorverarbeitung
• Delta Loading verwenden: Zuerst Deutschland hochladen, anschließend die Niederlande hinzufügen, sobald die Daten bereitstehen

Den Happy Path herausfiltern

Schließen Sie den Happy Path vor dem Upload aus. Dadurch lässt sich der Datensatz um 90 bis 95 % verkleinern.

Die meisten Geschäftsprozesse folgen der 80/20-Regel. Die große Mehrheit der Cases nimmt den standardmäßigen, erfolgreichen Weg. Wenn Sie nach Ausnahmen, Compliance-Verstößen oder Prozessabweichungen suchen, benötigen Sie diese Daten nicht.

Beispiel: Ein Purchase-to-Pay-Prozess mit 1,2 Millionen Bestellungen und 8,4 Millionen Events:

• 1,1 Millionen Bestellungen (92 %) folgen dem Happy Path: Create PO → Approve → Goods Receipt → Invoice → Payment
• 96.000 Bestellungen (8 %) enthalten Ausnahmen: Ablehnungen, Rücksendungen, doppelte Rechnungen und fehlende Genehmigungen

Wenn Sie Compliance-Probleme analysieren, exportieren Sie nur die Ausnahme-Cases. Das entspricht einer Reduzierung um 92 %, von 8,4 Millionen Events (1,9 GB) auf 670.000 Events (150 MB). Bei 100 Mbit/s sinkt die Upload-Zeit von 3 Minuten auf 15 Sekunden. Exportieren Sie die Daten als Parquet-Datei (15 MB), können Sie sie in weniger als 2 Sekunden hochladen.

Spaltenauswahl: Weniger ist mehr

Jede exportierte Spalte verursacht Aufwand für Bandbreite, Speicher und Verarbeitung. Eine sorgfältige Spaltenauswahl gehört zu den wirkungsvollsten Optimierungen.

Was Sie weglassen sollten:

• Lange Textfelder. Bestellbeschreibungen, Kommentare, Notizen und Freitextfelder. Ein Beschreibungsfeld mit 500 Zeichen fügt bei 5 Millionen Events 2,5 GB zu Ihrer Datei hinzu.
• PII (personenbezogene Daten). Namen, E-Mail-Adressen und Telefonnummern. Wenn Sie PII entfernen, verringern Sie die Dateigröße, beseitigen Datenschutzrisiken und vereinfachen die Compliance.
• Redundante Identifikatoren. Wenn Sie OrderId haben, benötigen Sie OrderGUID, OrderReference oder LegacyOrderNumber nicht zusätzlich.
• Audit-Spalten. CreatedBy, ModifiedBy, CreatedDate und ModifiedDate. Lassen Sie diese Spalten weg, sofern Sie sie nicht gezielt analysieren.
• Systemspalten. Interne Kennzeichen, Partitionsschlüssel und technische Metadaten.

Beispiel: Ein SAP-Export mit 1,8 Millionen Bestell-Events und 45 Spalten wurde auf 12 wesentliche Spalten reduziert:

• Dateigröße: 2,1 GB → 380 MB (82 % Reduzierung)
• Als Parquet: 380 MB → 58 MB (weitere Reduzierung um 85 %)
• Upload-Zeit (100 Mbit/s): 3,5 Min. → 6 Sekunden
• Gleicher analytischer Nutzen

Die wichtigen Spalten: CaseId, Activity, Timestamp und einige geschäftliche Attribute, etwa Status, Betrag, Kategorie und Region. Alles andere ist wahrscheinlich überflüssig.

Wann der Umfang entscheidend ist

Für einige analytische Fragen benötigen Sie tatsächlich große Datensätze. Wenn Sie wissen, wann dies der Fall ist, können Sie die richtige Entscheidung treffen:

• Erkennung seltener Events. Um Sonderfälle zu finden, die einmal in 100.000 Fällen auftreten, benötigen Sie eine ausreichend große Grundgesamtheit mit aussagekräftigen Stichproben. Wenn Sie 50 Fälle einer seltenen Ausnahme analysieren möchten und diese in 0,01 % der Fälle auftritt, benötigen Sie 500.000 Cases.
• Messung selten genutzter Pfade. Prozessvarianten, die in 0,1 % der Fälle auftreten, sind in einer Stichprobe mit 1 Million Events möglicherweise unsichtbar, können in einer Grundgesamtheit mit 50 Millionen Events jedoch relevant sein.
• Compliance und Audit. Einige Vorschriften verlangen eine vollständige Abdeckung der Grundgesamtheit. Eine Stichprobe ist dann nicht zulässig.
• Trendanalyse über mehrere Jahre. Für den Vergleich von Q1 2024, Q1 2025 und Q1 2026 benötigen Sie Daten aus allen drei Zeiträumen. Bauen Sie den Datensatz mit Delta Loading schrittweise auf.

Wenn Sie mehr als 50 Millionen Events benötigen, planen Sie entsprechend: Verwenden Sie das Parquet-Format, das eine 11-GB-CSV-Datei auf 1,7 GB reduziert und die Vorverarbeitung beschleunigt; verwenden Sie die API für zuverlässige Übertragungen; und nutzen Sie, sofern verfügbar, eine schnelle Netzwerkverbindung. Nach dem ersten Laden bleiben Dashboards schnell.

Modell und Benutzeroberfläche schnell halten

In den oben genannten Abschnitten ging es um das Datenvolumen. Die andere Hälfte der Reaktionsfähigkeit hängt davon ab, wie Modell und Dashboards aufgebaut sind:

• Vereinfachen Sie das Modell. Teilen Sie große Prozesse in modulare Subprocesses auf. Eine Zeichenfläche mit tausend sichtbaren Elementen wird langsam gerendert und ist kaum lesbar. Führen Sie nach strukturellen Änderungen Auto-Layout aus.
• Setzen Sie Dashboards gezielt ein. Jeder Chart und jedes Kachel-Element muss berechnet werden. Behalten Sie die Charts, auf deren Grundlage jemand handelt, und verschieben Sie den Rest in ein eigenes Dashboard, statt alles in einer Ansicht zu stapeln.
• Passen Sie den Chart an den Datensatz an. Vermeiden Sie bei großen Datensätzen Visualisierungen mit hohem Berechnungsaufwand, etwa detaillierte Kreisdiagramme oder Aufschlüsselungen mit vielen Kategorien. Verwenden Sie stattdessen zusammenfassende Charts.
• Setzen Sie Filter zurückhaltend ein. Einzelne Filter sind kostengünstig, in Kombination können sie jedoch teuer werden. Behalten Sie nur die Filter, die Ihre Frage beantworten, und entfernen Sie sie anschließend.
• Beobachten Sie die Animation. Der Aufwand für die Animation steigt mit der Zahl aktiver Cases. Verringern Sie die Geschwindigkeit oder deaktivieren Sie Spuren und Effekte, wenn Sie nur den Ablauf benötigen. Siehe Prozessanimation.
• Archivieren Sie und prüfen Sie später erneut. Verschieben Sie alte Datensätze und Prozesse aus dem aktiven Arbeitsbereich. Verwenden Sie Simulation zusammen mit Zeitkennzahlen, um die Engpässe zu finden, deren Behebung sich lohnt, statt alles gleichzeitig zu optimieren.

Nächste Schritte

Am besten verstehen Sie die Performance von Process Mining, wenn Sie sie mit Ihren eigenen Daten erleben.

1. Beginnen Sie mit einer Stichprobe. Exportieren Sie 1 Million Events aus einem aktuellen Zeitraum im Parquet-Format. Laden Sie sie hoch. Erstellen Sie Ihr erstes Modell. Sehen Sie, wie schnell Sie iterieren können.

2. Wenden Sie die Techniken aus dieser Anleitung an. Verwenden Sie Spaltenformate. Filtern Sie nach Ausnahmen. Segmentieren Sie nach Region. Entfernen Sie nicht benötigte Spalten. Jede Optimierung baut auf der vorherigen auf.

3. Skalieren Sie bewusst. Sobald Sie Ihren Prozess mit 1 Million Events verstehen, entscheiden Sie, ob Sie mehr Daten benötigen. Meistens ist das nicht der Fall. Wenn Sie mehr Daten brauchen, verwenden Sie Delta Loading, um sie anzuhängen, statt sie erneut hochzuladen.

Starten Sie Ihre kostenlose Testphase und erleben Sie diese Benchmarks in der Praxis. Wenn Sie Unterstützung bei der Größenbestimmung Ihres Datensatzes oder bei der Optimierung Ihrer Exporte benötigen, kontaktieren Sie uns. Wir haben Hunderten Unternehmen geholfen, das richtige Verhältnis zwischen Datenvolumen und Analysegeschwindigkeit zu finden.