Veri Şablonu: Hasar Süreçleri Yönetimi

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.

Bir talebin yaşam döngüsünü izlemek için temel anahtardır. Benzersiz bir Claim ID olmadan, analiz amacıyla farklı süreç adımlarını tek bir tutarlı yolculukta birleştirmek mümkün değildir.

Genellikle Case nesnesindeki 'CaseNumber' ya da 'Claim' (FinancialServicesCloud.Claim) nesnesindeki özel bir benzersiz ID alanıdır.

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, '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.

Genellikle veri çıkarma ve dönüştürme sürecinde, veri setinin kaynağını etiketlemek için eklenen sabit bir değerdir.

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, çalıştırma anında veri çıkarma aracı veya ETL süreci tarafından üretilir ve veri setine işlenir.

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.

Case veya Claim nesnesindeki 'OwnerId' alanıdır; hasar uzmanının adını almak için User nesnesine 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.

Genellikle Claim/Case nesnesindeki özel bir picklist alanıdır; çoğunlukla 'Origin' veya 'Channel' olarak adlandırılı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.

Case veya Claim nesnesi üzerindeki standart 'Status' alanı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.

Genellikle Case veya Claim nesnesi üzerindeki standart 'Type' ya da özel bir picklist alanı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.

Financial Services Cloud’daki Claim nesnesinde özel bir para birimi alanı olur; örneğin 'ClaimedAmount__c'.

Bu metrik, tek bir süreç adımının süresini hesaplar ve o adım üzerinde harcanan 'aktif' zamanı temsil eder. Genellikle bir aktivitenin End Time ve Start Time değerleri arasındaki fark olarak hesaplanır.

Darboğaz analizinin temel metriklerinden biridir. 'Process Step Duration Breakdown' dashboard’u, en fazla zamanı tüketen belirli aktiviteleri göstermek için bu hesaplamayı kullanır; böylece iyileştirme çabalarının en çok etki yaratacağı noktalara odaklanılmasını sağlar.

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.

Claim nesnesinde özel bir tarih alanı olur; örn. 'DateOfLoss__c'.

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 ilgili Account veya Contact nesnesindeki adres alanları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.

Claim/Case nesnesi üzerinde, Account veya Contact nesnesini işaret eden bir lookup alanıdır (örn. 'AccountId' veya 'ContactId').

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.

Genellikle türetilir. Bir event ile ilişkili kullanıcı genel bir 'System' veya 'Integration' kullanıcısı ise bu bayrak true olarak işaretlenir.

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.

Financial Services Cloud’da 'InsurancePolicy' nesnesine referans veren, Claim nesnesi üzerinde bir lookup alanı olur.

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.

Genellikle Claim/Case nesnesinde bulunan özel bir picklist alanıdır ve durum 'Rejected' veya 'Closed - Denied' olduğunda zorunlu hâle gelir.

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.

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.

Genellikle Claim/Case nesnesi üzerinde, başvuru tarihi ve talep türüne göre hesaplanan özel bir formül alanı ya da bir tarih alanıdır.

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 talebin nihai finansal etkisini ifade eder; finansal analiz, karşılık ayırma ve ilk hasar tahminlerinin doğruluğunu değerlendirmek için kritiktir.

Financial Services Cloud’da Claim nesnesinde veya ilişkili bir Payment nesnesinde özel bir para birimi alanı olur.

Bu metrik, bir talep dosyasının ilk başvurusundan nihai kapanışına kadar geçen uçtan uca toplam süreyi ölçer. Belirli bir Claim ID için en son event ile ilk event'in timestamp değerleri arasındaki fark olarak hesaplanır.

Süreç performansı için en önemli KPI’lardan biridir; 'Average Claim Cycle Time' KPI’sı ve 'Claim End-to-End Cycle Time' dashboard’u bu metriği doğrudan ele alır. Bu değeri düşürmek, süreç iyileştirme projelerinin çoğunda birincil hedeftir.

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.