BPMN oder nicht? Die Grundsatzfrage dahinter.
Die Diskussion, ob BPMN eingesetzt werden soll oder nicht, reduziert sich bei der “Contra”-Fraktion i.d.R. auf ein Argument: “BPMN ist zu kompliziert”.
In diesem Post soll es weniger um BPMN als um dieses Argument gehen, und meine Einschätzung zur gesamtgesellschaftlichen Entwicklung, die mit dieser Frage verbunden ist. Oder um es kurz zu machen: Warum die “BPMN ist zu kompliziert”-Haltung keine Zukunft hat.
Gunter Dueck beschreibt in seinem neuesten Buch “Aufbrechen” extrem anschaulich, wie sich unsere Gesellschaft gerade verändert. Und so wie in den letzten 200 Jahren in der Landwirtschaft und der Industrie die Pferde durch Trecker und die Arbeiter durch Maschinen und Roboter ersetzt werden, so werden seit einigen Jahren im Dienstleistungssektor bzw. den äquivalenten Abteilungen in Industrieunternehmen die Sachbearbeiter durch IT-Lösungen ersetzt. Und wir stehen gerade mal am Anfang dieser Entwicklung: Es ist kaum nennenswert, was bisher in dieser Richtung passiert ist, wenn man sich klar macht, was noch alles passieren wird.
Natürlich werden zigtausende, eher Millionen Menschen in Deutschland, der EU, USA etc. durch diese Entwicklung arbeitslos. Gar keine Frage, dass diese extreme gesellschaftliche Veränderung zu großen Schwierigkeiten führen wird. Prof. Dueck glaubt, dass wir die kritische Phase, wenn wir es richtig machen, relativ schnell überwinden und in eine bessere Phase eintreten werden, und ich glaube das auch. Aber wie auch immer: Diese Veränderung steht fest, so oder so.
BPMN ist ein zentraler Baustein in dieser Entwicklung: Mit BPMN beschreiben wir Geschäftsprozesse, die (überwiegend) von Menschen erledigt werden, damit sie zukünftig (überwiegend) von IT erledigt werden. Wir können damit auch andere Sachen machen, aber das ist die ursprüngliche Motivation. Natürlich geht das nicht immer gleich komplett, deshalb gibt es “Human Workflow Management”, auf dem Weg zur kompletten “Dunkelverarbeitung”, wie die angestrebte Vollautomatisierung in der Versicherungswirtschaft heißt.
Ob wir in 5 oder 10 Jahren noch mit BPMN arbeiten oder einer anderen Notation, ist dabei herzlich egal. Wichtig ist nur die Motivation hinter BPMN, und wie der Standard aufgebaut wurde, um diesen Zweck zu erfüllen. Ich bin mir ziemlich sicher, dass es in absehbarer Zeit eine bessere Lösung als BPMN für diesen Zweck geben wird, und später dann wieder eine bessere Lösung usw. Das ist gar nicht der Punkt.
Der Punkt ist, welche Menschen und Kompetenzen eine solche Gesellschaft noch brauchen wird, und welche nicht. Und jetzt wird es unangenehm.
Mit den Webmaschinen wurden die (Hand-)Weber überflüssig. Mit IT-Lösungen werden Sachbearbeiter, aber auch Manager, überflüssig. Natürlich wird es immer noch Sachbearbeiter und Manager geben, aber deutlich weniger. Standardisierte und automatisierte Prozesse arbeiten gleichartig und deshalb vorhersehbar. Da braucht es keine “Aufpasser” mehr. Natürlich passieren Fehler, und natürlich gibt es auch zukünftig Kunden mit Sonderwünschen. Und Dienstleistungen, die sich nicht mit IT-Lösungen automatisch erbringen lassen. Aber eben deutlich weniger.
Wenn ein Unternehmen in dieser neuen Gesellschaft kaufmännisch erfolgreich sein will, hat es zwei Möglichkeiten:
1) Es geht diesen Weg und maximiert den Automatisierungsgrad seiner Geschäftsprozesse, wo es nur geht
2) Es findet irgendeinen Weg, sich als “Service-Führer” in einer Nische einzurichten, und leistet sich ineffiziente Prozesse.
Der allergrößte Teil der Unternehmen wird 1) gehen, und das bedeutet, dass der Stellenwert von IT für den Unternehmenserfolg nochmal extrem steigen wird im Vergleich zu dem Stellenwert, den IT dort heute schon hat. Und eine Konsequenz davon ist, dass “IT follows Business” nicht geschehen wird. Es wird genau umgekehrt passieren: Nicht das Business wird dank modellgetriebener Entwicklung o.ä. IT-Mitarbeiter überflüssig machen, sondern immer mehr IT-Professionals erwerben betriebswirtschaftliche Kompetenzen, und drängen ins Business. Das Management der Unternehmen wird in dem Maße “technokratisiert”, wie die Gesellschaft insgesamt.
Das muss so passieren, weil 1) sonst nicht funktionieren würde. Unternehmen mit Mitarbeitern, die eine “Techie-Ader” haben, werden 1) erfolgreicher praktizieren als Unternehmen mit Mitarbeitern, denen die Denkweise von IT-Professionals fremd ist. Unternehmen mit analytisch geprägten Menschen, die intellektuelle Herausforderungen, z.B. im Bereich der Logik, interessant finden und eine Art sportlichen Ehrgeiz besitzen, Systeme zu verstehen, werden 1) besser umsetzen. Unternehmen mit Mitarbeitern, die solche Herausforderungen als lästig empfinden und sich eher in assoziativen und kommunikativen Disziplinen üben, werden 1) schlechter umsetzen und deshalb insgesamt im Wettbewerb verlieren.
Das heißt nicht, dass jeder Manager und jeder Mitarbeiter ein Programmierer sein muss. Aber tatsächlich muss fast jeder so “gestrickt” sein, dass er Programmieren prinzipiell interessant findet. Mit “fast” meine ich, dass es selbstverständlich auch in der “neuen Welt” Menschen geben muss und wird, auch in Versicherungen etc., die beispielsweise in rein kreativen Bereichen arbeiten, und für ihren Job keine “Techie-Ader” haben müssen. Aber es werden eben deutlich weniger als heute sein, das ist der Punkt.
Und jetzt schließen wir den Kreis zur BPMN: Menschen mit “Techie-Ader”, egal ob sie jetzt Programmierer oder Top-Manager sind, finden die Ideen und den Aufbau der BPMN eigentlich immer sehr interessant, geradezu faszinierend. Das habe ich jetzt oft genug erlebt. Es macht ihnen richtig Spaß, die Denkmuster zu durchdringen und BPMN auszuprobieren. Oder auch die logischen Schwachstellen zu finden und entsprechend zu kritisieren, was auch in Ordnung ist, weil man sich einfach damit beschäftigt, und nur darum geht es. Ich habe nicht selten erlebt, dass ein Abteilungsleiter BPMN viel besser verstanden hat als seine Mitarbeiter und diese regelrecht getreten hat, den intellektuellen Hintern hochzukriegen und sich mit einer formalen Modellierung anzufreunden. Und das ist das ganze Geheimnis hinter dem viel beschworenen “Business-IT-Alignment”, egal ob mit BPMN oder sontwas.
Menschen, die die Komplexität der BPMN, die zweifelsohne vorhanden ist, aus Prinzip ablehnen und als unzumutbare Belästigung empfinden, haben diese “Techie-Ader” in der Regel nicht. Das sind die Menschen, die für eine Entwicklung wie in 1) ganz zwangsläufig nur einen geringeren Beitrag leisten können. Natürlich wird es sie in Unternehmen, die 1) gehen, auch zukünftig geben. Aber eben… deutlich weniger.
Noch ein Hinweis zum Schluss: Ich will gar nicht sagen, dass die BPMN-Gegner zu “doof” wären und deshalb verschwinden müssten. Ich glaube aber, dass viele Menschen den “Techie in sich” entdecken müssen. Damit meine ich wie gesagt überhaupt nicht, dass jeder programmieren muss. Aber jeder sollte versuchen, ein gewisses Interesse für analytische Prinzipien zu entwickeln. Einfach Freude daran, ein logisch aufgebautes System gedanklich zu durchdringen. Das ist m.E. keine Frage der “Gene”, sondern eine innere Einstellung, die jeder entwickeln bzw. bei sich entdecken kann. Und hier bin ich einer Meinung mit Gunter Dueck. Denn wer das nicht macht, wird in den kommenden Jahrzehnten verflucht schlechte Karten haben.
> Ich will gar nicht sagen, dass die BPMN-Gegner zu “doof” wären
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 😉
Übrigens, hier mal meine Antwort dazu:
http://www.ariscommunity.com/users/sstein/2010-03-19-criticizing-bpmn
Hallo Jakob,
ich sehe die Redundanz nicht so kritisch. Hier kann sich doch jede Organisation auf einen Guide festlegen. Wir selbst bemerken, dass Redundanz auch Freiheitsgrade geben. Wir sind ja aktuell dabei, mit Signavio zusammen das BPM Round-Trip Engineering anzugehen, sprich Modellierung mit einem Tool zur professionellen Prozesdokumentation und Ausführung in unserer Worklfow Engine. Und da es nun immer konkreter wird, sprich wir aktiv an der Entwicklung des Transformers von BPMN nach SAPERION Workflow Modell sind, ist es doch gut, dass es nicht nur eine Verzweigung per Gateway gibt, sondern auch ohne möglich ist. Folgender Hintergrund:
Unser Workflow System bietet nicht nur eine Verzweigung, die durch Auswertung von Parametern, z.B. Betrag > 5000, durch die Engine geregelt wird. Alternativ geben wir die Verantwortung in die Hände der Benutzer. Ist dieser mit der Bearbeitung seiner Aufgabe fertig, entscheidet er über passende Kontextmenüeinträge, wohin es im Sequenzfluss weitergehen soll. Wir werden dies durch die Transformation so gestalten, dass die Bedingungseigenschaft eines Sequenzfluesses die Syntax “User:hier gehts lang” trägt.
Näheres zur Transformation von BPMN nach SAPERION habe ich gerade bei uns gepostet:
http://www.saperionblog.com/lang/de/saperion-und-signavio-auf-dem-weg-zum-bpm-round-trip-engineering/1220/#more-1220
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
Hallo Martin,
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
Hallo BPMNers,
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….
Hallo Jakob,
ein interessanter Beitrag mit interessanten Ansichten. Allerdings möchte ich auch gerne eine entgegengesetzte darstellen.
Meiner Ansicht nach besteht die zentrale Herausforderung in Zukunft für Unternehmen in unseren Breitengraden (also in den “westlichen Industrienationen”) nicht so sehr in der Erreichung einer möglichst hohen Automatisierung. Der Grund dafür liegt darin, dass dieses Ziel auf eine Kostenreduzierung abstellt – und man sich damit aus bisheriger Perspektive auf einen Kampf einlässt, der gegen aufstrebende Schwellenländer mit niedrigsten Löhnen und trotzdem hervorragend ausgebildeten Technikern nicht zu gewinnen sein wird. Für westliche Unternehmen wird denke ich Flexibilität das entscheidende Kriterium werden. In globalisierten Märkten mit Echtzeit-Kommunikation und immer kürzeren Produktlebenszyklen wird der gewinnen, der auf veränderte Bedingungen überzeugend reagieren kann und der Trends früh erkennt. Und das alles natürlich bei höchsten Ansprüchen an die Qualität. Und hier sehe ich das Problem: automatisierte Prozesse sind vielleicht effizient, aber unflexibel. Prozess-Exzellenz wird entscheidend sein, allerdings mit Blick auf zwei Fragestellungen: (1) Welche Prozesse lassen sich sinnvoll automatisieren, weil wenig Dynamik zu erwarten ist? (2) Kenne ich die kritischen Punkte in meinen Prozessen, an denen Veränderungen zu hohem Aufwand führen und möglicherweise Einfluss auf die Qualität meiner Leistungen haben können und habe ich entsprechende Szenarien entwickelt um damit umzugehen?
Dies bedeutet natürlich, dass Unternehmen ihre Prozesse wirklich beherrschen müssen, und dafür müssen sie sie kennen. Hier ist meiner Ansicht nach der Punkt, an dem die BPMN den Unternehmen wirklich Vorteile bringt, denn mit ihr _kann_ leicht verständlich, anschaulich und trotzdem präzise modelliert werden. Darüber hinaus ist es ein offener Standard, der aktiv weiter entwickelt wird. Ich sehe also den Hauptvorteil der BPMN nicht so sehr in ihrer Nähe zur automatischen Ausführbarkeit, sondern darin, dass mit ihr die Verfügbarmachung von Prozesswissen und damit letzlich die Beherrschbarkeit der Prozesse verbessert wird.
Zur häufig bemängelten Komplexität von BPMN: Das hat meiner Ansicht nach wenig mit einer “Techie-Ausrichtung” der BPMN zu tun. Es ist nun einmal so, dass Systeme eine bestimmte Komplexität aufweisen müssen, um entsprechende Leistungen (in diesem Fall: verständliche Diagramme mit hoher Informationsdichte) erbringen zu können. Daher muss man in der Praxis Vorgehensweisen zum Umgang mit dieser Komplexität entwickeln. Da ist denke ich der in eurem Buch dargestellte Ansatz der verschiedenen Sichten auf den Prozess (strategisch, operativ, technisch) schon recht hilfreich. Auch wenn die Erstellung verschiedener Modelle für jede Sicht aufwändig sein mag: Ein umfassendes Prozessverständnis lässt sich nunmal nicht umsonst (also gratis) erreichen.
Schöne Grüße und einen guten Wochenstart,
Carsten
Hallo zusammen,
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