Proaktive Stammdaten-Heilung — Die Agenten-Logik

Das Timing-Problem: Warum Batch nicht reicht

Ein klassisches Master-Data-Management-System synchronisiert Datenquellen in definierten Intervallen — typischerweise einmal täglich als Nachtlauf oder wöchentlich als Batch-Abgleich. Für den Redispatch-Kontext ist das strukturell zu langsam.

Eine Redispatch-Maßnahme kann innerhalb von Minuten angewiesen und innerhalb von Stunden beendet werden. Die kaufmännische Abrechnung dieser Maßnahme muss auf Stammdaten basieren, die zum Zeitpunkt der Maßnahme aktuell waren — nicht zum Zeitpunkt des letzten Batch-Laufs. Wenn ein BTR-Wechsel am Montag wirksam wird, die Abregelung am Dienstag erfolgt und der Batch-Abgleich erst am Sonntag läuft, dann rechnet das System fünf Tage lang gegen den falschen Betreiber ab. Bei einem KWK-Werk mit 10 MW Leistung und einem Strompreis von 80 €/MWh kann die Fehlzuordnung einer einzigen achtstündigen Maßnahme einen fünfstelligen Betrag betreffen.

Der agentische Ansatz: Kontinuierlicher Abgleich statt Monatsende-Korrektur

Ein Agentic-Asset-MDM-System im Redispatch-Kontext arbeitet nach einer anderen Logik. Es wartet nicht auf den Monatsabschluss, um Fehler zu erkennen. Es traversiert die relevanten Datenquellen täglich und gleicht drei zentrale Datenschichten gegeneinander ab:

Schicht 1: Das Anlagenregister. Alle redispatch-pflichtigen Anlagen (≥ 100 kW) mit ihren aktuellen Stammdaten — MaStR-Nummer, Anlagentyp, installierte Leistung, Netzanschlusspunkt (NAP), Marktlokation (MeLo), Spannungsebene, Betriebsstatus. Die autoritative Quelle ist das MaStR, abgeglichen gegen die lokalen Daten im ERP.

Schicht 2: Die BTR-Zuordnung. Für jede Anlage muss der aktuelle Betreiber der technischen Ressource identifizierbar sein. Die relevanten Quellen sind die EDIFACT-Stammdatenmeldungen (UTILMD), das ERP-System (Vertragspartner) und das MaStR (registrierter Betreiber). Ein Agent prüft die Konsistenz dieser drei Quellen und erkennt, wenn eine Quelle von den anderen abweicht.

Schicht 3: Die Abruf-Zuordnung. Jede Redispatch-Maßnahme im Leitsystem wird gegen die kaufmännischen Stammdaten abgeglichen: Ist die abgerufene technische Ressource einer gültigen MeLo zugeordnet? Stimmt die NAP-Zuordnung? Existiert ein aktueller Planwert für die betroffene Anlage?

Wie der Agent arbeitet: Ein konkreter Prüfzyklus

Der Agent durchläuft seinen Validierungszyklus in einem festen Rhythmus — idealerweise täglich, mindestens aber vor jedem Abrechnungslauf. Jeder Zyklus prüft das gesamte redispatch-relevante Portfolio und erzeugt einen strukturierten Validierungsreport.

Das folgende Beispiel zeigt den Output eines solchen Zyklus für ein Portfolio mit 59 Anlagen und einer Gesamtleistung von 73,4 MW:

{
 "agent": "agentic-asset-mdm",
 "module": "redispatch_prevalidation",
 "cycle": "daily_0600",
 "timestamp": "2026-03-28T06:00:12Z",
 "portfolio": {
   "grid_operator": "Beispiel-VNB",
   "total_installations": 59
 },
 "validation_results": {
   "fully_consistent": 51,
   "warnings": 5,
   "critical": 3,
   "findings": [
     {
       "severity": "CRITICAL",
       "type": "MISSING_BTR_DATA",
       "mastr_id": "SEE9XXXXX482910",
       "installation_name": "PV Freiflaeche Sued",
       "capacity_kw": 2298,
       "detail": "BTR-Zuordnung im ERP abgelaufen seit 2026-02-14. MaStR zeigt neuen Betreiber. UTILMD-Meldung fehlt.",
       "impact": "AAÜZ-Erzeugung blockiert. Kein gültiger Zahlungsempfänger.",
       "days_since_inconsistency": 42,
       "recommended_action": "ESCALATE_BTR_REQUEST"
     },
     {
       "severity": "CRITICAL",
       "type": "NAP_MELO_MISMATCH",
       "nap_id": "SAN9XXXXX641336",
       "detail": "NAP versorgt 5 Erzeugungseinheiten. 4 MeLo-IDs erwartet, aber nur 3 im ERP aktiv. MeLo für Gasturbine fehlt.",
       "impact": "Abrufe an Gasturbine nicht abrechenbar.",
       "recommended_action": "RESTORE_MELO_MAPPING"
     }
   ]
 },
 "billing_readiness": {
   "ready_for_aauz": 51,
   "blocked": 3,
   "next_billing_run": "2026-04-01"
 }
}

Drei Aspekte dieses Validierungsreports sind für das Verständnis der agentischen Logik zentral:

Die Kategorie MISSING_BTR_DATA. Der Agent erkennt nicht erst am Monatsende, dass die BTR-Zuordnung für eine 2,3-MW-Anlage fehlt. Er erkennt es 42 Tage vor dem Abrechnungslauf und identifiziert die Ursache (MaStR-Update ohne korrespondierende UTILMD-Meldung). Er kann den Eskalationsprozess eigenständig anstoßen.

Die Kategorie NAP_MELO_MISMATCH. Dieses Finding zeigt ein Problem, das bei manueller Prüfung nahezu unsichtbar ist. Ein Netzanschlusspunkt versorgt fünf Erzeugungseinheiten, die über vier Marktlokationen abgerechnet werden. Wenn eine MeLo-Zuordnung verloren geht, verteilt das System die Ausfallarbeit auf die verbleibenden MeLos — mathematisch korrekt, kaufmännisch falsch. Der Agent erkennt die Diskrepanz durch den Abgleich von MaStR-NAP-Verknüpfungen.

Der zweite Agent: Tagesabgleich Abruf gegen Stammdaten

Neben dem Portfolio-Validierungsagenten arbeitet ein zweiter Agent auf der operativen Ebene: Er gleicht jede einzelne Redispatch-Maßnahme des Vortages gegen die aktuellen Stammdaten ab.

{
 "agent": "agentic-asset-mdm",
 "module": "redispatch_daily_reconciliation",
 "date": "2026-03-27",
 "reconciliation": [
   {
     "measure_id": "RD-2026-0327-002",
     "timestamp_start": "2026-03-27T14:15:00Z",
     "scada_resource": "PV_SUED_01",
     "power_reduction_kw": 1500,
     "status": "BLOCKED",
     "blocking_reason": "MISSING_BTR_DATA",
     "reference": "Portfolio finding SEE9XXXXX482910",
     "action": "Maßnahme in Quarantäne. AAÜZ-Erzeugung gesperrt bis BTR-Klärung abgeschlossen. Frist für BTR-Klärung: 2026-04-15."
   }
 ],
 "summary": {
   "matched": 2,
   "blocked": 1,
   "total_ausfallarbeit_blocked_kwh": 3375,
   "aauz_ready_with_exclusions": "1 Maßnahme in Quarantäne (PV_SUED_01). Verbleibende Maßnahmen abrechnungsfähig."
 }
}

Der entscheidende Mechanismus ist der Status BLOCKED. Der Agent lässt eine Maßnahme nicht in die AAÜZ-Erzeugung einfließen, wenn die Stammdaten-Konsistenz nicht bestätigt ist. Stattdessen wird die Maßnahme in Quarantäne gesetzt — sie wird nicht abgerechnet, nicht ignoriert und nicht manuell „zurechtgebogen". Das ist der fundamentale Unterschied zum Notfallverfahren: Der Agent verhindert, dass fehlerhafte Daten in den Abrechnungslauf gelangen.

Die Prozesskette: Von der Erkennung zur Heilung

Der agentische Ansatz im Redispatch unterscheidet drei Eskalationsstufen:

Stufe 1 — Automatische Heilung. Inkonsistenzen, die der Agent eigenständig auflösen kann (z.B. veraltete Prognoseprofile bei Anlagen-Erweiterung). Keine menschliche Interaktion erforderlich.

Stufe 2 — Angereicherte Eskalation. Inkonsistenzen, die eine menschliche Entscheidung erfordern. Beispiel: Die BTR-Zuordnung fehlt. Der Agent bereitet eine UTILMD-Anforderung vor und legt sie dem Sachbearbeiter zur Freigabe vor.

Stufe 3 — Quarantäne. Maßnahmen, die weder automatisch noch durch Eskalation rechtzeitig lösbar sind. Sie werden isoliert und aus dem regulären SAP-Lauf ausgeschlossen. Der SAP-Abrechnungslauf läuft störungsfrei für alle konsistenten Maßnahmen durch. Die Blockade des gesamten Laufes durch einen Einzelfehler ist Geschichte.