Diskussion: RPA ist kein „süßes Gift“ – erst Dosis und falsche Anwendung lassen es hierzu werden

Gestern sprach Jakob Freund (CEO Camunda Services) Klartext und nannte drei Gründe, warum falscher RPA-Einsatz ein süßes Gift ist (“Warum RPA die Transformation behindert“). Nun steigt auch Mario Smeets (Management-Berater bei DCP Deutsche Consulting Partner) in den Ring und hält dagegen, denn “RPA ist kein süßes Gift – erst Dosis und falsche Anwendung lassen es hierzu werden”. Ein spannender Diskurs.

von Mario Smeets, Management-Berater DCP Deutsche Consulting Partner 

Vor vielen hundert Jahren stellte Paracelsus schon fest: „Alle Dinge sind Gift, und nichts ist ohne Gift; allein die Dosis machts, daß ein Ding kein Gift sei.“ Ob er damit den Einsatz von RPA in der Finanzwirtschaft meinte, bleibt fraglich. Doch wie in so vielen Bereichen gilt seine Aussage auch hier.

Im gestern veröffentlichten Beitrag stellt Jakob Freund verschiedene Thesen zum Einsatz von RPA auf. Zusammengefasst:
1. Es besteht die Gefahr, dass eigentlich notwendige IT- bzw. digitale Transformationen durch den Einsatz von RPA gefährdet und ausgebremst werden.
2. RPA sollte nicht für Kernprozesse genutzt werden; hier sind vielmehr Anpassungen an den (alternativ durch RPA zu automatisierenden) zugrundeliegenden Anwendungen sinnvoll.
3. RPA schafft die Gefahr, dass sich einzelne “Center of Excellence” innerhalb der Fachbereiche bilden, was eine mögliche „Schatten-IT“ entstehen lassen kann.

Wenngleich sich einige unterstützende Argumente für diese Thesen finden lassen, so finden sich mindestens ebenso viele Argumente hiergegen.”

Zu 1.: RPA sollte vielmehr (strategischer) Bestandteil der digitalen Transformation sein, anstatt diese auszubremsen.

In den Anwendungslandschaften der Finanzinstitute sind nach wie vor Unmengen von Altsystemen (“legacy systems”) im Einsatz. Entsprechende Neuerungen sind zwingend notwendig, um mit Marktentwicklungen und den Anforderungen einer fortschreitenden Digitalisierung von Prozessen Schritt halten zu können.

Dies bedeutet jedoch nicht, dass der Einsatz von RPA eine “Pflasterlösung” darstellt, also nur die eigentlich erforderliche Erneuerung eines Altsystems ersetzt. Arbeitet das Altsystem langsam, zum Beispiel bei Maskenwechseln, ist hiervon auch RPA betroffen. Agiert das Altsystem in seinen Prozessabläufen unhandlich und nicht mehr zeitgemäß, so ist RPA hier ebenfalls von betroffen. RPA kann seine vielfältigen Potenziale hier nicht entfalten. Die erforderliche Erneuerung der Altsysteme wird somit keinesfalls obsolet.

Diese Meinung herrscht aber auch nicht vor – zumindest nicht in den IT- und Organisationsbereichen der Finanzinstitute. Erfahrungen aus Umsetzungsprojekten und Gesprächen mit Experten und Entscheidern aus den entsprechenden Bereichen zeigen: Es ist bekannt und bewusst, dass RPA eben keine “Pflasterlösung” ist. Vielmehr ist RPA eine Chance, die eigene time-to-market zu erhöhen, indem erforderliche oder vom Markt verlangte Prozessveränderungen schnell und mit verhältnismäßig geringem Aufwand umgesetzt werden können. Dies oft schneller, als es mit einer umfangreichen und im Regelfall langwierigen Anpassung in den (Kern-) Anwendungen der Häuser der Fall wäre.

1. Die genannte Gefahr einer Ausbremsung von IT- und digitalen Transformationen würde nur dann bestehen, wenn RPA ausschließlich von Fachbereichen verwendet und vorangetrieben werden würde.
2. Es ist erforderlich, dass auch die IT- und Organisationsbereiche, die die Zusammenhänge und technischen Hintergründe aller Systeme und Anwendungen kennen, in die Implementierung von RPA und – genauso wichtig – in die strategische Ausrichtung von RPA innerhalb der Organisation eingebunden werden.
3. Durch diese Zusammenarbeit von Fach- und IT-/ Organisationsbereichen ist sichergestellt, dass a) RPA nicht als entwicklungshemmende „Pflasterlösung“ genutzt wird und b) eine hoch flexible Möglichkeit für kurzfristige Prozessanpassungen besteht (wodurch es als Zusatzeffekt zu einer Entlastung der IT-Bereiche kommt. Diese können sich wiederum auf die Weiterentwicklung oder den Austausch von Altsystemen kümmern, ohne von in immer kürzeren Zyklen auftretenden Anforderungen an Prozessveränderungen „vorangetrieben“ zu werden).

Zu 2.: Auch für die Automatisierung von Kernprozessen kann RPA eine geeignete (Teil-)Lösung bieten

Die Empfehlung, RPA nicht für Kernprozesse einzusetzen, darf nicht pauschal gelten. In einem ersten Schritt ist zu definieren, welche überhaupt die organisationseigenen Kernprozesse sind. Sicherlich sind viele hiervon so relevant und im Zeitablauf stabil (also nicht zu stark durch anhaltend neue Anforderungen an Prozessanpassungen getrieben), dass sich eine vollständige Abbildung und ggf. Automatisierung innerhalb der Kern-(bank-)Systeme anbietet. Wird aber in einem zweiten Schritt festgestellt, dass ein betroffener Kernprozess Anwendungen nutzt, zu denen beispielsweise eine Schnittstellenbildung unmöglich ist, kann RPA auch hier eine sinnvolle Ergänzung bieten.

Vor einer pauschalen Ablehnung von RPA zur Automatisierung der eigenen Kernprozesse ist eine differenzierte Prüfung jedes einzelnen Prozesses erforderlich.”

Zu 3.: Ein einziges, zentralisiertes „Center of Excellence“ mit Beteiligung von Fach- und IT-Seite verhindert das Entstehen einer Schatten-IT und reduziert Risiken im produktiven Einsatz von RPA

Es stellt sich zunächst die Frage, was überhaupt unter einem “Center of Excellence” (CoE) verstanden wird. Meistens ist dies die Kombination aus dem für die RPA-Implementierung und den RPA-Betrieb verantwortlichen Team mit den Regelungen für den RPA-Einsatz in der eigenen Organisation.

Ein solches CoE soll­te nicht un­ge­plant, un­ge­steu­ert und erst im Zeit­ab­lauf ent­ste­hen, son­dern viel­mehr früh­zei­tig und ge­mein­sam mit der RPA-Im­ple­men­tie­rung – ge­plant und sys­te­ma­tisch – auf­ge­baut wer­den.  Um das Pro­blem der Bil­dung de­zen­tra­ler CoEs in­ner­halb der Fach­be­rei­che zu ver­mei­den, emp­fiehlt sich die Eta­blie­rung ei­nes zen­tra­len CoE. Die­ses kann or­ga­ni­sa­to­risch bei­spiels­wei­se dem zen­tra­len IT- und/ oder Or­ga­ni­sa­ti­ons­be­reich zu­ge­ord­net wer­den. So sind die en­ge Ver­knüp­fung von RPA mit IT-Stra­te­gie, IT-Know-How und ein zen­tra­ler Wis­sens- und Ver­ständ­nis­auf­bau rund um RPA si­cher­ge­stellt. Zu­sätz­lich lässt sich hier­mit den mög­li­chen Ri­si­ken durch den Ein­satz von RPA be­geg­nen: Es ent­steht kei­ne „IT-Schat­ten­wirt­schaf­t“, Re­lease­zy­klen der RPA-Sys­te­me und al­ler au­to­ma­ti­sier­ten An­wen­dun­gen las­sen sich über­wa­chen und steu­ern, usw.

RPA an sich ist also kein Gift, auch kein süßes. Die richtige Dosis und die richtige Anwendung ermöglichen eine wenig gefährliche Nutzung der Potenziale, die die Technologie bietet.”

Wie Jakob Freund richtigerweise feststellt: Der Druck auf das Top-Management, Investitionen in die IT-Infrastruktur zu tätigen, darf durch die Nutzung von RPA keinesfalls sinken. Ein strategisch und umfassend geplanter Einsatz von RPA kann hier aber sogar Freiräume und mittelfristig auch Kostenersparnisse schaffen, um die erforderliche Erneuerung von Altsystemen endlich anzugehen.aj