Beschreibung der Herausforderung
Stellen Sie sich vor, Sie arbeiten an einem Projekt. Sie identifizieren Ihr Ziel, schreiben wahrscheinlich auf, was getan werden muss, und streichen dann jede dieser Maßnahmen durch, sobald Sie sie abgeschlossen haben. Dieses Projekt würde wahrscheinlich einige Zeit in Anspruch nehmen – Sie müssen schlafen, und es ist schwer, den ganzen Tag konzentriert und produktiv zu sein, nicht wahr? Dazu kommen Ablenkungen. Wenn Sie also nach einiger Zeit zu Ihrem Projekt zurückkehren und es fortsetzen möchten, wo fangen Sie an? In meinem Fall würde ich dieses Stück Papier nehmen und prüfen, was bereits erledigt wurde und was als nächstes getan werden muss, um den aktuellen Stand des Projekts zu bestimmen.
Wenn ein Bot nun an der Fertigstellung eines Prozesses arbeitet, können unerwartete Unterbrechungen auftreten, wie z. B. Netzwerkprobleme. Bei einfachen Automatisierungen kann er in der Regel neu gestartet werden und einfach von Anfang an beginnen. Manchmal gibt es jedoch Aktionen, die nach ihrer Ausführung nicht wiederholt werden können – was dann? Dann sollte der Bot einen Blick auf sein Stück Papier werfen.
Lösung
Bei der Identifizierung eines kürzlich automatisierten Prozesses forderten Geschäftsanwender, dass einige SAP-Transaktionen für einen bestimmten Parametersatz nur einmal ausgeführt werden sollten. Weitere Anforderungen umfassten, dass der Bot während der Verarbeitung erzeugte Daten in MS Teams-basierten Excel-Dateien speichert, die Eingaben für verschiedene Prozessschritte enthalten. Aufgrund dieser Anforderungen muss der Bot seinen Zustand vor Beginn der Verarbeitung überprüfen. Das resultierende Verfahren ist in vereinfachter Form im folgenden BPMN-Diagramm dargestellt:
![[Graphics 1] Simplified self-orienting procedure [Graphics 1] Simplified self-orienting procedure](https://www.ktbnet.pl/wp-content/uploads/elementor/thumbs/Graphics-1-Simplified-self-orienting-procedure-qumjexya7gnx3xam59lx6kvxttpkx5wg55r57mop1m.png)
Beachten Sie, dass wir insgesamt 6 Bot-Startzustände bestimmen können, denen jeweils ein Bedingungsknoten vorausgeht, der die Übergangsbedingung prüft – wenn eine bestimmte Bedingung erfüllt ist, überspringt der Bot die entsprechende Phase:
![[Graphics 2] States in starting procedure [Graphics 2] States in starting procedure](https://www.ktbnet.pl/wp-content/uploads/elementor/thumbs/Graphics-2-States-in-starting-procedure-qumjizn9ms7d3heziil3f24dwjrh28yud6velioo96.png)
Außerdem können wir bei näherer Betrachtung tiefer schauen und sehen, dass unter der Annahme, dass der Bot von Zustand 1 startet, der Happy Path Zustand 2 vollständig überspringt und direkt zu Zustand 3 übergeht. Wenn der Dokumentenerstellungsteil des Prozesses fehlschlägt, setzt der Bot bei Zustand 2 fort, der eine Benutzereingabe außerhalb der Bot-Ausführung erfordert – die Dokumentennummer könnte bereits generiert worden sein, aber nicht in der Datei bereitgestellt worden sein, was zu einem Fehler führt:
![[Graphics 3] States extended [Graphics 3] States extended](https://www.ktbnet.pl/wp-content/uploads/elementor/thumbs/Graphics-3-States-extended-qumjax74yz5rfz4vmj1dileychj1zrxs99adb0nbnu.png)
Fazit
Je nach Komplexität des automatisierten Prozesses kann die Bestimmung der Bot-Zustände während der Ausführung schwierig sein. Die Anzahl der Checkpoints erhöht die Sicherheit der Datenverarbeitung, möglicherweise jedoch auf Kosten des ständigen Speicherns und Hochladens von Daten, was die Ausführungseffizienz verringert. Das Risiko kann durch verschiedene Methoden zur Bewahrung des Bot-Zustands gesteuert werden. Excel ist eine benutzerfreundliche, aber zeitaufwändige Lösung. Wenn der Prozess andererseits Kommunikation und verzögerte Eingaben von Endbenutzern erfordert oder anderweitig anfällig für mehrfaches Fortsetzen ist, hilft die Lösung dabei, Ressourcen zu schonen.

