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、每日-每周-期末的三阶段控制、事件运行手册以及经过批准的变更机制。

> 文章范围： 这是一个建议的运营模型，不是Nhan Kiet签署的SLA或流程。代码中的频率被记录为系统特性；服务目标和责任人必须由Nhan Kiet正式确认。

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

上述矩阵为样本。对于每个客户，Nhan Kiet需要记录具体人员姓名、电话/随叫随到、替代人员和可用时间；仅记录部门名称是不够的。

4. 上线后的三阶段控制

上线后的EWA运营

4.1. 每日：保持流程清晰

运营团队需要监控：

  • 新同步、离职和调动人数；

  • 缺少连接键或格式错误的考勤记录；

  • 超过时限的待审批工时；

  • 符合条件但身份证/账户未完成的人员；

  • 成功、失败和状态不明确的交易；

  • 按客户支付的金额和与限额的比较；

  • 已审批工时的变更警告；

  • 涉及错误工时、错误可用金额或未收到款项的工单。

每日控制的目标是在期末前发现偏差。

4.2. 每周：寻找趋势和原因

每周运营会议不应逐条阅读工单。应集中于：

  • 工时审批率低的客户/组；

  • 数据源重复错误；

  • 验证失败率高的劳动者群体；

  • 挂起交易的处理时间；

  • 已实施的配置更改；

  • 未完成的事件后行动；

  • 劳动者反馈和引起误解的内容；

  • 即将到来的工资单周期的风险。

每个问题都必须有负责人、完成期限和关闭标准。

4.3. 期末：证明资金匹配

在锁定工资单之前需要对比：

  1. 符合条件的已审批工时总数；

  2. 已计算的可用金额总数；

  3. 总请求金额；

  4. 成功的银行交易总数；

  5. 纳入工资对账的总金额；

  6. 差异和挂起金额；

  7. 无法追回的金额；

  8. 期末审批的痕迹。

不应通过手动更改总数来关闭周期，而无法解释每笔交易造成的差异。

5. 最低限度的运营仪表板

组别

关键指标

管理问题

人力资源

新同步/离职/调动错误

名单上是否有正确的在职人员？

工时

按时审批率

已完成的工时是否及时生成可用金额？

档案

身份证和VPBank验证率

符合条件的人是否可以使用？

交易

成功/失败/挂起

资金是否正确流动且状态明确？

对账

银行差异

内部账簿是否与对账单匹配？

工资单

对账差异

已收到的金额是否进入正确的工资周期？

支持

每千人工单数，工单年龄

哪些问题正在重复出现？

风险

重复支付、错误人员、无法追回

关键控制是否有效？

仪表板必须允许按客户、周期、状态和原因进行筛选。某些系统总数可能会掩盖某个客户的严重错误。

6. 警示阈值不应为所有客户使用同一数字

拥有50名劳动者的客户和拥有5000名劳动者的客户需要不同的警示方式。应结合：

  • 绝对阈值： 例如挂起交易数量；

  • 比例阈值： 错误占总交易的百分比；

  • 时间阈值： 记录存在超过分钟/小时数；

  • 金额阈值： 未对账的总金额；

  • 异常阈值： 与历史相比的突然增加。

所有目标数字必须在SOP/SLA中获得批准。本文不代替Nhan Kiet的运营。

7. 未审批或被修改工时的处理流程

(查看更多：客户门户：工时审批、班次修改、控制。)

待审批工时

  1. 按客户、监督和记录年龄分类。

  2. 提醒有权审批的人。

  3. 超过阈值时升级。

  4. 不从未审批记录中生成金额。

  5. 记录原因：数据延迟、缺少班次、争议或遗漏。

已审批工时被修改

在日薪预支系统中，修改已审批的时间/班次会将状态返回到待审批，并记录前后日志。运营需要：

  • 确定是增加还是减少工时；

  • 检查劳动者是否已从该部分工时中收到款项；

  • 重新计算可用金额；

  • 将差异列入例外清单；

  • 通知正确的人；

  • 不删除已发生交易的历史记录。

如果工时在支付后减少，系统会有未追回金额的跟踪记录。记账政策和劳动者处理必须由Nhan Kiet批准。

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万越南盾；客户可以配置保留储备。这是技术默认值，不是适合所有群体的政策。

每周或根据批准的周期，运营应查看：

  • 可用金额总数；

  • 按客户支付的金额；

  • 资金使用情况；

  • 每人领取次数分布；

  • 达到限额的人；

  • 保留储备金额；

  • 未追回金额和金额年龄；

  • 工资周期的需求预测。

资金来源和运营成本承担者仍需Nhan Kiet正式确认。

14. 三层对账

(详情：见EWA交易与工资单和会计对账。)

第一层 — 系统与交易

请求金额必须与支付命令的稳定代码、金额和接收人匹配。

第二层 — 系统与银行

内部状态必须与对账单/查询匹配。差异被分类并有确认人。

第三层 — 交易与工资单

按人/周期支付的总金额必须与结算和工资单上的对账金额匹配。已覆盖的工时必须被锁定，以免累加到下一个周期。

只有当三层匹配时，一个周期才应被视为完全关闭。

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 · 企业日薪预支

← 新闻