Fachbeitrag · Wirtschaftsinformatik ·
Prozessanalyse: Warum eine einzige Fallnummer zusammengehörige Abläufe verzerren kann
Für eine Prozessanalyse werden Ereignisse häufig nach einer Fallnummer gruppiert. Das funktioniert gut, solange tatsächlich ein einzelner Geschäftsvorgang verfolgt wird. Im betrieblichen Alltag hängen jedoch Bestellungen, Positionen, Lieferungen und Rechnungen unterschiedlich zusammen. Wird alles auf nur eine dieser Kennungen reduziert, kann die Auswertung Aktivitäten vervielfachen oder getrennte Abläufe vermischen. Die Wahl der Fallperspektive beeinflusst damit schon vor der eigentlichen Analyse das Ergebnis.
Ein Ereignis kann mehrere Objekte betreffen
Eine Sammellieferung kann Positionen mehrerer Bestellungen enthalten. Wird das Lieferereignis jeder Bestellung vollständig zugeordnet, erscheint dieselbe reale Aktivität mehrfach im abgeleiteten Ereignisprotokoll. Umgekehrt kann eine Bestellung mehrere Lieferungen und Teilrechnungen auslösen. Eine einzige Fallnummer beschreibt diese Beziehungen nur eingeschränkt. Objektzentrierte Ereignisdaten halten deshalb fest, welche unterschiedlichen Geschäftsobjekte an einem Ereignis beteiligt sind, statt sämtliche Beziehungen dauerhaft in eine flache Ereignisfolge zu pressen.
Ein kleines Beispiel sauber abgrenzen
Zwei Bestellungen mit insgesamt fünf Positionen werden gemeinsam versendet. Für die Logistik ist das ein Versandvorgang; für den Einkauf sind es zwei Bestellabläufe. Eine Auswertung nach Bestellnummer darf den gemeinsamen Versand nicht unbemerkt als zwei unabhängige Transportleistungen zählen. Die Analyse sollte vorab festlegen, ob sie Bestelllaufzeiten, Lieferdurchlaufzeiten oder die Anzahl realer Versandereignisse untersucht. Diese Größen können aus denselben Quelldaten entstehen und trotzdem unterschiedliche Bezugsobjekte und Nenner benötigen.
Beziehungen als eigene Information behandeln
Ein geeignetes Datenmodell unterscheidet Ereignisse, Objekte und deren Beziehungen. Es dokumentiert etwa, dass eine Position zu einer Bestellung gehört und eine Lieferung mehrere Positionen enthält. Zusätzliche Rollen können erläutern, ob ein Objekt Auslöser, Ergebnis oder beteiligte Ressource eines Ereignisses war. Wichtig sind stabile Kennungen und eine nachvollziehbare zeitliche Zuordnung. Eine Beziehung, die erst nachträglich ergänzt wird, sollte nicht so aussehen, als sei sie bei der ursprünglichen Aktivität bereits bekannt gewesen.
Den Erkenntnisgewinn nicht überschätzen
Ein umfangreicheres Ereignismodell korrigiert keine falschen Zeitstempel oder fehlenden Fachinformationen. Auch objektzentrierte Daten brauchen Qualitätsprüfungen und einen klaren Analysezweck. Für einen einfachen, eindeutig abgegrenzten Ablauf kann eine klassische Fallnummer weiterhin ausreichen. Vor einer Umstellung lohnt ein Vergleich an wenigen repräsentativen Vorgängen: Welche Aktivitäten wurden bisher doppelt gezählt, welche Verzweigungen verschwanden und welche fachliche Frage lässt sich mit den zusätzlichen Beziehungen tatsächlich besser beantworten?
Technical insight · Business information systems ·
Process analysis: Why one case identifier can distort connected workflows
Process analysis often groups events by a case identifier. That works well when the analysis genuinely follows one distinct business instance. In everyday operations, however, orders, items, deliveries and invoices have different relationships. Reducing everything to just one of those identifiers can duplicate activities or mix separate flows. Choosing a case perspective therefore influences the result before the actual analysis even begins.
One event can involve several objects
A consolidated delivery can contain items from several orders. If its delivery event is assigned in full to every order, the same real activity appears several times in the derived event log. Conversely, one order may produce several deliveries and partial invoices. A single case identifier can only describe these relationships to a limited extent. Object-centric event data records the different business objects involved in an event instead of permanently flattening every relationship into one sequence.
Define a small example carefully
Two orders containing five items are dispatched together. Logistics sees one dispatch operation; procurement sees two order lifecycles. An analysis by order number should not silently count that common dispatch as two independent transport services. The analysis must first state whether it investigates order lead times, delivery lead times or the number of actual dispatch events. These measures can come from the same source data while requiring different reference objects and denominators.
Treat relationships as information in their own right
A suitable model separates events, objects and the relationships between them. It can record that an item belongs to an order and that a delivery contains several items. Additional relationship roles can explain whether an object triggered an event, resulted from it or acted as a resource. Stable identifiers and traceable timing are essential. A relationship added later should not look as though it was already known when the original activity took place.
Do not overstate the benefit
A richer event model does not correct inaccurate timestamps or missing business information. Object-centric data still requires quality checks and a specific analytical purpose. A traditional case identifier may remain sufficient for a simple, clearly bounded process. Before changing the approach, compare a few representative cases: which activities were previously double-counted, which branches disappeared and which business question can genuinely be answered better through the additional relationships?