Aus Softwarefabrik wird Prozessfabrik

30. Oktober 2026 9 Min. Lesezeit Editorial Gregor Lietz

Teil 3 der Reihe »Enterprise Process Factory« · Gregor Lietz

Teil 1 hat gezeigt, dass es bei der digitalen Transformation um Prozesse geht, dass Agilität zur entscheidenden Voraussetzung wird und dass KI die Transformation beschleunigt, aber keine Standardsoftware samt Produktlebenszyklus bauen kann.
Teil 2 hat gezeigt, warum ERP- und ECM-Systeme allein die Ende-zu-Ende-Digitalisierung nicht tragen und warum sie gerade jetzt auf dem Scheideweg stehen.
Teil 3 stellt das Gegenkonzept vor: die Enterprise Process Factory (EPF) – eine Fabrik, in der Geschäftsprozesse gebaut und laufend weiterentwickelt werden.

Warum ein neues Konzept

Wie im vorangegangenen Teil dargelegt, kämpft die Standardsoftware in Zeiten der digitalen Transformation mit einem Hauptproblem, das in ihrer DNA tief verankert ist. Ursprünglich auf Standardisierung als gemeinsamen Nenner für Tausende von Kunden ausgelegt, soll ausgerechnet sie nun zur Säule von Veränderung und Individualisierung werden.

Das Problem beschleunigt und verschärft sich in der aktuellen KI-Ära noch, denn KI zwar als Enabler und Beschleuniger der digitalen Transformation dient, jedoch selbst keine andere – keine bessere – Standardsoftware bauen kann.

Der Wunsch nach einer flexiblen Standardisierung rückt in den Fokus und erfordert ein neues Konzept des Geschäftsprozessmanagements (BPM). Gemeint ist die Möglichkeit, Geschäftsprozesse jederzeit nach eigenen Vorstellungen zu gestalten und gleichzeitig von den Vorteilen der Standardsoftware zu profitieren – etwa der Einhaltung zahlreicher Compliance-Regeln.

Dieses zukunftsfähige Konzept für das Geschäftsprozessmanagement muss drei grundlegende Fähigkeiten mitbringen:

  • Geschäftsprozesse sowohl aus Musterprozessen abzuleiten als auch von Grund auf neu zu erstellen

  • Abgeleitete oder erstellte Prozesse anschließend kontinuierlich weiterzuentwickeln

  • Dafür zu sorgen, dass die abgeleiteten oder erstellten Prozesse zu lauffähigen Anwendungen werden

Die erste Fähigkeit ergibt sich aus dem disruptiven Charakter der digitalen Transformation. Faktisch stehen derzeit alle Geschäftsprozesse auf dem Prüfstand, weil auch die dahinterstehenden Geschäftsmodelle infrage stehen. Die Transformation verändert die Regeln – zum Positiven wie zum Negativen. Durch den Einsatz von KI können ganze Geschäftsmodelle über Nacht obsolet werden. Im besten Fall müssen sie »nur« angepasst, im schlimmsten Fall neu erfunden werden. Hier helfen Musterprozesse, also bewährte, vorkonfigurierte Prozessvorlagen: Sie lassen sich ableiten und anpassen, statt jedes Mal bei null zu beginnen. Wo keine passende Vorlage existiert, muss ein Prozess von Grund auf neu entstehen können.

Die zweite Fähigkeit hat dieselbe Ursache. Organisationen und Geschäftsmodelle dürfen nicht stehen bleiben. Sie entwickeln sich ständig weiter – und mit ihnen müssen sich auch ihre Prozesse weiterentwickeln.

Das gilt für die Wirtschaft ebenso wie für die öffentliche Verwaltung. Diese versucht seit rund zwei Jahrzehnten, ihre Leistungen digital anzubieten, und bewegt sich dabei im Kreis zwischen der Modernisierung externer und interner Prozesse. Das Onlinezugangsgesetz von 2017 sah die Digitalisierung von 575 Verwaltungsleistungen bis Ende 2022 vor; das Ziel wurde deutlich verfehlt und 2024 mit dem OZG-Änderungsgesetz neu aufgesetzt [1]. Eine der Lehren: Ein digitales Antragsformular ohne digitalisierten Prozess dahinter verlagert lediglich die Arbeit.

Die dritte Fähigkeit stellt sicher, dass modellierte und umgesetzte Prozesse nicht auseinanderlaufen. In der Praxis ist das ein gängiges Problem, wenn für Modellierung und Anwendungserstellung unterschiedliche Werkzeuge verwendet werden.

Diese Anforderungen führen zu einem anderen Verständnis von BPM. Es geht weniger um ein Modell für das »Management« von Prozessen als um eine Fabrik für Prozesse: eine hochautomatisierte Fabrik, in der Geschäftsprozesse jederzeit neu gebaut oder abgeleitet, kontinuierlich weiterentwickelt und als lauffähige Anwendungen bereitgestellt werden können. Deshalb nennen wir das Konzept Enterprise Process Factory (EPF).

Isometrische Illustration einer Fabriklandschaft: Server mit der Aufschrift ERP sowie Knoten mit den Aufschriften IoT und ECMS sind über Datenleitungen mit Fabrikgebäuden verbunden. Roboterarme und Förderbänder bewegen Pakete, Menschen arbeiten an Bildschirmen mit Diagrammen.
Abb. 1: Die Prozessfabrik als Bild: ERP, ECMS und IoT liefern Daten und Dokumente, die Fabrik baut daraus lauffähige Prozesse. Eigene Darstellung.

Was die EPF von verwandten Ansätzen unterscheidet

Die Idee, Software industriell zu fertigen, ist nicht neu. Jack Greenfield und Keith Short beschrieben schon 2004 »Software Factories«, die Anwendungen aus Produktlinien und Modellen erzeugen [2]. Gartner propagierte 2014 das Postmodern ERP mit lose gekoppelten Bausteinen und 2020 das Composable Enterprise, das Anwendungen aus Packaged Business Capabilities zusammensetzt [3]. Seit 2024 fasst Gartner Werkzeuge zur systemübergreifenden Steuerung von Prozessen unter dem Begriff Business Orchestration and Automation Technologies (BOAT) zusammen [4]. Hinzu kommen Low-Code-Plattformen, die die Anwendungsentwicklung vereinfachen.

Die EPF steht in dieser Tradition – und geht doch einen eigenen Weg. Jeder der genannten Ansätze löst einen Teil des Problems: die Fertigung, die Zerlegung, die Orchestrierung oder die Entwicklung. Die EPF verbindet vier Dinge, die bislang getrennt gedacht werden:

  • Die Organisation als Modell: Die Prozesslandschaft wird entlang einer anerkannten Taxonomie aufgebaut, nicht entlang der Module eines Herstellers.
  • Durchgängigkeit vom Modell zur Ausführung: Das Prozessmodell, das der Fachbereich versteht, ist dasselbe, das ausgeführt wird. Damit adressiert die EPF das Process-Mining-Problem aus Teil 2 an der Wurzel.
  • ERP und ECM als Systems of Record: Standardsysteme bleiben unangetastet (Clean Core) und werden über Konnektoren orchestriert.
  • Musterprozesse mit Variantenmanagement: Der wichtigste Vorteil der Standardsoftware – die Wiederverwendung – bleibt erhalten, ohne in die Uniformierung zu führen.

Einzelne Bausteine gibt es auf dem Markt. Ihre Verbindung zu einem durchgängigen Fabrikkonzept für Geschäftsprozesse ist neu.

Die vier EPF-Eigenschaften

Eine Enterprise Process Factory muss vier Kerneigenschaften besitzen.

1. Agilität. Der Fabrik-Ansatz ersetzt den Modul-Ansatz. Im Mittelpunkt stehen Prozesse, nicht Ressourcen – und die Wandlungsfähigkeit der Prozesse wird zur Königsdisziplin. Alles bleibt in Bewegung, so wie die Geschäftswelt selbst.

2. Modularität. Eine Organisation besteht aus mehreren Prozessfabriken und baut sich ständig weiter aus. Das betrifft nicht nur die IT. Das Konzept gilt vor allem für die Organisation selbst, die sich als wandlungsfähige Struktur aufbauen und weiterentwickeln muss.

3. Vollständigkeit. ERP- und ECM-Systeme wachsen zu einem Gesamtpaket der Standardsoftware zusammen. Sie verschwinden nicht, sondern werden einer übergreifenden Orchestrierung unterstellt. Diese schließt nach Bedarf weitere Systeme ein – Fachverfahren, E-Mail, KI-Dienste oder IoT.

4. Wiederverwendbarkeit. Der wichtigste Vorteil der Standardsoftware bleibt erhalten: die Möglichkeit, auf vorhandenen Musterprozessen aufzubauen. Die EPF muss dabei für die nötige Anpassungsfähigkeit der Musterprozesse sorgen.

Nur eine Prozessfabrik, die alle vier Eigenschaften erfüllt, hält einer disruptiven und von ständiger Veränderung geprägten digitalen Transformation stand.

Der berechtigte Einwand

Ein Gegenargument liegt auf der Hand: Schafft eine Orchestrierungsschicht über ERP und ECM nicht einfach eine weitere Systemebene – mit eigener Komplexität, eigenen Kosten und eigener Herstellerbindung? Der Einwand ist ernst zu nehmen. Er trifft dann zu, wenn die neue Ebene wieder proprietäre Modelle, eigene Skriptsprachen und geschlossene Lizenzmodelle mitbringt. Eine EPF muss deshalb an drei Kriterien gemessen werden: an offenen Standards für Modelle und Schnittstellen, an der Durchgängigkeit vom Modell zur Ausführung und an der Wahlfreiheit bei Betrieb und Systemen. Teil 5 und 6 dieser Reihe greifen diese Kriterien wieder auf.

Der Aufbau einer EPF

Das EPF-Konzept ist zunächst abstrakt. Es soll aber zum Bau konkreter Prozessfabriken dienen. Dafür braucht es einen klaren Aufbau, der die vier Eigenschaften umsetzt. Er besteht aus sechs Ebenen:

Diagramm mit sechs Ebenen untereinander: Organisationsmodell, Prozessfabriken, Lösungen, Prozesse, Prozessbestandteile, Aktivitäten und Zustände. Rechts daneben die Aufgaben Modellieren, Kumulieren, Wiederverwenden, Orchestrieren, Integrieren und Überwachen. Ein grauer Bereich zeigt die Unternehmensressourcen Daten (ERP) und Dokumente (ECM) als Systems of Record außerhalb der Fabrik.
Abb. 2: Die Prozessfabriken bilden das Herzstück. Daten und Dokumente bleiben außerhalb der Fabrik in den Systems of Record – die Prozesse verändern nur ihren Zustand. Eigene Darstellung.

Organisationsmodell. Eine Organisation wird als Modell aufgebaut – etwa »Unternehmen«, »Behörde«, »Hochschule« oder »Verein«. Eine Branche besteht in diesem Sinne aus einer Gruppe von Modellen.

Prozessfabriken. Das Modell besteht aus beliebig vielen Prozessfabriken. Jeder abgrenzbare Prozessbereich der Organisation kann eine eigene Fabrik erhalten, typischerweise »Human Resources«, »Finanzen« oder »Kundenservice«. Eine bewährte Systematik liefert das Process Classification Framework (PCF) der APQC auf seiner obersten Ebene, den Categories [5].

Lösungen. Prozessfabriken bestehen aus Lösungen – in Form von konkreten Anwendungen, Bibliotheken oder Services. In der APQC-Taxonomie entsprechen sie in etwa den Process Groups. Diese Ebene ist nötig, weil manche Fabriken einen enormen Umfang haben und viele eigenständige Themen bündeln.

Prozesse. Lösungen bestehen aus Prozessen. Ein Prozess ist eine Aktivität oder eine Gruppe von Aktivitäten, die den Zustand von Unternehmensressourcen verändert – von Daten, Dokumenten oder anderen Ressourcen wie Fachverfahren.

Prozessbestandteile. Jeder Prozess besteht aus drei Teilen: dem Prozessmodell (dem Ablauf), der Prozessimplementierung (etwa Formulare, Dienste und Konnektoren) und der Prozessauswertung (Dashboards). Prozessdaten und Dokumente gehören ausdrücklich nicht dazu. Sie sind Unternehmensressourcen und liegen in den Systems of Record.

Aktivitäten und Zustände. Prozessmodelle bestehen aus Aktivitäten und Zuständen; jede Aktivität verändert den Zustand mindestens einer Ressource. Nach welchem Standard modelliert wird, ist für die Fabrik zweitrangig. Zu beachten ist nur, dass manche Standards – insbesondere BPMN 2.0 – Zustände nicht in den Mittelpunkt rücken. Datenobjekte können dort zwar einen Zustand tragen, er ist aber optional und wird in der Praxis selten gepflegt.

Die Prozessimplementierung hängt vom Prozesstyp und von der gewählten Technologie ab. Prozesse können Bedienoberflächen haben, müssen aber nicht. Dasselbe gilt für die Nutzung von ERP- und ECM-Systemen über Konnektoren.

EPF und Musterprozesse

Ein Aspekt der EPF ist so wesentlich, dass er eine eigene Betrachtung verdient: die Erstellung und Nutzung von Musterprozessen – und ihre Anpassung an die Geschäftsprozesse einer konkreten Organisation, die als Anwendungen laufen.

Musterprozesse können alle Bestandteile eines Prozesses enthalten: Muster für Abläufe, für Implementierungen und für Auswertungen. Was sie von ihren konkreten Umsetzungen unterscheidet, ist zunächst die Darstellung der Prozessbeteiligten und ihrer Berechtigungen.

In BPMN 2.0 erscheinen Prozessbeteiligte als Swimlanes – ideal, um das Zusammenspiel der Rollen sichtbar zu machen. In der UML heißen sie schlicht Actors. Musterprozesse können mit abstrakten Swimlanes und abstrakten Akteuren arbeiten, die in keiner realen Organisation vorkommen müssen. Ausführbare Anwendungen brauchen dagegen echte Rollen mit echten Berechtigungen.

Dasselbe gilt für Technik und Organisation:

  • Systeme: Im Musterprozess genügt ein abstraktes ERP- oder ECM-System. In der Prozessfabrik muss ein konkretes System gewählt werden – in der Regel über eine Konfiguration des Konnektors.
  • Kommunikation: Systemnachrichten müssen auf die tatsächlich genutzten Kanäle konfiguriert werden, etwa E-Mail oder API-Aufrufe.
  • Organisation: Abstrakte Rollen werden auf reale Organisationseinheiten, Gruppen und Berechtigungen abgebildet.

Das eigentliche Problem beginnt nach der Anpassung

Sobald ein Musterprozess angepasst und als Anwendung eingeführt ist, entwickeln sich Muster und Variante auseinander. Das Muster erhält Verbesserungen, gesetzliche Änderungen oder neue Funktionen. Die Variante enthält die Besonderheiten der Organisation. Ohne Unterstützung bleibt nur die Wahl zwischen zwei Übeln: die Variante einfrieren oder die Anpassung bei jedem Update von Hand wiederholen.

Softwareentwickler kennen diese Konstellation aus der Versionsverwaltung als Verhältnis von Upstream und Fork. Eine leistungsfähige Enterprise Process Factory unterstützt deshalb beides: die Ableitung von Varianten aus Musterprozessen und ihre spätere Synchronisierung, wenn sich das Muster weiterentwickelt. Erst dann ist die Wiederverwendung kein einmaliger, sondern ein dauerhafter Vorteil.

Ablaufdiagramm: Ein Musterprozess mit abstrakten Rollen, Systemen und Kanälen wird durch Adaption zur Prozessvariante mit realer Organisation und konkreten Systemen. Entwickelt sich das Muster weiter, etwa durch eine Gesetzesänderung, fließt die neue Muster-Version über die Synchronisierung in die Variante ein, ihre Anpassungen bleiben erhalten.
Abb. 3: Die Adaption macht aus dem Muster eine lauffähige Variante. Entscheidend ist der Rückweg: Neue Muster-Versionen müssen in die Varianten einfließen, ohne deren Anpassungen zu verlieren. Eigene Darstellung.

Fazit: Vom Verwalten zum Bauen

Die Enterprise Process Factory verschiebt den Blick: weg vom Verwalten von Prozessmodellen, hin zum Bauen und Weiterentwickeln lauffähiger Prozesse. ERP und ECM behalten ihre Rolle als verlässliche Hüter von Daten und Dokumenten. Die Fabrik darüber orchestriert sie, bildet die Organisation entlang einer anerkannten Taxonomie ab und hält Musterprozesse und ihre Varianten synchron.

Ob das Konzept trägt, entscheidet sich nicht auf dem Papier. Im nächsten Teil geht es zunächst um die oberste Ebene der Fabrik: die Organisation selbst – als Hochschule, als Verwaltung und als Unternehmen. Teil 5 sieht sich anschließend zwei Plattformen an, die das EPF-Konzept auf sehr unterschiedliche Weise umsetzen: die SAP-Plattform, die aus dem ERP heraus gewachsen ist, und die herstellerunabhängige A&O-Plattform.

Quellen

  1. Onlinezugangsgesetz (OZG) vom 14.08.2017; OZG-Änderungsgesetz (»OZG 2.0«), 2024.
  2. Greenfield, J.; Short, K.: Software Factories – Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley, 2004.
  3. Gartner: Postmodern ERP (2014); Future of Applications – Delivering the Composable Enterprise (2020).
  4. Gartner: Market Guide for Business Orchestration and Automation Technologies (BOAT), 2024.
  5. APQC: Process Classification Framework (PCF) – Ebenen Category, Process Group, Process, Activity, Task.

© 2026 Gregor Lietz, LCSI. Alle Rechte vorbehalten. Veröffentlichung, Vervielfältigung oder Weitergabe – auch auszugsweise – nur mit vorheriger schriftlicher Zustimmung des Autors.

Über den Autor

Gregor Lietz ist Informatiker. Seine berufliche Laufbahn hat er als Softwareentwickler bei der Entwicklung des Dokumentenmanagementsystems ARCIS der Siemens AG begonnen, bevor er ins Consulting und anschließend in die Strategieberatung wechselte. Als Berater des Bundesinnenministeriums hat er die Erstellung der Open-Source-Strategie der öffentlichen Verwaltung verantwortet und leitete als Autor die Erstellung des (Open-Source-)Migrationsleitfadens des BMI sowie des E-Government-Handbuchs „Sichere Integration von E-Government-Anwendungen“ des BSI. Er bekleidete Management-Positionen bei Electronic Data Systems (EDS), T-Systems und Microsoft. Er ist Gründer und Geschäftsführer der LCSI SaaS Operations Services GmbH und der A-&-O Software GmbH.