Článek přináší detailní pohled na výměnu core systému během transformace Directu.

Co je „core systém" a proč ho měnit

Core systémem tu nemyslíme datové úložiště, ale primární systém pojišťovny — živý systém, který vykonává procesy nad klíčovými entitami: smlouvou, partnerem, obchodníkem, škodou. Srdce provozu.

Direct první core zdědil. Po dlouhé diskuzi „koupit krabicové řešení, nebo vyvíjet vlastní" padlo rozhodnutí jít vlastní cestou — mimo jiné proto, že pro univerzální pojišťovnu prakticky neexistuje široká nabídka hotových produktů a krabicová řešení by si vynutila přizpůsobit byznys systému, ne naopak.

Prapůvodní ambice byla skromná: „Chceme to, co máme, jen rychlejší a stabilnější." Zděděný systém skoro nic nehlídal. Uživatelé mohli s minimálními validacemi měnit cokoliv. Postupem let se ale očekávání proměnilo: měl z toho být plnohodnotný informační systém s procesy, automatizací a digitalizací — a časem i potenciální produkt prodejný dál.

‍

Rozhodnutí: iterativně, ne „big bang"

Většina firem přistupuje k výměně jako k obrovskému projektu: dlouhá discovery, rozsáhlá analýza a design, dlouhý vývoj, pak adaptace a migrace. Roky do šuplíku, pak velký třesk.

My jsme se rozhodli vyvíjet jádro iterativně a inkrementálně — dopřát mu stejnou agilitu jako zbytku vývoje. Důvod byl prostý:

Každá vyvinutá část přinášela hodnotu hned. Když se zautomatizoval proces na změnu jména, telefonu nebo kontaktních údajů klienta, dalo se rovnou změřit, kolik času to první linii ušetří.

‍

Jak to konkrétně běželo

Když jsme v roce 2023 sestavili týmy podle byznysových segmentů, každý tým si vyvíjel svoji část core systému. Některé části byly společné (dokumenty, komunikační historie), jiné specifické — škoda pro likvidaci, smlouva pro správu, obchodník pro B2B. Každá část měla přidanou hodnotu, takže ji Product Owner mohl normálně prioritizovat.

Klíčové bylo přerámování pojmu „hotovo": jádro je v každém okamžiku hotové — a zároveň nikdy nebude úplně hotové, protože jsme nikdy neviděli cílovou „krabici". Až v roce 2025 jsme cíl přerámovali na hmatatelnější metu: až vypneme starý core — tedy až celá firma poběží v jednom novém systému.

‍

Rychlé nasazení = rychlá zpětná vazba

Nový core jsme dostali k uživatelům velmi brzy — kolem roku 2021–2022, ještě před value streamy. Uměl tehdy jedinou věc: vyhledat data. Ale to, co ve starém systému trvalo dlouhé minuty (a operátor na lince i klient na to čekali), zvládal za vteřiny.

Cena za to: uživatelé museli nějakou dobu obsluhovat dva systémy paralelně. Zisk: získali jsme systém, který šlo rozvíjet podle reálné zpětné vazby — a to je obrovský rozdíl oproti tomu, jak se takové systémy běžně dělají.

Příklad za všechny: v backlogu péče o klienta stálo „chceme umět automaticky změnit telefonní číslo". Ve starém světě to znamenalo ručně dohledat a přepsat čísla na všech smlouvách. Co duplicity? Co když má klient v systému číslo babičky a je potřeba ověření? Tyhle potřeby se sesbíraly, zrefinovaly, vyvinuly, nasadily — a uživatel je hned používal.

‍

Co nás to stálo — upřímně o reworku

Iterativní vývoj jádra má nevýhody a je fér je přiznat:

• Tím, že jsme chtěli dodat hodnotu brzy, jsme někdy nezvážili dost alternativ — pár věcí jsme vyvinuli sami, místo abychom zapojili hotová řešení z trhu.
• Některé komponenty jsme museli za běhu vyměnit — typicky BPM engine, na kterém dnes běžíme jiném než zpočátku. Tím, že jsme ji uměli vyměnit, jsme si zároveň ověřili, že to dokážeme.

Podíl reworku byl tedy větší, než kdyby se prošlo důkladnou up-front analýzou. Ale výměnou jsme každou iterací nasazovali přímo do systému, ve kterém poběží dlouhá léta — digitalizovali jsme firmu rovnou v cílovém systému, bez mezivrstvy.

‍

Srovnání s trhem: dvě cesty ke stejnému cíli

Tahle zkušenost vyústila ve veřejnou panelovou diskuzi o výměně core systémů, kde jsem reprezentoval agilní přístup vedle kolegy z Kooperativy, který zastupoval tradičnější, plánovaný. Není to souboj Waterfall vs. Agile — obě pojišťovny řeší stejnou úlohu a mají hodně společného. Ale kontrast je poučný:

‍

Zajímavé je, že konec obou cest může vypadat velmi podobně. Rozdíl je v tom, kdy uživatel dostane hodnotu — a jestli reflektujete jejich potřeby průběžně, nebo až podle plánu starého několik let.

‍

Pět věcí, které z toho stojí za zapamatování

1. „Hotovo, a přitom nikdy hotovo." Z každého nového core se časem stane legacy (životnost 20–30 let). Proto musí být modulární a počítat s výměnou komponent — a je potřeba aktivně pracovat s technickým dluhem (k tomu slouží pravidlo 50:30:20).
2. Pozor na vendor lock-in. Systém závislý na zastarávajícím dodavateli se těžko obnovuje.
3. Jádro samo o sobě hodnotu nedodá. Dokud do funkcionality nenavedete klienty přes web a mobil, je jádro jen třetina až polovina práce. (Tahle chyba — očekávání „až bude nový core, všechno se vyřeší" — nás stála nejvíc.)
4. Měřte hodnotu od první iterace. U nás se díky přechodu na lépe škálovatelnou architekturu (staré jádro bylo licencované podle jader databáze) začaly šetřit peníze hned od první iterace — a tenhle aspekt je dokonce součástí business case.

Technologie pro zajímavost: backend Java / Spring Boot, databáze PostgreSQL (zvolena brzy, ještě než byla mainstream), messaging RabbitMQ, frontend React i Angular podle aplikace. Jednotný tech stack držíme záměrně, aby šlo lidi rotovat mezi doménami bez učení nového stacku.

‍

‍