Veri Şablonu: Hasar Süreçleri
Talep Süreçleri Veri Şablonunuz
- Talep verisi toplama için önerilen nitelikler
- Hasar sürecinizde takip etmeniz gereken kilit aktiviteler
- Sapiens ClaimsPro için adım adım veri çıkarma rehberliği
Hasar İşleme Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
Faaliyet Adı ActivityName | Hasar sürecinde belirli bir noktada gerçekleşen spesifik iş aktivitesinin 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 temelidir. 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 Sürecin adımlarını tanımlar; süreç haritasını oluşturmak ve darboğazları ile verimsizlikleri belirlemek için esastı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 Kaydedildiİnceleme BaşladıÖdeme HesaplandıHasar Kapatıldı | |||
Hasar ID ClaimId | Her sigorta talebi için benzersiz tanımlayıcı olup, talebin yaşam döngüsünü takip etmek için birincil case ID'si olarak hizmet eder. | ||
Açıklama Claim ID (Hasar Kimliği), tek bir sigorta talebiyle ilişkili tüm olayları ve aktiviteleri birbirine bağlayan temel vaka 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 sağlar. 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. Data'ları Claim ID merceğinden analiz etmek, talebin yolculuğunun eksiksiz bir resmini sunar. Neden önemli İlgili tüm aktivitelerin tek bir process instance altında toplanmasını sağlar ve hasar yaşam döngüsünü uçtan uca analiz etmenize olanak tanır. Nereden alınır Bu, Sapiens ClaimsPro içindeki ana talep işlem tablosunda bir birincil anahtardır (primary key). Tam tablo ve alan adı için sistem belgelerine başvurun. Örnekler CL-2023-001234CL-2023-005678CL-2024-009101 | |||
Olay Zaman Damgası EventTimestamp | Belirli bir aktivitenin veya olayın başladığı kesin tarih ve saat. | ||
Açıklama Event Timestamp, 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ı sağlar. Bu timestamp, event log'unun zamansal omurgası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 kritik öneme sahiptir. 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 mümkün kılar. Neden önemli Bu timestamp, 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'da aktivite veya durum değişikliği bilgileriyle birlikte olay ya da işlem günlük 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' dashboard'u ve daha üst düzey organizasyonel süreç analizi için kritik öneme sahiptir. Neden önemli 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 Sistemde genellikle kullanıcının profiliyle ilişkilendirilir ya da doğrudan hasar nesnesine atanır. Sapiens ClaimsPro dokümantasyonuna bakın. Ö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 kritik öneme sahiptir. 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 olanak tanır. 'Adjuster & Department Activity Load' dashboard'unu oluşturmak ve 'Adjuster Workload Balance' KPI'ını hesaplamak için vazgeçilmez bir unsurdur. Neden önemli 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ı etkinlik günlüklerinde veya işlem tablolarında bulunur; genellikle kaydı oluşturan ya da son değiştiren kullanıcıyla ilişkilidir. Örnekler John Smithj.smithUSR-00451 | |||
Hasar Şiddeti 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 Şiddeti, bir hasara atanan, tahmini karmaşıklığını, riskini veya finansal maruziyetini gösteren bir derecelendirmedir. Bu derecelendirme genellikle inceleme düzeyini, eksperden beklenen deneyimi ve izlenecek iş akışını belirler. Bu nitelik, 'Hasar Şiddeti Çevrim Süresi Analizi' dashboard'u için kritiktir. 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 sağlar. Neden önemli Döngü süresi analizi için kritik bir bağlam sağlar; 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 çok önemlidir. Ö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 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 olanak tanır. 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 İçgörüleri' dashboard'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 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ığı kesin 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 timestamp, mevcut olduğunda, her adımın ne kadar sürdüğünün hassas bir şekilde ölçülmesini sağlar. Bu nitelik, aktiviteler arasındaki 'bekleme süresine' kıyasla bir aktivitenin 'aktif süresini' veya 'processing time'ını (işlem süresini) 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 kritik öneme sahiptir. Neden önemli Bireysel etkinlikler için aktif işlem süresinin hesaplanmasını sağlar, katma değerli süre ile bekleme süresini ayırt etmeye yardımcı olur. Nereden alınır Başlangıç zamanı ile aynı işlem günlüklerinde bulunabilir ya da bir sonraki olayın başlangıç zamanından çıkarılması gerekebilir. Sapiens ClaimsPro dokümantasyonuna bakın. Ö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' dashboard'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 içgörü, kanal optimizasyonu ve dijital dönüşüm yatırımlarına yön verebilir. Neden önemli Hangi başvuru kanallarının en verimli işlemeyi sağladığını gösterir; otomasyon ve daha iyi müşteri deneyimi fırsatlarını öne çı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' dashboard'u ve 'On-Time Claim Resolution Rate' KPI'ı için temeldir. 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 SLA uyumunu ölçmek için referans noktasıdır; zamanında sonuçlandırma oranlarını hesaplamayı ve gecikme riski taşıyan dosyaları belirlemeyi mümkün kılar. 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 yaşam 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 dashboard'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 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 içgörüler sağlayabilir ve daha hızlı bildirimleri teşvik etme fırsatları belirleyebilir; bu da genellikle daha iyi sonuçlar doğurur. Neden önemli Hasar olayının başlangıcını tanımlar; bildirim gecikmesinin (hasar anından talep gönderimine kadar) analizini sağlar. 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 | |||
İşlem Süresi ProcessingTime | Talep sürecindeki iki ardışık olay arasındaki hesaplanan süre. | ||
Açıklama İşleme Süresi, bir aktivitenin başlangıcı ile bir sonrakinin başlangıcı arasında geçen süreyi ölçer. Bu, bir adımın toplam döngü süresini temsil eder; hem aktif çalışma süresini hem de bir sonraki adım başlamadan önceki boş veya bekleme süresini içerir. Bu, Process Mining'deki en temel metriklerden biridir ve darboğaz analizini güçlendirmek için kullanılır. Analistler, süreç haritasındaki aktiviteler arasındaki yaylar üzerinde ortalama işleme süresini görselleştirerek, taleplerin nerede tıkandığını anında tespit edebilirler. 'Talep Aktivite Darboğaz Analizi' gibi panolar için vazgeçilmezdir. Neden önemli Bu metrik, darboğaz analizinin temelidir ve taleplerin en çok zamanı bekleyerek geçirdiği aşamaları vurgular. Nereden alınır Bu, Process Mining analizi sırasında, her bir 'ClaimId' için ardışık faaliyetlerin 'EventTimestamp'ları arasındaki fark alınarak türetilen, hesaplanan bir metriktir. Örnekler 2 gün 4 saat30 dakika15 gün | |||
Kaynak Sistem SourceSystem | Verinin çıkarıldığı sistemi belirtir; bu durumda Sapiens ClaimsPro. | ||
Açıklama Bu nitelik, süreç verilerinin kaynağı hakkında bağlam sağlar. Bu belirli veri seti için 'Sapiens ClaimsPro' gibi sabit bir değer olsa da, verilerin birden çok sistemden birleştirildiği ortamlarda kritik öneme sahiptir. Analiz açısından, veri yönetişimi, sorun giderme ve elde edilen içgörülerin kaynak sisteme doğru şekilde atfedilmesini sağlamada yardımcı olur. Veri soy ağacını (data lineage) korumak ve sürecin teknolojik bağlamını anlamak için kilit bir alandır. Neden önemli Veri soy ağacı ve izlenebilirlik sağlar; birden fazla sistemden gelen verilerin birleştirilmesi ve denetim amaçları için kritiktir. 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 sağlar. 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 bütünsel bir görünümünü sağlar. 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 Hasarı sigorta poliçesine bağlar; kapsam ve limitler gibi poliçe ayrıntılarıyla süreç verisini ilişkilendirerek daha derin analiz yapılmasını sağlar. 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-123456789POL-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 İçgörüleri' dashboard'u için paha biçilmezdir. 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 Reddedilen talepler için kritik bir bağlam sunar, red oranlarını azaltmak ve başvuru kalitesini artırmak için temel neden analizini mümkün kılar. Nereden alınır 'Hasar Reddedildi' veya 'Hasar Kararı Verildi' aktiviteleriyle ilişkilidir, muhtemelen Sapiens ClaimsPro'daki bir durum veya neden kodu alanında saklanır. Örnekler Poliçe İstisnasıTeminat dışı 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ı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' dashboard'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 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 'EventTimestamp' değeri ile 'ResolutionTargetDate' karşılaştırılarak veri dönüşümü sırasında hesaplanır. Örnekler ZamanındaGeç | |||
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 nitelik, Sapiens ClaimsPro'dan yapılan en son veri çekiminin tarih ve saatini kaydeder. Analiz edilen verinin güncelliğini anlamak için elzemdir ve genellikle tek bir veri setindeki tüm kayıtlarda standarttır. Herhangi bir analiz veya dashboard'da, bu 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 hayati önem taşır. Neden önemli Veri güncelliği hakkında bağlam sağlayarak, kullanıcıların analizin ne kadar yeni olduğunu bilmesini sağlar. 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 kritik öneme sahiptir. 'Claims Rework & Re-submission Trends' dashboard'unun altyapısını sağlar 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 Tekrar eden adımları açıkça işaretleyerek süreç verimsizliğini ölçmeye yardımcı olur ve hedefli iyileştirme çalışmaları yapılmasını sağlar. Nereden alınır Bu, kaynak sistemde bulunmaz. Process Mining aracı tarafından, tek bir case içindeki tekrarlanan aktivite dizileri tespit edilerek hesaplanır. Örnekler truefalse | |||
Hasar İşleme Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
Hasar Gönderildi | Başvuru kanalından bağımsız olarak, sigortalıdan ya da üçüncü bir taraftan hasarın ilk kez alındığını ifade eder. Hasar yaşam döngüsünün başlangıç noktasıdır; genellikle bir entegrasyonla ya da manuel veri girişiyle kaydedilir. | ||
Neden önemli 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 hasar kaydının oluşturulma zaman damgasından ya da ana hasar tablosundaki 'submission date' 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 | |||
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 Bu aktivite, sürecin sonunu işaretleyerek, her bir hasar için toplam uçtan uca döngü süresinin hesaplanmasını mümkün kılar. Nereden alınır Hasarın ana durumunun 'Closed' ya da eşdeğer bir nihai duruma güncellendiği zaman damgasından çıkarılır. Yakala Ana talep durumu alanında 'Closed' durumuna geçişin Timestamp'ı. 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 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ığı Timestamp. Event tipi explicit | |||
Hasar 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 Dahili işlemenin resmi başlangıcını belirler. 'Hasar Gönderildi' ile bu etkinlik arası süre, alım verimliliğini ölçer. Nereden alınır Bir hasar kaydının durumunun ön aşamadan (örn. 'pending') 'registered' ya da 'open'a değiştiği zaman damgasından çıkarılır. Açık bir günlük kaydı da olabilir. Yakala Talep durumunun 'Registered', 'Open' veya eşdeğer bir aktif duruma geçişinin Timestamp'ı. Event tipi inferred | |||
İnceleme 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 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 olanak tanır. Nereden alınır 'Investigation Complete' veya 'Pending Decision' durumuna geçişten ya da son inceleme görevinin tamamlanma zaman damgasından çıkarılı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 Timestamp'ı. 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 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ı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 Timestamp. Event tipi explicit | |||
Ek Bilgi Alındı | Talep edilen bilginin alınmasını temsil eder, bu da talep işleme sürecinin devam etmesini sağlar. Bu olay, talep üzerine başlayan tekrar işleme döngüsünü kapatır. | ||
Neden önemli '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 Hasar durumunun 'Pending Information'dan 'Open' veya 'Under Review' gibi aktif bir duruma dönmesinden çıkarılır. Gelen belge günlüğüne de bağlı olabilir. Yakala 'Pending' durumundan 'Active' durumuna geçişin Timestamp'ı; 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 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 Timestamp'ı. 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 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 Finansal karşılık veya zarar tutarı alanları sistemde kesinleştirildiğinde ya da onaylandığında bir zaman damgası olarak kaydedilir. Yakala 'Hasar Miktarı' veya 'Rezerv Miktarı' alanlarının nihai girişi veya onayı ile ilişkilendirilen timestamp. Event tipi explicit | |||
Hasar 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 Ö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ı sağlar. 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 | |||
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 İlk hasar yönetimindeki süreç istisnalarını ve olası aksaklıkları öne çıkarır. Yeniden açılan dosyaların yüksek oranı, karar kalitesi ya da müşteri iletişimiyle ilgili sorunlara işaret edebilir. Nereden alınır 'Closed' durumundan 'Open' ya da 'Under Review' durumuna geri dönmesiyle çıkarılır. Yakala Son/kapalı bir durumdan herhangi bir aktif/açık duruma geçişin Timestamp'ı. 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 Bu dönüm noktası, taleplerin ne kadar hızlı tasnif edildiğini anlamak için kritik öneme sahiptir. 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 'Under Review', 'Reviewed' durum değişimiyle ilişkili zaman damgasından ya da ilk inceleme görevi/workflow adımının tamamlanmasından çıkarılır. Yakala Bir 'Initial Review' (İlk İnceleme) görevinin tamamlanma zaman damgası veya hasarın olay günlüğü ya da geçmiş tablosundaki bir durum güncelleme olayı. Event tipi inferred | |||
İnceleme Başladı | Hasar için resmi inceleme aşamasının başladığını belirtir. Uzman atama, keşif planlama veya ayrıntılı delil toplama gibi faaliyetleri içerebilir. | ||
Neden önemli 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 kritik öneme sahiptir. Nereden alınır Muhtemelen durumun 'Under Investigation' durumuna değişmesinden ya da ilk incelemeyle ilgili görev/atamanın oluşturulma tarihinden çıkarılır. Yakala Talep durumunun 'Investigation in Progress' veya benzer bir duruma güncellendiği Timestamp. 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 Karar sonrası finansal hesaplama adımının verimliliğini ölçer. Buradaki darboğazlar nihai ödemeyi geciktirebilir. Nereden alınır 'Settlement Amount' alanının sistemin finansal modülünde doldurulup onaylandığı zaman damgasından çıkarılır. Yakala Talep kaydındaki 'Settlement Amount' alanının kesinleşmesiyle ilişkili Timestamp. Event tipi inferred | |||
Ödeme Yetkilendirildi | Tazminat ödemesinin serbest bırakılması için iç onay verilmiştir. Bu genellikle bir yöneticinin veya ayrı bir finans ekip üyesinin ödemeyi inceleyip onaylamasını içerir. | ||
Neden önemli Hasar kararı verilip tutar hesaplandıktan sonra, iç finans onay workflow'undaki olası gecikmeleri tespit eder. Nereden alınır Bu, sistemin workflow'unda 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 olay günlüğü girişi veya durum değişikliği zaman damgası. Event tipi explicit | |||
Çıkarma Rehberleri
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.
