23. Unsere Empfehlung aufgrund der gemachten Erfahrungen: „Überlegen Sie sich einen Umstieg auf die S/4HANA Extended Cloud (vorher bekannt als „Single Tenant Edition – STE“) sehr gut!“

Zusammenfassung: Dieser Blog-Beitrag warnt aufgrund negativer Erfahrungen vor einer Nutzung der S4/4HANA Extended Cloud (ehemals „Single Tenant Edition – STE“) und betont die Wichtigkeit einer sorgfältigen Überlegung vor dieser Entscheidung.

 

In BLOG „17. Was ist der Unterschied zwischen den zur Verfügung stehenden Betriebsmöglichkeiten – Public Cloud, Single Tenant Cloud, On-Premise System?“ habe ich eine Lanze für die HEC (HANA Enterprise Cloud) der SAP gebrochen. Dass muss ich heute in aller Form revidieren und zurücknehmen und dies aufgrund von Erfahrungen, in denen wir mit dem Entwicklungs-Mandanten im unsers On-Premise SAP Systems in die HEC STE (Single Tenant Edition) – mittlerweile umbenannt in S/4 HANA Extended Cloud – der SAP gegangen sind.

 

Vorsicht mit der HEC STE der SAP!

Das Fazit aus meiner Sicht ist, dass der SAP Pre-Sales wahrscheinlich gar nicht weiß, was dem Kunden blüht, wenn er einmal den Vertrag für die HEC unterschrieben hat. Mein damaliger Kunde, der sich im Rahmen seiner Cloud First Strategie bei der Auswahl des künftigen Betriebs-Modells seiner S/4HANA Umgebung von einem der weltweit führenden IT-Beratungsunternehmen hat unterstützen lassen, ist zu dem Schluss gekommen, dass die HEC STE der SAP das Beste ist, was er tun kann. Die Service-Versprechen der SAP waren groß und die Erwartungen an die große SAP, die die Umgebung für ihre eigenentwickelte Software ja sicher am besten betreiben kann, hoch.

Als ich als Projektleiter der S/4HANA Einführung gefragt wurde, was ich von der HEC STE erwarte, habe ich nur gesagt, dass ich erwarten würde, dass unser Entwicklungsmandant mit all unserer Arbeit in die HEC STE übernommen ist und mein Team problemlos ab max. Tag 3 des Übergangs in der HEC STE wie im jetzigen On-Prem System weiterarbeiten kann. Dies war Mitnichten der Fall. Vielmehr haben wir am Tag der Übergabe ein rudimentär initial installiertes SAP System (immerhin alle drei Instanzen DEV, QAS und PRD gleichartig laienhaft vorbereitet) übergeben bekommen. Wir mussten Tage damit verbringen, dem Team der SAP zu erklären, dass wir keine Industry Solutions oder Model Companies installiert haben wollen (das seitens der SAP in dem Zusammenhang hinzugezogene Team hat aufgrund der starken Arbeitsteilung auf Seiten der SAP zeitweise bis zu 10 Personen umfasst, was die Kommunikation und die interne Abstimmung auf Seiten SAP zeitweise unerträglich zäh und langsam gemacht hat).

Wir haben dann mit einem Abgleich der installierten SAP SW-Komponenten zwischen unseren On-Prem DEV und dem HEC STE DEV begonnen und die fehlenden in der HEC STE unter Zuhilfenahme von Service Requests an die SAP Service Factory (dazu komme ich später noch) nachinstallieren lassen, damit wir dann irgendwann unsere Arbeiten aus dem On-Prem DEV in die HEC STE übernehmen und dort weiterarbeiten konnten. Das hat ca. zwei Wochen gebraucht. Später mussten wir feststellen, dass nicht alle Teams in der HEC STE weiterarbeiten können, weil dort grundlegende Funktionen des S/4HANA Systems und sowie einige Add-Ons nicht lauffähig waren. Diese Teams arbeiten Stand heute noch immer in dem On-Prem System weiter und wir hoffen, ihre Arbeiten irgendwann in die HEC STE übernehmen zu können. Wir sprechen heute von Tag 80 nach der Übergabe der HEC STE an uns.

 

Die Defizite

Nachstehende auszugweise eMail, die ich (an Tag 50 nach der Übergabe der HEC STE an uns) auf Anforderung an einige der beteiligten Manager auf Seiten SAP geschickt habe, mag die wesentlichen Defizite verdeutlichen:

« … um eine Aufstellung der bis heute erkannten Defizite bei der Auslieferung und dem Betrieb der Systeme in der HEC STE gebeten:

Untenstehend meine eMail von gestern Abend, nachdem die HEC STE Ticket-Factory unser System seit vorgestern Abend für den gestrigen Tag komplett lahmgelegt hat.

Die vorangegangenen Punkte, auf die ich in dieser Bezug nehme sind (ohne Anspruch auf Vollständigkeit):

1.  Unzureichende Führung & Mitarbeit seitens SAP bei der initialen Bereitstellung der Systeme.

• Fehlende Abklärung des benötigtes Zustandes der initial bereitgestellten Systeme, sowohl hinsichtlich zu installierender SW-Komponenten, wie auch zu übernehmender bestehender Systeminhalte aus OnPrem
• Fehlende Abklärung freizuschaltender IP-Ranges für einen reibungslosen Zugriff auf die HEC STE durch Anwender und anzubindende Drittsysteme
• Fehlende Abklärung benötigter Business Functions; stattdessen zweiwöchige Irritation aller Beteiligten, um Festzustellen, dass wir keine benötigen
• Fehlende Abklärung der notwendigen künftigen geplanten Entstehung der Folgesysteme QAS und PRD aus dem DEV

 

2.  Im Laufe der bisherigen Zusammenarbeit haben wir dann noch die folgenden Defizite festgestellt, die uns massiv in der Projektarbeit behindert haben, bzw. immer noch behindern:

• Bei der Nachinstallation fehlender SAP SW-Komponenten wurde verabsäumt, darauf zu achten, die Systeme DEV, QAS und PRD in einem synchronen Zustand zu halten; das hätte jedes eigene Basis Team im Projekt gemacht, ohne, dass es eines separaten Hinweises bedurft hätte; bei der Betreuung im Rahmen der von der SAP angewendeten Factory Approaches ist ein solches Mitdenken, welches als normal vorausgesetzt werden sollte, offensichtlich nicht der Fall; allein dies hat uns mittlerweile einen Verzug im Projekt von mindestens drei Wochen eingebracht
• PPDS live-cache nicht aufgesetzt, obwohl Komponente im Einsatz; mussten wir selbst machen
• ERP interne eWM Kommunikation nicht konfiguriert, obwohl Komponente im Einsatz war; mussten wir selbst machen
• FIORI-Apps nicht konfiguriert und bis heute nicht lauffähig in der HEC STE Umgebung; wir dachten FIORI sei ein Bestandteil des S/4 HANA auch bei SAAS; hier sind wir immer noch mit eigenen Ressourcen dran
• Der Adobe Document Server für den Druck der Formulare Ist bis heute nicht lauffähig in der HEC STE installiert, weshalb wir nicht Drucken können, was für die Entwicklung sehr hinderlich ist; hier sind wir immer noch mit eigenen Ressourcen dran
• Keine Unterstützung bei der Übernahme der Konfigurationsdokumentation des bisherigen Projekte im IMG; hier sind wir immer noch mit eigenen Ressourcen dran. Diese Task haben wir auch übernommen, weil die SAP keinen validen Lösungsweg aufzeigen konnte
• Keines der unsererseits benötigten SAP Add-Ons ist von Anfang an in unseren Systemen in der HEC STE installiert gewesen – und schlimmer noch: keines ist für die Nutzung in der HEC STE ge-whitelisted gewesen; wir haben immer noch den Zustand, dass ein Grossteil der von uns benötigten Add-Ons bis heute nicht gewhitelistet sind und sich immer noch in diesem offensichtlich SAP intern sehr zähen Prozess befinden
• Und wie wir feststellen mussten, setzt die SAP für die Abarbeitung von Standard-Tasks Tools ein, die unzureichend stabil und getestet sind und gestern mal eben unser gesamten Projektteam in die Arbeitsunfähigkeit versetzt haben (s. unten)»

Einige dieser Missstände waren ein halbes Jahr später noch nicht behoben. Insbesondere, dass die durch die fehlende synchrone Installation der SW Komponenten in DEV, QAS und PRD des HEC STE entstandene Ungleichheit der Systeme laufend Probleme erzeugt und die SAP kein HEC STE-konformes Vorgehen anbietet, um das QAS und PRD System Mandanten- oder Systemkopie aus dem DEV aufzubauen. Dieses Vorgehen der systemübergreifenden Mandantenkopie, welches in On-Prem Systemen seit Jahrzehnten angewendet und mittels einer Standard-Transaktion, die die SAP gerade erst überarbeitet und relauncht hat ((Remote Mandantenkopie: SCC9 -> SCC9N), wird von der SAP in der HEC unter Hinweis auf in einer OSS Note aus dem Jahr 2002 genannte Risiken, nicht unterstützt. Funktionierende Alternativen werden aber auch nicht angeboten.

Einige sinngemäße Zitate von IT Managern meines Kunden aufgrund der gemachten Erfahrungen mit der HEC STE der SAP fassen das Erlebte eigentlich gut zusammen:

1. „Die SAP Organisation ist in dem Bereich des HEC Betriebs nicht erwachsen genug, um ein solches Modell zuverlässig zu betreiben“
2. „Wenn dieser Zustand anhält, war die Entscheidung, in die HEC STE der SAP zu gehen, die größte Fehlentscheidung, die wir je getroffen haben“

 

Warum ist das so?

Aus meiner Wahrnehmung und Sicht sind die Mängel im Wesentlichen in Folgendem begründet:

• Das HEC STE Team der SAP verfügt über keinerlei SAP (Basis) Kompetenz (Aussage des zuständigen Mangers der SAP)
  –> hier würde man wahrscheinlich bei jedem anderen Anbieter so eines (AZURE-) Cloud basierten Betriebsmodells besser aufgehoben sein, weil man dort einen SLA basierten One-Stop Service bekommt, der bei der SAP aufgrund der Strukturen offensichtlich nicht nötig ist und auch nicht durch einen noch so engagierten Service Manager der SAP kompensiert werden kann.
• In der HEC STE stellt die SAP dem Kunden die reine Rechnerleistung (also nur das Blech) zur Verfügung; um alles andere muss der Kunde sich selbst kümmern und kann dabei aus einem verwirrenden Katalog von ca. 1´200 Service Requests die einzelnen Basis-Aufgaben, von denen man viele aus unerklärlichen Gründen auch nicht selbst ausführen darf, sondern kostenpflichtig bei der SAP Ticket Factory beauftragen muss, auswählen. Hierbei darf man allerdings nicht voraussetzen, dass derjenige der diesen Service Request SAP-seitig irgendwo auf der Welt ausführt, über soviel Know-How verfügt, dass er im Sinne einer funktionierenden Lösung mitdenkend agiert. Vielmehr wird ein Großteil der Service-Requests erst einmal mit einer unsinnigen Rückfrage zurückgegeben (so wie man es vom OSS kennt) und es wird unnötig Zeit bei der Abarbeitung vergeudet. Darüber hinaus gibt es seitens der SAP offensichtlich keine gesicherten Management und Monitoring Prozesse für diese Service Requests. So sind zum Beispiel für uns kritische Service Requests drei Wochen einfach liegen geblieben, weil wir bei der Erfassung das falsche Team der SAP Service Factory zugeordnet hatten. Jede eigene Ticket-Organisation hätte das wohl innerhalb eines Tages gemerkt und gelöst – nicht so die der SAP Ticket Factory.
  -> Auch in diesem Punkt würde man sicher bei einem anderen Anbieter einer Cloud basierten Lösung besser aufgehoben sein, weil die meisten kompetente und mitdenkende Ressourcen bei der Abarbeitung von Tickets einsetzen.
• Die SAP Organisation als solche ist nicht agil, homogen, responsive und durchlässig genug, um einen solchen Service zur Zufriedenheit des Kunden anbieten zu können. Nachdem wir anfänglich sofort Riesenprobleme hatten, bekamen wir kurzfristig einen Service Manager von der SAP zugewiesen, der fraglos von Anfang an einen großartigen und engagierten Job gemacht hat, aber immer wieder mit den Grenzen der SAP Organisation konfrontiert und von diesen ausgebremst wurde. Intern angefragte Informationen wurden häufig schnell mal als Beratung klassifiziert und sollten erst nach dem Vorliegen eines entsprechenden Auftrags bearbeitet werden. So musste er sich bei vielen kritischen Themen wochenlang in Status-Meetings damit entschuldigen, dass er trotz Eskalation kein Feedback der zuständigen internen Abteilung der SAP bekommen hat und hat vielfach uns gebeten, den Punkt kundenseitig zu eskalieren, damit wir gemeinsam weiterkommen. Ein solches Vorgehen spricht meiner Meinung nach Bände für den Reifegrad der SAP Organisation im Umgang miteinander und hier speziell, sich als homogene Organisation gegenüber seinen HEC Kunden zu präsentieren.
  -> Auch in diesem Punkt würde man sicher bei einem anderen Anbieter einer Cloud basierten Lösung besser aufgehoben fühlen, weil viele der kleineren Organisationen einfach besser funktionieren und ihren Kunden gegenüber als homogene Organisation auftreten.

Zugegebenermaßen war auch unsere eigene Organisation nicht ausreichend vorbereitet für den Schritt in die HEC STE – allerdings wussten wir auch nicht, was uns im Detail erwartet. Und da wäre meine Erwartung, dass der Anbieter den Kunden diesbezüglich vorbereitend an die Hand nimmt und nicht erst dann anfängt zu agieren, wenn das erste Kind metertief im Brunnen liegt.

 

FAZIT:

Uns hat der Schritt in SAPs HEC STE diverse zusätzliche Mannwochen unserer qualifiziertesten Berater gekostet, um das, was die SAP nicht geleistet hat, zu kompensieren, bzw. aufzuräumen. Ferner hat der Schritt einen Verzug im Projektplan von mehreren Monaten verursacht – mal ganz abgesehen von den Frustrationen für alle Teammitglieder. Wir hatten am Ende immer noch keine komplett funktionsfähige HEC STE Umgebung für unser Projekt. Für die meisten war es nicht vorstellbar, in einer solchen Service-Umgebung produktiv zu gehen!

Deshalb meine Empfehlung:

„Überlegen Sie sich einen Umstieg auf die S/4 HANA Extended Cloud sehr gut!“

Und wie gesagt: Ich bin überzeugt, dass andere Anbieter das besser können.