前言：笔者按；近年来，主数据管理（MDM）成为企业数字化转型的关键设施。针对用户普遍关心的问题，我们专访了李晋先生，并整理出21个关键问题的干货内容，希望能让甲方的管理高层、CIO、架构师和数据分析师等关键用户快速了解MDM并构建自己的MDM战略。
严格来讲，MDM时候数据治理的一部分，但是从实践来看，MDM基本上从数据治理中独立出来自成一体了。为什么会这样呢？因为从实践上来看，数据治理厂商特别强调元数据标准化、数据资产管理和数据质量管理，这些实践我们都称之为“数据入湖后的治理”，这种治理难度很大，你可以理解为是传统数仓实践中的数据结构设计和复杂ETL工程，也就是说入湖后的治理其实依然还是一种后治理方案。
人们发现后治理方案都有严重的问题，数据治理必须贴源治理，就比如你要治理一条河流的水质，你是应该在下游治理，还是中游，还是上游呢？答案很简单，是去上游治理。那么数据仓库、数据湖的上游在哪里呢？就是应用系统嘛。MDM是入湖前的治理，是真正的贴源治理，比如供应商管理，MDM是从供应商的名称、编号建立开始就执行管理措施，它能在源头解决问题。能在源头解决的问题，谁还希望等到入湖后去治理呢？
所以，我们看到近年来数据中台客户纷纷开始关注数据治理，但是最终都会将MDM作为数据治理的落脚点，而不是技术晦涩的以元数据治理为核心的后治理方案。
从理论上来说，这种判断肯定有问题。但是从现实和实践来看，你说的这种判断是可行的，简单、快速，而且基本够用了。
另外值得注意的是，数据中台都具备元数据管理、数据质量管理的能力，在大部分场景下就够用了，不需要单独购买或上线专门的数据治理平台。直到需求发展到一定程度后，高阶用户可以再购买专用的数据治理工具。
很多人认为数据标准对齐是最难的，其实这是不对的。在国内，只有那种超级体量的央国企、世界500强才会很难，一般企业数据标准对齐是很容易的。你把所有系统的数据字典拿来一对，数据标准的基本框架就有了，不复杂。管理流程相对更复杂，因为主数据的创建者是某个应用系统，它本身是为自己的应用服务的，不是为下游消费者而生的，所以往往无法录入全部的数据属性/字段，所以就会涉及到跨部门的数据维护，包括修改、丰富等动作，这个流程往往需要跨系统的应用调整、工作流程和岗位梳理和系统集成，所以比较复杂。这往往是中国集团化企业在方案阶段最难搞定的事情。接口集成对齐是几乎所有项目中都让人讨厌的存在，如我们所知集成需要所有的系统一起配合、联合调试。所以，一般难点都在后面两个对齐。
这是一个很好的技术问题，其实困扰了很多擅长应用而不太关注底层技术的小伙伴。大概在10年前，MDM主要都是用ETL做数据集成，因为当时缺乏好的集成工具。但是近些年都是标配ESB。原因很简单，ETL严格来讲不是集成工具，是数据清洗加工工具，ETL做数据采集擅长做批处理，实时数据处理能力不足。虽然近些年来RETL工具发展很快，比如Data Pipe Line这样的工具，但是我们依旧不建议使用。因为ETL往往对数据库直接操作，这也是不对的，因为主数据是用经过应用系统的应用层，比如java来做控制的，不能直接入库或出库。所以选ESB是正确的选择。
其实，主数据集成看起来是数据集成，其本质是业务集成，走的是API集成路线。另外，API 网关和ESB不矛盾，ESB的核心定位是编排，也就是数据处理、接口处理，负责的是逻辑的编排，而网关是负责网络安全的。在互联网环境下，用户应该增加一个API网关，ESB和API 网关联合起来使用是一个常见搭配。
对的，前几年阿里就老师说ESB已死，这纯属误导。你看，后来阿里不仅不提这个说法了，他自己还搞了一个CSB，中文名叫云服务总线，其实就是一个简版的ESB，能力还不够用。比较遗憾的是，阿里没有出来对这个观点做必要的澄清，所以很多用户脑袋里还有这个观点。
事实上，在很长时间内，人们普遍不敢质疑阿里的，算是对权威的胆怯吧，其实这个观点不对的。
另外一点要注意，ESB是分代级的，严格来讲有三个代级，最新代级的产品已经十分轻量化，而且非常好用。用户要擦亮眼睛选择。
另外有一事情要注意：近年来国内外出现了很多的iPaaS平台，其本质基本都是一个简版的ESB+一个简版的API网关，对于基础需求用户来说是不错的，但是却不满足企业级用户的需求，用户应该选择HIP综合集成平台路线，HIP平台里面一般都有一个单列的新一代ESB平台。
从理论来讲，主数据管理或治理最终都要落实到组织和人身上，这个东西在数据治理里面叫OWNER，就是所有者的意思。
主数据常规咨询建议都是希望客户建立一个专门的主数据管理组织来承接这个事情。但是，中国企业基本都不具备建立一个专门的主数据管理组织的条件。所以，我们应该强调OWNER机制，也就是谁对某个主数据的主数据负责的问题，这样可以利用最简单的机制和方法来解决MDM持续发展的问题。也就是说我们更应该建立权责机制，而不是盲目追求一个什么专门组织或者委员会。
显然，这个问题也把我难住了。MDM项目有一个天生的悖论：地位重要但是价值不显。你会发现很多业务协作和数据分析问题都是因主数据管理而起，但是解决了主数据管理质量问题后，人们却体会不到其价值。特别有意思的是：MDM运行正常的时候，人们意识不到价值，但是MDM坏了之后才会知道其重要性。这种感觉就好像是某种人性——只有失去了才知道重要，而平常却不会珍惜。MDM呈现价值不是没有办法，但是我首先却不想讲办法，为什么呢？有一些东西是讲投资回报率的，有一些东西应该纯粹一点，上MDM项目应该纯粹一点。我们现在在大力发展MNC外企客户，我们发现欧美企业对这个事情就不讲ROI，因为这是一个常识问题，跟价值无关，就要像没人再去问为什么要为公司人员配一台电脑一样。很多中国企业还在讲ROI，那是因为企业数字化的成熟度有待加强和发展。
给大家汇报一个有意思的情况，去年一年我遇到好几个大型集团的客户给我反馈：MDM项目是总裁要求建设的，而不是业务部门或IT部门驱动的。某大型地方国企的总裁认为：任何一个体系的持续建设都应该抓标准，那么数字化的就应该从数据标准抓起，数据标准就应该从主数据标准抓起。这个领导不是干IT出身的，但是他是一个有哲学的人，他懂得标准的价值。
我认为这位领导的应该成为企业数字化的榜样，对于建立标准这样的事情是不应该讨价还价的，应该讨论的是如何早上线早受益，应该讨论的是如何确保项目做到–快、省、好、久。只有越过了基本的价值认知观，我觉得再来谈价值体现会更有意义。
几年前，我和肖忠先生（奥康CIO）一起实施了奥康MDM项目，我们提出了一个重要的价值观和方法——“价值优先，数业双轴”，意思就是实施一个主数据管理主题，就做一个数字化的应用创新项目。我们实施了人员主题，就将HR系统用低廉的价格改造为EHR；我们实施了产品主题，就帮助设计副总裁进行产品生命周期管理，大量砍掉无效的SKU；我们实施了会员主题，就推动力多品牌、多机构、多渠道的集团会员统一管理……这种状态我们持续了2年多，帮助奥康用少量的资金实现了显著的数字化升级。我们看到，欧美企业喜欢脚踏实地，一个主题一个主题实施，这样能够更好地帮助业务变革和升级。但是，国内企业喜欢一次性把所有主题都上完，成绩单看起来不错，但是错过了业务升级的机会。我觉得这是MDM价值显性化的最佳方案。当然，还有一个最最直观的方案——那就是实施完万路MDM，立即实施数澜中台，让所有的用户立即看到数据报告的价值，这是一种最直观的快捷方法。