Leitfaden zur Datenflussanalyse im SAP-Umfeld

Wenn Datenflüsse im Projekt erst sichtbar werden, wenn sie stören

Eine fehlende Lieferung im Lager, ein fehlerhafter Rechnungsstatus oder eine nicht übertragene Stammdatenänderung wirken zunächst wie einzelne operative Störungen. In SAP-Landschaften liegen die Ursachen jedoch häufig im Zusammenspiel mehrerer Systeme, Schnittstellen und Verantwortungsbereiche. Ein Leitfaden zur Datenflussanalyse im SAP-Umfeld schafft die Grundlage, um diese Abhängigkeiten nachvollziehbar zu erfassen und gezielt zu steuern.

Besonders kritisch wird dies in S/4HANA-Transformationen, bei Carve-outs, der Integration neuer Fachanwendungen oder vor einem produktiven Go-Live. Wer Datenflüsse nur aus technischen Schnittstellenbeschreibungen ableitet, übersieht oft fachliche Regeln, manuelle Übergaben, zeitliche Abhängigkeiten und Kontrolllücken. Die Folge sind hohe Aufwände im Test, Unsicherheit im Cutover und ein Betrieb, der auf Einzelfallwissen angewiesen bleibt.

Was eine Datenflussanalyse im SAP-Umfeld leisten muss

Eine Datenflussanalyse beschreibt nicht nur, welche Anwendung Daten an eine andere Anwendung übergibt. Sie dokumentiert den Weg einer fachlich relevanten Information vom auslösenden Ereignis bis zur Nutzung, Speicherung, Weitergabe oder Löschung. Im SAP-Umfeld betrifft das beispielsweise Kundenstammdaten, Materialstämme, Bestellungen, Chargeninformationen, Buchungsbelege oder Berechtigungsdaten.

Eine belastbare Analyse beantwortet vier Fragen: Wo entstehen Daten, wie werden sie verarbeitet, wer trägt die fachliche und technische Verantwortung, und welche Kontrollen sichern Qualität, Vollständigkeit und Nachvollziehbarkeit? Erst die Verbindung dieser Perspektiven macht aus einer Schnittstellenliste ein steuerbares Arbeitsmittel.

Der erforderliche Detailgrad hängt vom Ziel ab. Für eine erste Standortbestimmung genügt häufig die Sicht auf geschäftskritische Prozesse und zentrale Systemgrenzen. Für Migration, Auditvorbereitung oder die Absicherung eines Go-Lives müssen dagegen auch Transformationsregeln, Fehlerwege, Batch-Zeitpläne, Berechtigungen und Abstimmverfahren dokumentiert werden.

Den Untersuchungsrahmen vor der Detailarbeit festlegen

Viele Analysen verlieren Zeit, weil das Team alle vorhandenen Systeme und Tabellen gleichzeitig erfassen will. Sinnvoller ist es, den Rahmen über Risiko und Geschäftswirkung zu definieren. Welche Prozesse dürfen nicht ausfallen? Bei welchen Daten führen Fehler zu falschen Buchungen, Lieferverzögerungen, Compliance-Risiken oder fehlerhaftem Reporting?

In einem Großhandelsunternehmen kann dies etwa der Order-to-Cash-Prozess sein: Auftragsdaten entstehen im Vertriebskanal, werden in SAP verarbeitet, an Lager- und Transportlösungen übergeben und später für Faktura sowie Finanzbuchhaltung genutzt. In der Energieversorgung stehen häufig Marktkommunikation, Messdaten und Abrechnung im Mittelpunkt. Chemie und Life Sciences benötigen zusätzlich eine genaue Sicht auf Chargen, Spezifikationen und Freigabestatus.

Für jeden priorisierten Prozess sollten fachliche Eigentümer, technische Ansprechpartner und Entscheidungswege benannt werden. Die IT kann Schnittstellen technisch erläutern, aber sie kann nicht allein entscheiden, ob ein Feld geschäftskritisch ist oder welche fachliche Ausnahme zulässig bleibt. Diese Verantwortlichkeit gehört in die Fachbereiche und muss dokumentiert sein.

Datenflüsse in nachvollziehbaren Schritten erfassen

Der praktikabelste Einstieg ist ein gemeinsamer Workshop mit Fachbereich, SAP-Verantwortlichen, Integrationsverantwortlichen, Datenmanagement und gegebenenfalls Informationssicherheit. Ausgangspunkt ist ein konkretes Geschäftsszenario, nicht ein abstraktes Systembild. Das Team verfolgt beispielsweise eine Kundenanlage, eine Bestellung oder eine Produktionscharge entlang des realen Ablaufs.

Für jeden Übergabepunkt werden Quelle, Ziel, Übertragungsart und Frequenz festgehalten. Relevant sind etwa IDocs, APIs, Middleware, Dateien, Replikationen, manuelle Exporte oder direkte Datenbankzugriffe. Ebenso wichtig ist die Frage, ob Daten synchron verarbeitet werden oder zeitversetzt in Batches. Ein nächtlicher Lauf kann fachlich unkritisch sein, bei Bestandsdaten kurz vor Versand aber zu erheblichen Problemen führen.

Danach folgt die Datensicht. Nicht jedes Feld muss von Beginn an analysiert werden. Im Vordergrund stehen Schlüssel, Statuswerte, Beträge, Mengen, Organisationseinheiten, Zeitstempel und Attribute mit regulatorischer oder steuernder Wirkung. Gerade bei Stammdaten sollten Teams klären, welches System führend ist. Mehrere Systeme dürfen dieselben Daten verwenden, aber die Pflegehoheit sollte eindeutig sein.

Die Dokumentation wird belastbar, wenn sie auch Fehlerfälle abbildet. Was passiert bei einem fehlerhaften Mapping, einer abgelehnten Nachricht oder einem nicht erreichbaren Zielsystem? Wer erkennt die Störung, wer korrigiert sie, und wie wird die erfolgreiche Nachverarbeitung nachgewiesen? Ohne diese Angaben beschreibt ein Datenfluss nur den Idealfall.

Schnittstellen, Verarbeitung und Kontrolle getrennt bewerten

Eine häufige Schwachstelle ist die Gleichsetzung von technischer Übertragung und korrekter Verarbeitung. Eine Schnittstelle kann technisch erfolgreich laufen, obwohl ein Pflichtfeld leer bleibt, ein Status falsch interpretiert wird oder ein Beleg im Zielsystem fachlich nicht weiterverarbeitet werden kann.

Deshalb sollten Teams drei Ebenen separat bewerten. Die Transportebene prüft, ob eine Nachricht vollständig und fristgerecht übertragen wurde. Die Verarbeitungsebene betrachtet Validierungen, Mapping-Regeln, Dublettenlogik und Fehlerbehandlung. Die Kontrollebene stellt fest, ob Fachbereich und Betrieb Abweichungen erkennen, bewerten und revisionssicher nachvollziehen können.

Ein Beispiel aus der S/4HANA-Integration: Eine Bestellnummer wird an ein Vorsystem übermittelt und dort technisch bestätigt. Für die Fachseite reicht das nicht aus. Sie benötigt den Nachweis, dass Positionen, Mengen, Liefertermine und Änderungsstände korrekt übernommen wurden. Hier helfen abgestimmte Kontrollberichte, Soll-Ist-Abgleiche und klar definierte Klärungsfristen mehr als zusätzliche Protokolldaten ohne Verantwortlichen.

Risiken priorisieren statt Dokumentation verwalten

Die Datenflussanalyse soll Entscheidungen ermöglichen. Deshalb ist eine Risikobewertung erforderlich, die Eintrittswahrscheinlichkeit, Auswirkung und Erkennbarkeit kombiniert. Ein selten auftretender Fehler mit Auswirkungen auf Monatsabschluss oder Patientenversorgung verdient eine andere Behandlung als ein sichtbarer Formatfehler in einer unkritischen Auswertung.

Typische Risikomuster sind unklare Datenführerschaft, nicht dokumentierte manuelle Übergaben, fehlende Abstimmungen zwischen Quell- und Zielsystem, zu weitreichende Zugriffsrechte sowie unzureichend getestete Fehlerwege. Auch Schattenprozesse gehören dazu: Excel-Dateien oder lokale Korrekturen können operativ hilfreich sein, unterbrechen aber oft die Nachvollziehbarkeit und erschweren eine konsistente Datenbasis.

Nicht jedes Risiko muss sofort durch eine technische Änderung gelöst werden. Je nach Sachlage kann eine verbindliche Arbeitsanweisung, ein zusätzlicher Abgleich oder eine klarere Betriebsverantwortung angemessen sein. Bei kritischen Massendaten, automatisierten Buchungen oder personenbezogenen Daten reichen organisatorische Kontrollen allein jedoch meist nicht aus. Dann müssen Architektur, Berechtigungskonzept und Monitoring einbezogen werden.

Ergebnisse für Test, Cutover und Betrieb nutzbar machen

Der eigentliche Nutzen entsteht, wenn die Analyse in Projekt- und Betriebsartefakte überführt wird. Kritische Datenflüsse liefern die Grundlage für End-to-End-Testfälle. Dabei werden nicht nur einzelne Schnittstellen getestet, sondern fachliche Abläufe über alle beteiligten Systeme hinweg - einschließlich Wiederanlauf und Fehlerkorrektur.

Für den Cutover zeigt die Analyse, welche Daten zu welchem Zeitpunkt eingefroren, migriert, abgeglichen oder erneut übertragen werden müssen. Sie macht sichtbar, wo Reihenfolgen gelten und welche Teams in Bereitschaft sein müssen. So lassen sich Cutover-Pläne an tatsächlichen Abhängigkeiten ausrichten, statt Aktivitäten ausschließlich nach Systemen zu strukturieren.

Im stabilen Betrieb unterstützt die Dokumentation Incident-Management, Change-Bewertungen und revisionssicheres Reporting. Sie sollte daher nicht als einmalige Projektunterlage abgelegt werden. Sinnvoll ist ein schlankes Pflegeverfahren: Bei neuen Schnittstellen, relevanten Feldänderungen, Prozessänderungen oder neuen Empfängersystemen wird geprüft, welche Datenflüsse und Kontrollen anzupassen sind.

Typische Fehlansätze vermeiden

Reine Toolauswertungen liefern wertvolle technische Hinweise, ersetzen aber keine fachliche Klärung. Ebenso wenig genügt ein Organigramm mit Systemnamen. Datenflüsse müssen an konkreten Geschäftsobjekten und Verantwortlichkeiten festgemacht werden.

Problematisch ist auch eine Dokumentation, die ausschließlich von externen Spezialisten erstellt wird. Externe Expertise kann Struktur, Methodik und technische Tiefe einbringen. Die fachliche Akzeptanz und dauerhafte Pflege entstehen jedoch nur, wenn die verantwortlichen Bereiche die Ergebnisse prüfen, entscheiden und im Alltag verwenden.

Datenflüsse gezielt absichern

Quteco unterstützt SAP- und Transformationsprojekte mit Quick Checks, Workshops und operativer Projektbegleitung bei der strukturierten Datenflussanalyse. Im Fokus stehen priorisierte End-to-End-Prozesse, dokumentierte Verantwortlichkeiten sowie verwertbare Ergebnisse für Testmanagement, Cutover und stabilen Betrieb. Der entscheidende Schritt ist nicht maximale Dokumentation, sondern eine Datenflusssicht, die im nächsten Projekttermin und im nächsten Störfall belastbare Entscheidungen ermöglicht.