华为数据之道精读：某头部 ICT 企业如何从数据混乱走向 IT 治理闭环

数据混乱的典型症状

2015年前后，某头部ICT企业内部流传着一句话：“找数据比写代码还难。”

这不是夸张。当时这家年收入超千亿的企业，面临着几乎所有大型组织的共同困境：

• 同一个客户，三个系统三个名字。CRM里叫"ABC科技"，ERP里是"ABC科技有限公司"，计费系统里缩写成"ABC"。对账时财务部门每月要花两周人工匹配。
• 库存数据永远对不上。仓库系统显示有货，销售系统却显示缺货。后来发现两个系统的数据更新延迟差了48小时。
• 报表打架。市场部说季度增长15%，财务部说只涨了8%。两边都拿出了"权威数据"，但口径完全不同。
• 新员工入职第一天最崩溃。要申请七八个系统的权限，每个系统找不同的人审批，问一圈才知道谁管哪块数据。

某技术负责人回忆：“那时候我们意识到，系统越来越多，但数据越来越乱。IT投入每年涨，但业务部门对数据的满意度反而在降。”

这个问题不解决，数字化转型就是空谈。

Data Owner 机制：让每块数据都有"主人"

为什么需要 Data Owner

2016年，这家企业启动了一项看似简单却影响深远的变革：给每一类数据指定明确的负责人。

听起来理所当然，但在大型组织里，数据往往是"公地悲剧"的典型场景——大家都在用，但没人觉得该自己管。

某业务部门负责人的原话是：“以前数据出了问题，IT说业务没录对，业务说IT系统有问题，最后谁也不认账。”

Data Owner 的职责划分

这家企业把数据治理职责分成了三层：

关键设计点在于：Data Owner 必须是业务部门的人，不能是IT。

某数据治理专家解释：“数据是业务产生的，业务最清楚这数据该怎么用、什么算准确。如果让IT当Owner，就变成了IT替业务做决策，本末倒置。”

考核机制：让数据治理"动真格"

职责定了，怎么让人当真？这家企业的做法是把数据质量纳入绩效考核。

具体操作：

1. 每季度发布数据质量报告。每个业务部门的数据质量分数公开排名，从数据完整性、准确性、及时性、一致性四个维度打分。

2. 数据质量分数直接影响部门绩效。某业务线曾因为客户数据准确率低于90%，整个部门的季度绩效被降了一档。

3. 数据安全事故一票否决。发生过一次客户数据泄露的部门，当年评优资格直接取消。

这套机制刚推行时阻力很大。某业务线总监曾公开质疑：“我们是做业务的，不是做数据录入的。”

但半年后，态度变了。因为数据质量提升后，报表不用反复核对，决策速度明显加快，跨部门协作的扯皮也少了。

落地难点与应对

难点一：边界怎么划？

有些数据跨多个部门，比如"订单"涉及销售、交付、财务。这家企业的做法是按业务对象切分，不按部门切分。

“订单"作为一个整体业务对象，指定一个Owner（通常是销售部门负责人），其他部门作为Stakeholder参与治理委员会。

难点二：Owner不愿意管怎么办？

除了考核压力，这家企业还设计了正向激励：

• 数据质量优秀的部门，优先获得IT资源支持
• 年度评选"数据治理标杆团队”，给予专项奖金
• 数据资产化后，数据Owner可以"出租"数据服务给其他部门，获得内部结算收入

难点三：怎么防止Owner变成"数据垄断者"？

这家企业明确规定：Data Owner 的职责是治理，不是独占。数据必须按标准开放，Owner不能无理由拒绝其他部门的合理数据需求。

有句话说：“Data Owner 是数据的管家，不是数据的地主。”

信息架构设计：从业务对象到数据资产

为什么信息架构是数据治理的"地基"

有了Owner，下一个问题是：到底要管哪些数据？

这家企业发现，很多部门连自己有哪些数据都说不清。某IT系统里存了300多个表，但业务部门只知道"系统里什么都有"，具体有哪些字段、什么含义、谁在用，没人能完整回答。

2017年，这家企业启动了信息架构（Information Architecture）梳理项目，目标是用一套统一的语言描述全公司的数据资产。

业务对象：数据的"最小业务单元"

信息架构的核心概念是业务对象（Business Object）。

业务对象的定义是：业务运转中不可或缺的、可独立识别的实体。

举例：

• 客户（Customer）
• 产品（Product）
• 订单（Order）
• 合同（Contract）
• 员工（Employee）

这家企业花了三个月，组织20多个业务部门，梳理出了约400个核心业务对象。

某架构师回忆：“最难的不是列对象，而是达成共识。市场部说’线索’和’商机’是两个对象，销售部说是一个。最后我们定了规则：如果生命周期不同，就是不同对象。”

从业务对象到数据模型

业务对象确定后，下一步是定义每个对象的属性和关系。

这家企业设计了一套标准化的数据模型描述框架：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

业务对象：客户（Customer）
├─ 核心属性
│  ├─ 客户编码（唯一标识）
│  ├─ 客户名称
│  ├─ 客户类型（企业/个人）
│  └─ 客户等级（A/B/C）
├─ 扩展属性
│  ├─ 行业分类
│  ├─ 注册资本
│  └─ 联系人信息
├─ 关联关系
│  ├─ 1个客户 → N个订单
│  ├─ 1个客户 → N个合同
│  └─ 1个客户 → N个服务工单
└─ 数据Owner：销售运营部

每个业务对象都有这样一份"数据档案"，明确了：

• 有哪些属性
• 每个属性的业务含义和技术实现
• 谁负责维护
• 谁有权使用

信息架构的落地工具

为了管理这400多个业务对象和上万个属性，这家企业开发了一个信息架构管理平台。

这个平台的核心功能：

1. 业务对象注册。新增业务对象必须经过审批，避免重复定义。
2. 属性标准管理。每个属性都有标准的命名规范、数据类型、取值范围。
3. 数据血缘追踪。可以看到某个属性在哪些系统里被使用，上下游依赖关系。
4. 版本控制。属性定义变更有完整的审批和记录。

某IT负责人说：“以前改一个字段名，要发邮件问十几个系统有没有用到。现在平台上直接看血缘图，一目了然。”

信息架构带来的实际收益

信息架构梳理完成后，这家企业在三个方面看到了明显变化：

1. 系统建设周期缩短

新系统开发时，直接复用已定义的业务对象和数据模型，不用再从零设计。某项目的项目经理说：“以前需求分析要两周，现在三天就能搞定，因为数据模型都是现成的。”

2. 数据集成成本下降

不同系统之间对接时，因为用了统一的业务对象定义，字段映射的工作量减少了60%。

3. 数据质量可度量

有了明确的属性定义和质量标准，数据质量检查变成了自动化任务，不再依赖人工抽查。

数据服务化：API化、产品化、运营化

从"被动提供"到"主动服务"

2018年，这家企业的数据治理进入了一个新阶段：数据服务化。

背景是：数据质量提升了，但业务部门还是抱怨"数据难用"。原因是数据分散在几十个系统里，业务人员要自己写SQL、自己对接接口，门槛太高。

某业务分析师的吐槽很有代表性：“我60%的时间在找数据和清洗数据，真正做分析的时间不到40%。”

数据服务化的核心理念是：把数据当成产品来运营，把数据需求方当成客户来服务。

API化：让数据"开箱即用"

第一步是数据API化。

这家企业搭建了一个统一的数据服务平台，把常用的数据查询封装成标准API。

典型的数据API示例：

1
2
3
4
5
6
7
8
9

GET /api/v1/customers/{customer_id}
返回：客户基本信息、最近订单、服务记录

GET /api/v1/products/{product_id}/inventory
返回：当前库存、预计到货时间、历史销量

POST /api/v1/reports/sales-summary
参数：时间范围、区域、产品线
返回：销售汇总数据

API化的好处：

• 降低使用门槛。业务人员不用懂数据库，直接调API。
• 统一数据口径。所有API返回的数据都经过标准化处理，避免"各取所需"导致的口径不一致。
• 可监控、可审计。每次数据调用都有记录，便于安全管控和用量分析。

某IT架构师说：“以前业务部门要数据，得提工单，IT排期，一周后才能拿到。现在直接调API，秒级响应。”

产品化：从"工具"到"产品"

API化解决了"能用"的问题，但还不够"好用"。

2019年，这家企业开始推进数据产品化。

数据产品和数据API的区别：

典型的数据产品：

1. 客户360视图。输入客户名称，一站式查看客户的所有信息：基本信息、历史订单、服务记录、信用评级。
2. 销售预测模型。基于历史数据和市场趋势，自动生成未来三个月的销售预测。
3. 供应链风险预警。实时监控供应商的交货准时率、质量合格率，自动触发预警。

某数据产品经理说：“数据产品不是把数据’展示’出来，而是把数据’融入’业务决策流程。用户不需要知道数据从哪来，只需要知道这个产品能帮他做什么决策。”

运营化：让数据产品"活"起来

数据产品上线只是开始，持续运营才是关键。

这家企业的数据运营体系包括：

1. 用户反馈机制

每个数据产品都有反馈入口，用户可以报告数据问题、提出改进建议。运营团队每周review反馈，按月发布更新。

2. 使用量监控

通过数据分析，识别高价值用户和低频用户。对高频用户做深度访谈，了解使用场景；对低频用户做调研，找出使用障碍。

3. 数据质量闭环

用户反馈的数据问题，自动流转到对应的Data Owner处理。处理结果反馈给用户，形成闭环。

某运营负责人说：“数据产品不是上线就完了，要像运营互联网产品一样运营数据产品。用户满意度、活跃度、NPS（净推荐值）都是我们的KPI。”

数据服务化的量化收益

数据服务化推行一年后，这家企业统计了几个关键指标：

• 业务部门获取数据的平均时间从7天缩短到2小时
• 数据相关工单数量下降65%
• 数据产品用户满意度从3.2分提升到4.5分（5分制）
• 数据驱动的决策占比从30%提升到60%

落地路径：三阶段演进策略

阶段一：建基础（6-12个月）

核心目标：建立数据治理组织，明确职责，制定标准。

关键动作：

1. 成立数据治理委员会，任命首席数据官
2. 识别核心业务对象，指定Data Owner
3. 制定数据标准（命名规范、数据类型、质量规则）
4. 搭建数据治理平台（元数据管理、数据质量监控）
5. 选择1-2个试点业务线，跑通治理流程

常见坑：

• 贪大求全，想一次性覆盖所有数据。建议先抓核心业务对象，逐步扩展。
• 只建制度不建工具。数据治理必须平台化，靠人工会累死。
• IT主导，业务旁观。必须让业务部门当Owner，IT做支撑。

阶段二：推应用（12-24个月）

核心目标：数据服务化，让数据真正用起来。

关键动作：

1. 梳理高频数据需求，封装成标准API
2. 开发3-5个核心数据产品（如客户360、经营分析看板）
3. 建立数据运营团队，负责产品迭代和用户支持
4. 推广到更多业务线，收集反馈，优化流程
5. 建立数据资产目录，让用户能"搜索"数据

常见坑：

• 只做API不做产品。API是给开发用的，业务人员需要的是可视化产品。
• 上线后不运营。数据产品需要持续迭代，不能"一锤子买卖"。
• 忽视数据安全。数据开放的同时，必须做好权限管控和审计。

阶段三：促转型（24个月以后）

核心目标：数据驱动业务创新，数据成为核心竞争力。

关键动作：

1. 数据资产化，探索数据对外变现（如数据服务、行业报告）
2. 建设AI/ML平台，用数据训练模型，反哺业务决策
3. 数据治理融入业务流程，成为"默认动作"而非"额外工作"
4. 建立数据文化，全员具备数据思维

常见坑：

• 急于变现。数据资产化需要扎实的基础，不能跳过前两个阶段。
• 技术驱动而非业务驱动。AI项目必须从业务痛点出发，不能为了AI而AI。
• 忽视文化变革。数据治理最终是人的行为改变，需要持续宣导和激励。

从混乱到闭环，关键在人

回顾这家企业的数据治理历程，技术工具固然重要，但真正决定成败的是人和机制。

Data Owner机制解决了"谁负责"的问题，信息架构解决了"管什么"的问题，数据服务化解决了"怎么用"的问题。三者环环相扣，形成了完整的治理闭环。

有句话说：“数据治理不是项目，是能力。”

这家企业用了五年时间，从一个"找数据比写代码还难"的组织，变成了一个"数据即服务"的数据驱动型企业。这个过程没有捷径，但有方法。

如果你所在的组织也面临数据混乱的困境，不妨从这三步开始：找到你的Data Owner，梳理你的核心业务对象，把最常用的数据封装成API。

剩下的，交给时间。