Die Architektur von SAP S/4HANA Service beschreiben

Die wichtigsten Prinzipien der Architektur von S/4HANA Service beim Vergleich mit SAP CRM 7.0 lauten wie folgt:

• Harmonisierte Stammdaten:
  • Verwendung des SAP-S/4HANA-Materialstamms, nicht des SAP-CRM-Produkts
  • Verwendung des Geschäftspartnerstammsatzes (Debitorenstammsatzes) für vertriebsbereichsabhängige Daten anstelle von SAP-CRM-spezifischen Tabellen
  • Verwendung von technischen Objekten (z.B. Equipment) anstelle von IObjects
• Engine-Harmonisierung:
  • Verwendung von SAP S/4HANA Sales Pricing anstelle von IPC (SAP CRM 7.0)
  • Verwendung von SAP S/4HANA Sales Billing anstelle von SAP CRM Billing
  • Integration der Configuration Engine Erweiterte Variantenkonfiguration (aus SAP S/4HANA)
• Customizing-Harmonisierung (Verwendung von ursprünglichen SAP-S/4HANA-Tabellen, nicht von SAP-CRM-Spiegeltabellen)
• Keine Verwendung der SAP CRM Middleware für interne Prozesse wie das Anlegen von Folgebelegen oder den Datenaustausch mit externen (SAP- oder Fremd-)Systemen
• UI-Prinzipien:
  • WebClient-UI wird fortgesetzt, SAP-Fiori-Apps sind verfügbar
  • Visuelle Harmonisierung (Belize-Theme)
• Keine veralteten Technologie-Stacks mehr (IPC/VMC, TREX, JAVA-Stack)

Bei der Harmonisierung von Produktstammdaten (Materialstämmen) wird der SAP-CRM-Produktstamm nicht verwendet. Produktkategorien und Hierarchien sind nicht mehr verfügbar. Die einzigen Gruppierungskriterien sind die Warengruppe und die Produkthierarchie (Vertrieb).

Die Settyptechnologie zur Erweiterung des Produktstamms steht nicht mehr zur Verfügung. Alle Verwendungen von APIs für den Produktstamm (SAP_ABA) wurden durch neue APIs in SAP S/4HANA ersetzt. Die zentrale Klasse für den Zugriff ist CL_CRMS4_PRODUCT_API. Die Suche nach Produkten ist weiterhin als WebClient-UI-Suchanwendung verfügbar, verwendet jedoch nun Core-Data-Services-Views (CDS-Views) des SAP-S/4HANA-Materialstamms. Das BOL-Modell bleibt erhalten, wurde jedoch erheblich vereinfacht.

Für Kunden, die mit SAP CRM 7.0 arbeiten, ist ein Migrationspfad von SAP-CRM-Produkten zu SAP-S/4HANA-Materialstämmen für Serviceprodukte verfügbar.

Die Abbildung zeigt mögliche Bezugsobjekte in Servicevorgängen.

Einzelne Objekte (auch IObjects oder einfach Objekte genannt) werden nicht mehr unterstützt, da sie zum SAP_ABA-Produktstamm gehören.

Geschäftspartner: SAP S/4HANA verwendet den Geschäftspartner als Primärobjekt: Die Synchronisation mit (SAP ERP) Debitoren-/Kreditorenstammsätzen erfolgt über die Customer-Vendor-Integration (CVI). Die Pflege von Accounts ist weiterhin über die WebClient-UI-Anwendung möglich. Die SAP-CRM-Datenbanktabellen des Vertriebsbereichs-abhängige Daten (Versand, Fakturierung usw.) werden nicht mehr verwendet. Stattdessen werden die Tabellen aus dem Kundenstamm verwendet (KNV*-Tabellen). Insbesondere werden Partnerrollen keiner Beziehung mehr zugeordnet, sondern auf Vertriebsbereichsebene (Tabelle KNVP) gepflegt.

Die folgenden Funktionen werden nicht mehr unterstützt:

• Gruppenhierarchie
• Marketingattribute
• Marketing-Einwilligungen
• Vorlagen-Framework

Für Organisationsmanagement und Mitarbeiter: Die SAP-GUI-Transaktion PPOMA_CRM funktioniert nicht mehr für die Zuordnung von Mitarbeitern, da der Beziehungstyp 008 für die CP-S-Zuordnung (zentrale Person zu Planstelle) durch den neuen Typ 771 ersetzt wurde. Die Zuordnung muss z.B. über die WebClient-UI-Anwendung erfolgen. Der neue Verknüpfungstyp ermöglicht eine Koexistenz mit dem HR-Organisationsmodell ohne Nebeneffekte wie Überbeschäftigung, indem ein Mitarbeiter zwei Planstellen zugeordnet wird. Mitarbeiter selbst können nur in HCM (Transaktion PA30) gepflegt werden, nicht mehr in der WebClient-UI-Anwendung.

Hinsichtlich Ccustomizing-Harmonisierung: SAP CRM Ccustomizing-Tabellen, die Replikate einer SAP S/4HANA Ccustomizing-Tabelle sind, werden nicht mehr verwendet. Beispiel: Zahlungsbedingungen: CRMC_PMNTTRMS wird durch T052 ersetzt.

In Bezug auf die Preisfindung werden die folgenden Funktionen nicht unterstützt:

• Konditionsausschluss über Ausschlusskennzeichen KZNEP
• Verfolgung kumulierter Werte mit Konditionsupdate
• Datenquellen
• Mengenanpassungen
• Vereinbarte Umrechnungsfaktoren
• Konfigurierbare Parameter und Formeln in der Preisfindung (CPF)
• Commodity-Preisfindung

Informationen zu unterstützten Feldern finden Sie in der folgenden Option im Customizing für C: SAP Customizing Einführungsleitfaden→Service→Grundfunktionen→Preisfindung→Unterstützte preisrelevante Felder anzeigen (Standardauslieferung).

Datenaustausch:

• Dank der harmonisierten Stammdaten und des Customizings in SAP S/4HANA ist keine Replikation von Stammdaten oder Customizing mehr erforderlich.
• In SAP CRM 7.0 wurde die SAP CRM Middleware auch verwendet, um Folgebelege in SAP ERP aus einem SAP-CRM-Vorgang, z.B. einem Kundenauftrag oder einer Bestellanforderung, zu generieren. In SAP S/4HANA Service wird die SAP-CRM-Middleware vollständig aus diesen Prozessen entfernt. Alle Folgebelege werden beim Sichern über einen synchronen Aufruf der entsprechenden APIs angelegt:
  • SD-Kundenauftrag (enthält die Verkaufspositionen eines Serviceauftrags)
  • Innenauftrag (CO)
  • Fakturaanforderung
  • Reservierung, Bestellanforderung, Bestellung (Logistikintegration)
• Das Anstoßen der Folgeprozesse wird über die Systemtabelle CRMS4S_EXCH_FCTR gesteuert. Es gibt eine entsprechende Ccustomizing-Tabelle CRMS4C_EXCH_FCTR, mit der SAP-Kunden ihre eigenen Prozesse integrieren können.

Geschäftsvorgänge (Serviceauftrag, Opportunity, Aktivität usw.) basieren auf dem sogenannten One-Order-Datenmodell, das Ende der 1990er Jahre entwickelt wurde. Dieses Datenmodell ist für analytische Anwendungen aufgrund der Verteilung von Daten über viele Tabellen, GUID-Zeiger und Namens-/Wertetyptabellen sehr nachteilig. Aus diesem Grund wurde mit SAP S/4HANA Service ein Redesign des Datenmodells eingeführt. Das Ziel besteht darin, dass transaktionale und analytische Anwendungen auf derselben primären Persistenz der Daten ausgeführt werden können.

Im Folgenden finden Sie die Grundprinzipien des Datenmodells und seiner Neugestaltung:

• Eine flache Kopf- und Positionstabelle für jede Gruppe von Business-Objekten
• Semantische Schlüssel statt GUIDs
• Komplexe Erweiterungen und Sets:
  • Wichtige Datensätze werden als einzelne Felder in die Kopf-/Positionstabellen extrahiert. Beispiele: Partner: Auftraggeber, Warenempfänger, Ansprechpartner; Status: offen, abgeschlossen, fakturiert; Termine: gültig ab, gültig bis.
  • Alle Datensätze werden in einer separaten Tabelle aufbewahrt, aber die Schlüsselstruktur wird vereinfacht, um direkte JOINs zu ermöglichen (Vermeidung des Link-Handlers).
• Wiederholung von Kopffeldern auf Positionsebene
• Auftrags-APIs bleiben stabil (auch die untergeordneten APIs).
• Erweiterte Suchen, interaktive Berichte, Enterprise Search und analytische Anwendungen werden mithilfe von Core-Data-Services-Views (CDS-Views) implementiert.
• Keine Verwendung von Indextabellen mehr
• Jedem Business-Objekttyp (z.B. einem Servicevorgang) ist ein Akronym (z.B. SERV) zugeordnet, und die entsprechende Datenbanktabelle hat den Namen CRMS4D_<acronym>_H (Kopf) bzw. CRMS4D_<acronym>_I (Position). Die Akronyme werden in der Tabelle CRMS4C_ACRONYM gespeichert.
• Die (neuen) Tabellen für die komplexen Komponenten heißen CRMS4D_<Komponente>, z.B. CRMS4D_PARTNER, CRMS4D_SCHEDLIN.
• Um den bisherigen GUID-basierten Ansatz mit dem jetzt verwendeten Design zu verbinden, wurden die "reduzierten Versionen" von CRMD_ORDERADM_H/I beibehalten, die CRMS4D_BTX_H/I heißen.

Die obige Abbildung zeigt einige Beispiele für konvertierte SELECT-Anweisungen basierend auf der One-Order-Neugestaltung.

AET ist das Anwendungserweiterungstool. In SAP CRM 7.0 wurde von SAP ein Web-UI-basiertes Entwicklungstool eingeführt, das Anwendungserweiterungstool (AET) zum Anlegen von Feldern für Business-Objekte.

Felderweiterbarkeit: Felder können über ein sogenanntes Persistenz-Include an Kopf- und Positionstabellen angehängt werden. Dieses Persistenz-Include ist auch im One-Order-Segment CUSTOMER_H/I enthalten, das die Verknüpfung zum API und zur Benutzungsoberfläche darstellt, sowie in den Such- und Suchergebnisstrukturen.

Was die Integration angeht:

• In SAP CRM 7.0 wurde die Integration in andere Systeme (SAP- und Nicht-SAP-Systeme) immer über die SAP-CRM-Middleware implementiert (Ausnahme: SAP Supply Chain Management (SAP SCM)).
• Die Standardschnittstelle zu externen Systemen war der sogenannte XIF-Adapter, der es SAP-Kunden ermöglichte, Objekte in einem generischen IDoc-Format auszutauschen (asynchron). Zusätzlich standen SOAP-Services (synchron und asynchron) und BAPIs zur Verfügung.
• Mit SAP S/4HANA Service wurden alle diese Schnittstellen abgekündigt: Der XIF-Adapter verwendet die Middleware, IDocs sind in der Cloud nicht zulässig, die Schnittstelle enthält viele nicht unterstützte Segmente, die SOAP-Services enthalten nicht unterstützte Funktionen und entsprechen nicht der SAP-S/4HANA-Services-Architektur. Ebenso enthalten die BAPIs nicht unterstützte Parameter.
• Daher lautet das aktuelle Integrationsparadigma: Für jedes Business-Objekt werden synchrone CRUD-Services (OData) bereitgestellt. Es werden auch asynchrone SOAP-Services bereitgestellt. Die Priorisierung, welche Services mit welchem Release ausgeliefert werden, hängt von den Business Cases ab, die im jeweiligen Release-Umfang enthalten sind.

In Bezug auf die Werkzeuge für SAP Readiness Check und Migration:

• Es gibt keine Systemkonvertierung von SAP CRM 7.0 auf SAP S/4HANA Service wie die Konvertierung von SAP ERP auf SAP S/4HANA. Dies ist immer eine Migration, da das SAP-S/4HANA-Service-Add-on vorab installiert und in einem zweiten Schritt die Daten migriert werden müssen.
• Bereitschaftsprüfung: SAP hat Vereinfachungselemente veröffentlicht, die das Delta zwischen SAP CRM 7.0 und SAP S/4HANA Service im Detail beschreiben. Jedem Vereinfachungselement kann eine Prüfung zugeordnet werden, die in einem Kundensystem ausgeführt werden kann, um automatisch Bereiche zu ermitteln, in denen Funktionen nicht unterstützt werden oder Anpassungen vorgenommen werden müssen.
• Migrationstools: SAP stellt Migrationstools für die Migration von Objekten in das SAP-S/4HANA-Datenmodell bereit. Beispiele hierfür sind:
  • Migration von SAP-CRM-Serviceprodukten in SAP-S/4HANA-Materialstämme
  • Migration von Geschäftsvorfällen

Kunden, die bereit sind, von einer SAP-CRM-7.0-Installation auf SAP S/4HANA Service zu migrieren, möchten dies möglicherweise nicht in einem Schritt tun. Möglicherweise ziehen sie es vor, mit der Zeit reibungslos zu wechseln. Dies reduziert Risiken, ermöglicht eine flexiblere Anpassung an Geschäftsanforderungen und minimiert die Auswirkungen auf das Geschäft.

Aus diesem Grund wird ein hybrides Deployment-Modell unterstützt, wie in der Abbildung „Hybrid-Deployment: Systemlandschaft" dargestellt.

Wenn ein Kunde eine Migration einer SAP-CRM-7.0- oder SAP-CRM-7.0-EhP-Installation in SAP S/4HANA (On Premise) Release 1909 oder höher erwägt oder plant, sind die im SAP-Hinweis 2691605 - Persistenz von Geschäftsvorgängen, optimiert für SAP HANA, gepflegten Informationen bezüglich der Art und Weise, wie Daten im System persistiert werden, relevant.

Die Persistenz der Daten von SAP-S/4HANA-Service-Geschäftsvorgängen wurde vollständig neu gestaltet, um schnelle Abfragen und Analyseaktivitäten zu unterstützen. Jedes Business-Objekt in SAP S/4HANA wird durch eine flache Tabelle (Kopf- und Positionsebene) dargestellt, die alle flachen Sets und Erweiterungen aufnimmt. Komplexe Komponenten wie Partner oder Referenzobjekte werden weiterhin in einer separaten Tabelle gehalten, aber die Schlüsselstruktur dieser Tabelle wurde vereinfacht.

• Die wichtigsten Prinzipien hinter der Architektur von SAP S/4HANA Service beim Vergleich mit SAP CRM 7.0 lauten wie folgt: harmonisierte Stammdaten, Engine-Harmonisierung, Customizing-Harmonisierung, keine Verwendung von SAP CRM Middleware, moderne Benutzungsoberfläche und keine Verwendung veralteter Technologien mehr.
• Kunden, die bereit sind, von einer SAP-CRM-7.0-Installation auf SAP S/4HANA Service zu migrieren, möchten dies möglicherweise nicht in einem Schritt tun. Möglicherweise ziehen sie es vor, mit der Zeit reibungslos zu wechseln. Dies reduziert Risiken, ermöglicht eine flexiblere Anpassung an Geschäftsanforderungen und minimiert die Auswirkungen auf das Geschäft. Aus diesem Grund wird ein hybrides Deployment-Modell unterstützt.
• Die Persistenz der Daten von SAP-S/4HANA-Service-Geschäftsvorgängen wurde vollständig neu gestaltet, um schnelle Abfragen und Analyseaktivitäten zu unterstützen.