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.

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