5. Anwendung von Robotic Process Automation

Neben dem Einstieg in alternative und intelligente Technologien der Prozessautomatisierung oder dem Anstoß für den digitalen Wandel verspricht RPA ein vielfältiges Nutzenpotenzial. So werden in der Literatur quantitative und qualitative Vorteile genannt. Demnach erlaubt der Einsatz von RPA eine Reduktion der operativen Kosten. Der Grund liegt darin, dass durch die Automatisierung von manuellen Tätigkeiten Vollzeitäquivalente (VZÄ) und damit Personalkosten reduziert werden können. So zeigen Horton (2015, S. 6), das Institute for Robotic Process Automation (IRPA) (2015, S. 10) und Allweyer (2016, S. 5), dass durch einen Softwareroboter rund 90 % einer Onshore-VZÄ in Mitteleuropa und zwischen 30–50 % einer Offshore-VZÄ eingespart werden können. Damit ist der Einsatz von RPA kosteneffizienter als ein Offshore-Shared Services Center (SSC) (PwC 2018). Im Weiteren zeigt die Studie von Ostrowicz (2018, S. 6), dass bei den befragten Unternehmen, infolge der Technologie um RPA, in fünf Jahren generell eine VZÄ-Reduktion von 11 % und in zehn Jahren eine Reduktion von 18 % erwartet wird. Ein weiterer Faktor, der zur Reduktion der Kosten beiträgt, ist die Integrationsform der RPA-Technologie. Dadurch, dass die Softwareroboter über die Benutzeroberfläche existierender Systeme agieren, ist kein Eingriff an diesen Systemen nötig, um die angestrebte Automatisierung zu realisieren. Im Gegensatz dazu entstehen bei den traditionellen Ansätzen an den Enterprise-Resource-Planning (ERP)- oder Business-Process-Management-Systemen (BPMS) in der Regel umfangreiche Programmieraufwände (Allweyer 2016, S. 5). Ergänzend dazu entfällt nach Czarnecki und Auth (2018, S. 118) bei RPA die aufwendige Abstimmung zwischen fachlichen Anforderungen und technischen Rahmenbedingungen, da die Automatisierung direkt durch den Fachbereich erfolgt. Infolge der genannten Punkte kann bei RPA-Vorhaben im Normalfall eine hohe Rentabilität ausgewiesen werden. So zeigen insbesondere die Fallstudien von Willcocks et al. (2015, S. 18), dass sich die Kennzahl Return on Investment (ROI) zwischen 200 % (in einem Jahr) und 800 % (in drei Jahren) bewegen kann. Zudem unterstreichen auch die Angaben von PwC (2018) eine zeitnahe Amortisationszeit, welche im Durchschnitt ein bis zwei Jahre beträgt.

Ein zusätzlicher quantitativer Nutzen adressiert die Verringerung der Durchlaufzeit auf Basis einer Effizienzsteigerung. So ermöglicht der Einsatz von RPA entweder die Erledigung vom gleichen Arbeitsvolumen in weniger Zeit oder die Erhöhung des Arbeitsvolumens in der gleichen Zeit. Dazu kommt, dass die Softwareroboter während sieben Tagen in der Woche jeweils 24 Stunden eingesetzt werden können (IRPA 2015, S. 12; Allweyer 2016, S. 5). Die Effizienzsteigerung steht wiederum im direkten Zusammenhang mit den qualitativen Vorteilen. Diese zeigen sich in einer Erhöhung der Qualität selbst, welche darauf zurückzuführen ist, dass menschliche Verarbeitungsfehler verhindert werden können. Sofern der Roboter korrekt konfiguriert wurde, arbeitet dieser exakt nach den definierten Regeln und erfährt keine Ablenkung oder Müdigkeitserscheinungen. In diesem Kontext sind ebenfalls die Skalierbarkeit und Flexibilität zu erwähnen. Ist ein Prozess oder Prozessschritt einmal konfiguriert, lässt sich die Anzahl der Roboter flexibel an ein steigendes oder sinkendes Arbeitsvolumen anpassen (IRPA 2015, S. 13; Allweyer 2016, S. 5; Reich und Braasch 2019, S. 296; Lowers et al. 2016, S. 6). Weitere qualitative Nutzenpotenziale bilden die Sicherstellung der Compliance sowie allgemein das Monitoring. Da die RPA-Software die Aktivitäten regelbasiert ausführt, werden sämtliche Aktionen in einem Protokoll dokumentiert. Dies trägt sowohl zur Einhaltung der regulatorischen Vorschriften, als auch zu einer vereinfachten Auditierung bei (IRPA 2015, S. 12; Reich und Braasch 2019, S. 296). Ergänzend dazu bilden diese Daten die Grundlage für die laufende Prozessüberwachung und liefern Ansätze zur weiteren Optimierung (Allweyer 2016, S. 5; Lowers et al. 2016, S. 6).

Da es sich bei den automatisierten Tätigkeiten in der Regel um eher einfache Routinearbeiten handelt, welche bisher manuell ausgeführt werden mussten, bringt RPA gegenüber den betroffenen Mitarbeitenden eine Entlastung. Dadurch können sich diese auf Aufgaben mit einer größeren Wertschöpfung konzentrieren, was sich einerseits in einer gesteigerten Motivation und andererseits in einer höheren Produktivität widerspiegelt (IRPA 2015, S. 12 f.; Allweyer 2016, S. 6; Lowers et al. 2016, S. 6). Durch die Kombination des angeführten Nutzenpotenzials, namentlich durch kürzere Durchlaufzeiten, einer tieferen Fehlerquote sowie einer höheren Motivation und Produktivität der Mitarbeitenden, kann letztendlich auch eine gesteigerte Kundenzufriedenheit realisiert werden (IRPA 2015, S. 13). Abschließend ist die vielfältige Einsetzbarkeit von RPA zu erwähnen, da die Technologie ein breites Anwendungsgebiet umspannt. So können die Softwareroboter zahlreiche Aktivitäten innerhalb eines Prozesses übernehmen, was die Anwendung in verschiedenen Fachbereichen, Funktionen und Branchen erlaubt (IRPA 2015, S. 15). Hinsichtlich Kritikpunkten lassen sich nur spärliche Informationen finden. Asatiani und Penttinen (2016, S. 4) halten diesbezüglich fest, dass RPA lediglich als Übergangslösung zu betrachten ist, bis eine Lösung mit integrierten, traditionellen Anwendungssystemen möglich und wirtschaftlich sinnvoll ist. Im Weiteren ist die Technologie nicht für Prozesse einsetzbar, die menschliches Urteilsvermögen verlangen, was das Anwendungsfeld doch einschränkt. Außerdem kann die Einführung von Softwarerobotern bei Mitarbeitenden Bedenken und Ängste auslösen, die sich negativ auf die gesamte Unternehmung auswirken. Schließlich fallen die empirischen Befunde und Erkenntnisse über das realisierte Nutzenpotenzial gegenwärtig noch gering aus. So muss sich zuerst zeigen, ob sich die Vorteile in erwartetem Ausmaß bestätigen.

Unter Bezugnahme der beschriebenen Merkmale ist RPA für manuelle, regelbasierte und wiederkehrende Prozesse oder Prozessschritte geeignet. Weitere Punkte bilden ein entsprechend hohes Volumen und die Nutzung von verschiedenen, nicht integrierten Systemen. Bezogen auf Letztere sind ebenfalls das Vorliegen digitaler Daten sowie eine stabile Systemumgebung wichtig. Schließlich werden die Anfälligkeit für menschliche Fehler, der Zeitdruck sowie eine transparente Übersicht der aktuellen Prozesskosten genannt (Asatiani und Penttinen 2016, S. 5 f.; Deloitte 2019); Willcocks et al. (2015, S. 5) sprechen generell von sogenannten „Drehstuhlprozessen“. So handelt es sich um Prozesse, in welchen die sachbearbeitenden Personen Daten aus einem bestehenden System übernehmen, nach festgelegten Regeln weiterverarbeiten und anschließend in ein anderes System eintragen. Im Weiteren führt Horton (2015, S. 5) den Begriff von transaktionalen Prozessen an. Eine konkrete Definition findet sich bei Dressler (2007, S. 41), welcher unter transaktionalen Tätigkeiten Aktivitäten versteht, die vielfach wiederkehrend und gleichartig sind sowie eine kurze Einarbeitungszeit benötigen. Sie sind dementsprechend ohne Expertenwissen durchführbar. Das Anwendungsgebiet von RPA kann generell wie in Abb. 5.2 abgegrenzt werden.

Der Einsatz von Softwarerobotern macht dort Sinn, wo eine traditionelle Automatisierung (z. B. Schnittstellen) nicht gerechtfertigt ist, allen voran infolge hoher Implementierungskosten. Daneben gibt es Tätigkeiten, die in einem zu geringen Ausmaß auftreten oder Ausnahmefälle bilden. Solche Aktivitäten sind weiterhin durch Menschen zu erledigen, da die Anwendung von RPA nicht genügend Nutzen stiften würde (van der Aalst et al. 2018, S. 270). Ein weiterer Faktor bildet die Strukturiertheit der Prozesse oder der Prozessschritte, die sich auf deren Komplexität auswirkt. Czarnecki und Auth (2018, S. 118) unterscheiden drei Stufen: Routineaufgaben, strukturierte Aufgaben mit regelbasierten Entscheidungen, unstrukturierte Aufgaben und Entscheidungen. Die erste Stufe umfasst einfache Aufgaben, in denen die Sachbearbeitenden Daten aus verschiedenen Systemen kopieren und zusammenführen sowie wieder in unterschiedliche Anwendungen eintragen. In der nächsten Stufe erfolgen zusätzlich regelbasierte Entscheidungen. Die Grundlage entspricht hier der Beschreibung von vorgegebenen Geschäftsregeln, mit denen die strukturierten Daten bewertet und automatisiert werden können. Die dritte Stufe beschreibt schließlich Aktivitäten, bei denen neben Regeln auch zusätzliches Erfahrungswissen nötig ist. Dabei ist für eine Automatisierung solcher Aktivitäten der Einsatz von künstlicher Intelligenz nötig. Die Mehrheit der Softwareroboter, welche gegenwärtig im Einsatz stehen, bearbeiten Aufgaben, die zwischen der ersten und zweiten Stufe liegen (Czarnecki und Auth 2018, S. 18 ff.). In diesem Kontext kann ebenfalls ein Rückschluss auf die vier Ausprägungen der Softwareroboter nach Ostrowicz (2018, S. 3 und 4) erfolgen.

Geeignete Anwendungsfälle, welche die erläuterten Voraussetzungen oder Merkmale erfüllen, lassen sich in verschiedenen Branchen und Funktionen finden. So zeigt sich insbesondere bei Banken, Versicherungsunternehmen, Telekommunikationsanbietern sowie bei Energieversorgern und im Gesundheitswesen erhebliches branchenspezifisches Potenzial. Demgegenüber sind branchenunabhängige Querschnittsfunktionen wie Finanzen, Einkauf, Human Resources oder auch der Vertrieb qualifizierte Kandidaten für den Einsatz von RPA (Scheer 2017, S. 34 f.; Everest Group o. J.; EY 2015, S. 9; Allweyer 2016, S. 4). Weiterführend sind in der Tab. 5.1 eine Auswahl an funktions- und branchenspezifischen Anwendungsfällen aufgeführt.

Die Anwendungsfälle zeigen auf, dass sowohl Aktivitäten aus primären als auch aus sekundären Prozessen mit Softwarerobotern ausgeführt werden können (Czarnecki und Auth 2018, S. 119). Dabei handelt es sich gerade bei den branchenübergreifenden Funktionen häufig um Prozesse, die in einem Backoffice oder in einem Shared Service Center (SSC) ausgeführt werden. In diesem Kontext kann festgehalten werden, dass RPA als Alternative gegenüber dem SSC oder Business Process Outsourcing (BPO) angesehen werden kann. Der Grund liegt im kosteneffizienten Betrieb der Softwareroboter, was bereits im Abschnitt zum Nutzenpotenzial beschrieben wurde (Horton 2015, S. 5; IRPA 2015, S. 14; Allweyer 2016, S. 4; Lowers et al. 2016, S. 4). Weiterführend zeigen verschiedene Studien, dass insbesondere in den Finanzfunktionen ein hohes Automatisierungspotenzial besteht. So legt Horton (2015, S. 4 und 7) dar, dass eine Implementierung der Technologie vordergründig im Bereich der finanziellen Transaktionsprozesse erwartet wird. Im Weiteren erfolgt die Aussage, dass rund 56 % der gegenwärtigen Finanzfunktionen eine hohe Wahrscheinlichkeit für eine Automatisierung aufweisen. Gerade bei Tätigkeiten, die eine Aufbereitung und Abstimmung von Finanzdaten umfassen, wird erhebliches Potenzial unterstellt (EY 2019, S. 6). Daneben verdeutlicht auch die bereits erwähnte Erhebung von Ostrowicz (2018, S. 12), dass mehr als 75 % der befragten Teilnehmenden den Bereichen Financial Accounting und Financial Reporting eine hohe Bedeutung für RPA bescheinigen. Schließlich zeigt auch der Bericht von Kroll et al. (2016, S. 19), dass bereits 25 % der befragten Unternehmen RPA im Bereich Finance und Accounting einsetzen. Darüber hinaus planen 75 % eine Implementierung in diesen Funktionen im Verlauf der nächsten drei bis fünf Jahre.

Empirische Befunde bezüglich der Implementierung und dem anschließenden Betrieb einer RPA-Plattform finden sich hauptsächlich bei den Softwareherstellern und bei Beratungsunternehmen. Daneben können Daten aus bisherigen Fallstudien entnommen werden. Die Implementierungsmodelle zielen im Allgemeinen auf eine zeitnahe Umsetzung eines ersten Anwendungsfalls ab. So erfolgen eine umfassende Potenzialanalyse sowie die Ausgestaltung der weiteren Faktoren erst nach einem Proof of Concept (PoC). Die Vorgehensmodelle von Willcocks et al. (2017, S. 22) und Mindfields (2017, S. 45) verdeutlichen jedoch, dass zu Beginn auch eine umfangreichere Planung möglich ist. Erstere beginnen mit der Evaluation der Plattform und der Erhebung der Prozesse. Danach wird ein Business Case erstellt und das Projekt aufgesetzt, gefolgt vom Aufbau der Infrastruktur und der Schulung der Mitarbeitenden. Erst anschließend folgt schrittweise die Automatisierung der ersten Prozesse, begleitet von laufenden Bestrebungen zur Optimierung. Letztere beginnen mit der Definition einer Automatisierungsstrategie, der Potenzialerhebung und der Erarbeitung des Business Cases. In einer nächsten Phase werden die Prozesse priorisiert sowie die Konsequenzen für die Fachbereiche beurteilt. Danach wird das RPA-Modell evaluiert und die Implementierung geplant. Schließlich erfolgt die Einführung, beginnend mit einem PoC und der rückblickenden Beurteilung der getroffenen Annahmen. Bezüglich der Dauer einer Einführung von RPA finden sich wenige Informationen. Im Fallbeispiel von Willcocks et al. (2017, S. 22) wird die Technologie innerhalb von rund einem Jahr implementiert. Dabei erfolgte während dieser Zeit die Automatisierung von rund zehn Prozessen. Auch Reich und Braasch (2019, S. 297) halten fest, dass RPA-Projekte innerhalb weniger Monate implementiert werden können. Hieran anknüpfend erläutern Schuler und Gehring (2018, S. 1) ebenfalls, dass die Implementierung eines Softwareroboters auf einer bestehenden Plattform im Vergleich zu traditionellen IT-Projekten weniger Zeit benötigt.

Die Eckpunkte des Betriebs von RPA lassen sich anhand eines Operating Models beschreiben. Dessen generische Bestandteile umfassen Strategie und Governance, Struktur, Prozesse, Technologie sowie Ressourcen. Übergeordnet muss einerseits sichergestellt werden, dass die Implementierung von RPA und der daraus erwartete Nutzen zur Umsetzung der Unternehmensstrategie beiträgt. Andererseits müssen im Rahmen der Governance die verantwortlichen Rollen und Gremien sowie geltende Rahmenbedingungen definiert werden. Dazu gehören konkrete Richtlinien für die Qualifizierung und Priorisierung der geeigneten Prozesse sowie Vorgaben für das Design, die Entwicklung und den Betrieb der Softwareroboter. Weitergehend sind Regeln bezüglich der Compliance, der IT-Sicherheit sowie der operationellen Risiken festzuhalten. Schließlich sind im Rahmen der Governance das Changemanagement sowie die Kommunikation unter den Anspruchsgruppen zu definieren. In diesem Zusammenhang adressiert die Governance sowohl Themen aus den operativen Fachbereichen als auch aus der IT-Organisation (Prism 2019; UiPath 2019; Ayasse 2018, S. 29; Perrier 2018).

Bezogen auf die Struktur ist zu definieren, wie RPA in der Aufbauorganisation verankert wird. So ist gemäß Schuler und Gehring (2018, S. 4) zu entscheiden, ob RPA eher in der IT-Organisation oder im operativen Fachbereich angesiedelt wird. Ein weiterer Inhaltspunkt bildet ein Center of Excellence (CoE), welches das Fachwissen innerhalb der Unternehmung konzentriert und verankert. Dieses kann entweder in zentraler, dezentraler oder auch hybrider Form ausgestaltet sein (Perrier 2018). Im Rahmen des Bausteins der Prozesse kann ein generisches Vorgehen zur Prozessautomatisierung mittels RPA verstanden werden. Die Technologie umfasst sowohl die Auswahl der geeigneten RPA-Plattform als auch den Aufbau der IT-Infrastruktur. Nach Allweyer (2016, S. 2) kann in einem einfachen Fall die RPA-Software auf einem lokalen Gerät installiert werden. Die Mitarbeitenden können hier die Aufgaben selbstständig automatisieren und die Roboter individuell einsetzen. Demgegenüber bietet die zentrale Installation einer RPA-Plattform größeres Potenzial und die Möglichkeit, mehrere Roboter einzusetzen. Hinzu kommen eine einfachere Skalierbarkeit und Steuerung sowie die Möglichkeit der laufenden Überwachung. Der letzte Baustein richtet sich schließlich an die personellen Ressourcen. Der Fokus liegt auf den benötigten Fähigkeiten für die Ausführung der definierten Rollen. Konkret stellt sich die Frage, welche Skills benötigt werden und wie die Mitarbeitenden entsprechend geschult resp. trainiert und entwickelt werden können. Daneben muss RPA auch als Unternehmenskompetenz etabliert werden (Blue Prism 2019; UiPath 2019; Ayasse 2018, S. 29; Perrier 2018).

Die Forschungsarbeit wurde in Zusammenarbeit mit der BKW AG (BKW) erstellt. Das international tätige Energie- und Infrastrukturunternehmen mit Sitz in Bern beschäftigt rund 10.000 Mitarbeitende und umfasst ein großes Netzwerk an Firmen und Kompetenzen. Demnach plant, baut und betreibt die BKW-Gruppe Energieproduktions- und Versorgungsinfrastrukturen und bietet digitale Geschäftsmodelle für erneuerbare Energien an. Das Unternehmen hat sich in den letzten Jahren von der klassischen Stromproduzentin zur führenden Energie- und Infrastrukturdienstleisterin entwickelt.

Die Finanzfunktionen der Muttergesellschaft (BKW AG) verteilen sich über die beiden Geschäftsbereiche Finanzen und Dienste (FD) sowie Group Markets und Services (M&S). Der Geschäftsbereich FD stellt die finanzielle Führung sicher und zeichnet sich für die Informatik-, Immobilien- und Versicherungsstrategie sowie den Handel und die berufliche Vorsorge verantwortlich. Der Geschäftsbereich M&S bündelt Kompetenzen in den Bereichen Vertrieb, Marketing, Produkt- und Geschäftsmodellentwicklung, Marktanalyse, Regulierung und Recht. Dazu kommen der Kundenservice sowie die Business Services.

Die treibende Kraft hinter der Implementierung von RPA bildet bei der BKW die Organisationseinheit Controlling, welche im Geschäftsbereich FD angegliedert ist und deren Leiter im Rahmen von Fachkongressen mit der Technologie in Berührung kam. Die Motivation lag in erster Linie darin begründet, dass im Zuge des Projektes Shared Services im Jahr 2016 eine Zentralisierung der Controllingorganisation erfolgte. Damit einhergehend wurden im Laufe der letzten drei Jahre über zehn VZA resp. über 25 % der personellen Ressourcen reduziert. Damit steht das Controlling mit einer kleineren Ressourcenbasis unter einem erhöhten Leistungsdruck. Zudem wurde RPA als Technologieplattform als sehr interessant beurteilt, da sie auch in anderen Fachbereichen oder Konzerngesellschaften potenziell eingesetzt werden kann. So zeigte sich schon im Rahmen eines frühen Austausches innerhalb der BKW, dass auch Prozesse aus dem Bereich Billing und Revenue Management (im Geschäftsbereich M&S angegliedert) mit RPA pragmatisch automatisiert werden können. Der Antrieb lag hier in der gegenwärtigen Digitalisierung der O2C-Prozesse (Order to Cash). Darüber hinaus sehen sich die beiden Organisationen unter anderem durch das akquisitorische Wachstum im Dienstleistungsgeschäft der BKW-Gruppe mit einem steigenden Volumen konfrontiert. Mit dieser Ausgangslage hoben sich folgende Antriebe und Ziele im Zusammenhang mit der Implementierung von RPA hervor: Entlastung und Fokussierung der bestehenden Ressourcen (Fokus Controlling), mit den bestehenden Ressourcen mehr Volumen verarbeiten (Fokus Accounting, Billing und Revenue Management), Konzentration auf wertschöpfende Tätigkeiten und Steigerung der Arbeitszufriedenheit sowie das Sammeln von Erfahrungen mit RPA. Diesbezüglich sollte zudem geprüft werden, ob die Technologie für andere Finanzfunktionen oder Geschäftsbereiche zur Verfügung gestellt werden kann.

So wurde die Implementierung im Rahmen der Initiative „RPA in Finance“ gestartet. Das Team setzte sich aus vier Personen zusammen und wurde zusätzlich extern unterstützt, insbesondere in den Punkten Governance, Selektion und Konfiguration. Weiterführend erstreckten sich die genannten Arbeitspakete über die Phasen, Vorstudie, Pilot Phase 1, Pilot Phase 2 sowie Scale-up, was die Abb. 5.3 illustriert.

Im zeitlichen Ablauf befand sich das Vorhaben bei Eingabe der Forschungsarbeit in der Pilot Phase 2, wobei in der Fallstudie die Ergebnisse der ersten zwei Phasen berücksichtigt wurden. Auf die Erfahrungen nach der Abgabe der Forschungsarbeit wird in Abschn. 5.8 noch näher eingegangen.

Im Rahmen der Vorstudie erfolgte die Initialisierung der Initiative und die Aufsetzung der Strukturen. Dazu gehörten die Zielsetzung sowie die Auswahl der Finanzfunktionen. Daneben bildeten eine Literaturrecherche, eine Vorgehensanalyse sowie die Technologieevaluation mit einer Installation von Testlizenzen weitere Inhaltspunkte. Dazu kamen die Festlegung von Rahmenbedingungen für die Pilotphasen sowie die Kick-off-Veranstaltung für die initiale Prozessidentifikation in den Bereichen Controlling und Revenue Management. Die Vorstudie wurde schließlich mit einer umfassenden Dokumentation beendet, welche die Basis für die Freigabe der Pilotphase 1 durch den CFO bildete.

Die erste Pilotphase umfasste eine Qualifikation und Priorisierung der in der Vorstudie erhobenen Prozesse, was in Form von mehreren Workshops erfolge. Hier wurden vier Anwendungsfälle definiert, die im Rahmen eines PoC in den Pilotphasen 1 und 2 automatisiert wurden, wobei in der ersten Phase bereits ein Prozess mit RPA umgesetzt worden war. Daneben erfolgten die Konzeptionierung der IT-Architektur und Plattform sowie die Freigabe für die Pilotphase 2. In dieser Phase stand die Automatisierung der drei weiteren Anwendungsfälle im PoC im Fokus. Darüber hinaus wurde die Prozessselektion auf die Funktionen Accounting und Tax, Treasury, Corporate Finance und Risk Management ausgeweitet sowie die IT-Infrastruktur und RPA-Plattform institutionalisiert. Daneben erfolgte auch die detaillierte Ausgestaltung des Operating Models und der Governance. Das Ziel am Ende der Pilotphase 2 lag in der Bereitschaft für den Scale-up. So sollten Rahmenbedingungen, die Technologie, das Know-how und eine Liste von geeigneten Prozessen vorhanden sein, um die Technologie in der Aufbauphase in- und außerhalb der Finanzfunktionen voranzutreiben.

Das AP Governance und Operating Model umfasste die Ausgestaltung der Aufbau- und Ablaufstrukturen, welche durch die Implementierung von RPA neu benötigt oder tangiert werden. Zentrale Inhalte bildeten die Organisationsstruktur mit Aufgabenbereichen und Verantwortlichkeiten, der Kompetenzaufbau, die Vorgehensweise in der Prozessauswahl und -priorisierung sowie die Vorgaben zur IT-Plattform. Zusätzlich wurden konkrete Richtlinien zum Ablauf des Automatisierungsprozesses festgehalten. Hierzu gehörten unter anderem Guidelines zur (Prozess-)Dokumentation und Entwicklung der Softwareroboter, ein Berechtigungskonzept oder Vorschriften zu Testverfahren, Freigaben und der Sicherheit. Schließlich sollte ebenfalls das Betriebs- und Wartungsmodell definiert werden. Im Projektstand zum Zeitpunkt der Eingabe wurden diesbezüglich ein Entschluss für die Gestaltung der Aufbaustruktur gefasst sowie erste Rahmenbedingungen für die Pilotphasen ausgearbeitet. Daneben wurde ein Konzept für die IT-Infrastruktur erstellt. Zudem fand laufend ein interner Know-how-Aufbau statt. Insbesondere die ersten beiden Punkte der Organisationsstruktur und Governance werden nachfolgend erläutert.

Demnach erfolgte im Rahmen der Vorstudie eine Auseinandersetzung mit den generischen Modellen eines Centers of Excellence (CoE). Dabei wurde festgehalten, dass in der BKW ein hybrides Modell angestrebt wird. So sollten die oben genannten Themen wie die Governance, der Selektions- und Automatisierungsprozess, die Technologie sowie allgemeine Richtlinien zentral vorgegeben werden. Des Weiteren sollten damit das Know-how sowie ein bereichsübergreifender Erfahrungsaustausch sichergestellt werden. Zudem waren in der designierten Aufbauorganisation dezentrale CoE vorgesehen, die in den jeweiligen Fachbereichen operieren und die Prozessidentifikation sowie die Konfiguration selbstständig vornehmen. Weiter erfolgte der Vorschlag, dass das zentrale CoE in der Controllingorganisation verankert wird. Als Begründung wurden die Drehscheibenfunktion im Konzern und die Kompetenz in den Systemen angeführt. Während des Abschlusses der ersten Pilotphase wurde entschieden, dass das Modell in den Grundzügen wie beschrieben umgesetzt werden sollte, jedoch die Abgrenzung zur IT-Organisation zu klären sei und eine „organische“ Anwendungsausweitung (also keine Anwendung auf Befehl) angestrebt wird. Zudem waren keine voll dezidierten Mitarbeitenden für die Thematik RPA vorgesehen. Hinsichtlich der Rahmenbedingungen für die Automatisierung der vier Anwendungsfälle in den Pilotphasen wurden in der Vorstudie die folgenden Punkte zur Sicherstellung der Governance festgehalten:

Eine umfassende Klärung und Ausgestaltung der Governance erfolgte erst im Rahmen der weiteren Phasen (Pilotphase 2 und Scale-up). Das erwähnte Konzept für die IT-Infrastruktur wird im nachfolgenden Abschnitt erläutert. Der Know-how-Aufbau erfolgte in erster Linie im Austausch mit der externen Unterstützung und wird im Kontext der letzten beiden Arbeitspakete ersichtlich.

Die Inhalte des vorliegenden AP bildeten die Evaluation der Software sowie deren Installation und dem damit einhergehenden Aufbau der IT-Infrastruktur. Dazu kam die Schulung im Zusammenhang mit der gewählten Softwarelösung. Zum Zeitpunkt der Eingabe der Forschungsarbeit wurde die Software festgelegt und das Konzept für die IT-Architektur erstellt. Der effektive Aufbau der RPA-Plattform wurde in der Pilotphase 2 durchgeführt.

Die Evaluation der Software erfolgte bereits während der Vorstudie und war stark durch den Leiter der Initiative geprägt. Maßgebende Faktoren waren die benutzerfreundliche Bedienung, die deutsche Sprache, die Verfügbarkeit des Schweizer Supports, ein differenziertes Lizenzmodell, tiefe Einstiegsbarrieren (Kosten, schnelle Verfügbarkeit, notwendiges technisches Vorwissen), führende Marktpositionierung sowie die Möglichkeit der Konfiguration von „attended“ Robotern. Auf Basis der Evaluation wurde die Software von UiPath für den PoC ausgewählt, ohne damit bereits einen definitiven Softwareentscheid für den Scale-up vorzunehmen. Der Softwarehersteller UiPath bot zudem ein umfangreiches Angebot an Onlineschulungen an, sowohl für Anfängerinnen und Anfänger als auch für Fortgeschrittene, und zum Austausch eine offene Community, was den schnellen, internen Wissensaufbau entscheidend beschleunigte. Das Konzept für die RPA-Technologie und Architektur in der BKW basiert auf den drei Komponenten, die UiPath zur Verfügung stellt. Dazu gehört die Entwicklungsumgebung, die auf einem Client installiert wird und zur Konfiguration der Roboter dient. Weiter wird ein „Orchestrator“ eingesetzt, welcher für das Management und Monitoring der Roboter benötigt wird. Hier handelt es sich somit um eine Serverlösung, mit der Stammdaten, Berechtigungen, Prozesse sowie Roboter verwaltet und überwacht werden können. Die letzte Komponente bilden die Roboter selbst, welche sowohl in der Ausprägung „attended“ als auch „unattended“ ausgeführt werden können. Bezüglich des Lizenzmodells kann bei der Entwicklungsumgebung und den Robotern zwischen den drei Varianten Concurrent (Run), Node (Gerät) und Named (User) unterschieden werden.

Der Ansatz der BKW sah vor, dass für das zentrale CoE im Bereich der Finanzen ein „Orchestrator“, zwei Entwicklungsumgebungen („Studio“) sowie zehn Roboter eingesetzt werden (Concurrent). Die Lizenzkosten für die Software würden damit etwa 50 kCHF pro Jahr betragen. Die dezentrale CoE könnte diesbezüglich auf die bestehende zentrale Serverlösung des „Orchestrator“ aufbauen und bräuchte lediglich eine Entwicklungsumgebung und entsprechende Roboter. Die tiefen Einstiegskosten von etwa 10 bis 20 kCHF pro Jahr pro dezentralen CoE fördern dabei den vermehrten Einsatz der Technologie.

Das AP Prozesse umfasste eine initiale Aufnahme von geeigneten Anwendungsfällen und deren Potenzial in den Finanzfunktionen. So sollten per Ende der Pilotphase 2 eine Shortlist der Bereiche Controlling und Billing und Revenue Management sowie eine Longlist der Bereiche Accounting und Tax, Treasury, Corporate Finance und Risk Management vorliegen. Zum Zeitpunkt der Eingabe wurde erstere erstellt, qualifiziert und priorisiert. Die Kick-off-Veranstaltung der Prozessselektion für die Bereiche Controlling und Billing und Revenue Management erfolgte zu Beginn der Vorstudie in Form eines Workshops. Dabei wurden die Motivation, die Zielsetzung sowie die Grundlagen von RPA vorgestellt. Dazu kamen die Erklärung der für die Erhebung eingesetzten Vorlage sowie die Beantwortung von offenen Fragen.

Mit dieser Ausgangslage wurden im Anschluss während rund vier Wochen geeignete Anwendungsfälle identifiziert. Dies erfolgte durch die jeweiligen Teams, wobei insgesamt 18 Prozesse gesammelt werden konnten. In einem nächsten Schritt erfolgte in drei weiteren Workshops eine Qualifizierung der Prozesse. Dabei waren sowohl Mitarbeitende aus den Fachbereichen als auch aus dem Projektteam anwesend. Dazu kam die externe Unterstützung, welche bei der Selektion unterstütze und den Know-how-Transfer förderte. Das Ziel der Workshops lag in einem besseren Verständnis der Anwendungsfälle sowie der Prüfung, ob RPA ein geeigneter Ansatz für eine Automatisierung bildet. Schließlich erfolgte auf dieser Basis eine Priorisierung der Prozesse und die Auswahl der vier Anwendungsfälle für die Pilotphasen. Ein Auszug der Ergebnisse ist in Tab. 5.3 und 5.4 ersichtlich.

Innerhalb des AP Entwicklung wurden die Softwareroboter für die vier im AP Prozesse ausgewählten Anwendungsfälle zum Zweck eines PoC automatisiert. Dazu gehörten die detaillierte Aufnahme des Ist-Prozesses, die Definition des Soll-Prozesses sowie die Konfiguration der Softwareroboter mit entsprechender Dokumentation. Dabei wurde das Vorgehen so gewählt, dass der erste Anwendungsfall in der Pilotphase 1 durch die externe Unterstützung im Lead jedoch im Tandem mit einem Mitarbeitenden der BKW automatisiert wurde. Die drei weiteren Prozesse sollten dann durch den Mitarbeitenden im Lead mit externem Coaching umgesetzt werden. So sollte der Kompetenzaufbau innerhalb der BKW vorangetrieben werden. Zusätzlich diente dieses erste PoC als Referenzrahmen für weitere Vorhaben.

Zum Zeitpunkt der Eingabe der Forschungsarbeit war der erste Prozess konfiguriert und in Betrieb (siehe Tab. 5.3 PoC 1). Das Vorgehen beruhte in einem ersten Schritt auf einer detaillierten Aufnahme des Ist-Prozesses. Dies erfolgte im Rahmen von Besprechungen zwischen dem Mitarbeitenden, welcher den Prozess heute ausführt, sowie dem Projektteam. Das Ziel lag hier in der Aufnahme des Prozessinputs und -outputs sowie der entsprechenden Aktivitäten und Anforderungen. In einem weiteren Schritt wurde das Prozessdesign (Soll) im Kontext der Automatisierung definiert. Zu diesem Zweck wurde zeitnah ein Flussdiagramm des Anwendungsfalls erstellt, damit der Logik der Softwareroboter sowie den Funktionalitäten der Software Rechnung getragen werden konnten. Hier hat sich herauskristallisiert, dass der Prozess nicht in seiner ursprünglichen, manuellen Form konfiguriert werden soll, sondern im Hinblick auf eine Standardisierung und Optimierung, sowie in Bezug zu einer effizienten Nutzung der Funktionalitäten eine fundamentale Anpassung umgesetzt werden soll. So fanden zusammengefasst die Verfahren Dokumentation, Standardisierung, Optimierung und Automatisierung Anwendung.

Sobald das Prozessdesign definiert war, wurde der Prozess in der Entwicklungsumgebung konfiguriert und getestet. Im Anschluss an die Konfiguration erfolgte die vollständige Dokumentation in Form eines standardisierten Templates. Inhalte waren dabei allgemeine Informationen und Eckdaten zum Anwendungsfall, das Nutzenpotenzial sowie dessen Messung, eine Risikobeurteilung, die Prozessdokumentation, die Roboterspezifikation sowie die Ausgestaltung des Betriebs und des Monitorings. Mit dieser Grundlage wurde der Prozess durch das im AP Governance und Operating Model (Abschn. 5.5.3) beschriebene Gremium freigegeben. Abschließend konnte festgehalten werden, dass die Entwicklung des ersten Anwendungsfalls zehn Arbeitstage umfasste und die Einsparung auf rund 25 Tage pro Jahr geschätzt wurde. So dauerte der manuelle Prozess bis zu vier Stunden pro Woche. Die Durchführung verkürzte sich mit der Automatisierung durch RPA auf 15 Minuten je Woche.

Wie im Abschn. 5.3 beschrieben, wurden mit den AP-Verantwortlichen am Ende der Pilotphase 1 Reflexionsgespräche geführt und ihre Lessons Learned schriftlich festgehalten. Die Tab. 5.5 fasst die Ergebnisse zusammen.