Taleplerin işlenmesi için Veri Templateiniz
Taleplerin işlenmesi için Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Duck Creek Claims verilerini çıkarma yönergeleri
Taleplerin işlenmesi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Belirli bir zamanda hasar dosyası için gerçekleşen iş etkinliğinin veya olayın adı. | ||
| Açıklama Bu öznitelik, hasar sürecinde gerçekleştirilen 'Hasar Başvurusu Yapıldı', 'Hasar Uzmanı Atandı' veya 'Ödeme Yapıldı' gibi belirli bir adımı ya da görevi tanımlar. Her etkinlik, hasar dosyasının yaşam döngüsünde ayrı bir noktayı temsil eder. Bu etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining çalışmalarının temelini oluşturur. Süreç modellerini keşfetmenizi, darboğazları belirlemenizi, yeniden çalışma döngülerini tespit etmenizi ve süreç sapmalarını standart bir modelle karşılaştırmanızı sağlar. Neden önemli? Etkinlik adı, süreç akışındaki adımları tanımlar. Hasar sürecini keşfetmek, analiz etmek ve izlemek için temel bir özniteliktir. Nereden alınır? Genellikle Duck Creek Claims içindeki olay günlüklerinden, işlem adlarından veya durum değişikliği kayıtlarından elde edilir. Birden fazla kaynak alanı veya tablosu arasında haritalama yapmak gerekebilir. Örnekler Hasar başvurusu yapıldıHasar uzmanı atandıSoruşturma başladıÖdeme yapıldıHasar dosyası kapatıldı | |||
| Hasar kimliği ClaimId | Tek bir sigorta hasar dosyasını tanımlayan ve birincil vaka kimliği olarak kullanılan benzersiz tanımlayıcı. | ||
| Açıklama Hasar Kimliği, tek bir sigorta hasar dosyasıyla ilişkili tüm olayları ve etkinlikleri başvurudan dosyanın kapanışına kadar birbirine bağlayan temel anahtardır. Böylece hasar dosyasının tüm yaşam döngüsü tutarlı biçimde izlenebilir. Process Mining analizinde bu öznitelik, vaka görünümünü oluşturmak için gereklidir. Analistler her hasar dosyasının tüm sürecini izleyebilir, uçtan uca çevrim sürelerini ölçebilir ve süreç çeşitlerini analiz edebilir. Neden önemli? Süreçteki ilgili tüm olayları birbirine bağlayan temel Vaka kimliğidir. Böylece hasar dosyasının yaşam döngüsünü baştan sona görebilirsiniz. Nereden alınır? Duck Creek Claims içindeki ana hasar varlığında veya tablosunda birincil anahtar olarak kullanılır. Tablo ve alan adını öğrenmek için sistem dokümantasyonuna başvurun. Örnekler CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Olay zamanı EventTime | Belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
| Açıklama Olay zamanı, hasar dosyasının yaşam döngüsünde kaydedilen her etkinliğin tarihini ve saatini tam olarak gösterir. Bu zaman bilgisi, performans analizi için önemlidir. Analizde bu zaman damgası; etkinlikler arasındaki çevrim sürelerini hesaplamak, bekleme sürelerini belirlemek, toplam vaka süresini ölçmek ve süreç performansını farklı dönemlere göre incelemek için kullanılır. Zamana dayalı tüm süreç metriklerinin temelini oluşturur. Neden önemli? Bu zaman damgası, çevrim süreleri ve süre ölçümleri gibi zamana dayalı metrikleri hesaplamak, performansı analiz etmek ve darboğazları belirlemek için gereklidir. Nereden alınır? Duck Creek Claims içindeki olay veya işlem günlüklerinde bulunan 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 hasar uzmanı AssignedAdjuster | Belirli bir etkinlik sırasında hasar dosyasından sorumlu hasar uzmanının 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 süreci boyunca değişebilir. 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 ve iş yükü farklılıklarına odaklanan, darboğazları belirleyen Dashboardlar; işin kişiler arasında nasıl dağıtıldığını ve yürütüldüğünü anlamak için bu özniteliğe sıkça başvurur. Neden önemli? Kaynak performansını, iş yükü dengesini ve iş birliği örüntülerini analiz etmeyi sağlar. Böylece darboğazları ve eğitim ihtiyaçlarını belirlemeye yardımcı olur. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Hasar görevleri, olayları veya ana hasar varlığıyla ilgili tablolarda kullanıcı, sahip ya da atanan kişi alanlarını arayın. Örnekler John SmithJane DoeRobert Brownadjuster_1138 | |||
| Departman Department | Belirli bir zamanda etkinlikten veya hasar dosyasından sorumlu departman ya da ekip. | ||
| Açıklama Bu öznitelik, hasar dosyasını ele alan 'İlk Başvuru', 'Soruşturma Birimi' veya 'Uzlaşma Ekibi' gibi işlevsel grubu ya da departmanı belirtir. Süreç akışına kurumsal bir bağlam kazandırır. Departman bazında analiz, süreç performansını genel düzeyde anlamak için önemlidir. Departmanlar arasındaki darboğazları belirlemeye, ekip verimliliğini ölçmeye ve işin kuruluş genelinde nasıl ilerlediğini anlamaya yardımcı olur. Neden önemli? İşlevsel alanlara göre performans analizi yapmayı sağlar; departmanlar arası devir teslimleri ve ekiplere özgü darboğazları ortaya çıkarır. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Bu bilgi genellikle atanan kullanıcının profiliyle veya bir kuyruk ya da çalışma grubu atamasıyla ilişkilidir. Örnekler Oto hasarlarıBüyük hasarlı konut ve iş yeri hasarlarıÖzel soruşturma birimiÖdeme işlemleri | |||
| Hasar önem derecesi ClaimSeverity | Hasarın mali veya operasyonel karmaşıklığını düşük, orta ya da yüksek gibi sınıflandıran ölçüt. | ||
| Açıklama Hasar önem derecesi, hasarın beklenen etkisi veya karmaşıklığı hakkında bilgi verir. İlk hasar tahminine, olayın niteliğine veya önceden belirlenmiş diğer iş kurallarına göre belirlenebilir. Yüksek önem derecesine sahip hasarlar genellikle daha fazla adım, daha uzun işlem süreleri ve uzman kaynaklar gerektirdiğinden bu öznitelik performans analizi için önemlidir. KPI’ları önem derecesine göre gruplandırmak, gerçekçi performans hedefleri belirlemeye ve karmaşıklığın süreç verimliliğini ve sonuçlarını nasıl etkilediğini anlamaya yardımcı olur. Neden önemli? Hasar dosyalarını karmaşıklıklarına göre gruplandırarak çevrim sürelerini ve maliyetleri daha ayrıntılı analiz etmenizi ve gerçekçi kıyaslamalar yapmanızı sağlar. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Bu, özel bir alan olabilir veya ilk hasar karşılığı tutarından elde edilebilir. Örnekler DüşükOrtaYüksekFelaket düzeyinde | |||
| Hasar türü ClaimType | Oto, konut ve iş yeri ya da sorumluluk gibi sigorta hasarı kategorisi. | ||
| Açıklama Hasar türü, hasar dosyalarını sigorta branşına veya hasarın niteliğine göre sınıflandırır. Hasar verilerini gruplandırıp analiz etmek için temel bir boyuttur. Bu öznitelik, farklı hasar türlerindeki süreç performansını karşılaştırmak için kullanılır. Örneğin, 'Oto - Tam hasar' dosyasının süreci, 'Konut - Su hasarı' dosyasından oldukça farklıdır ve farklı KPI’ları vardır. Hasar türüne göre analiz, bağlam sağlar; performansı daha anlamlı biçimde karşılaştırmanıza ve sürece uygun iyileştirme çalışmaları planlamanıza yardımcı olur. Neden önemli? Analizi gruplandırmak için önemli bir boyuttur. Farklı hasar türlerinin süreçleri, hizmet düzeyi anlaşmaları ve karmaşıklık düzeyleri birbirinden farklı olabilir. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Bu, ana hasar kaydındaki temel bir özniteliktir. Örnekler Bireysel oto - çarpışmaTicari mülk - yangınİşçi tazminatıGenel sorumluluk | |||
| Hasar tutarı LossAmount | Talepte bildirilen hasarın tahmini veya gerçekleşen parasal tutarı. | ||
| Açıklama Bu öznitelik, taleple ilişkili hasarın başlangıçta tahmin edilen değerini gösterir. Talebin yönlendirilmesini, ciddiyetini ve gereken inceleme düzeyini etkileyen önemli bir finansal metriktir. Analizlerde hasar tutarı, talepleri gruplandırmak ve finansal etkinin süreç davranışıyla ilişkisini anlamak için kullanılır. Örneğin, yüksek tutarlı talepler farklı süreç yollarından geçebilir veya daha uzun çevrim sürelerine sahip olabilir. Bu tutar, operasyonel süreç verilerine önemli bir finansal bağlam kazandırır. Neden önemli? Talebe finansal bağlam kazandırır; talep tutarının işlem yolunu, süresini ve sonucunu nasıl etkilediğini analiz etmenizi sağlar. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Bu, talepteki temel finansal alanlardan biridir ve genellikle Bildirilen hasar veya İlk karşılık olarak adlandırılır. Örnekler 1500.0025000.50125000.00 | |||
| Talep durumu ClaimStatus | Talebin belirli bir andaki genel durumu; örneğin Açık, Beklemede veya Kapalı. | ||
| Açıklama Talep durumu, talebin yaşam döngüsündeki mevcut aşamasını gösterir. Talebin genel süreçte nerede olduğuna dair üst düzey bir özet sunar. Bu öznitelik, talep envanterine üst düzeyden bakmak ve vakaları filtrelemek için kullanışlıdır. Özellikle talebin nihai sonucunu (ör. Ödendiği için kapatıldı, Reddedildiği için kapatıldı) belirlemek açısından önemlidir. Bu bilgi, sonuç analizinin ve ret oranlarını anlamanın temelini oluşturur. Neden önemli? Talebin mevcut durumunu ve nihai sonucunu gösterir; sonuç analizi ve vakaları filtrelemek için önemlidir. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Bu, ana talep kaydındaki temel alanlardan biridir. Örnekler AçıkBeklemede - Bilgi bekleniyorKapalı - SonuçlandırıldıKapalı - Reddedildi | |||
| Bitiş zamanı EndTime | Bir etkinliğin tamamlandığını gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, bir etkinliğin tamamlanma zamanını belirtir. StartTime etkinliğin ne zaman başladığını gösterirken EndTime, ilgili görevin süresini hesaplamak için gereken diğer zamanı sağlar. Process Mining çalışmalarında etkinliklerin hem başlangıç hem de bitiş zamanlarının bulunması, performansı daha ayrıntılı analiz etmenizi sağlar. Böylece görevde fiilen çalışılan süre olan İşlem süresi ile görevler arasında geçen Bekleme süresi hassas biçimde hesaplanabilir. Bu ayrım, darboğazları doğru belirlemek için önemlidir. Neden önemli? Etkinliklerin işlem sürelerini hassas biçimde hesaplamanızı, fiilî çalışma süresini boşta veya beklemede geçen süreden ayırmanızı sağlar. Bu ayrım, darboğaz analizinin doğruluğu açısından önemlidir. Nereden alınır? Olay günlüklerinde ayrı bir zaman damgası alanı olarak bulunabilir. Aynı vakadaki sıradaki etkinliğin StartTime değeri kullanılarak da hesaplanabilir. Örnekler 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Çözüm hedef tarihi ResolutionTargetDate | Hizmet düzeyi anlaşmalarına (SLA) veya kurum içi hedeflere göre talebin sonuçlandırılmasının beklendiği hedef tarih. | ||
| Açıklama Bu öznitelik, talebin kapatılması için son tarihi kaydeder. Tarih genellikle mevzuat gerekliliklerine, hizmet düzeyi anlaşmalarına (SLA) veya temel performans göstergelerine (KPI) göre belirlenir ve talep türüne ya da ciddiyetine göre değişebilir. Bu tarih, Zamanında talep çözüm oranı KPI’ını hesaplamanın ve Talep çözüm hedeflerine uyum Dashboardını desteklemenin temelini oluşturur. SLA süresini aşma riski taşıyan talepleri önceden izlemenizi ve işleri önceliklendirmenizi sağlar. Neden önemli? Hizmet düzeyi anlaşmalarına (SLA) ve kurum içi hedeflere göre performansı ölçmenizi sağlar. Bu ölçüm, müşteri memnuniyetini ve uyumluluğu doğrudan etkiler. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Bu alan, özel bir SLA tarih alanı olabilir veya talebin başvuru tarihiyle 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ı belirtir. Bu kullanımda değer her zaman 'Duck Creek Claims' olur. Tüm veriler tek bir sistemden geldiğinde gereksiz görünebilir. Ancak veri yönetişimi ve izlenebilirlik açısından, ayrıca ileride birden fazla sistemden veri birleştirilmesi durumunda önem taşır. Verilerin kaynağı ve yapısı hakkında bağlam sağlar. Neden önemli? Veri kökenini ve bağlamını gösterir. Veri yönetişimi ve sorun giderme açısından, özellikle birden fazla sistemin entegre edildiği ortamlarda önemlidir. Nereden alınır? Genellikle veri çıkarma ve dönüştürme sırasında eklenen, verinin kaynağını belirten sabit bir değerdir. Örnekler Duck Creek Claims | |||
| Otomatik mi IsAutomated | Etkinliğin insan müdahalesi olmadan sistem tarafından otomatik olarak gerçekleştirilip gerçekleştirilmediğini belirten boole bayrağı. | ||
| Açıklama Bu bayrak, insan kullanıcıların tamamladığı görevlerle otomatik bildirimler, ilk veri doğrulaması veya uçtan uca otomatik işleme adımları gibi sistem otomasyonuyla yürütülenleri birbirinden ayırır. Bu özniteliği analiz etmek, talepler sürecindeki otomasyon düzeyini anlamanın temelidir. Otomasyon çalışmalarının etkisini ölçmeye, daha fazla otomasyon fırsatını belirlemeye ve sonraki adımlarda sorun yaratmadan otomatik adımların beklendiği gibi çalıştığını doğrulamaya yardımcı olur. Neden önemli? Otomasyonun verimlilik ve maliyet üzerindeki etkisini ölçmeye, uçtan uca otomatik işleme fırsatlarını belirlemeye yardımcı olur. Nereden alınır? Bu bilgi, bir olayla ilişkilendirilen kullanıcıdan (ör. SYSTEM veya BATCH) çıkarılabilir ya da olay kaydındaki özel bir bayraktan alınabilir. Örnekler truefalse | |||
| Poliçe numarası PolicyNumber | Talebin açıldığı sigorta poliçesinin benzersiz tanımlayıcısı. | ||
| Açıklama Bu öznitelik, talebi ilgili sigorta poliçesine bağlar. Taleple ilişkili teminat, koşullar ve müşteri hakkında bağlam sunar. Poliçe numarası süreç akışı analizinde her zaman doğrudan kullanılmasa da talep 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 işin bütünü daha iyi anlaşılır. Neden önemli? Talebi müşteri ve poliçeyle ilişkilendirir. Süreç performansının farklı müşteri segmentlerini veya poliçe türlerini nasıl etkilediğini daha geniş kapsamda analiz etmenizi sağlar. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Bu, ana talep varlığında bulunan standart bir referans alanıdır. Örnekler PA-987654321CP-123456789WC-555444333 | |||
| Ret nedeni RejectionReason | Bir talebin reddedilmesinin veya kabul edilmemesinin özel nedeni. | ||
| Açıklama Talebin reddedilmesine karar verildiğinde bu öznitelik, kararın altında yatan nedeni belirtir. Genellikle önceden tanımlanmış kodlar veya açıklamalar arasından seçilir. Ret nedenlerini analiz etmek, Talep kararı ve ret içgörüleri Dashboardı için önemlidir. Başvurulardaki yaygın sorunları, olası dolandırıcılık örüntülerini veya poliçe dilinin net olmadığı alanları belirlemeye yardımcı olur. Bu içgörüler, başvuru kabul sürecini veya risk değerlendirme kurallarını iyileştirmek için kullanılabilir. Neden önemli? Taleplerin neden reddedildiğini açıklar. Başvuru kabul sürecini iyileştirmek, geçersiz başvuruları azaltmak ve eğitim fırsatlarını belirlemek için uygulanabilir içgörüler sunar. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Bu alan genellikle talebin durumu Reddedildi veya benzer bir duruma getirildiğinde doldurulur. Örnekler Teminat kapsamı dışındaPoliçe süresi dolmuşMükerrer talepDolandırıcılık şüphesi | |||
| Son veri güncellemesi LastDataUpdate | Kaynak sistemden alınan en son veri yenilemesinin zaman damgası. | ||
| Açıklama Bu öznitelik, veri setinin en son ne zaman güncellendiğini gösterir. Analiz edilen verilerin ne kadar güncel olduğunu anlamanıza yardımcı olur. Dashboardlarda ve analizlerde, içgörülerin ne kadar yeni olduğunu kullanıcılara bildirmek için kullanılır. En son işlemlerin süreç görünümüne dahil edilip edilmediğine ilişkin beklentileri yönetmeye yardımcı olur. Neden önemli? Verilerin güncelliğini kullanıcılara bildirir. Bu bilgi, analizi doğru yorumlamak ve zamanında karar vermek için önemlidir. Nereden alınır? Bu zaman damgası, veri çıkarma, dönüştürme ve yükleme (ETL) işlemi sırasında oluşturulur ve genellikle veri setinin meta verilerinde saklanır. Örnekler 2024-05-21T02:00:00Z | |||
| Uzlaşma tutarı SettlementAmount | Talebi sonuçlandırmak için üzerinde anlaşılan nihai parasal tutar. | ||
| Açıklama Bu öznitelik, hesaplanan ve ödeme için onaylanan uzlaşma tutarını kaydeder. Ödeme yapılan her talep için sonuç odaklı önemli bir metriktir. Bu öznitelik, finansal analiz ve Ödeme onayı ve ödeme süresi gibi Dashboardlar için önemlidir. Karşılık doğruluğunu analiz etmek için başlangıçtaki Hasar tutarıyla karşılaştırılabilir ve talepler sürecinin finansal sonuçlarını anlamanın temelini oluşturur. Neden önemli? Talebin temel finansal sonucunu gösterir; finansal raporlama ve ilk hasar tahminlerinin doğruluğunu analiz etmek için gereklidir. Nereden alınır? Duck Creek Claims dokümantasyonuna başvurun. Bu bilgi genellikle taleple ilişkili finansal işlem veya ödeme tablolarında saklanır. Örnekler 1450.7522000.00115800.20 | |||
| Yeniden çalışma mı IsRework | Bir etkinliğin yeniden çalışma döngüsünün parçası olup olmadığını belirten hesaplanmış bir bayrak. | ||
| Açıklama Bu boole öznitelik, başka ve farklı etkinlikler gerçekleştikten sonra bir talep için aynı etkinlik tekrarlandığında true olarak ayarlanır. Örneğin süreç, Hasar değerlendirildi adımından İnceleme başlatıldı adımına geri dönerse. Bu öznitelik, yeniden çalışmayı ölçmek ve analiz etmek için gereklidir. Yeniden çalışma içeren etkinlikleri ve vakaları doğrudan filtreleyip öne çıkararak Talepte yeniden çalışma oranı KPI’ını ve Talepte yeniden çalışma ve yeniden işleme örüntüleri Dashboardını destekler. Böylece süreçteki verimsizlikleri ve kalite sorunlarını belirlemenize yardımcı olur. Neden önemli? Yeniden çalışmayı etkinlik 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 etkinlik dizilerini tespit eden algoritmalarla veri hazırlığı sırasında hesaplanır. Örnekler truefalse | |||
| Zamanında mı sonuçlandı IsOnTimeResolution | Talebin çözüm hedef tarihinde veya öncesinde kapatılıp kapatılmadığını belirten hesaplanmış bir bayrak. | ||
| Açıklama Bu boole öznitelik, Talep kapatıldı etkinliğinin zaman damgası ile ilgili talebin ResolutionTargetDate değeri karşılaştırılarak hesaplanır. Her talebi zamanında (true) veya geç (false) olarak işaretler. Bu öznitelik, Zamanında talep çözüm oranı KPI’ını doğrudan destekler. Dashboardlarda SLA hedeflerine uyumu kolayca toplulaştırıp görselleştirmenizi ve geç sonuçlanan taleplerin ortak özelliklerini (ör. belirli talep türleri, departmanlar veya süreç yolları) ayrıntılı incelemenizi sağlar. Neden önemli? Her talep için SLA uyumluluğunu doğrudan ölçer; süresi aşılmış talepleri filtrelemenizi ve temel nedenlerini analiz etmenizi sağlar. Nereden alınır? Bu, kaynak sistemde bulunan bir alan değildir. Veri hazırlığı sırasında son etkinliğin zaman damgası ResolutionTargetDate alanıyla karşılaştırılarak hesaplanır. Örnekler truefalse | |||
Taleplerin işlenmesi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Hasar başvurusu yapıldı | Bu, sigortacıya İlk Hasar Bildiriminin (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 sürecinin başlangıcını gösterir. Toplam işlem süresini ve başvuru aşamasının verimliliğini anlamak için bu olaydan sonraki olaylara kadar geçen süreyi analiz etmek önemlidir. Nereden alınır? Duck Creek Claims içinde yeni bir hasar kaydı ilk kez oluşturulduğunda, bu olay genellikle hasar veya FNOL günlük tablosuna açıkça kaydedilir. Kaydedin Yeni bir hasar kaydı oluşturulduğunda kaydedilen olay. Olay türü explicit | |||
| Hasar dosyası kapatıldı | Bu, son etkinliktir. Ödeme yapıldıktan veya hasar dosyası uzlaşmayla sonuçlandıktan sonra dosyanın idari olarak kapatıldığını gösterir. Nihai durumun 'Kapalı' olarak güncellenmesiyle kaydedilir. | ||
| Neden önemli? Sürecin başarıyla tamamlandığını gösterir. 'Ortalama uçtan uca hasar çevrim süresi' ve diğer önemli süre metriklerini hesaplamak için bitiş noktasıdır. Nereden alınır? Hasarın ana veri tablosunda nihai durumun 'Kapalı' veya 'Uzlaşmayla Sonuçlandı' olarak değiştiği zaman damgasından çıkarılır. Kaydedin Hasarın nihai durumunun 'Kapalı' olarak belirlenmesinden çıkarılır. Olay türü inferred | |||
| Hasar kararı verildi | Hasar dosyası hakkında 'Onaylandı', 'Kısmen Onaylandı' veya 'Reddedildi' gibi resmî kararı gösterir. Nihai karar durumuna geçişten çıkarılan önemli bir dönüm noktasıdır. | ||
| Neden önemli? Karar sürecinin önemli bir dönüm noktasıdır. Bu aşamaya kadar geçen süre ve kararın sonucu, süreç analizi ve verimlilik açısından belirleyicidir. Nereden alınır? Özel 'Hasar Kararı' veya 'Hasar Durumu' alanının 'Onaylandı' ya da 'Reddedildi' gibi nihai bir duruma geçmesinden çıkarılır. Bu değişikliğin zaman damgası kaydedilir. Kaydedin Hasarın birincil durum veya karar alanındaki güncellemeden çıkarılır. Olay türü inferred | |||
| Hasar talebi reddedildi | Hasar talebinin resmen reddedilmesiyle sürecin alternatif bir sona ulaştığını gösterir. Hasarın nihai durumu 'Reddedildi' veya 'Kabul Edilmedi' olarak belirlendiğinde kaydedilir. | ||
| Neden önemli? Ayrı olarak analiz edilmesi gereken önemli bir sonuçtur. Hasar taleplerinin neden ve ne zaman reddedildiğini anlamak, başvuru süreçlerini iyileştirmeye ve uyumluluğu yönetmeye yardımcı olur. Nereden alınır? Hasar kaydı tablosunda hasarın nihai durumu 'Reddedildi', 'Kabul Edilmedi' veya 'Ödeme Yapılmadan Kapatıldı' olarak değiştiğinde oluşan zaman damgasından çıkarılır. Kaydedin Hasarın nihai durumunun ret nedeni olarak belirlenmesinden çıkarılır. Olay türü inferred | |||
| Ödeme yapıldı | Bu etkinlik, hasar ödemesine ilişkin mali işlemin gerçekleştirilmesini gösterir. Çek, EFT veya başka bir yöntemle ödeme gönderildiğinde oluşan açık bir olaydır. | ||
| Neden önemli? Onaylanan hasar dosyasına ilişkin mali yükümlülüğün yerine getirildiğini gösterir. 'Ödeme Yetkilendirildi' ile 'Ödeme Yapıldı' arasındaki süre, finans ekibinin verimliliğini ortaya koyar. Nereden alınır? Duck Creek Claims içindeki mali işlem tablosundan alınır. Bu tabloda giden tüm ödemeler, belirli bir işlem kodu ve zaman damgasıyla kaydedilir. Kaydedin Ödeme işlendiğinde mali işlem günlüğüne ayrı bir kayıt eklenir. Olay türü explicit | |||
| Ödeme yetkilendirildi | Hesaplanan uzlaşma tutarının ödenmesi için resmî onay verildiğini gösterir. Genellikle bir yöneticinin veya ayrı bir yetkilinin katıldığı, açık bir onay işlemi olarak kaydedilen ayrı bir adımdır. | ||
| Neden önemli? Ödeme öncesindeki önemli bir kontrol noktası ve olası bir darboğazdır. 'Hasar Kararı Verildi' aşamasından bu noktaya kadar geçen süre, 'Ortalama Hasar Onay Süresi' KPI’ı ile ölçülür. Nereden alınır? Genellikle bir Workflow veya mali modülde, belirli izinlere sahip bir kullanıcının ödemeyi onayladığı açık bir olaydır. Onay günlüğünde bulunabilir. Kaydedin Bir Workflow veya işlem günlüğüne kaydedilen açık onay olayı. Olay türü explicit | |||
| Ek bilgi alındı | İstenen bilginin alındığını ve hasar işlemlerinin devam edebileceğini gösterir. Hasar uzmanı bu bilgiyi elle kaydedebilir veya bilgi dijital portal üzerinden gönderildiğinde sistem otomatik olarak kaydedebilir. | ||
| Neden önemli? 'Bilgi İstendi' ile 'Bilgi Alındı' arasındaki süre önemli bir bekleme dönemidir. Bu süreyi analiz etmek, dış taraflara bağlı gecikmeleri 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. Belgeler ulaştığında hasar uzmanının elle girdiği bir kayıt veya durum değişikliği de olabilir. Kaydedin Belge yüklendiğinde veya hasar uzmanı elle kayıt girdiğinde kaydedilen olay. Olay türü explicit | |||
| Ek bilgi istendi | Hasar uzmanı ek bilgi gerektiğine karar verip poliçe sahibine veya üçüncü bir tarafa talep gönderdiğinde bu etkinlik gerçekleşir. Genellikle sistemin iletişim veya yazışma modülüyle bağlantılı açık bir olay olarak kaydedilir. | ||
| 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üresine yol açarak genel çevrim süresini uzatır. Nereden alınır? Giden iletişim kayıtlarından (ör. mektup veya e-posta) ya da Duck Creek Claims içindeki özel bir 'Bilgi Talebi' işleminden alınır. Kaydedin Bilgi talebi için bir yazışma veya görev oluşturulduğunda kaydedilir. Olay türü explicit | |||
| Hasar kaydı oluşturuldu | Bu adım, başvurunun resmen kabul edilip kaydedildiğini ve benzersiz bir Hasar Kimliği atandığını gösterir. İlk veri doğrulamasının ardından sistem tarafından otomatik olarak oluşturulabilir. | ||
| Neden önemli? Hasar sürecini resmen başlatır ve hasar uzmanı ataması gibi sonraki süreçleri tetikler. Başvuru ile kayıt arasındaki süre, ilk veri kalitesi veya sistem yüküyle ilgili sorunlara işaret edebilir. Nereden alınır? Ana hasar tablosunda birincil Hasar Kimliğinin oluşturulduğu zaman damgasından ve hasar durumunun 'beklemede' veya 'başvuruldu' durumundan 'açık' ya da 'kaydedildi' durumuna geçmesinden çıkarılır. Kaydedin Birincil hasar kaydının oluşturulma zaman damgasından veya durumun 'Açık' olarak değişmesinden elde edilir. Olay türü inferred | |||
| Hasar tutarı belirlendi | Bu aşamada, soruşturma bulgularına göre mali karşılıklar belirlenir veya güncellenir. Hasarın mali etkisinin tahmin edildiğini gösterir ve karşılık tutarları girildiğinde ya da değiştirildiğinde kaydedilir. | ||
| Neden önemli? Süreçteki önemli bir mali kontrol noktasıdır. Ne zaman gerçekleştiğini analiz etmek, mali değerlendirmenin hızı ve doğruluğu hakkında bilgi verir. Nereden alınır? Genellikle Duck Creek Claims içindeki hasar mali işlem günlüğüne veya karşılık geçmişi tablosuna kaydedilen açık bir mali işlemdir. Kaydedin Hasar karşılıklarını belirlemek veya güncellemek için kaydedilen mali işlem. Olay türü explicit | |||
| Hasar uzmanı atandı | Bu olay, kayıtlı hasar dosyasına bir hasar uzmanı veya dosya sorumlusu atanmasını gösterir. Sistem bu atamayı kaydederek net bir devir teslim noktası oluşturur ve hasar dosyasının takibinden kimin sorumlu olduğunu belirler. | ||
| Neden önemli? Kaynak dağılımını ve hasar uzmanlarının iş yükünü analiz etmek, ayrıca dosya atamalarındaki gecikmeleri belirlemek için önemlidir. Bekleme süresine yol açabilecek önemli bir devir teslim noktasıdır. Nereden alınır? Ana hasar veri tablosundaki 'Atanan Hasar Uzmanı' alanının güncellenmesiyle izlenir. Bu alanın geçmişi veya denetim günlüğü zaman damgasını sağlar. Kaydedin Hasar uzmanı alanı doldurulduğunda veya değiştirildiğinde denetim izine kaydedilir. Olay türü explicit | |||
| İlk inceleme tamamlandı | Atanan hasar uzmanının hasar dosyasını ilk kez kapsamlı biçimde incelemesinin tamamlandığını gösterir. Genellikle atamanın ardından hasar durumu 'Atandı' durumundan 'İnceleniyor' veya 'Soruşturma' durumuna geçtiğinde çıkarılır. | ||
| Neden önemli? Bu aşama, hasar uzmanının ilk işlemi yapmasına kadar geçen süreyi ölçmeye yardımcı olur ve iş yükündeki olası birikmelere işaret edebilir. Süreçteki ilk önemli insan müdahalesi noktasıdır. Nereden alınır? Hasar durumu alanındaki değişiklikten, örneğin durumun 'İlk İnceleme Tamamlandı' veya 'Bilgi Bekleniyor' olarak güncellenmesinden çıkarılır. Bu durum değişikliğinin zaman damgası kullanılır. Kaydedin Hasar uzmanı atandıktan sonra hasar durumu alanındaki değişiklikten çıkarılır. Olay türü inferred | |||
| Soruşturma başladı | Bu etkinlik, hasar dosyasının resmî soruşturma aşamasının başladığını gösterir. Genellikle hasar durumunun 'Soruşturma Altında' veya benzer bir duruma geçmesinden çıkarılır. | ||
| Neden önemli? Kaynak gerektiren bir aşamanın başlangıcını gösterir. Soruşturma süresini ölçmek, 'Ortalama Soruşturma Süresi' 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 durumun 'Soruşturma Sürüyor' veya 'İnceleme Bekleniyor' olarak güncellendiği zaman damgasından çıkarılır. Kaydedin Soruşturma faaliyetlerinin başladığını gösteren hasar durumu değişikliğinden elde edilir. Olay türü inferred | |||
| Soruşturma tamamlandı | Gerekli tüm bilgilerin toplandığı soruşturma faaliyetlerinin sona erdiğini gösterir. Genellikle hasar durumu 'Soruşturma Altında' durumundan 'Karar Bekleniyor' gibi bir karar aşamasına geçtiğinde çıkarılır. | ||
| Neden önemli? Soruşturmanın tamamlanması, karar ve uzlaşma aşamalarının önünü açan önemli bir dönüm noktasıdır. Bu aşamadaki gecikmeler sonraki adımları da önemli ölçüde etkiler. Nereden alınır? Hasar durumunun 'soruşturma' aşamasından 'inceleme' veya 'karar' aşamasına geçtiği zaman damgasından çıkarılır. Kaydedin Soruşturma faaliyetlerinin sona erdiğini gösteren hasar durumu değişikliğinden elde edilir. Olay türü inferred | |||
| Uzlaşma tutarı hesaplandı | Onay kararının ardından bu etkinlik, nihai uzlaşma veya ödeme tutarının hesaplanmasını gösterir. Sistemdeki mali modülde açık bir adım olarak kaydedilebilir veya ödeme tutarlarının kesinleştirilmesinden çıkarılabilir. | ||
| Neden önemli? Bu etkinlik, 'Uzlaşma Yeniden Çalışma Oranı' KPI’ını ölçmek için önemlidir. Tek bir hasar dosyasında bu olayın birden fazla kez gerçekleşmesi, uzlaşma aşamasındaki verimsizliklere, hatalara veya müzakerelere işaret eder. Nereden alınır? Açık bir işlem günlüğü kaydı olabilir veya hasarın mali verilerindeki 'Uzlaşma Tutarı' alanının güncellenmesinden çıkarılabilir. Bu alanın denetim günlükleri başlıca veri kaynağıdır. Kaydedin Nihai ödeme tutarı hesaplanıp kaydedildiğinde oluşturulan 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 sürecini 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 girmeniz gerekir.
- Veri çıkarma sorgusunu girin: Dışa aktarma işinin sorgu tanımı bölümüne gidin. Aşağıdaki sorgu bölümündeki betiğin tamamını kopyalayıp sorgu düzenleyicisine yapıştırın.
- Sorgu parametrelerini ayarlayın: Yapılandırmadaki parametreler bölümünü bulun. İstenen veri çıkarma tarih aralığını belirlemek için sorguda kullanılan @StartDate ve @EndDate parametrelerine değer atayın. Ö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ıklar bu adlarla birebir aynı olmalıdır.
- Çıktı dosyasını yapılandırın: Çıktı biçimini CSV olarak belirleyin. ProcessMind ile uyumluluk için ayırıcı olarak virgül (,) ve karakter kodlaması olarak UTF-8 seçin.
- Hedef konumu belirleyin: 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 elle çalıştırabilirsiniz. Sürekli izleme için yinelenen bir zamanlama oluşturun (ör. günlük veya haftalık).
- İşi çalıştırıp dosyayı alın: Olay günlüğü dosyasını oluşturmak için işi çalıştırın. İşlem tamamlandığında CSV dosyasını 8. adımda belirttiğiniz konumdan alın.
- Yükleme için hazırlayın: ProcessMind’e yüklemeden önce son bir kontrol için CSV dosyasını açın. Başlıkların doğru olduğunu, tarih biçiminin tutarlı olduğunu (YYYY-MM-DD HH:MI:SS) ve verilerin beklendiği gibi göründüğünü doğrulayın.
Yapılandırma
- Ön koşullar: Duck Creek Data Hub modülüne erişiminiz olmalıdır. Dışa aktarma işini çalıştıran kullanıcı veya hizmet hesabı, Data Hub’ın temelindeki veritabanı tablolarını (ör. [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory]) okuma iznine sahip olmalıdır.
- Tarih aralığını yapılandırma: Sorguda @StartDate ve @EndDate parametreleri kullanılır. Veri çıkarma aralığını belirlemek için bu parametrelere değer atamanız gerekir. İlk analizde, tamamlanmış ve devam eden yeterli sayıda vakayı kapsamak için 6-12 aylık bir dönem önerilir.
- Filtreleme: Sorgudaki Common Table Expression (CTE) içinde /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ yer tutucusu bulunur. Belirli iş kollarına göre filtreleme yapmak (ör. 'Personal Auto', 'Commercial Property'), veri hacmini azaltmak ve analizi belirli bir alana odaklamak için bu satırın yorumunu kaldırıp düzenleyin.
- Data Hub yenileme sıklığı: Data Hub verilerindeki gecikmeyi göz önünde bulundurun. Veriler gerçek zamanlı değildir ve genellikle belirli bir zamanlamaya göre (ör. her gece) yenilenir. Çıkarılan veriler, Data Hub’daki son başarılı yenileme kadar güncel olur.
- Çıktı biçimi: Dışa aktarma işi, tercihen CSV biçiminde düz bir dosya oluşturacak şekilde yapılandırılmalıdır. Veri alanlarındaki virgüllerin sorun yaratmaması için metin niteleyicisinin çift tırnak (") olarak ayarlandığından emin olun.
Ö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, taleplerin işlenmesini iyileştirmeye başlamak için gereken her şeyi sunar. Veri yolculuğunuza bugün başlayın ve değerli içgörüleri ortaya çıkarın.
Hasar dosyası birikimini azaltın: Hasar dosyası işleme sürecinizi şimdi optimize edin
Maliyetleri ve gecikmeleri azaltarak işlemlerin %70’ini otomatik müdahale olmadan tamamlayın.
14 günlük ücretsiz deneme, kredi kartı gerekmez.