Es ist der Klassiker in fast jedem SAP-Projekt: Der Lagerleiter ruft an und meldet, dass der LKW steht, weil die Papiere fehlen. Die IT prüft und sagt: „Bei uns ist alles grün.“ Das angebundene WMS-Team sagt: „Wir haben die Daten gesendet.“
Willkommen beim „Schnittstellen-Pingpong“.
In meiner über 14-jährigen Beratungspraxis, insbesondere in der hochgradig vernetzten Automobilindustrie, habe ich gelernt: Schnittstellen sind mehr als nur technische Verbindungen. Sie sind die sensibelsten Nervenstränge der Supply Chain. Wenn hier ein Fehler passiert, steht im schlimmsten Fall die Produktion.
In diesem Artikel zeige ich auf, warum reactive Fehlersuche Geld verbrennt und wie Sie mit Operational Excellence im Monitoring Ruhe in Ihre Systemlandschaft bringen.
Warum „Status 51“ nicht gleich „Status 51“ ist
Das häufigste Problem im Monitoring ist die fehlende Unterscheidung zwischen technischen und fachlichen Fehlern.
Ein technischer Fehler (Verbindungsabbruch, Port nicht erreichbar) ist ein Fall für die Basis-IT. Doch 90 % der „Schnittstellen-Fehler“ in der täglichen Praxis sind eigentlich Datenfehler.
- Das Material ist im Zielsystem nicht angelegt.
- Die Mengeneinheit fehlt im Mapping.
- Der Debitor ist für den Buchungskreis gesperrt.
Wenn diese Fehler in einem allgemeinen IT-Sammelpostfach landen, passiert oft stundenlang nichts. Die IT versteht den fachlichen Inhalt nicht, und der Fachbereich weiß gar nicht, dass ein IDoc auf Fehler gelaufen ist.
Vom „Black Box“ Denken zur Transparenz
Viele Unternehmen betrachten Schnittstellen als „Black Box“. Man wirft vorne etwas rein und hofft, dass es hinten ankommt. Das ist im Zeitalter von S/4HANA und Just-in-Sequence-Logistik fahrlässig.
Operational Excellence bedeutet hier: Proaktivität.
Ein exzellenter Support wartet nicht auf das Ticket des Anwenders. Er sieht den Fehler im Monitoring-Cockpit, noch bevor der LKW an die Rampe fährt.
Die 3 Säulen eines stabilen Monitorings
Um vom Reagieren ins Agieren zu kommen, müssen drei Voraussetzungen geschaffen werden:
1. Intelligente Filterung und Alerting
Niemand kann täglich 10.000 erfolgreiche IDocs (Status 53) kontrollieren. Das Monitoring muss sich auf die Ausnahmen konzentrieren. Tools wie der SAP Solution Manager oder auch gut eingestellte Varianten in der Transaktion BD87 / WLF_IDOC sind hier Pflicht. Wichtig: Ein Alert (E-Mail) darf nur versendet werden, wenn Handlungsbedarf besteht. Wenn das Postfach überflutet wird, liest niemand mehr die Warnungen.
2. Business-Kontext statt technischer Kryptik
Eine Fehlermeldung wie „Eintrag in Tabelle T001L fehlt“ hilft einem Key-User wenig. Ein gutes Monitoring-Konzept übersetzt dies: „Lagerort fehlt in der Bestellung“. Wenn wir Schnittstellen designen, müssen wir sicherstellen, dass das Fehler-Handling so gebaut ist, dass die Meldung sprechend ist. Das spart im Support wertvolle Analysezeit.
3. Klare Verantwortlichkeiten (Governance)
Wer ist „Besitzer“ der Schnittstelle?
- Ist es ein Stammdaten-Problem? -> Verantwortlich: Master Data Team.
- Ist es ein Logik-Problem? -> Verantwortlich: SAP Application Management.
- Ist es ein Netzwerk-Problem? -> Verantwortlich: Infrastruktur.
Solange diese Zuständigkeiten nicht geklärt sind, wird jedes Ticket erst dreimal weitergeleitet (Pingpong), bevor es gelöst wird.
Best Practice: Monitoring als Routine
In meinen Projekten bei großen OEMs oder im Mittelstand empfehle ich immer die Einführung einer „Morning Routine“ für Key-User oder den 1st-Level-Support:
- 07:30 Uhr: Blick in das IDoc-Monitor (z.B. WE02/BD87).
- Filterung auf Fehler der letzten Nacht (Status 51, 63, etc.).
- Sofortige Analyse: Welche Lieferungen sind blockiert?
- Korrektur der Stammdaten oder Nachverbuchung bevor der operative Betrieb hochfährt.
Dieser Invest von 15 Minuten am Morgen spart tagsüber Stunden an Eskalationsmanagement und Telefonkonferenzen.
Fazit: Technik dient dem Prozess
Eine Schnittstelle ist nur so gut wie das Monitoring, das sie überwacht. Wer Schnittstellen-Projekte nur technisch betrachtet („Die Leitung steht“), hat nur die halbe Arbeit gemacht.
Erst durch sauberes Error-Handling, klare Verantwortlichkeiten und proaktives Monitoring wird aus einer technischen Verbindung ein stabiler Geschäftsprozess. Das Ziel muss sein: Eine Integration, die so geräuschlos läuft, dass man vergisst, dass sie existiert.