SAP Releasewechsel unter komplexen Bedingungen - Rückblick/Erfahrungsbericht aus Sicht SAP CCC Dr. Uwe Vehlies SAP Arbeitskreis Nord Meeting Juni 2009 in Hamburg

SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt Einordnung der Hannover Rückversicherung AG und ihrer Kernapplikation Ausgangsszenario für den Releasewechsel Vorgehen im Rahmen der Releasewechsel und der Einführung Zeitliches Vorgehen während der Releasewechselaktivitäten Komplexe Systemlandschaft während der Projektphase Synchronisierung der Releasestände auf Basis des Hannover Rück-Releases Einflußfaktoren und komplexe Bedingungen für die Releasewechsel Erfahrungen aus der Releasewechselthematik Einordnung der Hannover Rückversicherung AG und ihrer Kernapplikation Ausgangsszenario für den Releasewechsel Vorgehen im Rahmen der Releasewechsel und der Einführung Zeitliches Vorgehen während der Releasewechselaktivitäten Komplexe Systemlandschaft während der Projektphase Synchronisierung der Releasestände auf Basis des Hannover Rück-Releases Einflußfaktoren und komplexe Bedingungen für die Releasewechsel Erfahrungen aus der Releasewechselthematik 1

WIR SIND EINER DER GRÖSSTEN RÜCKVERSICHERER DER WELT Einordnung Hannover Rückversicherung AG WIR SIND EINER DER GRÖSSTEN RÜCKVERSICHERER DER WELT WIR SIND EINER DER GRÖSSTEN RÜCKVERSICHERER DER WELT Prämien-Ranking 2007 in Mio. USD1) Ertrag geht vor Umsatz! 1) Quelle: A.M. Best 2) GenRe Group; Berkshire Hathaway Re Group (National Indemnity) 3) 66 Syndikate (Stand 2007) 2

GRUPPENSTRUKTUR UNTERSTÜTZT UNSER GESCHÄFTSMODELL Einordnung Hannover Rückversicherung AG GRUPPENSTRUKTUR UNTERSTÜTZT UNSER GESCHÄFTSMODELL Wir sind operativ und finanziell unabhängig - trotz Mehrheitsaktionär Talanx AG* Streubesitz 50,2 % 49,8 % 64,2 % >100 Tochter- und Beteiligungsgesellschaften, Niederlassungen und Repräsentanzen in ~20 Ländern 8 deutsche VVaG 35,7 % VVaG – Versicherungsverein auf Gegenseitigkeit Inlandsgeschäft Internationales Geschäft * Alleineigentümer HDI V.a.G. 3

UNSER WEG ZU EINER GLOBALEN IT Einordnung Hannover Rückversicherung AG UNSER WEG ZU EINER GLOBALEN IT UNSER WEG ZU EINER GLOBALEN IT Die IT stellt Services für 26 HR-Lokationen bereit Great Britain London/V.W., Bracknell (92)/2000-04 Spain Madrid (6)/2000 Ireland Dublin (33)/2000 France Paris (39)/2000 Germany Hannover (~ 900) Italy Milan (12)/2000 Sweden Stockholm (79)/2000 Bahrain Manama (8)/2007 Canada Toronto (5)/2006 Malaysia Kuala Lumpur (31)/2008 Taiwan Taipei (5) Japan Tokyo (7) 2008 Korea Seoul (4)/2008 USA Chicago (10)/2006 New York (87) Orlando (92) India Mumbai (4)/2008/9 China Hong Kong (13) Shanghai (2) (8)/2007 Bermuda Hamilton (17 + 5) Brazil Rio (4)/2008 Mexico Mexico City (5)/2001 Colombia Bogotá (12)/2006 Australia Sydney (47) Fac (3)/2005 South Africa Johannesburg (156) 4

eher "Erweitert"  eher "SAP-Standard" Einordnung Kernapplikation der Hannover Rückversicherung AG INTEGRIERTE ARCHITEKTUR VON RE7 BENEFITS OF RE7 Verbesserte Unterstützung der Business-Prozesse durch re7 Der fachliche Umfang der neu eingeführten re7 Systemlandschaft reicht vom Underwriting (insbesondere die administrative Unterstützung) über die Abrechnung und Verbuchung im Bereich Technical Accounting bis hin zur Erstellung des Jahresabschlusses und der Konzern-Konsolidierung im Bereich Financial Accounting. Der größter Vorteil liegt in der integrierten Unterstützung der Geschäftsprozesse auch über mehrere Fachbereiche hinweg. eher "Erweitert"  eher "SAP-Standard" 5

RE7 ARCHITEkTUR RE7 ARCHITECTURE Überblick Einordnung Kernapplikation der Hannover Rückversicherung AG RE7 ARCHITEkTUR RE7 ARCHITECTURE Überblick Die re7-Architektur basiert auf einer SAP Standard-Lösung mit Erweiterungen und ist charakterisiert durch einen Standard-Arbeitsplatz mit Portalzugriff und Integration spezifischer Hannover Rück-Applikationen, und bringt so die re7-Lösung mit den Anforderungen der Geschäftsprozesse zusammen. 6

SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt Einordnung der Hannover Rückversicherung AG und ihrer Kernapplikation Ausgangsszenario für den Releasewechsel Vorgehen im Rahmen der Releasewechsel und der Einführung Zeitliches Vorgehen während der Releasewechselaktivitäten Komplexe Systemlandschaft während der Projektphase Synchronisierung der Releasestände auf Basis des Hannover Rück-Releases Einflußfaktoren und komplexe Bedingungen für die Releasewechsel Erfahrungen aus der Releasewechselthematik 7

KOMPLEXER RELEASEWECHSEL AUFGRUND NEUEINFÜHRUNG Ausgangsszenario für der Releasewechsel KOMPLEXER RELEASEWECHSEL AUFGRUND NEUEINFÜHRUNG KOMPLEXER RELEASEWECHSEL AUFGRUND NEUEINFÜHRUNG 4.6C  6.00 2004 2009 2008 2005-07 4.6C (CO,PS,HR) ERP2005 / SAP FS 6.0 (CO/PS/HCM/Finance Solution FI, konkret FS-RI, FS-CD + Zusatzmodule (msg Systems)  Daraus resultierte ein Einführungsprojekt mit dem Zielrelease ERP2005 / SAP FS 6.0, wobei die vorhandene 4.6C-Umgebung dort integriert werden sollte. 4.6C (CO,PS,HR) 4.6C ca. 350 User 2 Umgebungen (einmal 2 Mandanten) 6.00 ca. 900 User 4 Umgebungen (je 1 Mandant) Komplexer Releasewechsel Kein "Technischer Rel.Wechsel Ein "technischer" Releasewechsel für SAP-Umgebung war nicht ausreichend, da parallel die alte Non-SAP-Kernanwendung (SICS) abgelöst und in SAP überführt werden sollte. Ausgangspunkt war eine Installation unter 4.6C (Vertragsbeginn 01.10.2004). Der komplexe Releasewechsel war somit die Einführung einer neuen integrierten Standard-Rückversicherungs-Lösung auf Basis von SAP, bei Integration der vorhandenen SAP-Standardumgebung, sodass aus SAP-CCC-Sicht „Releasewechsel“ zum komplexen Nebenthema mit unterschiedlichsten Facetten wurde. 8

KOMPLEXER RELEASEWECHSEL AUFGRUND NEUEINFÜHRUNG Ausgangsszenario für der Releasewechsel KOMPLEXER RELEASEWECHSEL AUFGRUND NEUEINFÜHRUNG KOMPLEXER RELEASEWECHSEL AUFGRUND NEUEINFÜHRUNG 4.6C  6.00 2004 2009 2008 2005-07 4.7 100 IH Im SAP-Vertrag, aber System einerTochtergesellschaft Hinsichtlich Releasewechsel eigenständig... … Betreuung in separater Systemumgebung 6.00 100 IH 4.6C 100 HR (CO/FI/HR) 300 ProRe (CO/FI) Projekte/Vorhaben der SAP Basis Systemtrennung, Kopie, etc. Technischer Releasewechsel Ziel: 6.00 100 HR +… SICS (Non-SAP Core-App) Unternehmensprojekt (Convoy) Einführung einer neuen integrier- ten Rückversicherungs-Lösung Aufgrund Einführungsprojekt kein „reiner“ Releasewechsel SAP-Systeme immer E-K-P (Ausnahme bei kleiner Umgebung auch E-P) 9

SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt Einordnung der Hannover Rückversicherung AG und ihrer Kernapplikation Ausgangsszenario für den Releasewechsel Vorgehen im Rahmen der Releasewechsel und der Einführung Zeitliches Vorgehen während der Releasewechselaktivitäten Komplexe Systemlandschaft während der Projektphase Synchronisierung der Releasestände auf Basis des Hannover Rück-Releases Einflußfaktoren und komplexe Bedingungen für die Releasewechsel Erfahrungen aus der Releasewechselthematik Einordnung der Hannover Rückversicherung AG und ihrer Kernapplikation Ausgangsszenario für den Releasewechsel Vorgehen im Rahmen der Releasewechsel und der Einführung Zeitliches Vorgehen während der Releasewechselaktivitäten Komplexe Systemlandschaft während der Projektphase Synchronisierung der Releasestände auf Basis des Hannover Rück-Releases Einflußfaktoren und komplexe Bedingungen für die Releasewechsel Erfahrungen aus der Releasewechselthematik 10

ZEITLICHER ABLAUF DER RELEASEWECHSELAKTIVITÄTEN Systemvorbereitung (Trennung/Kopie/Neuaufbau) 2004 2009 2008 2005-07 Trennung durch Kopie u. Mandantenlöschung 1 4.6C 300ProRe (CO/FI) Produktiver Betrieb 4.6C, Basis-Services bei HR, fachlich bei ProRe Ziel: Separater techn. Releasewechsel Trennung durch Kopie u. Mandantenbereinigung 2 4.6C 100 HR (HCM) Produktiver Betrieb 4.6C mit Einspielung Legal Patches Ziel: Separater techn. Releasewechsel 4.6C 100 HR (CO/FI/HR) 300 ProRe (CO/FI) Produktiver Betrieb in Linie Ziel: Datenübernahme per MWB in neues System (inkl. Upgrade) Beibehaltung und Bereinigung 3 4.6C 100 HR "PROD" Systemkopie zur Trennung vom Produktionsbetrieb 4 4.6C 100 HR "COPY" Vorbereitung MWB-Lauf Projektziel: Einführung neuer integrierter RV-Lösung auf Basis akt. Release SICS (Non-SAP Core-App) 6.00 100 HR "NEW" Neuaufbau für Einführung und Daten per Migration aus SICS Neuaufbau für Einführungsprojekt 5 Unterschiedliche Stränge (Projekt/Linie) aufgesetzt als eigenständige Vorhaben Überschneidungen aufgrund zeitlicher Reihenfolge und begrenzter Ressourcen (Mitarbeiter und Hardware) 11

KOMPLEXER RELEASEWECHSEL MIT NEUEINFÜHRUNG Vorgehen beim Releasewechsel KOMPLEXER RELEASEWECHSEL MIT NEUEINFÜHRUNG Zeitlicher Ablauf unterschiedlicher Releasewechselaktivitäten Durchführung (techn. Rel-Wechsel, MWB, Migration/Neuaufbau) 2004 2009 2008 2005-07 Trennung durch Kopie u. Mandantenlöschung 1 4.6C 300ProRe (CO/FI) 6.00 300ProRe (CO/FI) Produktiver Betrieb 4.6C, Basis-Services bei HR, fachlich bei ProRe Ziel: Separater techn. Releasewchsel 10 Betrieb als Service-Provider Technischer Releasewechsel Trennung durch Kopie u. Mandantenbereinigung 2 4.6C 100 HR (HCM) Produktiver Betrieb 4.6C mit Einspielung Legal Patches Ziel: Separater techn. Releasewechsel 11 6.00 100 HR (HCM) Legal Patches unter Extended Maintenance Technischer Releasewechsel 4.6C 100 HR (CO/FI/HR) 300 ProRe (CO/FI) Produktiver Betrieb in Linie Ziel: Datenübernahme per MWB in neues System (inkl. Upgrade) Beibehaltung und Bereinigung 3 4.6C 100 HR "PROD" 6.00 100 HR EDU 6.00 100 HR EDU Produktver Betrieb bis Go-Live Neusystem 8 Vor Go-Live Aufbau u. Betrieb Schulungsumgebung Weitere Releaseakt. (Stabilisierung u. Konsolidierung) Systemkopie zur Trennung vom Produktionsbetrieb 4 4.6C 100 HR "COPY" Vorbereitung MWB-Lauf Übertragung der Alt- daten mit MWB-Lauf Projektziel: Einführung neuer integrierter RV-Lösung auf Basis akt. Release 12 6.00 100 HR RV-Prod 7 SICS (Non-SAP Core-App) 6.00 100 HR "NEW" 6 6.00 100 HR Neuaufbau für Einführung und Daten per Migration aus SICS 9 Entwicklung und Aufbau integriertes RV-System, Datenmigration aus SICS Zusammenführung 4.6C und SICS mit Go-Live Aug. 08 (techn. in 6 u. 7) Neuaufbau für Einführungsprojekt 5 12

KOMPLEXER RELEASEWECHSEL MIT NEUEINFÜHRUNG Vorgehen beim Releasewechsel Zeitlicher Ablauf unterschiedlicher Releasewechselaktivitäten KOMPLEXER RELEASEWECHSEL MIT NEUEINFÜHRUNG Durchführung (techn. Rel-Wechsel, MWB, Migration/Neuaufbau) 2004 2009 2008 2005-07 Trennung durch Kopie u. Mandantenlöschung 1 4.6C 300ProRe (CO/FI) 6.00 300ProRe (CO/FI) 10 Betrieb als Service-Provider Technischer Releasewechsel Trennung durch Kopie u. Mandantenbereinigung 2 4.6C 100 HR (HCM) 11 6.00 100 HR (HCM) Legal Patches unter Extended Maintenance Technischer Releasewechsel 4.6C 100 HR (CO/FI/HR) 300 ProRe (CO/FI) Beibehaltung und Bereinigung 3 4.6C 100 HR "PROD" 6.00 100 HR EDU 6.00 100 HR EDU 8 Vor Go-Live Aufbau u. Betrieb Schulungsumgebung Weitere Releaseakt. (Stabilisierung u. Konsolidierung) Systemkopie zur Trennung vom Produktionsbetrieb 4 4.6C 100 HR "COPY" Übertragung der Alt- daten mit MWB-Lauf 12 6.00 100 HR RV-Prod 7 SICS (Non-SAP Core-App) 6.00 100 HR "NEW" 6 6.00 100 HR 9 Entwicklung und Aufbau integriertes RV-System, Datenmigration aus SICS Zusammenführung 4.6C und SICS mit Go-Live Aug. 08 (techn. in 6 u. 7)) Neuaufbau für Einführungsprojekt 5 Systeme mit unterschiedlichem Releasestand parallel (vgl. E-K-P) Projektanforderungen forderten häufig Systemneuaufbauten durch Basis 13

SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt Einordnung der Hannover Rückversicherung AG und ihrer Kernapplikation Ausgangsszenario für den Releasewechsel Vorgehen im Rahmen der Releasewechsel und der Einführung Zeitliches Vorgehen während der Releasewechselaktivitäten Komplexe Systemlandschaft während der Projektphase Synchronisierung der Releasestände auf Basis des Hannover Rück-Releases Einflußfaktoren und komplexe Bedingungen für die Releasewechsel Erfahrungen aus der Releasewechselthematik 14

SAP SYSTEMLANDSCHAFT FEBRUAR 2008 Komplexe Systemlandschaft SAP SYSTEMLANDSCHAFT FEBRUAR 2008 Sichtweise für Identity Management SolutionIT-SD TestIT-QM IT-AS MIIS V03 I03 S03 Volle Gültigkeit HR-Guidelines AR CD EDU Verf. K03 IT-OP Business Convoy E03 (100, 111, 300) P03 AR CD Projekt-Scope Sync 17.0 Projekt-Scope Dry Runs Kopie ohne Bew.dat. SICS Datenmarkt Kopie FS RI M03 AR CD Datenmig und MWB für Prod RDB UDB … Für jedes System: Ownerschaft Berechtigungs- administration Nutzergruppen Guidelines A03 C03 MWB All (and other) in scope of SAP Basis (IT-OP) Migrations- vorbereitung Später dazu B03 Copy FI only Q02 IT-SD IT-QM IT-OP Business Mit MWB die Daten aus FI-AR ins FS-CD übertragen, dabei ohne Modulupgrade ins neue Release. MWB-Lauf innerhalb des SAP-Systems. HR produktiv E02 K02 P01 Human Resource EH1 KH1 PH1 Protection Re PPR EPR Inter Hannover IHP IHD 15

ANFORDERUNGEN HINSICHTLICH RELEASEWECHSELTHEMATIK Hauptpunkte aus Projektsicht Zur Fertigstellung abgegrenzter, aktueller, eindeutiger und getesteter Entwicklungs- u. Releasestände wiederholte Durchführung von Systemaufbauten (insb. für K03, M03, I03 bis zu S03)  Systemaufbauverfahren, Hauptlast in der SAP-Basis Darüber im Projektrahmen Zusammenführung der vorhandenen Daten und neuen Programme bei frühzeitiger Bereitstellung einer Schulungsumgebung im neuen Release (MWB, DryRuns, EDU-Verfahren,…) Zeitliche Abstimmungen und Aufteilung für die Migration der Rückversicherungs- verträge aus Altsystem aufgrund Datenmenge u. –komplexität Add-On-Entwicklung (ca. 300 Add-Ons) speziell in SAP-Modul für Rückversicherung und Aktualisierung mit SAP-Stacks erforderte ein Vorentwicklungssystem (V03) zur Abgrenzung der Releasestände Parallel Berücksichtigung der Einbindung in die System-Landschaft der Hannover Rückversicherung (vgl. RDB, UDB, MIIS…) Schnittstellen, Portal, Single Sign On,… Synchronisation Projektrelease mit Hannover Rück-Release zu 17.0 16

SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt Einordnung der Hannover Rückversicherung AG und ihrer Kernapplikation Ausgangsszenario für den Releasewechsel Vorgehen im Rahmen der Releasewechsel und der Einführung Zeitliches Vorgehen während der Releasewechselaktivitäten Komplexe Systemlandschaft während der Projektphase Synchronisierung der Releasestände auf Basis des Hannover Rück-Releases Einflußfaktoren und komplexe Bedingungen für die Releasewechsel Erfahrungen aus der Releasewechselthematik 17

SYNCHRONISIERUNG DER RELEASESTÄNDE Releasewechsel unter komplexen Bedingungen INHALT SYNCHRONISIERUNG DER RELEASESTÄNDE Hannover Rück-Release aus Sicht SAP-CCC Über das Releasemanagement der HR werden der gesamten Nutzerschaft in regelmäßigen Abständen komplette über Qualitätsmanagement getestete Releases bereitgestellt (Desktop inkl. darüber zugreifbaren Anwendungen) x.x (2004) 15.x 16.x (2005-07) 17.0 (2008) 18.x.x.x (2009) HR-Release HR-Release (Standard- Desktop + Appl.) Eigenentwicklung Kurzgetaktete HR-Releases und 5-Systemland- schaft MS Patch/Release Synchronisation mit 17.0 Go-Live auf Basis 18.0 msg-Rel. (spez. RV) HR-Rel. (add-ons) SAP-Release (4.6C  6.00) Projekt- Release (inkl. Non-SAP Eigenentwickl.) Unterschiedliche Releasezählung bei SAP, Entwicklungspartner und HR im Rahmen des Einführungsprojektes zusammengefasst zu Projekt-Release  Wartungsfähigkeit erhalten! Taktung vorgegeben durch Releasemanagement Synchronisation Projekt- mit HR-Release zu 17.0 und Go-Live mit HR-Release 18.0 Ab 2009 kurzgetaktete HR-Releases 18.x.x.x.und 5-Systemlandschaft 18

SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt Einordnung der Hannover Rückversicherung AG und ihrer Kernapplikation Ausgangsszenario für den Releasewechsel Vorgehen im Rahmen der Releasewechsel und der Einführung Zeitliches Vorgehen während der Releasewechselaktivitäten Komplexe Systemlandschaft während der Projektphase Synchronisierung der Releasestände auf Basis des Hannover Rück-Releases Einflußfaktoren und komplexe Bedingungen für die Releasewechsel Erfahrungen aus der Releasewechselthematik 19

SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN EINFLUßFAKTOREN AUF DIE RELEASEWECHSELTHEMATIK Hauptpunkte aus Projektsicht SAP nicht führendes System, sondern Gesamtlandschaft ist zu beachten Release-Synchronisierung auf Hannover Rück Release Datenmigration und Zusammenführung aus Legacy-System und altem SAP-Release über MWB (Migration Workbench) Datenmenge und –komplexität (Rückversicherungsverträge) Entwicklung und Releasewechsel prallel (Hannover Rück Add-Ons und msg-Module) (Nicht) verfügbare Ressourcen und Skills, da paralleler Linienbetrieb Belastung SAP Basis durch häufige Systemaufbauten Systemgovernance (Abstimmung zwischen Systemownern) Einspielung Legal Patches unter altem Release Nachlaufend einzelne technische Releasewechsel in vorher abgetrennten Systemen 20

SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt Einordnung der Hannover Rückversicherung AG und ihrer Kernapplikation Ausgangsszenario für den Releasewechsel Vorgehen im Rahmen der Releasewechsel und der Einführung Zeitliches Vorgehen während der Releasewechselaktivitäten Komplexe Systemlandschaft während der Projektphase Synchronisierung der Releasestände auf Basis des Hannover Rück Releases Einflußfaktoren und komplexe Bedingungen für die Releasewechsel Erfahrungen aus der Releasewechselthematik 22

SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN ERFAHRUNGEN AUS DER RELEASEWECHSELTHEMATIK SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Hauptpunkte aus Projektsicht Einführungsprojekt und SAP-Releasewechsel orientieren sich am abgestimmten Zeitplan des Releasemanagments (Vorgaben insb. auch durch Business-Termine und durch Leistungsfähigkeit der Organisation/Entwickung  Releasetaktung) Einpassung der Termine in einen regelmäßigen Organisationsablauf Komplexität reduzieren und (zeitlich) verfügbare Ressourcen beachten Trennung der Systeme Teilprojekte und kleinere Releaseschritte (z. B. Trennung fachl./techn. Rel.) 5-Systemlandschaft als Erweiterung zu klassischer Landschaft mit E-K-P Frühes und konsequentes Testen (unterschiedliche Testszenarien, Fehlervermeidung im Projekt, weniger Probleme im Linienbetrieb  Zusammenarbeit mit Fachbereichen) Aufgrund des Einführungsprojektes hohe Anforderungen an den Übergang in den Linienbetrieb/Neue Anforderungen an die Serviceorganisation (Gremien u. Key-User) Hoher Abstimmungsaufwand mit vielen Meetings (zunächst saubere Planung, dann konzentrierte Durchführung) Nicht der Releasewechsel an sich steht im Vordergrund, sondern Projektplanung, Abstimmung und Kommunikation Performance-Probleme eher bei Neuentwicklung, nicht unbedingt bei techn. Releasewechsel Randbedingungen sind auch zeitliche Verfügbarkeit und Machbarcheit Einzelverfarhen für Backup, Systemaufbau, Hochverfügbarkeit, etc. sollten vorher definiert und implementiert sein Die Tücke steckt nicht unbedingt in der Komplexität, aber viele Tücken machen es komplex… Versuchen in Einzelprojekte zu trennen, Ressourcenverfügbarkeit, Je komplexer, desto wichtiger Projektmanagement Bei Neuentwicklungen auch mal „nein“ sagen, damit nicht zuviel pro Release Eipassung der Termine in regelmäßigen Ablauf 23

Thank you for your attention!