MaKo-Prozessmonitoring und Datenqualität
Wie Marktkommunikationsprozesse durch Rollen-, Datenobjekt- und Nachrichtenkonsistenz operativ stabil gehalten werden.
Marktkommunikation ist im Tagesbetrieb weniger ein einzelnes EDIFACT-Format als eine durchgängige Prozesskette. Lieferanten, Verteilnetzbetreiber, Messstellenbetreiber und Bilanzkreisverantwortliche müssen dieselben Marktlokationen, Messlokationen, Marktpartner, Zeitpunkte und Statusinformationen verwenden. Wenn diese Bezüge auseinanderlaufen, entstehen Clearingfälle, APERAK-Schleifen, verspätete Wechsel, unklare Messwertläufe oder fehlerhafte Abrechnung.
Diese Seite betrachtet Marktkommunikation deshalb als operatives Datenqualitäts- und Monitoringproblem. Die fachlichen Grundlagen zu GPKE, WiM, GeLi Gas, EDIFACT und Marktrollen bleiben in Quellartikeln erklärt; Cernion vertieft die Frage, wie die Prozesskette im laufenden Betrieb prüfbar und stabil bleibt.
Operatives Problem
Viele MaKo-Fehler werden erst sichtbar, wenn ein Prozess bereits stockt. Beispiele sind:
- eine UTILMD-Nachricht ist formal versendet, passt aber nicht zum erwarteten MaLo-/MeLo-Bezug
- ein APERAK-Fehler wird empfangen, aber nicht als fristrelevanter Eskalationsfall erkannt
- MSCONS-Werte treffen ein, können aber nicht eindeutig einer Abrechnungseinheit zugeordnet werden
- Marktpartner- oder Bilanzkreiszuordnungen unterscheiden sich zwischen EDM, CRM, Abrechnung und MaKo-System
- manuelle Korrekturen schließen einen Einzelfall, erzeugen aber neue Abweichungen in Folgesystemen
Das Risiko liegt nicht nur in der einzelnen Nachricht. Entscheidend ist, ob Nachricht, Stammdatensatz, Marktrolle und Prozessstatus zusammenpassen.
Betroffene Marktrollen
Ein MaKo-Monitoring muss die Sicht mehrerer Rollen verbinden:
- Lieferant: benötigt bestätigte Lieferzeiträume, korrekte Kundenzuordnung, Bilanzkreisbezug und klare Rückmeldungen zu Anmeldungen, Abmeldungen oder Stammdatenänderungen.
- Verteilnetzbetreiber: prüft Marktlokation, Netzgebiet, Bilanzierungsgebiet, Marktpartner und technische Zuordnungen.
- Messstellenbetreiber: hält Messlokation, Zähler, Messkonzept, Gerätewechsel und Messwertqualität stabil.
- Bilanzkreisverantwortlicher: ist betroffen, wenn Lieferbeginn, Profil, Messwerte oder Zuordnung nicht sauber in Bilanzierung und Abrechnung ankommen.
- Service- und Clearingteams: müssen erkennen, ob ein Fall ein fachlicher Widerspruch, ein Fristproblem oder ein technischer Nachrichtenfehler ist.
Relevante Datenobjekte
Für eine belastbare Prüfung sind vor allem diese Objekte kritisch:
- Marktlokation, Messlokation, Zählpunkt und Zählernummer
- Marktpartner-ID, BDEW-Codenummer, Lieferant, Netzbetreiber und Messstellenbetreiber
- Bilanzkreis, Bilanzierungsgebiet, Lastprofil und Messkonzept
- Lieferbeginn, Lieferende, Fristen, Status und Prozessschritt
- UTILMD-, APERAK-, MSCONS-, INVOIC-, ORDERS- und REMADV-Nachrichten
- MaStR- und Anlagenbezüge, sofern Erzeugung, steuerbare Verbrauchseinrichtungen oder Prosumer-Fälle betroffen sind
Ein stabiler MaKo-Prozess braucht keine isolierte Prüfung dieser Felder, sondern eine Konsistenzprüfung über Systemgrenzen hinweg.
Prozesspunkte mit hohem Risiko
Besonders anfällig sind Übergänge zwischen fachlicher Entscheidung und maschineller Nachricht:
- Vor dem Versand: Sind Rolle, MaLo, MeLo, Bilanzkreis, Frist und Nachrichtenanlass konsistent?
- Beim Eingang der Rückmeldung: Wird ein APERAK- oder UTILMD-Fehler fachlich klassifiziert und priorisiert?
- Bei Korrektur und Wiederholung: Ist klar, welcher Datensatz korrigiert wurde und welche Folgesysteme denselben Stand benötigen?
- Bei Messwert- und Abrechnungsläufen: Passen MSCONS-Werte, Profile, Marktlokation und Abrechnungszeitraum zusammen?
- Beim Reporting: Sind offene Clearingfälle, Fristverletzungen und wiederkehrende Datenfehler nach Ursache sichtbar?
Ohne diese Sicht entstehen Schattenlisten, manuelle Wiedervorlagen und unklare Verantwortlichkeiten zwischen Fachbereich und IT.
Cernion-Prüfansatz
Cernion behandelt Marktkommunikation als überprüfbaren Prozessgraphen. Ein geeigneter Check verbindet:
- Rollen- und Marktpartnerkonsistenz über Lieferant, VNB, MSB und BKV
- MaLo-/MeLo- und Messkonzeptprüfung über Stammdaten, Nachrichten und Folgesysteme
- Erkennung wiederkehrender APERAK-, UTILMD- und MSCONS-Fehlercluster
- Frist- und Statussicht auf offene GPKE-, WiM-, GeLi-Gas- und MaBiS-Prozesse
- Abgleich von MaStR-, Anlagen- und Profilinformationen, wenn sie den Prozess beeinflussen
- nachvollziehbare Evidenz, welcher Datenstand zu welchem Zeitpunkt eine Entscheidung oder Eskalation ausgelöst hat
Damit wird aus der allgemeinen Frage "funktioniert die Marktkommunikation?" eine konkrete Prüfliste: Welche Datenobjekte widersprechen sich, welcher Prozess ist betroffen, wer muss handeln und welche Fälle haben Frist- oder Abrechnungswirkung?
Bezug zu weiteren Wiki-Seiten
Für konkrete Teilprobleme sind diese Vertiefungen relevant:
- GPKE-Fristen und Stammdatenqualität für Wechselprozesse, Fristwirkung und MaLo-/MeLo-Konsistenz.
- SLP25, MaBiS und Stammdatenqualität für Profil-, Bilanzierungs- und MaBiS-nahe Datenrisiken.
- Multidimensionale Qualitätsmetriken für Energiedaten für die Bewertung von Datenqualität als wiederholbaren Audit-Prozess.
Grenzen
Diese Seite ersetzt keine BDEW-Anwendungshilfe, keine verbindliche Prozessauslegung und kein Format-Handbuch. Sie beschreibt den operativen Prüf- und Monitoringlayer hinter bestehenden Marktkommunikationsprozessen. Fachliche Grundlagen, EDIFACT-Beispiele und Rollenüberblick sollten in erklärenden Quellartikeln bleiben; die Cernion-Seite vertieft die Stabilitäts-, Datenqualitäts- und Überwachungsfrage.
Kurzfassung für Quellseiten
Wenn Marktkommunikation nicht nur erklärt, sondern operativ stabil betrieben werden soll, müssen Marktrollen, MaLo-/MeLo-Bezüge, Bilanzkreis, Messwerte, Nachrichtenstatus und Fristen zusammen betrachtet werden. Cernion ordnet diese Zusammenhänge als Prozessmonitoring- und Datenqualitätsprüfung ein.
Agentic Asset-MDM in der Praxis
Theoretische Methodik ist gut – operative Software ist besser. Cernion bietet die schlüsselfertige Architektur zur automatisierten Konsistenzprüfung, basierend auf den Prinzipien dieses Wikis (Local-First, XAI, OEO).
Use-Case besprechen →