Heute geht es aber wirklich rund in den Foren, z. B. auf BPM-Netzwerk, in der ARIS Community und BPM-Guide (und wahrscheinlich noch ein paar mehr, aber neben dem Bloggen versuche ich auch noch zu arbeiten …). Langsam wird die Debatte etwas ideologisch. Hier das Lager „BPMN ist doof, weil zu kompliziert“, dort „BPMN ist die Sprache auf dem Weg in die Zukunft unserer Gesellschaft“.
Ich denke nicht, dass das weiterhilft. BPMN hat viele Macken, das ist unbestritten. Insofern kann man einer Weiterentwicklung und Verbesserung der BPMN nur zustimmen. Wenn es Konstrukte gibt, die sich absolut nicht bewähren, sollte man diese auch wieder entfernen, auch wenn man dann die Abwärtskompatibilität zu früheren BPMN-Versionen verliert. Ja, die Diskussion wird in der OMG zu technisch geführt. Wenn das Ziel einer gemeinsamen Sprache von Business und IT ernst gemeint ist, dann muss einiges in Richtung fachlicher Modellierung verbessert werden (z. B. in Richtung Prozesslandkarten, bessere Anknüpfung an die Organisationsmodellierung usw.).
Der wesentliche Punkt ist aber: Bisher gab es keine einheitliche Notation, jetzt gibt es einen Standardisierungsvorschlag, der zunehmend an Akzeptanz gewinnt – sowohl bei den Herstellern als mittlerweile auch immer stärker bei den Anwendern. Dass man eine gemeinsame Sprache spricht, ist schon ein Wert an sich. Warum sollte z. B. derjenige, der nur ganz simple Modelle mit ein paar Aktivitäten und Verzweigungen erstellt, nicht einfach die Standardsymbole der BPMN verwenden? Die einzige Alternative ist ja, dass jeder wie bisher seine eigene Notation verwendet, oftmals „Freestyle Modeling“ mit Visio. Den Ausdruck „Freestyle Modeling“ habe ich von einem BPMN-Seminar, wo ein Teilnehmer den gegenwärtigen Zustand im Unternehmen beschrieb: Jeder modelliert, wie er will, und nichts passt zusammen. Wo sollte da der Vorteil gegenüber einem Standard sein?
Ob man es will oder nicht: Wer professionelle und hochwertige Produkte und Dienstleistungen anbieten will, der muss auch seine Prozesse professionell managen. Dazu gehört es, diese so genau und exakt zu modellieren, wie es dem jeweiligen Zweck angemessen ist. Hier kann sich das Business nicht auf den Standpunkt stellen, es genüge, die Prozesse quick and dirty darzustellen. Professionelles Arbeiten heißt auch, die Prozesse genau zu beschreiben und zu durchdenken. Bekanntlich leiden viele IT-Projekte unter mangelhaften Anforderungsdefinitionen. Das kann aber nicht alleine von der IT-Seite gelöst werden. Das Business kann sich hier auf Dauer nicht aus der Verantwortung stehlen. Der Satz „das versteht das Business nicht“, wenn es um mehr als zwei Kästchen und einen Pfeil geht, ist ebenso unangemessen wie falsch. Das Business soll sich nicht um die technischen Details kümmern, wohl aber um die genaue und korrekte Beschreibung seiner Prozesse, Regeln usw. Zu den hierfür geeigneten Beschreibungsmitteln können im konkreten Fall auch verschiedene Ereignistypen, Nachrichtenflüsse und weitere BPMN-spezifische Konstrukte gehören.
In diesem Sinne schließe ich mich den Diskussionsteilnehmern an, die die BPMN einsetzen und sich zugleich für eine Weiterentwicklung und Verbesserung dieser Notation stark machen.
Sehr geehrter Prof. Dr. Thomas Allweyer,
natürlich kann und will sich das Business nicht dahinter verstecken, dass ein BPMN Modell mit mehr als 2 Kästchen und einem Pfeil zu kompliziert ist.
Ich habe bisher eher die Erfahrung gemacht, dass das Business mit weit mehr komplexität umgehen kann. Das Business interessiert sich aber für ganz andere Aspekte, als jene, die im Kontext dieser Diskussion angeführt wurden.
Vielleicht habe ich noch nicht genug Einblick in die BPMN, aber es hat sich mir noch nicht erschlossen, wie man die andern für das Business genau so wichtigen Fragen im Modell umsetzt. Z. B.:
– Wie ist der beschriebene Prozess in das Unternehmensprozesshaus eingeordnet (vorangegangene und nachfolgende Prozesse, übergeordnete Unternehmensfunktionen, …)?
– Welche Risiken (z. B. im Sinne von SOX) treten während der Prozessausführung auf?
– Welche Kennzahlen an welchen Punkten im Prozess definieren die Qualität oder Effektivität des Prozesses?
– Welche Regularien (Gesetze, Verfehrensanweisungen, Normen, …) sind im Prozess und an einzelnen Prozessfunktionen zu beachten?
– An welchen Funktionen ist eine Rolle im Untrnehmensprozess noch beteiligt und wie (responsible, accountable, consulting, informative, …)? Oder anders gefragt – was ist das (vollständige) Funktionsprofil einer Rolle?
– Welches Material muss wo während der Prozessausführung bereitgestellt werden?
Hallo Herr Ploetz,
das ist absolut richtig, diese ganzen Themen werden von der BPMN bisher überhaupt nicht adressiert. BPMN konzentriert sich ausschließlich auf den Kontrollfluss, und ein bisschen auf den Datenfluss. Schon der Zusammenhang mit der Aufbauorganisation ist nicht so richtig definiert.
Wahrscheinlich wäre es schwierig, alle genannten Aspekte komplett mit einem Standard abdecken zu wollen. Ein solcher Standard würde vermutlich nie fertig, oder er wäre für viele Organisationen nicht brauchbar, weil er spzeifische Anforderungen doch nicht unterstützt.
Aber immerhin, ein Standard für die Ablaufmodellierung ist ja schon ein Anfang. Jetzt werden m. E. Best Practices benötigt, wie man diese mit den anderen Sichten und Aspketen verknüpft. Die BPMN bietet eine Reihe von Möglichkeiten für die Erweiterung, wie z. B. die Möglichkeit, eigene Artefakte zu definieren.
Da es bisher noch keine allgemein anerkannten Best Practices für die Integration mit anderen Sichten gibt, entwickelt derzeit jeder Hersteller seine eigene Art, die Sichten zu verbinden. Schon der Einstieg in die oberste Modellierungsebene ist unterschiedlich: Die einen verwenden Wertschöpfungsketten, andere vereinfachte (und im Sinne der Spezifikation nicht unbedingt korrekte) BPMN-Modelle, wieder andere UML Use Case Diagramme, oder sie verzichten ganz auf eine grafische Darstellung und stellen lediglich eine Prozesshierarchie in Explorer-Form dar.
Ich stimme absolut zu, dass diese Baustellen für eine fachliche Modellierung wesentlich wichtiger sind als z. B. die Darstellung von unterbrechenden Zwischenereignissen in einem Detailprozess.
Wobei die genannten Probleme nicht nur für die fachliche Modellierung existieren. Vergleichbare Fragestellungen finden sich auch bei der Modellierung ausführbarer Prozesse. Wie werden z. B. Funktionaliäten für neu zu entwickelnde Services spezifiziert, wie werden Benutzerdialoge integriert, wie kann man Regeln für eine dynamische Auswahl von Bearbeitern integrieren, u.v.m.