Process Discovery: Wie aus Ereignisdaten ein Prozessmodell entsteht

Ein Modell aus dem Log gewinnen

Das Process Mining Manifesto ordnet Discovery als grundlegende Form des Process Mining ein. Während Conformance-Verfahren ein bestehendes Modell mit Ereignissen vergleichen, erzeugt Discovery zunächst ein Modell aus dem Log selbst.[1]

Welche Strukturen entstehen, wird durch die Ereignisauswahl, Fallbildung und das gewählte Verfahren geprägt. Das Modell kann beobachtete Wege zusammenfassen und darüber hinaus Verhalten zulassen, das in den ausgewählten Daten noch nicht vorkam. Ein häufig beobachteter Weg kann fachlich unerwünscht sein, ein seltener Pfad eine notwendige Ausnahme.

Beispiel: Von beobachteten Folgen zu einem Modell

Ein fiktives, vereinfachtes Log enthält drei Folgen abgeschlossener Aktivitäten. Die Beobachtung beginnt jeweils nach der Herstellung:

• Prüfen → Qualitätsentscheidung → Freigeben
• Prüfen → Nacharbeiten → Prüfen → Qualitätsentscheidung → Freigeben
• Prüfen → Qualitätsentscheidung → Sperren

Die erste Modellierungsfrage betrifft den gemeinsamen Ablauf: In allen drei Folgen kommt eine Prüfung vor der Qualitätsentscheidung. Danach zeigen die Beobachtungen zwei unterschiedliche Enden. Ein Modell könnte diese als alternative Ausgänge darstellen. Die Folgen allein geben jedoch nicht an, welche fachliche Bedingung die Auswahl steuert.

Welches Modell ein Discovery-Verfahren tatsächlich erzeugt, hängt unter anderem von Verfahren, Parametern und Aufbereitung ab. Das Beispiel legt keinen bestimmten Algorithmus und damit auch kein garantiertes Ausgabemodell fest. Es zeigt, welche Strukturen erklärt werden sollen und wo eine Modellannahme über die Beobachtungen hinausgeht.

Ein veröffentlichtes Grundlagenbeispiel macht diesen Verdichtungsschritt messbar: Das Ereignislog L1 umfasst 16 Fälle und drei beobachtete Trace-Varianten. Zehn Fälle folgen ⟨a, b, c, e⟩, fünf ⟨a, c, b, e⟩ und ein Fall ⟨a, d, e⟩. Für einen Directly-Follows Graph werden daraus unter anderem die Häufigkeiten der unmittelbar auf a folgenden Aktivitäten gezählt.^[6]

Bei der Bildung von Prozessvarianten werden identische vollständige Aktivitätsfolgen zusammengefasst. Discovery leitet dagegen ein Modell ab, das die Struktur mehrerer beobachteter Folgen abbildet.

Eine Wiederholung beobachten, eine Schleife zulassen

Die zweite Folge kehrt nach der Nacharbeit zur Prüfung zurück. Ein Modell kann diesen einmal beobachteten Weg aufnehmen. Eine Schleife kann weitere Nacharbeitsrunden erlauben. Diese zusätzliche Möglichkeit stammt aus der Verallgemeinerung des Verfahrens, nicht aus weiteren beobachteten Runden.

Außerdem fehlt in der zweiten Folge vor der Nacharbeit eine gesonderte Qualitätsentscheidung. Das Log lässt offen, ob ein Ereignis fehlt, die Entscheidung unter „Prüfen“ mitgeführt wurde oder der Ablauf tatsächlich anders war. Aus den drei Folgen allein lässt sich das nicht auflösen. Die Ereignisbedeutung ist daher Teil der Prüfung der Datenbasis.

Bei wechselnden Reihenfolgen entsteht eine verwandte Frage: Wird eine Dokumentenprüfung einmal vor und einmal nach einer Materialbestätigung erfasst, kann ein Verfahren mögliche Parallelität modellieren. Ungenaue Zeitstempel oder unterschiedliche Ereignisbedeutungen wären andere Erklärungen.

Unterschiedliche Verfahren entdecken unterschiedliche Modelle

Für Process Discovery existiert nicht ein einziger universell richtiger Algorithmus. Verfahren unterscheiden sich darin, welche Beziehungen sie untersuchen, welche Modellnotation sie erzeugen, wie sie mit seltenem Verhalten umgehen und welche formalen Eigenschaften sie garantieren.

Der Alpha-Algorithmus gehört zu den grundlegenden frühen Verfahren. Er leitet aus direkt beobachteten Reihenfolgen Beziehungen wie Kausalität, Parallelität und Auswahl ab und konstruiert daraus ein Workflow-Netz. Die ursprüngliche Arbeit von van der Aalst, Weijters und Măruşter zeigt damit anschaulich das Grundproblem der automatischen Prozessentdeckung, benennt aber auch Einschränkungen bei kurzen Schleifen und bestimmten komplexen Strukturen.^[2]

Heuristische Ansätze berücksichtigen zusätzlich Häufigkeiten. Seltene Beziehungen können weniger stark gewichtet oder herausgefiltert werden. Das hilft bei verrauschten realen Logs, birgt jedoch die Gefahr, seltene, aber fachlich wichtige Ausnahmewege zu verlieren.

Inductive-Mining-Verfahren zerlegen das beobachtete Verhalten schrittweise in Strukturen wie Sequenz, Auswahl, Parallelität und Schleife. Leemans, Fahland und van der Aalst beschreiben einen konstruktiven Ansatz, der blockstrukturierte Modelle erzeugt und für das entdeckte Modell formale Soundness sowie Passung zum beobachteten Log sicherstellt.^[3]

Die Wahl des Verfahrens ist damit keine bloße Softwareeinstellung. Sie beeinflusst, welche Prozessstrukturen sichtbar werden, wie komplex das Ergebnis ausfällt und welches Verhalten das Modell zusätzlich zulässt.

Das Ergebnis kann verschiedene Modellformen annehmen

Ein Discovery-Ergebnis muss nicht zwingend ein vollständiges BPMN-Diagramm sein. Je nach Verfahren und Zweck kommen unterschiedliche Darstellungen infrage:

• Directly-Follows Graph: zeigt, welche Aktivität unmittelbar auf eine andere folgte und wie häufig diese Beziehung beobachtet wurde.
• Prozessbaum: bildet Abläufe hierarchisch mit Operatoren für Sequenz, Auswahl, Parallelität und Schleife ab.
• Petri-Netz oder Workflow-Netz: beschreibt das mögliche Ausführungsverhalten formal und kann Synchronisation oder Nebenläufigkeit ausdrücken.
• BPMN-Modell: übersetzt entdeckte Strukturen in eine für viele Fachanwender vertraute Prozessnotation.

Eine einfache Darstellung ist leichter lesbar, kann aber wichtige Bedingungen verbergen. Ein formal reiches Modell kann genauer analysierbar sein, zugleich aber die menschliche Interpretation erschweren. Deshalb muss die Modellform zur Frage passen: Soll ein erster Überblick entstehen, sollen Ausführungsvarianten erklärt oder soll später eine formale Verhaltensprüfung durchgeführt werden?

Ausgangspunkt ist ein fachlich verständliches Ereignislog

Ein Discovery-Verfahren verarbeitet keine reale Arbeit unmittelbar. Es verarbeitet Daten über diese Arbeit. Deshalb bilden fachlich klare Prozessereignisse den Ausgangspunkt des Ereignislogs und damit des Discovery-Ergebnisses.

Für eine klassische fallbezogene Analyse müssen Ereignisse mindestens einer Aktivität und einer Prozessinstanz zugeordnet sowie in eine Reihenfolge gebracht werden können. Zeitstempel, ausführende Rollen, Ergebnisse, Systeme und weitere Attribute erweitern die Auswertungsmöglichkeiten. Ein Prozessmodell lässt sich jedoch nur dann sinnvoll entdecken, wenn gleich benannte Ereignisse fachlich dasselbe bedeuten und der gewählte Fallbezug einen zusammenhängenden Ablauf repräsentiert.

Ein Beispiel zeigt das Problem: Werden alle Ereignisse eines Kalendertages als ein Fall zusammengefasst, vermischen sich mehrere Chargen. Wird jede einzelne Aufgabe als eigener Fall behandelt, zerfällt der übergreifende Chargenverlauf. In beiden Situationen kann ein Algorithmus formal ein Modell erzeugen. Das Modell beantwortet jedoch nicht die beabsichtigte Prozessfrage.

Auch Beginn und Abschluss einer Aktivität müssen konsistent interpretiert werden. Ein Ereignis „Prüfung“ kann den Start einer Kontrolle, das erfasste Ergebnis oder die abschließende Freigabe bezeichnen. Werden solche Lebenszykluszustände nicht unterschieden, entstehen scheinbare Reihenfolgen, die im realen Betrieb anders gemeint waren.

Die Modelle XES und OCEL können Ereignisdaten strukturiert repräsentieren. Sie entscheiden aber nicht automatisch, welche fachliche Granularität, Objektbeziehung oder Aktivitätssemantik für eine konkrete Discovery-Frage richtig ist.

Filter verändern, welche Wirklichkeit sichtbar wird

Reale Ereignislogs enthalten oft seltene Varianten, unvollständige Fälle, technische Wiederholungen oder Aktivitäten, die unabhängig vom eigentlichen Prozesszustand an vielen Stellen auftreten. Ohne Aufbereitung können daraus unübersichtliche Modelle entstehen.

Filter können Fälle auf einen Zeitraum begrenzen, unvollständige Ausführungen entfernen, Aktivitäten zusammenfassen oder seltene Beziehungen ausblenden. Jede dieser Maßnahmen verändert jedoch die Datengrundlage. Ein übersichtlicheres Modell kann zugleich weniger vollständige Information enthalten.

Tax, Sidorova und van der Aalst zeigen, dass sogenannte chaotische Aktivitäten die Präzision entdeckter Modelle deutlich beeinträchtigen können und dass ein bloßes Entfernen seltener Aktivitäten dieses Problem nicht zuverlässig löst.^[5] Häufigkeit und fachliche Relevanz sind nicht identisch.

In einem regulierten Prozess kann beispielsweise eine Abweichungsbearbeitung selten vorkommen, aber für die Beurteilung des Kontrollsystems wesentlich sein. Eine fachlich sinnvolle Filterstrategie sollte deshalb dokumentieren, welche Daten ausgeschlossen, zusammengefasst oder umbenannt wurden und welche Frage das resultierende Modell beantworten soll.

Gute Modelle balancieren mehrere Qualitätsziele

Ein entdecktes Modell kann nicht allein danach beurteilt werden, ob es das Ereignislog wiedergibt. Vier Qualitätsdimensionen stehen häufig in einem Spannungsverhältnis:

• Fitness: Wie viel des beobachteten Verhaltens kann das Modell wiedergeben?
• Precision: Wie stark begrenzt das Modell Verhalten, das im Log nicht beobachtet wurde?
• Generalization: Wie gut erfasst das Modell auch mögliches Verhalten desselben Prozesses, das im ausgewählten Log noch nicht vorkam?
• Simplicity: Wie verständlich und wenig komplex bleibt die Darstellung?

Ein Modell, das jede einzelne Trace als Sonderfall abbildet, kann eine hohe Fitness erreichen und dennoch unlesbar sein. Ein Modell, das jede beliebige Reihenfolge erlaubt, gibt zwar alle beobachteten Fälle wieder, ist aber kaum präzise. Ein extrem einfaches Modell kann die zentrale Prozesslogik verlieren.

Buijs und Kollegen beschreiben diese vier Dimensionen als miteinander konkurrierende Kriterien der Prozessentdeckung.^[4] Die angemessene Balance hängt vom Analysezweck ab. Für eine operative Diskussion kann Verständlichkeit wichtiger sein als maximale Detailtreue. Für eine formale Prüfung können andere Eigenschaften dominieren.

Auch bei Fitness und Precision hängt die Aussage eines Werts vom verwendeten Berechnungsverfahren ab. Qualitätskennzahlen ersetzen daher nicht die fachliche Beurteilung. Ein hoher numerischer Wert sagt nicht, ob Aktivitäten richtig benannt, relevante Ausnahmen erhalten oder die betrachteten Fälle repräsentativ ausgewählt wurden.

Eine einzige Fallnummer kann den Prozess verzerren

Klassische Discovery-Verfahren betrachten Ereignisse häufig entlang einer Case-ID. In realen Betriebsabläufen wirken jedoch mehrere Objekte zusammen: Eine Charge verwendet verschiedene Materialien, durchläuft Aufgaben und Prüfungen, beansprucht Geräte und kann sich in Zwischenprodukte aufteilen oder mit anderen Objekten zusammengeführt werden.

Wird eine dieser Perspektiven zur einzigen Fallachse gemacht, können Beziehungen verloren gehen oder Ereignisse künstlich vervielfacht werden. Die Analyse einer Charge zeigt möglicherweise ihren Hauptweg, verdeckt aber, dass ein Gerät gleichzeitig für mehrere Chargen eingesetzt wurde. Eine Materialperspektive zeigt Abstammung, aber nicht automatisch die vollständige Aufgabenfolge.

Object-Centric Process Mining erweitert diese Perspektive, indem Ereignisse mit mehreren Objekten verbunden bleiben. Auch hier muss ein Discovery-Verfahren entscheiden, welche Beziehungen und Modellstrukturen aus den objektzentrierten Daten abgeleitet werden. Das Problem verschwindet nicht; es wird fachlich angemessener beschrieben.

Das entdeckte Modell erhält zunächst einen analytischen Status

Das Ergebnis der Entdeckung wird zunächst als Modell des ausgewählten beobachteten Verhaltens behandelt. Eine Fachprüfung kann untersuchen, welche Alternativen, Wiederholungen und Vereinfachungen darin enthalten sind. Vorhandenes Prozesswissen hilft, diese Entscheidungen einzuordnen.

Soll anschließend die Übereinstimmung mit einer Vorgabe geprüft werden, vergleicht Conformance Checking das aufgezeichnete Verhalten mit einem dafür festgelegten Modell. Die Entdeckung selbst erteilt dem beobachteten Ablauf keine Freigabe.

Ursachen und Regelkonformität gesondert prüfen

Ein entdecktes Prozessmodell beschreibt Ablaufstrukturen; warum etwa eine Wartezeit oder Nacharbeit entsteht, muss anhand zusätzlicher Informationen untersucht werden.

Auch die Einhaltung verbindlicher Vorgaben ist damit nicht nachgewiesen: Dafür müssen die Abläufe gesondert an den geltenden Anforderungen gemessen werden.

Die offene Qualitätsentscheidung bleibt eine Frage an die Daten

Das Modell kann eine Schleife zeigen, obwohl nur eine Nacharbeitsrunde beobachtet wurde. Es kann aber nicht allein erklären, weshalb vor dieser Nacharbeit keine Qualitätsentscheidung aufgezeichnet ist. Wer das Ergebnis verwendet, muss beides unterscheiden können: die Verallgemeinerung des Verfahrens und die offene Frage an die Ereignisdaten. Deshalb gehören die gewählte Datenperspektive und die Verfahrenseinstellungen zum Modell, das weitergegeben wird.