花了上百万、忙了一两年，终于把全集团HR系统“统一”了。上线之前，所有人都在说：系统上线后，数据打通了，报表自动了，决策有依据了。上线之后，你打开系统，可能连一份人力报表都拉不出来，或者同一份报表，不同人拉出来不一样；同一个问题，问系统、问子公司、问Excel，三个答案。

到底为什么？

一、数据迁移：历史信息被“搬”进了新系统

新系统的数据是哪儿来的？从旧系统搬过来的。

旧系统用了几年、十几年，里面本来就有大量错误——同一人在不同模块信息不一致、已离职未标记、组织架构变更没同步、岗位名称有七八种叫法。这些错误在旧系统里就是“历史遗留问题”。

数据迁移的逻辑是：旧系统有什么，就搬什么。做一次映射、跑一次脚本、数据就过去了。错的数据从旧系统搬进新系统，换了个地方继续错，甚至因为映射规则出偏差，本来对的也被改错了。

更隐蔽的问题是：新系统上线时，很多数据不是从旧系统迁移过来的，是从Excel手工录进去的。不同子公司、不同时段、不同人录入，格式不统一、字段不全、校验不严。错误在迁移中产生、在录入中叠加、在系统里沉淀。

二、口径定义：同一个字段，填的根本不是同一个东西

你认为的“入职日期”和子公司HR认为的“入职日期”是同一个意思吗？不一定哦。有的人填Offer发送日，有的人填劳动合同签署日，有的人填实际到岗日。系统里只有一个“入职日期”字段，但背后至少有三种不同理解。

员工状态呢？试用期算在职还是算“试用期”？停薪留职的算不算在职？借调到其他公司的算不算离职？口径不统一，系统里填出来的人数和结构，数据之间根本不可比。

薪酬数据也一样。“月薪”是税前还是税后？包含年终奖还是只算固定部分？各地区社保基数、公积金比例都不一样，拉一张全集团薪资报表的时候，加总出来的数字能说明什么？

集团层面没有统一的数据字典，或者有但没人执行。系统是统一了，但人没有统一。

三、多系统并行：数据源不唯一，信谁都不对

新系统上线了。但旧系统没停——有的是想停停不掉，有的是不敢停，有的是嫌麻烦。于是新旧系统并行运行。同一个员工，新系统显示在职，旧系统显示已离职，因为离职手续只在旧系统里走完了，新系统里还没同步。

还有OA、财务、考勤、绩效，各有一套数据。组织架构在OA里是一套，在HR系统里是另一套；人员名单在考勤系统里是一套，在HR系统里又是一套。更严重的是，不同系统间的数据口径本身就存在冲突，数据“打架”，到了决策者面前变成“不知道该信谁”。

数据源不唯一，就没有真相。各系统之间的对接靠接口，接口不稳定，同步有延迟，还时常断。

四、一线录入：应付心态下的数据“注水”

新系统意味着更多录入工作。原来Excel里填一张表，现在系统里要填三张。原来拍个脑袋就能定的事，现在要录一堆字段才能走完流程。

对一线HR和业务部门来说，录数据是“额外的工作”。赶时间、嫌麻烦、不愿意学新系统——填错了也没人管。系统里设了必填字段，就随便选一个填上；设了格式校验，就找办法绕过去，先把流程走完。

五、系统设计与业务实际脱节：系统里没有“例外”的容身之处

系统上线之前，业务部门提了一堆需求。上线之后发现，很多业务场景系统里根本跑不通。

比如借调：跨单位借调，人事关系不动，薪酬发放主体可能变、也可能不变，系统里没有这个状态怎么办？

跨单位兼职、阶段性停薪留职，甚至有些子公司有自建的“特殊人才通道”，系统都不支持。

最终一线只能绕着走。明明应该走“借调”流程，但系统里走不通，只好用“离职+再入职”代替。系统数据自然失真。系统管不了“例外”，业务就绕过系统，数据就成了“系统里的数据”和“真实业务”两回事。

六、上线后没人对数据负责：数据质量是“无主之地”

上线前，项目组负责数据迁移。上线后，项目组撤了，数据交给运维。

但运维只管系统跑不跑得动，不管数据对不对。业务部门只管用系统办事，不关心系统里沉淀的数据质量。IT说“数据是业务的事”，业务说“数据是系统的事”，HR说“数据是IT的事”。

没有人对数据质量负责。错的数据没人改、没人追责、没人关心，导致错误数据越积越多。

七、管理者只关心“上线”，不关心“数据质量”

HR系统项目立项时，关注点永远是功能。能跑通招聘流程吗？能不能算薪酬？报表能不能自动生成？至于“数据准不准”，默认是“上了系统就自然准了”。

上线是硬指标，数据准备仓促，清洗不彻底，迁移不完备。项目验收时看的是“功能是否实现”，那么数据可不可信呢。验收通过了，项目组撤走了，留下一堆数据的坑。

不可信的数据，比没有数据更可怕。