Zwischen Konsultationsende und finaler Festlegung liegt Arbeitszeit
Die Bundesnetzagentur hat am 1. Oktober 2026 den Entwurf BK8-26-001-A zur Konsultation gestellt. Gegenstand ist der Aufwendungsersatz für den bilanziellen Ausgleich bei Redispatch-Maßnahmen, wenn der Verteilnetzbetreiber keinen gezielten bilanziellen Ausgleich durchführt. Die Frist für Stellungnahmen endete am 21. Oktober. Nach Auswertung der Eingaben soll eine finale Festlegung folgen.
Für VNB entsteht damit eine typische Zwischenphase. Der Entwurf ist fachlich konkret genug, um Auswirkungen auf Abläufe und Daten zu erkennen. Er ist zugleich noch kein finaler Regelungsstand. Zwei Reaktionen wären deshalb unklug: vollständiges Abwarten und vorschnelle Produktivumsetzung. Die bessere Antwort ist ein operativer Trockenlauf mit klarer Veränderungskontrolle.
Ein solcher Test nimmt keine abschließende Auslegung vor. Er prüft, ob ein Fall durch die Organisation geführt werden kann: von der Maßnahme über Zeitbezug und Datenherkunft bis zur Zuordnung, Prüfung und Dokumentation. Alle Punkte, die von der finalen Festlegung abhängen, werden als Annahme markiert. Prozessbausteine, die unabhängig vom Detailwortlaut nötig sind, können dagegen schon heute stabilisiert werden.
Den Fall zuerst als Ereigniskette beschreiben
Redispatch wird in Organisationen häufig aus der Perspektive einzelner Systeme betrachtet. Netzführung sieht Abrufe, Marktprozesse sehen Fahrpläne und Zeitreihen, Abrechnung sieht Mengen und Zuordnungen, Regulierung sieht Nachweise. Im konkreten Fall müssen diese Ausschnitte jedoch zusammenpassen.
Der Trockenlauf beginnt deshalb mit einer Ereigniskette. Sie hält fest, wann eine Maßnahme erkannt, angekündigt, ausgelöst, geändert und beendet wurde. Danach werden die dazugehörigen Datenstände zugeordnet: technische Soll- und Ist-Werte, Kommunikationsnachrichten, Fahrpläne, Messwerte, Korrekturen und fachliche Entscheidungen. Jeder Schritt erhält einen Zeitstempel und eine verantwortliche Rolle.
Der Nutzen dieser Darstellung liegt in den Übergängen. Ein fachlich richtiger Einzelwert reicht nicht, wenn er zu spät eintrifft, einer anderen Version zugeordnet wird oder in der nächsten Rolle nicht eindeutig interpretierbar ist. Der Fall muss deshalb als Kette und nicht als Sammlung von Dateien testbar sein.
Annahmen und stabile Bausteine sichtbar trennen
Ein guter Trockenlauf unterscheidet drei Klassen. Die erste Klasse umfasst stabile Grundlagen: eindeutige Anlagen- und Fallkennzeichen, nachvollziehbare Zeitstempel, versionierte Eingangsdaten, dokumentierte Rollen und ein Korrekturweg. Diese Fähigkeiten werden unabhängig von einzelnen Detailentscheidungen gebraucht.
Die zweite Klasse umfasst entwurfsabhängige Regeln. Dazu können konkrete Fristen, Berechnungslogiken, Voraussetzungen oder Zuordnungen gehören. Sie werden im Test als Parameter behandelt und mit der Quellenstelle im Entwurf verknüpft. Ändert sich die finale Festlegung, wird der Parameter angepasst, ohne den gesamten Prozess neu zu bauen.
Die dritte Klasse umfasst offene Fragen. Hier darf der Test kein Scheinergebnis produzieren. Stattdessen entsteht ein Klärpunkt mit Eigentümer, benötigter Quelle und Auswirkung auf den Prozess. Diese Offenheit ist ein Qualitätsmerkmal. Sie verhindert, dass eine lokale Annahme unbemerkt zu einer vermeintlich verbindlichen Unternehmensregel wird.
Synthetische Fälle schützen Betrieb und Vertraulichkeit
Für den ersten Test sind keine produktiven Kunden- oder Anlagendaten erforderlich. Ein synthetischer Fall kann eine fiktive Anlage, definierte Viertelstunden, beispielhafte Nachrichten und bewusst eingebaute Abweichungen enthalten. Wichtig ist nicht die reale Identität, sondern die strukturelle Nähe zum späteren Prozess.
Mindestens vier Varianten sind sinnvoll. Der Normalfall enthält vollständige und rechtzeitige Daten. Ein zweiter Fall enthält eine verspätete Information. Ein dritter Fall arbeitet mit einer nachträglichen Datenkorrektur. Ein vierter Fall erzeugt einen Widerspruch zwischen Zeitreihe, Maßnahme und Zuordnung. So zeigt der Test nicht nur, ob der glückliche Pfad funktioniert, sondern auch, wie die Organisation mit Unsicherheit umgeht.
Jeder Fall endet mit einem Prüfprotokoll. Darin stehen verwendete Annahmen, Datenversionen, automatische und manuelle Schritte, offene Punkte sowie die Person oder Rolle, die eine Entscheidung freigegeben hat. Das Protokoll ist keine bloße Dokumentation im Nachgang. Es ist Teil des Prozesses.
Zeitstempel brauchen eine gemeinsame Bedeutung
In energiewirtschaftlichen Prozessen existieren häufig mehrere Zeitbegriffe: Entstehungszeit, Sendezeit, Empfangszeit, Verarbeitungszeit und fachliche Gültigkeit. Wenn diese Ebenen nicht getrennt werden, kann derselbe Vorgang in zwei Systemen unterschiedlich erscheinen. Für den Trockenlauf sollte deshalb ein kleiner Zeitkatalog festlegen, was jeder Zeitstempel bedeutet und aus welcher Quelle er stammt.
Besonders wichtig ist die Versionierung. Eine korrigierte Nachricht darf den ursprünglichen Stand nicht unsichtbar überschreiben. Der Prozess muss erkennen lassen, welche Version zu welchem Zeitpunkt vorlag und welche Folgeentscheidung darauf beruhte. Nur dann lässt sich später erklären, warum ein Fall so und nicht anders bearbeitet wurde.
Die technische Umsetzung kann einfach beginnen. Schon ein strukturiertes Ereignisregister mit Fall-ID, Ereignistyp, Quell-ID, fachlicher Zeit, Eingangszeit und Versionsnummer schafft mehr Klarheit als eine lose Ablage. Entscheidend ist, dass alle beteiligten Rollen dieselben Begriffe verwenden.
Übergaben sind die eigentlichen Testpunkte
Die meisten Störungen entstehen nicht innerhalb einer gut beherrschten Fachaufgabe, sondern an Übergaben. Netzführung übermittelt einen Fall an den Marktprozess. Marktprozess und Datenmanagement ordnen Zeitreihen zu. Abrechnung verarbeitet das Ergebnis. Regulierung oder Controlling benötigen später einen Nachweis.
Für jede Übergabe sollte der Trockenlauf vier Fragen beantworten: Welcher Mindestdatensatz wird übergeben? Welcher Status zeigt die fachliche Reife? Wie wird eine Ablehnung oder Rückfrage dokumentiert? Wer entscheidet bei einem Konflikt? Ohne diese Antworten wird ein Fall weitergereicht, obwohl er noch nicht entscheidungsfähig ist.
Ein kleines Statusmodell genügt häufig: angelegt, Daten unvollständig, fachlich in Prüfung, klärungsbedürftig, freigegeben und korrigiert. Der Status muss eine Bedeutung haben, nicht nur eine Farbe. Beispielsweise darf „freigegeben“ nur gesetzt werden, wenn definierte Pflichtdaten und Prüfungen erfüllt sind.
Betriebsbereitschaft ist mehr als ein erfolgreiches Rechenbeispiel
Ein Trockenlauf ist bestanden, wenn die Organisation den Fall reproduzierbar bearbeiten kann. Dazu gehören nicht nur korrekte Ergebnisse, sondern auch klare Zuständigkeiten, beherrschte Ausnahmen und nachvollziehbare Korrekturen. Sinnvolle Kennzahlen sind Durchlaufzeit, Zahl manueller Übergaben, Zahl offener Definitionen, Anteil automatisch geprüfter Daten und Zeit bis zur Klärung eines Widerspruchs.
Diese Kennzahlen sind keine regulatorischen Leistungsversprechen. Sie dienen der internen Reifeprüfung. Ein Prozess kann rechnerisch funktionieren und betrieblich dennoch fragil sein, wenn nur eine Person die Übergaben versteht oder Korrekturen außerhalb des Systems erfolgen. Der Test sollte genau diese Abhängigkeiten sichtbar machen.
Nach Veröffentlichung der finalen Festlegung folgt ein Änderungsabgleich. Jede relevante Passage wird gegen die im Trockenlauf verwendeten Parameter und Annahmen geprüft. Änderungen werden priorisiert, Tests wiederholt und Prozessunterlagen aktualisiert. Dadurch entsteht keine starre Vorwegnahme, sondern eine anpassbare Umsetzungsbasis.
Ein begrenzter Test schafft Handlungsfähigkeit
Die Zwischenphase nach der Konsultation ist kein Leerlauf. Sie ist die richtige Zeit, um Begriffe, Datenketten und Rollenübergaben unter kontrollierten Bedingungen zu prüfen. VNB müssen dabei weder produktive Fälle verändern noch den finalen Regelungsstand behaupten.
Ein sauber begrenzter Trockenlauf liefert drei Ergebnisse: eine Liste stabiler Prozessbausteine, ein Register entwurfsabhängiger Parameter und einen priorisierten Klärbestand. Damit kann die Organisation nach der finalen Festlegung gezielt reagieren, statt erst dann ihre Datenlandschaft und Zuständigkeiten zu entdecken.