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).

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

Aus meiner Sicht das bisher spannendste Indiz für die Konvergenz der beiden BPM-Fraktionen und die damit verbundene Konsolidierung des Marktes. Jetzt sollte auch der letzte Process Execution – averse IT-follows-Business-Ideologe merken, wo die Reise hingeht

Erst vor kurzem hatte ich mir den Business Modeler der IBM angesehen, der in genau dasselbe Thema fällt. Ob der Coup von SAG und IDS auch operativ gelingen und zum Erfolg führen wird, kann man natürlich bezweifeln und als Außenstehender nicht wirklich seriös beurteilen.

Aber man kann trotzdem drüber diskutieren Und genau das hat Gero Decker von Signavio im BPM-Netzwerk angestoßen: Zum Forenbeitrag

Insofern möchte ich alle BPM-Guide-Leser einladen, sich an der Diskussion zu beteiligen…

Sondern es geht um den IBM Websphere Business Modeler. Hierbei handelt es sich um ein BPMA-Werkzeug, das also für die Modellierung, Dokumentation und Analyse von Geschäftsprozessen genutzt werden kann. Die Kenner “klassischer” BPMA-Werkzeuge wie ARIS & Co. rümpfen hier häufig spontan die Nase: “Was kann so eine Tekkie-Firma wie IBM schon leisten, um Organisatoren zufrieden zu stellen?”. Und ich muss gestehen, dass auch ich in dieser Hinsicht zunächst eher skeptisch war.

Ich will jetzt auch gar nicht ein Loblied auf dieses Tool anstimmen. Aber es hat mich tatsächlich etwas überrascht, weil es doch deutlich mehr Funktionen für BPMA besaß, als ich bei einem Modeler, der von einem BPMS-Hersteller gebaut wird, erwartet hätte. Ich habe es mir im Rahmen eines Workshops angesehen, der bei einem Kunden stattfand, der sich gerade im Evaluierungsprozess befindet. Für diesen Workshop hatten wir einen Kriterienkatalog erstellt, der viele Funktionen abfragte, die man von “klassischen” BPMA-Werkzeugen kennt (z.B. strukturiertes Repostory für die Modellierung, Darstellung und Verknüpfung von Aufbau- und Ablauforga, Hinterlegung und Auswertung fachlicher Kennzahlen etc.). Und ich war selbst erstaunt, wieviel davon im Business Modeler vorhanden war.

Jetzt gibt es viele Punkte, die man kritisch hinterfragen kann bzw. wo man mal viel tiefer einsteigen muss, zum Beispiel:

• Wie gutes funktioniert es tatsächlich? So ein Workshop ist ja auch recht kompakt, und über manche Punkte sind wir auch rein verbal gegangen. Um sich ein verlässliches Bild zu verschaffen, muss man aber das Produkt selbst testen. und ich meine jetzt wirklich persönlich selbst. Also nicht von jemandem zeigen lassen. Aber das geht nicht an einem Tag, und nicht in einer Gesprächsrunde. Insofern werden wir uns das gute Stück vermutlich demnächst mal bei uns im Headquarter zu Gemüte führen
• Bedienbarkeit für die relevanten Rollen? Der Modeler basiert auf Eclipse, was ich als alter Java-Fan natürlich kenne und schätze. Aber man merkt eben doch den technischen Background im Aufbau der Oberfläche etc., und es ist fraglich, wie hier die Akzeptanz auf Business-Seite aussieht ( => Differenzierte Customizing-Möglichkeiten? Hier bietet der Business Modeler nicht soviel, hatte ich den Eindruck)
• Der Modeler ist Teil eines Technologie Stacks, mit dem (wieder mal) das lang ersehnte Roundtripping versprochen wird. Hier bin ich ja extrem skeptisch. Nicht wegen der Vision an sich (sie wird Realität werden), aber weil einfach noch soviel zu tun ist. Es ist sicher eine wichtiges Element, dass der Modeler die Prozesse (vermutlich sauber und vollständig) nach BPEL exportiert, sodass sie im WID übernommen werden können. Und ich habe auch so ein paar Klassiker abgefragt, auf die ich durchaus zufrieden stellende Antworten erhalten hatte (z.B. zum Thema nachträgliche Anpassungen / Synchronisation, Reverse Engineering etc.). Aber die Technologie ist eben nur ein Drittel der Miete. Die anderen beiden Drittel sind die Modellierungsmethodik (und hier ist die Notation wie BPMN nur ein Baustein!) und die Befähigung und Motivation der erfolgskritischen Rollen. Und hier haben wir noch einen weiten Weg vor uns, durchaus auch im Tooling (Modellierungs-Pattern?). Und das wird leider definitiv viel zu häufig viel zu sehr unterschätzt. Grafische Diagramme nach BPEL bringen, ist noch das geringste Problem dabei.

Ja also wie gesagt, es gibt hier noch diverse Themen, über die man bzgl. des Modelers von IBM Gutes wie Schlechtes sagen kann (BPMN habe ich jetzt mal komplett ausgeklammert). Aber das würde den Rahmen dieses Posts total sprengen. Mir ging es jetzt erstmal nur darum festzustellen, dass so manch ein klassischer BPMA-Anbieter vielleicht doch nicht mehr ganz so selbstgefällig auf dem hohen Ross sitzen sollte – Der Markt bewegt sich

Und allgemein es ist spannend zu beobachten, wie der Konvergenztrend hin zum ganzheitlichen BPM auf der Tool-Ebene momentan stattfindet. Da ist IBM ja auch nur ein Player unter vielen, und der zugrundeliegende Ansatz (BPEL etc.) ebenfalls.

Denn als ich neulich im Zuge der Wochenendplanung die Zitty durchblätterte viel mir der kleine Cartoon zu unserer Linken in die Hände. Und mir drängte sich sofort der Vergleich zu Workflow-Engines auf, auch wenn dies aus sozial-psychologischer Sicht vielleicht bedenklich ist

Fragt man Projekte warum sie Workflow- bzw. Process-Engines selbst bauen möchten hört man häufig:

• “Wir haben nur ganz einfache Anforderungen, einen ganz simplem Zustandsautomat. Da ist eine Workflow-Engine Overkill.”
• “Wir müssen die Engine in die eigene Anwendung einbauen.”
• “Wir haben Produkt x evaluiert und es passt einfach nicht”

Klingt ja soweit auch ganz plausibel, oder? Ich möchte den Argumente jedoch ganz kurz ein paar Gedanken widmen:

Wir haben nur ganz einfache Anforderungen

Mit jedem eingesetzten Produkt oder Framework steigt natürlich die Komplexität. Auch ist die Lernkurve mancher Workflow-Engines nicht gerade flach, gar keine Frage. Ich habe es jedoch schon so oft gesehen, dass mit einem einfachen Zustandsautomaten gestartet wird, meist dann so irgendwie eine Entät/Tabelle pro “Prozessinstanz” mit einer Spalte, die den Zustand angibt. Denn Persistenz und eine Datenbank braucht man ja sowieso.

Aber Moment, wenn ich Wartezustände habe, brauche ich dann nicht auch Timeouts oder Eskalationen?

Oder möchte ich nicht vielleicht von einem Zustand in einen Folgezustand “gehen”, wobei ich eine Entscheidung treffen muss (also ein datenbasiertes exklusives Gateway in BPMN)?

Naja, ok, das bauen wir schon auch irgendwie in den eigenen Zustandsautomat ein. Die Softwareentwicklung hat ja auch vor der Existenz von Workflow-Engines funktioniert. Werkelt man also weiter vor sich hin, möchte man häufig die Prozesse flexibler haben. Also fix ein XML-Format definiert. Eventuell sogar dem Standard XPDL oder bald BPMN 2.0 bedient, aber eher nicht. Ist ja auch wieder zu komplex. Es soll nur bitte der (Produkt-) Manager nicht mit dem Wunsch nach grafischer Darstellung der Porzesse kommen! Wozu auch, XML ist doch eh prima lesbar.

Okay, geschafft. War doch ganz einfach. Und wir haben keine unnötigen Features in unserer Maschine

Aber wir haben eben leider auch manch anderes nicht unbedingt in unserer Maschine: Skalierbarkeit? Concurrency bedacht? Versionierung von Prozessen? …?

Brauchen wir doch auch nicht, wir haben ja auch nur einfache Anforderungen. Und das Produkt entwickelt sich ja auch nich weiter, wenn man erstmal Begehrlichkeiten nach Workflows geweckt hat? Oder vielleicht benutzt es mal der Kollege an einer anderen Stelle (Hurra, Wiederverwendung)? In meiner Projekterfahrung habe ich auf jeden Fall schon so viele Engines gesehen, die dann doch nach und nach aufgebohrt wurden/werden mussten und am Schluß auch ganz schön leistungsfähig waren. Und dabei ist es dann nicht nur um die Personentage der Entwicklung schade, sondern vor allem um die Wartung. Und im gegensatz zur Neuentwicklung macht die noch nicht mal Spaß.

Wir müssen die Engine in die eigene Anwendung integrieren

Soll die Engine in das eigene Produkt eingebaut werden gelten in der Tat andere Regeln. Viele BPM Produkte und Workflow-Engines sind hier wirklich ungeeignet, wenn auch nicht generell. Das man Integration mit der eigenen Anwendung nicht mit Webservices realisieren möchte, nun das verstehe ich gut. Auch kommen manche Engines als dicke Server daher, mit entsprechenden Installtions- und Hardware-Anforderungen. Und günstig sind die Produkte auch nicht, schon dreimal nicht wenn man sie ins eigene Produkt integriert und weiterverkaufen möchte.

Aber spätestens seit die Open Source Gemeine Process Engines entdeckt hat, gilt dieses Argument nicht mehr. Mit den verschiedenen Vertretern dieser Zunft (Beispielsweise JBoss jBPM, Nova Bonita oder Enhydra Shark) kann eine meist leichtgewichtige Java Engine in die eigene Anwendung problemlos integriert werden. Oft bieten die Engines entsprechend vielseitige Konfigurationsmöglichkeiten, so dass sie entsprechend dem eigenen Bedarf angepasst werden können. Teilweise kann auch die Workflow-Sprache noch angepasst oder erweitert werden.  Konsequent zu Ende gedacht ist dies aktuell auch in der JBoss Process Virtual Machine (PVM), die nur den grundlegenden Zustandsautomat definiert, und keine Sprache. Möchte man also tatsächlich eine eigene Engine bauen, könnte man dies zumindest als Grundlage nehmen um nicht das ganze Rad neu zu erfinden.

Wir haben x evaluiert, es passt nicht

Den Punkt habe ich reserviert, um mir ein bisschen Frust von der Seele zu schreiben Evaluieren heißt halt leider mehr, als einen Studi nen Tag ranzusetzen, der das dann auf Anhieb erst mal nicht zum Laufen bekommt. Ich entschuldige mich bei allen, die sich auf den Schlips getreten fühlen (aber wer trägt denn in der IT heute noch Schlips )! Ja, es ist leider wahr, dass gerade die Open Source Engines eine gewisse Einstiegshürde legen. Also mal eben nebenbei aufsetzen ist daher recht schwierig. Man muss sich also ein bisschen Zeit nehmen. Um einmal jBPM als Beispiel zu nehmen: Bisher hatte ich bei keinem Kunden in einem Workshop etwas gefunden, was mit jBPM nicht relativ einfach umgesetzt werden kann. Immerhin sind in die aktuelle Version einige Jahre an Reifeprozess und Erfahrung eingeflossen. Meist erlebt man schon nach einigen Minuten bei der ersten Frage ein “Ah ha”-Erlebnis beim Kunden: “So geht das also. Cool. Ist ja ganz einfach. Zum Glück haben wir das nicht selbst gebaut.”

Natürlich darf man den zweiten Teil des Satzes nicht vergessen: “Das muss man aber wissen”. Ja, stimmt. Da erfordern die Produkte eben leider doch ein bisschen Einarbeitung. Aber aus meiner Sicht ist die Zeit hier deutlich besser investiert als in der eigenen Engine. Denn

• Die Wartung erfolgt extern,
• Das Produkt wird weiter entwickelt,
• Man profitiert von der Erfahrung, die im Produkt steck,
• Man kann Support kaufen bzw. sich Internet-Foren bedienen und
• Man bekommt viele Features, die man zu Anfang vielleicht nicht braucht, später aber wichtig werden können.

Zu guter Letzt

Ich kann also nur immer sagen: Bitte, nicht selbst entwickeln! Die Engines bringen einiges mit, was man nicht mal so eben selbst entwickelt. Es ist die Lernkurve fast immer wert! Und diese Engine ist dann eben kein unkalkulierbares Risiko. Um in der Analogie des Comics vom Anfang zu bleiben: ich glaube sogar, dass es zukünftig für viele Anwendungen wichtiger wird, Prozessorientierung besser zu verinnerlichen. Dies würde vielen Anwendungen auch gut tun. Es ist also ein wichtiger Fortschritt, bei dem ich lieber dabei bin als zuzuschauen. Aber klar, muss ich ja sagen, ist ja mein Job

Kurz gesagt: In einer perfekten Welt wird die Engine also vielleicht sogar eine Art Selbstverständlichkeit. So wie OR-Mapper heute. Und es will doch auch keiner mehr ein zweites Hibernate entwicklen, oder?

P.S.

Sollte jemand anderer Meinung sein oder doch einen guten Grund parat haben, warum die Eigenetwicklug sein musste bzw. Sinn macht, lasst es mich wissen!

Das Problem vieler Firmen ist ja, dass sie eine Software zu Unterstützung ihres BPM suchen, jedoch nicht wirklich darüber im Bilde sind, was diese speziell für ihre Situation leisten muss. Hier werden aufgrund von Halbwissen viel zu früh Buzzwords und Standards als Muss-Kriterien definiert, ohne dass der tatsächliche Bedarf vorhanden ist. Kein Wunder, dass dann viele Anbieter versuchen, ihr Produkt an diesen Kriterien vorbei “zu manövrieren” und trotzdem einen Termin beim Kunden bekommen wollen – letzten Endes handeln sie in gutem Glauben und mitunter sogar im Interesse des Kunden, wenn dieser bestimmte Funktionen nur glaubt zu brauchen, sie aber nicht wirklich braucht. Auf der anderen Seite erschwert diese Geisteshaltung die Kommunikation zwischen Kunden und Anbietern natürlich ungeheuer. Meines Erachtes ist eine unzureichende Kompetenz in Bezug auf BPM die größte Hürde bei der Softwareauswahl.

Ich habe beim PSD versucht, die Leute für dieses Problem in einem etwas flappsigen Vortrag zu sensibilisieren – flappsig auch deshalb, weil ich am Nachmittag nochmal ein wenig Unterhaltung bieten wollte, nach dem umfangreichen Input zuvor. Leider war ich nicht so gut in Form und musste etwas zu viel Inhalt in zu kurzer Zeit transportieren – aber ich habe trotzdem kein schlechtes Feedback bekommen, ich denke, die Message ist angekommen. Für Interessierte kommen hier nochmal die Folien (leider ohne Tonspur).

Visio bietet keine Versionierung oder Mehrbenutzerfähigkeit
Wenn man Prozessmodelle überarbeitet, evtl. mit unterschiedlichen Modellierern, verliert man mit Visio-Dateien sehr schnell den Überblick. Wer hat wann welche Version des Prozessmodells erstellt? Wenn man ältere Versionen archivieren möchte, um evtl. darauf zurück zu greifen, muss man das alles von Hand machen, und auch hier entsteht sehr schnell ein großer Wildwuchs.

Visio bietet keine Hilfe bei der Verwaltung umfangreicher Prozessmodelle
Für Visio ist jedes Prozessmodell einfach ein Diagramm, nichts weiter. Wenn Sie z.B. eine Rolle anlegen, und diese Rolle in verschiedenen Prozessen vorkommt, würden Sie in Visio in jedem Diagramm einen Pool oder eine Lane (bei BPMN) für die Rolle anlegen. Wenn Sie die Rolle mal umbenennen (neuer Name für die Stelle o.ä.), müssten Sie jedes Diagramm von Hand öffnen und die Bezeichnung für die Rolle ändern. Dasselbe gilt für Aufgaben, die in unterschiedlichen Prozessen vorkommen, für Formulare und alles Mögliche. Ein solches System kann auf Dauer eigentlich gar nicht gepflegt werden.

Visio bietet keinerlei Unterstützung beim Business-IT-Alignment
Die ganze Frage, wie man jetzt fachliche Prozessmodelle mit technisch umgesetzten Prozessen koppeln könnte (z.B. im Rahmen der Konzeption, für die Dokumentation oder Aufbereitung von Kennzahlen, das Monitoring etc.) ist mit Visio vollständig überflüssig. Mit Visio können Sie in dieser Hinsicht ÜBERHAUPT nichts machen.

Mit Visio ist eine Hierarchisierung von Prozessmodellen nicht möglich
Visio kennt immer nur eine Betrachtungsebene, nämlich das aktuelle Diagramm. Dass manche Prozess-Schritte in eigenen Prozessen genauer beschrieben werden, ist mit Visio nicht möglich. Auch nicht die Arbeit mit Prozesslandkarten, aus denen auf konkrete Abläufe referenziert wird etc.

Mit Visio können Prozessmodelle nicht kommuniziert werden.
Natürlich können Sie jedem Mitarbeiter eine Visio Lizenz geben, und die Dateien rumschicken. Sie könnten auch das Diagramm als Bild exportieren, und auf den Intranet-Server legen. Aber beides ist ziemlich aufwendig uns muss jedes Mal händisch wiederholt werden, wenn sich ein Prozessmodell ändert. Und eine Navigation für den Anwender, oder gar eine Suchfunktion, über die diversen Prozessmodelle hinweg, ist nicht möglich. Das ist ein absoluter Killer für die Akzeptanz in der Belegschaft.

Fazit: Besser ein richtiges BPM-Tool
Es gibt noch mehr Argumente, aber diese 6 reichen eigentlich schon jeweils für sich allein aus, um sich gegen Visio zu entscheiden, wenn man nicht nur sporadisch mal einen simplen Prozess aufmalen will. Das Prozessmanagement, egal ob rein organisatorisch oder im Business-IT-Alignment, braucht wesentlich mehr, als Visio zu bieten hat. Sonst fliegen Ihnen die Modelle komplett um die Ohren (ich kenne da einige reale Erfahrungen von Firmen, die das schmerzhaft lernen mussten, aber die kann ich hier natürlich nicht nennen ).

Teilnehmen können Anwender, die bereits Erfahrungen mit einem BPM-Tool gesammelt haben, und alle, die sich für BPM-Tools interessieren. Indem wir die Aussagen der Anwender den Vorstellungen der Interessenten gegenüber stellen, wollen wir ein Bild davon bekommen, ob BPM-Tools die Erwartungen der Kunden erfüllen können, und wo ggf. die häufigsten Probleme liegen.

Jeder Teilnehmer erhält kostenlos die ausführliche Auswertung, und es gibt auch etwas zu gewinnen

Mehr Infos und der Link zur Teilnahme: http://www.BPM-Software.de

Vielen Dank für Ihre Hilfe

Vom intalio-CEO Ismael Ghalimi ist man ja schon eine gewisse Euphorie bei der Beschreibung der eigenen Erfolge gewöhnt. Das ist eigentlich auch völlig in Ordnung. Und ich glaube auch, dass er durchaus weiß, wovon er spricht bzw. bloggt. Umso gespannter war ich natürlich auf die o.g. Lösung, mit der laut Ismael nun endlich auch die “Business People” auf einfachste Weise ihre Prozesse selbst anpassen können. Genau genommen war das sogar der eigentliche Grund für den Zwischenstopp in Hannover. Und was passiert? Am Stand angekommen (ich hatte extra einen Termin vereinbart), erfahre ich, dass intalio die Business Edition noch nicht freigegeben hätte, und es deshalb auch nichts zum Präsentieren gibt. Na toll. Sowas kann zwar immer passieren, auch wenn ich mir natürlich gewünscht hätte, dass man dann auch den Termin im Vorfeld cancelt.

Aber es ist auch ein schönes Beispiel für ein ausgesprochen “proaktives” Marketing, das leider sehr häufig betrieben wird. Ein Spiel, das am Ende alle Anbieter mitspielen müssen, damit sie überhaupt noch im Markt wahrgenommen werden. Das Ergebnis sind häufig enttäuschte und deshalb grundsätzlich misstrauische Anwender. Und irgendwann heißt es dann “BPM (oder SOA oder XYZ) ist tot, bitte die nächste Sau durchs Dorf treiben!”. Wem hilft das?