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!

Neuer Podcast und neuer Artikel veröffentlicht

Christoph Pacher, der Betreiber der Podcast-Reihe „The State of Process Automation„, hat mich ein zweites Mal interviewt. Diesmal ging es um weitere Details zum Prozessgesteuerten Ansatz. Zudem diskutierten wir folgende Fragen:

  • Welche Herausforderungen können durch den Prozessgesteuerten Ansatz gelöst werden?
  • Welche Rahmenbedingungen müssen geschaffen werden, um den Prozessgesteuerten Ansatz einsetzen zu können?
  • Projektbeispiele für den Einsatz des Prozessgesteuerten Ansatzes

Zudem bin ich in einem neuen Artikel der Frage nachgegangen, ob bei der Namensgebung für bestimmte Technologien der IT-Industrie nicht ein wenig geschummelt wird. Die Frage ist, ob durch die Namen nicht mehr versprochen wird, als die Technologien letztendlich leisten können. Verdeutlicht habe ich die Diskrepanz zwischen Wunsch und Wirklichkeit an den beiden Technologien Robotic Process Automation (RPA) und Process Mining. Beide Veröffentlichungen sind über diesen Link aufrufbar.

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!

Der Prozessgesteuerte Ansatz in der Fertigungsautomatisierung: Best Paper Award auf der CIRPe 2021

In meinen Vorträgen und Veröffentlichungen betone ich stets die Bedeutung des Prozessgesteuerten Ansatzes nicht nur für betriebswirtschaftliche Prozesse. Selbstverständlich ist der Ansatz beispielsweise auch für Fertigungsprozessen einsetzbar.

Aus diesem Grund arbeite ich seit geraumer Zeit mit dem Lehrstuhl für Fertigungsautomatisierung und Produktionssystematik (kurz FAPS) der Friedrich-Alexander-Universität Erlangen-Nürnberg zusammen. Aus dieser Zusammenarbeit und unter Beteiligung der exentra GmbH sowie der Flowable Germany GmbH entstand nun eine Veröffentlichung, die am 28.10.2021 auf der namhaften Konferenz CIRPe 2021 mit dem Best Paper Award ausgezeichnet wurde. Bei der CIRP handelt es sich laut eigener Aussage um „die weltweit führende Organisation im Bereich der produktionstechnischen Forschung und steht an der Spitze der Entwicklung, Optimierung, Steuerung und Verwaltung von Prozessen, Maschinen und Systemen“ (siehe https://cirpe2021.sciencesconf.org/).

In unserem Beitrag mit dem Titel „Reference Architecture and Agile Development Method for a Process Driven Web Platform based on the BPMN Standard and Process Engines” schlagen wir eine Referenzarchitektur und eine agile Entwicklungsmethode für Engineering-Plattformen vor, die im Kern auf dem Prozessgesteuerten Ansatz ruht und somit auf dem bewährten BPMN-Standard unter Einsatz von Prozess-Engines. Das Papier steht sowohl bei ScienceDirect als auch bei ResearchGate zum Download bereit. Der Prozessgesteuerte Ansatz setzt somit seine Erfolgsgeschichte auch in der Fertigungsautomatisierung fort. Ich wünsche viel Spaß bei der Lektüre!

Webinar vom 08.09.2021 schon Online

Gestern noch live, heute schon online verfügbar: Mein Webinar zum „Prozessgesteuerten Ansatz“ in Zusammenarbeit mit Camunda. Es hat enorm viel Spaß gemacht, vor so vielen Teilnehmer*innen den Ansatz präsentieren zu können! Das Feedback zeigt mir die dringende Notwendigkeit eines Implementierungsansatzes für Prozesse, der Unternehmen die Möglichkeit gibt, ihre technischen Schulden zu reduzieren und nicht immer weiter zu erhöhen. Gleich zu Beginn meiner Präsentation komme ich auf diesen Aspekt zu sprechen und begründe, warum der Prozessgesteuerte Ansatz im Zeitalter der digitalen Transformation so wichtig ist. Auch zu sehen: Zwei Live-Demos zur Architektur prozessgesteuerter Anwendungen. Lasst Euch das Webinar nicht entgehen und schaut Euch die Aufzeichnung unter diesem Link an. Viel Spaß!

Neuer Podcast zum „Prozessgesteuerten Ansatz“

Letzten Samstag (17.07.2021) konnte ich ein wenig mit Markus Herhoffer und Lucas Rott von der exentra GmbH über den „Prozessgesteuerten Ansatz“ fachsimpeln. Die Diskussion wurde mitgeschnitten und liegt mittlerweile als Podcast vor. Unter diesem Link könnt Ihr gerne mal reinhören. In einer kurzweiligen Diskussion streifen wir die wichtigsten Aspekte des „Prozessgesteuerten Ansatzes“. Natürlich ist auch meine neue Initiative „PiDiArtify“ ein Thema und wie der „Prozessgesteuerte Ansatz“ in einer weltweit einzigartigen Form an der Technischen Hochschule Ingolstadt (THI) gelehrt wird.

Noch ein kleiner Hinweis: Der Podcast beginnt mit einigen News aus der IT-Welt. Ab Minute 18 beginnt dann unsere Diskussion. Ich wünsche Euch viel Spaß beim Anhören!

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!

THI-Studierende erstellen erste kommerzielle prozessgesteuerte Anwendung

Studierende der Technischen Hochschule Ingolstadt leisten Herausragendes und unterstützen dabei gleichzeitig Kulturschaffende: In der Rekordzeit von nur drei Monaten entwickelten die Studierenden die erste kommerzielle prozessgesteuerte Anwendung zur Durchführung von Veranstaltungen unter Pandemie-Bedingungen! Mehr über dieses faszinierende Projekt, nicht nur für Veranstalter, unter https://www.volkerstiehl.de/erste-kommerzielle-pda/. Vielleicht rettet diese einzigartige Anwendung auch Ihre Veranstaltung!