Kárigénykezelési adatgyűjtési sablon
Kárigénykezelési adatgyűjtési sablon
- Javasolt attribútumok
- Követendő fő tevékenységek
- Adatkinyerési útmutató a Duck Creek Claims rendszerhez
A kárigénykezelés attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időpontja EventTime | Az az időbélyeg, amely megadja, mikor történt egy adott tevékenység vagy esemény. | ||
| Leírás Az esemény időpontja pontos dátumot és időt rendel a kárigény életciklusában rögzített minden tevékenységhez. Ez az időadat elengedhetetlen a teljesítmény elemzéséhez. Az elemzés során az időbélyeg alapján számítható ki a tevékenységek közötti átfutási idő, azonosíthatók a várakozási idők, mérhető az ügy teljes időtartama, és vizsgálható a folyamat teljesítménye különböző időszakokban. Minden időalapú folyamatmutató erre épül. Miért fontos? Ez az időbélyeg szükséges minden időalapú mutató, például az átfutási idők és időtartamok kiszámításához. Lehetővé teszi a teljesítmény elemzését és a szűk keresztmetszetek feltárását. Hol szerezhető be? Ez egy szabványos időbélyegmező a Duck Creek Claims esemény- vagy tranzakciónaplóiban. Keresse például a „CreateDate”, „Timestamp” vagy „EventDate” mezőt. Példák 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Kárigényazonosító ClaimId | Egy biztosítási kárigény egyedi azonosítója, amely elsődleges ügyazonosítóként szolgál. | ||
| Leírás A Claim ID az az alapvető azonosító, amely a benyújtástól a lezárásig összekapcsolja az egy biztosítási kárigényhez tartozó összes eseményt és tevékenységet. Így a kárigény teljes életciklusa egységesen nyomon követhető. A process mining elemzésben ez az attribútum szükséges az ügy nézetének összeállításához. Segítségével az elemzők végigkövethetik az egyes kárigények teljes útját, mérhetik a teljes átfutási időt, és elemezhetik a folyamatváltozatokat. Miért fontos? Ez az alapvető Case ID kapcsolja össze a folyamat összes kapcsolódó eseményét, így a kárigény teljes életciklusa elejétől a végéig áttekinthető. Hol szerezhető be? Ez a Duck Creek Claims fő kárigény-entitásának vagy -táblájának elsődleges kulcsa. A pontos táblanévért és mezőnévért tekintse meg a rendszer dokumentációját. Példák CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Tevékenység neve ActivityName | A kárigénnyel kapcsolatban egy adott időpontban végrehajtott üzleti tevékenység vagy bekövetkezett esemény neve. | ||
| Leírás Ez az attribútum a kárrendezési folyamat egy adott lépését vagy feladatát írja le, például: „Kárigény benyújtva”, „Kárszakértő kijelölve” vagy „Kifizetés elindítva”. Minden tevékenység a kárigény életciklusának egy különálló pontját jelöli. A tevékenységek sorrendjének és gyakoriságának elemzése a process mining alapja. Segítségével feltárhatók a folyamatmodellek, azonosíthatók a szűk keresztmetszetek, felismerhetők az utómunka ismétlődő körei, és elemezhetők a szabványos modelltől való eltérések. Miért fontos? A tevékenység neve határozza meg a folyamat lépéseit, ezért alapvető a kárrendezés feltárásához, elemzéséhez és nyomon követéséhez. Hol szerezhető be? Általában a Duck Creek Claims eseménynaplóiból, tranzakcióneveiből vagy állapotváltozási rekordjaiból származik. Előfordulhat, hogy több forrásmezőt vagy táblát kell összerendelni. Példák Kárigény benyújtvaKárszakértő kijelölveVizsgálat megkezdveKifizetés elindítvaKárigény lezárva | |||
| Kár súlyossága ClaimSeverity | A kárigény pénzügyi vagy működési összetettségének besorolása, például alacsony, közepes vagy magas. | ||
| Leírás A kár súlyossága a kárigény várható hatását vagy összetettségét jelzi. Meghatározható a kezdeti kárbecslés, az esemény jellege vagy más előre meghatározott üzleti szabályok alapján. Ez az attribútum fontos a teljesítmény elemzéséhez, mert a súlyosabb károk általában több lépést, hosszabb ügyintézést és speciális erőforrásokat igényelnek. A KPI-ok súlyosság szerinti csoportosítása segít reális teljesítménycélokat kitűzni, és megérteni, hogyan hat az összetettség a folyamat hatékonyságára és eredményére. Miért fontos? Segít a kárigények összetettség szerinti csoportosításában, így részletesebb teljesítményelemzés és reálisabb átfutásiidő- és költség-összehasonlítás végezhető. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Ez lehet külön mező, vagy a kezdeti kártartalék összegéből is származtatható. Példák AlacsonyKözepesMagasKatasztrofális | |||
| 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 annak aktuális helyzetét mutatja az ügyintézés során. Röviden összefoglalja, hol tart a kárigény a teljes folyamatban. Ez az attribútum hasznos a kárigényállomány áttekintéséhez és az esetek szűréséhez. Különösen fontos a végső kimenetel azonosításához, például „Lezárva, kifizetve” vagy „Lezárva, elutasítva”. Ez elengedhetetlen az eredmények elemzéséhez és az elutasítási arány megértéséhez. Miért fontos? Megmutatja a kárigény aktuális állapotát és végső kimenetelét, ami nélkülözhetetlen az eredmények elemzéséhez és az esetek szűréséhez. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Ez alapvető mező a fő kárigényrekordon. Példák NyitottFüggőben, adatokra várLezárva, rendezveLezárva, elutasítva | |||
| Kárigény típusa ClaimType | A biztosítási kárigény kategóriája, például gépjármű-, vagyon- vagy felelősségi kár. | ||
| Leírás A kárigény típusa az üzletág vagy a kár jellege alapján sorolja kategóriákba a kárigényeket. Ez alapvető szempont a káradatok csoportosításához és elemzéséhez. Az attribútummal összehasonlítható a különböző kárigénytípusok folyamatának teljesítménye. Például a „Personal Auto - Collision” kárigény folyamata jelentősen eltér a „Property - Water Damage” kárigényétől, és más KPI-ok vonatkoznak rájuk. A kárigény típusa kontextust ad, így érdemibb teljesítmény-összehasonlítás és célzott folyamatfejlesztés végezhető. Miért fontos? Ez fontos szempont az elemzés csoportosításához, mert az egyes kárigénytípusok folyamatai, SLA-i és összetettsége gyakran eltérnek. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Ez a fő kárigényrekord egyik alapvető attribútuma. Példák Személygépkocsi, ütközésKereskedelmi ingatlan, tűzkárMunkahelyi baleseti kártérítésÁltalános felelősségbiztosítás | |||
| Kárösszeg LossAmount | A kárigényben bejelentett veszteség becsült vagy tényleges pénzösszege. | ||
| Leírás Ez az attribútum a kárigényhez kapcsolódó veszteség kezdeti becsült értékét mutatja. Fontos pénzügyi mutató, amely gyakran befolyásolja a kárigény útvonalát, súlyossági besorolását és a szükséges vizsgálat mélységét. Az elemzés során a kárösszeg alapján csoportosíthatók a kárigények, és megvizsgálható, hogyan függ össze a pénzügyi hatás a folyamat alakulásával. A nagyobb összegű kárigények például más útvonalon haladhatnak, vagy hosszabb átfutási idővel járhatnak. Az adat pénzügyi összefüggésbe helyezi a működési folyamat adatait. Miért fontos? Pénzügyi összefüggésbe helyezi a kárigényt, így elemezhető, hogyan hat az összeg az ügyintézés útvonalára, időtartamára és kimenetelére. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Ez alapvető pénzügyi mező a kárigényrekordon, gyakran „Bejelentett kár” vagy „Kezdeti tartalék” néven. Példák 1500.0025000.50125000.00 | |||
| Kijelölt kárszakértő AssignedAdjuster | Az adott tevékenység idején a kárigény kezeléséért felelős kárszakértő neve vagy azonosítója. | ||
| Leírás Ez az attribútum azonosítja a tevékenységet végző felhasználót vagy erőforrást. A kárigény életciklusa során változhat, amikor az ügyet másik kárszakértőnek vagy csapatnak adják át. Az attribútum fontos az erőforrások teljesítményének, a munkaterhelés eloszlásának és az átadásoknak az elemzéséhez. A kárszakértők áteresztőképességét, a munkaterhelés eltéréseit és a szűk keresztmetszeteket vizsgáló dashboardok gyakran erre támaszkodnak annak megértéséhez, hogyan osztják el és dolgozzák fel az egyes felhasználók a munkát. Miért fontos? Lehetővé teszi az erőforrások teljesítményének, a munkaterhelés kiegyensúlyozásának és az együttműködésnek az elemzését, így feltárhatók a szűk keresztmetszetek és a képzési igények. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Keresse a felhasználót, felelőst vagy kijelölt személyt jelölő mezőket a kárigény-feladatokhoz, eseményekhez vagy a fő kárigény-entitáshoz kapcsolódó táblákban. Példák John SmithJane DoeRobert Brownadjuster_1138 | |||
| Részleg Department | Az adott időpontban a tevékenységért vagy a kárigényért felelős részleg vagy csapat. | ||
| Leírás Ez az attribútum azt a szervezeti egységet vagy részleget jelöli, amely a kárigényt kezeli, például „Initial Intake”, „Investigation Unit” vagy „Settlement Team”. Szervezeti hátteret ad a folyamat áttekintéséhez. A részlegenkénti elemzés segít megérteni a folyamat teljesítményét összesített szinten. Feltárja a részlegek közötti szűk keresztmetszeteket, méri a csapatok hatékonyságát, és megmutatja, hogyan halad át a munka a szervezeten. Miért fontos? Lehetővé teszi a teljesítmény funkcionális területenkénti elemzését, és megmutatja a részlegek közötti átadásokat, valamint a csapatszintű szűk keresztmetszeteket. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Ez az információ gyakran a kijelölt felhasználó profiljához vagy egy várólistához, illetve munkacsoporthoz való hozzárendeléshez kapcsolódik. Példák Gépjármű-kárrendezésVagyonkárok, nagy összegű károkKülönleges vizsgálati egységKifizetések feldolgozása | |||
| Adatok utolsó frissítése LastDataUpdate | A forrásrendszerből érkező legutóbbi adatfrissítés időbélyege. | ||
| Leírás Ez az attribútum jelzi, mikor frissült utoljára az adatkészlet. Támpontot ad az elemzett adatok aktualitásáról. A dashboardokon és az elemzésekben tájékoztatja a felhasználókat arról, mennyire frissek az eredmények. Segít megítélni, hogy a legutóbbi tranzakciók is szerepelnek-e a folyamat nézetében. Miért fontos? Tájékoztatja a felhasználókat az adatok aktualitásáról, ami fontos az elemzés értelmezéséhez és az időben meghozott döntésekhez. Hol szerezhető be? Ez az időbélyeg az adatok kinyerése, átalakítása és betöltése (ETL) során jön létre, és általában az adatkészlet metaadatai között tárolják. Példák 2024-05-21T02:00:00Z | |||
| Automatizált? IsAutomated | Logikai jelző, amely megmutatja, hogy a tevékenységet a rendszer emberi beavatkozás nélkül hajtotta-e végre. | ||
| Leírás Ez a jelző megkülönbözteti az emberi felhasználók által végzett feladatokat a rendszerautomatizálással végrehajtottaktól. Ilyen lehet az automatikus értesítés, az első adatellenőrzés vagy az emberi beavatkozás nélküli feldolgozás. Az attribútum elemzésével felmérhető, milyen mértékben automatizált a kárigénykezelés. Segít mérni az automatizálási kezdeményezések hatását, feltárni a további automatizálás lehetőségeit, és ellenőrizni, hogy az automatizált lépések a későbbi folyamatok megzavarása nélkül működnek-e. Miért fontos? Segít mérni, hogyan hat az automatizálás a hatékonyságra és a költségekre, valamint feltárni az emberi beavatkozás nélküli feldolgozás lehetőségeit. Hol szerezhető be? Az adat kikövetkeztethető az eseményhez rendelt „user” mezőből, például „SYSTEM” vagy „BATCH” értékből, illetve az eseményrekord külön jelzőjéből. Példák truefalse | |||
| Befejezés időpontja EndTime | Az időbélyeg, amely megmutatja, mikor fejeződött be egy tevékenység. | ||
| Leírás Ez az attribútum rögzíti a tevékenység befejezésének időpontját. A StartTime a kezdést jelzi, az EndTime pedig az adott feladat időtartamának kiszámításához szükséges másik időpontot adja meg. A process mining során a tevékenységek kezdési és befejezési időpontja részletesebb teljesítményelemzést tesz lehetővé. Pontosan kiszámítható a „Feldolgozási idő”, vagyis a feladaton végzett aktív munka, és a „Várakozási idő”, vagyis a feladatok közötti idő. Ez a különbségtétel elengedhetetlen a szűk keresztmetszetek pontos azonosításához. Miért fontos? Lehetővé teszi a tevékenységek feldolgozási idejének pontos kiszámítását, és elkülöníti az aktív munkát a tétlen vagy várakozási időtől. Ez elengedhetetlen a szűk keresztmetszetek pontos elemzéséhez. Hol szerezhető be? Az eseménynapló külön időbélyegmezőként tartalmazhatja, vagy az adott eset következő tevékenységének StartTime értékéből származtatható. Példák 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Elutasítás oka RejectionReason | A kárigény elutasításának konkrét oka. | ||
| Leírás Ha a döntés a kárigény elutasítása, ez az attribútum rögzíti a döntés okát. Az értéket általában előre meghatározott kódok vagy leírások listájából választják ki. Az elutasítási okok elemzése elengedhetetlen a „Kárigénydöntések és elutasítások elemzése” dashboardhoz. Segít feltárni a benyújtások gyakori problémáit, a lehetséges csalási mintákat, valamint azokat a területeket, ahol a biztosítási feltételek nem egyértelműek. Az eredmények alapján javítható a kárbejelentés fogadása és a kockázatelbírálás szabályrendszere. Miért fontos? Megmutatja, miért utasítják el a kárigényeket. Az eredmények alapján javítható a kárbejelentés fogadása, csökkenthetők a hibás benyújtások, és azonosíthatók a képzési igények. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Ez a mező általában akkor kap értéket, amikor a kárigény állapota „Elutasítva” vagy hasonló értékre változik. Példák A biztosítás nem terjed ki az eseményreLejárt biztosítási kötvényDuplikált kárigényCsalás gyanúja | |||
| Forrásrendszer SourceSystem | A rendszer, amelyből az eseményadatokat kinyerték. | ||
| Leírás Ez az attribútum azonosítja a forrásalkalmazást, ahonnan a kárigény adatai származnak. Ebben az esetben az értéke mindig „Duck Creek Claims”. Ha minden adat egyetlen rendszerből származik, ez feleslegesnek tűnhet, de fontos az adatirányítás és a nyomon követhetőség szempontjából, valamint akkor is, ha később több rendszer adatait kell összekapcsolni. Megmutatja az adatok eredetét és szerkezetét. Miért fontos? Megadja az adatok eredetét és hátterét, ami fontos az adatirányításhoz és a hibakereséshez, különösen több integrált rendszer használatakor. Hol szerezhető be? Ez általában az adatok kinyerése és átalakítása során hozzáadott állandó érték, amely az adatok eredetét jelöli. Példák Duck Creek Claims | |||
| Határidőre történt a rendezés? IsOnTimeResolution | Számított jelző, amely megmutatja, hogy a kárigényt a rendezési céldátumig vagy az előtt lezárták-e. | ||
| Leírás Ez a logikai attribútum a „Kárigény lezárása” tevékenység időbélyegének és az adott kárigény ResolutionTargetDate értékének összevetésével számítható ki. Minden kárigényt határidőben lezártként (true) vagy késedelmesként (false) jelöl. Az attribútum közvetlenül támogatja az „Időben rendezett kárigények aránya” KPI-t. Segítségével egyszerűen összesíthető és megjeleníthető az SLA-k betartása a dashboardokon, valamint részletesen elemezhetők a késedelmes kárigények közös jellemzői, például a kárigény típusa, az osztály vagy a folyamat útvonala. Miért fontos? Kárigényenként méri az SLA-k betartását, így könnyen szűrhetők a határidőn túli esetek, és elemezhetők azok kiváltó okai. Hol szerezhető be? Ez a mező nem szerepel a forrásrendszerben. Az adat-előkészítés során számítható ki a végső tevékenység időbélyegének és a ResolutionTargetDate mezőnek az összevetésével. Példák truefalse | |||
| Kártérítési összeg SettlementAmount | A kárigény rendezéséről megállapodott végleges pénzösszeg. | ||
| Leírás Ez az attribútum rögzíti a kiszámított és kifizetésre jóváhagyott kártérítés összegét. A kifizetéssel záruló kárigények egyik fontos eredménymutatója. Az adat elengedhetetlen a pénzügyi elemzéshez és az olyan dashboardokhoz, mint a „Kifizetés jóváhagyásának és teljesítésének ideje”. A kezdeti kárösszeggel összevetve elemezhető a tartalékbecslés pontossága, és segít megérteni a kárigénykezelés pénzügyi eredményeit. Miért fontos? A kárigény pénzügyi eredményét mutatja. Elengedhetetlen a pénzügyi jelentésekhez és a kezdeti kárbecslések pontosságának elemzéséhez. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Ez az adat általában a kárigényhez kapcsolódó pénzügyi tranzakciós vagy kifizetési táblákban található. Példák 1450.7522000.00115800.20 | |||
| Kötvényszám PolicyNumber | Annak a biztosítási kötvénynek az egyedi azonosítója, amely alapján a kárigényt benyújtották. | ||
| Leírás Ez az attribútum összekapcsolja a kárigényt az alapjául szolgáló biztosítási kötvénnyel. Megmutatja a kárigényhez tartozó fedezetet, feltételeket és ügyfelet. A kötvényszámot nem mindig használják közvetlenül a folyamat elemzéséhez, de értékes kiegészítő adat. Segítségével összekapcsolhatók a kárigény-, kötvény- és ügyféladatok, így elemezhető, hogyan változik a folyamat teljesítménye ügyfélszegmens, kötvénytípus vagy a kötvény kora szerint. Ez teljesebb képet ad az üzleti működésről. Miért fontos? Összekapcsolja a kárigényt az ügyféllel és a kötvénnyel, így elemezhető, hogyan hat a folyamat teljesítménye az egyes ügyfélszegmensekre és kötvénytípusokra. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Ez egy szabványos hivatkozási mező a fő kárigényrekordon. Példák PA-987654321CP-123456789WC-555444333 | |||
| Rendezés céldátuma ResolutionTargetDate | Az a céldátum, ameddig a kárigényt várhatóan rendezik az SLA-k vagy belső célok alapján. | ||
| Leírás Ez az attribútum tárolja a kárigény lezárásának határidejét. A dátumot gyakran jogszabályi előírások, szolgáltatási szintű megállapodások (SLA-k) vagy belső teljesítménymutatók (KPI-k) határozzák meg. A kárigény típusától és súlyosságától függően eltérhet. Ez az adat szolgál az „Időben rendezett kárigények aránya” KPI kiszámításának alapjául, és támogatja a „Kárigények rendezési határidejének betartása” dashboardot. Segítségével előre nyomon követhetők az SLA túllépésének kockázatával érintett kárigények, és rangsorolható a munka. Miért fontos? Lehetővé teszi a szolgáltatási szintű megállapodások (SLA-k) és a belső célok teljesítésének mérését, ami közvetlenül hat az ügyfelek elégedettségére és a megfelelésre. Hol szerezhető be? Tekintse meg a Duck Creek Claims dokumentációját. Az adat külön SLA-dátummezőben szerepelhet, vagy a kárigény benyújtásának dátuma és az üzleti szabályok alapján számítható ki. Példák 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
| Újramunkálás? IsRework | Számított jelző, amely megmutatja, hogy a tevékenység része-e egy újramunkálási ciklusnak. | ||
| Leírás Ez a logikai attribútum akkor kap true értéket, ha egy tevékenység megismétlődik a kárigény során, miután már más tevékenységek is történtek. Például a folyamat a „Kár felmérése” lépésből visszatér a „Vizsgálat megkezdése” lépéshez. Az attribútum elengedhetetlen az újramunkálás méréséhez és elemzéséhez. Támogatja a „Kárigények újramunkálási aránya” KPI-t és a „Kárigények újramunkálási és ismételt feldolgozási mintái” dashboardot. Segítségével közvetlenül szűrhetők és kiemelhetők az újramunkálással érintett tevékenységek és esetek, így feltárhatók a folyamat hatékonysági és minőségi problémái. Miért fontos? Tevékenységszinten méri az újramunkálást, így egyszerűen elemezhetők és megjeleníthetők a folyamat hatékonysági problémáinak okai és hatásai. Hol szerezhető be? Ez a mező nem szerepel a forrásrendszerben. Az adat-előkészítés során olyan algoritmusokkal számítható ki, amelyek azonosítják az eseteken belüli ismétlődő tevékenységsorozatokat. Példák truefalse | |||
A kárigénykezelés tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Kárigény benyújtva | Ez az első esemény, amely azt jelzi, hogy a biztosító megkapta az első kárbejelentést (First Notice of Loss, FNOL). Általában külön tranzakcióként rögzül, amikor az ügynök vagy a szerződő megadja a rendszerben a kárigény kezdeti adatait. | ||
| Miért fontos? Ez a tevékenység jelöli a teljes kárrendezési folyamat kezdetét. Az esemény és a későbbi események közötti idő elemzése segít megérteni a teljes ügyintézési időt és az adatfelvétel hatékonyságát. Hol szerezhető be? Ez általában külön eseményként jelenik meg a kárrendezési vagy FNOL-naplóban, amikor a Duck Creek Claims rendszerben létrejön az új kárigény rekordja. Rögzítés Az új kárigény rekordjának létrehozásakor naplózott esemény. Eseménytípus explicit | |||
| Kárigény elutasítva | Ez a tevékenység a folyamat egyik lehetséges lezárását jelöli, amikor hivatalosan elutasítják a kárigényt. Akkor rögzül, amikor a kárigény végleges állapota „Denied” vagy „Rejected” értékre változik. | ||
| Miért fontos? Ez fontos eredmény, amelyet külön kell elemezni. Az elutasítás okainak és időpontjának megértése segít javítani az adatfelvételt és biztosítani a megfelelést. Hol szerezhető be? A kárigény entitástáblájában rögzített időbélyegből következtethető ki, amikor a végleges állapot „Denied”, „Rejected” vagy „Closed without Payment” értékre változik. Rögzítés A kárigény végleges elutasítási állapotából következtethető ki. Eseménytípus inferred | |||
| Kárigény lezárva | Ez az utolsó tevékenység: a káraktát a kifizetés után vagy a kárrendezés befejeztével adminisztratív úton lezárják. Ezt a végleges „Closed” állapot rögzíti. | ||
| Miért fontos? Ez a tevékenység jelöli a folyamat sikeres lezárását. Ez a végpontja az „Average End-to-End Claim Cycle Time” és más fontos időtartam-mutatók számításának. Hol szerezhető be? A kárigény fő adattáblájában rögzített időbélyegből következtethető ki, amikor a végleges állapot „Closed” vagy „Settled” értékre változik. Rögzítés A kárigény „Closed” végleges állapotából következtethető ki. Eseménytípus inferred | |||
| Kárigényről döntés született | Ez a tevékenység a kárigény hivatalos elbírálását jelöli, például „Approved”, „Partially Approved” vagy „Denied” eredménnyel. Ez fontos mérföldkő, amelyre a végleges döntési állapotra váltásból lehet következtetni. | ||
| Miért fontos? Ez a döntéshozatal egyik fontos mérföldköve. A döntésig eltelt idő és annak eredménye alapvető a folyamat elemzéséhez és hatékonyságának értékeléséhez. Hol szerezhető be? A külön „Claim Decision” vagy „Claim Status” mező végleges állapotra, például „Approved” vagy „Denied” értékre váltásából következtethető ki. A módosítás időbélyege rögzül. Rögzítés A kárigény elsődleges állapot- vagy döntési mezőjének módosításából következtethető ki. Eseménytípus inferred | |||
| Kifizetés elindítva | Ez a tevékenység jelöli a kárigény kifizetésére irányuló pénzügyi tranzakció végrehajtását. Egyértelmű, külön eseményként rögzül, amikor a kifizetést csekken, elektronikus átutalással vagy más módon elindítják. | ||
| Miért fontos? Ez jelzi, hogy a jóváhagyott kárigényhez kapcsolódó pénzügyi kötelezettség teljesült. A „Payment Authorized” és a „Payment Issued” közötti idő megmutatja a pénzügyi részleg ügyintézésének hatékonyságát. Hol szerezhető be? A Duck Creek Claims pénzügyi tranzakciós táblájából nyerhető ki, amely minden kimenő kifizetést külön tranzakciókóddal és időbélyeggel rögzít. Rögzítés A kifizetés feldolgozásakor külön pénzügyi tranzakciónapló-bejegyzés jön létre. Eseménytípus explicit | |||
| Kifizetés engedélyezve | A kiszámított kártérítési összeg kifizetésének hivatalos jóváhagyását jelöli. Ez gyakran külön lépés, amelyben vezető vagy más illetékes vesz részt, és külön jóváhagyási tranzakcióként rögzül. | ||
| Miért fontos? Ez fontos ellenőrzési pont, és a kifizetés előtti szűk keresztmetszet is lehet. A „Claim Decision Made” eseménytől eddig a pontig eltelt időt az „Average Claim Approval Time” KPI méri. Hol szerezhető be? Ez általában külön eseményként jelenik meg egy workflow- vagy pénzügyi modulban, amikor egy megfelelő jogosultságú felhasználó jóváhagyja a kifizetést. A jóváhagyási naplóban található meg. Rögzítés Workflow- vagy tranzakciónaplóban rögzített külön jóváhagyási esemény. Eseménytípus explicit | |||
| Első felülvizsgálat befejezve | A kijelölt kárszakértő első, teljes körű kárigény-felülvizsgálatának befejezését jelöli. Erre általában a kijelölés utáni állapotváltozásból lehet következtetni, például amikor az állapot „Assigned” értékről „Under Review” vagy „Investigation” értékre vált. | ||
| Miért fontos? Ez a mérföldkő segít mérni, mennyi idő telik el a kárszakértő első intézkedéséig, és jelezheti a felhalmozódott ügyhátralékot. Ez az első jelentős, emberi közreműködést igénylő ellenőrzési pont. Hol szerezhető be? A kárigény állapotmezőjének változásából következtethető ki, például amikor az állapot „Initial Review Complete” vagy „Pending Information” értékre vált. Az időbélyeg a módosítás időpontja. Rögzítés A kárszakértő kijelölése utáni állapotváltozásból következtethető ki. Eseménytípus inferred | |||
| Kárigény regisztrálva | A benyújtott kárigény hivatalos elfogadását és regisztrálását jelöli. Ekkor kapja meg az ügy az egyedi kárigényazonosítót. Ez gyakran automatikus rendszeresemény, amely az első adatellenőrzést követi. | ||
| Miért fontos? Hivatalosan elindítja a kárigény ügyintézését, és elindítja a további folyamatokat, például a kárszakértő kijelölését. A benyújtás és a regisztrálás közötti idő az adatok kezdeti minőségére vagy a rendszer terheltségére utalhat. Hol szerezhető be? A fő kárigényrekordban rögzített időbélyegből következtethető ki, amikor létrejön az elsődleges Claim ID, és a kárigény állapota „pending” vagy „submitted” értékről „open” vagy „registered” értékre változik. Rögzítés Az elsődleges kárigényrekord létrehozási időbélyegéből vagy az „Open” állapotra váltásból származtatható. Eseménytípus inferred | |||
| Kárösszeg felmérve | Ez a mérföldkő azt jelöli, amikor a vizsgálat eredményei alapján meghatározzák vagy módosítják a pénzügyi tartalékot. Ekkor becsülik meg a kárigény pénzügyi hatását, amit a tartalékösszeg megadásakor vagy módosításakor rögzítenek. | ||
| Miért fontos? Ez fontos pénzügyi ellenőrzési pont a folyamatban. Az időpont elemzése megmutatja, milyen gyorsan történik a pénzügyi értékelés, és mennyire pontos. Hol szerezhető be? Ez gyakran külön pénzügyi tranzakcióként szerepel a Duck Creek Claims rendszer kárigényhez tartozó pénzügyi tranzakciós naplójában vagy tartalékelőzmény-táblájában. Rögzítés A kárigény-tartalék meghatározásakor vagy módosításakor naplózott pénzügyi tranzakció. Eseménytípus explicit | |||
| Kárszakértő kijelölve | Ez az esemény rögzíti, hogy a regisztrált kárigényhez kárszakértőt vagy ügyintézőt rendeltek. A rendszer naplózza a kijelölést, így egyértelmű átadási pont jön létre, és meghatározható, ki felel az ügyért annak teljes életciklusa során. | ||
| Miért fontos? Az esemény fontos az erőforrások elosztásának és a kárszakértők munkaterhelésének elemzéséhez, valamint a kijelölési késedelmek feltárásához. Ez egy fontos átadási pont, ahol várakozás alakulhat ki. Hol szerezhető be? A fő kárigény-adattáblában az „Assigned Adjuster” mező módosításával követhető. A mező előzményeit vagy auditnaplóját használhatja az időbélyeg meghatározásához. Rögzítés Az auditnapló rögzíti, amikor kitöltik vagy módosítják a kárszakértő mezőjét. Eseménytípus explicit | |||
| Kártéríté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 jelöli. Ez lehet külön lépés, vagy a rendszer pénzügyi moduljában szereplő összegek véglegesítéséből lehet rá következtetni. | ||
| Miért fontos? Ez a tevékenység fontos a „Settlement Rework Rate” KPI méréséhez. Ha egy kárigénynél többször is előfordul, az a kárrendezési szakasz hatékonysági problémáira, hibáira vagy egyeztetéseire utalhat. Hol szerezhető be? Külön tranzakciónapló-bejegyzésként jelenhet meg, vagy a kárigény pénzügyi adataiban szereplő „Settlement Amount” mező módosításából következtethető ki. Elsődleges forrásként a mező auditnaplója használható. Rögzítés A végleges kifizetési összeg kiszámításakor és mentésekor naplózott esemény. Eseménytípus explicit | |||
| További információ beérkezett | Az esemény a kért információ beérkezését jelöli, amely után folytatódhat a kárigény ügyintézése. A kárszakértő kézzel is rögzítheti, de digitális portálon történő benyújtás esetén automatikusan is naplózódhat. | ||
| Miért fontos? Az „Information Requested” és az „Information Received” közötti idő fontos várakozási időszak. Ennek elemzése segít feltárni a külső függőségeket és a kommunikációs szűk keresztmetszeteket. Hol szerezhető be? Az esemény származhat dokumentumkezelő rendszer integrációjából, vagy a kárszakértő kézi naplóbejegyzéséből, illetve a dokumentumok beérkezésekor végrehajtott állapotmódosításból. Rögzítés Dokumentumfeltöltéskor vagy a kárszakértő kézi bejegyzésekor naplózott esemény. Eseménytípus explicit | |||
| További információ kérése | Ez a tevékenység akkor történik, amikor a kárszakértő további információt kér a szerződőtől vagy egy harmadik féltől. Az esemény gyakran külön bejegyzésként jelenik meg a rendszer kommunikációs vagy levelezési moduljában. | ||
| Miért fontos? Ha ez a tevékenység gyakran fordul elő, az a kezdeti adatgyűjtés problémáira utalhat. Jelentős várakozási időt is okoz, ami növeli a teljes átfutási időt. Hol szerezhető be? A kimenő kommunikáció naplóiból, például levelekből és e-mailekből, vagy a Duck Creek Claims rendszer „Request for Information” tranzakciójából nyerhető ki. Rögzítés A rendszer akkor naplózza, amikor létrejön az információkéréshez kapcsolódó levelezés vagy feladat. Eseménytípus explicit | |||
| Vizsgálat befejezve | A vizsgálati tevékenységek lezárását jelöli, amikor már minden szükséges tényt összegyűjtöttek. Erre általában abból lehet következtetni, hogy a kárigény állapota „Under Investigation” értékről döntést előkészítő állapotra, például „Pending Decision” értékre vált. | ||
| Miért fontos? A vizsgálat lezárása fontos mérföldkő, amely lehetővé teszi a döntéshozatali és kárrendezési szakasz megkezdését. Az itt jelentkező késedelmek jelentősen kihatnak a további lépésekre. Hol szerezhető be? A kárigény állapotának „investigation” értékről „review” vagy „decision” értékre váltásakor rögzített időbélyegből következtethető ki. Rögzítés A vizsgálati tevékenységek végét jelző állapotváltozásból származtatható. Eseménytípus inferred | |||
| Vizsgálat megkezdve | Ez a tevékenység jelzi a kárigény hivatalos vizsgálati szakaszának kezdetét. Erre gyakran abból lehet következtetni, hogy a kárigény állapota „Under Investigation” vagy hasonló értékre változik. | ||
| Miért fontos? Ezzel kezdetét veszi az erőforrás-igényes szakasz. A vizsgálat időtartamának mérése fontos az „Average Investigation Duration” KPI-hoz, és segít a folyamat egyik meghatározó részének kezelésében. Hol szerezhető be? A fő kárigény-állapotmező „Investigation in Progress” vagy „Pending Inspection” értékre váltásának időbélyegéből következtethető ki. Rögzítés A vizsgálati tevékenységek kezdetét jelző állapotváltozásból származtatható. Eseménytípus inferred | |||
Adatkinyerési útmutatók
Lépések
- Nyissa meg a Duck Creek Data Hub Configuration Utility alkalmazást: Jelentkezzen be a Duck Creek környezetbe, majd nyissa meg a Data Hub alkalmazást. Az adatexportálási beállítások létrehozásához vagy módosításához megfelelő jogosultságokra lesz szüksége.
- Hozzon létre új adatexportálási feladatot: A Data Hub segédprogramban indítsa el egy új exportálási feladat létrehozását. Adjon neki beszédes nevet, például ProcessMind_Claims_Event_Log_Export.
- Adja meg az adatforrást: Állítsa be a feladatot úgy, hogy csatlakozzon az elsődleges Data Hub SQL-adatbázishoz. Adja meg a kiszolgáló és az adatbázis nevét, valamint egy olyan felhasználó hitelesítő adatait, akinek olvasási jogosultsága van az érintett sémákhoz.
- Adja meg a kinyerési lekérdezést: Nyissa meg az exportálási feladat lekérdezésdefiníciós részét. Másolja ki az alábbi lekérdezési szakaszban található teljes szkriptet, majd illessze be a lekérdezésszerkesztőbe.
- Állítsa be a lekérdezés paramétereit: Keresse meg a konfiguráció paraméterszakaszát. Adja meg az @StartDate és az @EndDate paraméter értékét, amelyekre a lekérdezés hivatkozik. Ezek határozzák meg a kívánt kinyerési időszakot. Például: '2023-01-01' és '2023-12-31'.
- Rendelje hozzá a kimeneti oszlopokat: Állítsa be a kimeneti fájl beállításait. Ellenőrizze, hogy a SELECT utasításban megadott oszlopok (ClaimId, ActivityName, EventTime stb.) megfelelően szerepelnek-e a kimeneti fájlban. A fájl fejlécében pontosan ezek a nevek szerepeljenek.
- Állítsa be a kimeneti fájlt: Válassza ki a CSV formátumot. Az elválasztó vessző (,) legyen, a karakterkódolás pedig UTF-8, hogy a fájl kompatibilis legyen a ProcessMinddel.
- Adja meg a célhelyet: Adja meg azt a fájlútvonalat vagy hálózati helyet, ahová a létrehozott CSV-fájl kerül. Ellenőrizze, hogy a rendszer rendelkezik-e írási jogosultsággal ezen a helyen.
- Ütemezze az exportálási feladatot: Állítsa be a feladat ütemezését. Az első elemzéshez kézzel is futtathatja. A folyamatos nyomon követéshez állítson be ismétlődő ütemezést, például napi vagy heti futtatást.
- Futtassa a feladatot, és töltse le a fájlt: Futtassa a feladatot az eseménynapló létrehozásához. Ha elkészült, töltse le a CSV-fájlt a 8. lépésben megadott célhelyről.
- Készítse elő a fájlt feltöltésre: A ProcessMindbe való feltöltés előtt nyissa meg a CSV-fájlt, és végezzen végső ellenőrzést. Ellenőrizze a fejléceket, a dátumformátum egységességét (YYYY-MM-DD HH:MI:SS), valamint azt, hogy az adatok a várakozásoknak megfelelően jelennek-e meg.
Konfiguráció
- Előfeltételek: Szükség van a Duck Creek Data Hub modulhoz való hozzáférésre. Az exportálási feladatot futtató felhasználónak vagy szolgáltatásfióknak olvasási jogosultsággal kell rendelkeznie a Data Hub mögöttes adatbázistábláihoz, például a [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim] és [DataHubSchema].[DimStatusHistory] táblákhoz.
- Dátumtartomány beállítása: A lekérdezés az @StartDate és @EndDate paramétereket használja. Ezeket mindenképpen állítsa be a kinyerési időszak meghatározásához. Első elemzéshez 6–12 hónapos időszak ajánlott, hogy elegendő lezárt és folyamatban lévő ügy kerüljön az adatok közé.
- Szűrés: A lekérdezés Common Table Expression (CTE) részében egy helyőrző található: /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */. A szűréshez távolítsa el a megjegyzésjeleket, majd módosítsa a sort, például a 'Personal Auto' vagy 'Commercial Property' üzletágra. Így csökkentheti az adatmennyiséget, és az elemzést a kívánt területre összpontosíthatja.
- A Data Hub frissítési ciklusa: Vegye figyelembe a Data Hub adatainak késését. Az adatok nem valós időben frissülnek, hanem jellemzően ütemezetten, például éjszakánként. A kinyert adatok a Data Hub legutóbbi sikeres frissítésének állapotát tükrözik.
- Kimeneti formátum: Az exportálási feladatot egyszerű, lehetőleg CSV-fájl létrehozására kell beállítani. Az idézőjelet állítsa dupla idézőjelre (") az adatmezőkben előforduló vesszők megfelelő kezeléséhez.
Példa-lekérdezés sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL; Kezdheti?
Ezzel a sablonnal minden szükséges adat rendelkezésére áll a kárigénykezelés optimalizálásának megkezdéséhez. Kezdje el az adatok feldolgozását, és tárja fel az értékes összefüggéseket.
Számolja fel a kárügyhátralékot: optimalizálja most a kárrendezést
Érjen el 70%-os automatikus, emberi beavatkozás nélküli feldolgozást, és csökkentse a költségeket, valamint a késedelmeket.
Ingyenes, 14 napos próbaverzió, bankkártya megadása nélkül.