- 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
- 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
- DataBridgeAgent
- 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
- Basic troubleshooting guide
Designing an event log
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.
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 |
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.
purchase_order_type
und eine Rechnungsentität eine payment_due_date
haben.
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.