Go bis firo_komplexesprogram_und_agilespm_v021_zurverteilung

19.06.2015 Project Services DACH Colloquium – Dr. Oliver Klapp
Entwicklung eines Complex Program Managements bei der Barmer GEK und Nutzung von agilem PM
Reinhard Borosch, Dr. Oliver Klapp
goBIS = geschäftsprozess orientiere Barmer Insurance Solution
Programm goBIS –
Entwicklung eines Complex Program Managements
bei der Barmer GEK und Nutzung von agilem PM

2
Agenda
1 Barmer GEK & „SAP“ Strategie
2 Roadmap und Inhalte Programm goBIS (Claims I & II, MBW Stufen)
3 Organisation, Masterplan und Vertragswesen
4 Technische Herausforderungen: Systemintegration, Schnittstellen und Migration
5 Agiles Projekt Management – Prinzipien, Werte
6 Agile Methoden in einem Projekt zur Migration großer Datenmengen
7 Selbstkritische Reflexion

3
Die Barmer GEK
Überblick
– Deutschlands größte gesetzliche Krankenkasse
(Fusion in 2010 aufgrund politischer Rahmenbedingungen,
demografischen Wandels und Kostensituation; erste Fusion der
BARMER überhaupt, „auf Augenhöhe“ und „best of both worlds“
trotz der Größenunterschiede)
– Aktuell rund 8,6 Millionen Versicherte
(urspr. 6,5 Mio BARMER u. 1,7 Mio GEK Versicherte)
– Etwa 19.000 Mitarbeiter
– Über 1.000 Betreuungsstellen
– Hauptsitz in Wuppertal und
Schwäbisch-Gmünd
– Auszeichnungen:
- “Beste im Internet”
- “Familienfreundlichste”
- n-tv Testsieger

4
Die Systemsituation bei der Barmer GEK war gekennzeichnet durch Überalterung,
gewachsener Komplexität und mangelnder Wart- und Erweiterbarkeit.
Die BARMER hat bereits im Jahre 2003 damit begonnen,
ihre in Eigenregie programmierten Anwendungen (Host basiert) auf die
GKV-Branchenlösung oscare® umzustellen (goBIS I).
Dies ist bereits für die Anwendungssysteme im Beitragsumfeld und
für den Firmenkundenservice erfolgt. Nunmehr sollten in einem weiteren Schritt alle relevanten
Anwendungen aus den Bereichen Leistung und Privatkunden-Management bis 2014 auf die GKV-
Branchenlösung oscare® 2.0/3.0 umgestellt werden (goBIS II: Stand 2010).
Die Fusion änderte diese Entscheidung für einige Teile Richtung der GEK Strategie, die auf eigen
entwickelten Applikationen (MBW) basierte. Dies führte zu einer Kopplungsarchitektur oscare® – MBW.
SAP-Strategie – Ablösung Altsysteme

5
Agenda

6
Die Roadmap als Zielbild der Anwendungslandschaft ist ein komplexes
Projektkonstrukt mit der Notwendigkeit zu priorisieren.
Barmer GEK - IT Roadmap
kann geplant werden
20
81
2011  2012 2013 2014 
Abwicklung Reste
d. Altsysteme
C27
Bestandsführung/Meldewesen aus BUS/Zentrale nach MBWC33
Replikation PK von MBW nach oscare®
inkl.
MZ/EZ
C10
Legende
Bereits gestartet
Nicht gestartet
Bearbeitung in goBIS
Relevant für MEZ und
Bestandszusammen-
führung
darf nicht früher enden
Vorkehrung erforderlich: G-
Lstg. nicht in claims
bearbeiten
LeistungMelde/Beitrag/BestandWeitere
C11 oscare® Claims St.1 G-Welt
C12 oscare Claims St.2 G-Welt
Clusternummer
TelematikC38
Projekt
C19
MEZ Konzeptions-
phase
C17C17 ZLF-Ausbau - Anbindung BUS an ZLF
C05-1
Überführung FK nach oscare inkl.
Schnittstellen
C04 OM-Konsolidierung
C34 Vorarbeiten MBW für Ablösung BUS-Melde
Gemeinsames DWHC08
ZES - Zusammenführung EntgeltsystemeC03
C07
oscare® Claims Stufe 2-Leistungsw. B-Welt / Ablösung BUS-
Leistungswesen
C32 Einführung neues Mahnwesen in oscare®
C22C22 ZLF-Ausbau - Anbindung oscare® claims an ZLF für Leistgs- u. VM
C35 Umsetzung GKV-FinG in MBW
DoS / eAkteC30
C16
Beitragskonten nach oscare® - Sanfte MigrationC05-2
VAMP (Phase1)C39
C37 Redesign VIS
C40 GP-Konzept
Ruhendes Vorhaben
Abgeschlossene
Vorhaben
Gem. VersichertenbestandC20
FIZC02
C13
C14 goBIS CRM 2.0
oscare® Claims St. 1 – B-
Welt
C06
C41 Wissens- und Informationsmanagement
für Claims
Join@IT - RZ-Integration, Konsolidierung ASS, Konzept für neue OrganisationsformC28
C36
goBIS Claims goBIS MBW

Ausgangssituation Mai 2011
 Projekt Claims in kritischer Situation:
• Einführungstermin für 10/2011 terminiert
• Testfortschritt- und Entwicklungsfortschritt ungenügend
• Stimmungslage angespannt (Fingerpointing-Mentalität)
• Keine übergreifende Projekt-/Team-Kultur
• Zufriedenheit und Vertrauen gegenüber IBM sehr niedrig
 Scope nicht finalisiert:
• Claims für die G-Welt unklar
• Einbindung MBW unklar (statt OSCARE PKM)
 Kostenprobleme:
• Bei den Festpreisen
 mehr als 50% der Kosten verbraucht bei einem deutlich höheren Anteil zu
erbringender Leistungen
 DE Case
7

8
Stufe 1:
Sachleistungen
Hilfsmittel
Häusliche Krankenpflege
Pflege
Heilmittel
Erstattungen
Fahrkosten
Dialyse
Leistungs-
management
Stufe 2:
Entgeltersatzleistungen
Arbeitsunfähigkeit
Mutterschaftsgeld
Krankengeld
Kinderkrankengeld
Berufsfördernde Maßnahmen
Durchgangsarztbericht
Ersatzleistungswesen
Erstattungsansprüche § 115 SGB X
Ersatzansprüche § 116 SGB X
Rentenabrechnung
Auftragsleistung Unfallversicherung
(Arbeitsunfall, Berufskrankheit)
Zuzahlungsforderungen/Härtefall-
prüfung/-erstattung § 62 SGB V
Rückforderungen
Sonstige Forderungen
…
Stufe 2:
Stationäre Aufenthalte
Krankenhaus
Stationäre Reha
Ambulantes OP
...
Inhalte Claims

Stufe 1
Gemeinsamer
Versichertenbestand
Stufe 2
Replikation Person
nach oscare aus MBW
Stufe 4
MBW zuständig
für Bestandsführung /
Meldewesen PK;
Beitragsberechnung PK
Ablösung BUS
Stufe 5
oscare zuständig
für Beitrag komplett
(ein Beitragsbuch PK/FK)
Stufe 3
oscare zuständig
für Arbeitgeber
Replikation Arbeitgeber
nach MBW
MBW Stufenplan Versichertenintegration
9
 MBW Nutzung anstatt oscare PKM aufgrund Fusionsentscheidung
 Firmenkunden (FK) führend in oscare; Privatkunden (PK) führend in MBW
 Replikationen in die jeweiligen Systeme SAP Core, SAP CRM und MBW
 komplexe Kopplungsarchitektur

10
Agenda

11
Programmorganisation

1212
Mitglieder im Team und Projekt in Zahlen
Reinhard Borosch
Programmleiter
PL Claims
Projekt in Zahlen
Umsatz, Beratertage & andere interessante Zahlen
 Total Contract Volume: ~53 M€ (2010 – Mai 2015)
(bei 300k€ = 1 Beraterjahr -> 175 Beraterjahre)
 HeadCount: 450 in Peak, davon ca. 70 Team IBM (inkl. SSO)
 SSOs: AOK Systems, Adesso, Blue Carat
 >10 Einzelprojekte + diverse Stabsfunktionen
 Mischung aus DL & WL sowie FP & T&M mit Bonus/Malus Regelung
Dr. Oliver Klapp
PL IT-Services
stellv. Programmleiter
Foto
Dr. Markus Beyer
Architekt Foto
Volker Lang
PL Testmanagement Foto
Ulrich Löfflad
Fachlicher Koordinator
Betrieb
Ursula Kieserg
Architekt Foto
Andreas Gaspard
PL Einführung Foto
Udo Winzer
Planung, Berichtswesen,
Fortschrittskontrolle
Norbert Quante
Lead Architekt Foto
Gero Seifert
PL Migration
Michael Fritz
Leiter PMO Foto
12

13 30.10.15
Masterplanung
2012 2013 Q1/2014 Q2/2014 Q3/2014 Q4/2014 Q1/2015
MBW Stufe 4 („Meldewesen“)
Claims 1 G-Welt
MBW (PK)
MBW (FK)
19.11.2012
10/2012
21.10.2013
29.09.201
3
gestartete
Projekte
geplante IPN-Termine
erreichte IPN-Termine
17.10. 2013
12.07.201
4
Stufe 3
Stufe 2 Teil 1 Teil 2
Claims 2 (Inkremente 1-5)
Stufe 5 („Beitrag“) 31. Juli 2015
StabPhase
StabPhase
Stabilisierung
Support
BZ-Einrichtungen 1-8
DoS DoS mit IBM PL
1. BZ-Einrichtung
am 23.08.2014
IPN DoS Beitrag
19.07.2014
Claims 1 B-Welt
10.2011
13

14
Vertragswesen (Stand 31.03.2015)
removed
FiRo = Finalisierung Roadmap

15
Agenda

Systemintegration und Schnittstellenübersicht Claims II
16

Vorgehensmodell Falldatenmigration (je Produkt)
Fachliche
Spezifikation
Anforderungs
Analyse
Daten
Qualitäts
Analyse
Migrations
Design
Migrations
Entwicklung
Technische
Tests
Fachliche
Tests
• Erstellung der
fachlichen
Spezifikation
• Fachliches +
Technisches
Feldmapping
• Beschreibung von
Datenquelle,
Datensenke und
notwendiger
Transformationen
• Definition der
nichtfunktionalen
Anforderungen
an die Migration
• Analyse der
Anforderungen
gemäß
Fachspezifikation
• Erstellung Klassen-
und
Aktivitätsdiagramme
• Identifizierung der
notwendigen
Quelldaten
• Identifizierung der
zu verwendenden
SAP DI Strukturen
• Spezifikation der
Datenextrakte für
Datenqualitätsanaly
se (DQA)
• Konzeption DQA
• Erstellung der
Datenqualitätsanaly
se (DQA)
• Durchführung von
DQA Workshops
• Bewertung der DQA
Ergebnisse
• Erarbeitung von
Datenkorrektur
Maßnahmen
• Event. Anpassung
der Fachlichen
Spezifikation
• Erstellung der
Technischen
Spezifikation
• Fertigstellung der
Klassen- und
Aktivitätsdiagramme
• Fertigstellung des
technischen
Feldmappings
• Zuordnung von
Aktivitäten zu
Datastage Jobs
Datenextrakte für
Migration
Testfälle für
technische Tests in
RQM
• Umsetzung der
Migrationsroutinen
• Durchführung der
Modultests
technischen Tests
• Dokumentation der
Testergebnisse in
RQM
• Fehlerbehebung
fachlichen Tests
• Dokumentation der
Testergebnisse in
RQM
• Fehlerbehebung
17

Vorgehensmodell Falldatenmigration (je IPN)
Konzeptions
phase
Entwicklung
(je Produkt)
K-Aktionen
General
probe
Modell
betrieb
• Allgemeine
Migrationskonzeption
und Architektur
• Zuarbeit Feinkonzept
Produktionsvorbereitun
g
• Zurarbeit zur
Konzeption Fallback-
Notfall-Szenarien
• Spezifikation,
Design,
Implementierung
und Test der
Migrationsroutinen
je Produkt
• Konzeption, Planung
und Durchführung
von 3 „konzertierten
Aktionen“
• Fehlerbehebung
• Erstellung der
Abschlussberichte je
K-Aktion
• Zuarbeit zu
Detailplan
Generalprobe/
Modellbetrieb
• Begleitung der
Migrations
durchführung
• Begleitung der
Migrations-
Abnahmetests
• Abschlussbericht
und technische
Protokolle Migration
Generalprobe
(Modellbetrieb)
• Begleitung der
Migrations-
Abnahmetests
IPN
• Migrationskonzept
zur Durchführung
der IPN
• Erstellung
abgestimmter
Detailplan zur
finalen IPN
• Abschlussbericht
und Technische
Protokolle
zur finalen IPN
18

goBIS – was wurde bewegt!
(am Beispiel Claims II)
Was Wieviel Wie
Projektmitarbeiter > 450 An 5 Standorten
Gesamtaufwand (BAC)
(Ohne MBW Stufe 4)
ca. 72.000 PT gesteuert in 15 ProjPlänen mit über 600
Aktualisierungen
Gemanagte Risiken > 460
Change Requests ca. 400 Davon ca. 160 für Phase 2 (11 offene)
Schnittstellen 48 17 einfache, 14 mittlere, 17 komplexe
Schulungsteilnehmer 12.000 68.000 PT Schulungsaufwand
Arbeitsanleitungen u.
Schulungsunterlagen
4.000 Seiten
Testfälle ca. 9.500
Migrationsvolumen Ca. 50 Mio.
(aus 2 Mrd. Datensätzen)
Einführung 4-tägige IPN Im 3-Schichtbetrieb über mehrere Standorte
19

20
Agenda

2121
Kernaspekte des agilen Projektmanagements
21

2222
Werte des agilen Projektmanagements
22

2323
Prinzipien des agilen Projektmanagements
23
Agiles Manifest: 4 Werte und 12 Prinzipien

24
Agenda

25
Fragestellung
 Mit welchen besonderen Maßnahmen wurden im bisher größten* Migrationsprojekt bei einer
deutschen Krankenkasse die Stärken agiler Methoden ausgespielt?
 Neben den üblichen Hürden (wie fest etablierten „Wasserfall“-Prozessen, nur wenigen
Projektmitarbeitern mit agiler Erfahrung und verteilten Teams) bestanden im Migrations-
projekt folgende besonderen Herausforderungen bei der Einführung agiler Methoden:
1. „Big Bang“ – genau ein Liefertermin zur Produktivsetzung
2. Umfangreiche Anforderungsänderungen bei Festpreisvertrag
3. Kopfmonopole – teilweise mit stark autokratischem Führungsstil
4. Erschwerte Qualitätssicherung 1 – Entwicklung und Test getrennt
5. Erschwerte Qualitätssicherung 2 – keine Kontinuierliche Integration

26
„Big Bang“ – genau ein Liefertermin zur Produktivsetzung
...so dass die Qualitätssicherung sehr stark auf einen einzigen Zeitpunkt ausgerichtet war.
Damit wurde eine starke Verdichtung der gefundenen Fehler und der erforderlichen
Korrekturen auf diesen Liefertermin hin riskiert.
Agile Methoden zur Risikominderung:
Iterativ-inkrementelle Entwicklung mit Auslieferung an Fachtest
 Zum Ende jeder 4-Wochen-Iteration wurden die jeweils neu implementierten
Migrationsanforderungen auf Mapping- und Fachtestumgebungen ausgeliefert.
 Durch diese Testverbuchungen mit anschließender Verifikation wurde der inkrementelle
Projektfortschritt regelmäßig und zuverlässig überprüft.
 Wohl-definierte Regressiontests stellten sicher, dass die Qualität früher implementierter
Anforderungen erhalten blieb.

27
Umfangreichen Anforderungsänderungen bei Festpreisvertrag
...so dass das Risiko von erhöhten Projektkosten durch Scope Creep oder „Verwaltungs-
Blindleistung“ bestand.
Agile Methode zur Risikominderung:
Product Backlog in Kombination mit klassischen Change Requests nach einer Baseline
 Um die Implementierung annähernd fristgerecht beginnen zu können, ohne dass die
Anforderungsspezifikationen fristgerecht freigegeben waren, musste das Migrationsteam
verschiedenste Annahmen treffen.
 Änderungen gegenüber der so durchgesetzten Baseline wurden generell als Change
Requests dokumentiert.
 Nach ihrer Freigabe im programmweiten Standardprozess wurden die Change Requests mit
allen anderen Anforderungen im Product Backlog streng priorisiert eingeordnet.
 Dieses Vorgehen reduzierte den Verwaltungsaufwand darauf, was auch die Erstellung der
entsprechenden „User Story“ erfordert hätte. Zudem entkoppelte es das Migrationsteam von
den Verhandlungen darüber, was Scope Creep gewesen wäre und was nicht.

28
Kopfmonopole – teilweise mit stark autokratischem Führungsstil
Einzelne Teammitglieder verfügten über kritisches Know-How und diktieren allen anderen ihre
technische Lösungen und Vorgehensweisen. Erstere waren chronisch überlastet, die
anderen Teammitglieder demotiviert und die Leistungsfähigkeit des gesamten Teams litt.
Agile Methoden zur Linderung:
Selbst-organisierende Teams und direkte Kommunikation in Kombination mit der
klassischen Methode ungeeignete Mitarbeiter auszutauschen
 Die Mitarbeiter des Migrationsprojektes wurden nach den zu migrierenden Produkten in drei
Teams organisiert. Alle Teammitglieder planten zu Beginn jeder 4-Wochen-Iteration
gemeinsam die Aufgaben und stimmten sich täglich in ~15-minütigen „Standups“ ab.
 Mindestens einmal vor jeder 4-Wochen-Iteration fand ein Anforderungs-Workshops pro
Produkt statt, bei dem sich die an diesem Thema arbeitenden Kollegen – auch von anderen
Standorten – für einen Tag zusammensetzten.
 Ein Mitarbeiter, der seine Vorstellungen immer wieder heimlich und durch Überschreitung
seiner Befugnisse durchzusetzen versuchte, und häufig lautstark mit verschiedenen
Teamkollegen stritt, musste ausgetauscht werden.

29
Erschwerte Qualitätssicherung 1 – Entwicklung und Test getrennt
Organisatorisch war vorgegeben, dass nicht nur der Fachtest, sondern auch der
Mapping-/Integrationstest für die Migration durch ein eigenes Testprojekt geleistet wurde.
Dadurch wurden viele Fehler erst nach Übergabe vom Migrations- an das Testprojekt
gefunden.
Agile Methode zur Effizienzsteigerung:
Collocation
 Für die Arbeit an der besonders komplexen Krankenhaus-Migration zogen Mitarbeiter aus
Migration, Fachbereich und Test von mehreren Standorten für die letzten vier Monate der
Entwicklung nebeneinander in ein Großraumbüro.
 Dadurch wurden potentielle Fehler über Projektgrenzen hinweg schnellstmöglich
besprochen und ggf. mit einer bereits abgestimmten Lösung zur Entscheidung vorgelegt.

30
Erschwerte Qualitätssicherung 2 – keine Kontinuierliche Integration
Dem Migrationsprojekt stand nur eine Integrationstest-Umgebung zur Verfügung und als
zentrales Entwicklungstool unterstützte DataStage keine interne Versionsverwaltung und
kaum Testautomatisierung, so dass sich Kontinuierliche Integration als eine der wichtigsten
Agilen Methoden nicht umsetzen ließ.
Plan B zur Vorbeugung von geballt auftretenden Integrationsproblemen und zum Monitoring
der Produktreife: Viel manuelle Arbeit unter strenger Prozesskontrolle und etwas UC4
(Jobsteuerung)
 Zentrale Versionsverwaltung mit Subversion sowie strenge Definition und Überwachung der
Prozessschritte beim Check-in, um zu verhindern, dass sich Entwickler mit Codeänderungen
gegenseitig blockierten.
 Mindestens wöchentlicher Haupt-Build, der auf Zuruf – unter Angabe neuer Tags – gestartet
wurde, nachdem Entwickler mit den Tags eigene Builds durchgeführt und getestet hatten.
 Begrenzte Automatisierung der Migrationsabläufe mittels UC4. Dadurch wurde auch den
strengen Zugriffsbeschränkungen auf Test- und Produktivsystemen entsprochen.
 Ausführung und Überwachung der UC4-Skripte durch eigens dazu abgestellte Mitarbeiter.

31
Agenda

Selbstkritische Reflexion
 Der Erfolg gibt uns Recht, ….
– Wir haben sämtliche Meilensteine erfolgreich erreicht
– Die Systeme sind produktiv und stabil im Einsatz
– Der Kunde ist zufrieden
– Das Programm war profitabel
 … oder?
– Wir hatten auch Glück und „gute“ Umstände
– Wir sind auf einen „gutmütigen“ Kunden getroffen
– Jede noch so gute Methode lebt von den Menschen
(Wir hatten die „richtigen“ Menschen an Bord … nicht nur IBM)
– Was ist ein Fehler und was ein Change
– Umgebungs- und Daten-Management wird immer unteschätzt
– Und am Ende die User-Akzeptanz noch „ALLES“ verhageln
– Nachlässigkeiten werden sofort bestraft
… Traue „KEINEM“ vorgegebenen Termin
32

33
Reinhard Borosch
IBM Global Business Services
Senior IT Architect (Insurance)
D-50968 Köln
Mobil: 49-(0)170-9106116
Mail: reinhard_borosch@de.ibm.com
Kontakt
Dr. Oliver Klapp
IBM Global Business Services
Executive Project Manager
D-50968 Köln
Mobil: 49-(0)175-1868503
Mail: oliver.klapp@de.ibm.com

34
FRAGEN

Anhang

36

Go bis firo_komplexesprogram_und_agilespm_v021_zurverteilung

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Empfohlen

Empfohlen (20)

Go bis firo_komplexesprogram_und_agilespm_v021_zurverteilung

Hinweis der Redaktion