Object-Centric Process Mining: Prozesse über mehrere Objekte analysieren

Was ist Object-Centric Process Mining?

Klassische Process-Mining-Verfahren gruppieren Ereignisse üblicherweise über eine ausgewählte Fall-ID, beispielsweise eine Bestell- oder Chargennummer.

Diese Sicht ist geeignet, wenn die gewählte Fallperspektive die konkrete Analysefrage ausreichend abbildet. Betriebliche Informationssysteme enthalten jedoch häufig mehrere miteinander verflochtene Objekte. Eine Bestellung umfasst mehrere Positionen, eine Rechnung kann mehrere Bestellungen betreffen und eine Lieferung kann Positionen unterschiedlicher Bestellungen zusammenfassen. Berti und van der Aalst zeigen deshalb, dass ein Ereignis nicht zwingend zu genau einem Fall gehören muss, sondern mit mehreren Objekten verschiedener Typen verbunden sein kann.^[1]

OCPM bewahrt diese objektübergreifenden Beziehungen für die Analyse. Statt zuerst eine einzige Fallperspektive festzulegen, werden Ereignisse, Objekte und ihre Verbindungen gemeinsam betrachtet. Dadurch lassen sich umfassende Modelle entdecken und bei Bedarf einzelne Objektsichten herauslösen.^[1]

Prüfwartezeiten über verbundene Lose untersuchen

Ein fiktiver Produktionsverlauf führt von einer Ernte über Verarbeitung und Trocknung zu mehreren Inventarlosen. Proben und Prüfergebnisse werden diesen Losen mit ihrem konkreten Bezug zugeordnet. Die Analysefrage lautet: Wie verteilt sich die Zeit zwischen Probenentnahme, verfügbarem Ergebnis und anschließender Freigabe auf die betroffenen Lose?

Dafür werden zunächst die Zeitpunkte und ihre Bedeutung festgelegt. „Ergebnis vorhanden“ kann die technische Bereitstellung oder die fachlich abgeschlossene Bewertung meinen. Für jedes Los muss erkennbar sein, welche Ergebnisse erforderlich waren. Gemeinsam genutzte Prüfobjekte verbinden dabei mehrere Lebenszyklen.

Die Auswertung unterscheidet die Wartezeit bis zum erforderlichen Ergebnis von der Zeit bis zur anschließenden Entscheidung. Ein gemeinsames Ergebnis darf bei einer Zählung durchgeführter Prüfungen nicht mehrfach als neue Prüfung erscheinen. Bei einer Betrachtung betroffener Lose kann dieselbe Wartephase dagegen mehrere Lose betreffen; diese Bezugsgröße ist ausdrücklich anzugeben.

Ohne Messdaten lässt sich daraus weder eine Dauer noch eine Engpassursache ableiten. Das Beispiel beschreibt eine Untersuchungsanordnung. Erst die bereinigten Ereignisse, dokumentierten Beziehungen und festgelegten Rechenregeln ermöglichen ein Ergebnis.

Objekte besitzen eigene Lebenszyklen

Objekte sind nicht lediglich zusätzliche Attribute eines Ereignisses. Jedes Objekt besitzt seinen eigenen Lebenszyklus. Eine Charge wird angelegt, bearbeitet, geprüft, gesperrt und freigegeben. Ein Gerät wird in Betrieb genommen, verwendet, gereinigt, geprüft und gewartet. Eine Probe wird entnommen, transportiert, analysiert und einem Ergebnis zugeordnet.

Diese Lebenszyklen laufen nicht unabhängig nebeneinander. Eine Geräteprüfung kann mehrere Produktionsvorgänge betreffen. Ein Analyseergebnis kann die Freigabe einer Charge beeinflussen. Eine Materialcharge wird über mehrere Aufgaben und Produkte hinweg verbraucht. OCPM untersucht deshalb nicht nur die Reihenfolge von Aktivitäten innerhalb eines einzelnen Falls, sondern auch die Synchronisation zwischen Objekten verschiedener Typen.

Der Lebenszyklus eines Objekts kann als eigene Sicht betrachtet werden, ohne die Beziehungen zu anderen Objekten zu verlieren. So lässt sich beispielsweise der Weg einer Laborprobe untersuchen und anschließend zurückverfolgen, welche Charge, Entnahmeaufgabe, Person und Freigabeentscheidung mit ihr verbunden waren.

Wann eine einzige Fall-ID Zusammenhänge verdeckt

Die Fall-ID entscheidet im klassischen Event Log darüber, welche Ereignisse zu derselben Prozessinstanz gehören. Wird die Bestellung als Fall gewählt, erscheinen alle Ereignisse mit derselben Bestellnummer in einer gemeinsamen Ablaufspur. Das klingt eindeutig, kann aber Beziehungen zu Rechnungen, Sendungen oder einzelnen Positionen verzerren.

Ein einfaches Beispiel:

• Auftrag A enthält die Positionen P1 und P2.
• Auftrag B enthält die Position P3.
• P1 und P3 werden gemeinsam in Sendung S1 transportiert.
• P2 folgt später in Sendung S2.
• Eine Rechnung R1 umfasst P1 und P2.

Wird die Auftragsnummer als einzige Fall-ID verwendet, muss das Versandereignis von S1 sowohl Auftrag A als auch Auftrag B zugeordnet werden. Das Ereignis wird möglicherweise dupliziert. Wird stattdessen die Sendung als Fall gewählt, verschwinden Ereignisse, die nur den Auftrag oder die Rechnung betreffen. Jede Perspektive zeigt einen Ausschnitt, aber keine erhält das vollständige Beziehungsnetz.

Die wissenschaftliche Literatur beschreibt dieses Problem als Folge mehrerer miteinander verflochtener Fallbegriffe. Reale Systeme wie ERP- und CRM-Anwendungen speichern ihre Daten in verbundenen Tabellen und Objekten; die Reduktion auf einen einzigen Fall erfordert eine vorgelagerte Transformation.^[1][2]

Was beim Flattening verloren geht

Um objektbezogene Daten mit klassischen Verfahren zu analysieren, werden sie häufig „geflattet“. Dafür wird ein Objekttyp als Fallbegriff ausgewählt. Ereignisse ohne Objekt dieses Typs werden entfernt; Ereignisse mit mehreren Objekten dieses Typs werden für jedes Objekt vervielfältigt.^[1]

Dabei entstehen drei typische Probleme:

Die gemeinsame Beteiligung muss erhalten bleiben

Die Prozessereignisse einer Prüfung können sowohl die Probe als auch die betroffenen Lose verbinden. Für eine Wartezeitanalyse ist entscheidend, welche Lose auf welches Ergebnis angewiesen waren. Eine bloße Liste aller im Zeitraum vorkommenden Objekte würde diese Beziehung nicht ausdrücken.

XES und OCEL strukturieren Ereignisdaten für den Austausch unterschiedlich. In der objektzentrierten Analyse müssen zusätzlich die Rollen der Beziehungen berücksichtigt werden: Herkunft einer Probe, Bezug eines Ergebnisses und Gegenstand einer Freigabe sind unterschiedliche Verbindungen.

Das veröffentlichte SEFM-Beispiel zeigt die Convergence-Verzerrung direkt: Das Ereignis 9913 (place order) gehört zu Auftrag o2 und gleichzeitig zu den drei Items i3, i4 und i5. Wird item als Fallbegriff gewählt, muss dasselbe reale Ereignis drei Item-Fällen zugeordnet werden.^[5]

Genau darin liegt die analytische Verzerrung: Drei Einträge in der geflatteten Sicht dürfen nicht als drei reale Bestellereignisse interpretiert werden. Die ursprüngliche Ereignisidentität und ihre Beziehungen zu mehreren Objekten müssen erhalten bleiben.

Beziehungen zwischen Objekten

Nicht jede fachliche Beziehung entsteht erst durch ein gemeinsames Ereignis. Eine Teilcharge gehört zu einer Produktionscharge, ein Gerät befindet sich in einem Raum und eine SOP-Version ersetzt eine frühere Version. OCEL 2.0 kann deshalb auch qualifizierte Object-to-Object-Beziehungen abbilden.^[3]

Für die Analyse ist diese Ebene wichtig. Wenn eine Abweichung an einem Gerät festgestellt wird, kann die Frage lauten, welche Chargen während eines bestimmten Zeitraums mit diesem Gerät bearbeitet wurden. Dafür müssen Geräte-, Aufgaben- und Chargenbeziehungen zusammengeführt werden. Eine einzelne Fallspur liefert diesen Zusammenhang nicht automatisch.

Gleichzeitig sind Objektbeziehungen zeitabhängig. Ein Gerät kann den Raum wechseln, eine Person übernimmt eine andere Rolle und eine Materialcharge wird aufgeteilt. Ein objektzentriertes Modell muss deshalb erkennen lassen, wann eine Beziehung oder ein Attribut galt. Sonst können heutige Zuordnungen fälschlich auf frühere Vorgänge übertragen werden. OCEL 2.0 sieht Zeitangaben für Änderungen von Objektattributen vor. Eine Object-to-Object-Beziehung besteht dagegen aus zwei Objektkennungen und einem Qualifier, ohne eigenes Gültigkeitsintervall. Soll beispielsweise ein Raumwechsel ausgewertet werden, muss seine zeitliche Bedeutung zusätzlich modelliert werden, etwa durch ein Wechselereignis mit den beteiligten Objekten.

Von mehreren Sichten zu einem Gesamtmodell

OCPM bedeutet nicht, sämtliche Daten in einem unlesbaren Gesamtbild zu zeigen. Objektzentrierte Modelle können mehrere Objekttypen gemeinsam repräsentieren und dennoch nach einer bestimmten Perspektive gefiltert oder vereinfacht werden. Berti und van der Aalst beschreiben objektzentrierte Petri-Netze, deren Stellen Objekttypen entsprechen und deren Transitionen Objekte verschiedener Typen verbrauchen oder erzeugen können.^[1]

Für Anwender ist weniger die konkrete Petri-Netz-Notation entscheidend als das Prinzip: Die Analyse beginnt mit einem zusammenhängenden Objektmodell. Erst für eine konkrete Frage wird eine Sicht gewählt. Dadurch ist nachvollziehbar, welche Beziehungen ausgeblendet wurden und welche im Ergebnis enthalten bleiben.

Ein klassisches Modell beginnt dagegen häufig bereits mit der Entscheidung für einen einzigen Falltyp. Andere Zusammenhänge müssen anschließend durch zusätzliche Attribute, Zusammenführungen oder getrennte Analysen rekonstruiert werden.

Welche Fragen objektzentrierte Analysen ermöglichen

Eine objektzentrierte Datenbasis erweitert die möglichen Prozessfragen. Beispielsweise lässt sich untersuchen:

• welche Materialchargen in welchen Produkten verwendet wurden,
• welche Aufgaben gleichzeitig mehrere Chargen oder Geräte betrafen,
• wie oft eine Probe zwischen Entnahme und Ergebnis den Verantwortungsbereich wechselte,
• welche Geräteereignisse zeitlich mit späteren Abweichungen zusammenfallen,
• ob Freigaben auf alle erforderlichen Teilobjekte warteten,
• wie Aufteilungen, Zusammenführungen und Weiterverarbeitungen abliefen,
• welche Varianten nur in bestimmten Kombinationen von Material, Anlage und Rolle auftreten.

Diese Fragen verbinden Verhalten und Struktur. Es geht nicht nur darum, welche Aktivität auf eine andere folgte. Entscheidend ist auch, welche Objekte an diesem Übergang beteiligt waren und wie sich ihre Lebenszyklen gegenseitig beeinflussten.

Soll-Modell und objektzentrierte Ausführung

Ein Workflow-Modell beschreibt, welche Aufgaben, Entscheidungen und Übergänge vorgesehen sind. Objektzentrierte Ereignisdaten zeigen dagegen, welche konkreten Objekte an der Ausführung beteiligt waren.

Diese Ebenen ergänzen sich. Das Workflow-Modell kann verlangen, dass vor einer Freigabe eine Probe vorliegt. OCPM kann sichtbar machen, ob die Entscheidung tatsächlich mit der richtigen Probe und dem betroffenen Inventory-Lot verbunden war, ob mehrere Lose auf dasselbe Ergebnis bezogen wurden oder ob sich Wartezeiten an bestimmten Objektübergaben häufen.

Die bloße Verbindung eines Ereignisses mit mehreren Objekten beweist allerdings noch keine Konformität. Dafür müssen die erwarteten Beziehungen, Kardinalitäten und Reihenfolgen fachlich definiert und anschließend mit der beobachteten Ausführung verglichen werden.

Prozessbeziehungen machen dabei ausdrücklich sichtbar, welche Rolle Ereignisse und Objekte innerhalb des gemeinsamen Ablaufs einnehmen.

Grenzen objektzentrierter Analysen

• Mehr Beziehungen bedeuten nicht automatisch bessere Daten. Falsch verknüpfte Objekte erzeugen ein plausibles, aber unzutreffendes Prozessbild.
• Ein objektzentriertes Log beweist keine Vollständigkeit. Fehlende Ereignisse oder Beziehungen bleiben auch in einem ausdrucksstärkeren Modell fehlend.
• Korrelation ist keine Kausalität. Gemeinsame Objekte und zeitliche Nähe belegen nicht allein, dass ein Ereignis ein anderes verursacht hat.
• OCPM ist kein regulatorischer Konformitätsnachweis. Analysen können Abweichungen und Zusammenhänge sichtbar machen; ihre rechtliche und fachliche Bewertung bleibt erforderlich.

Die Bezugsgröße entscheidet über das Ergebnis

Eine Prüfung kann mehrere Lose betreffen. Daraus entstehen unterschiedliche Fragen: Wie viele Prüfungen fanden statt, wie viele Lose warteten und an welchem Übergang entstand die Wartezeit? OCPM hilft, diese Fragen auf einer verbundenen Datenbasis zu untersuchen.

Der Nutzen liegt in der nachvollziehbaren Auswahl und Auswertung dieser Beziehungen. Das Modell muss erkennen lassen, welche Objekte, Ereignisse und Zeitbezüge berücksichtigt wurden. Erst dann lässt sich ein auffälliger Übergang gezielt fachlich untersuchen, ohne aus gemeinsamer Beteiligung bereits eine Ursache abzuleiten.