Hasar taleplerinin işlenmesi için Veri Templateiniz

Guidewire ClaimCenter
Hasar taleplerinin işlenmesi için Veri Templateiniz

Hasar taleplerinin işlenmesi için Veri Templateiniz

Hasar taleplerinin işlenmesini iyileştirmeye yönelik kaynağınıza hoş geldiniz. Bu Template, toplanması gereken temel veri özniteliklerini ve izlenecek önemli etkinlikleri açıklar; ayrıca verilerin nasıl çıkarılacağı konusunda net yönergeler sunar. Süreç analizi için gereken tüm bilgileri topladığınızdan emin olmak üzere bu Templateten yararlanın.
  • Toplanması önerilen öznitelikler
  • İzlenecek temel etkinlikler
  • Guidewire ClaimCenter için veri çıkarma yönergeleri
Olay günlüklerine yeni misiniz? Process Mining için nasıl Event Log oluşturacağınızı öğrenin.

Hasar taleplerinin işlenmesine ilişkin öznitelikler

Önerilen bu veri alanları, hasar taleplerinin iş akışlarını etkili biçimde analiz edebilmek için eksiksiz bir Event Log oluştururken büyük önem taşır.
3 Zorunlu 4 Önerilen 14 İsteğe bağlı
Ad Açıklama
Etkinlik adı
ActivityName
Hasar yaşam döngüsünün belirli bir aşamasında gerçekleşen iş faaliyetinin veya olayın adı.
Açıklama

Bu öznitelik, hasar sürecindeki Hasar Oluşturuldu, İnceleme Başlatıldı veya Ödeme Yapıldı gibi belirli bir adımı ya da kilometre taşını tanımlar. Belirli bir Hasar kimliği için bu faaliyetlerin sıralaması süreç akışını oluşturur.

Faaliyetlerin sırasını, sıklığını ve aralarındaki süreyi analiz etmek, Process Mining çalışmalarının temelini oluşturur. Bu analiz, süreç modellerini ortaya çıkarmaya, darboğazları belirlemeye, yeniden çalışma döngülerini saptamaya ve süreç sapmalarını incelemeye yardımcı olur.

Neden önemli?

Süreç adımlarını tanımlar; süreç haritalarını görselleştirmenizi, süreç akışını incelemenizi ve darboğazları belirlemenizi sağlar.

Nereden alınır?

Bu bilgi genellikle ClaimCenter’daki olay tablolarından veya denetim günlüklerinden elde edilir. Bunun için belirli sistem olayları ya da durum değişiklikleri standart faaliyet adlarıyla eşleştirilir.

Örnekler
Hasar dosyası oluşturulduSorumluluk kararı verildiÖdeme gönderildiHasar dosyası kapatıldı
Hasar kimliği
ClaimID
Her sigorta hasar dosyasını benzersiz biçimde tanımlayan ve ana vaka tanımlayıcısı olarak kullanılan kimlik.
Açıklama

Hasar kimliği, her dosyayı başvurudan kapanışa kadar benzersiz biçimde tanımlayarak hasar süreci analizinin temelini oluşturur. İlişkili tüm etkinlikleri, belgeleri, ödemeleri ve iletişimleri birbirine bağlar; böylece hasar dosyasının yaşam döngüsünü eksiksiz ve tutarlı biçimde görmenizi sağlar.

Process Mining’de Veri Setindeki her olay bir hasar kimliğine bağlanır. Bu sayede süreç akışı baştan sona yeniden oluşturulabilir. Bu, çevrim sürelerini analiz etmek, süreç farklılıklarını belirlemek ve bir hasar dosyasının farklı departmanlar ile eksperler arasındaki ilerleyişini izlemek için gereklidir.

Neden önemli?

İlişkili tüm olayları birbirine bağlayan temel anahtardır; tek bir hasar dosyasının tüm sürecini izleyip analiz etmenizi sağlar.

Nereden alınır?

Guidewire ClaimCenter’da bu, genellikle Claim temel varlığındaki Claim.ClaimNumber alanı veya benzer bir alandır.

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

Bu zaman damgası, bir faaliyetin sisteme kaydedildiği kesin anı gösterir. Zamana dayalı tüm süreç analizlerinin temelini oluşturur.

Tek bir Hasar kimliğine ait EventTime değerlerini kronolojik olarak sıralayarak süreç akışını yeniden oluşturabilirsiniz. Ardışık olaylar arasındaki süre; çevrim süresini, bekleme süresini ve işlem süresini hesaplamak için kullanılır. Bu değerler performans analizinde, darboğazların belirlenmesinde ve SLA takibinde önem taşır.

Neden önemli?

Olayları sıralamak, çevrim sürelerini ve süreleri hesaplamak, süreçteki gecikmeleri belirlemek için gereklidir.

Nereden alınır?

Guidewire ClaimCenter’ın geçmiş veya denetim tablolarında olay ya da faaliyet verileriyle birlikte bulunur. Genellikle CreateTime veya UpdateTime alanı olarak yer alır.

Örnekler
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
Atanan hasar uzmanı
AssignedAdjuster
Hasarı veya belirli bir faaliyeti yürütmekle görevlendirilen kullanıcının adı ya da kimliği.
Açıklama

Bu öznitelik, belirli bir zamanda hasardan sorumlu olan hasar uzmanını belirtir. Uzman, hasarın tamamına veya hasar kapsamındaki belirli görevlere atanabilir.

Atanan hasar uzmanına göre analiz yapmak; iş yükünü dengelemek, performansı yönetmek ve eğitim ihtiyaçlarını belirlemek açısından önemlidir. Hangi uzmanların en fazla dosyaya baktığı, uzmanlar arasında performans farkı olup olmadığı ve işlerin eşit dağıtılıp dağıtılmadığı gibi soruları yanıtlamaya yardımcı olur.

Neden önemli?

Kullanıcıların sürece katılımını izler; iş yükü analizini, performans karşılaştırmasını ve kaynaklarla ilgili darboğazların belirlenmesini sağlar.

Nereden alınır?

ClaimCenter’daki Claim veya Exposure varlığında bulunur ve genellikle User nesnesine bağlıdır. Örneğin, Claim.Assignee.

Örnekler
j.doem.smiths.jones
Hasar durumu
ClaimStatus
Olayın gerçekleştiği andaki genel hasar durumu. Örneğin, Açık, Kapalı veya Reddedildi.
Açıklama

Bu öznitelik, hasarın genel durumunu gösterir. Başlıca durumlar Açık, Kapalı, Reddedildi ve Yeniden Açıldı’dır. Hasarın son durumu, sonuçları değerlendirmek için kullanılan önemli bir metriktir.

Hasar durumundaki değişiklikleri izlemek, temel süreç aşamalarını ve sonuçlarını tanımlamaya yardımcı olur. Hasarın nasıl sonuçlandığını belirlemek, ret oranlarını hesaplamak ve kapatıldıktan sonra yeniden açılan hasarların sıklığını incelemek için kullanılır. Yeniden açılma, çoğu zaman süreç sorunlarına veya müşteri memnuniyetsizliğine işaret eder.

Neden önemli?

Hasarın sonucunu gösterir; ret oranlarını, kapanış örüntülerini ve yeniden açılma sıklığını analiz etmeyi sağlar.

Nereden alınır?

Claim varlığındaki temel bir alandır; genellikle State veya Status olarak adlandırılır.

Örnekler
AçıkKapalıReddedildiYeniden açıldı
Hasar nedeni
LossCause
Kayba yol açan olayın belirli nedeni. Örneğin, çarpışma, yangın veya su hasarı.
Açıklama

Bu öznitelik, hasar talebinin neden yapıldığına ilişkin ayrıntılı bağlam sunar. Hasarın nedeni; gerekli inceleme adımlarını, ihtiyaç duyulan uzmanları ve hasarın genel karmaşıklığını belirleyebilir.

Süreci hasar nedenine göre analiz etmek, gizli örüntüleri ortaya çıkarabilir. Örneğin, Su Hasarı hasarlarında yeniden çalışma oranı daha yüksek olabilir veya Hırsızlık hasarlarına kıyasla daha fazla uzman desteği gerekebilir. Bu içgörüler, daha uzmanlaşmış ve verimli işlem prosedürleri oluşturmanıza yardımcı olur.

Neden önemli?

Hasarın niteliği hakkında bağlam sunar; farklı hasar nedenlerinin süreç akışını ve süresini nasıl etkilediğini analiz etmenizi sağlar.

Nereden alınır?

Claim varlığındaki standart bir alandır; genellikle LossCause olarak adlandırılır.

Örnekler
ÇarpışmaYangınSu hasarıHırsızlık
Hasar türü
ClaimType
Oto, Konut veya Sorumluluk gibi sigorta hasarının kategorisi.
Açıklama

Hasar türü, hasarı iş koluna veya kaybın niteliğine göre sınıflandırır. Farklı hasar türleri genellikle farklı süreçlerden geçer, farklı karmaşıklık düzeylerine sahiptir ve farklı düzenlemelere tabidir.

Anlamlı içgörüler elde etmek için süreç analizini hasar türüne göre bölümlere ayırmak gerekir. Böylece farklı iş kollarındaki süreç performansını karşılaştırabilir, belirli hasar türlerine özgü darboğazları bulabilir ve süreç iyileştirme çalışmalarını her kategorinin özelliklerine göre şekillendirebilirsiniz.

Neden önemli?

Hasarları türlerine göre ayırmanızı sağlar. Örneğin, Oto ve Konut hasarları farklı süreçlerden geçebilir ve farklı performans hedeflerine sahip olabilir.

Nereden alınır?

ClaimCenter’daki Policy veya Claim varlığından, genellikle İş Kolu (LOB) koduna göre elde edilir.

Örnekler
Bireysel OtoTicari MülkGenel Sorumlulukİşçi Tazminatı
Bitiş zamanı
EndTime
Bir faaliyetin tamamlandığı zamanı gösteren zaman damgası.
Açıklama

Bitiş zamanı, özellikle İnceleme veya Belge İncelemesi gibi ölçülebilir bir süresi olan görevlerin tamamlandığı anı gösterir. Process Mining çalışmalarındaki birçok faaliyet anlık gerçekleştiğinden yalnızca Başlangıç zamanı yeterlidir. Ancak başlangıç ve bitiş zamanı belirgin olan faaliyetleri iki zaman damgasıyla göstermek daha doğru olur.

Bu öznitelik, bekleme süresinden ayrı olarak faaliyetin işlem süresini hassas biçimde hesaplamanızı sağlar. Böylece farklı adımlar arasındaki uzun gecikmelere bakmakla kalmaz, hangi görevlerin zaman aldığını da belirleyebilirsiniz.

Neden önemli?

Bir faaliyetin ne kadar sürede tamamlandığını hassas biçimde ölçmenizi ve işlem süresini bekleme süresinden ayırmanızı sağlar.

Nereden alınır?

Bu değer, faaliyeti mantıksal olarak tamamlayan sonraki bir olay bulunarak elde edilebilir. Örneğin, durumun Devam Ediyor’dan Tamamlandı’ya geçmesi.

Örnekler
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Çözüm hedef tarihi
ResolutionTargetDate
Hasarın kurum içi veya düzenleyici SLA’lara göre çözüme kavuşturulmasının beklendiği tarih.
Açıklama

Çözüm hedef tarihi, hasarın kapatılması için belirlenen son tarihtir. Bu tarih genellikle yargı bölgesi, hasar türü ve poliçe koşulları gibi etkenlere göre belirlenir. Performansı ve uyumluluğu ölçmek için bir referans noktası sunar.

Bu öznitelik, SLA uyumluluğunu izleyen Dashboardlar ve KPI’lar oluşturmak için önemlidir. Gerçek Hasar Kapatıldı tarihini hedef tarihle karşılaştırarak geciken hasarları otomatik olarak işaretleyebilir, zamanında tamamlanma oranlarını ölçebilir ve hedefleri karşılamakta zorlanan hasar türlerini veya departmanları belirleyebilirsiniz.

Neden önemli?

Hizmet Düzeyi Anlaşması (SLA) uyumluluğunu ölçmek ve gecikme riski taşıyan hasarları belirlemek için referans noktasıdır.

Nereden alınır?

Bu, özel bir alan olabilir veya ClaimCenter’da tanımlanan iş kurallarına, muhtemelen belirli hasar metriklerine göre hesaplanabilir.

Örnekler
2023-06-142023-07-202023-08-28
Departman
Department
Hasar faaliyetini yürütmekten sorumlu iş birimi veya departman.
Açıklama

Bu öznitelik, atanan hasar uzmanının bağlı olduğu departmanı veya ekibi belirtir. Örneğin, Oto Hasarları, Konut Hasarları veya Özel İncelemeler Birimi. Sürece kurumsal bir bağlam kazandırır.

Departmana göre analiz yapmak, süreç performansını kuruluş genelinde anlamak açısından önemlidir. Departmanlar arasındaki devir teslim gecikmelerini belirlemeye, ekiplerin verimliliğini karşılaştırmaya ve hasar kuruluşundaki kaynakları daha etkili dağıtmaya yardımcı olur.

Neden önemli?

Kurumsal bağlam sunarak farklı ekiplerin performansını analiz etmenizi ve departmanlar arasındaki devir teslim sorunlarını belirlemenizi sağlar.

Nereden alınır?

Bu bilgi genellikle ClaimCenter’da atanan kullanıcının veya grubun profiliyle ilişkilendirilir.

Örnekler
Oto Hasarları BölümüKonut Hasarları BirimiÖzel İncelemeler Birimi (SIU)
Hasar tarihi
LossDate
Hasar talebine yol açan olayın veya kaybın gerçekleştiği tarih.
Açıklama

Hasar tarihi, talebe konu olan gerçek olayın gerçekleştiği tarihtir. Örneğin, trafik kazasının veya mülk hasarının yaşandığı gün. Hasarın bildirildiği ya da oluşturulduğu tarihten farklıdır.

Hasar tarihi ile Hasar Oluşturuldu faaliyeti arasındaki süre, bildirim gecikmesi olarak bilinir ve önemli bir KPI’dır. Bu süreyi analiz etmek, müşteri davranışını ve ilk hasar bildirimi kanallarının etkinliğini anlamaya yardımcı olur.

Neden önemli?

Hasarın kaynağı hakkında önemli bağlam sunar ve olay ile hasar bildirimi arasındaki süreyi analiz etmeye yardımcı olur.

Nereden alınır?

Claim varlığındaki temel bir tarih alanıdır; genellikle LossDate olarak adlandırılır.

Örnekler
2023-05-102023-04-202023-05-28
Kaynak sistem
SourceSystem
Verilerin alındığı sistem.
Açıklama

Bu öznitelik, olay verilerinin kaynağını belirtir. Günümüz kuruluşlarında hasarla ilgili olaylar Guidewire gibi temel sistemlerden, belge yönetim sistemlerinden veya müşteri portallarından gelebilir.

Kaynak sistemi belirtmek; veri yönetişimi, veri tutarsızlıklarını giderme ve sürecin teknolojik altyapısını anlama açısından önemlidir. Temel süreç adımlarını, çevre sistemlerdeki destekleyici faaliyetlerden ayırmaya yardımcı olur.

Neden önemli?

Verilerin kaynağını belirtir. Veri yönetişimi ve birden fazla entegre sistemi kapsayan analizler için önemlidir.

Nereden alınır?

Bu değer genellikle verilerin çıkarılması, dönüştürülmesi ve yüklenmesi (ETL) sırasında eklenen sabit bir değerdir.

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

Bu öznitelik, hasar için yapılan her bir ödemenin tutarını kaydeder. Bir hasar yaşam döngüsü boyunca birden fazla ödeme yapılabilir.

Process Mining kapsamında mali analiz yapmak için bu bilgi gereklidir. Hasar başına toplam ödemeyi izlemek, tutara göre ödeme onay sürelerini incelemek ve süreç verimsizliklerini mali sonuçlarla ilişkilendirmek için kullanılabilir. Örneğin, çevrim süresi uzun olan hasarlar daha yüksek toplam ödemelerle ilişkili olabilir.

Neden önemli?

Hasar kapsamındaki mali işlemleri izler; ödeme tutarlarını ve bunların süreç faaliyetleriyle ilişkisini analiz etmenizi sağlar.

Nereden alınır?

Hasara bağlı ödeme varlıklarında, genellikle işlem veya çek tablosunda bulunur.

Örnekler
4500.00125000.00500.00
Otomatik mi
IsAutomated
Bir faaliyetin sistem tarafından otomatik olarak mı yoksa bir kullanıcı tarafından mı gerçekleştirildiğini belirten bir işaret.
Açıklama

Bu boole özniteliği, sistemin gerçekleştirdiği faaliyetleri (örneğin, otomatik karşılık oluşturma veya sistem tarafından hazırlanan yazışmalar) hasar uzmanının elle yaptığı faaliyetlerden ayırır.

Bu özniteliği analiz etmek, hasar sürecindeki otomasyon düzeyini anlamanın temel yollarından biridir. Elle müdahale edilen noktaları belirlemeye, uçtan uca otomasyon çalışmalarının etkinliğini ölçmeye ve insanların hâlâ yaptığı tekrarlı, kurallara dayalı görevleri saptayarak yeni otomasyon fırsatları bulmaya yardımcı olur.

Neden önemli?

Sistem tarafından yürütülen faaliyetleri kullanıcıların yaptığı faaliyetlerden ayırır. Otomasyon analizinde ve elle yürütülen işlerdeki darboğazları belirlemede önemlidir.

Nereden alınır?

Bu değer çoğu zaman mevcut verilerden türetilmelidir. Örneğin, genel bir system kullanıcısı tarafından kaydedilen olaylar otomatik olarak işaretlenebilir.

Örnekler
truefalse
Poliçe türü
PolicyType
Hasarın bildirildiği sigorta poliçesinin türü.
Açıklama

Poliçe türü, hasar türünden daha ayrıntılı bir sınıflandırma sunar ve Konut, Ticari Oto veya Siber Sorumluluk gibi sigorta ürününü belirtir. Bu ayrıntı düzeyi, belirli ürünlere bağlı süreç farklılıklarını ortaya çıkarabilir.

Süreci poliçe türüne göre analiz etmek, ürünlere özgü verimsizlikleri bulmaya yardımcı olur. Örneğin, yeni sunulan bir poliçeye ait hasarlar henüz olgunlaşmamış bir süreçten geçerek gecikmelere yol açabilir. Bu analiz, ürün tasarımına ve süreçleri standartlaştırma çalışmalarına yön verebilir.

Neden önemli?

Belirli sigorta ürünlerine göre süreç analizi yapmanızı ve poliçe özelliklerine bağlı işlem farklılıklarını belirlemenizi sağlar.

Nereden alınır?

Bu bilgi, Claim’e bağlı Policy varlığında bulunur.

Örnekler
Konut Çoklu RiskTicari Oto Sorumlulukİç Su Taşımacılığı
SLA durumu
SLAState
Hasarın çözüm hedef tarihine kadar kapatılıp kapatılmadığını gösterir.
Açıklama

Bu hesaplanan öznitelik, kapatılan her hasar için SLA uyumluluğunu kategorik olarak gösterir. Hasar Kapatıldı faaliyetinin zaman damgası ile Çözüm hedef tarihi karşılaştırılarak elde edilir.

Bu öznitelik, analizi Zamanında veya Gecikti gibi anlaşılır kategorilere ayırarak Hasar çözüm hedefi uyumluluğu Dashboardunu doğrudan destekler. Kolayca filtreleme ve toplulaştırma yaparak genel SLA uyumluluk oranını hesaplayabilir, gecikme nedenlerini ayrıntılı inceleyebilirsiniz.

Neden önemli?

SLA uyumluluğu sonucunu anlaşılır kategorilerle gösterir; zamanında tamamlanan işleri filtrelemeyi, toplulaştırmayı ve analiz etmeyi kolaylaştırır.

Nereden alınır?

Hesaplanan alan: IF (ActualCloseDate <= ResolutionTargetDate, 'Zamanında', 'Gecikti').

Örnekler
ZamanındaGecikti
Son veri güncellemesi
LastDataUpdate
Verilerin kaynak sistemden en son yenilendiği veya alındığı zamanı gösteren zaman damgası.
Açıklama

Bu öznitelik, kaynak sistemden en son veri alımının zaman damgasını verir. Analizin ne kadar güncel olduğunu anlamak için gereken bir meta veri alanıdır.

Kullanıcıların verilerin güncelliğini görebilmesi için bu bilgi Dashboardlarda ve analizlerde belirgin biçimde yer almalıdır. Böylece içgörülerin mevcut operasyon durumunu mu yoksa eski verileri mi yansıttığını değerlendirebilirsiniz.

Neden önemli?

Verilerin güncelliğini göstererek kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasını sağlar.

Nereden alınır?

Bu değer ETL işlemi sırasında oluşturulup kaydedilir ve veri yüklemesinin zaman damgasını gösterir.

Örnekler
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
Talep edilen tutar
ClaimedAmount
Poliçe sahibinin başlangıçta talep ettiği toplam para tutarı.
Açıklama

Bu öznitelik, talep sahibinin bildirdiği kayıp tutarını gösterir. Genellikle ilk tahmindir; hasar incelendikçe ve karşılıklar belirlendikçe değişebilir.

Talep edilen tutarı analiz ederek hasarları mali etkilerine göre gruplandırabilirsiniz. Yüksek tutarlı hasarlar, düşük tutarlı hasarlara kıyasla daha ayrıntılı ve karmaşık bir süreçten geçebilir. Farklı tutar aralıklarındaki süreçleri karşılaştırmak, küçük hasarların işlemlerini kolaylaştırma veya büyük hasarlar için daha sıkı kontroller uygulama fırsatlarını ortaya çıkarabilir.

Neden önemli?

Hasarları mali değerlerine göre gruplandırmanızı sağlar. Yüksek tutarlı hasarlar farklı ve daha karmaşık süreçlerden geçebilir.

Nereden alınır?

Bu bilgi tek bir alanda bulunmayabilir; Exposure kayıtlarında yer alan ilk kayıp tahminlerinden elde edilebilir.

Örnekler
5000.00150000.00750.50
Tekrarlanan bilgi talebi
RepeatedInfoRequestFlag
Aynı hasar için Ek Bilgi İstendi faaliyetinin birden fazla kez gerçekleşip gerçekleşmediğini belirten bir işaret.
Açıklama

Bu boole işareti, bir hasarda Ek Bilgi İstendi faaliyeti birden fazla kez gerçekleştiğinde true olarak ayarlanır. Bu durum genellikle ilk bilgi toplama aşamasındaki verimsizliklere işaret eder.

Bu öznitelik, Tekrarlanan bilgi talebi oranı KPI’ını doğrudan destekler. İlk incelemede bilgilerin eksik toplanması sorununu ölçmeye yardımcı olur. Bu eksiklikler önemli gecikmelere ve müşteri memnuniyetsizliğine yol açabilir. Bu işaretin bulunduğu hasarları analiz ederek kontrol listelerini ve hasar uzmanlarının prosedürlerini iyileştirebilir, gerekli tüm bilgilerin tek seferde istenmesini sağlayabilirsiniz.

Neden önemli?

Bilgilerin ilk seferde eksiksiz toplanmamasından kaynaklanan verimsizlikleri belirler; bu durum süreç gecikmelerine ve yeniden çalışmaya yol açar.

Nereden alınır?

Process Mining aracı, her vaka için Ek Bilgi İstendi faaliyetinin kaç kez gerçekleştiğini sayarak bu değeri hesaplar.

Örnekler
truefalse
Yargı bölgesi
JurisdictionState
Hasarı düzenleyen ve tabi olduğu mevzuatı belirleyen eyalet veya yargı bölgesi.
Açıklama

Bu öznitelik, hasarın ele alındığı yasal yargı bölgesini, örneğin ABD eyaletini belirtir. Sigorta düzenlemeleri yargı bölgelerine göre önemli ölçüde değişebilir ve gerekli süreç adımlarını, iletişim sürelerini ve belgelendirme gerekliliklerini etkileyebilir.

Bu öznitelik, uyumluluğu izlemek için önemlidir. Süreci yargı bölgesine göre analiz ederek eyalete özgü düzenleyici gerekliliklerin karşılanıp karşılanmadığını kontrol edebilirsiniz. Ayrıca çevrim süresi veya süreç akışındaki farklılıkların operasyonel verimsizlikten değil, yasal kısıtlamalardan kaynaklanıp kaynaklanmadığını anlamaya yardımcı olur.

Neden önemli?

Farklı yargı bölgelerindeki düzenlemeler hasar sürecini etkilediğinden, uyumluluk analizi için önemlidir.

Nereden alınır?

Claim varlığındaki standart bir alandır; genellikle JurisdictionState olarak adlandırılır.

Örnekler
CANYTXFL
Yeniden çalışma mı
IsRework
Bir faaliyetin önceki bir süreç aşamasına dönüşü, yani yeniden çalışma döngüsünü gösterip göstermediğini belirten bir işaret.
Açıklama

Bu hesaplanan öznitelik, yeniden çalışma döngüsünün parçası olan faaliyetleri işaretler. Örneğin, süreç İnceleme Tamamlandı adımından yeniden İnceleme Başlatıldı adımına dönerse, ikinci İnceleme Başlatıldı faaliyeti yeniden çalışma olarak işaretlenir.

Yeniden çalışmayı belirlemek, süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarmanın temel yollarından biridir. Yeniden Çalışma ve Ret Sıklığı Dashboardu, hasarların ideal yoldan ne sıklıkta saptığını ölçmek için bu metriği kullanır. Yeniden çalışmanın nedenlerini analiz etmek, süreç kalitesini ve hızını önemli ölçüde iyileştirebilir.

Neden önemli?

Yeniden çalışma döngüsüne dahil olan faaliyetleri açıkça işaretleyerek süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarır.

Nereden alınır?

Process Mining aracı, her vaka için faaliyet sırasını analiz ederek bu değeri hesaplar.

Örnekler
truefalse
Zorunlu Önerilen İsteğe bağlı

Hasar taleplerinin işlenmesine ilişkin etkinlikler

Hasar sürecini doğru biçimde keşfetmek ve analiz etmek için Event Loga kaydedilmesi gereken temel süreç adımları ve önemli aşamalar şunlardır.
7 Önerilen 7 İsteğe bağlı
Aktivite Açıklama
Hasar dosyası kapatıldı
Tüm etkinlikler ve ödemeler tamamlandıktan sonra hasar dosyasının başarıyla kapatıldığını belirtir. Bu, ana başarılı bitiş olayıdır ve hasar dosyasının ana durumundaki değişiklikten çıkarımlanır.
Neden önemli?

Ana bitiş olayı olan bu etkinlik, baştan sona çevrim süresini hesaplamak ve SLA hedeflerine uyumu ölçmek için gereklidir. Hasar dosyasının yaşam döngüsünün tamamlandığını gösterir.

Nereden alınır?

cc_claim tablosundaki State alanının 'Kapalı' olarak değişmesinden çıkarımlanır. Olayın zaman damgası, hasar kaydındaki CloseDate alanıdır.

Kaydedin

Hasar dosyasının ana durum alanının 'Kapalı' olarak güncellendiği zamanı belirleyin.

Olay türü inferred
Hasar dosyası oluşturuldu
Bu etkinlik, ilk hasar bildiriminin (FNOL) alınmasını ve Guidewire ClaimCenter’da yeni bir hasar kaydının resmen oluşturulmasını belirtir. Yeni bir Claim varlığı ilk kez veritabanına kaydedildiğinde açıkça kayda alınır.
Neden önemli?

Başlangıç olayı olarak bu etkinlik, hasar dosyasının baştan sona çevrim süresini ölçmek için gereklidir. Sonraki tüm performans ve süre KPI’ları için başlangıç noktası oluşturur.

Nereden alınır?

Bu, cc_claim tablosundaki CreateTime alanından alınan açık bir olaydır. Benzersiz bir Claim ID ile yeni bir kayıt oluşturulması olayı tetikler.

Kaydedin

Temel Claim varlık tablosundaki yeni kaydın oluşturulma zaman damgasını belirleyin.

Olay türü explicit
Hasar talebi reddedildi
Hasar talebinin reddedilmesine ilişkin nihai kararı belirtir ve süreç için son nokta oluşturur. Hasar talebinin durumu, ret nedeni ile birlikte kapalı bir duruma geçtiğinde bu olay çıkarımlanır.
Neden önemli?

Bu, sonucu belirleyen önemli bir olaydır. Retlerin sıklığını, nedenlerini ve bunlara yol açan süreç yollarını analiz etmek; hasar başvurusu, inceleme veya poliçe hükümlerinin yorumlanmasıyla ilgili sorunları belirlemeye yardımcı olur.

Nereden alınır?

cc_claim tablosundaki State alanının 'Kapalı' olarak değişmesi ve CloseReason alanının 'Reddedildi' veya benzer bir değer olmasıyla çıkarımlanır. Olayın zaman damgası CloseDate alanıdır.

Kaydedin

Ret nedenini belirten kodun bulunduğu, durumu 'Kapalı' olarak değişen hasar dosyalarını filtreleyin.

Olay türü inferred
İlk karşılık ayrıldı
Bir teminat kalemi için ilk finansal karşılık işleminin oluşturulduğunu ve hasar dosyasının olası maliyetinin tahmin edildiğini belirtir. Açıkça kaydedilen önemli bir finansal olaydır.
Neden önemli?

Bu kilometre taşı, finansal analiz ve olası yükümlülüğün ne kadar hızlı değerlendirildiğini anlamak açısından önemlidir. Gecikmeler finansal planlamayı ve raporlamayı etkileyebilir.

Nereden alınır?

Bu olay, hasar dosyasındaki bir teminat kalemiyle ilişkili ilk cc_reserveline kaydının oluşturulmasından alınır. İşlemin CreateTime alanı olayın zaman damgasıdır.

Kaydedin

Belirli bir hasar dosyasının teminat kalemlerine ait tüm karşılık satırları arasındaki en erken oluşturulma zaman damgasını bulun.

Olay türü explicit
Ödeme gönderildi
Bu etkinlik, ödemenin resmen gönderilip finansal sisteme iletildiği ödeme sürecinin son adımını belirtir. Açıkça kaydedilen bir finansal işlemdir.
Neden önemli?

Bu etkinlik, ödeme gönderme sürecinin verimliliğini ölçmek için önemlidir. Onay gecikmeleriyle paranın gerçekten gönderilmesindeki gecikmeleri birbirinden ayırmaya yardımcı olur.

Nereden alınır?

cc_check veya cc_transaction varlığındaki IssueDate alanından ya da durumun 'Gönderildi' veya 'İletildi' olarak değişmesinden alınır. Bu genellikle zaman damgası içeren açık bir olaydır.

Kaydedin

Ödeme kaydındaki IssueDate alanını veya durumun 'Gönderildi' olarak değiştiği zaman damgasını belirleyin.

Olay türü explicit
Ödeme onaylandı
Uzlaşma ödemesinin resmen onaylanmasını belirtir. Denetim açısından önemli olan bu olay, yetkili bir kullanıcı işlemi onayladığında açıkça kaydedilir.
Neden önemli?

Bu önemli kilometre taşı, son ödeme adımının önünü açar. Bu etkinlikten önceki ve sonraki süreleri analiz etmek, onay iş akışlarından veya yöneticilerin müsait olmamasından kaynaklanan gecikmeleri ayırmaya yardımcı olur.

Nereden alınır?

Bu olay genellikle cc_check veya cc_transaction varlığıyla ilişkili olarak cc_history tablosuna açıkça kaydedilir ve durumun 'Onay bekliyor' değerinden 'Onaylandı' değerine değiştiğini gösterir.

Kaydedin

Belirli bir ödeme işleminin durumunun 'Onaylandı' olarak değiştiği olayı izleyin.

Olay türü explicit
Teminat kalemi oluşturuldu
Bu etkinlik, hasar dosyası kapsamındaki belirli bir olası yükümlülüğü veya hasar türünü (ör. araç hasarı, yaralanma) temsil eden bir teminat kaleminin oluşturulduğunu belirtir. Guidewire’da açıkça kaydedilen bir olaydır.
Neden önemli?

Teminat kalemleri, hasar dosyalarını bölümlere ayırma ve analiz etme açısından temel öneme sahiptir. Oluşturulmalarını izlemek, hasar dosyasının karmaşıklığına ve hasar türüne bağlı süreç farklılıklarını anlamaya yardımcı olur.

Nereden alınır?

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

Kaydedin

Exposure varlık tablosundaki yeni kaydın oluşturulma zaman damgasını belirleyin.

Olay türü explicit
Ek bilgi alındı
Ek bilgi talebinin tamamlandığını belirtir. Bilgi talebiyle ilgili Activity (Task) 'Tamamlandı' olarak işaretlendiğinde kaydedilir.
Neden önemli?

Bu etkinlik, 'Ek bilgi toplama çevrim süresi' KPI’ının bitiş noktasıdır. Talep ile bilginin alınması arasındaki uzun süreler, hasar sürecindeki yaygın gecikme nedenlerindendir.

Nereden alınır?

ActivityPattern alanı bilgi talebiyle ilgili olan bir cc_activity kaydının CloseTime alanından alınır. Etkinliğin durumu 'Tamamlandı' olmalıdır.

Kaydedin

Dışarıdan bilgi isteme görevinin tamamlanma zaman damgasını belirleyin.

Olay türü explicit
Ek bilgi istendi
Hasar talebinde bulunan kişiye veya üçüncü tarafa daha fazla bilgi ya da belge göndermesi için iletilen talebi belirtir. Bu genellikle ClaimCenter’da açıkça oluşturulan bir Activity (Task) olarak kaydedilir.
Neden önemli?

Bu etkinlik, 'Ek bilgi toplama çevrim süresi' KPI’ını ölçmek için başlangıç noktasıdır. Sık tekrarlanması, FNOL sürecindeki eksikliklere veya bilgi toplamadaki verimsizliğe işaret edebilir.

Nereden alınır?

ActivityPattern alanı dış bir taraftan belge veya bilgi istemeyle ilgili olan bir cc_activity kaydının CreateTime alanından alınır.

Kaydedin

Dışarıdan bilgi istemek için oluşturulan görevi belirleyin.

Olay türü explicit
Hasar dosyası atandı
Bir hasar dosyasının işlenmek üzere belirli bir kullanıcıya (eksper) veya gruba atanmasını belirtir. Bu genellikle Claim varlığındaki atama alanlarındaki değişiklikler izlenerek çıkarımlanır.
Neden önemli?

Atamaları izlemek; eksperlerin iş yükünü analiz etmek, yönlendirme darboğazlarını belirlemek ve dosyayı üstlenen kişinin ilk işlemine kadar geçen süreyi ölçmek için önemlidir.

Nereden alınır?

Belirli bir Claim ID ile ilişkili AssignedUser veya AssignedGroup alanlarındaki değişiklikler izlenerek cc_history tablosundan çıkarımlanır. Değişikliğin zaman damgası, olayın ne zaman gerçekleştiğini gösterir.

Kaydedin

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

Olay türü inferred
Hasar dosyası yeniden açıldı
Ek işlem yapılması için hasar dosyasının 'Kapalı' durumundan yeniden 'Açık' duruma geçirilmesini belirtir. Bu olay, belirli bir durum değişikliği sırasından çıkarımlanır.
Neden önemli?

Bu etkinlik yeniden çalışmaya işaret eder. Yeniden açılan hasar dosyalarının sayısının yüksek olması; ilk uzlaşmada sorunlara, hasarların gözden kaçmasına veya süreçteki başka aksaklıklara işaret eder. Bunlar maliyetleri artırır ve verimliliği düşürür.

Nereden alınır?

cc_claim varlığındaki State alanının 'Kapalı' durumundan yeniden 'Açık' veya başka bir etkin duruma geçtiği belirlenerek cc_history tablosundan çıkarımlanır.

Kaydedin

Hasar dosyasının ana durum alanını, kapalı durumdan açık duruma geçiş açısından izleyin.

Olay türü inferred
İnceleme başladı
Bir hasar dosyası veya teminat kalemi için inceleme aşamasının resmen başladığını belirtir. Bu genellikle Guidewire’da incelemeyle ilgili ilk Activity (Task) oluşturulmasından çıkarımlanır.
Neden önemli?

Bu etkinlik, önemli ve çoğu zaman uzun süren bir aşamanın başlangıcını gösterir. İncelemenin başlamasına kadar geçen süreyi ve incelemenin kendi süresini analiz etmek, önemli darboğazları ortaya çıkarır.

Nereden alınır?

ActivityPattern alanı incelemeyle ilgili olan bir cc_activity kaydının CreateTime alanından çıkarımlanır (ör. 'İlk inceleme', 'Tanıkla iletişime geç').

Kaydedin

İncelemeyle ilgili bir örüntü veya konuya sahip görevin ilk kez oluşturulduğu zamanı belirleyin.

Olay türü inferred
Sorumluluk kararı verildi
Bir teminat kalemi için sorumluluk veya kusur kararının verildiği noktayı belirtir. Bu olay genellikle Exposure varlığındaki durum değişikliğinden çıkarımlanır.
Neden önemli?

Bu önemli karar kilometre taşı, uzlaşma ve ödeme aşamalarının önünü açar. Karara kadar geçen süreyi analiz etmek, inceleme ve değerlendirme aşamalarındaki darboğazları belirlemeye yardımcı olur.

Nereden alınır?

cc_exposure varlığındaki State alanında veya özel sorumluluk durumu alanında gerçekleşen değişiklikler izlenerek cc_history tablosundan çıkarımlanır. Geçmiş kaydının zaman damgası, olayın gerçekleştiği zamanı gösterir.

Kaydedin

Teminat kaleminin durumu veya sorumluluk durumundaki güncellemeler için denetim günlüklerini ya da geçmiş tablolarını izleyin.

Olay türü inferred
Uzlaşma tutarı hesaplandı
Uzlaşma tutarının belirlendiği ancak ödeme için henüz onaylanmadığı noktayı belirtir. 'Onay bekliyor' durumunda bir ödeme kaydı oluşturulmasından çıkarımlanabilir.
Neden önemli?

Değerlendirmeden ödemeye geçişi belirtir. Onay zincirindeki gecikmeleri ortaya çıkarmak için 'Ödeme onayına kadar geçen süre' KPI’ının başlangıç noktasıdır.

Nereden alınır?

Başlangıç durumu 'Onay bekliyor' veya 'Onaylandı' öncesindeki benzer bir durum olan cc_check ya da cc_transaction kaydının CreateTime alanından çıkarımlanır.

Kaydedin

Ön onay durumundaki bir ödeme veya işlem kaydının oluşturulduğu zamanı belirleyin.

Olay türü inferred
Önerilen İsteğe bağlı

Veri çıkarma rehberleri

Guidewire ClaimCenter’dan verilerinizi nasıl alırsınız?

Başlamaya hazır mısınız?

Verilerinizi analize hazırlamak ve hasar taleplerinin işlenmesine ilişkin içgörüleri keşfetmek için bu Templateten yararlanın. İş akışlarınızı bugün iyileştirmeye başlayın.

Hasar taleplerini daha hızlı işleyin ve vakaları daha çabuk sonuçlandırın

Birikmiş işleri azaltın, dolandırıcılığı önleyin ve işlemlerin %70'ini baştan sona otomatik yürütmeyi hedefleyin.

Ücretsiz denemeyi başlatın

Kredi kartı gerekmez, kurulumu yalnızca birkaç dakika sürer.