KYC müşteri işe alımı Veri Seti Templateiniz
KYC müşteri işe alımı Veri Seti Templateiniz
- Olay günlüğünüz için önerilen öznitelikler
- Süreç boyunca izlenecek temel faaliyetler
- Pratik veri çıkarma yönlendirmeleri
KYC Müşteri Kabulü Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Başlangıç zamanı
EventTime
|
Bir etkinliğin veya olayın ne zaman başladığını gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, bir etkinliğin başladığı kesin tarih ve saati kaydeder. Tek bir müşteri başvurusu vakasındaki tüm olayların kronolojik sırasını sağlar. Zaman damgaları, performansa dayalı süreç analizi için temel veridir. Etkinliklerin süresini, adımlar arasındaki bekleme süresini ve işe alım sürecinin uçtan uca toplam çevrim süresini hesaplamak için kullanılır. Bu veri, darboğazları belirlemek, SLA uyumluluğunu ölçmek ve süreç verimliliğini anlamak açısından büyük önem taşır.
Neden önemli?
Zaman damgaları, süreleri hesaplamak, süreç performansını analiz etmek ve gecikmeleri belirlemek için gereken kronolojik bağlamı sağlar.
Nereden alınır?
Bu, Pega'nın denetim izinin standart bir parçasıdır ve geçmiş tablolarında her olay için genellikle pxTimeCreated alanında bulunur.
Örnekler
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
|
|||
|
Etkinlik
ActivityName
|
İşe alım sürecinde gerçekleşen belirli olayın veya görevin adı. | ||
|
Açıklama
Bu öznitelik, 'Başvuru Gönderildi', 'Uyumluluk İncelemesi Başlatıldı' veya 'Başvuru Reddedildi' gibi bir iş etkinliğinin ya da sistem olayının adını kaydeder. Genel müşteri işe alım sürecindeki tek bir adımı temsil eder. Etkinlikleri analiz etmek, Process Mining'in temelini oluşturur. Bu öznitelik, farklı adımlar arasındaki akışı gösteren süreç haritasını oluşturmak için kullanılır. Olayların sırasını belirlemeye, her etkinliğin sıklığını ölçmeye ve en yaygın ya da en fazla zaman alan görevleri saptamaya yardımcı olur.
Neden önemli?
Bu öznitelik, süreç haritasındaki adımları tanımlar ve süreç akışını görselleştirmeyi, analiz etmeyi ve anlamayı mümkün kılar.
Nereden alınır?
Bu bilgiler genellikle Pega'nın denetim izinde, yani geçmiş tablolarında tutulur veya vakanın durum değişikliklerinden türetilebilir.
Örnekler
İlk tarama tamamlandıUyumluluk incelemesi tamamlandıBaşvuru onaylandı
|
|||
|
Müşteri başvurusu
CustomerApplication
|
Her müşteri işe alım başvurusu vakası için benzersiz tanımlayıcı. | ||
|
Açıklama
Müşteri Başvurusu, tek bir müşterinin işe alım yolculuğuyla ilgili tüm etkinlikleri ve olayları gruplandıran birincil vaka tanımlayıcısıdır. Her başvuru, gönderimden onaya ve hesabın etkinleştirilmesine ya da reddedilmeye kadar ilerler. Process Mining kapsamında bu öznitelik, her başvurunun uçtan uca yolculuğunu yeniden oluşturmak için gereklidir. Analistlerin olayların eksiksiz sırasını görmesine, her başvurunun durumunu izlemesine ve farklı yolları karşılaştırmasına imkan verir. Vakaları bu kimliğe göre analiz etmek, yaygın süreç varyantlarını, darboğazları ve standart prosedürden sapmaları belirlemeye yardımcı olur.
Neden önemli?
Bu kimlik, tüm bağımsız olayları analiz edilebilen tutarlı uçtan uca süreç örneklerinde birleştirdiği için Process Mining'in temelini oluşturur.
Nereden alınır?
Bu, Pega'daki genellikle birincil vaka kimliğidir ve ana vaka türündeki iş nesnesinde çoğunlukla pzInsKey veya iş birimlerinin kolayca anlayabileceği eşdeğer bir alan olarak bulunur.
Örnekler
APP-2023-00123APP-2023-00124APP-2023-00125
|
|||
|
Başvuru durumu
ApplicationStatus
|
Müşteri başvurusunun nihai sonucu veya mevcut durumu. | ||
|
Açıklama
Bu öznitelik, sürecin sonunda başvurunun genel durumunu, örneğin 'Onaylandı', 'Reddedildi' veya 'Geri çekildi', gösterir. Devam eden vakalar için bilinen son durumu da yansıtabilir. Bu, sonuç analizi için temel bir boyuttur. Vakaları segmentlere ayırmak ve belirli sonuçların neden ortaya çıktığını anlamak amacıyla doğrudan 'Başvuru reddi analizi' Dashboardunda kullanılır. Farklı durumlara götüren süreç akışlarını analiz etmek, onaylanan vakalardaki en iyi uygulamaları ve reddedilen vakaların temel nedenlerini belirlemenize yardımcı olur.
Neden önemli?
Bir vakanın iş sonucunu tanımlar ve başarılı yollarla başarısız yolları karşılaştıran ayrıntılı analizler yapılmasını sağlar.
Nereden alınır?
Bu, genellikle Pega'daki vaka iş nesnesinin nihai durumu olan pyStatusWork alanıdır.
Örnekler
OnaylandıReddedildiUyumluluk BekleniyorMüşteri Tarafından Geri Çekildi
|
|||
|
Bitiş zamanı
EndTime
|
Bir etkinliğin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, bir etkinliğin sona erdiği kesin tarih ve saati kaydeder. Tek tek etkinliklerin işlem süresini hesaplamak için Başlangıç zamanı ile birlikte kullanılır. Ayrı bir Bitiş zamanı bulunması, performans analizinin daha doğru yapılmasını sağlar. Etkin işlem süresiyle, yani Başlangıç zamanı ile Bitiş zamanı arasındaki süreyle, bekleme süresini, yani bir etkinliğin Bitiş zamanı ile sonraki etkinliğin Başlangıç zamanı arasındaki süreyi ayırmaya yardımcı olur. Bu ayrım, gerçek darboğazları kuyruklardan ayırmak için gereklidir.
Neden önemli?
Etkinliklerin işlem süresini kesin biçimde hesaplamayı sağlar. Bu, ayrıntılı performans analizi ve darboğazların belirlenmesi için gereklidir.
Nereden alınır?
Bu bilgi Pega'nın denetim izinde bulunabilir veya mevcut etkinliğin Bitiş zamanı olarak sonraki olayın Başlangıç zamanı kullanılarak türetilebilir.
Örnekler
2023-10-26T10:15:00Z2023-10-26T18:05:20Z2023-10-27T11:00:00Z
|
|||
|
Departman
WorkGroup
|
Etkinlikten sorumlu departman veya işlevsel ekip. | ||
|
Açıklama
Bu öznitelik, etkinliği gerçekleştiren kullanıcının ait olduğu organizasyon birimini veya ekibi tanımlar. Örneğin 'Tarama ekibi', 'Uyumluluk' veya 'İşe alım operasyonları'. Süreci departmana göre analiz etmek, 'Departmana göre iş yükü dağılımı' Dashboardu için büyük önem taşır. Yöneticilerin işin farklı ekipler arasında nasıl aktığını anlamasına, işlevler arası darboğazları belirlemesine ve tüm işe alım sürecindeki kaynak tahsisini değerlendirmesine yardımcı olur. Devir teslimleri optimize etmek ve iş yüklerini dengelemek için temel bir özniteliktir.
Neden önemli?
Farklı iş birimleri arasındaki süreç akışını ve darboğazları analiz etmeyi sağlar; kaynak yönetimini ve organizasyonel iyileştirmeyi destekler.
Nereden alınır?
Bu bilgi genellikle Pega'daki kullanıcı profiliyle, yani Operator ID kaydıyla ilişkilidir ve olay verileriyle birleştirilebilir. İlgili özellik pyWorkGroup olabilir.
Örnekler
İlk TaramaUyumluluk İncelemesiHesap Aktivasyonu
|
|||
|
Kullanıcı
OperatorId
|
Etkinliği gerçekleştiren kullanıcının benzersiz tanımlayıcısı. | ||
|
Açıklama
Bu öznitelik, uyumluluk görevlisi veya otomatik tarama botu gibi KYC sürecindeki belirli bir görevi tamamlayan çalışanın ya da sistem kullanıcısının kimliğini saklar. Otomatik adımlarda bu, bir sistem veya hizmet hesabının kimliği olabilir. Kullanıcı bazında analiz yapmak, iş yükünün dağılımını, bireysel performansı ve eğitim ihtiyaçlarını anlamaya yardımcı olur. Ayrıca standart dışı süreç akışlarında hangi kullanıcıların veya ekiplerin yer aldığını belirleyerek süreç sapmalarını incelemek için kullanılabilir.
Neden önemli?
Bu öznitelik, süreç etkinliklerini belirli kişilerle veya ekiplerle ilişkilendirerek iş yükü analizine, performans değerlendirmesine ve uyumluluk kontrollerine imkan verir.
Nereden alınır?
Bu, Pega'nın denetim izindeki standart bir alandır ve geçmiş tablolarında genellikle pxUpdateOperator veya benzer bir özellik olarak saklanır.
Örnekler
j.doe@acmebank.comkyc_analyst_04system_auto_agent
|
|||
|
Ret nedeni
RejectionReason
|
Bir başvurunun neden reddedildiğini belirtir. | ||
|
Açıklama
Bir başvurunun nihai durumu 'Reddedildi' olduğunda bu öznitelik, 'Arka plan kontrolü başarısız', 'Belgeler eksik' veya 'Yüksek risk profili' gibi belirli nedeni gösterir. Bu öznitelik, 'Başvuru reddi analizi' Dashboardunun temel girdisidir. Reddedilen vakaları nedene göre segmentlere ayırarak işe alım sürecindeki en yaygın başarısızlık noktalarını belirleyebilirsiniz. Bu içgörü, reddetme oranını azaltmak, müşteri deneyimini iyileştirmek ve operasyonel verimliliği artırmak için hedefli iyileştirmeler uygulamanıza yardımcı olur.
Neden önemli?
Başvuruların neden başarısız olduğuna ilişkin uygulanabilir içgörüler sunar ve başarı oranını artıracak hedefli süreç iyileştirmelerine imkan verir.
Nereden alınır?
Bu, vakanın 'Reddedildi' durumuna geçmesiyle ayarlanan özel bir özellik olabilir. Standart ret nedeni alanları için Pega KYC belgelerine başvurun.
Örnekler
Yaptırım BulgusuBelge UyumsuzluğuPEP TespitiYetersiz Bilgi
|
|||
|
Risk seviyesi
RiskLevel
|
Müşteri başvurusunun hesaplanan risk seviyesi. | ||
|
Açıklama
Bu öznitelik, müşteriye ilişkin değerlendirilen riski temsil eder ve genellikle 'Düşük', 'Orta' veya 'Yüksek' olarak sınıflandırılır. Risk seviyesi çoğunlukla müşteri verileri ve tarama sonuçlarına dayalı otomatik bir puanlama motoru tarafından belirlenir. Risk seviyesi, süreç varyasyonlarının önemli bir belirleyicisidir. Yüksek riskli başvurular, daha ayrıntılı bir uyumluluk incelemesi gibi ek durum tespiti adımları gerektirebilir ve bu da daha uzun çevrim sürelerine yol açar. Süreci risk seviyesine göre analiz etmek, bu farklılıkları açıklamaya ve gereksiz gecikmelere neden olmadan risk kontrollerinin etkili biçimde çalışmasını sağlamaya yardımcı olur.
Neden önemli?
Risk seviyesi gerekli durum tespiti düzeyini belirlediği için süreç yolundaki ve süresindeki farklılıkları açıklar.
Nereden alınır?
Bu, Pega karar kuralı veya puanlama modeli tarafından doldurulan, vaka üzerinde hesaplanan bir özellik olabilir. Pega KYC belgelerine başvurun.
Örnekler
DüşükOrtaYüksek
|
|||
|
SLA hedef tarihi
SlaTargetDate
|
Müşteri işe alım vakasının tamamlanmasının beklendiği tarih. | ||
|
Açıklama
Bu öznitelik, hizmet düzeyi anlaşmasında tanımlanan başvuru hedef tamamlanma tarihini saklar. SLA; müşteri türü, risk düzeyi veya ürün gibi etkenlere göre değişebilir. Bu tarih, 'SLA uyumluluk takibi' Dashboardu ve ilgili KPI için gereklidir. Gerçek tamamlanma tarihinin karşılaştırıldığı ölçüt olarak kullanılır. SLA hedefini kaçıran vakaları analiz etmek, sistemik gecikmeleri belirlemenize ve hizmet taahhütlerine uyumu sağlamak için süreç iyileştirmelerine öncelik vermenize yardımcı olur.
Neden önemli?
Zamanında tamamlanma performansını ölçmek için bir referans noktası sağlar. Bu, müşteri memnuniyeti ve operasyonel kontrol açısından önemlidir.
Nereden alınır?
Pega'da yerleşik bir SLA yönetim çerçevesi bulunur. Bu tarih genellikle pySLAGoal gibi özelliklerde veya vaka üzerinde özel olarak tanımlanan bir SLA alanında saklanır.
Örnekler
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
|
|||
|
Belge durumu
DocumentStatus
|
Müşterinin sağladığı belgelerin mevcut durumu. | ||
|
Açıklama
Bu öznitelik, KYC süreci için gerekli belgelerin durumunu izler. Değerler arasında 'Müşteri bekleniyor', 'Alındı', 'Doğrulandı' ve 'Reddedildi' bulunur. Bu durum tek bir vaka boyunca birden çok kez değişebilir. Bu, 'İşe alım işlem hacmi ve durumu' Dashboardu ile 'Belge doğrulama hızı' analizi için temel bir özniteliktir. En yaygın darboğaz alanlarından birini ayrıntılı biçimde görmenizi sağlar. Belgelerin her durumda ne kadar süre kaldığını izleyerek müşteri gönderimindeki veya iç incelemedeki gecikmeleri belirleyebilirsiniz.
Neden önemli?
Belge işleme alt sürecini görünür kılar ve belge doğrulamadaki yaygın gecikmelerin belirlenmesine ve giderilmesine yardımcı olur.
Nereden alınır?
Bu, ana vakayla ilişkili bir veri nesnesi veya sayfa listesinde bulunan ve gerekli her belgeyi izleyen bir özellik olabilir. Pega KYC belgelerine başvurun.
Örnekler
Yükleme BekleniyorAlındı, İnceleme BekleniyorOnaylandıReddedildi, Daha Fazla Bilgi Gerekli
|
|||
|
Çevrim süresi
CycleTime
|
Başvurunun gönderilmesinden nihai çözüme kadar geçen toplam süre. | ||
|
Açıklama
Bu hesaplanan metrik, her müşteri başvurusunun ilk olaydan son olaya kadar uçtan uca süresini ölçer. Genellikle belirli bir vaka için son etkinliğin zaman damgası ile ilk etkinliğin zaman damgası arasındaki fark olarak hesaplanır. Çevrim süresi, süreç verimliliği ve müşteri deneyimi için temel performans göstergelerinden biridir. Ortalama işlem sürelerini izlemek, uzun süren vakaları belirlemek ve süreç iyileştirme çalışmalarının zaman içindeki etkisini takip etmek amacıyla 'Genel işe alım çevrim süresi analizi' Dashboardunda kullanılır.
Neden önemli?
Bu, işe alım sürecinin müşterinin bakış açısından genel hızını ve verimliliğini doğrudan ölçen temel bir KPI'dır.
Nereden alınır?
Bu metrik, her vaka kimliği için maksimum ve minimum zaman damgaları arasındaki fark alınarak Process Mining aracında hesaplanır.
Örnekler
5 gün 4 saat12 gün 1 saat2 gün 8 saat
|
|||
|
İşe alınan ürün
OnboardedProduct
|
Müşterinin başvurduğu finansal ürün. | ||
|
Açıklama
Bu öznitelik, müşterinin hangi ürün veya hizmet için işe alındığını belirtir. Örnek olarak 'Bireysel Banka Hesabı', 'Kurumsal Kredi' veya 'Yatırım Hizmetleri' verilebilir. Farklı ürünlerin farklı düzenleyici gereklilikleri ve karmaşıklık düzeyleri olabileceği için ürün, işe alım sürecini etkileyebilir. Süreci ürüne göre analiz etmek, belirli ürün gruplarında çevrim sürelerinin daha uzun veya ret oranlarının daha yüksek olup olmadığını belirlemeye ve ürüne özel süreç iyileştirmeleri için içgörü sağlamaya yardımcı olur.
Neden önemli?
Süreç analizinin ürün grubuna göre segmentlere ayrılmasını ve performans farklılıklarıyla iyileştirme fırsatlarının ortaya çıkarılmasını sağlar.
Nereden alınır?
Bu, başvuru sürecinin başında seçilen ve vaka üzerinde bulunan bir özellik olabilir.
Örnekler
Vadesiz HesapVarlık YönetimiTicari Kredi Limiti
|
|||
|
Kaynak sistem
SourceSystem
|
Verinin hangi sistemden geldiğini belirtir. | ||
|
Açıklama
Bu öznitelik, olayın kaydedildiği kaynak uygulamayı belirtir. Bu süreçte değer sürekli olarak 'Pega KYC' olur. Tüm veri tek bir sistemden geliyorsa gereksiz görünebilir. Ancak bu öznitelik, veri yönetişimi için önemlidir ve birden fazla sistemden veri entegre edilirken vazgeçilmez hale gelir. Verinin kaynağını netleştirir ve veri entegrasyonu sorunlarını gidermeye yardımcı olur.
Neden önemli?
Verinin kaynağı hakkında gerekli bağlamı sağlar, veri yönetişimini destekler ve birden fazla kaynak sistem arasında analiz yapılmasına imkan verir.
Nereden alınır?
Bu, genellikle veri çıkarma ve dönüştürme sürecinde Veri Seti'nin kaynağını belirtmek için eklenen sabit bir değerdir.
Örnekler
Pega KYCPega CLM
|
|||
|
Müşteri kimliği
CustomerId
|
İşe alımı yapılan müşterinin benzersiz tanımlayıcısı. | ||
|
Açıklama
Bu öznitelik, başvuruyu ana veri sistemindeki müşteri kaydına bağlayan benzersiz kimliktir. KYC sürecinin konusu olan kişi veya kuruluşu temsil eder. Başvuru kimliği süreci izlerken Müşteri kimliği, aynı müşterinin birden fazla başvurusu genelinde analiz yapılmasını veya süreç verilerinin segment ya da geçmiş gibi müşteriye özgü özniteliklerle zenginleştirilmesini sağlar. Böylece işe alım sürecine müşteri odaklı bir bakış sunar.
Neden önemli?
Süreç verilerini müşteri ana verilerine bağlar ve müşteri öznitelikleri ile geçmişine dayalı daha ayrıntılı analiz yapılmasını sağlar.
Nereden alınır?
Bu, KYC vakasındaki temel özelliklerden biridir ve vakayı Pega içindeki veya harici CRM'deki müşteri veri modeline bağlar.
Örnekler
CUST-98765CUST-98766CUST-98767
|
|||
|
Müşteri ülkesi
CustomerCountry
|
Müşterinin ikamet ettiği veya kuruluşunun bulunduğu ülke. | ||
|
Açıklama
Bu öznitelik, işe alımı yapılan müşteriyle ilişkilendirilen ülkeyi saklar. Bu bilgi, risk değerlendirmesi ve gerekli durum tespiti düzeyinin belirlenmesi için temel girdilerden biridir. Analiz sırasında müşterinin ülkesi önemli örüntüleri ortaya çıkarabilir. Bazı yargı bölgeleri daha yüksek riskle ilişkilendirilebilir ve bu durum daha uzun, daha karmaşık işe alım süreçlerine yol açabilir. Bu boyut, coğrafi temelli performans analizi yapılmasını ve bölgesel uyumluluk gerekliliklerinin verimli biçimde karşılanmasını sağlar.
Neden önemli?
Sürecin coğrafi olarak analiz edilmesini sağlar. Bu boyut genellikle düzenleyici karmaşıklık ve risk seviyeleriyle ilişkilidir.
Nereden alınır?
Bu, vakayla ilişkili müşteri veri nesnesindeki bir özellik olabilir.
Örnekler
USADEUSGPGBR
|
|||
|
Otomatik mi
IsAutomated
|
Bir etkinliğin sistem veya insan tarafından gerçekleştirilip gerçekleştirilmediğini gösteren işaret. | ||
|
Açıklama
Bu Boolean öznitelik, etkinlik tarama motoru veya sistem kuralı gibi otomatik bir aracı tarafından yürütüldüğünde true, insan kullanıcı tarafından gerçekleştirildiğinde false değerini alır. Otomatik ve manuel etkinlikleri ayırt etmek, otomasyon analizinin temelidir. Mevcut otomasyonun etkinliğini ölçmeye, gelecekte otomasyona uygun manuel görevleri belirlemeye ve süreçteki insanlarla sistem aktörleri arasındaki etkileşimi anlamaya yardımcı olur.
Neden önemli?
İnsanların gerçekleştirdiği etkinlikleri sistemlerin gerçekleştirdiği etkinliklerden ayırır. Bu ayrım, her otomasyon girişimi veya analizi için temeldir.
Nereden alınır?
Bu değer, olayla ilişkilendirilen kullanıcı kimliğinden türetilebilir. OperatorId bilinen bir sistem veya aracı hesabıyla eşleşiyorsa bu işaret true olarak ayarlanır.
Örnekler
truefalse
|
|||
|
SLA durumu
SlaStatus
|
Vakanın SLA hedefi içinde tamamlanıp tamamlanmadığını belirtir. | ||
|
Açıklama
Bu öznitelik, her tamamlanan vakayı gerçek tamamlanma zaman damgası ile 'SLA hedef tarihi' arasındaki karşılaştırmaya göre 'Zamanında' veya 'Gecikmiş' olarak sınıflandırır. Bu, 'SLA uyumluluk takibi' Dashboardu ve 'SLA uyumluluk oranı' KPI için temel metriktir. Hizmet düzeyi taahhütlerine göre performansı tek bakışta net biçimde görmenizi sağlar. Geciken vakaların özelliklerini analiz etmek, gecikmelerin temel nedenlerini belirlemenize ve gelecekteki SLA ihlali risklerini azaltmanıza yardımcı olur.
Neden önemli?
Taahhütlere göre performansı doğrudan ölçer. Bu, operasyon yönetimi, uyumluluk ve müşteri memnuniyeti açısından önemlidir.
Nereden alınır?
Vakanın son etkinliğinin zaman damgası SlaTargetDate alanıyla karşılaştırılarak türetilir. Tamamlanma zamanı hedeften sonraysa durum 'Geç' olur.
Örnekler
ZamanındaGecikmişRisk Altında
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Son veri yenileme veya çıkarma işleminin zaman damgası. | ||
|
Açıklama
Bu öznitelik, verilerin kaynak sistemden en son çıkarıldığı zamanı gösterir. Tek bir veri yüklemesindeki tüm kayıtlar için genellikle aynıdır. Bu zaman damgası, analiz edilen verilerin güncelliğini anlamak için önemlidir. Süreç analizinin ne kadar güncel olduğunu ve bir sonraki veri güncellemesinin ne zaman beklendiğini bilmenizi sağlar. Bu bilgi, operasyonel izleme Dashboardları için büyük önem taşır.
Neden önemli?
Kullanıcılara verilerin güncelliği hakkında bilgi verir ve analizin mevcut durumu mu yoksa geçmiş bir dönemi mi yansıttığını anlamalarını sağlar.
Nereden alınır?
Bu değer, veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde oluşturulur ve Veri Seti'ne eklenir.
Örnekler
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Vaka türü
CaseType
|
KYC işe alım vakasının özel türü. | ||
|
Açıklama
Bu öznitelik, işe alım başvurusunu 'Bireysel Müşteri', 'Kurumsal Müşteri' veya 'Yüksek Net Değerli Birey' gibi kategorilere ayırır. Farklı vaka türleri genellikle farklı adımlara, SLA'lara ve risk profillerine sahip ayrı süreç varyasyonlarını izler. Süreci Vaka türüne göre analiz etmek, performansın daha anlamlı biçimde karşılaştırılmasını sağlar. Belirli işe alım türlerinin gecikmeye veya redde daha yatkın olup olmadığını anlamaya yardımcı olur. Bu segmentasyon, süreç iyileştirmelerini farklı müşteri yolculuklarının özel ihtiyaçlarına göre uyarlamak için gereklidir.
Neden önemli?
Süreç verilerini ayrı kategorilere ayırmayı ve daha doğru, ilgili performans analizleri yapmayı sağlar.
Nereden alınır?
Bu, genellikle Pega'daki vaka örneğinin sınıf adıdır veya vakanın türünü tanımlayan özel bir özelliktir.
Örnekler
Bireysel Müşteri KabulüKurumsal Müşteri KabulüBasitleştirilmiş Durum Tespiti
|
|||
|
Yeniden işlem mi
IsRework
|
Bir etkinliğin yeniden işlem döngüsünün parçası olup olmadığını gösteren işaret. | ||
|
Açıklama
Bu boolean öznitelik, 'Belge incelemesi' gibi belirli bir etkinlik aynı vaka içinde birden fazla kez gerçekleştiğinde true değerini alır. Genellikle 'Ek bilgi istendi' gibi olaylar tarafından tetiklenir. Yeniden çalışmayı belirlemek, süreç verimsizliklerini ve müşteri açısından sorun oluşturan noktaları ortaya çıkarmak için gereklidir. 'Süreçte yeniden çalışma ve döngüler' Dashboardu, yeniden çalışmanın sıklığını ve etkisini ölçmek için bu özniteliği kullanır. Yeniden çalışmayı azaltmak çoğu zaman temel bir hedeftir. Çünkü bu, daha hızlı işlem, daha düşük operasyonel maliyet ve daha iyi müşteri deneyimi sağlar.
Neden önemli?
Süreç verimsizliklerini, gereksiz görevleri ve döngüleri görünür kılar. Bunlar süreç iyileştirmelerinin başlıca hedefleridir.
Nereden alınır?
Bu işaret, aynı vaka kimliği içindeki tekrarlanan etkinlik adları kontrol edilerek veri analizi sırasında türetilir. Örneğin 'Belge İncelemesi Tamamlandı' ikinci kez görünüyorsa.
Örnekler
truefalse
|
|||
KYC Müşteri Kabulü Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Başvuru gönderildi
|
Bu faaliyet, Pega sisteminde yeni bir müşteri edinimi vakasının oluşturulmasını ifade eder. Müşteri başvurusu için yeni bir vaka örneği, müşteri portalı, şirket içi kullanıcı veya otomatik veri akışı üzerinden resmen başlatıldığında kaydedilir. | ||
|
Neden önemli?
Bu, tüm müşteri edinimi sürecinin birincil başlangıç olayıdır. Uçtan uca çevrim süresini ölçmek ve başvuru hacimleri ile kalıplarını analiz etmek için gereklidir.
Nereden alınır?
Bu, yeni bir iş nesnesi (vaka) oluşturulduğunda Pega'nın denetim izinde kaydedilen açık bir olaydır. Vaka kimliği için pc_history_work tablosundaki ilk kaydı bulun.
Yakalayın
Vaka oluşturma zaman damgasından veya denetim izindeki ilk kayıttan alınır.
Olay türü
explicit
|
|||
|
Başvuru onaylandı
|
Müşterinin müşteri edinimi başvurusunu onaylamaya yönelik nihai kararı ifade eder. Vaka durumu nihai ve başarılı bir çözüm durumuna güncellendiğinde çıkarılan önemli bir iş kilometre taşıdır. | ||
|
Neden önemli?
Başarılı ve başarısız vakaları birbirinden ayıran önemli bir kilometre taşıdır. Nihai hesap etkinleştirme adımlarından önce gelir ve karar verme süresini ölçmek için yaygın olarak kullanılır.
Nereden alınır?
Vaka çözüm durumunun (pyStatusWork) 'Resolved-Completed' veya 'Resolved-Approved' gibi nihai bir başarı değerine ayarlandığı zaman damgasından çıkarılır.
Yakalayın
Vakanın denetim izinde başarılı çözümü gösteren pyStatusWork için yapılan son güncellemeyi belirleyin.
Olay türü
inferred
|
|||
|
Başvuru reddedildi
|
Müşterinin başvurusunu reddetmeye yönelik nihai kararı ifade eder ve müşteri edinimi sürecini sonlandırır. Vaka nihai ve başarısız bir çözüm durumuna taşındığında çıkarılır. | ||
|
Neden önemli?
Bu, birincil başarısızlık bitiş olayıdır. Başvuru Ret Oranını analiz etmek ve 'Rejection Reason' gibi öznitelikler üzerinden başarısızlık nedenlerini anlamak için gereklidir.
Nereden alınır?
Vaka çözüm durumunun (pyStatusWork) 'Resolved-Rejected' gibi nihai bir başarısızlık değerine ayarlandığı zaman damgasından çıkarılır.
Yakalayın
Vakanın denetim izinde ret durumunu gösteren pyStatusWork alanındaki son güncellemeyi belirleyin.
Olay türü
inferred
|
|||
|
Belgeler alındı
|
Müşterinin istenen tüm belgeleri sisteme yüklediği veya ilettiği anı gösterir. Genellikle Pega vakasına yeni ekler bağlandığında açık bir olay olarak kaydedilir. | ||
|
Neden önemli?
Bu, belge inceleme ve doğrulama SLA'ları için sürenin başlatıldığı önemli bir kilometre taşıdır. Bu noktadan önceki gecikmeler müşteriye, sonraki gecikmeler ise iç operasyonlara bağlıdır.
Nereden alınır?
Yeni bir belge vakayla ilişkilendirildiğinde Pega'nın ek tablolarına (pc_link_attachment veya pc_data_workattach) açıkça kaydedilir.
Yakalayın
Olay, vakaya bağlanan ilgili ek nesnesinin oluşturulma zaman damgasıdır.
Olay türü
explicit
|
|||
|
Müşteri edinimi tamamlandı
|
Tüm KYC müşteri edinimi sürecinin başarıyla sona erdiğini gösterir. Pega vakası, başarılı tamamlanmayı belirten nihai çözülmüş duruma ulaştığında ve tüm alt sistem işlemleri tamamlandığında kaydedilir. | ||
|
Neden önemli?
Süreç için birincil başarı bitiş olayıdır. Müşteri edinimi başarıyla tamamlanan tüm müşteriler için uçtan uca çevrim süresini hesaplamak açısından gereklidir.
Nereden alınır?
Vaka çözüm durumunun (pyStatusWork) 'Resolved-Completed' gibi nihai başarı değerine ayarlandığı zaman damgasından çıkarılır.
Yakalayın
History-Work tablosundaki son 'Resolved-Completed' durumunun zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Risk değerlendirmesi yapıldı
|
Başvuru ve doğrulama verilerine dayalı müşteri risk değerlendirmesi ile puanlamasının tamamlanmasını gösterir. Genellikle Pega vakasındaki risk değerlendirmesi aşaması veya adımı çözüldüğünde kaydedilen önemli bir kilometre taşıdır. | ||
|
Neden önemli?
Bu, uyumluluk açısından önemli bir kilometre taşıdır. Bu faaliyetin süresini ve sonucunu analiz etmek, risk yönetimi verimliliğini ve bunun süreç yoluna etkisini anlamak için gereklidir.
Nereden alınır?
Pega vaka modelindeki belirli bir aşamanın veya akışın tamamlanmasından çıkarılır ve denetim izine kaydedilen bir durum değişikliğiyle sonuçlanır.
Yakalayın
Risk değerlendirmesi aşamasından sonra pyStatusWork değerindeki değişiklikten çıkarılır. Örneğin durum 'Pending-Compliance-Review' olabilir.
Olay türü
inferred
|
|||
|
Uyumluluk incelemesi başlatıldı
|
Uyumluluk ekibinin resmi incelemesinin başlangıcını gösterir. Bu, sürecin önemli ve çoğu zaman uzun süren bir bölümüdür. Vaka uyumluluk iş kuyruğuna atandığında veya durumu buna göre güncellendiğinde kaydedilir. | ||
|
Neden önemli?
Uyumluluk İncelemesi Çevrim Süresi KPI'ı için başlangıç olayıdır. Bu önemli ve çoğu zaman manuel olan inceleme aşamasındaki darboğazları ölçmeye ve belirlemeye yardımcı olur.
Nereden alınır?
Vaka durumunun (pyStatusWork) 'Pending-Compliance' durumuna değişmesinden veya uyumluluk iş sepetinde bir atama oluşturulması olayından çıkarılır.
Yakalayın
Vakanın bir uyumluluk iş sepetine atandığı veya incelemenin başladığını gösteren durum değişikliğinin gerçekleştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Uyumluluk incelemesi tamamlandı
|
Uyumluluk ekibinin incelemesini tamamladığını ve bir öneride bulunduğunu gösterir. Vaka uyumluluk aşamasından çıkarıldığında gerçekleşen durum değişikliğiyle kaydedilir. | ||
|
Neden önemli?
Uyumluluk İncelemesi Çevrim Süresi KPI'ı için bitiş olayıdır. Bu noktaya kadar geçen süreyi analiz etmek, uyumluluk verimliliğini artırmak için büyük önem taşır.
Nereden alınır?
Vaka durumunun (pyStatusWork) 'Pending-Compliance' durumundan 'Pending-Final-Decision' veya 'Resolved-Approved' gibi bir duruma geçmesinden çıkarılır.
Yakalayın
Uyumluluk incelemesi aşamasının veya atamasının vaka geçmişinde tamamlandığı zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Arka plan kontrolü başlatıldı
|
Müşteri üzerinde üçüncü taraf hizmet entegrasyonlarını da içerebilen harici veya dahili arka plan kontrollerinin başlamasını ifade eder. Genellikle vakanın bu kontrollerin sonuçlarını beklediğini gösteren durum değişikliğinden çıkarılır. | ||
|
Neden önemli?
Bu faaliyet, harici bağımlılıkları beklerken geçen süreyi ayırmaya yardımcı olur. Üçüncü taraf hizmet performansını ve bunun toplam müşteri edinimi süresine etkisini analiz etmenizi sağlar.
Nereden alınır?
Pega'nın History-Work tablosuna kaydedilen vaka durumunun (pyStatusWork) 'Pending-Background-Check' veya benzer bir duruma değişmesinden çıkarılır.
Yakalayın
Arka plan kontrolü sürecinin başladığını gösteren pyStatusWork güncellemesinin zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Belge incelemesi tamamlandı
|
Bu faaliyet, bir uyumluluk görevlisinin veya otomatik bir sürecin müşteri tarafından gönderilen belgeleri incelemeyi tamamladığını gösterir. İnceleme adımının tamamlandığını belirten vaka veya belge durumu değişikliğinden çıkarılır. | ||
|
Neden önemli?
Belge Doğrulama Süresi KPI'ını tamamlar. Bu adımın tamamlanma süresini analiz etmek, manuel veya otomatik inceleme sürecindeki verimsizlikleri ortaya çıkarır.
Nereden alınır?
Denetim izinde vaka durumunun (pyStatusWork) 'Pending-Review' durumundan 'Review-Complete' veya 'Pending-Checks' durumuna geçmesinden çıkarılır.
Yakalayın
Belge doğrulama alt sürecinin çözüldüğünü gösteren vaka durumu (pyStatusWork) değişikliğinin zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Belgeler istendi
|
Sistem veya bir görevli, sürecin devam edebilmesi için müşteriden belirli belgelerin gerekli olduğuna karar verdiğinde gerçekleşir. Bir yazışmanın oluşturulması veya vaka durumunun 'Pending-Customer-Docs' gibi bir duruma değişmesi üzerinden kaydedilir. | ||
|
Neden önemli?
Bunu izlemek, müşterilerin yanıt vermesi için geçen süreyi ölçmeye ve sürecin belge beklerken sık sık durup durmadığını belirlemeye yardımcı olur. Belge Doğrulama Süresi KPI'ının öncülüdür.
Nereden alınır?
Açık bir yazışma olayı (pc_link_attachment) olarak kaydedilebilir veya denetim izinde kaydedilen vaka durumu değişikliğinden (pyStatusWork) çıkarılabilir.
Yakalayın
pyStatusWork değerinin 'Pending-Documents' veya benzer bir duruma geçmesinden çıkarılır. Ayrıca açık bir 'Send Correspondence' olayıyla ilişkilendirilebilir.
Olay türü
inferred
|
|||
|
Ek bilgi istendi
|
Genellikle uyumluluk alanındaki bir incelemeci, müşteriden daha fazla bilgi veya açıklama istediğinde gerçekleşir. Kullanıcının vakadan belirli bir yazışma göndermesiyle açıkça kaydedilir. | ||
|
Neden önemli?
Bu faaliyet, süreçteki yeniden çalışmanın ve döngülerin başlıca göstergesidir. Sıklığını izlemek, İlk Seferde İşleme Oranını ölçmek ve belirsiz gereklilikleri belirlemek için gereklidir.
Nereden alınır?
Denetim izine kaydedilen açık bir 'Send Correspondence' olayı olabilir. Alternatif olarak durumun 'Pending-Customer-Info' değerine değişmesinden çıkarılabilir.
Yakalayın
Belirli bir yazışma nesnesinin oluşturulmasından veya vaka çalışanı tarafından başlatılan akış eyleminden alınır.
Olay türü
explicit
|
|||
|
Hesap etkinleştirildi
|
Müşterinin hesabının ana bankacılık sisteminde veya ilgili alt sistemde başarıyla oluşturulup etkinleştirildiğini gösterir. Başarılı onaydan sonra Pega vakasındaki nihai durum güncellemesinden çıkarılır. | ||
|
Neden önemli?
Müşteri ve işletme için değerin ortaya çıktığı anı ifade eder. 'Application Approved' ile bu olay arasındaki süre, sistem devirlerinin verimliliğini ölçer.
Nereden alınır?
Denetim izine kaydedilen 'Resolved-AccountActive' gibi belirli bir vaka durumu (pyStatusWork) veya entegrasyon aracılığıyla vakaya ayarlanan bir işaretten çıkarılır.
Yakalayın
Alt sistemdeki hesabın etkin olduğunu gösteren vaka özelliği güncellemesinin zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
İlk tarama tamamlandı
|
Başvuru verilerinin eksiksizliği ve temel uygunluğu için genellikle otomatik gerçekleştirilen ilk incelemenin tamamlanmasını ifade eder. Bu olay çoğunlukla vaka durumundaki bir değişiklikten, örneğin 'New' durumundan 'Pending-Documents' durumuna geçişten çıkarılır. | ||
|
Neden önemli?
Bu ilk aşamada harcanan süreyi analiz etmek, veri doğrulama veya otomatik kural yürütümündeki ve tüm süreci geciktirebilecek erken darboğazları belirlemeye yardımcı olur.
Nereden alınır?
Pega denetim izinde History-Work tablosuna kaydedilen vaka durumu özelliğindeki (pyStatusWork) değişiklikten çıkarılır.
Yakalayın
pyStatusWork değerinin 'New' veya 'Submitted' durumundan 'ScreeningComplete' ya da benzer bir duruma geçtiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
Çıkarma rehberleri
Başlamaya hazır mısınız?
Bu Veri Seti Templatei, KYC müşteri işe alım sürecinizi optimize etmeye başlamanız için sağlam bir temel sunar. Verimsizlikleri bugün ortaya çıkarmaya ve uyumluluğu iyileştirmeye başlayın!
KYC müşteri kabulünü şimdi kolaylaştırın, gecikmeleri kalıcı olarak ortadan kaldırın
KYC sürecini daha akıcı hale getirin, müşteri kabulünü 24 saate indirin ve uyumluluğu artırın.
Kredi kartı gerekmez, dakikalar içinde kurulumu tamamlayın