日薪预支(EWA)试点计划模板与扩大标准

一份日薪预支（EWA）试点计划需要事先明确目标、目标员工群体、时间安排、额度政策、对接数据、职责分工、预算、KPI以及终止条件。参考流程共分六个阶段：准备、设计、系统对接、UAT、受控运营与评估。试点结束时，企业不应只在“扩大”或“不扩大”之间二选一，而应作出四种可能的决策之一：推广（Go）、调整（Adjust）、延长（Extend）或终止（Stop）。该决策必须基于员工价值、人力资源影响、运营质量、成本与风险综合判断。

> 说明： 本文为实施框架模板，并非日薪预支(EWA)在时间安排或功能方面的任何承诺。具体日程、规模、KPI阈值、法律角色、收费政策、资金来源及结算流程，需由Nhan Kiet Manpower Supply Co., Ltd.与企业在正式试点文件中共同确认。

> 术语说明： EWA（按已完成工时预支工资）· pilot（试点/试运行）· UAT（用户验收测试）· RACI（角色分工矩阵：执行(Responsible)–最终负责(Accountable)–咨询(Consulted)–知情(Informed)）· KPI（关键绩效指标）· cutoff（结算截止时点）· go-live（正式上线运营）· project charter（项目章程）· baseline（基线）· wave（扩大批次/波次）· Go–Adjust–Extend–Stop（推广–调整–延长–终止）。

什么是日薪预支(EWA)试点？

EWA试点是一个范围有限的实施阶段，目的是在正式扩大之前验证一组假设。其范围可按法人实体、工厂、员工群体、考勤系统、薪资周期、人数或时间加以限定。

试点不应被当作“无需管控的试运行”。员工进行的仍是真实交易，薪资与账户数据依然敏感，资金流与payroll仍须对账。因此，试点需要具备与正式运营环境同等完整的关键管控措施，只是范围有所限定，以便快速学习并在出现问题时降低影响面。

一个优质试点必须回答五个问题

1. 员工是否理解并能够使用EWA？

2. 考勤、薪资及员工状态数据是否足够可靠？

3. 交易是否得到正确处理与对账？

4. 该计划是否产生了人力资源或福利方面的价值信号？

5. 成本、风险与运营量是否适合扩大规模？

1. 企业何时才算准备好开展试点？

不应仅因为合同已签署或应用程序已上线就启动试点。最低准入条件包括：

目标方面

• 存在一个具体的、需要解决的经营或员工问题；

• 有可衡量的假设；

• 有具备足够权限的项目发起人（Sponsor）；

• 各部门就“试点成功”与“试点失败”的标准达成一致。

数据方面

• 拥有统一的员工编号；

• 用工状态按时更新；

• 考勤或工时具有清晰的审批状态；

• 薪资周期、cutoff及薪资规则已明确定义；

• EWA交易可与payroll及付款相关联；

• 数据质量已在真实样本上完成检验。

运营方面

• 有明确的流程责任人及支持窗口；

• 已建立处理未审批工时、错误账户、挂起交易及投诉的流程；

• 具备日结与期末对账机制；

• 具备按权限锁定/解锁账户的机制；

• 已制定系统或支付中断时的应对方案。

法律与安全方面

• 合同模式及各方责任已完成审查；

• 向员工提供的信息清晰明确；

• 数据范围、处理目的、存储与共享已获批准；

• 权限管理、身份验证、加密、日志记录及事件响应机制均已就绪；

• 各方均明确事件发生时的协调窗口。

若上述条件尚未达标，企业应将此阶段视为准备期处理，而不是为“赶进度”而勉强引入真实交易。

2. 在选择KPI之前先写出试点假设

一个好的假设包含四个部分：对象、变化、预期结果与衡量条件。

结构示例

> 对于[单位]符合条件的员工群体，在[时间]内按[政策]提供EWA，预期能够带来[结果]，同时仍维持[相关运营与风险阈值]。

示例说明

> 对于A工厂已完成试用期的生产工人，预期EWA能够提升其应对短期支出的主动性，并减少人工借支申请；同时交易须在已获批准的内部目标范围内完成处理、对账与支持。

该示例并未给出假定的改善比例。数值目标应基于企业自身的基线数据构建，而非照搬营销资料或其他客户的数据。

3. 选择“足够小以便管控、足够大以便学习”的试点范围

试点单位选择标准

• 单位负责人愿意配合；

• 考勤流程相对稳定；

• 员工群体的需求与试点目标相符；

• payroll与HR能够按时提供数据；

• 具备现场或远程支持团队；

• 未同时进行过多系统/政策变更；

• 如需评估影响，能够建立合适的对照组。

不应仅因为“最容易”而选择

过于理想化的单位可能使试点“顺利成功”，却无法代表未来将要扩大的场景。反之，一开始就选择最困难的场景，可能使项目组无法区分究竟是产品问题还是基础数据问题。

较为平衡的做法是选择复杂度适中的范围，并明确记录其与企业整体之间的差异：班次类型、发薪方式、收款银行、地域、工龄、合同类型及考勤系统。

范围描述表

4. 试点六阶段路线图

（按天细化的版本，参见企业日薪预支(EWA)90天试点计划。）

```mermaid
flowchart TD
A["1. 准备"] --> B["2. 设计"]
B --> C["3. 系统对接"]
C --> D["4. UAT与演练"]
D --> E["5. 试点运营"]
E --> F["6. 评估与决策"]
```

每个阶段的时长取决于准备程度。在完成数据与系统调研之前，不应先行承诺统一的时间表。

5. 第1阶段——准备与立项审批

主要工作

1. 明确目标与假设；

2. 选定范围及对照组；

3. 组建指导委员会与项目团队；

4. 确定预算与资源；

5. 建立初始风险登记表；

6. 收集基线数据；

7. 完成法律、数据及合同层面的审查；

8. 就试点结束时的决策标准达成一致。

交付成果

• 项目章程（Project Charter）；

• 范围说明；

• 相关方名单；

• RACI矩阵；

• 一套KPI体系及基线数据；

• 风险登记表；

• 宣导沟通计划；

• 各阶段的准入/退出标准。

通过关卡的条件

若尚未有政策审批人、数据责任人以及对payroll/对账最终负责的人员，则不应进入详细设计阶段。

6. 第2阶段——政策与流程设计

需要确定的政策

• 符合条件的对象；

• 允许参与的用工状态；

• 符合条件的工时或收入类型；

• 额度计算公式及上限；

• 交易次数限制；

• 收费政策及费用承担方；

• 适用的周期/cutoff；

• 离职、休假及工时调整的处理方式；

• 交易失败、状态不明或退款的处理方式；

• 交易如何计入payroll及会计系统。

员工使用旅程

1. 接收信息；

2. 注册/激活；

3. 身份验证；

4. 查看额度；

5. 选择金额；

6. 确认前查看完整信息；

7. 交易验证；

8. 获取状态；

9. 到账，或在出错时获得指引；

10. 查看历史记录及相关结算信息。

运营流程旅程

需要为HR、审批考勤的主管、Payroll、Finance、IT、支持团队、风险管理（Risk）及支付合作方分别设计流程。良好的员工端体验，无法弥补一个缺乏责任人的内部流程。

7. 第3阶段——数据与系统对接

（数据需求与架构详见EWA与考勤、payroll及ERP系统对接以及EWA交易与payroll、会计系统的对账。）

最低数据集

• 员工及用工状态；

• 法人实体、单位、薪资组；

• 考勤/工时及审批状态；

• 薪资周期、cutoff及所需规则；

• 位于安全处理域内的收款账户；

• EWA交易记录；

• 支付状态；

• 用于对账的payroll/ERP数据。

技术决策

• 采用近实时API、批量文件/SFTP，还是其他受控方式；

• 身份标识键及映射表；

• 数据版本管理及迟到数据的处理；

• 幂等性及防重复文件机制；

• 交易状态定义；

• 重试、超时及告警机制；

• 对账及差异报告；

• 权限管理、日志与存储。

UAT前的数据质量检查

不应在测试环境中使用未加保护的真实数据。测试数据须经过适当的模拟或脱敏处理。

8. 第4阶段——UAT与演练

UAT必须同时检验正常流程与异常场景。

员工场景组

• 成功激活；

• 身份信息错误或缺失；

• 更换设备、手机号码或收款账户；

• 因工时未审批而无可用额度；

• 申请超出额度；

• 交易成功、失败及处理中三种状态；

• 对非本人发起交易的投诉；

• 员工离职或调岗。

数据场景组

• 审批后又被修改的考勤记录；

• 旧版本数据延迟到达；

• 文件重复或顺序错误；

• 部分记录出错；

• 员工编号映射错误；

• 薪资周期或cutoff错误；

• 源数据暂停更新。

支付场景组

• 使用相同的idempotency_key重复发送；

• 在指令发出前后发生超时；

• 回调（callback）延迟到达、重复或签名错误；

• 收款账户无效；

• 合作方反馈结果不明；

• 交易先成功后又被退款。

Payroll与会计场景组

• 交易被计入正确的周期；

• 已录入的交易被拦截重复录入；

• 总额与逐笔交易能够对上；

• cutoff之后发生的调整处理；

• 差异生成case并有人负责跟进；

• ERP/凭证可追溯至具体交易。

事件演练

至少应演练以下情形：

• 员工账户被盗用；

• 转账错误或疑似重复扣款；

• 大范围考勤同步故障；

• 数据文件泄露；

• 临近薪资发放期的服务中断；

• 支付合作方无响应。

每次演练都必须记录：由谁决定锁定流程、由谁负责通知、哪些数据需要保全，以及恢复的判定标准。

9. 试点上线（go-live）的条件

必须满足的条件

• [ ] 范围及符合条件名单已获批准。

• [ ] 额度、费用、cutoff及例外处理政策已确定。

• [ ] 业务、系统对接、安全及对账方面的UAT均已达标。

• [ ] 严重缺陷已修复并复测。

• [ ] 初始数据已完成对账。

• [ ] 支持及升级（escalation）窗口已就绪。

• [ ] 具备日度报告及运营告警机制。

• [ ] 回滚或暂停方案已完成演练。

• [ ] 面向员工的信息告知已获批准。

• [ ] 具有权限的负责人已签署上线决定。

不应仅因试点人数少而放行一个严重缺陷。小规模试点只是缩小了影响范围，并不能降低保护员工与资金安全的责任。

10. 第5阶段——受控试点运营

初期“超密切关注（hypercare）”机制

在初期阶段，各方应保持更密集的跟踪节奏：

• 检查考勤及额度数据；

• 跟踪错误/状态不明的交易；

• 当日完成对账；

• 快速召开会议处理阻塞问题（blocker）；

• 统一维护一份问题（issue）清单；

• 对受影响用户保持透明沟通；

• 记录临时应对措施与根本解决方案。

无需公布固定的hypercare时长。当数据、交易及支持已依据既定标准趋于稳定后，可相应降低跟踪频率。

决策日志

试点期间的每一次政策变更都应记录：

• 问题；

• 支撑数据；

• 所选方案；

• 审批人；

• 生效日期；

• 受影响群体；

• 变更后的衡量方式；

• 回退方案。

若同时改动过多变量，企业将无法判断究竟是哪一项变化产生了效果。

11. EWA试点RACI矩阵模板

符号说明：R——执行；A——最终负责；C——需咨询；I——需知情。

以上仅为示例模板。企业须根据真实组织架构调整，并确保每项工作都只有一个明确的最终负责角色。

12. 均衡的试点KPI体系

（完整指标体系参见如何用KPI衡量EWA的成效？以及EWA实施的ROI如何计算。）

触达与使用类KPI

• 符合条件人员比例；

• 信息触达率；

• 激活启动率及完成率；

• 额度可见比例；

• 活跃用户比例；

• 按cohort统计的交易频次与金额。

体验类KPI

• 交易成功率；

• 到账时间的中位数及分位数；

• 各步骤的放弃率；

• 每千笔交易的工单量；

• 响应及解决时长；

• 满意度及对费用/条款的理解程度。

人力资源类KPI

• 人工借支申请量；

• 缺勤及未报备缺勤情况；

• 按cohort统计的离职率；

• 新员工出勤率；

• 该福利的认知度及感知价值。

运营类KPI

• 按时审批的考勤比例；

• 数据新鲜度；

• 自动化处理比例；

• 自动对账比例；

• 按来源统计的数据错误；

• cutoff后的调整数量；

• 差异关闭所需时长。

财务与风险类KPI

• 总拥有成本；

• 按符合条件人数/活跃用户/交易笔数分摊的成本；

• 状态不明交易；

• 差异比例及金额；

• 已确认的欺诈案例；

• 误拦截比例；

• 安全或数据事件；

• 超期的访问权限及例外情况。

13. 结果类KPI与保护类KPI

结果类KPI说明该计划创造了什么价值；保护类KPI则防止项目组以制造其他风险的方式来达成目标。

若业务类KPI达标而保护类KPI超出可接受水平，则不应扩大规模。

14. 如何设定KPI目标？

第一步：获取基线数据

在试点前，用统一的口径衡量数据：离职率、缺勤率、借支申请量、payroll工单量、处理时长及成本。

第二步：确定强制性最低标准

例如：不得出现重复扣款、不得存在未处理的严重安全漏洞、状态不明交易须有人负责跟进、payroll必须可对账。这些是管控性条件，而非增长性目标。

第三步：设定改善目标

基于基线数据、系统能力及试点范围设定。每项目标都应明确数据来源、计算公式、责任人及衡量时点。

第四步：设定预警阈值与终止阈值

预警阈值用于触发调查；终止阈值则依据授权级别触发暂停某一流程，或暂停整个试点。

第五步：上线前完成审批

不应仅为迎合已发生的结果而在事后更改试点结束标准。若确有正当理由需要更改，必须记录在决策日志中。

15. 试点终止或暂停的标准

计划应事先明确：在什么情况下需要停止接受新交易、暂停某一群体，或终止整个项目。

以下事件可能触发紧急审议：

• 大范围出现疑似重复扣款或转错收款人；

• 考勤/薪资数据错误导致额度不可信；

• UNKNOWN状态交易累积超出可控能力；

• 存在尚未隔离的严重安全漏洞；

• 数据超出授权范围被泄露或滥用；

• payroll无法在结算周期截止前完成对账；

• 资金来源或支付合作方发生中断；

• 投诉数量异常增长；

• 欺诈防控机制误拦截大量合规用户；

• 项目团队已不再具备安全支持的能力。

具体的数值阈值应保留在内部计划中，若公开可能削弱管控效果，则不应对外发布。

暂停不同于终止

暂停是在保留数据、交易记录及证据的同时，先行保护用户并展开调查；终止试点则是评估之后作出的治理决定。流程中必须明确：谁有权决定暂停、谁负责批准恢复，以及如何向员工通报。

16. 第6阶段——试点结束评估

评估应同时使用定量数据与定性证据。

定量数据

• 试点前、试点中及试点结束时的KPI；

• 与基线数据的对比；

• 与可比对照组的对比（如有）；

• 按cohort、单位及使用旅程划分的结果；

• 总成本及收益假设；

• 事件、差异及剩余风险。

定性数据

• 对使用及未使用该计划的员工进行访谈；

• 主管、HR、Payroll、Finance及支持团队的反馈；

• 用户流失（漏斗脱落）的原因；

• 难以规模化的人工操作环节；

• 尚未在dashboard上体现的问题；

• 从事件与例外情况中获得的经验教训。

不要急于下因果结论

若离职率下降，需要一并考察季节性、订单量、薪酬、奖金、管理方式及其他政策因素。若使用EWA的员工离职率反而更高，也可能是因为该群体本身面临更大的财务压力、原本风险就较高。当试点设计尚不足以确认因果关系时，报告应使用“观察到差异/信号”这类措辞。

17. 推广（Go）–调整（Adjust）–延长（Extend）–终止（Stop）决策矩阵

建议的“推广（Go）”条件

• 核心价值目标已达成，或已有足够有力的证据；

• 已无未修复的严重缺陷；

• 交易、payroll及会计能够顺利对账；

• 每人/每笔交易的支持工作量呈可控趋势；

• 扩大所需成本已充分测算；

• 员工理解相关政策并有支持渠道可用；

• 剩余风险已有责任人，并获得有权限人员的接受；

• 系统架构能够支撑更大规模；

• 下一步扩大的单位已就与试点单位的差异进行过评估。

若仅使用类KPI达标，而安全、对账或对员工的透明度未达标，则尚不具备“推广（Go）”的条件。

18. 分批次（wave）扩大计划

若各单位、系统或政策之间差异较大，不应从一个小规模试点一次性跳跃到全企业推广。

批次（wave）设计

每个批次应将特征相近的单位归为一组：

• 使用相同的考勤/payroll系统；

• 属于同一法人实体或适用同一政策；

• 班次分组及计薪方式相同；

• HR/主管的准备程度相近；

• 使用相同的支持渠道；

• 支付复杂度相近。

每批次（wave）开始前的关卡

• 数据及映射关系已完成检查；

• 支持团队具备足够能力；

• 上一批次遗留的问题已处理完毕；

• 对账及dashboard已完成扩展；

• 新范围内的访问权限已完成审查；

• 沟通宣导内容已针对目标群体调整；

• 回滚方案已就绪；

• 已获得有权限人员的批准。

每批次（wave）之后的跟踪

不应只与最初的试点结果做比较。不同单位在激活率、数据错误、收款银行及使用行为上可能各不相同。应按批次分别比较，并及时发现随规模扩大而出现的绩效下滑。

19. 简化版项目章程（Project Charter）模板

1. 项目名称

[单位]日薪预支(EWA)试点。

2. 需要解决的问题

描述基础数据、受影响群体及当前的影响状况。

3. 目标与假设

记录预期结果及相应的保护类KPI。

4. 范围

法人实体、单位、员工、系统、薪资周期、时间及交易类型。

5. 范围之外

尚未纳入实施的员工群体、系统或功能。

6. 交付成果

系统对接、文档、培训、UAT、dashboard、对账及试点结束报告。

7. RACI

谁最终负责、谁执行、谁需咨询、谁需知情。

8. 风险与依赖项

数据、payroll、支付、安全、法律、资源及薪资周期安排。

9. 预算

供应商费用、系统对接、人力、支持、安全、宣导及预备金。

10. 决策标准

推广（Go）、调整（Adjust）、延长（Extend）、终止（Stop），以及具备审批权限的人员。

20. 试点结束评估报告模板

A. 执行结论

• 哪些目标已达成/未达成；

• 建议的决策；

• 重大风险；

• 后续所需资源及条件。

B. KPI结果

C. 财务情况

总成本、有依据的收益、相关假设、扩大规模所需成本及敏感性情景分析。

D. 风险情况

事件、欺诈、误拦截、差异、个人数据、剩余风险及风险接受人。

E. 经验教训

哪些做法应保留、修改或取消；推广到其他单位所需的条件。

F. 决策

推广（Go）/调整（Adjust）/延长（Extend）/终止（Stop）；范围；预算；责任人；下次复核时点。

21. EWA试点常见错误

开始前未定义何为“成功”

到试点结束时，各部门各自挑选对自身观点有利的指标。

只顾规模，未顾代表性

参与人数虽多，但集中在同一班次、同一主管或同一系统之下，因而无法反映整个企业的真实情况。

未完整走完一个payroll周期

虽然评估了应用体验，却尚未验证对账、结算及期末调整环节。

只对成功流程做UAT

不清楚如何处理超时、迟到修改的考勤、错误账户、退款及payroll录入错误等情形。

只测量数据却没有基线

上线后有了dashboard，却不知道该计划究竟改善了什么。

在运营团队仍靠人工处理时就扩大规模

试点看起来“运转良好”，只是因为项目团队在“手把手照顾每一笔交易”，但这种模式无法承受规模扩大。

政策频繁变动

导致无法区分究竟是政策、宣导、数据还是产品本身带来的影响。

缺乏结束方案

一旦停止，交易尚未对账、数据尚未清理、员工未获通知，责任归属也不清晰。

22. 试点中的数据与员工保护

（完整的安全框架参见实施EWA时的数据安全与隐私保护以及EWA中的风险治理与反欺诈管理。）

试点阶段仍须遵循数据保护及信息安全的各项原则。企业需要按目的限定数据范围、按职责分配权限、使用安全的测试数据、做好日志记录、管理供应商，并制定事件处理方案。

在越南，第91/2025/QH15号个人数据保护法自2026年1月1日起生效。试点方案的设计须依据各方角色、数据类型、共享范围以及员工权利进行审查。

在人力资本计量方面，ISO 30414:2025为人力资本报告提供了相关要求与建议。在信息安全风险治理方面，NIST Cybersecurity Framework 2.0是一套可供参考的框架，用于组织治理、识别、保护、检测、响应与恢复等各项活动。以上均为参考来源；试点标准仍须结合企业自身及真实的EWA模式来设计。

结语

EWA试点是一项受控的治理决策，而不仅仅是一次技术试用。一个值得信赖的试点，必须事先具备明确的假设、基线数据、具有代表性的范围、清晰的政策、足够可靠的数据、覆盖异常场景的UAT、保护类KPI以及已获批准的终止标准。

试点结束时，企业需要基于证据在推广（Go）、调整（Adjust）、延长（Extend）或终止（Stop）之间作出选择。如果企业希望根据自身现有的考勤系统、payroll及员工队伍情况，制定一份合适的日薪预支试点计划，欢迎了解企业日薪预支解决方案，共同探讨调研范围与实施文件体系。

参考来源

• ISO 30414:2025 – Human capital reporting and disclosure

• NIST Cybersecurity Framework 2.0

• 第91/2025/QH15号个人数据保护法

• 第356/2025/NĐ-CP号关于细化个人数据保护法的议定

---

作者： Tran Van Tai — 总经理助理，负责发展战略工作，Nhan Kiet Manpower Supply Co., Ltd.

企业日薪预支(EWA)解决方案咨询： 热线 0937.022.655 · 邮箱 info@nhankiet.vn · 企业日薪预支解决方案