揭开主数据管理的陷阱( 二 ) 对于主数据

某电工集团， 2016年开启了主数据管理项目的一期工作（顶层管理型主数据的治理），选型了国内某主数据管理平台， 2017年开启二期实施后突然发现此平台架构根本无法满足业务部门的业务场景数据的管理要求，甲乙双方还因此拍了桌子，差点对簿公堂，无奈项目二期暂停。2018年中甲方领导特意来乙方公司探讨此问题的解决方案， 2018年底我们也特意去了一趟甲方现场再次沟通，无奈平台无法替换，最终只能不了了之。
某石化控股集团， 2016实施了国内某主数据管理平台， 2017年该集团的二级公司就提出因业务管理的需要独立进行业务场景的主数据管理。
某煤集团， 2011年实施了国内某主数据管理平台， 2013年开始二级公司陆续因业务场景数据治理的需要独立开展主数据管理项目。
这样的情况不是个例，尤其是随着企业对数据管理的要求越来越高，业务场景越来越多样化，主数据管理无法满足业务场景导致的数据治理障碍会越来越明显，推倒重来或者亡羊补牢会成为一种常态。
3．主数据管理项目实施后体系运维难以保障
数据管理体系的运维（如制度的重修、流程的调整、新的数据类型或类别的模型新增等）是项目后运维管理的两大任务之一（另外一个是数据质量的日常监测）。
企业都很重视数据管理的运维工作，不少企业甚至专门设置了数据管理组织，配备了相关人员等，但是目前实际管理中大部分还是以主数据管理员为数据管理工作的核心，包括平台的维护，工作的协调等，所谓的数据管理组织根本就没有发挥出应有的功效。
举个例子，企业实施主数据管理项目后进入运维阶段，当需要增加某一新类型的数据时，传统的方式的是让大家（数据管理组织成员）坐下来直接讨论该数据应该如何分类，模型如何制定等，，或者是主数据管理员提出具体建议提交会议后再讨论，或者说通过相关系统线上提交领导审核然后定稿，以上所有过程都似乎是非常严谨、合理，但是我们有没有想过这里讨论的合理性，因为领导根本不了解同类相关数据的分类、建模思路，领导依据什么来和咱们讨论，依据什么线下或线上给我们审核定稿？为了慎重起见领导一定会搁置等待，直到主数据管理员参考业务人员建议提出更加合理的解释。当然也会出现领导被主数据管理员以阻碍业务进度为“要挟”草草审核定稿。
有人会说，领导不知道没关系，主数据管理员是从项目实施跟过来的，肯定了解当时的思路，肯定能直接说服领导，如果主数据管理员如果是新来的怎么办？如果主数据管理员把思路忘了怎么办？主数据管理员又能依据什么来制定出合理的模型呢？答案只能是“拍脑袋” ，如果这样我们得给咱们的主数据管理员配上头盔才行。
综上所述，这样就出现了项目后的数据运维管理和项目中主数据管理体系咨询的思路是脱节的状态，导致数据运维管理阶段根本无法延续当时的思路。
某化工集团， 2015年实施某国内MDM平台，项目顺利验收， 2016年底集团扩展业务，主数据管理员面对需要新增的一些数据模型一筹莫展，组织召开数据管理组织会议讨论时各业务领导成员以出差、忙等各种理由拒绝参加。2017年增加了线上标准审核机制，甚至还用上了移动审批，各业务领导迫于考核的压力草草审核定稿，其实最终还是主数据管理员和相关业务人员讨论后的结果，所谓的数据管理组织也就成了一个摆设。导致主数据管理体系逐渐脱离该有的扩展思路， 1-2年后最终成为“体系两层皮”（运维前中运维后）。