Entscheidungshilfe: 6 Kriterien für oder gegen einen RPA Einsatz – Teil 3

3 klare Kriterien, die gegen den Einsatz einer RPA Lösung sprechen (CONTRA)  und ein kurzes Fazit.

Teil 1
dieser kleinen Serie widmet sich der Frage ob es einen Konflikt zwischen meist Fachabteilungen, als Befürworter von RPA und meist IT Vertretern, eher als Skeptikern von RPA gibt und warum Low-Code eine meist unbeachtete Alternative darstellt.

Teil 2
nennt 3 konkrete Punkte bei denen der Einsatz von RPA richtig ist (PRO

Teil 3
nennt 3 klare Kriterien, die gegen den Einsatz einer RPA Lösung sprechen (CONTRA)  und zieht ein kurzes Fazit.

Teil 3
3 Kriterien gegen den Einsatz einer RPA Lösung (CONTRA)  plus Fazit.

Nachdem wir uns in den vorangegangenen Teilen der Frage gewidmet haben ob es einen Konflikt zwischen Fachseite meist als RPA Verfechter und IT meist als RPA Skeptiker gibt (Teil1) und uns in Teil 2 einige klare Kriterien für einen RPA Einsatz angesehen haben, folgt hier nun Teil 3 dieser kleinen Serie.

Welche Kriterien helfen bei der Entscheidung gegen RPA und für Low-Code?

Manchmal hilft auch das Gegenteil. Das Kriterium etwas mit RPA zu tun ist ab und an nicht so klar, wie ein Argument, das Sie unterstützt, garantiert die Finger davon zu lassen.

Aber liegt ein solches Kriterium vor, dann kann es auch sehr hilfreich sein es zu kennen, auch wenn die Alternative dann nicht so klar ist wie meist in der von mir vertretenden Welt einer gern APPIAN basierten Low-Code Lösung.

Kriterium 4 :
Gibt es eine Schnittstelle wie REST; SOAP oder XML für das Problem, dann nutze sie mit Low-Code und nicht mit RPA.

Warum gibt es eine Schnittstelle in einem Prozess zwischen Systemen oder innerhalb eines Systems meist nicht?

Es gibt viele Gründe, aber ganz vorn dabei sind sicherlich diejenigen, dass es zu teuer war bzw. zu lange dauerte diese Schnittstelle zu implementieren.
Oder man kannte die Schnittstelle nicht.
Oder wenn es die Schnittstelle gab, dann war keiner in Lage mit ihr umzugehen und gegen sie zu programmieren, weshalb eine Prozesslücke blieb.
Oder die Schnittstelle wurde erst viel später durch Updates des Herstellers seiner Software hinzugefügt, und stand als man damals seine „kleinen“ Anpassungen der „Standardsoftware“ bei Einführung vornahm, noch nicht zur Verfügung.

Viele Hersteller von Software haben die Bedeutung einer API als Element ihrer Software heute erkannt und zumindest kein modernes und hippes neues System, von Jira bis Doxis, von Appian bis Confluence oder von Quicken bis Office (vielleicht alles nicht so „hipp“…), kommt heute ohne eine API daher.

Leider ist die Überzeugung der Nutzung solcher API’s bei den Lizenznehmern dieser Software nicht ganz so verbreitet, wie bei den Anbietern.

Aber wenn Sie bei Ihrer Untersuchung während einer Entscheidung für RPA oder gegen RPA feststellen, dass es passende existierende (und funktionierende) Schnittstellen Protokolle gibt, dann nutzen Sie sie!

Gerade mit Low-Code!

Low-Code Umgebungen ziehen u.a. ihren Nutzen gerade daraus, die Entwicklung von passender Software auch gegen typische und verbreitete Standardschnittstellen wie REST, SOAP und XML zu erleichtern. Dies gilt umso mehr noch für vorhandene proprietäre Technologien, wie zum Beispiel IDOC und BAPI oder andere Message orientierte Formate. Das geht zum Teil so weit, dass es richtig Spaß machen kann in die Gesichter der Entwicklungstruppe zu sehen, die eben noch dem LowCode Entwickler einen mitgegeben hat, weil er auf seiner „proprietären“ Umgebung doch erstmal einen sauberen REST Service erstellen soll, bevor er wieder mit seinem Low-Code Ansatz in seiner „geschlossenen“ Umgebung daher kommt.

Noch bevor die Truppe die Tür erreicht, werden sie so manches Mal von der Frage erreicht, ob es „so“ denn recht sei.

Sie sollten einer solche Schnittstelle aus mannigfaltigen Gründen aber nicht mit einer RPA Antwort begegnen. Denn klebt Ihr Pflaster erstmal über zwei existierenden Schnittstellen, dann wird Ihr Patient ewig an dieser Stelle weiterhumpeln und niemals geheilt, dafür aber ewig in Ihrer Pflege bleiben müssen, wenn sich die Schnittstellen auch nur minimal ändern. Und Sie sehen dann nicht, nicht im Prozess, nicht im Build-Vorgang, nicht im Test und nicht im Prozessmonitoring, wo es klemmt. Aber irgendwann klingelt das Telefon aus der Fachabteilung und bittet um Entsendung des jungen Beraters von der Beratungsfirma…damals…aber bitte Pronto, denn „..hier kann keiner arbeiten.“

Kriterium 5 :
Transaktionen mit hohem Tagesvolumen

(z.B. >10.000 Stück) und /oder die in Echtzeit durchgeführt

Hohe Stückzahlen deuten häufig auf einen möglicherweise interessanten Business Case, der gerne auch eine vollständige Implementierung einer Prozessbrücke (natürlich mit einem Low-Code System) rechtfertigt.

Aber hohe Stückzahlen bringen auch immer den Aspekt einer zeitlichen Komponente mit. Es mag dauern diese Vorgänge zu bearbeiten, vielleicht auch länger als gewünscht, oder es gibt eine harte Grenze, bis ein Vorgang garantiert abgeschlossen sein muss.

RPA hat den Nachteil, immer (wenn man denn die Regeln 4 mit den Schnittstellen einhält, was man besser tut) über die GUIs der jeweiligen Anwendungssysteme gehen zu müssen. Und das kann dauern.

Erstens weil „Kollege Roboter“ zwar unwidersprochen schneller ist beim Eingeben, als sein menschlicher Gegenpart, aber im Sinne eines Computers keinem anderen Tempo Standard auch nur annähernd das Wasser reichen kann. Und zweitens, weil die betroffenen Softwaresysteme und ihre Oberflächen meist wesentlicher Bestandteil des Problems sind. Wer kennt nicht das „Sanduhr-Anzeige-Programm“ oder die Oberfläche, bei der man sich bei der Suche nach dem richtigen Kunden oder der Verarbeitung der richtigen Daten entspannt zurücklegt, einen Schluck aus der Kaffeetasse nimmt und die Kollegin nebenan mit einem schlechten Scherz beglückt, bevor die Software vor einem dem nächsten Datensatz freudig entgegenblickt.

Das geht dem Kollegen Roboter nicht anders.

Skalieren durch mehrere Roboter hilft hier auch nicht viel, weil es das System nur noch mehr belastet.

Skalierung durch mehr Roboter mag aber eine Option sein, wenn das verarbeitende System ausreichend Reserven hat.

Technisch bedeutet das aber, drei, vier oder mehr weitere Softwarekomponenten aufzustellen und zu betreiben, um zu skalieren.
Kann man machen. Kann man aber auch lassen und seine passende Softwarelösung einfach per se skalieren lassen, oder durch Auto -Instanziierung wachsen zu lassen. Nennen Sie mich einen Ketzer, aber ich halte die Art der Skalierung über Roboter nicht für den heiligen Gral, sondern würde das als das Kreuz betrachten, dass es zu tragen gilt. Und bitte jeder nur ein Kreuz, wenn sie mir dieses Zitat verzeihen.

Kriterium 6 :
Sollte Mehrweg-Mensch-Maschine Interaktionen erforderlich sein, dann ist RPA nicht der Weg

Wenn Sie feststellen, dass die RPA Implementierung an der Stelle ihrer Beschwerden häufiger dazu übergeht, dass der menschliche Kollege des Roboters mit ihm interagieren muss, um

• Mehrmals in einem einzigen Prozess-Ablauf
• Mindestens einmal in einem von vielen einzelnen Prozessen
• Mindestens einmal an mehr als einer Stelle in verknüpften Prozess-Stacks

einzugreifen. Und sollten diese Prozesse in ordentlicher Stückzahl vorkommen, was sie eigentlich immer tun, denn sonst würde Kollege Roboter da nicht sitzen sollen, dann ist das ein klares Zeichen es besser mit einem anderen Ansatz zu versuchen.

Warum?

Das Auftreten von Aufgaben (Tasks) in einer Mensch-Maschine-Kommunikation, insbesondere an mehreren aufeinanderfolgenden Stellen ist ein Signal für das Vorliegen eines Prozesses und nicht für einen isolierten Bearbeitungsschritt.

Nun bieten RPA Systeme natürlich auch alle Möglichkeiten der Erstellung eines Workflows an sich, welches auch die Konsultation von Menschen im Prozess mit einbezieht.

Alle Möglichkeiten des Dialoges, der Entscheidung und Verzweigung, der Protokollierung und Rechtekontrolle sind gegeben. Das Gesagte gilt heutzutage in stark zunehmendem Maße auch für andere Softwareklassen, seien es Ticketverarbeitungssysteme, Dokumentenverarbeitungssysteme, viele Formen von Management- und Organisationswerkzeugen etc.

Aus meiner Sicht jedoch liegt an dieser Stelle ein klarer Prozess vor und der gehört dann für mich eher in die Hände eines Spezialisten, wie es ein BPM Werkzeug sein kann.

Denn diese Interaktion führt an Stellen, in denen höhere Stückzahlen vorkommen können, zu weiteren Fragen, wie Arbeitsgruppen, Aufgabenverteilung und Monitoring, Rücknahme, Routing und Weitergabe von Aufgaben, Fehlerbearbeitung etc. und da sehe ich persönlich BPM Systeme im klaren Vorteil gegenüber Robotics (und allen anderen) Lösungen.

Tatsächlich ist es in vielen Fällen so, dass RPA Hersteller und BPM Hersteller hier eng kooperieren, eben weil Erstere die Fähigkeiten der Letzteren brauchen, wenn es den Idealfall verlässt oder es einen komplizierteren Verlauf nimmt. Und Letztere brauchen Erstere, weil eben viele Menschen sich nicht sonderlich viele Gedanken um die unter anderem hier gestellten Fragen machen und daher derzeit die RPA Lösungen einen nachhaltigen Marktanteil von der Prozess Seite übernehmen. Es wird interessant sein zu verfolgen, ob das in Zukunft so bleibt und ob die mögliche Veränderung von gleichfalls umfangreicher Pressearbeit begleitet sein wird.

Fazit

RPA Systeme haben einen nicht zu vernachlässigenden Wert. Roboter gehören unumstößlich in den Werkzeugkasten einer guten aufgestellten IT, wie eine saubere Architekturidee, Services, AI, Machine Learning und Low-Code.

BPM und Low-Code kämpfen mit dem aktuellen Hype in der Branche in Bezug auf Robots, wenngleich deren Technologie, anders als man glauben mag, nicht wirklich neu ist.

Eine Low-Code Alternative gehört in jeden Werkzeugkasten eines IT Managers, der einen guten Job machen will. Und die Low-Code Alternative sollte immer ein Prüfstein in einer RPA Entscheidung sein.

Aber die Entscheidung, wann RPA einsetzen und wann nicht, sollte gut überlegt sein und keinesfalls allein auf Basis eines möglichen guten Business Cases mit RPA erfolgen. Wenn man nicht andere Möglichkeiten, insbesondere einer Low-Code basierte Software Lösung in Betracht gezogen hat, und natürlich auch deren Business Case, macht man etwas falsch. Auf keinen Fall darf man bei Beiden den Einbezug der sekundären Kosten, der Wartbarkeit, des Risikos oder der Bewältigbarkeit vernachlässigen.

Die in diesem Artikel formulierten 6 konkreten Argumentationshilfen, für oder gegen die Nutzung von RPA an einer Stelle, können dabei hilfreich sein.

…Teil 1 widmete sich der Frage, ob es einen Konflikt zwischen RPA Vertretern, üblicherweise in Fachabteilungen und Low-Code Vertretern, üblicherweise in der IT, gibt.

…Teil 2 nennt 3 Kriterien, bei denen der RPA Einsatz wirklich sinnvoll ist und auch Low-Code keine wirklich gute Alternative ist.