Hasar Süreçleri Veri Template'inuz

Sapiens ClaimsPro
Hasar Süreçleri Veri Template'inuz

Hasar Süreçleri Veri Template'inuz

Bu şablon, talep işleme iş akışını (workflow)nuzu analiz etmek için gerekli verileri toplama konusunda detaylı bir rehber sunar. Sapiens ClaimsPro'ya özel pratik veri veri çekme kılavuzuyle birlikte, izlenecek temel öznitelikler.i ve faaliyetleri özetlemektedir. Veri toplama sürecinizi iyileştirmek ve derinlemesine Process Mining analizlerine hazırlanmak için bu kaynağı kullanın.
  • Talep verisi toplama için önerilen nitelikler
  • Talep sürecinizde izlenecek temel aktiviteler
  • Sapiens ClaimsPro için adım adım veri veri çekme kılavuzu
Olay günlüklerine (Event Log) yeni mi başlıyorsunuz? Öğrenin Process Mining event log nasıl oluşturulur.

Hasar Yönetimi Öznitelikleri

Bunlar, detaylı hasar işleme analizi gerçekleştirmek ve verimsizlikleri tespit etmek için event lognüze (event log) dahil etmeniz önerilen data (veri) alanlarıdır.
3 Gerekli 6 Önerilen 10 Opsiyonel
Ad Açıklama
Aktivite Adı
ActivityName
Hasar sürecinde belirli bir aşamada gerçekleşen iş adımının veya olayın adı.
Açıklama

Bu nitelik, 'Talep Gönderildi', 'İlk İnceleme Yapıldı' veya 'Ödeme Gerçekleşti' gibi bir tazminat süreci içindeki tek bir adımı veya görevi açıklar. Her aktivite, sürecin bir başlangıç ve potansiyel bir bitiş zamanına sahip belirli bir noktasını temsil eder.

Aktiviteleri analiz etmek, Process Mining'in merkezindedir. Bu sayede süreç haritası görselleştirilebilir, adımlar arasındaki darboğazlar tespit edilebilir, aktivite sıklığı analiz edilebilir ve süreç varyasyonları anlaşılabilir. Belirli bir Claim ID için aktivite dizisi, süreç akışının temelini oluşturur.

Neden Önemli?dir?

Süreç adımlarını tanımlar; bu, süreç haritası oluşturmak, darboğazları veya verimsizlikleri belirlemek için büyük önem taşır.

Nereden Alınır??

Genellikle Sapiens ClaimsPro içindeki olay log'larından, durum değişikliği kayıtlarından veya görev tamamlama tablolarından türetilir. Durum kodlarından veya işlem türlerinden eşleme gerektirebilir.

Örnekler:::::::
Hasar Talebi KaydedildiSoruşturma BaşladıÖdeme HesaplandıHasar Kapatıldı
Claim ID
ClaimId
Her sigorta talebi için benzersiz tanımlayıcı olup, talebin süreç döngüsünü takip etmek için birincil case ID'si olarak olarak kullanılır.
Açıklama

Claim ID (Hasar Kimliği), tek bir sigorta talebiyle ilişkili tüm olayları ve aktiviteleri birbirine bağlayan temel vaka (case) tanımlayıcısıdır. Bu, bir talebin ilk başvurusundan nihai kapanışına kadar tüm sürecinin tutarlı bir şekilde yeniden yapılandırılmasını ve analiz edilmesini sunar.

Process Mining'de, her event log girişi bir Claim ID ile ilişkilendirilmelidir. Bu sayede araç, her talebin eksiksiz yolunu izleyebilir, süreç varyantlarını görselleştirebilir, uçtan uca döngü sürelerini hesaplayabilir ve standart workflow'dan sapmaları veya darboğazları belirleyebilir. Verileri Hasar Kimliği (Claim ID) üzerinden analiz etmek, talebin yolculuğunun eksiksiz bir resmini sunar.

Neden Önemli?dir?

Tüm ilgili aktiviteleri tek bir süreç örneğinde gruplandırmak için büyük önem taşır ve talep süreç döngüsünün uçtan uca analizini sunar.

Nereden Alınır??

Bu, Sapiens ClaimsPro içindeki ana talep işlem tablosunda bir birincil büyük önem taşır (primary key). Tam tablo ve alan adı için sistem belgelerine başvurun.

Örnekler:::::::
CL-2023-001, 2, 3, 4CL-2023-005678CL-2024-009101
Olay Zaman Damgası
EventTimestamp
Belirli bir aktivitenin veya olayın başladığı tam tarih ve saat.
Açıklama

Event zaman damgası (zaman damgası), hasar sürecindeki her aktivitenin başlangıç zamanını kaydeder. Bu, olayları sıralamak ve aralarındaki süreleri hesaplamak için gerekli kronolojik bağlamı sunar. Bu zaman damgası (zaman damgası), event lognun temel zaman referansıdır.

Process Mining analizinde, bu nitelik döngü süreleri, bekleme süreleri ve aktivite süreleri dahil olmak üzere zamanla ilgili tüm metrikleri hesaplamak için büyük önem taşır. Ne zaman ne olduğuna dair olgusal bir temel sağlayarak darboğazların keşfedilmesini, zaman içindeki süreç performansının analizini ve SLA uyumluluğunun izlenmesini sunar.

Neden Önemli?dir?

Bu zaman damgası (zaman damgası), olayları kronolojik olarak sıralamak ve cycle time (döngü süresi) ve bottlenecks (darboğazlar) gibi tüm süre tabanlı metrikleri hesaplamak için gereklidir.

Nereden Alınır??

Sapiens ClaimsPro'daki aktivite veya durum değişikliği bilgileriyle birlikte olay veya işlem günlüğü tablolarında bulunur.

Örnekler:::::::
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
Atanan Departman
AssignedDepartment
Hasar talebini belirli bir aşamada yürütmekten sorumlu departman veya ekip.
Açıklama

Bu nitelik, 'İlk Kabul', 'Karmaşık Talepler' veya 'SIU (Özel Soruşturma Birimi)' gibi bir talebe veya aktiviteye atanmış iş birimini veya ekibi gösterir. Bu sayede süreç, departman bazında analiz edilebilir.

Departmana göre analiz yapmak, belirli ekiplere özgü darboğazları belirlemeye, departmanlar arası devirleri anlamaya ve departman verimliliğini değerlendirmeye yardımcı olur. 'Adjuster & Department Activity Load' kontrol paneli'u ve daha üst düzey organizasyonel süreç analizi için büyük önem taşır.

Neden Önemli?dir?

Farklı ekipler arasındaki süreç performansının ve devir teslimlerinin analizini sağlayarak organizasyonel darboğazları ortaya çıkarır.

Nereden Alınır??

Genellikle sistemdeki kullanıcı profiliyle ilişkilendirilir veya doğrudan talep nesnesine atanır. Sapiens ClaimsPro belgelerine başvurun.

Örnekler:::::::
Oto Hasar DepartmanıMülk Hasar TalepleriÖzel Soruşturma Birimi
Atanan Eksper
AssignedAdjuster
Hasar talebini veya belirli bir aktiviteyi yürütmekten sorumlu hasar uzmanının adı veya kimliği.
Açıklama

Bu nitelik, talep üzerinde bir eylem gerçekleştiren bireysel kullanıcıyı veya kaynağı tanımlar. Atanan eksperleri takip etmek, iş yükü dağılımını, bireysel performansı ve kaynak tahsisini anlamak açısından büyük önem taşır.

Analizde bu bilgi, farklı eksperlerin talepleri nasıl ele aldığını görmek, performanslarını karşılaştırmak ve potansiyel eğitim fırsatlarını belirlemek için süreç haritasını filtrelemeye sunar. 'Adjuster & Department Activity Load' kontrol paneli'unu oluşturmak ve 'Adjuster Workload Balance' KPI'ını hesaplamak için temel bir bileşendir.

Neden Önemli?dir?

Kaynak analizi için kritik; iş yükü dengesizliklerini, yüksek performans gösterenleri ve eğitim ihtiyaçlarını belirlemeye yardımcı olur.

Nereden Alınır??

Sapiens ClaimsPro'daki kullanıcı aktivite günlüklerinde veya işlem tablolarında bulunur, genellikle bir kaydı oluşturan veya son güncelleyen kullanıcıyla ilişkilidir.

Örnekler:::::::
Can Demirj.smithUSR-00451
Hasar Önem Derecesii
ClaimSeverity
Hasarın karmaşıklığının veya potansiyel finansal etkisinin bir sınıflandırması (örneğin, Düşük, Orta, Yüksek).
Açıklama

Hasar Önem Derecesii, bir hasara atanan, tahmini karmaşıklığını, riskini veya finansal riskini gösteren bir derecelendirmedir. Bu derecelendirme genellikle inceleme düzeyini, eksperden beklenen deneyimi ve izlenecek iş akışını belirler.

Bu nitelik, 'Hasar Önem Derecesii Çevrim Süresi Analizi' kontrol paneli'u için büyük önem taşır. Daha karmaşık hasarların verimli bir şekilde ele alınıp alınmadığını veya uzun çevrim sürelerine orantısız bir şekilde katkıda bulunup bulunmadıklarını anlamaya yardımcı olur. Yüksek şiddetli bir hasarın, düşük şiddetli bir hasardan daha uzun sürmesi beklendiği için, performans metrikleri için hayati bir bağlam sunar.

Neden Önemli?dir?

Döngü süresi analizi için önemli bir bağlam sunar; bazı taleplerin neden diğerlerinden daha uzun sürdüğünü ve karmaşık durumların verimli bir şekilde ele alınıp alınmadığını açıklamaya yardımcı olur.

Nereden Alınır??

Bu, Sapiens ClaimsPro'daki talep özelliklerine dayalı olarak manuel girilen bir alan veya türetilmiş bir puan olabilir.

Örnekler:::::::
DüşükOrtaYüksekKarmaşık
Hasar Türü
ClaimType
Sigorta hasar talebinin Araç, Konut veya Sorumluluk gibi kategorisi.
Açıklama

Hasar Türü, hasarları iş koluna veya kaybın niteliğine göre sınıflandırır. Bu, bir hasarın hangi süreç iş akışını izleyeceğini ve hangi ekiplerin dahil olacağını genellikle belirleyen temel bir segmentasyon niteliğidir.

Hasar Türüne göre süreci analiz etmek, farklı iş kolları arasındaki verimlilik ve prosedür farklılıklarını belirlemek için büyük önem taşır. Örneğin, bir oto hasar süreci yüksek oranda otomatik ve hızlı olabilirken, ticari mülk hasarı süreci karmaşık ve yavaş olabilir. Bu nitelik, 'Ödeme Tutarı Tutarlılık Endeksi' KPI'ını hesaplamak için gereklidir.

Neden Önemli?dir?

Farklı iş kolları arasındaki süreçleri karşılaştırarak her hasar kategorisi için en iyi uygulamaları ve belirli darboğazları belirlemeye sunar.

Nereden Alınır??

Sapiens ClaimsPro'daki ana hasar kaydında standart bir alan. Herhangi bir hasar sistemi için temel bir veri öğesidir.

Örnekler:::::::
Motorlu Araç Maddi HasarGenel Sorumlulukİşçi TazminatıTicari Mülk
Ödeme Tutarı
SettlementAmount
Hasar talebini sonuçlandırmak üzere talep sahibine ödenen nihai parasal miktar.
Açıklama

Bu nitelik, tazminat ödemesinin değerini belirtir. Talebin finansal etkisini ve süreç boyunca alınan kararları yansıtan kilit bir sonuç metriğidir.

Süreç analizinde, Ödeme Tutarı (Settlement Amount), 'Tazminat Kararı ve Ödeme Analizleri' kontrol paneli'unda, süreç varyasyonlarının veya eksper davranışlarının ödeme sonuçlarını nasıl etkilediğini analiz etmek için kullanılır. Aynı zamanda, benzer türdeki taleplerde ödeme kararlarındaki tutarsızlıkları tespit etmeye yardımcı olan 'Settlement Amount Consistency Index' KPI'ı için ana girdilerden biridir.

Neden Önemli?dir?

Bu, temel bir sonuç metriğidir. Süreç varyantlarına göre analiz edilmesi, süreç verimsizliklerinin veya sapmalarının finansal sonuçları nasıl etkilediğini ortaya çıkarabilir.

Nereden Alınır??

Sapiens ClaimsPro'daki hasarla ilişkili finansal veya ödeme işlem tablolarında bulunur.

Örnekler:::::::
5000.001250.75250000.00
Olay Bitiş Zamanı
EventEndTime
Belirli bir aktivitenin tamamlandığı tam tarih ve saat.
Açıklama

Event End Time, bir aktivitenin tamamlanmasını işaret eder. Bazı olaylar anlık olsa da (StartTime, EndTime'a eşittir), birçok aktivitenin bir süresi vardır. Bu zaman damgası (zaman damgası), mevcut olduğunda, her adımın ne kadar sürdüğünün hassas bir şekilde ölçülmesini sunar.

Bu nitelik, aktiviteler arasındaki 'bekleme süresine' kıyasla bir aktivitenin 'aktif süresini' veya 'işlem süresini (processing time) hesaplamak için kullanılır. Bu, bir hasar üzerinde aktif olarak çalışılan süre ile bir kuyrukta boşta beklediği süreyi ayırt etmeye yardımcı olur. Zaman alıcı belirli aktiviteleri saptamak için bu büyük önem taşır.

Neden Önemli?dir?

Bireysel etkinlikler için aktif işlem süresinin hesaplanmasını sunar, katma değerli süre ile bekleme süresini ayırt etmeye yardımcı olur.

Nereden Alınır??

Başlangıç zamanıyla aynı işlem günlüklerinde bulunabilir veya sonraki olayın başlangıç zamanından çıkarılması gerekebilir. Sapiens ClaimsPro belgelerine başvurun.

Örnekler:::::::
2023-10-26T11:30:00Z2023-10-26T15:00:15Z2023-10-27T13:45:00Z
Başvuru Kanalı
SubmissionChannel
Hasar talebinin ilk olarak gönderildiği yöntem (ör. çevrimiçi portal, acente, posta).
Açıklama

Bu nitelik, yeni bir talep için başvuru kanalını tanımlar. Farklı kanallar, ilk veri kalitesi üzerinde önemli bir etkiye sahip olabilir ve bu da süreç akışının tamamını etkiler.

Süreci Başvuru Kanalına göre analiz etmek, verimlilik ve kaliteyle ilgili soruları yanıtlamaya yardımcı olur. Örneğin, 'Claims Submission Channel Efficiency' kontrol paneli'u, çevrimiçi portal aracılığıyla gönderilen taleplerin, posta yoluyla gönderilenlere kıyasla daha hızlı döngü sürelerine ve daha düşük yeniden işleme oranlarına sahip olup olmadığını ortaya koyabilir. Bu önemli bilgi, kanal optimizasyonu ve dijital dönüşüm yatırımlarına yön verebilir.

Neden Önemli?dir?

En verimli işleme yol açan başvuru kanallarını belirlemeye yardımcı olur; otomasyon ve gelişmiş müşteri deneyimi için fırsatları ortaya çıkarır.

Nereden Alınır??

Genellikle ilk temas noktasında yakalanır ve Sapiens ClaimsPro'daki ana talep kaydında bir alan olarak saklanır.

Örnekler:::::::
Online PortalYetkiliPostaTelefon
Çözüm Hedef Tarihi
ResolutionTargetDate
Servis seviyesi anlaşmalarına (SLA) göre hasar talebinin kapanması beklenen hedef tarih.
Açıklama

Çözüm Hedef Tarihi, hasar kapanışı için belirlenen ve genellikle hasar türü, yargı yetkisi veya poliçe şartları gibi faktörlere göre belirlenen bir son tarihtir. Performansı ve servis seviyesi anlaşmalarına (SLA) uyumu ölçmek için bir kıyaslama noktası görevi görür.

Bu tarih, 'Hasar Çözüm SLA Compliance' kontrol paneli'u ve 'On-Time Claim Resolution Rate' KPI'ı için büyük önem taşır. Gerçek 'Claim Closed' tarihi bu hedefle karşılaştırılarak, sistem hasarları otomatik olarak 'On-Time' (Zamanında) veya 'Late' (Gecikmeli) olarak sınıflandırabilir ve SLA performansının net bir görünümünü sunar.

Neden Önemli?dir?

SLA uyumluluğunu ölçmek için bir ölçüttür; zamanında çözüm oranlarının hesaplanmasını ve gecikme riski taşıyan taleplerin belirlenmesini sunar.

Nereden Alınır??

Bu tarih, ana talep kaydında veya Sapiens ClaimsPro içindeki ilgili bir SLA yönetim modülünde saklanabilir.

Örnekler:::::::
2024-01-152024-03-202024-06-01
Hasar Durumu
ClaimStatus
Hasar dosyasının mevcut durumu (ör. Açık, Beklemede, Kapalı).
Açıklama

Bu nitelik, talep dosyasının herhangi bir andaki genel durumunu temsil eder. Aktiviteler olayları temsil ederken, durum bu olaylar sonucunda ortaya çıkan talebin güncel halidir. Talebin süreç döngüsünde nerede olduğuna dair üst düzey bir özet sunar.

Talep durumunu analiz etmek, açık taleplerin envanterini ve mevcut aşamalarını anlamaya yardımcı olur. Operasyonel kontrol paneli'lar için faydalıdır ve durumun süreç boyunca ne sıklıkta ve ne kadar anlamlı bir şekilde güncellendiğini takip ederek 'Claim Status Transparency Score' KPI'ını hesaplamak için kullanılır.

Neden Önemli?dir?

Bir talebin mevcut durumuna üst düzey bir bakış sunar; devam eden iş yükünü takip etmek ve durumun ilerleyişini anlamak için faydalıdır.

Nereden Alınır??

Sapiens ClaimsPro'daki ana hasar kaydında, çeşitli iş işlemleriyle güncellenen birincil bir alan.

Örnekler:::::::
AçıkBeklemede - Bilgi BekleniyorKapatıldı - ÖdendiKapatıldı - Reddedildi
Hasar Tarihi
LossDate
Talebi tetikleyen olayın veya vakanın gerçekleştiği tarih.
Açıklama

Hasar Tarihi (Kayıp Tarihi olarak da bilinir), talebin yapıldığı asıl olayın (ör. araç kazası, mülk hasarı) meydana geldiği tarihtir. Genellikle müşterinin bakış açısından tüm hasar sürecinin başlangıç noktasıdır.

Bu nitelik, Hasar Tarihi ile 'Talep Gönderildi' tarihi arasındaki süre olan bildirim gecikmesini hesaplamak için önemlidir. Bu gecikmeyi analiz etmek, müşteri davranışları hakkında stratejik bilgiler sağlayabilir ve daha hızlı bildirimleri teşvik etme fırsatları belirleyebilir; bu da genellikle daha iyi sonuçlar doğurur.

Neden Önemli?dir?

Hasar olayının başlangıcını tanımlar; bildirim gecikmesinin (hasar anından talep gönderimine kadar) analizini sunar.

Nereden Alınır??

İlk Zarar Bildirimi (FNOL) sırasında yakalanan, ana hasar kaydındaki temel bir alan.

Örnekler:::::::
2023-10-202023-11-152024-01-05
Kaynak Sistem
SourceSystem
Verilerin çıkarıldığı sistemi, bu durumda Sapiens ClaimsPro'yu tanımlar.
Açıklama

Bu nitelik, süreç verilerinin kaynağı hakkında bağlam sunar. Bu belirli veri seti için 'Sapiens ClaimsPro' gibi sabit bir değer olsa da, verilerin birden çok sistemden birleştirildiği ortamlarda büyük önem taşır.

Analiz açısından, veri yönetişimi, sorun giderme ve elde edilen stratejik bilgilerin kaynak sisteme doğru şekilde atfedilmesini güçlüada yardımcı olur. Veri soy ağacını (veri izlenebilirliği) korumak ve sürecin teknolojik bağlamını anlamak için kilit bir alandır.

Neden Önemli?dir?

Veri soy ağacı ve izlenebilirlik sunar; birden fazla sistemden gelen verilerin birleştirilmesi ve denetim amaçları için büyük önem taşır.

Nereden Alınır??

Bu, genellikle veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında kayıtların kaynağını etiketlemek için eklenen statik bir değerdir.

Örnekler:::::::
Sapiens ClaimsProClaimsPro v10.1
Poliçe Numarası
PolicyNumber
Hasar talebinin yapıldığı sigorta poliçesinin benzersiz tanımlayıcısı.
Açıklama

Poliçe Numarası, hasar talebini talep sahibi tarafından tutulan spesifik sigorta sözleşmesine bağlar. Bu, hasar yönetimi ve kararları üzerinde etkili olan teminat, limitler ve muafiyetler hakkında temel bağlam sunar.

Süreç akışı analizinde her zaman doğrudan kullanılmasa da, herhangi bir derinlemesine inceleme için kritik bir niteliktir. Analistlerin hasar data'larını poliçe data'larıyla birleştirmesine olanak tanıyarak müşteri ilişkisinin ve risk profilinin daha uçtan uca görmenizi sunar. Ayrıca, sorunlu poliçeleri veya eğilimleri belirlemek için hasarları poliçeye göre gruplandırmak amacıyla da kullanılabilir.

Neden Önemli?dir?

Talebi sigorta sözleşmesine bağlar; süreç verilerini teminat ve limitler gibi poliçe detaylarıyla birleştirerek daha derinlemesine analiz yapılmasını sunar.

Nereden Alınır??

Sapiens ClaimsPro'daki ana hasar kaydında, bunu poliçe yönetim sistemine bağlayan standart bir alan.

Örnekler:::::::
POL-987654321POL-1, 2, 3, 456789POL-555444333
Reddedilme Nedeni
ReasonForRejection
Bir hasar talebi reddedildiğinde veya bir ödeme geri çevrildiğinde belirtilen spesifik neden.
Açıklama

Bir hasar kararı 'Reddedildi' olduğunda, bu özellik temel gerekçeyi sunar. Bu, standart bir kod olabileceği gibi, hasarın neden karşılanmadığını açıklayan serbest bir metin de olabilir; örneğin 'Poliçe Dışı Kalma', 'Kanıt Yetersizliği' veya 'Dolandırıcılık Şüphesi'.

Bu bilgi, 'Hasar Kararı ve Ödeme Analizleri' kontrol paneli'u için büyük önem taşır. Reddedilme nedenlerini analiz etmek, eksik bilgi nedeniyle yüksek sayıda ret gibi kalıpları ortaya çıkarabilir; bu da veri toplama aşamasındaki sorunlara işaret edebilir. Hasar retleri için kök neden analizine yardımcı olur.

Neden Önemli?dir?

Reddedilen talepler için kritik bir bağlam sunar, red oranlarını azaltmak ve başvuru kalitesini artırmak için kök neden analizini sunar.

Nereden Alınır??

'Talep Reddedildi' veya 'Hasar Kararı Verildi' aktiviteleriyle ilişkilidir, muhtemelen Sapiens ClaimsPro'daki bir durum veya neden kodu alanında saklanır.

Örnekler:::::::
Poliçe istisnasıKapsam dışı bir riskİstenen bilgi sağlanmadıYinelenen hasar talebi
SLA Durumu
SlaState
Kapanan bir hasarın çözüm hedef tarihini karşılayıp karşılamadığını gösteren hesaplanmış bir bayrak.
Açıklama

Bu nitelik, 'Claim Closed' aktivitesinin zaman damgası (zaman damgası)nın 'ResolutionTargetDate' ile karşılaştırılmasıyla elde edilir. Talepleri 'Zamanında' veya 'Gecikmeli' gibi durumlarına göre sınıflandırarak, SLA performansının açık ve anında bir göstergesini sunar.

Bu hesaplanmış alan, 'Claim Resolution SLA Compliance' kontrol paneli'unun temelini oluşturur. Kullanıcıların tüm gecikmiş talepleri anında filtrelemesine ve gecikmeye yol açan yaygın süreç yollarını veya darboğazları araştırmalarına olanak tanıyarak analizi basitleştirir. 'On-Time Claim Resolution Rate' KPI'ını doğrudan destekler.

Neden Önemli?dir?

SLA uyumluluğunu doğrudan ölçer, bu da geç çözümlenen hasarları filtrelemeyi ve analiz etmeyi kolaylaştırır.

Nereden Alınır??

Bu nitelik, kaynak sistemde bulunmaz. 'Claim Closed' aktivitesinin 'Eventzaman damgası (zaman damgası)' değeri ile 'ResolutionTargetDate' karşılaştırılarak veri dönüşümü sırasında hesaplanır.

Örnekler:::::::
ZamanındaGecikmiş
Son Veri Güncellemesi
LastDataUpdate
Verinin kaynak sistemden en son ne zaman yenilendiğini veya çıkarıldığını gösteren zaman damgası (zaman damgası)dır.
Açıklama

Bu nitelik, Sapiens ClaimsPro'dan yapılan en son veri çekiminin tarih ve saatini kaydeder. Analiz edilen verinin güncelliğini anlamak için gereklidir ve genellikle tek bir veri setindeki tüm kayıtlarda standarttır.

Herhangi bir analiz veya kontrol paneli'da, bu zaman damgası (zaman damgası) verinin güncel durumu hakkında kritik bir bağlam sunar. Kullanıcıların gerçek zamanlı bilgi mi yoksa geçmiş bir anlık görüntü mü görüntülediklerini anlamalarına yardımcı olur; bu da zamanında operasyonel kararlar almak için önemlidir.

Neden Önemli?dir?

Veri güncelliği hakkında bağlam sağlayarak, kullanıcıların analizin ne kadar yeni olduğunu bilmesini sunar.

Nereden Alınır??

Bu değer, veri çıkarma (ETL) süreci sırasında oluşturulur ve veri setine damgalanır.

Örnekler:::::::
2024-05-21T02:00:00Z2024-05-20T02:00:00Z
Yeniden İşleme mi?
IsRework
Yeniden işleme döngüsünün bir parçası olan etkinlikleri belirleyen hesaplanmış bir boolean bayrak.
Açıklama

Bu nitelik, bir aktivite veya aktivite dizisi aynı talep için tekrarlandığında 'true' değerini alır. Örneğin, bir talep 'İlk İnceleme'den 'Ek Bilgi İstendi'ye ve ardından tekrar 'İlk İnceleme'ye geçerse, ikinci inceleme durumu yeniden işleme (rework) olarak işaretlenir.

Yeniden işleme durumunu işaretlemek, süreç verimsizliğini nicelendirmek için büyük önem taşır. 'Claims Rework & Re-submission Trends' kontrol paneli'unun altyapısını sunar ve 'Claim Rework Loop Frequency' KPI'ını besler. Yeniden işleme döngülerini izole ederek ve analiz ederek, kuruluşlar kötü başlangıç veri kalitesi veya belirsiz yönergeler gibi ana nedenleri belirleyebilir ve boşa harcanan çabayı azaltmak için harekete geçebilirler.

Neden Önemli?dir?

Tekrarlanan aktiviteleri açıkça işaretleyerek süreç verimsizliğini ölçmeye yardımcı olur ve hedefe yönelik iyileştirme çabalarına olanak sunar.

Nereden Alınır??

Bu, kaynak sistemde bulunmaz. Process Mining aracı tarafından, tek bir vaka içindeki tekrarlanan aktivite dizileri tespit edilerek hesaplanır.

Örnekler:::::::
truefalse
Gerekli Önerilen Opsiyonel

Hasar Yönetimi Aktiviteleri

Bunlar, doğru Process Discovery ve performans ölçümü için event lognüze (event log) kaydetmeniz gereken temel süreç adımları ve dönüm noktaları.dır.
6 Önerilen 9 Opsiyonel
Aktivite Açıklama
Hasar Kapatıldı
Hasar dosyası sistemde resmi olarak kapatılmıştır. Bu, ödeme veya ret bildirimleri dahil tüm faaliyetlerin tamamlandığını gösteren, sürecin ana başarılı bitiş olayıdır.
Neden Önemli?dir?

Bu aktivite, sürecin sonunu işaretleyerek, her bir hasar için toplam uçtan uca döngü süresinin hesaplanmasını sunar.

Nereden Alınır??

Talebin ana durumunun 'Kapalı' veya eşdeğer nihai bir duruma güncellendiği zaman damgası (zaman damgası)ndan çıkarılmıştır.

Yakala

Ana talep durumu alanında 'Closed' durumuna geçişin zaman damgası (zaman damgası)'ı.

Event tipi inferred
Hasar Kararı Verildi
Hasar talebini onaylama, kısmen onaylama veya reddetme yönündeki resmi karar, yetkili bir hasar uzmanı tarafından alınmış ve kaydedilmiştir. Bu, süreçte önemli bir dönüm noktasıdır.
Neden Önemli?dir?

Bu, sonraki süreç yolunu (ödeme veya kapanış) belirleyen kritik bir karar noktasıdır. Karar verme süresini analiz etmek, temel bir performans göstergesidir.

Nereden Alınır??

Bu, talebin durumu veya karar alanı doldurulup kaydedildiğinde yakalanan (örn. 'Approved', 'Denied') ayrı bir olaydır.

Yakala

Karar alanının/durumunun (örn. 'Claim Status') 'Approved' veya 'Denied' gibi nihai bir karara ayarlandığı zaman damgası (zaman damgası).

Event tipi explicit
Hasar Talebi Kaydedildi
Sapiens ClaimsPro içinde benzersiz bir Talep Kimliğinin resmi olarak oluşturulmasını ve atanmasını temsil eder. Bu genellikle ilk başvuruyu takip eder ve talebin resmi olarak işleme için sistemde olduğunu gösterir.
Neden Önemli?dir?

Dahili işlemenin resmi başlangıcını belirler. 'Talep Gönderildi' ile bu etkinlik arası süre, alım verimliliğini ölçer.

Nereden Alınır??

Bir talep kaydının durumunun ön bir aşamadan (örn. 'beklemede') 'kayıtlı' veya 'açık' duruma değiştiği zaman damgası (zaman damgası)ndan çıkarılmıştır. Aynı zamanda açık bir günlük girişi de olabilir.

Yakala

Talep durumunun 'Registered', 'Open' veya eşdeğer bir aktif duruma geçişinin zaman damgası (zaman damgası)'ı.

Event tipi inferred
Ödeme Yapıldı
Tazminat tutarını ödemek için finansal işlem gerçekleştirildi. Bu olay, fonların talep sahibine veya lehtara gönderildiği noktayı işaretler.
Neden Önemli?dir?

Bu, müşteriyle doğrudan ilgili kritik bir dönüm noktasıdır. 'Claim Decision Made' ile bu aktivite arasındaki süre, müşteri memnuniyetini büyük ölçüde etkiler.

Nereden Alınır??

Finans modülündeki ödeme işlem kaydının zaman damgası (zaman damgası)ndan yakalanır ve Hasar ID'si ile bağlantılıdır.

Yakala

Talebe ilişkin ödeme işlem kaydından veya finansal sistem arayüzü kaydından alınan zaman damgası (zaman damgası).

Event tipi explicit
Soruşturma Tamamlandı
Gerekli tüm soruşturma faaliyetlerinin tamamlandığını ve bulguların belgelendiğini belirtir. Bu, talep hakkında nihai bir karar verilmesi için bir ön koşuldur.
Neden Önemli?dir?

Bu önemli dönüm noktası, kanıt toplama aşamasının sonunu işaretler. Soruşturma verimliliğinin ve karar verme süresi üzerindeki etkisinin analiz edilmesine sunar.

Nereden Alınır??

'Soruşturma Tamamlandı' veya 'Karar Bekleniyor' durumuna yapılan bir değişiklikten ya da son soruşturma görevinin tamamlanma zaman damgası (zaman damgası)ndan çıkarılmıştır.

Yakala

Soruşturmanın sona erdiğini veya tüm soruşturma alt görevlerinin tamamlandığını gösteren durum değişikliğinin zaman damgası (zaman damgası)'ı.

Event tipi inferred
Talep Gönderildi
Bir sigorta sahibinden veya üçüncü taraftan, başvuru kanalından bağımsız olarak, bir talebin ilk kez alınmasını işaret eder. Bu, talep süreç döngüsünün başlangıç noktasıdır ve genellikle bir entegrasyon veya manuel veri girişi yoluyla kaydedilir.
Neden Önemli?dir?

Bu aktivite, sürecin birincil başlangıç olayıdır. Gönderimden kayda kadar geçen süreyi analiz etmek, data girişindeki ve ilk hasar kurulumundaki gecikmeleri belirlemeye yardımcı olur.

Nereden Alınır??

Büyük olasılıkla ilk talep kaydının oluşturulma zaman damgası (zaman damgası)ndan veya ana talep tablosundaki belirli bir 'gönderim tarihi' alanından alınır.

Yakala

Hasar kaydının sistemde oluşturulma olayı, genellikle İlk Hasar Bildirimi (FNOL) girişiyle ilişkilendirilir.

Event tipi explicit
Ek Bilgi Alındı
Talep edilen bilginin alınmasını temsil eder, bu da talep işleme sürecinin devam etmesini sunar. Bu olay, talep üzerine başlayan tekrar işleme döngüsünü kapatır.
Neden Önemli?dir?

'Ek Bilgi Talep Edildi' ile bu aktivite arasındaki süreyi analiz etmek, harici gecikmeleri ortaya çıkarır ve müşteri beklentilerini yönetmeye yardımcı olur.

Nereden Alınır??

Talebin durumunun 'Bilgi Bekleniyor'dan 'Açık' veya 'İnceleme Altında' gibi aktif bir duruma geri dönmesinden çıkarılmıştır. Ayrıca gelen bir belge günlüğüyle de ilişkilendirilebilir.

Yakala

'Pending' durumundan 'Active' durumuna geçişin zaman damgası (zaman damgası)'ı; genellikle bir belge upload'ı ile tetiklenir.

Event tipi inferred
Ek Bilgi Talep Edildi
Hasar uzmanı eksik veya tamamlanmamış bilgi tespit etmiş ve poliçe sahibine veya üçüncü bir tarafa talep göndermiştir. Bu aktivite, süreçte yaygın bir bekleme durumunu başlatır.
Neden Önemli?dir?

Bu aktivite, bir yeniden çalışma döngüsünün başlangıcıdır. Yüksek sıklığı, ilk data toplama ile ilgili sorunlara işaret eder, bu da gecikmelere ve artan manuel çabaya yol açar.

Nereden Alınır??

Bir yazışma gönderildiğinde kaydedilen açık bir olay olabilir veya hasar durumunun 'Bilgi Bekleniyor' veya 'Beklemede' olarak değişmesinden çıkarılabilir.

Yakala

Talep durumunun 'Pending Information' durumuna geçişinin veya dışa dönük iletişim için günlük kaydının zaman damgası (zaman damgası)'ı.

Event tipi inferred
Hasar Değerlendirildi
Hasarın finansal değerinin resmi olarak belirlenip kaydedildiği olay. Bu, nihai tazminat miktarını hesaplamak için kilit bir girdidir.
Neden Önemli?dir?

Bu adım, finansal planlama ve rezerv yönetimi için kritik bir öneme sahiptir. Hasar değerlendirmesindeki gecikmeler, tüm uzlaşma ve ödeme sürecini aksatabilir.

Nereden Alınır??

Büyük olasılıkla finansal rezerv veya zarar tutarı alanları sistemde kesinleştiğinde veya onaylandığında bir zaman damgası (zaman damgası) olarak kaydedilir.

Yakala

'Hasar Miktarı' veya 'Rezerv Miktarı' alanlarının nihai girişi veya onayı ile ilişkilendirilen zaman damgası (zaman damgası)dır.

Event tipi explicit
Hasar Yeniden Açıldı
Daha önce kapanmış bir hasar, daha fazla inceleme veya işlem için yeniden etkinleştirildi. Bu, yeni bilgiler veya bir itiraz nedeniyle ortaya çıkabilecek istisnai bir olaydır.
Neden Önemli?dir?

İlk talep işlemlerindeki süreç istisnalarını ve potansiyel aksaklıkları vurgular. Yeniden açılan taleplerin yüksek oranı, karar kalitesi veya müşteri iletişimiyle ilgili sorunlara işaret edebilir.

Nereden Alınır??

'Kapalı' durumundan 'Açık' veya 'İnceleme Altında' durumuna geri dönen bir durum değişikliğinden çıkarılmıştır.

Yakala

Son/kapalı bir durumdan herhangi bir aktif/açık duruma geçişin zaman damgası (zaman damgası)'ı.

Event tipi inferred
İlk İnceleme Gerçekleştirildi
Bir eksper veya hasar görevlisi, sunulan hasar detayları ve belgeleri üzerinde ilk değerlendirmeyi tamamlamıştır. Bu adım, hasarın başlangıçtaki geçerliliğini ve sonraki adımlarını belirler.
Neden Önemli?dir?

Bu dönüm noktası, taleplerin ne kadar hızlı tasnif edildiğini anlamak için büyük önem taşır. Buradaki gecikmeler, genel döngü süresini ve müşteri memnuniyetini önemli ölçüde etkileyebilir.

Nereden Alınır??

Büyük olasılıkla 'İnceleme Altında', 'İncelendi' durumuna yapılan bir değişiklikle ilişkili zaman damgası (zaman damgası)ndan veya ilk inceleme görevinin ya da iş akışı adımının tamamlanmasından çıkarılır.

Yakala

Bir 'Initial Review' (İlk İnceleme) görevinin tamamlanma zaman damgası (zaman damgası) veya hasarın event log ya da geçmiş tablosundaki bir durum güncelleme olayı.

Event tipi inferred
Ödeme Hesaplandı
Onay kararının ardından, hak sahibine ödenecek nihai tazminat tutarı hesaplanmıştır. Bu adım, ödeme yetkilendirmesinden önce gelir.
Neden Önemli?dir?

Bir karar verildikten sonra finansal hesaplama adımının verimliliğini ölçer. Buradaki darboğazlar nihai ödemeyi geciktirebilir.

Nereden Alınır??

'Ödeme Tutarı' alanının sistemin finans modülünde doldurulduğu ve onaylandığı zaman damgası (zaman damgası)ndan çıkarılmıştır.

Yakala

Talep kaydındaki 'Settlement Amount' alanının kesinleşmesiyle ilişkili zaman damgası (zaman damgası).

Event tipi inferred
Ödeme Yetkilendirildi
Ödeme fonlarının serbest bırakılması için dahili onay verilmiştir. Bu genellikle bir yönetici veya ayrı bir finans ekip üyesinin ödemeyi incelemesini ve yetkilendirmesini içerir.
Neden Önemli?dir?

Talep kararı verildikten ve tutar hesaplandıktan sonra, dahili finansal onay iş akışındaki potansiyel gecikmeleri tespit eder.

Nereden Alınır??

Bu, sistemin iş akışını (workflow)nda bir onay eylemi tarafından tetiklenen açık bir olaydır veya 'Pending Payment' ya da 'Approved for Payment' durumuna geçişle ilişkilidir.

Yakala

Ödemenin onaylandığını gösteren açık bir event log girişi veya durum değişikliği zaman damgası (zaman damgası)dır.

Event tipi explicit
Soruşturma Başladı
Talebin resmi soruşturma aşamasının başlangıcını işaret eder. Bu, uzmanların görevlendirilmesini, denetimlerin planlanmasını veya diğer detaylı kanıt toplama faaliyetlerini içerebilir.
Neden Önemli?dir?

Bu aktivite, kritik ve genellikle zaman alıcı bir fazın başlangıcını tanımlar. Soruşturmanın süresini ölçmek, önemli darboğazları tespit etmek için büyük önem taşır.

Nereden Alınır??

Büyük olasılıkla 'Soruşturma Altında' durumuna yapılan bir değişiklikten veya ilk soruşturmayla ilgili görevin ya da atamanın oluşturulma tarihinden çıkarılır.

Yakala

Talep durumunun 'Investigation in Progress' veya benzer bir duruma güncellendiği zaman damgası (zaman damgası).

Event tipi inferred
Talep Reddedildi
Hasar talebi resmi olarak reddedildi ve dosya kapatılmaya hazırlanıyor. Bu durum, 'Hasar Kararı Verildi' aktivitesinde 'Reddedildi' kararının alınmasından sonra gerçekleşir.
Neden Önemli?dir?

Önemli bir alternatif süreç yolunu temsil eder. Bu yolu analiz etmek, reddedilen taleplerdeki örüntüleri ortaya çıkarabilir ve doğru prosedürlerin takip edildiğinden emin olunmasını sunar.

Nereden Alınır??

Bu, genellikle 'Claim Closed' olayı ile aynıdır, ancak nihai karar niteliğiyle ayrılır. 'Decision' alanının değeri 'Denied' olduğunda ayrı bir aktivite olarak modellenebilir.

Yakala

Hasar üzerindeki nihai karar 'Reddedildi' olduğunda, 'Claim Closed' olayından türetilir.

Event tipi calculated
Önerilen Opsiyonel

Veri Çıkarma Kılavuzları

Sapiens ClaimsPro'dan verilerinizi nasıl alırsınız?

Bu süreç için veri çıkarma yöntemleri şu anda doğrulanmaktadır. Lütfen daha sonra tekrar kontrol edin veya bize ulaşın yardım için.