Bot-Checkpoint beim Fortsetzen

Beschreibung der Herausforderung

Stellen Sie sich vor, Sie arbeiten an einem Projekt. Sie definieren Ihr Ziel, schreiben wahrscheinlich auf, was zu tun ist, und streichen dann jede dieser Aktionen nach und nach ab, sobald sie erledigt ist. Ein solches Projekt würde wahrscheinlich einige Zeit in Anspruch nehmen – Sie müssen schlafen, und es ist schwierig, den ganzen Tag über fokussiert und produktiv zu bleiben, nicht wahr? Hinzu kommen Ablenkungen. Wenn Sie also (insbesondere nach einer gewissen Zeit) zu Ihrem Projekt zurückkehren und die Arbeit fortsetzen möchten, wo fangen Sie an? In meinem Fall würde ich zu diesem Blatt Papier greifen und prüfen, was bereits erledigt wurde und was als Nächstes zu tun ist, um zu bestimmen, in welcher Phase sich der Projektabschluss gerade befindet.

Wenn ein Bot nun einen Prozess ausführt, können unerwartete Unterbrechungen auftreten, etwa durch Netzwerkprobleme. Bei einfachen Automatisierungen kann der Prozess in der Regel neu gestartet werden und einfach von Beginn an von vorne beginnen. Manchmal gibt es jedoch Aktionen, die nach ihrem Abschluss nicht wiederholt werden können – was dann? Dann sollte der Bot einen Blick auf sein eigenes „Blatt Papier“ werfen.

Antwort

Bei der Analyse eines kürzlich automatisierten Prozesses baten die Fachanwender darum, dass bestimmte SAP-Transaktionen für einen gegebenen Satz von Parametern nur einmal ausgeführt werden sollten. Weitere Anforderungen umfassten, dass der Bot die während der Verarbeitung erzeugten Daten in MS-Teams-basierten Excel-Dateien speichert, die die Eingaben für die verschiedenen Prozessschritte enthalten. Aufgrund dieser Anforderungen muss der Bot vor Beginn der Verarbeitung seinen Zustand prüfen. Der daraus resultierende Ablauf ist in vereinfachter Form im folgenden BPMN-Diagramm dargestellt:

[Grafik 1] Vereinfachter selbstorientierender Ablauf

Man beachte, dass wir insgesamt 6 Startzustände des Bots bestimmen können, wobei jedem ein Bedingungsknoten vorausgeht, der die Durchlaufbedingung prüft – ist eine gegebene Bedingung erfüllt, überspringt der Bot die entsprechende Stufe:

[Grafik 2] Zustände im Startablauf

Bei genauerem Hinsehen können wir zudem feststellen, dass der Bot – ausgehend von Zustand 1 – im Idealfall Zustand 2 vollständig überspringt und direkt zu Zustand 3 übergeht. Schlägt der Teil des Prozesses zur Dokumentenerstellung fehl, setzt der Bot in Zustand 2 fort, der eine Benutzereingabe außerhalb der Bot-Ausführung erfordert – die Dokumentennummer könnte bereits generiert, aber noch nicht in die Datei eingetragen worden sein, was zu einem Fehler führt:

[Grafik 3] Erweiterte Zustände

Fazit

Je nach Komplexität des automatisierten Prozesses kann die Bestimmung der Bot-Zustände während der Ausführung eine anspruchsvolle Aufgabe sein. Eine höhere Anzahl an Checkpoints erhöht die Sicherheit der Datenverarbeitung, geht jedoch möglicherweise mit den Kosten eines ständigen Speicherns und Hochladens von Daten einher, was die Effizienz der Ausführung verringert. Dieses Risiko lässt sich durch unterschiedliche Methoden zur Speicherung des Bot-Zustands steuern. Excel ist dabei eine benutzerfreundliche, aber zeitaufwendige Lösung. Erfordert der Prozess hingegen Kommunikation und verzögerte Eingaben von Endnutzern oder ist er anderweitig anfällig für häufiges Fortsetzen, hilft diese Lösung, Ressourcen zu schonen.