Struktur von Transformationen

Überblick

Die folgende Abbildung zeigt die Transformationsschritte der Process Mining App-Vorlagen.

Der Ordner models\ im Abschnitt Transformationen von Datentransformationen ist entsprechend der Struktur der Transformationsschritte organisiert.

Hinweis:

Die App-Vorlagen Ereignisprotokoll und Benutzerdefinierter Prozess haben eine vereinfachte Datentransformationsstruktur. Prozess-Apps, die mit diesen App-Vorlagen erstellt wurden, haben diese Ordnerstruktur nicht.

1. Objekte

Im Schritt Objekte werden Eingabetabellen in Objekttabellen umgewandelt. Jedes Objekt, das für die erwarteten Ereignisse erforderlich ist, sollte eine eigene Tabelle erhalten. Siehe Entwerfen eines Ereignisprotokolls. Darüber hinaus kann hier auch das Unterstützungsobjekt definiert werden.

Im folgenden Beispiel werden die drei Eingabetabellen Invoices_input, Invoice_types_input und Customers_input miteinander verbunden, um die Objekttabelle Rechnungen zu erstellen.

Richtlinien

Befolgen Sie diese Richtlinie beim Erstellen einer Objekttabelle.

• Es gibt ein Objekt-ID-Feld, das für jeden Datensatz eindeutig ist.
• Alle Objektfelder, die für die Datenanalyse erforderlich sind, sind vorhanden.
• Alle Objektfelder haben Namen, die leicht verständlich sind.

Falls zutreffend, verweist die Objekttabelle über ein ID-Feld auf ein anderes Objekt. Im folgenden Beispiel beziehen sich die Rechnungszeilen auf das Rechnungsobjekt über das Feld Invoice_ID .

Zusätzliche Transformationen

Nicht alle Eingabetabellen werden in Objekttabellen umgewandelt. Auch andere Eingabetabellen können relevante Informationen enthalten, wie z. B. die Tabelle Customers im Beispiel. Es kann hilfreich sein, sie im Schritt Objekte als separate Tabellen zu definieren, sodass sie in den Datentransformationen wiederverwendet werden können.

Benennungskonvention

Wenn die Namen der Objekttabellen später zu Namenskonflikten führen würden, fügen Sie den Tabellen das Suffix _base hinzu.

2. Ereignisse

Hinweis:

Die Eingabe für Ereignisprotokoll- und benutzerdefinierte Prozess- App-Vorlagen ist bereits ein klar definiertes Ereignisprotokoll für Process Mining. Die Daten müssen nicht aus dem Quellsystem in die Ereignisse für Process Mining transformiert werden.

In diesem Transformationsschritt werden für jedes Objekt Ereignistabellen erstellt. Sehen Sie sich Entwerfen eines Ereignisprotokolls an. Jeder Datensatz in einer Ereignistabelle stellt ein Ereignis dar, das stattgefunden hat. Es gibt zwei Szenarien, wie die Daten strukturiert sind:

• Zeitstempelfelder: Felder in einer Objekttabelle mit einem Zeitstempel für ein Ereignis. Zum Beispiel das Feld Invoice_created in einer Invoices -Tabelle.
• Transaktionsprotokoll: Eine Liste der Ereignisse.

Je nach Struktur der Daten unterscheiden sich die Transformationen zum Erstellen der Ereignistabellen.

Zeitstempelfelder

In diesem Szenario müssen die Werte eines Zeitstempelfelds in separate Datensätze in einer Ereignistabelle umgewandelt werden. Das folgende Beispiel enthält eine Rechnungstabelle, die drei Zeitstempelfelder enthält.

Jedes Zeitstempelfeld wird verwendet, um eine separate Ereignistabelle zu erstellen. Erstellen Sie für jeden Datensatz, bei dem das Zeitstempelfeld einen Wert enthält, eine Tabelle mit der Rechnungs-ID, dem Namen des Ereignisses (Aktivität) und dem Zeitstempel, in dem das Ereignis stattgefunden hat (Ereignisende).

Die Invoices_input table ist aufgeteilt in Invoice_events_Create_invoice , Invoice_events_Delete_invoice und Invoices_events_Change_invoice_price .

Die separaten Ereignistabellen können dann in eine einzelne Ereignistabelle pro Objekt zusammengeführt werden, z. B. Invoices_events.

Transaktionsprotokoll

Wenn Ereignisse in einem Transaktionsprotokoll gespeichert werden, sollten die relevanten Ereignisse pro Objekt identifiziert werden. Erstellen Sie eine Tabelle pro Objekt und speichern Sie die entsprechende Objekt-ID, den Namen des Ereignisses (Aktivität) und den Zeitstempel, in dem das Ereignis stattgefunden hat (Ereignisende).

Im folgenden Beispiel enthält das Transaktionsprotokoll Ereignisse für die Objekte Bestellung und Rechnung .

Die folgenden Felder sind in einer Ereignistabelle obligatorisch. Alle Datensätze in den Ereignistabellen müssen einen Wert für diese Felder enthalten.

Feld	Beschreibung
Objekt-ID	ID des Objekts, für das das Ereignis auftritt. Zum Beispiel die Rechnungs-ID.
Aktivität	Die Aktivität beschreibt, welche Aktion für das Objekt stattgefunden hat.
Event end	Das Feld Ereignisende gibt an, wann das bestimmte Ereignis beendet wurde. Im Idealfall sollte dies ein datetime-Feld und kein Datum sein.

Benennungskonvention

Benennen Sie die Tabellen nach [Activity] + _events um eine Ereignisdatei pro Aktivität zu erstellen, oder [Object] + _events um eine Ereignisdatei pro Objekt zu erstellen. Zum Beispiel Purchase_order_created_events, Purchase_order_approved_events oder eine Datei mit allen Bestellaktivitäten kombiniert Purchase_order_events.

3. Geschäftslogik

Im letzten Transformationsschritt wird die Geschäftslogik nach Bedarf für die Datenanalyse hinzugefügt. Hier können zusätzliche abgeleitete Felder zu vorhandenen Tabellen hinzugefügt werden. Zum Beispiel bestimmte Durchlaufzeiten oder boolesche Felder, die in KPIs in Dashboards verwendet werden.

In Process Mining, there are two additional standard tables defined in this transformation step: Tags and Due dates.

Tags

Tags sind Eigenschaften von Objekten, die für bestimmte Geschäftsregeln stehen. Tags werden in der Regel hinzugefügt, um die Analyse dieser Geschäftsregeln zu vereinfachen. Zum Beispiel:

• Rechnung wurde von derselben Person bezahlt und genehmigt.
• Die Rechnungsgenehmigung hat mehr als 10 Tage gedauert.
• Aktivität „Rechnung überprüfen“ übersprungen.

Jeder Datensatz in der Tags-Tabelle steht für ein Tag, das in den Daten für einen bestimmten Fall aufgetreten ist. Die Pflichtfelder für diese Tabelle sind die Object ID und das Tag. Nicht alle Objekte haben ein Tag und einige Objekte können mehrere Tags haben. Die folgende Abbildung zeigt eine Beispiel-Tags-Tabelle.

Hinweis:

Ähnlich wie bei Ereignissen können mehrere Tag-Tabellen im Datenmodell vorhanden sein.

Benennungskonvention

Benennen Sie die Tabellen nach der Struktur [Tag] + _tags , um eine Datei pro Tag zu erstellen, oder [Object] + _tags , um eine Datei pro Objekt zu erstellen. Zum Beispiel Invoice_approved_and_paid_by_same_person_tags, Invoice_approval_too_late_tags oder eine Datei mit allen Rechnungs-Tags kombiniert Invoice_tags.

Fälligkeitsdaten

Fälligkeitsdaten stellen Fristen im Prozess dar. Diese werden den Daten hinzugefügt, um zu analysieren, ob Aktivitäten zu diesen Fälligkeitsdaten pünktlich ausgeführt werden oder nicht.

Jeder Datensatz in der Tabelle „Fälligkeitsdaten“ stellt ein Fälligkeitsdatum für ein bestimmtes Objekt dar. Beispiele für Fälligkeitsdaten sind:

• eine Zahlungsfrist für eine Zahlung.
• eine Genehmigungsfrist für eine Bestellung.

Die Pflichtfelder für diese Tabelle sind Object ID, Due date, Actual date und Expected date.

Hinweis:

Ähnlich wie bei Ereignissen können mehrere Fälligkeitsdatentabellen im Datenmodell vorhanden sein.

Benennungskonventionen

Benennen Sie die Tabellen nach der Struktur [Due date] + _due_dates , um eine Datei pro Fälligkeitsdatum zu erstellen, oder [Object] + _due_dates , um eine Datei pro Objekt zu erstellen. Zum Beispiel Payment_deadline_due_dates, Payment_deadline_with_discount_due_dates oder eine Datei mit allen Fälligkeitsdaten der Rechnung kombiniert Payment_due_dates.