Bei Plattformwechseln in SAP, CRM und DWH sehe ich immer wieder dasselbe Muster: Nicht die eigentliche technische Umstellung verursacht die größten Probleme, sondern die falsche Reihenfolge der Schnittstellen. Genau dort entstehen Verzögerungen, doppelte Arbeiten und unnötige Risiken. Wenn ich ein Migrationsvorhaben begleite, beginne ich deshalb nicht mit der Frage, welches System zuerst ersetzt wird, sondern mit der Frage, welche Abhängigkeiten zuerst entkoppelt werden müssen.
In der Praxis reicht es nicht, die Zielarchitektur sauber auf dem Papier zu haben. Entscheidend ist, wie die Daten und Prozesse während der Übergangszeit fließen. Ein Plattformwechsel ist nie nur ein Technologiethema. Er berührt Fachprozesse, Berechtigungen, Stammdaten, Berichtswesen und oft auch Verträge mit externen Partnern. Wenn ich die Schnittstellenreihenfolge falsch plane, wandert das Risiko einfach von einem Team zum nächsten. Wenn ich sie bewusst steuere, gewinne ich Zeit, Stabilität und Akzeptanz.
Warum die Reihenfolge der Schnittstellen so wichtig ist
Jede Schnittstelle hat eine Rolle im Gesamtsystem. Manche liefern Stammdaten, andere Bewegungsdaten, wieder andere dienen nur dem Berichtswesen oder der Protokollierung. Bei einer Migration ist es verführerisch, zuerst die sichtbarsten Verbindungen anzufassen. Das ist jedoch oft falsch. Ich prüfe zuerst, welche Schnittstellen geschäftskritisch sind, welche Datenketten mehrfach verwendet werden und wo sich Abhängigkeiten gegenseitig blockieren.
Ein typisches Beispiel: Das CRM soll ersetzt werden, das SAP bleibt zunächst als führendes System für bestimmte Geschäftsdaten bestehen, und das DWH muss währenddessen weiter Berichte liefern. Wenn ich nun die Berichtsschnittstellen früh umstelle, obwohl die führenden Datenquellen noch nicht stabil sind, produziere ich inkonsistente Auswertungen. Wenn ich dagegen zuerst die Führungslogik kläre und danach die Berichtswege anpasse, bleibt das Fachgebiet handlungsfähig.
Ich denke bei solchen Vorhaben immer in vier Ebenen: Datenherkunft, Verarbeitung, Konsum und Rückmeldung. Erst wenn ich diese Ebenen klar trenne, kann ich die Reihenfolge so festlegen, dass keine Abhängigkeit unbeachtet bleibt.
So ermittle ich die kritischen Abhängigkeiten
Am Anfang erstelle ich eine Schnittstellenlandkarte. Dabei erfasse ich nicht nur technische Verbindungen, sondern auch fachliche Auslöser, Datenbesitzer und zeitliche Anforderungen. Eine saubere Landkarte zeigt mir sofort, wo eine Kette geschlossen sein muss und wo ich Übergangslösungen brauche.
Ich stelle mir dabei unter anderem diese Fragen:
- Welche Systeme liefern führende Stammdaten?
- Welche Schnittstellen erzeugen Folgeprozesse in anderen Systemen?
- Welche Daten müssen in Echtzeit übertragen werden, und welche dürfen zeitversetzt laufen?
- Welche Berichte oder Kontrollmechanismen hängen vom DWH ab?
- Welche Altverbindungen können parallel weiterlaufen, ohne Widersprüche zu erzeugen?
- Welche Fachbereiche reagieren besonders empfindlich auf Lücken oder Verzögerungen?
Aus diesen Antworten entsteht eine Priorisierung. Nicht jede Schnittstelle muss zuerst migriert werden. Manche sollten sogar bewusst zuletzt umgestellt werden, weil sie auf bereits stabilisierten Daten aufbauen. Das klingt simpel, ist aber in Projekten oft der Unterschied zwischen geordnetem Übergang und chaotischem Schnitt.
Welche Schnittstellen ich meist zuerst plane
Wenn SAP, CRM und DWH parallel betroffen sind, ordne ich die Migration meist nach dem Nutzen für die Stabilität des Gesamtsystems. In vielen Fällen beginne ich mit den Schnittstellen, die die führenden Stammdaten absichern. Dazu gehören zum Beispiel Kunden-, Material-, Lieferanten- oder Organisationsdaten. Solange diese Datenströme nicht sauber laufen, lohnt es sich selten, weiter oben im Prozess zu optimieren.
Danach betrachte ich die Schnittstellen, die operative Prozesse unmittelbar auslösen. Das können Auftragsübermittlungen, Statusmeldungen, Preisrückgaben oder Zahlungsinformationen sein. Ich achte darauf, dass ein Prozess erst dann auf das neue Zielsystem umgestellt wird, wenn die vorgelagerten Daten sauber und nachvollziehbar bereitstehen.
Erst im dritten Schritt ziehe ich Auswertungs- und Berichtsschnittstellen nach. Das DWH ist oft kein Auslöser, sondern ein Verstärker. Wenn die Quellsysteme noch wechseln, kann ich im DWH leicht falsche Eindrücke erzeugen. Deshalb stelle ich Berichte häufig erst dann vollständig um, wenn die fachlichen Datenwege im Zielbild bereits mehrfach getestet sind.
Die Reihenfolge hängt natürlich vom Einzelfall ab. Aber mein Grundsatz bleibt gleich: erst die Quelle der Wahrheit stabilisieren, dann die operativen Ketten absichern, danach das Berichtswesen umstellen.
Wie ich Übergangsarchitekturen nutze
Bei großen Plattformwechseln versuche ich selten, alles auf einmal zu drehen. Stattdessen plane ich Übergangsarchitekturen. Das bedeutet: Ein Teil der alten Welt bleibt vorübergehend aktiv, während das neue System bereits einzelne Aufgaben übernimmt. Diese Zwischenphase braucht Disziplin, sonst entsteht ein unübersichtlicher Mischbetrieb. Richtig eingesetzt, ist sie jedoch ein wirksames Mittel gegen Verzögerungen.
Ich achte dabei besonders auf drei Punkte:
- Eindeutige Datenführerschaft: Für jedes Objekt muss klar sein, welches System führend ist.
- Saubere Protokollierung: Änderungen müssen nachvollziehbar bleiben, damit Fehler schnell gefunden werden.
- Begrenzte Doppelpflege: Doppelte Eingaben sind nur dann akzeptabel, wenn sie zeitlich strikt begrenzt und fachlich kontrolliert sind.
Ein häufiger Fehler ist, dass Teams eine Übergangslösung einführen, aber keinen klaren Endpunkt definieren. Dann bleibt eine Notlösung zu lange bestehen und wird plötzlich zum Dauerzustand. Ich plane deshalb immer schon zu Beginn, wann eine Zwischenlösung wieder abgeschaltet wird und welche Bedingung dafür erfüllt sein muss.
Woran ich die richtige Reihenfolge prüfe
Ich verlasse mich nie nur auf technische Diagramme. Ich prüfe jede geplante Reihenfolge gegen konkrete Projektsituationen. Hat ein Fachbereich einen Stichtag, an dem bestimmte Daten verfügbar sein müssen? Gibt es gesetzliche Meldefristen? Muss das DWH zu einem bestimmten Zeitpunkt verlässliche Zahlen liefern? Solche Fragen beeinflussen die Reihenfolge oft stärker als die technische Komplexität.
In Workshops arbeite ich gern mit einem einfachen Vergleich der möglichen Pfade. Ich bewerte dabei nicht nur den Aufwand, sondern auch die Abhängigkeitstiefe, die Rückfalloption und die Auswirkungen auf den Betrieb. Diese Betrachtung hilft mir, Diskussionen aus dem Bauchgefühl herauszulösen und in eine belastbare Entscheidung zu überführen.
| Schnittstellenart | Typische Abhängigkeit | Empfohlene Reihenfolge | Hauptrisiko bei falscher Reihenfolge |
|---|---|---|---|
| Stammdaten | Hohe fachliche Verflechtung | Früh | Inkonsistente Folgeprozesse |
| Operative Transaktionen | Abhängig von stabilen Stammdaten | Nach der Stammdatenumstellung | Abgebrochene Abläufe im Tagesgeschäft |
| Berichtswesen im DWH | Abhängig von verlässlichen Quellsystemen | Später | Falsche Kennzahlen und Vertrauensverlust |
| Rückmeldungen an Drittsysteme | Oft zeitkritisch, aber nicht immer führend | Nach Stabilisierung des Kernflusses | Blockierte Partnerprozesse |
Wie ich Teams auf die Umstellung vorbereite
Die beste Reihenfolge nützt wenig, wenn die beteiligten Teams sie nicht verstehen. Deshalb bereite ich die Umstellung nicht nur technisch, sondern auch organisatorisch vor. Ich erkläre den Fachbereichen, warum eine bestimmte Schnittstelle bewusst später kommt und was das für ihre Arbeit bedeutet. Transparenz nimmt Druck aus dem Projekt und verhindert unrealistische Erwartungen.
Besonders wichtig ist mir, dass Fachbereiche nicht erst kurz vor dem Umschalten eingebunden werden. Wenn Mitarbeitende früh sehen, wie ihre Prozesse in die Migrationsreihenfolge passen, liefern sie oft wertvolle Hinweise. Häufig kennen sie Ausnahmen, Sonderfälle oder Monatsendprozesse, die in der Architektur zunächst unsichtbar bleiben. Genau diese Hinweise retten später Termine.
Ich nutze außerdem klare Testfenster. Für jede Schnittstelle definiere ich, wann sie mit welchen Daten getestet wird, wer die Freigabe erteilt und wie ein Rückfall organisiert ist. Dadurch wird aus einer abstrakten Migrationslogik ein beherrschbarer Ablauf. Das ist besonders wichtig, wenn mehrere Plattformen gleichzeitig betroffen sind.
Welche Fehler ich am häufigsten sehe
Der erste Fehler ist, dass Teams die Reihenfolge nach technischer Bequemlichkeit statt nach fachlicher Wirkung festlegen. Der zweite Fehler ist, dass Abhängigkeiten nur auf Systemebene betrachtet werden, nicht aber auf Prozessebene. Der dritte Fehler ist die Annahme, dass ein erfolgreich getesteter Einzelpfad automatisch das Gesamtbild absichert. In Wirklichkeit scheitern viele Vorhaben genau an den Übergängen zwischen den Pfaden.
Ein weiterer häufiger Stolperstein ist der Umgang mit Datenqualität. Wenn ein Quellsystem historisch gewachsene Datenprobleme enthält, darf die Schnittstellenreihenfolge diese Probleme nicht einfach verdecken. Ich plane dann zusätzliche Prüfungen ein, bevor die nächste Stufe freigegeben wird. Sonst wandern Fehler unbemerkt vom alten in das neue System.
Auch die Reihenfolge von Alt- und Neusystem wird oft unterschätzt. Manchmal muss das alte System länger als erwartet aktiv bleiben, weil ein nachgelagerter Prozess noch nicht vollständig migriert werden kann. Dann braucht es eine klare Entscheidungslogik: Welche Altverbindung bleibt vorübergehend bestehen, und ab wann wird sie konsequent abgeschaltet?
Wie ich den Erfolg einer Schnittstellenreihenfolge beurteile
Für mich ist eine gute Reihenfolge nicht daran zu erkennen, dass sie elegant wirkt, sondern daran, dass sie im Betrieb ruhig bleibt. Wenn Fachbereiche ihre Aufgaben weiter erledigen können, wenn Berichte plausibel bleiben und wenn Störungen schnell lokalisierbar sind, dann war die Reihenfolge richtig. Ich messe Erfolg deshalb nicht nur an der Einhaltung eines Terminplans, sondern auch an der Stabilität nach dem Umschalten.
Ich achte auf folgende Anzeichen:
- Die Zahl ungeplanter Rückfälle bleibt niedrig.
- Fehler lassen sich schnell einer konkreten Stufe zuordnen.
- Fachbereiche melden keine widersprüchlichen Datenstände.
- Das DWH liefert nach der Umstellung belastbare Werte.
- Die Betriebsverantwortlichen behalten die Übersicht über die aktiven Verbindungen.
Wenn diese Punkte erfüllt sind, weiß ich, dass die Schnittstellenreihenfolge nicht nur technisch, sondern auch organisatorisch getragen wird. Genau das ist für mich der eigentliche Maßstab bei Plattformwechseln rund um SAP, CRM und DWH: nicht möglichst schnell alles umstellen, sondern so planen, dass die Abhängigkeiten das Projekt nicht ausbremsen.