Veri Şablonu: Hasar Süreçleri

Başlangıç Zamanı, bir aktivitenin başladığı anı gösteren kesin bir tarih ve saat bilgisidir. Süreç logundaki her event için kritik bir veri olup, performans analizi için gerekli zamansal bağlamı sağlar.

Process Mining'de Başlangıç Zamanı, bir case'in yolculuğunu doğru bir şekilde yeniden yapılandırmak için event'leri kronolojik olarak sıralamak adına hayati öneme sahiptir. Döngü süreleri, bekleme süreleri ve işlem süreleri gibi temel performans göstergelerinin hesaplanmasının temelini oluşturur. Timestamp'leri analiz etmek, adımlar arasındaki gecikmeleri belirlemeye, hizmet seviyesi anlaşmalarına (SLA) uyumu ölçmeye ve talep işleme sürecinin zamansal dinamiklerini anlamaya yardımcı olur.

Bu timestamp, event'leri doğru şekilde sıralamak ve döngü süreleri ile Bottleneck'ler gibi tüm zamanla ilgili metrikleri hesaplamak için esastır.

Genellikle olay günlükleri, denetim kayıtları veya işlem verilerinde kaydedilir ve sıklıkla 'olay zamanı' ya da 'oluşturma tarihi' olarak etiketlenir.

Hasar Kimliği, her sigorta hasarına kaydı sırasında atanan benzersiz bir anahtardır. İlk başvurudan nihai kapanışa kadar hasarın tüm yaşam döngüsü boyunca ilgili tüm faaliyetleri, olayları ve veri noktalarını birbirine bağlayan merkezi bir bağlayıcı görevi görür.

Process Mining'de, Hasar Kimliği her hasarın uçtan uca yolculuğunu yeniden yapılandırmak için kritik öneme sahiptir. Yazılım, aynı Hasar Kimliği'ne sahip tüm olayları gruplandırarak süreç akışını görselleştirebilir, varyasyonları tespit edebilir ve vaka bazlı metrikleri hesaplayabilir. Bu sayede, eksper atamasından ödeme yapılmasına kadar her eylemin ait olduğu belirli hasara doğru şekilde atfedilmesi sağlanarak tutarlı ve doğru bir süreç analizi gerçekleştirilir.

Bu, ilgili tüm event'leri birbirine bağlayan temel case tanımlayıcısıdır ve her talebin uçtan uca yolculuğunu takip etmeyi mümkün kılar.

Bir hasar dosyasının veya hasar yönetim sistemi işleminin başlığında ya da birincil kaydında genellikle yer alır.

Etkinlik Adı, talep işleme yaşam döngüsü içindeki belirli bir adımı, görevi veya olayı açıklar. Bu etkinlikler, 'Talep Kaydedildi', 'Soruşturma Başlatıldı' veya 'Ödeme Yapıldı' gibi yapılan işi temsil eder. Her etkinlik, olay günlüğünde yakalanan süreçteki ayrı bir noktadır.

Süreç madenciliği analizi için etkinlikler, süreç haritasının yapı taşlarıdır. Bu etkinliklerin 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 eyleme geçirilebilir bir süreç modeli oluşturmak için açık ve tutarlı etkinlik adlandırması kritik öneme sahiptir.

Aktiviteler, süreç haritasının çekirdeğini oluşturur; süreç performansını anlamak için sırası ve süresi analiz edilerek tanımlanan adımlar ve görevlerdir.

Hasar yönetim sistemi içindeki olay günlüklerinde, denetim kayıtlarında veya işlem kayıtlarında bulunur.

Kaynak Sistem niteliği, faaliyetin orijinal olarak kaydedildiği belirli BT uygulamasını veya platformunu tanımlar. Karmaşık ortamlarda, hasar işleme verileri bir çekirdek hasar platformu, bir belge yönetim sistemi veya bir müşteri ilişkileri yönetimi (CRM) aracı gibi birden çok sistemden gelebilir.

Kaynak sistemi anlamak, veri doğrulaması ve süreç parçalanmasını analiz etmek için önemlidir. Veri kalitesi sorunlarını kaynağına kadar izlemeye yardımcı olur ve manuel veri transferleri veya farklı sistemler arasındaki iş devirlerinden kaynaklanan verimsizlikleri ortaya koyabilir. Bu analiz, daha iyi sistem entegrasyonu ve otomasyonu için fırsatları ortaya çıkarabilir.

Olay verilerinin (event data) kökenini belirler; bu, veri doğrulama ve birden fazla BT sistemi arasında süreç uygulamasını analiz etmek için çok önemlidir.

Bu bilgi, veri çıkarma mantığının bir parçası olabilir veya entegre sistemlerin event loglarında bir alan olarak depolanabilir.

Son Veri Güncellemesi, olay günlüğü (event log) verilerinin kaynak sistemlerden en son ne zaman yenilendiğini gösterir. Bu zaman damgası (timestamp), analiz edilen verinin güncelliği hakkında bağlam sağlayarak paydaşların verinin güncelliğinden haberdar olmasını sağlar.

Herhangi bir süreç analizinde, verinin güncelliğini bilmek, bilinçli kararlar almak için kritiktir. Bu öznitelik (attribute), kullanıcıların neredeyse gerçek zamanlı bir süreci mi yoksa geçmiş bir anlık görüntüyü mü görüntülediklerini anlamalarına yardımcı olur. Özellikle sürekli izleme panoları (dashboard) için ve çıkarılan herhangi bir sonucun ilgili ve güncel bilgilere dayanmasını sağlamak için önemlidir.

Verilerin güncelliği hakkında kritik bağlam sağlar; böylece analiz ve kararların güncel bilgilere dayandığından emin olunur.

Bu genellikle veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında üretilen metadata'dır.

Atanan Tazminat Uzmanı, belirli bir faaliyeti gerçekleştiren veya belirli bir anda hasardan sorumlu olan çalışanı veya kullanıcıyı belirler. Bu nitelik, süreç adımlarını bu adımları yürüten kişilerle ilişkilendirir.

Tazminat uzmanı özelinde yapılan veri analizi, iş yükü yönetimi, performans değerlendirmesi ve eğitim ihtiyaçlarının belirlenmesi açısından büyük önem taşır. Bu analiz sayesinde yöneticiler, ekip üyelerinin performanslarını karşılaştırabilir, işin adil dağılımını sağlayabilir ve yüksek performans gösterenlerle ek desteğe ihtiyacı olanları tespit edebilir. Kaynak bazındaki bu görünüm, ekip performansı ve iş yükü dengesiyle ilgili dashboard'lar için kritik bir role sahiptir.

Süreç faaliyetlerini bunları gerçekleştiren kişilerle ilişkilendirir; bu da iş yükü, ekip performansı ve kaynak tahsisi analizini sağlar.

İşlem kayıtlarında, denetim günlüklerinde veya hasar yönetim sistemi içindeki kullanıcı atama alanlarında bulunur.

Bitiş Zamanı, bir faaliyetin tamamlandığı anı gösteren kesin bir tarih ve zaman göstergesidir. Başlangıç Zamanı ile birlikte mevcut olduğunda, bir faaliyetin tamamlanmasının ne kadar sürdüğünün tam olarak ölçülmesini sağlar.

Bu nitelik, detaylı performans analizi için çok değerlidir. Başlangıç Zamanı ile Bitiş Zamanı arasındaki fark, 'işlem süresi' veya 'faaliyet süresi'ni sağlar; bu, verimsiz adımları belirlemek için kilit bir metriktir. İşlem sürelerini analiz etmek, hangi faaliyetlerin en çok kaynak tükettiğini ve operasyonları düzene sokma çabalarının nereye odaklanması gerektiğini belirlemeye yardımcı olur. Süreç darboğazları ve ekip performansı ile ilgili dashboard'lar oluşturmak için hayati öneme sahiptir.

Faaliyet işleme sürelerinin hassas bir şekilde hesaplanmasını sağlar; bu da darboğazları belirlemek ve kaynak verimliliğini analiz etmek için kritik öneme sahiptir.

Genellikle olay günlüklerinde veya denetim kayıtlarında başlangıç zamanıyla birlikte yer alır. Yalnızca değişiklik olayları kaydediliyorsa, bu verinin türetilmesi gerekebilir.

Departman niteliği, bir hasarın yaşam döngüsünün belirli bir aşamasında sorumlu olan organizasyonel grubu tanımlar. Örnekler arasında 'İlk Hasar İhbarı', 'Araştırma Birimi' veya 'Ödemeler Departmanı' yer alır.

Bu bilgi, kuruluşun farklı bölümleri arasındaki devirleri ve işbirliğini anlamak için büyük önem taşır. Süreci departman özelinde analiz etmek, bir hasar bir ekipten diğerine geçtiğinde ortaya çıkabilecek gecikmeleri gösterebilir. Bu, departmanlar arası darboğazları belirlemeye yardımcı olur. Ayrıca, Eksper İş Yükü Dengesi gibi KPI'ları ve Ekip Performansı dashboard'larını destekleyerek ekibe özel iş yüklerini ve performansını değerlendirmek için kritik öneme sahiptir.

Ekipler arası süreç aktarımlarını analiz etmeye ve departmanlar arası darboğazları (bottleneck) belirlemeye yardımcı olarak kurumsal performans analizini destekler.

Hasar kaydında saklanır; genellikle atanan kullanıcıyla veya mevcut süreç aşamasıyla ilişkilendirilir.

Çözüm Hedef Tarihi veya son teslim tarihi, hasar sürecini tamamlamak için belirlenen son tarihtir. Bu tarih genellikle yasal gereklilikler veya zamanında müşteri hizmeti sağlamak üzere tasarlanmış dahili Hizmet Seviyesi Anlaşmaları (SLA'lar) tarafından belirlenir.

Bu nitelik, uyumluluk ve performans izleme için kritiktir. Gerçek hasar kapanış tarihini hedef tarihle karşılaştırarak, kuruluşlar SLA Uyum Oranlarını ölçebilirler. Process Mining, hangi süreç adımlarının veya varyantlarının SLA ihlallerine neden olma olasılığının en yüksek olduğunu ortaya koyabilir. Bu, son teslim tarihlerinin proaktif yönetimine olanak tanır ve zamanında çözüm üzerinde en büyük etkiyi yaratacak iyileştirmelerin önceliklendirilmesine yardımcı olarak 'SLA ve Son Teslim Tarihi Uyumu' dashboard'ını doğrudan destekler.

SLA'lara veya yasal son teslim tarihlerine karşı süresinde performansı ölçmeyi sağlar; bu, süreç etkinliğinin kritik bir ölçütüdür.

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

Hasar Ciddiyeti, bir hasarın karmaşıklığını, aciliyetini veya potansiyel finansal maliyetinin değerlendirmesini sağlar. Bu sınıflandırma, hasarların önceliklendirilmesine ve uygun yetkinlikteki eksperlere yönlendirilmesine yardımcı olur. Ciddiyet; tahmini kayıp miktarı, olayın niteliği veya dava durumu gibi faktörlerle belirlenebilir.

Süreci Hasar Ciddiyeti'ne göre analiz etmek, işlem prosedürlerinin uygun şekilde uyarlanıp uyarlanmadığını anlamak için kritik öneme sahiptir. Örneğin, yüksek ciddiyetli hasarların daha uzun döngü sürelerine sahip olması beklenebilir, ancak daha titiz bir soruşturma süreci izlemesi gerekir. Bu öznitelik, karmaşık hasarların gerekli ilgiyi görmesini, basit hasarların ise hızlıca işlenmesini sağlayarak kaynak tahsisini ve müşteri memnuniyetini optimize etmeye yardımcı olur.

Basit ve karmaşık hasarları ayırt etmeye yardımcı olarak süreç uygulamasının hasar karmaşıklığına uygun şekilde uyarlanıp uyarlanmadığının analizini sağlar.

Genellikle talep alımı sırasında iş kuralları tarafından belirlenir ve ana talep kaydında bir alan olarak saklanır.

Hasar Türü, hasarları iş koluna veya kaybın niteliğine göre sınıflandıran bir kategoridir; örneğin 'Oto', 'Mülkiyet', 'Sorumluluk' veya 'İş Göremezlik' gibi. Farklı hasar türleri genellikle farklı süreç yollarını izler ve farklı karmaşıklık seviyelerine ve SLA'lara sahiptir.

Süreç analizini Hasar Türü'ne göre segmentlere ayırmak, anlamlı içgörüler elde etmek için temel bir tekniktir. Bu, farklı kategorilerdeki döngü sürelerinin, maliyetlerin ve süreç uyumluluğunun karşılaştırılmasına olanak tanır. Bu analiz, oto hasarları için verimli olan bir sürecin, mülkiyet hasarları için verimsiz olabileceğini ortaya çıkarabilir ve hedeflenmiş iyileştirme çabalarına rehberlik edebilir. Bu öznitelik, 'Hasar Kategorisine Göre Performans' Dashboard'u için çok önemlidir.

Taleplerin farklı iş kolları arasında segmente edilerek süreçleri ve performansı karşılaştırma imkanı sunar; bu sayede kategoriye özgü sorunlar ortaya çıkarılır.

Ana talep kaydında, genellikle talep ilk oluşturulduğunda belirlenen standart bir alan.

Ödeme Tutarı, bir hasarı çözmek için ödenen toplam parasal değeri temsil eder. Hasarın finansal etkisini yansıtan kritik bir sonuç metriğidir. Genellikle hasar değerlendirildikten ve bir karar verildikten sonra belirlenir.

Process Mining'de bu nitelik, maliyet bazlı analiz için kritik öneme sahiptir. 'Hasar Başına Ortalama Maliyet' gibi KPI'ların hesaplanmasına ve süreç varyasyonlarının finansal sonuçları nasıl etkilediğini araştırmaya olanak tanır. Örneğin, analizler belirli yeniden işleme döngülerine sahip veya daha uzun çevrim süreleri olan hasarların daha yüksek ödeme tutarlarıyla sonuçlanma eğiliminde olduğunu gösterebilir. Bu, süreç verimliliği ile finansal performans arasında doğrudan bir bağlantı kurar ve 'Hasar Maliyet Analizi' dashboard'ını destekler.

Bu, süreç davranışını finansal etkiyle doğrudan ilişkilendiren, süreç iyileştirmelerinin maliyet-fayda analizini sağlayan temel bir sonuç metriğidir.

Hasarla ilişkili finansal veya ödeme kayıtlarında bulunur, hasar kapatıldığında veya ödeme yapıldığında sonuçlandırılır.

Başvuru Kanalı, bir talebin şirkete ilk olarak nasıl bildirildiğini gösterir. Yaygın kanallar arasında online müşteri portalı, mobil uygulama, acente, broker veya geleneksel posta bulunur.

Süreci başvuru kanalına göre analiz etmek, veri kalitesi, verimlilik ve müşteri deneyimindeki önemli farklılıkları ortaya çıkarabilir. Örneğin, dijital bir portal aracılığıyla gönderilen taleplerde, postayla gönderilenlere kıyasla daha az veri giriş hatası ve daha hızlı ilk işlem süreleri olabilir. Bu içgörüler, hangi kanalların teşvik edileceği ve otomasyon ile süreç iyileştirmelerine nereye yatırım yapılacağı konusunda stratejik kararlar alınmasına yardımcı olur.

Giriş kanalının süreç verimliliğini, veri kalitesini ve genel döngü süresini nasıl etkilediğini analiz etmeye yardımcı olur.

Genellikle 'İlk Hasar İhbarı' (FNOL) süreci sırasında kaydedilir ve ana hasar kaydında tutulur.

Hasar Durumu, bir olayın gerçekleştiği anda hasarın yaşam döngüsü içindeki durumunu gösterir. Bu durum, hasarın süreçte nerede olduğuna dair üst düzey bir özet sunar; örneğin 'Soruşturma Altında', 'Bilgi Bekleniyor' veya 'Sonuçlandı' gibi.

Proses madenciliği, faaliyetlerden detaylı akışı yeniden yapılandırırken, Hasar Durumu özniteliği değerli bir bağlamsal katman sunar. Süreç akışını doğrulamak (örneğin, 'Ödeme Yapıldı' etkinliği durumu doğru bir şekilde 'Kapandı'ya taşıyor mu?) ve hasarların belirli durumlarda geçirdiği süreyi analiz etmek için kullanılabilir. Bu, vakaların ne kadar süre beklemede kaldığını anlamaya yardımcı olur ve sistemsel gecikmeleri veya verimsizlikleri vurgulayabilir.

Bir talebin herhangi bir zamandaki durumu hakkında bağlam sağlar, farklı aşamalarda harcanan zamanı analiz etmeye ve süreç akışını doğrulamaya yardımcı olur.

Ana talep kaydında yer alan, talebin yaşam döngüsü boyunca ilerledikçe güncellenen temel bir alan.

Hasar Tarihi, hasara yol açan olayın (örn. trafik kazası, mal hasarı) gerçek tarihini belirtir. Bu, hasarın sisteme bildirildiği veya kaydedildiği tarihten farklıdır.

Hasar Tarihi ile hasar kayıt tarihi arasındaki fark 'bildirim gecikmesi' olarak bilinir. Bu gecikmeyi analiz etmek, müşteri davranışlarını anlamak ve potansiyel dolandırıcılık risklerini (örn. bildirimde alışılmadık derecede uzun gecikmeler) belirlemek açısından büyük önem taşır. Olaydan çözüme kadar tüm hasar deneyiminin daha eksiksiz bir zaman çizelgesini sunarak sadece dahili işlem süresinden daha geniş bir bakış açısı sağlar.

Gerçek olayın tarihini belirler, raporlama gecikmelerinin analizine ve olaydan kapanışa kadar olan tam zaman çizelgesine olanak tanır.

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

Poliçe Numarası, bildirilen hasarı kapsayan sigorta sözleşmesinin benzersiz referansıdır. Hasarı belirli bir müşteri, poliçe şartları, teminat limitleri ve diğer sözleşmesel detaylarla ilişkilendirir.

Süreç akışı analizinde doğrudan kullanılmasa da, Poliçe Numarası kritik bir bağlamsal bilgidir. Tek bir poliçe sahibinden sıkça gelen hasarlar gibi kalıpları ortaya çıkarabilen hasar verilerinin poliçe veya müşteri düzeyinde toplanmasını sağlar. Ayrıca, daha gelişmiş segmentasyon ve analiz için hasar verilerinin poliçe seviyesindeki detaylarla (örn. poliçe türü, teminat tutarı) zenginleştirilmesine de olanak tanır.

Hasarı belirli sigorta sözleşmesiyle ilişkilendirir; bu da daha derin ve bağlamsal analiz için poliçe verileriyle zenginleştirmeyi sağlar.

Talep alımı sırasında kaydedilen ve talep kaydının başlığında saklanan temel bir veri.

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

Ret nedenlerini analiz etmek, hem dahili süreçleri hem de müşteri iletişimini iyileştirme fırsatlarını belirlemek açısından büyük önem taşır. Örneğin, çok sayıda hasar eksik bilgi nedeniyle reddedilirse, bu durum başvuru sürecinin iyileştirilmesi gerektiğini gösterebilir. Ret nedenleri üzerinde yapılacak kök neden analizi, daha net poliçe diline, daha iyi müşteri eğitimine ve nihayetinde reddedilecek hasarlar için harcanan idari çabanın azaltılmasına katkıda bulunabilir.

Taleplerin neden ödenmediğine dair içgörü sağlar, müşteri iletişimini ve ön uç süreçlerini iyileştirmek için kök neden analizini mümkün kılar.

'Talep Reddedildi' faaliyeti gerçekleştiğinde önceden tanımlanmış bir listeden seçilir veya bir uzman tarafından metin olarak girilir.

Talep Edilen Tutar, hasarın ilk tahmini veya talep sahibi tarafından sürecin başında istenen miktardır. Bu değer, inceleme ve değerlendirme aşamasında daha sonra revize edilebilir.

Bu nitelik, çeşitli analizler için faydalıdır. Hasarın başlangıçtaki ciddiyet seviyesini belirlemek ve ilk talep ile nihai ödeme tutarı arasındaki farkı takip etmek için kullanılabilir. Bu farkı analiz etmek, ilk tahminlerin doğruluğu ve hasar sürecindeki maliyet kontrol önlemlerinin etkinliği hakkında içgörüler sunabilir. Finansal tahminleme ve karşılık ayırma için kritik bir girdidir.

Talebin başlangıçtaki finansal kapsamını temsil eder, hasar tespiti ve nihai ödeme tutarı ile sapmayı analiz etmek için faydalıdır.

İlk talep başvuru süreci sırasında kaydedilir ve talep kaydının finansal bölümünde saklanır.