Computerwoche is one of the most read magazines for IT-Professionals in Germany (I would actually assume it is THE most read one), and therefore I was quite happy I could contribute an article about BPM-Software to their last edition. Well, the article is in German, of course, but if you are brave enough you will download the PDF and try to read it anyway If not, here comes the core message of it: I divided BPM-Systems into the categories “pure play”, “embedded”, “saas” and “open source”. I consider that useful, although there can be overlappings such as an open source – BPMS that is embedded into a commercial product like an CRM or ERP. Then I thought about the future of commercial pure play BPMS and came to the result, that a shift of market shares is likeley, boosting the relevance of both Open Source BPM and SaaS BPM at the expense of “classical” on premise, closed source BPM products, which was also one of the reasons for our engagement in the Activiti project.

One of the main reasons behind that shift is that Open Source gives you more control over your technical BPM-Infrastructure and therefore less vendor-lock-in, especially if the OSS Stack does not require your Engineers to learn proprietary ways of implementing process applications, but let them do all that with their Java skillset plus BPMN (which is a standard and therefore not vendor specific). This makes OSS the perfect choice for supporting processes that implement your core competences and strategic USPs, while you can go for out-of-the-box SaaS-Solutions for processes that are “just” supporting your core processes, e.g. in HR, Accounting, Helpdesk or similar things (well, depends on your company, of course…). However, that OSS based BPM-strategy works only out if you do have a strong Java team in your company, no doubt about that. Well, I did not say that EVERY company is heading that way, but I am expecting or actually experiencing quite a few companies doing that already, e.g. based on JBoss jBPM.

So, the bottom line is: OSS BPM is not necessarily cheaper, but it makes you more independant, if you fulfill the prerequisites (<= qualified Java Resources).

• “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