Talepleri işleme Veri Templateınız
Talepleri işleme Veri Templateınız
- Toplanması önerilen öznitelikler
- İzlenecek temel faaliyetler
- Guidewire ClaimCenter için veri çıkarma yönlendirmesi
Hasar taleplerinin işlenmesi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Aktivite adı ActivityName | Hasar yaşam döngüsünün belirli bir noktasında gerçekleşen iş faaliyetinin veya olayın adıdır. | ||
| Açıklama Bu öznitelik, hasar sürecindeki belirli bir adımı veya kilometre taşını tanımlar; örneğin 'Claim Created', 'Investigation Started' veya 'Payment Issued'. Belirli bir Claim ID için bu faaliyetlerin sırası süreç akışını oluşturur. Faaliyetlerin sırasını, sıklığını ve aralarındaki süreyi analiz etmek Process Mining'in temelini oluşturur. Bu analiz, süreç modellerini keşfetmenize, darboğazları belirlemenize, yeniden işleme döngülerini tespit etmenize ve süreç sapmalarını incelemenize imkân verir. Neden önemli? Süreç adımlarını tanımlar ve süreç haritalarını görselleştirmenizi, süreç akışını ve darboğazları analiz etmenizi sağlar. Nereden alınır? Genellikle ClaimCenter'daki olay tablolarından veya denetim günlüklerinden elde edilir. Belirli sistem olayları ya da durum değişiklikleri standartlaştırılmış faaliyet adlarıyla eşleştirilir. Örnekler Hasar dosyası oluşturulduYükümlülük kararı verildiÖdeme düzenlendiHasar dosyası kapatıldı | |||
| Hasar ID'si ClaimID | Her sigorta hasar dosyasının benzersiz tanımlayıcısıdır ve birincil vaka tanımlayıcısı olarak kullanılır. | ||
| Açıklama Claim ID, hasar süreci analizinin temelidir ve her vakayı gönderimden kapanışa kadar benzersiz biçimde tanımlar. İlişkili tüm faaliyetleri, belgeleri, ödemeleri ve iletişimleri birbirine bağlayarak hasar dosyasının yaşam döngüsünü eksiksiz ve tutarlı biçimde görmenizi sağlar. Process Mining'de Veri Seti içindeki her olay bir Claim ID'ye bağlıdır. Bu sayede uçtan uca süreç akışı yeniden oluşturulabilir. Claim ID, çevrim sürelerini analiz etmek, süreç varyantlarını belirlemek ve bir hasar dosyasının farklı departmanlar ve hasar uzmanları arasındaki yolculuğunu 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 yolculuğunu izlemeyi ve analiz etmeyi mümkün kılar. Nereden alınır? Guidewire ClaimCenter'da birincil anahtar olarak kullanılır ve genellikle temel Claim varlığındaki Claim.ClaimNumber veya benzer bir alanda bulunur. Örnekler 000-123-45678000-987-65432001-456-11223 | |||
| Olay zamanı EventTime | Faaliyetin gerçekleştiği kesin tarih ve saattir. | ||
| Açıklama Bu zaman damgası, bir faaliyetin sistemde kaydedildiği kesin anı gösterir. Zamana dayalı tüm süreç analizlerinin temelini oluşturur. Tek bir Claim ID için EventTime değerlerinin kronolojik sıralanması, süreç akışının yeniden oluşturulmasını sağlar. Ardışık olaylar arasındaki zaman farkı; performans analizi, darboğazların belirlenmesi ve SLA izleme açısından önemli olan çevrim sürelerini, bekleme sürelerini ve işlem sürelerini hesaplamak için kullanılır. Neden önemli? Bu zaman damgası, olayları sıralamak, çevrim sürelerini ve süreleri hesaplamak ve süreçteki gecikmeleri belirlemek için gereklidir. Nereden alınır? Guidewire ClaimCenter'daki geçmiş veya denetim tablolarında olay ya da faaliyet verilerinin yanında bulunur ve çoğu zaman 'CreateTime' veya 'UpdateTime' alanı olarak yer alır. Örnekler 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
| Atanan eksper AssignedAdjuster | Hasarı veya belirli bir etkinliği ele almakla görevlendirilen kullanıcının adı ya da kimliği. | ||
| Açıklama Bu öznitelik, belirli bir zamanda bir hasardan sorumlu olan eksperi tanımlar. Eksper, hasarın tamamına veya hasar içindeki belirli görevlere atanabilir. Atanan eksper bazında analiz yapmak, iş yükünü dengelemek, performansı yönetmek ve eğitim fırsatlarını belirlemek için büyük önem taşır. Bu analiz, 'Hangi eksperlerin dosya yükü en yüksek?', 'Eksperler arasında performans farklılıkları var mı?' ve 'İşler dengeli dağıtılıyor mu?' gibi soruları yanıtlamaya yardımcı olur. Neden önemli? Kullanıcı katılımını izler; iş yükü analizine, performans karşılaştırmasına ve kaynakla ilgili darboğazların belirlenmesine imkan verir. Nereden alınır? ClaimCenter içindeki Claim veya Exposure varlığında bulunur ve genellikle User nesnesine bağlanı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 Open, Closed veya Denied. | ||
| Açıklama Bu öznitelik, hasarın genel durumunu gösterir. Temel durumlar arasında 'Open', 'Closed', 'Denied' ve 'Reopened' bulunur. Hasarın nihai durumu, önemli bir sonuç metriğidir. Hasar durumundaki değişiklikleri izlemek, temel süreç kilometre taşlarını ve sonuçlarını tanımlamaya yardımcı olur. Bu bilgi, hasarın nihai çözümünü belirlemek, ret oranlarını hesaplamak ve kapatıldıktan sonra yeniden açılan hasarların sıklığını analiz etmek için kullanılır. Yeniden açılma sıklığı, ç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ı, kapatma modellerini ve yeniden açılma sıklığını analiz etmek için gereklidir. Nereden alınır? Claim varlığındaki temel bir alandır ve genellikle 'State' veya 'Status' olarak adlandırılır. Örnekler AçıkKapatıldıReddedildiYeniden açıldı | |||
| Hasar nedeni LossCause | Hasara yol açan olayın belirli nedeni. Örneğin Collision, Fire veya Water Damage. | ||
| Açıklama Bu öznitelik, hasarın neden bildirildiği hakkında ayrıntılı bağlam sağlar. Hasarın nedeni, gerekli inceleme adımlarını, ihtiyaç duyulan uzman türünü ve hasarın genel karmaşıklığını belirleyebilir. Süreci hasar nedenine göre analiz etmek, gizli kalmış örüntüleri ortaya çıkarabilir. Örneğin 'Water Damage' ile ilgili hasarlarda, 'Theft' hasarlarına göre yeniden işleme oranı daha yüksek olabilir veya 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 sağlar ve farklı hasar nedenlerinin süreç akışını ve süresini nasıl etkilediğini analiz etmenize imkan verir. Nereden alınır? Claim varlığındaki standart bir alandır ve genellikle 'LossCause' olarak adlandırılır. Örnekler ÇarpışmaYangınSu HasarıHırsızlık | |||
| Hasar türü ClaimType | Otomobil, mülk veya sorumluluk gibi sigorta hasarının kategorisi. | ||
| Açıklama Hasar türü, iş koluna veya zararın niteliğine göre yapılan temel bir sınıflandırmadı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ümlendirmek gerekir. Bu yaklaşım, farklı iş kollarındaki süreç performansını karşılaştırmanıza, türe özgü darboğazları belirlemenize ve süreç iyileştirme çalışmalarını her hasar kategorisinin özelliklerine göre uyarlamanıza imkan verir. Neden önemli? Hasarları bölümlendirmenizi sağlar. Örneğin otomobil ve mülk hasarları genellikle farklı süreçlerden geçer ve farklı performans hedeflerine sahiptir. Nereden alınır? ClaimCenter içindeki Policy veya Claim varlığından türetilir ve genellikle Line of Business (LOB) koduna dayanır. Örnekler Bireysel OtoTicari MülkGenel Sorumlulukİşçi Tazminatı | |||
| Bitiş zamanı EndTime | Bir etkinliğin tamamlandığı zamanı gösteren zaman damgası. | ||
| Açıklama Bitiş zamanı, özellikle 'Investigation' veya 'Document Review' gibi ölçülebilir süreye sahip görevlerde bir etkinliğin tamamlandığını gösterir. Process Mining etkinliklerinin çoğu anlık gerçekleştiği için StartTime yeterli olabilir. Ancak belirgin bir başlangıç ve bitiş zamanı olan etkinlikler için her iki zaman damgasını kullanmak daha doğru sonuç verir. Bu öznitelik, bekleme süresinden ayrı olarak etkinliğin işlenme süresinin hassas biçimde hesaplanmasını sağlar. Böylece yalnızca adımlar arasındaki uzun gecikmeleri görmek yerine, hangi görevlerin gerçekten zaman aldığını belirleyebilirsiniz. Neden önemli? Bir etkinliğin tamamlanmasının ne kadar sürdüğünü hassas biçimde ölçmenizi ve işlenme süresini bekleme süresinden ayırmanızı sağlar. Nereden alınır? Etkinliği mantıksal olarak tamamlayan sonraki bir olay bulunarak türetilmesi gerekebilir. Örneğin durumun 'In Progress' değerinden 'Completed' değerine değiş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ülmesinin 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 uyumluluk ölçümü için bir referans noktası görevi görür. Bu öznitelik, SLA uyumluluğu için Dashboard ve KPI'lar oluştururken büyük önem taşır. Gerçek 'Claim Closed' tarihini hedef tarihle karşılaştırarak geç kalan hasarları otomatik olarak işaretleyebilir, zamanında tamamlama oranlarını ölçebilir ve hedeflerini 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 kullanılan referans noktasıdır. Nereden alınır? ClaimCenter'da yapılandırılan iş kurallarına göre oluşturulan özel bir alan olabilir veya türetilebilir. Belirli hasar metrikleriyle ilişkili olması mümkündür. Örnekler 2023-06-142023-07-202023-08-28 | |||
| Departman Department | Hasar etkinliğini ele almaktan sorumlu iş birimi veya departman. | ||
| Açıklama Bu öznitelik, atanan eksperin bağlı olduğu departmanı veya ekibi gösterir. Örnekler arasında 'Auto Claims', 'Property Claims' ve 'Special Investigations Unit' yer alır. Böylece sürece ilişkin kurumsal bağlam sağlanır. Departman bazında analiz yapmak, süreç performansını kurumsal düzeyde anlamak için önemlidir. Departmanlar arasındaki devir gecikmelerini belirlemenize, ekiplerin verimliliğini karşılaştırmanıza ve hasar organizasyonundaki kaynakları daha etkili dağıtmanıza yardımcı olur. Neden önemli? Kurumsal bağlam sağlar; farklı ekiplerin performansını analiz etmenize ve departmanlar arasındaki devir sorunlarını görmenize yardımcı olur. Nereden alınır? Bu bilgi genellikle ClaimCenter içindeki atanan kullanıcının veya grubun profiliyle ilişkilendirilir. Örnekler Oto Hasarları BölümüMülk Hasarları BirimiÖzel İncelemeler Birimi (SIU) | |||
| Hasar tarihi LossDate | Hasara yol açan olayın veya zararın gerçekleştiği tarih. | ||
| Açıklama Hasar tarihi, hasarın bildirildiği gerçek olayın tarihidir. Örneğin trafik kazası veya mülk hasarı. Bu tarih, hasarın bildirildiği ya da oluşturulduğu tarihten farklıdır. Hasar tarihi ile 'Claim Created' etkinliği arasındaki süre, bildirim gecikmesi olarak bilinir ve önemli bir KPI'dır. Bu süreyi analiz etmek, müşteri davranışı ve ilk hasar bildirimi kanallarının etkinliği hakkında içgörü sağlayabilir. Neden önemli? Hasarın kaynağı hakkında önemli bağlam sağlar ve bildirim gecikmesini, yani olay ile hasar bildirimi arasındaki süreyi analiz etmenize yardımcı olur. Nereden alınır? Claim varlığındaki temel bir tarih alanıdır ve genellikle 'LossDate' olarak adlandırılır. Örnekler 2023-05-102023-04-202023-05-28 | |||
| Kaynak sistem SourceSystem | Verilerin çıkarıldığı sistemdir. | ||
| Açıklama Bu öznitelik, olay verilerinin kaynağını tanımlar. Modern bir kurumsal ortamda hasarla ilgili olaylar Guidewire gibi bir temel sistemden, belge yönetim sisteminden veya müşteri portalından gelebilir. Kaynak sistemi belirtmek; veri yönetişimi, veri tutarsızlıklarının giderilmesi ve sürecin teknolojik yapısının anlaşılması için önemlidir. Temel süreç adımlarını çevre sistemlerdeki destekleyici faaliyetlerden ayırmaya yardımcı olur. Neden önemli? Verilerin kaynağını tanımlar. Bu bilgi, veri yönetişimi ve birden fazla entegre sistemi içeren analizler için önemlidir. Nereden alınır? Genellikle veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde eklenen statik bir değerdir. Örnekler Guidewire ClaimCenter v10Müşteri Portalı API'siDocumentum | |||
| Ödeme tutarı PaymentAmount | Bir ödeme etkinliği kapsamında fiilen ödenen para tutarı. | ||
| Açıklama Bu öznitelik, bir hasar için yapılan her bir ödemenin değerini kaydeder. Tek bir hasar yaşam döngüsü boyunca birden fazla ödeme içerebilir. Bu bilgi, Process Mining kapsamında finansal analiz için gereklidir. Hasar başına toplam ödemeyi izlemek, tutara göre ödeme onay sürelerini analiz etmek ve süreç verimsizliklerini finansal sonuçlarla ilişkilendirmek için kullanılabilir. Örneğin uzun çevrim sürelerine sahip hasarlar, daha yüksek toplam ödemelerle ilişkili olabilir. Neden önemli? Hasar içindeki finansal işlemleri izler; ödeme değerlerini ve bunların süreç etkinlikleriyle ilişkisini analiz etmenizi sağlar. Nereden alınır? Hasarla bağlantılı ödeme varlıklarında, genellikle işlem veya çek tablosunda bulunur. Örnekler 4500.00125000.00500.00 | |||
| Otomatik mi IsAutomated | Bir etkinliğin sistem tarafından otomatik olarak mı yoksa insan kullanıcı tarafından mı gerçekleştirildiğini gösteren işaret. | ||
| Açıklama Bu boolean öznitelik, sistem tarafından yürütülen etkinliklerle, örneğin otomatik karşılık oluşturma veya sistem tarafından oluşturulan yazışmalarla, eksper tarafından manuel olarak gerçekleştirilen etkinlikleri birbirinden ayırır. Bu özniteliği analiz etmek, hasar sürecindeki otomasyon düzeyini anlamanın temel yollarından biridir. Manuel müdahale noktalarını belirlemenize, doğrudan işleme girişimlerinin etkinliğini ölçmenize ve insanların hâlâ gerçekleştirdiği tekrarlı, kural tabanlı görevleri ortaya çıkararak yeni otomasyon fırsatları bulmanıza yardımcı olur. Neden önemli? Sistem tarafından yürütülen etkinliklerle insan tarafından yürütülen etkinlikleri ayırır; otomasyon analizi ve manuel darboğazların belirlenmesi için önemlidir. Nereden alınır? Genellikle türetilmesi gerekir. Ö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 belirli sigorta poliçesi türü. | ||
| Açıklama Poliçe türü, hasar türüne göre daha ayrıntılı bir sınıflandırma sunar ve 'Homeowners', 'Commercial Auto' veya 'Cyber Liability' gibi belirli sigorta ürünlerini tanımlar. 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üne özgü verimsizlikleri görmenize yardımcı olur. Örneğin yeni sunulan bir poliçeye ait hasarlar, daha az olgun bir süreçten geçerek gecikmelere yol açabilir. Bu analiz, ürün tasarımı ve süreç standardizasyonu çalışmalarına yön verebilir. Neden önemli? Belirli sigorta ürünleri için süreç analizi yapmanızı ve poliçe özelliklerine göre işlem farklılıklarını belirlemenizi sağlar. Nereden alınır? Bu bilgi, Claim ile bağlantılı olan Policy varlığında bulunur. Örnekler Konut Sahipleri Çoklu RiskTicari Oto Sorumluluğuİç Sular Taşımacılığı | |||
| SLA durumu SLAState | Hasarın çözüm hedef tarihi içinde kapatılıp kapatılmadığını gösterir. | ||
| Açıklama Bu hesaplanan öznitelik, kapatılan her talep için SLA uyumluluk durumunu kategorik olarak gösterir. Claim Closed etkinliğinin zaman damgası ile Resolution Target Date karşılaştırılarak elde edilir. Bu öznitelik, analizi On Time veya Late gibi net kategorilere ayırarak Claim Resolution Target Adherence Dashboardını doğrudan destekler. Gecikmelerin nedenlerini ayrıntılı incelemenin yanı sıra genel SLA uyumluluk oranını hesaplamak için kolay filtreleme ve toplama olanağı sağlar. Neden önemli? SLA uyumluluğu için açık ve kategorik bir sonuç sağlar; zamanında tamamlanan işlemleri filtrelemeyi, toplulaştırmayı ve analiz etmeyi kolaylaştırır. Nereden alınır? Hesaplanan alan: IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late'). Örnekler ZamanındaGecikmiş | |||
| Son veri güncellemesi LastDataUpdate | Verilerin kaynak sistemden en son ne zaman yenilendiğini veya çıkarıldığını gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, kaynak sistemden en son veri çekme işleminin zaman damgasını sağlar. Analizin güncelliğini anlamak için gerekli bir meta veri alanıdır. Dashboard ve analizler, kullanıcıların verilerin güncelliğini görebilmesi için bu bilgiyi belirgin şekilde göstermelidir. Bu bilgi, içgörülerin operasyonların mevcut durumunu yansıtıp yansıtmadığını veya eski verilere dayanıp dayanmadığını değerlendirmeye yardımcı olur. Neden önemli? Verilerin güncelliğini gösterir ve 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 sürecinde oluşturulur ve saklanır; veri yükleme işleminin 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 parasal tutar. | ||
| Açıklama Bu öznitelik, talep sahibinin bildirdiği zarar değerini gösterir. Genellikle hasar incelendikçe ve karşılıklar belirlendikçe değişebilen ilk tahmindir. Talep edilen tutarı analiz etmek, hasarları finansal etkilerine göre bölümlendirmenize yardımcı olur. Yüksek tutarlı hasarlar, düşük tutarlı hasarlara göre daha ayrıntılı ve karmaşık bir süreçten geçebilir. Farklı değer aralıklarındaki süreçleri karşılaştırmak, küçük hasarların ele alınmasını kolaylaştırma veya büyük hasarlar için daha sıkı kontroller uygulama fırsatlarını ortaya çıkarabilir. Neden önemli? Hasarları finansal değerlerine göre bölümlendirmenizi 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ındaki ilk zarar tahminlerinden türetilebilir. Örnekler 5000.00150000.00750.50 | |||
| Tekrarlanan bilgi talebi RepeatedInfoRequestFlag | Aynı hasar için 'Additional Info Requested' etkinliğinin birden fazla kez gerçekleşip gerçekleşmediğini gösteren işaret. | ||
| Açıklama Bu boolean işaret, bir hasar için birden fazla 'Additional Info Requested' etkinliği gerçekleştiğinde true olarak ayarlanır. Bu durum genellikle ilk bilgi toplama aşamasındaki verimsizliklere işaret eder. Bu öznitelik, 'Repeated Info Request Rate' KPI'ını doğrudan destekler. İlk bilgi toplama işleminin eksik yapılmasından kaynaklanan ve önemli gecikmelere ve müşteri memnuniyetsizliğine yol açabilen sorunun ölçülmesine yardımcı olur. Bu işaretin bulunduğu hasarları analiz etmek, eksperlerin gerekli tüm bilgileri tek seferde istemesini sağlamak üzere kontrol listelerini ve prosedürleri iyileştirmenize yardımcı olabilir. Neden önemli? Bilgi toplama işleminin ilk seferde tamamlanmadığı, bunun da süreç gecikmelerine ve yeniden işlemeye yol açtığı verimsizlikleri belirler. Nereden alınır? Vaka başına 'Additional Info Requested' etkinliğinin gerçekleşme sayısı hesaplanarak Process Mining aracı içinde türetilir. Örnekler truefalse | |||
| Yargı bölgesi JurisdictionState | Hasarı yöneten ve düzenleyici gereklilikleri belirleyen eyalet veya yargı bölgesi. | ||
| Açıklama Bu öznitelik, hasarın ele alındığı hukuki yargı bölgesini, örneğin ABD'deki eyaleti, 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 belgeleri etkileyebilir. Bu öznitelik, uyumluluğu izlemek için büyük önem taşır. Süreci yargı bölgesine göre analiz etmek, eyalete özgü düzenleyici gerekliliklerin karşılanıp karşılanmadığını kontrol etmenizi sağlar. Ayrıca çevrim sürelerindeki veya süreç yollarındaki farklılıkların operasyonel verimsizlikten değil, hukuki kısıtlamalardan kaynaklandığını açıklayabilir. Neden önemli? Uyumluluk analizi için önemlidir; farklı yargı bölgelerindeki düzenlemeler hasar sürecini farklı şekillerde etkiler. Nereden alınır? Claim varlığındaki standart bir alandır ve genellikle 'JurisdictionState' olarak adlandırılır. Örnekler CANYTXFL | |||
| Yeniden işleme mi IsRework | Bir etkinliğin yeniden işleme döngüsünü, yani önceki bir süreç aşamasına dönüşü temsil edip etmediğini gösteren işaret. | ||
| Açıklama Bu hesaplanan öznitelik, yeniden işleme döngüsünün parçası olan etkinlikleri işaretler. Örneğin süreç 'Investigation Completed' adımından 'Investigation Started' adımına geri dönüyorsa, ikinci 'Investigation Started' etkinliği yeniden işleme olarak işaretlenir. Yeniden işlemeyi belirlemek, süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarmak için temel bir adımdır. Rework and Rejection Frequency Dashboard, hasarların ideal 'happy path'ten ne sıklıkta saptığını ölçmek için bu metriğe dayanır. Yeniden işlemenin nedenlerini analiz etmek, süreç kalitesinde ve hızında önemli iyileştirmeler sağlayabilir. Neden önemli? Yeniden işleme döngüsünün parçası olan etkinlikleri açıkça işaretleyerek süreç verimsizliklerini ve kalite sorunlarını görünür kılar. Nereden alınır? Her vaka için etkinlik dizisi analiz edilerek Process Mining aracı içinde hesaplanır. Örnekler truefalse | |||
Hasar taleplerinin işlenmesi faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Exposure oluşturuldu | Bu faaliyet, hasar dosyası kapsamındaki belirli bir potansiyel yükümlülüğü veya kayıp türünü temsil eden bir Exposure'ın oluşturulmasını ifade eder (örneğin araç hasarı veya yaralanma). Bu, Guidewire içinde açıkça kaydedilen bir olaydır. | ||
| Neden önemli? Exposure'lar, hasar dosyalarının bölümlendirilmesi ve analizi için temel unsurlardır. Oluşturulmalarını izlemek, hasarın karmaşıklığına ve kayıp türüne göre süreç farklılıklarını anlamaya yardımcı olur. Nereden alınır? cc_exposure tablosundaki yeni bir kaydın CreateTime alanından yakalanır. Her kayıt tek bir Claim ID ile ilişkilendirilir. Yakalayın Exposure varlık tablosundaki yeni kaydın oluşturulma zaman damgasını belirleyin. Olay türü explicit | |||
| Hasar dosyası kapatıldı | Tüm faaliyetler ve ödemeler tamamlandıktan sonra hasar dosyasının başarıyla kapatılmasını belirtir. Hasar dosyasının ana durumundaki değişiklikten çıkarılan birincil başarılı bitiş olayıdır. | ||
| Neden önemli? Birincil bitiş olayı olarak bu faaliyet, uçtan uca çevrim süresini hesaplamak ve SLA uyumunu ölçmek için gereklidir. Hasar yaşam döngüsünün tamamlandığını gösterir. Nereden alınır? cc_claim tablosundaki State alanının 'Closed' olarak değişmesinden çıkarılır. Olayın zaman damgası, hasar kaydındaki CloseDate alanıdır. Yakalayın Hasar dosyasının ana durum alanının ne zaman 'Closed' olarak güncellendiğini belirleyin. Olay türü inferred | |||
| Hasar dosyası oluşturuldu | Bu faaliyet, ilk hasar bildirimini (FNOL) ve Guidewire ClaimCenter'da yeni bir hasar kaydının resmî olarak oluşturulmasını belirtir. Yeni bir Claim varlığı veritabanına ilk kez kaydedildiğinde açıkça yakalanır. | ||
| Neden önemli? Birincil başlangıç olayı olarak bu faaliyet, uçtan uca hasar ç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 yakalanan açık bir olaydır. Benzersiz bir Claim ID içeren yeni bir kaydın oluşturulması olay tetikleyicisi olarak kullanılır. Yakalayın Temel Claim varlık tablosundaki yeni kaydın oluşturulma zaman damgasını belirleyin. Olay türü explicit | |||
| Hasar dosyası reddedildi | Bir hasar dosyasını reddetmeye yönelik nihai kararı ifade eder ve süreç için son nokta görevi görür. Hasar dosyasının durumu 'Denied' nedeni ile kapalı bir duruma değiştiğinde bu olay çıkarılır. | ||
| Neden önemli? Bu, önemli bir sonuç olayıdır. Retlerin sıklığını, nedenlerini ve retlere giden süreç yollarını analiz etmek; hasar kabulü, inceleme veya poliçe yorumlamasındaki sorunları belirlemeye yardımcı olur. Nereden alınır? cc_claim tablosundaki State alanının 'Closed' olarak değişmesi ve CloseReason alanının 'Denied' veya benzer bir değer olması birlikte değerlendirilerek çıkarılır. Olayın zaman damgası CloseDate alanıdır. Yakalayın Neden kodunun ret olduğunu gösterdiği durumlarda hasar durumunun 'Closed' olarak değiştiği kayıtları filtreleyin. Olay türü inferred | |||
| İlk rezerv belirlendi | Bir Exposure için ilk finansal rezerv işleminin oluşturulmasını ve hasarın olası maliyetinin tahmin edilmesini belirtir. Bu, açıkça yakalanan önemli bir finansal olaydır. | ||
| Neden önemli? Bu kilometre taşı, finansal analiz ve potansiyel yükümlülüğün ne kadar hızlı değerlendirildiğini anlamak için önemlidir. Gecikmeler finansal planlamayı ve raporlamayı etkileyebilir. Nereden alınır? Bu olay, hasar dosyasındaki bir Exposure ile ilişkili ilk cc_reserveline kaydının oluşturulmasından yakalanır. İşlemin CreateTime alanı olayın zaman damgasıdır. Yakalayın Belirli bir hasar dosyasının Exposure'larına ait tüm rezerv satırları arasındaki en erken oluşturulma zaman damgasını bulun. Olay türü explicit | |||
| Ödeme düzenlendi | Bu faaliyet, ödemenin resmî olarak düzenlenip finansal sisteme gönderildiği ödeme sürecinin son adımını belirtir. Açıkça kaydedilen bir finansal işlemdir. | ||
| Neden önemli? Bu faaliyet, ödeme gönderme sürecinin verimliliğini ölçmek için önemlidir. Onay gecikmeleri ile fonların fiilen düzenlenmesindeki gecikmeleri ayırt etmeye yardımcı olur. Nereden alınır? cc_check veya cc_transaction varlığındaki IssueDate alanından ya da durumun 'Issued' veya 'Submitted' olarak değişmesinden yakalanır. Bu, çoğu zaman zaman damgası içeren açık bir olaydır. Yakalayın Ödeme kaydındaki IssueDate alanını veya durumun 'Issued' olarak değiştiği zaman damgasını belirleyin. Olay türü explicit | |||
| Ödeme onaylandı | Bir sonuçlandırma ödemesinin resmî olarak onaylanmasını ifade eder. Bu, yetkili bir kullanıcı işlemi onayladığında açıkça kaydedilen önemli bir denetim olayıdır. | ||
| Neden önemli? Bu önemli kilometre taşı, son ödeme adımının önündeki engeli kaldırır. Bu etkinlikten önceki ve sonraki süreyi analiz etmek, onay iş akışlarından veya yöneticilerin uygun olmamasından kaynaklanan gecikmeleri ayırmaya yardımcı olur. Nereden alınır? Bu, çoğu zaman cc_check veya cc_transaction varlığıyla ilişkili cc_history tablosunda açıkça kaydedilen bir olaydır ve durumun 'Pending Approval'dan 'Approved'a değiştiğini gösterir. Yakalayın Belirli bir ödeme işlemi için durumun 'Approved' olarak değiştiği olayı izleyin. Olay türü explicit | |||
| Ek bilgi alındı | Ek bilgi talebinin tamamlandığını belirtir. Bilgi talebine karşılık gelen 'Activity' (görev) 'Completed' olarak işaretlendiğinde yakalanır. | ||
| Neden önemli? Bu, 'Additional Info Gathering Cycle Time' KPI'ının bitiş noktasıdır. Talep ile bilginin alınması arasındaki uzun süreler, hasar sürecindeki yaygın gecikme kaynaklarıdır. Nereden alınır? ActivityPattern alanı bilgi talebiyle ilişkili olan bir cc_activity kaydının CloseTime alanından yakalanır. Activity durumu 'Completed' olmalıdır. Yakalayın Dış bilgi isteme görevinin tamamlanma zaman damgasını belirleyin. Olay türü explicit | |||
| Ek bilgi istendi | Hasar sahibine veya üçüncü bir tarafa daha fazla bilgi ya da belge göndermesi için iletilen talebi ifade eder. Bu durum genellikle ClaimCenter'da açık bir 'Activity' (görev) oluşturulmasıyla kaydedilir. | ||
| Neden önemli? Bu faaliyet, 'Additional Info Gathering Cycle Time' KPI'ını ölçmenin başlangıç noktasıdır. Sık tekrarlanması, eksik FNOL süreçlerine veya verimsiz bilgi toplama işlemlerine işaret edebilir. Nereden alınır? ActivityPattern alanı dış bir taraftan belge veya bilgi istemeyle ilişkili olan bir cc_activity kaydının CreateTime alanından yakalanır. Yakalayın Dış bilgi istemek üzere oluşturulan görevi belirleyin. Olay türü explicit | |||
| Hasar dosyası atandı | Bir hasar dosyasının işlem yapılması için belirli bir kullanıcıya (hasar uzmanına) veya gruba atanmasını ifade eder. Bu durum genellikle Claim varlığındaki atama alanlarında yapılan değişiklikler izlenerek çıkarılır. | ||
| Neden önemli? Atamaları izlemek, hasar uzmanlarının iş yükünü analiz etmek, yönlendirme darboğazlarını belirlemek ve atanan görevlinin 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ılır. Değişikliğin zaman damgası, olayın ne zaman gerçekleştiğini gösterir. Yakalayın 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 yapmak üzere bir hasar dosyasının 'Closed' durumundan yeniden 'Open' durumuna geçirilmesini ifade eder. Bu olay, belirli bir durum değişikliği dizisinden çıkarılır. | ||
| Neden önemli? Bu faaliyet yeniden işlemeyi gösterir. Yeniden açılan hasar dosyalarının yüksek sayıda olması, ilk sonuçlandırmadaki sorunlara, gözden kaçan hasarlara veya diğer süreç hatalarına işaret eder ve maliyetleri ve verimsizliği artırır. Nereden alınır? cc_history tablosunda cc_claim varlığının State alanının 'Closed'dan yeniden 'Open' veya başka bir etkin duruma değiştiği belirlenerek çıkarılır. Yakalayın 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şlatıldı | Bir talep veya hasar dosyası için inceleme aşamasının resmî başlangıcını gösterir. Bu başlangıç, genellikle Guidewire içindeki incelemeyle ilgili ilk Etkinlik görevinin oluşturulmasından anlaşılır. | ||
| Neden önemli? Bu faaliyet, genellikle uzun süren önemli 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, başlıca darboğazları ortaya çıkarır. Nereden alınır? ActivityPattern alanı incelemeyle ilişkili olan bir cc_activity kaydının CreateTime alanından çıkarılır (örneğin 'Initial Investigation', 'Contact Witness'). Yakalayın İncelemeyle ilişkili bir kalıba veya konuya sahip görevin ilk kez oluşturulmasını belirleyin. Olay türü inferred | |||
| Sonuçlandırma hesaplandı | Sonuçlandırma tutarının belirlendiği ancak ödeme için henüz onaylanmadığı noktayı ifade eder. 'Pending Approval' durumundaki bir ödemenin oluşturulmasından çıkarılabilir. | ||
| Neden önemli? Değerlendirmeden ödemeye geçişi belirtir. 'Payment Authorization Lead Time' KPI'ını ölçmenin başlangıç noktasıdır ve onay zincirindeki gecikmeleri ortaya çıkarır. Nereden alınır? İlk durumu 'Pending Approval' veya 'Approved' öncesindeki benzer bir durum olan bir cc_check ya da cc_transaction kaydının CreateTime alanından çıkarılır. Yakalayın Ön onay durumundaki bir ödeme veya işlem kaydının oluşturulmasını belirleyin. Olay türü inferred | |||
| Yükümlülük kararı verildi | Bir Exposure için yükümlülük veya kusur kararının belirlendiği noktayı ifade eder. Bu olay genellikle Exposure varlığındaki durum değişikliğinden çıkarılır. | ||
| Neden önemli? Bu, sonuçlandırma ve ödeme aşamalarını başlatan önemli bir karar kilometre taşıdır. Bu 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 veya özel yükümlülük durumu alanında yapılan değişiklikler cc_history tablosundan izlenerek çıkarılır. Geçmiş kaydının zaman damgası olay zamanını gösterir. Yakalayın Exposure durumundaki veya yükümlülük durumundaki güncellemeler için denetim günlüklerini ya da geçmiş tablolarını izleyin. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşulları doğrulayın: Guidewire DataHub / InfoCenter veri martı veritabanına okuma yetkisiyle erişmek için gerekli izinlere ve kimlik bilgilerine sahip olduğunuzu doğrulayın. Hasar verisi martını dolduran ETL işlerinin başarıyla çalıştığından ve verilerin güncel olduğundan emin olun.
- Veritabanı bağlantısı: Veri martı veritabanı sunucusuna bağlanmak için standart bir SQL istemcisi, örneğin DBeaver, SQL Server Management Studio veya benzer bir araç kullanın.
- Şemayı inceleyin: Tam sorguyu çalıştırmadan önce veri martı şemasını tanıyın. Hasarlar, teminatlar, faaliyetler ve finansal işlemler için temel tabloları belirleyin. Temel tabloların adları genellikle _dim (boyut) ve _fact (olgu) gibi son ekler içerir. Bu inceleme, sağlanan betikteki yer tutucu tablo ve sütun adlarını doğrulamanıza yardımcı olur.
- SQL sorgusunu hazırlayın: Sorgu bölümünde sağlanan eksiksiz SQL betiğini SQL istemcinizin sorgu düzenleyicisine kopyalayın.
- Yer tutucuları özelleştirin: Betiği dikkatle inceleyin ve tüm yer tutucu değerleri değiştirin. Buna veritabanı/şema adı, örneğin [YourDataMart], tarih aralığı parametreleri ('[StartDate]', '[EndDate]') ve sisteme özgü yapılandırma değerleri, örneğin faaliyet kalıpları ve durum kodları dahildir.
- Sorguyu çalıştırın: Değiştirilmiş SQL sorgusunu veri martına karşı ç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ümesindeki ilk birkaç yüz satırı inceleyin. ClaimID, ActivityName ve EventTime sütunlarının beklendiği gibi doldurulduğunu ve farklı faaliyet türlerinin bulunduğunu kontrol edin.
- CSV'ye aktarın: Sonuç kümesinin tamamını SQL istemcinizden bir 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ırdır.
Yapılandırma
- Veri kaynağı: Guidewire DataHub/InfoCenter Hasar Veri Martı. Bu veri martı, canlı ClaimCenter üretim veritabanından ayrı, raporlama ve analitik için tasarlanmış, önceden toplulaştırılmış boyutsal bir veritabanıdır.
- Gerekli yetkilendirmeler: Veri martını barındıran SQL veritabanına salt okunur erişim. Kullanıcı adı, parola ve bağlantı ayrıntılarına, yani sunucu adresi ve veritabanı adına ihtiyacınız olacaktır.
- ETL işi durumu: Bu çıkarımın doğruluğu, veri martını dolduran Guidewire ETL işlerinin başarılı ve zamanında çalışmasına bağlıdır. Verilerin güncelliğini anlamak için son başarılı çalışma 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 sınırlı bir tarih aralığıyla, örneğin 3-6 ayla başlamanız önerilir. Tarih filtresi hasarın 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 ayarlamanız gerekir. Buna şunlar dahildir:
- ActivityPattern adları, örneğin 'fnol', 'investigation', 'Request additional information'
- ClaimStatus, ExposureStatus ve CloseReason kodları, örneğin 'denied', 'closed'
- TransactionStatus kodları, örneğin 'pendingapproval', 'approved', 'issued'
- Performans: Büyük geçmiş veya denetim tablolarını sorgulamak kaynak tüketebilir. Çok büyük Veri Setleri için sorguyu yoğun olmayan saatlerde çalıştırmanız önerilir. İlgili tablolarda ClaimID veya ClaimNumber sütunlarının dizinlendiğinden emin olun.
a Ö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. Snowflake hesap tanımlayıcısını, veritabanını, şemayı, warehouse'u, rolü, kimlik doğrulama yöntemini ve yetkili ağ yapılandırmasını Guidewire Cloud yöneticinizden alın.
- Paylaşımınızda sunulan CDA veritabanı nesnelerini ve sütunlarını doğrulayın. CDA şemaları ve sütun adları tenant'a, sürüme, yapılandırmaya ve veri paylaşım modeline göre değişebilir. Sorgudaki köşeli parantez içindeki her nesne veya sütun yer tutucusunu ortamınızdaki karşılığıyla değiştirin. Operasyonel ClaimCenter varlık adlarının Snowflake'te değişmeden sunulduğunu varsaymayın.
- Hasar oluşturma, hasar atama geçmişi, teminat oluşturma, rezerv işlemleri, faaliyetler, teminat durumu geçmişi, ödeme durumu geçmişi ve hasar durumu geçmişi için 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 kullanıcıyı koruyan onaylı bir kaynak yapılandırın.
- Yetkili bir Snowflake istemcisi, worksheet, notebook 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 ayarlayın, onaylanmış ş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 faaliyetin tamamı için açıkça satırlar oluşturur: Claim Created, Claim Assigned, Exposure Created, Initial Reserve Set, Investigation Started, Additional Info Requested, Additional Info Received, Liability Decision Made, Settlement Calculated, Payment Approved, Payment Issued, Claim Denied, Claim Closed ve Claim Reopened.
- 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ı koruyun ve olayları hasara göre toplulaştırmayın.
- Dışa aktarmadan önce zaman damgalarını, durum geçişlerini, atama değişikliklerini, yinelenen kayıtların işlenmesini ve faaliyet sayılarını doğrulayın. Olay zaman damgalarının tutarlı bir saat diliminde olduğunu ve aynı zaman damgasına sahip ayrı iş faaliyetlerini temsil eden birden fazla olayın ayrı satırlar olarak kaldığını doğrulayın.
- 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 faaliyet ve EventTime'ı olay zaman damgası olarak eşleyin. Önerilen öznitelikleri ek olay öznitelikleri olarak koruyun ve çıkarım dışında varsayılan faaliyetler eklemeden dosyayı ProcessMind'e yükleyin.
Yapılandırma
- Bağlantı ve yetkilendirme: Yetkili bir Snowflake hesabı, rolü, warehouseı ve ağ yolu üzerinden Guidewire tarafından sağlanan Snowflake veri paylaşımını kullanın. CDA, tüketici açısından salt okunurdur. Gerekli erişim, tenant yapılandırmanıza bağlıdır ve paylaşılan veritabanını, 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ğrulanmış nesnelerle değiştirin. Sorgu, sunulan CDA yapıları sürüme ve tenanta göre değiştiği için evrensel ClaimCenter tablo veya sütun adlarını varsaymaz.
- Tarih aralığı: Doğrulama ve operasyonel analiz için üç ila altı aylık bir dönemle başlayın. Daha geniş bir aralığı yalnızca warehouse kapasitesini, olay geçmişi saklama süresini ve kabul edilebilir sorgu süresini doğruladıktan sonra kullanın. Daha sonraki etkinliklerin dışarıda kalmaması için kaynak kayıtlarını yalnızca talep oluşturma tarihine göre değil, ilgili etkinlik 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ç modelinin beklediği etiketleri tam olarak kullanmalıdır.
- Önerilen çıktı: AssignedAdjuster, ClaimType, ClaimStatus ve LossCause alanlarını ekleyin. Kullanılabiliyorsa bu değerler olay zamanı anlık görüntüsünden alınabilir. Yalnızca mevcut durum değerleri sunuluyorsa bu sınırlamayı belgeleyin, çünkü geçmiş öznitelikler olay zamanındaki değeri yansıtmayabilir.
- Filtreler: [Company filter] uygulamasını yalnızca ilgili tenanta özel şirket, kuruluş, iş birimi veya tüzel kişi sütununu doğruladıktan sonra kullanın. ClaimCenter yapılandırması, istenen etkinliklerle ilgili doğrulanmış bir belge türü alanı sunmuyorsa 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ı gibi geçişleri belirlemek için geçmiş veya denetim verileri gerekir. Yalnızca mevcut durum tabloları geçmiş olayları güvenilir biçimde yeniden oluşturamaz.
- Yinelenen kayıtların kaldırılması: Kullanılabiliyorsa doğrulanmış bir kaynak olay tanımlayıcısı kullanın. Sorgu, ROW_NUMBER işlevini yalnızca yapılandırılabilir bir güvenlik önlemi olarak kullanır. Farklı etkinlikler aynı anda gerçekleşebileceği için 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ğı etkinlik zaman damgasına göre filtreleyin ve uygun boyutta bir Snowflake warehouse kullanın. Büyük hacimler için doğrulanmış bir olay görünümünü somutlaştırmayı veya artımlı veri çıkarımı kullanmayı değerlendirin.
- Saat dilimi: EventTime değerini belgelenmiş tek bir saat diliminde standartlaştırın. Olay günlüğünü yüklemeden önce CDA zaman damgalarının UTC, yerel saat veya Snowflake zaman damgası varyantları olarak saklanıp saklanmadığını doğrulayın.
- Ön koşullar: Gerekli ClaimCenter finans, etkinlik, atama, exposure, ödeme ve durum geçmişi verilerinin paylaşıma dahil edildiğini ve saklama politikalarının gerekli geçmiş geçişlerini koruduğunu doğrulayın.
a Ö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çi Guidewire ClaimCenter operasyonel veritabanına doğrudan okuma erişiminin yetkilendirildiğini, veritabanı platformunun ve şema sürümünün belgelendiğini ve salt okunur bir bağlantının kullanılabildiğini doğrulayın. Onaylanmış bir çıkarım aralığı olmadan üretim veritabanını sorgulamayın.
- ClaimCenter uygulamanızda kullanılan fiziksel tabloları ve sütunları belirleyin. Hasar, teminat, faaliyet, atama, rezerv, ödeme, durum geçmişi ve kullanıcı veya grup varlıklarını sorgudaki yer tutucularla eşleyin. Fiziksel adlar ve denetim yapıları uygulamaya ve sürüme göre değiştiğinden, her yer tutucuyu yalnızca veritabanı kataloğunu ve ClaimCenter veri modelini doğruladıktan sonra değiştirin.
- Çıkarım dönemini [Start date parameter] ve [End date parameter] ile tanımlayın. Durum değişiklikleri, görev tamamlamaları veya finansal işlemler birincil hasar oluşturma dönemi dışında kaydedilebiliyorsa, istenen başlangıç tarihinden bir veya iki gün öncesi gibi kayan bir örtüşme kullanın.
- Eksiksiz SQL ifadesini salt okunur yetkilerle çalıştırın. Her faaliyet açık bir olay satırı olarak üretilir. Sorgu, alımdan sonra olayları çıkarsamak için ProcessMind'e dayanmaz. Alan değişikliklerinden çıkarılan olaylar, ilgili geçmiş veya denetim kayıtlarından SQL ifadesi içinde türetilir.
- Her faaliyet için kaynak eşlemelerini doğrulayın. Hasar oluşturmanın kaydedilen ilk Claim kaydını kullandığını, atamanın atama değişikliklerini kullandığını, teminat oluşturmanın teminat oluşturma kayıtlarını kullandığını, ilk rezervin her teminat için ilk rezerv işlemini kullandığını, inceleme ve bilgi taleplerinin faaliyet kayıtlarını kullandığını, sorumluluğun yapılandırılmış teminat durumu geçişini kullandığını, uzlaşmanın onay bekleyen ödeme durumunu kullandığını ve ödeme onayı ile ödemenin ilgili finansal denetim durumlarını kullandığını doğrulayın.
- Çıktıyı gerekli Event Log yapısına dönüştürün. ClaimID vaka tanımlayıcısı, ActivityName belgelenen on dört faaliyet adından tam olarak biri ve EventTime bir zaman damgası olmalıdır. Kaynak eşlemesi sağladığında 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ı bulunuyorsa ilgili ortak tablo ifadesinde uygulamaya özgü ayıklama anahtarını kullanın. Farklı zaman damgalarına veya kaynak tanımlayıcılarına sahip 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ı içeren bir başlık satırı 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 faaliyet, EventTime'ı olay zaman damgası olarak eşleyin.
Yapılandırma
- Veritabanı erişimi: Gerekli ClaimCenter operasyon tablolarını, geçmiş tablolarını, faaliyet tablolarını ve finansal işlem tablolarını sorgulama izni olan salt okunur bir hesap kullanın. Çı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 uygulamada doğrulanmış adlarla değiştirin. Mantıksal bir Guidewire varlık adının fiziksel veritabanı tablosu adı olduğunu varsaymayın.
- Tarih aralığı: Üç ila altı aylık verilerle başlayın. [Start date parameter] ve [End date parameter] değerlerini kullanın. Olaylar hasar oluşturulduktan sonra kaydedilebiliyorsa veya yeniden açılan hasarlar birden fazla raporlama dönemine yayılıyorsa örtüşme aralığı ekleyin.
- Filtreler: [Company Code filter], [Document Type filter], yargı alanı, 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 gerekli olduklarından, ödeme veya teminatı olmayan hasarları filtreleyerek çıkarmayın.
- Faaliyet adları: ProcessMind'in tutarlı olay etiketleri alması için on dört ActivityName değerini sorguda tanımlandığı biçimde aynen koruyun.
- Olay anlamı: Çıkarımsal olarak tanımlanan faaliyetler SQL içinde kaynak durum, atama, geçmiş veya faaliyet geçişlerinden oluşturulur. ProcessMind, alımdan sonra bu olayları diğer satırlardan türetmez.
- Performans: Çıkarım dönemini sınırlayın, yalnızca gerekli sütunları seçin, birleştirmelerden önce kaynak tabloları filtreleyin ve hasar tanımlayıcıları, teminat tanımlayıcıları, olay zaman damgaları, durum alanları ve işlem tanımlayıcıları üzerindeki dizinleri doğrulayın. Kullanılabiliyorsa büyük çıkarımları raporlama replikası üzerinde çalıştırın.
- Tutarlılık: Raporlama için uygun bir işlem izolasyon düzeyi kullanın ve tutarlı bir çıkarım sınırı belirleyin. Finansal bir toplu işlem veya toplu durum güncellemesi kısmen işlenirken tabloları okumaktan kaçını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 saatini ve veritabanı sunucusu saatini karıştırmayın.
- Ön koşullar: Gerekli ClaimCenter modüllerinin, finans izinlerinin, denetim veya geçmiş saklama ayarlarının ve veritabanı bağlantısının kullanılabilir olduğunu doğrulayın. Geçmiş veya denetim saklama devre dışıysa ilgili çıkarımsal faaliyetler 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, çıkarım zamanını, tarih parametrelerini, filtreleri ve satır sayılarını kaydedin.
a Ö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?
Talepleri işleme verilerinizi analize hazırlamak ve içgörüler elde etmek için bu Templatetan yararlanın. İş akışlarınızı bugün iyileştirmeye başlayın.
Hasar işlemlerini hızlandırın, dosyaları şimdi daha hızlı sonuçlandırın
Birikmiş işleri ortadan kaldırın, sahtekarlığı önleyin ve %70 oranında straight-through processing hedefleyin.
Kredi kartı gerekmez, kurulum yalnızca birkaç dakika sürer.