陶玉印的博客

企业数据治理、数据仓库、数据质量、AI应用实践与研究

0%

发表于

在和一些年轻的数据工程师交流时，我发现一个有趣的现象。

很多人每天都在开发ODS、DWD、DWS、ADS。

熟悉Hive、Spark、Flink、ClickHouse。

却很少认真思考过一个问题：

为什么企业需要数据仓库？

尤其是在AI快速发展的今天。

越来越多的人开始提出类似的问题：

  • 有了湖仓一体，还需要数据仓库吗？
  • 有了ChatBI，还需要数据仓库吗？
  • Agent能够自动生成SQL，还需要数据仓库吗？

在回答这些问题之前，我们需要先回到数据仓库诞生的那个时代。

因为只有理解它为什么出现，才能理解它为什么至今仍然存在。

企业最早并没有数据仓库

今天很多企业的数据架构看起来似乎理所当然：

1
ERP → 数据仓库 → BI → 报表

但实际上，大多数企业最初并没有数据仓库。

在信息化建设初期，企业通常只有几个核心业务系统：

  • ERP
  • 财务系统
  • CRM
  • HR系统

当管理层需要数据时，往往直接从业务系统查询。

例如：

销售总监问：

“本月销售额是多少？”

技术人员登录ERP数据库。

执行一条SQL。

得到结果。

似乎没有任何问题。

因为那时：

  • 数据量不大
  • 系统数量不多
  • 分析需求简单

业务系统同时承担：

  • 交易处理
  • 数据存储
  • 数据分析

三种职责。

但随着企业规模扩大，问题开始逐渐暴露。

第一个问题：业务系统不是为分析而设计的

ERP最重要的任务是什么？

是保证订单能够正常流转。

CRM最重要的任务是什么？

是保证客户管理流程正常运行。

MES最重要的任务是什么？

是保证生产过程可控。

这些系统有一个共同特点：

它们都属于OLTP系统（联机事务处理系统）。

其核心目标是：

  • 快速写入
  • 快速更新
  • 高并发事务

而数据分析恰恰相反。

分析系统更关注：

  • 大量历史数据
  • 多表关联计算
  • 聚合统计分析

例如：

业务系统可能需要快速保存一笔订单。

而分析系统则希望统计：

过去三年各区域产品销售趋势。

这是两种完全不同的工作模式。

如果直接在ERP上执行复杂分析：

轻则查询缓慢。

重则影响业务运行。

因此：

业务系统适合处理交易，不适合处理分析。

这是数据仓库存在的第一个原因。

第二个问题：企业的数据是分散的

很多企业管理层都喜欢问这样的问题：

“哪个客户最赚钱？”

看起来很简单。

但实际计算往往涉及多个系统：

销售额来自CRM。

成本来自ERP。

回款来自财务系统。

物流费用来自供应链系统。

如果没有统一的数据平台。

每次分析都需要跨系统取数。

不仅效率低。

而且很容易出现口径不一致的问题。

例如：

销售部门说客户A贡献利润500万元。

财务部门说只有350万元。

双方都认为自己正确。

问题出在哪里？

不是数据错了。

而是计算逻辑不同。

企业真正需要的不是更多数据。

而是统一的数据语言。

这正是数据仓库解决的核心问题之一。

第三个问题：业务系统只关心现在

业务系统关注的是当前状态。

例如ERP中的库存表。

今天库存100件。

明天库存80件。

后天库存120件。

ERP只需要记录当前库存。

但管理层更关心：

  • 库存变化趋势
  • 历史库存水平
  • 周转率变化

这些分析都需要历史数据。

而历史数据往往不会长期保存在业务系统中。

于是企业开始把业务数据持续同步出来。

形成历史快照。

构建分析主题。

这也是数据仓库的重要价值。

它不仅存储数据。

更保存企业经营过程中的历史记忆。

第四个问题：企业需要统一指标

很多企业都有一个经典现象。

开会时讨论同一个指标。

不同部门拿出不同数字。

例如：

“上个月销售额是多少？”

销售部门：

1.2亿元。

财务部门：

1.05亿元。

运营部门：

1.1亿元。

数据部门：

1.15亿元。

每个人都能解释自己的计算逻辑。

但最终没人知道哪个数字才是正确的。

问题本质上不是数据问题。

而是指标问题。

数据仓库建设过程中。

企业第一次开始系统化思考：

  • 什么是销售额？
  • 什么是利润？
  • 什么是客户数？
  • 什么是新增用户？

通过统一口径。

企业建立起共同的数据语言。

从某种意义上说：

数据仓库最大的价值不是存储数据，而是统一认知。

数据仓库真正解决了什么？

如果把前面的问题总结一下。

数据仓库解决的并不是简单的数据存储问题。

而是四个核心问题：

第一：

让业务系统专注交易处理。

第二：

打通企业数据孤岛。

第三：

沉淀历史数据资产。

第四：

统一企业指标体系。

因此。

数据仓库的本质不是一个数据库。

而是一套数据组织方法。

是一种让企业能够理解自身经营状况的基础设施。

AI时代，数据仓库为什么依然重要？

最近两年。

很多人开始讨论：

ChatBI。

Data Agent。

自然语言问数。

智能分析。

似乎未来不再需要数据仓库。

但实际上。

这些新技术恰恰更加依赖数据仓库。

我们可以思考一个简单问题：

如果企业内部存在三个版本的销售额。

Agent应该相信谁？

如果客户名称在不同系统中不一致。

Agent应该分析哪个客户？

如果历史数据缺失。

Agent如何完成趋势分析？

如果数据质量存在问题。

Agent如何保证回答正确？

答案很简单。

Agent不会自动创造事实。

Agent只能利用已有事实。

而数据仓库正是企业事实的组织者。

过去：

数据仓库服务BI。

未来：

数据仓库服务Agent。

它的角色会变化。

但其核心价值不会消失。

数据仓库最大的价值，其实是降低沟通成本

很多人认为数据仓库的价值在于技术。

我越来越觉得不是。

数据仓库最大的价值其实是：

降低组织沟通成本。

当企业拥有统一的数据口径时：

销售和财务不再争论数字。

业务和技术不再争论规则。

管理层不再争论结果。

大家能够把精力放在真正重要的问题上：

为什么会这样？

应该怎么办？

而不是：

数字到底哪个对？

从这个角度看。

数据仓库从来不是技术项目。

而是企业管理能力建设的一部分。

写在最后

过去二十年。

数据仓库之所以能够成为企业数据体系的核心。

并不是因为它拥有最先进的技术。

而是因为它解决了企业最本质的问题：

让企业能够用统一的语言理解自己的经营状况。

AI不会改变这一点。

ChatBI不会改变这一点。

Data Agent也不会改变这一点。

未来发生变化的。

只是数据被消费的方式。

而不会是数据被组织的逻辑。

下一篇文章，我们继续讨论另一个关键问题：

BI为什么成为企业数据消费的主流模式？

发表于 更新于

过去二十年，企业数据领域发生过很多变化。

数据库、数据仓库、大数据平台、数据治理、BI、数据中台、湖仓一体、ChatBI、Data Agent……

新概念层出不穷，新技术不断涌现。

但如果站在更高的视角来看，这二十年的变化，本质上是在解决同一个问题：

如何更快、更准确地获得答案。

今天很多人在讨论AI、Agent、ChatBI。

有人说数据仓库会消失，有人说BI将被取代，还有人认为未来根本不需要数据开发工程师。

这些观点听起来很有冲击力，但如果不了解企业数据体系的发展历程，就很容易得出片面的结论。

因此，在讨论AI会带来什么变化之前，我们不妨先回顾一下企业数据开发范式过去二十年的演进历程。

第一阶段：数据库时代——直接从业务系统取数

大约在2000年前后，大多数企业的信息化建设刚刚起步。

企业中的核心系统主要是：

  • ERP
  • 财务系统
  • 进销存系统
  • 人事系统

那时的数据分析需求并不复杂。

业务人员提出问题：

“这个月销售额是多少？”

技术人员登录数据库，写一条SQL。

很快就能得到结果。

那时的数据开发范式可以简单概括为：

1
业务系统 = 数据源 = 分析系统

所有分析工作直接基于业务数据库完成。

这种模式在企业规模较小时运行良好。

但随着企业发展，问题逐渐出现。

例如：

  • ERP关注交易处理
  • 财务系统关注账务处理
  • CRM关注客户管理

每个系统的数据标准不同。

每个系统的数据口径不同。

每个系统都只关注自身业务。

当企业希望回答：

“某客户的销售额、利润和回款情况如何？”

就需要跨多个系统进行关联分析。

此时，数据库时代开始暴露出局限性。

企业需要一种新的数据组织方式。

数据仓库由此诞生。

第二阶段：数据仓库时代——让数据形成统一语言

从2005年前后开始，越来越多企业开始建设数据仓库。

数据仓库的核心思想并不复杂：

把分散在各业务系统中的数据统一汇集起来。

通过清洗、转换、整合。

形成统一的数据资产。

此时，企业数据架构开始演变为：

1
业务系统 → 数据集成 → 数据仓库 → 数据应用

对于很多企业而言，这是一次巨大的进步。

数据仓库解决了几个关键问题：

第一，统一数据口径。

同一个指标不再出现多个版本。

第二，沉淀历史数据。

业务系统可能只保留当前状态。

数据仓库可以保留完整历史轨迹。

第三，提高分析效率。

复杂分析不再直接访问业务数据库。

第四，实现跨系统分析。

企业第一次能够从全局视角看待经营数据。

也正是在这一时期，维度建模、星型模型、事实表、维度表等概念开始广泛普及。

很多企业的数据团队开始形成：

  • ETL开发工程师
  • 数据仓库工程师
  • BI工程师

等专业岗位。

数据开发开始进入工程化时代。

第三阶段：BI时代——从数据到决策

如果说数据仓库解决的是“数据从哪里来”的问题。

那么BI解决的是：

“数据如何被使用”的问题。

从2010年以后，越来越多企业开始建设：

  • 经营驾驶舱
  • 管理看板
  • KPI体系
  • 数据分析平台

FineBI、Tableau、Power BI等产品快速发展。

企业开始尝试用数据驱动决策。

此时的数据开发范式变成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
业务系统

↓

数据仓库

↓

OLAP

↓

BI

↓

决策分析

这也是很多企业今天仍然在采用的主流架构。

这一模式极大提升了企业的数据使用效率。

但与此同时，一个新的问题开始出现。

所有答案都需要提前准备。

  • 业务提出需求。
  • 数据团队开发ETL。
  • 开发指标。
  • 开发报表。
  • 测试上线。

最终才能看到结果。

很多企业都经历过这样的场景：

业务部门提出一个分析需求。

排期两周。

开发一周。

测试三天。

上线一天。

最后花费近一个月时间。

而业务真正关心的问题，可能只需要一个答案。

问题并不在于技术。

而在于这种模式本质上属于：

先开发答案，再提出问题。

这也为下一轮变革埋下伏笔。

第四阶段：AI时代——从开发答案到生成答案

2022年以后，大模型开始快速发展。

ChatGPT、Claude、DeepSeek等产品让自然语言交互成为现实。

与此同时，企业数据领域也开始出现新的变化。

ChatBI开始流行。

智能问数开始普及。

企业知识库快速增长。

Data Agent不断涌现。

过去的数据分析过程通常是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
提出问题

↓

提交需求

↓

开发模型

↓

开发报表

↓

获得答案

而今天越来越多企业开始尝试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
提出问题

↓

Agent理解问题

↓

自动检索数据

↓

自动生成SQL

↓

自动分析

↓

获得答案

两种模式最大的区别在于：

过去是开发答案。

现在是生成答案。

这是企业数据开发范式过去二十年来最重要的一次变化。

AI会取代数据仓库吗？

这是最近两年被问得最多的问题之一。

我的观点很明确：

不会，至少在可预见的未来不会。

因为AI解决的是答案生成问题，而数据仓库解决的是数据组织问题。两者并不是替代关系。

Agent越强，越依赖高质量的数据基础。

ChatBI越智能，越需要统一的数据口径。

企业知识库越丰富，越需要高质量的数据治理。

未来消失的不会是数据仓库，而是数据仓库作为最终消费终端的角色。

它会逐渐退居幕后，成为Agent的数据底座。

下一代企业数据体系正在形成

回顾过去二十年。

企业数据体系经历了四次重要演进：

数据库时代：

解决数据存储问题。

数据仓库时代：

解决数据整合问题。

BI时代：

解决数据消费问题。

AI时代：

解决答案生成问题。

每一次演进，都不是推翻上一代体系。

而是在上一代基础上的能力扩展。

因此，我并不认为AI会终结企业数据体系。

AI正在推动企业数据体系进入一个新的阶段。

未来五年。

真正值得关注的问题不是：

“数据仓库会不会消失？”

而是：

“企业如何构建能够支撑Agent的数据体系？”

这也是本专栏接下来希望持续探讨的话题。

下一篇，我们将从一个最基础的问题开始：

为什么企业需要数据仓库？

发表于 更新于

这些年，无论是数字化转型、智能制造，还是人工智能，几乎都绕不开一个关键词：

数据。

很多企业也确实投入了大量资源：

  • 上ERP
  • 建MES
  • 做数据仓库
  • 上BI平台
  • 搭数据中台

但如果认真观察会发现，不同企业的数据建设效果差异非常大。

有的企业：

  • 报表越来越多
  • 数据越来越全
  • 但业务依然靠经验决策

而有的企业：

  • 数据已经成为经营管理的重要组成部分
  • 甚至开始驱动业务创新

同样是数据建设，为什么会出现如此大的差异？

因为企业之间最大的区别，往往不是技术水平，而是：

数据能力所处的发展阶段不同。

数据治理的本质，不是建设几个系统，也不是做几个项目。

从更长周期来看，它实际上是在推动企业完成一次能力升级：

从报表驱动，走向数据驱动；从数据资源，走向数据资产。

一、企业数据能力的发展，往往会经历四个阶段

过去十多年，我参与过互联网企业的数据平台建设，也参与过制造业数据仓库和数据治理项目。

回头来看，大多数企业的数据能力演进路径其实非常相似。

大致可以分为四个阶段。

第一阶段：报表时代

这是绝大多数企业数字化建设的起点。

企业建设ERP、财务系统、进销存系统之后，最直接的需求就是：

我要看报表。

于是开始建设：

  • 日报
  • 周报
  • 月报
  • 经营分析报表

这个阶段最大的特点是：

数据用于展示结果。

例如：

  • 本月销售额是多少
  • 本月生产多少产品
  • 库存还有多少

企业开始拥有数据，但数据主要承担的是：

统计和汇报功能。

这个阶段的典型问题

每个部门都有自己的报表：

  • 财务有财务报表
  • 销售有销售报表
  • 生产有生产报表

结果经常出现：

同一个指标，不同部门算出来的结果不一样。

于是管理层开始产生疑问：

到底哪个数据是真的？

这时候企业会发现：

问题已经不是没有数据，而是数据不一致。

于是进入第二阶段。

第二阶段：数据整合时代

为了统一数据，企业开始建设：

  • 数据仓库
  • 数据平台
  • BI系统

通过整合ERP、MES、CRM等系统数据：

形成统一的数据出口。

这一阶段解决的是：

数据集中问题。

企业开始拥有：

  • 统一指标
  • 统一报表
  • 统一分析平台

相比第一阶段，这是一次巨大进步。

但新的问题出现了

很多企业走到这里后会发现：

虽然数据统一了，但业务依然不完全信任数据。

原因很简单：

  • 客户编码不统一
  • 物料编码不统一
  • 指标口径不统一

于是：

数据仓库建好了，但数据治理的问题开始暴露出来。

企业进入第三阶段。

第三阶段：数据治理时代

这个阶段，企业开始意识到：

数据问题不是技术问题，而是管理问题。

开始关注：

  • 数据标准
  • 数据质量
  • 主数据管理
  • 元数据管理
  • 数据责任体系

企业不再仅仅关注：

数据怎么存。

而开始关注：

数据是否可信。

这是一个重要转折点。

在这个阶段

企业逐步建立：

  • Data Owner
  • Data Steward
  • 数据治理委员会

建立：

  • 数据标准体系
  • 数据质量机制
  • 主数据管理体系

经过一段时间后，企业内部会出现一个明显变化：

大家开始逐步相信同一套数据。

这其实是数据治理最大的价值之一。

因为：

信任，才是数据价值释放的前提。

第四阶段：数据资产时代

这是很多企业努力的方向，也是数据治理真正想达到的目标。

什么叫数据资产？

简单来说：

数据能够持续创造价值，并且被企业主动运营。

这时候数据已经不仅仅是：

  • 报表来源
  • 分析依据

而成为企业的重要生产要素。

数据开始支撑经营

例如：

  • 销售预测
  • 库存优化
  • 采购计划
  • 生产排程
  • 渠道管理
  • 客户运营

数据开始驱动决策

管理层讨论问题时：

不再是：

“我觉得……”

而是：

“数据告诉我们……”

数据开始创造新的价值

例如：

  • 数据产品
  • 数据服务
  • 数据运营
  • AI应用

尤其在人工智能时代。

企业会越来越深刻地认识到：

AI的上限，很大程度取决于数据的质量和治理水平。

二、为什么很多企业始终停留在“报表阶段”？

这是一个值得思考的问题。

很多企业投入了大量资金：

  • 买系统
  • 建平台
  • 招团队

但几年之后：

依然停留在做报表。

原因往往不是技术。

而是缺少三个关键能力。

第一：统一标准

没有统一标准：

  • 指标无法统一
  • 数据无法复用
  • 资产无法沉淀

第二：治理机制

没有治理机制：

  • 数据质量无法持续改善
  • 主数据无法长期维护

第三：业务参与

数据治理从来不是IT部门的事情。

真正的数据资产：

一定是业务和技术共同建设的结果。

三、制造业企业的数据资产化，更应该关注什么？

结合大量制造业实践，我认为有三个优先方向。

优先做好主数据

重点包括：

  • 物料
  • 客户
  • 供应商

这是所有分析和决策的基础。

优先做好核心指标

重点包括：

  • 收入
  • 库存
  • 订单
  • 产量
  • 交付

不要一开始追求几千个指标。

先把最关键的几十个指标做好。

优先做好治理闭环

重点：

  • 发现问题
  • 解决问题
  • 防止重复发生

形成持续改进机制。

四、AI时代，数据治理正在被重新定义

过去很多企业认为：

数据治理是成本。

今天越来越多企业开始意识到：

数据治理是能力建设。

尤其随着生成式AI的发展。

企业逐渐发现：

如果：

  • 数据标准不统一
  • 主数据混乱
  • 数据质量不稳定

那么：

  • 企业知识库效果差
  • AI问答不可信
  • 智能分析结果不准确

换句话说：

AI不是替代数据治理，而是在倒逼企业重视数据治理。

未来企业之间的竞争，很可能不只是：

谁拥有AI

而是：

谁拥有更高质量的数据资产。

五、写在最后

回顾整个系列，我们讨论了：

  • 为什么数据治理项目会失败
  • 制造业数据治理难在哪
  • ERP与MES如何打通
  • 数据仓库为什么建而不用
  • 数据质量如何持续改善
  • 什么是真正的数据治理体系
  • 数据标准为什么是起点
  • 主数据管理到底要不要做
  • 数据治理组织如何设计

最终，其实都在回答同一个问题：

企业为什么要做数据治理？

我的答案是：

数据治理从来不是为了治理而治理。

它真正的意义在于：

让企业的数据，从记录业务，走向支撑业务；从支撑业务，走向驱动业务；最终成为企业持续创造价值的数据资产。

而这，或许才是数据治理最值得投入的地方。

系列结语

如果把企业数据建设比作盖房子：

  • 数据平台是钢筋水泥
  • 数据仓库是主体结构
  • 数据标准是设计图纸
  • 数据治理是施工管理
  • 数据资产则是最终建成并持续创造价值的大厦

很多企业已经拥有了砖瓦。

接下来更重要的，是把这些砖瓦真正组织起来，形成能够长期支撑企业发展的数据能力体系。

因为未来企业的竞争，不仅是产品的竞争、效率的竞争，更是数据能力的竞争。

而数据治理，正是这场竞争的起点。

发表于

很多企业在推进数据治理时，前期往往会投入大量精力在：

  • 数据平台
  • 数据仓库
  • BI系统
  • 数据质量工具

这些都很重要。

但真正做一段时间后，很多团队会慢慢发现：

技术问题其实没那么难，真正难的是:事情到底谁来推动？问题到底谁来负责？

你会看到很多熟悉的场景：

  • 数据有问题，但没人认领
  • 规则定了，但没人执行
  • 报表对不上，部门之间互相解释
  • 数据治理开会很热闹，落地却很慢

最后项目进入一种状态：

“大家都知道重要，但就是推进不动。”

而这背后，真正缺少的，往往不是技术，而是：

数据治理组织机制。

一、很多企业的数据治理，为什么越做越累？

因为它通常是这样开始的：

第一阶段：IT部门发起

企业想做数字化，于是：

  • 建数仓
  • 做BI
  • 做指标

数据治理也顺理成章交给IT团队。

刚开始问题不大。

但随着推进深入，很快会发现：

IT能处理“数据”，却很难决定“业务”

例如：

  • 什么是营收收入？
  • 哪个库存口径用于经营分析？
  • 客户怎么分类？

这些问题，本质上都是：

业务规则问题。

IT可以实现，但不能替业务拍板。

于是项目慢慢进入一种尴尬状态：

  • IT在推进
  • 业务在观望
  • 管理层偶尔关注
  • 但没人真正“负责治理”

最后：

数据治理变成了一项“长期协调工作”。

二、为什么说“数据治理本质是组织问题”？

因为数据天然具有一个特点：

它是“跨部门”的。

例如：

一个订单，会经过：

  • 销售
  • 财务
  • 生产
  • 仓储
  • 供应链

每个部门：

  • 都会产生数据
  • 都会使用数据
  • 也都会定义数据

于是问题就来了：

谁说了算？

如果没有组织机制，最后通常会变成：

  • 各自维护自己的口径
  • 各自相信自己的数据

最终：

企业内部形成多个“数据世界”。

三、数据治理组织，到底在解决什么？

很多人会把“数据治理组织”理解成：

成立一个数据治理部门。

但真正核心的，其实不是“部门”，而是：

责任机制。

它要解决的是：

1️⃣ 谁定义数据？

例如：

  • 收入口径谁定？
  • 客户分类谁定？
  • 物料编码规则谁定？

2️⃣ 谁维护数据？

例如：

  • 数据错误谁修复？
  • 主数据谁审核？
  • 指标变更谁管理？

3️⃣ 谁对结果负责？

例如：

  • 报表不一致怎么办？
  • 数据质量下降怎么办？

👉 如果这些问题没有明确答案：

那么数据治理一定会越来越难推进。

四、一个比较实用的数据治理组织模型

很多企业一听“组织建设”，容易想到：

  • 大规模组织调整
  • 新成立部门
  • 复杂管理体系

其实未必需要。

对于大部分企业，更现实的方法是：

在现有组织上，建立“数据治理责任体系”。

这里分享一个比较通用、也比较容易落地的模型。

五、三个核心角色（非常关键）

1️⃣ Data Owner（数据Owner）

这是整个治理体系里最核心的角色。

通常由：

  • 业务负责人
  • 部门负责人

担任。

例如：

  • 销售数据 → 销售负责人
  • 库存数据 → 仓储负责人

Owner负责什么？

核心只有一句话：

对数据结果负责。

包括：

  • 数据定义
  • 指标口径
  • 数据准确性

👉 注意：

Owner一定是业务角色，而不是IT。

因为：

业务最懂业务数据。

2️⃣ Data Steward（数据管理员/数据管家）

这个角色更偏执行与运营。

通常来自：

  • 业务骨干
  • 数据团队
  • 信息化团队

Steward负责什么？

例如：

  • 数据维护
  • 规则执行
  • 数据问题跟踪
  • 数据质量监控

如果说Owner负责“方向”，那么Steward负责：

“日常运行”。

3️⃣ 数据治理委员会（很多企业忽略）

这是跨部门协调的关键。

因为很多问题：

  • 不是某一个部门能决定的
  • 而是涉及多个业务口径

例如：

  • 收入口径
  • 订单定义
  • 库存规则

这些问题，必须有：

企业级协调机制。

委员会不需要天天开会

但需要具备几个能力：

  • 标准审批
  • 冲突协调
  • 优先级决策
  • 重大问题推动

六、一个特别容易被忽略的问题

很多企业会任命：

  • 数据负责人
  • 数据管理员

但最后发现：

角色有了，事情还是推进不动。

为什么？

因为：

“责任”没有真正进入业务流程。

举个典型例子：

如果：

  • 数据质量问题
  • 不影响绩效
  • 不影响业务流程
  • 不影响结果考核

那么再强调“重要”，也很难长期执行。

所以数据治理组织真正有效，往往需要：

数据责任“进入管理体系”

例如：

  • 数据质量纳入部门考核
  • 核心指标必须统一口径
  • 主数据变更必须审批

👉 当数据开始影响业务运行时，治理才会真正发生。

七、很多企业治理推进不下去，其实是“节奏错了”

还有一种常见问题：

一开始就想搭建“大而全”的治理体系。

结果：

  • 会议越来越多
  • 规则越来越复杂
  • 业务越来越疲惫

最后：

大家逐渐失去耐心。

更合理的方式通常是：

1️⃣ 先明确关键领域

例如：

  • 销售
  • 库存
  • 生产

不要一开始覆盖全公司。

2️⃣ 先解决关键问题

例如：

  • 指标不一致
  • 主数据混乱
  • 数据质量问题

先做出“可见效果”。

3️⃣ 用结果建立信任

这是非常重要的一步。

当业务看到：

  • 数据开始可信
  • 报表开始统一
  • 协同效率提升

治理体系才会真正获得支持。

八、一个很现实的理解

很多企业会认为：

数据治理是“IT升级”。

但真正成熟之后会发现：

数据治理其实是“管理升级”。

因为它最终改变的是：

  • 企业内部协同方式
  • 数据责任机制
  • 决策运行模式

九、写在最后

很多数据治理项目，最后真正拉开差距的，并不完全是：

  • 技术平台
  • 工具能力
  • 系统架构

而是：

在上面的基础之上，有没有形成一套真正能持续运行的组织机制。

因为：

技术可以快速建设，
但“组织共识”和“责任体系”，才决定数据治理能走多远。

发表于 更新于

在数据治理领域，“MDM（主数据管理）”一直是一个很有意思的话题。

一方面，很多企业一提数据治理，就会想到MDM；
另一方面，也有不少企业在做过之后，留下了一句评价：

“投入很大，但效果并没有想象中明显。”

于是问题就来了：

主数据管理，到底有没有必要做？
什么企业适合做？
又为什么很多MDM项目最后做得很“痛苦”？

这篇文章，我们不讲概念堆砌，而是站在企业真实落地的角度，聊聊MDM这件事。

一、很多企业，其实已经“被主数据问题困扰很久了”

只不过，他们未必意识到：

这些问题，本质上是“主数据问题”。

来看几个制造业里非常常见的场景。

场景1：同一个物料，不同的系统里有多个名字

ERP里叫：

“一次性无菌导管”

MES里可能叫：

“无菌导管”

仓库系统里又叫：

“导管A型”

结果：

  • 库存统计对不上
  • 采购分析混乱
  • BI报表无法统一

最后只能靠人工“猜”。

场景2：同一个物料，同一个系统里有多个

这种情况属于物料编码在进行 MDM 管理，不过后续操作层面存在问题。

比如物料编码最初由 ERP 同步过来，所以

  • 物料编码在 ERP 是唯一
  • 初始化同步到SRM时也是唯一
  • 但是 SRM 又生成了自己系统的唯一ID，SRM 内部关联使用的是本身系统的唯一ID

后续物料规格有调整，SRM 采用的是新增数据行的方式，导致

ERP 的唯一物料编码 在 SRM 系统不唯一了。

这种情况在企业内部还比较常见。

场景3：客户重复、分裂

CRM有一套客户；
ERP有一套客户；
财务系统还有一套客户。

甚至：

  • 同一个客户有多个编码
  • 名称还不完全一致

例如：

  • “XX医疗科技有限公司”
  • “XX医疗”
  • “XX医疗科技有限公司(河北)”

系统看起来是三个客户，但业务知道：

其实是同一家。

场景3：供应商无法统一分析

采购部门想分析：

某供应商全年采购额。

结果发现：

  • 不同系统编码不同
  • 历史数据不一致
  • 公司名称变化过

最后：

根本无法准确汇总。

这些问题，看起来像：

  • 系统问题
  • 数据问题
  • 历史问题

但如果抽象一下，你会发现它们有一个共同点：

同一个“核心业务对象”，在企业内部没有统一身份。

而这，就是MDM要解决的问题。

二、那什么是“主数据”？

很多人第一次接触MDM，会觉得概念有点抽象。

其实可以简单理解：

主数据，就是企业里“被反复使用、跨系统共享”的核心业务对象。

例如：

  • 物料
  • 客户
  • 供应商
  • 组织
  • 员工

这些数据有几个共同特点：

1️⃣ 使用范围广

不仅一个系统使用，而是：

  • ERP在用
  • MES在用
  • SRM也在用

2️⃣ 生命周期长

不像订单、库存这种“交易数据”会不断变化。

主数据通常长期存在。

例如：

  • 一个物料可能使用几年
  • 一个客户可能合作十几年

3️⃣ 一旦混乱，影响会被不断放大

这点非常关键。

如果一个物料编码错了：

  • 采购会错
  • 库存会错
  • 生产会错
  • 分析也会错

👉 主数据问题，会“传染”。

三、为什么很多企业“越数字化，主数据越乱”？

这是个很现实的问题。

理论上：

系统越多，数据应该越规范。

但现实往往相反：

系统越多，主数据越混乱。

为什么？

因为很多企业的信息化建设，是“分阶段成长”的。

第一年，上ERP
第二年，上MES
第三年，上CRM
后面又上：

  • WMS
  • SRM
  • BI

每套系统：

  • 厂商不同
  • 设计不同
  • 编码规则不同

早期可能还能靠人工维持。

但随着系统越来越多，就会逐渐出现：

“同一个东西，在不同系统里长得完全不一样。”

四、那MDM到底在做什么？

很多人以为：

MDM = 做一个主数据系统

其实这只是表象。

MDM真正做的事情是：

1️⃣ 建立统一的数据身份

例如：

  • 一个客户，全公司只有一个主身份
  • 一个物料，全系统只有一个标准编码

2️⃣ 建立统一标准

包括：

  • 命名规则
  • 分类规则
  • 编码规则

3️⃣ 建立数据同步机制

让各业务系统：

  • 使用同一套主数据
  • 保持一致更新

4️⃣ 建立管理机制

包括：

  • 谁创建？
  • 谁审核？
  • 谁变更？

👉 这其实已经不只是技术问题，而是：

企业管理问题。

五、很多MDM项目为什么失败？

这是最值得聊的一部分。

因为很多企业不是没做MDM，而是：

做完之后，发现很难真正运行下去。

常见原因有几个。

1️⃣ 一上来就“全量建设”

一开始就想统一：

  • 所有物料
  • 所有客户
  • 所有供应商
  • 所有组织

结果：

  • 周期特别长
  • 协调成本巨大
  • 业务逐渐失去耐心

最后项目变成：

“一直在建设，但始终没上线。”

2️⃣ 过于技术化

很多MDM项目：

  • 重点在系统
  • 重点在平台
  • 重点在同步接口

但真正困难的是：

业务规则统一。

比如：

  • 客户到底怎么分类？
  • 物料编码谁说了算？

这些问题，不是技术能决定的。

3️⃣ 没有业务推动

如果业务部门认为：

“这是IT项目”

那么MDM大概率很难成功。

因为主数据本身就是：

业务数据。

最终一定需要：

  • 采购参与
  • 生产参与
  • 销售参与

4️⃣ 想一步做到“绝对统一”

这是很多企业容易陷入的理想化状态。

现实里：

  • 历史数据一定有问题
  • 不同系统一定存在差异
  • 一次性完全统一几乎不可能

所以：

MDM不是“世界瞬间完美”，而是“逐步减少混乱”。

六、那企业到底要不要做MDM？

我的观点其实很明确：

大部分制造企业，最终都需要做MDM。

尤其是：

  • 系统越来越多
  • 数据分析越来越深入
  • 想真正做经营决策

因为没有统一主数据，后面会越来越痛苦：

  • 数据越来越难对
  • 系统越来越难集成
  • 报表越来越难统一

但这里有个关键前提：

不要把MDM理解成“大系统项目”。

很多时候，更合理的做法是：

从“小而关键”开始。

七、一个更现实的MDM落地路径

这是我更推荐的一种方式。

第一步：先统一最关键的主数据

优先级通常是：

  • 物料
  • 客户
  • 供应商

第二步：先建立“标准”，再谈“平台”

很多企业顺序反了。

其实应该先明确：

  • 编码规则
  • 命名规则
  • 分类规则

然后再考虑系统实现。

第三步：建立映射关系（非常重要）

现实里，不可能一下完全替换历史数据。

所以很多时候需要：

“主数据映射层”

例如：

  • ERP编码 → 标准编码
  • MES编码 → 标准编码

这一步非常实用。

第四步：逐步治理，而不是一次革命

真正成熟的MDM，往往是：

  • 一边运行
  • 一边优化
  • 一边统一

而不是：

停下来重建整个世界。

八、一个很重要的理解

很多企业把MDM理解成：

“数据治理高级阶段”

但其实：

MDM本质上是在解决企业“语言不统一”的问题。

它统一的不是数据本身，而是：

  • 企业对业务对象的认知
  • 企业内部的业务语言
  • 企业跨系统的协同方式

九、写在最后

如果你的企业已经出现：

  • 多系统数据难以统一
  • 指标反复对不上
  • 主数据大量重复混乱

那么很可能说明：

你已经到了必须认真面对MDM的时候。

但也不必把它想得太重。

因为真正有效的MDM，从来不是：

“一套宏大的系统工程”

而是：

从一个关键对象开始，逐步建立统一与秩序。