Veri Şablonu: Hasar Süreci

Guidewire ClaimCenter
Veri Şablonu: Hasar Süreci

Hasar Süreçleri Veri Şablonunuz

Hasar süreçlerinizi optimize etmeye yönelik özel kaynağınıza hoş geldiniz. Bu şablon; toplanacak temel veri özniteliklerini, izlenecek kritik aktiviteleri özetler ve veri çıkarma için net yönlendirmeler sunar. Kapsamlı süreç analizi için gerekli tüm bilgileri topladığınızdan emin olmak için kullanın.
  • Toplanması Önerilen Nitelikler
  • İzlenecek anahtar faaliyetler
  • Guidewire ClaimCenter için Veri Çıkarma Rehberi
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Hasar Süreci Özellikleri

Hasar süreçlerinizdeki workflow'ları etkili biçimde analiz edebilmek için eksiksiz bir event log oluştururken bu önerilen veri alanları kritik öneme sahiptir.
3 Gerekli 4 Önerilen 15 İsteğe Bağlı
AdAçıklama
Faaliyet Adı
ActivityName
Hasar dosyasının yaşam döngüsünde belirli bir noktada gerçekleşen iş aktivitesinin veya olayın adı.
Açıklama

Bu özellik, hasar sürecindeki 'Claim Created', 'Investigation Started' veya 'Payment Issued' gibi belirli adım ya da kilometre taşlarını tanımlar. Belirli bir Claim ID için bu aktivitelerin sıralaması süreç akışını oluşturur.

Aktiviteler arasındaki sıralama, sıklık ve sürelerin analiz edilmesi Process Mining'in özüdür. Bu sayede süreç modelleri keşfedilir, darboğazlar belirlenir, yeniden iş döngüleri saptanır ve süreç sapmaları incelenir.

Neden önemli

Sürecin adımlarını tanımlar; süreç haritalarının görselleştirilmesini, akışın ve darboğazların analizini mümkün kılar.

Nereden alınır

Bu, genellikle ClaimCenter'daki event tablolarından veya audit log'larından türetilir; çoğu zaman belirli sistem event'leri ya da durum değişimleri standartlaştırılmış aktivite adlarına eşleştirilerek elde edilir.

Örnekler
Hasar OluşturulduSorumluluk Kararı VerildiÖdeme Emri VerildiHasar Kapatıldı
Hasar ID
ClaimID
Her hasar dosyası için benzersiz tanımlayıcı; temel vaka kimliği olarak kullanılır.
Açıklama

Claim ID, hasar süreci analizinin bel kemiğidir; başvurudan kapanışa kadar her dosyayı benzersiz biçimde tanımlar. İlgili tüm aktiviteleri, belgeleri, ödemeleri ve yazışmaları birbirine bağlayarak dosyanın yaşam döngüsüne eksiksiz ve tutarlı bir bakış sunar.

Process mining'de veri setindeki her olay bir Claim ID ile ilişkilidir; böylece uçtan uca süreç akışı yeniden kurulabilir. Bu, çevrim sürelerini analiz etmek, süreç varyantlarını belirlemek ve dosyanın farklı departmanlar ile hasar uzmanları arasında izlediği yolu takip etmek için kritiktir.

Neden önemli

Tek bir hasarın tüm yolculuğunu izleyip analiz etmeyi mümkün kılan, ilişkili tüm olayları birbirine bağlayan temel anahtardır.

Nereden alınır

Bu, Guidewire ClaimCenter'da bir birincil anahtardır; temel Claim varlığında genellikle Claim.ClaimNumber veya benzeri bir alanda bulunur.

Örnekler
000-123-45678000-987-65432001-456-11223
Olay Zamanı
EventTime
Aktivitenin gerçekleştiği kesin tarih ve saat.
Açıklama

Bu timestamp, bir aktivitenin sisteme kaydedildiği tam anı gösterir. Zaman temelli tüm süreç analizlerinin temelidir.

Tek bir Claim ID için EventTime değerlerinin kronolojik sıralanması, süreç akışının yeniden kurgulanmasına olanak tanır. Ardışık event'ler arasındaki zaman farkı, çevrim süreleri, bekleme süreleri ve işlem sürelerini hesaplamak için kullanılır. Bu metrikler, performans analizi, darboğaz tespiti ve SLA takibi için kritiktir.

Neden önemli

Bu timestamp, event'lerin sıralanması, çevrim ve işlem sürelerinin hesaplanması ve süreçteki gecikmelerin tespiti için kritiktir.

Nereden alınır

Guidewire ClaimCenter'ın geçmiş veya denetim tablolarında, etkinlik ya da aktivite verilerinin yanında, genellikle 'CreateTime' veya 'UpdateTime' alanı olarak bulunur.

Örnekler
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
Assigned Adjuster
AssignedAdjuster
Hasar dosyasını ya da belirli bir aktiviteyi yürütmek üzere atanan kullanıcının adı veya ID'si.
Açıklama

Bu özellik, belirli bir anda dosyadan sorumlu hasar uzmanını belirtir. Bir uzman, tüm dosyaya ya da içindeki belirli görevlere atanabilir.

Atanan hasar uzmanı bazında analiz; iş yükü dengesi, performans yönetimi ve eğitim fırsatlarını belirlemek için kritiktir. 'Hangi uzmanların dosya yükü en yüksek?', 'Uzmanlar arasında performans farklılıkları var mı?' ve 'İş dengeli biçimde dağıtılıyor mu?' gibi sorulara yanıt verir.

Neden önemli

Kullanıcı katılımını izler; iş yükü analizi, performans karşılaştırması ve kaynağa bağlı darboğazların tespitini sağlar.

Nereden alınır

ClaimCenter’da Claim veya Exposure entity’sinde bulunur; genellikle User nesnesine bağlıdır (örn. Claim.Assignee).

Örnekler
j.doem.smiths.jones
Hasar Durumu
ClaimStatus
Olay anındaki dosyanın genel durumu (örn. Open, Closed, Denied).
Açıklama

Bu özellik, dosyanın üst düzey durumunu yansıtır. Temel durumlar 'Open', 'Closed', 'Denied' ve 'Reopened'dır. Dosyanın nihai durumu kritik bir sonuç metriğidir.

Claim Status değişimlerini izlemek, temel süreç kilometre taşlarını ve sonuçlarını tanımlamaya yardımcı olur. Nihai çözümü belirlemek, ret oranlarını hesaplamak ve kapanıştan sonra dosyaların ne sıklıkla yeniden açıldığını analiz etmek için kullanılır; bu da çoğu kez süreç sorunlarına ya da müşteri memnuniyetsizliğine işaret eder.

Neden önemli

Bir hasarın sonucunu gösterir; ret oranlarını, kapanış kalıplarını ve yeniden açılma sıklıklarını analiz etmek için kritiktir.

Nereden alınır

Bu, Claim varlığında temel bir alandır; genellikle 'State' veya 'Status' olarak adlandırılır.

Örnekler
AçıkKapalıReddedildiYeniden Açıldı
Hasar Nedeni
LossCause
Hasar olayının belirli nedeni (örn. Çarpışma, Yangın, Su Hasarı).
Açıklama

Bu özellik, dosyanın neden açıldığını ayrıntılı biçimde açıklar. Kayıp nedeni, gerekli inceleme adımlarını, ihtiyaç duyulan uzmanlıkları ve dosyanın genel karmaşıklığını çoğu zaman belirler.

Hasar Nedeni bazında süreci analiz etmek, gözden kaçan kalıpları ortaya çıkarabilir. Örneğin 'Su Hasarı' ile ilgili dosyalar, 'Hırsızlık' dosyalarına kıyasla daha yüksek yeniden iş oranına sahip olabilir ya da daha fazla uzmanın devreye girmesini gerektirebilir. Bu içgörüler, daha uzmanlaşmış ve verimli yönetim prosedürleri oluşturmayı sağlar.

Neden önemli

Hasarın niteliğine dair bağlam sağlar; farklı kayıp nedenlerinin süreç akışını ve süresini nasıl etkilediğini analiz etmeyi mümkün kılar.

Nereden alınır

Bu, Claim varlığında standart bir alandır; genellikle 'LossCause' olarak adlandırılır.

Örnekler
ÇarpışmaYangınSu HasarıHırsızlık
Hasar Türü
ClaimType
Hasar dosyasının kategorisi (örn. Oto, Mülk, Sorumluluk).
Açıklama

Hasar Türü, bir hasarın iş koluna veya zararın niteliğine göre yapılan temel sınıflandırmadır. Farklı hasar türleri genellikle farklı süreçleri izler, karmaşıklık düzeyleri değişir ve farklı düzenlemelere tabidir.

Süreç analizini Hasar Türü'ne göre bölümlendirmek, anlamlı içgörüler için kritik önemdedir. Bu sayede farklı iş kollarındaki süreç performansını karşılaştırabilir, türe özgü darboğazları belirleyebilir ve her kategoriye uygun süreç iyileştirmelerini tasarlayabilirsiniz.

Neden önemli

Farklı türler (örn. Auto vs. Property) genellikle farklı süreçler izler ve farklı performans hedeflerine sahiptir; hasarları türe göre segmentlemenizi sağlar.

Nereden alınır

ClaimCenter'deki Policy veya Claim varlığından türetilir; genellikle Line of Business (LOB) koduna göre belirlenir.

Örnekler
Bireysel AraçTicari Emlak SigortasıGenel Sorumlulukİşçi Tazminatı
Bitiş Saati
EndTime
Bir aktivitenin ne zaman tamamlandığını gösteren zaman damgası.
Açıklama

End Time, özellikle 'Investigation' veya 'Document Review' gibi ölçülebilir süreye sahip görevlerde, aktivitenin tamamlandığı anı gösterir. Birçok process mining aktivitesi anlıktır (StartTime yeterlidir); ancak belirgin bir başlangıç ve bitişi olan aktiviteler iki zaman damgasıyla daha doğru temsil edilir.

Bu alan, bekleme süresinden farklı olarak aktivitenin işleme süresinin hassas biçimde hesaplanmasını sağlar. Yalnızca adımlar arasındaki gecikmeleri görmek yerine, hangi görevlerin zaman tükettiğini belirlemeye yardımcı olur.

Neden önemli

Bir aktivitenin tamamlanmasının ne kadar sürdüğünü hassas biçimde ölçmeyi sağlar; işlem süresi ile bekleme süresini ayırır.

Nereden alınır

Bunu, aktiviteyi mantıksal olarak sonlandıran bir sonraki event'i bularak türetmek gerekebilir (örneğin, durumun 'In Progress'ten 'Completed'a değişmesi).

Örnekler
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Bölüm
Department
Hasar aktivitesini yürüten sorumlu iş birimi veya departman.
Açıklama

Bu özellik, atanan uzmanın bağlı olduğu departman ya da ekibi (ör. 'Oto Hasar', 'Konut Hasar', 'Özel İnceleme Birimi') belirtir; sürece kurumsal bir çerçeve kazandırır.

Departman bazında analiz, süreci organizasyon düzeyinde anlamak için kritiktir. Departmanlar arası devir gecikmelerini tespit etmeye, ekipler arası verimliliği karşılaştırmaya ve hasar organizasyonu genelinde kaynakları daha etkin tahsis etmeye yardımcı olur.

Neden önemli

Organizasyonel bağlam sağlar; farklı ekipler arası performans analizini mümkün kılar ve birimler arası devir teslim sorunlarını görünür kılar.

Nereden alınır

Bu bilgi genellikle ClaimCenter'da atanan kullanıcı veya grubun profiliyle ilişkilidir.

Örnekler
Auto Claims DivisionMülk Hasar BirimiÖzel Soruşturma Birimi (SIU)
Çözüm Hedef Tarihi
ResolutionTargetDate
İç politikalar veya mevzuata dayalı SLA'lara göre dosyanın sonuçlanmasının beklendiği tarih.
Açıklama

Resolution Target Date, dosyanın kapanması için belirlenen son tarihtir; yargı alanı, dosya türü ve poliçe koşulları gibi faktörlere göre şekillenir. Performans ve uyumu ölçmek için bir referans görevi görür.

Bu alan, SLA uyum dashboard'ları ve KPI'larını oluşturmak için kritiktir. Gerçek 'Claim Closed' tarihi bu hedefle karşılaştırılarak geciken dosyalar otomatik işaretlenir, zamanında tamamlama oranları ölçülür ve hangi dosya türlerinin veya departmanların hedefleri tutturmakta zorlandığı ortaya çıkar.

Neden önemli

Bu, Hizmet Düzeyi Anlaşması (SLA) uyumunu ölçmek ve gecikme riski taşıyan hasar dosyalarını belirlemek için kıyas ölçütüdür.

Nereden alınır

Bu, ClaimCenter'da yapılandırılan iş kurallarına dayanarak türetilmiş veya özel bir alan olabilir; muhtemelen belirli hasar metrikleriyle ilişkilidir.

Örnekler
2023-06-142023-07-202023-08-28
Hasar Tarihi
LossDate
Hasar dosyasını tetikleyen olayın/hasarın gerçekleştiği tarih.
Açıklama

Date of Loss, hasara konu olayın gerçekleştiği tarihi (ör. trafik kazası, mülk hasarı) ifade eder. Bu tarih, dosyanın raporlandığı veya oluşturulduğu tarihten farklıdır.

Date of Loss ile 'Claim Created' aktivitesi arasındaki süre farkı, bildirim gecikmesi (reporting lag) olarak bilinen önemli bir KPI'dır. Bunun analizi, müşteri davranışları ve ilk hasar bildirimi kanallarının etkinliği hakkında içgörüler sağlar.

Neden önemli

Hasarın kaynağı hakkında kritik bağlam sunar ve bildirim gecikmesini (vakadan dosya açılışına kadar geçen süre) analiz etmeye yardımcı olur.

Nereden alınır

Bu, Claim varlığında temel bir tarih alanıdır; çoğunlukla 'LossDate' olarak geçer.

Örnekler
2023-05-102023-04-202023-05-28
İşlem Süresi
ProcessingTime
Bir aktivite üzerinde aktif çalışmaya ayrılan süre.
Açıklama

Processing Time, bir aktivite üzerinde aktif çalışılan süreyi ölçer; End Time ile Start Time arasındaki farktır. Bu metrik, bekleme dönemlerini de içeren çevrim süresinden (cycle time) farklıdır.

Bu hesaplanan metrik, performans analizi için kritiktir; bir görevin gerçek çabasını boşta/bekleme süresinden ayırır. Gerçekte hangi adımların zaman tükettiğini doğru biçimde belirlemenize ve eğitim, daha iyi araçlar veya süreç tasarımıyla nerede verim kazanılabileceğine karar vermenize yardımcı olur.

Neden önemli

Bir aktivitenin aktif çalışma süresini ölçer; katma değerli süre ile bekleme süresini ayırt etmeye yardımcı olur.

Nereden alınır

Hesaplanan alan: EndTime - StartTime. Kaynak veride her iki timestamp’in de bulunmasını gerektirir.

Örnekler
8SPT15MP2D
Kaynak Sistem
SourceSystem
Verilerin çekildiği sistem.
Açıklama

Bu özellik, event verisinin kaynağını belirtir. Güncel kurumsal yapılarda hasarla ilgili event'ler; Guidewire gibi çekirdek bir sistemden, bir doküman yönetim sisteminden veya bir müşteri portalından gelebilir.

Kaynak sistemin belirtilmesi; veri yönetişimi, veri tutarsızlıklarını gidermek ve sürecin teknolojik yapısını anlamak açısından kritiktir. Bu sayede çekirdek süreç adımları ile çevre sistemlerden gelen destekleyici aktiviteler ayrıştırılabilir.

Neden önemli

Verinin kaynağını belirler; bu, veri yönetişimi ve birden fazla entegre sistemi içeren analizler için kritiktir.

Nereden alınır

Bu, genellikle veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde eklenen sabit bir değerdir.

Örnekler
Guidewire ClaimCenter v10Müşteri Portalı API'siDocumentum
Ödeme Tutarı
PaymentAmount
Bir ödeme aktivitesi kapsamında fiilen ödenen tutar.
Açıklama

Bu özellik, bir hasar dosyası için yapılan her bir ödemenin tutarını kaydeder. Tek bir dosyanın yaşam döngüsü boyunca birden fazla ödeme olabilir.

Process Mining bağlamında finansal analiz için kritiktir. Dosya başına toplam ödemeyi izlemek, tutara göre ödeme onay sürelerini analiz etmek ve süreç verimsizliklerini finansal sonuçlarla ilişkilendirmek için kullanılabilir. Örneğin, çevrim süresi uzun olan dosyalar daha yüksek toplam ödemelerle ilişkili olabilir.

Neden önemli

Bir hasar dosyasındaki finansal işlemleri izler; ödeme tutarlarının ve süreç aktiviteleriyle ilişkilerinin analizini mümkün kılar.

Nereden alınır

Hasarla ilişkili ödeme varlıklarında, çoğunlukla bir transaction veya check tablosunda bulunur.

Örnekler
4500.00125000.00500.00
Otomatikleştirildi mi?
IsAutomated
Bir activity’nin sistem tarafından otomatik mi yoksa bir kullanıcı tarafından mı yapıldığını gösteren bir gösterge.
Açıklama

Bu boolean özellik, sistem tarafından yürütülen aktiviteler (örn. otomatik rezerv oluşturma, sistem tarafından üretilen yazışmalar) ile bir uzman tarafından manuel yapılan aktiviteleri ayırt eder.

Bu özelliği analiz etmek, hasar sürecindeki otomasyon düzeyini anlamanın anahtarıdır. Manuel müdahalenin yoğunlaştığı noktaları belirlemeye, uçtan uca otomatik işlem girişimlerinin etkinliğini ölçmeye ve halen insanlar tarafından yapılan tekrarlı, kural tabanlı görevlerde yeni otomasyon fırsatları bulmaya yardımcı olur.

Neden önemli

Sistem tarafından yürütülen ve insan tarafından yürütülen aktiviteleri ayırt eder; bu, otomasyon analizi ve manuel darboğazların tespiti için kritiktir.

Nereden alınır

Bu, çoğu zaman türetilmesi gereken bir bilgidir. Örneğin, genel bir 'system' kullanıcısı tarafından kaydedilen event'ler otomatik olarak işaretlenebilir.

Örnekler
truefalse
Poliçe Türü
PolicyType
Dosyanın bağlı olduğu sigorta poliçesi türü.
Açıklama

Poliçe Türü, Hasar Türü’ne kıyasla daha ayrıntılı bir sınıflandırma sunar; 'Konut', 'Ticari Araç' veya 'Siber Sorumluluk' gibi spesifik sigorta ürününü belirtir. Bu ayrıntı düzeyi, ürüne bağlı süreç farklılıklarını görünür kılabilir.

Süreci Poliçe Türü bazında analiz etmek, ürüne özgü verimsizlikleri ortaya çıkarır. Örneğin, yeni çıkmış bir poliçenin hasarları daha olgunlaşmamış bir süreçten geçtiği için gecikebilir. Bu içgörüler, ürün tasarımını ve süreç standartlaştırma çalışmalarını besleyebilir.

Neden önemli

Belirli sigorta ürünleri için süreç analizi yapmayı sağlar; poliçe detaylarına bağlı işleyiş farklarını ortaya çıkarır.

Nereden alınır

Bu bilgi, Claim ile ilişkili Policy varlığında bulunur.

Örnekler
Konut Paket SigortasıTicari Araç Sorumluluk SigortasıNakliyat Sigortası
SLA Durumu
SLAState
Hasarın hedeflenen çözüm tarihine uygun şekilde kapanıp kapanmadığını gösterir.
Açıklama

Bu hesaplanmış özellik, kapanmış her dosya için SLA uyumunun kategorik durumunu sağlar. 'Claim Closed' aktivitesinin timestamp'i ile 'Resolution Target Date' karşılaştırılarak türetilir.

Bu özellik, analizi 'Zamanında' veya 'Geç' gibi net kategorilere indirerek 'Hasar Çözüm Hedefine Uyum' dashboard'unu doğrudan destekler. Genel SLA uyum oranını hesaplamak ve gecikmelerin nedenlerine derinlemesine inmek için kolayca filtreleme ve toplulaştırma yapılmasına imkan tanır.

Neden önemli

SLA uyumu için net, kategorik bir sonuç sağlar; zamanında performansı filtrelemeyi, toplamayı ve analiz etmeyi kolaylaştırır.

Nereden alınır

Hesaplanan alan: IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late').

Örnekler
ZamanındaGecikmiş
Son Veri Güncelleme
LastDataUpdate
Verinin kaynak sistemden en son ne zaman güncellendiğini ya da çekildiğini gösteren zaman damgası.
Açıklama

Bu özellik, kaynak sistemden yapılan en son veri çekiminin timestamp'ini içerir. Analizin güncelliğini anlamak için gerekli bir metadata alanıdır.

Dashboard ve analizlerde bu bilginin görünür biçimde yer alması, kullanıcıların verinin güncelliğinin farkında olmasını sağlar. Bu sayede içgörülerin operasyonların mevcut durumunu yansıtıp yansıtmadığını değerlendirmek mümkün olur.

Neden önemli

Verinin ne kadar güncel olduğunu gösterir; böylece kullanıcılar süreç analizinin güncelliğini anlayabilir.

Nereden alınır

Bu değer, ETL sürecinde üretilir ve saklanır; veri yüklemesinin timestamp'ini temsil eder.

Örnekler
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
Talep Edilen Tutar
ClaimedAmount
Sigortalı tarafından başlangıçta talep edilen toplam parasal tutar.
Açıklama

Bu özellik, hak sahibi tarafından bildirilen kayıp tutarını ifade eder. İnceleme ilerledikçe ve rezervler (karşılıklar) ayrıldıkça bu ilk tahmin değişebilir.

Claimed Amount'u analiz etmek, dosyaları finansal etkiye göre segmentlere ayırmaya yardımcı olur. Yüksek tutarlı dosyalar genellikle düşük tutarlılara kıyasla daha sıkı ve daha karmaşık bir süreç izler. Farklı tutar bantlarındaki süreçleri karşılaştırmak, küçük dosyalar için süreci sadeleştirme ya da büyük dosyalar için daha sıkı kontroller uygulama fırsatlarını ortaya çıkarabilir.

Neden önemli

Hasarları finansal tutarlarına göre segmentlemenizi sağlar; yüksek tutarlı hasarlar daha farklı ve karmaşık süreçleri izleyebilir.

Nereden alınır

Bu bilgi tek bir alan olmayabilir; Exposure kayıtlarına girilen ilk hasar tahminlerinden türetilebilir.

Örnekler
5000.00150000.00750.50
Tekrarlanan Bilgi Talebi
RepeatedInfoRequestFlag
Aynı claim için 'Additional Info Requested' aktivitesinin birden fazla kez gerçekleşip gerçekleşmediğini gösteren bir gösterge.
Açıklama

Bu boolean bayrak, bir dosyada birden fazla 'Additional Info Requested' aktivitesi varsa true olarak işaretlenir. Bu durum çoğu kez ilk bilgi toplama aşamasındaki verimsizliklere işaret eder.

Bu özellik, 'Repeated Info Request Rate' KPI'sını doğrudan destekler. Eksik ön inceleme sorununu nicel olarak ortaya koyar; bu durum ciddi gecikmelere ve müşteri memnuniyetsizliğine yol açabilir. Bu bayrağa sahip dosyaları analiz etmek, tüm gerekli bilgilerin tek seferde istenmesini sağlamak için uzmanların kontrol listelerini ve prosedürlerini iyileştirmeye yardımcı olur.

Neden önemli

Bilgi toplamanın ilk seferde eksiksiz yapılmadığı durumları tespit eder; bu da süreçte gecikmelere ve yeniden işlemeye yol açar.

Nereden alınır

Her dosya için 'Additional Info Requested' aktivitesinin sayısı temel alınarak process mining aracında hesaplanır.

Örnekler
truefalse
Yargı Bölgesi (Eyalet)
JurisdictionState
Dosyanın tabi olduğu eyalet/yargı alanı; ilgili düzenleyici gereklilikleri belirler.
Açıklama

Bu özellik, dosyanın işlem gördüğü hukuki yetki alanını (örn. ABD eyaleti) belirtir. Sigorta mevzuatı, yetki alanına göre ciddi farklılık gösterebilir; bu da gerekli süreç adımlarını, iletişim sürelerini ve dokümantasyonu etkiler.

Uyum takibi için hayati bir özelliktir. Süreci yetki alanına göre analiz etmek, eyalete özgü düzenleyici gerekliliklerin karşılandığından emin olmayı sağlar. Ayrıca çevrim süreleri veya süreç yollarındaki farklılıkların, operasyonel verimsizlikten ziyade hukuki kısıtlamalardan kaynaklandığını açıklayabilir.

Neden önemli

Uyum analizi için kritiktir; çünkü farklı yargı bölgelerinde hasar sürecini etkileyen farklı düzenlemeler bulunur.

Nereden alınır

Claim entity’sinde bulunan standart bir alan; genellikle 'JurisdictionState' olarak adlandırılır.

Örnekler
CANYTXFL
Yeniden İşleme mi?
IsRework
Bir activity’nin rework (yeniden çalışma) döngüsü olup olmadığını, yani sürecin önceki bir aşamasına dönüşü gösteren bir gösterge.
Açıklama

Bu hesaplanmış özellik, yeniden iş döngüsünün parçası olan aktiviteleri işaretler. Örneğin süreç 'Investigation Completed'dan 'Investigation Started'a geri dönüyorsa, ikinci 'Investigation Started' aktivitesi yeniden iş olarak işaretlenir.

Yeniden işi belirlemek, süreç verimsizliklerini ve kalite sorunlarını açığa çıkarmanın temelidir. 'Rework and Rejection Frequency' dashboard'u, dosyaların ideal akıştan ('happy path') ne sıklıkla saptığını nicel olarak ölçmek için bu metrikten yararlanır. Yeniden işin nedenlerini analiz etmek, süreç kalitesi ve hızında ciddi iyileşmelere yol açabilir.

Neden önemli

Yeniden işlem döngüsünün parçası olan aktiviteleri açıkça işaretleyerek süreçteki verimsizlik ve kalite sorunlarını görünür kılar.

Nereden alınır

Bu, her case için aktivitelerin sıralaması analiz edilerek Process Mining aracında hesaplanır.

Örnekler
truefalse
Gerekli Önerilen İsteğe Bağlı

Hasar Süreci Aktiviteleri

Hasar süreçlerini doğru keşfetmek ve analiz etmek için event log'unuza dahil etmeniz gereken başlıca süreç adımları ve önemli kilometre taşları bunlardır.
7 Önerilen 7 İsteğe Bağlı
AktiviteAçıklama
Hasar Kalemi Oluşturuldu
Bu aktivite, bir hasar altında belirli bir potansiyel sorumluluğu ya da kayıp türünü (örn. araç hasarı, yaralanma) temsil eden bir hasar kaleminin (exposure) oluşturulduğunu gösterir. Guidewire'da açıkça kaydedilen bir olaydır.
Neden önemli

Hasar kalemleri, hasar segmentasyonu ve analizin temelidir. Oluşturulmalarını izlemek; hasarın karmaşıklığı ve hasar türüne göre süreç farklılıklarını anlamaya yardımcı olur.

Nereden alınır

cc_exposure tablosunda oluşturulan yeni bir kaydın CreateTime alanından alınır. Her kayıt tek bir Claim ID ile ilişkilidir.

Yakala

Exposure entity tablosunda yeni bir kaydın oluşturulma timestamp’ini belirleyin.

Event tipi explicit
Hasar Kapatıldı
Tüm aktiviteler ve ödemeler tamamlandıktan sonra hasar dosyasının başarıyla kapatıldığını işaretler. Bu, dosyanın ana statüsündeki değişimden türetilen birincil başarılı bitiş olayıdır.
Neden önemli

Birincil bitiş event’i olduğundan, uçtan uca çevrim süresinin hesaplanması ve SLA uyumunun ölçülmesi için kritiktir. Hasar yaşam döngüsünün tamamlandığını ifade eder.

Nereden alınır

cc_claim tablosundaki State alanının 'Closed' olarak değişmesinden çıkarım yapılır. Olayın timestamp’i, hasar kaydındaki CloseDate’dir.

Yakala

Hasarın ana durum alanının 'Closed' olarak güncellendiği zamanı tespit edin.

Event tipi inferred
Hasar Oluşturuldu
Bu aktivite, İlk Hasar Bildiriminin (FNOL) alındığını ve Guidewire ClaimCenter'da yeni bir hasar dosyasının resmi olarak oluşturulduğunu gösterir. Yeni bir Claim kaydı veritabanına ilk kez yazıldığında bu durum açık bir olay olarak kaydedilir.
Neden önemli

Birincil başlangıç event’i olduğundan, hasarın uçtan uca çevrim süresini ölçmek için gereklidir. Tüm performans ve süre KPI’ları için bir başlangıç referansı sağlar.

Nereden alınır

Bu, cc_claim tablosunun CreateTime alanından yakalanan açık bir event'tir. Benzersiz bir Claim ID ile yeni bir kaydın oluşturulması event tetikleyicisidir.

Yakala

Temel Claim entity tablosundaki yeni kaydın oluşturulma timestamp’ini belirleyin.

Event tipi explicit
Hasar Reddedildi
Bir hasar dosyasının reddine ilişkin nihai kararı ifade eder ve sürecin son noktasını temsil eder. Bu olay, dosyanın durumunun gerekçe 'Denied' olacak şekilde 'Closed' olmasına bakılarak anlaşılır.
Neden önemli

Bu, kritik bir sonuç event'idir. Reddin sıklığını, nedenlerini ve reddiyle sonuçlanan süreç yollarını analiz etmek; hasar bildirimi, soruşturma veya poliçe yorumlamasındaki sorunları belirlemeye yardımcı olur.

Nereden alınır

cc_claim tablosundaki State alanının 'Closed' değerine değişmesi ve CloseReason alanının 'Denied' veya benzeri bir değer olmasıyla çıkarım yapılır. Olayın timestamp’i CloseDate’dir.

Yakala

Gerekçe kodunun ret belirttiği ve hasar durumunun 'Closed' olarak değiştiği kayıtları filtreleyin.

Event tipi inferred
İlk Karşılık Ayrıldı
Bir hasar kalemi (Exposure) için ilk finansal karşılık işleminin oluşturulduğunu işaretler ve hasarın muhtemel maliyetini tahmin eder. Bu, kritik bir finansal olaydır ve açık biçimde kaydedilir.
Neden önemli

Bu kilometre taşı, finansal analiz ve potansiyel yükümlülüğün ne kadar hızlı değerlendirildiğini anlamak için kritiktir. Gecikmeler finansal planlama ve raporlamayı etkileyebilir.

Nereden alınır

Bu event, dosyadaki bir hasar kalemiyle ilişkili ilk cc_reserveline kaydının oluşturulmasından yakalanır. İşlemin CreateTime değeri event timestamp'idir.

Yakala

Belirli bir hasarın tüm hasar kalemlerindeki muallak satırlarının en düşük oluşturulma zaman damgasını bulun.

Event tipi explicit
Ödeme Emri Verildi
Bu aktivite, ödeme sürecinin son adımını gösterir; ödeme resmi olarak oluşturulur ve finansal sisteme gönderilir. Bu, sistemde açıkça kaydı bulunan bir finansal işlemdir.
Neden önemli

Bu aktivite, ödeme çıkışı sürecinin verimliliğini ölçmek için kritiktir. Onay gecikmeleri ile ödemenin fiilen yapılmasındaki gecikmeleri ayırt etmeye yardımcı olur.

Nereden alınır

cc_check veya cc_transaction kaydındaki IssueDate alanından ya da durumun 'Issued' veya 'Submitted' olarak değişmesinden alınır. Bu genellikle açıkça zaman damgalı bir olaydır.

Yakala

Ödeme kaydında IssueDate alanını ya da durumunun 'Issued' olarak değiştiği anın timestamp’ini belirleyin.

Event tipi explicit
Ödeme Onaylandı
Tazminat ödemesinin resmi onayını ifade eder. Bu, kritik bir denetim olayıdır ve yetkili bir kullanıcı işlemi onayladığında açıkça kaydedilir.
Neden önemli

Bu kritik kilometre taşı, nihai ödeme adımının önünü açar. Bu aktiviteden önceki ve sonraki süreyi analiz etmek, onay workflow'larından veya yöneticilerin uygunluğundan kaynaklanan gecikmeleri ayırt etmeye yardımcı olur.

Nereden alınır

Bu, çoğunlukla cc_check veya cc_transaction varlığıyla ilişkili olarak cc_history tablosuna yazılan açık bir event'tir; durumun 'Pending Approval'dan 'Approved'a değişmesini kaydeder.

Yakala

Belirli bir ödeme işlemi için durumun 'Approved'a değiştiği event'i izleyin.

Event tipi explicit
Additional Info Received
Ek bilgi talebinin tamamlandığını işaretler. Bu, ilgili bilgi talebi 'Activity' (görev) kaydı 'Completed' olarak işaretlendiğinde kaydedilir.
Neden önemli

Bu, 'Additional Info Gathering Cycle Time' KPI'nin bitiş noktasıdır. Talep ile bilgi alımı arasında geçen uzun süreler, hasar sürecindeki gecikmelerin yaygın bir nedenidir.

Nereden alınır

ActivityPattern değeri bilgi talebini ifade eden cc_activity kaydındaki CloseTime alanından alınır. Aktivitenin durumu 'Completed' olmalıdır.

Yakala

Dış bilgi talebi için açılan bir görevin tamamlanma timestamp’ini belirleyin.

Event tipi explicit
Additional Info Requested
Talep sahibinden veya üçüncü bir taraftan ek bilgi ya da belge istemeyi ifade eder. Bu genellikle ClaimCenter'da oluşturulan ayrı bir 'Activity' (task) olarak kayda alınır.
Neden önemli

Bu aktivite, 'Additional Info Gathering Cycle Time' KPI'sinin ölçümünde başlangıç noktasıdır. Sık gerçekleşmesi, FNOL (İlk Hasar Bildirimi) sürecinin eksik kaldığına veya bilgi toplamanın verimsiz ilerlediğine işaret edebilir.

Nereden alınır

ActivityPattern dış taraflardan doküman/bilgi talebiyle ilişkili olan cc_activity kaydının CreateTime alanından alınır.

Yakala

Dış bilgi talebi için bir görevin oluşturulduğunu tespit edin.

Event tipi explicit
Hasar Atandı
Bir hasar dosyasının işlenmesi için belirli bir kullanıcıya (hasar uzmanı) veya gruba atanmasını ifade eder. Bu olay genellikle Claim nesnesindeki atama alanlarındaki değişiklikler izlenerek anlaşılır.
Neden önemli

Atamaların izlenmesi; hasar uzmanlarının iş yükünü analiz etmek, yönlendirme darboğazlarını belirlemek ve atanan kişinin ilk aksiyona kadar geçen süresini ölçmek için kritiktir.

Nereden alınır

Bu olay, cc_history tablosunda belirli bir Claim ID ile ilişkili AssignedUser veya AssignedGroup alanlarındaki değişikliklerin izlenmesiyle çıkarılır. Değişikliğin timestamp’i olayın gerçekleştiği anı gösterir.

Yakala

Hasar atama alanlarındaki güncellemeler için denetim kayıtlarını veya geçmiş tablolarını izleyin.

Event tipi inferred
Hasar Yeniden Açıldı
Ek çalışma yapmak üzere bir hasar dosyasının 'Closed' durumundan tekrar 'Open' durumuna alındığını ifade eder. Bu olay, belirli bir durum değişikliği dizisinden türetilir.
Neden önemli

Bu aktivite, yeniden iş yapıldığını gösterir. Yeniden açılan hasar dosyalarının yüksek olması, ilk ödeme kararında sorunlar, atlanan hasarlar veya diğer süreç hatalarına işaret eder; maliyetleri artırır ve verimsizliğe yol açar.

Nereden alınır

Bu olay, cc_history tablosunda cc_claim entity’sinin State alanının 'Closed'dan yeniden 'Open' veya başka bir aktif duruma değiştiğinin tespit edilmesiyle çıkarılır.

Yakala

Dosyanın ana durum alanında kapalı durumdan açık duruma geçişi izleyin.

Event tipi inferred
İnceleme Başladı
Bir hasar veya exposure için inceleme aşamasının resmen başladığını gösterir. Bu genellikle Guidewire’da incelemeyle ilgili ilk 'Activity' (task) kaydının oluşturulmasından anlaşılır.
Neden önemli

Bu aktivite, çoğu zaman uzun süren kritik bir aşamanın başlangıcıdır. İncelemenin ne kadar sürede başlatıldığını ve incelemenin süresini analiz etmek, başlıca darboğazları ortaya çıkarır.

Nereden alınır

ActivityPattern değeri incelemeyle ilişkili olan (ör. 'Initial Investigation', 'Contact Witness') bir cc_activity kaydının CreateTime alanından çıkarım yapılır.

Yakala

İncelemeyle ilgili bir pattern ya da konuya sahip bir görevin ilk kez oluşturulduğunu tespit edin.

Event tipi inferred
Sorumluluk Kararı Verildi
Bir Exposure için sorumluluk veya kusur kararının verildiği anı ifade eder. Bu olay genellikle Exposure nesnesindeki durum değişiminden anlaşılır.
Neden önemli

Bu, sonuçlandırma ve ödeme aşamalarının önünü açan kritik bir karar eşiğidir. Bu karara kadar geçen süreyi analiz etmek, soruşturma ve değerlendirme aşamalarındaki darboğazları ortaya çıkarır.

Nereden alınır

Bu olay, cc_history tablosunda cc_exposure entity’sindeki State ya da özelleştirilmiş sorumluluk durum alanındaki değişim izlenerek çıkarılır. Geçmiş kaydının timestamp’i olay zamanını gösterir.

Yakala

Hasar kaleminin durumuna veya sorumluluk statüsüne yönelik güncellemeler için denetim kayıtlarını ya da geçmiş tablolarını izleyin.

Event tipi inferred
Tazminat Hesaplandı
Bu aktivite, tazminat tutarının belirlendiğini ancak ödemenin henüz onaylanmadığını gösterir. 'Pending Approval' durumunda bir ödeme kaydı oluşturulmasından anlaşılabilir.
Neden önemli

Değerlendirmeden ödemeye geçişi işaretler. Onay zincirindeki gecikmeleri ortaya çıkaran 'Payment Authorization Lead Time' KPI’ının ölçüm başlangıç noktasıdır.

Nereden alınır

İlk durumu 'Pending Approval' ya da 'Approved' öncesi benzer bir durumda olan cc_check veya cc_transaction kaydının CreateTime değerinden çıkarım yapılır.

Yakala

Ön onay durumunda bir ödeme veya işlem kaydının oluşturulmasını tespit edin.

Event tipi inferred
Önerilen İsteğe Bağlı

Çıkarma Rehberleri

Guidewire ClaimCenter’dan verinizi nasıl alırsınız