编辑导语：主数据（MD Master Data）指系统间共享数据（例如，客户、供应商、账户和组织部门相关数据）。与记录业务活动、波动较大的交易数据相比，主数据（也称基准数据）变化缓慢。主数据必须存在并加以正确维护，才能保证交易系统的参照完整性。本文作者就从主数据管理出发，剖析了主数据管理的局限性。
从主数据的概念定义上理解，主数据表示业务实体对象的基准数据以及其被引用的关联属性信息。例如每个人的身份证号码就是主数据编码，而对应的性别、年龄等就是属于被引用的关联属性信息。
我们再进一步理解，在信息化领域对于主数据定义：
主数据：对于某一个业务实体对象中，包含基础数据（静态或相对静态的数据）中被两个及两个以上业务系统共同使用的属性字段。
这个定义是相对合理的，短期内也被各厂家推广使用，这也是目前国内主数据厂商对主数据的统一标准定义。
但是我们会发现，不少企业将主数据管理平台进行了推广和使用，还是没有从根本上解决数据质量的问题。反而投入的人力物力越来越多，收效甚微。
一、主数据静态性与动态性的悖论
前面讲到主数据的一个特征便是业务实体对象的属性字段是需要静态或者相对静态的，这实际上也是主数据的核心特征之一。
如果要确保各个业务系统能够进行匹配拉通，那么对于业务实体对象的主数据定义必须是要静态的。例如：我们每个人的身份证号码，它一定是不能随意更改，确保唯一性的。
但是在企业实际的发展过程中——特别是目前企业的转型的过程中，企业业务系统的新增和更换，原来被主数据厂商识别出来的主数据已经无法满足新的业务系统的上线需求，需要重新进行主数据的扩充识别和相关模型、流程等的变更操作。
从而造成了主数据管理平台后期运维成本的居高不下，严重违背了实施主数据管理平台的初衷。
例如：房地产行业从粗放型转为精细型管理的过程中，需要扩充主数据项。原本管理的维度可能是项目、分期、楼栋的维度，接下来需要对于每一户进行管理。
那么实际上原本固定静态的主数据层级架构就会发生调整，在调整的过程中，我们可能会想当然的认为其实只是加一个”户”的主数据项。
但是问题来了，增加一个主数据维度真的那么容易么？对于户的主数据属性字段、元数据管理的范围定了吗？不需要补充它的历史取值？不需要找业务部门的主管们讨论、协商？数据OWNER是谁？
我们会发现花了九牛二虎之力识别的主数据管理范围和主数据字段，没过多久就因为业务需求，场景变更进行了调整。
我们所谓的主数据静态性并不是那么静态，甚至还具备动态性的特征；而主数据项的增减，以及对于主数据项的属性字段的扩充都无疑增加了额外的工作量。
我们了解到主数据的这个特征后会发现，随着企业的发展，业务场景越来越多样化，动态性的影响也会让我们对于主数据管理工作更加头疼。
二、主数据无法满足所有的业务场景
我们在做数据治理的时候往往会和主数据治理混为一谈，但是实际上这两者只是包含的关系。
数据治理的范围应该是更为宽泛的范围，如果我们理解完成主数据平台搭建后，就能实现各个系统各个场景的数据拉通，实际上是有失偏颇的。
所以我们说业务场景数据管理和主数据管理是两个层面的问题，这两者的重要性没有高低之分。
从数据治理的角度出发，如果我们无法管控业务场景数据，首先主数据管理将变成一件没有意义的事情，第二个问题就是业务场景的数据对现有业务以及未来数据中心的不会起到有效支撑。
例如：在做房地产主数据管理的过程中，楼栋以及面积需要解决的问题其实无非就是：数据OWNER、录入时点、数据标准等问题。
但是实际上管理了楼栋和面积也并不能解决货值管理的业务场景，对于业务数据和指标体系而言，主数据只是迈出了第一步，接下来业务场景数据管理才是最为关键的一步。
总之，主数据管理并不能辐射到系统所有的业务数据质量，同样主数据管理无法满足业务场景导致的数据治理障碍也越来越明显。所以可以判断的是，亡羊补牢甚至推倒重来会成为主数据管理的一种常态。
三、主数据逐渐沦为赋码平台
企业在上主数据平台进行管理的初衷之一，就是寄希望于通过主数据拉通改善数据质量。
但是目前绝大部分企业反馈的都是收效甚微，原因就是主数据管理作为多条线多部门协作的事情，从数据验证机制、巡检机制、管理规范、主责部门、录入依据等等环节上都体现了管理的难度。
主数据项的属性字段有没有维护？维护的质量怎么样？
——这是主数据运维的核心。
但是受限于上游系统，主数据真的能管理好么？还是逐渐沦为了各个业务系统赋码的一个平台。
以上就是我对于主数据管理的一些局限性思考，任何产品平台我相信都会存在一些局限性。没有一味药可以治百病，核心还是要对症下药，搭配其他的管控机制以及治理方式，才能最终实现数据价值。
作者：成于念，微信号：415864696，感兴趣的事情很多，欢迎一起沟通交流。
本文由@成于念 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Pexels，基于CC0协议
