Kárrendezési adatmintája
Kárrendezési adatmintája
Ez a(z) Kárigények feldolgozása folyamathoz készült általános process mining adatsablonunk. Részletesebb útmutatásért használja a rendszerspecifikus sablonokat.
Válasszon egy konkrét rendszert- Útmutató a szükséges adatattribútumokhoz.
- A teljes folyamat áttekintéséhez szükséges fő tevékenységek.
- Rugalmas keretrendszer, amely bármilyen kárrendezési rendszerhez használható.
A kárrendezés attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Kárigényazonosító ClaimId | Az egyes biztosítási kárigények egyedi azonosítója, amely a process mining során az ügy elsődleges azonosítójaként szolgál. | ||
| Leírás A kárigényazonosító egyedi kulcs, amelyet minden biztosítási kárigényhez annak nyilvántartásba vételekor rendelnek hozzá. Ez kapcsolja össze a kárigény teljes életciklusa során keletkező tevékenységeket, eseményeket és adatokat, a kezdeti benyújtástól a végleges lezárásig. A process mining során a kárigényazonosító alapvető fontosságú az egyes kárigények teljes folyamatának rekonstruálásához. Az azonosító alapján csoportosított eseményekből a szoftver megjeleníti a folyamat menetét, feltárja az eltéréseket, és kiszámítja az ügy szintű mutatókat. Így minden művelet, a kárszakértő kijelölésétől a kifizetésig, a megfelelő kárigényhez rendelhető, ami pontos és összefüggő folyamatelemzést tesz lehetővé. Miért fontos? Ez az ügy egyedi azonosítója, amely összekapcsolja a kapcsolódó eseményeket, így nyomon követhető az egyes kárigények teljes folyamata. Hol szerezhető be? Általában a kárigény aktájának fejlécében vagy elsődleges rekordjában, illetve a kárigénykezelő rendszer tranzakciós adatai között található. Példák CL-2023-001234A789-C54329876543210 | |||
| Kezdési idő StartTime | Az az időbélyeg, amely megmutatja, mikor kezdődött egy adott tevékenység vagy esemény. | ||
| Leírás A kezdési idő pontos dátum- és időadat, amely megmutatja, mikor indult el egy tevékenység. A folyamatnapló minden eseményénél fontos adat, mert időbeli kontextust ad a teljesítmény elemzéséhez. A process mining során a kezdési idő alapján rendezhetők időrendbe az események, így pontosan rekonstruálható az ügy folyamata. Ez az adat szükséges többek között az átfutási, várakozási és feldolgozási idők kiszámításához. Az időbélyegek elemzésével feltárhatók a lépések közötti késések, mérhető a szolgáltatási szintű megállapodások (SLA-k) betartása, és megérthető a kárigény-feldolgozás időbeli alakulása. Miért fontos? Ez az időbélyeg szükséges az események helyes sorrendbe állításához és az időalapú mutatók, például az átfutási idők és a szűk keresztmetszetek kiszámításához. Hol szerezhető be? Általában az eseménynaplókban, az ellenőrzési nyomvonalakban vagy a tranzakciós adatok között szerepel, gyakran „esemény időpontja” vagy „létrehozás dátuma” néven. Példák 2023-03-15T09:00:00Z2023-05-20T14:35:10Z2023-07-01T11:21:05Z | |||
| Tevékenység neve ActivityName | A kárigényhez kapcsolódó, adott időpontban végrehajtott üzleti tevékenység vagy bekövetkezett esemény neve. | ||
| Leírás A tevékenység neve a kárigény feldolgozásának egy adott lépését, feladatát vagy eseményét jelöli. Ilyen például a „Kárigény nyilvántartásba véve”, a „Vizsgálat megkezdődött” vagy a „Kifizetés elindítva”. Minden tevékenység a folyamat egy különálló pontja, amelyet az eseménynapló rögzít. A folyamattérképen a tevékenységek alkotják a folyamat építőelemeit. Sorrendjük, gyakoriságuk és időtartamuk elemzésével feltárható a tényleges folyamatmenet, a jellemző útvonalak, a szűk keresztmetszetek és a szabványos eljárástól való eltérések. Az érthető és következetes tevékenységnevek segítenek használható folyamatmodellt készíteni. Miért fontos? A tevékenységek adják a folyamattérkép alapját. Sorrendjük és időtartamuk elemzésével megérthető a folyamat teljesítménye. Hol szerezhető be? Általában az eseménynaplókban, az ellenőrzési nyomvonalakban vagy a kárigénykezelő rendszer tranzakciós rekordjaiban található. Példák Kárügy rögzítveKárfelmérés készKifizetés elindítvaKárigény elutasítva | |||
| Forrásrendszer SourceSystem | Az a nyilvántartó rendszer, amelyből az eseményadatokat kinyerték. | ||
| Leírás A forrásrendszer attribútum megadja, melyik informatikai alkalmazásban vagy platformon rögzítették eredetileg a tevékenységet. Összetett informatikai környezetben a kárigény-feldolgozás adatai több rendszerből is származhatnak, például egy központi kárigénykezelő platformból, dokumentumkezelő rendszerből vagy ügyfélkapcsolat-kezelő (CRM) eszközből. A forrásrendszer ismerete segít az adatok ellenőrzésében és a folyamat széttagoltságának elemzésében. Visszavezethető vele az adatminőségi probléma az eredetéhez, és feltárhatók a kézi adatátvitelből vagy a rendszerek közötti munkatovábbításból eredő hatékonysági problémák. Az elemzés rámutathat a rendszerek jobb integrációjának és az automatizálásnak a lehetőségeire. Miért fontos? Megmutatja, honnan származnak az eseményadatok. Ez fontos az adatok ellenőrzéséhez és a folyamat több informatikai rendszeren átívelő végrehajtásának elemzéséhez. Hol szerezhető be? Ez az információ része lehet az adatkinyerési logikának, vagy mezőként szerepelhet az integrált rendszerek eseménynaplóiban. Példák Kárigénykezelő rendszerCRM-portálDokumentumkezelő rendszer | |||
| Utolsó adatfrissítés LastDataUpdate | A forrásrendszerből végzett legutóbbi adatfrissítés vagy adatkinyerés időbélyege. | ||
| Leírás Az utolsó adatfrissítés azt jelzi, mikor frissítették legutóbb az eseménynapló adatait a forrásrendszerekből. Az időbélyeg megmutatja, mennyire frissek az elemzett adatok, így az érintettek tisztában vannak azok aktualitásával. A megalapozott döntésekhez minden folyamatelemzésnél fontos tudni, mennyire naprakészek az adatok. Ez az attribútum segít eldönteni, hogy közel valós idejű folyamatot vagy korábbi állapotot lát-e. Különösen fontos a folyamatos nyomon követést szolgáló dashboardoknál, és annak biztosításához, hogy a következtetések releváns, naprakész információkon alapuljanak. Miért fontos? Megmutatja, mennyire frissek az adatok, így az elemzés és a döntések naprakész információkra támaszkodhatnak. Hol szerezhető be? Ez általában az adatkinyerés, -átalakítás és -betöltés (ETL) során létrejövő metaadat. Példák 2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Befejezési idő EndTime | Az az időbélyeg, amely megmutatja, mikor fejeződött be egy adott tevékenység vagy esemény. | ||
| Leírás A befejezési idő pontos dátum- és időadat, amely megmutatja, mikor zárult le egy tevékenység. Ha a kezdési idő is rendelkezésre áll, pontosan kiszámítható, mennyi ideig tartott a tevékenység. Ez az attribútum részletes teljesítményelemzéshez különösen hasznos. A kezdési és befejezési idő különbsége adja a feldolgozási időt, vagyis a tevékenység időtartamát. Ez a mutató segít azonosítani a nem hatékony lépéseket. A feldolgozási idők elemzésével kiderül, mely tevékenységek kötik le a legtöbb erőforrást, és hol érdemes egyszerűsíteni a működést. A folyamat szűk keresztmetszeteit és a csapat teljesítményét bemutató dashboardok alapjául is szolgál. Miért fontos? Lehetővé teszi a tevékenységek feldolgozási idejének pontos kiszámítását, ami segít feltárni a szűk keresztmetszeteket és elemezni az erőforrások hatékony felhasználását. Hol szerezhető be? Általában az eseménynaplókban vagy az ellenőrzési nyomvonalakban, a kezdési idő mellett található. Ha csak a változásokat rögzítik, előfordulhat, hogy ki kell számítani. Példák 2023-03-15T11:30:00Z2023-05-20T15:05:45Z2023-07-01T11:29:15Z | |||
| Kár súlyossága ClaimSeverity | A kárigény becsült összetettségének vagy várható pénzügyi hatásának besorolása, például alacsony, közepes vagy magas. | ||
| Leírás A kár súlyossága a kárigény összetettségét, sürgősségét vagy várható pénzügyi költségét jelzi. Ez a besorolás segít a kárigények rangsorolásában és a megfelelő tapasztalattal rendelkező kárszakértőkhöz irányításában. A súlyosságot többek között a becsült kárösszeg, az esemény jellege vagy a peres eljárás ténye határozhatja meg. A kár súlyossága szerinti folyamatelemzésből kiderül, hogy a feldolgozás módja igazodik-e a kárigényhez. A súlyos károk feldolgozása például várhatóan tovább tart, de alaposabb vizsgálatot igényel. Ez az attribútum segít ellenőrizni, hogy az összetett kárigények megkapják-e a szükséges figyelmet, miközben az egyszerű ügyeket gyorsan feldolgozzák. Így hatékonyabban oszthatók el az erőforrások, és javítható az ügyfél-elégedettség. Miért fontos? Segít elkülöníteni az egyszerű és az összetett kárigényeket, így ellenőrizhető, hogy a folyamat igazodik-e a kárigény bonyolultságához. Hol szerezhető be? Gyakran a kárigény befogadásakor, üzleti szabályok alapján határozzák meg, és a kárigény fő rekordjának mezőjeként tárolják. Példák AlacsonyKözepesMagasKatasztrofális | |||
| Kárigény típusa ClaimType | A biztosítási kárigény kategóriája, amely alapján összehasonlítható a különböző típusú kárigények feldolgozása és a folyamat teljesítménye. | ||
| Leírás A kárigény típusa szerinti besorolás az üzletág vagy a kár jellege alapján történik, például „Gépjármű”, „Vagyon”, „Felelősség” vagy „Rokkantság”. A különböző típusú kárigények gyakran eltérő folyamatot követnek, és más a bonyolultságuk, illetve az SLA-juk. A kárigény típusa szerinti folyamatelemzés alapvető módszer az érdemi következtetések levonásához. Lehetővé teszi az átfutási idők, a költségek és a folyamatkövetés összehasonlítását a kategóriák között. Kiderülhet például, hogy a gépjármű-kárigények feldolgozása hatékony, míg a vagyonkároké nem. Ez segít célzott fejlesztéseket tervezni. Ez az attribútum a „Teljesítmény kárigény-kategóriánként” dashboardhoz is szükséges. Miért fontos? Lehetővé teszi a kárigények csoportosítását, így összehasonlítható a folyamat és a teljesítmény az egyes üzletágak között, és feltárhatók a kategóriaspecifikus problémák. Hol szerezhető be? A kárigény fő rekordjának szokásos mezője, amelyet általában a kárigény létrehozásakor töltenek ki. Példák GépjárműVagyonMunkavállalói balesetÁltalános felelősség | |||
| Kártérítési összeg SettlementAmount | A kárigény rendezésére a károsultnak vagy egy harmadik félnek kifizetett végleges pénzösszeg. | ||
| Leírás A kártérítési összeg a kárigény rendezésére kifizetett teljes pénzösszeg. Ez fontos eredménymutató, amely megmutatja a kárigény pénzügyi hatását. Általában a kár felmérése és a döntés meghozatala után határozzák meg. A process mining során ez az attribútum elengedhetetlen a költségelemzéshez. Segítségével kiszámíthatók például az „Átlagos költség kárigényenként” KPI-k, és megvizsgálható, hogyan befolyásolják a folyamat eltérései a pénzügyi eredményeket. Az elemzés például kimutathatja, hogy az utómunkát igénylő vagy hosszabb átfutású kárigények kártérítési összege magasabb. Így közvetlen kapcsolat teremthető a folyamat hatékonysága és a pénzügyi teljesítmény között. Ez adja a „Kárigényköltségek elemzése” dashboard alapját. Miért fontos? Ez az eredménymutató közvetlen kapcsolatot teremt a folyamat működése és a pénzügyi hatás között, így elemezhető a folyamatfejlesztések költsége és haszna. Hol szerezhető be? A kárigényhez tartozó pénzügyi vagy kifizetési rekordokban található. A kárigény lezárásakor vagy a kifizetéskor véglegesítik. Példák 1500.0025000.50125.750.00 | |||
| Kijelölt kárszakértő AssignedAdjuster | A kárigény vagy egy tevékenység kezeléséért felelős felhasználó, például kárszakértő neve vagy azonosítója. | ||
| Leírás A kijelölt kárszakértő attribútum megmutatja, melyik munkatárs vagy felhasználó végzett el egy adott tevékenységet, illetve ki felelt a kárigényért egy adott időpontban. Ez az attribútum összekapcsolja a folyamat lépéseit az azokat végrehajtó munkatársakkal. A kárszakértők szerinti elemzés segít a munkaterhelés kezelésében, a teljesítmény értékelésében és a képzési igények feltárásában. A vezetők összehasonlíthatják a csapattagok teljesítményét, kiegyensúlyozhatják a feladatok elosztását, és felismerhetik a kiemelkedően teljesítő, illetve további támogatást igénylő munkatársakat. Ez az erőforrások szintjén végzett elemzés alapot ad a csapatteljesítményt és a munkaterhelés egyensúlyát bemutató dashboardokhoz. Miért fontos? Összekapcsolja a folyamat tevékenységeit az azokat végző munkatársakkal, így elemezhető a munkaterhelés, a csapat teljesítménye és az erőforrások elosztása. Hol szerezhető be? A kárigénykezelő rendszer tranzakciós rekordjaiban, ellenőrzési naplóiban vagy felhasználó-hozzárendelési mezőiben található. Példák John SmithUSER789Emily Jonesadjuster_team_a | |||
| Rendezés céldátuma ResolutionTargetDate | Az a céldátum, ameddig a kárigényt várhatóan rendezni kell a szolgáltatási szintű megállapodások (SLA-k) vagy a jogszabályok alapján. | ||
| Leírás A rendezés céldátuma, más néven határidő, a kárigény-feldolgozás befejezésének kitűzött időpontja. Ezt gyakran jogszabályi előírások vagy a megfelelő ügyfélkiszolgálást biztosító belső szolgáltatási szintű megállapodások (SLA-k) határozzák meg. Ez az attribútum alapvető a megfelelés és a teljesítmény nyomon követéséhez. A kárigény tényleges lezárási dátumát a céldátummal összevetve mérhető az SLA-k betartási aránya. A process mining feltárja, mely folyamatlépések vagy folyamatváltozatok vezetnek leggyakrabban az SLA megsértéséhez. Így előre kezelhetők a határidők, és előtérbe kerülhetnek azok a fejlesztések, amelyek a leginkább segítik a kárigények időbeni rendezését. Ez közvetlenül támogatja az „SLA-k és határidők betartása” dashboardot. Miért fontos? Lehetővé teszi a határidőre történő teljesítés mérését az SLA-khoz vagy jogszabályi határidőkhöz képest. Ez a folyamat hatékonyságának fontos mutatója. Hol szerezhető be? Általában a kárigény létrehozásakor, üzleti szabályok alapján számítják ki, majd a kárigény fő rekordjában tárolják. Példák 2023-04-142023-06-192023-08-30 | |||
| Részleg Department | Az adott időpontban a tevékenység vagy a kárigény kezeléséért felelős üzleti egység, csapat vagy részleg. | ||
| Leírás A részleg attribútum megadja, melyik szervezeti egység felel a kárigényért annak életciklusa egy adott szakaszában. Ilyen lehet például a „Kárbejelentési egység”, a „Különleges vizsgálati egység” vagy a „Kifizetési részleg”. Ez az információ segít megérteni a szervezeti egységek közötti feladatátadásokat és együttműködést. A folyamat részlegenkénti elemzésével feltárhatók azok a késések, amelyek akkor keletkeznek, amikor a kárigény egyik csapattól a másikhoz kerül. Az elemzés segít azonosítani a részlegek közötti szűk keresztmetszeteket, és felmérni az egyes csapatok munkaterhelését és teljesítményét. Támogatja például a kárszakértők munkaterhelésének egyensúlyát mérő KPI-kat és a csapatteljesítményt bemutató dashboardokat. Miért fontos? Segít elemezni a csapatok közötti feladatátadásokat és feltárni a részlegek közötti szűk keresztmetszeteket, támogatva a szervezeti teljesítmény elemzését. Hol szerezhető be? Általában a kárigény rekordjában tárolják, gyakran a kijelölt felhasználóhoz vagy az aktuális folyamatszakaszhoz kapcsolva. Példák Kárbejelentési csapatKülönleges vizsgálati egységFelelősség megállapításaPénzügy és kifizetések | |||
| Benyújtási csatorna SubmissionChannel | Az a mód vagy csatorna, amelyen keresztül a kárigényt először benyújtották. | ||
| Leírás A benyújtási csatorna megmutatja, hogyan jelentették be először a kárigényt a vállalatnak. Gyakori csatorna az online ügyfélportál, a mobilalkalmazás, az ügynök, az alkusz vagy a hagyományos postai levél. A benyújtási csatorna szerinti elemzés feltárhatja az adatminőség, a hatékonyság és az ügyfélélmény közötti fontos különbségeket. A digitális portálon benyújtott kárigényeknél például kevesebb lehet az adatbeviteli hiba, és gyorsabb lehet a kezdeti feldolgozás, mint a postán érkezett ügyeknél. Ezek az eredmények segíthetnek eldönteni, mely csatornákat érdemes népszerűsíteni, és hol célszerű automatizálásba vagy folyamatfejlesztésbe fektetni. Miért fontos? Segít elemezni, hogyan hat a befogadási csatorna a folyamat hatékonyságára, az adatminőségre és a teljes átfutási időre. Hol szerezhető be? Általában az első kárbejelentés (FNOL) során rögzítik, és a kárigény fő rekordjában tárolják. Példák Webes portálÜgyintézőTelefonLevél | |||
| Elutasítás oka DenialReason | Az elutasított kárigényhez megadott konkrét indok. | ||
| Leírás Az elutasítás oka olyan kód vagy szöveges leírás, amely megmagyarázza, miért nem fizették ki a kárigényt. Az ok lehet például a kötvény szerinti fedezet hiánya, csalás gyanúja vagy a szükséges dokumentumok be nem nyújtása. Az elutasítási okok elemzése segít feltárni, hogyan javíthatók a belső folyamatok és az ügyfélkommunikáció. Ha például sok kárigényt hiányzó adatok miatt utasítanak el, érdemes lehet javítani a bejelentés felvételének folyamatán. Az okok kiváltó tényezőinek feltárása egyértelműbb kötvényszövegezéshez, hatékonyabb ügyféltájékoztatáshoz és az elutasításra kerülő kárigényekkel kapcsolatos adminisztráció csökkentéséhez vezethet. Miért fontos? Megmutatja, miért nem fizetik ki a kárigényeket. A kiváltó okok elemzésével javítható az ügyfélkommunikáció és a folyamat kezdeti szakasza. Hol szerezhető be? Az ügyintéző előre meghatározott listából választja ki vagy szövegesen adja meg a „Kárigény elutasítva” tevékenység rögzítésekor. Példák A kötvény nem fedeziCsalás gyanújaHiányos dokumentációIsmételt kárigény | |||
| Igényelt összeg ClaimedAmount | A kötvénytulajdonos által a kárigény benyújtásakor kezdetben igényelt teljes összeg. | ||
| Leírás Az igényelt összeg a kár kezdeti becslése, illetve az az összeg, amelyet a károsult az ügyintézés elején kér. A vizsgálat és a kárfelmérés során ez az érték módosulhat. Ez az adat többféle elemzéshez használható. Segítségével kezdeti súlyossági szint rendelhető a kárigényhez, és nyomon követhető a kezdetben igényelt, valamint a végül kifizetett összeg közötti eltérés. Ennek elemzése megmutathatja, mennyire pontosak a kezdeti becslések, és mennyire hatékonyak a költségkontroll intézkedései a kárrendezésben. A pénzügyi előrejelzések és tartalékképzés egyik fontos bemenő adata. Miért fontos? A kárigény kezdeti pénzügyi nagyságát jelzi. Hasznos a súlyosság felméréséhez és a végleges kifizetéstől való eltérés elemzéséhez. Hol szerezhető be? A kárigény kezdeti benyújtásakor rögzítik, majd a kárügy pénzügyi adatai között tárolják. Példák 2000.0035000.00500.00 | |||
| Káresemény dátuma LossDate | Az a dátum, amikor a biztosítási kárigényt kiváltó esemény vagy kár bekövetkezett. | ||
| Leírás A káresemény dátuma a kárigényt kiváltó esemény tényleges időpontját jelöli, például egy autóbaleset vagy vagyoni kár dátumát. Ez eltér attól a naptól, amikor a kárigényt bejelentették vagy rögzítették a rendszerben. A káresemény dátuma és a kárigény rögzítésének dátuma közötti időt bejelentési késedelemnek nevezzük. Ennek elemzése segít megérteni az ügyfelek viselkedését és felismerni a lehetséges csalási kockázatokat, például a szokatlanul hosszú bejelentési késedelmet. A teljes kárügy menetéről ad képet az eseménytől a lezárásig, nem csupán a belső ügyintézés idejéről. Miért fontos? Rögzíti a káresemény tényleges dátumát, így elemezhető a bejelentési késedelem és az eseménytől a lezárásig tartó teljes időszak. Hol szerezhető be? A károsult adja meg az első kárbejelentéskor, az adat pedig a kárügy fő rekordjába kerül. Példák 2023-03-102023-05-182023-06-25 | |||
| Kárigény állapota ClaimStatus | A kárigény aktuális állapota, például nyitott, függőben lévő vagy lezárt. | ||
| Leírás A kárigény állapota attribútum megmutatja, hol tart a kárigény az életciklusában az adott esemény időpontjában. Magas szintű képet ad a folyamat állásáról, például „Vizsgálat alatt”, „Információra vár” vagy „Rendezve”. A process mining a tevékenységekből rekonstruálja a részletes folyamatot, a kárigény állapota attribútum pedig hasznos kiegészítő kontextust ad. A folyamatmenet ellenőrzésére is használható, például annak megállapítására, hogy a „Kifizetés elindítva” tevékenység után valóban „Lezárva” állapotba kerül-e a kárigény. Azt is megmutatja, mennyi időt töltenek a kárigények az egyes állapotokban. Így kiderül, mennyi ideig maradnak függőben az ügyek, és feltárhatók a rendszerszintű késések vagy hatékonysági problémák. Miért fontos? Megmutatja a kárigény aktuális állapotát, így elemezhető az egyes szakaszokban eltöltött idő, és ellenőrizhető a folyamat menete. Hol szerezhető be? A kárigény fő rekordjának alapvető mezője, amely a kárigény életciklusa során folyamatosan frissül. Példák NyitottFüggőben, ügyféladatokra várLezárva, kifizetveLezárva, elutasítva | |||
| Kötvényszám PolicyNumber | A biztosítási kötvény egyedi azonosítója, amely alapján a kárigényt benyújtották. | ||
| Leírás A kötvényszám a bejelentett kárt fedező biztosítási szerződés egyedi azonosítója. Összekapcsolja a kárigényt az adott ügyféllel, a kötvény feltételeivel, a fedezeti limitekkel és a szerződés egyéb adataival. Bár a kötvényszámot nem mindig használják közvetlenül a folyamat elemzésekor, fontos háttéradat. Segítségével a kárigények adatai kötvény vagy ügyfél szerint összesíthetők, így például feltárhatók az egy ügyfélhez kapcsolódó gyakori kárbejelentések. A káradatok a kötvény részleteivel, például a biztosítás típusával vagy a fedezet összegével is kiegészíthetők, ami részletesebb szegmentálást és elemzést tesz lehetővé. Miért fontos? Összekapcsolja a kárigényt a megfelelő biztosítási szerződéssel, így a kötvény adataival kiegészítve részletesebb, több összefüggést feltáró elemzés végezhető. Hol szerezhető be? A kárigény bejelentésekor rögzített alapvető adat, amely a kárügy fejlécében szerepel. Példák POL-987654A-100-200-300555444333 | |||
A kárrendezés tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Első felülvizsgálat befejezve | A kijelölt ügyintéző elvégezte a kárügy első teljes körű felülvizsgálatát. Ennek során megvizsgálja a kárigény jogosságát és részleteit, majd meghatározza a szükséges további lépéseket. | ||
| Miért fontos? Ez a mérföldkő segít mérni az első értékelés és besorolás idejét. Az itt jelentkező késedelmek jelentősen növelhetik a kárügy teljes átfutási idejét. Hol szerezhető be? Az esemény gyakran a rendszer állapotváltozásából következtethető ki, például amikor az ügy állapota „Új” vagy „Kijelölve” értékről „Felülvizsgálat alatt” vagy „Vizsgálat alatt” értékre változik. Rögzítés Keressen olyan állapotváltozást, amely az első értékelési szakasz végét és az aktív feldolgozás kezdetét jelzi. Eseménytípus inferred | |||
| Kárfelmérés kész | Ez a mérföldkő azt jelzi, hogy megbecsülték a kárigény pénzügyi hatását, és tartalékot képeztek rá. Ekkor hivatalosan is felmérik a kárigény várható költségét. | ||
| Miért fontos? Ez a folyamat egyik fontos pénzügyi eseménye. A tartalék módosításainak időpontja és gyakorisága megmutatja, mennyire pontos az értékelés, és mennyire hatékony a folyamat. Hol szerezhető be? Az esemény akkor rögzül, amikor a kárigényhez tartozó pénzügyi nyilvántartásban először megadják, majd később módosítják a tartalék összegét. Rögzítés Rögzítse a kárigény pénzügyi tartalékainak naplójában szereplő első tranzakció időbélyegét. Eseménytípus explicit | |||
| Kárigény elutasítva | Ez a tevékenység a kifizetésre nem jóváhagyott kárigény végső eredményét jelzi. Az elutasító döntés után a kárigény rekordját „Elutasítva” állapottal véglegesítik. | ||
| Miért fontos? Ez a folyamat egyik fő változatának fontos lezáró eseménye. Az elutasított kárigények elemzése segít megérteni az elutasítások arányát és okait. Hol szerezhető be? Az esemény akkor rögzül, amikor a kárigény végső állapota egyértelműen „Elutasítva” vagy „Visszautasítva” értékre vált. Rögzítés Keresse meg az „Elutasítva”, „Visszautasítva” vagy hasonló végleges állapotra váltó állapotfrissítést. Ez az első döntés után is bekövetkezhet. Eseménytípus inferred | |||
| Kárigény lezárva | Ez az utolsó adminisztratív tevékenység: a kárigény aktáját a kifizetés elindítása vagy a kárigény elutasítása után lezárják. Ekkorra minden tevékenység befejeződik. | ||
| Miért fontos? Ez a folyamat elsődleges záróeseménye. Ennek alapján számítható ki az összes kárigény teljes átfutási ideje. Hol szerezhető be? A rendszerben az összes többi feldolgozási lépés után „Lezárva” vagy „Véglegesítve” állapotfrissítés jelzi. Rögzítés Keresse meg azt az időbélyeget, amikor a kárigény fő állapotmezője a végleges „Lezárva” értékre vált. Eseménytípus inferred | |||
| Kárigényről szóló döntés | A vizsgálat alapján a biztosító hivatalosan dönt a kárigény jóváhagyásáról, részleges jóváhagyásáról vagy elutasításáról. Ez az elbírálási folyamat hivatalos eredménye. | ||
| Miért fontos? Ez a döntési pont határozza meg a kárigény további útját, vagyis hogy kifizetik vagy elutasítják. A döntési idő és az eredmények elemzéséhez elengedhetetlen. Hol szerezhető be? Ezt szinte mindig egyértelmű állapotváltozás jelzi a rendszerben, például „Jóváhagyva”, „Elutasítva” vagy „Rendezve”. Rögzítés Keresse meg az első állapotfrissítést, amely végleges döntést jelző állapotra, például „Jóváhagyva” vagy „Elutasítva” értékre vált. Eseménytípus inferred | |||
| Kárügy rögzítve | Ez a tevékenység jelzi, hogy az első kárbejelentés (FNOL) után a feldolgozó rendszerben hivatalosan létrejött a kárügy rekordja. Ekkor kapja meg az ügy az egyedi Claim ID azonosítót, és hivatalosan megkezdődik a feldolgozása. | ||
| Miért fontos? Ez a kárrendezési folyamat elsődleges kezdő eseménye. Segítségével mérhető a teljes átfutási idő a hivatalos rögzítéstől a lezárásig. Hol szerezhető be? Ez az esemény általában a forrásrendszerben található elsődleges kárügyrekord vagy ügyobjektum létrehozási időbélyegéből nyerhető ki. Rögzítés Keresse meg a létrehozási eseményt vagy a kárügy előzménynaplójának első állapotfrissítését. Eseménytípus explicit | |||
| Kifizetés elindítva | Ez a tevékenység a kárigény kifizetésére szolgáló pénzügyi tranzakció végrehajtását jelzi. Ekkor indítják el a kifizetést a károsult vagy a szolgáltató felé. | ||
| Miért fontos? Ez fontos pénzügyi esemény, és gyakran a folyamat problémamentes ágának végét jelzi. A jóváhagyástól a kifizetésig eltelt idő méréséhez elengedhetetlen. Hol szerezhető be? Ezt általában külön tranzakciós naplóbejegyzés vagy a végső kifizetési állapot frissítése rögzíti, gyakran egy pénzügyi rendszerrel való integráció révén. Rögzítés Keresse meg azt az eseményt, amikor a kárigényhez tartozó kifizetési rekord állapota „Kifizetve”, „Elindítva” vagy „Folyósítva” értékre vált. Eseménytípus explicit | |||
| Kárigény újranyitva | Akkor történik, amikor egy korábban lezárt vagy elutasított kárigényt további vizsgálat vagy feldolgozás céljából újraaktiválnak. Ennek oka általában fellebbezés, új információ vagy egy hiba felismerése. | ||
| Miért fontos? Az újranyitott kárigények jelentős utómunkát jelentenek. Nyomon követésük segít feltárni a folyamat hibáit, a fellebbezések okait és a költségekre gyakorolt hatásukat. Hol szerezhető be? Ezt a „Lezárva” vagy „Elutasítva” állapotból egy aktív állapotba, például „Felülvizsgálat alatt” állapotba történő váltás jelzi. Rögzítés Keresse meg a végleges állapotból, például „Lezárva” állapotból egy aktív, nem végleges állapotba történő visszaváltást. Eseménytípus inferred | |||
| Kifizetés engedélyezve | A kiszámított kártérítési összeg kifizetésének hivatalos jóváhagyását jelenti. Ez gyakran külön lépés, amelyben vezető vagy más illetékes vesz részt a csalások megelőzése és a pontosság biztosítása érdekében. | ||
| Miért fontos? Ez fontos ellenőrzési pont. A számítás és az engedélyezés közötti idő elemzése feltárhatja a jóváhagyási folyamat szűk keresztmetszeteit vagy a megfelelési problémákat. Hol szerezhető be? Ezt a rendszerben egy külön jóváhagyási tranzakció vagy egy „Kifizetésre jóváhagyva” állapotváltozás rögzíti. Rögzítés Rögzítse a kifizetés jóváhagyásának időbélyegét, vagy a „Kifizetésre jóváhagyva” állapotra váltás időpontját. Eseménytípus explicit | |||
| Kifizetési összeg kiszámítva | A jóváhagyó döntés után ez a tevékenység a végleges kártérítési vagy kifizetési összeg kiszámítását jelenti. Az összeg a biztosítási fedezet korlátaitól, az önrésztől és a felmért károktól függ. | ||
| Miért fontos? Az itt eltelt időből kiderülhet, hol alakul ki szűk keresztmetszet a kárigényről szóló döntés és a kifizetés engedélyezése között. Ez a pénzügyi rendezés egyik fontos lépése. Hol szerezhető be? Ez valószínűleg akkor rögzül, amikor a rendszer pénzügyi moduljában megadják és jóváhagyják a végleges kifizetési vagy kártérítési összeget. Rögzítés Keresse meg, mikor adják meg a végleges kártérítési összeget, vagy mikor jön létre „Jóváhagyásra vár” állapotú kifizetési rekord. Eseménytípus explicit | |||
| További információ beérkezett | Ez az esemény jelzi a kért dokumentumok vagy információk beérkezését, amely után folytatódhat a kárügy feldolgozása. Ezzel lezárul a bekéréssel kezdődött várakozási szakasz. | ||
| Miért fontos? Ez az esemény lezárja az információbekérési ciklust. A bekérés és az információ beérkezése közötti idő fontos mutatója a külső függőségeknek és a szűk keresztmetszeteknek. Hol szerezhető be? Az esemény általában abból következtethető ki, hogy a kárügy állapota „Hiányzó információra vár” értékről ismét aktív állapotra, például „Felülvizsgálat alatt” értékre változik. Rögzítés Észlelje, amikor az állapot „Várakozás” értékről ismét aktív feldolgozási állapotra változik. Eseménytípus inferred | |||
| További információ bekérése | Ez a tevékenység akkor történik, amikor az ügyintéző úgy ítéli meg, hogy a folytatáshoz további információra van szükség a károsulttól vagy egy harmadik féltől. Ezzel gyakran várakozási szakasz kezdődik a folyamatban. | ||
| Miért fontos? Ez a tevékenység gyakran ismételt munkafolyamat vagy várakozási ciklus kezdetét jelzi. Gyakoriságának és időtartamának elemzése segít feltárni az első adatgyűjtés és a kommunikáció problémáit. Hol szerezhető be? Ezt gyakran egy konkrét állapotváltozás, például a „Hiányzó információra vár” állapot, vagy egy kimenő kommunikációs esemény naplózása rögzíti. Rögzítés Keresse meg a „Hiányzó információra vár” állapotba történő változásokat, vagy az információkéréshez kapcsolódó feladatok és kommunikációk létrehozását. Eseménytípus inferred | |||
| Ügyintéző kijelölve | Ez a tevékenység azt rögzíti, hogy a kárügyet egy adott kárrendezési ügyintézőhöz, kezelőhöz vagy csapathoz rendelték. Ezzel meghatározzák, ki felel az ügy kezeléséért annak teljes folyamata során. | ||
| Miért fontos? A kijelölések nyomon követése segít elemezni a munkaterhelés eloszlását és a csapat teljesítményét, valamint felismerni a kárügyek átadásakor jelentkező késedelmeket. Hol szerezhető be? Ezt az információt általában a kijelölési naplóban rögzítik, vagy a kárügyrekord „owner” vagy „assignee” mezőjének változásai alapján követik nyomon. Rögzítés Rögzítse a kárügyhöz tartozó felhasználó- vagy csoportkijelölési mezők frissítéseit. Eseménytípus explicit | |||
| Vizsgálat befejeződött | Ez az esemény jelzi az összes vizsgálati tevékenység lezárását, amikor már minden szükséges tényt összegyűjtöttek és dokumentáltak. Ez a lépés előfeltétele a kárügy végleges elbírálásának. | ||
| Miért fontos? Ez a mérföldkő jelzi a bizonyítékgyűjtési szakasz végét. Az eddig eltelt időből következtetni lehet a vizsgálat hatékonyságára. Hol szerezhető be? Általában akkor állapítható meg, amikor a kárigény állapota „Vizsgálat alatt” értékről döntési szakaszt jelző állapotra, például „Döntésre vár” vagy „Elbírálásra kész” értékre vált. Rögzítés Keresse meg azt az állapotváltozást, amely a vizsgálat végét és a végső döntésre való felkészültséget jelzi. Eseménytípus inferred | |||
| Vizsgálat megkezdődött | Ez a tevékenység jelzi a kárügy hivatalos, részletes vizsgálati szakaszának kezdetét. Ennek része lehet szakértők kijelölése, szemlék ütemezése vagy más bizonyítékgyűjtési tevékenység. | ||
| Miért fontos? A vizsgálat kezdetének nyomon követésével elkülöníthető és mérhető a kárrendezés gyakran összetett és időigényes szakaszának időtartama. Hol szerezhető be? Ez az esemény gyakran abból következtethető ki, hogy a kárügy állapota „Vizsgálat alatt” vagy hasonló értékre változik, illetve létrejön az első vizsgálathoz kapcsolódó feladat. Rögzítés Keresse meg a „Vizsgálat alatt” állapotba történő változást vagy az első hivatalos vizsgálati feladat létrehozását. Eseménytípus inferred | |||
Adatkinyerési útmutatók
Az adatkinyerési módszerek rendszerenként eltérnek. Részletes útmutatásért
olvassa el az ETL-útmutatónkat vagy válasszon ki egy konkrét folyamatot és rendszert.
Kezdheti?
Kezdje el fejleszteni a kárrendezést: válasszon egy rendszerhez készült adatkinyerési útmutatót, vagy készítse elő az eseménynaplót az általános minta alapján.
Vegye kézbe a folyamatokat, javítsa a teljesítményt
Találja meg a hatékonysági problémákat, fejlessze a működést, és érje el gyorsabban a céljait.
Nincs szükség bankkártyára. Kezdje el még ma a folyamatok fejlesztését.