Im vorigen Kapitel wurde der Stand der Technik bezüglich der Automatisierung von Geschäftsprozessen skizziert. Hier werden die aktuellen Bemühungen zur Erhöhung des Automatisierungsgrades vorgestellt.

19.1 Robotic Process Automation (RPA)

19.1.1 Einführung

Im Kern geht es hier um folgendes: Ein weiterer bisher von Menschen realisierter Geschäftsprozessabschnitt soll automatisiert werden. Dafür wird ein neues Programm geschrieben, das möglichst problemlos mit der übrigen Software zusammenarbeitet.

Um was geht's?

Ulrich Storck, Head of Product Development bei der Scheer GmbH, beschreibt es sehr präzise:

"Es geht um die Weiterentwicklung der klassischen Prozessautomatisierung" …"Ein RPA-System simuliert demnach, wie Menschen einzelne Bedienungsmasken oder auch ganze Geschäftsprozesse bedienen. Dazu werden Softwareroboter eingesetzt, die vom Anwender lernen, Benutzerschnittstellen zu verwenden. Zur Bedienung einer Software nutzen sie eine virtuelle Tastatur und eine Maus." [Herrmann 2017, S. 20]

Programme also, die – einmal eingerichtet – selbständig ihre Aufgabe erfüllen und die diese sogar vom früheren menschlichen Nutzer lernen.

Hier wird auch gleich der Lernprozess angesprochen, den diese Software leisten soll.

Weitgehend synonym werden in der aktuellen Diskussion die Bezeichnungen RPA-Lösung, Softwareroboter, Frontend-Assistent (FEA) und Botverwendet. Bei Bots wird u.a. noch unterschieden nach ChatBots, RPA-Bots, ActBots. Dazu unten mehr. Der Begriff Bot kommt vom englischen Wort robot.

Begriffe

Bei Frontend-Assistenten liegt der Schwerpunkt auf der Unterstützung von Mitarbeitern. Z.B. unterstützt die Telekom damit vor allem ihre Servicemitarbeiter, die bei Bedarf per Mausklick einen „ServiceBot" für eine bestimmte Aufgabe starten können.

Frontend-Assistent

19.1.2 Lose Kopplung

Ein wichtiges Motiv für die Entwicklung dieser Softwareprodukte ist der Wunsch, separate IT-Systeme miteinander ohne großen Aufwand zu koppeln. Also nicht durch Reengineering der Prozesse und Anpassungen in den IT-Systemen.

Dies betont auch Andreas Lüth (Partner bei ISG, Head of Robotic Process and Cognitive Automation DACH). Er weist darauf hin, dass RPA sich vor allem für die Automatisierung von Geschäftsprozessen eignet,

"bei denen die prozessunterstützenden IT-Systeme nicht ausreichend vernetzt sind".

Damit, so führt er weiter aus, ergibt sich die Möglichkeit, mit RPA Geschäftsprozesse zu automatisieren, "ohne die Prozesse oder die sie unterstützenden IT-Systeme anpassen zu müssen". [Bayer 2018, S. 18]

Typischerweise werden hier also die Aufgaben über verschiedene Anwendungen bzw. Geschäftsprozesse hinweg ausgeführt. Der Softwareroboter "bedient" dazu vorhandene Applikationen und führt auf diese Weise systemübergreifend Transaktionen aus, bearbeitet Datenbestände oder stößt die Kommunikation mit anderen digitalen Systemen an.

Verknüpfung

Sehr treffend haben es Haisermann/Rückershäuser beschrieben:

"Ein RPA-Bot … bleibt also an der Benutzeroberfläche von CRM- oder ERP-Systemen und interagiert auf nichtinvasive Weise mit jeder Art von Infrastruktur." [Haisermann und Rückershäuser 2019, S. 34]

RPA-Bot steht hier für ein Softwareprodukt (einen Softwareroboter), das die Verknüpfung solcher IT-Systeme realisiert.

19.1.3 Drei Typen von Systemen

Die Scheer Group unterscheidet dabei drei Typen von Systemen:

  • Einfache RPA-Systeme zur Nachahmung sich wiederholender Routineaufgaben.
  • Kognitive RPA-Systeme, die das Anwenderverhalten auch in komplexeren Situationen nachahmen können, z.B. durch das Einbringen von Expertenwissen und die Fähigkeit zur natürlichsprachigen Kommunikation.
  • Intelligente RPA-Systeme, die zusätzlich lernfähig sein sollen.

19.1.4 Voraussetzungen für den Einsatz

Voraussetzung für den Einsatz ist wie immer, wenn es um Automatisierung geht, dass es sich um einen standardisierten und wohlstrukturierten Prozess mit hoher Wiederholzahl handelt.

Der Prozess des Softwareroboters sollte detailliert modelliert, die Schnittstellen seiner Partner (mit ihrem Prozessumfeld), wie auch immer sie geartet sind (vgl. unten), sollten genau spezifiziert sein. In der aktuellen Diskussion wird hier für die Modellierung eine automatisierte Erfassung der Process durch Process Mining diskutiert. Vgl. Abschnitt 19.3.

19.1.5 Schatten-IT

In der aktuellen Diskussion wird immer wieder darauf hingewiesen, dass der Einsatz von Softwarerobotern oftmals von "den Fachabteilungen" und nicht von der IT realisiert wird:

"Oft sind es die Fachabteilungen, die die meisten Bots bauen, in den häufigsten Fällen mit Unterstützung von externen Dienstleistern. Die IT wird häufig erst im Nachgang eingeschaltet, obwohl Governance, Roboter-Management und Prozessanalyse eine zunehmend wichtige Rolle spielen." [Bremmer 2018a, S. 36]

Damit streifen wir das Thema Schatten-IT. Vgl. auch 19.1.12.

19.1.6 Erwartungen

Die Erwartungen an die Automatisierung durch RPA-Systeme sind sehr hoch. Sie soll zu einer Beschleunigung der Prozessabwicklung und zu größerer Transparenz führen. Entsprechend sind die Erwartungen (der Unternehmensberatungen):

"Die Marktforscher von Forrester Research gehen davon aus, dass es bis 2021 weltweit mehr als vier Millionen Softwareroboter geben wird, die Büro- und Verwaltungsarbeiten sowie Vertriebs- und verwandte Aufgaben erledigen." [Bremmer 2018a, S. 36]

19.1.7 Grenzen von Softwarerobotern

In Bezug auf die einfachen RPA-Systeme mit konventioneller Programmierung (vgl. oben) gelten die oben angeführten Grenzen. Sehr plastisch beschreibt diese Andreas Lüth, zitiert nach Bayer:

"Die grundlegende Einschränkung von Softwarerobotern bestehe darin, dass sie "dumm" seien. Die Technik tue genau das, wofür sie entwickelt worden sei - nicht mehr und nicht weniger. Das bedeute unter anderem, dass nichts mehr geht, wenn Ausnahmen auftreten oder Daten fehlen. Anwender müssten deshalb darauf achten, für RPA ausgesuchte Prozesse korrekt abzubilden und sämtliche möglichen Ausnahmen zu berücksichtigen." [Bayer 2018, S. 19]

Dimitar Todorov (Head of IT Applications and Integration Services bei der Energieversorgung Niederösterreich) beschreibt den Stand von 2018 sehr plastisch. Die bis dahin umgesetzten RPA-Projekte zeigen positive Aspekte. Der Return on Invest (ROI) wird "um Faktoren besser", die Time to Market kürzer. An die zu automatisierenden Prozessabschnitte sollten allerdings keine zu hohen Erwartungen gestellt werden:

"In einem automatisierten Prozess Daten von A nach B zu schaufeln, ist laut Todorov der Idealfall." (zitiert nach [Bremmer 2018b, S. 43])

Das ist ohne weiteres nachvollziehbar. Es wundert nicht, dass dadurch der Ruf nach leistungsfähigeren Softwarerobotern deutlich wurde, den sog. kognitiven und intelligenten RPA-Systemen.

19.1.8 RPA/Bot-Lösung vs. Integrationsprojekt

Beim Einsatz von Softwarerobotern stellt sich immer die Frage, ob man deren automatisierte Prozessabschnitte nicht besser in die vorhandene integrierte Software einfügt, durch programmieren bzw. programmieren lassen. Dies wird auch in der Praxis so gesehen. Evtl. auch so, dass die "Roboter-Lösung" eine Übergangslösung ist: Zuerst Bots, dann, bei Bewährung, Integration in die Unternehmenssoftware. So auch Sebastian Zeiss (Vice President Lean Management Competence Center bei der Telekomm Service GmbH), der in [Bremmer 2018a, S. 37] zitiert wird:

Integriert oder nicht

"Seine Company greife als eines der Werkzeuge auf RPA zurück, um durch die typische agile Scrum-Vorgehensweise Zeit zu sparen und sofort Ergebnisse zu erhalten. Später werde dann geprüft, ob es Sinn gibt, die Bot-Lösung durch ein Integrationsprojekt abzulösen."

Immer wieder taucht auch das Argument auf, der Einsatz von Softwarerobotern erlaube es Unternehmen, eine eigentlich veraltete Software (meist angedeutet: auf Großrechnern) weiterzubetreiben und sei insoweit ein "Fortschrittshemmer".

Fortschrittshemmer?

19.1.9 Einschätzung

In der Computerwoche (Ausgabe 2020, 12-14) wird von einer Diskussionsrunde berichtet, in der IT-Verantwortliche den Einsatz von RPA-Bots thematisieren (vgl. [Stocker 2020, S. 34]). Insbesondere ging es auch um die oben angesprochene Frage, ob durch RPA-Bots notwendige Softwareneuerungen unterlassen werden können ("Fortschrittshemmer").

Zu Beginn wird aus einer aktuellen RPA-Studie von IDG zitiert, die auf die Bedeutung der Thematik hinweist [Stocker 2020, S. 34]. Danach sind bis zu 20 automatisierte Prozesse "bei Konzernen und Mittelständlern durchschnittlich in Betrieb".

Einsatz

Die Diskussion zeigt eine durchaus realistische Einschätzung der Möglichkeiten. Einige der Positionen:

  • Aufgrund ihrer Architektur ("Andocken am User-Interface") haben Softwareroboter ein begrenztes Veränderungspotential. "Der Prozess bleibt der gleiche, er läuft nur schneller und weniger fehleranfällig ab" (S. 34).
  • Gehofft wird, dass RPA "eine Schlüsselrolle als Enabler der digitalen Transformation" einnimmt, weil dadurch Nutzer in die Lage kommen, "ihre Arbeit selbst zu automatisieren" (S. 35).
  • Hingewiesen wird auf "Bot-Molochs". Von diesen spricht man, wenn ein "robotergestützter Prozess an einen oder mehrere andere andockt". Dies wird als kritisch angesehen (S. 35).
  • RPA und Process Mining gehören zwingend zusammen, weil mit Process Mining der gesamte Prozess im Fokus ist und die RPA-Bots dadurch effizient eingesetzt werden können.

19.1.10 Anbieter / Softwarehäuser

In [Bremmer 2018c] wird aus einer Umfrage von Forrester Research berichtet. Danach zeigte es sich, dass Blue Prism der führende Anbieter ist (32 % Marktanteil), gemeinsam "mit den etwas besser gerankten Anbietern UiPath und Automation Anywhere". Weiter wurde ausgeführt, dass zum Kreis der „Strong Performers" außerdem Pegasystems, Nice, Edgeverve, Kryon, Kofax und Thoughtonomy" gehören [Bremmer 2018c, S. 16].

Insgesamt also:

  • Blue Prism
  • UiPath
  • Automation Anywhere
  • Pegasystems
  • Nice
  • Edgeverve
  • Kryon
  • Kofax
  • Thoughtonomy

Diese Liste hat sich in einer neuen Übersicht, wiederum basierend auf einer Gartner-Studie, nur unwesentlich verändert:

  • UiPath
  • Automation Anywhere
  • Blue Prism
  • NICE
  • Pegasystems
  • Kofax
  • NTT-AT
  • EdgeVerve Systems
  • Openconnect
  • HelpSystems

Vgl. [Bremmer 2019a, S. 24, basierend auf Gartner]

Die dort angegebene Tabelle zeigt außerdem auf, dass im Jahr 2018 knapp 40% des Marktanteils auf weitere Anbieter entfallen.

19.1.11 "Bots überall"

Wie wir oben gesehen haben, ist ein Softwareroboter im Kern ein Computerprogramm, das im IT-gestützten Umfeld Aufgaben automatisiert und selbstständig ausführt, meist auch wiederholt. Diese Softwaretechnologie kann natürlich in vielen Bereichen zum Einsatz kommen, auch außerhalb des geschäftlichen Umfelds:

  • Bei Computerspielen als selbständiger "Mitspieler", als Ersatz für einen menschlichen Spieler
  • In Chats und Foren zur Bereinigung und Kontrolle der Inhalte
  • Auch die sog. Webcrawler der Suchmaschinen, die aus dem Internet die Sucheinträge einsammeln, sind Bots.
  • Trojaner und Malware beruhen teilweise auch auf dieser Technologie.

Richtet man es entsprechend ein, dann können Bots auch miteinander kommunizieren. Man spricht dann von einem Botnet. Im nicht-kriminellen geschäftlichen Umfeld geht es dann z.B. um unternehmensübergreifende Kommunikation. Ansonsten handelt es sich meist um Schadsoftware. Ein typisches Beispiel hierfür ist Spam.

Botnet

Social Bots

Nur zur Abrundung hier noch ein Blick in das Social Web. Eine immer wichtigere Rolle in der Gesellschaft, vor allem bei dem Teil, der sich im Internet bewegt, spielen die sog. Social Bots. Die Bundeszentrale für politische Bildung (BPD) beschreibt es treffend:

"Sie können menschliches (Kommunikations-) Verhalten imitieren, beispielsweise bei Facebook Freundschaftsanfragen versenden, bei Twitter anderen Accounts folgen oder eigene Texte vorbereiten. Ihre Zielsetzung hingegen ist unterschiedlich und der Übergang zwischen folgenden drei Kategorien verläuft fließend. Ein Bot kann auch mehrere Aufgaben übernehmen.

 

1. Die Überlaster

 

Ein Bot kann den Feed einer bestimmten Seite oder einer Person mit einer bestimmten Aussage überfluten. Sieht er beispielsweise, dass eine Nachrichtenseite sich zu einem bestimmten Thema geäußert hat, postet er immer wieder dieselben Gegenaussagen. Vor allem, wenn solche Bots ihre Nachrichten gegenseitig "liken" oder kommentieren können, beschleunigen diese sich in ihrem gegenseitigen Mechanismus selbst. Echte Kommentare gehen dadurch oftmals unter. Das macht eine normale Diskussion über ein Thema unmöglich.

 

2. Die Trendsetter

 

Mit einer kleinen Bot-Armee, die immer und immer wieder dasselbe Hashtag verwendet, ist es möglich, die Themen-Agenda zu bestimmen. Unterhalten sich plötzlich tausende Bots auf Twitter über diesen Hashtag kann der Inhalt Bedeutung in der öffentlichen Debatte erlangen. Ein Thema erscheint damit plötzlich größer als es ist und echte Nutzer schließen sich einer "Fake-Bewegung" an, weil sie diese als eine echte Mehrheit begreifen.

 

3. Die Auto-Trolle

 

Diese Bots sollen einzelne Nutzer ablenken, damit diese möglichst viel Zeit mit sinnloser Diskussion verbringen. Wenn sich etwa zwei Nutzer über ein Thema unterhalten, klinkt ein solches Programm sich ein und schreibt immer wieder unpassende, extreme oder sogar beleidigende Argumente. Weil viele Nutzer dann auf diese fiktiven Provokateure reinfallen, gerät die normale Diskussion in den Hintergrund. Wer nicht merkt, dass er eigentlich mit einem Bot diskutiert, kann stundenlang beschäftigt sein."

Vgl. http://www.bpb.de/252585/was-sind-social-bots, abgerufen am 2.8.2019

Hierzu ein Beispiel von August 2019, das den breiten Einsatz dieser Technologie zeigt. Dabei traten Bots als Käufer von Schuhen ("seltene Sneaker") bei einem Onlineshop auf. Die Geschäftsidee ist anscheinend, möglichst viele dieser Schuhe schnell zu kaufen und sie dann gleich wieder, zu einem höheren Preis, an Sammler wieder zu verkaufen. So kamen, nach der Quelle, "fast 700000 Zugriffe" zusammen, wenn ein seltener Sneaker im Angebot war. So etwas wirkt "wie ein DDoS-Angriff".

Onlineshop trickst Kaufbots mit teuren Produktbildern aus

Lassen wir die Quelle sprechen: "Der Mitgründer des Skaterladens … hat eine Strategie entwickelt, um Bots und automatische Scripts bei Onlinekäufen auszutricksen. Statt begehrter Nike-Schuhe hat er lediglich deren Produktbilder für 10 Euro pro Stück online gestellt - inklusive passender Beschreibung. Bots haben diese trotzdem tausendfach automatisiert bestellt."

Näheres unter der Quelle: https://www.golem.de/news/ddos-onlineshop-trickst-kaufbots-mit-teuren-produktbildern-aus-1908-142999.html?utm_source=pocket-newtab Abruf am 9.8.2019.

19.1.12 Schattenseiten?

Das Thema "Zementierung" im Sinne von Zementierung von Prozessstrukturen durch deren Umsetzung in Programme wurde schon öfters thematisiert. Im Rahmen der RPA taucht ein weiterer Aspekt dieser Fixierung von IT- und Prozessstrukturen auf.

Vgl. Abschnitte 17.9, 18.10

Freund (CEO von Camunda) thematisiert die Frage, ob der Einsatz von RPA nicht dazu führt, dass "veraltete IT-Systeme und Strukturen" zementiert werden, in dem Sinn, dass der Einsatz von Softwarerobotern hilft, die veralteteten Systeme nicht abzulösen. Er hebt insbesondere auf den Punkt ab, dass es mit Hilfe von Softwarerobotern möglich ist, "Software ohne API in einen Workflow einzubinden und von einer Workflow-Engine steueren zu lassen". Gemeint ist z.B., dass ein Softwareroboter die ganz normale grafische Bedienoberfläche (GUI) eines anderen Programmes nutzt und dort Daten einträgt, abfragt, usw. Also auch, ohne dessen API (falls vorhanden) zu nutzen [Freund 2019, S. 20f].

Altsysteme + RPA

Er sieht da, annehmend dass "Altsysteme" per se "schlecht" seien, die Gefahr, dass der Druck, Altsysteme zu ersetzten nachlässt. Und dass damit den Organisationen ermöglicht wird, "die Kosten für neue IT zu umgehen" [ebenda].

Licht oder Schatten?

Dies kann aber natürlich auch ein Vorteil sein, wenn z.B. die Altsysteme gut funktionieren und erhalten bleiben sollen. Dann wird diese Möglichkeit in vielen Organisationen sicherlich als Vorteil gesehen.

Ein echter Nachteil ist der ebenfalls angesprochene Punkt, dass RPA-Lösungen eine "zerbrechliche Angelegenheit" sind, denn "sobald sich an der Oberfläche (GUI) auch nur ein kleines Detail ändert, muss der Softwareroboter neu programmiert werden" [ebenda, S. 21]. Dies, kann man ergänzen, gilt aber natürlich auch für Lösungen, die eine API zur Anbindung nutzen.

Zerbrechliche Lösung

In den Erfahrungsberichten der Nutzer von Softwarerobotern wird auch deutlich, dass die Softwareroboter oft von "den Fachabteilungen" gewollt und sogar eingeführt werden [Freund 2019], [Bremmer 2018a], sie also im Zusammenspiel von IT und Fachabteilung eher eine Sache der Fachabteilungen sind. Dadurch entsteht eine sog. Schatten-IT (oder wird ausgebaut), also ein Bereich der IT, der ohne Kontrolle der IT-Abteilung betrieben wird. So wie Excel-Lösungen, usw. Freund führt auf Basis einer Studie von Camunda aus, dass heute "61 % der befragten Führungskräfte und IT-Leiter gar nicht mehr wissen, wieviele Softwareroboter überhaupt im Einsatz sind" [Freund 2019, S. 21].

Schatten-IT

Frage:

Obigen Ausführungen liegt die Annahme zugrunde, dass eine Schatten-IT immer negativ ist. Ist das so?

19.2 Cognitive Process Automation (CPA)

Einfache RPA-Lösungen sind, wie oben beschrieben, auf der Leistungsfähigkeit konventioneller Programme angesiedelt. Sie folgen vorher festgelegten Abläufen und Geschäftsregeln mit fest definierten Inputs und Outputs. Mögliche Varianten im Ablauf müssen im Programm realisiert worden sein.

Vgl. Abschnitt 21.1.

Konventionell erstellte Programme sind also typischerweise nicht in der Lage, sich auf veränderte Situationen, auf Ausnahmen, usw. selbständig einzustellen. Sie sind auch nicht lernfähig. Dies soll durch den Einsatz von Techniken der Künstlichen Intelligenz – Forschung verbessert werden. Es wurde oben schon kurz angeführt, aus einfachen werden kognitive und dann intelligente RPA-Systeme, so die Wortwahl der Scheer GmbH.

KI: Künstliche Intelligenz

Deshalb die Weiterentwicklung, die Ergänzung des Einsatzes von Bots durch KI-gestützte Programme. Schlagwort: Von Bots zu Smart Digitization, RPA + KI, und weiter zu Cognitive Process Automation (CPA).

Kombination von RPA und KI

Was konkret damit gemeint ist, kann von den erwarteten Leistungen abgeleitet werden:

  • Anwenderverhalten replizieren mittels hinterlegtem Experten- und Prozesswissen
  • Vorausschauende Wartung(Predictive Maintenance)
  • Analyse von Finanztransaktionen und des Warenabsatzes
  • IT-Sicherheitslösungen, die eigenständig Cyber-Angriffe abwehren
  • Spracherkennung
  • Assistenzsysteme
  • Planungs-Tools mit Kl-Unterstützung
  • Automatisierung von IT- Administrationsaufgaben
  • Weitgehend selbständiges Erfassen von Prozessen mittels Musteranalysen und -erkennungsverfahren sowie neuronalen Netze. [Bayer 2018, S. 19]

Das ist eine umfassende Liste aus dem Werkzeugkasten der KI. Vieles zielt auf automatisiertes Lernen (i.d.R. mit neuronalen Netzen; vgl. Kapitel 21). Daneben wird Spracherkennung gefordert und natürlich Texterkennung.

Da hierbei meist das Ziel ist, die Prozesse rund um den Kundenservice umfassend zu automatisieren, werden folgende konkreten KI-Funktionen genannt:

  • Optische Zeichenerkennung (optical character recognition; OCR) zur Texterkennung.
  • Intelligente Zeichenerkennung (intelligent character recognition; ICR) für die Interpretation von Handschriften.
  • Maschinelles Lernen für erweiterte Inhaltsanalysen, z.B. um "die Position von Feldern auf Dokumenten wie Kundenrechnungen zu identifizieren" [Bremmer 2019a, S. 23]
  • Verstehen natürlicher Sprache (natural Language Processing; NLP)
  • Erzeugen natürlicher Sprache (natural Language Generation; NLG)
  • Automatisiertes Erkennen von Geschäftsprozessen und Aufgaben

[Safar 2019, S. 18f], [Bremmer 2019, S. 23]

Safar (Managing Partner der Weissenberg Group) weist auf die Bedeutung der zu bearbeitenden Daten hin. Er führt aus, dass die klassische RPA für strukturierte Daten geeignet ist. Bei unstrukturierten Daten und komplexen Prozessen, "stößt die klassische RPA an ihre Grenzen" ([Safar 2019, S. 18]). Auch das ist ein Grund, RPA-Lösungen um KI-Funktionalitäten zu erweitern.

Strukturiert / Unstrukturiert: vgl. Abschnitt 20.1.1

Beispiele

(1) Sebastian Zeiss beschreibt als ein Beispiel für die erfolgreiche Kombination von RPA und KI bei Telekom Service …

"die automatische Bearbeitung und Lösung von E-Mail-Anfragen an die Clearing-Abteilung: Bei der im zweiten Quartal 2018 ausgerollten Lösung wird der Inhalt der Mails via KI erkannt und durch Bots weiterbearbeitet." (Sebastian Zeiss, Vice President Lean Management Competence Center bei der Telekomm Service GmbH. Zitiert in [Bremmer 2018a, S. 37]).

(2) "Beim Ausfüllen eines E-Formulars für die Eröffnung eines neuen Bankkontos werden Daten falsch eingegeben oder ein Abschnitt wird vollständig ausgelassen. Bisherige Lösungen lehnen das fehlerhafte Formular ab. Ein kognitiv automatisierter Prozess identifiziert und korrigiert das Problem selbständig, ohne dass ein menschliches Eingreifen erforderlich ist" [Safar 2019, S. 19].

(3) Insbesondere "das Erkennen von Datenmustern" erlaubt gegenüber den klassischen RPA-Lösungen weitere Anwendungsszenarien:

  • "das Feststellen von Inkongruenzen zwischen Verträgen und Rechnungen
  • ein End-to-End-Kundenservice mit Chatbots: Mit der kognitiven Automatisierung können Chatbots erstellt werden, mit denen sich problemlos Änderungen an anderen Systemen vornehmen lassen;
  • die Abwicklung von Bankfinanzierungsgeschäften: CPA wickelt die Bearbeitung der Unterlagen ab und führt behördliche Prüfungen durch;
  • das Bearbeiten von Versicherungs/Serviceverträgen: Mit Hilfe von NLP-Techniken und OCR können Vertragsdaten extrahiert werden, um automatisierte Entscheidungen in Bezug auf Vertragsänderungen zu treffen;
  • die automatische Schadensregulierung in der Versicherung: Kognitive automatisierte Prozesse treffen selbständig Entscheidungen über Schadensfälle auf der Grundlage von Vertrags- und Schadensfalldaten und benachrichtigen die Zahlungssysteme."

[ebenda, S. 19]

Zusammenfassend beschreibt Safar die Unterschiede zwischen RPA und CPA wie folgt:

  • Bezüglich der Einsatzbereiche "übernimmt RPA repetitive Aufgaben, die keine Entscheidungen und keine menschlichen Eingriffe verlangen". Dagegen soll CPA in der Lage sein, "menschliche Verhaltensweisen nachzuahmen" (S. 19)
  • Bezüglich der Technologien sieht er bei RPA "Basistechnologien wie Screen Scraping, Makro-Scripting und Workflow- Automation". Dagegen kommen bei CPA auch KI-Techniken zum einsatz, insbesondere "Textanalyse, Data Mining, NLP, semantische Technologien und Machine Learning" (S. 19).
  • Bezüglich der verwendeten Methoden sieht er RPA als regelbasiert und auf der konventionellen Programmierung ("if-then-Prinzip"). Dagegen soll CPA wissensbasiert und zu selbstständigem Lernen fähig sein. (S. 19)
  • Bezüglich der vewendeten Daten sieht er RPA mit strukturierten und semistrukturierten Daten umgehend, während CPA auch unstrukturierte Daten verbeiten können soll, "indem sie Beziehungen und Ähnlichktien erkennt."

Vertieftes zum Unterschied von RPA und CSA findet sich in [Safar 2019, S. 19]: "RPA vs. CPA - vier Unterschiede".

19.3 Process Mining

19.3.1 Ausgangspunkt

Prozesserhebung ist ein mühsames Geschäft, dies sollten insbesondere die Kapitel 12 bis 16 deutlich gemacht haben. Die Abläufe werden weitgehend manuell beziehungsweise werkzeuggestützt ermittelt. Interviews mit Prozessnutzern und Prozessspezialisten sind zu führen, Unterlagen und Dokumentationen sind zu sichten, evtl. müssen ausgewählte Prozessabschnitte beobachtet werden. Die entstehenden Prozessmodelle und Prozesslandkarten müssen dann von den Betroffenen verstanden werden, was oft zusätzliche Anstrengungen mit sich bringt.

Klassische Prozesserhebung

Außerdem hat die Veränderungsrate von Geschäftsprozessen deutlich zugenommen, gerade auch im Rahmen der Bemühungen um IT-Unterstützung oder Automatisierung. Dies bedeutet zusätzlichen Aufwand, denn die Änderungen müssen eingepflegt werden.

Da lag die Idee nahe, auch die Erfassung von Geschäftsprozessen automatisiert zu realisieren. Diese Bemühungen, mit Hilfe von Software Geschäftsprozesse zu erfassen und zu analysieren, werden mit Process Mining bezeichnet. Im Wesentlichen geschieht dies, indem die digitalen Spuren der Geschäftsprozesse erfasst und ausgewertet werden. Wesentlicher Bestandteil dieser digitalen Spuren sind die Log-Dateien des Geschäftsprozesses (falls vorhanden).

Automatisierte Prozesserhebung

Ein tiefer liegender Grund für diese Versuche der softwaregestützten Prozessanalyse ist, dass die Geschäftsprozesse in vielen Organisationen nicht ausreichend modelliert und beschrieben wurden, vielleicht weil der Aufwand dafür sehr groß ist.

Leidensdruck

Voraussetzung für Process Mining ist, dass die Geschäftsprozesse oder Prozessabschnitte IT-gestützt sind, dass sie also regelbasiert immer gleich und mit klar strukturierten Daten ablaufen.

19.3.2 Ziele und Möglichkeiten

Das erste Ziel ist, wie oben schon angemerkt, die automatisierte Erfassung von IT-gestützten Geschäftsprozessen. Dies soll dann zahlreiche Möglichkeiten eröffnen.

Durch eine solche effiziente Erfassung der IT-gestützten Geschäftsprozesse sollen Optimierungsvorhaben erleichtert werden. Der Geschäftsprozess wird transparent, Änderungen sind leichter "einpflegbar".

Optimierung

Die digitalen Spuren der Geschäftsprozesse erfassen konkrete Durchgänge ("Instanzen") durch den Prozess. Damit können die Optimierungsbemühungen vertieft werden. Z.B. kann der Zeitverbrauch des ganzen Prozesses und seiner Abschnitte (leichter) erfasst werden.

Instanzen

Die Anpassung von automatisierten oder IT-gestützten Geschäftsprozesse an neue Abläufe oder Datenstrukturen ist durch die gewonnene erhöhte Transparenz erleichtert.

Anpassung

Damit ist auch eine erleichterte Erfolgsmessung, z.B. nach durchgeführten RPA-Projekten, möglich. Die Messung von Durchlaufzeiten und der Zahl der Ausführungen (als Grundlage für die Bestimmung von Prozesskosten) sollte für beide Zeitpunkte (vor und nach der Automatisierung) leicht möglich sein.

Erfolgsmessung

Noch weiter geht Rother (Gründer der Process Analytics Factory), der sich vorstellt, dass durch Process Mining neue Geschäftsmodelle und -abläufe entstehen sollen, während …

Ableitung von Prozessmodellen

"gleichzeitig bestehende Prozesse und Bereiche umgebaut und digitalisiert werden."

Verbesserungspotentiale in digitalisierten Prozessen sollen gefunden werden, die

"mit traditionellen Verfahren des Messens, Aufschreibens und in Workshop Bearbeitens" nicht gefunden werden können. [Rother 2018, S. 36]

19.3.3 Aktuelle Methoden

Einen kurzen Überblick über die aktuellen Methoden legt Safar (Managing Partner der Weissenberg Group) vor. Genannt werden:

  • Process Mining als solches, um "die relevanten Kern-, Unterstützungs- und Management-Prozesse sowie die dazugehörigen Key Performance Indicators (KPI) aufzuzeichnen und zu analysieren". [Safar 2018, S. 28]
  • Process Recording zur Aufzeichnung von Prozessaktivitäten.
  • Process Reporting "zur Evaluierung der realisierten Effizienzsteigerung." (S. 29)

Safar geht auch ein Stück weit auf die Implementierung der jeweiligen Softwarekomponenten ein. Für das Process Mining skizziert er eine mögliche programmtechnische Umsetzung wie folgt:

Process Mining als solches

"Hierzu wird die Software an einer zentralen Stelle im IT-System des Unternehmens installiert. Alle Systeme, in denen die einzelnen Aktionen oder Schritte in einem Log gespeichert werden können, werden durch einen Experten angebunden. Die Software greift auf die produktiven Log-Dateien zu und konvertiert diese in ein eigenes Datenformat. Die konvertierten Daten bilden die Datenquelle der grafischen Darstellungen." [Safar 2018, S. 28]

Damit sollen dann Auswertungen möglich sein, die Hinweise auf "für die Automatisierung geeignete Prozesse" geben. Für diese wird "ein Codegerüst zur Implementierung" erstellt (ebenda). Es soll also um eine Vorbereitung der Modellierung gehen.

Für das Process Recording wird die Software auf einem PC im Unternehmen installiert. Diese

Process Recording

"zeichnet alle Aktionen des Mitarbeiters bis hin zu einzelnen Mausklicks und Tastenanschlägen im Hintergrund auf. Das Ablaufdiagramm eines Prozesses wird durch die tatsächlichen Aktionen des Users am PC erstellt. Seine Ergebnisse hinterlegt der Recorder in einem Logfile, das anschließend mit Hilfe eines speziell entwickelten Analyseroboters und einer dort hinterlegten Mustererkennung ausgewertet wird." [Safar 2018, S. 29]

Bremmer (er benutzt den Begriff Desktop Activity Mining) weist darauf hin, dass bei dieser Vorgehensweise

"… auch solche Aktionen erfasst werden, die trotz ihrer Prozessrelevanz bisher nicht durch vorhandene IT-Systeme dokumentiert werden können – beispielsweise das Schreiben einer E-Mail." [Bremmer 2018b, S. 25]

Process Reporting meint die Visualisierung der relevanten Informationen über ein Dashboard. Grundlage der angezeigten Informationen sind "strukturierte Logfiles" der verschiedenen Bots. Für die "technische und geschäftliche Sichtweise können getrennte Dashboards eingerichtet werden.

Process Reporting

Safar gibt einen Einblick in typischerweise in solch einem Dashboard verwaltete Daten, wobei es in seinem Beispiel um die Messung des Erfolgs der Prozessautomatisierung geht. Er führt an:

  • die Durchlaufzeiten des Softwareroboters
  • die Zahl seiner erledigten (Teil-)Aufgaben
  • die gesparten Kosten
  • das "Zusammenspiel aus vollautomatisierter und mitarbeiterbasierter Entscheidungsfindung, welche als Variable in eine Metrik „Mitarbeiterentlastung" einfließt." [Safar 2018, S. 29]

19.3.4 Automatisierte Prozessmodellierung

Es klingt in den Artikeln und Erfahrungsberichten immer wieder an. Die Befürworter dieser Technologien sehen auch die Möglichkeit, Prozessmodelle automatisch aus der softwaretechnischen Prozessbeobachtung zu gewinnen.

So z.B. Safar, wenn er in Bezug auf Process Recording ausführt:

"Das Ablaufdiagramm eines Prozesses wird durch die tatsächlichen Aktionen des Users am PC erstellt. Seine Ergebnisse hinterlegt der Recorder in einem Logfile, das anschließend mit Hilfe eines speziell entwickelten Analyseroboters und einer dort hinterlegten Mustererkennung ausgewertet wird. Da der Process Recorder an keine weiteren Systeme angeschlossen werden muss, können mit geringem Organisationsaufwand und ohne lange Anlaufzeiten die relevanten Kennzahlen und die Kosten des manuellen Prozesses ermittelt werden." [Safar 2018, S. 29]

Ähnlich Bremmer. Aus den durch das Desktop Activity Mining gewonnenen Daten sollen mit Hilfe von Process-Mining-Algorithmenautomatisch Prozessmodelle entwickelt werden.

In [Reder 2019] ist ebenfalls die Vorstellung bemerkbar, dass die Bestandsaufnahme und Optimierung der vorhandenen Prozesse mittels Process Mining erfolgen kann (S. 15f).

Konkret geht es also darum, die digitalen Spuren, die bei der Nutzung eines Geschäftsprozesses entstehen, zu erheben und sie den hoffentlich vorhandenen Prozessbeschreibungen hinzuzufügen. Diese digitalen Spuren sind:

Digitale Spuren

  • Transaktionsdaten
  • Log-Dateien, die einzelne Schritte oder Aktionen speichern
  • Log-Daten, die automatisch von den prozessunterstützenden IT-Systemen generiert werden.

Dafür ist meist die Beachtung der Zusammenarbeit verschiedener Softwareprodukte nötig. Bayer beschreibt es recht detailliert:

"…Process Mining arbeitet mit Log-Daten, die automatisch von den prozessunterstützenden IT-Systemen generiert werden. Die Process-Mining-Tools bringen dafür Konnektoren oder sogenannte Loader zu Systemen wie beispielsweise Enterprise Resource Planning (ERP), Manufacturing Execution Systems (MES) und Supply-Chain-Management (SCM) beziehungsweise Datenbanken mit."

 

"Die eingesammelten Daten werden in einem sogenannten Event Log aufbereitet, das heißt vor der weiteren Analyse noch einmal auf Vollständigkeit, Konsistenz und Integrität geprüft sowie gegebenenfalls entsprechend bereinigt. Für eine sinnvolle Auswertung der Prozessdaten müssen diese bestimmte Voraussetzunger erfüllen: Es braucht mindestens eine Case-ID und eine Aktivitätsbezeichnung, um die Log-Daten eindeutig einem Prozesskontext zuordnen zu können, sowie Zeitstempel wie Start- und Endpunkte." [Bayer 2019a, S. 14]

Damit sind wir wieder bei der automatischen Prozessmodellgenerierung:

"Mit Hilfe des Event Log kann die Process-Mining-Software ein Ist-Modell des untersuchten Prozesses erstellen. Diese sogenannte Process Discovery bildet die Grundfunktionalität eines jeden Process-Mining-Werkzeugs." (S. 15)

Bei diesem Beispiel wird dann auch wieder ein tatsächlicher Vorteil dieser Vorgehensweise deutlich, die Betrachtung einzelner Prozessinstanzen. Bayer führt aus, dass mit dieser Process Discovery "viele unterschiedliche Prozessdurchläufe … analysiert werden können". Deren "Abweichungen und Variationen" erlauben dann die Abklärung von Faktoren, die "einen Prozess im positiven oder negativen Sinn beeinflussen." (S. 15) Ergänzen kann man, dass dadurch auch der Standardisierungsgrad des betrachteten Geschäftsprozesses geklärt werden kann. Dieser Vorteil liegt auch vor, wenn die Daten über den Prozess nur den Verlauf widerspiegeln.

Instanzenbetrachtungen

19.3.5 Heute und Morgen

Die oben beschriebenen Methoden können IT-unterstützte oder automatisierte Geschäftsprozesse beschreiben. Dies sind dann natürlich nur wohlstrukturierte Prozessabschnitte (vgl. Abschnitt 2.4). Semistrukturierte werden nur abschnittsweise erfasst. Unstrukturierte gar nicht.

So verstandenes Process Mining erfasst Nutzereingaben und Log-Dateien und wertet diese aus. Alle semantischen Strukturen sind damit nicht erfasst. Deshalb überrascht nicht, dass in der aktuellen einschlägigen Diskussion KI-Techniken betont werden. Mit diesen kann die Softwareinteraktion verbessert und der Bereich der wohlstrukturierten Aufgaben erweitert werden.

Heute

Angesichts dessen, dass die Standardtechniken des Process Mining nur ein eingeschränktes Bild der Geschäftsprozesse erbringen, wundert es nicht, dass die hier aktiven Unternehmen über eine Erhöhung der Leistungsfähigkeit nachdenken. Folgendes wird derzeit vorgestellt:

Morgen

Nutzung von Künstliche Intelligenz-Techniken und Machine Learning.

  • "Um Ursachen für Ineffizienzen und Abweichungen in den Prozessen zu erkennen."
  • "selbständig relevante Daten in unterschiedlichsten Systemen identifizieren und für die Prozessanalyse aufbereiten können."[ebenda]
  • Als Grundlage "für selbstlernende Prozesse …, in denen Zusammenhänge zwischen den Daten und Abläufen automatisch erkannt und mit Systemkonfigurationen sowie Kennzahlsystemen in Korrelation gesetzt würden."[ebenda]
  • Automatisierte Gewinnung von Kontextwissen aus den Systemdaten (Tobias Rother)

Vgl. Lana Labs nach [Bayer 2019a, S. 16]

Großflächige Prozessabdeckung

  • Verbesserung der Prozessabdeckung, hin zu einer möglichst großflächigen Erfassung ("Process Monitoring").
  • Kontinuierliche Erfassung und Optimierung der Geschäftsprozesse und ("Continuous Auditing").

Das Unternehmen Processgold hat dafür ETL-Funktionen entwickelt, die eine "integrierte Datenerfassung aus unterschiedlichsten Quellen wie SAP HANA, Microsoft SQL und Oracle erlauben." (so Rudolf Kuhn, CEO von Processgold, nach [Bayer 2019, S. 16f]). "Für die Transformation und Aufbereitung der einlaufenden Daten verfügt die Processgold-Lösung über eine eigene integrierte In-Memory-Datenbank." [ebenda]

Digitale Unternehmenslandkarte

Oliver Zeller (Geschäftsführer von Ploetz + Zeller ) "… bringt eine digitale Unternehmenslandkarte ins Spiel, die laufend Live-Daten aus dem Geschäftsbetrieb sammelt und anhand derer sich Prozesse beobachten, steuern und optimieren lassen. Die Verantwortlichen erhalten damit ein Abbild, wie Mitarbeiter, Kunden und Partner intern wie extern zusammenspielen" (Oliver Zeller, vgl. [Bayer 2019, S. 17]). Wichtig ist der von ihm gegebene Hinweis, "auch manuelle Abläufe, die keinen digitalen Fußabdruck in den IT-Systemen hinterlassen, in das Process Mining einzubeziehen" [ebenda].

19.3.6 Process Mining als wissenschaftliche Disziplin

In [van der Aalst 2016] findet sich eine umfassende Darstellung der wissenschaftlichen Bemühungen rund um Process Mining.

<<mehr dazu im Seminar/in der Vorlesung>>

19.3.7 Unternehmen

Folgende Unternehmen werden in den angeführten Artikeln genannt:

  • Processgold
  • Lana Labs. Berliner Process-Mining-Startup.
  • Celonis
  • Software AG. Hat nach der Übernahme der IDS Scheer AG die BPM-Suite ARIS in Richtung Process Mining weiterentwickelt.
  • Process Analytics Factory (PAF) GmbH. Darmstädter Startup.
  • Ploetz + Zeller.
  • Fluxicon https://fluxicon.com/

<<Diese Liste wird fortlaufend ergänzt und aktualisiert>>

19.3.8 Durchdringung, Ziele

[Reder 2019a] berichtet aus der Studie "Process Mining amp; RPA 2019" von IDG Research Services. Danach haben 18% der befragten Unternehmen (n=361) RPA-Pilotprojekte laufen oder abgeschlossen (S. 15). Als Beispiele für den Einsatz werden genannt (S. 16):

  • Call-Center und Helpdesk-Abteilungen, z.B. zum Zurücksetzen vergessener Passwörter.
  • Bereitstellen von Cloud-Servies
  • Erstellen von Angeboten durch eine Versicherung

Dabei sind die von den befragten Unternehmen genannten Ziele durchaus klassischer Natur:

  • Steigerung des Umsatzes
  • Niedrigere Kosten
  • Höhere Kundenzufriedenheit

Die befragten Unternehmen sehen derzeit folgende Probleme für den vertiefteren Einsatz von Machine Lerning-Techniken:

  • Die Qualität der vorhandenen Daten. Obwohl Daten von Maschinen und Produktionsanlagen sowie Transaktionsdaten, Kundeninformationen und Log-Daten vorhanden sind, mangelt es an der Qualität, die für die "Fütterung der ML-System" nötig ist (S. 19)
  • Unverständichkeit der Machine Learning-Algorithmen. Da könnten nur ML-Experten Abhilfe schaffen, die derzeit aber auf dem Arbeitsmarkt knapp sind, oder IT-Beratungsunternehmen.

19.4 Beispiele

19.4.1 Online-Fachhändler

Milad Safar, Managing Partner der Weissenberg Group, schildert ein Beispiel für den Einsatz bei einem Online-Fachhändler:

"Ein Online-Fachhändler vergleicht regelmäßig die Preise seiner Artikel mit den Preisen der identischen Artikel seiner Mitbewerber auf drei unterschiedlichen E-Commerce-Plattformen. Die recherchierten Informationen bilden die Grundlage für seine Preispolitik. Recherche und Kalkulation der optimalen Marge sind aber mit einem erheblichen zeitlichen Aufwand verbunden. Der Einsatz des Process Recorders ergab, dass der Mitarbeiter fünf Minuten benötigte, um den Preis für einen Artikel manuell aus drei Vergleichsportalen abzugleichen. Für den Preisabgleich von 5000 Artikeln auf den Vergleichsportalen summierte sich der Aufwand auf 52 Arbeitstage (bei acht Arbeitsstunden). Das bedeutete, dass die Preise nur alle zweieinhalb Monate aktualisiert werden konnten.

Nach der Automatisierung des Prozesses mittels RPA entnimmt ein Roboter dem System des Online-Händlers die notwendigen Artikeldaten und sucht die Artikel mit Hilfe festgelegter Kriterien auf den Portalen. Die Informationen über die gefundenen Artikel werden ausgelesen und gespeichert. Auf Grundlage dieser Daten erfolgt die Berechnung der optimalen Marge jedes einzelnen Artikels." [Safar 2018, S. 29]

Die Effizienzsteigerung ist in einem solchen Fall enorm. Die Auswertung der Daten ergab, "dass der Roboter die Arbeit, für die der Mitarbeiter noch fünf Minuten benötigte, in 16 Sekunden erledigt. Für den Preisabgleich von 5000 Artikeln braucht der Roboter jetzt gerade einmal 22 Stunden (2,7 Arbeitstage). Das entspricht einer Effizienzsteigerung von 95 Prozent." [ebenda]

19.4.2 ActBot

Von ActBots wird gesprochen, wenn Chatbots, Robotic Process Automation und Cognitive Computing verknüpft werden. Zur Erinnerung: Das Eigenschaftswort "cognitive" wird in diesem Bereich immer dann hinzugefügt, wenn KI-Techniken zum jeweiligen Instrumentarium hinzugenommen werden.

Haisermann/Rückershäuser schildern in Actbot-Beispiel, bei dem es um die Koppelung von "Mail-Bearbeitung beziehungsweise Chat und RPA" geht:

  • RPA-Bots für die Verarbeitung der jeweiligen Prozesse in Standardsoftwareprodukten wie CRM von Salesforce oder ERP/MM von S/4HANA.
  • Für das "Cognitive Computing und Chatbot" wurde, wegen dem "semantischen Konzept", das Angebot von Cognesysgewählt.
  • Für die RPA-Interaktion mit Salesforce und SAP S/4HANA fiel die Entscheidung auf das patentierte Bilderkennungsverfahren sowie das REST-API des Darmstädter RPA-Spezialisten Servicetrace.

[Haisermann und Rückershäuser 2019, S. 34]

Sie beschreiben dann drei Anwendungsfälle:

  • Anwendungsfall 1 (S. 35): "Direkte Kundenkommunikation mit Salesforce und Abgleich des Produktbestands in SAP S/4HANA im Modul MM. Abwicklung und Änderung der Bestellung zu einer Expressbestellung mit abschließendem Rechnungsversand über das SAP-Modul SD".
  • Anwendungsfall 2 (S. 36): "Lieferantenkommunikation via Chatbot mit einem RPA-Bot, der eine Saldenbestätigung im S/4HANA-Modul FI erzeugt und an den anfragenden Lieferanten per Mail versendet."
  • Anwendungsfall 3 (S. 36): "Mail-Eingang, Interpretation des Mail-Inhalts und Versenden einer Rechnungskopie aus dem S/4HANA-System."

Anwendungsfall 1 - Bestellungsänderung

Quelle für den nachfolgenden Text sind die Prozessbeschreibung und die prozessbeschreibende Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Der erste Anwendungsfall startet dadurch, dass ein Kunde für eine von ihm getätigte Bestellung den Status erfahren und gegebenenfalls eine Expresslieferung initiieren möchte. Folgende Schritte können aus dem in [Haisermann und Rückershäuser 2019, S. 35f] beschriebenen Beispiel abgeleitet werden (vgl. auch das unten angegebene Business Process Diagram):

(1) Kunde wählt die Webseiten bzw. das Portal des produzierenden Unternehmens an.

Kunde

(2) Kunde startet ChatBot und fragt nach dem Status seiner Bestellungen. Dies kann, wie man vielleicht aus eigener Erfahrung weiß, durchaus zu einer regen Kommunikation zwischen Mensch und Software führen. In diesem Fall zwischen einem ChatBot und einem Kunden. Im Wesentlichen wird dabei der Kunde mit seiner Kundennummer identifiziert.

Kunde und ChatBot

Zum nachfolgenden Business Process Diagram (BPD): Die "rege Kommunikation" wird hier durch das Element Gruppe ausgedrückt.

(3) Der ChatBot formuliert Anfrage für das CRM-System. Er kann also aus den Ausführungen des Kunden den Wunsch erkennen, er kennt auch die Struktur der Anfragen an das CRM-System und kann damit die Anfrage erstellen.

ChatBot zwischen Kunde und CRM

Hinweis: Im Beispiel ([Haisermann und Rückershäuser 2019, S. 35f]) wird der positive Fortgang beschrieben. Dass bei jeglichem Handeln mögliche Scheitern wird nicht betrachtet. In dem nachfolgenden Business Process Diagram wird dies genauso gehalten, das mögliche Scheitern aber durch ein Exclusive Gateway und ein Schlussereignis angedeutet.

(4) Der ChatBot greift auf CRM-System (Salesforce) zu, bestimmt alle Bestellungen des Kunden und prüft den jeweiligen Bestellstatus.

ChatBot mit CRM

(5) Der ChatBot zeigt dem Kunden die Ergebnisse an. Der Kunde wählt eine Bestellung aus und verlangt für diese eine Expresslieferung.

Kunde mit ChatBot

(6) Der ChatBot gibt die Anfrage an einen RPA-Bot weiter.

ChatBot und RPA-Bot

Zum nachfolgenden BPD: Dies wurde mit Empfänger-/Sender-Aufgaben modelliert. Alternativ wäre auch ein einfacher Informationstransport möglich.

(7) RPA-Bot greift auf SAP-S/4HANA-Modul MM zu und prüft, ob eine entsprechende Bestandsmenge vorhanden ist.

RPA-Bot und SAP MM

Zum nachfolgenden BPD: Dies wurde als Dienst-Aufgabe (service task object) modelliert. Besser wäre – parallel zur Nutzeraufgabe (user task object) – ein Aufgaentyp "bot task objekt" (Bot-Aufgabe), der ist aber derzeit noch nicht vorgesehen.

Die weiteren Prozessschritte gelten für den positiven Fortgang. Falls positiv, d.h. falls die Bestandemenge eine Expresslieferung zulässt:

(8) Der RPA-Bot übergibt die Informationen an den ChatBot.

RPA-Bot und ChatBot

Zum nachfolgenden BPD: Auch dies wurde wieder mit Empfänger-/Sender-Aufgaben modelliert. Alternativ wäre auch ein einfacher Informationstransport möglich.

(9) Der ChatBot bestätigt dem Kunden, dass Expresslieferung "zu einem bestimmten Preis" möglich ist.

ChatBot und Kunde

Auch hier wird wieder ein positiver Fortgang angenommen, d.h. dass der Kunde tatsächlich die Bestellung auf Expresslieferung umstellen will.

(10) ChatBot bittet Kunden um Bestätigung, Nennung seiner E-Mail-Adresse, um die "Zustimmung zum Datenschutz" und nimmt die Angaben entgegen.

ChatBot und Kunde

(11) ChatBot greift auf CRM-System zu und stellt die ausgewählte Bestellung auf Expressversand um.

Chat-Bot und CRM

Der RPA-Bot leitet den Prozess der Rechnungserstellung ein.

(12) ChatBot weist Kunden darauf hin, dass er in Kürze eine Rechnung in seinem elektronischen Postfach findet.

ChatBot und Kunde

(13) ChatBot meldet sich im SAP-S/4HANA-Modul FI/SD an, erstellt eine Ausgangsrechnung und sendet diese an die Kunden-Mail-Adresse.

Chat-Bot und SAP FI/SD

Die Zugriffe des RPA-Bots auf Software wurden a) durch eine entsprechende Grafik (PC-Symbol) und b) durch einen Pfeil für den Informationsaustausch modelliert.


Abbildung 19.4-1:

BPMN-Prozessmodell ActBot-Beispiel - Teil 1
Erstellt nach der textlichen Beschreibung und der Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Anmerkung für die WebTexte: Obige Grafik wird in der Veranstaltung in besserer Qualität verteilt. Vgl. auch www.staud.info/grafiken2020/grafiken.html.


Abbildung 19.4-2:

BPMN-Prozessmodell ActBot-Beispiel - Teil 2
Erstellt nach der textlichen Beschreibung und der Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Anmerkung für die WebTexte: Obige Grafik wird in der Veranstaltung in besserer Qualität verteilt. Vgl. auch www.staud.info/grafiken2020/grafiken.html.

Anwendungsfall 2 - Saldenbestätigung

Quelle für den nachfolgenden Text sind die Prozessbeschreibung und die prozessbeschreibende Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff]. Daraus wurde auch wieder ein Business Process Diagram, vgl. die folgende Abbildlung, abgeleitet.

Hier geht es um eine Saldenbestätigung, d.h. ein Lieferant möchte von einem Kunden seine Forderungen bestätigt haben. Im Beispiel ist der Kunde ein Fahrradhersteller mit einem seiner Lieferanten.

Hier die einzelnen Prozessschritte:

(1) Der Lieferant wählt die Webseiten/das Portal des Kunden (des produzierenden Unternehmens) an. Das Beispiel geht davon aus, dass der Lieferant auf einen ChatBot stößt und diesen startet.

Lieferant und ChatBot

(2) In der Kommunikation zwischen Lieferant und Kunde wird der Lieferant durch den ChatBot einschließlich seiner Lieferantennummer identifiziert. Anschließend wird sein Wunsch auf Saldenbestätigung erfasst.

Lieferant und ChatBot

Im nachfolgenden Business Process Diagram (BPD) wird diese Interaktion wieder durch ein Element Gruppe modelliert.

(3) Der ChatBot übergibt über ein REST API die Lieferantennummer an den RPA-Bot und bittet um Prüfung, ob der Lieferant Forderungen hat.

ChatBot und RPA-Bot

(4) Der RPA-Bot prüft im S/4HANA-Modul FI, ob der Lieferant Forderungen hat.

Dies ist derzeit die Standardsituation rund um RPA: Der RPA-Bot nutzt eine Software. Er kennt also die Eingabebedingungen, die Struktur der Eingaben und kann die Antworten der Software entgegennehmen sowie interpretieren.

(5) Falls der Lieferant Forderungen hat ("positives Ergebnis"), wird dies dem ChatBot gemeldet. Dieser übermittel das positive Ergebnis ("Ja, Sie haben Forderungen, …") an den Lieferanten und bittet diese um Zusendung seiner E-Mail-Adresse.

RPA-Bot und ChatBot

(6) Der ChatBot übergibt dann die Mail-Adresse, die Lieferantennummer und den Wunsch des Lieferanten an den RPA-Bot.

ChatBot und RPA-Bot

(7) Der RPA-Bot greift auf das SAP-S/4-Modul FI zu, erstellt eine Rechnungsübersicht und wandelt diese in ein PDF-Dokument.

(8) Der RPA-Bot sendet die Rechnungsübersicht per Mail an den Lieferanten.

RPA-Bot und Lieferant

(9) Falls der Lieferant keine Forderungen hatte, wird dies ebenfalls dem ChatBot gemeldet. Dieser übermittelt das negative Ergebnis dem Lieferanten.

Die Zugriffe des RPA-Bots auf Software wurden a) durch eine entsprechende Grafik (PC-Symbol) und b) durch einen Pfeil für den Informationsaustausch modelliert.


Abbildung 19.4-3:

BPMN-Prozessmodell Saldenbestätigung
Erstellt nach der textlichen Beschreibung und der Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Anmerkung für die WebTexte: Obige Grafik wird in der Veranstaltung in besserer Qualität verteilt. Vgl. auch www.staud.info/grafiken2020/grafiken.html

Anwendungsfall 3 – Reklamationsmanagement

Quelle für den nachfolgenden Text sind die Prozessbeschreibung und die prozessbeschreibende Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Bei diesem Beispiel findet die Kommunikation ausschließlich per Mail statt. Betrachtet wird die Anforderung einer neuen Rechnungskopie durch einen Lieferanten. Vgl. auch das nachfogende Business Process Diagram.

Hier die einzelnen Prozessschritte:

(1) Kunde oder Lieferant sendet eine Mail an die "Cognitive-Instanz". D.h., der Kunde stößt mit seiner Anfrage auf Softwarekomponenten, die KI-Techniken realisieren.

Kunde und Cognitive-Instanz

(2) Die Cognitive-Instanz interpretiert und klassifiziert die Mail.

Cognitive-Instanz

(3) Die Cognitive-Instanz prüft, ob die Daten vollständig sind.

(4) Falls die Daten vollständig sind, werden sie über das REST API an den RPA-Bot übergeben.

Cognitive-Instanz und RPA-Bot

Im Beispiel wurde nicht ausgeführt, was geschieht, falls die Daten nicht vollständig sind. So wird es auch hier gehalten.

(5) Der RPA-Bot nimmt die Daten an und zieht im S/4HANA-System eine Rechnungskopie.

RPA-Bot mit SAP S/4HANA

(6) Der RPA-Bot versendet die Rechnungskopie an den Lieferanten. Der RPA-Bot soll also auch selbständig Nachrichten versenden können.

In diesem Beispiel spielt die sog. Cognitive-Instanz (vgl. Abschnitt 19.2) eine zen­trale Rolle. Ihre Aufgabe der Interpretation und Klassifizierung von Mail verlangt eine leistungsstarke KI-Lösung.

Anmerkungen zu den obigen Beispielen

Insgesamt ergeben die Beispiele ein eindrucksvolles Bild bzgl. des notwendigen Zusammenspiels von Softwarekomponenten. Es wirken mit:

  • RPA-Bots
  • CRM (Salesforce)
  • Module von SAP S/4HANA.
  • Cognitive Computing
  • Bilderkennungsverfahren sowie eine REST-API
  • ChatBots

Für eine detaillierte Beschreibung des Ablaufs vgl. [Haisermann und Rückershäuser 2019].


Abbildung 19.4-4:

BPMN-Prozessmodell Reklamationsmanagement
Erstellt nach der textlichen Beschreibung und der Abbildung in [Haisermann und Rückershäuser 2019, S. 34ff].

Anmerkung für die WebTexte: Obige Grafik wird in der Veranstaltung in besserer Qualität verteilt. Vgl. auch www.staud.info/grafiken2020/grafiken.html.

19.4.3 RPA Datenbankübergreifend

Herrmann erwähnt als Einsatzgebiete für RPA datenbankübergreifende Abgleiche von Informationen. Beispielsweise die Änderung von Kundenadressen, z.B. in der Finanz- und Versicherungsbranche. Auch eine polizeiliche Personenüberprüfung, wie sie etwa beim Beantragen eines Waffenscheins obligatorisch ist, ließe sich, so Herrmann, beschleunigen. Bearbeiter müssen heute verschiedene Datenbanken konsultieren, um zu prüfen, ob gegen einen Antragsteller etwas vorliegt. Diese Aufgabe könnte ein RPA-System zumindest teilweise erledigen und beispielsweise alle Personen aussortieren, für die kein negativer Eintrag zu finden ist. Genauer prüfen müssten die Bearbeiter dann nur noch wenige Einzelfälle [Herrmann 2017, S. 20].

Ein konkretes Beispiel für datenbankübergreifende Aktivitäten führt Bayer an:

Dekabank

"So hat die Dekabank nach der Übernahme der Landesbank Berlin Investment (LBB-Invest) 2014 rund 46.000 Wertpapierdepots in ein einheitliches System übertragen. Eine manuelle Migration inklusive Datenprüfung hätte rund drei Jahre gedauert, so die Kalkulation der Verantwortlichen. Der gemeinsam mit Capgemini Consulting entwickelte Softwareroboter schaufelte die Depotdaten innnerhalb von zehn Tagen in das Dekabank-System und sorgte nebenbei auch noch für eine bessere Datenqualität, indem er unplausible Datensätze erkannte und automatisch reparierte." [Bayer 2018, S. 19]

19.4.4 Automatisierte Prozesserkennung

Ulrich Storck (Head of Product Development bei der Scheer GmbH) beschreibt in einem Vortrag auf dem Scheer Digital World Congress 2018 in Frankfurt am Main die Scheer Process Automation Suite als "Low-Code-Plattform für die modellgetriebene Digitalisierung und Automatisierung von menschlichen Arbeitsprozessen." [Bremmer 2018b, S. 24]

Scheer Process Automation Suite (PAS)

Sie dient als

"… eine Methode, mit deren Hilfe Arbeitsprozesse automatisiert erfasst und dokumentiert werden können. Mit Desktop Activity Mining, das Techniken aus dem Data und Process Mining nutzt, würden Vorarbeiten entfallen, die bisher für RPA notwendig waren. Im Detail werden über ein im Hintergrund laufendes Aufnahmeprogramm die relevanten Prozessaktionen der Mitarbeiter wie Texteingaben, Mausklicks oder Programmaufrufe identifiziert und anonymisiert erfasst. Aus diesen werden dann mit Process-Mining-Algorithmen Prozessmodelle generiert, um eine umfangreiche Darstellung des realen Arbeitsprozesses zu erhalten." [Bremmer 2018b, S. 25]

Dies erscheint beim gegenwärtigen Entwicklungsstand nicht möglich, erfasst doch die Aktvität des Nutzers am Desktop, selbst wenn sie sehr umfassend erfolgt, nur einen Teilaspekt des Geschäftsprozesses. So auch Ulrich Storck, der in seinem Vortrag auch anmerkt, dass sich bzgl. RPA bei vielen Anwendern "eine gewisse Ernüchterung einstellt, "geboren aus der Erkenntnis, dass RPA nicht die eierlegende Wollmilchsau ist, sondern nur ein Mittel von vielen." [Bremmer 2018b, S. 24]

Realismus