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 behandelt 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.

RPA-Kompendium: Einsichten eines Informatikers

Die letzten Jahre habe ich mich bei einem DAX-Konzern intensiv mit RPA beschäftigt. RPA ist die Abkürzung für Robotics Process Automation und gemeint sind damit Roboter in Form von Software die bei anderen Programmen auf Knöpfe drücken und dabei die Arbeit in Form von Prozessen (vulgo: Klickarbeit) leisten die sonst ein Mensch machen würde. Das Ziel ist dabei repetitive Abläufe zur automatisieren um so mehr Raum für anspruchsvollere Tätigkeit zu geben.

Dafür gibt es verschiedene Produkte auf dem Markt zu Preisen von mehrere Kiloeuro pro Jahr, wie UIPath, Blue Prism oder Automation Anywhere, aber auch kostenloses Zeug wie OpenRPA und Pakete für Programmiersprachen wie Python. Mein persönlicher Favorit für den Business-Einsatz ist UIPath, da die typischen Probleme im geschäftlichen Alltag von zickigen Applikationen bis zur Governance aus meiner Einschätzung am besten abgebacken werden.

RPA ist dabei etwas mehr als nur andere Programme zu skripten, es ist ein ganzheitliches Konzept um Geschäftsprozesse in einem Unternehmen zu automatisieren. Wer hier nur den Teil betrachtet bei dem die RPA mit anderen Programmen interagiert sucht nur nach Ähnlichkeiten aber verkennt die Unterschiede.

Es ist eben nicht RPA wenn man mit VBA oder Python einfach nur Klickarbeit automatisiert, dies kann ein Teil davon sein, viel wichtiger ist aber dass die Prozesse dokumentiert werden, wartbare und beherrschbare Lösungen entstehen, das Ganze auch noch den Anforderungen an Datenschutz, Datensicherheit und Compliance genügt, und nicht zuletzt dass man jederzeit gegenüber den Fachabteilungen auskunftsfähig ist was der Roboter denn gerade so macht.

Außerdem ist es wichtig dass Prozesse im Unternehmen erkannt, analysiert und optimiert werden. Wenn der Roboter einfach nur genau das machen soll was vorher per Hand gemacht wurde dann wird das Projekt mit ziemlicher Sicherheit scheitern. Der sogenannte Business Analyst (früher sagte man Systemanalytiker dazu) muss wie ein Roboter denken können und die technischen Möglichkeiten genau kennen.

Setzt man hier die Personen mit den falschen Skills ein bedeutet dies nach hinten raus Mehrarbeit und unzufriedene Fachabteilungen. Es reicht für den Business Analyst eben nicht aus nur den Ist-Prozess zu dokumentieren, auch wenn dies allein schon in einigen Abteilungen eine reife Leistung sein kann.

In den letzten Jahren habe ich einige grundsätzliche Erkenntnisse bei der Architektur von RPA-Lösungen gewinnen können. Dazu beigetragen hat auch mein monatlich veranstaltetes Meetup der RPA-Developer in Berlin.

Dabei geht es nicht um bestimmte Produkte, vielmehr geht es mir um grundsätzliche Einsichten eines Informatikers zum Thema, die ich in dieser Serie von Artikeln in meinem verstaubten Blog teilen möchte. Vielleicht wird mal ein Buch draus.

Foren und die Datenschutz-Grundverordnung

Ab dem 25. Mai 2018 gilt die Datenschutz-Grundverordnung (DSGVO) der EU, nach Einschätzung auch kritischer Fachleute tatsächlich besser als die allgemeine Diskussion vermuten lässt. Im Prinzip ist Datenschutz nichts Neues, wir hatten vorher auch schon das Bundesdatenschutzgesetz (BDSG).

Diese Verordnung ist vor allem wegen der drastischen Strafen in der Diskussion mit denen große Unternehmen bedroht werden. Diese müssen dann strengere Regeln einhalten um personenbezogene Daten zu schützen. Allerdings ist die Verordnung oft sehr allgemein gehalten, um Anwälte und Richter nicht arbeitslos zu machen.

Für unsere Foren (vulgo: Clubs) bedeutet der Hype um die DSGVO vermutlich, dass nun die Mitglieder vermehrt verlangen werden dass ihre Daten gelöscht werden. Dazu gibt es jetzt es eine praktische Funktion im Profil, es muss keine E-Mail mehr an einen Admin geschickt werden.

An dieser Stelle kann man auch erfahren welche personenbezogenen Daten gespeichert sind und sie selbst ändern oder löschen.

Außerdem wurden alle Konten gelöscht die nie einen Beitrag geschrieben haben, da es nicht mehr erforderlich ist diese personenbezogenen Daten weiter aufzubewahren.

Für alles weitere gibt es einen Link zu den seitenlangen Datenschutz-Hinweisen, die man wohl bald auf jeder Website findet und die sich wohl nur selten jemand durchlesen wird. Genau wie diese albernen Cookie-Consent-Dinger die man seit 2015 überall sieht.

Twitter-Wall als Kiosk mit Raspberry-Pi im Eduroam

Diese kleinen Himbeerkuchen-Boxen sind ja schon faszinierend. Preislich wie ein abendlicher Restaurantbesuch zu zweit und von der Größe eine Zigarettenschachtel können sie alles was ein kleiner PC so können muss. Natürlich läuft Linux, besser gesagt eine spezielle Version von Debian, darauf.

Für ein Event in der Universität wurde nun eine Twiiter-Wall gewünscht, damit man auf einer großen Glotze gucken kann was alles gerade so von den Besuchern gezwitschert wird. Der Raspi bringt alles was gebraucht wird dafür schon mit, also vor allem HDMI für die großen Displays und einen WLAN-Dongle für den Internet-Zugang, in diesem Fall zum Eduroam.

Für meine Erläuterung wie man so ein Setup konfiguriert setze ich mal voraus, dass man einen potenten Raspi (also mindestens Version 2) samt Speicherkarte (in meinem Fall eine von Samsung mit 8 GB aus der Grabbelkiste) hat und mit die einfache Installation des Rasbian-Images mit dem Win32-Disk-Imager-Tool hinter sich gebracht hat.

Anschließend kann man sich auf dem Raspi mit "pi" und "raspberry" einloggen und mit "sudo su" Root-Rechte holen um alles auf der Shell zu konfigurieren. Als erstes mache ich immer ein "apt-get update && apt-get upgrade" um das System auf den neuesten Stand zu bringen.

Um das WLAN für Eduroam zu konfigurieren stellt meine Uni die passenden Datein für Linux zur Verfügung. Die "wpa_supplicant.conf" kommt nach "/etc/wpa_supplicant/" und das Telekom-Root-Zertifikat kommt einfach nach "/home/pi/".

Danach muss man die Zugangsdaten anpassen und beim nächsten Start kann man beobachten wie das WLAN verbindet. Wenn man kein Eduroam verwendet ist alles viel einfacher und kann mit dem Dialog auf der grafischen Oberfläche von Rasbian Jessie erledigt werden.

Als Browser für den Kiosk-Mode (also Fullscreen ohne Bedienelemente) habe ich Midora gewählt und mit "apt-get install midora" nachinstalliert. Gestartet wird der Browser dann mit einem kleinen Skript das bei mir "kiosk.sh" heisst und so aussieht:
#!/bin/sh
sleep 20
midori -e Fullscreen -a http://dkg2015.tweetwally.com/projection


Tweetwally ist eine Website von vielen die eine soganannte Tweet-Wall bereitstellt, also Tweet zu einem bestimmten Hashtag sammelt, die angegebene Seite aktualisiert sich dann automatisch. Das ist soweit also sehr einfach, die 20 Sekunden Pause sind dafür da um abzuwarten dass die Internetverbindung auch aufgebaut ist.

Etwas trickreicher ist dann schon die Änderung der grafischen Oberfläche, hier daher der Inhalt meine Datei "/home/pi/.config/lxsession/LXDE-pi/autostart":
@lxpanel --profile LXDE-pi
@pcmanfm --desktop --profile LXDE-pi
@sh ${HOME}/.config/lxsession/LXDE-pi/autokey.sh
@xset s off
@xset -dpms
@xset s noblank
@sh /home/pi/kiosk.sh


Dabei wird auch der Bildschirmschoner abgeschaltet, denn niemand wird an einer Raspi-Box ohne Tastatur und Maus mehr eine Taste drücken oder die Maus bewegen können. Nach dem nächsten Start sollte sich die Internet-Verbindung aufbauen (kann man durch die Visualisierung erkennen) und der Brower mit der Tweetwall gestartet.

Rolle rückwärts mit den Clubs

Vor knapp 12 Jahren ging es los: Zwei heute immer noch aktive Internet-Foren wurden von mir installiert. Eins von beiden, der Linux-Club, startete ziemlich schnell durch.

Das andere, der Geoclub, damals noch Geocache-Forum genannt, wuchs etwas langsamer, dafür aber viel gewaltiger. So gewaltig, dass zu den Spitzenzeiten um 2010 herum ein dedizierter Server angeschafft und kurz später noch mal upgegradet werden musste.

Mittlerweile hat die Kannibalisierung des Internets (die Großen fressen die Kleinen) hier auch zugeschlagen, Foren werden den Weg der vergessenen Newsgroups gehen und die Kommunikation sich immer mehr auf Fratzenbuchgruppen und andere soziale Medien verlagern.

So lange die Einnahmen aus den Werbebannern noch die Ausgaben für Domains und Server überstiegen konnte mir das alles recht egal sein. Seit einiger Zeit ist das nicht mehr so, und das obwohl ich schon knapp einhundert Domains gekündigt habe, die sich im Laufe der Zeit so angesammelt haben.

Auch die immer notwendig werdenden Adblocker (deren Verwendung ich völlig verstehen kann!) tragen ihren Teil dazu bei. Das ist für mich alles völlig in Ordnung und war absehbar, es wird aber Zeit wieder abzurüsten und aufzuräumen mit all den kleinen Projekten und Domains.

Ab August wird also von dem was ich bisher online hatte nicht mehr viel übrig bleiben: Neben diesem Blog hier vermutlich nur noch der Linux-Club, die grüne Hölle und die Linupedia. Die Podcast-Episoden des Cachertalk versuche ich hier im Blog unterzubringen. Während des Umzugs gibt es Statusmeldungen auf Twitter von mir.
tweetbackcheck