Mẫu RFP lựa chọn nhà cung cấp EWA: 60 tiêu chí đánh giá

Một RFP lựa chọn nhà cung cấp EWA cần đánh giá toàn bộ chuỗi từ công đã làm, quyền duyệt, số tiền khả dụng, chi ngân hàng đến đối soát payroll, không chỉ so sánh giao diện và phí. Mẫu dưới đây giúp doanh nghiệp đặt cùng một bộ câu hỏi cho mọi nhà cung cấp, yêu cầu bằng chứng và chấm điểm theo mức độ quan trọng.
> Nói ngắn gọn: RFP nên gồm 10 nhóm với 60 tiêu chí, điều kiện loại bắt buộc và thang điểm có trọng số. Mỗi câu trả lời phải ghi rõ: có sẵn, cần cấu hình, cần phát triển hay không đáp ứng; đồng thời đính kèm tài liệu hoặc bản trình diễn làm bằng chứng.
> Lưu ý sử dụng: Nguyễn Minh Khang — Chuyên viên ban chiến lược, không phải hồ sơ mời thầu pháp lý hoàn chỉnh và không phải cam kết rằng Lương Ngày đáp ứng mọi tiêu chí. Nhân Kiệt phải trả lời từng mục bằng bằng chứng hiện hành khi tham gia một RFP thực tế.
1. RFP EWA khác RFP phần mềm nhân sự thông thường thế nào?
(Xem thêm: Checklist lựa chọn nhà cung cấp EWA và Doanh nghiệp đánh giá nhà cung cấp EWA theo tiêu chí nào.)
EWA liên quan đồng thời đến dữ liệu nhân sự, chấm công, tiền lương, dữ liệu cá nhân và chuyển tiền. Một lỗi hiển thị có thể chỉ gây bất tiện; một lỗi trạng thái giao dịch hoặc công đã duyệt có thể gây chênh lệch tiền thật.
Vì vậy, RFP phải kiểm tra năm khả năng cốt lõi:
Không sinh tiền từ công tương lai hoặc công chưa duyệt.
Không trả sai người, sai tài khoản hoặc trùng giao dịch.
Giải thích được từng đồng trong số khả dụng.
Đối soát được giao dịch với ngân hàng và payroll.
Bảo vệ được dữ liệu cá nhân và duy trì dịch vụ khi có sự cố.
Nếu một nhà cung cấp không chứng minh được một trong năm điểm này, doanh nghiệp không nên bù điểm bằng giao diện đẹp hoặc mức phí thấp.
2. Cách yêu cầu nhà cung cấp trả lời
Mỗi tiêu chí nên có sáu cột:
Trường trả lời | Nội dung |
|---|---|
Mức đáp ứng | Có sẵn / Cấu hình / Phát triển / Không đáp ứng |
Mô tả | Cách tính năng hoặc quy trình hoạt động |
Bằng chứng | Tài liệu, ảnh màn hình, log ẩn dữ liệu, demo hoặc báo cáo |
Ngoại lệ | Điều kiện tính năng không hoạt động hoặc cần thao tác tay |
Thời gian | Thời gian sẵn sàng nếu phải cấu hình/phát triển |
Chi phí | Khoản đã gồm và khoản phát sinh |
Không chấp nhận câu trả lời chỉ có “Có”. Nếu cần phát triển, nhà cung cấp phải ghi phạm vi, nghiệm thu, thời hạn và trách nhiệm khi trễ.
3. Thang điểm và điều kiện loại
Thang điểm 0–5
Điểm | Ý nghĩa |
|---|---|
0 | Không đáp ứng hoặc không trả lời |
1 | Chỉ có định hướng, chưa có kế hoạch/bằng chứng |
2 | Cần phát triển đáng kể hoặc phụ thuộc bên thứ ba chưa xác nhận |
3 | Đáp ứng sau cấu hình, có kế hoạch và người chịu trách nhiệm |
4 | Có sẵn, trình diễn được và có tài liệu |
5 | Có sẵn, có bằng chứng vận hành/kiểm soát và chỉ số đo được |
Điều kiện loại gợi ý
không chặn được công chưa làm/chưa duyệt;
không có cơ chế chống chi trùng;
không xác thực tài khoản nhận tiền;
không lưu nhật ký sửa công và trạng thái giao dịch;
không nối được khoản đã nhận vào payroll;
không xác định vai trò xử lý dữ liệu cá nhân;
không cung cấp quy trình xử lý sự cố nghiêm trọng;
không giải thích được bản chất pháp lý và các bên trong luồng tiền.
Điều kiện loại phải được phê duyệt trước khi mở hồ sơ để tránh thay đổi tiêu chuẩn theo cảm tính.
4. Nhóm 1 — Nghiệp vụ EWA và trải nghiệm người lao động (8 tiêu chí)
Chỉ tính giá trị từ công đã làm và đã duyệt.
Chặn ngày hiện tại chưa chốt và ngày tương lai.
Hiển thị số khả dụng và công thức giải thích được.
Hiển thị chi tiết ngày công, đã nhận và phần giữ dự trù.
Cho người lao động chủ động yêu cầu, không cần duyệt từng lệnh nếu đủ điều kiện.
Có bước xác nhận/đồng ý trước mỗi lần nhận.
Hiển thị trạng thái giao dịch rõ: chờ, thành công, thất bại, cần tra soát.
Có kênh hỗ trợ khi sai hồ sơ, sai công hoặc chưa nhận tiền.
Bằng chứng nên yêu cầu: demo từ một ngày công đã duyệt đến giao dịch; demo trường hợp công chưa duyệt; mẫu lịch sử giao dịch và nội dung cam kết.
Với Lương Ngày, công thức trong hệ thống là: công đã duyệt × đơn giá/ngày theo khách hàng − đã nhận trong kỳ − khoản giữ dự trù, làm tròn xuống bội 1.000 đồng. Đây là thông tin xác minh từ mã; chính sách áp dụng cho từng khách hàng vẫn phải được xác nhận.
5. Nhóm 2 — Chấm công, duyệt công và ngoại lệ (7 tiêu chí)
Nhận dữ liệu từ hệ thống khách hàng, ERP hoặc app.
Hỗ trợ nhiều khuôn bảng công và ca qua nửa đêm.
Có khóa nối ổn định giữa người lao động và mã chấm công.
Phân quyền xem, sửa, duyệt và từ chối công.
Sửa công đã duyệt phải quay lại trạng thái cần kiểm tra.
Lưu nhật ký trước/sau, người sửa và thời điểm.
Có quy trình cho đổi ca, điều chuyển, nghỉ việc và công bị giảm sau khi đã nhận tiền.
Kịch bản demo bắt buộc: sửa một bản ghi đã duyệt và chứng minh số khả dụng được tính lại theo quy tắc; không xóa dấu vết cũ.
Hệ thống Lương Ngày hiện hỗ trợ khách hàng thao tác trên cổng /kh; khách hàng hoặc giám sát Nhân Kiệt có thể duyệt theo quyền. Việc phù hợp với quy trình phê duyệt nhiều cấp của từng doanh nghiệp phải được kiểm thử riêng.
6. Nhóm 3 — Pháp lý và quản trị hợp đồng (6 tiêu chí)
Xác định pháp nhân ký hợp đồng và thẩm quyền người ký.
Có bản phân tích pháp lý về bản chất mô hình và cơ chế đối trừ.
Điều khoản người lao động thống nhất giữa hợp đồng, app và truyền thông.
Chính sách phí, bên chịu phí và điều kiện thay đổi minh bạch.
Trách nhiệm khi sai công, sai người, chi trùng hoặc không thu hồi được.
Quy trình khiếu nại, chấm dứt dịch vụ và giải quyết tranh chấp.
Doanh nghiệp không nên coi câu “không phải vay” là kết luận pháp lý. Nhà cung cấp phải trình bày cấu trúc giao dịch, quyền và nghĩa vụ các bên, sau đó để pháp chế đánh giá trong bối cảnh hợp đồng cụ thể.
7. Nhóm 4 — Bảo vệ dữ liệu cá nhân (6 tiêu chí)
Xác định vai trò của từng bên trong xử lý dữ liệu.
Có danh mục dữ liệu, mục đích và căn cứ xử lý.
Có thông báo/đồng ý và cơ chế thực hiện quyền chủ thể dữ liệu khi cần.
Quy định thời hạn lưu, xóa, ẩn danh và trả dữ liệu.
Công bố bên xử lý phụ, nơi lưu trữ và luồng chuyển dữ liệu.
Có quy trình xử lý vi phạm dữ liệu và hồ sơ đánh giá tác động theo yêu cầu.
RFP phát hành từ năm 2026 cần được pháp chế rà soát theo Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và văn bản hướng dẫn hiện hành. Các trường nhạy cảm như CCCD, ảnh, vị trí, thiết bị, tài khoản ngân hàng và tiền lương phải được mô tả riêng.
8. Nhóm 5 — An toàn thông tin (7 tiêu chí)
Kiến trúc phân tách môi trường và dịch vụ nhạy cảm.
Xác thực, phân quyền tối thiểu và rà soát quyền định kỳ.
Mã hóa dữ liệu khi truyền và khi lưu.
Quản lý khóa, bí mật và thông tin kết nối ngân hàng.
Nhật ký kiểm toán, giám sát và cảnh báo hành vi bất thường.
Quản lý lỗ hổng, cập nhật và kiểm thử bảo mật độc lập.
Ứng cứu sự cố, sao lưu, phục hồi và diễn tập liên tục kinh doanh.
Nhà cung cấp phải ghi rõ bằng chứng nào được cung cấp trong giai đoạn hồ sơ, thẩm định tại chỗ hoặc phòng dữ liệu bảo mật. Số lượng test nội bộ không thay thế pentest hoặc chứng nhận độc lập.
9. Nhóm 6 — Tích hợp và chất lượng dữ liệu (6 tiêu chí)
Có đặc tả API/file và từ điển dữ liệu.
Xác định nguồn dữ liệu chuẩn khi hai hệ thống khác nhau.
Có kiểm tra trùng, thiếu, sai định dạng và tổng kiểm soát.
Có cơ chế đồng bộ lại, chống nhập trùng và quản lý phiên bản.
Có môi trường test, dữ liệu giả lập và tiêu chí nghiệm thu.
Có báo cáo độ trễ, bản ghi lỗi và quy trình xử lý.
Nhà cung cấp cần phân biệt lịch chạy kỹ thuật với SLA đã cam kết. Ví dụ, hệ thống Lương Ngày hiện có lịch đồng bộ Sheet 30 phút và ERP hằng ngày; RFP vẫn phải yêu cầu mức dịch vụ, cách đo và ngoại lệ bằng văn bản.
10. Nhóm 7 — Ngân hàng, chi tiền và chống giao dịch trùng (6 tiêu chí)
Xác minh người nhận và tài khoản chính chủ.
Có mã giao dịch duy nhất, bất biến qua các lần thử.
Có khóa đồng thời để ngăn hai lệnh chi cho cùng yêu cầu.
Chỉ ghi thành công khi có phản hồi/chữ ký hợp lệ.
Giữ chờ khi trạng thái không rõ và có cơ chế tra soát.
Có công tắc dừng khẩn cấp và quyền bật lại được kiểm soát.
Trong luồng chuẩn hiện tại, Lương Ngày chi qua VPBank vào tài khoản VPBank chính chủ đã xác thực. Trường hợp đặc biệt sử dụng ngân hàng khác và phạm vi áp dụng phải được Nhân Kiệt xác nhận, không mặc nhiên ghi vào RFP như tính năng tiêu chuẩn.
11. Nhóm 8 — Đối soát, payroll và kiểm toán (5 tiêu chí)
Có báo cáo giao dịch theo người, khách hàng và kỳ lương.
Có đối soát với sao kê ngân hàng và quy trình khoản treo.
Có tệp/API đưa khoản đã nhận vào payroll.
Có kiểm soát để ngày công đã sử dụng không cộng dồn kỳ sau.
Có sổ và quy trình xử lý khoản không thu hồi được.
Bằng chứng nên yêu cầu: một bộ dữ liệu mẫu hoàn chỉnh gồm công, yêu cầu nhận, phản hồi ngân hàng, báo cáo đối soát và phiếu lương đã che thông tin cá nhân.
12. Nhóm 9 — SLA, hỗ trợ và triển khai (5 tiêu chí)
SLA khả dụng, phản hồi và khôi phục được định nghĩa bằng số.
Có phân cấp P1–P4, đầu mối và cơ chế escalation.
Có kế hoạch pilot, đào tạo, truyền thông và quản lý thay đổi.
Có RTO/RPO, lịch bảo trì và thông báo sự cố.
Có báo cáo dịch vụ định kỳ và phân tích nguyên nhân gốc.
Các câu như “gần như tức thì” không đủ để chấm điểm SLA. RFP phải chỉ rõ đồng hồ bắt đầu lúc nào, dừng lúc nào, log nào là nguồn chuẩn và trường hợp nào được loại trừ.
13. Nhóm 10 — Thương mại, năng lực và thoát dịch vụ (4 tiêu chí)
Cơ cấu giá đầy đủ: triển khai, tích hợp, vận hành, giao dịch và phát triển thêm.
Năng lực tài chính, vận hành và case tham chiếu .
Quyền sở hữu dữ liệu, xuất dữ liệu và hỗ trợ chuyển đổi.
Quy trình thu hồi quyền, xóa/trả dữ liệu và hỗ trợ sau chấm dứt.
Không nên yêu cầu case quá giống chỉ để loại nhà cung cấp mới; thay vào đó, đánh giá chất lượng bằng chứng, năng lực kiểm soát và khả năng chạy pilot an toàn.
14. Trọng số chấm điểm gợi ý

Nhóm | Trọng số |
|---|---|
Nghiệp vụ và trải nghiệm | 15% |
Chấm công và ngoại lệ | 12% |
Pháp lý/hợp đồng | 12% |
Dữ liệu cá nhân | 12% |
An toàn thông tin | 15% |
Tích hợp | 8% |
Ngân hàng/chi tiền | 10% |
Đối soát/payroll | 8% |
SLA/triển khai | 5% |
Thương mại/thoát dịch vụ | 3% |
Điểm tổng có trọng số không thay thế điều kiện loại. Một nhà cung cấp đạt 90/100 nhưng không chống được chi trùng vẫn không nên vào pilot.
15. Ba vòng đánh giá nhà cung cấp
15. Ba vòng đánh giá nhà cung cấp

(Xem thêm: Hồ sơ thẩm định Lương Ngày và Mẫu kế hoạch pilot EWA và tiêu chí mở rộng.)
Vòng 1 — Hồ sơ
Kiểm tra tính đầy đủ, điều kiện loại và bằng chứng pháp lý/bảo mật.
Vòng 2 — Demo theo kịch bản
Không để nhà cung cấp tự chọn luồng đẹp nhất. Doanh nghiệp phát kịch bản chung: ca đêm, sửa công đã duyệt, giao dịch treo, nghỉ việc và đối soát cuối kỳ.
Vòng 3 — Pilot có kiểm soát
Chọn phạm vi nhỏ, chạy song song với payroll, đặt ngưỡng dừng và đo KPI. Chỉ mở rộng sau khi chênh lệch được giải thích và xử lý đúng.
16. Câu hỏi thường gặp
Có nên chọn nhà cung cấp có phí thấp nhất không?
Không nên nếu tổng chi phí chưa gồm tích hợp, hỗ trợ, xử lý dữ liệu và vận hành ngoại lệ. Chi phí sai giao dịch hoặc lệch payroll có thể lớn hơn chênh lệch đơn giá.
Có cần yêu cầu đủ 60 tiêu chí?
Không nhất thiết mọi tiêu chí có trọng số như nhau, nhưng doanh nghiệp nên trả lời toàn bộ để biết mình đang chấp nhận khoảng trống nào.
Demo thành công có đủ để vào vận hành không?
Không. Demo chứng minh luồng chức năng; pilot mới kiểm tra dữ liệu thật, phân quyền, hỗ trợ và đối soát trong phạm vi kiểm soát.
Nhà cung cấp có thể trả lời “cần phát triển” không?
Có, nếu nêu rõ phạm vi, thời gian, chi phí, tiêu chí nghiệm thu và rủi ro phụ thuộc. Không nên chấm như tính năng có sẵn.
Lương Ngày hiện đáp ứng toàn bộ 60 tiêu chí không?
Bài không đưa ra kết luận đó. Nhiều năng lực kỹ thuật từ mã, nhưng hồ sơ pháp lý, SLA, pentest, chính sách thương mại và bằng chứng vận hành phải được bộ phận có thẩm quyền cung cấp.
17. Kết luận
RFP tốt giúp doanh nghiệp biến câu hỏi “ứng dụng có gì?” thành câu hỏi quan trọng hơn: toàn bộ chuỗi có kiểm soát được không và bằng chứng ở đâu? Bộ 60 tiêu chí tạo một ngôn ngữ chung cho HR, pháp chế, IT, an toàn thông tin, tài chính, payroll và mua hàng. Nhà cung cấp phù hợp không chỉ trình diễn được luồng thuận lợi mà còn giải thích được điều gì xảy ra khi dữ liệu sai, ngân hàng chậm hoặc người lao động nghỉ giữa kỳ.
---
Tác giả: Nguyễn Minh Khang — Chuyên viên ban chiến lược, Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt.
Tư vấn giải pháp Lương Ngày cho doanh nghiệp: Hotline 0937.022.655 · Email info@nhankiet.vn · Lương Ngày cho doanh nghiệp