> การปรับปรุงกระบวนการอย่างต่อเนื่อง > กระบวนการรับลูกค้าใหม่ KYC > LexisNexis Risk Solutions > เทมเพลตข้อมูล

เทมเพลตข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

LexisNexis Risk Solutions

แอตทริบิวต์ของกระบวนการรับลูกค้าใหม่ KYC(20) กิจกรรมในกระบวนการรับลูกค้าใหม่ KYC(14) คู่มือการดึงข้อมูล(1)

เทมเพลตข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

เทมเพลตนี้แนะนำวิธีรวบรวมข้อมูลที่จำเป็นสำหรับวิเคราะห์กระบวนการรับลูกค้าใหม่ KYC โดยระบุแอตทริบิวต์สำคัญที่ควรเก็บ กิจกรรมหลักที่ควรติดตาม และวิธีดึงข้อมูลจากระบบต้นทาง ใช้ทรัพยากรนี้สร้างบันทึกเหตุการณ์ที่มีข้อมูลพร้อมสำหรับการวิเคราะห์ เพื่อให้เห็นข้อมูลเชิงลึกตลอดเส้นทางการรับลูกค้าใหม่.

แอตทริบิวต์ที่แนะนำให้รวบรวม
กิจกรรมสำคัญที่ควรติดตาม
แนวทางการดึงข้อมูล

เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

ดาวน์โหลดเทมเพลต

แอตทริบิวต์ของกระบวนการรับลูกค้าใหม่ KYC

ฟิลด์ข้อมูลเหล่านี้เป็นรายการที่แนะนำให้ใส่ในบันทึกเหตุการณ์ เพื่อวิเคราะห์และค้นพบกระบวนการรับลูกค้าใหม่ KYC.

3 จำเป็น 6 แนะนำ 11 ไม่บังคับ

	ชื่อ	คำอธิบาย
	ชื่อกิจกรรม ActivityName	ชื่อของงานหรือเหตุการณ์เฉพาะที่เกิดขึ้น ณ ช่วงเวลาหนึ่งในกระบวนการเริ่มต้นใช้งาน.
คำอธิบาย ชื่อกิจกรรมระบุขั้นตอนหนึ่งในเวิร์กโฟลว์เริ่มต้นใช้งาน KYC เช่น 'ส่งใบสมัครแล้ว' 'ตรวจสอบเอกสารแล้ว' หรือ 'อนุมัติใบสมัครแล้ว' แต่ละกิจกรรมแทนการดำเนินการหรือหมุดหมายที่แตกต่างกันในกระบวนการ. คุณลักษณะนี้สำคัญต่อการสร้างแผนผังกระบวนการ ซึ่งแสดงลำดับกิจกรรมเป็นภาพ ช่วยวิเคราะห์รูปแบบกระบวนการ คอขวดระหว่างขั้นตอน และความถี่ของงานที่ต้องทำซ้ำ การวิเคราะห์กิจกรรมช่วยให้เข้าใจว่าเกิดอะไรขึ้นในกระบวนการ. เหตุผลที่สำคัญ คุณลักษณะนี้เป็นพื้นฐานของแผนผังกระบวนการ ช่วยให้คุณเห็นภาพและวิเคราะห์ลำดับเหตุการณ์ตลอดการเริ่มต้นใช้งานลูกค้า. แหล่งข้อมูล โดยทั่วไปพบข้อมูลนี้ในบันทึกเหตุการณ์หรือตารางประวัติการตรวจสอบภายใน LexisNexis Risk Solutions ซึ่งใช้ติดตามขั้นตอนของกระบวนการ. ตัวอย่าง ส่งใบสมัครแล้วตรวจสอบเบื้องต้นแล้วขอเอกสารแล้วตรวจสอบการปฏิบัติตามข้อกำหนดเสร็จแล้ว
	ใบสมัครลูกค้า CustomerApplication	รหัสเฉพาะของใบสมัครเริ่มต้นใช้งานลูกค้าแต่ละรายการ ซึ่งใช้เป็นรหัสเคสหลัก.
คำอธิบาย ใบสมัครลูกค้าเป็นรหัสกลางที่เชื่อมโยงกิจกรรมและข้อมูลทั้งหมดของการเริ่มต้นใช้งานลูกค้าหนึ่งรายเข้าด้วยกัน เริ่มตั้งแต่ส่งใบสมัครและติดตามเคสไปจนกว่าจะดำเนินการเสร็จหรือถูกปฏิเสธ. ใน process mining คุณต้องใช้คุณลักษณะนี้เพื่อจัดกลุ่มเหตุการณ์ทั้งหมดให้อยู่ในเคสเดียวกัน และวิเคราะห์กระบวนการตั้งแต่ต้นจนจบ คุณจึงสร้างเส้นทางกระบวนการทั้งหมดของผู้สมัครแต่ละรายได้ ซึ่งเป็นพื้นฐานสำคัญสำหรับคำนวณระยะเวลาดำเนินการ วิเคราะห์รูปแบบกระบวนการ และติดตามสถานะใบสมัครตามเวลา. เหตุผลที่สำคัญ นี่คือรหัสเคสหลัก หากไม่มีรหัสนี้ คุณจะติดตามกระบวนการของใบสมัครลูกค้าตั้งแต่ต้นจนจบไม่ได้ ทำให้วิเคราะห์กระบวนการไม่ได้. แหล่งข้อมูล นี่คือรหัสเคสหลักในโมดูลจัดการเคสของ LexisNexis Risk Solutions. ตัวอย่าง APP-2023-001234APP-2023-005678APP-2024-009101
	เวลาที่เกิดเหตุการณ์ EventTimestamp	วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหนึ่งเริ่มต้นขึ้น.
คำอธิบาย เวลานี้ระบุจุดเริ่มต้นของกิจกรรมและใช้เรียงเหตุการณ์ทั้งหมดภายในเคสตามลำดับเวลา เป็นพื้นฐานของการวิเคราะห์ด้านเวลาทั้งหมดใน process mining. เมื่อใช้เวลาที่เกิดเหตุการณ์ คุณจะคำนวณระยะเวลาของกิจกรรม เวลาระหว่างกิจกรรม และเวลารวมตั้งแต่ต้นจนจบของกระบวนการเริ่มต้นใช้งานได้ ข้อมูลนี้จำเป็นต่อการระบุคอขวด ติดตามการทำตาม SLA และทำความเข้าใจประสิทธิภาพของกระบวนการ. เหตุผลที่สำคัญ เวลานี้จำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลาและคำนวณตัวชี้วัดด้านเวลาทั้งหมด เช่น ระยะเวลาดำเนินการและคอขวด. แหล่งข้อมูล อยู่ในตารางบันทึกเหตุการณ์หรือ audit trail ร่วมกับชื่อกิจกรรม. ตัวอย่าง 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
	ผู้ใช้ที่ได้รับมอบหมาย AssignedUser	รหัสเฉพาะของผู้ใช้หรือตัวแทนที่รับผิดชอบดำเนินกิจกรรม.
คำอธิบาย แอตทริบิวต์นี้ระบุบุคคลที่ทำงานนั้นโดยเฉพาะ เช่น เจ้าหน้าที่การปฏิบัติตามข้อกำหนดที่ตรวจสอบเอกสาร ข้อมูลนี้ช่วยวิเคราะห์การกระจายภาระงานและผลงานรายบุคคล ในการวิเคราะห์ ผู้ใช้ที่ได้รับมอบหมายเป็นข้อมูลหลักของแดชบอร์ด 'Resource Allocation and Workload' คุณสามารถกรองแผนผังกระบวนการตามผู้ใช้ เปรียบเทียบผลงานระหว่างสมาชิกในทีม และหาโอกาสในการฝึกอบรมหรือปรับสมดุลภาระงาน นอกจากนี้ยังช่วยระบุคอขวดที่เกิดจากผู้ใช้บางกลุ่มได้ด้วย. เหตุผลที่สำคัญ แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ผลงานและการกระจายภาระงานของทรัพยากร รวมถึงการหาโอกาสใช้ระบบอัตโนมัติหรือปรับการใช้ทรัพยากรให้เหมาะสม. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ โดยปกติจะพบข้อมูลนี้ใน audit trail หรือตารางจัดการงาน. ตัวอย่าง j.doem.smithk.chen
	แผนก Department	แผนกหรือทีมธุรกิจที่ผู้ใช้ซึ่งได้รับมอบหมายสังกัดอยู่.
คำอธิบาย แอตทริบิวต์แผนกระบุหน่วยงานที่รับผิดชอบกิจกรรม เช่น 'การปฏิบัติตามข้อกำหนด', 'ทีมปฏิบัติการรับลูกค้าใหม่' หรือ 'การป้องกันการฉ้อโกง' แอตทริบิวต์นี้ใช้วิเคราะห์กระบวนการในมุมมองของแต่ละแผนก และช่วยดูการส่งต่องานระหว่างทีม เป็นมิติหลักในแดชบอร์ด 'Resource Allocation and Workload' และช่วยระบุความไม่มีประสิทธิภาพข้ามหน่วยงานหรือความล่าช้าในการสื่อสารระหว่างแผนก. เหตุผลที่สำคัญ ช่วยวิเคราะห์การส่งต่องานและผลงานของแต่ละหน่วยงาน เพื่อระบุคอขวดที่เกิดขึ้นระหว่างแผนก. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ อาจต้องนำข้อมูลจากตารางข้อมูลหลักของผู้ใช้หรือฝ่ายทรัพยากรบุคคลมาเชื่อมเพิ่ม. ตัวอย่าง Complianceทีมรับลูกค้าใหม่นักวิเคราะห์ KYCฝ่ายบริการลูกค้า
	ระดับความเสี่ยง RiskLevel	ระดับความเสี่ยงที่คำนวณได้ของใบสมัครลูกค้า เช่น ต่ำ ปานกลาง หรือสูง.
คำอธิบาย LexisNexis Risk Solutions เชี่ยวชาญด้านการประเมินความเสี่ยง แอตทริบิวต์นี้แสดงผลการประเมิน โดยจัดประเภทใบสมัครตามระดับความเสี่ยงที่อาจเกิดขึ้น ระดับความเสี่ยงมักเป็นตัวกำหนดความเข้มข้นและระยะเวลาที่ต้องใช้ในการตรวจสอบสถานะ แอตทริบิวต์นี้เป็นมิติหลักของแดชบอร์ด 'Risk Level vs. Onboarding Duration' การวิเคราะห์กระบวนการตามระดับความเสี่ยงช่วยให้เห็นว่าใบสมัครความเสี่ยงสูงใช้เวลานานขึ้นตามที่คาดหรือไม่ หรือใบสมัครความเสี่ยงต่ำกลับล่าช้าโดยไม่จำเป็นหรือไม่ ข้อมูลนี้ช่วยตรวจสอบและปรับแนวทางรับลูกค้าตามระดับความเสี่ยงให้เหมาะสม. เหตุผลที่สำคัญ จำเป็นต่อการวิเคราะห์ตามระดับความเสี่ยง ช่วยให้เข้าใจว่าโปรไฟล์ความเสี่ยงของลูกค้าส่งผลต่อความซับซ้อน ระยะเวลา และเส้นทางของกระบวนการอย่างไร. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ ข้อมูลนี้เป็นผลลัพธ์หลักจากโมดูลประเมินความเสี่ยง. ตัวอย่าง ต่ำปานกลางสูงอยู่ในรายการคว่ำบาตร
	วันที่เป้าหมายตาม SLA SlaTargetDate	วันที่คาดว่าจะดำเนินกระบวนการรับลูกค้าใหม่ให้เสร็จสิ้น.
คำอธิบาย วันที่เป้าหมายตาม SLA กำหนดกรอบเวลาที่ตกลงกันไว้สำหรับดำเนินใบสมัครให้เสร็จ โดยมักพิจารณาจากประเภทใบสมัคร กลุ่มลูกค้า หรือเขตอำนาจศาล แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'SLA Target Adherence Monitoring' และ KPI 'SLA Adherence Rate' เมื่อนำวันที่เสร็จจริงมาเปรียบเทียบกับวันที่เป้าหมายตาม SLA องค์กรจะวัดผลเทียบกับข้อตกลง ระบุเคสที่เสี่ยงผิด SLA และตรวจสอบสาเหตุที่ทำให้ล่าช้าได้. เหตุผลที่สำคัญ ช่วยวัดผลการดำเนินงานเทียบกับข้อตกลงระดับการให้บริการ และชี้ให้เห็นความไม่มีประสิทธิภาพของกระบวนการที่ทำให้ผิด SLA. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ ข้อมูลนี้อาจจัดเก็บไว้ในเคสหรือคำนวณจากกฎทางธุรกิจ. ตัวอย่าง 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
	เวลาสิ้นสุด EndTime	วันและเวลาที่กิจกรรมเสร็จสิ้นอย่างแม่นยำ.
คำอธิบาย การประทับเวลานี้ระบุเวลาที่กิจกรรมเสร็จสิ้น ส่วนต่างระหว่างเวลาสิ้นสุดและเวลาเริ่มต้นของเหตุการณ์คือเวลาประมวลผลของเหตุการณ์นั้น เวลาสิ้นสุดมีความสำคัญต่อการคำนวณระยะเวลาของแต่ละขั้นตอนอย่างแม่นยำ และเป็นข้อมูลหลักสำหรับแดชบอร์ด 'เวลาประมวลผลและเวลารอของกิจกรรม' ช่วยแยกเวลาที่ทรัพยากรลงมือทำงานจริงออกจากเวลาที่เคสรอให้เริ่มขั้นตอนถัดไป. เหตุผลที่สำคัญ ช่วยคำนวณเวลาที่ใช้ดำเนินกิจกรรมได้อย่างแม่นยำ ซึ่งจำเป็นต่อการระบุขั้นตอนที่ไม่มีประสิทธิภาพและวิเคราะห์ภาระงานของทรัพยากร. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ โดยมักพบข้อมูลนี้ในบันทึกเหตุการณ์ที่บันทึกทั้งเวลาเริ่มต้นและเวลาสิ้นสุด. ตัวอย่าง 2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
	สถานะใบสมัคร ApplicationStatus	สถานะปัจจุบันหรือสถานะสุดท้ายของใบสมัครลูกค้า.
คำอธิบาย แอตทริบิวต์นี้แสดงสถานะโดยรวมของเคส ณ เวลาหนึ่งหรือผลลัพธ์สุดท้าย สถานะที่พบบ่อย ได้แก่ 'กำลังดำเนินการ', 'อนุมัติแล้ว', 'ปฏิเสธแล้ว' หรือ 'รอข้อมูลเพิ่มเติม' สถานะใบสมัครมีความสำคัญต่อการติดตามผลลัพธ์ของกระบวนการรับลูกค้าใหม่ ใช้ในแดชบอร์ด 'Application Rejection Reasons & Stages' และ 'Daily Throughput and Application Status' เพื่อติดตามอัตราความสำเร็จและการไหลของงาน การวิเคราะห์การเปลี่ยนแปลงสถานะตามเวลาช่วยให้เข้าใจวงจรชีวิตของเคส. เหตุผลที่สำคัญ ติดตามผลลัพธ์ของแต่ละใบสมัคร ซึ่งจำเป็นต่อการคำนวณ KPI สำคัญ เช่น อัตราการปฏิเสธใบสมัคร และติดตามปริมาณงานที่ดำเนินการได้. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ โดยทั่วไปจะเป็นฟิลด์สำคัญในออบเจ็กต์เคสหรือใบสมัครหลัก. ตัวอย่าง กำลังดำเนินการอนุมัติแล้วปฏิเสธแล้วรอข้อมูลจากลูกค้า
	ช่องทาง Channel	ช่องทางที่ใช้ส่งใบสมัคร เช่น 'เว็บไซต์', 'มือถือ' หรือ 'สาขา'.
คำอธิบาย แอตทริบิวต์ช่องทางระบุแหล่งที่มาของใบสมัคร ช่องทางอาจส่งผลต่อคุณภาพข้อมูล พฤติกรรมลูกค้า และประเภทของปัญหาที่พบระหว่างกระบวนการรับลูกค้าใหม่ แอตทริบิวต์นี้ใช้เปรียบเทียบผลการดำเนินงานของกระบวนการในแต่ละช่องทาง ตัวอย่างเช่น คุณสามารถกรองแดชบอร์ด 'Onboarding Funnel Conversion Rates' ตามช่องทาง เพื่อดูว่าผู้สมัครผ่านมือถือออกจากกระบวนการมากกว่าผู้สมัครผ่านเว็บไซต์หรือไม่ และนำผลไปปรับปรุงกระบวนการให้เหมาะกับแต่ละช่องทาง. เหตุผลที่สำคัญ ช่วยวิเคราะห์ผลการดำเนินงานตามช่องทางที่ส่งใบสมัคร และระบุความแตกต่างเพื่อนำไปปรับกลยุทธ์ช่องทางและประสบการณ์ผู้ใช้. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ โดยปกติข้อมูลนี้จะบันทึกเมื่อเริ่มกระบวนการสมัคร. ตัวอย่าง พอร์ทัลเว็บไซต์แอปมือถือสาขาAPI
	ดำเนินการอัตโนมัติหรือไม่ IsAutomated	ตัวบ่งชี้ว่าระบบดำเนินกิจกรรมโดยอัตโนมัติ หรือผู้ใช้เป็นผู้ดำเนินการด้วยตนเอง.
คำอธิบาย แอตทริบิวต์แบบบูลีนนี้ใช้แยกงานที่ระบบทำงานอัตโนมัติ เช่น การตรวจสอบเบื้องต้น ออกจากงานที่ต้องให้คนดำเนินการ เช่น การตรวจสอบเอกสารด้วยตนเอง 'เป็นระบบอัตโนมัติ' ใช้คำนวณ KPI 'สัดส่วนกิจกรรมที่ทำด้วยตนเอง' และวิเคราะห์ประสิทธิผลของโครงการระบบอัตโนมัติ ในแผนผังกระบวนการ แอตทริบิวต์นี้ช่วยให้เห็นจุดเชื่อมต่อระหว่างขั้นตอนอัตโนมัติกับขั้นตอนที่คนทำ และค้นหาโอกาสเพิ่มระบบอัตโนมัติเพื่อลดต้นทุนและเวลาประมวลผล. เหตุผลที่สำคัญ แยกงานที่ทำด้วยตนเองออกจากงานอัตโนมัติ ซึ่งช่วยระบุโอกาสใช้ระบบอัตโนมัติและวัดผลที่เกิดขึ้น. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ ข้อมูลนี้อาจเป็นตัวบ่งชี้ในบันทึกเหตุการณ์ หรืออนุมานจาก 'AssignedUser' เช่น ผู้ใช้ชื่อ 'system'. ตัวอย่าง truefalse
	ประเทศของลูกค้า CustomerCountry	ประเทศที่ลูกค้าอาศัยอยู่หรือจดทะเบียนจัดตั้ง.
คำอธิบาย แอตทริบิวต์นี้ระบุประเทศของลูกค้า ซึ่งเป็นปัจจัยสำคัญใน KYC เนื่องจากกฎระเบียบระหว่างประเทศและระดับความเสี่ยงแตกต่างกันไปตามเขตอำนาจศาล การวิเคราะห์กระบวนการตามประเทศของลูกค้าอาจเผยให้เห็นความแตกต่างอย่างชัดเจนของระยะเวลาดำเนินการและความซับซ้อนของกระบวนการ ตัวอย่างเช่น ใบสมัครจากเขตอำนาจศาลที่มีความเสี่ยงสูงอาจต้องผ่านการตรวจสอบการปฏิบัติตามข้อกำหนดเพิ่มเติม จึงใช้เวลานานขึ้น ข้อมูลนี้ช่วยวางแผนทรัพยากรและกำหนด SLA ที่เหมาะสมสำหรับแต่ละภูมิภาค. เหตุผลที่สำคัญ ช่วยวิเคราะห์ตามเขตอำนาจศาล ซึ่งจำเป็นต่อการทำความเข้าใจว่ากฎระเบียบและปัจจัยความเสี่ยงในแต่ละภูมิภาคส่งผลต่อผลการดำเนินงานของกระบวนการอย่างไร. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ โดยทั่วไปเป็นฟิลด์มาตรฐานในข้อมูลหลักของลูกค้า. ตัวอย่าง USAGBRDEUSGP
	ประเภทใบสมัคร ApplicationType	ประเภทใบสมัครลูกค้า เช่น 'บุคคล' หรือ 'ธุรกิจ'.
คำอธิบาย แอตทริบิวต์นี้จัดประเภทใบสมัครตามประเภทของลูกค้าที่กำลังเข้าสู่กระบวนการ ประเภทใบสมัครที่ต่างกันมักมีเส้นทางกระบวนการ โปรไฟล์ความเสี่ยง และเป้าหมาย SLA ต่างกัน การวิเคราะห์กระบวนการตามประเภทใบสมัครช่วยแบ่งกลุ่มข้อมูลเพื่อเปรียบเทียบประสิทธิภาพและความซับซ้อนในการรับลูกค้าแต่ละประเภท นอกจากนี้ยังเป็นตัวกรองที่ใช้บ่อยในแดชบอร์ดส่วนใหญ่ เพื่อให้เห็นผลการดำเนินงานได้ละเอียดขึ้น. เหตุผลที่สำคัญ ช่วยแบ่งกลุ่มกระบวนการให้เห็นวิธีจัดการใบสมัครแต่ละประเภท และระบุคอขวดเฉพาะของแต่ละประเภท. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ โดยทั่วไปจะเป็นฟิลด์หลักในออบเจ็กต์ใบสมัครหรือเคส. ตัวอย่าง บุคคลธุรกิจบุคคลที่มีสินทรัพย์สุทธิสูงทรัสต์
	เป็นงานแก้ไขซ้ำหรือไม่ IsRework	ตัวบ่งชี้ว่ากิจกรรมเป็นส่วนหนึ่งของวงจรการทำงานซ้ำหรือไม่.
คำอธิบาย ตั้งค่าตัวบ่งชี้แบบบูลีนนี้เป็น true เมื่อมีกิจกรรมเดิมเกิดซ้ำในเคสเดียวกัน เช่น 'ตรวจสอบเอกสารแล้ว' เกิดขึ้นเป็นครั้งที่สองหลังจาก 'ขอข้อมูลเพิ่มเติม' ซึ่งแสดงว่ากระบวนการย้อนกลับไปทำขั้นตอนก่อนหน้า 'เป็นงานแก้ไขซ้ำหรือไม่' จำเป็นต่อแดชบอร์ด 'Rework and Repetition Analysis' และ KPI 'Rework Loop Percentage' ช่วยวัดปริมาณงานที่สูญเปล่าและระบุสาเหตุของการแก้ไขซ้ำ เช่น คำแนะนำไม่ชัดเจนหรือข้อมูลไม่มีคุณภาพ เพื่อนำไปปรับปรุงกระบวนการได้ตรงจุด. เหตุผลที่สำคัญ วัดความไม่มีประสิทธิภาพและงานที่สูญเปล่าในกระบวนการได้โดยตรง พร้อมชี้กิจกรรมที่ต้องทำซ้ำบ่อยและทำให้ต้นทุนกับระยะเวลาดำเนินการเพิ่มขึ้น. แหล่งข้อมูล แอตทริบิวต์นี้คำนวณจากการตรวจจับลำดับกิจกรรมที่เกิดซ้ำภายในเคส โดยทั่วไปคำนวณในเครื่องมือ process mining. ตัวอย่าง truefalse
	ผู้ตรวจสอบการปฏิบัติตามข้อกำหนด ComplianceReviewer	ผู้ใช้หรือตัวแทนที่ได้รับมอบหมายให้ทำกิจกรรมตรวจสอบการปฏิบัติตามข้อกำหนดโดยเฉพาะ.
คำอธิบาย แม้ 'AssignedUser' จะระบุผู้ใช้ของทุกกิจกรรม แต่แอตทริบิวต์นี้ระบุผู้เชี่ยวชาญด้านการปฏิบัติตามข้อกำหนดที่เกี่ยวข้องกับขั้นตอนตรวจสอบสำคัญโดยเฉพาะ จึงช่วยวิเคราะห์งานด้านนี้ได้ตรงจุดยิ่งขึ้น แอตทริบิวต์นี้เป็นข้อมูลหลักของแดชบอร์ด 'Compliance Review Duration and Backlog' ช่วยวิเคราะห์ภาระงานและผลงานของทีมตรวจสอบการปฏิบัติตามข้อกำหนด เพื่อดูว่าผู้ตรวจสอบบางรายเป็นคอขวดหรือทีมมีทรัพยากรไม่เพียงพอโดยรวมหรือไม่. เหตุผลที่สำคัญ ช่วยให้เห็นภาพงานด้านการปฏิบัติตามข้อกำหนดโดยเฉพาะ และวิเคราะห์ภาระงานกับผลงานของผู้ตรวจสอบในขั้นตอนสำคัญที่มักล่าช้านี้ได้อย่างละเอียด. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ คุณสามารถระบุข้อมูลนี้ได้โดยกรอง 'AssignedUser' ตามกิจกรรมที่เกี่ยวข้องกับการปฏิบัติตามข้อกำหนด. ตัวอย่าง c.joness.patelsystem_escalation
	ระบบต้นทาง SourceSystem	ระบบหรือแอปพลิเคชันที่เป็นแหล่งที่มาของข้อมูลเหตุการณ์.
คำอธิบาย แอตทริบิวต์นี้ระบุระบบต้นทางที่สร้างข้อมูลเหตุการณ์ เช่น LexisNexis Risk Solutions หรือเครื่องมือจากผู้ให้บริการภายนอกที่เชื่อมต่อไว้ ในสภาพแวดล้อมที่ซับซ้อน ข้อมูลของกระบวนการเดียวอาจมาจากหลายระบบ การทราบระบบต้นทางช่วยตรวจสอบความถูกต้องของข้อมูล แก้ไขปัญหา และวิเคราะห์ความแตกต่างของกระบวนการที่อาจเกิดจากระบบใดระบบหนึ่ง อีกทั้งช่วยรักษาความถูกต้องของข้อมูลและให้บริบทว่ากิจกรรมถูกบันทึกไว้ที่ใดและอย่างไร. เหตุผลที่สำคัญ ระบุแหล่งที่มาของข้อมูล ซึ่งจำเป็นต่อการกำกับดูแลและตรวจสอบข้อมูล รวมถึงทำความเข้าใจการดำเนินกระบวนการในระบบ IT ต่างๆ. แหล่งข้อมูล ข้อมูลนี้อาจจัดเก็บเป็นค่าคงที่หรืออยู่ในฟิลด์เฉพาะของไฟล์ส่งออกข้อมูลหรือ API response. ตัวอย่าง LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
	ระยะเวลาดำเนินการ CycleTime	ระยะเวลาตั้งแต่ลูกค้าส่งใบสมัครจนถึงการตัดสินใจขั้นสุดท้าย.
คำอธิบาย ระยะเวลาดำเนินการวัดเวลาตั้งแต่เหตุการณ์แรกสุด เช่น 'ส่งใบสมัครแล้ว' จนถึงเหตุการณ์สุดท้าย เช่น 'ดำเนินการรับลูกค้าใหม่เสร็จแล้ว' หรือ 'ปฏิเสธใบสมัคร' ของแต่ละเคส นี่คือ KPI หลักที่ใช้วัดสุขภาพโดยรวมของกระบวนการ และแสดงผลในแดชบอร์ด 'Onboarding End-to-End Cycle Time' การติดตามระยะเวลาดำเนินการเฉลี่ยช่วยให้องค์กรเห็นผลของการปรับปรุงกระบวนการ และเข้าใจว่าปัจจัยต่างๆ เช่น ระดับความเสี่ยงหรือประเภทใบสมัคร ส่งผลต่อประสบการณ์โดยรวมของลูกค้าอย่างไร. เหตุผลที่สำคัญ ตัวชี้วัดผลการดำเนินงานนี้วัดเวลาตั้งแต่เริ่มต้นจนลูกค้าได้รับผลลัพธ์ ซึ่งส่งผลโดยตรงต่อความพึงพอใจของลูกค้าและประสิทธิภาพการปฏิบัติการ. แหล่งข้อมูล ค่านี้คำนวณจากการนำเวลาของเหตุการณ์แรกมาลบออกจากเวลาของเหตุการณ์สุดท้ายในแต่ละเคส. ตัวอย่าง 5 วัน 4 ชั่วโมง22 วัน 8 ชั่วโมง1 วัน 2 ชั่วโมง
	สถานะ SLA SlaStatus	ระบุว่าใบสมัครที่ดำเนินการเสร็จแล้วเป็นไปตามเป้าหมาย SLA หรือไม่.
คำอธิบาย แอตทริบิวต์นี้จัดประเภทเคสที่เสร็จแล้วตามการปฏิบัติตาม 'SlaTargetDate' โดยค่าที่พบบ่อยคือ 'ตามกำหนด' หรือ 'เกินกำหนด' ฟิลด์ที่คำนวณนี้เป็นพื้นฐานของแดชบอร์ด 'SLA Target Adherence Monitoring' และ KPI 'SLA Adherence Rate' ช่วยให้เห็นภาพรวมผลการดำเนินงานเทียบกับข้อตกลงระดับการให้บริการอย่างชัดเจน และเจาะลึกเพื่อทำความเข้าใจลักษณะร่วมของเคสที่ผิด SLA ได้. เหตุผลที่สำคัญ แสดงผลการดำเนินงานตาม SLA เป็นผลลัพธ์ที่ชัดเจนสองสถานะ จึงติดตาม รายงาน และวิเคราะห์การปฏิบัติตามเป้าหมายระดับการให้บริการได้ง่าย. แหล่งข้อมูล แอตทริบิวต์นี้คำนวณโดยเปรียบเทียบเวลาของกิจกรรมสุดท้ายกับ 'SlaTargetDate' ของแต่ละเคส. ตัวอย่าง ตามกำหนดเกินกำหนดเสี่ยงเกินกำหนด
	เหตุผลที่ปฏิเสธ RejectionReason	รหัสหรือคำอธิบายที่ระบุสาเหตุที่ปฏิเสธใบสมัคร.
คำอธิบาย เมื่อสถานะสุดท้ายของใบสมัครเป็น 'ปฏิเสธแล้ว' แอตทริบิวต์นี้จะแสดงเหตุผลโดยเฉพาะ เช่น 'ยืนยันตัวตนไม่ผ่าน', 'พบชื่อในรายการคว่ำบาตร' หรือ 'เอกสารไม่ครบถ้วน' ข้อมูลนี้เป็นข้อมูลหลักของแดชบอร์ด 'Application Rejection Reasons & Stages' การวิเคราะห์เหตุผลที่ปฏิเสธช่วยระบุจุดที่มักเกิดปัญหาในกระบวนการ และนำไปปรับปรุงแนวทางการสมัคร การสื่อสารกับลูกค้า หรือเกณฑ์การตรวจสอบภายใน การเข้าใจสาเหตุที่ปฏิเสธใบสมัครเป็นกุญแจสำคัญในการเพิ่มอัตราการอนุมัติโดยรวม. เหตุผลที่สำคัญ ช่วยให้เห็นสาเหตุที่กระบวนการรับลูกค้าใหม่ไม่สำเร็จโดยตรง และปรับปรุงได้ตรงจุดเพื่อเพิ่มอัตราการอนุมัติใบสมัคร. แหล่งข้อมูล ตรวจสอบเอกสารของ LexisNexis Risk Solutions หรือสอบถามผู้ดูแลระบบ โดยมักพบในฟิลด์ที่มีการกรอกค่าเมื่อสถานะใบสมัครเปลี่ยนเป็น 'ปฏิเสธแล้ว'. ตัวอย่าง พบชื่อในรายการคว่ำบาตรเอกสารไม่ครบถ้วนยืนยันตัวตนไม่ผ่านโปรไฟล์ความเสี่ยงสูง
	อัปเดตข้อมูลล่าสุด LastDataUpdate	วันและเวลาที่มีการรีเฟรชหรือดึงข้อมูลจากระบบต้นทางครั้งล่าสุด.
คำอธิบาย แอตทริบิวต์นี้ระบุเวลาที่อัปเดตชุดข้อมูลครั้งล่าสุด โดยทั่วไปจะบันทึกไว้กับชุดข้อมูลทั้งหมดในขั้นตอนดึงและโหลดข้อมูล ข้อมูลนี้ช่วยให้ผู้ใช้แดชบอร์ดทราบว่าข้อมูลที่กำลังวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด เพื่อให้ตัดสินใจจากข้อมูลที่เป็นปัจจุบันตามต้องการ และเข้าใจกรอบเวลาของข้อมูลเชิงลึกที่ได้รับ. เหตุผลที่สำคัญ ให้บริบทสำคัญเกี่ยวกับความใหม่ของข้อมูล ช่วยให้การวิเคราะห์ยังเกี่ยวข้องกับสถานการณ์ปัจจุบันและป้องกันการตัดสินใจจากข้อมูลเก่า. แหล่งข้อมูล โดยปกติระบบจะสร้างและประทับเวลานี้ไว้กับชุดข้อมูลระหว่างกระบวนการ ETL (Extract, Transform, Load). ตัวอย่าง 2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z

จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในกระบวนการรับลูกค้าใหม่ KYC

ขั้นตอนและจุดสำคัญเหล่านี้ควรบันทึกไว้ในบันทึกเหตุการณ์ เพื่อให้ค้นพบกระบวนการและวิเคราะห์ประสิทธิภาพได้อย่างแม่นยำ.

8 แนะนำ 6 ไม่บังคับ

	กิจกรรม	คำอธิบาย
	ได้รับเอกสารแล้ว	ยืนยันว่าลูกค้าอัปโหลดหรือส่งเอกสารที่ต้องการเข้าสู่ระบบแล้ว โดยทั่วไป พอร์ทัลส่งเอกสารจะสร้างเหตุการณ์นี้โดยอัตโนมัติ หรือเจ้าหน้าที่อาจบันทึกข้อมูลด้วยตนเอง.
เหตุผลที่สำคัญ กิจกรรมนี้สิ้นสุดช่วงเวลารอและเริ่มขั้นตอนตรวจสอบถัดไป ถือเป็นหมุดหมายสำคัญในช่วงเก็บข้อมูล. แหล่งข้อมูล ดึงข้อมูลจากบันทึกของระบบจัดการเอกสาร หรือเวลาที่ระบุในแฟ้มเคสใบสมัครเมื่อมีการแนบเอกสารใหม่. บันทึก ระบบบันทึกเหตุการณ์เมื่ออัปโหลดเอกสารสำเร็จ หรือเมื่อมีผู้ทำเครื่องหมายว่าได้รับเอกสารแล้วด้วยตนเอง. ประเภทเหตุการณ์ explicit
	ตรวจสอบการปฏิบัติตามข้อกำหนดเสร็จแล้ว	เจ้าหน้าที่ตรวจสอบการปฏิบัติตามข้อกำหนดเสร็จและให้ข้อเสนอแนะ จากนั้นเคสจะเข้าสู่ขั้นตอนถัดไป ระบบบันทึกเหตุการณ์นี้ได้เมื่อทำเครื่องหมายว่างาน 'เสร็จแล้ว' หรืออนุมานได้เมื่อสถานะเปลี่ยนจาก 'รอตรวจสอบการปฏิบัติตามข้อกำหนด' เป็นสถานะอื่น.
เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญที่สิ้นสุดขั้นตอนสำคัญซึ่งมักต้องทำด้วยตนเอง และเป็นจุดสิ้นสุดสำหรับวัดระยะเวลาการตรวจสอบการปฏิบัติตามข้อกำหนด. แหล่งข้อมูล ดึงข้อมูลจากเวลาที่งานตรวจสอบการปฏิบัติตามข้อกำหนดเสร็จสิ้น หรือจากการเปลี่ยนสถานะออกจาก 'อยู่ระหว่างตรวจสอบการปฏิบัติตามข้อกำหนด'. บันทึก อนุมานได้จากการเปลี่ยนสถานะที่ระบุว่าตรวจสอบเสร็จแล้ว เช่น เปลี่ยนเป็น 'อนุมัติ' 'ปฏิเสธ' หรือ 'ตัดสินใจขั้นสุดท้าย'. ประเภทเหตุการณ์ inferred
	ปฏิเสธใบสมัครแล้ว	ระบบบันทึกการตัดสินใจขั้นสุดท้ายที่ปฏิเสธใบสมัครของลูกค้า เหตุการณ์นี้เป็นจุดสิ้นสุดและบันทึกผ่านการเปลี่ยนสถานะที่ชัดเจนในระบบ.
เหตุผลที่สำคัญ นี่คือเหตุการณ์สิ้นสุดที่แสดงความไม่สำเร็จหลัก การวิเคราะห์ขั้นตอนที่เกิดการปฏิเสธและเหตุผลที่เกี่ยวข้องมีความสำคัญต่อการปรับปรุงกระบวนการ. แหล่งข้อมูล ดึงข้อมูลจากฟิลด์สถานะสุดท้ายในระเบียนใบสมัคร ซึ่งตั้งค่าเป็น 'ปฏิเสธ' 'ไม่อนุมัติ' หรือสถานะสิ้นสุดที่มีความหมายใกล้เคียงกัน. บันทึก บันทึกเป็นการเปลี่ยนสถานะสุดท้ายที่ชัดเจนในตารางใบสมัครหรือตารางเคสหลัก. ประเภทเหตุการณ์ explicit
	ประเมินความเสี่ยงแล้ว	ระบบคำนวณคะแนนความเสี่ยงของลูกค้าจากข้อมูลที่รวบรวมและผลการตรวจสอบ นี่เป็นฟีเจอร์หลักของ LexisNexis และโดยทั่วไปจะบันทึกเป็นเหตุการณ์อัตโนมัติอย่างชัดเจนในประวัติเคส.
เหตุผลที่สำคัญ ผลการประเมินนี้มักกำหนดเส้นทางถัดไปของกระบวนการ เช่น ต้องตรวจสอบสถานะลูกค้าอย่างละเอียดเพิ่มเติม จึงเป็นจุดตัดสินใจสำคัญในเวิร์กโฟลว์. แหล่งข้อมูล ค้นหาเหตุการณ์ในบันทึกการตรวจสอบหรือประวัติเวิร์กโฟลว์ของใบสมัครที่ระบุว่าโมดูลให้คะแนนหรือประเมินความเสี่ยงทำงานเสร็จแล้ว. บันทึก ระบบบันทึกเหตุการณ์เฉพาะเมื่อเครื่องมือประเมินความเสี่ยงวิเคราะห์เสร็จและกำหนดระดับหรือคะแนนความเสี่ยงแล้ว. ประเภทเหตุการณ์ explicit
	เริ่มต้นใช้งานลูกค้าเสร็จแล้ว	เหตุการณ์นี้แสดงว่ากระบวนการเริ่มต้นใช้งานทั้งหมดเสร็จสมบูรณ์และลูกค้าเปิดใช้งานเต็มรูปแบบแล้ว อาจบันทึกเป็นสถานะสุดท้ายโดยตรง หรืออนุมานจากเหตุการณ์ 'เปิดใช้งานบัญชีแล้ว'.
เหตุผลที่สำคัญ นี่คือเหตุการณ์สิ้นสุดที่แสดงความสำเร็จหลัก ซึ่งจำเป็นต่อการคำนวณเวลาตั้งแต่ต้นจนจบของลูกค้าทุกรายที่เริ่มใช้งานสำเร็จ. แหล่งข้อมูล อนุมานจากเวลาที่ 'เปิดใช้งานบัญชีแล้ว' หรือดึงจากสถานะสุดท้าย เช่น 'เริ่มต้นใช้งานเสร็จแล้ว' ในแฟ้มเคส. บันทึก อนุมานจากเหตุการณ์เชิงบวกที่สำคัญครั้งสุดท้าย เช่น การเปิดใช้งานบัญชี หรือการอัปเดตสถานะสุดท้าย. ประเภทเหตุการณ์ inferred
	เริ่มตรวจสอบการปฏิบัติตามข้อกำหนด	มอบหมายเคสให้เจ้าหน้าที่หรือทีมดูแลการปฏิบัติตามข้อกำหนดตรวจสอบด้วยตนเอง โดยทั่วไปใช้กับใบสมัครที่มีความเสี่ยงสูง อนุมานได้จากการเปลี่ยนสถานะเป็น 'รอตรวจสอบการปฏิบัติตามข้อกำหนด' หรือจากบันทึกการมอบหมายงาน.
เหตุผลที่สำคัญ เป็นจุดเริ่มต้นของขั้นตอนตรวจสอบด้วยตนเอง ซึ่งมักใช้เวลานาน การวัดเวลาตั้งแต่จุดนี้จนเสร็จช่วยประเมินคอขวดที่เกี่ยวข้องกับการปฏิบัติตามข้อกำหนดได้. แหล่งข้อมูล ดึงข้อมูลจากบันทึกการมอบหมายงาน การเปลี่ยนผู้รับผิดชอบเคสเป็นทีมดูแลการปฏิบัติตามข้อกำหนด หรือการอัปเดตสถานะในประวัติเคส. บันทึก อนุมานได้จากการเปลี่ยนสถานะ เช่น 'อยู่ระหว่างตรวจสอบการปฏิบัติตามข้อกำหนด' หรือเมื่อมอบหมายเคสให้คิวงานของผู้ใช้ที่เกี่ยวข้องกับการปฏิบัติตามข้อกำหนด. ประเภทเหตุการณ์ inferred
	ส่งใบสมัครแล้ว	เป็นจุดเริ่มต้นของกระบวนการเริ่มต้นใช้งาน KYC เมื่อระบบได้รับใบสมัครของลูกค้าเป็นครั้งแรก โดยทั่วไป ระบบจะบันทึกเหตุการณ์นี้เมื่อส่งแบบฟอร์มผ่านพอร์ทัลลูกค้าหรือระบบป้อนข้อมูลภายในที่เชื่อมต่อกับ LexisNexis.
เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ การวิเคราะห์เวลาตั้งแต่กิจกรรมนี้จนถึงขั้นตอนเสร็จสิ้นมีความสำคัญต่อการวัดเวลาตั้งแต่ต้นจนจบและการทำตาม SLA. แหล่งข้อมูล ดึงข้อมูลจากบันทึกระบบหรือตารางใบสมัครที่บันทึกเวลาสร้างรายการใบสมัครลูกค้าใหม่ครั้งแรก. บันทึก ระบบบันทึกเหตุการณ์เมื่อสร้างเคสใบสมัครใหม่หรือเพิ่มรายการในตารางใบสมัครหลัก. ประเภทเหตุการณ์ explicit
	อนุมัติใบสมัครแล้ว	ระบบตัดสินใจอนุมัติใบสมัครของลูกค้าและบันทึกผล นี่คือผลลัพธ์ทางธุรกิจที่สำคัญ และเกือบทุกครั้งจะบันทึกไว้อย่างชัดเจนผ่านการเปลี่ยนสถานะ.
เหตุผลที่สำคัญ หมุดหมายนี้แสดงว่ากระบวนการตัดสินใจเสร็จสมบูรณ์ การวิเคราะห์เส้นทางที่นำไปสู่การอนุมัติช่วยให้ระบุแนวทางปฏิบัติที่ดีได้. แหล่งข้อมูล ค้นหาการอัปเดตสถานะสุดท้ายในระเบียนเคสใบสมัคร โดยสถานะจะเป็น 'อนุมัติ' หรือสถานะสิ้นสุดที่มีความหมายใกล้เคียงกัน. บันทึก บันทึกเป็นการเปลี่ยนสถานะสุดท้ายที่ชัดเจนในตารางใบสมัครหรือตารางเคสหลัก. ประเภทเหตุการณ์ explicit
	ขอข้อมูลเพิ่มเติมแล้ว	เจ้าหน้าที่หรือผู้ตรวจสอบขอข้อมูลเพิ่มเติมหรือขอคำชี้แจงจากลูกค้า เหตุการณ์นี้เป็นสาเหตุหลักของงานที่ต้องทำซ้ำ และโดยทั่วไปจะบันทึกไว้อย่างชัดเจนผ่านการเปลี่ยนสถานะหรือรายการสื่อสาร.
เหตุผลที่สำคัญ กิจกรรมนี้ทำให้เกิดการวนกลับไปทำงานซ้ำและยืดเวลาของกระบวนการเริ่มต้นใช้งาน การติดตามความถี่ช่วยระบุข้อกำหนดที่ไม่ชัดเจนหรือข้อบกพร่องที่พบบ่อยในใบสมัคร. แหล่งข้อมูล ค้นหาการเปลี่ยนสถานะเป็น 'รอข้อมูลจากลูกค้า' หรือเหตุการณ์การสื่อสารขาออก โดยมากผู้ใช้เป็นผู้เริ่มดำเนินการนี้. บันทึก ระบบบันทึกเหตุการณ์เมื่อเจ้าหน้าที่ใช้ฟีเจอร์ 'ขอข้อมูล' ซึ่งจะเปลี่ยนสถานะเคสและอาจบันทึกเหตุการณ์การสื่อสารด้วย. ประเภทเหตุการณ์ explicit
	ขอเอกสารแล้ว	ระบบหรือผู้ใช้ขอเอกสารเฉพาะจากลูกค้า เช่น ใบขับขี่หรือใบแจ้งค่าสาธารณูปโภค ดึงเหตุการณ์นี้ได้จากบันทึกการสื่อสารที่ระบบสร้างขึ้น หรือการเปลี่ยนสถานะที่ระบุว่าเคสกำลังรอเอกสาร.
เหตุผลที่สำคัญ กิจกรรมนี้มักทำให้เกิดเวลารอคอยนาน การวิเคราะห์ความถี่และระยะเวลาช่วยระบุความล่าช้าที่เกิดจากเวลาตอบกลับของลูกค้า. แหล่งข้อมูล ตรวจสอบเหตุการณ์ในบันทึกการสื่อสารที่ส่งถึงลูกค้า หรือการเปลี่ยนสถานะของใบสมัคร เช่น 'รอเอกสารจากลูกค้า'. บันทึก อนุมานได้จากการเปลี่ยนสถานะเป็น 'รอเอกสาร' หรือจากเวลาที่บันทึกการสื่อสารขาออก. ประเภทเหตุการณ์ inferred
	ตรวจสอบเบื้องต้นแล้ว	ระบบตรวจสอบโดยอัตโนมัติทันทีหลังส่งใบสมัคร เพื่อตรวจว่าข้อมูลพื้นฐานครบถ้วนและดำเนินการตรวจสอบเบื้องต้น กิจกรรมนี้มักบันทึกไว้อย่างชัดเจนในประวัติเวิร์กโฟลว์ของกระบวนการ.
เหตุผลที่สำคัญ ช่วยระบุใบสมัครที่ไม่ผ่านตั้งแต่ขั้นตอนแรก ทำให้เข้าใจปัญหาคุณภาพข้อมูลได้ดีขึ้น และยังเป็นขั้นตอนแรกที่ระบบทำงานอัตโนมัติเพื่อเพิ่มคุณค่าให้กระบวนการ. แหล่งข้อมูล ค้นหาบันทึกการทำงานของกฎอัตโนมัติ หรือการเปลี่ยนสถานะในประวัติเวิร์กโฟลว์ของใบสมัครที่แสดงว่าการตรวจสอบเบื้องต้นเสร็จแล้ว. บันทึก บันทึกเป็นงานอัตโนมัติที่เสร็จสมบูรณ์ หรือเป็นการอัปเดตสถานะเฉพาะในประวัติเคส. ประเภทเหตุการณ์ explicit
	ตรวจสอบเอกสารแล้ว	ผู้ใช้หรือเครื่องมืออัตโนมัติตรวจสอบความถูกต้อง ความสมบูรณ์ และความครบถ้วนของเอกสารที่ส่งมา อนุมานกิจกรรมนี้ได้จากการเปลี่ยนสถานะจาก 'ได้รับเอกสารแล้ว' เป็น 'ตรวจสอบเสร็จแล้ว' หรือจากรายการบันทึกเหตุการณ์ที่ระบุชัดเจน.
เหตุผลที่สำคัญ ขั้นตอนนี้มักเป็นสาเหตุของคอขวดและงานที่ต้องทำซ้ำ การวิเคราะห์เวลาที่ใช้และจำนวนครั้งที่ทำซ้ำมีความสำคัญต่อการเพิ่มประสิทธิภาพและค้นหาโอกาสในการทำงานอัตโนมัติ. แหล่งข้อมูล อนุมานได้จากการติดตามเวลาระหว่างสถานะ 'ได้รับเอกสารแล้ว' กับสถานะถัดไป เช่น 'ผ่านการตรวจสอบ' หรือ 'ต้องการข้อมูลเพิ่มเติม'. บันทึก คำนวณจากเวลาระหว่างเหตุการณ์ที่ได้รับเอกสารกับเหตุการณ์ที่ระบุว่าตรวจสอบเสร็จแล้ว. ประเภทเหตุการณ์ inferred
	เปิดใช้งานบัญชีแล้ว	หลังอนุมัติ ระบบจะสร้างและเปิดใช้งานบัญชีของลูกค้าในแพลตฟอร์มธนาคารหรือบริการหลัก กิจกรรมนี้มักบันทึกไว้ในประวัติการตรวจสอบ หรืออนุมานได้จากวันที่สร้างบัญชี.
เหตุผลที่สำคัญ นี่คือขั้นตอนสุดท้ายที่ส่งมอบคุณค่าให้ลูกค้า ความล่าช้าระหว่าง 'อนุมัติใบสมัครแล้ว' กับขั้นตอนนี้อาจบ่งชี้ถึงปัญหาการเชื่อมต่อระหว่างระบบ. แหล่งข้อมูล ดึงข้อมูลจากบันทึกการสร้างบัญชี การเรียก API ไปยังระบบอื่น หรือเวลาที่สร้างระเบียนบัญชี. บันทึก บันทึกเป็นเหตุการณ์แยกหลังการอนุมัติ หรือระบุได้จากเวลาที่เปิดใช้งานในระเบียนลูกค้า. ประเภทเหตุการณ์ explicit
	เริ่มตรวจสอบตัวตน	เป็นจุดที่ระบบเริ่มตรวจสอบตัวตน ซึ่งเป็นขั้นตอนหลัก โดยใช้บริการของ LexisNexis เช่น การตรวจสอบกับฐานข้อมูล โดยปกติจะมีบันทึกเหตุการณ์อย่างชัดเจนเมื่อเรียกใช้บริการตรวจสอบ.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นของกระบวนการย่อยที่สำคัญและมักใช้เวลานาน การติดตามระยะเวลาช่วยแยกคอขวดที่เกี่ยวข้องกับการตรวจสอบตัวตนได้. แหล่งข้อมูล ดึงข้อมูลจากบันทึกการเรียก API ไปยังโมดูลตรวจสอบตัวตน หรือรายการตรวจสอบย้อนหลังที่ระบุเวลาเริ่มงานตรวจสอบ. บันทึก ระบบบันทึกเหตุการณ์เมื่อเรียกใช้โมดูลหรือ API ตรวจสอบตัวตนสำหรับใบสมัคร. ประเภทเหตุการณ์ explicit

แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

วิธีดึงข้อมูลจาก LexisNexis Risk Solutions

ขั้นตอน

เตรียมสภาพแวดล้อม Python: ติดตั้ง Python 3.8 หรือใหม่กว่าบนระบบ เปิดเทอร์มินัลหรือพรอมต์คำสั่ง แล้วติดตั้งไลบรารีที่จำเป็นด้วยคำสั่ง pip install requests pandas.
ขอข้อมูลรับรอง API: ติดต่อผู้ดูแลระบบหรือผู้ดูแลบัญชี LexisNexis Risk Solutions เพื่อขอข้อมูลรับรอง API ซึ่งประกอบด้วย API Key, API Secret และ Base URL สำหรับ API endpoints.
ตั้งค่าสคริปต์ Python: เปิดสคริปต์ Python ที่ให้มาในโปรแกรมแก้ไขข้อความ ไปที่ส่วนตั้งค่าด้านบน แล้วแทนค่าตัวอย่างของ API_KEY, API_SECRET และ BASE_URL ด้วยข้อมูลรับรองจริงของคุณ.
กำหนดพารามิเตอร์การดึงข้อมูล: ในส่วนตั้งค่าเดียวกัน ให้กำหนดช่วงเวลาที่ต้องการดึงข้อมูลด้วยตัวแปร START_DATE และ END_DATE โดยใช้รูปแบบวันที่ 'YYYY-MM-DD' แนะนำให้เริ่มจากช่วงสั้นๆ เช่น หนึ่งเดือน เพื่อทดสอบการดึงข้อมูล.
ตรวจสอบการจับคู่กิจกรรม: ตรวจสอบพจนานุกรม ACTIVITY_MAP ในสคริปต์ ซึ่งใช้จับคู่ประเภทเหตุการณ์จากการตอบกลับของ LexisNexis API กับชื่อกิจกรรมมาตรฐานที่ต้องใช้ในบันทึกเหตุการณ์ คุณอาจต้องปรับคีย์และค่าทางซ้ายให้ตรงกับชื่อเหตุการณ์ที่ใช้ในการตั้งค่า LexisNexis ของคุณ ตรวจสอบชื่อเหล่านี้ได้จากตัวอย่างการตอบกลับของ API.
เรียกใช้สคริปต์: เรียกใช้สคริปต์จากเทอร์มินัลด้วยคำสั่ง python your_script_name.py สคริปต์จะยืนยันตัวตน ดึงรายการใบสมัครลูกค้าในช่วงวันที่ที่กำหนด แล้วดึงประวัติเหตุการณ์ของแต่ละรายการ.
ติดตามความคืบหน้าของสคริปต์: สคริปต์จะแสดงข้อความความคืบหน้าในคอนโซล เช่น จำนวนใบสมัครที่กำลังประมวลผล ตรวจสอบข้อความแสดงข้อผิดพลาด ซึ่งอาจบ่งชี้ถึงปัญหาเกี่ยวกับข้อมูลรับรอง API endpoints หรือการจำกัดอัตราการเรียกใช้.
รับไฟล์ผลลัพธ์: เมื่อสคริปต์ทำงานเสร็จ ไฟล์ชื่อ lexisnexis_event_log.csv จะถูกสร้างในโฟลเดอร์เดียวกัน โดยไฟล์นี้มีบันทึกเหตุการณ์ที่ดึงมา.
เตรียมอัปโหลด: ก่อนอัปโหลดไปยังเครื่องมือ process mining ให้เปิดไฟล์ CSV และตรวจสอบว่ามีคอลัมน์ที่ต้องการ เช่น CustomerApplication, ActivityName, EventTimestamp และคอลัมน์อื่นๆ ตรวจดูว่าข้อมูลถูกต้องและสอดคล้องกัน.
อัปโหลดไปยัง ProcessMind: อัปโหลดไฟล์ lexisnexis_event_log.csv ที่สร้างขึ้นไปยังแอปพลิเคชัน process mining แล้วจับคู่คอลัมน์กับฟิลด์รหัสเคส กิจกรรม และเวลาให้ตรงกัน.

การกำหนดค่า

ข้อมูลรับรอง API: ต้องใช้ API Key และ Secret ที่ยังใช้งานได้เพื่อยืนยันตัวตน ขอข้อมูลเหล่านี้จากผู้ดูแลระบบ LexisNexis และเก็บเป็นความลับ.
API Endpoints: ตั้งค่าสคริปต์ด้วย Base URL ที่ถูกต้องสำหรับ LexisNexis REST API โดยกำหนด endpoints สำหรับดึงใบสมัครและประวัติเหตุการณ์ไว้ในโค้ดสคริปต์.
ช่วงวันที่: พารามิเตอร์ START_DATE และ END_DATE ใช้กำหนดช่วงเวลาที่ต้องการดึงข้อมูล เพื่อให้ทำงานได้มีประสิทธิภาพและหลีกเลี่ยงการเรียก API เกินอัตราที่กำหนด แนะนำให้ดึงข้อมูลเป็นชุด ชุดละ 3 ถึง 6 เดือน.
การจับคู่กิจกรรม: พจนานุกรม ACTIVITY_MAP เป็นการตั้งค่าที่สำคัญ คุณต้องตรวจสอบว่าชื่อเหตุการณ์ต้นทางจาก API ซึ่งใช้เป็นคีย์ในพจนานุกรม ตรงกับชื่อที่ระบบของคุณสร้าง เหตุการณ์ที่ไม่ได้จับคู่จะถูกละเว้น.
การจำกัดอัตราการเรียกใช้: สคริปต์มีการหน่วงเวลาพื้นฐานระหว่างการเรียก API เพื่อรองรับข้อจำกัดด้านอัตราการเรียกใช้ หากมีข้อมูลจำนวนมาก คุณอาจต้องปรับค่า API_CALL_DELAY_SECONDS หรือเพิ่มกลไกหน่วงเวลาแบบปรับตามสถานการณ์.
ข้อกำหนดเบื้องต้น: วิธีนี้ต้องใช้ระบบที่ติดตั้ง Python 3.x พร้อมไลบรารี requests และ pandas ผู้ใช้หรือบัญชีบริการที่เรียกใช้สคริปต์ต้องมีสิทธิ์เพียงพอในการเข้าถึง LexisNexis API.

ตัวอย่างคำค้น 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()

พร้อมเริ่มต้นหรือยัง?

ใช้เทมเพลตนี้เพื่อเริ่มต้นทำ process mining กับกระบวนการรับลูกค้าใหม่ KYC เปลี่ยนข้อมูลของคุณให้เป็นข้อมูลเชิงลึกที่นำไปใช้ได้จริงตั้งแต่วันนี้.

กลับไปยังคู่มือการปรับปรุง

ดาวน์โหลดเทมเพลต

ปรับปรุงการรับลูกค้าใหม่ KYC ลดการละทิ้งใบสมัครได้ตั้งแต่วันนี้

ทำให้การรับลูกค้าใหม่เป็นไปอย่างราบรื่น และลดเวลาเหลือเพียง 24 ชั่วโมง.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงกระบวนการได้วันนี้.

เทมเพลตข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

เทมเพลตข้อมูลสำหรับกระบวนการรับลูกค้าใหม่ KYC

แอตทริบิวต์ของกระบวนการรับลูกค้าใหม่ KYC

กิจกรรมในกระบวนการรับลูกค้าใหม่ KYC

คู่มือการดึงข้อมูล

ดึงข้อมูลจาก LexisNexis API ด้วยสคริปต์ Python

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น python

พร้อมเริ่มต้นหรือยัง?

ปรับปรุงการรับลูกค้าใหม่ KYC ลดการละทิ้งใบสมัครได้ตั้งแต่วันนี้