RPA (Abkürzung für Robotergesteuerte Prozess-Automatisierung, siehe auch https://de.wikipedia.org/wiki/Robotergesteuerte_Prozessautomatisierung) ist in zahlreichen Fertigungsindustrien, Dienstleistungsbranchen sowie im Energiemarkt nach wie vor in aller Munde. Zahlreiche Unternehmen sind unterwegs, teils im Alleingang - teils mit Unterstützung von Beratern, Softwarefirmen und/oder Servicedienstleistern, die ökonomischen Potenziale dieser Technologie auszuloten.
Einige Unternehmen stecken in der Evaluationsphase, wo bemessen wird, ob und welche Prozesse sich eignen, und wie groß die möglichen Effizienzgewinne sein können. Andere Unternehmen haben bereits Pilotprozesse mittels Softwarerobotern automatisiert, oder sogar erste RPA-Automationen im operativen täglichen Einsatz. Einige wenige sind sogar soweit, in etlichen Fachbereichen gleichzeitig roboterautomatisierte Prozesse zu betreiben, und dutzende, manchmal sogar dreistellige Zahlen von Softwarerobotern in einer sogenannten RPA-Fabrik (siehe unten: RPA-Fünf-Layer-Modell, Layer 4) gebündelt zu betreiben und zu betreuen.
Eines ist, unterstützt durch zahlreiche Umfragen, Studien und Expertenstimmen, sicher: das Thema der Robotergesteuerte Prozess-Automatisierung wird mittlere und größere Unternehmen noch auf lange Sicht beschäftigen. Das wahre Potenzial von RPA wird sich nach Meinung der meisten Branchenkenner nämlich erst dann entfalten, wenn der Einsatz von künstlicher Intelligenz, mindestens von ML (Machine Learning), im Praxiseinsatz in der Breite ankommt und über Prototypenstadien hinaus kommt. Doch so weit sind wir noch nicht, zumindest nicht in Deutschland, wo wie in so manchen IT-nahen Belangen die Uhr ca. 4-5 Jahre nachgeht.
Zunächst klingt RPA nach einem sehr technischen, geradezu "IT-nerdigen" Thema, das man doch getrost den Programmierern und IT-Servicekräften zur Erledigung überlassen könnte. Warum sollte das überhaupt ein Change-Thema sein? Dafür gibt es gleich mehrere Gründe!
Fangen wird mit dem ersten, dem eigentlich naheliegendstem an: RPA ist eine Lösung, deren einziger Zweck es ist, IT-anwendungsunterstützte Geschäftsprozesse anwendungsübergreifend zu automatisieren und Datenverarbeitung und Datenströme von einem Prozessschritt in den nächsten und weitere folgende zu bringen - und das ohne dass ein Sachbearbeiter selber "in die Tasten hauen muss". Das klingt zunächst recht simpel - Softwareroboter, also allgemein Maschinen, kennen weder Ermüdung, noch Langeweile, noch Tippfehler. Und bei reinen Datenverarbeitungs- und Datenbewegungsaufgaben sind sie unvergleichlich schneller und fehlerunanfälliger als menschliche Gehirne.
Kommen wir hiermit zum ersten großen Haken an der ganzen Sache: Softwareroboter sind genau genommen dumm, denn sie wissen und können exakt und genau nur das, was man ihnen haarklein einprogrammiert hat. Triviales Beispiel: nehmen wir einmal an, in einem Onlineshop gibt es ein neues Produkt, und ein Roboter, der dieses Produkt noch nicht kennt, soll eine automatische Bestellannahme und -ausführung per Email übernehmen. Er wird das schlicht nicht können, wenn er keine Information zu diesem neuen Produkt erhalten hat, weil es zum Beispiel in der Datenbank mit den Produktstammdatensätzen noch nicht eingepflegt wurde. Der Softwareroboter bricht den Prozess also ab. Im besten Fall erfahren der bestellende Kunde bzw. ein Kundenbetreuer davon. Unterm Strich wäre der Mensch anders vorgegangen: komisch, das Produkt kenne ich nicht? Aber kann ja etwas Neues sein, dann frage ich mal bei XY nach etc. Der Bestellprozess wäre wahrscheinlich nicht einfach abgebrochen worden.
Ich möchte darauf hinaus, dass Softwareroboter, so wie eigentlich alle "unintelligenten" Maschinen nicht flexibel reagieren können, wenn sich an den Rahmenbedingungen, den Arbeitsinhalten, den Prozessparameter etc. etwas verändert. Wie schaut jedoch die gelebte Praxis in den meisten Unternehmen heute aus? Geschäftsprozesse erfordern stets das Mitdenken der Handelnden, egal ob Autos, Versicherungen oder Kilowattstunden verkauft werden. Der Grund ist, dass sich die Wirklichkeit in einem Unternehmen ständig verändert. Neue Kunden, neue Projekte, neue Lieferanten, neue Produkte, neue Gesetze, neue Wettbewerber, neue Qualitätserfordernisse… die Liste könnte man lange noch fortsetzen. Bei jeder dieser Änderungen muss, sobald ein Softwareroboter unterstützt, dieser von den Änderungen neu in Kenntnis gesetzt werden. Er denkt ja schließlich nicht mit.
Das erfordert schlussendlich, dass auch ein moderner Softwareroboter in der Wartung, Pflege und Weiterentwicklung seiner Fähigkeiten NICHT von einem externen Serviceanbieter, und auch NICHT von der internen IT-Abteilung betreut werden kann - sondern ausschließlich unter der Verantwortung und Leitung desjenigen Fachbereichs, den er unterstützt. Nur dieser Fachbereich kennt die Geschäftslogik (siehe unten: RPA-Fünf-Layer-Modell, Layer 5), die erforderlichen Anpassungen und die neuen Informationen, die der Softwareroboter verstehen und verarbeiten können muss. Das bedeutet nicht, dass die Fachabteilung selber programmieren lernen muss - wohl aber muss sie in die Lage versetzt werden, die Änderungen am Roboter anzustoßen, zu koordinieren und ihre vollständige und korrekte Umsetzung zu überprüfen.
Wenn DAS kein Change zu bisherigen Prozessautomatisierungen ist! Die Auswirkungen gehen weit über das Anpassen von einer Datenschnittstelle hinaus, wenn es mal ein neues Feld im Datensatz zu verarbeiten gab… Fachbereiche brauchen erweiterte Kompetenzen und IT-Service-/-Organisationswissen, das weit über eine "Fachbereich = Servicekonsument"-Haltung hinausgeht. Sie müssen für die geschäftstüchtige Funktion der Softwareroboter die ökonomische Verantwortung übernehmen, mit allen ihren Konsequenzen. Die meisten Fachabteilungen, die ich in der erst- oder gar zweitjährigen Konfrontation mit RPA erlebt habe, waren dazu nicht mal ansatzweise im Stande. Change benötigt nach meiner Einschätzung in diesem Fall eher 3-4 Jahre, wenn er gut erkannt, gesteuert und verankert wird.
Aber es gibt noch einen zweiten Grund, warum RPA ein Change-Thema ist. Nicht nur in den Fachbereichen werden völlig andere Verantwortlichkeiten, Kompetenzen und Fähigkeiten benötigt, sondern auch in der IT-Organisation. Der Hintergrund an dieser Stelle ist, dass das traditionelle Betriebsmodell (Service Operation Model) nicht greift. Softwareroboter sind, wie oben beschrieben wurde, einer ständigen Betreuung zur Anpassung und Erweiterung unterworfen. Genaugenommen verlassen die meisten Softwareroboter nie ihr Beta-Stadium. Vom glasklaren, reifegradorientierten Übergang von der Design-/Entwicklungsphase, über eine Test- und Abnahmephase hinein in eine Deployment- und schlussendlich stabile Betriebsphase kann hier KEINE Rede sein.
Alle Unternehmen die ich kennenlernen durfte, die den etablierten Applikationslebenszyklus und das damit verbundene stabilitätsorientiere Service-Betriebsmodell für Softwareroboter verwendet haben, sind damit spätestens nach der RPA-Pilotphase gescheitert. Doch warum?
Das liegt, kurz gesagt, daran, dass ein Softwareroboter sich ständig verändern muss, das aber weder selber kann, noch kann es der Fachbereich alleine bewerkstelligen, noch kann es die IT-Abteilung, noch kann es ein externer Serviceanbieter. Es braucht stets und immer alle genannten Beteiligten. Kann man bei einem Softwareroboter, der mit sich ändernden Geschäftsdaten hantieren soll, ernsthaft von einem eingeschwungenen, stabilen Zustand sprechen, so wie man es von einem SAP Hauptbuch, oder von einem Warenwirtschaftssystem irgendwann kenn? Eher ein. Daher scheitert auch jedes reifegradorientierte Service-Lebenszyklusmodell. Doch was statt dessen zu tun? Ganz einfach: alles "im Fluss halten".
Neben agilen Vorgehensmodellen im Software-Engineering existiert mit DevOps (siehe https://de.wikipedia.org/wiki/DevOps) auch ein Verfahrens-Ansatz (ich möchte nicht von Modell sprechen, dafür ist es zu generisch), der darauf basiert, dass es keinen endgültigen, eingeschwungenen Zustand im Betrieb einer Softwarelösung gibt. Vielmehr sind Bestandteile oder Komponenten der Lösung in permanenter Veränderung. Die Lösung dieses Problems besteht in der prozessualen und organisatorischen Vermeidung der bisherigen "Chinese Walls" zwischen den Entwicklungs- und den Betriebsteams. Betrieb und Entwicklung müssen nach DevOps eng verzahnt arbeiten, und in kontinuierliches Flussmodell aus Anforderungsdefinition/Veränderung, Implementierung, Verfügbarmachung und Betrieb eintauchen. Wer da noch versucht, mit einem Ticketsystem wie Service Now (SNOW) zu arbeiten, wird sicher nicht die erforderliche Agilität, Geschwindigkeit und Verzahnung erreichen.
Zusammengefasst stehen Unternehmen, die RPA breit ausrollen möchten, vor zwei großen Herausforderungen, die mit Paradigmenwechseln bei den beteiligten Stakeholdern einhergehen, und deswegen als waschechte Change-Vorhaben einzustufen sind: einerseits sind die Fachabteilungen in den Geschäftsbereichen aufgefordert, fachlich-kommerzielle Verantwortung für die Softwareroboter zu übernehmen, und dafür gerade zu stehen, dass die Roboter stehts den Geschäftsanforderungen gemäß funktionieren können. Andererseits sind die traditionell im Softwarelebenszyklus von Großapplikationen arbeiteten IT-Bereiche gefordert, die bisherigen Grenzen zwischen Entwicklung und Betrieb aufzugeben und die Prozesse in einem kontinuierlichen Veränderungs-Flussmodell zu integrieren.
Für weitere Informationen, Kontaktaufnahme, Diskussion oder Unterstützung stehe ich als Ansprechpartner unter www.claus-boche.de gerne zur Verfügung.