> Cải tiến quy trình liên tục > Tiếp nhận khách hàng KYC > Pega KYC > Mẫu dữ liệu

Mẫu dữ liệu quy trình tiếp nhận khách hàng KYC

Pega KYC

Thuộc tính quy trình tiếp nhận khách hàng KYC(21) Hoạt động trong quy trình tiếp nhận khách hàng KYC(14) Hướng dẫn trích xuất dữ liệu(2)

Mẫu dữ liệu quy trình tiếp nhận khách hàng KYC

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để phân tích quy trình tiếp nhận khách hàng KYC. Mẫu nêu rõ các thuộc tính quan trọng cần lấy và những hoạt động chính cần theo dõi trong nhật ký sự kiện. Bạn cũng sẽ tìm thấy hướng dẫn thực tế để trích xuất dữ liệu hiệu quả, giúp bạn bắt đầu process mining thuận lợi.

Các thuộc tính nên có trong nhật ký sự kiện
Các hoạt động chính cần theo dõi trong quy trình
Hướng dẫn thực tế về trích xuất dữ liệu

Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Tải mẫu xuống

Thuộc tính quy trình tiếp nhận khách hàng KYC

Đây là những trường dữ liệu nên có trong nhật ký sự kiện, cung cấp thông tin cần thiết để phân tích quy trình tiếp nhận khách hàng KYC.

3 Bắt buộc 7 Nên có 11 Không bắt buộc

	Tên	Mô tả
	Đơn đăng ký của khách hàng CustomerApplication	Mã định danh duy nhất của từng hồ sơ tiếp nhận khách hàng.
Mô tả Đơn đăng ký của khách hàng là mã hồ sơ chính, dùng để nhóm mọi hoạt động và sự kiện liên quan trong quá trình tiếp nhận một khách hàng. Mỗi đơn đi từ lúc nộp đến khi được phê duyệt và kích hoạt tài khoản, hoặc bị từ chối. Trong process mining, thuộc tính này giúp dựng lại toàn bộ hành trình của từng đơn đăng ký. Chuyên viên phân tích có thể xem chuỗi sự kiện đầy đủ, theo dõi trạng thái từng đơn và so sánh các luồng xử lý. Phân tích theo mã này giúp tìm ra các biến thể quy trình phổ biến, điểm nghẽn và những bước lệch khỏi quy trình chuẩn. Vì sao điều này quan trọng Mã này là nền tảng cho process mining, vì nó liên kết từng sự kiện thành các trường hợp quy trình xuyên suốt, mạch lạc để phân tích. Lấy dữ liệu ở đâu Trong Pega, đây thường là mã hồ sơ chính, có thể truy xuất dưới dạng pzInsKey hoặc một tên tương đương dễ hiểu với nghiệp vụ trong đối tượng công việc của loại hồ sơ chính. Ví dụ APP-2023-00123APP-2023-00124APP-2023-00125
	Hoạt động ActivityName	Tên sự kiện hoặc tác vụ cụ thể diễn ra trong quy trình tiếp nhận khách hàng.
Mô tả Thuộc tính này ghi lại tên hoạt động nghiệp vụ hoặc sự kiện hệ thống, chẳng hạn như 'Đã nộp đơn đăng ký', 'Đã bắt đầu rà soát tuân thủ' hoặc 'Đã từ chối đơn đăng ký'. Mỗi giá trị thể hiện một bước trong toàn bộ quy trình tiếp nhận khách hàng. Phân tích hoạt động là trọng tâm của process mining. Thuộc tính này được dùng để dựng sơ đồ quy trình, thể hiện luồng giữa các bước. Nhờ đó, bạn có thể xác định thứ tự sự kiện, đo tần suất của từng hoạt động và tìm ra tác vụ phổ biến hoặc tốn nhiều thời gian nhất. Vì sao điều này quan trọng Thuộc tính này xác định các bước trên sơ đồ quy trình, giúp bạn trực quan hóa, phân tích và hiểu luồng quy trình. Lấy dữ liệu ở đâu Thông tin này thường được ghi trong lịch sử kiểm tra của Pega (các bảng lịch sử) hoặc có thể suy ra từ những lần thay đổi trạng thái của hồ sơ. Ví dụ Đã hoàn tất sàng lọc ban đầuĐã hoàn tất rà soát tuân thủĐã phê duyệt hồ sơ
	Thời gian bắt đầu EventTime	Dấu thời gian cho biết thời điểm một hoạt động hoặc sự kiện bắt đầu.
Mô tả Thuộc tính này ghi lại chính xác ngày giờ một hoạt động bắt đầu. Nó xác định thứ tự thời gian của mọi sự kiện trong một hồ sơ đăng ký của khách hàng. Dấu thời gian là dữ liệu nền tảng để phân tích hiệu suất quy trình. Bạn có thể dùng chúng để tính thời lượng hoạt động, thời gian chờ giữa các bước và tổng thời gian xử lý từ đầu đến cuối. Dữ liệu này rất cần thiết để tìm điểm nghẽn, đo mức độ đáp ứng SLA và hiểu hiệu quả quy trình. Vì sao điều này quan trọng Dấu thời gian cung cấp thứ tự thời gian cần thiết để tính thời lượng, phân tích hiệu suất quy trình và xác định chậm trễ. Lấy dữ liệu ở đâu Đây là thông tin tiêu chuẩn trong lịch sử kiểm tra của Pega, thường được lưu dưới dạng pxTimeCreated trong bảng lịch sử của từng sự kiện. Ví dụ 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
	Lý do từ chối RejectionReason	Cho biết lý do đơn đăng ký bị từ chối.
Mô tả Khi trạng thái cuối cùng của đơn đăng ký là 'Đã từ chối', thuộc tính này nêu rõ lý do, chẳng hạn như 'Không đạt kiểm tra lý lịch', 'Thiếu giấy tờ' hoặc 'Hồ sơ rủi ro cao'. Thuộc tính này là cơ sở chính cho dashboard 'Phân tích đơn đăng ký bị từ chối'. Khi phân nhóm hồ sơ bị từ chối theo lý do, doanh nghiệp có thể xác định những điểm thường khiến quy trình tiếp nhận khách hàng thất bại. Thông tin này giúp cải tiến đúng trọng tâm để giảm tỷ lệ từ chối, nâng cao trải nghiệm khách hàng và tăng hiệu quả vận hành. Vì sao điều này quan trọng Cho biết nguyên nhân đơn đăng ký không thành công, giúp bạn cải tiến quy trình đúng trọng tâm và tăng tỷ lệ thành công. Lấy dữ liệu ở đâu Đây có thể là một thuộc tính cụ thể được thiết lập trên hồ sơ khi trạng thái chuyển thành 'Đã từ chối'. Hãy tham khảo tài liệu Pega KYC để biết các trường lý do từ chối tiêu chuẩn. Ví dụ Phát hiện trùng danh sách trừng phạtThông tin trên giấy tờ không khớpXác định người có ảnh hưởng chính trị (PEP)Thiếu thông tin
	Mức độ rủi ro RiskLevel	Mức độ rủi ro được tính cho đơn đăng ký của khách hàng.
Mô tả Thuộc tính này thể hiện mức độ rủi ro đã đánh giá của khách hàng, thường được phân loại là 'Thấp', 'Trung bình' hoặc 'Cao'. Mức độ rủi ro thường do công cụ tính điểm tự động xác định dựa trên dữ liệu khách hàng và kết quả sàng lọc. Mức độ rủi ro ảnh hưởng lớn đến biến thể quy trình. Đơn đăng ký có rủi ro cao thường cần thêm các bước thẩm định, chẳng hạn như rà soát tuân thủ nâng cao, nên thời gian xử lý dài hơn. Phân tích quy trình theo mức độ rủi ro giúp lý giải những khác biệt này và đảm bảo các biện pháp kiểm soát rủi ro hoạt động hiệu quả mà không gây chậm trễ không cần thiết. Vì sao điều này quan trọng Giải thích sự khác nhau về luồng và thời lượng quy trình, vì mức độ rủi ro thường quyết định mức thẩm định cần thiết. Lấy dữ liệu ở đâu Đây có thể là thuộc tính được tính trên hồ sơ và điền bằng quy tắc quyết định hoặc mô hình chấm điểm của Pega. Hãy tham khảo tài liệu Pega KYC. Ví dụ ThấpTrung bìnhCao
	Ngày mục tiêu SLA SlaTargetDate	Ngày dự kiến hoàn tất hồ sơ tiếp nhận khách hàng.
Mô tả Thuộc tính này lưu ngày mục tiêu hoàn tất đơn đăng ký theo thỏa thuận mức dịch vụ (SLA). SLA có thể thay đổi tùy theo loại khách hàng, mức độ rủi ro hoặc sản phẩm. Ngày này rất cần thiết cho dashboard 'Theo dõi mức độ đáp ứng SLA' và KPI liên quan. Đây là mốc để so sánh với ngày hoàn tất thực tế. Phân tích các hồ sơ không đạt mục tiêu SLA giúp tìm ra chậm trễ mang tính hệ thống và ưu tiên cải tiến quy trình để đáp ứng cam kết dịch vụ. Vì sao điều này quan trọng Đây là mốc để đo lường việc hoàn tất đúng hạn, yếu tố quan trọng đối với sự hài lòng của khách hàng và khả năng kiểm soát vận hành. Lấy dữ liệu ở đâu Pega có sẵn khung quản lý SLA. Ngày này thường được lưu trong các thuộc tính như pySLAGoal hoặc một thuộc tính SLA tùy chỉnh trên hồ sơ. Ví dụ 2023-11-10T17:00:00Z2023-11-15T17:00:00Z
	Người dùng OperatorId	Mã định danh duy nhất của người dùng thực hiện hoạt động.
Mô tả Thuộc tính này lưu mã nhân viên hoặc người dùng hệ thống chịu trách nhiệm hoàn thành một tác vụ cụ thể trong quy trình KYC, chẳng hạn như nhân viên tuân thủ hoặc bot sàng lọc tự động. Với các bước tự động, đây có thể là mã tài khoản hệ thống hoặc tài khoản dịch vụ. Phân tích theo người dùng giúp bạn hiểu cách phân bổ khối lượng công việc, hiệu suất cá nhân và nhu cầu đào tạo. Bạn cũng có thể xác định người dùng hoặc nhóm tham gia vào các luồng xử lý không theo chuẩn để tìm hiểu nguyên nhân sai lệch. Vì sao điều này quan trọng Thuộc tính này liên kết hoạt động trong quy trình với từng cá nhân hoặc nhóm, hỗ trợ phân tích khối lượng công việc, đánh giá hiệu suất và kiểm tra tuân thủ. Lấy dữ liệu ở đâu Đây là trường tiêu chuẩn trong lịch sử kiểm tra của Pega, thường được lưu dưới dạng pxUpdateOperator hoặc một thuộc tính tương tự trong bảng lịch sử. Ví dụ j.doe@acmebank.comkyc_analyst_04system_auto_agent
	Phòng ban WorkGroup	Phòng ban hoặc nhóm chức năng chịu trách nhiệm thực hiện hoạt động.
Mô tả Thuộc tính này xác định đơn vị hoặc nhóm mà người thực hiện thuộc về, chẳng hạn như 'Nhóm sàng lọc', 'Bộ phận tuân thủ' hoặc 'Nhóm vận hành tiếp nhận khách hàng'. Phân tích quy trình theo phòng ban rất quan trọng đối với dashboard 'Phân bổ khối lượng công việc theo phòng ban'. Qua đó, quản lý có thể hiểu công việc luân chuyển giữa các nhóm ra sao, tìm điểm nghẽn giữa các bộ phận và đánh giá cách phân bổ tài nguyên trong toàn bộ quy trình tiếp nhận khách hàng. Đây cũng là cơ sở để cải thiện việc bàn giao và cân bằng khối lượng công việc. Vì sao điều này quan trọng Giúp phân tích luồng quy trình và điểm nghẽn giữa các đơn vị, hỗ trợ quản lý tài nguyên và cải thiện cách tổ chức công việc. Lấy dữ liệu ở đâu Thông tin này thường gắn với hồ sơ người dùng trong Pega (bản ghi Operator ID) và có thể kết hợp với dữ liệu sự kiện. Thuộc tính có thể là pyWorkGroup. Ví dụ Sàng lọc ban đầuRà soát tuân thủKích hoạt tài khoản
	Thời gian kết thúc EndTime	Dấu thời gian cho biết thời điểm một hoạt động hoặc sự kiện hoàn tất.
Mô tả Thuộc tính này ghi lại chính xác ngày giờ một hoạt động kết thúc. Kết hợp với Thời gian bắt đầu, thuộc tính giúp tính thời gian xử lý của từng hoạt động. Có Thời gian kết thúc riêng giúp phân tích hiệu suất chính xác hơn. Bạn có thể phân biệt thời gian xử lý thực tế, tính từ Thời gian bắt đầu đến Thời gian kết thúc, với thời gian chờ, tính từ lúc một hoạt động kết thúc đến khi hoạt động tiếp theo bắt đầu. Điều này rất cần thiết để xác định đúng điểm nghẽn và phân biệt chúng với thời gian chờ trong hàng đợi. Vì sao điều này quan trọng Giúp tính chính xác thời gian xử lý hoạt động, yếu tố cần thiết để phân tích hiệu suất chi tiết và xác định điểm nghẽn. Lấy dữ liệu ở đâu Thông tin này có thể có trong lịch sử kiểm tra của Pega. Nếu không, có thể lấy Thời gian bắt đầu của sự kiện tiếp theo làm Thời gian kết thúc của sự kiện hiện tại. Ví dụ 2023-10-26T10:15:00Z2023-10-26T18:05:20Z2023-10-27T11:00:00Z
	Trạng thái đơn đăng ký ApplicationStatus	Kết quả cuối cùng hoặc trạng thái hiện tại của đơn đăng ký của khách hàng.
Mô tả Thuộc tính này cho biết trạng thái tổng thể của đơn đăng ký khi quy trình kết thúc, chẳng hạn như 'Đã phê duyệt', 'Đã từ chối' hoặc 'Đã rút'. Với hồ sơ đang xử lý, thuộc tính cũng có thể phản ánh trạng thái gần nhất. Đây là chiều phân tích quan trọng để đánh giá kết quả. Dashboard 'Phân tích đơn đăng ký bị từ chối' dùng thuộc tính này để phân nhóm hồ sơ và tìm hiểu nguyên nhân dẫn đến từng kết quả. Phân tích luồng quy trình theo trạng thái giúp xác định cách xử lý hiệu quả ở các hồ sơ được phê duyệt và nguyên nhân gốc rễ khiến hồ sơ bị từ chối. Vì sao điều này quan trọng Thuộc tính này xác định kết quả nghiệp vụ của hồ sơ, giúp so sánh hiệu quả giữa các luồng xử lý thành công và không thành công. Lấy dữ liệu ở đâu Trong Pega, đây thường là trạng thái cuối cùng (pyStatusWork) của đối tượng công việc trong hồ sơ. Ví dụ Đã phê duyệtĐã từ chốiĐang chờ bộ phận tuân thủKhách hàng đã rút đơn
	Có làm lại IsRework	Cờ cho biết hoạt động có thuộc một vòng lặp làm lại hay không.
Mô tả Thuộc tính dạng đúng/sai này có giá trị đúng nếu một hoạt động cụ thể, chẳng hạn như 'Rà soát giấy tờ', diễn ra nhiều hơn một lần trong cùng hồ sơ. Tình trạng này thường xuất hiện sau sự kiện như 'Yêu cầu bổ sung thông tin'. Xác định các bước làm lại là việc cần thiết để tìm ra điểm kém hiệu quả trong quy trình và những trở ngại khách hàng gặp phải. Dashboard 'Làm lại và vòng lặp trong quy trình' dùng thuộc tính này để đo tần suất và tác động của việc làm lại. Giảm số lần làm lại thường là mục tiêu quan trọng vì giúp xử lý nhanh hơn, giảm chi phí vận hành và cải thiện trải nghiệm khách hàng. Vì sao điều này quan trọng Làm rõ những điểm kém hiệu quả, tác vụ trùng lặp và vòng lặp trong quy trình, vốn là những mục tiêu chính của cải tiến quy trình. Lấy dữ liệu ở đâu Cờ này được xác định trong quá trình phân tích dữ liệu bằng cách kiểm tra tên hoạt động có lặp lại trong cùng một mã hồ sơ hay không. Ví dụ: 'Đã hoàn tất rà soát giấy tờ' xuất hiện lần thứ hai. Ví dụ truefalse
	Có tự động hóa IsAutomated	Cờ cho biết hoạt động do hệ thống hay con người thực hiện.
Mô tả Thuộc tính dạng đúng/sai này có giá trị đúng nếu hoạt động do tác nhân tự động thực hiện, chẳng hạn như công cụ sàng lọc hoặc quy tắc hệ thống; giá trị sai nếu hoạt động do người dùng thực hiện. Phân biệt hoạt động tự động với hoạt động thủ công rất quan trọng khi phân tích tự động hóa. Việc này giúp đo lường hiệu quả của tự động hóa hiện có, xác định tác vụ thủ công phù hợp để tự động hóa trong tương lai và hiểu cách con người tương tác với hệ thống trong quy trình. Vì sao điều này quan trọng Giúp phân biệt hoạt động do con người thực hiện với hoạt động do hệ thống xử lý, đây là cơ sở cho mọi sáng kiến hoặc phân tích về tự động hóa. Lấy dữ liệu ở đâu Có thể suy ra thuộc tính này từ mã người dùng gắn với sự kiện. Nếu OperatorId khớp với tài khoản hệ thống hoặc tài khoản tác nhân đã biết, cờ này được đặt thành đúng. Ví dụ truefalse
	Hệ thống nguồn SourceSystem	Cho biết dữ liệu bắt nguồn từ hệ thống nào.
Mô tả Thuộc tính này xác định ứng dụng nguồn ghi nhận sự kiện. Với quy trình này, giá trị thường là 'Pega KYC'. Nếu toàn bộ dữ liệu đến từ một hệ thống, thuộc tính này có thể có vẻ dư thừa. Tuy nhiên, nó rất quan trọng đối với quản trị dữ liệu và càng cần thiết khi tích hợp dữ liệu từ nhiều hệ thống. Thuộc tính giúp xác định nguồn gốc dữ liệu rõ ràng và hỗ trợ xử lý sự cố tích hợp. Vì sao điều này quan trọng Thuộc tính này cung cấp thông tin cần thiết về nguồn gốc dữ liệu, hỗ trợ quản trị dữ liệu và phân tích trên nhiều hệ thống nguồn. Lấy dữ liệu ở đâu Đây thường là giá trị cố định được thêm vào trong quá trình trích xuất và chuyển đổi dữ liệu để ghi rõ nguồn gốc của tập dữ liệu. Ví dụ Pega KYCPega CLM
	Lần cập nhật dữ liệu gần nhất LastDataUpdate	Dấu thời gian của lần làm mới hoặc trích xuất dữ liệu gần nhất.
Mô tả Thuộc tính này cho biết thời điểm gần nhất dữ liệu được trích xuất từ hệ thống nguồn. Giá trị thường giống nhau ở mọi bản ghi trong cùng một lần tải dữ liệu. Dấu thời gian này giúp bạn biết dữ liệu đang phân tích mới đến mức nào, phân tích quy trình phản ánh tình hình hiện tại hay không và khi nào dự kiến có bản cập nhật tiếp theo. Đây là thông tin quan trọng để theo dõi vận hành trên dashboard. Vì sao điều này quan trọng Cho người dùng biết dữ liệu được cập nhật đến thời điểm nào, để họ hiểu phân tích phản ánh tình hình hiện tại hay một giai đoạn trước đó. Lấy dữ liệu ở đâu Giá trị này được tạo và ghi vào tập dữ liệu trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL). Ví dụ 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Loại hồ sơ CaseType	Loại hồ sơ tiếp nhận khách hàng KYC cụ thể.
Mô tả Thuộc tính này phân loại đơn đăng ký tiếp nhận khách hàng, chẳng hạn như 'Khách hàng cá nhân', 'Khách hàng doanh nghiệp' hoặc 'Khách hàng có tài sản ròng cao'. Mỗi loại hồ sơ thường có biến thể quy trình riêng, với các bước, SLA và mức độ rủi ro khác nhau. Phân tích quy trình theo Loại hồ sơ giúp so sánh hiệu suất có ý nghĩa hơn. Bạn có thể tìm hiểu liệu một số loại hồ sơ có thường bị chậm trễ hoặc từ chối hơn không. Việc phân nhóm này rất cần thiết để điều chỉnh cải tiến quy trình theo nhu cầu cụ thể của từng hành trình khách hàng. Vì sao điều này quan trọng Cho phép phân nhóm dữ liệu quy trình theo từng loại, giúp phân tích hiệu suất chính xác và phù hợp hơn. Lấy dữ liệu ở đâu Trong Pega, đây thường là tên lớp của phiên bản hồ sơ hoặc một thuộc tính riêng trên hồ sơ dùng để xác định loại. Ví dụ Tiếp nhận khách hàng cá nhânTiếp nhận khách hàng doanh nghiệpThẩm định rút gọn
	Mã khách hàng CustomerId	Mã định danh duy nhất của khách hàng đang được tiếp nhận.
Mô tả Thuộc tính này là mã duy nhất liên kết đơn đăng ký với hồ sơ khách hàng trong hệ thống dữ liệu chủ. Mã đại diện cho cá nhân hoặc tổ chức là đối tượng của quy trình KYC. Mã đơn đăng ký theo dõi quy trình, còn Mã khách hàng cho phép phân tích nhiều đơn của cùng một khách hàng hoặc bổ sung dữ liệu quy trình bằng các thuộc tính riêng của khách hàng, chẳng hạn như phân khúc hoặc lịch sử. Nhờ đó, bạn có thể xem quy trình tiếp nhận khách hàng từ góc độ khách hàng. Vì sao điều này quan trọng Liên kết dữ liệu quy trình với dữ liệu khách hàng chủ, giúp phân tích sâu hơn dựa trên thuộc tính và lịch sử khách hàng. Lấy dữ liệu ở đâu Đây có thể là thuộc tính cốt lõi trên hồ sơ KYC, liên kết hồ sơ với mô hình dữ liệu khách hàng trong Pega hoặc một CRM bên ngoài. Ví dụ CUST-98765CUST-98766CUST-98767
	Quốc gia của khách hàng CustomerCountry	Quốc gia nơi khách hàng cư trú hoặc đăng ký thành lập.
Mô tả Thuộc tính này lưu quốc gia của khách hàng đang được tiếp nhận. Đây là dữ liệu đầu vào quan trọng để đánh giá rủi ro và xác định mức thẩm định cần thiết. Phân tích theo quốc gia của khách hàng có thể cho thấy những xu hướng đáng chú ý. Một số khu vực pháp lý có thể gắn với mức rủi ro cao hơn, khiến quy trình tiếp nhận kéo dài và phức tạp hơn. Chiều phân tích này cho phép đánh giá hiệu suất theo địa lý và giúp đảm bảo các yêu cầu tuân thủ theo khu vực được đáp ứng hiệu quả. Vì sao điều này quan trọng Cho phép phân tích quy trình theo khu vực địa lý, yếu tố thường liên quan đến độ phức tạp của quy định và mức độ rủi ro. Lấy dữ liệu ở đâu Đây có thể là thuộc tính trong đối tượng dữ liệu khách hàng gắn với hồ sơ. Ví dụ USADEUSGPGBR
	Sản phẩm đăng ký OnboardedProduct	Sản phẩm tài chính mà khách hàng đăng ký.
Mô tả Thuộc tính này xác định sản phẩm hoặc dịch vụ khách hàng đăng ký, chẳng hạn như 'Tài khoản ngân hàng cá nhân', 'Khoản vay doanh nghiệp' hoặc 'Dịch vụ đầu tư'. Sản phẩm có thể ảnh hưởng đến quy trình tiếp nhận khách hàng vì mỗi sản phẩm có thể có yêu cầu pháp lý và mức độ phức tạp khác nhau. Phân tích quy trình theo sản phẩm giúp xác định dòng sản phẩm nào có thời gian xử lý dài hơn hoặc tỷ lệ từ chối cao hơn, từ đó tìm ra cơ hội tối ưu hóa quy trình cho từng sản phẩm. Vì sao điều này quan trọng Cho phép phân nhóm phân tích quy trình theo dòng sản phẩm, qua đó cho thấy khác biệt về hiệu suất và cơ hội tối ưu hóa. Lấy dữ liệu ở đâu Đây có thể là thuộc tính trên hồ sơ, được chọn khi bắt đầu quy trình đăng ký. Ví dụ Tài khoản thanh toánQuản lý tài sảnHạn mức tín dụng doanh nghiệp
	Thời gian xử lý toàn trình CycleTime	Tổng thời gian từ lúc nộp đơn đăng ký đến khi có kết quả cuối cùng.
Mô tả Chỉ số được tính này đo thời lượng xử lý từ đầu đến cuối của từng đơn đăng ký, từ sự kiện đầu tiên đến sự kiện cuối cùng. Thông thường, chỉ số được tính bằng cách lấy dấu thời gian của hoạt động cuối cùng trừ dấu thời gian của hoạt động đầu tiên trong một hồ sơ. Thời gian xử lý toàn trình là KPI chính để đánh giá hiệu quả quy trình và trải nghiệm khách hàng. Dashboard 'Phân tích tổng thời gian tiếp nhận khách hàng' dùng chỉ số này để theo dõi thời gian xử lý trung bình, xác định hồ sơ kéo dài và đo tác động của các sáng kiến cải tiến quy trình theo thời gian. Vì sao điều này quan trọng Đây là KPI quan trọng, đo trực tiếp tốc độ và hiệu quả tổng thể của quy trình tiếp nhận khách hàng từ góc nhìn của khách hàng. Lấy dữ liệu ở đâu Công cụ process mining tính chỉ số này bằng cách lấy dấu thời gian lớn nhất trừ dấu thời gian nhỏ nhất của từng mã hồ sơ. Ví dụ 5 ngày 4 giờ12 ngày 1 giờ2 ngày 8 giờ
	Trạng thái giấy tờ DocumentStatus	Trạng thái hiện tại của giấy tờ do khách hàng cung cấp.
Mô tả Thuộc tính này theo dõi trạng thái giấy tờ cần thiết cho quy trình KYC, chẳng hạn như 'Chờ khách hàng cung cấp', 'Đã nhận', 'Đã xác minh' hoặc 'Bị từ chối'. Trạng thái có thể thay đổi nhiều lần trong một hồ sơ. Đây là thuộc tính quan trọng đối với dashboard 'Số lượng và trạng thái hồ sơ tiếp nhận khách hàng' và phân tích 'Tốc độ xác minh giấy tờ'. Thuộc tính cho phép xem chi tiết một trong những khu vực thường có điểm nghẽn nhất. Bằng cách theo dõi thời gian giấy tờ ở từng trạng thái, doanh nghiệp có thể xác định chậm trễ trong khâu khách hàng nộp giấy tờ hoặc nội bộ rà soát. Vì sao điều này quan trọng Giúp theo dõi quy trình xử lý giấy tờ, từ đó xác định và khắc phục những chậm trễ thường gặp khi xác minh. Lấy dữ liệu ở đâu Đây có thể là thuộc tính trong đối tượng dữ liệu liên quan hoặc danh sách trang gắn với hồ sơ chính, dùng để theo dõi từng giấy tờ cần thiết. Hãy tham khảo tài liệu Pega KYC. Ví dụ Chờ tải lênĐã nhận, chờ rà soátĐã phê duyệtBị từ chối, cần bổ sung thông tin
	Trạng thái SLA SlaStatus	Cho biết hồ sơ có hoàn tất trong thời hạn SLA hay không.
Mô tả Thuộc tính này phân loại từng hồ sơ đã hoàn tất là 'Đúng hạn' hoặc 'Trễ hạn', dựa trên việc so sánh dấu thời gian hoàn tất thực tế với 'Ngày mục tiêu SLA'. Đây là chỉ số cốt lõi của dashboard 'Theo dõi mức độ đáp ứng SLA' và KPI 'Tỷ lệ đáp ứng SLA'. Chỉ số cho thấy rõ hiệu suất so với cam kết dịch vụ. Phân tích đặc điểm của các hồ sơ trễ hạn giúp tìm nguyên nhân gốc rễ của chậm trễ và giảm nguy cơ vi phạm SLA trong tương lai. Vì sao điều này quan trọng Đo trực tiếp mức độ thực hiện cam kết, yếu tố quan trọng đối với quản lý vận hành, tuân thủ và sự hài lòng của khách hàng. Lấy dữ liệu ở đâu Giá trị này được xác định bằng cách so sánh dấu thời gian của hoạt động cuối cùng trong hồ sơ với trường SlaTargetDate. Nếu thời gian hoàn tất sau ngày mục tiêu, trạng thái là 'Trễ hạn'. Ví dụ Đúng hạnTrễ hạnCó nguy cơ trễ hạn

Bắt buộc Nên có Không bắt buộc

Hoạt động trong quy trình tiếp nhận khách hàng KYC

Đây là các bước và mốc chính cần ghi lại trong nhật ký sự kiện để khám phá quy trình chính xác và hiểu sâu hơn về quy trình tiếp nhận khách hàng KYC.

8 Nên có 6 Không bắt buộc

	Hoạt động	Mô tả
	Đã bắt đầu rà soát tuân thủ	Hoạt động này đánh dấu thời điểm đội ngũ tuân thủ bắt đầu rà soát chính thức, một phần quan trọng và thường kéo dài của quy trình. Sự kiện được ghi nhận khi hồ sơ được giao vào hàng đợi công việc tuân thủ hoặc trạng thái được cập nhật tương ứng.
Vì sao điều này quan trọng Đây là sự kiện bắt đầu của KPI Thời gian xử lý rà soát tuân thủ. KPI này giúp đo lường và xác định điểm nghẽn trong giai đoạn rà soát quan trọng, thường được thực hiện thủ công. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái hồ sơ (pyStatusWork) sang 'Pending-Compliance' hoặc từ sự kiện tạo nhiệm vụ trong hàng đợi công việc tuân thủ. Thu thập Xác định dấu thời gian khi hồ sơ được giao vào hàng đợi công việc tuân thủ hoặc trạng thái thay đổi để cho biết quá trình rà soát bắt đầu. Loại sự kiện inferred
	Đã hoàn tất onboarding	Hoạt động này đánh dấu thời điểm hoàn tất thành công toàn bộ quy trình KYC onboarding. Sự kiện được ghi nhận khi hồ sơ Pega đạt trạng thái hoàn tất cuối cùng, cho biết quy trình đã thành công và mọi thao tác ở các hệ thống tiếp theo đã hoàn tất.
Vì sao điều này quan trọng Đây là sự kiện kết thúc thành công chính của quy trình. Sự kiện này cần thiết để tính thời gian xử lý từ đầu đến cuối cho tất cả khách hàng đã onboarding thành công. Lấy dữ liệu ở đâu Suy ra từ dấu thời gian khi trạng thái giải quyết hồ sơ (pyStatusWork) được đặt thành giá trị thành công cuối cùng, chẳng hạn 'Resolved-Completed'. Thu thập Xác định dấu thời gian của trạng thái 'Resolved-Completed' cuối cùng trong bảng History-Work. Loại sự kiện inferred
	Đã hoàn tất rà soát tuân thủ	Hoạt động này cho biết đội ngũ tuân thủ đã hoàn tất rà soát và đưa ra đề xuất. Sự kiện được ghi nhận qua thay đổi trạng thái hồ sơ khi hồ sơ rời khỏi giai đoạn tuân thủ.
Vì sao điều này quan trọng Đây là sự kiện kết thúc của KPI Thời gian xử lý rà soát tuân thủ. Phân tích thời gian đến thời điểm này là điều cần thiết để cải thiện hiệu quả tuân thủ. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái hồ sơ (pyStatusWork) từ 'Pending-Compliance' sang trạng thái như 'Pending-Final-Decision' hoặc 'Resolved-Approved'. Thu thập Xác định dấu thời gian khi giai đoạn rà soát tuân thủ hoặc nhiệm vụ được hoàn tất trong lịch sử hồ sơ. Loại sự kiện inferred
	Đã nhận tài liệu	Đánh dấu thời điểm khách hàng tải lên hoặc gửi đầy đủ các tài liệu được yêu cầu. Thông thường, sự kiện này được ghi nhận rõ ràng khi tệp đính kèm mới được liên kết với hồ sơ Pega.
Vì sao điều này quan trọng Đây là cột mốc quan trọng, đánh dấu thời điểm bắt đầu tính SLA cho việc rà soát và xác minh tài liệu. Chậm trễ trước thời điểm này phụ thuộc vào khách hàng, còn chậm trễ sau đó thuộc nội bộ. Lấy dữ liệu ở đâu Được ghi nhận rõ ràng trong các bảng tệp đính kèm của Pega (pc_link_attachment hoặc pc_data_workattach) khi tài liệu mới được liên kết với hồ sơ. Thu thập Sự kiện này là dấu thời gian tạo đối tượng tệp đính kèm liên quan được liên kết với hồ sơ. Loại sự kiện explicit
	Đã nộp hồ sơ	Hoạt động này ghi nhận thời điểm tạo hồ sơ onboarding khách hàng mới trong hệ thống Pega. Sự kiện được ghi lại khi hồ sơ của khách hàng chính thức bắt đầu, qua cổng thông tin khách hàng, người dùng nội bộ hoặc luồng dữ liệu tự động.
Vì sao điều này quan trọng Đây là sự kiện bắt đầu chính của toàn bộ quy trình onboarding. Sự kiện này cần thiết để đo thời gian xử lý từ đầu đến cuối và phân tích số lượng cũng như xu hướng nộp hồ sơ. Lấy dữ liệu ở đâu Đây là sự kiện được ghi nhận rõ ràng trong nhật ký kiểm tra của Pega khi một đối tượng công việc mới (hồ sơ) được tạo. Tìm bản ghi đầu tiên trong bảng pc_history_work theo mã hồ sơ. Thu thập Lấy từ dấu thời gian tạo hồ sơ trong bảng pc_work hoặc bản ghi đầu tiên trong nhật ký kiểm tra. Loại sự kiện explicit
	Đã phê duyệt hồ sơ	Đây là quyết định cuối cùng về việc phê duyệt hồ sơ onboarding của khách hàng. Cột mốc kinh doanh quan trọng này được suy ra khi trạng thái hồ sơ được cập nhật thành trạng thái hoàn tất cuối cùng với kết quả thành công.
Vì sao điều này quan trọng Đây là cột mốc quan trọng để phân biệt hồ sơ thành công với hồ sơ không thành công. Sự kiện này diễn ra trước các bước kích hoạt tài khoản cuối cùng và thường được dùng để đo thời gian ra quyết định. Lấy dữ liệu ở đâu Suy ra từ dấu thời gian khi trạng thái giải quyết hồ sơ (pyStatusWork) được đặt thành giá trị thành công cuối cùng, chẳng hạn 'Resolved-Completed' hoặc 'Resolved-Approved'. Thu thập Xác định lần cập nhật cuối cùng của pyStatusWork cho biết hồ sơ được giải quyết thành công trong nhật ký kiểm tra. Loại sự kiện inferred
	Đã thực hiện đánh giá rủi ro	Hoạt động này đánh dấu việc hoàn tất đánh giá và chấm điểm rủi ro khách hàng dựa trên dữ liệu hồ sơ và xác minh. Đây là cột mốc quan trọng, thường được ghi nhận khi giai đoạn hoặc bước đánh giá rủi ro trong hồ sơ Pega hoàn tất.
Vì sao điều này quan trọng Đây là cột mốc quan trọng về tuân thủ. Phân tích thời gian và kết quả của hoạt động này là yếu tố then chốt để hiểu hiệu quả quản lý rủi ro và ảnh hưởng của hoạt động đến luồng quy trình. Lấy dữ liệu ở đâu Suy ra từ việc hoàn tất một giai đoạn hoặc luồng cụ thể trong mô hình hồ sơ Pega, dẫn đến thay đổi trạng thái được ghi trong nhật ký kiểm tra. Thu thập Suy ra từ thay đổi pyStatusWork sau giai đoạn đánh giá rủi ro, chẳng hạn chuyển sang 'Pending-Compliance-Review'. Loại sự kiện inferred
	Đã từ chối hồ sơ	Đây là quyết định cuối cùng về việc từ chối hồ sơ khách hàng, chấm dứt quy trình onboarding. Sự kiện được suy ra khi hồ sơ chuyển sang trạng thái giải quyết cuối cùng với kết quả không thành công.
Vì sao điều này quan trọng Đây là sự kiện kết thúc chính khi quy trình không thành công. Sự kiện này rất quan trọng để phân tích Tỷ lệ hồ sơ bị từ chối và tìm hiểu nguyên nhân qua các thuộc tính như 'Lý do từ chối'. Lấy dữ liệu ở đâu Suy ra từ dấu thời gian khi trạng thái giải quyết hồ sơ (pyStatusWork) được đặt thành giá trị thất bại cuối cùng, chẳng hạn 'Resolved-Rejected'. Thu thập Xác định lần cập nhật cuối cùng của pyStatusWork thể hiện trạng thái từ chối trong lịch sử kiểm tra của hồ sơ. Loại sự kiện inferred
	Đã bắt đầu kiểm tra lý lịch	Hoạt động này đánh dấu thời điểm bắt đầu kiểm tra lý lịch khách hàng, có thể do bên ngoài hoặc nội bộ thực hiện và có thể cần tích hợp với dịch vụ bên thứ ba. Thông thường, sự kiện được suy ra từ thay đổi trạng thái cho biết hồ sơ đang chờ kết quả kiểm tra.
Vì sao điều này quan trọng Hoạt động này giúp tách riêng thời gian chờ các bên bên ngoài. Nhờ đó, bạn có thể phân tích hiệu suất dịch vụ bên thứ ba và ảnh hưởng của dịch vụ đến tổng thời gian onboarding. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái hồ sơ (pyStatusWork) sang 'Pending-Background-Check' hoặc trạng thái tương tự, được ghi trong bảng History-Work của Pega. Thu thập Xác định dấu thời gian khi pyStatusWork được cập nhật để cho biết quy trình kiểm tra lý lịch đã bắt đầu. Loại sự kiện inferred
	Đã hoàn tất rà soát tài liệu	Hoạt động này cho biết nhân viên tuân thủ hoặc quy trình tự động đã hoàn tất việc rà soát tài liệu khách hàng gửi. Sự kiện được suy ra từ thay đổi trạng thái hồ sơ hoặc tài liệu, cho biết bước rà soát đã hoàn tất.
Vì sao điều này quan trọng Hoàn tất KPI Thời gian xác minh tài liệu. Phân tích thời gian hoàn thành bước này giúp phát hiện điểm kém hiệu quả trong quy trình rà soát thủ công hoặc tự động. Lấy dữ liệu ở đâu Suy ra từ thay đổi trạng thái hồ sơ (pyStatusWork) trong nhật ký kiểm tra, từ 'Pending-Review' sang 'Review-Complete' hoặc 'Pending-Checks'. Thu thập Xác định dấu thời gian khi trạng thái hồ sơ (pyStatusWork) thay đổi, cho biết quy trình con xác minh tài liệu đã hoàn tất. Loại sự kiện inferred
	Đã hoàn tất sàng lọc ban đầu	Hoạt động này ghi nhận việc hoàn tất bước rà soát ban đầu, thường được tự động hóa, để kiểm tra tính đầy đủ và điều kiện cơ bản của dữ liệu hồ sơ. Sự kiện thường được suy ra từ thay đổi trạng thái hồ sơ, chẳng hạn từ 'New' sang 'Pending-Documents'.
Vì sao điều này quan trọng Phân tích thời gian ở giai đoạn đầu này giúp phát hiện điểm nghẽn trong khâu xác thực dữ liệu hoặc chạy quy tắc tự động, vốn có thể làm chậm toàn bộ quy trình. Lấy dữ liệu ở đâu Suy ra từ thay đổi thuộc tính trạng thái hồ sơ (pyStatusWork) được ghi trong nhật ký kiểm tra Pega (bảng History-Work). Thu thập Xác định dấu thời gian khi pyStatusWork chuyển từ trạng thái 'New' hoặc 'Submitted' sang 'ScreeningComplete' hoặc trạng thái tương tự. Loại sự kiện inferred
	Đã kích hoạt tài khoản	Hoạt động này cho biết tài khoản khách hàng đã được tạo và kích hoạt thành công trong hệ thống ngân hàng lõi hoặc hệ thống liên quan ở bước tiếp theo. Thông thường, sự kiện được suy ra từ lần cập nhật trạng thái cuối cùng trong hồ sơ Pega sau khi hồ sơ được phê duyệt.
Vì sao điều này quan trọng Đây là thời điểm khách hàng và doanh nghiệp nhận được giá trị. Khoảng thời gian từ 'Đã phê duyệt hồ sơ' đến sự kiện này cho biết hiệu quả bàn giao giữa các hệ thống. Lấy dữ liệu ở đâu Suy ra từ trạng thái hồ sơ cụ thể (pyStatusWork), chẳng hạn 'Resolved-AccountActive', hoặc cờ được đặt trên hồ sơ qua tích hợp và ghi trong nhật ký kiểm tra. Thu thập Xác định dấu thời gian cập nhật thuộc tính hồ sơ cho biết tài khoản ở hệ thống tiếp theo đã hoạt động. Loại sự kiện inferred
	Đã yêu cầu bổ sung thông tin	Sự kiện này xảy ra khi người rà soát, thường thuộc đội ngũ tuân thủ, cần khách hàng cung cấp thêm thông tin hoặc làm rõ. Sự kiện thường được ghi nhận rõ ràng khi người dùng gửi thư trao đổi cụ thể từ hồ sơ.
Vì sao điều này quan trọng Hoạt động này là dấu hiệu chính cho thấy quy trình phải làm lại và có vòng lặp. Theo dõi tần suất hoạt động giúp đo tỷ lệ xử lý hồ sơ thành công ngay lần đầu và xác định yêu cầu nào chưa rõ ràng. Lấy dữ liệu ở đâu Có thể ghi nhận bằng sự kiện 'Send Correspondence' trong nhật ký kiểm tra. Ngoài ra, có thể suy ra từ thay đổi trạng thái sang 'Pending-Customer-Info'. Thu thập Ghi nhận khi một đối tượng thư trao đổi cụ thể được tạo hoặc nhân viên xử lý hồ sơ khởi chạy một thao tác luồng. Loại sự kiện explicit
	Đã yêu cầu tài liệu	Hoạt động này diễn ra khi hệ thống hoặc nhân viên xác định cần khách hàng cung cấp một số tài liệu để tiếp tục xử lý. Có thể ghi nhận bằng cách xác định thời điểm tạo thư trao đổi hoặc khi trạng thái hồ sơ chuyển sang trạng thái như 'Pending-Customer-Docs'.
Vì sao điều này quan trọng Theo dõi hoạt động này giúp đo thời gian khách hàng phản hồi và xác định liệu quy trình có thường xuyên bị đình trệ vì chờ tài liệu hay không. Đây là bước trước KPI Thời gian xác minh tài liệu. Lấy dữ liệu ở đâu Có thể ghi nhận bằng sự kiện thư trao đổi cụ thể (pc_link_attachment) hoặc suy ra từ thay đổi trạng thái hồ sơ (pyStatusWork) trong nhật ký kiểm tra. Thu thập Suy ra khi pyStatusWork chuyển sang 'Pending-Documents' hoặc trạng thái tương tự. Cũng có thể gắn với sự kiện 'Send Correspondence' cụ thể. Loại sự kiện inferred

Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ Pega KYC

Các bước

Mở Pega Designer Studio: Đăng nhập môi trường Pega bằng quyền nhà phát triển hoặc quản trị viên BIX. Mở trình khám phá Records rồi mở rộng danh mục SysAdmin.
Tạo quy tắc trích xuất BIX: Nhấp chuột phải vào Extract rồi chọn Tạo. Đặt nhãn dễ nhận biết cho quy tắc, chẳng hạn ExtractCustomerOnboardingHistory. Chọn ruleset ứng dụng và chỉ định lớp cần trích xuất. Để tạo nhật ký sự kiện, bạn phải dùng lớp lịch sử của loại hồ sơ, thường theo mẫu [Your-FW-KYC-History-Work].
Cấu hình thẻ Definition: Trong biểu mẫu Extract Rule, đảm bảo Class Name được đặt thành lớp lịch sử đã xác định ở bước trước. Đây là bước quan trọng để tạo nhật ký sự kiện thay vì bản tóm tắt hồ sơ.
Đặt tiêu chí lọc: Mở thẻ Filter Criteria. Thêm bộ lọc theo dấu thời gian tạo hồ sơ để giới hạn lượng dữ liệu. Dùng thuộc tính pxCreateDateTime và đặt khoảng thời gian, chẳng hạn từ ba tháng trước đến nay. Nếu cần, bạn có thể thêm tiêu chí lọc theo trạng thái hoặc loại hồ sơ.
Chọn các thuộc tính cần trích xuất: Mở thẻ Dữ liệu. Tại đây, bạn ánh xạ thuộc tính Pega sang các cột trong tệp đầu ra. Thêm một hàng cho mỗi thuộc tính cần có. Ví dụ:
- CustomerApplication: Ánh xạ sang .pzInsKey (mã duy nhất của hồ sơ).
- EventTime: Ánh xạ sang .pxTimeCreated (dấu thời gian của sự kiện lịch sử).
- RawActivity: Ánh xạ sang .pyMessageKey (mã thông báo nội bộ của Pega cho sự kiện).
- Trạng thái: Ánh xạ sang .pyHistoryType (chẳng hạn 'Kiểm tra ở cấp trường', 'Phân công', 'Thay đổi trạng thái').
- OperatorId: Ánh xạ sang .pxPerformer.
- Thêm các thuộc tính khác như .pyAssignedToWorkgroup và dữ liệu riêng của hồ sơ như .RiskLevel hoặc .RejectionReason. Lưu ý, cần truy cập dữ liệu cấp hồ sơ qua thuộc tính trang tham chiếu đến phiên bản hồ sơ, chẳng hạn pxHistoryForReference.
Chỉ định định dạng tệp đầu ra: Trong thẻ File Specification, xác định định dạng đầu ra. Chọn CSV làm File Type. Đặt tên tệp đầu ra, chẳng hạn kyc_event_log.csv. Bạn cũng có thể cấu hình thư mục đích trên máy chủ Pega.
Lên lịch trích xuất: Lưu quy tắc Extract. Để kiểm tra, bạn có thể chạy thủ công từ menu Actions > Run. Khi triển khai thực tế, hãy tạo quy tắc Job Scheduler gọi hoạt động pxExtractDataWithArgs để chạy trích xuất BIX định kỳ, chẳng hạn mỗi đêm.
Chuyển đổi sự kiện thô: Dữ liệu thô trích xuất từ các bảng lịch sử Pega bằng .pyMessageKey và .pyHistoryType mang tính kỹ thuật. Bạn cần thêm một lớp chuyển đổi để ánh xạ các sự kiện kỹ thuật sang hoạt động nghiệp vụ cần có. Tải tệp CSV đầu ra từ BIX vào cơ sở dữ liệu trung gian hoặc công cụ chuyển đổi dữ liệu.
Áp dụng logic nghiệp vụ: Chạy tập lệnh SQL hoặc tác vụ chuyển đổi dùng câu lệnh CASE để chuyển sự kiện Pega thô thành các giá trị ActivityName dễ hiểu với nghiệp vụ. Truy vấn được cung cấp có ví dụ đầy đủ về logic này.
Tạo nhật ký sự kiện cuối cùng: Sau khi chuyển đổi, dữ liệu sẽ có cấu trúc nhật ký sự kiện phù hợp. Xuất dữ liệu đã chuyển đổi sang tệp CSV, đảm bảo tiêu đề cột khớp với yêu cầu của ProcessMind: CustomerApplication, ActivityName, EventTime, v.v.
Tải lên ProcessMind: Tải tệp CSV cuối cùng đã được làm sạch lên dự án ProcessMind của bạn.

Cấu hình

Lớp Pega dùng để trích xuất: Thiết lập quan trọng nhất là trích xuất từ lớp lịch sử gắn với loại hồ sơ KYC, chẳng hạn [Your-FW-KYC-History-Work]. Nếu trích xuất từ chính lớp công việc ([Your-FW-KYC-Work]), kết quả chỉ có một hàng cho mỗi hồ sơ, không phải nhật ký sự kiện.
Tiêu chí lọc: Luôn lọc theo khoảng ngày trên pxCreateDateTime để kiểm soát lượng dữ liệu. Với lần phân tích đầu tiên, nên lấy dữ liệu trong 3 đến 6 tháng gần nhất. Bạn có thể lọc thêm theo pyStatusWork để loại các hồ sơ không liên quan, chẳng hạn hồ sơ bị rút ngay lập tức.
Thuộc tính Pega chính: Việc trích xuất dựa vào các thuộc tính cốt lõi của Pega. .pzInsKey là mã định danh duy nhất của hồ sơ. .pxTimeCreated trên phiên bản lớp lịch sử cung cấp dấu thời gian sự kiện. .pyMessageKey và .pyHistoryType cung cấp ngữ cảnh để xác định hoạt động nghiệp vụ.
Định dạng đầu ra: Cấu hình BIX để xuất tệp CSV kèm tệp kê khai. Tệp kê khai (.xml) chứa siêu dữ liệu về lần chạy trích xuất, hữu ích cho việc kiểm tra và khắc phục sự cố.
Điều kiện tiên quyết: Ruleset Pega-BIX phải được cài đặt và bật trong ứng dụng. Người chạy trích xuất cần có vai trò PegaRULES:BIXAdmins. BIX là sản phẩm Pega có cấp phép.
Hiệu suất: Với tập dữ liệu rất lớn, gồm hàng triệu hồ sơ, hãy cân nhắc chạy trích xuất BIX ngoài giờ cao điểm. Bạn có thể cấu hình trích xuất tăng dần dựa trên thời điểm chạy thành công gần nhất để cải thiện hiệu suất cho các lần chạy sau.

Truy vấn mẫu sql

/*
 Part 1: BIX Rule-Admin-Extract Configuration (XML Representation)
 This XML defines the BIX rule. You would configure this using the Pega UI.
 The key is extracting from the History-Work class and including the raw event fields.
*/

<?xml version="1.0"?>
<pagedata>
    <pxObjClass>Rule-Admin-Extract</pxObjClass>
    <pyClassName>[Your-FW-KYC-History-Work]</pyClassName>
    <pyExtractName>ExtractCustomerOnboardingHistory</pyExtractName>
    <pyOutputFormat>CSV</pyOutputFormat>
    <pyDelimiter>,</pyDelimiter>
    <pyTargetFile>kyc_event_log.csv</pyTargetFile>
    <!-- Filter Criteria: Filter for cases created in the last 180 days -->
    <pyFilterCriteria>
        <rowdata REPEATINGTYPE="PageList">
            <row RIX="1">
                <pyFilterProperty>pxHistoryForReference.pxCreateDateTime</pyFilterProperty>
                <pyCondition>IS GREATER THAN</pyCondition>
                <pyFilterValue>CurrentDate-180</pyFilterValue>
            </row>
        </rowdata>
    </pyFilterCriteria>
    <!-- Properties to Extract -->
    <pyExtractProperties>
        <rowdata REPEATINGTYPE="PageList">
            <row RIX="1"><pyTargetProperty>CustomerApplication</pyTargetProperty><pySourceProperty>.pxHistoryForReference.pyID</pySourceProperty></row>
            <row RIX="2"><pyTargetProperty>EventTime</pyTargetProperty><pySourceProperty>.pxTimeCreated</pySourceProperty></row>
            <row RIX="3"><pyTargetProperty>RawActivity</pyTargetProperty><pySourceProperty>.pyMessageKey</pySourceProperty></row>
            <row RIX="4"><pyTargetProperty>HistoryType</pyTargetProperty><pySourceProperty>.pyHistoryType</pySourceProperty></row>
            <row RIX="5"><pyTargetProperty>OperatorId</pyTargetProperty><pySourceProperty>.pxPerformer</pySourceProperty></row>
            <row RIX="6"><pyTargetProperty>WorkGroup</pyTargetProperty><pySourceProperty>.pyAssignedToWorkgroup</pySourceProperty></row>
            <row RIX="7"><pyTargetProperty>ApplicationStatus</pyTargetProperty><pySourceProperty>.pxHistoryForReference.pyStatusWork</pySourceProperty></row>
            <row RIX="8"><pyTargetProperty>SlaTargetDate</pyTargetProperty><pySourceProperty>.pxHistoryForReference.pxGoalTime</pySourceProperty></row>
            <row RIX="9"><pyTargetProperty>RiskLevel</pyTargetProperty><pySourceProperty>.pxHistoryForReference.[YourRiskLevelProperty]</pySourceProperty></row>
            <row RIX="10"><pyTargetProperty>RejectionReason</pyTargetProperty><pySourceProperty>.pxHistoryForReference.[YourRejectionReasonProperty]</pySourceProperty></row>
        </rowdata>
    </pyExtractProperties>
</pagedata>

/*
 Part 2: SQL Transformation Query
 This script is run after BIX exports the raw data. It translates the technical
 Pega history events into the required business-friendly activity names.
 Assumes the BIX output has been loaded into a staging table named 'bix_raw_history'.
*/

SELECT
    b.CustomerApplication,
    CASE
        WHEN b.HistoryType = 'New' THEN 'Application Submitted'
        WHEN b.RawActivity = 'workitem new' THEN 'Application Submitted'
        WHEN b.RawActivity LIKE 'Status changed from New to Pending-Documents' THEN 'Initial Screening Performed'
        WHEN b.RawActivity LIKE 'Correspondence generated for document request' THEN 'Documents Requested'
        WHEN b.RawActivity LIKE 'Attachment added' THEN 'Documents Received'
        WHEN b.RawActivity = 'Flow Action: CompleteDocumentReview' THEN 'Document Review Completed'
        WHEN b.RawActivity LIKE '%BackgroundCheck%' AND b.HistoryType = 'Status Change' THEN 'Background Check Initiated'
        WHEN b.RawActivity = 'StageCompleted: RiskAssessment' THEN 'Risk Assessment Performed'
        WHEN b.RawActivity = 'AssignmentCreated: ComplianceQueue' THEN 'Compliance Review Initiated'
        WHEN b.RawActivity LIKE 'Correspondence sent to customer for info' THEN 'Additional Information Requested'
        WHEN b.RawActivity = 'StageCompleted: ComplianceReview' THEN 'Compliance Review Completed'
        WHEN b.RawActivity = 'Resolved-Completed' AND b.ApplicationStatus LIKE 'Approved%' THEN 'Application Approved'
        WHEN b.RawActivity = 'Status changed from Approved to Active' THEN 'Account Activated'
        WHEN b.RawActivity = 'Resolved-Completed' THEN 'Onboarding Completed'
        WHEN b.RawActivity = 'Resolved-Rejected' THEN 'Application Rejected'
        ELSE NULL -- Exclude rows that do not map to a required activity
    END AS ActivityName,
    b.EventTime,
    NULL AS EndTime, -- EndTime is not directly available from Pega history
    b.OperatorId,
    b.WorkGroup,
    b.ApplicationStatus,
    b.RejectionReason,
    b.SlaTargetDate,
    b.RiskLevel
FROM
    bix_raw_history AS b
WHERE
    CASE
        WHEN b.HistoryType = 'New' THEN 'Application Submitted'
        WHEN b.RawActivity = 'workitem new' THEN 'Application Submitted'
        WHEN b.RawActivity LIKE 'Status changed from New to Pending-Documents' THEN 'Initial Screening Performed'
        WHEN b.RawActivity LIKE 'Correspondence generated for document request' THEN 'Documents Requested'
        WHEN b.RawActivity LIKE 'Attachment added' THEN 'Documents Received'
        WHEN b.RawActivity = 'Flow Action: CompleteDocumentReview' THEN 'Document Review Completed'
        WHEN b.RawActivity LIKE '%BackgroundCheck%' AND b.HistoryType = 'Status Change' THEN 'Background Check Initiated'
        WHEN b.RawActivity = 'StageCompleted: RiskAssessment' THEN 'Risk Assessment Performed'
        WHEN b.RawActivity = 'AssignmentCreated: ComplianceQueue' THEN 'Compliance Review Initiated'
        WHEN b.RawActivity LIKE 'Correspondence sent to customer for info' THEN 'Additional Information Requested'
        WHEN b.RawActivity = 'StageCompleted: ComplianceReview' THEN 'Compliance Review Completed'
        WHEN b.RawActivity = 'Resolved-Completed' AND b.ApplicationStatus LIKE 'Approved%' THEN 'Application Approved'
        WHEN b.RawActivity = 'Status changed from Approved to Active' THEN 'Account Activated'
        WHEN b.RawActivity = 'Resolved-Completed' THEN 'Onboarding Completed'
        WHEN b.RawActivity = 'Resolved-Rejected' THEN 'Application Rejected'
        ELSE NULL
    END IS NOT NULL;

Các bước

Điều kiện tiên quyết và thiết lập môi trường: Đảm bảo bạn đã cài Python 3.6 trở lên. Cài các thư viện cần thiết để xử lý dữ liệu và gọi API, gồm pandas và requests, bằng lệnh sau trong terminal: pip install pandas requests.
Lấy thông tin xác thực API: Trong Pega, tạo đăng ký ứng dụng khách dịch vụ REST. Cấu hình loại cấp quyền OAuth 2.0 Client Credentials. Lưu Client ID và Client Secret để dùng khi xác thực.
Cấu hình tập lệnh: Mở tập lệnh Python được cung cấp. Tìm phần cấu hình ở đầu tệp và thay các giá trị giữ chỗ PEGA_BASE_URL, CLIENT_ID, CLIENT_SECRET và CASE_TYPE bằng thông tin môi trường Pega của bạn.
Đặt thông số trích xuất: Điều chỉnh biến START_DATE và END_DATE trong tập lệnh để xác định khoảng thời gian lấy dữ liệu hồ sơ. Các biến này quyết định những đơn đăng ký của khách hàng nào được đưa vào nhật ký sự kiện.
Chạy tập lệnh Python: Chạy tập lệnh trong terminal bằng lệnh python extract_pega_kyc_data.py. Tập lệnh sẽ xác thực với Pega API, lấy mã truy cập rồi truy xuất danh sách mã định danh hồ sơ cần thiết.
Lấy dữ liệu hồ sơ và kiểm tra: Với mỗi mã định danh hồ sơ, tập lệnh thực hiện hai lệnh gọi API chính. Lệnh gọi đầu tiên lấy thông tin hồ sơ chính, chẳng hạn trạng thái và mức độ rủi ro. Lệnh gọi thứ hai lấy lịch sử kiểm tra của hồ sơ, gồm chuỗi sự kiện, thay đổi trạng thái và thao tác của người dùng.
Ánh xạ sự kiện kiểm tra sang hoạt động: Logic chính của tập lệnh xử lý lịch sử kiểm tra của từng hồ sơ. Tập lệnh ánh xạ các thay đổi trạng thái Pega cụ thể, chẳng hạn thay đổi pyStatusWork, và ghi chú kiểm tra sang các hoạt động nghiệp vụ đã xác định, như 'Đã gửi đơn đăng ký' hoặc 'Đã hoàn tất rà soát tuân thủ'.
Sắp xếp và chuyển đổi dữ liệu: Khi xử lý từng sự kiện, tập lệnh sắp xếp dữ liệu theo định dạng chuẩn, tạo một hàng cho mỗi hoạt động được xác định. Tập lệnh điền các cột bắt buộc: CustomerApplication, ActivityName, EventTime và các thuộc tính được đề xuất.
Tạo tệp nhật ký sự kiện: Sau khi xử lý tất cả hồ sơ trong khoảng ngày đã chọn, tập lệnh tổng hợp dữ liệu và dùng thư viện pandas để xuất nhật ký sự kiện hoàn chỉnh thành tệp CSV có tên pega_kyc_event_log.csv.

Cấu hình

Điểm cuối API: Tập lệnh dùng các REST API tiêu chuẩn của Pega. Các điểm cuối chính gồm /token để xác thực, /cases để truy vấn mã định danh hồ sơ và /cases/{ID} để lấy thông tin chi tiết cùng lịch sử kiểm tra của hồ sơ. Điểm cuối chính xác để lấy danh sách hồ sơ có thể là API tùy chỉnh cung cấp Pega Report Definition.
Xác thực: Tập lệnh dùng OAuth 2.0 cùng Client ID và Secret để giao tiếp an toàn giữa các máy chủ. Ứng dụng khách API trong Pega cần được cấp vai trò có quyền đọc loại hồ sơ KYC đã chỉ định và dữ liệu liên quan.
Bộ lọc khoảng ngày: Tập lệnh được cấu hình bằng các tham số START_DATE và END_DATE. Nên trích xuất theo từng đợt, chẳng hạn mỗi đợt từ 3 đến 6 tháng, để tránh hết thời gian chờ và kiểm soát mức sử dụng bộ nhớ. Các ngày này dùng để lọc danh sách hồ sơ ban đầu cần xử lý.
Bộ lọc loại hồ sơ: Tham số quan trọng là CASE_TYPE. Hãy đặt tham số này thành tên lớp cụ thể của hồ sơ tiếp nhận khách hàng KYC trên Pega, chẳng hạn YourOrg-App-Work-KYC. Nhờ đó, tập lệnh chỉ trích xuất dữ liệu của quy trình liên quan.
Lưu ý về hiệu suất: Lấy dữ liệu và lịch sử kiểm tra từng hồ sơ một có thể chậm khi khối lượng lớn. Tập lệnh có phân trang khi lấy danh sách hồ sơ ban đầu. Nếu cần trích xuất hơn 50.000 hồ sơ, hãy cân nhắc chạy tập lệnh ngoài giờ cao điểm hoặc tìm phương án trích xuất hàng loạt nếu phiên bản Pega của bạn hỗ trợ.

Truy vấn mẫu python

import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Section --- #
class=class="hl-string">"hl-comment"># Replace with your Pega environment details
PEGA_BASE_URL = class="hl-string">"https://[your-pega-server]/prweb/api/v1"
CLIENT_ID = class="hl-string">"[your_client_id]"
CLIENT_SECRET = class="hl-string">"[your_client_secret]"

class=class="hl-string">"hl-comment"># Pega Case Type for KYC Customer Onboarding
CASE_TYPE = class="hl-string">"[Your-KYC-Case-Type]"

class=class="hl-string">"hl-comment"># Date range for extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># Mapping from Pega statuses/audit notes to standard Activity Names
class=class="hl-string">"hl-comment"># This section requires customization based on your specific Pega application configuration.
ACTIVITY_MAPPING = {
    class="hl-string">'Pending-InitialScreening': class="hl-string">'Initial Screening Performed',
    class="hl-string">'Pending-Customer-Docs': class="hl-string">'Documents Requested',
    class="hl-string">'Attachment-Added': class="hl-string">'Documents Received',
    class="hl-string">'Pending-DocReview': class="hl-string">'Document Review Completed',
    class="hl-string">'Pending-BackgroundCheck': class="hl-string">'Background Check Initiated',
    class="hl-string">'Pending-RiskAssessment': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'Pending-ComplianceReview': class="hl-string">'Compliance Review Initiated',
    class="hl-string">'Correspondence-Sent-InfoRequest': class="hl-string">'Additional Information Requested',
    class="hl-string">'Pending-FinalDecision': class="hl-string">'Compliance Review Completed',
    class="hl-string">'Resolved-Completed': class="hl-string">'Application Approved',
    class="hl-string">'Status-AccountActivated': class="hl-string">'Account Activated',
    class="hl-string">'Resolved-Onboarded': class="hl-string">'Onboarding Completed',
    class="hl-string">'Resolved-Rejected': class="hl-string">'Application Rejected'
}

class=class="hl-string">"hl-comment"># --- Script Logic --- #

def get_access_token():
    class="hl-string">"""Authenticates with Pega and returns an access token."""
    token_url = fclass="hl-string">"{PEGA_BASE_URL.replace('/api/v1', '')}/PRRestService/oauth2/v1/token"
    auth_payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials'
    }
    try:
        response = requests.post(token_url, auth=(CLIENT_ID, CLIENT_SECRET), data=auth_payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def get_case_ids(token):
    class="hl-string">"""Retrieves a list of case IDs for the specified date range and case type."""
    case_ids = []
    page = 1
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}'}
    
    while True:
        query_params = {
            class="hl-string">'caseTypeID': CASE_TYPE,
            class="hl-string">'query': fclass="hl-string">'.pxCreateDateTime > "{START_DATE}T00:00:00.000Z" AND .pxCreateDateTime < "{END_DATE}T23:59:59.000Z"',
            class="hl-string">'page': page,
            class="hl-string">'pageSize': 1000  class=class="hl-string">"hl-comment"># Adjust page size as needed
        }
        try:
            response = requests.get(fclass="hl-string">"{PEGA_BASE_URL}/cases", headers=headers, params=query_params)
            response.raise_for_status()
            data = response.json()
            cases_on_page = data.get(class="hl-string">'cases', [])
            if not cases_on_page:
                break class=class="hl-string">"hl-comment"># Exit loop if no more cases are returned
            
            for case in cases_on_page:
                case_ids.append(case.get(class="hl-string">'ID'))
            
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching case IDs on page {page}: {e}")
            break
    return case_ids

def main():
    class="hl-string">"""Main function to extract, process, and save event data."""
    print(class="hl-string">"Starting Pega KYC data extraction...")
    access_token = get_access_token()
    if not access_token:
        return

    print(fclass="hl-string">"Successfully authenticated. Fetching case IDs between {START_DATE} and {END_DATE}...")
    case_ids = get_case_ids(access_token)
    print(fclass="hl-string">"Found {len(case_ids)} cases to process.")

    event_log = []
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}

    for i, case_id in enumerate(case_ids):
        print(fclass="hl-string">"Processing case {i+1}/{len(case_ids)}: {case_id}")
        try:
            case_response = requests.get(fclass="hl-string">"{PEGA_BASE_URL}/cases/{case_id}", headers=headers)
            case_response.raise_for_status()
            case_data = case_response.json()

            class=class="hl-string">"hl-comment"># Extract case-level attributes
            case_info = case_data.get(class="hl-string">'content', {})
            rejection_reason = case_info.get(class="hl-string">'RejectionReason', None)
            sla_date = case_info.get(class="hl-string">'pySLADeadline', None)
            risk_level = case_info.get(class="hl-string">'RiskLevel', None)

            class=class="hl-string">"hl-comment"># 1. Application Submitted Event (from case creation time)
            event_log.append({
                class="hl-string">'CustomerApplication': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Application Submitted',
                class="hl-string">'EventTime': case_info.get(class="hl-string">'pxCreateDateTime'),
                class="hl-string">'EndTime': None, class=class="hl-string">"hl-comment"># EndTime can be derived in post-processing if needed
                class="hl-string">'OperatorId': case_info.get(class="hl-string">'pxCreateOperator'),
                class="hl-string">'WorkGroup': case_info.get(class="hl-string">'pxCreateOpWorkgroup', None),
                class="hl-string">'ApplicationStatus': case_info.get(class="hl-string">'pyStatusWork'),
                class="hl-string">'RejectionReason': rejection_reason,
                class="hl-string">'SlaTargetDate': sla_date,
                class="hl-string">'RiskLevel': risk_level
            })

            class=class="hl-string">"hl-comment"># 2. Process Audit History for other events
            audit_history = case_data.get(class="hl-string">'audit', [])
            for audit_entry in audit_history:
                timestamp = audit_entry.get(class="hl-string">'timeStamp')
                operator = audit_entry.get(class="hl-string">'performedBy', {}).get(class="hl-string">'userID')
                message = audit_entry.get(class="hl-string">'message')
                
                class=class="hl-string">"hl-comment"># Map status changes and specific messages to activities
                activity_name = None
                if class="hl-string">'changed status to' in message:
                    new_status = message.split(class="hl-string">' to ')[-1].strip()
                    activity_name = ACTIVITY_MAPPING.get(new_status)
                elif class="hl-string">'Created attachment' in message:
                    class=class="hl-string">"hl-comment"># This is a generic mapping, may need refinement
                    activity_name = ACTIVITY_MAPPING.get(class="hl-string">'Attachment-Added')
                elif class="hl-string">'Sent correspondence' in message and class="hl-string">'Request for Information' in message:
                     activity_name = ACTIVITY_MAPPING.get(class="hl-string">'Correspondence-Sent-InfoRequest')
                
                if activity_name:
                    event_log.append({
                        class="hl-string">'CustomerApplication': case_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': timestamp,
                        class="hl-string">'EndTime': None,
                        class="hl-string">'OperatorId': operator,
                        class="hl-string">'WorkGroup': None, class=class="hl-string">"hl-comment"># Workgroup is not always available in audit trail
                        class="hl-string">'ApplicationStatus': case_info.get(class="hl-string">'pyStatusWork'),
                        class="hl-string">'RejectionReason': rejection_reason,
                        class="hl-string">'SlaTargetDate': sla_date,
                        class="hl-string">'RiskLevel': risk_level
                    })

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not process case {case_id}: {e}")
        except Exception as ex:
            print(fclass="hl-string">"An unexpected error occurred processing case {case_id}: {ex}")

    print(class="hl-string">"Processing complete. Generating CSV file...")
    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'], ascending=[True, True])
    df.to_csv(class="hl-string">'pega_kyc_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to pega_kyc_event_log.csv")

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

Sẵn sàng bắt đầu chưa?

Mẫu dữ liệu này giúp bạn có nền tảng vững chắc để bắt đầu tối ưu hóa quy trình tiếp nhận khách hàng KYC. Hãy bắt đầu tìm ra điểm kém hiệu quả và cải thiện việc tuân thủ ngay hôm nay!

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Tinh gọn quy trình tiếp nhận KYC ngay, chấm dứt chậm trễ

Đơn giản hóa quy trình KYC, rút ngắn thời gian tiếp nhận xuống còn 24 giờ và cải thiện việc tuân thủ.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng, thiết lập chỉ trong vài phút

Mẫu dữ liệu quy trình tiếp nhận khách hàng KYC

Mẫu dữ liệu quy trình tiếp nhận khách hàng KYC

Thuộc tính quy trình tiếp nhận khách hàng KYC

Hoạt động trong quy trình tiếp nhận khách hàng KYC

Hướng dẫn trích xuất dữ liệu

Xuất dữ liệu bằng Pega Business Intelligence Exchange (BIX)

Các bước

Cấu hình

Truy vấn mẫu sql

Tập lệnh Python dùng REST API quản lý hồ sơ Pega

Các bước

Cấu hình

Truy vấn mẫu python

Sẵn sàng bắt đầu chưa?

Tinh gọn quy trình tiếp nhận KYC ngay, chấm dứt chậm trễ