RPA kommt in den Unternehmen an

Betrachtet man den Gartner Hypecycle für Emerging Technologies, erreichte das Thema Robotic Process Automation (bei Gartner Smart Robots genannt) 2017 seinen Höhepunkt. Doch was passiert nach dem Hype? Verschwindet das Thema wieder oder findet nun der Übergang in die produktive Phase statt? Was für Erfahrungen und Lessons learned gibt es bereits? Mit diesen Fragen befasste sich Ulrich Storck, Head of Product Development bei der Scheer GmbH, in seinem Vortrag auf der Veranstaltung in Frankfurt/Main.

Für erste Anhaltspunkte verwies Storck auf eine Studie der Information Services Group (ISG), in der knapp 250 Unternehmen aus Deutschland, Österreich und der Schweiz zum Thema RPA befragt wurden.

Der Erhebung zufolge befinden sich mehr als die Hälfte der befragten Unternehmen in einer frühen produktiven Phase mit Piloten oder wenigen Einzelprojekten, setzen RPA aber noch nicht strategisch ein. Allerdings stellen sechs von zehn Unternehmen in Aussicht, in zwei Jahren bereits mindestens zehn RPA-Prozesse aufgesetzt zu haben. Über die Hälfte davon wollen bis dahin sogar mehr als 25 Geschäftsprozesse an Softwareroboter übergeben.

Wie Storck ausführt, stellt sich bei den Anwendern teilweise bereits eine gewisse Ernüchterung ein - geboren aus der Erkenntnis, dass RPA nicht die eierlegende Wollmilchsau ist, sondern nur ein Mittel von vielen. Um Unternehmen Enttäuschungen zu ersparen, hat der Scheer-Manager sieben Lektionen aus Kundenprojekten zusammengetragen:

• Ein schlechter Prozess bleibt auch automatisiert ein schlechter Prozess: Man sollte Prozesse genau anschauen und erst optimieren, dann automatisieren.

• RPA löst nicht jedes Problem: Man muss die Prozesse ganzheitlich betrachten und Einschränkungen berücksichtigen.

• Nicht nur auf die Technologie fokussieren: Es gilt auch bei RPA die klassische Vier-Säulen-Strategie: Strategie, Implementierung, Produkt, IT

• Lohnende Prozesse für RPA systematisch identifizieren: Beratern zufolge gibt es 6 +2 Kriterien für Prozesse: Wiederholung, Häufigkeit, geringe Ausnahmequote, stabile Prozesse, Zeitersparnis möglich, keine Systemänderung nötig. Die Kriterien "Regelbasiert" und "standardisiert" sind dagegen mit der Einbeziehung von KI nicht mehr so wichtig, erklärt Storck.

• RPA-Projekte sollten agil sein: Eine Richtung ist vorgegeben, aber das Endergebnis steht noch nicht fest.

• Transparenz ist ein Schlüssel zum Erfolg: Das Wissen über Daten und Datenflüsse ist ein entscheidender Wettbewerbsfaktor, Erhebung und Analyse wichtiger Daten ist wichtiger Schritt für die nächste Automatisierungsstufe, übergreifende Modellierung und Darstellung der Prozesse ist weiterhin wichtig, Transparenz durch Integration und Auswertung aller Daten-Logs in Analytics/Mining-Tools.

• Überwachung und Fehler-Handling ist wichtig: Logische Fehler können durch Automatisierung zu größeren Schäden führen, Software-Robotor können nur Fehler behandeln, die während der Modellierung bedacht wurden, frühzeitiges Erkennen und permanentes Monitoring sind daher zwingende Notwendigkeit.

• RPA-Hürden meistern
  Keep it simple – der falsche Einstiegsprozess
  Der häufigste Fehler bei der Implementierung eines RPA-Projekts ist die Wahl des falschen Prozesses. „Falsch“ heißt für den Anfang zu komplex oder zu speziell. Zu empfehlen ist für den RPA-Einstieg die Wahl eines einfachen Prozesses. Damit stellt sich der Erfolg eher ein.
  Brauche Input! Aber bitte digital
  Bei der Wahl des richtigen Prozesses gilt der erste Blick den Daten. Um die Interaktion durch den Menschen gering zu halten, sollten die zugrundeliegenden Daten natürlich möglichst digital vorliegen.
  Strukturierte Daten: Ordnung muss sein
  Was ein Unternehmen bekommt, wenn es einen semioptimalen Prozess digitalisiert, hat der damalige Bitkom-Präsident Thorsten Dirks auf dem IT-Gipfel 2015 recht drastisch beschrieben. „Organisation geht vor Automatisierung“ gilt auch bei RPA, deshalb sollten die Daten möglichst strukturiert vorliegen.
  Text schlägt Bild
  Noch ein Hinweis zum Thema Daten, um den richtigen Prozess für den RPA-Einstieg zu identifizieren: Text- und Zahlenbasierte Daten lassen sich leichter mit RPA verarbeiten als Bildinformationen.
  Vorteil Standard
  Die Vorteile von standardisierten IT-Prozessen sind mannigfaltig. Stichworte sind Kosteneffizienz, sichere IT in hoher Qualität, transparentes Monitoring und Reporting etc. Je standardisierter ein Prozess ist, desto besser ist er für den RPA-Einstieg geeignet.
  Stabilität ist Trumpf
  Stabilität sollte nicht mit Stagnation verwechselt werden. Für RPA sind stabile Prozesse enorm wichtig. Denn die Software dient der Bearbeitung von strukturierten Geschäftsprozessen. Sie arbeitet dabei den Prozess genauso ab, wie ein Mensch das machen würde. Läuft der Prozess stabil, sind Interaktionen von Menschen nur selten oder gar nicht nötig.
  Die Masse machts - Prozesse mit hohem Volumen wählen
  Je häufiger ein Prozess vorkommt, desto größer ist die Entlastung durch RPA. Da Mitarbeiter meist erst einmal skeptisch auf den Ersteinsatz von RPA reagieren, hilft ein Prozess der ein hohes Volumen hat, auch bei der Akzeptanz der Robotics durch die Belegschaft.
  RPA als Erbsenzähler? Unbedingt!
  Fehleranfällige Prozesse sind häufig monotone Tätigkeiten, in die sich irgendwann der berühmte Schlendrian einschleicht. Aber für RPA gibt es keine Monotonie. Wenn der Prozess fehleranfällig ist, können sie ihre Stärken besser ausspielen!
  Das Team gewinnt
  Automatisierungen folgen in den meisten Unternehmen einer Strategie. Diese sollte mit einem zentralen Team verfolgt werden, das Informationen bündelt und RPA über Geschäftseinheiten hinweg einführt. Kleine Gruppen ohne Informationsaustausch über Learnings sind dazu verurteilt, die Fehler der anderen zu wiederholen.
  Strategie: Was sind die nächsten Schritte?
  Spötter sagen, dass eine Strategie vor allen Dingen festlegt, was nicht zu tun ist. Eine Automatisierungsstrategie hat klare Vorteile: Denn sobald Robotic Process Automation gut eingeführt ist, finden sich neue Anwendungsmöglichkeiten wie von selbst. Mit einer Strategie kann das Team abwägen, welche Prozesse zu priorisieren sind.
  Hauseigene IT einbeziehen
  Ein Vorteil von RPA ist es, dass es von der Fachabteilung angestoßen werden kann. Eine automatisierte Schatten-IT kann aber nicht das Ziel ein. Selbst wenn das Projekt von der Fachabteilung gesteuert wird: Bei der Implementierung der RPA ist die Unterstützung der IT notwendig.

RPA: Weder Hexenwerk noch Selbstläufer

Von den bereits umgesetzten RPA-Projekten und den dabei gemachten Erfahrungen berichtete Dimitar Todorov, Head of IT Applications and Integration Services bei der Energieversorgung Niederösterreich (EVN). Das Unternehmen mit knapp 7000 Mitarbeitern befindet sich beim Einsatz von Software-Robotern gerade in einem Proof of Concept, hat aber über die letzten Monate bereits 6 bis 7 Anwendungsfälle realisiert. Das bisherige Ergebnis fällt dabei laut Todorov weitgehend positiv aus: Der Return on Invest (ROI) werde mit RPA positiv beeinflusst und sei um Faktoren besser, konstatiert der IT-Verantwortliche, auch die Time to Market werde kürzer. Außerdem sei die Umsetzung kein Hexenwerk, wenn gegen eine grafische Schnittstelle entwickelt werde.

Allerdings, so Todorov, ist RPA nicht unbedingt ein Selbstläufer. So erfülle sich der Traum von Wiederverwendung nur selten, die Anwendungsfälle seien sorgfältig zu prüfen. Der Idealfall sei, wenn man in einem automatisierten Prozess Daten von A nach B schaufeln müsse. Der IT-Manager empfiehlt außerdem, bei einem RPA-Projekt alle Stakeholder rechtzeitig abzuholen. Dazu zähle auch der Betriebsrat. In seinem Unternehmen habe dieser das Projekt sogar unterstützt, da häufig monotone Tätigkeiten automatisiert werden, die die Mitarbeiter eher frustrierten.

Zudem dürften die IT-Verantwortlichen nicht vergessen, dass sie sich mit RPA eine weitere Technologie ins Haus holen - mit allen Konsequenzen. Werde RPA erst einmal geschäftskritisch eingesetzt, komme es schnell zu Auswirkungen auf die Kapazitätsplanung, da bei einem Ausfall Abläufe zum Stillstand kommen. Außerdem habe RPA lizenztechnische Auswirkungen auf Drittprodukte wie z.B. SAP.

Bei einem relativ neuen Thema wie RPA ist außerdem die Kompetenz des Technologiepartners wichtig. "Viele kennen das Potenzial noch nicht", erklärt Todorov, auch das Wissen über die Vor- und Nachteile der verschiedenen Lösungen am Markt sei oft nicht ausreichend vorhanden. Aus diesem Grund sei ein Partner gefragt, der die Technik beherrscht und sich auskennt.

RPA als Self-Service

Interessant ist die Art und Weise, wie das Thema interne Zuständigkeit bei der EVN gelöst wurde: Die IT bietet den Fachbereichen RPA als eine Art Self-Service an, allerdings nur angelernten/eingewiesenen Mitarbeitern, da dazu gewisse Programmierkenntnisse erforderlich sind. Hintergrund war das Interesse der Fachabteilungen, selbst Prozesse auszuwählen und einem Software-Roboter zu übergeben, schildert der EVN-Mann. Im Prinzip sei das richtig gewesen, so Todorov. Man müsse aber bedenken, dass es sich bei RPA um Softwareentwicklung handle und damit sei eine Qualitätssicherung erforderlich. Gleichzeitig brauche man jedoch die Kenntnisse aus dem Fachbereich für die Anpassung.

Von Low-Code zu No-Code

Unterstützt werden solche Bemühungen, die Fachabteilungen bei der Prozessautomatisierung stärker miteinzubeziehen, von der Industrie - und natürlich auch vom Gastgeber Scheer GmbH: So bietet das Saarbrückener Unternehmen mit der Scheer Process Automation Suite (Scheer PAS), die eine Lösung des RPA-Spezialisten Uipath integriert, bereits eine Low-Code-Plattform für die modellgetriebene Digitalisierung und Automatisierung von menschlichen Arbeitsprozessen.

Das August-Wilhelm Scheer Institut (AWSI) wiederum entwickelt eine Methode, mit deren Hilfe Arbeitsprozesse automatisiert erfasst und dokumentiert werden können. Mit Desktop Activity Mining, das Techniken aus dem Data und Process Mining nutzt, würden nötige Vorarbeiten entfallen, die bisher für RPA notwendig waren. Im Detail werden über ein im Hintergrund laufendes Aufnahmeprogramm die relevanten Prozessaktionen der Mitarbeiter wie Texteingaben, Mausklicks oder Programmaufrufe identifiziert und anonymisiert erfasst. Aus diesen werden dann mit Process-Mining-Algorithmen Prozessmodelle generiert, um eine umfangreiche Darstellung des realen Arbeitsprozesses zu erhalten.

Laut AWSI setzt Desktop Activity Mining im Gegensatz zu klassischen Process-Mining-Ansätzen, bei denen nur Transaktionsdaten aus IT-Systemen zur Beschreibung eines Geschäftsprozesses genutzt werden, auf der direkten Arbeitsebene der Mitarbeiter an. Es werden also auch solche Aktionen erfasst, die trotz ihrer Prozessrelevanz bisher nicht durch vorhandene IT-Systeme dokumentiert werden können - beispielsweise das Schreiben einer E-Mail.