- 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
- Starten eines Task Mining-Projekts über Process Mining
- 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
- Veröffentlichen von Prozess-Apps
- App-Vorlagen
- Zusätzliche Ressourcen
- Vorgefertigte Tags und Fälligkeitsdaten
- Bearbeiten von Datentransformationen in einer lokalen Umgebung
- Setting up a local test environment
- Designing an event log
- Systemanforderungen
- Konfigurieren des DataBridgeAgent
- Hinzufügen eines benutzerdefinierten Connectors zu DataBridgeAgent
- Verwenden von DataBridgeAgent mit dem SAP Connector für den Purchase-to-Pay Discovery Accelerator
- Verwenden von DataBridgeAgent mit dem SAP Connector für den Order-to-Cash Discovery Accelerator
- Erweitern des Extraktionstools SAP Ariba
- Leistungsmerkmale
Structure of transformations
Nachfolgend finden Sie eine Übersicht über die Transformationsschritte der Process Mining -App-Vorlagen.
models\
ist entsprechend 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 „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.
Invoices_input
, Invoice_types_input
und Customers_input
miteinander verbunden, um die Entitätstabelle „Rechnungen“ zu erstellen.
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.
Invoice_ID
mit der Rechnungsentität zusammenhängen.
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.
3. events
in den Transformationen für Ereignisprotokoll- und benutzerdefinierte Prozess -Apps 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 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 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).
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 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. |
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.
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.
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.
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 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 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.
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.
- Überblick
- 1. Eingabe
- Benennungskonvention
- Optionale Felder
- 2. Entitäten
- Richtlinien
- Additional transformations
- Benennungskonvention
- 3. Ereignisse
- Timestamp fields
- Transaktionsprotokoll
- Benennungskonvention
- 4. Ereignisprotokolle
- Prozess mit einer einzelnen Entität
- Prozess mit mehreren Entitäten
- Entity relations
- Relation tables
- Ereignisprotokoll
- Benennungskonvention
- 5. Geschäftslogik
- Tags
- Fälligkeitsdaten