Es werden hin- und wieder Zweifel laut, inwieweit BPMN für die Abstimmung zwischen Fachseite und IT wirklich geeignet ist, oder ob es von der IT Seite bevorzugt wird. Darauf möchte ich hier eine Antwort geben.
BPMN ist nur ein Standard für die Definition von Geschäftsprozessmodellen, nichts weiter.
Natürlich werden mit jedem neuen Standard oder mit jeder neuen Methode Hoffnungen verbunden und auch Enttäuschungen erlebt.
Hier hilft Nüchternheit.
Es ist ein Werkzeug, das für bestimmte Aufgabenstellungen nützlich sein kann und für andere Aufgabenstellungen ist es wiederum nicht nützlich. Liegt im Hammer die Zukunft? Oder doch eher in der Zange? Vielleicht in der Bohrmaschine? Für die richtige Aufgabenstellung ist jedes dieser Werkzeuge für sich nützlich. So ist es auch mit den Modellierungssprachen.
Ein Fehler sollte nicht gemacht werden: Aus einer falschen Anwendung einer Methode Rückschlüsse darauf ziehen, ob die Methode für bestimmte Aufgaben geeignet ist oder nicht. Die Methode, die man nicht falsch anwenden kann, die ist auch noch nicht erfunden worden. Zu der Nutzung einer Methode gehört darum auch immer das “Gewusst wie!”.
Zurück zur Ausgangsfrage bezüglich der Abstimmung von Fachseite mit der IT-Seite. Die Aufgabe des Modells dabei ist es Transparenz zu schaffen, die Qualität in einer frühen Phase zu sichern (und dadurch Geldverschwendung durch die IT-Umsetzung falscher Prozesse zu vermeiden), Integration zu schaffen, Struktur zu geben und letztendlich eine höhere Stufe der Flexibiltät zu erreichen (sprich es geht schneller, wenn ein Ablauf geändert werden muss als vorher ohne Modell).
Alles in ein Modell ist sicher falsch dabei. Ein Beispiel: Ein Modell sollte nicht wesentlich mehr als um die 7 Aktivitäten beinhalten. Warum das? Weil der menschliche Geist umgefähr 7 Dinge gleichzeitig erkennen kann. Übersteigt ein Modell die Anzahl dieser Modellierungselemente wesentlich, dann wird es als verwirrend und unübersichtlich wahrgenommen. Sie glauben das ist nicht möglich? Natürlich ist es möglich. Dazu muss das Modell nur entsprechend strukturiert werden. Dazu dienen zum Beispiel die Möglichkeiten der Sub-Prozesse in BPMN.
Zudem beleuchten verschiedene Modelltypen verschiedene Aspekte des gleichen Prozesses.
Nehmen Sie zum Beispiel das Konversationsmodell
Siehe dazu auch dieses Kurzvideo:
Hier kann man mit nur drei Modellierungselementen eine gute Übersicht über eine Prozesslandschaft erstellen und der ganzen Modell-Landschaft die richtige Struktur geben. Von dort aus ist es dann möglich in weitere Ebenen darunter zu drillen.
Ein weiterer Punkt ist, dass Fachseite und IT-Seite unterschiedliche Informationsbedürfnisse haben. Die Fachseite interessiert sich mehr dafür, welche Geschäftsdokumente (Auftrag, Lieferung, Rechnung, …) wann wie erzeugt und bearbeitet werden und wer dafür verantwortlich ist. Die IT-Seite interessiert sich mehr für die Strukturierung der Anwendungen (Schnittstellen) und für die Sonderfälle (Stornierung, Änderungen im laufenden Prozess). Natürlich muss auch die Fachseite diese Fragen nach den Sonderfällen im Prozess mit beantworten, nicht aber die Strukturierung der Anwendungen (Schnittstellen). Hier kommt es darauf an, verschiedene Modelle mit verschiedenen Details des gleichen Prozesses zu machen.
Sprich es ergibt sich eine Modell-Landschaft, die aber untereinander verbunden ist. Änderungen, die sich in einem Modell ergeben können – das richtige Tool vorausgesetzt – dann leicht in anderen Modellteilen nachvollzogen werden, da es für die entsprechenden Elemente (Geschäftsobjekte) Verwendungsnachweise gibt – also die Auskunft in welchem anderen Modell dieses Geschäftsobjekt – das jetzt geändert werden soll – ebenfalls vorhanden ist, und das damit ggf. ebenfalls angepasst werden muss. Diese Möglichkeiten wurden erst durch das BPMN Metamodell erschaffen.
Diese Änderungen wiederum sollten natürlich, vor allem wenn es eine größere Modell-Landschaft ist, einem Reviewprozess unterworfen sein. Gerade der ordentliche Reviewprozess wird oft gerne vernachlässigt. Man denkt: Naja – wir reden eben schnell einmal darüber oder wir machen einen Workshop. Da kommt es oft zu mehr Missverständnissen als Lösungen. Ein strukturierter Reviewprozess sorgt dafür, dass bei jeder relevanten Änderung, die Einfluss auf andere Bereiche hat, den entsprechenden Stakeholder eine Reviewphase zugebilligt wird, offene Punkte formuliert werden, und diese strukturiert abgearbeitet werden. Das ist in der Summe weniger aufwändig, als es “Auf Zuruf” zu machen, weil eben viele Missverständnisse vermieden und von Anfang an ausgeschlossen werden. Es gibt auch keine Modellierungsmethode der Welt, die einen solchen Prozess überflüssig macht, wenn die Aufgabenstellung eben entsprechend groß ist. Für kleinere Aufgaben kann der Reviewprozess natürlich schlanker sein – das ist klar.
Im Reviewprozess wird ein Leitfaden zugrunde gelegt. Dieser Leitfaden wird für ein spezifisches Projekt maßgeschneidert erstellt und legt die Regeln fest. Die Regeln besagen, welche Modellierungselemente für welche Ebene des Modells erlaubt sich und welche nicht. Das generell und allgemeingültig festzulegen ist nicht sinnvoll, da es immer vom Projekt abhängt und von der Aufgabenstellung, die das Projekt erfüllen muss. Natürlich gibt es einige Gemeinsamkeiten mit anderen Projekten. Jedenfalls ist der Leitfaden die wesentliche Grundlage dafür, welche Modellierungselemente zu Einsatz kommen. Das vom Standard zu erwarten heißt, den Standard zu überfordern. Der Standard hat schon einige solcher Regeln bereits festgelegt, aber eben genug Freiraum gelassen, damit sowohl die Bedürfnisse der Fachseiten als auch die der IT-Seiten berücksichtigt werden können.
Ob BPMN zu viele Modellierungselemente hat? Ich sage einmal so: 20% der Elemente werden in 80% der Fällen verwendet. Und das ist auch gut so. Ich halte einige der Elemente ebenfalls für überflüssig oder warne sogar vor deren Einsatz. Aber viele sind auch gut, und gerade mit BPMN 2.0 sind wieder sehr gute neue Modellierungsmöglichkeiten dazu gekommen, die beispielsweise viel Transparenz in B2B Prozesse bringen können. Was auch wichtig ist: Die Fachseite vesteht konkrete Modellierungselemente viel besser als abstrakte. Konkret ist beispielsweise: Datenobjekte (Geschäftsobjekt wie Rechnung, Bestelltung, Lieferung, …), der Status eines Datennobjektes (Offen, Erledigt, In Bearbeitung, Genehmigt, Bezahlt, …) die Aktivität (wie Freigeben, Genehmigen, …) als auch eine Rolle (Einkäufer, Gruppenleiter, …). Ich hatte noch nie und bei niemandem Probleme mit der intuitiven Verständlichkeit eines solche Modells. Intuitiv heißt hier: Ohne Schulung. Schlechter verstanden werden dagegen abstrakte Modellierungselemente wie Gateways, Events, etc. pp. Ungefähr in der Mitte sind Nachrichten und Nachrichtenflüsse. Es ist die Aufgabe des Leitfadens, den Einsatz der Modellierungselemente dahingehend zu regeln.
Man darf nicht die Leistung, die man eigentlich von einem ordentlichen Reviewprozess erwarten muss, von der Methode erwarten.
Ist BPMN die Zukunft? Ich sage: Es ist im Moment sehr nützlich, wenn es richtig – also für den richtigen Zweck und auf die richtige Weise – eingesetzt wird. Und dazu gehört definitiv die Abstimmung zwischen Fachseite und IT.
