Generali migrációs projekt
Közös nevezőn
A Generali Providencia Biztosító Zrt. végfelhasználói talán csak annyit vettek észre, hogy az eddigi számítógépes rendszer megbízhatóbbá vált. A háttérben azonban komoly átállások, fejlesztések zajlottak és zajlanak. Ezekről beszélgettünk Nick Gábor András rendszerfejlesztési osztályvezetővel, aki menedzsment szinten foglalkozik az említett átállással, illetve az IBM munkatársával, Balogh Péterrel, aki az IBM-en belül koordinálta a szakmai előkészítést.
„A Generali már régóta használ folyamattámogatási rendszert az ügyvitelben tevékenykedők, így többek között a kárszakértők vagy például az ügyfélszolgálatosok munkájának könnyítésére” – kezdi némi előtörténet felvázolásával Nick Gábor András, rendszerfejlesztési osztályvezető. „Hogy mindez minél megbízhatóbb elektronikus formában történjen, már évekkel ezelőtt bevezettük az IBM MQ Workflow nevű termékét. Ezzel párhuzamosan természetesen szükség volt a háttérrendszerekkel való kapcsolat biztosítására is, amire viszont egy saját fejlesztésű eszközt, az EDS-t használtuk, a frontend alapjául pedig a nyílt forráskódú Tomcat szolgált. Nagyjából két évvel ezelőtt már világossá vált, hogy érdemes egyetlen termékcsaládban gondolkoznunk, ezért teljes egészében az IBM világ felé fordultunk.”
„Amellett, hogy a Generalinál több téren is esedékessé vált a technológiaváltás, felerősödött a törekvés, hogy az üzleti igények rugalmasabb, hatékonyabb és gyorsabb kiszolgálása érdekében a biztosító elinduljon a SOA (szolgáltatásorientált architektúra) irányába” – veszi át a szót Balogh Péter. „Ráadásul nagyjából ez idő tájt váltak érezhetővé a cég saját fejlesztésű middleware-jének (EDS) funkcionális korlátai is, ezért szinte magától adódott a döntés: az EDS-t az IBM Message Broker alkalmazásával kell leváltani. Ez utóbbi révén könnyebben és gyorsabban integrálhatók a meglévő rendszerek, ami azért is különösen fontos a Generali esetén, mert itt rendkívül homogén az infrastruktúra: iSeries-en futó RPG, illetve zSeries-en levő PL1 rendszerektől az SAP-n keresztül a korszerű Java és .NET alkalmazásokig, eltérő platformú rendszerek funkcionalitását kell összehozni egyetlen egységes szolgáltatásfelületen.
- Mennyi időt vett igénybe az EDS lecserélése? – fordulok ismét az osztályvezetőhöz.
- Az EDS kiváltása, mondhatni, mintaértékű volt, hiszen gyakorlatilag néhány hónap alatt sikerült áthelyezni a tranzakciók többségét a Message Brokerre, ráadásul a fejlesztési hatékonyság is sokat javult. Míg korábban a fejlesztési kisfeladatok elvégzése általában 5-7 napig tartott, ugyanezek az új rendszerben gyakorlatilag 1-3 nap alatt elkészülnek. Ugyancsak sikerült javítani a központi komponens (a middleware) és a front end rendelkezésre állásán, így míg korábban havonta akár egyszer-kétszer is előfordultak leállások, az új rendszerben eddig nem történt ilyen.
Ezután a másik fontos rész, a workflow, a folyamatmotor kerül szóba. Az MQ Workflow-t már csak azért is le kellett cserélni, mert az IBM 2007-ben megszüntette ennek támogatását, és helyette egy új, fejlettebb rendszert vezetett be, a Websphere Process Servert. Ezzel egyidejűleg a Generali az üzlettel való együttműködést is magasabb szintre kívánta helyezni, ezért nemcsak a workflow-t cserélte le, hanem egyúttal egy teljes BPM (Business Process Management) megoldás bevezetését tűzte ki célul. Az új rendszerben tulajdonképpen az üzleti folyamatok teljes életciklusát végig tudják követni, illetve optimalizálni tudják a folyamatokat. Mindez lehetővé teszi, hogy üzleti oldalról is értékeljenek egy-egy folyamatot, megkeressék benne a szűk keresztmetszeteket, lássák a problémás területeket, találjanak optimalizálási lehetőségeket. Ha mindez megtörtént, újra lehet implementálni a workflow-ba a szóban forgó folyamatot, és megint lehet figyelni, hogy milyen eredményt sikerült elérni.
„Ha önmagában csak az informatikai eszközöket változtatjuk meg, az a vállalat egésze szempontjából nem vezet eredményre, nem lesz olyan hatékony, mint ahogy azt elvárnák tőle” – ad magyarázatot az osztályvezető arra, hogy miért is olyan összetett, sokrétű feladat az átállás. „Lényeges, hogy először az üzleti oldal vegye górcső alá a folyamatait, ha kell, akkor optimalizálja (erre megvannak a megfelelő módszerek), és csak a már letisztult, a felesleges terhektől megszabadított folyamatokat valósítsuk meg az új rendszerben.
- Mennyit vesznek észre a felhasználók abból, hogy a háttérben új rendszer dolgozik?
- Bár a háttérfolyamatok nagyon megváltoztak, ezek bizonyos szintig rejtve vannak a felhasználók elől. Leginkább persze azon végfelhasználók elől, akik a monitor előtt ülve dolgoznak a szolgáltatásokkal. Ők a megnövekedett stabilitáson túl, legfeljebb annyit tapasztalnak a megszokott felületeken, hogy az optimalizáció következtében bizonyos feladatok tovább egyszerűsödtek. Van viszont a felhasználóknak egy másik csoportja is, akiket én „megrendelőknek” hívok. Ők azok, akik az üzleti oldalról tervezik meg a folyamatokat, és megmondják az informatikának, hogy mit is szeretnének. Ha valahol, akkor ezen a területen lényeges változás történt, ugyanis ezek a „megrendelők” immár aktívan részt vesznek mindenben. Valójában nem is egy, hanem két nagy projektről beszélhetünk. Van egy informatikai projekt, aminek az alapvető motivációiról már szó volt, de ezzel párhuzamosan az üzleti oldal is rájött arra, hogy a folyamataik már nem elég hatékonyak, és ezen változtatni kell. Nyilván mindkét oldal önmagában is fejleszthet, de, mint említettem, az igazi sikert az hozza meg, ha megtalálják a közös nevezőt. Éppen ezt könnyíti meg az IBM termékportfóliója, hiszen az üzleti folyamatok tervezői a megfelelő modellezéssel maguk is aktívan részt vehetnek a fejlesztésben. Úgy is szoktam mondani, hogy az üzleti rész kezdi írni a könyvet, megírja a fejezetcímeket, átadja az informatikának, amelyik kitölti szöveggel ezeket a fejezeteket. Nagyon lényeges és persze előnyös, hogy mindkét oldal ugyanazt a dokumentumot fejleszti, így végre nem tudnak elveszni információk.
- Hol tart most a migrációs projekt?
- Jelenleg van már egy olyan folyamat, amelyet teljes egészéből áthoztunk a régi környezetből az új rendszerre, illetve van olyan, amelyet már kifejezetten az újra fejlesztettünk. Ez persze csak a kezdet, hiszen számtalan olyan projektünk van, amely vagy a migrációról, vagy a fejlesztésről szól. Ma már bátran állíthatjuk, hogy a két évvel ezelőtt választott megoldás működik, és jól döntöttünk, amikor 2007-ben erre az útra léptünk.