KYC müşteri işe alımı Veri Şablonunuz
KYC müşteri işe alımı Veri Şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek temel faaliyetler
- Veri çıkarma yönlendirmesi
KYC Müşteri Kabulü Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Faaliyet adı
ActivityName
|
KYC müşteri kabul sürecinde gerçekleşen belirli bir iş olayının veya görevin adı. | ||
|
Açıklama
Etkinlik adı, müşteri işe alım yolculuğundaki tek bir adımı veya olayı açıklar. Örneğin 'Başvuru gönderildi', 'Analist incelemesi başlatıldı' veya 'Tarama tamamlandı - temiz'. Bu etkinlikler süreç haritasındaki düğümleri oluşturur ve uçtan uca iş akışının ayrıntılı bir dökümünü sunar. Etkinlikleri analiz etmek, Process Mining’in temelini oluşturur. Analistler farklı etkinliklerin sırasını ve sıklığını izleyerek gerçek süreç akışını keşfedebilir, yaygın yolları belirleyebilir, standart prosedürden sapmaları tespit edebilir ve gecikmeye veya yeniden çalışmaya neden olan belirli adımları ortaya çıkarabilir. Bu öznitelik, süreç haritaları oluşturmak ve etkinlik düzeyindeki metrikleri hesaplamak için gereklidir.
Neden önemli?
Bu öznitelik, sürecin tek tek adımlarını tanımlar. Süreç akışını keşfetmek, görselleştirmek ve darboğazları belirlemek için gereklidir.
Nereden alınır?
Bu bilgi genellikle Event Loglarda veya denetim izi tablolarında bulunur ve çoğu zaman vaka yönetimi varlığındaki durum değişiklikleriyle ilişkilidir.
Örnekler
Olası eşleşme belirlendiAnalist incelemesi başlatıldıYanlış pozitif doğrulandıBaşvuru onaylandı
|
|||
|
Müşteri başvurusu
CustomerApplication
|
Tek bir müşterinin müşteri kabul başvurusuna ait benzersiz tanımlayıcıdır ve birincil vaka tanımlayıcısı olarak kullanılır. | ||
|
Açıklama
Customer Application, tek bir müşterinin müşteri kabul süreciyle ilgili tüm olayları ve faaliyetleri gruplandıran merkezi vaka tanımlayıcısıdır. Her müşterinin ilk başvurudan nihai karara kadar Know Your Customer (KYC) sürecindeki ilerlemesini eksiksiz ve kronolojik biçimde izlemeyi sağlar. Process Mining analizinde bu öznitelik, her başvurunun uçtan uca yolculuğunu yeniden oluşturmak için temel niteliktedir. Süreç akışlarının görselleştirilmesini, toplam çevrim sürelerinin hesaplanmasını ve varyantların belirlenmesini sağlar. Kuruluşlar, tanımlayıcıya göre gruplandırılmış vakaları analiz ederek bir başvurunun izleyebileceği farklı yolları anlayabilir, darboğazları belirleyebilir ve çeşitli müşteri kabul süreçlerinin verimliliğini karşılaştırabilir.
Neden önemli?
İlgili tüm faaliyetleri birbirine bağlayan temel vaka tanımlayıcısıdır. Bu sayede uçtan uca müşteri kabul süreci analiz edilebilir.
Nereden alınır?
Bu tanımlayıcı, genellikle Refinitiv World-Check sistemindeki veya entegre bir CRM'deki ana başvuru ya da vaka yönetimi tablosunun birincil anahtarıdır.
Örnekler
APP-2023-00123APP-2023-00124APP-2023-00125
|
|||
|
Olay zamanı
EventTime
|
Belirli bir faaliyet veya olayın gerçekleştiğini gösteren zaman damgası. | ||
|
Açıklama
Olay zamanı, bir faaliyetin kaydedildiği kesin tarih ve saati gösterir. Bu zaman damgası, olayların doğru sıraya konulmasını ve vaka geçmişinin yeniden oluşturulmasını sağlayan kronolojik temeldir. Bu öznitelik, Process Mining'deki zamana dayalı tüm analizler için önemlidir. Faaliyetler arasındaki süreleri, yani çevrim ve bekleme sürelerini hesaplamak, toplam vaka süresini ölçmek, süreç performansını zaman içinde analiz etmek ve Hizmet Seviyesi Anlaşmalarına (SLA) uyumluluğu kontrol etmek için kullanılır. Doğru zaman damgaları olmadan süreç performansını anlamak ve zamana bağlı darboğazları belirlemek mümkün değildir.
Neden önemli?
Her faaliyet için zaman damgası, süreye dayalı tüm metrikleri hesaplamak, süreç sırasını keşfetmek ve darboğaz analizi yapmak için gereklidir.
Nereden alınır?
Bu, herhangi bir Event Log veya denetim izi tablosunda bulunan standart bir alandır. Genellikle 'Timestamp', 'EventDate' veya 'CreationDate' olarak adlandırılır.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
|
|||
|
Departman
DepartmentName
|
Faaliyeti gerçekleştirmekten sorumlu departman veya işlevsel ekip. | ||
|
Açıklama
Bu öznitelik, kullanıcının bağlı olduğu 'Müşteri kabulü', 'Uyumluluk' veya 'Kalite Güvencesi' gibi iş birimini ya da ekibi belirtir. Bireysel kullanıcıdan daha üst bir kurumsal düzeyde analiz yapılmasını sağlar. Departmana göre analiz, departmanlar arası darboğazları belirlemek ve devir sürelerini ölçmek için önemlidir. İşin farklı ekipler arasında nasıl aktığını ve bu geçişlerde gecikmelerin nerede oluştuğunu görselleştirmeye yardımcı olur. Bu görünüm, işlevler arası iş birliğini kolaylaştırmak ve genel süreç verimliliğini artırmak için büyük fayda sağlar.
Neden önemli?
Süreç performansının departman bazında analiz edilmesini sağlar ve farklı ekipler arasındaki devirlerde yaşanan gecikmeleri belirlemek için gereklidir.
Nereden alınır?
Bu bilgi, sistemde kullanıcının profiliyle veya ilişkili bir İK sistemiyle birlikte tutulabilir. Kullanıcı kimliği kullanılarak olay verileriyle birleştirilmesi gerekebilir.
Örnekler
Müşteri Kabul EkibiUyumluluk İncelemesiÜst Yönetim
|
|||
|
İnceleyen kimliği
ReviewerId
|
Faaliyeti gerçekleştiren kullanıcı, analist veya otomatik aracının tanımlayıcısı. | ||
|
Açıklama
İnceleyen kimliği veya kullanıcı, KYC sürecindeki belirli bir görevi kimin gerçekleştirdiğini gösterir. Bu kişi bir uyumluluk analisti, müşteri kabul uzmanı veya otomatik faaliyetler için kullanılan bir sistem hesabı olabilir. Bu bilginin izlenmesi, iş yükü dağılımı ve bireysel performans hakkında görünürlük sağlar. Bu öznitelik, kaynak temelli analiz için gereklidir. Kullanıcılar veya ekipler arasındaki performans farklarını anlamaya, eğitim ihtiyaçlarını belirlemeye ve iş yükü dengesini iyileştirmeye yardımcı olur. Ayrıca devirleri, sosyal ağları ve uyumluluk kaynaklarının kullanımını analiz etmek için temel bileşenlerden biridir.
Neden önemli?
İş yükü dağılımının, kullanıcı performansının ve departmanlar arası devirlerin analiz edilmesini sağlar. Bu, kaynakların verimli kullanılması için önemlidir.
Nereden alınır?
Genellikle Event Loglarda veya denetim izlerinde bulunur ve çoğu zaman 'UserID', 'PerformedBy' veya 'Owner' olarak adlandırılır.
Örnekler
analyst_jdoesystem_auto_screenermanager_bsmith
|
|||
|
Olay bitiş zamanı
EventEndTime
|
Belirli bir faaliyet veya olayın tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
Olay bitiş zamanı, bir faaliyetin tamamlandığı anı gösterir. Birçok olay anlık olarak modellenebilir ve BaşlangıçZamanı ile BitişZamanı birbirine eşit olabilir. Ancak 'Analist incelemesi başlatıldı' ve 'Analist incelemesi tamamlandı' gibi bazı faaliyetlerin ölçülebilir bir süresi vardır. Başlangıç ve bitiş zamanlarının birlikte tutulması, işlem süresinin hassas biçimde ölçülmesini sağlar. Süreç analizinde bitiş zamanının bulunması, bekleme süresini de içeren çevrim süresinden farklı olarak faaliyetin kesin işlem süresini hesaplamak için gereklidir. Bu sayede vakanın aktif olarak işlendiği süre ile kuyrukta beklediği süre birbirinden ayrılabilir. Bu ayrım, kaynakların verimli kullanılması ve verimlilik analizleri için önemlidir.
Neden önemli?
Faaliyetin işlem süresinin hassas biçimde hesaplanmasını sağlar. Daha doğru performans analizi için aktif çalışma süresini boşta bekleme süresinden ayırır.
Nereden alınır?
Süreye sahip faaliyetlerde bu bilgi, Event Log veya denetim izi tablolarında 'CompletionDate' ya da 'EndDate' gibi ayrı bir alanda tutulabilir.
Örnekler
2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
|
|||
|
Risk seviyesi
RiskLevel
|
Müşteri başvurusuna ait hesaplanan risk sınıflandırmasıdır. Örneğin Düşük, Orta veya Yüksek. | ||
|
Açıklama
Risk düzeyi, KYC süreçlerinde gereken durum tespiti düzeyini belirleyen önemli bir bilgidir. Genellikle müşteri türü, coğrafya ve işletmenin niteliği gibi etkenlere göre belirlenir. Bu sınıflandırma, bir başvurunun izleyeceği süreç yolunu önemli ölçüde etkileyebilir. Süreç analizinde vakaları risk düzeyine göre bölümlere ayırmak önemlidir. Bu yaklaşım, çevrim süreleri ve süreç akışlarındaki farklılıkları açıklamaya yardımcı olur. Örneğin yüksek riskli başvurular daha fazla adım gerektirebilir ve daha uzun sürebilir. Bu öznitelik, riskin sonuçları ve verimliliği nasıl etkilediğini anlamak için 'Başvuru ret oranı ve nedenleri' Dashboardu ile 'Arka plan kontrolü başlatma çevrim süresi' Dashboardu açısından temel öneme sahiptir.
Neden önemli?
Süreci risk seviyesine göre bölümlere ayırmak, bazı vakaların neden daha uzun sürdüğünü veya farklı yollar izlediğini anlamak ve ret oranlarını analiz etmek için önemlidir.
Nereden alınır?
Bu, müşteri başvurusunda veya vaka kaydında bulunan temel bir veri noktasıdır. Refinitiv World-Check'teki vaka yönetimi modülünü inceleyin.
Örnekler
DüşükOrtaYüksek
|
|||
|
SLA hedef tarihi
SlaTargetDate
|
Müşteri kabul sürecinin tamamlanması gereken hedef tarih. | ||
|
Açıklama
SLA hedef tarihi, müşteriyle yapılan hizmet seviyesi anlaşmasında veya kurum içi politikalarda tanımlanan, tüm işe alım vakasının tamamlanması gereken son tarihtir. Gerçek tamamlanma süreleri bu tarihle karşılaştırılır. Bu öznitelik, 'SLA uyumu ve ihlal analizi' Dashboardu için temel oluşturur. Bir vakanın zamanında tamamlanıp tamamlanmadığını hesaplamak için kullanılır. SLA ihlallerini analiz etmek, gecikmelere neden olan sistemik sorunları belirlemeye yardımcı olur. Böylece kuruluş, zamanında tamamlanma oranını artırmak ve uyumluluk gerekliliklerini karşılamak için düzeltici önlemler alabilir.
Neden önemli?
Zamanında performans ölçümünün temelidir. SLA uyum oranını hesaplamak ve ihlalleri analiz etmek için gereklidir.
Nereden alınır?
Bu tarih genellikle başvurunun gönderilme tarihine ve iş kurallarına göre hesaplanır. Vaka kaydında bir alan olarak tutulabilir.
Örnekler
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
|
|||
|
Başvuru kanalı
ApplicationChannel
|
Müşteri başvurusunun gönderildiği kanal. Örneğin Çevrim içi Portal, Şubeden veya Mobil Uygulama. | ||
|
Açıklama
Başvuru kanalı, müşteri başvurusunun gönderildiği kaynağı gösterir. Farklı kanalların veri eksiksizliği, veri kalitesi ve müşteri demografisi farklı olabilir. Bu farklılıklar sonraki süreci etkileyebilir. Bu öznitelik, 'Kanala göre başvuru hacmi' Dashboardu için gereklidir. Farklı kanallardan gelen başvuruların hacmini, çevrim süresini ve sonuçlarını analiz ederek hangi kanalların daha verimli olduğunu, hangilerinde süreç iyileştirmeleri gerektiğini belirleyebilirsiniz. Bu analiz, kaynak dağılımı ve kanal yatırımıyla ilgili stratejik kararları destekler.
Neden önemli?
Farklı başvuru kanallarının performansını ve verimliliğini analiz etmeye yardımcı olur. Teknoloji ve müşteri deneyimiyle ilgili stratejik kararlar için bilgi sağlar.
Nereden alınır?
Bu bilgi genellikle sürecin başında alınır ve başvuru kaydında bir öznitelik olarak saklanır.
Örnekler
Çevrim İçi PortalMobil UygulamaŞubedeMüşteri İlişkileri Yöneticisi
|
|||
|
Eşleşme kimliği
MatchId
|
World-Check taraması sırasında bulunan olası eşleşmeye ait benzersiz tanımlayıcı. | ||
|
Açıklama
Otomatik tarama süreci yaptırım listelerinde, PEP listelerinde veya olumsuz medyada olası bir eşleşme bulduğunda, belirli bulguyu izlemek için genellikle bir Eşleşme kimliği oluşturulur. Bu kimlik, başvuru vakasını World-Check veri tabanında uyarıyı tetikleyen belirli kayda bağlar. Bu öznitelik, ayrıntılı uyumluluk analizi için kullanışlıdır. Analistlerin eşleşmelerin niteliğini incelemesini, belirli uyarıların sonuçlandırılmasını izlemesini, örneğin yanlış pozitif veya gerçek eşleşme olarak doğrulanmasını ve hangi uyarı türlerinin daha yaygın olduğunu ya da sonuçlandırılmasının daha uzun sürdüğünü anlamasını sağlar. 'Olası eşleşme belirlendi' faaliyeti hakkında daha ayrıntılı bilgi sunar.
Neden önemli?
Belirli tarama sonuçlarına ayrıntılı bir bağlantı sağlar. Eşleşme sonuçlandırma sürelerinin ve uyarı türlerinin daha derinlemesine analiz edilmesini mümkün kılar.
Nereden alınır?
Bu kimlik, World-Check tarama motoru tarafından oluşturulur ve olası eşleşme bulunduğunda başvuru vakasına karşı kaydedilir.
Örnekler
WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
|
|||
|
Kaynak sistem
SourceSystem
|
Olay verilerinin çıkarıldığı sistemdir. Bu örnekte kaynak sistem Refinitiv World-Check'tir. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynağını tanımlar. Tek kaynaklı bir veri aktarımında sabit bir değer olabilir. Ancak CRM ve World-Check gibi birden fazla sistemden alınan veriler bütünsel bir süreç görünümü oluşturmak üzere birleştirildiğinde büyük önem taşır. Analizde veri yönetişimine, sorun gidermeye ve verilerin bağlamını anlamaya yardımcı olur. Örneğin, ana tarama sistemine kaydedilen faaliyetlerin özellikleri veya ayrıntı düzeyi, çevre sistemlerden alınanlardan farklı olabilir. Böylece veri soyu açık ve denetlenebilir kalır.
Neden önemli?
Verilerin kaynağını tanımlar. Veri yönetişimi, doğrulama ve birden fazla kaynaktan gelen verilerin birleştirilmesi için önemlidir.
Nereden alınır?
Bu, genellikle Veri Seti'ni etiketlemek için veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde eklenen statik bir değerdir.
Örnekler
Refinitiv World-CheckWorldCheckOne
|
|||
|
Müşteri kimliği
CustomerId
|
Müşteri kabul sürecine alınan müşteri varlığına ait benzersiz tanımlayıcı. | ||
|
Açıklama
Müşteri kimliği, müşteri profilinin benzersiz tanımlayıcısıdır. Customer Application ID'den farklıdır, çünkü bir müşteri zaman içinde birden fazla başvuru gönderebilir. Bu öznitelik, müşteri kabul sürecini ana müşteri kaydına bağlar. Analizde Müşteri kimliği, aynı müşterinin tekrarlanan başvurularının izlenmesini sağlar. Ayrıca CRM'den veya ana veri sisteminden alınan diğer müşteri öznitelikleriyle süreç verilerinin zenginleştirilmesinde kullanılabilir. Böylece tek bir müşteri kabul örneğinin ötesinde daha bütünsel bir müşteri yolculuğu görünümü elde edilir.
Neden önemli?
Müşteri kabul vakasını belirli bir müşteriye bağlar. Tekrarlanan başvuruların analiz edilmesini ve ana müşteri verileriyle zenginleştirilmesini sağlar.
Nereden alınır?
Bu, başvuru veya vaka kaydında bulunan ve kaydı müşteri ana verilerine bağlayan temel bir alandır.
Örnekler
CUST-98765CUST-98766CUST-98767
|
|||
|
Müşteri türü
CustomerType
|
Müşterinin Bireysel, Şirket veya Trust gibi sınıflandırması. | ||
|
Açıklama
Müşteri türü, işe alınan varlığı sınıflandırır. Farklı müşteri türlerinin işe alım gereksinimleri, risk profilleri ve düzenleyici yükümlülükleri farklı olabilir. Örneğin bir şirketin işe alınması, genellikle bir bireyin işe alınmasından daha karmaşıktır. Bu öznitelik, özellikle 'KYC müşteri türü performansı' Dashboardu için segmentasyon analizinde kullanılır. Farklı müşteri segmentleri arasındaki süreç verimliliğini, çevrim sürelerini ve ret oranlarını karşılaştırmanıza olanak verir. Böylece kuruluşlar işe alım deneyimini belirli müşteri türlerine göre uyarlayıp optimize edebilir.
Neden önemli?
Farklı müşteri segmentleri arasında performans karşılaştırması yapılmasını sağlar ve müşteri kabul sürecinin her türe göre uyarlanmasına ve iyileştirilmesine yardımcı olur.
Nereden alınır?
Bu, kaynak sistemdeki müşteri veya başvuru kaydında tutulan temel bir özniteliktir.
Örnekler
BireyselŞirketKâr Amacı Gütmeyen KuruluşVakıf
|
|||
|
Müşteri ülkesi
CustomerCountry
|
Müşterinin ikamet ettiği veya kuruluşunun bulunduğu ülke. | ||
|
Açıklama
Bu öznitelik, müşterinin coğrafi konumunu gösterir. Ülke, KYC süreçlerinde risk değerlendirmesi ve düzenleyici gereksinimler açısından önemli bir faktördür. Farklı yargı bölgelerindeki kurallar değişebilir ve bu durum süreç akışını ve süresini etkileyebilir. Sürecin ülkeye göre analiz edilmesi, kuruluşların farklı bölgelerdeki performansı karşılaştırmasına, konuma özgü darboğazları belirlemesine ve yerel düzenlemelere uyumluluğu sağlamasına yardımcı olur. Süreç analizine coğrafi bir boyut kazandırarak önemli operasyonel farklılıkları ortaya çıkarabilir.
Neden önemli?
Sürecin coğrafi olarak analiz edilmesini sağlar. Performans, risk ve uyumluluk gereksinimlerindeki bölgesel farklılıkların belirlenmesine yardımcı olur.
Nereden alınır?
Bu, müşteri profilinde veya başvuru formunda bulunan standart bir alandır.
Örnekler
USAGBRSGPDEU
|
|||
|
Otomatik mi
IsAutomated
|
Faaliyetin bir sistem tarafından mı (true) yoksa bir insan tarafından mı (false) gerçekleştirildiğini gösteren işaret. | ||
|
Açıklama
Bu boolean öznitelik, otomatik sistem görevleri ile kullanıcılar tarafından gerçekleştirilen manuel faaliyetleri birbirinden ayırır. Örneğin, “Otomatik Tarama Gerçekleştirildi” otomatik, “Analist İncelemesi Başlatıldı” ise manuel olarak işaretlenir. Bu ayrım, otomasyon analizinde büyük önem taşır. Otomasyonun süreç verimliliği üzerindeki etkisini ölçmenize, gelecekte otomasyona uygun manuel görevleri belirlemenize ve insanlarla sistem aktörleri arasındaki etkileşimi anlamanıza yardımcı olur. Böylece sistem işleme süresi ile manuel işlem süresini net biçimde ayırabilirsiniz.
Neden önemli?
Sistem faaliyetleri ile insan faaliyetlerini birbirinden ayırır. Bu, otomasyonun etkisini ölçmek ve yeni otomasyon fırsatlarını belirlemek için önemlidir.
Nereden alınır?
Bu değer genellikle faaliyet adına veya olayla ilişkilendirilmiş kullanıcı kimliğine göre belirlenir. Örneğin, kullanıcı bir “system” hesabıysa.
Örnekler
truefalse
|
|||
|
Ret nedeni
RejectionReason
|
Müşteri başvurusu reddedildiğinde belirtilen özel neden. | ||
|
Açıklama
Bir başvuru reddedildiğinde ret nedeni, bu kararın neden verildiğini açıklar. Nedenler arasında 'Yaptırım eşleşmesi', 'Eksik belge' veya 'Yüksek risk profili' bulunabilir. Bu bilgi, gelen başvuruların kalitesi ve tarama sürecinin verimliliği hakkında değerli ve yapılandırılmış geri bildirim sağlar. Bu öznitelik, 'Başvuru ret oranı ve nedenleri' Dashboardunun temelini oluşturur. Bu nedenleri analiz etmek, retlerin temel nedenlerini belirlemeye yardımcı olur. Böylece süreç iyileştirmeleri yapılabilir, başvuru sahipleriyle iletişim netleştirilebilir ve gereksiz retler azaltılabilir. Nicel ret oranı KPI’ına nitel bağlam sağlar.
Neden önemli?
Başvuruların reddedilmesindeki temel nedeni ortaya koyar. Ret oranını azaltmak için müşteri kabul sürecinde iyileştirilmesi gereken alanları belirlemek açısından önemlidir.
Nereden alınır?
'Başvuru reddedildi' olayı gerçekleştiğinde, büyük olasılıkla vaka veya başvuru kaydındaki bir alan olarak kaydedilir.
Örnekler
PEP EşleşmesiYaptırım Listesi BulgusuBelge Doğrulama BaşarısızOlumsuz Medya İçeriği
|
|||
|
SLA ihlal edildi
SlaBreached
|
Onboarding vakasının SLA Hedef Tarihi’nden sonra tamamlanıp tamamlanmadığını gösteren boolean işaretidir. | ||
|
Açıklama
Bu öznitelik, bir vakanın Hizmet Seviyesi Anlaşmasını ihlal edip etmediğini gösteren hesaplanmış bir işarettir. Vakanın son tamamlanma etkinliğinin zaman damgası, örneğin 'Başvuru onaylandı' veya 'Başvuru reddedildi', vaka için tanımlanan 'SlaTargetDate' ile karşılaştırılarak belirlenir. Bu işaret, 'SLA uyumu ve ihlal analizi' Dashboardunun ve 'SLA uyum oranı' KPI’ının temelini oluşturur. Kullanıcıların ihlal edilmiş tüm vakaları hızlıca filtrelemesini sağlayarak analizi kolaylaştırır. İhlal edilen vakaların süreç özelliklerini analiz eden kuruluşlar, gecikmelerin temel nedenlerini belirleyebilir ve iyileştirme çalışmalarını etkili biçimde yönlendirebilir.
Neden önemli?
Service Level Agreement uyumluluğunu doğrudan ölçer, geciken vakaları kolayca filtrelemenizi ve temel neden analizi yapmanızı sağlar.
Nereden alınır?
Veri dönüşümü sırasında, bir vakanın son faaliyet zaman damgası SlaTargetDate alanıyla karşılaştırılarak hesaplanır.
Örnekler
truefalse
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Bu olaya ait verilerin kaynak sistemden son kez yenilendiği veya çıkarıldığı zaman damgası. | ||
|
Açıklama
Bu öznitelik verilerin güncelliğini gösterir. Refinitiv World-Check’ten son veri çekiminin tarihini ve saatini kaydeder. Process Mining panolarının ve analizlerinin ne kadar güncel olduğunu anlamak için önemlidir. Analiz amacıyla bu bilgi, kullanıcıların neredeyse gerçek zamanlı verilere mi yoksa belirli bir zamandaki anlık görüntüye mi baktığını anlamasını sağlar. Veri yönetişimi ve sunulan içgörülerin güncelliğiyle ilgili kullanıcı beklentilerini yönetmek için gereklidir.
Neden önemli?
Verilerin güncelliği hakkında önemli bağlam sağlar ve kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasına yardımcı olur.
Nereden alınır?
Bu zaman damgası, veri çıkarma (ETL) sürecinde oluşturulur ve eklenir.
Örnekler
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Yeniden işleme mi
IsRework
|
Bir faaliyetin aynı vaka içinde ikinci veya daha sonraki kez gerçekleştirilip gerçekleştirilmediğini gösteren işarettir. | ||
|
Açıklama
IsRework, aynı müşteri başvurusu vakası içinde bir etkinliğin tekrarlandığını belirleyen hesaplanmış bir boolean özniteliğidir. Örneğin tek bir başvuru için 'Risk değerlendirmesi yapıldı' etkinliği birden fazla kez gerçekleşirse sonraki oluşumlar yeniden çalışma olarak işaretlenir. Bu öznitelik, süreç verimsizliklerini, döngüleri ve gereksiz tekrarları belirlemek için önemlidir. 'Risk değerlendirmesinde yeniden çalışma ve verimlilik' Dashboardunu ve 'Risk değerlendirmesinde yeniden çalışma oranı' KPI’ını doğrudan destekler. Yeniden çalışmayı analiz etmek, kalite, bilgi netliği veya karar alma sorunlarını ortaya çıkarmaya yardımcı olur. Bu sorunlar boşa harcanan çalışmaya ve daha uzun çevrim sürelerine yol açar.
Neden önemli?
Tekrarlanan faaliyetleri işaretleyerek süreç verimsizliklerini görünür kılar, yeniden işleme döngülerini analiz etmenizi, kaliteyi artırmanızı ve çevrim sürelerini kısaltmanızı sağlar.
Nereden alınır?
Veri dönüşümü sırasında, her vakadaki faaliyet dizisi analiz edilerek bir faaliyetin ilk gerçekleşmesinden sonraki tüm tekrarları işaretlenir.
Örnekler
truefalse
|
|||
KYC Müşteri Kabulü Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Analist incelemesi başlatıldı
|
Uyumluluk analisti, müşteri başvurusu için olası eşleşmeleri manuel olarak incelemeye başlar. Bu işlem, olası eşleşmelerin ayrıntılarının müşteri bilgileriyle karşılaştırılarak ilgili olup olmadığının belirlenmesini içerir. | ||
|
Neden önemli?
Bu, manuel uyumluluk incelemesinin başlangıcını gösterir ve sık görülen bir darboğazdır. 'Olası eşleşme belirlendi' ile bu faaliyet arasındaki sürenin ölçülmesi kuyrukta bekleme gecikmelerini ortaya çıkarır. İnceleme süresi ise analist verimliliğini gösterir.
Nereden alınır?
Bir analistin inceleme kuyruğundan vakayı 'üzerine alması' veya açmasıyla çıkarılabilir. Vaka durumu 'İncelemede' olarak değiştiğinde ya da vaka belirli bir kullanıcıya atandığında sistem bu olayı denetim izine açıkça kaydedebilir.
Yakalayın
Vaka durumunun 'İnceleniyor' olarak değişmesinden veya vakanın bir analiste atanmasından çıkarılır.
Olay türü
inferred
|
|||
|
Başvuru gönderildi
|
Bu aktivite, müşterinin başvurusunu göndermesiyle KYC müşteri kabul sürecinin başladığını gösterir. Bu olay genellikle bir CRM veya temel uygulama sisteminde kaydedilir ve ardından Refinitiv World-Check'te tarama sürecini tetikler. | ||
|
Neden önemli?
Bu, uçtan uca müşteri kabul yolculuğunun temel başlangıç olayıdır. Bu noktadan tamamlanmaya kadar geçen süreyi analiz etmek, müşteri deneyimini ve SLA uyumunu ölçmek için önemli olan genel müşteri kabul çevrim süresini gösterir.
Nereden alınır?
Bu olay World-Check'e özgü değildir. CRM veya müşteri hesap yönetimi platformu gibi bir üst sistemden alınmalı ve Customer Application ID ile ilişkilendirilmelidir.
Yakalayın
İlk başvuru gönderildiğinde kaynak uygulama sistemine kaydedilen olay.
Olay türü
explicit
|
|||
|
Başvuru reddedildi
|
Müşteri başvurusu, çoğu zaman World-Check'te 'Eşleşme Bulundu' sonucu alınması veya diğer risk faktörleri nedeniyle resmî olarak reddedilir. Bu olay, müşteri kabul sürecinin nihai olumsuz sonucudur. | ||
|
Neden önemli?
Bu, sürecin başlıca başarısızlık bitiş noktasıdır. Özellikle ret nedenleri ve öncesindeki faaliyetler incelenerek gereksiz retlerin azaltılması ve sürecin iyileştirilmesi sağlanabilir.
Nereden alınır?
Bu nihai iş kararı World-Check'in kendisine değil, üst CRM'e veya ana uygulama sistemine kaydedilir. Veriler bu sistemden alınmalıdır.
Yakalayın
Kaynak uygulama sistemine, çoğu zaman ilgili ret nedeni koduyla birlikte kaydedilen olay.
Olay türü
explicit
|
|||
|
Gerçek eşleşme doğrulandı
|
Analist, olası eşleşmenin gerçekten taranan müşteri olduğunu doğrulayarak olası bir risk belirler. Bu önemli kilometre taşı, genellikle daha ayrıntılı durum tespiti yapılmasını veya başvurunun reddedilmesini tetikler. | ||
|
Neden önemli?
Bu, risk azaltma açısından önemli bir sonuç ve süreçte belirleyici bir andır. Müşteri başvurusuyla ilgili nihai kararı doğrudan etkiler ve uyumluluk raporlaması ile analizi için büyük önem taşır.
Nereden alınır?
Analistin belirli bir eşleşmeyi 'Gerçek Eşleşme' veya 'Doğrulanmış Eşleşme' olarak sonuçlandırdığı açık bir kullanıcı işlemidir. Bu olay, vaka denetim izine kaydedilir.
Yakalayın
Bir analist sistemde eşleşmeyi resmî olarak doğruladığında kaydedilir.
Olay türü
explicit
|
|||
|
Hesap etkinleştirildi
|
Müşterinin hesabı ana sistemde oluşturulur ve etkinleştirilir. Böylece müşteri kabul süreci tamamlanır. Bu işlem, nihai başvuru onayının ardından gerçekleşir ve hesabı kullanıma hazır hâle getirir. | ||
|
Neden önemli?
Bu, süreçte değer sağlayan son adımdır. Başvurunun gönderilmesinden hesabın etkinleştirilmesine kadar geçen süre, operasyonel verimlilik ve müşteri memnuniyeti için önemli bir metriktir.
Nereden alınır?
Bu olay World-Check'te yakalanmaz. Ana bankacılık veya müşteri hesap sistemine kaydedilir ve Customer Application ID ile ilişkilendirilmelidir.
Yakalayın
Hesap etkinleştirildiğinde ana hesap sistemine kaydedilen olay.
Olay türü
explicit
|
|||
|
Tarama talebi oluşturuldu
|
Refinitiv World-Check sistemi içinde bir müşteri başvurusu için yeni bir tarama vakası resmi olarak oluşturulur. Bu işlem, üst sistemden gelen bir API çağrısı veya manuel girişle tetiklenir ve risk istihbaratı kontrolünün başlangıcını gösterir. | ||
|
Neden önemli?
Bu, tarama alt sürecinin resmi başlangıcını gösterir. Application Submitted ile bu aktivite arasındaki süre, iş birimi sistemi ile uyumluluk işlevi arasındaki devirlerde yaşanan gecikmeleri ortaya çıkarır.
Nereden alınır?
World-Check vaka yönetimi günlüklerinde veya denetim izinde kaydedilir. Belirli vaka veya varlık kimliği için oluşturma olayı ve zaman damgası kullanılır.
Yakalayın
Sistemde yeni bir tarama vakası oluşturulduğunda otomatik olarak kaydedilir.
Olay türü
explicit
|
|||
|
Tarama tamamlandı - Eşleşme bulundu
|
Tarama vakası, doğrulanmış bir risk bulunduğunu belirten 'Eşleşme Bulundu' sonucuyla resmî olarak kapatılır. Bu karar, ayrıntılı durum tespiti veya başvurunun reddedilmesi gibi farklı bir sonraki süreci tetikler. | ||
|
Neden önemli?
Bu, tarama sürecinin başlıca olumsuz akış bitiş noktasıdır. Bu vakaların analizi, risk profillerinin ve tarama kontrollerinin etkinliğinin anlaşılmasına yardımcı olur.
Nereden alınır?
Nihai vaka durumunun 'Eşleşme Bulundu', 'Risk Belirlendi' veya 'Kapatıldı - Pozitif' olarak değişmesinden çıkarılır. Bu son durum değişikliğinin zaman damgası kullanılır.
Yakalayın
Doğrulanmış eşleşmeyi gösteren nihai vaka durumunun zaman damgasından türetilir.
Olay türü
inferred
|
|||
|
Tarama tamamlandı - Temiz
|
Tarama vakası, gerçek eşleşme bulunmadığını belirten 'Temiz' sonucuyla resmî olarak kapatılır. Bu karar, başvurunun başlatıldığı sisteme iletilerek müşteri kabul sürecinin devam etmesini sağlar. | ||
|
Neden önemli?
Bu faaliyet, tarama sürecinin başarılı ve beklenen akışa uygun şekilde tamamlandığını gösterir. Standart ve düşük riskli başvuruların çevrim süresini ölçmek için önemli bir bitiş noktasıdır.
Nereden alınır?
Nihai vaka durumunun 'Temiz', 'Tamamlandı' veya 'Kapatıldı - Eşleşme Yok' olarak değişmesinden çıkarılır. Bu son durum değişikliğinin zaman damgası kullanılır.
Yakalayın
Temiz sonucu gösteren nihai vaka durumunun zaman damgasından türetilir.
Olay türü
inferred
|
|||
|
Başvuru onaylandı
|
Müşteri başvurusu, başarılı bir KYC taraması ve gerekli diğer kontrollerin ardından tamamen onaylanmıştır. Bu olay genellikle World-Check'ten 'Temiz' sonucu alındıktan sonra kaynak sistemde gerçekleşir. | ||
|
Neden önemli?
Bu, müşteri kabul sürecinin başarılı iş sonucunu gösterir. Başvurunun gönderilmesinden bu noktaya kadar geçen sürenin izlenmesi, yeni bir müşteri için toplam 'olumlu yanıt süresini' ortaya çıkarır.
Nereden alınır?
Bu olay World-Check'e özgü değildir. Nihai iş kararını veren üst CRM'den veya ana uygulama sisteminden alınmalıdır.
Yakalayın
Nihai onay verildiğinde kaynak uygulama sistemine kaydedilen olay.
Olay türü
explicit
|
|||
|
Ek bilgi istendi
|
Analist, olası eşleşmeyi sonuçlandırmak için daha fazla bilgi gerektiğine karar verir ve bu bilgiyi iş biriminden ister. Bilgi sağlanana kadar vaka beklemede kalır. | ||
|
Neden önemli?
Bu faaliyetin sık tekrarlanması, tarama için sağlanan ilk verilerin kalitesiyle ilgili sorunlara işaret eder. Faaliyet dış ekiplerin yanıtına bağlı olduğu için önemli gecikmelere yol açar ve uzun çevrim sürelerinin başlıca nedenlerinden biridir.
Nereden alınır?
Bu, vaka notlarına veya denetim günlüğüne kaydedilen açık bir kullanıcı işlemi olabilir. Alternatif olarak vaka durumunun 'Bilgi Bekleniyor' veya 'RFI' olarak değişmesinden çıkarılabilir.
Yakalayın
Bir analist, vakayı daha fazla bilgi gerektiğini belirtecek şekilde işaretlemek için bir Özellik kullandığında kaydedilir.
Olay türü
explicit
|
|||
|
Olası eşleşme belirlendi
|
Otomatik tarama süreci, bir analistin manuel incelemesini gerektiren bir veya daha fazla olası eşleşme bulmuştur. Bu olay, vakayı otomatik durumdan manuel inceleme kuyruğuna taşır. | ||
|
Neden önemli?
Bu faaliyet, süreçte önemli bir ayrım noktasıdır. Olası eşleşme bulunan vakalar daha uzun ve karmaşık bir yolu izler. Bu faaliyetin izlenmesi, inceleme ekibi için kaynak planlamasına ve darboğaz analizine yardımcı olur.
Nereden alınır?
World-Check vaka yönetimi modülünde vaka durumunun 'İnceleme Gerekli', 'Olası Eşleşme' veya benzer bir duruma değişmesinden çıkarılır.
Yakalayın
Manuel incelemenin artık gerekli olduğunu gösteren vaka durumu değişikliğinden çıkarılır.
Olay türü
inferred
|
|||
|
Otomatik tarama gerçekleştirildi
|
World-Check sistemi, müşterinin bilgilerini risk istihbaratı veritabanına karşı otomatik olarak tarar. Bu, olası eşleşmeler veya temiz durum gibi ilk sonuçları üreten sistem odaklı bir aktivitedir. | ||
|
Neden önemli?
Bu faaliyet, tarama sürecindeki ilk katma değer sağlayan adımdır. Bu noktadan önce yaşanan gecikmeler sistem veya veri hazırlığıyla ilgili sorunlara işaret ederken sonuç, sonraki manuel iş yükünü belirler.
Nereden alınır?
Bu olay, vaka denetim izine açıkça kaydedilebilir veya ilk tarama sonuçlarının vaka için kullanılabilir hâle geldiği zaman damgasından çıkarılabilir.
Yakalayın
Otomatik veri tabanı taraması tamamlandığında oluşturulan sistem günlüğü kaydı.
Olay türü
explicit
|
|||
|
Vaka inceleme için üst kademeye aktarıldı
|
Birinci seviye analist, karmaşık veya yüksek riskli bir vakayı nihai karar için kıdemli analiste ya da yöneticiye aktarır. Bu, uyumluluk ekibi içindeki önemli bir devir noktasıdır. | ||
|
Neden önemli?
Üst kademeye aktarımlar çoğu zaman darboğaz oluşturur ve çevrim süresini artırır. Aktarımların sıklığı ve nedenleri incelendiğinde, kıdemsiz analistler için eğitim ihtiyaçları veya inceleme politikalarındaki belirsizlikler ortaya çıkabilir.
Nereden alınır?
Vaka iş akışında veya denetim izinde açık bir işlem olarak kaydedilir. Özellikle daha yüksek yetkilere sahip bir kullanıcı olmak üzere, vakaya atanan kullanıcının değişmesiyle de anlaşılabilir.
Yakalayın
Vaka içindeki özel 'Üst kademeye aktar' düğmesi veya Workflow işlemi aracılığıyla kaydedilir.
Olay türü
explicit
|
|||
|
Yanlış pozitif doğrulandı
|
Analist, olası eşleşmenin taranan müşteriyle aynı kişi veya kuruluş olmadığı sonucuna varır. Eşleşme reddedilir ve ilgili uyarı için tarama süreci sonuçlandırılır. | ||
|
Neden önemli?
Bu, inceleme sürecinde sık görülen bir sonuçtur. Yanlış pozitiflerin sonuçlandırılmasının ne kadar sürdüğünü anlamak, analist verimliliğini ve otomatik tarama mantığının doğruluğunu ölçmeye yardımcı olur.
Nereden alınır?
Analistin belirli bir eşleşmeyi 'Yanlış Pozitif' veya 'Eşleşme Değil' olarak sonuçlandırdığı açık bir kullanıcı işlemidir. Bu işlem genellikle vaka geçmişine kaydedilir.
Yakalayın
Bir analist sistemde olası eşleşmeyi resmî olarak reddettiğinde kaydedilir.
Olay türü
explicit
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
KYC müşteri işe alımı için Process Mining yolculuğunuzu başlatmak üzere bu veri şablonundan yararlanın. Bu yönergeleri izleyerek değerli içgörüleri ortaya çıkarın ve operasyonlarınızda önemli iyileştirmeler sağlayın.
KYC müşteri onboarding sürecini şimdi optimize edin, uyumluluğu artırın
Sorunsuz bir müşteri onboarding deneyimi sağlayın ve süreyi yalnızca 24 saate indirin.
Kredi kartı gerekmez. 14 gün boyunca ücretsiz deneyin.