Sok cégnél, különösen a biztosítási szektorban, van egy rendszer, amiről mindenki tudja, hogy elavult, mégis évek óta ugyanazzal dolgoznak. A felület réginek tűnik, az adatok szétszórtan élnek, az új funkciók beépítése egyre nehezebb és lassabb — de a rendszer cseréje ijesztő, kockázatos és drága projektnek tűnik, ezért inkább halasztódik.
Ez a halogatás érthető, de van ára. Egy elavult, alulfejlesztett értékesítési portál lassítja az értékesítési folyamatokat, rontja az ügyfélélményt, és minden új funkció vagy integráció egyre nehezebben illeszthető rá. A kérdés idővel nem az, hogy szükség van-e változásra, hanem hogy mikor és hogyan érdemes belevágni.
Ez a probléma nem korlátozódik a biztosítási szektorra, bár ott gyakran a legszembetűnőbb — a hosszú termékéletciklusok és a szabályozási környezet miatt sok biztosítónál évtizedes rendszerek húzódnak a háttérben. Ugyanez a minta megjelenik bármely olyan iparágban, ahol a vállalat gyors ütemben nőtt, miközben az informatikai háttere nem tartott lépést ezzel a növekedéssel.
Miért halasztódik ez a döntés annyira gyakran?
A legtöbb vezető pontosan tudja, hogy a rendszer elavult — mégis évről évre tovább tolódik a döntés. Ennek több oka is van. Egyrészt a csere gondolata azonnal egy nagy, kockázatos, hónapokig vagy évekig tartó projektet idéz fel, amihez nehéz megtalálni a megfelelő időpontot: mindig van egy fontosabb, sürgősebb feladat. Másrészt a régi rendszer, minden hibája ellenére, működik — ez a fajta "ha nem romlott el teljesen, minek nyúlj hozzá" gondolkodás sok helyen tartja fenn a status quo-t. Harmadrészt gyakran hiányzik a belső kapacitás vagy szakértelem ahhoz, hogy valaki alaposan felmérje, mi is lenne a helyes irány — csere, modernizáció, vagy csak egy-két kritikus pont javítása.
Eközben a rendszer minden egyes évvel nehezebben karbantartható lesz. A fejlesztők, akik ismerik a régi technológiát, egyre nehezebben találhatók a piacon. Az új funkciók beépítése egyre több munkaórát emészt fel, mert a régi architektúra nem lett ilyen bővítésekre tervezve. És minden halasztott döntéssel nő a kockázat, hogy egy váratlan hiba vagy egy szabályozási változás kényszeríti ki a lépést — a legrosszabb pillanatban, felkészülés nélkül.
Csere vagy modernizáció?
Nem minden legacy rendszernél a teljes csere az egyetlen út. Van, amikor egy meglévő rendszer fokozatos modernizálása — a felület megújítása, az adatstruktúra rendezése, új funkciók hozzáadása a meglévő alapokra — pontosan azt az eredményt hozza, amire szükség van, jóval kisebb kockázattal és rövidebb átfutási idővel, mint egy teljesen új rendszer felépítése.
Egyik megoldás sem eleve jobb a másiknál — a helyes válasz mindig az adott rendszer állapotától és a cég céljaitól függ. Máskor viszont a meglévő architektúra annyira korlátozza a fejlődést, hogy a hosszú távon költséghatékonyabb megoldás egy új alapokra épülő rendszer — még ha ez elsőre nagyobb beruházásnak is tűnik. Ha minden új funkció aránytalanul sok munkát igényel a régi struktúra korlátai miatt, vagy ha a rendszer technológiai alapja már nem támogatott, a toldozgatás hosszú távon drágább lehet, mint egy jól megtervezett újraépítés.
A helyes válasz mindig az adott helyzettől függ, és ezt egy alapos felmérés nélkül nem lehet eldönteni. Ezért minden ilyen projekt egy discovery és igényfelmérési szakasszal kezdődik, ahol a cél nem az, hogy a lehető legnagyobb projektet ajánljuk, hanem hogy a legköltséghatékonyabb megoldást találjuk meg, ami valóban megoldja a problémát.
Egy konkrét referencia
Az egyik magyar biztosítótársaságnál egy elavult, alulfejlesztett értékesítési portált modernizáltunk: kortárs felhasználói felülettel, új funkciókkal és rendezettebb adatkezeléssel láttuk el, ami közvetlenül támogatja az értékesítési folyamataikat. A projekt körülbelül egy évig tartott, a pontos időtáv a terjedelemtől és komplexitástól függően változik.
A projekt minden lépésénél a konzultatív megközelítést alkalmaztuk: nem azt néztük, mi lenne a technológiailag legizgalmasabb megoldás, hanem azt, hogy melyik út viszi el legmegbízhatóbban és legköltséghatékonyabban a kívánt eredményhez. Ez a fajta modernizációs munka jelenleg is aktívan fejlődő szolgáltatási területünk — folyamatosan bővítjük a tapasztalatunkat ezen a téren, az értékesítési portál projekt pedig a kiindulópontunk és zászlóshajó referenciánk.
Mennyibe kerül valójában a halogatás?
A halogatás költsége ritkán jelenik meg egyetlen soron egy költségvetésben, ezért könnyű alábecsülni. Valójában több helyen is jelentkezik: a fejlesztők és üzemeltetők egyre több időt töltenek azzal, hogy a régi rendszer korlátai között próbálnak megoldásokat találni; az új funkciók vagy szabályozási megfelelések bevezetése egyre tovább tart, mert a rendszer nem lett ilyen változásokra tervezve; és az ügyfélélmény romlása — egy lassú, nehézkes portál — hosszabb távon az értékesítési eredményekre is hatással lehet.
A biztosítási szektorban ehhez gyakran társul egy további réteg: a szabályozási környezet folyamatosan változik, és egy rugalmatlan, elavult rendszer nehezebben tud alkalmazkodni az új megfelelési követelményekhez. Minél tovább halasztódik a modernizáció, annál nagyobb eséllyel egy szabályozási határidő kényszeríti ki a lépést — jellemzően rosszabb feltételek mellett, mint amikor a cég saját ütemezésében, felkészülten vág bele a projektbe.
Milyen jelekre érdemes figyelni?
Néhány visszatérő jel, ami arra utal, hogy itt az ideje foglalkozni a kérdéssel: az ügyfelek vagy a belső munkatársak rendszeresen panaszkodnak a rendszer lassúságára vagy nehézkességére; egy új funkció beépítése hetekbe vagy hónapokba telik, ami korábban napok alatt megoldható lett volna; egyre nehezebb olyan fejlesztőt találni, aki ismeri a rendszer mögötti régi technológiát; vagy az adatok annyira szétszórtan élnek, hogy egy egyszerű riport elkészítése is több rendszerből való kézi adatgyűjtést igényel.
Ha ezek közül több is ismerősen hangzik, érdemes minél előbb, még nyugodt körülmények között elkezdeni a felmérést — nem akkor, amikor egy váratlan hiba vagy egy szabályozási határidő már kényszerhelyzetbe hozza a céget.
Hogyan néz ki egy ilyen projekt felépítése?
A folyamat mindig discovery-vel és igényfelméréssel indul, amit a megoldás megtervezése követ — ilyenkor konzultatív módon azt javasoljuk, ami a legköltséghatékonyabban éri el a kívánt eredményt. Ezután következik a fejlesztés (jellemzően Angular frontend, Java backend, de a technológia rugalmasan igazodik az adott projekthez), a tesztelés, végül az átadás és a dokumentáció.
Mit érdemes elvárni egy discovery szakasztól?
Egy jól felépített discovery szakasz nem csak a technológiai réteget vizsgálja, hanem azt is, hogyan használják a rendszert a gyakorlatban a napi munkatársak, hol keletkeznek a leggyakoribb kézi megkerülő megoldások, és melyik funkciók azok, amik ténylegesen értéket teremtenek az üzleti oldalon. Ez a fajta alapos felmérés az, ami megkülönbözteti egy konzultatív megközelítést egy olyan fejlesztőtől, aki egyszerűen leprogramozza, amit elsőre kérnek tőle — anélkül, hogy megkérdőjelezné, valóban ez-e a legjobb út.
A discovery szakasz végén egy világos javaslat születik: mi a probléma pontos gyökere, milyen megoldási irányok jöhetnek szóba, és ezek közül melyik hozza a legjobb arányt a befektetett erőforrás és az elért üzleti eredmény között. Ez a javaslat az alapja a további tervezésnek — a cégvezetés így nem egy homályos "informatikai projektbe" vág bele, hanem egy konkrét, indokolt üzleti döntést hoz.
Gyakran felmerülő kérdések
Mennyi ideig tart egy ilyen projekt?
Ez erősen függ a terjedelemtől és a komplexitástól — egy teljes portál-modernizáció akár egy évig is tarthat, míg egy szűkebb, célzottabb fejlesztés lényegesen rövidebb idő alatt megvalósítható.
Biztosítási szektoron kívül is releváns ez a szolgáltatás?
Igen — bár a biztosítási szektor az eddigi legerősebb referenciánk, az elavult, alulfejlesztett rendszerek problémája iparágtól függetlenül ugyanúgy jelentkezik, és a megközelítésünk ugyanúgy alkalmazható más szektorokban is.
Mi van, ha nem tudjuk eldönteni, hogy cserére vagy modernizációra van szükségünk?
Pontosan ez a discovery szakasz célja — nem szükséges előre eldönteni, melyik irány a helyes, hiszen ez a felmérés eredménye lesz, nem az előfeltétele.
Mi történik, ha a discovery szakasz azt mutatja, hogy egy kisebb beavatkozás is elég lenne?
Ez a legjobb kimenetel a cég szempontjából, és pontosan ez a konzultatív megközelítés lényege: nem azt javasoljuk, ami a legnagyobb projekt, hanem azt, ami a leginkább megéri. Ha egy célzottabb, kisebb léptékű fejlesztés is megoldja a problémát, ezt fogjuk javasolni egy nagyobb, indokolatlan projekt helyett.
Milyen kockázatai vannak egy modernizációs projektnek, és hogyan kezelhetők?
A legnagyobb kockázat jellemzően az, hogy a modernizáció közben a napi működés fennakadás nélkül folytatódjon. Ezért a projektek jellemzően fázisokban épülnek fel, ahol az egyes lépések tesztelhetők és visszaforgathatók, mielőtt a következő szakasz elindulna — így a kockázat fokozatosan, kezelhető lépésekben csökken, nem egyetlen nagy, visszafordíthatatlan váltással. Ez a fázisos megközelítés azt is lehetővé teszi, hogy a cégvezetés minden szakasz után újraértékelje a projekt irányát, és szükség esetén finomítson a terven, mielőtt a következő, jellemzően nagyobb beruházást igénylő fázis elindulna.
Miért érdemes időben, nem kényszerből belevágni?
Van egy jelentős különbség aközött, hogy egy cég saját elhatározásából, felkészülten kezd bele egy modernizációs projektbe, vagy egy külső kényszer — egy súlyos hiba, egy szabályozási határidő, egy elvesztett ügyfél — hatására kénytelen lépni. Az első esetben van idő alaposan felmérni a helyzetet, több megoldást mérlegelni, és a legköltséghatékonyabb utat választani. A második esetben a döntéshozatal ideje összeszűkül, a választási lehetőségek beszűkülnek, és jellemzően drágább, kapkodóbb megoldások születnek.
Ez az egyik legerősebb érv amellett, hogy a modernizáció kérdését ne akkor kezdje el vizsgálni egy cég, amikor már nyilvánvaló válsághelyzet van, hanem jóval korábban, amikor még nyugodt körülmények között lehet megalapozott döntést hozni.
Összegzés
Ha a cégeteknél is van egy rendszer, amiről sejtitek, hogy ideje lenne foglalkozni vele, de nem vagytok biztosak benne, hogy csere vagy modernizáció a jó irány — érdemes ezt egy discovery beszélgetéssel kezdeni, mielőtt a döntést egy váratlan probléma kényszeríti ki.
Egy alapos felmérés nem kötelezi el a céget semmilyen konkrét irány mellett — csupán tiszta képet ad arról, hol tart most a rendszer, és milyen utak állnak nyitva előre, hogy a döntés végül tényeken, ne találgatáson alapuljon.