ERP: Versicherung schickt SAP R/3 in den Ruhestand

19.11.2007
Von Udo Busjan und Rainer Bultmann
Der technische Umstieg von SAP R/3 auf ERP 6.0 verlief bei den LVM Versicherungen ohne Schwierigkeiten. Aufwändig gestalteten sich dagegen Anpassungen der Employee Self-Services und der Archivlink-Schnittstelle sowie der Wechsel des Applikations-Servers.

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 ist die Nutzung weiterer SAP-HR-Services basierend auf dem Java-Stack von Netweaver angedacht.

Systembetrieb mit emuliertem Unix

Foto: BTC

Bei der Umstellung spielte die Mainframe-Umgebung eine besondere Rolle. Neben 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 auf das Unix-Derivat von IBM.

Vier Phasen bis zum Produktivstart

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

  • Phase eins: Projektvorbereitung und -definition im zweiten und dritten Quartal 2006. Darüber hinaus wurde BTC und SAP zur Zielplattform konsultiert.

  • 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 IBM-Datenbank UDB verbunden.

  • Phase vier: den eigentlichen Release-Wechsel wickelte das Team zwischen Mai bis August diesen Jahres ab. Zunächst wurde eine homogene Systemkopie der Produktivumgebung gezogen und auf einem Testsystem der erste SAP-Release-Upgrade durchgeführt. 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 ESS und Target sowie die von BTC entwickelten Add-ons "Akte" und "Letter" umfangreiche Tests erforderlich. Der Grund dafür lag in der höheren Komplexität dieser Teilfunktionen und der hohen 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

Foto: BTC

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.

Key User und BTC-Experten arbeiten Hand in Hand

Die Projektgruppe bestand seitens der LVM Versicherungen aus einem Projektleiter und einem IT-Koordinator, Administratoren für DB2, AIX, USS 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 u.a. integrative Themenstellungen wie Drucken über den z/OS-Host (mit Hilfe des Moduls "Beta93" von Beta Systems) sowie die Schnittstellenumstellung, bedingt durch die Zeichensatzumstellung von Host-basierenden EBCDIC (Extended Binary Coded Decimals Interchange Code) auf Ascii, eine Rolle.

Probleme mit Employee Self-Service (ESS)

Foto: BTC

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 das Unternehmen jedoch 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 ESS 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 Pages (BSP)

Als Ersatz für die Starttransaktion der ESS-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.

Umsetzung der Archivelink-Schnittstelle

Foto: BTC

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-Server nicht mehr verwendbar

Da der Softwarehersteller den ITS-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 Kalkulation von Rechnerlaufzeiten

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)

Systemumgebung vorher und nachher

120 professionelle SAP-Nutzer greifen per Sapgui auf die ERP-Lösung zu. Weitere 2700 Anwender nutzen einen Web-Browser, um die SAP Employee Self-Services zu bedienen.

Systemlandschaft vor dem Projekt:

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

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

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

  • 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 Finanzamtkommunikation);

  • 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.