Hasar Süreçleri Data Şablonunuz
Hasar Süreçleri Data Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Guidewire ClaimCenter için Veri Çekme Rehberliği
Hasar İşleme Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
Claim ID ClaimID | Her bir sigorta hasarı için birincil case tanımlayıcısı olarak hizmet eden benzersiz ID. | ||
Açıklama Hasar ID, hasar süreci analizinin temel taşıdır ve her case'i başvurusundan kapanışına kadar benzersiz bir şekilde tanımlar. İlişkili tüm aktiviteleri, belgeleri, ödemeleri ve iletişimleri birbirine bağlayarak bir hasarın yaşam döngüsüne eksiksiz ve tutarlı bir bakış açısı sunar. Process Mining'de, data setindeki her event bir Hasar ID'sine bağlıdır. Bu sayede uçtan uca süreç akışı yeniden yapılandırılabilir. Bu, döngü sürelerini analiz etmek, süreç varyantlarını belirlemek ve bir hasarın farklı departmanlar ve eksperler arasındaki yolculuğunu takip etmek için kritik öneme sahiptir. Neden önemli Tüm ilgili event'leri birbirine bağlayan temel anahtar olup, tek bir hasarın tüm yolculuğunu takip etmeyi ve analiz etmeyi mümkün kılar. Nereden alınır Bu, Guidewire ClaimCenter'da birincil bir anahtardır ve genellikle çekirdek Hasar varlığındaki Claim.ClaimNumber veya benzeri bir alan olarak bulunur. Örnekler 000-123-45678000-987-65432001-456-11223 | |||
Faaliyet Adı ActivityName | Hasar yaşam döngüsünde belirli bir noktada meydana gelen iş aktivitesinin veya event'in adı. | ||
Açıklama Bu özellik, 'Dosya Oluşturuldu', 'Soruşturma Başladı' veya 'Ödeme Yapıldı' gibi dosya sürecindeki belirli bir adımı veya dönüm noktasını tanımlar. Belirli bir Claim ID'si için bu aktivitelerin sırası, süreç akışını (process flow) oluşturur. Aktiviteler arasındaki sırayı, sıklığı ve süreyi analiz etmek, Process Mining'in temelini oluşturur. Bu analiz, süreç modellerinin keşfedilmesine, darboğazların belirlenmesine, yeniden işleme döngülerinin (rework loops) tespit edilmesine ve süreç sapmalarının analiz edilmesine olanak tanır. Neden önemli Süreç adımlarını tanımlayarak süreç haritalarının görselleştirilmesini, süreç akışının ve darboğazların analizini sağlar. Nereden alınır Bu, genellikle ClaimCenter'daki event tablolarından veya audit log'larından türetilir; genellikle belirli sistem eventlerini veya durum değişikliklerini standartlaştırılmış activity isimleriyle eşleştirerek elde edilir. Örnekler Hasar OluşturulduSorumluluk Kararı VerildiÖdeme YapıldıHasar Kapatıldı | |||
Olay Zamanı EventTime | Aktivitenin meydana geldiği kesin tarih ve saat. | ||
Açıklama Bu timestamp, bir activitynin sisteme kaydedildiği tam anı işaretler. Tüm zaman tabanlı process analizi için temeldir. Tek bir Hasar ID'si için EventTime'ın kronolojik sıralaması, process flow'un yeniden oluşturulmasına olanak tanır. Art arda gelen eventler arasındaki zaman farkı, performans analizi, darboğaz tespiti ve SLA izlemesi için kritik olan cycle timeları, bekleme sürelerini ve processing timeları hesaplamak için kullanılır. Neden önemli Bu timestamp, eventleri sıralamak, cycle time ve süreleri hesaplamak ve süreçteki gecikmeleri belirlemek için esastır. Nereden alınır Guidewire ClaimCenter'ın geçmiş veya denetim tablolarındaki olay veya faaliyet verilerinin yanında bulunur, genellikle 'CreateTime' veya 'UpdateTime' alanı olarak. Örnekler 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
Atanan Eksper AssignedAdjuster | Hasarı veya belirli bir aktiviteyi yönetmekle görevlendirilen kullanıcının adı veya ID'si. | ||
Açıklama Bu özellik, belirli bir zamanda bir dosyanın sorumluluğunu üstlenen hasar görevlisini tanımlar. Bir hasar görevlisi, dosyanın tamamına veya içindeki belirli görevlere atanabilir. Atanmış Hasar Görevlisine göre analiz yapmak, iş yükü dengeleme, performans yönetimi ve eğitim fırsatlarını belirlemek için kritik öneme sahiptir. Bu, 'Hangi hasar görevlilerinin iş yükü en fazla?', 'Hasar görevlileri arasında performans farklılıkları var mı?' ve 'İş adil bir şekilde dağıtılıyor mu?' gibi soruların yanıtlanmasına yardımcı olur. Neden önemli Kullanıcı katılımını takip ederek iş yükü analizi, performans karşılaştırması ve kaynakla ilgili darboğazların tespit edilmesini sağlar. Nereden alınır ClaimCenter'daki Talep (Claim) veya Teminat (Exposure) varlığında bulunur, genellikle Kullanıcı nesnesine (örneğin, Claim.Assignee) bağlıdır. Örnekler j.doem.smiths.jones | |||
Hasar Durumu ClaimStatus | Event anındaki hasarın genel durumu (örn: Açık, Kapalı, Reddedildi). | ||
Açıklama Bu özellik, dosyanın üst düzey durumunu yansıtır. Başlıca durumlar arasında 'Açık', 'Kapalı', 'Reddedildi' ve 'Yeniden Açıldı' bulunur. Bir dosyanın nihai durumu, kritik bir sonuç metridir. Dosya Durumu'ndaki değişiklikleri izlemek, temel süreç dönüm noktalarını ve sonuçlarını tanımlamaya yardımcı olur. Bu, bir dosyanın nihai çözümünü belirlemek, reddetme oranlarını hesaplamak ve kapanış sonrası dosyaların yeniden açılma sıklığını analiz etmek için kullanılır; bu durum genellikle süreç sorunlarına veya müşteri memnuniyetsizliğine işaret eder. Neden önemli Reddetme oranları, kapanış modelleri ve hasar yeniden açılma sıklıklarını analiz etmek için kritik olan bir hasarın sonucunu belirtir. Nereden alınır Bu, Hasar varlığı üzerinde yer alan, genellikle 'Durum' veya 'Statü' olarak adlandırılan temel bir alandır. Örnekler AçıkKapalıReddedildiYeniden Açıldı | |||
Hasar Nedeni LossCause | Hasar event'inin belirli nedeni veya sebebi (örn: Çarpışma, Yangın, Su Hasarı). | ||
Açıklama Bu özellik, dosyanın neden açıldığına dair detaylı bağlam sağlar. Hasarın nedeni (Cause of Loss), genellikle gerekli soruşturma adımlarını, ihtiyaç duyulan uzman türlerini ve dosyanın genel karmaşıklığını belirler. Hasar Nedenine göre süreci analiz etmek, gizli kalıpları ortaya çıkarabilir. Örneğin, 'Su Hasarı' ile ilgili dosyalar, 'Hırsızlık' dosyalarına kıyasla daha yüksek yeniden işleme (rework) oranına sahip olabilir veya daha fazla uzman katılımı gerektirebilir. Bu içgörüler, daha özel ve verimli işleme prosedürleri oluşturmaya yardımcı olur. Neden önemli Hasarın niteliği hakkında bağlam sağlayarak, farklı hasar nedenlerinin süreç akışını ve süresini nasıl etkilediğinin analiz edilmesini sağlar. Nereden alınır Bu, Hasar varlığı üzerinde standart bir alandır ve genellikle 'Hasar Nedeni' olarak adlandırılır. Örnekler CollisionYangınSu HasarıHırsızlık | |||
Hasar Türü ClaimType | Sigorta hasar talebinin Araç, Konut veya Sorumluluk gibi kategorisi. | ||
Açıklama Hasar Türü, bir hasarın iş koluna veya kaybın niteliğine göre yapılan temel bir sınıflandırmadır. Farklı hasar türleri genellikle kendine özgü süreçleri takip eder, farklı karmaşıklık seviyelerine sahiptir ve çeşitli düzenlemelere tabidir. Süreç analizini Hasar Türüne göre segmentlere ayırmak, anlamlı içgörüler elde etmek için hayati öneme sahiptir. Bu sayede, farklı iş kolları arasındaki süreç performansını karşılaştırmak, türe özgü darboğazları belirlemek ve süreç iyileştirme inisiyatiflerini her bir hasar kategorisinin benzersiz özelliklerine göre uyarlamak mümkün olur. Neden önemli Farklı türdeki hasarların (örneğin, Otomobil ve Mülk) genellikle farklı süreçleri takip etmesi ve farklı performans hedeflerine sahip olması nedeniyle hasarların segmentlere ayrılmasını sağlar. Nereden alınır ClaimCenter'daki Poliçe veya Hasar kayıtlarından elde edilir, genellikle İş Kolu (LOB) koduna göre belirlenir. Örnekler Bireysel OtoTicari MülkGenel Sorumlulukİşçi Tazminatı | |||
Bitiş Saati EndTime | Bir aktivitenin tamamlandığını gösteren timestamp. | ||
Açıklama Bitiş Zamanı, özellikle 'Soruşturma' veya 'Belge İncelemesi' gibi ölçülebilir bir süreye sahip task'lar için bir aktivitenin tamamlandığını gösterir. Birçok Process Mining aktivitesi anlık olsa da (StartTime yeterlidir), belirgin bir başlangıcı ve bitişi olan aktiviteler her iki timestamp ile daha iyi temsil edilir. Bu attribute, bekleme süresinden farklı olarak aktivite işlem süresinin hassas bir şekilde hesaplanmasına olanak tanır. Farklı adımlar arasındaki uzun gecikmeleri gözlemlemek yerine, hangi belirli task'ların zaman alıcı olduğunu belirlemeye yardımcı olur. Neden önemli Bir faaliyetin tamamlanmasının ne kadar sürdüğünü hassas bir şekilde ölçerek işlem süresini bekleme süresinden ayırır. Nereden alınır Bu, activityyi mantıksal olarak sonlandıran sonraki bir eventin bulunmasıyla türetilmesi gerekebilir (örn. 'Devam Ediyor' durumundan 'Tamamlandı' durumuna geçiş). Örnekler 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
Bölüm Department | Hasar aktivitesini yönetmekten sorumlu iş birimi veya departman. | ||
Açıklama Bu özellik, atanmış hasar görevlisinin bağlı olduğu departmanı veya ekibi, örneğin 'Araç Hasarları', 'Mülk Hasarları' veya 'Özel Soruşturma Birimi' gibi belirtir. Süreç için örgütsel bir bağlam sağlar. Departmana göre analiz yapmak, süreç performansını organizasyonel düzeyde anlamak için çok önemlidir. Bu, departmanlar arası devir gecikmelerini belirlemeye, ekipler arasındaki verimliliği karşılaştırmaya ve hasar organizasyonu genelinde kaynakları daha etkili bir şekilde tahsis etmeye yardımcı olur. Neden önemli Kurumsal bağlam sağlar, farklı ekipler arasında performans analizi yapılmasına olanak tanır ve departmanlar arası devir teslim sorunlarını vurgular. Nereden alınır Bu bilgi genellikle ClaimCenter içindeki atanmış kullanıcının veya grubun profiliyle ilişkilidir. Örnekler Oto Hasar DepartmanıMal Hasar BirimiÖzel Soruşturma Birimi (ÖSB) | |||
Çözüm Hedef Tarihi ResolutionTargetDate | Hasarın, iç veya yasal SLA'lara göre çözülmesi beklenen tarih. | ||
Açıklama Çözüm Hedef Tarihi, hasar kapanışı için belirlenen bir son tarihtir ve genellikle yargı alanı, hasar türü ve poliçe koşulları gibi faktörlere göre belirlenir. Performansı ve uyumluluğu ölçmek için bir referans noktası görevi görür. Bu attribute, SLA uyumu dashboard'ları ve KPI'ları oluşturmak için kritik öneme sahiptir. Gerçek 'Hasar Kapandı' tarihi bu hedef tarihle karşılaştırılarak, analiz otomatik olarak geciken hasarları işaretleyebilir, zamanında tamamlama oranlarını ölçebilir ve hangi hasar türlerinin veya departmanların hedeflerine ulaşmakta zorlandığını belirleyebilir. Neden önemli Bu, Hizmet Seviyesi Anlaşması (SLA) uyumunu ölçmek ve geç kalma riski taşıyan hasarları belirlemek için bir kıyas noktasıdır. Nereden alınır Bu, ClaimCenter'da yapılandırılmış iş kurallarına dayalı olarak özel bir alan veya türetilmiş bir değer olabilir, muhtemelen belirli hasar metricleriyle ilgilidir. Örnekler 2023-06-142023-07-202023-08-28 | |||
Hasar Tarihi LossDate | Hasarı tetikleyen olayın veya kaybın meydana geldiği tarih. | ||
Açıklama Hasar Tarihi, hasara yol açan fiili event'in (örn: trafik kazası, mülk hasarı) meydana geldiği tarihtir. Bu, hasarın bildirildiği veya oluşturulduğu tarihten farklıdır. Hasar Tarihi ile 'Hasar Oluşturuldu' aktivitesi (bildirim gecikmesi olarak bilinir) arasındaki zaman farkı önemli bir KPI'dır. Bunun analizi, müşteri davranışları ve ilk hasar bildirimi kanallarının etkinliği hakkında değerli içgörüler sağlayabilir. Neden önemli Hasarın kökeni hakkında kritik bağlam sunar ve raporlama gecikmesinin (olaydan hasar bildirimine kadar geçen süre) analiz edilmesine yardımcı olur. Nereden alınır Bu, Hasar varlığı üzerinde yer alan, genellikle 'Hasar Tarihi' olarak adlandırılan temel bir tarih alanıdır. Örnekler 2023-05-102023-04-202023-05-28 | |||
İşlem Süresi ProcessingTime | Bir aktivite üzerinde aktif olarak çalışılan süre. | ||
Açıklama İşlem Süresi, bir aktivite üzerinde aktif olarak çalışılan süreyi ölçer; Bitiş Zamanı ile Başlangıç Zamanı arasındaki fark olarak hesaplanır. Bekleme sürelerini içeren döngü süresinden farklıdır. Bu hesaplanmış metrik, bir görevin gerçek çabasını boşta kalma veya bekleme süresinden ayırdığı için performans analizi için hayati öneme sahiptir. Hangi adımların gerçekten zaman alıcı olduğunu ve eğitim, daha iyi araçlar veya süreç yeniden tasarımı yoluyla verimlilik kazanımlarının nerede sağlanabileceğini doğru bir şekilde belirlemeye yardımcı olur. Neden önemli Bir aktivitenin aktif çalışma süresini ölçer, katma değerli zamanı bekleme süresinden ayırmaya yardımcı olur. Nereden alınır Hesaplanmış alan: EndTime - StartTime. Kaynak verilerde her iki zaman damgasının da mevcut olmasını gerektirir. Örnekler 8SPT15MP2D | |||
Kaynak Sistem SourceSystem | Verilerin çekildiği sistem. | ||
Açıklama Bu özellik, event verisinin kaynağını tanımlar. Modern bir kurumsal ortamda, dosya ile ilgili event'ler, Guidewire gibi bir ana sistem, bir doküman yönetim sistemi veya bir müşteri portalı gibi birden fazla sistemden kaynaklanabilir. Kaynak sistemi belirtmek, veri yönetimi (data governance), veri tutarsızlıklarını giderme (troubleshooting data inconsistencies) ve sürecin teknolojik yapısını anlamak için çok önemlidir. Bu, temel süreç adımları ile çevre sistemlerden gelen destekleyici aktiviteler arasında ayrım yapmaya yardımcı olur. Neden önemli Veri yönetimi ve birden fazla entegre sistem içeren analizler için kritik olan verilerin kaynağını belirler. Nereden alınır Bu, genellikle data extraction, transformation ve loading (ETL) süreci sırasında eklenen statik bir değerdir. Örnekler Guidewire ClaimCenter v10Customer Portal APIDocumentum | |||
Ödeme Tutarı PaymentAmount | Bir ödeme aktivitesi için ödenen fiili miktar. | ||
Açıklama Bu özellik, bir dosyaya yapılan her bir ödemenin değerini kaydeder. Bir dosya, yaşam döngüsü boyunca birden fazla ödeme içerebilir. Bu, Process Mining bağlamında finansal analiz için çok önemlidir. Dosya başına toplam ödemeyi izlemek, miktara göre ödeme onay sürelerini analiz etmek ve süreç verimsizliklerini finansal sonuçlarla ilişkilendirmek için kullanılabilir. Örneğin, uzun döngü sürelerine (cycle times) sahip dosyalar, daha yüksek toplam ödemelerle ilişkili olabilir. Neden önemli Bir hasar içindeki finansal transactionları takip ederek, ödeme değerlerinin ve bunların process activityleri ile ilişkisinin analiz edilmesini sağlar. Nereden alınır Hasarla bağlantılı ödeme bağlantılı varlıklarda, genellikle bir işlem veya çek tablosunda bulunur. Örnekler 4500.00125000.00500.00 | |||
Otomatikleştirildi mi? IsAutomated | Bir aktivitenin sistem tarafından otomatik olarak mı yoksa bir insan kullanıcısı tarafından mı gerçekleştirildiğini gösteren bir işaretçi. | ||
Açıklama Bu boolean özellik, bir sistem tarafından yürütülen (örneğin otomatik rezerv oluşturma, sistem tarafından oluşturulan yazışmalar) aktiviteler ile bir hasar görevlisi tarafından manuel olarak gerçekleştirilenleri ayırt eder. Bu özelliği analiz etmek, dosya sürecindeki otomasyon seviyesini anlamak için anahtardır. Manuel müdahale noktalarını belirlemeye, düz işlem (straight-through processing) girişimlerinin etkinliğini ölçmeye ve şu anda insanlar tarafından yapılan tekrarlayan, kural tabanlı görevleri tespit ederek yeni otomasyon fırsatları bulmaya yardımcı olur. Neden önemli Sistem ve insan odaklı faaliyetler arasındaki farkı ortaya koyar; bu, otomasyon analizi ve manuel darboğazların belirlenmesi için anahtar niteliğindedir. Nereden alınır Bu genellikle türetilmesi gereken bir bilgidir. Örneğin, genel bir 'sistem' kullanıcısı tarafından günlüğe kaydedilen eventler otomatik olarak işaretlenebilir. Örnekler truefalse | |||
Poliçe Türü PolicyType | Hasarın dosyalandığı sigorta poliçesinin belirli türü. | ||
Açıklama Poliçe Türü, Hasar Türü'nden daha ayrıntılı bir sınıflandırma sunarak, 'Konut Sigortası', 'Ticari Oto' veya 'Siber Sorumluluk' gibi belirli sigorta ürünlerini detaylandırır. Bu detay seviyesi, belirli ürünlere bağlı süreç varyasyonlarını ortaya çıkarabilir. Poliçe Türüne göre süreci analiz etmek, ürüne özgü verimsizlikleri keşfetmeye yardımcı olur. Örneğin, yeni başlatılan bir poliçeye ait hasarlar, daha az olgun bir süreci takip edebilir ve bu da gecikmelere yol açabilir. Bu analiz, ürün tasarımına ve süreç standardizasyon çalışmalarına bilgi sağlayabilir. Neden önemli Belirli sigorta ürünlerine yönelik süreç analizini mümkün kılar, poliçe detaylarına göre işlem farklılıklarının belirlenmesine yardımcı olur. Nereden alınır Bu bilgi, Poliçe varlığında bulunur ve Hasar ile ilişkilidir. Örnekler Konut Sahipleri Çoklu Risk SigortasıCommercial Auto Liabilityİç Deniz Nakliyat | |||
SLA Statüsü SLAState | Hasarın çözüm hedef tarihi içinde kapatılıp kapatılmadığını belirtir. | ||
Açıklama Bu hesaplanmış özellik, her kapanmış dosya için SLA uyumluluğunun kategorik bir durumunu sağlar. Bu, 'Dosya Kapandı' aktivitesinin timestamp'i ile 'Çözüm Hedef Tarihi'nin karşılaştırılmasıyla türetilir. Bu özellik, analizi 'Zamanında' veya 'Gecikti' gibi net kategorilere ayırarak 'Dosya Çözüm Hedefi Uyumluluğu' dashboard'unu doğrudan destekler. Genel SLA uyumluluk oranını hesaplamak ve gecikmelerin nedenlerini derinlemesine incelemek için kolay filtreleme ve toplama imkanı sunar. Neden önemli SLA uyumluluğu için net, kategorik bir sonuç sağlayarak, zamanında performansı filtrelemeyi, toplamayı ve analiz etmeyi kolaylaştırır. Nereden alınır Hesaplanmış alan: EĞER (ActualCloseDate <= ResolutionTargetDate, 'Zamanında', 'Gecikmeli'). Örnekler ZamanındaGecikmiş | |||
Son Veri Güncellemesi LastDataUpdate | Data'nın kaynak sistemden en son ne zaman yenilendiğini veya çıkarıldığını gösteren timestamp. | ||
Açıklama Bu özellik, kaynak sistemden en son veri çekiminin (data pull) timestamp'ini sağlar. Analizin güncelliğini anlamak için gerekli olan bir metadata alanıdır. Dashboard'lar ve analizler bu bilgiyi belirgin bir şekilde göstermelidir, böylece kullanıcılar verinin güncelliğinin farkında olurlar. Bu, elde edilen içgörülerin operasyonların mevcut durumunu yansıtıp yansıtmadığını veya eski verilere mi dayandığını değerlendirmeye yardımcı olur. Neden önemli Verilerin güncelliğini gösterir, böylece 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üreci sırasında oluşturulur ve saklanır; data load'unun timestampini temsil eder. Örnekler 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
Talep Edilen Tutar ClaimedAmount | Sigorta sahibi 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 Yüksek değerli hasarların farklı, daha karmaşık süreçleri takip edebilmesi nedeniyle hasarların finansal değere göre segmentlere ayrılmasını sağlar. Nereden alınır Bu bilgi tek bir alan olmayabilir, ancak maruziyetler üzerine kaydedilen ilk zarar tahminlerinden türetilebilir. Örnekler 5000.00150000.00750.50 | |||
Tekrarlanan Bilgi Talebi RepeatedInfoRequestFlag | Aynı hasar için 'Ek Bilgi Talep Edildi' aktivitesinin birden fazla kez gerçekleşip gerçekleşmediğini gösteren bir işaretçi. | ||
Açıklama Bu boolean flag, bir dosyanın birden fazla 'Ek Bilgi Talebi' aktivitesine sahip olması durumunda doğru olarak ayarlanır. Bu senaryo, genellikle ilk bilgi toplama aşamasındaki verimsizliklere işaret eder. Bu özellik, 'Tekrarlayan Bilgi Talep Oranı' KPI'ını doğrudan destekler. Eksik ilk bilgi toplama sorununu nicelleştirmeye yardımcı olur; bu da önemli gecikmelere ve müşteri memnuniyetsizliğine yol açabilir. Bu flag'e sahip dosyaları analiz etmek, hasar görevlileri için tüm gerekli bilgilerin tek seferde istenmesini sağlamak amacıyla kontrol listelerini ve prosedürleri iyileştirmeye yardımcı olabilir. Neden önemli İlk seferde eksiksiz bilgi toplanamadığı durumlardan kaynaklanan süreç gecikmelerini ve yeniden işlemeleri tespit eder. Nereden alınır Process Mining aracı içinde, her vaka başına 'Ek Bilgi Talep Edildi' aktivitesinin gerçekleşme sayısını sayarak hesaplanır. Örnekler truefalse | |||
Yargı Yetkisi Eyaleti JurisdictionState | Hasarı yöneten eyalet veya yargı alanı, düzenleyici gereksinimleri belirler. | ||
Açıklama Bu özellik, dosyanın işlem gördüğü yasal yetki alanını (örneğin ABD eyaleti) belirtir. Sigorta düzenlemeleri, yetki alanları arasında önemli ölçüde farklılık gösterebilir; bu da gerekli süreç adımlarını, iletişim sürelerini ve dokümantasyonu etkiler. Bu, uyumluluk izleme (compliance monitoring) için hayati bir özelliktir. Süreci yetki alanına göre analiz etmek, eyalete özgü düzenleyici gereksinimlerin karşılandığından emin olunmasını sağlar. Ayrıca, döngü sürelerindeki (cycle times) veya operasyonel verimsizlikten ziyade yasal kısıtlamalar tarafından yönlendirilen süreç yollarındaki farklılıkları da açıklayabilir. Neden önemli Farklı yargı bölgelerinin hasar sürecini etkileyen farklı düzenlemeleri olduğu için uyumluluk analizi için kritik öneme sahiptir. Nereden alınır Talep (Claim) varlığında yer alan, genellikle 'JurisdictionState' olarak adlandırılan standart bir alan. Örnekler CANYTXFL | |||
Yeniden İşleme mi? IsRework | Bir aktivitenin tekrar işleme döngüsünü, yani önceki bir süreç aşamasına dönüşü temsil edip etmediğini gösteren bir işaretçi. | ||
Açıklama Bu hesaplanmış özellik, yeniden işleme (rework) döngüsünün bir parçası olan aktiviteleri işaretler. Örneğin, süreç 'Soruşturma Tamamlandı'dan 'Soruşturma Başladı'ya geri dönerse, ikinci 'Soruşturma Başladı' aktivitesi yeniden işleme olarak işaretlenir. Yeniden işlemeyi (rework) tespit etmek, süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarmak için temeldir. Yeniden İşleme ve Reddetme Sıklığı dashboard'u, dosyaların ideal 'happy path'ten ne sıklıkta saptığını nicelleştirmek için bu metriğe dayanır. Yeniden işleme nedenlerini analiz etmek, süreç kalitesinde ve hızında önemli iyileşmelere yol açabilir. Neden önemli Tekrarlayan iş döngüsünün bir parçası olan faaliyetleri açıkça işaretleyerek süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarır. Nereden alınır Bu, process mining aracında her bir case için activity dizisinin analiz edilmesiyle hesaplanır. Örnekler truefalse | |||
Hasar İşleme Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
Hasar Kapatıldı | Tüm faaliyetler ve ödemeler tamamlandıktan sonra bir hasarın başarılı bir şekilde kapatıldığını gösterir. Bu, hasarın ana durumundaki bir değişiklikten çıkarılan birincil başarılı bitiş olayıdır. | ||
Neden önemli Birincil bitiş olayı olarak bu aktivite, uçtan uca çevrim süresini hesaplamak ve Hizmet Seviyesi Anlaşması (HSA) uyumluluğunu ölçmek için hayati öneme sahiptir. Hasar yaşam döngüsünün tamamlandığını gösterir. Nereden alınır cc_claim tablosunun State alanının 'Closed' olarak değiştirilmesinden çıkarılır. Olayın zaman damgası, hasar kaydındaki CloseDate'tir. Yakala Hasarın ana durum alanının 'Closed' olarak güncellendiği zamanı belirleyin. Event tipi inferred | |||
Hasar Oluşturuldu | Bu aktivite, ilk hasar bildirimini (FNOL) ve Guidewire ClaimCenter'da yeni bir dosya kaydının resmi olarak oluşturulmasını gösterir. Yeni bir Claim entity'si veritabanına ilk kez kaydedildiğinde açıkça yakalanır. | ||
Neden önemli Birincil başlangıç olayı olarak bu aktivite, uçtan uca hasar çevrim süresini ölçmek için hayati öneme sahiptir. Sonraki tüm performans ve süre KPI'ları için temel teşkil eder. Nereden alınır Bu, cc_claim tablosunun CreateTime değerinden yakalanan açık bir eventtir. Benzersiz bir Hasar ID'si ile yeni bir kaydın oluşturulması, event tetikleyicisi olarak işlev görür. Yakala Temel Claim varlık tablosundaki yeni kaydın oluşturulma zaman damgasını belirleyin. Event tipi explicit | |||
Hasar Reddedildi | Bir hasarın reddedilmesi yönündeki nihai kararı temsil eder ve süreç için bir bitiş noktası görevi görür. Bu event, hasarın durumunun 'Reddedildi' sebebiyle kapalı bir duruma geçmesinden anlaşılır. | ||
Neden önemli Bu, kritik bir sonuç olayıdır. Reddedilmelerin sıklığını, nedenlerini ve bu reddedilmelere yol açan süreç yollarını analiz etmek; hasar girişi, soruşturma veya poliçe yorumlamasındaki sorunları tespit etmeye yardımcı olur. Nereden alınır cc_claim tablosunun State alanının 'Closed' olarak değiştirilmesinden ve CloseReason alanının 'Denied' veya benzeri bir değer olmasından çıkarılır. Olayın zaman damgası CloseDate'tir. Yakala Hasar durumu 'Kapandı' olarak değiştiğinde ve neden kodu reddi gösterdiğinde filtreleme yapın. Event tipi inferred | |||
İlk Rezerv Oluşturuldu | Bir risk için ilk finansal karşılık işleminin oluşturulduğunu gösterir ve hasarın potansiyel maliyetini tahmin eder. Bu kritik bir finansal olaydır ve açıkça kaydedilir. | ||
Neden önemli Bu kilometre taşı, finansal analiz ve potansiyel sorumluluğun ne kadar hızlı değerlendirildiğini anlamak için anahtardır. Gecikmeler, finansal planlama ve raporlamayı etkileyebilir. Nereden alınır Bu event, dosyada bir exposure ile ilişkili ilk cc_reserveline kaydının oluşturulmasından yakalanır. Bu transaction'ın CreateTime değeri, event'in timestamp'idir. Yakala Belirli bir hasarın rizikoları için tüm provizyon kalemlerinin minimum oluşturma zaman damgasını bulun. Event tipi explicit | |||
Ödeme Onaylandı | Bir tazminat ödemesinin resmi onayını temsil eder. Bu, kritik bir denetim event'idir ve yetkili bir kullanıcı işlemi onayladığında açıkça kaydedilir. | ||
Neden önemli Bu anahtar kilometre taşı, son ödeme adımının önünü açar. Bu activity öncesi ve sonrası süreyi analiz etmek, onay workflowları veya yönetici müsaitliği nedeniyle oluşan gecikmeleri izole etmeye yardımcı olur. Nereden alınır Bu, genellikle bir cc_check veya cc_transaction varlığıyla ilgili cc_history tablosunda günlüğe kaydedilen, 'Onay Bekliyor' durumundan 'Onaylandı' durumuna geçişi gösteren açık bir eventtir. Yakala Belirli bir ödeme transaction'ı için durum değişikliği eventini 'Onaylandı' olarak takip edin. Event tipi explicit | |||
Ödeme Yapıldı | Bu aktivite, ödemenin resmi olarak yapıldığı ve finansal sisteme gönderildiği ödeme sürecindeki son adımdır. Bu, açıkça kaydedilmiş bir finansal işlemdir. | ||
Neden önemli Bu aktivite, ödeme gönderim sürecinin verimliliğini ölçmek için kritik öneme sahiptir. Onay gecikmeleri ile fonların fiilen ödenmesindeki 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 yakalanmıştır. Bu genellikle açıkça belirtilmiş bir timestamped event'tir. Yakala Ödeme kaydındaki 'Issued' durum değişikliğinin IssueDate veya zaman damgasını belirleyin. Event tipi explicit | |||
Riziko Oluşturuldu | Bu aktivite, bir dosya kapsamındaki belirli bir potansiyel sorumluluğu veya hasar türünü (örneğin araç hasarı, yaralanma) temsil eden bir exposure oluşturulduğunu gösterir. Bu, Guidewire'da açıkça kaydedilmiş bir event'tir. | ||
Neden önemli Rizikolar, hasar segmentasyonu ve analizi için temeldir. Bunların oluşturulmasını takip etmek, hasar karmaşıklığına ve zarar 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 yakalanmıştır. Her kayıt tek bir Claim ID ile ilişkilidir. Yakala Exposure varlık tablosundaki yeni bir kaydın oluşturulma zaman damgasını belirleyin. Event tipi explicit | |||
Ek Bilgi Alındı | Ek bilgi talebinin tamamlandığını gösterir. Bu, bilgi talebiyle ilgili 'Aktivite' (görev) 'Tamamlandı' olarak işaretlendiğinde kaydedilir. | ||
Neden önemli Bu, 'Ek Bilgi Toplama Döngü Süresi' KPI'sı için bitiş noktasıdır. Talep ve makbuz arasındaki uzun süreler, hasar sürecindeki gecikmelerin yaygın nedenleridir. Nereden alınır ActivityPattern'ın bir bilgi talebiyle ilgili olduğu bir cc_activity kaydının CloseTime değerinden alınmıştır. Aktivitenin durumu 'Completed' (Tamamlandı) olmalıdır. Yakala Harici bilgi talep etme görevinin tamamlanma zaman damgasını belirleyin. Event tipi explicit | |||
Ek Bilgi Talep Edildi | Hak sahibine veya üçüncü bir tarafa gönderilen daha fazla bilgi veya belge talebini temsil eder. Bu durum, genellikle ClaimCenter'da oluşturulan açık bir 'Aktivite' (görev) olarak kaydedilir. | ||
Neden önemli Bu aktivite, 'Ek Bilgi Toplama Döngü Süresi' KPI'ını ölçmek için başlangıç noktasıdır. Sık sık tekrarlanması, eksik FNOL süreçlerine veya verimsiz bilgi toplamaya işaret edebilir. Nereden alınır Harici bir taraftan belge veya bilgi talep etmeyle ilgili ActivityPattern'e sahip bir cc_activity kaydının CreateTime alanından yakalanmıştır. Yakala Harici bilgi talep etme görevinin oluşturulmasını belirleyin. Event tipi explicit | |||
Hasar Atandı | Bir hasar dosyasının belirli bir kullanıcıya (eksper/sorumlu) veya gruba atanmasını temsil eder. Bu durum, genellikle Hasar entity'si üzerindeki atama alanlarındaki değişiklikler izlenerek anlaşılır. | ||
Neden önemli Atamaları takip etmek, eksper iş yükünü analiz etmek, yönlendirme darboğazlarını belirlemek ve atanmış eksperin ilk eyleme geçme süresini ölçmek için kritiktir. Nereden alınır cc_history tablosundan, belirli bir Hasar ID'siyle ilişkili AssignedUser veya AssignedGroup alanlarındaki değişiklikler izlenerek çıkarılır. Değişikliğin zaman damgası, olayın ne zaman gerçekleştiğini 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ı | Bir hasarın ek çalışma yapmak üzere 'Kapalı' durumdan tekrar 'Açık' duruma geçirilmesini temsil eder. Bu olay, belirli bir durum değişikliği dizisinden çıkarılır. | ||
Neden önemli Bu aktivite, yeniden işleme (rework) anlamına gelir. Yeniden açılan dosyaların yüksek sayısı, ilk uzlaşmada, gözden kaçan hasarlarda veya diğer süreç hatalarında sorunlar olduğunu göstererek maliyetleri ve verimsizliği artırır. Nereden alınır cc_history tablosundan, cc_claim varlığının State alanının 'Closed' durumundan tekrar 'Open' veya başka bir aktif duruma geçtiği tespit edilerek çıkarılır. Yakala Hasarın ana durum alanını, kapalı durumdan açık duruma geçiş için izleyin. Event tipi inferred | |||
Ödeme Hesaplandı | Bu aktivite, bir uzlaşma miktarının belirlendiği ancak ödeme için henüz onaylanmadığı noktayı temsil eder. 'Onay Bekliyor' durumunda bir ödeme oluşturulmasından çıkarılabilir. | ||
Neden önemli Değerlendirmeden ödemeye geçişi işaret eder. Onay zincirindeki gecikmeleri ortaya koyan 'Ödeme Yetkilendirme Süresi' KPI'ını ölçmek için başlangıç noktasıdır. Nereden alınır Başlangıç durumu 'Pending Approval' veya 'Approved' öncesi benzer bir durum olan bir cc_check veya cc_transaction kaydının CreateTime'ından çıkarılır. Yakala Ön onaylı durumda bir ödeme veya işlem kaydının oluşturulmasını belirleyin. Event tipi inferred | |||
Sorumluluk Kararı Verildi | Bir risk için sorumluluk veya kusur kararının belirlendiği noktayı temsil eder. Bu event, genellikle Risk entity'si üzerindeki bir status değişikliğinden anlaşılır. | ||
Neden önemli Bu, ödeme ve tazminat aşamalarının önünü açan kritik bir karar aşamasıdır. Bu kararın alınma süresini analiz etmek, araştırma ve değerlendirme aşamalarındaki darboğazları belirlemeye yardımcı olur. Nereden alınır cc_history tablosundan, cc_exposure varlığı üzerindeki State veya özel bir sorumluluk durumu alanındaki bir değişiklik izlenerek çıkarılır. Geçmiş kaydının zaman damgası olay zamanını belirtir. Yakala Risk durumunun veya sorumluluk statüsünün güncellemeleri için denetim kayıtlarını veya geçmiş tablolarını izleyin. Event tipi inferred | |||
Soruşturma Başladı | Bir hasar veya maruziyet için soruşturma aşamasının resmi başlangıcını gösterir. Bu durum, genellikle Guidewire'da ilk soruşturma ile ilgili 'Faaliyet' (görev) oluşturulmasından çıkarılır. | ||
Neden önemli Bu aktivite, genellikle uzun süren önemli bir aşamanın başlangıcını işaret eder. Soruşturmanın başlangıcına kadar geçen süreyi ve soruşturmanın kendi süresini analiz etmek, büyük darboğazları ortaya çıkarır. Nereden alınır ActivityPattern'ın soruşturma ile ilgili olduğu (örneğin, 'Initial Investigation', 'Contact Witness') bir cc_activity kaydının CreateTime'ından çıkarılır. Yakala Soruşturma ile ilgili bir desen veya konuya sahip ilk görevin oluşturulmasını belirleyin. Event tipi inferred | |||
Veri Çekim Kılavuzları
Adımlar
- Ön Koşulların Doğrulanması: Guidewire DataHub / InfoCenter veri ambarı veritabanına okuma yetkileriyle erişmek için gerekli izinlere ve kimlik bilgilerine sahip olduğunuzdan emin olun. Hasar veri ambarını dolduran ETL işlerinin başarılı bir şekilde çalıştığından ve verilerin güncel olduğundan emin olun.
- Veritabanı Bağlantısı: Veri ambarı veritabanı sunucusuna bağlantı kurmak için standart bir SQL istemcisi (DBeaver, SQL Server Management Studio veya benzeri araçlar gibi) kullanın.
- Şema Keşfi: Sorguyu çalıştırmadan önce veri ambarı şemasına aşina olun. Hasarlar, teminatlar, aktiviteler ve finansal işlemler için birincil tabloları belirleyin. Ana tablolar genellikle _dim (boyut) ve _fact (olgusal) gibi son eklerle adlandırılır. Bu, sağlanan betikteki yer tutucu tablo ve sütun adlarını doğrulamanıza yardımcı olacaktır.
- SQL Sorgusunu Hazırlama: query bölümünde sağlanan SQL betiğinin tamamını SQL istemcinizin sorgu düzenleyicisine kopyalayın.
- Yer Tutucuları Özelleştirme: Betiği dikkatlice inceleyin ve tüm yer tutucu değerlerini değiştirin. Buna veritabanı/şema adı (örneğin, [YourDataMart]), tarih aralığı parametreleri ('[StartDate]', '[EndDate]') ve herhangi bir sisteme özel yapılandırma değerleri (örneğin, aktivite desenleri, durum kodları) dahildir.
- Sorgu Yürütme: Değiştirilen SQL sorgusunu veri ambarında yürütün. Yürütme süresi, seçilen tarih aralığına ve sisteminizdeki veri hacmine bağlı olarak değişebilir.
- İlk Veri İncelemesi: Sorgu tamamlandığında, sonuç kümesinin ilk birkaç yüz satırını inceleyin. ClaimID, ActivityName ve EventTime sütunlarının beklendiği gibi doldurulduğunu ve farklı aktivite türlerinin mevcut olduğunu kontrol edin.
- CSV'ye Dışa Aktarma: Tüm sonuç kümesini SQL istemcinizden bir CSV dosyasına dışa aktarın. Dosyayı açıklayıcı bir şekilde adlandırın, örneğin, guidewire_claimcenter_event_log.csv.
- ProcessMind için Biçimlendirme: CSV dosyasının UTF-8 kodlamasıyla kaydedildiğinden emin olun. Dosyanın SQL sorgusundaki sütun takma adlarıyla eşleşen bir başlık satırına sahip olduğunu doğrulayın. Dosya artık ProcessMind'e yüklenmeye hazırdır.
Konfigürasyon
- Veri Kaynağı: Guidewire DataHub/InfoCenter Hasar Veri Ambarı (Claims Data Mart). Bu, raporlama ve analitik için tasarlanmış, önceden toplanmış, boyutlu bir veritabanıdır ve canlı ClaimCenter üretim veritabanından ayrıdır.
- Gerekli Yetkilendirmeler: Veri ambarını barındıran SQL veritabanına salt okunur (read-only) erişim. Bir kullanıcı adı, şifre ve bağlantı detaylarına (sunucu adresi, veritabanı adı) ihtiyacınız olacaktır.
- ETL İş Durumu: Bu veri çıkarımının doğruluğu, veri ambarını dolduran Guidewire ETL işlerinin başarılı ve zamanında çalıştırılmasına bağlıdır. Verinin ne kadar güncel olduğunu anlamak için en son başarılı çalışma zamanını kontrol edin.
- Tarih Aralığı Filtrelemesi: Sağlanan sorgu, WHERE koşullarıyla '[StartDate]' ve '[EndDate]' yer tutucularını içermektedir. Performansı yönetmek için sınırlı bir tarih aralığıyla (örn. 3-6 ay) başlamanız önerilir. Tarih filtresi, hasarın CreateTime alanı üzerinden uygulanır.
- Konfigürasyona Özel Değerler: Guidewire oldukça yapılandırılabilirdir (configurable). Kuruluşunuzun kurulumuna (setup) uyacak şekilde WHERE koşullarındaki değerleri ayarlamalısınız. Bu şunları içerir:
- 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 geçmiş veya denetim tablolarını sorgulamak yoğun kaynak tüketebilir. Çok büyük veri kümeleri için sorguyu yoğun olmayan saatlerde çalıştırmanız önerilir. İlgili tablolarda ClaimID veya ClaimNumber sütunlarının indekslendiğinden 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
- Ön Koşulların Doğrulanması: Guidewire DataHub / InfoCenter veri ambarı veritabanına okuma yetkileriyle erişmek için gerekli izinlere ve kimlik bilgilerine sahip olduğunuzdan emin olun. Hasar veri ambarını dolduran ETL işlerinin başarılı bir şekilde çalıştığından ve verilerin güncel olduğundan emin olun.
- Veritabanı Bağlantısı: Veri ambarı veritabanı sunucusuna bağlantı kurmak için standart bir SQL istemcisi (DBeaver, SQL Server Management Studio veya benzeri araçlar gibi) kullanın.
- Şema Keşfi: Sorguyu çalıştırmadan önce veri ambarı şemasına aşina olun. Hasarlar, teminatlar, aktiviteler ve finansal işlemler için birincil tabloları belirleyin. Ana tablolar genellikle _dim (boyut) ve _fact (olgusal) gibi son eklerle adlandırılır. Bu, sağlanan betikteki yer tutucu tablo ve sütun adlarını doğrulamanıza yardımcı olacaktır.
- SQL Sorgusunu Hazırlama: query bölümünde sağlanan SQL betiğinin tamamını SQL istemcinizin sorgu düzenleyicisine kopyalayın.
- Yer Tutucuları Özelleştirme: Betiği dikkatlice inceleyin ve tüm yer tutucu değerlerini değiştirin. Buna veritabanı/şema adı (örneğin, [YourDataMart]), tarih aralığı parametreleri ('[StartDate]', '[EndDate]') ve herhangi bir sisteme özel yapılandırma değerleri (örneğin, aktivite desenleri, durum kodları) dahildir.
- Sorgu Yürütme: Değiştirilen SQL sorgusunu veri ambarında yürütün. Yürütme süresi, seçilen tarih aralığına ve sisteminizdeki veri hacmine bağlı olarak değişebilir.
- İlk Veri İncelemesi: Sorgu tamamlandığında, sonuç kümesinin ilk birkaç yüz satırını inceleyin. ClaimID, ActivityName ve EventTime sütunlarının beklendiği gibi doldurulduğunu ve farklı aktivite türlerinin mevcut olduğunu kontrol edin.
- CSV'ye Dışa Aktarma: Tüm sonuç kümesini SQL istemcinizden bir CSV dosyasına dışa aktarın. Dosyayı açıklayıcı bir şekilde adlandırın, örneğin, guidewire_claimcenter_event_log.csv.
- ProcessMind için Biçimlendirme: CSV dosyasının UTF-8 kodlamasıyla kaydedildiğinden emin olun. Dosyanın SQL sorgusundaki sütun takma adlarıyla eşleşen bir başlık satırına sahip olduğunu doğrulayın. Dosya artık ProcessMind'e yüklenmeye hazırdır.
Konfigürasyon
- Veri Kaynağı: Guidewire DataHub/InfoCenter Hasar Veri Ambarı (Claims Data Mart). Bu, raporlama ve analitik için tasarlanmış, önceden toplanmış, boyutlu bir veritabanıdır ve canlı ClaimCenter üretim veritabanından ayrıdır.
- Gerekli Yetkilendirmeler: Veri ambarını barındıran SQL veritabanına salt okunur (read-only) erişim. Bir kullanıcı adı, şifre ve bağlantı detaylarına (sunucu adresi, veritabanı adı) ihtiyacınız olacaktır.
- ETL İş Durumu: Bu veri çıkarımının doğruluğu, veri ambarını dolduran Guidewire ETL işlerinin başarılı ve zamanında çalıştırılmasına bağlıdır. Verinin ne kadar güncel olduğunu anlamak için en son başarılı çalışma zamanını kontrol edin.
- Tarih Aralığı Filtrelemesi: Sağlanan sorgu, WHERE koşullarıyla '[StartDate]' ve '[EndDate]' yer tutucularını içermektedir. Performansı yönetmek için sınırlı bir tarih aralığıyla (örn. 3-6 ay) başlamanız önerilir. Tarih filtresi, hasarın CreateTime alanı üzerinden uygulanır.
- Konfigürasyona Özel Değerler: Guidewire oldukça yapılandırılabilirdir (configurable). Kuruluşunuzun kurulumuna (setup) uyacak şekilde WHERE koşullarındaki değerleri ayarlamalısınız. Bu şunları içerir:
- 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 geçmiş veya denetim tablolarını sorgulamak yoğun kaynak tüketebilir. Çok büyük veri kümeleri için sorguyu yoğun olmayan saatlerde çalıştırmanız önerilir. İlgili tablolarda ClaimID veya ClaimNumber sütunlarının indekslendiğinden 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
- Ön Koşulların Doğrulanması: Guidewire DataHub / InfoCenter veri ambarı veritabanına okuma yetkileriyle erişmek için gerekli izinlere ve kimlik bilgilerine sahip olduğunuzdan emin olun. Hasar veri ambarını dolduran ETL işlerinin başarılı bir şekilde çalıştığından ve verilerin güncel olduğundan emin olun.
- Veritabanı Bağlantısı: Veri ambarı veritabanı sunucusuna bağlantı kurmak için standart bir SQL istemcisi (DBeaver, SQL Server Management Studio veya benzeri araçlar gibi) kullanın.
- Şema Keşfi: Sorguyu çalıştırmadan önce veri ambarı şemasına aşina olun. Hasarlar, teminatlar, aktiviteler ve finansal işlemler için birincil tabloları belirleyin. Ana tablolar genellikle _dim (boyut) ve _fact (olgusal) gibi son eklerle adlandırılır. Bu, sağlanan betikteki yer tutucu tablo ve sütun adlarını doğrulamanıza yardımcı olacaktır.
- SQL Sorgusunu Hazırlama: query bölümünde sağlanan SQL betiğinin tamamını SQL istemcinizin sorgu düzenleyicisine kopyalayın.
- Yer Tutucuları Özelleştirme: Betiği dikkatlice inceleyin ve tüm yer tutucu değerlerini değiştirin. Buna veritabanı/şema adı (örneğin, [YourDataMart]), tarih aralığı parametreleri ('[StartDate]', '[EndDate]') ve herhangi bir sisteme özel yapılandırma değerleri (örneğin, aktivite desenleri, durum kodları) dahildir.
- Sorgu Yürütme: Değiştirilen SQL sorgusunu veri ambarında yürütün. Yürütme süresi, seçilen tarih aralığına ve sisteminizdeki veri hacmine bağlı olarak değişebilir.
- İlk Veri İncelemesi: Sorgu tamamlandığında, sonuç kümesinin ilk birkaç yüz satırını inceleyin. ClaimID, ActivityName ve EventTime sütunlarının beklendiği gibi doldurulduğunu ve farklı aktivite türlerinin mevcut olduğunu kontrol edin.
- CSV'ye Dışa Aktarma: Tüm sonuç kümesini SQL istemcinizden bir CSV dosyasına dışa aktarın. Dosyayı açıklayıcı bir şekilde adlandırın, örneğin, guidewire_claimcenter_event_log.csv.
- ProcessMind için Biçimlendirme: CSV dosyasının UTF-8 kodlamasıyla kaydedildiğinden emin olun. Dosyanın SQL sorgusundaki sütun takma adlarıyla eşleşen bir başlık satırına sahip olduğunu doğrulayın. Dosya artık ProcessMind'e yüklenmeye hazırdır.
Konfigürasyon
- Veri Kaynağı: Guidewire DataHub/InfoCenter Hasar Veri Ambarı (Claims Data Mart). Bu, raporlama ve analitik için tasarlanmış, önceden toplanmış, boyutlu bir veritabanıdır ve canlı ClaimCenter üretim veritabanından ayrıdır.
- Gerekli Yetkilendirmeler: Veri ambarını barındıran SQL veritabanına salt okunur (read-only) erişim. Bir kullanıcı adı, şifre ve bağlantı detaylarına (sunucu adresi, veritabanı adı) ihtiyacınız olacaktır.
- ETL İş Durumu: Bu veri çıkarımının doğruluğu, veri ambarını dolduran Guidewire ETL işlerinin başarılı ve zamanında çalıştırılmasına bağlıdır. Verinin ne kadar güncel olduğunu anlamak için en son başarılı çalışma zamanını kontrol edin.
- Tarih Aralığı Filtrelemesi: Sağlanan sorgu, WHERE koşullarıyla '[StartDate]' ve '[EndDate]' yer tutucularını içermektedir. Performansı yönetmek için sınırlı bir tarih aralığıyla (örn. 3-6 ay) başlamanız önerilir. Tarih filtresi, hasarın CreateTime alanı üzerinden uygulanır.
- Konfigürasyona Özel Değerler: Guidewire oldukça yapılandırılabilirdir (configurable). Kuruluşunuzun kurulumuna (setup) uyacak şekilde WHERE koşullarındaki değerleri ayarlamalısınız. Bu şunları içerir:
- 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 geçmiş veya denetim tablolarını sorgulamak yoğun kaynak tüketebilir. Çok büyük veri kümeleri için sorguyu yoğun olmayan saatlerde çalıştırmanız önerilir. İlgili tablolarda ClaimID veya ClaimNumber sütunlarının indekslendiğinden 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';