BPM-Lösung: Fünf entscheidende Punkte für eine erfolgreiche BPM-Einführung
Der digitale Wandel ist im vollen Gange und viele Unternehmen stehen vor der Herausforderung, diesen im eigenen Haus umzusetzen, zumindest aber zu begleiten. Sehr oft wird im Rahmen der digitalen Transformation ein Projekt zur Abbildung von Prozessen in einer BPM- bzw. Workflowlösung initiiert. An und für sich ist das ein sehr guter Ansatz mit hohem Optimierungspotenzial bezüglich der internen Prozesse und deren Laufzeit sowie Datenqualität. Doch auf welche Fallstricke und Stolperfallen man bei der Einführung solch einer Lösung achten sollte, ist vielen Unternehmen nicht bewusst.
Lesen Sie nachfolgend die fünf wichtigsten Aspekte, die Sie bei der Einführung einer BPM-Lösung beachten sollten.
Auswahl einer geeigneten Softwarelösung
Nach der Entscheidung, ob man eine BPM-Lösung im eigenen Rechenzentrum betreiben will oder den Service aus der Cloud bezieht, schließt sich häufig die Frage an, was man für Anforderungen an die Software hat und welche Anbieter diese bedienen können.
Viele Anforderungen sind dabei sehr individuell auf das Unternehmen zugeschnitten. Dennoch muss der Prozess in jedem Fall modelliert werden. Hier geht momentan kein Weg an der Business Process Model and Notation (BPMN) vorbei. Dieser Standard hat sich durchgesetzt und wird von vielen Systemen unterstützt. Entscheidend ist, dass die BPM-Lösung mit Veränderungen im Prozessmodell umgehen kann. Hat man beispielsweise in Version 1 eines Prozesses einen Task mit dem Namen „Antrag durch Assistenz genehmigen“ und wird dieser in Version 2 auf Grund einer Prozessoptimierung entfernt, so muss die Workflow-Engine in der Lage sein, bereits bestehende Prozessinstanzen im entsprechenden Task zu verarbeiten. Eine Behandlung kann je nach Anforderung in eine unterschiedliche Migrationsrichtlinie münden. Entweder lässt man alte Instanzen in der Version zum Ende laufen, in der sie gestartet worden, man löscht sie oder aber man migriert diese. Bei der Migration einzelner Instanzen und deren Tasks muss angegeben werden, welche Task folgen soll.
Eine Anforderung, die fast immer aus Qualitätssicherungsgründen besteht, ist die Notwendigkeit neben dem Produktivsystem noch ein Test- und Qualitätssicherungssystem in die gesamte Architektur aufzunehmen. Im Idealfall wird eine Prozessversion mittels eines Snapshots gesichert und in das Q-System übertragen. Erst nach Test und Freigabe der jeweiligen Version durch den Process Owner, wird diese in das Produktivsystem übertragen.
Ein weiteres wichtiges Kriterium ist, ob und wie das System mit Software Release Updates umgeht. Besteht die Möglichkeit, immer ein InPlace Update zu fahren, sodass alle Prozesse und deren Instanzen automatisch auf die neue Softwareversion aktualisiert werden oder unterstützt das System den Aufbau eines föderativen Ansatzes, wo das alte System parallel zum neuen System betrieben wird. Alte Versionen können nahtlos über eine Schnittstelle in die Umgebung des neuen Releases integriert werden, sodass der Endanwender letztendlich nicht merkt, auf welcher Softwareversion seine Prozessinstanz gerade ausgeführt wird. In solch einem side-by-side-Verfahren wird die alte Version erst dann abgeschaltet, wenn keine offenen Prozessinstanzen mehr aktiv sind.
Integration von Umsystemen wie ERP, CRM, Datenbanken
Jede Prozessautomatisierung beinhaltet die Integration von Umsystemen. Soll die Automatisierung doch die Lücken und Medienbrüche zwischen den Datensilos, Mitarbeitern und bereits etablierten Softwarelösungen schließen.
Ein möglicher Ansatz besteht darin, diese Integrationsaufgaben in einzelne Tasks bzw. Services des zu entwickelnden Prozesses zu integrieren. Für die Entwicklung des ersten Prozesses auf solch einer Workflow Engine mag dies noch problemlos funktionieren. Aber bereits bei der Integration des SAP in einen zweiten Workflow kommt die Frage auf, warum dieser Service erneut entwickelt werden muss. Mit copy&paste kommt man hier noch relativ schnell zum Ziel. Spätestens beim ersten Change bzw. der ersten Erweiterung der SAP-Lösung wird es kompliziert und umfangreiche Änderungen in jedem Prozess werden notwendig. Schnell kommen die Berater und technischen Betreuer zusammen und fragen, wo die SAP-Schnittstelle in der Prozessumgebung überall verwendet wird.
Eine mögliche Lösung ist das Arbeiten mit Bibliotheken oder auch Toolkits. Hier werden alle Zugriffsfunktionalitäten entwickelt und versioniert ablegt. Jeder Prozess nutzt genau eine spezifische Version solch einer Schnittstellenbibliothek. Wird es auf Grund von Fehlerbehebung in der Schnittstelle notwendig, mehrere parallele Schnittstellenzugriffsmethoden einzubinden, ist es von Vorteil, wenn die Workflow Engine das Erstellen von Tracks zulässt, also parallelen Entwicklungspfaden.
Zusätzlich zu diesen Schnittstellen bietet sich die Entwicklung einer administrative Oberfläche an, die es ermöglicht, die Schnittstellenfunktionen einzeln zu testen.
Umgang mit Dokumenten innerhalb der abgebildeten Prozesse
Fast jede Workflow Engine bringt die Möglichkeit mit, Dokumente (Attachments) zu transportieren. Über geeignete User Interfaces können diese sehr komfortabel per Drag&Drop an der jeweiligen Prozessinstanz angehängt werden und stehen damit allen folgenden Bearbeitern zur Verfügung. Auch die Versionierung und der lesende Zugriff auf Vorgängerversionen von Attachments stellt keine allzu große Herausforderung dar.
Die deutlich größere Herausforderung besteht darin, wie die Dokumente im Prozesskontext abgelegt werden. Speichert man sie direkt in der Engine, werden die Daten als BLOB in eine Datenbanktabelle geschrieben. In solch einem Fall ist die Bereinigung der Workflow Engine wie unter Punkt [4] beschrieben sehr empfehlenswert. Ignoriert man das, können in 10 Jahren Betriebszeit Prozessdaten mit mehr als 70GB Speicherplatz angesammelt werden. Wobei die Dokumente hier mehr als 80% der Daten ausmachen.
Hat man in der Prozessanalyse erkannt, dass der zu automatisierende Prozess viele Attachments besitzen wird, empfiehlt sich der Einsatz eines abgesetzten Dokumenten Management Systems (DMS). Viele DMS und BPM Softwarehersteller unterstützen dabei den Content Management Interoperability Services (CMIS) Standard [1], welcher zum Austausch der Daten genutzt wird. Der große Vorteil besteht dabei, dass die Workflow Engine in der Speichernutzung schlank gehalten wird und dass man nach Beendigung eines Prozesses sich nicht um die revisionssichere Ablage der transportierten Dokumente kümmern muss.
Archivierung und Auswertung von Prozessdaten
Ohne Kennzahlen wird ein strategisches Prozessmanagement zu einer sehr großen Herausforderung und schwer umsetzbar. Zusätzlich unterliegen viele Prozessdaten gesetzlichen Aufbewahrungsfristen. Beide Punkte können von einer Workflow Engine abgebildet werden. In Übersichten zu Lauf- und Wartezeiten können genaue Aussagen darüber geben werden, ob der Automatisierungsgrad gut eingestellt ist oder ob es in einer Abteilung einen Ressourcenengpass gibt. Zusätzlich kümmern sich die meisten Systeme eigenständig um die Erfassung und Speicherung von Prozessdaten.
Wozu benötigt man dennoch eine dedizierte Archivierungslösung von Prozessdaten?
1) Die erfassten Daten einer Instanz werden auf unterschiedlichste Art und Weise in einer Workflow Engine gespeichert. Pro Prozess kann das eine Tabelle auf einem Datenbanksystem sein. Es ist auch möglich, dass alle Prozessdaten in einer eigenen Struktur in ein und derselben Datenbank-Tabelle gespeichert werden.
Um eine Analyse und Reporting der Prozessdaten und Kennzahlen auch abteilungsübergreifend zu ermöglichen, ist es sinnvoll ein abgeschlossenes Data Warehouse (DWH) als Datenquelle anbieten zu können. Hier besteht die Möglichkeit eine definierte Datenstruktur aufzubauen, welche von der Workflow Engine befüllt wird. Außerdem entkoppelt man das Risiko, dass die Engine auf Grund von suboptimalen Auswertungen und Analysen in ihrer Aufgabe behindert wird.
2) Wenn eine Prozessinstanz beendet wurde, liegen alle Prozessdaten in der Speicherstruktur der Workflow Engine. Ist man an gesetzliche Aufbewahrungsfristen gebunden, wandelt sich diese Engine mit der Zeit zu einem System of Records (SoR). Dafür sind die wenigsten Automatisierungslösungen ausgelegt. Werden viele Daten innerhalb eines Prozesses transportiert und hat dieser zusätzlich eine hohe Instanzdichte pro Jahr, wird man sich unweigerlich mit Performancethemen beschäftigen müssen. Die deutlich bessere Strategie besteht darin, die Prozessdaten nach Abschluss einer Instanz in ein separates SoR bzw. DWH auszulagern. Die Workflow Engine bleibt dadurch schlank und performant.
Überwachung des Zustandes der BPM-Engine
Betreibt man als betriebsverantwortliche Abteilung eine Workflow Engine im eigenen Rechenzentrum, hat man es unweigerlich mit IT-Themen zu tun. Da IT auf Grund von Störungen, Überlastungen oder Fehlern ausfallen kann, sollte diese überwacht werden. Neben dem Monitoring der IT-Komponenten einer Automatisierungslösung ist die Überwachung der Workflow Engine auf Software-Ebene wichtig. Dies betrifft beispielsweise die Kennzahlen für offene Web-Sessions, offene Datenbank Connections, Speicher- und CPU-Auslastung der Engine bis hin zu prozessspezifischen Kenngrößen, die Aussage über den Inhalt und Ablauf der Prozessinstanzen geben können.
Hat man all diese Messwerte im Blick und damit den prozesstechnischen Blindflug beendet, wird der Betrieb einer Workflow Engine zu einem kontrolliertem Vorgang, der die geschäftskritischen Prozesse des Unternehmens ideal unterstützt.
Die Klärung von Betriebsfrage, Betriebsverantwortung, Betriebssicherheit und wer den fachlichen Betrieb leisten kann, lesen Sie in einem weiteren Artikel.
Weiterführender Link:
[1] CMIS Standard: http://docs.oasis-open.org/cmis/CMIS/v1.1/os/CMIS-v1.1-os.html
Weiterführende Informationen:
Prozessautomatisierung Prozessdokumentation
Bildquelle/Copyright: © iStock.com/ismagilov
