Robotic Process Automation (RPA)

Vor einiger Zeit habe ich in Nürnberg drei ehemalige Kollegen getroffen. Drei gute Freunde, die ich als Spitzeninformatiker bezeichnen würde. Sie haben die Schwerpunkte Projekt Management, Quality Management und Software Architektur. Alle drei lösen aktuelle Herausforderungen bei einer ganz großen und in Nürnberg ansässigen Behörde.

Wir waren – nicht weit weg vom Südwestpark, in dem in Nürnberg ja einiges an IT-Elite residiert – in einem italienischen Feinkostgeschäft verabredet, in dem man sich zu Mittag an sehr leckeren und trotzdem preiswerten italienischen Spezialitäten laben kann. Eine unscheinbare Adresse mit sehr guter Küche.

Gut essen fördert interessante Themen

So ein einfaches Lokal, wo die Tische und Stühle im Lager zwischen den Regalen aufgestellt sind und man ganz unkompliziert sein Mittagessen – wenn möglich begleitet von einem guten Glas Pino Grigio – einnehmen kann. Ich weißt noch, dass ich die Spaghetti Aglio & Olio getestet hatte und sehr zufrieden war.

Wir hatten uns lange nicht mehr gesehen, so dass es genug Themen gab, um sich einem ausführlichen Ratsch & Tratsch hinzugeben. Der Qualitätsmanager in unserer Runde berichtete von einem Vortrag zu RPA, den er bei einem CIO-Treffen gehört hatte. Und welches RPA Potential dort angekündigt worden war.

RPA im Ratsch & Tratsch

Damals wußte ich noch nicht, was RPA ist. Meine Freunde klärten mich auf: Hätte ich denn noch nie etwas von Robotic Process Automation, auf Deutsch Robotergesteuerte Prozessautomatisierung gehört? Sogar in Wikipedia gäbe es dazu einen Artikel, der aber nicht so sonderlich gut wäre.

Später habe ich auch dann immer wieder bei Tagungen Vorträge von renommierten Referenten gehört, die Aussagen tätigten wie diese
„kurzfristig wird jeder zweite Sachbearbeiter unnötig werden, mittel- und langfristig werden 90 % dieser Jobs verloren gehen. Möglich wird das durch künstliche Intelligenz und selbst lernende Software werden“.

Da muss ich immer lachen, weil das auch ganz ohne künstliche Intelligenz und selbst lernende Software geht.

Bei RPA fällt mir die InterFace ein

Ich muß nur an unsere Produkte HIT und CLOU denken. Das Textsystem HIT ermöglichte seit 1984, Texte a) schnell zu schreiben und b) durch „Textbausteine“ automatisch zu erstellen. Und wurde schnell zum erfolgreichsten UNIX-Software-Produkt in Europa.

Das Zauberwort war „Embedded SQL“

Allerdings waren das keine Textbausteine, sondern Textgenerierungsprogramme. Denn der CLOU war eine 4GL (Programmiersprache der 4. Generation), die alle denkbaren Möglichkeiten einer Programmiersprache hatte. Und zusätzlich komplexe Datenzugriffe lesend wie schreibend (embedded sql) ausführen konnte. Das bedeutet, dass man in SQL programmierte Datenbankabfragen und -Transaktionen in das Clou-Programm einbetten und die Ergebnisse in den Texten verarbeiten konnte. Und z.B. das fertige Dokument und das Versanddatum desselbigen in der DB hinterlegen konnte.

So konnte man zum Beispiel in einem CLOU-Baustein alle ******geldempfänger ermitteln und die Bescheide für diese automatisch erstellen. Alle dazu benötigten Daten wurden aus den Datenbanken gelesen und der erstellte Bescheid auch an der richtigen Stelle abgelegt.

In den 1980er Jahren ging RPA ganz ohne „Künstliche Intelligenz“

Die Arbeit von Sachbearbeitern folgt in der Regel einem sehr determinierten und durch Regeln und Gesetzen vorgegebenem System. Da gibt es keine Entscheidungsfreiheit, weil der Gesetzgeber präzise festlegt, wer unter welchen Voraussetzungen was machen darf und wem wieviel zusteht. Entscheidungsfreiheit, die einen Lernraum gäbe, wäre hier eher schlecht. Und da wo der Gesetzgeber Fehler macht und Lücken zu läßt, kann „künstliche Intelligenz“ auch nicht helfen.

Unsere CLOU-Textbausteine, die Programme waren, könnte man heute auch Process Automations Robots oder Bots nennen, also PAR oder PAB. Wir hatten Kunden, die hatten um die 10.000 davon und die gesamte Erstellung ihrer Bescheide automatisiert. Aus den „Anwendern“ wurden so „Fachanwender“, die den Prozess der Erstellung des Briefverkehrs nur noch „dirigierten“.

Unsere Kunden waren hoch zufrieden. Die Erstellung war effizient, effektiv und die Bescheide fehlerfrei. Bis word kam und die Anwendungen mit visual basic neu entwickelt wurden. Dann wurde alles bunter und schöner, aber auch langsamer und komplizierter.

Gelegentlich hatten die Kunden besondere Wünsche. So wollte einer Kunde mit 10.000 Bausteinen (die Zahl kam vom Kunden, ich habe sie nie nachgezählt) wissen, wie oft jeder einzelne von diesen in einem bestimmten Zeitrauf aufgerufen würde. Also wie fleißig oder faul seine BOTs sind.

Diesen Wunsch konnten wir einfach erfüllen, da die Sprache CLOU als Interpreter realisiert war. Wir mussten nur im Interpreter-Rahmen eine Funktion implementieren, die Aufrufe eines Bausteins mitzählte. Der Kunde musste nur noch diese Funktion für den gewünschten Baustein aktivieren und schon wusste er, wie fleißig (oft aufgerufen) oder faul (nie aufgerufen) der „Bot“ war.

Es gab noch mehr einzigartige Funktionen in HIT/CLOU. Von einer will ich noch berichten. Wir konnten Textblöcke mit Semantik versorgen. Das ging über spezielle Markups, die man beim Schreiben erzeugen oder über CLOU automatisch einfügen könnte. Dann wurde ein Feld mit fünf Ziffern plötzlich zum Rechnungsbetrag oder ein Dreizeilentext zur Empfänger-Adresse.

Da das alles prozedural war, und die Welt damals objektorientiert wurde, kam der Fortschritt mit einer ISO-Norm namens ODA/ODIF. Das stand für Office Document Architecture / Office Document Interchange Format.
ODA legte wunderbar fest, wie Dokumentklassen in einer Art Grammatik beschrieben werden mussten, mit ODIF wurde das Austausch-Format festgelegt. Wir entwickelten und verfügten den ersten funktionierenden ODA/ODIF Editor weltweit.

Er hieß Magic Hit und war ein wunderbares Werkzeug, mit dem man gleichzeitig Dokumente schreiben und Dokumentklassen erstellen konnte. Schon in der Version 1 hatte er Funktion, die dem Büroalltag genügte. Es sollte unser „wysiwyg„-Nachfolgermodell für HIT/CLOU werden – und war die schönste Software, die ich jemals gesehen habe. Wir haben damals allerdings auch eine zweistellige Anzahl von Millionen DM investiert. CLOU-HIT war noch komplett in der Programmiersprache „c“ entwickelt, der magic-HIT in „c++“.

Das war damals sehr innovativ, ich erinnere mich noch, wie ich die ersten druckfrischen Exemplare der zweiten und halbwegs brauchbaren Version des c++-Buches von Bjarne Stroustrup von einer Uniforum aus den USA mitgebracht hatte. In IF-Blog habe ich hier darüber berichtet. Das Buch hieß „The C++ Programming Language“ (Addison-Wesley, first edition 1985).

Nur hatten wir – wie auch die Leute von der ODA/ODIF-Group und die „großen“ klassischen IT-Konzerne wie IBM und Siemens übersehen, dass eine – nicht mehr ganz neue Firma mit Namen Microsoft die Anwender mit Word und Solitär eroberte. MS wurde von den Großen IT-Unternehmen wie auch von uns nicht so ernst genommen wie es notwendig gewesen wäre. So eroberten sie in Windeseile mit DOS und Windows die Welt. Und so wurde in den Behörden wie in der Industrie MS-Office zum Standart nicht ODIF sondern „word 2.0“ das allgemeine Austauschformat für Dokumente. Und unsere Millionen, die wir mit HIT-CLOU verdient hatten und in den Nachfolger magic HIT gesteckt hatten, waren weg.

Alle wollten „word“ und „Client-Server“ wurde das Buzzword. Wir mussten den magic HIT einmotten und schufen CLOU-CS. HIT wurde da gegen word ausgetauscht, und word generierte gesteuert vom CLOU die Dokumente. Das war für unseren Umsatz gut und schlecht für die Performance. Mit den neuen „fat clients“ haben wir das auch hinbekommen. Die großartige ODA/ODIF Idee einer Automatisierung auf der Basis von semantischen Dokumenten war kaputt. Heute haben wir proprietäre Spezialformate für bestimmte Dokumentarten. Schon die olle Tante „EDIFACT“ mit ihrer Edi*-Familie war organisatorisch weiter.

Mit ODA/ODIF hätte man Office in allen Branchen hervorragend automatisieren können. Und alles ganz einfach durch Algorithmen. Das hätte reicht völlig ausgereicht, die meisten Sachbearbeiter zu ersetzen. Denn Sachbearbeiter entscheiden nicht frei, sondern folgen Regeln und Gesetzen, die kaum Entscheidungsspielräume geben.

e-Government braucht keine KI und keine selbstlernende Systeme

Und heute träumt man von RPA und selbst lernenden KI-Systemen. Der Sachbearbeiter muss die Dinge anders machen, wenn der Gesetzgeber die Regeln ändert. Das kann die Software aber nicht „selbst lernen“, sondern dazu müssen Algorithmen an die gesetzlichen Vorschriften angepasst werden.

„Selbst Lernen“ klingt immer so einfach, ist es aber nicht.

KI-Systeme müssen trainiert werden. Das ist in der Regel ganz schön aufwändig. Vielleicht müssen wir mal gemeinsam unsere Software-Freunde bei BMW besuchen, die ihren „selbstfahrenden Autos“ im Norden Münchens unterrichten, das heißt beim Lernen helfen. Die könnten uns da manchen Schwank erzählen und uns berichten, wie mühsam das ist, ein KI-System zum Lernen zu bewegen.

Es geht nicht um die Heldentaten der Vergangenheit, sondern um die Zukunft.

Gerne schreibe ich über großartige Technik, die Probleme besser lösen konnte als man das mit moderne „buzzwords“ kann. Als Gründer und Mehrheitsaktionäre der InterFace AG geht es mir aber nicht um historische Verdienste, sondern um unsere Zukunft. Deshalb habe ich diesen Artikel auch nicht mit den klassischen Logos von HIT, CLOU und magicHIT illustriert, sondern dem zeitlosen IF-Logo, das für www.IF.de in die Zukunft weist.

RMD