Partnerwahl: Wie findet man den „Richtigen“ für SAP on Cloud?

"SAP on Cloud" heißt das Gebot der Stunde im Universum des Walldorfer Softwareriesen. Ohne Frage gibt es eine breite Palette von handfesten Vorteilen, eine SAP-Infrastruktur in die virtuelle Wolke zu verlagern. Davor steht allerdings immer die Herausforderung, einen oder mehrere richtige Partner für die "Cloud Journey" zu finden.

"SAP on Cloud" heißt das Gebot der Stunde im Universum des Walldorfer Softwareriesen. Ohne Frage gibt es eine breite Palette von handfesten Vorteilen, eine SAP-Infrastruktur in die virtuelle Wolke zu verlagern. Davor steht allerdings immer die Herausforderung, einen oder mehrere richtige Partner für die "Cloud Journey" zu finden. Hier greifen klassische Ausschreibungs- und Auswahlprozesse nur bedingt. Abhängig von den Anbietern und Lösungsszenarien sind innovative Prozesse gefragt.
Was gibt es also bei der Partnersuche für die Migration zu beachten? Fünf Tipps am Beispiel einer Ausschreibung für die Transformation eines klassischen Basis-Betriebs der SAP Business Suite auf eine Public-Cloud-Plattform.

Tipp 1 – Long List

Der Anbietermarkt entwickelt sich rasant – sowohl im Hinblick auf konkrete Lösungen als auch hinsichtlich konkreter Umsetzungserfahrung. Deshalb ist ein besonders weit gefasstes Scoping bei der initialen Bestimmung der Long List für eine Ausschreibung sinnvoll. Hierbei sollten im Rahmen eines RFI bereits konkrete Referenzbeispiele und der Umfang von möglichen Use Cases detailliert abgefragt werden. Alle Anbieter weisen heute "Cloud-Erfahrung" vor, aber nur wenige können Kunden nennen, die bereits klassische SAP-Lösungen auf der Public Cloud betreiben.

Tipp 2 – RFP "Light"

Insbesondere Public-Cloud-Anbieter tun sich mit dem klassischen mehrstufigen RFP-Vorgehen schwer. Zum einen ist das Account Management der Anbieter häufig unterbesetzt, da ja der Fokus auf "Self-Service" liegt. Der Kunde muss sich bei der Auswahl auf die allgemein verfügbaren Dokumentationen verlassen – kundenspezifische Absprachen sind die Ausnahme. Zum anderen geben diese Provider kein kaufmännisch verbindliches Angebot ab, sondern verweisen ausschließlich auf die aktuell veröffentlichten Konditionen und Servicebeschreibungen, die jederzeit einseitig geändert werden können. Hinzu kommt: Gerade hinsichtlich der Ressourcen-Bereitstellung für SAP Workloads befinden sich die großen Public-Cloud-Anbieter derzeit in einem Innovationswettbewerb. Dabei kommt Ankündigungen und Roll-out-Plänen von geeigneten Ressourcen über die weltweiten Standorte eine hohe Relevanz zukommt. Daher sollte man die tatsächlich verfügbaren und die bislang nur angekündigten Features während des gesamten Auswahlprozesses genau verfolgen.

Tipp 3 – Zielarchitektur

Im klassischen Full-IT-Outsourcing des SAP Basis-Betriebs wurde die technische Architektur durch den Managed Service Provider einmalig festgelegt und in der Regel auf Provider-eigenen Systemen implementiert. Bei Nutzung einer Public-Cloud-Plattform hat der SAP-Basis-Betreiber zwar weiterhin die Architekturhoheit, ist aber hochgradig abhängig von den durch den Public-Cloud-Provider beigestellten, hochstandardisierten Lösungskomponenten. Die Herausforderung besteht in der optimalen Konfiguration der Zielarchitektur – zum einen sind die technischen Abhängigkeiten der Komponenten untereinander (z.B. die Anzahl der zulässigen Festplatten je Instanz) sowie die Performanz-Anforderungen (z.B. die IOPS je Instanz) abzubilden, zum anderen ist eine kostenoptimale Lösung zu finden. Voraussetzung hierfür sind genaue Kenntnisse bezüglich der aktuellen Workloads je System – am besten über das Monitoring der Ist-Umgebung für einen relevanten Beobachtungszeitraum. In diesem Modell stellt also der Public-Cloud-Provider seine standardisierten Ressourcen zur Verfügung, auf denen dann ein zweiter IT-Provider den eigentlichen Betrieb der SAP-Basis organisiert. Der strategische Vorteil dieser auf den Layer-Strukturen verteilten Beauftragung: Sie lässt dem auslagernden Unternehmen mehr Freiheiten, die Verantwortungen auf den verschiedenen Layern austauschen zu können. Zugleich reduziert sich das Risiko eines potenziellen Lock-In-Effekts.

Tipp 4 – Proof of Concept (PoC)

Die angebotenen Zielarchitekturen können von Anbieter zu Anbieter abweichen. Daher ist über einen PoC die Umsetzbarkeit und Performance der angebotenen Lösung zu validieren. Der PoC sollte hierbei die Bedingungen des zukünftigen Operating Models weitestgehend abbilden. Hier sind insbesondere die Verwendung der Migrations-, Monitoring- und Backup-Tools zu berücksichtigen – sämtlich potenzielle Kosten- und Komplexitätstreiber! Ebenso wichtig sind belastbare Tests des laufenden Betriebs einschließlich Restores. Daneben sind auch die Security-Konzepte zu validieren, hier insbesondere das Zoning und der sichere Zugriff auf Systeme über Firewalls. Nicht zuletzt sind auch die Kosten der Nutzung von Public-Cloud-Ressourcen im PoC zu planen und genau zu überwachen, um unangenehme Überraschungen durch ungenutzte Ressourcen zu vermeiden.

Tipp 5 – Business Case

Die Ermittlung des Business Case bei einer Public-Cloud-Nutzung ist zweifellos eine besondere Herausforderung. Zum einen sind eine Vielzahl von Service-Elementen der Public Cloud zu berücksichtigen, die im klassischen Betrieb nicht verrechnet und daher nicht gemessen wurden. Zum anderen sind die dynamischen Nutzungsmöglichkeiten auch mit erhöhten Risiken bei der Budgetkontrolle verbunden. Hier ist der Einsatz von speziellen Tools für das Cloud Cost Management zu erwägen. Es ist sinnvoll, hierbei mit verschiedenen Szenarien zu arbeiten, die eine Bandbreite für das insgesamt mögliche Einsparpotenzial ergeben.

Artikel empfehlen

Durch die Nutzung dieser Webseite erkläre ich mich mit der Verwendung von Cookies einverstanden. Weitere Informationenschließen