KYC müşteri kabulü Veri Templateiniz
KYC müşteri kabulü Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Veri çıkarma yönergeleri
KYC müşteri kabulü öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik 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 kabul sürecindeki tek bir adımı veya olayı tanımlar. Örneğin 'Başvuru gönderildi', 'Analist incelemesi başladı' ya da 'Tarama tamamlandı - sonuç temiz'. Bu etkinlikler süreç haritasındaki düğümleri oluşturur ve iş akışının uçtan uca ayrıntılı görünümünü sunar. Etkinlikleri incelemek, Process Mining çalışmalarının temelidir. Farklı etkinliklerin sırasını ve sıklığını takip ederek gerçek süreç akışını keşfedebilir, yaygın yolları belirleyebilir, standart prosedürden sapmaları tespit edebilir ve gecikmeye ya da yeniden çalışmaya neden olan adımları bulabilirsiniz. Süreç haritaları oluşturmak ve etkinlik düzeyindeki metrikleri hesaplamak için bu öznitelik gereklidir.
Neden önemli?
Bu öznitelik, sürecin tek tek adımlarını tanımlar. Süreç akışını keşfetmek ve görselleştirmek, darboğazları belirlemek için gereklidir.
Nereden alınır?
Bu bilgi genellikle olay günlüklerinde veya denetim izi tablolarında bulunur ve çoğu zaman vaka yönetimi kaydındaki durum değişiklikleriyle ilişkilidir.
Örnekler
Olası eşleşme belirlendiAnalist incelemesi başladıHatalı eşleşme olduğu doğrulandıBaşvuru onaylandı
|
|||
|
Müşteri başvurusu
CustomerApplication
|
Tek bir müşterinin müşteri kabul başvurusuna ait benzersiz kimlik; birincil vaka kimliği olarak kullanılır. | ||
|
Açıklama
Müşteri başvurusu, tek bir müşterinin kabul süreciyle ilgili tüm olayları ve etkinlikleri bir araya getiren temel vaka kimliğidir. İlk başvurudan nihai karara kadar her müşterinin Müşterinizi Tanıyın (KYC) sürecindeki ilerlemesini kronolojik olarak takip etmenizi sağlar. Process Mining analizinde bu öznitelik, her başvurunun uçtan uca yolculuğunu yeniden oluşturmanın temelini oluşturur. Süreç akışlarını görselleştirmenize, toplam çevrim sürelerini hesaplamanıza ve farklı süreç varyantlarını belirlemenize yardımcı olur. Kuruluşlar, bu kimliğe göre gruplandırılmış vakaları inceleyerek başvuruların 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 etkinlikleri birbirine bağlayan bu temel vaka kimliği, müşteri kabul sürecini uçtan uca analiz etmenizi sağlar.
Nereden alınır?
Bu kimlik 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 etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
|
Açıklama
Olay zamanı, bir etkinliğin kaydedildiği kesin tarih ve saati belirtir. Bu zaman damgası, vaka geçmişini yeniden oluşturmak için olayları doğru sıraya koymanızı sağlar. Process Mining çalışmalarındaki zamana dayalı tüm analizler bu özniteliğe bağlıdır. Etkinlikler arasındaki süreleri (çevrim ve bekleme süreleri) hesaplamak, toplam vaka süresini ölçmek, süreç performansını zaman içinde incelemek ve hizmet seviyesi anlaşmalarına (SLA) uyumu kontrol etmek için kullanılır. Zaman damgaları doğru değilse süreç performansını anlamak ve zamana bağlı darboğazları belirlemek mümkün olmaz.
Neden önemli?
Her etkinliğin zaman damgası, süreye dayalı metrikleri hesaplamak, süreç sırasını ortaya çıkarmak ve darboğaz analizi yapmak için gereklidir.
Nereden alınır?
Herhangi bir olay günlüğünde 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
|
Etkinliği 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. Böylece analiz, tek tek kullanıcıların ötesinde kuruluş düzeyinde yapılabilir. Departmana göre analiz yapmak, departmanlar arasındaki darboğazları belirlemek ve devir teslim sürelerini ölçmek açısından önemlidir. İşin farklı ekipler arasında nasıl ilerlediğini ve geçişlerde nerelerde gecikme yaşandığını görselleştirir. Bu görünüm, ekipler arası iş birliğini kolaylaştırmaya ve genel süreç verimliliğini artırmaya yardımcı olur.
Neden önemli?
Süreç performansını departmana göre analiz etmenizi sağlar ve farklı ekipler arasındaki devir teslim gecikmelerini belirlemek için gereklidir.
Nereden alınır?
Bu bilgi, sistemdeki kullanıcı profiliyle veya bağlantılı bir İK sistemiyle birlikte tutulabilir. Olay verileriyle birleştirmek için kullanıcı kimliğinin kullanılması gerekebilir.
Örnekler
Müşteri kabul ekibiUyumluluk incelemesiÜst yönetim
|
|||
|
İnceleyen kimliği
ReviewerId
|
Etkinliği gerçekleştiren kullanıcının, analistin veya otomatik aracının kimliği. | ||
|
Açıklama
İnceleyen kimliği, KYC sürecinde belirli bir görevi kimin gerçekleştirdiğini gösterir. Bu kişi bir uyumluluk analisti, müşteri kabul uzmanı veya otomatik etkinlikler için kullanılan bir sistem hesabı olabilir. Bu bilgiyi takip ederek iş yükünün nasıl dağıldığını ve kişisel performansı görebilirsiniz. Bu öznitelik, kaynaklara dayalı 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ünü dengelemeye yardımcı olur. Devir teslimleri, sosyal ağları ve uyumluluk kaynaklarının kullanımını analiz etmek için de önemlidir.
Neden önemli?
İş yükü dağılımını, kullanıcı performansını ve departmanlar arasındaki devir teslimleri analiz etmenizi sağlar; kaynakları verimli kullanmak için önemlidir.
Nereden alınır?
Genellikle olay günlüklerinde veya denetim izlerinde bulunur; 'UserID', 'PerformedBy' ya da 'Owner' olarak adlandırılabilir.
Örnekler
analyst_jdoesystem_auto_screenermanager_bsmith
|
|||
|
Olay bitiş zamanı
EventEndTime
|
Belirli bir etkinliğin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
Olay bitiş zamanı, bir etkinliğin tamamlandığı anı gösterir. Başlangıç ve bitiş zamanlarının aynı olduğu anlık olaylar şeklinde modellenebilen birçok etkinliğin yanı sıra, 'Analist incelemesi başladı' ve 'Analist incelemesi tamamlandı' gibi ölçülebilir süreye sahip etkinlikler de vardır. Başlangıç ve bitiş zamanlarının ikisi de varsa işlem süresini hassas biçimde ölçebilirsiniz. Süreç analizinde bitiş zamanının bulunması, bekleme süresini de içeren çevrim süresinden farklı olarak etkinliğin tam işlem süresini hesaplamanızı sağlar. Böylece vakanın aktif olarak üzerinde çalışıldığı süreyle kuyrukta beklediği süreyi birbirinden ayırabilirsiniz. Bu ayrım, kaynakları verimli kullanmak ve verimlilik analizi yapmak açısından önemlidir.
Neden önemli?
Etkinliğin işlem süresini hassas biçimde hesaplamanızı sağlar. Aktif çalışma süresini bekleme süresinden ayırarak performansı daha doğru analiz edebilirsiniz.
Nereden alınır?
Süreye sahip etkinlikler için bu bilgi, olay günlüğünde 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 düzeyi
RiskLevel
|
Müşteri başvurusu için hesaplanan risk sınıflandırması; örneğin düşük, orta veya yüksek. | ||
|
Açıklama
Risk düzeyi, KYC süreçlerinde gereken ayrıntılı incelemenin kapsamını belirleyen önemli bir bilgidir. Genellikle müşteri türü, coğrafi konum ve işletmenin niteliği gibi etkenlere göre belirlenir. Bu sınıflandırma, başvurunun izleyeceği süreci önemli ölçüde etkileyebilir. Süreç analizinde vakaları risk düzeyine göre gruplandırmak gerekir. Bu, ç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' ile 'Arka plan kontrolü başlatma çevrim süresi' Dashboardlarında kullanılır.
Neden önemli?
Süreci risk düzeyine göre gruplandırmak, bazı vakaların neden daha uzun sürdüğünü veya farklı yollar izlediğini anlamak ve ret oranlarını incelemek açısından önemlidir.
Nereden alınır?
Müşteri başvurusu veya vaka kaydındaki temel veri noktalarından biridir. Refinitiv World-Check vaka yönetimi modülüne bakın.
Ö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 iç politikalarda belirtilen, tüm müşteri kabul 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' Dashboardunun temel verisidir. Vakanın zamanında tamamlanıp tamamlanmadığını hesaplamak için kullanılır. SLA ihlallerini incelemek, gecikmelere yol açan 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 adımlar atabilir.
Neden önemli?
Zamanında tamamlanma performansını ölçmek için karşılaştırma noktasıdır; SLA uyum oranını hesaplamak ve ihlalleri incelemek açısından önemlidir.
Nereden alınır?
Bu tarih genellikle başvurunun gönderildiği tarih ve iş kuralları temel alınarak 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 çevrimiçi portal, şube veya mobil uygulama. | ||
|
Açıklama
Başvuru kanalı, müşteri başvurusunun hangi kaynaktan gönderildiğini gösterir. Farklı kanallardaki veri bütünlüğü ve kalitesi ile müşteri profilleri değişebilir; bu da sonraki süreçleri etkileyebilir. Bu öznitelik, 'Kanala göre başvuru hacmi' Dashboardu için gereklidir. Kuruluşlar, farklı kanallardan gelen başvuruların hacmini, çevrim süresini ve sonuçlarını inceleyerek hangi kanalların daha verimli olduğunu ve hangilerinde süreç iyileştirmesi gerektiğini belirleyebilir. Bu analiz, kaynak dağılımı ve kanal yatırımları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 kararlara 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
Çevrimiçi portalMobil uygulamaŞubeMüşteri ilişkileri yöneticisi
|
|||
|
Eşleşme kimliği
MatchId
|
World-Check taraması sırasında bulunan olası eşleşmeye ait benzersiz kimlik. | ||
|
Açıklama
Otomatik tarama süreci yaptırım listelerinde, PEP listelerinde veya olumsuz haber kaynaklarında olası bir eşleşme bulduğunda, ilgili bulguyu izlemek için genellikle bir Eşleşme Kimliği oluşturulur. Bu kimlik, başvuru vakasını uyarıyı tetikleyen World-Check veritabanındaki kayda bağlar. Bu öznitelik, ayrıntılı uyumluluk analizi için kullanışlıdır. Analistlerin eşleşmelerin niteliğini incelemesine, belirli uyarıların nasıl sonuçlandığını izlemesine (ör. yanlış pozitif veya gerçek eşleşme olduğunu doğrulamasına) ve hangi uyarı türlerinin daha sık görüldüğünü ya da sonuçlandırılmasının daha uzun sürdüğünü anlamasına yardımcı olur. 'Olası Eşleşme Belirlendi' etkinliğini daha ayrıntılı inceleme olanağı sunar.
Neden önemli?
Belirli tarama sonuçlarına doğrudan bağlantı sağlar; böylece eşleşmelerin sonuçlandırılma süreleri ve uyarı türleri daha ayrıntılı incelenebilir.
Nereden alınır?
Olası bir eşleşme bulunduğunda bu kimlik, World-Check tarama motoru tarafından oluşturulur ve başvuru vakasına kaydedilir.
Örnekler
WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
|
|||
|
Kaynak sistem
SourceSystem
|
Bu örnekte Refinitiv World-Check olmak üzere, olay verilerinin alındığı sistem. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynağını belirtir. Tek bir kaynaktan veri alındığında sabit bir değer olabilir; ancak bütünsel bir süreç görünümü oluşturmak için CRM ve World-Check gibi birden fazla sistemin verileri birleştirildiğinde önem kazanır. Analiz sırasında veri yönetişimine, sorun gidermeye ve verilerin bağlamını anlamaya yardımcı olur. Örneğin, temel tarama sistemine kaydedilen etkinliklerin özellikleri veya ayrıntı düzeyi, yardımcı bir sistemdekilerden farklı olabilir. Ayrıca verilerin kaynağının açıkça izlenebilmesini ve denetlenebilmesini sağlar.
Neden önemli?
Verilerin kaynağını belirtir. Veri yönetişimi ve doğrulama için, ayrıca birden fazla kaynaktan gelen verileri birleştirirken önem taşır.
Nereden alınır?
Veri setini etiketlemek için genellikle veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde eklenen sabit bir değerdir.
Örnekler
Refinitiv World-CheckWorldCheckOne
|
|||
|
Müşteri kimliği
CustomerId
|
Müşteri kabul sürecine alınan müşteriye ait benzersiz kimlik. | ||
|
Açıklama
Müşteri kimliği, müşteri profilinin benzersiz kimliğidir. Bir müşteri zaman içinde birden fazla başvuru yapabileceğinden, bu kimlik Müşteri Başvuru Kimliğinden farklıdır. Müşteri kabul sürecini ana müşteri kaydına bağlar. Analizde Müşteri Kimliği, aynı müşterinin tekrarlanan başvurularını takip etmenizi sağlar. Ayrıca süreç verilerini CRM’den veya ana veri sisteminden alınan diğer müşteri öznitelikleriyle zenginleştirmek için kullanılabilir. Böylece tek bir müşteri kabul sürecinin ötesinde, müşteri yolculuğunun bütününü görebilirsiniz.
Neden önemli?
Müşteri kabul vakasını belirli bir müşteriye bağlar; tekrarlanan başvuruları analiz etmenizi ve verileri ana müşteri bilgileriyle zenginleştirmenizi sağlar.
Nereden alınır?
Başvuru veya vaka kaydında bulunan ve kaydı ana müşteri verilerine bağlayan önemli bir alandır.
Örnekler
CUST-98765CUST-98766CUST-98767
|
|||
|
Müşteri türü
CustomerType
|
Müşterinin birey, şirket veya tröst gibi sınıflandırması. | ||
|
Açıklama
Müşteri türü, müşteri kabul sürecine alınan varlığı sınıflandırır. Farklı müşteri türlerinin kabul koşulları, risk profilleri ve mevzuat yükümlülükleri değişebilir. Örneğin, bir şirketin müşteri kabul süreci genellikle bir bireyinkinden daha karmaşıktır. Bu öznitelik, özellikle 'KYC müşteri türüne göre performans' Dashboardunda segmentasyon analizi için kullanılır. Farklı müşteri segmentlerinin süreç verimliliğini, çevrim sürelerini ve ret oranlarını karşılaştırmanızı sağlar. Böylece kuruluşlar, müşteri kabul deneyimini farklı müşteri türlerine göre uyarlayıp iyileştirebilir.
Neden önemli?
Farklı müşteri segmentlerinin performansını karşılaştırmanızı, her tür için müşteri kabul sürecini uyarlayıp iyileştirmenizi sağlar.
Nereden alınır?
Kaynak sistemdeki müşteri veya başvuru kaydında tutulan temel bir özniteliktir.
Örnekler
BireyŞirketKâr amacı gütmeyen kuruluşTröst
|
|||
|
Müşterinin ülkesi
CustomerCountry
|
Müşterinin ikamet ettiği veya kurulduğu ülke. | ||
|
Açıklama
Bu öznitelik, müşterinin coğrafi konumunu gösterir. Ülke, KYC süreçlerinde risk değerlendirmesini ve mevzuat gerekliliklerini önemli ölçüde etkiler. Farklı ülkelerin kuralları, süreç akışını ve süresini değiştirebilir. Süreci ülkeye göre incelemek, kuruluşların farklı bölgelerdeki performansı karşılaştırmasına, bölgesel darboğazları belirlemesine ve yerel düzenlemelere uyumu sağlamasına yardımcı olur. Süreç analizine coğrafi bir boyut katar ve operasyonlardaki önemli farklılıkları ortaya çıkarabilir.
Neden önemli?
Süreci coğrafi açıdan analiz etmenizi sağlar; bölgesel performans, risk ve uyumluluk gerekliliklerindeki farklılıkları belirlemeye yardımcı olur.
Nereden alınır?
Müşteri profilinde veya başvuru formunda bulunan standart bir alandır.
Örnekler
USAGBRSGPDEU
|
|||
|
Otomatik mi
IsAutomated
|
Etkinliğin bir sistem (true) ya da bir kişi (false) tarafından gerçekleştirildiğini belirten bir işaret. | ||
|
Açıklama
Bu boole özniteliği, otomatik sistem görevleriyle kullanıcıların gerçekleştirdiği manuel etkinlikleri birbirinden ayırır. Örneğin, 'Otomatik tarama yapıldı' otomatik olarak işaretlenirken 'Analist incelemesi başladı' manuel olarak işaretlenir. Bu ayrım, otomasyon analizinde büyük önem taşır. Otomasyonun süreç verimliliğine etkisini ölçmeye, gelecekte otomatikleştirilebilecek manuel görevleri belirlemeye ve insanlarla sistemlerin etkileşimini anlamaya yardımcı olur. Sistem işlem süresiyle manuel işlem süresini net biçimde ayırmanızı sağlar.
Neden önemli?
Sistem etkinlikleriyle insan etkinliklerini ayırır. Bu ayrım, otomasyonun etkisini ölçmek ve yeni otomasyon fırsatlarını belirlemek için önemlidir.
Nereden alınır?
Bu değer genellikle etkinlik adına veya olayla ilişkilendirilmiş kullanıcı kimliğine göre belirlenir (ör. kullanıcı bir 'system' hesabıysa).
Örnekler
truefalse
|
|||
|
Ret nedeni
RejectionReason
|
Müşteri başvurusu reddedildiğinde belirtilen özel neden. | ||
|
Açıklama
Başvuru reddedildiğinde ret nedeni, bu kararın nedenini belirtir. Nedenler arasında 'Yaptırım listesi eşleşmesi', 'Eksik dokümantasyon' veya 'Yüksek risk profili' bulunabilir. Bu bilgi, gelen başvuruların kalitesi ve tarama sürecinin etkililiği hakkında yapılandırılmış geri bildirim sağlar. Bu öznitelik, 'Başvuru ret oranı ve nedenleri' Dashboardunun temel verisidir. Ret nedenlerini incelemek, retlerin temel nedenlerini belirlemeye yardımcı olur. Böylece süreç iyileştirilebilir, başvuru sahipleriyle daha açık iletişim kurulabilir ve gereksiz retler azaltılabilir. Ayrıca sayısal ret oranı metriğine niteliksel bağlam kazandırır.
Neden önemli?
Başvuruların neden reddedildiğini ortaya koyar. Ret oranını azaltmak için müşteri kabul sürecinde iyileştirilmesi gereken alanları belirlemeye yardımcı olur.
Nereden alınır?
'Başvuru reddedildi' olayı gerçekleştiğinde, muhtemelen vaka veya başvuru kaydındaki bir alana yazılır.
Örnekler
PEP eşleşmesiYaptırım listesinde eşleşme bulunduBelge doğrulaması başarısız olduOlumsuz medya kaydı
|
|||
|
SLA ihlal edildi
SlaBreached
|
İşe alım vakasının SLA hedef tarihinden sonra tamamlanıp tamamlanmadığını belirten bir boole işareti. | ||
|
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 tamamlama etkinliğinin zaman damgası (ör. 'Başvuru onaylandı' veya 'Başvuru reddedildi'), vakaya ait 'SlaTargetDate' değeriyle 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 edilen tüm vakaları hızla filtrelemesini sağlayarak analizi kolaylaştırır. Kuruluşlar, SLA’yı ihlal eden vakaların süreç özelliklerini inceleyerek gecikmelerin temel nedenlerini belirleyebilir ve iyileştirme çalışmalarını doğru alanlara yöneltebilir.
Neden önemli?
Hizmet seviyesi anlaşmalarına uyumu doğrudan ölçer; geciken vakaları kolayca filtreleyip temel nedenlerini analiz etmenizi sağlar.
Nereden alınır?
Bu değer, veri dönüştürme sırasında vakanın son etkinliğinin zaman damgası ile SlaTargetDate alanı karşılaştırılarak hesaplanır.
Örnekler
truefalse
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Bu olaya ait verilerin kaynak sistemden en son yenilendiği veya alındığı zamanı gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, verilerin ne kadar güncel olduğunu gösterir. Refinitiv World-Check’ten en son veri alımının tarih ve saatini kaydeder. Process Mining Dashboardlarının ve analizlerinin güncelliğini anlamak için önemlidir. Analiz sırasında kullanıcıların gerçek zamana yakın verileri mi yoksa belirli bir andan alınmış bir anlık görüntüyü mü incelediğini anlamalarını sağlar. Veri yönetişimi ve sunulan içgörülerin güncelliğine ilişkin beklentileri 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 çalışma mı
IsRework
|
Bir etkinliğin aynı vaka içinde ikinci veya daha sonraki kez gerçekleştirildiğini belirten bir işaret. | ||
|
Açıklama
IsRework, aynı müşteri başvuru vakasında bir etkinliğin tekrarlandığını belirleyen hesaplanmış bir boole özniteliğidir. Örneğin, tek bir başvuru için 'Risk değerlendirmesi yapıldı' etkinliği birden fazla kez gerçekleşirse sonraki tekrarlar 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 açıklığı veya karar alma süreçlerindeki sorunları ortaya çıkarır. Bu sorunlar boşa harcanan emeğe ve daha uzun çevrim sürelerine yol açar.
Neden önemli?
Tekrarlanan etkinlikleri işaretleyerek süreç verimsizliklerini ortaya çıkarır. Böylece kaliteyi artırmak ve çevrim sürelerini kısaltmak için yeniden çalışma döngülerini analiz edebilirsiniz.
Nereden alınır?
Bu değer, veri dönüştürme sırasında her vakadaki etkinlik sırası incelenerek ve bir etkinliğin ilk gerçekleşmesinden sonraki tüm tekrarları işaretlenerek hesaplanır.
Örnekler
truefalse
|
|||
KYC müşteri kabulü etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Analist incelemesi başladı
|
Uyumluluk analisti, müşteri başvurusundaki olası eşleşmeleri manuel olarak incelemeye başlar. Bu incelemede, olası eşleşmelerin ayrıntıları müşterinin bilgileriyle karşılaştırılarak eşleşmenin geçerli olup olmadığı değerlendirilir. | ||
|
Neden önemli?
Bu etkinlik, manuel uyumluluk incelemesinin başlangıcını gösterir. Bu aşama sıkça darboğaz oluşturur. 'Olası eşleşme belirlendi' ile bu etkinlik arasındaki süre, kuyrukta bekleme gecikmelerini; incelemenin süresi ise analistlerin verimliliğini gösterir.
Nereden alınır?
Bir analistin inceleme kuyruğundan vakayı 'üstlenmesi' veya açmasıyla çıkarılabilir. Vaka durumu 'İnceleniyor' olarak değiştiğinde ya da vaka belirli bir kullanıcıya atandığında sistem bu olayı denetim izine açıkça kaydedebilir.
Kaydedin
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 etkinlik, müşterinin başvurusunu göndermesiyle KYC müşteri kabul sürecinin başladığını gösterir. Bu olay genellikle bir CRM veya temel başvuru sisteminde kaydedilir ve ardından Refinitiv World-Check’te tarama sürecini başlatır. | ||
|
Neden önemli?
Bu, müşterinin baştan sona kabul sürecindeki temel başlangıç olayıdır. Bu noktadan tamamlanmaya kadar geçen süreyi analiz ederek toplam müşteri kabul çevrim süresini ölçebilirsiniz. Bu ölçüm, müşteri deneyimini ve SLA hedeflerine uyumu değerlendirmek için önemlidir.
Nereden alınır?
Bu olay World-Check’te yerleşik olarak bulunmaz. CRM veya müşteri hesabı yönetim platformu gibi önceki bir sistemden alınmalı ve Müşteri Başvurusu Kimliği kullanılarak ilişkilendirilmelidir.
Kaydedin
İlk başvuru gönderildiğinde kaynak başvuru sistemine kaydedilen olay.
Olay türü
explicit
|
|||
|
Başvuru reddedildi
|
Müşteri başvurusu, çoğunlukla World-Check’te 'Eşleşme bulundu' sonucu alınması veya başka risk etkenleri nedeniyle resmen reddedilir. Bu olay, müşteri kabul sürecinin nihai olumsuz sonucudur. | ||
|
Neden önemli?
Bu, sürecin başlıca başarısızlıkla sonuçlanan bitiş noktasıdır. Özellikle ret nedenlerini ve öncesindeki etkinlikleri incelemek, süreci iyileştirmek ve gereksiz retleri azaltmak açısından önemlidir.
Nereden alınır?
Bu nihai iş kararı World-Check’te değil, üst sistemdeki CRM’de veya temel başvuru sisteminde kaydedilir. Veriler bu sistemden alınmalıdır.
Kaydedin
Kaynak başvuru sistemine, çoğu zaman ilgili bir ret nedeni koduyla birlikte kaydedilen olay.
Olay türü
explicit
|
|||
|
Gerçek eşleşme olduğu doğrulandı
|
Analist, olası eşleşmenin taranan müşteriyle gerçekten aynı kişi ya da kuruluş olduğunu doğrulayarak olası bir riski belirler. Bu önemli aşama genellikle ayrıntılı incelemeyi başlatır veya başvurunun reddedilmesine yol açar. | ||
|
Neden önemli?
Bu, riski azaltmaya yönelik önemli bir sonuç ve süreçte belirleyici bir aşamadır. Müşteri başvurusu hakkındaki nihai kararı doğrudan etkiler; uyumluluk raporlaması ve analizi açısından da ö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.
Kaydedin
Analist sistemde bir eşleşmeyi resmen doğruladığında kaydedilir.
Olay türü
explicit
|
|||
|
Hesap etkinleştirildi
|
Müşterinin hesabı temel sistemde oluşturulur ve etkinleştirilir; böylece müşteri kabul süreci tamamlanır. Bu adım, başvurunun nihai onayından sonra gelir ve hesabı kullanıma hazır hâle getirir. | ||
|
Neden önemli?
Bu, süreçte müşteriye 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 açısından önemli bir metriktir.
Nereden alınır?
Bu olay World-Check’te kaydedilmez. Temel bankacılık veya müşteri hesap sisteminde tutulur ve Müşteri Başvuru Kimliği kullanılarak ilişkilendirilmelidir.
Kaydedin
Hesap etkinleştirildiğinde temel hesap sistemine kaydedilen olay.
Olay türü
explicit
|
|||
|
Tarama talebi oluşturuldu
|
Refinitiv World-Check sisteminde müşteri başvurusu için yeni bir tarama vakası resmî olarak oluşturulur. Bu işlem, önceki bir sistemden gelen API çağrısıyla veya manuel girişle başlatılır ve risk istihbaratı kontrolünün başlangıcını gösterir. | ||
|
Neden önemli?
Bu, tarama alt sürecinin resmen başladığını gösterir. Başvurunun gönderilmesi ile bu etkinlik arasındaki süre, iş birimi sisteminden uyumluluk ekibine yapılan devir teslimlerdeki gecikmeleri ortaya çıkarır.
Nereden alınır?
World-Check vaka yönetimi günlüklerinde veya denetim izinde kaydedilir. İlgili vaka ya da varlık kimliği için oluşturma olayı ve zaman damgası kullanılır.
Kaydedin
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 resmen kapatılır. Bu karar, ayrıntılı inceleme veya başvurunun reddedilmesi gibi farklı bir sonraki süreci başlatır. | ||
|
Neden önemli?
Bu, tarama sürecinin başlıca olumsuz sonuçla biten yoludur. Bu vakaları incelemek, risk profillerini ve tarama kontrollerinin ne kadar etkili olduğunu anlamaya yardımcı olur.
Nereden alınır?
Nihai vaka durumunun 'Eşleşme bulundu', 'Risk belirlendi' veya 'Kapandı - olumlu' olarak değişmesinden çıkarılır. Bu son durum değişikliğinin zaman damgası kullanılır.
Kaydedin
Doğrulanmış eşleşmeyi belirten nihai vaka durumunun zaman damgasından elde edilir.
Olay türü
inferred
|
|||
|
Tarama tamamlandı - sonuç temiz
|
Tarama vakası, gerçek bir eşleşme bulunmadığını belirten 'Temiz' sonucuyla resmen kapatılır. Bu karar başvurunun geldiği sisteme iletilir ve müşteri kabul sürecinin devam etmesini sağlar. | ||
|
Neden önemli?
Bu etkinlik, tarama sürecinin başarıyla tamamlandığı ideal yolu 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 'Kapandı - eşleşme yok' olarak değişmesinden çıkarılır. Bu son durum değişikliğinin zaman damgası kullanılır.
Kaydedin
Temiz sonucu belirten nihai vaka durumunun zaman damgasından elde edilir.
Olay türü
inferred
|
|||
|
Başvuru onaylandı
|
Başvuru, KYC taraması ve gerekli diğer kontroller başarıyla tamamlandıktan sonra 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 aşamaya kadar geçen süreyi takip ederek yeni bir müşteri için toplam onay süresini görebilirsiniz.
Nereden alınır?
Bu olay World-Check’e özgü değildir. Nihai iş kararını veren üst sistemdeki CRM’den veya temel başvuru sisteminden alınmalıdır.
Kaydedin
Nihai onay verildiğinde kaynak başvuru 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 etkinliğin sık tekrarlanması, tarama için sağlanan ilk verilerin kalitesinde sorun olduğuna işaret eder. Başka ekiplere 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?
Vaka notlarında veya denetim günlüğünde kaydedilen açık bir kullanıcı işlemi olabilir. Alternatif olarak, vaka durumunun 'Bilgi bekleniyor' veya 'Bilgi talebi' olarak değişmesinden çıkarılabilir.
Kaydedin
Analist, vakayı daha fazla bilgi gerekiyor şeklinde işaretleyen bir özelliği kullandığında kaydedilir.
Olay türü
explicit
|
|||
|
Hatalı eşleşme olduğu doğrulandı
|
Analist, olası eşleşmenin taranan müşteriyle aynı kişi ya da 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 karşılaşılan sonuçlardan biridir. Hatalı eşleşmeleri sonuçlandırma süresini 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 'Hatalı eşleşme' 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.
Kaydedin
Analist olası eşleşmeyi sistemde resmen reddettiğinde kaydedilir.
Olay türü
explicit
|
|||
|
Olası eşleşme belirlendi
|
Otomatik tarama süreci, bir analistin manuel olarak incelemesi gereken bir veya daha fazla olası eşleşme bulmuştur. Bu olay, vakayı otomatik işlem aşamasından manuel inceleme kuyruğuna taşır. | ||
|
Neden önemli?
Bu etkinlik, süreçte önemli bir ayrım noktasıdır. Olası eşleşme bulunan vakalar daha uzun ve karmaşık bir yol izler. Bu vakaları takip etmek, inceleme ekibinin 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.
Kaydedin
Manuel incelemenin gerektiğini belirten vaka durumu değişikliğinden elde edilir.
Olay türü
inferred
|
|||
|
Otomatik tarama yapıldı
|
World-Check sistemi, müşterinin bilgilerini risk istihbaratı veri tabanıyla otomatik olarak karşılaştırır. Sistem tarafından yürütülen bu etkinlik, olası eşleşmeler veya temiz sonuç gibi ilk bulguları üretir. | ||
|
Neden önemli?
Bu etkinlik, tarama sürecindeki ilk katma değerli adımdır. Bu noktadan önceki gecikmeler, sistemin veya verilerin hazır olmadığını gösterebilir. Sonuç ise sonraki manuel iş yükünü belirler.
Nereden alınır?
Bu olay, vaka denetim izinde 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.
Kaydedin
Otomatik veri tabanı taraması tamamlandığında oluşturulan sistem günlüğü kaydı.
Olay türü
explicit
|
|||
|
Vaka inceleme için üst kademeye aktarıldı
|
İlk düzeydeki bir analist, karmaşık veya yüksek riskli bir vakayı nihai karar için kıdemli bir analiste ya da yöneticiye aktarır. Bu, uyumluluk ekibindeki önemli bir devir teslim noktasıdır. | ||
|
Neden önemli?
Üst kademeye aktarılan vakalar çoğu zaman darboğazlara yol açar ve çevrim süresini uzatır. Aktarımların sıklığını ve nedenlerini incelemek, deneyimsiz analistlerin eğitim ihtiyacını veya inceleme politikalarındaki belirsizlikleri ortaya çıkarabilir.
Nereden alınır?
Vaka iş akışında veya denetim izinde açık bir işlem olarak kaydedilir. Vakanın atandığı kullanıcının, özellikle daha yüksek yetkilere sahip bir kullanıcının değişmesinden de çıkarılabilir.
Kaydedin
Vaka içindeki özel bir 'Üst kademeye aktar' düğmesi veya iş akışı işlemiyle kaydedilir.
Olay türü
explicit
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
KYC müşteri kabulü için Process Mining çalışmalarınıza bu veri Templateiyle başlayın. Bu yönergeleri izleyerek değerli içgörüler elde edebilir ve operasyonlarınızda önemli iyileştirmeler yapabilirsiniz.
KYC müşteri kabulünü şimdi iyileştirin, uyumluluğu artırın
Müşteri kabulünü sorunsuz hale getirin ve süreyi yalnızca 24 saate indirin.
Kredi kartı gerekmez. 14 gün ücretsiz deneyin.