Das Dilemma
Die Business Process Modeling Notation (BPMN) stellt in erster Linie eine Reihe von Symbolen bereit. Darüber hinaus enthält sie eine gewisse Methodik, die sich vor allem in den Regeln ausdrückt, nach denen diese Symbole grafisch miteinander verbunden werden dürfen. Die grafische Definition der Symbole und die Regeln ihrer Anwendung bezeichnet man auch als Syntax. Die inhaltliche Bedeutung der Symbole bzw. der Konstrukte, die Sie mit den Symbolen modellieren können, wird als Semantik bezeichnet.
Leider wird allein die Kenntnis der BPMN-Symbole noch nicht dafür sorgen, dass Sie "gute" Prozessmodelle erstellen.
Wir arbeiten seit 2007 mit der BPMN. In dieser Zeit haben wir sie sehr häufig und umfangreich angewandt. Und eines können Sie uns glauben: Wir haben dabei furchtbar gelitten. Das liegt vor allem daran, dass wir uns stets um eine syntaktisch korrekte und semantisch konsistente, also widerspruchsfreie Modellierung bemüht haben. Man kann es sich auch leichter machen, indem man sagt: "Das Prozessmodell ist syntaktisch nicht ganz korrekt, und wirklich widerspruchsfrei ist es auch nicht. Aber egal, Hauptsache, der Betrachter versteht es!" Dieser Schuss geht nach hinten los:
- Wenn Sie die BPMN nicht syntaktisch korrekt anwenden, verlieren Sie alle Vorteile der Standardisierung. Wozu braucht man einen Standard, wenn die Modelle am Ende doch wieder alle unterschiedlich aussehen? Viele BPMN-Werkzeuge ermöglichen Ihnen auch gar keine syntaktisch falsche Modellierung.
- Semantische Ungenauigkeiten oder Widersprüche bergen immer das Risiko, dass Ihr Modell falsch interpretiert wird. Dieses Risiko ist besonders groß, wenn Sie ein Soll-Prozessmodell erstellen und es dann in die IT geben, damit diese es technisch umsetzt.
- Wenn Sie Ihr Prozessmodell für die Ausführung direkt in eine Process Engine geben wollen, haben Sie gar keine andere Wahl, als korrekt, präzise und konsistent zu modellieren.
Wir müssen deshalb zwei sich widersprechende Ziele unter einen Hut bringen:
- Das Prozessmodell muss von unterschiedlichen Betrachtern verstanden und akzeptiert werden, weshalb es möglichst einfach zu lesen sein muss.
- Das Prozessmodell muss den Ansprüchen einer formalen Modellierung genügen, was in den meisten Fällen zu Komplexität führt und einem unerfahrenen Betrachter das Verständnis erschwert.
Dieser Konflikt ist der Hauptgrund dafür, dass es in der Vergangenheit kaum gelungen ist, den Verständnisgraben zwischen Business und IT mit Hilfe von Prozessmodellen zu schließen. Und jetzt kommt die Katastrophe: Die BPMN allein kann das auch nicht!
Genau wie die deutsche Sprache kann auch die BPMN mit sehr großen Erfolgen, aber auch Fehlschlägen verwendet werden. Und genau wie bei der deutschen Sprache hängt die richtige Verwendung vor allem davon ab, mit wem Sie kommunizieren möchten, und worüber. Wenn Sie mit Ihrem Kollegen die Details einer zu entwickelnden IT-Anwendung besprechen, werden Sie ein anderes Deutsch verwenden, als wenn Sie Ihrem dreijährigen Sohn erklären, warum die Katze nicht gern am Schwanz gezogen wird. Und genauso werden Sie für die Abstimmung mit Ihrem IT-Kollegen andere BPMN-Prozessmodelle brauchen als für die Darstellung des zukünftigen Prozesses gegenüber dem Top-Management. Ob Sie hier eine Analogie zum Kleinkind sehen, können Sie selbst entscheiden.
Sie müssen also für bestimmte Zielgruppen und Themen ganz unterschiedliche BPMN-Prozessmodelle entwickeln, damit diese einerseits verstanden werden und andererseits alle Fakten enthalten, die für das jeweilige Thema wichtig sind. Die BPMN kann zwar eine "gemeinsame Sprache" für Business und IT sein -- die Wortwahl und Formulierungen werden trotzdem unterschiedlich bleiben.
Für die Arbeit mit BPMN gilt deshalb:
Der Anspruch an die Präzision und formale Korrektheit des Prozessmodells muss abhängig vom Ziel der Modellierung und den zu erwartenden Betrachtern unterschiedlich hoch sein.
Die Kunden eines Prozessmodells
 |
 Klicken zum Vergrößern |
| Die Prozess-Matrixorganisation |
Wenn wir Prozesse modellieren, müssen wir "kundenorientiert" vorgehen. Das bedeutet, wir müssen stets an den Betrachter des Modells denken und uns in seine Lage hineinversetzen. Das klingt vielleicht banal, aber die wenigsten Prozessmodelle werden diesem Anspruch gerecht.
Die Interessen und Kompetenzen der möglichen Betrachter unserer Prozessmodelle können sehr unterschiedlich sein. Wir haben einmal die typischen Rollen zusammengestellt, auf die wir in unseren BPM-Projekten gestoßen sind. Relativ selten entsprechen sie auch wirklichen Stellen in der Primärorganisation. Meistens bezeichnen sie einfach eine Reihe von Aufgaben, die von bestimmten Projektteilnehmern wahrgenommen werden. Wir konnten aber auch feststellen, dass diese Rollen umso konsequenter definiert und zugeordnet werden, je mehr Erfahrung das Unternehmen mit Business Process Management bereits gesammelt hat. Deshalb empfehlen wir auch BPM-Anfängern, sich mit ihnen vertraut zu machen. Wir haben englische Bezeichnungen für diese Rollen gewählt, weil unsere Kunden häufig international agieren. Das deutsche Äquivalent finden Sie jeweils in Klammern.
- Process Owner (Prozessverantwortlicher
