主数据管理：模式，方案与管控

1. MDM系统概述

主数据是指人员，产品、客户、供应商、物料，会计科目等被多个业务系统共享使用的静态数据。而主数据管理是描述了一组规程、技术和解决方案来管理主数据的创建，维护和使用流程，并确保主数据的完整性和一致性。

这个定义里面有两个核心。

其一是静态数据。静态数据的意思就是这个数据不经常发生属性或状态的变化。如果经常变化就不能算作主数据。因此很多人会对类似合同，项目这些是否作为主数据发生疑问。

实际上这个问题跟企业本身的业务运作模式关系紧密。有些企业合同仅仅管理一个基本信息，也不经常发生变化，那么当然可以作为主数据。但是大点的企业，合同本身极其复杂，包括了详细的合同基本信息，合同条款，合同状态，合同付款等，那么在这种情况下合同信息一定不能作为主数据进行管理。

其二是跨多个系统使用。这里的跨多个系统，我个人理解至少是要跨3个或3个以上的业务系统使用。如果仅仅是两个系统间基础数据，做个简单接口同步进行管理即可。只有跨多个系统使用，往往才需要统一管控，统一分发，才有形成统一数据视图的需求。

比较典型的类似供应商，你会看到有些采购类属性实际在供应链系统管理，财务类属性又在ERP或财务系统管理，而还有些研发类属性本身又在PLM系统管理。由于跨多个系统使用大家都各管一部分，形成统一数据视图的诉求就越大。

对于主数据管理涉及到业务和技术两个方面的内容，谈MDM方案同样你需要首先讲清楚业务解决方案，其次才是通过MDM系统或平台落地的技术解决方案。
 

不论是业务和IT，主数据管理的范畴包括了底层的数据模型，数据全生命周期流程，组织岗位和角色分配，主数据质量管控多个方面的内容。当前对于大部分MDM项目，实际上很多厂商更多的都是只做IT层面的方案，而忽视了业务方案。

2. 主数据管理的两种模式

主数据管理当前分为集中和共享两种模式。
 

集中模式即主数据本身的从创建开始的所有管理全部在MDM系统里面，而共享模式则是主数据已经在其他业务系统中形成，MDM系统仅仅是将数据采集过来整合清洗，然后在提供API接口开放或进行数据分发。理想目标都是集中化管理模式，也是最彻底的模式。那么什么时候适合采用共享模式进行管理呢？

如果原来主数据的产生源头就只有一个，那么这种时候你可以考虑共享模式。比如会计科目信息本身在财务系统里面管理得很好，也只有这个地方能够生成，但是财务系统不希望去管理数据的分发等操作。那么这个时候适合采用共享模式。

反之，如果数据本身原来就管理混乱，多个源头都在管，而且管理的范围还不一样。那么这个时候就必须去考虑统一，最好就是集中化管理再分发。
 

3. 业务解决方案

先有业务解决方案，再有技术解决和实现方案。在你和业务人员沟通的时候，更多的应该是讨论业务解决方案。
 

举个例子来说供应商主数据的变更申请，你跟业务人员讨论的是变更申请的业务流程，岗位角色，审批规则，但是业务人员并不需要你是否通过流程引擎实现，或者在流程引擎里面如何去配置。你和业务人员讨论主数据的完整性校验规则或其他质量管理要求，但是业务人员不关心你是配置实现，代码实现，还是规则引擎实现。

主数据业务方案核心仍然是组织岗位，流程，数据模型，数据质量四个关键方面。再简单来说就是静态的数据模型和动态的数据流程处理。

数据模型即是最基本的元数据管理。
 

数据模型不是简单地确实这个主数据是单表还是多表，具体每个表有哪些字段和字段类型长度等信息。更加重要的是数据对象之间的关联和依赖，数据项参考完整性和校验，数据采集和来源规则，数据字典和编码约束等。

10多年前，我们做MDM系统，一个物料主数据的编码规范和编码管理，编码的定义规则，生成规则就是一个独立的文件，编码申请也是独立的流程。

现在的数据治理里面经常谈到数据血缘关系分析，那么前期你的数据模型，数据和数据之间的关联依赖关系建立，随着业务流程的流转形成的数据对象间的关系映射是否构建的完善，将直接影响到数据血缘关系的分析和数据的可追溯性。

对于流程管理也是同样的道理。不仅仅是主数据的申请，变更， 废弃等需要有流程支撑。对于主数据的关键字段项的变更，类似编码，状态等的变更往往都可能根据业务需要独立流程支撑。

比如一个供应商信息，如果其状态或类型需要变更，往往会对已经引用了该供应商的合同，订单等都造成影响，这种变更实际需要对历史在途单据做大量的规则校验和切换动作。采用独立流程支撑是完全有必要的。

4. 主数据现状分析和识别

主数据现状分析和调研建议的思路仍然是业务和流程驱动，从端到端流程分析入手，逐步展开到2到3级流程，通过流程分析找到核心的业务对象和数据对象。同时基于流程分解后形成的业务功能和数据对象进程CRUD分析来评估数据的参考引用范围情况。
 

当然流程功能映射到具体的业务系统，很多端到端流程形成了跨系统的业务交互，这些交互点往往会成为后续数据分发和共享的关键接口点。

数据本身是静态的，但是端到端流程的流转本身形成了业务对象和数据对象的流转，产生了数据之间的动态映射，典型的类似从项目到合同，从合同到订单，从订单到物料，从物料到资产等。这些数据映射本身又体现了数据模型中的动态特性。

在传统的主数据规范咨询中，我们往往引入了企业架构规划方法论进行数据架构规划，主数据分析和识别。主数据作为企业的核心基础业务数据，会被多个业务系统使用，通常具有较高的业务价值。从不同层面，准确地识别出企业的主数据，及科学的管理主数据能够为企业在业务运营及IT支撑等方面带来显著的收益。
 

主数据识别思路仍然是从静态数据，跨多个系统使用两个关键要素出发。

如果只有单个系统，则不需要纳入主数据管理。

如果数据变动频繁，不纳入主数据管理。

基于以上主数据识别思路，则主数据识别需要重点关注的点在于上下游业务流程之间的数据交互，要处理的是来自不同系统但代表同一类业务对象的数据流等。

当然，原来偏重的主数据识别方法论已经没有太大的必要。一个很重要的原因就是MDM出来了很多年，大的行业都有比较多的应用，究竟哪些基础数据应该做为主数据管理已经有明确的历史应用和最佳实践，这个本身不会再出现大的变化。也无需你再从0开始去做详细的主数据调用，主数据识别工作。

比如一个MDM项目往往标书中就已经明确规范要求要实施哪些类别的主数据，你需要做的仅仅是对每类主数据展开详细的数据模型调用，流程调用，集成和分发需求调研即可。

5. 产品和技术解决方案

对于主数据平台，我在前面已经谈到。客户往往希望你提供一个灵活的类似快速开发平台一样的产品，所有的数据对象，流程，规则，表单全部都可以灵活配置出来，不需要任何定制化的代码开发。也就是在业务解决方案和业务建模完成后，所有内容都可以配置。

但是实际上类似上图中红色虚线框中的内容很难做到完全可配置，一个简单的单表，多表的数据增删改查或挂接一个流程引擎跑很容易的，但是复杂规则的配置很难。

如果现在我来考虑MDM平台。那么该平台更类似我前面谈到的低代码开发平台，也就是80%左右的内容可以灵活配置实现，而对于复杂规则则仍然定制开发API接口服务，在前端界面中能够动态去调用。这是当前MDM平台最佳的一种处理方式。

6. 主数据项目实施

注意主数据平台建设项目实际是偏重实施的项目，不仅仅是搭建一个MDM平台，更加重要的是前期的数据需求调研，数据现状分析，数据采集和清洗，数据质量管理，数据治理和管控体系建设等。
 

特别是在IT系统建设已经初具规模情况下建设MDM系统，那么一定存在大量的历史数据采集，清洗，去重，合并等工作。

也就是你首先要解决的是期初主数据的标准化，规范化和一致性问题。其次才是对后续主数据的申请，变更进行科学规范管理。而前期这个工作大部分都是实施类工作，ETL工具仅仅是技术支撑，更多的是需要采集数据，系统自动完成部分清理和规则确认，然后大量工作往往都是需要找业务部门沟通确认。

除了这块工作外，剩余三个方面的工作内容。
 

其一就是前面谈的数据模型定义和元数据确认，其中包括了数据对象，字段，依赖关系，参考完整性约束，引用规则，采集规则等诸多定义。

其二就是主数据流程定义，其中包括了主数据的创建者，所有者，使用者，负责人各个岗位角色的定义，详细的申请，创建，变更，废弃流程定义等。

其三就是数据采集，数据分发和共享规则的定义。产生的数据究竟需要开放或分发给哪些业务系统使用，采集和分发的规则是如何的，实时性和一致性如何保证，安全如何保证，数据多点落地后如何进行数据稽核和数据质量管理等。
 

这里面的第3点实际和ESB总线或SOA集成平台关系紧密。期初的数据采集和集成可以通过ETL工具来完成。但是后续MDM平台上线后，数据的采集，分发，数据服务能力的开放更多的都是一种实时方式，因此需要依赖ESB总线来完成。一个方面是类似能力开放平台模式直接提供数据查询服务API接口，一个是借助ESB总线本身的消息中间件能力，实现1对多的主数据分发和订阅。

来源：AIC商业导论

作者：何明璐