Kaizen 2 go 191 : Process-Mining und Robotic-Process-Automation

 

Inhalt der Episode:

  • Stichworte bzgl. Process Mining und Robotic Process Automation
  • Welcher Nutzen wird aus Process Mining gezogen? Welche Voraussetzungen sind dafür gegeben?
  • Was lässt sich zu der Nutzenfrage bzgl. RPA sagen? Welche Voraussetzungen sind dafür notwendig?
  • Welche Wechselwirkung gibt es zwischen Process Mining und Robotic Process Automation?
  • Welche Rolle spielt der Mensch, speziell im Zusammenhang mit RPA?
  • Welche Fragen sollten sich die Unternehmen und Entscheider im Zusammenhang mit einem möglichen Einstieg in Process Mining und/oder RPA stellen?

Notizen zur Episode:

Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei iTunes.
Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Episode 191 : Process-Mining und Robotic-Process-Automation

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Markus Starke bei mir im Podcast-Gespräch. Er ist selbständiger Berater mit Fokus auf Prozess- und Organisationsberatung. Hallo Herr Starke.

Markus Starke: Hallo Herr Müller, danke schön, dass ich hier dabei sein darf.

Götz Müller: Ja, Schön, dass es heute klappt. Ich habe schon einen halben Satz zu Ihnen gesagt, aber ergänzen Sie das gern noch mal mit zwei, drei Sätzen.

Markus Starke: Sehr gerne. Genau, wie Herr Müller gesagt hat, ich bin selbständiger Berater, seit mittlerweile fast vier Jahren selbständig. Vorher habe ich ein Stück weit so eine klassische Beratungskarriere hinter mir in mehreren kleinen, mittleren und großen Beratungen gearbeitet. Ursprünglich so ganz klassische Prozess- und Organisationsberatung, habe auch mal eine Six-Sigma-Ausbildung gemacht und mittlerweile geht's aber vielmehr wirklich auch um Prozessdigitalisierung und digitale Transformation mit Fokus auf Prozess-Themen. In Summe ist das dann ganz oft auch Aufbau von ja Organisationseinheiten oder Bereichen und den zugehörigen Prozessen. Genau. Ein kleiner Funfact: In meinem ersten Leben bin ich studierter Orchestermusiker und auch noch immer recht ambitionierter, aber nicht mehr so zu mit dem beruflichen Fokus, ambitionierter Posaunist ist und genau, das ist so eine kleine Spezialität. Ich arbeite in meiner Beratertätigkeit natürlich auch viel mit anderen Beratern zusammen, unter anderem mit der ten4 Consulting und genau das eben mit Fokus auf Prozessen, aber mittlerweile viel IT-näher und digitalisierungsnäher als das noch vor fünf bis acht oder zehn Jahren der Fall war.

Götz Müller: Mir kam gerade der spontane Gedanke … Ihr, sagen wir mal, früheres Leben hat ja auch schon viel mit Harmonie zu tun gehabt.

Markus Starke: Ja, das stimmt.

Götz Müller: Das lässt sich hier gut übertragen.

Markus Starke: Das kann man so sagen. Auf jeden Fall kann man auch, finde ich, den Rückschluss immer ziehen, Prozessberatung hat immer ganz viel auch mit, ja, auch mit zwischenmenschlichem Verstehen und Verstehen von komplexen Zusammenhängen zu tun und da gibt es natürlich auch starke Parallelen zum Thema Musik und Orchestermusik.

Götz Müller: Und wenn es da Misstöne gibt, dann funktioniert das Ganze auch nicht.

Markus Starke: Genau.

Götz Müller: Gut. Jetzt haben wir ein spannendes Thema, wo sich zwei Dinge in zwei Welten begegnen, also sowohl einerseits Prozess, andererseits eben auch Digitalisierung und da zum Einstieg … ich hatte schon mal eine Episode, ja schon vor Jahren, wo es um das Process Mining geht, da kann man also im Zweifelsfall noch mal etwas nachhören, was jetzt aber sicher neu ist, ist das Thema Robotic Process Automation, deshalb mal da noch ein paar Stichworte speziell zum Einstieg.

Markus Starke: Gerne. Genau. Vielleicht erstmal noch mal kurz zum Thema Process Mining. Ja, wie hat man sich früher über Prozesse Gedanken gemacht? Also auch heute noch macht man da meistens, wenn man die Prozesse analysiert, Interviews, schaut sich irgendwie bestehen Dokumentationen an, die meistens irgendeine Form von Soll-Zustand darstellen sollen, malt irgendwas an einem Whiteboard. Das Ganze ist dann häufig sehr qualitativ ausgerichtet und dann versucht man es gegebenenfalls noch durch ein Zahlenwerk zu ergänzen zum Beispiel mit Six-Sigma-Methodik. Wenn man an Process Controlling denkt, dann ist es heutzutage oder in der Vergangenheit meistens sehr auf, ich sage mal recht statische Kennzahlen fokussiert, also in Anführungsstrichen einfache Business Intelligence. Process-Mining erlaubt aber eine wesentlich quantitativ orientierte und detailliertere Aufnahme von Ist-Prozessen basierend auf den Systemdaten. Voraussetzung ist natürlich, dass das auch Prozesse sind, die zum größten Teil in Systemen abgebildet sind. Dazu, wenn man ans Controlling denkt, erlaubt es also auch, sich nicht nur mit den Prozess-Ergebnissen, sondern auch mit dem eigentlichen Prozessablauf dann auch viel mehr zu beschäftigen. Ich sage da immer ganz gerne, so das klassische Process Controlling beantwortet vielleicht die Frage „Hat ein Prozess funktioniert?“ oder vielleicht noch „Wie gut hat ein Prozess funktioniert?“, also „Wie gut ist das Ergebnis eines Prozesses?“, während Process Mining zum Beispiel geht ja viel mehr auf detaillierte reale Werte ein und kann also auch Fragen beantworten „Warum hat ein Prozess nicht funktioniert und wie kann ein Prozent verbessert werden?“, kann also durchaus weiterreichende Fragen. Wenn wir jetzt mal richtig Richtung RPA denken, auch wenn wir da vielleicht mal ein bisschen versuchen so ein bisschen zu sagen, früher … wie war's früher? Wie ist es heute? Früher, jetzt natürlich deutlich vereinfacht und schwarz-weiß gemalt, gab's Automatisierung in den Prozessen, fast ausschließlich über entweder programminterne Logiken und oder separat programmierte Schnittstellen, die eben da wirklich auch sehr technisches Know-how erfordern und für den Business User kaum nachvollziehbar sind. Meistens auch mit einer relativ langwierigen Umsetzung verbunden sind. Es gibt noch diese kleine Ausnahme, die ich jetzt gerne nenne, weil man die auch im Zusammenhang mit RPA immer gerne nennt, das ist das Thema Excel Makros, wo so der ein oder andere vielleicht auch der jetzt sonst nicht so viel programmiert oder so sich da vielleicht trotzdem auch schon mal ein bisschen wohlgefühlt hat und damit einfache Vorgänge, ich sag mal, automatisiert hat und da kommen wir dann nämlich auch zum Übergang zum Thema Robotic Process Automation, RPA, wo viele sagen „Okay, das ist ja eigentlich wie ein Excel Makro nur größer und besser und tatsächlich ist das eine Form der Automatisierung, die sich im Wesentlichen auf der Benutzeroberfläche der Systeme bewegt, wo also der Roboter, ja, eigentlich die Aktivitäten eines menschlichen Nutzers simuliert oder nachahmt. Also normalerweise agiert der Roboter ja dann genauso wie ein menschlicher Nutzer. Das Schöne an einigen oder den meisten RPA-Lösungen ist halt auch, dass die Definition der Roboter vergleichsweise einfach ist. Also da spricht man dann auch gerne von low-code- bis no-code-Lösungen, wo also fast kein Programmierer Wissen notwendig ist und teilweise sogar noch darüber erleichtert, dass die Lösungen bis dahin gehen, dass man wirklich auch die Prozesse einfach oder die menschlichen Handlungen einfach aufnimmt und dann lernt der Roboter das basierend auf diesen Aufnahmen, auf diesen Recordings. Tatsächlich habe ich das selber mal in einem Projekt mal mit umgesetzt, wo wir eine kleine Pilotierung hatten, wo wir einen nicht ganz einfachen Prozess innerhalb von wenigen Stunden auf die Art und Weise wirklich zu einem brauchbaren Proof of Concept bringen konnten. Und was ich auch spannend finde an Robotics, an der RPA, ist, dass man damit halt auch durchaus die Interaktion mit den menschlichen Nutzern ermöglicht. Da gibt's so dieses Stichwort Hybride Automatisierung, also Automatisierung, die sich quasi zwischen dem Menschen und dem Roboter bewegt. Ganz ganz wichtig finde ich immer zu sagen, dass RPA normalerweise jetzt keine echten end-to-end-Prozesse abbildet, sondern dass es am Ende meistens Fokus auf relativ abgegrenzte kleine Aufgaben ist, womit man sich da beschäftigt.

Götz Müller: Gut. Jetzt wird sich vielleicht der ein oder andere fragen, ein bisschen hatten Sie es schon angedeutet, ich möchte es aber noch ein bisschen vertiefen: Was habe ich davon? Also sowohl auf der Process-Mining-Seite als auch auf der Robotic-Process-Automation-Seite.

Markus Starke: Wenn wir mal an Process Mining denken, da gibt es, also wenn man sich die Literatur anschaut steht, die Benennung ist da manchmal so ein bisschen abweichend, aber grundsätzlich gibt's da so drei bis vier Anwendungsfälle. Der erste Fall ist Process Discovery, also einfach das Verstehen und Entdecken eines Prozesses: Wie sieht der Ist-Prozess aus? Welche Variationen gibt es und welche Vielfalt gibt es? Das zweite wäre dann Process Improvement, also aus dieser Entdeckerphase auszutreten und quasi Verbesserungspotenziale aufzudecken und diese dann auch umzusetzen. Die dritte Variante wäre dann zusagen Process Conformance oder Conformance Checking, wo halt überprüft wird, passt der Prozess wie er ausgeführt wird zu bestimmten Vorgaben. Erfüllt er sozusagen … passt er zu dem Soll-Prozess. Da erlauben die Lösungen teilweise dann auch den Abgleich der Ist-Prozesse, also der real aufgenommen Ist-Prozesse das Abgleichen mit einem vorgegebenen BPM-Modell, BPMN-Modell und der vierte Use Case für Process-Mining ist so dieses Process Controlling, wo man wirklich sagt „Okay wir machen ein laufendes Controlling der Prozesse mit Hilfe einer Process-Mining-Lösung.“ Also konkret gesprochen würde sich das natürlich zum Beispiel im Bereich Prozessanalyse und Prozessoptimierung anbieten, dann auch in Audit-Situationen, wo man also sagt, man will irgendwie überprüfen, ob die Prozesse bestimmten Audit Anforderungen gerecht werden oder zum Beispiel auch wenn wir jetzt an das Process Controlling denken, halt wirklich Steuerung von Prozessen und Teams, also wirklich auch die Teams in der laufenden Arbeit sozusagen zu begleiten und zu kontrollieren und dann eben auch Maßnahmen zu ergreifen. Wenn wir jetzt mal so drüber nachdenken, was braucht es alles, wie funktioniert das, kann man das vielleicht aufteilen in technische und organisatorische Voraussetzungen. Und technisch kann man sagen, okay man braucht halt für Process Mining schlicht und einfach Eventlogs. Eventlogs bedeutet, man braucht eine Auflistung dessen was passiert in den Prozessen. Das heißt man braucht eine eindeutige Bezeichnung des eigentlichen Vorgangs des Prozessdurchlaufs, dann braucht man die Aktivitäten, die passieren und die jeweiligen Zeitpunkte, zu denen die Aktivitäten passieren und daraus wird in so einer Process-Mining-Lösung halt rekonstruiert. Da entsteht dann auch durchaus aus sehr großen Datenmengen dann ein detailliertes Bild der Ist-Prozesse, wo man häufig sieht, dass es viel mehr Variationen gibt als man erstmal annimmt. Also oft ist es ja so, wenn man irgendwie eine Prozessaufnahme des Ist-Prozesses macht, dann kommt man irgendwie auf zwei, drei, vier Variationen. Wenn man das mit Process Mining macht kommt man auf teilweise hunderte bis tausende Prozess-Variation. Wie erfolgt dieser Zugriff auf die Eventlogs? Also auch eine technische Voraussetzung. Teilweise bieten Systeme das an, dass sozusagen da ein entsprechend strukturierter Export schon vorhanden ist, teilweise muss es halt ein separat definierter Export mit Hilfe eines ETL-Tools sein. Man kann auch durchaus und da ist zum Beispiel schon eine Verknüpfung mit RPA gegeben, ich habe schon mal an einem Konzept gearbeitet, wie man RPA nutzt, um Eventdaten zu extrahieren. In Einzelfällen für, ich sag mal rein beispielhafte Analysen, habe ich es tatsächlich auch schon durchgeführt, dass das die Eventlogs mehr oder weniger händisch generiert wurden. D kriegt man natürlich überhaupt keine repräsentative Datenmenge raus, aber da kann man durchaus auch mal so ein paar Beispiele sich mal erstellen.

Götz Müller: Ja. Und das fällt dann wahrscheinlich dann auch, wenn man es von Hand machen müsste, eher in die Kategorie Strafarbeit.

Markus Starke: Genau, das fällt in die Kategorie Strafarbeit, wo man jemand Freiwilliges dafür finden muss. Genau. Aber gut, manchmal als allererster Startpunkt, wenn man mal wie nur mit einem ein, zwei Tage mal investieren will, ob das Ganze überhaupt irgendwie einen Sinn hat oder nicht, kann man da vielleicht auch mal mit einer ganz begrenzten Anzahl Cases dann starten. Genau. Eine Herausforderung ist durchaus auch dann diese Eventlogs dann natürlich in eine brauchbare Form zu bringen. Da spricht man dann von der Transformation der Daten, da muss man vielleicht auch manchmal die Events noch mal anreichern, vielleicht zusätzliche Informationen wie Stammdaten hinzufügen, mehrere Datenquellen halt miteinander verknüpfen über einheitliche Unique Identifiers und Daten-Qualitätsprobleme auch irgendwo lösen und dann schließen sich halt an auch dann die eigentlichen Analysen und gegebenenfalls auch zu definieren und zu entwickeln. Wenn wir jetzt an organisatorische Voraussetzungen vielleicht noch mal denken, um da ein bisschen den Schwenk zu kriegen, das ist ja schon relativ technisch. Es ist, glaube ich, ganz zentral, dass man sich überlegt, welche Prozesse will man sich eigentlich anschauen. Also welcher Prozess ist es eigentlich wert, dass wir ihn uns anschauen. Das muss natürlich zum Beispiel überhaupt erstmal ein Prozess sein, der auch zu wesentlichen Teilen digitalisiert ist, wo es überhaupt Eventlogs gibt. Dann brauchen wir natürlich auch das notwendige Know how, also sowohl für diese technischen Schritte als auch zur Analyse. Zur Analyse braucht man, ich sag mal, klassische Prozess-Analyse-Skills, also Six Sigma und Lean helfen da, aber halt auch natürlich fachliches Spezialwissen, aus den jeweiligen Fachbereichen, die betroffen sind und auch meistens Wissen aus der IT, die einem hilft, die Eventlogs noch mal zu interpretieren, weil das oft nicht so selbsterklärend ist, was steht da nicht drin.

Götz Müller: Jetzt habe ich gerade so einen konkreten Fall vor meinem geistigen Auge … Das ist jetzt sehr produktionsnah, wobei nah im Grunde noch untertrieben ist, es ist im Grunde Produktion, wo man halt klassisch eine Wertstromanalyse macht, also so mit Post-its vor einer großen weißen Wand steht am Anfang und da jetzt mal konkret nachgefragt, sind so etwas dann auch Möglichkeiten oder sind das dann eventuell Dinge, wo es an den verfügbaren Daten scheitert?

Markus Starke: Also ich habe tatsächlich mit einem Process-Mining-Anbieter zum Beispiel schon zusammengearbeitet oder zu tun gehabt, der auch vermehrt sagt „Wir beschäftigen uns auch mit Produktionsfragen.“ und tatsächlich liefern Produktionssystem ja durchaus auch eine ganze Menge an Daten. Also das muss man natürlich immer im Einzelfall bewerten, aber grundsätzlich würde ich davon ausgehen, dass man häufig aus dem Produktionssystem auch etwas rauskriegt, gerade in der pharmazeutischen Produktion oder überall, wo es irgendwie so track-and-trace-Erfordernisse gibt, müsste man eigentlich aktiv genau wissen, was passiert wann und das sind ja genau die Daten, die man dann auch potentiell für Process Mining verwenden kann. Also alles, wo irgendwie Chargen nachverfolgt werden oder Artikelnummern nachverfolgt werden, da müsste sowas eigentlich relativ gut funktionieren, aber muss man sich immer im Einzelfall anschauen. Also deswegen bietet sich bei Process Mining meiner Meinung nach immer an, erstmal so eine Art kleine Machbarkeitsstudie zu machen.

Götz Müller: Okay, gut. Jetzt haben relativ viel noch über Process Mining gesprochen, wie sieht die vergleichbare Frage, also sowohl den Nutzen, als auch Voraussetzungen, ein bisschen was hatten Sie auch schon angedeutet, auf der RPA-Seite aus?

Markus Starke: Genau. Gerne. Also RPA, wie gesagt, ist ja noch ein alternativer Automatisierungsansatz, mittlerweile auch nicht mehr neu, auch schon seit einigen Jahren unterwegs in Unternehmen und immer etablierter. Nutzen, vereinfacht gesagt natürlich, die Automatisierung von relativ einfach strukturierten, aber zeitintensiven und sehr repetitiven Aufgaben. Also das sind gleich da auch ein Stück weit die Voraussetzungen, die Aufgaben und Aufgaben und Daten müssen halt klar strukturiert sein oder strukturierbar sein. Der Vorteil ist, dass man damit häufig sehr schnell auf Ergebnisse kommt, wie gesagt und mithilfe von solchen Recording-Funktionen wenig Programmierungsnotwendigkeit, relativ einfache Konfiguration der Robots. Das erlaubt halt zum Beispiel auch häufig den Fachabteilunge diese Definition zum großen Teil selber zu treiben, aber trotzdem würde ich immer davor warnen, dass ohne die IT zu versuchen.

Götz Müller: Ja, da kommt mir nachher noch ein Punkt, den ich auch gern besprechen würde.

Markus Starke: Genau, also da sollte man sicherlich ein Auge drauf haben, dass man nicht versucht, die IT dabei auszuschließen, aber diese starke Einbindung der Fachabteilung erlaubt manchmal sicherlich auch im mehr Skalierung als wenn man jetzt total von der IT abhängig wäre, weil häufig natürlich irgendwo die Ressourcen der IT auch begrenzt sind und die mit den Ideen der Fachabteilung manchmal zeitlich einfach mir hinterherkomm können. Was auch ein großer Vorteil ist, dass man, glaube ich, ganz pauschal sagen kann RPA ist relativ wenig invasiv auf die Systeme. Also man arbeitet prinzipiell auf der Nutzeroberfläche, das ist eine etwas pauschalisierte Aussage, aber man arbeitet tendenziell auf der Nutzeroberfläche, wodurch man wenig in irgendwelche Systemhintergründe rein muss. So konkrete Beispiele, was man da machen kann … so ein Beispiel finde ich auch von der Benennung immer ganz schön, das sind diese sogenannten Drehstuhlaufgaben, wo also von einem System oder einem Bildschirm auf den anderen Bildschirm einfach Daten übertragen werden. Zum Beispiel vielleicht auch Automatisierung in Alt-Systemen, in Legacy-Systemen, die man vielleicht mit anderen Methoden nicht mehr anfassen möchte. Oft wird RPA auch in Verbindung mit Scanning-Vorgängen und Optical Character Recognition genutzt, weil die Systeme damit ganz gut umgehen können, damit ganz gut integriert sind und ganz allgemein gesprochen halt alle Aufgaben, die halt Interaktion mit einer Reihe von verschiedenen Systeme erfordern, wo man sonst ein Konvolut aus Schnittstellen hätte.

Götz Müller: Gut.

Markus Starke: Wenn man jetzt noch mal an Voraussetzungen denkt, wie gesagt, da ist sicherlich Kernvoraussetzung für RPA, dass man über strukturierte Vorgänge und Daten spricht oder strukturierbare Daten, also zum Beispiel bei gescannten Dokumenten, das sind ja erstmal keine strukturierten Daten, die kann man dann aber ein Stück weit strukturieren, dass man relativ einfache Prozesslogiken und vor allem eindeutige Entscheidung hat, weil der Robot selber natürlich in dem Sinne keine Intelligenz hat, sondern der kann halt nur nach ganz klaren Vorgaben arbeiten. Auch ist es aus meiner Sicht, sage ich mal, nicht optimal zu versuchen mit RPA Prozesse abzubilden, die sehr, sehr viele Variationen haben, sondern das Ziel sollte sowieso vorher sein, diese Variationen auch mal zu reduzieren, aber wenn man es dann dennoch versuchen würde, würde das mit RPA auch sehr, sehr schnell sehr unübersichtlich werden, wenn man dann den gleichen Prozess mit X Varianten hat.

Götz Müller: Wenn es dann unter Umständen länger dauert, irgendwas zu automatisieren wie es halt dann doch selber zu machen als Mensch.

Markus Starke: Genau. Ganz ganz wichtig finde ich auch, dass man das weiter … dass sowohl vorher als auch nachher die Organisation halt selber die Prozesse auch noch versteht, wozu natürlich auch gehört, dass die ganze RPA-Implementierung und Definition halt auch vernünftig dokumentiert sein muss. Selber muss man auch nachher noch nachvollziehen können, was habe ich denn da eigentlich automatisiert, weil sonst hat man nachher das Problem, wenn dann irgendwas nicht mehr funktioniert, dann weiß man nicht mehr oder man aus anderen Gründen was anpassen muss, aus regulatorischen Gründen oder welchen anderen Gründen auch immer, dass man nicht weiß, wo muss man ansetzen.

Götz Müller: Ja, das ist genau der Punkt, der mir vorhin schon durch den Kopf schoss und vielleicht ist auch der richtige Zeitpunkt, das zu vertiefen. Da habe ich manchmal so das Gefühl, dass dieser Aspekt „Ich bastle mir da mal was mit Excel zurecht.“ natürlich jetzt unter Umständen sogar noch verstärkt wird, weil ich eventuell mehr Möglichkeiten habe und ich glaube, wir wissen beide was manchmal passiert, wir sind wahrscheinlich, also zumindest ich bin solchen Fällen schon begegnet, wo dann halt ein Meier-Sheet oder ja vielleicht auch mal Müller-Sheet oder so irgendwas existiert, dieser Meier oder Müller aber schon lange nicht mehr im Unternehmen ist, nur das Ding selber weiterlebt und jeder das Kreuz drüber schlägt, weil man das das nicht anfassen kann, weil man nicht weiß …

Markus Starke: Das ist eigentlich eine ganz schöne Analogie, genau. Also es gibt den … der Fall ist mir auch schon oft begegnet, dass man quasi irgendwelche Excel-Vorlagen hat, die irgendjemand irgendwann mal erstellt hat und nur diese Person noch weiß, wie die funktionieren und diese Person entweder das Unternehmen schon komplett verlassen hat oder einen komplett anderen Bereich arbeitet oder das Ding seit fünf Jahren nicht mehr angefasst hat, deswegen es selber auch nicht mehr weiß, wie das Excel-Sheet funktioniert und die Gefahr ist natürlich bei RPA genau die gleiche. Also da muss man natürlich dafür sorgen, dass es zu den Robots eine adäquate Dokumentation gibt und Begründung, warum die jetzt so und so arbeiten.

Götz Müller: Ja. Und das, was sie vorhin gesagt haben, nicht an der IT vorbei, das kann man im Grunde nicht genug betonen, weil spätestens in dem Augenblick, wo ich etwas an der Benutzeroberfläche mache und jetzt halt ein Entwickler an der Benutzeroberfläche ganz klassisch ein neues Release und vielleicht kommt dann noch ein weiterer Button dazu und dann verschiebt sich alles und dann tut es nicht mehr.

Markus Starke: Da können die RPA-Tools unterschiedlich gut damit umgehen, wenn sich da etwas ändert. Aber genau, die IT muss da mit an Bord sein, weil sie eben auch in den etwaigen Anpassung und Problemlösungen dann auf einmal benötigt wird und wenn die IT dann sagt „Ja, wir haben diesen Robot aber noch nie gesehen, dann wird natürlich der Einstieg dann ein Problem ist und mitzuwirken natürlich auch entsprechend herausfordernder. Also das macht es dann natürlich auch nicht einfacher.

Götz Müller: Jetzt hatten Sie es schon ein bisschen angedeutet, ich möchte es noch mal ein bisschen vertiefen, was die Wechselwirkung angeht, nach meinem Verständnis, mal mit meinen Worten ausgedrückt, wenn Process Mining funktioniert, weil ich Strukturen habe und so weiter, dann ist die Chance auch groß, dass ich darüber eine Ebene RPA legen kann. Mal als eine Wechselwirkung.

Markus Starke: Ja, genau. Es gibt diverse, also es gibt sicherlich Varianten, wie gesagt, wo man zum Beispiel auch die Erstellung von Eventlogs für Process Mining mit RPA unterstützt. Es gibt die Variante zu sagen, Process Mining kann helfen die notwendige Prozessanalyse für die RPA-Definition zu unterstützen, wobei man da immer dran denken muss, dass Process Mining und RPA sozusagen normalerweise auf unterschiedlichen Levels der Systeme agieren, also die RPA bewegt sich ja wie gesagt meistens auf der Benutzeroberfläche und Process Mining eigentlich eher auf den Aktivitäten, die sozusagen hinter der Nutzeroberfläche passieren, wodurch da kann ich keine ganz direkte Verbindung besteht. Eine Verbindung, die ich aber zum Beispiel ganz interessant finde, ist, wenn wir über RPA sprechen, da muss man sich auch immer über das Controlling der Robots Gedanken machen. Funktionieren die Robots, funktionieren die so wie sie sollen, gibt's da irgendwelche Performance-Schwierigkeiten etc.? Welche Robots werden viel genutzt und welche wenig genutzt, welche sind wirklich aktiv und welche sind weniger aktiv etc. und da kann es durchaus aus meiner Sicht … ich habe es noch nicht gesehen, aber da wäre es natürlich durchaus zum Beispiel auch attraktiv auch die Robotaktivitäten über Process Mining zu kontrollieren und da mal zuschauen „Okay, wie sieht das denn aus, also was machen die denn eigentlich?“, weil da verliert man schnell die Übersicht, was da eigentlich alles passiert.

Götz Müller: Im Vergleich zu dem realen Roboter, der dann halt doch irgendwo noch die Hupe eingebaut hat oder halt die Ampel an der Seite, die dann auf Rot schaltet und ich dann optisch sehe oder im Extremfall knallt es halt und ich höre es, dann weiß ich, was los ist. Wenn die Software nicht tut, merke ich es vielleicht gar nicht.

Markus Starke: Genau. Und die RPA-Tools, die meisten bringen natürlich irgendeine Form von Dashboard mit, welche Robots sind gerade aktiv, welche sind erfolgreich gelaufen, welche sind aus ähnlichen Gründen hängen geblieben, aber grundsätzlich wäre das sicherlich interessant, diese Analyse der Robots auch noch mal eine Ebene tiefer zu legen.

Götz Müller: Und vielleicht dann auch wieder einen Roboter draufzusetzen, der dann danach guckt, was dann die anderen machen, weil sonst wäre es ein bisschen absurd, wenn das jetzt ein Mensch überwacht.

Markus Starke: Da gibt es diverse Varianten, die da helfen können, also genau. Ich könnte mir auch vorstellen, ich habe es auch noch nicht real gesehen, aber dass tatsächlich zum Beispiel auch Ergebnisse aus dem Process Mining genutzt werden, um zum Beispiel Roboter-Aktionen einfach zu triggern. Wenn also das Process Mining irgendwo eine Abweichung vom Soll-Prozess darstellt, dass man dann sagt „Ok, da kann mithilfe von RPA irgendeine Gegenmaßnahme dann initiiert werden.

Götz Müller: Das kann ich mir auch gut vorstellen. Jetzt hatten wir gerade schon das Stichwort Mensch und Sie haben es am Anfang auch schon gesagt, dass es da eine nicht unerhebliche Wechselwirkung gibt. Was ist so Ihre Erfahrung, welche Rolle spielt der Mensch speziell, ich glaube bei manchen ist vielleicht auch noch ein gewisses rotes Tuch „Roboter? Werde ich ersetzt?“

Markus Starke: Also das ist natürlich eine ganz ganz kritische Frage. Also es gibt so ein paar Aspekte … Der Mensch ist natürlich erstmal Inputgeber und Know-how-Träger, also ganz klar. In den meisten Unternehmen steht das meiste Wissen darüber, wie Prozesse aussehen sollen und wie sie auszuführen sind, steckt letzten Endes bei den Menschen. Es ist immer mal wieder etwas niedergeschrieben, in verschiedenen Detaillevels und in verschiedener Qualität, aber am Ende sind die Menschen erstmal die Know-how-Träger und das wird sich auch so bald hoffentlich nicht ändern. Insofern spielt der Mensch einfach da initial mal eine Riesenrolle darin überhaupt RPA zu ermöglichen. Dann eben das, was wir gerade auch schon gesprochen haben. Natürlich müssen die Robots auch gemanagt werden. Auch das … dafür braucht es Menschen. Also sie müssen technisch umgesetzt werden, aber auch gemanagt werden. Auch da braucht es Menschen. Natürlich kann das auch wieder unterstützt werden, zum Beispiel durch Process Mining, aber am Ende müssen da auch Menschen mit ran und müssen auch Menschen dann noch mal entscheiden „Okay, der Robot ist noch aktuell, der macht seinen Job noch gut oder nicht und deswegen muss man den anpassen oder abschalten.“ Wie auch immer. Aber klar, die größte Frage, die immer wieder auftaucht, ist die kulturelle Akzeptanz der Robots. Sowohl auch in der Interaktion mit den Robot, dass man sagt „Ich vertraue dem Robot nicht, dass er seine Arbeit richtig macht.“, wo man sich da manchmal denkt, der Mensch macht seine Arbeit auch nicht immer richtig, aber gut, das kann ich trotzdem nachvollziehen, dass man da zumindest am Anfang gewisse Bedenken hat und überzeugt werden muss, dass der Robot hoffentlich seine Arbeit vernünftig macht, aber das ist auf der anderen Seite ist natürlich genau das diese Angst, dass alles, was mit Robotern zu tun hat, ob das jetzt eben Produktionsroboter sind oder eben Softwareroboter sind, natürlich immer mit dem Stichwort Stellenabbau verbunden ist. Habe ich bisher noch gar nicht so viel beobachtet, sondern … also, klar, macht man sich immer Gedanken darüber, was ist der Kostenvorteil, den man durch RPA vielleicht erreichen kann, aber auf der einen Seite … also der Kostenvorteil ist oft gar nicht so riesig groß, allein schon deswegen, weil man einerseits ja wirklich so eine total cost of ownership Betrachtung heranziehen muss, wo ja auch das Management der Roboter mit reinfließen muss und die Weiterentwicklung der Roboter etc., wo man auch sagen muss, ganz billig sind die RPA-Lösungen auch nicht. Aber auch, weil man ja häufig damit anfängt, Aktivitäten zu automatisieren, die aktuell in Ländern mit relativ niedrigen Grundstrukturen gemacht werden. Also häufig ist das ja quasi, ist die RPA-Welle die Welle nach dem Near- oder Offshoring und wenn man natürlich dann schon Lohnstrukturen hat, die ein dritte der Mitteleuropäischen Löhne hat, wird natürlich der cost case für RPA auch schon schwieriger. Ich halte es für essentiell, dass man bei RPA, aber auch bei jeder anderen Form von Prozessautomatisierung sich vor allem auch darüber Gedanken macht, kann man darüber die Zuverlässigkeit von Prozessen erhöhen, kann man die Gesamtqualität der Leistung verbessern oder kann man auch die Geschwindigkeit, mit der die Leistung erbracht wird, verbessern? Kann man Mitarbeiter von eintönigen, repetitiven Tätigkeiten befreien und dadurch Zeit freischaufeln, die auf anspruchsvollere Tätigkeiten verwendet werden kann und diese Tätigkeiten, die sonst vielleicht heute untergehen. Also das habe ich auch tatsächlich bei Kunden schon gesehen, die gesagt haben, das ist natürlich auch immer eine Frage der Kommunikation, aber die gesagt haben „Unsere RPA-Initiative zielt nicht darauf ab, Stellen abzubauen, sondern Arbeitskraft von den einfacheren Tätigkeiten auf die anspruchsvolleren Tätigkeiten zu verlagern, weil diese anspruchsvolleren Tätigkeiten im Moment zu kurz kommen.

Götz Müller: Ja. Total nachvollziehbar. Sie haben es gerade schon ein bisschen vielleicht auch unbewusst angedeutet, Fragen im Prinzip so zum Abschluss, die sich Unternehmen und die Entscheider in den Unternehmen stellen sollten, wenn sie über sowas wie Process Mining oder RPA nachdenken.

Markus Starke: Ja, genau. Das ist wirklich ein guter Punkt. Ich glaube, da tun sich viele Unternehmen auch noch schwer. Also ganz zentral finde ich, dass man die Technologie nicht zum Selbstzweck macht. Also gerade in den letzten drei Jahren oder so, als RPA auf einmal ganz populär wurde und auch Process Mining populär wurde, da haben die Unternehmen gerne gesagt „So wir machen jetzt ein RPA-Programm. Wir brauchen jetzt irgendwie ein RPA Center of Excellence auf und wir versuchen jetzt überall, wo es irgendwie geht RPA umzusetzen.“ Auf diese Art und Weise, glaube ich, führt das nicht immer zu den gewünschten Ergebnissen, sondern man sollte sich nicht primär darüber Gedanken machen, welche Technologie will man einführen, sondern darüber, was will man eigentlich erreichen. Deswegen, würde ich an der Stelle empfehlen, man sollte sich die Frage stellen: Wo wollen wir hin? Was sowas soll überhaupt erreicht werden? Was haben wir bereits an Fähigkeiten und Voraussetzungen rund um Prozessmanagement, Digitalisierungsaktivitäten, Big Data Fähigkeiten etc.? Was haben wir bereits im Unternehmen und was fehlt vielleicht noch, wenn man sich vielleicht mal so ein Ziel-Portfolio anschaut? Und dann zu überlegen „Okay, mit welchen Themen oder Prozessen müssen wir uns dann überhaupt priorisiert beschäftigen?“ Also worüber müssen wir uns Gedanken machen und was ist bei diesen Themen der Zielzustand?“ Und wenn man diesen Zielzustand definiert hat, dann muss man sich überlegen „Okay, welche Technologien aus diesem Baukasten kann man hier verwenden?“ Da würde ich dann ganz stark empfehlen auch immer mit, ich sag mal, mit kleinen Iterationen zu arbeiten, also da kommt dieses Stichwort minimum viable product dann auch ins Spiel, zu sagen, vielleicht wirklich auffällt erstmal ein proof of concept zu erarbeiten etc. und dann das Ganze erweitern. Was ich da in dem Zusammenhang total spannend finde ist dieses Stichwort Intelligent Process Automation, was quasi einen Schritt weiter geht, kann man sagen, was unter anderem von McKinsey stark geprägt wurde, das sagt: Okay, man rund um das Feld intelligentere Prozessautomatisierung als sie heute ist, man hat eine Anzahl von Technologien in dem Werkzeugkasten, die man halt kombinieren sollte. McKinsey hat gesagt, das ist Robotic Process Automation, das ist eine smarte, eine intelligente Workflow-Lösung, das ist das ganze Thema Machine Learning und Advanced Analytics, wo man zum Beispiel durchaus auch in den Block dann Process Mining einordnen könnte. Das ist das Thema Natural Language Processing und Generation, also darüber auch die Interaktion auch zu verbessern und das Thema Cognitive Agents, also wirklich auch eine virtuelle Workforce aufzubauen. Und ich glaube halt an diesem Werkzeugkasten-Gedanken. Ich glaube nicht, dass es darum geht solitär zu sagen RPA einzuführen, sondern ich glaube, es geht darum, zu sagen, wir müssen überlegen, was wollen wir eigentlich erreichen, was ist unser Zielzustand und welche Bausteine brauchen wir dafür.

Götz Müller: Ja, im Grunde, wenn man es ein bisschen bildlich ausdrückt, sich zu überlegen, warum will ich hier einen Nagel in die Wand schlagen und brauche vielleicht einen Hammer, weil ich ein schönes Ambiente habe, wenn da Bilder an der Wand hängen.

Markus Starke: Genau. Man überlegt sich nicht „Ich will den Nagel in die Wand schlagen.“, sondern man überlegt sich, man will das Bild oder die Uhr an der Wand haben und dann muss man sich überlegen: Mache ich das mit einem doppelseitigen Klebeband, einem Nagel oder einer Schraube? Genau, aber bei diesem Schritt oder Gedankengang tun sich die Unternehmen teilweise schwer. Ich würde natürlich auch immer sagen, das ganze prozessorientiert anzugehen, also immer wirklich sich an Prozessen zu orientieren zu überlegen, das ist ein Prozess, den wir optimieren wollen und das ist aber meine oder unsere Perspektive als Prozessberater und Prozessmanager, die die wir da halt tragen, wo ich aber auch überzeugt bin, dass sie eine relativ sinnvoll ist.

Götz Müller: Und da eben sich auch mal klar zu machen „Ok, was ist denn mein Problem? Also sprich, wo gefällt mir irgendetwas nicht, weil ich vielleicht, wieder bildlich gesprochen, einen Fleck an der Wand habe und den jetzt halt mit dem Bild zudecke und nicht zu sagen „Ich gehe jetzt in den nächsten Baumarkt und kaufe mir mal einen Hammer und ein paar Nägel.“

Markus Starke: Genau. Und das kann auch durchaus bedeuten, sich mit langfristigen Trends auch mal zu beschäftigen. Nicht nur zu überlegen, was ist jetzt unser Problem, dass vielleicht der Mitarbeiter A seine Arbeit anders macht als der Mitarbeiter B, sondern sich vielleicht auch mal zu überlegen, was können langfristige Herausforderungen sein. Auch wenn man sagt RPA zum Beispiel hat einen relativ kurzen und schnellen Umsetzungszyklus, sollte es nicht nur immer das Schließen eines Flickenteppich sein, sondern es sollte auch die Arbeit an einem langfristigen Ziel durchaus auch berücksichtigt werden.

Götz Müller: Ja, weil solche schnellen Schüsse dann oft ein unheimlich langes Leben haben. Okay, gut. Herr Starke, ich fand, das war eine spannende Unterhaltung. Ich habe da einige Parallelen gesehen zu Themen, die mich gerade beschäftigen. Deshalb danke ich Ihnen für Ihre Zeit.

Markus Starke: Sehr gerne. Ich bedanke mich auch einfach. Ich fand auch, das war ein gutes Gespräch und finde das Format auch toll und vielen Dank.

Götz Müller: Das war die heutige Episode im Gespräch mit Markus Starke zum Thema Process-Mining und Robotic-Process-Automation. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 191.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei iTunes. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder zu lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.

Hinweis: Ich behalte mir vor, Kommentare zu löschen, die beleidigend sind oder nicht zum Thema gehören.