1.2 主数据管理的局限

主数据最初的定义为：表示业务实体对象的基准数据以及其被引用的关联属性信息。2010年，主数据的概念被中翰软件率先引入国内并加以调整改善，使之更加通俗易懂。通俗化后的主数据定义为：描述某一业务实体对象时，基础数据（静态或相对静态的数据）中被两个及两个以上业务系统共同使用的属性字段。此定义很快被证明了其合理性，短期内被各厂家推广使用，这也是目前国内主数据厂商对主数据的统一标准定义。

但是，随着主数据管理平台的逐渐推广和使用，一连串的问题就出现了，这也导致了目前很多企业实施主数据管理项目后，数据质量并未显著改善。

1.2.1 主数据的动态性问题

随着企业业务系统的新增和更换，原来被主数据厂商识别出来的主数据已经无法满足新的业务系统的上线需求，需要重新进行主数据的扩充识别和相关模型、流程等的变更操作，从而造成了主数据管理平台后期运维成本的居高不下，严重违背了实施主数据管理平台的初衷。

甚至目前很多主数据项目的招标现场招标方就非常严肃地问投标方：“你们的主数据平台未来调整模型中的某个属性字段需要多长时间？”，仔细想想这个问题还真的很严肃，因为未来这个调整是会频繁发生的，为了应标很多人不负责任地脱口而出“1小时”“2小时”，以应付甲方。难道我们加一个属性字段不需要确定它的元数据标准？不需要补充它的历史取值？不需要找业务部门的主管们讨论、协商？这怎么可能是1、2个小时就能确定实现的呢？

其实，为什么我们老是想尽一切办法去识别主数据呢？难道就是为了让我们的主数据管理员未来别闲待着？数据治理的核心是要解决数据质量、安全、服务以及相关的环境等问题，费了九牛二虎之力识别出了所谓的主数据，没过多久因为业务系统的变化出现了倒逼主数据必须改变的情况，这不是相当于给自己设置障碍？必须要认识到主数据是动态的这一特性。

某核电集团，2013年实施了某国外厂商的MDM（Master Data Management，主数据管理）平台，2014年中期，该企业领导发现主数据管理员在不断地调整花了几百万元费用制定的主数据模型标准，要知道此时平台上线才近1年时间，不该出现这种状况。经调查发现，是由于业务系统的扩充和变更造成的。不改变主数据模型标准，数据就无法顺利分发出去；改变模型就要管理员自己去琢磨如何识别主数据字段，识别出来后还要确认元数据标准等，一连串的问题。

这样的情况不是个例，随着大家对主数据的概念认识得越来越清晰，对主数据管理的理解也会越来越深刻，尤其是当真正走到主数据项目后更应该能体会到主数据动态性造成的“麻烦”会有多大。

1.2.2 主数据管理无法满足业务场景需求

主数据的核心管理理念就是实现数据的“单一视图”，是共享性数据的统称。但是，要管理业务场景的数据（业务场景数据指针对某一业务实体对象在特定业务场景下的描述信息，不包含主数据部分，如某产品在不同生产线的描述，以及针对不同区域的价格描述等）就会增加业务场景视角的数据管理，因此业务场景数据管理和主数据管理是两个层面的问题。但是从数据治理的角度出发，如果我们无法管控业务场景数据，就可能无法很好地保证业务场景的数据对现有业务以及未来数据中心的有效支撑。

某电工集团，2016年开启了主数据管理项目的一期工作（顶层管理型主数据的治理），选型了国内某主数据管理平台，2017年开启项目二期实施后突然发现此平台架构根本无法满足业务部门的业务场景数据的管理需要，二期项目只得暂停。2018年甲乙双方反复沟通寻求解决此问题的方案，无奈平台无法替换，项目最终只能不了了之。

某石化控股集团，2016年实施了国内某主数据管理平台，2017年该集团的二级公司就提出因业务管理的需要独立进行业务场景的主数据管理。

某煤炭集团，2011年实施了国内某主数据管理平台，2013年开始二级公司因该平台无法满足业务场景数据治理的需要而不得不陆续独立开展主数据管理项目。

随着企业对数据管理的要求越来越高，业务场景越来越多样化，主数据管理无法满足业务场景导致的数据治理障碍会越来越明显，推倒重来或者亡羊补牢成为一种常态。

1.2.3 主数据管理项目实施后运维难以保障

数据管理体系的运维（如制度的重修、流程的调整、新的数据类型或类别的模型新增等）是项目后运维管理的两大任务之一（另外一个是数据质量的日常监测）。

各个企业都很重视数据管理的运维工作，不少企业甚至专门设置了数据管理组织，配备了相关人员，但是目前实际管理中大部分还是以主数据管理员进行数据管理工作，工作职责包括平台的维护、工作的协调等，所谓的数据管理组织根本就没有发挥出应有的功效。

举个例子，企业实施主数据管理项目后进入运维阶段，当需要增加某一新的数据的模型时，理想状态是大家（数据管理组织成员）坐下来一起讨论数据应该如何分类，模型如何制定，或者说主数据管理员提出具体建议后提交会议再讨论，至少也是通过相应的办公系统线上提交建议给企业负责人审核然后定稿。所有过程都似乎是非常严谨、合理的，但是大多数企业负责人并不了解数据分类、建模的思路，并无依据进行讨论，而可能直接拍板定稿，这种讨论往往空具形式，没有实际意义。

有人会说，企业负责人只需要审核批准即可，主数据管理员是从项目一路跟下来的，肯定了解当时的设计思路，但如果主数据管理员是新来的怎么办？如果主数据管理员把思路忘了怎么办？主数据管理员又能依据什么来制定出合理的模型呢？答案只能是“拍脑袋”。

综上所述，这样就出现了主数据管理项目实施后的数据运维管理和项目建立的主数据管理体系之间是脱节的状态，数据的运维和管理无法达到数据治理项目的目标。

某化工集团，2015年实施某国内MDM平台，项目顺利验收，2016年底集团扩展业务，主数据管理员面对需要新增的一些数据模型一筹莫展，组织召开数据管理组织会议讨论时各业务部门的有关负责人以出差、忙等各种理由拒绝参加。2017年增加了线上标准审核机制，甚至还用上了移动审批，各相关业务部门的负责人迫于考核的压力草草审核定稿，其实最终还是主数据管理员和相关业务人员讨论后的结果，所谓的数据管理组织也就成了一个摆设。这导致主数据管理体系逐渐脱离该有的思路，最终形成“体系两层皮”的现象。

1.2.4 主数据管理项目实施后数据质量并未改善

自从主数据管理平台面世后，很多人就把解决数据质量的问题寄希望于此了——通过制定标准的主数据模型以及全面的验证机制实现数据采集（如录入等）环节的统一、规范，再加上理想化的多级次的数据质量审核。

貌似合情合理，实则忽略了几个核心的问题，纯技术的验证手段真的可以发现所有的质量问题吗？如果写了错别字怎么办？所谓的同名词库等手段也只能是判断曾经发生过的且预置在平台内的错别字，以往从没有出现过的错别字出现了怎么办？另外，诸如数据放错类别等问题也是主数据管理平台无法避免的问题。有人说，没关系，这样的情况不会很多，并且我们还有严格的审核机制。但审核真的管用吗？负责人（领导）真的有时间审核吗？负责人（领导）真的对所有数据的质量了解吗？多年来多家企业验证和审核只是一种“摆设”，只是一种行政的知会，对数据质量的把关几乎没有太大用处。这些问题似乎我们都可以不在乎，但时间久了就会造成数据质量产生问题。

某能源集团，2012年实施某国内的MDM平台，项目顺利验收，甲方也花了近半年的时间进行了历史数据质量的全面清洗，但是2015年初突然发现60多万条的物料数据有20多万条出现了不同形式的数据质量问题（包括名称叫法的不一致、各种错别字、数据描述的不完整等），且分公司及集团两级审核机制形同虚设。目前该主数据管理平台沦为了只是为ERP等业务系统提供赋码功能（生成编码并传给业务系统），整个数据治理项目很不成功。