IT development v České pojišťovně – nová éra architektury a procesů David Škarka Česká pojišťovna a.s.
IT v ČP – nová éra architektury a procesů
Úvod Procesní řízení IT Business Architecture Board IT Enterprise Architecture IAA model pojišťovny Strategická platforma
2
IT v ČP – nová éra architektury a procesů
Úvod Procesní řízení IT Business Architecture Board IT Enterprise Architecture IAA model pojišťovny Strategická platforma
3
Úvod
ČP je velká firma •
Největší univerzální pojišťovna v České republice
•
Počet klientů 2,5 mil; 1,2 mil pojistných událostí za rok
•
Počet zaměstnanců 5600; počet uživatelů systémů 10 000
•
Počet hlavních obchodních míst 270
ČP prošla transformací •
Business transformace (změna základních procesů)
•
Centralizace řízení a procesů
4
Úvod
Změna podmínek IT
Pozice IT v ČP • GŘ ČP
•
Centralizace IS
•
Oddělení IT provozu a IT vývoje
• NGŘ Obchod
•
Jiné nároky na vývoj a provoz IT
• IT Provoz • 268
•
Jiný způsob řízení IT
• NGŘ ŽP a IT
• IT Vývoj ŽP • 133
ČP má velké IT •
535 lidí
•
40 projektů za rok
•
1500 liniových požadavků za rok
5
• NGŘ NŽP
• IT Vývoj NŽP • 115
• NGŘ …
• IT Arch • 19
IT v ČP – nová éra architektury a procesů
Úvod Procesní řízení IT Business Architecture Board IT Enterprise Architecture IAA model pojišťovny Strategická platforma
6
Procesní řízení IT
Proč ITIL? •
IT = množina poskytovaných služeb
•
Tyto služby jsou zákazníky vnímány jako nákladné, pomalé, netransparentní – celkově neefektivní
•
IT musí umět dodávat požadované služby v požadované kvalitě, v požadovaném čase za co nejnižších nákladů
•
IT musí umět reportovat o spotřebě zdrojů a o stavu služeb
•
IT musí umět plánovat spotřebu zdrojů
Jedno z řešení je ITIL – best practice jak řídit IT služby
7
Procesní řízení IT
Jak na ITIL? •
Studie - Road map - postup zavádění procesního řízení IT ČP dle doporučení ITIL pro období 2006-2008
•
Procesy implementovat paralelně (izolované procesy nepřinášejí kýžený efekt – není synergie)
•
Podpora managementu (ne zcela jednoznačná záležitost pro odběratele IT služeb jako nutné účastníky řady procesů!)
•
Nástroj pro automatizaci procesů - Mercury ITG
•
Business vlastníci procesů
8
Procesní řízení IT
Jak na ITIL? •
Úroveň procesů sledována dle PMF (Process Maturity Framework): } Initial (Level 1) } Repeatable (Level 2) } Defined (Level 3) } Managed (Level 4) } Optimising (Level 5)
•
Rok 2008: úroveň: 2-3
•
Výzva pro IT ČP: certifikace dle ISO 20000 je naším dlouhodobým cílem
9
Procesní řízení IT
Zkušenosti •
Máme } Shodu na cílech rozvoje systému řízení IT } Realistický koncept rozvoje v konkrétní situaci IT ČP } Plán rozvoje a implementace procesů dle standardů ITIL
•
Change management } 1 ½ roku nasazen – omezen na IT vývoj a liniové požadavky } Příliš složité workflow – odrazuje od používání
•
Aktuálně implementujeme Service desk, Incident a Problem mngmt. a rozšíření ChM na provozní útvary
•
Pilotujeme Release mngmt
10
IT v ČP – nová éra architektury a procesů
Úvod Procesní řízení IT Business Architecture Board IT Enterprise Architecture IAA model pojišťovny Strategická platforma
11
Business Architecture Board
1) Porada vedení: Strategie a Vize firmy –hlavní cíle a cestu, jak docílit cílů, jasně specifikuje měřitelné cílové ukazatele
2) Business útvary: Jednotlivé úseky v gesci NGŘ doporučují prioritizované požadavky na realizaci do Business Architecture Board 3) Business Architecture Board: Vede Roadmap, navrhuje technické a procesní řešení, zajišťuje ocenění požadavků
12
Business Architecture Board
B út U S va IN ry ES
Business Architekti za jednotlivé NGŘ
BBB
BBI
IT Architekti
BII
Požadavek
Core IT řešitelé
ry va út
Business vlastníci, metodici
IT
S
BA – překlenutí sémantické mezery mezi core Business a core IT
III Dodaná funkčnost
Tvoří ideový záměr požadavku
Hledají synergie v rámci firmy
Tvoří high level procesní mapu
Provádí rozpad do procesních a funkčních celků Mapují požadavek na IT architektury
13
Řeší vývoj konkrétní části dle funkčních celků
Business Architecture Board
Role Business vlastník / Metodik •
Vlastník požadavku
•
Připravuje ideový záměr
•
Připravuje základní procesní mapu která požadavek jasně specifikuje
•
Navrhuje priority požadavku (schvaluje příslušný VŘ, v případě konfliktu NGŘ)
•
Zná detailní principy a procesy vlastněných aplikací / procesů
•
Akceptuje dodávku ve formě změněného procesu, funkčnosti nebo nové aplikace
14
Business Architecture Board
Role Business Architect •
Koordinuje scope požadavků NGŘ
•
Koordinuje SCOPE NGŘ s ostatními aktivitami v rámci ČP
•
Zajišťuje přehled o aktivitách v ostatních částech firmy
•
Zajišťuje kontinuální komunikaci s IT útvary
•
Doporučuje prioritu požadavků
•
Rozhoduje o předložení požadavku do BA Boardu
•
Spravuje aktuální priority list a Business Development Roadmap NGŘ
•
Figuruje v roli konzultanta při přípravě ideových záměrů a základního popisu procesů
15
Business Architecture Board
Zkušenosti •
Jsme na začátku!
•
Společnost přesvědčena o nezbytnosti role business architecture
•
Vydefinovány základní principy a procesy (vztah k Change Managementu, vztah k poradě vedení společnosti)
•
Obsazeny základní role (1 BA, 4 business vlastníci, 1 IT architekt)
16
IT v ČP – nová éra architektury a procesů
Úvod Procesní řízení IT Business Architecture Board IT Enterprise Architecture IAA model pojišťovny Strategická platforma
17
IT Enterprise Architecture
Mise IT architektů •
Zajistit návrh technického řešení v požadované a potřebné kvalitě s ohledem na vynaložené náklady, potřebu údržby a rozvíjitelnosti řešení
•
Zajistit lepší komunikaci mezi IT a business útvary
•
Konsolidovat pohled útvarů IT vývoj a IT provoz na efektivitu vynaložených investic
•
Řídit IT architekturu
18
IT Enterprise Architecture
Role IT architekt •
Snížení/zefektivnění nákladů na vývoj a provoz IS
•
Úzká spolupráce s BA a programovou kanceláří
•
Řízení standardizace aplikační, integrační, datové a infrastrukturní architektury
•
Sledování trhu IT a identifikace potenciálu využití nových trendů
•
Expertní podpora implementačních projektů
•
Udržuje informační model pohledů na architekturu IT systémů – aplikační portfolio
•
Provádí kontroly dodržování pravidel a standardů
19
IT Enterprise Architecture
Proces řízení architektury 1. Plánování architektury:
2. Implementace plánu:
• Definice cílové architektury
• Přímo zavádění nových platforem/komponent
• Definice preferovaných platforem
• Business projekty – návrh/oponentura řešení
• Road-map rozvoje architektury (as-is/to-be)
• Změnové řízení
• Ukazatele úspěšnosti
Plá nov ání
• Finanční zhodnocení
ce nta me ple Im
• Plán útlumu/náhrady aplikací
• Závazné koncepty/ standardy • Reportování 3. Kontrola/Audit: • Akceptace řešení – certifikace • Návrhy korekcí • Vstup do plánů IT
Audit
• Formální externí audit
20
IT Enterprise Architecture
Zkušenosti •
Společnost přesvědčena o nezbytnosti role IT enterprise architekt
•
Útvar IT architektury v přímé gesci NGŘ pro IT (tj. stejný level jako VŘ IT Provoz a IT Vývoj)
•
Vydefinovány základní principy a procesy (vztah k Change managementu, vztah k poradě vedení společnosti, BA Board)
•
Obsazeny základní role (3x Solution architekt, správce aplikačního portfolia)
21
IT v ČP – nová éra architektury a procesů
Úvod Procesní řízení IT Business Architecture Board IT Enterprise Architecture IAA model pojišťovny Strategická platforma
22
IAA model pojišťovny
Co je IAA model •
Informační, procesní a integrační modely - „best practice“ vývoje systémů pro pojišťovnictví
•
Informační architektura s detailním business obsahem – využití pro celopodnikové iniciativy i pro specifické oddělené projekty
•
Podklad pro detailní specifikace celopodnikové architektury IS
•
300 kumulativních let vývoje; vstupy mnoha vedoucích světových finančních institucí
•
Nabízí předdefinované business šablony pro specifikaci a návrh informačních řešení
23
IAA model pojišťovny
Co je IAA model? •
Jednotný jazyk (business Terms) - odstraňuje sémantické bariéry mezi jednotlivými útvary
•
Pokrývá až 90% procesní a datové analýzy a požadavků na návrh systému
•
Modely jsou snadno upravitelné a rozšiřitelné pro pokrytí specifických požadavků
•
Modely mají jednotný základ: IAA Foundation Models - pomáhají při definici rozsahu projektu a při identifikaci závislostí mezi jednotlivými projekty
24
IAA model pojišťovny
25
IAA model pojišťovny
Co je IAA model? plan
Business development roadmap
Cíle Cíle společnosti společnosti
Business Business architektura architektura
Aplikační Aplikační architektura architektura
Infrastruktura Infrastruktura
Plán
Package
Aplikace
Platforma
Cíle
Proces
Aplikační modul
Prostředí
Ukazatele
Aktivita
Funkcional ita
Aplikační soubor
Business
Application development roadmap
Referenční model (IAA) 26
Infrastructure development roadmap
IAA model pojišťovny
Zkušenosti •
Feasibility Study: JOK PRO }
Pozitivní dopad na Requirement Management 66 požadavků <=> 16 duplicit 4 implementační závislosti
}
Požadavky namapovány na IAA funkční model
}
Existující funkcionality namapovány na IAA funkční model
}
Přímočarý design určující měněné či nově vyvíjené aplikace
27
IAA model pojišťovny
Zkušenosti JOK KCL
JOK PK / CCD Sales support
Market research
Communications
Intermediary compensation
Task manager
MPU Task manager
Customer relationship management
Event scheduler Channel management
JOK PRO New application processing / Quoting
Policy acquisition
28
IT v ČP – nová éra architektury a procesů
Úvod Procesní řízení IT Business Architecture Board IT Enterprise Architecture IAA model pojišťovny Strategická platforma
29
Strategická platforma •
Rok 2003 – projekt „JOK“ – Jednotná Obsluha Klienta •
Základ CRM – cíl: unifikace pohledu na klienta, smlouvy, pojistné události
•
Velká výzva Stav IT systémů – obraz stavu procesů – separátní systémy dle oblastí (mnohdy i dle produktů); různorodá architektura
•
Řešení Vybudovat moderní, snadno rozšiřitelnou a udržovatelnou platformu
•
Implementace strategické platformy – Partneři: Accenture, Softec, Cleverlance, Raventia Od roku 2004 Softec (J2EE) a Raventia (DB)
30
Strategická platforma •
– není to jen technologie Specializovaný tým pro rozvoj a podporu, portfolio dodavatelů
Standardizované řízení procesu vývoje
Organizace
Procesy
Metody a standardy
Nástroje Model oriented (MDA), process modeling, metatools
Kontrolované a vyžadované
Architektura
Infrastruktura
J2EE, BEA, Service Oriented, Unifikované GUI
Unifikovaná a sdílená
31
Strategická platforma
Pravidla a standardy
Organizace
Procesy
+ • • •
Unifikace architektury, vývoje a provozu aplikací Zastupitelnost vývojářů a provozních administrátorů Jednotné procesy
Metody a standardy
Nástroje
Architektura
Infrastruktura
• • •
Tvorba, správa a rozvoj pravidel a standardů Kontrola dodržování pravidel (checklisty, codereview…) Přizpůsobování pravidlům a standardům – může být svazující
Definované standardy a pravidla vzhledu, chování a technologie budovaných aplikací umožnilo ČP vytvořit platformu, která svými nástroji výrazně podporuje rychlost a kvalitu vyvíjených aplikací v ČP
32
Strategická platforma
Cyklus vývoje aplikací Konec projektu
Migrace do Provozu
Codereview
Codereview
Migrace do Systém-testu
Začátek projektu
Počet aplikací a dodavatelů v ČP nutně vedl ke stanovení standardů a závazných pravidel a následně i kontrolních mechanismů určujících jak jsou dané standardy a pravidla dodržována.
33
Strategická platforma
Od programování k modelování • •
JOK FW 2.0: důraz na modelování - efektivita práce funkčního analytika a vývojáře Vytvořena „Vývojová linka“ (podpořená vývojovými nástroji)
Vývojář v nástroji SMC Modeller provede import modelu obrazovek
Funkční analytik pomocí nástroje Visual SMC Editor namodeluje obrazovky aplikace
Vývojář obohatí model obrazovek o technologické informace
Z modelu vygeneruje HTML demo, které konfrontuje se zadavatelem
Po doladění připomínek Z modelu se vygeneruje od zadavatele vygeneruje základ technické dokumentaci dokumentace
34
Z modelu se vygenerují artefakty potřebné pro běh aplikace
Strategická platforma
Zkušenosti •
5 týmů aplikačních podpor (dělení dle obchodních domén)
•
4 externí společnosti - core dodavatelé řešení nad JOK FW
•
Dedikovaný tým pro rozvoj a podporu JOK FW (ČP, Softec, Raventia)
•
Dedikovaný tým administrátorů BEA
•
Dedikovaný tým provozní podpory aplikací
•
15 aplikací pro koncové uživatele (35 komponent na integrační platformě)
•
V roce 2006 - 33 auditů a udělení 13 certifikátů o shodě řešení se standardy JOK FW
•
Není laciná záležitost => nutná periodická obhajoba
35
IT v ČP – nová éra architektury a procesů
36
