Migration von robotergestützer Automatisierung hin zu API-Orchestrierung im Kontext der Prozessautomatisierung

Robotic Process Automation (RPA) erlaubt die Bereitstellung automatisierter Funktionalität auch bei Abwesenheit von Automatisierungsmöglichkeiten über das Backend von Informationssystemen. Viele Unternehmen nutzen RPA daher als Schnittstelle für Altsysteme, planen aber mittel- bis langfristig auf nachhaltigere Automatisierungslösungen wie APIs zu setzen. Die Migration von der robotergestützten Automation hin zu API-basierter Orchestrierung (vgl. Abbildung 1) ist Gegenstand dieses Blogposts.

Die zentrale Fragestellung lässt sich in drei Bereiche unterteilen. In einem ersten Schritt gilt es herauszufinden, wie die Entwicklung von RPA Bots angegangen werden muss, sodass sie zu einem späteren Zeitpunkt leicht zu migrieren sind. In einem zweiten Schritt bedarf es der Untersuchung von migrationsrelevanten Kriterien, mit denen die Dringlichkeit einer Migration von Robotern abgeleitet werden kann. Zuletzt wird aus den gesammelten Erkenntnissen eine Architektur entworfen, die eine Migration von RPA zu API-Orchestrierung aus architektonischer Sichtweise möglich macht.

Abbildung 1: Zentrale Fragestellung

Wie sollten migrationsfertige RPA Bots entwickelt werden?

Interviews mit insgesamt 13 Experten aus dem Bereich des Geschäftsprozessmanagements legen sechs Design Requirements (DRs) und zwei Migration Challenges (MCs) offen. Die DRs stellen Anforderungen an das Design von migrationsfertigen Robotern dar, wohingegen die MCs Herausforderungen bei der Migrationsdurchführung an sich festhalten.

• DR1: Migrationsfertige RPA Roboter sollten von einem übergeordneten Prozess orchestriert werden und Teile eines Geschäftsprozesses automatisieren, nicht aber den Geschäftsprozess selbst. Dafür sind BPM- bzw. Worfklow-Systeme zu nutzen.
  
  
• DR2: Migrationsfertige RPA Roboter sollten auf gleicher Granularitätsebene wie Geschäftsfunktionen aus dem Gesamtprozess agieren. Damit stellt der Roboter einen Service bereit, der in gleicher Weise durch einen oder mehrere API Calls automatisiert werden kann. Bei der Modellierung des Services sollte die Bot-Logik nicht mit jener des eigentlichen Geschäftsprozesses vermengt werden. So ist die Klickstrecke des Roboters im User Interface nicht Teil des Geschäftsprozesses, sondern vielmehr die eigentliche „Service Task“, die der Roboter im Ergebnis realisiert.
  
  
• DR3: Migrationsfertige RPA Roboter sollten in einem System arbeiten. Sobald sie in mehreren Systemen arbeiten, sind auch eine Mehrzahl an APIs zu nutzen. Eine unkomplizierte Migration wäre damit behindert.
  
  
• DR4: Migrationsfertige RPA Roboter sollten wiederverwendbar sein. Für einen Roboter, der nicht wiederverwendbar ist und kaum Anwendungsfälle in anderen Prozessen hat, ist es schwierig, eine API-Entwicklung aus betriebswirtschaftlicher Sichtweise zu motivieren.
  
  
• DR5: Migrationsfertige RPA Roboter sollten das gleiche Fehlerverhalten wie APIs realisieren. Das erfordert die Idempotenz als wesentliche Eigenschaft für eine einheitliche Fehlerbehandlung. So müsste ein Roboter beispielsweise überprüfen, ob er eine übergebene Entität schon im Zielsystem findet, damit keine Zweite mit neuer ID entsteht.
  
  
• DR6: Nicht nur die Roboter, sondern auch die Prozesse, in dem sie genutzt werden, müssen eine Migration zulassen. Das Umfeld der zu realisierenden „Service Task“ muss es demnach erlauben, dass sowohl Bot als auch APIs eine Automation übernehmen können. Ist beispielsweise ein Timer-Event im Prozess auf die Laufzeit des RPA Bots zugeschnitten, so wird der Prozess immer solange warten müssen, bis der Roboter fertig ist. Bei Wechsel auf eine API ist allerdings ein Warten in dem Umfang nicht notwendig, da in aller Regel die Ergebnisse schneller zur Verfügung gestellt werden können. Solche „Hartkodierungen“ Bot-spezifischer Aspekte in Prozessen sind also zu vermeiden.
  
  
• MC1: Der eigentlichen Migration muss eine Eignungsanalyse zur Priorisierung von Robotern vorausgehen. Es bedarf strategischer Untersuchungen, in welcher Reihenfolge die Roboter abgelöst werden sollten. Diese Herausforderung ist Teil des zweiten Bereichs der zentralen Fragestellung dieses Blogposts.
  
  
• MC2: Die Migration wird durch ein abweichendes Datenverhalten zwischen Bot und API erschwert. Ein Roboter arbeitet u.U. mit anderen Daten als eine API und vice versa. So kann sich beispielsweise die Benamung einzelner Parameter unterscheiden, aber auch ihr Datentyp. Dies macht ein Mapping der Daten notwendig.

Die DRs und MCs lassen sich in ein Framework zur Herstellung von Migrationsfähigkeit von RPA Bots übersetzen. Konkret bedeutet das eine Erweiterung des RPA-Lebenszyklus um den Schritt der Migration auf einer untergeordneten Ebene, aber auch eine Kombination mit dem Lebenszyklus aus dem Geschäftsprozessmanagement als übergeordneter Ansatz zur Prozessautomatisierung. Das liegt darin begründet, dass migrationsfertige Roboter auf API-Granularität eine Orchestrierung im End-To-End Prozess notwendig machen. Das Framework in Abbildung 2 veranschaulicht die einzelnen DRs und MCs und weist diese den einzelnen Phasen zu. Es unterscheidet darüber hinaus technische Anforderungen zur Herstellung der Migrationsfähigkeit und „Business Value“-orientierte Aspekte, die eine Migration aus betriebswirtschaftlicher Sicht begünstigen.

Abbildung 2: Framework für die Entwicklung migrationsfertiger Roboter

Welche Kriterien können herangezogen werden, um die Dringlichkeit zur Migration von Robotern abzuleiten?

Ein Entscheidungsunterstützungsmodell zur Priorisierung von Robotern erfordert deren Evaluation anhand bestimmter Kriterien. In der Analyse der Interviews haben sich die Kriterien von Abbildung 3 als geeignete Indikatoren herausgestellt. So sind Roboter dringlicher zu migrieren, wenn sie auf Oberflächen arbeiten, die sehr anfällig für Veränderungen sind. Das Gleiche gilt für ihre absehbare Lebenszeit. Sollte ein Roboter bald obsolet werden, z.B. durch ein Systemwechsel oder -update, so sollte er mit Priorität betrachtet werden. Roboter, die unmittelbar mit dem Kunden interagieren, sind ebenso präferiert zu migrieren wie jene RPA Bots, die nur wenige Fälle komplett automatisieren können oder dies lediglich in unzureichender Qualität schaffen. Ein anderer Aspekt umfasst die Anzahl an „Bot Runners“. Bot Runner sind physikalische Maschinen, die für die Ausführung der RPA Prozessinstanzen notwendig sind. Eine hohe Anzahl deutet auf einen sehr kostenintensiven Roboter hin. Demnach könnte eine Migration von ressourcenhungrigen Robotern schneller zu Kosteneinsparungen führen als die Migration von Robotern mit weniger dedizierter Hardware.

Auch die Ausführungshäufigkeit und der Business Impact des zu automatisierenden Services spielen eine Rolle. APIs sind besonders bei hochvoluminösen und sehr einflussreichen Prozessen die bessere Alternative, weil sie weniger Hardware beanspruchen, Ergebnisse schneller produzieren und verlässlicher arbeiten können. Ein weiteres Kriterium ist die Anzahl der Systeme, mit der der Roboter bei Aufgabendurchführung kommunizieren muss. Die Stärken von RPA kommen besonders bei Prozessen zur Geltung, die eine Vielzahl von Applikationen beinhalten. Das kann, zum Beispiel, die Datenmigration über mehrere Systeme sein. Solche Roboter sind nur schwer mit APIs abzulösen, weshalb jene innerhalb  der Systemgrenzen für eine Migration bevorzugt werden sollten (vgl. DR3).

Die Wiederverwendbarkeit eines Roboters ist gleichermaßen zu berücksichtigen. Ein Roboter, der in mehreren Prozessen wiederverwendet werden kann, birgt höheres Potential für Kosteneinsparungen als ein Roboter, der lediglich in einem einzigen Prozess zur Anwendung kommt. Auf diese Weise würde ein Wechsel in der Wahl der Automatisierungstechnologie gleich an mehreren Stellen Wirkung erzielen. Das letzte Kriterium umfasst die Notwendigkeit zur Einhaltung gesetzlicher Vorschriften. Sollten bei Prozessausführung beispielsweise bestimmte ISO Richtlinien relevant werden, ist eine API in der Regel die bessere Wahl. Roboter können Unternehmen nämlich vor rechtliche Problemen stellen, insbesondere wegen der Lizenzbestimmungen und Nutzungsrechte der zu automatisierenden Software. Auch bietet RPA neue Angriffsflächen für Cyberattacken. Entsprechende Sicherheitsvorkehrungen werden notwendig und machen die Technologie daher in erster Linie wegen der gesetzlichen Vorgaben (z.B. durch DSGVO) aufwendiger zu realisieren und zu warten.

Abbildung 3: Kriterien für die Priorisierung von RPA Robotern

Diese Kriterien sind nicht mit „Ja“ oder „Nein“ zu bewerten, sondern in ihrem Grad der Zutreffendheit auf einer Skala. Beispielsweise kann die Stabilität des Frontends auf einer Likert Skala von 1 bis 4 eingeschätzt werden. So könnte der unterste Randwert eine einjährige Stabilität suggerieren, während der oberste Randwert eine Änderungshäufigkeit des User Interfaces von drei Monaten impliziert. Mit Festlegung der Skala und ihrer Interpretation kann bestimmt werden, inwieweit ein Roboter die Kriterien erfüllt. Das geschieht sowohl manuell als auch automatisiert. So ist die Stabilität des Frontends durch Fachexperten zu beurteilen, wohingegen die Automatisierungsquote eines RPA Bots nicht durch eine subjektive Einschätzung bewertet werden muss. Stattdessen kann die Auswertung gelingen, indem Informationen von BPM- und RPA-Systemen abgegriffen werden.   

Wie sieht eine migrationsfördernde Architektur aus?

Eine migrationsfördernde Architektur benötigt ein BPM-System für die Ausführung des übergeordneten Prozesses, ein RPA-System für die Ausführung der sich im Prozess befindlichen Aufgaben und eine systemische Brücke, mit der ein RPA-System aus dem Prozesskontext heraus angesteuert und Ergebnisse dem BPM-System zurückgeliefert werden können. Ferner ist es notwendig, den statischen und manuell zu erfassenden Teil der migrationsrelevanten Kriterien (vgl. Abbildung 3) schon bei der Modellaufnahme zu berücksichtigen. Dies erfordert Erweiterungen im Modellierungstool des BPM-Systems, die es erlauben, einen RPA-Bot zu verlinken und ihn entsprechend der Kriterien von Abbildung 3 zu bewerten. Gemäß MC2 ist es ebenso notwendig, die Migration durch ein Mapping der Daten zu begleiten. Das erlaubt das Wechseln von Roboter zu API mit nur einem Klick, da der Service unabhängig von der Automatisierungstechnologie in gleicher Weise automatisiert werden kann.  Dafür sind zwei sogenannte Task Handler notwendig. Der RPA Task Handler ist für die Ausführung der RPA-Task zuständig und Teil der systemischen Brücke. Er verbindet sich mit dem RPA-System, initiiert die Prozessausführung in der robotergestützten Umgebung und liefert dem BPM-System das erhaltene Ergebnis zurück. Der API Task Handler ist wiederum für die Ausführung zuständig, sobald eine Automation mit APIs möglich wird. Er greift auf ein zuvor von dem Nutzer angelegtes Mapping zurück und nutzt dies für die Ausführung des Services. Dadurch ist sichergestellt, dass die API die Aufgabe auf die exakt selbe Weise  erledigt. Beide Task Handler werden als Externe Worker im Prozessmodell über eine bestimmte Referenz angesprochen. Das Austauschen dieser Referenz erlaubt damit die Migration von Frontend Automation zu Backend Automation.

Im Rahmen der einer Proof of Concept-Implementierung wurde Camunda als BPM-System, UiPath als RPA-System und der External Task Client zur Realisierung der systemischen Brücke herangezogen. Der RPA Task Handler beruht auf Teilen der RPA Bridge von Camunda. Das Plugin für den Camunda Modeler ist genau wie der Task Handler für die APIs selbst geschrieben. Ein migrationsförderndes User Interface zur Priorisierung der Migrationskandidaten und Anlegung von Mapping-Templates ist ebenso entstanden und Teil der migrationsfördernden Architektur wie in Abbildung 4 dargestellt.

Abbildung 4: Migrationsfördernde Architektur

Diese Architektur ist exemplarisch implementiert und kann auf GitHub eingesehen werden. Der resultierende Prototyp ist in einem konkreten Anwendungsfall getestet worden. Das Ergebnis ist auf YouTube veröffentlicht und kann hier angeschaut werden. Die Ergebnisse zeigen, dass Roboter, die auf API Granularität in einem migrationsfertigen Gesamtprozess innerhalb der Systemgrenzen agieren (vgl. DR1, DR2, DR3 und DR6), das gleiche Fehlerverhalten wie APIs realisieren und darüber hinaus in verschiedenen Prozessen wieder verwendbar sind (vgl. DR4 und DR5) eine Migration aus technischer und betriebswirtschaftlicher Sicht erheblich begünstigen. Die hier vorgeschlagene Bewältigung der identifizierten Migrationsherausforderungen (vgl. MC1 und MC2) erleichtert die Migration zusätzlich.

Haben Sie RPA-Bots im Einsatz und wollen eine nachhaltige Architektur aufbauen, die eine spätere Migration ermöglicht? Kommen wir ins Gespräch!

Dieser Artikel basiert in großen Teilen auf der Master-Thesis „Migrating From Frontend Robotic Process Automation Solutions to Backend API Calls“ von Andre Strothmann, betreut vom Institut für Wirtschaftsinformatik der WWU Münster / ERCIS am Lehrstuhl von Prof. Becker.