Organisatorische Aspekte einer automatisierten Datenmigration

Unsere Erfahrungen aus einem Kundenprojekte in der Energiebranche bereiten wir in einer dreiteiligen Serie auf. Erfahren Sie wie Datenmigration mit RPA gelingt, welche organisatorischen Rahmenbedingungen beachten werden müssen und wie RPA-Entwicklung mit mateo umgesetzt werden kann.

Im ersten Teil unserer Blog-Reihe haben wir erläutert warum RPA als Lösungsansatz für Datenmigrationen geeignet sein kann und welche Schritte in einem Projektablauf notwendig sind. An jedem dieser Schritte sind unterschiedliche organisatorische Einheiten beteiligt, die jeweils eigene, oft konkurrierende Interessen und Anforderungen an den geplanten Prozess mitbringen.

Nun wollen wir diese potenziell konfliktgeladene Situation untersuchen und zeigen, wie die unterschiedlichen organisatorischen Anforderungen zu einer Lösung verwoben werden können. Eine besonders wichtige Rolle spielen die verschiedenen Sicherheitsaspekte.

Das Vorhaben Datenmigration

Die beschriebene Fallbetrachtung drehte sich um die Notwendigkeit, einen Teil der Stammdaten in einen anderen Mandanten innerhalb des ERP-System zu übertragen. Im ersten Teil dieser Blog-Serie haben wir untersucht, welche Alternativen es zu einer RPA-Lösung gibt und herausgearbeitet, warum diese doch die bessere Lösung war. Alle Ansätze hatten jedoch den gleichen Grundansatz:

• Daten extrahieren (extract)
• Daten transformieren (transform)
• Daten einspielen (load)

Lediglich in Zeitpunkt und Werkzeugen, also der Art "wie" ein Schritt umgesetzt wird, unterscheiden sich die einzelnen Methoden. Ein manueller Übertrag der Daten baut auf den gesunden Menschenverstand und das Fachwissen der umsetzenden Person. Automatisierte Lösungen müssen diese Kenntnisse informationstechnologisch abbilden. Hierfür werden besagte Kenntnisse dennoch benötigt. Der Kreis der Akteurinnen und Akteure wächst damit und mit einem größeren Kreis Beteiligter, entsteht auch ein Interesse in Unternehmensbereichen, die scheinbar erst einmal nichts mit dem Vorhaben zu tun haben. Sicherheitsthemen beim Umgang mit sensiblen Daten, die eine verantwortliche Gruppe verlassen, kommen auf. Betriebsräte sehen ebenfalls mit Argusaugen auf Automatisierungslösungen und haben ganz eigene Ansprüche. Je nach Thema kann auch eine juristische Einheit Anforderungen haben, etwa zu Themen der Revisionssicherheit oder Vertragsfragen.

Somit kommen zu den fachlichen Regelwerken, also der Beschreibung der Transformation, weitere Interessensgruppen mit eigenen Anforderungen hinzu. Bindet man diese nicht frühzeitig in den Prozess ein, besteht die Gefahr des Scheiterns, obwohl man fachlich und technisch sauber gearbeitet hat.

Interessengruppen

Fachabteilung

Da eine konkrete Fachgruppe mit der Migration beauftragt war, lag natürlich dort zunächst die Hauptverantwortung für die Anforderungserfassung. Dabei ist aufgrund des Ist-Zustands der Daten, die durch die lange Lebensdauer des Quellsystems lücken- und teilweise fehlerhaft sind, bereits eine wichtige Frage, welche konkreten Daten beim Zielmandanten ankommen sollen. Wie sollen also Lücken gefüllt werden oder welcher Teildatensatz soll verwendet werden, wenn zwei gleichberechtigte ohne eindeutige Gültigkeitskriterien existieren (etwa doppelt gepflegte Adressen). Da die Fachabteilungen üblicherweise auf einzelnen Datensätzen arbeiten und selten einen aggregierten Blick auf einen Teilbestand haben, wird hier bereits die Hilfe von IT-nahen Abteilungen benötigt. Im betrachteten Projekt unterstützte das Team für die Einrichtung der RPA-Lösung. Alternativ können Systemverantwortliche und Datenbankadministratorinnen und -administratoren die Voranalyse durchführen.

In unserer Fallstudie bleiben die Daten innerhalb desselben Systems. Die Herausforderung, eine Transformation von einem Quell- in ein Zielsystem zu definieren, steigt noch, wenn die betroffenen Systeme unterschiedliche Datenmodelle haben oder Daten in mehrere Zielsysteme aufgeteilt werden müssen. Ein klassisches Beispiel ist der Umgang mit dem Straßennamen und der Hausnummer. Gehört beides in ein Feld oder muss es getrennt werden? Während diese Frage noch durch relative einfache Transformationsschritte gelöst werden kann, kann es in anderen Fällen eine größere Herausforderung darstellen, z. B. bei der Handhabung von natürlichen und juristischen Personen.

Operations- und Betriebsmanagement

Mit einem bzw. mehreren Robotern im Betrieb können unvorhergesehene Seiteneffekte für das tägliche Geschäft entstehen. RPA-Lösungen zeichnen sich durch ihre Ausdauer aus, d. h. im Gegensatz zu Menschen können die Roboter ohne Pausen über längere Zeiträume in potentiell höherer Aktivität agieren. Bei der Entwicklung komplexer Systeme werden zwar häufig "nicht funktionale" Anforderungen bzgl. Reaktionszeiten und Belastbarkeit gestellt. Diese orientieren sich in der Regel aber an der Leistungsfähigkeit von Menschen. Parallel arbeitende Roboter, die immer die gleiche Aufgabe wiederholen, können unter Umständen eine unerwartete Last und damit negative Auswirkungen auf die Arbeit der üblichen Anwenderinnen und Anwender erzeugen. Die Gruppe, die für den Betrieb zuständig ist, hat damit ein Interesse daran, das Verhalten der RPA-Lösung zu verstehen und zu bewerten.

Ein weiterer Aspekt sind konkurrierende Zugriffe durch andere automatisierte Prozesse außerhalb normaler Arbeitszeiten. Nächtliche Batchläufe können Systeme so stark auslasten, dass normales Arbeiten nicht mehr möglich ist – was ja der Hauptgrund ist, diese Prozesse in der Nacht laufen zu lassen. Damit ist das erwartete Verhalten einer automatisierten Oberfläche nicht mehr garantiert, der Roboter kann nur bedingt oder unter Umständen gar nicht zum Einsatz kommen.

Fachabteilungen bzw. Personen, die mit den Systemen interagieren, welche mit Hilfe des RPA-Ansatzes automatisiert werden sollen, wissen meist von den Dingen, die über Nacht geschehen, kennen aber die Einzelheiten, insbesondere die Verfügbarkeit der Systeme nicht im Detail.

Daraus folgt die Notwendigkeit, das Betriebsmanagement beim Einsatz von RPA-Technologien einzubinden. Durch die hohe Arbeitsleistung, die in einer ungewöhnlich kurzen Zeit erbracht werden soll, ist dies sogar noch wichtiger als in vielen anderen Fällen.

IT-Abteilung und IT-Security

Der Einsatz von neuen Systemen bedarf, besonders in größeren Unternehmensgeflechten, häufig einer Freigabe. Für Testumgebungen sind Zustimmungen einfacher zu erhalten, im Falle eines produktiven RPA-Einsatzes ist jedoch mit weitreichenden Prüfungen zu rechnen. Dabei ist eine der ersten Fragen, die vom RPA-Projekt beantwortet werden muss, warum ein zusätzliches Roboter-System benötigt wird und warum die anstehende Aufgabe nicht mit bestehenden Mitteln bewältigt werden kann. Hier ist die Analyse, wie sie im ersten Teil der Blog-Reihe beschrieben wurde, ein wichtiger Bestandteil, um Entscheidungsträger und Entscheidungsträgerinnen zu überzeugen.

Ein RPA-System muss die gleichen Voraussetzungen erfüllen, wie andere im Einsatz befindliche Systeme. Größere Unternehmen haben hierfür üblicherweise eine Kriterienliste anhand welcher Fachabteilung und RPA-Team eine Prüfung durchführen und eventuelle Lücken vor einer Freigabe schließen können.

Neben den IT-Verantwortlichen kann es für eine Freigabe notwendig sein, dass spezielle Akteurinnen und Akteure für die IT-Sicherheit involviert werden müssen. Beim Thema Datenmigration gibt es neben gesetzlichen Voraussetzungen auch einen eigenen Anspruch darauf, die Daten des Kundenstamms zu schützen und sicherzustellen, dass die Möglichkeit für einen Missbrauch minimiert wird.

Sicherheit beim RPA-Einsatz

Die Frage nach der Sicherheit lässt sich in mehrere Aspekte unterteilen, die einzeln betrachtet werden sollen.

Threat-Modell: Darstellung des RPA- und Anwendungs-Kontext zur Identifizierung von Sicherheitsrisiken

Applikationssicherheit

Kommen automatisierte Skripte zum Einsatz und werden diese von einem Roboter ausgeführt, fehlt es an menschlichem Feingefühl. Eingaben in Masken können ohne Prüfung des Kontextes ausgeführt werden, auf Fehler- oder Warnmeldungen, die in der händischen Abwicklung selten oder gar nicht auftreten, kann nicht immer reagiert werden. Je nach System ist es also denkbar, dass ein Roboter „glaubt“, eine bestimmte Aufgabe auszuführen, in Wirklichkeit jedoch seinen vorgesehenen Pfad verlassen hat. So entsteht ein Risiko, schädliche Eingaben zu tätigen. Ein zwar eher konstruiertes aber nicht unmögliches Szenario wäre das unerwartete Auslösen einer Fehlerseite, auf der ein Mensch die Möglichkeit hat, einen Kundenservice zu kontaktieren. Gibt der Roboter hier Bankdaten ein, weil er glaubt in der entsprechenden Erfassungsmaske zu sein, verlassen sensible Daten den geschützten Bereich der Anwendung. Der Roboter muss also in der Lage sein, zu erkennen, dass vorgesehene Pfade verlassen wurden. Dies kann realisiert werden, in dem vor jeder Eingabe z. B. der Name des aktiven Fensters oder eine technische ID für ein Eingabefeld geprüft wird.

Betriebssicherheit

Wie bereits oben erläutert, kann intensiver Einsatz von Robotern die Betriebssicherheit beinträchtigen. Durch das von Menschen unterschiedliche Lastverhalten entstehen Risiken für die Stabilität anderer Prozesse, z. B. bei Batch-Läufen oder auch dem Arbeitsalltag. Die Vorbereitung der RPA-Lösung in einer Testumgebung kann Hinweise auf die Lastauswirkung geben. In Absprache mit dem Betrieb sollten die Einsatzzeiten für die Lösung abgestimmt werden. Bestehen Zweifel an den genauen Effekten in einer produktiven Umgebung empfiehlt es sich, die Last schrittweise zu erhöhen und auf Rückmeldungen zu warten.

Ablaufsicherheit

Eine andere Sicht auf das Thema Sicherheit ist die Frage nach dem tatsächlichen Ablauf eines automatisierten Prozesses. Zwar können die Skripte so gestaltet werden, dass Fehler abgefangen und dokumentiert werden und anschließend wieder auf eine fehlerfreie Strecke zurückzukommen. Das allein reicht aber nicht, um bei einmaligen Vorhaben wie z. B. einer Migration den Ablauf sicherzustellen. Auf erkannte Fehler muss reagiert werden. Für Fehler, die man vorher in dem automatisierten Ablauf identifizieren kann, können Vereinbarungen getroffen werden, wie damit umzugehen ist. Erwartete Fehler definieren sich z. B. durch bekannte Kombinationen von Daten, die bereits im Quellsystem fehlerhaft sind.

Auftretende Fehler müssen meist manuell bearbeitet werden, um eine konsistente Abwicklung zu erreichen. In bestimmten Fällen kann es aber auch dazu kommen, dass nachgelagerte Skripte bestehende Fehlerkonstellationen auslösen. Haben die Datensätze untereinander Beziehungen, kommt es zum Fehler, wenn die Beziehung nicht hergestellt werden kann, weil ein bestimmter Datensatz noch nicht angelegt ist. Nach Abschluss eines ersten Durchlaufs kann dann automatisch ein zweiter Lauf durchgeführt werden, der dann erfolgreich ist, weil der fehlende Datensatz im ersten Lauf angelegt wurde.

In jedem Fall muss der Ablauf vorher geplant werden. Wichtige Fragen sind Abbruchbedingungen bei hoher Fehlerzahl, Adressatinnen und Adressaten für den Empfang fehlerhafter Datensätze und das Verfahren, wie mit manuell korrigierten Datensätzen umzugehen ist.

Informationssicherheit

Letztendlich ist der vermutlich wichtigste Sicherheitsaspekt die Informationssicherheit. Im Fallbeispiel mussten personenbezogene Daten inklusive Informationen über Bank- und Zahlverbindungen transportiert werden. Diese Daten unterliegen gesetzlich besonderem Schutz und müssen dementsprechend besonders geschützt werden.

Hierfür wurde gemeinsam mit der Abteilung für IT-Sicherheit ein Threat-Modell aufgestellt und analysiert, um Risiken zu identifizieren und Gegenmaßnahmen zu erarbeiten.

Das Threat-Modell beinhaltet u. a. eine visuelle Darstellung der beteiligten Systeme, Ein- und Ausgangsschnittstellen sowie Informationen zur Datenhaltung (siehe Abbildung oben). Systemgrenzen und Verantwortlichkeiten werden einander entgegengestellt, ergänzt durch die Aktionen, die innerhalb eines automatischen Schrittes durchgeführt werden.

Zugriff auf Skripte und Dateien

Mittels dieser Threat-Analyse kann identifiziert werden, wo mögliche Angriffspunkte bestehen, z. B. dort, wo per SQL Injection Zugriff auf eigentlich geschützte Daten ermöglicht werden. Ist es wie im Fallbeispiel notwendig, Daten für einen Transformationsschritt zwischenzuspeichern, werden Sicherheitsmechanismen zum Schutz dieser Daten ausgehebelt. So werden Daten in ERP-Systemen in der Regel über verschlüsselte Kanäle in eine gesicherte Datenbank übertragen bzw. daraus gelesen. Liest man nun massenhaft Daten über den dafür vorgesehenen Weg aus und schreibt diese in eine ungeschützte Datenbank, die noch dazu offen im Firmennetzwerk zugänglich ist, macht man sich angreifbar.

Aus diesem Grund muss sichergestellt werden, dass gespeicherte Dateien oder die Datenbank den Schutz proprietärer Systeme nachbilden und ebenfalls verschlüsselt, passwortgesichert und nur möglichst wenigen Personen zugänglich sind. Im Fallbeispiel wurden die Daten in eine kleine Datenbank abgelegt, die die Daten angemessen verschlüsseln konnte und die Zugänge zur Datenbank wurden mit Passwörtern gesichert. Zusätzlich stellte das Betriebsmanagement sicher, dass die Ablage der Dateien ein eigenes Netzwerksegment nutzte, zu dem nur die Benutzer-Accounts der Roboter Zugang hatten.

Zugangssicherheit und Passwörter

Ein Teil des Threat-Modells prüft auch, wie die Maschinen, auf denen der Roboter läuft, zugänglich sind. Für Angreiferinnen und Angreifer ist es sehr viel einfacher, schadhaftes Verhalten durchzuführen, wenn ein direkter Zugriff auf Skripte oder Dateien besteht. Offene Laptops, vielleicht sogar in einem Großraumbüro, eignen sich nicht, um sicherheitsempfindliche RPA-Prozesse durchzuführen. Die Maschinen müssen gesichert werden, z. B. in isolierten virtuellen Umgebungen oder alt hergebracht hinter einer abschließbaren Tür.

Wie auch im normalen Tagesgeschäft sind die Zugänge zu Betriebssystemen, Netzwerken und Applikationen mit Passwörtern gesichert. Der Umgang mit Passwörtern ist heikel: Dem Roboter müssen Passwörter bekannt sein, d. h. sie müssen irgendwo gespeichert werden. Auch wenn der Zugang zu den Maschinen, auf denen ein Roboter aktiv ist, nicht offen zugänglich ist, müssen Passwörter sicher abgelegt werden. Im Fallbeispiel wurde dies durch einen Passwort-Tresor realisiert. Dabei wurde das Master-Passwort des Tresors sicher im Quellcode verschlüsselt abgelegt und alle weiteren Account-Passwörter dann im Tresor hinterlegt.

Zwischenfazit

Ein RPA-Vorgehen optimiert wiederkehrende gleichartige Aufgaben, kann die Effizienz enorm steigern und Kosten senken. Dieser Aspekt kommt zum Tragen, wenn die Vorbereitungen abgeschlossen sind und alle betroffenen Abteilungen das Vorhaben unterstützen.

Darin liegt aber die besondere Kunst der Einführung eines solchen Projekts. Viele Abteilungen und Interessenten schauen auf das Thema RPA und stellen ihre jeweiligen Anforderungen, die zum großen Teil nichts mit den inhaltlichen Themen zu tun haben. Die Besonderheiten eines RPA-Vorgehens bedürfen wohl durchdachter Lösungen. Durch eine frühzeitige Einbindung der Interessensgruppen und die Berücksichtigung der geschilderten Aspekte konnten alle Anforderungen erfüllt werden. Dabei zeichnete sich die offene RPA-Lösung mateo durch eine für Entwicklerinnen und Entwickler einfache Erweiterbarkeit aus. Die dadurch erzielte Zustimmung aller Beteiligten eröffnet im Anschluss die Möglichkeit, zukünftig schneller RPA-Lösungen im Unternehmen einzubringen und noch effektiver zu werden.

Im letzten Teil der Blog-Reihe schauen wir noch einmal detailliert auf die Umsetzung des Fallbeispiels mit der RPA-Lösung mateo und tauchen tief in die technischen Eigenschaften einer Automatisierung ein.