BUSINESS PROCESS MODELING: Bindeglied zwischen IT und operativem Management?

Bei der Modellierung von Geschäftsprozessen liegt die größte Herausforderung darin, die unterschiedlichen Blickwinkel von IT-Fachleuten und operativem Management miteinander zu vereinbaren. Eine gute Modellierungs-Software muss Ergebnisse liefern, die beide Seiten verstehen – und mit denen sie auch arbeiten können.

Wer über (Business) Process Modeling spricht, lernt schnell, dass Business und IT den Begriff „(Geschäfts-) Prozess“ von ganz unterschiedlichen Betrachtungswinkeln sehen. Hier liegt ein Grundproblem, das sich später oft störend auf die praktische Umsetzung von Business Process Modeling-Projekten, zum Beispiel die prozessorientierte Einführung einer Workflow-Lösung oder eines BPMS (Business Process Management System), auswirkt. Die Managementebene sieht im Geschäftsprozess meist eine Abfolge von organisatorischen Schritten, die zu einemgewünschten Ergebnis führen soll. Welche IT-Anwendungen dabei zum Einsatz kommen, insbesondere aber wie diese miteinander in Verbindung stehen und funktionieren, ist für den Aufgabenbereich des kaufmännisch denkenden Managers wenig entscheidend.

Verständigungsprobleme
Ganz anders der IT-Spezialist, der letztendlich dafür sorgen soll, dass die Geschäftsprozesse mit einer wirksamen und leistungsfähigen Software unterstützt werden. Technisch können bereits heute viele Modellierungslösungen Daten an Workflow oder BPM-Systeme (BPMS) übergeben. Ein gängiger Weg ist beispielsweise aus einem Prozessmodell BPEL-Code (Business Process Execution Language) zu generieren. Für funktionierenden BPEL-Code reichen jedoch die aus dem Management gelieferten Informationen meist nicht aus. Andererseits hat die IT-Abteilung nur selten Einblick in die organisatorischen Prozesse des gesamten Unternehmens. Die bisherigen Ansätze aus der IT-Welt, wo mit Formaten wie UML (Unified Modeling Language) bereits modelliert wird, haben einen Pferdefuß: Es handelt sich um „Sprachen“ von Softwareentwicklern für Softwareentwickler. Das macht sie zu einem hervorragenden Kommunikationswerkzeug in der IT-Welt. In anderen Bereichen wie der Modellierung von Geschäftsprozessen stoßen sie dagegen schnell an ihre Grenzen. Das erste Problem ist die Notation. Sie ist teilweise so spezifisch, dass sie außerhalb der IT-Welt nicht verstanden wird. Die zweite, schwerwiegendere Problematik besteht darin, dass viele Bereiche, die für Unternehmen interessant sind, in der Softwareentwicklung schlichtweg nicht vorkommen. Bei der Modellierung von Geschäftsprozessen spielt die IT nur eine untergeordnete Rolle. Hier geht es viel häufiger darum, die Effizienz bestimmter Abläufe zu evaluieren, Änderungen in Wertschöpfungsketten zu simulieren oder eine Risikoanalyse zu erstellen. Da diese Anforderungen beim Softwaredesign keine Rolle spielen, können rein IT-orientierte Sprachen sie nicht erfüllen. Hier müssen andere Lösungen der Darstellung gefunden werden. Der Hauptgrund für die Probleme bei solchen Projekten liegt also oft schlicht und ergreifend daran, dass die Beteiligten unterschiedlich denken und es schwer haben, in ihrer gewohnten Fachsprache erfolgreich miteinander zu kommunizieren – genau das wird aber heute von ihnen erwartet.

Gesucht: Eine gemeinsame Sprache

Die Aufgabe einer Modellierungs-Software besteht in erster Linie darin, eine Brücke zwischen diesen unterschiedlichen Anforderungen und Denkweisen zu schlagen. In der IT existieren bereits standardisierte Modelle, um Services, Abläufe und Zusammenhänge zu beschreiben und grafisch darzustellen. Im Management gibt es dagegen verschiedenste Modellierungstechniken. Nach wie vor wird in rein organisationsorientierten Projekten klassisch mit Brownpaper oder Kartentechnik gearbeitet, wie etwa im Six Sigma. Daneben haben verschiedene Modellierungssprachen, zum Beispiel ereignisgesteuerte Prozessketten oder Flussdiagramme, Verbreitung gefunden. Oft fehlt es aber an der allgemeinen Akzeptanz dieser Darstellungsformen im Fachbereich oder es mangelt an der Weiterverwendbarkeit für IT-Implementierungen. Insgesamt gibt es keine gemeinsame Norm, die sowohl den Anforderungen des Business als auch der IT genügt. Jeder beschreibt Prozesse so, dass seine Kollegen es verstehen, folgt dabei aber keiner allgemeingültigen beziehungsweise für beide Seiten geeigneten Notation. Benötigt wird also ein Standard, der detailliert genug ist, um den IT-spezifischen Anforderungen gerecht zu werden und gleichzeitig die vergleichsweise „groben“ Prozesse der Wirtschaftswelt nach deren Belangen verständlich abbilden kann. Dieser Standard muss eine Vielzahl von Kriterien erfüllen: Eine allgemeinverständliche Notation Es gilt der Leitsatz: Ein gutes Diagramm sagt mehr als tausendWorte. Gut ist ein Diagramm aber nur dann, wenn alle Beteiligten seinen Inhalt schnell und einfach erfassen können und wenn das Diagrammden jeweiligen Kontext (z.B. Business vs. IT) berücksichtigt. Die grafische Darstellung der Prozesse und Zusammenhänge ist also ein entscheidendes Erfolgskriterium für eine gemeinsame BPM-Sprache.

Ein klar definiertes Metamodell und Vokabular
Auch Programmiersprachen verfügen bekanntlich über Wortschatz und Grammatik. Dabei ist es im BPM wichtig, dass die so genannten Metamodelle nicht nur die hierarchischen Strukturen abbilden, sondern auch die vielfältigen Beziehungen zwischen den einzelnen Teilprozessen, zur Organisation, IT, usw. Für alle Prozesse müssen einerseits klare Definitionen möglich sein, die zum Beispiel Mitarbeitern bei der Prozessausführung eine echte Hilfe sind oder eine umfassende Auswirkungsanalyse vor einer organisatorischen Veränderung zulassen. Gleichzeitig soll das Metamodell die Implementierung von wirtschaftlichen Prozessen in IT erleichtern. Hierfür ist ein höherer Formalisierungs- und Detaillierungsgrad notwendig, der auch durch Metamodell und Notation unterstützt sein muss.

Einheitliches Interaktionsmodell
Für den Manager sind die Teilprozesse oft die kleinsten Einheiten eines Modells. Für die Fachabteilung sind Aktivitäten und Arbeitsschritte die übliche Granularität. Hier fängt für den IT-Experten erst die eigentliche Arbeit an. Er muss darstellen können, welche Daten innerhalb eines Prozesses wohin übertragen werden, welche Voraussetzung die Datenpakete erfüllen müssen, damit dieser Transfer reibungslos vonstattengeht, etc. Dasselbe gilt selbstverständlich ebenfalls für den Datenverkehr zwischen den Prozessen. Der BPM-Standard muss auch diese Ebene darstellen können.

Granularität
Das Metamodell muss von der Wertschöpfungskette über die Organisation einzelner Prozesse bis zur Integration der IT alle Ebenen einer Prozessanalyse umfassen. Dazu muss die Notation auf alle Ebenen anwendbar sein. Gleichzeitig werden Mechanismen benötigt, die es möglich machen, zwischen den verschiedenen Analyseebenen zu navigieren.

Dokumentation
Sowohl das Prozessmodell als auch die daraus entstehenden Diagramme müssen in einem Format vorliegen, das alle Beteiligten verstehen und nutzen können.

Interoperabilität
Wo die IT betroffen ist, muss das im BPM erarbeitete Modell so detailliert sein, dass es ohne großen zusätzlichen Arbeitsaufwand in einen Softwarecode umgewandelt werden kann, der bei der Implementierung von Workflow oder BPMS tatsächlich von Nutzen ist. Andernfalls bleibt die heute oft bestehende Parallelität der Prozessmodelle von Business und IT bestehen.

BPMN – Schritte in die richtige Richtung

Eine perfekte Lösung, die all diesen Anforderungen gerecht wird, gibt es leider immer noch nicht. Doch mit BPMN sind die ersten Schritte in die richtige Richtung gemacht. BPMN ist heute eine Notation, die als Standard anerkannt ist und zunehmend Verbreitung findet. Wie auch UML wird sie von der Object Management Group (OMG) verwaltet. Doch nach wie vor wird heute in der technischen Umsetzung häufig eine Neumodellierung mit allen damit verbundenen Problemen vorgenommen: hoher Aufwand, Fehleranfälligkeit bei der manuellen Übertragung und geringe Sicherheit, dass später beide Modelle synchron gewartet werden. Auch wird teilweise vom Business in Frage gestellt, ob BPMN wirklich die richtige Notation darstellt, da BPMN der Ruf vorauseilt, wie UML aus der Softwareentwicklung zu kommen. Tatsächlich basiert BPMN zwar auf theoretischen Überlegungen der modellgetriebenen Softwarentwicklung. Allerdings liegt der Fokus auf der Prozessautomatisierung, also der Steuerung von Prozessen z.B. durch Workflowoder BPM-Systeme. BPMN wurde von Anfang an so entwickelt, dass damit Geschäftsprozesse sowohl organisationsals auch technikorientiert modelliert werden können. Was heute noch fehlt ist einerseits ein eindeutiges Metamodell für BPMN. Dieses befindet sich aber in der Entwicklung. Andererseits fehlt häufig im Business noch die Erfahrung, wie man mit BPMN pragmatisch umgeht. Wer eine reine BPMN-Schulung besucht, erlernt dort meist die vollständige Notation. Mit zunehmendem Einsatz von BPMN im Business wird sich zeigen, dass wie bei vielen anderen Notationen zunächst ein sehr einfaches abstrahiertes Modell ausreicht. Hier soll ja zunächst beschrieben werden, was im Prozess zu tun ist ohne auf alle Details des  Wie einzugehen. In der IT-nahen Modellierung geht es dann primär darum, wie der Prozess durch IT realisiert werden soll.

Enterprise Repository für alle

Produkte wie die MEGA Modeling Suite setzen für die Beschreibung von Systemprozessen bereits auf BPMN und benutzen für die Darstellung der Geschäftsabläufe adäquate eigene Methoden. BPMN wurde in diese Methodik integriert. Als gemeinsame „Schaltzentrale“ dient das Enterprise Repository, in dem sowohl die Geschäftsprozesse als auch IT-Anwendungen, Infrastruktur und Risiken und Kontrollen enthalten sind. Ebenso werden dort die Verbindungen zwischen diesen „Welten” hinterlegt. Zum Beispiel ist im Repository klar festgelegt, welche Geschäftsprozesse welche IT-Services nutzen. Der wichtigste Vorteil solcher Lösungen ist die Möglichkeit, Strukturen und Prozesse in verschiedenen grafischen Modellen darzustellen. So erhält der Manager Einblick in die IT-Strukturen seines Unternehmens, ohne sich tief in die Niederungen des Softwaredesigns einarbeiten zu müssen. Auf der anderen Seite kann der IT-Verantwortliche erkennen, in welchen größeren Zusammenhängen seine Software zu sehen ist. Da auch die Beziehungen zwischen den einzelnen Prozessen und Anwendungen hinterlegt sind, lassen sich die Auswirkungen von Änderungen sofort erkennen.

Eine bessere Zukunft

Neue Standards wie die Anfang 2008 veröffentlichte BPMN 1.1 sind wichtige Schritte hin zu einer besseren Verständigung. MEGA und andere führende Anbieter von BPM-Lösungen arbeiten auf dieser Grundlage an einemgemeinsamen Standard, der alle oben aufgezählten Anforderungen erfüllen soll. Eine solche Lösung würde dann noch besser die Voraussetzungen für die Orchestrierung einzelner IT-Services schaffen, wie sie für die Implementierung von serviceorientierten Architekturen notwendig ist. Dadurch kann das Requirements Engineering verbessert und die Abbildung in Workflow- und BPM-Systeme beschleunigt werden. Zusammenfassend lässt sich sagen, dass die Hauptaufgabe jeder Modellierungs-Software heute darin liegt, die unterschiedlichen Denkweisen von operativem Management und IT-Spezialisten miteinander zu vereinbaren. Dabei müssen momentan noch Kompromisse geschlossen werden. Die Entwicklung neuer Standards und Notationen wird in Zukunft dafür sorgen, dass diese Kommunikationsprobleme überwunden werden. Es ist daher gut vorstellbar, dass in näherer Zukunft in jedem Unternehmen spezialisierte Prozessentwickler Hand in Hand mit Prozessarchitekten aus dem Fachbereich zusammenarbeiten oder sich sogar eine ganze Abteilung um die Koordination von Geschäftsprozessen und IT-Diensten kümmern wird.

ROLF IRION

Diesen Artikel finden Sie auch in der Ausgabe Januar/Februar 2009 des it management.