Wiederkehrende Tätigkeiten kosten Zeit, Geld und oftmals auch Nerven. Industrie und Servicegesellschaften haben schon vor längerer Zeit erkannt, dass es sinnvoll sein kann, diese von Softwarerobotern ausführen zu lassen. Zunehmend setzen auch Banken und Versicherungen auf die robotergesteuerte Prozessautomatisierung, kurz RPA. In welchen Fällen sich RPA besonders lohnt, lässt sich sehr gut mit Process Mining identifizieren. Doch gehören Process Mining und RPA immer zusammen, oder funktioniert auch das eine ohne das andere? Die Ansichten darüber gehen auseinander.

"Für die Automatisierung via RPA kann Process Mining hilfreich sein, ist aber nicht zwingend vorausgesetzt. Effizienzpotenziale in Prozessen lassen sich auch über andere Verfahren strukturiert identifizieren, und eine schnelle RPA schafft einen direkten ROI. Für Process Mining gilt dies nicht. Ich verschaffe mir via Process Mining zwar Transparenz über meine Prozesse, die Transparenz allein sorgt aber noch nicht für einen ROI. Zur Realisierung brauche ich nachgelagerte Aktivitäten wie zum Beispiel RPA", erklärt Tobias Beuckes von Horváth & Partners.

Dass es neben RPA als Folgeschritt auch andere Möglichkeiten gibt, begründet Constantin Wehmschulte von Mehrwerk damit, dass sich Process Mining auch dafür eignet, herauszufinden, "wie beispielsweise die Entwicklung der Qualitätsrate in der Produktion mit den zugehörigen Fertigungsprozessen zusammenhängt. Da geht es um Verbesserungen, für die auch an anderen Stellschrauben gedreht werden kann."

Anwendungen für RPA, die nicht unbedingt die Notwendigkeit von Process Mining erfordern, sehen beide in Fällen, bei denen die Charakteristika auf der Hand liegen. Ein Beispiel von Wehmschulte: "Wenn ich die Kundennummer vom linken ins rechte CRM kopiere und dann auf Speichern drücke, erkenne ich das Automatisierungspotenzial auch ohne Process Mining."

Ob man beides auf einmal braucht, ist für Milad Safar, Weissenberg Group, eine Frage der Kultur und des Budgets. Wie viel ist das Unternehmen bereit zu investieren, um hinterher einen Erfolg zu haben? "Wie viel Vorarbeit möchte ich machen, und will ich dann noch ein IT-Projekt aufsetzen? Wenn man das als Entscheider beantwortet hat, dann fällt es einem auch leichter zu sehen, ob das jetzt zusammenhängt oder zwei Themen sind. Generell lässt sich mit Process Mining der Ausgangspunkt aller Automatisierung leichter bestimmen, ohne den man später den Erfolg nicht messen kann."

Informationen zu Partner-Paketen der Studie "Process Mining und RPA" finden Sie hier

Ganz klar zusammen gehören die Technologien hingegen für Tobias Rother von Process Analytics Factory. Seine Erklärung: "Die Kunden fordern von uns, am Ende des Tages schlauer und besser zu werden. Mit Process Mining wird man als Kunde in der Regel schlauer, macht man Robotik, wird man besser. Macht man beides, wird man schneller besser!" Für Roman Schäfer von Reply haben beide ihre Daseinsberechtigung, und er bringt die Diskussion um richtig oder falsch, vorher oder nachher damit auf den Punkt, dass deren Einsatz situativ zu beurteilen ist. Und dazu gehört auch, ob der Impuls dazu nun aus dem Fachbereich oder der IT-Abteilung kommt.

Ein Tool nicht nur für den Fachbereich

Ob nun die Notwendigkeit einer Prozessoptimierung vom Fachbereich ausgeht oder die IT Prozesse revolutionieren will, um dem Business etwas anzubieten - Process Mining ist immer ein Gemeinschaftsprojekt, welches das Know-how der einen und die Systeme der anderen Abteilung benötigt. Ein Miteinander ist für Walter Obermeier von UIPath auch die Automatisierung, macht hier aber einen Unterschied: "Bei der durchgehenden End-to-End-Prozessautomatisierung nehme ich dem Mitarbeiter den gesamten Prozess weg. Dazu braucht die IT in der Umsetzung das Prozessverständnis des Fachbereiches. Ein weiterer Punkt sind die vom User getriggerten Automatisierungen, wo ich nur teilautomatisiere. Man darf den Nutzer aber dabei nicht allein lassen, da muss eine global Governance dahinterstecken."

Zudem müsse auch das Volumen betrachtet werden: Braucht es die IT dazu, wird es ein größeres Projekt. "Kommt aber eine Fachabteilung, die für 20 User schnell eine agile Lösung benötigt, wäre RPA eine solche, für die die IT sonst schlichtweg keine Zeit hat", so Obermeier über die Theorie. Die Praxis von RPA sieht meist anders aus: Wenn automatisieren, dann richtig. Reply-Manager Schäfer spürt diese Gegenwehr vorrangig in den IT-Bereichen, die den eigenen Nutzen, also dass RPA-Technologien auch für sie ein Entwicklungswerkzeug sind, noch nicht richtig erkannt haben. Reagiert die IT also nicht schnell genug, sucht der Fachbereich selbst nach Lösungen - und erzeugt damit eine Schatten-IT, welche die IT-Abteilung eigentlich vermeiden will. Dabei ist mit RPA auf Basis der eigenen Kern-IT genau das möglich. "Man muss aber im Kopf behalten, dass RPA keine IT ersetzt", so der Hinweis von Obermeier.

Auch Weissenberg-Mann Safar weiß, dass RPA nicht nur für den Fachbereich da ist, sondern auch für die IT. "Im ersten Schritt ist die IT oftmals zwar ein Bremser, kann aber hinterher, wenn gute Proof of Concepts durchgelaufen sind, auch als Beschleuniger gelten - nämlich dann, wenn sie erkennt, dass sie mit RPA kein Tool, sondern eine Plattform in Einsatz hat, mit der sie dem Fachbereich den Service anbieten kann, schnell zu automatisieren. Dann begreift die IT auch relativ schnell, dass sie eine stabile IT-Plattform braucht, Services, einen First-, Second- und Third Level Support und jemanden, der als Key User mit dem Fachbereich sprechen kann." Wer das verstanden hat, kann eine Plattform schaffen, von der aus man Bots abrufen und an die Fachabteilungen verteilen kann.

Struktur macht zufrieden

Den Fachbereich noch vor der IT von dem Mehrwert von RPA zu überzeugen hat noch einen weiteren Vorteil: Ist es keine Top-down-Entscheidung, sondern eine vom Fachbereich getriebene, ist die Akzeptanz für diese Technologie viel höher. Selbst wenn sich herausstellt, dass ein Prozess eigentlich nicht so abläuft, wie er seit Jahren ausgeführt wird. "Das ist das Charmanteste an RPA: dass ich endlich Harmonisierungsaktivitäten stringent umsetzen kann, der Bot folgt strikt den Standards, die gemeinsam gesetzt werden", sagt Beuckes über die Möglichkeit der Prozessstrukturierung.

Auch Jannis Eißen von Capgemini merkt immer wieder, "dass die Leute in einem strukturierten Prozess arbeiten wollen. Kein Bürokratie-Monster, sondern ein schlanker, strukturierter Prozess, bei dem die Mitarbeiter wissen, wofür sie zuständig sind." Laufen Prozesse chaotisch ab, kann das für ihn auch ein Grund für Fluktuation sein.

Auch Workarounds, denen die Mitarbeiter folgen müssen, weil "schlank" noch nicht geht, führen laut Obermeier zu Unzufriedenheit. Ebenso die Tatsache, dass viele Unternehmen heute um qualifizierte Mitarbeiter kämpfen und sie dann stumpfe und langweile Prozesse ausführen lassen. "Ein promovierter Wirtschaftsinformatiker, der jeden Tag Autos zählt, das haben wir auch schon mal erlebt", nennt Wehmschulte ein Beispiel dafür.

Informationen zu Partner-Paketen der Studie "Process Mining und RPA" finden Sie hier

Was passiert, wenn man dem Mitarbeiter nun ein Tool an die Hand gibt, mit dem er solche Prozesse automatisieren kann, und ihm dann auch noch vorschlägt, sich selbst Gedanken zu Verbesserungen zu machen, weiß Obermeier ebenfalls: "Der Mitarbeiter weiß am besten, was ihn nervt und wo er die meiste Zeit verliert. Wer da genau zuhört, kann dann mit einem schlanken RPA-Tool schnell umsetzen und auch in der IT punkten."

RPA ist kein Allheilmittel

Es kommt aber auch vor, dass es nicht funktioniert. Zum Beispiel dann, wenn der Fachbereich etwas automatisieren möchte, ohne sich Gedanken gemacht zu haben, oder der Prozess nicht ausreichend analysiert wurde. Ein Mehrwert durch RPA entsteht ebenfalls nicht, wenn kein Sinn dahintersteckt - beispielsweise wenn bekannt ist, dass der Prozess mit dem nächsten Software-Release in zwei Jahren sowieso angepasst wird. Ein weiterer Grund zum Scheitern: Es wird nur der Happy Path definiert. Tobias Beuckes: "Zu überlegen, wie der Prozess im Idealfall aussehen sollte, ist keine hohe Kunst. Wir müssen schauen, wie der Prozess im Fachbereich gelebt wird und wo es Ausnahmen vom Happy Path gibt, die ich mit abbilden und automatisieren muss." Müssten diese Ausnahmen wieder an den Fachbereichsmitarbeiter zurückgeben werden, ergibt die Automatisierung für ihn weder einen Sinn, noch erreicht man damit das Volumen, bei dem es sich lohnt.

"RPA ist kein Allheilmittel", betont Beuckes und klärt über die Technologie auf, die eben nur bis zu einem gewissen Punkt sinnvoll ist. Wer zu 100 Prozent automatisieren will, kann laut Safar auch eine Schnittstelle programmieren: "Und das ist der Unterschied, denn ich möchte bei RPA nicht immer 100 Prozent automatisieren, weil ich es dadurch aufblähe." Für ihn sind die idealen RPA-Prozesse die, die sich innerhalb von sechs bis acht Wochen entwickeln lassen. Es darf aber nicht verpasst werden, innerhalb der Entwicklung des Projektes, also auch im Code selbst, Messkriterien einzubauen, um darüber während der Entwicklung zu sprechen. "Ansonsten muss ich am Ende wieder um Akzeptanz kämpfen", so Safar.

Im Markt ist noch viel Luft nach oben

Und wie sieht es aktuell mit der Akzeptanz von RPA und Process Mining im Markt aus? Bewegte man sich vor vier Jahren primär noch im Proof-of-Concepts-Bereich, setzen große Unternehmen und der Mittelstand RPA bereits flächendeckend, aber in unterschiedlichen Ausprägungen ein. Vor allem Servicegesellschaften, die bereits Prozesse aus den Bereichen HR, IT und Finance übernommen haben, erkennen seit einiger Zeit, dass ihnen RPA ein enormes Wachstumspotenzial beschert.

Hat ein Servicecenter automatisiert, kann es seine Services zum einen wettbewerbsfähiger anbieten. Zum anderen verfügt ein SSC über Prozess-Know-how aus den verschiedensten Bereichen, das es sich nicht nur für Serviceerweiterungen zunutze machen, sondern mit dem er sich auch zum Service Center of Excellence entwickeln kann. "Ein Servicecenter, das schon End-to-End-Prozess-Verständnis hat, ist eher dazu geeignet, die Prozesse zu schreiben, als die IT", ist sich Obermeier sicher.

Der Markt für Process Mining entwickelt sich aufgrund einer anderen Ausgangslage laut Rother ganz anders, denn es adressiert hauptsächlich den Fachbereich und Beratungshäuser. Zudem ist es ein stark SAP-orientiertes, europäisches Phänomen, vorrangig Benelux und D-A-CH, in dem dadurch noch extrem viel Wachstumspotenzial steckt. Dass die tool-basierte Methode bei beiden Zielgruppen ein Projektbeschleuniger ist, erkennt man allmählich auch in Asien und in den USA.