RPA-Kompendium: Tidy data matters

Die meisten Daten unserer real existierenden Business-Welt sind Messy Data. Da werden optisch trennende Leerzeilen in Excel-Tabellen (dem kleinsten gemeinsamen Nenner der IT im Unternehmen) eingefügt und Zellen verbunden, Schriftfarben eine Bedeutung zugewiesen und leere Spalten eingesetzt um Abstände zwischen die Daten zu bekommen. Die Benutzung dieser Tabellen orientiert sich eher am menschlichen Benutzer als am Roboter der damit nun arbeiten soll.

Das Problem mit den Messy Data beschränkt sich allerdings nicht nur auf das von mir bei Controllern als Berufskrankheit akzeptierte Excel, sondern tritt überall auf. Meistens sind Bestände an Messy Data historisch gewachsen und dadurch bedingt, dass die Daten an verschiedenen Orten zu unterschiedlichen Aufgaben gesammelt oder erfasst wurden. Der Gipfel von Messy Data betrifft den Themenkomplex OCR, den ich extra behandeln werde.

Um nicht falsch verstanden zu werden: Die Existenz von Messy Data ist völlig nachvollziehbar, aber der Wunsch damit direkt weiterarbeiten zu wollen ist es nicht.
Tidy Data bedeutet ganz grob: Ein Entitätstyp pro Tabelle, Datensätze in Zeilen, Attribute in Spalten, in jeder Zelle nur maximal ein Wert. Für die Datenbanker: So knapp vor Erste Normalform. Das habe ich mir nicht ausgedacht sondern diese Klassifikation kommt aus der Wissenschaft, wo man mit Daten erst dann feine Analysen machen kann wenn man sie etwas in Form gebracht hat.

Ein Beispiel dazu: Das ist so eine Excel-Mappe mit Rechnungen, jeweils nach Jahren und Fachbereichen einzelne Tabellen darin. Das ist für Menschen schön übersichtlich, wenn man einen Roboter drauf ansetzen will gibt’s zwei Möglichkeiten: Entweder der Roboter wird so programmiert dass er mit dem Kram zurechtkommt oder wir bringen die Daten vorher in eine saubere Form. Das bedeutet in diesem Fall eine Tabelle (wir haben einen Entitätstyp Rechnung) und Fachbereich und Jahr sind einfach weitere Attribute (also Spalten) in der großen Tabelle. Sofern letzteres nicht redundant ist, weil eh ein Datum als Attribut drin steht.

Was RPA angeht ist es nun so, dass meiner Ansicht nach die Grenze zwischen Messy Data und Tidy Data die Queue sein sollte. Das heißt also dort, wo der Arbeitsvorrat für den Prozess definiert wird. Die Queue ist ohnehin so ein unterschätztes Merkmal von RPA, aber dazu an anderer Stelle mehr. Damit ist sichergestellt dass der Prozess sauber lesbar bleibt und sich konzentriert um die Applikationen kümmern kann, die automatisiert werden sollen. Wenn man anfängt im Prozess zur Laufzeit auch noch die Daten aus den meist menschgemachten Vorprozessen auseinanderfusseln zu müssen dann wird der Code an dieser Stelle hässlich. Und das bedeutet schlecht wartbar und fehleranfällig.

Üblicherweise verwendet man dazu für einen Roboter eine Aufteilung in einen Loader und einen Worker (bei UIPath heißen die Dispatcher und Performer, ist aber das selbe). In dem Loader sorgt man dafür das die ganzen in den Prozess eingehenden Datenmengen in eine saubere Form (also Tidy Data) gebracht werden. Der direkte Ansatz ist dazu dass man also genau genommen zwei Roboter macht, einen um die Daten bereitzustellen, sowie einen weiteren der Arbeit erledigt. Wenn dann viel zu tun ist skaliert das auch viel besser, aber auch dazu kommen wir noch.

Dass der Worker-Teil der RPA-Lösung mit einer RPA-Software implementiert werden muss steht sicher außer Frage. Der Loader-Teil allerdings lässt sich meist besser mit Big-Data-Werkzeugen umsetzen, die virtuos mit unterschiedlichen Datenquellen umzugehen gelernt haben wie beispielsweise Python mit Pandas. Egal woher die Daten kommen, Pandas macht daraus Dataframes und sie lassen sich dann mergen, melten, slicen oder was auch immer erforderlich ist.

Vor 30 Jahren sagte mein Informatikprof in der Vorlesung: „Sie können auch mit einem Aschenbecher einen Nagel in die Wand schlagen, aber sollten dies nicht als den richtigen Weg propagieren.“ Daher an dieser Stelle noch einmal der Hinweis darüber nachzudenken ob die RPA-Lösung für den Loader das richtige Werkzeug ist. Die Stärke von RPA-Lösungen ist die Interaktion mit dem Zielsystem, nicht die Analyse und Konvertierung von Daten.

Die Aufteilung in Loader und Worker ist sogar dann sinnvoll, wenn das Quell- und Zielsystem der Automatisierung identisch ist, und beide Teile mit der RPA-Lösung implementiert werden sollen, wie man es oft bei Projekten im Umfeld von SAP hat. Ein Team kann den Loader programmieren, der den Arbeitsvorrat mit allen benötigten Attributen auch aus mehreren Transaktionen zusammen sammelt und in die Queue schreibt. Ein anderes kümmert sich darum, die Daten aus der Queue mit einem Worker abzuarbeiten. Das kann auch durch unterschiedliche Teams mit spezieller Expertise für die jeweilige Umgebung und sogar in zeitgleichen Sprints erfolgen.

Um auf Pandas zurück zu kommen: Eine gute RPA-Lösung bietet an, die gewünschten Transaktionen über eine REST-API in die Queue zu schreiben. Damit kann man Python verwenden um die Daten in Form zu bringen und dann auch gleich ohne den Umweg über CSV oder andere Exporte für den Worker in die Queue zu pumpen. Was nebenbei auch noch den Vorteil hat damit den Worker nur bei Bedarf triggern zu können.

Abschließend zusammengefasst kann man sagen, dass ein RPA-Prozess nie versuchen sollte mit Messy Data direkt loszurennen. Es sollte immer ein Schritt vorgesehen werden der daraus Tidy Data macht. Außerdem ist es sinnvoll das Ergebnis, also die hier erzeugten aufgeräumen Daten dem Auftraggeber vorzulegen, um sicherzustellen, dass es sich dabei um die Daten handelt die der Roboter verarbeiten soll.

Trackbacks

Trackback specific URI for this entry

This link is not meant to be clicked. It contains the trackback URI for this entry. You can use this URI to send ping- & trackbacks from your own blog to this entry. To copy the link, right click and select "Copy Shortcut" in Internet Explorer or "Copy Link Location" in Mozilla.

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
tweetbackcheck