S/4 on premise Sandbox Planung (Hana XS System)

Intro

Um ein SAP ERP Transformierungsprojekt greifbarer zu machen, kann man sich eine Sandbox installieren. Also mal weg vom Workshop und Powerpoint, hin zu Softwarearchiven und Servern.

Einen Brownfieldansatz würde ich im ersten Schritt nicht wählen, sondern ein leeres, grünes System wählen, um die Anforderungen kennen zu lernen und nicht mit Migrationsherausforderungen zu starten.

Im Moment ist ein guter Zeitpunkt um SAP-Lizenzen einzukaufen oder on-top zu verhandeln – brauchen wird man diese sicher.

Aber was benötigt man überhaupt, um SAP S/4 im eigenem Rechenzentrum zu installieren.

(Anmerkung: leichter und schneller geht es auch bei Cloudpartnern (z.B. AWS), die vorgefertigte Templates haben)

Ziel: S/4 1909 on Premise installieren

Quicksizer

Die „Währung“ von SAP Perfomance wurde und wird in SAPS gemessen. Das ist ein Messwert, in Form von Transaktionsschritten, die man auf der Annahme einer Systemnutzung ermittelt.

Problem ist fast diesen Sizer zu finden, da dieser häufig umgezogen ist.
Hier der Link für die Hana-Version (https://apps.support.sap.com/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sap/qs_oberflaeche/hana.do?bsp-language=en) Ein S-User wird benötigt.

Einfach formuliert: Systemidee (Produktion), Anzahl der Produktionsaufträge, Produkte, Schichten und Kernarbeitszeiten = SAPS

Auch hier kann man verschiedenste Guidelines und Schulungen finden.

Das ist zwar theoretisch, ergibt aber im Endergebnis ein Grundlage für einen ersten Architekturentwurf in Form einer T-Shirtgröße (XS – XXL)

Das kleinste zu planende System ist XS.
Wer noch nicht zur Hana migriert hat und eine andersartige Datenbank betrieben hat, der wird bei der „Systemvoraussetzung HANA“ merken, dass viel Hardware und RAM geplant werden darf. Speed comes for a price.

Ebenso gibt es bei der Hardware freigegebene Produkte. Dazu gibt es Kompatibilitätshinweise.

Der Case hier, für einen Stack: Suse Linux, Hana Datenbank, VM Ware als virtuelle Privatecloud.

Betriebsystem

Suse Linux Enterprise for SAP (SLES)

60 Tage frei,
https://www.suse.com/products/sles-for-sap/download/
https://www.suse.com/shop/sles-for-sap/

1-2 virtuelle Maschinen
6100 € für 3 Jahre
2100 € für 1 Jahr

unlimitierte Maschinen
12900 € für 3 Jahre
4780 € für 3 Jahre

Hardware

  • 200 GB RAM
  • 8 CPUs
  • 1,2 TB Laufwerke bzw.
    ca. 35.000€
  • Mounts
  • /usr/sap/ ~ 100 GB
  • /hana/log/ ~ 200 GB
  • /hana/shared/ ~ 200 GB
  • /hana/data/ ~ 500 GB

    für den internen Basis gebraucht
  • /sapbasis/temp/ ~200 GB

Vorsichtiger Nachteil, kann bei Sandboxen ggf. vernachlässigt werden: Eine Hana-Instanz muss, laut SAP, die Ressourcen fix allokieren. Heißt, diese stehen nicht mehr dynamisch anderen Maschinen zur Verfügung.

Software

Im Maintenanceplanner
(Link: https://apps.support.sap.com/sap(bD1kZSZjPTAwMQ==)/support/mp/index.html)

kann man sich in wenigen Minuten die notwendingen Pakete zusammenstellen und herunterladen, die Grundlage installieren und dann hochpatchen.

  • SAP S/4HANA für Finanzen 1503: März 2015
  • SAP S/4HANA 1511: 11. November 2015
  • SAP S/4HANA für Finanzen 1605: Mai 2016
  • SAP S/4HANA 1610: 31. Oktober 2016
  • SAP S/4HANA 1709: 15. September 2017
  • SAP S/4HANA 1809: 21. September 2018
  • SAP S/4HANA 1909: 20. September 2019

Invest

Für einen Pilotbetrieb in dieser Größe kann gerne für (Hardware, OS Lizenzen, … ) ca. 50.000 € eingeplant werden. Hier ist noch keine Beratung zur eingeplant. Das scheint eine erste gesunde Kennzahl, die natürlich stark abweichen kann, wenn Hardware frei ist oder Lizenzen für einige Monate frei getestet werden.

Gründe es (trotzdem) zu tun

  1. Slicing the elefant: Technologie und Prozesse entzerren
  2. das beste Training ist ein Livesystem, auch wenn man Systeme in der Cloud betreibt
  3. Technologiewechsel in der Infrastrukur (z. B. Windows auf SLEs)
  4. neue Technologien (Hana 2.0., Front End Server)
  5. neue Arbeitsweisen (Fiori, Rollen, Buchhaltung)
  6. neue Durchlaufzeiten und Operations (Patching)
  7. Showcase für das Unternehmen (IT Image)
  8. technisches Vertrauen in der Mannschaft aufbauen
  9. geringe Kosten Betriebskosten (vgl. interner Betrieb und Cloudauslastung)

Beste Grüße,
Mario