In diesem Interview beleuchtet Abid Mustafa, Leiter der Abteilung Business Cognition and Excellence bei Etisalat, die Robotic Process Automation und erklärt, was sie ist, wie sie eingesetzt werden kann und welchen Einfluss sie auf die Geschäftswelt haben kann. Er erklärt auch, was Führungskräfte über RPA und ihre geschäftlichen Bemühungen wissen sollten, sowie die Details der Erstellung eines Business Case auf Basis von RPA.
Abid Mustafa ist spezialisiert auf RPA, Robotik und künstliche Intelligenz. Er leitet den Bereich Business Cognition and Excellence bei Etisalat, einem führenden Telekommunikationsanbieter in der MENA-Region.
Detecon: Herr Mustafa, als Leiter des Bereichs Business Cognition and Excellence bei Etisalat verfügen Sie sicherlich über eine Menge Fachwissen rund um das Thema Robotik und wie Sie vielleicht wissen, gibt es eine Menge Verwirrung um den Begriff RPA. Könnten Sie diese Verwirrung aus Ihrer Sicht aufklären?
Abid Mustafa: Sicher, es besteht kaum ein Zweifel daran, dass Robotics Processes Automation (RPA) unter technisch versierten Menschen extrem beliebt ist. Außerhalb des Technologiebereichs tun sich Geschäftsanwender jedoch oft schwer, RPA und seine Anwendbarkeit zur Lösung von Geschäftsproblemen zu verstehen.
Meiner Meinung nach gibt es drei Hauptgründe für diese Verwirrung:
Der erste Grund ist, dass RPA in den IT-Abteilungen beginnt.
Wenn es um die Implementierung von RPA geht, ist der klassische Ansatz, dass die IT-Abteilung die Führung übernimmt, während die Fachanwender wenig mit der Technologie in Berührung kommen - im Sinne von Entwicklung und damit tiefem Verständnis. Der Mangel an Vertrautheit verstärkt die Wahrnehmung, dass RPA ähnlich wie andere Automatisierungstools und -lösungen ausschließlich der IT-Abteilung vorbehalten ist. In der Folge sinkt der Druck auf die Fachanwender, RPA zu erkunden und zu erlernen, dramatisch. Dies wird noch verstärkt durch die Unfähigkeit der Technologen, die Vorteile von RPA effektiv zu artikulieren und zu erklären, wie sie sich von der Systemautomatisierung unterscheidet, was uns zum zweiten Punkt führt:
Der zweite Grund ist, dass Geschäftsanwender den Unterschied zwischen RPA und Systemautomatisierung nicht verstehen.
Es mangelt an direkter Interaktion mit RPA, was dazu führt, dass Geschäftsanwender den Unterschied zwischen dieser und der Systemautomatisierung nicht verstehen. Für viele Geschäftsanwender ist RPA Systemautomatisierung und das bedeutet typischerweise, dass die Anwender Geschäftsanforderungen spezifizieren müssen, diese bei der IT einreichen und, wenn man "Glück" hat, wird die RPA-Lösung geliefert. Um einen breiteren Kontext zu geben: RPA wurde entwickelt, um die Verzögerungen im konventionellen SDLC (Software Development Life Cycle) zu überwinden - von der Erfassung der Geschäftsanforderungen bis zum Design und der Entwicklung der Lösung durch die IT. Das liegt daran, dass RPA im Gegensatz zur Systemautomatisierung nur mit der Benutzerebene arbeitet und menschliches Verhalten wie Navigation, Ausschneiden und Einfügen, Dateneingabe, Datenextraktion und so weiter nachahmt. Zur Erleichterung können Sie einen Blick auf diese Illustration (Abbildung 1.0) werfen, die die Unterschiede zwischen RPA und Systemautomatisierung hervorhebt und auch die Einschränkungen von RPA aufzeigt - die durch eine Kombination aus Künstlicher Intelligenz (KI) und RPA überwunden werden können.
Aus Erfahrung kann ich sagen, dass es für Geschäftsanwender sehr einfach ist, die Anwendbarkeit der RPA-Technologie zu verstehen, sobald sie in der Lage sind, diese Realität zu begreifen. Außerdem ist die Technologie einfach zu bedienen, und das macht die Fachanwender extrem versiert bei der Erstellung von Anwendungsfällen. Ja, IT-Entwickler werden immer noch benötigt, aber eingeschaltete Geschäftsanwender, die zahlreiche Anwendungsfälle identifizieren, helfen bei der Annahme der RPA-Technologie und beim Einsatz von Software-Robotern.
Und schließlich ist der dritte Grund, dass RPA nicht nur in der IT beginnt, sondern auch dort bleibt.
Diese Tatsache schreckt viele Fachanwender davon ab, die Technologie anzunehmen. Die Gefahr einer solchen organisatorischen Trägheit, die durch die Angst vor "Robotern, die Arbeitsplätze ersetzen" geschürt wird, wird jede RPA-Implementierung zum Scheitern bringen. Daher ist es für die RPA-Verantwortlichen unerlässlich, die permanenten Barrieren zwischen Fachanwendern und ihren Technologiepartnern zu überwinden. Das Aufbrechen von organisatorischen Silos und die effektive Kommunikation der Vorteile von RPA an die Fachanwender sollte zur Hauptaufgabe der IT-Abteilungen werden.
Das ist eine wirklich aufschlussreiche Analyse. Was würden Sie Unternehmen raten, um diese Trugschlüsse zu vermeiden?
Nun, kurz gesagt, RPA-Implementierungen haben eine gute Chance auf Erfolg, wenn Geschäftsanwender über RPA aufgeklärt werden, die Vorteile verstehen und die Möglichkeit haben, mit der Technologie herumzuspielen. Der letzte Punkt ist besonders relevant, da er den Geschäftsanwendern die Möglichkeit bietet, den Unterschied zwischen RPA und Systemautomatisierung zu erkennen und die Leichtigkeit zu verstehen, mit der die Technologie eingesetzt werden kann. Folglich obliegt es den Führungskräften, die CIOs zu ermutigen, die Kontrolle über RPA abzugeben und sie den Geschäftsanwendern zu überlassen. Auf diese Weise werden RPA-Anwendungsfälle, die von Geschäftsanwendern getrieben werden, eine goldene Periode des RPA-Erfolgs einleiten und die Investition in die Technologie lohnenswert machen. Langfristig sollte natürlich ein Robotics Centre of Excellence (RCoE) das Streckziel sein, um die interne Interaktion zwischen Unternehmen und Technologie zu erleichtern.
Apropos RCoE's und da Sie ein Excellence Center bei Etisalat leiten, können Sie uns einen Überblick darüber geben, wie ein solches Vorhaben realisiert werden könnte?
Auch hier kann ich aus Erfahrung sagen, dass die Gründung eines RCoE eine gewaltige Aufgabe sein kann, wenn man alle Formalitäten und Rahmenbedingungen für die Gründung eines solchen Zentrums außer Acht lässt. Da es sich um ein digitales Zentrum handelt, liegt der Fokus allzu oft auf den falschen Dingen, nämlich auf Ressourcen und Werkzeugen, wo der Fokus auf dem Prozess liegen sollte, da Werkzeuge und Ressourcen reichlich vorhanden und wirklich gut sind. Kurzum, man muss das Rad nicht neu erfinden. Größere Unternehmen tendieren zu einem föderierten Modell von RCoEs - das sind verteilte Zentren für Robotik-Exzellenz, die in Geschäftsfunktionen wie Finanzen, HR, Betrieb usw. eingerichtet werden -, bei denen die IT die Kontrolle über die Aufzeichnung abgibt, aber das Primat über die Orchestrierung behält. Letzteres dient dazu, die Sicherheit aller eingesetzten Software-Roboter zu wahren und die Lizenzkosten gering zu halten. Unabhängig vom RCoE-Modell, das von Unternehmen gewählt wird, ist es jedoch immer notwendig, einen Schritt zurückzutreten und das Gesamtbild zu betrachten, bevor man sich auf die Reise der Robotik-Prozessautomatisierung (RPA) begibt.
Was meinen Sie damit, einen Schritt zurückzutreten?
Kurz gesagt: Geschäftsanwender besitzen reichlich Einfallsreichtum, um Software-Roboter zu nutzen, um menschliche Schnittstellenaufgaben durch Maschinen zu ersetzen, und man sollte ihnen erlauben, so schnell wie möglich zu experimentieren. Allerdings haben sie eine unheimliche Fähigkeit, notwendige Prozessänderungen zu vermeiden, die mit dieser Transformation einhergehen. Das ist gefährlich, denn wenn Prozesse unverändert gelassen werden, kommt eine zusätzliche Komplexitätsschicht hinzu, die RPA-Lösungen auf lange Sicht schwerfälliger in der Anwendung macht. Man könnte es zum Beispiel damit vergleichen, dass man beim Autofahren eine Abkürzung nimmt, nur um dann festzustellen, dass die Straße gerade gewartet wird, eine Situation, die tatsächlich zusätzliche Zeit für die Fahrt bedeutet.
Ein weiterer Aspekt ist die Tatsache, dass der Versuch, die Pläne zur Systemautomatisierung, die die meisten größeren Unternehmen haben, zu umgehen, auch Risiken birgt. Es gibt wenig Anzeichen dafür, dass der Software Development Life Cycle (SDLC) bald verschwinden wird. Der SDLC wird zwar als umständlich und langsam wahrgenommen, leistet aber einen wichtigen Dienst für die Geschäftsanwender, indem er Lösungen liefert, die den Umfang und das Ausmaß der kollektiven manuellen Aufgaben reduzieren.
Darüber hinaus kann SDLC in einigen Fällen auch mühsame Aufgaben ganz eliminieren, wenn es richtig implementiert wird. Daher ist es für Geschäftsanwender wichtig, sich über neue Systemfunktionen bewusst zu sein, die wahrscheinlich die Software-Roboter überflüssig machen.
Kurz gesagt, die richtige Balance aus dem Einsatz von RPA zur Lösung unmittelbarer geschäftlicher Herausforderungen, die schwere manuelle Aufgaben über mehrere Systeme hinweg erfordern, kann Abteilungen helfen, bis SDLC die richtige Lösung liefern kann, um solche Roboter in den Ruhestand zu schicken oder sie in anderen Bereichen einzusetzen.
Da wir gerade über Automatisierung und RPA gesprochen haben, könnten Sie mehr Licht auf die Art und Weise werfen, wie sie zusammenarbeiten bzw. nicht zusammenarbeiten?
Zum Beispiel ist es üblich, dass RPA-Lösungen in Bereichen eingesetzt werden, in denen Benutzer zwischen mehreren Bildschirmen navigieren müssen. Das macht durchaus Sinn, wenn eine Unified-Desktop-Lösung nicht in der Automatisierungspipeline ist. Wenn dies jedoch der Fall ist, müssen die Vorteile des RPA-Einsatzes gegenüber der Systemautomatisierung sorgfältig abgewogen werden. Auf der Suche nach schnellen Workarounds für komplexe Geschäftsprozesse sollten sich Anwender zweimal überlegen, ob sie sich mit RPA das Leben leichter machen wollen. Jede geplante Systemautomatisierung wird nicht nur Software-Roboter töten, sondern auch die durch Effizienzgewinne erzielten Einsparungen aufzehren.
Vor dem Hintergrund, dass sich Unternehmen bei der Automatisierung stark auf die IT verlassen, könnten einige argumentieren, dass die RPA-Technologie ein kompletter Game Changer ist. Was sind Ihre Gedanken dazu?
Viel zu lange waren Unternehmen bei der Automatisierung auf die Gnade der IT angewiesen. Die Reife der RPA-Technologie hat die Fachanwender emanzipiert und sie weniger abhängig von der IT gemacht. Dennoch bedeutet dies nicht, dass Fachanwender freie Hand haben oder eine unverantwortliche Haltung gegenüber RPA einnehmen können. Jede Rücksichtslosigkeit wird dem CIO garantiert mehrere Ausreden liefern - Doppelarbeit, Verschwendung von Ressourcen und Zeit sowie erhöhte Kosten -, um unseriösen RPA-Praktiken Einhalt zu gebieten. Es wäre sehr schade, wenn ein solches Verhalten dazu führen würde, dass Fachanwender die Kontrolle über RPA verlieren und wieder völlig von der IT abhängig werden.
Um noch einen Schritt weiter zu gehen: Wie gehen die Unternehmen derzeit mit RPA um?
Glücklicherweise veranlasst die wachsende Popularität von RPA die Unternehmen dazu, die Technologie ernster zu nehmen. Das bedeutet, dass Unternehmen den gesamten Return on Investment (RoI) verstehen wollen, wenn sie RPA einführen.
In der Folge muss auf der Ebene der Geschäftsanwender jede RPA-Anfrage durch einen Business Case gerechtfertigt werden. Dies ist ein kniffliges Thema, da der Business Case grundlegend davon abhängt, wie das Unternehmen seine internen Kostenstrukturen aufgebaut hat. In kleinen Unternehmen sind sowohl die Investitions- als auch die Betriebskosten (Capex und Opex), die mit RPA verbunden sind, in einer einzigen Abteilung wie der IT angesiedelt.
In großen Unternehmen hingegen liegen die Investitionskosten in der Regel bei einer einzigen Abteilung - vor allem der IT -, während die Betriebskosten für die RPA-Implementierung auf mehrere Abteilungen wie Business Ops, HR, Finanzen, IT und andere verteilt sind. Um die Sache noch komplizierter zu machen, wird die Steuerung des Business Case zur Freigabe von Budgets zur Unterstützung der RPA-Entwicklung hauptsächlich von der Finanzabteilung übernommen. Daher ist der komplette Business Case für die RPA-Implementierung eine Summierung von Business Cases auf der Nachfrageseite und der Angebotsseite. Mit einer Vielzahl von Stakeholdern, die in den Business Case involviert sind, ist es wichtig, ein klares Bild über den Business Case, der mit jeder RPA-Anfrage eingereicht wird, den gesamten Governance-Prozess und die Kosten, die in jeder Phase anfallen, zu erstellen.
In solchen Organisationen werden die mit der RPA-Implementierung verbundenen Kosten auf der Angebotsseite nicht berücksichtigt. Dies beinhaltet in der Regel eine Reduzierung der budgetierten Opex, um entweder RPA-Anwendungsfälle zu unterstützen oder Investitionen in die Einrichtung von RCoE zu rechtfertigen. Wenn kein zusätzliches Opex-Budget zur Verfügung steht, untermauern FTE-Einsparungen (Reduzierung von Vollzeit- und Vertragsmitarbeitern) die Machbarkeit beider Szenarien.
Aus reiner Neugier, welche Prozesse würden sich am besten für eine robotergestützte Automatisierung eignen?
Die besten Kandidaten für RPA-Bedarfsanfragen sind Prozesse oder Aufgaben, die ein hohes Volumen aufweisen, eine lange Bearbeitungszeit haben und "dumm" sind, d. h. einen geringen intellektuellen Gehalt haben, der nicht zu viel menschliches Eingreifen erfordert, und einfach auszuführen sind. Es kommt jedoch häufig vor, dass sich einige Aufgaben nicht für RPA eignen. Ein Prozess hat viele Aktivitäten und jede Aktivität kann weiter in eine Anzahl von Aufgaben zerlegt werden (siehe Grafiken unten - Abbildung 2.0). Zum Beispiel könnten bei einer bestimmten Aktivität nur 60 % für eine RPA-Implementierung geeignet sein.
Nachdem wir nun wissen, welche Prozesse mit RPA automatisiert werden könnten, zurück zum Business Case: Welche Details sollte man im Blick behalten, wenn man einen soliden Business Case entwickeln will?
Nun, nach der Definition der Zielprozesse, die automatisiert werden sollen, und der Prüfung, ob dies machbar ist oder nicht, besteht der nächste logische Schritt - der von vielen Unternehmen übersehen wird - darin, Parameter zu definieren, die bei der Berechnung der Einsparungen helfen können.
Parameter wie das Transaktionsvolumen (VoT), die durchschnittlichen Bearbeitungszeiten (AHT) und die FTE-Kosten sollten zu den Grundbestandteilen des Business Case werden. Weitere Parameter sind die Fehlerrate (ER) - wie viele Transaktionen der Roboter nicht bewältigen kann - und die Zeit, die für die Konfiguration des Roboters nach dem Einsatz aufgewendet wird. Wir könnten die Definition von Parametern für Business Cases noch weiter ausführen, aber das ist ein ganz eigenes Thema für sich.
Nachdem man also die oben genannten Parameter definiert hat, ist man in der Lage, einen Geschäftsfall zu entwerfen. Um die Feinheiten eines RPA-Business Use Cases zu verdeutlichen, nehmen wir ein fiktives Beispiel: Ein Telekommunikationsunternehmen bearbeitet jährlich 200.000 komplexe Geschäftsbeschwerden mit 100 Vollzeitkräften. Die Bearbeitung jeder Beschwerde dauert durchschnittlich eine Stunde. Hier ist eine Tabelle (siehe unten - Abbildung 3.0), die erklärt, was passiert, wenn die RPA-Technologie eingeführt wird. In Szenario A ist RPA nur für 60 % der VoT wirksam und schafft es immer noch, bei 10 % der Beschwerden zu versagen. Es gibt keine Reduzierung der AHT, und die Anzahl der eingesparten Stunden beträgt 108.000, was 54 FTEs entspricht.
In Szenario B verbessert sich die Leistung von RPA, was zu einer Einsparung von 158.400 Stunden führt. Dies entspricht 79 FTEs. Dennoch bleibt die AHT gleich. Bei Szenario C sinkt die AHT auf 5 Minuten, die Anzahl der eingesparten Stunden beträgt 13.333, was etwa 7 VZÄ entspricht. In diesem Szenario ist die Anzahl der eingesparten Stunden irreführend, da bereits 79 VZÄ aus Szenario B als Einsparung vorgesehen sind.
Daher werden andere Parameter wie Kundenzufriedenheit und Genauigkeit benötigt, um die Gesamtleistung von RPA zu bewerten. Obwohl die AHT in Szenario C um 55 Minuten gesenkt wurde, werden für die Bearbeitung von 41.600 Beschwerden immer noch 21 Vollzeitäquivalente benötigt (wobei die AHT weiterhin 1 Stunde beträgt und zusätzlich ermittelt werden muss, warum 1600 Beschwerden fehlgeschlagen sind).
Haben Sie abschließend noch irgendwelche Gedanken zu anderen Anforderungen in Bezug auf die Kosten bei der Implementierung von RPA, um einen Business Case zu entwickeln?
Die Kosten der RPA-Implementierung müssen addiert werden, bevor der Business Case Sinn macht. Dazu gehören die einmaligen Einrichtungskosten der RPA-Plattform (Capex) und ein jährlicher Opex, der Lizenzgebühren, Kosten für professionelle Dienstleistungen und die Kosten für Entwickler (eigene FTEs) umfasst. Der komplette Business Case setzt sich dann aus dem Geschäftsbedarf für RPA und den IT-Kosten für die RPA-Implementierung zusammen.
Kurz gesagt, die Entwicklung von Business Cases für die RPA-Implementierung ist abhängig von den internen Kostenstrukturen des Unternehmens. Damit RCoEs bei der Ausarbeitung von Business Cases effektiv sein können, müssen sie mit verschiedenen Stakeholdern zusammenarbeiten und sich der IT-Kosten bewusst sein, die mit der RPA-Nachfrage verbunden sind.
Herr Mustafa, wir danken Ihnen für Ihre Zeit und die interessanten Einblicke in RPA und wünschen Ihnen viel Erfolg bei der Implementierung von RPA in Ihrem Unternehmen, um möglicherweise Einsparungen zu erzielen und die Geschäftsbereiche effizienter arbeiten zu lassen.
