导语：在上一篇文章中，作者谈到了数据孤岛形成的原因，简单介绍了主数据管理的概念和主数据管理为何能发挥作用。而主数据管理和数据治理一直以来饱受诟病的，便是落地难。选择一个称手的主数据开发平台，也是项目成功的关键。本篇就将结合具体案例，谈谈主数据管理在一个企业中如何落地，并帮助企业更好地把数据当作生产要素来支撑业务发展。
今天想和大家聊聊如何选择主数据管理方案。在上一篇文章里，我们谈到了数据孤岛形成的原因，简单地介绍了主数据管理的概念和主数据管理为何能发挥作用。 当然，理念的东西毕竟是抽象的，从实用角度而言可能是无用的。这一篇文章将会从一个具体案例出发，来谈一谈主数据管理在一个企业中如何落地，并帮助企业更好地把数据当作生产要素来支撑业务发展。
数据孤岛的形成是有其必然性的。企业的历史也是业务系统信息化/数字化的历史。当年任正非力排众议，邀请 IBM 为华为内部做流程化改造。一举奠定了现在仍在发挥重要作用的 IPD 流程，这也是华为引以为傲的竞争力。企业的成长，和孩子的成长是一样的。原本合身的上衣和裤子，也会发展过程中，慢慢变得不合适，不再适用当前的发展状态。
但也有不太一样的地方，业务系统跟衣服不一样，它们无法丢弃。
这些业务系统或者 IT 系统，可能还在企业的关键业务系统中，扮演或关键或重要的角色。需要在飞驰的过程中，将这些历史系统逐步现代化，甚至有一些系统还不得不持续维护。
我们今天介绍的这家，在大陆以及港澳台皆有珠宝零售业务的头部企业，也是沿着这个发展模式和脉络，逐渐在自己企业内部形成了数据孤岛，从而导致了在应对移动互联网上的吃力，还持续性地对业务造成了伤害。
作为国内珠宝零售行业的领头羊，其在大陆以及港澳台累计门店数接近 1000 家，其中大陆门店数占 70% 左右，8 个旗舰系列、7 个国际品牌，累积系列品牌总数为 27 个。
提起珠宝，大家可能脑子里浮现的第一个词是“贵”。这一特点，也将珠宝零售行业区别于其他以快销为特点的日用品零售行业。珠宝零售行业从生产制造到最终的交易发生，大致可以分为：
- 研发设计
- 生产制造
- 供应链/库存管理
- 销售管理
- 售后管理
相较于快消品而言，珠宝零售行业的库存周转相对较慢，所以每一次销售机会都显得格外珍贵。用户在门店开始选购珠宝时，考虑主要是三个方面，分别是价格、款式、尺寸，这些主要跟库存管理有关系。
这就要求门店的营业员能够直接查看本区域、跨区域的珠宝库存情况，在顾客已经选择某个特定的款式，预算充分的情况下，通过“调货”的方式，来完成本门店没有库存情况下的销售过程。
今天我们探讨的珠宝零售公司，在它的发展历史过程中分别在中国大陆、中国台湾、中国香港、中国澳门等地，建设了多套不同的供应链管理、库存管理和销售管理的系统。
多套不同的系统，听起来是不是有点多，且不必要？但在这家公司漫长的信息化和数字化旅程中，这些系统都是为了回应在不同区域更快速地开展业务的需求而建设完成的。或许一个事物的发展多半总是在荆棘中前进的，很少一帆风顺，更不会按照脑海中所预想的完美路线图推进，一切都是权衡的结果。
一、烟囱式开发，数据分散，取数难
由于企业 IT 发展了几十年，陆陆续续采购了不少的独立 IT 系统，例如：ERP、CRM、SCM 等，往往一件货品信息散落在不同的数据库中，想要一份完整的数据，对研发团队来说可能需要花大量时间去了解、沟通数据结构，再做数据清洗、加工。整个研发周期就会被拉得很长，想要快速获取一些数据，就会显得非常困难。
同时，多套异构数据库对运维团队的技术能力，也是一个不小的考验。
- 二次开发难
有那么多套不同厂商的业务系统，能够弄明白系统之间关系的人越来越少了，更别说在已有系统上做一些二次开发，这对技术人员的业务要求相当高。
- 跨部门协作，组织协调难
业务越来越多，自然就会成立不同的部门去维护，而一旦需要跨部门协作开发时，组织架构的复杂性，直接延长了开发周期和项目上线时间。
二、割裂的商品中心，难以形成合力
不同的地域都部署了相同的“服务和数据库”的组合模式，这也为后续的数据孤岛埋下伏笔。随着数字化进程的深入，这些割裂的系统让不同区域的商品数据无法流转和查询，同时还会造成冗余的库存信息，最大的问题实际上是在业务侧：不同的业务条线有不同的业务人员，他们作为数据消费者，在现有的架构下是无法及时消费到数据的，换句话说，订单的状态抵达相关业务人员的时间，会被大幅度延长。
这种难以消费数据的原因是，数据割裂。数据割裂这一概念本身可能过于抽象。
我们从数据割裂造成的实际问题来谈一谈。
作为一家头部的珠宝零售公司，它的商品 SKU 大概有 100 多万，分别散落在不同的数据库表和数据库中，且字典表难以理解，业务映射表关系复杂，业务研发不得不花费大量时间在内部的沟通上。
即使沟通也不一定能解决全部问题，还需要通过数据库的跨实例查询（dblink）解决数据割裂的问题。因为超过 1.5 亿库存订单存放在多个 Oracle 和分布在 20 张表中的 10 万商品信息，整个运维团队和业务团队，需要花费很多的精力解决：
- 订单状态跨地域维护。
- 数据在多个数据库之间的同步导致的延时。
- 订单逻辑复杂，不易扩展。
当一位中国香港门店店员想要在香港查一件货，通过系统查询得知这件货不在香港，在澳门。一般而言，店员可以通过系统去做“调货”动作，最后完成交易。
但因为一些 IT 历史原因，这家珠宝零售公司的门店店员，必须通过系统将澳门的货转到香港后，才可以查询该货明细，而这个转货的过程需要花费数小时来等待。客户的购买时间，往往也就在关键的几个小时以内。如果这样的等待经常发生，这对营业额会产生较大的冲击。
三、活动难以按时按需开展
移动互联网对于零售业改造是全方位的，珠宝行业也不例外。
传统的“人货场”概念被拓宽到了线上，一些交易活动也不再局限在线下零售店内。为了适应消费者购买习惯发生的变化，珠宝零售行业一方面需要融入到淘宝、京东等这些线上零售平台已有的活动中，同时也需要根据节假日及时开展适当的营销活动，增加销售收入。
这里就出现了供给侧和需求侧的矛盾：“业务以为的研发周期” 和 “工程师能提供的研发周期”，可能是存在不匹配情况的。
在双十一来临之际，业务团队根据当前市场情况及政策规定，提出了一系列促销活动方案，工程师团队在收到十几个需求时，开始拒绝，因为不可能在短时间内全都满足。
当然现实情况会更加复杂，工程师团队通过加班加点的工作满足了业务的需求，但这种冲刺式的努力不可持续，需要组织中的关键角色，对现有的 IT 蓝图进行复盘和盘点，制定出合适的升级路线。
四、互联网+，重造数字化中的自己
虽然是一家传统的零售企业，但企业文化使得他们不断精益求精，希望通过结合互联网电商、社交、媒体等线上平台，为企业带来新一轮的增长。
在过去的 3 年中，全国数百家门店，年均举办了超过上万场线上线下活动，更是在某年双十一珠宝销售榜中取得了位居第二的好成绩。
但问题也越来越明显，落后的历史系统已经严重地掣肘了业务的发展。此时对于这家传统企业来说，已经无法通过“头痛医头，脚痛医脚”的方式来打补丁进行局部的调整。
“新一代数据架构”的诉求应运而生，企业需要通过这样的数据平台，来帮助他们解决由来已久的问题，从根本上解决因“数据孤岛”问题引发的一系列技术和业务问题：
- 数据模型线性增长，关系型数据结构越来越复杂，修改字段时，就像在电源插座上找唯一能用的插位。
- 20年前的 IT 架构结构复杂，大量存储过程，学习周期慢，改动困难。
- 研发速度跟不上需求变化 。
- 需要一个高效的数据开发服务平台，支撑企业内部敏捷开发和 DevOps。
- 重复建设用户数据、订单数据，统一数据困难。
经过层层筛选，公司决策，最终形成：“连接数据孤岛，融合数据，形成主数据” 的决策，用主数据管理和数据治理，来解决数据孤岛的问题，更好地支撑业务，提升业务执行效率。
五、工欲善其事，必先利其器
Gartnter 在《成功实施主数据管理的 7 个步骤》[1]中指出，在企业中实现一个主数据管理（MDM）策略大致需要 7 步：
- 确定愿景、战略和利益相关者
- 发展过程
- 选择衡量标准
- 建立一个绩效基线
- 商讨目标改进
- 将目标改进转化为财务结果
- 建立所有权总成本模型
- 计算投资回报率
这 7 步背后的本质逻辑是什么呢？较大的组织会选出一组人（当然这些人是组织里有深厚影响力的），建立和执行数据质量标准，并以此为基础建立持续迭代并形成最佳实践。数据孤岛的打通和数据治理的实施，贯穿整个组织，伴随组织权力的调整，或者是根据已有的权力结构进行本地化的改造。
换句话说，通过务虚会、头脑风暴会、问题分析会，在利益相关者中形成对于数据治理的共识，确定里程碑和衡量成功的标准，最后通过财务数字证明“数据治理”这项行动是有效的，切实地提升了公司运营效率。
为了使主数据管理发挥作用，它必须是一个团体的努力且是一个持续的努力。
一般对于数据治理项目的理解都是一种变革管理，需要引导组织通过调研、整理、归纳等工作，对现有流程进行梳理和分析。当然还会有创造性的活动，制定新的流程。
主数据管理和数据治理一直以来饱受诟病的，便是落地难。选择一个称手的主数据开发平台，也是项目成功的关键。
把数据治理或主数据管理等围绕数据的方法论，落实到企业的生产、运行和支撑的全过程中。对于这样的一把兵器，它是有一些画像的：
数据发现和连接。发现和连接功能利用算法，即时识别数据的重复，并帮助解决多个条目成为一个单一和准确的记录。主数据管理软件有助于消除数据重复，将正确的信息输入所有的系统，监测数据来源的完整性，并将一些本来被认为是额外需要资源的任务自动化。
这是保障来自于孤岛的数据和主数据完整性的重要能力。缺少了该项能力，其本身的意义就失去了对于主数据来说，不能够再成为企业的共享数据，更关键的是不再能支持一个关键、完整的业务流程。
数据整合能力。在一个集中的数据源中创建、维护和分发主数据，并在企业的各种不同业务中延伸。它确保数据的一致性，随时随地，标准化的定义和业务规则，强制执行验证值，并监测完整的审计跟踪的变化。这是对数据按需进行修改的关键能力，能对数据进行合理变形，达成业务部门所需要的数据样式。
这一能力从最终使用者的角度而言，还意味着极致易用性。通过前端页面和拖拉拽操作掩盖掉数据整合操作的复杂度，将操作面和管控面进行分离，使得企业内部用户在数据整合过程可视化，如拖放、显示变化、最佳记录审查和匹配审查。
大批量数据处理能力。主数据管理软件的大规模处理功能，可执行有益的大规模更改过程，使主数据用户能够对业务伙伴、客户、供应商和产品数据范围，进行批量更改和修改。它使一个有效的过程来执行属性的大规模变化。
流式数据处理能力。和数据整合能力一道，帮助企业实时地获取、过滤、加工数据，尽可能地保障主数据的完整和一致。
数据共享能力。主数据管理软件使业务规则，可以在不同的使用情况下共享。一些从业者会将数据共享性称为数据虚拟化或者数据及服务，这并不冲突。
例如，在进行数据导入或审批过程中，业务规则可以在不同的使用案例中共享。这些控制必须是集中式的，只需改变一次就能在所有地方生效。业务规则必须在用户界面上实现，而不需要等待后台开发。
这五个基本关键能力是评分表中的五个象限，可依据评分的大小绘制雷达图，在选择兵器时需要重点考察，根据企业当前的现状，合理选择主数据管理的软件产品。如果进一步提炼，主数据管理的过程可以抽象为：连接、融合、发布这3 个阶段，通过广泛的连接性，将业务数据库数据以低代码拖拉拽的方式构建数据链路，形成数据镜像层。
接着，在平台中完成建模开发形成主数据模型层（MDM），主数据模型层（MDM）将会成为之后各业务系统所需数据的核心数据层。
为此我们和客户一道，结合珠宝零售行业的实际情况，打造了“商品模型主数据”“库存模型主数据”“组织架构主数据”，构建了能够支撑珠宝零售业销售这一关键业务流程的主数据模型。
最后，在主数据模型层之上，可以快速拓展出满足各业务需求的应用数据模型层（ADM）。
最终将应用数据模型层（ADM）中的数据，以 API 的方式对外提供统一的数据服务，业务作为数据消费者可直接实时读取数据，这种能力是数据发布能力，同时也需要整个主数据平台，能提供数据虚拟化或者说数据中央化存储的能力。
六、珠宝零售行业，如何实现主数据管理完成敏捷化转型
集团战略规划
和集团利益相关者一起合作，结合实际业务发展情况和 IT 基础设施情况，制定了 3 年 IT 规划。
通过调研和访谈的形式，摸清数据孤岛的情况，为顶层战略规划做好奠基性工作。与此同时，和客户业务部门一道为后续的应用场景规划进行需求调研，同时形成数据质量规范和数据流程规范。在明确组织架构和数据治理原则的前提下，协助客户开始技术平台的搭建，最后一步就是在完成了主数据治理之后，实现业务价值。
数据资产盘点，形成统一商品中心
前面提到，这家珠宝零售公司有多个 ERP 系统，围绕珠宝的生产制造、物流供应链和最终的销售都散落在不同的地方。
这里我们和公司的业务方一起，以拥有主数据较多的部分为核心，将历史和实时库存数据、商品信息和钻石、黄金和玉器等各类证书都进行打通、合并。并在此基础上，按照组织架构进行合理的数据发布和数据授权，让门店店员和中高层，都具备了在需要时消费适当数据的能力。
最重要的是，在统一库存模型、统一商品模型和统一数据访问服务的前提下，开发能够跟得上市场变化，数据模型复杂但易用，可快速开发新应用。
七、实施主数据管理之后的效果
在连通数据孤岛之后，融合数据，生成主数据，在这样的数据治理的基础上，集团很快就上线了基于主数据的“全渠道商品中心”，大陆以及港澳台门店店员使用同一套后台，即可查询全国商品。
相较于之前的多次查询 API 方式，现在前端只需查询一次，即可获取商品所有信息。查询次数从 5 次缩减为 1 次，查询响应时间从累计 10 秒缩减到 3 秒内。
技术研发可通过平台快速查到想要的数据，无需追问相关同事，减少 DBA 日常 70% 查询工作，有效提升研发 90% 开发效率，这极大地降低了跨部门带来的沟通效率问题。
研发周期从 2~3 个月缩减为 1 周。通过『数据即服务』的新架构将数据变成了真正的生产要素，为集团真正实现了“增效降本”的务实的业务价值。
支撑业务流程的主数据得到沉淀与复用，能在组织间高效共享有价值的信息，让不同业务部门都可轻松复用历史数据，快速发现数据价值。
采用的主数据平台 Tapdata 是一体化平台，服务化程度提高，通过灵活的交互式服务，显著缩短了开发周期，提升集团市场竞争力。此外，较其他主数据治理平台，集团选择的 Tapdata 能持续根据业务发展迭代主数据模型，适应企业的动态发展。
八、写在最后的话
按照 Gartner 对于主数据管理（MDM）的定义，它不仅是一门技术驱动的学科，更是一门管理的学科，需要 IT 部门和业务部门共同合作，确保企业正式共享的主数据资产的统一性、准确性、管理性、语义一致性和责任性。
主数据，是描述企业核心实体的一致和统一的标识符和扩展属性集的，包括客户、潜在客户、公民、供应商、网站、层次结构和账户图表。从这个定义出发，主数据管理就注定不完全是一个技术问题，更多的是一个对于公司所处环境（行业属性、技术储备、人才画像）的理解后，特殊化出来的一套变革管理的咨询方案。
随着数字化在各行各业的乘风破浪，主数据管理作为一种数据治理的方法论，一定能帮助这些企业提升对于数据这一新的生产要素的使用度，释放更多价值。
虽然再怎么强调主数据管理咨询的属性也不为过，但是平台本身的能力也不能忽视。基于我们在技术人才储备较为薄弱行业实践的经验而言，一个好用的主数据管理平台，也是至关重要的。关于如何选好一个主数据管理平台，前文已颇用了些笔墨，此处不再赘述，感兴趣的朋友可以往前查看。
最后，祝福各位在数字化/数智化的进程中，破局数据孤岛，扫除拦路虎，助主数据管理药到病除。
参考资料：
[1] 7 Steps to Build a Successful Business Case for MDM Programs《成功实施主数据管理的 7 个步骤》
Tapdata 实时主数据服务平台 Active Master Data Platform
传统的主数据管理采用 T+1 的方式从业务系统获取源数据，加工处理后形成企业的标准数据， 并通过导出方式输送到业务系统使用。这种方案的局限性在于数据更新较为滞后。Tapdata 的实时主数据方案允许用户用实时数据管道及强大的 UDF 功能让用户可以简单的实现去重、规则判断等主数据治理功能。端到端的秒级延迟 + 自动API 服务意味着客户直接从Tapdata 获取需要的主数据。
本文作者：杨哲轩，Tapdata 运营合伙人&客户工程团队负责人。毕业于明尼苏达大学-双城分校，后加入 PingCAP 担任基础架构研发工程师，深度参与TiDB、TiSpark 等项目，曾任 PingCAP 咨询&解决方案总监。为多家知名金融、互联网和制造业等行业企业，提供咨询和解决方案服务。对数据库、分布式原理、HTAP、DaaS、数据架构和数据治理等架构和管理领域，有独到的见解和丰富的实践经验。
