KYC Müşteri Kabul Veri Şablonunuz
KYC Müşteri Kabul Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Veri Çekim Rehberliği
KYC Müşteri Kabul Nitelikleri
| 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
|
|||
KYC Müşteri Kabul 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
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
|
|||