Các lỗi thường gặp trong 30 ngày đầu sau go-live EWA và cách xử lý

Trong 30 ngày đầu sau go-live, lỗi thường không chỉ nằm ở phần mềm mà xuất hiện ở giao điểm giữa dữ liệu công, hồ sơ người lao động, chính sách, tài khoản nhận, giao dịch ngân hàng và payroll. Cách xử lý tốt nhất là phân loại lỗi theo nguồn, có owner rõ, ưu tiên những lỗi ảnh hưởng tiền và dùng nhịp hypercare hằng ngày để ngăn sai lệch tích tụ đến cuối kỳ.

Vì sao 30 ngày đầu dễ phát sinh lỗi hơn giai đoạn UAT?

UAT sử dụng tập dữ liệu và kịch bản đã chuẩn bị.

Sau go-live, môi trường thực tế khác hẳn:

• dữ liệu đến từ nhiều nguồn;
• người lao động mới liên tục phát sinh;
• có nghỉ việc và điều chuyển;
• giám sát duyệt công không đều;
• người dùng đổi thiết bị;
• tài khoản có trường hợp sai;
• giao dịch xuất hiện vào nhiều thời điểm;
• payroll phải xử lý dữ liệu thật cuối kỳ.

Do đó, 30 ngày đầu cần được xem là giai đoạn hypercare có kiểm soát, chưa chuyển thẳng sang nhịp vận hành thông thường.

Lỗi 1: Người lao động đủ điều kiện nhưng không thấy chức năng

Biểu hiện:

• đăng nhập được nhưng không thấy Lương Ngày;
• thấy sai khách hàng;
• không có số tiền;
• trạng thái “chưa đủ điều kiện”.

Nguyên nhân thường gặp:

• hồ sơ chưa active;
• assignment chưa đồng bộ;
• khách hàng chưa bật;
• mã người không ghép;
• policy chưa áp đúng phạm vi.

Cách xử lý:

1. kiểm tra danh tính;
2. kiểm tra assignment;
3. kiểm tra policy version;
4. kiểm tra trạng thái tính năng;
5. ghi reason code;
6. sửa nguồn đúng chỗ.

Không nên bật tay cho từng người nếu lỗi đến từ mapping hệ thống.

Lỗi 2: Công đã làm nhưng chưa tạo số tiền có thể nhận

Nguyên nhân có thể là:

• công chưa duyệt;
• dữ liệu chưa đồng bộ;
• mã chấm công sai;
• ca đêm bị đọc sai;
• công bị giữ vì bản ghi trùng;
• công vừa bị sửa và đang chờ duyệt lại.

Cách xử lý:

• xác định nguồn công;
• kiểm tra trạng thái;
• phân loại theo khách hàng/giám sát;
• không tự tạo số khả dụng bằng tay;
• ưu tiên sửa quy trình duyệt nếu lỗi lặp lại.

Nếu công chưa duyệt, đây không phải lỗi “tiền”, mà là lỗi quy trình trước tiền.

Lỗi 3: Số tiền hiển thị thay đổi khiến người lao động thắc mắc

Điều này có thể xảy ra khi:

• có thêm công được duyệt;
• công bị sửa;
• giao dịch trước vừa thành công;
• khoản đã nhận tăng;
• policy thay đổi;
• phần giữ thay đổi.

Đội hỗ trợ cần có khả năng giải thích bằng audit trail.

Không nên trả lời:

> “Hệ thống tự tính.”

Nên trả lời theo dữ liệu:

> “Ngày công X vừa được điều chỉnh và duyệt lại, vì vậy số tiền hiện tại được tính lại.”

Lỗi 4: Tài khoản nhận không xác minh được

Các trường hợp:

• sai tên;
• sai số;
• tài khoản không hoạt động;
• người dùng nhập nhầm;
• dữ liệu hiển thị bị cũ.

Cách xử lý:

• không cho chi;
• yêu cầu xác minh lại;
• không cho support tự sửa tài khoản nếu thiếu quyền;
• ghi log mọi thay đổi;
• kiểm tra quy trình đổi tài khoản.

Đây là lỗi cần ưu tiên vì ảnh hưởng trực tiếp người nhận tiền.

Lỗi 5: Giao dịch pending kéo dài

Đây là lỗi phổ biến và dễ bị xử lý sai.

Nguy hiểm nhất là:

• người dùng bấm lại;
• support tạo lệnh mới;
• hệ thống tự retry bằng mã khác.

Cách đúng:

1. giữ trạng thái pending;
2. khóa phần giá trị;
3. tra soát bằng mã giao dịch gốc;
4. kiểm tra phản hồi ngân hàng;
5. đối chiếu sao kê;
6. chỉ kết luận khi có bằng chứng.

Đây là fail-closed.

Lỗi 6: Hai yêu cầu gần nhau gây nghi chi trùng

Biểu hiện:

• cùng người;
• cùng số tiền;
• thời gian sát nhau;
• một giao dịch chưa chốt.

Cần kiểm tra:

• request ID;
• idempotency key;
• transaction ID;
• trạng thái ngân hàng;
• số khả dụng trước/sau;
• concurrency lock.

Không nên xóa một giao dịch để “cho đẹp”.

Nếu có chi trùng thật, phải giữ bằng chứng, điều tra nguyên nhân và xử lý theo chính sách đã phê duyệt.

Lỗi 7: Công bị sửa sau khi tiền đã chi

Đây là ngoại lệ thường chỉ lộ ra khi dữ liệu thật bắt đầu thay đổi.

Quy trình:

1. giữ lịch sử giao dịch;
2. đưa công về trạng thái cần duyệt lại;
3. tính lại;
4. xác định chênh lệch;
5. đưa vào đối soát;
6. xử lý theo policy.

Không nên sửa ngược lịch sử tiền đã chi.

Lỗi 8: Một người làm nhiều nơi bị cộng nhầm công

Dấu hiệu:

• công A dùng đơn giá B;
• cùng ngày xuất hiện ở hai nơi;
• tổng số khả dụng tăng bất thường;
• payroll không biết giao dịch thuộc nơi nào.

Cần kiểm tra:

• CCCD;
• company_id;
• mã chấm công;
• assignment;
• ngày hiệu lực;
• đơn giá.

Nguyên tắc là tách trước, tính riêng, rồi mới tổng hợp.

Lỗi 9: Dữ liệu Google Sheet thay đổi cấu trúc

Ví dụ:

• chèn cột;
• đổi tên cột;
• mất số 0 đầu ở mã công;
• đổi định dạng ngày;
• gộp ô;
• thay ký hiệu công.

Nếu parser vẫn cố đoán, dữ liệu có thể đi sai.

Cách xử lý:

• phát hiện schema khác;
• giữ bản ghi ở ngoại lệ;
• kiểm tra mapping;
• cập nhật cấu hình có phê duyệt;
• không tự suy luận khi chưa chắc.

Lỗi 10: Số liệu hệ thống và sao kê không khớp

Có thể xảy ra:

• hệ thống success nhưng sao kê chưa có;
• sao kê có nhưng hệ thống pending;
• số tiền lệch;
• mã tham chiếu không khớp;
• giao dịch trùng.

Reconciliation phải phát hiện và tạo exception.

Không sửa tay một bên chỉ để tổng khớp.

Lỗi 11: Khoản đã nhận không vào đúng payroll

Đây là lỗi nghiêm trọng cuối chuỗi.

Có hai rủi ro:

Giao dịch thành công nhưng payroll không trừ

Người lao động có thể nhận lại phần đã nhận trước.

Payroll trừ nhưng giao dịch không thành công

Người lao động có thể bị giảm tiền dù chưa nhận.

Do đó, báo cáo cầu nối phải nối:

người + kỳ + transaction ID + số tiền + trạng thái

Lỗi 12: Support trả lời không thống nhất

Một lỗi vận hành thường bị xem nhẹ là mỗi người giải thích một kiểu.

Ví dụ:

• người nói pending là thất bại;
• người nói công chưa duyệt vẫn sẽ có tiền;
• người nói người lao động cứ gửi lại yêu cầu;
• người nói lỗi tài khoản phải liên hệ ngân hàng dù lỗi nằm ở hồ sơ.

Cần:

• knowledge base chung;
• reason code;
• script theo trạng thái;
• escalation rõ;
• không tự suy luận.

Lỗi 13: Có quá nhiều việc sửa tay

Trong tuần đầu, một số manual workaround có thể được chấp nhận.

Nhưng nếu sau 2–3 tuần vẫn phải:

• sửa mã thủ công;
• cập nhật công bằng tay;
• tải file bằng tay;
• đối soát bằng copy-paste;
• mở quyền bằng ticket;

thì đây là tín hiệu hệ thống chưa sẵn sàng mở rộng.

Mọi workaround cần có:

• owner;
• ngày hết hạn;
• kế hoạch sửa gốc;
• rủi ro.

Lỗi 14: Không biết lỗi nào là P1, P2 hay P3

Nếu mọi ticket đều “khẩn”, đội vận hành sẽ mất ưu tiên.

Một khung gợi ý:

Mức	Ví dụ
P1	Chi trùng, sai người, sai tiền diện rộng, rủi ro dữ liệu cần bảo vệ
P2	Một khách hàng lỗi công, nhiều pending, payroll lệch
P3	Một người sai hồ sơ, hiển thị sai nhưng không ảnh hưởng tiền
P4	Câu hỏi cách dùng, đề nghị cải tiến

Mức chính thức phải được doanh nghiệp phê duyệt.

Lỗi 15: Mở rộng quá nhanh khi lỗi gốc chưa đóng

Một pilot hoặc wave đầu có thể vẫn “trông ổn” nếu đội dự án sửa tay rất nhiều.

Nếu mở rộng ngay:

• lỗi mapping nhân lên;
• support quá tải;
• đối soát khó;
• payroll tăng ngoại lệ.

Chỉ nên mở wave mới khi lỗi trọng yếu đã có permanent fix.

Nên tổ chức 30 ngày đầu theo nhịp nào?

Tuần 1 — Kích hoạt và định danh

Tập trung:

• hồ sơ;
• assignment;
• tài khoản;
• login;
• activation.

Tuần 2 — Dữ liệu công

Tập trung:

• mapping;
• duyệt;
• ca;
• công sửa;
• dữ liệu trùng.

Tuần 3 — Giao dịch

Tập trung:

• success/failed/pending;
• timeout;
• idempotency;
• support.

Tuần 4 — Payroll

Tập trung:

• đối soát;
• cut-off;
• báo cáo cầu nối;
• phiếu lương;
• chênh lệch.

Không có nghĩa lỗi chỉ xuất hiện ở tuần tương ứng; đây là trọng tâm quản trị.

Daily hypercare nên nhìn gì?

Mỗi ngày nên có một bảng ngắn:

• số người active;
• số người lỗi hồ sơ;
• số công chờ;
• số công sửa;
• giao dịch success/failed/pending;
• transaction exception;
• chênh lệch sao kê;
• ticket;
• lỗi mới;
• lỗi tái diễn;
• owner;
• ETA nội bộ nếu có.

Không cần họp dài; cần owner và quyết định rõ.

Khi nào lỗi được coi là đóng?

Một lỗi chỉ nên đóng khi:

1. triệu chứng đã hết;
2. dữ liệu được sửa đúng;
3. giao dịch/payroll đã xử lý nếu bị ảnh hưởng;
4. nguyên nhân gốc được xác định với lỗi quan trọng;
5. có hành động ngăn tái diễn;
6. bằng chứng được lưu.

Không nên đóng chỉ vì người dùng “không hỏi nữa”.

KPI 30 ngày đầu nên theo dõi

• tỷ lệ kích hoạt thành công;
• tỷ lệ hồ sơ lỗi;
• tỷ lệ công duyệt đúng nhịp;
• số công sửa sau duyệt;
• tỷ lệ giao dịch pending;
• số duplicate signal;
• chênh lệch đối soát;
• số payroll exception;
• ticket/1.000 người;
• tỷ lệ lỗi tái diễn;
• thời gian xử lý theo loại;
• số workaround còn mở.

Mục tiêu là thấy xu hướng ổn định dần, không chỉ tổng giao dịch tăng.

Kết luận

30 ngày đầu sau go-live là giai đoạn hệ thống chuyển từ “đã kiểm thử” sang “đang chịu dữ liệu và hành vi thật”. Những lỗi thường gặp nhất nằm ở hồ sơ, công, tài khoản, pending, chi trùng, multi-workplace, đối soát và payroll. Doanh nghiệp nên xử lý theo nguyên tắc: phân loại đúng nguồn, một owner rõ, bảo toàn bằng chứng, ưu tiên lỗi tiền và chỉ đóng khi có permanent fix hoặc kiểm soát được rủi ro.

Tác giả: Đỗ Huy Lê — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

Tư vấn Lương Ngày cho doanh nghiệp: Hotline 0937.022.655 · Email info@nhankiet.vn · Tìm hiểu Lương Ngày cho doanh nghiệp