Prozessmonitoring und Klärfälle

Kurzantwort

Prozessmonitoring in der Marktkommunikation beobachtet nicht nur Nachrichten, sondern Vorgänge. Es zeigt, welche Marktprozesse offen sind, welche Fristen laufen und welche Schritte fehlen. Ein Klärfall entsteht, wenn ein Vorgang nicht automatisch verarbeitet werden kann, etwa weil Stammdaten fehlen, Zuordnungen widersprüchlich sind oder eine Rückmeldung ausbleibt.

Für SAP-IS-U-Berater heißt das: Monitoring braucht ein Statusmodell, das die Ebenen der Marktkommunikation abbildet. Transport, Syntax, fachliche Verarbeitung und Geschäftsergebnis sind getrennt zu führen. Wer nur die Übertragung überwacht, sieht die eigentlichen Prozessstörungen nicht.

Der Artikel beschreibt, wie ein solches Statusmodell aufgebaut ist, wann Klärfälle entstehen und wie die Bearbeitung organisiert wird. Er richtet sich an Fachliche, die Marktprozesse betreiben, und an Berater, die Monitoring-Konzepte für SAP-IS-U-Landschaften entwerfen.

Was Monitoring leisten muss

Ein Nachrichtenmonitor zeigt, welche Dateien empfangen und versendet wurden. Er beantwortet die Frage: Ist die Übertragung gelaufen? Diese Sicht reicht für den Betrieb der Marktkommunikation nicht aus. Entscheidend ist die Frage, ob der dahinterliegende Prozess vorankommt.

Ein Lieferbeginn durchläuft mehrere Schritte: Anmeldung, Prüfung, Bestätigung, Folgeprozesse. Jeder Schritt kann scheitern oder ausbleiben. Ein Monitor, der nur die Anmeldung als versendet zeigt, verdeckt, dass die Bestätigung des Netzbetreibers fehlt. Prozessmonitoring führt deshalb den Zustand des gesamten Vorgangs, nicht nur den Zustand einzelner Nachrichten.

Für die Praxis bedeutet das eine Sicht auf offene Vorgänge mit ihren Fristen. Wer heute weiß, welche Lieferbeginne noch auf eine Antwort warten, kann gezielt nachfassen. Wer erst am Monatsende feststellt, dass Vorgänge fehlen, korrigiert zu spät.

Ein gutes Monitoring trennt außerdem die Verantwortlichkeiten. Ein Netzbetreiber überwacht andere Vorgänge als ein Lieferant oder ein Messstellenbetreiber. Jede Rolle braucht die Sicht auf die Prozesse, die sie selbst anstößt oder bearbeitet. Eine gemeinsame Plattform hilft, aber jede Rolle muss ihre eigenen offenen Vorgänge und Fristen sehen können.

Ein Statusmodell für Marktprozesse

Ein belastbares Statusmodell bildet den Lebensweg eines Vorgangs ab. Für eine ausgehende Nachricht gehören dazu die Stufen: erstellt, übertragen, quittiert, verarbeitet, beantwortet. Für eine eingehende Nachricht gelten ähnliche Stufen aus Sicht des Empfängers. Jede Stufe hat einen dokumentierten Zustand.

Die Stufen folgen den Rückmeldungsebenen der Marktkommunikation. Die CONTRL bestätigt die Übertragung, die APERAK die Verarbeitbarkeit, die Geschäftsantwort das Ergebnis. Allgemeine Festlegungen Das Statusmodell übersetzt diese Ebenen in die Sprache des Betriebs.

Dabei gilt: Nicht jeder Statuswechsel ist ein Erfolg. Eine negative CONTRL, eine negative APERAK oder eine ablehnende Geschäftsantwort sind ebenfalls Ergebnisse. Das Monitoring muss sie sichtbar machen und die nächste Aktion bestimmen. Wer Ablehnungen nicht als Status führt, verliert sie im Datenstrom.

Fristen aktiv überwachen

Die Marktkommunikation lebt von Fristen. Prozesse geben vor, bis wann eine Meldung zu senden oder zu beantworten ist. Die Fristen sind je Regelwerk unterschiedlich und ändern sich mit den Festlegungen. Ein Monitor, der Fristen nicht kennt, kann Verspätungen nicht erkennen.

Für die Überwachung zählt der nächste relevante Zeitpunkt. Ein Vorgang ist dann kritisch, wenn eine erwartete Rückmeldung ausbleibt oder eine Frist abläuft. Das System sollte solche Vorgänge hervorheben und den Verantwortlichen informieren. Je enger die Fristen sind, desto wichtiger wird diese Vorwarnung. Der Lieferantenwechsel in 24 Stunden ist dafür das deutlichste Beispiel.

Die Fristberechnung folgt den Zeitregeln der Prozesse. Werktage, Feiertage und Tageszeiten beeinflussen das Raster. Ein System, das nur Kalendertage kennt, berechnet Fristen falsch. Die GPKE definiert ihre Zeitbegriffe selbst, etwa den Werktag. GPKE Diese Definitionen gehören in die Fristlogik des Monitors.

Für den Betrieb ist deshalb ein Fristenkalender nötig, der die Regeln der einzelnen Prozesse abbildet. Jeder Prozess kennt eigene Zeitpunkte, und jede Änderung einer Festlegung kann die Fristen verschieben. Wer die Fristen zentral pflegt, kann sie bei neuen Regeln schnell anpassen. Wer sie in der Verarbeitungslogik verstreut, muss bei jeder Änderung aufwendig suchen.

Wann ein Klärfall entsteht

Ein Klärfall entsteht, wenn ein Vorgang nicht automatisch abgeschlossen werden kann. Die Ursachen sind vielfältig. Häufig fehlen Stammdaten, etwa eine unbekannte Marktlokation oder ein nicht gepflegter Marktpartner. Oder die Zuordnung ist widersprüchlich, etwa wenn zwei Lieferanten dieselbe Marktlokation beanspruchen.

Weitere Ursachen liegen in der Nachricht selbst. Ein unzulässiger Zeitpunkt, eine fehlende Berechtigung oder eine nicht passende Kombination von Feldern führt zur Ablehnung. Auch ausbleibende Rückmeldungen erzeugen Klärfälle, weil der Vorgang nicht fortgesetzt werden kann. Klärfälle sind damit kein Zeichen für schwache Technik, sondern Teil des Marktbetriebs.

Für die Bearbeitung ist die Einordnung entscheidend. Ein Klärfall braucht eine fachliche Bewertung: Liegt der Fehler beim Sender, beim Empfänger oder in den Stammdaten? Wer diese Frage beantwortet, findet die richtige Korrektur. Ein Klärfall ohne Einordnung wandert zwischen den Abteilungen, statt gelöst zu werden.

Klärfälle steuern und dokumentieren

Die Steuerung von Klärfällen folgt einer klaren Logik. Jeder Klärfall braucht eine Identifikation, einen Verantwortlichen und eine Frist. Die Identifikation verweist auf den Vorgang und die betroffenen Objekte. Der Verantwortliche entscheidet über die Korrektur. Die Frist verhindert, dass der Fall liegen bleibt.

Die Dokumentation hält fest, was passiert ist. Welche Nachricht kam wann, welche Prüfung schlug fehl, welche Korrektur wurde vorgenommen? Diese Informationen sind die Grundlage für spätere Rückfragen und für die Verbesserung der Prozesse. Wer Klärfälle nicht dokumentiert, wiederholt dieselben Fehler.

Dazu kommt die Auswertung. Wiederholen sich bestimmte Klärfälle, deutet das auf eine systematische Ursache hin. Eine Marktlokation, die immer wieder falsch gemeldet wird, braucht eine Stammdatenkorrektur. Ein Feld, das häufig fehlt, weist auf ein Mapping-Problem hin. Die Auswertung der Klärfälle verbindet den Betrieb mit der Qualitätssicherung.

Eine sinnvolle Kennzahl ist die Zahl der offenen Klärfälle nach Alter. Sie zeigt, ob die Bearbeitung Schritt hält oder ob Fälle liegen bleiben. Ebenso aufschlussreich ist die Verteilung der Ursachen: Wie viele Klärfälle stammen aus fehlenden Stammdaten, wie viele aus fehlenden Rückmeldungen? Solche Auswertungen lenken die Aufmerksamkeit auf die größten Hebel und verhindern, dass das Team nur die lautesten Fälle bearbeitet.

Zu einer sauberen Steuerung gehört schließlich die Eskalation. Ein Klärfall, der eine Frist überschreitet oder einen kritischen Prozess blockiert, braucht eine höhere Bearbeitungsebene. Wer Eskalationsregeln definiert, stellt sicher, dass wichtige Fälle nicht in der Masse untergehen. Diese Regeln sollten einfach sein: eine Altersgrenze, ein festgelegter Eskalationsweg und ein dokumentiertes Ergebnis auf jeder Stufe.

Ein bewährtes Mittel ist ein täglicher Überblick für die Verantwortlichen. Er listet die offenen Vorgänge nach Alter und Risiko und nennt die nächste fällige Frist. Solche Überblicke ersetzen keine Detailarbeit, schaffen aber gemeinsame Prioritäten. Ohne sie entscheidet der Zufall, welcher Fall zuerst bearbeitet wird.

Bedeutung für SAP IS-U

In SAP-IS-U-Systemen gibt es mehrere Ebenen der Überwachung. Der Datenaustausch (IDE) protokolliert die eingehenden und ausgehenden Nachrichten, das Energiedatenmanagement überwacht die Werteverarbeitung. SAP Help: IDE SAP Help: EDM Diese Ebenen müssen zu einer Prozesssicht zusammengeführt werden.

Für SAP gilt wie für jedes System: Die Werkzeuge zeigen Nachrichten und Fehler, die Fachlichkeit interpretiert sie. Ein Fehlereintrag im Datenaustausch kann viele Ursachen haben. Erst die Zuordnung zum Prozess und zu den Objekten macht den Eintrag bewertbar. Fachliche Verantwortliche brauchen deshalb eine Sicht, die Nachrichten mit Vorgängen verbindet.

Der Intercompany Data Exchange für den deutschen Markt bietet dafür Funktionen, die auf die Marktkommunikation zugeschnitten sind. SAP Intercompany Data Exchange Die Einrichtung dieser Funktionen gehört in jedes Projekt, das Marktprozesse betreibt. Ohne sie bleibt die Fehlersuche auf den Rohdaten hängen.

In der Projektpraxis hat sich bewährt, Monitoring-Anforderungen aus den Prozessen abzuleiten. Für jeden betriebenen Prozess fragt das Team: Welche Schritte laufen, welche Rückmeldungen sind zu erwarten, welche Fristen gelten, welche Abweichungen sind kritisch? Aus diesen Antworten entsteht die Liste der Überwachungsfälle. Ein Monitoring, das nicht aus den Prozessen abgeleitet ist, zeigt entweder zu viel oder zu wenig.

Praxisbeispiel: Ein offener Lieferbeginn

Ein Lieferant hat einen Lieferbeginn angemeldet und wartet auf die Bestätigung des Netzbetreibers. Das Monitoring zeigt den Vorgang als offen. Die Frist läuft, eine Rückmeldung fehlt. Der zuständige Mitarbeiter prüft den Vorgang im System.

Er findet die gesendete Anmeldung, aber keine Bestätigung. Die Nachfrage beim Netzbetreiber ergibt, dass die Anmeldung dort einen Prüffehler ausgelöst hat und im Klärfall liegt. Der Netzbetreiber teilt den Grund mit: Die Marktlokation wurde nicht gefunden. Der Lieferant prüft die MaLo-ID und korrigiert die Anmeldung.

Im Beispiel zeigt sich der Wert des Prozessmonitorings. Ohne die Sicht auf den offenen Vorgang hätte der Lieferant den fehlenden Wechsel erst bei der Abrechnung bemerkt. Mit der Überwachung löst er die Störung, bevor sie Folgen hat.

Das Beispiel zeigt zugleich, wie wichtig die Zusammenarbeit zwischen den Marktpartnern bleibt. Das Monitoring zeigt den Zustand, die Ursache klärt der Austausch. Wer Klärfälle nur im eigenen System bearbeitet, ohne den Marktpartner einzubeziehen, verlängert die Bearbeitung. Die Marktkommunikation ist ein gemeinsamer Prozess, und die Klärung folgt derselben Logik.

Typische Missverständnisse

„Monitoring heißt: Nachrichtenlogs ansehen.“
Nein. Prozessmonitoring zeigt den Zustand von Vorgängen, nicht nur den Versand von Nachrichten.

„Eine positive CONTRL beendet den Vorgang.“
Nein. Sie quittiert die Übertragung. Der Vorgang läuft bis zur Geschäftsantwort weiter.

„Klärfälle sind immer eigene Fehler.“
Nein. Klärfälle entstehen auch durch fehlerhafte Nachrichten von Marktpartnern oder fehlende Rückmeldungen.

„Fristen kann man pauschal über Kalendertage rechnen.“
Nein. Die Fristen folgen den Zeitregeln der Prozesse mit Werktagen und Tageszeiten.

„Ein guter Nachrichtenmonitor ersetzt die Fachabteilung.“
Nein. Er liefert die Daten. Die fachliche Bewertung und die Klärung übernehmen Menschen.

Quellen und Pflegehinweis

Die Prozessregeln und Fristen stehen in den Festlegungen der Bundesnetzagentur, die Werkzeuge in der SAP-Dokumentation. Die konkrete Ausgestaltung von Monitoring und Klärfallbearbeitung hängt vom System und von den betriebenen Prozessen ab. Vor jeder Umsetzung die gültigen Prozessfassungen prüfen.

• SAP Help: SAP Intercompany Data Exchange for German Electric Utilities
• SAP Help: Intercompany Data Exchange (IDE)
• SAP Help: Energy Data Management (EDM)
• Bundesnetzagentur: Allgemeine Festlegungen zu den EDIFACT- und XML-Nachrichten
• EDI@Energy: Datenformate für die Marktkommunikation
• Bundesnetzagentur: Lieferantenwechsel (GPKE)

Abrufdatum aller Quellen: 7. September 2026.