HR数字化转型，历史数据清洗和迁移，这活儿真不是敲几下键盘那么简单

聊到HR的数字化转型，老板们总是很兴奋，PPT上画的都是“智能”、“高效”、“数据驱动”。但真正落到我们这些干活的人头上，最头疼的往往不是新系统怎么用，而是那些躺在旧系统里、Excel表格里，甚至是十几年前纸质档案里的“陈年旧账”。

说白了，新系统就像一间精装好的新房子，看着是真漂亮。但你想搬进去住，总不能把旧房子里的破烂儿一股脑全搬过去吧？那些数据，就是我们要处理的“破烂儿”。处理不好，新系统跑不起来，跑起来也是垃圾进、垃圾出，最后老板一看报表，发现数据对不上，锅还是我们HR的。

所以，今天咱们就抛开那些虚头巴脑的概念，聊点实在的，怎么把历史数据这摊浑水给理清，再安安稳稳地搬到新家去。这活儿，我愿称之为“给HR系统做一次彻底的肠胃镜检查和手术”。

第一步：别急着动手，先当个“考古学家”

很多人一拿到任务，马上就开始导出数据，然后对着Excel一通猛操作。这是大忌。在动手清洗之前，你得先花足够的时间去了解你的数据，就像考古学家挖到文物，得先小心翼翼地清理、研究，而不是直接拿刷子使劲刷。

1.1 搞清楚你的“家底”到底是什么样的

先别管新系统需要什么格式，先看看旧数据长什么样。把所有能找到的数据源都列出来，包括但不限于：

• 核心HR系统：比如用友、金蝶、SAP之类的，这是主力。



• 各种Excel表：这是重灾区。员工信息表、薪资表、考勤记录、绩效表……可能散落在不同部门、不同人的电脑里，文件名可能是“最终版”、“最终版(1)”、“绝对不改版.xlsx”。
• 纸质档案：特别是那些老员工，或者一些特殊岗位的记录，可能还在档案柜里。
• 其他业务系统：比如招聘系统、培训系统，甚至财务系统里都可能有人事相关的数据。

这个阶段，你的目标是形成一份《数据资产清单》，把每个数据源的字段、数据量、更新频率、负责人、存储位置都记下来。别嫌麻烦，这一步做好了，后面能省一半的命。

1.2 定义什么是“脏数据”

“脏数据”这个词很笼统，我们需要把它具体化。在HR的语境里，脏数据通常指以下几种情况：

• 不完整的：比如身份证号少了一位，手机号是空的，入职日期没填。
• 不准确的：比如员工已经离职了，但系统状态还是“在职”；或者一个员工在系统里有两条记录，一条是入职时的，一条是转岗后的。
• 不一致的：比如A表里的部门叫“市场部”，B表里叫“市场营销部”；或者同一个员工的出生日期在不同表里不一样。
• 不规范的：比如日期格式，有的写“2023-01-01”，有的写“2023/1/1”，还有的写“23年1月1号”。性别，有的写“男”，有的写“M”，有的甚至是“1”。
• 重复的：同一个员工因为历史原因，在系统里有多个ID。

把这些“脏”的类型定义清楚，后面清洗的时候才有标准可依。

第二步：制定规则，这是“立法”环节

数据清洗不是随心所欲的，必须有严格的规则。这个环节，你要扮演一个“立法者”，为你的数据世界建立秩序。

2.1 数据标准规范

在清洗之前，必须和IT部门、新系统的供应商一起，制定一套数据标准。这套标准就是新系统的“宪法”。主要包括：

• 字段定义：每个字段叫什么，是什么意思。比如“员工状态”，新系统里可能只允许“在职”、“试用”、“离职”、“退休”这几种，那旧系统里的“待离职”、“长期病假”就得归到这几类里。
• 格式规范：日期统一用YYYY-MM-DD，手机号必须是11位数字，姓名中间不能有空格等等。
• 代码规范：部门、岗位、学历等，最好用代码。比如“本科”的代码是“B01”，“硕士”是“B02”。这样可以避免“本科”和“大学本科”这种歧义。

这个标准最好能整理成一个文档，比如下面这样，方便随时查阅：

字段名称	旧数据常见形式	新系统标准	清洗规则
入职日期	2020.05.06, 2020/5/6, 20200506	YYYY-MM-DD	统一转换为2020-05-06
部门	研发部, 研发中心, R&D	部门代码 (如RD01)	映射到RD01
学历	本科, 学士, 大学	学历代码 (如B01)	映射到B01

2.2 数据清洗策略

对于不同类型的脏数据，处理方式也不同：

• 直接修正：对于明显的格式错误、拼写错误，写个公式或者用工具直接批量修正。
• 关联补全：比如有员工的部门信息缺失，但有他的工号，可以通过工号在其他表里找到部门信息，然后补进去。
• 标记处理：对于无法确认真伪的数据（比如两个不同的出生日期），不要瞎猜。可以标记出来，交给业务部门或者员工本人去核实。宁可数据暂时缺失，也不能引入错误信息。
• 删除归档：对于重复的数据，要确定保留哪一条，然后把另一条标记为“归档”或删除。这个操作一定要谨慎，最好先备份。

第三步：动手清洗，这是一场“硬仗”

规则都定好了，现在可以开始真正的清洗了。这个过程通常是枯燥、耗时且容易出错的。

3.1 工具的选择

别一上来就想用什么高大上的ETL工具，对于大多数公司来说，Excel和SQL就是最趁手的武器。

• Excel：数据量不大（比如几万行以内）时，Excel是yyds。VLOOKUP、INDEX+MATCH、数据透视表、条件格式，这些功能足够你完成大部分清洗工作。特别是VLOOKUP，用来做数据匹配和补全，简直是神器。
• SQL：如果数据量比较大，或者需要从多个数据库里抽取数据，那SQL是必须的。写几个查询语句，把数据关联起来，再用UPDATE语句修正错误，效率比Excel高得多。
• Python/R：如果你懂编程，用Python的Pandas库来做数据清洗，那更是如虎添翼。可以写脚本自动化处理，特别是需要重复操作的时候。

不管用什么工具，核心思想都是一样的：先抽样检查，再批量处理，最后全面验证。

3.2 清洗的顺序

清洗也是有顺序的，一般是先主后次，先大后小。

1. 清洗主数据：先清洗员工基本信息，比如姓名、工号、身份证号、部门、岗位。这些是核心，其他数据都依赖它们。
2. 清洗关联数据：然后是薪资、合同、绩效、考勤等数据。这些数据需要和主数据关联，所以主数据必须是干净的。
3. 处理特殊数据：比如员工的自定义字段、历史异动记录等。这些数据结构可能比较复杂，需要单独处理。

举个例子，要清洗“部门”这个字段。旧数据里可能有“市场部”、“市场营销部”、“市场中心”、“市场(MKT)”。

第一步，用Excel的“筛选”功能，把这些不同的叫法都找出来。

第二步，对照你之前制定的《数据标准规范》，确定它们应该对应哪个新部门代码。比如，都对应“MKT01”。

第三步，用“查找和替换”功能，先把最明显的“市场部”替换掉。对于“市场(MKT)”这种，可能需要用LEFT、MID等文本函数提取出“市场”两个字，再做替换。

第四步，全部替换完后，再用数据透视表检查一下，看看是不是所有“市场”相关的部门都变成了“MKT01”，有没有漏网之鱼。

3.3 数据去重和关联

数据去重是个大难题，特别是同名同姓的员工。光靠名字肯定不行，必须用多个字段来判断，比如“姓名+身份证号”、“姓名+手机号”、“姓名+出生日期”。

在Excel里，可以用“条件格式”里的“突出显示重复项”来快速找到重复值。但要判断哪条是有效的，哪条是需要删除的，就得人工介入了。通常的原则是：

• 保留信息最全的那条记录。
• 如果信息差不多，保留最新更新的那条。
• 如果还是分不清，就只能去查纸质档案或者问本人了。

对于历史数据，最常见的问题是“一人多号”。比如一个员工，入职时给的工号是001，后来离职了又重新入职，给了个新工号002。在新系统里，我们希望他只有一个唯一的ID（比如身份证号或者系统自动生成的GUID），所有历史记录都挂在这个ID下面。这就需要做数据关联，把他的多条历史记录合并到一起。这个工作通常需要IT部门协助，通过脚本来完成。

第四步：验证，这是“质检”环节

数据清洗完了，千万别急着导入新系统。你得先自己验一遍，确保质量过关。这就像工厂生产出来的零件，得先质检，不能直接装到机器上。

4.1 自我验证

这一步主要靠逻辑检查和统计分析。

• 完整性检查：关键字段（姓名、工号、部门、入职日期）的空值率是多少？如果超过1%，说明清洗得不彻底。
• 一致性检查：随机抽取100条数据，人工核对原始数据和清洗后的数据，看看转换规则有没有执行错。
• 逻辑性检查：比如，员工的入职日期不能晚于他的合同终止日期；出生日期和身份证号里的出生年月日要对得上；离职员工的离职日期不能为空。
• 统计分析：用数据透视表看看各部门人数、各学历人数、男女比例等，和旧系统里的报表对比一下，看看总数有没有大的出入。如果差异很大，说明清洗过程中可能有数据丢失或错误合并。

4.2 业务方验证

HR自己检查完了，还得让业务方（比如薪酬组、招聘组的同事）来验证。因为他们最了解业务，能发现一些HRIT发现不了的问题。

可以抽几条有代表性的数据，比如一个刚入职的、一个准备离职的、一个有调薪记录的，把清洗前后的数据都给他们看，让他们确认是不是正确。或者，把清洗后的数据导出一个Excel，让他们自己去筛、去看，提反馈意见。

这个过程可能会来回拉扯好几遍，但一定要有耐心。在系统上线前发现问题，总比上线后发不出工资、算错考勤要好得多。

第五步：迁移，这是“搬家”本身

数据清洗干净、验证通过后，终于可以开始迁移了。迁移通常有两种方式：一次性迁移和分步迁移。

5.1 一次性迁移（Big Bang）

就是选一个周末，把旧系统关掉，把所有清洗好的数据一次性导入新系统，下周一所有人直接用新系统。

• 优点：简单直接，没有新旧系统并行的混乱。
• 缺点：风险极高。一旦迁移失败或者数据有问题，整个HR业务就瘫痪了。而且，如果数据量特别大，迁移时间可能很长，甚至超过一个周末。

这种方式适合数据量不大、业务相对简单的公司。

5.2 分步迁移（Phased Migration）

就是把数据分批次迁移到新系统。比如，先迁移在职员工的基本信息，再迁移薪酬数据，或者先在一个部门试点，成功后再推广到全公司。

• 优点：风险可控，即使出问题影响范围也小。可以逐步验证新系统的稳定性。
• 缺点：在一段时间内，需要维护新旧两个系统，工作量大，容易出错。比如，员工在新系统里转岗了，但旧系统里还没更新，薪酬组就可能搞错。

对于大多数有一定规模的公司，我更推荐分步迁移。虽然麻烦点，但稳妥。

5.3 迁移前的准备工作

无论哪种方式，迁移前都必须做好以下准备：

• 备份！备份！备份！：旧系统的数据、清洗好的数据，都要做多个版本的备份。这是你的救命稻草。
• 写好迁移脚本：如果需要IT写脚本来导入数据，一定要和他们反复确认数据格式、字段对应关系、异常处理逻辑。
• 做一次完整的演练：找一个测试环境，把迁移过程完整地走一遍。这是发现潜在问题的最后机会。演练中要记录每一步花了多长时间，这样正式迁移时才能准确预估。
• 制定应急预案：如果迁移失败怎么办？如果数据导入后大面积报错怎么办？如果新系统跑不动怎么办？必须有Plan B。

第六步：迁移后，别忘了“开荒保洁”

数据导入新系统，不代表万事大吉。新系统就像刚装修好的房子，还需要“开荒保洁”。

6.1 数据校验

迁移完成后，要立刻进行数据校验。这次校验比清洗时的验证更直接，是看新系统里的数据和你准备的数据是否一致。

可以写一些SQL查询，或者用新系统自带的报表功能，对比两边的数据量、关键字段的值。比如，随机抽取50个员工，看他们在新旧系统里的入职日期、部门、薪资是否完全一样。

6.2 试运行

让一小部分用户（比如HR部门的同事）先用起来，处理一些真实的业务，比如办理一个入-职、开一个证明、算一次月度薪酬。在试运行中，你可能会发现：

• 有些数据虽然洗干净了，但不符合新系统的业务逻辑。
• 有些字段在新系统里是必填项，但旧数据里没有，导致无法保存。
• 用户操作习惯和新系统不匹配，导致误操作。

这些都是在试运行阶段需要解决的问题。别怕暴露问题，早发现早解决。

6.3 建立数据质量监控机制

数据清洗和迁移不是一劳永逸的。新系统上线后，还会有新的数据进来，也可能因为操作不当产生新的“脏数据”。所以，需要建立一个长期的数据质量监控机制。

比如，可以设置一些自动检查规则：新入职员工的身份证号必须是18位，手机号必须是11位；部门调整时，必须选择系统里已有的部门。通过系统约束，从源头上减少脏数据的产生。

同时，定期（比如每个季度）跑一次数据质量报告，看看关键字段的空值率、重复率有没有升高，及时发现问题并处理。

HR的数字化转型，说到底是一场管理变革，而数据是这场变革的基石。清洗和迁移历史数据，这个过程虽然痛苦、琐碎，甚至有点“脏”，但它却是整个转型中最关键、最能体现专业性的一环。把这件事做好了，新系统才能真正发挥价值，而不是成为一个昂贵的摆设。这个过程，考验的不仅是技术，更是我们的耐心、细心和责任心。慢慢来，别急。

猎头公司对接