HR软件系统实施上线前，到底要准备哪些数据？一篇写给“实战派”的避坑指南
说真的，每次提到HR系统上线，很多HR同行的第一反应可能不是兴奋，而是头皮发麻。尤其是想到那堆积如山的历史数据，Excel表格满天飞，每个人的入职日期、合同年限、薪资结构都不在一个标准上……这简直就是一场“数据大迁徙”。
我见过太多项目，软件本身功能强大得不行，结果因为前期数据准备得一塌糊涂，上线后闹出“张三的工龄算错了”、“李四的工资发少了”这种致命笑话。最后锅还得HR自己背，老板可不管是不是系统的问题，他只看结果。
所以，今天咱们不谈那些虚头巴脑的理论，就聊点实在的。如果你正准备上新系统，或者正在为数据发愁，这篇东西应该能帮到你。咱们用最接地气的方式，把数据准备这事儿捋清楚。
一、 先搞清楚“地基”：基础档案数据
任何HR系统，最底层的逻辑都是“人”。没有人，系统就是个空壳。所以，第一块硬骨头，就是员工主数据。
很多人觉得，不就是把名字和身份证号导进去吗？哪有那么简单。这里有个非常容易踩的坑，叫“历史遗留问题”。
1. 唯一标识符的确定
你得先问自己一个问题：在这个公司里，谁是唯一的“张三”？是工号？是身份证号？还是系统自动生成的ID？
在数据清洗时，最怕的就是工号重复或者一人多号。比如，以前离职又入职的员工，HR偷懒没建新档案，直接在原档案上改了入职日期。这种数据直接导入新系统，绝对是灾难。因为系统逻辑里，这可能意味着他的连续工龄从十年前算起，但实际上他中间断了三年。
建议： 必须以“身份证号”作为核心唯一键（当然要符合法律法规）。如果系统允许，给每个人生成一个唯一的员工ID。对于历史数据中身份证号缺失或者错误的，必须单独拎出来，人工核对，这是死命令，不能含糊。
2. 组织架构的标准化
你的组织架构图在Excel里可能是这样的：
- 销售部（王总管）
- 销售部-华东区（李经理）
- 销售部-华东区-上海组
但在系统里，这可能需要严格的层级关系：公司 -> 事业部 -> 部门 -> 二级部门 -> 岗位。
如果历史数据里，有的人挂在“销售部”下面，有的挂在“销售部-华东区”下面，系统在做报表时就会乱套。比如，你想统计全公司的销售人数，可能就漏掉了那些挂在大部门下面的人。
所以，导入前，必须画一张标准的组织架构树，把所有部门代码化。比如“XS-BJ”代表北京销售部。所有人的归属必须严格对应到树的最末端叶子节点。
二、 最敏感也最要命：薪酬与考勤数据
如果说员工档案是面子，那薪酬考勤就是里子，更是真金白银。这块数据要是错了，员工直接找上门吵架，HR部门的信誉瞬间崩塌。
1. 薪酬结构的拆解
这是最考验HR专业度的地方。很多老系统的薪酬数据是一坨浆糊。
比如，旧系统里只有一个“总工资”字段，或者只有“基本工资”和“绩效工资”。但新系统通常要求精细化管理，你需要把薪酬拆解成：基本工资、岗位工资、绩效工资、工龄工资、各类补贴（餐补、交通补、通讯补）、扣款项目（社保、公积金、个税）等。
这里有个现实问题： 很多公司的薪酬发放是“打包”的，员工只知道到手多少钱。你让财务拆解去年的历史数据，他们可能都拆不出来。
如果拆解不出来怎么办？通常的做法是：
- 分段处理： 比如，只导入近一年的明细，或者只导入最近一次发薪的结构。
- 关键字段必填： 哪怕拆不细，“基本工资”这个字段必须准确。因为很多社保基数、加班费计算都依赖它。
2. 社保公积金基数的“坑”
社保和公积金的缴纳基数，每年都会调整。在数据准备时，你必须理清楚两个时间点：
- 当前执行基数： 现在正在按什么标准交？
- 历史调整记录： 今年7月份调的基数，系统里能不能追溯到7月之前的基数？
如果新系统要做成本分析，或者计算离职补偿金，它需要知道员工在去年的月平均工资是多少。如果你只导入了当前的基数，系统算出来的结果就是错的。
（插一句，这块数据最好直接找财务要，他们手里的发放记录是最准的，别自己瞎猜。）
3. 考勤规则的“翻译”
考勤数据准备，其实是在做“翻译”工作。把公司的土政策，翻译成系统听得懂的逻辑。
比如，公司规定“迟到10分钟以内扣20元”。在系统里，你可能需要设置一个规则：迟到时长 <= 10分钟，触发扣款规则A（金额20）。
最难的是年假数据。
- 年假是按司龄算的？还是按自然年清零的？
- 员工离职时没休完的年假，要折算成钱吗？
- 历史剩余年假有多少？
这个数据如果没盘点清楚，上线第一天就会有人投诉：“我明明还有5天年假，怎么系统显示是0？”
三、 流程与权限：看不见的“骨架”
数据不仅仅是填数字，还包括各种逻辑关系和权限设置。这部分工作往往被忽视，但决定了系统好不好用。
1. 审批流的梳理
在旧模式下，请假可能就是口头跟主管说一声，或者在微信上发个消息。但在系统里，必须走流程。
你需要提前准备好一张“审批权限映射表”。
| 业务类型 | 审批人逻辑 | 备注 |
|---|---|---|
| 请假（<3> | 直接主管 | 无需更高级别审批 |
| 请假（>=3天） | 直接主管 -> 部门总监 | 必须逐级审批 |
| 报销 | 直接主管 -> 财务审核 | 金额超过5000需VP审批 |
如果不把这个表理清楚，系统上线后就会出现“找不到审批人”或者“该批的没批，不该批的乱批”的情况。
2. 角色与权限的分配
谁看得到什么数据？谁能修改什么数据？这是数据安全的核心。
你需要列出一个清单，通常包括：
- 超级管理员： IT或HR负责人（通常1-2人）
- HRBP/专员： 能看到自己负责部门的所有员工全档案，能修改部分信息。
- 部门经理： 只能看到自己部门下属的简历、考勤、绩效，只能审批，不能修改档案。
- 普通员工： 只能看自己的信息，提交申请。
千万别为了省事，给所有人开“上帝视角”。一旦敏感薪酬数据泄露，后果不堪设想。
四、 历史数据的“断舍离”：迁移策略
说到这，你可能要问了：“那我到底要把多久的历史数据搬进去？”
这是一个典型的“既要又要”的问题。理论上，数据越全越好。但现实中，数据迁移是有成本的，而且旧数据往往脏得没法看。
我建议采用“分层迁移法”：
1. 核心层（必须迁移）
包括：员工基本信息、当前合同信息、当前薪资标准、当前社保公积金基数、当前组织架构归属。
原则： 确保上线第一天，发薪、考勤、合同管理能正常运转。
2. 业务层（选择性迁移）
包括：过去1-2年的绩效结果、过去1年的薪资发放记录、过去1年的考勤打卡记录。
原则： 用于新系统做数据分析和对比，比如同比环比。
3. 归档层（不迁移或封存）
包括：5年前的绩效记录、离职员工的详细档案（除非法律要求）、零散的纸质扫描件。
原则： 这些数据建议单独建立一个“历史数据库”或者干脆封存备查，不要混入新系统，以免拖慢运行速度，增加管理复杂度。
特别提醒： 在迁移前，一定要做数据清洗。怎么洗？
- 去重： 用Excel的透视表或者VLOOKUP，把身份证号重复的人揪出来。
- 补缺： 性别、出生日期、入职日期，这三个字段不能空。身份证号可以推导出性别和出生日期，这是个好办法。
- 格式统一： 比如“部门”字段，全是“销售部”、“销售部(总部)”、“销售部-总部”，必须统一成一个名字。
五、 测试，测试，还是测试
数据准备好了，导进系统就完事了？千万别！
你必须进行“沙盘推演”。
1. 模拟发薪
找几个典型的员工样本（比如：刚入职的、老员工、有请假的、有加班的、有晋升调薪的）。
在测试环境里，按照新系统的逻辑跑一遍工资。然后拿计算器（或者Excel）手工算一遍，看看结果是否一致。如果差了几分钱，都要查出原因。是四舍五入的问题？还是逻辑设置错了？
2. 边缘案例测试
专门找那些“不正常”的数据去测试系统边界。
- 入职日期是2月29日的人，平年怎么算周年？
- 跨月请假（比如2月28日到3月2日），考勤怎么拆分？
- 中途入职的员工，年假按比例折算对不对？
很多时候，系统崩就崩在这些小概率事件上。
六、 所谓的“数据准备”，其实是在做管理
写到这里，你会发现，准备HR系统的数据，表面上是在整理Excel表格，实际上是在梳理公司的管理流程。
你把数据理顺了，你会发现：
- 原来公司里有3个同名同姓的人没被发现。
- 原来有5个人的合同早就过期了还在发工资。
- 原来各部门的汇报关系早就乱成一锅粥了。
这就是为什么很多公司上了HR系统后，管理效率反而提升了。因为被逼着把历史烂账给清理干净了。
数据准备是一项浩大的工程，它枯燥、繁琐，甚至有点反人性。但请相信我，你在前期投入的每一分钟，都会在系统上线后以“准确无误的工资条”和“流畅的审批体验”回报给你。
所以，别怕麻烦。拉个清单，找几个靠谱的同事，甚至请财务帮帮忙，分模块、分阶段地去攻克它。当系统顺利跑通第一个月，你会发现，之前熬的那些夜，掉的那些头发，都值了。
电子签平台