揭开主数据管理的陷阱

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

但是，随着主数据管理平台的逐渐被推广使用，一连串的问题就来了，这也导致了目前很多企业实施主数据管理项目后，数据质量重蹈覆辙的悲剧。

1．主数据的动态性问题凸显

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

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

其实，为什么我们老是想尽一切办法去识别主数据呢？难道就是为了让我们的主数据管理员未来别闲呆着？难道就是因为老外提出了这个理念就无法动摇？数据治理核心要解决的是数据质量、安全、服务以及相关的环境等，费了九牛+二虎之力识别出了所谓的主数据，没多久因为业务系统的变化出现了倒逼主数据必须变化的情况，何苦呢！干吗要自己给自己设置障碍？干吗非要先去贴标签再去解决数据质量、数据安全等问题？

负责任地讲，在数据治理行业，外企不值得我们去迷信。

某核电集团，2013年实施了某国外MDM（Master Data Management）平台，2014年中期，该企业领导发现主数据管理员在不断地调整花了几百万费用制定的主数据模型标准，一怒之下彻查原因，最终发现是由于业务系统的扩充、变更造成的。其实主数据管理员也很委屈，不改变主数据模型标准，数据就无法顺利分发出去，改变模型还要自己去琢磨如何识别主数据字段，识别出来后还要确认元数据标准等，一连串的问题忙得不可开交，最后还被领导痛骂，想想就挺可怜的。

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

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

主数据的核心管理理念就是实现数据的“单一视图”，是共享性数据的统称。但是，要管理业务场景的数据（业务场景数据：指针对某一业务实体对象在特定业务场景下的描述信息，不包含主数据部分，如某产品在不同生产线的描述，以及针对不同区域的价格描述等），就是增加了业务场景视角的数据管理。因此业务场景数据管理和主数据管理有是两个层面的问题，但是从数据治理的角度出发，如果我们无法涉及业务场景数据，可能就无法很好的保证业务场景的数据对现有业务以及未来数据中心的有效支撑。目前很多实施了传统主数据管理平台的企业只是在顶层管理解决了部分数据问题，开始数据中心等的建设时又被迫重新开始数据的全面治理工作。

某电工集团，2016年开启了主数据管理项目的一期工作（顶层管理型主数据的治理），选型了国内某主数据管理平台，2017年开启二期实施后突然发现此平台架构根本无法满足业务部门的业务场景数据的管理要求，甲乙双方还因此拍了桌子，差点对簿公堂，无奈项目二期暂停。2018年中甲方领导特意来乙方公司探讨此问题的解决方案，2018年底我们也特意去了一趟甲方现场再次沟通，无奈平台无法替换，最终只能不了了之。

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

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

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

3．主数据管理项目实施后体系运维难以保障

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

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

举个例子，企业实施主数据管理项目后进入运维阶段，当需要增加某一新类型的数据时，传统的方式的是让大家（数据管理组织成员）坐下来直接讨论该数据应该如何分类，模型如何制定等，，或者是主数据管理员提出具体建议提交会议后再讨论，或者说通过相关系统线上提交领导审核然后定稿，以上所有过程都似乎是非常严谨、合理，但是我们有没有想过这里讨论的合理性，因为领导根本不了解同类相关数据的分类、建模思路，领导依据什么来和咱们讨论，依据什么线下或线上给我们审核定稿？为了慎重起见领导一定会搁置等待，直到主数据管理员参考业务人员建议提出更加合理的解释。当然也会出现领导被主数据管理员以阻碍业务进度为“要挟”草草审核定稿。

有人会说，领导不知道没关系，主数据管理员是从项目实施跟过来的，肯定了解当时的思路，肯定能直接说服领导，如果主数据管理员如果是新来的怎么办？如果主数据管理员把思路忘了怎么办？主数据管理员又能依据什么来制定出合理的模型呢？答案只能是“拍脑袋”，如果这样我们得给咱们的主数据管理员配上头盔才行。

综上所述，这样就出现了项目后的数据运维管理和项目中主数据管理体系咨询的思路是脱节的状态，导致数据运维管理阶段根本无法延续当时的思路。

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

这样的情况不是个例，应该在每家企业中都有存在，其实这不是企业领导的不作为，是我们太理想化，设置的模式太不切合实际。

4．主数据管理项目实施后数据质量重蹈覆辙

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

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

某能源集团，2012年实施某国内MDM平台，项目顺利验收，甲方也花了近半年的时间进行了历史数据质量的全面清洗，且分子公司及集团两级审核机制，集团有6个人分别对不同大类的物资数据进行审核，但是2015年初突然发现60多万条的物料数据有20多万条出现了不同形式的数据质量问题（包括名称叫法的不一致、各种错别字、数据描述的不完整等），导致目前主数据管理平台沦为了只是为ERP等业务系统的赋码功能（生成编码并传给业务系统），SAP ERP等业务系统中一物多码、一码多物问题大量重现，让整个集团上上下下真正体验到了“回到解放前”（回到主数据管理项目前）的感觉。

这样的情况当然也不是个例，曾经听到有甲方说“问题在于我们自己没有管理好，是我们的人不行，不能怪主数据管理平台”，不知这是甲方的无奈还是乙方的无能！（山东中翰软件有限公司）