- Versionshinweise
- Bevor Sie beginnen
- Erste Schritte
- Integrationen
- Arbeiten mit Prozess-Apps
- Arbeiten mit Dashboards und Diagrammen
- Arbeiten mit Prozessdiagrammen
- Arbeiten mit Discover-Prozessmodellen und Import BPMN-Modellen
- Showing or hiding the menu
- Kontextinformationen
- Exportieren
- Filter
- Senden von Automatisierungsideen an den UiPath® Automation Hub
- Tags
- Fälligkeitsdaten
- Vergleichen
- Konformitätsprüfung
- Ursachenanalyse
- Simulation des Automatisierungspotenzials
- Auslösen einer Automatisierung über eine Prozess-App
- Anzeigen von Prozessdaten
- Erstellen von Apps
- Laden von Daten
- Anpassen von Prozess-Apps
- Einführung in Dashboards
- Dashboards erstellen
- Dashboards
- Automatisierungsmanager
- Input data
- Definieren neuer Eingabetabellen
- Hinzufügen von Feldern
- Hinzufügen von Tabellen
- Anforderungen an das Datenmodell
- Anzeigen und Bearbeiten des Datenmodells
- Exportieren und Importieren von Transformationen
- Bearbeiten und Testen von Datentransformationen
- Structure of transformations
- Zusammenführen von Ereignisprotokollen
- Tips for writing SQL
- Prozessmanager
- Dashboards veröffentlichen
- App-Vorlagen
- Zusätzliche Ressourcen

Process Mining
Structure of transformations
models\
im Abschnitt Transformationen der Datentransformationen ist gemäß der Struktur der Transformationsschritte organisiert.
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.
_input
hinzuzufügen.
optional
-Makro aus dem pm-utils
-Paket verwendet werden. Dadurch wird sichergestellt, dass ein Feld den Wert null
erhält, wenn es in den Quelldaten nicht verfügbar ist. So werden alle Transformationen korrekt ausgeführt.
-
Verwenden Sie das optional_table()- Makro, wenn die gesamte Tabelle optional ist.
Im Schritt Object werden Eingabetabellen in Objekttabellen umgewandelt. Jedes Objekt, das für die erwarteten Ereignisse erforderlich ist, sollte eine eigene Tabelle erhalten. Weitere Informationen finden Sie unter Entwerfen eines Ereignisprotokolls. Darüber hinaus kann hier auch das unterstützende Objekt definiert werden.
Invoices_input
, Invoice_types_input
und Customers_input
miteinander verbunden, um die Objekttabelle Rechnungen zu erstellen.
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.
Invoice_ID
.
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.
3. events
in den Transformationen für Ereignisprotokoll- und benutzerdefinierte Prozess -Apps nicht vorhanden ist.
In diesem Transformationsschritt werden für jedes Objekt Ereignistabellen erstellt. Informieren Sie sich über Entwerfen eines Ereignisprotokolls. Jeder Datensatz in einer Ereignistabelle stellt ein Ereignis dar, das stattgefunden hat. Es gibt zwei Szenarien für die Struktur der Daten:
- Zeitstempelfelder: Felder in einer Objekttabelle mit einem Zeitstempel für ein Ereignis. Zum Beispiel das Feld
Invoice_created
in einerInvoices
-Tabelle. - Transaktionsprotokoll: Eine Liste von Ereignissen.
Je nach Struktur der Daten unterscheiden sich die Transformationen zum Erstellen der Ereignistabellen.
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).
Invoices_input table
ist aufgeteilt in Invoice_events_Create_invoice
, Invoice_events_Delete_invoice
und Invoices_events_Change_invoice_price
.
Invoices_events
.
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).
Die folgenden Felder sind in einer Ereignistabelle obligatorisch. Alle Datensätze in den Ereignistabellen sollten einen Wert für diese Felder enthalten.
Feld |
Beschreibung |
---|---|
Objekt-ID |
ID des Objekts, für das das Ereignis passiert. 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. |
[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
.
Wenn der Prozess ein Objekt enthält, sind in diesem Schritt keine zusätzlichen Transformationen erforderlich. Die Einzelobjekttabelle und die Ereignistabellen haben bereits das richtige Format.
Wenn mehrere Objekte an einem Prozess beteiligt sind, müssen die Ereignisse aller Objekte mit dem Hauptobjekt verknüpft werden, das im Prozess als „Fall“ betrachtet wird. Weitere Informationen finden Sie unter Definieren des Ereignisprotokolls . In den folgenden Schritten wird beschrieben, wie alle Ereignisse auf das Hauptobjekt bezogen werden und wie sie in einem einzigen Ereignisprotokoll kombiniert werden.
Erstellen Sie eine „Objektbeziehungen“-Tabelle, um die Beziehungen zwischen allen Objekten zu zentralisieren. Diese Tabelle der Objektbeziehungen enthält die ID-Felder der zugehörigen Objekte.
Um die Tabelle „Objektbeziehungen“ zu erstellen, verbinden Sie alle Objekttabellen basierend auf ihren ID-Feldern:
- Beginnen Sie mit dem Hauptobjekt
- Verbinden Sie verknüpfte Objekte mit dem Hauptobjekt durch eine linke Verknüpfung.
- Wenn Objekte sich nicht direkt auf das Hauptobjekt beziehen, verbinden Sie sie links mit den zugehörigen Objekten, die bereits mit dem Hauptobjekt verbunden sind.
Im folgenden Beispiel gibt es drei Objekte: Bestellung,Rechnungszeile und Rechnung. Die Bestellung gilt als das Hauptobjekt im Prozess. Die Zeile Rechnung ist direkt mit der Bestellung und die Rechnung indirekt über die Zeile Rechnung verknüpft.
Object_relations as (
select
Purchase_orders."Purchase_order_ID"
Invoice_lines.Invoice_line_ID
"Invoices.Invoice_ID"
from Purchase_orders
left join Invoice_lines
on Purchase_orders."Purchase_order_ID" = "Invoice_lines."Purchase_order_ID"
left join Invoices
on Invoice_lines."Invoice_ID" = Invoices."Invoice_ID
)
Object_relations as (
select
Purchase_orders."Purchase_order_ID"
Invoice_lines.Invoice_line_ID
"Invoices.Invoice_ID"
from Purchase_orders
left join Invoice_lines
on Purchase_orders."Purchase_order_ID" = "Invoice_lines."Purchase_order_ID"
left join Invoices
on Invoice_lines."Invoice_ID" = Invoices."Invoice_ID
)
Die folgende Abbildung zeigt die resultierende Tabelle der Objektbeziehungen.
Die einzelnen Beziehungen zwischen dem Hauptobjekt und jedem anderen Objektobjekt werden in separaten Tabellen gespeichert, wobei die kombinierten Informationen aus der Tabelle der Objektbeziehungen verwendet werden.
Relation_invoice_lines as (
select
Object_relations."Purchase_order_ID"
Object_relations."Invoice_line_ID"
from Object_relations
group by "Purchase_order_ID", "Invoice_line_ID"
)
Relation_invoice_lines as (
select
Object_relations."Purchase_order_ID"
Object_relations."Invoice_line_ID"
from Object_relations
group by "Purchase_order_ID", "Invoice_line_ID"
)
Relation_invoices as (
select
Object_relations."Purchase_order_ID"
Object_relations."Invoice_ID"
from Object_relations
group by "Purchase_order_ID", "Invoice_ID"
)
Relation_invoices as (
select
Object_relations."Purchase_order_ID"
Object_relations."Invoice_ID"
from Object_relations
group by "Purchase_order_ID", "Invoice_ID"
)
Der nächste Schritt besteht darin, diese Beziehungen zu verwenden, um jeder Ereignistabelle eine entsprechende „Fall-ID“ hinzuzufügen. Die „Fall-ID“ wird über die Beziehungstabelle abgerufen, wobei die Ereignisinformationen aus der Ereignistabelle abgerufen werden. Um das vollständige Ereignisprotokoll zu erstellen, werden die Ereignistabellen für jedes Objekt vereint.
Purchase_order_event_log as (
select
Purchase_order_events."Purchase_order_ID"
Purchase_order_events."Activity"
Purchase_order_events."Event_end"
from Purchase_order_events
union all
select
Relation_invoice_lines."Purchase_order_ID"
Invoice_line_events."Activity"
Invoice_line_events."Event_end"
from Invoice_line_events
inner join Relation_invoice_lines
on Invoice_line_events."Invoice_line_ID" = "Relation_invoice_lines."Invoice_line_ID"
union all
select
Relation_invoices."Purchase_order_ID"
Invoice_events. "Activity"
Invoice_events. "Event_end"
from Invoice_events
inner join Relation_invoices
on Invoice_events."Invoice_line_ID" = Relation_invoices."Invoice_line_ID"
)
Purchase_order_event_log as (
select
Purchase_order_events."Purchase_order_ID"
Purchase_order_events."Activity"
Purchase_order_events."Event_end"
from Purchase_order_events
union all
select
Relation_invoice_lines."Purchase_order_ID"
Invoice_line_events."Activity"
Invoice_line_events."Event_end"
from Invoice_line_events
inner join Relation_invoice_lines
on Invoice_line_events."Invoice_line_ID" = "Relation_invoice_lines."Invoice_line_ID"
union all
select
Relation_invoices."Purchase_order_ID"
Invoice_events. "Activity"
Invoice_events. "Event_end"
from Invoice_events
inner join Relation_invoices
on Invoice_events."Invoice_line_ID" = Relation_invoices."Invoice_line_ID"
)
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.
Tags
und Due dates
.
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.
Object ID
und das Tag
. Nicht alle Objekte haben ein Tag und einige Objekte können mehrere Tags haben. Die folgende Abbildung zeigt ein Beispiel für die Tags-Tabelle.
Im Datenmodell ist nur eine Tags-Tabelle zulässig.
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.
Object ID
, Due date
, Actual date
und Expected date
.
Im Datenmodell ist nur eine Fälligkeitsdatentabelle zulässig.
- Überblick
- 1. Eingabe
- Benennungskonvention
- Optionale Felder
- 2. Objekte
- Richtlinien
- Additional transformations
- Benennungskonvention
- 3. Ereignisse
- Timestamp fields
- Transaktionsprotokoll
- Benennungskonvention
- 4. Ereignisprotokolle
- Einzelobjektprozess
- Prozess mit mehreren Objekten
- Objektbeziehungen
- Relation tables
- Ereignisprotokoll
- Benennungskonvention
- 5. Geschäftslogik
- Tags
- Fälligkeitsdaten