Transcript SAP Releasewechsel unter komplexen Bedingungen - Rückblick/Erfahrungsbericht aus Sicht SAP CCC

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. USD1)
Rang Gruppe
Land
Bruttoprämie
Gebuchte
Nettoprämie
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CH
D
USA
D
GB
F
CDN
USA
USA
BDA
ROK
BDA
BDA
NL
USA
30.673
29.843
17.952
12.327
10.361
7.106
6.133
5.371
4.283
4.078
3.890
3.810
3.406
2.462
2.283
27.872
28.439
17.398
10.779
7.990
6.501
5.155
4.909
3.953
3.919
2.775
3.757
2.812
2.173
2.089
Swiss Re
Münchener Rück
Berkshire Hathaway2)
Hannover Rück
Lloyd's 3)
SCOR
London Re
RGA Re
Transatlantic Re
Everest Re
Korean Re
Partner Re
XL Re
Aegon
Odyssey Re
Ertrag geht vor Umsatz!
1) Quelle: A.M. Best
3) 66 Syndikate (Stand 2007)
2
2) GenRe 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
VVaG
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
India
 Mumbai
(4)/2008/9
Australia
 Sydney (47)
 Fac (3)/2005
South Africa
 Johannesburg
(156)
4
Einordnung Kernapplikation der Hannover Rückversicherung AG
INTEGRIERTE ARCHITEKTUR VON 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.
Underwriting
Acquisition /
Negotiation
Technical
Accounting
Contract
Administration
Operational /
Current Accounting
Book Closing
(Technical)
Payments
Financial Accounting /
General Ledger
Book Closing
(Company)
Consolidation
Unterstützte Geschäftsprozesse
eher "Erweitert"
5

eher "SAP-Standard"
Einordnung Kernapplikation der Hannover Rückversicherung AG
RE7 ARCHITEkTUR
Ü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.
Processes
Technical /
current
accounting,
Claims
Underwriting
General
ledger
External reporting
Operative reporting
Business
partner
Data
catalogue
Reporting
and
Controlling
General
codes
Core Applications
HR
individual
Other GL
add ons
FS-RI
RMnL
Underwriting Frontend
HRES reporting
FS-CD
FI-GL
Preparing
external
reporting
(e.g. special
ledger)
FS-CD:
Payment Transactions
In Current Accounting
RMNL:
Risk Manager Non Life
For facutative non life accounting
add ons
Underwriting Front End:
A specific SAP Development for
Single Risk Underwriting
HRES reporting
External reporting
Standard Work Station with Single Sign On Portal Access for SAP and HR Specific Applications
6
SAP
for HR only
FS- RI:
Treaty Reinsurance and
Technical Accounting
P&E
HRESAPPS
SAP
P & E:
Module for Prognosis and
Estimation
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.6C  6.00
2004
4.6C
4.6C
(CO,PS,HR)
(CO,PS,HR)
4.6C
ca. 350 User
2 Umgebungen
2005-07

2008
2009
ERP2005 / 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.6C (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 ERP2005 / SAP FS 6.0,
wobei die vorhandene 4.6C-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.6C  6.00
2004
4.7
100 IH
4.6C
100 HR
(CO/FI/HR)
300 ProRe
(CO/FI)
2005-07
2008
2009
Im SAP-Vertrag, aber System einerTochtergesellschaft
Hinsichtlich Releasewechsel eigenständig...
… Betreuung in separater Systemumgebung
Projekte/Vorhaben der SAP Basis
- Systemtrennung, Kopie, etc.
- Technischer Releasewechsel
6.00
100 IH
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
300ProRe
(CO/FI)
1
Trennung durch Kopie
u. Mandantenbereinigung
4.6C
100 HR
(CO/FI/HR)
300 ProRe
(CO/FI)
4.6C
4.6C
2
100 HR
(HCM)
3
4.6C
Beibehaltung und
Bereinigung
100 HR
"PROD"
4.6C
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.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)
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 ProRe
(CO/FI)
100 HR
(HCM)
3
4.6C
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 AltVorbereitung MWB-Lauf
Konsolidierung)
Projektziel:
daten mit MWB-Lauf
100 HR
"COPY"
6.00
5
Produktiver
Produktver Betrieb
bis Go-Live Neusystem
in Linie
4.6C
4
(Non-SAP
Core-App)
Ziel: 11
6.00
Produktiver
Betrieb
Legal Patches
unter 4.6C Technischer
Separater techn.
100 HR
Releasewechsel
Maintenance
mitExtended
Einspielung
Legal Patches
Releasewechsel
(HCM)
4.6C
2
2009
Ziel: 10
Produktiver Betrieb 4.6C,
6.00
Technischer
Betrieb als
Separater techn.
Basis-Services bei HR,
300ProRe
Releasewechsel
Service-Provider
Releasewchsel
fachlich bei ProRe
(CO/FI)
4.6C
300ProRe
(CO/FI)
1
4.6C
2008
7
6
Einführung
12 neuer
6.00
integrierter RV-Lösung
100 HR
auf9Basis 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.6C 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 ProRe
(CO/FI)
4.6C
300ProRe
(CO/FI)
1
4.6C
2008
4.6C
2009
Betrieb als
Service-Provider
Technischer
Releasewechsel
Legal Patches unter
Extended Maintenance
Technischer
Releasewechsel
6.00
300ProRe
(CO/FI)
11
6.00
2
100 HR
(HCM)
3
4.6C
6.00
6.00
100 HR
"PROD"
100 HR
EDU
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 AltKonsolidierung)
daten mit MWB-Lauf
100 HR
"COPY"
SICS
5
8
4.6C
4
12
7
6
Entwicklung und Aufbau
integriertes RV-System,
Datenmigration aus SICS
6.00
100 HR
9
Zusammenführung
4.6C 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
SolutionIT-SD
Convoy
All (and other)
in scope of
SAP Basis
(IT-OP)
Datenmarkt
Kopie
AR
Dry
Runs
Migrationsvorbereitung
FS RI
AR
M03
A03
Q02
Sync 17.0
15
E03
CD
IT-AS
CD
AR
(100, 111, 300)
MWB
SICS
V03
TestIT-QM
I03
K03
EDU Verf.
S03
P03
IT-OP
Business
CD
Kopie
ohne Bew.dat.
C03
MIIS
Datenmig
und MWB
für Prod
Copy FI only
Später
dazu
 RDB
 UDB
…
B03
IT-SD
IT-QM
HR produktiv
E02
K02
IT-OP
Business
P01
Human Resource
EH1
KH1
PH1
Protection Re
EPR
PPR
Inter Hannover
IHD
IHP
Volle Gültigkeit
HR-Guidelines
Projekt-Scope
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 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
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.6C  6.00)
msg-Rel. (spez. RV)
HR-Rel. (add-ons)
HR-Release
(StandardDesktop
+ Appl.)
ProjektRelease
(inkl. Non-SAP
Eigenentwickl.)
17.0 (2008)
18.x.x.x (2009)
Go-Live auf Basis 18.0
HR-Release
16.x (2005-07)
Synchronisation mit 17.0
x.x (2004) 15.x
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
21
22
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
22
23
Thank you for your attention!