Doanh nghiệp cần bao nhiêu người để vận hành EWA?

Triển khai EWA không nhất thiết phải lập thêm một phòng ban. Phần lớn vai trò có thể do HR, payroll, tài chính, CNTT và CSKH hiện hữu kiêm nhiệm. Tuy nhiên, doanh nghiệp vẫn cần một người chịu trách nhiệm đầu cuối và đủ năng lực trực tại các điểm nhạy cảm: duyệt công, giao dịch ngân hàng, đối soát và xử lý khiếu nại.

> Nói ngắn gọn: Đừng hỏi trước “cần mấy người”; hãy đo số người lao động, số khách hàng, khuôn bảng công, giao dịch, ngoại lệ, ca hỗ trợ và mức tự động hóa. Một pilot nhỏ có thể vận hành bằng nhóm kiêm nhiệm; quy mô lớn cần các vai trò chuyên trách và trực luân phiên.

> Cảnh báo: Ngô Nhã Kỳ — Biên tập viên ban biên tập, không phải định biên Nhân Kiệt. Phải đo workload thật trong pilot trước khi quyết định biên chế hoặc cam kết hỗ trợ 24/7.

1. Vì sao số người dùng không đủ để định biên?

Hai doanh nghiệp cùng 5.000 lao động có thể cần nguồn lực rất khác nhau:

• doanh nghiệp A có một hệ thống công chuẩn, một kỳ lương, ít ngoại lệ;

• doanh nghiệp B có 20 khách hàng, nhiều Sheet, ca đêm, người làm nhiều nơi và duyệt công phân tán.

Khối lượng vận hành chủ yếu đến từ ngoại lệ, không chỉ số giao dịch thành công.

2. Mười biến số quyết định nguồn lực

1. Số người lao động đủ điều kiện.

2. Số người dùng hoạt động và giao dịch/ngày.

3. Số khách hàng/địa điểm/ca.

4. Số khuôn bảng công.

5. Tỷ lệ công không ghép/chưa duyệt.

6. Tỷ lệ CCCD/tài khoản không xác thực.

7. Tỷ lệ giao dịch treo/thất bại.

8. Số kỳ và mức phức tạp payroll.

9. Giờ hỗ trợ yêu cầu.

10. Mức tự động hóa, SLA và rủi ro chấp nhận.

3. 11 vai trò cốt lõi

3. 11 vai trò cốt lõi

(Xem thêm: Vận hành EWA sau go-live: RACI, kiểm soát và sự cố.)

1. Executive Sponsor

Phê duyệt mục tiêu, ngân sách, phạm vi, khẩu vị rủi ro và quyết định mở rộng/dừng.

2. Service Owner

Chịu trách nhiệm đầu cuối về chất lượng dịch vụ, không chỉ một hệ thống. Đây là vai trò không nên bỏ trống.

3. Product/Process Owner

Quản lý yêu cầu, công thức, hạn mức, quy trình và ưu tiên cải tiến.

4. HR Master Data

Quản lý hồ sơ, CCCD, trạng thái làm việc, điều chuyển, nghỉ việc và quan hệ khách hàng.

5. Attendance Operations

Quản lý nguồn công, mapping, ca, lỗi đồng bộ và điều phối người duyệt.

6. Payment Operations

Theo dõi lệnh chi, tài khoản chuyên chi, giao dịch treo, tra soát và công tắc dừng.

7. Reconciliation/Finance

Đối soát sổ EWA–sao kê–công nợ; xử lý chênh lệch và khoản không thu hồi.

8. Payroll

Đưa đúng giao dịch vào đúng người/kỳ, lập báo cáo cầu nối và phiếu lương.

9. Customer Support

Tiếp nhận một cửa, xác minh, phân loại, cập nhật và đóng ticket.

10. Engineering/SRE/ATTT

Tích hợp, monitoring, release, sự cố, bảo mật, sao lưu và khôi phục.

11. Legal/Data/Compliance

Hợp đồng, quy chế, dữ liệu cá nhân, nội dung truyền thông và thay đổi pháp lý.

Một người có thể kiêm nhiều vai trò ở pilot; nhưng quyền xung đột phải được tách.

4. Mô hình A — Pilot nhỏ

4. Mô hình A — Pilot nhỏ

Phạm vi minh họa

• 100–1.000 người đủ điều kiện;

• một–hai khách hàng;

• ít khuôn công;

• hỗ trợ trong giờ xác định;

• giới hạn giao dịch/tiền thấp;

• đối soát hằng ngày.

Nhóm lõi tham khảo

Tổng số người thực tế có thể 5–8 người kiêm nhiệm, không phải 5–8 FTE toàn thời gian.

5. Mô hình B — Vận hành quy mô vừa

Phạm vi minh họa

• 1.000–10.000 người;

• nhiều địa điểm/khách hàng;

• giao dịch hằng ngày ổn định;

• một số khuôn công;

• SLA và ca hỗ trợ mở rộng.

Cấu trúc tham khảo

• một Service Owner chuyên trách;

• một Product/Process Owner;

• 1–3 người HR/công;

• 1–2 người payment/đối soát;

• 1–2 người CSKH theo ca;

• payroll theo kỳ, có người dự phòng;

• kỹ thuật/SRE on-call;

• ATTT, pháp chế và dữ liệu theo lịch review.

Định biên phải điều chỉnh theo tỷ lệ ngoại lệ và khối lượng thật.

6. Mô hình C — Quy mô lớn, nhiều khách hàng

Đặc điểm

• hàng chục nghìn người lao động;

• hàng trăm khách hàng/địa điểm;

• nhiều nguồn và khuôn bảng công;

• hỗ trợ ngoài giờ;

• giao dịch và dòng tiền lớn;

• yêu cầu kiểm soát/phân tách nhiệm vụ cao.

Nên tổ chức theo các pod

1. Service Governance: owner, KPI, rủi ro, vendor.

2. Workforce Data: hồ sơ, công, mapping, duyệt.

3. Money Operations: nguồn tiền, lệnh chi, tra soát.

4. Reconciliation & Payroll: sao kê, công nợ, bảng lương.

5. Worker Experience: onboarding, CSKH, tài chính cá nhân.

6. Technology & Trust: engineering, SRE, ATTT, dữ liệu.

Mỗi pod có trưởng nhóm và lịch dự phòng; P1 có Incident Commander độc lập với người gây thay đổi.

7. Công thức định biên theo workload

7. Công thức định biên theo workload

Có thể ước tính:

FTE = tổng phút xử lý công việc trong kỳ ÷ số phút làm việc hữu ích mỗi FTE

Ví dụ CSKH:

Ticket/ngày × phút trung bình/ticket × hệ số hậu kiểm ÷ phút hữu ích/ca

Ví dụ đối soát:

Ngoại lệ/ngày × phút/ngoại lệ + thời gian kiểm tra tổng + báo cáo

Không dùng 480 phút/ngày như năng suất hữu ích tuyệt đối; cần trừ họp, đào tạo, nghỉ và biến động tải.

8. Bộ dữ liệu phải thu trong pilot để định biên

(Xem thêm: Kết quả pilot Lương Ngày: KPI và bài học và Kế hoạch pilot EWA 90 ngày.)

• số hồ sơ mới/sửa/nghỉ;

• số dòng công và tỷ lệ lỗi;

• công chờ duyệt và tuổi;

• tài khoản/OCR không khớp;

• giao dịch theo giờ/ca;

• tỷ lệ thành công/chờ/thất bại;

• số ngoại lệ đối soát;

• ticket theo loại;

• thời gian xử lý và tái mở;

• số thay đổi cấu hình;

• khối lượng payroll theo cut-off;

• sự cố và giờ on-call.

Đo ít nhất qua một kỳ có payroll để tránh đánh giá thấp tải cuối tháng.

9. RACI mẫu

10. Những vai trò không nên gộp hoàn toàn

• người sửa công và người duyệt cùng bản ghi;

• người đổi hạn mức và người phê duyệt;

• người phát/điều chỉnh giao dịch và người chốt đối soát;

• developer tự đưa thay đổi production và tự xác nhận;

• người giữ khóa ngân hàng và người quyết định mọi lệnh;

• người xử lý sự cố và người phê duyệt xóa log;

• người lập payroll và người duyệt cuối.

Ở nhóm nhỏ, có thể dùng kiểm soát bốn mắt theo thời điểm thay vì tuyển thêm ngay, nhưng không được bỏ phân tách.

11. Ca trực và on-call

Nếu hệ thống cho giao dịch 24/7 nhưng đội hỗ trợ chỉ làm giờ hành chính, phải công bố rõ:

• chức năng nào tự động 24/7;

• P1 nào có on-call;

• ticket thông thường phản hồi khi nào;

• ai nhận cảnh báo số dư/giao dịch treo;

• escalation đến VPBank;

• quyền dùng công tắc dừng;

• bàn giao giữa ca.

Không cam kết 24/7 chỉ vì ứng dụng mở được mọi lúc.

12. Runbook tối thiểu cho mỗi vai trò

(Xem thêm: Khi Lương Ngày phát sinh sự cố và Playbook xử lý khiếu nại EWA.)

HR/công

Hồ sơ sai, mã công không ghép, nghỉ việc, điều chuyển, sửa công đã duyệt.

Payment Ops

Tài khoản không khớp, giao dịch chờ, timeout, tra soát, thiếu nguồn, dừng khẩn cấp.

Đối soát

Dòng thiếu/thừa, sai số tiền, giao dịch hoàn, chênh lệch qua kỳ.

Payroll

Cut-off, giao dịch sát kỳ, trừ hai lần, hoàn sau chốt, phiếu lương lệch.

CSKH

Xác minh người hỏi, mã lý do, dữ liệu tối thiểu, SLA/escalation, nội dung trả lời.

Kỹ thuật/ATTT

Cảnh báo, rollback, bảo toàn log, P1, vi phạm dữ liệu, khôi phục.

13. KPI cho đội vận hành

Nên đo

• hồ sơ đủ điều kiện;

• công được duyệt đúng hạn;

• tỷ lệ bản ghi ghép;

• giao dịch thành công;

• tuổi giao dịch treo;

• đối soát đúng hạn;

• payroll khớp;

• thời gian phản hồi/giải quyết;

• tỷ lệ ticket tái mở;

• lỗi tiền/dữ liệu;

• hành động RCA đúng hạn.

Không nên dùng đơn độc

• số lượt rút;

• tổng tiền chi;

• số tài khoản cài app;

• số ticket đóng mà không tính tái mở/chất lượng.

KPI không được thúc đẩy người lao động giao dịch để đội đạt chỉ tiêu.

14. Nhân sự tại khách hàng/nơi làm

Mỗi khách hàng cần tối thiểu xác định:

• sponsor hoặc đầu mối quản lý;

• người quản trị danh sách;

• người duyệt công và người thay thế;

• người hỗ trợ onboarding tại ca;

• đầu mối payroll/kế toán;

• đầu mối sự cố/escalation.

Với nhiều ca, mô hình “đại sứ tại ca” giúp hướng dẫn nhưng không được giữ OTP, mật khẩu hay giao dịch thay người lao động.

15. Đào tạo theo vai trò

Mỗi khóa cần bài thực hành và kiểm tra, không chỉ gửi tài liệu.

16. Kế hoạch nhân sự khi mở rộng

(Xem thêm: Mẫu kế hoạch pilot EWA và tiêu chí mở rộng.)

Cổng 1 — Tăng người dùng

Kiểm tra CSKH, đối soát, số dư và công chờ.

Cổng 2 — Thêm khách hàng

Đánh giá khuôn công, người duyệt và đầu mối tại chỗ.

Cổng 3 — Tăng tự động hóa

Kiểm tra monitoring, on-call, dừng khẩn cấp và phân quyền.

Cổng 4 — Hỗ trợ ngoài giờ

Thiết kế ca, phụ cấp, bàn giao, escalation và sức khỏe đội trực.

Không mở rộng phạm vi trước rồi mới tuyển/bố trí người xử lý ngoại lệ.

17. Checklist tổ chức vận hành

• Có một Service Owner được bổ nhiệm.

• RACI không có hoạt động thiếu “A”.

• Người duyệt công có dự phòng.

• Payment Ops và đối soát được phân tách.

• Có người theo dõi giao dịch treo.

• Payroll tham gia từ pilot.

• CSKH có một cửa và Case Owner.

• Kỹ thuật/SRE có on-call phù hợp.

• Incident Commander được chỉ định.

• Pháp chế/ATTT có lịch review.

• Workload được đo theo loại ngoại lệ.

• Định biên tính cả giờ cao điểm/cuối kỳ.

• Mỗi vai trò có runbook.

• Đào tạo và diễn tập hoàn tất.

• Mở rộng phải qua cổng nguồn lực.

18. Câu hỏi thường gặp

Pilot 500 người có cần nhân sự chuyên trách không?

Có thể dùng nhóm kiêm nhiệm, nhưng vẫn cần Service Owner, người duyệt công, payment/đối soát, payroll, CSKH và kỹ thuật on-call được chỉ định rõ.

Hệ thống tự động rồi vì sao vẫn cần Payment Ops?

Tự động xử lý luồng chuẩn; Payment Ops giám sát nguồn tiền, giao dịch chờ, tra soát, ngoại lệ và dừng khẩn cấp.

Có cần CSKH 24/7 không?

Phụ thuộc cửa sổ giao dịch và SLA. Nếu không hỗ trợ 24/7, phải nêu rõ giờ phản hồi và vẫn có on-call cho sự cố tiền nghiêm trọng.

Ai nên làm Service Owner?

Người có quyền điều phối HR, công, tiền, payroll, kỹ thuật và khách hàng; không nhất thiết là trưởng phòng IT.

Khi nào cần tăng biên chế?

Khi backlog, tuổi ngoại lệ, SLA, overtime hoặc rủi ro phân tách nhiệm vụ vượt ngưỡng—không chỉ khi số người dùng tăng.

---

Tác giả: Ngô Nhã Kỳ — Biên tập viên ban biên tập, 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