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!

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!