华为数据之道精读：从数据混乱走向IT治理闭环

Wed, 29 Jul 2026 09:00:00 +0800

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

数据混乱的典型症状

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

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

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

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

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

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

为什么需要 Data Owner

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

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

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

Data Owner 的职责划分

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

角色	职责范围	典型人选	考核指标
数据Owner	对某类数据的整体质量、安全、生命周期负责	业务部门负责人	数据质量分、数据安全事故数
数据Steward	日常数据维护、质量问题处理、标准执行	业务骨干或IT BP	问题响应时效、标准覆盖率
数据Custodian	数据存储、备份、技术实现	IT运维人员	系统可用性、数据完整性

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

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

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

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

具体操作：

每季度发布数据质量报告。每个业务部门的数据质量分数公开排名，从数据完整性、准确性、及时性、一致性四个维度打分。
数据质量分数直接影响部门绩效。某业务线曾因为客户数据准确率低于90%，整个部门的季度绩效被降了一档。
数据安全事故一票否决。发生过一次客户数据泄露的部门，当年评优资格直接取消。

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

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

落地难点与应对

难点一：边界怎么划？

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

“订单"作为一个整体业务对象，指定一个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个核心业务对象。

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

从业务对象到数据模型

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

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

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

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

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

信息架构的落地工具

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

这个平台的核心功能：

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

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

信息架构带来的实际收益

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

1. 系统建设周期缩短

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

2. 数据集成成本下降

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

3. 数据质量可度量

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

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

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

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

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

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

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

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

第一步是数据API化。

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

典型的数据API示例：

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的区别：

维度	数据API	数据产品
用户	开发人员	业务人员、管理层
形态	接口	可视化界面、报表、应用
交互	编程调用	点击、筛选、下载
运营	技术文档	用户培训、需求收集、迭代优化

典型的数据产品：

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

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

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

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

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

1. 用户反馈机制

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

2. 使用量监控

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

3. 数据质量闭环

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

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

数据服务化的量化收益

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

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

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

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

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

关键动作：

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

常见坑：

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

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

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

关键动作：

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

常见坑：

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

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

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

关键动作：

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

常见坑：

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

从混乱到闭环，关键在人

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

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

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

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

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

剩下的，交给时间。

IT治理 on 文艺技术笔记

华为数据之道精读：从数据混乱走向IT治理闭环

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

数据混乱的典型症状

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

为什么需要 Data Owner

Data Owner 的职责划分

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

落地难点与应对

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

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

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

从业务对象到数据模型

信息架构的落地工具

信息架构带来的实际收益

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

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

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

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

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

数据服务化的量化收益

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

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

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

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

从混乱到闭环，关键在人