Robotic Process Automation und Digitale Service-Transformation bei der DRV

Aufgrund der Digitalisierung und der damit in Verbindung stehenden Einführung neuer Technologien, Prozesse und Praktiken passen die Organisationen ihre Wertversprechen immer wieder an die neuen Marktanforderungen an. Vor allem während der COVID-Pandemie hat diese Herausforderung eine andere Dimension im öffentlichen Sektor, dessen Dienstleistungen für die Gesellschaft unabdingbar sind. Die Dienste der Verwaltung haben in der Krise mehr an Bedeutung gewonnen, da diese von Bürger*innen stärker in Anspruch genommen worden sind.

Auch die Deutsche Rentenversicherung (DRV) befindet sich mit 59.000 Mitarbeiter*innen, die rund 56 Mio. Versicherte und fast 21 Mio. Rentner im In- und Ausland betreuen, im ständigen Wandel. Ein Indikator dafür ist die Einführung von innovativen Dienstleistungen, die auf die digitale Strategie der Organisation ausgerichtet sind, und das Ziel verfolgen, den Kunden der DRV flexible, ortsunabhängige und verlässliche Dienstleistungen anzubieten. So hat die DRV seit der Initiative BundOnline 2005 für Bürger*innen 17 Online-Dienste zur Verfügung gestellt, wie zum Beispiel eAntrag, eSolution, eTermin, eID und eService.

Die DRV^{Footnote 1} ist gerade dabei, sein Bestandssystem zu modernisieren. Das neue System wird von seiner Architekturausrichtung her auf Automatisierung und Digitalisierung ausgerichtet sein. Da es eine zeitlich begrenzte Phase der Koexistenz beider Systeme (Bestand und Modern) geben wird, hat man sich für Robotic Process Automation (RPA) als Brückentechnologie zur Erhöhung des Automatisierungsgrades des Bestandssystems entschieden. Somit stellt RPA einen wichtigen Baustein für die Digitalisierungsstrategie der DRV dar. Als RPA bezeichnet man in der DRV die automatisierte Ausführung manueller Aktivitäten bei der Durchführung von Geschäftsprozessen durch einen (Software‑)Roboter. Im Fokus liegen hierbei vor allem manuelle, repetitive und anspruchslose Tätigkeiten, deren Automatisierung den Serviceerbringungsprozess beschleunigt und die Servicequalität erhöht, indem dadurch vom Menschen verursachte Fehler erheblich reduziert werden. RPA stößt auf zunehmendes Interesse in Praxis und Forschung. Jedoch ist der Fokus stark auf Prozessautomatisierung gerichtet und der Blick auf die Dienstleistungstransformation fehlt. Ebenso gibt es eine Mangel an Berichten aus dem öffentlichen Bereich (siehe Abschn. 2). Mit diesem Beitrag möchten die Autoren diese Lücke schließen.

Dieser Artikel berichtet über die ersten Ergebnisse von einem RPA-basierten Transformationsprozess der Dienstleistungen bei der DRV. Mit der RPA-basierten Transformation erhofft sich die DRV erhebliche Vorteile in der Serviceerbringung durch Prozessautomatisierung und Fehlerreduktion. Insgesamt werden Einsparungen von über 100.000 Arbeitsstunden/Jahr alleine für die identifizierten Use Cases erwartet. Nichtsdestotrotz ist RPA als Übergangslösung anzusehen, welche vorzugsweise dort einzusetzen ist, wo die entdeckten Automatisierungspotentiale nicht kurzfristig in den Anwendungen implementiert werden können.

Abschn. 2 dokumentiert den Stand der Forschung in RPA, die Umsetzung von RPA in Dienstleistungen sowie RPA in der Verwaltung. Abschn. 3 beschreibt das Vorgehensmodell für die RPA-Einführung bei der DRV. Abschn. 4 informiert über die Umsetzung, den Selektionsprozess sowie die Ergebnisse. Abschn. 5 fasst die Arbeit zusammen.

In der Literatur und Praxis besteht ein zunehmendes Interesse an RPA. Diese ist zum einen durch die Anzahl von und Erkenntnissen aus den aktuellen systematischen Literaturarbeiten in diesem Feld zu beobachten. Beispielsweise führt (Enriquez et al. 2020) eine Mapping Studie durch, in der 54 Publikationen analysiert werden. Ein zentrales Ergebnis ist die steigende Tendenz in den Veröffentlichungen ab 2015. Diese Beobachtung wird in der Literaturanalyse von (Ivančić et al. 2019) bestätigt. Die dritte systematische Studie ist von (Syed et al. 2020). In dieser umfassenderen Veröffentlichung analysieren die Autoren 125 Publikationen inklusive Whitepapers, analysieren unterschiedliche Definitionen, weisen auf die Vorteile, Potenziale, Methodologien, Technologien und Herausforderungen der RPA-Einführung in Organisationen.

Zum anderen gibt es eine Vielzahl von Publikationen, die Rahmenbedingungen und Implikationen der RPA-Einführung aus diversen Aspekten beleuchten. So gibt (Czarnecki und Auth 2018) konkrete Handlungsempfehlungen für die Praxis und stellt in drei Projektbeispielen dar, wie RPA die Prozessdigitalisierung ermöglicht. Ferner diskutieren die Autoren Auswahlkriterien für RPA-Software und schlagen ein Vorgehen zur Auswahl von RPA-Software vor. (Wewerka und Reichert 2020) diskutiert die quantifizierten Effekte einer RPA-Einführung und beobachten die mittels RPA automatisierten Geschäftsprozesse in zwölf Anwendungsfällen aus der Automobilbranche. (Osman 2019) verdeutlicht die Lessons Learned aus zehn Use Cases, die operationale Prozesse mittels RPA automatisieren. Ähnlich diskutiert (Asatiani und Penttinen 2016) die RPA-Einführung in der Finanzbranche und (Lamberton et al. 2017; Hermann et al. 2018) in der Versicherungsbranche. (Eggert und Moulen 2020) liefert Selektionskriterien für die Auswahl der zu automatisierenden Prozesse.

Die Literatur bietet mit umfassenden systematischen Analysen sowie den wertvollen Berichten aus der Praxis also ausreichend Stoff zum Thema. Dennoch gibt es hierzu zwei fehlende Aspekte, die unseren Beitrag motivieren. Der erste Punkt bezieht sich auf den fehlenden Fokus der Beiträge auf die öffentliche Verwaltung. Anwendungsfälle aus der Praxis, wie zum Beispiel (AKOA AB 2021) sind vorhanden, allerdings ist uns bisher eine einzige wissenschaftliche Studie bekannt, die von der RPA im Kontext von Public Services berichtet (Houy et al. 2019). Auch (Enriquez et al. 2020) identifiziert in ihrer ausführlichen Mapping Studie, dass die Berichte aus dem öffentlichen Bereich unterrepräsentiert sind. Die Autoren laden zu den wissenschaftlichen Beiträgen mit mehr Praxisfokus vor allem bei der Validierung ein.

Der zweite Punkt ist die aus unserer Sicht fehlende Untersuchung vom RPA-Einsatz im Kontext von Dienstleistungstransformation und der zu starke Fokus auf die darunter liegenden Prozesse sowie deren Automatisierung. Dies ist eher überraschend, da in der Service-Literatur Dienstleistungen und Prozesse miteinander eng verzahnt betrachtet werden (vgl. (Lê et al. 2010), (Bruhn und Hadwich 2020a), (Welke 2015)). Hierzu werden die Geschäftsprozesse als eine Reihe von Aktivitäten verstanden, die für die Serviceerbringung benötigt werden (Welke 2015). Der Beitrag von (Lacity und Willcocks 2016) weist auf die Verbindung zwischen „Service Automation“ und „Software Robots“ hin. Allerdings stellt die Arbeit ein generisches managementtaugliches Set von Best Practices zur Verfügung, ohne die Transformationsaspekte von Dienstleistungen zu diskutieren. Aus diesem Grund ist es bisher nicht klar, wie der über den Prozess liegende Service mittels Prozessautomatisierung transformiert wird. Basierend auf diesen Erkenntnissen, möchten die Autoren in diesem Artikel die Beziehung herstellen.

Es gibt durchaus Studien, die Digitalisierung von Dienstleistungen als Forschungsgegenstand haben. Vor allem bieten sich in der deutschsprachigen Literatur die Werke in (Bruhn und Hadwich 5,6,b, c) an. Auch die Themen im Kontext der Digitalisierung in der Verwaltung wurden betrachtet (vgl. (Klenk et al. 2020), insbesondere (Döring und Löbel 2020) und (Jarke und Kubicek 2020)). Allerdings ist gemeinsam in diesen Studien der fehlende Bezug zur RPA. Deshalb zielt dieser Artikel darauf ab, die Lücke in der Literatur mit diesem Beitrag zu schließen.

In der Literatur werden einige Prozess- beziehungsweise Lebenszyklusmodelle zur Implementierung von RPA-Lösungen vorgeschlagen. Laut (Jimenez-Ramirez et al. 2019) existieren die sechs Phasen Analysis, Design, Development, Deployment, Control sowie Operation and Maintenance. In der Analysis-Phase werden die Kandidaten für die Prozessautomatisierung beziehungsweise Servicedigitalisierung identifiziert. Die Design-Phase umfasst die Bewertung von Kandidaten anhand von Selektionskriterien. Basierend darauf werden die entsprechenden Prozesse in der Development-Phase für die Ausführung über Roboter (Bots) vorbereitet. Die Deployment-Phase betrifft die Bereitstellung in der Laufzeitumgebung, in der die Roboter konkrete Aufgaben übernehmen und umsetzen. In der Control-Phase werden die Leistungen überwacht. Die letzte Phase Operation and Maintenance erlaubt eine Evaluation der gesammelten Leistungsinformationen. Ähnlich teilt (Manutiu 2018) den Lebenszyklus einer RPA in sechs Phasen ein. Diese sind „Analyse, Design, Entwicklung, Test, Freigabe“ und „Run“. Die beiden Ansätze sind im Einklang mit den Lebenszyklusmodellen von (Enriquez et al. 2020) oder (Flechsig et al. 2019). Dahingehend scheint es in der Literatur eine gemeinsame Meinung bzgl. der RPA-Vorgehensmodelle zu geben.

Bei der DRV wurde ein ähnliches Vorgehensmodell mit leichten Anpassungen im letzten Schritt benutzt (siehe Abb. 1). Analog zur Analyse-Phase wurde im ersten Schritt ein Workshop mit der Stabstelle Digitalisierung, den serviceerbringenden Fachabteilungen, dem Architekturmanagement sowie den RPA-Experten eines externen Beratungshauses durchgeführt. Wie (Eggert und Moulen 2020) berichtet, halten die Autoren es für unabdingbar, dass die Vorschläge der Fachseite um die Anforderungen für die Selektion von Use Cases miteinbezogen werden. Schritt 2 des Vorgehens umfasst die Detaildokumentation von Use Cases bezogen auf die Selektionskriterien (siehe Abschn. 4) der Serviceprozesse. Für die spätere Entwicklung und Implementierung von Robotern benötigen die RPA-Experten die Unterstützung des Architekturmanagementteams. Dies ist vor allem wichtig, weil die Services IT-gestützt angeboten werden und die darunter liegenden Prozesse die Nutzung von Software in der IT-Landschaft der DRV erfordern. Ein Abgleich findet im Schritt 3 statt. Somit kann der Schritt 3 der „Design-Phase“ eingeteilt werden. Schritt 4 bezieht sich auf die Entwicklung, Test und Produktivsetzung von Bots für die identifizierten Serviceprozesse. Es handelt sich hier um eine iterative Vorgehensweise, das heißt die Entwicklung-Test-Phasen werden wiederholend durchgeführt. Im letzten Schritt Betriebsmodell definieren werden die Anforderungen für die Inbetriebnahme definiert. Anders als die bisher genannten Vorgehensmodellen werden hier die Rollen, Prozesse, Technologien etc. festgelegt, um eine RPA-Fähigkeit im Unternehmen aufzubauen.

Vorgehensmodell zur RPA-Einführung

Full size image

4.1 Schritt 1: Workshops durchführen

Die Umsetzung begann mit einem „Ideation-Workshop“ (siehe (1), Abb. 1) im Mai 2020. Im Workshop wurde zunächst geklärt, was RPA ist und wie sie funktioniert. Es wurde vor allem das Potenzial betont, dass mittels RPA repetitive Tätigkeiten automatisiert werden, Mitarbeiter sich auf wertschöpfende Tätigkeiten konzentrieren können und damit die Qualität in der Dienstleistungserbringung erhöht werden kann. Darüber hinaus wurden zwei Anwendungsfälle aus der öffentlichen Verwaltung kurz vorgestellt. Hier lag der Fokus auf den Mehrwert der automatisierten Prozesse im Sinne von Zeitersparnissen und weitere qualitative Verbesserungen, wie zum Beispiel Optimierung der Systemlast, bessere Datenqualität oder starke Skalierbarkeit (Allweyer 2016; Wewerka und Reichert 2020; Syed et al. 2020). Im zweiten Teil des Workshops wurden Informationen über die Dienstleistungen, die Eigenschaften der darunter liegenden Geschäftsprozesse sowie deren Kennzahlen im DRV-Kontext gesammelt (wie viele Fälle am Tag? Wie lang pro Fall?). Die Workshops dauerten je 90 min in einem kleinen Kreis bis zu 10 Teilnehmer.

4.2 Schritt 2: Serviceprozesse dokumentieren

Die Selektionskriterien zur Überprüfung der Prozessautomatisierung wurden in der Literatur mehrfach diskutiert. Folgende, aus der Literatur abgeleitete, Kriterien haben die Fachabteilungen für Prozesse, die den Dienstleistungen unterliegen zur Überprüfung ausgewählt.

• Regelbasiert: Die Prozesse können mithilfe einfacher Regeln beschrieben werden (Eggert und Moulen 2020; Syed et al. 2020; Allweyer 2016).

• Sehr repetitiv: Die Prozesse bestehen aus repetitiven Schritten (Syed et al. 2020; Allweyer 2016; Hermann et al. 2018).

• Hohe Volumina: Die Prozesse sind umfangreich und/oder bestehen aus vielen Schritten (Syed et al. 2020; Allweyer 2016).

• Wenige Ausnahmen: Es gibt keine bis wenige Veränderungen der Abläufe (Syed et al. 2020; Hermann et al. 2018).

• Maschinenlesbarer Input: Der Prozess nutzt digitale Input beziehungsweise Output-Quellen (Syed et al. 2020; Hermann et al. 2018).

• Strukturierter Input: Die Input-Daten für den Prozess liegen in strukturierter Form vor (Syed et al. 2020).

• Sehr manuell: Der Prozess beinhaltet ein hohes Maß an manuellen Aktivitäten (Syed et al. 2020; Hermann et al. 2018)

Insgesamt wurden 26 Use Cases identifiziert, die von einer RPA-Einführung profitieren können. Die Use Cases hatten einen engen Bezug zu den internen und externen Dienstleistungen. Im zweiten Schritt wurden die Use Cases dokumentiert (siehe Abb. 2). Es wurde auf die relevanten Prozesse für die Serviceerbringung näher eingegangen. Die Prozesse von Dienstleistungen mit großem Zeitersparnispotenzial und hohe Volumina haben, sollten zunächst untersucht werden. Für die Gruppierung von Prozessen wurde ein fünfstufiges Schema angewandt, welches in der Tab. 1 dargestellt und im Schritt 4 detailliert wird. Dieses Schema resultierte aus den Diskussionen im Schritt 1. Basierend auf diesem Schema wurden schließlich Bots für die Services entwickelt, deren Prozesse den Status „erweiterte Pilotierung in der Produktion“ und „umgesetzt im Test“ haben.

Dokumentation der Serviceprozesse

Full size image

4.3 Schritt 3: Architektonische Voraussetzungen abgleichen

Im Schritt 3 haben die IT-Architekten die relevanten Systeme für die einzelnen Use Cases sowie die unterstützenden Technologien identifiziert und die Schnittstellen zwischen der einzusetzenden RPA-Software und DRV-Software analysiert. Konkret handelte es sich um zwei Aspekte: Technischer Zugriff des Roboters zur Bedienung einer Anwendung, in der Regel über eine Dynamic Data Exchange-Schnittstelle von Windows und um die Zugriffsrechte des Roboters auf die Anwendung, da nicht jeder Benutzer auf jede Anwendung zugreifen darf. Des Weiteren musste die IT-Sicherheit die Bereitstellung und Ausführung der Roboter auf einem Testrechner in der Produktionsumgebung freigeben. Dies beinhaltete technische und datenschutzrechtliche Aspekte (Netzwerk bzw. Zugriffsrechte für die Entwickler und Umgang mit Produktivdaten für die Tests). Dieser Schritt wurde mit der Organisation von Zugriffsrechten für die Entwickler (Softwarerechte für die Frontends, kein Zugang zu Produktivdaten, z. B. Schulungs- oder Testausweise) abgeschlossen.

4.4 Schritt 4: Roboter implementieren

Tab. 1 zeigt die Ergebnisse der Prozessuntersuchung (siehe Spalte „Prozess“) für Servicedigitalisierung (siehe Spalte „Service“) an, die im Zuge des initialen Workshops und weiteren Gesprächen identifiziert wurden. „Anzahl Fälle“ steht für die Anzahl der Anwendungsfälle. „Anzahl der Fälle pro Jahr“ ist die Zahl der Ausführungen des Anwendungsfalls. In Verbindung mit der „durchschnittlichen Bearbeitungszeit nach der Automatisierung“ ergibt sich das zeitliche Einsparpotential.

Der Fokus lag auf Themen, die ein relativ hohes Einsparpotential erbringen könnten. In Übereinstimmung mit den Selektionskriterien wurde die Priorisierung der Prozessfälle anhand geschätzter Bearbeitungszeiten und Fallmengen vorgenommen. Genauere Analysen dazu wurden in der Teststellung noch nicht vorgenommen.

Die untersuchten Prozesse von externen und internen Dienstleistungen ließen sich in fünf Hauptgruppen einteilen:

4.4.1 Erweiterte Pilotierung in der Produktion

Von vier relevanten Use Cases wurde der „Prüfabschluss ohne Feststellung (PAoF) – Vorsortierung“ für die erweiterte Pilotierung als erstes ausgewählt. Dieser Prozess unterstützt die Erbringung des externen Service „Prüfdienst“, welcher für rund 400.000 Arbeitgeberprüfungen pro Jahr verantwortlich ist. Dazu kommen Prüfungen bei Krankenkassen und unmittelbaren Beitragszahlern wie beispielsweise Arbeitsagenturen und Pflegekassen. Bei jedem Durchlauf wird ein Prüfbericht erstellt und gedruckt. Jeder Prüfer sichtet seinen Bestand an Prüfungen pro Jahr. Der Bestand wird manuell selektiert und geprüft. Anschließend erstellt der Prüfer das Prüfergebnis, druckt und erledigt den Vorgang statistisch. Für die Erbringung von diesem Service wird der Prüfabschlussprozess 40.000 mal je 60 min durchlaufen, der vom RPA-Bot übernommen werden sollte.

Der Fall „PAoF-Vorsortierung“ für den Service Prüfdienst wurde für ca. 10 Tage in der Produktionsumgebung^{Footnote 2} betrieben. Zunächst wurden die Bots in entsprechenden Umgebungen in zwei Wochen entwickelt und getestet. Die erweiterte Pilotierung für den Serviceprozess wurde unter strenger Kontrolle durch IT-Sicherheit und Fachabteilung in einer abgegrenzten Produktivumgebung erfolgreich ausgeführt. Als Ergebnis wurden ca. 40.000 Fälle aus dem zu prüfenden Arbeitsvorrat^{Footnote 3} vorsortiert. Manuelle Vorsortierarbeiten wurden durch den Bot übernommen. Die Roboter-Software wurde nach der erweiterten Pilotierung wieder vom Produktivrechner entfernt.

4.4.2 Umgesetzt im Test

Die drei Prozesse beziehungsweise Testfälle mit dem Status „umgesetzt im Test“ beziehen sich auf drei interne Services, nämlich Dokumentumwandlung, Informations- und Statistikdienste sowie Ultimo-Lauf. Sie decken ein breites Spektrum an Anwendungsbereichen teilautomatisiert (attended Bot) und vollautomatisiert (unattended Bots) sowie eine Vielzahl an Applikationen (Kernanwendung, Bürokommunikation, Office-Anwendungen, PDF- und XML-Verarbeitung) ab. Im Falle eines attended Bots können Einzelpersonen Bot-Aktivitäten auslösen, um Teile eines Prozesses auszuführen, und diese Aktivitäten aktiv zu überwachen. Der unattended Bot dagegen ist autonom und eignet sich für einfachere Prozesse, die zwar nicht variieren, aber bei Verwendung in komplexeren Fällen zu erheblichen Fehlern führen können (Syed et al. 2020).

Ein Testfall beinhaltet einen PDF-Bot (attended Bot) für die Digitalisierung des internen Service „Dokumentumwandlung“. Dieser bringt substantielle Vorteile für den einzelnen Sachbearbeiter bei der automatisierten Umwandlung von Dokumenten von verschiedenen Formaten in PDFs und dem Hochladen des Dokuments in Workflow-Anwendung. Die Ausführung über den Bot ist einfacher in der Handhabung, da es nur einen Prozess für jede Applikation gibt. Für ungeübte Mitarbeiter wird außerdem eine beschleunigte Bearbeitung ermöglicht.

Der für den Prozess „Identifizierung offener Statistiken“ entwickelte Bot (unattended) stellt zusammenfassend eine geeignete Maßnahme zur Qualitätssicherung dar. Dieser Prozess wird im Kontext des internen Service „Informations- und Statistikdienste“ durchgeführt. Dabei läuft der Bot im Hintergrund ab und wird nicht von einem Sachbearbeiter bzw. Mitarbeiter bedient. Dieser Anwendungsfall unterstützt die Führungskräfte und erzeugt neben der Qualitätssteigerung auch eine Zeitersparnis in der Serviceerbringung, da die Koordinierung und Verteilung der Fälle an die jeweiligen Sachbearbeiter in der Workflow-Anwendung erleichtert wird.

Der Bot für die statistische Erfassung des „Ultimo-Laufs^{Footnote 4}“, ein weiterer interner Service, eliminiert mehrere manuelle Prozessschritte. Außerdem bietet der Bot sehr hohes Potenzial für Erweiterungen auf andere Prozesse in der Sachbearbeitung.

4.4.3 Vorqualifiziert

Eine Reihe von vorqualifizierten Prozessen steht bereit für die Entwicklung, bei denen ein hohes Einsparungspotential besteht. Die dargestellten Use Cases aus den Fachabteilungen bieten hohe Potenziale für eine verbesserte Servicequalität, Zeitersparnisse und die Mitarbeiterzufriedenheit. Es handelt sich hierbei um die Prozesse, die zwar ein hohes Einsparpotential bieten, aber für den ersten Test erst einmal als zu aufwändig zurückgestellt werden. Nach der endgültigen Einsatzentscheidung werden die vorqualifizierten Fälle angegangen.

4.4.4 Nicht für die Testphase geeignet

Diese Gruppe besteht aus den Serviceprozessen, die in Summe eine hohe Komplexität aufweisen beziehungsweise nicht die erhofften Entlastungen einbringen und somit für die Testphase nicht weiter betrachtet werden. Diese Fälle sind in das Backlog zur späteren Betrachtung aufgenommen und werden bei einer Weiterführung der Thematik vertieft untersucht. Gründe dafür sind unter anderem, dass die Selektionskriterien zu einem gewissen Grad erfüllt werden oder in den Fachabteilungen bereits Projekte laufen, die sich die Digitalisierung der Prozesse vorgenommen haben.

4.4.5 Ausqualifiziert

Ergänzend zu den umgesetzten, priorisierten und zurückgestellten Anwendungsfällen wurden Anwendungsfälle im Zuge der ersten Prozessanalyse ausqualifiziert. Gründe hierfür waren unter anderem eine mit RPA nicht abbildbare Komplexität im Geschäftsprozess (z. B. Handschrifterkennung), außerdem zu geringe Einsparpotentiale und systemische Anpassungen in den Zielanwendungen, die die Nutzung von RPA obsolet machen.

4.5 Schritt 5: Betriebsmodell definieren

Der letzte Schritt der Methode sieht vor, ein Betriebsmodell festzulegen. Aktuell besteht das RPA Betriebsmodell der DRV aus fünf Dimensionen (siehe Abb. 3). Dieses basiert auf die Ergebnisse von den Workshops im Schritt 1. Organisation & Rollen bezieht sich auf das Etablieren von Rollenprofilen bei der DRV im Kontext von RPA-Projekten sowie die Kooperation unterschiedlicher Rollen wie zum Beispiel Fachexperten, Entwickler (Syed et al. 2020) oder Lösungsarchitekten (Eggert und Moulen 2020). Laut Prozesse sollten die automatisierten Prozesse in die Prozesslandschaft integriert werden. Technologie betont das Zusammenspiel der Komponenten der RPA-Architektur mit Legacy Systemen. Sie gilt als die Grundlage für die enge Zusammenarbeit mit dem Architekturmanagementteam. Governance weist auf die RPA-Richtlinien und Dokumente sowie Performance Management inklusive Key Performance Indicators (KPIs) für RPA hin. Mitarbeiter & Kultur erfordert die Erstellung eines Mitarbeiterqualifikationskonzepts im Sinne von Aus‑/Weiterbildungen und Trainings. Die RPA hat eine enge Beziehung zur Digitalstrategie der DRV. Insofern gilt die Mission und Vision der Organisation als übergreifende Dimension und gibt die Ziele der RPA-Projekte vor.

RPA-Betriebsmodell DRV

Full size image

RPA ist ein wichtiger Baustein für die Digitalisierungsstrategie der DRV. Sie bringt große Potenziale für die Erhöhung der Servicequalität, Kosteneinsparungen und Entlastungen der Sachbearbeitung mit sich – dies zeigt sich in den im vorherigen Kapitel vorgestellten Zahlen zu Bearbeitungszeiten und Mengengerüsten für die Prozesskandidaten, die sich für die Automatisierung mit RPA eignen. Dies stellt in der aktuellen Phase von steigender Aufgabenbelastung verbunden mit der demografischen Entwicklung ein sehr gutes Potenzial dar.

Für die RPA-Einführung wurden im Rahmen einer strukturierten Einführung 26 Use Cases identifiziert. Gemeinsam mit den serviceerbringenden Abteilungen wurden diese Use Cases in einem Workshop weiter analysiert und qualifiziert. Mithilfe eines Kriterienkatalogs wurden diese für eine weitere Bearbeitung priorisiert. Nach Bereitstellung einer RPA-Software wurde der erste Use Case „Prüfabschluss ohne Feststellung – Vorsortierung“ erfolgreich pilotiert und in einer erweiterten Produktionsumgebung eingeführt. Für die Erbringung von diesem Service wird der Prüfabschlussprozess 40.000 mal je 60 min durchlaufen. Ziel der Transformation ist die weitgehende Automatisierung von ausgewählten Services. Es handelt sich in diesem Kontext nicht nur um kundennahe bzw. externe Services. Auch die Digitalisierung von internen Services wurde in dem Projekt betrachtet und sind somit ein Bestandteil von diesem Beitrag.

Generell gibt es in allen bisher an der Teststellung beteiligten Fachabteilungen eine hohe Begeisterung für die Einführung von RPA für die Automatisierung von repetitiven und zeitaufwändigen Geschäftsprozessen. Ein weitergehender Einsatz „intelligenter“ Formen des RPA (IPA) ist aktuell nicht vorgesehen. Im Zuge des Service-Konzepts muss ein besonderer Fokus auf die Dokumentationsanforderungen und -standards für RPA gelegt werden. Dennoch liegen aktuell keine quantitativen Daten zur Messung der Zufriedenheit. Diesbezüglich wird geplant, eine Studie durchzuführen und von den Ergebnissen zu berichten. Hierzu bietet sich beispielsweise das Evaluierungsschema von (Wewerka und Reichert 2020) geeignet an.

Parallel kann die Entwicklung eines Service-Konzepts für RPA angestoßen werden. Hieraus leiten sich dann auch Rollenprofile und entsprechende Personalbedarfe für die Einführung von RPA bei der DRV ab. Die entsprechenden Personen können anschließend trainiert und bei der RPA-Entwicklung unterstützt werden. Ein Fokus soll auf die Nutzung bestehender Prozesse und Tool-Landschaften der DRV gelegt werden, um ineffiziente Parallelstrukturen für RPA zu vermeiden.

Die bisherige Prozessanalyse und auch Umsetzung einzelner Fälle hat sich auf ausgewählte Fachabteilungen konzentriert. Insofern wurden die Ziele der Testphase erreicht und durch die erweiterte Pilotierung sogar übertroffen und eine technische Machbarkeit sowie der Bedarf und das Potenzial aus Sicht der Fachabteilungen bestätigt. Ein erweiterter Blick auf die gesamte Organisationsstruktur im Kontext vom Betriebsmodell der DRV zeigt jedoch, dass sich weitere Möglichkeiten in anderen Abteilungen bieten, um Automatisierungsbedarfe zu identifizieren und das Automatisierungspotential innerhalb der zusätzlichen Abteilungen und Dezernate zu heben. Dahingehend soll bis Ende 2021 bewertet werden, inwiefern RPA das Potenzial für eine strategische und skalierbare Nutzung innerhalb der DRV besitzt. Es ist geplant, im Anschluss an die Teststellung einen Proof of Concept mit pilotierenden Abteilungen unter der Erprobung möglicher Service-Prozessen durchzuführen. Bei einer positiven Bewertung und Entscheidung für einen Proof of Concept mit weiteren Fachabteilungen kann der Einsatz von RPA erweitert werden. Hieran muss sich direkt die Erstellung eines Datenschutz- und IT-Sicherheitskonzepts sowie die Auswahl und Beschaffung einer geeigneten RPA-Lösung anschließen.