Die Standardsoftware am Scheideweg

Teil 2 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 Prozessfabriken bauen kann.
Teil 2 wendet sich der Standardsoftware zu: ERP- und ECM-Systeme haben über Dekaden das Rückgrat der Unternehmens-IT gebildet und stellen auch heute die Grundlage für die Digitale Transformation von Unternehmen und Behörden dar. Doch vier strukturelle Probleme treffen gerade jetzt auf die künstliche Intelligenz – und führen dazu, dass das bisherige Konzept der Standardsoftware an seine Grenzen kommt.

Prozessmanagement unter Druck

Geschäftsprozessmanagement (BPM) ist für viele Organisationen derzeit das wichtigste Digitalisierungsthema. Für Unternehmen entscheidet es über die Wettbewerbsfähigkeit, für Verwaltungen entscheidet es darüber, ob sie ihre gesetzlichen Aufgaben auch künftig erfüllen können. In der BPM-Studie 2025 der ZHAW erwarten 76 % der befragten Organisationen, dass die Relevanz von BPM weiter zunimmt [1].

Beide stehen vor derselben Herausforderung: Sie müssen BPM konsequent voranbringen – mit knappen Budgets und in einem demografischen Wandel, der Fachkräfte rar macht. Allein dem öffentlichen Dienst fehlen nach Schätzung des dbb bereits mehr als eine halbe Million Beschäftigte [2]. Ähnlich sieht es in der deutschen Wirtschaft aus – das Institut der deutschen Wirtschaft (IW) prognostiziert in einer aktuellen Studie für 2027 trotz Stellenabbau eine Lücke von 600 Tausend Arbeitskräften [3]. Wer weniger Menschen hat, muss bessere Prozesse haben.

BPM ist dabei keine reine IT-Aufgabe. Es ist eine gemeinsame Aufgabe der Unternehmensführung, des gesamten Managements und am Ende der IT, die die Systeme betreibt. Diese IT ruht in der Regel auf zwei klassischen Säulen: dem Enterprise Resource Planning (ERP) für die datenbezogenen und dem Enterprise Content Management (ECM) für die dokumentbezogenen Prozesse.

Beide Säulen haben eines gemeinsam: Ihre Einführung, ihre Integration und die damit verbundene digitale Transformation sind langwierig und teuer. Allzu oft enden sie mit überschrittenen Zeitplänen und Budgets. Eine viel zitierte Untersuchung von McKinsey und der Universität Oxford ergab bereits 2012, dass große Software-Projekte ihr Budget im Durchschnitt um 66 % und ihren Zeitplan um 33 % überschreiten und dabei 17 % weniger Nutzen liefern als erwartet [4]. Die Hoffnung, dass diese Werte durch neue Generationen von Standardsoftware aufgehellt werden, erfüllt sich nicht. Gartner prognostiziert, dass bis 2027 mehr als 70 % der jüngst gestarteten ERP-Initiativen ihre ursprünglichen Geschäftsziele nicht oder nicht vollständig erreichen. Für bis zu 25 % der Projekte erwartet Gartner ein vollständiges Scheitern [5].

Das vollständige Scheitern ist keine Ausnahme, sondern real. Lidl brach 2018 die Einführung eines neuen Warenwirtschaftssystems nach rund sieben Jahren ab; die Fachpresse bezifferte den Aufwand auf etwa 500 Millionen Euro [6]. Die Liste solcher Fälle in der Wirtschaft ist lang. In der öffentlichen Verwaltung steht die E-Akte exemplarisch für diese Erfahrung. Seit dem DOMEA-Konzept Ende der 1990er-Jahre wird sie eingeführt, das E-Government-Gesetz des Bundes von 2013 hat sie verbindlich gemacht – und doch zieht sich die flächendeckende Umsetzung bis heute hin. Die E-Akte ist mit den zugrunde liegenden ECM-Systemen in der Verwaltung zwar angekommen, von einer flächendeckenden und medienbruchfreien Nutzung kann jedoch nach Erfahrungen des Autors nur in Ausnahmefällen gesprochen werden [7].

Die Gründe sind vielschichtig. Softwareanbieter, Systemintegratoren und Kunden sind inzwischen geübt darin, sich gegenseitig die Schuld zuzuschieben. Ein genauerer Blick lohnt sich, denn die meisten Probleme haben gemeinsame systemische Ursachen.

Die alten und die neuen Probleme

Selten lässt sich ein Projektverzug oder eine Budgetüberschreitung allein einer Seite zuschreiben. Und nur wenige Problemfälle, über die man in der Fachpresse liest oder die man selbst in Projekten erlebt, sind direkt und ausschließlich in der ERP- oder ECM-Software begründet.

Natürlich gibt es den Fall, dass ein Kunde objektiv das falsche System wählt. Die Software ist für seinen Bedarf schlicht »zu groß« oder »zu klein« und in manchen Fällen schlicht fachlich ungeeignet. Aus der öffentlichen Verwaltung kennt man eine Variante davon: Da das Vergaberecht eine bedarfsgerechte Auswahl eher erschwert, als dass es sie erleichtert, beschaffen Behörden mitunter ein Produkt, das sie nicht wollten und das ihre Anforderungen nicht erfüllt.

Im Normalfall liegen die Ursachen jedoch tiefer – in der Art, wie Standardsoftware eingeführt, angepasst und kombiniert wird. Vier Probleme stechen heraus:

1. Das »Process-Mining-Problem«, oder das Problem der Inkongruenz, resultiert aus der Art, wie ERP- und ECM-Projekte durchgeführt werden. Dass aus diesem Problem eine neue, gleichnamige Produktkategorie entstanden ist, zeigt: Man brauchte in diesem Fall spezialisierte Werkzeuge, um die Folgen der ungeeigneten Methodik nachträglich zu bereinigen.
2. Das »Clean-Core-Problem«, oder das Problem der Inflexibilität, betrifft den Umgang mit Änderungen – im Projekt und in der Weiterentwicklung. »Clean Core« ist die aktuelle Strategie der ERP- und ECM-Hersteller und verdeutlicht beim näheren Hinschauen, dass die Strategie selbst zum Problem geworden ist.
3. Das »Strategie-Problem«, oder das Problem der Ambivalenz, resultiert aus der zunehmenden funktionalen Überschneidung der beiden Säulen der Standardsoftware und erschwert jede Strategiebildung und Einhaltung der Wirtschaftlichkeit bei der Verteilung der Prozesse zwischen ERP und ECM.
4. Das »DNA-Problem«, oder das Problem der Ablehnung, rundet die Liste ab. Es ist direkt in der Herkunft der Systeme begründet und trägt deshalb diesen Namen.

Process Mining und das Problem der Inkongruenz

Process Mining gehört zu den bekanntesten Techniken der Prozessoptimierung und Prozessautomatisierung. Gartner bewertet den Markt inzwischen in einem eigenen Magic Quadrant [8]. Schon die Definition seiner ersten Phase, der Process Discovery, lässt jedoch die Stirn runzeln. Sinngemäß heißt es bei Wikipedia [9]:

Process Discovery ist die Rekonstruktion bestehender Prozesse direkt aus Ablaufprotokollen und Ereignisdaten, ohne sich auf vorab vorhandene Informationen oder Modelle zu stützen. Aus einem Ereignisprotokoll wird ein Prozessmodell erzeugt – reale Prozesse lassen sich allein aus Beispielausführungen entdecken.

Das wirft eine Frage auf: Warum müssen Prozesse, die zuvor mit großem Aufwand modelliert und eingeführt wurden, mit eigenen Werkzeugen wiederentdeckt und rekonstruiert werden?

Fairerweise kann es dafür auch gute Gründe geben. Die Realität weicht immer vom Modell ab – durch Ausnahmen, Workarounds und Abläufe über mehrere Systeme hinweg. Process Mining macht diese Abweichungen sichtbar und ist deshalb auch bei sauber modellierten Prozessen wertvoll. Diese Aufgabe von Process Mining wird häufig als Conformance Checking bezeichnet. In der überwiegenden Zahl der Fälle liegt die Ursache aber tiefer: in der Art, wie Prozesse modelliert, umgesetzt und eingeführt werden.

Zwei Sprachen für einen Prozess

BPMN 2.0 hat sich weltweit als Standard der Prozessmodellierung durchgesetzt und ist seit 2013 auch als ISO/IEC 19510 normiert [10]. BPMN-Diagramme sind für Menschen intuitiv verständlich und konsensfähig. Genau das ist ihre Stärke.

Die Schwäche zeigt sich beim Übergang zur Ausführung. Zwar definiert BPMN 2.0 eine Ausführungssemantik, und einige Process Engines können BPMN-Modelle ausführen. Die Modelle, die Fachbereiche erstellen und verabschieden, sind dafür jedoch fast nie geeignet. Aus Sicht einer Engine sind sie »unscharf«: Es fehlen Daten, Formulare, Schnittstellen, Fehlerbehandlung und vor allem Zustände. Die Praxisliteratur unterscheidet deshalb ausdrücklich zwischen fachlichen und technischen Prozessmodellen [11].

Für die präzise Umsetzung greifen Entwickler zu technischeren Notationen wie UML oder ergänzen die Modelle um Entscheidungslogik in DMN. Beide sind mit zahlreichen Artefakten verbunden: Die UML allein kennt 14 Diagrammtypen, die DMN bringt mit den Decision Requirements Diagrams (DRD) und den Entscheidungstabellen weitere Darstellungsformen hinzu. Diese Darstellungen sind exakt – aber komplex, unübersichtlich und für Menschen ohne tiefes Prozesswissen kaum lesbar. Selbst erfahrene Modellierer tun sich schwer, wenn das Flussdiagramm fehlt.

Zwei Vorgehensmodelle, zwei Bruchstellen

Aus dieser Ausgangslage entstehen – je nach Vorgehensmodell – zwei unterschiedliche Probleme.

Das erste ist typisch für Projekte, die mit dem „klassischen“ Ansatz des Projektmanagements durchgeführt werden, d.h. auf Basis einer Spezifikation. Auf die kurze Formel gebracht: Kunden verabschieden häufig Spezifikationen, die sie nicht verstehen.

Das zweite ist typisch für agile Projekte. In der agilen Welt spielt die Spezifikation eine eher untergeordnete Rolle – die Projekte werden in den meisten Fällen durch visuelle Prototypen (Mockups) begonnen und anschließend in kontinuierlichen Sprint-Ausbaustufen zur Produktreife weiterentwickelt. Die Spezifikation leidet darunter, weil sie in der agilen Welt nicht wirklich benötigt wird. Dies hat letztendlich zur Folge, dass der Kunde nicht das Prozessmodell, sondern gleich die Anwendung abnimmt, die zwar initial häufig in BPMN modelliert, jedoch in den meisten Fällen nicht in BPMN, sondern in einer anderen, oft plattformspezifischen Notation umgesetzt wurde. Dazwischen liegt eine Konvertierung – und mit ihr die Verfälschung des Modells.

In beiden Fällen laufen das verabschiedete Modell und der tatsächlich ausgeführte Prozess auseinander. Process Mining ist deshalb nicht nur ein Analysewerkzeug. Es ist auch ein Symptom: für die fehlende Durchgängigkeit vom Modell bis zur Ausführung.

Clean Core und das Aufgeben der Individualität

ERP- und ECM-Systeme stehen sinnbildlich für Standardsoftware – und für den in der Vergangenheit vollzogenen Abschied von der Individualsoftware. Ihre Existenzberechtigung schöpfen sie aus der Standardisierung: der Unternehmensprozesse ebenso wie der Daten- und Dokumenthaltung, also der Unternehmensressourcen. Über Jahrzehnte sind sie zu funktionsreichen, stabilen Frameworks gewachsen, mit denen die IT von Unternehmen und Behörden zum Laufen gebracht und am Laufen gehalten wird.

Der Drang zur Standardisierung hat jedoch eine gravierende Nebenwirkung, die über die Zukunftsfähigkeit dieser Systeme mitentscheidet: Kunden wollen zwar die Vorteile der Standardisierung – aber keine Uniformierung. Sie brauchen Plattformen, auf denen sie ihre Geschäftsprozesse so individuell gestalten können, wie ihre Organisation es erfordert. Sie wollen weder dieselben Prozesse wie ihre Wettbewerber noch ihre Organisation an die Software anpassen, nur weil es umgekehrt nicht funktioniert.

Die Hersteller trifft das nicht unvorbereitet. ERP- wie ECM-Anbieter haben die Anpassbarkeit von Prozessen längst auf ihrer Agenda. Sie bieten mehr oder weniger umfangreiche Möglichkeiten, Standardprozesse anzupassen. In der Regel läuft das auf Programmierung hinaus, im Normalfall in herstellerspezifischen Skriptsprachen.

Mit dieser Programmierung kommen jedoch die bekannten Probleme: Projekte werden komplexer und teurer, Einführungszeiten verlängern sich, und die Wartbarkeit sinkt mit jeder programmierten Änderung und Erweiterung. Hinzu kommt die Abhängigkeit von Spezialwissen, das in den Unternehmen selten vorhanden ist.

»Bleiben Sie am Standard«

Die Antwort der Hersteller nach Jahrzehnten der Erfahrung ist so einfach wie ernüchternd: möglichst nah am Standard bleiben. Das bekannteste Beispiel ist die Clean-Core-Strategie der SAP [12]. Der ERP-Kern soll frei von Modifikationen bleiben. Das sorgt für bessere Wartbarkeit, weniger Aufwand bei jedem Release-Wechsel, niedrigere Kosten und am Ende höhere Stabilität.

Diese Empfehlung ist keineswegs auf ERP-Systeme beschränkt. Im Protokoll der Anwendergruppe eines großen ECM-Herstellers fand ich die Clean-Core-Strategie fast wörtlich wieder. Die Empfehlung eines großen Anwenders an die anderen lautete schlicht: »Bleiben Sie dicht am Standard.«

Das Dilemma bleibt: Der Wunsch nach Anpassung lässt sich nicht einfach ignorieren. Es braucht einen Weg, Prozesse so zu gestalten, wie sie benötigt werden – ohne den Kern zu beschädigen. Genau das ist der Punkt, an dem Clean Core, richtig verstanden, mehr ist als ein Verbot: Es verlagert die Anpassung aus dem Kern heraus. Wohin – das ist die eigentliche Frage, der Teil 3 und Teil 5 dieser Reihe nachgehen.

ECM und das Problem der Ambivalenz

Der Begriff Enterprise Content Management wurde Anfang der 2000er-Jahre von der Branchenvereinigung AIIM (Association for Information and Image Management) geprägt. Selten ist ein Begriff so verbreitet und zugleich so unglücklich gewählt. Lästig ist die ständige Verwechslung mit Web-Content-Management-Systemen. Schwerer wiegt jedoch die Unschärfe – und sie ist das eigentliche Problem. Bezeichnend: Gartner hat den Begriff 2017 zunächst durch Content Services Platforms ersetzt, und die AIIM selbst spricht heute von Intelligent Information Management [13]. Das Problem der Unschärfe des Begriffs war vermutlich der Grund, warum Gartner den neu eingeführten Begriff Content Services Platforms inzwischen ebenfalls aufgegeben hat und zum ursprünglichen Begriff Document Management zurückkehrt.

Die Weiterentwicklung vom Dokumentenmanagementsystem (DMS) zum ECM-System hatte zwei Treiber. Der wichtigste war die wachsende Zahl an Regulierungsvorschriften zum Umgang mit Dokumenten. Der zweite war die wachsende Zahl an Geschäftsprozessen, die ausschließlich oder fast ausschließlich mit Dokumenten arbeiten. Beispiele sind Strategie-, Marketing- oder Reklamationsprozesse. In ihnen entstehen vor allem Dokumente, allerdings in unterschiedlichen Formaten, sodass sie sowohl ins Belegarchiv als auch ins Web oder andere Kommunikationskanäle passen müssen.

Dokumentbezogene Prozesse und prozessbezogene Dokumente

Die Prozesse eines DMS sind eher interner Natur: Versionierung, Langzeitarchivierung, Löschung. Die dokumentbezogenen Prozesse eines ECM-Systems sind dagegen ein wesentlicher Teil des unternehmensweiten Geschäftsprozessmanagements. Sie müssen mit den Prozessen im ERP abgestimmt werden – und zwischen beiden Systemen gibt es kein grundsätzliches »oben« und »unten«.

Theoretisch ist die Unterscheidung einfach:

• Dokumentbezogene Prozesse drehen sich um Dokumente – etwa eine Vertragsprüfung. Die primäre Zuständigkeit liegt beim ECM-System.
• Prozessbezogene Dokumente begleiten einen datengetriebenen Prozess – etwa der Lieferschein zur Bestellung und Auslieferung. Die primäre Zuständigkeit liegt beim ERP-System.

Eine prozessorientierte Organisation erkennt man daran, dass beide Prozesstypen und beide Systeme nach dem Ende-zu-Ende-Prinzip ineinandergreifen. Diese Anforderung ist jedoch auch die Ursache, warum die in der Theorie einfache Verteilung in der Praxis nicht so einfach funktioniert. Sowohl ERP- als auch ECM-Systeme unterliegen einer kontinuierlichen Weiterentwicklung und erweitern beständig ihren Funktionsumfang mit dem Ziel der Ende-zu-Ende-Integration. Typisches Beispiel für diese Entwicklung ist der Purchase-to-Pay-Prozess (P2P), der eine komplexe Wertschöpfungskette von der Bestellung zur Bezahlung eines Produktes oder einer Dienstleistung abdeckt. Dieser Prozess beteiligt im Normalfall sowohl ein ERP- als auch ein ECM-System, allerdings kann er in zwei unterschiedlichen Varianten umgesetzt werden:

• Im ERP-System mit Integration eines ECM zur revisionssicheren Beleghaltung

• Im ECM-System mit Integration eines ERP zur transaktionssicheren Datenhaltung

Diese Auswahl an Alternativen ist nur auf den ersten Blick ein Luxusproblem. Allzu häufig entspricht weder die erste noch die zweite Alternative dem Wunschprozess (s. auch das Problem der Inflexibilität), dafür überschneiden sich die beiden Frameworks inzwischen in ihrem Funktionsumfang. Die strategische Dimension geht in diesem Punkt auch in die finanzielle über. Wenn die sich überschneidende Funktionalität nicht selektiv aus den Produkt-Bundles entfernt werden kann, muss sie doppelt lizenziert werden.

Dies führt häufig zur dritten Variante der Umsetzung – in einer externen Prozessplattform mit Integration zu ERP- und ECM-Systemen. Die externe Prozessplattform löst dabei das Problem der fehlenden systemübergreifenden Orchestrierung. Beide Systemtypen brauchen eine Instanz, die Prozesse Ende-zu-Ende über Systemgrenzen hinweg steuert.

ECM-Systeme sind aus der Unternehmens-IT nicht mehr wegzudenken. Sie decken eine große Bandbreite ab – vom einfachen Belegarchiv für ERP-Systeme und Fachverfahren bis zur anpassbaren Plattform für dokumentbezogene Prozesse. Genau daraus entsteht das Problem: die Bidirektionalität der Beziehung zwischen ERP und ECM und die Komplexität ihrer Integration. Obwohl auf beiden Seiten viel Entwicklung geflossen ist, bleibt diese Integration die Hauptquelle von Problemen im Ende-zu-Ende-Prozessmanagement. Nur 19 % der Unternehmen nutzen laut ZHAW bereits die Integration von IT-Systemen zur ganzheitlichen oder teilweisen Prozessautomatisierung [1].

Die Legacy und das Problem der Ablehnung

ERP- und ECM-Systeme leiden nicht nur an der Inflexibilität, die aus der Standardisierung herrührt, oder an der Überschneidung ihrer Funktionen. Sie haben auch ein DNA-Problem.

ERP-Systeme tragen die DNA der Datenverarbeitung, insbesondere der Stammdatenverarbeitung. Nicht die Flexibilität des Produktionsprozesses, sondern die Korrektheit der Produktionsdaten war die oberste Priorität der ersten ERP-Systeme – und ist es bis heute. Ein Blick auf ihre Bedienoberflächen genügt, um diese Herkunft zu erkennen.

ECM-Systeme haben die DNA der DMS geerbt. Im Mittelpunkt stehen Metadaten, Dokument- und Aktenklassen. Nur wenige ECM-Systeme erlauben es, Geschäftsprozesse ganz ohne Dokumente abzubilden. Auch ihre Bedienoberflächen sind darauf optimiert.

Für beide gilt: Sie können ihre Rolle nur schwer, wenn überhaupt, verlassen. Das ist kein Vorwurf – es ist die Folge ihres Erfolgs in genau dieser Rolle.

Ende-zu-Ende-Prozesse brauchen jedoch Bedienoberflächen, die den Anwendungsfall vollständig abdecken – nicht nur seine datenbezogene oder seine dokumentbezogene Hälfte. Die daraus entstehenden Usability-Probleme gehören zu den stärksten Treibern für den Ruf nach individualisierten Prozessen und einer entsprechend individualisierbaren Software. Spätestens an dieser Stelle wird die Clean-Core-Strategie zum Problem.

Fazit: Bisherige Konzepte tragen nicht in die Zukunft

Die vier Probleme – die Unkenntnis der realen Prozessabläufe, die Inflexibilität und die Überschneidung der Standardsoftware sowie ihre DNA – verstärken sich gegenseitig. Und sie spitzen sich genau in dem Moment zu, in dem künstliche Intelligenz in Wirtschaft und Verwaltung Einzug hält.

Das ist kein Zufall. KI-Assistenten und KI-Agenten entfalten ihren Nutzen dort, wo Prozesse durchgängig, Daten zugänglich und Dokumente auffindbar sind. Sie scheitern an denselben Systemgrenzen wie die Menschen vor ihnen. In der ZHAW-Studie erwarten 49 % der Unternehmen eine wachsende Rolle der Agentic Process Automation [1]. Gartner ging bereits 2024 davon aus, dass bis 2028 rund ein Drittel aller Unternehmensanwendungen agentische KI enthalten wird [14]; diese Schätzung dürfte sich als zu konservativ erweisen. Agenten brauchen jedoch etwas, das sie orchestriert – sonst automatisieren sie nur die Fragmentierung.

Um die Probleme zu lösen und dabei von der KI zu profitieren, braucht es ein grundsätzlich neues Konzept für das Geschäftsprozessmanagement und die IT dahinter. Ein Konzept, in dem weder das KI-unterstützte Enterprise Resource Planning noch das KI-unterstützte Enterprise Content Management, sondern das KI-basierte Enterprise Process Management im Vordergrund steht. Allerdings nicht als Fähigkeit zur bloßen Modellierung und Verwaltung von Prozessen. Sondern als Fähigkeit, Geschäftsprozesse in Form konkreter IT-Systeme zu bauen und kontinuierlich weiterzuentwickeln.

ERP- und ECM-Systeme verlieren dadurch nicht an Bedeutung. Es geht vielmehr darum, ihnen die Rolle zu geben, in der sie den größten Beitrag leisten: die der zuverlässigen Hüter der Daten und Dokumente – der Systems of Record. Allein schaffen sie es jedoch nicht, Prozesse systemübergreifend zu orchestrieren und die Ende-zu-Ende-Digitalisierung zu ermöglichen.

Im nächsten Teil stelle ich dieses neue Konzept vor: die Enterprise Process Factory (EPF) – eine Fabrik, in der Geschäftsprozesse gebaut und weiterentwickelt werden.

Quellen

1. ZHAW School of Management and Law: BPM-Studie 2025.
2. dbb beamtenbund und tarifunion: Monitor öffentlicher Dienst 2025 / Personalbedarf im öffentlichen Dienst.
3. Institut der deutschen Wirtschaft: Arbeitsmarktfortschreibung 2029, September 2026
4. Bloch, M.; Blumberg, S.; Laartz, J.: Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company, 2012.
5. Gartner: Prognose zu ERP-Initiativen bis 2027 (»more than 70 % … will fail to fully meet their original business case goals«), 2023.
6. Berichterstattung zum Abbruch des Projekts »eLWIS« bei Lidl, u. a. Heise Online, Handelsblatt und CIO.de, Juli 2018.
7. KBSt: DOMEA-Konzept und das Gesetz zur Förderung der elektronischen Verwaltung (EGovG), § 6 Elektronische Aktenführung.
8. Gartner: Magic Quadrant for Process Mining Platforms, 2023 ff.
9. Wikipedia: Process mining, Abschnitt »Process discovery«.
10. Object Management Group: BPMN 2.0.2; ISO/IEC 19510:2013.
11. Freund, J.; Rücker, B.: Praxishandbuch BPMN. Hanser, aktuelle Auflage.
12. SAP: Clean-Core-Strategie (RISE with SAP, ABAP Cloud, Erweiterungen auf SAP BTP); DSAG-Leitfaden zu Clean Core.
13. Gartner: Magic Quadrant for Content Services Platforms, 2017; AIIM – Intelligent Information Management.
14. Gartner: Top Strategic Technology Trends for 2025 – Agentic AI, Oktober 2024.

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