Auf der Suche nach der besten BPMN-basierten Process Engine für prozessgesteuerte Anwendungen

Die digitale Transformation ist stark von der Prozessautomatisierung geprägt. Dazu hat sich zur Modellierung von Prozessen mittlerweile der weltweit anerkannte Standard BPMN (Business Process Model and Notation) etabliert. Die Notation erlaubt gleichzeitig die Ausführung derartiger Modelle durch BPMN-basierte Process Engines. Abgerundet wird dieses Paket bestehend aus BPMN als Notation und Process Engines zu deren Ausführung durch den Prozessgesteuerten Ansatz, einer Methodik zur Entwicklung vollständiger Prozessanwendungen inklusive einer dazu passenden Softwarearchitektur. Dieser Ansatz stellt die erfolgreiche Umsetzung von Prozessanwendungen einschließlich ihrer langfristigen Wartung sicher.

Der Prozessgesteuerte Ansatz, so ehrlich muss man sein, steht und fällt allerdings mit der Qualität der genutzten Process Engine. Also musste ich mich zu Beginn meiner Lehrtätigkeit an der Technischen Hochschule Ingolstadt (THI) im Jahre 2016 für eine Process Engine entscheiden. Es war also schon damals eine aufwändige Entscheidungsfindung notwendig, die schließlich in der Wahl einer Open Source-Lösung mündete. Seit 2016 setzte ich diese Process Engine also nun in meiner Lehre ein und es bestand wahrlich keine Not für einen Wechsel. Um es kurz zu sagen: Ich war mit meiner Wahl mehr als zufrieden. Allerdings wurde vom Hersteller meiner in der Lehre genutzten Engine die Weiterentwicklung aufgekündigt. Grund war, wie könnte es anders sein, der Wechsel in die Cloud. Die Parallelen zu SAP Process Orchestration sind offensichtlich. SAP Process Orchestration ist dabei die Ablauf- und Entwicklungsumgebung (inklusive Process Engine) für Prozessanwendungen, für die ich lange Jahre im Produktmanagement bei der SAP tätig war.

Durch diese Ankündigung hatte ich jedenfalls auf einmal ein Problem. Auch wenn der Wechsel nicht unmittelbar bevorsteht, so stört das Wissen darum und dass man auf einem „Auslaufmodell“ lehrt. Also stellte ich mir einen für meine Belange wichtigen Kriterienkatalog zusammen, aus dem ich im Rahmen dieses Artikels ein paar Punkte herausgreifen möchte. Die Liste meiner Kriterien sieht dabei wie folgt aus (Erläuterungen zu den einzelnen Punkten folgen im Anschluss):

  1. Hersteller muss seine Engine als eine Infrastrukturkomponente sehen
  2. Leichtgewichtiges Framework und keine schwergewichtige BPM-Suite
  3. Kein Vendor Lock-in
  4. Keine Konnektoren
  5. Enterprise-Qualitäten
  6. Geeignet für Universitäten, Hochschulen, aber auch für Startups und KMUs
  7. Niedrige Einstiegshürde (Ziel: Leicht zu installieren und gleich loslegen)
  8. Komplikationsloser Zugang
  9. Keine Abhängigkeit von einer bestimmten Programmiersprache
  10. Keine (zu hohen) Kosten
  11. Nutzt der Hersteller seine Engine selbst produktiv, z. B. für eigene Produkte und/oder Dienstleistungen oder ist der Hersteller ein Trockenschwimmer?
  12. Gute BPMN-Unterstützung und -Abdeckung
  13. Hohe Entwicklerproduktivität
  14. Komfortables Debugging

Gehen wir kurz auf die einzelnen Punkte ein.

Ich beginne mit der Forderung, dass der Hersteller seine Engine als eine Infrastrukturkomponente ansehen sollte. Warum ist dieser Punkt, der so wenig intuitiv ist, so entscheidend? Er ist deshalb so wichtig, weil ich vermeiden möchte, dass eine Process Engine zu einer eierlegenden Wollmilchsau verkommt. Doch alles der Reihe nach. Zunächst einmal muss geklärt werden, was ich unter einer Infrastrukturkomponente im Gegensatz zu eine Now-Code-/Low-Code-Plattform verstehe. Eine Infrastrukturkomponente zeichnet sich durch ihre Fokussierung auf genau eine Aufgabe aus. Diese Aufgabe muss sie dafür umso professioneller umsetzen. Ich nutze als Beispiel immer gerne Datenbanken. Datenbanken sind für mich der Klassiker einer Infrastrukturkomponente. Sie konzentrieren sich auf die transaktionale Verwaltung von Daten unter Verwendung einer standardisierten Sprache (SQL). That’s it. Mehr soll sie nicht tun. Dasselbe wünsche ich mir für Process Engines. Wie Datenbanken sollten sie sich auf eine Kernfunktionalität konzentrieren, nämlich auf die transaktionale Steuerung von Prozessabläufen basierend auf einer standardisierten Sprache (BPMN). That’s it. Was Datenbanken für Daten sind, sind Process Engines für Prozesse. So einfach ist das.

Das Ergebnis dieser Anforderung ist das Gegenteil von dem, was ich aktuell am Markt beobachte. Die Hersteller überbieten sich geradezu mit immer neuen exotischen Features fernab der Kernfunktionalität, die die jeweiligen Process Engines zu komplexen BPM-Suiten anwachsen lassen. Dies gilt es allerdings zu vermeiden (Anforderung 2). Warum? Weil Kunden sich zunehmend von dem jeweiligen Hersteller abhängig machen, dem berühmt berüchtigten Vendor Lock-in. Je mehr proprietäre Funktionalitäten des jeweiligen Herstellers genutzt werden, desto größer die Abhängigkeit. Ist die Abhängigkeit bei betriebswirtschaftlichen Standardlösungen noch zu rechtfertigen, sind sie für Entwicklungsumgebungen und Automatisierungsplattformen aber ein No-Go (Anforderung 3). Schließlich hängt die Wettbewerbsfähigkeit der Unternehmen im Zeitalter der digitalen Transformation maßgeblich von der Freiheit, Flexibilität und Anpassungsfähigkeit im Bereich der Softwareentwicklung ab. Sich aber genau in diesem sensiblen Bereich von einem Hersteller abhängig zu machen, ist für mich rational nicht mehr nachzuvollziehen. Man beraubt sich zukünftiger Alternativen und ist auf Gedeih und Verderb dem Hersteller ausgeliefert. Ein Beispiel, anhand dessen man diese Entwicklung sehr gut erkennen kann, ist die Nutzung von spezialisierten Verbindungen zu bestimmten Systemen wie SAP oder Salesforce. Diese sogenannten Konnektoren erlauben das schnelle Anbinden von Systemen direkt aus den BPMN-Modellen heraus. Was nach einer großartigen Idee klingt, zeigt sich bei genauerem Hinsehen als böser Bumerang. Durch deren Verwendung holt man sich komplexe Schnittstellen in die Prozesse. Während des Modellierens müssen diesen Schnittstellen konkret Daten zu deren Aufruf zugeordnet werden, das sogenannte „Mapping“. Nur: Dieses Mapping ist eine klassische Integrationsanforderung und hat in einer Process Engine nichts verloren. Aus diesem Grund habe ich den Verzicht auf Konnektoren explizit in meine Liste aufgenommen (Anforderung 4).

Anforderung 5 adressiert die Fähigkeit einer Process Engine, im anspruchsvollen Unternehmenskontext eingesetzt werden zu können. Schließlich wollen wir komplexe Prozessanwendungen entwickeln und keine Micky Maus-Prozesse umsetzen. Von daher muss die Engine natürlich Enterprise-Qualitäten wie beispielsweise Zuverlässigkeit, Verfügbarkeit, Performance, Sicherheit und Skalierbarkeit genügen. Idealerweise ist sie „cloud-ready“.

Anforderung 6, also die Eignung der Process Engine für Universitäten, Hochschulen, aber auch für Startups und KMUs, kann als große Klammer für die Anforderungen 7 (niedrige Einstiegshürde), 8 (komplikationsloser Zugang), 9 (Programmiersprachenunabhängigkeit) und 10 (keine zu hohen Kosten) gesehen werden. Ich habe damit insbesondere die Eignung der Engine für Experimentier- und Proof-of-Concept-Szenarien im Kopf. Aber auch Startups und Unternehmen mit nur kleinem Budget soll der Zugang zu DER Schlüsseltechnologie der digitalen Transformation ermöglicht werden, um damit viele innovative Geschäftsmodelle am Markt ausprobieren zu können. Diese Wege werden durch schwerfällige und dabei gleichzeitig sündhaft teure BPM-Suiten verhindert. Daher liegen mir die genannten Anforderungen besonders am Herzen. Wenn ich gerade an meine Studierenden denke, so sollen sie mit einem Klick die Engine runterladen und nach dem Auspacken einer ZIP-Datei sofort mit dem Modellieren und Ausführen ihrer Prozesse beginnen können (Anforderung 7 und 8). Bitte keine Registrierung und ein Tag später steht der Vertriebler auf der Matte, um einen Deal abzuschließen. Auch nicht viel besser sind spezielle Verträge, die man als Ausbildungsstätte abschließen kann und den uneingeschränkten Zugriff auf die Software eröffnet. Das alles will ich nicht. Außerdem will ich mich bei der Wahl der Programmiersprache nicht einschränken lassen (Anforderung 9) und natürlich muss die Engine auch von der finanziellen Seite her stemmbar sein (Anforderung 10). Sechsstellige Beträge, wie sie teilweise aufgerufen werden, sind nicht kompatibel zu dem Budget kleiner und mittelständischer Unternehmen sowie Startups. Natürlich sollen die Hersteller von Process Engines gutes Geld verdienen. Aber es gibt sicherlich kreativere Wege, wie sich auch KMUs und Startups Process Engines leisten können. Mir tut es persönlich weh, wenn eine gute Geschäftsidee einzig daran scheitert, weil ein Hersteller auf seine üppigen Preise besteht. So wird ein potenziell lukrativer Markt für neue Geschäftsideen basierend auf Prozessautomatisierung im Keim erstickt.

Ein Aspekt bei der Bewertung von Process Engines ist die Nutzung der Engine und der dazugehörigen Entwicklungsumgebung durch den Hersteller selbst (Anforderung 11). Im Englischen gibt es dafür den herrlichen Ausdruck „Eat your own dog food“. Wie soll ich einem Anbieter vertrauen, der sein eigenes Produkt nicht einsetzt? Ergibt für mich keinen Sinn. Dieser Hersteller wird stets auf das Feedback seiner Kunden angewiesen sein, wie er das Produkt weiterentwickeln soll. Auf der anderen Seite hat der Eigennutzer einen intrinsischen Ansporn, das Produkt zu verbessern, da er ja selbst als erster davon profitiert. Diesen Sachverhalt merkt man einer Process Engine samt zugehöriger Entwicklungsumgebung deutlich an. Von daher ist dieser Aspekt tatsächlich eminent wichtig.

Schließlich muss die Process Engine eine sehr gute BPMN-Abdeckung aufweisen (Anforderung 12) und eine signifikante Steigerung der Entwicklerproduktivität gewährleisten (Anforderung 13). Zur Entwicklerproduktivität zähle ich zum einen die Produktivität bei der erstmaligen Erstellung einer Prozessanwendung, zum anderen natürlich die ständige Weiterentwicklung durch Erweiterungen, Änderungen, Bugfixes, Anpassungen bei Releasewechseln, kurz alles, was im Laufe eines Software-Lebens an Arbeiten anfällt. Dabei ist die Pflege für mich von der Priorität her bedeutsamer als die Erstimplementierung, da die Pflege ständig stattfindet, die Erstimplementierung, wie der Name schon ausdruckt, aber nur einmalig. Hier ist grundsätzlich Vorsicht geboten, da Hersteller in ihrer Werbung primär die Schnelligkeit bei der Erstellung neuer Lösungen hervorheben. Dabei verschlingt die kontinuierliche Pflege über die Gesamtlaufzeit der Software betrachtet sehr viel mehr Geld. Folglich ist der Pflege von Prozessanwendungen bei der Auswahl einer Process Engine eine wesentlich kritischere Betrachtung einzuräumen.

Last but not least ist das zeiteffiziente Auffinden von Fehlern insbesondere in Produktivumgebungen für den Betrieb von Prozessanwendungen durch bestmögliche Debugging-Unterstützung überlebenswichtig (Anforderung 14). Gerade dieser Punkt ist bei der Nutzung von Aufrufaktivitäten und Kollaborationsdiagrammen in BPMN für mich von entscheidender Bedeutung, zumal der Prozessgesteuerte Ansatz deren intensive Nutzung empfiehlt. Denn ich muss in Fehlersituationen oft unter hohem Zeitdruck in die Szenarien eintauchen und erkennen können, wie eine spezielle Fehlersituation im Prozessablauf entstanden ist. Folglich muss ich ausgehend vom fehlerhaften Zustand schrittweise rückwärts durch meinen Prozess steppen können. Eine Anforderung, an der die meisten Engines und Entwicklungsumgebungen scheitern.

Soweit also die Erklärung einiger meiner für wichtig erachteten Aspekte, die ich bei der Auswahl einer Process Engine heranziehe. Ausgestattet mit dieser Liste begab ich mich also auf die Suche. Und ich habe mir wahrlich SEHR VIELE Engines angesehen. Sie hier alle aufzuführen, würde den Rahmen dieses Artikels sprengen. Ich kann aber verraten, dass letztendlich nur eine einzige Engine in meinem Netz hängen blieb: Der ProcessCube® von 5Minds. Diese Engine erfüllt, so unfassbar es klingt, tatsächlich alle meine obigen Anforderungen, wobei die BPMN-Abdeckung noch ausbaufähig ist. Allerdings werden auch hier die wesentlichen Lücken bis zum Release 2024.1 (geplant für Februar 2024) geschlossen, so dass für mich kein Wunsch mehr offenbleibt. Das ist schon eine beeindruckende Leistung! Dabei sticht Anforderung 14 besonders heraus: Ich habe wirklich noch keine Engine gesehen, bei der die Fehleranalyse so einfach wie beim ProcessCube® ist. Wie spielerisch der Entwickler hier die Szenarien rückwärts durchlaufen kann, sucht ihresgleichen. Egal ob Aufrufaktivitäten genutzt oder ob Nachrichten verschickt wurden, man kann jederzeit zum Aufrufer oder zum Versender navigieren und sich die Situation von Variablen dort anzeigen lassen. Das hat mich tatsächlich schwer beeindruckt und begründet wohl meine Faszination für diese Lösung. Tatsächlich repräsentiert der ProcessCube® genau das, was ich unter eine Process Engine verstehe und das dahinterstehende Unternehmen 5Minds lebt mit ihrem Angebot auch genau diesen Spirit vor.

Soweit also einige Einblicke in meine Vorgehensweise zur Suche „meiner“ Process Engine. Meine Studierenden können sich jedenfalls ab dem nächsten Wintersemester (Beginn 10/2023) auf die Arbeit mit einer modernen BPMN-Engine freuen, die auf der Höhe der Zeit angekommen ist.

Ich beende an dieser Stelle meinen Artikel und höre mir jetzt, passend zur Botschaft meines Beitrags, eine großartige Ballade von Survivor mit dem vielsagenden Titel „The search is over“ an. Gänsehaut ist da garantiert 😉.

Prozessautomatisierung im Gesundheitswesen

Die neueste Folge 79 des Podcasts „State of Process Automation“ von Christoph Pacher beleuchtet die Prozessoptimierungspotenziale im Gesundheitswesen. Der sehr sympathische Gast Dr. Ansgar Hörtemöller berichtet hochkompetent über Potenziale, die prozesstechnisch im Gesundheitswesen gehoben werden können. Sehr spannend!

Im Podcast wird auch ein sinnvoller Einsatz von Process Mining zur Identifikation der effizientesten Varianten von Prozessen für bestimmte Krankheitsbilder erläutert (ja, ich kann mich auch lobend über Process Mining äußern 😉). Dr. Hörtemöller bezeichnet es als die Suche nach „den Trampelpfaden“, in dem die derzeitigen Abläufe auf Basis digitaler Spuren mithilfe von Process Mining analysiert wurden (ab ca. Minute 16:15). Anschließend folgt das bekannte Loblied auf Process Mining.

Was dadurch allerdings auch deutlich wird: Es handelt sich bei diesen Beispielen einmal mehr um Szenarien für die Digitalisierung und NICHT für die digitale Transformation, wie die Folge wieder einmal angekündigt wurde (siehe die Ankündigung auf LinkedIn hier). Die Prozesse wurden auch nicht neu gedacht (siehe auch hier die Ankündigung zur Folge), sondern im Sinne der Digitalisierung evolutionär weiterentwickelt.

Unglücklicherweise nutzt Hr. Dr. Hörtemöller den prozessgesteuerten Ansatz nicht zur Implementierung der verbesserten Prozesse, was man aus seiner Bemerkung bei Minute 26:20 entnehmen kann. Er sagt:

Und wenn man dann einen kleinen Teilprozessschritt verändert hat, kann man mit Process Mining ja zu jeder Zeit den Prozessschritt erneut überprüfen und kann sehen, diese kleine Veränderung, wie groß die Auswirkungen sind.

Bei Einsatz des prozessgesteuerten Ansatzes benötigt man bekanntlich kein Process Mining mehr. Die Kliniken hätten somit die Chance, noch mehr Transparenz in ihre Abläufe zu bekommen (besser, als jedes Process Mining-Tool es jemals könnte) und dabei gleichzeitig die kostspielige Nutzung von Process Mining sukzessive zu reduzieren.

Leider werden in dem Podcast auch keine Zahlen bezüglich der Kosten der angesprochenen Projekte genannt. Was hat denn der Einsatz von Process Mining und die Umsetzung der Projekte konkret gekostet? Vielleicht kann der Moderator, Christoph Pacher, zukünftig hier auch mal konkreter nachfragen. Meiner Meinung nach werden die Kosten des Einsatzes von Process Mining viel zu wenig thematisiert. Ansonsten eine tolle Folge, die ich sehr inspirierend fand! Mehr davon!

Neuer Podcast live

In Zusammenarbeit mit Bots&People ist ein neuer, hoffentlich für Euch interessanter Podcast zur Nutzung des Prozessgesteuerten Ansatzes entstanden. Neben der obligatorischen Begriffsdefinition zwischen Digitalisierung und digitaler Transformation (siehe dazu auch meinen Artikel hier), diskutiere ich mit der Moderatorin Louise Kuehns die konkreten Auswirkungen des Ansatzes auf sowohl etablierte Unternehmen als auch auf Startups. Gerade für Startups bietet der Prozessgesteuerte Ansatz enorme Chancen bei der Gestaltung der digitalen Transformation. Alle Details nachzuhören im besagten Podcast, den Ihr über diesen Link erreichen könnt. Viel Spaß beim Anhören!

10 Irrtümer der digitalen Transformation

Am Wochenende war es mal wieder soweit: Ein neuer Podcast mit dem Titel „10 Gründe, warum Unternehmen bei ihrer digitalen Transformation in einer Sackgasse landen“ wurde auf der Plattform „The State of Process Automation“ von Christoph Pacher veröffentlicht.

Darin räume ich nicht nur mit ein paar Mythen zu Process Mining, Robotic Process Automation oder Microservices auf, sondern gebe auch eine Einschätzung zu einer idealen Low-Code-Plattform ab. Darüber hinaus möchte ich nicht nur die Finger in die Wunden legen, sondern auch einen Weg aus den vielen Sackgassen aufzeigen.

Meine persönliche Highlight-Liste der Anhaltspunkte, anhand derer man erkennen kann, dass man bei der digitalen Transformation auf dem Holzweg ist, liest sich dabei wie folgt:

  1. Ihr setzt BPMN nicht oder falsch ein
  2. Ihr setzt keine BPMN-basierte Process Engine ein oder ihr setzt sie falsch ein
  3. Ihr programmiert Eure Prozesse
  4. Ihr kauft Software zur Lösung von Problemen
  5. Ihr setzt Robotic Process Automation (RPA) ein und plant dessen Rückbau nicht ein
  6. Ihr nutzt Ereignisse zur Verknüpfung von Microservices zu Prozessen
  7. Ihr setzt die (falsche) No-Code/Low-Code-Plattformen ein (im Gegensatz zum Einsatz einer Infrastrukturkomponente)
  8. Ihr setzt auf Citizen Developer als Lösung des IT-Fachkräftemangels
  9. Ihr setzt Process Mining ein
  10. Bei Personal-Fluktuation (z.B. Entwickler, SW-Architekt) verschwindet das Wissen mit und lässt sich nicht sofort ersetzen

Wichtig: Es handelt sich NICHT um eine Liste für die Digitalisierung, sondern um die Liste für die digitale Transformation. Den Unterschied habe ich ja in einem Artikel auf dieser Webseite schon erklärt. In der Podcast-Folge gehe ich zudem auf einen weiteren Anhaltspunkt ein, der hier aber nicht veröffentlicht werden soll. Hört daher in den Podcast rein, den Ihr hier (Folge 65) finden könnt.

Viel Spaß beim Anhören!

Podcast-Ankündigung

Ich möchte Sie hiermit auf einen Podcast aufmerksam machen, der am Sonntag, den 06.03.2022 veröffentlicht wird.


Christoph Pacher, der Betreiber der Podcast-Reihe The State of Process Automation, hat mich nach meiner Meinung zu den Folgen der Digitalisierung bzw. der digitalen Transformation befragt. In dem Podcast erkläre ich, warum uns die eigentliche Disruption durch die digitale Transformation erst noch bevorsteht: Die Disruption der IT-Abteilungen, also einem Bereich, von dem man es am wenigsten erwartet hätte.

Wir besprechen die Bedeutung der Handlungsfähigkeit der IT für die Zukunftsfähigkeit von Unternehmen und natürlich darf der Prozessgesteuerte Ansatz als Lösungsoption in diesem Zusammenhang nicht unerwähnt bleiben.

Seien Sie also gespannt 😉

PiDiArtify – Die bessere Alternative zu aktuellen Trends in der Digitalisierung bzw. digitalen Transformation

Wer meine Blog-Beiträge und Artikel gelesen hat, weiß um meine Kritik an einigen aktuellen Entwicklungen in der Digitalisierung bzw. digitalen Transformation (zum Unterschied zwischen Digitalisierung und digitalen Transformation siehe meinen Artikel hier). Die Hauptkritikpunkte habe ich in meinem Moral Hazard-Artikel zusammengefasst. Und wenn man denkt, es könnte nicht mehr schlimmer kommen, tritt genau das ein. Auslöser für diesen Blog-Beitrag und meiner Entscheidung, mich mit Entschiedenheit von einigen neuen Trends der Digitalisierung/digitalen Transformation zu distanzieren, war die Keynote von SAP CTO und Mitglied des Vorstands der SAP SE Jürgen Müller anlässlich der SAP TechEd 2021, die man sich hier auch nochmal in Ruhe ansehen kann.

Nun sind No-Code- bzw. Low-Code-Plattformen wahrlich nichts Neues. Doch die Meinung und Aussage von Hrn. Müller ab Minute 36:46 nach der Demo zu SAP‘s neuer No-Code-Plattform SAP AppGyver kann ich so weder teilen noch gutheißen. Ich zitiere wörtlich:

„Actually I hope that some of this can remove some of the inequality in the world we talked earlier about. Just think about it: SAP alone has more than 230 million end users of our cloud applications. And there are a lot more when you include our on-premise systems. And now imagine that we can show all those end users a path to becoming a citizen developer. I’m already looking forward to seeing someone, may be an hourly worker, and she or he extends an SAP-system, for example with SAP AppGyver. This can unlock a new order of magnitude of value creation: for that individual person, of course, but also for society as a whole. And that actually can help closing the skill gap we have, too.“

Frei übersetzt (mit Unterstützung von DeepL):

“Ich hoffe sogar, dass dadurch ein Teil der Ungleichheit in der Welt, über die wir vorhin gesprochen haben, beseitigt werden kann. Denken Sie einfach mal darüber nach: Allein bei SAP gibt es mehr als 230 Millionen Endnutzer unserer Cloud-Anwendungen. Und es sind noch viel mehr, wenn Sie unsere On-Premise-Systeme mit einbeziehen. Und nun stellen Sie sich vor, dass wir all diesen Endnutzern den Weg zum Citizen Developer zeigen können. Ich freue mich schon darauf, wenn ich jemanden sehe, vielleicht einen Stundenarbeiter, der ein SAP-System erweitert, zum Beispiel mit SAP AppGyver. Das kann eine neue Größenordnung der Wertschöpfung freisetzen: für die einzelne Person natürlich, aber auch für die Gesellschaft als Ganzes. Und das kann tatsächlich auch dazu beitragen, die Qualifikationslücke zu schließen, die wir haben.”

Genau das, was hier angedeutet wird, verstehe ich NICHT unter Digitalisierung und digitaler Transformation. Es ist für mich tatsächlich das genaue Gegenteil!

Konkret: Sollten die Endnutzer nun, wie vorgeschlagen, in wirklich signifikanter Zahl anfangen, Erweiterungen zu ihren geschäftskritischen Anwendungen zu bauen, so ist dies der wahrgewordene Albtraum jeder IT-Abteilung! Eine unüberschaubare Zahl von Kleinstanwendungen mit Zugriff auf hochkritische Backend-Systeme – unvorstellbar. Unzählige ungelöste Fragen in Bezug auf Sicherheit, Last, Performance, Stabilität, Wartbarkeit, Abhängigkeiten zwischen Systemen, usw.

Sicherlich ist es wünschenswert, die Fachexperten mehr in die Ausgestaltung der Geschäftsprozesse mit einzubinden, Agilität ist ebenfalls sehr wichtig, ABER: Dieser Ansatz dazu kann es nun wirklich nicht sein! Und dass damit die Qualifikationslücke geschlossen werden soll, halte ich für Wunschdenken. Im Gegenteil: Es werden mehr IT-Fachkräfte benötigt, um diesen Wildwuchs später kontrollieren zu können. Hier wird in den Unternehmen eine tickende Zeitbombe scharf geschaltet, die in der völligen IT-Handlungsunfähigkeit münden kann. Genau das können sich Unternehmen aktuell in der Digitalisierung bzw. digitalen Transformation nicht leisten!

Kritik muss immer sachlich sein und vor allem sollte man eine bessere Alternative anbieten können. Mein Gegenvorschlag liegt in einer qualitativ hochwertigen und nachhaltigen Umsetzung von fachlich-getriebenen Geschäftsinnovationen. Diesen Weg zur digitalen Selbstbestimmung und einer neuen Transformation habe ich mittlerweile in unzähligen Büchern, Artikeln, Blog-Beiträgen und auch Online-Seminaren veröffentlicht. Und damit jeder diese Methodik erkennen und zuordnen kann, haben wir ihr einen Namen gegeben: PiDiArtify!

Ich möchte an dieser Stelle auf die neu gegründete, zugehörige PiDiArtify-Initiative hinweisen, in der wir, neben meinen Artikeln und Blog-Beiträgen, über PiDiArtify berichten und unsere Vorstellungen dieser neuen Qualität erklären werden. “Wir” bedeutet in diesem Zusammenhang meine Partner und ich bei 730pm, unserem neu gegründeten Unternehmen mit einer klaren Mission: Hilfe zur Selbsthilfe bei der neuen digitalen Transformation mit PiDiArtify.

Wir suchen Gleichgesinnte, die sich mit den Zielen von PiDiArtify identifizieren können und die zugrundeliegenden Ideen für eine bessere und nachhaltigere digitale Transformation auch weiterverbreiten möchten. Das erste Treffen der Initiative findet online am 28.01.2022 um 15:30 Uhr statt. Zur Teilnahme genügt die Anmeldung zum Newsletter der Initiative unter https://www.pidiartify.de/newsletter/. Ich freue mich auf Ihre Mitarbeit!

Unterschiedliches Verständnis von Digitaler Transformation anhand zweier Beispiele: SAP und MID

In meinem Artikel mit dem Titel „Digitalisierung vs. Digitale Transformation: Warum Digitalisierung nicht genügt“ bin ich auf mein Verständnis eingegangen, was ich unter Digitalisierung bzw. digitaler Transformation konkret verstehe. Das ist natürlich nur meine Sicht der Dinge, denn das Verständnis darüber kann sehr weit auseinanderliegen, wie ich an zwei konkreten Beispielen verdeutlichen möchte. Das erste Beispiel stammt aus einem Newsletter, den ich vorgestern (15.12.2021) in meiner Email-Box fand. Er stammt von der SAP SE und kündigt einen vielversprechenden Artikel mit dem Titel „So treibt die Felix Schoeller Group mit SAP und der Telekom die digitale Transformation voran“ an. Das zweite Beispiel liegt schon etwas länger zurück und betrifft ein Webinar der Firma MID GmbH vom 24.11.2021. Auch dieses Webinar wirbt mit einem nicht minder spannenden Titel: „DATEVs digitale Transformation mit Prozessstandards und Bpanda“.

Offensichtlich nutzen beide Beiträge den Begriff „Digitale Transformation“. Schauen wir mal in die Inhalte und entscheiden anschließend, wie nach meiner Definition die beiden Beispiele einzuordnen sind. Ich möchte an dieser Stelle betonen, dass ich hier nicht über „richtig“ oder „falsch“ urteilen möchte. Ich möchte lediglich verdeutlichen, wie unterschiedlich ein und derselbe Begriff von SAP, MID und auch von mir interpretiert wird. Ich überlasse es Ihnen, wie Sie darüber urteilen. Eines sollten Sie allerdings aus diesem Vergleich mitnehmen: Fragen Sie immer nach, was derjenige, der Ihnen etwas verkaufen möchte, unter Digitalisierung bzw. digitaler Transformation konkret versteht. Sie beugen dadurch unliebsamen Überraschungen vor. Dabei kann Ihnen mein Grundlagenartikel mit seinen vielfältigen Kriterien als Orientierung zur Einstufung in Digitalisierung bzw. digitale Transformation dienen.

Doch nun zurück zu den Beispielen. Ich beginne mit dem SAP-Artikel, in dem es um das Reisekostenmanagement bei der Felix Schoeller Group, einem Hersteller von Spezialpapieren, geht. Nach meiner Definition gehört dieses Fallbeispiel eindeutig in die Kategorie Digitalisierung. Warum? Die Beschreibung zeigt die Einführung einer Standardlösung. Der Zettelwirtschaft soll ein Ende bereitet und durch digitale Prozesse ersetzt werden. Im Grunde sind also Standardprozesse zu implementieren. Dies ist allerdings eines meiner Kriterien für die Einstufung in die Digitalisierungskategorie. Weiterhin wird im Artikel kurz auf die Vorgehensweise im Projekt eingegangen. So heißt es im Text: „Den Beginn des Prozesses markiert eine Analyse der bestehenden Prozesse.“ Wir haben es hier also mit der klassischen Ist-Aufnahme von Prozessen und folglich mit einem Bottom-Up-Vorgehen zu tun. Auch das ist ein klarer Hinweis auf eine Digitalisierung. Last but not least gehört das Thema „Reisekostenmanagement“ mit hoher Wahrscheinlichkeit nicht zur Kernkompetenz der Felix Schoeller Group und wird dem Unternehmen demnach wohl kaum einen Wettbewerbsvorteil bringen. Der Einsatz von Standardsoftware bringt einem Unternehmen keine, und wenn überhaupt, dann nur relativ kurzfristig Wettbewerbsvorteile, da die Konkurrenz durch den Kauf ähnlicher Software den Vorteil schnell egalisieren kann. Mit anderen Worten: Das Geschäftsmodell hat sich für die Felix Schoeller Group aufgrund des Einsatzes der Standardlösung mit Sicherheit nicht geändert. Der Wettbewerbsvorteilsaspekt und die Weiterentwicklung des Geschäftsmodells spielen allerdings für meine Definition der digitalen Transformation eine ganz entscheidende Rolle. Dieser Sachverhalt ist hier also nicht erfüllt, folglich handelt es sich bei diesem Beispiel auch nicht um eine digitale Transformation.

Sie sehen also: Gemäß meiner Definition handelt es sich in diesem Fall lediglich um eine Digitalisierung und nicht um eine digitale Transformation.

Dem MID-Anwendungsfall liegt ein Webinar zugrunde, das am 24.11.2021 stattfand und auf YouTube unter diesem Link veröffentlicht wurde. Mit meiner Definition von „Digitaler Transformation“ im Kopf war ich natürlich sehr gespannt, wie die DATEV die digitale Transformation mit Prozessstandards wohl angehen würde. Ich erwartete Informationen über die Steigerung des Automatisierungsgrades bei den Kernprozessen der DATEV und wie dies auf Basis von Prozessmodellen wohl erreicht wurde. Allerdings wurde ich dann doch arg enttäuscht. Denn mit der Automatisierung von Prozessmodellen hatte das Webinar rein gar nichts zu tun. Es ging im Wesentlichen um die kontinuierliche Prozessverbesserung bei der DATEV auf Basis von dokumentierten (!) BPMN-Prozessmodellen und wie man die Zusammenarbeit organisatorisch in den Griff bekommt. Hier muss man den Veranstaltern zumindest zugutehalten, dass durch Einsatz von Tools eine gewisse IT-Unterstützung gegeben war. So saß ich also ungeduldig vor dem Monitor und wartete auf innovative Automatisierungsansätze, die dann leider nicht kamen.

Auf die Frage, ob denn auch an eine Automatisierung der so mühsam erstellten BPMN-Modelle mittels Process Engines gedacht werde (ab Stelle 1h 08min 01sec), kam die Antwort, dass dies bei der DATEV noch in den Kinderschuhen stecke. Überhaupt ist gerade bei dieser Frage eine interessante Verhaltensänderung des DATEV-Experten zu beobachten. Nach der Frage trat zunächst ein vielsagendes Schweigen ein. Für mich wirkte der Herr an dieser Stelle verunsichert. Es folgten halbherzige Aussagen rund zu „Process Mining“ und „Celonis“. Da muss man sich schon fragen, wie man bei Process Engines als erstes an Process Mining denken kann? Später kam dann noch die Automatisierung von Formularen ins Spiel, aber es war deutlich zu spüren, dass über eine BPMN-basierte Prozessautomatisierung, zumindest in dieser DATEV-Abteilung, noch nicht intensiver nachgedacht wurde.

Noch eine kleine Bemerkung am Rande: Im Webinar kam auch die Frage nach der Nutzung der gesamten BPMN-Palette zur Sprache (ab Stelle 1h 01min 30sec). Wie nicht anders zu erwarten, wurde auch diesmal wieder die Mähr von der Komplexität der BPMN erzählt. Man möchte die Leute ja schließlich mit der ganzen BPMN-Fülle nicht verwirren, so die Aussage. Meine Erfahrungen sind jedoch ganz andere. Es ist nach meiner Ansicht essenziell, die gesamte Palette zu kennen, da jedes Element, jedes Symbol und jede Markierung nicht ohne Grund Einzug in den Standard fand. Wenn man die BPMN lehrt, so gibt es stets einen fachlich sinnvollen Anwendungsfall, der den Einsatz jedes Elements rechtfertigt. Wie sollen korrekte und aussagekräftige BPMN-Modelle entstehen, wenn man nur einen Bruchteil der BPMN-Palette den Nutzern zur Verfügung stellt?

Ich finde es zudem anmaßend und bevormundend den Menschen gegenüber, die später die BPMN einsetzen sollen und wollen. Als wären sie nicht selbst in der Lage zu entscheiden, was sie verwenden möchten oder nicht, sofern Sie zumindest einmalig die BPMN-Möglichkeiten erklärt bekommen haben. Ich war jedenfalls einmal mehr enttäuscht darüber, BPMN in ein solch schlechtes Licht gerückt zu sehen.

Alles in allem war das Webinar also eher ernüchternd und gemäß meiner Definition weder eine Digitalisierung noch eine digitale Transformation. Wenn überhaupt, so kann man einen hauchdünnen Digitalisierungsansatz erkennen, da eine toolunterstützte bereichsübergreifende Zusammenarbeit erreicht wurde. Immerhin.

Sie sehen also, Digitalisierung ist nicht gleich Digitalisierung und digitale Transformation längst nicht gleich digitale Transformation. Diese beiden Beispiele haben das unterschiedliche Verständnis der Begriffe einmal mehr eindrucksvoll verdeutlicht. Genau das macht die Diskussion um diese Begriffe so schwierig, da jeder etwas anderes darunter versteht. Seien Sie also kritisch, wenn mit diesen Begriffen geworben wird und klären Sie vorher ab, was Sie erwarten können. Nur so können Sie Enttäuschungen vorbeugen.

Beim Prozessgesteuerten Ansatz wissen Sie jedenfalls genau, woran Sie sind: Qualitativ hochwertige Digitalisierung und digitale Transformation gemäß der Begriffsdefinitionen aus meinem Grundlagenartikel. Diese Webseite trägt alles Wesentliche zusammen, was Sie für einen Start in die Digitalisierung bzw. digitale Transformation wissen müssen. Legen Sie los!

Graphic Recording meines Vortrags auf der Konferenz „Agile Verwaltung“

Gestern hatte ich das große Vergnügen, auf der Konferenz „Agile Verwaltung“ in Form eines Impuls-Vortrags über neue Wege der digitalen Transformation in öffentlichen Einrichtungen zu sprechen. Das Feedback zur Session hat mir gezeigt, dass die Botschaft verstanden wurde: Der richtige Weg zur digitalen Transformation führt ausschließlich über den Prozessgesteuerten Ansatz!

Doch auch der Veranstalter hatte eine besondere Überraschung parat: Meine Session wurde in Form eines „Graphic Recordings“ aufgenommen! Es gibt also keine Videoaufzeichnung meines Vortrags, aber eine grafische Aufnahme, die von Imke Schmidt-Sári (123comics) parallel zu meinem Vortrag angefertigt wurde. Und was soll ich sagen? Das „Recording“ ist phänomenal geworden! Ich will Euch dieses Meisterwerk natürlich nicht vorenthalten und darf es mit freundlicher Genehmigung des Veranstalters und der Künstlerin hier veröffentlichen. Hier ist es also (Tipp: Bild mit rechter Maustaste anklicken und „Bild in neuem Tab öffnen“ auswählen, um das Werk in voller Größe genießen zu können):

Graphical Recording erstellt von Imke Schmidt-Sári (123comics)

Der „Prozessgesteuerte Ansatz“ mal ganz anders repräsentiert. Wenn das keine Lust auf den Prozessgesteuerten Ansatz macht, verstehe ich es auch nicht mehr 😉.

Nachhaltigkeit in der Softwareentwicklung und der Moral Hazard

Leser meiner Webseite wissen, dass ich über die Art und Weise, wie heute Software entwickelt wird, höchst unzufrieden bin. Der Einsatz von Robotic Process Automation (RPA) beispielsweise oder die Programmierung von Prozessen (egal ob monolithisch über starren Programmcode oder über ereignisbasierte Microservices) sind meiner Meinung nach höchst bedenkliche Entwicklungen mit weitreichenden negativen Folgen für Unternehmen, die dem Bestehen der Unternehmen im Zeitalter der digitalen Transformation entgegenwirken.

Die möglichen Auswirkungen dieser Entwicklungen, was das alles mit Nachhaltigkeit und dem Moral Hazard zu tun hat, aber auch welche Möglichkeiten es gibt, den negativen Folgen zu begegnen, habe ich in meinem neuesten Artikel diskutiert. Ich freue mich auf reichlich Feedback!

Digitalisierungs-Eldorado „Öffentliche Verwaltung“

In meinem heutigen Blog-Beitrag möchte ich auf einen hörenswerten Podcast des Handelsblatts aufmerksam machen, der am 09.07.2021 veröffentlicht wurde und unter diesem Link anzuhören ist. In diesem Podcast wird Lars Zimmermann interviewt. Gemäß der oben verlinkten Ankündigungsseite zu dem Podcast „baut Lars Zimmermann mit Public eine sogenannte Venture Firm auf, die Tech-Startups und Verwaltungen zusammenbringt. Außerdem stellt Public Kontakt zwischen Startups und internationalen Investoren her, die gerade enorme Summen in das Feld investieren.“

Inhaltlich werden folgende Fragen diskutiert (ebenfalls obiger Seite entnommen):

„Welche Ideen haben wirklich eine Chance? Wie sieht ein moderner Staat aus? Ist es überhaupt realistisch, dass die schleppende Digitalisierung mehr Fahrt aufnimmt oder bleibt es am Ende wieder bei leeren Versprechen? Und welche Rolle können junge Technologiefirmen bei alledem spielen?“

Soweit also die Ankündigung auf der Handelsblatt-Webseite. Hört man sich den Podcast an, so ist es im Grunde ein einziger Schrei nach dem „Prozessgesteuerten Ansatz“. Wieder einmal geht es im Kern um neue Prozesse, die, wenig überraschend, so schnell wie irgend möglich umzusetzen sind. Auch Lars Zimmermann weist auf den hinlänglich bekannten Punkt hin, dass es nichts bringen wird, aktuelle Prozesse einfach nur digital nachzubauen. An dieser Stelle erinnere ich nur an das altbekannten Dirks-Zitat: „Wenn Sie einen Scheißprozess digitalisieren, dann haben Sie einen scheiß digitalen Prozess.“

Zimmermann formuliert es etwas eleganter (Minute 11:29): „Wir digitalisieren gerade die Vergangenheit nach.“ Aber er spricht auch die organisatorischen Herausforderungen der Digitalisierung an, denen wir insbesondere hier in Deutschland aufgrund der föderalen Struktur gegenüberstehen. Auf den Punkt gebracht sagt er (Minute 12:35): „Wie machen wir den Föderalismus fit für das 21. Jahrhundert?“

Allein: Wegweisende Antworten, wie das genau zu erreichen ist, findet man nur wenige, denn wir werden mit an Sicherheit grenzender Wahrscheinlichkeit das föderale System nicht grundlegend infrage stellen. Von daher bin ich, was diese Forderung angeht, mehr als skeptisch.

Angesprochen auf Public und welche Rolle Public konkret spielt, stimmen mich seine Antworten ebenfalls nachdenklich. Konkret antwortet er (ab Minute 19:40):

„Unser Hebel ist, dass wir sagen, es gibt ’ne ganze Reihe von technologischen Lösungen und Innovationen, die in der Tech-Szene schon bestehen oder dort entwickelt werden und die aber noch keine Anwendung in Verwaltungen finden und wir sagen: Es würde so viel einen Mehrwert für alle möglichen Bereiche geben, wenn wir diese Lösungen aus Deutschland oder aus Europa in Deutschland selber anwenden. D.h. wir versuchen im Grunde genommen diese Brücke zu bauen zwischen Startups/Technologieunternehmen und dem Staat als Anwender und als Nachfrager und als Auftraggeber und damit können wir natürlich z.B. relativ schnell sehr gute Produkte in die Verwaltung bringen.“

Er spricht auch später stets von den „richtigen Produkten“ (21:36) für die Verwaltungen. Das ist typisch für die meiner Meinung nach nicht mehr passende Denkweise im Zeitalter der digitalen Transformation. Es geht eben nicht mehr um fertige Lösungen und Produkte, die dann mal so eben in den Verwaltungen einzusetzen sind. Das verschlimmert den Zustand der Schnittstellenrepublik, wie es die ebenfalls in dem Podcast zitierte Bundeskanzlerin (Minute 24:10) so treffend ausdrückt, nur zusätzlich. Außerdem befindet sich der Markt in einem solchen Wandel, auf welche Lösung sollten die Verwaltungen denn setzen? Die Lösung von heute ist morgen schon wieder veraltet. Wie will man bei diesem Hase-und-Igel-Rennen gewinnen? Glaubt Hr. Zimmermann wirklich, dies ließe sich in diesem Ameisenhaufen in irgendeiner Form geordnet umsetzen? Ich glaube nicht daran.

Das bereits oben angesprochene Zitat der Bundeskanzlerin ist in vielerlei Hinsicht interessant. Hören wir nochmal in den Podcast rein (24:10):

„Wir dürfen keine Schnittstellenrepublik werden, wo wir permanent irgendwelche Schnittstellen miteinander vernetzen, wo sich aber die einzelnen Untersysteme nicht gleichmäßig weiterentwickeln. Und Digitalisierung hat ja ständige Erneuerung und das ist ’ne richtige tiefe Debatte, die wir über die Funktionsfähigkeit eines föderalen Systems im digitalen Zeitalter führen müssen.“

Diese Systemvielfalt ist mit Sicherheit ein Hindernis bei der geforderten schnellen digitalen Transformation Deutschlands. Aber sich dieser Herausforderung zu stellen und Lösungen unter Berücksichtigung der Heterogenität zu finden, genau an diesem Punkt scheiden sich die Geister. Stattdessen wird Unmögliches gefordert: Die Untersysteme, wie es die Bundeskanzlerin fordert, sollen sich gleichmäßig weiterentwickeln. Wie soll das funktionieren? Wie soll das in diesem „Hühnerhaufen“ umgesetzt werden? Und das schnell?

Lars Zimmermann schlägt in eine ähnliche Kerbe (ab Minute 24:40). Er fordert die Erfüllung von drei Bedingungen. Sind sie erfüllt, so Zimmermann, dann ist die Skalierung von Technologie zu schaffen:

  1. Zentrales Auffinden der Lösungen und deren Einsatz (aktuell keine Transparenz im Markt, was wo eingesetzt wird)
  2. Interoperabilität
  3. Standardisierung (Marktplatz, Plattform)

Getoppt werden diese Bedingungen mit Zimmermanns Aussage, die den „heiligen Gral der kommunalen Selbstbestimmung in Technologiefragen“ (25:55) infrage stellt. Meine Meinung dazu: Unrealistisch!

Die einzige Möglichkeit, in diesen stürmischen Zeiten die Weichen richtig zu stellen, ist die Standardisierung auf Prozessebene. Diese Prozesse in einem Process App Store zu sammeln und den Verwaltungen dann zur Verfügung zu stellen. Dieser Ansatz scheint mir zielführend und erfolgversprechend zu sein, wenn es darum geht, Prozesse in der Fläche zu skalieren.

Diese Skalierung in der Fläche wird auch von Markus Richter als kritisch angesehen. Markus Richter ist CIO der Bundesregierung und gibt im Podcast ebenfalls ein kurzes Statement ab (Minute 35:10): „Wir haben viele digitalen Lösungen und in vielen Bereichen ist das auch im Praxisbetrieb. Aber es skaliert nicht in der Fläche. Es ist eben nicht so, dass man in Deutschland auf einen Knopf drückt und dann ist der digitale Bauantrag in allen Kommunen vorhanden. […] Das ist die große Herausforderung, die Skalierung in der Fläche.“

Genau diesem Traum des Knopfdrucks und des Ausrollens von Prozessen in der Fläche kommen wir mit dem Process App Store schon sehr nahe, insbesondere natürlich dann, wenn diese Prozesse dem „Prozessgesteuerten Ansatz“ folgen. So können diese innovativen systemunabhängigen Fachprozesse über systemabhängige Integrationsprozesse (siehe hierzu den Abschnitt der „Prozessgesteuerten Architektur“ in meinem Grundlagenartikel über den Prozessgesteuerten Ansatz) an die jeweiligen lokalen Gegebenheiten der Behörde angepasst werden, in der die neuen Fachprozesse letztendlich zum Einsatz kommen.

In die föderalen Strukturen müsste bei diesem Vorgehen nicht eingegriffen werden. Die Kommunen dürften sogar unabhängig voneinander neue Prozesslösungen erarbeiten und sie im Process App Store zur Wiederverwendung veröffentlichen, alles kein Problem. Es kommt letztendlich zu einem Wettbewerb der Prozessideen und nicht der Produkte und Lösungen! Der bessere (Prozess) möge gewinnen. Und diese könnten anschließend mit überschaubarem Aufwand in den Kommunen zum Einsatz kommen! So könnten Deutschlands Verwaltungen wirklich innoviert werden! Wenn uns das gelänge, könnten wir wieder zu den Vorreitern der Verwaltungen werden, wie uns dies im analogen Zeitalter gelungen war und damit dem finalen Wunsch von Lars Zimmermann erfüllen, wenn er fordert (Minute 47:45):

„Die Bundesrepublik Deutschland sollte die Ambitionen haben zu sagen, wir sind unter den Top Drei Tech-Nationen der Welt. Das sollte und muss aus meiner Sicht die Ambition sein, auch der nächsten Bundesregierung: Zu sagen, es gibt drei Länder, wo Technologien die Basis für zukünftiges Wachstum sind und das sind die USA, das ist China und das ist die Bundesrepublik Deutschland“.

Der „Prozessgesteuerte Ansatz“ steht jedenfalls bereit, um diese Ambitionen Wirklichkeit werden zu lassen!