KYC müşteri işe alımı Veri Templateiniz
KYC müşteri işe alımı Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel faaliyetler
- Veri çıkarma yönlendirmesi
KYC Müşteri Kabulü Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Başlangıç zamanı EventStartTime | Bir faaliyetin veya olayın resmî olarak ne zaman başladığını gösteren zaman damgasıdır. | ||
| Açıklama Bu öznitelik, belirli bir etkinliğin başladığı kesin tarih ve saati kaydeder. Süreç akışını yeniden oluşturmak için gereken kronolojik sırayı sağlar ve zamana dayalı tüm analizler için gereklidir. Process Mining içinde başlangıç zamanı, etkinliklerin süresini, etkinlikler arasındaki bekleme süresini ve vakanın genel çevrim süresini hesaplamak için kullanılır. Event Logun zamansal temelini oluşturur ve performans ile darboğaz analizi açısından büyük önem taşır. Neden önemli? Olayları kronolojik olarak sıralamak ve döngü süreleri ile süreler gibi zamana dayalı tüm metrikleri hesaplamak için gereklidir. Nereden alınır? Fenergo'nun denetim izi, Event Log veya Workflow geçmişi tablolarında bulunur. Genellikle 'Timestamp', 'StartDate' veya 'CreationDate' olarak adlandırılır. Örnekler 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Faaliyet adı ActivityName | Onboarding sürecinde belirli bir zamanda gerçekleşen iş olayının veya görevin adıdır. | ||
| Açıklama Faaliyet Adı, 'Initial Screening Performed' veya 'Application Approved' gibi müşteri onboarding yolculuğundaki tek bir adımı ya da kilometre taşını tanımlar. Bu faaliyetler dizisi, süreç haritasının temelini oluşturur. Bu özniteliği analiz etmek, süreç akışını görselleştirmeyi, yaygın ve alternatif yolları belirlemeyi ve her adımın sıklığını ölçmeyi sağlar. Hangi işlemlerin hangi sırayla gerçekleştirildiğini anlamak için önemlidir. Neden önemli? Bu öznitelik, süreçteki adımları tanımlar ve süreç haritası oluşturmanın yanı sıra süreç akışını ve farklılıklarını analiz etmeyi sağlar. Nereden alınır? Bu bilgi genellikle Fenergo'nun Workflow veya denetim günlüğü tablolarında, vaka durumu geçişleri ya da görev tamamlamalarıyla ilişkili olarak bulunur. Örnekler Veri ve belgeler talep edildiUyumluluk incelemesi başlatıldıBaşvuru onaylandı | |||
| Müşteri başvurusu CustomerApplication | Tek bir müşterinin onboarding yolculuğuna ilişkin benzersiz tanımlayıcıdır ve birincil vaka tanımlayıcısı olarak kullanılır. | ||
| Açıklama Müşteri Başvurusu, tek bir müşterinin KYC onboarding sürecine ilişkin tüm faaliyetleri ve olayları gruplandıran merkezi tanımlayıcıdır. Başvurunun ilk gönderimden nihai sonuca kadar, onaylanmış, reddedilmiş veya kapatılmış olmasına bakılmaksızın uçtan uca takip edilmesini sağlar. Process Mining'de bu öznitelik, her başvurunun eksiksiz yolculuğunu yeniden oluşturmak için temel niteliktedir. Başvuru bazında süreç akışlarını, döngü sürelerini, farklılıkları ve darboğazları analiz etmeyi mümkün kılarak münferit vakaların nasıl ele alındığını net biçimde gösterir. Neden önemli? İlgili tüm olayları birbirine bağlayan temel Case ID'dir ve uçtan uca müşteri onboarding sürecinin analiz edilmesini sağlar. Nereden alınır? Bu, genellikle Fenergo'nun temel vaka yönetimi veya müşteri yaşam döngüsü yönetimi varlığındaki birincil anahtardır. Örnekler APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Kaynak sistem SourceSystem | Verilerin çıkarıldığı kayıt sistemidir. | ||
| Açıklama Bu öznitelik, olay verilerinin kaynaklandığı sistemi tanımlar. Bu süreçte değer sürekli olarak Fenergo olur, ancak birleştirilmiş veri setlerinde veri kaynaklarını ayırt etmeye yardımcı olur. Analizdeki temel kullanım amacı, belirli sistemlerden gelen verileri filtrelemek veya verilerin kaynağını doğrulamaktır. Bütünsel bir süreç görünümü oluşturmak için birden fazla sistemden gelen verilerin birleştirilebildiği ortamlarda netlik sağlar. Neden önemli? Verilerin kaynağını tanımlar. Bu bilgi, veri yönetişimi ve doğrulama için ve analizin doğru kaynağa dayanmasını sağlamak açısından önemlidir. Nereden alınır? Bu, genellikle kayıtların kaynağını belirtmek için veri çıkarma sürecinde eklenen statik bir değerdir. Örnekler FenergoFenergo CLM | |||
| Son veri güncellemesi LastDataUpdate | Bu sürece ilişkin verilerin en son yenilendiğini veya çıkarıldığını gösteren zaman damgasıdır. | ||
| Açıklama Bu öznitelik, en son veri yenilemesinin tarih ve saatini kaydeder. Analiz edilen verilerin güncelliği hakkında bağlam sağlar ve içgörülerin ne kadar güncel olduğunu anlamak açısından önemlidir. Dashboardlarda ve raporlarda bu bilgi, verilerin güncelliği hakkında kullanıcıları bilgilendirmek için kullanılır. Analizin gerçek zamanlı operasyonları mı yoksa geçmişe ait bir anlık görüntüyü mü yansıttığına ilişkin beklentilerin yönetilmesine yardımcı olur. Neden önemli? Verilerin güncelliği hakkında önemli bağlam sağlar ve kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasına yardımcı olur. Nereden alınır? Bu değer, veri çıkarma ve yükleme (ETL) sürecinde veri setine oluşturulup eklenir. Örnekler 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Başlatan kullanıcı InitiatingUser | Faaliyeti gerçekleştiren kişinin kullanıcı kimliği veya adıdır. | ||
| Açıklama Bu öznitelik, belirli bir görevi veya olayı gerçekleştirmekten sorumlu çalışanı ya da sistem kullanıcısını tanımlar. Benzersiz bir kullanıcı kimliği, ad veya rol olabilir. Kullanıcı bazında analiz yapmak iş yükü dağılımını ve bireysel performansı anlamaya, ayrıca eğitim ihtiyaçlarını belirlemeye yardımcı olur. 'Staff Activity Distribution' Dashboardu ve belirli kişilerin veya ekiplerin gerçekleştirdiği etkinliklerin ayrıntısına inmek için önemlidir. Neden önemli? Bir işlemi hangi kullanıcının gerçekleştirdiğini takip eder ve iş yükü dağılımı, ekip performansı ile kaynak tahsisini analiz etmeyi sağlar. Nereden alınır? Bu bilgi genellikle Fenergo'nun denetim günlüklerinde veya görev geçmişi tablolarında olay ayrıntılarıyla birlikte saklanır. Çoğu zaman 'UserID', 'UserName' veya 'ModifiedBy' olarak adlandırılır. Örnekler j.doea.smithSYSTEM | |||
| Başvuru durumu ApplicationStatus | Müşteri başvurusunun mevcut veya nihai sonucudur. | ||
| Açıklama Bu öznitelik, sürecin sonundaki başvuru sonucunu veya süreç devam ediyorsa mevcut durumunu gösterir. Yaygın değerler arasında 'Approved', 'Rejected' ve 'In Progress' bulunur. Bu, sonuç analizi için önemli bir boyuttur. Süreç akışlarını nihai sonuçlarına göre filtreleyip karşılaştırmanızı sağlar. 'Application Rework and Rejection' Dashboardu ve Application Rejection Rate gibi temel performans göstergelerini hesaplamak için gereklidir. Neden önemli? Vakanın sonucunu tanımlar ve onaylanan başvurularla reddedilen başvuruların yollarını karşılaştırarak başarı oranlarını anlamaya yönelik ayrıntılı analiz sağlar. Nereden alınır? Bu, genellikle Fenergo'nun vaka yönetimi sistemindeki vaka varlığına kaydedilen son durumdur. Örnekler OnaylandıReddedildiUyumluluk BekleniyorKapatıldı | |||
| Bitiş zamanı EventEndTime | Bir faaliyetin veya olayın ne zaman tamamlandığını gösteren zaman damgasıdır. | ||
| Açıklama Bu öznitelik, belirli bir faaliyetin tamamlandığı kesin tarih ve saati kaydeder. Bir görevin aktif süresini belirlemek için başlangıç zamanını tamamlar. Process Mining'de bitiş zamanı, her faaliyetin işlem süresini hesaplamak için başlangıç zamanıyla birlikte kullanılır. Süreçte hangi adımların en fazla zaman aldığını belirlemek ve kaynak verimliliğini analiz etmek için gereklidir. Neden önemli? Faaliyet işlem sürelerinin hesaplanmasını sağlar. Bu, uzun süren görevleri ve performans darboğazlarını belirlemek için temel niteliktedir. Nereden alınır? Fenergo'nun denetim izi veya Workflow geçmişi tablolarında bulunur. Genellikle 'EndDate' ya da 'CompletionDate' olarak adlandırılır veya sonraki olayın başlangıç zamanından türetilir. Örnekler 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Kullanıcı departmanı UserDepartment | Başlatan kullanıcının bağlı olduğu departman veya iş birimidir. | ||
| Açıklama Bu öznitelik, 'Compliance', 'Onboarding Operations' veya 'Sales' gibi bir etkinliği gerçekleştiren kullanıcının kurumsal bağlamını sağlar. Genellikle kullanıcı profili bilgilerinden elde edilir. Bu boyut, farklı departmanlar arasındaki süreç devir teslimlerini analiz etmek ve departmanlar arası darboğazları belirlemek için önemlidir. Çalışmaların ekip veya departman düzeyinde toplanmasına izin vererek 'Staff Activity Distribution' Dashboardunu doğrudan destekler. Neden önemli? Süreç performansının departman bazında analiz edilmesini sağlar ve departmanlar arası devirleri, gecikmeleri ve iş yükü dağılımını görünür kılar. Nereden alınır? Bu bilgi, 'InitiatingUser' kimliği kullanılarak ayrı bir kullanıcı veya İK ana veri tablosundan birleştirilebilir. Fenergo bu bilgiyi kullanıcı profilinin bir parçası olarak da saklayabilir. Örnekler ComplianceMüşteri KabulüKalite Güvencesi | |||
| Risk puanı RiskScore | Müşterinin hesaplanan risk düzeyini gösteren sayısal puandır. | ||
| Açıklama Risk Score, müşterinin taşıdığı potansiyel riskin nicel ölçüsüdür. Yargı alanı, sektör ve tarama sonuçları gibi çeşitli faktörlere göre hesaplanır. Fenergo kural motoru bu skoru genellikle kendisi hesaplar. Bu öznitelik, risk düzeyleri ile süreç davranışı arasındaki ilişkiyi analiz etmenizi sağlar. Örneğin analiz, yüksek riskli müşterilerin daha uzun çevrim sürelerine sahip olup olmadığını veya daha fazla manuel müdahale gerektirip gerektirmediğini gösterebilir. Bu bilgi 'Risk & Compliance Review Deep Dive' Dashboardu için yararlıdır. Neden önemli? Müşteri riskini sayısallaştırır ve risk düzeylerinin süreç süresini, yeniden işlemeyi ve sonuçları nasıl etkilediğini analiz etmeyi sağlar. Nereden alınır? Bu, Fenergo'nun Müşteri Risk Değerlendirmesi modülünün temel çıktılarından biridir. Vaka veya müşteri varlığında saklanır. Örnekler 154585 | |||
| SLA hedef tarihi SlaTargetDate | Müşteri onboarding vakasının tamamlanmasının beklendiği tarihtir. | ||
| Açıklama SLA Target Date, bir müşteri başvurusunun tüm işe alım sürecinin tamamlanması için üzerinde anlaşılmış son tarihi gösterir. Gerçek performansın ölçüldüğü önemli bir referans noktasıdır. Bu öznitelik, 'SLA Compliance Monitoring' Dashboardu ve 'SLA Adherence Rate' temel performans göstergesinin hesaplanması için gereklidir. SLA ihlali riski taşıyan vakaların proaktif biçimde yönetilmesini ve işlerin önceliklendirilmesini sağlar. Neden önemli? Hedef tamamlanma tarihini tanımlar. SLA uyumluluğunu izlemek ve süresi aşılmış vakalara öncelik vermek için önemlidir. Nereden alınır? Bu tarih çoğu zaman başvuru gönderim tarihine ve Fenergo'nun SLA yönetimi modülünde yapılandırılan iş kurallarına göre hesaplanır. Örnekler 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Başvuru kanalı ApplicationChannel | Müşteri başvurusunun gönderildiği kanaldır. | ||
| Açıklama Bu öznitelik, başvurunun gönderildiği kaynağı tanımlar. Örneğin başvuru çevrim içi portal, fiziksel şube veya müşteri ilişkileri yöneticisi aracılığıyla gönderilmiş olabilir. Kaynak, veri kalitesini ve işleme gerekliliklerini etkileyebilir. Bu boyut, farklı kanalların performansını karşılaştırmak için 'Application Source & Type Efficiency' Dashboardunda kullanılır. İşletmelerin hangi kanalların daha verimli olduğunu ve hangilerinin süreç optimizasyonu gerektirebileceğini anlamasına yardımcı olur. Neden önemli? Başvuruların kaynağını tanımlar ve kanal verimliliği, maliyet ile müşteri deneyiminin analiz edilmesini sağlar. Nereden alınır? Bu bilgi, Fenergo'daki ilk veri giriş formunda alınabilir veya önceki bir sistemden aktarılabilir. Örnekler Çevrim İçi PortalŞubeMüşteri İlişkileri YöneticisiMobil Uygulama | |||
| Ek bilgi talebi sayısı AdditionalInfoRequestCount | Bir başvuru için kaç kez ek bilgi talep edildiğinin toplam sayısı. | ||
| Açıklama Bu metrik, her vaka için 'Additional Information Requested' faaliyetinin gerçekleşme sayısını hesaplar. Sayının yüksek olması, sürecin uzamasına ve müşteri deneyiminin olumsuz etkilenmesine yol açabilecek daha fazla karşılıklı iletişime işaret eder. Bu öznitelik, 'Ek Bilgi Talebi Bulunan Vakalar' KPI'sını doğrudan destekler. Aşırı sayıda talep içeren başvuruları belirlemek için kullanılır. Bu durum, ilk veri toplama adımındaki sorunlara veya karmaşık vaka gereksinimlerine işaret edebilir. Analiz, bilgi toplama sürecini kolaylaştırmanıza yardımcı olur. Neden önemli? İlk bilgilerin eksik olmasından kaynaklanan müşteri zorluklarını ve süreç gecikmelerini ölçer, veri toplama adımını iyileştirmenize yardımcı olur. Nereden alınır? Bu, her 'CustomerApplication' kimliği için 'Additional Information Requested' olaylarının sayılmasıyla hesaplanan bir metriktir. Örnekler 013 | |||
| Müşteri kimliği CustomerId | Müşteri kabul sürecine alınan müşteri veya tüzel kişi için benzersiz tanımlayıcı. | ||
| Açıklama Müşteri kimliği, ana veri sistemindeki müşteri varlığına ait benzersiz referanstır. Başvuru numarası süreçteki vaka kimliğini gösterirken müşteri kimliği, müşteri kabul faaliyetini belirli bir müşteriye bağlar. Bu öznitelik, tek bir müşterinin müşteri kabul geçmişini analiz etmenizi sağlar. Örneğin müşterinin zaman içinde birden fazla müşteri kabul sürecinden geçip geçmediğini görebilirsiniz. Ayrıca daha kapsamlı bir iş görünümü elde etmek için süreç verilerini müşteriyle ilgili diğer verilerle birleştirmenize imkan verir. Neden önemli? Müşteri kabul sürecini benzersiz bir müşteri varlığına bağlar; müşteri odaklı analiz ve veri zenginleştirme sağlar. Nereden alınır? Bu kimlik, Fenergo'daki müşteri veya tüzel kişi kaydında saklanır ve müşteri kabul vakasıyla ilişkilendirilir. Örnekler CUST-98765CUST-98766CUST-98767 | |||
| Müşteri türü CustomerType | Onboarding sürecine alınan müşterinin Individual, Corporate veya Trust gibi sınıflandırmasıdır. | ||
| Açıklama Bu öznitelik, müşterileri yasal yapılarına veya finans kuruluşuyla ilişkilerine göre farklı kategorilere ayırır. Farklı müşteri türleri, değişen karmaşıklık ve durum tespiti gereklilikleriyle farklı işe alım yollarını izleyebilir. Süreci Customer Type bazında analiz etmek, segmentler arasındaki performans farklılıklarını belirlemeye yardımcı olur. Çevrim sürelerini ve onay oranlarını karşılaştırmak, ardından sürece özel iyileştirmeler yapmak için 'Application Source & Type Efficiency' Dashboardunda önemlidir. Neden önemli? Genellikle farklı karmaşıklık ve SLA düzeylerine sahip müşteri segmentleri arasında süreç performansının karşılaştırılmasını sağlar. Nereden alınır? Bu bilgi genellikle Fenergo'daki müşteri veya client varlığında saklanır ve başvuru vakasına bağlanır. Örnekler BireyselKurumsalVakıfOrtaklık | |||
| Otomatik mi IsAutomated | Faaliyetin insan kullanıcı yerine bir sistem tarafından gerçekleştirilip gerçekleştirilmediğini belirten boolean işareti. | ||
| Açıklama Bu öznitelik, sistemin otomatik olarak yürüttüğü görevlerle (ör. ilk tarama ve sistem kontrolleri) kullanıcıların manuel olarak gerçekleştirdiği görevleri birbirinden ayırır. Bu ayrım genellikle yürütücü kullanıcının bir sistem veya hizmet hesabı olup olmadığı kontrol edilerek yapılır. Bu işareti analiz etmek, süreçteki otomasyon düzeyini anlamak için önemlidir. Otomasyonun verimlilik, maliyet ve hız üzerindeki etkisini ölçmenize, ayrıca daha fazla otomasyon fırsatlarını belirlemenize yardımcı olur. Neden önemli? İnsan ve sistem faaliyetlerini birbirinden ayırır. Bu ayrım, otomasyon analizinde ve kaynak maliyetlerini anlamada büyük önem taşır. Nereden alınır? Genellikle 'InitiatingUser' alanından türetilir. Bu işareti true olarak ayarlamak için bilinen sistem kullanıcı kimliklerinden oluşan bir liste kullanılır. Örnekler truefalse | |||
| Ret nedeni RejectionReason | Bir başvurunun neden reddedildiğini açıklayan kod veya açıklamadır. | ||
| Açıklama Bir başvurunun nihai durumu 'Rejected' olduğunda bu öznitelik, reddedilme nedenini belirtir. Örnekler arasında 'Failed Background Check', 'Incomplete Documentation' ve 'High Risk Profile' bulunur. Bu öznitelik, başarısız başvuruların temel neden analizi için çok değerlidir. Başarısızlıkları kategorilere ayırarak 'Application Rework and Rejection' Dashboardunu doğrudan destekler. Böylece işletme yaygın sorunları belirleyebilir ve ilk seferde geçiş oranını artırmak için düzeltici adımlar uygulayabilir. Neden önemli? Başvuruların neden başarısız olduğuna ilişkin önemli içgörüler sağlar ve ret oranlarını azaltmak için temel neden analizini mümkün kılar. Nereden alınır? Genellikle Fenergo vaka iş akışındaki nihai ret durumuyla ilişkili neden kodu veya notlar alanında bulunur. Örnekler Yaptırım EşleşmesiGeçersiz BelgelerPolitika İhlaliMüşteri Başvurusunu Geri Çekti | |||
| SLA'ya uygun mu IsSlaCompliant | Vakanın SLA hedef tarihi içinde tamamlanıp tamamlanmadığını belirten boolean işareti. | ||
| Açıklama Bu öznitelik, tamamlanmış bir vakanın SLA performansını ikili bir göstergeyle ifade eder. Son kapatma faaliyetinin zaman damgası 'SlaTargetDate' değerine eşit veya ondan önceyse 'true', aksi durumda 'false' olarak ayarlanır. Bu hesaplanan alan, SLA izleme ve raporlamasını kolaylaştırır. Genel 'SLA'ya Uyum Oranı' KPI'sını hesaplamak için kolayca toplulaştırma yapmanızı ve uyumlu olanlarla uyumlu olmayan vakaların süreç özelliklerini analiz etmek üzere filtreleme yapmanızı sağlar. Neden önemli? SLA performansını doğrudan ölçer. SLA'ya Uyum Oranı KPI'sını kolayca hesaplamanızı ve uyumlu olmayan vakaları filtrelemenizi sağlar. Nereden alınır? Son vaka faaliyetinin zaman damgası (ör. 'Application Approved', 'Application Rejected') 'SlaTargetDate' ile karşılaştırılarak türetilir. Örnekler truefalse | |||
| Ülke Country | Müşteri başvurusuna ilişkin ikamet ülkesi veya yargı bölgesidir. | ||
| Açıklama Bu öznitelik, müşteriyle ilişkili ülkeyi belirtir. Ülke, onboarding süreci için geçerli olan düzenleyici kuralları ve risk faktörlerini çoğu zaman belirler. Süreci ülke bazında analiz etmek, döngü süresi, risk düzeyi ve süreç karmaşıklığı açısından yargı bölgeleri arasında karşılaştırma yapmayı sağlar. Bölgesel farklılıkların operasyonel performansı nasıl etkilediğini anlamaya ve yerel düzenlemelere uyumluluğu sağlamaya yardımcı olur. Neden önemli? Sürecin coğrafyaya göre segmentlere ayrılmasını sağlar. Bu, düzenleyici etkileri ve bölgesel performansı analiz etmek için önemlidir. Nereden alınır? Bu bilgi, başvuru sürecinde alınan temel müşteri verilerinin bir parçasıdır ve Fenergo'daki client varlığında saklanır. Örnekler USAGBRSGPDEU | |||
| Vaka sahibi CaseOwner | Başvuruyu yaşam döngüsü boyunca yönetmekten sorumlu ana kullanıcı veya ekip. | ||
| Açıklama Vaka sahibi, müşteri kabul vakasının birincil sorumluluğunu üstlenen kişi veya gruptur. Bu kişi genellikle vakanın zamanında ve başarıyla tamamlanmasından sorumludur. Bu öznitelik, vaka yöneticisi düzeyinde iş yükünü ve performansı analiz etmenize yardımcı olur. Belirli vaka sahiplerinin daha uzun çevrim sürelerine veya daha yüksek ret oranlarına sahip olup olmadığını görmenizi sağlar. Bu durum, eğitim ihtiyacına veya kaynak dengesizliğine işaret edebilir. Neden önemli? Bir vakanın sorumlu kişi veya ekibini belirleyerek vaka yöneticilerinin performansını analiz etmenizi sağlar. Nereden alınır? Bu, genellikle Fenergo'daki birincil vaka varlığında yer alan ve vakanın kime atandığını gösteren özel bir alandır. Örnekler s.jonesonboarding_team_am.chen | |||
| Yeniden çalışma mı IsRework | Bir faaliyetin yeniden çalışma döngüsünün parçası olup olmadığını belirten boolean işareti. | ||
| Açıklama Bu öznitelik, süreçte geriye dönüşü gösteren faaliyetleri belirler. Örneğin 'Compliance Review' başladıktan sonra yeniden 'Document Review' adımına dönülmesi veya 'Additional Information Requested' faaliyetinin gerçekleşmesi bu kapsamdadır. Yeniden çalışmayı belirlemek, süreç verimsizliğini ve sürecin yarattığı zorlukları anlamak için önemlidir. Bu işaret, 'Yeniden Çalışma Döngüsü Oranı' KPI'sını doğrudan hesaplamanızı, süreç akışındaki gereksiz ve tekrarlanan adımların etkisini görselleştirip ölçmenizi sağlar. Neden önemli? Süreçteki verimsiz yeniden çalışma döngülerini görünür kılar. İsrafı ölçmenize ve ilk seferde doğru tamamlama oranını artırmak için iyileştirme alanlarını belirlemenize yardımcı olur. Nereden alınır? Bu işaret, faaliyetlerin sırasını analiz eden Process Mining teknikleriyle türetilir. Örneğin aynı vaka için 'Activity A' faaliyetinin ardından 'Activity B' gelirse ve daha sonra 'Activity A' yeniden görünürse ikinci 'Activity A' yeniden çalışma olarak kabul edilir. Örnekler truefalse | |||
KYC Müşteri Kabulü Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Başvuru onaylandı | Bu faaliyet, müşterinin onboarding başvurusunun onaylanmasına ilişkin nihai kararı gösterir. Vaka durumu son 'Approved' veya 'Onboarding Approved' değerine geçtiğinde çıkarılır. | ||
| Neden önemli? Bu önemli kilometre taşı, son hesap etkinleştirme adımlarından önce başarılı bir sonucu gösterir. Onay oranlarını hesaplamak ve başarıyla onboarding yapılan müşterilerin özelliklerini analiz etmek için gereklidir. Nereden alınır? Vaka geçmişi veya denetim günlüğünde, son durumun 'Approved' veya benzer bir olumlu son duruma değiştiği zaman damgası bulunarak çıkarılır. Yakalayın Son durumun 'Approved' olarak değiştiği zaman damgasını belirleyin. Olay türü inferred | |||
| Başvuru reddedildi | Bu faaliyet, müşterinin başvurusunu reddetmeye ilişkin nihai kararı gösteren son olaydır. Vaka durumu son 'Rejected' veya 'Declined' değerine geçtiğinde çıkarılır. | ||
| Neden önemli? Önemli bir süreç sonu olarak bu faaliyet, 'Application Rejection Rate' hesaplamak ve başarısızlık nedenlerini analiz etmek için gereklidir. Yaygın ret noktalarını belirlemeye ve başvuru kalitesini iyileştirmeye yardımcı olur. Nereden alınır? Son durumun 'Rejected' olarak değiştiği zaman damgası vaka denetim günlüğünden alınır. Ret nedeni çoğu zaman ilişkili bir alanda saklanır. Yakalayın Son durumun 'Rejected' olarak değiştiği zaman damgasını belirleyin. Olay türü inferred | |||
| Belge incelemesi tamamlandı | Gönderilen tüm müşteri belgelerinin gerçekliğini ve doğruluğunu kontrol eden manuel veya otomatik sürecin tamamlandığını gösterir. Bu olay genellikle bir Workflow görevinin tamamlanmasından veya Fenergo'daki durum değişikliğinden çıkarılır. | ||
| Neden önemli? Birçok gecikmenin yaşandığı önemli bir kilometre taşıdır. Bu faaliyetin süresini ve sonuçlarını analiz etmek, belge işleme sürecindeki darboğazları belirlemeye ve 'First-Time Pass Rate' gibi KPI'ları desteklemeye yardımcı olur. Nereden alınır? Vaka iş akışındaki 'Document Verification' görevinin tamamlanma zaman damgasından veya vaka geçmişi günlüğündeki 'Documents Approved' durum güncellemesinden çıkarılır. Yakalayın Belge inceleme görevinin tamamlanma zaman damgasını veya ilgili durum değişikliğini kullanın. Olay türü inferred | |||
| Risk değerlendirmesi tamamlandı | Müşteriye çeşitli faktörlere göre risk derecesi atandığı kurum içi risk sınıflandırma sürecinin tamamlandığını gösterir. Bu bilgi, durum değişikliğinden veya risk derecesi alanının doldurulmasından çıkarılır. | ||
| Neden önemli? Genellikle sonraki Workflow yolunu belirleyen önemli bir karar aşamasıdır. Süresini analiz etmek, önemli bir uyumluluk adımını sadeleştirmeye ve risk değerlendirmesinde tutarlılık sağlamaya yardımcı olur. Nereden alınır? Vakanın 'Risk Assessed' gibi bir duruma geçtiği veya son 'Customer Risk Rating' alanının bir değerle doldurulduğu an belirlenerek vaka geçmişi günlüğünden çıkarılır. Yakalayın Risk derecesi alanının kesinleştirildiği veya ilgili durumun ayarlandığı zaman damgasını kullanın. Olay türü inferred | |||
| Uyumluluk incelemesi başlatıldı | Bu faaliyet, uyumluluk departmanının incelemesinin başladığını gösterir. Bu aşama önemli ve çoğu zaman uzundur. Vaka uyumluluk iş kuyruğuna atandığında veya durumu 'Pending Compliance Review' olarak değiştiğinde çıkarılır. | ||
| Neden önemli? Bu faaliyet, 'Average Compliance Review Time' KPI'ını ölçmek için başlangıç noktasıdır. Vakaların uyumluluk ekibi tarafından aktif olarak ele alınmadan önce ne kadar beklediğini belirlemeye yardımcı olur. Nereden alınır? Fenergo vaka denetim günlüğünden, durumun 'In Compliance Review' olarak değiştiği veya vakanın bir uyumluluk yetkilisine ya da ekibine atandığı zaman damgası alınarak çıkarılır. Yakalayın 'Under Compliance Review' durumuna geçişin veya atama olayının zaman damgasını belirleyin. Olay türü inferred | |||
| Uyumluluk incelemesi tamamlandı | Uyumluluk departmanının resmî onayını ve tüm düzenleyici gerekliliklerin karşılandığını gösterir. Bu bilgi, bir görevin tamamlanmasından veya durumun 'Compliance Approved' olarak değişmesinden çıkarılır. | ||
| Neden önemli? Önemli bir kilometre taşı olarak bu faaliyetin tamamlanması, toplam döngü süresi açısından büyük önem taşır. 'Average Compliance Review Time' ölçümünün bitiş noktasıdır ve uyumluluk işlevindeki darboğazları belirlemeye yardımcı olur. Nereden alınır? Fenergo iş akışındaki 'Compliance Review' görevinin tamamlanma zaman damgasından veya vaka geçmişindeki durum güncellemesi olayından çıkarılır. Yakalayın Uyumluluk inceleme görevinin tamamlanma veya durum güncellemesi zaman damgasını kullanın. Olay türü inferred | |||
| Vaka kapatıldı | Bu son faaliyet, onboarding vakasının Fenergo'da idari olarak kapatıldığını ve başka bir işlem beklenmediğini gösterir. Hem onaylanan hem de reddedilen başvurular için geçerlidir ve son 'Closed' durumundan çıkarılır. | ||
| Neden önemli? Bu faaliyet, tüm sürecin kesin bitiş noktasıdır. Sonuçtan bağımsız olarak tüm vakalar için doğru döngü süresi hesaplamalarını sağlar ve sürecin tamamlandığını doğrular. Nereden alınır? Vaka durumunun 'Closed', 'Completed' veya başka bir son duruma ayarlandığı zaman damgası belirlenerek Fenergo vaka denetim günlüğünden çıkarılır. Yakalayın Son durumun 'Closed' veya 'Completed' olarak değiştiği zaman damgasını belirleyin. Olay türü inferred | |||
| Vaka oluşturuldu | Bu faaliyet, yeni bir müşteri başvurusu Fenergo'da resmî olarak oluşturulduğunda KYC onboarding sürecinin başladığını gösterir. Genellikle vaka kaydı ilk kez kaydedildiğinde belirli bir zaman damgasıyla kaydedilen açık bir olaydır. | ||
| Neden önemli? Başlangıç olayı olarak bu faaliyet, toplam onboarding döngü süresini hesaplamak ve işlem hacmini analiz etmek için gereklidir. Sonraki tüm süreç ölçümleri ve SLA takibi için başlangıç noktası sağlar. Nereden alınır? Bu bilgi genellikle Fenergo’daki birincil vaka varlığının oluşturulma zaman damgasından alınır. Bu zaman damgası çoğunlukla Client Onboarding vakaları veya iş akışlarıyla ilgili tablolarda bulunur. Yakalayın Onboarding vaka kaydının oluşturulma zaman damgasını kullanın. Olay türü explicit | |||
| Arka plan kontrolleri başlatıldı | Bu faaliyet, harici arka plan, AML veya kredi kontrollerinin tetiklendiği noktayı gösterir. Genellikle üçüncü taraf bir hizmetle entegrasyon çağrıldığında kaydedilen açık bir olaydır. | ||
| Neden önemli? Bu kontrollerin başlatılmasını ve tamamlanmasını takip etmek, harici bağımlılıkların neden olduğu gecikmeleri anlamak için önemlidir. Kurum içi süreç süresini harici bekleme süresinden ayırmaya yardımcı olur. Nereden alınır? Genellikle harici tarama sağlayıcılarına yapılan API çağrılarını kaydeden sistem günlüklerinden veya Fenergo vakasında belirli bir 'Background Check' görevinin oluşturulmasından alınır. Yakalayın Harici hizmet entegrasyonlarına ilişkin günlükleri veya bir 'Screening' görevinin oluşturulmasını bulun. Olay türü explicit | |||
| Belgeler alındı | Bu faaliyet, müşterinin gerekli belgeleri yüklediğini veya gönderdiğini ve belgelerin artık Fenergo'da incelenmeye hazır olduğunu gösterir. Genellikle vaka durumu 'Documents Received' veya 'Pending Review' olarak güncellendiğinde çıkarılır. | ||
| Neden önemli? Bu olay, müşterinin bekleme süresinin sona erdiğini ve kurum içi inceleme döngüsünün başladığını gösterir. Müşterinin yanıt süresini ve kurum içi işlem kuyruğunda geçen süreyi ölçmek için önemlidir. Nereden alınır? Vaka denetim izinden çıkarılır. Bu iz, durumun 'Documents Received' veya benzer bir değere değiştiği zaman damgasını kaydeder. Bilgi, belge yükleme olaylarıyla da ilişkilendirilebilir. Yakalayın 'Documents Received' veya 'Ready for Review' durumuna geçişin zaman damgasını belirleyin. Olay türü inferred | |||
| Ek bilgi talep edildi | Onboarding ekibinin açıklama veya eksik belge için müşteriye yeniden başvurması gereken bir yeniden işleme döngüsünü gösterir. Bu, genellikle müşteriye iletişim gönderildiğinde kaydedilen açık bir olaydır. | ||
| Neden önemli? Bu faaliyet, süreç verimsizliğinin ve zayıf müşteri deneyiminin başlıca göstergelerindendir. Sıklığını takip etmek, yeniden işlemenin temel nedenlerini belirlemeye ve 'Rework Loop Rate' KPI'ını desteklemeye yardımcı olur. Nereden alınır? Müşteri iletişimleri olay günlüğünden veya durumun 'Awaiting Additional Information' değerine değişmesinden alınır. İlk seçenek, talebin tam olarak yapıldığı anı yakalamak için daha hassastır. Yakalayın Kaydedilmiş iletişim olaylarını veya 'Pending Customer Response' durumuna geçişi bulun. Olay türü explicit | |||
| Hesap etkinleştirildi | Onaydan sonra müşterinin hesabının ana bankacılık sisteminde veya ilgili sonraki sistemde başarıyla oluşturulup etkinleştirildiğini gösterir. Bu bilgi, onay sonrasında Fenergo'daki son durum güncellemesinden çıkarılabilir. | ||
| Neden önemli? Bu faaliyet, onboarding sürecinden aktif müşteri durumuna başarılı bir aktarımı doğrular. Onaydan etkinleştirmeye kadar geçen süreyi ölçmek, operasyonel kurulumdaki gecikmeleri ortaya çıkarabilir. Nereden alınır? 'Account Active' veya 'Onboarding Complete' gibi bir vaka durumundan çıkarılabilir. Ayrıca sonraki sistemle entegrasyon tarafından kaydedilen açık bir olay da olabilir. Yakalayın Onay sonrası durum değişikliğini veya entegrasyon başarı günlüğü olayını arayın. Olay türü inferred | |||
| İlk tarama tamamlandı | Temel veri doğrulama veya yaptırım listesi taraması gibi ön otomatik ya da manuel kontrollerin tamamlandığını gösterir. Bu bilgi genellikle Fenergo vaka iş akışındaki bir durum değişikliğinden çıkarılır. Örneğin durum 'New' değerinden 'Screening Complete' değerine geçer. | ||
| Neden önemli? Bu erken kilometre taşını takip etmek, ön yeterlilik aşamasındaki ilk veri kalitesi sorunlarını ve darboğazları belirlemeye yardımcı olur. İlk otomatik aşamayı daha yoğun manuel inceleme süreçlerinden ayırır. Nereden alınır? Vaka geçmişi veya denetim günlüğü incelenerek, vakanın taramanın tamamlandığını gösteren bir duruma geçtiği zaman damgası belirlenir. Örnek durumlar 'Screening Passed' veya 'Awaiting Documents' olabilir. Yakalayın Vaka geçmişinde 'Screening Complete' veya benzer bir duruma geçişi belirleyin. Olay türü inferred | |||
| Veri ve belgeler talep edildi | Bu olay, sistemin veya işe alım temsilcisinin müşteriden gerekli bilgi ve belgeleri resmî olarak istediğini gösterir. Genellikle standart bir iletişim Template gönderildiğinde açık bir olay olarak yakalanır. | ||
| Neden önemli? Bu faaliyet, müşteriye bağlı bir aşamanın başlangıcını gösterir. Bu noktadan belgelerin alındığı ana kadar geçen süreyi ölçmek, müşteri yolculuğunu analiz etmek ve iletişim gecikmelerini belirlemek için önemlidir. Nereden alınır? Müşteri iletişimleriyle ilişkili bir olay günlüğünden veya 'Request Documents' görevinin tamamlanma günlüğünden alınır. Ayrıca durumun 'Awaiting Customer Information' değerine değişmesinden de çıkarılabilir. Yakalayın Müşteri iletişimiyle ilgili kaydedilmiş bir olay veya görev tamamlanması arayın. Olay türü explicit | |||
Çıkarma rehberleri
Adımlar
- Raporlama modülüne erişin: Raporlama ve Analiz modülü için yeterli izinlere sahip bir kullanıcı hesabıyla Fenergo uygulamasına giriş yapın. Genellikle ana uygulama menüsünde bulunan modüle gidin.
- Yeni bir rapor oluşturun: Yeni bir özel rapor oluşturmayı başlatın. Amacını açıkça belirten bir ad ve açıklama seçin, örneğin 'KYC Onboarding Event Log for Process Mining'.
- Birincil veri kaynağını tanımlayın: Vaka yaşam döngüsü bilgilerini yakalayan temel veri nesnesini veya görünümünü seçin. Bu genellikle
[CaseWorkflowHistory]veya[LifecycleEventsView]gibi önceden yapılandırılmış bir görünümdür. Bu nesne vaka tanımlayıcılarını, olay adlarını veya durumları ve zaman damgalarını içermelidir. - Rapor sütunlarını yapılandırın (öznitelikler): Sütun eklemek için rapor oluşturucu arayüzünü kullanın. Fenergo veri modelindeki kaynak alanları gerekli Event Log öznitelikleriyle eşleyin. Örneğin Fenergo
CaseIDalanınıCustomerApplicationalanına,EventTimestampalanınıEventStartTimealanına veEventPerformeralanınıInitiatingUseralanına eşleyin. - Etkinlik mantığını oluşturun: Bu en önemli adımdır. Rapor, gerekli 14 etkinliğin her biri için ayrı bir satır oluşturacak şekilde yapılandırılmalıdır. Bunun için her etkinlik için mantıksal bloklar veya filtrelenmiş veri kümeleri oluşturun ve bunları rapor oluşturucuda UNION ya da eşdeğer bir işlev kullanarak birleştirin.
- 'Case Created' mantığını tanımlayın: İlk bloğu oluşturun. Veri kaynağını ilk vaka oluşturma olayına göre filtreleyin. Bu genellikle vakayla ilişkilendirilen en erken zaman damgasına veya 'Case Created' adlı bir olay türüne dayanır.
CreationDatealanınıEventStartTimealanına eşleyin. - Duruma dayalı etkinlik mantığını tanımlayın: Durum değişikliklerinden çıkarılan etkinlikler, örneğin 'Documents Received' ve 'Application Approved', için ayrı bloklar oluşturun. Veri kaynağını belirli
Durumalanı değerine göre filtreleyin veStatusChangeDatedeğeriniEventStartTimeolarak kullanın. - Göreve dayalı etkinlik mantığını tanımlayın: İş akışı görevleriyle ilişkili etkinlikler, örneğin 'Compliance Review Completed', için
TaskNameveTaskCompletionDatealanlarına göre filtrelenen bloklar oluşturun. Tamamlanma tarihiniEventStartTimeolarak kullanın. - Genel rapor filtrelerini ayarlayın: Verilerin kapsamını belirlemek için rapor düzeyinde filtreler uygulayın. Aşırı büyük dışa aktarımları önlemek üzere
EventStartTimeiçin belirli birDate Rangeayarlayın. İlk analiz için 3 ila 6 aylık bir dönem önerilir. 'KYC Customer Onboarding' gibi belirli vaka türüne göre filtreleyin. - Raporu çalıştırın ve önizleyin: Raporu Fenergo kullanıcı arayüzünde çalıştırın. Veri yapısının doğru olduğunu, tüm sütunların beklendiği gibi doldurulduğunu ve farklı etkinliklerin bulunduğunu doğrulamak için ilk 100-200 satırı önizleyin.
- Verileri dışa aktarın: Rapor sonuçlarının tamamını CSV veya Excel dosyasına aktarın. Bu dosya ham Event Logdur.
- Verileri son kullanıma hazırlayın: Dışa aktardığınız CSV dosyasını açın.
SourceSystemveLastDataUpdatesütunları doğrudan rapor tarafından oluşturulamadıysa bunları manuel olarak ekleyin. Tüm satırlardaSourceSystemdeğerini 'Fenergo',LastDataUpdatedeğerini ise dışa aktarım zaman damgası olarak ayarlayın.
Yapılandırma
- Ön koşullar: Kullanıcının özel rapor oluşturup çalıştırma izinleriyle birlikte Fenergo Reporting & Analytics modülüne erişimi olmalıdır.
- Temel veri kaynakları: Rapor öncelikle Fenergo'nun vaka yönetimi ve Workflow geçmişi nesnelerinden oluşturulmalıdır. Yaygın kaynaklar arasında
[CaseDetails],[CaseStatusHistory]ve[WorkflowTaskHistory]bulunur. Kesin adlar Fenergo yapılandırmanıza göre değişebilir. - Tarih aralığı: Performansı yönetmek için olay zaman damgasına tarih aralığı filtresi uygulamak önemlidir. Önce 3 ila 6 aylık yakın bir dönemle başlayın. Geçmiş analizleri için raporu partiler halinde, örneğin üç aylık veya yıllık dönemler şeklinde çalıştırın.
- Temel filtreler: İlgisiz verileri dışarıda bırakmak için her zaman 'KYC Customer Onboarding' gibi belirli süreç veya vaka türüne göre filtreleyin. Analiz hedeflerinize bağlı olarak tüzel kişi türüne veya yargı alanına göre de filtreleme yapmanız gerekebilir.
- Faaliyet tanımı: Her faaliyet,
Status,TaskNameveya özel birEventTypealanındaki belirli filtre ölçütleriyle tanımlanmalıdır. Süreçteki her benzersiz olayı ayırmak için bu alanları kullanmak önemlidir. - Performansla ilgili noktalar: Birçok veri kaynağını birleştiren veya geniş bir tarih aralığını tarayan raporlar yavaş çalışabilir. Mümkünse raporu yoğun olmayan saatlerde çalışacak şekilde planlayın. Dışa aktarıma gereksiz sütunlar eklemeyin, çünkü bu işlem süresini artırır.
a Örnek sorgu sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' Başlamaya hazır mısınız?
Bu Veri Templateinden yararlanarak Fenergo’daki KYC müşteri işe alım sürecinizdeki verimsizlikleri ortaya çıkarma ve süreci sadeleştirme yolunda önemli bir ilerleme kaydedebilirsiniz. Optimize edilmiş operasyonlara ve daha yüksek müşteri memnuniyetine giden yolculuğunuza bugün başlayın.
KYC müşteri kabulünü kolaylaştırın, bugün daha hızlı onaylar alın
Müşteri kabul süresini yalnızca 24 saate indiren işletmelere katılın.
Kredi kartı gerekmez. Dakikalar içinde başlayın.