21. Analysieren Sie vor Projektbeginn Ihre Umsysteme und Schnittstellen – Vorschlag für einen strukturierten Ansatz bei der Umstellung auf S/4HANA: „Integration Solution Advisory Methodology (ISA-M)”

Zusammenfassung: Der Blogbeitrag empfiehlt bei der Umstellung auf S/4HANA eine strukturierte Analyse von Umsystemen und Schnittstellen mithilfe der „Integration Solution Advisory Methodology (ISA-M)“, um mögliche Probleme frühzeitig zu erkennen und zu lösen.

Bei der Umstellung auf S/4HANA liegt es auf der Hand, dass man auch seine gesamte Applikationslandschaft kritisch überprüfen sollte, um diese möglichst zu entschlacken, von unnötigen gewachsenen Informationsflüssen zu bereinigen, standortübergreifend zu vereinheitlichen und somit zu vereinfachen. Meine Empfehlung ist die folgende Vorgehensweise:

1. Klären Sie für jedes Umsystem und jede Schnittstelle die Business- und IT Ownership (sofern das nicht schon kristallklar ist)
2. Klassifizieren Sie alle Umsysteme und Schnittstellen. Hier ein Beispiel:
   1. Von Kunden oder Behörden vorgegebenes 3rd-Party-System zur Kommunikation -> muss wieder angebunden werden
   2. Über alle Standorte vereinheitlichtes 3rd-Party-System, dessen Funktionalität nicht in S/4HANA vorhanden ist -> muss wieder angebunden werden
   3. Über alle Standorte vereinheitlichtes 3rd-Party-System, dessen Funktionalität ggfs. in S/4HANA vorhanden ist -> Prüfung der Ablösung durch S4/HANA
   4. An nur einem Standort eingesetztes 3rd-Party-System, dessen Funktionalität nicht in S/4HANA vorhanden ist -> Prüfung des künftigen einheitlichen (Nicht-) Einsatzes im Unternehmen
   5. An nur einem Standort eingesetztes 3rd-Party-System, dessen Funktionalität ggfs. in S/4HANA vorhanden ist -> Prüfung des künftigen einheitlichen (Nicht-) Einsatzes im Unternehmen bzw. der der Ablösung durch S4/HANA
3. Machen Sie eine strukturierte Interface Analyse zur Festlegung der Ziel-Technologien / Kommunikationstechniken für die verbleibeenden Schnittstellen. Die SAP bietet hierfür eine aus meiner Sicht sehr gute gecoachte Vorgehensweise an: „Integration Solution Advisory Methodology (ISA-M)”. Ich würde empfehlen, sich dabei von einem ISA-M Experten der SAP coachen zu lassen, da die mit S/4HANA daherkommenden Möglichkeiten so vielfältig sind, dass man diese in der Regel einfach nicht kennt und mit einem Coaching in einer Grössenordnung von 5 – 10 md durch Spezialisten der SAP kann man extrem viel Mehrwert für seine künftige Applikations- und Schnittstellenlandschaft generieren.

Auch spielt das künftige Deployment Modell für das S/4 HANA System (Cloud / On Premise) und ggfs. die Wahl des entsprechenden Hosting Partners und dessen Möglichkeiten eine wichtige Rolle:

Folgende Links geben Aufschluss darüber, was in den Cloud Lösungen der SAP an Kommunikationsmöglichkeiten (BAPIs und IDOCs) zur Verfügung steht:

In der Cloud wie On-Premise kann BAPI’s, Idocs von S/4HANA und auch die Cloud-API’s verwenden, die im SAP API Hub unter https://api.sap.com/ aufgelistet sind.

Die vollständige Integration ist für S/4HANA Public Cloud, Ariba, SuccessFactors und OnPrem-Systeme verfügbar. Wie ein kundeneigenes On-Premise-System können Sie es nach Belieben erweitern und modifizieren, einschließlich der Darstellung von Daten über SAP-Tabellen mit Ihren eigenen benutzerdefinierten Schnittstellen (Read, Write). Für die HEC STE gilt dasselbe wie oben, mit wichtiger Einschränkung: Der SAP-Code muss unverändert bleiben, d.h. Kunden können den SAP-Code nicht ändern. Ausnahmen hiervon gibt es nur in der Private Edition (vergleiche dazu BLOG 17)

Verfügbare BAPIs und Idocs für die Integration sind in den folgenden Hinweisen dokumentiert:
• Verfügbare iDocs in der S/4HANA Cloud zur Integration in SAP On Premise Lösungen
• Verfügbare BAPIs in der S/4HANA Cloud zur Integration in SAP On Premise Lösungen
Es gibt einen guten Blog, der es wert ist, die STE-Implementierung zu überprüfen.

Ungeklärte und ungelöste Schnittstellenthematiken können ein Projekt schnell mal um Wochen oder Monate zurückwerfen und Budget und Zeitplan sprengen. Deshalb lautet meine Empfehlung, diese im Rahmen eines Vorprojektes möglichst vollständig zu lösen und sowohl das derzeitige ERP Umgebungsmodell wie auch das künftige um das S/4HANA ERP angestrebte bereits vor Beginn des Projektes definiert und entschieden zu haben.