DAILY WAGEHired TodayPaid Today

新闻

企业需要多少人来运营日薪预支?

tat Nien Cong Ty Nhan Kiet 2019 115

企业需要多少人来运营日薪预支?人力模型与RACI

实施日薪预支不一定需要新设部门。大部分角色可以由现有的人力资源、薪资、财务、IT和客服兼任。然而,企业仍需一名负责人在关键点进行监督:工时审核、银行交易、对账和投诉处理。

> 简而言之: 不要先问“需要多少人”;而是要衡量员工数量、客户数量、工时模板、交易、例外情况、支持班次和自动化程度。一个小型试点可以由兼任团队运营;大规模需要专职角色和轮班值守。

> 警告: 本文中的FTE数字仅为计划模型,不是Nhân Kiệt的编制。必须在试点中测量实际工作量,然后再决定编制或承诺24/7支持。

1. 为什么用户数量不足以决定编制?

两家拥有5000名员工的企业可能需要非常不同的资源:

  • 企业A有一个标准的工时系统,一个工资周期,例外情况少;

  • 企业B有20个客户,多个表格,夜班,多地工作和分散的工时审核。

运营工作量主要来自例外情况,而不仅仅是成功交易的数量。

2. 决定资源的十个变量

  1. 符合条件的员工数量。

  2. 活跃用户和每日交易数量。

  3. 客户/地点/班次数量。

  4. 工时模板数量。

  5. 未合并/未审核工时的比例。

  6. 未验证的身份证/账户比例。

  7. 挂起/失败交易的比例。

  8. 薪资周期和复杂程度。

  9. 支持请求的时间。

  10. 自动化程度、SLA和可接受的风险。

3. 11个核心角色

运营日薪预支所需的角色

(更多信息请参见:日薪预支上线后的运营:RACI、控制和事故管理。)

1. 执行赞助商

批准目标、预算、范围、风险偏好和扩展/停止决策。

2. 服务负责人

对服务质量负责,不仅仅是一个系统。这个角色不应空缺。

3. 产品/流程负责人

管理需求、公式、限额、流程和改进优先级。

4. 人力资源主数据

管理档案、身份证、工作状态、调动、离职和客户关系。

5. 出勤运营

管理工时来源、映射、班次、同步错误和审核协调。

6. 支付运营

监控支付指令、专用账户、挂起交易、对账和紧急停止。

7. 对账/财务

对账日薪预支账簿、对账单、债务;处理差异和不可回收款项。

8. 薪资

将正确的交易分配给正确的人/周期,编制桥接报告和工资单。

9. 客户支持

一站式接收、验证、分类、更新和关闭工单。

10. 工程/SRE/信息安全

集成、监控、发布、事故、安全、备份和恢复。

11. 法务/数据/合规

合同、规章、个人数据、传播内容和法律变更。

在试点中,一个人可以兼任多个角色;但必须分离冲突权限。

4. 模型A — 小型试点

企业需要多少人来运营日薪预支

示例范围

  • 100–1,000名符合条件的人;

  • 一到两个客户;

  • 少量工时模板;

  • 在指定时间内支持;

  • 低交易/资金限制;

  • 每日对账。

参考核心团队

角色

参与程度

服务/项目负责人

0.3–0.5 FTE

人力资源 + 工时

0.5–1 FTE

支付 + 对账

0.5–1 FTE

薪资

0.2–0.5 FTE

客服

0.5–1 FTE

技术/信息安全

随叫随到/兼任

法务/数据

根据审批节点

实际人数可能为5–8人兼任,而不是5–8个全职FTE。

5. 模型B — 中型运营

示例范围

  • 1,000–10,000人;

  • 多个地点/客户;

  • 稳定的每日交易;

  • 若干工时模板;

  • 扩展的SLA和支持班次。

参考结构

  • 一名专职服务负责人;

  • 一名产品/流程负责人;

  • 1–3名人力资源/工时人员;

  • 1–2名支付/对账人员;

  • 1–2名客服轮班;

  • 按周期的薪资,有备用人员;

  • 技术/SRE随叫随到;

  • 信息安全、法务和数据按计划审查。

编制必须根据例外比例和实际工作量进行调整。

6. 模型C — 大规模,多客户

特点

  • 数万名员工;

  • 数百个客户/地点;

  • 多个来源和工时模板;

  • 非工作时间支持;

  • 大量交易和资金流动;

  • 高要求的控制/任务分离。

应按小组组织

  1. 服务治理: 负责人、KPI、风险、供应商。

  2. 劳动力数据: 档案、工时、映射、审核。

  3. 资金运营: 资金来源、支付指令、对账。

  4. 对账与薪资: 对账单、债务、工资单。

  5. 员工体验: 入职、客服、个人财务。

  6. 技术与信任: 工程、SRE、信息安全、数据。

每个小组有组长和备用计划;P1有独立于变更者的事故指挥官。

7. 基于工作量的编制公式

可以估算:

FTE = 周期内总工作处理分钟数 ÷ 每个FTE的有效工作分钟数

例如客服:

工单/天 × 平均分钟/工单 × 后检查系数 ÷ 每班有效分钟数

例如对账:

例外/天 × 分钟/例外 + 总检查时间 + 报告

不要使用480分钟/天作为绝对有效生产力;需要扣除会议、培训、休息和负载波动。

8. 试点中需要收集的数据集以进行编制

(更多信息请参见:日薪预支试点结果:KPI和经验教训90天日薪预支试点计划。)

  • 新增/修改/离职档案数量;

  • 工时行数和错误率;

  • 等待审核的工时和时长;

  • 不匹配的账户/OCR;

  • 按小时/班次的交易;

  • 成功/等待/失败率;

  • 对账例外数量;

  • 按类型的工单;

  • 处理时间和重新打开时间;

  • 配置更改数量;

  • 按截止日期的薪资工作量;

  • 事故和随叫随到时间。

至少测量一个包含薪资的周期,以避免低估月末负载。

9. RACI示例

活动

R

A

C

I

员工档案

人力资源数据

人力资源负责人

IT

员工

工时映射

出勤运营

流程负责人

客户/主管

客服

工时审核

客户/主管

工时来源负责人

人力资源

员工

限额/储备

产品运营

服务负责人

财务/法务

客服

账户验证

支付运营

服务负责人

VPBank/信息安全

员工

自动支付

系统/运营

服务负责人

财务/VPBank

客服

对账

对账

财务负责人

VPBank/IT

薪资

薪资

薪资

薪资负责人

财务/日薪预支

员工

P1

事故团队

事故指挥官

法务/信息安全

领导/客户

生产变更

工程

变更审批人

产品/SRE

运营

10. 不应完全合并的角色

  • 修改工时和审核同一记录的人;

  • 更改限额和批准的人;

  • 发起/调整交易和对账结算的人;

  • 开发人员自行进行生产变更和确认的人;

  • 持有银行密钥和决定所有指令的人;

  • 处理事故和批准删除日志的人;

  • 编制薪资和最终审核的人。

在小团队中,可以使用四眼原则进行时间点控制,而不是立即招聘更多人,但不能放弃分离。

11. 值班和随叫随到

如果系统支持24/7交易,但支持团队仅在工作时间内工作,必须明确:

  • 哪些功能是24/7自动化的;

  • 哪些P1有随叫随到支持;

  • 常规工单何时回复;

  • 谁接收余额/挂起交易警报;

  • 升级到VPBank;

  • 使用紧急停止开关的权限;

  • 班次交接。

不要仅因为应用程序可以随时打开而承诺24/7。

12. 每个角色的最低运行手册

(更多信息请参见:当日薪预支出现问题时日薪预支投诉处理手册。)

人力资源/工时

档案错误、未合并的工时代码、离职、调动、已审核工时的修改。

支付运营

账户不匹配、挂起交易、超时、对账、资金不足、紧急停止。

对账

缺失/多余条目、金额错误、交易退回、跨周期差异。

薪资

截止日期、接近周期的交易、双重扣除、结算后退款、工资单差异。

客服

验证询问者、理由代码、最低数据、SLA/升级、回复内容。

技术/信息安全

警报、回滚、日志保护、P1、数据违规、恢复。

13. 运营团队的KPI

应该测量

  • 符合条件的档案;

  • 按时审核的工时;

  • 合并记录的比例;

  • 成功交易;

  • 挂起交易的时长;

  • 按时对账;

  • 薪资匹配;

  • 响应/解决时间;

  • 工单重新打开率;

  • 资金/数据错误;

  • 按时完成的RCA行动。

不应单独使用

  • 提款次数;

  • 支付总金额;

  • 安装应用的账户数量;

  • 关闭工单数量而不考虑重新打开/质量。

KPI不应推动员工进行交易以达到团队目标。

14. 客户/工作地点的人员

每个客户至少需要确定:

  • 赞助商或管理联系人;

  • 名单管理员;

  • 工时审核员和替代者;

  • 班次入职支持人员;

  • 薪资/会计联系人;

  • 事故/升级联系人。

对于多个班次,“班次大使”模型有助于指导,但不得保留OTP、密码或代替员工进行交易。

15. 按角色培训

角色

必修内容

监督

审核/修改工时、截止日期、审计跟踪

人力资源

档案、身份证、离职/调动、传播

支付运营

状态、失败关闭、对账

薪资

桥接报告、周期、退款/调整

客服

验证、数据保护、手册

技术

幂等性、监控、事故

领导

KPI、风险、扩展门户

每个课程需要实践和测试,而不仅仅是发送资料。

16. 扩展时的人力计划

(更多信息请参见:日薪预支试点计划模板和扩展标准。)

门槛1 — 增加用户

检查客服、对账、余额和等待工时。

门槛2 — 增加客户

评估工时模板、审核员和现场联系人。

门槛3 — 增加自动化

检查监控、随叫随到、紧急停止和权限。

门槛4 — 非工作时间支持

设计班次、津贴、交接、升级和值班团队健康。

不要先扩大范围,然后再招聘/安排人员处理例外情况。

17. 运营组织检查清单

  • 已任命一名服务负责人。

  • RACI中没有缺少“A”的活动。

  • 工时审核员有备用。

  • 支付运营和对账已分离。

  • 有人监控挂起交易。

  • 薪资从试点开始参与。

  • 客服有一站式和案例负责人。

  • 技术/SRE有适当的随叫随到。

  • 已指定事故指挥官。

  • 法务/信息安全有审查计划。

  • 工作量按例外类型测量。

  • 编制考虑高峰/周期末时间。

  • 每个角色都有运行手册。

  • 培训和演练已完成。

  • 扩展必须通过资源门槛。

18. 常见问题

500人试点是否需要专职人员?

可以使用兼任团队,但仍需明确指定服务负责人、工时审核员、支付/对账、薪资、客服和技术随叫随到。

系统已经自动化,为什么还需要支付运营?

自动化处理标准流程;支付运营监督资金来源、挂起交易、对账、例外情况和紧急停止。

是否需要24/7客服?

取决于交易窗口和SLA。如果不支持24/7,必须明确回复时间,并且仍需对严重资金问题进行随叫随到支持。

谁应该担任服务负责人?

能够协调人力资源、工时、资金、薪资、技术和客户的人;不一定是IT部门负责人。

何时需要增加编制?

当积压、例外时长、SLA、加班或任务分离风险超过阈值时——不仅仅是用户数量增加时。

---

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

新闻