DAILY WAGEHired TodayPaid Today

新闻

EWA系统的SLA:30个需要承诺的指标

Gala nhan ky niep thanh lap Nhan Kiet 8

EWA系统的SLA需要什么?从考勤到工资单的30个指标

“快速到账”承诺并不是SLA。EWA依赖于人力资源、考勤、审批、身份识别、银行、对账和工资单。如果仅测量应用程序的正常运行时间,企业可能会遇到应用程序可以打开但考勤未更新、交易挂起无人处理或期末工资单不匹配的情况。

> 简而言之: EWA的SLA必须根据用户旅程和最终结果进行测量:档案按时更新,考勤审批被计算,支付指令有状态,挂起的款项被处理,对账单匹配且工资单接收到正确的数据

> 警告: 本文中的阈值是设计示例,并不是Nhan Kiet或VPBank的正式SLA。每个承诺必须有测量公式、数据来源、服务时间表、例外情况、责任和经过批准的制裁措施。

1. SLA与SLO、KPI和OLA有何不同?

  • SLA: 各方之间的服务水平承诺,通常与合同相关。

  • SLO: 针对某个指标的内部运营目标。

  • KPI: 更广泛的绩效评估指标,不一定总是服务承诺。

  • OLA: 内部团队之间的运营协议,以共同实现SLA。

例如:与客户的SLA要求在某个时间范围内处理挂起的交易;OLA为客户服务、银行团队和技术团队分配时间。

2. 每个SLA指标的六个必备组成部分

  1. 名称和目的。

  2. 计算公式。

  3. 数据来源。

  4. 测量窗口和服务时间表。

  5. 目标/阈值。

  6. 排除、责任和报告机制。

如果没有定义开始和结束点,不要使用“快速”、“及时”、“几乎即时”等词语。

3. 确定开始–结束时间

EWA系统SLA中的时间测量方式

例如,“到账时间”可以从以下时刻开始:

  • 劳动者点击确认时;

  • 服务器接受请求时;

  • 指令发送到银行时。

并在以下时刻结束:

  • API报告成功时;

  • 劳动者账户被记入时;

  • 交易出现在对账单上时;

  • 劳动者确认收到款项时。

如果没有确定定义,双方可能会报告两个正确但不相同的结果。

4. 组A — 可用性和性能 (SLA 1–5)

EWA系统的SLA组

1. 劳动者应用程序的可用率

测量在服务窗口内登录、查看可用余额和创建请求的能力。

2. 客户门户的可用率

测量查看、审批、拒绝和修改考勤的功能。

3. 核心屏幕/API的响应时间

应测量百分位数如P95/P99,而不仅仅是平均值,因为平均值会掩盖非常慢的请求。

4. 服务器错误率

区分系统错误、输入数据错误、用户错误和第三方错误。

5. 维护窗口

规定时间表、提前通知时间、紧急维护和受影响的功能。

5. 组B — 人力资源和考勤 (6–10)

6. 人力资源档案同步延迟

从源头有变更到EWA反映,特别是离职/调动人员。

7. 考勤表同步延迟

日薪预支目前每30分钟有一个Google Sheet同步计划和一个立即同步按钮;SLA必须说明如果任务延迟或文件错误的测量方法。

8. 应用程序考勤延迟

应用程序中的考勤在设计上是实时记录的;仍需目标在屏幕/审批源上反映。

9. 考勤记录成功合并率

正确合并到人员、客户、日期/班次的记录数除以有效记录总数。

10. 考勤记录错误处理时间

区分系统错误与源数据错误;规定谁负责修复和响应时间。

6. 组C — 考勤审批和可用余额 (11–14)

11. 考勤审批时间

这通常是客户/监督的OLA,不完全由平台控制。需要从考勤准备好到审批的时间进行测量。

12. 审批后可用余额更新延迟

从有效审批事件到服务器计算/显示新余额的时间。

13. 可用余额正确计算率

通过从考勤、单价、已收款、保留、限额和四舍五入重新计算的样本进行检查。

14. 政策变更应用时间

单价/限额/保留必须有生效日期、审批和变更后的检查。

7. 组D — 身份识别和账户 (15–17)

15. OCR/身份证验证响应时间

区分自动处理与需要人工检查的例外情况。

16. 账户名称查询时间

测量系统部分和银行部分;规定查询服务中断时的状态。

17. 设备/账户更换处理时间

必须在用户体验与防止劫持之间取得平衡,进行验证和审批。

8. 组E — 银行交易 (18–22)

18. 请求成功处理率

必须区分由于系统、银行、账户、数据或政策导致的失败。

19. 确认后指令发送时间

从服务器接受到支付服务接收指令的时间。

20. 结果确认时间

与“到账”不同。需要定义确认来源。

21. 交易转为挂起的比率

监控比率和原因;过低的异常也可能是系统过早得出结论。

22. 挂起交易的年龄

从进入挂起状态到最终结论的时间;报告最长的款项并按年龄分组。

在日薪预支中,挂起款项的对账按技术层面的五分钟计划运行。SLA必须计算银行/相关方的响应时间。

9. 组F — 对账和工资单 (23–26)

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

23. T+1对账完成

日薪预支在08:00有一个读取对账单文件的计划。承诺需要规定文件准备的时间、合并率和异常的确认人。

24. 自动对账单合并交易比率

唯一合并的行数,正确的代码/金额/账户除以符合条件的总行数。

25. 对账差异关闭时间

根据价值、人数和重复支付/错误支付的风险进行分级。

26. 按时交付工资单数据

测量已检查的文件/API,正确的截止时间,正确的人员/客户/周期;不仅仅是“已发送电子邮件”。

10. 组G — 支持和故障 (27–30)

(参见:当日薪预支发生故障时EWA投诉处理手册。)

27. 首次响应时间

从有效工单被记录到用户收到带有事件编号的响应的时间。

28. 恢复/处理时间

区分服务恢复与彻底解决和根本原因分析(RCA)。

29. 故障通知时间

规定识别、确认、初始通知和定期更新的时间点。

30. 提供RCA的时间

RCA必须包括时间线、根本原因、影响、补救措施和预防行动。

11. 参考故障级别矩阵

级别

示例

处理

P1

大范围重复支付/错误支付,失去锁定控制,核心服务中断

指挥故障,适当暂停,持续更新

P2

多人无法交易,显著的可用余额/对账错误

高优先级,跨职能团队

P3

小群体错误,有替代方案

按标准SLA处理

P4

信息请求/显示错误

积压/常规支持

正式级别必须有金额、人员、数据和时间的阈值;不能仅凭感觉进行分类。

12. SLA目标示例表

指标

示例目标

注意事项

核心服务正常运行时间

99.9%/月

仅供示例,需要定义排除项

API响应P95

≤ 2秒

区分银行API

Sheet同步

每30分钟周期

从有效源数据开始计算

P1工单响应

≤ 15分钟

如果承诺,需要24/7值班时间表

P2工单响应

≤ 30分钟

不等于已处理完毕

T+1对账

按截止时间完成

依赖银行文件

工资单交付

在批准的截止时间前

有校验和/收据

表中的所有数字仅用于示例说明。不要用作日薪预支的承诺。

13. 正确计算正常运行时间的方法

一个常见的公式:

正常运行时间 = (服务窗口总分钟数 − 计算SLA的中断分钟数) ÷ 服务窗口总分钟数 × 100%

合同需要规定:

  • 哪些功能被测量;

  • 从外部测量还是内部日志;

  • 部分中断如何计算;

  • 维护是否排除;

  • 互联网/银行的依赖;

  • 四舍五入和时区;

  • 数据争议如何处理。

14. 不应过于广泛地排除

诸如“所有第三方错误”之类的条款可能会使SLA失去意义,因为银行和基础设施是EWA的重要组成部分。

应区分:

  • 供应商负责协调的端到端SLA;

  • 依赖银行/客户的指标;

  • 各方之间的OLA;

  • 无论原因如何,通知义务和备用计划。

15. RTO和RPO

  • RTO: 中断后恢复服务的目标时间。

  • RPO: 可以在时间上丢失的最大数据量。

EWA需要针对以下内容的RTO/RPO:

  • 档案/考勤;

  • 可用余额;

  • 交易;

  • 审计日志;

  • 对账/工资单。

金融交易需要比通信内容更严格的要求。目标只有在演练和有恢复不重复支付的证据时才有意义。

16. 数据和安全的SLA

(完整框架:参见 EWA实施中的数据安全和隐私。)

除了正常运行时间,还需要协议:

  • 可疑账户锁定时间;

  • 离职人员权限撤销;

  • 根据严重程度修补漏洞;

  • 数据泄露通知;

  • 提供日志/证据;

  • 处理数据主体请求;

  • 备份和恢复测试;

  • 定期权限审查;

  • 终止时删除/返还数据。

正式期限必须符合法律和风险评估,不应机械复制国际模板。

17. 服务信用是否足够?

服务信用可以激励合规,但不能替代:

  • 修复错误支付;

  • 数据保护义务;

  • 处理投诉;

  • 根据合同/法律赔偿;

  • 停止/扩展的权利;

  • 防止重演的计划。

对于严重的财务错误,阻止条件和具体责任比小额费用减免更重要。

18. 每月SLA报告应包含

  • 适用的30个指标结果;

  • 三至六个月的趋势;

  • 违规次数和持续时间;

  • 按客户/来源分析;

  • 挂起交易和年龄;

  • 对账/工资单差异;

  • P1–P4和RCA;

  • 重大维护/变更;

  • 投诉和重新打开;

  • 补救行动、负责人、期限;

  • 下期预期风险。

总览仪表板不应以漂亮的平均数掩盖严重错误。

19. 六步构建SLA流程

  1. 绘制旅程和依赖关系。

  2. 选择对劳动者/企业重要的结果。

  3. 确定指标、来源和测量时间。

  4. 在承诺前测量基线。

  5. 协商目标、排除项、OLA和制裁措施。

  6. 试点、审查和调整后再扩展。

不要仅因为市场通常这样记录就承诺高水平,如果系统尚无基线。

20. SLA审查清单

(文件包:参见 日薪预支审查文件。)

  • 有服务窗口定义。

  • 有处理时间的开始/结束点。

  • 独立且可追溯的数据来源。

  • 有性能的百分位数。

  • 第三方错误不被无限排除。

  • 有挂起交易的SLA。

  • 有对账和工资单的承诺。

  • 有P1–P4的客观阈值。

  • 有故障更新时间表。

  • 有RTO/RPO和演练。

  • 有数据/安全的SLA。

  • 有定期报告和审查。

  • 有审计/数据争议的权利。

  • 有适当的服务信用/责任。

  • 有规模变化时修订SLA的机制。

21. 常见问题

30秒内到账是否为SLA?

只有当合同定义了开始点、结束点、交易达成率、账户/银行条件和例外情况时才是。如果没有,这只是体验信息。

99.9%的正常运行时间对EWA是否足够?

不够。应用程序可能在线,但考勤未更新或银行未处理。需要端到端的SLA。

挂起交易是否被视为SLA违规?

必须有关于挂起交易比率和年龄的单独指标。一些挂起状态是安全控制,但不能无限期存在。

客户延迟审批考勤是否为供应商的错误?

通常是客户的依赖/OLA。SLA需要区分考勤有效审批前后的时间。

是否应在网站上公开SLA?

可以公开已批准的框架或服务状态。详细合同目标可能因客户而异;不公开没有证据的数字。

---

作者: Nguyen Minh Tuan — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

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

新闻