Um den höheren Kosten für die Wartung von R/3 4.6c zu entgehen, wollten die LVM Versicherungen die Applikationssoftware aktualisieren. Zugleich hofften die Verantwortlichen, mit SAP ERP 6.0 eine Plattform zu erhalten, die sich leicht anpassen und erweitern lässt. Mittelfristig wird die Nutzung weiterer SAP-HR-Services basierend auf dem Java-Stack von Netweaver erwogen.

Systembetrieb mit emuliertem Unix

Bei der Umstellung spielte die Mainframe-Umgebung eine besondere Rolle. Außer der Versicherung betreiben nur wenige Anwender ihre SAP-Software auf einer emulierten Unix-Umgebung. Es handelt sich um einen Datenbank-Server mit dem Betriebssystem z/OS Version 1.6 (unter DB2 7.1) und einen Applikations-Server auf "Unix System Service" (USS). Weil diese Plattform eher selten ist, kam es immer wieder zu Verzögerungen beim SAP-Support. Die Wartung des USS hat SAP mittlerweile gekündigt, und er steht für Netweaver nicht zur Verfügung. Als Alternativen haben die LVM Versicherungen AIX und Linux geprüft. Die Entscheidung fiel zugunsten des Unix-Derivats von IBM.

Vier Phasen bis zum Produktivstart

Mit dem Zieltermin "Produktivstart 1. September 2007" wurde das Umstellungsprojekt gemeinsam mit dem SAP-Partnerunternehmen BTC in vier Phasen realisiert:

• Phase eins: Projektvorbereitung und -definition im zweiten und dritten Quartal 2006. Darüber hinaus wurden Informationen zur Zielplattform eingeholt.

• Phase zwei: Den Release-Wechsel bei der Datenbankplattform von DB2 V7 auf DB2 V8 hat die Versicherung im Oktober 2006 in Eigenregie vollzogen. Als Datenbank für z/OS dient bei den LVM Versicherungen ausschließlich DB2. Die Umstellung betraf auch versicherungstechnische Anwendungen.

• Phase drei: Umstellung der Applikations-Server auf AIX von Dezember bis Februar 2007. Zunächst nahm das Projektteam eine Testmigration des Applikations-Servers auf AIX vor (Umzug der Central Instance auf einen neuen Server). Dem Testbetrieb folgten das Entwicklungs- und das Produktivsystem. Begleitet wurden die Umstellungen vom Austausch der DB2-Client-Kopplung vom ICLI-Server zu DB2-Connect. Vor dem Release-Wechsel wurde zudem der "SAP Solution Manager" auf AIX installiert und mit der Datenbank Universal Database (UDB) verbunden.

• Phase vier: den eigentlichen Release-Wechsel wickelte das Team von Mai bis August letzten Jahres ab. Zunächst wurde eine homogene Systemkopie der Produktivumgebung gezogen und auf einem Testsystem der erste SAP-Release-Upgrade vorgenommen. Daran schlossen sich Workshops, Customizing-Arbeiten und Modultests an. Alle Änderungen wurden in Transportaufträgen aufgezeichnet.

Aufwändige Tests bei Schnittstellen

Während die Upgrades bei FI, FI-AA, CO, Workflow und HR-Abrechnung schnell und fehlerfrei liefen, waren für die Schnittstellen sowie für die Softwarebausteine Employee Self-Services (ESS) und das SAP-Add-on für das Ideen-Management "Target" vom gleichnamigen Anbieter umfangreiche Tests erforderlich. Das galt auch für die von BTC entwickelten Add-ons "Akte" und "Letter". Der Grund dafür lag in der höheren Komplexität dieser Teilfunktionen und der großen Zahl der Anwender.

Das Entwicklungssystem stand während dieser Zeit weiter für das Tagesgeschäft zur Verfügung. Dadurch war es dem Projektteam möglich, das Produktivsystem zu verändern, ohne die Anwender zu beeinträchtigen. Anfang August konnte das Entwicklungssystem umgestellt werden. Weil dort drei Mandanten mit produktivem Datenbestand enthalten sind, wurden nochmals alle Testfälle durchgespielt. Dies war nötig, da in dieser Phase das R/3 4.6C verändert wurde und diese Arbeiten auch in ERP 6.0 zu testen waren. Da parallel dazu ein SAP-Softwareprojekt im Bereich Personalwesen lief, war auch dieses mit dem Release-Wechsel abzustimmen.

Produktivstart ohne große Überraschungen

Wie geplant erfolgte am Wochenende zum 1. September 2007 die produktive Migration. An diesem Wochenende war zudem ein Monatsabschluss fällig. Die Versicherung entschloss sich, vor dem Release-Wechsel den Monat im alten Release abzuschließen, um zeitlichen Druck zu vermeiden. Die spätere Umstellung verlief völlig störungsfrei, so dass der Projektausschuss die Systeme nach kurzer Zeit wieder freigeben konnte.

Am Montag nach Beginn des Produktivbetriebs zeigten sich unter Lastbedingungen zwar Performance-Störungen, doch mit Parameterjustierung im SAP-System und der virtuellen AIX-Umgebung konnten diese schnell behoben werden.

Die Projektgruppe bestand seitens der LVM Versicherungen aus einem Projektleiter und einem IT-Koordinator, Administratoren für DB2, AIX, Unix System Service und z/OS, zwei SAP-Basis-Betreuern, einem Leitstand-Mitarbeiter, einem Abap-Programmierer für Schnittstellen und mehreren Key Usern aus den beteiligten Fachabteilungen. Der SAP-Partner BTC steuerte acht Berater und einen Programmierer bei.

Viel Arbeit bei der Basisumstellung

Den größten Aufwand verursachte die Basisumstellung. Wegen der komplexen IT-Umgebung und Migrationsproblemen mussten sich die Teammitglieder häufig abstimmen. Hier spielten unter anderem Integrationsthemen wie Drucken über den z/OS-Host (mit Hilfe des Moduls "Beta93" von Beta Systems) sowie die Schnittstellenumstellung, bedingt durch die Zeichensatzumstellung von Host-basierendem EBCDIC (Extended Binary Coded Decimals Interchange Code) auf Ascii, eine Rolle.

Probleme mit Employee Self-Services (ESS)

Zu Problemen kam es bei der Umstellung der ESS-Anwendung. Erstens war bekannt, dass SAP die von der Versicherung genutzten ESS-Szenarien auf Java-Technik umgestellt hatte. Untypisch für SAP ist hingegen, dass die alte Funktion im Coding nicht mehr existiert. Genauer gesagt: Die ESS-Starttransaktion "PZM3" wird nicht mehr ausgeliefert, auf die LVM aber angewiesen war. Hier musste das Team eine andere Lösung finden. Da die Versicherung die Self-Service-Funktionen umfangreich angepasst hatte und viele Anwender im Unternehmen die Dienste verwenden, kam das vom Softwarehersteller gebotene neue Java-System nicht in Frage. Der Softwarekonzern hatte die ESS mit Hilfe von Web Dynpro (Java-Fassung) neu entwickelt. Sie sind mit ERP 6.0 verfügbar und benötigen die Java-Engine des SAP Web Application Server. Eine Alternative bot sich auf der Grundlage des Internet Transaction Server (ITS), wobei auch hier der Produktfahrplan der SAP zu berücksichtigen war.

ITS-basierende Employee Self-Services in SAP ERP 6.0

Die Walldorfer sehen für den Stand-alone-ITS ab Netweaver 2004 nur noch eine eingeschränkte Wartung vor. In der Regel sind alte ESS-Szenarien weiterhin auf dem neuen, im Applikations-Server integrierten ITS lauffähig. SAP empfiehlt dazu allerdings den Einsatz des SAP-Portals. ITS-basierende Applikationen, die entweder das Programmiermodell "Flow Logic" oder "Webreporting" verwenden, sind umzustellen oder zu ersetzen, wenn der Anwender sie unter Netweaver ab Version 2004 oder höhere betreiben will.

Business Server Employee Self-Pages (BSP)

Als Ersatz für die Starttransaktion der Employee Self-Services (PZM3) suchte die Projektgruppe eine Lösung, die sich leicht umsetzen ließ und für den Anwender keine Umgewöhnung erforderte. Die Lösung bestand darin, das ESS-Menü in Form von "Business Server Pages" (BSPs) nachzubilden. Da die Customizing-Tabellen angebunden sind, kann man die Anwendung weiterhin anpassen und erweitern. Schulungen waren nicht notwendig, da sich bis auf die Anmeldung die Optik nicht verändert hatte.

Zu den Vorteilen der BSP/ESS-Lösung zählen:

• Geringer Umstellungsaufwand beim Wechsel von SAP/R3 4.6c auf SAP ERP 6.0

• Gleiche Optik im LVM-Mitarbeiter-Portal (kein SAP-Portal).

• Das Customizing der PZM3 kann zur Steuerung der ESS-Anwendung weiterhin genutzt werden.

• Alle zusätzlichen kundenspezifischen Entwicklungen der LVM Versicherungen sind ohne Änderung verwendbar.

• Ein interner ITS genügt, weder die Java-Engine noch das SAP- Portal ist notwendig.

• Der Hardware- und Pflegeaufwand sinkt, da kein externer ITS erforderlich ist.

  Systemumgebung vorher und nachher

  120 professionelle SAP-Nutzer verwenden das Sapgui. Weitere 2700 Anwender nutzen einen Web-Browser, um die SAP Employee Self-Services zu bedienen.

  Systemlandschaft vor dem Projekt:

  • Datenbank-Server auf z/OS 1.6 unter DB2 V7.1;

  • Applikations-Server auf Unix System Service (USS), emuliertes Unix unter z/OS;

  • drei ITS (Internet Transaction Server für ESS-Szenarien) auf Windows 2003 Server;

  • SAP R/3 4.6C mit den Modulen FI, FI-AA, CO, EC-CS;

  • Rechnungseingangs-Workflow mit IBM-Archivsystem "Common Store";

  • Personalabrechnung mit SAP HR, Veranstaltungs-Management, HR-Organisations-Management, HR-Zeitwirtschaft;

  • Target (Ideen-Management);

  • ESS (Employee Self-Service);

  • BTC Add-ons "BTC Akte" (Personalakte) und "BTC Letter" zur Integration zwischen HR und Microsoft Office.

  • Schnittstellen zu

  • versicherungstechnischen Anwendungen auf z/OS- Host;

  • Lotus Notes;

  • SAP Business Connector (Krankenkassen- und Finanzamtskommunikation);

  • Zeitwirtschafts-Subsystem von Interflex;

  • IT-Equipmentverwaltung (Valuemation);

  • Integration mit Microsoft Office;

  • Job-Steuerung mit Stonebranch;

  • SAS (Business Intelligence).

  Nach dem Projekt:

  • Datenbank-Server auf z/OS Version 1.6 unter DB2 8.1;

  • Applikations-Server auf AIX 5.3 auf IBM Regatta mit Virtualisierung (44 CPUs);

  • Frontends: Windows 2003 und Thin Clients unter Linux mit Citrix-Client;

  • Firefox-Browser;

  • Microsoft Office;

  • SAP ERP 6.0 mit Modulen und Zusatzfunktionen wie unter SAP/R3 4.6c;

  • Single-Abap-Stack-Installation (kein Java-Stack);

  • SAP Solution Manager 4.0 unter AIX und UDB (DB2);

  • Schnittstellen wie unter SAP/R3 4.6c.

Umsetzung der Archivelink-Schnittstelle

Die LVM Versicherungen setzten bisher über Archivelink definierte File-System-Archive (Repositories) ein. Eigentlich wurden sie von SAP nie für den Produktivbetrieb freigegeben, dennoch nutzen einige Firmen diese Funktion. Die Versicherung speichert damit PDF-Dateien aus dem HR-Bescheinigungswesen, Mitarbeiterfotos und archivierte Listings (Journale). Da SAP diese File-Archive seit R/3 4.7 nicht mehr unterstützt, mussten im Zuge der ERP-Umstellung auch diese Archive migriert werden. Die Archive für Bescheinigungen und Listings überführten die Softwarespezialisten der BTC in das Dokumenten-Management-System "Common Store" von IBM. Die Fotos für den schnellen Zugriff aus den HR-Transaktionen PA20/PA30 wurden in ein Repository mit Datenbankablage verschoben. Diese Migrationen vollzog das Projektteam, nachdem die neue ERP-Software installiert war.

Externe ITS waren nicht mehr verwendbar

Da der Softwarehersteller den Internet Transaction Server ab Netweaver 2004 nur noch im SAP-Kernel zur Verfügung stellt, konnten die LVM Versicherungen ihre externen ITS-Systeme nicht mehr verwenden. Wie stark der integrierte ITS die Systeme belasten würde, ließ sich anhand von SAP-Angaben zwar abschätzen, nicht jedoch per Lasttest genau verifizieren. Aufkommende Laufzeitprobleme nach dem Produktivstart in der neuen ERP-Umgebung konnten jedoch schnell behoben werden, indem Softwarespezialisten die Zuordnung von CPU und RAM justierten.

Virtualisierung erschwert Laufzeit-Kalkulationen

Da Firmen ihre Systemumgebung zunehmend virtualisieren, fällt es schwer, Laufzeiten von SAP-Systemen zu kalkulieren. Oft ist nicht klar, welche Ressourcen in Testläufen zur Verfügung standen, weil Anwender diesen Systemen in der Regel eine geringe Priorität beimessen. Damit fehlt jedoch die Grundlage, um die Ressourcenauslastung zu ermitteln. In diesem Projekt stellten die Experten im Entwicklungssystem Laufzeiten fest, die fast doppelt so lang waren wie die des Testsystems, obwohl die Systemspezialisten genau das Gegenteil prognostiziert hatten. Dass die ERP-Umstellung schneller erledigt war als erwartet, lag an ausreichend verfügbaren IT-Ressourcen. (fn)