Clean Core ohne Dogma: Welche Entscheidungen anstehen und wie Teams sie richtig treffen

1. Einführung: Wenn Clean Core zur strategischen Notwendigkeit wird

Zum Einstieg: ein Dilemma aus der Praxis

Stellen Sie sich vor, Ihre SAP-S/4HANA-Implementierung befindet sich seit sechs Wochen in der Explore-Phase. Ein Prozessverantwortlicher besteht darauf: „Können wir nicht einfach die Funktionen aus SAP ECC nachbauen?“ Gleichzeitig entgegnet eine Führungskraft: „Das ist unser Alleinstellungsmerkmal. Wir dürfen unseren Wettbewerbsvorteil nicht gefährden.“ In diesem Moment wird Clean Core vom Marketingbegriff zur strategischen Entscheidung mit großer Tragweite: Welche Teile unseres Betriebs differenzieren uns wirklich, und welche sind lediglich etablierte Gewohnheiten, lokale Vorlieben oder Altlasten?

Warum Clean Core die USP-Erzählung hinterfragt

Unternehmen verwechseln ihr Alleinstellungsmerkmal häufig mit betrieblichen Eigenheiten. Tatsächlich überlagern sich oft drei unterschiedliche Kategorien: echte Differenzierung, etwa eigene umsatzwirksame Algorithmen, Compliance-Vorgaben, etwa regulatorische Berichte, und Bequemlichkeit, etwa vertraute Benutzeroberflächen. Clean Core verlangt eine klare Trennung. Vorschnelle Anpassungen im ERP-Kern können künftige Änderungskosten erhöhen, Upgrades verlangsamen und die Agilität schwächen.¹ Indem Unternehmen möglichst auf Standardprozesse setzen, bewahren sie sich Spielraum für Innovationen an anderer Stelle.²

Leitgedanke

Das Grundprinzip ist einfach und weitreichend: Halten Sie den Kern „langweilig“, damit das Geschäft „interessant“ sein kann. Differenzierung entsteht nicht dadurch, dass gestrige Prozesse im ERP festgeschrieben werden, sondern durch geringe Änderungskosten. Dieser Artikel verzichtet auf Dogmen und untersucht reale Entscheidungen, Zielkonflikte und bewährte Strategien erfahrener Teams, um langfristige Risiken wie wachsende technische Schulden zu vermeiden.³

2. Die eigentlichen Ziele von Clean Core

Handlungsspielraum als wirtschaftliche Kernstrategie

Clean Core folgt im Kern einer wirtschaftlichen Notwendigkeit mit diesen Zielen:

• Änderungskosten senken: Standardkonfigurationen reduzieren den Aufwand für Erweiterungen.
• Upgrades beschleunigen: Unveränderte Kerne erleichtern die reibungslose Übernahme von Herstellerinnovationen.¹
• Verantwortung klären: Klare Grenzen verhindern eine „diffuse Verantwortung“, bei der niemand für individuellen Code zuständig ist.

Studien zeigen, dass übermäßige Anpassungen Upgrades in langwierige „archäologische Expeditionen“ verwandeln, bei denen jede Codezeile auf Abhängigkeiten und Auswirkungen untersucht werden muss.⁴

Die wachsenden „Zinsen“ eines unaufgeräumten Kerns

Individuelle Abweichungen verursachen eine verdeckte Dauerbelastung:

• Jede Erweiterung schafft dauerhafte Pflichten: Testsuiten, Regressionsanalysen, Dokumentation, Support-Tickets und Sicherheitsprüfungen.
• Upgrades werden zu risikoreichen Befragungen: „Warum gibt es das? Wer ist verantwortlich? Was geht kaputt, wenn wir es entfernen?“
• Ausscheidende Fachleute hinterlassen „versteinerte Entscheidungen“ im System und erhöhen den Wartungsaufwand.³

Erkenntnis: Die erste Anpassung erscheint harmlos; die zweihundertste führt zur Lähmung. Studien zu ERP-Migrationen zeigen, dass Unternehmen mit einem hohen Anpassungsanteil drei- bis fünfmal höhere Upgrade-Kosten haben als vergleichbare Unternehmen mit Clean Core.²

3. Stakeholder-Anfragen verstehen: drei Grundtypen

Stakeholder formulieren ihren Bedarf selten präzise. „Das brauchen wir“ umfasst meist drei Kategorien:

1. Compliance-getrieben: Gesetzlich vorgeschrieben, etwa Prüfpfade oder Sicherheitsprotokolle.⁵
2. Differenzierungsgetrieben: Schafft Kundennutzen, etwa individuelle Preislogik, die höhere Preise ermöglicht.
3. Komfortgetrieben: Beruht auf Gewohnheiten oder Vorlieben, etwa bisherigen Layouts.

Ein erfahrenes Team ordnet Anfragen zuerst ein, bevor es sie erfüllt: Compliance in standardkonforme Kernerweiterungen, Differenzierung in Sidecar-Lösungen und Komfort in Low-Code-Oberflächen. Eine falsche Einordnung schafft technische Schulden.⁶

4. Kritische Entscheidungen in der Praxis

Jede Entscheidung folgt derselben Struktur: die typische Stakeholder-Aussage, die dahinterliegende Dynamik, eine sinnvolle Antwort und ein problematisches Gegenmuster.

Entscheidung Nr. 1: „Unser bisheriges Bildschirm-Layout nachbauen“

Aussage: „Fügen Sie einfach sechs Felder hinzu und verschieben Sie die Schaltflächen.“

Dynamik: Festhalten an vertrauter Bedienung wird als geschäftskritisch dargestellt.

Sinnvolle Antwort: Prüfen Sie Compliance- und Datenanforderungen, etwa Pflichtfelder für gesetzliche Berichte. Geht es nur um die Darstellung:

• Optimieren Sie Rollen und Voreinstellungen für persönliche Ansichten, ohne den Kern zu verändern.
• Nutzen Sie Fiori und Standard-UX-Werkzeuge, die schnelle Upgrades und geringeren Wartungsaufwand unterstützen.⁷
• Bereinigen Sie Stammdaten, um Darstellungsfehler an der Ursache zu beseitigen.⁸

Problematisches Muster: Oberflächenanpassungen verankern abweichende Abläufe direkt im Kern. Individueller Code bläht ihn auf, schafft technische Schulden und erhöht durch mangelhafte Dokumentation und ungenutzte Artefakte den Wartungsaufwand. Upgrades werden dadurch komplex und riskant.⁷⁸⁹

Erkenntnis: Standardoberflächen erleichtern die Akzeptanz, weil Nutzer mit dem SAP-Ökosystem vertraut sind. Individuelle Oberflächen schaffen dagegen oft unnötige Komplexität, die spätere Wartung und Upgrades erschwert.⁷⁸

Entscheidung Nr. 2: „Individuelle Preis-, ATP- oder Abrechnungslogik einbetten“

Aussage: „Das ist unser Alleinstellungsmerkmal.“

Dynamik: Echter Vorteil oder historisch gewachsene Behelfslösung?

Sinnvolle Antwort: Verlangen Sie eine knappe geschäftliche Begründung. Fragen Sie: „Lässt sich dasselbe Ergebnis mit anderen Regeln erreichen?“ Wenn die Logik tatsächlich differenziert:

• Kapseln Sie sie in ABAP Cloud oder BTP-Erweiterungen, um den Kern intakt zu halten und Upgrades zu beschleunigen.¹
• Prüfen Sie Standardoptionen wie Kalkulationsschemata oder ATP-Regeln, bevor Sie individuellen Code entwickeln.
• Validieren Sie das Alleinstellungsmerkmal mit Sidecar-Prototypen, ohne den Kern zu belasten.¹

Problematisches Muster: Regeln ohne klare Verantwortung fest in Kernobjekte einzubauen schafft verflochtene Abhängigkeiten. Sie erhöhen die Wartungslast, erschweren Regressionstests bei Upgrades und fördern technische Schulden durch undokumentierte, „versteinerte“ Logik.³⁴

Erkenntnis: Ein Alleinstellungsmerkmal auf erweiterbaren Plattformen wie BTP umzusetzen bewahrt den Handlungsspielraum des Clean Core. Es ermöglicht schnelle Innovation und herstellerkonforme Weiterentwicklung, statt durch eingebettete Anpassungen Upgrade-Kosten um den Faktor drei bis fünf zu erhöhen.²

Entscheidung Nr. 3: „Bestehende Freigabe-Workflows exakt spiegeln“

Aussage: „Die Prüfer akzeptieren keine Abweichungen.“

Dynamik: Prüfungsangst trifft auf unklare Zuständigkeiten.

Sinnvolle Antwort: Trennen Sie zwingende Prüfanforderungen von Vorlieben. Richten Sie sich nach Rollen, Schwellenwerten und Ausnahmen statt nach einzelnen Personen:

• Bilden Sie die Anforderungen mit konfigurierbaren Regeln in Standard-Workflow-Engines von SAP ab.⁵
• Nutzen Sie BRF+ für dynamische Entscheidungen statt fest codierter Genehmigerlisten.
• Validieren Sie die Lösung vor der Implementierung durch simulierte Prüfungen.⁵

Problematisches Muster: Freigabeketten, die das Organigramm abbilden und jedes Quartal veralten, verankern personenspezifische Logik. Das fördert Überalterung, erzeugt bei Rollenwechseln mehr Support-Tickets und macht Upgrades zur riskanten Suche nach Abhängigkeiten.⁷⁹

Erkenntnis: Standard-Workflow-Werkzeuge ermöglichen prüfungssichere Flexibilität mit wenigen Berührungspunkten zum Kern. Sie schaffen klare Verantwortung und Agilität, während individuelle Ketten diffuse Zuständigkeiten und Wartungs-„Zinsen“ verstärken.⁴

Entscheidung Nr. 4: „Diesen bisherigen Bericht exakt liefern“

Aussage: „Die Finanzabteilung verlangt dieses Format.“

Dynamik: Berichtsgewohnheiten bestimmen Transaktionen.

Sinnvolle Antwort: Klären Sie, welche Entscheidung der Bericht unterstützt. Vertraglich vorgeschriebene Ausgaben gehören in Erweiterungen; interne Ansichten in SAC oder Embedded Analytics:

• Nutzen Sie SAP Analytics Cloud für pixelgenaue individuelle Ansichten ohne Änderungen an Transaktionen.
• Integrieren Sie Analysen direkt in Fiori-Apps für Erkenntnisse in Echtzeit.
• Standardisieren Sie Eingaben über bereinigte Datenmodelle.⁸

Problematisches Muster: Transaktionen wegen Layoutwünschen umzugestalten bringt berichtsspezifische Felder und Logik in Kerntabellen. Ungenutzte Artefakte, schlechte Dokumentation und verborgene Auswirkungen sammeln sich an, bis Upgrades blockiert sind.³⁷

5. Entscheidungen in leistungsfähigen Teams beschleunigen

Leistungsfähige Teams behandeln Anpassungsentscheidungen als wichtige Weichenstellungen für künftige Agilität. Sie beschleunigen sie diszipliniert, statt sich in Analysen zu verlieren. Dieses an agiler ERP-Governance orientierte Vorgehen richtet Entscheidungen am Clean Core aus und verhindert technische Schulden durch endlose Debatten.⁹

Die Zwei-Termine-Regel

Wiederkehrende Diskussionen über mehr als zwei Termine hinweg weisen auf Prozessprobleme hin und gehören in die Governance. Lange Debatten verdecken häufig Ängste vor Upgrade-Risiken oder undokumentierten Anpassungen. Dadurch wachsen technische Schulden samt „Zinsen“ wie erhöhtem Wartungs- und Testaufwand.³⁷

Begrenzen Sie die Ideenfindung in der Praxis auf zwei Termine à 60 Minuten:

• Termin 1 ordnet Anforderungen den Standardfunktionen zu
• Termin 2 erprobt Alternativen, etwa BTP-Erweiterungen

Reicht das nicht aus? Eskalieren Sie mit einer einseitigen Vorlage, die Risiken problematischer Muster, etwa einen aufgeblähten Kern durch den Nachbau alter Abläufe, und einen vorgeschlagenen Governance-Beschluss aufzeigt.

Entscheidung Nr. 5: „Lokale Ländervarianten berücksichtigen“

Aussage: „Bei uns ist alles anders.“

Dynamik: Gesetzliche Anforderungen oder kulturelle Vorlieben?

Sinnvolle Antwort: Fordern Sie einen rechtlichen Nachweis. Setzen Sie auf 80/20: eine globale Baseline mit minimalen Ergänzungen:

• Nutzen Sie länderspezifische SAP-Inhalte und gesetzliche Erweiterungen.
• Begrenzen Sie kulturelle Vorlieben auf Low-Code-Apps oder Stammdatenvarianten.⁶
• Harmonisieren Sie mit globalen Vorlagen und klar begrenzten Lokalisierungen.

Problematisches Muster: Eigene Prozesse je Land untergraben die Standardisierung und fragmentieren den Kern durch variantenspezifischen Code. Das erschwert globale Upgrades, vervielfacht Testsuiten und verstetigt Bequemlichkeit, die als Notwendigkeit dargestellt wird.⁶²

Erkenntnis: Globale Standardprozesse mit gezielten Erweiterungen erhalten das Upgrade-Tempo und reduzieren technische Schulden. So entsteht Raum für echte Differenzierung jenseits lokaler Gewohnheiten.³

Entscheidung Nr. 6: „Schnittstellen an die Mappings der Altsysteme anpassen“

Aussage: „Die ändern nichts.“

Dynamik: Externe technische Schulden dringen in den Kern ein.

Sinnvolle Antwort: Übersetzen Sie an den Systemgrenzen über APIs oder BTP und halten Sie das Chaos draußen:

• Standardisieren Sie saubere Integrationen auf OData-APIs oder RAP.
• Nutzen Sie die BTP Integration Suite für Transformationen und schützen Sie den Kern vor der Unordnung der Altsysteme.¹
• Vereinbaren Sie vor dem Go-live gemeinsame API-Verträge.

Problematisches Muster: Das ERP wird zum Universaladapter. Individuelle Mappings blähen den Kern auf und schaffen Schnittstellenwildwuchs, Datenqualitätsprobleme und endlose Upgrade-Prüfungen wegen jeder Eigenheit der Altsysteme.⁷⁴

Erkenntnis: API-basierte Systemgrenzen fördern Modularität und Zukunftsfähigkeit. Sie reduzieren die „Zinsen“ externer technischer Schulden, statt durch Kernanpassungen die Wartungslähmung zu verstärken.³¹⁰

Vier Fragen, die Blockaden lösen

Diese Fragen prüfen Begründungen für Kernmodifikationen, indem sie Upgrade-Schwachstellen, echte Notwendigkeiten, Verantwortung und den kleinstmöglichen Eingriff sichtbar machen:

1. Was funktioniert nach einem Upgrade nicht mehr? Suchen Sie nach verborgenen Abhängigkeiten, etwa individueller Preislogik, die Regressionstests zum Albtraum macht.⁴ Das zwingt zur Quantifizierung: „Diese Modifikation verdreifacht den Analyseaufwand bei Upgrades.“²
2. Differenzierung, Compliance oder Komfort? Ordnen Sie konsequent zu. Echte Alleinstellungsmerkmale gehören auf BTP; Compliance nutzt gesetzliche Inhalte⁶; Komfort ordnet sich dem Standard unter.²
3. Wer trägt die Verantwortung für die nächsten drei Jahre? Legen Sie dauerhafte Verantwortung fest. Ein vages „Finanzen/IT“ schafft diffuse Zuständigkeiten; benannte Verantwortliche übernehmen Wartungs-„Kapital und Zinsen“.⁴
4. Was ist die kleinste tragfähige Änderung? Suchen Sie den schlanksten Weg, etwa SAC für Berichte statt Eingriffe in Transaktionen. Das passt zu modular zusammensetzbaren Architekturen und ermöglicht schnelle Neukombinationen ohne Belastung des Kerns.¹⁰¹¹

Definition of Done

Keine Entscheidung wird ohne diese verbindlichen Punkte abgeschlossen. Sie sichern Nachvollziehbarkeit und reduzieren Risiken:

• Dokumentierte Begründung: Ein Absatz zum Business Case und den Alternativen, abgelegt in einem Abweichungsverzeichnis mit Hinweisen auf problematische Muster.
• Benannte Verantwortung: Eine Person oder Gruppe mit dreijährigem Mandat, einschließlich Simulationen der Upgrade-Auswirkungen.
• Auswirkungsbewertung: Eine Bewertungsmatrix für Wartungskosten, Upgrade-Mehraufwand und Schuldenaufbau, etwa ein Faktor von drei bis fünf bei eingebetteten Anpassungen.²
• Zusätzlich: Ein Validierungsprototyp, etwa ein BTP-Sidecar oder SAC-Dashboard, reduziert Risiken vor der verbindlichen Entscheidung.¹

6. Das unausgesprochene Spektrum der Zielkonflikte

Ein zu rigide durchgesetzter Clean Core führt vorhersehbar dazu, dass Menschen ihn umgehen. Wenn Teams eine nötige Änderung nicht auf offiziellem Weg durchsetzen können, weil die Governance langsam, die Hürde unrealistisch oder „Nein“ die Standardantwort ist, hören sie nicht auf zu liefern. Sie improvisieren.

So entstehen Schattensysteme: Tabellen werden zur betrieblichen Wahrheit, lokale Datenbanken replizieren „vorübergehend“ Stammdaten, Low-Code-Apps bauen Freigaben nach und Einzeltools übernehmen stillschweigend Berichte oder Planung.

Das Ergebnis ist weniger Kontrolle: fragmentierte Daten, unklare Verantwortung, Sicherheitslücken und eine Anwendungslandschaft, die gerade deshalb komplexer wird, weil der Kern als unantastbar gilt. Empirisch sind Schattensysteme oft eng mit ERP-Daten und -Funktionen verflochten. Dadurch lassen sie sich später schwer ablösen: Sie werden inoffiziell Teil des Prozessgefüges.¹⁰

Zu viel Nachsicht führt dagegen in die entgegengesetzte Falle: unkontrollierte Anpassungen. Zu Beginn eines Programms wirken individuelle Änderungen effizient: „nur eine Erweiterung“, „nur eine kleine Anpassung“, „nur ein Mapping“. Doch die langfristigen Kosten wachsen. Jede Abweichung erhöht typischerweise den Lebenszyklusaufwand: Dokumentation, Berechtigungsfolgen, erweiterter Testumfang, zusätzliche Fehlerquellen und Nacharbeiten bei Upgrades.

Mit der Zeit entstehen technische Schulden im ganz praktischen Sinn: Wartungs-„Zinsen“, die in jedem Release-Zyklus fällig werden, plus soziale Schulden durch verlorene Begründungen, unklare Verantwortung und Wissen, das bei wenigen Personen liegt.

Die unbequeme Wahrheit: Beide Extreme können Transformationen zum Stillstand bringen: Starrheit führt zu Schatten-IT; Beliebigkeit zum Upgrade-Stau.

In realen Projekten bewährt sich meist dieses Gleichgewicht: strenge Grenzen für den ERP-Kern, flexible Wege für alles andere. In der Praxis schützen Sie damit ein sauberes Transaktionsfundament: stabile Stammdaten-Semantik, Standard-Geschäftsobjekte und minimale invasive Änderungen. Zugleich lenken Sie Differenzierung bewusst in modular zusammensetzbare Sidecars: APIs und Integrationsebenen für systemübergreifende Abläufe, passende Workflows und Automatisierung sowie Analysen außerhalb des Transaktionskerns.

7. Erfolgsindikatoren am Ende der Explore-Phase

Am Ende von Explore sollte Clean Core kein Glaubenssatz sein. Einige konkrete Signale sollten zeigen, dass Ihr Programm unter Kontrolle ist und die Umsetzung nicht zu einer endlosen Diskussion darüber wird, was in den Workshops eigentlich gemeint war.

1. Sie haben ein knappes Abweichungsverzeichnis mit fundierten Entscheidungen

Keine Tabellenablage, in der alles versandet. Eine kurze Liste, oft mit 10 bis 30 Einträgen, mit bewussten Standardabweichungen und jeweils:

• der Abweichung in klarer Sprache
• ihrer Begründung
• der verantwortlichen Rolle statt einer einzelnen Person
• ihrem Ort: Kernkonfiguration, Erweiterung oder Systemgrenze
• ihren Berührungspunkten: Prozesse, Integrationen, Berechtigungen, Tests

Wenn ein neues Teammitglied in 20 Minuten verstehen kann, „was wir geändert haben und warum“, sind Sie gut aufgestellt.

2. Ihre globalen Prozesse sind stabil und lokale Varianten bewusst selten

Sie „erzwingen“ keine globale Lösung. Sie tun, was erfahrene Programme tun:

• Globaler Prozess = der Standard
• Lokale Ergänzungen = die Ausnahme

Das bedeutet: Lokale Unterschiede sind

• klar begrenzt: dieses Land, dieser Schritt, diese Regel
• auf eine echte Einschränkung zurückführbar: Regulierung, Marktstruktur oder Anforderungen einer juristischen Person
• auf Wiederverwendung geprüft: „Ist das eigentlich nur ein Parameter, den wir standardisieren sollten?“

Der Maßstab ist einfach: Lokale Ausnahmen wirken wie saubere Ergänzungen, nicht wie Paralleluniversen.

3. Ihre Schnittstellenverträge sind präzise und der Kern dient nicht als Adapter

Am Ende von Explore sollte für Integrationen nicht gelten: „Das klären wir in der Umsetzung.“ Sie sollten bereits Folgendes haben:

• klare Verantwortung je Schnittstelle für Quelle, Ziel und Systemgrenze
• stabile Geschäftsobjekte sowie Ereignis- und API-Definitionen: Was wird wann und warum übertragen?
• Mapping-Regeln, die kein externes Chaos ins ERP tragen

Mit präzisen Schnittstellenverträgen können Sie Systeme ändern, ohne alles neu schreiben zu müssen. Zugleich vermeiden Sie die klassische Falle, fremde Einschränkungen dauerhaft in Ihrem Kern zu verankern.

4. Ihr Backlog enthält keine versteckten Kernmodifikationen

Das ist das heimtückischste Fehlermuster: Kernänderungen verstecken sich hinter harmlosen Tickets wie:

• „kleine Erweiterung“
• „minimale Bildschirmanpassung“
• „schnelle Logikkorrektur“
• „vorübergehende Behelfslösung“

Ein erfolgreiches Explore-Ende zeigt sich in einem Backlog, in dem:

• alles mit möglichem Upgrade-Risiko früh gekennzeichnet ist
• vor Beginn der Umsetzung entschieden ist, „wo das umgesetzt wird“
• „vorübergehende“ Elemente Ablaufkriterien haben, andernfalls sind sie nicht vorübergehend

Wenn Ihr Backlog architektonische Auswirkungen offenlegt, entdecken Sie Ihr tatsächliches Design nicht erst beim Testen.

5. Sie vertrauen dem nächsten Upgrade, statt Ermittlungsarbeit zu fürchten

Sie brauchen keine absolute Gewissheit. Sie brauchen das Vertrauen, dass Ihr künftiges Ich nicht darunter leiden wird.

Upgrade-Zuversicht bedeutet:

• Abweichungen sind selten, bewusst und gut abgegrenzt
• die Verantwortung ist klar
• Sie können erklären, wie jede Abweichung getestet und betreut wird
• niemand fürchtet den Ausdruck „nächstes Release“

Angst vor der Spurensuche klingt so: „Fassen wir das lieber nicht an“, „Niemand weiß, wie es funktioniert“ oder „Darum kümmern wir uns nach dem Go-live“. So entstehen die Schulden eines unaufgeräumten Kerns in Echtzeit.

8. Fazit: Clean Core als Wettbewerbsschutz

Alleinstellungsmerkmale gedeihen nicht in eigenwilligen, stark angepassten ERPs, sondern durch agile Weiterentwicklung. Sie ermöglicht schnelle Kurswechsel bei Produkten, Kanälen und Lieferketten. Ein sauberer Kern dient daher nicht nur der IT, sondern ermöglicht die ständige Erneuerung des Geschäfts. Das entspricht Forschungsergebnissen, die ERP-Systeme als kritische, hochkomplexe Infrastruktur beschreiben, bei der große Änderungen erhebliche Risiken bergen und strukturierte Entscheidungen zu Upgrades und Ablösungen erfordern.¹²

Teams, die Clean Core erfolgreich umsetzen, behandeln ihn als Disziplin statt als Doktrin. Sie wissen, wann sie konsequent bleiben, wann sie bewusst einen anderen Weg wählen und wann sie eskalieren müssen, bevor eine kleine Ausnahme zur dauerhaften Einschränkung wird.

Das unterscheidet einen Kern, der das Geschäft ermöglicht, von einem, der es irgendwann ausbremst.

Quellen

1. Schreieck, M., et al. (2021). The evolution of design principles enabling knowledge platform modularity. European Journal of Information Systems. ↩
2. Sundaram, K. T. (2022). Five Key Steps Realize the Digital Transformation Value and Ensure a Successful SAP HANA Transformation in Global Organizations. ↩
3. Asatiani, A., et al. (2025). Technical Debt Is Killing Digital Transformation, But There Is a Way Out. California Management Review. ↩
4. Rinta-Kahila, T., et al. (2023). Getting Trapped in Technical Debt: Sociotechnical Analysis of a Legacy System's Replacement. MIS Quarterly. ↩
5. Abdul-Azeez, O. Y., et al. (2024). Best practices in SAP implementations: Enhancing project management to overcome common challenges. ↩
6. Munkácsi, I., et al. (2024). Implementation Challenges of Industry-Specific ERP System Solutions by Utilizing Best Practices. ↩
7. Khosroshahi, P. A., et al. (2016). Causes and Consequences of Application Portfolio Complexity. ↩
8. Light, B. (2001). The maintenance implications of the customization of ERP software. ↩
9. Nakayama, M., et al. (2023). Organic transformation of ERP documentation practices. ↩
10. Sunyaev, A., et al. (2023). Shadow IT research perspectives. ↩
11. Teng, X., et al. (2023). Process variants performance management. ↩
12. Goman, M., & Koch, S. (2021). A Process Model for ERP Upgrade and Replacement Decisions. ↩