KYC Müşteri Kimlik Doğrulama Veri Template'inuz
KYC Müşteri Kimlik Doğrulama Veri Template'inuz
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- Veri Çekim Kılavuzu
KYC Müşteri Edinimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite Adı
ActivityName
|
Kabul süreci sırasında belirli bir zamanda gerçekleşen spesifik görevin veya olayın 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 büyük önem taşır. 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 sunar. Aktiviteleri analiz etmek, süreçte ne olduğunu anlamanın anahtarıdır.
Neden Önemli?dir?
Bu nitelik, süreç haritasının temelini oluşturur, bu da müşteri kabul yolculuğundaki event dizisini görselleştirmenize ve analiz etmenize sunar.
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 olayları tutarlı bir vaka halinde gruplamak için gereklidir, bu da kabul süreç döngüsünün uçtan uca analizine sunar. Her başvuru sahibi için tüm süreç akışının yeniden yapılandırılmasını sunar, bu da döngü sürelerini hesaplamak, süreç varyantlarını analiz etmek ve bir başvurunun durumunu zaman içinde izlemek için büyük önem taşır.
Neden Önemli?dir?
Bu, temel Vaka ID'sidir. Bu olmadan, bir müşteri başvurusunun tüm sürecini 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 (case) tanımlayıcısıdır.
Örnekler:::::::
APP-2023-001, 2, 3, 4APP-2023-005678APP-2024-009101
|
|||
|
Olay Zaman Damgası
EventTimestamp
|
Belirli bir aktivitenin başladığı tam tarih ve saat. | ||
|
Açıklama
Bu zaman damgası (zaman damgası), bir aktivitenin başlangıcını işaret eder ve bir vaka içindeki tüm event'ler için kronolojik sırayı sunar. Process Mining'deki tüm zaman tabanlı analizlerin temelidir. Event zaman damgası (zaman damgası) 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 gereklidir.
Neden Önemli?dir?
Bu zaman damgası (zaman damgası), olayları kronolojik olarak sıralamak ve döngü süreleri ve darboğazlar gibi tüm zaman tabanlı metrikleri hesaplamak için gereklidir.
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 temel rol oynar. 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 sunar. Ayrıca belirli kullanıcı gruplarından kaynaklanan darboğazları belirlemeye de yardımcı olabilir.
Neden Önemli?dir?
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 büyük önem taşır.
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 büyük önem taşır. 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' Panellerinda kullanılır. Durumun zaman içinde nasıl değiştiğini analiz etmek, vaka süreç döngüsü hakkında önemli bilgi sunar.
Neden Önemli?dir?
Her başvurunun sonucunu izler, bu da Başvuru Reddetme Oranı gibi temel KPI'ları hesaplamak ve üretimi izlemek için gereklidir.
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ş Zamanı
EndTime
|
Bir aktivitenin tamamlandığı `tam tarih ve saat`. | ||
|
Açıklama
Bu zaman damgası (zaman damgası), 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 büyük önem taşır 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?dir?
Aktivite işleme süresinin doğru hesaplanmasını sunar, bu da verimsiz adımları belirlemek ve kaynak iş yükünü analiz etmek için gereklidir.
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 sunar. 'Kaynak Tahsisi ve İş Yükü' Dashboard'unda birincil bir boyuttur ve departmanlar arası verimsizlikleri veya iletişimdeki gecikmeleri belirlemeye yardımcı olur.
Neden Önemli?dir?
Süreç devirlerinin ve fonksiyonel alana göre performansın analiz edilmesini sunar, 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:::::::
ComplianceEdinim EkibiKYC AnalistleriMüşteri Desteği
|
|||
|
Risk Seviyesi
RiskLevel
|
Müşteri başvurusunun hesaplanan 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?dir?
Risk tabanlı analiz için büyük önem taşır, 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 işe alım 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 gereklidir. 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?dir?
Hizmet seviyesi anlaşmalarına (SLA) karşı performans ölçümünü sunar, 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 sunar. Performansın daha ayrıntılı bir görünümünü güçlüak için çoğu Dashboard'da kullanılan yaygın bir filtredir.
Neden Önemli?dir?
Sürecin güçlü bir şekilde bölümlendirilmesini sunar, 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 BireyTröst
|
|||
|
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 sunar.
Neden Önemli?dir?
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 olayın zaman damgası (zaman damgası)'inden son olayın zaman damgası (zaman damgası)'inin çıkarılmasıyla türetilen hesaplanmış bir metriktir.
Örnekler:::::::
5 gün 4 saat22 gün 8 saat1 gün 2 saat
|
|||
|
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 sunar.
Neden Önemli?dir?
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ü güçlüaya ve bir aktivitenin nasıl ve nerede kaydedildiği hakkında bağlam güçlüaya yardımcı olur.
Neden Önemli?dir?
Verinin kaynağını belirler, bu da veri yönetimi, doğrulama ve farklı BT sistemleri genelinde süreç yürütmesini anlamak için büyük önem taşır.
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?dir?
Bölgesel düzenlemelerin ve risk faktörlerinin süreç performansını nasıl etkilediğini anlamak için kritik olan yargısal analizi sunar.
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 aktivitenin sistem tarafından `otomatik` mi yoksa bir kullanıcı tarafından `manuel` mi gerçekleştirildiğini gösteren bir göstergedir. | ||
|
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?dir?
Manuel ve otomatik görevler arasında ayrım yapar, bu da otomasyon fırsatlarını belirlemek ve etkilerini ölçmek için temel rol oynar.
Nereden Alınır??
LexisNexis Risk Solutions belgelerine veya sistem yöneticisine danışın. Bu, event lognde 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 sunar. Ö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 temel rol oynar.
Neden Önemli?dir?
Müşteri kabulünün neden başarısız olduğuna dair doğrudan önemli bilgi sağlayarak, başvuru onay oranını artırmak için hedefe yönelik iyileştirmelere sunar.
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 sunar ve SLA'larını ihlal eden vakaların ortak özelliklerini anlamak için detaylı analizlere sunar.
Neden Önemli?dir?
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 zaman damgası (zaman damgası)'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ığı zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Bu nitelik, veri setinin en son ne zaman güncellendiğine dair bir zaman damgası (zaman damgası) sunar. 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 büyük önem taşır. Kararların gerektiği kadar güncel verilere dayanmasını sunar ve stratejik bilgilerin zamanında sağlanması konusundaki beklentileri yönetmeye yardımcı olur.
Neden Önemli?dir?
Veri güncelliği hakkında önemli bilgiler sağlayarak analizlerin ilgili olmasını ve kararların güncel olmayan bilgilere dayanmamasını sunar.
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 sunar. Bu nitelik, 'Uyumluluk İnceleme Süresi ve Birikim' Dashboard'u için temel rol oynar. 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?dir?
Uyumluluk fonksiyonuna odaklanmış önemli bilgi sunarak, bu kritik ve genellikle gecikmeli süreç aşamasındaki inceleyici iş yükünün ve performansının detaylı analizine sunar.
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 değeri, 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 büyük önem taşır. 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 sunar.
Neden Önemli?dir?
Süreçteki verimsizliği ve boşa harcanan çabayı doğrudan ölçülmesini sağlar, 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
|
|||
KYC Müşteri Edinimi Aktiviteleri
| 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?dir?
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 büyük önem taşır.
Nereden Alınır??
Sistem günlüklerinden veya yeni bir müşteri başvuru kaydının ilk oluşturulma zaman damgası (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?dir?
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?dir?
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 büyük önem taşır.
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?dir?
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 Edinimi 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' olayınden çıkarılabilir. | ||
|
Neden Önemli?dir?
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 gereklidir.
Nereden Alınır??
'Hesap Etkinleştirildi' zaman damgası (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 Yapıldı
|
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?dir?
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?dir?
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?dir?
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ı (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?dir?
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 temel rol oynar.
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?dir?
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ı (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?dir?
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 logna bakın. Bu genellikle kullanıcı tarafından tetiklenen bir eylemdir.
Yakala
Bir temsilcinin vaka durumunu değiştiren ve bir iletişim olayıni kaydedebilen 'Bilgi İste' özelliğini kullandığında kaydedilir.
Event tipi
explicit
|
|||
|
Hesap Aktive Edildi
|
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?dir?
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ı (zaman damgası)ndan alınmıştır.
Yakala
Onay sonrası ayrı bir event olarak kaydedilir veya müşteri kaydında bir aktivasyon zaman damgası (zaman damgası)'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?dir?
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?dir?
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
|
|||