企业EWA 90天试点计划
EWA 90天试点建议分为三个阶段:0–30天准备阶段;31–60天受控运行阶段;61–90天评估与扩展决策阶段。目标不是追求尽可能多的交易笔数,而是证明从已核准工时–额度–放款–薪资–财务这一完整链条运转正确,员工清楚了解自身权益,且风险处于企业可接受的范围内。
EWA — Earned Wage Access通常被理解为一种帮助员工在正式发薪日之前,提前支取部分已产生工资的解决方案。由于 EWA 直接连接人力资源、考勤、薪资、支付与财务数据,试点必须是跨部门协作的项目,而不仅仅是一次应用测试。
> 术语说明:EWA(按已完成工时预支工资)· pilot(试点部署)· UAT(用户验收测试)· RACI(角色分工矩阵:执行–最终负责–咨询–知会)· KPI(关键绩效指标)· ROI(投资回报率)· go-live(正式上线运行)· soft launch(小范围试运行)· project charter(项目章程)· risk register(风险登记册)· playbook(应急处理手册)· dashboard(监控仪表盘)· Go–Adjust–Stop(继续–调整–终止)。
为什么要先试点再全企业推广?
文档、演示和 UAT 只能验证部分内容。使用真实数据进行试点可以帮助企业确认:
已核准工时是否准确且及时更新(按照Lương Ngày 流程)。
额度计算公式是否会在期末产生差异。
交易是否存在重复、卡单或账户错误的情况。
薪资与财务部门能否将对账精确到每一笔交易。
员工是否清楚了解费用、额度和剩余工资。
支持团队能否处理考勤错误、离职和查询问题。
总成本与收益是否接近商业论证(business case)的预期。
在真实运行环境中,个人数据与访问权限是否得到有效管控。
过早扩大规模可能会将一个小错误演变成大范围的偏差(参见 EWA 部署风险)。试点有助于限制影响范围,从数据中学习,并在扩大规模前完善流程。
企业是否已准备好开展 EWA 试点?
只有在具备基础条件的情况下,才应确定启动日期。
条件类别 | 准备情况问题 | 最低证明材料 |
|---|---|---|
目标 | 试点要解决什么问题? | 项目章程与 KPI |
工时 | 是否有可靠的已核准工时状态? | 考勤质量报告 |
薪资 | 是否有计算公式、封账周期和对账文件? | 一轮薪资 UAT |
员工 | 是否有合格名单和支持渠道? | 试点名单、FAQ |
财务 | 资金来源与项目上限是否已获批? | 预算/资金来源审批 |
法务 | 合同、规章、条款和统一话术是否到位? | 法务审批文件 |
数据 | 各方角色、目的、权限划分和存储方式是否明确? | 数据流程图、权限矩阵 |
技术 | 是否有测试环境、日志和防重复机制? | UAT 及错误测试结果 |
运营 | 每一种异常情况由谁处理、需要多长时间? | RACI、SLA 及应急手册 |
如果任何一项必备条件尚未满足,企业应保持准备阶段,而不是让真实员工充当测试环境。
如何选择试点范围
选择合适的单位
应优先选择具备以下条件的工厂、区域或团队:
考勤数据相对稳定。
工时审批人和 HR 对接人明确。
薪资部门能够为试点团队单独出具报表。
管理层愿意配合。
员工人数足以产生真实场景。
不与其他重大政策变动同时进行。
多大的规模才合适?
约 300–1,000 名员工可作为大型企业的参考范围,但并非强制标准。规模较小的企业可以以更少的人数试点;数据尚不稳定的企业则应从更小的范围开始。
规模需要满足两个要求:
足够小,以便在出现问题时能够暂停并处理。
足够大,以便检验负荷、使用行为和各种异常情况。
定义合格群体
试点群体应按照已批准的标准筛选,例如:
目前处于有效劳动关系中。
已正确匹配员工编号。
拥有已核准工时。
拥有作为计算依据的工资数据。
拥有有效的收款账户。
不处于离职/临时锁定/工时争议状态。
已完成条款确认与数据告知。
不应先按"全体员工"名单开通,再事后处理数据缺失的问题。
90天时间线概览
阶段 | 时间 | 主要目标 | 产出成果 |
|---|---|---|---|
1. 准备 | 第 0–30 天 | 确定模式、数据、流程、管控与沟通方案 | 上线文档、UAT、试点名单 |
2. 受控运行 | 第 31–60 天 | 以谨慎的额度进行真实运行,并每日监控 | 交易、错误、反馈报告及期中对账 |
3. 评估 | 第 61–90 天 | 完成一个薪资周期,测算 KPI、ROI 及风险 | 试点报告及 Go–Adjust–Stop 决策 |
第一阶段——第 0 天至第 30 天:准备
第 1 周:确定目标与范围
制定项目章程。
选定项目负责人及项目组。
选定试点单位、员工群体及试点周期。
确定一个核心目标及相应的 KPI。
建立离职率、预支、工时、薪资和成本的基线数据。
确定预算与资金来源。
编制初步风险登记册。
产出: 已获批准的范围、KPI、预算、责任人及项目日程。
第 2 周:法务、政策与数据
确定交易结构与资金流向图。
审阅合同、规章及员工条款。
确定费用模式及承担方。
编制数据地图、处理角色及权限矩阵。
明确存储/删除期限及事故处理流程。
确定使用资格条件、额度、备用金及项目上限。
产出: 已获批准的法务–政策–数据文件组。
第 3 周:系统集成与业务测试
完成 HR、考勤、薪资与 EWA 系统之间的员工编号匹配。
测试各类工时状态。
测试额度计算公式。
测试收款账户变更。
测试防重复交易机制。
测试成功、失败、查询待处理及退款交易。
测试离职人员、工时错误及封账场景。
从交易到工资单/会计凭证进行试对账。
产出: UAT 记录、错误清单、责任人及重测结果。
第 4 周:培训与上线审批
培训工时审批的管理人员。
培训 HR、薪资、财务、IT 及支持团队。
使用通俗易懂的语言向试点群体进行宣导。
在启用前进行认知理解调查。
确定值班安排及支持渠道。
演练事故处理及暂停机制。
召开 Go/No-Go 会议。
产出: 最终合格名单、上线检查清单及审批记录。
第二阶段——第 31 天至第 60 天:受控运行
第 31–37 天:小范围试运行
不必在第一天就开通整个试点群体,可以按小批量逐步启用,以检验:
注册/认证成功率。
已核准工时和额度是否正确显示。
费用及剩余工资是否正确显示。
交易是否到达正确的账户。
交易后额度是否正确扣减。
日志、通知及支持工单是否正常运作。
首周应每日进行对账,并召开简短的日终碰头会。
第 38–45 天:流程稳定化
在已批准的范围内逐步扩大。
监控待审批工时及额度更新时间。
按原因对所有工单进行分类。
在扩大规模前关闭重大缺陷。
复查重复提现行为及剩余工资情况。
检查高峰日的资金充足能力。
第 46–60 天:压力测试及异常情况检验
在真实运行环境中执行预设场景。
监控高峰日、周末及临近封账的时段。
检查离职、换班、无薪假及工时调整情况。
评估支持效率及升级处理情况。
准备首次薪资对账。
试点期间的审慎额度管理
不存在统一适用的安全比例。在试点期间,企业应当:
仅按已核准工时进行计算。
如有需要,采用低于扩展后预期水平的提取比例。
为工时调整及合理债务预留备用金。
设定个人、单日、单位及全项目的上限。
当资金来源或数据低于阈值时暂停运行。
不为提高交易笔数而放宽额度。
第三阶段——第 61 天至第 90 天:评估
第 61–75 天:完成一个薪资周期
这是检验完整生命周期的必经节点:
确定工时数据。
确认所有交易的最终状态。
将已提前支取的金额纳入薪资计算。
逐人、逐笔交易核对。
与银行流水及会计账目核对。
处理差异。
发放易于理解的工资单。
封账并归档。
如果仅仅是放款准确,却尚未证明期末对账无误,不应认为试点已经成功。
第 76–85 天:测量体验、成效与风险
对使用者及未使用者进行问卷调查。
采访管理人员、HR、薪资、财务及支持团队。
将 KPI 与基线数据及对照组进行比较。
计算总成本、初步收益及 ROI。
复查费用、投诉、剩余工资及使用行为。
更新风险登记册并评估管控措施。
第 86–90 天:做出决策
项目组编制总结报告,并提出以下三种决策之一:
Go(继续): 按路线图扩大推广。
Adjust(调整): 延长或调整试点。
Stop(终止): 暂停、重新设计模式或不再继续。
EWA 试点项目的 RACI
标注说明:R – 直接执行;A – 最终负责/审批;C – 需咨询;I – 需知会。
事项 | 发起人/总经理 | 项目负责人 | HR/运营 | 薪资/财务 | 财务部 | IT/安全 | 法务 | 供应商 |
|---|---|---|---|---|---|---|---|---|
目标、范围、预算 | A | R | C | C | C | I | I | C |
使用资格条件 | I | A | R | C | C | C | C | C |
额度计算公式 | I | A | C | R | R | C | C | C |
合同与条款 | I | C | C | C | C | I | A/R | C |
数据地图与保护 | I | C | C | I | I | R | A | C |
系统集成与 UAT | I | A | C | R | I | R | I | R |
资金来源与上限 | I | C | I | C | A/R | I | C | C |
沟通、培训 | I | A | R | C | I | C | C | C |
上线与运行 | I | A | R | R | C | R | C | R |
对账与封账 | I | C | C | A/R | C | C | I | R |
事故处理 | I | A | R | R | C | R | C | R |
Go–Adjust–Stop 评估 | A | R | C | C | C | C | C | C |
RACI 应根据组织实际情况进行调整。每个事项都应只有一个明确的 A 角色,以避免出现无人承担最终责任的情况。
90天试点 KPI 仪表盘
数据与资格条件类
合格员工人数/比例。
员工编号正确匹配的记录比例。
收款账户认证成功率。
按 SLA 完成核准的工时比例。
因数据缺失而无法获得额度的人数。
使用情况类
激活率。
使用者比例。
人均/周期内交易笔数。
平均提取金额。
已提取金额占已产生工资的比例。
交易后的预计剩余工资。
运营类
交易成功率。
交易处理时长。
失败/待查询/退款交易。
因疑似重复而被拦截或重复的交易。
对账差异的笔数及金额。
工单关闭时长。
体验类
对 EWA、费用及剩余工资的正确理解比例。
满意度。
每千名合格员工的投诉数。
未激活/未使用的原因。
希望继续使用的比例。
人力与财务类
试点前后人工预支笔数对比。
HR/薪资部门节省的时间。
7/30/60/90 天离职率。
缺勤/擅自离岗情况。
试点成本及每位合格员工/使用者的成本。
折算收益、净收益及初步 ROI。
风险类
超过实际工资的放款。
因数据错误/欺诈造成的损失。
安全/个人数据事故。
重大 SLA 违规。
剩余工资低于内部预警阈值的人数。
Go–Adjust–Stop 决策标准
Go——具备扩大条件
已完成至少一个薪资周期,并对账到每一笔交易。
不存在尚未处理的重大差异。
已核准工时及数据符合 SLA 要求。
交易错误率、工单量及风险处于已批准的阈值内。
员工正确理解费用、额度及剩余工资。
成本在预算范围内,且有合理的收益信号。
法务、数据、资金来源及安全方面没有阻碍扩大的问题。
Adjust——继续但需调整
未达到 KPI,但原因明确且有应对方案。
由于沟通不到位,导致工时审批延迟或激活率偏低。
系统集成仍存在人工操作,但可控。
费用模式、额度或 SLA 需要调整。
由于一次性成本或试点规模较小,ROI 尚未转正。
Stop——终止或重新设计
无法与薪资/财务对账。
出现错误放款/重复放款或不受控的损失。
资金来源无法保证。
法律性质或各方责任尚不明确。
发生严重的数据事故。
员工被误导或受到重大负面影响,且尚无有效应对措施。
上线检查清单
法务与政策
[ ] 模式及资金流向已描述并获批。
[ ] 合同、规章及员工条款保持一致。
[ ] 费用及承担方已明确公示。
[ ] 已建立离职、工资不足及工时争议的处理机制。
[ ] 关于借贷、征信记录、利息/费用的相关话术已审核。
数据与技术
[ ] 仅已核准工时计入额度计算。
[ ] 员工编号及交易编号具有唯一性。
[ ] 已完成防重复、重试及待处理交易的测试。
[ ] 已建立权限分级、加密、日志及预警机制。
[ ] 已有离职人员账户锁定机制。
[ ] 已有回滚/暂停方案。
财务、薪资及会计
[ ] 额度计算公式及备用金已获批准。
[ ] 资金来源及项目上限已就绪。
[ ] 已完成从工资单到会计凭证的 UAT。
[ ] 已建立三层对账文件及流程。
[ ] 已建立退款、纠错及封账流程。
员工与支持
[ ] 已核实合格名单。
[ ] 界面能够显示费用、实际到账金额及剩余工资。
[ ] 已准备好关于工时错误/交易异常的 FAQ 及指南。
[ ] 已公布支持渠道、值班安排及 SLA。
[ ] 在正式上线前已进行认知理解调查。
EWA 试点部署中十个常见错误
没有基线数据: 试点结束后无法判断结果是变好还是变差。
选择的单位数据基础太薄弱: 大量时间被用于纠正工时问题,而非验证 EWA 本身。
第一天就开通范围过大: 一个小错误就会影响过多人员。
只测试正常流程: 不清楚如何处理离职、工时错误、卡单交易或退款。
没有明确的责任项目负责人: 各部门相互等待对方做决定。
将交易笔数设为主要目标: 可能助长过度使用。
未完成一个完整的薪资周期: 无法验证完整的生命周期。
过度宣传: 承诺"随时可提现"或"零费用"等不符合实际条件的说法。
未计入内部成本: ROI 被夸大。
在问题尚未解决时就扩大规模: 技术债务及偏差会随规模扩大而增加。
面向员工的沟通计划
沟通话术需要回答以下六个问题:
Lương Ngày/EWA 是什么?
谁符合资格?
哪些工时会用于计算额度?
费用及实际到账金额是多少?
期末工资会如何变化?
出现问题时应联系谁?
建议使用多种形式:短视频、海报、FAQ、应用内指引及针对一线管理人员的培训。所有渠道的内容必须保持一致。
提交管理层的试点报告模板
1. 执行摘要
目标、范围、时间。
主要成果。
风险及事故。
Go–Adjust–Stop 建议。
2. 运行结果
资格条件、已核准工时、交易、SLA、对账情况。
3. 员工体验
正确理解程度、满意度、投诉、定性反馈。
4. 人力影响
招聘、离职、缺勤及对照组情况。
5. 财务
成本、收益、ROI 及三种扩展情景。
6. 风险与管控
风险登记册、差异、事故、尚未关闭的行动项。
7. 后续计划
扩大范围或调整清单。
预算及资源。
下一个决策节点。
结论
EWA 90天试点是对一个跨部门运行系统进行验证的过程。成功不仅仅是快速放款,还必须确保:
正确的对象 → 正确的已核准工时 → 正确的额度 → 正确的账户 → 精确到一次 → 正确的薪资 → 正确的会计 → 正确的体验。
企业应在前 30 天充分做好准备,在接下来的 30 天以受控方式开通,并在最后 30 天完成薪资结算、测算 KPI、计算 ROI,并基于实证做出决策。
企业可以根据自身规模、考勤数据、薪资及人力目标,在 企业版 Lương Ngày 获取量身定制的 Lương Ngày 试点计划。
> 提示: 本文提供的是通用部署框架,不能替代针对特定企业的法律、财务、会计、安全或项目管理咨询。
参考资料
---
作者: Nguyễn Tấn Lộc —— Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt 战略部专员。
企业版 Lương Ngày 解决方案咨询: 热线 0937.022.655 · 邮箱 info@nhankiet.vn · 企业版 Lương Ngày
常见问题
EWA 90天试点是否太长?
对于许多模式而言,三个月的时间足以完成准备、受控运行及至少一个薪资周期。薪资周期、系统集成或法律结构较为复杂的企业,可能需要更长时间。
应该以多少员工进行试点?
没有统一的数字标准。300–1,000 人的范围可供大型企业参考;具体决策应基于数据质量、支持能力、资金来源及可接受的风险水平。
试点前是否需要完成 API 集成?
并非必须。只要能够保证身份识别、版本管理、审批、防重复及对账,也可以使用受控文件方式。但不应采用缺乏管控的人工操作。
为什么必须经过一个薪资周期?
因为只有在那时,企业才能验证工时、额度、交易、调整、工资单、会计及封账这一完整生命周期。
90天后 ROI 为负是否必须终止?
不一定。需要区分一次性成本并找出原因。如果有明确的改进方向,可以选择 Adjust;如果存在根本性风险或成本无法控制,则应选择 Stop。
试点期间是否应该完全免除所有费用?
如果符合目标,可以考虑,但必须明确说明这是试点期间的专属政策。如果正式阶段将收取费用,应提前告知员工,以避免试点结果无法反映真实使用行为。
出现事故时,由谁决定暂停系统?
RACI 及应急手册必须明确规定拥有暂停权限的角色,以及处理人、重新启用的审批人和通知渠道。
使用率高是否可以立即扩大规模?
不可以。使用率高只是其中一项指标,还必须综合考察对账结果、错误率、费用、剩余工资、数据风险及整体成效。
Read more articles
- 已经打卡但仍未看到出勤天数或额度未增加：原因及处理方法 · Người lao động
- 多班次制造企业的EWA:如何实施才能算准工时? · Doanh nghiệp
- 什么是日薪预支（EWA）？越南全面指南 · Kiến thức
- 日薪预支(EWA)试点计划模板与扩大标准 · Doanh nghiệp
- 'luong ngay' 是什么意思？区分三种易混淆的含义 · Kiến thức
- 用哪些KPI衡量日薪预支的效果? · Doanh nghiệp
- 传统预支工资与EWA（日薪预支）有何不同？ · Kiến thức
- 越南工资预支规定：劳动者与企业需要了解什么？ · Pháp lý
- EWA 是借款吗？按模式逐一分析 · Kiến thức