Hasar işlemleri Veri Templateiniz
Hasar işlemleri Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel aktiviteler
- Duck Creek Claims için veri çıkarma rehberi
Hasar taleplerinin işlenmesi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet adı ActivityName | Bir hasar talebi için belirli bir zamanda gerçekleşen iş faaliyetinin veya olayın adı. | ||
| Açıklama Bu öznitelik, hasar sürecinde gerçekleştirilen belirli bir adımı veya görevi tanımlar. Örneğin 'Hasar Talebi Gönderildi', 'Eksper Atandı' veya 'Ödeme Yapıldı'. Her faaliyet, hasar talebinin yaşam döngüsünde ayrı bir noktayı temsil eder. Bu faaliyetlerin sırasını ve sıklığını analiz etmek, Process Mining çalışmalarının temelini oluşturur. Süreç modellerinin keşfedilmesini, darboğazların belirlenmesini, yeniden işleme döngülerinin tespit edilmesini ve süreç sapmalarının standart bir modelle karşılaştırılmasını sağlar. Neden önemli? Faaliyet adı, süreç akışındaki adımları tanımlar. Bu bilgi, hasar sürecini keşfetmek, analiz etmek ve izlemek için temel oluşturur. Nereden alınır? Genellikle Duck Creek Claims içindeki Event Log, işlem adları veya durum değişikliği kayıtlarından elde edilir. Birden fazla kaynak alanının veya tablonun haritalanması gerekebilir. Örnekler Hasar bildirildiEksper atandıİnceleme başladıÖdeme yapıldıHasar kapatıldı | |||
| Hasar talebi kimliği ClaimId | Tek bir sigorta hasar talebini tanımlayan ve birincil vaka kimliği olarak kullanılan benzersiz tanımlayıcı. | ||
| Açıklama Hasar talebi kimliği, tek bir sigorta hasar talebiyle ilişkili tüm olayları ve faaliyetleri başvurudan kapanışa kadar birbirine bağlayan temel anahtardır. Hasar talebinin tüm yaşam döngüsünün tutarlı biçimde izlenmesini sağlar. Process Mining analizinde bu öznitelik, vaka görünümünü oluşturmak için gereklidir. Analistlerin her hasar talebinin tamamını izlemesine, uçtan uca çevrim sürelerini ölçmesine ve süreç varyantlarını analiz etmesine imkan verir. Neden önemli? Süreçteki tüm ilişkili olayları birbirine bağlayan temel Case ID budur. Böylece hasar talebinin yaşam döngüsü uçtan uca ve eksiksiz biçimde görüntülenebilir. Nereden alınır? Duck Creek Claims içindeki ana hasar talebi varlığında veya tablosunda bulunan birincil anahtardır. Belirli tablo ve alan adını öğrenmek için sistem belgelerine başvurun. Örnekler CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Olay zamanı EventTime | Belirli bir faaliyet veya olayın gerçekleştiği zamanı gösteren zaman damgası. | ||
| Açıklama Olay zamanı, hasar talebinin yaşam döngüsünde kaydedilen her faaliyet için kesin tarih ve saati sağlar. Bu zamansal bilgi, performans analizi için büyük önem taşır. Analizde bu zaman damgası, faaliyetler arasındaki çevrim sürelerini hesaplamak, bekleme sürelerini belirlemek, toplam vaka süresini ölçmek ve farklı dönemlerdeki süreç performansını analiz etmek için kullanılır. Zaman temelli tüm süreç metriklerinin temelini oluşturur. Neden önemli? Bu zaman damgası, çevrim süreleri ve süreler gibi zamana dayalı tüm metrikleri hesaplamak için gereklidir. Performans analizini ve darboğazların belirlenmesini sağlar. Nereden alınır? Duck Creek Claims içindeki olay veya işlem günlükleriyle ilişkili standart bir zaman damgası alanıdır. 'CreateDate', 'Timestamp' veya 'EventDate' gibi alanları arayın. Örnekler 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Atanan eksper AssignedAdjuster | Belirli bir faaliyette hasar talebini ele almaktan sorumlu eksperin adı veya kimliği. | ||
| Açıklama Bu öznitelik, bir etkinliği gerçekleştiren kullanıcıyı veya kaynağı tanımlar. Vaka farklı hasar uzmanları ya da ekipler arasında devredildikçe hasarın yaşam döngüsü boyunca değişebilir. Bu öznitelik, kaynak performansını, iş yükü dağılımını ve devir teslimleri analiz etmek için gereklidir. Hasar uzmanlarının işlem hacmine, iş yükü farklılıklarına ve darboğazların belirlenmesine odaklanan Dashboardlar, işin kişiler tarafından nasıl dağıtıldığını ve işlendiğini anlamak için çoğu zaman büyük ölçüde bu özniteliğe dayanır. Neden önemli? Kaynak performansını, iş yükü dengesini ve iş birliği modellerini analiz etmeyi sağlar. Darboğazların ve eğitim ihtiyaçlarının belirlenmesine yardımcı olur. Nereden alınır? Duck Creek Claims belgelerine başvurun. Hasar görevleri, olayları veya ana hasar talebi varlığıyla ilişkili tablolarda kullanıcı, sahip ya da atanan kişi alanlarını arayın. Örnekler John SmithJane DoeRobert Brownadjuster_1138 | |||
| Departman Department | Belirli bir zamanda faaliyetten veya hasar talebinden sorumlu departman ya da ekip. | ||
| Açıklama Bu öznitelik, hasar talebini ele alan işlevsel grubu veya departmanı tanımlar. Örneğin 'İlk Kabul', 'İnceleme Birimi' veya 'Mutabakat Ekibi'. Süreç akışına kurumsal bir bağlam kazandırır. Departman bazında analiz, süreç performansını toplu düzeyde anlamak için önemlidir. Departmanlar arası darboğazların belirlenmesine, ekip verimliliğinin ölçülmesine ve işin kuruluş içinde nasıl ilerlediğinin anlaşılmasına yardımcı olur. Neden önemli? İşlevsel alana göre performans analizi yapılmasını sağlar. Departmanlar arası devirleri ve ekibe özgü darboğazları görünür kılar. Nereden alınır? Duck Creek Claims belgelerine başvurun. Bu bilgi genellikle atanan kullanıcının profiliyle veya bir kuyruk/çalışma grubu atamasıyla ilişkilidir. Örnekler Oto HasarlarıKonut ve Ticari Mülk Hasarları - Büyük HasarÖzel İncelemeler BirimiÖdeme İşleme | |||
| Hasar talebi durumu ClaimStatus | Belirli bir zamandaki genel hasar talebi durumu. Örneğin Açık, Beklemede veya Kapalı. | ||
| Açıklama Hasar talebi durumu, talebin yaşam döngüsündeki mevcut konumunu gösterir. Genel süreç içinde talebin hangi aşamada olduğuna dair üst düzey bir özet sunar. Bu öznitelik, hasar talebi envanterinin üst düzey görünümlerini oluşturmak ve vakaları filtrelemek için kullanışlıdır. Bir talebin nihai sonucunu, örneğin 'Kapalı - Ödendi' veya 'Kapalı - Reddedildi', belirlemek için özellikle önemlidir. Bu bilgi, sonuç analizleri ve ret oranlarını anlamak açısından gereklidir. Neden önemli? Hasar talebinin mevcut durumu ve nihai sonucu hakkında anlık görünüm sağlar. Sonuç analizi ve vaka filtreleme için önemlidir. Nereden alınır? Duck Creek Claims belgelerine başvurun. Bu, ana hasar talebi kaydındaki temel alanlardan biridir. Örnekler AçıkBeklemede - Bilgi bekleniyorKapatıldı - Mutabakata varıldıKapatıldı - Reddedildi | |||
| Hasar talebi önem derecesi ClaimSeverity | Hasar talebinin finansal veya operasyonel karmaşıklığını gösteren Düşük, Orta veya Yüksek gibi sınıflandırma. | ||
| Açıklama Hasar talebi önem derecesi, bir talebin beklenen etkisi veya karmaşıklığı hakkında bilgi verir. İlk zarar tahminine, olayın niteliğine veya önceden tanımlanmış diğer iş kurallarına göre belirlenebilir. Bu öznitelik performans analizi için önemlidir. Yüksek önem derecesine sahip hasar talepleri genellikle daha fazla adım, daha uzun işlem süreleri ve uzman kaynaklar gerektirir. KPI'ları önem derecesine göre bölümlere ayırmak, gerçekçi performans hedefleri belirlemeye ve karmaşıklığın süreç verimliliği ile sonuçları nasıl etkilediğini anlamaya yardımcı olur. Neden önemli? Hasar taleplerini karmaşıklığa göre bölümlere ayırmayı sağlar. Böylece çevrim süreleri ve maliyetler daha ayrıntılı analiz edilebilir ve gerçekçi kıyaslamalar yapılabilir. Nereden alınır? Duck Creek Claims belgelerine başvurun. Bu, özel bir alan olabilir veya ilk zarar karşılığı tutarından türetilmiş olabilir. Örnekler DüşükOrtaYüksekFelaket düzeyinde | |||
| Hasar talebi türü ClaimType | Otomobil, mülk veya sorumluluk gibi sigorta hasar talebinin kategorisi. | ||
| Açıklama Hasar talebi türü, talepleri iş koluna veya zararın niteliğine göre sınıflandırır. Hasar verilerini bölümlere ayırmak ve analiz etmek için temel bir boyuttur. Bu öznitelik, farklı hasar talebi türleri arasındaki süreç performansını karşılaştırmak için kullanılır. Örneğin 'Otomobil - Tam Hasar' talebi, 'Mülk - Su Hasarı' talebinden çok farklı bir süreç izler ve farklı KPI'lara sahiptir. Hasar talebi türüne göre yapılan analiz, bağlam sağlar; daha anlamlı performans karşılaştırmalarına ve hedefe yönelik süreç iyileştirme çalışmalarına imkan verir. Neden önemli? Analizi bölümlere ayırmak için temel bir boyuttur. Farklı hasar talebi türlerinin süreçleri, SLA'ları ve karmaşıklık düzeyleri genellikle birbirinden farklıdır. Nereden alınır? Duck Creek Claims belgelerine başvurun. Bu, ana hasar talebi kaydındaki temel özniteliklerden biridir. Örnekler Bireysel Oto - ÇarpışmaTicari Mülk - Yangınİşçi TazminatıGenel Sorumluluk | |||
| Zarar tutarı LossAmount | Hasar talebinde bildirilen zararın tahmini veya gerçekleşen finansal tutarı. | ||
| Açıklama Bu öznitelik, hasar talebiyle ilişkili zararın ilk tahmini değerini gösterir. Genellikle talebin yönlendirilmesini, önem derecesini ve gereken inceleme düzeyini etkileyen temel bir finansal metriktir. Analizde zarar tutarı, hasar taleplerini bölümlere ayırmak ve finansal etkinin süreç davranışıyla nasıl ilişkili olduğunu anlamak için kullanılır. Örneğin, yüksek tutarlı hasar talepleri farklı yollar izleyebilir veya daha uzun çevrim sürelerine sahip olabilir. Operasyonel süreç verilerine önemli bir finansal bağlam kazandırır. Neden önemli? Hasar talebinin finansal bağlamını sağlar. Talep tutarının işlem yolunu, süresini ve sonucunu nasıl etkilediğinin analiz edilmesine imkan verir. Nereden alınır? Duck Creek Claims belgelerine başvurun. Bu, hasar talebindeki temel finansal alandır ve genellikle 'Bildirilen Zarar' veya 'İlk Karşılık' olarak adlandırılır. Örnekler 1500.0025000.50125000.00 | |||
| Bitiş zamanı EndTime | Bir faaliyetin tamamlandığı zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, bir faaliyetin tamamlanma zamanını gösterir. StartTime bir faaliyetin ne zaman başladığını belirtirken EndTime, ilgili görevin süresini hesaplamak için gereken diğer zamanı sağlar. Process Mining çalışmalarında faaliyetlerin hem başlangıç hem de bitiş zamanlarının bulunması, performansın çok daha ayrıntılı analiz edilmesini sağlar. 'İşlem Süresi'ni, yani görev üzerinde aktif çalışılan süreyi, görevler arasındaki 'Bekleme Süresi'nden ayırarak kesin biçimde hesaplamaya imkan verir. Bu ayrım, darboğazları doğru şekilde belirlemek için gereklidir. Neden önemli? Faaliyetlerin işlem sürelerinin kesin biçimde hesaplanmasını sağlar. Aktif çalışma süresini boşta kalma veya bekleme süresinden ayırarak doğru darboğaz analizi yapılmasına yardımcı olur. Nereden alınır? Event Log içinde ayrı bir zaman damgası alanı olarak bulunabilir veya aynı vaka için sıradaki faaliyetin StartTime değeri olarak türetilebilir. Örnekler 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Çözüm hedef tarihi ResolutionTargetDate | SLA'lara veya kurum içi hedeflere göre hasar talebinin çözümlenmesinin beklendiği hedef tarih. | ||
| Açıklama Bu öznitelik, hasarın kapatılması için son tarihi tutar. Bu tarih çoğu zaman mevzuat gereklilikleri, hizmet düzeyi anlaşmaları (SLA) veya temel performans göstergeleri (KPI) tarafından belirlenir ve hasar türüne ya da ciddiyetine göre değişebilir. Bu tarih, On-Time Claim Resolution Rate KPI’ının hesaplanmasının ve Claim Resolution Target Adherence Dashboardının temelini oluşturur. SLA ihlali riski taşıyan hasarları proaktif biçimde izlemenizi ve çalışmaları önceliklendirmenizi sağlar. Neden önemli? Hizmet düzeyi anlaşmalarına (SLA'lar) ve kurum içi hedeflere göre performansın ölçülmesini sağlar. Bu da müşteri memnuniyetini ve uyumluluğu doğrudan etkiler. Nereden alınır? Duck Creek Claims belgelerine başvurun. Bu, belirli bir SLA tarih alanı olabilir veya hasar talebi gönderim tarihi ile iş kurallarına göre hesaplanabilir. Örnekler 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
| Kaynak sistem SourceSystem | Olay verilerinin çıkarıldığı sistem. | ||
| Açıklama Bu öznitelik, hasar verilerinin geldiği kaynak uygulamayı tanımlar. Bu bağlamda değer sürekli olarak 'Duck Creek Claims' olur. Tüm veriler tek bir sistemden geliyorsa gereksiz görünebilir. Ancak veri yönetişimi, izlenebilirlik ve gelecekte birden fazla sistemden gelen verilerin birleştirilebileceği senaryolar için önemlidir. Verilerin kaynağı ve yapısı hakkında bağlam sağlar. Neden önemli? Veri soyu ve bağlamı hakkında gerekli bilgiyi sağlar. Özellikle birden fazla entegre sistemin bulunduğu ortamlarda veri yönetişimi ve sorun giderme için önemlidir. Nereden alınır? Genellikle veri çıkarma ve dönüştürme sürecinde eklenen, verilerin kaynağını belirten statik bir değerdir. Örnekler Duck Creek hasar talepleri | |||
| Mutabakat tutarı SettlementAmount | Hasar talebini sonuçlandırmak üzere üzerinde anlaşmaya varılan nihai finansal tutar. | ||
| Açıklama Bu öznitelik, hesaplanan ve ödeme için onaylanan sonuçlandırma tutarını kaydeder. Ödeme yapılan her hasar için sonuç odaklı önemli bir metriktir. Bu öznitelik, finansal analiz ve Payment Authorization & Issuance Time gibi Dashboardlar için büyük önem taşır. Karşılık doğruluğunu analiz etmek için ilk Loss Amount değeriyle karşılaştırılabilir ve hasar sürecinin finansal sonuçlarını anlamanın temelini oluşturur. Neden önemli? Hasar talebinin temel finansal sonucunu gösterir. Finansal raporlama ve ilk zarar tahminlerinin doğruluğunu analiz etmek için gereklidir. Nereden alınır? Duck Creek Claims belgelerine başvurun. Bu bilgi genellikle hasar talebiyle ilişkili finansal işlem veya ödeme tablolarında saklanır. Örnekler 1450.7522000.00115800.20 | |||
| Otomatik mi IsAutomated | Faaliyetin insan müdahalesi olmadan sistem tarafından otomatik olarak gerçekleştirilip gerçekleştirilmediğini gösteren boolean işareti. | ||
| Açıklama Bu işaret, insan kullanıcılar tarafından tamamlanan görevlerle sistem otomasyonu tarafından yürütülen görevleri birbirinden ayırır. Otomatik bildirimler, ilk veri doğrulaması veya doğrudan işleme adımları buna örnek verilebilir. Bu özniteliği analiz etmek, hasar sürecindeki otomasyon düzeyini anlamak için önemlidir. Otomasyon çalışmalarının etkisini ölçmeye, daha fazla otomasyon fırsatını belirlemeye ve otomatik adımların sonraki süreçlerde sorun oluşturmadan beklendiği gibi çalıştığını doğrulamaya yardımcı olur. Neden önemli? Otomasyonun verimlilik ve maliyet üzerindeki etkisini ölçmeye, ayrıca doğrudan işleme fırsatlarını belirlemeye yardımcı olur. Nereden alınır? Bu bilgi, bir olayla ilişkilendirilmiş 'user' değerinden, örneğin 'SYSTEM' veya 'BATCH', ya da olay kaydındaki özel bir işaretten çıkarılabilir. Örnekler truefalse | |||
| Poliçe numarası PolicyNumber | Hasar talebinin oluşturulduğu sigorta poliçesinin benzersiz tanımlayıcısı. | ||
| Açıklama Bu öznitelik, hasar talebini ilgili sigorta poliçesine bağlar. Talep ile ilişkili teminat, koşullar ve müşteri hakkında bağlam sağlar. Poliçe numarası süreç akışı analizinde her zaman doğrudan kullanılmasa da hasar verilerini zenginleştirmek için çok değerlidir. Poliçe ve müşteri verileriyle birleştirilerek süreç performansının müşteri segmentine, poliçe türüne veya poliçe yaşına göre nasıl değiştiği analiz edilebilir. Böylece daha bütünsel bir iş görünümü elde edilir. Neden önemli? Hasar talebini müşteri ve poliçeyle ilişkilendirir. Süreç performansının farklı müşteri segmentlerini veya poliçe türlerini nasıl etkilediğinin daha geniş kapsamda analiz edilmesini sağlar. Nereden alınır? Duck Creek Claims belgelerine başvurun. Bu, ana hasar talebi varlığındaki standart referans alanıdır. Örnekler PA-987654321CP-123456789WC-555444333 | |||
| Ret nedeni RejectionReason | Bir hasar talebinin reddedilmesinin veya geri çevrilmesinin özel nedeni. | ||
| Açıklama Hasar kararı bir talebin reddedilmesi yönünde verildiğinde bu öznitelik, kararın temelindeki nedeni gösterir. Bu değer genellikle önceden tanımlanmış kod veya açıklama listesinden seçilir. Ret nedenlerinin analizi, Claim Decision & Rejection Insights Dashboardı için büyük önem taşır. Bu analiz, başvurulardaki yaygın sorunları, olası sahtecilik örüntülerini veya poliçe metninin açık olmayabileceği alanları belirlemeye yardımcı olur. Elde edilen içgörü, ilk kabul sürecinde veya sigortalama kurallarında iyileştirmeler yapılmasını sağlayabilir. Neden önemli? Hasar taleplerinin neden reddedildiğini açıklar. İlk kabul sürecini iyileştirmek, geçersiz başvuruları azaltmak ve eğitim fırsatlarını belirlemek için uygulanabilir içgörüler sağlar. Nereden alınır? Duck Creek Claims belgelerine başvurun. Bu alan genellikle hasar talebinin durumu 'Reddedildi' veya benzer bir duruma getirildiğinde doldurulur. Örnekler Teminat kapsamındaki bir risk değilPoliçenin süresi dolduYinelenen hasar dosyasıDolandırıcılık şüphesi | |||
| Son veri güncellemesi LastDataUpdate | Kaynak sistemden yapılan en son veri yenilemesinin zaman damgası. | ||
| Açıklama Bu öznitelik, veri setinin en son ne zaman güncellendiğini gösterir. Analiz edilen verilerin güncelliğini değerlendirmek için referans noktası sağlar. Dashboard ve analizlerde, içgörülerin ne kadar güncel olduğu hakkında kullanıcılara bilgi vermek için kullanılır. En son işlemlerin süreç görünümüne dahil edilip edilmediği konusunda beklentilerin doğru yönetilmesine yardımcı olur. Neden önemli? Verilerin güncelliği hakkında bilgi verir. Bu bilgi, analizi doğru yorumlamak ve zamanında karar almak için önemlidir. Nereden alınır? Bu zaman damgası, veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde oluşturulur ve genellikle veri setinin meta verilerinde saklanır. Örnekler 2024-05-21T02:00:00Z | |||
| Yeniden işleme mi IsRework | Bir faaliyetin yeniden işleme döngüsünün parçası olup olmadığını gösteren hesaplanmış işaret. | ||
| Açıklama Bu boolean öznitelik, diğer farklı etkinlikler gerçekleştikten sonra bir etkinlik hasar için tekrarlandığında true olarak ayarlanır. Örneğin süreç Loss Assessed durumundan Investigation Started durumuna geri dönerse. Bu öznitelik, yeniden çalışmayı ölçmek ve analiz etmek için gereklidir. Claim Rework Rate KPI’ını ve Claim Rework & Reprocessing Patterns Dashboardını destekler. Yeniden çalışma içeren etkinlikleri ve vakaları doğrudan filtrelemenizi ve vurgulamanızı sağlar. Böylece süreçteki verimsizlikleri ve kalite sorunlarını belirleyebilirsiniz. Neden önemli? Yeniden işlemeyi faaliyet düzeyinde ölçer. Süreç verimsizliklerinin nedenlerini ve etkilerini ölçmeyi, görselleştirmeyi ve analiz etmeyi kolaylaştırır. Nereden alınır? Bu, kaynak sistemde bulunan bir alan değildir. Bir vaka içindeki tekrarlanan faaliyet dizilerini tespit eden algoritmalar kullanılarak veri hazırlama sırasında hesaplanır. Örnekler truefalse | |||
| Zamanında çözüldü mü IsOnTimeResolution | Bir hasar talebinin çözüm hedef tarihinde veya bu tarihten önce kapatılıp kapatılmadığını gösteren hesaplanmış işaret. | ||
| Açıklama Bu boolean öznitelik, Claim Closed etkinliğinin zaman damgası ile ilgili hasarın ResolutionTargetDate değeri karşılaştırılarak türetilir. Her hasarı zamanında (true) veya gecikmiş (false) olarak işaretler. Bu öznitelik, On-Time Claim Resolution Rate KPI’ını doğrudan destekler. Dashboardlarda SLA uyumunu kolayca toplamanıza ve görselleştirmenize, ayrıca geciken hasarların ortak özelliklerini (ör. belirli hasar türleri, departmanlar veya süreç yolları) belirlemek için ayrıntıya inmenize olanak tanır. Neden önemli? SLA uyumunu hasar talebi düzeyinde doğrudan ölçer. Süresi aşılmış talepler için etkili filtreleme ve kök neden analizi yapılmasını sağlar. Nereden alınır? Bu, kaynak sistemde bulunan bir alan değildir. Veri hazırlama sırasında son faaliyetin zaman damgası ile 'ResolutionTargetDate' alanı karşılaştırılarak hesaplanır. Örnekler truefalse | |||
Hasar taleplerinin işlenmesi faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Hasar bildirildi | Bu, sigortacıya İlk Hasar Bildirimi'nin (FNOL) ulaştığını gösteren ilk olaydır. Genellikle bir acente veya poliçe sahibi ilk hasar bilgilerini sisteme girdiğinde açık bir işlem olarak kaydedilir. | ||
| Neden önemli? Bu etkinlik, hasar yaşam döngüsünün tamamının başlangıcını gösterir. Bu etkinlik ile diğerleri arasındaki süreyi analiz etmek, toplam işleme süresini ve ilk başvuru verimliliğini anlamak için önemlidir. Nereden alınır? Bu, Duck Creek Claims içinde yeni bir hasar kaydı ilk oluşturulduğunda genellikle hasar veya FNOL log tablosuna kaydedilen açık bir olaydır. Yakalayın Yeni bir hasar kaydı ilk oluşturulduğunda kaydedilen olay. Olay türü explicit | |||
| Hasar kapatıldı | Bu, ödeme yapıldıktan veya hasar sonuçlandırıldıktan sonra hasar dosyasının idari olarak kapatıldığını gösteren son etkinliktir. Nihai durumun 'Closed' olarak güncellenmesiyle kaydedilir. | ||
| Neden önemli? Sürecin başarıyla sona erdiğini gösterir. 'Average End-to-End Claim Cycle Time' ve diğer temel süre metriklerini hesaplamak için bitiş noktasıdır. Nereden alınır? Hasarın ana veri tablosunda nihai durumun 'Closed' veya 'Settled' olarak değiştiği zaman damgasından çıkarılır. Yakalayın Hasarın nihai durumunun 'Closed' olarak belirlenmesinden çıkarılır. Olay türü inferred | |||
| Hasar kararı verildi | Bu etkinlik, 'Approved', 'Partially Approved' veya 'Denied' gibi hasara ilişkin resmi kararı gösterir. Nihai karar durumuna geçişten çıkarılan önemli bir kilometre taşıdır. | ||
| Neden önemli? Karar alma sürecinin önemli bir kilometre taşıdır. Bu noktaya kadar geçen süre ve kararın sonucu, süreç analizi ve verimliliğin temel unsurlarıdır. Nereden alınır? Özel 'Claim Decision' veya 'Claim Status' alanının 'Approved' veya 'Denied' gibi sonlandırıcı bir duruma değişmesinden çıkarılır. Bu değişikliğin zaman damgası kaydedilir. Yakalayın Hasarın birincil durum veya karar alanındaki güncellemeden çıkarılır. Olay türü inferred | |||
| Hasar reddedildi | Bu etkinlik, hasarın resmi olarak reddedildiği alternatif bir süreç sonunu gösterir. Hasarın nihai durumu 'Denied' veya 'Rejected' olarak belirlendiğinde kaydedilir. | ||
| Neden önemli? Ayrı olarak analiz edilmesi gereken önemli bir sonuçtur. Hasarların neden ve ne zaman reddedildiğini anlamak, ilk başvuru süreçlerini iyileştirmeye ve uyumluluğu yönetmeye yardımcı olur. Nereden alınır? Hasar varlığı tablosunda hasarın nihai durumu 'Denied', 'Rejected' veya 'Closed without Payment' olarak değiştiğinde oluşan zaman damgasından çıkarılır. Yakalayın Hasarın nihai durumunun bir ret nedeni olmasından çıkarılır. Olay türü inferred | |||
| Ödeme yapıldı | Bu etkinlik, hasar ödemesine ilişkin finansal işlemin gerçekleştirilmesini gösterir. Çek, EFT veya başka bir yöntemle ödeme gönderildiğinde oluşturulan açık bir olaydır. | ||
| Neden önemli? Onaylanan hasara ilişkin finansal yükümlülüğün tamamlandığını gösterir. 'Payment Authorized' ile 'Payment Issued' arasındaki süre, finans departmanının verimliliğini ortaya koyar. Nereden alınır? Tüm giden ödemeleri belirli bir işlem kodu ve zaman damgasıyla kaydeden Duck Creek Claims finansal işlem tablosundan alınır. Yakalayın Ödeme işlendiğinde ayrı bir finansal işlem logu kaydı oluşturulur. Olay türü explicit | |||
| Ödeme yetkilendirildi | Hesaplanan tazminat tutarının ödenmesi için verilen resmi onayı gösterir. Genellikle bir yönetici veya ayrı bir yetkili tarafından yürütülen ve açık bir onay işlemi olarak kaydedilen farklı bir adımdır. | ||
| Neden önemli? Ödeme öncesindeki önemli bir kontrol noktası ve olası bir darboğazdır. 'Claim Decision Made' ile bu nokta arasındaki süre, 'Average Claim Approval Time' KPI'ı ile ölçülür. Nereden alınır? Bu, genellikle belirli izinlere sahip bir kullanıcının ödemeyi onayladığı iş akışındaki veya finans modülündeki açık bir olaydır. Bu olay onay günlüğünde bulunabilir. Yakalayın İş akışında veya işlem günlüğünde kaydedilen açık bir onay olayıdır. Olay türü explicit | |||
| Ek bilgi alındı | Talep edilen bilginin alındığını ve hasar işlemenin devam edebileceğini gösterir. Bilgi, eksper tarafından manuel olarak kaydedilebilir veya dijital portal üzerinden gönderildiğinde otomatik olarak kayda alınabilir. | ||
| Neden önemli? 'Information Requested' ile 'Information Received' arasındaki süre önemli bir bekleme dönemidir. Bu süreyi analiz etmek, dış bağımlılıkları ve iletişim darboğazlarını belirlemeye yardımcı olur. Nereden alınır? Belge yönetim sistemi entegrasyonundan alınan açık bir olay olabilir. Alternatif olarak eksper, belgeleri aldığında manuel bir log kaydı veya durum değişikliği oluşturabilir. Yakalayın Belge yüklendiğinde veya eksper tarafından manuel giriş yapıldığında kaydedilen olay. Olay türü explicit | |||
| Ek bilgi talep edildi | Bu etkinlik, eksper daha fazla bilgi gerektiğine karar verip poliçe sahibine veya üçüncü bir tarafa talep gönderdiğinde gerçekleşir. Genellikle sistemin iletişim veya yazışma modülüyle bağlantılı açık bir olaydır. | ||
| Neden önemli? Bu etkinliğin sık gerçekleşmesi, ilk veri toplama sürecindeki sorunlara işaret edebilir. Ayrıca önemli bir bekleme süresi yaratır ve genel çevrim süresini etkiler. Nereden alınır? Duck Creek Claims içindeki giden iletişimlerle (ör. mektuplar, e-postalar) veya belirli bir Request for Information işlemiyle ilgili günlüklerden alınır. Yakalayın Bilgi talebine yönelik bir yazışma veya görev oluşturulduğunda kaydedilir. Olay türü explicit | |||
| Eksper atandı | Bu olay, kayıtlı hasara bir eksper veya hasar sorumlusu atanmasını gösterir. Sistem bu atamayı kaydederek net bir devir noktası oluşturur ve hasar yaşam döngüsü için sorumluluk belirler. | ||
| Neden önemli? Kaynak dağılımını ve eksper iş yükünü analiz etmek, ayrıca hasar atamalarındaki gecikmeleri belirlemek için önemlidir. Bekleme süresi yaratabilecek önemli bir devir noktasıdır. Nereden alınır? Ana hasar veri tablosundaki 'Assigned Adjuster' alanının güncellenmesiyle izlenir. Bu alanın geçmişi veya denetim logu zaman damgasını sağlar. Yakalayın Eksper alanı doldurulduğunda veya değiştirildiğinde denetim izine kaydedilir. Olay türü explicit | |||
| Hasar değerlendirildi | Bu kilometre taşı, inceleme bulgularına göre finansal karşılıkların belirlendiği veya güncellendiği noktayı gösterir. Hasarın finansal etkisinin tahmin edilmesini ifade eder ve karşılık tutarları girildiğinde veya ayarlandığında kaydedilir. | ||
| Neden önemli? Süreçteki önemli bir finansal kontrol noktasıdır. Ne zaman gerçekleştiğini analiz etmek, finansal değerlendirmenin hızı ve doğruluğu hakkında bilgi sağlar. Nereden alınır? Bu, genellikle Duck Creek Claims içindeki hasarın finansal işlem günlüğünde veya karşılık geçmişi tablosunda kaydedilen açık bir finansal işlemdir. Yakalayın Hasar karşılıklarının belirlenmesi veya güncellenmesi için kaydedilen finansal işlem. Olay türü explicit | |||
| Hasar kaydedildi | Bildirilen hasarın resmen kabul edilip kaydedildiğini gösterir. Bu aşamada benzersiz bir Claim ID atanır. Genellikle ilk veri doğrulamasının ardından gerçekleşen otomatik bir sistem olayıdır. | ||
| Neden önemli? Hasarın başlangıcını resmileştirir ve eksper ataması gibi sonraki süreçleri tetikler. Bildirim ile kayıt arasındaki süre, ilk veri kalitesi veya sistem yükü sorunlarına işaret edebilir. Nereden alınır? Birincil Claim ID'nin oluşturulduğu ve ana hasar varlığı tablosunda hasar durumunun 'pending' veya 'submitted' değerinden 'open' veya 'registered' değerine geçtiği zamanın damgasından çıkarılır. Yakalayın Birincil hasar kaydının oluşturulma zaman damgasından veya durumun 'Open' olarak değişmesinden türetilir. Olay türü inferred | |||
| İlk inceleme tamamlandı | Atanan eksperin hasarı ilk kez kapsamlı biçimde incelemesini tamamladığını gösterir. Genellikle atamadan sonra hasar durumunun 'Assigned' değerinden 'Under Review' veya 'Investigation' gibi bir değere geçmesiyle çıkarılır. | ||
| Neden önemli? Bu kilometre taşı, eksperin ilk işlemine kadar geçen süreyi ölçmeye yardımcı olur ve iş yükündeki olası birikmelere işaret edebilir. İnsan müdahalesi gerektiren ilk önemli kontrol noktasıdır. Nereden alınır? Hasar durumu alanındaki değişiklikten, örneğin 'Initial Review Complete' veya 'Pending Information' durumuna geçişten çıkarılır. Bu durum değişikliğinin zaman damgası kullanılır. Yakalayın Eksper atamasından sonra hasar durumu alanındaki değişiklikten çıkarılır. Olay türü inferred | |||
| İnceleme başladı | Bu etkinlik, hasarın resmi inceleme aşamasının başladığını gösterir. Genellikle hasar durumunun 'Under Investigation' veya benzer bir duruma değişmesinden çıkarılır. | ||
| Neden önemli? Kaynak yoğun bir aşamanın başlangıcını gösterir. İnceleme süresini ölçmek, 'Average Investigation Duration' KPI'ı için önemlidir ve sürecin önemli bir bölümünü yönetmeye yardımcı olur. Nereden alınır? Ana hasar durumu alanında hasar durumunun 'Investigation in Progress' veya 'Pending Inspection' olarak güncellendiği zaman damgasından çıkarılır. Yakalayın İnceleme faaliyetlerinin başladığını gösteren hasar durumu değişikliğinden türetilir. Olay türü inferred | |||
| İnceleme tamamlandı | Gerekli tüm bilgilerin toplandığı inceleme faaliyetlerinin sona erdiğini gösterir. Genellikle hasar durumunun 'Under Investigation' değerinden 'Pending Decision' gibi bir karar durumuna geçmesiyle çıkarılır. | ||
| Neden önemli? İncelemenin tamamlanması, karar alma ve tazminat aşamalarının önünü açan önemli bir kilometre taşıdır. Buradaki gecikmeler sonraki aşamaları önemli ölçüde etkiler. Nereden alınır? Hasar durumu değişikliğinin 'investigation' durumundan 'review' veya 'decision' durumuna geçtiği zaman damgasından çıkarılır. Yakalayın İnceleme faaliyetlerinin sona erdiğini gösteren hasar durumu değişikliğinden türetilir. Olay türü inferred | |||
| Tazminat hesaplandı | Onay kararının ardından bu etkinlik, nihai tazminat veya ödeme tutarının hesaplanmasını gösterir. Açık bir adım olabilir veya sistemin finans modülündeki ödeme tutarlarının kesinleştirilmesinden çıkarılabilir. | ||
| Neden önemli? Bu etkinlik, 'Settlement Rework Rate' KPI'ını ölçmek için önemlidir. Tek bir hasar için bu olayın birden fazla kez gerçekleşmesi, tazminat aşamasındaki verimsizliklere, hatalara veya görüşmelere işaret eder. Nereden alınır? Açık bir işlem günlüğü girdisi olabilir veya hasarın finansal verilerindeki Settlement Amount alanı güncellemelerinden çıkarılabilir. Bu alana ait denetim günlükleri temel kaynaktır. Yakalayın Nihai ödeme tutarı hesaplanıp kaydedildiğinde kaydedilen olay. Olay türü explicit | |||
Veri çıkarma rehberleri
Adımlar
- Duck Creek Data Hub Configuration Utility'ye erişin: Duck Creek ortamında oturum açın ve Data Hub uygulamasına gidin. Veri dışa aktarma yapılandırmaları oluşturmak veya değiştirmek için uygun izinlere sahip olmanız gerekir.
- Yeni bir veri dışa aktarma işi oluşturun: Data Hub yardımcı programında yeni bir dışa aktarma işi oluşturma işlemini başlatın. İşe ProcessMind_Claims_Event_Log_Export gibi açıklayıcı bir ad verin.
- Veri kaynağını tanımlayın: İşi birincil Data Hub SQL veritabanına bağlanacak şekilde yapılandırın. Sunucu adını, veritabanı adını ve ilgili şemalara okuma erişimi olan bir kullanıcının kimlik bilgilerini sağlamanız gerekir.
- Çıkarma sorgusunu girin: Dışa aktarma işinin sorgu tanımı bölümüne gidin. Aşağıdaki sorgu bölümündeki tam betiği kopyalayıp sorgu düzenleyicisine yapıştırın.
- Sorgu parametrelerini ayarlayın: Yapılandırmadaki parametre bölümünü bulun. İstenen çıkarma tarih aralığını belirtmek için sorguda kullanılan @StartDate ve @EndDate parametrelerini tanımlayıp değerlerini girin. Örneğin, '2023-01-01' ve '2023-12-31'.
- Çıktı sütunlarını eşleyin: Çıktı dosyası ayarlarını yapılandırın. SELECT ifadesinde tanımlanan sütunların (ClaimId, ActivityName, EventTime vb.) çıktı dosyasındaki sütunlarla doğru eşleştiğinden emin olun. Çıktı dosyasındaki başlık adları bu adlarla tam olarak aynı olmalıdır.
- Çıktı dosyasını yapılandırın: Çıktı biçimini CSV olarak belirtin. ProcessMind ile uyumluluğu sağlamak için ayırıcıyı virgül (,) ve karakter kodlamasını UTF-8 olarak ayarlayın.
- Hedefi tanımlayın: Oluşturulan CSV dosyasının kaydedileceği dosya yolunu veya ağ konumunu belirtin. Sistemin bu konuma yazma izni olduğundan emin olun.
- Dışa aktarma işini zamanlayın: İşin zamanlamasını yapılandırın. İlk analiz için işi manuel olarak çalıştırabilirsiniz. Sürekli izleme için yinelenen bir zamanlama oluşturun, örneğin günlük veya haftalık.
- Dosyayı çalıştırın ve alın: Event Log dosyasını oluşturmak için işi çalıştırın. İş tamamlandığında CSV dosyasını 8. adımda belirttiğiniz hedeften alın.
- Yüklemeye hazırlayın: ProcessMind'e yüklemeden önce son bir kontrol yapmak için CSV dosyasını açın. Başlıkların doğru olduğunu, tarih biçiminin tutarlı olduğunu (YYYY-AA-GG SS:DD:SS) ve verilerin beklenen şekilde göründüğünü doğrulayın.
Yapılandırma
- Ön koşullar: Duck Creek Data Hub modülüne erişim gerekir. Dışa aktarma işini çalıştıran kullanıcı veya hizmet hesabı, Data Hub'ın temel veritabanı tablolarında okuma izinlerine sahip olmalıdır, örneğin [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory].
- Tarih aralığı yapılandırması: Sorgu @StartDate ve @EndDate parametrelerini kullanır. Çıkarma aralığını tanımlamak için bu değerlerin ayarlanması gerekir. İlk analiz için yeterli sayıda tamamlanmış ve devam eden vaka yakalamak amacıyla 6-12 aylık bir dönem önerilir.
- Filtreleme: Sorgu, Common Table Expression (CTE) içinde /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ yer tutucusunu içerir. Belirli iş kollarına göre filtre uygulamak, örneğin 'Personal Auto' veya 'Commercial Property', veri hacmini azaltmak ve analizi odaklamak için bu satırın yorumunu kaldırıp değiştirin.
- Data Hub yenileme döngüsü: Data Hub verilerindeki gecikmeyi dikkate alın. Veriler gerçek zamanlı değildir ve genellikle belirli bir zamanlamaya göre yenilenir, örneğin her gece. Çıkarılan veriler, son başarılı Data Hub yenilemesi kadar güncel olacaktır.
- Çıktı biçimi: Dışa aktarma işi tercihen CSV olmak üzere düz dosya üretecek şekilde yapılandırılmalıdır. Veri alanlarındaki virgülleri işlemek için metin niteleyicinin çift tırnak (") olarak ayarlandığından emin olun.
a Örnek sorgu sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL; Başlamaya hazır mısınız?
Bu Template ile hasar dosyası işleme sürecinizi optimize etmeye başlamak için gereken her şeye sahipsiniz. Veri yolculuğunuza bugün başlayın ve değerli içgörüleri ortaya çıkarın.
Hasar dosyası birikimlerini sona erdirin: Hasar dosyası işleme sürecinizi şimdi optimize edin
Düz akışlı işlemede %70 oranına ulaşarak maliyetleri ve gecikmeleri azaltın.
14 günlük ücretsiz deneme, kredi kartı gerekmez.