Veri Şablonu: Hasar İşleme

Bu nitelik, hasar sürecindeki tek bir adımı veya kilometre taşını tanımlar; örneğin 'Hasar Bildirimi Alındı', 'Ön İnceleme Yapıldı' ya da 'Ödeme Gerçekleştirildi'. Her aktivite, dosya üzerinde yapılan belirli bir işlemi temsil eder.

Bu aktivitelerin sırası ve sıklığını analiz etmek, Process Mining'in temelidir. Gerçek süreç akışını görünür kılar, işin biriktiği darboğazları tespit etmeye yardımcı olur ve dosyaların izlediği yaygın ya da istisnai yolları ortaya çıkarır.

Süreç adımlarını tanımlar; süreç haritasını görselleştirmenizi ve workflow kalıpları ile sapmaları analiz etmenizi sağlar.

Genellikle FINEOS Claims sistemi içindeki olay günlüklerinden (event log), görev durum değişikliklerinden veya denetim izlerinden (audit trail) türetilir.

Event Time, bir hasar işleme adımının gerçekleştiği kesin tarih ve saati kaydeder. Bu kronolojik bilgi, olayları doğru sıralamak ve dosyanın zaman çizelgesini görmek için kritiktir.

Analizlerde bu zaman damgası; adımlar arası, çevrim ve bekleme sürelerini hesaplamak için kullanılır. Gecikmeleri tespit etmek, performansı SLA'lere göre ölçmek ve sürecin zaman boyutunu anlamak için temel veridir.

Bu zaman damgası, olayların kronolojik sıralamasını sağlar; çevrim süresi gibi zamana dayalı tüm metriklerin hesaplanması ve darboğazların tespiti için esastır.

Bu bilgi, FINEOS Claims'deki her olay veya durum (status) kaydıyla ilişkilendirilmiş oluşturma ya da güncelleme zaman damgası olarak genellikle bulunur.

Hasar Numarası (Claim ID), bir hasar dosyasının yaşam döngüsü boyunca tüm aktiviteleri, event’leri ve veri noktalarını birbirine bağlayan temel anahtardır. İlk başvurudan nihai kapanışa kadar her temasın tek bir dosyanın parçası olarak tutarlı biçimde izlenmesini sağlar.

Process Mining’de bu öznitelik, her hasarın uçtan uca yolculuğunu yeniden kurmak için vazgeçilmezdir. Süreç akışlarını analiz etmenize, toplam sonuçlandırma sürelerini hesaplamanıza ve farklı dosyaların nasıl ele alındığındaki varyasyonları tespit etmenize olanak tanır.

Bu, ilgili tüm olayları tek bir süreç örneğinde (process instance) birleştiren temel tanımlayıcıdır; böylece hasarın uçtan uca yaşam döngüsünün analizi mümkün olur.

Bu, FINEOS Claims'teki ana hasar dosyası yönetim tablolarının primary key'idir.

Bu nitelik, süreç verisinin kaynağını belirtir. Bu analizde sürekli olarak 'FINEOS Claims' olacaktır; ancak çok sistemli ortamlarda veri soyağacını izlemek ve veri kalitesini güvence altına almak için kritiktir.

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

Datanın kaynağı hakkında kritik bir bağlam sunar; bu, data yönetişimi, doğrulama ve diğer sistemlerle entegrasyon için esastır.

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

Bu nitelik, verinin en son ne zaman çekildiğini veya güncellendiğini gösteren tarih ve saati sağlar. Analizi yapılan verinin güncelliğini anlamak için önemlidir.

Bu bilgi, veri yönetişimi açısından kritiktir ve kullanıcıların en güncel süreç verisine bakıp bakmadığını bilmesini sağlar. Veri gecikmesiyle ilgili beklentilerin yönetilmesine yardımcı olur ve gerçeğe yakın zamanlı süreçlerin raporlanması için hayati önemdedir.

Verinin güncelliğini gösterir; kullanıcıların analizin kapsadığı dönemi ve en son ne zaman yenilendiğini anlamasını sağlar.

Bu zaman damgası genellikle veri çıkarma veya ETL işi sonunda ilgili araç tarafından üretilir ve saklanır.

Bu nitelik, hasar sürecindeki belirli bir görevi kimin ya da hangi ekibin yaptığını belirtir. Süreç aktivitelerini insan kaynaklarıyla ilişkilendirmenin en temel yöntemidir.

Atanan hasar uzmanına göre analiz yapmak, iş yükü dağılımını, bireysel performansı ve kaynak verimliliğini anlamak için kritiktir. Aşırı yük altındaki uzmanları görünür kılar, performans karşılaştırmalarıyla eğitim ihtiyaçlarını belirler ve iş yüklerini dengelemek için daha iyi kaynak tahsisi stratejilerini destekler.

Bu nitelik, süreç adımlarını bunları gerçekleştiren kişi ya da ekiplerle ilişkilendirir; iş yükü analizi yapmayı, kaynak verimliliğini değerlendirmeyi ve performans karşılaştırmaları yapmayı sağlar.

FINEOS Claims dokümantasyonuna bakın. Bu bilgi genellikle claim event'lerine bağlı görev sahipliği veya kullanıcı ataması alanlarında tutulur.

Bu nitelik, dosyanın hangi kanaldan alındığını kaydeder; örneğin online portal, e‑posta, posta ya da acente. Farklı başvuru kanalları, veri kalitesi ve ilk işlem süreleri üzerinde kayda değer etki yaratabilir.

Süreci başvuru kanalına göre analiz etmek, bazı kanalların daha hızlı işlemeye, eksik bilgi nedeniyle daha yüksek yeniden işleme oranına veya daha iyi sonuçlara yol açıp açmadığını gösterir. Bu içgörüler, örneğin online formları iyileştirerek hataları azaltmak gibi kanal optimizasyonu yatırımlarını yönlendirir.

Belirli başvuru kanallarının daha verimli işlemeye mi yoksa daha yüksek yeniden işleme oranlarına mı yol açtığını anlamanıza yardımcı olur ve hangi kanallara yatırım yapmanız gerektiği konusunda yol gösterir.

FINEOS Claims dokümantasyonuna bakın. Bu bilgi genellikle hasar kabul sürecinde alınır ve ana hasar kaydında saklanır.

End Time alanı, bir aktivitenin tamamlandığı anı hassas biçimde kaydeder. Start Time (EventTime) ile birlikte kullanıldığında, her adımın tamamlanmasının ne kadar sürdüğünü (işleme süresi) tam olarak hesaplamayı sağlar.

Analizde, aktif işleme süresi ile bekleme süresini ayırt etmek için kritiktir. En çok zamanı tüketen aktiviteleri ve adımlar arasında hangi noktalarda kuyruk oluştuğunu gösteren ayrıntılı darboğaz analizlerinin yapılmasına imkan tanır.

Her aktivite için işlem süresinin hassas biçimde hesaplanmasını sağlar; bu, verimsiz adımları belirlemek ve kaynak kullanımını ölçmek için anahtardır.

FINEOS Claims dokümantasyonuna bakın. Bu bilgi event log'larında bulunabilir ya da sonraki event'in başlangıç zamanından türetilebilir.

Bu nitelik, belirli bir aktiviteden sorumlu olan ya da belirli bir aşamada dosyanın sahibi sayılan organizasyondaki birimi belirtir; örneğin 'İlk Kabul', 'İnceleme Birimi' ya da 'Ödemeler Departmanı'.

Süreci departmana göre analiz etmek, genellikle gecikme kaynağı olan birimler arası devir teslimleri anlamak için kritiktir. Hangi departmanların darboğaz oluşturduğunu belirlemeye, departman verimliliğini ölçmeye ve kurum genelinde kaynak tahsisini analiz etmeye destek olur.

Organizasyon birimi bazında performans analizi yapılmasını sağlar; birimler arası devir teslim gecikmelerini ve departman içi darboğazları öne çıkarır.

FINEOS Claims dokümantasyonuna bakın. Bu bilgi, atanan eksperin kullanıcı profiliyle ya da görevin atandığı kuyrukla ilişkilendirilebilir.

Bu nitelik, hizmet seviyesi anlaşmaları (SLA) veya düzenleyici gereklilikler tarafından tanımlanan, dosyanın tamamlanması için son tarihi temsil eder. Gerçek performansın ölçüldüğü referans noktasıdır.

Bu tarih, SLA uyumunun izlenmesi için esastır. Gerçek kapatma tarihi ile Çözüm Hedef Tarihi karşılaştırılarak SLA uyum oranı hesaplanabilir, SLA ihlali riski taşıyan dosyalar belirlenebilir ve uyumsuzluğa yol açan gecikmelerin kök nedenleri analiz edilebilir.

Bu, SLA uyumunu ölçmek için referans noktasıdır. Geç kalan hasar dosyalarının belirlenmesini ve gecikme nedenlerinin analizini sağlar.

FINEOS Claims dokümantasyonuna bakın. Bu tarih, çoğunlukla iş kurallarına göre hasar başvurusunun tarihi ve türüne dayanarak hesaplanır.

Tazminat durumu, dosyanın yaşam döngüsündeki konumunu belirtir; örneğin 'Open', 'Pending Information', 'Approved', 'Denied' veya 'Closed'. Bu alan, tazminatın belirli bir anda hangi aşamada olduğuna dair anlık bir görünüm sağlar.

Süreç analizinde durum değişiklikleri çoğu zaman doğrudan süreç aktivitelerine karşılık gelir. Durumun izlenmesi; sonuçları anlamak, belirli bir durumda uzun süre takılan dosyalardaki darboğazları tespit etmek ve 'Denied' ya da 'Closed' gibi nihai sonuçların nedenlerini analiz etmek için kritik önemdedir.

Bu nitelik, dosya sonuçlarını anlamak, aktif ve kapalı dosyaları filtrelemek ve dosyaların takılıp kaldığı aşamaları belirlemek için anahtardır.

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

Tazminat Önem Derecesi, dosyanın karmaşıklığına, aciliyetine veya finansal riskine ilişkin bir derecelendirme sunar. Yüksek önem dereceli tazminatlar, düşük önem derecelilere kıyasla daha fazla adım, uzman incelemesi ya da daha uzun işlem süreleri gerektirebilir.

Süreçleri önem derecesine göre analiz etmek, kaynak tahsisi ve süreç tasarımının farklı karmaşıklık seviyelerine uygun olup olmadığını anlamaya yardımcı olur. Yüksek önem dereceli dosyaların orantısız biçimde gecikip gecikmediğini ya da düşük önem derecelilerin gereğinden fazla işlendiğini ortaya çıkararak daha iyi süreç segmentasyonu ve kaynak yönetimi sağlar.

Ciddiyet derecesine göre segmentasyon, yüksek etkili taleplerin süreçte doğru önceliklendirildiğini kontrol etmeye ve belirli karmaşıklık seviyelerinin darboğazlara yol açıp açmadığını tespit etmeye yardımcı olur.

FINEOS Claims dokümantasyonuna bakın. Bu, özel bir alan olabilir ya da tahmini hasar tutarı gibi diğer niteliklerden türetilebilir.

Tazminat Türü, poliçenin niteliğine veya zarara göre dosyaları sınıflandırır. Farklı tazminat türleri çoğu zaman farklı süreç varyasyonları izler, farklı mevzuat gerekliliklerine tabidir ve özel işleyiş gerektirir.

Bu, karşılaştırmalı analiz için kritik bir boyuttur. Süreç görünümünü Tazminat Türü’ne göre filtreleyip segmente ederek analistler, türe özgü darboğazları ortaya çıkarabilir, kategoriler arası performansı kıyaslayabilir ve her türün ihtiyaçlarına uygun süreç iyileştirmeleri tasarlayabilir. Ayrıca bazı tazminat türlerinin doğası gereği daha düşük verimle işlenip işlenmediğini anlamaya yardımcı olur.

Süreci segmentlere ayırmanızı sağlar; farklı hasar kategorileri arasında performansı karşılaştırıp farklılıkları belirlemenize yardımcı olur ve daha hedefli iyileştirmeler yapmanın önünü açar.

FINEOS Claims dokümantasyonuna bakın. Bu, hasar dosyasının temel bir özelliğidir; genelde kayıt sırasında belirlenir ve ana dosya tablosunda saklanır.

Processing Time, bir aktivitenin başlangıcı ile bitişi arasındaki geçen zamanı ölçen hesaplanmış bir metriktir. Bir kaynağın göreve aktif olarak dahil olduğu 'touch time'ı, yani fiili çalışma süresini ifade eder.

Bu gösterge performans analizinin temelidir. Aktif çalışma süresi ile bekleme süresini ayırt etmeye yardımcı olur; böylece kaynak verimliliğini daha doğru değerlendirebilir ve doğası gereği zaman alan aktiviteleri belirleyebilirsiniz. Operasyonel maliyetlerin ve eksper kullanım oranlarının hesaplanmasında kilit bir girdidir.

Aktif 'dokunma süresi'ni (touch time) ölçer; en çok zaman alan görevleri nokta atışı belirlemeye ve kaynak verimliliğini doğru biçimde ölçmeye yardımcı olur.

Bu değer, etkinliğin EndTime ile StartTime arasındaki farkı olarak hesaplanır.

Loss Date, olayın (ör. kaza, yaralanma) fiilen gerçekleştiği zamanı belirtir. Bu tarih, hasarın sisteme iletildiği tarihten farklıdır ve dosyanın doğrulanmasında ve işlenmesinde önemli bir faktör olabilir.

Bu öznitelik değerli bir bağlam sunar. Loss Date ile 'Claim Submitted' tarihi arasındaki süre (raporlama gecikmesi), önemli bir performans göstergesi olabilir. Bu gecikmenin analizi, bildirim süreçlerindeki sorunları ve bunların hasarın genel yaşam döngüsüne etkisini ortaya çıkarabilir.

Önemli bir bağlam sunar ve ihbar gecikmesinin (kayıp anından başvuruya kadar geçen sürenin) hesaplanmasını sağlar; bu gecikme talebin karmaşıklığını ve sonuçlarını etkileyebilir.

FINEOS Claims dokümantasyonuna bakın. Bu tarih, 'First Notice of Loss' ya da hasar kaydı sürecinde alınan standart bir alandır.

Kayıp Tutarı, bir hasar dosyası için ayrılan ilk tahmini tutarı veya finansal karşılığı ifade eder. Dosya incelenip değerlendirildikçe bu değer güncellenebilir.

Bu finansal data, hasarları segmentlere ayırmak ve finansal etkinin süreç davranışıyla nasıl ilişkili olduğunu anlamak açısından kritiktir. Örneğin şu sorulara yanıt verir: Daha yüksek tutarlı hasarlar daha uzun mu sürüyor, daha fazla yeniden işleme gerektiriyor mu? Ayrıca finansal tahmin ve risk yönetimi için de temel bir girdidir.

Sürece finansal bağlam katar; talep tutarının işlem süresi, karmaşıklık ve izlenen yol üzerindeki etkisini analiz etmeyi sağlar.

FINEOS Claims dokümantasyonuna bakın. Bu bilgi genellikle hasara bağlı finansal ya da rezervle ilgili tablolarda bulunur.

Bu nitelik, dosyayla ilişkilendirilen coğrafi konumu belirtir; bu, hak sahibinin adresine ya da hasarın gerçekleştiği yere dayanabilir.

Coğrafi analiz, hasar türleri, sıklıkları ve işlem verimliliğinde bölgesel farklılıkları ortaya çıkarabilir. Bazı bölge ofislerinin diğerlerine göre daha iyi performans gösterip göstermediğini ya da mevzuat, hava koşulları gibi konuma özgü etkenlerin süreç üzerinde etkisi olup olmadığını anlamaya yardımcı olur. Böylece daha hedefli yönetim ve kaynak tahsisi mümkün olur.

Bölgesel performans farklarını, uyum farklılıklarını veya lokasyona özgü darboğazları saptamak için coğrafi segmentasyona olanak tanır.

FINEOS Claims dokümantasyonuna bakın. Bu bilgi genellikle sistemde tutulan sigortalı ya da talep sahibinin adres bilgilerinden türetilir.

Ödeme Tutarı, hasar dosyası onaylanıp sonuçlandığında yapılan nihai ödemeyi ifade eder. Birden fazla ödeme içeren dosyalarda bu, tekil bir ödeme işlemini temsil edebilir.

Bu özellik, finansal mutabakat ve sürecin parasal sonuçlarını analiz etmek için kritiktir. İlk tahmini kayıp ile nihai ödeme arasında karşılaştırma yapmayı sağlar. Süreç analizinde farklı süreç varyantları veya kararların finansal etkisini anlamaya yardımcı olur.

Sürecin finansal sonucunu takip eder; bu da finansal performansın ölçülmesi ve hasar bedelinin analiz edilmesi için kritiktir.

FINEOS Claims dokümantasyonuna bakın. Bu veri, ilgili hasar dosyasına bağlı ödeme işlem tablolarında yer alır.

Poliçe Numarası, hasarı kapsayan sigorta sözleşmesinin kimliğidir. Hasarı belirli bir müşteriye, poliçe koşullarına ve teminat detaylarına bağlar.

Doğrudan bir süreç özniteliği olmasa da kritik iş bağlamı sağlar. Hasar verilerinin poliçe veya müşteri bazında birleştirilmesine imkan tanır; bu da hasar sıklığının, müşteri deneyiminin analizinde ve karmaşık hasar üreten poliçelerin tespitinde yararlıdır.

Talebi belirli bir müşteri sözleşmesine bağlayarak kritik iş bağlamı sağlar ve müşteri odaklı süreç analizi yapılmasına imkân tanır.

FINEOS Claims dokümantasyonuna bakın. Bu, hasar kaydı sırasında alınan ve ana hasar kaydında saklanan temel bir veri öğesidir.

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 analizinde kritik öneme sahiptir; reddedilen hasarları azaltma ve kabul kalitesini iyileştirme fırsatlarını ortaya çıkarmaya yardımcı olur.

FINEOS Claims dokümantasyonuna bakın. Bu, genellikle 'Claim Denied' aktivitesi gerçekleştirildiğinde seçilen yapılandırılmış bir alan veya koddur.

Bu nitelik, her dosya için SLA performansına ilişkin net ve kategorik bir durum sağlar. 'Dosya Kapatma' tarihi ile 'Çözüm Hedef Tarihi' karşılaştırılarak sonuç 'Zamanında' ya da 'Gecikmiş' olarak sınıflandırılır.

Bu sayede SLA uyumunun raporlanması ve analizi sadeleşir. Analistler ham tarihler yerine bu basit kategoriyi kullanarak SLA uyum oranını gösteren dashboard'lar oluşturabilir, geciken tüm dosyaları filtreleyip ortak özelliklerini inceleyebilir ve zaman içindeki SLA performans eğilimlerini izleyebilir. Bu nitelik, SLA Uyum dashboard'u ve KPI'yı doğrudan besler.

Her dosya için SLA performansını açık ve sade bir göstergeyle sunar; SLA uyum oranını ölçmeyi ve analiz etmeyi kolaylaştırır.

Bu, her dosya için son etkinliğin zaman damgası ile 'ResolutionTargetDate'in karşılaştırılmasından türetilen hesaplanmış bir alandır.

Bu nitelik, 'Kapalı' durumdaki bir hasar dosyasının neden yeniden aktive edildiğini belirtir. Yaygın nedenler arasında yeni bilginin gelmesi, hak sahibinin itirazı ya da bir hatanın düzeltilmesi yer alır.

Yeniden açılma nedenlerini incelemek, sürecin kalitesini ve kapanışların kalıcılığını doğrudan ölçmenin bir yoludur. Özellikle belirli gerekçelerle çok sayıda dosyanın yeniden açılması, ilk kapanışın hatalı olduğunu gösterir. Bu veriler, inceleme veya karar aşamalarındaki zayıflıkları ortaya çıkararak dosyaların ilk seferde doğru şekilde kapatılması için net iyileştirme hedefleri sunar.

Bir talebin erken ya da hatalı kapatıldığı süreç arızalarına doğrudan içgörü sunar; ilk seferde çözüm oranını artırma fırsatlarını öne çıkarır.

FINEOS Claims dokümantasyonuna bakın. Bu gerekçe genellikle kullanıcı sistemde 'Reopen Claim' işlemini gerçekleştirdiğinde kaydedilir.

Bu hesaplanmış nitelik, aynı dosya için ikinci kez 'Ek Bilgi Talep Edildi' gibi yeniden işlemeyi temsil eden aktiviteleri işaretler. Genellikle yinelenen aktivitelerin veya süreç akışındaki geri döngülerin tespitiyle belirlenir.

Yeniden işlemeyi açıkça işaretlemek, verimsizlik odaklı analizi sadeleştirir. Yeniden işleme oranı gibi önemli bir performans göstergesini kolayca ölçmeyi sağlar. Dashboard'lar bu işareti kullanarak yeniden işlemenin sıklığını ve etkisini görselleştirir; böylece bu verimsiz döngülerin kök nedenleri nokta atışı belirlenebilir.

Verimsiz süreç döngülerini doğrudan işaretler; yeniden işleme oranını hesaplamayı ve tekrarlanan işi tetikleyen unsurları analiz etmeyi kolaylaştırır.

Bu alan, process mining analizi sırasında aynı dosya için yinelenen etkinlikler belirlenerek türetilir. Örneğin, 'Investigation Started' etkinliğinin ikinci kez gerçekleşmesi işaretlenir.