Im Eingangsartikel haben wir dargelegt, was unter einem Software-Roboter eigentlich zu verstehen ist. Ein großer Knackpunkt in vielen Beiträgen zu dem Thema ist, dass gar nicht erklärt wird, wie der Roboter die Arbeitsweisen überhaupt „erlernt“ beziehungsweise „imitiert“. Das wird so gesagt, als gegeben hingestellt und dann geht es weiter im Text.
So einfach wollen wir uns hier bei Pentadoc Radar jedoch nicht aus der Affäre ziehen…
Vom Macro zur künstlichen Intelligenz
Es gab schon früh in der Entwicklung von Software Bemühungen, gleichförmige und standardisierte Abläufe zu automatisieren und zu optimieren. Waren anfangs Scripte und Macros für den versierten Anwender eine Offenbarung, wurde parallel an Verbesserungen der IT-Systeme sowie der Geschäftsprozesse gearbeitet. Der Ansatz der Robotic Process Automation (RPA) und die dabei entstehenden Software-Roboter stellen den nächsten Schritt in dieser Entwicklungsgeschichte dar.
RPA hat den Status eines neuen Themas hinter sich gelassen. Die Szenarien, in denen sie ihren enormen Nutzen unter Beweis stellt, nehmen beständig zu. Dabei zeichnet sich schon heute ab, dass Software-Roboter bald zum unhinterfragten Standard in großen und mittleren Unternehmen gehören werden. Und am Horizont dämmert zudem mit der „Künstlichen Intelligenz“ sowie „machine/cognitive learning“ bereits die nächste bedeutende Erweiterung herauf.
Wie funktioniert das denn?
Nun ist es ja durchaus nichts Neues, dass ein Algorithmus zuvor aufgezeichnete Mausbewegungen und Aktionen innerhalb bestimmter Programmumgebungen in eine Befehlsabfolge umwandelt. Beispielsweise, wenn man in Excel einen Ablauf aufzeichnet und dann auf alle gleichartigen Datenübertragungsvorgänge ablaufen lässt.
Da die Anforderungen an die Skalierbarkeit nicht zuletzt durch die Möglichkeiten von Cloud-Anwendungen gestiegen sind, handelt es sich bei Software-Robotern allerdings nicht mehr um solche ‚einfachen‘ Scripte, die lokal ausgeführt werden. Stattdessen funktionieren sie in einer Synthese aus den bekannten Ansätzen und ähneln in ihrer Entstehung dabei der Modellierung von Geschäftsprozessen. Es ist daher auch keineswegs abwegig, RPA als Ergänzung des bisherigen BPM zu begreifen.
Software-Roboter bestehen aus zwei großen Teilbereichen, welche die einzelnen Prozessbausteine sowie die eigentliche Prozessbeschreibung enthalten. Moderne Lösungen setzen auf das Arbeiten mit Modulen, die standardisierte Anweisungen beinhalten. Dafür stehen entsprechende Design-Werkzeuge zur Verfügung.
Es gibt also einerseits separate Pakete mit der Beschreibung von Arbeitsschritten in Bezug auf eine spezifische Anwendung:
- Einloggen im System und im Programm mit üblicher Benutzerkennung
- Aufruf der erforderlichen Oberfläche
- Eingeben vordefinierter Daten (aus einer Datenbank oder anderen Anwendung) an definierten Positionen auf der Benutzeroberfläche
- Und/oder Abrufen sowie Speichern des gewünschten Outputs
Andererseits gibt es die übergeordnete Prozessbeschreibung, in der festgelegt wird, in welcher Reihenfolge diese einzelnen Anwendungspakete aufeinander folgen. Im Ergebnis entsteht eine Kette von Arbeitsanweisungen, die der Software-Roboter künftig durchläuft.
Die Prozesslogik kann lediglich einfache Wenn/Dann-Weichen enthalten. In ihrer Gesamtheit können die Arbeitsanweisungen des Software-Roboters dennoch sehr komplex werden, da sie in jedem Element sehr genau beschrieben werden müssen.
Hab ich’s kaputtgemacht oder verbessert?
Zusätzlich zu den Designern, mit denen der Software-Roboter zusammengesetzt wird, gibt es Kontroll-Werkzeuge, mit denen die Workflows überwacht, gesteuert und ausgewertet werden können. Sämtliche Vorgänge sind also protokollierbar und die Leistungsfähigkeit wird konkret sichtbar.
Gibt es irgendwo im Prozess eine Änderung, die den Roboter „kaputt“ gemacht hat, ist diese ohne Weiteres aufzuspüren. Und da die Anwendungspakete immer einzeln in Abhängigkeit zum verwendeten Programm beschrieben werden, ist es vergleichsweise einfach, Korrekturen vorzunehmen. Aber auch sonstige Änderungen, wie zum Beispiel aufgrund geänderter Compliance-Vorgaben, können so vergleichsweise schnell und verlässlich umgesetzt werden.
Wenn eine Benutzeroberfläche geändert wurde, muss das in den Arbeitsanweisungen des Software-Roboters berücksichtigt werden, hat aber überhaupt keinen Einfluss auf den Arbeitsablauf davor und danach. Man kann sich das so vorstellen, als ob ein Mensch mit einer neuen Version eines Programms konfrontiert wird und sich dann daran anpassen muss.
Alles in Allem ist die Aussage „Der Roboter imitiert den menschlichen Arbeiter“ eine eingängige Beschreibung. Zumal spätestens nach der Lektüre des ersten Artikels klar ist, dass ein Software-Roboter in seiner einfachen Ausprägung ohne künstliche Intelligenz seine Umgebung nicht wahrnimmt und natürlich auch nichts von alleine tut.
Überzeugende Vorteile gibt es zuhauf
Mithilfe des oben beschriebenen Bausteinsystems können auch Mitarbeiter ohne ausgeprägten IT-Background bereits nach einer Schulungsphase von wenigen Tagen produktionstaugliche Software-Roboter erschaffen, testen und später auch kontrollieren. Um einen Software-Roboter im Designer zu bauen, programmiert man nicht, sondern konfiguriert lediglich.
Dadurch werden natürlich Kosten vermieden, die üblicherweise durch Experten anfallen (Programmierer, Architekten, Tester etc.). Zugleich erstellen diejenigen die Prozesse für die Software-Roboter, die aufgrund ihrer Praxiserfahrung auch die größte Expertise hinsichtlich der fachlichen Anforderungen mitbringen. Die Fach-IT übernimmt in diesem Zusammenspiel nicht mehr die Kontrolle, sondern unterstützt die Fachabteilungen und achtet auf die Einhaltung der Rahmenbedingungen aus IT-Perspektive.
Die initiale Anpassung der verwendeten Sequenzen an das Bestandssystem wird durch den Anbieter der Lösung vorgenommen, wofür tiefgreifende Fachkenntnis weiterhin zwingend erforderlich bleibt. Dessen ungeachtet profitiert ein Unternehmen von Beginn an von seinen selbst modellierten/imitierten Arbeitsprozessen und ist Herr im eigenen Haus. Denn von ihm erstellte Sequenzen werden über Bibliotheken in den jeweiligen Kontroll-Werkzeugen verwaltet und stehen für die weitere Entwicklung zur Verfügung.
Anwendungsfelder für Software-Roboter ausloten und nutzen
Bisher haben wir uns auf die Klärung wesentlicher Sachverhalte beschränkt. Nun gilt es, das grundsätzliche Verständnis in praktischen Nutzen zu überführen. Aufgrund der raschen Entwicklung rund um die Robotic Process Automation steht hierfür bereits eine Reihe von realen Beispielen bereit, die uns als Vorlage für eigene Projekte dienen können.
Um Ihnen die vielfältigen Anwendungsbereiche und Einsatzmöglichkeiten stärker zu verdeutlichen, wenden wir uns im nächsten Beitrag Pilotprojekten und Use-Cases aus der Praxis zu. Spätestens dann haben Sie genügend Anregungen gesammelt, um eigene RPA-taugliche Prozesse aufzuspüren.