SAP Releasewechsel unter komplexen Bedingungen RckblickErfahrungsbericht aus Sicht
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 1
Einordnung Hannover Rückversicherung AG WIR SIND EINER DER GRÖSSTEN RÜCKVERSICHERER DER WELT Prämien-Ranking 2007 in Mio. USD 1) Ertrag geht vor Umsatz! 1) Quelle: A. M. Best 3) 66 Syndikate (Stand 2007) 2 2) Gen. Re Group; Berkshire Hathaway Re Group (National Indemnity)
Einordnung Hannover Rückversicherung AG GRUPPENSTRUKTUR UNTERSTÜTZT UNSER GESCHÄFTSMODELL Wir sind operativ und finanziell unabhängig - trotz Mehrheitsaktionär Talanx AG* 50, 2 % Streubesitz 49, 8 % 64, 2 % >100 Tochter- und Beteiligungsgesellschaften, Niederlassungen und Repräsentanzen in ~20 Ländern 8 deutsche 35, 7 % VVa. G Inlandsgeschäft * Alleineigentümer HDI V. a. G. 3 Internationales Geschäft
Einordnung Hannover Rückversicherung AG UNSER WEG ZU EINER GLOBALEN IT Die IT stellt Services für 26 HR-Lokationen bereit Spain § Madrid (6)/2000 Ireland § Dublin (33)/2000 Great Britain § London/V. W. , France § Paris § Bracknell § (92)/2000 -04 (39)/2000 Germany § Hannover (~ 900) Italy § Milan (12)/2000 Sweden § Stockholm (79)/2000 Bahrain § Manama (8)/2007 Canada § Toronto Korea § Seoul (4)/2008 (5)/2006 Japan USA § Chicago § Tokyo (7) 2008 (10)/2006 Taiwan § Taipei (5) § New York (87) § Orlando (92) China § Hong Kong (13) Bermuda § Hamilton (17 + 5) § Shanghai (2) (8)/2007 Malaysia § Kuala Lumpur Mexico § Mexico City (31)/2008 (5)/2001 Colombia § Bogotá (12)/2006 Brazil § Rio (4)/2008 4 India § Mumbai (4)/2008/9 Australia § Sydney (47) § Fac (3)/2005 South Africa § Johannesburg (156)
Einordnung Kernapplikation der Hannover Rückversicherung AG INTEGRIERTE ARCHITEKTUR VON RE 7 Verbesserte Unterstützung der Business-Prozesse durch re 7 Der fachliche Umfang der neu eingeführten re 7 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" 5 eher "SAP-Standard"
Einordnung Kernapplikation der Hannover Rückversicherung AG RE 7 ARCHITEk. TUR Überblick Die re 7 -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 re 7 -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
Ausgangsszenario für der Releasewechsel KOMPLEXER RELEASEWECHSEL AUFGRUND NEUEINFÜHRUNG 4. 6 C 6. 00 2004 4. 6 C (CO, PS, HR) 4. 6 C ca. 350 User 2 Umgebungen 2005 -07 2008 2009 ERP 2005 / SAP FS 6. 0 (CO/PS/HCM/Finance Solution FI, konkret FS-RI, FS-CD + Zusatzmodule (msg Systems) Kein "Technischer Rel. Wechsel Komplexer Releasewechsel (einmal 2 Mandanten) 6. 00 ca. 900 User 4 Umgebungen (je 1 Mandant) Ausgangspunkt war eine Installation unter 4. 6 C (Vertragsbeginn 01. 10. 2004). 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. Daraus resultierte ein Einführungsprojekt mit dem Zielrelease ERP 2005 / SAP FS 6. 0, wobei die vorhandene 4. 6 C-Umgebung dort integriert werden sollte. 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
Ausgangsszenario für der Releasewechsel KOMPLEXER RELEASEWECHSEL AUFGRUND NEUEINFÜHRUNG 4. 6 C 6. 00 2004 4. 7 100 IH 4. 6 C 100 HR (CO/FI/HR) 300 Pro. Re (CO/FI) 2005 -07 2008 2009 Im SAP-Vertrag, aber System einer. Tochtergesellschaft 6. 00 Hinsichtlich Releasewechsel eigenständig. . . 100 IH … Betreuung in separater Systemumgebung 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 integrierten 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 10
ZEITLICHER ABLAUF DER RELEASEWECHSELAKTIVITÄTEN Systemvorbereitung (Trennung/Kopie/Neuaufbau) 2004 2005 -07 Trennung durch Kopie u. Mandantenlöschung 300 Pro. Re (CO/FI) 1 Trennung durch Kopie u. Mandantenbereinigung 4. 6 C 100 HR (CO/FI/HR) 300 Pro. Re (CO/FI) 4. 6 C 2 100 HR (HCM) 3 4. 6 C Beibehaltung und Bereinigung 100 HR "PROD" 4. 6 C 4 Systemkopie zur Trennung vom Produktionsbetrieb 100 HR "COPY" SICS 6. 00 (Non-SAP Core-App) 100 HR "NEW" 5 Neuaufbau für Einführungsprojekt 2008 2009 Produktiver Betrieb 4. 6 C, Basis-Services bei HR, fachlich bei Pro. Re Ziel: Separater techn. Releasewechsel Produktiver Betrieb 4. 6 C mit Einspielung Legal Patches Ziel: Separater techn. Releasewechsel Produktiver Betrieb in Linie Ziel: Datenübernahme per MWB in neues System (inkl. Upgrade) Vorbereitung MWB-Lauf Neuaufbau für Einführung und Daten per Migration aus SICS Projektziel: Einführung neuer integrierter RV-Lösung auf Basis akt. Release 0 Unterschiedliche Stränge (Projekt/Linie) aufgesetzt als eigenständige Vorhaben Überschneidungen aufgrund zeitlicher Reihenfolge und begrenzter Ressourcen (Mitarbeiter und Hardware) 11
Vorgehen beim Releasewechsel Zeitlicher Ablauf unterschiedlicher Releasewechselaktivitäten Durchführung (techn. Rel-Wechsel, MWB, Migration/Neuaufbau) 2004 2005 -07 Trennung durch Kopie u. Mandantenlöschung Trennung durch Kopie u. Mandantenbereinigung 100 HR (CO/FI/HR) 300 Pro. Re (CO/FI) 100 HR (HCM) 3 4. 6 C Beibehaltung und Bereinigung Systemkopie zur Trennung vom Produktionsbetrieb SICS 12 100 HR "PROD" 8 Neuaufbau für Einführungsprojekt 100 HR "NEW" 6. 00 Betrieb 100 HR EDU Ziel: 6. 00 Datenübernahme 100 HR per MWB in neues EDU System (inkl. Upgrade) Vor Go-Live Aufbau u. Betrieb Schulungsumgebung Weitere Releaseakt. (Stabilisierung u. Übertragung der Alt. Vorbereitung MWB-Lauf Konsolidierung) Projektziel: daten mit MWB-Lauf 100 HR "COPY" 6. 00 5 Produktiver Produktver Betrieb bis Go-Live Neusystem in Linie 4. 6 C 4 (Non-SAP Core-App) Ziel: 11 6. 00 Produktiver Betrieb Legal Patches unter 4. 6 C Technischer Separater techn. 100 HR Releasewechsel Maintenance mit. Extended Einspielung Legal Patches Releasewechsel (HCM) 4. 6 C 2 2009 Ziel: 10 Produktiver Betrieb 4. 6 C, 6. 00 Technischer Betrieb als Separater techn. Basis-Services bei HR, 300 Pro. Re Releasewechsel Service-Provider Releasewchsel fachlich bei Pro. Re (CO/FI) 4. 6 C 300 Pro. Re (CO/FI) 1 4. 6 C 2008 6 7 Einführung 12 neuer 6. 00 integrierter RV-Lösung 100 HR auf 9 Basis akt. RV-Prod Release 6. 00 Neuaufbau für Einführung und 100 HR Daten per Migration aus SICS Zusammenführung Entwicklung und Aufbau integriertes RV-System, Datenmigration aus SICS 4. 6 C und SICS mit Go-Live Aug. 08 (techn. in 6 u. 7)
Vorgehen beim Releasewechsel Zeitlicher Ablauf unterschiedlicher Releasewechselaktivitäten Durchführung (techn. Rel-Wechsel, MWB, Migration/Neuaufbau) 2004 2005 -07 Trennung durch Kopie u. Mandantenlöschung Trennung durch Kopie u. Mandantenbereinigung 100 HR (CO/FI/HR) 300 Pro. Re (CO/FI) 4. 6 C 300 Pro. Re (CO/FI) 1 4. 6 C 2008 4. 6 C 2009 Betrieb als Service-Provider Technischer Releasewechsel Legal Patches unter Extended Maintenance Technischer Releasewechsel 6. 00 300 Pro. Re (CO/FI) 11 6. 00 2 100 HR (HCM) 3 4. 6 C 6. 00 100 HR "PROD" 100 HR EDU Beibehaltung und Bereinigung Systemkopie zur Trennung vom Produktionsbetrieb 6. 00 (Non-SAP Core-App) 100 HR "NEW" Neuaufbau für Einführungsprojekt 100 HR (HCM) Vor Go-Live Aufbau u. Betrieb Schulungsumgebung Weitere Releaseakt. (Stabilisierung u. Übertragung der Alt. Konsolidierung) daten mit MWB-Lauf 100 HR "COPY" SICS 5 8 4. 6 C 4 6 12 7 Entwicklung und Aufbau integriertes RV-System, Datenmigration aus SICS 6. 00 100 HR 9 Zusammenführung 4. 6 C und SICS mit Go-Live Aug. 08 (techn. in 6 u. 7)) Systeme mit unterschiedlichem Releasestand parallel (vgl. E-K-P) Projektanforderungen forderten häufig Systemneuaufbauten durch Basis 13 10 6. 00 100 HR RV-Prod
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
Komplexe Systemlandschaft SAP SYSTEMLANDSCHAFT FEBRUAR 2008 Sichtweise für Identity Management Solution. IT-SD V 03 All (and other) in scope of SAP Basis (IT-OP) Datenmarkt Kopie Dry Runs Migrationsvorbereitung FS RI AR M 03 A 03 Q 02 CD K 03 EDU Verf. S 03 P 03 IT-OP Business CD Kopie ohne Bew. dat. C 03 MIIS Datenmig und MWB für Prod Copy FI only Später dazu Ø RDB Ø UDB Ø… B 03 IT-SD IT-QM HR produktiv E 02 K 02 IT-OP Business P 01 Human Resource EH 1 KH 1 Protection Re EPR PPR Inter Hannover IHD IHP Sync 17. 0 15 AR (100, 111, 300) MWB SICS CD AR E 03 Convoy IT-AS Test. IT-QM I 03 Volle Gültigkeit HR-Guidelines Projekt-Scope Für jedes System: Ø Ownerschaft Ø Berechtigungsadministration Ø Nutzergruppen Ø Guidelines
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 K 03, M 03, I 03 bis zu S 03) 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, Dry. Runs, 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 (V 03) 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
Releasewechsel unter komplexen Bedingungen 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) Eigenentwicklung MS Patch/Release SAP-Release (4. 6 C 6. 00) msg-Rel. (spez. RV) HR-Rel. (add-ons) HR-Release (Standard. Desktop + Appl. ) Projekt. Release (inkl. Non-SAP Eigenentwickl. ) 17. 0 (2008) Go-Live auf Basis 18. 0 HR-Release 16. x (2005 -07) Synchronisation mit 17. 0 x. x (2004) 15. x 18. x. x. x (2009) Kurzgetaktete HR-Releases und 5 -Systemlandschaft Unterschiedliche Releasezählung bei SAP, Entwicklungspartner und HR im Rahmen des Einführungsprojektes zusammengefasst zu Projekt-Release Wartungsfähigkeit erhalten! Taktung vorgegeben durch Synchronisation Projekt- mit HR-Release zu 17. 0 und Go-Live Releasemanagement 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
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 21
Releasewechsel unter komplexen Bedingungen ERFAHRUNGEN AUS DER RELEASEWECHSELTHEMATIK 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 23 22
Thank you for your attention!
- Slides: 24