Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Dr. Uwe Vehlies SAP Arbeitskreis Nord Meeting Juni 2009 in Hamburg SAP Releasewechsel unter komplexen Bedingungen - Rückblick/Erfahrungsbericht aus Sicht."—  Präsentation transkript:

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

2 1  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 SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt 1

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

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

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

6 5  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. INTEGRIERTE ARCHITEKTUR VON RE7 Verbesserte Unterstützung der Business-Prozesse durch re7 5 eher "Erweitert"  eher "SAP-Standard" Einordnung Kernapplikation der Hannover Rückversicherung AG

7 6  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. RE7 ARCHITEkTUR Überblick 6

8 7  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 SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt 7

9 8  Ausgangspunkt war eine Installation unter 4.6C (Vertragsbeginn ). 4.6C ca. 350 User 2 Umgebungen (einmal 2 Mandanten)  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. KOMPLEXER RELEASEWECHSEL AUFGRUND NEUEINFÜHRUNG Ausgangsszenario für der Releasewechsel 4.6C  C (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. 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 ca. 900 User 4 Umgebungen (je 1 Mandant) Komplexer Releasewechsel 8 4.6C (CO,PS,HR)

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

11 10  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  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 SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt

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

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

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

15 14  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 SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt 14

16 15 Komplexe Systemlandschaft Test IT-QM K03 I03 AR Migrations- vorbereitung M03 MIIS IT-OP Business IT-QM Human Resource KH1PH1EH1 Solution IT-SD IT-AS IT-SD IT-OP Business Copy FI only MWB Q02 A03 All (and other) in scope of SAP Basis (IT-OP) Convoy Kopie ohne Bew.dat. P03 E03 (100, 111, 300) Inter Hannover IHPIHD HR produktiv K02P01E02 EDU Verf. S03 V03 SICS Datenmarkt Kopie FS RI Dry Runs Protection Re PPREPR Sync 17.0 Für jedes System:  Ownerschaft  Berechtigungs- administration  Nutzergruppen  Guidelines Volle Gültigkeit HR-Guidelines Projekt-Scope  RDB  UDB  … C03 AR CD Datenmig und MWB für Prod SAP SYSTEMLANDSCHAFT FEBRUAR 2008 Sichtweise für Identity Management 15 B03 Später dazu

17 16  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 ANFORDERUNGEN HINSICHTLICH RELEASEWECHSELTHEMATIK Hauptpunkte aus Projektsicht

18 17  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 SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt 17

19 18 msg-Rel. (spez. RV) HR-Rel. ( add-ons) SAP-Release ( 4.6C  6.00) Taktung vorgegeben durch Releasemanagement 18 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) HR-Release (Standard- Desktop + Appl.) MS Patch/Release Eigenentwicklung x.x (2004) 15.x18.x.x.x (2009)17.0 (2008) 16.x ( ) 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! HR-Release  Synchronisation Projekt- mit HR-Release zu 17.0 und Go-Live mit HR-Release 18.0 Synchronisation mit 17.0 Go-Live auf Basis 18.0  Ab 2009 kurzgetaktete HR-Releases 18.x.x.x.und 5-Systemlandschaft Kurzgetaktete HR-Releases und 5-Systemland- schaft

20 19  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 SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt 19

21 20  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 Releasewechsel unter komplexen Bedingungen EINFLUßFAKTOREN AUF DIE RELEASEWECHSELTHEMATIK Hauptpunkte aus Projektsicht 20

22 21  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 SAP RELEASEWECHSEL UNTER KOMPLEXEN BEDINGUNGEN Inhalt 22

23  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 Releasewechsel unter komplexen Bedingungen ERFAHRUNGEN AUS DER RELEASEWECHSELTHEMATIK Hauptpunkte aus Projektsicht 23

24 Thank you for your attention!


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

Ähnliche Präsentationen


Google-Anzeigen