Die meisten Dinge fangen klein an. Es geht ja nur darum, einen Arbeitsauftrag von einem Mitarbeiter zum anderen zu senden. Das ist ja gar kein richtiger Prozess. OK, ein kleiner Prozess ist es schon, handelt es sich doch um in sich geschlossene Geschäftsfunktionen, von denen jede für sich wertschöpfend ist.

(Du hast keine Ahnung, wovon hier die Rede ist? Dann lies noch einmal unser letztes Antipattern!)

Also einverstanden, es ist ein Prozess und der gehört nicht eingebettet in die Fachlogik. Separation of concerns habe ich schließlich verstanden. Aber es ist ja nur ein Schritt und mehr wird da auch nicht kommen. Dafür ist eine Process Engine nun wirklich die sprichwörtliche Kanone, mit der auf Spatzen geschossen wird. Wir müssten erstmal eine Tool-Evaluierung durchführen. Aus der letzten Produktpräsentation des Anbieters mit den drei blauen Buchstaben erinnere mich an diese riesige BPM-Suite, sowas brauchen wir doch alles nicht.

Aber mehr brauchen wir doch nicht

Mitarbeiter verwalten wir im System sowieso schon, und eine eigene Inbox ist schnell implementiert. Den Fachkomponenten bieten wir eine API, mit der sie Aufgaben in diese Inbox stellen können. Damit können wir doch schon alles abbilden.

Klingt einfach, ausreichend und billig. Aber dabei bleibt es nicht. Wirklich nicht. Am Ende werden die Prozesse doch größer. Plötzlich gibt es Verzweigungen und Ausnahmen und unterschiedliche Prozessversionen. Dann kommen automatisierte Aufgaben und Monitoring-Anforderungen hinzu und plötzlich baut man eine eigene Process Engine. Das kann nicht gut gehen, glaub mir, ich habe es selbst versucht.

Zugegeben, die Verlockung ist groß. Die Scheu vor großen Suiten und noch größeren Investitionen ist historisch bedingt und nachvollziehbar. Zudem ist es, seien wir ehrlich, auch ein bisschen cool, so was zu bauen. Da freut sich das Techie-Herz in uns. Denken wir den oben geschilderten Anwendungsfall weiter, lässt sich gut eine Rules Engine einbinden (wir haben damals gleich selbst eine gebaut), vielleicht noch eine BPMN-2.0-Importfunktion und ein Diagramm-Renderer. Da kann man sich schon schön austoben (aber auch Zeit und Geld investieren).

Baust du noch oder kaufst du schon?

Aber hat nicht schon Dr. Wohland vom Institut für dynamikrobuste Höchstleistung gesagt, dass, wer Schalenkompetenz selbst produziert, Verschwendung betreibt? Und mal Hand auf’s Herz, bei wie vielen Unternehmen gehört die Entwicklung einer Process Engine zur Kernkompetenz? Und Zulieferer gibt es auch hinreichend viele. Die Strategie lautet also „Kaufen“!

Tatsächlich ist der Markt für Process Engines deutlich vielfältiger als vor zehn Jahren und die Reife der Tools hat auch ordentlich zugenommen. Damals war es tatsächlich schwieriger, ein geeignetes Produkt zu finden. Das ist heute anders. Es tummeln sich Anbieter jeder Form und Größe am Markt und für jedes Bedürfnis findet man ein passendes Tool. Von der eierlegenden Wollmilch-Suite, mit der sich neben der reinen Prozessausführung auch gleich noch der Rest der kompletten Systemlandschaft umsetzen lässt (Stichwort „Zero-Code“) bis hin zur schlanken OpenSource-Engine, die sich auf das Wesentliche konzentriert, nämlich die Prozesssteuerung, und die sich gut in bestehende Landschaften einbetten lässt.

(Stehst du gerade vor der Frage, welches Tool das passende ist, hilft dir vielleicht unsere Scorecard zur Tool-Evaluierung.)

Und um nochmal zur Wirtschaftlichkeitsbetrachtung zurückzukehren – die einzigen Unternehmen, deren Kernkompetenz die Herstellung einer Process-Engine ist, sind eben diese Anbieter. Es ist getrost davon auszugehen, dass die ihre Kernkompetenz so gut beherrschen, dass die Produkte besser sind, als das, was du selbst nebenbei produzieren könntest. Früher oder später wird es Anforderungen an die Process Engine geben, die du nicht mehr umsetzen kannst, weil nötiges Know-how und Erfahrung fehlen. Es ist zudem sehr wahrscheinlich, dass einer der Anbieter, der über das nötige Spezial-Know-how verfügt, das Problem schon gelöst hat. Und anstatt sich auf die Umsetzung fachlich wertschöpfender Anforderungen zu konzentrieren, versuchen deine Anwendungsentwickler nun, ein Tool weiterzuentwickeln, das von vornherein zum Scheitern verurteilt war. Dazu fällt mir das vielseitig einsetzbare Zitat des amerikanischen Ökonoms Peter Drucker ein, der gesagt hat: „Nothing is less productive than making more efficient, what should not have been done at all“.

tl;dr

Wenn du nicht gerade Produkthersteller einer Process Engine bist, dann verschwende besser keine Energie darauf, Probleme zu lösen, auf die du bei der Entwicklung einer eigenen Process Engine treffen würdest. Denn das haben andere schon getan und du würdest mit großer Wahrscheinlichkeit daran scheitern! Schau dich statt dessen am vielfältigen Markt um und finde das passende Tool für dich. Deine Energie investierst du lieber in die Umsetzung deiner Fachprozesse mit der ausgewählten Engine. Die Fachprozesse und deren Umsetzung sind nämlich deine Kernkompetenz!