Foto: Olivier Le Moal - shutterstock.com
Bei der robotergesteuerten Prozessautomatisierung (RPA) werden Software-Roboter - sogenannte Bots - so trainiert, dass sie regelgestützte Arbeitsabläufe selbständig ausführen. Die Vorteile klingen auf den ersten Blick verlockend: Bots beschleunigen Vorgänge, arbeiten kosteneffizient und minimieren die Fehlerquote. Allerdings eignet sich diese Methode lediglich für einfache Aufgaben und simuliert menschliche Arbeiten an einem Bildschirm. Für die Digitalisierung komplexer Geschäftsprozesse ist sie nicht gedacht.
Ein typisches Beispiel für die Digitalisierung von Prozessen ist das Ausfüllen eines Online-Formulars. Bei der einfachen Eingabe der Daten kann RPA den User noch unterstützen. Ist das Formular aber Teil eines Onboarding-Prozesses mit mehreren Schritten und Abhängigkeiten, sind bereits die Grenzen der Technologie erreicht. Denn RPA ist nicht in der Lage, einen komplexen Geschäftsablauf zu simulieren. Diesen wichtigen Unterschied erkennen leider nur wenige Unternehmen. Die Folge sind minderwertige Umsetzungen und gescheiterte Projekte.
RPA ist kein Allrounder
RPA selbst ist keine Allround-Lösung, sondern nur ein Tool in einem gut sortierten Werkzeugkasten. Um das Potenzial voll auszuschöpfen, sollte RPA mit einer Lösung für BPA (Business Process Automation, also die Automatisierung von Geschäftsprozessen) kombiniert werden, mit der sich komplexe Geschäftsprozesse digitalisieren lassen. Durch die Ergänzung dieser beiden Methoden entsteht ein deutlicher Mehrwert für das Unternehmen.
Foto: Blue Planet Studio - shutterstock.com
Bei umfangreichen Projekten, welche die Integration mehrerer IT-Anwendungen beinhalten, ist es üblicherweise effizienter, skalierbarer und zuverlässiger, wenn eine Anwendung die Programmierschnittstelle (API) jedes Systems aufruft. Es gibt aber Situationen, in denen der Einsatz von RPA sinnvoll ist:
Fehlende API: Es gibt keine API, um die Interaktion und Integration mit einer Anwendung zu handhaben. Oder die API bietet zu wenig Funktionalität, ist umständlich in der Handhabung oder erfordert zusätzliche Lizenzen.
Fehlendes Fachwissen: Das für die Integration verantwortliche Team kennt sich mit der API nicht aus. Mithilfe von RPA kann es aber interaktive Bildschirmsitzungen aufzeichnen und sich anzeigen lassen, welche Informationen automatisch eingegeben oder gelesen werden sollen.
Kein API-Zugriff: Es gibt Fälle, in denen die Systemverantwortlichen dem Anwendungsentwickler keinen Zugriff auf die APIs gewähren wollen. Dies könnte die Bereitstellung von Servicekonten, Training, Tests und Überwachungsressourcen erfordern, die vorübergehend nicht verfügbar sind.
Schnelle Bereitstellung: Wenn das Ziel darin besteht, dass ein zeitnahes PoC (Proof of Concept) und ein erster Prototyp zügig bereitgestellt werden müssen, um Feedback einzuholen, ist eine Unterstützung durch RPA sinnvoll. Dieser Ansatz bietet sich etwa als erster Testlauf mit Blick auf die spätere Verwendung einer API-basierten Lösung an.
Die Grenzen von RPA
Trotz der skizzierten Anwendungsszenarien ist RPA kein Allheilmittel und empfiehlt sich nicht für jede Situation. In der Praxis haben sich im Wesentlichen drei wichtige Einschränkungen gezeigt:
Aktualisierungen: Wenn sich bei einem Update die Benutzeroberfläche ändert, wird ein RPA-Bot unwirksam. Er kann mit der neuen UI nicht mehr interagieren, da er sie nicht erkennt.
Ressourcen: Bei jeder Bot-Sitzung wird eine Browser- oder eine Desktop-Anwendung als eigene Instanz gestartet. Das kann viele Ressourcen verbrauchen. Zudem ist es üblich, dass RPA-Anbieter die Preise für die Nutzung ihrer Plattformen nach Anzahl der gleichzeitig laufenden Bots berechnen. Unter Umständen führt dies zu hohen Kosten.
Auslesen von IDs: Einige Integrationen hängen von eindeutigen IDs in den Datenbanken ab. Diese werden etwa für Abfragen und Funktionsaufrufe verwendet, wobei die IDs nicht immer auf dem Bildschirm auftauchen. Selbst wenn eine Master-Item-ID grundsätzlich sichtbar ist, werden nicht unbedingt die IDs für Einzelposten oder verknüpfte Daten angezeigt - etwa die Positionsliste einer Bestellung oder Informationen über bevorzugte Lieferanten. In diesen Fällen kann der RPA-Bot die ID am Bildschirm nicht auslesen und die Aufgabe nicht ausführen. Der Versuch, dies durch die Simulation einer interaktiven Suche auszugleichen, ist nicht zu empfehlen. Ein solches Vorgehen birgt große Risiken.
Der entscheidende Unterschied: Aufgabe vs. Prozess
Um die Grenzen von RPA zu verstehen, muss man zwischen einfachen Aufgaben und Prozessen unterscheiden. Die Unterschiede lassen sich anhand des oben erwähnten Beispiels veranschaulichen: Ausfüllen eines einzelnen Formulars (Aufgabe) gegenüber Onboarding eines Mitarbeiters (Prozess).
Das Onboarding ist in der Regel ein komplexer Ablauf, an dem mehrere Unternehmensbereiche beteiligt sind - unter anderem die HR- oder die IT-Abteilung. Der Ablauf besteht zudem aus einer ganzen Reihe einzelner Aufgaben, Entscheidungen und Workflows:
Gehaltsverhandlung,
Festlegen eines Starttermins,
Zuteilung von Büroräumen oder Vereinbarung von Mobile Work,
Ausgabe von Sicherheitsausweisen und Schlüsseln,
Beschaffung und Versand von Ausrüstung,
Erstellen von Netzwerk-Anmeldeinformationen,
Zuteilung von Softwarelizenzen,
Einweisung in den Umgang mit Tools und anderen spezifischen Lösungen,
Terminvereinbarung für ein Gespräch am Ende der Probezeit,
… und vieles mehr.
Einige dieser Schritte lassen sich nicht automatisieren. Sie sollten trotzdem identifiziert, modelliert, überwacht und geprüft werden. Allerdings kann RPA die Einarbeitung eines neuen Mitarbeiters beschleunigen - beispielsweise durch die Unterstützung beim Ausfüllen von Formularen. Dieser Schritt stellt jedoch nur eine isolierte Aufgabe dar.
Konsequenzen für den Betriebsalltag
RPA ist ein leistungsfähiges Werkzeug im Rahmen seiner Möglichkeiten, aber nicht geeignet für Situationen, in denen es um allgemeine Initiativen zur digitalen Transformation geht. Dort lässt sich die Technologie nur punktuell einsetzen.
Das wirft die Frage auf, wie ein Unternehmen an die Optimierung seiner Geschäftsprozesse herangehen sollte. Als Faustregel empfiehlt sich: Wenn es vorrangig darum geht, "wie" etwas erledigt werden soll, eignet sich die Automatisierung von Aufgaben und somit RPA. Geht es aber darum, "was" oder sogar, "ob" etwas erledigt werden muss, empfehlen sich BPA-Tools, die komplexere Prozesse digitalisieren können.
Diese Unterschiede haben auch Auswirkungen auf das Projektmanagement. Denn bei der Automatisierung von einzelnen Aktivitäten beschäftigt sich das Projektteam hauptsächlich mit dem RPA-Tool und der Implementierung des Bots - in Verbindung mit der Dokumentation seiner Funktionsweise, um diese für Außenstehende transparent zu machen. Bei der Automatisierung von komplexeren Geschäftsprozessen unter Einsatz von BPA-Tools hingegen steht die Dokumentation der Ziele und Abläufe im Vordergrund. Die Details zur technischen Umsetzung bleiben oftmals zur besseren Übersicht über den Gesamtprozess im Hintergrund verborgen.
Bei RPA handelt es sich sicher nicht um die "nächste Generation der Prozess-Automatisierung", wie oft behauptet wird. Denn es geht nicht um Geschäftsprozesse, sondern nur um die massenhafte Verrichtung von Aufgaben durch Bots anstatt durch Menschen. Diese Aufgaben sind aber nur einer von vielen Bestandteilen eines Geschäftsprozesses, neben der Orchestrierung mitsamt Delegierung und Berücksichtigung von Vertreterregelungen sowie der Steuerung von abhängigen Sub-Prozessen. Gute BPA-Plattformen beinhalten alle dafür nötigen Werkzeuge und noch viel mehr, wie beispielsweise Reporting Tools, die Transparenz über alle Vorgänge im Unternehmen schaffen. RPA Tools hingegen bieten diese Funktionen und Möglichkeiten nicht.
Auch wenn es der Strategie vieler Unternehmen widerspricht, so wenig Tools wie möglich im Haus zu haben, ist es wichtig, jedes der beiden Werkzeuge für seinen bestimmten Zweck zu verwenden - BPA-Tools für die Digitalisierung von Geschäftsprozessen und RPA für die massenhafte Ausführung repetitiver Aufgaben.