> Perbaikan proses berkelanjutan > Penerimaan Nasabah KYC > LexisNexis Risk Solutions > Templat data

Templat data onboarding nasabah KYC Anda

LexisNexis Risk Solutions

Atribut onboarding nasabah KYC(20) Aktivitas onboarding nasabah KYC(14) Panduan ekstraksi(1)

Templat data onboarding nasabah KYC Anda

Templat ini memandu Anda mengumpulkan data yang diperlukan untuk menganalisis proses onboarding nasabah KYC. Templat ini menjelaskan atribut penting yang perlu dikumpulkan, aktivitas utama yang perlu dilacak, serta cara mengambil informasi tersebut dari sistem sumber. Gunakan panduan ini untuk menyusun log peristiwa yang dapat membantu Anda memahami proses onboarding secara mendalam.

Atribut yang disarankan untuk dikumpulkan
Aktivitas utama yang perlu dilacak
Panduan ekstraksi

Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Unduh template

Atribut onboarding nasabah KYC

Berikut kolom data yang disarankan untuk dicantumkan dalam log peristiwa agar analisis dan penemuan proses onboarding nasabah KYC lebih akurat.

3 Wajib 6 Disarankan 11 Opsional

	Nama	Deskripsi
	Aplikasi pelanggan CustomerApplication	Pengenal unik untuk setiap aplikasi onboarding pelanggan, yang berfungsi sebagai ID kasus utama.
Deskripsi Aplikasi pelanggan adalah pengenal utama yang menghubungkan semua aktivitas dan data terkait dalam perjalanan onboarding seorang pelanggan. Proses dimulai saat aplikasi dikirim dan berlanjut hingga kasus selesai atau ditolak. Dalam process mining, atribut ini penting untuk mengelompokkan semua peristiwa ke dalam satu kasus. Dengan begitu, Anda dapat menganalisis proses onboarding dari awal hingga akhir. Atribut ini memungkinkan rekonstruksi seluruh alur proses setiap pemohon, yang menjadi dasar untuk menghitung waktu siklus, menganalisis variasi proses, dan melacak status aplikasi dari waktu ke waktu. Mengapa ini penting Ini adalah ID kasus utama. Tanpanya, Anda tidak dapat melacak perjalanan aplikasi pelanggan dari awal hingga akhir, sehingga analisis proses tidak dapat dilakukan. Sumber data Ini adalah pengenal kasus utama dalam modul manajemen kasus LexisNexis Risk Solutions. Contoh APP-2023-001234APP-2023-005678APP-2024-009101
	Nama aktivitas ActivityName	Nama tugas atau peristiwa tertentu yang terjadi pada suatu waktu selama proses onboarding.
Deskripsi Nama aktivitas menjelaskan langkah dalam alur kerja KYC onboarding, seperti 'Aplikasi dikirim', 'Peninjauan dokumen dilakukan', atau 'Aplikasi disetujui'. Setiap aktivitas mewakili tindakan atau tonggak tertentu dalam proses. Atribut ini penting untuk menyusun peta proses yang menggambarkan alur aktivitas secara visual. Anda dapat menggunakannya untuk menganalisis variasi proses, hambatan di antara langkah tertentu, dan frekuensi pengulangan pekerjaan. Analisis aktivitas membantu Anda memahami apa yang terjadi dalam proses. Mengapa ini penting Atribut ini menjadi dasar peta proses, sehingga Anda dapat melihat dan menganalisis urutan peristiwa dalam perjalanan onboarding pelanggan. Sumber data Biasanya ditemukan dalam log peristiwa atau tabel jejak audit di LexisNexis Risk Solutions yang mencatat langkah-langkah proses. Contoh Aplikasi dikirimPemeriksaan awal dilakukanDokumen dimintaPeninjauan kepatuhan selesai
	Stempel waktu peristiwa EventTimestamp	Tanggal dan waktu tepat saat suatu aktivitas dimulai.
Deskripsi Stempel waktu ini menandai awal suatu aktivitas dan menunjukkan urutan kronologis semua peristiwa dalam sebuah kasus. Ini menjadi dasar untuk semua analisis waktu dalam process mining. Dengan stempel waktu peristiwa, Anda dapat menghitung durasi aktivitas, waktu tunggu di antara aktivitas, dan total waktu siklus onboarding dari awal hingga akhir. Data ini penting untuk menemukan hambatan, memantau kepatuhan SLA, dan memahami efisiensi proses. Mengapa ini penting Stempel waktu ini penting untuk mengurutkan peristiwa secara kronologis dan menghitung semua metrik berbasis waktu, seperti waktu siklus dan hambatan. Sumber data Tersedia di log peristiwa atau tabel jejak audit, bersama Nama Aktivitas. Contoh 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
	Departemen Department	Departemen atau tim bisnis tempat pengguna yang ditugaskan bekerja.
Deskripsi Atribut Departemen menunjukkan kelompok fungsi yang bertanggung jawab atas suatu aktivitas, seperti 'Kepatuhan', 'Operasional orientasi pelanggan', atau 'Pencegahan penipuan'. Atribut ini digunakan untuk menganalisis proses dari sudut pandang departemen dan melihat perpindahan pekerjaan antar tim. Atribut ini menjadi dimensi utama dalam dasbor 'Alokasi sumber daya dan beban kerja' serta membantu menemukan ketidakefisienan lintas fungsi atau keterlambatan komunikasi antar departemen. Mengapa ini penting Memungkinkan analisis perpindahan pekerjaan dan kinerja berdasarkan fungsi, sehingga hambatan lintas departemen dapat ditemukan. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Data mungkin perlu digabungkan dari tabel data induk pengguna atau SDM. Contoh ComplianceTim orientasi pelangganAnalis KYCDukungan pelanggan
	Pengguna yang ditugaskan AssignedUser	ID unik pengguna atau agen yang bertanggung jawab menjalankan aktivitas.
Deskripsi Atribut ini menunjukkan orang yang menjalankan tugas tertentu, misalnya petugas kepatuhan yang meninjau dokumen. Informasi ini membantu menganalisis pembagian beban kerja dan kinerja tiap orang. Dalam analisis, Pengguna yang ditugaskan menjadi kunci bagi dasbor 'Alokasi sumber daya dan beban kerja'. Anda dapat memfilter peta proses berdasarkan pengguna, membandingkan kinerja anggota tim, serta menemukan peluang pelatihan atau penyeimbangan beban kerja. Atribut ini juga dapat membantu menemukan hambatan yang disebabkan kelompok pengguna tertentu. Mengapa ini penting Atribut ini penting untuk menganalisis kinerja sumber daya, pembagian beban kerja, serta peluang otomatisasi atau optimalisasi sumber daya. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Data ini biasanya terdapat di jejak audit atau tabel manajemen tugas. Contoh j.doem.smithk.chen
	Status permohonan ApplicationStatus	Status terkini atau status akhir permohonan pelanggan.
Deskripsi Atribut ini menunjukkan status keseluruhan kasus pada waktu tertentu atau hasil akhirnya. Status yang umum antara lain 'Sedang diproses', 'Disetujui', 'Ditolak', atau 'Menunggu informasi'. Status permohonan penting untuk melacak hasil proses orientasi pelanggan. Atribut ini digunakan dalam dasbor 'Alasan dan tahap penolakan permohonan' serta 'Volume harian dan status permohonan' untuk memantau tingkat keberhasilan dan alur operasional. Dengan menganalisis perubahan status dari waktu ke waktu, Anda dapat memahami siklus hidup kasus. Mengapa ini penting Melacak hasil setiap permohonan. Informasi ini penting untuk menghitung KPI utama, seperti tingkat penolakan permohonan, dan memantau volume proses. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Biasanya, data ini terdapat di kolom utama pada objek kasus atau permohonan. Contoh Sedang diprosesDisetujuiDitolakMenunggu informasi pelanggan
	Tanggal target SLA SlaTargetDate	Tanggal target penyelesaian proses orientasi pelanggan.
Deskripsi Tanggal target SLA menetapkan batas waktu penyelesaian permohonan sesuai perjanjian tingkat layanan. Tanggal ini sering ditentukan berdasarkan jenis permohonan, segmen pelanggan, atau yurisdiksi. Atribut ini penting untuk dasbor 'Pemantauan pencapaian target SLA' dan KPI 'Tingkat pencapaian SLA'. Dengan membandingkan tanggal penyelesaian aktual dengan tanggal target SLA, organisasi dapat mengukur kinerja terhadap komitmen, menemukan kasus yang berisiko melanggar SLA, dan menyelidiki penyebab keterlambatan. Mengapa ini penting Memungkinkan pengukuran kinerja terhadap perjanjian tingkat layanan dan menyoroti ketidakefisienan proses yang menyebabkan pelanggaran SLA. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Data ini mungkin disimpan pada kasus atau dihitung berdasarkan aturan bisnis. Contoh 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
	Tingkat risiko RiskLevel	Tingkat risiko permohonan pelanggan yang dihitung, seperti Rendah, Sedang, atau Tinggi.
Deskripsi LexisNexis Risk Solutions berfokus pada penilaian risiko. Atribut ini menunjukkan hasil penilaian tersebut dengan mengelompokkan setiap permohonan berdasarkan profil risikonya. Tingkat risiko biasanya menentukan intensitas dan durasi uji tuntas yang diperlukan. Atribut ini menjadi dimensi utama dalam dasbor 'Tingkat risiko dan durasi orientasi pelanggan'. Analisis proses berdasarkan tingkat risiko dapat menunjukkan apakah permohonan berisiko tinggi memang membutuhkan waktu jauh lebih lama, atau apakah permohonan berisiko rendah justru tertunda tanpa alasan. Analisis ini membantu memvalidasi dan menyempurnakan strategi orientasi pelanggan berbasis risiko. Mengapa ini penting Penting untuk analisis berbasis risiko. Atribut ini membantu memahami dampak profil risiko pelanggan terhadap kompleksitas, durasi, dan jalur proses. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Data ini merupakan keluaran utama modul penilaian risiko. Contoh RendahSedangTinggiDikenai sanksi
	Waktu selesai EndTime	Tanggal dan waktu tepat saat suatu aktivitas selesai.
Deskripsi Stempel waktu ini menandai selesainya suatu aktivitas. Selisih antara Waktu selesai dan Waktu mulai suatu peristiwa menunjukkan waktu pemrosesannya. Waktu selesai penting untuk menghitung durasi setiap langkah secara akurat. Data ini menjadi masukan utama bagi dasbor 'Waktu pemrosesan dan tunggu aktivitas'. Informasi ini membantu membedakan waktu saat sumber daya aktif mengerjakan tugas dengan waktu saat kasus menunggu langkah berikutnya dimulai. Mengapa ini penting Memungkinkan penghitungan waktu pemrosesan aktivitas secara tepat. Informasi ini penting untuk menemukan langkah yang tidak efisien dan menganalisis beban kerja sumber daya. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Data ini sering tersedia di log peristiwa yang mencatat waktu mulai dan selesai. Contoh 2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
	Alasan penolakan RejectionReason	Kode atau keterangan yang menjelaskan alasan permohonan ditolak.
Deskripsi Jika status akhir permohonan adalah 'Ditolak', atribut ini mencatat alasan spesifiknya. Contohnya, 'Verifikasi identitas gagal', 'Cocok dengan daftar sanksi', atau 'Dokumen tidak lengkap'. Data ini menjadi masukan utama bagi dasbor 'Alasan dan tahap penolakan permohonan'. Analisis alasan penolakan membantu menemukan titik kegagalan yang sering terjadi dalam proses. Temuan ini dapat menjadi dasar untuk memperbaiki panduan permohonan, komunikasi dengan pelanggan, atau kriteria peninjauan internal. Memahami alasan permohonan ditolak penting untuk meningkatkan tingkat persetujuan secara keseluruhan. Mengapa ini penting Menunjukkan secara langsung alasan proses orientasi pelanggan gagal, sehingga perbaikan dapat diarahkan untuk meningkatkan tingkat persetujuan permohonan. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Data ini sering tersedia di kolom yang terisi saat Status permohonan berubah menjadi 'Ditolak'. Contoh Cocok dengan daftar sanksiDokumen tidak lengkapVerifikasi identitas gagalProfil berisiko tinggi
	Dilakukan otomatis IsAutomated	Penanda yang menunjukkan apakah aktivitas dijalankan otomatis oleh sistem atau secara manual oleh pengguna.
Deskripsi Atribut boolean ini membedakan tugas yang dijalankan otomatis oleh sistem, seperti pemeriksaan penyaringan awal, dari tugas yang memerlukan campur tangan manusia, seperti peninjauan dokumen secara manual. Atribut 'Dilakukan otomatis' digunakan untuk menghitung KPI 'Proporsi aktivitas manual' dan menganalisis efektivitas inisiatif otomatisasi. Pada peta proses, atribut ini dapat menunjukkan peralihan antara langkah otomatis dan manual. Informasi ini membantu menemukan peluang otomatisasi lebih lanjut untuk mengurangi biaya dan waktu pemrosesan. Mengapa ini penting Membedakan tugas manual dan otomatis. Informasi ini penting untuk menemukan peluang otomatisasi dan mengukur dampaknya. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Penanda ini mungkin tersedia di log peristiwa atau dapat disimpulkan dari 'AssignedUser', misalnya jika nilainya adalah pengguna 'system'. Contoh truefalse
	Jenis permohonan ApplicationType	Jenis permohonan pelanggan, seperti 'Perorangan' atau 'Perusahaan'.
Deskripsi Atribut ini mengelompokkan permohonan berdasarkan jenis entitas yang menjalani proses orientasi pelanggan. Jenis permohonan yang berbeda sering mengikuti jalur proses yang berbeda, dengan profil risiko dan target SLA masing-masing. Analisis proses berdasarkan jenis permohonan memungkinkan Anda membandingkan efisiensi dan kompleksitas orientasi berbagai jenis pelanggan. Atribut ini umum digunakan sebagai filter di berbagai dasbor untuk melihat kinerja secara lebih terperinci. Mengapa ini penting Memungkinkan segmentasi proses secara terperinci. Anda dapat melihat bagaimana berbagai jenis permohonan ditangani dan menemukan hambatan khusus pada tiap jenis. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Data ini biasanya terdapat di kolom utama pada objek permohonan atau kasus. Contoh PeroranganPerusahaanIndividu dengan kekayaan bersih tinggiPerwalian
	Kanal Channel	Kanal pengajuan permohonan, seperti 'Web', 'Seluler', atau 'Kantor cabang'.
Deskripsi Atribut Kanal menunjukkan sumber pengajuan permohonan. Kanal dapat memengaruhi kualitas data, perilaku pelanggan, dan jenis kendala yang muncul selama proses orientasi pelanggan. Atribut ini digunakan untuk membandingkan kinerja proses di berbagai kanal. Misalnya, dasbor 'Tingkat konversi corong orientasi pelanggan' dapat difilter berdasarkan kanal untuk melihat apakah lebih banyak pemohon melalui seluler yang berhenti di tengah proses dibandingkan pemohon melalui web. Hasilnya dapat menjadi dasar perbaikan proses khusus untuk tiap kanal. Mengapa ini penting Membantu menganalisis kinerja proses berdasarkan kanal pengajuan dan menemukan variasi yang dapat menjadi dasar strategi kanal serta perbaikan pengalaman pengguna. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Informasi ini biasanya dicatat saat proses permohonan dimulai. Contoh Portal webAplikasi selulerKantor cabangAPI
	Merupakan pengerjaan ulang IsRework	Penanda yang menunjukkan aktivitas yang termasuk dalam rangkaian pengerjaan ulang.
Deskripsi Penanda boolean ini bernilai true saat suatu aktivitas diulang dalam kasus yang sama. Contohnya, aktivitas 'Peninjauan dokumen dilakukan' terjadi untuk kedua kalinya setelah 'Informasi tambahan diminta'. Ini menandakan proses kembali ke langkah sebelumnya. Atribut 'Merupakan pengerjaan ulang' penting untuk dasbor 'Analisis pengerjaan ulang dan pengulangan' serta KPI 'Persentase rangkaian pengerjaan ulang'. Atribut ini membantu mengukur upaya yang terbuang dan menemukan penyebab utama pengerjaan ulang, seperti instruksi yang kurang jelas atau kualitas data yang buruk, sehingga perbaikan proses dapat diarahkan dengan tepat. Mengapa ini penting Mengukur langsung ketidakefisienan dan upaya yang terbuang dalam proses. Atribut ini menyoroti aktivitas yang sering diulang dan meningkatkan biaya serta waktu siklus. Sumber data Atribut ini dihitung, biasanya di dalam alat process mining dengan mendeteksi urutan aktivitas yang berulang dalam suatu kasus. Contoh truefalse
	Negara pelanggan CustomerCountry	Negara tempat pelanggan tinggal atau badan usaha didirikan.
Deskripsi Atribut ini menunjukkan negara pelanggan. Informasi ini penting dalam KYC karena peraturan internasional dan tingkat risiko berbeda di setiap yurisdiksi. Analisis proses berdasarkan negara pelanggan dapat menunjukkan perbedaan besar dalam waktu siklus dan kompleksitas proses. Misalnya, permohonan dari yurisdiksi berisiko tinggi mungkin memerlukan pemeriksaan kepatuhan tambahan sehingga prosesnya lebih lama. Analisis ini membantu merencanakan sumber daya dan menetapkan SLA yang realistis untuk tiap wilayah. Mengapa ini penting Memungkinkan analisis berdasarkan yurisdiksi. Informasi ini penting untuk memahami dampak peraturan dan faktor risiko regional terhadap kinerja proses. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Data ini merupakan kolom standar dalam data induk pelanggan. Contoh USAGBRDEUSGP
	Pembaruan data terakhir LastDataUpdate	Waktu terakhir data diperbarui atau diekstrak dari sistem sumber.
Deskripsi Atribut ini mencatat waktu pembaruan terakhir kumpulan data. Biasanya, waktu tersebut diterapkan ke seluruh kumpulan data saat proses ekstraksi dan pemuatan data. Informasi ini penting agar pengguna dasbor mengetahui seberapa baru data yang mereka analisis. Dengan begitu, keputusan dapat dibuat berdasarkan data yang cukup mutakhir dan ekspektasi terhadap ketepatan waktu wawasan dapat dikelola. Mengapa ini penting Memberi konteks penting tentang kemutakhiran data, sehingga analisis tetap relevan dan keputusan tidak didasarkan pada informasi yang sudah usang. Sumber data Biasanya, informasi ini dibuat dan dicatat pada kumpulan data selama proses ETL (Extract, Transform, Load). Contoh 2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
	Peninjau kepatuhan ComplianceReviewer	Pengguna atau agen yang secara khusus ditugaskan untuk melakukan peninjauan kepatuhan.
Deskripsi 'AssignedUser' mencatat pengguna untuk aktivitas apa pun, sedangkan atribut ini secara khusus menunjukkan spesialis kepatuhan yang terlibat dalam tahap peninjauan penting. Dengan begitu, fungsi kepatuhan dapat dianalisis secara lebih terarah. Atribut ini penting untuk dasbor 'Durasi dan antrean peninjauan kepatuhan'. Atribut ini membantu menganalisis beban kerja dan kinerja tim kepatuhan, serta menemukan apakah peninjau tertentu menjadi hambatan atau apakah jumlah sumber daya tim secara keseluruhan belum memadai. Mengapa ini penting Memberi gambaran terarah tentang fungsi kepatuhan, sehingga beban kerja dan kinerja peninjau dapat dianalisis secara terperinci pada tahap proses penting yang sering mengalami keterlambatan. Sumber data Lihat dokumentasi LexisNexis Risk Solutions atau tanyakan kepada administrator sistem. Data ini dapat diperoleh dengan memfilter 'AssignedUser' untuk aktivitas terkait kepatuhan. Contoh c.joness.patelsystem_escalation
	Sistem sumber SourceSystem	Sistem atau aplikasi asal data peristiwa.
Deskripsi Atribut ini menunjukkan sistem sumber yang menghasilkan data peristiwa, seperti LexisNexis Risk Solutions atau alat pihak ketiga yang terintegrasi. Dalam lingkungan yang kompleks, data untuk satu proses bisa berasal dari beberapa sistem. Mengetahui sistem sumber berguna untuk memvalidasi data, mengatasi masalah, dan menganalisis variasi proses yang mungkin hanya terjadi di sistem tertentu. Informasi ini membantu menjaga integritas data serta memberi konteks tentang bagaimana dan di mana aktivitas dicatat. Mengapa ini penting Menunjukkan asal data. Informasi ini penting untuk tata kelola dan validasi data, serta untuk memahami pelaksanaan proses di berbagai sistem TI. Sumber data Informasi ini dapat disimpan sebagai nilai tetap atau di kolom tertentu dalam ekspor data maupun respons API. Contoh LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
	Status SLA SlaStatus	Menunjukkan apakah permohonan yang selesai memenuhi target SLA.
Deskripsi Atribut ini mengelompokkan setiap kasus yang selesai berdasarkan pencapaiannya terhadap 'SlaTargetDate'. Nilai yang umum adalah 'Tercapai' atau 'Terlewati'. Kolom hasil perhitungan ini menjadi dasar dasbor 'Pemantauan pencapaian target SLA' dan KPI 'Tingkat pencapaian SLA'. Atribut ini memberikan gambaran umum yang jelas tentang kinerja terhadap komitmen layanan. Anda juga dapat menelusuri satu tingkat lebih dalam untuk memahami karakteristik umum kasus yang melanggar SLA. Mengapa ini penting Memberikan hasil yang jelas, tercapai atau tidak, untuk kinerja SLA. Dengan begitu, kepatuhan terhadap target tingkat layanan mudah dilacak, dilaporkan, dan dianalisis. Sumber data Atribut ini dihitung dengan membandingkan stempel waktu aktivitas terakhir dengan 'SlaTargetDate' untuk setiap kasus. Contoh TercapaiTerlewatiBerisiko
	Waktu siklus CycleTime	Total durasi proses permohonan pelanggan dari pengajuan hingga keputusan akhir.
Deskripsi Waktu siklus mengukur total waktu sejak peristiwa pertama, misalnya 'Permohonan diajukan', hingga peristiwa terakhir, misalnya 'Orientasi pelanggan selesai' atau 'Permohonan ditolak', untuk satu kasus. Waktu siklus merupakan KPI utama untuk mengukur kesehatan proses secara keseluruhan. Metrik ini ditampilkan di dasbor 'Waktu siklus orientasi pelanggan dari awal hingga akhir'. Dengan memantau rata-rata waktu siklus, organisasi dapat mengukur dampak perbaikan proses dan melihat pengaruh faktor seperti tingkat risiko atau jenis permohonan terhadap pengalaman pelanggan. Mengapa ini penting KPI utama ini mengukur total waktu hingga pelanggan memperoleh manfaat. Nilainya berdampak langsung pada kepuasan pelanggan dan efisiensi operasional. Sumber data Metrik ini dihitung dengan mengurangi stempel waktu peristiwa pertama dari stempel waktu peristiwa terakhir untuk setiap kasus. Contoh 5 hari 4 jam22 hari 8 jam1 hari 2 jam

Wajib Disarankan Opsional

Aktivitas onboarding nasabah KYC

Catat langkah dan pencapaian utama proses ini dalam log peristiwa agar penemuan proses dan analisis kinerja lebih akurat.

8 Disarankan 6 Opsional

	Aktivitas	Deskripsi
	Aplikasi dikirim	Menandai awal proses KYC onboarding, saat sistem pertama kali menerima aplikasi pelanggan. Peristiwa ini biasanya tercatat saat formulir aplikasi dikirim melalui portal pelanggan atau sistem entri data internal yang terhubung dengan LexisNexis.
Mengapa ini penting Ini adalah peristiwa awal utama dalam proses. Analisis waktu dari aktivitas ini hingga proses selesai penting untuk mengukur waktu siklus dari awal hingga akhir dan kepatuhan SLA. Sumber data Diambil dari log sistem atau tabel aplikasi yang mencatat waktu pembuatan awal data aplikasi pelanggan baru. Pengumpulan data Peristiwa dicatat saat kasus aplikasi baru atau entri baru dibuat di tabel aplikasi utama. Jenis peristiwa explicit
	Aplikasi disetujui	Keputusan akhir untuk menyetujui aplikasi pelanggan dibuat dan dicatat di sistem. Ini adalah hasil bisnis yang penting dan hampir selalu tercatat sebagai perubahan status secara langsung.
Mengapa ini penting Tonggak ini menandai keberhasilan proses pengambilan keputusan. Analisis alur yang berujung pada persetujuan membantu menemukan praktik terbaik. Sumber data Cari pembaruan status akhir pada catatan kasus aplikasi. Statusnya biasanya ditetapkan menjadi 'Disetujui' atau status akhir serupa. Pengumpulan data Dicatat sebagai perubahan status akhir yang pasti di tabel aplikasi atau kasus utama. Jenis peristiwa explicit
	Aplikasi ditolak	Keputusan akhir untuk menolak aplikasi pelanggan dicatat. Ini adalah peristiwa akhir yang ditandai dengan perubahan status pasti di sistem.
Mengapa ini penting Ini adalah peristiwa akhir yang menandai kegagalan proses. Analisis tahap terjadinya penolakan beserta alasannya penting untuk perbaikan proses. Sumber data Diambil dari kolom status akhir pada data aplikasi yang ditetapkan menjadi 'Ditolak', 'Tidak disetujui', atau status akhir serupa. Pengumpulan data Dicatat sebagai perubahan status akhir yang pasti di tabel aplikasi atau kasus utama. Jenis peristiwa explicit
	Customer onboarding selesai	Peristiwa ini menandai berakhirnya seluruh proses onboarding dengan sukses dan mengonfirmasi bahwa pelanggan telah aktif sepenuhnya. Peristiwa ini dapat berupa status akhir yang tercatat secara langsung atau disimpulkan dari peristiwa 'Akun diaktifkan'.
Mengapa ini penting Ini adalah peristiwa akhir yang menandai keberhasilan proses. Peristiwa ini penting untuk menghitung waktu siklus dari awal hingga akhir bagi semua pelanggan yang berhasil menjalani onboarding. Sumber data Disimpulkan dari stempel waktu 'Akun diaktifkan' atau diambil dari status akhir dalam berkas kasus, seperti 'Onboarding selesai'. Pengumpulan data Disimpulkan dari peristiwa positif penting terakhir, seperti aktivasi akun, atau dari pembaruan status akhir. Jenis peristiwa inferred
	Dokumen diterima	Mengonfirmasi bahwa pelanggan telah mengunggah atau menyerahkan dokumen yang diperlukan ke sistem. Biasanya, peristiwa ini dicatat oleh portal pengiriman dokumen atau dimasukkan secara manual oleh petugas.
Mengapa ini penting Aktivitas ini mengakhiri masa tunggu dan memulai aktivitas peninjauan berikutnya. Ini adalah tonggak penting dalam tahap pengumpulan data. Sumber data Diambil dari log sistem manajemen dokumen atau entri bertanggal dalam berkas kasus aplikasi saat dokumen baru dilampirkan. Pengumpulan data Peristiwa dicatat saat dokumen berhasil diunggah atau ditandai telah diterima secara manual di sistem. Jenis peristiwa explicit
	Penilaian risiko dilakukan	Sistem menghitung skor risiko pelanggan berdasarkan informasi yang dikumpulkan dan pemeriksaan yang dilakukan. Ini adalah fitur utama LexisNexis dan biasanya tercatat sebagai peristiwa otomatis dalam riwayat kasus.
Mengapa ini penting Hasil penilaian ini sering menentukan alur proses berikutnya, misalnya apakah pemeriksaan uji tuntas yang lebih mendalam diperlukan. Ini adalah titik pengambilan keputusan penting dalam alur kerja. Sumber data Cari peristiwa dalam log audit aplikasi atau riwayat alur kerja yang mencatat selesainya pemberian skor risiko atau modul penilaian. Pengumpulan data Peristiwa tertentu dicatat saat mesin risiko menyelesaikan analisis dan menetapkan profil atau skor risiko. Jenis peristiwa explicit
	Peninjauan kepatuhan dimulai	Kasus ditugaskan kepada petugas atau tim kepatuhan untuk ditinjau secara manual, biasanya untuk aplikasi berisiko tinggi. Aktivitas ini sering disimpulkan dari perubahan status menjadi 'Menunggu peninjauan kepatuhan' atau dari log penugasan tugas.
Mengapa ini penting Ini menandai awal tahap peninjauan manual yang sering memakan waktu. Dengan mengukur waktu hingga tahap ini selesai, Anda dapat mengetahui besarnya hambatan terkait kepatuhan. Sumber data Diambil dari log penugasan tugas, perubahan kepemilikan kasus ke tim kepatuhan, atau pembaruan status dalam riwayat kasus. Pengumpulan data Disimpulkan dari perubahan status seperti 'Sedang ditinjau untuk kepatuhan' atau saat kasus ditugaskan ke antrean pengguna terkait kepatuhan. Jenis peristiwa inferred
	Peninjauan kepatuhan selesai	Petugas kepatuhan menyelesaikan peninjauan dan memberikan rekomendasi, lalu kasus berlanjut ke tahap berikutnya. Aktivitas ini dapat dicatat secara langsung saat tugas ditandai 'selesai' atau disimpulkan dari perubahan status dari 'Menunggu kepatuhan' ke status lain.
Mengapa ini penting Ini adalah tonggak penting yang mengakhiri bagian proses yang krusial dan sering dilakukan secara manual. Peristiwa ini menjadi titik akhir untuk mengukur durasi peninjauan kepatuhan. Sumber data Diambil dari stempel waktu penyelesaian tugas kepatuhan atau perubahan status dari 'Sedang ditinjau untuk kepatuhan'. Pengumpulan data Disimpulkan dari perubahan status yang menunjukkan peninjauan telah selesai, misalnya menjadi 'Disetujui', 'Ditolak', atau 'Keputusan akhir'. Jenis peristiwa inferred
	Akun diaktifkan	Setelah disetujui, akun pelanggan dibuat secara resmi dan diaktifkan di platform perbankan atau layanan utama. Aktivitas ini sering tercatat dalam jejak audit atau disimpulkan dari tanggal pembuatan akun.
Mengapa ini penting Ini adalah langkah terakhir yang memberikan nilai kepada pelanggan. Keterlambatan antara 'Aplikasi disetujui' dan langkah ini dapat menunjukkan masalah integrasi sistem. Sumber data Diambil dari log pembuatan akun, panggilan API ke sistem lain, atau stempel waktu pembuatan data akun. Pengumpulan data Dicatat sebagai peristiwa terpisah setelah persetujuan atau diketahui dari adanya stempel waktu aktivasi pada data pelanggan. Jenis peristiwa explicit
	Dokumen diminta	Sistem atau pengguna meminta dokumen tertentu dari pelanggan, seperti SIM atau tagihan utilitas. Peristiwa ini dapat diambil dari log komunikasi yang dibuat sistem atau perubahan status yang menunjukkan kasus sedang menunggu dokumen.
Mengapa ini penting Aktivitas ini sering menambah waktu tunggu yang cukup lama dalam proses. Analisis frekuensi dan durasinya membantu menemukan keterlambatan akibat waktu respons pelanggan. Sumber data Cari peristiwa dalam log komunikasi yang dikirim kepada pelanggan atau perubahan status aplikasi, misalnya 'Dokumen pelanggan ditunggu'. Pengumpulan data Disimpulkan dari perubahan status menjadi 'Menunggu dokumen' atau dari stempel waktu log komunikasi keluar. Jenis peristiwa inferred
	Informasi tambahan diminta	Petugas kepatuhan atau peninjau meminta informasi tambahan atau klarifikasi dari pelanggan. Peristiwa ini sering menyebabkan pekerjaan ulang dan biasanya tercatat sebagai perubahan status atau entri log komunikasi.
Mengapa ini penting Aktivitas ini memicu pengulangan pekerjaan yang memperpanjang waktu siklus onboarding. Dengan melacak frekuensinya, Anda dapat menemukan persyaratan yang kurang jelas atau kekurangan umum dalam aplikasi. Sumber data Cari perubahan status menjadi 'Menunggu informasi dari pelanggan' atau peristiwa log komunikasi keluar. Tindakan ini biasanya dimulai oleh pengguna. Pengumpulan data Dicatat saat petugas menggunakan fitur 'Minta informasi', yang mengubah status kasus dan mungkin mencatat peristiwa komunikasi. Jenis peristiwa explicit
	Pemeriksaan awal dilakukan	Setelah aplikasi dikirim, sistem langsung melakukan pemeriksaan otomatis untuk memastikan data dasar lengkap dan menjalankan pemeriksaan awal. Aktivitas ini sering tercatat sebagai langkah otomatis dalam riwayat alur kerja proses.
Mengapa ini penting Menunjukkan aplikasi yang gagal pada tahap paling awal, sehingga membantu menemukan masalah kualitas data. Aktivitas ini juga menandai langkah otomatis pertama yang memberikan nilai dalam proses. Sumber data Cari log eksekusi aturan otomatis atau perubahan status dalam riwayat alur kerja aplikasi yang menunjukkan pemeriksaan awal telah selesai. Pengumpulan data Dicatat sebagai tugas otomatis yang selesai atau pembaruan status tertentu dalam riwayat kasus. Jenis peristiwa explicit
	Peninjauan dokumen dilakukan	Pengguna atau alat otomatis meninjau keaslian, keabsahan, dan kelengkapan dokumen yang dikirim. Aktivitas ini dapat disimpulkan dari perubahan status dari 'Dokumen diterima' menjadi 'Peninjauan selesai' atau dari entri log yang tercatat secara langsung.
Mengapa ini penting Aktivitas ini sering menjadi sumber hambatan dan pekerjaan ulang. Analisis waktu pemrosesan dan pengulangannya penting untuk meningkatkan efisiensi dan menemukan peluang otomatisasi. Sumber data Disimpulkan dengan melacak waktu antara status 'Dokumen diterima' dan status berikutnya, seperti 'Verifikasi lolos' atau 'Informasi tambahan diperlukan'. Pengumpulan data Dihitung dari selisih waktu antara peristiwa penerimaan dokumen dan peristiwa yang menandai selesainya peninjauan. Jenis peristiwa inferred
	Verifikasi identitas dimulai	Menandai saat sistem memulai proses utama verifikasi identitas menggunakan layanan LexisNexis, misalnya dengan mencocokkan data ke database. Biasanya, log peristiwa mencatat aktivitas ini saat layanan verifikasi dipanggil.
Mengapa ini penting Aktivitas ini menandai awal subproses penting yang sering memakan waktu. Dengan melacak durasinya, Anda dapat menemukan hambatan dalam pemeriksaan identitas. Sumber data Diambil dari log panggilan API ke modul verifikasi identitas atau entri jejak audit yang menunjukkan dimulainya tugas verifikasi. Pengumpulan data Peristiwa dicatat saat modul atau API verifikasi identitas sistem dijalankan untuk aplikasi. Jenis peristiwa explicit

Disarankan Opsional

Panduan ekstraksi

Cara mengambil data dari LexisNexis Risk Solutions

Langkah

Siapkan lingkungan Python: Pasang Python 3.8 atau versi lebih baru di sistem Anda. Buka terminal atau command prompt, lalu pasang pustaka yang diperlukan dengan menjalankan pip install requests pandas.
Dapatkan kredensial API: Hubungi administrator LexisNexis Risk Solutions atau perwakilan akun Anda untuk mendapatkan kredensial API. Anda memerlukan API Key, API Secret, dan Base URL untuk endpoint API.
Atur skrip Python: Buka skrip Python yang disediakan di editor teks. Cari bagian konfigurasi di bagian atas, lalu ganti nilai placeholder API_KEY, API_SECRET, dan BASE_URL dengan kredensial Anda.
Tentukan parameter ekstraksi: Di bagian konfigurasi yang sama, tentukan rentang waktu ekstraksi data dengan mengatur variabel START_DATE dan END_DATE. Gunakan format tanggal 'YYYY-MM-DD'. Sebaiknya mulai dengan rentang yang lebih pendek, misalnya satu bulan, untuk menguji ekstraksi.
Periksa pemetaan aktivitas: Periksa kamus ACTIVITY_MAP dalam skrip. Kamus ini memetakan jenis peristiwa dari respons API LexisNexis ke nama aktivitas standar yang diperlukan dalam log peristiwa. Anda mungkin perlu menyesuaikan kunci, yaitu nilai di sebelah kiri, agar sesuai dengan nama peristiwa dalam konfigurasi LexisNexis Anda. Cari tahu nama tersebut dengan memeriksa contoh respons API.
Jalankan skrip: Jalankan skrip dari terminal dengan perintah python your_script_name.py. Skrip akan melakukan autentikasi, mengambil daftar permohonan nasabah dalam rentang tanggal yang ditentukan, lalu mengambil riwayat peristiwa untuk setiap permohonan.
Pantau proses skrip: Skrip akan menampilkan pesan kemajuan di konsol, seperti jumlah permohonan yang sedang diproses. Perhatikan pesan kesalahan yang mungkin menunjukkan masalah pada kredensial, endpoint API, atau batas permintaan.
Ambil file hasil: Setelah skrip berhasil dijalankan, file bernama lexisnexis_event_log.csv akan dibuat di direktori yang sama. File ini berisi log peristiwa yang diekstrak.
Siapkan file untuk diunggah: Sebelum mengunggah file ke alat process mining, buka CSV dan pastikan kolom yang diharapkan tersedia: CustomerApplication, ActivityName, EventTimestamp, dan kolom lainnya. Periksa apakah datanya benar dan konsisten.
Unggah ke ProcessMind: Unggah file lexisnexis_event_log.csv yang dihasilkan ke aplikasi process mining Anda. Petakan kolom ke kolom ID kasus, aktivitas, dan stempel waktu yang sesuai.

Konfigurasi

Kredensial API: Anda memerlukan API Key dan Secret yang valid untuk autentikasi. Minta kredensial ini dari administrator LexisNexis dan jaga kerahasiaannya.
Endpoint API: Skrip harus menggunakan Base URL yang benar untuk REST API LexisNexis. Endpoint khusus untuk mengambil permohonan dan riwayat peristiwanya ditentukan dalam kode skrip.
Rentang tanggal: Parameter START_DATE dan END_DATE menentukan rentang waktu ekstraksi. Untuk menjaga kinerja dan menghindari batas permintaan API, sebaiknya ekstrak data dalam kelompok berisi 3 hingga 6 bulan.
Pemetaan aktivitas: Kamus ACTIVITY_MAP merupakan konfigurasi penting. Pastikan nama peristiwa sumber dari API, yang digunakan sebagai kunci dalam kamus, sesuai dengan nama yang dihasilkan sistem Anda. Peristiwa yang tidak dipetakan akan diabaikan.
Batas permintaan: Skrip menyertakan jeda singkat di antara panggilan API untuk mematuhi kemungkinan batas permintaan. Untuk kumpulan data yang sangat besar, Anda mungkin perlu menyesuaikan nilai API_CALL_DELAY_SECONDS atau menerapkan mekanisme jeda bertahap yang lebih canggih.
Prasyarat: Metode ini memerlukan sistem dengan Python 3.x serta pustaka requests dan pandas. Pengguna atau akun layanan yang menjalankan skrip harus memiliki izin yang memadai untuk mengakses API LexisNexis.

Contoh kueri python

import requests
import pandas as pd
import time
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Section --- #
class=class="hl-string">"hl-comment"># Replace with your actual LexisNexis API credentials and endpoints
API_KEY = class="hl-string">'[Your_API_Key]'
API_SECRET = class="hl-string">'[Your_API_Secret]'
BASE_URL = class="hl-string">'[https://api.example.lexisnexis.com/v1]' class=class="hl-string">"hl-comment"># e.g., your specific API gateway URL

class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-06-30'

class=class="hl-string">"hl-comment"># Delay between API calls to avoid rate limiting
API_CALL_DELAY_SECONDS = 0.5

class=class="hl-string">"hl-comment"># Mapping from LexisNexis event types to standard activity names
class=class="hl-string">"hl-comment"># CRITICAL: The keys of this dictionary must be adjusted to match the event names
class=class="hl-string">"hl-comment"># returned by your specific LexisNexis API endpoint.
ACTIVITY_MAP = {
    class="hl-string">'application.submitted': class="hl-string">'Application Submitted',
    class="hl-string">'screening.initial.performed': class="hl-string">'Initial Screening Performed',
    class="hl-string">'verification.identity.initiated': class="hl-string">'Identity Verification Initiated',
    class="hl-string">'documents.requested': class="hl-string">'Documents Requested',
    class="hl-string">'documents.received': class="hl-string">'Documents Received',
    class="hl-string">'review.document.performed': class="hl-string">'Document Review Performed',
    class="hl-string">'assessment.risk.performed': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'review.compliance.initiated': class="hl-string">'Compliance Review Initiated',
    class="hl-string">'information.additional.requested': class="hl-string">'Additional Information Requested',
    class="hl-string">'review.compliance.completed': class="hl-string">'Compliance Review Completed',
    class="hl-string">'application.approved': class="hl-string">'Application Approved',
    class="hl-string">'account.activated': class="hl-string">'Account Activated',
    class="hl-string">'onboarding.completed': class="hl-string">'Customer Onboarding Completed',
    class="hl-string">'application.rejected': class="hl-string">'Application Rejected'
}

def get_auth_token():
    class="hl-string">"""Handles authentication and returns an access token."""
    class=class="hl-string">"hl-comment"># This is a placeholder for the actual authentication mechanism.
    class=class="hl-string">"hl-comment"># Adjust according to LexisNexis API documentation (e.g., OAuth2).
    class=class="hl-string">"hl-comment"># For simplicity, we assume the API Key can be used directly in a header.
    class=class="hl-string">"hl-comment"># In a real scenario, you might POST to a token endpoint.
    print(class="hl-string">"Authentication successful (simulated).")
    return fclass="hl-string">'Bearer {API_KEY}' class=class="hl-string">"hl-comment"># Simplified for example purposes

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    auth_token = get_auth_token()
    if not auth_token:
        print(class="hl-string">"Failed to authenticate. Exiting.")
        return

    headers = {
        class="hl-string">'Authorization': auth_token,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }

    print(fclass="hl-string">"Fetching applications from {START_DATE} to {END_DATE}...")
    
    class=class="hl-string">"hl-comment"># 1. Fetch all application IDs within the date range
    try:
        applications_endpoint = fclass="hl-string">'{BASE_URL}/applications'
        params = {class="hl-string">'startDate': START_DATE, class="hl-string">'endDate': END_DATE}
        response = requests.get(applications_endpoint, headers=headers, params=params)
        response.raise_for_status()
        applications = response.json().get(class="hl-string">'applications', [])
        print(fclass="hl-string">"Found {len(applications)} applications to process.")
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching applications: {e}")
        return

    all_events = []

    class=class="hl-string">"hl-comment"># 2. For each application, fetch its detailed event history
    for i, app in enumerate(applications):
        app_id = app.get(class="hl-string">'customerApplicationId')
        if not app_id:
            continue

        print(fclass="hl-string">"Processing application {i+1}/{len(applications)}: {app_id}")
        try:
            events_endpoint = fclass="hl-string">'{BASE_URL}/applications/{app_id}/events'
            event_response = requests.get(events_endpoint, headers=headers)
            event_response.raise_for_status()
            events_data = event_response.json().get(class="hl-string">'events', [])
            
            class=class="hl-string">"hl-comment"># 3. Parse events and map them to the event log format
            for event in events_data:
                event_type = event.get(class="hl-string">'eventType')
                if event_type in ACTIVITY_MAP:
                    activity_name = ACTIVITY_MAP[event_type]
                    
                    class=class="hl-string">"hl-comment"># Extract attributes, using .get() to handle missing data gracefully
                    record = {
                        class="hl-string">'CustomerApplication': app_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTimestamp': event.get(class="hl-string">'eventTimestamp'),
                        class="hl-string">'EndTime': event.get(class="hl-string">'eventCompletionTimestamp', None), class=class="hl-string">"hl-comment"># Optional
                        class="hl-string">'AssignedUser': event.get(class="hl-string">'userId', class="hl-string">'System'),
                        class="hl-string">'Department': event.get(class="hl-string">'userDepartment', None),
                        class="hl-string">'ApplicationStatus': event.get(class="hl-string">'applicationStatusAfterEvent'),
                        class="hl-string">'RiskLevel': event.get(class="hl-string">'riskAssessment', {}).get(class="hl-string">'level', None),
                        class="hl-string">'SlaTargetDate': app.get(class="hl-string">'slaTargetDate', None)
                    }
                    all_events.append(record)

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch events for application {app_id}: {e}")
        
        time.sleep(API_CALL_DELAY_SECONDS)

    if not all_events:
        print(class="hl-string">"No events were extracted. The output file will be empty.")
        return

    class=class="hl-string">"hl-comment"># 4. Create a DataFrame and save to CSV
    df = pd.DataFrame(all_events)
    df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
    df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTimestamp'], inplace=True)
    
    output_filename = class="hl-string">'lexisnexis_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

Siap memulai?

Gunakan templat ini untuk memulai process mining pada proses onboarding nasabah KYC. Mulai ubah data Anda menjadi wawasan yang dapat ditindaklanjuti.

Kembali ke panduan perbaikan

Unduh template

Tingkatkan proses onboarding KYC dan kurangi nasabah yang mengundurkan diri

Permudah proses onboarding dan pangkas waktunya menjadi hanya 24 jam.

Mulai uji coba gratis

Tidak perlu kartu kredit. Mulai tingkatkan proses Anda hari ini.

Templat data onboarding nasabah KYC Anda

Templat data onboarding nasabah KYC Anda

Atribut onboarding nasabah KYC

Aktivitas onboarding nasabah KYC

Panduan ekstraksi

Ekstraksi data LexisNexis melalui API menggunakan skrip Python

Langkah

Konfigurasi

Contoh kueri python

Siap memulai?

Tingkatkan proses onboarding KYC dan kurangi nasabah yang mengundurkan diri