Veri Şablonu: Hasar Süreci
Hasar Süreçleri Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- İzlenecek anahtar faaliyetler
- Guidewire ClaimCenter için Veri Çıkarma Rehberi
Hasar Süreci Özellikleri
| Ad | Açıklama | ||
|---|---|---|---|
Faaliyet Adı ActivityName | Hasar dosyasının yaşam döngüsünde belirli bir noktada gerçekleşen iş aktivitesinin veya olayın adı. | ||
Açıklama Bu özellik, hasar sürecindeki 'Claim Created', 'Investigation Started' veya 'Payment Issued' gibi belirli adım ya da kilometre taşlarını tanımlar. Belirli bir Claim ID için bu aktivitelerin sıralaması süreç akışını oluşturur. Aktiviteler arasındaki sıralama, sıklık ve sürelerin analiz edilmesi Process Mining'in özüdür. Bu sayede süreç modelleri keşfedilir, darboğazlar belirlenir, yeniden iş döngüleri saptanır ve süreç sapmaları incelenir. Neden önemli Sürecin adımlarını tanımlar; süreç haritalarının görselleştirilmesini, akışın ve darboğazların analizini mümkün kılar. Nereden alınır Bu, genellikle ClaimCenter'daki event tablolarından veya audit log'larından türetilir; çoğu zaman belirli sistem event'leri ya da durum değişimleri standartlaştırılmış aktivite adlarına eşleştirilerek elde edilir. Örnekler Hasar OluşturulduSorumluluk Kararı VerildiÖdeme Emri VerildiHasar Kapatıldı | |||
Hasar ID ClaimID | Her hasar dosyası için benzersiz tanımlayıcı; temel vaka kimliği olarak kullanılır. | ||
Açıklama Claim ID, hasar süreci analizinin bel kemiğidir; başvurudan kapanışa kadar her dosyayı benzersiz biçimde tanımlar. İlgili tüm aktiviteleri, belgeleri, ödemeleri ve yazışmaları birbirine bağlayarak dosyanın yaşam döngüsüne eksiksiz ve tutarlı bir bakış sunar. Process mining'de veri setindeki her olay bir Claim ID ile ilişkilidir; böylece uçtan uca süreç akışı yeniden kurulabilir. Bu, çevrim sürelerini analiz etmek, süreç varyantlarını belirlemek ve dosyanın farklı departmanlar ile hasar uzmanları arasında izlediği yolu takip etmek için kritiktir. Neden önemli Tek bir hasarın tüm yolculuğunu izleyip analiz etmeyi mümkün kılan, ilişkili tüm olayları birbirine bağlayan temel anahtardır. Nereden alınır Bu, Guidewire ClaimCenter'da bir birincil anahtardır; temel Claim varlığında genellikle Claim.ClaimNumber veya benzeri bir alanda bulunur. Örnekler 000-123-45678000-987-65432001-456-11223 | |||
Olay Zamanı EventTime | Aktivitenin gerçekleştiği kesin tarih ve saat. | ||
Açıklama Bu timestamp, bir aktivitenin sisteme kaydedildiği tam anı gösterir. Zaman temelli tüm süreç analizlerinin temelidir. Tek bir Claim ID için EventTime değerlerinin kronolojik sıralanması, süreç akışının yeniden kurgulanmasına olanak tanır. Ardışık event'ler arasındaki zaman farkı, çevrim süreleri, bekleme süreleri ve işlem sürelerini hesaplamak için kullanılır. Bu metrikler, performans analizi, darboğaz tespiti ve SLA takibi için kritiktir. Neden önemli Bu timestamp, event'lerin sıralanması, çevrim ve işlem sürelerinin hesaplanması ve süreçteki gecikmelerin tespiti için kritiktir. Nereden alınır Guidewire ClaimCenter'ın geçmiş veya denetim tablolarında, etkinlik ya da aktivite verilerinin yanında, genellikle 'CreateTime' veya 'UpdateTime' alanı olarak bulunur. Örnekler 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
Assigned Adjuster AssignedAdjuster | Hasar dosyasını ya da belirli bir aktiviteyi yürütmek üzere atanan kullanıcının adı veya ID'si. | ||
Açıklama Bu özellik, belirli bir anda dosyadan sorumlu hasar uzmanını belirtir. Bir uzman, tüm dosyaya ya da içindeki belirli görevlere atanabilir. Atanan hasar uzmanı bazında analiz; iş yükü dengesi, performans yönetimi ve eğitim fırsatlarını belirlemek için kritiktir. 'Hangi uzmanların dosya yükü en yüksek?', 'Uzmanlar arasında performans farklılıkları var mı?' ve 'İş dengeli biçimde dağıtılıyor mu?' gibi sorulara yanıt verir. Neden önemli Kullanıcı katılımını izler; iş yükü analizi, performans karşılaştırması ve kaynağa bağlı darboğazların tespitini sağlar. Nereden alınır ClaimCenter’da Claim veya Exposure entity’sinde bulunur; genellikle User nesnesine bağlıdır (örn. Claim.Assignee). Örnekler j.doem.smiths.jones | |||
Hasar Durumu ClaimStatus | Olay anındaki dosyanın genel durumu (örn. Open, Closed, Denied). | ||
Açıklama Bu özellik, dosyanın üst düzey durumunu yansıtır. Temel durumlar 'Open', 'Closed', 'Denied' ve 'Reopened'dır. Dosyanın nihai durumu kritik bir sonuç metriğidir. Claim Status değişimlerini izlemek, temel süreç kilometre taşlarını ve sonuçlarını tanımlamaya yardımcı olur. Nihai çözümü belirlemek, ret oranlarını hesaplamak ve kapanıştan sonra dosyaların ne sıklıkla yeniden açıldığını analiz etmek için kullanılır; bu da çoğu kez süreç sorunlarına ya da müşteri memnuniyetsizliğine işaret eder. Neden önemli Bir hasarın sonucunu gösterir; ret oranlarını, kapanış kalıplarını ve yeniden açılma sıklıklarını analiz etmek için kritiktir. Nereden alınır Bu, Claim varlığında temel bir alandır; genellikle 'State' veya 'Status' olarak adlandırılır. Örnekler AçıkKapalıReddedildiYeniden Açıldı | |||
Hasar Nedeni LossCause | Hasar olayının belirli nedeni (örn. Çarpışma, Yangın, Su Hasarı). | ||
Açıklama Bu özellik, dosyanın neden açıldığını ayrıntılı biçimde açıklar. Kayıp nedeni, gerekli inceleme adımlarını, ihtiyaç duyulan uzmanlıkları ve dosyanın genel karmaşıklığını çoğu zaman belirler. Hasar Nedeni bazında süreci analiz etmek, gözden kaçan kalıpları ortaya çıkarabilir. Örneğin 'Su Hasarı' ile ilgili dosyalar, 'Hırsızlık' dosyalarına kıyasla daha yüksek yeniden iş oranına sahip olabilir ya da daha fazla uzmanın devreye girmesini gerektirebilir. Bu içgörüler, daha uzmanlaşmış ve verimli yönetim prosedürleri oluşturmayı sağlar. Neden önemli Hasarın niteliğine dair bağlam sağlar; farklı kayıp nedenlerinin süreç akışını ve süresini nasıl etkilediğini analiz etmeyi mümkün kılar. Nereden alınır Bu, Claim varlığında standart bir alandır; genellikle 'LossCause' olarak adlandırılır. Örnekler ÇarpışmaYangınSu HasarıHırsızlık | |||
Hasar Türü ClaimType | Hasar dosyasının kategorisi (örn. Oto, Mülk, Sorumluluk). | ||
Açıklama Hasar Türü, bir hasarın iş koluna veya zararın niteliğine göre yapılan temel sınıflandırmadır. Farklı hasar türleri genellikle farklı süreçleri izler, karmaşıklık düzeyleri değişir ve farklı düzenlemelere tabidir. Süreç analizini Hasar Türü'ne göre bölümlendirmek, anlamlı içgörüler için kritik önemdedir. Bu sayede farklı iş kollarındaki süreç performansını karşılaştırabilir, türe özgü darboğazları belirleyebilir ve her kategoriye uygun süreç iyileştirmelerini tasarlayabilirsiniz. Neden önemli Farklı türler (örn. Auto vs. Property) genellikle farklı süreçler izler ve farklı performans hedeflerine sahiptir; hasarları türe göre segmentlemenizi sağlar. Nereden alınır ClaimCenter'deki Policy veya Claim varlığından türetilir; genellikle Line of Business (LOB) koduna göre belirlenir. Örnekler Bireysel AraçTicari Emlak SigortasıGenel Sorumlulukİşçi Tazminatı | |||
Bitiş Saati EndTime | Bir aktivitenin ne zaman tamamlandığını gösteren zaman damgası. | ||
Açıklama End Time, özellikle 'Investigation' veya 'Document Review' gibi ölçülebilir süreye sahip görevlerde, aktivitenin tamamlandığı anı gösterir. Birçok process mining aktivitesi anlıktır (StartTime yeterlidir); ancak belirgin bir başlangıç ve bitişi olan aktiviteler iki zaman damgasıyla daha doğru temsil edilir. Bu alan, bekleme süresinden farklı olarak aktivitenin işleme süresinin hassas biçimde hesaplanmasını sağlar. Yalnızca adımlar arasındaki gecikmeleri görmek yerine, hangi görevlerin zaman tükettiğini belirlemeye yardımcı olur. Neden önemli Bir aktivitenin tamamlanmasının ne kadar sürdüğünü hassas biçimde ölçmeyi sağlar; işlem süresi ile bekleme süresini ayırır. Nereden alınır Bunu, aktiviteyi mantıksal olarak sonlandıran bir sonraki event'i bularak türetmek gerekebilir (örneğin, durumun 'In Progress'ten 'Completed'a değişmesi). Örnekler 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
Bölüm Department | Hasar aktivitesini yürüten sorumlu iş birimi veya departman. | ||
Açıklama Bu özellik, atanan uzmanın bağlı olduğu departman ya da ekibi (ör. 'Oto Hasar', 'Konut Hasar', 'Özel İnceleme Birimi') belirtir; sürece kurumsal bir çerçeve kazandırır. Departman bazında analiz, süreci organizasyon düzeyinde anlamak için kritiktir. Departmanlar arası devir gecikmelerini tespit etmeye, ekipler arası verimliliği karşılaştırmaya ve hasar organizasyonu genelinde kaynakları daha etkin tahsis etmeye yardımcı olur. Neden önemli Organizasyonel bağlam sağlar; farklı ekipler arası performans analizini mümkün kılar ve birimler arası devir teslim sorunlarını görünür kılar. Nereden alınır Bu bilgi genellikle ClaimCenter'da atanan kullanıcı veya grubun profiliyle ilişkilidir. Örnekler Auto Claims DivisionMülk Hasar BirimiÖzel Soruşturma Birimi (SIU) | |||
Çözüm Hedef Tarihi ResolutionTargetDate | İç politikalar veya mevzuata dayalı SLA'lara göre dosyanın sonuçlanmasının beklendiği tarih. | ||
Açıklama Resolution Target Date, dosyanın kapanması için belirlenen son tarihtir; yargı alanı, dosya türü ve poliçe koşulları gibi faktörlere göre şekillenir. Performans ve uyumu ölçmek için bir referans görevi görür. Bu alan, SLA uyum dashboard'ları ve KPI'larını oluşturmak için kritiktir. Gerçek 'Claim Closed' tarihi bu hedefle karşılaştırılarak geciken dosyalar otomatik işaretlenir, zamanında tamamlama oranları ölçülür ve hangi dosya türlerinin veya departmanların hedefleri tutturmakta zorlandığı ortaya çıkar. Neden önemli Bu, Hizmet Düzeyi Anlaşması (SLA) uyumunu ölçmek ve gecikme riski taşıyan hasar dosyalarını belirlemek için kıyas ölçütüdür. Nereden alınır Bu, ClaimCenter'da yapılandırılan iş kurallarına dayanarak türetilmiş veya özel bir alan olabilir; muhtemelen belirli hasar metrikleriyle ilişkilidir. Örnekler 2023-06-142023-07-202023-08-28 | |||
Hasar Tarihi LossDate | Hasar dosyasını tetikleyen olayın/hasarın gerçekleştiği tarih. | ||
Açıklama Date of Loss, hasara konu olayın gerçekleştiği tarihi (ör. trafik kazası, mülk hasarı) ifade eder. Bu tarih, dosyanın raporlandığı veya oluşturulduğu tarihten farklıdır. Date of Loss ile 'Claim Created' aktivitesi arasındaki süre farkı, bildirim gecikmesi (reporting lag) olarak bilinen önemli bir KPI'dır. Bunun analizi, müşteri davranışları ve ilk hasar bildirimi kanallarının etkinliği hakkında içgörüler sağlar. Neden önemli Hasarın kaynağı hakkında kritik bağlam sunar ve bildirim gecikmesini (vakadan dosya açılışına kadar geçen süre) analiz etmeye yardımcı olur. Nereden alınır Bu, Claim varlığında temel bir tarih alanıdır; çoğunlukla 'LossDate' olarak geçer. Örnekler 2023-05-102023-04-202023-05-28 | |||
İşlem Süresi ProcessingTime | Bir aktivite üzerinde aktif çalışmaya ayrılan süre. | ||
Açıklama Processing Time, bir aktivite üzerinde aktif çalışılan süreyi ölçer; End Time ile Start Time arasındaki farktır. Bu metrik, bekleme dönemlerini de içeren çevrim süresinden (cycle time) farklıdır. Bu hesaplanan metrik, performans analizi için kritiktir; bir görevin gerçek çabasını boşta/bekleme süresinden ayırır. Gerçekte hangi adımların zaman tükettiğini doğru biçimde belirlemenize ve eğitim, daha iyi araçlar veya süreç tasarımıyla nerede verim kazanılabileceğine karar vermenize yardımcı olur. Neden önemli Bir aktivitenin aktif çalışma süresini ölçer; katma değerli süre ile bekleme süresini ayırt etmeye yardımcı olur. Nereden alınır Hesaplanan alan: EndTime - StartTime. Kaynak veride her iki timestamp’in de bulunmasını gerektirir. Örnekler 8SPT15MP2D | |||
Kaynak Sistem SourceSystem | Verilerin çekildiği sistem. | ||
Açıklama Bu özellik, event verisinin kaynağını belirtir. Güncel kurumsal yapılarda hasarla ilgili event'ler; Guidewire gibi çekirdek bir sistemden, bir doküman yönetim sisteminden veya bir müşteri portalından gelebilir. Kaynak sistemin belirtilmesi; veri yönetişimi, veri tutarsızlıklarını gidermek ve sürecin teknolojik yapısını anlamak açısından kritiktir. Bu sayede çekirdek süreç adımları ile çevre sistemlerden gelen destekleyici aktiviteler ayrıştırılabilir. Neden önemli Verinin kaynağını belirler; bu, veri yönetişimi ve birden fazla entegre sistemi içeren analizler için kritiktir. Nereden alınır Bu, genellikle veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde eklenen sabit bir değerdir. Örnekler Guidewire ClaimCenter v10Müşteri Portalı API'siDocumentum | |||
Ödeme Tutarı PaymentAmount | Bir ödeme aktivitesi kapsamında fiilen ödenen tutar. | ||
Açıklama Bu özellik, bir hasar dosyası için yapılan her bir ödemenin tutarını kaydeder. Tek bir dosyanın yaşam döngüsü boyunca birden fazla ödeme olabilir. Process Mining bağlamında finansal analiz için kritiktir. Dosya 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, çevrim süresi uzun olan dosyalar daha yüksek toplam ödemelerle ilişkili olabilir. Neden önemli Bir hasar dosyasındaki finansal işlemleri izler; ödeme tutarlarının ve süreç aktiviteleriyle ilişkilerinin analizini mümkün kılar. Nereden alınır Hasarla ilişkili ödeme varlıklarında, çoğunlukla bir transaction veya check tablosunda bulunur. Örnekler 4500.00125000.00500.00 | |||
Otomatikleştirildi mi? IsAutomated | Bir activity’nin sistem tarafından otomatik mi yoksa bir kullanıcı tarafından mı yapıldığını gösteren bir gösterge. | ||
Açıklama Bu boolean özellik, sistem tarafından yürütülen aktiviteler (örn. otomatik rezerv oluşturma, sistem tarafından üretilen yazışmalar) ile bir uzman tarafından manuel yapılan aktiviteleri ayırt eder. Bu özelliği analiz etmek, hasar sürecindeki otomasyon düzeyini anlamanın anahtarıdır. Manuel müdahalenin yoğunlaştığı noktaları belirlemeye, uçtan uca otomatik işlem girişimlerinin etkinliğini ölçmeye ve halen insanlar tarafından yapılan tekrarlı, kural tabanlı görevlerde yeni otomasyon fırsatları bulmaya yardımcı olur. Neden önemli Sistem tarafından yürütülen ve insan tarafından yürütülen aktiviteleri ayırt eder; bu, otomasyon analizi ve manuel darboğazların tespiti için kritiktir. Nereden alınır Bu, çoğu zaman türetilmesi gereken bir bilgidir. Örneğin, genel bir 'system' kullanıcısı tarafından kaydedilen event'ler otomatik olarak işaretlenebilir. Örnekler truefalse | |||
Poliçe Türü PolicyType | Dosyanın bağlı olduğu sigorta poliçesi türü. | ||
Açıklama Poliçe Türü, Hasar Türü’ne kıyasla daha ayrıntılı bir sınıflandırma sunar; 'Konut', 'Ticari Araç' veya 'Siber Sorumluluk' gibi spesifik sigorta ürününü belirtir. Bu ayrıntı düzeyi, ürüne bağlı süreç farklılıklarını görünür kılabilir. Süreci Poliçe Türü bazında analiz etmek, ürüne özgü verimsizlikleri ortaya çıkarır. Örneğin, yeni çıkmış bir poliçenin hasarları daha olgunlaşmamış bir süreçten geçtiği için gecikebilir. Bu içgörüler, ürün tasarımını ve süreç standartlaştırma çalışmalarını besleyebilir. Neden önemli Belirli sigorta ürünleri için süreç analizi yapmayı sağlar; poliçe detaylarına bağlı işleyiş farklarını ortaya çıkarır. Nereden alınır Bu bilgi, Claim ile ilişkili Policy varlığında bulunur. Örnekler Konut Paket SigortasıTicari Araç Sorumluluk SigortasıNakliyat Sigortası | |||
SLA Durumu SLAState | Hasarın hedeflenen çözüm tarihine uygun şekilde kapanıp kapanmadığını gösterir. | ||
Açıklama Bu hesaplanmış özellik, kapanmış her dosya için SLA uyumunun kategorik durumunu sağlar. 'Claim Closed' aktivitesinin timestamp'i ile 'Resolution Target Date' karşılaştırılarak türetilir. Bu özellik, analizi 'Zamanında' veya 'Geç' gibi net kategorilere indirerek 'Hasar Çözüm Hedefine Uyum' dashboard'unu doğrudan destekler. Genel SLA uyum oranını hesaplamak ve gecikmelerin nedenlerine derinlemesine inmek için kolayca filtreleme ve toplulaştırma yapılmasına imkan tanır. Neden önemli SLA uyumu için net, kategorik bir sonuç sağlar; zamanında performansı filtrelemeyi, toplamayı 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üncelleme LastDataUpdate | Verinin kaynak sistemden en son ne zaman güncellendiğini ya da çekildiğini gösteren zaman damgası. | ||
Açıklama Bu özellik, kaynak sistemden yapılan en son veri çekiminin timestamp'ini içerir. Analizin güncelliğini anlamak için gerekli bir metadata alanıdır. Dashboard ve analizlerde bu bilginin görünür biçimde yer alması, kullanıcıların verinin güncelliğinin farkında olmasını sağlar. Bu sayede içgörülerin operasyonların mevcut durumunu yansıtıp yansıtmadığını değerlendirmek mümkün olur. Neden önemli Verinin ne kadar güncel olduğunu gösterir; böylece kullanıcılar süreç analizinin güncelliğini anlayabilir. Nereden alınır Bu değer, ETL sürecinde üretilir ve saklanır; veri yüklemesinin timestamp'ini temsil eder. Örnekler 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
Talep Edilen Tutar ClaimedAmount | Sigortalı tarafından başlangıçta talep edilen toplam parasal tutar. | ||
Açıklama Bu özellik, hak sahibi tarafından bildirilen kayıp tutarını ifade eder. İnceleme ilerledikçe ve rezervler (karşılıklar) ayrıldıkça bu ilk tahmin değişebilir. Claimed Amount'u analiz etmek, dosyaları finansal etkiye göre segmentlere ayırmaya yardımcı olur. Yüksek tutarlı dosyalar genellikle düşük tutarlılara kıyasla daha sıkı ve daha karmaşık bir süreç izler. Farklı tutar bantlarındaki süreçleri karşılaştırmak, küçük dosyalar için süreci sadeleştirme ya da büyük dosyalar için daha sıkı kontroller uygulama fırsatlarını ortaya çıkarabilir. Neden önemli Hasarları finansal tutarlarına göre segmentlemenizi sağlar; yüksek tutarlı hasarlar daha farklı ve karmaşık süreçleri izleyebilir. Nereden alınır Bu bilgi tek bir alan olmayabilir; Exposure kayıtlarına girilen ilk hasar tahminlerinden türetilebilir. Örnekler 5000.00150000.00750.50 | |||
Tekrarlanan Bilgi Talebi RepeatedInfoRequestFlag | Aynı claim için 'Additional Info Requested' aktivitesinin birden fazla kez gerçekleşip gerçekleşmediğini gösteren bir gösterge. | ||
Açıklama Bu boolean bayrak, bir dosyada birden fazla 'Additional Info Requested' aktivitesi varsa true olarak işaretlenir. Bu durum çoğu kez ilk bilgi toplama aşamasındaki verimsizliklere işaret eder. Bu özellik, 'Repeated Info Request Rate' KPI'sını doğrudan destekler. Eksik ön inceleme sorununu nicel olarak ortaya koyar; bu durum ciddi gecikmelere ve müşteri memnuniyetsizliğine yol açabilir. Bu bayrağa sahip dosyaları analiz etmek, tüm gerekli bilgilerin tek seferde istenmesini sağlamak için uzmanların kontrol listelerini ve prosedürlerini iyileştirmeye yardımcı olur. Neden önemli Bilgi toplamanın ilk seferde eksiksiz yapılmadığı durumları tespit eder; bu da süreçte gecikmelere ve yeniden işlemeye yol açar. Nereden alınır Her dosya için 'Additional Info Requested' aktivitesinin sayısı temel alınarak process mining aracında hesaplanır. Örnekler truefalse | |||
Yargı Bölgesi (Eyalet) JurisdictionState | Dosyanın tabi olduğu eyalet/yargı alanı; ilgili düzenleyici gereklilikleri belirler. | ||
Açıklama Bu özellik, dosyanın işlem gördüğü hukuki yetki alanını (örn. ABD eyaleti) belirtir. Sigorta mevzuatı, yetki alanına göre ciddi farklılık gösterebilir; bu da gerekli süreç adımlarını, iletişim sürelerini ve dokümantasyonu etkiler. Uyum takibi için hayati bir özelliktir. Süreci yetki alanına göre analiz etmek, eyalete özgü düzenleyici gerekliliklerin karşılandığından emin olmayı sağlar. Ayrıca çevrim süreleri veya süreç yollarındaki farklılıkların, operasyonel verimsizlikten ziyade hukuki kısıtlamalardan kaynaklandığını açıklayabilir. Neden önemli Uyum analizi için kritiktir; çünkü farklı yargı bölgelerinde hasar sürecini etkileyen farklı düzenlemeler bulunur. Nereden alınır Claim entity’sinde bulunan standart bir alan; genellikle 'JurisdictionState' olarak adlandırılır. Örnekler CANYTXFL | |||
Yeniden İşleme mi? IsRework | Bir activity’nin rework (yeniden çalışma) döngüsü olup olmadığını, yani sürecin önceki bir aşamasına dönüşü gösteren bir gösterge. | ||
Açıklama Bu hesaplanmış özellik, yeniden iş döngüsünün parçası olan aktiviteleri işaretler. Örneğin süreç 'Investigation Completed'dan 'Investigation Started'a geri dönüyorsa, ikinci 'Investigation Started' aktivitesi yeniden iş olarak işaretlenir. Yeniden işi belirlemek, süreç verimsizliklerini ve kalite sorunlarını açığa çıkarmanın temelidir. 'Rework and Rejection Frequency' dashboard'u, dosyaların ideal akıştan ('happy path') ne sıklıkla saptığını nicel olarak ölçmek için bu metrikten yararlanır. Yeniden işin nedenlerini analiz etmek, süreç kalitesi ve hızında ciddi iyileşmelere yol açabilir. Neden önemli Yeniden işlem döngüsünün parçası olan aktiviteleri açıkça işaretleyerek süreçteki verimsizlik ve kalite sorunlarını görünür kılar. Nereden alınır Bu, her case için aktivitelerin sıralaması analiz edilerek Process Mining aracında hesaplanır. Örnekler truefalse | |||
Hasar Süreci Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
Hasar Kalemi Oluşturuldu | Bu aktivite, bir hasar altında belirli bir potansiyel sorumluluğu ya da kayıp türünü (örn. araç hasarı, yaralanma) temsil eden bir hasar kaleminin (exposure) oluşturulduğunu gösterir. Guidewire'da açıkça kaydedilen bir olaydır. | ||
Neden önemli Hasar kalemleri, hasar segmentasyonu ve analizin temelidir. Oluşturulmalarını izlemek; hasarın karmaşıklığı ve hasar türüne göre süreç farklılıklarını anlamaya yardımcı olur. Nereden alınır cc_exposure tablosunda oluşturulan yeni bir kaydın CreateTime alanından alınır. Her kayıt tek bir Claim ID ile ilişkilidir. Yakala Exposure entity tablosunda yeni bir kaydın oluşturulma timestamp’ini belirleyin. Event tipi explicit | |||
Hasar Kapatıldı | Tüm aktiviteler ve ödemeler tamamlandıktan sonra hasar dosyasının başarıyla kapatıldığını işaretler. Bu, dosyanın ana statüsündeki değişimden türetilen birincil başarılı bitiş olayıdır. | ||
Neden önemli Birincil bitiş event’i olduğundan, uçtan uca çevrim süresinin hesaplanması ve SLA uyumunun ölçülmesi için kritiktir. Hasar yaşam döngüsünün tamamlandığını ifade eder. Nereden alınır cc_claim tablosundaki State alanının 'Closed' olarak değişmesinden çıkarım yapılır. Olayın timestamp’i, hasar kaydındaki CloseDate’dir. Yakala Hasarın ana durum alanının 'Closed' olarak güncellendiği zamanı tespit edin. Event tipi inferred | |||
Hasar Oluşturuldu | Bu aktivite, İlk Hasar Bildiriminin (FNOL) alındığını ve Guidewire ClaimCenter'da yeni bir hasar dosyasının resmi olarak oluşturulduğunu gösterir. Yeni bir Claim kaydı veritabanına ilk kez yazıldığında bu durum açık bir olay olarak kaydedilir. | ||
Neden önemli Birincil başlangıç event’i olduğundan, hasarın uçtan uca çevrim süresini ölçmek için gereklidir. Tüm performans ve süre KPI’ları için bir başlangıç referansı sağlar. Nereden alınır Bu, cc_claim tablosunun CreateTime alanından yakalanan açık bir event'tir. Benzersiz bir Claim ID ile yeni bir kaydın oluşturulması event tetikleyicisidir. Yakala Temel Claim entity tablosundaki yeni kaydın oluşturulma timestamp’ini belirleyin. Event tipi explicit | |||
Hasar Reddedildi | Bir hasar dosyasının reddine ilişkin nihai kararı ifade eder ve sürecin son noktasını temsil eder. Bu olay, dosyanın durumunun gerekçe 'Denied' olacak şekilde 'Closed' olmasına bakılarak anlaşılır. | ||
Neden önemli Bu, kritik bir sonuç event'idir. Reddin sıklığını, nedenlerini ve reddiyle sonuçlanan süreç yollarını analiz etmek; hasar bildirimi, soruşturma veya poliçe yorumlamasındaki sorunları belirlemeye yardımcı olur. Nereden alınır cc_claim tablosundaki State alanının 'Closed' değerine değişmesi ve CloseReason alanının 'Denied' veya benzeri bir değer olmasıyla çıkarım yapılır. Olayın timestamp’i CloseDate’dir. Yakala Gerekçe kodunun ret belirttiği ve hasar durumunun 'Closed' olarak değiştiği kayıtları filtreleyin. Event tipi inferred | |||
İlk Karşılık Ayrıldı | Bir hasar kalemi (Exposure) için ilk finansal karşılık işleminin oluşturulduğunu işaretler ve hasarın muhtemel maliyetini tahmin eder. Bu, kritik bir finansal olaydır ve açık biçimde kaydedilir. | ||
Neden önemli Bu kilometre taşı, finansal analiz ve potansiyel yükümlülüğün ne kadar hızlı değerlendirildiğini anlamak için kritiktir. Gecikmeler finansal planlama ve raporlamayı etkileyebilir. Nereden alınır Bu event, dosyadaki bir hasar kalemiyle ilişkili ilk cc_reserveline kaydının oluşturulmasından yakalanır. İşlemin CreateTime değeri event timestamp'idir. Yakala Belirli bir hasarın tüm hasar kalemlerindeki muallak satırlarının en düşük oluşturulma zaman damgasını bulun. Event tipi explicit | |||
Ödeme Emri Verildi | Bu aktivite, ödeme sürecinin son adımını gösterir; ödeme resmi olarak oluşturulur ve finansal sisteme gönderilir. Bu, sistemde açıkça kaydı bulunan bir finansal işlemdir. | ||
Neden önemli Bu aktivite, ödeme çıkışı sürecinin verimliliğini ölçmek için kritiktir. Onay gecikmeleri ile ödemenin fiilen yapılmasındaki gecikmeleri ayırt etmeye yardımcı olur. Nereden alınır cc_check veya cc_transaction kaydındaki IssueDate alanından ya da durumun 'Issued' veya 'Submitted' olarak değişmesinden alınır. Bu genellikle açıkça zaman damgalı bir olaydır. Yakala Ödeme kaydında IssueDate alanını ya da durumunun 'Issued' olarak değiştiği anın timestamp’ini belirleyin. Event tipi explicit | |||
Ödeme Onaylandı | Tazminat ödemesinin resmi onayını ifade eder. Bu, kritik bir denetim olayıdır ve yetkili bir kullanıcı işlemi onayladığında açıkça kaydedilir. | ||
Neden önemli Bu kritik kilometre taşı, nihai ödeme adımının önünü açar. Bu aktiviteden önceki ve sonraki süreyi analiz etmek, onay workflow'larından veya yöneticilerin uygunluğundan kaynaklanan gecikmeleri ayırt etmeye yardımcı olur. Nereden alınır Bu, çoğunlukla cc_check veya cc_transaction varlığıyla ilişkili olarak cc_history tablosuna yazılan açık bir event'tir; durumun 'Pending Approval'dan 'Approved'a değişmesini kaydeder. Yakala Belirli bir ödeme işlemi için durumun 'Approved'a değiştiği event'i izleyin. Event tipi explicit | |||
Additional Info Received | Ek bilgi talebinin tamamlandığını işaretler. Bu, ilgili bilgi talebi 'Activity' (görev) kaydı 'Completed' olarak işaretlendiğinde kaydedilir. | ||
Neden önemli Bu, 'Additional Info Gathering Cycle Time' KPI'nin bitiş noktasıdır. Talep ile bilgi alımı arasında geçen uzun süreler, hasar sürecindeki gecikmelerin yaygın bir nedenidir. Nereden alınır ActivityPattern değeri bilgi talebini ifade eden cc_activity kaydındaki CloseTime alanından alınır. Aktivitenin durumu 'Completed' olmalıdır. Yakala Dış bilgi talebi için açılan bir görevin tamamlanma timestamp’ini belirleyin. Event tipi explicit | |||
Additional Info Requested | Talep sahibinden veya üçüncü bir taraftan ek bilgi ya da belge istemeyi ifade eder. Bu genellikle ClaimCenter'da oluşturulan ayrı bir 'Activity' (task) olarak kayda alınır. | ||
Neden önemli Bu aktivite, 'Additional Info Gathering Cycle Time' KPI'sinin ölçümünde başlangıç noktasıdır. Sık gerçekleşmesi, FNOL (İlk Hasar Bildirimi) sürecinin eksik kaldığına veya bilgi toplamanın verimsiz ilerlediğine işaret edebilir. Nereden alınır ActivityPattern dış taraflardan doküman/bilgi talebiyle ilişkili olan cc_activity kaydının CreateTime alanından alınır. Yakala Dış bilgi talebi için bir görevin oluşturulduğunu tespit edin. Event tipi explicit | |||
Hasar Atandı | Bir hasar dosyasının işlenmesi için belirli bir kullanıcıya (hasar uzmanı) veya gruba atanmasını ifade eder. Bu olay genellikle Claim nesnesindeki atama alanlarındaki değişiklikler izlenerek anlaşılır. | ||
Neden önemli Atamaların izlenmesi; hasar uzmanlarının iş yükünü analiz etmek, yönlendirme darboğazlarını belirlemek ve atanan kişinin ilk aksiyona kadar geçen süresini ölçmek için kritiktir. Nereden alınır Bu olay, cc_history tablosunda belirli bir Claim ID ile ilişkili AssignedUser veya AssignedGroup alanlarındaki değişikliklerin izlenmesiyle çıkarılır. Değişikliğin timestamp’i olayın gerçekleştiği anı gösterir. Yakala Hasar atama alanlarındaki güncellemeler için denetim kayıtlarını veya geçmiş tablolarını izleyin. Event tipi inferred | |||
Hasar Yeniden Açıldı | Ek çalışma yapmak üzere bir hasar dosyasının 'Closed' durumundan tekrar 'Open' durumuna alındığını ifade eder. Bu olay, belirli bir durum değişikliği dizisinden türetilir. | ||
Neden önemli Bu aktivite, yeniden iş yapıldığını gösterir. Yeniden açılan hasar dosyalarının yüksek olması, ilk ödeme kararında sorunlar, atlanan hasarlar veya diğer süreç hatalarına işaret eder; maliyetleri artırır ve verimsizliğe yol açar. Nereden alınır Bu olay, cc_history tablosunda cc_claim entity’sinin State alanının 'Closed'dan yeniden 'Open' veya başka bir aktif duruma değiştiğinin tespit edilmesiyle çıkarılır. Yakala Dosyanın ana durum alanında kapalı durumdan açık duruma geçişi izleyin. Event tipi inferred | |||
İnceleme Başladı | Bir hasar veya exposure için inceleme aşamasının resmen başladığını gösterir. Bu genellikle Guidewire’da incelemeyle ilgili ilk 'Activity' (task) kaydının oluşturulmasından anlaşılır. | ||
Neden önemli Bu aktivite, çoğu zaman uzun süren kritik bir aşamanın başlangıcıdır. İncelemenin ne kadar sürede başlatıldığını ve incelemenin süresini analiz etmek, başlıca darboğazları ortaya çıkarır. Nereden alınır ActivityPattern değeri incelemeyle ilişkili olan (ör. 'Initial Investigation', 'Contact Witness') bir cc_activity kaydının CreateTime alanından çıkarım yapılır. Yakala İncelemeyle ilgili bir pattern ya da konuya sahip bir görevin ilk kez oluşturulduğunu tespit edin. Event tipi inferred | |||
Sorumluluk Kararı Verildi | Bir Exposure için sorumluluk veya kusur kararının verildiği anı ifade eder. Bu olay genellikle Exposure nesnesindeki durum değişiminden anlaşılır. | ||
Neden önemli Bu, sonuçlandırma ve ödeme aşamalarının önünü açan kritik bir karar eşiğidir. Bu karara kadar geçen süreyi analiz etmek, soruşturma ve değerlendirme aşamalarındaki darboğazları ortaya çıkarır. Nereden alınır Bu olay, cc_history tablosunda cc_exposure entity’sindeki State ya da özelleştirilmiş sorumluluk durum alanındaki değişim izlenerek çıkarılır. Geçmiş kaydının timestamp’i olay zamanını gösterir. Yakala Hasar kaleminin durumuna veya sorumluluk statüsüne yönelik güncellemeler için denetim kayıtlarını ya da geçmiş tablolarını izleyin. Event tipi inferred | |||
Tazminat Hesaplandı | Bu aktivite, tazminat tutarının belirlendiğini ancak ödemenin henüz onaylanmadığını gösterir. 'Pending Approval' durumunda bir ödeme kaydı oluşturulmasından anlaşılabilir. | ||
Neden önemli Değerlendirmeden ödemeye geçişi işaretler. Onay zincirindeki gecikmeleri ortaya çıkaran 'Payment Authorization Lead Time' KPI’ının ölçüm başlangıç noktasıdır. Nereden alınır İlk durumu 'Pending Approval' ya da 'Approved' öncesi benzer bir durumda olan cc_check veya cc_transaction kaydının CreateTime değerinden çıkarım yapılır. Yakala Ön onay durumunda bir ödeme veya işlem kaydının oluşturulmasını tespit edin. Event tipi inferred | |||
Çıkarma Rehberleri
Adımlar
- Önkoşulların Doğrulanması: Guidewire DataHub / InfoCenter data mart veritabanına okuma yetkisiyle erişmek için gerekli izin ve kimlik bilgilerine sahip olduğunuzu doğrulayın. Hasar data mart’ını besleyen ETL job’larının sorunsuz çalıştığını ve verinin güncel olduğunu kontrol edin.
- Veritabanı Bağlantısı: DBeaver, SQL Server Management Studio gibi standart bir SQL client kullanarak data mart veritabanı sunucusuna bağlanın.
- Şemayı İnceleme: Tam sorguyu çalıştırmadan önce data mart şemasını tanıyın. Claim, exposure, activity ve finansal işlemler için ana tabloları belirleyin. Önemli tablolar genellikle _dim (dimension) ve _fact (fact) sonekleriyle adlandırılır. Bu adım, verilen script’teki yer tutucu tablo ve kolon adlarını doğrulamanıza yardımcı olur.
- SQL Sorgusunu Hazırlama: query bölümünde verilen tam SQL script’ini SQL client’ınızın sorgu editörüne kopyalayın.
- Yer Tutucuları Özelleştirme: Script’i dikkatle gözden geçirip tüm yer tutucu değerleri değiştirin. Buna veritabanı/şema adı (örn. [YourDataMart]), tarih aralığı parametreleri ('[StartDate]', '[EndDate]') ve sisteminize özgü yapılandırma değerleri (örn. activity pattern’ları, durum kodları) dahildir.
- Sorguyu Çalıştırma: Düzenlenmiş SQL sorgusunu data mart üzerinde çalıştırın. Çalışma süresi, seçtiğiniz tarih aralığına ve sisteminizdeki veri hacmine göre değişebilir.
- İlk Veri Kontrolü: Sorgu tamamlandığında, sonuç kümesinin ilk birkaç yüz satırını inceleyin. ClaimID, ActivityName ve EventTime kolonlarının beklendiği gibi dolduğunu ve farklı activity türlerinin yer aldığını teyit edin.
- CSV’ye Aktarma: SQL client’tan tüm sonuç kümesini bir CSV dosyasına aktarın. Dosyayı açıklayıcı bir adla kaydedin; örneğin guidewire_claimcenter_event_log.csv.
- ProcessMind için Biçimlendirme: CSV dosyasının UTF-8 kodlamasıyla kaydedildiğinden emin olun. Dosyada, SQL sorgusundaki kolon alias’larıyla eşleşen bir başlık satırı bulunduğunu doğrulayın. Dosya artık ProcessMind’a yüklenmeye hazır.
Konfigürasyon
- Veri Kaynağı: Guidewire DataHub/InfoCenter Claims Data Mart. Bu, canlı ClaimCenter üretim veritabanından ayrı, raporlama ve analitik için tasarlanmış, önceden özetlenmiş boyutsal bir veritabanıdır.
- Gerekli Yetkiler: Data mart'ı barındıran SQL veritabanına yalnızca okuma erişimi. Bir kullanıcı adı, parola ve bağlantı bilgilerine (sunucu adresi, veritabanı adı) ihtiyacınız olacak.
- ETL İş Durumu: Bu veri çekiminin doğruluğu, data mart'ı besleyen Guidewire ETL işlerinin zamanında ve başarıyla çalışmasına bağlıdır. Verinin güncelliğini görmek için son başarılı çalıştırma zamanını kontrol edin.
- Tarih Aralığı Filtreleme: 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 (örn. 3–6 ay) başlamanız önerilir. Tarih filtresi, claim'in 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 kurumunuzun yapılandırmasıyla eşleşecek şekilde uyarlamalısınız. Buna şunlar dahildir:
- ActivityPattern adları (örn. 'fnol', 'investigation', 'Request additional information')
- ClaimStatus, ExposureStatus ve CloseReason kodları (örn. 'denied', 'closed')
- TransactionStatus kodları (örn. 'pendingapproval', 'approved', 'issued')
- Performans: Büyük history veya audit tablolarını sorgulamak yüksek kaynak tüketebilir. Ç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 indeksli olduğundan emin olun.
a Örnek Sorgu sql
`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
- Önkoşulların Doğrulanması: Guidewire DataHub / InfoCenter data mart veritabanına okuma yetkisiyle erişmek için gerekli izin ve kimlik bilgilerine sahip olduğunuzu doğrulayın. Hasar data mart’ını besleyen ETL job’larının sorunsuz çalıştığını ve verinin güncel olduğunu kontrol edin.
- Veritabanı Bağlantısı: DBeaver, SQL Server Management Studio gibi standart bir SQL client kullanarak data mart veritabanı sunucusuna bağlanın.
- Şemayı İnceleme: Tam sorguyu çalıştırmadan önce data mart şemasını tanıyın. Claim, exposure, activity ve finansal işlemler için ana tabloları belirleyin. Önemli tablolar genellikle _dim (dimension) ve _fact (fact) sonekleriyle adlandırılır. Bu adım, verilen script’teki yer tutucu tablo ve kolon adlarını doğrulamanıza yardımcı olur.
- SQL Sorgusunu Hazırlama: query bölümünde verilen tam SQL script’ini SQL client’ınızın sorgu editörüne kopyalayın.
- Yer Tutucuları Özelleştirme: Script’i dikkatle gözden geçirip tüm yer tutucu değerleri değiştirin. Buna veritabanı/şema adı (örn. [YourDataMart]), tarih aralığı parametreleri ('[StartDate]', '[EndDate]') ve sisteminize özgü yapılandırma değerleri (örn. activity pattern’ları, durum kodları) dahildir.
- Sorguyu Çalıştırma: Düzenlenmiş SQL sorgusunu data mart üzerinde çalıştırın. Çalışma süresi, seçtiğiniz tarih aralığına ve sisteminizdeki veri hacmine göre değişebilir.
- İlk Veri Kontrolü: Sorgu tamamlandığında, sonuç kümesinin ilk birkaç yüz satırını inceleyin. ClaimID, ActivityName ve EventTime kolonlarının beklendiği gibi dolduğunu ve farklı activity türlerinin yer aldığını teyit edin.
- CSV’ye Aktarma: SQL client’tan tüm sonuç kümesini bir CSV dosyasına aktarın. Dosyayı açıklayıcı bir adla kaydedin; örneğin guidewire_claimcenter_event_log.csv.
- ProcessMind için Biçimlendirme: CSV dosyasının UTF-8 kodlamasıyla kaydedildiğinden emin olun. Dosyada, SQL sorgusundaki kolon alias’larıyla eşleşen bir başlık satırı bulunduğunu doğrulayın. Dosya artık ProcessMind’a yüklenmeye hazır.
Konfigürasyon
- Veri Kaynağı: Guidewire DataHub/InfoCenter Claims Data Mart. Bu, canlı ClaimCenter üretim veritabanından ayrı, raporlama ve analitik için tasarlanmış, önceden özetlenmiş boyutsal bir veritabanıdır.
- Gerekli Yetkiler: Data mart'ı barındıran SQL veritabanına yalnızca okuma erişimi. Bir kullanıcı adı, parola ve bağlantı bilgilerine (sunucu adresi, veritabanı adı) ihtiyacınız olacak.
- ETL İş Durumu: Bu veri çekiminin doğruluğu, data mart'ı besleyen Guidewire ETL işlerinin zamanında ve başarıyla çalışmasına bağlıdır. Verinin güncelliğini görmek için son başarılı çalıştırma zamanını kontrol edin.
- Tarih Aralığı Filtreleme: 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 (örn. 3–6 ay) başlamanız önerilir. Tarih filtresi, claim'in 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 kurumunuzun yapılandırmasıyla eşleşecek şekilde uyarlamalısınız. Buna şunlar dahildir:
- ActivityPattern adları (örn. 'fnol', 'investigation', 'Request additional information')
- ClaimStatus, ExposureStatus ve CloseReason kodları (örn. 'denied', 'closed')
- TransactionStatus kodları (örn. 'pendingapproval', 'approved', 'issued')
- Performans: Büyük history veya audit tablolarını sorgulamak yüksek kaynak tüketebilir. Ç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 indeksli olduğundan emin olun.
a Örnek Sorgu sql
`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
- Önkoşulların Doğrulanması: Guidewire DataHub / InfoCenter data mart veritabanına okuma yetkisiyle erişmek için gerekli izin ve kimlik bilgilerine sahip olduğunuzu doğrulayın. Hasar data mart’ını besleyen ETL job’larının sorunsuz çalıştığını ve verinin güncel olduğunu kontrol edin.
- Veritabanı Bağlantısı: DBeaver, SQL Server Management Studio gibi standart bir SQL client kullanarak data mart veritabanı sunucusuna bağlanın.
- Şemayı İnceleme: Tam sorguyu çalıştırmadan önce data mart şemasını tanıyın. Claim, exposure, activity ve finansal işlemler için ana tabloları belirleyin. Önemli tablolar genellikle _dim (dimension) ve _fact (fact) sonekleriyle adlandırılır. Bu adım, verilen script’teki yer tutucu tablo ve kolon adlarını doğrulamanıza yardımcı olur.
- SQL Sorgusunu Hazırlama: query bölümünde verilen tam SQL script’ini SQL client’ınızın sorgu editörüne kopyalayın.
- Yer Tutucuları Özelleştirme: Script’i dikkatle gözden geçirip tüm yer tutucu değerleri değiştirin. Buna veritabanı/şema adı (örn. [YourDataMart]), tarih aralığı parametreleri ('[StartDate]', '[EndDate]') ve sisteminize özgü yapılandırma değerleri (örn. activity pattern’ları, durum kodları) dahildir.
- Sorguyu Çalıştırma: Düzenlenmiş SQL sorgusunu data mart üzerinde çalıştırın. Çalışma süresi, seçtiğiniz tarih aralığına ve sisteminizdeki veri hacmine göre değişebilir.
- İlk Veri Kontrolü: Sorgu tamamlandığında, sonuç kümesinin ilk birkaç yüz satırını inceleyin. ClaimID, ActivityName ve EventTime kolonlarının beklendiği gibi dolduğunu ve farklı activity türlerinin yer aldığını teyit edin.
- CSV’ye Aktarma: SQL client’tan tüm sonuç kümesini bir CSV dosyasına aktarın. Dosyayı açıklayıcı bir adla kaydedin; örneğin guidewire_claimcenter_event_log.csv.
- ProcessMind için Biçimlendirme: CSV dosyasının UTF-8 kodlamasıyla kaydedildiğinden emin olun. Dosyada, SQL sorgusundaki kolon alias’larıyla eşleşen bir başlık satırı bulunduğunu doğrulayın. Dosya artık ProcessMind’a yüklenmeye hazır.
Konfigürasyon
- Veri Kaynağı: Guidewire DataHub/InfoCenter Claims Data Mart. Bu, canlı ClaimCenter üretim veritabanından ayrı, raporlama ve analitik için tasarlanmış, önceden özetlenmiş boyutsal bir veritabanıdır.
- Gerekli Yetkiler: Data mart'ı barındıran SQL veritabanına yalnızca okuma erişimi. Bir kullanıcı adı, parola ve bağlantı bilgilerine (sunucu adresi, veritabanı adı) ihtiyacınız olacak.
- ETL İş Durumu: Bu veri çekiminin doğruluğu, data mart'ı besleyen Guidewire ETL işlerinin zamanında ve başarıyla çalışmasına bağlıdır. Verinin güncelliğini görmek için son başarılı çalıştırma zamanını kontrol edin.
- Tarih Aralığı Filtreleme: 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 (örn. 3–6 ay) başlamanız önerilir. Tarih filtresi, claim'in 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 kurumunuzun yapılandırmasıyla eşleşecek şekilde uyarlamalısınız. Buna şunlar dahildir:
- ActivityPattern adları (örn. 'fnol', 'investigation', 'Request additional information')
- ClaimStatus, ExposureStatus ve CloseReason kodları (örn. 'denied', 'closed')
- TransactionStatus kodları (örn. 'pendingapproval', 'approved', 'issued')
- Performans: Büyük history veya audit tablolarını sorgulamak yüksek kaynak tüketebilir. Ç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 indeksli olduğundan emin olun.
a Örnek Sorgu sql
`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';
`