Hasar Süreçleri Data Şablonunuz

Guidewire ClaimCenter
Hasar Süreçleri Data Şablonunuz

Hasar Süreçleri Data Şablonunuz

Hasar süreçlerini optimize etmeye adanmış kaynağınıza hoş geldiniz. Bu şablon, toplanması gereken temel data attributelerini, takip edilecek kritik activityleri özetler ve data extraction için net rehberlik sağlar. Kapsamlı process analizi için gerekli tüm bilgileri yakaladığınızdan emin olmak için bunu kullanın.
  • Toplanması Önerilen Nitelikler
  • Takip Edilmesi Gereken Temel Aktiviteler
  • Guidewire ClaimCenter için Veri Çekme Rehberliği
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Hasar İşleme Nitelikleri

Bu önerilen data alanları, hasar işleme workflow'larınızı etkili bir şekilde analiz etmek için eksiksiz bir event log oluşturmak açısından kritik öneme sahiptir.
3 Gerekli 4 Önerilen 15 İsteğe Bağlı
AdAçıklama
Claim ID
ClaimID
Her bir sigorta hasarı için birincil case tanımlayıcısı olarak hizmet eden benzersiz ID.
Açıklama

Hasar ID, hasar süreci analizinin temel taşıdır ve her case'i başvurusundan kapanışına kadar benzersiz bir şekilde tanımlar. İlişkili tüm aktiviteleri, belgeleri, ödemeleri ve iletişimleri birbirine bağlayarak bir hasarın yaşam döngüsüne eksiksiz ve tutarlı bir bakış açısı sunar.

Process Mining'de, data setindeki her event bir Hasar ID'sine bağlıdır. Bu sayede uçtan uca süreç akışı yeniden yapılandırılabilir. Bu, döngü sürelerini analiz etmek, süreç varyantlarını belirlemek ve bir hasarın farklı departmanlar ve eksperler arasındaki yolculuğunu takip etmek için kritik öneme sahiptir.

Neden önemli

Tüm ilgili event'leri birbirine bağlayan temel anahtar olup, tek bir hasarın tüm yolculuğunu takip etmeyi ve analiz etmeyi mümkün kılar.

Nereden alınır

Bu, Guidewire ClaimCenter'da birincil bir anahtardır ve genellikle çekirdek Hasar varlığındaki Claim.ClaimNumber veya benzeri bir alan olarak bulunur.

Örnekler
000-123-45678000-987-65432001-456-11223
Faaliyet Adı
ActivityName
Hasar yaşam döngüsünde belirli bir noktada meydana gelen iş aktivitesinin veya event'in adı.
Açıklama

Bu özellik, 'Dosya Oluşturuldu', 'Soruşturma Başladı' veya 'Ödeme Yapıldı' gibi dosya sürecindeki belirli bir adımı veya dönüm noktasını tanımlar. Belirli bir Claim ID'si için bu aktivitelerin sırası, süreç akışını (process flow) oluşturur.

Aktiviteler arasındaki sırayı, sıklığı ve süreyi analiz etmek, Process Mining'in temelini oluşturur. Bu analiz, süreç modellerinin keşfedilmesine, darboğazların belirlenmesine, yeniden işleme döngülerinin (rework loops) tespit edilmesine ve süreç sapmalarının analiz edilmesine olanak tanır.

Neden önemli

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

Nereden alınır

Bu, genellikle ClaimCenter'daki event tablolarından veya audit log'larından türetilir; genellikle belirli sistem eventlerini veya durum değişikliklerini standartlaştırılmış activity isimleriyle eşleştirerek elde edilir.

Örnekler
Hasar OluşturulduSorumluluk Kararı VerildiÖdeme YapıldıHasar Kapatıldı
Olay Zamanı
EventTime
Aktivitenin meydana geldiği kesin tarih ve saat.
Açıklama

Bu timestamp, bir activitynin sisteme kaydedildiği tam anı işaretler. Tüm zaman tabanlı process analizi için temeldir.

Tek bir Hasar ID'si için EventTime'ın kronolojik sıralaması, process flow'un yeniden oluşturulmasına olanak tanır. Art arda gelen eventler arasındaki zaman farkı, performans analizi, darboğaz tespiti ve SLA izlemesi için kritik olan cycle timeları, bekleme sürelerini ve processing timeları hesaplamak için kullanılır.

Neden önemli

Bu timestamp, eventleri sıralamak, cycle time ve süreleri hesaplamak ve süreçteki gecikmeleri belirlemek için esastır.

Nereden alınır

Guidewire ClaimCenter'ın geçmiş veya denetim tablolarındaki olay veya faaliyet verilerinin yanında bulunur, genellikle 'CreateTime' veya 'UpdateTime' alanı olarak.

Örnekler
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
Atanan Eksper
AssignedAdjuster
Hasarı veya belirli bir aktiviteyi yönetmekle görevlendirilen kullanıcının adı veya ID'si.
Açıklama

Bu özellik, belirli bir zamanda bir dosyanın sorumluluğunu üstlenen hasar görevlisini tanımlar. Bir hasar görevlisi, dosyanın tamamına veya içindeki belirli görevlere atanabilir.

Atanmış Hasar Görevlisine göre analiz yapmak, iş yükü dengeleme, performans yönetimi ve eğitim fırsatlarını belirlemek için kritik öneme sahiptir. Bu, 'Hangi hasar görevlilerinin iş yükü en fazla?', 'Hasar görevlileri arasında performans farklılıkları var mı?' ve 'İş adil bir şekilde dağıtılıyor mu?' gibi soruların yanıtlanmasına yardımcı olur.

Neden önemli

Kullanıcı katılımını takip ederek iş yükü analizi, performans karşılaştırması ve kaynakla ilgili darboğazların tespit edilmesini sağlar.

Nereden alınır

ClaimCenter'daki Talep (Claim) veya Teminat (Exposure) varlığında bulunur, genellikle Kullanıcı nesnesine (örneğin, Claim.Assignee) bağlıdır.

Örnekler
j.doem.smiths.jones
Hasar Durumu
ClaimStatus
Event anındaki hasarın genel durumu (örn: Açık, Kapalı, Reddedildi).
Açıklama

Bu özellik, dosyanın üst düzey durumunu yansıtır. Başlıca durumlar arasında 'Açık', 'Kapalı', 'Reddedildi' ve 'Yeniden Açıldı' bulunur. Bir dosyanın nihai durumu, kritik bir sonuç metridir.

Dosya Durumu'ndaki değişiklikleri izlemek, temel süreç dönüm noktalarını ve sonuçlarını tanımlamaya yardımcı olur. Bu, bir dosyanın nihai çözümünü belirlemek, reddetme oranlarını hesaplamak ve kapanış sonrası dosyaların yeniden açılma sıklığını analiz etmek için kullanılır; bu durum genellikle süreç sorunlarına veya müşteri memnuniyetsizliğine işaret eder.

Neden önemli

Reddetme oranları, kapanış modelleri ve hasar yeniden açılma sıklıklarını analiz etmek için kritik olan bir hasarın sonucunu belirtir.

Nereden alınır

Bu, Hasar varlığı üzerinde yer alan, genellikle 'Durum' veya 'Statü' olarak adlandırılan temel bir alandır.

Örnekler
AçıkKapalıReddedildiYeniden Açıldı
Hasar Nedeni
LossCause
Hasar event'inin belirli nedeni veya sebebi (örn: Çarpışma, Yangın, Su Hasarı).
Açıklama

Bu özellik, dosyanın neden açıldığına dair detaylı bağlam sağlar. Hasarın nedeni (Cause of Loss), genellikle gerekli soruşturma adımlarını, ihtiyaç duyulan uzman türlerini ve dosyanın genel karmaşıklığını belirler.

Hasar Nedenine göre süreci analiz etmek, gizli kalıpları ortaya çıkarabilir. Örneğin, 'Su Hasarı' ile ilgili dosyalar, 'Hırsızlık' dosyalarına kıyasla daha yüksek yeniden işleme (rework) oranına sahip olabilir veya daha fazla uzman katılımı gerektirebilir. Bu içgörüler, daha özel ve verimli işleme prosedürleri oluşturmaya yardımcı olur.

Neden önemli

Hasarın niteliği hakkında bağlam sağlayarak, farklı hasar nedenlerinin süreç akışını ve süresini nasıl etkilediğinin analiz edilmesini sağlar.

Nereden alınır

Bu, Hasar varlığı üzerinde standart bir alandır ve genellikle 'Hasar Nedeni' olarak adlandırılır.

Örnekler
CollisionYangınSu HasarıHırsızlık
Hasar Türü
ClaimType
Sigorta hasar talebinin Araç, Konut veya Sorumluluk gibi kategorisi.
Açıklama

Hasar Türü, bir hasarın iş koluna veya kaybın niteliğine göre yapılan temel bir sınıflandırmadır. Farklı hasar türleri genellikle kendine özgü süreçleri takip eder, farklı karmaşıklık seviyelerine sahiptir ve çeşitli düzenlemelere tabidir.

Süreç analizini Hasar Türüne göre segmentlere ayırmak, anlamlı içgörüler elde etmek için hayati öneme sahiptir. Bu sayede, farklı iş kolları arasındaki süreç performansını karşılaştırmak, türe özgü darboğazları belirlemek ve süreç iyileştirme inisiyatiflerini her bir hasar kategorisinin benzersiz özelliklerine göre uyarlamak mümkün olur.

Neden önemli

Farklı türdeki hasarların (örneğin, Otomobil ve Mülk) genellikle farklı süreçleri takip etmesi ve farklı performans hedeflerine sahip olması nedeniyle hasarların segmentlere ayrılmasını sağlar.

Nereden alınır

ClaimCenter'daki Poliçe veya Hasar kayıtlarından elde edilir, genellikle İş Kolu (LOB) koduna göre belirlenir.

Örnekler
Bireysel OtoTicari MülkGenel Sorumlulukİşçi Tazminatı
Bitiş Saati
EndTime
Bir aktivitenin tamamlandığını gösteren timestamp.
Açıklama

Bitiş Zamanı, özellikle 'Soruşturma' veya 'Belge İncelemesi' gibi ölçülebilir bir süreye sahip task'lar için bir aktivitenin tamamlandığını gösterir. Birçok Process Mining aktivitesi anlık olsa da (StartTime yeterlidir), belirgin bir başlangıcı ve bitişi olan aktiviteler her iki timestamp ile daha iyi temsil edilir.

Bu attribute, bekleme süresinden farklı olarak aktivite işlem süresinin hassas bir şekilde hesaplanmasına olanak tanır. Farklı adımlar arasındaki uzun gecikmeleri gözlemlemek yerine, hangi belirli task'ların zaman alıcı olduğunu belirlemeye yardımcı olur.

Neden önemli

Bir faaliyetin tamamlanmasının ne kadar sürdüğünü hassas bir şekilde ölçerek işlem süresini bekleme süresinden ayırır.

Nereden alınır

Bu, activityyi mantıksal olarak sonlandıran sonraki bir eventin bulunmasıyla türetilmesi gerekebilir (örn. 'Devam Ediyor' durumundan 'Tamamlandı' durumuna geçiş).

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

Bu özellik, atanmış hasar görevlisinin bağlı olduğu departmanı veya ekibi, örneğin 'Araç Hasarları', 'Mülk Hasarları' veya 'Özel Soruşturma Birimi' gibi belirtir. Süreç için örgütsel bir bağlam sağlar.

Departmana göre analiz yapmak, süreç performansını organizasyonel düzeyde anlamak için çok önemlidir. Bu, departmanlar arası devir gecikmelerini belirlemeye, ekipler arasındaki verimliliği karşılaştırmaya ve hasar organizasyonu genelinde kaynakları daha etkili bir şekilde tahsis etmeye yardımcı olur.

Neden önemli

Kurumsal bağlam sağlar, farklı ekipler arasında performans analizi yapılmasına olanak tanır ve departmanlar arası devir teslim sorunlarını vurgular.

Nereden alınır

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

Örnekler
Oto Hasar DepartmanıMal Hasar BirimiÖzel Soruşturma Birimi (ÖSB)
Çözüm Hedef Tarihi
ResolutionTargetDate
Hasarın, iç veya yasal SLA'lara göre çözülmesi beklenen tarih.
Açıklama

Çözüm Hedef Tarihi, hasar kapanışı için belirlenen bir son tarihtir ve genellikle yargı alanı, hasar türü ve poliçe koşulları gibi faktörlere göre belirlenir. Performansı ve uyumluluğu ölçmek için bir referans noktası görevi görür.

Bu attribute, SLA uyumu dashboard'ları ve KPI'ları oluşturmak için kritik öneme sahiptir. Gerçek 'Hasar Kapandı' tarihi bu hedef tarihle karşılaştırılarak, analiz otomatik olarak geciken hasarları işaretleyebilir, zamanında tamamlama oranlarını ölçebilir ve hangi hasar türlerinin veya departmanların hedeflerine ulaşmakta zorlandığını belirleyebilir.

Neden önemli

Bu, Hizmet Seviyesi Anlaşması (SLA) uyumunu ölçmek ve geç kalma riski taşıyan hasarları belirlemek için bir kıyas noktasıdır.

Nereden alınır

Bu, ClaimCenter'da yapılandırılmış iş kurallarına dayalı olarak özel bir alan veya türetilmiş bir değer olabilir, muhtemelen belirli hasar metricleriyle ilgilidir.

Örnekler
2023-06-142023-07-202023-08-28
Hasar Tarihi
LossDate
Hasarı tetikleyen olayın veya kaybın meydana geldiği tarih.
Açıklama

Hasar Tarihi, hasara yol açan fiili event'in (örn: trafik kazası, mülk hasarı) meydana geldiği tarihtir. Bu, hasarın bildirildiği veya oluşturulduğu tarihten farklıdır.

Hasar Tarihi ile 'Hasar Oluşturuldu' aktivitesi (bildirim gecikmesi olarak bilinir) arasındaki zaman farkı önemli bir KPI'dır. Bunun analizi, müşteri davranışları ve ilk hasar bildirimi kanallarının etkinliği hakkında değerli içgörüler sağlayabilir.

Neden önemli

Hasarın kökeni hakkında kritik bağlam sunar ve raporlama gecikmesinin (olaydan hasar bildirimine kadar geçen süre) analiz edilmesine yardımcı olur.

Nereden alınır

Bu, Hasar varlığı üzerinde yer alan, genellikle 'Hasar Tarihi' olarak adlandırılan temel bir tarih alanıdır.

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

İşlem Süresi, bir aktivite üzerinde aktif olarak çalışılan süreyi ölçer; Bitiş Zamanı ile Başlangıç Zamanı arasındaki fark olarak hesaplanır. Bekleme sürelerini içeren döngü süresinden farklıdır.

Bu hesaplanmış metrik, bir görevin gerçek çabasını boşta kalma veya bekleme süresinden ayırdığı için performans analizi için hayati öneme sahiptir. Hangi adımların gerçekten zaman alıcı olduğunu ve eğitim, daha iyi araçlar veya süreç yeniden tasarımı yoluyla verimlilik kazanımlarının nerede sağlanabileceğini doğru bir şekilde belirlemeye yardımcı olur.

Neden önemli

Bir aktivitenin aktif çalışma süresini ölçer, katma değerli zamanı bekleme süresinden ayırmaya yardımcı olur.

Nereden alınır

Hesaplanmış alan: EndTime - StartTime. Kaynak verilerde her iki zaman damgasının da mevcut olmasını gerektirir.

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

Bu özellik, event verisinin kaynağını tanımlar. Modern bir kurumsal ortamda, dosya ile ilgili event'ler, Guidewire gibi bir ana sistem, bir doküman yönetim sistemi veya bir müşteri portalı gibi birden fazla sistemden kaynaklanabilir.

Kaynak sistemi belirtmek, veri yönetimi (data governance), veri tutarsızlıklarını giderme (troubleshooting data inconsistencies) ve sürecin teknolojik yapısını anlamak için çok önemlidir. Bu, temel süreç adımları ile çevre sistemlerden gelen destekleyici aktiviteler arasında ayrım yapmaya yardımcı olur.

Neden önemli

Veri yönetimi ve birden fazla entegre sistem içeren analizler için kritik olan verilerin kaynağını belirler.

Nereden alınır

Bu, genellikle data extraction, transformation ve loading (ETL) süreci sırasında eklenen statik bir değerdir.

Örnekler
Guidewire ClaimCenter v10Customer Portal APIDocumentum
Ödeme Tutarı
PaymentAmount
Bir ödeme aktivitesi için ödenen fiili miktar.
Açıklama

Bu özellik, bir dosyaya yapılan her bir ödemenin değerini kaydeder. Bir dosya, yaşam döngüsü boyunca birden fazla ödeme içerebilir.

Bu, Process Mining bağlamında finansal analiz için çok önemlidir. Dosya başına toplam ödemeyi izlemek, miktara göre ödeme onay sürelerini analiz etmek ve süreç verimsizliklerini finansal sonuçlarla ilişkilendirmek için kullanılabilir. Örneğin, uzun döngü sürelerine (cycle times) sahip dosyalar, daha yüksek toplam ödemelerle ilişkili olabilir.

Neden önemli

Bir hasar içindeki finansal transactionları takip ederek, ödeme değerlerinin ve bunların process activityleri ile ilişkisinin analiz edilmesini sağlar.

Nereden alınır

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

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

Bu boolean özellik, bir sistem tarafından yürütülen (örneğin otomatik rezerv oluşturma, sistem tarafından oluşturulan yazışmalar) aktiviteler ile bir hasar görevlisi tarafından manuel olarak gerçekleştirilenleri ayırt eder.

Bu özelliği analiz etmek, dosya sürecindeki otomasyon seviyesini anlamak için anahtardır. Manuel müdahale noktalarını belirlemeye, düz işlem (straight-through processing) girişimlerinin etkinliğini ölçmeye ve şu anda insanlar tarafından yapılan tekrarlayan, kural tabanlı görevleri tespit ederek yeni otomasyon fırsatları bulmaya yardımcı olur.

Neden önemli

Sistem ve insan odaklı faaliyetler arasındaki farkı ortaya koyar; bu, otomasyon analizi ve manuel darboğazların belirlenmesi için anahtar niteliğindedir.

Nereden alınır

Bu genellikle türetilmesi gereken bir bilgidir. Örneğin, genel bir 'sistem' kullanıcısı tarafından günlüğe kaydedilen eventler otomatik olarak işaretlenebilir.

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

Poliçe Türü, Hasar Türü'nden daha ayrıntılı bir sınıflandırma sunarak, 'Konut Sigortası', 'Ticari Oto' veya 'Siber Sorumluluk' gibi belirli sigorta ürünlerini detaylandırır. Bu detay seviyesi, belirli ürünlere bağlı süreç varyasyonlarını ortaya çıkarabilir.

Poliçe Türüne göre süreci analiz etmek, ürüne özgü verimsizlikleri keşfetmeye yardımcı olur. Örneğin, yeni başlatılan bir poliçeye ait hasarlar, daha az olgun bir süreci takip edebilir ve bu da gecikmelere yol açabilir. Bu analiz, ürün tasarımına ve süreç standardizasyon çalışmalarına bilgi sağlayabilir.

Neden önemli

Belirli sigorta ürünlerine yönelik süreç analizini mümkün kılar, poliçe detaylarına göre işlem farklılıklarının belirlenmesine yardımcı olur.

Nereden alınır

Bu bilgi, Poliçe varlığında bulunur ve Hasar ile ilişkilidir.

Örnekler
Konut Sahipleri Çoklu Risk SigortasıCommercial Auto Liabilityİç Deniz Nakliyat
SLA Statüsü
SLAState
Hasarın çözüm hedef tarihi içinde kapatılıp kapatılmadığını belirtir.
Açıklama

Bu hesaplanmış özellik, her kapanmış dosya için SLA uyumluluğunun kategorik bir durumunu sağlar. Bu, 'Dosya Kapandı' aktivitesinin timestamp'i ile 'Çözüm Hedef Tarihi'nin karşılaştırılmasıyla türetilir.

Bu özellik, analizi 'Zamanında' veya 'Gecikti' gibi net kategorilere ayırarak 'Dosya Çözüm Hedefi Uyumluluğu' dashboard'unu doğrudan destekler. Genel SLA uyumluluk oranını hesaplamak ve gecikmelerin nedenlerini derinlemesine incelemek için kolay filtreleme ve toplama imkanı sunar.

Neden önemli

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

Nereden alınır

Hesaplanmış alan: EĞER (ActualCloseDate <= ResolutionTargetDate, 'Zamanında', 'Gecikmeli').

Örnekler
ZamanındaGecikmiş
Son Veri Güncellemesi
LastDataUpdate
Data'nın kaynak sistemden en son ne zaman yenilendiğini veya çıkarıldığını gösteren timestamp.
Açıklama

Bu özellik, kaynak sistemden en son veri çekiminin (data pull) timestamp'ini sağlar. Analizin güncelliğini anlamak için gerekli olan bir metadata alanıdır.

Dashboard'lar ve analizler bu bilgiyi belirgin bir şekilde göstermelidir, böylece kullanıcılar verinin güncelliğinin farkında olurlar. Bu, elde edilen içgörülerin operasyonların mevcut durumunu yansıtıp yansıtmadığını veya eski verilere mi dayandığını değerlendirmeye yardımcı olur.

Neden önemli

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

Nereden alınır

Bu değer, ETL süreci sırasında oluşturulur ve saklanır; data load'unun timestampini temsil eder.

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

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

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

Neden önemli

Yüksek değerli hasarların farklı, daha karmaşık süreçleri takip edebilmesi nedeniyle hasarların finansal değere göre segmentlere ayrılmasını sağlar.

Nereden alınır

Bu bilgi tek bir alan olmayabilir, ancak maruziyetler üzerine kaydedilen ilk zarar tahminlerinden türetilebilir.

Örnekler
5000.00150000.00750.50
Tekrarlanan Bilgi Talebi
RepeatedInfoRequestFlag
Aynı hasar için 'Ek Bilgi Talep Edildi' aktivitesinin birden fazla kez gerçekleşip gerçekleşmediğini gösteren bir işaretçi.
Açıklama

Bu boolean flag, bir dosyanın birden fazla 'Ek Bilgi Talebi' aktivitesine sahip olması durumunda doğru olarak ayarlanır. Bu senaryo, genellikle ilk bilgi toplama aşamasındaki verimsizliklere işaret eder.

Bu özellik, 'Tekrarlayan Bilgi Talep Oranı' KPI'ını doğrudan destekler. Eksik ilk bilgi toplama sorununu nicelleştirmeye yardımcı olur; bu da önemli gecikmelere ve müşteri memnuniyetsizliğine yol açabilir. Bu flag'e sahip dosyaları analiz etmek, hasar görevlileri için tüm gerekli bilgilerin tek seferde istenmesini sağlamak amacıyla kontrol listelerini ve prosedürleri iyileştirmeye yardımcı olabilir.

Neden önemli

İlk seferde eksiksiz bilgi toplanamadığı durumlardan kaynaklanan süreç gecikmelerini ve yeniden işlemeleri tespit eder.

Nereden alınır

Process Mining aracı içinde, her vaka başına 'Ek Bilgi Talep Edildi' aktivitesinin gerçekleşme sayısını sayarak hesaplanır.

Örnekler
truefalse
Yargı Yetkisi Eyaleti
JurisdictionState
Hasarı yöneten eyalet veya yargı alanı, düzenleyici gereksinimleri belirler.
Açıklama

Bu özellik, dosyanın işlem gördüğü yasal yetki alanını (örneğin ABD eyaleti) belirtir. Sigorta düzenlemeleri, yetki alanları arasında önemli ölçüde farklılık gösterebilir; bu da gerekli süreç adımlarını, iletişim sürelerini ve dokümantasyonu etkiler.

Bu, uyumluluk izleme (compliance monitoring) için hayati bir özelliktir. Süreci yetki alanına göre analiz etmek, eyalete özgü düzenleyici gereksinimlerin karşılandığından emin olunmasını sağlar. Ayrıca, döngü sürelerindeki (cycle times) veya operasyonel verimsizlikten ziyade yasal kısıtlamalar tarafından yönlendirilen süreç yollarındaki farklılıkları da açıklayabilir.

Neden önemli

Farklı yargı bölgelerinin hasar sürecini etkileyen farklı düzenlemeleri olduğu için uyumluluk analizi için kritik öneme sahiptir.

Nereden alınır

Talep (Claim) varlığında yer alan, genellikle 'JurisdictionState' olarak adlandırılan standart bir alan.

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

Bu hesaplanmış özellik, yeniden işleme (rework) döngüsünün bir parçası olan aktiviteleri işaretler. Örneğin, süreç 'Soruşturma Tamamlandı'dan 'Soruşturma Başladı'ya geri dönerse, ikinci 'Soruşturma Başladı' aktivitesi yeniden işleme olarak işaretlenir.

Yeniden işlemeyi (rework) tespit etmek, süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarmak için temeldir. Yeniden İşleme ve Reddetme Sıklığı dashboard'u, dosyaların ideal 'happy path'ten ne sıklıkta saptığını nicelleştirmek için bu metriğe dayanır. Yeniden işleme nedenlerini analiz etmek, süreç kalitesinde ve hızında önemli iyileşmelere yol açabilir.

Neden önemli

Tekrarlayan iş döngüsünün bir parçası olan faaliyetleri açıkça işaretleyerek süreç verimsizliklerini ve kalite sorunlarını ortaya çıkarır.

Nereden alınır

Bu, process mining aracında her bir case için activity dizisinin analiz edilmesiyle hesaplanır.

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

Hasar İşleme Aktiviteleri

Bunlar, hassas hasar süreci keşfi ve analizi için event log'unuzda yakalamanız gereken temel süreç adımları ve önemli dönüm noktalarıdır.
7 Önerilen 7 İsteğe Bağlı
AktiviteAçıklama
Hasar Kapatıldı
Tüm faaliyetler ve ödemeler tamamlandıktan sonra bir hasarın başarılı bir şekilde kapatıldığını gösterir. Bu, hasarın ana durumundaki bir değişiklikten çıkarılan birincil başarılı bitiş olayıdır.
Neden önemli

Birincil bitiş olayı olarak bu aktivite, uçtan uca çevrim süresini hesaplamak ve Hizmet Seviyesi Anlaşması (HSA) uyumluluğunu ölçmek için hayati öneme sahiptir. Hasar yaşam döngüsünün tamamlandığını gösterir.

Nereden alınır

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

Yakala

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

Event tipi inferred
Hasar Oluşturuldu
Bu aktivite, ilk hasar bildirimini (FNOL) ve Guidewire ClaimCenter'da yeni bir dosya kaydının resmi olarak oluşturulmasını gösterir. Yeni bir Claim entity'si veritabanına ilk kez kaydedildiğinde açıkça yakalanır.
Neden önemli

Birincil başlangıç olayı olarak bu aktivite, uçtan uca hasar çevrim süresini ölçmek için hayati öneme sahiptir. Sonraki tüm performans ve süre KPI'ları için temel teşkil eder.

Nereden alınır

Bu, cc_claim tablosunun CreateTime değerinden yakalanan açık bir eventtir. Benzersiz bir Hasar ID'si ile yeni bir kaydın oluşturulması, event tetikleyicisi olarak işlev görür.

Yakala

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

Event tipi explicit
Hasar Reddedildi
Bir hasarın reddedilmesi yönündeki nihai kararı temsil eder ve süreç için bir bitiş noktası görevi görür. Bu event, hasarın durumunun 'Reddedildi' sebebiyle kapalı bir duruma geçmesinden anlaşılır.
Neden önemli

Bu, kritik bir sonuç olayıdır. Reddedilmelerin sıklığını, nedenlerini ve bu reddedilmelere yol açan süreç yollarını analiz etmek; hasar girişi, soruşturma veya poliçe yorumlamasındaki sorunları tespit etmeye yardımcı olur.

Nereden alınır

cc_claim tablosunun State alanının 'Closed' olarak değiştirilmesinden ve CloseReason alanının 'Denied' veya benzeri bir değer olmasından çıkarılır. Olayın zaman damgası CloseDate'tir.

Yakala

Hasar durumu 'Kapandı' olarak değiştiğinde ve neden kodu reddi gösterdiğinde filtreleme yapın.

Event tipi inferred
İlk Rezerv Oluşturuldu
Bir risk için ilk finansal karşılık işleminin oluşturulduğunu gösterir ve hasarın potansiyel maliyetini tahmin eder. Bu kritik bir finansal olaydır ve açıkça kaydedilir.
Neden önemli

Bu kilometre taşı, finansal analiz ve potansiyel sorumluluğun ne kadar hızlı değerlendirildiğini anlamak için anahtardır. Gecikmeler, finansal planlama ve raporlamayı etkileyebilir.

Nereden alınır

Bu event, dosyada bir exposure ile ilişkili ilk cc_reserveline kaydının oluşturulmasından yakalanır. Bu transaction'ın CreateTime değeri, event'in timestamp'idir.

Yakala

Belirli bir hasarın rizikoları için tüm provizyon kalemlerinin minimum oluşturma zaman damgasını bulun.

Event tipi explicit
Ödeme Onaylandı
Bir tazminat ödemesinin resmi onayını temsil eder. Bu, kritik bir denetim event'idir ve yetkili bir kullanıcı işlemi onayladığında açıkça kaydedilir.
Neden önemli

Bu anahtar kilometre taşı, son ödeme adımının önünü açar. Bu activity öncesi ve sonrası süreyi analiz etmek, onay workflowları veya yönetici müsaitliği nedeniyle oluşan gecikmeleri izole etmeye yardımcı olur.

Nereden alınır

Bu, genellikle bir cc_check veya cc_transaction varlığıyla ilgili cc_history tablosunda günlüğe kaydedilen, 'Onay Bekliyor' durumundan 'Onaylandı' durumuna geçişi gösteren açık bir eventtir.

Yakala

Belirli bir ödeme transaction'ı için durum değişikliği eventini 'Onaylandı' olarak takip edin.

Event tipi explicit
Ödeme Yapıldı
Bu aktivite, ödemenin resmi olarak yapıldığı ve finansal sisteme gönderildiği ödeme sürecindeki son adımdır. Bu, açıkça kaydedilmiş bir finansal işlemdir.
Neden önemli

Bu aktivite, ödeme gönderim sürecinin verimliliğini ölçmek için kritik öneme sahiptir. Onay gecikmeleri ile fonların fiilen ödenmesindeki gecikmeleri ayırt etmeye yardımcı olur.

Nereden alınır

cc_check veya cc_transaction varlığındaki IssueDate alanından ya da durumun 'Issued' veya 'Submitted' olarak değişmesinden yakalanmıştır. Bu genellikle açıkça belirtilmiş bir timestamped event'tir.

Yakala

Ödeme kaydındaki 'Issued' durum değişikliğinin IssueDate veya zaman damgasını belirleyin.

Event tipi explicit
Riziko Oluşturuldu
Bu aktivite, bir dosya kapsamındaki belirli bir potansiyel sorumluluğu veya hasar türünü (örneğin araç hasarı, yaralanma) temsil eden bir exposure oluşturulduğunu gösterir. Bu, Guidewire'da açıkça kaydedilmiş bir event'tir.
Neden önemli

Rizikolar, hasar segmentasyonu ve analizi için temeldir. Bunların oluşturulmasını takip etmek, hasar karmaşıklığına ve zarar türüne göre süreç farklılıklarını anlamaya yardımcı olur.

Nereden alınır

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

Yakala

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

Event tipi explicit
Ek Bilgi Alındı
Ek bilgi talebinin tamamlandığını gösterir. Bu, bilgi talebiyle ilgili 'Aktivite' (görev) 'Tamamlandı' olarak işaretlendiğinde kaydedilir.
Neden önemli

Bu, 'Ek Bilgi Toplama Döngü Süresi' KPI'sı için bitiş noktasıdır. Talep ve makbuz arasındaki uzun süreler, hasar sürecindeki gecikmelerin yaygın nedenleridir.

Nereden alınır

ActivityPattern'ın bir bilgi talebiyle ilgili olduğu bir cc_activity kaydının CloseTime değerinden alınmıştır. Aktivitenin durumu 'Completed' (Tamamlandı) olmalıdır.

Yakala

Harici bilgi talep etme görevinin tamamlanma zaman damgasını belirleyin.

Event tipi explicit
Ek Bilgi Talep Edildi
Hak sahibine veya üçüncü bir tarafa gönderilen daha fazla bilgi veya belge talebini temsil eder. Bu durum, genellikle ClaimCenter'da oluşturulan açık bir 'Aktivite' (görev) olarak kaydedilir.
Neden önemli

Bu aktivite, 'Ek Bilgi Toplama Döngü Süresi' KPI'ını ölçmek için başlangıç noktasıdır. Sık sık tekrarlanması, eksik FNOL süreçlerine veya verimsiz bilgi toplamaya işaret edebilir.

Nereden alınır

Harici bir taraftan belge veya bilgi talep etmeyle ilgili ActivityPattern'e sahip bir cc_activity kaydının CreateTime alanından yakalanmıştır.

Yakala

Harici bilgi talep etme görevinin oluşturulmasını belirleyin.

Event tipi explicit
Hasar Atandı
Bir hasar dosyasının belirli bir kullanıcıya (eksper/sorumlu) veya gruba atanmasını temsil eder. Bu durum, genellikle Hasar entity'si üzerindeki atama alanlarındaki değişiklikler izlenerek anlaşılır.
Neden önemli

Atamaları takip etmek, eksper iş yükünü analiz etmek, yönlendirme darboğazlarını belirlemek ve atanmış eksperin ilk eyleme geçme süresini ölçmek için kritiktir.

Nereden alınır

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

Yakala

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

Event tipi inferred
Hasar Yeniden Açıldı
Bir hasarın ek çalışma yapmak üzere 'Kapalı' durumdan tekrar 'Açık' duruma geçirilmesini temsil eder. Bu olay, belirli bir durum değişikliği dizisinden çıkarılır.
Neden önemli

Bu aktivite, yeniden işleme (rework) anlamına gelir. Yeniden açılan dosyaların yüksek sayısı, ilk uzlaşmada, gözden kaçan hasarlarda veya diğer süreç hatalarında sorunlar olduğunu göstererek maliyetleri ve verimsizliği artırır.

Nereden alınır

cc_history tablosundan, cc_claim varlığının State alanının 'Closed' durumundan tekrar 'Open' veya başka bir aktif duruma geçtiği tespit edilerek çıkarılır.

Yakala

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

Event tipi inferred
Ödeme Hesaplandı
Bu aktivite, bir uzlaşma miktarının belirlendiği ancak ödeme için henüz onaylanmadığı noktayı temsil eder. 'Onay Bekliyor' durumunda bir ödeme oluşturulmasından çıkarılabilir.
Neden önemli

Değerlendirmeden ödemeye geçişi işaret eder. Onay zincirindeki gecikmeleri ortaya koyan 'Ödeme Yetkilendirme Süresi' KPI'ını ölçmek için başlangıç noktasıdır.

Nereden alınır

Başlangıç durumu 'Pending Approval' veya 'Approved' öncesi benzer bir durum olan bir cc_check veya cc_transaction kaydının CreateTime'ından çıkarılır.

Yakala

Ön onaylı durumda bir ödeme veya işlem kaydının oluşturulmasını belirleyin.

Event tipi inferred
Sorumluluk Kararı Verildi
Bir risk için sorumluluk veya kusur kararının belirlendiği noktayı temsil eder. Bu event, genellikle Risk entity'si üzerindeki bir status değişikliğinden anlaşılır.
Neden önemli

Bu, ödeme ve tazminat aşamalarının önünü açan kritik bir karar aşamasıdır. Bu kararın alınma süresini analiz etmek, araştırma ve değerlendirme aşamalarındaki darboğazları belirlemeye yardımcı olur.

Nereden alınır

cc_history tablosundan, cc_exposure varlığı üzerindeki State veya özel bir sorumluluk durumu alanındaki bir değişiklik izlenerek çıkarılır. Geçmiş kaydının zaman damgası olay zamanını belirtir.

Yakala

Risk durumunun veya sorumluluk statüsünün güncellemeleri için denetim kayıtlarını veya geçmiş tablolarını izleyin.

Event tipi inferred
Soruşturma Başladı
Bir hasar veya maruziyet için soruşturma aşamasının resmi başlangıcını gösterir. Bu durum, genellikle Guidewire'da ilk soruşturma ile ilgili 'Faaliyet' (görev) oluşturulmasından çıkarılır.
Neden önemli

Bu aktivite, genellikle uzun süren önemli bir aşamanın başlangıcını işaret eder. Soruşturmanın başlangıcına kadar geçen süreyi ve soruşturmanın kendi süresini analiz etmek, büyük darboğazları ortaya çıkarır.

Nereden alınır

ActivityPattern'ın soruşturma ile ilgili olduğu (örneğin, 'Initial Investigation', 'Contact Witness') bir cc_activity kaydının CreateTime'ından çıkarılır.

Yakala

Soruşturma ile ilgili bir desen veya konuya sahip ilk görevin oluşturulmasını belirleyin.

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

Veri Çekim Kılavuzları

Verilerinizi Guidewire ClaimCenter'dan Nasıl Alırsınız?