Der Stichtag ist nicht das eigentliche Problem
Die Beschlusskammer 6 der Bundesnetzagentur hat mit Mitteilung Nr. 56 überarbeitete Nachrichtentypversionen zur Abwicklung der Marktkommunikation veröffentlicht. Genannt werden unter anderem EDIFACT-Dokumente, Entscheidungsbaum-Diagramme, Regelungen zum Übertragungsweg AS4 und ergänzende Hinweise zu API-Webdiensten und XML-Dateien. Die veröffentlichten Versionen gelten grundsätzlich ab dem 01.10.2026 verbindlich für umsetzungspflichtige Marktteilnehmer.
Für Stadtwerke klingt das zunächst nach einem klassischen Releasewechsel. Dokumente werden heruntergeladen, Dienstleister erhalten Prüfaufträge, Systeme werden angepasst, Testfenster werden eingeplant. Doch diese Lesart greift zu kurz. Ein MaKo-Release ist immer auch ein Datenqualitätstest. Es prüft, ob Marktrollen, Identifikatoren, Kommunikationswege, Berechtigungen, Prüfregeln und fachliche Verantwortlichkeiten so zusammenpassen, dass ein massengeschäftstauglicher Betrieb am Stichtag nicht ins Rutschen kommt.
Gerade kleinere und mittlere Häuser laufen Gefahr, den Releasekalender als externes Ereignis zu behandeln. Dann entsteht bis kurz vor dem Termin ein scheinbar geordnetes Bild: Dienstleister arbeiten, Verbände informieren, interne Listen wachsen. Die eigentliche Frage bleibt aber offen: Welche konkreten Geschäftsprozesse, Stammdatenfelder, Fehlerantworten und Eskalationswege sind im eigenen Betrieb betroffen? Wer kann im Fachbereich erklären, warum eine neue Nachrichtenversion nicht nur syntaktisch, sondern fachlich relevant ist?
Dokumente müssen in Datenobjekte übersetzt werden
Die Veröffentlichung enthält zahlreiche Artefakte: Anwendungshandbücher, Nachrichtenbeschreibungen, Prüfidentifikatoren, Codelisten, Regelungen zum Übertragungsweg und weitere begleitende Dokumente. Im Alltag eines Stadtwerks dürfen diese Artefakte nicht nur als PDF-Sammlung existieren. Sie müssen in betriebliche Datenobjekte übersetzt werden.
Dazu gehören mindestens eine betroffene Prozessliste, eine Zuordnung der Nachrichtentypen zu Marktrollen, ein Feldkatalog für kritische Stammdaten, eine Liste der relevanten Prüfidentifikatoren, ein AS4-Kommunikationsregister und eine Übersicht der Systeme und Dienstleister, die Nachrichten erzeugen, empfangen, validieren oder archivieren. Erst diese Übersetzung macht sichtbar, wo ein Release tatsächlich wirkt.
Ein Beispiel: Wenn ein Anwendungshandbuch angepasst wird, kann das Auswirkungen auf Eingangskontrollen, Fehlermeldungen, Clearingfälle oder Abrechnungsdaten haben. Wird nur die technische Schnittstelle aktualisiert, bleibt unklar, ob Fachbereiche die neuen Fehlerbilder verstehen. Wird nur der Fachbereich informiert, bleibt offen, ob das System die geänderte Prüfung wirklich ausführt. Die Brücke zwischen beidem ist Daten-Governance.
AS4 ist Betriebsführung, nicht nur Übertragungsweg
Die Regelungen zum Übertragungsweg sind für viele Organisationen besonders heikel, weil sie an der Schnittstelle zwischen Marktkommunikation, IT-Betrieb, Zertifikaten, Dienstleistern und Marktpartnern liegen. Ein funktionierender Übertragungsweg beweist nicht automatisch, dass der gesamte Prozess belastbar ist. Zertifikate können auslaufen, Empfängerprofile können veraltet sein, Rollen können falsch zugeordnet sein, Quittungen können nicht ausgewertet werden, und Störungen können in der falschen Organisationseinheit landen.
Deshalb sollte AS4 nicht als einmaliger Technikcheck behandelt werden. Sinnvoll ist eine kleine Betriebsakte: Marktpartner, Marktrolle, Kommunikationsendpunkt, Zertifikatsstatus, zuständiger Dienstleister, letzte erfolgreiche Testnachricht, Quittungsverhalten, Fehlerantworten, Eskalationskontakt und Wiederanlaufpfad. Diese Akte muss nicht groß sein. Sie muss aber aktuell sein und im Störfall erreichbar bleiben.
Für die Geschäftsleitung entsteht daraus eine einfache Kontrollfrage: Kann das Haus zeigen, dass ein Releasewechsel nicht nur installiert, sondern fachlich, technisch und organisatorisch freigegeben wurde? Wenn diese Frage nicht beantwortet werden kann, ist der Stichtag noch nicht vorbereitet, selbst wenn der Dienstleister grünes Licht signalisiert.
Prüfidentifikatoren sind Frühwarnsysteme
Prüfidentifikatoren werden oft erst sichtbar, wenn Nachrichten abgelehnt werden. Gerade deshalb eignen sie sich als Frühwarnsystem. Stadtwerke sollten vor dem Stichtag nicht nur fragen, ob die neue Anwendungsübersicht eingespielt wird. Sie sollten eine kleine Fehlerlandkarte erstellen: Welche Prüfungen betreffen häufige Prozesse? Welche Fehler sind rein formal? Welche Fehler deuten auf Stammdatenprobleme hin? Welche Fehler müssen an den Fachbereich, welche an IT oder Dienstleister?
Eine solche Fehlerlandkarte reduziert die Reaktionszeit nach dem Release. Sie verhindert auch, dass Clearingfälle als Einzelfälle behandelt werden, obwohl sie auf ein systematisches Datenproblem hinweisen. Wenn zum Beispiel eine Klasse von Nachrichten wiederholt an derselben Information scheitert, ist das kein Kommunikationsproblem, sondern ein Stammdaten- oder Prozessproblem.
Der Nutzen liegt nicht nur in weniger Nacharbeit. Prüfidentifikatoren schaffen eine gemeinsame Sprache zwischen Fachbereich und Technik. Statt allgemein über „MaKo-Fehler“ zu sprechen, kann das Team sagen: Diese Fehlerklasse betrifft diese Datenquelle, diese Marktrolle, diesen Dienstleister und diesen Prozessschritt. Damit wird aus Fehlerbearbeitung eine steuerbare Qualitätsroutine.
Der Releaseplan braucht fachliche Abnahme
Ein belastbarer Releaseplan enthält mehr als Meilensteine. Er beschreibt, welche Prozesse getestet werden, welche Testfälle als ausreichend gelten, welche Datenbestände vorab bereinigt werden, wer den Go-live fachlich freigibt und wie nach dem Stichtag überwacht wird. Dabei sollte der Plan bewusst zwischen technischer Bereitschaft und fachlicher Wirksamkeit unterscheiden.
Technische Bereitschaft bedeutet: Systeme sind aktualisiert, Kommunikationswege erreichbar, Zertifikate gültig, Nachrichtenversionen verfügbar. Fachliche Wirksamkeit bedeutet: Die Organisation versteht die betroffenen Prozesse, erkennt Fehlerbilder, kann Clearing priorisieren und weiß, welche Datenqualität für einen stabilen Betrieb notwendig ist. Beides muss zusammenkommen.
Für Stadtwerke empfiehlt sich ein kurzer Drei-Schritt-Ansatz. Erstens: Release-Artefakte in eine betroffene Prozess- und Datenmatrix übersetzen. Zweitens: typische Nachrichtenszenarien mit echten Rollen, realistischen Stammdaten und erwarteten Fehlerantworten testen. Drittens: die ersten Wochen nach dem Stichtag als Beobachtungsphase führen, in der Fehlerklassen, Mengen, Ursachen und Maßnahmen täglich oder wöchentlich betrachtet werden.
Führung entscheidet über Ruhe im Betrieb
MaKo-Releases werden nicht dadurch sicher, dass jede Detailregel in der Führungsebene gelesen wird. Sie werden sicher, wenn Führung die richtigen Fragen stellt: Gibt es eine eindeutige Verantwortlichkeit? Sind Dienstleister und Fachbereiche synchron? Sind kritische Stammdaten geprüft? Sind AS4-Wege und Zertifikate nachvollziehbar? Sind Prüfidentifikatoren als Fehlerklassen verstanden? Gibt es ein Lagebild nach dem Stichtag?
Die Bundesnetzagentur veröffentlicht mit den Datenformaten den marktweiten Rahmen. Die eigentliche Betriebsqualität entsteht im Stadtwerk. Dort entscheidet sich, ob aus neuen Nachrichtenversionen ein ruhiger Regelbetrieb oder ein Stapel ungeklärter Fälle wird. Wer den Release als Datenqualitätsprüfung behandelt, gewinnt nicht nur Stichtagssicherheit. Er verbessert dauerhaft die Fähigkeit, Marktkommunikation als Führungsaufgabe zu betreiben.