Release-Management für die Marktkommunikation

Kurzantwort

Die Marktkommunikation ändert sich in festen Zyklen. Die Bundesnetzagentur konsultiert und beschließt neue Prozessfassungen, EDI@Energy veröffentlicht überarbeitete Nachrichtentypen, und die Marktpartner setzen die Änderungen zu Umsetzungsterminen um. Üblich sind Termine zum 1. April und zum 1. Oktober eines Jahres, ergänzt um außerordentliche Termine.

Für SAP-IS-U-Projekte heißt das: Release-Management ist keine IT-Übung, sondern ein fachlicher Prozess. Jede Änderung braucht eine Betroffenheitsanalyse, eine Anpassung von Prozessen und Formaten, Tests gegen den neuen Stand und eine geordnete Einführung. Wer erst am Umsetzungstermin beginnt, scheitert an der Frist.

Der Artikel beschreibt die Quellen von Änderungen, den Zyklus der Umsetzungstermine und die Schritte von der Analyse bis zum produktiven Betrieb. Er richtet sich an alle, die Marktprozesse in SAP-IS-U-Systemen pflegen oder Releases koordinieren.

Woher Änderungen kommen

Änderungen an der Marktkommunikation haben unterschiedliche Quellen. Der Gesetzgeber ändert das EnWG oder das MsbG, etwa mit neuen Vorgaben zum Lieferantenwechsel oder zum Messwesen. Die Bundesnetzagentur setzt diese Vorgaben über Festlegungen um, etwa in GPKE, WiM und MaBiS. Dazu kommen technische Neuerungen, die neue Prozesse erfordern.

Die Prozessfestlegungen werden auf den Seiten der Beschlusskammer 6 veröffentlicht. Dort stehen die aktuell gültige Fassung, die Historie und die laufenden Verfahren. Ein Beispiel ist die GPKE, die mit den Festlegungen BK6-22-024 und BK6-24-174 zum 6. Juni 2025 neu verfügt wurde. GPKE

Zu den Prozessfassungen kommen die Formate. Überarbeitete Nachrichtentypversionen veröffentlicht EDI@Energy, die Bundesnetzagentur begleitet sie mit Mitteilungen zu den Datenformaten. EDI@Energy Ein Release entsteht also aus dem Zusammenspiel von Festlegung, Mitteilung und Formatdokument. Wer nur eine der Quellen beobachtet, verpasst Teile der Änderung.

Der Rhythmus der Umsetzungstermine

Die Marktpartner setzen Änderungen zu festen Terminen um. Der übliche Rhythmus sieht Umsetzungstermine zum 1. April und zum 1. Oktober vor. Davor konsultiert die Bundesnetzagentur die neuen Nachrichtentypversionen, danach erklärt sie ihr Inkrafttreten. Datenformate-Mitteilungen

Ein Blick in die Mitteilungen zeigt den Ablauf. Für einen Umsetzungstermin 1. Oktober 2026 veröffentlichte die Bundesnetzagentur im Februar 2026 die Konsultation und im April 2026 das Inkrafttreten der überarbeiteten Nachrichtentypversionen. Für den Termin 1. April 2027 startete die Konsultation im Juli 2026. Datenformate-Mitteilungen

Neben dem halbjährlichen Rhythmus gibt es außerordentliche Termine. Der Lieferantenwechsel in 24 Stunden wurde mit dem 6. Juni 2025 zu einem Sondertermin umgesetzt, der ursprünglich für April 2025 geplant war. Solche Termine entstehen, wenn Gesetz oder Markt eine schnellere Umsetzung verlangen. Für die Planung bedeutet das: Der Rhythmus ist die Regel, aber nicht die Garantie.

Wer den Rhythmus kennt, kann seine Ressourcen planen. Die Arbeit an einem Release beginnt Monate vor dem Termin, nicht am Termin selbst. Zwischen Konsultation und Inkrafttreten liegt genug Zeit für Analyse und Tests, wenn das Team sie nutzt. Ein Releasekalender, der die erwarteten Termine und die Konsultationsphasen zeigt, gibt dem Unternehmen den Überblick über das Jahr.

Die Betroffenheitsanalyse

Vor jeder Umsetzung steht die Frage: Was ändert sich für unser Unternehmen? Die Betroffenheitsanalyse beantwortet diese Frage systematisch. Sie beginnt bei den Prozessen: Welche Use-Cases ändern sich, welche kommen neu, welche entfallen? Danach folgen die Rollen: In welcher Rolle handelt unser Unternehmen in den betroffenen Prozessen?

Anschließend prüft das Team die Nachrichten. Welche Nachrichtentypen ändern sich, welche Felder kommen hinzu, welche entfallen? Welche Prüfidentifikatoren gelten neu? Dazu kommen die Fristen: Verschieben sich Zeitpunkte, ändern sich Werktagsregeln? Am Ende steht eine Liste der betroffenen Objekte, Prozesse und Systeme.

Die Betroffenheitsanalyse ist die Grundlage für alles Weitere. Aus ihr entstehen die Arbeitspakete für Customizing, Mapping und Tests. Sie schützt vor Überraschungen, weil sie die Änderung vollständig erfasst. Wer die Analyse überspringt, arbeitet an einer unvollständigen Liste und entdeckt die Lücken erst im Test.

Die Analyse sollte dokumentiert und nachvollziehbar sein. Für jede Änderung hält das Team fest, welche Quelle sie hat, welche Prozesse betroffen sind und welche Systeme angepasst werden müssen. Diese Dokumentation dient später als Grundlage für Tests und für die Kommunikation mit dem Fachbereich. Sie ist zugleich der Nachweis, dass das Unternehmen die Änderung verstanden hat.

Umsetzung in den Systemen

Die Umsetzung in SAP-IS-U-Systemen betrifft mehrere Bausteine. Der Datenaustausch muss die neuen Nachrichtenversionen verarbeiten, die Stammdaten die neuen Felder aufnehmen, die Prozesse die neuen Fristen und Prüfungen abbilden. Der Intercompany Data Exchange für den deutschen Markt bündelt viele dieser Funktionen. SAP Intercompany Data Exchange

Die Reihenfolge der Arbeiten folgt der Fachlichkeit. Zuerst wird das Customizing angepasst, dann das Mapping, dann die Prozesslogik. Zuletzt folgen die Tests. Wer das Mapping vor der Prozessanalyse ändert, arbeitet ohne Zielbild. Wer die Prozesse nicht testet, weiß nicht, ob die Änderung im Zusammenspiel funktioniert.

Ein wichtiger Punkt ist die Versionierung. Systeme müssen wissen, welche Formatversion sie zu welchem Zeitpunkt verwenden. Bei einem Umsetzungstermin wechseln alle Marktpartner zum selben Stichtag auf den neuen Stand. Eine saubere Versionierung verhindert, dass Alt und Neu vermischt werden und Nachrichten am Stichtag scheitern.

Zur Versionierung gehört auch der Umgang mit Altbeständen. Nachrichten, die vor dem Umsetzungstermin erstellt wurden, können nach dem Termin noch eintreffen. Das System muss solche Altfälle erkennen und nach der alten oder der neuen Logik behandeln, je nachdem, was der Prozess verlangt. Wer diese Übergänge nicht plant, verliert am Stichtag Vorgänge, die bereits unterwegs sind.

Testen gegen den neuen Stand

Der Test ist die Qualitätskontrolle des Releases. Er prüft, ob die Systeme die neuen Prozesse, Formate und Fristen korrekt umsetzen. Dafür braucht das Team Testfälle, die aus den Änderungen abgeleitet sind. Jede neue Nachrichtenversion, jeder neue Prüfidentifikator und jede geänderte Frist gehört in die Testliste.

Die Tests decken beide Richtungen ab. Ausgehende Nachrichten werden gegen die neuen Vorgaben erzeugt und geprüft. Eingehende Nachrichten werden mit den erwarteten Inhalten simuliert und verarbeitet. Dazu kommen Fehlerfälle: Wie verhält sich das System bei abgelehnten Nachrichten, bei fehlenden Feldern, bei Fristüberschreitungen?

Für die Praxis lohnt der Austausch mit den Marktpartnern. Viele Fehler zeigen sich erst im Zusammenspiel, etwa wenn zwei Systeme unterschiedliche Versionen verwenden. Wer früh mit den wichtigsten Partnern testet, findet diese Fehler vor dem Umsetzungstermin. Wer allein testet, riskiert, dass der erste echte Austausch scheitert.

Auch die Regression gehört in den Test. Ein Release ändert nicht nur das Neue, es kann auch Bestehendes brechen. Wer nach der Umsetzung nur die neuen Fälle prüft, übersieht, dass ein verändertes Feld einen laufenden Prozess stört. Ein Regressionspaket mit den wichtigsten Standardfällen schützt vor solchen Rückschlägen.

Bedeutung für SAP IS-U

Release-Management für die Marktkommunikation ist in SAP-IS-U-Projekten eine Daueraufgabe. Zwei- bis dreimal im Jahr kommen neue Vorgaben, die Systeme, Stammdaten und Prozesse berühren. Wer diese Aufgabe nicht organisiert, arbeitet permanent im Krisenmodus.

Eine belastbare Organisation umfasst mehrere Elemente: einen Releasekalender mit den Umsetzungsterminen, eine Betroffenheitsanalyse je Release, ein Testkonzept und einen Verantwortlichen für die Koordination. Dazu kommen die Pflege der Formatversionen und die Schulung der Fachbereiche. Ohne diese Elemente bleibt die Umsetzung dem Zufall überlassen.

Die SAP-Dokumentation beschreibt die Funktionen des Datenaustauschs, die konkrete Umsetzung bleibt aber fachlich getrieben. Wer die Funktionen kennt, aber die Prozesse nicht, kann Releases technisch einspielen, ohne die fachlichen Anforderungen zu erfüllen. Umgekehrt gilt: Wer die Prozesse kennt, aber die Systeme nicht, kann die Anforderungen nicht umsetzen. Release-Management verbindet beide Seiten.

Praxisbeispiel: Ein Release zum 1. Oktober

Ein Versorger plant ein Release zum 1. Oktober. Die Betroffenheitsanalyse zeigt: Ein neuer Prüfidentifikator für eine Stammdatenänderung kommt hinzu, ein bestehendes Feld wird Pflicht. Das Team erstellt die Arbeitspakete für Customizing und Mapping.

Im August beginnen die Tests. Das Team erzeugt die neuen Nachrichten, simuliert die eingehenden Fälle und prüft die Fristen. Im September stimmt es sich mit den wichtigsten Marktpartnern ab. Zum 1. Oktober wechselt das System auf den neuen Stand. Eine Nachbereitungswoche prüft die ersten produktiven Nachrichten und gleicht Auffälligkeiten ab.

Das Beispiel zeigt den Wert der Vorbereitung. Wer den Zyklus kennt und früh plant, hat am Umsetzungstermin ein System, das den neuen Stand beherrscht. Wer den Zyklus ignoriert, erlebt am Stichtag den ersten produktiven Fehlschlag.

Nach dem Release gehört die Beobachtung in den Alltag. Die Fachbereiche achten in den ersten Tagen auf Auffälligkeiten bei den eingehenden und ausgehenden Nachrichten. Werden Ablehnungen häufiger, liegt oft ein Detailfehler im Mapping vor. Ein kurzer Nachbereitungszeitraum mit täglicher Sicht auf die Fehlerquoten verhindert, dass sich ein kleiner Fehler über Wochen fortsetzt.

Am Ende jedes Releases lohnt eine kurze Auswertung. Was lief gut, was hat Zeit gekostet, wo traten Fehler auf? Diese Erkenntnisse fließen in den nächsten Release-Zyklus ein und verbessern die Planung. Unternehmen, die diesen Kreislauf etablieren, werden mit jedem Release schneller und sicherer.

Typische Missverständnisse

„Release-Management ist eine IT-Aufgabe.“
Nein. Es beginnt mit der fachlichen Betroffenheitsanalyse. Die IT setzt die fachlichen Vorgaben um.

„Änderungen kommen nur zum 1. April und 1. Oktober.“
Das ist der übliche Rhythmus. Außerordentliche Termine wie der 6. Juni 2025 sind möglich.

„Die Datenformate-Mitteilungen genügen als Informationsquelle.“
Sie sind wichtig, aber nicht alles. Prozessfestlegungen, AHB und die Konsultationen gehören ebenso dazu.

„Ein Release ist nur ein Mapping-Update.“
Nein. Releases ändern Prozesse, Fristen, Formate und Stammdaten. Mapping ist nur ein Teil.

„Nach dem Umsetzungstermin ist das Release erledigt.“
Nein. Die Nachbereitung prüft die ersten produktiven Nachrichten und behebt Auffälligkeiten. Ein Release endet erst, wenn der Betrieb stabil läuft.

Quellen und Pflegehinweis

Die Umsetzungstermine und Formate veröffentlicht die Bundesnetzagentur in den Mitteilungen zu den Datenformaten, die Prozessfassungen auf den Seiten zu GPKE, WiM und MaBiS. EDI@Energy liefert die Formatdokumente. Für jedes Release die zum Stichtag gültigen Fassungen prüfen und einen eigenen Releasekalender führen.

• Bundesnetzagentur: Gemeinsame Mitteilungen zu Datenformaten
• Bundesnetzagentur: Lieferantenwechsel (GPKE)
• Bundesnetzagentur: Wechselprozesse im Messwesen (WiM Strom)
• EDI@Energy: Datenformate für die Marktkommunikation
• BDEW: Marktkommunikation, Standards im Energiemarkt
• SAP Help: SAP Intercompany Data Exchange for German Electric Utilities

Abrufdatum aller Quellen: 7. September 2026.