Talepleri işleme Veri Templateınız

Guidewire ClaimCenter
Talepleri işleme Veri Templateınız

Talepleri işleme Veri Templateınız

Talepleri işlemeyi iyileştirmeye yönelik özel kaynağınıza hoş geldiniz. Bu Template, toplanması gereken temel veri özniteliklerini ve izlenmesi gereken önemli etkinlikleri açıklar, ayrıca veri çıkarma konusunda net yönlendirmeler sunar. Kapsamlı süreç analizi için gerekli tüm bilgileri yakaladığınızdan emin olmak üzere bu Templateı kullanın.
  • Toplanması önerilen öznitelikler
  • İzlenecek temel faaliyetler
  • Guidewire ClaimCenter için veri çıkarma yönlendirmesi
Event Loglarına yeni misiniz? Öğrenin Process Mining Event Logu oluşturmayı öğrenin.

Hasar taleplerinin işlenmesi öznitelikleri

Hasar talebi Workflowlarınızı etkili biçimde analiz etmek için eksiksiz bir Event Log oluşturmanızda bu önerilen veri alanları büyük önem taşır.
3 Gerekli 4 Önerilen 14 İsteğe bağlı
Ad Açıklama
Aktivite adı
ActivityName
Hasar yaşam döngüsünün belirli bir noktasında gerçekleşen iş faaliyetinin veya olayın adıdır.
Açıklama

Bu öznitelik, hasar sürecindeki belirli bir adımı veya kilometre taşını tanımlar; örneğin 'Claim Created', 'Investigation Started' veya 'Payment Issued'. Belirli bir Claim ID için bu faaliyetlerin sırası süreç akışını oluşturur.

Faaliyetlerin sırasını, sıklığını ve aralarındaki süreyi analiz etmek Process Mining'in temelini oluşturur. Bu analiz, süreç modellerini keşfetmenize, darboğazları belirlemenize, yeniden işleme döngülerini tespit etmenize ve süreç sapmalarını incelemenize imkân verir.

Neden önemli?

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

Nereden alınır?

Genellikle ClaimCenter'daki olay tablolarından veya denetim günlüklerinden elde edilir. Belirli sistem olayları ya da durum değişiklikleri standartlaştırılmış faaliyet adlarıyla eşleştirilir.

Örnekler
Hasar dosyası oluşturulduYükümlülük kararı verildiÖdeme düzenlendiHasar dosyası kapatıldı
Hasar ID'si
ClaimID
Her sigorta hasar dosyasının benzersiz tanımlayıcısıdır ve birincil vaka tanımlayıcısı olarak kullanılır.
Açıklama

Claim ID, hasar süreci analizinin temelidir ve her vakayı gönderimden kapanışa kadar benzersiz biçimde tanımlar. İlişkili tüm faaliyetleri, belgeleri, ödemeleri ve iletişimleri birbirine bağlayarak hasar dosyasının yaşam döngüsünü eksiksiz ve tutarlı biçimde görmenizi sağlar.

Process Mining'de Veri Seti içindeki her olay bir Claim ID'ye bağlıdır. Bu sayede uçtan uca süreç akışı yeniden oluşturulabilir. Claim ID, çevrim sürelerini analiz etmek, süreç varyantlarını belirlemek ve bir hasar dosyasının farklı departmanlar ve hasar uzmanları arasındaki yolculuğunu 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 yolculuğunu izlemeyi ve analiz etmeyi mümkün kılar.

Nereden alınır?

Guidewire ClaimCenter'da birincil anahtar olarak kullanılır ve genellikle temel Claim varlığındaki Claim.ClaimNumber veya benzer bir alanda bulunur.

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

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

Tek bir Claim ID için EventTime değerlerinin kronolojik sıralanması, süreç akışının yeniden oluşturulmasını sağlar. Ardışık olaylar arasındaki zaman farkı; performans analizi, darboğazların belirlenmesi ve SLA izleme açısından önemli olan çevrim sürelerini, bekleme sürelerini ve işlem sürelerini hesaplamak için kullanılır.

Neden önemli?

Bu zaman damgası, olayları sıralamak, çevrim sürelerini ve süreleri hesaplamak ve süreçteki gecikmeleri belirlemek için gereklidir.

Nereden alınır?

Guidewire ClaimCenter'daki geçmiş veya denetim tablolarında olay ya da faaliyet verilerinin yanında bulunur ve çoğu zaman 'CreateTime' veya 'UpdateTime' alanı olarak yer alır.

Örnekler
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
Atanan eksper
AssignedAdjuster
Hasarı veya belirli bir etkinliği ele almakla görevlendirilen kullanıcının adı ya da kimliği.
Açıklama

Bu öznitelik, belirli bir zamanda bir hasardan sorumlu olan eksperi tanımlar. Eksper, hasarın tamamına veya hasar içindeki belirli görevlere atanabilir.

Atanan eksper bazında analiz yapmak, iş yükünü dengelemek, performansı yönetmek ve eğitim fırsatlarını belirlemek için büyük önem taşır. Bu analiz, 'Hangi eksperlerin dosya yükü en yüksek?', 'Eksperler arasında performans farklılıkları var mı?' ve 'İşler dengeli dağıtılıyor mu?' gibi soruları yanıtlamaya yardımcı olur.

Neden önemli?

Kullanıcı katılımını izler; iş yükü analizine, performans karşılaştırmasına ve kaynakla ilgili darboğazların belirlenmesine imkan verir.

Nereden alınır?

ClaimCenter içindeki Claim veya Exposure varlığında bulunur ve genellikle User nesnesine bağlanı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 Open, Closed veya Denied.
Açıklama

Bu öznitelik, hasarın genel durumunu gösterir. Temel durumlar arasında 'Open', 'Closed', 'Denied' ve 'Reopened' bulunur. Hasarın nihai durumu, önemli bir sonuç metriğidir.

Hasar durumundaki değişiklikleri izlemek, temel süreç kilometre taşlarını ve sonuçlarını tanımlamaya yardımcı olur. Bu bilgi, hasarın nihai çözümünü belirlemek, ret oranlarını hesaplamak ve kapatıldıktan sonra yeniden açılan hasarların sıklığını analiz etmek için kullanılır. Yeniden açılma sıklığı, ç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ı, kapatma modellerini ve yeniden açılma sıklığını analiz etmek için gereklidir.

Nereden alınır?

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

Örnekler
AçıkKapatıldıReddedildiYeniden açıldı
Hasar nedeni
LossCause
Hasara yol açan olayın belirli nedeni. Örneğin Collision, Fire veya Water Damage.
Açıklama

Bu öznitelik, hasarın neden bildirildiği hakkında ayrıntılı bağlam sağlar. Hasarın nedeni, gerekli inceleme adımlarını, ihtiyaç duyulan uzman türünü ve hasarın genel karmaşıklığını belirleyebilir.

Süreci hasar nedenine göre analiz etmek, gizli kalmış örüntüleri ortaya çıkarabilir. Örneğin 'Water Damage' ile ilgili hasarlarda, 'Theft' hasarlarına göre yeniden işleme oranı daha yüksek olabilir veya 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 sağlar ve farklı hasar nedenlerinin süreç akışını ve süresini nasıl etkilediğini analiz etmenize imkan verir.

Nereden alınır?

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

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

Hasar türü, iş koluna veya zararın niteliğine göre yapılan temel bir sınıflandırmadı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ümlendirmek gerekir. Bu yaklaşım, farklı iş kollarındaki süreç performansını karşılaştırmanıza, türe özgü darboğazları belirlemenize ve süreç iyileştirme çalışmalarını her hasar kategorisinin özelliklerine göre uyarlamanıza imkan verir.

Neden önemli?

Hasarları bölümlendirmenizi sağlar. Örneğin otomobil ve mülk hasarları genellikle farklı süreçlerden geçer ve farklı performans hedeflerine sahiptir.

Nereden alınır?

ClaimCenter içindeki Policy veya Claim varlığından türetilir ve genellikle Line of Business (LOB) koduna dayanır.

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

Bitiş zamanı, özellikle 'Investigation' veya 'Document Review' gibi ölçülebilir süreye sahip görevlerde bir etkinliğin tamamlandığını gösterir. Process Mining etkinliklerinin çoğu anlık gerçekleştiği için StartTime yeterli olabilir. Ancak belirgin bir başlangıç ve bitiş zamanı olan etkinlikler için her iki zaman damgasını kullanmak daha doğru sonuç verir.

Bu öznitelik, bekleme süresinden ayrı olarak etkinliğin işlenme süresinin hassas biçimde hesaplanmasını sağlar. Böylece yalnızca adımlar arasındaki uzun gecikmeleri görmek yerine, hangi görevlerin gerçekten zaman aldığını belirleyebilirsiniz.

Neden önemli?

Bir etkinliğin tamamlanmasının ne kadar sürdüğünü hassas biçimde ölçmenizi ve işlenme süresini bekleme süresinden ayırmanızı sağlar.

Nereden alınır?

Etkinliği mantıksal olarak tamamlayan sonraki bir olay bulunarak türetilmesi gerekebilir. Örneğin durumun 'In Progress' değerinden 'Completed' değerine değiş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ülmesinin 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 uyumluluk ölçümü için bir referans noktası görevi görür.

Bu öznitelik, SLA uyumluluğu için Dashboard ve KPI'lar oluştururken büyük önem taşır. Gerçek 'Claim Closed' tarihini hedef tarihle karşılaştırarak geç kalan hasarları otomatik olarak işaretleyebilir, zamanında tamamlama oranlarını ölçebilir ve hedeflerini 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 kullanılan referans noktasıdır.

Nereden alınır?

ClaimCenter'da yapılandırılan iş kurallarına göre oluşturulan özel bir alan olabilir veya türetilebilir. Belirli hasar metrikleriyle ilişkili olması mümkündür.

Örnekler
2023-06-142023-07-202023-08-28
Departman
Department
Hasar etkinliğini ele almaktan sorumlu iş birimi veya departman.
Açıklama

Bu öznitelik, atanan eksperin bağlı olduğu departmanı veya ekibi gösterir. Örnekler arasında 'Auto Claims', 'Property Claims' ve 'Special Investigations Unit' yer alır. Böylece sürece ilişkin kurumsal bağlam sağlanır.

Departman bazında analiz yapmak, süreç performansını kurumsal düzeyde anlamak için önemlidir. Departmanlar arasındaki devir gecikmelerini belirlemenize, ekiplerin verimliliğini karşılaştırmanıza ve hasar organizasyonundaki kaynakları daha etkili dağıtmanıza yardımcı olur.

Neden önemli?

Kurumsal bağlam sağlar; farklı ekiplerin performansını analiz etmenize ve departmanlar arasındaki devir sorunlarını görmenize yardımcı olur.

Nereden alınır?

Bu bilgi genellikle ClaimCenter içindeki atanan kullanıcının veya grubun profiliyle ilişkilendirilir.

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

Hasar tarihi, hasarın bildirildiği gerçek olayın tarihidir. Örneğin trafik kazası veya mülk hasarı. Bu tarih, hasarın bildirildiği ya da oluşturulduğu tarihten farklıdır.

Hasar tarihi ile 'Claim Created' etkinliği arasındaki süre, bildirim gecikmesi olarak bilinir ve önemli bir KPI'dır. Bu süreyi analiz etmek, müşteri davranışı ve ilk hasar bildirimi kanallarının etkinliği hakkında içgörü sağlayabilir.

Neden önemli?

Hasarın kaynağı hakkında önemli bağlam sağlar ve bildirim gecikmesini, yani olay ile hasar bildirimi arasındaki süreyi analiz etmenize yardımcı olur.

Nereden alınır?

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

Örnekler
2023-05-102023-04-202023-05-28
Kaynak sistem
SourceSystem
Verilerin çıkarıldığı sistemdir.
Açıklama

Bu öznitelik, olay verilerinin kaynağını tanımlar. Modern bir kurumsal ortamda hasarla ilgili olaylar Guidewire gibi bir temel sistemden, belge yönetim sisteminden veya müşteri portalından gelebilir.

Kaynak sistemi belirtmek; veri yönetişimi, veri tutarsızlıklarının giderilmesi ve sürecin teknolojik yapısının anlaşılması için önemlidir. Temel süreç adımlarını çevre sistemlerdeki destekleyici faaliyetlerden ayırmaya yardımcı olur.

Neden önemli?

Verilerin kaynağını tanımlar. Bu bilgi, veri yönetişimi ve birden fazla entegre sistemi içeren analizler için önemlidir.

Nereden alınır?

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

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

Bu öznitelik, bir hasar için yapılan her bir ödemenin değerini kaydeder. Tek bir hasar yaşam döngüsü boyunca birden fazla ödeme içerebilir.

Bu bilgi, Process Mining kapsamında finansal analiz için gereklidir. Hasar 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 uzun çevrim sürelerine sahip hasarlar, daha yüksek toplam ödemelerle ilişkili olabilir.

Neden önemli?

Hasar içindeki finansal işlemleri izler; ödeme değerlerini ve bunların süreç etkinlikleriyle ilişkisini analiz etmenizi sağlar.

Nereden alınır?

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

Örnekler
4500.00125000.00500.00
Otomatik mi
IsAutomated
Bir etkinliğin sistem tarafından otomatik olarak mı yoksa insan kullanıcı tarafından mı gerçekleştirildiğini gösteren işaret.
Açıklama

Bu boolean öznitelik, sistem tarafından yürütülen etkinliklerle, örneğin otomatik karşılık oluşturma veya sistem tarafından oluşturulan yazışmalarla, eksper tarafından manuel olarak gerçekleştirilen etkinlikleri birbirinden ayırır.

Bu özniteliği analiz etmek, hasar sürecindeki otomasyon düzeyini anlamanın temel yollarından biridir. Manuel müdahale noktalarını belirlemenize, doğrudan işleme girişimlerinin etkinliğini ölçmenize ve insanların hâlâ gerçekleştirdiği tekrarlı, kural tabanlı görevleri ortaya çıkararak yeni otomasyon fırsatları bulmanıza yardımcı olur.

Neden önemli?

Sistem tarafından yürütülen etkinliklerle insan tarafından yürütülen etkinlikleri ayırır; otomasyon analizi ve manuel darboğazların belirlenmesi için önemlidir.

Nereden alınır?

Genellikle türetilmesi gerekir. Ö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 belirli sigorta poliçesi türü.
Açıklama

Poliçe türü, hasar türüne göre daha ayrıntılı bir sınıflandırma sunar ve 'Homeowners', 'Commercial Auto' veya 'Cyber Liability' gibi belirli sigorta ürünlerini tanımlar. 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üne özgü verimsizlikleri görmenize yardımcı olur. Örneğin yeni sunulan bir poliçeye ait hasarlar, daha az olgun bir süreçten geçerek gecikmelere yol açabilir. Bu analiz, ürün tasarımı ve süreç standardizasyonu çalışmalarına yön verebilir.

Neden önemli?

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

Nereden alınır?

Bu bilgi, Claim ile bağlantılı olan Policy varlığında bulunur.

Örnekler
Konut Sahipleri Çoklu RiskTicari Oto Sorumluluğuİç Sular Taşımacılığı
SLA durumu
SLAState
Hasarın çözüm hedef tarihi içinde kapatılıp kapatılmadığını gösterir.
Açıklama

Bu hesaplanan öznitelik, kapatılan her talep için SLA uyumluluk durumunu kategorik olarak gösterir. Claim Closed etkinliğinin zaman damgası ile Resolution Target Date karşılaştırılarak elde edilir.

Bu öznitelik, analizi On Time veya Late gibi net kategorilere ayırarak Claim Resolution Target Adherence Dashboardını doğrudan destekler. Gecikmelerin nedenlerini ayrıntılı incelemenin yanı sıra genel SLA uyumluluk oranını hesaplamak için kolay filtreleme ve toplama olanağı sağlar.

Neden önemli?

SLA uyumluluğu için açık ve kategorik bir sonuç sağlar; zamanında tamamlanan işlemleri filtrelemeyi, toplulaştırmayı 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üncellemesi
LastDataUpdate
Verilerin kaynak sistemden en son ne zaman yenilendiğini veya çıkarıldığını gösteren zaman damgası.
Açıklama

Bu öznitelik, kaynak sistemden en son veri çekme işleminin zaman damgasını sağlar. Analizin güncelliğini anlamak için gerekli bir meta veri alanıdır.

Dashboard ve analizler, kullanıcıların verilerin güncelliğini görebilmesi için bu bilgiyi belirgin şekilde göstermelidir. Bu bilgi, içgörülerin operasyonların mevcut durumunu yansıtıp yansıtmadığını veya eski verilere dayanıp dayanmadığını değerlendirmeye yardımcı olur.

Neden önemli?

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

Nereden alınır?

Bu değer ETL sürecinde oluşturulur ve saklanır; veri yükleme işleminin 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 parasal tutar.
Açıklama

Bu öznitelik, talep sahibinin bildirdiği zarar değerini gösterir. Genellikle hasar incelendikçe ve karşılıklar belirlendikçe değişebilen ilk tahmindir.

Talep edilen tutarı analiz etmek, hasarları finansal etkilerine göre bölümlendirmenize yardımcı olur. Yüksek tutarlı hasarlar, düşük tutarlı hasarlara göre daha ayrıntılı ve karmaşık bir süreçten geçebilir. Farklı değer aralıklarındaki süreçleri karşılaştırmak, küçük hasarların ele alınmasını kolaylaştırma veya büyük hasarlar için daha sıkı kontroller uygulama fırsatlarını ortaya çıkarabilir.

Neden önemli?

Hasarları finansal değerlerine göre bölümlendirmenizi 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ındaki ilk zarar tahminlerinden türetilebilir.

Örnekler
5000.00150000.00750.50
Tekrarlanan bilgi talebi
RepeatedInfoRequestFlag
Aynı hasar için 'Additional Info Requested' etkinliğinin birden fazla kez gerçekleşip gerçekleşmediğini gösteren işaret.
Açıklama

Bu boolean işaret, bir hasar için birden fazla 'Additional Info Requested' etkinliği gerçekleştiğinde true olarak ayarlanır. Bu durum genellikle ilk bilgi toplama aşamasındaki verimsizliklere işaret eder.

Bu öznitelik, 'Repeated Info Request Rate' KPI'ını doğrudan destekler. İlk bilgi toplama işleminin eksik yapılmasından kaynaklanan ve önemli gecikmelere ve müşteri memnuniyetsizliğine yol açabilen sorunun ölçülmesine yardımcı olur. Bu işaretin bulunduğu hasarları analiz etmek, eksperlerin gerekli tüm bilgileri tek seferde istemesini sağlamak üzere kontrol listelerini ve prosedürleri iyileştirmenize yardımcı olabilir.

Neden önemli?

Bilgi toplama işleminin ilk seferde tamamlanmadığı, bunun da süreç gecikmelerine ve yeniden işlemeye yol açtığı verimsizlikleri belirler.

Nereden alınır?

Vaka başına 'Additional Info Requested' etkinliğinin gerçekleşme sayısı hesaplanarak Process Mining aracı içinde türetilir.

Örnekler
truefalse
Yargı bölgesi
JurisdictionState
Hasarı yöneten ve düzenleyici gereklilikleri belirleyen eyalet veya yargı bölgesi.
Açıklama

Bu öznitelik, hasarın ele alındığı hukuki yargı bölgesini, örneğin ABD'deki eyaleti, 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 belgeleri etkileyebilir.

Bu öznitelik, uyumluluğu izlemek için büyük önem taşır. Süreci yargı bölgesine göre analiz etmek, eyalete özgü düzenleyici gerekliliklerin karşılanıp karşılanmadığını kontrol etmenizi sağlar. Ayrıca çevrim sürelerindeki veya süreç yollarındaki farklılıkların operasyonel verimsizlikten değil, hukuki kısıtlamalardan kaynaklandığını açıklayabilir.

Neden önemli?

Uyumluluk analizi için önemlidir; farklı yargı bölgelerindeki düzenlemeler hasar sürecini farklı şekillerde etkiler.

Nereden alınır?

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

Örnekler
CANYTXFL
Yeniden işleme mi
IsRework
Bir etkinliğin yeniden işleme döngüsünü, yani önceki bir süreç aşamasına dönüşü temsil edip etmediğini gösteren işaret.
Açıklama

Bu hesaplanan öznitelik, yeniden işleme döngüsünün parçası olan etkinlikleri işaretler. Örneğin süreç 'Investigation Completed' adımından 'Investigation Started' adımına geri dönüyorsa, ikinci 'Investigation Started' etkinliği yeniden işleme olarak işaretlenir.

Yeniden işlemeyi belirlemek, süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarmak için temel bir adımdır. Rework and Rejection Frequency Dashboard, hasarların ideal 'happy path'ten ne sıklıkta saptığını ölçmek için bu metriğe dayanır. Yeniden işlemenin nedenlerini analiz etmek, süreç kalitesinde ve hızında önemli iyileştirmeler sağlayabilir.

Neden önemli?

Yeniden işleme döngüsünün parçası olan etkinlikleri açıkça işaretleyerek süreç verimsizliklerini ve kalite sorunlarını görünür kılar.

Nereden alınır?

Her vaka için etkinlik dizisi analiz edilerek Process Mining aracı içinde hesaplanır.

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

Hasar taleplerinin işlenmesi faaliyetleri

Hasar taleplerinin hassas süreç keşfi ve analizi için Event Logunuza kaydetmeniz gereken temel süreç adımları ve önemli kilometre taşları aşağıda yer alır.
7 Önerilen 7 İsteğe bağlı
Aktivite Açıklama
Exposure oluşturuldu
Bu faaliyet, hasar dosyası kapsamındaki belirli bir potansiyel yükümlülüğü veya kayıp türünü temsil eden bir Exposure'ın oluşturulmasını ifade eder (örneğin araç hasarı veya yaralanma). Bu, Guidewire içinde açıkça kaydedilen bir olaydır.
Neden önemli?

Exposure'lar, hasar dosyalarının bölümlendirilmesi ve analizi için temel unsurlardır. Oluşturulmalarını izlemek, hasarın karmaşıklığına ve kayıp 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 yakalanır. Her kayıt tek bir Claim ID ile ilişkilendirilir.

Yakalayın

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

Olay türü explicit
Hasar dosyası kapatıldı
Tüm faaliyetler ve ödemeler tamamlandıktan sonra hasar dosyasının başarıyla kapatılmasını belirtir. Hasar dosyasının ana durumundaki değişiklikten çıkarılan birincil başarılı bitiş olayıdır.
Neden önemli?

Birincil bitiş olayı olarak bu faaliyet, uçtan uca çevrim süresini hesaplamak ve SLA uyumunu ölçmek için gereklidir. Hasar yaşam döngüsünün tamamlandığını gösterir.

Nereden alınır?

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

Yakalayın

Hasar dosyasının ana durum alanının ne zaman 'Closed' olarak güncellendiğini belirleyin.

Olay türü inferred
Hasar dosyası oluşturuldu
Bu faaliyet, ilk hasar bildirimini (FNOL) ve Guidewire ClaimCenter'da yeni bir hasar kaydının resmî olarak oluşturulmasını belirtir. Yeni bir Claim varlığı veritabanına ilk kez kaydedildiğinde açıkça yakalanır.
Neden önemli?

Birincil başlangıç olayı olarak bu faaliyet, uçtan uca hasar ç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 yakalanan açık bir olaydır. Benzersiz bir Claim ID içeren yeni bir kaydın oluşturulması olay tetikleyicisi olarak kullanılır.

Yakalayın

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

Olay türü explicit
Hasar dosyası reddedildi
Bir hasar dosyasını reddetmeye yönelik nihai kararı ifade eder ve süreç için son nokta görevi görür. Hasar dosyasının durumu 'Denied' nedeni ile kapalı bir duruma değiştiğinde bu olay çıkarılır.
Neden önemli?

Bu, önemli bir sonuç olayıdır. Retlerin sıklığını, nedenlerini ve retlere giden süreç yollarını analiz etmek; hasar kabulü, inceleme veya poliçe yorumlamasındaki sorunları belirlemeye yardımcı olur.

Nereden alınır?

cc_claim tablosundaki State alanının 'Closed' olarak değişmesi ve CloseReason alanının 'Denied' veya benzer bir değer olması birlikte değerlendirilerek çıkarılır. Olayın zaman damgası CloseDate alanıdır.

Yakalayın

Neden kodunun ret olduğunu gösterdiği durumlarda hasar durumunun 'Closed' olarak değiştiği kayıtları filtreleyin.

Olay türü inferred
İlk rezerv belirlendi
Bir Exposure için ilk finansal rezerv işleminin oluşturulmasını ve hasarın olası maliyetinin tahmin edilmesini belirtir. Bu, açıkça yakalanan önemli bir finansal olaydır.
Neden önemli?

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

Nereden alınır?

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

Yakalayın

Belirli bir hasar dosyasının Exposure'larına ait tüm rezerv satırları arasındaki en erken oluşturulma zaman damgasını bulun.

Olay türü explicit
Ödeme düzenlendi
Bu faaliyet, ödemenin resmî olarak düzenlenip finansal sisteme gönderildiği ödeme sürecinin son adımını belirtir. Açıkça kaydedilen bir finansal işlemdir.
Neden önemli?

Bu faaliyet, ödeme gönderme sürecinin verimliliğini ölçmek için önemlidir. Onay gecikmeleri ile fonların fiilen düzenlenmesindeki 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 yakalanır. Bu, çoğu zaman zaman damgası içeren açık bir olaydır.

Yakalayın

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

Olay türü explicit
Ödeme onaylandı
Bir sonuçlandırma ödemesinin resmî olarak onaylanmasını ifade eder. Bu, yetkili bir kullanıcı işlemi onayladığında açıkça kaydedilen önemli bir denetim olayıdır.
Neden önemli?

Bu önemli kilometre taşı, son ödeme adımının önündeki engeli kaldırır. Bu etkinlikten önceki ve sonraki süreyi analiz etmek, onay iş akışlarından veya yöneticilerin uygun olmamasından kaynaklanan gecikmeleri ayırmaya yardımcı olur.

Nereden alınır?

Bu, çoğu zaman cc_check veya cc_transaction varlığıyla ilişkili cc_history tablosunda açıkça kaydedilen bir olaydır ve durumun 'Pending Approval'dan 'Approved'a değiştiğini gösterir.

Yakalayın

Belirli bir ödeme işlemi için durumun 'Approved' olarak değiştiği olayı izleyin.

Olay türü explicit
Ek bilgi alındı
Ek bilgi talebinin tamamlandığını belirtir. Bilgi talebine karşılık gelen 'Activity' (görev) 'Completed' olarak işaretlendiğinde yakalanır.
Neden önemli?

Bu, 'Additional Info Gathering Cycle Time' KPI'ının bitiş noktasıdır. Talep ile bilginin alınması arasındaki uzun süreler, hasar sürecindeki yaygın gecikme kaynaklarıdır.

Nereden alınır?

ActivityPattern alanı bilgi talebiyle ilişkili olan bir cc_activity kaydının CloseTime alanından yakalanır. Activity durumu 'Completed' olmalıdır.

Yakalayın

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

Olay türü explicit
Ek bilgi istendi
Hasar sahibine veya üçüncü bir tarafa daha fazla bilgi ya da belge göndermesi için iletilen talebi ifade eder. Bu durum genellikle ClaimCenter'da açık bir 'Activity' (görev) oluşturulmasıyla kaydedilir.
Neden önemli?

Bu faaliyet, 'Additional Info Gathering Cycle Time' KPI'ını ölçmenin başlangıç noktasıdır. Sık tekrarlanması, eksik FNOL süreçlerine veya verimsiz bilgi toplama işlemlerine işaret edebilir.

Nereden alınır?

ActivityPattern alanı dış bir taraftan belge veya bilgi istemeyle ilişkili olan bir cc_activity kaydının CreateTime alanından yakalanır.

Yakalayın

Dış bilgi istemek üzere oluşturulan görevi belirleyin.

Olay türü explicit
Hasar dosyası atandı
Bir hasar dosyasının işlem yapılması için belirli bir kullanıcıya (hasar uzmanına) veya gruba atanmasını ifade eder. Bu durum genellikle Claim varlığındaki atama alanlarında yapılan değişiklikler izlenerek çıkarılır.
Neden önemli?

Atamaları izlemek, hasar uzmanlarının iş yükünü analiz etmek, yönlendirme darboğazlarını belirlemek ve atanan görevlinin 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ılır. Değişikliğin zaman damgası, olayın ne zaman gerçekleştiğini gösterir.

Yakalayın

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 yapmak üzere bir hasar dosyasının 'Closed' durumundan yeniden 'Open' durumuna geçirilmesini ifade eder. Bu olay, belirli bir durum değişikliği dizisinden çıkarılır.
Neden önemli?

Bu faaliyet yeniden işlemeyi gösterir. Yeniden açılan hasar dosyalarının yüksek sayıda olması, ilk sonuçlandırmadaki sorunlara, gözden kaçan hasarlara veya diğer süreç hatalarına işaret eder ve maliyetleri ve verimsizliği artırır.

Nereden alınır?

cc_history tablosunda cc_claim varlığının State alanının 'Closed'dan yeniden 'Open' veya başka bir etkin duruma değiştiği belirlenerek çıkarılır.

Yakalayın

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şlatıldı
Bir talep veya hasar dosyası için inceleme aşamasının resmî başlangıcını gösterir. Bu başlangıç, genellikle Guidewire içindeki incelemeyle ilgili ilk Etkinlik görevinin oluşturulmasından anlaşılır.
Neden önemli?

Bu faaliyet, genellikle uzun süren önemli 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, başlıca darboğazları ortaya çıkarır.

Nereden alınır?

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

Yakalayın

İncelemeyle ilişkili bir kalıba veya konuya sahip görevin ilk kez oluşturulmasını belirleyin.

Olay türü inferred
Sonuçlandırma hesaplandı
Sonuçlandırma tutarının belirlendiği ancak ödeme için henüz onaylanmadığı noktayı ifade eder. 'Pending Approval' durumundaki bir ödemenin oluşturulmasından çıkarılabilir.
Neden önemli?

Değerlendirmeden ödemeye geçişi belirtir. 'Payment Authorization Lead Time' KPI'ını ölçmenin başlangıç noktasıdır ve onay zincirindeki gecikmeleri ortaya çıkarır.

Nereden alınır?

İlk durumu 'Pending Approval' veya 'Approved' öncesindeki benzer bir durum olan bir cc_check ya da cc_transaction kaydının CreateTime alanından çıkarılır.

Yakalayın

Ön onay durumundaki bir ödeme veya işlem kaydının oluşturulmasını belirleyin.

Olay türü inferred
Yükümlülük kararı verildi
Bir Exposure için yükümlülük veya kusur kararının belirlendiği noktayı ifade eder. Bu olay genellikle Exposure varlığındaki durum değişikliğinden çıkarılır.
Neden önemli?

Bu, sonuçlandırma ve ödeme aşamalarını başlatan önemli bir karar kilometre taşıdır. Bu 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 veya özel yükümlülük durumu alanında yapılan değişiklikler cc_history tablosundan izlenerek çıkarılır. Geçmiş kaydının zaman damgası olay zamanını gösterir.

Yakalayın

Exposure durumundaki veya yükümlülük durumundaki güncellemeler için denetim günlüklerini ya da geçmiş tablolarını izleyin.

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

Veri çıkarma rehberleri

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

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

Talepleri işleme verilerinizi analize hazırlamak ve içgörüler elde etmek için bu Templatetan yararlanın. İş akışlarınızı bugün iyileştirmeye başlayın.

Hasar işlemlerini hızlandırın, dosyaları şimdi daha hızlı sonuçlandırın

Birikmiş işleri ortadan kaldırın, sahtekarlığı önleyin ve %70 oranında straight-through processing hedefleyin.

Ücretsiz denemeyi başlatın

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