Mit S/4HANA haben Sie ein datenhungriges Produktionssystem. Und bei der Dimensionierung der Hardware geht es nicht nur um die Festplatte, sondern auch um den Speicher. Diese werden entweder als vorgefertigte Appliance geliefert, oder Sie können Hyperscaler nutzen, die T-Shirt-Sizings für den Verbrauch anbieten. Wenn Ihr System die empfohlene Maximalkapazität erreicht, müssen Sie eine Größe aufstocken - was oft das Doppelte der vorherigen Zuweisung ist.
Uns wird ständig gesagt, dass wir uns in einer Zeit des beispiellosen technologischen Wandels befinden. Dass wir viele Bereiche unseres Arbeitslebens aufgrund der KI und ihrer überwältigenden Macht neu überdenken müssen. Das Ausmaß dessen, was uns abverlangt wird, ist unglaublich entmutigend... daher hier eine kleine Pause von all dem, in der wir einen einfachen technologischen Wandel klar erkennen können und warum wir anders handeln müssen.
In den letzten 30 Jahren haben die meisten Unternehmen, die SAP einsetzen, Systemkopien durchgeführt. Es wurde klar, dass Produktionsdaten die einzige Möglichkeit für Unit-Tests, Regressionstests, Integrationstests, Systemtests, Tests der Tests usw. waren. Das stetige Wachstum der Produktionssysteme bedeutete also ein verzögertes, aber gleichmäßiges Wachstum der Nicht-Produktionssysteme. Das dreistufige Modell (Datenbankserver, Anwendungsserver und Präsentationsschicht) mit einer herkömmlichen Datenbank machte es sehr einfach, bei Bedarf zusätzlichen Speicherplatz hinzuzufügen, und in späteren Jahren ermöglichte ein SAN (Storage Area Network) das fast sofortige Hinzufügen kleinerer Speicherplatzeinheiten.
Der Prozess der Zuweisung einer ausreichenden Anzahl von Festplatten und der anschließenden Rückkopierung der Produktion auf ein oder mehrere nicht produktive Systeme hat sich so sehr in den Jahreskalender eines SAP-Basisteams eingebürgert, dass er nur selten in Frage gestellt wird. Bis Sie beginnen, Ihre S/4HANA-Landschaft zu planen...
Jetzt werden Sie ein datenintensiveres Produktionssystem haben. Und bei der Dimensionierung der Hardware geht es nicht nur um die Festplatte, sondern auch um den Speicher. Diese werden entweder als vorgefertigte Appliance geliefert, oder Sie können Hyperscaler nutzen, die T-Shirt-Größen für den Verbrauch anbieten. Aber beim Hyperscaler-Modell kann man in der Regel nicht von 1 auf 1,1 von etwas gehen. Wenn Ihr System die empfohlene Maximalkapazität ausschöpft, müssen Sie eine Größe aufstocken - was oft das Doppelte der vorherigen Zuweisung ist. Aus der stark ausgelasteten Produktions-Appliance mit 1 TB wird also eine Appliance mit 2 TB, die nur gering ausgelastet ist, und vor der nächsten QA-Aktualisierung müssen Sie auch hier die Hardware aufstocken, da sie sonst das Produktionsdatenvolumen (Festplatte und Speicher) nicht bewältigen kann.
Seit 20 Jahren behaupte ich, dass Sie Produktionsdaten von vor 10 Jahren nicht in Ihrem QS-System benötigen. Sie werden nicht angezeigt, berichtet, geändert, verarbeitet usw. Aus der Kostenperspektive ist mein Argument absolut unbestreitbar. Transaktionsdaten machen in der Regel 50-90 % des Volumens eines SAP-Systems aus. Wenn wir also die Historie in unserem Testsystem begrenzen können, können wir eine kleinere Appliance oder eine kleinere T-Shirt-Größe für Hyperscaler-Hardware nutzen.
Aber noch besser ist, dass Ihre nicht produktiven Systeme nicht annähernd mit der gleichen Geschwindigkeit wachsen. Es sei denn, Ihr Unternehmen generiert eine große Menge an Stammdaten, oder Ihr Unternehmen hat im letzten Jahr mehr Transaktionen generiert als im Jahr davor, dann könnte die Größe des QA-Systems (mehr oder weniger) gleich bleiben. Mit der Client Sync-Lösung (Teil der EPI-USE Labs Data Sync Manager-Suite) können Sie Ihr nicht produktives System mit allen Anpassungen, Stammdaten und nur einem bestimmten Zeitraum von Transaktionen, z. B. den letzten sechs Monaten, aufbauen. Das ist alles, was Sie zum Testen brauchen.
Und diese Lösung bietet auch Spielraum. Wenn Ihre Datenscheibe aufgrund von mehr Stammdaten oder häufigeren Transaktionen zu wachsen beginnt, können Sie das Datum der Scheibe anpassen, um sie etwas zu verkleinern, oder die Auswahl auf bestimmte repräsentative Buchungskreise beschränken, um eine Hardware-Investition um ein oder zwei Jahre zu verschieben.
Das ist aber nur die eine Seite der Medaille. Es gibt auch die Möglichkeit, in Ihren Testsystemen mehr zu tun und zusätzliche kleine Clients für bestimmte Projekte oder Pilotprojekte zu haben. Und dies wird in der S/4HANA-Welt immer notwendiger werden, da das System mehr und mehr zum digitalen Rückgrat wird als zu dem Ort, an dem jeder Geschäftsprozess abläuft. Cloud-Anwendungen werden dedizierte Backend-Clients benötigen, um Schnittstellen zu testen, ohne andere Projekte zu stören oder von ihnen beeinflusst zu werden. Was Ihnen also kurzfristig Geld spart, kann Ihnen langfristig dabei helfen, das Wachsen des Unternehmens zu unterstützen.
Möchten Sie mehr über die Anforderungen an das Landschafts- und Testdatenmanagement in einer S/4HANA-Welt erfahren? Laden Sie das E-Book von Paul Hammersley herunter