Conformance Checking: Tatsächliche Abläufe mit Prozessmodellen vergleichen

Was Conformance Checking bedeutet

Conformance Checking beantwortet eine andere Frage als die automatische Process Discovery. Sie erzeugt aus Ereignisdaten ein Modell des beobachteten Verhaltens. Conformance Checking setzt dagegen bereits ein Vergleichsmodell voraus und prüft, wie sich aufgezeichnete Abläufe dazu verhalten. Das Process Mining Manifesto ordnet diesen Soll-Ist-Vergleich als eine der drei grundlegenden Arten des Process Mining ein – neben Discovery und Enhancement.^[1]

Der Begriff „Conformance“ darf dabei nicht vorschnell mit rechtlicher oder regulatorischer Compliance gleichgesetzt werden. Das Verfahren stellt zunächst eine technische Beziehung zwischen Ereignisdaten und Modell her. Ob eine erkannte Abweichung rechtlich relevant, fachlich zulässig, erwünscht oder lediglich Folge eines unvollständigen Modells ist, muss anschließend anhand des konkreten Zwecks beurteilt werden.

Conformance Checking kann einzelne Fälle untersuchen, Abweichungsmuster über viele Ausführungen erkennen und Kennzahlen für die Übereinstimmung berechnen. Sein besonderer Wert liegt darin, nicht nur einen Gesamtwert auszugeben, sondern Unterschiede bis zu konkreten Aktivitäten und Prozessstellen zurückzuführen.

Ein Freigabeereignis steht vor der erwarteten Prüfung

Ein fiktives Vergleichsmodell verlangt für Charge C-24 eine dokumentierte Prüfung vor der Freigabe. Im ausgewählten Log erscheint zunächst die Freigabe; das zugeordnete Prüfereignis folgt danach. Der Vergleich lokalisiert diesen Unterschied zwischen Ereignisfolge und Modell.

Drei Erklärungsrichtungen bleiben offen. Erstens könnte die Ausführung tatsächlich von der Vorgabe abgewichen sein. Zweitens könnte die Erfassung den Verlauf falsch darstellen, etwa durch einen unpassenden Zeitbezug oder einen fehlenden Import. Drittens könnte die Vergleichsgrundlage ungeeignet sein: eine andere Modellfassung, eine zu grobe Ereigniszuordnung oder eine für diesen Fall nicht geltende Vorgabe.

Die Diagnose muss deshalb zum konkreten Freigabeereignis, seinem Prüfbezug und der maßgeblichen Modellfassung zurückführen. Eine Korrektur des Mappings und eine Korrektur des betrieblichen Ablaufs wären unterschiedliche Maßnahmen. Der technische Befund entscheidet noch nicht, welche davon erforderlich ist.

Ereignislog und Prozessmodell sind zwei verschiedene Perspektiven

Für den Vergleich werden zwei eigenständige Beschreibungen benötigt. Das Ereignislog dokumentiert, was tatsächlich beobachtet wurde. Das Prozessmodell beschreibt, welches Verhalten als möglich, vorgesehen oder erwartet gilt.

Ein klassisches Ereignislog enthält geordnete Traces. Jeder Trace steht für einen Fall, beispielsweise eine Bestellung, einen Servicevorgang oder eine Produktionscharge. Die darin enthaltenen Prozessereignisse bezeichnen ausgeführte Aktivitäten und tragen häufig zusätzliche Angaben wie Zeitpunkte, Rollen, Ressourcen oder Ergebnisse. Ihre Bedeutung muss eindeutig sein, damit eine Beobachtung der richtigen Modellaktivität zugeordnet werden kann.

Das Vergleichsmodell kann in unterschiedlichen Notationen vorliegen. Häufig werden Petri-Netze, BPMN-Modelle, Prozessbäume oder deklarative Regeln verwendet. Entscheidend ist, dass das Modell ein auswertbares Verhalten beschreibt. Eine reine Prozessgrafik ohne eindeutige Semantik reicht für eine algorithmische Prüfung nicht aus.

Beide Seiten dürfen nicht miteinander verwechselt werden. Ein Ereignislog ist kein vollständiges Abbild aller möglichen Abläufe, sondern eine Sammlung beobachteter Ausführungen in einem bestimmten Zeitraum. Ein Modell ist keine neutrale Wahrheit, sondern eine zweckgebundene Beschreibung. Es kann normativ festlegen, wie gearbeitet werden soll, oder deskriptiv zusammenfassen, welches Verhalten als typisch angesehen wird.

Vor dem Vergleich müssen Ereignisse und Modell zusammenpassen

Ein Verfahren kann nur vergleichen, was fachlich zugeordnet wurde. Die Aktivität „Prüfung abgeschlossen“ im Ereignislog muss einem passenden Element des Prozessmodells entsprechen. Abweichende Bezeichnungen, verschiedene Granularitäten oder fehlende Ereignisse erschweren diese Zuordnung.

Ein Modell kann beispielsweise einen einzigen Schritt „Material prüfen“ enthalten, während das Ereignislog Probenahme, Messung, Vier-Augen-Prüfung und Freigabe getrennt aufzeichnet. Umgekehrt kann das Modell mehrere fachliche Prüfungen unterscheiden, obwohl das Quellsystem nur ein allgemeines Ereignis „Check completed“ liefert.

Vor dem Conformance Checking ist deshalb ein Mapping erforderlich. Es legt fest, welche Ereignisklassen welchen Modellaktivitäten entsprechen, welche Ereignisse für den Vergleich ignoriert werden dürfen und welche Lebenszyklusübergänge relevant sind. Auch Start- und Endbedingungen müssen eindeutig sein.

Standards strukturieren die Daten, lösen aber nicht automatisch ihre fachliche Zuordnung. XES und OCEL beschreiben unterschiedliche Modelle für Ereignislogs. Ob ein Ereignistyp und eine Modellaktivität dasselbe bedeuten, bleibt eine fachliche Vereinbarung.

Ein fehlerhaftes Mapping erzeugt scheinbare Abweichungen, obwohl Log und Modell denselben Sachverhalt nur unterschiedlich ausdrücken. Ebenso kann ein zu grobes Mapping echte Unterschiede verdecken. Die Vergleichsgrundlage muss daher dokumentiert, versioniert und für den konkreten Analysezweck geprüft werden.

Token-basiertes Replay spielt den Verlauf im Modell nach

Token-basiertes Replay ist ein frühes und anschauliches Verfahren des Conformance Checking. Es wird insbesondere auf Petri-Netzen angewendet. Der beobachtete Trace wird Ereignis für Ereignis im Modell abgespielt. Für jede Aktivität wird geprüft, ob die zugehörige Transition im aktuellen Modellzustand ausführbar ist.

Kann eine beobachtete Aktivität nur ausgeführt werden, wenn im Modell ein benötigtes Token fehlt, wird dieses Defizit erfasst. Nach dem vollständigen Replay wird die erreichte Markierung mit der vorgesehenen Endmarkierung verglichen. Die dort erwarteten Tokens sind kein Fehler; gezählt werden fehlende und überschüssig verbleibende Tokens. Produzierte, konsumierte, fehlende und verbleibende Tokens können zu einer Fitness-Kennzahl zusammengeführt werden.

Rozinat und van der Aalst entwickelten diesen Ansatz, um reale Prozessausführungen mit Modellen zu vergleichen und Abweichungen auf Modellebene sichtbar zu machen.^[2] Das Verfahren ist verständlich und vergleichsweise effizient, hängt aber von der Modellnotation und der lokalen Behandlung einer Abweichung ab.

Wenn beim Replay ein Fehler auftritt, muss das Verfahren den Verlauf künstlich fortsetzen können. Eine lokale Reparatur kann dazu führen, dass später erkannte Unterschiede von der gewählten Zwischenkorrektur abhängen. Token-basiertes Replay liefert daher nicht in jedem Fall die global beste Erklärung für die Abweichung zwischen Trace und Modell.

Alignments suchen die passendste Modell-Ausführung

Alignment-basierte Verfahren betrachten Ereignisfolge und Modellverhalten gemeinsam. Ziel ist, den beobachteten Trace mit einer zulässigen Ausführung des Modells auszurichten. Für jeden Schritt wird unterschieden, ob Log und Modell übereinstimmen oder ob eine Bewegung nur auf einer Seite erforderlich ist.

Ein synchroner Schritt bedeutet: Das beobachtete Ereignis passt zur nächsten ausführbaren Modellaktivität. Eine Bewegung nur im Log zeigt, dass ein Ereignis beobachtet wurde, für das an dieser Stelle keine entsprechende Modellaktivität ausgeführt wird. Eine Bewegung nur im Modell zeigt, dass ein Modellschritt ohne entsprechendes Logereignis ausgeführt wird. Bei einer sichtbaren Aktivität kann das auf eine fehlende Beobachtung hindeuten. Stille Modellschritte haben dagegen absichtlich kein zugehöriges Logereignis und sind nicht schon deshalb eine Abweichung.

Den unterschiedlichen Bewegungen können Kosten zugeordnet werden. Das Verfahren sucht dann eine zulässige Ausrichtung mit möglichst geringen Gesamtkosten. Van der Aalst, Adriansyah und van Dongen zeigen, wie eine solche Beziehung zwischen Ereignissen und Modellelementen zur Konformitäts- und Leistungsanalyse genutzt werden kann.^[3]

Ein optimales Alignment ist nicht automatisch die einzig richtige fachliche Erklärung. Verschiedene Ausrichtungen können dieselben Kosten besitzen. Die gewählten Kosten drücken außerdem aus, welche Abweichungen als schwerer oder leichter gelten. Werden alle übersprungenen Aktivitäten gleich gewichtet, kann das fachliche Bedeutung stark vereinfachen.

Den Befund bis zur prüfbaren Stelle zurückführen

Für C-24 ist die Fundstelle genauer als die Aussage „schlechte Konformität“: Welches Freigabeereignis wurde welchem Modellelement zugeordnet, und welcher erwartete Schritt fehlt an dieser Stelle? Replay oder Alignment liefern dafür einen technischen Bezug.

Die anschließende Untersuchung hält Befund und Erklärung auseinander. Sie dokumentiert die verwendete Zuordnung, die betroffenen Originalereignisse und die noch zu prüfenden Annahmen. Werden mehrere gleich günstige Alignments gefunden, ist auch diese Mehrdeutigkeit relevant. Eine rechnerisch optimale Ausrichtung bestimmt nicht allein die tatsächliche Fehlerursache.

Zwei Kennzahlen ergänzen die lokale Diagnose

Fitness und Precision bewerten unterschiedliche Eigenschaften des Vergleichs: Fitness betrachtet, wie gut das Modell die aufgezeichneten Verläufe wiedergeben kann. Precision betrachtet, wie stark zusätzlich erlaubtes, im betrachteten Log nicht beobachtetes Verhalten begrenzt wird. Werte sind nur unter Berücksichtigung der jeweiligen Berechnung sinnvoll vergleichbar.

Ein Gesamtwert ersetzt den lokalisierten Befund im Freigabefall nicht. Er hängt unter anderem von Verfahren, Parametern und Datenauswahl ab; die Forschung unterscheidet zahlreiche Maße mit unterschiedlichen Eigenschaften.[4]

Der Zweck des Modells verändert die Aussage

Bei einem normativen Modell beschreibt die Abweichung einen Unterschied zu einem vorgesehenen Verhalten. Das kann einen Prüfbedarf auslösen. Ob tatsächlich ein Verstoß vorliegt, hängt jedoch davon ab, ob das Modell die maßgebliche Vorgabe korrekt und vollständig abbildet und auf den konkreten Fall anwendbar ist.

Bei einem deskriptiven Modell bedeutet eine Abweichung zunächst nur, dass der Fall nicht dem modellierten Normal- oder Referenzverhalten entspricht. Der ungewöhnliche Verlauf kann fehlerhaft, selten, innovativ oder durch eine legitime Ausnahme bedingt sein.

Auch entdeckte Modelle können für Conformance Checking verwendet werden, etwa um unterschiedliche Zeiträume oder Standorte zu vergleichen. Dann muss deutlich bleiben, dass der Referenzprozess aus historischen Daten abgeleitet wurde. Häufiges Verhalten ist nicht automatisch richtig; seltenes Verhalten ist nicht automatisch falsch.

Vor jeder Analyse sollte deshalb schriftlich feststehen, was das Modell repräsentiert: eine freigegebene Arbeitsweise, einen technischen Kontrollfluss, einen historischen Referenzzustand oder eine analytische Hypothese. Ohne diesen Zweck ist die Bedeutung eines Abweichungswerts offen.

Datenqualität begrenzt die Aussagekraft

Conformance Checking bewertet nur das beobachtbare Verhalten. Nicht protokollierte Arbeitsschritte bleiben unsichtbar. Doppelte Ereignisse, falsche Zeitstempel, wechselnde Fallkennungen oder unklare Aktivitätsnamen können den rekonstruierten Verlauf verändern.

Auch die Fallbildung ist entscheidend. Wird ein komplexer Ablauf ausschließlich über eine Auftragsnummer betrachtet, können gemeinsam genutzte Materialien, Geräte oder Prüfungen mehreren Fällen zugeordnet sein. Eine erzwungene Einzelperspektive kann dann Reihenfolgen erzeugen, die in der realen Arbeit so nicht bestanden.

Vor der Analyse sollten deshalb mindestens Vollständigkeit, Eindeutigkeit, Zeitordnung, Aktivitätssemantik und Objektbezug geprüft werden. Filter und Ausschlüsse müssen reproduzierbar sein. Ein bereinigtes Log darf nicht so stark auf das Modell zugeschnitten werden, dass relevante Abweichungen bereits vor dem Vergleich verschwinden.

Der technische Export ist ebenfalls Teil der Aussage. Wenn ein Quellsystem nur erfolgreiche Abschlüsse ausgibt, können abgebrochene oder zurückgewiesene Schritte nicht untersucht werden. Eine hohe Fitness würde dann eher die Auswahl der Daten als den tatsächlichen Prozess beschreiben.

Ein lokalisierter Unterschied wird zur konkreten Prüffrage

Im Freigabefall ist der nächste Schritt keine pauschale Bewertung der gesamten Charge. Zuerst muss geklärt werden, weshalb das zugeordnete Prüfereignis im Vergleich zu spät erscheint. Der Befund liefert dafür eine bestimmte Stelle in Log und Modell.

Damit hat Conformance Checking einen klaren Nutzen: Es grenzt ein, was untersucht werden muss. Die dokumentierte Erklärung entscheidet anschließend, ob Daten, Vergleichsgrundlage oder Ausführung zu korrigieren sind.

Conformance Checking bewertet nicht automatisch die Datenrichtigkeit. Ein formal passendes Ereignis kann inhaltlich falsch sein.