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- sowie DMN-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 oder der Ausführung eines Docker-Pulls 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-/DMN-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. Welche Kriterien sind für Dich bei der Process Engine-Wahl entscheidend? Gerne kannst Du meine Liste ergänzen. Nutze dazu einfach die Kommentarfunktion.

Neues aus Absurdistan: BAföG-Peinlichkeiten

In meinem heutigen Blog geht es einmal mehr um nicht-funktionierende Prozesse. Ein ja fast schon unglaubliches Beispiel wurde am 05.12.2022 von Jan-Henrik Wiebe in einem Artikel auf tagesschau.de unter dem Titel „BAföG-Anträge: Digitalisierung mit fatalen Folgen“ veröffentlicht. Was man da zu lesen bekommt, lässt einen nur den Kopf schütteln. Im Wesentlichen geht es um die verspätete Auszahlung von BAföG-Geldern an Studierende. Doch es geht nicht um einige wenige Tage oder vielleicht eine Woche. Es geht um Monate, teilweise fünf Monate und länger. Die Gründe? Im Artikel heißt es dazu:

Grund dafür sind eine fehlgeschlagene Digitalisierung der Anträge, immer neue Regeln und damit überarbeitete Ämter. Hinzu kommen ein hoher Krankenstand und Fachkräftemangel.

Jan-Henrik Wiebe

Wir lenken unseren kritischen Blick natürlich auf die fehlgeschlagene Digitalisierung. Wie sieht die Digitalisierung also konkret aus? Dazu wieder ein Zitat aus dem Artikel:

Zwar kann seit September 2021 mit BAföG-Digital in allen Bundesländern der Antrag online gestellt werden. Doch dann beginnen die Probleme. Laut dem Dachverband der bundesweit 57 Studenten- und Studierendenwerke hat die digitalisierte BAföG-Antragstellung „in der Praxis fatale Folgen“. „Die BAföG-Ämter der Studierendenwerke müssen die online eingereichten BAföG-Anträge der Studierenden händisch ausdrucken. Die Drucklast in den BAföG-Ämtern ist so hoch, dass dafür eigens zusätzliches Personal eingestellt werden muss: um digitale Anträge auszudrucken“.

Jan-Henrik Wiebe

Ah ja: In dem Prozess wurde offensichtlich genau ein Schritt digitalisiert: Der Antrag kann jetzt online gestellt werden. Danach erfolgt die Weiterverarbeitung wie gehabt auf Papier. Die Anträge werden tatsächlich händisch ausgedruckt, wozu extra Personal eingestellt werden musste. Es kommt aber noch besser:

Auch beim Papier selbst gibt es Engpässe. Im Jahresbericht des Studentenwerks Ost-Niedersachsen heißt es etwa: Papiermangel in der BAföG-Abteilung im Dezember 2021.

Jan-Henrik Wiebe

Haben Sie da noch Fragen? Ich nicht mehr. Einmal mehr ein Beispiel aus Absurdistan, an dem man nur verzweifeln kann. Und wer bleibt letztendlich auf der Strecke? Die Studierenden, die auf dieses Geld angewiesen sind. Im Artikel ist von knapp einer halben Million Studierenden die Rede. Sie müssen ausbaden, was an anderen Stellen versäumt wurde.

Ich empfinde dieses Beispiel einfach nur noch als höchst peinlich.

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!

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!

PiDiArtify-Initiative gestartet

Es ist mir eine Freude, heute eine ganz besondere Initiative ankündigen zu dürfen. Unter „PiDiArtify – die Kunst der methodischen Prozessautomatisierung“ möchte ich meinen Beitrag zu einer nachhaltigen digitalen Transformation von Unternehmen durch Einsatz des Prozessgesteuerten Ansatzes leisten!

Ziel der PiDiArtify-Initiative ist der Aufbau einer Community zum Austausch von Wissen und Erfahrungen zum Einsatz des Prozessgesteuerten Ansatzes in Unternehmen. Dadurch wird eine schnellere Verbreitung des Ansatzes angestrebt und Unternehmen die Chance gegeben, in diesen stürmischen Zeiten der digitalen Transformation zu bestehen und Geschäftsmodelle auf ein neues Niveau zu heben.

Insbesondere Startups eröffnet die Initiative Möglichkeiten, ihre Prozessanwendungen von Beginn an auf ein qualitativ hochwertiges Fundament zu stellen.

Weitere Details zu den Hintergründen und Zielen der Initiative sowie zur kostenlosen Teilnahme sind auf meiner Webseite unter https://volkerstiehl.de/pidiartify zu finden.

Ich hoffe auf eine breite Unterstützung! Auch wenn es sonst nicht meine Art ist, so bitte ich Sie diesmal darum, diese Ankündigung mit so vielen Ihrer Kontakte wie möglich zu teilen.

Vielen Dank schon jetzt für Ihre Unterstützung!

Digitalisierung vs. Digitale Transformation: Warum Digitalisierung nicht genügt

Haben Sie sich schon mal Gedanken über den Unterschied zwischen Digitalisierung und Digitaler Transformation gemacht? Tatsächlich wird der Begriff Digitalisierung in sämtlichen Gazetten und Online-Publikationen inflationär verwendet. Kaum ein Artikel, der ohne ihn auskommt. Dabei ist den wenigsten bewusst, dass die digitale Transformation für die Zukunft von Unternehmen viel entscheidender ist. Höchste Zeit also, sich mit den Unterschieden auseinanderzusetzen und die Herausforderungen für Unternehmen zu beleuchten, wenn sie sich für den einen oder anderen Weg entscheiden. Doch so einfach ist das gar nicht. Als ich mir Gedanken darüber machte, vielen mir so viele Aspekte ein, in denen sich die beiden Begriffe unterschieden, dass sie den Rahmen eines Blog-Beitrags sprengen würden. Also entschloss ich mich dazu, einen separaten Artikel darüber zu schreiben. Dieser Artikel ist nun fertig und kann unter diesem Link nachgelesen werden.

Nach der Lektüre des Artikels werden Sie vielleicht überrascht sein, in wie vielen Nuancen sich Digitalisierung und Digitale Transformation teilweise gravierend unterscheiden. Erstaunlich sicherlich auch die Erkenntnis darüber, welche Konsequenzen Unternehmen zu berücksichtigen haben, wenn Sie den Weg zur digitalen Transformation beschreiten. Interessant sind aber auch die Voraussetzungen, die ein Unternehmen erfüllen muss, um bei der digitalen Transformation erfolgreich zu sein.

Doch letztendlich hilft alles nichts: Ohne digitale Transformation keine Zukunft. Und noch etwas dürfte am Ende des Artikels deutlich geworden sein: Es ist nicht die Digitalisierung, die Unternehmen benötigen. Sie reicht bei weitem nicht aus, obwohl es gerade dieser Begriff ist, der in den Medien so omnipräsent ist. Es ist die digitale Transformation, auf die es ankommt und die den Unterschied ausmacht! Wir sollten zukünftig bewusster mit den beiden Begrifflichkeiten umgehen.

Wir sind noch nicht in der Digitalisierung angekommen

Dieser Blog-Beitrag bezieht sich auf einen Artikel von André Ammer, der in den Nürnberger Nachrichten am 16.02.2021 unter dem Titel „Bayern nutzt nun Fachwissen aus Afrika“ erschienen ist. Im Wesentlichen geht der Artikel auf den Einsatz eines neuen IT-Systems namens Sormas in Bayern ein. Sormas hat sich bereits in Afrika bei Ausbrüchen anderer Infektionskrankheiten (genannt werden u.a. Cholera, Ebola und Denguefieber) bewährt. Von diesem Know-how soll nun auch Bayern für die Corona-Pandemie profitieren. Der Hauptartikel selbst ist größtenteils auch online verfügbar, allerdings fehlt in der Online-Ausgabe ein interessanter Kasten, der in der Printausgabe mit „Wie weit sind die Gesundheitsämter in der Region?“ überschrieben ist.

Mir geht es in meinem heutigen Beitrag nicht so sehr darum, ob der Einsatz bzw. ob das System selbst gut oder schlecht ist. Ich möchte den Artikel exemplarisch nutzen, um daran aufzuzeigen, wie sehr wir noch in dem Systemdenken verhaftet sind, den ich für die anstehende digitale Transformation für nicht förderlich halte.

Fangen wir also an: Überfliegen Sie doch spaßeshalber mal den Artikel: Der Artikel wimmelt nur so von Systemnamen (Sormas, Sormas-X, Demis, BaySIM – in dem von mir angesprochenen Kasten kommen dann noch weitere Systeme mit so illustren Namen wie Covid-PIS, R23 und Äskulab21 hinzu) und Problemen der Interaktionen zwischen diesen Systemen. Da ist von Schnittstellenproblemen und nicht kompatiblen Datenaustauschen sowie potenziellen Gefahren wie der händischen Dateneingabe aufgrund inkompatibler Formate die Rede.

Diese Beschreibung trifft auf so ziemlich jedes Unternehmen und jede Behörde zu. Wir haben uns mittlerweile mehr oder weniger mit derartigen Problemen abgefunden, als wäre es ein gottgegebenes Gesetz. Ist halt so. Die Systemlandschaft ist historisch gewachsen. Ein Grundproblem dabei ist meiner Meinung nach das Denken in Systemen: Für jedes Problem gibt es hoffentlich ein dazu passendes System, das dieses Problem löst. Gibt es das System, wird es gekauft. Gibt es das System noch nicht, so muss es eben geschrieben werden. Was sind die Konsequenzen dieses Denkens? In den Rechenzentren dieser Welt treibt der System-Wildwuchs seine Blüten und die Administratoren ersticken in Verbindungsproblemen! An Innovation ist in einer solchen Gemengelage überhaupt nicht zu denken. Man ist froh, das Gesamtgefüge überhaupt irgendwie am Laufen zu halten.

Um es nochmal hervorzuheben: In diesem kurzen Artikel werden in Summe nicht weniger als sieben Systeme angesprochen! Für ein wirklich relativ simples Problem. Zudem ist der Artikel ja für eine breite Masse geschrieben, die sich in der Regel für unterschiedliche Systeme nun wahrlich nicht sonderlich interessiert. Aber dem Autor blieb keine andere Möglichkeit, als sich durch dieses Chaos von Systemen zu arbeiten, um die ganze Bandbreite der Probleme zu beleuchten. Verrückt! Sie können aber davon ausgehen, dass dies nur die Spitze des Eisberges ist. In den Rechenzentren der Unternehmen und Behörden schlummern Tausende von Systemen. Und diese Systeme sollen dann auch noch, wie durch Geisterhand, Daten mit wildfremden Systemen austauschen können. Mit dieser Herangehensweise ist die Katastrophe allerdings vorprogrammiert: Unzählige Systeme ersticken über kurz oder lang die Handlungsfähigkeit der IT und damit die Handlungsfähigkeit von Unternehmen und Behörden! Die Reaktionsfähigkeit auf neue Herausforderungen nimmt mit jedem weiteren System ab, bis bald gar nichts mehr geht.

Aber genau das ist das Letzte, was wir in Anbetracht der anstehenden Digitalisierungswelle gebrauchen können!

Die Systemvielfalt in Unternehmen und Behörden ist auch kein neues Problem – dieses Problem gibt es schon, seit es Computer gibt. Nur im Zuge der Digitalisierung, wo alles auf Geschwindigkeit und Flexibilität ankommt, wird dieser Umstand zu einem nicht kalkulierbaren Risiko! Die Herausforderungen der Digitalisierung lassen sich mit dem Systemdenken einfach nicht mehr meistern! Das meine ich mit meiner Überschrift, dass wir, wenn wir wie oben beschrieben vorgehen, noch nicht in der Digitalisierung angekommen sind!

So sehr ich die Handlungsweise der Verantwortlichen auch nachvollziehen kann („Ich brauche jetzt eine Lösung und zwar schnell!“), so schmerzhaft wird diese Entwicklung auf lange Sicht sein. Irgendwie scheinen alle auf ein Wunder zu warten bzw. zu hoffen, dass sich die Schnittstellenprobleme irgendwann in Luft auflösen werden. Diese Hoffnung muss ich allerdings nehmen: Das wird nicht passieren!

Typisch dafür ist beispielsweise folgende Passage aus dem Text: „Durch Sormas und Demis wurde auch das System BaySIM abgelöst, das Bayerns ehemalige Gesundheitsministerin Melanie Huml (CSU) im Mai vergangenen Jahres vorgestellt hatte. […] Ein Grund dafür: BaySIM war nicht mit allen Systemen kompatibel, die bis dahin in den Gesundheitsämtern verwendet wurden. Deshalb hätte der Import und Export der bisherigen Daten in Zusammenhang mit der Corona-Pandemie teilweise händisch erfolgen müssen, und dafür hatten die Behörden zu diesem Zeitpunkt einfach nicht die personellen Kapazitäten.“

Warum in Gottes Namen muss ein System mit allen eingesetzten Systemen kompatibel sein? Nach welcher Softwarearchitektur wird denn hier Software entwickelt? Morgen kommt für die Gesundheitsämter eine neue Lösung mit einer neuen Schnittstelle daher und dann werden auch Sormas und Demis weggeworfen oder wie? Oder noch schlimmer: Die neue Software für die Gesundheitsämter ist wirklich signifikant besser, wird aber nicht eingesetzt, weil sie nicht zu Sormas/Demis passt? Wie krank ist das? Zudem: BaySIM wurde im Mai 2020 eingesetzt und wird nach noch nicht einmal einem Jahr schon wieder ersetzt? Was geht da ab?

Für mich klingt das nach totaler Panik und Konzeptlosigkeit. Merkt man denn nicht, dass man sich mit diesem Vorgehen sein eigenes Grab schaufelt? Das Verhalten erinnert mich an folgendes Zitat:

Die Definition von Wahnsinn ist, immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten.

Tatsächlich kommen wir mit dem Systemdenken im Zeitalter der Digitalisierung nicht mehr weiter. Diese Ära ist definitiv vorbei. Nein, wir brauchen stattdessen mehr denn je einen Befreiungsschlag. Wir brauchen einen grundlegenden Paradigmenwechsel in der Softwarearchitektur und der Softwareentwicklung, der den Anforderungen der Digitalisierung Rechnung trägt. Und diese Anforderungen sind nun einmal Schnelligkeit und Flexibilität! Schnelligkeit und Flexibilität erhält man durch den „Prozessgesteuerten Ansatz“. Der Ansatz bedingt allerdings einen Wechsel weg vom Systemdenken und hin zum Prozessdenken. Prozesse, die durch Modelle explizit gemacht werden, und im Zusammenspiel mit einer nachhaltigen Software-Architektur einen Gesamtansatz entstehen lassen, der den IT-Verantwortlichen endlich wieder die Luft zum Atmen gibt, da sie sich aus dem System-Wirrwarr Schritt für Schritt befreien können! Auf dieser Basis können dann auch wieder Innovationen entstehen!

Ja, das ist neu und ungewohnt, aber die vielversprechendste Antwort auf die Herausforderungen der Digitalisierung. Prozesse explizit modellieren, diese durch eine Process Engine automatisieren und durch eine separierende Integrationsschicht von der existierenden IT-Landschaft trennen. Diese flexible Software-Architektur ermöglicht dann nachhaltige Prozesslösungen. Aber nicht nur das! Unterhalb der Integrationsschicht kann dann gleichzeitig mit den Aufräumarbeiten begonnen werden: Denn Ziel muss es sein, die IT-Landschaft schrittweise zu vereinfachen und die Anzahl der Systeme zu reduzieren. Dadurch lösen sich Unternehmen und Behörden aus dem Würgegriff der heterogenen IT-Systeme und ihrer Abhängigkeiten. Dank der separierenden Integrationsschicht ist genau dies möglich. Endvision dieser Herangehensweise ist eine Vielzahl von Prozessen, die über einer nur noch geringen Zahl von Basissystemen agieren!

Auf diese Weise gelingt Unternehmen und Behörden die Befreiung aus der einengenden Wirkung des System-Wildwuchses. Der Weg zur Innovation, Schnelligkeit und Flexibilität ist frei. Auf Basis des Prozessgesteuerten Ansatzes kann die digitale Transformation also tatsächlich gelingen!