功能清单决定一套 HR 系统“能不能用”,另外三件事决定它“能不能活下来”:能不能和现有系统对上、主数据归谁管、数据敢不敢给人看。这三件事在选型阶段常常只有一句话,在实施阶段却要占掉大半工期。
这篇文章面向信息中心与选型负责人,把这三件事摊开讲清楚,并给出可落地的验收口径。
HR 系统是典型的“中间系统”:向上给决策层供数,向下给员工提供服务,横向还要和一堆系统交换数据。常见需要打通的至少有这么几类:
• 财务与 ERP:成本中心、工资凭证、费用预算、人工成本科目。
• OA 与审批:入转调离、请假加班、用工需求的审批流。
• 门禁与考勤设备:闸机、考勤机、访客系统的时间与记录。
• 协同办公平台:组织架构与人员同步、消息与待办推送。
• 招聘渠道与背调:职位发布、简历回流、入职前核验。
• 银行与税务社保经办:代发文件、申报数据、缴费结果回传。
• 身份与安全体系:单点登录、账号生命周期、离职账号回收。
• BI 与数据仓库:指标口径、历史归档、跨系统分析。
接口的第一件事不是“连”,而是定主从:每个字段都要先回答“谁是主数据源”。组织架构是以 HR 为准同步给协同平台,还是反过来由平台下发,必须写清楚,否则两边会互相覆盖,而且没人说得清最后一次是谁改的。
第二件事是失败处理。接口连上只是开始,要问的是:失败了重试几次、有没有补偿机制、有没有日终对账、失败时业务能不能继续跑。比如代发文件生成失败,业务是否有手工兜底路径,还是全公司等在那里。
第三件事是时序。组织调整当天同步还是次日凌晨同步、发薪日前的批量接口是否需要单独的时间窗、审批结果回写是否实时。这些细节决定了上线后每天有没有人来问“为什么这边还没更新”。
HR 侧的主数据有四类:人员、组织、岗位职级、成本中心。它们看起来简单,治理起来最费时间。
第一是唯一标识。工号规则怎么定、离职后是否回收、返聘与再入职怎么处理。如果同一个人因为再入职变成两条记录,他的工龄、年假、历史薪酬就断成两截,之后再怎么补都是人工补。
第二是归属分离。组织归属与成本归属经常不是一回事:人在 A 部门,成本记在 B 项目或 C 分公司。系统要能把两者分开存、分别统计,否则要么编制算错,要么成本算错。
第三是变更留痕。组织调整要不要保留版本;用了版本,报表是按“当时”口径还是“现在”口径。这个问题必须在项目早期定下来,因为它决定了所有历史报表的算法。
一条经验:主数据治理投入的多少,和上线后每月的对账工时成反比。前期多花两周把规则写清楚,后期每个月能省两天。
HR 系统的使用者至少有三类:HR 专业用户、直线经理、员工本人。权限不是一个“角色”能解决的,要同时控制两个维度——数据范围和字段范围。
数据范围指能看哪些法人、哪些部门、哪些岗位的人;字段范围指同一个页面里,薪酬明细、身份证号、银行卡号、绩效结果是否可见。只做角色不做字段,就会出现“经理能看到全部门工资”这种上线后必须紧急修的漏洞。
薪酬数据要单独设计。谁能看汇总、谁能看明细、谁能导出,三者权限应当分开。导出往往是最容易被忽略的泄露口——查询可以审计,导出的表格会流到聊天群里。
操作审计也要有。谁在什么时候查了谁的薪酬、改了哪条记录、批量导出了什么,要能查得到、留得下。在当前个人信息保护的监管环境下,“能追溯”本身就是合规的一部分,而不是可选项。
还有离职这一环:账号回收、权限回收必须和离职流程绑定,不能靠 IT 每月人工比对名单。这一条在选型打分表里通常没有位置,在安全审计里却年年被问。
个人信息保护法自 2021 年 11 月 1 日施行,对 HR 场景的影响比多数人预想的深。HR 系统处理的是全员的身份、联系方式、薪酬、考勤、健康与资质信息,几乎覆盖了员工信息的全部。
第一层是告知与最小必要。收集什么、为什么收集、保存多久、给谁看,都要有明确说明,并且只收集业务确实需要的信息。员工与企业的地位并不完全对等,所以“同意”这件事要做得更实:告知处理规则、给出必要说明,而不是在入职材料里塞一行小字。
第二层是敏感个人信息。人脸与指纹、体检与病假材料、定位打卡形成的行踪轨迹、工资卡等金融账户信息,都属于敏感个人信息,处理时需要特定目的、充分必要性、单独告知并取得同意。实务上更稳妥的做法是同时提供替代方案,例如以刷卡代替人脸识别。
第三层是合规审计。《个人信息保护合规审计管理办法》自 2025 年 5 月 1 日起施行,个人信息处理者需要按规定开展合规审计。落到系统上,含义很具体:授权记录、操作日志、处理目的说明要能随时导出,而不是审计前临时补材料。
第四层是跨境。2024 年 3 月 22 日施行的《促进和规范数据跨境流动规定》明确了若干免予申报数据出境安全评估、订立个人信息出境标准合同、通过个人信息保护认证的情形,其中就包括按照依法制定的劳动规章制度和依法签订的集体合同实施跨境人力资源管理、确需向境外提供员工个人信息的情形。需要留意的是,“免予”的是上述三项机制,并不等于免除法定义务——制度是否依法制定、传输是否确有必要,仍要由企业自己举证。
第五层是签署与留存的证据链。人社部发布过电子劳动合同订立指引,电子签名法为电子签名的效力提供基础。系统层面要保证三件事:签署主体身份可核验、签署意愿可证明、合同原文完整且可回读。
第六层是留存与删除。劳动合同、考勤记录、工资支付记录的保存期限各有要求,到期后的归档与删除策略要提前定好,否则系统里会留下一批“不知道该不该删”的数据。安全侧的等保定级、日志留存、传输与存储加密,通常由 IT 统一把关,也应当在选型阶段就写进需求。
实施顺序有一条被反复验证过的路线:主数据、核心人事、考勤、薪酬。倒过来做一定返工——先上薪酬,就得回头补组织与人员口径;先上考勤,就得回头补排班规则。
并行期至少覆盖一个完整薪酬周期。新旧两套各算一遍,逐人对账。并行的意义不是“求稳”,而是把口径差异提前暴露出来:差异清单本身就是最有价值的上线文档。
验收指标建议用业务结果,而不是功能点数:算薪一次成功率、考勤异常的平均处理时长、接口成功率与补偿次数、员工自助使用率、月结关账天数。这些数字能说明系统是否真的在用,也能说明上线后的运维负担。
上线之后还有三件事要有人负责:规则变更谁改、版本怎么升、每年社保基数调整与个税政策变化谁来跟进。这三件事没有归属,系统会在第二年慢慢退化成一个昂贵的电子档案柜。
• 接口清单是否在合同前确认。接口在实施中期才“对一下”,几乎必然延期。选型阶段就该把主要接口的方向、字段、频率写进方案。
• 规则归属是否清晰。业务规则由 HR 定义,系统配置由谁维护、变更如何验证,要有明确分工,否则每次政策调整都会变成一次跨部门扯皮。
• 供应商的交付与运维能力。实施顾问是否懂业务、是否有本地化支持、版本迭代节奏如何。HR 系统的价值一半在软件,一半在交付。
明基逐鹿软件(苏州)有限公司
