SAP for Utilities Blogs
Discover insights and practical tips to optimize operations, reduce costs, and deliver reliable energy with SAP technology. Contribute your own blog post!
cancel
Showing results for 
Search instead for 
Did you mean: 
Gerald_G
Product and Topic Expert
Product and Topic Expert

this Blog-Post is outdated // dieser Beitrag ist nicht mehr up-to-date !


SAP goes Cloud doch was ist eine Hybride Architektur?


SAP befindet sich auf dem Weg in die Cloud. Das ist die große "Überschrift", die generelle Direktive. Diese generelle Ausrichtung klar zu kommunizieren ist der einzig richtige Ansatz. Auf der strategischen Ebene gibt es keine andere zulässige Interpretation: Cloud first!

Gleichzeitig wissen wir alle gemeinsam (Kunden, Partner und SAP), dass es – insbesondere – in der Utilities Industrie eine sehr große Anzahl an Energieversorgungsunternehmen gibt, die für die eigene Transformation ihrer ERP-Landschaften einen Sprung machen müssen von einer SAP-ECC-basierten Landschaft zu einer Landschaft basierend auf SAP S/4HANA. Nun ist die im SAP ECC seit Jahrzehnten genutzte Industrie-Lösung (gern einfach als IS-U bezeichnet) künftig als SAP S/4HANA Utilities firmierend nur in den Auslieferungsversionen „on premise“ oder „private cloud“ erhältlich, also selbst im eigenen Rechenzentrum betriebenen, oder einer Private-Cloud-Edition, also einer zwar von SAP gehosteten aber von Kunden betriebenen Auslieferungsform[i].

Bezogen auf die insbesondere in Deutschland[ii] benötigten Funktionalitäten rund um das Regularium der deutschen Marktkommunikation ist allerdings eine alleinige Verwendung von SAP S/4HANA Utilities ohne gleichzeitig auf die neue von SAP betriebene SAP Cloud for Market Communication zu setzen, schlicht ziemlich sinnfrei.

Die SAP Cloud for Market Communication folgt dem Paradigma der Trennung von Markt- und Geschäftsprozessen. Das heißt, jene Prozessteile, die durch den Regulator bestimmt sind, werden als Marktprozess in der Public-Cloud-Lösung SAP Cloud for Market Communication abgewickelt während die Geschäftsprozesse im unternehmenseigenen Backend verbleiben. Das SAP S/4HANA Utilities fungiert folgerichtig in diesem Kontext als wesentlicher Teil des unternehmenseigenen Backends. (Man sollte aber im Zusammenhang mit der SAP Cloud for Market Communication alles außer dieser Lösung als das unternehmenseigene Backend betrachten, das erleichtert das Verständnis.)

Das ist der grundlegende Aufbau der Architektur nach der Transformation zu SAP S/4HANA in einem Utility: neben SAP S/4HANA Utilities findet sich mindestens SAP Cloud for Market Communication. Eine Architektur in der es ein SAP S/HANA for Utilities neben einer (oder mehreren) Public-Cloud-Lösung(en) gibt (hier die SAP Cloud for Market Communication), bezeichnen wir als hybride Architektur.

Wir stellen also fest, es wird wohl konsequenterweise keine kundenseitig betriebene, reine OnPrem-Architektur mehr möglich sein, da das SAP S/4HANA Utilities nur gemeinsam mit der SAP Cloud for Market Communication sinnvoll einsetzbar ist.









Ok, mindestens Hybrid – und jetzt?


Ja, was jetzt? Was fangen wir mit dieser Erkenntnis an, und welche Rolle spielt SAP Cloud for Utilities, flexible edition in diesem Kontext.

Wenn denn in der künftigen Architektur, die immer eine hybride ist, mindestens SAP S/4HANA Utilities gemeinsam mit der SAP Cloud for Market Communication zum Einsatz kommt wozu sollte man dann noch etwas benötigen wie die SAP Cloud for Utilities, flexible edition.

Lassen wir unseren Gedanken mal freien Lauf. Mir fallen dazu ein paar Fragen ein.

Welche Lösungen werden denn für den Kundenservice eingesetzt? Welche für das Marketing? Welche Webshops kommen zum Einsatz? Die Liste solcher Art Fragen kann schier unendlich werden. Planen Sie überhaupt Marketing in großem Stil zu betreiben? Oder setzen Sie einfach weiter auf Ihre Bekanntheit und können auf ausgefeilte Marketing-Kampagnen, die ohnehin heutzutage eher auf digitalen Wegen vor sich gehen und das mit der Digitalen Welt ist eh nicht so Ihr Ding?

Ich provoziere, ich weiß! Und ich habe natürlich keine allumfassende Antwort. Aber ein wenig können wir uns die Dinge zusammenreimen, einiges wissen wir aus unseren Marktbeobachtungen auch ganz sicher.

Wir gehen in unseren Anstrengungen für die Unterstützung der hybriden Architektur, die auf die Marktrolle des Energy Retailers (in der deutschen Analogie ist das ein Energie-Lieferant) ausgerichtet ist, davon aus, dass mindestens[iii] immer ein Webshop eine Rolle spielt. Im Jahr 2019 war und bis heute ist es schlicht nicht denkbar, dass ein modernes Energieversorgungsunternehmen ohne einen Internet-Auftritt mit integriertem Webshop existiert.

Und das hat eine logisch ableitbare Konsequenz, die ein klein wenig revolutionär anmutet auch wenn dieses Pathos vielleicht übertrieben wirkt. Weg vom Pathos, hin zur Realität:

  • Der Geschäftsprozess des Verkaufs von Produkten des modernen Energieversorgers beginnt im Webshop. Und das ist nicht das SAP S/4HANA Utilities.

  • Der Geschäftsprozess Verkauf von Produkten des modernen Energieversorgers endet im SAP S/4HANA Utilities in dem dort ein uns allen sehr bekannter Folge-Prozess wiederkehrend, manchmal über Jahre, ausgeführt wird: Meter-to-Cash

  • Wir bezeichnen den Prozess vom Verkauf im Webshop bis zum Beginn des Meter-to-Cash systemagnostisch als Order-to-Fulfillment


Und um Order-to-Fulfillment für das hybride Szenario kümmert sich SAP Cloud for Utilities, flexible edition.

 

this Blog-Post is outdated // dieser Beitrag ist nicht mehr up-to-date !


SAP Cloud for Utilities, flexible edition - Outdated


Die SAP Cloud for Utilities, flexible edition adressiert mit Order-to-Fulfillment im Kern jene Ende-zu-Ende Prozesse die insbesondere vor dem Hintergrund auch neuer Geschäftsmodelle ihren Ausgangspunkt in eher kundenzentrierten Web-Shops oder Customer-Self-Service-Portalen haben, in ihrem Verlauf spezielle Cloud Lösungen tangieren (müssen), wie zum Beispiel die SAP Cloud for Market Communication und am Ende, wo es ums Geld geht (meter-to-cash) im SAP S/4HANA Utilities ihren Abschluss finden.

Es geht also um Prozesse im Hybriden Szenario, die sich über mehrere, verschiedene Lösungen spannen.

Der systemagnostisch als „Order-to-Fulfillment“ benannte E2E-Prozess zerfällt konkret in verschiedene, nicht mehr system-agnostische Prozesse. Abhängig vom konkreten Typus des Produktes werden verschiedene Lösungen (oder Systeme) orchestriert und sachgerecht standardisierte und möglichst dunkel automatisiert ablaufende Geschäftsprozesse nutzbar gemacht.

Der im SAP API Business Hub abrufbare Content, der seitens SAP Cloud for Utilities, flexible edition ausgeliefert wird, hilft dabei zum Beispiel das Order-to-Fulfillment Szenario vom digitalen Verkaufsprozess (im Webshop) bis zum Meter-to-Cash (im SAP S/4HANA Utilities) zu orchestrieren.

Dies geschieht

  • basierend auf SAP Cloud Platform Integration und SAP Business Transformation Platform und

  • zwischen und über Lösungen hinweg (accross and between underlying solutions)


und integriert im deutschen Markt zusätzlich die hinter dem Vorhang benötigten Marktkommunikationsprozesse.

 

Das Beispiel: Verkauf von Energieverträgen mit SAP Cloud for Utilities, flexible edition


Der Energievertrag ist hier der von uns identifizierte Typ des Produktes. Ein Energieprodukt zu liefern ist nun mal nicht identisch mit der Lieferung eines physikalischen Produktes. Die Abwicklung gestaltet sich notwendigerweise sehr different. Daher die klare Differenzierung nach Produkttypen.

Eine zusätzliche Herausforderung im Prozess-Design ist das zugrundeliegende Marktdesign. Es leuchtet ein: wenn im Rahmen eines Order-to-Fulfill in irgendeiner Weise andere Markpartner aufgrund regulatorischer Regeln einzubinden sind, so ist das in der konkreten Umsetzung des Prozesses zu berücksichtigen.




Die folgende Darstellung zeigt den Prozess-Steckbrief für den Verkauf eines Energieproduktes.


Prozess-Steckbrief "Sales of Commodity products in deregulated markets" (anglehnt an Six Sigma)




Wir gehen global davon aus, dass der Endkunde diesen Prozess in einem Webshop startet, in dem er dort ein entsprechendes Produkt auswählt, in den Warenkorb legt und "kostenpflichtig bestellen" (checkout) klickt. Wir erwarten per definitionem, dass der Warenkorb alle benötigten Daten enthält, neben den Daten zum Kunden und zum Produkt selbst, sind in diesem Fall wegen des Typs des Produktes folgende Daten von großer Wichtigkeit:

  • die Gerätenummer des Zählers (Strom- / Gas-Zähler)

  • optional die Markt-Lokations-ID

  • die Lieferadresse (was die postalische Anschrift der Markt-Lokations-ID darstellt)

  • optional der ehemalige Lieferant


 

Die Notwendigkeit der Erhebung dieser Daten ergibt sich hier im konkreten Fall aus dem durch den deutschen Regulator definierten Modell der Marktkomminkation.

Es ist - leider - nicht zwingend, einen Lieferbeginn mit einer Marktlokations-ID anzumelden, es ist gegewärtig ebenfalls nicht zwingend, dem ehemaligen Lieferanten eine Kündigung zuzusenden. Wenn aber keine Marktlokations-ID im Lieferbeginn angegeben wird, muss die Lieferadresse und die relevante Gerätenummer und der Kunde angegeben werden. Das Energieversorgungsunternehmen wird solche Art Daten im Web Shop erheben, da diese Daten schon heute von belang sind. Diese zwingnde Voraussetzung sollte also ohnehin gegeben sein.

Im Bild sehen wir den groben Ablauf des Prozesses wie er durch SAP Cloud for Utilities, flexible edition vorgesehen ist und in dem auf dem SAP API Business Hub abrufbaren Inhalt enthalten ist.

Genau in dem Punkt, an dem der Warenkorb an den Prozess übergeben wird wird es spannend. Im Bild ist das der Schritt "capture customer order". Dazu ist mit SAP Cloud for Utilities, flexible edition vorgesehen, den Integration Flow "Create Customer Orders in SAP Cloud for Utilities Foundation" mit der Datenstruktur gemäß Customer Order API aufzurufen. Mit diesem Aufruf beginnt der Prozess  "Sales of Commodity ..." zu laufen.


Sales of Commodity in deregulated markets







Im Bild sehen wir den groben Ablauf des Prozesses wie er durch SAP Cloud for Utilities, flexible edition vorgesehen ist und in dem auf dem SAP API Business Hub abrufbaren Inhalt enthalten ist.

Was auffällt ist ganz offensichtlich eine Abkehr von einem vollständig innerhalb SAP S/4HANA Utilities ablaufenden Prozesses. Der wesentliche Teil diese Prozesses läuft hier auf der SAP Business Transformation Platform und der Marktprozess Lieferbeginn[iv] wird hier faktisch hinter dem Vorgang, neudeutsch „backstage“ als Sub-Prozess, abgewickelt.

Die Erzeugung technischer Stammdaten im SAP S/4HANA Utilities basiert, bedingt durch dieses ganz bewusst gewählte Prozessdesign, nicht allein auf den Eingaben des Kunden im Webshop sondern ausschließlich auf den Daten des VNB in seiner Bestätigung des Lieferbeginns. Richtiger können die Daten nicht mehr werden.

Die Erzeugung der kaufmännischen Daten erfolgt ebenfalls spät im Prozess.

Und – dieser Einwurf sei mir gestattet – vielleicht wird damit langsam das Bewusstsein geändert: Was hier stattfindet, sollten wir alle gemeinsam nicht mehr als Einzug bezeichnen. Denn, glauben Sie mir, wenn ich selbst meinen Lieferanten wechsele steht bei mir definitiv kein Möbelwagen vor der Tür, wohl aber passiert im System des neuen Lieferanten genau das, was hier beschrieben wurde.

this Blog-Post is outdated // dieser Beitrag ist nicht mehr up-to-date !


 

Community


Community bedeutet (dem Duden nach) „Gemeinschaft, Gruppe von Menschen, die ein gemeinsames Ziel verfolgen, gemeinsame Interessen pflegen, …“. Mein Interesse richtet sich in jedem Fall auch auf den Austausch, natürlich zum Thema.

Jede Form des Austausches, seien es Fragen, Unsicherheiten, Ideen, Verbesserungsvorschläge, neue Anforderungen … gerne, her damit! Seien Sie offen und konstruktiv,

Ich freue mich auf den Austausch!

Herzlichst

Gerald Galka




 

------------------

[i] Es mag weitere von Partnern betriebene Mischformen geben, das spielt hier aber keine Rolle. Entscheidend für diesen Blog ist vielmehr, dass ein SAP S/4HANA Utilities eben nur in solchen Auslieferungsformen verfügbar ist, bei denen der Betrieb der Lösung durch den Kunden oder Partner erfolgt und eben nicht durch SAP selbst.

[ii] ausgenommen die hier eingebundenen Bilder, die einer Präsentation entnommen sind

[iii] Das ist der kleinste gemeinsame Nenner auf den wir uns bei SAP geeinigt haben. Mehr ist immer möglich, aber irgendwo müssen wir ja anfangen.

[iv] Weiter oben habe ich auf das Paradigma der Trennung von Markt- und Geschäftsprozessen hingewiesen.
2 Comments
Top kudoed authors