Hasar Süreçleri Veri Template'inuz
Hasar Süreçleri Veri Template'inuz
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- Guidewire ClaimCenter için Veri Çekme Rehberliği
Hasar Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Aktivite Adı ActivityName | Hasar süreç döngüsünde belirli bir noktada meydana gelen iş aktivitesinin veya olayın 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 sunar. Neden Önemli?dir? 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 sunar. Nereden Alınır?? Bu, genellikle ClaimCenter'daki event tablolarından veya denetim kayıtları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ı | |||
| Claim ID ClaimID | Her bir sigorta hasarı için birincil vaka tanımlayıcısı olarak hizmet eden benzersiz ID. | ||
| Açıklama Hasar ID, hasar süreci analizinin en önemli bileşenidir 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 süreç döngüsüne eksiksiz ve tutarlı bir bakış açısı sunar. Process Mining'de, veri setindeki her olay 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 büyük önem taşır. Neden Önemli?dir? Tüm ilgili olayları birbirine bağlayan temel anahtar olup, tek bir hasarın tüm yolculuğunu takip etmeyi ve analiz etmeyi sunar. Nereden Alınır?? Bu, Guidewire ClaimCenter'da birincil bir büyük önem taşır ve genellikle çekirdek Hasar varlığındaki Claim.ClaimNumber veya benzeri bir alan olarak bulunur. Örnekler::::::: 000-123-45678000-987-65432001-456-11223 | |||
| Olay Zamanı EventTime | Aktivitenin meydana geldiği tam tarih ve saat. | ||
| Açıklama Bu zaman damgası (zaman damgası), bir aktivitenin sisteme kaydedildiği tam anı işaretler. Tüm zaman tabanlı süreç analizi için büyük önem taşır. Tek bir Hasar ID'si için (EventTime)'ın kronolojik sıralaması, süreç akışının yeniden oluşturulmasına sunar. Art arda gelen eventler arasındaki zaman farkı, performans analizi, darboğaz tespiti ve SLA izlemesi için kritik olan döngü süreleriı, bekleme sürelerini ve işlem sürelerini hesaplamak için kullanılır. Neden Önemli?dir? Bu zaman damgası (zaman damgası), eventleri sıralamak, döngü süresi (cycle time) ve süreleri hesaplamak ve süreçteki gecikmeleri belirlemek için gereklidir. 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 büyük önem taşır. 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?dir? 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 sunar. 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?dir? 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 olayınin 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 sunar. 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 stratejik bilgiler, daha özel ve verimli işleme prosedürleri oluşturmaya yardımcı olur. Neden Önemli?dir? 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 sunar. 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ı stratejik bilgiler elde etmek için büyük önem taşır. 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?dir? 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ı sunar. 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ş Zamanı EndTime | Bir aktivitenin tamamlandığını gösteren zaman damgası (zaman damgası)dır. | ||
| Açıklama Bitiş Zamanı, özellikle 'Soruşturma' veya 'Belge İncelemesi' gibi ölçülebilir bir süreye sahip görevler 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 zaman damgası (zaman damgası) ile daha iyi temsil edilir. Bu nitelik, bekleme süresinden farklı olarak aktivite işlem süresinin hassas bir şekilde hesaplanmasına sunar. Farklı adımlar arasındaki uzun gecikmeleri gözlemlemek yerine, hangi belirli görevlerın zaman alıcı olduğunu belirlemeye yardımcı olur. Neden Önemli?dir? 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 kurumsal bir bağlam sunar. Departmana göre analiz yapmak, süreç performansını organizasyonel düzeyde anlamak için büyük önem taşır. 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?dir? Kurumsal bağlam sunar, farklı ekipler arasında performans analizi yapılmasına sunar 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 nitelik, SLA uyumu panelleri ve KPI'ları oluşturmak için büyük önem taşır. 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?dir? 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 metrikleriyle 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 olayın (ö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 stratejik bilgiler sağlayabilir. Neden Önemli?dir? 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 | |||
| 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 yönetişim), veri tutarsızlıklarını giderme (troubleshooting data inconsistencies) ve sürecin teknolojik yapısını anlamak için büyük önem taşır. Bu, temel süreç adımları ile çevre sistemlerden gelen destekleyici aktiviteler arasında ayrım yapmaya yardımcı olur. Neden Önemli?dir? 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 veri çıkarma, dönüştürme ve yükleme (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, süreç döngüsü boyunca birden fazla ödeme içerebilir. Bu, Process Mining bağlamında finansal analiz için büyük önem taşır. 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?dir? Bir hasar içindeki finansal transactionları takip ederek, ödeme değerlerinin ve bunların process aktiviteleri ile ilişkisinin analiz edilmesini sunar. 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 temel rol oynar. 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?dir? 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 açıklar. 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?dir? Belirli sigorta ürünlerine yönelik süreç analizini sunar, 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 sunar. Bu, 'Dosya Kapandı' aktivitesinin zaman damgası (zaman damgası)'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' kontrol paneli'unu doğrudan destekler. Genel SLA uyumluluk oranını belirlemeye yardımcı olur.saplamak ve gecikmelerin nedenlerini derinlemesine incelemek için kolay filtreleme ve toplama imkanı sunar. Neden Önemli?dir? 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 | Verinin kaynak sistemden en son ne zaman yenilendiğini veya çıkarıldığını gösteren zaman damgası (zaman damgası)dır. | ||
| Açıklama Bu özellik, kaynak sistemden en son veri çekiminin (data pull) zaman damgası (zaman damgası)'ini sunar. 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 stratejik bilgilerin operasyonların mevcut durumunu yansıtıp yansıtmadığını veya eski verilere mi dayandığını değerlendirmeye yardımcı olur. Neden Önemli?dir? Verilerin güncelliğini gösterir, böylece kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasını sunar. Nereden Alınır?? Bu değer, ETL süreci sırasında oluşturulur ve saklanır; data load'unun zaman damgası (zaman damgası)ini 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 iyileştirme ya da büyük dosyalar için daha sıkı kontroller uygulama fırsatlarını ortaya çıkarabilir. Neden Önemli?dir? 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ı sunar. 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 güçlüak amacıyla kontrol listelerini ve prosedürleri iyileştirmeye yardımcı olabilir. Neden Önemli?dir? İ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 (uyumluluk izleme) 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ı sunar. 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?dir? Farklı yargı bölgelerinin hasar sürecini etkileyen farklı düzenlemeleri olduğu için uyumluluk analizi için büyük önem taşır. 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 büyük önem taşır. Yeniden İşleme ve Reddetme Sıklığı kontrol paneli'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?dir? 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 vaka için activity dizisinin analiz edilmesiyle hesaplanır. Örnekler::::::: truefalse | |||
Hasar Yönetimi 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?dir? 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 büyük önem taşır. Hasar süreç 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ı (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?dir? Birincil başlangıç olayı olarak bu aktivite, uçtan uca hasar çevrim süresini ölçmek için büyük önem taşır. 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ı (zaman damgası)nı belirleyin. Event tipi explicit | |||
| İ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?dir? Bu kilometre taşı, finansal analiz ve potansiyel sorumluluğun ne kadar hızlı değerlendirildiğini anlamak için temel rol oynar. 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, olayın zaman damgası (zaman damgası)'idir. Yakala Belirli bir hasarın rizikoları için tüm provizyon kalemlerinin minimum oluşturma zaman damgası (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?dir? 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?dir? Bu aktivite, ödeme gönderim sürecinin verimliliğini ölçmek için büyük önem taşır. 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 zaman damgası (zaman damgası)ed event'tir. Yakala Ödeme kaydındaki 'Issued' durum değişikliğinin IssueDate veya zaman damgası (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?dir? Rizikolar, hasar segmentasyonu ve analizi için büyük önem taşır. 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ı (zaman damgası)nı belirleyin. Event tipi explicit | |||
| Talep 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?dir? 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ı (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 | |||
| 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?dir? 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ı (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?dir? 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?dir? 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 büyük önem taşır. 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ı (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?dir? 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?dir? 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 durum değişikliğinden anlaşılır. | ||
| Neden Önemli?dir? 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ı (zaman damgası) olay zamanını belirtir. Yakala Risk durumunun veya sorumluluk durumsü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?dir? 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 Çıkarma 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
-- 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
-- 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
-- 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';