Hyperautomation aus der Sicht eines AI-Unternehmens

Aus der Sicht des Herstellers eines AI-Betriebssystems mit nativer Unterstützung von BPMN-Prozessen ist Hyperautomation ein logischer Schritt, um das Portfolio der Anwendungsmöglichkeiten des Systems zu erweitern. Im Artikel werden wir die einzelnen Bausteine von Hyperautomation näher beleuchten.

Bei Hyperautomation handelt es sich um einen Trend, der von Gartner in dessen Top Strategic Technology Trends 2020 sowie 2021 aufgenommen wurde. Der Begriff beschreibt eine Idee, bei der alles, das in einer Organisation sinnvoll automatisiert werden könnte, auch automatisiert werden sollte. Dazu müssen bessere Automatisierungsmöglichkeiten geschaffen werden, indem wir verschiedenste Technologien miteinander verknüpfen. Wir verstehen Hyperautomation als Kombination folgender Themen:

  • Business Process Management
  • Robot Process Automation
  • Artificial Intelligence

Hierbei ist wichtig, dass Hyperautomation nicht dazu gedacht ist, sämtliche Arbeiten eines Menschen zu übernehmen. Dies ist weder technisch möglich noch gewünscht – gerade in Bezug auf sicherheitskritischen bzw. sensiblen Workflows. Vielmehr werden Menschen durch die Automatisierung von repetitiven Aufgaben befreit, um sich auf solche zu konzentrieren, die einen höheren Wert für das Unternehmen haben.

Die Kombination aus Automatisierung und menschlichem Engagement soll Unternehmen dabei helfen, ein besseres Kundenerlebnis zu bieten und gleichzeitig die Betriebskosten zu senken und die Rentabilität zu steigern. Verwenden wir eine Kombination von Automatisierungstechnologien, kann Hyperautomation einige der Einschränkungen einzelner Ansätze überwinden.

Die Automatisierung erfordert jedoch eine sorgfältige Planung und Implementierung. Unternehmen müssen verstehen, wie sich digitale Technologien in ihre bestehenden Arbeitsabläufe einfügen und welche Rolle sie in neuen Prozessen spielen werden. Bei der richtigen Anwendung von Hyperautomation können für ein Unternehmen folgende Vorteile entstehen:

  • Flexibilität
    Aufgrund der Verwendung von unterschiedlichen Technologien können unterschiedlichste Automatisierungsaufgaben flexibel umgesetzt werden
  • Verbesserte Mitarbeiterproduktivität
    Durch die Automatisierung zeitaufwändiger Aufgaben sind Mitarbeiter in der Lage, mehr mit weniger Ressourcen zu erledigen und wertvollere Aufgaben in Organisationen zu übernehmen
  • Integration
    Mit Hyperautomation können Unternehmen digitale Technologien in ihre Prozesse und Legacy-Systeme integrieren
  • Verbesserter ROI
    Hyperautomation kann dazu beitragen, den Umsatz zu steigern und Kosten zu senken und die Produktivität allgemein zu erhöhen

Um Skalierbarkeit im Betrieb zu erreichen, müssen verschiedene Automatisierungstechnologien nahtlos zusammenarbeiten. Die sorgfältige Planung, Umsetzung und Verbesserung von Prozessen wird durch intelligentes Business Process Management (BPM) erreicht. Aus diesen Gründen ist BPM eine Kernkomponente der Hyperautomation.

Business Process Management

Business Process Management (BPM) repräsentiert das Fundament, mit dem sich die Hyperautomatisierungsstrategien und -initiativen eines Unternehmens verwalten lassen. Generell beschäftigt sich BPM damit, einen Geschäftsprozess von Anfang bis Ende zu verbessern.

Ein Geschäftsprozess ist eine Aktivität oder eine Reihe von Aktivitäten, die ein bestimmtes Organisationsziel erreichen sollen. Dabei ist BPM keine einmalige Aufgabe, sondern ein kontinuierlicher Prozess, der eine ständige Überarbeitung beinhaltet. Dieses methodische Vorgehen kann dabei in Form eines Regelkreises dargestellt werden.

BPM kann auch angewendet werden, wenn in einem Unternehmen noch keine Prozessbeschreibungen vorhanden sind, da zumindest „de-facto“ Prozesse, definiert durch die Art wie Aufgaben abgearbeitet werden, beschrieben werden können. Der BPM Lifecycle enthält mehrere Aktivitäten, dessen mögliche Umsetzung in weiterer Folge kurz beschrieben wird:

Design

Der Design Lifecycle Step umfasst sowohl die Identifikation bestehender Prozesse als auch das Design von neuen Prozessen, wobei es das Ziel ist, diese Prozesse in Form eines Prozessablaufes darzustellen.

In diesem Zusammenhang sollte Process Mining erwähnt werden, das ermöglicht, Geschäftsprozesse auf Basis digitaler Spuren in IT-Systemen zu rekonstruieren und auszuwerten. Damit ist es u.a. möglich, implizites und sonst verborgenes Prozesswissen zu modellieren und somit verwendbar zu machen.

Die Task Force on Process Mining des Institute of Electrical and Electronic Engineers (IEEE) definiert drei verschiedene Process-Mining-Typen:

  • Discovery
    Basierend auf vorhandenen (Text-) Ablaufprotokollen werden Prozesse rekonstruiert und in einen Prozessablauf überführt. Im folgenden Beispiel repräsentieren die Buchstaben A-I die Prozessschritte und die Variablen a1-f3 die Anzahl der Prozessschrittdurchläufe. Bei der Erstellung eines Prozessablaufes sollte besonders auf Schleifen (Siehe B-C) im Prozessablauf geachtet werden. Entweder handelt es sich hierbei um einen Fehler im Prozessablauf oder es ist notwendig, eine Logik für die Prozessentscheidung in den Prozessablauf zu integrieren.
  • Conformance
    Bei dieser Art des Process-Minings ist bereits ein Modell in Form eines Prozessablaufes vorhanden. Die vorhandenen Daten werden somit verwendet, um das Modell auf Konformität überprüfen zu können.
  • Enhancement
    Auch hier sind bereits Ablaufprotokolle und ein Modell des Prozesses vorhanden. Im Gegensatz zum Conformance Typ, sollen hierbei jedoch nicht nur der Prozess auf formale Konformität überprüft, sondern darüber hinaus auch bei Bedarf angepasst und erweitert werden.

Modeling

Im nächsten Schritt geht es darum, den Prozessablauf in eine Form zu überführen, welche in weiterer Folge ausgeführt werden kann. Hierfür setzen wir  auf den BPMN-2-Standard. BPMN 2 ist ein offener Notationsstandard, der zur Modellierung von Geschäftsprozessen verwendet wird. Der Standard ist im Geschäftsprozessmanagement weit verbreitet, da er für Fachanwender leicht verständlich ist und gleichzeitig technischen Anwenderinnen und Anwendern die Möglichkeit bietet, komplexe Prozesse darzustellen und zu implementieren.

Dabei bietet unsere Hyperautomation-Lösung (AIOS) zwei Möglichkeiten, ein Modell zu erstellen. Bei der ersten Variante kann ein Geschäftsprozess über einen visuellen Designer erstellt werden. Es wäre genauso möglich, den initialen Prozess direkt aus dem Prozessablauf erstellen zu lassen. Das folgende Modell stellt den zuvor dargestellte Prozessablauf als BPMN-2-Modell dar (Annahme: f1, f2 und f3 haben den gleichen Wert und sind daher parallel):

Alternativ zur Erstellung mittels eines visuellen Designers, besteht in unserem System  die Möglichkeit, BPMN Prozesse über eine Modeling DSL zu erstellen, so dass ein Entwickler direkt eine Entwicklungsumgebung verwenden kann. Ein Beispiel könnte folgendermaßen aussehen:

process("process_1") {
   noneStartEvent("startEvent_1")
   sequence("sequence1", "startEvent_1", "scriptTask_1")
   scriptTask("scriptTask_1", "Task 1") {
      script("atreus", "println('test')")
   }
   sequence("scriptTask_1", "endEvent_1")
   noneEndEvent("endEvent_1")
}

BPMN 2 bietet eine große Anzahl an syntaktischen Möglichkeiten. Zum Beispiel können mit dem Standard auch manuelle Schritte mittels UserTask und ManualTask abgebildet werden, so dass nicht automatisierte bzw. hybride Geschäftsprozesse ebenfalls dargestellt werden können. Des Weiteren sieht der Standard über Extensions Erweiterungsmöglichkeiten vor, von dem wir bei der Umsetzung von Hyperautomation Gebrauch machen.

Execution

Aufgrund der semantischen Ausdrucksstärke von BPMN 2 können Prozesse bereits so modelliert werden, dass sie in weiterer Folge von einer BPMN Engine ausgeführt werden können. Bei der BPMN 2 Engine unserer Hyperautomation-Lösung (AIOS) handelt es sich um eine Eigenentwicklung, die auf Performance, Skalierbarkeit und Ausfallsicherheit optimiert wurde. Die Beschreibung der BPMN Engine hätte genug Stoff für einen eigenen Artikel. Aus diesem Grund werde ich hier nur oberflächlich auf diese eingehen. Generell bietet die BPMN Engine im Gegensatz zu alternativen Lösungen entscheidende technische Vorteile. Diese basieren auf folgenden technischen Designentscheidungen:

  • Graphendatenbank
    Wie wir aus einem Prozessablauf entnehmen können, handelt es sich bei Geschäftsprozessen um Graphen. Aus diesem Grund sollte man Geschäftsprozesse auch in Form von Graphen und nicht wie zumeist bei alternativen Lösungen in relationalen Tabellen abbilden. Diese Vorgehensweise bietet viele Vorteile – u.a. den direkten Gebrauch  der Graphentheorie. Dies ist insofern bei komplexen Geschäftsprozessen mit inclusive oder parallel Gateways hilfreich, da einfach und elegant die Tokens der parallelen Ausführung mittels einer Graphentraversierung ermittelt werden können.
  • Aktorenmodell
    In der Informatik handelt es sich bei einem Aktorenmodell um ein Modell für nebenläufige Berechnungen bzw. Programme. Diese werden in nebenläufige Einheiten, sogenannte Aktoren, unterteilt, die ausschließlich über Nachrichtenaustausch kommunizieren. Umgelegt auf die BPMN 2 Engine bedeutet das, dass die einzelnen Prozessschritte von Aktoren abgebildet werden. Die Sequenzen zwischen den Prozessschritten werden als asynchroner Nachrichtenaustausch zwischen den Aktoren umgesetzt.
  • Reactive Programming
    In der Informatik ist die reaktive Programmierung ein deklaratives Programmierparadigma, das sich mit Datenströmen und der Ausbreitung von Änderungen beschäftigt. Mit diesem Paradigma ist es möglich, statische oder dynamische Datenströme einfach auszudrücken, um somit die automatische Propagierung des Datenflusses zu erleichtern.

Diese technischen Entscheidungen ermöglichten es, ein reaktives System (laut dem reaktiven Manifesto) zu erstellen. Das reaktive Manifesto definiert 4 Prinzipien, die ein solches System ausmachen:

Responsive
Das System reagiert, wenn möglich, zeitnah. Reaktionsfähigkeit bedeutet in diesem Zusammenhang, dass Probleme schnell erkannt und effektiv behandelt werden können. Responsive-Systeme konzentrieren sich darauf, schnelle und konsistente Reaktionszeiten zu bieten und verlässliche Obergrenzen festzulegen, damit sie eine konsistente Servicequalität liefern.

Resilient
Das System bleibt im Falle eines Ausfalls reaktionsfähig. Die Ausfallsicherheit wird durch Replikation, Eingrenzung, Isolierung und Delegation erreicht. Ausfälle werden innerhalb jeder Komponente eingeschlossen, wodurch die Komponenten voneinander isoliert werden und somit sichergestellt wird, dass Teile des Systems ausfallen und wiederhergestellt werden können, ohne das System als Ganzes zu gefährden. Die Wiederherstellung jeder Komponente wird an eine andere Komponente delegiert, und die Hochverfügbarkeit wird bei Bedarf durch Replikation sichergestellt.

Elastic
Das System bleibt bei wechselnder Arbeitslast reaktionsfähig. Reaktive Systeme können auf Änderungen der Eingaberate reagieren, indem sie die zur Bedienung dieser Eingaben zugewiesenen Ressourcen erhöhen oder verringern. Dies impliziert Entwürfe, die keine Konfliktpunkte oder zentralen Engpässe aufweisen, was zu der Fähigkeit führt, Komponenten zu splitten oder zu replizieren und Eingaben unter ihnen zu verteilen.

Message Driven
Reaktive Systeme verlassen sich auf asynchrones Message Passing, um eine Grenze zwischen den Komponenten zu etablieren, die lose Kopplung, Isolation und Standorttransparenz gewährleistet. Diese Grenze bietet auch die Möglichkeit, Fehler als Nachrichten zu delegieren. Der Einsatz von explizitem Message Passing ermöglicht Lastmanagement, Elastizität und Flusskontrolle, indem die Message Queues im System überwacht werden und bei Bedarf Back-Pressure ausgeübt wird.

Monitoring

Die auszuführenden Prozesse werden fortlaufend überwacht und mittels eines Dashboards visualisiert. Die dafür benötigten Informationen sind jederzeit in Echtzeit vom System abrufbar, so dass Third-Party-Systeme ebenfalls auf diese Informationen zugreifen können. Diese Daten bilden die Grundlage für die spätere Optimierung der Prozesse und können ebenfalls als Basis für Process Mining herangezogen werden.

Neben der Sammlung der Daten befindet sich auch die Analyse dieser Informationen im Monitoring Step des BPM-Lifecycles. Für die Bewertung der Geschäftsprozessdaten kann das volle Potential des AIOS hinsichtlich der Analyse mittels AI ausgeschöpft werden.

Generell wird während des Monitorings der Prozesse die Ist-Situation des Unternehmens festgestellt, um in weiterer Folge Engpässe oder Informationen über die Auslastung von Ressourcen auslesen zu können.

Des Weiteren werden hiermit mögliche Schwachstellen sowie Verbesserungspotentiale identifiziert. Dies kann u.a. erreicht werden, indem die Ist-Daten mit den zuvor modellierten Soll-Vorgaben verglichen werden. Wird ein definierter Threshold unterschritten, können flexibel über das System beliebige Aktionen, wie z.B. das Versenden der Information über eine E-Mail, durchgeführt werden.

Um einen Soll-Ist-Vergleich durchführen zu können, müssen bestimmte Parameter bestimmt werden. Dies kann beispielsweise die Gesamtlaufzeit eines Prozesses oder auch die Gesamtkosten, die sich aus der Nutzung aller am Prozess beteiligten Ressourcen ergeben, sein. Mit dem AI Operating System lassen sich jedoch auch flexibel weitere Metriken erfassen. Hierfür haben wir eine BPMN Extension in Form eines NotificationIntermediateEvents erstellt. Mit Hilfe dieses Intermediate Events ist man in der Lage, beliebige Notifications zu erstellen und zu messen.

Somit ist durch messbare und auswertbare Daten bzw. Prozesse eine Überwachung und Auswertung der Geschäftsprozesse anhand solcher Soll-Ist-Vergleiche möglich. So lassen sich Durchschnittswerte und eventuelle Abweichungen feststellen. Anschließend werden aus den ermittelten Daten Reports erzeugt, die die Schwachstellen aufzeigen.

Optimization

Basierend aus den Erkenntnissen des Monitorings können Verbesserungsmaßnahmen sowie Vorgaben für die Gestaltung neuer Geschäftsprozesse abgeleitet werden. Für eine Optimierung von Prozessen können Lösungen entworfen und mittels einer Simulation überprüft werden. Die Möglichkeiten einer Optimierung erweist sich als vielseitig. Vorschläge für eine Optimierung könnten sein:

  • Kombination mehrerer Geschäftsprozesse zu einem
  • Automatisierung weiterer Teilaufgaben
  • Vermeidung unnötiger Prozessschritte
  • Verbesserung der Datenstruktur

Nachfolgend der Optimierung fließen die Erkenntnisse in einem Kreislauf wieder in die Design-Phase ein, womit sich der Regelkreis schließt. Wie wir dadurch erkennen können, durchlaufen Geschäftsprozesse den BPM Lifecycle, damit diese kontinuierlich verbessert und angepasst werden können.  Denn nur wenn alle Aktivitäten des BPM Lifecycles durchlaufen werden, können Fortschritte auch gemessen und Prozesse kontinuierlich verbessert werden.

Ein wesentlicher Aspekt hierbei ist die Durchgängigkeit, womit gemeint ist, dass die einzelnen Aktivitäten des Regelkreises ohne wesentliche Bedienbrüche integrierbar sein sollen. Dies ist Voraussetzung, um flexible Anpassungen, Erweiterungen und Optimierungen an Prozessen vorzunehmen. Da das AIOS alle Aktivitäten des BPM Lifecycles abbildet, ist diese Voraussetzung erfüllt.

Durch Anwendung von BPM besitzt man die Grundlage für die Automatisierung jeglicher Geschäftsprozesse. Für die meisten Geschäftsprozesse wird es notwendig sein, mit Drittsystemen interagieren zu können. Hierfür setzt das Hyperautomation-Thema auf Robot Process Automation.

Robot Process Automation

Robot Process Automation hat sich zu einer der am schnellsten wachsenden Unternehmenstechnologien der letzten Jahre entwickelt. Grundsätzlich handelt es sich bei RPA um die Möglichkeit, repetitive und auf Regeln basierende Aufgaben automatisiert über eine API oder direkt über die Präsentationsschicht zu steuern.

Von vielen RPA-Anbietern wird letzteres propagiert, da die Simulation eines Users auf einer Softwareoberfläche in der Theorie schnell umgesetzt werden kann. In der Praxis sieht es jedoch mit der Umsetzung nicht so einfach aus, da häufig nicht klar kommuniziert wird, was ein RPA-Bot leisten kann.

Gängige Marketingkampagnen suggerieren zudem, dass der Einbezug der IT aufgrund der Simplizität von RPA nicht notwendig ist. Diese falschen Erwartungshaltungen können dann unter Umständen auch dazu führen, dass RPA-Projekte scheitern. Insbesondere die verbreitete Behauptung, RPA könne schnell und einfach ohne Coding umgesetzt werden, erscheint in diesem Zusammenhang nicht ideal.

Denn die Einführung und Aufrechterhaltung von umfangreichen RPA-Lösungen stellt nach wie vor eine Herausforderung dar. Erstens erfordern auch RPA-Lösungen für die Automatisierung von komplexen Workflows einen nicht unerheblichen Aufwand an Codierungs- bzw. Konfigurationsarbeit. Zweitens sind UI-basierte RPA-Bots fest mit der Benutzeroberfläche gekoppelt. Daher können auch kleinere Anpassungen der Benutzeroberfläche dazu führen, dass diese fehlschlagen. Auch die Erstellung von RPA-Automatisierungen über ein Screen Recording Tool erweist sich in der Praxis nicht immer als praktikabel.

Bei einfacheren Prozessen kann Screen Recording marketingtechnisch gut verwendet werden. Meistens ist es jedoch so, dass die zu automatisierenden Prozesse eine komplexere Form haben. Bei komplexeren Prozessen wird die Erstellung eines RPA-Prozesses mittels Screen Recording umständlich.

Das kann bereits bei einen auf den ersten Blick einfachen Prozess demonstriert werden. Folgender Prozess führt zu Beginn des Workflows „Task 1“ aus. Je nachdem welcher Output aus diesem Task entsteht, wird entschieden, ob der obere oder der untere Weg durch den Prozess weiter durchlaufen werden sollte. Wenn wir diesen Prozess aufzeichnen würden, müssten wir mehrere Recordings aufnehmen bzw. erneut die Entscheidungslogik codieren.

Wir haben bei der Automatisierung von Tasks im Hyperautomation-System bewusst eine Abgrenzung zwischen API- und UI-Automatisierungen eingeführt. Tasks, die über eine API automatisiert werden können, werden über einen Standard BPMN ScriptTask bzw. über einer Task Extension, dem Connector SkillTask implementiert. Während im ScriptTask ein Script in der AIOS-eigenen Programmiersprache ausgeführt wird, können bei einem Connector Skill unterschiedliche Konnektoren für Systeme über die Skill-Abstraktion (als eine Art Microservice) erstellt werden.

Der Aufruf einer externen REST-Schnittstelle könnte dabei folgendermaßen aussehen:

httpPost("https://domain.com/api/") // <1>
    .header("Content-Type", "application/json")
    .header("api-secret", "top_secret") // <2>
    .body(mapOf("param1": 1)) // <3>
    .execute() // <4>
    .map(response -> $response.abc) // <5>

<1>      Initialisierung des Requests als POST Request
<2>      Setzen von HTTP Header Informationen
<3>      Setzen der HTTP Body Informationen
<4>      Ausführung des Requests
<5>      Transformation des http Responses

Für die Automatisierung von Anwendungen über die Benutzeroberfläche haben wir den BPMN-Standard um einen RPATask erweitert. Da zumeist ein Entwickler für die Automatisierung von komplexen Workflows notwendig wird, macht es aus Sicht von Leftshift One natürlich Sinn, ihr oder ihm die Arbeit in seiner gewohnten Arbeitsumgebung zu ermöglichen.

Im Unterschied zu dem ScriptTask wird das Script nicht direkt am System ausgeführt,  sondern auf einem RPA Server, der direkt auf dem zu automatisierenden Rechner läuft. Beim RPATask verbindet sich das AIOS mit dem RPA Server und leitet die Automatisierungsanweisungen an diesen weiter. Der Businessprozess, in dem der RPATask ausgeführt wird, wartet solange im WAITING State, bis eine Rückmeldung vom RPA Server erfolgt ist oder ein Timeout auftritt.

Bei der Erstellung der Automatisierungsanweisungen haben wir die Komplexität der Robot Process Automation mittels der Erstellung einer eigenen Domain Specific Language (DSL) stark vereinfacht, so dass keine Programmierkenntnisse notwendig sind. Dennoch können Entwickler diese DSL-Skripte innerhalb der gewohnten Entwicklungsumgebung erstellen und testen.

Die DSL ist so konzipiert, dass sie sowohl mit nativen OS-Applikationen als auch mit Browsern umgehen kann. Dabei verwenden wir für die Abstraktion der zu automatisierenden Elemente den CSS Selector Syntax, um sowohl Web als auch Native OS Controls steuern zu können.

Für die Identifikation von Control IDs bei Windows-Applikationen kann z.B. das Accessibility Insights for Windows Tool verwendet werden. Ein simples Beispiel für die Automatisierung einer Calculator-Anwendung könnte folgendermaßen gestaltet werden:

launch("calc") { // <1>
    window("Rechner") { // <2>
        click("#num3Button")  // <3>
        click("#plusButton")  // <4>
        click("#num5Button")  // <5>
        click("#equalButton") // <6>
        send(mapOf("result", read("#CalculatorResults"))) // <7>
    }
    close("Rechner") // <8>
}

<1> Starte die Calculator-Applikation
<2> Fokussiere das neue Fenster
<3> Klicke auf den Button „3“
<4> Klicke auf den Button „+“
<5> Klicke auf den Button „5“
<6> Klicke auf den Button „=“
<7> Schicke das Resultat zum AIOS
<8> Schließe das Fenster

Mit Hilfe der DSL können jedoch auch komplexere Workflows automatisiert werden:

launch("App123") {
    window("App") {
        click("#buttonA")
        input("#inputA", "text 123")
        click("#buttonEnter")
        
        if (read("#textField").startsWith("DEV")) {
           // do something dev specific
           send(mapOf("result" to "dev"))
        }
        if (read("#textField").startsWith("BIZ") {
           // do something biz specific
           send(mapOf("result" to "biz"))
        }
    }
    close("App")
}

Die DSL kann des Weiteren auch verwendet werden, um mit mehreren Applikationen zu interagieren. 

launch("App1", "App2", "App3")) {
    window("App1") { // do something with app1
        set("variableName1", "value from app1")
    }
    window("App2") { // do something with app2
        set("variableName2", "value from app2")
    }
    window("App3") { // do something with app3
        set("variableName3", "value from app3")    
    }
    close("App1")
    close("App2")
    close("App3")
}

RPA ist eine sehr interessante Technogie, die richtig eingesetzt schnell zu einem Mehrwert führen kann. Mit der Kombination von RPA und AI können wir den Bereich der möglichen Automationslösungen erweitern, so dass auch komplexere Use Cases umgesetzt werden können.

Jedoch muss man sich bei der Implementierung auch dem Aufwand bewusst sein. Denn entgegen der weit verbreiteten Meinung ist ein RPA-System, vor allem bei komplexeren Workflows, nicht wartungsfrei. Auch die Erwartung, dass ein RPA-System als Ersatz für jegliche menschliche Arbeitskraft herangezogen werden kann, wird in der Regel enttäuscht.

Artificial Intelligence

Eine Einschränkung von RPA ist, dass sie auf strukturierte Daten beschränkt ist, um Aufgaben zu erledigen. Daher hat RPA weder die Fähigkeit, den Kontext zu verstehen oder zu lernen, noch kann es auf unstrukturierte Datenquellen wie Bilder zugreifen und diese sinnvoll nutzen.

Aus diesen Grund braucht Hyperautomatisierung den strategischen Einsatz von künstlicher Intelligenz.  Mit Hilfe der Kombination aus RPA und AI erhöht sich der Umfang an Automationsmöglichkeiten weiter, indem AI kognitive Tasks wie die Interpretation von Texten, Audio, Bilder usw. übernimmt.

Mithilfe der automatisierten Erkennung von Informationen zusammen mit dem semantischen Kontext ist man in der Lage, auch komplexere Geschäftsentscheidungen zu treffen. Die Erwartung, dass jegliche menschliche Arbeit automatisiert werden kann, bleibt dabei nach wie vor ein gefährlicher Trugschluss. Häufig wird man bei der Beschreibung von AI mit Texten wie dem folgenden konfrontiert:

„KI ist zu einem Oberbegriff für Technologie geworden, die Software hilft, wie Menschen zu denken und zu handeln, und die alles umfasst, von kognitiver Datenverarbeitung und optischer Zeichenerkennung bis hin zur Verarbeitung natürlicher Sprache.“

Dabei ist leicht nachvollziehbar, dass viele mit einer derartigen Definition nicht einverstanden sind, da versucht wird, eine Analogie zwischen der menschlichen und der künstlichen Intelligenz herzustellen.

Mittels AI kann tatsächlich bereits sehr viel umgesetzt werden. Teilweise übersteigen die Möglichkeiten der AI, in stark eingegrenzten Bereichen, auch menschliche Fähigkeiten. Doch die kognitiven Fähigkeiten von AI mit jenen des Menschen gleichzusetzen, hält als Prämisse bei weitem nicht stand.

Prinzipiell ist es so, dass wir den Begriff Intelligenz nicht exakt beschreiben können. Deswegen sollten wir künstliche Intelligenz als eine andere Form der Intelligenz betrachten und nicht ständig mit der menschlichen vergleichen.

Gerade wenn sensible und kritische Workflows automatisiert werden sollten, muss ein menschlicher Mitarbeiter weiterhin zumindest als Supervisor in den Prozess integriert werden.

Bei AI handelt es sich um ein leistungsstarkes Automatisierungswerkzeug, dessen Implementierung jedoch eine erhebliche Investition von Ressourcen und eine sorgfältige Planung erfordert, um die Integration mit anderen Technologien und Prozessen sicherzustellen.

Als Betriebssystem für AI ist das AIOS prädestiniert dafür, diesen Punkt im Hyperautomation-Bereich umzusetzen. Das System unterstützt dabei die Umsetzung von AI-Lösungen – angefangen vom Sammeln der Daten über das Training von Modellen bis hin zu Deployment und Ausführen sowie Monitoring und Weiterentwicklung.

Die lauffähigen AI-Lösungen innerhalb des Systems werden dabei als Skills bezeichnet. Eine große Anzahl an vordefinierten Skills können bereits aus dem in AIOS integrierten Marketplace („Skill Store“) bezogen und nahtlos in einen Workflow integriert werden. Wie bereits zuvor erwähnt, haben wir hierfür den BPMN-Standard um einen SkillTask erweitert. Im folgenden Beispiel wird demonstriert, wie AI und RPA in einem Workflow zusammenwirken können:

Der BPMN-Prozess zeigt einen Geschäftsprozess, bei dem ein Dokument (Bild oder PDF) automatisch verarbeitet wird, indem der Text aus dem Dokument extrahiert und in weiterer Folge in externen Systemen persistiert wird. In diesem konkreten Prozess sind beispielsweise folgende AI-Funktionalitäten enthalten:

Natural Language Processing (NLP)
NLP ermöglicht Maschinen, unstrukturierte Daten aus z.B. E-Mails oder Social-Media-Posts semantisch zu verstehen, um in weiterer Folge eine Aufgabenstellung lösen zu können. Hierbei wird die Struktur und Bedeutung der menschlichen Sprache analysiert, indem verschiedene Aspekte wie Syntax und Semantik automatisiert verarbeitet werden. Beispielsweise könnte der Text in dem gezeigten Geschäftsprozess einer Klasse zugeordnet werden (Classification).

Optical Character Recognition (OCR)
OCR ist eine Technologie, um die Zeichen eines Textes in Bildern wie gedruckten Büchern, Fotos oder gescannten Dokumenten erkennen zu können. In dem Beispiel kann sowohl aus Bildern oder PDF Files, die Bilder enthalten, mittels OCR der Text extrahiert werden, um infolge von dem NLP Task weiterverarbeitet zu.

Zusammenfassend halten wir also fest: Bei Hyperautomation handelt es sich um den nächsten Schritt im Bereich der Automatisierung von Geschäftsprozessen. Die Integration unterschiedlicher Technologien ermöglicht es, Tätigkeiten zu automatisieren, die bislang mit den einzelnen Bausteinen von Hyperautomation nicht oder nur umständlich automatisiert werden konnten. Gerade die Integration von AI erhöht die Möglichkeiten der Automatisierung stark, da u.a. auch kontextsensitive Entscheidungen automatisiert werden können. Mit der richtigen Integration und Erwartungshaltung erweist sich Hyperautomation als spannende Technologie, die sehr flexibel in einem Unternehmen eingesetzt werden kann.