Structure of transformations

Überblick

Nachfolgend finden Sie eine Übersicht über die Transformationsschritte der Process Mining -App-Vorlagen.

Der Ordner models\ ist entsprechend der Struktur der Transformationsschritte organisiert.

1. Eingabe

Der Eingabeschritt wird verwendet, um die Rohdaten zu laden. Die folgenden Vorgänge werden in der Regel durchgeführt, um die Daten für die nächsten Transformationsschritte vorzubereiten:

• Wählen Sie Felder mit dem optionalen und obligatorischen Makro aus. Ein Feld muss nicht in den Rohdaten vorhanden sein, wenn das optionale Makro verwendet wird.
• Geben Sie Umwandlungsfelder in die entsprechenden Datentypen ein.

• Filtern Sie Tabellen, um die Datengröße zu Beginn der Transformationen zu reduzieren.

Hinweis: Es wird empfohlen, die Datengröße nach Möglichkeit bereits bei der Extraktion zu reduzieren.

Benennungskonvention

Wenn Sie erwarten, dass Namenskonflikte mit Tabellennamen in den nächsten Transformationsschritten auftreten, ist es sinnvoll, den Eingabetabellen das Suffix _input hinzuzufügen.

2. Entitäten

Im Schritt „Entitäten“ werden Eingabetabellen in Entitätstabellen umgewandelt. Jede Entität, die für die erwarteten Ereignisse erforderlich ist, sollte eine eigene Tabelle erhalten. Weitere Informationen finden Sie unter Entwerfen eines Ereignisprotokolls. Zudem können hier auch unterstützende Entitäten definiert werden.

Im folgenden Beispiel werden 3 Eingabetabellen Invoices_input , Invoice_types_input und Customers_input miteinander verbunden, um die Entitätstabelle „Rechnungen“ zu erstellen.

Richtlinien

Befolgen Sie diese Richtlinie, wenn Sie eine Entitätstabelle erstellen.

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

Falls zutreffend, bezieht sich die Entitätstabelle über ein ID-Feld auf eine andere Entität. Siehe das folgende Beispiel, in dem die Rechnungszeilen über das Feld Invoice_ID mit der Rechnungsentität zusammenhängen.

Additional transformations

Nicht alle Eingabetabellen werden in Entitätstabellen umgewandelt. Auch andere Eingabetabellen können relevante Informationen enthalten, z. B. die Customers-Tabelle im Beispiel. Es kann praktisch sein, sie im Entitätenschritt als separate Tabellen zu definieren, damit sie in den Datenumwandlungen wiederverwendet werden können.

Benennungskonvention

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

3. Ereignisse

Hinweis: Die Eingabe für die App-Vorlagen „TemplateOne-SingleFile“ und „ TemplateOne-MultiFiles“ ist bereits ein gut definiertes Ereignisprotokoll für Process Mining. Hier müssen die Daten aus dem Quellsystem nicht in die Ereignisse für Process Mining umgewandelt werden. Das bedeutet, dass 3. events in den Transformationen für die Prozess-Apps TemplateOne-SingleFile und TemplateOne-MultiFiles nicht vorhanden ist.

In diesem Transformationsschritt werden für jede Entität Ereignistabellen erstellt. Siehe Entwerfen eines Ereignisprotokolls. Jeder Datensatz in einer Ereignistabelle stellt ein stattgefundenes Ereignis dar. Es gibt zwei Szenarien für die Struktur der Daten:

• Zeitstempelfelder: Felder in einer Entitätstabelle mit einem Zeitstempel für ein Ereignis. Zum Beispiel das Feld Invoice_created in einer Invoices -Tabelle.
• Transaktionsprotokoll: Eine Liste von Ereignissen.

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

Timestamp fields

In diesem Szenario müssen die Werte eines Zeitstempelfelds in separate Datensätze in einer Ereignistabelle umgewandelt werden. Das folgende Beispiel ist 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 zu einer einzelnen Ereignistabelle pro Entität zusammengeführt werden, z. B. Invoices_events .

Transaktionsprotokoll

Wenn Ereignisse in einem Transaktionsprotokoll gespeichert werden, sollten die relevanten Ereignisse pro Entität identifiziert werden. Erstellen Sie eine Tabelle pro Entität und speichern Sie die entsprechende Entitäts-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 Entitäten „ Purchase Order “ und „Invoice “.

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

Feld	Beschreibung
Entitäts-ID	ID der Entität, für die das Ereignis eintritt. Beispielsweise die Rechnungs-ID.
Aktivität	Die Aktivität beschreibt, welche Aktion für die Entität ausgeführt wurde.
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 gemäß der Struktur [Entity] + _events. Zum Beispiel  Purchase_order_events und Invoice_events .

4. Ereignisprotokolle

Prozess mit einer einzelnen Entität

Wenn der Prozess eine Entität enthält, sind in diesem Schritt keine zusätzlichen Transformationen erforderlich. Die Tabelle mit einer einzelnen Entität und die Ereignistabellen haben bereits das richtige Format.

Prozess mit mehreren Entitäten

Wenn mehrere Entitäten an einem Prozess beteiligt sind, müssen die Ereignisse aller Entitäten mit der Hauptentität verknüpft werden, die im Prozess als „Fall“ betrachtet wird. Weitere Informationen finden Sie unter Definieren des Ereignisprotokolls . In den folgenden Schritten wird beschrieben, wie alle Ereignisse auf die Hauptentität bezogen werden und wie sie in einem einzigen Ereignisprotokoll kombiniert werden.

Entity relations

Erstellen Sie eine „Entity-Relations“-Tabelle, um die Beziehungen zwischen allen Entitäten zu zentralisieren. Diese Entitätsbeziehungstabelle enthält die ID-Felder der zugehörigen Entitäten.

Um die Entitätsbeziehungstabelle zu erstellen, verknüpfen Sie alle Entitätstabellen basierend auf ihren ID-Feldern:

• Beginnen Sie mit der Hauptentität
• Verbinden Sie verwandte Entitäten mit der Hauptentität mit einer linken Verknüpfung.
• Wenn Entitäten sich nicht direkt auf die Hauptentität beziehen, verknüpfen Sie sie mit den verknüpften Entitäten, die bereits mit der Hauptentität verknüpft sind.

Im folgenden Beispiel gibt es drei Entitäten: Purchase order,Invoice lineund Invoice. Die Bestellung gilt als die Hauptentität im Prozess. Die Rechnungszeile ist direkt mit der Bestellung und die Rechnung indirekt über die Rechnungszeileverknüpft.

Unten sehen Sie die resultierende Entitätsbeziehungstabelle.

Relation tables

Die einzelnen Beziehungen zwischen der Hauptentität und jeder anderen Entität werden in separaten Tabellen gespeichert, wobei die kombinierten Informationen aus der Tabelle der Entitätsbeziehungen verwendet werden.

Ereignisprotokoll

Der nächste Schritt besteht darin, diese Beziehungen zu verwenden, um jeder Ereignistabelle die entsprechende „Fall-ID“ hinzuzufügen. Die „Fall-ID“ wird über die Beziehungstabelle abgerufen, in der die Ereignisinformationen aus der Ereignistabelle abgerufen werden. Um das vollständige Ereignisprotokoll zu erstellen, werden die Ereignistabellen für jede Entität vereinigt.

Benennungskonvention

Wenn der Name der Ereignisprotokolltabelle zu einem späteren Zeitpunkt zu Namenskonflikten führen kann, fügen Sie dem Namen der Ereignisprotokolltabellen das Suffix _base hinzu.

5. 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 Miningsind in diesem Transformationsschritt zwei zusätzliche Standardtabellen definiert: Tags und Due dates .

Tags

Tags sind Eigenschaften von Fällen, die bestimmte Geschäftsregeln bezeichnen. Tags werden normalerweise 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 Tag-Tabelle stellt ein Tag dar, das in den Daten für einen bestimmten Fall vorgekommen ist. Die Pflichtfelder für diese Tabelle sind die „Fall-ID“ und das „Tag“. Nicht alle Fälle haben ein Tag und einige Fälle können mehrere Tags haben. Unten sehen Sie ein Beispiel für eine Tags-Tabelle.

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 Ereignis dar. Beispiele für Fälligkeitsdaten sind:

• eine Zahlungsfrist für ein Zahlungsereignis.
• eine Genehmigungsfrist für einen Genehmigungstermin.

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

Nicht alle Ereignisse haben ein Fälligkeitsdatum und einige Ereignisse können mehrere Fälligkeitsdaten haben.