Prozessereignisse: Wie reale Arbeit zu auswertbaren Ereignisdaten wird

Was ist ein Prozessereignis?

Das Process Mining Manifesto beschreibt Ereignislogs als Ausgangspunkt des Process Mining. Im klassischen Grundmodell bezieht sich jedes Ereignis auf eine Aktivität und eine bestimmte Prozessinstanz; die Ereignisse werden geordnet und können zusätzliche Angaben wie Zeitstempel oder ausführende Ressourcen enthalten.^[1]

Ein Ereignis ist damit mehr als eine technische Logzeile. Damit es betrieblich verstanden und später ausgewertet werden kann, muss klar sein, welches reale Geschehen es repräsentiert. Die Zeichenfolge task.completed besitzt allein nur geringe Aussagekraft. Erst durch die Verbindung mit einer konkreten Aufgabe, einer Charge, einem Zeitpunkt, einem Ergebnis und der verantwortlichen Rolle wird daraus verwendbare Prozessinformation.

Ein Verbrauchsereignis mit eindeutigem Auslöser

In einem fiktiven Vorgang bestätigt eine Person den Verbrauch von 2,4 Kilogramm aus Materialcharge M-04 innerhalb der Aufgabe A-17 für Produktcharge C-24. Das Ereignis E-208 dokumentiert diese Bestätigung. Ein allgemeiner Klick auf „Aufgabe erledigt“ reicht nicht, um dieselbe Menge zu behaupten.

Solche Ereignisse können Bausteine eines Electronic Batch Record sein. Der EBR ist jedoch der vollständige chargenbezogene Record und nicht das einzelne Ereignis.

Diese Aufzeichnung erklärt, was bestätigt wurde und in welchem Zusammenhang. Sie ist kein unabhängiger Beweis dafür, dass genau diese Menge physisch verbraucht wurde. Die Erfassungsweise und gegebenenfalls zugehörige Belege bleiben für die Bewertung relevant.

Semantik entscheidet über den späteren Wert

Struktur allein erzeugt noch keine eindeutige Bedeutung. Wenn ein System Aufgabe abgeschlossen protokolliert, kann damit gemeint sein, dass die Person den letzten Schritt bestätigt hat. Es kann aber auch bedeuten, dass ein fachliches Ergebnis erzeugt, eine Prüfung bestanden oder ein Folgeprozess ausgelöst wurde. Für Menschen mögen solche Unterschiede aus der Benutzeroberfläche hervorgehen; in Ereignisdaten müssen sie ausdrücklich modelliert sein.

Das Process Mining Manifesto fordert, Ereignisdaten als eigenständige, hochwertige Grundlage zu behandeln. Es betont unter anderem, dass Ereignisse klar definierte Semantik besitzen und auf einem angemessenen Abstraktionsniveau vorliegen sollen.^[1]

Praktisch bedeutet das:

• Ereignistypen besitzen eine dokumentierte Bedeutung,
• gleiche Bezeichnungen stehen für vergleichbare Handlungen,
• Einheiten und Wertebereiche sind eindeutig,
• Statuswechsel lassen Ausgangs- und Zielzustand erkennen,
• beteiligte Objekte werden in ihrer jeweiligen Rolle verbunden und
• technische Systemmeldungen werden nicht ungeprüft als fachliche Ereignisse ausgegeben.

Eine semantisch saubere Ereignisstruktur ist nicht nur für Analysewerkzeuge wichtig. Sie verbessert auch die Verständlichkeit zwischen Betrieb, Qualitätssicherung, Entwicklung und späteren Prüfern.

Bekannten Kontext übernehmen, die Handlung bestätigen

Die Aufgabe A-17 kann ihren Produktbezug und die anzuwendende Arbeitsanweisung bereits kennen. Solche Angaben müssen nicht bei jeder Verbrauchserfassung neu eingetippt werden. Die Erfassung sollte jedoch erkennen lassen, welche Zuordnung übernommen und welche Angabe ausdrücklich bestätigt wurde.

Wird eine Materialcharge nur vorgeschlagen, ist sie noch nicht als tatsächlich verwendet bestätigt. Ebenso ist eine geplante Menge kein gemessener Verbrauch. Die Ereignisgestaltung muss diese Unterschiede bewahren, damit aus einer bequem vorbefüllten Maske keine unzutreffende Tatsachenbehauptung entsteht.

Welche Angaben ein Prozessereignis benötigt

Die konkrete Struktur hängt vom Anwendungsfall ab. Einige Elemente sind jedoch regelmäßig erforderlich, damit ein Ereignis nicht isoliert bleibt.

Die richtige Granularität

OCEL 2.0 beschreibt Ereignisse als diskrete, atomare Handlungen oder Beobachtungen zu einem bestimmten Zeitpunkt.^[3] Atomar bedeutet hier nicht, dass ein Ereignis jede kleinste technische Operation abbilden muss. Es soll eine fachlich sinnvolle Einheit repräsentieren, die für den vorgesehenen Zweck nicht weiter zerlegt werden muss.

Ist die Granularität zu grob, verschwinden relevante Unterschiede. Ein einziges Ereignis Produktion abgeschlossen zeigt nicht, welche Materialien eingesetzt, welche Prüfungen durchgeführt oder welche Nacharbeiten erforderlich wurden. Ist sie zu fein, entsteht dagegen eine Flut technischer Meldungen, aus der sich der betriebliche Zusammenhang nur schwer rekonstruieren lässt.

Die passende Ebene richtet sich daher nach der Frage, die später beantwortet werden soll. Für einen Chargenprozess können eigenständige Ereignisse beispielsweise sinnvoll sein für:

• Beginn und Ende einer ausgeführten Aufgabe,
• Verwendung einer bestimmten Materialcharge,
• Erfassung eines entscheidungsrelevanten Messwerts,
• Auftreten und Klassifizierung einer Abweichung,
• Anforderung und Abschluss einer Nacharbeit,
• Prüfung eines Ergebnisses sowie
• Erteilung, Einschränkung oder Verweigerung einer Freigabe.

Einzelne Klicks, Seitenaufrufe oder rein visuelle Änderungen müssen dagegen nicht automatisch fachliche Prozessereignisse sein.

Eine spätere Prüfung ist ein weiteres Ereignis

Wird E-208 später geprüft, bezieht sich die Prüfentscheidung auf die konkrete Verbrauchsaufzeichnung. Sie darf nicht so erscheinen, als hätte sie schon bei der Erfassung vorgelegen. Eine Beanstandung oder erforderliche Berichtigung erhält ebenfalls einen eigenen Bezug.

Damit bleiben Ausführung und Bewertung unterscheidbar. Die spätere Reihenfolge allein genügt zur Zuordnung nicht: Eine prüfende Person kann mehrere Aufzeichnungen bearbeiten, und ihre Entscheidung muss den tatsächlich betroffenen Gegenstand benennen.

Reihenfolge ist mehr als Sortierung nach Uhrzeit

Prozesse entstehen aus Abfolgen und Abhängigkeiten. Ein Zeitstempel ermöglicht die zeitliche Sortierung, bildet aber nicht jede fachliche Beziehung vollständig ab. Zwei Handlungen können parallel stattfinden. Eine spätere Korrektur kann sich ausdrücklich auf ein früheres Ergebnis beziehen. Ein Prüfereignis kann eine bestimmte Ausführung bestätigen, ohne unmittelbar nach ihr gespeichert worden zu sein.

Deshalb können zusätzlich zu Zeitangaben direkte Beziehungen erforderlich sein:

• dieses Ereignis korrigiert ein früheres Ereignis,
• diese Prüfung bezieht sich auf diese Ausführung,
• dieser Materialverbrauch erfolgte innerhalb dieser Aufgabe,
• diese Freigabe gilt für diesen Produktzustand,
• diese Nacharbeit wurde durch diese Beanstandung ausgelöst.

Solche Beziehungen schützen den Prozesskontext davor, auf eine bloße chronologische Liste reduziert zu werden. Die zeitliche Ordnung bleibt wichtig, wird aber durch fachliche Verknüpfungen ergänzt.

Ereignis, Zustand und Datensatz sind nicht dasselbe

Ein Zustand beschreibt, wie etwas zu einem bestimmten Zeitpunkt beschaffen ist: Eine Charge ist gesperrt, ein Materialbestand beträgt 18 Kilogramm oder eine Aufgabe wartet auf Prüfung. Ein Ereignis beschreibt dagegen, was zu diesem Zustand beigetragen hat: Die Charge wurde nach einer Abweichung gesperrt, vier Kilogramm Material wurden verbraucht oder eine Ausführung wurde zur Nacharbeit zurückgegeben.

Auch ein gewöhnlicher Datensatz ist nicht automatisch ein Prozessereignis. Eine Stammdatenzeile kann etwa den Namen eines Geräts oder die aktuelle Bezeichnung eines Produkts enthalten, ohne eine konkrete Handlung abzubilden. Umgekehrt kann ein Ereignis auf solche Datensätze verweisen und ihre Bedeutung in einem Ablauf sichtbar machen.

Die Unterscheidung ist wichtig:

Aus Ereignissen können Zustände abgeleitet oder erklärt werden. Das Architekturprinzip Event Sourcing nutzt eine solche geordnete Ereignisfolge, um den Zustand eines Systems zu bilden. Dafür müssen die Ereignisse inhaltlich eindeutig, richtig verknüpft und in einer belastbaren Reihenfolge vorliegen.

Datenqualität beginnt vor der Analyse

Ein Analyseverfahren kann nur mit dem arbeiten, was in den Ereignisdaten enthalten ist. Fehlende Ereignisse, wechselnde Bedeutungen, unzuverlässige Zeitstempel oder falsch verknüpfte Objekte führen nicht nur zu einem technischen Qualitätsproblem. Sie verändern das Bild des tatsächlichen Ablaufs.

Das Manifesto nennt Vertrauenswürdigkeit, Vollständigkeit und klar definierte Semantik als zentrale Qualitätsanforderungen an Ereignisdaten.^[1] Der XES-Kontext unterstreicht zudem, dass standardisierte Ereignisdaten transportiert, gespeichert und zwischen Werkzeugen ausgetauscht werden können sollen.^[2]

Die Qualität eines einzelnen Ereignisses ist dabei Teil einer größeren Frage. Datenintegrität verlangt, dass Daten über ihren Lebenszyklus vollständig, konsistent, genau und verlässlich bleiben. Für Ereignisdaten betrifft das unter anderem ihre Erzeugung, Korrektur, Übertragung, Aufbewahrung und spätere Auswertbarkeit.

Auch die Herkunft des Datums ist eigenständig zu betrachten. Data Provenance macht nachvollziehbar, aus welcher Beobachtung, Eingabe oder Verarbeitung eine Information entstanden ist und welche Akteure oder Vorgänge beteiligt waren. Ein Ereignis kann solche Beziehungen tragen, ersetzt aber kein vollständiges Provenance-Modell.

Wer den ersten Digitalisierungsfall in der Produktion auswählt, muss deshalb zunächst die Datenlage klären: Welche benötigten Informationen liegen bereits vor, welche sind unklar zugeordnet und welche müssten erst erhoben werden?

Von der Ereignisbedeutung zur Analysefrage

Process Mining kann Ereignisdaten zur Untersuchung von Abläufen verwenden.[1][2] Im Verbrauchsbeispiel hängt die Aussage einer Zeitmessung davon ab, ob E-208 den physischen Verbrauch oder dessen spätere Bestätigung datiert. Derselbe Zeitabstand würde sonst unterschiedlich interpretiert.

Conformance Checking vergleicht aufgezeichnetes Verhalten mit einem Modell. Auch dafür muss der Ereignistyp zur verglichenen Handlung passen: Eine erfasste Mengenbestätigung ist nicht ohne Weiteres mit einem beliebigen Aufgabenabschluss gleichzusetzen.

Was Prozessereignisse nicht beweisen

• Ein gespeichertes Ereignis beweist nicht automatisch sachliche Richtigkeit. Eine falsche Eingabe kann korrekt protokolliert und dennoch falsch sein.
• Prozessereignisse sind nicht mit einem Audit Trail gleichzusetzen. Anforderungen, Umfang und Zweck eines Audit Trails hängen vom konkreten System- und Regelungskontext ab.
• Analyse erzeugt keine automatische Compliance-Bewertung. Ergebnisse müssen im jeweiligen fachlichen und rechtlichen Kontext eingeordnet werden.

Eine Ereignisbezeichnung ist ein fachliches Versprechen

Wer E-208 als „Materialverbrauch bestätigt“ liest, muss erkennen können, welche Menge, welches Material und welche Bestätigung gemeint sind. Diese Bedeutung darf sich nicht unbemerkt zwischen Masken, Schnittstellen und Auswertungen verändern.

Der Entwurf eines Prozessereignisses beginnt deshalb beim Auslöser und seiner Aussage. Identität, Zeitbezug und Objekte halten diese Aussage zuordenbar. Erst dann lässt sich beurteilen, welche Prozessfrage die gespeicherte Spur tatsächlich beantworten kann.