S/4HANA Integrationsfehler im Mittelstand

Ein Auftrag wird in S/4HANA korrekt angelegt, erreicht das Lager aber nicht. Eine Rechnung wird erzeugt, scheitert jedoch beim Versand an das Kundenportal. Oder Stammdaten sind im führenden System richtig, in einer angebundenen Anwendung aber veraltet. S/4HANA Integrationsfehler im Mittelstand zeigen sich selten zuerst als Architekturproblem. Sie erscheinen als operative Störung, manueller Klärungsaufwand und steigendes Risiko im Tagesgeschäft.

Gerade mittelständische Unternehmen betreiben häufig über Jahre gewachsene Landschaften: S/4HANA ist mit E-Commerce, Lagerverwaltung, CRM, Manufacturing Execution, Business Intelligence, Banken, Behördenportalen oder branchenspezifischen Anwendungen verbunden. Einzelne Schnittstellen funktionieren dabei lange ausreichend. Kritisch wird es, wenn sich Datenmodelle, Prozesse, Verantwortlichkeiten oder technische Plattformen im Zuge einer Migration verändern.

Der Fehler liegt dann nicht zwingend in einer einzelnen Schnittstelle. Häufig fehlt die durchgängige Steuerung des Datenflusses. Wer Integrationen ausschließlich als technische Aufgabe behandelt, erkennt Abhängigkeiten zu Fachprozess, Berechtigungen, Stammdatenqualität, Monitoring und Cutover zu spät.

Warum Integrationsfehler in S/4HANA-Projekten spät sichtbar werden

Eine S/4HANA-Transformation verändert mehr als die ERP-Oberfläche. Geschäftspartner ersetzen oder konsolidieren frühere Stammdatenobjekte, Belegstrukturen ändern sich, Custom Code muss geprüft werden und APIs oder IDocs erhalten eine neue fachliche Bedeutung. Selbst wenn eine Schnittstelle technisch Nachrichten überträgt, kann sie fachlich falsche Ergebnisse liefern.

Das ist besonders relevant, wenn Altsysteme weiterlaufen. Ein Vertriebssystem erwartet etwa bestimmte Kundennummern, während S/4HANA Geschäftspartnerrollen und Dublettenbereinigung anders verarbeitet. Die Übertragung kann erfolgreich quittiert werden, obwohl das Empfängersystem den Datensatz nicht korrekt zuordnet. Aus technischer Sicht liegt kein Kommunikationsfehler vor. Aus betrieblicher Sicht fehlt jedoch eine entscheidende Information.

Hinzu kommt die übliche Projektlogik: Teams testen häufig Funktionen innerhalb ihrer eigenen Zuständigkeit. Der Einkauf prüft Bestellungen, die Finanzbuchhaltung Buchungen, das Integrationsteam Nachrichtenformate. Der kritische End-to-End-Prozess - vom Auftrag über Lieferung und Faktura bis zur Übergabe an ein Drittsystem - wird oft erst kurz vor dem Go-Live vollständig ausgeführt. Dann treffen offene Defekte, fehlende Testdaten und knappe Entscheidungswege zusammen.

Fünf typische S/4HANA Integrationsfehler im Mittelstand

Die Ursachen unterscheiden sich je nach Branche und Systemlandschaft. In Projekten mit komplexen Lieferketten, regulatorischen Nachweisen oder hohem Transaktionsvolumen treten jedoch wiederkehrende Muster auf.

• Unklare Datenführerschaft: Mehrere Systeme pflegen denselben Kunden, Materialstamm oder Preis. Ohne verbindliche Regel, welches System für welches Attribut führend ist, entstehen Konflikte und manuelle Korrekturen.

• Falsche fachliche Zuordnung: Felder werden zwar übertragen, aber anders interpretiert. Das betrifft etwa Mengeneinheiten, Steuerkennzeichen, Zahlungsbedingungen, Statuswerte oder Werke.

• Unvollständige Fehlerbehandlung: Fehlgeschlagene Nachrichten landen in technischen Queues oder Monitoring-Ansichten, ohne dass ein Fachbereich die Auswirkungen bewertet und fristgerecht entscheidet.

• Nicht realistische Testdaten: Tests nutzen vereinfachte Stammdaten und Standardfälle. Ausnahmen wie Teillieferungen, Retouren, Sperrgründe, Chargen oder abweichende Debitoren bleiben ungetestet.

• Ungeplante Berechtigungs- und Rollenwirkungen: Eine Integration kann technisch korrekt aufgebaut sein, scheitert aber im Betrieb an fehlenden Berechtigungen, abweichenden Service-Usern oder nicht abgestimmten Rollenmodellen.

Nicht jedes dieser Muster verlangt eine grundlegende Neuentwicklung. Manchmal genügt eine klare Mapping-Regel oder ein fachlicher Klärungsprozess. In anderen Fällen muss die Architektur angepasst werden, etwa wenn synchrone Aufrufe bei Lastspitzen nicht ausreichend stabil betrieben werden können. Entscheidend ist, Ursache und Wirkung sauber zu trennen, bevor Maßnahmen beschlossen werden.

Datenfluss statt Schnittstellenliste betrachten

Eine Schnittstellenliste ist notwendig, reicht aber nicht aus. Sie zeigt Systeme, Technologien und Verantwortliche. Was sie meist nicht zeigt: Welche Geschäftsentscheidung ein Datenelement auslöst, welche Abhängigkeiten bestehen und welche Folgen eine verzögerte oder falsche Übertragung hat.

Belastbarer ist eine Datenflussanalyse entlang konkreter Prozesse. Für einen Vertriebsauftrag sollte nachvollziehbar sein, wo der Auftrag entsteht, welche Prüfungen stattfinden, welche Stammdaten verwendet werden, welche Systeme Statusinformationen zurückmelden und wo eine Fachentscheidung erforderlich wird. Gleiches gilt für Beschaffung, Produktion, Instandhaltung, Finanzprozesse und regulatorisches Reporting.

Dabei helfen Fragen, die über die technische Verbindung hinausgehen: Wer erkennt den Fehler zuerst? Wer darf Daten korrigieren? Bis wann muss eine fehlerhafte Nachricht wiederholt oder fachlich entschieden sein? Welche Daten werden rückwirkend verändert, und wie lässt sich das revisionssicher dokumentieren? Diese Fragen schaffen die Grundlage für einen stabilen Betrieb, nicht erst für einen erfolgreichen Test.

Testmanagement muss Prozessrisiken priorisieren

Vollständige Testabdeckung ist in komplexen S/4HANA-Projekten selten realistisch. Die sinnvolle Alternative ist keine beliebige Reduktion, sondern eine risikobasierte Priorisierung. Prozesse mit hoher wirtschaftlicher Auswirkung, enger Taktung oder regulatorischer Relevanz benötigen nachvollziehbare End-to-End-Tests.

Ein Energieversorger wird beispielsweise Marktkommunikation, Abrechnung und Fristen anders gewichten als ein Großhändler, der Auftragsdurchlauf, Lagerbestand und Lieferfähigkeit absichern muss. In der Chemie können Chargenbezug und Gefahrstoffinformationen kritisch sein. In Life-Sciences-Umgebungen kommen Anforderungen an Nachvollziehbarkeit und dokumentierte Freigaben hinzu. Das Testkonzept muss diese Unterschiede abbilden, statt nur technische Standardfälle zu wiederholen.

Gute Testfälle enthalten daher nicht nur Eingabe und Soll-Ergebnis. Sie benennen Ausgangsdaten, beteiligte Systeme, fachliche Prüfpunkte, erwartete Fehlermeldungen und den Verantwortlichen für die Abnahme. Ebenso wichtig ist ein geregelter Umgang mit Defekten: Schweregrad, Auswirkung, Workaround, Entscheidung und Retest müssen für Projektleitung und Fachbereich transparent sein.

Cutover: Der kritische Übergang wird oft unterschätzt

Viele Integrationsprobleme entstehen nicht im Normalbetrieb, sondern beim Wechsel in die produktive Landschaft. Während des Cutovers werden Daten migriert, Schnittstellen umgestellt, Benutzer aktiviert und Altprozesse beendet oder parallel betrieben. Wenn Reihenfolge, Zeitfenster und Rückfalloptionen nicht präzise geplant sind, kann eine fachlich funktionierende Schnittstelle mit unvollständigen Daten starten.

Ein belastbarer Cutover-Plan beschreibt deshalb nicht nur technische Aktivitäten. Er legt fest, welche Daten zu welchem Zeitpunkt eingefroren werden, wann Replikationen enden, welche Kontrollsummen oder fachlichen Abstimmungen erfolgen und wer die Freigabe für den nächsten Schritt erteilt. Für kritische Schnittstellen gehört ein produktionsnaher Smoke Test dazu: wenige, gezielt ausgewählte Geschäftsvorfälle, mit denen Übertragung, Verarbeitung und Rückmeldung geprüft werden.

Besondere Aufmerksamkeit verdienen offene Belege und Statuswechsel. Ein Auftrag, der zum Umschaltzeitpunkt zwischen zwei Systemen hängt, kann doppelt verarbeitet werden oder ganz verloren gehen. Solche Fälle lassen sich nicht allein durch technische Tests beherrschen. Sie benötigen fachliche Regeln für Übergangsbestände, Verantwortliche und dokumentierte Entscheidungen.

So entsteht eine steuerbare Integrationslandschaft

Nach dem Go-Live beginnt die eigentliche Betriebsverantwortung. Monitoring sollte nicht nur technische Fehler anzeigen, sondern fachlich priorisieren. Eine fehlende Statusmeldung kann je nach Prozess harmlos sein oder Lieferungen, Rechnungen und Monatsabschlüsse beeinflussen. Ohne definierte Service Levels und Eskalationswege bleibt die Bewertung beim Zufall oder bei einzelnen erfahrenen Mitarbeitenden.

Sinnvoll ist ein kompaktes Betriebsmodell mit eindeutigen Zuständigkeiten zwischen IT, Fachbereich und externen Partnern. Dazu gehören Eigentümer für Schnittstellen und Datenobjekte, feste Regeln für Fehlerklassifizierung sowie Kennzahlen wie Fehlerquote, Wiederanlaufzeit, manuelle Nachbearbeitung und wiederkehrende Fehlerursachen. Diese Kennzahlen machen sichtbar, ob ein Problem nur behoben oder tatsächlich dauerhaft beseitigt wurde.

Auch Änderungen verdienen eine feste Kontrolle. Neue Felder, geänderte Partneranforderungen oder Releases können bestehende Abläufe beeinträchtigen. Ein schlanker Change-Prozess mit Auswirkungsanalyse, Testnachweis und dokumentierter Freigabe reduziert das Risiko, dass kleine Anpassungen unbemerkt in kritische Datenflüsse eingreifen.

Integrationen vor dem Go-Live belastbar prüfen

Quteco unterstützt S/4HANA-Projekte mit Datenflussanalysen, risikobasiertem Testmanagement und operativer Cutover-Steuerung. In einem Quick Check oder Workshop lassen sich kritische Schnittstellen, offene Verantwortlichkeiten und prüfbare Maßnahmen für den produktiven Übergang strukturiert erfassen. Das schafft eine belastbare Grundlage, bevor Fehler im Betrieb zu manuellen Dauerprozessen werden.

Die entscheidende Frage lautet nicht, ob jede Schnittstelle technisch verbunden ist. Entscheidend ist, ob Geschäftsvorfälle mit ihren Daten, Entscheidungen und Verantwortlichkeiten auch unter realen Betriebsbedingungen nachvollziehbar durchlaufen.