Praxisbericht:
itelligence implementiert SAP® ERP powered by SAP HANA® Die In-Memory-Technologie auf dem Prüfstand: Als eines der ersten Unternehmen überhaupt hat itelligence die Lösung SAP® ERP powered by SAP HANA® implementiert. In diesem Expert Paper erläutern wir die einzelnen Schritte, teilen unsere Erfahrungen und geben Praxistipps. Wir von itelligence beraten Unternehmen weltweit in allen Fragen rund um das Themen gebiet SAP. Was unsere Kunden derzeit am meisten beschäftigt: Wie lässt sich durch Daten analysen und Entscheidungen in Echtzeit ein differenzierender Mehrwert schaffen? Eine Schlüsselrolle spielt dabei SAP HANA. Die In-Memory-Plattform markiert einen entschei denden Durchbruch in der Evolution von Datenbanken – und liefert Unternehmen das digitale Rüstzeug für die zunehmende Marktdynamik. Mit SAP HANA gewinnen Entscheider aktuelle Einblicke in sich ständig ändernde Geschäfts anforderungen. Analysen und Szenarien lassen sich mit Echtzeitdaten in höchstem Detail grad durchführen und Informationen effizienter konsolidieren und aufbereiten.
Reporting: Früher tagesaktuell, bald in Echtzeit Als einer der weltweit führenden SAP-Partner befassen wir uns schon geraume Zeit mit den Möglichkeiten und Vorteilen dieser Technologie. Mit der Einführung in unserem eigenen System wollten wir SAP HANA noch besser kennenlernen. Denn wir müssen neue Techno logien und Lösungen detailliert verstehen, um unsere Kunden optimal zu unterstützen. Analysen und Szenarien lassen
Darüber hinaus legen wir mit dem Projekt die Basis für die Optimierung unserer eigenen Pro
sich mit Echtzeitdaten in höchs-
zesse, vor allem des Reportings. Bislang müssen wir die Daten aus der Business-Intelligence-
tem Detailgrad durchführen.
Lösung in das ERP spielen. Das dauert – und wird daher nur einmal täglich durchgeführt. Mit SAP HANA lassen sich Informationen in der Zukunft direkt aus dem ERP nutzen. Der Vorteil: Die Daten sind immer aktuell und Berichte lassen sich jederzeit quasi auf Knopfdruck erstellen.
Vor dem Start: Der Projektplan Eine Implementierung von SAP HANA betrifft viele Abteilungen und Personen. Darum ist eine sorgfältige Vorbereitung gefragt: Zunächst erstellten wir einen Migrationsplan und kalkulierten die Kosten und Aufwände. Der Projektplan listet die wesentlichen Phasen, Verantwortlichkeiten
www.itelligence.de
n
corporate.itelligence-blog.com
1
und Termine sowie die Dauer und den Status auf. So lassen sich die einzelnen Arbeitsschritte sicher koordinieren.
In drei Wellen zum Projekterfolg Die Einführung selbst gingen wir in drei Schritten an, den sogenannten Waves: von der Testphase über die eigentliche Implementierung bis zum Go-live. Das Projekt war groß zügig auf sechs Monate angelegt, um genügend Raum für zusätzliche Tests zu lassen. Eine Implementierung von
itelligence nutzt SAP ERP (früher: SAP R/3) schon seit 1996. Mittlerweile greifen 2.400 An
SAP HANA betrifft viele
wender in 22 Ländern darauf zu. Die Lösung hatte also bereits einige Upgrades und Erweite
Abteilungen und Personen. Eine sorgfältige Vorberei-
rungen hinter sich. Um gleich zwei Fliegen mit einer Klappe zu schlagen, entschieden wir uns
tung ist gefragt.
während des laufenden Projekts, das ERP-System auf den neuesten Release-Stand EhP7 zu aktualisieren. Eine Besonderheit: Damit unsere Experten ohne Datenschutzrisiko arbeiten konnten, erstell te unser Team ein von HR-Daten bereinigtes Testsystem. Die meisten Unternehmen lagern ihre Personalinformationen in einem isolierten System und brauchen diesen Zwischenschritt nicht. Sie können damit einige Wochen einsparen.
Wave 0: Testphase mit Sandbox-Migration
Kopie des Produktivsystems in eine Sandbox-Umgebung
Plattform-Upgrade Win 2003 auf Win 2008 R2 SQL 2005 auf SQL Server 2008
Upgrades und Migration auf SAP HANA Upgrade von EhP4 auf EhP7 (6.17) Export von MS-SQL Installation von SAP HANA Size S+ Import in SAP HANA Nachbereitung des Imports Funktionale Tests und Prüfung durch High-Level-User
Wave 2: Upgrades und Migration zu SAP HANA
Wave 1: Plattformwechsel mit OS -/DB-Upgrade
Plattform-Upgrade Win 2003 auf Win 2008 R2 SQL 2005 auf SQL Server 2008/2012
Installation von SAP HANA Size M und SAP HANA Size S
Erstes Testsystem Upgrade von EhP4 auf EhP7 (6.17) Export von MS-SQL Import in SAP HANA Nachbereitung des Imports (bspw. Löschen der HR-Daten) Anwendertests
Zweites Testsystem Wie im ersten Testsystem, aber mit HR-Daten Freigabe durch Key-User
Produktivsystem Wie im zweiten Testsystem Go-live
Anwendertests (Unit-Test und Prüfung der Systemintegration) mit Fokus auf Schnittstellen und Drucker
2
Ausgangssituation: Das Altsystem ■■ SAP ERP 6.0 EhP4 mit 2.400 Anwendern in 22 Ländern, Unicode mit 14 Sprachen ■■ Diverse Schnittstellen, darunter 15 komplexe – unter anderem zu SAP Customer Relationship Management (SAP CRM), SAP BusinessObjects™ Business Intelligence und mobilen Lösungen
■■ Dreisystemlandschaft ■■ Go-live am 1. Januar 1996 (damals: SAP R/3), seitdem viele Updates und Eigenent wicklungen
■■ Mehr als 1.500 Z-Objekte, davon werden rund 200 genutzt
Wave 0: Datenmigration in der Sandbox Das Team kopierte zunächst die bestehende Instanz SAP ERP 6.04 in eine Sandbox-Umgebung und führte das Release-Upgrade auf SAP ERP 6.16 sowie die Migration auf SAP HANA durch. Dort wurden Laufzeiten gemessen, technische Herausforderungen geprüft und ermittelt, wie groß die Datenbanken nach der Migration sein würden und welche Server für den Produktiv betrieb geeignet wären. Zuvor lief die Datenbank auf Microsoft SQL Server 2005 mit 350 GB. SAP HANA erzielte eine Datenkompression von 72 Prozent. Für den neuen Server ergab sich also eine Größe von 98 GB. Folglich würde ein Server der Größe Size S+ mit 256 GB ausreichen. Schließlich wiederholten wir den Vorgang mit SAP ERP 6.17, um auch für diese Version allgemeine Richtlinien für unsere Kundenprojekte ableiten zu können. Wer bereits das SAP Enhancement Package 6.0 für SAP ERP einsetzt, muss nicht zwingend auf das neue Release wechseln und kann Aufwand und Downtime verringern. Ist der Release-Stand jedoch älter als SAP ERP 6.0, ist der Umstieg auf SAP ERP 6.17 unumgänglich.
Alternative „DMO“: Update und Migration zugleich Das von SAP bereitgestellte Tool Database Migration Option (DMO) ermöglichte uns, Upgrade und Migration in einem Schritt zu vollziehen. Das geht schneller als bei der „klassischen“ Vorgehensweise, die zuerst das Upgrade und anschließend die Migration vorsieht. 10 % weniger Ausfallzeit durch
Wir nutzten die Chance und erprobten beide Methoden mit identischer Hardware und iden
das DMO-Tool von SAP
tischem Quellsystem. So konnten wir das Laufzeitverhalten vergleichen. Das Ergebnis: Mit dem DMO-Tool verringerte sich die Downtime um zehn Prozent gegenüber der traditionel len Herangehensweise. Das kann ein entscheidender Vorteil sein für Unternehmen, bei denen die Ausfallzeit betriebskritisch ist – etwa bei Firmen aus der Fertigungsindustrie oder aus der Handelsbranche.
3
Wave 1: Ein solides Fundament legen Zunächst mussten wir unser System auf die Migration vorbereiten. Betriebssystem (Microsoft Server 2003) und SQL-Datenbank (Microsoft SQL Server 2005) waren weder mit SAP HANA kompatibel noch mit SAP ERP EhP6. Also mussten wir sie erneuern. Weil außerdem die ServerHardware veraltet war, entschieden wir uns für einen Komplettaustausch. Die dedizierten Server wurden durch virtuelle Server ersetzt. Alle diese Schritte sind nicht zwingend erforderlich für Firmen, deren Hardware, Betriebssystem und Datenbanken auf dem aktuellen Stand sind. Darüber hinaus benötigten wir SAP HANA-Appliances für das Test- und für das Entwick lungssystem. Die Herausforderung in dieser Phase besteht darin, die Schnittstellen sorgfältig zu prüfen und zu testen. Wir organisierten den Hardwarewechsel so, dass die IP-Adressen beibehal ten und nur die Hostnamen geändert wurden. Das senkt den Anpassungsbedarf.
Die Systemlandschaft Die technischen Daten im Überblick
2 VMs, 4000 SAPS Windows Server 2008 R2 4 CPU 16 GB
VM, 8000 SAPS Windows Server 2008 R2 8 CPU 32 GB
ITD ITQ
ITP
SAP HANA Appliance Size M
SAP HANA Appliance Size S
IBM Appliance Size M 512 GB Version 1.00.63 MCOS SuSE Linux Enterprise Server 11 40 Cores
IBM Appliance Size S+ 256 GB Version 1.00.63 SuSE Linux Enterprise Server 11 20 Cores
ITD: Entwicklungssystem ITQ: Testsystem ITP: Produktivsystem
Wave 2: Migration auf SAP HANA Das eigentliche Upgrade folgte in Wave 2. Hier wurde aus Datenschutzgründen zunächst eine Kopie des Entwicklungssystems erstellt und migriert. Die sensiblen Personaldaten hatten wir, wie bereits erwähnt, zuvor anonymisiert oder gelöscht. So konnten wir den Entwicklern weitreichende Berechtigungen einräumen. Die Abnahmetests durch Key-User und IT er folgten in einem parallelen System mit HR-Daten.
4
Eine parallele Projektlandschaft reduziert Risiken
ITD
ITP
ITQ
Upgrade und Migration SPAU SPDD
Systemkopie Doppelte Pflege Transporte
Projektlandschaft
ITD2
Upgrade
SPAU SPDD
SPAU SPDD
ITQ2
Upgrade
ITD: ITQ: ITP: ITD2:
Entwicklungssystem Testsystem Produktivsystem Migrationstestsystem ohne HR-Daten ITQ2: Abnahmesystem für Migration inkl. HR-Daten
Der Code Inspector: Fehlerquellen auf der Spur Drei Manntage: Eine Code-Optimierung führt schnell ans Ziel
Mit SAP HANA ändert sich die Arbeitslogik eines Systems. Darum mussten wir prüfen, inwieweit unsere selbst entwickelten Lösungen die neue Datenbank unterstützten. Wir setzten dafür den „Code Inspector“ von SAP ein. Mit diesem Check-Report-Tool lassen sich Codes analysieren und syntaktische Probleme aufzeigen – auch hinsichtlich der Kompatibilität mit SAP HANA. Das Ergebnis: 250 Treffer mit unterschiedlichen Schweregraden. Die Analyse dauerte fünf Manntage, drei weitere waren für die Optimierung erforderlich. Auf diese Weise konnten wir verschie dene Reporting-Prozesse noch beschleunigen. Dieses Beispiel zeigt: Die Umstellung auf SAP HANA kann auch mit einem System rasch gelingen, das über einen langen Zeitraum individuell erweitert und angepasst wurde. Die Code-Anpassungen sind viel einfacher, als wir vermutet hatten.
Go-live: itelligence wirft den Turbo an Die anschließende Testphase für Key-User aus den Fachbereichen verlief reibungslos – wir konnten das Produktivsystem migrieren. Nach kurzer, im Voraus geplanter Downtime von anderthalb Arbeitstagen in Europa und zwei in den USA und Kanada lief das System.
Das Ergebnis: Eine IT im Sprint Mit SAP HANA konnten wir die System-Performance an vielen Stellen steigern. Die Prozesse laufen heute durchschnittlich um 60 bis 70 Prozent schneller. Das macht sich vor allem im Finanz-Reporting bemerkbar: Berichte über ausstehende Posten sind um 85 Prozent früher fertig, Anlagengitter um 83 Prozent und Profit-Center-Berichte um 77 Prozent. 5
Sogar unser komplexes, selbst entwickeltes Programm zur Bewertung der Mitarbeiterleistung läuft jetzt doppelt so schnell. Außerdem haben wir die Voraussetzungen geschaffen, unsere Business-Intelligence-Lösung abzulösen, die derzeit noch in einem separaten Business Warehouse läuft. Das einzige Manko: Die Payroll-Anwendung läuft jetzt etwas langsamer als zuvor, weil hier sogenannte Pool- oder Clustertabellen zum Einsatz kommen. SAP arbeitet daran, SAP HANA auch dafür zu optimieren.
Weniger Speicherplatzbedarf: Nur noch 100 statt 350 GB
Datenbankkomprimierung SAP HANA
72% Kompression
Fazit Durchschnittlich 60-70 % schnellere Prozesse
Die Migration war erstaunlich einfach und mit weniger Aufwand und Kosten verbunden, als wir erwartet hatten. Es gab keine kritischen Probleme. Sogar alte, selbst geschriebene Pro gramme ließen sich einfach migrieren und laufen stabil. Viele Transaktionen sind schneller geworden, einige um bis zu 80 Prozent.
Heinz Feil Heinz Feil ist seit 2009 Head of internal IT bei itelligence. In dieser Funktion ist er für die operative Betreuung sowie die strategische Ausrichtung der globalen IT-Systeme und Anwendungen zuständig. In Deutschland leitet er außerdem die Bereiche IT-Infrastruktur und IT-Service. Nach seinem Abschluss als Informatiker arbeitete Heinz Feil sieben Jahre lang als SAPBerater und später als SAP-Projektleiter bei itelligence. Anschließend war er vier Jahre als Spezialist für SAP-Lösungen bei einem international agierenden Unternehmen aus der Baubranche tätig.
6