Entscheidungshilfe: 6 Kriterien für oder gegen einen RPA Einsatz – Teil 2

3 konkrete Punkte bei denen der Einsatz von RPA richtig ist (PRO)

Über den Author:


„Dipl.-Inform Olaf Neidhardt, geboren 1967, ist Unternehmer und BPM/Low-Code Evangelist mit Appian. Er steht für Prozessmanagement, dass Menschen in der IT und in der Fachabteilung gemeinsam mitnimmt und dabei in einem dynamischen Umfeld der Digitalisierung massiven finanziellen Nutzen erzeugt. Als zweiter verantwortlicher Lizenznehmer in Deutschland der US-Trendsoftware APPIAN, lange vor den jetzt folgenden Großkonzernen, verfügt er über ausgeprägtes Wissen rund um LowCode Development mit APPIAN. Dabei profitierten die Unternehmen enorm von seiner weit mehr als 20 Jahren Erfahrung in der Digitalisierung von Prozessen. Er gründete 2020 die international vernetzte appassionals GmbH mit dem Ziel, sich vor allem der Automatisierung von Prozessen rund um die LowCode/BPM Plattform APPIAN zu widmen. Für ihn waren die Begriffe „Application“, „Passion“ und „Professional“ die Basis, die der appassionals GmbH den Namen gaben.“

Teil 1
dieser kleinen Serie widmet sich der Frage ob es einen Konflikt zwischen meist Fachabteilungen, als Befürworter von RPA und meist IT Vertretern, eher als Skeptikern von RPA gibt und warum Low-Code eine meist unbeachtete Alternative darstellt.

Teil 2
nennt 3 konkrete Punkte bei denen der Einsatz von RPA richtig ist (PRO)

Teil 3
nennt 3 klare Kriterien, die gegen den Einsatz einer RPA Lösung sprechen (CONTRA)  und zieht ein kurzes Fazit.

Teil 2
3 konkrete Punkte bei denen der Einsatz von RPA richtig ist (PRO)

Im ersten Teil haben wir uns der Frage gewidmet, ob es einen Konflikt zwischen Vertretern der Fachseite, meist als RPA-Verfechter und der IT, meist als eher RPA Skeptiker, gibt. Wir schauen jetzt mal auf ein paar klare Kriterien, die sich in meiner beruflichen Praxis oder durch lokale Studien ergeben haben.

Welche Kriterien helfen also bei der konkreten Entscheidung für RPA und gegen Low-Code an einer bestimmten Stelle?

Grundsätzlich wird wohl niemand bezweifeln, dass eine saubere Architektur und funktionierende Schnittstellen und Services die beste Lösung für eine skalier- und leistungsfähige digitale Welt eines Unternehmens sind.

Aber die Argumente dagegen sind eben auch die Argumente der RPA Vertreter.

Die Projekte scheinen billiger, einfacher und „leichtgewichtig“. Sie setzen direkt am Problem an und die Fachabteilungen brauchen die IT nicht mehr für ihre Erfolge in der Digitalisierung. Im Endeffekt geht es damit schneller und das ist was in einem rasant voran schreitenden Digitalisierungsumfeld zählt.

Nun, ist dem wirklich so? Sind dies Argumente, die die RPA Technologie exklusiv für sich in Anspruch nehmen kann, und zwar eben gerade gegenüber einer Low-Code Alternative?

Viele zufriedene Nutzer einer Low-Code Umgebung (auch wenn sie, wie im Falle Appian, als Option RPA inkludiert), werden den genannten Vorteil so nicht sehen. Denn auch eine Low Code Umgebung ermöglicht schnellere und damit billigere Lösungen als ihre wesentliche Eigenschaft. Sie sind meistens „leichtgewichtiger“, denn genau das macht sie schneller und ermöglicht weiteren Benutzerkreise die Beteiligung, somit eben auch der Fachabteilung selbst. Low-Code Tools ermöglichen das in unterschiedlicher Abstufung, aber eigentlich alle RPA Tools sind da in der Realität eben auch nicht besser, als ihre Low-Code Kollegen. Am Ende muss auch dort doch häufig der Arzt helfen.

Aber die Lösung setzt dennoch am Ende woanders an, als es ein Roboter tut. Nämlich nicht vor dem Bildschirm, sondern hinter der Fassade, am System, an Schnittstellen, architektonisch z.B. auf einer Workflow Ebene.

Und was vielleicht noch mehr zählt, die passiert als integriertes Element von Build und Testprozessen, Systemdokumenten, Nutzerrechten und Berichtswesen, wie es für jedes relevante IT Element (hier bewusst nicht „System“ gesagt) in einem gut gemanagten IT Bereich der Fall sein sollte, damit am Ende die Probleme nicht hinten durch die Tür wieder hereinkommen, die eben gerade vorne raus zur jubelnden Menge geschoben wurden.

Dennoch: RPA macht Sinn. Es gibt unzweifelhaft eine Reihe von Fällen in denen RPA Lösungen wirklich helfen, wenig oder keine Seiteneffekte haben oder schlicht unumgänglich sind.

Aber welche sind das?

Aus konkreten Fällen und Studien meiner beruflichen Vergangenheit habe ich 7 Kriterien gefunden, die für mich Hilfe bei der Entscheidung bieten:
„To RPA or not to RPA?“

Kriterium 1 :
Überbrückungstechnologie

Falls in Ihrem Unternehmen dringende Probleme an Schnittstellen bzw in Prozessen vorliegen, die einen ausreichenden Business Case generieren, für die im Moment (nicht länger als 1 Jahr), bis zum nächsten Erfüllungs-Termin, bzw bis zum aktuellen Zusammenbruch Ihrer Mitarbeiter keine andere IT Lösung im Einklang mit Ihren generellen Digitalisierungsbemühungen gefunden werden kann, dann kann eine RPA Lösung Ihre Symptome lindern.

Wichtig ist hier nur, vor dem Hintergrund der bereits gebrachten Argumente, sich nicht der Ansicht hinzugeben, dass das Pflaster Ihr Knie heilen wird, oder auch nur die Probleme in ihren IT Budgets in den kommenden Jahren verbessern wird.

Ist also eine Schnittstelle geplant, aber noch nicht fertig oder umgesetzt; ist eine Systemablösung vorgesehen, aber eben noch nicht da oder wurde beschlossen eine Applikation in Services aufzulösen, aber es ist noch nicht überall geschehen, dann ist RPA möglicherweise gut geeignet, diesen Umstand zu überbrücken.

Dabei gehe ich davon aus, dass für den Umbau und dessen Dauer die Möglichkeiten der Low-Code Umgebung geprüft wurden, denn sonst schafft mangelnde Vorbereitung erst die Probleme, warum Umbauten so lange dauern und Überbrückungsmaßnahmen ergriffen werden müssen.

Dauert die RPA Lösung wieder so lange, wie die Low-Code Lösung, dann: Finger weg.

In jedem Fall seien Sie sich des Risikos bewusst, dass eine einmal geschaffene Lösung meistens viel, viel länger bleibt, als Sie heute glauben. Werden also Ihre Entscheider heute schon den späteren Umbau mit Etat vorsehen?

Kriterium 2  :
Zugriff auf schnittstellenlose Fremdtechnologie

Ihre Kollegen nutzen eine Webseite eines anderen Anbieters für ihre Arbeit? Sie schlagen dort Preise nach, erhalten Auskünfte oder erteilen Aufträge?

Und sie haben einfach keine Möglichkeit eine Anbindung an dieses Unternehmen zu erstellen, weil entweder

  • Der Anbieter keine Schnittstelle, sondern nur eine Website bietet
  • Sie zu wenige Aufgaben täglich über diese Schnittstelle abwickeln, als dass sich eine Implementation aufgrund anderer Komplexitäten wirklich lohnen würde und Ihre Mitarbeiter sind trotzdem negativ betroffen?
  • Sie auf keinen Fall den Legacy-Tech-Stack des Anbieters der Schnittstelle ins Haus bekommen wollen?
  • Sie der Sicherheit der Schnittstelle des Anbieters keinesfalls vertrauen?

Dann steht einer Nutzung von RPA aus meiner Sicht nichts im Wege. Low-Code Umgebungen helfen hier nicht, da sie meist kein Screen Scraping als Integrationstechnologie anbieten und ihren Informationsfluss über definierte Schnittstellen erwarten. Zwar kann man diese unter zu Hilfenahme von weiteren Werkzeugen herstellen, aber das ist am Ende wieder ein “Pflaster“, dass niemand in seiner IT möchte.

Kriterium 3 :
Einfache technische Tätigkeiten

(z.B. Daten extrahieren, verändern, kopieren, einfügen und verschieben) typischerweise im Rahmen von Anwenderapplikationen (z.B. MS Office, Webseiten)

In vielen Betrieben teilt sich die IT-Landschaft, unter anderem weil Workflow und Low-Code in den Betrieben keine oder kaum eine Rolle spielen, in zwei drei große Gruppen. Dort sind zunächst einige schwergewichtige Anwendungen, besser häufig bekannt als Backend- oder Entity-Systeme. Dann gibt es einige unterstützende Systeme, für bestimmte meist spezielle oder wiederkehrende Problemstellungen. Und dann ist da ein ganzer riesiger Sack voller kleinerer Anwendungen. Gerne in MS-Office dargestellt. Entweder in „kleinen“ Office VBA Applikationen oder auch nur in vielfach geteilten Excel oder Word Dokumenten, die dann mit ganzem Körpereinsatz täglich kopiert oder mittels Makros oder Batch Dateien hin und her bewegt werden.

Diese „kleinen“ Anwendungen sind in Regel aber weder „klein“ noch „unbedeutend“. Sie sind häufig System-kritisch.

Die Access Datenbank funktioniert schon lange nicht mehr performant, hält den Arbeitsfortschritt auf und bei so manchem Office Update, dass die IT verteilt hat trat der Schweiß ins Gesicht der örtlichen Kollegen, weil „….seit heute Morgen nichts mehr geht“.

Im der Finanzbrache sind diese Anwendungen im Sinne der Bankenaufsicht „systemkritisch“ und für Fragen des „Business Continuity Management“ relevant.

Die BAFIN hat in der Vergangenheit die Frage aufgeworfen, ob diese Anwendungen der Gruppe der gemanagten IT–Anwendungen, den sogenannten Anwendungen der „individuellen Datenverarbeitung (IDV)“ oder einfach persönlichen unrelevanten Spielereien zuzuordnen sind. Daran knüpfen sich reichlich Kriterien, Folgenabschätzungen und geradezu verbissene Kleinkriege zwischen der Fachabteilung und der IT über die Einordnung und den Umgang damit. Denn die Konsequenz sind Versions-Repositories, Sicherheitseinschätzungen, Dokumentationen, Handbücher, Wiederanlaufverfahren und manchmal letzten Endes die Ablösung. Die Fachabteilung bezeichnet das dann nicht unberechtigt als „Wegnahme“ und Einmischung der IT.

Diese Diskussion allein zeigt bereits, dass diese „Kleinapplikationen / IDV’s“ ein perfektes Spielfeld für mindestens eine Low-Code Umgebung oder ein Workflow Tool, wie zum Beispiel Appian sind, da sie der gesamten Diskussion durch ihren fundierten und compliance mäßig abgesicherten Auftritt komplett den Boden entziehen.

Aber die Verbreitung ist noch zu gering, und vielleicht steht Ihnen selbst kein solches Tool zur Verfügung.

Ohne Zweifel stellt RPA dann eine mögliche Lösung dar, völlig unnötige und mit allen Office Lösung immer wiederkehrende Tätigkeiten des Kopierens, Einfügens, Verschiebens und Vervielfältigens von Information („…dieses kleine Datum muss auch noch in diese, diese und diese Datei, die dann an diesen, diesen und diesen Kunden (bzw. Ablage oder Mülleimer) geht“) zu automatisieren und den armen Mitarbeitern abzunehmen. Übrigens würden Sie vermutlich gar nicht glauben, wie viele Menschen gerade diese Tätigkeiten Tag ein und Tag aus geradezu abgöttisch lieben und immer wieder gegen Angriffe von außen verteidigen.

Tun Sie es also! Setzen Sie an dieser Stelle gern auf RPA.

Aber hüten Sie sich davor dabei gleich noch Transformationen, Aggregationen oder Umformungen vorzunehmen und einen eigentlich vorhandenen, aber nicht abgebildeten Prozess in dem nächsten System zu verstecken, der nicht ihrer allgemeinen Governance und Transparenz Bemühung folgt.

Lesen Sie weiter in Teil 3 über 3 CONTRA Argument gegen den Einsatz einer RPA Lösung und das Fazit dieser kleinen Serie..

Teil 1 widmete sich der Frage, ob es einen Konflikt zwischen RPA Vertretern, üblicherweise in Fachabteilungen und Low-Code Vertretern, üblicherweise in der IT, gibt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

* Falls Sie mit uns bloggen wollen, müssen wir Sie leider bitten unsere Datenschutzbestimmungen zu akzeptieren.