Designing an event log

Einleitung

Beim Einrichten der Transformationen für Process Mining ist es wichtig, den Prozess gut zu verstehen. Der erste Schritt besteht darin, die auftretenden Ereignisse und die Entitäten zu definieren, für die diese Ereignisse stattfinden.

Define the events

Beginnen Sie mit der Definition der hochwertigen Aktivitäten. Legen Sie die Prioritäten für das Hinzufügen von Aktivitäten danach fest, wie häufig sie auftreten und wie sinnvoll sie für den Endbenutzer sind. Das Definieren der Aktivitäten sollte ein iterativer Prozess sein.

Nachfolgend finden Sie ein Beispiel für ein Ereignisprotokoll für den Prozess „Rechnungen“.

Die ideale Anzahl von Aktivitäten zur Beschreibung eines Prozesses liegt zwischen 10 und 20. Obwohl mehr Aktivitäten zu mehr Analysemöglichkeiten führen, führt dies auch zu mehr Prozessvariationen und einer höheren Komplexität.

Anzahl der Aktivitäten	Ergebnis
<10	Geringe Analysekomplexität, geringe Anzahl potenzieller Verbesserungen.
10-20	Optimale Balance von Analysekomplexität und möglichen Verbesserungen
20	Hohe Analysekomplexität, hohe Anzahl kleiner Verbesserungen.

Benennungskonventionen

Für Aktivitätsnamen empfiehlt sich die Verwendung des Verb-Substantiv-Formats, z. B. Dokument erstellen. In der folgenden Tabelle finden Sie einige Ratschläge zur Benennung von Aktivitäten.

Aktivitätsname	Hinweis	Best Practices
Auftrag Auftrag	Vermeiden Sie nicht eindeutige Aktivitätsnamen.	Material bestellen
Ticket	Vermeiden Sie singuläre Aktivitätsnamen und geben Sie an, was womit passiert ist.	Ticket erstellen
Dokument storniert	Vermeiden Sie Passivformen.	Dokument stornieren
Kreditkontrollprüfung für den Kundenauftrag genehmigen	Vermeiden Sie zu lange Aktivitätsnamen.	SO-Bonitätsprüfung genehmigen

Define entities

Die Ereignisse finden für eine oder mehrere Entitäten im Prozess statt. Verwenden Sie den Satz der gewünschten Ereignisse, um zu bestimmen, welche Entitäten für einen Geschäftsprozess benötigt werden. Nachfolgend finden Sie ein Beispiel für eine Reihe von Ereignissen und ihre entsprechenden Entitäten.

Jede Entität kann Eigenschaften haben, die für diese Entität spezifisch sind. Beispielsweise kann eine Bestellentität eine purchase_order_type und eine Rechnungsentität eine payment_due_date haben.

Define the event log

Die Anzahl der Entitäten, die in einem Prozess von Interesse sind, hängt von der Komplexität des Prozesses ab. In einigen Prozessen ist möglicherweise nur eine Entität erforderlich, z. B. das Ticket in einem Incident Management-Prozess.

In komplexeren Prozessen können mehrere Entitäten von Interesse sein. Ein Purchase-to-Pay-Prozess, der mit dem Kauf eines Produkts bis zur Zahlung einer Rechnung beginnt, deckt beispielsweise eine Reihe von Ereignissen ab, die sich auf mehrere Entitäten beziehen. Um ein Ereignisprotokoll für solche Prozesse zu erstellen, müssen die Beziehungen zwischen den Entitäten definiert werden. In der folgenden Abbildung finden Sie ein Beispiel für ein Beziehungsdiagramm für Purchase-to-Pay-Entitäten.

Das Ereignisprotokoll beschreibt den End-to-End-Prozess, der die Ereignisse aller Entitäten zusammen abdeckt. Nur eine Entität im Prozess kann als Hauptentität fungieren, die während des gesamten Prozesses nachverfolgt wird. Diese Hauptentität wird im Prozess als „Fall“ bezeichnet und durch ihre „Fall-ID“ identifiziert.