DAILY WAGEHired TodayPaid Today

最新消息

EWA 上線後的運營：RACI、每日控制和事故管理

Doanh nghiệp · 22/09/2026 · 作者: Ngô Nhã Kỳ (Biên tập viên ban biên tập)

tat Nien Cong Ty Nhan Kiet 2019 3

EWA 上線後的運營：RACI、每日控制和事故管理

上線後，EWA 只有在企業能管理整個人事數據鏈 → 考勤 → 工時審批 → 可用額計算 → 支付 → 銀行對賬 → 工資結算時，才能持續運營。每個環節都必須有負責人、警示指標、處理期限和在狀態不明時的安全停止方案。

> 簡而言之： 上線不是項目的終點，而是從實施團隊向運營團隊轉移所有權的時刻。企業需要一個明確的 RACI、每日–每週–期末的三重控制、事故運行手冊和經批准的變更機制。

> 文章範圍： 這是建議的運營模型，不是 Nhân Kiệt 的已簽署 SLA 或流程。代碼中的頻率被記錄為系統特徵；服務目標和負責人必須由 Nhân Kiệt 正式確認。

1. 為什麼 EWA 在試點階段後容易出現問題？

(參見：Lương Ngày 試點結果：KPI 和經驗教訓 和 企業需要準備什麼來實施 Lương Ngày。)

在試點中，項目團隊通常密切跟蹤每筆交易，數據被手動清理且範圍較小。當擴展時，條件發生變化：

  • 勞動者和客戶數量增加；

  • 多個班次、工時表和單價同時運行；

  • 人員每天辭職、調動或更改代碼；

  • 項目團隊不再提醒每個記錄；

  • 銀行交易在非工作時間發生；

  • 工資單必須匯總多個周期和多個來源；

  • 配置更改可能影響數百人；

  • 支持團隊接收未參加初始培訓者的問題。

因此，一個成功的試點並不能證明模型可以在大規模運營。上線後的階段需要從“專家密切跟蹤”轉向“系統和流程可控”。

2. 確定服務擁有者

EWA 通常位於人力資源、勞動運營、工資、財務和技術之間。如果沒有一個服務擁有者，每個部門只會優化自己的部分。

服務擁有者應負責：

  • 端到端的服務目標和質量；

  • 批准標準流程；

  • 召集處理嚴重事故；

  • 決定變更優先級；

  • 監控 KPI 和風險；

  • 向管理層報告；

  • 確保事故後的行動完成。

服務擁有者不必直接處理每個工單。主要角色是確保各團隊之間沒有責任空白。

3. EWA 運營的 RACI 矩陣

企業的日薪預支運營 RACI

符號：R 執行，A 最終負責，C 諮詢，I 通知。

活動

客戶

NK 監督

工資

財務

IT/產品

客戶服務

服務擁有者

更新勞動者名單

C/R

R

I

I

C

I

A

記錄和審批工時

A/R

R

I

I

C

C

I

修改已審批工時

A/R

R

C

I

C

I

I

計算可用額

I

C

C

I

A/R

I

I

管理限額/儲備

C

C

C

C

R

I

A

處理用戶請求

I

C

C

I

C

A/R

I

處理掛起交易

I

I

C

C

A/R

R

I

銀行對賬

I

I

C

A/R

R

I

I

工資對賬

C

C

A/R

C

C

I

I

P1 事故

I

C

C

C

R

C

A

批准重大變更

C

C

C

C

R

I

A

上述矩陣是範例。對於每個客戶，Nhân Kiệt 需要記錄具體人員的姓名、電話/值班、替代人員和可用時間；僅記錄部門名稱是不夠的。

4. 上線後的三重控制

上線後的 EWA 運營

4.1. 每日：保持流程清晰

運營團隊需要監控：

  • 新同步、辭職和調動的人數；

  • 缺少連接鍵或格式錯誤的工時記錄；

  • 超過期限的待審批工時；

  • 符合條件但身份證/賬戶資料未完成的人數；

  • 成功、失敗和狀態不明的交易；

  • 按客戶支付的金額和與限額的比較；

  • 已審批工時的更改警告；

  • 與工時錯誤、可用額錯誤或未收到款項相關的工單。

每日控制的目標是發現偏差，防止其積累到期末。

4.2. 每週：尋找趨勢和原因

每週運營會議不應逐一閱讀工單。應集中於：

  • 客戶/組織的低工時審批率；

  • 根據數據來源的重複錯誤；

  • 驗證失敗率高的勞動者群體；

  • 處理掛起交易的時間；

  • 已實施的配置更改；

  • 未完成的事故後行動；

  • 勞動者反饋和引起誤解的內容；

  • 即將到來的工資期的風險。

每個問題必須有負責人、完成期限和關閉標準。

4.3. 期末：證明資金匹配

在鎖定工資單之前，需要對比：

  1. 符合條件的已審批工時總數；

  2. 已計算的可用額總數；

  3. 收到的請求總數；

  4. 成功的銀行交易總數；

  5. 納入工資對賬的總額；

  6. 差異和掛起的款項；

  7. 無法追回的款項；

  8. 期末審批的證據。

不應通過手動更改總數來關閉期末，而無法解釋每筆交易造成的差異。

5. 最低運營儀表板

組別

主要指標

管理問題

人事

新同步/辭職/調動錯誤

名單是否正確？

工時

準時審批率

工時是否及時生成可用額？

資料

身份證和 VPBank 驗證率

符合條件的人能否使用？

交易

成功/失敗/掛起

資金是否正確流動且狀態明確？

對賬

銀行差異

內部賬是否與對賬單一致？

工資

對賬差異

已收到的款項是否進入正確的工資期？

支持

每千人工單數、工單年齡

哪些問題在重複出現？

風險

重複支付、錯誤人員、無法追回

關鍵控制是否有效？

儀表板必須允許按客戶、期、狀態和原因過濾。一些系統總數可能掩蓋一個客戶的嚴重錯誤。

6. 警示閾值不應對所有客戶使用同一數字

擁有 50 名勞動者的客戶和擁有 5,000 名勞動者的客戶需要不同的警示方式。應結合：

  • 絕對閾值： 例如掛起交易的數量；

  • 比例閾值： 總交易中的錯誤百分比；

  • 時間閾值： 記錄存在超過的分鐘/小時數；

  • 金額閾值： 未對賬的總金額；

  • 異常閾值： 與歷史相比的突然增長。

所有目標數字必須在 SOP/SLA 中獲得批准。本文不代表 Nhân Kiệt 的運營。

7. 處理未審批或被修改工時的流程

(參見：客戶門戶：工時審批、班次修改、控制。)

待審批工時

  1. 按客戶、監督和記錄年齡分類。

  2. 提醒有權審批的人。

  3. 超過閾值時升級。

  4. 不從未審批的記錄中生成金額。

  5. 記錄原因：數據延遲、缺少班次、爭議或遺漏。

已審批工時被修改

在日薪預支系統中，修改已審批的時間/班次會將狀態返回待審批並記錄前後日誌。運營需要：

  • 確定是增加還是減少工時；

  • 檢查勞動者是否已從該部分工時中收到款項；

  • 重新計算可用額；

  • 將差異列入例外清單；

  • 通知正確的人；

  • 不刪除已發生交易的歷史記錄。

如果工時在支付後減少，系統會有一個無法追回款項的跟蹤賬。會計政策和勞動者處理必須由 Nhân Kiệt 批准。

8. 未明交易的運行手冊

(參見：當日薪預支出現事故時，企業如何處理。)

當應用尚未從銀行收到明確結果時，最危險的行為是立即發送一個新交易碼。運行手冊應包括：

  1. 保持請求在等待狀態；

  2. 鎖定以防止創建重複指令；

  3. 使用原始交易碼查詢；

  4. 對比代付服務反饋；

  5. 到時檢查對賬單；

  6. 只有在有證據時才轉為成功/失敗；

  7. 用不引起誤解的語言通知勞動者；

  8. 記錄確認人和依據。

系統目前有按周期和 T+1 對賬的掛賬查詢機制。這是一種安全的 fail-closed 設計：在不明確時保持等待，不猜測。

9. P1–P4 事故分級

等級

例子

反應

P1

疑似重複支付、錯誤人員、數據洩露、系統大範圍計算錯誤

停止相關流程，建立戰情室，通知領導

P2

一個客戶的工時不同步，許多交易掛起

劃定範圍，優先處理，定期更新

P3

小群體的資料或顯示錯誤

標準工單，有處理期限

P4

使用問題，改進建議

支持/產品排隊

正式定義必須附帶 SLA、聯絡人和通知渠道。不應僅根據人數評定 P1/P2；一筆錯誤交易仍可能是關鍵控制事故。

10. 嚴重事故的戰情室管理

在前 30–60 分鐘內，優先：

  • 確認事件和範圍；

  • 保護日誌/證據；

  • 停止可能造成進一步損害的部分；

  • 指定事故指揮官；

  • 分離技術、運營、傳播和法律團隊；

  • 設定更新節奏；

  • 在有數據前不猜測原因。

恢復後，需要進行 RCA，包括時間線、直接原因、系統原因、已運行/未運行的控制、修復行動和負責人。RCA 不是為了找人背鍋；目標是防止重演。

11. 配置變更管理

單價/天、限額、儲備、自動提取權限、工時來源或審批人等變更都可能影響資金。流程需要：

  1. 變更申請單說明理由和範圍；

  2. 檢查申請人是否有權限；

  3. 評估數據/資金影響；

  4. 對敏感變更的四眼原則；

  5. 在小範圍內測試；

  6. 部署和回滾計劃；

  7. 變更前後日誌；

  8. 變更後檢查；

  9. 通知相關方。

不應通過口頭或未經批准的消息直接修改生產環境。

12. 勞動者生命周期管理

新員工

同步資料，匹配身份證、考勤代碼、客戶、入職日期；完成 VPBank 的實名賬戶和使用指南。

調動

按時關閉舊分配，開啟新分配，按客戶分離工時和單價；避免一天計算兩次。

離職

按生效時間鎖定新發生的可能性；結算工時、掛起交易和已收到款項；根據批准的政策進行最終結算。

更換電話/賬戶

系統控制一人一設備，並在驗證後鎖定銀行賬戶。例外流程需要足夠強的身份驗證、日誌和比普通操作更高的權限。

13. 限額和資金來源控制

當前代碼有默認級別：每次最低 50,000 越南盾，每次最多 300 萬越南盾，每人每天 500 萬越南盾；客戶可以有儲備配置。這是技術默認，不是適合所有群體的政策。

每週或根據批准的周期，運營應查看：

  • 可用資金總額；

  • 按客戶支付的金額；

  • 資金使用水平；

  • 每人接收次數分佈；

  • 達到限額的人；

  • 儲備金額；

  • 未追回的金額和賬齡；

  • 按工資期的需求預測。

資金來源和誰承擔運營成本仍需 Nhân Kiệt 正式確認。

14. 三層對賬

(詳情：參見 EWA 與工資和會計的交易對賬。)

層 1 — 系統和交易

接收請求必須與支付指令的穩定碼、金額和接收人匹配。

層 2 — 系統和銀行

內部狀態必須與對賬單/查詢一致。差異需分類並有確認人。

層 3 — 交易和工資

按人/期支付的總額必須與結算和工資單上的對賬數一致。已覆蓋的工時必須鎖定，以免累積到下期。

只有當三層一致時，一個周期才應被視為完全關閉。

15. 供應商和依賴服務控制

EWA 可能依賴於銀行、VietQR、sFTP、客戶系統、Google Sheet、ERP 和基礎設施。服務擁有者需要維持：

  • 依賴清單和擁有者；

  • 每方承諾的服務水平；

  • 升級聯絡人；

  • 服務中斷時的方案；

  • 變更/維護計劃；

  • 定期風險評估證據。

如果沒有備份或補償流程，整體 SLA 不可能優於最弱的環節。

16. 建議的會議和報告時間表

節奏

成員

輸出

每日 15 分鐘

運營、支持、技術

例外、負責人、處理期限

每週

服務擁有者和各領導

KPI 趨勢、風險、變更

工資前

工資、財務、運營

差異清單和鎖定條件

每月

贊助商/客戶

服務報告和改進計劃

每季

管理層、風險、法律

效率、控制、擴展決策

小規模可以合併節奏，但不能省略控制輸出。

17. 常見問題

上線後誰負主要責任？

應有一個服務擁有者負責端到端；每個環節仍在 RACI 中有具體的 R/A。

未明交易是否應讓勞動者重試？

在用原始碼查詢並確定初始指令未成功之前，不應重試。目標是避免重複支付。

已審批的工時被修改怎麼辦？

系統將工時返回待審批並記錄痕跡。運營必須檢查對可用額、已支付交易和工資的影響。

30 分鐘同步計劃是 SLA 嗎？

不是。這是當前 Google Sheet 資源的技術計劃；SLA 必須以書面形式規定目標、測量方法、排除和責任。

什麼時候應使用緊急停止開關？

當有資金損失風險、大範圍計算錯誤、重複支付、數據洩露或無法確定安全狀態時。停止/重新啟動的權限必須事先規定。

18. 結論

EWA 上線後的運營是一個紀律問題，而不是增加功能的問題。一個好的模型必須知道每天早上需要查看什麼，每週末需要修正什麼，期末需要證明什麼，以及當事故發生時誰有權停止系統。當 RACI、儀表板、運行手冊和變更管理一起運作時，企業才能在擴展 EWA 的同時保持正確的人、正確的工時、正確的資金和正確的周期。

---

作者： Ngô Nhã Kỳ — Biên tập viên ban biên tập, Nhan Kiet Manpower Supply Co., Ltd.

企業日薪預支解決方案諮詢： 熱線 0937.022.655 · 電郵 info@nhankiet.vn · 企業日薪預支

← 最新消息