Hasar Süreçleri Data Şablonunuz

Talep Kimliği (Claim ID), tek bir sigorta talebine ait tüm faaliyetleri, olayları ve veri noktalarını gönderimden kapanışa kadar birbirine bağlayan temel vaka tanımlayıcısıdır.

Proses madenciliğinde, bu nitelik her talebin uçtan uca yolculuğunu yeniden yapılandırmak için kritik öneme sahiptir. İlgili tüm olayların tutarlı bir vaka halinde toplanmasını sağlayarak, bireysel talepler için döngü süreleri, süreç varyantları ve darboğazların analiz edilmesine olanak tanır.

Bu, bir talep yaşam döngüsünü takip etmek için temel anahtar konumundadır. Benzersiz bir Talep Kimliği olmadan, çeşitli süreç adımlarını tutarlı bir analiz akışına bağlamak mümkün değildir.

Bu genellikle Case objesi üzerindeki 'CaseNumber' veya 'Claim' (FinancialServicesCloud.Claim) objesi üzerindeki özel benzersiz bir ID field'ıdır.

Bu öznitelik, 'Hasar Başvuruldu', 'İlk İnceleme Yapıldı' veya 'Ödeme Yapıldı' gibi hasar sürecindeki tek bir adımı veya dönüm noktasını tanımlar. Süreç haritasının omurgasını oluşturur.

Faaliyetlerin sırasını ve sıklığını analiz etmek, en yaygın süreç yollarını (varyantları) belirlemeye, standart süreçten sapmaları keşfetmeye ve sıkça tekrarlanan, yeniden işlemeye işaret eden faaliyetleri tespit etmeye yardımcı olur.

Süreçteki 'neyi' tanımlar; bu da süreç akışının görselleştirilmesine, darboğazların, yeniden işleme döngülerinin ve süreç farklılıklarının belirlenmesine olanak tanır.

Talep/Vaka objesindeki 'Durum' alanındaki değişikliklerden veya ilişkili Görev veya Olay kayıtlarının 'Konusu'ndan türetilir.

Bu öznitelik, verinin çıkarıldığı kaynak uygulamayı veya platformu belirtir. Bu süreç için, sürekli olarak 'Salesforce Financial Services Cloud' olacaktır.

Sabit gibi görünse de, özellikle verinin birden fazla sistemden birleştirilebileceği ortamlarda, kaynak sistemi açıkça takip etmek iyi bir uygulamadır. Verinin kaynağı hakkında netlik sağlar ve veri yönetişimi ile doğrulaması için kullanışlıdır.

Veri yönetişimi, sorun giderme ve birden fazla kurumsal sistemden veri entegrasyonu için kritik öneme sahip veri kaynağını doğrular.

Bu genellikle veri çıkarma ve dönüştürme süreci sırasında veri setinin kaynağını etiketlemek için eklenen statik bir değerdir.

Event Time, hasar yaşam döngüsündeki her aktivite için kesin tarih ve saati sağlar ve bu zamansal veri, olayları kronolojik olarak sıralamak ve süreleri hesaplamak için kritik öneme sahiptir.

Analizde, zaman damgaları (timestamps) aktiviteler arasındaki döngü süreleri, bekleme süreleri ve toplam vaka süresi dahil olmak üzere tüm zamanla ilgili metrikleri hesaplamak için kullanılır. Dinamik bir süreç animasyonu oluşturmak ve gecikmelerin ne zaman ve nerede meydana geldiğini belirlemek için temel oluştururlar.

Bu öznitelik, her event için 'ne zaman' bilgisini sağlayarak süreleri hesaplamayı, zaman içinde süreç performansını analiz etmeyi ve zamana dayalı darboğazları tespit etmeyi mümkün kılar.

Durum değişiklikleri için bu, objenin alan geçmişindeki (örn. CaseHistory) 'CreatedDate' değeridir. Görevler için ise 'CompletedDateTime' veya 'CreatedDate' değeridir.

Bu öznitelik, verinin Salesforce Financial Services Cloud'dan en son ne zaman çekildiğini gösteren tarih ve saati belirtir. Analiz edilen verinin güncelliği için bir bağlam sunar.

Dashboard kullanıcılarının analizin ne kadar güncel olduğunu anlaması önemlidir. Verinin zamanlamasına ilişkin beklentileri yönetmeye yardımcı olur ve veri boru hatlarının planlandığı gibi çalıştığını doğrulamak için kritik öneme sahiptir.

Veri güncelliği hakkında kritik bağlam sağlar ve analistlerin ve iş kullanıcılarının süreç görünümünün ne kadar güncel olduğunun farkında olmasını temin eder.

Bu değer, veri çıkarma aracı veya ETL süreci tarafından, yürütme anında oluşturulur ve veri setine damgalanır.

Bu öznitelik, bir faaliyetten veya vakanın tamamından sorumlu olan bireysel hasar eksperini/sorumlusunu tanımlar. Genellikle hasar vakasının sahibinden veya belirli bir görevi tamamlayan kişiden türetilir.

Eksper bazında performansı analiz etmek, operasyonel yönetim için kritik öneme sahiptir. 'Eksper İş Yükü ve Performansı' gibi dashboard'lar, bu özniteliği kullanarak kişi başına hasar hacmini, aktif vakaları ve döngü sürelerini takip eder; böylece dengeli iş yükü dağılımını destekler ve koçluk fırsatlarını belirler.

Bu öznitelik, ekip ve bireysel performansı analiz etmek, iş yüklerini yönetmek ve en iyi uygulamaları veya eğitim ihtiyaçlarını belirlemek için temeldir.

Bu, Case veya Claim objesi üzerindeki 'OwnerId' field'ıdır ve eksperin adını almak için User objesine bağlanır.

Bu öznitelik, bir hasarın ilk olarak nasıl bildirildiğini gösterir; örneğin, web portalı, mobil uygulama, telefon araması veya e-posta aracılığıyla. Başvuru kanalı, başlangıçtaki bilgi kalitesini ve sonraki işleme adımlarını önemli ölçüde etkileyebilir.

Hasarları başvuru kanalına göre analiz etmek, talep modellerini ve farklı alım yöntemlerinin verimliliğini anlamaya yardımcı olur. 'Hasar Akışı ve Hacmi' dashboard'u, bu özniteliği kullanarak zaman içinde her kanaldan gelen hasar sayısını takip eder; bu da kaynak tahsisi ve teknoloji yatırım kararları için bilgi sağlar.

Farklı başvuru kanallarının verimliliğini değerlendirmeye ve belirli kanalların daha fazla yeniden işleme veya daha uzun döngü sürelerine yol açıp açmadığını anlamaya yardımcı olur.

Bu genellikle Claim/Case objesi üzerinde, sıklıkla 'Kaynak' veya 'Kanal' olarak etiketlenen özel bir picklist field'ıdır.

Bitiş Zamanı (End Time) niteliği, bir faaliyetin tam olarak ne zaman sona erdiğini kaydeder. Başlangıç Zamanı (EventTime) başlangıcı işaretlerken, Bitiş Zamanı bir faaliyetin tamamlanmasının ne kadar sürdüğünü ölçmek için gereken diğer sınırı sağlar.

Analizde, hem Başlangıç Zamanı hem de Bitiş Zamanına sahip olmak, faaliyetler arası bekleme sürelerinden farklı olarak faaliyet işleme sürelerinin hassas bir şekilde hesaplanmasına olanak tanır. Bu durum, 'Süreç Adımı Süre Dağılımı' gibi gösterge tabloları oluşturmak ve sadece faaliyetler arası değil, belirli görevler içerisindeki verimsizlikleri tespit etmek için temeldir.

Her aktivite için aktif işlem süresinin kesin olarak hesaplanmasına olanak tanır; bu, katma değerli süreyi bekleme süresinden ayırmak için kritik öneme sahiptir.

Zaman damgası verilerinden türetilir. Örneğin, 'İlk İnceleme Yapıldı' bir durum değişikliğiyle tetiklenirse, EndTime, bir sonraki durum değişikliğinin zaman damgası olabilir.

Bu öznitelik, 'Bireysel Sigortalar', 'Ticari Araç' veya 'Özel Soruşturma Birimi' gibi hasara atanan iş birimini veya departmanı belirtir.

Süreci departman bazında analiz etmek, ekipler arasındaki performans farklılıklarını belirlemeye, iş yüklerinin nasıl dağıtıldığını anlamaya ve departmana özgü süreç sapmalarını veya darboğazlarını tespit etmeye yardımcı olur. Bu boyut, kuruluşun farklı bölümlerinin nasıl performans gösterdiğini görmek için 'Hasar SLA Uyumluluğuna Genel Bakış' gibi dashboard'larda değerli bir rol oynar.

Farklı iş birimleri arasında performans karşılaştırması yapılmasına olanak tanır; bu da en iyi uygulamaları belirlemeye ve kaynakları daha etkin bir şekilde tahsis etmeye yardımcı olur.

Bu, Claim/Case objesi üzerinde özel bir alan olabilir veya User objesindeki atanan kullanıcının profilinden veya rolünden çıkarılabilir.

Hasar Durumu, bir talebin yaşam döngüsündeki (Yeni, İnceleme, Müşteri Bekliyor veya Kapalı gibi) anlık aşamasını gösterir. Sürecin mevcut durumunu anlamak için kilit bir özelliktir.

Bu özellik, 'Açık Hasar Yaşlandırma Raporu' gibi operasyonel gösterge tablolarında iş yükünü görselleştirmek ve belirli bir durumda uzun süre takılı kalan talepleri belirlemek için yoğun olarak kullanılır. Durumlar arası geçişleri analiz etmek, süreç haritasındaki faaliyetleri tanımlamak için de ana yöntemdir.

Aktif hasarların mevcut durumuna gerçek zamanlı görünürlük sağlayarak, birikimlerin yönetilmesine ve takılmış vakaların belirlenmesine yardımcı olur.

Bu, Case veya Claim objesi üzerinde standart 'Durum' field'ıdır.

Hasar Tipi, hasar süreçlerini bölümlere ayırmak ve analiz etmek için kilit bir boyuttur. Farklı hasar türleri genellikle farklı süreçleri takip eder, farklı karmaşıklıklara ve SLA'lara tabidir.

Hasar Tipine göre performansı filtreleyerek veya karşılaştırarak, analistler türe özgü darboğazları ortaya çıkarabilir, hedeflenen SLA uyumunu değerlendirebilir ve süreç varyasyonlarının kategoriler arasında nasıl farklılaştığını anlayabilir. 'Hasar SLA Uyumluluk Genel Bakışı' gibi gösterge tablolarında daha hedefli içgörüler sunmak için kullanılır.

Hasarların segmentasyonuna olanak tanır; süreçleri karşılaştırmak, türe özgü sorunları belirlemek ve iyileştirme girişimlerini uyarlamak için kullanılır.

Bu genellikle Case veya Claim objesi üzerinde standart bir 'Tip' veya özel bir picklist field'ıdır.

Bu öznitelik, sürecin başlangıcında müşteri tarafından talep edilen toplam kayıp veya hasar miktarını temsil eder. Bu değer, genellikle hasarın karmaşıklığını, gereken inceleme düzeyini ve izlediği işleme yolunu etkiler.

Hasar değerine dayalı süreç metriklerini analiz etmek önemli modelleri ortaya çıkarabilir. Örneğin, daha yüksek değerli hasarlar daha uzun döngü sürelerine sahip olabilir, daha fazla adım içerebilir veya uzman ekiplere yönlendirilebilir. Bu, gerçekçi SLA'lar belirlemede ve finansal rezervleri tahmin etmede yardımcı olur.

Her vakaya finansal bağlam sağlar ve hasar değerinin süreç karmaşıklığını, süresini ve sonuçlarını nasıl etkilediğinin analiz edilmesine olanak tanır.

Bu, Financial Services Cloud'daki Claim objesi üzerinde, örneğin 'ClaimedAmount__c' gibi özel bir para birimi field'ı olacaktır.

Bu metrik, tek bir süreç adımının süresini, yani üzerinde harcanan 'aktif' zamanı hesaplar. Genellikle bir aktivitenin Bitiş Saati ile Başlangıç Saati arasındaki fark olarak hesaplanır.

Bu, darboğaz analizi için temel bir metriktir. 'Process Step Duration Breakdown' dashboard'u, en çok zaman harcayan belirli aktiviteleri göstermek için bu hesaplamadan faydalanır ve iyileştirme çabalarını en büyük etkiyi yaratacakları alanlara odaklamaya yardımcı olur.

Her adım için gerçek çalışma süresini nicelleştirerek, aktif işlem darboğazlarını atıl bekleme süresinden ayırt etmeye yardımcı olur.

Hesaplanan alan: 'EndTime' eksi 'EventTime' (StartTime). Bu hesaplama, process mining aracı içinde veya veri dönüşümü sırasında gerçekleştirilir.

Hasar Tarihi (Loss Date), sigorta poliçesi kapsamındaki olayın ne zaman gerçekleştiğini kaydeder. Bu tarih, talebin gönderildiği tarihten farklıdır.

Bu nitelik, uyumluluk ve olayın gerçekleşmesi ile raporlanması arasındaki gecikme süresini analiz etmek için önemlidir. Büyük boşluklar bazen potansiyel sorunlara işaret edebilir veya farklı işleme prosedürleri gerektirebilir. Olayların tam zaman çizelgesini anlamak için değerli bir bağlam sunar.

Bir olayın meydana gelişi ile raporlanması arasındaki gecikmeyi analiz etmeye yardımcı olur; bu da soruşturmayı ve uzlaşmayı etkileyebilir.

Bu, Claim objesi üzerinde, örn. 'DateOfLoss__c' gibi özel bir tarih field'ı olacaktır.

Bu öznitelik, hasar için coğrafi bağlam sağlar; örneğin hasarın meydana geldiği eyalet veya poliçe sahibinin ülkesi. Bu veri, poliçe sahibinin adresinden veya hasarın detaylarından türetilebilir.

Coğrafi analiz, hasar türleri, sıklıkları ve işlem sürelerindeki bölgesel eğilimleri ortaya çıkarabilir. Ayrıca farklı bölge ofislerindeki performansı değerlendirmek ve konuma özgü düzenlemelere uyumu sağlamak için de kullanılabilir.

Hasarların coğrafi analizine olanak tanır; bu da bölgesel performans farklılıklarını, dolandırıcılık modellerini veya yerel olayların etkilerini ortaya çıkarabilir.

Genellikle ilişkili Account veya Contact objesi üzerindeki adres field'larından (örn. 'BillingState', 'BillingCountry') türetilir.

Müşteri Kimliği (Customer ID), talebi başvuran kişi veya kuruluşa bağlar. Salesforce'da bu genellikle Hesap veya İlgili Kişi nesnesine bir bağlantıdır (lookup).

Bu nitelik, talep sürecine müşteri odaklı bir bakış açısı sunar. Müşteri başına talep geçmişini analiz etmek, sık talep oluşturanları belirlemek ve hizmeti kişiselleştirmek için kullanılabilir. Aynı zamanda, bütünsel bir iş görünümü elde etmek için talep verilerini bir CRM'deki diğer müşteri verileriyle bağlamak için de kritik öneme sahiptir.

Müşteri odaklı bir analiz imkanı sunar; bu sayede bireysel müşteriler için hasar kalıplarını anlamaya ve hasar sürecinin müşteri ilişkileri üzerindeki etkisini ölçmeye yardımcı olur.

Bu, Claim/Case objesi üzerinde, Account veya Contact objesine işaret eden bir lookup field'dır (örn. 'AccountId' veya 'ContactId').

Bu öznitelik, hasar kapatıldığında ve çözümlendiğinde başvuru sahibine ödenen gerçek miktarı kaydeder. Bu miktar, değerlendirme, muafiyetler ve poliçe limitleri nedeniyle başlangıçta talep edilen miktardan farklılık gösterebilir.

Ödeme miktarını, özellikle başlangıçta talep edilen miktarla ilişkili olarak analiz etmek, hasar değerlendirme doğruluğu ve ödeme müzakeresi sonuçları hakkında içgörüler sağlar. Hasarların toplam maliyetini anlamak için kritik bir finansal metriktir.

Bir hasarın nihai finansal etkisini temsil eder; finansal analiz, karşılık ayırma ve ilk hasar değerlendirmelerinin doğruluğunu ölçmek için kritik öneme sahiptir.

Bu, Financial Services Cloud'daki Claim objesi veya ilgili bir Payment objesi üzerinde özel bir para birimi field'ı olacaktır.

Bu flag, insan eksperler tarafından tamamlanan görevler ile otomatik iş akışları, kurallar veya sistem entegrasyonları tarafından yürütülen görevleri birbirinden ayırır. Örneğin, ilk hasar kaydı tamamen otomatik olabilir.

Otomasyonu analiz etmek, süreç verimliliğini anlamanın anahtarıdır. Otomasyon girişimlerinin başarısını ölçmeye, gelecekteki otomasyon için iyi aday olan adımları belirlemeye ve otomatik görevlerin hızı ile tutarlılığını manuel olanlarla karşılaştırmaya yardımcı olur.

Otomasyonun etkisini ve etkinliğini değerlendirmek için kritik öneme sahip olan insan kaynaklı ve sistem tabanlı aktiviteler arasında ayrım yapar.

Bu genellikle türetilmiştir. Bir event ile ilişkili kullanıcı genel bir 'Sistem' veya 'Entegrasyon' kullanıcısıysa, bu bayrak true olarak ayarlanır.

Poliçe Numarası (Policy Number), talebi müşterinin aktif sigorta poliçesine bağlar. Bu, teminat, limitler ve poliçe sahibinin geçmişi hakkında temel bağlam sağlar.

Süreç akışının her zaman birincil bir itici gücü olmasa da, bu önemli bir bağlamsal veri parçasıdır. Belirli poliçe türlerinin daha sık veya karmaşık taleplerle ilişkili olup olmadığını anlamak gibi daha derinlemesine analizler için talep verilerini poliçe verileriyle birleştirmek için kullanılabilir.

Hasarı temel sigorta poliçesine bağlayarak, belirli poliçeler veya teminat türleriyle ilgili hasar kalıplarının daha geniş bir analizine olanak tanır.

Bu, Claim objesi üzerinde, Financial Services Cloud'daki 'InsurancePolicy' objesine referans veren bir lookup field'ı olacaktır.

Bir hasar talebinin nihai kararı 'Reddedildi' olduğunda, bu nitelik 'Poliçe Kapsamında Değil', 'Dolandırıcılık Şüphesi' veya 'Eksik Bilgi' gibi red gerekçelerini sunar.

Bu, 'Hasar Red Nedenleri Analizi' dashboard'u için anahtar bir özelliktir. Çoğunlukla hasar türüne veya departmana göre ayrıştırılan farklı red nedenlerinin sıklığını analiz ederek kuruluş, underwriting'i iyileştirmek, poliçe dilini netleştirmek veya geçersiz başvuruları azaltmak amacıyla bilgi toplama sürecini geliştirmek için fırsatlar belirleyebilir.

Hasarların neden reddedildiğine dair doğrudan içgörü sunar; bu, sigorta poliçelerini iyileştirmek ve geçersiz hasarların gereksiz işlenmesini azaltmak için hayati öneme sahiptir.

Bu genellikle Claim/Case objesi üzerinde, durum 'Reddedildi' veya 'Kapandı - Reddedildi' olarak değiştirildiğinde zorunlu hale gelen özel bir picklist field'ıdır.

SLA Hedef Tarihi, talep çözümlemesi için son teslim tarihini temsil eden, hesaplanmış veya manuel olarak belirlenmiş bir tarihtir. Bu, zamanında performansın ölçüldüğü bir referans noktasıdır.

Bu nitelik, müşterilere veya düzenleyicilere verilen taahhütlere karşı performansı izlemek için hayati öneme sahiptir. Bu, 'SLA Uyumluluk Oranı' KPI'ı ve 'Talep SLA Uyumluluk Genel Bakışı' gösterge tablosu için temel oluşturur; böylece kuruluş, taleplerin yüzde kaçının zamanında çözüldüğünü izleyebilir ve hangi talep türlerinin veya departmanların hedeflerini karşılamakta zorlandığını belirleyebilir.

Hasar çözünürlük süresi için performans hedefini tanımlar ve SLA uyumluluğunun doğrudan ölçülebilmesini sağlar.

Bu genellikle Claim/Case objesi üzerinde, gönderim tarihi ve talep tipine göre hesaplanan özel bir formül field'ı veya tarih field'ıdır.

Bu öznitelik, genellikle 'Karşılandı' veya 'İhlal Edildi' gibi değerlere sahip kategorik bir sonuçtur. Hasarın fiili tamamlanma tarihi (son faaliyetin timestamp'i) ile 'SlaTargetDate' değerinin karşılaştırılmasıyla türetilir.

Bu öznitelik, 'SLA Uyum Oranı' KPI'si ve 'Hasar SLA Uyumluluğuna Genel Bakış' dashboard'u için temel metriktir. Hedeflere karşı performansın net ve somut bir ölçütünü sunar, uyum raporlaması ve operasyonel yönetim için vazgeçilmezdir.

Müşteri memnuniyeti ve yasal uyumluluk için kritik öneme sahip olan, zamanlama hedeflerine karşı performansın net bir göstergesini sunar.

Hesaplanan alan: Son olayın 'EndTime' değeri 'SlaTargetDate' değerine küçük veya eşitse 'Uygun', aksi takdirde 'İhlal Edildi' olarak işaretlenir. Bu mantık, veri dönüşümü sırasında veya process mining aracı içinde uygulanır.

Bu metrik, bir talep vakasının ilk gönderiminden nihai kapanışına kadar olan toplam uçtan uca süresini ölçer. Belirli bir Talep Kimliği için en son event'in timestamp'i ile ilk event'in timestamp'i arasındaki fark olarak hesaplanır.

Bu, süreç performansı için en önemli KPI'lardan biridir ve 'Ortalama Talep Çevrim Süresi' KPI'ı ile 'Talep Uçtan Uca Çevrim Süresi' dashboard'u tarafından doğrudan ele alınır. Bu değeri azaltmak, süreç iyileştirme projelerinin genellikle birincil hedefidir.

Sürecin genel uçtan uca verimliliğini ölçer ve müşteri deneyiminin temel bir göstergesidir.

Hesaplanan alan: Her bir 'ClaimId' için son olayın zaman damgası eksi ilk olayın zaman damgası. Bu, process mining aracı tarafından hesaplanır.

Bir hasar, sürecin önceki bir aşamasına geri döndüğünde bu flag 'true' olarak ayarlanır. Klasik bir örnek, 'İnceleme Tamamlandı' adımından 'Ek Bilgi Talep Edildi' adımına geri dönülmesidir. Yeniden işleme tespit etme mantığı, süreç bilgisine dayanarak tanımlanır.

Bu öznitelik, 'Hasar Yeniden İşleme Döngü Analizi' dashboard'u ve 'Yeniden İşleme Oranı' KPI'si için temeldir. Verimsizliğin, artan maliyetlerin ve daha uzun döngü sürelerinin temel itici gücü olan yeniden işlemenin sıklığını ve etkisini doğrudan nicelendirmeye olanak tanır.

Verimsiz süreç döngülerini doğrudan işaretler ve böylece yeniden işleme miktarının kolayca belirlenmesini ve temel nedenlerinin hedeflenen analizini mümkün kılar.

Hesaplanan alan. Bu, her bir vaka için faaliyet dizisini analiz ederek türetilir. Örneğin, 'A Aktivitesi'ni 'B Aktivitesi' takip ediyor ve ardından tekrar 'A Aktivitesi' geliyorsa, 'A'nın ikinci örneği yeniden işleme (rework) anlamına gelir.