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.