Signavio Stand. Ist das Gero Decker im rosa T-Shirt?

Steffen Söngen zeigt mir den neuen BPMN-Support in ibo Prometheus. Nice

Ich wollte noch bei intellior vorbeischauen, aber Martin Mayer-Abt war leider schon wieder weg, und deshalb war das nur eine kurze Stippvisite. Bei der ich allerdings beobachten konnte, wie Interessenten vor allem die BPMN-Unterstützung des Tools demonstriert bekamen. BPMN rulz

Wo steht mein Prozess? Bei inubit sieht man es im BPMN-Diagramm (rot umrandet) - auf dem iPhone (bzw. iPod Touch)!

Ich bin noch über die Standfläche von Software AG und IDS Scheer gebummelt, aber irgendwie war mir das dort alles “zu” Salesman-lastig. Wahrscheinlich tu ich den Kollegen unrecht, aber die Leute dort waren alle so schick, dynamisch und selbstbewusst, dass ich gar keine Lust mehr auf ein Gespräch hatte. Aber ARIS Express haben wir uns schon angesehen, wegen der neuen BPMN-Unterstützung, da poste ich in Kürze mal einen Screencast.

Tja, dann war auch schon der zweite Termin, und danach bin ich wieder nach Hause gefahren. Sicher kein Überblicks-Rundumschlag, den ich auf der Cebit vollzogen habe. Aber es waren trotzdem interessante Sachen dabei.

Die Cebit im Spiegelbild

Nice

camunda BPM-Kreislauf

BPM + Scrum?

Sowohl BPM als auch Scrum werden immer beliebter. Lassen sich die beiden Disziplinen sinnvoll kombinieren? Wir glauben schon, und haben auch schon erste Versuche in diese Richtung unternommen, da wir nicht nur BPM-Experten sind, sondern auch Scrum-Expertise besitzen und das Thema entsprechend coachen. Ganz ähnlich geht es Dr. Martin Bartonitz von Saperion, und Martin Wieschollek von Seven Principles, und deshalb haben wir drei uns gestern mal bei camunda in Berlin zusammen gesetzt.

Wie man sich denken kann, ist das ein ziemlich großes Fass, das wir da aufgemacht haben. Und der gestrige Vormittag hat bei Weitem nicht gereicht, um das wieder schließen zu können. Deshalb haben wir zwei Dinge getan: Einfach mal gesammelt, welche Themen bzw. Fragen uns bei “BPM + Scrum” durch den Kopf gehen, und uns dann einfach mal welche herausgepickt und darüber diskutiert. Es wurde eine lebhafte und produktive Diskussion, und die ersten Ergebnisse kommen weiter unten.

Das Ganze ist 100% “work in progress”, aber ganz im Sinne von Scrum wollen wir nicht ewig tüfteln für die perfekte Lösung, sondern zeitnah unsere Ideen herausbringen, damit sie diskutiert und vielleicht sogar schon angewandt werden können. Für die Diskussion habe ich ein Forenbrett auf BPM-Netzwerk.de eingerichtet. Aber natürlich sind auch Diskussionen dazu im Rahmen von Events etc. denkbar, z.B. bei der Berliner BPM-Offensive. Ich werde das dort mal anregen.

Wir drei werden uns jedenfalls im März wieder treffen, um weiter zu diskutieren und die nächste Iteration unserer Ideen zu entwickeln. Die Ergebnisse werden wieder geblogged, entweder im Blog von Martin Bartonitz oder im Blog von Martin Wieschollek, je nachdem wer das nächste Mal Gastgeber und somit Moderator ist. Ich werde dann aber natürlich auch auf BPM-Guide.de darauf hinweisen.

BPM + Scrum: Ergebnisse des 1. Workshops (18.02.2010, camunda, Berlin)

Spontane Überlegung am Anfang: Prozessmodellierung ist kein Overhead

Wir sehen grundsätzlich keinen Widerspruch zwischen der Modellierung von Prozessen und dem agilen Manifest. Die zentrale Frage ist einfach, in welchem Umfang man Prozessmodellierung betreibt. Aber ganz unabhängig von User Stories etc. erspart uns ein kleines Prozessdiagramm eine umfangreiche textuelle Prozessbeschreibung, und das ist ist kein Bremser, sondern eine Hilfe für mehr Agilität.

Scope: Was betrachen wir?

Wir konzentrieren uns im ersten Schritt auf BPM-Projekte (Scrum ist ein Vorgehensmodell für Projekte), also weniger den kontinuierlichen Prozessbetrieb o.ä.. Diese Projekte können drei Ausprägungen haben:

• “Reine” IT-Projekte
• IT-Projekte mit Orga-Anteil (=> Change Management etc.)
• “Reine” Orga-Projekte

Auch wenn es die beiden Reinformen wohl kaum gibt, geht es darum, die unterschiedlichen “Ausmaße”, die der Orga- bzw. IT-Teil in einem BPM-Projekt haben kann, zu berücksichtigen.

Themen rund um BPM + Scrum

Das sind die Fragen, die wir uns spontan gestellt haben:

• Sprint und BPM-Kreislauf bzw. BPM-Projekt: Wie geht das zusammen?
• Scrum-Rollen im BPM-Projekt?
• Scrum-Artefakte im BPM-Projekt?
• Scrum-Zeremonien im BPM-Projekt?
• User Stories im BPM-Projekt?

Als estes haben wir uns der Sprint-Frage gewidmet.

Sprint und BPM-Kreislauf bzw. BPM-Projekt: Wie geht das zusammen?

camunda BPM-Kreislauf

Hier kommt schon das erste Problem: Im Kreislauf ist explizit von einer Phase der Prozesskonzeption die Rede, und danach kommt die Umsetzung. Das riecht verdächtig nach Wasserfall, und tatsächlich ist das ja auch die Denkweise, die dem allgemeinen Paradigma von Konzeption und Umsetzung zugrundeliegt: Erst entwerfe ich ein Haus, dann baue ich es. Spätere Änderungen unerwünscht. Das widerspricht Scrum. Wir sind trotzdem der Ansicht, dass die Prozesskonzeption als Phase erhalten bleiben muss. Hier subsummieren sich viele Tätigkeiten, die einer Prozessverbesserung richtigerweise vorausgehen, z.B. eine ROI-Abschätzung. In der Prozesskonzeption werden unter Umständen überhaupt erst die User Stories ermittelt, die ins Product Backlog eingehen.

Der Soll-Prozess ist nicht in Stein gemeißelt

Das klingt jetzt irgendwie banal, aber tatsächlich schafft diese neue Prämisse einen großen Spielraum, aber auch große Herausforderungen. Allerdings genau die Herausforderungen, denen sich Scrum widmet, und für die Scrum ja auch Lösungsansätze bietet.

Nach dieser Grundsatzüberlegung kamen wir zur Gretchenfrage: Wie schneide ich meine Sprints? Ist eine Iteration im Kreislauf ein Sprint? Oder finden mehrere Kreislaufiterationen innerhalb eines Sprints statt? Oder anders herum sogar mehrere Sprints innerhalb einer jeden Phase im Kreislauf?

Die vorläufige Antwort lautet wie so oft: Es kommt drauf an , sprich das Ganze hängt maßgeblich von der Komplexität des Prozesses / der Prozesse bzw. des Verbesserungsvorhabens ab. Aber gehen wir mal von einem typischen “mittelschweren” Vorhaben aus, das sich locker über 6 Monate hinziehen kann. Nach einigen Versuchen, die Sprint=>Kreislauf-Frage “top-down”, also vom Groben zum Feinen, zu diskutieren, mussten wir erstmal aufgeben: Wir kamen nicht so recht weiter, auch wenn unser schönes BPMN-Framework dabei recht schnell eine zentrale Rolle spielte . Nein, wir entschieden uns, “bottom-up” vorzugehen, was die Diskussion sehr schnell konkret werden ließ und sich am Ende als zielführender herausstellte (wie so oft).

Sprich: Wenn wir jetzt mal nur die Phase der Prozessumsetzung anschauen, wie verhält sich diese zu einem Sprint? In einem mittelschweren Vorhaben (3-6 Monate), ist die Konsequenz ganz klar: Die Prozessumsetzung kann sich über mehrere Sprints hinweg ziehen, denn ein Sprint sollte idealerweise 3 oder 4 Wochen dauern, jedenfalls nicht 6 Monate. Diesen Grundgedanken übertrugen wir auf andere Phasen im Kreislauf:

Das Verhältnis von Kreislaufphasen zu Sprints ist häufig 1:N.

OK, spinnen wir den Gedanken für die Prozessumsetzung mal weiter, was müssen wir tun, damit das klappt? Schließlich sind Sprints eine ziemlich abgegrenzte Sache, mit jeweils eigenem Planning etc. Die erste Challenge (neben vielen weiteren) besteht also darin, die Prozessumsetzung in Sprint-fähige Phasen einzuteilen, wir müssen das Ganze “schneiden”. Das wiederum brachte uns zu einer Diskussion, die vorerst ohne Konsens beendet werden musste:

Ist es für die Akzeptanz der betroffenen Prozessbeteiligten (”Process Participants”) besser, wenn mehrere kleine Prozessänderungen erfolgen, oder ist es besser, wenn nur eine große Prozessänderung erfolgt?

Eine interessante Frage, die man vielleicht im Forum diskutieren könnte. Ja klar, es kommt mal wieder drauf an, aber ich selbst tendiere eher zu vielen kleinen Änderungen, als zu einer großen, solange es nicht die Änderungen selbst sind, die wieder geändert werden (denn das führt ja dann zum “heute hü, morgen hott”-Gefühl).

Obwohl wir hier keinen Konsens hatten, konnten wir trotzdem über mögliche “Schnittmuster” für die Prozessumsetzung diskutieren, um diese in Sprints aufzuteilen. Spontan eingefallen sind uns drei Muster:

Parallele Prozess-Stränge: Mitunter findet ein Prozess durch mehrere gleichzeitig ablaufende “Stränge” statt, sodass man die einzelnen Stränge in jeweils eigenen Sprints umsetzen könnte. Ein Beispiel, das Martin Wieschollek hierführ nennen konnte, war die Einschleusung neuer Mitarbeiter, also aus dem HR-Bereich.

Vertikal schneiden: Prozesse lassen sich oft in Phasen aufteilen, also sequentielle Teilprozesse, wenn man so möchte. Beispielsweise Bestellprozesse. Je nach Zeit und “Erlaubnis” kann ich hoffentlich bald ein Projektbeispiel hierzu bringen. Jedenfalls lassen sich diese Phasen bzw. Teilprozesse auf Sprints verteilen, wobei natürlich sicher gestellt werden muss, dass die “neuen” Teilprozesse mit den “alten” Teilprozessen gekoppelt werden können, z.B. über technische Schnittstellen.

Horizontal schneiden: Ein anderer Ansatz wäre, den Prozess end-to-end im ersten Sprint umzusetzen, aber nur für einen bestimmten organisatorischen Bereich, z.B. eine Niederlassung, oder für ganz bestimmte interne oder externe Prozessbeteiligte.

Wir haben uns vorgenommen, in den kommenden Wochen für jede dieser drei Ideen ein Beispiel zu formulieren und das Ganze auf dieser Grundlage weiter zu diskutieren. Martin Bartonitz hat heute direkt mal vorgelegt:

Scrum-Rollen im BPM-Projekt?

Danach haben wir noch kurz die Rollenfrage andiskutiert, sind aber aufgrund des Zeitlimits nicht sehr weit gekommen. Hier trotzdem mal der aktuelle Stand:

Product Board: Hier werden in Scrum die strategischen Produktentscheidungen getroffen, die der Product Owner in User Stories ausformulieren muss. Der Horizont der Entscheidungen dieses Boards liegt oft bei ca. 6 Monaten. Wenn wir ein ähnliches Gremium für einen oder mehrere Prozesse überlegen, wäre das ein Process Board, dem die Führungskräfte angehören, die den Prozess ganz oder teilweise verantworten, was mit dem Problem der Prozess-Matrixorganisation zusammenhängt. In unserem BPMN-Buch heißen diese Rollen Process Manager. Falls der Prozess nur von einem Process Manager verantwortet wird, bestünde das Board eben nur aus einer Person. Wichtig: Hier wird unter einem Process Manager also wirklich ein Entscheider verstanden, nicht bloß ein Inhouse-Consultant oder Methodenspezialist, das ist viel mehr der Process Analyst (siehe unten).

Product Owner: Die Analogie, die am ehesten zum Product Owner passt, wäre der Process Analyst, zumal dieser als Einziger in der Lage wäre, aus den Soll-Prozessmodellen die notwendigen User Stories abzuleiten.

An dieser Stelle mussten wir aus Zeitgründen einen Cut machen, obwohl sich natürlich gerade bei den Rollen zigtausend weitere Fragen auftun (z.B. Aus welchen Mitgliedern besteht das Scrum-Team, wenn die Verbesserungsmaßnahme ganz oder teilweise aus Change Management, also nicht IT-Umsetzung, besteht? Wie verändert sich die Zusammensetzung des Teams über mehrere Sprints hinweg, z.B. zuerst mehr Entwickler, später mehr Change Manager?).

Aber wie schon gesagt: Unser Anspruch ist es nicht, unangreifbare Weisheiten zu postulieren. Wir wollen einfach nur unsere Überlegungen, Ideen etc. mitteilen, evtl. Hilfestellung und Anregungen dadurch liefern, und natürlich Feedback sammeln und Diskussionen führen. Jedes Workshop-Ergebnis soll, so gut es halt geht, ein Working Increment sein, aber mit Sicherheit nicht der Weisheit letzter Schluss

Vorschlag von Shapiro

Eines ist jedenfalls erfreulich: Endlich ist in der Breite angekommen, dass BPMN nicht zwangsläufig “zu kompliziert fürs Business” ist, sondern das sehr davon abhängt, wie man sie einsetzt. Man kann auch ganz einfache Modelle mit BPMN machen, und darum geht es bei den Klassen, die von Shapiro vorgestellt werden. Hierbei handelt es sich übrigens nicht um ein offizielles Zwischenergebnis der Finalization Task Force (FTF) der BPMN 2.0, der wir ja auch angehören. Insofern bleibt abzuwarten, ob und was genau von diesem Vorschlag in die Spec zur 2.0 wirklich eingehen wid.

Die Idee der Sub-Classes, oder auch “Subsets”, ist nicht neu. Sie wurde bereits von Bruce Silver in seinem Buch “BPMN Method and Style” aufgegriffen, und auch wir haben im camunda BPMN-Framework, das in unserem Praxishandbuch BPMN beschrieben wird, verschiedene Ebenen der Modellierung festgelegt. Es gibt aber zwei Aspekte an der aktuellen Diskussion bzw. an dem Glauben an die Subsets, der mich stört:

• Der Glaube, dass man die benötigten Symbole pauschalisieren könnte
• Der Glaube, dass eine Einschränkung der Symbole der Schlüssel für eine vereinfachte Modellierung ist

Zu Punkt 1: Auch wir empfehlen auf Ebene 1 unseres Frameworks eine bestimmte Symbolpalette, die der Empfehlung von Shapiro zumindest ähnelt (bei uns enthält die Palette zur Ebene 1 die Symbole von “Simple” und fast alle von “Descriptive”). Aber schon für Ebene 2 schreiben wir im Buch Folgendes:

Praxishandbuch BPMN, Abschnitt 4.6 Häufigkeit der Symbole in unseren BPDs auf Ebene 2 Für die Erstellung von Ebene-2-Modellen geben wir keine allgemeine Empfehlung zur Einschränkung der Symbolpalette. Der Grund ist einfach, dass es sehr stark von Ihrer Organisation und Ihren Bedürfnissen abhängt, welche Symbole auf Ebene 2 verwendet werden sollten. Es kann beispielsweise auch für ein rein fachliches Prozessmodell extrem wichtig sein, eine Transaktion mit den entsprechenden Kompensationspfaden auszumodellieren, wie wir sie in Kapitel 2 vorgestellt haben. Auch wenn wir davon ausgehen, dass viele von Ihnen das nie tun werden, haben wir doch genug Kunden in unterschiedlichen Branchen, für die genau dieses Thema absolut erfolgskritisch ist. Es gibt also kein einziges BPMN-Symbol, das man für die Verwendung auf Ebene 2 allgemeingültig ausschließen kann. Falls Sie die Symbolpalette auf dieser Ebene unbedingt einschränken wollen, müssen Sie diese Entscheidung selbst treffen. In der Abbildung haben wir als erste Orientierung einmal zusammengestellt, welche Symbole wir in unseren Projekten bislang mit welcher Häufigkeit eingesetzt haben. Wir haben auch die neuen Symbole der BPMN 2.0 aufgenommen. Weil die neue Version erst seit Kurzem als Entwurf verfügbar ist, konnten wir bislang kaum praktische Erfahrungen mit ihr sammeln. Deshalb ist die Darstellung in Bezug auf BPMN 2.0 unsere Einschätzung aus heutiger Sicht.

Insofern habe ich erstmal nichts dagegen, Vorschläge für die Einschränkung der Symbolpalette zu liefern. Aber sobald es um eine “operative” Modellierung geht, sollten dies wirklich unverbindliche Vorschläge sein, die es den Anwendern bewusst offen lassen, sie für sich anzupassen. Oder noch strikter formuliert: Ich glaube, dass die Unternehmen selbst entscheiden müssen, wie ihre jeweiligen Subsets aussehen sollten. Denn ich habe einfach viel zu oft erlebt, dass die Bedürfnisse bei den verschiedenen Firmen sehr sehr unterschiedlich sind, was die Präzision und “Schmerzgrenze” in der operativen Prozessmodellierung (also bei uns die Ebene 2) angeht.

Zum zweiten Punkt, und der ist fast noch wichtiger: Es reicht bei Weitem nicht, einfach die Symbolpalette einzuschränken. Es müssen viel mehr Entscheidungen getroffen werden, um BPMN zielgruppengerecht verwenden zu können, z.B.

• Zum Zweck und “Scope” des Prozessmodells auf den jeweiligen Ebenen: Wofür wird es gemacht? Wer ist der Betrachter? In welcher Projektphase? Was betrachten wir auf dieser Ebene, und was lassen wir weg (ich meine jetzt nicht Symbole, sondern konkrete Aspekte des Prozesses, z.B. Ausnahmen)?
• Zusammenhang zwischen den Ebenen: Wie komme ich von einer Ebene in die darunter liegende? Bestimmt nicht einfach über eine Teilprozessverfeinerung, das funktioniert nicht!
• Orchestrierung / Choreographie: Eine typische Frage bei BPMN ist ja immer wieder, ob “ich jetzt Pools nehme oder Lanes”. Die Antwort auf diese Frage kann nicht sein, dass man Pools “halt nimmt, um eine B2B-Zusammenarbeit darzustellen, also wenn es um verschiedene Firmen geht”. Das ist weder die Intention der BPMN, noch ermöglicht diese Pauschalisierung ein Business-IT-Alignment
• Naja, und noch diverse weitere Fragen…

Ich bin sehr gespannt, was es mit den DoDAF-Pattern auf sich hat, die Shapiro in seinem Webinar erwähnt. Diese Pattern sind m.E. einer der Schlüssel für eine erfolgreiche Arbeit mit BPMN. Leider ist dieses Thema im Webinar recht kurz gekommen, genauso wie die o.g. Fragen. Aber ich werde mal versuchen, sie mir anzuschauen, sofern ich ich sie bekomme.

So wie es aussieht, findet demnächst ein FTF Meeting in Deutschland statt. Wir freuen uns auf die Teilnahme und werden gerade dieses Thema besonders aufmerksam verfolgen, um so gut es geht mitzuhelfen, dass ein vernünftiger Pattern-Approach noch in die Spec aufgenommen wird.

BPMN 2.0 Poster

Gemeinsam mit Signavio haben wir für die deutsche Fassung auch die Möglichkeit geschaffen, sich eine gedruckte Fassung kostenlos schicken zu lassen.

Den Startschuss liefert  Bernd Rederlechner von T-Systems mit seinem Vortrag “Business Process Management – Chancen und Grenzen“. Natürlich können auch wir am BPM-Day nicht die Klappe halten, daher redet mein Kollege Jakob Freund danach über “BPMN 2.0 in der Praxis: Vom fachlichen Modell zum ausführbaren Prozess“. Dieser Vortrag gibt einen Einblick in die BPMN 2.0, aber vor allem aber auch in Methodik und Best Practices zur richtigen Anwendung der Notation. Anschließend habe ich zusammen mit Jörg Moldenhauer von der 1&1 Internet AG eine Session zu “BPMN in der Praxis: Der Roundtrip bei 1&1 mit Open Source Tools“. Hier sollen Praxiserfahrungen und Anwendbarkeit mit Open Source Tools im Vordergrund stehen. Weitere Werkzeuge stellt dann Hajo Normann in seinem Vortrag “BPMN 2.0 Werkzeuge im Vergleich: Oracle BPA & BPM / SOPERA BPM” vor, denn ohne Tools geht es ja leider auch nicht. Der letzte Vortrag des Tages steht aus organisatorischen Gründen seitens des Verlages leider noch nicht sicher fest. Ich freue mich schon sehr darauf und hoffe auf zahlreiche Besucher, interessante Diskussionen und Feedback.

Übrigens darf ich daneben auf der JAX auch mal wieder ein bisschen tiefer in die Technik abtauchen und nach Herzenslust Quellcode zeigen Daher am Dienstag, den 04.05.2010, auch nicht verpassen: Einführung in den JBoss ESB.

Ach ja, wo wir schon bei Konferenzen sind. Auf der OOP 2010 letzte Woche durften wir auch reden. Wer sich also erst mal ein Bild machen möchte, hier die Folien: http://www.slideshare.net/camunda/20100118-bpmn-20-auf-der-oop.

Aus dem Seminar: Geschäftsregeln im Kontext

Betriebswirtschaftlicher Teil

Aus dem Seminar: Prozesse und Regeln

IT-Teil

Aus dem Seminar: Einbettung von Rule Engines

Für wen geeignet?

Das Seminar ist ein kompakter, 1-tägiger Überblick zum Thema. Insofern ist es für Jeden interessant, er sich über Business Rules Management informieren will und verstehen will, was hinter den Konzepten steckt. Obwohl das Thema definitiv einen starken IT-Bezug hat, ist der IT-Teil nicht nur für Techniker verständlich. Anders herum ist der BWL-Teil zwar zum Teil auf “High-Level-Ebene”, weil es um den Zusammenhang zwischen den Strategien und den Geschäftsregeln eines Unternehmens geht, aber er ist dennoch konkret genug, dass sich auch Techniker nicht allzusehr langweilen sollten

Wir haben den Kurs jetzt einige Male inhouse durchgeführt und recht gutes Feedback bekommen. Falls jemand bestimmte Aspekte vermissen sollte, sind wir aber für jeden Hinweis dankbar!

Mehr Infos und die Anmeldung gibt es hier

Zertifikat: CBPP

Mein Kollege Bernd Rücker übrigens auch, und böse Zungen behaupten, er hätte in der Prüfung noch mehr Punkte gemacht als ich. Nagut, muss man akzeptieren .

Leider konnten wir an der offiziellen Verleihung in Zürich aus zeitlichen Gründen nicht teilnehmen (ironischerweise gab ich an diesem Tag ein BPM-Seminar an der Berner Fachhochschule, wo man als Gastdozent übrigens ganz hervorragend betreut wird).

Dass sie auch ohne uns stattfinden konnte, beweist das unten stehende Foto.

Und wie geht es jetzt weiter?

Die neuen Certified Professionals

Nun, das Ganze war ja “nur” eine Pilotprüfung auf Basis des aktuellen CBOK Version 2.0, wie er von der EABPM (Europa) und ABPMP (USA) gemeinsam veröffentlicht wurde.

Die ersten “produktiven” Prüfungen sollen, wenn alles klappt, noch im 2. Quartal in der Schweiz und auch in Deutschland starten. Wir sind gerade dabei, einen geeigneten Vorbereitungskurs zu entwickeln. Diesen muss man nicht zwingend belegen, aber er ist natürlich empfehlenswert.

Genaueres kann ich leider noch nicht mitteilen, aber sobald das möglich ist, wird man die Informationen hier finden

Falls noch jemand weitere gute BPM-Blogs kennt, bitte einfach diesen Artikel kommentieren…

Deutsch

• Allweyer, Thomas: Prof. Allweyer gehört m.E. zu den besten Autoren in D.A.CH., was BPM angeht. Mir gefällt auch seine kritische Haltung zur IT-Perspektive von BPM. Die Haltung ist nicht selten anzutreffen, aber er kann sie als Informatiker fundiert begründen, und reduziert sie nicht auf Phrasendrescherei wie “IT follow Business” oder “A fool with a tool is still a fool”.
• Bartonitz, Martin: In seinem SAPERION-Blog berichtet Martin rund um DMS-Themen, aber auch sehr viel über BPM. Er hat einige ausgezeichnete Artikel im BPM-Netzwerk veröffentlicht, der neueste behandelt top-aktuell den Status Quo der Standards und Methoden rund um BPM.
• Signavio: Das ist eigentlich ein Corporate Blog, wo vor allem Pressemitteilungen rund um den Modeler zu finden sind. Aber es kommt auch immer wieder zu fachlich interessanten Postings (z.B. der EPK-BPMN-Vergleich) und aktuell interessanten Hinweisen.
• Wieschollek, Martin: Ein Newcomer, könnte man sagen, und genau wie wir ein BPMN-Fan. In seinem Blog greift Martin u.a. das Thema BPM und Agile Projekte auf, dem wir uns ebenfalls verschrieben haben. Und er gewährt einen guten Einblick in den intalio Stack. Huch, er hat sogar eine ganz formidable Buch-Rezension geschrieben

Deutsch / Englisch

• BPMN.info: Diesen Blog betreiben wir in der Berliner BPM-Offensive. Leider finden wir alle zu wenig Zeit zum Bloggen dort, und in absehbarer Zeit wird die Domain auch anderweitig verwendet. Aber im Archiv gibt es bereits viele hilfreiche Artikel zu BPMN.
• Planet BPM: Eine Sammlung von BPM-Blogs aus Deutschland und der Welt, sehr hilfreich für den aktuellen Überblick zu neuen Postings.

Englisch

• Baeyens, Tom: OK, das ist nur was für jBPM-Fans, den Tom ist der jBPM project lead. Nichtsdestotrotz sind seine Postings fundiert und spannend, wenn man sich für die Open Source Engine interessiert.
• Kemsley, Sandy: Sandy ist eine kanadische BPM-Analystin und bloggt immer wieder interessante Erfahrungsberichte zu Konferenzen und Webinars, die zumindest ich sonst gar nicht wahrnehme. Sie stellt auch regelmäßig interessante Links zu anderen Seiten zusammen.
• Silver, Bruce: Bruce ist der BPMN-Guru in USA, und blogged wirklich hervorragende Fachartikel und Meinungs-Postings zum Thema.

Gut, soweit meine aktuellen Favoriten. Wie gesagt, bei Bedarf bitte per Kommentar ergänzen (siehe unten). Oh, und falls es bei der Gelegenheit mal ein Feedback zu diesem Blog hier (BPM-Guide) geben sollte, das würde mich natürlich auch sehr freuen

Jetzt warte ich erstmal drauf dass endlich mein Flieger nach München geht, dort haben wir heute unseren BPMN-Vortrag auf der OOP. Hoffentlich komm ich noch rechtzeitig ;-(

• “Das BPMS-Versprechen ist, dass das Business ‘mal eben selbst’ seine Prozesse anpassen kann, und sie dann auch direkt so technisch laufen. Das funktioniert aber nicht.”
• “BPMS sind zu schwer gewichtig. Meine Java-Leute könnten das Problem in kürzester Zeit mit einem simplen Hack lösen, aber nein, wir müssen den langwierigen Weg über das BPMS gehen.”
• “Das BPMS bringt mir nicht die Lösung. Ich brauche letzten Endes eine Applikation, eine Software, mit der ich in meinem Prozess bestimmte Dinge tun kann. Das BPMS bringt mir das nicht, es kann nur die Funktionen anderer Backend-Systeme aufrufen und über Workflows bereitstellen, aber das war’s.”

Natürlich gibt es noch weitere Kritikpunkte, aber das sind die drei, denen ich persönlich am häufigsten begegne, wenn ich mit BPMS-”Veteranen” spreche. (OK: Lassen wir jetzt mal die ganze ideologische “A fool with a tool is still a fool”-Geschichte rund um die methodischen Paradigmen von BPM beiseite, und konzentrieren uns auf diese akuten Hands-on-Probleme).

Was ist meine Antwort darauf? Die Leute haben recht!

Problem Nr. 1: Das Business kann seine Prozesse nicht selbst erstellen / anpassen.

Eine der großen Lügen unserer Zeit: “Kaufen Sie unser BPMS, und Sie werden endlich Ihre lästige IT los!”. Das hat nie funktioniert, zumindest nicht für Prozesse. Eine halbwegs komplexe Prozess-Applikation (nein, NICHT der Urlaubsantrag) lauffähig zu machen erfordert jede Menge technischer Maßnahmen, die ein Nicht-Techniker nicht durchführen kann. Egal ob er BPMN oder sonst etwas einsetzt. Das wird sich auch mit BPMN 2.0 nicht ändern.

Lösung Nr. 1a: Akzeptieren wir Prozessmodelle als das, was sie sind: Ein Kommunikationsinstrument!

Mit dieser Forderung mache ich “technische” Prozessmodelle nicht überflüssig, und ich stelle auch nicht den Sinn der Ausführbarkeit von BPMN 2.0 infrage. Im Gegenteil: Wir sind ganz vorn mit dabei, was dieses Thema angeht. Aber wir müssen lernen und akzeptieren, dass wir in unseren BPM-Projekten auch zukünftig IT’ler haben werden, mit denen wir reden müssen. Die Durchgängigkeit von BPMN erleichtert uns diese Kommunikation, aber sie macht den Dialog nicht überflüssig. Dank der Durchgängigkeit gelingt uns das Forward Engineering besser, auch der Roundtrip, und auch das KPI-Monitoring. Aber es wird nicht automatisiert. Und wir haben viel Arbeit vor uns, um diese Früchte zu ernten: Die Notation an sich reicht nicht aus, man braucht ein methodisches Framework für den effektiven Einsatz. Aber dann funktioniert es auch. Mehr dazu hier.

Lösung Nr. 1b: Konzentrieren wir uns auf die Bereiche, wo das Business direkten Einfluss nehmen kann !

Das sind ganz akut vor allem die Business Rules, sprich die Geschäftsregeln. Bei den Regeln haben wir hier und jetzt das Know how und das Tooling, um Anpassungen von Nicht-Technikern vornehmen zu lassen. Durch die Kombination von Business Rules Management und BPM, bzw. Rule Engines und Process Engines erreichen wir keine maximale, aber doch eine absolut nennenswerte Agilität in unserer Prozesslandschaft. Es gibt viel zu wenig Content zu diesem Thema, und ich werde demnächst mal etwas ausführlicher dazu bloggen. Bis dahin gibt es hier einen sehr groben Einführungspost, und in unserem Praxishandbuch BPMN greifen wir das Thema ebenfalls auf.

Problem Nr. 2: BPMS sind zu schwer gewichtig. Viele Aspekte lassen sich schlanker lösen.

Das stimmt definitiv, wir haben selbst diese Erfahrung schmerzhaft machen müssen. Brauche ich einen ESB und Web Service Calls, um eine Mail zu verschicken? Muss ich einen banalen Maskenfluss mit “Vor” und “Zurück” über eine Workflow Engine steuern? Lohnt sich ein Enterprise Portal, um ein Bestellformular anzubieten? Nein, das wäre alles Quatsch! Es gibt eine ganze Reihe von Anforderungen, für die ein BPMS und seine peripheren Komponenten einen extremen technischen Overhead erzeugen, sowohl in Bezug auf die Performance, als auch die Komplexität und somit erschwerte Entwicklung und Anpassung. Es gilt wie immer der alte Spruch: Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel.

Lösung Nr. 2: Wir nutzen einen flexiblen Technologie-Stack, der hybride Architekturen erlaubt

Wir sollten BPMS-Funktionen da einsetzen, wo ihre Kernstärken liegen: In der Ausführung technischer Prozessmodelle und in der Überwachung derselben. Wir müssen wegkommen von akademischen Architekturen und in der Lage sein, die Process Engine direkt und performant mit Backend-Komponenten zu koppeln, wo z.B. eine ESB / Web Service – Architektur einfach nur Overhead erzeugt. Wir müssen Applikationen bauen können, in denen Process Engines einen “Ablauf-Backbone” darstellen, aber ansonsten genau so gut Plain Development wie Java JSF oder was auch immer eingesetzt werden kann, um z.B. einfache GUIs zu erzeugen. Ein BPMS muss wieder eine schlanke, performante und 100%ig stabile Komponente sein, und nicht ein überdimensioniertes Schweizer Taschenmesser. Und es muss einsehbar sein: Wir können ein BPMS nicht performant, stabil und sicher in eine hybride Umgebung einbetten, wenn wir es mit einer Blackbox zu tun haben, die nur über hoffentlich wohldefinierte Schnittstellen nutzbar ist, und deren Eigenleben wir nicht kennen, geschweige denn anpassen können.

Problem Nr. 3: Das BPMS ist nicht die Lösung.

Das ist natürlich ein schwieriger Punkt, denn die Idee eines BPMS ist es ja gerade, neue Lösungen (Prozesse) auf der Grundlage vorhandener Lösungen (Backend-Assets) flexibler bauen zu können. Aber ich bin mir wirklich nicht sicher, wie weit man diese Entkopplung in der Realität wirklich treiben kann. Ich habe es jedenfalls sehr häufig erlebt, dass BPMS in diesem Kontext eher aus der Not heraus eingesetzt wurden, weil man die alten Assets aufgrund fehlenden Know hows gar nicht mehr effizient aus den alten Mainframes ziehen konnte. Am Ende kamen dann zigtausend feinstgranulare Services heraus, die auch mit dem schönsten Repository nicht mehr handlebar waren. Und natürlich immer haargenau so geschnitten waren, dass eine Wiederverwendbarkeit gar nicht möglich war.

OK, das muss nicht unbedingt so passieren. Aber eines ist wichtig: Wenn wir BPMS als das sehen, was sie sind, können wir damit Lösungen bauen, aber sie sind nicht die Lösung!

Lösung Nr. 3: Akzeptieren wir BPMS als Plattformen, und nicht als Produkte oder gar Lösungen. Und ziehen wir die Konsequenzen!

Ein BPMS an sich ist für das Business noch keine Lösung, genauso wenig, wie z.B. Java oder .NET eine Lösung ist. Die Lösungen entstehen erst auf Basis dieser Systeme. Das klingt banal, bedeutet aber viel: Wer soll denn die Lösung bauen? Das Business selbst? Das wird nicht funktionieren. Die IT des Unternehmens? Das funktioniert leider oft weniger, als viele hoffen. Vor allem, wenn das BPMS eine spezifische Kompetenz erfordert, weil der Lösungsbau auf Grundlage proprietärer Mechanismen funktioniert. Sprich, wenn man eine Spezialkompetenz für dieses eine BPMS aufbauen muss. Der Effekt ist häufig, dass die Unternehmen doch wieder von den BPMS-Herstellern oder ihren Partnern abhängig sind, und die teuren Consultants auch bei kleinen Problemen eingeflogen werden müssen.

Wenn ein Unternehmen also wirklich unabhängig werden will, braucht es eine BPM-Plattform (oder auch BPP), die keine proprietären Skills erfordert, sondern mit Hilfe weit verbreiteter Kompetenzen, z.B. Java, genutzt werden kann.

Fazit: BPMS der nächsten Generation

Ein guter Freund von mir hat vor einige Zeit gemutmaßt: “Ich glaube, dass die reinrassigen BPMS über kurz oder lang wieder verschwinden und sich lediglich als Komponenten von Applikationen präsentieren werden, die Geschäftslogik umsetzen und somit den direkten Mehrwert stiften.”

Ob es wirklich so kommen wird, wage ich heute noch nicht zu beurteilen, irgendwie klingt es ja sogar wie ein Schritt zurück.

An sich glaube ich aber durchaus an eine langfristig (!) grundlegende Veränderung des IT-Marktes, an deren Ende zwei wesentliche Segmente stehen werden:

• Nicht-IT-Unternehmen, deren strategische Kernkompetenz direkt in der Software abgebildet ist, die sie einsetzen.
• Nicht-IT-Unternehmen, bei denen das nicht der Fall ist.

Die erstgenannten brauchen eine maximale Kontrolle über ihre Software-Systeme (auch BPMS), und müssen prinzipiell völlig unabhängig von ihren IT-Anbietern in der Lage sein, diese zu warten und maßgeschneidert weiter zu entwickeln. Hier kommen technische Black-Box-Lösungen im Grunde nicht infrage.

Und die anderen machen SaaS.

OK, die beiden Szenarien können natürlich auch in einem Unternehmen prozessabhängig kombiniert vorkommen.

Schlussendlich aber werden sich die erfolgreichen “BPMS der nächsten Generation” deshalb durch folgende Merkmale auszeichnen:

• Sie bieten Funktionen, um Prozessmodelle sehr viel effektiver als früher für die Kommunikation zwischen Business und IT einzusetzen.
• Das Business erhält direktere Einflussmöglichkeiten, aber nicht über Prozessmodelle, sondern tangierende Themen wie Business Rules.
• Sie bedienen die Zielgruppe / Prozesse “Kernkompetenz in unserer IT” mit offenen und flexiblen On Premise – Plattformen, die Zielgruppe / Prozesse “Kernkompetenz nicht in unserer IT” hingegen mit SaaS.
• Sie sind als abgegrenzte BPMS-Produkte gar nicht mehr erkennbar, sondern gehen auf in anderen Produkten, offenen Plattformen, SaaS-Produkten oder sogar Beratungsprodukten.

OK, soweit mal meine spontane Einschätzung aus dem Bauch heraus

Aber ein Hinweis: Das ist natürlich auch deshalb meine / unsere Meinung, weil wir uns im Geschäftsmodell entsprechend positionieren. Auf der anderen Seite würden wir uns nicht entsprechend positionieren, wenn diese Überzeugung nicht aus unseren Erfahrungen und Beobachtungen heraus entstanden wäre