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

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

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

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

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

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

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

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

เหตุผลที่สำคัญ

แอตทริบิวต์นี้กำหนดขั้นตอนในแผนผังกระบวนการ ทำให้มองเห็น วิเคราะห์ และเข้าใจการไหลของกระบวนการได้.

แหล่งข้อมูล

โดยทั่วไป ข้อมูลนี้บันทึกไว้ในประวัติการตรวจสอบของ Pega (ตารางประวัติ) หรืออนุมานได้จากการเปลี่ยนสถานะของเคส.

ตัวอย่าง
ตรวจสอบเบื้องต้นแล้วตรวจสอบการปฏิบัติตามข้อกำหนดเสร็จแล้วอนุมัติคำขอแล้ว
ใบสมัครของลูกค้า
CustomerApplication
รหัสเฉพาะของเคสใบสมัครรับลูกค้าใหม่แต่ละรายการ.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

โดยทั่วไป นี่คือรหัสเคสหลักใน Pega ซึ่งมักดูได้จาก pzInsKey หรือชื่ออื่นที่เข้าใจง่ายสำหรับธุรกิจใน work object ของประเภทเคสหลัก.

ตัวอย่าง
APP-2023-00123APP-2023-00124APP-2023-00125
เวลาเริ่มต้น
EventTime
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เริ่มต้นเมื่อใด.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ข้อมูลนี้เป็นส่วนมาตรฐานในประวัติการตรวจสอบของ Pega โดยมักจัดเก็บเป็น pxTimeCreated ในตารางประวัติของแต่ละเหตุการณ์.

ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
ผู้ใช้
OperatorId
รหัสเฉพาะของผู้ใช้ที่ดำเนินกิจกรรม.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ฟิลด์นี้เป็นส่วนมาตรฐานในประวัติการตรวจสอบของ Pega โดยทั่วไปจัดเก็บเป็น pxUpdateOperator หรือพร็อพเพอร์ตีที่คล้ายกันในตารางประวัติ.

ตัวอย่าง
j.doe@acmebank.comkyc_analyst_04system_auto_agent
แผนก
WorkGroup
แผนกหรือทีมงานที่รับผิดชอบกิจกรรม.
คำอธิบาย

แอตทริบิวต์นี้ระบุหน่วยงานหรือทีมที่ผู้ดำเนินงานสังกัด เช่น 'ทีมคัดกรอง' 'ฝ่ายกำกับดูแล' หรือ 'ทีมปฏิบัติการรับลูกค้าใหม่'

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

เหตุผลที่สำคัญ

ช่วยวิเคราะห์การไหลของกระบวนการและคอขวดระหว่างหน่วยงาน สนับสนุนการจัดการทรัพยากรและการปรับปรุงองค์กร.

แหล่งข้อมูล

โดยทั่วไป ข้อมูลนี้เชื่อมโยงกับโปรไฟล์ผู้ใช้ใน Pega (ระเบียน Operator ID) และนำมาเชื่อมกับข้อมูลเหตุการณ์ได้ พร็อพเพอร์ตีที่ใช้อาจเป็น pyWorkGroup.

ตัวอย่าง
การคัดกรองเบื้องต้นการทบทวนด้านการปฏิบัติตามข้อกำหนดการเปิดใช้งานบัญชี
ระดับความเสี่ยง
RiskLevel
ระดับความเสี่ยงที่คำนวณได้ของใบสมัครลูกค้า.
คำอธิบาย

แอตทริบิวต์นี้แสดงระดับความเสี่ยงที่ประเมินได้ของลูกค้า โดยมักแบ่งเป็น 'ต่ำ' 'ปานกลาง' หรือ 'สูง' โดยทั่วไป ระบบให้คะแนนอัตโนมัติจะประเมินระดับความเสี่ยงจากข้อมูลลูกค้าและผลการคัดกรอง

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

เหตุผลที่สำคัญ

ช่วยอธิบายความแตกต่างของเส้นทางและระยะเวลาในกระบวนการ เพราะระดับความเสี่ยงมักกำหนดระดับการตรวจสอบสถานะที่ต้องดำเนินการ.

แหล่งข้อมูล

นี่น่าจะเป็นพร็อพเพอร์ตีที่คำนวณในเคส โดยใช้ decision rule หรือโมเดลให้คะแนนของ Pega โปรดดูเอกสาร Pega KYC.

ตัวอย่าง
ต่ำปานกลางสูง
วันที่เป้าหมายตาม SLA
SlaTargetDate
วันที่คาดว่าจะดำเนินการเคสรับลูกค้าใหม่เสร็จ.
คำอธิบาย

แอตทริบิวต์นี้เก็บวันที่เป้าหมายในการดำเนินใบสมัครให้เสร็จตามข้อตกลงระดับการให้บริการ (SLA) โดย SLA อาจแตกต่างกันตามประเภทลูกค้า ระดับความเสี่ยง หรือผลิตภัณฑ์

วันที่นี้จำเป็นต่อแดชบอร์ด 'ติดตามการปฏิบัติตาม SLA' และ KPI ที่เกี่ยวข้อง ใช้เป็นเกณฑ์เปรียบเทียบกับวันที่ดำเนินการเสร็จจริง การวิเคราะห์เคสที่ไม่ทันเป้าหมาย SLA ช่วยระบุความล่าช้าที่เกิดซ้ำและจัดลำดับความสำคัญของการปรับปรุงกระบวนการ เพื่อให้เป็นไปตามข้อตกลงการให้บริการ.

เหตุผลที่สำคัญ

เป็นเกณฑ์วัดว่าดำเนินงานเสร็จตรงเวลาหรือไม่ ซึ่งสำคัญต่อความพึงพอใจของลูกค้าและการควบคุมการปฏิบัติการ.

แหล่งข้อมูล

Pega มีกรอบการจัดการ SLA ในตัว โดยทั่วไป วันที่นี้จัดเก็บในพร็อพเพอร์ตี เช่น pySLAGoal หรือพร็อพเพอร์ตี SLA ที่กำหนดขึ้นเองในเคส.

ตัวอย่าง
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
เวลาสิ้นสุด
EndTime
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด.
คำอธิบาย

แอตทริบิวต์นี้บันทึกวันที่และเวลาที่กิจกรรมสิ้นสุดอย่างแม่นยำ เมื่อนำมาใช้ร่วมกับเวลาเริ่มต้น จะช่วยคำนวณเวลาที่ใช้ดำเนินกิจกรรมแต่ละรายการ

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ข้อมูลนี้อาจมีอยู่ในประวัติการตรวจสอบของ Pega หรืออาจต้องอนุมานโดยใช้เวลาเริ่มต้นของเหตุการณ์ถัดไปเป็นเวลาสิ้นสุดของเหตุการณ์ปัจจุบัน.

ตัวอย่าง
2023-10-26T10:15:00Z2023-10-26T18:05:20Z2023-10-27T11:00:00Z
สถานะใบสมัคร
ApplicationStatus
ผลลัพธ์สุดท้ายหรือสถานะปัจจุบันของใบสมัครลูกค้า.
คำอธิบาย

แอตทริบิวต์นี้ระบุสถานะโดยรวมของใบสมัครเมื่อสิ้นสุดกระบวนการ เช่น 'อนุมัติ' 'ปฏิเสธ' หรือ 'ถอนใบสมัคร' และยังแสดงสถานะล่าสุดที่ทราบสำหรับเคสที่ยังดำเนินอยู่ได้

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

เหตุผลที่สำคัญ

ระบุผลลัพธ์ทางธุรกิจของเคส ทำให้เปรียบเทียบเส้นทางที่สำเร็จกับเส้นทางที่ไม่สำเร็จได้.

แหล่งข้อมูล

โดยทั่วไป นี่คือสถานะสุดท้าย (pyStatusWork) ของ work object สำหรับเคสใน Pega.

ตัวอย่าง
อนุมัติแล้วปฏิเสธแล้วรอฝ่ายกำกับดูแลลูกค้าถอนใบสมัคร
เหตุผลที่ปฏิเสธ
RejectionReason
ระบุสาเหตุที่ปฏิเสธใบสมัคร.
คำอธิบาย

เมื่อสถานะสุดท้ายของใบสมัครเป็น 'ปฏิเสธ' แอตทริบิวต์นี้จะระบุสาเหตุ เช่น 'ไม่ผ่านการตรวจสอบประวัติ' 'เอกสารไม่ครบ' หรือ 'มีความเสี่ยงสูง'

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

เหตุผลที่สำคัญ

ช่วยให้เห็นสาเหตุที่ใบสมัครไม่ผ่านและนำไปปรับปรุงกระบวนการได้ตรงจุด เพื่อเพิ่มอัตราความสำเร็จ.

แหล่งข้อมูล

ข้อมูลนี้น่าจะเป็นพร็อพเพอร์ตีเฉพาะที่กำหนดให้เคสเมื่อเปลี่ยนสถานะเป็น 'ปฏิเสธ' โปรดดูเอกสาร Pega KYC เพื่อค้นหาฟิลด์เหตุผลการปฏิเสธมาตรฐาน.

ตัวอย่าง
พบชื่อในรายการคว่ำบาตรข้อมูลในเอกสารไม่ตรงกันพบว่าเป็นบุคคลที่มีสถานภาพทางการเมืองข้อมูลไม่เพียงพอ
ดำเนินการอัตโนมัติหรือไม่
IsAutomated
ตัวบ่งชี้ว่ากิจกรรมดำเนินการโดยระบบหรือบุคคล.
คำอธิบาย

แอตทริบิวต์แบบบูลีนนี้มีค่า true หากกิจกรรมดำเนินการโดยตัวแทนอัตโนมัติ เช่น ระบบคัดกรองหรือกฎของระบบ และมีค่า false หากดำเนินการโดยผู้ใช้ที่เป็นบุคคล

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานค่านี้ได้จากรหัสผู้ใช้ที่เชื่อมกับเหตุการณ์ หาก OperatorId ตรงกับบัญชีระบบหรือตัวแทนอัตโนมัติที่รู้จัก ค่านี้จะเป็น true.

ตัวอย่าง
truefalse
ประเทศของลูกค้า
CustomerCountry
ประเทศที่ลูกค้าอาศัยอยู่หรือจดทะเบียนจัดตั้ง.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ช่วยวิเคราะห์กระบวนการตามภูมิศาสตร์ ซึ่งมักเกี่ยวข้องกับความซับซ้อนของกฎระเบียบและระดับความเสี่ยง.

แหล่งข้อมูล

นี่ควรเป็นพร็อพเพอร์ตีใน data object ของลูกค้าที่เชื่อมกับเคส.

ตัวอย่าง
USADEUSGPGBR
ประเภทเคส
CaseType
ประเภทเฉพาะของเคสรับลูกค้าใหม่สำหรับ KYC.
คำอธิบาย

แอตทริบิวต์นี้จัดประเภทใบสมัครรับลูกค้าใหม่ เช่น 'ลูกค้าบุคคล' 'ลูกค้าองค์กร' หรือ 'บุคคลที่มีสินทรัพย์สูง' เคสแต่ละประเภทมักมีขั้นตอนกระบวนการ SLA และระดับความเสี่ยงแตกต่างกัน

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

เหตุผลที่สำคัญ

ช่วยแบ่งข้อมูลกระบวนการเป็นหมวดหมู่ ทำให้วิเคราะห์ประสิทธิภาพได้แม่นยำและตรงประเด็นยิ่งขึ้น.

แหล่งข้อมูล

โดยทั่วไป นี่คือชื่อคลาสของอินสแตนซ์เคสใน Pega หรือพร็อพเพอร์ตีเฉพาะในเคสที่ระบุประเภทของเคส.

ตัวอย่าง
รับลูกค้าบุคคลรับลูกค้าองค์กรการตรวจสอบสถานะแบบง่าย
ผลิตภัณฑ์ที่สมัคร
OnboardedProduct
ผลิตภัณฑ์ทางการเงินที่ลูกค้าสมัคร.
คำอธิบาย

แอตทริบิวต์นี้ระบุผลิตภัณฑ์หรือบริการที่ลูกค้าสมัคร เช่น 'บัญชีธนาคารรายย่อย' 'สินเชื่อธุรกิจ' หรือ 'บริการลงทุน'

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

เหตุผลที่สำคัญ

ช่วยแบ่งการวิเคราะห์กระบวนการตามประเภทผลิตภัณฑ์ เพื่อให้เห็นความแตกต่างด้านประสิทธิภาพและโอกาสในการปรับปรุง.

แหล่งข้อมูล

นี่ควรเป็นพร็อพเพอร์ตีในเคส ซึ่งเลือกตั้งแต่เริ่มขั้นตอนสมัคร.

ตัวอย่าง
บัญชีกระแสรายวันการบริหารความมั่งคั่งวงเงินสินเชื่อธุรกิจ
มีการทำงานซ้ำหรือไม่
IsRework
ตัวบ่งชี้ว่ากิจกรรมเป็นส่วนหนึ่งของวงจรการทำงานซ้ำหรือไม่.
คำอธิบาย

แอตทริบิวต์แบบบูลีนนี้มีค่า true หากกิจกรรม เช่น 'ตรวจสอบเอกสาร' เกิดขึ้นมากกว่าหนึ่งครั้งในเคสเดียวกัน โดยมักเกิดจากเหตุการณ์อย่าง 'ขอข้อมูลเพิ่มเติม'

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ค่านี้ได้จากการวิเคราะห์ข้อมูล โดยตรวจหาชื่อกิจกรรมที่เกิดซ้ำภายในรหัสเคสเดียวกัน เช่น พบ 'ตรวจสอบเอกสารเสร็จแล้ว' เป็นครั้งที่สอง.

ตัวอย่าง
truefalse
รหัสลูกค้า
CustomerId
รหัสเฉพาะของลูกค้าที่กำลังเข้าสู่กระบวนการรับลูกค้าใหม่.
คำอธิบาย

แอตทริบิวต์นี้เป็นรหัสเฉพาะที่เชื่อมใบสมัครกับระเบียนลูกค้าในระบบข้อมูลหลัก ใช้ระบุบุคคลหรือองค์กรที่อยู่ระหว่างกระบวนการ KYC

รหัสใบสมัครใช้ติดตามกระบวนการ ส่วนรหัสลูกค้าช่วยวิเคราะห์ใบสมัครหลายรายการของลูกค้ารายเดียวกัน หรือเพิ่มข้อมูลเฉพาะของลูกค้า เช่น กลุ่มลูกค้าหรือประวัติ ทำให้มองกระบวนการรับลูกค้าใหม่จากมุมมองของลูกค้าได้.

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

นี่ควรเป็นพร็อพเพอร์ตีหลักในเคส KYC ที่เชื่อมกับโมเดลข้อมูลลูกค้าใน Pega หรือ CRM ภายนอก.

ตัวอย่าง
CUST-98765CUST-98766CUST-98767
ระบบต้นทาง
SourceSystem
ระบุระบบที่เป็นแหล่งที่มาของข้อมูล.
คำอธิบาย

แอตทริบิวต์นี้ระบุแอปพลิเคชันต้นทางที่บันทึกเหตุการณ์ สำหรับกระบวนการนี้ ค่าจะเป็น 'Pega KYC' เสมอ

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

เหตุผลที่สำคัญ

ช่วยระบุที่มาของข้อมูล ซึ่งจำเป็นต่อการกำกับดูแลข้อมูลและการวิเคราะห์ข้อมูลจากหลายระบบต้นทาง.

แหล่งข้อมูล

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

ตัวอย่าง
Pega KYCPega CLM
ระยะเวลาดำเนินการ
CycleTime
เวลาทั้งหมดตั้งแต่ส่งใบสมัครจนถึงได้ข้อสรุปสุดท้าย.
คำอธิบาย

ตัวชี้วัดที่คำนวณได้นี้วัดระยะเวลาตั้งแต่ต้นจนจบของใบสมัครลูกค้าแต่ละรายการ ตั้งแต่เหตุการณ์แรกจนถึงเหตุการณ์สุดท้าย โดยทั่วไปคำนวณจากผลต่างระหว่างเวลาประทับของกิจกรรมสุดท้ายกับกิจกรรมแรกในเคส

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

เครื่องมือ process mining คำนวณตัวชี้วัดนี้โดยหาผลต่างระหว่างเวลาประทับที่มากที่สุดกับน้อยที่สุดของแต่ละรหัสเคส.

ตัวอย่าง
5 วัน 4 ชั่วโมง12 วัน 1 ชั่วโมง2 วัน 8 ชั่วโมง
สถานะ SLA
SlaStatus
ระบุว่าเคสดำเนินการเสร็จภายในกำหนด SLA หรือไม่.
คำอธิบาย

แอตทริบิวต์นี้จัดประเภทเคสที่เสร็จแล้วเป็น 'ตรงเวลา' หรือ 'ล่าช้า' โดยเปรียบเทียบเวลาที่ดำเนินการเสร็จจริงกับ 'วันที่เป้าหมายตาม SLA'

นี่คือตัวชี้วัดหลักของแดชบอร์ด 'ติดตามการปฏิบัติตาม SLA' และ KPI 'อัตราการปฏิบัติตาม SLA' ช่วยให้เห็นผลการดำเนินงานเทียบกับข้อตกลงการให้บริการได้อย่างชัดเจน การวิเคราะห์ลักษณะของเคสที่ล่าช้าช่วยระบุสาเหตุหลักและลดความเสี่ยงที่จะผิด SLA ในอนาคต.

เหตุผลที่สำคัญ

วัดผลการทำงานเทียบกับข้อตกลงโดยตรง ซึ่งสำคัญต่อการจัดการการปฏิบัติการ การปฏิบัติตามข้อกำหนด และความพึงพอใจของลูกค้า.

แหล่งข้อมูล

ค่านี้ได้จากการเปรียบเทียบเวลาประทับของกิจกรรมสุดท้ายในเคสกับฟิลด์ SlaTargetDate หากดำเนินการเสร็จหลังวันที่เป้าหมาย สถานะจะเป็น 'ล่าช้า'.

ตัวอย่าง
ตรงเวลาล่าช้ามีความเสี่ยง
สถานะเอกสาร
DocumentStatus
สถานะปัจจุบันของเอกสารที่ลูกค้าส่งมา.
คำอธิบาย

แอตทริบิวต์นี้ติดตามสถานะของเอกสารที่ต้องใช้ในกระบวนการ KYC เช่น 'รอเอกสารจากลูกค้า' 'ได้รับแล้ว' 'ตรวจสอบแล้ว' หรือ 'ปฏิเสธแล้ว' สถานะนี้อาจเปลี่ยนหลายครั้งในเคสเดียว

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

เหตุผลที่สำคัญ

ช่วยให้เห็นขั้นตอนย่อยในการจัดการเอกสาร และระบุพร้อมแก้ไขความล่าช้าที่พบบ่อยในการตรวจสอบเอกสาร.

แหล่งข้อมูล

ข้อมูลนี้น่าจะเป็นพร็อพเพอร์ตีใน data object หรือ page list ที่เชื่อมกับเคสหลัก ซึ่งใช้ติดตามเอกสารที่ต้องใช้แต่ละรายการ โปรดดูเอกสาร Pega KYC.

ตัวอย่าง
รออัปโหลดได้รับแล้ว รอตรวจสอบอนุมัติแล้วปฏิเสธแล้ว ต้องการข้อมูลเพิ่มเติม
อัปเดตข้อมูลล่าสุด
LastDataUpdate
เวลาที่รีเฟรชหรือดึงข้อมูลครั้งล่าสุด.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ช่วยให้ผู้ใช้ทราบความใหม่ของข้อมูล และเข้าใจว่าผลวิเคราะห์สะท้อนสถานการณ์ปัจจุบันหรือช่วงเวลาก่อนหน้า.

แหล่งข้อมูล

ค่านี้สร้างและบันทึกลงในชุดข้อมูลระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL).

ตัวอย่าง
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
จำเป็น แนะนำ ไม่บังคับ

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

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

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

แหล่งข้อมูล

บันทึกไว้อย่างชัดเจนในตารางไฟล์แนบของ Pega (pc_link_attachment หรือ pc_data_workattach) เมื่อมีการเชื่อมโยงเอกสารใหม่กับกรณี.

บันทึก

เวลาของเหตุการณ์คือเวลาที่สร้างออบเจ็กต์ไฟล์แนบที่เกี่ยวข้องและเชื่อมโยงกับกรณี.

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

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะกรณี (pyStatusWork) จาก 'Pending-Compliance' เป็นสถานะอย่าง 'Pending-Final-Decision' หรือ 'Resolved-Approved'.

บันทึก

ระบุเวลาที่ขั้นตอนตรวจสอบหรือการมอบหมายงานด้านการปฏิบัติตามข้อกำหนดเสร็จสิ้นในประวัติกรณี.

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

นี่คือเหตุการณ์สิ้นสุดหลักที่แสดงว่ากระบวนการไม่สำเร็จ มีความสำคัญต่อการวิเคราะห์อัตราการปฏิเสธคำขอและทำความเข้าใจสาเหตุ เช่น จากแอตทริบิวต์ 'Rejection Reason'.

แหล่งข้อมูล

อนุมานจากเวลาที่ตั้งสถานะผลการดำเนินการของกรณี (pyStatusWork) เป็นค่าความล้มเหลวขั้นสุดท้าย เช่น 'Resolved-Rejected'.

บันทึก

ระบุการอัปเดต pyStatusWork ครั้งสุดท้ายในประวัติการตรวจสอบของเคสที่แสดงสถานะปฏิเสธ.

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

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

แหล่งข้อมูล

อนุมานจากการเสร็จสิ้นของระยะหรือ flow ที่กำหนดในแบบจำลองกรณีของ Pega ซึ่งทำให้สถานะที่บันทึกไว้ในประวัติการตรวจสอบเปลี่ยนแปลง.

บันทึก

อนุมานจากการเปลี่ยน pyStatusWork หลังขั้นตอนประเมินความเสี่ยง เช่น เปลี่ยนเป็น 'Pending-Compliance-Review'.

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

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

แหล่งข้อมูล

อนุมานจากเวลาที่ตั้งสถานะผลการดำเนินการของกรณี (pyStatusWork) เป็นค่าสำเร็จขั้นสุดท้าย เช่น 'Resolved-Completed'.

บันทึก

ระบุเวลาของสถานะ 'Resolved-Completed' ครั้งสุดท้ายในตาราง History-Work.

ประเภทเหตุการณ์ inferred
เริ่มตรวจสอบการปฏิบัติตามข้อกำหนดแล้ว
กิจกรรมนี้บันทึกการเริ่มตรวจสอบอย่างเป็นทางการโดยทีมกำกับการปฏิบัติตามข้อกำหนด ซึ่งเป็นขั้นตอนสำคัญและมักใช้เวลานาน ตรวจจับได้เมื่อมีการมอบหมายกรณีไปยังคิวงานของทีม หรือเมื่อสถานะได้รับการอัปเดตตามนั้น.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะกรณี (pyStatusWork) เป็น 'Pending-Compliance' หรือจากเหตุการณ์สร้างงานมอบหมายใน workbasket ของทีมกำกับการปฏิบัติตามข้อกำหนด.

บันทึก

ระบุเวลาที่มอบหมายกรณีไปยัง workbasket ของทีมกำกับการปฏิบัติตามข้อกำหนด หรือเวลาที่สถานะเปลี่ยนเพื่อแสดงว่าเริ่มตรวจสอบแล้ว.

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

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

แหล่งข้อมูล

เหตุการณ์นี้บันทึกไว้อย่างชัดเจนในประวัติการตรวจสอบของ Pega เมื่อสร้าง work object (case) ใหม่ ให้ค้นหารายการแรกในตาราง pc_history_work ของรหัสกรณีนั้น.

บันทึก

ดึงข้อมูลจากเวลาที่สร้างกรณีในตาราง pc_work หรือรายการแรกในประวัติการตรวจสอบ.

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

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

แหล่งข้อมูล

อนุมานจากเวลาที่ตั้งสถานะผลการดำเนินการของกรณี (pyStatusWork) เป็นค่าสำเร็จขั้นสุดท้าย เช่น 'Resolved-Completed' หรือ 'Resolved-Approved'.

บันทึก

ระบุการอัปเดต pyStatusWork ครั้งสุดท้ายที่แสดงว่ากรณีเสร็จสิ้นโดยสำเร็จในประวัติการตรวจสอบของกรณี.

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

กิจกรรมนี้เป็นตัวบ่งชี้หลักของการแก้ไขงานและลูปในกระบวนการ การติดตามความถี่เป็นสิ่งสำคัญต่อการวัดอัตราการดำเนินการให้เสร็จตั้งแต่ครั้งแรกและค้นหาข้อกำหนดที่ไม่ชัดเจน.

แหล่งข้อมูล

อาจเป็นเหตุการณ์ 'Send Correspondence' ที่บันทึกไว้อย่างชัดเจนในประวัติการตรวจสอบ หรืออนุมานจากการเปลี่ยนสถานะเป็น 'Pending-Customer-Info'.

บันทึก

บันทึกจากการสร้างออบเจ็กต์ข้อความติดต่อเฉพาะรายการ หรือ flow action ที่เจ้าหน้าที่ดูแลกรณีเริ่มดำเนินการ.

ประเภทเหตุการณ์ explicit
ขอเอกสารแล้ว
กิจกรรมนี้เกิดขึ้นเมื่อระบบหรือเจ้าหน้าที่พิจารณาแล้วว่าต้องขอเอกสารบางรายการจากลูกค้าจึงจะดำเนินการต่อได้ ตรวจจับได้จากการสร้างรายการติดต่อสื่อสาร หรือการเปลี่ยนสถานะกรณีเป็นสถานะอย่าง 'Pending-Customer-Docs'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อาจเป็นเหตุการณ์ติดต่อสื่อสารที่บันทึกไว้อย่างชัดเจน (pc_link_attachment) หรืออนุมานจากการเปลี่ยนสถานะกรณี (pyStatusWork) ที่บันทึกไว้ในประวัติการตรวจสอบ.

บันทึก

อนุมานได้จากการเปลี่ยน pyStatusWork เป็น 'Pending-Documents' หรือสถานะที่มีความหมายใกล้เคียง และอาจเชื่อมโยงกับเหตุการณ์ 'Send Correspondence' ที่บันทึกไว้อย่างชัดเจนได้.

ประเภทเหตุการณ์ inferred
ตรวจทานเอกสารเสร็จแล้ว
กิจกรรมนี้หมายถึงเจ้าหน้าที่ด้านการปฏิบัติตามข้อกำหนดหรือกระบวนการอัตโนมัติตรวจทานเอกสารที่ลูกค้าส่งมาเสร็จแล้ว อนุมานเหตุการณ์นี้ได้จากการเปลี่ยนสถานะกรณีหรือเอกสาร ซึ่งแสดงว่าการตรวจทานเสร็จสิ้น.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะกรณี (pyStatusWork) จาก 'Pending-Review' เป็น 'Review-Complete' หรือ 'Pending-Checks' ในประวัติการตรวจสอบ.

บันทึก

ระบุเวลาที่สถานะกรณี (pyStatusWork) เปลี่ยน ซึ่งแสดงว่าขั้นตอนย่อยการตรวจสอบเอกสารเสร็จสิ้นแล้ว.

ประเภทเหตุการณ์ inferred
ตรวจสอบเบื้องต้นแล้ว
หมายถึงการตรวจสอบข้อมูลคำขอเบื้องต้น ซึ่งมักดำเนินการโดยอัตโนมัติ เพื่อดูว่าข้อมูลครบถ้วนและมีคุณสมบัติเบื้องต้นหรือไม่ โดยทั่วไปอนุมานเหตุการณ์นี้ได้จากการเปลี่ยนสถานะกรณี เช่น จาก 'New' เป็น 'Pending-Documents'.
เหตุผลที่สำคัญ

การวิเคราะห์เวลาที่ใช้ในขั้นตอนแรกนี้ช่วยค้นหาคอขวดตั้งแต่ต้นในกระบวนการตรวจสอบข้อมูลหรือการทำงานของกฎอัตโนมัติ ซึ่งอาจทำให้กระบวนการทั้งหมดล่าช้า.

แหล่งข้อมูล

อนุมานจากการเปลี่ยนแปลงคุณสมบัติสถานะกรณี (pyStatusWork) ที่บันทึกไว้ในประวัติการตรวจสอบของ Pega (ตาราง History-Work).

บันทึก

ระบุเวลาที่ pyStatusWork เปลี่ยนจากสถานะ 'New' หรือ 'Submitted' เป็น 'ScreeningComplete' หรือสถานะที่มีความหมายใกล้เคียง.

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

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

แหล่งข้อมูล

อนุมานจากสถานะกรณีเฉพาะ (pyStatusWork) เช่น 'Resolved-AccountActive' หรือจากแฟล็กที่ตั้งไว้ในกรณีผ่านการเชื่อมต่อระบบ ซึ่งบันทึกไว้ในประวัติการตรวจสอบ.

บันทึก

ระบุเวลาที่อัปเดตคุณสมบัติของกรณีเพื่อแสดงว่าบัญชีในระบบปลายทางเปิดใช้งานแล้ว.

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

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะกรณี (pyStatusWork) เป็น 'Pending-Background-Check' หรือสถานะที่มีความหมายใกล้เคียง ซึ่งบันทึกไว้ในตาราง History-Work ของ Pega.

บันทึก

ระบุเวลาที่ pyStatusWork ได้รับการอัปเดตเพื่อแสดงว่าเริ่มกระบวนการตรวจสอบประวัติแล้ว.

ประเภทเหตุการณ์ inferred
แนะนำ ไม่บังคับ

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

วิธีดึงข้อมูลจาก Pega KYC

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

เทมเพลตข้อมูลนี้ช่วยให้คุณมีพื้นฐานพร้อมเริ่มปรับปรุงกระบวนการรับลูกค้า KYC ค้นหาจุดที่ทำงานไม่มีประสิทธิภาพและยกระดับการปฏิบัติตามข้อกำหนดได้ตั้งแต่วันนี้!

ปรับกระบวนการรับลูกค้า KYC ให้คล่องตัว ลดความล่าช้า

ทำให้การรับลูกค้า KYC ราบรื่นขึ้น ลดเวลาเริ่มต้นใช้งานเหลือ 24 ชั่วโมง และยกระดับการปฏิบัติตามข้อกำหนด.

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

ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จได้ในไม่กี่นาที