多元化集团企业主数据治理项目实施的三个难点及应对措施

中国企业数据治理联盟（www.chinaedg.com/）

进入》主数据管理    企业数据治理   信息资源规划   数据安全管理

前言

随着大数据、人工智能、云计算等新技术的蓬勃发展，数据治理对于大型集团企业的经营管理越来越重要。一个完整的数据治理项目包含项目准备、现状体系调研与分析、标准体系构建、数据管理平台搭建、数据清洗、数据服务集成、运营体系建立等七大阶段。

本文主要针对大型集团企业数据治理项目实施过程中关于“标准体系构建”和“数据服务集成”两个阶段所涉及的3个问题进行讨论，包括主数据模型标准制定、主数据集成设计及人事类主数据应用等问题。这3个问题是从多元化大型集团企业数据治理项目中总结出的难点，解决方案可能不具有广泛适用性，但基本原则和大致思路有一定的参考借鉴意义。

一主数据模型标准的制定难点

1.1主数据模型标准制定

根据主数据管理实践白皮书，简单来说，主数据是指各个系统间共享的数据，往往会涉及到人员、组织机构、会计科目、银行账户、外部单位、物料等。这些数据需要通过一系列编码标准和描述标准定义后才可供下游系统使用，编码的构成可根据实际需求设定，可以由系统按照一定的规则自动分配流水码来实现。

主数据模型标准通常由一个或多个自然属性字段共同构成，通过不同的特征量、取值、符号等唯一确定不同功能的描述目标，而且自然属性必须具备客观性、稳定性和唯一性，例如一款商品的规格型号、某人的出生日期、企业的统一社会信用代码等，都可以当作是某一类主数据的某一项描述属性。

1.2主数据模型标准制定难点剖析

主数据模型标准必然要从定义本身出发，但在实际项目中，由于每个企业的信息化建设进程不同，有时主数据标准会被迫加入一些业务型字段信息，例如有的企业把ERP的物料工厂信息、采购组织信息、仓库信息等也加入到物料主数据标准中，仅仅是为了减少业务人员的工作习惯调整和操作便利。

从定义角度来看，标准应具有客观性、稳定性和唯一性；但从企业角度来看，还要考虑源头数据的兼容性、易用性和高效性。如果主数据标准中加入业务型字段信息，会使主数据系统直接管理变化型数据，这并不是主数据管理的优势所在。如果标准以定义为准，各类业务信息需要到相应业务系统逐一完善，又会对工作效率有一定的影响。那么主数据标准是否应该囊括业务型字段呢？

1.3应对措施

思路一：主数据系统只保证数据的唯一性，由下游目标系统统一维护业务信息。

优点：主数据系统负责数据的唯一性，下游系统负责业务信息的准确性，系统间各司其职，优势互补。

缺点：新增数据时，需要先在主数据系统维护基础信息，再到下游系统补录业务信息，应用系统切换导致工作流加长，没有连贯性，用户体验不是特别好。

思路二：下游系统提供业务字段及相应标准，主数据系统作为信息录入前端，将业务字段信息纳入主数据标准中。

优点：新增数据时，只需要在主数据系统统一申请即可，再往别的信息系统集中分发，用户体验度好。

缺点：随着企业的组织逐步扩展、IT系统逐渐增多、业务愈加复杂，主数据的维护成本和集成成本会大大增加，主数据系统会逐渐变成业务系统，严重违背了主数据管理的初衷。

综上所述，定义角度和企业角度并不冲突，两种思路各有优劣。一般来说，企业为了保证基础主数据的唯一性、准确性和完整性，在企业范围内实现共享利用，避免信息孤岛，建议采用思路一，业务字段由业务系统管理，也便于对后续业务的统一调整。考虑有的企业信息系统较少，业务也比较单一，当业务字段的数据较为稳定时（录入系统后变化周期较长），为了减少数据新增的工作流程，可以采用思路二。（一定要慎重考虑、立足未来）

二主数据集成设计的难点

2.1主数据集成的意义

企业建设主数据系统固化各类主数据标准、流程、权限及主数据代码库，打通不同系统、组织、业务之间的数据壁垒，通过统一集成分发机制实现基础主数据的全企业范围内共享，最终实现对企业数据的统一源头、统一标准、统一视图管理，为后续IT业务系统的建设提供数据保障。

如果将信息系统比喻成水库，那么系统集成就是将水库之间串并联而成的水道，水道上的水就是主数据，主数据从上游系统流通到下游，实现了数据共享。在好的集成设计中，数据流应具备稳定性、经济性和拓展性。

2.2数据流向难点剖析

如果以主数据系统作为源头，原有标准的废止和新标准的推广需要时间和过程，对企业现有系统和业务流程具有一定的冲击。事实上，一般企业的主数据项目启动较晚，信息系统建设已初具规模，有些系统的数据质量虽然不高但数据维度基本满足，可以作为源头系统，例如HR系统的员工信息和组织机构数据，但此类系统可能和下游系统存在兼容性问题。那么在集成设计时数据源头该如何选择呢？

2.3应对措施

思路一：以主数据系统作为数据源头，进行集中管控，向目标系统统一分发。

优点：主数据系统作为唯一的主数据入口，严格把关数据标准和质量，规范维护法则，实现数出同源、规范共享。作为主数据官方出口，当数据出现问题时，无需多系统协调，只需在主数据系统中修复即可，严格保证数据的唯一性、准确性和完整性。

缺点：项目实施过程中，为了保证数据的一致性，一些已建成系统需和主数据系统重新开发接口并采用前期制定的主数据标准，可能会对已建成的系统和业务流程带来一定的冲击，增加企业的资源成本。

思路二：以已建成系统作为数据源头，数据审批完成生成正式编码后，提交给主数据系统进行统一的备案管理。

优点：不调整已建成系统的原有数据结构，在其基础上进行数据清洗，不仅提高了已建成系统的数据质量，减少对现有业务和系统的影响，也降低了主数据项目成本。

缺点：当源系统无法满足下游目标系统的数据需求时，需要对源系统进行相应调整，同时源系统-MDM-目标系统的接口程序也需要做相应调整，维护成本高，同时随着集成的需求和逻辑逐渐增加和复杂，给源系统带来一定的承载压力，不利于企业主数据的统一管理。

思路三：以一个源系统+主数据系统或多个源系统产生的同一主数据，在主数据系统统一汇集、整合、审批生成正式编码，形成多源头模式。

优点：充分利用现有系统的数据资源，不会对现有业务和系统带来较大影响，结合主数据管理的概念进行统一整合，实现主数据的统一规范管理，避免重复劳动，节约资源成本。

缺点：多源头主数据集成最大的风险在于数据质量管控，多个系统各自维护同一数据，如果没有严格的标准和法则进行约束，很容易出现不一致的情况，日积月累，数据质量问题就会显现。

主数据系统作为数据源头时，更适合新建企业或企业处在信息化建设的初期，存量数据较少、易于重新统建，后续加入的信息系统直接使用主数据即可。

已建成系统作为数据源头时，更适合处在信息系统建设中后期的企业，此阶段企业的数据存量大、维度高，在其基础上优化标准可以满足业务系统使用，但此类设计中不能过分要求系统之间的实时性，当系统之间存在兼容性问题时，建议采取线下传输的形式变通解决。

而多源头系统的集成模式在业务、逻辑、需求比较复杂的情况下，具有一定的灵活性和开拓性，但一定要注意应用时严格遵循相应的规章制度，保障高质量的数据为其他信息系统所用。

三人事类主数据的应用难点

3.1人事类主数据

人事类主数据包括人员和组织机构，人员包括企业的正式员工、外协员工、返聘员工、离退休人员、离职员工等，组织机构包括集团、公司、部门、事业部、班组等。不同岗位的人员组成部门，不同职能的部门构成企业，人员和组织机构是企业的运营基础，也是信息系统管理的核心元素。

3.2难点剖析

在主数据项目实施过程中，人事类主数据治理的难点不在于数据本身，而在于数据流向。基于IT系统和业务的需要，企业往往需要设立多套不同的人员和组织机构体系予以支撑，那么该如何建设好不同业务领域的人员和组织机构主数据呢？

3.3应对措施

思路一：主数据系统管理人员的基本信息和层级只到单位级的组织机构。

人事类主数据应用（思路一）

此方案中主数据系统只管理人员的基本信息和内部单位，其原因有以下3点：

1)在大型投资性企业中，部门级组织机构调整比单位级组织机构调整更频繁，不符合主数据系统的管理标准。

2)单位级组织机构调整只需修改上下级关系，对下游系统影响较小；而部门级组织机构与业务密切相关，调整时需要协同业务系统。

3)在主数据系统中，人员和单位信息数据标准化后与客商、银行账户、会计科目等主数据相辅相成，而部门类数据利用率较低。

结合上述3点原因，将人事类主数据分成单位和部门两部分，主数据系统管理单位，业务系统管理部门，不仅弥补了主数据系统对变化类数据的管理弱势，而且降低了组织机构调整对整个信息系统的冲击。部门调整和账务调整统一由业务系统管理，减少了冗余流程，提高了系统工作效率。此方案中各类数据的管理较为科学，符合主数据的管理标准，但对现有系统存在一定冲击，需要各系统相互配合。

思路二：人事类主数据以HR系统为源头，通过主数据系统向下游目标系统集中分发。

人事类主数据应用（思路二）

此方案中企业的信息系统共用一套人员和组织机构，一般企业的人员和组织机构由HR系统管理（也有其他系统管理的情况），主数据系统以这类系统作为人事类主数据的源头，数据清洗整合后，集中分发至下游系统使用。

这种思路实现了企业各系统在人事类数据方面的高度统一，但仅用一套人员和组织机构实现多领域系统的高耦合应用，通常伴有很多潜在风险，下面以财务域和行政域的人事类主数据应用举例说明：

风险一：一般的核算系统要求账务挂在末级部门下，且已被挂账的末级部门下不得新增部门，而在HR系统中，末级部门下新建部门通常没有限制。如果财务部门和人力部门不能解决系统兼容性问题，则两个系统无法共用一套人员和组织机构。

风险二：核算系统中人员的履历信息和账务调整有关，且通常情况下，履历信息不属于主数据管理的范畴。如果需要履历信息，核算系统可以和HR系统进行增量开发，但业务核算中特殊需求较多，接口方式并不利于核算系统灵活地解决业务问题。

风险三：HR系统中的组织机构是行政类组织机构，只涵盖实体部门，核算系统需在其系统内自行添加核算需要用的虚拟部门。

综上所述该思路起点高，但具有一定的局限性，不仅需要部门之间、系统之间的积极协调配合，还需要各系统具备一定的兼容性，弥补不同业务领域所带来的差异性。

思路三：在主数据系统中，建立多套人员和组织机构体系，满足各个领域系统业务的需求。

该思路以多领域系统的独立性为前提，同时以集团下发的官方文件为各系统的调整依据，既保证了独立性又具有相对统一性。下面以财务域和行政域的人事类主数据应用举例。

单一核算系统

人事类主数据应用-单核算系统（思路三）

因行政类组织机构和财务类组织机构不兼容，故形成两个视图，互不影响。HR系统负责行政类人员和组织机构的编码和维护；核算系统通过线下提供的调整说明书管理财务类人员和组织机构；主数据系统负责两个系统中人员和组织机构的唯一性。

当企业只有单个核算系统时，由核算系统管理财务类人员和组织机构更具优势，实现了数据变更和业务调整的内化解决，消除了人员和组织机构跨系统变更的复杂性。此方案中人员和组织机构的编码由HR系统和核算系统生成，两系统必须使用一致的编码规则进行配码，保持编码的统一性。

(2)多套核算系统

人事类主数据应用-多核算系统（思路三）

当企业存在多套核算系统且板块交叉性业务较多时，建议由主数据系统统一管理财务类人员和组织机构。企业的人员和组织机构发生变更时，主数据系统结合下游系统调整规范与调整说明书做出相应调整，该工作需要安排专人负责，会增加一定的企业资源成本。

某些核算系统可能需要履历信息，该类数据变动性大，不属于主数据的管理范畴，建议核算系统以HR系统提供的履历信息作为期初数据，根据业务需求自行管理。面对多核算系统时，此方案基本实现了人事类主数据的正常应用，但为了保证各核算系统的一致性，主数据系统必须作为数据源头，数据调整伴随更多流程，降低了工作效率，专人维护工作也增加了资源成本。

人事类主数据可以由单个系统生成一套视图，也可以由多个系统各自生成业务视图，还可以多个系统共同管理多套视图，三种思路各有取舍。在主数据项目实施过程中，人事类主数据的实施方案需要结合企业现状进行调整，尽量减少对已建成系统的冲击，加强对存量数据的利用。人事类主数据牵扯的系统众多，实施方案存在不确定性，需要实施方多和甲方业务人员沟通交流，共同确认好人事类主数据的实施方案。

总结

本文主要对大型集团企业主数据治理项目实施过程中，关于主数据模型标准的制定、主数据的集成设计时和人事类主数据的应用这三个问题进行难点剖心并给出应对措施。实际操作过程中，应从多个角度分析问题，每个方案都具有优势和劣势，需要结合企业的实际情况选取最优的解决方案，只有按照符合企业实际的实施方案实施数据治理，才能取得事半功倍的效果，助力企业的信息化建设更上一层楼。

作者：贠思奇 来源：数据工匠俱乐部