Die Antwort zuerst: Die Jahresmeldung braucht eine laufende Ereignisakte
Netzbetreiber sollten jede relevante Versorgungsunterbrechung von Beginn an in einer gemeinsamen Ereignisakte führen. Darin werden Zeitpunkt, Dauer, Ausmaß und Ursache nicht erst zum Meldetermin rekonstruiert, sondern während Entstörung, Nachbereitung und Qualitätsprüfung schrittweise vervollständigt. So wird aus einer jährlichen Berichtspflicht ein beherrschbarer Datenprozess.
Die Bundesnetzagentur informiert öffentlich darüber, dass Betreiber von Elektrizitäts- und Gasnetzen jeweils bis zum 30. April über Versorgungsunterbrechungen des Vorjahres berichten müssen. Genannt werden als Inhalte Zeitpunkt, Dauer, Ausmaß und Ursache. Für die Datenübermittlung stehen ein Web-Formular im Energiedaten-Portal sowie ein XML-Webservice zur Verfügung. Diese knappe Beschreibung zeigt bereits die entscheidende Prozessfrage: Woher kommen die vier Kerndimensionen und wer bestätigt ihre Qualität?
Ein Ereignis hat mehrere Wahrheiten
Im Störungsfall arbeiten verschiedene Systeme und Rollen parallel. Die Leitstelle kennt Schaltzustände und Zeitpunkte. Außendienst oder Bereitschaft dokumentieren Befund und Maßnahmen vor Ort. Asset-Management liefert Betriebsmittel und technische Stammdaten. Kundenservice sieht Anrufe und lokale Auswirkungen. Geografische Systeme helfen bei der räumlichen Zuordnung. Keine dieser Quellen enthält automatisch das vollständige, widerspruchsfreie Ereignis.
Deshalb darf die Ereignisakte nicht mit einem einzelnen Export verwechselt werden. Sie ist der abgestimmte Datensatz, in dem operative Rohsignale zusammengeführt, Abweichungen geklärt und die für die Meldung relevante Fassung freigegeben werden. Die Rohdaten bleiben nachvollziehbar, die gemeldete Sicht erhält einen dokumentierten Status.
Zeitpunkt und Dauer brauchen gemeinsame Regeln
Zeitangaben wirken zunächst eindeutig. In der Praxis können jedoch Alarm, erste Kundenmeldung, bestätigter Ausfall, Schalthandlung, Teilwiederversorgung und vollständige Wiederversorgung auseinanderliegen. Ohne definierte Ereignislogik entstehen verschiedene Dauern für denselben Vorfall.
Ein Netzbetreiber sollte deshalb festlegen, welches Signal den Beginn markiert, wie Teilwiederversorgungen erfasst werden und wann ein Ereignis als beendet gilt. Automatisch erzeugte Zeitstempel sollten nicht überschrieben werden. Korrekturen benötigen einen Grund und eine Historie. Für Ereignisse, die mehrere Netzbereiche oder Betriebsmittel betreffen, muss klar sein, ob sie als ein zusammenhängendes Ereignis oder als mehrere Datensätze geführt werden.
Diese Regeln dienen nicht nur der externen Meldung. Sie machen auch interne Vergleiche über Jahre, Regionen und Störungstypen belastbarer.
Das Ausmaß entsteht aus Netz- und Kundenzuordnung
Das Ausmaß einer Unterbrechung lässt sich nicht zuverlässig aus der Zahl eingehender Anrufe ableiten. Erforderlich ist eine konsistente Zuordnung zwischen Netzstruktur, Schaltzustand, betroffenen Anschlüssen und Ereigniszeitraum. Dafür müssen Topologie- und Stammdaten aktuell genug sein, um die technische Lage in eine nachvollziehbare Betroffenheit zu übersetzen.
Ein guter Prozess dokumentiert die verwendete Datenbasis. Welche Netzversion war maßgeblich? Welche Zuordnung wurde automatisiert berechnet? Wo musste fachlich nachgearbeitet werden? Gab es provisorische Umschaltungen oder unvollständige Fernwirkinformationen? Solche Hinweise erklären später, warum sich ein zunächst geschätztes Ausmaß verändert hat.
Die Qualitätsprüfung sollte Ausreißer erkennen: ungewöhnlich hohe oder niedrige Betroffenheit, Ereignisse ohne zugeordnetes Betriebsmittel, unplausible Überschneidungen und Unterbrechungen mit Dauer, aber ohne belastbare Start- oder Endmarke.
Ursachenklassifikation ist ein Lernprozess
Die Ursache steht während der Entstörung häufig noch nicht abschließend fest. Eine erste operative Einordnung kann sich nach Sichtprüfung, Messung oder technischer Analyse ändern. Deshalb sollte die Ereignisakte zwischen vorläufiger und bestätigter Ursache unterscheiden.
Für die spätere Auswertung ist eine konsistente Klassifikation wichtiger als möglichst ausführlicher Freitext. Kategorien und Unterkategorien müssen verständlich definiert sein. Freitext bleibt dort sinnvoll, wo er die technische Besonderheit erklärt oder eine Zuordnung begründet. Wiederkehrende Fälle sollten in regelmäßigen Abständen gemeinsam geprüft werden, damit verschiedene Teams ähnliche Ereignisse nicht unterschiedlich klassifizieren.
Die Ursachenprüfung erzeugt außerdem betrieblichen Nutzen. Häufen sich Ereignisse an bestimmten Betriebsmitteltypen, Regionen oder Prozessübergaben, kann daraus ein Prüfauftrag für Instandhaltung, Schutztechnik, Vegetationsmanagement, Baukoordination oder Datenpflege entstehen. Die Jahresmeldung ist dann nicht das Ende der Datenkette, sondern ein Anlass für systematisches Lernen.
Rollen und Freigaben müssen vor dem Störungsfall klar sein
Eine praxistaugliche Rollenverteilung umfasst mindestens Ereignisverantwortung, technische Ursachenprüfung, Datenqualitätsprüfung und Meldefreigabe. Je nach Organisation können mehrere Rollen bei derselben Person liegen; ihre Aufgaben sollten dennoch getrennt beschrieben sein.
Die Leitstelle oder der Netzbetrieb eröffnet und ergänzt das Ereignis. Fachverantwortliche bestätigen technische Zuordnung und Ursache. Eine Datenrolle prüft Vollständigkeit, Formate und Plausibilität über alle Ereignisse. Die Meldeverantwortung erstellt die Jahresfassung, dokumentiert Korrekturen und übermittelt sie über den vorgesehenen Weg. Ein Vier-Augen-Prinzip sollte dort greifen, wo manuelle Änderungen die gemeldeten Kerndaten betreffen.
Vertretung ist Teil des Prozesses. Ein jährlicher Termin darf nicht von einer einzelnen Person, einem lokalen Tabellenstand oder einem nicht dokumentierten Zugang abhängen.
Web-Formular und XML-Webservice sind nur der letzte Transportweg
Die Bundesnetzagentur nennt Web-Formular und XML-Webservice als Übermittlungsverfahren. Die Wahl des Kanals löst jedoch keine vorgelagerten Qualitätsprobleme. Ein automatisierter Webservice kann fehlerhafte oder unvollständige Daten nur schneller übertragen. Ein Web-Formular kann bei kleinerem Volumen praktikabel sein, erhöht aber den Bedarf an kontrollierter manueller Übernahme.
Der interne Zieldatensatz sollte deshalb unabhängig vom Übermittlungsweg definiert sein. Aus ihm werden entweder die Eingaben für das Portal oder die technische Nachricht erzeugt. Validierungsfehler, Rückmeldungen und Korrekturen fließen wieder in die Ereignisakte zurück. Damit bleibt nachvollziehbar, welche Fassung wann übermittelt wurde.
Ein Jahreslauf mit vier Kontrollpunkten
Statt einer einmaligen Aktion im April empfiehlt sich ein Jahreslauf. Der erste Kontrollpunkt liegt direkt nach dem Ereignis: Sind Kerndaten vorhanden und ist eine Person für die Nachbereitung benannt? Der zweite liegt in einem monatlichen Qualitätslauf: Gibt es offene Ursachen, fehlende Zuordnungen oder unplausible Zeitangaben? Der dritte erfolgt nach Jahresende: Der Gesamtbestand wird auf Vollständigkeit, Dubletten und einheitliche Klassifikation geprüft. Der vierte Kontrollpunkt ist die formelle Freigabe und Übermittlung mit dokumentierter Rückmeldung.
Ein kleines Kennzahlenset unterstützt diesen Rhythmus: Anteil vollständig klassifizierter Ereignisse, Zahl offener Ursachen, Zeit bis zur fachlichen Bestätigung, Zahl manueller Korrekturen und Zahl technischer Validierungsfehler. Diese Kennzahlen messen die Reife des Datenprozesses, nicht die Versorgungsqualität selbst.
Fazit: Gute Meldedaten entstehen im Betrieb
Die Qualität einer Jahresmeldung wird in den Minuten, Tagen und Wochen nach einer Unterbrechung bestimmt. Wer erst vor dem Termin mit der Rekonstruktion beginnt, kann fehlende Zeitstempel, unklare Ursachen oder veraltete Zuordnungen oft nur noch schätzen. Eine gemeinsame Ereignisakte verbindet dagegen Entstörung, Nachbereitung, Datenqualität und Übermittlung.
Der Beitrag bleibt bewusst auf der Prozessebene. Maßgeblich für die konkrete Berichtspflicht, Form und Einzelfallbehandlung sind die jeweils aktuellen Vorgaben und Primärquellen. Die beschriebene Routine ist keine Rechtsberatung, sondern eine Methode für nachvollziehbare Betriebsdaten.