Hasar Süreçleri Veri Template'inuz

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 (case) tanımlayıcısıdır.

Proses madenciliğinde, bu nitelik her talebin tüm sürecini yeniden yapılandırmak için büyük önem taşır. İ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 sunar.

Bu, bir talep süreç 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 temelini 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 sunar.

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 sunar 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 büyük önem taşıyan 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 süreç döngüsündeki her aktivite için tam tarih ve saati sunar ve bu zamansal veri, olayları kronolojik olarak sıralamak ve süreleri hesaplamak için büyük önem taşır.

Analizde, zaman damgaları (zaman damgası (zaman damgası)s) 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 sunar.

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 büyük önem taşır.

Veri güncelliği hakkında önemli bilgiler sunar 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 büyük önem taşır. 'Eksper İş Yükü ve Performansı' gibi kontrol paneli'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 büyük önem taşır.

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' kontrol paneli'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 sunar.

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ı sunar.

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 sunar. 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 büyük önem taşır.

Her aktivite için aktif işlem süresinin kesin olarak hesaplanmasına sunar; bu, katma değerli süreyi bekleme süresinden ayırmak için büyük önem taşır.

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ı (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 kontrol paneli'larda değerli bir rol oynar.

Farklı iş birimleri arasında performans karşılaştırması yapılmasına sunar; 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 süreç 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 stratejik bilgiler sunmak için kullanılır.

Hasarların segmentasyonuna sunar; 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 sunar ve hasar değerinin süreç karmaşıklığını, süresini ve sonuçlarını nasıl etkilediğinin analiz edilmesine sunar.

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

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 sunar; ö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 güçlüak için de kullanılabilir.

Hasarların coğrafi analizine sunar; 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, uçtan uca 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 büyük önem taşır.

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 stratejik bilgiler sunar. 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 büyük önem taşır.

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 büyük önem taşıyan 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 sunar.

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 sunar.

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' kontrol paneli'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 önemli bilgi sunar; bu, sigorta poliçelerini iyileştirmek ve geçersiz hasarların gereksiz işlenmesini azaltmak için büyük önem taşır.

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 büyük önem taşır. 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 sunar.

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 zaman damgası (zaman damgası)'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ış' kontrol paneli'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 büyük önem taşır.

Müşteri memnuniyeti ve yasal uyumluluk için büyük önem taşıyan 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 olayın zaman damgası (zaman damgası)'i ile ilk olayın zaman damgası (zaman damgası)'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' kontrol paneli'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ı (zaman damgası) eksi ilk olayın zaman damgası (zaman damgası)dır. 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' kontrol paneli'u ve 'Yeniden İşleme Oranı' KPI'si için büyük önem taşır. 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 ölçmeye sunar.

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 sunar.

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.