Die Antwort zuerst: Fehlende Werte brauchen einen sichtbaren Betriebsstatus
SMARD hat im Oktober 2026 darauf hingewiesen, dass Zeitreihen zur Stromerzeugung zeitweise unvollständig waren. Ursache waren Verzögerungen auf der Transparenzplattform von ENTSO-E, von der gemeldete Erzeugungs- und Verbrauchsdaten übernommen werden. SMARD erklärte zugleich, keine Schätzwerte anstelle der fehlenden Meldungen zu veröffentlichen. Später wurden fehlende Daten nachgeliefert.
Der Vorgang ist ein nützlicher Praxisfall für Stadtwerke. Externe Zeitreihen fließen in Marktbeobachtung, Beschaffungsberichte, Netzanalysen, Kommunikationsgrafiken und automatisierte Auswertungen ein. Wenn Werte fehlen, darf ein Dashboard nicht so aussehen, als sei die Welt vollständig beobachtet. Entscheidend ist ein sichtbarer Qualitätsstatus: vollständig, verspätet, vorläufig, korrigiert oder nicht verfügbar.
Eine Quelle ist eine Lieferkette
Der Name einer Plattform beschreibt noch nicht die gesamte Herkunft. Eine veröffentlichte Zeitreihe kann von Marktakteuren oder Netzbetreibern gemeldet, über eine europäische Plattform verteilt, von einer nationalen Plattform übernommen und schließlich in ein internes Datenprodukt geladen werden. Auf jeder Stufe können Verzögerungen, Korrekturen oder Formatänderungen auftreten.
Für jede wichtige externe Zeitreihe sollte deshalb eine kompakte Herkunftskarte existieren. Sie nennt Primärmelder beziehungsweise Ursprung, Übertragungsplattform, interne Abrufstelle, Aktualisierungsrhythmus, erwartete Verzögerung und fachliche Verwendung. Ebenso wichtig ist die Frage, ob die Daten nachträglich aktualisiert werden können. Eine Kennzahl aus einem täglichen Bericht kann sonst später von der erneut abgerufenen Zeitreihe abweichen, ohne dass ein Fehler vorliegt.
Die Herkunftskarte muss nicht öffentlich sein. Sie ist eine interne Betriebsgrundlage für Analysten, Fachbereiche und automatisierte Systeme. Ihr Wert zeigt sich, wenn eine Quelle ausfällt: Das Team weiß, wo geprüft werden muss und welche Produkte betroffen sind.
Fehlend, null und unverändert sind drei verschiedene Zustände
In Zeitreihen werden Datenlücken häufig technisch als Null, leeres Feld oder letzter bekannter Wert behandelt. Fachlich sind das sehr unterschiedliche Aussagen. Null kann eine echte Messung sein. Ein leeres Feld kann fehlende Lieferung bedeuten. Ein fortgeschriebener Altwert kann eine bewusste Annahme oder ein unbemerkter Fehler sein. Wer diese Zustände nicht trennt, verändert die Aussage der Daten.
Ein solides Datenmodell führt deshalb neben dem Wert mindestens einen Qualitätsstatus und einen Zeitstempel der Quelle. Optional kommen Veröffentlichungs- und Abrufzeit hinzu. So lässt sich erkennen, ob ein Wert zum erwarteten Zeitpunkt vorlag, später korrigiert wurde oder weiterhin fehlt. Dashboards können daraus verständliche Hinweise ableiten, statt Lücken optisch zu verstecken.
Schätzwerte sind nicht grundsätzlich verboten. Sie müssen jedoch als Schätzung gekennzeichnet, methodisch dokumentiert und für den jeweiligen Zweck freigegeben sein. Eine operative Prognose darf möglicherweise mit einer Ersatzmethode weiterlaufen. Ein Bericht über tatsächlich veröffentlichte Marktdaten sollte dagegen klar zwischen gemeldetem Wert und Schätzung unterscheiden. Die Entscheidung hängt vom Anwendungsfall ab, nicht von der Bequemlichkeit des Systems.
Die Lückenregel gehört vor den Ausfall
Unter Zeitdruck entstehen schlechte Ersatzlösungen. Deshalb braucht jede wichtige Datenanwendung vorab eine Lückenregel. Sie beantwortet fünf Fragen: Ab wann gilt eine Lieferung als verspätet? Wer wird informiert? Welche Anzeigen oder Berechnungen werden gestoppt? Ist eine Ersatzquelle oder Schätzung erlaubt? Wie wird nach der Nachlieferung neu gerechnet?
Für ein internes Lagebild kann beispielsweise ein gelber Status mit dem letzten vollständigen Datenstand genügen. Für eine automatisierte Veröffentlichung kann die Regel strenger sein: keine Aktualisierung, solange zentrale Zeitreihen unvollständig sind. Für eine Prognoseanwendung kann eine gekennzeichnete Ersatzschätzung zulässig sein. Wichtig ist, dass der Modus sichtbar bleibt und nicht unbemerkt zum Normalzustand wird.
Auch KI-gestützte Analysen brauchen diese Grenze. Ein Sprachmodell kann eine Lücke sprachlich elegant überdecken, aber keinen fehlenden Messwert erzeugen. Eingabedaten sollten Qualitätsmarker enthalten, und Ausgaben müssen erkennen lassen, wenn Aussagen auf unvollständigen Reihen beruhen. Automatisierung darf Unsicherheit strukturieren, nicht verbergen.
Wiederanlauf bedeutet mehr als neue Daten abrufen
Wenn die Quelle nachliefert, ist der Vorfall nicht automatisch abgeschlossen. Betroffene Zeiträume müssen erneut geladen, validiert und gegebenenfalls nachberechnet werden. Dashboards, Berichte oder abgeleitete Kennzahlen können bereits auf dem unvollständigen Stand erzeugt worden sein. Ein Wiederanlaufplan führt deshalb eine Wirkungsliste: Welche Produkte verwenden die Zeitreihe und welche davon müssen aktualisiert werden?
Ein kontrollierter Wiederanlauf vergleicht die nachgelieferte Fassung mit dem zuvor bekannten Stand. Er prüft, ob nur Lücken geschlossen oder auch vorhandene Werte korrigiert wurden. Anschließend werden abhängige Auswertungen in definierter Reihenfolge neu erzeugt. Der Vorfall endet mit einem dokumentierten aktuellen Datenstand, nicht mit dem ersten erfolgreichen HTTP-Abruf.
Öffentliche Daten brauchen interne Verantwortung
Frei verfügbare Daten wirken oft wie ein kostenloser Rohstoff ohne Betriebspflicht. Sobald ein Stadtwerk sie regelmäßig nutzt, entsteht jedoch interne Verantwortung. Jemand muss Quelle, Lizenzhinweis, Abruf, Qualität und Änderungen beobachten. Das gilt auch für Daten, die unter offenen Nutzungsbedingungen bereitstehen. Die rechtliche Verfügbarkeit ersetzt keine fachliche Qualitätssicherung.
Eine einfache Zuständigkeitsmatrix reicht: fachlicher Eigentümer der Zeitreihe, technischer Betreiber des Imports, Verantwortlicher für das Datenprodukt und Empfänger von Störungsmeldungen. Bei kleinen Anwendungen können mehrere Rollen bei einer Person liegen. Entscheidend ist, dass der Ausfall nicht zwischen Marktanalyse und IT verschwindet.
Ein schlanker Praxistest
Stadtwerke können ihre Routine mit einer bewusst unterbrochenen Testreihe prüfen. Ein Tag oder mehrere Viertelstunden werden aus einem synthetischen Import entfernt. Das Team beobachtet, ob der Qualitätsstatus anschlägt, ob Berechnungen angemessen reagieren und ob Nutzer die Einschränkung verstehen. Danach werden Werte nachgeliefert und der Wiederanlauf ausgeführt.
Der Test sollte mindestens ein Dashboard, einen Export und eine abgeleitete Kennzahl umfassen. Besonders aufschlussreich ist die Frage, ob alte Berichte reproduzierbar bleiben und neue Berichte den korrigierten Stand erhalten. So wird sichtbar, ob Versionierung und Datenstand wirklich zusammenpassen.
Aus der Datenlücke wird eine Qualitätsroutine
Die praktische Betriebsakte enthält Herkunftskarte, erwarteten Aktualisierungsrhythmus, Qualitätsstatus, Lückenregel, betroffene Produkte und Wiederanlaufplan. Ergänzt wird sie um eine kurze Kommunikationsvorlage: Quelle verzögert, Datenstand, betroffene Aussagen, nächster Prüfzeitpunkt.
Damit lässt sich eine externe Störung sachlich behandeln. Die Organisation bleibt arbeitsfähig, ohne Vollständigkeit vorzutäuschen. Gerade in einer Energiewirtschaft mit immer mehr automatisierten Datenflüssen ist diese Fähigkeit wichtiger als ein scheinbar lückenloses Dashboard.