吐糟一下“国有企事业人力资源数智化领航者”

近期在一家客户这里做Tableau项目，客户既有浪潮的ERP系统，也有宏景HR等其他业务系统。由于我的项目涉及到数据库层面的取数、处理，因此就会了解到不同工具背后的数据库设计、数据表设计等内容。

日久天长之后我发现，国产系统的薄弱，很大一方面在于“偷懒”，其实是“凑合”心态。长此以往，软件的bug越来越多，系统的客户满意度也会随之降低，然后客户再进入换软件、再换软件的循环中。

1

举个例子，我今天在宏景系统的数据处理中，发现一个hr- code竟然会对应完全不同的两个人！如下所示：

直觉是数据出错了，后来才发现这个是普遍现象，如下所示。一个hr-code可以对应多个人员库中的不同人（employee-id /身份证号码不同）。这么看来，这是系统设计时就没有考虑hr-code全局唯一。

为什么会这样？这不科学！

一个HR系统，竟然不能保证“人员编码”的唯一性，那这个编码体系就不具有可用性，还是要使用职工的“身份证ID”，但这样就面临数据安全性的问题。

为什么会这样？AGAIN！

我们仔细看一下宏景的设计会发现，它不仅区分了在职、减员、不在岗、离退休四个阶段，而且区分了人员、兼职、异动三个场景，然后为此设计了12个表来存放相关的数据。如下所示：

• 在职库  usra01，usra09，usra03 ， 分别是人员表、兼职表和异动表

• 减员人员库 Reta01，Reta09，Reta03 ，分别是人员表、兼职表和异动表

• 不在岗人员库 Bzga01 Bzga09，Bzga03，分别是人员表、兼职表和异动表

• 离退休人员库 Ltxa01 Ltxa09，Ltxa03，分别是人员表、兼职表和异动表

所以，我在用Prep合并人员信息时，不得不像下面一样跨越很多表完成Union（当然也可以用SQL UNION）。

当初做到这里，我只能惊讶地掉下来下巴，高呼，“我的天呐”！

2

像宏景这样的HR业务数据库，它的背后离不开坚定的数据库知识、数据模型知识，以及业务知识。这就要求产品经理、产品工程师，包括为客户交付和配置环境的实施工程师，既要了解业务，又要熟知技术，方可作出最佳选择。

从上面宏景的分表来看，我看不出这样做的理由。因为每个表中的数据几乎一致，也就是说，它们对应几乎完全一样的业务过程。

用一句话说，每个表都是记录“谁、何时入职、姓名、性别、婚姻状态等个人信息”，区别在于所处的职业阶段（在职、离职、离退休、不在岗）和人员来源（内部人员、兼职等）。它们可以视为人的属性。

人的职业阶段变化，甚至可以视为“岗位调动”的特殊形式——离退休，就是从当前岗位调整到“家里蹲”的岗位。

既然如此，为什么还要大费周章地分那么多表，然后还要考虑人员直接的跨库增删，甚至出现了开篇的问题：

当员工A从在职状态离退休后，它的hr-code（比如某主管-101）会被后来的新人重新使用。

这就是典型的业务问题，和技术实现的脱节。

说到这里，吐槽一下宏景的网站。号称“国有企事业人力资源数智化领航者”。乍一看，它占据了天时、地利、人和——深处“国有企业国产化”的大时代、深处企事业单位聚集的北京、做的还是“人力资源”这种敏感生意。

只可惜，它忘了一点——只有精湛的技术，而不是政治或当前的“舒适区”，才会让它长久的活下去。归根结底，“国有企事业单位”不是我们以为的“有钱的傻大粗”，它们也是客户，它们也追求最终的使用体验。

作为数据行业从业者，有时候恨其不争。

关于宏景：国内“最具专业实力”的e-HR专业厂商，专注于国有企事业单位人力与人才管理数智化产品的研发和应用推广，累计服务的中大型国有企事业单位超5000家。

宏景软件经过20多年的深耕打磨，将现代管理理念、先进技术与国有企事业单位人力资源管理相结合，先后推出宏景e-HR、宏景HCM、宏景云等系列产品，产品功能强大、稳定性好，全面支持国产化，是国内人力与人才管理软件中备受用户青睐的数智化软件产品。

@喜乐君