Die fünf Erfolgsfaktoren in der Prozessautomatisierung

Erfahrungen aus der Beratungspraxis 

Drei Viertel der befragten Unternehmen in der TEC-Marktstudie 10/2021 nannten Effizienzsteigerung als wesentliches Ziel ihrer Automatisierungsbestrebungen. Zur Zielerreichung sind fünf wesentliche Erfolgsfaktoren für Automatisierungsprojekte entscheidend. 

In der TEC-Marktstudie 10/2021 von CGI und Böcker Ziemen kam heraus, dass 75% der befragten Telekommunikationsunternehmen Prozessautomatisierung mit dem Ziel der Effizienzsteigerung verfolgen. Kosteneinsparungen stehen bei den Befragten an zweiter Stelle. Allerdings erreichen laut unserer aktuellen Kundenumfrage „Voice of our Clients“ 80 Prozent der Unternehmen noch nicht die erwünschten Ergebnisse aus ihren Digitalisierungsvorhaben, was die Automatisierungen einschließt.  Deshalb widme ich mich in meinem Bog-Artikel der Fragestellung, wie Effizienzsteigerung mit Prozessautomatisierung gelingen kann und stütze mich auf die Erfahrungen unserer CGI Projekte aus der Praxis. Dabei werden nachfolgende Erfolgsfaktoren aktuell als besonders relevant bewertet:

Faktor 1: Change Management

Ein Automatisierungsprojekt ist eine organisatorische Veränderung im Unternehmen, keine primär technische. Dies bedeutet, dass zunächst durch die Veränderung bei den Mitarbeitern Widerstände aufgebaut werden. Dies ist ein ganz normales, menschliches Verhalten. Deshalb ist es unter anderem wichtig, dass das Management transparent den Mitarbeitern die Ziele, Potentiale, Auswirkungen und über den regelmäßigen Status kommuniziert. Die Dringlichkeit und Sinnhaftigkeit muss für alle Beteiligten erkennbar und somit auch erklärt werden. Außerdem sollte das Management bei Fragen der Mitarbeiter ein offenes Ohr haben. Zur Akzeptanzsicherstellung des Projektes lassen sich die Mitarbeiter auch aktiv einbeziehen, beispielsweise bei der Erarbeitung des fachlichen Prozesses und Optimierungspotentiale. Schließlich sind die Mitarbeiter geschätzte Experten im Unternehmen.

Faktor 2: Partnerschaftliche Zusammenarbeit zwischen Fachbereich und IT 

Leider lässt sich in den Unternehmen immer noch die „Kluft“ zwischen Fachbereich und IT erleben. Diese wird noch künstlich verstärkt durch die Einführung von Projektleitern auf Fachbereich- und IT-Seite. Dies ist kontraproduktiv, da sowohl Fachbereich und IT im selben Boot sitzen. Beide sind Bestandteil des Unternehmens und müssen die Geschäftsstrategie des Unternehmens umsetzen. Deshalb ist der Fachbereich als Experte für die fachlichen Prozesse und Anforderungen relevant und die IT als Experten zur konkreten Implementierung der fachlichen Prozesse. 

Bei der partnerschaftlichen Zusammenarbeit zwischen Business und IT unterstützen Standards wie die BPMN (Notation für Prozessmodellierung) und DMN (Notation zur Modellierung von operativen Entscheidungen). Diese unterstützen die präzise, graphische Beschreibung des fachlichen Prozesses und des Entscheidungsmodells für Fachbereich und IT. Die Präzisierung ist für die Automatisierung entscheidend. Hier sollte gelten, dass sämtliche Informationen zum fachlichen Prozess mithilfe der Modellierungsnotation BPMN beschrieben werden, sodass Fachbereich und IT über ein präzises Prozessmodell sprechen können. 

Faktor 3: Die Fachlichkeit steht im Vordergrund 

Der fachliche Prozess muss im Vordergrund stehen. Es braucht beim gesamten Unternehmen, einschließlich der IT, eine andere Denkweise. Hier kann die agile Vorgehensweise durch die Einführung eines Product Owners (PO) helfen, der Ansprechpartner für den Fachbereich und IT ist. Weitere Aufteilungen wie einen Business Analysten für die Anforderungen und einen für die „funktionale Analyse“ (Solution Designer) bedarf es dann nicht, da beide Funktionen in einer Rolle vereint sind. Dies erhöht durch konsequente Anwendung der Vorgehensweise und Veränderung des Mindset die Effizienz des Projektes. Auch bedeutet dies, dass die jeweiligen IT-Rolleninhaber ein anderes Verständnis aufweisen müssen und nicht nur reine Techniker sein dürfen. Selbst wenn der PO durch einen Mitarbeiter aus dem Fachbereich besetzt wird, sollte dieser über grundlegende IT-Expertise verfügen.

Faktor 4: Prozessdesign und (Prozess-)Architektur

Es ist enorm wichtig, auf Best Practices beim Prozessdesign zu achten. 
Dazu gehören - neben der syntaktisch korrekten Anwendung der Notationen BPMN und DMN - auch die Erstellung eines Modellierungsleitfadens, sodass mehrere Personen parallel und einheitlich fachliche Prozesse im Hinblick auf die Automatisierung beschreiben. So sind beispielsweise die Aufgaben in den Prozessen basierend auf fachlicher Bezeichnungen wie folgt zu benennen: „Objekt + Verb“ (Beispiel: „Kundenauftrag erfassen“).

Neben dem Prozessdesign ist die Systemarchitektur rund um die Prozessautomatisierung auf das jeweilige Unternehmen und den fachlichen und nichtfunktionalen Anforderungen abzustimmen. Als grundsätzliche Architekturziel ist die lose Kopplung der IT-Systeme, die Anpassung der fachlichen Prozesse und die Erweiterbarkeit zu nennen. Bei dem Schnittstellendesign ist auf die konsequente Ausrichtung der Fachlichkeit zu achten.

Aktuell ist die Microservice-Architektur sehr beliebt (Microservices sind im Kern auf einen einfachen fachlichen Zweck ausgerichtet, was einen unabhängigen Betrieb von anderen IT-Systemen und damit eine schnellere Reaktion auf Marktsituationen ermöglicht), sodass viele Unternehmen diese pauschal einsetzen wollen. Ein häufig beobachteter Fehler ist das falsche Schneiden der Microservices. Dadurch entstehen hohe Abhängigkeiten zu anderen IT-Komponenten.

Beispiel: Die Prozessdefinition in BPMN wird vom zentralen Workflow Management System verwaltet. Die Implementierung der Fachlogik in den Aufgaben des Prozesses werden über externe Implementierung realisiert. Im Extremfall wird die Implementierung jeder einzelnen Aufgabe als eigener Microservice verstanden und im abgeschwächten Fall wird die Implementierungslogik zum fachlichen Prozess aller Aufgaben als eigener Microservice verstanden. Eventuell geht mit diesem Ansatz auch der Irrglaube einher, dass ein Workflow Management System ausschließlich zentral sein muss. Dies erhöht die Abhängigkeiten zu den IT-Komponenten und reduziert nochmals Performance der Anwendung, die sowieso durch die Abhängigkeiten zwischen Microservices existieren (Netzwerkverkehr). Besser ist, wenn alle erforderlichen Komponenten zur Ausführung des fachlichen Prozesses in einem Microservice untergebracht werden. Das bedeutet, dass sowohl die Prozessdefinitionen, Implementierungslogik und auch das eingebettete Workflow Management System zusammen zum Microservice gehören. 
Des Weiteren sind im Kontext von Microservices Event-driven-Architekturen beliebt. Dabei senden Microservices bestimmte Informationen an das Messaging-System, die wiederum von anderen Microservices aufgegriffen werden können. Dadurch können Microservices lose gekoppelt miteinander kommunizieren. Dabei wird es besonders problematisch, wenn hohe inhaltliche Abhängigkeiten bei der Ausführung verschiedener Microservices untereinander entstehen. Diese können beispielsweise dadurch entstehen, wenn eine Reihenfolge von Events eingehalten werden müssen. Somit wird Fachlogik verborgen und es entsteht wiederum eine Art Monolith.

Faktor 5: Richtige Auswahl der Automatisierungstools

Viele Hersteller versprechen, dass sie die „Eierlegende Wollmilchsau“ für die Automatisierung der fachlichen Prozesse anbieten. Hierbei ist auf die richtigen Technologien zu setzen, um zukunftsfähige und schnell die fachlichen Prozesse zu digitalisieren. Die Realität sieht anders aus, zumal sich auch die Hersteller auf bestimmte Technologien beschränken. Der eine bietet beispielsweise ein Workflow Management System mit BPMN/DMN-Unterstützung an, ein anderer wiederum eine Backend-Automatisierungslösung mit Schwerpunkt Data Science-Features wie OCR, Textklassifikation und angewandte Machine Learning Modelle zur Rechnungserkennung. Auch bei den verschiedenen Herstellern von OCR-Komponenten ist Vorsicht geboten. So ist das eine Produkt besser in klassischer Texterkennung, während das andere auf Handschrifterkennung ausgerichtet ist.

Bei der Ausrichtung auf End2End-Prozessen ist es wichtig, dass die Prozessorchestrierung (d.h. Prozesskoordination) Workflow Management Systeme mit BPMN-Unterstützung verwendet. So sind die fachlichen Prozessbeschreibungen sehr nahe an der technischen Implementierung, um so die Prozesse schneller zu digitalisieren. So können Fachbereich und IT gemeinsam über das Prozessmodell und dessen Umsetzung kommunizieren. Dazu ist allerdings erforderlich, dass die Workflow Management-Systeme die BPMN im großen Umfang für die Modellierung und Implementierung unterstützen. Hingegen sind auch proprietäre Notationen in den Workflow-Management-Systemen von verschiedenen Herstellern auf dem Markt. Es gilt zu beachten, dass bei den meisten dieser Systeme nur die Abhängigkeit zum Hersteller vermutlich bezweckt wird. Die direkte Ausführung des fachlichen Prozesses ist meist nur sehr rudimentär graphisch möglich, sodass zur Präzisierung Eigenschaften konfiguriert werden müssen. So können auch Fachseite und IT-Seite nicht ausreichend über den fachlichen Prozess kommunizieren, da die Prozessdetails in verborgenen Eigenschaftsdialogen zu finden sind. 

Robotic Process Automation (RPA) wird oft eingesetzt, um die strukturierten und regelbasierten fachlichen Prozesse zu digitalisieren, die bisher vom Menschen erledigt worden. Es ist zu beachten, dass bei RPA ein anderer Detaillierungsgrad vorzufinden ist als bei der Prozessautomatisierung mit einem Workflow Management System. Damit ist auch klar, dass mit reinen RPA-Plattformen keine End2End-Prozessautomatisierung umgesetzt werden kann.
RPA wird meist auch als „Brückentechnologie“ eingesetzt, wenn ein IT System bisher keine API besitzt, über die das IT-System direkt angebunden werden kann. Dann wird mithilfe von RPA-Bots die graphische Benutzeroberfläche des IT-Systems genutzt. Dies ist allerdings kritisch, da sich diese abhängig vom IT-System oft verändern können und damit ein hoher Entwicklungsaufwand der RPA-Bots entsteht. Auch wenn die graphische Benutzeroberfläche sich nicht häufig verändert, stellt das Zusammenspiel des RPA-Bots im Kontext der End2End-Prozessausführung eine weitere Komplexität dar. Fehlersuchen sind nicht immer einfach, an welcher Stelle des End2End-Prozesses oder gar Bots der fachliche Prozess nicht korrekt ausgeführt wurde. Stattdessen sind fachlich-ausgerichtete Schnittstellen zu den jeweiligen IT-Systemen zu bevorzugen.

Auch Process Mining ist in aller Munde. Bei den jeweiligen Unternehmen wird sich viel versprochen durch Anwendung von Process Mining. Allerdings wird keine „Magie“ mit Process Mining möglich, auch wenn das Marketing der Hersteller dies suggerieren mag. Mithilfe von Process Mining lässt sich vereinfacht ausgedrückt ein Process-Reporting über einen fachlichen Prozess realisieren. Dabei werden die digitalen Spuren aus dem am fachlichen Prozess involvierten IT-Systemen (z.B. SAP, SalesForce,…) zu einer bestimmten Datenstruktur („Eventlog“) aufgearbeitet, sodass sich mittels dieser Struktur der fachliche Prozess erkennen lässt. Dies kann einen enormen Aufwand bedeuten, welcher sich auf die IST-Situation des operativen Prozesses fokussiert. Dabei hängt es sehr stark von der Datenqualität ab und es werden Fachexperten aus dem Prozesskontext benötigt, die die Interpretationen des Reportings vornehmen und bei der Aufbereitung der Daten mithelfen müssen. Bei der Prozessorchestrierung mittels Workflow Management System erhält man das Prozess-Reporting gleich mit, da der Prozess strukturiert vorliegt. Sowohl mit der Integration der eigenen Reporting-Tools oder der von dem Hersteller mitgelieferten Reporting-Tools lassen sich Prozess-Reports aufsetzen. Die Nutzung von spezifischen Process Mining-Tools macht zum aktuellen Zeitpunkt nur eingeschränkt Sinn. Ein Anwendungsfall könnte bei Einsatz von Standardanwendungssysteme sein. Ansonsten sollte der Fokus des Unternehmens auf der SOLL-Situation liegen.

Abschließend wird auf die Verbreitung sogenannter „Low Code“-Plattformen eingegangen. Diese sind sowohl unter den RPA-Plattformen als auch den Workflow Management-Systemen vorzufinden.
Ziel von "Low Code"-Plattformen sollte es sein, die schnellere Umsetzung von Applikationen zu ermöglichen und den IT-Fachkräftemangel zu begegnen. Letzteres soll dadurch erreicht werden, dass die Fachexperten ihre eigene Fachlogik direkt in Applikationen einbringen. Andererseits können Quereinsteiger als Entwickler aus anderen Gebieten schneller in die Programmierung von Applikationen einsteigen. 
Durch die Befähigungen des Fachbereichs zur Umsetzung der eigenen Fachlogik in Prozessapplikationen bedarf es weiterhin die IT. Denn es handelt sich immer noch um Softwareentwicklung. Allerdings sollte die Rolle der IT anders verstanden werden: als „Enabler“ des Business. Dazu bedarf es in der IT – neben technische Spezialisten – auch Vermittlerrollen zwischen Business und IT mit „Hands-on“-Mentalität. 
"Low Code"-Plattformen müssen noch nicht per Definition herstellerabhängig und unflexibel sein. So bedarf es für allgemeine Tätigkeiten Bausteine, aber auch genug Flexibilität um weiterhin programmieren zu können, um beispielsweise Datentransformationen vorzunehmen. Auch die Unterstützung von Standards ist wichtig, um den fachlichen Prozess graphisch und präzise für Business und IT abzubilden. Zudem ist die Testunterstützung der Applikation entscheidend.
Aktuell werden von den Herstellern von „Low Code“-Plattformen der „Low Code“-Begriff unterschiedlich interpretiert. Dies ist nicht verwunderlich, da dieser kein standardisierter Begriff ist. Letztendlich liegt es an jedem Entscheidenden, welche Plattformen/Systeme bei der Erreichung der Geschäftsziele des Unternehmens unterstützen können. Hierbei kann ein erfahrener Dienstleister bei der Auswahl der zielführenden IT-Systeme für die Lösung unterstützen.

Fazit

Zur Erreichung der nachhaltigen Effizienzsteigerung mithilfe der Prozessautomatisierung muss also einiges beachtet werden. Insbesondere die beiden Faktoren „Change Management“ und „Prozessdesign und (Prozess-)Architektur“ sind hervorzuheben. Mit dem ersten Faktor wird als Querschnittsdisziplin sichergestellt, dass die Mitarbeitenden, als wertvolle operative Experten des Unternehmens, die Wichtigkeit der Veränderung verstehen lernen und unterstützen. Mit dem zweiten Faktor wird adressiert, wie die Prozessautomatisierung im Unternehmen aufgesetzt wird. Die Auswahl der richtigen Technologie folgt auf die zielführende Auswahl der Architektur auf Basis der fachlichen und nichtfunktionalen Anforderungen. Ratsam ist es aber immer, sich Unterstützung durch einen erfahrenen und partnerschaftlichen Dienstleister zu holen.