Lösungspräsentation, Stand Januar 2017

Transkript

1 Anpassungsbedarfe des SAP IS-U Stammdatenmodells an die Erfordernisse des Gesetzes zur Digitalisierung der Energiewende Beschluss BNetzA, BK / BK vom Sicht Lieferant Lösungspräsentation, Stand Januar 2017

2 Die getroffenen Regelungen werden überwiegend zum als sogenanntes Interimsmodell wirksam Wesentliche Eckpunkte der Beschlüsse der Bundesnetzagentur Angepasste Geschäftsprozessbeschreibungen für GPKE, GeLi Gas und WiM Anpassung und Erweiterung der Marktprozesse für Einspeisestellen Strom (MPES), Veränderungsmeldungen mittels standardisiertem Excel-Formular Flächendeckende Einführung von Marktlokations-IDs als eigenständige Identifikationsnummer, spätestens zum , durch den Netzbetreiber Die Übermittlung sämtlicher EDIFACT-Nachrichten zur Marktkommunikation ist spätestens ab dem mittels Signatur und Verschlüsselung abzusichern Umfangreiche Prozess- und Systemanpassungen zum erfordern einen sofortigen Projektstart Entwicklung einer einheitlichen Geschäftsprozessbeschreibung zur Ermöglichung von Lieferantenwechsel für Haushaltskunden innerhalb von Kundenanlagen zum

3 Neue Begrifflichkeiten werden auf Basis des Rollenmodell für die Marktkommunikation im deutschen Energiemarkt eingeführt Die Marktlokation Bezeichnung Marktlokation ersetzt den bislang in der GPKE verwendeten Begriff der Entnahmestelle. Marktlokation ist jener Punkt, an dem Energie erzeugt und verbraucht wird und der Gegenstand von Lieferantenwechsel- bzw. Bilanzierungsprozessen ist. Die Marktlokation ist mit mindestens einer Leitung mit einem Netz verbunden. Das Verständnis der Marktlokation ist ein kaufmännisch-bilanzielles Die Messlokation(en) Die an einer Marktlokation entnommene Energie wird mittels einer oder mehrerer Messeinrichtungen ermittelt, die ihrerseits unter dem Begriff der Messlokation geführt werden. Eine Messlokation ist eine Lokation, an der Energie gemessen wird und die alle technischen Einrichtungen beinhaltet, die zur Ermittlung und ggf. Übermittlung der Messwerte erforderlich sind. In einer Messlokation wird jede relevante physikalische Größe zu einem Zeitpunkt maximal einmal ermittelt. Sowohl die Markt- als auch die Messlokation werden durch eine eindeutige ID identifiziert. Dazu ist, um eine eindeutige Zuordnung einer ID zu einer Markt- oder Messlokation zu gewährleisten und um Verwechslungen zu vermeiden, eine neue ID für Marktlokationen einzuführen 3

4 An der Marktlokation wird Energie erzeugt und verbraucht. Sie ist Gegenstand von Lieferantenwechsel- bzw. Bilanzierungsprozessen Die Marktlokation Netzgebiet Messlokation 1 Marktlokation A Flächendeckende Einführung von Marktlokations-IDs als eigenständige Identifikationsnummer, spätestens zum die Marktlokations-ID darf nicht mit der der Identifikation-ID für die Messlokationen identisch sein die Generierung und Ausgabe der Marktlokations-IDs erfolgt durch eine zentrale bundesweite Stelle (Codevergabestelle) Netzgebiet Messlokation 1 Marktlokation A Zuweisung erfolgt durch die Betreiber von Elektrizitätsversorgungsnetzen und betroffene Marktteilnehmer sind unverzüglich zu informieren Die ID identifiziert die jeweilige Marktlokation nach ihrer erstmaligen Zuordnung dauerhaft. Messlokation 2 Die Marktlokations-ID ist mit einer Prüfziffer ausgestattet, anhand derer überprüft werden kann, ob eine ID korrekt übermittelt worden ist 4

5 Die getroffenen Regelungen werden überwiegend zum als sogenanntes Interimsmodell wirksam Transformation zum neuen Stammdatenmodell Sicht Lieferant SLP Profil Vertrag Anlage Aktuell * Neues Datenmodell * Zählpunkt Zählwerk Geräteinfosatz RLM Profil SLP Profil Vertrag Anlage Marktlokation Zählwerk Geräteinfosatz Messlokation RLM Profil Aktivitäten Splittung des Zählpunktes in Markt- und Messlokation(en) führt zur Vergabe einer neuen Marktlokations-ID Zählpunkt-ID (MeteringCode) geht auf die Messlokation über und ist für den Lieferanten nicht weiter von Bedeutung Marktlokation erhält neue eigenständige ID Verknüpfung zw. Markt- und Messlokation wird in der Marktrolle Lieferant vermutlich informativ für die Prozessabwicklung im elektronischen Datenaustausch benötigt Veränderung von Zählpunkt-ID auf Marktlokations-ID muss vollhistorische erfolgen Geschäftspartner Vertragskonto Verbrauchsstelle Anschlussobjekt Geschäftspartner Vertragskonto Verbrauchsstelle Anschlussobjekt Neu *SAP IS-U Datenmodell, vereinfachte Darstellung 5

6 Transformationsvorgehen Marktrolle Lieferant 6

7 Zur Sicherstellung der effizienten Prozessbearbeitung ist eine vollständige historische Datenmodell-Transformation erforderlich Anforderungen an das Transformationsvorgehen Transformation der Datenkonstrukte bis spätestens zum Entscheidung zum Stichtag oder zur Zeitraumbasierten Umstellung obliegt dem jeweiligen Netzbetreiber Vollständige historische Datenmodelltransformation ist somit eventgesteuert erforderlich Information über die Transformation / Veränderung der Zählpunkt-ID zur Marktlokations-ID wird durch den jeweiligen Netzbetreiber initiiert (separater Datenaustauschprozess) Tabellenorientiertes Transformationsverfahren mit Berücksichtigung laufender Prozesse Transformation über Systemgrenzen hinweg (SAP IS-U, CRM, BW, EAI-Konverter, nonsap-systeme) Automatisierte (Massen-) Datenmodellprüfungen (Konsistenzprüfungen, Prozessprüfungen) Dokumentation und Reporting Erfüllen von Nachweispflichten 7

8 Die fachlichen und technischen Herausforderungen sind vielfältig und führen zu einer komplexen Datentransformation Einige der aktuell bekannten Herausforderungen Ereignisgesteuerte Transformation Historische Tiefe Datenumfang Laufende Prozesse Rand-/Umsysteme Nachweispflicht Erergnisgesteuerte Datenmodell-Anpassung Änderungsbedarfe werden durch Netzbetreiber kommuniziert und sind ereignisgesteuert zu transformieren Komplexe Stammdatenmodelle Vollhistorische Datenmodell-Transformation Transformationsregeln je Zieldatenmodell sind zu definieren und vollhistorische Datenmodelltransformation (tabellenbasiert) ist durchzuführen Datenumfang Hochperformance Datentransformation die vollständig konsistente Datenmodellumstellung erfordert ein hoch performantes Transformationsverfahren ohne System-Downtime Historische Tiefe Datentransformation für aktive Prozesse Die Datentransformation muss im laufenden Betrieb (aktive Prozesse) erfolgen. Die Prozesse müssen in ihrem aktuellen Status weiter prozessiert werden können Laufende Prozesse Transformation über SAP hinaus erforderlich Aktuelle Dateninformationen sind in der gesamten Systemlandschaft verteilt. Datentransformation und Datenbereitstellung für Umsysteme ist sicherzustellen Rand-/Umsysteme Transparenter Nachweis auch für Wirtschaftsprüfer Vollständige Datenmodellumstellung erfordert umfangreiche Nachweise (Stammdatenkonsistenz, Transformationsreporting, Revisionssicherheit) Nachweispflicht 8

9 Die fachlichen und technischen Herausforderungen sind vielfältig und führen zu einer komplexen Datentransformation Transformationsvorgehen SMART MOVE powered by DCS Ganzheitliche Datenmodell-Transformation Identifikation (Datenumfang) (Umstellungsumfang) Transformation (ganzheitliche Umstellung) Prüfen (Konsistenz) Protokollierung (Revisionssicherheit)

10 Die fachlichen und technischen Herausforderungen sind vielfältig und führen zu einer komplexen Datentransformation Transformationsvorgehen Identifikation SMART MOVE powered by DCS Ganzheitliche Datenmodell-Transformation Identifikation (Datenumfang) (Umstellungsumfang) Transformation (ganzheitliche Umstellung) Prüfen (Konsistenz) Protokollierung (Revisionssicherheit) Empfang der Änderungsmeldungen des Netzbetreibers mittels Marktkommunikation Informationsverarbeitung mittels File-Upload oder interner SAP Kommunikation (RFC-/WebService-Aufruf) Identifikation der zu ändernden Zählpunkte, ggf. Fehlerliste Paketierung zur terminierten Transformation 10

11 Die fachlichen und technischen Herausforderungen sind vielfältig und führen zu einer komplexen Datentransformation Transformationsvorgehen SMART MOVE powered by DCS Ganzheitliche Datenmodell-Transformation Identifikation (Datenumfang) (Umstellungsumfang) Transformation (ganzheitliche Umstellung) Prüfen (Konsistenz) Protokollierung (Revisionssicherheit) Sperren der Datensätze / Datenobjekte für die Verarbeitung (ENQUEUE / DEQUEUE) der Schlüssel und Tabellenfelder auf Basis vordefiniertem Transformationscustomizing. (Adhoc-DDIC-Scan bei Bedarf möglich) Relevante Objekte: Stammdaten, Bewegungsdaten, kundeneigene Tabellenfelder, Metadaten, Workflowcontainer 11

12 Die fachlichen und technischen Herausforderungen sind vielfältig und führen zu einer komplexen Datentransformation Transformationsvorgehen Transformation SMART MOVE powered by DCS Ganzheitliche Datenmodell-Transformation Identifikation (Datenumfang) (Umstellungsumfang) Transformation (ganzheitliche Umstellung) Prüfen (Konsistenz) Protokollierung (Revisionssicherheit) Vollhistorische Änderung der Zählpunkt-ID auf die neue Marktlokations-ID Relevante Objekte: ext. Zählpunktbezeichnung, Wechselbeleg/PDOC, Datenaustauschaufgaben, Rechnungseingangsdaten, weitere kundeneigene Tabellenfelder, Metadaten, Workflowcontainer Sicherung der Änderung für revisionssichere Prüfung und historische Auskunft 12

13 Die fachlichen und technischen Herausforderungen sind vielfältig und führen zu einer komplexen Datentransformation Transformationsvorgehen Prüfen SMART MOVE powered by DCS Ganzheitliche Datenmodell-Transformation Identifikation (Datenumfang) (Umstellungsumfang) Transformation (ganzheitliche Umstellung) Prüfen (Konsistenz) Protokollierung (Revisionssicherheit) Automatisierte Objektbasierte Stammdatenprüfung Automatisierte BigCheck-Prüfung Automatisierte fachliche Finger-Print-Prüfungen Freigabe der Datensätze für die weitere Bearbeitung oder automatisierter Rollback 13

14 Die fachlichen und technischen Herausforderungen sind vielfältig und führen zu einer komplexen Datentransformation Transformationsvorgehen Protokollierung SMART MOVE powered by DCS Ganzheitliche Datenmodell-Transformation 1 Identifikation (Datenumfang) (Umstellungsumfang) Transformation (ganzheitliche Umstellung) Prüfen (Konsistenz) Protokollierung (Revisionssicherheit) Sicherung der Änderung für revisionssichere Prüfung und historische Auskunft Protokollierung der Umstellungsaktivitäten, je Datenbanktabelle und Datensatz Bereitstellung Anpassungstrigger für Um-/Randsysteme 14

15 Transformationsvorgehen Schematischer Prozessablauf Identifikation (Datenumfang) Änderungsmeldung liegt vor Zählpunkt identifizieren XOR Zählpunkt nicht bekannt Manuelle Prüfung (Umstellungsumfang) Zählpunkt identifiziert Änderungsaufträge sammeln durchführen Regelwerk XOR nicht erfolgreich Manuelle Prüfung Sperrung nicht möglich Zählpunkt typisiert Datensatz für Änderung sperren XOR Transformation (ganzheitliche Umstellung) Sperrung möglich Vollhistorische Transformation durchführen XOR Umstellung nicht erfolgreich Rollback / Manuelle Prüfung Regelwerk Prüfen (Konsistenz) Umstellung erfolgt Konsistenzprüfungen durchführen XOR 15 Protokollierung (Revisionssicherheit) Umstellung erfolgreich Protokollierung durchführen Änderungshistorie schreiben Trigger für Umsysteme erstellen Individuelle Anpassung der Umsysteme

16 NATUVION Data Conversion Server (DCS) als zentraler Bestandteile für die ganzheitliche Datentransformation NATUVION Ganzheitliche Datentransformation NATVION Data Conversion Server (ohne Lizenzkosten) Freie Datenselektion und schlüsselorientierte Vollhistorische Datenmodell-Transformation Schlüsselbasiert Tabellenorientiert Komplexe Mappingund Transformationsregeln Virtuelles Umstellungsszenario Höchste Performance und technisches Monitoring Durchgängiges, wirtschaftsprüferkonformes Reporting Automatisiertes Testen und Stammdatenprüfungen PODSERVICE UI (Zählpunkt) ACCOUNT CONTRACT PREMISE CONNOBJ INSTLN DEVICEMOD NBSERVICE DEVICERATE MOVE_IN DEVLOC PARTNER MOVE_OUT Weitere BIGCHECK 16 Erfüllung der Datenschutzanforderungen im Projekt

17 Komplexes Umsetzungsszenario fordert integrative Prozess- und Systemanpassungen Indikative Zeitplanung Tätigkeit Rahmentermine Prozessanpassungen GPKE / GeLi / WiM Anpassung MaKo Start Interimsmodell MaLo-ID eingeführt Initiierung Detailkonzept Projektsetup Installation AddOn Indiv. Erweiterung Testphasen Produktivsetzung Individualtests Integrationstests GoLive Produktivbegleitung Laufende Transformation Meilensteine Projektteam ist arbeitsfähig Detailkonzept erstellt Entwicklungen abgeschlossen Testzyklus I abgeschlossen Testzyklus II abgeschlossen GoLive Datentransformation abgeschlossen 17

18 Für weitere Fragen stehen gerne zur Verfügung Holger Strotmann Geschäftsführer Fon: Mail: Natuvion GmbH Altrottstraße Walldorf Fon Fax Patric Dahse Geschäftsführer Fon: Mail: Natuvion GmbH Altrottstraße Walldorf Fon Fax