Hasar taleplerinin işlenmesi için Veri Templateiniz
Hasar taleplerinin işlenmesi için Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Guidewire ClaimCenter için veri çıkarma yönergeleri
Hasar taleplerinin işlenmesine ilişkin öznitelikler
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Hasar yaşam döngüsünün belirli bir aşamasında gerçekleşen iş faaliyetinin veya olayın adı. | ||
| Açıklama Bu öznitelik, hasar sürecindeki Hasar Oluşturuldu, İnceleme Başlatıldı veya Ödeme Yapıldı gibi belirli bir adımı ya da kilometre taşını tanımlar. Belirli bir Hasar kimliği için bu faaliyetlerin sıralaması süreç akışını oluşturur. Faaliyetlerin sırasını, sıklığını ve aralarındaki süreyi analiz etmek, Process Mining çalışmalarının temelini oluşturur. Bu analiz, süreç modellerini ortaya çıkarmaya, darboğazları belirlemeye, yeniden çalışma döngülerini saptamaya ve süreç sapmalarını incelemeye yardımcı olur. Neden önemli? Süreç adımlarını tanımlar; süreç haritalarını görselleştirmenizi, süreç akışını incelemenizi ve darboğazları belirlemenizi sağlar. Nereden alınır? Bu bilgi genellikle ClaimCenter’daki olay tablolarından veya denetim günlüklerinden elde edilir. Bunun için belirli sistem olayları ya da durum değişiklikleri standart faaliyet adlarıyla eşleştirilir. Örnekler Hasar dosyası oluşturulduSorumluluk kararı verildiÖdeme gönderildiHasar dosyası kapatıldı | |||
| Hasar kimliği ClaimID | Her sigorta hasar dosyasını benzersiz biçimde tanımlayan ve ana vaka tanımlayıcısı olarak kullanılan kimlik. | ||
| Açıklama Hasar kimliği, her dosyayı başvurudan kapanışa kadar benzersiz biçimde tanımlayarak hasar süreci analizinin temelini oluşturur. İlişkili tüm etkinlikleri, belgeleri, ödemeleri ve iletişimleri birbirine bağlar; böylece hasar dosyasının yaşam döngüsünü eksiksiz ve tutarlı biçimde görmenizi sağlar. Process Mining’de Veri Setindeki her olay bir hasar kimliğine bağlanır. Bu sayede süreç akışı baştan sona yeniden oluşturulabilir. Bu, çevrim sürelerini analiz etmek, süreç farklılıklarını belirlemek ve bir hasar dosyasının farklı departmanlar ile eksperler arasındaki ilerleyişini izlemek için gereklidir. Neden önemli? İlişkili tüm olayları birbirine bağlayan temel anahtardır; tek bir hasar dosyasının tüm sürecini izleyip analiz etmenizi sağlar. Nereden alınır? Guidewire ClaimCenter’da bu, genellikle Claim temel varlığındaki Claim.ClaimNumber alanı veya benzer bir alandır. Örnekler 000-123-45678000-987-65432001-456-11223 | |||
| Olay zamanı EventTime | Faaliyetin gerçekleştiği kesin tarih ve saat. | ||
| Açıklama Bu zaman damgası, bir faaliyetin sisteme kaydedildiği kesin anı gösterir. Zamana dayalı tüm süreç analizlerinin temelini oluşturur. Tek bir Hasar kimliğine ait EventTime değerlerini kronolojik olarak sıralayarak süreç akışını yeniden oluşturabilirsiniz. Ardışık olaylar arasındaki süre; çevrim süresini, bekleme süresini ve işlem süresini hesaplamak için kullanılır. Bu değerler performans analizinde, darboğazların belirlenmesinde ve SLA takibinde önem taşır. Neden önemli? Olayları sıralamak, çevrim sürelerini ve süreleri hesaplamak, süreçteki gecikmeleri belirlemek için gereklidir. Nereden alınır? Guidewire ClaimCenter’ın geçmiş veya denetim tablolarında olay ya da faaliyet verileriyle birlikte bulunur. Genellikle CreateTime veya UpdateTime alanı olarak yer alır. Örnekler 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
| Atanan hasar uzmanı AssignedAdjuster | Hasarı veya belirli bir faaliyeti yürütmekle görevlendirilen kullanıcının adı ya da kimliği. | ||
| Açıklama Bu öznitelik, belirli bir zamanda hasardan sorumlu olan hasar uzmanını belirtir. Uzman, hasarın tamamına veya hasar kapsamındaki belirli görevlere atanabilir. Atanan hasar uzmanına göre analiz yapmak; iş yükünü dengelemek, performansı yönetmek ve eğitim ihtiyaçlarını belirlemek açısından önemlidir. Hangi uzmanların en fazla dosyaya baktığı, uzmanlar arasında performans farkı olup olmadığı ve işlerin eşit dağıtılıp dağıtılmadığı gibi soruları yanıtlamaya yardımcı olur. Neden önemli? Kullanıcıların sürece katılımını izler; iş yükü analizini, performans karşılaştırmasını ve kaynaklarla ilgili darboğazların belirlenmesini sağlar. Nereden alınır? ClaimCenter’daki Claim veya Exposure varlığında bulunur ve genellikle User nesnesine bağlıdır. Örneğin, Claim.Assignee. Örnekler j.doem.smiths.jones | |||
| Hasar durumu ClaimStatus | Olayın gerçekleştiği andaki genel hasar durumu. Örneğin, Açık, Kapalı veya Reddedildi. | ||
| Açıklama Bu öznitelik, hasarın genel durumunu gösterir. Başlıca durumlar Açık, Kapalı, Reddedildi ve Yeniden Açıldı’dır. Hasarın son durumu, sonuçları değerlendirmek için kullanılan önemli bir metriktir. Hasar durumundaki değişiklikleri izlemek, temel süreç aşamalarını ve sonuçlarını tanımlamaya yardımcı olur. Hasarın nasıl sonuçlandığını belirlemek, ret oranlarını hesaplamak ve kapatıldıktan sonra yeniden açılan hasarların sıklığını incelemek için kullanılır. Yeniden açılma, çoğu zaman süreç sorunlarına veya müşteri memnuniyetsizliğine işaret eder. Neden önemli? Hasarın sonucunu gösterir; ret oranlarını, kapanış örüntülerini ve yeniden açılma sıklığını analiz etmeyi sağlar. Nereden alınır? Claim varlığındaki temel bir alandır; genellikle State veya Status olarak adlandırılır. Örnekler AçıkKapalıReddedildiYeniden açıldı | |||
| Hasar nedeni LossCause | Kayba yol açan olayın belirli nedeni. Örneğin, çarpışma, yangın veya su hasarı. | ||
| Açıklama Bu öznitelik, hasar talebinin neden yapıldığına ilişkin ayrıntılı bağlam sunar. Hasarın nedeni; gerekli inceleme adımlarını, ihtiyaç duyulan uzmanları ve hasarın genel karmaşıklığını belirleyebilir. Süreci hasar nedenine göre analiz etmek, gizli örüntüleri ortaya çıkarabilir. Örneğin, Su Hasarı hasarlarında yeniden çalışma oranı daha yüksek olabilir veya Hırsızlık hasarlarına kıyasla daha fazla uzman desteği gerekebilir. Bu içgörüler, daha uzmanlaşmış ve verimli işlem prosedürleri oluşturmanıza yardımcı olur. Neden önemli? Hasarın niteliği hakkında bağlam sunar; farklı hasar nedenlerinin süreç akışını ve süresini nasıl etkilediğini analiz etmenizi sağlar. Nereden alınır? Claim varlığındaki standart bir alandır; genellikle LossCause olarak adlandırılır. Örnekler ÇarpışmaYangınSu hasarıHırsızlık | |||
| Hasar türü ClaimType | Oto, Konut veya Sorumluluk gibi sigorta hasarının kategorisi. | ||
| Açıklama Hasar türü, hasarı iş koluna veya kaybın niteliğine göre sınıflandırır. Farklı hasar türleri genellikle farklı süreçlerden geçer, farklı karmaşıklık düzeylerine sahiptir ve farklı düzenlemelere tabidir. Anlamlı içgörüler elde etmek için süreç analizini hasar türüne göre bölümlere ayırmak gerekir. Böylece farklı iş kollarındaki süreç performansını karşılaştırabilir, belirli hasar türlerine özgü darboğazları bulabilir ve süreç iyileştirme çalışmalarını her kategorinin özelliklerine göre şekillendirebilirsiniz. Neden önemli? Hasarları türlerine göre ayırmanızı sağlar. Örneğin, Oto ve Konut hasarları farklı süreçlerden geçebilir ve farklı performans hedeflerine sahip olabilir. Nereden alınır? ClaimCenter’daki Policy veya Claim varlığından, genellikle İş Kolu (LOB) koduna göre elde edilir. Örnekler Bireysel OtoTicari MülkGenel Sorumlulukİşçi Tazminatı | |||
| Bitiş zamanı EndTime | Bir faaliyetin tamamlandığı zamanı gösteren zaman damgası. | ||
| Açıklama Bitiş zamanı, özellikle İnceleme veya Belge İncelemesi gibi ölçülebilir bir süresi olan görevlerin tamamlandığı anı gösterir. Process Mining çalışmalarındaki birçok faaliyet anlık gerçekleştiğinden yalnızca Başlangıç zamanı yeterlidir. Ancak başlangıç ve bitiş zamanı belirgin olan faaliyetleri iki zaman damgasıyla göstermek daha doğru olur. Bu öznitelik, bekleme süresinden ayrı olarak faaliyetin işlem süresini hassas biçimde hesaplamanızı sağlar. Böylece farklı adımlar arasındaki uzun gecikmelere bakmakla kalmaz, hangi görevlerin zaman aldığını da belirleyebilirsiniz. Neden önemli? Bir faaliyetin ne kadar sürede tamamlandığını hassas biçimde ölçmenizi ve işlem süresini bekleme süresinden ayırmanızı sağlar. Nereden alınır? Bu değer, faaliyeti mantıksal olarak tamamlayan sonraki bir olay bulunarak elde edilebilir. Örneğin, durumun Devam Ediyor’dan Tamamlandı’ya geçmesi. Örnekler 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
| Çözüm hedef tarihi ResolutionTargetDate | Hasarın kurum içi veya düzenleyici SLA’lara göre çözüme kavuşturulmasının beklendiği tarih. | ||
| Açıklama Çözüm hedef tarihi, hasarın kapatılması için belirlenen son tarihtir. Bu tarih genellikle yargı bölgesi, hasar türü ve poliçe koşulları gibi etkenlere göre belirlenir. Performansı ve uyumluluğu ölçmek için bir referans noktası sunar. Bu öznitelik, SLA uyumluluğunu izleyen Dashboardlar ve KPI’lar oluşturmak için önemlidir. Gerçek Hasar Kapatıldı tarihini hedef tarihle karşılaştırarak geciken hasarları otomatik olarak işaretleyebilir, zamanında tamamlanma oranlarını ölçebilir ve hedefleri karşılamakta zorlanan hasar türlerini veya departmanları belirleyebilirsiniz. Neden önemli? Hizmet Düzeyi Anlaşması (SLA) uyumluluğunu ölçmek ve gecikme riski taşıyan hasarları belirlemek için referans noktasıdır. Nereden alınır? Bu, özel bir alan olabilir veya ClaimCenter’da tanımlanan iş kurallarına, muhtemelen belirli hasar metriklerine göre hesaplanabilir. Örnekler 2023-06-142023-07-202023-08-28 | |||
| Departman Department | Hasar faaliyetini yürütmekten sorumlu iş birimi veya departman. | ||
| Açıklama Bu öznitelik, atanan hasar uzmanının bağlı olduğu departmanı veya ekibi belirtir. Örneğin, Oto Hasarları, Konut Hasarları veya Özel İncelemeler Birimi. Sürece kurumsal bir bağlam kazandırır. Departmana göre analiz yapmak, süreç performansını kuruluş genelinde anlamak açısından önemlidir. Departmanlar arasındaki devir teslim gecikmelerini belirlemeye, ekiplerin verimliliğini karşılaştırmaya ve hasar kuruluşundaki kaynakları daha etkili dağıtmaya yardımcı olur. Neden önemli? Kurumsal bağlam sunarak farklı ekiplerin performansını analiz etmenizi ve departmanlar arasındaki devir teslim sorunlarını belirlemenizi sağlar. Nereden alınır? Bu bilgi genellikle ClaimCenter’da atanan kullanıcının veya grubun profiliyle ilişkilendirilir. Örnekler Oto Hasarları BölümüKonut Hasarları BirimiÖzel İncelemeler Birimi (SIU) | |||
| Hasar tarihi LossDate | Hasar talebine yol açan olayın veya kaybın gerçekleştiği tarih. | ||
| Açıklama Hasar tarihi, talebe konu olan gerçek olayın gerçekleştiği tarihtir. Örneğin, trafik kazasının veya mülk hasarının yaşandığı gün. Hasarın bildirildiği ya da oluşturulduğu tarihten farklıdır. Hasar tarihi ile Hasar Oluşturuldu faaliyeti arasındaki süre, bildirim gecikmesi olarak bilinir ve önemli bir KPI’dır. Bu süreyi analiz etmek, müşteri davranışını ve ilk hasar bildirimi kanallarının etkinliğini anlamaya yardımcı olur. Neden önemli? Hasarın kaynağı hakkında önemli bağlam sunar ve olay ile hasar bildirimi arasındaki süreyi analiz etmeye yardımcı olur. Nereden alınır? Claim varlığındaki temel bir tarih alanıdır; genellikle LossDate olarak adlandırılır. Örnekler 2023-05-102023-04-202023-05-28 | |||
| Kaynak sistem SourceSystem | Verilerin alındığı sistem. | ||
| Açıklama Bu öznitelik, olay verilerinin kaynağını belirtir. Günümüz kuruluşlarında hasarla ilgili olaylar Guidewire gibi temel sistemlerden, belge yönetim sistemlerinden veya müşteri portallarından gelebilir. Kaynak sistemi belirtmek; veri yönetişimi, veri tutarsızlıklarını giderme ve sürecin teknolojik altyapısını anlama açısından önemlidir. Temel süreç adımlarını, çevre sistemlerdeki destekleyici faaliyetlerden ayırmaya yardımcı olur. Neden önemli? Verilerin kaynağını belirtir. Veri yönetişimi ve birden fazla entegre sistemi kapsayan analizler için önemlidir. Nereden alınır? Bu değer genellikle verilerin çıkarılması, dönüştürülmesi ve yüklenmesi (ETL) sırasında eklenen sabit bir değerdir. Örnekler Guidewire ClaimCenter v10Müşteri Portalı API’siDocumentum | |||
| Ödeme tutarı PaymentAmount | Bir ödeme faaliyeti kapsamında fiilen ödenen para tutarı. | ||
| Açıklama Bu öznitelik, hasar için yapılan her bir ödemenin tutarını kaydeder. Bir hasar yaşam döngüsü boyunca birden fazla ödeme yapılabilir. Process Mining kapsamında mali analiz yapmak için bu bilgi gereklidir. Hasar başına toplam ödemeyi izlemek, tutara göre ödeme onay sürelerini incelemek ve süreç verimsizliklerini mali sonuçlarla ilişkilendirmek için kullanılabilir. Örneğin, çevrim süresi uzun olan hasarlar daha yüksek toplam ödemelerle ilişkili olabilir. Neden önemli? Hasar kapsamındaki mali işlemleri izler; ödeme tutarlarını ve bunların süreç faaliyetleriyle ilişkisini analiz etmenizi sağlar. Nereden alınır? Hasara bağlı ödeme varlıklarında, genellikle işlem veya çek tablosunda bulunur. Örnekler 4500.00125000.00500.00 | |||
| Otomatik mi IsAutomated | Bir faaliyetin sistem tarafından otomatik olarak mı yoksa bir kullanıcı tarafından mı gerçekleştirildiğini belirten bir işaret. | ||
| Açıklama Bu boole özniteliği, sistemin gerçekleştirdiği faaliyetleri (örneğin, otomatik karşılık oluşturma veya sistem tarafından hazırlanan yazışmalar) hasar uzmanının elle yaptığı faaliyetlerden ayırır. Bu özniteliği analiz etmek, hasar sürecindeki otomasyon düzeyini anlamanın temel yollarından biridir. Elle müdahale edilen noktaları belirlemeye, uçtan uca otomasyon çalışmalarının etkinliğini ölçmeye ve insanların hâlâ yaptığı tekrarlı, kurallara dayalı görevleri saptayarak yeni otomasyon fırsatları bulmaya yardımcı olur. Neden önemli? Sistem tarafından yürütülen faaliyetleri kullanıcıların yaptığı faaliyetlerden ayırır. Otomasyon analizinde ve elle yürütülen işlerdeki darboğazları belirlemede önemlidir. Nereden alınır? Bu değer çoğu zaman mevcut verilerden türetilmelidir. Örneğin, genel bir system kullanıcısı tarafından kaydedilen olaylar otomatik olarak işaretlenebilir. Örnekler truefalse | |||
| Poliçe türü PolicyType | Hasarın bildirildiği sigorta poliçesinin türü. | ||
| Açıklama Poliçe türü, hasar türünden daha ayrıntılı bir sınıflandırma sunar ve Konut, Ticari Oto veya Siber Sorumluluk gibi sigorta ürününü belirtir. Bu ayrıntı düzeyi, belirli ürünlere bağlı süreç farklılıklarını ortaya çıkarabilir. Süreci poliçe türüne göre analiz etmek, ürünlere özgü verimsizlikleri bulmaya yardımcı olur. Örneğin, yeni sunulan bir poliçeye ait hasarlar henüz olgunlaşmamış bir süreçten geçerek gecikmelere yol açabilir. Bu analiz, ürün tasarımına ve süreçleri standartlaştırma çalışmalarına yön verebilir. Neden önemli? Belirli sigorta ürünlerine göre süreç analizi yapmanızı ve poliçe özelliklerine bağlı işlem farklılıklarını belirlemenizi sağlar. Nereden alınır? Bu bilgi, Claim’e bağlı Policy varlığında bulunur. Örnekler Konut Çoklu RiskTicari Oto Sorumlulukİç Su Taşımacılığı | |||
| SLA durumu SLAState | Hasarın çözüm hedef tarihine kadar kapatılıp kapatılmadığını gösterir. | ||
| Açıklama Bu hesaplanan öznitelik, kapatılan her hasar için SLA uyumluluğunu kategorik olarak gösterir. Hasar Kapatıldı faaliyetinin zaman damgası ile Çözüm hedef tarihi karşılaştırılarak elde edilir. Bu öznitelik, analizi Zamanında veya Gecikti gibi anlaşılır kategorilere ayırarak Hasar çözüm hedefi uyumluluğu Dashboardunu doğrudan destekler. Kolayca filtreleme ve toplulaştırma yaparak genel SLA uyumluluk oranını hesaplayabilir, gecikme nedenlerini ayrıntılı inceleyebilirsiniz. Neden önemli? SLA uyumluluğu sonucunu anlaşılır kategorilerle gösterir; zamanında tamamlanan işleri filtrelemeyi, toplulaştırmayı ve analiz etmeyi kolaylaştırır. Nereden alınır? Hesaplanan alan: IF (ActualCloseDate <= ResolutionTargetDate, 'Zamanında', 'Gecikti'). Örnekler ZamanındaGecikti | |||
| Son veri güncellemesi LastDataUpdate | Verilerin kaynak sistemden en son yenilendiği veya alındığı zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, kaynak sistemden en son veri alımının zaman damgasını verir. Analizin ne kadar güncel olduğunu anlamak için gereken bir meta veri alanıdır. Kullanıcıların verilerin güncelliğini görebilmesi için bu bilgi Dashboardlarda ve analizlerde belirgin biçimde yer almalıdır. Böylece içgörülerin mevcut operasyon durumunu mu yoksa eski verileri mi yansıttığını değerlendirebilirsiniz. Neden önemli? Verilerin güncelliğini göstererek kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasını sağlar. Nereden alınır? Bu değer ETL işlemi sırasında oluşturulup kaydedilir ve veri yüklemesinin zaman damgasını gösterir. Örnekler 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
| Talep edilen tutar ClaimedAmount | Poliçe sahibinin başlangıçta talep ettiği toplam para tutarı. | ||
| Açıklama Bu öznitelik, talep sahibinin bildirdiği kayıp tutarını gösterir. Genellikle ilk tahmindir; hasar incelendikçe ve karşılıklar belirlendikçe değişebilir. Talep edilen tutarı analiz ederek hasarları mali etkilerine göre gruplandırabilirsiniz. Yüksek tutarlı hasarlar, düşük tutarlı hasarlara kıyasla daha ayrıntılı ve karmaşık bir süreçten geçebilir. Farklı tutar aralıklarındaki süreçleri karşılaştırmak, küçük hasarların işlemlerini kolaylaştırma veya büyük hasarlar için daha sıkı kontroller uygulama fırsatlarını ortaya çıkarabilir. Neden önemli? Hasarları mali değerlerine göre gruplandırmanızı sağlar. Yüksek tutarlı hasarlar farklı ve daha karmaşık süreçlerden geçebilir. Nereden alınır? Bu bilgi tek bir alanda bulunmayabilir; Exposure kayıtlarında yer alan ilk kayıp tahminlerinden elde edilebilir. Örnekler 5000.00150000.00750.50 | |||
| Tekrarlanan bilgi talebi RepeatedInfoRequestFlag | Aynı hasar için Ek Bilgi İstendi faaliyetinin birden fazla kez gerçekleşip gerçekleşmediğini belirten bir işaret. | ||
| Açıklama Bu boole işareti, bir hasarda Ek Bilgi İstendi faaliyeti birden fazla kez gerçekleştiğinde true olarak ayarlanır. Bu durum genellikle ilk bilgi toplama aşamasındaki verimsizliklere işaret eder. Bu öznitelik, Tekrarlanan bilgi talebi oranı KPI’ını doğrudan destekler. İlk incelemede bilgilerin eksik toplanması sorununu ölçmeye yardımcı olur. Bu eksiklikler önemli gecikmelere ve müşteri memnuniyetsizliğine yol açabilir. Bu işaretin bulunduğu hasarları analiz ederek kontrol listelerini ve hasar uzmanlarının prosedürlerini iyileştirebilir, gerekli tüm bilgilerin tek seferde istenmesini sağlayabilirsiniz. Neden önemli? Bilgilerin ilk seferde eksiksiz toplanmamasından kaynaklanan verimsizlikleri belirler; bu durum süreç gecikmelerine ve yeniden çalışmaya yol açar. Nereden alınır? Process Mining aracı, her vaka için Ek Bilgi İstendi faaliyetinin kaç kez gerçekleştiğini sayarak bu değeri hesaplar. Örnekler truefalse | |||
| Yargı bölgesi JurisdictionState | Hasarı düzenleyen ve tabi olduğu mevzuatı belirleyen eyalet veya yargı bölgesi. | ||
| Açıklama Bu öznitelik, hasarın ele alındığı yasal yargı bölgesini, örneğin ABD eyaletini belirtir. Sigorta düzenlemeleri yargı bölgelerine göre önemli ölçüde değişebilir ve gerekli süreç adımlarını, iletişim sürelerini ve belgelendirme gerekliliklerini etkileyebilir. Bu öznitelik, uyumluluğu izlemek için önemlidir. Süreci yargı bölgesine göre analiz ederek eyalete özgü düzenleyici gerekliliklerin karşılanıp karşılanmadığını kontrol edebilirsiniz. Ayrıca çevrim süresi veya süreç akışındaki farklılıkların operasyonel verimsizlikten değil, yasal kısıtlamalardan kaynaklanıp kaynaklanmadığını anlamaya yardımcı olur. Neden önemli? Farklı yargı bölgelerindeki düzenlemeler hasar sürecini etkilediğinden, uyumluluk analizi için önemlidir. Nereden alınır? Claim varlığındaki standart bir alandır; genellikle JurisdictionState olarak adlandırılır. Örnekler CANYTXFL | |||
| Yeniden çalışma mı IsRework | Bir faaliyetin önceki bir süreç aşamasına dönüşü, yani yeniden çalışma döngüsünü gösterip göstermediğini belirten bir işaret. | ||
| Açıklama Bu hesaplanan öznitelik, yeniden çalışma döngüsünün parçası olan faaliyetleri işaretler. Örneğin, süreç İnceleme Tamamlandı adımından yeniden İnceleme Başlatıldı adımına dönerse, ikinci İnceleme Başlatıldı faaliyeti yeniden çalışma olarak işaretlenir. Yeniden çalışmayı belirlemek, süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarmanın temel yollarından biridir. Yeniden Çalışma ve Ret Sıklığı Dashboardu, hasarların ideal yoldan ne sıklıkta saptığını ölçmek için bu metriği kullanır. Yeniden çalışmanın nedenlerini analiz etmek, süreç kalitesini ve hızını önemli ölçüde iyileştirebilir. Neden önemli? Yeniden çalışma döngüsüne dahil olan faaliyetleri açıkça işaretleyerek süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarır. Nereden alınır? Process Mining aracı, her vaka için faaliyet sırasını analiz ederek bu değeri hesaplar. Örnekler truefalse | |||
Hasar taleplerinin işlenmesine ilişkin etkinlikler
| Aktivite | Açıklama | ||
|---|---|---|---|
| Hasar dosyası kapatıldı | Tüm etkinlikler ve ödemeler tamamlandıktan sonra hasar dosyasının başarıyla kapatıldığını belirtir. Bu, ana başarılı bitiş olayıdır ve hasar dosyasının ana durumundaki değişiklikten çıkarımlanır. | ||
| Neden önemli? Ana bitiş olayı olan bu etkinlik, baştan sona çevrim süresini hesaplamak ve SLA hedeflerine uyumu ölçmek için gereklidir. Hasar dosyasının yaşam döngüsünün tamamlandığını gösterir. Nereden alınır? cc_claim tablosundaki State alanının 'Kapalı' olarak değişmesinden çıkarımlanır. Olayın zaman damgası, hasar kaydındaki CloseDate alanıdır. Kaydedin Hasar dosyasının ana durum alanının 'Kapalı' olarak güncellendiği zamanı belirleyin. Olay türü inferred | |||
| Hasar dosyası oluşturuldu | Bu etkinlik, ilk hasar bildiriminin (FNOL) alınmasını ve Guidewire ClaimCenter’da yeni bir hasar kaydının resmen oluşturulmasını belirtir. Yeni bir Claim varlığı ilk kez veritabanına kaydedildiğinde açıkça kayda alınır. | ||
| Neden önemli? Başlangıç olayı olarak bu etkinlik, hasar dosyasının baştan sona çevrim süresini ölçmek için gereklidir. Sonraki tüm performans ve süre KPI’ları için başlangıç noktası oluşturur. Nereden alınır? Bu, cc_claim tablosundaki CreateTime alanından alınan açık bir olaydır. Benzersiz bir Claim ID ile yeni bir kayıt oluşturulması olayı tetikler. Kaydedin Temel Claim varlık tablosundaki yeni kaydın oluşturulma zaman damgasını belirleyin. Olay türü explicit | |||
| Hasar talebi reddedildi | Hasar talebinin reddedilmesine ilişkin nihai kararı belirtir ve süreç için son nokta oluşturur. Hasar talebinin durumu, ret nedeni ile birlikte kapalı bir duruma geçtiğinde bu olay çıkarımlanır. | ||
| Neden önemli? Bu, sonucu belirleyen önemli bir olaydır. Retlerin sıklığını, nedenlerini ve bunlara yol açan süreç yollarını analiz etmek; hasar başvurusu, inceleme veya poliçe hükümlerinin yorumlanmasıyla ilgili sorunları belirlemeye yardımcı olur. Nereden alınır? cc_claim tablosundaki State alanının 'Kapalı' olarak değişmesi ve CloseReason alanının 'Reddedildi' veya benzer bir değer olmasıyla çıkarımlanır. Olayın zaman damgası CloseDate alanıdır. Kaydedin Ret nedenini belirten kodun bulunduğu, durumu 'Kapalı' olarak değişen hasar dosyalarını filtreleyin. Olay türü inferred | |||
| İlk karşılık ayrıldı | Bir teminat kalemi için ilk finansal karşılık işleminin oluşturulduğunu ve hasar dosyasının olası maliyetinin tahmin edildiğini belirtir. Açıkça kaydedilen önemli bir finansal olaydır. | ||
| Neden önemli? Bu kilometre taşı, finansal analiz ve olası yükümlülüğün ne kadar hızlı değerlendirildiğini anlamak açısından önemlidir. Gecikmeler finansal planlamayı ve raporlamayı etkileyebilir. Nereden alınır? Bu olay, hasar dosyasındaki bir teminat kalemiyle ilişkili ilk cc_reserveline kaydının oluşturulmasından alınır. İşlemin CreateTime alanı olayın zaman damgasıdır. Kaydedin Belirli bir hasar dosyasının teminat kalemlerine ait tüm karşılık satırları arasındaki en erken oluşturulma zaman damgasını bulun. Olay türü explicit | |||
| Ödeme gönderildi | Bu etkinlik, ödemenin resmen gönderilip finansal sisteme iletildiği ödeme sürecinin son adımını belirtir. Açıkça kaydedilen bir finansal işlemdir. | ||
| Neden önemli? Bu etkinlik, ödeme gönderme sürecinin verimliliğini ölçmek için önemlidir. Onay gecikmeleriyle paranın gerçekten gönderilmesindeki gecikmeleri birbirinden ayırmaya yardımcı olur. Nereden alınır? cc_check veya cc_transaction varlığındaki IssueDate alanından ya da durumun 'Gönderildi' veya 'İletildi' olarak değişmesinden alınır. Bu genellikle zaman damgası içeren açık bir olaydır. Kaydedin Ödeme kaydındaki IssueDate alanını veya durumun 'Gönderildi' olarak değiştiği zaman damgasını belirleyin. Olay türü explicit | |||
| Ödeme onaylandı | Uzlaşma ödemesinin resmen onaylanmasını belirtir. Denetim açısından önemli olan bu olay, yetkili bir kullanıcı işlemi onayladığında açıkça kaydedilir. | ||
| Neden önemli? Bu önemli kilometre taşı, son ödeme adımının önünü açar. Bu etkinlikten önceki ve sonraki süreleri analiz etmek, onay iş akışlarından veya yöneticilerin müsait olmamasından kaynaklanan gecikmeleri ayırmaya yardımcı olur. Nereden alınır? Bu olay genellikle cc_check veya cc_transaction varlığıyla ilişkili olarak cc_history tablosuna açıkça kaydedilir ve durumun 'Onay bekliyor' değerinden 'Onaylandı' değerine değiştiğini gösterir. Kaydedin Belirli bir ödeme işleminin durumunun 'Onaylandı' olarak değiştiği olayı izleyin. Olay türü explicit | |||
| Teminat kalemi oluşturuldu | Bu etkinlik, hasar dosyası kapsamındaki belirli bir olası yükümlülüğü veya hasar türünü (ör. araç hasarı, yaralanma) temsil eden bir teminat kaleminin oluşturulduğunu belirtir. Guidewire’da açıkça kaydedilen bir olaydır. | ||
| Neden önemli? Teminat kalemleri, hasar dosyalarını bölümlere ayırma ve analiz etme açısından temel öneme sahiptir. Oluşturulmalarını izlemek, hasar dosyasının karmaşıklığına ve hasar türüne bağlı süreç farklılıklarını anlamaya yardımcı olur. Nereden alınır? cc_exposure tablosundaki yeni bir kaydın CreateTime alanından alınır. Her kayıt tek bir Claim ID ile ilişkilidir. Kaydedin Exposure varlık tablosundaki yeni kaydın oluşturulma zaman damgasını belirleyin. Olay türü explicit | |||
| Ek bilgi alındı | Ek bilgi talebinin tamamlandığını belirtir. Bilgi talebiyle ilgili Activity (Task) 'Tamamlandı' olarak işaretlendiğinde kaydedilir. | ||
| Neden önemli? Bu etkinlik, 'Ek bilgi toplama çevrim süresi' KPI’ının bitiş noktasıdır. Talep ile bilginin alınması arasındaki uzun süreler, hasar sürecindeki yaygın gecikme nedenlerindendir. Nereden alınır? ActivityPattern alanı bilgi talebiyle ilgili olan bir cc_activity kaydının CloseTime alanından alınır. Etkinliğin durumu 'Tamamlandı' olmalıdır. Kaydedin Dışarıdan bilgi isteme görevinin tamamlanma zaman damgasını belirleyin. Olay türü explicit | |||
| Ek bilgi istendi | Hasar talebinde bulunan kişiye veya üçüncü tarafa daha fazla bilgi ya da belge göndermesi için iletilen talebi belirtir. Bu genellikle ClaimCenter’da açıkça oluşturulan bir Activity (Task) olarak kaydedilir. | ||
| Neden önemli? Bu etkinlik, 'Ek bilgi toplama çevrim süresi' KPI’ını ölçmek için başlangıç noktasıdır. Sık tekrarlanması, FNOL sürecindeki eksikliklere veya bilgi toplamadaki verimsizliğe işaret edebilir. Nereden alınır? ActivityPattern alanı dış bir taraftan belge veya bilgi istemeyle ilgili olan bir cc_activity kaydının CreateTime alanından alınır. Kaydedin Dışarıdan bilgi istemek için oluşturulan görevi belirleyin. Olay türü explicit | |||
| Hasar dosyası atandı | Bir hasar dosyasının işlenmek üzere belirli bir kullanıcıya (eksper) veya gruba atanmasını belirtir. Bu genellikle Claim varlığındaki atama alanlarındaki değişiklikler izlenerek çıkarımlanır. | ||
| Neden önemli? Atamaları izlemek; eksperlerin iş yükünü analiz etmek, yönlendirme darboğazlarını belirlemek ve dosyayı üstlenen kişinin ilk işlemine kadar geçen süreyi ölçmek için önemlidir. Nereden alınır? Belirli bir Claim ID ile ilişkili AssignedUser veya AssignedGroup alanlarındaki değişiklikler izlenerek cc_history tablosundan çıkarımlanır. Değişikliğin zaman damgası, olayın ne zaman gerçekleştiğini gösterir. Kaydedin Hasar dosyası atama alanlarındaki güncellemeler için denetim günlüklerini veya geçmiş tablolarını izleyin. Olay türü inferred | |||
| Hasar dosyası yeniden açıldı | Ek işlem yapılması için hasar dosyasının 'Kapalı' durumundan yeniden 'Açık' duruma geçirilmesini belirtir. Bu olay, belirli bir durum değişikliği sırasından çıkarımlanır. | ||
| Neden önemli? Bu etkinlik yeniden çalışmaya işaret eder. Yeniden açılan hasar dosyalarının sayısının yüksek olması; ilk uzlaşmada sorunlara, hasarların gözden kaçmasına veya süreçteki başka aksaklıklara işaret eder. Bunlar maliyetleri artırır ve verimliliği düşürür. Nereden alınır? cc_claim varlığındaki State alanının 'Kapalı' durumundan yeniden 'Açık' veya başka bir etkin duruma geçtiği belirlenerek cc_history tablosundan çıkarımlanır. Kaydedin Hasar dosyasının ana durum alanını, kapalı durumdan açık duruma geçiş açısından izleyin. Olay türü inferred | |||
| İnceleme başladı | Bir hasar dosyası veya teminat kalemi için inceleme aşamasının resmen başladığını belirtir. Bu genellikle Guidewire’da incelemeyle ilgili ilk Activity (Task) oluşturulmasından çıkarımlanır. | ||
| Neden önemli? Bu etkinlik, önemli ve çoğu zaman uzun süren bir aşamanın başlangıcını gösterir. İncelemenin başlamasına kadar geçen süreyi ve incelemenin kendi süresini analiz etmek, önemli darboğazları ortaya çıkarır. Nereden alınır? ActivityPattern alanı incelemeyle ilgili olan bir cc_activity kaydının CreateTime alanından çıkarımlanır (ör. 'İlk inceleme', 'Tanıkla iletişime geç'). Kaydedin İncelemeyle ilgili bir örüntü veya konuya sahip görevin ilk kez oluşturulduğu zamanı belirleyin. Olay türü inferred | |||
| Sorumluluk kararı verildi | Bir teminat kalemi için sorumluluk veya kusur kararının verildiği noktayı belirtir. Bu olay genellikle Exposure varlığındaki durum değişikliğinden çıkarımlanır. | ||
| Neden önemli? Bu önemli karar kilometre taşı, uzlaşma ve ödeme aşamalarının önünü açar. Karara kadar geçen süreyi analiz etmek, inceleme ve değerlendirme aşamalarındaki darboğazları belirlemeye yardımcı olur. Nereden alınır? cc_exposure varlığındaki State alanında veya özel sorumluluk durumu alanında gerçekleşen değişiklikler izlenerek cc_history tablosundan çıkarımlanır. Geçmiş kaydının zaman damgası, olayın gerçekleştiği zamanı gösterir. Kaydedin Teminat kaleminin durumu veya sorumluluk durumundaki güncellemeler için denetim günlüklerini ya da geçmiş tablolarını izleyin. Olay türü inferred | |||
| Uzlaşma tutarı hesaplandı | Uzlaşma tutarının belirlendiği ancak ödeme için henüz onaylanmadığı noktayı belirtir. 'Onay bekliyor' durumunda bir ödeme kaydı oluşturulmasından çıkarımlanabilir. | ||
| Neden önemli? Değerlendirmeden ödemeye geçişi belirtir. Onay zincirindeki gecikmeleri ortaya çıkarmak için 'Ödeme onayına kadar geçen süre' KPI’ının başlangıç noktasıdır. Nereden alınır? Başlangıç durumu 'Onay bekliyor' veya 'Onaylandı' öncesindeki benzer bir durum olan cc_check ya da cc_transaction kaydının CreateTime alanından çıkarımlanır. Kaydedin Ön onay durumundaki bir ödeme veya işlem kaydının oluşturulduğu zamanı belirleyin. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşulları doğrulayın: Guidewire DataHub / InfoCenter veri ambarı veritabanına okuma yetkisiyle erişmek için gerekli izinlere ve kimlik bilgilerine sahip olduğunuzu doğrulayın. Hasar verilerini veri ambarına aktaran ETL işlerinin başarıyla çalıştığından ve verilerin güncel olduğundan emin olun.
- Veritabanı bağlantısı: Veri ambarı veritabanı sunucusuna bağlanmak için standart bir SQL istemcisi (DBeaver, SQL Server Management Studio veya benzeri araçlar) kullanın.
- Şemayı inceleyin: Sorgunun tamamını çalıştırmadan önce veri ambarı şemasını tanıyın. Hasar talepleri, teminatlar, etkinlikler ve finansal işlemler için kullanılan temel tabloları belirleyin. Temel tabloların adları genellikle _dim (boyut) ve _fact (olgu) gibi son ekler içerir. Böylece sağlanan betikteki yer tutucu tablo ve sütun adlarını doğrulayabilirsiniz.
- SQL sorgusunu hazırlayın: Sorgu bölümünde verilen SQL betiğinin tamamını kopyalayıp SQL istemcinizin sorgu düzenleyicisine yapıştırın.
- Yer tutucuları özelleştirin: Betiği dikkatlice inceleyip tüm yer tutucu değerleri değiştirin. Veritabanı/şema adı ([YourDataMart]), tarih aralığı parametreleri ('[StartDate]', '[EndDate]') ve sisteme özgü yapılandırma değerleri (etkinlik örüntüleri, durum kodları gibi) buna dahildir.
- Sorguyu çalıştırın: Düzenlediğiniz SQL sorgusunu veri ambarında çalıştırın. Çalışma süresi, seçilen tarih aralığına ve sisteminizdeki veri hacmine göre değişebilir.
- İlk veri incelemesi: Sorgu tamamlandığında sonuç kümesinin ilk birkaç yüz satırını inceleyin. ClaimID, ActivityName ve EventTime sütunlarının beklendiği gibi dolu olduğunu ve farklı etkinlik türlerinin bulunduğunu kontrol edin.
- CSV olarak dışa aktarın: Sonuç kümesinin tamamını SQL istemcinizden CSV dosyasına aktarın. Dosyaya açıklayıcı bir ad verin; örneğin guidewire_claimcenter_event_log.csv.
- ProcessMind için biçimlendirin: CSV dosyasının UTF-8 kodlamasıyla kaydedildiğinden emin olun. Dosyada, SQL sorgusundaki sütun takma adlarıyla eşleşen bir başlık satırı bulunduğunu doğrulayın. Dosya artık ProcessMind’e yüklenmeye hazır.
Yapılandırma
- Veri kaynağı: Guidewire DataHub/InfoCenter Claims Data Mart. Bu, raporlama ve analiz için tasarlanmış, önceden bir araya getirilmiş boyutsal bir veritabanıdır ve canlı ClaimCenter üretim veritabanından ayrıdır.
- Gerekli yetkiler: Veri ambarını barındıran SQL veritabanına salt okunur erişim. Kullanıcı adı, parola ve bağlantı bilgileri (sunucu adresi, veritabanı adı) gerekir.
- ETL işi durumu: Veri çıkarımının doğruluğu, verileri veri ambarına aktaran Guidewire ETL işlerinin zamanında ve başarıyla çalışmasına bağlıdır. Verilerin ne kadar güncel olduğunu anlamak için son başarılı çalıştırma zamanını doğrulayın.
- Tarih aralığı filtresi: Sağlanan sorguda '[StartDate]' ve '[EndDate]' yer tutucularını içeren WHERE koşulları bulunur. Performansı yönetmek için önce sınırlı bir tarih aralığıyla (ör. 3-6 ay) başlamanız önerilir. Tarih filtresi, hasar talebinin CreateTime alanına uygulanır.
- Yapılandırmaya özgü değerler: Guidewire yüksek düzeyde yapılandırılabilir. WHERE koşullarındaki değerleri kuruluşunuzun kurulumuna göre düzenlemeniz gerekir. Bunlar şunları içerir:
- ActivityPattern adları (ör. 'fnol', 'investigation', 'Ek bilgi talep edin')
- ClaimStatus, ExposureStatus ve CloseReason kodları (ör. 'denied', 'closed')
- TransactionStatus kodları (ör. 'pendingapproval', 'approved', 'issued')
- Performans: Büyük geçmiş veya denetim tablolarını sorgulamak yoğun kaynak kullanabilir. Çok büyük veri setlerinde sorguyu yoğun olmayan saatlerde çalıştırmanız önerilir. İlgili tablolarda ClaimID veya ClaimNumber sütunlarının dizinlendiğinden emin olun.
Örnek sorgu sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed'; Adımlar
- Kuruluşunuzun ClaimCenter ortamı için etkin bir Guidewire Cloud Data Access (CDA) Snowflake veri paylaşımına sahip olduğunu doğrulayın. Guidewire Cloud yöneticinizden Snowflake hesap tanımlayıcısını, veritabanını, şemayı, ambarı, rolü, kimlik doğrulama yöntemini ve yetkili ağ yapılandırmasını alın.
- Paylaşımınızda sunulan CDA veritabanı nesnelerini ve sütunlarını tam olarak belirleyin. CDA şemaları ve sütun adları kiracıya, sürüme, yapılandırmaya ve veri paylaşım modeline göre değişebilir. Sorgudaki köşeli parantezli nesne veya sütun yer tutucularını ortamınızdaki karşılıklarıyla değiştirin. Operasyonel ClaimCenter varlık adlarının Snowflake’te değişmeden sunulduğunu varsaymayın.
- Hasar talebi oluşturma, talep atama geçmişi, teminat oluşturma, karşılık işlemleri, etkinlikler, teminat durumu geçmişi, ödeme durumu geçmişi ve talep durumu geçmişi için kullanılan kaynakları belirleyin. Paylaşımınız geçmiş tablolarını veya denetim kayıtlarını sunmuyorsa, gerekli her durum geçişi için önceki değeri, yeni değeri, olay zaman damgasını ve işlemi yapan kişiyi koruyan onaylı bir kaynak yapılandırın.
- Yetkili bir Snowflake istemcisi, çalışma sayfası, not defteri veya SQL çalıştırma aracı kullanarak CDA Snowflake paylaşımına bağlanın. Mümkünse salt okunur bir rol kullanın. Sorguda analiz başlangıç ve bitiş zaman damgalarını [Start timestamp] ve [End timestamp] ile belirleyin. Onaylı şirket veya iş birimi filtresini [Company filter] ile uygulayın.
- Sorgudaki kaynak yer tutucularını doğrulanmış CDA nesne ve sütun adlarıyla değiştirin. Sorgu, gerekli 14 etkinliğin tümü için açıkça satır oluşturur: Talep oluşturuldu, Talep atandı, Teminat oluşturuldu, İlk karşılık belirlendi, İnceleme başlatıldı, Ek bilgi talep edildi, Ek bilgi alındı, Sorumluluk kararı verildi, Uzlaşma tutarı hesaplandı, Ödeme onaylandı, Ödeme yapıldı, Talep reddedildi, Talep kapatıldı ve Talep yeniden açıldı.
- Sorguyu çalıştırın ve sonuç şemasını inceleyin. Çıktıda ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus ve LossCause bulunmalıdır. ProcessMind için ClaimID, ActivityName ve EventTime gereklidir. Her olay için bir satır bırakın; olayları talep bazında toplamayın.
- Dışa aktarmadan önce zaman damgalarını, durum geçişlerini, atama değişikliklerini, yinelenen kayıtları ve etkinlik sayılarını doğrulayın. Olay zaman damgalarının aynı saat diliminde olduğunu kontrol edin. Ayrı iş etkinliklerini temsil eden aynı zaman damgalı olayları ayrı satırlarda tutun.
- Sonucu UTF-8 CSV veya ProcessMind’in desteklediği başka bir tablo biçiminde dışa aktarın. ClaimID’yi vaka tanımlayıcısı, ActivityName’i etkinlik ve EventTime’ı olay zaman damgası olarak eşleyin. Önerilen öznitelikleri ek olay öznitelikleri olarak tutun ve bu çıkarımın dışında kalan etkinlikleri varsayımla eklemeden dosyayı ProcessMind’e yükleyin.
Yapılandırma
- Bağlantı ve yetkilendirme: Guidewire tarafından sağlanan Snowflake veri paylaşımını yetkili bir Snowflake hesabı, rolü, ambarı ve ağ yolu üzerinden kullanın. Veri tüketicisi açısından CDA salt okunurdur. Gerekli erişim, kiracı yapılandırmanıza bağlıdır ve paylaşılan veritabanını ve belirli şemaları veya görünümleri sorgulama iznini içerebilir.
- Kaynak nesne yapılandırması: Köşeli parantez içindeki tüm kaynak başvurularını CDA paylaşımınızda doğruladığınız nesnelerle değiştirin. Sunulan CDA yapıları sürüme ve kiracıya göre değiştiğinden sorgu, tüm ClaimCenter kurulumları için geçerli tablo veya sütun adları olduğunu ileri sürmez.
- Tarih aralığı: Doğrulama ve operasyonel analiz için üç ila altı aylık bir dönemle başlayın. Daha geniş bir aralığa ancak ambar kapasitesini, olay geçmişi saklama süresini ve kabul edilebilir sorgu süresini doğruladıktan sonra geçin. Sonraki etkinliklerin dışarıda kalmaması için kaynak kayıtlarını yalnızca talep oluşturma tarihine göre değil, ilgili olay zaman damgasına göre filtreleyin.
- Gerekli çıktı: Her olay satırında ClaimID, ActivityName ve EventTime bulunmalı ve bu alanlar boş olmamalıdır. ActivityName, ProcessMind süreç modelinde beklenen etiketlerle tam olarak eşleşmelidir.
- Önerilen çıktı: AssignedAdjuster, ClaimType, ClaimStatus ve LossCause alanlarını ekleyin. Varsa bu değerleri olay anındaki anlık görüntüden alın. Yalnızca mevcut durum değerleri sunuluyorsa bu sınırlamayı belgeleyin; geçmiş öznitelikler olay anındaki değerleri yansıtmayabilir.
- Filtreler: [Company filter] filtresini yalnızca kiracıya özgü şirket, kuruluş, iş birimi veya tüzel kişilik sütununu doğruladıktan sonra uygulayın. ClaimCenter yapılandırmasında istenen etkinliklerle ilgili, doğrulanmış bir belge türü alanı yoksa belge türüne göre filtre uygulamayın.
- Olay geçmişi: Atama, inceleme, bilgi talepleri, sorumluluk kararları, ödeme durumları ve taleplerin yeniden açılması için geçişleri belirleyecek geçmiş veya denetim verileri gerekir. Yalnızca mevcut durumu içeren tablolar, önceki olayları güvenilir biçimde yeniden oluşturamaz.
- Yinelenen kayıtları ayıklama: Varsa doğrulanmış bir kaynak olay tanımlayıcısı kullanın. Sorgudaki ROW_NUMBER yalnızca yapılandırılabilir bir güvenlik önlemidir. Farklı etkinliklerin aynı anda gerçekleşmesi mümkünse olayları yalnızca ClaimID ve zaman damgasına göre tekilleştirmeyin.
- Performans: Tarih aralığını sınırlayın, yalnızca gerekli sütunları seçin, her kaynağı olay zaman damgasına göre filtreleyin ve uygun boyutta bir Snowflake ambarı kullanın. Büyük hacimler için doğrulanmış bir olay görünümü oluşturmayı veya artımlı veri çıkarımını değerlendirin.
- Saat dilimi: EventTime değerlerini belgelenmiş tek bir saat diliminde standartlaştırın. Event Logu yüklemeden önce CDA zaman damgalarının UTC, yerel saat veya Snowflake zaman damgası türlerinden hangisiyle saklandığını doğrulayın.
- Ön koşullar: Gerekli ClaimCenter finans, etkinlik, atama, teminat, ödeme ve durum geçmişi verilerinin paylaşıma dahil olduğunu ve saklama politikalarının gerekli geçmiş geçişlerini koruduğunu doğrulayın.
Örnek sorgu sql
WITH
params AS (
SELECT
TO_TIMESTAMP_TZ('[Start timestamp]') AS start_ts,
TO_TIMESTAMP_TZ('[End timestamp]') AS end_ts
),
claim_created AS (
SELECT
CAST(c.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Created' AS ActivityName,
CAST(c.[Claim created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(c.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(c.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(c.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(c.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(c.[Claim event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim source object] c
CROSS JOIN params p
WHERE c.[Claim created timestamp column] >= p.start_ts
AND c.[Claim created timestamp column] < p.end_ts
AND [Company filter]
),
claim_assigned AS (
SELECT
CAST(h.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Assigned' AS ActivityName,
CAST(h.[Assignment event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(h.[New assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(h.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(h.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(h.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(h.[Assignment event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim assignment history object] h
CROSS JOIN params p
WHERE h.[Assignment event timestamp column] >= p.start_ts
AND h.[Assignment event timestamp column] < p.end_ts
AND h.[New assigned adjuster column] IS DISTINCT FROM h.[Previous assigned adjuster column]
AND [Company filter]
),
exposure_created AS (
SELECT
CAST(e.[Claim ID column] AS VARCHAR) AS ClaimID,
'Exposure Created' AS ActivityName,
CAST(e.[Exposure created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(e.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(e.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(e.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(e.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(e.[Exposure event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure source object] e
CROSS JOIN params p
WHERE e.[Exposure created timestamp column] >= p.start_ts
AND e.[Exposure created timestamp column] < p.end_ts
AND [Company filter]
),
initial_reserve_set AS (
SELECT
CAST(r.[Claim ID column] AS VARCHAR) AS ClaimID,
'Initial Reserve Set' AS ActivityName,
CAST(r.[Reserve transaction timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(r.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(r.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(r.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(r.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(r.[Reserve transaction identifier column] AS VARCHAR) AS SourceEventID
FROM [Your reserve transaction source object] r
CROSS JOIN params p
WHERE r.[Reserve transaction timestamp column] >= p.start_ts
AND r.[Reserve transaction timestamp column] < p.end_ts
AND r.[Reserve transaction sequence or first reserve indicator column] = [Value identifying first reserve]
AND [Company filter]
),
investigation_started AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Investigation Started' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured investigation activity value]'
AND [Company filter]
),
additional_info_requested AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Requested' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND [Company filter]
),
additional_info_received AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Received' AS ActivityName,
CAST(a.[Activity completion timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity completion timestamp column] >= p.start_ts
AND a.[Activity completion timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND a.[Activity status column] = '[Configured completed status value]'
AND [Company filter]
),
liability_decision_made AS (
SELECT
CAST(eh.[Claim ID column] AS VARCHAR) AS ClaimID,
'Liability Decision Made' AS ActivityName,
CAST(eh.[Exposure status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(eh.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(eh.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(eh.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(eh.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(eh.[Exposure status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure status history object] eh
CROSS JOIN params p
WHERE eh.[Exposure status event timestamp column] >= p.start_ts
AND eh.[Exposure status event timestamp column] < p.end_ts
AND eh.[New exposure status column] = '[Configured liability decision status value]'
AND eh.[New exposure status column] IS DISTINCT FROM eh.[Previous exposure status column]
AND [Company filter]
),
settlement_calculated AS (
SELECT
CAST(pay.[Claim ID column] AS VARCHAR) AS ClaimID,
'Settlement Calculated' AS ActivityName,
CAST(pay.[Payment created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(pay.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(pay.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(pay.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(pay.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(pay.[Payment identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment source object] pay
CROSS JOIN params p
WHERE pay.[Payment created timestamp column] >= p.start_ts
AND pay.[Payment created timestamp column] < p.end_ts
AND pay.[Payment status column] = '[Configured pending approval status value]'
AND [Company filter]
),
payment_approved AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Approved' AS ActivityName,
CAST(ph.[Payment approval timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Approving user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment approval timestamp column] >= p.start_ts
AND ph.[Payment approval timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured approved status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
payment_issued AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Issued' AS ActivityName,
CAST(ph.[Payment issued timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Issuing user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment issued timestamp column] >= p.start_ts
AND ph.[Payment issued timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured issued status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
claim_denied AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Denied' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND ch.[Claim closure reason column] = '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_closed AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Closed' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND COALESCE(ch.[Claim closure reason column], '') <> '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_reopened AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Reopened' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[Previous claim status column] = '[Configured closed status value]'
AND ch.[New claim status column] = '[Configured open status value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
all_events AS (
SELECT * FROM claim_created
UNION ALL SELECT * FROM claim_assigned
UNION ALL SELECT * FROM exposure_created
UNION ALL SELECT * FROM initial_reserve_set
UNION ALL SELECT * FROM investigation_started
UNION ALL SELECT * FROM additional_info_requested
UNION ALL SELECT * FROM additional_info_received
UNION ALL SELECT * FROM liability_decision_made
UNION ALL SELECT * FROM settlement_calculated
UNION ALL SELECT * FROM payment_approved
UNION ALL SELECT * FROM payment_issued
UNION ALL SELECT * FROM claim_denied
UNION ALL SELECT * FROM claim_closed
UNION ALL SELECT * FROM claim_reopened
),
deduplicated_events AS (
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause,
SourceEventID,
ROW_NUMBER() OVER (
PARTITION BY ActivityName, COALESCE(SourceEventID, ClaimID || '|' || TO_VARCHAR(EventTime))
ORDER BY EventTime
) AS duplicate_rank
FROM all_events
WHERE ClaimID IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
)
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause
FROM deduplicated_events
WHERE duplicate_rank = 1
ORDER BY ClaimID, EventTime, ActivityName; Adımlar
- Şirket içindeki Guidewire ClaimCenter operasyonel veritabanına doğrudan salt okunur erişimin onaylandığını, veritabanı platformu ve şema sürümünün belgelendiğini ve salt okunur bağlantının kullanılabildiğini doğrulayın. Onaylı bir veri çıkarma aralığı olmadan üretim veritabanını sorgulamayın.
- ClaimCenter kurulumunuzda kullanılan fiziksel tablo ve sütunları belirleyin. Talep, teminat, etkinlik, atama, karşılık, ödeme, durum geçmişi ve kullanıcı veya grup varlıklarını sorgudaki yer tutucularla eşleyin. Fiziksel adlar ve denetim yapıları kuruluma ve sürüme göre değiştiğinden, her yer tutucuyu yalnızca veritabanı kataloğunuz ve ClaimCenter veri modeliniz üzerinden doğruladıktan sonra değiştirin.
- Veri çıkarma dönemini [Start date parameter] ve [End date parameter] ile belirleyin. Durum değişiklikleri, görev tamamlanması veya finansal işlemler birincil talep oluşturma döneminin dışında kaydedilebiliyorsa, istenen başlangıç tarihinden bir veya iki gün öncesi gibi bir örtüşme aralığı kullanın.
- SQL ifadesinin tamamını salt okunur yetkilerle çalıştırın. Her etkinlik açık bir olay satırı olarak oluşturulur. Sorgu, veri alımından sonra ProcessMind’in olayları çıkarsamasına dayanmaz. Alan değişikliklerinden çıkarılan olaylar, ilgili geçmiş veya denetim kayıtlarından SQL ifadesinin içinde türetilir.
- Her etkinliğin kaynak eşlemesini doğrulayın. Talep oluşturma için ilk kaydedilen Claim kaydının, atama için atama değişikliklerinin, teminat oluşturma için teminat oluşturma kayıtlarının, ilk karşılık için her teminata ait ilk karşılık işleminin, inceleme ve bilgi talepleri için etkinlik kayıtlarının, sorumluluk için yapılandırılmış teminat durumu geçişinin, uzlaşma için onay bekleyen ödeme durumunun, ödeme onayı ve ödemesi için de ilgili finansal denetim durumlarının kullanıldığını doğrulayın.
- Çıktıyı gerekli Event Log yapısına göre standartlaştırın. ClaimID vaka tanımlayıcısı, ActivityName belgelenmiş on dört etkinlik adından tam olarak biri, EventTime ise zaman damgası olmalıdır. Kaynak eşlemesi sağlıyorsa AssignedAdjuster, ClaimType, ClaimStatus ve LossCause dahil önerilen öznitelikleri koruyun.
- Yinelenen olayları ve olay sıralamasını inceleyin. Kaynakta aynı iş geçişi için birden fazla denetim satırı varsa ilgili ortak tablo ifadesinde kuruluma özgü tekilleştirme anahtarını uygulayın. Farklı zaman damgaları veya kaynak tanımlayıcıları olan ayrı iş olaylarını birleştirmeyin.
- Sonucu UTF-8 CSV veya ProcessMind’in desteklediği başka bir tablo biçiminde dışa aktarın. ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus ve LossCause başlıklarını ekleyin. Zaman damgalarının saat dilimi bilgisi içerdiğinden veya belgelenmiş veritabanı saat diliminin tutarlı biçimde kullanıldığından emin olun. Dosyayı ProcessMind’e yükleyin ve ClaimID’yi vaka tanımlayıcısı, ActivityName’i etkinlik, EventTime’ı olay zaman damgası olarak eşleyin.
Yapılandırma
- Veritabanı erişimi: Gerekli ClaimCenter operasyonel tablolarını, geçmiş tablolarını, etkinlik tablolarını ve finansal işlem tablolarını sorgulama izni olan salt okunur bir hesap kullanın. Veri çıkarımı için yazma, şema değiştirme veya yönetici yetkileri vermeyin.
- Şema eşlemesi: [Your claim table], [Your exposure table], [Your activity table], [Your reserve table], [Your payment table], [Your claim history table], [Your exposure history table] ve ilgili yer tutucuları hedef kurulumda doğrulanmış adlarla değiştirin. Mantıksal bir Guidewire varlık adının fiziksel veritabanı tablosuyla aynı olduğunu varsaymayın.
- Tarih aralığı: Üç ila altı aylık veriyle başlayın. [Start date parameter] ve [End date parameter] değerlerini kullanın. Olaylar talep oluşturulduktan sonra kaydedilebiliyorsa veya yeniden açılan talepler birden fazla raporlama dönemine yayılıyorsa örtüşme aralığı ekleyin.
- Filtreler: [Company Code filter], [Document Type filter], yetki bölgesi, iş kolu veya kuruluşa özgü diğer filtreleri yalnızca fiziksel sütunlarını ve iş anlamlarını doğruladıktan sonra uygulayın. Eksiksiz yaşam döngüsü analizi için ödeme veya teminat kaydı bulunmayan talepler de gerektiğinden bunları filtreyle dışarıda bırakmayın.
- Etkinlik adları: ProcessMind’in tutarlı olay etiketleri alması için on dört ActivityName değerini sorguda tanımlandığı biçimde aynen kullanın.
- Olay anlamı: Çıkarım olarak tanımlanan etkinlikler, SQL’de kaynak durum, atama, geçmiş veya etkinlik geçişlerinden oluşturulur. Veri alımından sonra ProcessMind bu olayları diğer satırlardan türetmez.
- Performans: Veri çıkarma dönemini sınırlayın, yalnızca gerekli sütunları seçin, birleştirmelerden önce kaynak tabloları filtreleyin ve talep kimlikleri, teminat kimlikleri, olay zaman damgaları, durum alanları ve işlem tanımlayıcıları üzerindeki dizinleri doğrulayın. Mümkünse büyük veri çıkarımlarını raporlama kopyasında çalıştırın.
- Tutarlılık: Raporlama için uygun bir işlem yalıtım düzeyi kullanın ve tutarlı bir veri çıkarma sınırı belirleyin. Finansal bir toplu işlem veya toplu durum güncellemesi kısmen kaydedilirken tabloları okumayın.
- Saat dilimleri: Veritabanı saat dilimini belgeleyin ve dışa aktarmadan önce tüm kaynak zaman damgalarını üzerinde anlaşılmış tek bir saat dilimine dönüştürün. Uygulama yerel saatiyle veritabanı sunucusu saatini karıştırmayın.
- Ön koşullar: Gerekli ClaimCenter modüllerinin, finansal izinlerin, denetim veya geçmiş verisi saklama ayarlarının ve veritabanı bağlantısının kullanılabilir olduğunu doğrulayın. Geçmiş veya denetim verilerinin saklanması devre dışıysa ilgili etkinlikler güvenilir biçimde yeniden oluşturulamaz.
- Doğrulama yapılandırması: Her dışa aktarma için ClaimCenter sürümünü, veritabanı platformunu, şema eşlemesini, veri çıkarma zamanını, tarih parametrelerini, filtreleri ve satır sayılarını kaydedin.
Örnek sorgu sql
WITH
claim_created AS (
SELECT
c.[Claim ID column] AS ClaimID,
CAST('Claim Created' AS VARCHAR(100)) AS ActivityName,
c.[Claim Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim table] c
WHERE c.[Claim Created Timestamp column] >= [Start date parameter]
AND c.[Claim Created Timestamp column] < [End date parameter]
),
claim_assigned AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Assigned' AS VARCHAR(100)) AS ActivityName,
h.[Assignment Change Timestamp column] AS EventTime,
h.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim assignment history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Assignment Change Timestamp column] >= [Start date parameter]
AND h.[Assignment Change Timestamp column] < [End date parameter]
AND h.[Assigned Adjuster column] IS NOT NULL
),
exposure_created AS (
SELECT
e.[Claim ID column] AS ClaimID,
CAST('Exposure Created' AS VARCHAR(100)) AS ActivityName,
e.[Exposure Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure table] e
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = e.[Claim ID column]
WHERE e.[Exposure Created Timestamp column] >= [Start date parameter]
AND e.[Exposure Created Timestamp column] < [End date parameter]
),
initial_reserve_set AS (
SELECT
x.ClaimID,
CAST('Initial Reserve Set' AS VARCHAR(100)) AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
r.[Claim ID column] AS ClaimID,
r.[Reserve Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause,
ROW_NUMBER() OVER (
PARTITION BY r.[Exposure ID column]
ORDER BY r.[Reserve Timestamp column], r.[Reserve Transaction ID column]
) AS reserve_sequence
FROM [Your reserve transaction table] r
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = r.[Claim ID column]
WHERE r.[Reserve Timestamp column] >= [Start date parameter]
AND r.[Reserve Timestamp column] < [End date parameter]
) x
WHERE x.reserve_sequence = 1
),
investigation_started AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Investigation Started' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Investigation activity type value])
),
additional_info_requested AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Requested' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
),
additional_info_received AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Received' AS VARCHAR(100)) AS ActivityName,
a.[Activity Completed Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Completed Timestamp column] >= [Start date parameter]
AND a.[Activity Completed Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
AND a.[Activity Status column] = [Completed activity status value]
),
liability_decision_made AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Liability Decision Made' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Exposure Status column] IN ([Liability decision status value])
),
settlement_calculated AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Settlement Calculated' AS VARCHAR(100)) AS ActivityName,
p.[Payment Status Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Payment Status Timestamp column] >= [Start date parameter]
AND p.[Payment Status Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Pending approval payment status value]
),
payment_approved AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Approved' AS VARCHAR(100)) AS ActivityName,
p.[Approval Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment approval history table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Approval Timestamp column] >= [Start date parameter]
AND p.[Approval Timestamp column] < [End date parameter]
AND p.[Approval Status column] = [Approved payment status value]
),
payment_issued AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Issued' AS VARCHAR(100)) AS ActivityName,
p.[Issued Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment issuance table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Issued Timestamp column] >= [Start date parameter]
AND p.[Issued Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Issued payment status value]
),
claim_denied AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Denied' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] = [Denied status reason value]
),
claim_closed AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Closed' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] <> [Denied status reason value]
),
claim_reopened AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Reopened' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim status history table] previous_h
ON previous_h.[Claim ID column] = h.[Claim ID column]
AND previous_h.[Status Change Timestamp column] = (
SELECT MAX(prior_h.[Status Change Timestamp column])
FROM [Your claim status history table] prior_h
WHERE prior_h.[Claim ID column] = h.[Claim ID column]
AND prior_h.[Status Change Timestamp column] < h.[Status Change Timestamp column]
)
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND previous_h.[New Claim Status column] = [Closed claim status value]
AND h.[New Claim Status column] = [Open claim status value]
)
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_assigned
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM exposure_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM initial_reserve_set
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM investigation_started
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_requested
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_received
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM liability_decision_made
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM settlement_calculated
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_approved
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_issued
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_denied
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_closed
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_reopened
ORDER BY ClaimID, EventTime, ActivityName; Başlamaya hazır mısınız?
Verilerinizi analize hazırlamak ve hasar taleplerinin işlenmesine ilişkin içgörüleri keşfetmek için bu Templateten yararlanın. İş akışlarınızı bugün iyileştirmeye başlayın.
Hasar taleplerini daha hızlı işleyin ve vakaları daha çabuk sonuçlandırın
Birikmiş işleri azaltın, dolandırıcılığı önleyin ve işlemlerin %70'ini baştan sona otomatik yürütmeyi hedefleyin.
Kredi kartı gerekmez, kurulumu yalnızca birkaç dakika sürer.