vielen Dank nochmal für Eure sehr interessanten Reaktionen!

Ich muss zugeben dass ich das Ganze auch absichtlich etwas überspitzt (oder “brutal”) dargestellt habe, weil das nach meiner Erfahrung häufig zu den spannenderen Diskussionen führt.

Tatsächlich sehe ich den Sachverhalt ähnlich differenziert wie Ihr, aber teilweise auch immer noch etwas anders . Ich will versuchen mir in Kürze wieder etwas Zeit zu nehmen und meine (differenziertere) Sicht mit ein paar Schaubildern verständlich zu machen.

Viele Grüße

Jakob

Schöne Grüße und einen guten Wochenstart,
Carsten

geschwinde meine 50 cents zu dem Thema: Ich sehe es nicht so brutal wie J Freund, und finde auch nicht, dass BPMN zu kompliziert ist, und damit nicht erlernbar für die Masse. Ich stimme eher anderen Kommentaren zu, die sagen, dass es eben auch nicht jeder können / verstehen muss, aber: Es muss eben die für Prozesse relevante Gruppe von Personen schon verstehen, und das sind und bleiben dedizierte Menschen aus der IT und den Fachbereichen. Denn die können eben schon über gemeinsame Prozessmodelle verstehen was die eine Gruppe (Fachbereich) will, und die andere Gruppe (IT) liefern kann – wenn ich das mal ein wenig plakativ formuliere.

Fakt ist aber, und das kann ich bei allen meinen Kunden beobachten, das grösste Problem ist das mangelnde Detailwissen über Prozesse, und das ist mangelhaft auf beiden Seiten. Die IT weiss zu wenig über die fachlichen Motivationen, die Fachseite weiss zu wenig über IT Realitäten, und oft auch was sie im Sinne der Prozesse wirklich braucht und will. Deswegen muss das Prozessmodell von der Fachseite kommend en detail beschrieben werden, zum Beispiel inklusive detailierter Datenflüsse, spätestens falls man die IT beauftragen will. Hier sehe ich aber grosse Herausforderungen zum Beispiel in Datenattributen zu denken – auf der Fachseite – und zusätzlich sind diese Datenattribute in der IT oftmals schön verteilt, und redundant, und gerne auch mal kryptisch (in den Augen der Fachseite) benamst. Das alles macht die Aufgabe der Verwendung eines Prozessmodels aus dem Fachbereich für eine mehr oder weniger geschwinde Umsetzung in der IT sehr schwierig. Zusätzlich stimmt es, dass die realen Prozesse in vielen Unternehmen sehr schnell sehr umfangreich und komplex werden, so dass man sich am Anfang auch einschränken muss, welche Prozesse, oder auch nur welche Pfade von welchen Prozessen sinnhaft und realistisch erste Kandidaten für so eine Übung Richtung Prozessautomatisierung sind. Und hier wird sehr schnell von der Fachseite prozedurales und strukturelles Denken gefordert, was eine weitere Hürde ist……denn vielen auf der Seite graut schon vor dem Einsatz von Gateways, und wenn Prozesse eine Mindestanforderung haben, dann ist es die zu beschreiben und welchen Kriterien bestimmte mögliche Pfade verfolgt werden sollen. Wer das nicht wissen / modellieren will, der hat auch ohne BPMN seine Probleme…

Die BPMN scheint eine neue Möglichkeit zu sein das Thema anzugehen, und ich rate auch davon ab, den Standard in all seiner Fülle am Tag 1 einzusetzen, viel eher sollte man sich in einer definierten Governance einig sein, a) warum überhaupt modelliert wird, b) wer was mit den Prozessmodellen machen soll, und c) welche Objekte der BPMN dann relevant sind und verwendet werden sollen. Und man muss dann die Lust der Prozessmodellierer wecken, den Dingen / Prozessen auf den Grund gehen zu wollen, denn nur dann sind die Modelle am Ende des Tages auch zu gebrauchen, eventuell sogar auch für die IT, die dann in der Lage sein wird die Prozesse und deren Aktivitäten mit ‘Services’ zu bedienen – oder um darüber zumindest mal nachzudenken. Das alles wird aber nicht ohne viele Diskussionen gehen, denn eine Aufgabe im Fachbreich findet in der Regel keinen direkt passenden Service in der IT – und das ist genau die Krux im Zusammenspiel zwischen Fachbereich und IT, welches über standardisierte Prozessbeschreibungen besser funktionieren kann und wird.

Es ist daher richtig, dass es Menschen in den Fachbereichen geben muss, die mehr Technik-affin sind, damit sie überhaupt mal klar beschreiben können – im Sinne eines strukturierten Prozesses – was sie gerne implementiert sehen würden, damit die IT die Services richtig entwickeln und / oder schneiden kann, und auch erstmal eine Diskussion auf Augenhöhe stattfindet.

BPMN hilft uns hier uns im Sinne einer einheitlichen Sprache (die aber auch nur bis zu einem bestimmten Punkt innerhalb der Modellierungspyramide von oben kommend funktioniert) auf den Weg zu machen, ist aber auch wieder nur ein kleiner Bestandteil der Gesamtherausforderung die von den beteiligten Menschen addressiert werden muss. Die grösste davon ist der gemeinsame Wille sich aufmachen zu wollen, transparente Prozesse haben zu wollen innerhalb der Organisation, diese bewusst und manchmal schmerzhaft messbar haben zu wollen, um früh reagieren zu können, wenn Kennzahlen in Schieflage geraten. Wer will das heute? Nicht alle in einer Organisation sind daran interessiert, angefangen von Sachberarbeitern, über’s einfache Management bis hoch ins Executive Management.

Business Process Management fängt daher in den Köpfen an, und BPMN ist nur eines der notwendigen Hilfsmittel, um damit schneller voranzukommen. Retten kann uns BPMN nicht, retten kann uns nur der ernsthafte Wille zur konstruktiven und selbstbestimmten Veränderung. Wer das verstanden hat, wird die BPMN akzeptieren und so wie er sie braucht verwenden, wer das nicht versteht, verschwindet in den Geschichtsbüchern….und damit bin ich dann doch auch so brutal wie J. Freund….

ich finde die visuellen Redundanzen teilweise durchaus störend, z.B. das “X” im XOR, das auch weggelassen werden kann. Hier hätte ich nichts dagegen, die Spezifikation etwas aufzuräumen.

Aber auch Deine Überlegungen kann ich nachvollziehen. Ich habe in der Praxis auch weniger Probleme wegen der visuellen Redundanzen beobachtet, als mit der Fragestellung, welche inhaltlichen “Pattern” angewendet werden sollten, speziell für den Weg vom fachlichen zum technischen Prozessmodell. Hier sehe ich den Pain, um den man sich kümmern muss.

@Sebastian: Nein, ich bin eigentlich nicht der Ansicht, dass ich BPMN-Unkundige als “doof” bezeichnet hätte. Es ist auch überhaupt keine Schande, BPMN nicht zu kennen und zu verstehen. Ich sehe nur jeden, der IT-Projekte umsetzen will, in der Verantwortung, sich mit den formalen Denkweisen, die hinter BPMN stehen, auseinander zu setzen. Und zwar ganz unabhängig davon, ob er im “Business” oder der “IT” arbeitet. Das ist im Wesentlichen meine Forderung, mit der ich sicher nicht überall auf Gegenliebe stoße.

Viele Grüße

Jakob

Ich verstehe aber auch nicht die Aufregung zur Komplexität der BPMN. Man kann doch BPMN mit ganz wenigen Elementen benutzen. Da wir keiner überfordert. Ich habe früher Petri-Netze gemalt. Die haben tatsächlich Sachbearbeiter wenig verstanden bzw. lehnten sie dies ab. Dagegen bemerke ich zunehmend die Akzeptanz der BPMN.
Allerdings muss ich eingestehen, dass es beim Schritt von der reinen Prozessdokumentation in die Ausführungswelt doch etwas mehr analytisches Affinität benötigt. Hier kann nicht einfach drauflos modelliert werden. Gewisse Spielregeln müssen eingehalten werden, damit die Transformation reibungslos laufen kann.
Viele Grüße, Martin

http://www.ariscommunity.com/users/sstein/2010-03-19-criticizing-bpmn

Machst du aber

Im Ernst, ich bin Techniker (promovierter Informatiker), aber gerade weil ich den Informatiker in mir habe, stören mich Teile der BPMN, denn sie ist nicht elegant. In der Programmierung ist es ein oberstes Gebot Redundanzen zu vermeiden, aber die BPMN hat in ihrem Sprachumfang eine Vielzahl von Redundanzen. Genau das macht die Sprache so schwierig.

Generell musst du aufpassen hier nicht 2 Sachen zu vermischen:

1) Entwurfsfehler in der BPMN
2) zu viele mögliche Einsatzgebiete der BPMN

Punkt 1) muss man kritisieren und er muss behoben werden, um BPMN als universelle Sprache erfolgreich zu machen.

Im Sinne des Punkt 2) kritisiere ich die BPMN nicht. Persönlich habe ich kein Problem damit, dass die BPMN zu unterschiedlichen Aufgaben (etwa Fachmodellierung und Prozessautomatisierung) genutzt wird.

Generelle Anmerkung: Dein Post hört sich an wie jemand, der sagt, Function follows Design. Das hat sich nicht bewahrheitet und ich glaube auch nicht, dass sich deine Techie Sicht durchsetzen wird. Aber das können wir ja gerne mal in 20 Jahren diskutieren, wenn wir wissen, wie es ausgegangen ist