die Frage von Martin B. ist natürlich essentiell für den Einwand von Martin W.: Wodurch ist ein “BPMS” überhaupt genau gekennzeichnet? Daran macht sich ja auch die Frage nach dem Overhead / der Schwergewichtigkeit fest.

Ich habe bei meinem Post zunächstan solche Produkte gedacht, die sich als “eierlegende Wollmilchsäue” der Prozessautomatisierung verstehen, hier also durchaus integration-centric und human-centric und noch diverse weitere Themen kombinieren.

Aber ich sehe auch durchaus Probleme bei den “kleinen” human-centric Workflow-Tools, z.B. wenn eine GUI zu bauen ist, die sich nicht durch das Tasklist-Paradigma abfackeln lässt, oder eben GUI-Aspekte beinhaltet, die nicht out-of-the-box im Workflow-Tool vorgehesen sind. Gerade rund um JavaScript kann man die tollsten Sachen erleben, wenn sich z.B. die Libs des Tools und dann die eigenen gegenseitig in Konflikt bringen.

Mein springender Punkt ist einfach, dass aus relativ geschlossenen BPM-Systemen eher offene, komponentenbasierte BPM-Plattformen werden müssen, damit diese zweckmäßiger und mit minimalem Overhead eingesetzt werden können, oder eben auch schlank in andere Produkte wie z.B. ein DMS, aber auch ein CRM o.ä. eingebaut werden können. Dann haben wir zwar wieder das Silo-Problem, aber ich glaube am Ende läuft es auf eine Kombination aus Silo-Workflows und dem darüber liegenden BPM-Layer hinaus.

Zur anderen Frage von Martin B.: Ja, das wird ja immer so gerne vergessen: Auch wenn die Fachabteilung selber Anpassungen vornehmen kann, müssen diese natürlich Integrationstests etc. durchlaufen, bevor sie tatsächlich produktiv gehen! Die Kunst besteht darin, dieses Testing so gut es geht zu automatisieren.

VG Jakob

Dein Post war schon klar verständlich Ich wollte nur darauf hinweisen, dass ein BPMS nicht immer zu viel Overhead hat, nicht immer zu schwergewichtig ist. Auch wenn die zu erledigende Aufgabe im ersten Moment recht klein erscheint. Man muss geschickt Ausloten wann und wie ein BPMS am besten eingesetzt werden kann, wenn es denn überhaupt sinnvoll ist.

Schöne Grüße
Martin

ich bin mir nicht sicher ob mein Blog Post so klar verständlich geworden ist, ehrlich gesagt. Mir geht es einfach darum nicht immer alles auf Teufel komm raus im BPMS abbilden zu wollen. Selbst wenn das BPMS schon längst beschafft wurde, kann das noch der falsche Ansatz sein. Man kann ja auch durchaus schlanke Ansätze in einer hybriden (z.B. Process Engine + JSF-Maskenflüsse) Architektur verwenden und diese TROTZDEM sauber, stabil und skalierbar gestalten.

Eine Process Engine, also den eigentlichen Core des BPMS, selber stricken, davon halte ich genauso wenig wie Du.

Viele Grüße

Jakob

bei Problem 1 & 3 stimme ich dir zu.
Bei Problem 2 habe ich teilweise Bauchschmerzen. Ich sehe es auch so, dass man ausgehend vom Problem überlegen sollte, ob der Einsatz eines BPM sinnvoll ist. Das ist auch meine Überzeugung. Dass sich die Einführung eines Portals + BPMS für einen einzigen Prozess nicht rechnet kann bestimmt auch jeder nachvollziehen. Aber spätestens bei der dritten oder vierten selbstentwickelten Applikation, die irgendwie eine selbstgestrickte Prozesssteuerung implementiert hat, hätten sich das Portal und das BPMS schon lange rentiert. Hier sagst du, dass man ein BPMS als “Ablauf-Backbone” verwenden soll. Wenn das auch so gemacht würde, wäre es klasse. Doch hierfür benötigt man dennoch wieder ein BPMS und muss argumentieren können warum. Die Einführung eines BPMS ist häufig eine strategische Entscheidung, die nicht nur im Zusammenhang mit einem einzelnen Problem gesehen werden darf. Ich habe es schon häufiger erlebt, wie auch aus einem einfachen “Maskenfluss mit “Vor” und “Zurück”” auf einmal doch komplexe Prozesse mit diverse Entscheidungen, Parallelverzweigungen und vielem mehr wurden. Dann braucht der Chef auf einmal unbedingt noch eine Überwachung der Abläufe. Und eine verantwortliche Person soll in die Arbeitsabläufe eingreifen können. Schneller als man gucken kann hat man sein eigenes BPMS gebaut, welches garantiert nicht so flexibel und stabil läuft, wie ein etabliertes System. Auch in der Anpassung der Prozessabläufe ist ein richtiges BPMS meistens einem selbstentwickeltem Programm einen Schritt voraus. Und wenn man dann ein zweites oder drittes System dieser Art gebaut hat, evtl. alle auch noch komplett unabhängig voneinander sind die Pflege und Wartung auch nicht mehr so einfach. Ggf. hat man dann je System einen Entwickler zu bezahlen, die sich mit ihren selbstgebauten Applikationen auskennen statt nur einen der sich mit dem zentralen BPMS auskennt.
Wie schon gesagt, ich bin auch nicht der Überzeugung, dass man immer ein BPMS benötigt. Aber diese Entscheidung sollte gut, ja sogar sehr gut überlegt sein wenn sich zu Beginn eines Projektes schon ein grober Prozess erkennen lässt. Sei dieser Prozess im ersten Augenblick auch noch so trivial.

Schöne Grüße
Martin