Es vergeht kein Tag, an dem ich nicht die Worte "S/4HANA-Roadmap" höre. Es scheint, dass viele Unternehmen entweder einige Teile ihres Bestands auf S/4HANA umgestellt haben oder aktiv ihre nächsten Schritte ana...
Paul Hammersley ist bereits seit vielen Jahren bei EPI-USE Labs tätig. Als Vice President der ALM-Produkte umfasst sein Portfolio auch die Systemlandschaftsoptimierung. Seine praktische Erfahrung bei der Implementierung des Data Sync Managers sowie seine Unterstützung für Kunden, bei der Datenverwaltung der gesamten SAP Landschaft ist einzigartig. Er verfügt über tiefe Kenntnisse in den Bereichen Datensicherheit, einschließlich der Datenschutzgrundverordnung.
Im ersten Teil habe ich über Release-Zyklen, deren Abstimmung und das Zusammenspiel zwischen einer S/4HANA Landschaft mit den unterschiedlichen Cloudlösungen geschrieben.
Das ist zwar alles schön und gut, aber wie sieht es mit dem Mechanismus zur Kontrolle von Änderungen in der Landschaft aus? Welche Möglichkeiten gibt es für die Bereitstellung von Daten, die repräsentativ für die Produktion sind, wenn die Änderung eintritt? In S/4HANA haben wir dieselben Möglichkeiten, die es schon immer gab, sowohl im SAP-Standard als auch bei anderen Anbietern. Für das SAP-Transportmanagementsystem und Mandanten- bzw. Systemkopien gibt es jeweils Alternativen von anderen Anbietern, entweder in ABAP oder damit integriert.
Aber was ist mit reinen Cloud-Lösungen? Bieten sie dieselben Möglichkeiten? Das möchte in diesem Blog am Beispiel C/4HANA klären.
Zunächst müssen wir genau definieren, was C/4HANA ist.
Dieser ausgezeichnete Blog-Beitrag von Gavin Mooney erklärt die Namen und Ursprünge der fünf Lösungen, aus denen C/4HANA besteht: SAP Customer Data Cloud (auf Basis von Gigya), SAP Marketing Cloud (zuvor Hybris Marketing Cloud), SAP Commerce Cloud (Hybris Commerce Cloud), SAP Sales Cloud (Kombination aus SAP Hybris Cloud for Sales, SAP Subscription Billing und CallidusCloud), SAP Service Cloud (Hybris Cloud for Service, SAP Customer Engagement Center und andere).
Die letzten beiden sind das, was SAP vorher im Paket als C4C angeboten hat. Erwähnenswert ist auch, dass nur die letzten beiden (SAP Sales Cloud und SAP Service Cloud) nicht (On-Premise) verfügbar sind.
Angesichts der Vielzahl an Lösungen verwundert es nicht, dass wir zwischen verschiedenen Gruppen unterscheiden müssen:
SAP Sales und Service Cloud
Das Service Control Workcenter bietet zwei Möglichkeiten. Mit der ersten, „Lösungsprofil kopieren“, lassen sich alle Business Configurations von einem Quell- zu einem Ziel-Tenant kopieren. Das wird typischerweise am Anfang eines C/4HANA-Projekts durchgeführt, um eine Testumgebung zu erhalten. Viele Tätigkeiten im Verlauf einer C/4HANA-Implementierung sind nicht im Business Configuration Work Center enthalten und mussten bisher in jedem Tenant manuell wiederholt werden. Diese Tätigkeiten sind nun durch die zweite Funktion abgedeckt, das Transportmanagement. An den Namenskonventionen ist recht klar zu erkennen, woher die Idee stammt. Transportwege werden angelegt, woraufhin Transportanfragen für Anpassungsänderungen, Geschäftsrollen, Sprachanpassungen, lokale Formularvorlagen und Mashups erstellt werden können.
SAP Customer Data Cloud
Die Gigya-Konsole bietet die Möglichkeit, eine Konfiguration zu kopieren, aber dies wird üblicherweise zwischen zwei Produktionsseiten („Seiten“ ist der statt „Tenant“ verwendete Begriff) verwendet. Die Customer Data Cloud ist eher eine Blackbox. Entwickelt wird außerhalb der Lösung auf anderen Plattformen, die APIs zur Integration mit ihr nutzen. Ein Konzept wie Testsysteme und Change-Management gibt es somit einfach nicht. Weitere Informationen finden Sie hier.
SAP Marketing Cloud
Im SAP Help Portal für die SAP Marketing Cloud gibt es einen Solution Lifecycle Overview, der erklärt, wie eine Zwei-System-Landschaft üblicherweise verwendet wird. Ein Qualitätssystem erhält alle Daten und wird konfiguriert, bevor es für den Go-Live in die Produktion kopiert wird. Die Segmentations- und Zielgruppenkonfiguration sowie die Erweiterungsobjekte (benutzerdefinierte Felder, benutzerdefinierte Logik etc.) müssen nach wie vor manuell mit der App „Manage your solution“ in die Produktion importiert werden. Auch laufende Änderungen daran, werden nach dem Go-Live so gehandhabt. Alle anderen Konfigurationsänderungen werden im Qualitätssystem durchgeführt und dann durch Anlegen eines Tickets für Serviceanfragen in der App „Manage your solution“ transportiert. Wenn diese Anfrage bearbeitet wird, werden nicht einzelne Änderungen aus der Qualität in die Produktion übertragen, sondern die gesamte Konfiguration.
SAP Commerce Cloud
Die Public-Cloud-Edition von SAP Commerce läuft in Azure unter Einsatz von Kubernetes und der SAP Cloud Platform.
Erweiterungen werden für zusätzliche Funktionen verwendet, wovon bestimmte von SAP geliefert oder eigens erstellt werden können. Ein Erweiterungsgenerator mit dem Namen extgen erstellt neue Erweiterungen mit denen Sie auf der Grundlage von Vorlagen arbeiten können. Die Konfiguration wird mit Code ausgeführt, und empfohlen wird eine kontinuierliche Bereitstellung / Integration unter der Verwendung von Code aus einem Git-Repository. Das Erstellen und Bereitstellen von Paketen kann mit APIs und Tools von Drittanbietern automatisiert werden. Weitere Informationen zur Architektur der SAP Commerce Cloud finden Sie in diesem Artikel.
Die zunehmende Anzahl an Plattformen bedeutet auch, dass die Möglichkeiten zur Bereitstellung von Testdaten stark unterschiedlich sind. Die SAP Sales Cloud und SAP Service Cloud haben beide ein „Tenant Refresh“-Verfahren, mit dem eine Kopie des gesamten Systems und der Daten entweder von der Produktion zum Test oder von einem Test-Tenant zum Anderen beantragt werden kann. Der Prozess wird durch Protokollieren eines Vorfalls innerhalb der Lösung verwaltet. SAP-Hinweis 2751824 enthält weitere Einzelheiten.
Der SAP Customer Data Cloud fehlt das Konzept von Testinstanzen oder Tenants. Die Konfiguration wird nur außerhalb der Lösung zum Aufruf der von ihr bereitgestellten APIs ausgeführt.
Die SAP Marketing Cloud hat eine Zwei-Schichten-Architektur, und alle im Testsystem vorgenommenen Konfigurationen werden bei jeder Bereitstellung in die Produktion übernommen. Die Daten in der Testumgebung werden entsprechenden Testsystemen entnommen, z. B. S/4HANA-Entwicklungs-/Test-Mandanten. Mehrere Segmentierungsprofile können dafür verwendet werden, Daten aus mehr als einem S/4HANA-Entwicklungs-/Testsystem in die SAP Marketing Cloud zu übernehmen. Das bedeutet, dass der Test-Mandant nicht aus der Produktion aktualisiert werden muss, aber man ist von der Qualität guter Testdaten in der Testumgebung des verbundenen Systems abhängig.
Erfahren Sie wie Data Sync Manager™ (DSM) Suite, zu einer smarten und effizienten S/4HANA Migration helfen kann.
© 2023 EPI-USE Berlin GmbH, Friedrichstraße 95, 10117 Berlin
© 2023 EPI-USE GmbH, Sophie-Scholl-Platz 8, 63452 Hanau
© 2023 EPI-USE Labs GmbH, Altrottstraße 31, 69190 Walldorf
Einen Kommentar schreiben