Hasar işleme Veri Templateiniz

Başlangıç Zamanı, bir faaliyetin başladığı anı gösteren kesin tarih ve saat bilgisidir. Süreç günlüğündeki her olay için performans analizi açısından gerekli zamansal bağlamı sağlar.

Process Mining kapsamında Başlangıç Zamanı, vaka yolculuğunu doğru şekilde yeniden oluşturmak için olayları kronolojik sıraya koymada temel rol oynar. Çevrim süreleri, bekleme süreleri ve işlem süreleri gibi temel performans göstergelerini hesaplamanın temelini oluşturur. Zaman damgalarını analiz etmek, adımlar arasındaki gecikmeleri belirlemeye, hizmet seviyesi anlaşmalarına (SLA) uyumu ölçmeye ve talep sürecinin zamansal dinamiklerini anlamaya yardımcı olur.

Bu zaman damgası, olayları doğru sıraya koymak ve çevrim süreleri ile darboğazlar gibi zamanla ilgili tüm metrikleri hesaplamak için gereklidir.

Genellikle olay günlüklerinde, denetim izlerinde veya işlem verilerinde bulunur ve çoğu zaman 'olay zamanı' ya da 'oluşturma tarihi' olarak adlandırılır.

Faaliyet Adı, talep işleme yaşam döngüsündeki belirli bir adımı, görevi veya olayı tanımlar. Bu faaliyetler, 'Talep Kaydedildi', 'İnceleme Başladı' veya 'Ödeme Yapıldı' gibi gerçekleştirilen işleri ifade eder. Her faaliyet, olay günlüğünde kaydedilen ayrı bir süreç noktasıdır.

Process Mining analizinde faaliyetler, süreç haritasının yapı taşlarını oluşturur. Bu faaliyetlerin sırasını, sıklığını ve süresini analiz etmek; gerçek süreç akışını, yaygın yolları, darboğazları ve standart prosedürden sapmaları ortaya çıkarır. Anlaşılır ve tutarlı faaliyet adları, anlaşılması kolay ve uygulanabilir bir süreç modeli oluşturmak için büyük önem taşır.

Faaliyetler, süreç haritasının temelini oluşturur. Süreç performansını anlamak için sıraları ve süreleri analiz edilen adımları ve görevleri tanımlar.

Genellikle talep yönetimi sistemindeki olay günlüklerinde, denetim izlerinde veya işlem kayıtlarında bulunur.

Talep Kimliği, her sigorta talebi kaydedildiğinde atanan benzersiz anahtardır. İlk gönderimden nihai kapatmaya kadar talebin yaşam döngüsü boyunca ilgili tüm faaliyetleri, olayları ve veri noktalarını birbirine bağlayan merkezi bağlantıyı oluşturur.

Process Mining kapsamında Talep Kimliği, her talebin uçtan uca yolculuğunu yeniden oluşturmak için temel unsurdur. Yazılım, aynı Talep Kimliğine sahip tüm olayları gruplayarak süreç akışını görselleştirebilir, farklılıkları belirleyebilir ve vaka düzeyindeki metrikleri hesaplayabilir. Hasar uzmanı atamasından ödemenin yapılmasına kadar her işlemin ait olduğu talebe doğru şekilde bağlanmasını sağlar. Böylece tutarlı ve doğru bir süreç analizi yapılabilir.

İlgili tüm olayları birbirine bağlayan bu temel vaka kimliği, her talebin uçtan uca yolculuğunun izlenmesini mümkün kılar.

Genellikle bir talep dosyasının veya talep yönetimi sistemi işlem kaydının üstbilgisinde ya da ana kaydında bulunur.

Kaynak Sistem özniteliği, faaliyetin ilk olarak kaydedildiği belirli BT uygulamasını veya platformunu tanımlar. Karmaşık ortamlarda talep işleme verileri, temel talep platformu, belge yönetim sistemi veya müşteri ilişkileri yönetimi (CRM) aracı gibi birden fazla sistemden gelebilir.

Kaynak sistemi anlamak, veri doğrulama ve süreç parçalanmasını analiz etmek açısından değerlidir. Veri kalitesi sorunlarının kaynağına kadar izlenmesine yardımcı olur ve farklı sistemler arasındaki manuel veri aktarımlarından veya iş devirlerinden kaynaklanan verimsizlikleri ortaya çıkarabilir. Bu analiz, daha iyi sistem entegrasyonu ve otomasyon fırsatlarını belirleyebilir.

Olay verilerinin kaynağını belirler. Bu bilgi, veri doğrulama ve birden fazla BT sistemi üzerinden süreç yürütümünü analiz etmek için gereklidir.

Bu bilgi, veri çıkarma mantığının bir parçası olabilir veya entegre sistemlerin olay günlüklerinde bir alan olarak saklanabilir.

Last Data Update, Event Log verilerinin kaynak sistemlerden en son yenilendiği zamanı gösterir. Bu zaman damgası, analiz edilen verilerin güncelliği hakkında bağlam sağlar ve paydaşların verilerin ne kadar güncel olduğunu bilmesine yardımcı olur.

Her süreç analizinde verilerin güncelliğini bilmek, bilinçli kararlar almak için büyük önem taşır. Bu öznitelik, kullanıcıların gerçek zamana yakın bir süreci mi yoksa geçmişe ait bir anlık görüntüyü mü incelediğini anlamasına yardımcı olur. Özellikle sürekli izleme Dashboardları ve çıkarılan sonuçların güncel ve ilgili bilgilere dayanmasını sağlamak açısından önemlidir.

Verilerin güncelliği hakkında önemli bağlam sağlar ve analiz ile kararların güncel bilgilere dayanmasına yardımcı olur.

Bu, genellikle veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde oluşturulan meta veridir.

Assigned Adjuster, belirli bir etkinliği gerçekleştiren veya belirli bir anda hasardan sorumlu olan çalışanı ya da kullanıcıyı gösterir. Bu öznitelik, süreç adımlarını bunları gerçekleştiren insan kaynaklarıyla ilişkilendirir.

Verileri hasar uzmanına göre analiz etmek, iş yükü yönetimi, performans değerlendirmesi ve eğitim ihtiyaçlarının belirlenmesi açısından önemlidir. Yöneticilerin ekip üyelerinin performansını karşılaştırmasına, işlerin adil biçimde dağıtılmasını sağlamasına ve yüksek performans gösteren ya da ek desteğe ihtiyaç duyabilecek kişileri belirlemesine imkan verir. Kaynak düzeyindeki bu görünüm, ekip performansı ve iş yükü dengesiyle ilgili Dashboardlar için önemlidir.

Süreç faaliyetlerini bunları gerçekleştiren kişilerle ilişkilendirerek iş yükü, ekip performansı ve kaynak tahsisi analizini mümkün kılar.

Talep yönetimi sistemindeki işlem kayıtlarında, denetim günlüklerinde veya kullanıcı atama alanlarında bulunur.

End Time, bir etkinliğin tamamlandığı anı gösteren kesin tarih ve saat bilgisidir. Start Time ile birlikte bulunduğunda, bir etkinliğin tamamlanmasının ne kadar sürdüğünü tam olarak ölçmenizi sağlar.

Bu öznitelik ayrıntılı performans analizi için çok değerlidir. Start Time ile End Time arasındaki fark, verimsiz adımları belirlemede kullanılan önemli bir metrik olan işlem süresini veya etkinlik süresini verir. İşlem sürelerini analiz ederek en fazla kaynağı hangi etkinliklerin tükettiğini ve operasyonları sadeleştirme çalışmalarının nereye odaklanması gerektiğini belirleyebilirsiniz. Bu bilgi, süreç darboğazları ve ekip performansıyla ilgili Dashboardlar oluşturmanın temelini oluşturur.

Faaliyet işlem sürelerinin kesin olarak hesaplanmasını sağlar. Bu, darboğazları belirlemek ve kaynak verimliliğini analiz etmek için gereklidir.

Genellikle olay günlüklerinde veya denetim izlerinde başlangıç zamanının yanında bulunur. Yalnızca değişiklik olayları kaydediliyorsa türetilmesi gerekebilir.

Department özniteliği, yaşam döngüsünün belirli bir aşamasında bir hasardan sorumlu olan kurumsal grubu belirtir. Örnekler arasında First Notice of Loss, Investigation Unit ve Payments Department bulunur.

Bu bilgi, kuruluşun farklı bölümleri arasındaki devir teslimleri ve iş birliğini anlamak için büyük önem taşır. Süreci departman bakış açısıyla analiz etmek, bir hasar bir ekipten diğerine geçtiğinde oluşan gecikmeleri ortaya çıkarabilir. Departmanlar arası darboğazları belirlemeye yardımcı olur ve ekiplerin iş yükünü ve performansını değerlendirmek için gereklidir. Ayrıca Adjuster Workload Balance gibi temel performans göstergelerini ve Team Performance Dashboardlarını destekler.

Ekipler arasındaki süreç devirlerini analiz etmeye ve departmanlar arası darboğazları belirlemeye yardımcı olarak kurumsal performans analizini destekler.

Genellikle talep kaydında saklanır ve çoğu zaman atanan kullanıcıyla veya mevcut süreç aşamasıyla ilişkilendirilir.

Resolution Target Date veya son tarih, hasar sürecinin tamamlanması için belirlenen son günü ifade eder. Bu tarih çoğu zaman düzenleyici gereklilikler veya müşterilere zamanında hizmet sunulmasını sağlamak üzere tasarlanmış kurum içi hizmet seviyesi anlaşmaları (SLA) tarafından belirlenir.

Bu öznitelik, uyumluluk ve performans izleme için temel öneme sahiptir. Kuruluşlar gerçek hasar kapatma tarihini hedef tarihle karşılaştırarak SLA Adherence Rate değerini ölçebilir. Process Mining, SLA ihlallerine yol açma olasılığı en yüksek süreç adımlarını veya varyantlarını vurgulayabilir. Böylece son tarihleri proaktif biçimde yönetebilir ve zamanında çözüm üzerinde en büyük etkiyi yaratacak iyileştirmelere öncelik verebilirsiniz. Bu yaklaşım, SLA and Deadline Adherence Dashboardını doğrudan destekler.

SLA'lara veya düzenleyici son tarihlere göre zamanında performansın ölçülmesini sağlar ve süreç etkinliğinin önemli bir göstergesidir.

Genellikle talep oluşturulduğunda iş kurallarına göre hesaplanır ve ana talep kaydında saklanır.

Talep Şiddeti, talebin karmaşıklığı, aciliyeti veya olası maliyeti hakkında değerlendirme sağlar. Bu sınıflandırma, taleplere öncelik verilmesine ve uygun beceri düzeyine sahip hasar uzmanlarına yönlendirilmesine yardımcı olur. Şiddet; tahmini kayıp tutarı, olayın niteliği veya hukuki süreç bulunması gibi faktörlere göre belirlenebilir.

Süreci Talep Şiddetine göre analiz etmek, işlem prosedürlerinin uygun şekilde uyarlanıp uyarlanmadığını anlamak açısından gereklidir. Örneğin yüksek şiddetli taleplerin daha uzun çevrim sürelerine sahip olması beklenebilir, ancak bu talepler daha ayrıntılı bir inceleme yolunu izlemelidir. Bu öznitelik, karmaşık taleplerin gerekli ilgiyi görmesini, basit taleplerin ise hızlıca işlenmesini sağlayarak kaynak tahsisini ve müşteri memnuniyetini iyileştirmeye yardımcı olur.

Basit ve karmaşık talepleri ayırt etmeye yardımcı olur ve süreç yürütümünün talep karmaşıklığına uygun şekilde uyarlanıp uyarlanmadığını analiz etmeyi sağlar.

Genellikle talebin ilk kaydı sırasında iş kurallarıyla belirlenir ve ana talep kaydında bir alan olarak saklanır.

Claim Type, hasarları iş koluna veya kaybın niteliğine göre sınıflandıran bir kategoridir. Örnekler arasında Auto, Property, Liability ve Disability bulunur. Farklı hasar türleri çoğu zaman farklı süreç yollarını izler ve farklı karmaşıklık düzeylerine ve SLA değerlerine sahiptir.

Süreç analizini Claim Type temelinde bölümlere ayırmak, anlamlı içgörüler elde etmek için temel bir tekniktir. Farklı kategoriler arasındaki çevrim sürelerini, maliyetleri ve süreç uyumluluğunu karşılaştırmanızı sağlar. Bu analiz, otomobil hasarları için verimli olan bir sürecin mülk hasarları için verimsiz olabileceğini ortaya çıkarabilir ve hedefli iyileştirme çalışmalarına yön verebilir. Bu öznitelik, Performance by Claim Category Dashboardı için gereklidir.

Talepleri bölümlere ayırarak farklı iş kollarındaki süreçleri ve performansı karşılaştırmayı, kategoriye özgü sorunları ortaya çıkarmayı sağlar.

Ana talep kaydında bulunan standart bir alandır ve genellikle talep ilk oluşturulduğunda belirlenir.

Settlement Amount, bir hasarı sonuçlandırmak için ödenen toplam parasal tutarı ifade eder. Bu, hasarın finansal etkisini gösteren önemli bir sonuç metriğidir. Tutar genellikle kayıp değerlendirildikten ve karar verildikten sonra belirlenir.

Process Mining içinde bu öznitelik, maliyet temelli analiz için gereklidir. Average Cost per Claim gibi temel performans göstergelerini hesaplamanızı ve süreç varyasyonlarının finansal sonuçları nasıl etkilediğini incelemenizi sağlar. Örneğin analiz, belirli yeniden çalışma döngülerine veya daha uzun çevrim sürelerine sahip hasarların daha yüksek uzlaşma tutarlarıyla sonuçlanma eğiliminde olduğunu gösterebilir. Bu bilgi, süreç verimliliği ile finansal performans arasında doğrudan bağlantı kurarak Claim Cost Analysis Dashboardının temelini oluşturur.

Bu, süreç davranışını finansal etkiyle doğrudan ilişkilendiren önemli bir sonuç metriğidir ve süreç iyileştirmelerinin maliyet-fayda analizini mümkün kılar.

Talebe bağlı finans veya ödeme kayıtlarında bulunur ve talep kapatıldığında ya da ödeme yapıldığında kesinleştirilir.

Gönderim Kanalı, bir talebin şirkete ilk kez nasıl bildirildiğini gösterir. Yaygın kanallar arasında çevrim içi müşteri portalı, mobil uygulama, acente, broker veya geleneksel posta bulunur.

Süreci gönderim kanalına göre analiz etmek, veri kalitesi, verimlilik ve müşteri deneyimindeki önemli farklılıkları ortaya çıkarabilir. Örneğin dijital portal üzerinden gönderilen taleplerde, posta yoluyla gönderilen taleplere kıyasla daha az veri giriş hatası ve daha kısa ilk işlem süreleri görülebilir. Bu içgörüler, hangi kanalların teşvik edileceği ve otomasyon ile süreç iyileştirmesine nerede yatırım yapılacağı konusunda stratejik kararları destekleyebilir.

Kayıt kanalının süreç verimliliğini, veri kalitesini ve toplam çevrim süresini nasıl etkilediğini analiz etmeye yardımcı olur.

Genellikle 'İlk Hasar Bildirimi' (FNOL) sürecinde kaydedilir ve ana talep kaydında saklanır.

Hasar Tarihi, talebe yol açan olayın, örneğin trafik kazası veya mülk hasarının, gerçekleştiği gerçek tarihi gösterir. Bu tarih, talebin sisteme bildirildiği veya kaydedildiği tarihten farklıdır.

Hasar Tarihi ile talebin kayıt tarihi arasındaki fark 'bildirim gecikmesi' olarak adlandırılır. Bu gecikmeyi analiz etmek, müşteri davranışını anlamak ve olası dolandırıcılık risklerini, örneğin bildirimde olağandışı uzun gecikmeleri, belirlemek açısından önemlidir. Yalnızca kurum içi işlem süresine kıyasla daha geniş bir görünüm sunarak olaydan sonuçlandırmaya kadar tüm talep deneyiminin daha eksiksiz bir zaman çizelgesini oluşturur.

Gerçek olayın tarihini belirler ve bildirim gecikmelerinin yanı sıra olaydan kapatmaya kadar geçen tüm zaman çizelgesinin analiz edilmesini sağlar.

Talep sahibi tarafından 'İlk Hasar Bildirimi' sırasında sağlanır ve ana talep kaydında saklanır.

Poliçe Numarası, bildirilen kaybı kapsayan sigorta sözleşmesinin benzersiz referansıdır. Talebi belirli bir müşteri, poliçe koşulları, teminat limitleri ve diğer sözleşme ayrıntılarıyla ilişkilendirir.

Poliçe Numarası süreç akışı analizinde her zaman doğrudan kullanılmasa da önemli bir bağlam bilgisidir. Talep verilerinin poliçe veya müşteri düzeyinde toplanmasını sağlar ve tek bir poliçe sahibinin sık talepte bulunması gibi örüntüleri ortaya çıkarabilir. Ayrıca talep verilerinin poliçe düzeyindeki ayrıntılarla, örneğin poliçe türü ve teminat tutarıyla zenginleştirilmesini sağlayarak daha gelişmiş bölümlendirme ve analiz imkânı sunar.

Talebi belirli bir sigorta sözleşmesiyle ilişkilendirerek daha derin ve bağlama dayalı analiz için poliçe verileriyle zenginleştirilmesini sağlar.

Talebin ilk kaydı sırasında alınan ve talep kaydının üstbilgisinde saklanan temel bir veri parçasıdır.

Ret Nedeni, bir talebin neden ödenmediğini açıklayan kod veya metin açıklamasıdır. Nedenler, poliçe kapsamındaki sorunlardan dolandırıcılık faaliyetlerine veya gerekli belgelerin sunulmamasına kadar değişebilir.

Ret nedenlerini analiz etmek, hem kurum içi süreçleri hem de müşteri iletişimini iyileştirme fırsatlarını belirlemek açısından gereklidir. Örneğin çok sayıda talebin eksik bilgi nedeniyle reddedilmesi, ilk kayıt sürecinin iyileştirilmesi gerektiğini gösterebilir. Ret nedenleri üzerinde kök neden analizi yapmak; daha açık poliçe metinlerine, daha iyi müşteri bilgilendirmesine ve sonunda reddedilecek talepler için harcanan idari emeğin azalmasına katkı sağlayabilir.

Hasarların neden ödenmediğini anlamanızı sağlar; müşteri iletişimini ve ön yüz süreçlerini iyileştirmek için kök neden analizi yapmanıza yardımcı olur.

Bir Hasar Reddedildi etkinliği gerçekleştiğinde, eksper önceden tanımlanmış bir listeden seçim yapar veya metin girer.

Talep Durumu, bir olay gerçekleştiği sırada talebin yaşam döngüsündeki konumunu gösterir. Bu durum, talebin süreçte hangi aşamada olduğuna dair üst düzey bir özet sunar. Örneğin 'İnceleniyor', 'Bilgi Bekleniyor' veya 'Sonuçlandırıldı' olabilir.

Process Mining, ayrıntılı akışı faaliyetlerden yeniden oluştururken Talep Durumu değerli bir bağlam katmanı sağlar. Süreç akışını doğrulamak, örneğin 'Ödeme Yapıldı' faaliyetinin durumu doğru şekilde 'Kapatıldı' olarak değiştirip değiştirmediğini kontrol etmek ve taleplerin belirli durumlarda ne kadar süre kaldığını analiz etmek için kullanılabilir. Bu, vakaların beklemede ne kadar kaldığını anlamaya ve sistemik gecikmeleri veya verimsizlikleri ortaya çıkarmaya yardımcı olur.

Herhangi bir zamanda talebin durumuna ilişkin bağlam sağlar, farklı aşamalarda geçirilen sürenin analiz edilmesine ve süreç akışının doğrulanmasına yardımcı olur.

Ana talep kaydındaki temel alandır ve talep yaşam döngüsünde ilerledikçe güncellenir.

Talep Edilen Tutar, sürecin başında kaybın ilk tahminini veya talep sahibinin istediği tutarı ifade eder. Bu değer, inceleme ve değerlendirme aşamasında daha sonra güncellenebilir.

Bu öznitelik çeşitli analizler için kullanışlıdır. Talebin ilk şiddet düzeyini belirlemek ve ilk talep tutarı ile nihai tazminat tutarı arasındaki farkı izlemek için kullanılabilir. Bu farkı analiz etmek, ilk tahminlerin doğruluğu ve talep sürecindeki maliyet kontrol önlemlerinin etkinliği hakkında içgörü sağlayabilir. Finansal tahmin ve karşılık ayırma için temel girdilerden biridir.

Talebin başlangıçtaki finansal kapsamını gösterir; şiddet değerlendirmesi ve nihai tazminat tutarıyla arasındaki farkın analizi için kullanışlıdır.

Talebin ilk oluşturulması sırasında kaydedilir ve talep kaydının finans bölümünde saklanır.