Die Überschrift klingt reißerisch und ist es natürlich auch – Clickbaiting olé! Bei LinkedIn hatte ich einen spannenden Austausch zum Thema regulatorische Anforderungen an Bots und RPA. Die Gedanken und Ansätze, wie aus dem Sturz in den Abgrund das sichere Befahren einer Küstenstraße wird…
Robot Process Automation – Was ist das?
Das Abspielen von Arbeitsschritten in unterschiedlichster Software. Sehr vereinfacht gesagt: Excel-Makros inkl. des Makrorecorders, nur eben nicht mehr nur in Excel, sondern verbunden mit allen möglichen weiteren Programmen, wie SAP, Dateiablage oder dem Kernbankensystem.
Warum ich den Excel-Makrorecorder erwähnt habe? Weil so eine Funktionalität in der Software enthalten ist – ich kann meine menschlichen Clicks aufnehmen lassen und die Software überführt sie in einen Algorithmus. Zur Wahrheit gehört an dieser Stelle, dass ein derartig aufgenommener Algorithmus meist für einen Spezialzweck nützlich ist, aber noch nicht um eine generelle Prozessaktivität zu automatisieren.
Die einfache Bedienung durch den Fachbenutzer wird immer wieder gepriesen – Microsoft spricht beispielsweise vom "Citizen-Developer". Wenig Einbindung der IT, einfache Bedienung und geringe Betriebskosten – endlich haben wir den heiligen Gral der IT gefunden.
Zusammenfassend zitiere ich einen der großen Anbieter: „Mit RPA erstellen Software-Nutzer Softwareroboter oder „Bots“, die lernen, nachahmen und anschließend regelgestützte Geschäftsprozesse ausführen können. Die RPA-Automatisierung ermöglicht es Nutzern, durch Beobachten menschlicher digitaler Aktionen Bots zu erstellen.“
Prüfung von Robotic Process Automation
Sie möchten auf einen Schlag geballtes Wissen tanken, was Ihr nächstes IT-Audit von 0 auf 100 bringt?
Hier anmelden!
Die regulatorische Herausforderung
Excel habe ich nicht nur wegen des Makrorecorders erwähnt. Es ist für mich der Inbegriff von individueller Datenverarbeitung (kurz IDV oder nach BCBS 239: „End User Computing“ bzw. EUC) und den damit verbundenen regulatorischen Anforderungen. Die MaRisk und die Konkretisierung innerhalb der Bankaufsichtlichen Anforderungen an die IT (BAIT) bzw. der VAIT für Versicherungen und KAIT für Kapitalverwaltungsgesellschaften geben hier den Rahmen vor.
In Ziffer 44 der BAIT finden wir Folgendes: „Vorgaben zur Identifizierung aller von Endbenutzern des Fachbereichs entwickelten oder betriebenen Anwendungen […] sind zu regeln (z.B. in einer IDV-Richtlinie).“ Erste kleine Erkenntnis für die IDV-Richtlinie: Ergänzung von potentiell spezifischen Anforderungen im Umgang mit RPAs.
Übrigens, der erste Impuls die RPAs durch die IT entwickeln und betreiben zu lassen zieht nicht: Für Anwendungen der IT sind die Anforderungen sogar höher.
BAIT - Erläuterungen zu Ziffer 44
Für einen Überblick und zur Vermeidung von Redundanzen wird ein zentrales Register dieser Anwendungen geführt und es werden mindestens folgende Informationen erhoben:
- Name und Zweck der Anwendung
- Versionierung, Datumsangabe
- Fremd- oder Eigenentwicklung
- Fachverantwortliche(r) Mitarbeiter
- Technisch verantwortliche(r) Mitarbeiter
- Technologie
- Ergebnis der Risikoklassifizierung/Schutzbedarfseinstufung und ggf. die daraus
abgeleiteten Schutzmaßnahmen.
Ob eine (Excel-)Anwendung als IDV eingestuft wird oder nicht, ergibt sich aus dem in den Erläuterungen zu Ziffer 44 angesprochenen „Ergebnis der Risikoklassifizierung[...]“. Warum auf einmal eine Risikoklassifizierung? Die MaRisk AT 7.2 Ziffer 5 gibt an dieser Stelle Auskunft: „Die Festlegung von Maßnahmen zur Sicherstellung der Datensicherheit hat sich am Schutzbedarf der verarbeiteten Daten zu orientieren.“
Was erstmal nach Arbeit klingt (ist es auch), kann als Erleichterung gesehen werden. Mittels nachweisbarer Risikoeinschätzungen kann die Einstufung als IDV vermieden werden. Fakt ist aus meiner Sicht: Es wird ein Prozess benötigt, um auch RPAs zu bewerten, zentral zu dokumentieren und ggf. „Maßnahmen zur Sicherstellung der Datensicherheit“ zu gewährleisten.
Die Umsetzung in der Praxis
Um das IDV-Drama mit Office-Dateien anzugehen, gibt es diverse etablierte Lösungen. Sei es EUC Insight von Cimcon oder auch Softwareprodukte von deutschen Anbietern. Bei RPAs ist mir bisher kein vergleichbares Inventarisierungs- und Dokumentationsprodukt bekannt. Ob es ein solches jemals geben wird? Ich bezweifele es.
Der Grund ist simpel: RPA-Lösungen bringen oft zentrale Orchestrator mit. Diese dienen dem Monitoring, der Provisionierung oder Berechtigungssteuerung der Bots – eben die Vince Medonzas der Digital Workforce. Innerhalb dieser Lösungen gibt es die Möglichkeit Tags, Ordner oder ähnliche Formen von Kategorien zu vergeben. Derartige Konzepte können natürlich auch für die Abbildung der Ergebnisse der Risikoeinschätzung genutzt werden.
Mit ein wenig Mehraufwand können in solchen Orchestratorn die Deployment-Prozesse so angepasst werden, dass sie „alle“ regulatorischen Anforderungen abbilden bzw. dokumentieren. Eben die geforderten „Maßnahmen zur Sicherstellung der Datensicherheit“. Einen Nachteil hat eine Dokumentation innerhalb der RPA-Tools: Die BAIT spricht von einem „zentralen Register“, nicht einem Register pro Anwendungstyp.
Die Krux mit Microsoft 365
Eine Herausforderung ist in meinen Augen die Automatisierungslösung von Microsoft mit seinen Flows. Innerhalb von Microsoft 365 – das RPA-Produkt heißt Power Automate bzw. Power Automate Desktop – sind einige Funktionen, die bei anderen Anbietern komfortabel mitgekauft werden können, durch den Kunden selbst zu lösen.
Microsoft bietet zwar mit seinem Center of Excellence (CoE) gute Beispiele und viele Lösungsansätze, diese müssen aber vom Kunden selbst eingebaut werden. Das CoE hat den Vorteil, dass es relativ leicht um z. B. einen Risikoklassifizierungsprozess erweitert werden kann. Automatisch bei Erstellen eines RPAs würde dieser gestartet und müsste vom Ersteller ausgefüllt werden.
Apropos Power Automate Desktop: Dieses kleine RPA-Tool wird Microsoft demnächst „at no additional cost“ mit Windows 10 ausliefern. Das Preview ist bereits verfügbar und in ersten Tests ist mir bei der kostenfreien Version ein wichtiger Unterschied zu der kostenpflichtigen Lizenz aufgefallen: Der zentrale Orchestrator von Microsoft ist nur in der kostenpflichtigen Variante enthalten.
Von den von mir „at no additional cost“ angelegten Flows fehlt in der zentralen Verwaltung jede Spur. Ich kann weder erkennen, dass es sie gibt, noch dass ich sie ausgeführt habe. Im Zusammenhang mit Power Automate Desktop sind mir aber auch noch einige andere Risiken aufgefallen, dazu aber zu anderer Zeit mehr. Da schließt sich der Kreis zum Titel des Blogeintrags: Mit Bots in der regulatorischen Abgrund.
Fazit
RPAs sind in vielen Unternehmen Alltag oder zumindest dabei Alltag zu werden – ohne jede Frage muss es also auch regulatorisch passen. Viele Lösungen bringen etwas mit, was bei den gängigen IDVs (wie Excel) schmerzlich vermisst wird: Eine zentrale Steuerung und Überwachung. Das ist auch der neuralgische Punkt, an dem die Anforderungen umgesetzt werden können.
Sie haben immer noch nicht genug
von Prüfung von RPAs?
Mit unserem Newsletter erhalten Sie
- aktuelle Artikel und Whitepaper,
- unsere Kategorien "schon gewusst?" und "was uns gerade inspiriert"
- und die aktuellen Termine unserer Audinare.
Was erhalten wir dafür?
- Die Chance Sie von uns und unserem Know-how zu überzeugen.