Hasar Süreçleri Data Şablonunuz

Talep Kimliği (Claim ID), bir tazminat talebinin yaşam döngüsü boyunca tüm faaliyetleri, olayları ve veri noktalarını birbirine bağlayan temel anahtardır. İlk başvurudan nihai kapanışa kadar her temas noktasının, tek bir vakanın parçası olarak tutarlı bir şekilde takip edilebilmesini sağlar.

Process mining'de bu özellik, her talebin uçtan uca yolculuğunu yeniden yapılandırmak için kritik öneme sahiptir. Süreç akışlarının analiz edilmesine, toplam çözüm sürelerinin hesaplanmasına ve farklı taleplerin nasıl ele alındığındaki varyasyonların belirlenmesine olanak tanır.

Bu, tüm ilgili olayları tek bir süreç örneğine bağlayan ve hasar yaşam döngüsünün uçtan uca analizini mümkün kılan temel tanımlayıcıdır.

Bu, FINEOS Claims sistemindeki ana hasar vaka yönetimi tablolarında kullanılan birincil anahtardır.

Bu özellik, hasar süreci içindeki tek bir adımı veya kilometre taşını açıklar; örneğin, 'Hasar Başvurusu Yapıldı', 'İlk İnceleme Yapıldı' veya 'Ödeme Gerçekleştirildi'. Her aktivite, hasar üzerinde atılan ayrı bir eylemi temsil eder.

Bu aktivitelerin sırasını ve sıklığını analiz etmek, Process Mining'in temelini oluşturur. Gerçek süreç akışını ortaya çıkarır, işin biriktiği darboğazları belirlemeye yardımcı olur ve hasarların izlediği yaygın veya istisnai yolları vurgular.

Süreçteki adımları tanımlayarak, süreç haritasının görselleştirilmesine ve iş akışı kalıplarını ve sapmaları analiz etmeye olanak tanır.

Genellikle FINEOS Claims sistemi içindeki olay (event) kayıtlarından, görev durumu değişikliklerinden veya denetim izlerinden elde edilir.

Event Time, bir hasar süreci etkinliğinin gerçekleştiği kesin tarihi ve saati kaydeder. Bu kronolojik veri, olayları doğru sıralamak ve bir hasarın zaman çizelgesini anlamak için kritik öneme sahiptir.

Analizde, bu timestamp, farklı adımlar arasındaki süreleri, döngü sürelerini ve bekleme sürelerini hesaplamak için kullanılır. Gecikmeleri tespit etmek, SLA'lara göre performansı ölçmek ve sürecin zamansal dinamiklerini anlamak için temel bir unsurdur.

Bu zaman damgası, olayların kronolojik sırasını sunar ve bu da döngü süresi gibi tüm zaman tabanlı metrikleri hesaplamak ve darboğazları belirlemek için kritik öneme sahiptir.

Bu bilgi, FINEOS Claims sistemindeki her bir olay (event) veya durum kaydıyla ilişkilendirilmiş bir oluşturulma ya da son güncelleme zaman damgası olarak genellikle mevcuttur.

Bu özellik, süreç verilerinin kaynağını belirtir. Bu analiz için sürekli olarak 'FINEOS Claims' olacaktır; ancak çoklu sistem ortamında, veri soyunu izlemek ve veri kalitesini sağlamak için çok önemlidir.

Daha geniş bir analitik bağlamda, birden fazla sistemi kapsayabilen süreçleri ayırt etmeye ve veri yorumunun kaynağına göre doğru olmasını sağlamaya yardımcı olur.

Verinin kökeni hakkında kritik bilgiler sunar; bu da veri yönetişimi, doğrulama ve diğer sistemlerle entegrasyon için elzemdir.

Bu, genellikle veri çıkarma süreci sırasında veri setinin kaynağını etiketlemek için eklenen sabit (statik) bir değerdir.

Bu özellik, verinin en son ne zaman çekildiğini veya güncellendiğini gösteren tarih ve saati sağlar. Analiz edilen verinin güncelliğini anlamak için önemlidir.

Bu bilgi, veri yönetimi açısından ve kullanıcıların en güncel süreç verilerini görüp görmediğini bilmeleri için kritiktir. Veri gecikmesiyle ilgili beklentileri yönetmeye yardımcı olur ve neredeyse gerçek zamanlı süreçler hakkında raporlama yapmak için hayati önem taşır.

Verilerin güncelliğini gösterir, kullanıcıların analizin kapsadığı zaman dilimini ve en son ne zaman yenilendiğini anlamalarını sağlar.

Bu zaman damgası, genellikle bir veri yükleme işleminin sonunda veri çıkarma veya ETL aracı tarafından oluşturulur ve saklanır.

Bu özellik, hasar sürecinde belirli bir görevi gerçekleştiren kişiyi veya ekibi tanımlar. Süreç aktivitelerini insan kaynaklarına bağlamanın ana yoludur.

Atanmış Hasar Uzmanına göre verileri analiz etmek, iş yükü dağılımını, bireysel performansı ve kaynak verimliliğini anlamak için kritik öneme sahiptir. Aşırı yüklenmiş uzmanları ortaya çıkarabilir, performans karşılaştırmaları yaparak eğitim fırsatlarını belirleyebilir ve iş yüklerini dengelemek için daha iyi kaynak tahsisi stratejilerini destekleyebilir.

Bu özellik, süreç adımlarını bu adımları gerçekleştiren kişilerle ilişkilendirerek iş yükü analizi, kaynak verimliliği değerlendirmesi ve performans karşılaştırmaları yapılmasına olanak tanır.

FINEOS Claims dokümantasyonuna başvurun. Bu bilgi, genellikle hasar event'leriyle ilişkili görev sahipliği veya kullanıcı atama alanlarında saklanır.

Bu özellik, hasarın nasıl alındığını kaydeder; örneğin, çevrimiçi bir portal aracılığıyla, e-posta ile, fiziksel postayla veya bir acente üzerinden. Farklı başvuru kanalları, veri kalitesi ve başlangıç işlem süreleri üzerinde önemli bir etkiye sahip olabilir.

Süreci başvuru kanalına göre analiz etmek, belirli kanalların daha hızlı işleme, daha yüksek yeniden işleme oranlarına (örn. eksik bilgi nedeniyle) veya daha iyi sonuçlara yol açıp açmadığını belirlemeye yardımcı olur. Bu içgörüler, hataları azaltmak için çevrimiçi formları iyileştirmek gibi kanal optimizasyonu yatırımlarına rehberlik edebilir.

Belirli başvuru kanallarının daha verimli işlemeye mi yoksa daha yüksek yeniden işlem oranlarına mı yol açtığını belirlemeye yardımcı olur, kanal stratejisi ve yatırım hakkında bilgi sağlar.

FINEOS Claims dokümantasyonuna başvurun. Bu, genellikle hasar kabul (intake) süreci sırasında alınır ve ana hasar kaydında saklanır.

Bitiş Zamanı (End Time) özelliği, bir faaliyetin tam olarak ne zaman sona erdiğini kaydeder. Başlangıç Zamanı (EventTime) ile eşleştirildiğinde, her adımın tamamlanmasının ne kadar sürdüğünün (yani, işleme süresinin) tam olarak hesaplanmasını sağlar.

Analizde, bu özellik aktif işleme süresi ile boş bekleme süresi arasında ayrım yapmak için kritik öneme sahiptir. Hangi belirli faaliyetlerin en çok zamanı tükettiğini ve adımlar arasında nerede kuyrukların oluştuğunu gösteren ayrıntılı darboğaz analizlerinin oluşturulmasını sağlar.

Her bir aktivite için işlem süresinin kesin olarak hesaplanmasını sağlayarak, verimsiz adımları belirleme ve kaynak kullanımını ölçme konusunda kilit rol oynar.

FINEOS Claims dokümantasyonuna başvurun. Bu, event log'larında mevcut olabilir veya sonraki event'in başlangıç zamanından türetilebilir.

Bu özellik, 'İlk Kabul', 'Soruşturma Birimi' veya 'Ödemeler Departmanı' gibi belirli bir aktiviteden sorumlu olan veya hasara belirli bir aşamada sahip olan organizasyonel birimi belirtir.

Süreci departmanlara göre analiz etmek, yaygın bir gecikme kaynağı olan departmanlar arası geçişleri anlamak için çok önemlidir. Hangi departmanların darboğaz olduğunu belirlemeye, departman verimliliğini ölçmeye ve organizasyon genelinde kaynak tahsisi analizini desteklemeye yardımcı olur.

Kuruluş birimi bazında performans analizine olanak tanır, departmanlar arası devir gecikmelerini ve departman darboğazlarını vurgular.

FINEOS Claims dokümantasyonuna başvurun. Bu, atanan eksperin kullanıcı profiliyle veya bir görevin atandığı kuyrukla ilişkilendirilebilir.

Bu özellik, hizmet seviyesi anlaşmaları (SLA'lar) veya yasal gereksinimler tarafından tanımlanan, hasar sürecini tamamlama son tarihini temsil eder. Gerçek performansın ölçüldüğü bir kıyaslama noktası olarak hizmet eder.

Bu tarih, SLA uyumunu izlemek için çok önemlidir. Gerçek hasar kapanış tarihini Çözüm Hedef Tarihi ile karşılaştırarak, SLA uyum oranı hesaplanabilir, SLA'larını ihlal etme riski taşıyan hasarlar belirlenebilir ve uyumsuzluğa yol açan gecikmelerin temel nedenleri analiz edilebilir.

Bu, Hizmet Seviyesi Anlaşması (SLA) uyumluluğunu ölçmek için bir referans noktasıdır. Bu sayede geciken hasarların tespit edilmesini ve gecikme nedenlerinin analiz edilmesini mümkün kılar.

FINEOS Claims dokümantasyonuna başvurun. Bu tarih, genellikle hasar başvuru tarihi ve türüne göre business kuralları tarafından hesaplanır.

Hasar Durumu, bir hasarın yaşam döngüsündeki 'Açık', 'Bilgi Bekliyor', 'Onaylandı', 'Reddedildi' veya 'Kapalı' gibi durumunu gösterir. Bu nitelik, hasarın herhangi bir anda hangi aşamada olduğunu anlık olarak görmenizi sağlar. Süreç analizinde, durum değişiklikleri genellikle doğrudan süreç faaliyetlerine karşılık gelir. Durum takibi, hasar sonuçlarını anlamak, hasarların belirli bir durumda uzun süre takılı kaldığı darboğazları tespit etmek ve 'Reddedildi' veya 'Kapalı' gibi nihai sonuçların nedenlerini analiz etmek için hayati öneme sahiptir.

Bu özellik, hasar sonuçlarını anlamak, aktif ve kapanmış dosyaları filtrelemek ve hasarların tıkandığı aşamaları belirlemek için anahtar niteliğindedir.

FINEOS Claims dokümantasyonuna başvurun. Bu, ana hasar kaydında yaşam döngüsü boyunca güncellenen temel bir alandır.

Hasar Şiddeti; hasarın karmaşıklığına, aciliyetine veya finansal riskine göre bir derecelendirme sunar. Yüksek şiddetli hasarlar, düşük şiddetli olanlara kıyasla daha fazla adım, özel inceleme veya daha uzun işlem süreleri gerektirebilir. Süreci şiddete göre analiz etmek, kaynak tahsisinin ve süreç tasarımının farklı hasar karmaşıklığı seviyeleri için uygun olup olmadığını anlamaya yardımcı olur. Bu analiz, yüksek şiddetli hasarların orantısız bir şekilde gecikip gecikmediğini veya düşük şiddetli hasarların gereğinden fazla işleme tabi tutulup tutulmadığını ortaya çıkararak, daha iyi süreç segmentasyonu ve kaynak yönetimini mümkün kılar.

Şiddete göre segmentasyon yapmak, sürecin yüksek etkili hasarları doğru bir şekilde önceliklendirip önceliklendirmediğini kontrol etmeye yardımcı olur ve belirli karmaşıklık seviyelerinin süreç darboğazlarına yol açıp açmadığını belirler.

FINEOS Claims dokümantasyonuna başvurun. Bu, özel bir alan olabilir veya tahmini hasar miktarı gibi diğer özelliklerden türetilebilir.

Hasar Tipi, hasarları poliçenin veya kaybın niteliğine göre sınıflandırır. Farklı hasar tipleri genellikle ayrı süreç varyasyonlarını takip eder, farklı yasal gerekliliklere sahiptir ve özel işlem gerektirir. Bu, karşılaştırmalı analiz için kritik bir boyuttur. Süreç görünümünü Hasar Tipi'ne göre filtreleyerek veya segmentlere ayırarak, analistler türe özgü darboğazları ortaya çıkarabilir, kategoriler arasında performansı karşılaştırabilir ve süreç iyileştirme girişimlerini her hasar tipinin benzersiz ihtiyaçlarına göre uyarlayabilir. Bu sayede, belirli hasar tiplerinin doğası gereği daha az verimli işlenip işlenmediği sorusuna yanıt bulunabilir.

Sürecin farklı talep kategorilerine göre bölümlere ayrılmasıyla, performans karşılaştırmaları yapmak ve farklılıkları belirlemek mümkün olur, bu da daha hedefli iyileştirmelerin önünü açar.

FINEOS Claims dokümantasyonuna başvurun. Bu, bir hasarın temel bir özelliğidir, genellikle kayıt sırasında belirlenir ve ana case tablosunda saklanır.

Hasar Miktarı, bir talep için ayrılan başlangıç tahmini veya finansal rezervi temsil eder. Bu değer, talep incelendikçe ve değerlendirildikçe güncellenebilir.

Bu finansal veri, talepleri segmentlere ayırmak ve finansal etkinin süreç davranışı ile nasıl ilişkili olduğunu anlamak için çok önemlidir. Örneğin, şu sorulara yanıt bulmaya yardımcı olur: Daha yüksek değerli taleplerin işlenmesi daha mı uzun sürer yoksa daha fazla yeniden işleme mi gerektirir? Aynı zamanda finansal tahmin ve risk yönetimi için de önemli bir girdidir.

Sürece finansal bağlam sağlar, hasar değerinin işleme süresi, karmaşıklığı ve ilerleme yolları üzerindeki etkisinin analizini mümkün kılar.

FINEOS Claims dokümantasyonuna başvurun. Bu bilgi, genellikle hasarla ilişkili finansal veya karşılık (rezerv) tablolarında bulunur.

Hasar Tarihi (Loss Date), asıl olayın (örn. kaza, yaralanma) ne zaman gerçekleştiğini belirtir. Bu tarih, talebin sunulduğu tarihten farklıdır ve talep doğrulaması ile işlenmesinde önemli bir faktör olabilir.

Bu özellik, değerli bir bağlam sağlar. Hasar Tarihi ile 'Talep Gönderildi' tarihi (raporlama gecikmesi) arasındaki zaman farkı, temel bir performans göstergesi olabilir. Bu gecikmeyi analiz etmek, raporlama süreçlerindeki sorunları ve bunların genel talep yaşam döngüsü üzerindeki etkisini ortaya çıkarabilir.

Önemli bağlam sağlar ve raporlama gecikmesinin (hasardan bildirime kadar geçen süre) hesaplanmasını sağlar, bu da hasar karmaşıklığını ve sonuçlarını etkileyebilir.

FINEOS Claims dokümantasyonuna başvurun. Bu tarih, 'İlk Hasar Bildirimi' veya hasar kayıt süreci sırasında kaydedilen standart bir alandır.

İşleme Süresi, bir aktivitenin başlangıcı ile bitişi arasındaki geçen süreyi ölçen, hesaplanmış bir metriktir. Kaynakların bir görevle aktif olarak ilgilendiği 'dokunma süresini' veya bu dönemi temsil eder.

Bu, performans analizi için temel bir metriktir. Aktif çalışma süresini boş bekleme süresinden ayırmaya yardımcı olur; böylece kaynak verimliliğinin daha doğru değerlendirilmesini ve doğası gereği zaman alıcı olan aktivitelerin belirlenmesini sağlar. Operasyonel maliyetleri ve hasar uzmanı kullanım oranlarını hesaplamak için önemli bir girdidir.

Faaliyetler için aktif 'dokunma süresini' ölçer, hangi belirli görevlerin en çok zaman aldığını belirlemeye ve kaynak verimliliğini doğru bir şekilde ölçmeye yardımcı olur.

Bu, aktivitenin Başlangıç Zamanı (StartTime), bitiş zamanından (EndTime) çıkarılarak hesaplanır.

Bu özellik, sigortalının adresi veya hasarın meydana geldiği yer gibi hasarla ilişkili coğrafi konumu belirtir.

Coğrafi analiz, hasar türleri, sıklıkları ve işlem verimliliğindeki bölgesel farklılıkları ortaya çıkarabilir. Belirli bölge ofislerinin diğerlerinden daha iyi performans gösterip göstermediğini veya hasar sürecini etkileyen konuma özgü faktörlerin (örn. düzenlemeler, hava olayları) olup olmadığını belirlemeye yardımcı olabilir. Bu, daha hedefe yönelik yönetim ve kaynak tahsisi sağlar.

Bölgesel performans farklılıklarını, uyumluluk farklılıklarını veya konuma özgü darboğazları tespit etmek için coğrafi segmentasyona olanak tanır.

FINEOS Claims dokümantasyonuna başvurun. Bu bilgi, genellikle sistemde kayıtlı poliçe sahibi veya başvuru sahibinin adres bilgilerinden elde edilir.

Ödeme Miktarı, talep çözümü ve onayının ardından dağıtılan nihai toplam tutardır. Birden fazla ödemesi olan talepler için bu, bireysel bir ödeme işlemini temsil edebilir.

Bu öznitelik, finansal mutabakat ve sürecin parasal sonuçlarını analiz etmek için çok önemlidir. Başlangıçtaki tahmini hasar ile nihai ödeme arasındaki karşılaştırmaları sağlar. Süreç analizinde, farklı süreç varyantlarının veya kararlarının finansal etkisini anlamaya yardımcı olur.

Finansal performansı ölçmek ve hasarların değerini analiz etmek açısından kritik olan sürecin finansal sonucunu takip eder.

FINEOS Claims dokümantasyonuna başvurun. Bu data, hasar case'ine bağlı ödeme transaction tablolarında bulunur.

Poliçe Numarası (Policy Number), tazminat talebini karşılayan sigorta sözleşmesinin tanımlayıcısıdır. Talebi belirli bir müşteriyle, poliçe şartlarıyla ve teminat detaylarıyla ilişkilendirir.

Doğrudan bir süreç özelliği olmasa da, temel bir iş bağlamı sağlar. Tazminat verilerinin poliçe veya müşteriye göre toplanmasına olanak tanır; bu da talep sıklığını, müşteri deneyimini analiz etmek ve yüksek hacimli karmaşık talepler üreten poliçeleri belirlemek için faydalı olabilir.

Kritik iş bağlamı sağlar, hasarı belirli bir müşteri sözleşmesine bağlayarak müşteri odaklı süreç analizini mümkün kılar.

FINEOS Claims dokümantasyonuna başvurun. Bu, hasar kaydı sırasında alınan ve ana hasar kaydında saklanan temel bir data parçasıdır.

Bir hasar talebi 'Reddedildi' sonucuna ulaştığında, bu özellik ret kararının özel nedenini belirtir. Nedenler arasında 'Poliçe Kapsamında Değil', 'Dolandırıcılık Şüphesi' veya 'Eksik Bilgi' yer alabilir.

Bu, hasar talebi retlerinin temel neden analizi için kritik bir özelliktir. Farklı ret nedenlerinin sıklığını analiz ederek kurum, başvuru sürecindeki yaygın sorunları, müşterilerin poliçe kapsamı konusundaki kafa karışıklıklarını veya eksperler için olası eğitim ihtiyaçlarını tespit edebilir. Bu içgörüler, ret oranlarını düşüren ve müşteri memnuniyetini artıran girişimlere yol açabilir.

Başarısız süreçlerin kök neden analizi için kritik öneme sahiptir; hasar retlerini azaltma ve kabul kalitesini artırma fırsatlarını belirlemeye yardımcı olur.

FINEOS Claims dokümantasyonuna başvurun. Bu, genellikle 'Hasar Reddedildi' aktivitesi gerçekleştirildiğinde seçilen yapısal bir alan veya koddur.

Bu özellik, her hasar için SLA performansına dair net, kategorik bir durum sunar. 'Hasar Kapanış' tarihi ile 'Çözüm Hedef Tarihi'nin karşılaştırılmasıyla 'Zamanında' veya 'Geç' olarak sınıflandırılır.

Bu durum, SLA uyumunun raporlanmasını ve analizini basitleştirir. Analistler, ham tarihlerle uğraşmak yerine, bu basit kategoriyi kullanarak SLA uyum oranını gösteren dashboard'lar oluşturabilir, geciken tüm hasarları filtreleyerek ortak özelliklerini analiz edebilir ve zaman içindeki SLA performansı eğilimlerini izleyebilir. SLA Uyum dashboard'ını ve KPI'ını doğrudan destekler.

Her vaka için SLA performansının net ve basit bir göstergesini sunar, SLA uyumluluk oranını ölçmeyi ve analiz etmeyi kolaylaştırır.

Bu, her bir vaka için son aktivitenin zaman damgasını 'ResolutionTargetDate' ile karşılaştırarak elde edilen hesaplanmış bir alandır.

Bu özellik, kapanmış bir hasar dosyasının tekrar aktif duruma getirilme nedenini kaydeder. Yeni bilgi alınması, sigortalının itirazı veya bir hatanın düzeltilmesi gibi durumlar sıkça karşılaşılan nedenlerdendir.

Tekrar açılma nedenlerini analiz etmek, süreç kalitesini ve kesinliğini ölçmenin doğrudan bir yoludur. Özellikle belirli nedenlerle yüksek sayıda tekrar açılan dosya, ilk kapanışın kusurlu olduğunu gösterir. Bu veriler, soruşturma veya karar alma aşamalarındaki zayıflıkları ortaya çıkararak, hasarların ilk seferde doğru kapatılmasını sağlamak için net süreç iyileştirme hedefleri sunar.

Bir hasarın vaktinden önce veya yanlış kapatıldığı süreç hatalarına doğrudan içgörü sağlar, ilk seferde çözüm oranını iyileştirme fırsatlarını vurgular.

FINEOS Claims dokümantasyonuna başvurun. Bu neden, genellikle bir kullanıcı sistemde 'Hasarı Yeniden Aç' aksiyonunu gerçekleştirdiğinde kaydedilir.

Bu hesaplanmış özellik, aynı hasar için ikinci bir 'Ek Bilgi Talep Edildi' olayı gibi yeniden işlemeyi temsil eden aktiviteleri işaretler. Genellikle süreç akışındaki tekrarlanan aktiviteler veya geri döngüler tespit edilerek belirlenir.

Yeniden işlemeyi açıkça işaretlemek, verimsizliğe odaklanan analizi basitleştirir. Bu, temel bir performans göstergesi olan yeniden işleme oranının kolayca ölçülmesini sağlar. Dashboard'lar, bu işareti kullanarak yeniden işlemelerin sıklığını ve etkisini görselleştirebilir, bu verimsiz döngülerin temel nedenlerini belirlemeye yardımcı olur.

Verimsiz süreç döngülerini doğrudan işaretleyerek, yeniden işleme oranını hesaplamayı ve tekrarlanan işlerin nedenlerini analiz etmeyi kolaylaştırır.

Bu, Process Mining analizi sırasında aynı vaka için tekrarlanan aktivitelerin belirlenmesiyle elde edilir. Örneğin, 'Soruşturma Başlatıldı' aktivitesinin ikinci kez gerçekleşmesi bu duruma örnek teşkil eder.