KYC Müşteri Kabul Veri Şablonunuz

LexisNexis Risk Solutions
KYC Müşteri Kabul Veri Şablonunuz

KYC Müşteri Kabul Veri Şablonunuz

Bu şablon, KYC Müşteri Kabul sürecinizi analiz etmek için kapsamlı bir rehber sunar. Toplanması gereken temel nitelikleri, izlenecek ana aktiviteleri özetler ve bu bilgiyi kaynak sistemlerinizden nasıl çıkaracağınıza dair rehberlik sağlar. Kabul yolculuğunuza derinlemesine içgörüler sağlamak için sağlam bir event logu oluşturmak amacıyla bu kaynağı kullanın.
  • Toplanması Önerilen Nitelikler
  • Takip Edilmesi Gereken Temel Aktiviteler
  • Veri Çekim Rehberliği
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

KYC Müşteri Kabul Nitelikleri

Bunlar, kapsamlı KYC Müşteri Kabul analizi ve süreç keşfi için event log'unuza eklemeniz önerilen veri alanlarıdır.
3 Gerekli 6 Önerilen 12 İsteğe Bağlı
Ad Açıklama
Faaliyet Adı
ActivityName
Kabul süreci sırasında belirli bir zamanda gerçekleşen spesifik görevin veya event'in adı.
Açıklama

Aktivite Adı, 'Başvuru Gönderildi', 'Belge İncelemesi Yapıldı' veya 'Başvuru Onaylandı' gibi KYC kabul Workflow'undaki bir adımı açıklar. Her aktivite, süreçte belirgin bir eylemi veya kilometre taşını temsil eder.

Bu nitelik, aktivitelerin akışını görsel olarak temsil eden süreç haritasını oluşturmak için kritiktir. Süreç varyantlarının, belirli adımlar arasındaki darboğazların ve yeniden işleme döngülerinin sıklığının analiz edilmesine olanak tanır. Aktiviteleri analiz etmek, süreçte ne olduğunu anlamanın anahtarıdır.

Neden önemli

Bu nitelik, süreç haritasının omurgasını oluşturur, bu da müşteri kabul yolculuğundaki event dizisini görselleştirmenize ve analiz etmenize olanak tanır.

Nereden alınır

Genellikle LexisNexis Risk Solutions içindeki süreç adımlarını izleyen bir event logunda veya denetim izi tablosunda bulunur.

Örnekler
Başvuru Gönderildiİlk Tarama GerçekleştirildiBelgeler Talep EdildiUyumluluk İncelemesi Tamamlandı
Müşteri Başvurusu
CustomerApplication
Her müşteri kabul başvurusu için birincil vaka ID'si olarak hizmet veren benzersiz tanımlayıcı.
Açıklama

Müşteri Başvurusu, tek bir müşterinin kabul yolculuğuna ait tüm ilgili aktiviteleri ve veri noktalarını birbirine bağlayan merkezi tanımlayıcıdır. Bir başvuru gönderildiğinde başlar ve vaka tamamlanana veya reddedilene kadar devam eder.

Process mining'de, bu nitelik tüm event'leri tutarlı bir vaka halinde gruplamak için esastır, bu da kabul yaşam döngüsünün uçtan uca analizine olanak tanır. Her başvuru sahibi için tüm süreç akışının yeniden yapılandırılmasını sağlar, bu da döngü sürelerini hesaplamak, süreç varyantlarını analiz etmek ve bir başvurunun durumunu zaman içinde izlemek için temeldir.

Neden önemli

Bu, temel Vaka ID'sidir. Bu olmadan, bir müşteri başvurusunun uçtan uca yolculuğunu takip edemezsiniz, bu da süreç analizini imkansız hale getirir.

Nereden alınır

Bu, LexisNexis Risk Solutions vaka yönetimi modülündeki birincil vaka tanımlayıcısıdır.

Örnekler
APP-2023-001234APP-2023-005678APP-2024-009101
Olay Zaman Damgası
EventTimestamp
Belirli bir aktivitenin başladığı kesin tarih ve saat.
Açıklama

Bu timestamp, bir aktivitenin başlangıcını işaret eder ve bir vaka içindeki tüm event'ler için kronolojik sırayı sağlar. Process Mining'deki tüm zaman tabanlı analizlerin temelidir.

Event Timestamp kullanılarak, aktivitelerin süresi, aralarındaki bekleme süresi ve kabul sürecinin toplam uçtan uca döngü süresi hesaplanabilir. Bu veri, darboğazları belirlemek, SLA uyumunu izlemek ve süreç verimliliğini anlamak için esastır.

Neden önemli

Bu timestamp, event'leri kronolojik olarak sıralamak ve döngü süreleri ve darboğazlar gibi tüm zaman tabanlı metrikleri hesaplamak için esastır.

Nereden alınır

Event log veya denetim izi tablolarında Aktivite Adı'nın yanında bulunur.

Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
Atanan Kullanıcı
AssignedUser
Aktiviteyi gerçekleştirmekten sorumlu kullanıcının veya temsilcinin benzersiz tanımlayıcısı.
Açıklama

Bu nitelik, bir görevi gerçekleştiren belirli kişiyi, örneğin bir belge incelemesi yapan uyumluluk görevlisini tanımlar. İş yükü dağılımının ve bireysel performansın analiz edilmesine yardımcı olur.

Analizde, Atanan Kullanıcı 'Kaynak Tahsisi ve İş Yükü' Dashboard'u için anahtardır. Süreç haritasını kullanıcıya göre filtrelemeye, ekip üyeleri arasındaki performansı karşılaştırmaya ve eğitim veya iş yükü dengeleme fırsatlarını belirlemeye olanak tanır. Ayrıca belirli kullanıcı gruplarından kaynaklanan darboğazları belirlemeye de yardımcı olabilir.

Neden önemli

Bu nitelik, kaynak performansını, iş yükü dağılımını analiz etmek ve otomasyon veya kaynak optimizasyonu fırsatlarını belirlemek için kritik öneme sahiptir.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Genellikle denetim izlerinde veya görev yönetim tablolarında bulunur.

Örnekler
j.doem.smithk.chen
Başvuru Durumu
ApplicationStatus
Müşteri başvurusunun mevcut veya nihai durumu.
Açıklama

Bu nitelik, vakanın belirli bir andaki genel durumunu veya nihai sonucunu yansıtır. Yaygın durumlar arasında 'Devam Ediyor', 'Onaylandı', 'Reddedildi' veya 'Bilgi Bekleniyor' bulunur.

Başvuru Durumu, kabul sürecinin sonuçlarını izlemek için hayati öneme sahiptir. Başarı oranlarını ve operasyonel akışı izlemek için 'Başvuru Reddetme Nedenleri ve Aşamaları' ve 'Günlük Çıktı ve Başvuru Durumu' Dashboard'larında kullanılır. Durumun zaman içinde nasıl değiştiğini analiz etmek, vaka yaşam döngüsü hakkında içgörü sağlar.

Neden önemli

Her başvurunun sonucunu izler, bu da Başvuru Reddetme Oranı gibi temel KPI'ları hesaplamak ve üretimi izlemek için esastır.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bu, genellikle ana vaka veya başvuru nesnesindeki anahtar bir alandır.

Örnekler
Devam EdiyorOnaylandıReddedildiBekleyen Müşteri Bilgileri
Bitiş Saati
EndTime
Bir `aktivite`nin tamamlandığı `kesin tarih ve saat`.
Açıklama

Bu timestamp, bir aktivitenin tamamlanmasını işaret eder. Bir event için End Time ile Start Time arasındaki fark, işlem süresini temsil eder.

End Time, her adımın ne kadar sürdüğünü doğru bir şekilde hesaplamak için çok önemlidir ve 'Aktivite İşlem ve Bekleme Süreleri' Dashboard'u için birincil bir girdidir. Bir kaynağın bir görev üzerinde aktif olarak çalıştığı zaman ile vakanın bir sonraki adımın başlamasını beklediği zaman arasındaki farkı ayırt etmeye yardımcı olur.

Neden önemli

Aktivite işleme süresinin hassas hesaplanmasını sağlar, bu da verimsiz adımları belirlemek ve kaynak iş yükünü analiz etmek için esastır.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Genellikle hem başlangıç hem de bitiş olaylarını kaydeden olay günlüklerinde bulunur.

Örnekler
2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
Bölüm
Department
Atanan kullanıcının ait olduğu iş departmanı veya ekip.
Açıklama

Departman niteliği, 'Uyumluluk', 'Müşteri Kabul Operasyonları' veya 'Dolandırıcılık Önleme' gibi bir aktiviteden sorumlu fonksiyonel grubu belirtir.

Bu nitelik, süreci departmansal bir bakış açısıyla analiz etmek için kullanılır ve farklı ekipler arasındaki el değişimlerinin analizini sağlar. 'Kaynak Tahsisi ve İş Yükü' Dashboard'unda birincil bir boyuttur ve departmanlar arası verimsizlikleri veya iletişimdeki gecikmeleri belirlemeye yardımcı olur.

Neden önemli

Süreç devirlerinin ve fonksiyonel alana göre performansın analiz edilmesini sağlar, departmanlar arası darboğazların belirlenmesine yardımcı olur.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bir kullanıcı veya İnsan Kaynakları ana veri tablosundan birleştirilmesi gerekebilir.

Örnekler
ComplianceMüşteri Kabul EkibiKYC AnalistleriMüşteri Desteği
Risk Seviyesi
RiskLevel
Müşteri başvurusunun hesaplanmış risk seviyesi, örneğin Düşük, Orta veya Yüksek.
Açıklama

LexisNexis Risk Solutions, risk değerlendirmesi konusunda uzmanlaşmıştır. Bu nitelik, değerlendirmenin çıktısını temsil eder ve her başvuruyu potansiyel risk profiline göre kategorize eder. Risk seviyesi genellikle gerekli durum tespiti sürecinin yoğunluğunu ve süresini belirler.

Bu nitelik, 'Risk Seviyesi ve Kabul Süresi' Dashboard'u için temel boyuttur. Süreci risk seviyesine göre analiz etmek, yüksek riskli başvuruların beklendiği gibi daha uzun sürüp sürmediğini veya düşük riskli başvuruların gereksiz yere gecikip gecikmediğini ortaya çıkarabilir. Risk tabanlı kabul stratejilerini doğrulamaya ve iyileştirmeye yardımcı olur.

Neden önemli

Risk tabanlı analiz için kritik öneme sahiptir, müşteri risk profillerinin süreç karmaşıklığı, süresi ve yolları üzerindeki etkisini anlamaya yardımcı olur.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bu, risk değerlendirme modüllerinin temel bir çıktısıdır.

Örnekler
DüşükOrtaYüksekYaptırım Uygulandı
SLA Hedef Tarihi
SlaTargetDate
Müşteri kabul sürecinin tamamlanması beklenen tarih.
Açıklama

SLA Hedef Tarihi, bir başvurunun tamamlanması için hizmet seviyesi anlaşmasını tanımlar. Bu tarih genellikle başvuru türü, müşteri segmenti veya yargı yetkisi gibi faktörlere göre belirlenir.

Bu nitelik, 'SLA Hedefi Uyum İzleme' Dashboard'u ve 'SLA Uyum Oranı' KPI'ı için esastır. Gerçek tamamlanma tarihini SLA Hedef Tarihi ile karşılaştırarak, kuruluşlar taahhütlerine karşı performanslarını ölçebilir, SLA'ları ihlal etme riski taşıyan vakaları belirleyebilir ve gecikmelerin temel nedenlerini araştırabilir.

Neden önemli

Hizmet seviyesi anlaşmalarına (SLA) karşı performans ölçümünü mümkün kılar, SLA ihlallerine neden olan süreç verimsizliklerini vurgular.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bu, vakada depolanabilir veya iş kurallarına göre hesaplanabilir.

Örnekler
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
Başvuru Türü
ApplicationType
'Bireysel' veya 'Kurumsal' gibi müşteri başvurusunun türü.
Açıklama

Bu nitelik, başvuruları kabul edilen varlık türüne göre kategorize eder. Farklı başvuru türleri genellikle farklı süreç yollarını takip eder ve farklı risk profillerine ve SLA hedeflerine sahiptir.

Süreci Başvuru Türüne göre analiz etmek, farklı türdeki müşterilerin kabul verimliliğini ve karmaşıklığını karşılaştırmak için verilerin segmentasyonuna olanak tanır. Performansın daha ayrıntılı bir görünümünü sağlamak için çoğu Dashboard'da kullanılan yaygın bir filtredir.

Neden önemli

Sürecin güçlü bir şekilde bölümlendirilmesini sağlar, farklı başvuru türlerinin nasıl ele alındığını ve her tür için belirli darboğazların nerede bulunduğunu ortaya çıkarır.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bu, genellikle başvuru veya vaka nesnesindeki temel bir alandır.

Örnekler
BireyselKurumsalYüksek Net Değerli BireyGüven
Döngü Süresi
CycleTime
Bir müşteri başvurusunun gönderiminden nihai karara kadar olan toplam uçtan uca süresi.
Açıklama

Döngü Süresi, tek bir vaka için ilk olaydan (örneğin, 'Başvuru Gönderildi') son olaya (örneğin, 'Müşteri Kayıt Süreci Tamamlandı' veya 'Başvuru Reddedildi') kadar geçen toplam süreyi ölçer.

Bu, genel süreç sağlığını ölçmek için birincil bir KPI'dır ve 'Uçtan Uca Kayıt Süresi' Dashboard'unda görselleştirilir. Ortalama döngü süresini takip etmek, kuruluşların süreç iyileştirmelerinin etkisini izlemesine ve risk seviyesi veya başvuru türü gibi farklı faktörlerin genel müşteri deneyimini nasıl etkilediğini belirlemesine olanak tanır.

Neden önemli

Bu, müşteri için toplam değer yaratma süresini ölçen, müşteri memnuniyetini ve operasyonel verimliliği doğrudan etkileyen önemli bir performans göstergesidir.

Nereden alınır

Bu, her vaka için ilk event'in timestamp'inden son event'in timestamp'inin çıkarılmasıyla türetilen hesaplanmış bir metriktir.

Örnekler
5 gün 4 saat22 gün 8 saat1 gün 2 saat
İşlem Süresi
ProcessingTime
Bir faaliyet üzerinde aktif olarak çalışılan süre.
Açıklama

İşlem Süresi, bir aktivitenin başlangıç ve bitiş timestamp'lerinden (EndTime - StartTime) hesaplanan süredir. Bir kaynağın bir görevle aktif olarak ilgilendiği zamanı temsil eder, bekleme süresinin aksine.

Bu hesaplanmış metrik, performans analizinin temel taşıdır ve doğrudan 'Aktivite İşlem ve Bekleme Süreleri' Dashboard'unu besler. Hangi belirli aktivitelerin en çok zaman alıcı olduğunu belirlemeye yardımcı olur, süreç iyileştirme, eğitim veya otomasyon için hedefleri gösterir. Örneğin, 'Ort. Belge İnceleme İşlem Süresi' KPI'ını hesaplamaya yardımcı olur.

Neden önemli

Aktiviteler için aktif çalışma süresini ölçerek, gerçek darboğazları belirlemek için değer katan zaman ile israf edilen bekleme süresini ayırt etmeye yardımcı olur.

Nereden alınır

Bu, 'EndTime' ve 'EventTimestamp' (StartTime) nitelikleri arasındaki farktan türetilen hesaplanmış bir alandır.

Örnekler
25 dakika1 saat 15 dakika3 gün
Kanal
Channel
Başvurunun gönderildiği kanal, örneğin 'Web', 'Mobil' veya 'Şube İçi'.
Açıklama

Kanal niteliği, başvurunun gönderim kaynağını tanımlar. Kanal, veri kalitesini, müşteri davranışını ve kabul sırasında karşılaşılan sorun türlerini etkileyebilir.

Bu nitelik, farklı kanallardaki süreç performansını karşılaştırmak için kullanılır. Örneğin, 'Müşteri Kabul Hunisi Dönüşüm Oranları' Dashboard'u, mobil başvuru sahiplerinin web başvuru sahiplerinden daha yüksek oranda ayrılıp ayrılmadığını görmek için kanala göre filtrelenebilir ve kanala özgü süreç iyileştirmeleri hakkında bilgi sağlar.

Neden önemli

Gönderim kanalına göre süreç performansını analiz etmeye yardımcı olur, kanal stratejisi ve kullanıcı deneyimi iyileştirmelerini bilgilendirebilecek varyasyonları belirler.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bu bilgi genellikle başvuru sürecinin başlangıcında yakalanır.

Örnekler
Web PortalMobil UygulamaŞube İçiAPI
Kaynak Sistem
SourceSystem
Event verisinin kaynaklandığı sistem veya uygulama.
Açıklama

Bu nitelik, event verisini oluşturan kaynak sistemi, örneğin LexisNexis Risk Solutions veya entegre bir üçüncü taraf aracı tanımlar. Karmaşık ortamlarda, tek bir süreç için veriler birden fazla sistemden gelebilir.

Kaynak sistemi anlamak, veri doğrulaması, sorun giderme ve belirli bir sisteme özgü olabilecek süreç varyasyonlarını analiz etmek için faydalıdır. Veri bütünlüğünü sağlamaya ve bir aktivitenin nasıl ve nerede kaydedildiği hakkında bağlam sağlamaya yardımcı olur.

Neden önemli

Verinin kaynağını belirler, bu da veri yönetimi, doğrulama ve farklı BT sistemleri genelinde süreç yürütmesini anlamak için çok önemlidir.

Nereden alınır

Bu bilgi, statik bir değer olarak veya veri dışa aktarımında veya API yanıtında belirli bir alanda saklanabilir.

Örnekler
LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
Müşteri Ülkesi
CustomerCountry
Müşterinin ikamet veya kuruluş ülkesi.
Açıklama

Bu nitelik, müşterinin ülkesini belirtir; bu, değişen uluslararası düzenlemeler ve farklı yargı bölgeleriyle ilişkili risk seviyeleri nedeniyle KYC'de kritik bir faktördür.

Müşteri Ülkesine göre süreci analiz etmek, döngü sürelerinde ve süreç karmaşıklığında önemli farklılıkları ortaya çıkarabilir. Örneğin, yüksek riskli yargı bölgelerinden gelen başvurular ek uyumluluk kontrolleri gerektirebilir, bu da daha uzun sürelere yol açar. Bu analiz, kaynak planlamasına ve farklı bölgeler için gerçekçi SLA'lar belirlemeye yardımcı olur.

Neden önemli

Bölgesel düzenlemelerin ve risk faktörlerinin süreç performansını nasıl etkilediğini anlamak için kritik olan yargısal analizi mümkün kılar.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bu, müşteri ana verilerinde standart bir alandır.

Örnekler
USAGBRDEUSGP
Otomatikleştirildi mi?
IsAutomated
Bir `aktivite`nin sistem tarafından `otomatik` mi yoksa bir kullanıcı tarafından `manuel` mi gerçekleştirildiğini gösteren bir `flag`.
Açıklama

Bu boolean niteliği, sistem otomasyonu tarafından yürütülen görevler (örn. ilk tarama kontrolü) ile insan müdahalesi gerektiren görevleri (örn. manuel belge incelemesi) birbirinden ayırır.

'Otomatik mi' ('Is Automated'), 'Manuel Aktivite Oranı' KPI'ını hesaplamak ve otomasyon girişimlerinin etkinliğini analiz etmek için kullanılır. Süreç haritasında, otomatik ve manuel adımlar arasındaki arayüzü vurgulayabilir, maliyetleri ve işlem sürelerini azaltmak için daha fazla otomasyon fırsatlarını belirlemeye yardımcı olabilir.

Neden önemli

Manuel ve otomatik görevler arasında ayrım yapar, bu da otomasyon fırsatlarını belirlemek ve etkilerini ölçmek için anahtardır.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bu, olay günlüğünde bir işaret olabilir veya 'AssignedUser'a (örneğin, bir 'sistem' kullanıcısı) göre çıkarılabilir.

Örnekler
truefalse
Ret Nedeni
RejectionReason
Bir başvurunun neden reddedildiğini açıklayan bir kod veya açıklama.
Açıklama

Bir başvurunun nihai durumu 'Reddedildi' olduğunda, bu nitelik belirli nedeni sağlar. Örnekler arasında 'Kimlik Doğrulama Başarısız', 'Yaptırım Eşleşmesi' veya 'Eksik Belgeleme' bulunur.

Bu veri, 'Başvuru Reddetme Nedenleri ve Aşamaları' Dashboard'u için birincil girdidir. Reddetme nedenlerini analiz etmek, süreçteki yaygın hata noktalarını belirlemeye yardımcı olur, bu da başvuru yönergelerine, müşteri iletişimine veya dahili inceleme kriterlerine ilişkin iyileştirmeleri bilgilendirebilir. Başvuruların neden reddedildiğini anlamak, genel onay oranını iyileştirmek için anahtardır.

Neden önemli

Müşteri kabulünün neden başarısız olduğuna dair doğrudan içgörü sağlayarak, başvuru onay oranını artırmak için hedefe yönelik iyileştirmelere olanak tanır.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Genellikle Başvuru Durumu 'Reddedildi' olarak ayarlandığında doldurulan bir alanda bulunur.

Örnekler
Yaptırım Listesi EşleşmesiEksik DokümantasyonKimlik Doğrulama BaşarısızYüksek Risk Profili
SLA Statüsü
SlaStatus
Tamamlanan başvurunun SLA hedefini karşılayıp karşılamadığını gösterir.
Açıklama

Bu nitelik, tamamlanmış her vakayı 'SlaTargetDate' uyumuna göre kategorize eder. Tipik değerler 'Met' (Karşılandı) veya 'Breached' (İhlal Edildi) şeklindedir.

Bu hesaplanmış alan, 'SLA Hedefi Uyum İzleme' Dashboard'unun ve 'SLA Uyum Oranı' KPI'ının temelidir. Hizmet taahhütlerine karşı performansa dair net, üst düzey bir görünüm sağlar ve SLA'larını ihlal eden vakaların ortak özelliklerini anlamak için detaylı analizlere olanak tanır.

Neden önemli

SLA performansı için net, ikili bir sonuç sunarak hizmet seviyesi hedeflerine uyumu izlemeyi, raporlamayı ve analiz etmeyi kolaylaştırır.

Nereden alınır

Bu, her vaka için nihai aktivitenin timestamp'ini 'SlaTargetDate' ile karşılaştırarak türetilen hesaplanmış bir niteliktir.

Örnekler
Karşılandıİhlal EdildiRisk Altında
Son Veri Güncellemesi
LastDataUpdate
Verinin kaynak sistemden en son yenilendiği veya çıkarıldığı timestamp.
Açıklama

Bu nitelik, veri setinin en son ne zaman güncellendiğine dair bir timestamp sağlar. Genellikle veri çıkarma ve yükleme süreci sırasında tüm veri setine uygulanır.

Bu bilgi, Dashboard kullanıcılarının analiz ettikleri verilerin güncelliğini anlamaları için kritiktir. Kararların gerektiği kadar güncel verilere dayanmasını sağlar ve içgörülerin zamanında sağlanması konusundaki beklentileri yönetmeye yardımcı olur.

Neden önemli

Veri güncelliği hakkında kritik bağlam sağlayarak analizlerin ilgili olmasını ve kararların güncel olmayan bilgilere dayanmamasını sağlar.

Nereden alınır

Bu, genellikle ETL (Extract, Transform, Load) süreci sırasında veri setine oluşturulur ve damgalanır.

Örnekler
2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
Uyumluluk İnceleyicisi
ComplianceReviewer
Uyumluluk inceleme aktivitelerine özel olarak atanmış kullanıcı veya temsilci.
Açıklama

'AssignedUser' herhangi bir aktivite için kullanıcıyı yakalarken, bu nitelik kritik inceleme adımlarına dahil olan uyumluluk uzmanını özel olarak tanımlar. Bu, uyumluluk fonksiyonunun daha odaklı bir analizine olanak tanır.

Bu nitelik, 'Uyumluluk İnceleme Süresi ve Birikim' Dashboard'u için anahtardır. Uyumluluk ekibinin iş yükünü ve performansını analiz etmeye yardımcı olur, belirli inceleyicilerin darboğaz olup olmadığını veya genel ekibin kaynak yetersizliği yaşayıp yaşamadığını belirler.

Neden önemli

Uyumluluk fonksiyonuna odaklanmış içgörü sunarak, bu kritik ve genellikle gecikmeli süreç aşamasındaki inceleyici iş yükünün ve performansının detaylı analizine olanak tanır.

Nereden alınır

LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bu, uyumlulukla ilgili aktiviteler için 'AssignedUser' filtresi uygulanarak türetilebilir.

Örnekler
c.joness.patelsystem_escalation
Yeniden İşleme mi?
IsRework
Yeniden işleme döngüsünün bir parçası olan aktiviteleri tanımlayan bir işaret.
Açıklama

Bu boolean bayrağı, aynı vaka içinde bir aktivitenin tekrarlandığında true olarak ayarlanır, örneğin 'Ek Bilgi Talep Edildi'den sonra ikinci kez 'Belge İncelemesi Yapıldı' meydana geldiğinde. Bu, sürecin geriye gittiğini gösterir.

'Yeniden İşleme mi' ('Is Rework'), 'Yeniden İşleme ve Tekrar Analizi' Dashboard'u ve 'Yeniden İşleme Döngüsü Yüzdesi' KPI'ı için kritik öneme sahiptir. Harcanan çabanın niceliksel olarak belirlenmesine yardımcı olur ve belirsiz talimatlar veya kötü veri kalitesi gibi yeniden işlemenin temel nedenlerini belirlemeye yardımcı olarak hedefe yönelik süreç iyileştirmelerini sağlar.

Neden önemli

Süreçteki verimsizliği ve boşa harcanan çabayı doğrudan nicelendirir, sıkça tekrarlanan ve maliyetleri ve döngü sürelerini artıran aktiviteleri vurgular.

Nereden alınır

Bu, genellikle bir vaka içindeki tekrarlayan aktivite dizilerini tespit ederek Process Mining aracı içinde türetilen hesaplanmış bir niteliktir.

Örnekler
truefalse
Gerekli Önerilen İsteğe Bağlı

KYC Müşteri Kabul Aktiviteleri

Bunlar, doğru süreç keşfi ve performans analizi için event log'unuzda yakalamanız gereken temel süreç adımları ve kilometre taşlarıdır.
8 Önerilen 6 İsteğe Bağlı
Aktivite Açıklama
Başvuru Gönderildi
Bir müşterinin başvurusu sistem tarafından ilk kez alındığında KYC kabul sürecinin başlangıcını işaretler. Bu event, genellikle başvuru formu bir müşteri portalı veya LexisNexis ile entegre bir dahili veri giriş sistemi aracılığıyla gönderildiğinde açıkça kaydedilir.
Neden önemli

Bu, süreç için birincil başlangıç event'idir. Bu aktiviteden tamamlanmaya kadar geçen süreyi analiz etmek, uçtan uca döngü süresini ve SLA uyumunu ölçmek için kritik öneme sahiptir.

Nereden alınır

Sistem günlüklerinden veya yeni bir müşteri başvuru kaydının ilk oluşturulma zaman damgasını kaydeden bir başvuru tablosundan alınmıştır.

Yakala

Yeni bir başvuru vakasının veya çekirdek başvuru tablosuna bir girişin oluşturulması üzerine olay günlüğe kaydedilir.

Event tipi explicit
Başvuru Onaylandı
Müşterinin başvurusunu onaylamak için nihai karar verilir ve sisteme kaydedilir. Bu, kritik bir iş sonucudur ve neredeyse her zaman açık bir durum değişikliği olarak yakalanır.
Neden önemli

Bu kilometre taşı, karar verme sürecinin başarılı bir şekilde sona erdiğini işaret eder. Onaya yol açan yolları analiz etmek, en iyi uygulamaları belirlemeye yardımcı olur.

Nereden alınır

Başvuru vaka kaydında durumun 'Onaylandı' veya benzer bir son duruma ayarlandığı nihai bir durum güncellemesini arayın.

Yakala

Ana başvuru veya vaka tablosunda nihai, kesin bir durum değişikliği olarak kaydedilir.

Event tipi explicit
Başvuru Reddedildi
Müşterinin başvurusunu reddetmek için nihai karar kaydedilir. Bu, sonlandırma event'idir ve sistemde kesin bir durum değişikliği aracılığıyla yakalanır.
Neden önemli

Bu, birincil başarısızlık durumu son event'idir. Reddedilmelerin hangi aşamalarda gerçekleştiğini ve ilişkili nedenleri analiz etmek, süreç iyileştirme için hayati öneme sahiptir.

Nereden alınır

Başvuru kaydının son durum alanının 'Reddedildi', 'Ret Edildi' veya benzeri bir nihai duruma ayarlanmasından alınmıştır.

Yakala

Ana başvuru veya vaka tablosunda nihai, kesin bir durum değişikliği olarak kaydedilir.

Event tipi explicit
Evraklar Alındı
Müşterinin gerekli belgeleri sisteme yüklediğini veya sağladığını onaylar. Bu, genellikle belge gönderim portalı tarafından oluşturulan açık bir olay veya bir temsilci tarafından manuel bir giriştir.
Neden önemli

Bu aktivite, bir bekleme süresini sona erdirir ve sonraki inceleme aktivitelerini tetikler. Veri toplama aşamasında önemli bir kilometre taşıdır.

Nereden alınır

Belge yönetim sistemi günlüklerinden veya yeni belgeler eklendiğinde başvuru vaka dosyasındaki zaman damgalı bir girdiden alınmıştır.

Yakala

Bir belge başarıyla yüklendiğinde veya sistemde manuel olarak alındı olarak işaretlendiğinde olay günlüğe kaydedilir.

Event tipi explicit
Müşteri Kayıt Süreci Tamamlandı
Bu event, müşterinin tamamen aktif olduğunu doğrulayarak tüm kabul sürecinin başarılı bir şekilde sona erdiğini işaretler. Açık bir nihai durum olabilir veya 'Hesap Aktive Edildi' event'inden çıkarılabilir.
Neden önemli

Bu, birincil başarı durumu son event'idir. Başarılı bir şekilde kabul edilen tüm müşteriler için uçtan uca döngü süresini hesaplamak için esastır.

Nereden alınır

'Hesap Etkinleştirildi' zaman damgasından çıkarılır veya vaka dosyasındaki 'Kayıt Tamamlandı' gibi nihai, terminal bir durumdan yakalanır.

Yakala

Hesap aktivasyonu gibi son önemli olumlu olaydan veya nihai bir durum güncellemesinden çıkarılır.

Event tipi inferred
Risk Değerlendirmesi Gerçekleştirildi
Sistem, toplanan bilgilere ve yapılan kontrollere dayanarak müşteri için bir risk skoru hesaplar. Bu, LexisNexis'in temel bir özelliğidir ve genellikle vaka geçmişinde açık, otomatik bir event olarak kaydedilir.
Neden önemli

Bu değerlendirmenin sonucu genellikle, geliştirilmiş durum tespiti gerektirmesi gibi sonraki süreç yolunu belirler. Workflow'da kritik bir karar noktasıdır.

Nereden alınır

Başvurunun denetim logunda veya Workflow geçmişinde, risk puanlama veya değerlendirme modülünün tamamlandığını kaydeden bir event arayın.

Yakala

Risk motoru analizini tamamladığında ve bir risk profili veya puanı atadığında belirli bir olay günlüğe kaydedilir.

Event tipi explicit
Uyumluluk İncelemesi Başlatıldı
Bir vaka, genellikle yüksek riskli başvurular için, manuel inceleme için bir uyumluluk görevlisine veya ekibine atanır. Bu durum genellikle 'Uyumluluk İncelemesi Bekleniyor' durum değişikliğinden veya bir görev atama günlüğünden çıkarılır.
Neden önemli

Bu, manuel, çoğu zaman uzun süren bir inceleme adımının başlangıcını işaret eder. Bu noktadan tamamlanmaya kadar geçen süreyi ölçmek, uyumlulukla ilgili darboğazları niceliksel olarak belirlemeye yardımcı olur.

Nereden alınır

Bir görev atama günlüğünden, vaka sahipliğinin bir uyumluluk ekibine geçişinden veya vaka geçmişindeki bir durum güncellemesinden alınmıştır.

Yakala

'Uyumluluk İncelemesi Altında' gibi bir durum değişikliğinden veya vakanın uyumlulukla ilgili bir kullanıcı kuyruğuna atanmasından çıkarılır.

Event tipi inferred
Uyumluluk İncelemesi Tamamlandı
Uyum görevlisi incelemesini tamamlar ve bir tavsiyede bulunarak vakayı bir sonraki aşamaya taşır. Bu, bir görevin 'tamamlandı' olarak işaretlenmesiyle açıkça kaydedilebilir veya durum 'Uyum Bekleniyor'dan başka bir duruma değiştiğinde çıkarılabilir.
Neden önemli

Bu, sürecin kritik ve genellikle manuel bir bölümünü sonlandıran önemli bir kilometre taşıdır. Uyumluluk inceleme süresini ölçmek için bitiş noktasıdır.

Nereden alınır

Bir uyumluluk görevi tamamlanma zaman damgasından veya 'Uyumluluk İncelemesi Altında' durumundan çıkış durum değişikliğinden alınmıştır.

Yakala

İncelemenin bittiğini gösteren bir durum değişikliğinden çıkarılır, örneğin 'Onaylandı', 'Reddedildi' veya 'Nihai Karar'a geçiş.

Event tipi inferred
Belge İncelemesi Yapıldı
Bir kullanıcı veya otomatik bir araç, sunulan belgeleri orijinallik, geçerlilik ve eksiksizlik açısından inceler. Bu aktivite, 'Belgeler Alındı' durumundan 'İnceleme Tamamlandı' durumuna bir değişiklikten veya açık bir günlük girişinden çıkarılabilir.
Neden önemli

Bu, darboğazların ve yeniden işleme süreçlerinin yaygın bir kaynağıdır. İşlem süresini ve tekrarlarını analiz etmek, verimliliği artırmak ve otomasyon fırsatlarını belirlemek için anahtardır.

Nereden alınır

Belgeler Alındı' durumu ile 'Doğrulama Başarılı' veya 'Ek Bilgi Gerekli' gibi sonraki bir durum arasındaki süreyi takip ederek çıkarılır.

Yakala

Belge alma olayı ile incelemenin tamamlandığını işaret eden olay arasındaki süre olarak hesaplanır.

Event tipi inferred
Belgeler Talep Edildi
Sistem veya bir kullanıcı, müşteriden sürücü ehliyeti veya fatura gibi belirli belgeler talep eder. Bu event, sistem tarafından oluşturulan iletişim loglarından veya vakanın belge beklediğini gösteren bir durum değişikliğinden yakalanabilir.
Neden önemli

Bu aktivite genellikle sürece önemli bir bekleme süresi ekler. Sıklığını ve süresini analiz etmek, müşteri yanıt sürelerinden kaynaklanan gecikmeleri belirlemeye yardımcı olur.

Nereden alınır

Müşteriye gönderilen iletişim günlüklerinde bir olay veya başvuruda bir durum değişikliği olup olmadığını kontrol edin, örneğin 'Müşteri Belgeleri Bekleniyor'.

Yakala

'Belgeler Bekleniyor' durumuna bir değişiklikten veya giden iletişim günlüğü zaman damgasından çıkarılır.

Event tipi inferred
Ek Bilgi Talep Edildi
Bir uyumluluk görevlisi veya inceleyicisi, müşteriden daha fazla bilgi veya açıklama ister. Bu olay, yeniden işlemenin temel bir nedenidir ve genellikle açık bir durum değişikliği veya iletişim günlüğü girişi olarak kaydedilir.
Neden önemli

Bu aktivite, kabul döngüsü süresini uzatan yeniden işleme döngüleri oluşturur. Sıklığını izlemek, belirsiz gereksinimleri veya yaygın başvuru eksikliklerini belirlemeye yardımcı olur.

Nereden alınır

Durum değişikliğinin 'Müşteri Bilgileri Bekleniyor' olmasına veya giden bir iletişim event log'una bakın. Bu genellikle kullanıcı tarafından tetiklenen bir eylemdir.

Yakala

Bir temsilcinin vaka durumunu değiştiren ve bir iletişim event'ini kaydedebilen 'Bilgi İste' özelliğini kullandığında kaydedilir.

Event tipi explicit
Hesap Etkinleştirildi
Onayın ardından, müşterinin hesabı resmi olarak çekirdek bankacılık veya hizmet platformunda oluşturulur ve etkinleştirilir. Bu aktivite genellikle bir denetim izinde günlüğe kaydedilir veya hesap oluşturma tarihinden çıkarılır.
Neden önemli

Bu, müşteri için nihai değer teslim adımıdır. 'Başvuru Onaylandı' ile bu adım arasındaki gecikmeler sistem entegrasyon sorunlarını gösterebilir.

Nereden alınır

Bir hesap oluşturma günlüğünden, başka bir sisteme yapılan bir API çağrısından veya hesap kaydının kendi oluşturulma zaman damgasından alınmıştır.

Yakala

Onay sonrası ayrı bir event olarak kaydedilir veya müşteri kaydında bir aktivasyon timestamp'inin varlığıyla belirlenir.

Event tipi explicit
İlk Tarama Gerçekleştirildi
Sistem tarafından başvuru sonrası temel veri eksiksizliğini doğrulamak ve ön kontrolleri çalıştırmak için hemen yapılan otomatik bir kontrol. Bu aktivite genellikle süreç iş akışı geçmişinde açık, otomatik bir adım olarak günlüğe kaydedilir.
Neden önemli

En erken aşamada başarısız olan başvuruları belirler, veri kalitesi sorunlarını anlamaya yardımcı olur. Ayrıca süreçteki ilk otomatik katma değerli adımı işaretler.

Nereden alınır

Otomatik kural yürütme loglarını veya başvurunun Workflow geçmişinde ilk tarama adımının tamamlandığını gösteren bir durum değişikliğini arayın.

Yakala

Tamamlanmış otomatik bir görev veya vaka geçmişindeki belirli bir durum güncellemesi olarak kaydedilir.

Event tipi explicit
Kimlik Doğrulama Başlatıldı
Sistemin, LexisNexis hizmetlerini kullanarak (veri tabanlarını kontrol etmek gibi) temel kimlik doğrulama sürecini başlattığı noktayı temsil eder. Bu genellikle doğrulama hizmeti çağrıldığında açık bir event logu olarak kaydedilir.
Neden önemli

Bu aktivite, kritik ve genellikle zaman alıcı bir alt sürecin başlangıcını işaret eder. Süresini izlemek, kimlik kontrolleriyle ilgili darboğazları izole etmeye yardımcı olur.

Nereden alınır

Kimlik doğrulama modülüne yapılan API çağrı günlüklerinden veya doğrulama görevinin başlangıcını gösteren bir denetim izi girişinden alınmıştır.

Yakala

Sistemin kimlik doğrulama modülü veya API'si başvuru için tetiklendiğinde bir olay günlüğe kaydedilir.

Event tipi explicit
Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

Verilerinizi LexisNexis Risk Solutions'tan Nasıl Alırsınız?