Az életbiztosítási évfordulós folyamat integrálása folyamatvezérlő rendszerbe

Tóth Máté (2018) Az életbiztosítási évfordulós folyamat integrálása folyamatvezérlő rendszerbe. Pénzügyi és Számviteli Kar.

	PDF NKP5KV.pdf Hozzáférés joga: Csak nyilvántartásba vett egyetemi IP címekről nyitható meg Download (1MB)
	PDF tóth máté titkosítási nyilatkozat.pdf Hozzáférés joga: Csak nyilvántartásba vett egyetemi IP címekről nyitható meg Download (256kB)

Absztrakt (kivonat)

Budapesti Gazdasági Egyetem Pénzügyi és Számviteli Kar Tóth Máté Gazdaságinformatika FOSZK Levelező Az életbiztosítási évfordulós folyamat integrálása folyamatvezérlő rendszerbe 2018   Tóth Máté Gazdaságinformatika FOSZK Levelező Beszámoló szakmai gyakorlatról 2018   Tartalomjegyzék Bevezetés 3 Az NN Biztosító rövid bemutatása 3 A gyakorlati idő alatt ellátott feladataim 4 Megismerkedés a biztosítóval 4 User story 6 Portfólió módosítás 7 Szeparátor QR kód 7 Lejárati folyamat 8 Pénzmosás elleni törvényi megfelelés 8 Összefoglalás 9 Mellékletek 9   Bevezetés A gazdaságinformatikai felsőfokú szakképzés szakhoz tartozó utolsó féléves szakmai gyakorlatomat, az NN Biztosító magyarországi központjában töltöttem. Ez számomra több szempontból is igen szerencsés, hiszen a mellett, hogy ez a jelenlegi munkahelyem, a munkaköröm is alkalmas szakmai gyakorlat teljesítésére. Ezen kívül a napi munkavégzésem során sok olyan feladattal, kihívással találkozok, amik elvégzéséhez vagy megoldásához hasznosítani tudom a tanulmányaim során szerzett tudásomat. A gyakorlati hely kiválasztása így teljesen egyértelmű volt számomra. Az NN Biztosító rövid bemutatása A mai NN Biztosító 1991-ben, zöldmezős beruházásként jelent meg Magyarországon Nationale-Nederlanden néven. Cégünk volt az első kizárólag életbiztosítást kínáló vállalat hazánkban. 1997-re piacvezetők lettünk a magyar életbiztosítási piacon, és ezt a pozíciót azóta is minden évben megőriztük. Az NN Biztosító számos kiemelkedően sikeres biztosítási és pénzügyi terméket vezetett be elsőként Magyarországon. Cégünk úttörő volt többek között a befektetéshez kötött életbiztosítások bevezetésében, a piacon elsőként nyújtottunk időseknek szóló garantált kibocsátású biztosításokat, és az elsők között jelentünk meg a piacon garantált kifizetést kínáló nyugdíjbiztosítással is. Az NN Biztosító 2001 és 2015 márciusa között az ING Csoport részeként ING Biztosító néven működött Magyarországon. Az ING Csoport 2014-es szétválásának következményeképpen az ING Csoport életbiztosítási üzletága világszerte NN név alatt folytatja működését, míg az ING Bank változatlan néven nyújtja tovább a banki szolgáltatásokat. 2015. április 1-től NN Biztosító néven, változatlan minőségben és elkötelezettséggel szolgáljuk ki ügyfeleinket. Cégünk termékei az életbiztosítások és hosszú távú megtakarítások széles skáláját ölelik fel. Kínálunk kockázati életbiztosítást, amellyel ügyfeleink gondoskodhatnak saját és szeretteik biztonságáról. Hagyományos biztosításaink segítségével hosszú távú, biztonságos megtakarítási lehetőséget ajánlunk biztosítási védelemmel. Befektetési egységekhez kötött életbiztosításainkhoz ügyfeleink számos eszközalap közül válogatva állíthatják össze egyéni befektetési portfóliójukat kockázatvállalási hajlandóságuknak megfelelően. Ezen termékeink elérhetőek forint- és euró-alapon egyaránt. Nyugdíjbiztosításaink garantált és befektetési egységekhez kötött formában is választhatók. Termékeink és szolgáltatásaink az országban bárhol elérhetőek. Mintegy 1300 szerződött partnerünk az érdeklődővel egyeztetett időpontban és helyszínen segít feltérképezni az egyéni igényeket, és megtalálni a megfelelő biztosítási védelmet, pénzügyi megoldást. A gyakorlati idő alatt ellátott feladataim Megismerkedés a biztosítóval Az NN biztosítónál eltöltött első hetem fő témája az ismerkedés volt. Mint minden új munkahelyen, új környezetben a kezdeti időszakban sok dologgal kell megismerkedni. Legelőször a Process Developpment Team tagjaival ismerkedtem meg, hiszen ez az a csapat, aminek én is a tagja vagyok. A csapat fő feladata a biztosító belső folyamatainak elemzése, fejlesztése. Munkánk, hogy a hatékonyság növelésével, automatizációk segítségével gyorsabbá és könnyebbé tegyük a biztosítón belüli társosztályok munkáját. A csapat egyike annak a négy agilis szoftverfejlesztői csapatnak, amelyek az integrált projektiroda keretein belül felelősek a biztosítón belüli informatikai fejlesztési projektek megvalósításáért. Az első hetekben a közvetlen felettesem bemutatott azoknak a kollégáknak, akikkel együtt fogok dolgozni a jövőben. Minden társosztályon külön bemutatkozós köröket szerveztek, amin nem csak én, de a velem együtt érkező többi új munkatárs is megismerhette a biztosítónál dolgozókat. Ezekben a napokban sor került a kötelező tűzvédelmi, biztonsági tréningek elvégzésére, és a munkaállomás, egyéb eszközök átvételére. Ezen kívül össze kellett gyűjteni, hogy milyen rendszereket fogok használni a munkám során, és ezekhez meg kellett igényelni a szükséges hozzáféréseket. Miután a munkavégzéshez szükséges eszközök és rendszer hozzáférések beállításra kerültek, a biztosító saját szabályzatában foglaltak szerint egy 3 napos biztosítási tanfolyamot kellett elvvégezni, amely átfogóan bemutatta a biztosítási ágazat működését, majd közelebbről az NN Biztosító tevékenységét. A tananyag kitért az NN Biztosító termékeire, értékesítési módszereinek bemutatására. Ezt követően munkatársaim segítségével elkezdtem megismerni a biztosítónál használ szoftvereket, környezetet. Az NN Biztosító alap szerződéskezelő rendszere a LIFE400 nevű biztosítási szerződéskezelő rendszer. Ennek a rendszernek a feladata a meglévő szerződésekkel kapcsolatos valamennyi adat, tranzakció tárolása és futtatása. Az ügyféladatok tárolása kezelése, díjak és árfolyamok számítása szintén a LIFE400-ban történik. A Cobol nyelvben íródott rendszer, holott nem nevezhető egy újszerű rendszernek, a biztosítók körében igen gyakran használatos, köszönhetően stabilitásának, és annak, hogy alapvetően biztosítási szerződések kezelésére írták. Ehhez a core rendszerhez kapcsolódik minden egyéb az NN Biztosítónál használt szakrendszer is, úgy mint az nn.hu oldalról elérhető NNDirect, a szerződött partnerek által használt CRM. A LIFE400 legacy rendszer és a többi szakrendszer közötti kapcsolatért a szintén IBM fejlesztésű JAVA alapú ESB (Enterprise Service Bus) rendszer a felelős. Ez a rendszer egyfajta út, átadó egység a többi rendszer között, ahova azok különböző szolgáltatásokat tudnak kiajánlani, onnan meghívni. A biztosító ügyfeleivel a szerződött partnereken keresztül, valamint leggyakrabban levélben érintkezik. A ügyfeleknek és minden egyéb szereplőnek (mint például a szerződött partnerek) kiküldendő levelek előállításáért, és karbantartásáért a HPE nevű rendszer a felelős. Ebben környezetben keletkeznek meg a LIFE400-ban tárolt adatok alapján a levelek, ugyanakkor, magában a HPE-ben is találunk üzleti logikákat a levelek kódjába írva. A szerződéskezelési osztály által a LIFE400 rendszeren kívül használt másik vastagklienses rendszer a TP2 (TouchPoint2), amely a szkennelt dokumentumok tárolására szolgál, illetve ebbe a rendszerbe kerültek kialakításra többek között a szerződéskezelési feladatokat támogató ügyviteli folyamatok is. A TP2 nem kapcsolódik sem közvetlenül, sem közvetve a LIFE400-hoz. A folyamatvezérlő vagy más szóval workflow management rendszer a JAVA alapokon felépülő PEGA. A PEGA egy a biztosító saját szerverén futó internetes böngészőből elérhető vékonyklienses rendszer, amely támogatja a folyamatok automatizálását. A dokumentumok tárolásáért a TP2-n kívül az Alfresco nevű rendszer is felelős. Az ismerkedést követően részt vettem az agilis, ezen belül is SAFe szoftverfejlesztési módszertan White Elephant elnevezésű eseményén. Ezen az eseményen részt vesz minden a csapatokban dolgozó fejlesztő, programozó elemző kolléga, azért, hogy a következő fejlesztési időszakra, ami jellemzően egy negyedév, vonatkozó fejlesztési igényeket megértsék, és meg tudják becsülni az azok megvalósításához szükséges időt. A fejlesztési igények a különböző üzleti területek adják be korábban, és az elemző kollégák a White Elephant előtt részletesen is kidolgozzák. Az igények összegyűjtését, rendszerezését, és az esemény lebonyolítását az elemzési vezető végzi. Erre az eseményre azért van szükség, hogy a negyedéves tervezésre előre meglegyen, nagyjából várhatóan melyik fejlesztés mekkora erőforrást igényel. Ezen információ birtokában tud a management priorizálni a beküldött igények között. Ezen az eseményen az én fő feladatom az igényekhez tartozó fejlesztői becslések rögzítése, összegzése volt, valamint a becslések során felmerült újabb kérdések továbbítása az üzleti területek felé. A későbbi negyedévekben részt vettem az igények előzetes elemzésében, tisztázásában is. User story Az agilis fejlesztési módszertan alapján a programozó, fejlesztő munkatársak User Story-k formájában kapják a fejlesztési feladatokat. Ezek a user story-k az üzleti igények részekre bontásai, rövid feladatleírások, melyeknek fejlesztési ideje nem haladhatja meg az aktuális fejlesztési sprint hosszát, ami jellemzően két hét. A White Elephant esemény után, részt vettem a következő negyedévre tervezett fejlesztési igények user story-kra bontásában, azok megírásában. Ebben az időszakban sok egyztetésen vettem részt mind a közvetlen kollégáimmal, elemzőkkel, mind azokkal, akik a társosztályokat képviselték. A user story-k pontos és egyértelmű megfogalmazása elengedhetetlen ahhoz, hogy a fejlesztése időben elkészüljenek. A következő nagy tervezési esemény, amin minden csapat részt vesz a negyedévente megrendezésre kerülő, két napos részletes tervezés, úgynevezett Process Increment vagyis PI. Ezen a kétnapos rendezvényen az agilis csapatok részletesen megtervezik hétről hétre a következő három hónap fejlesztési feladatait. Az előre elkészített user story-kra pontosabb becsléseket adnak, valamint feltárják a csapatok között lévő függőségeket és minden olyan kockázati tényezőt, ami hatással lehet a negyedéves tervek megvalósítására. Ezen az eseményen a fő feladatom, a user story-k értelmezésének segítése volt, hogy a kollégák minél pontosabb becslést tudjanak adni. Ezt követően a user story-kat az erőforrásoknak megfelelően sprintekbe kellett rendeznünk, majd vállalást tenni a leszállítandó új fejlesztésekre. A negyedéves tervezést követően a feladatom a következő tervezési ciklusra való felkészülés volt. Erre az időszakra kellett a beküldött újabb fejlesztési igényeket felmérni, és pontosítani, majd kidolgozni. Portfólió módosítás A Unit Linked biztosítási termékekhez kapcsolódó portfólió módosítási folyamat hatékonyabbá tétele, valamint integrálása az új PEGA rendszerbe, egy ilyen igény volt. Ennek a folyamatnak a részletes megértése, ábrázolása, és egyeztetése volt a következő feladatom. Ezt követően el kellett készítenem ennek az ügyviteli folyamatnak a PEGA-ban megvalósítandó folyamatát vázlatosan, hogy azt további egyeztetésekre lehessen vinni a társosztályokkal. Ennek a folyamatnak az ábráját az egyes számú mellékétel tartalmazza. Az egyeztetéseket követően, részletesen ábrázoltam a tervezett új folyamatot, valamint a csapat vezetőjével megfogalmaztuk a fejlesztéshez kapcsolódó user story-kat. A folyamat kidolgozásának részeként, át kellet fogalmazni az ügyfeleknek kiküldendő értesítő levelet is, melynek új szövegére és tartalmára én adtam javaslatot. További levél fejlesztési feladat volt a portfólió módosítási feladatok feldolgozásakor esetlegesen szükségessé váló hiánypótló vagy elutasító levelek szövegeinek megírása. Ehhez a korábbi években ilyen témában Az üzleti igények kapcsán dolgoztam a kedvezményezett és szerződő módosítási, évfordulós folyamat, visszapattanó e-mailek kezelésének folyamatának kidolgozásán. Szeparátor QR kód A portfólió módosítás folyamatának kidolgozását követően, egy érdekes problémára kerestem megoldást. Ez a probléma abból fakad, hogy az iratkezelési osztályon a dokumentumok szkennelésekor, a különálló dokumentumok közé szeparátorokat helyeznek. Ezeket a szeparátorokat a szkenner rendszere felismeri és minden ilyen esetben a szeparátor utáni oldalakat új dokumentumként menti el. A szeparátorok kis öntapadós címkére nyomtatott QR kódok, amik a következő információt hordozzák: NN|SEP000001, amelyben a szám egy inkrementálisan növekvő sorozat. A felmerülő probléma, a szeparátor címkék nyomtatásának rossz minősége volt, ami miatt sok esetben a szoftver nem tudta érzékelni a QR kódot. A kódokat egy speciális nyomtatóval készítették hosszú öntapadós szalagokra. Megoldásként létrehoztam egy olyan Excel makrót, ami egy előzetesen beállított számú szeparáló QR kódot képes készíteni. Ennek segítségével bármelyik nyomtatóval kinyomtathatóvá váltak a QR kódok, egy A4-es öntapadós lapra. A QR kódok egy mintája a kettes számú mellékletben található. Lejárati folyamat A Lejártai folyamat egy olyan része az operációs feladatoknak, aminek integrálása a PEGA rendszerbe a vége felé közeledett, amikor csatlakoztam a biztosítóhoz. Ennek ellenére a következő időszakban szinte csak és kizárólag ennek a folyamatnak a támogatásával foglalkoztam. Ez annak köszönhető, hogy bár a folyamat lépéseinek kialakítása, lefejlesztése megtörtént a PEGA rendszerben a fejlesztés után kezdődő UAT, felhasználói teszt közben a tesztelő erőforrás kiesett a csapatból. A tesztelési feladatok, úgy mint tesztesetek írása, azok futtatása, az eredmények ellenőrzése mind a munkám részét képezik. Ahhoz, azonban, hogy a tesztelést hatékonyan és eredményesen tudjam csinálni, a lejárati folyamatot is meg kellett ismernem, így sok időt töltöttem azon operációs kollégákkal, akik ezen a területen dolgoznak. A lejárati folyamattal kapcsolatosan előkerült hibák rendszerezését, kategorizálását és priorizálását szintén én csináltam, valamint a folyamat élesbe helyezése után felmerült éles hibák javításának koordinálását is. Pénzmosás elleni törvényi megfelelés A pénzmosás megelőzését segítő törvényi jogszabályok megkövetelik, hogy a biztosító minden azonosított ügyfelének személyi azonosításra alkalmas igazolványának másolatát, tárolja, valamit nyilatkoztassa ügyfeleit a pénzeszközeinek forrásáról. Ennek az ügyfél azonosítási folyamatnak a kialakítása nagyjából akkor kezdődött, amikor én a biztosítónál kezdtem dolgozni, és részben a megismerkedés miatt megkértek, hogy vegyek részt az ezzel kapcsolatos egyeztetéseken. A végleges folyamat kialakításában, ahogy azt a dolgozatom második részében lehet látni, sok csapat dolgozott összehangoltan. Én képviseltem a folyamatfejlesztésért felelős csapatot, így részt vettem ennek a folyamatnak a kialakításában. Összefoglalás Összefoglalásként szeretném összegezni, hogy a munkába állásom óta igen sok változatos feladatot kaptam, sok különböző munkafolyamatban vettem részt. Az NN Biztosítóval való megismerkedést követően, a tervezési, tervezés előkészítésével kapcsolatos feladatokba vonódtam be, később folyamat átalakításokkal foglalkoztam. Manapság pedig a lejárati folyamat támogatása a fő tevékenységem. Biztos vagyok benne, hogy a jövőben is hasonlóan változatos, és izgalmas munkát végezhetek majd az NN Biztosítónál. Mellékletek 1. számú mellékélet, a portfólió módosítás új PEGA folyamata 2. számú melléklet, szeparátor QR kód   Tóth Máté Gazdaságinformatika FOSZK Levelező Záró dolgozat 2018   Tartalomjegyzék Bevezetés 3 Témaválasztás, dolgozat célja 3 Az NN Biztosító rövid bemutatása 3 Az integrál projektiroda, és az AGILIS módszertan 4 Az évfordulós folyamat 8 Jelenlegi folyamat leírása, szoftveres környezete, architektúrája 8 Lehetséges fejlesztési pontok a folyamatban, az új szoftveres környezet 13 Az új évfordulós folyamat 14 A pénzmosás elleni törvényi megfelelés új folyamata 20 Szerződött partneri látogatás során 21 Az NNDirekt online felületen keresztül 21 Azonosítás postai úton 23 Összefoglalás 23 Irodalomjegyzék 24 Mellékletek 25   Bevezetés Témaválasztás, dolgozat célja A gazdaságinformatikai felsőfokú szakképzés szakhoz tartozó utolsó féléves szakmai gyakorlatomat, az NN Biztosító magyarországi központjában töltöttem. Ez számomra több szempontból is igen szerencsés, hiszen a mellett, hogy ez a jelenlegi munkahelyem, a munkaköröm is alkalmas szakmai gyakorlat teljesítésére. Ezen kívül a napi munkavégzésem során sok olyan feladattal, kihívással találkozok, amik elvégzéséhez vagy megoldásához hasznosítani tudom a tanulmányaim során szerzett tudásomat. A gyakorlati hely kiválasztása így teljesen egyértelmű volt számomra. Ugyan csak az volt a záró dolgozat témájának kiválasztása, amely az NN Biztosító egyik jelenlegi szerződéskezelési folyamatának az áttekintése, elemzése, és megtervezése egy új folyamattámogató rendszerben. Ez a folyamat a biztosítási évfordulóhoz kapcsolódó szerződéskezelési folyamat, aminek átdolgozásán egyébként is dolgoztam. A folyamat fejlesztés és ezáltal a záró dolgozatom célja is, hogy a meglévő folyamatot egy új az automatizált folyamatokat jobban támogató folyamatvezérlő, workfolw szoftverbe ültessük át. A dolgozatban ugyanakkor szeretnék röviden kitérni az évfordulós folyamathoz kapcsolódó másik folyamatfejlesztési projektre is, mert az egy teljesen új eddig nem létező folyamat kiépítéséről szól, amiben nekem is volt szerencsém részt venni, és igen érdekesnek találtam. Ez nem más mint a pénzmosás elleni törvényi megfeleléshez tartozó folyamat. Az NN Biztosító rövid bemutatása A mai NN Biztosító 1991-ben, zöldmezős beruházásként jelent meg Magyarországon Nationale-Nederlanden néven. Cégünk volt az első kizárólag életbiztosítást kínáló vállalat hazánkban. 1997-re piacvezetők lettünk a magyar életbiztosítási piacon, és ezt a pozíciót azóta is minden évben megőriztük. Az NN Biztosító számos kiemelkedően sikeres biztosítási és pénzügyi terméket vezetett be elsőként Magyarországon. Cégünk úttörő volt többek között a befektetéshez kötött életbiztosítások bevezetésében, a piacon elsőként nyújtottunk időseknek szóló garantált kibocsátású biztosításokat, és az elsők között jelentünk meg a piacon garantált kifizetést kínáló nyugdíjbiztosítással is. Az NN Biztosító 2001 és 2015 márciusa között az ING Csoport részeként ING Biztosító néven működött Magyarországon. Az ING Csoport 2014-es szétválásának következményeképpen az ING Csoport életbiztosítási üzletága világszerte NN név alatt folytatja működését, míg az ING Bank változatlan néven nyújtja tovább a banki szolgáltatásokat. 2015. április 1-től NN Biztosító néven, változatlan minőségben és elkötelezettséggel szolgáljuk ki ügyfeleinket. Cégünk termékei az életbiztosítások és hosszú távú megtakarítások széles skáláját ölelik fel. Kínálunk kockázati életbiztosítást, amellyel ügyfeleink gondoskodhatnak saját és szeretteik biztonságáról. Hagyományos biztosításaink segítségével hosszú távú, biztonságos megtakarítási lehetőséget ajánlunk biztosítási védelemmel. Befektetési egységekhez kötött életbiztosításainkhoz ügyfeleink számos eszközalap közül válogatva állíthatják össze egyéni befektetési portfóliójukat kockázatvállalási hajlandóságuknak megfelelően. Ezen termékeink elérhetőek forint- és euró-alapon egyaránt. Nyugdíjbiztosításaink garantált és befektetési egységekhez kötött formában is választhatók. Termékeink és szolgáltatásaink az országban bárhol elérhetőek. Mintegy 1300 szerződött partnerünk az érdeklődővel egyeztetett időpontban és helyszínen segít feltérképezni az egyéni igényeket, és megtalálni a megfelelő biztosítási védelmet, pénzügyi megoldást. Az integrál projektiroda, és az AGILIS módszertan Informatikai üzleti elemzőként a fő feladatom az NN Biztosító belsős szoftver fejlesztési csapatainak támogatása. Ez többek között magában foglalja a folyamatok felmérését, megtervezését, az üzleti igények egyeztetését, rendszerezésé, összesítését. A fejlesztői csapatok az biztosítón belül felmerülő üzleti igényeknek megfelelő szoftverfejlesztési feladatokat látnak el, egy Projekt Management Office elnevezésű szervezeti egységen belül. Ebben a szervezeti egységben összesen 4 fejlesztői csapat dolgozik nem teljesen egymástól függetlenül, hiszen gyakran kell olyan projekteken dolgozniuk, amelyekben részben vagy egészben, de több csapat is érintett. A négy csapat ettől eltekintve külön meghatározott feladatokon dolgozik. A csapatok a következő összetételben állnak fenn: • Minden csapatban a vezetői feladatokat a Produc Owner látja el. Ő az aki a csapat által követett fejlesztési célokat, prioritásokat meghatározza. • Üzleti elemzők, a Product Ownerek munkáját segítik, részt vesznek a tervezésben, elemzésekben. • Scrum Masterek segítik a fejlesztő csapatok mindennapi munkavégzését, az agilis működéshez tartozó ceremóniák lebonyolítását. • Fejlesztők, akik a Product Owner, és az üzleti elemzők által készített User Story-k alapján a szoftverfejlesztési feladatokat látják el. • Tesztelők, az elkészül fejlesztések tesztelésében vesznek részt, gyakran nem csak egy adott csapathoz tartoznak. Az integrált projektirodán belül működő 4 fejlesztői csapat a SAFe agilis módszertan szerint végzi a munkáját. Erről a szoftverfejlesztési módszertanról szeretnék a következőkben egy rövid áttekintést nyújtani. Fontos kiemelni, hogy az NN Biztosítónál működő fejlesztői csapatok nem minden esetben a „tankönyv” szerinti módszertant alkalmazzák, sokszor találkozhatunk az erre a szervezetre jobban illeszkedő egyedi megoldásokkal. A SAFe a scrum fejlesztési módszertanon alapszik. A scrum egy olyan folyamat-keretrendszer, melyet már az 1990-es évek elejétől kezdve használnak a komplex termékfejlesztés kezelésére. A scrum nem egy folyamat és nem is egy technika, hanem inkább egy olyan keretrendszer, amely során különböző folyamatokat és technikákat lehet alkalmazni. A scrum keretrendszere scrum csapatokból, illetve ezekhez a csapatokhoz kapcsolódó szerepekből, eseményekből, tárgyakból és szabályokból áll. A scrum empirikus folyamatellenőrzési elméleten nyugszik, ami azt takarja, hogy tudás és a döntéshozás tapasztalatokon alapszik. A scrum iteratív, inkrementális megközelítést alkalmaz a kockázatcsökkentés és az előre jelzés optimalizálása érdekében. A scrum alapjait három pillér képezi: - Átláthatóság: azoknak, akik a folyamat eredményéért felelősek, a folyamat jelentős aspektusait látniuk kell. Ezeket az aspektusokat egy közös sztenderd alapján meg kell határozni, mivel ez biztosítja, hogy a résztvevők ugyanazt értik a látottak alatt. - Ellenőrzés: a scrum-ot használóknak gyakran meg kell vizsgálniuk a folyamatot és fel kell deríteniük a nemkívánatos elemeket. Az ellenőrzéseket nem szabad gyakran végezni, mivel az hátráltatná a munkát. - Alkalmazkodás: ha egy ellenőrzést végző személy észleli, hogy a folyamat bizonyos elemei eltérnek az elfogadottól, így a termék elfogadhatatlanná válik, akkor a folyamaton módosításokat kell végrehajtani. Ezeket a módosításokat minél előbb el kell végezni, hogy minimalizáljuk a még nagyon eltérést. A scrum csapatok köré szerveződik, amelyek általában egy product owner-ből, egy scrum master-ből és a fejlesztő csapatból állnak. A scrum csapatok önszerveződő, keretszfunkcionális csoportok. Az önszerveződő csapat általában arra fekteti a hangsúlyt, hogy minél jobban végrehatjsa a munkát, nem pedig arra, hogy megfeleljenek egy külső irányítás elvárásainak. A keresztfunkcionális csapatok úgy alakulnak meg, hogy meglegyen minden szükséges kompetencia a munka elvégzéséhez, ne kelljen csapaton kívüli erőforrást igénybe venni. A fejlesztő csapat olyan szakemberekből áll, akik azért dolgoznak, hogy egy késztermék jöjjön létre minden sprint végén. A sprint egy olyan meghatározott periódus, amely során egy bizonyos munkafolyamatot be kell fejezni (TechTarget, 2017). Keresztfunkcionalitás jellemzi a csapatot, mivel fontos, hogy a csapat rendelkezzen mindazon képességekkel, melyek a feladat végrehajtásához szükségesek. A scrum szerint a fejlesztő csapatot nem szabad részekre tagolni, illetve annak ellenére, hogy a tagok eltérő képességekkel rendelkeznek, a fejlesztés különböző területeire fókuszálnak, a felelősséget az egész csapat viseli. Ami a csapat létszámát illeti, általában a három főnél kisebb csoportok nem képesek igazán hatékonyan működni, ekkor alacsony az interakció foka, valamint ebben az esetben képességbeli problémák léphetnek fel. Amennyiben túl sok tagja van egy csapatnak, akkor a koordináció okozhat nehézséget és a komplexitás is növekszik, így kilenc főnél nagyobb csoportokat sem ajánlatos képezni. A scrum előír bizonyos eseményeket, melyeknek az a célja, hogy rendszerességet hozzanak a folyamatba, illetve hogy csökkentsék a szükségtelen találkozók számát. Az eseményeknek mindig van egy meghatározott időkeretük. Az időkeretet úgy alakítják ki, hogy meglegyen a megfelelő idő a feladatok elvégzésére, de ne töltsenek el felesleges időt a folyamattal, mivel az pazarlás. A scrum lelke az úgynevezett sprint. Az egész fejlesztési folyamatot felbontják folyamategységekre, melyeknek van egy saját időkeretük. Ezek az egységek a sprintek. Minden sprint esetén van egy speciális cél, amit el kell érni. A sprintek maximum egy hónap hosszúságúak lehetnek. A segítségükkel javul az egész folyamat előrejelezhetősége, ezáltal csökken a költségbeli kockázat is (Schwaber et. at., 2013). A scrum során kialakítandó termékre a rugalmasság a jellemző, melyet számos környezeti tényező befolyásol, például a rendelkezésre álló idő, a költség vagy a funkcionalitás. Emellett még hatással van a projektre a piaci intelligencia, az ügyfélkapcsolat, valamint a fejlesztői készségek is. A környezetre való reakció miatt a folyamat során gyakran változtatni kell a terméken. A scrum projektekre a következő pontok jellemzőek: - rugalmas termék – az elkészítendő tartalmat a környezet befolyásolja - rugalmas ütemterv – a terméket akár korábban vagy akár később is igényelheti a vevő a tervezettnél - kis csapatok – általában nem több, mint hat fő - egy projekten több csapat dolgozik - gyakori felülvizsgálat – a csapat munkáját olyan gyakran vizsgálják felül, mint amennyire azt a környezeti komplexitás és a kockázat megköveteli (általában 1-4 hetes ciklusok vannak) - együttműködés a csapaton belüli és kívüli érdekeltekkel - célorientált – minden csapat meghatározott célok elérésére törekszik A scrum módszertan előnyei: A hagyományos fejlesztési módszereket úgy tervezték, hogy csak a folyamat elején képes reagálni az esetleges változásokra. A scrum módszertan ezzel szemben az egész folyamat során rugalmas etéren. Olyan ellenőrzési mechanizmusokat építenek be a scrum projektekben, melyek képesek kezelni a változókat a folyamat alatt, ennek köszönhetően a szervezet bármikor képes a terméken változtatni, hogy a legmegfelelőbb produktum jöjjön létre a fejlesztés végére. A scrum egyfajta szabadságot biztosít a fejlesztők számára. Szabadon dolgozhatnak megoldásokon a projekt során, mivel változik a környezet, illetve a fejlesztők a folyamat során tanulnak is. A kis, kollaboratív csapatok meg tudják osztani a tacit tudásukat egymással a folyamat végzése alatt. A scrum egy kiváló tanulási környezetet teremt a résztvevők számára (Schwaber, 1998). Az évfordulós folyamat Jelenlegi folyamat leírása, szoftveres környezete, architektúrája Az életbiztosítási évfordulós folyamat célja, hogy az ügyfél az évenkénti biztosítási díj növeléséről tudomást szerezzen, és ezzel kapcsolatban nyilatkozatot tegyen. Ezt a nyilatkozat tételt, ahogyan látni fogjuk, megteheti önállóan is postai úton, vagy az úgynevezett szerződött partnereken keresztül. A biztosítóval szerződésben álló szerződött partnerek feladatai közé tartozik ugyanis a hozzájuk tartozó ügyfeleket felkeresése azok szerződéseinek évfordulója alkalmával, a meglévő szerződésállományuk ápolása. Ahhoz, hogy a jelenlegi folyamat leírását megkezdhessem, a teljesség igénye nélkül be kell, hogy mutassam a folyamatban szerepet játszó különböző szervezeti egységeket, illetve rendszereket. Az NN Biztosító alap szerződéskezelő rendszere az IBM által a kétezres évek előtt fejlesztett LIFE400 nevű biztosítási szerződéskezelő rendszer. Ennek a rendszernek a feladata a meglévő szerződésekkel kapcsolatos valamennyi adat, tranzakció tárolása és futtatása. Az ügyféladatok tárolása kezelése, díjak és árfolyamok számítása szintén a LIFE400-ban történik. A Cobol nyelvben íródott rendszer, holott nem nevezhető egy újszerű rendszernek, a biztosítók körében igen gyakran használatos, köszönhetően stabilitásának, és annak, hogy alapvetően biztosítási szerződések kezelésére írták. Ehhez a core rendszerhez kapcsolódik minden egyéb az NN Biztosítónál használt szakredszer is, úgy mint az nn.hu oldalról elérhető NNDirect, a szerződött partnerek által használt CRM. A LIFE400 legacy rendszer és a többi szakredszer közötti kapcsolatért a szintén IBM fejlesztésű JAVA alapú ESB (Enterprise Service Bus) redszer a felelős. Ez a rendszer egyfajta út, átadó egység a többi rendszer között, ahova azok különböző szolgáltatásokat tudnak kiajánlani, onnan meghívni. Az ESB rendszerben üzleti logikák nem kerülnek beépítésre, kizárólag a többi rendszer közötti kapcsolat biztosítása a feladata. A biztosító ügyfeleivel a szerződött partnereken keresztül, valamint leggyakrabban levélben érintkezik. A ügyfeleknek és minden egyéb szereplőnek (mint például a szerződött partnerek) kiküldendő levelek előállításáért, és karbantartásáért a HPE nevű rendszer a felelős. Ebben környezetben keletkeznek meg a LIFE400-ban tárolt adatok alapján a levelek, ugyanakkor, magában a HPE-ben is találunk üzleti logikákat a levelek kódjába írva. A szerződéskezelési osztály által a LIFE400 rendszeren kívül használt másik vastagklienses rendszer a TP2 (TouchPoint2), amely a szkennelt dokumentumok tárolására szolgál, illetve ebbe a rendszerbe kerültek kialakításra többek között a szerződéskezelési feladatokat támogató ügyviteli folyamatok is. A TP2 nem kapcsolódik sem közvetlenül, sem közvetve a LIFE400-hoz. Ebben a folyamatok feldolgozásához szükséges lépések követhetőek le, itt keletkeznek meg az elvégzendő ügyek, feladatok. A feladatok keletkezésének általános indítója egy kimenő, vagy beérkező ügyfél levél, vagy rendelkezés. A TP2-ben létrejött feladatokat ezután ügyintézőkhöz lehet kiosztani. Ahogy a sok másik folyamat is az évfordulós folyamat is egy levél kiküldésével indul a biztosítási évfordulót megelőzendően. Ez az értesítő levél tartalmazza szerződés aktuális adatait, a szerződés értékkövetési lehetőségeit, a következő évre érvényes díjfizetési kedvezményeket. A levél két példányban készül. Ennek oka, hogy az egyik példányt az ügyfélhez tartozó szerződött partner kapja meg az ügyfél példányának kiküldése előtt 10 nappal. Ennek az oka, hogy a szerződött partnernek legyen lehetősége az ügyfelet személyesen felkeresni, és egy találkozó alkalmával segíteni az ügyfélnek nyilatkozatot tenni a biztosítási évfordulóval kapcsolatos módosításokról. Amennyiben a szerződött partner a megadott tíz napon belül nem keresi fel az ügyfelet, úgy az ügyfél a saját példányán keresztül önállóan is megteheti a nyilatkozatát. Az ügyfélnek kiküldött levél egy példányát első számú mellékletként, anonimizált formában a dolgozathoz mellékelem. A levél kézhezvételét követően, vagy a szerződött partneri látogatás során az ügyfélnek lehetősége van arra, hogy elfogadja, vagy elutasítsa a díjnövelési lehetőségeket, amennyiben azokat felajánlja a biztosító. Amennyiben az ügyfél nem tesz semmilyen nyilatkozatot a díjnövelés automatikusan elfogadásra kerül a biztosítási évfordulókor. Az ügyfeleknek továbbá lehetőségük van a szerződött partnerek személyes látogatásáról nyilatkozni. Erre a szerződött partnereknek az állományápoláshoz kapcsolódó személyes találkozók után járó jutalék elszámolása miatt van szükség. Az ügyfelek által a biztosító számára visszaküldött nyilatkozatokat az NN Biztosító központjában a Iratkezelési osztály dolgozza fel. Ezen az osztályon kerülnek kezelésre a biztosító által kiküldött, illetve annak megküldött postai levelek. A levelek kibontását és folyamatok szerinti szortírozását követően a biztosítási évfordulóval kapcsolatos nyomtatványokat az iratkezelés munkatársai a következő hat kategóriába sorolják: • INFTAYUL Tartalma: VAN igazolt személyes látogatás VAN alapértelmezettől eltérő ügyfélnyilatkozat (jobb oldalon X-el) Befektetési egységhez kötött a szerződés Kezelése: Ezek a nyilatkozatok incoming-ként bekerülnek a normál workflowba és a normál ügymenet szerinti folyamatba. • INFTAYTR Tartalma: VAN igazolt személyes látogatás VAN alapértelmezettől eltérő ügyfélnyilatkozat (jobb oldalon X-el) Hagyományos a szerződés Kezelése: Ezek a nyilatkozatok incoming-ként bekerülnek a normál workflowba és a normál ügymenet szerinti folyamatba. • INFTANUL Tartalma: NINCS igazolt személyes látogatás VAN alapértelmezettől eltérő ügyfélnyilatkozat (jobb oldalon X-el) Befektetési egységhez kötött a szerződés Kezelése: Ezek a nyilatkozatok incoming-ként bekerülnek a normál workflowba és a normál ügymenet szerinti folyamatba. • INFTANTR Tartalma: NINCS igazolt személyes látogatás VAN alapértelmezettől eltérő ügyfélnyilatkozat (jobb oldalon X-el) Hagyományos a szerződés Kezelése: Ezek a nyilatkozatok incoming-ként bekerülnek a normál workflowba és a normál ügymenet szerinti folyamatba. • INFTAY Tartalma: VAN igazolt személyes látogatás NINCS alapértelmezettől eltérő ügyfélnyilatkozat (bal oldalon X-el) Módozattól független típus Kezelése: szkennelés archív típussal, így az irattal nincs további teendő. • INFTAN Tartalma: NINCS igazolt személyes látogatás NINCS alapértelmezettől eltérő ügyfélnyilatkozat (bal oldalon X-el) Módozattól független típus Kezelése: szkennelés archív típussal, így az irattal nincs további teendő 1. ábra, a beérkező nyomtatványok szortírozása A levelek szétválogatásának legfőbb oka, hogy más-más módon kerülnek kezelésre a folyamat további fázisaiban. Amint azt a fenti felsorolásból is láthatjuk, megkülönböztetik a hagyományos (tradicionális) biztosítási termékeket, az Unit Linked termékektől, a szerződött partneri látogatások meglétét vagy hiányát valamint a díjváltozás elfogadását vagy elutasítását. A hat kategória mindezekből úgy áll össze, hogy amennyiben az ügyfél elfogadó nyilatkozatot tett, úgy nincs további feldolgozás, ezért nem különböztetik meg a tradicionális és Unit Linked szerződéseket. A szétválogatást követően a dokumentumokat külön csomagokban szkennelik, és a TP2 rendszerbe terelik, ahol ellátják a megfelelő metaadatokkal. A TP2 rendszerben a szerződéskezelési ügyintézők a saját „sorukba” rakhatják a még fel nem dolgozott ügyeket. Ezeket később megnyitva láthatóvá válik a dokumentumok képe. A dokumentumok ellenőrzését követően az ügyintézők a LIFE400 rendszerben rögzítik a díjmódosítás elutasítását, majd visszatérve lezárják az adott ügyet a TP2-ben. 2. Ábra, a jelenlegi évfordulós folyamat ábrája Lehetséges fejlesztési pontok a folyamatban, az új szoftveres környezet Ahhoz, hogy a lehetséges fejlesztési pontokat jobban megértsük, röviden szeretném ismertetni azt a két rendszert, amit az NN Biztosító döntése alapján a jelenleg TP2-ben kezelt folyamatok kiváltására szánnak. A folyamatvezérlő vagy más szóval workflow management rendszer a JAVA alapokon felépülő PEGA. A PEGA egy a biztosító saját szerverén futó internetes böngészőből elérhető vékonyklienses rendszer, amely támogatja a folyamatok automatizálását. A PEGA rendszer képes az ESB-n keresztül a LIFE400-ban automatikusan tranzakciókat futtatni, business object-ek segítségével. Ilyen automatizációk fejlesztésére más folyamatok esetében sor is került a biztosítónál. Viszont a rendszerek közötti integrációk kiépítésének magas programozói erőforrás igénye miatt, ehhez hasonló fejlesztésekre a jelen helyzetben nem kerül sor. Külön rendszerbe kerülnek tárolásra a szkennelést követően a dokumentumok. Ezért az Alfresco dokumentumkezelő a felelős. Az Alfresco-ban egy új dokumentum modell került kialakításra, amelynek segítségével minden a biztosítóhoz beérkező dokumentum megkaphatja az arra jellemző metaadatokat. Ezekben a rendszerekben kerültek korábban kialakításra, más ügyviteli folyamatok is, amelyekhez a rendszerek közötti integrációk már létre lettek hozva. Ezen kapcsolatok közé tartozik a PEGA és LIFE400 ESB-n keresztüli kapcsolata, amely lehetővé teszi szerződés, kliens és pénzügyi adatok lekérdezését és visszaírását a PEGA számára. Az évfordulós folyamat esetén, ahogy azt korábban említettem új integráció nem került kialakításra, a meglévők nem kerületek bővítésre. A folyamat elemzését követően arra a megállapításra jutottam, hogy a meglévő technikai megoldásokkal, illetve a PEGA és Alfresco rendszerek használatával az évfordulós folyamatban az iratkezelési szortírozási tevékenységeknél lehet hatékonyságot növelni. Ennek módja, hogy az ügyfélnek, és szerződött partnereknek kiküldött értesítő levélen egy QR kódot helyezünk el, amely tartalmazza a biztosítási módozatot, valamint a szerződő és szerződés adatait. Ezzel jelentősen megrövidíthető az iratkezelési tevékenység, melynek szignifikáns részét képezi a dokumentumok metaadatokkal való ellátása. Az új évfordulós folyamat 3. Ábra, az új évfordulós folyamat ábrája Az új évfordulós folyamat első lépésében nem történik változás, az ügyfélnek és a szerződött partnernek kiküldésre kerülnek az évfordulós levelek, ennek a lépésnek az indítója továbbra is a LIFE400. A levelek tartalmában életbe lépő változtatás, hogy azok tartalmazni fognak egy QR kódot. A QR kód információt hordoz a szerződő személyére, szerződés módozatára vonatkozóan. A nyomtatvány beérkezését követően, az iratkezelésen nem szükséges a nyomtatványok termékek szerinti szétválogatása, hiszen az azokon elhelyezett QR kód már tartalmazza ezt az információt. A szkennelést követően a dokumentumok az Alfresco metaadatozó felületében jelennek meg. Itt az iratkezelési munkatársaknak ellenőrizniük kell, a QR kódokból már kiolvasott metaadatokat, valamint el kell látniuk a dokumentumokat az egyéb metaadatokkal. Ilyen például, a díjmódosítás elfogadása, vagy elutasítása. Amint azt korábban láthattuk, abban az esetben, ha a szerződő elfogadja a biztosító által meghatározott díjmódosítást, további feldolgozásra nincs szükség. Amennyiben viszont ez elutasításra kerül, további feldolgozás válik szükségessé a LIFE400 rendszerben. Ez előbbi esetben az Alfresco a metaadatozást követően a dokumentumokat archiválja. 4. ábra, Az Alfresco metaadatozó felülete, a nyilatkozat típusa, szerződés és kliensszám automatikusan kitöltődik a QR kódokban tárolt adatok alapján Utóbbi esetben viszont a metadatok bevitelét követően az Alfresco közvetlen kapcsolat révén évfordulós ügyet indít a PEGA rendszerben. Az ügy indítást követően a PEGA business object integrációt használva, az ESB-n keresztül lekéri a LIFE400 rendszerből a szerződés, és szerződő adatait. Ezt a lépést inicializálásnak nevezzük. 5. ábra, a PEGA képernyő az ügy indítása és inicializálás után láthatóvá válnak a szerződés és szerződő adatai Viszonylag gyakori eset ennél a folyamatnál, hogy a nyilatkozatok az ügyféltől, szerződött partnerektől kis időbeli eltéréssel több csatornán is beérkezhetnek a biztosítóhoz. Ilyen lehet, ha mind a két szereplő postán juttatja el a nyilatkozatot, vagy az egyik postán a másik személyesen, esetleg faxon. Ezekben az esetekben nagyon fontos, hogy ne induljanak duplikált PEGA ügyek. Ezért a PEGA ügyek indulása után az első lépésben a PEGA összegyűjti és feladat kiosztás után az ügyintézőknek listázza, az azonos szerződésszámokra, az utóbbi 15 napban létrehozott hasonló típusú PEGA ügyeket. Az ügyintézőknek lehetőségük van ellenőrizni ezeket az ügyeket, és ha úgy találják, hogy valamelyik duplikátum, az újonnan beérkező dokumentumokat egy meglévő ügyhöz csatolhatják. Ezt követően a korábbi ügy aktiválódik, és folytatható lesz annak feldolgozása. Amennyiben nincs potencionálisan duplikált ügy, vagy nem tényleges duplikátumokról van szó, az ügy feldolgozása folytatható. A PEGA folyamat következő lépésében az ügyintéző ellenőrzi a beérkezett nyilatkozatot. Amennyiben a feldolgozási feltételek szerint azt elfogathatónak találja a PEGA rendszerben rögzíti az elfogadást. 6. ábra, a PEGA felületen elfogadásra került a beküldött nyilatkozat Ha a beérkezett dokumentumok nem felelnek meg hiánypótlás, vagy elutasítás indítására van lehetőség, a hiánypótlás, vagy elutasítási okok megjelölésével. A hiánypótló, vagy elutasító levelek kiküldése a LIFE400 és HPE rendszereken keresztül, sztenderd levél kiküldési folyamatban történik meg. A hiánypótló és elutasító levelek PEGA ügyszámmal rendelkeznek és kiküldést követően letárolásra kerülnek az Alfresco-ban. A PEGA ügyszámra azért van szükség, mert a következő lépésben ezeknek a leveleknek láthatónak kell lenniük az ügyekben. Elutasítás esetén a PEGA ügyek lezárt feldolgozatlan státuszba kerülnek. Hiánypótlás esetén a PEGA ügy várakozó státuszba kerül tizenöt napra. Amennyiben ennyi idő alatt az ügyfél nem küldi meg a hiánypótolt dokumentumot a PEGA ügy automatikusan lezáródik. 7. ábra, hiánypótlás indítása az aláírás hiánya miatt A dokumentum elvárások elfogadását követően az ügyintézőknek a LIFE400-ban kell rögzíteniük a díjmódosítás elutasítását. Ennek megtörténtét a PEGA rendszerben is rögzíteniük kell. 8. ábra, rögzítés megerősítse a PEGA rendszerben Ezt követően a PEGA ügy automatikusan lezárt státuszba kerül.   A pénzmosás elleni törvényi megfelelés új folyamata 9. ábra, az ügyfél azonosítási folyamat Az NN Biztosítónál törvényi megfelelés miatt új folyamattal bővül a biztosítási évfordulón lévő szerződött partneri ügyféllátogatás. A 2017. évi LIII. törvény értelmében ugyanis a biztosítónak minden ügyfelét azonosítania kell, valamint a személyes azonosítás igazolására el kell tárolnia azok személyi azonosításra, lakcím igazolásra alkalmas igazolványuk képét. Az azonosítás során bekérendő adatokat, adatszerkezetet a kettesszámú melléklet tartalmazza. Az ügyfelek azonosító adatainak, valamint az igazolványok érvényességének, és magának az azonosítás tényének tárolására a LIFE400 rendszerben kerül kialakításra a megfelelő adatszerkezet. Ebben az adatbázisban kerülnek eltárolásra a fentebb említett adatok, valamint az a minden ügyfélhez hozzárendelt jelzés, ami a különböző feltételek figyelembevételével megadja, hogy az adott ügyfél azonosítása megtörtént-e, az az adott időpontban érvényes vagy sem. Ez a jelző fogja megadni, melyik ügyfelet mikor kell azonosítani, ezt felhasználva fogják a további szakrendszerek, mint ahogy később kitérek rá elindítani az ügyfél azonosítási folyamatokat. Mivel a szerződött partnereknek minden évben egyszer a biztosítási évforduló alkalmával személyesen fel kell keresniük az ügyfeleket, logikus lépés, hogy ezt az alkalmat is felhasználjuk az azonosításra, okmánymásolatok tárolására. Ez azonban az azonosítási folyamatnak csak az egyik ága, hiszen előfordulhat, hogy egy szerződött partner nem találkozik egy-egy ügyféllel, valamint a törvény értelmében az azonosítást újra el kell végezni abban az esetben, ha a személyes azonosításra szolgáló okmányok lejárnak. Annak érdekében, hogy a biztosító a teljes ügyfélkörét azonosítani lehessen a következő folyamatágak kerület kidolgozásra. Szerződött partneri látogatás során A személyes találkozó alkalmával a szerződött partnerek által használt CRM rendszer segítségével elvégezhető az azonosítás. Ez az alkalmazás minden partner rendelkezésére áll, naprakészen megtalálhatóak benne a szerződéses és kliens adatok, a LIFE400 rendszerrel való napi szinkronizációs kapcsolatnak köszönhetően. A CRM rendszerben a szerződött partnerek a LIFE400 –ban lévő adatok alapján értesítést, vagy feladatot kapnak az ügyfeleik beazonosítására. Azonosításkor lehetőségük lesz a személyes adatok és okmányok adatainak felvitelére, valamint az okmányokról fénykép készítésére. Az elkészült okmányképeket a rendszer a megfelelő metaadatokkal együtt az Alfresco rendszerben tárolja. Az azonosítás megtörténtét, illetve az okmányok érvényességi idejét pedig a LIFE400-ba továbbítja. A folyamat ezen ágán az okmányok képének ellenőrzésre nincs szükség, hiszen a szerződött partnerek készítik el a képeket. Az NNDirekt online felületen keresztül 10. ábra, ügyfél azonosítás az NNDirekt-en kersztül Az NNDirekt a biztosító online ügyfélportálja, ami az nn.hu weboldalról érhető el, szintén alkalmas az azonosítási feladatok egy részének ellátására. Ezen a felületen keresztül elérhetőek azon ügyfelek, akik vállalták, hogy a biztosító elektronikus kommunikációs csatornákon keresztül kommunikál velük. A felületen azon ügyfelek számára, akik a LIFE400-ban tárolt adatok alapján nem minősülnek beazonosítottnak, egy értesítő levél kíséretében, elvégzendő feladat fog megjelenni. Ehhez az NNDirekt és LIFE400 között az ESB-n létrejövő kapcsolat kiépítésére van szükség, amin keresztül a LIFE400-ból lekérdezhetőek az adott ügyfélhez tartozó azonosítási adatok. Az online felületen kialakításra kerül tehát az a felület, ahol az ügyfelek elektronikus úton elvégezhetik az azonosítást. Itt belépés után megjelenítésre kerülnek azok az adatok, amiket az adott pillanatban a LIFE400 tárol. Lehetőség lesz ezen adatok ellenőrzésére illetve módosítására, valamint az okmány másolati képek feltöltésére. Ebben a folyamatban azonban, eddig a pontig a biztosító egyik munkatársa sem tudja felügyelni, ellenőrizni az online felületen keresztül feltöltött adatok, igazolványképek megfelelőségét, ezért a PEGA rendszerben minden az NNDriket-en keresztül indított azonosítás új ügyet fog indítani. Az NNDirekt minden olyan esetben, amikor egy ügyfél elkezdi az azonosítási folyamatot az online felületen, az ESB-n keresztül meghívja a PEGA ügyindító szolgáltatását, amire válaszként egy egyedei PEGA ügyszámot kap. Ezt az ügyszámot felhasználva tárolja aztán később az NNDirekt, az Alfresco-ban az okmány másolatokat, valamint hozzárendeli az ügyfél által megadott azonosítási adatokhoz. Amikor az ügyfél befejezi az adatai ellenőrzését vagy módosítását, illetve a képek feltöltését az online feladat lezárul, és az NNDiretk már a PEGA ügyszámmal együtt adja át a PEGA-nak egy másik szolgáltatás hívásával az adatokat. A képek az Alfresco-ba kerülnek feltöltésre. A PEGA rendszerben az ügyfél azonosítási ellenőrzési ügyek a szerződéskezelésen kerülnek kiosztásra, ahol a munkatársak ellenőrizni tudják a megadott adatokat, valamint az ügyfelek által feltöltött okmányképeket. Amennyiben a feltöltött okmányképek nem felelnek meg az elvárt követelményeknek, nem olvashatóak, hiánypótló levél indítható. Egyéb esetben az ügyintéző elfogadhatja az azonosítást, amelynek adatai automatikusan beíródnak a LIFE400 rendszerbe, egy az ESB-n létesített kapcsolaton keresztül. Azonosítás postai úton Azon ügyfelek számára, akik nem kerülnek azonosításra szerződő partnerek segítségével, és nem használnak elektronikus kommunikációs csatornát, postai levél kerül kiküldésre. Ez a levél tartalmazza egy ügyfél azonosítási nyomtatványt, amelyet kitöltve és a biztosító számára visszaküldve végezhető el az azonosítás. Ezeket a beérkező nyomtatványokat az iratkezelés érkezteti, majd beszkenneli. A szkennelést követően a dokumentum képek az Alfresco-ba kerülnek, és az NNDirekt-es esetekhez hasonlóan PEGA ügyek indulnak az ellenőrzések elvégzéséhez. Az ellenőrzéseket követően az adatok ebben az esetben is a LIFE400-ba kerülnek rögzítésre. Összefoglalás A dolgozatomban az NN Biztosító bemutatását követően nagyvonalakban vázoltam a jelenlegi biztosítási évfordulós folyamatok azon részét, aminek feldolgozása a NN Biztosító magyarországi közpántjában történik. Itt érintve a szerződött partnerek, iratkezelési és szerződéskezelési osztályok folyamatait, valamint az aktuális folyamat lehetséges fejlesztési pontjait. Bemutattam ezt a folyamatot az új PEGA rendszerbe integrálva, ennek a rendszernek a kapcsolatait a többi szakrendszerrel. Ezt követően bemutattam az évfordulós folyamathoz szorosan kacsolódó új ügyfél azonosítási tervezett folyamatát mutattam be, amelynek egyik ága szintén a PEGA folyamatkezelő rendszerben kerül kialakításra. Irodalomjegyzék • TechTarget, 2017 • Schwaber et. at., 2013 • Schwaber, 1998   Mellékletek 1. számú melléklet, Évfordulós tájékoztató levél   2. Ügyfél azonosításhoz szükséges adatszerkezet

Magyar cím

Az életbiztosítási évfordulós folyamat integrálása folyamatvezérlő rendszerbe

Intézmény

Budapesti Gazdasági Egyetem

Kar

Pénzügyi és Számviteli Kar

Tanszék

Gazdaságinformatika Intézeti Tanszék

Tudományterület/tudományág

NEM RÉSZLETEZETT

Szak

Gazdaságinformatika FOSZK

Konzulens(ek)

Mű típusa:	projektmunka
Kulcsszavak:	Évforduló, folyamatvezérlő rendszer, Korpega rendszer
Felhasználói azonosító szám (ID):	Tóth Máté
Rekord készítés dátuma:	2018. Dec. 18. 16:22
Utolsó módosítás:	2018. Dec. 18. 16:22

Actions (login required)

Tétel nézet