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.

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

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.