KYC müşteri kabul süreci için Veri Templateiniz
KYC müşteri kabul süreci için Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Veri çıkarma yönergeleri
KYC müşteri kabul süreci öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik adı
ActivityName
|
Müşteri kabul sürecinde belirli bir anda gerçekleşen görevin veya olayın adı. | ||
|
Açıklama
Etkinlik adı, KYC müşteri kabul iş akışındaki bir adımı belirtir. Örneğin 'Başvuru gönderildi', 'Belge incelemesi yapıldı' veya 'Başvuru onaylandı'. Her etkinlik, süreçteki ayrı bir eylemi veya dönüm noktasını temsil eder. Bu öznitelik, etkinlik akışını görsel olarak gösteren süreç haritasını oluşturmak için gereklidir. Süreç varyantlarını, belirli adımlar arasındaki darboğazları ve yeniden çalışma döngülerinin sıklığını analiz etmenizi sağlar. Süreçte neler olduğunu anlamak için etkinlikleri incelemek önemlidir.
Neden önemli?
Bu öznitelik, süreç haritasının temelini oluşturur ve müşteri kabul sürecindeki olayların sırasını görselleştirip analiz etmenizi sağlar.
Nereden alınır?
Genellikle LexisNexis Risk Solutions içindeki süreç adımlarını izleyen Event Log veya denetim izi tablosunda bulunur.
Örnekler
Başvuru gönderildiİlk tarama yapıldıBelgeler istendiUyumluluk incelemesi tamamlandı
|
|||
|
Müşteri başvurusu
CustomerApplication
|
Her müşteri kabul başvurusuna verilen ve temel vaka kimliği olarak kullanılan benzersiz tanımlayıcı. | ||
|
Açıklama
Müşteri başvurusu, tek bir müşterinin kabul sürecine ait tüm etkinlikleri ve veri noktalarını birbirine bağlayan temel tanımlayıcıdır. Başvuru gönderildiğinde başlar ve vaka tamamlanana veya reddedilene kadar süreci izler. Process Mining’de bu öznitelik, tüm olayları tek bir vaka altında toplamak için gereklidir. Böylece müşteri kabul sürecinin tamamını baştan sona analiz edebilirsiniz. Her başvuru sahibinin süreç akışını yeniden oluşturabilir; çevrim sürelerini hesaplayabilir, süreç varyantlarını inceleyebilir ve başvurunun durumunu zaman içinde izleyebilirsiniz.
Neden önemli?
Bu, temel vaka kimliğidir. Bu kimlik olmadan müşteri başvurusunun baştan sona nasıl ilerlediğini izleyemezsiniz; dolayısıyla süreç analizi yapmak mümkün olmaz.
Nereden alınır?
LexisNexis Risk Solutions vaka yönetimi modülündeki temel vaka tanımlayıcısıdır.
Örnekler
APP-2023-001234APP-2023-005678APP-2024-009101
|
|||
|
Olay zaman damgası
EventTimestamp
|
Belirli bir etkinliğin başladığı kesin tarih ve saat. | ||
|
Açıklama
Bu zaman damgası, bir etkinliğin başlangıcını belirtir ve vaka içindeki tüm olayların kronolojik sırasını belirler. Process Mining’de zamana dayalı tüm analizlerin temelidir. Olay zaman damgasını kullanarak etkinliklerin süresini, aralarındaki bekleme zamanını ve müşteri kabul sürecinin baştan sona çevrim süresini hesaplayabilirsiniz. Bu veriler, darboğazları belirlemek, SLA hedeflerine uyumu izlemek ve süreç verimliliğini anlamak için gereklidir.
Neden önemli?
Bu zaman damgası, olayları kronolojik sıraya koymak ve çevrim süresi ile darboğazlar gibi zamana dayalı tüm Metrikleri hesaplamak için gereklidir.
Nereden alınır?
Olay günlüğünde veya denetim izi tablolarında, Aktivite Adı alanının yanında bulunur.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
|
|||
|
Atanan kullanıcı
AssignedUser
|
Etkinliği gerçekleştirmekle sorumlu kullanıcının veya temsilcinin benzersiz kimliği. | ||
|
Açıklama
Bu öznitelik, belge incelemesi yapan bir uyumluluk görevlisi gibi görevi gerçekleştiren kişiyi belirtir. İş yükünün dağılımını ve kişisel performansı incelemenize yardımcı olur. Analizlerde Atanan kullanıcı, Kaynak dağılımı ve iş yükü Dashboardu için temel bir özniteliktir. Süreç haritasını kullanıcıya göre filtrelemenizi, ekip üyelerinin performansını karşılaştırmanızı ve eğitim ya da iş yükünü yeniden dengeleme fırsatlarını belirlemenizi sağlar. Belirli kullanıcı gruplarının yol açtığı darboğazları da ortaya çıkarabilir.
Neden önemli?
Kaynak performansını ve iş yükü dağılımını incelemek, otomasyon veya kaynak optimizasyonu fırsatlarını belirlemek için önemlidir.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Genellikle denetim izlerinde veya görev yönetimi tablolarında bulunur.
Örnekler
j.doem.smithk.chen
|
|||
|
Başvuru durumu
ApplicationStatus
|
Müşteri başvurusunun mevcut veya nihai durumu. | ||
|
Açıklama
Bu öznitelik, vakanın belirli bir andaki genel durumunu veya nihai sonucunu gösterir. Yaygın durumlar arasında Devam ediyor, Onaylandı, Reddedildi ve Bilgi bekleniyor yer alır. Başvuru durumu, işe alım sürecinin sonuçlarını izlemek için önemlidir. Başvuru ret nedenleri ve aşamaları ile Günlük işlem hacmi ve başvuru durumu Dashboardlarında başarı oranlarını ve operasyonel akışı izlemek için kullanılır. Durumun zaman içinde nasıl değiştiğini incelemek, vaka yaşam döngüsünü anlamanızı sağlar.
Neden önemli?
Her başvurunun sonucunu izler; Başvuru ret oranı gibi temel KPI’ları hesaplamak ve işlem hacmini takip etmek için gereklidir.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Bu alan genellikle ana vaka veya başvuru nesnesinde bulunur.
Örnekler
Devam ediyorOnaylandıReddedildiMüşteri bilgileri bekleniyor
|
|||
|
Bitiş zamanı
EndTime
|
Bir etkinliğin tamamlandığı kesin tarih ve saat. | ||
|
Açıklama
Bu zaman damgası, bir etkinliğin tamamlandığı zamanı belirtir. Bir olayın Bitiş zamanı ile Başlangıç zamanı arasındaki fark, işlem süresini gösterir. Her adımın ne kadar sürdüğünü doğru hesaplamak için Bitiş zamanı gerekir. Bu değer, Etkinlik işlem ve bekleme süreleri Dashboardunun temel girdilerindendir. Kaynağın bir görev üzerinde fiilen çalıştığı süreyle vakanın sonraki adımın başlamasını beklediği süreyi ayırt etmenize yardımcı olur.
Neden önemli?
Etkinliklerin işlem süresini doğru hesaplamayı sağlar. Verimsiz adımları belirlemek ve kaynakların iş yükünü incelemek için gereklidir.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. 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
|
|||
|
Departman
Department
|
Atanan kullanıcının bağlı olduğu iş departmanı veya ekip. | ||
|
Açıklama
Departman özniteliği, Uyumluluk, İşe alım operasyonları veya Dolandırıcılığı önleme gibi bir etkinlikten sorumlu işlevsel grubu belirtir. Bu öznitelik, süreci departman bazında incelemek ve ekipler arasındaki devir teslimleri analiz etmek için kullanılır. Kaynak dağılımı ve iş yükü Dashboardunun temel boyutlarından biridir. Departmanlar arasındaki işlevler arası verimsizlikleri veya iletişim gecikmelerini belirlemeye yardımcı olur.
Neden önemli?
Süreçteki devir teslimleri ve işlev alanlarına göre performansı incelemenizi, departmanlar arasındaki darboğazları belirlemenizi sağlar.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Bu bilgi, kullanıcı veya İK ana veri tablosundan birleştirilerek alınabilir.
Örnekler
Complianceİşe alım ekibiKYC analistleriMüşteri desteği
|
|||
|
Risk düzeyi
RiskLevel
|
Müşteri başvurusunun Düşük, Orta veya Yüksek gibi hesaplanan risk düzeyi. | ||
|
Açıklama
LexisNexis Risk Solutions risk değerlendirmesi alanında uzmanlaşmıştır. Bu öznitelik, değerlendirme sonucunu gösterir ve her başvuruyu olası risk profiline göre sınıflandırır. Risk düzeyi, gerekli durum tespiti sürecinin kapsamını ve süresini belirler. Bu öznitelik, Risk düzeyi ve işe alım süresi Dashboardunun temel boyutudur. Süreci risk düzeyine göre inceleyerek 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 görebilirsiniz. Risk temelli işe alım stratejilerini doğrulamanıza ve iyileştirmenize yardımcı olur.
Neden önemli?
Risk temelli analiz için gereklidir; müşteri risk profillerinin süreç karmaşıklığını, süresini ve izlenen yolları nasıl etkilediğini anlamanızı sağlar.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Bu, risk değerlendirme modüllerinin temel çıktılarından biridir.
Örnekler
DüşükOrtaYüksekYaptırım uygulanan
|
|||
|
SLA hedef tarihi
SlaTargetDate
|
Müşteri işe alım sürecinin tamamlanmasının beklendiği tarih. | ||
|
Açıklama
SLA hedef tarihi, bir başvurunun tamamlanması için belirlenen hizmet düzeyi anlaşması hedefini tanımlar. Bu tarih genellikle başvuru türü, müşteri segmenti veya yargı yetki alanı gibi etkenlere göre belirlenir. Bu öznitelik, SLA hedeflerine uyum izleme Dashboardu ve SLA uyum oranı KPI’ı için gereklidir. Gerçek tamamlanma tarihini SLA hedef tarihiyle karşılaştırarak taahhütlerin ne ölçüde yerine getirildiğini ölçebilir, SLA ihlali riski taşıyan vakaları belirleyebilir ve gecikmelerin temel nedenlerini araştırabilirsiniz.
Neden önemli?
Hizmet düzeyi anlaşmalarına göre performansı ölçer ve SLA ihlallerine yol açan süreç verimsizliklerini ortaya çıkarır.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Bu bilgi vakada saklanabilir 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şvurusu türü. | ||
|
Açıklama
Bu öznitelik, işe alım sürecine alınan kuruluşun türüne göre başvuruları sınıflandırır. Farklı başvuru türleri genellikle farklı süreç yollarını izler; risk profilleri ve SLA hedefleri de farklı olabilir. Süreci başvuru türüne göre inceleyerek farklı müşteri türlerinin işe alım verimliliğini ve karmaşıklığını karşılaştırabilirsiniz. Performansı daha ayrıntılı incelemek için çoğu Dashboardda kullanılan yaygın bir filtredir.
Neden önemli?
Süreci başvuru türüne göre ayrıntılı incelemenizi, her türün nasıl ele alındığını ve hangi darboğazların yaşandığını görmenizi sağlar.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Bu alan genellikle başvuru veya vaka nesnesinde bulunur.
Örnekler
BireyselKurumsalYüksek net değerli bireysel müşteriTröst
|
|||
|
Çevrim süresi
CycleTime
|
Müşteri başvurusunun gönderilmesinden nihai karara kadar geçen toplam süre. | ||
|
Açıklama
Çevrim süresi, tek bir vaka için ilk olaydan (örneğin Başvuru gönderildi) son olaya (örneğin Müşteri işe alımı tamamlandı veya Başvuru reddedildi) kadar geçen toplam süreyi ölçer. Bu, genel süreç sağlığını ölçen temel KPI’lardan biridir ve Uçtan uca işe alım çevrim süresi Dashboardunda gösterilir. Ortalama çevrim süresini izleyerek süreç iyileştirmelerinin etkisini takip edebilir; risk düzeyi veya başvuru türü gibi etkenlerin genel müşteri deneyimini nasıl etkilediğini görebilirsiniz.
Neden önemli?
Müşterinin değer elde etmesi için geçen toplam süreyi ölçen temel bir performans göstergesidir. Müşteri memnuniyetini ve operasyonel verimliliği doğrudan etkiler.
Nereden alınır?
Bu metrik, her vaka için ilk olayın zaman damgasının son olayın zaman damgasından çıkarılmasıyla hesaplanır.
Örnekler
5 gün 4 saat22 gün 8 saat1 gün 2 saat
|
|||
|
Kanal
Channel
|
Başvurunun gönderildiği Web, Mobil veya Şube gibi kanal. | ||
|
Açıklama
Kanal özniteliği, başvurunun hangi kaynaktan gönderildiğini belirtir. Kanal; veri kalitesini, müşteri davranışını ve işe alım sırasında karşılaşılan sorunları etkileyebilir. Bu öznitelik, farklı kanallardaki süreç performansını karşılaştırmak için kullanılır. Örneğin İşe alım hunisi dönüşüm oranları Dashboardunu kanala göre filtreleyerek mobil başvuruların web başvurularına kıyasla daha sık yarıda bırakılıp bırakılmadığını görebilir ve kanala özel süreç iyileştirmeleri planlayabilirsiniz.
Neden önemli?
Başvuru kanalına göre süreç performansını incelemenize, kanal stratejisini ve kullanıcı deneyimini iyileştirecek farklılıkları belirlemenize yardımcı olur.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Bu bilgi genellikle başvuru sürecinin başlangıcında kaydedilir.
Örnekler
Web portalıMobil uygulamaŞubeAPI
|
|||
|
Kaynak sistem
SourceSystem
|
Olay verilerinin geldiği sistem veya uygulama. | ||
|
Açıklama
Bu öznitelik, LexisNexis Risk Solutions veya entegre edilmiş bir üçüncü taraf aracı gibi olay verilerini oluşturan kaynak sistemi belirtir. Karmaşık ortamlarda tek bir sürece ait veriler birden fazla sistemden gelebilir. Kaynak sistemi bilmek, verileri doğrularken, sorunları giderirken ve belirli sistemlere özgü süreç farklılıklarını incelerken fayda sağlar. Veri bütünlüğünü korumaya yardımcı olur; ayrıca etkinliğin nasıl ve nerede kaydedildiğini anlamanız için bağlam sunar.
Neden önemli?
Verilerin kaynağını belirtir. Bu bilgi, veri yönetişimi ve doğrulama için, ayrıca farklı BT sistemlerinde sürecin nasıl yürütüldüğünü anlamak için önemlidir.
Nereden alınır?
Bu bilgi, sabit bir değer olarak veya veri dışa aktarımında ya da API yanıtında belirli bir alanda saklanabilir.
Örnekler
LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
|
|||
|
Müşterinin ülkesi
CustomerCountry
|
Müşterinin ikamet ettiği veya kurulduğu ülke. | ||
|
Açıklama
Bu öznitelik, müşterinin ülkesini belirtir. Farklı yargı yetki alanlarındaki düzenlemeler ve risk düzeyleri değiştiğinden, ülke KYC açısından önemli bir etkendir. Süreci müşterinin ülkesine göre incelemek, çevrim süreleri ve süreç karmaşıklığındaki önemli farklılıkları ortaya çıkarabilir. Örneğin, yüksek riskli yargı yetki alanlarından gelen başvurular için ek uyumluluk kontrolleri gerekebilir ve bu da süreci uzatabilir. Bu analiz, kaynak planlamasına ve farklı bölgeler için gerçekçi SLA hedefleri belirlemeye yardımcı olur.
Neden önemli?
Yargı yetki alanına göre analiz yapmanızı sağlar. Bölgesel düzenlemelerin ve risk etkenlerinin süreç performansını nasıl etkilediğini anlamak için gereklidir.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Bu, müşteri ana verilerinde bulunan standart bir alandır.
Örnekler
USAGBRDEUSGP
|
|||
|
Otomatik mi
IsAutomated
|
Bir etkinliğin sistem tarafından otomatik mi yoksa kullanıcı tarafından elle mi gerçekleştirildiğini belirten işaret. | ||
|
Açıklama
Bu mantıksal öznitelik, sistem otomasyonuyla yürütülen görevleri (örneğin ilk tarama kontrolü) insan müdahalesi gerektiren görevlerden (örneğin elle yapılan belge incelemesi) ayırır. Otomatik mi özniteliği, Elle gerçekleştirilen etkinlik oranı KPI’ını hesaplamak ve otomasyon çalışmalarının etkisini incelemek için kullanılır. Süreç haritasında otomatik ve elle yapılan adımlar arasındaki geçişi göstererek maliyetleri ve işlem sürelerini azaltacak yeni otomasyon fırsatlarını belirlemenize yardımcı olur.
Neden önemli?
Elle yapılan ve otomatik görevleri ayırt eder. Otomasyon fırsatlarını belirlemek ve etkilerini ölçmek için gereklidir.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Bu bilgi, olay günlüğünde bir işaret olarak yer alabilir veya Atanan kullanıcı alanına (örneğin sistem kullanıcısı) göre çıkarılabilir.
Örnekler
truefalse
|
|||
|
Ret nedeni
RejectionReason
|
Bir başvurunun neden reddedildiğini açıklayan kod veya açıklama. | ||
|
Açıklama
Başvurunun nihai durumu Reddedildi olduğunda bu öznitelik, ret nedenini belirtir. Kimlik doğrulamasının başarısız olması, yaptırım listesi eşleşmesi veya eksik dokümantasyon örnek olarak verilebilir. Bu veri, Başvuru ret nedenleri ve aşamaları Dashboardunun temel girdisidir. Ret nedenlerini incelemek, süreçteki yaygın aksama noktalarını belirlemeye yardımcı olur. Elde edilen bulgular başvuru yönergelerini, müşteri iletişimini veya kurum içi inceleme ölçütlerini iyileştirmek için kullanılabilir. Başvuruların neden reddedildiğini anlamak, genel onay oranını artırmanın temelidir.
Neden önemli?
İşe alım sürecindeki başarısızlıkların nedenlerini doğrudan gösterir ve başvuru onay oranını artırmaya yönelik iyileştirmeler yapmanızı sağlar.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Başvuru durumu Reddedildi olarak ayarlandığında doldurulan bir alanda bulunabilir.
Örnekler
Yaptırım listesi eşleşmesiEksik dokümantasyonKimlik doğrulaması başarısızYüksek risk profili
|
|||
|
SLA durumu
SlaStatus
|
Tamamlanan başvurunun SLA hedefini karşılayıp karşılamadığını belirtir. | ||
|
Açıklama
Bu öznitelik, tamamlanan her vakayı SLA hedef tarihi koşulunu karşılayıp karşılamadığına göre sınıflandırır. Yaygın değerler Karşılandı ve İhlal edildi şeklindedir. Bu hesaplanan alan, SLA hedeflerine uyum izleme Dashboardunun ve SLA uyum oranı KPI’ının temelini oluşturur. Hizmet taahhütlerine göre performansı genel hatlarıyla gösterir ve SLA ihlali yaşanan vakaların ortak özelliklerini anlamak için ayrıntılı inceleme yapmanızı sağlar.
Neden önemli?
SLA performansını karşılandı veya ihlal edildi şeklinde açıkça gösterir; hizmet düzeyi hedeflerine uyumu izlemeyi, raporlamayı ve analiz etmeyi kolaylaştırır.
Nereden alınır?
Bu hesaplanan öznitelik, her vaka için son etkinliğin zaman damgası SLA hedef tarihiyle karşılaştırılarak elde edilir.
Örnekler
Karşılandıİhlal edildiRisk altında
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden en son yenilendiği veya alındığı zamanı gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, veri setinin en son ne zaman güncellendiğini gösteren zaman damgasını içerir. Genellikle veri çıkarma ve yükleme işlemi sırasında veri setinin tamamına uygulanır. Bu bilgi, Dashboard kullanıcılarının inceledikleri verilerin ne kadar güncel olduğunu anlamalarına yardımcı olur. Kararların ihtiyaç duyulan güncellikteki verilere dayanmasını sağlar ve içgörülerin ne zaman elde edildiğine ilişkin beklentileri yönetmeye yardımcı olur.
Neden önemli?
Verilerin güncelliğini anlamak için gerekli bağlamı sunar; analizlerin geçerliliğini korumasına ve kararların güncelliğini yitirmiş bilgilere dayanmamasına yardımcı olur.
Nereden alınır?
Bu değer genellikle ETL (Extract, Transform, Load) işlemi sırasında oluşturulur ve veri setine eklenir.
Örnekler
2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
|
|||
|
Uyumluluk inceleme sorumlusu
ComplianceReviewer
|
Uyumluluk incelemesi etkinlikleri için özel olarak görevlendirilen kullanıcı veya temsilci. | ||
|
Açıklama
Atanan kullanıcı herhangi bir etkinliği gerçekleştiren kullanıcıyı belirtirken, bu öznitelik özellikle önemli inceleme adımlarında görev alan uyumluluk uzmanını gösterir. Böylece uyumluluk işlevini daha yakından inceleyebilirsiniz. Bu öznitelik, Uyumluluk inceleme süresi ve birikmiş işler Dashboardu için temel niteliktedir. Uyumluluk ekibinin iş yükünü ve performansını incelemenize; belirli inceleme sorumlularının darboğaz oluşturup oluşturmadığını veya ekibin genel olarak yeterli kaynağa sahip olup olmadığını belirlemenize yardımcı olur.
Neden önemli?
Uyumluluk işlevini yakından incelemenizi, bu önemli ve sıklıkla geciken süreç aşamasında inceleme sorumlularının iş yükünü ve performansını ayrıntılı analiz etmenizi sağlar.
Nereden alınır?
LexisNexis Risk Solutions dokümantasyonuna veya sistem yöneticinize başvurun. Atanan kullanıcı alanı, uyumlulukla ilgili etkinliklere göre filtrelenerek bu bilgi elde edilebilir.
Örnekler
c.joness.patelsystem_escalation
|
|||
|
Yeniden çalışma mı
IsRework
|
Yeniden çalışma döngüsüne dahil olan etkinlikleri belirten işaret. | ||
|
Açıklama
Bu mantıksal işaret, aynı vakada bir etkinlik tekrarlandığında true olarak ayarlanır. Örneğin Ek bilgi istendi etkinliğinden sonra Belge incelemesi yapıldı etkinliğinin ikinci kez gerçekleşmesi bu duruma örnektir. Sürecin önceki bir adıma döndüğünü gösterir. Yeniden çalışma mı özniteliği, Yeniden çalışma ve tekrar analizi Dashboardu ile Yeniden çalışma döngüsü yüzdesi KPI’ı için gereklidir. Boşa harcanan çabayı ölçmenize ve belirsiz talimatlar ya da düşük veri kalitesi gibi yeniden çalışmanın temel nedenlerini belirlemenize yardımcı olur. Böylece hedefe yönelik süreç iyileştirmeleri yapabilirsiniz.
Neden önemli?
Süreçteki verimsizliği ve boşa harcanan çabayı doğrudan ölçer; sık tekrarlanan, maliyetleri ve çevrim sürelerini artıran etkinlikleri ortaya çıkarır.
Nereden alınır?
Bu hesaplanan öznitelik, genellikle Process Mining aracı tarafından bir vakadaki tekrarlanan etkinlik dizileri belirlenerek elde edilir.
Örnekler
truefalse
|
|||
KYC müşteri kabul süreci etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Başvuru gönderildi
|
Müşterinin başvurusunun sisteme ilk ulaştığı anı, yani KYC müşteri kabul sürecinin başlangıcını belirtir. Bu olay genellikle başvuru formu, LexisNexis ile entegre müşteri portalı veya kurum içi veri giriş sistemi üzerinden gönderildiğinde açıkça kaydedilir. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç olayıdır. Bu etkinlikten tamamlanma anına kadar geçen süreyi analiz etmek, baştan sona çevrim süresini ve SLA hedeflerine uyumu ölçmek için önemlidir.
Nereden alınır?
Yeni müşteri başvuru kaydının ilk oluşturulma zaman damgasını tutan sistem günlüklerinden veya başvuru tablosundan alınır.
Kaydedin
Ana başvuru tablosunda yeni bir başvuru vakası veya kaydı oluşturulduğunda olay kaydedilir.
Olay türü
explicit
|
|||
|
Başvuru onaylandı
|
Müşterinin başvurusunu onaylama kararı verilir ve sisteme kaydedilir. Bu önemli bir iş sonucudur ve neredeyse her zaman açık bir durum değişikliği olarak tutulur. | ||
|
Neden önemli?
Bu dönüm noktası, karar sürecinin başarıyla tamamlandığını gösterir. Onaya giden yolları analiz etmek, iyi uygulamaları belirlemeye yardımcı olur.
Nereden alınır?
Başvuru vaka kaydında durumun 'Onaylandı' veya benzer bir son duruma ayarlandığı nihai güncellemeyi arayın.
Kaydedin
Ana başvuru veya vaka tablosunda nihai ve kesin bir durum değişikliği olarak kaydedilir.
Olay türü
explicit
|
|||
|
Başvuru reddedildi
|
Müşterinin başvurusunu reddetme kararı kaydedilir. Bu, sistemde kesin bir durum değişikliğiyle tutulan son olaydır. | ||
|
Neden önemli?
Bu, başarısızlık durumunu gösteren temel bitiş olayıdır. Süreci iyileştirmek için retlerin hangi aşamalarda gerçekleştiğini ve nedenlerini analiz etmek önemlidir.
Nereden alınır?
Başvuru kaydındaki son durum alanının 'Reddedildi', 'Kabul edilmedi' veya benzer bir son duruma ayarlanmasından alınır.
Kaydedin
Ana başvuru veya vaka tablosunda nihai ve kesin bir durum değişikliği olarak kaydedilir.
Olay türü
explicit
|
|||
|
Belgeler alındı
|
Müşterinin gerekli belgeleri sisteme yüklediğini veya ilettiğini doğrular. Bu olay genellikle belge gönderim portalı tarafından açıkça oluşturulur ya da bir temsilci tarafından manuel olarak kaydedilir. | ||
|
Neden önemli?
Bu etkinlik bekleme süresini sona erdirir ve sonraki inceleme etkinliklerini başlatır. Veri toplama aşamasındaki önemli bir dönüm noktasıdır.
Nereden alınır?
Belge yönetim sistemi günlüklerinden veya yeni belgeler eklendiğinde başvuru dosyasına eklenen zaman damgalı kayıttan alınır.
Kaydedin
Bir belge başarıyla yüklendiğinde veya sistemde manuel olarak alındı şeklinde işaretlendiğinde olay kaydedilir.
Olay türü
explicit
|
|||
|
Müşteri kabulü tamamlandı
|
Bu olay, müşterinin tamamen etkin olduğunu doğrulayarak müşteri kabul sürecinin başarıyla tamamlandığını gösterir. Açık bir son durum olarak kaydedilebilir veya 'Hesap etkinleştirildi' olayından çıkarılabilir. | ||
|
Neden önemli?
Bu, başarı durumunu gösteren temel bitiş olayıdır. Müşteri kabulü başarıyla tamamlanan tüm müşteriler için baştan sona çevrim süresini hesaplamakta gereklidir.
Nereden alınır?
'Hesap etkinleştirildi' zaman damgasından çıkarılır veya vaka dosyasındaki 'Müşteri kabulü tamamlandı' gibi nihai bir durumdan alınır.
Kaydedin
Hesabın etkinleştirilmesi gibi son önemli olumlu olaydan veya nihai durum güncellemesinden çıkarılır.
Olay türü
inferred
|
|||
|
Risk değerlendirmesi yapıldı
|
Sistem, toplanan bilgilere ve yapılan kontrollere göre müşteri için bir risk skoru hesaplar. Bu, LexisNexis’in temel özelliklerinden biridir ve genellikle vaka geçmişinde otomatik bir olay olarak açıkça kaydedilir. | ||
|
Neden önemli?
Bu değerlendirmenin sonucu, gelişmiş durum tespiti gerekip gerekmediği gibi sonraki süreç yolunu belirler. İş akışında önemli bir karar noktasıdır.
Nereden alınır?
Risk puanlama veya değerlendirme modülünün tamamlandığını kaydeden olayı, başvurunun denetim günlüğünde ya da iş akışı geçmişinde arayın.
Kaydedin
Risk motoru analizini tamamlayıp bir risk profili veya skoru atadığında belirli bir olay kaydedilir.
Olay türü
explicit
|
|||
|
Uyumluluk incelemesi başlatıldı
|
Genellikle yüksek riskli başvurular için vaka, manuel inceleme amacıyla bir uyumluluk sorumlusuna veya ekibine atanır. Bu durum çoğu zaman 'Uyumluluk incelemesi bekleniyor' durumuna geçişten veya görev atama günlüğünden çıkarılır. | ||
|
Neden önemli?
Bu adım, manuel ve çoğu zaman uzun süren bir incelemenin başlangıcını gösterir. Bu noktadan tamamlanmaya kadar geçen süreyi ölçmek, uyumlulukla ilgili darboğazları belirlemeye yardımcı olur.
Nereden alınır?
Görev atama günlüğünden, vaka sahipliğinin uyumluluk ekibine geçmesinden veya vaka geçmişindeki durum güncellemesinden alınır.
Kaydedin
'Uyumluluk incelemesinde' gibi bir durum değişikliğinden veya vakanın uyumlulukla ilgili bir kullanıcı kuyruğuna atanmasından çıkarılır.
Olay türü
inferred
|
|||
|
Uyumluluk incelemesi tamamlandı
|
Uyumluluk sorumlusu incelemesini tamamlayıp bir öneride bulunur ve vakayı sonraki aşamaya taşır. Görev 'tamamlandı' olarak işaretlendiğinde bu olay açıkça kaydedilebilir. Ayrıca durumun 'Uyumluluk bekleniyor' aşamasından başka bir duruma geçmesinden de çıkarılabilir. | ||
|
Neden önemli?
Bu önemli dönüm noktası, sürecin kritik ve çoğu zaman manuel yürütülen bir bölümünü sona erdirir. Uyumluluk incelemesinin süresini ölçmek için bitiş noktasıdır.
Nereden alınır?
Uyumluluk görevinin tamamlanma zaman damgasından veya 'Uyumluluk incelemesinde' durumundan çıkıştan alınır.
Kaydedin
İncelemenin bittiğini gösteren bir durum değişikliğinden, örneğin 'Onaylandı', 'Reddedildi' veya 'Nihai karar' durumuna geçişten çıkarılır.
Olay türü
inferred
|
|||
|
Belge incelemesi yapıldı
|
Bir kullanıcı veya otomatik araç, gönderilen belgelerin gerçekliğini, geçerliliğini ve eksiksizliğini inceler. Bu etkinlik, 'Belgeler alındı' durumundan 'İnceleme tamamlandı' durumuna geçişten veya açık bir günlük kaydından çıkarılabilir. | ||
|
Neden önemli?
Bu adım, darboğazların ve yeniden çalışmanın sık görülen nedenlerinden biridir. Verimliliği artırmak ve otomasyon fırsatlarını belirlemek için işlem süresini ve tekrar sayısını analiz etmek önemlidir.
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üre izlenerek çıkarılır.
Kaydedin
Belgenin alındığı olay ile incelemenin tamamlandığını belirten olay arasındaki süre olarak hesaplanır.
Olay türü
inferred
|
|||
|
Belgeler istendi
|
Sistem veya bir kullanıcı, müşteriden sürücü belgesi ya da fatura gibi belirli belgeleri ister. Bu olay, sistemin oluşturduğu iletişim günlüklerinden veya vakanın belge beklediğini gösteren durum değişikliğinden alınabilir. | ||
|
Neden önemli?
Bu etkinlik sürece çoğu zaman önemli bir bekleme süresi ekler. Sıklığını ve süresini analiz etmek, müşteri yanıtlarından kaynaklanan gecikmeleri belirlemeye yardımcı olur.
Nereden alınır?
Müşteriye gönderilen iletişim günlüklerinde bir olay veya başvuruda, örneğin 'Müşteri belgeleri bekleniyor' şeklinde bir durum değişikliği arayın.
Kaydedin
'Belgeler bekleniyor' durumuna geçişten veya giden iletişim kaydının zaman damgasından çıkarılır.
Olay türü
inferred
|
|||
|
Ek bilgi istendi
|
Bir uyumluluk sorumlusu veya incelemeyi yapan kişi, müşteriden ek bilgi ya da açıklama ister. Bu olay yeniden çalışmanın başlıca nedenlerinden biridir ve genellikle açık bir durum değişikliği veya iletişim günlüğü kaydı olarak tutulur. | ||
|
Neden önemli?
Bu etkinlik, müşteri kabul çevrim süresini uzatan yeniden çalışma döngüleri oluşturur. Sıklığını izlemek, gerekliliklerin net olmadığı veya başvurularda sık görülen eksikliklerin bulunduğu noktaları belirlemeye yardımcı olur.
Nereden alınır?
'Müşteri bilgisi bekleniyor' durumuna geçişi veya giden iletişim Event Logunu arayın. Bu işlem çoğu zaman bir kullanıcı tarafından başlatılır.
Kaydedin
Bir temsilci 'Bilgi iste' özelliğini kullandığında kaydedilir. Bu işlem vaka durumunu değiştirir ve bir iletişim olayı kaydı oluşturabilir.
Olay türü
explicit
|
|||
|
Hesap etkinleştirildi
|
Onayın ardından müşterinin hesabı temel bankacılık veya hizmet platformunda resmen oluşturulur ve etkinleştirilir. Bu etkinlik genellikle denetim izine kaydedilir veya hesap oluşturulma tarihinden çıkarılır. | ||
|
Neden önemli?
Bu, müşteriye değer sunan son adımdır. 'Başvuru onaylandı' ile bu adım arasındaki gecikmeler, sistem entegrasyonuyla ilgili sorunlara işaret edebilir.
Nereden alınır?
Hesap oluşturma günlüğünden, başka bir sisteme yapılan API çağrısından veya hesap kaydının oluşturulma zaman damgasından alınır.
Kaydedin
Onaydan sonra ayrı bir olay olarak kaydedilir veya müşteri kaydındaki etkinleştirme zaman damgasından belirlenir.
Olay türü
explicit
|
|||
|
İlk tarama yapıldı
|
Sistem, başvuru gönderildikten hemen sonra temel veri bütünlüğünü doğrulamak ve ilk kontrolleri yapmak için otomatik bir kontrol gerçekleştirir. Bu etkinlik genellikle süreç iş akışı geçmişinde açıkça kaydedilen otomatik bir adımdır. | ||
|
Neden önemli?
İlk aşamada başarısız olan başvuruları belirleyerek veri kalitesi sorunlarını anlamanıza yardımcı olur. Ayrıca süreçte değer sağlayan ilk otomatik adımdır.
Nereden alınır?
İlk tarama adımının tamamlandığını gösteren otomatik kural çalıştırma günlüklerini veya başvuru iş akışı geçmişindeki durum değişikliğini bulun.
Kaydedin
Tamamlanmış otomatik bir görev veya vaka geçmişindeki belirli bir durum güncellemesi olarak kaydedilir.
Olay türü
explicit
|
|||
|
Kimlik doğrulama başlatıldı
|
Sistemin veritabanlarında sorgulama gibi LexisNexis hizmetlerini kullanarak temel kimlik doğrulama sürecini başlattığı noktayı belirtir. Doğrulama hizmeti çağrıldığında genellikle Event Loga açıkça kaydedilir. | ||
|
Neden önemli?
Bu etkinlik, kritik ve çoğu zaman uzun süren bir alt sürecin başlangıcını gösterir. Süresini izlemek, kimlik kontrolleriyle ilgili darboğazları belirlemeye yardımcı olur.
Nereden alınır?
Kimlik doğrulama modülüne yapılan API çağrılarının günlüklerinden veya doğrulama görevinin başladığını gösteren denetim izi kaydından alınır.
Kaydedin
Sistemin kimlik doğrulama modülü veya API’si başvuru için çalıştırıldığında olay kaydedilir.
Olay türü
explicit
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
KYC müşteri kabul sürecinde Process Mining yolculuğunuza başlamak için bu Templateten yararlanın. Verilerinizi bugün uygulanabilir içgörülere dönüştürmeye başlayın.
KYC müşteri kabul sürecinizi iyileştirin, başvuruların yarıda bırakılmasını azaltın
Sorunsuz bir müşteri kabul süreci sağlayın, süreyi yalnızca 24 saate indirin.
Kredi kartı gerekmez. Bugün iyileştirmeye başlayın.