Anzeige
| RPA-Praxiseinsatz (2)

Naspa pilotiert erfolgreich Robotics-Technologie

Robotic Process Automation (RPA) soll Mitarbeiter von Routinetätigkeiten entlasten, um etwa mehr Zeit für Vertriebsaktivitäten zu schaffen. Doch hält eine Steuerung von Prozessen durch Roboter das, was sie verspricht? Ja, in vielen Bereichen schon, zeigt ein Pilotprojekt der Nassauischen Sparkasse.

Anzeige

Wir alle kennen sie: Prozesse, die viel Zeit kosten, von anderen oft wichtigeren Tätigkeiten abhalten und dabei aber vollkommen regelbasiert ablaufen. Warum lassen sich diese nicht automatisieren? Ein vielfach genannter Grund sind die im Prozess verwendeten Anwendungen und Systeme. Ein eigenständiger, programmiertechni­scher Eingriff ist hier meist nicht oder nur mit sehr viel Aufwand möglich. So wird etwa das Kernbanksystem der Sparkassen (OSPlus) zentra­lisiert und gleichzeitig für eine große Zahl einzelner Institute bereitge­stellt. Eine Herausforderung, wenn es an die Automatisierung instituts­individueller Prozesse geht.

Eine ergänzende Alternative bietet Robotic Process Automation (RPA). Mit dieser Software-Lösung lassen sich Anwendungen automatisieren, ohne in Programm-Codes eingreifen oder Schnittstellen schaffen zu müssen. RPA genießt seit einigen Jahren verstärkte Aufmerksamkeit im Dienstleistungssektor – mittlerweile auch in der Finanzwirtschaft. Studien und Umfragen versprechen für die kommenden Jahre ein massives Wachstum des RPA-Markts.

Verschiedenen Marktforschungsinstituten zufolge lag dieses in den vergangenen Jahren bei durchschnittlich mehr als 50 Prozent pro Jahr. Das McKinsey Global Institute sieht das aggregierte, technische Automatisierungspotenzial der weltweiten Finanzwirtschaft nach eigenen Erhebungen bei mehr als 40 Prozent. Ein Großteil davon lässt sich mit RPA heben. Die Kernaussage ist eindeutig: Die Finanzwirtschaft besitzt enormes Potenzial zur Effizienzsteigerung und Kosteneinsparung durch die Nutzung von RPA.

Innerhalb der Sparkassen-Finanzgruppe (SFG) ist der Anteil RPA-einsetzender Institute aktuell noch gering, steigt aber ständig. Um RPA im eigenen Institut zu etablieren und Umsetzungsfehler zu vermeiden, muss man allerdings die Technologie verstehen und einordnen können sowie ihre Einsatz­bereiche und Grenzen kennen. Hierzu sollen im Folgenden zunächst die technologischen Hintergründe und Nutzenpotenziale von RPA skizziert werden. Am Beispiel der projekthaften Implementierung in der Nassauischen Sparkasse wird anschließend gezeigt, wie mit einem verhältnismäßig geringen Einmalaufwand von rund 30.000 bis 50.000 Euro jährliche Prozesskosten in doppelter Höhe eingespart werden können.

RPA als Lösung zur Voll- oder Teilautomatisierung

Doch was genau ist RPA und worin unterscheidet sich die Technologie von anderen Systemen? Eine gängige Definition ist: Bei RPA handelt es sich nicht um physische Maschinen, sondern um eine installierbare Software. Deren Einsatzziel ist es, Menschen bei der Ausübung ihrer strukturiert-repetitiven Tätigkeiten zu unterstützen oder ihnen einzelne Tätigkeiten vollständig abzunehmen. Dabei kommuniziert RPA mit ande­ren digitalen Systemen, extrahiert Daten, bearbeitet diese und fügt sie in andere Anwendungen ein.

RPA eignet sich somit in seinen Grundzügen zur voll- oder teilautomati­sier­ten Abwicklung von Geschäfts- und Verwal­tungspro­zessen. Es ist eine Lösung, die – für sich genommen – oftmals tiefgreifende Änderun­gen an vorhandener IT-Infrastruktur überflüssig macht. RPA nutzt meist das User-Interface so, wie es auch ein Mensch nutzen würde und kann daher auch als „non-invasiv“ bezeichnet werden. Die hier geschilderten RPA-Lösungen verwenden weder künstliche Intelli­genz noch Kompo­nenten des maschinellen Lernens oder ähnliche Techno­logien. Die meisten Anwendungsfälle in der Finanzwirtschaft – zumin­dest im Bereich umfangreicher, hochvolumiger Prozessautomatisierungen – beschränken sich erfahrungsgemäß bislang auf solche (Basis-) Lösungen.

Mit RPA automatisierbare Anwendungen

Zwei Faktoren bestimmen, was im individuellen Anwendungsfall mit RPA automatisiert werden kann:
  1. die ausgewählte RPA-Software
  2. die zu automatisierenden Anwendungen (auch „Zielanwendungen“).
Meist nutzt RPA das User-Interface, um zugrundeliegende Anwendungen zu bedienen. Diese „merken“ dabei nicht, dass Befehle und Eingaben aus einer anderen Software und nicht von einem Mensch kommen. An diesem Punkt unterscheidet sich RPA von anderen Automatisierungslösungen, die direkt mit der sogenannten Business-Logik- und der Datenbankzugriffsschicht interagieren, was ein großer Vorteil von RPA ist. Diese „Einfachheit“ führt zu hoher Flexibilität und Unabhängigkeit von möglichen Anforderungen, die eine Zielanwendung an andere Automatisierungslösungen stellt.

Alternativ zur Nutzung des User Interfaces kann RPA vorhandene Schnitt­stellen verwenden. Auch der direkte Zugriff auf Betriebssysteme und Datenbanken beziehungsweise deren Zugriffsschichten ist möglich. Eine nur noch selten genutzte Zugriffsmöglichkeit wird über Bildschirmkoordinaten gesteuert (auch als „Screen Scraping“ bezeichnet). Felder werden dabei per virtuellem „Mausklick“ ausgewählt und bedient. Dieser Mausklick erfolgt an einer vorher festgelegten Stelle auf dem Bildschirm. Problematisch: Verschiebt sich das zu bedienende Feld, kann der Roboter es nicht mehr bearbeiten oder wählt ein falsches Feld aus. Screen Scraping sollte deshalb in der Prozessautomatisierung nur als Ausweichlösung dienen.

Aufbau von RPA-Software

RPA-Software-Lösungen beinhalten eine Komponente, um den Prozessablauf „zu designen“. Meist wird das in hohem Maß mit grafischer Unterstützung umgesetzt. Verwendet werden die nachfolgen­den Bausteine:

  • Prozessbaukasten, in dem sich mittels „Drag-and-Drop“ Prozessabläufe darstellen lassen – regelmäßig in Form von „Flowcharts“, also grafisch dargestellte und miteinander verbundene Prozessschritte.
  • Auswahl-Listen mit vordefinierten Befehlen wie Öffnen und Bedienen von Tabellenblättern, Ausführen von Mausklicks etc.
  • Rekorder zur Aufzeichnung von Prozessen. Dafür wird der Prozess manuell durchlaufen, während alle Schritte aufgezeichnet werden. Auf diesem Grundgerüst setzen später die RPA-Entwickler auf.
Die relevanten Software-Bestandteile unterscheiden sich oft nur geringfügig in grundsätzlichen Funktionalitäten. Die meisten können Texte auf spezifische, gesuchte Teststellen hin scannen und diese auslesen, Daten einlesen, (zwischen-)speichern und einfügen. Befehle wie Bedingungen, Schleifen etc. lassen sich in Form einer Programmie­rung integrieren – vergleichbar einem konventionellen Coding.

Die oben beschriebene Komponente, in der die RPA-Entwickler arbeiten, wird je nach Hersteller als „Studio“, „Creator“, „Designer“ etc. bezeichnet. Daneben schließt die vollständige RPA-Architektur weitere Komponenten ein. Zum einen sind dies die eigentlichen Roboter, auch als „Runner“ oder „Bots“ bezeichnet, sowie eine zentrale Steuerungs­einheit wie „Control Room“ oder „Orchestrator“.

Die Roboter selbst führen die erstellten RPA-Artefakte aus, durchlaufen also die operativen Prozesse und sind damit die Komponente, die – bildlich gesprochen – den prozessausführenden Menschen ersetzt. Je mehr Roboter parallel betrieben werden, desto wichtiger wird die zen­trale Steuerungseinheit. Erst mit ihr lassen sich die Roboter auch automatisiert steuern. Zu diesem Zweck werden Auslastung und Performance überwacht, Prozesse unter den Robotern verteilt etc.

Wichtig, auch wenn sich die RPA-Software-Lösungen ähneln: Vor der Auswahl einer konkreten RPA-Software muss in jedem Fall die Funktions- und Zugriffsfähigkeit innerhalb der institutsindividuellen Umgebung geprüft werden.

Abgrenzung von RPA zu anderen SFG-Automatisierungslösungen

RPA unterscheidet sich in manchen Dingen wesentlich, in anderen aber nahezu überhaupt nicht von anderen Automatisierungslösungen. Auch die SFG besitzt bereits verschiedene Möglichkeiten zur Prozessautomatisie­rung wie die Automatisierung durch Dynamische Prozesse (DynPro) in der Interaktiven-Service-Plattform (ISP). In der ISP sind bereits einige automatisierte Prozesse enthalten, die durch die DynPro ergänzt werden. Letztere ergänzen bei Einbindung in die Internet-Filiale die OSPlus_neo-Prozesse, die für bestimmte Themen bereits genutzt werden können.

Worin unterscheidet sich RPA von den hier beschriebenen und in der SFG bereits umfassend verwendeten Lösungen? Bei den beschrie­be­nen Lösungen handelt es sich um Angebote, die zwar individualisierbar sind, jedoch nur eine sehr eingeschränkte anwendungsübergreifende Automatisierung ermöglichen. Ihr Fokus liegt auf einer Automatisierung der Prozesse im OSPlus (wenngleich etwa auch ein E-Mailversand oder ähnliches möglich ist). Mit RPA ist dagegen eine vollständige, anwen­dungs­übergreifende Individualisierung des Prozessablaufs und damit eine Anpassung an die Bedürfnisse des eigenen Instituts möglich. Der Grundsatz lautet: Nahezu alle durch Menschen bedienbaren Anwen­dun­gen sind auch durch RPA bedienbar.

Trotzdem sollte RPA nicht ungeprüft eingesetzt werden. Sofern SFG-eigene Lösungen vorhanden oder in naher Zukunft geplant sind, sollten diese genutzt werden. Denn grundsätzlich gilt in den meisten Instituten zurecht der Grundsatz, sich an einem einheitlichen Standard ausrichten. Zudem sind programmierte, also „invasive“ Automatisierungslösungen manchmal die stabilere Wahl – auch wenn der Aufwand für deren Ein­richtung mitunter deutlich größer ist. Dennoch und wie eingangs gesagt: Diese invasiven Lösungen kann ein Institut allein nicht umsetzen. Für Anpassungen von Anwendungen, die alle Institute der SFG nutzen, sind langwierige, oft kostenintensive Anforderungsprozesse zu durchlaufen. RPA ermöglicht statt dessen eine oftmals geforderte kurze Time-to-market in der Automatisierung und damit eine Beschleunigung von Prozessen.

Vier Kategorien von RPA-Nutzenpotenzialen

Die Verlockung ist groß, RPA unverzüglich im eigenen Institut zu implementieren. Zunächst empfiehlt es sich jedoch, die versprochenen Potenziale kritisch zu untersuchen. Dazu werden vier Kategorien von RPA-Potenzialen unterschieden: Kosteneinsparungen, Qualitätssteigerungen, Zeiteinsparungen sowie sonstige Potenziale.

Kosteneinsparung
Klassische Zielsetzung jeder Prozessoptimierung und -standardisierung ist, Prozesskosten zu reduzieren oder künftig zumindest steigende Kosten zu vermeiden. Nächster logischer Schritt ist dann die Prozessautomatisierung. Hiermit lassen sich (zusätzliche) gebundene Mitarbeiterkapazitäten reduzieren und durch (oft niedrigere) Kosten einer Automatisierung ersetzen. Bereits an dieser Stelle sei erwähnt: Eine Automatisierung durch RPA bedeutet in aller Regel nicht, dass für die vorher mit der Prozessdurchführung beauftragten Beschäftigten keine Kosten mehr anfallen. Vielmehr dient RPA dazu, diese von repe­titiven, zeitintensiven Tätigkeiten zu befreien, sodass sie anschließend mehr Kapazität für wertschöpfende Arbeiten haben.
In vielen Fallstudien und Beispielen erfolgreicher RPA-Einsatzszenarien werden große Kosteneinsparpotenziale aufgeführt. Ihre Bezugsbasis und Vergleichsgrößen sind aber häufig unterschiedlich, was einer genauen Prüfung bedarf. Die Größenordnungen reichen von 20- bis hin zu 90-prozentiger Kosteneinsparung.
Bestandteil der Kosten sind neben Lizenzkosten für die RPA-Software initiale Kosten für die Automatisierung eines Prozesses sowie laufender Betriebsaufwand. Grundsätzlich gilt: Mit zunehmendem Umfang eines RPA-Einsatzes – also einer zunehmenden Zahl automatisierter Prozesse – steigen die Kosten für RPA-Steuerung und -Betrieb an. Gleichzeitig verringert sich aber durch Lerneffekte der jeweilige Aufwand für die Umsetzung neuer Automatisierungen. Die Kosteneinsparungen durch RPA können deshalb variieren – nach oben wie nach unten.
Wird eine langfristige Automatisierung unterschiedlicher Prozesse im eigenen Haus angestrebt, kann – inklusive der skizzierten und umzulegenden Overhead-Kosten – mit 30 bis 40 Prozent nachhaltiger Kosteneinsparung gegenüber den Ist-Prozesskosten vor Automatisierung gerechnet werden. Dies gilt für einen schon vorher effizienten, also optimierten Prozess. Ist dieser dagegen seit Jahren nicht mehr (bankfachlich) überprüft und gegebenenfalls optimiert worden (war vorher ineffizient), sind die Einsparpotenziale noch deutlich größer.
Die Amortisationsdauer, also die Zeit, in der das eingesetzte Kapital in Form von Einsparungen durch geringere RPA-Prozesskosten wieder „zurückgeflossen“ ist, liegt in den meisten Fällen bei unter einem Jahr. Sie ist damit verhältnismäßig kurz.

Qualitätssteigerung
Zusätzliches Potenzial liegt in einer RPA-bedingten Qualitätssteigerung der Prozessbearbeitung. Menschliche Prozessbearbeitung birgt ein Risiko für (unsystematische) Erfassungs- und Ausführungsfehler. RPA-Software dagegen nicht – sofern diese richtig konfiguriert und die „RPA-Artefakte“ korrekt entwickelt worden sind. Um systematische Fehler auszuschließen, sind entsprechend umfangreiche Vorarbeiten und Tests erforderlich.

Zeiteinsparung
Eng mit der Kostenreduktion geht die mögliche Zeiteinsparung durch RPA einher – bezogen auf die Prozessdurchlauf- oder Prozessbearbei­tungszeit (je nach Messgröße). Die beiden bedingen sich oft gegensei­tig. Reduziert sich die benötigte Zeit, sinken im Regelfall auch die Prozesskosten (durch die geringere Bindung von Mitarbeiter- und IT-Kapazitäten). Dennoch kann auch eine Zeiteinsparung für sich genom­men einen Vorteil bedeuten. Grade in Prozessen, in denen der (externe) Kunde direkt oder indirekt involviert ist, bedeutet eine Geschwindigkeits­steigerung Wettbewerbsvorteile und erhöht die Kundenzufriedenheit.

Weitere Potenziale
Reduktion von Compliance-Risiken: Anstatt Compliance-Risiken zu generieren, hilft RPA bei deren Beseitigung. Ein einmal vorgabenkon­form entwickeltes und vor Anpassungen geschütztes RPA-Artefakt ist nur schwer (gewollt oder ungewollt) zu verändern. Missbräuchlich zu handeln, ist nur noch sehr eingeschränkt möglich. Zusätzlich wird jeder Schritt, jede Systemeingabe des Roboters dokumentiert (meist sowohl innerhalb der Zielanwendungen als auch zusätzlich in einer RPA-eigenen Dokumentation) und ist damit vollumfänglich durch Dritte prüfbar.
Reduktion der Time-to-Market: RPA kann die Time-to-Market drastisch reduzieren. Während der Markt zunehmende Flexibilität und Geschwindigkeit in allen Handlungen fordert, dauert die Anpassung vorhandener Prozesse oft zu lange. RPA kann hier schnelle Lösungen liefern, um Prozesse an neue Gegebenheiten anzupassen. Eine alternative Anwendungsentwicklung oder die IT-seitige Anpassung von Anwendungen würde mehr Zeit kosten und ist für eine Sparkasse, die zentral bereitgestellte Software-Lösungen nutzt, nur stark eingeschränkt möglich. 
Entlastung der IT: RPA kann eine Entlastung für die IT bedeuten. IT-seitige Prozessanpassungen besitzen – sofern es sich um Prozessoptimierungen und damit Kann- statt „Muss-Anpassungen“ handelt – meist eine niedrige Priorität. Dies kann die Dauer einer IT-seitigen Prozessanpassung nochmals erhöhen. Auch hier bietet RPA eine Alternative, in dem die IT nur noch die Infrastruktur für die Software-Lösung bereitstellen muss.

Projekt: „Robotics in der Naspa“

 
Die Nassauische Sparkasse gehört zu den erfolgreichen Vorreitern für Robotic Process Automation (RPA) in der Sparkassen-Finanzgruppe.
Die Nassauische Sparkasse (Naspa) vollzieht in einem breit aufgesetz­ten Strategieprogramm (Naspa 4.0) verschiedenste grundlegende Veränderungen. Bestandteil eines separaten Programmpakets ist dabei das Themenfeld „Automation“. Eine 2017 von der Naspa begonnene Vorstudie zum Thema „Robotics“ bzw. RPA hat die grundlegende technische Umsetzbarkeit innerhalb der eigenen IT-Infrastruktur bestätigt. Im Herbst 2018 ist deshalb das Pilotprojekt Robotics zur Einführung und Verankerung von RPA in der Naspa gestartet. Geplant (zum Zeitpunkt der Entstehung des Artikels im März 2019) war dafür eine Laufzeit von sechs Monaten, sodass es kurz vor erfolgreicher Beendigung steht.

Das übergeordnete Ziel des Pilotprojekts war, die „Toolbox“ Robotics zu erschließen, das heißt die RPA-Technologie in das eigene Institut zu integrieren und zugleich das für eine zielgerichtete Nutzung erforderliche Know-how aufzubauen.

Pilothafte RPA-Implementierung und Gesamthauspotenzialanalyse im Fokus

Neben der Klärung technischer Aspekte waren auch organisatorische Fragen zu beantworten und Automatisierungspotenziale auf Gesamthausebene zu analysieren. Hieraus ergaben sich folgende Arbeitspakete:
  1. Technische Implementierung der RPA-Technologie
  2. Organisatorische Implementierung der RPA-Technologie
  3. Auswahl und Automatisierung des Pilotprozesses
  4. Gesamthauspotenzialanalyse.
Erarbeitet worden sind die Projektziele in Verantwortung des Projektleiters Lukas von Eicken, durch ein Projektteam aus Mitarbeitenden des Fachbereichs Organisation und des IT-Managements, begleitet durch die Unternehmensberatung Deutsche Consulting Partner (DCP) aus Düsseldorf unter Leitung von Mario Smeets.

Der Fokus in der ersten Hälfte der Projektlaufzeit lag auf der technolo­gischen Umsetzung (IT-Backend, Software, Datenbank, IT-Sicherheit, Berechtigungen) und dem „Streamlining“ (also einer Verbesserung/ Optimierung) des Pilotprozesses als Vorarbeit zur Bot-Programmierung. Die mit dem auftraggebenden Vorstand vereinbarte Maxime im Projekt­vorgehen lautete: „Hands-On“. Das Projekt musste deshalb schnell umgesetzt und Problemstellungen sukzessive, zum Zeitpunkt ihres Auftretens gelöst werden.

In der zweiten Hälfte der Projektlaufzeit lag der Fokus auf der eigentli­chen Programmierung des Roboters sowie dem Aufbau und der Verfei­nerung des Naspa-individuellen Fachkonzepts „Automation“. Letzteres würdigt vor allem die relevanten Aspekte aufsichtsrechtlicher Vorgaben wie der MaRisk sowie notwendiger Governance-Regeln für einen dauerhaften RPA-Einsatz.

 
© BBL
Parallel zur pilothaften Prozessautomatisierung ist die Gesamthaus­potenzialanalyse (Arbeitspaket IV) durchgeführt worden. Die laufenden Erkenntnisse aus der pilothaften Automatisierung konnten direkt für die Ermittlung des RPA-Gesamthauspotenzials verwendet werden. Abbildung 1 zeigt die eingesetzte Vorgehensweise.

Ausgewählter Pilotprozess: Kontomodellvariantenwechsel

Die Gesamthauspotentialanalyse hat Automatisierungsmöglichkeiten in verschiedensten Unternehmensbereichen aufgedeckt. Insgesamt sind 600 interne und ausgelagerte Prozesse analysiert und auf Basis der vorliegenden Prozessdokumentationen hinsichtlich ihres Automatisie­rungs­potenzials bewertet worden. Einer dieser Prozesse war der spätere RPA-Pilotprozess „Kontomodellvariantenwechsel“. Ausschlaggebend für die Wahl als Pilot waren nicht primär monetäre Kriterien. Ziel war es vielmehr, einen bankfachlich relevanten Prozess zu finden, der automatisierbar ist und zugleich wenige kritische Elemente enthält, sodass mögliche Fehler und Ausfälle nicht geschäftskritisch sind. Auch die Mengengerüste sollten überschaubar bleiben, um die manuelle Bearbeitung als „Fallback-Lösung“ nutzen zu können. Vor dem Hintergrund dieser Rahmenbedingungen ist der genannte, nachgelagerte Sachbearbeitungsprozess ausgewählt worden.

Prozessanpassungen und Herausforderungen
Schnell haben sich deutliche Abweichungen zwischen Prozessdoku­men­tation und -ausführung beim Dienstleister herauskristallisiert – die weithin bekannten Abweichungen zwischen Theorie und Praxis. Zusätz­lich konnten diverse historisch gewachsenen Tätigkeiten, die bei näherer Betrachtung nicht mehr sachdienlich gewesen sind, aus dem Prozess entfernt werden.
Besondere Herausforderungen haben die Abstimmungen über den Umgang mit Spezialfällen und die Höhe des Standardisierungsgrads – im Spannungsfeld zwischen einer möglichst reibungslosen Automa­tisie­rung und einer möglichst kundenindividuellen Online-Prozessstrecke – geboten. Im Ergebnis konnten zahlreiche Prozessschleifen entfernt und der Standardisierungsgrad erhöht werden. Zugleich sind die Anforderungen des prozessverantwortlichen Fachbereichs und letztlich der Kunden an Individualität nach wie vor bedient worden.

Abgrenzung und Einordnung RPA zu OSPlus-Neo und ISP (BdZ)

Als individuelle Einzellösung ist RPA in der Naspa eine Besonderheit und steht im Spannungsfeld zwischen OSPlus-Neo, der Interaktiven Serviceplattform (ISP) und den Implikationen des „Betrieb der Zukunft“ (BdZ). Im DSGV-Projekt BdZ werden unter anderem Automatisierungs­potenziale der gesamten SFG bewertet und Lösungen zu deren Hebung pilotiert – darunter auch RPA. Es greift das Grundprinzip „zentrale Entwicklung und Rollout eines Standardprozesses“. Dafür stehen zentrale (Technologie-)Lösungen im Fokus, wie die oben beschriebenen DynPro oder Neo-Prozesse. Dies bringt hohe Rationalisierungseffekte mit sich, würdigt mögliche hausindividuelle Anforderungen aber nicht immer umfassend.

Mit RPA war eine vollständig fallabschließende Automatisierung des Pilotprozesses „Kontomodellvariantenwechsel“ möglich. Dieser berücksichtigt alle (noch verbliebenen) fachlichen Anforderungen (z. B. Aussteuerung von Private-Banking-Kunden, die den Online-Prozess angestoßen haben, um diese individuell anzusprechen). Die grundsätz­liche Ausrichtung der Naspa hin zu einer Prozessstandardisierung bleibt unverändert, weshalb etwa ein späterer Wechsel auf einen möglicher­weise weiterentwickelten Neo-Prozess nicht ausgeschlossen ist.

Fazit und Ausblick

Nach der 2017 durchgeführten Vorstudie und dem 2018/19 durchgeführten Pilotprojekt ist der größte und wertvollste Effekt bei der Naspa der große Know-how-Gewinn im Bereich der Prozessautomation und den damit verbundenen Herausforderungen. Das Pilotprojekt belegt, dass eine große Sparkasse ausreichende RPA-Automatisierungs­poten­ziale und zum anderen Ressourcen zu deren Hebung und zum Aufbau einer „Toolbox Automation“ besitzt.

Auf Basis der Erfahrungen aus dem Pilotprojekt lassen sich die Automa­ti­sie­rungskosten (inklusive externer Unterstützung für Bot-Programmierung) für weitere RPA-Prozessautomatisierungen in der Naspa auf rund 30.000 bis 50.000 Euro pro Prozess prognostizieren.

Aktuell (März 2019) steht das Pilotprojekt kurz vor seiner formellen Beendigung – mit guten Ergebnissen und einer Zielerreichung nach Plan. Aufgrund der parallel durchgeführten Gesamthauspotenzialanalyse wird intern bereits ein Folgeprojekt geplant und abgestimmt. Ziel soll es sein, mehrere Prozessoptimierungen und -automatisierungen individuell und Tool-unabhängig (ISP, OSP-Neo, RPA, ggf. weitere) durchzuführen. Grundlage ist die nun gefüllte „Toolbox Automation“ – denn ohne umfassendes Know-how keine Automatisierung.

Autoren
Lukas von Eicken ist Projektleiter Robotics bei der Nassauischen Sparkasse in Wiesbaden.
Mario Smeets ist Head of Process Management Practice bei DCP Deutsche Consulting Partner GmbH in Düsseldorf.