SAP hat ERP zum vertrauenswürdigen System of Record für globale Unternehmen gemacht. Erfahren Sie, warum Migrationen — Daten, Prozesse und Menschen — eine dauerhafte Wettbewerbsstärke (Burggraben) schaffen.
Ein System of Record ist der Ort, den Ihr Unternehmen als die offizielle Wahrheit für kritische Geschäftsfakten behandelt — Kunden, Produkte, Preise, Aufträge, Rechnungen, Inventar, Mitarbeiter und die Regeln, die sie steuern. Wenn zwei Systeme widersprüchliche Angaben liefern, gewinnt das System of Record.
Das ist wichtig, weil Führungsentscheidungen, Prüfungen und der tägliche Betrieb alle konsistente Antworten auf einfache Fragen brauchen: Was haben wir verkauft? An wen? Mit welcher Marge? Was schulden wir? Was haben wir auf Lager? Wenn diese Antworten je nach Region oder Tool variieren, verbringt die Organisation ihre Energie damit, Daten abzugleichen, statt das Geschäft zu steuern.
SAP hat diese Rolle in vielen globalen Unternehmen eingenommen, weil es an der Schnittstelle von Finanzen, Supply Chain und Betrieb sitzt — den Bereichen, in denen Genauigkeit und Kontrollen nicht verhandelbar sind. Im Laufe der Zeit bauten Unternehmen Richtlinien, Freigaben und Compliance-Routinen rund um SAP-Daten und -Transaktionen auf. Sobald das passiert, ist SAP nicht mehr „nur Software“; es wird zum Rückgrat, auf das andere Systeme verweisen.
Der Wettbewerbsvorteil liegt nicht in der Lizenz. Der Vorteil ist die organisatorische Fähigkeit zu migrieren — Daten zu verschieben, Prozesse neu zu entwerfen, Systeme zu integrieren und Menschen mitzunehmen, ohne das Geschäft zu unterbrechen. Wenn Sie Ihr ERP schneller und sicherer modernisieren können als Ihre Wettbewerber, können Sie neue Betriebsmodelle, Übernahmen und regulatorische Anforderungen mit weniger Reibung annehmen.
Dies ist keine Anbieter-Geschichte. Es ist eine praktische Sammlung von Lehren für Führungskräfte: wo Migrationen wirklich scheitern, wo die Arbeit wirklich liegt und wie man sich vorbereitet.
Die Beispiele sind SAP-zentriert, aber die Muster gelten für andere große ERPs: Sobald ein ERP Ihr System of Record wird, wird Veränderung zu einer Fähigkeit, die Sie entweder aufbauen — oder später teuer einkaufen.
ERP begann nicht als das „Gehirn“ des Unternehmens. Frühe ERP-Programme wurden oft als Finanz- und Rechnungswesen-Modernisierungen gerechtfertigt: bessere Bücher, schnellere Abschlüsse, saubereres Reporting. Aber als die Finanzdaten strukturiert und verlässlich wurden, war es naheliegend, die Aktivitäten zu verbinden, die diese Zahlen erzeugen — Einkauf, Produktion, Versand, Service und Gehaltsabrechnung.
Im Laufe der Zeit erweiterte sich ERP vom Erfassen von Transaktionen hin zur Koordination von Arbeit. Eine Bestellung ist nicht mehr nur Papierkram; sie triggert Genehmigungen, aktualisiert Budgets, reserviert Inventar, plant Wareneingänge und fließt letztlich in Kreditorenbuchungen. Dasselbe Muster wiederholt sich über Order-to-Cash, Hire-to-Retire und Plan-to-Produce.
Standardisierung machte diese Expansion skalierbar. Große Unternehmen standardisierten auf:
Als ERP zum System of Record wurde, wurde Vertrauen zum eigentlichen Produkt. Führungskräfte verlassen sich auf ERP, weil es Prüfpfade und Kontrollen unterstützt: wer was genehmigt hat, wann Änderungen vorgenommen wurden, welche Richtlinie angewandt wurde und wie jedes operative Ereignis die finanziellen Ergebnisse beeinflusst. Wenn das ERP gut geführt ist, gibt es eine einzige Version der Schlüsselzahlen — Umsatz, Marge, Inventarwert, Mitarbeiteranzahl — die einer Prüfung standhält.
Diese Konsistenz hat ihren Preis. Zentrale Templates, geteilte Stammdaten und standardisierte Prozesse reduzieren lokale Autonomie. Ein Werk oder ein Landesteam kann sich eingeengt fühlen, wenn ein globales Modell nicht zu lokalen Gewohnheiten oder Vorschriften passt.
Die besten ERP-Programme behandeln das als bewusste Designentscheidung: Standardisieren, was vergleichbar und kontrollierbar sein muss, und zulassen, wo Flexibilität echten Kundenwert oder Compliance ermöglicht. Dieses Gleichgewicht verwandelt ERP vom „Programm“ zum Betriebssystem.
Globale Firmen standardisierten nicht auf SAP, weil es "one size fits all" ist. Sie taten es, weil SAP konsistent genug gemacht werden konnte, um das Geschäft global zu betreiben, während dennoch lokale Abweichungen dort möglich blieben, wo Steuern, Gesetze oder Betriebsmodelle es erfordern.
Unternehmen mit Dutzenden Geschäftsbereichen haben ein wiederkehrendes Problem: Jedes Land und jede Produktlinie benötigt dieselben Kerndisziplinen (Order-to-Cash, Procure-to-Pay, Record-to-Report), aber keines arbeitet exakt gleich.
Die Stärke von SAP liegt in der Fähigkeit, gemeinsame Prozesstemplates zu unterstützen — gemeinsame Definitionen für Kunden, Produkte, Preise, Rechnungen, Genehmigungen — und gleichzeitig länderspezifische Anforderungen (Steuern, Währung, Reporting, Dokumentation) zu konfigurieren. Dieses Gleichgewicht ermöglicht Standardisierung, ohne jeden Standort in identische Abläufe zu pressen.
Wenn ERP, Finanzen, Einkauf, Fertigung und Logistik in getrennten Systemen laufen, verbringen Teams erstaunlich viel Zeit mit Übergaben: Daten neu erfassen, Summen abgleichen, fehlende Statusupdates nachverfolgen und erklären, „warum System A Versand anzeigt, System B aber nicht als fakturiert“.
Die Standardisierung auf SAP reduzierte oft die Zahl dieser Nahtstellen. Weniger Übergaben bedeuten in der Regel weniger Abstimmungszyklen, klarere Datenverantwortung und schnellere Root-Cause-Analysen, wenn etwas schiefgeht. Es ist nicht automatisch — aber ein wiederholbares Muster, wenn Integration manuelle Brücken ersetzt.
Große Unternehmen brauchen Kontrolle: Trennung von Zuständigkeiten, Genehmigungsketten, Audit-Trails und Compliance-Checks.
SAP unterstützt Governance by Design — Rollen und Berechtigungen, Workflow-Genehmigungen für Beschaffung und Zahlungen und Prozesskontrollen, die konsistent über Regionen hinweg durchgesetzt werden können. Der Nutzen ist nicht „perfekte Compliance“, sondern die Fähigkeit, Richtlinien in den Systemen zu operationalisieren, die die Leute tatsächlich nutzen.
Eine ERP-Migration ist nicht nur „Daten bewegen“ von A nach B. Es ist eine koordinierte Veränderung, wie das Geschäft läuft: Prozesse neu designen, Integrationen neu bauen, Kontrollen und Reporting aktualisieren, Sicherheitsrollen anpassen und Schulungen, die neue Verhaltensweisen verankern. Das Daten-Cutover-Wochenende ist nur der sichtbarste Moment einer viel längeren Transformation.
Zwei Unternehmen können dieselbe ERP-Software kaufen und dennoch völlig unterschiedliche Migrationsaufwände haben. Ihr Produktkatalog, Preisregeln, Freigabepfade, regulatorische Pflichten, Übernahmehistorie und individuelle Schnittstellen schaffen ein einzigartiges Abhängigkeitsnetz. Migrieren heißt, diese Realität in neue Konfigurationen, Integrationen und Governance-Routinen zu übersetzen, ohne den Betrieb zu unterbrechen.
Diese Arbeit ist schwer zu kopieren, weil sie in der tatsächlichen Funktionsweise Ihres Unternehmens verankert ist. Wettbewerber sehen das Ergebnis — schnellere Abschlüsse, sauberere Stammdaten, weniger manuelle Workarounds — aber sie können das Wissen, das Sie beim Entwirren von Ausnahmen, Abgleichen von Definitionen und Abstimmen von Teams aufgebaut haben, nicht leicht reproduzieren.
Die erste große ERP-Migration zwingt Sie zu lernen, wo die Organisation unklar ist: wer Stammdaten besitzt, welche Berichte vertrauenswürdig sind, welche Kontrollen real vs. „tribal“ sind und welche Integrationen undokumentiert existieren. Nachdem man das einmal durchlaufen hat, hat man oft bessere Templates, klarere Entscheidungsrechte und wiederverwendbare Integrationsmuster.
Die zweite Migration ist oft schneller und sicherer, nicht weil die Technologie leichter wäre, sondern weil Ihre Organisation besser ist.
Wenn Migrationen wiederholbar werden — unterstützt durch starke Datenverantwortung, Testdisziplin und Change Management — gewinnen Sie strategische Flexibilität. Sie können Übernahmen schneller integrieren, Innovationen wie S/4HANA sicherer einführen und modernisieren, ohne das Geschäft zu blockieren. Diese Fähigkeit ist ein Wettbewerbsvorteil, den Sie durch konsequentes, gutes Arbeiten aufbauen.
ERP-Migrationen passieren selten, weil ein Unternehmen plötzlich „modernisieren will“. Sie bleiben auf der Roadmap, weil sich das Geschäft weiterentwickelt — und SAP im Zentrum dessen steht, wie Finanzen, Supply Chain und Betrieb erfasst werden.
Ein Migrationsprogramm wird oft durch Ereignisse vorgezogen, die ändern, was das System unterstützen muss:
Diese Auslöser sind keine Randfälle — sie sind normal für globale Unternehmen. Deshalb wird aus „wir migrieren später“ oft „wir migrieren mitten in einer Krise".
Wenn Migrationen verschoben werden, kompensieren Organisationen mit Provisorien: parallele Systeme, Zusatztools, zusätzliche Abstimmungen und tabellenlastige Workarounds. Das Ergebnis ist nicht nur IT-Komplexität — es sind langsamere Abschlüsse, langsameres Reporting und mehr Zeit für Erklärungen statt Handeln.
Verzögerungen verschlimmern auch Datenprobleme. Je länger Stammdatenprobleme bestehen, desto mehr downstream-Prozesse verlassen sich auf Ausnahmen und manuelle Korrekturen.
Selbst wenn die Entscheidung gefallen ist, kann der Kalender das Ergebnis machen oder brechen. Peak-Season, Jahresabschluss, wichtige Produkteinführungen und geplante Stilllegungen von Anlagen schaffen „No-Fly-Zonen“. Außerdem sind die selben Schlüsselpersonen, die für Migration gebraucht werden — Finance SMEs, Supply-Chain-Leads, Integrationsverantwortliche — oft diejenigen, die man am wenigsten entbehren kann.
Weil Wandel konstant ist, verschiebt sich der Vorteil zu Unternehmen, die wiederholbare Migrationsfähigkeit aufbauen: klare Datenverantwortung, disziplinierte Integrationsmuster und Governance, die Reorganisationen absorbiert, ohne den gesamten Plan zurückzusetzen. Migration wird so zu einer Betriebsfähigkeit, nicht zu einem einmaligen Projekt.
ERP-Migrationen scheitern selten an der Software. Sie stocken, weil die Organisation sich nicht darauf einigen kann, was ihre Daten bedeuten, wer sie besitzt und wie sauber sie vor dem Umzug sein müssen.
Betrachten Sie transaktionale Daten als die „Ereignisse“, die Ihr Geschäft täglich aufzeichnet: Aufträge, Rechnungen, Wareneingänge, Zeiterfassungen, Zahlungen. Diese sind volumenstark und zeitgestempelt.
Stammdaten sind die „gemeinsame Referenz“, auf die sich diese Ereignisse stützen: Kunden-, Lieferanten-, Materialstämme, Stücklisten, Werke, Kostenstellen, Preisbedingungen, Kontenplan. In SAP ERP machen Stammdaten Transaktionen vergleichbar und berichtsfähig.
Ein einfaches Beispiel: Eine Rechnung (Transaktion) ist nur so genau wie der Kundenstamm (Stammdatum), auf den sie verweist — Adresse, Steuer-ID, Zahlungsbedingungen, Kreditlimits.
Die meisten Unternehmen entdecken während einer ERP-Migration dieselben Probleme:
Datenbereinigung ist kein IT-Aufräumprojekt; es ist eine Geschäftsentscheidung. Daten-Eigentümer (oft in Finanzen, Sales Ops, Supply Chain, Einkauf) müssen Standards definieren: welche Felder Pflicht sind, wie Benennungen funktionieren, was der Golden Record ist und welches Team Änderungen genehmigt.
Wenn Ownership unklar ist, bleibt Qualität subjektiv — und das hat reale Konsequenzen: schwächere Forecasts, langsamere Quote-to-Cash-Prozesse, inkonsistente Kundenerfahrungen und Prüfungsrisiken, wenn Audits sich auf unvollständige oder widersprüchliche Datensätze stützen.
Ein neues SAP-System kann technisch „live“ sein und sich trotzdem fehlerhaft anfühlen, wenn tägliche Prozesse und Integrationen nicht sorgfältig neu aufgebaut wurden. Die meisten Migrationsschmerzen treten hier auf: Aufträge, die nicht End-to-End fließen, Genehmigungen, die Kontrollen umgehen, oder Berichte, die nicht mehr mit der operativen Realität übereinstimmen.
Viele Legacy-ERPs sammelten jahrelang Custom-Code für Edge-Cases, lokale Varianten und „das haben wir schon immer so gemacht“. Moderne SAP-Programme folgen zunehmend einem Clean Core-Ansatz: SAP näher am Standard halten, Erweiterungen in wohldefinierte Schichten auslagern und Änderungen reduzieren, die Upgrades erschweren.
Das heißt nicht „keine Anpassung“. Es bedeutet bewusstes Handeln: Wenn eine Anpassung nicht klar Umsatz, Compliance oder echten Wettbewerbsvorteil schützt, ist sie ein Kandidat für Redesign oder Abschaffung.
Standardisierung von Finanzen, grundlegender Beschaffung und gängigen Supply-Chain-Schritten zahlt sich meist schnell aus: gemeinsame Datendefinitionen, weniger Ausnahmen, einfacheres Training und globaleres Reporting.
Bewahren Sie Differenzierung dort, wo Kunden sie bemerken und schätzen — Preislogik, Fulfillment-Versprechen, After-Sales-Service oder Produktkonfiguration. Der praktische Test lautet: Wenn wir hier einen Standardprozess einsetzen würden, würde sich unsere Marktposition ändern? Wenn nicht, standardisieren.
Legacy-Integrationen beruhen oft auf brüchigen Punkt-zu-Punkt-Verbindungen und Batch-Dateien. Moderne Integration ähnelt eher zuverlässigen „Connectors“ zwischen Systemen:
Das Ziel ist nicht Neuheit — sondern weniger Brüche, klarere Verantwortlichkeiten und schnellere Veränderung.
In der Praxis brauchen Teams oft auch leichte „surrounding apps" — interne Portale für Cutover-Tracking, Datenqualitäts-Warteschlangen, Exception-Triage-Dashboards oder rollenbasierte Aufgaben-Checklisten. Plattformen wie Koder.ai können helfen, solche unterstützenden Tools schnell über einen chatbasierten Workflow bereitzustellen (mit exportierbarem Quellcode), damit das Migrationsprogramm nicht durch lange Custom-Entwicklungszyklen für jede kleine, aber kritische Fähigkeit blockiert wird.
Kontrollen dürfen nicht erst nach dem Go-Live aufgesetzt werden. Genehmigungsschritte, Trennung von Zuständigkeiten, Protokollierung und Abstimmungen müssen in Workflows und Integrationen von Anfang an eingebaut werden. Andernfalls entstehen „Schattenprozesse“ in E-Mails und Tabellen — genau dort verschwindet Prüfbarkeit.
Behandeln Sie jede Integration wie eine finanzielle Transaktion: Wer hat was geändert, wann und warum — das sollte designbedingt nachvollziehbar sein.
Die meisten ERP-Programme scheitern nicht, weil die Software nicht konfigurierbar ist. Sie scheitern, weil die Organisation nicht die (und dauerhaft) erforderlichen Entscheidungen treffen und einhalten kann, die nötig sind, um Arbeit neu zu gestalten.
Drei Muster tauchen wiederholt auf:
Erfolgreiche Migrationen benennen spezifische Outcome-Verantwortliche, nicht nur Aufgaben:
Nutzer widersetzen sich nicht „SAP“; sie widersetzen sich Überraschungen. Eine Migration verändert Jobs: neue Genehmigungen, neue Übergaben, neues Exception-Handling und neue Kennzahlen, die Verzögerungen oder Nacharbeit offenlegen. Schulungen sollten rollenbasiert und szenariobasiert sein (was zu tun ist, wenn etwas schiefgeht) und Manager einschließen, die die neuen Dashboards interpretieren und die neuen Regeln durchsetzen.
Setzen Sie einen Takt, der Fortschritt erzwingt:
Wenn Menschen und Governance gut gehandhabt werden, wird technische Komplexität beherrschbar — und Migration wird zur Fähigkeit, nicht zum einmaligen Ereignis.
Eine ERP-Migration ist kein Schönheitswettbewerb. Realistisches Ziel ist, Risiko zu reduzieren und Time-to-Value zu beschleunigen — das Geschäft auf eine stabile, wartbare Plattform mit sauberen Daten und funktionierenden Prozessen zu bringen — statt überall gleichzeitig ein „perfektes" Redesign zu verfolgen.
Big-bang (einmaliger Cutover): Sie schalten alle Standorte, Prozesse und Nutzer auf einmal auf das neue System um.
Phasenweise Rollout (nach Region, Business Unit oder Prozess): Sie gehen gestaffelt vor.
Selektive Datenmigration (selektiver historischer Umfang): Sie übertragen nur, was nötig ist — oft offene Posten plus ein definiertes History-Fenster.
Behandeln Sie Tests als progressiven Trichter:
Wählen Sie Ihren Weg, indem Sie jede Hauptfläche bewerten nach:
Die „richtige" Strategie ist diejenige, die Ihrer operativen Risikotoleranz und Ihrer organisatorischen Kapazität entspricht — und gleichzeitig den Umfang eng genug hält, um ein echtes Zwischenziel zu liefern, nicht ein endloses Programm.
Der Wechsel von einem klassischen SAP-ERP zu S/4HANA (und besonders zu cloudgehostetem ERP) ist nicht nur ein technisches Upgrade. Er verändert, wie schnell Sie neue Fähigkeiten übernehmen können, wie stark Sie das System anpassen dürfen und wie „gute Governance" im Alltag aussehen muss.
S/4HANA basiert auf einem vereinfachten Datenmodell und einer In-Memory-Datenbank. Für Business-Teams bedeutet das in der Regel schnelleres Reporting und konsistentere Echtzeit-Sichten (z. B. Inventar, Finanzen und Auftragsstatus, die sauberer zusammenfallen).
Cloud-Hosting bringt eine weitere Verschiebung: SAP (und Ihr Cloud-Provider) übernimmt mehr der Plattformarbeit — Patching, Skalierung und Infrastruktur — sodass Ihr Team sich stärker auf Prozesse, Daten und Change konzentrieren kann.
Der Trade-off ist einfach:
Selbst im Cloud-ERP bleibt Sicherheit in Schlüsselbereichen Ihre Verantwortung:
„Go-Live" beendet die Arbeit nicht. Integrationen benötigen weiterhin Monitoring, Change-Koordination und Version-Management. Und Daten brauchen fortlaufende Verantwortung: Stammdatensstandards, Qualitätsregeln und Accountability, wenn Definitionen auseinanderdriften. Die Plattform modernisiert sich — Ihre Betriebsdisziplin muss ebenfalls reifen.
Betrachten Sie Readiness als Gate, nicht als Gefühl. Bevor Sie einem ERP-Migrationsplan (insbesondere einer S/4HANA-Migration) zustimmen, gleichen Sie ab, was „bereit" in konkreten, testbaren Begriffen bedeutet.
Zu viele Custom-Objekte ohne klaren Business-Wert, unbekannte Schnittstellen („finden wir in Tests") und schwache Datenverantwortung („IT wird die Daten richten") sind Top-Anzeichen dafür, dass Ihr Zeitplan illusorisch ist.
Wählen Sie eine kleine Menge Metriken und messen Sie sie jetzt: Zeit bis Finanzabschluss, Auftragsdurchlaufzeit, Inventargenauigkeit und User Adoption (Aufgabenerledigungsraten, Ticketvolumen pro Prozess).
Planen Sie Hypercare (klare Triage, tägliche Business-Checkpoints), ein priorisiertes Backlog (was nicht ins Go-Live geschafft hat) und eine Continuous-Improvement-Rhythmik mit Eigentümern und KPIs — damit das System besser wird, statt nur „online zu bleiben".
SAP hat seinen Platz als System of Record verdient, weil es kritische Unternehmensfakten — Aufträge, Inventar, Rechnungen, Gehaltsabrechnung, Compliance-Belege — so konsistent macht, dass ein globales Geschäft darauf laufen kann. Der langfristige Vorteil ist jedoch nicht allein SAP zu haben. Es ist die Fähigkeit, SAP sicher und wiederholt zu verändern, während andere ins Stocken geraten.
ERP-Migrationen konzentrieren die härteste Arbeit an einem Ort: Daten, Prozesse, Integrationen und Menschen. Wenn Ihre Organisation sie vorhersagbar ausführen kann, können Sie bessere Prozesse einführen, Altlastenkosten abbauen und schneller auf regulatorische oder Marktveränderungen reagieren. Diese Fähigkeit akkumuliert sich: Jede Migration lehrt Muster, reduziert Unsicherheit und verkürzt den nächsten Zyklus.
Die besten Teams bauen wiederverwendbare Playbooks:
Das sind keine einmaligen Artefakte. Das ist operative Muskelkraft.
Beginnen Sie damit, Ihre aktuelle Komplexität zu kartieren: Anzahl der Schnittstellen, Hotspots für Custom Code, Stamdatendomänen ohne klare Ownership und Geschäftsprozesse, die regional variieren. Priorisieren Sie dann Migrationen, die den meisten Wert freischalten — alte, risikobehaftete Plattformen, teure Integrationen oder Bereiche, in denen Datenqualität Automatisierung blockiert.
Überlegen Sie außerdem, wo kleine, zweckgebundene interne Tools Reibung reduzieren könnten (z. B. Workflows für Data Stewardship, Interface-Monitoring, UAT-Triage, Cutover-Runbooks oder Hypercare-Ticket-Routing). Diese „Migrationsbeschleuniger" müssen nicht lange auf ihre Umsetzung warten — Teams nutzen zunehmend Plattformen wie Koder.ai, um solche Apps schnell aus einem Chat-Interface zu erstellen und bei Bedarf den Code zu exportieren, wenn tiefere Kontrolle oder unternehmensweite Bereitstellung nötig ist.
Migrationen sind schwierig. Sie erfordern Geduld, Governance und unspektakuläre Detailarbeit. Aber wenn Ihre Organisation sie vorhersehbar ausführen kann, wird diese Kompetenz dauerhaft — und sie zeigt sich in Geschwindigkeit, Resilienz und Selbstvertrauen, wenn die nächste Veränderung kommt.
Ein System of Record ist die autoritäre Quelle für zentrale Geschäftsdetails (Kunden, Produkte, Preise, Bestellungen, Rechnungen, Inventar, Mitarbeiter). Wenn zwei Systeme widersprüchliche Angaben haben, ist das System of Record dasjenige, dem für Betrieb, Prüfungen und Berichte Vertrauen geschenkt wird.
Ein praktischer Test: Wenn ein Streit entsteht, welches System wird korrigiert — und welches System wird aktualisiert, damit es übereinstimmt?
SAP sitzt oft an der Schnittstelle von Finanzen, Supply Chain und Betrieb — Bereichen, in denen Kontrollen, Prüfbarkeit und standardisierte Definitionen besonders wichtig sind.
Im Laufe der Zeit werden Richtlinien (Genehmigungen, Trennung von Zuständigkeiten, Compliance-Routinen) in SAP-Workflows eingebettet, sodass SAP zum Referenzpunkt wird, an den sich andere Systeme anpassen müssen.
Wer eine wiederholbare Migrationsfähigkeit besitzt, kann Prozesse modernisieren, Übernahmen schneller integrieren und auf regulatorische Änderungen reagieren — ohne den Tagesbetrieb zu beeinträchtigen.
Software lässt sich kaufen; das organisatorische Know-how, Daten zu reinigen, Prozesse neu zu gestalten, Integrationen neu aufzubauen und Cutovers sicher auszuführen, ist für Wettbewerber schwer zu kopieren.
Typische Auslöser sind:
Diese Ereignisse erzwingen Änderungen in dem System, das finanzielle und operative Wahrheit abbildet.
Stammdaten sind die gemeinsame Referenz (Kunden, Lieferanten, Materialien, Kontenplan, Kostenstellen, Preisfindungsbedingungen). Transaktionale Daten sind die täglichen Ereignisse (Aufträge, Rechnungen, Wareneingänge, Zahlungen).
Migrationen stocken oft an Stammdaten, weil fehlerhafte Referenzen in das neue System falsche Transaktionen erzeugen. Stammdatenkorrektur erfordert zudem Geschäftsentscheidungen (Definitionen, Ownership), nicht nur technische Aufräumarbeit.
Beginnen Sie mit geschäftsverantwortlichen Regeln und Verbindlichkeiten:
Wenn die Erwartung lautet "IT wird die Daten richten", geraten Zeitpläne meist ins Stocken.
Der Clean-Core-Ansatz hält SAP näher an den Standards und verschiebt differenzierende Logik in kontrollierte Erweiterungen (Konfiguration, Side-by-Side-Apps, stabile Schnittstellen).
Vorteile:
Es bedeutet nicht „keine Anpassungen“ — sondern nur dort anzupassen, wo es Umsatz, Compliance oder echten Wettbewerbsvorteil schützt.
Priorisieren Sie Klarheit und Zuverlässigkeit der Integrationen:
Behandeln Sie jede Integration wie eine finanzielle Kontrolle: nachvollziehbar, testbar und beobachtbar.
Wählen Sie anhand operativer Risikotoleranz und Bereitschaft:
Eine einfache Entscheidungslogik: Bewerten Sie jede große Fläche nach Kritikalität, Bereitschaft (Daten/Prozesse/People) und Abhängigkeiten (Schnittstellen/Regulierung/Kalender).
Mindestzeichen der Readiness:
Für die Stabilisierung: Planen Sie Hypercare mit klarer Triage, täglichen Business-Checkpoints und einem priorisierten Post-Go-Live-Backlog, damit das System verbessert und nicht nur „am Laufen gehalten“ wird.
