【数据之道解惑001】数据体系为什么建不起来——Ownership应始终作为数据治理的目标,坚持长期推进 经常有行业朋友和我交流聊得最多的一个困惑就是华为的数据治理我们照着做了平台建了、模型梳了、指标体系也抄了可业务主管就是不买账不认可。久而久之业内就有了一个声音华为的数据管理方法你学不会。作为《华为数据之道》的作者也是华为数据管理理论、流程方法的创始成员以及主要的落地推行者我亲历了华为十几年来从混乱的数据现状一步步走到数据标准化、服务化的全过程。先后负责流程IT、终端、财经、华为云、数字能源等多个核心领域的数据管理和变革项目数据架构。长期在基层业务领域培养金种子和数据团队开枝散叶构建起数据管理的组织框架培育人才基础逐步改善业务认知十几年的“日拱一卒”持续推进才换来业务领域从“你是数据管理者你要管好数据”逐步变成“这是我的数据感谢你们帮我”的认知转变。回头看走过的十几年路站在实操的角度我想说一句真话不是华为的方法学不会是大多数企业急功近利只学了一点“术”而回避了最漫长磨人的“道”——数据Ownership构建的长期性和复杂性。而这正是数据治理真正的根也是所有企业想要做好数据管理必须迈过去的坎。01 很多企业做反了重工具平台建设忽略了支撑工具平台运作的组织设计当下大多数企业做数据治理几乎都是偏技术重形式短期目标。比如立项建数据中台、搭数据底座、梳理元数据、统一指标口径。这些工作交付成果清晰、验收简单追求“短平快”容易出绩效。但是没有组织的保障这些成果不过是空中阁楼水中镜月热点一过就成了一堆废弃的资产无法持续对公司产生价值。从我这么多年的实践来看下来绝大多数企业的治理困境根本不出在工具和数据应用项目上。企业的问题大抵相似系统建好了但数据还是乱的平台建好了业务还是喜欢用excel标准文档发布了很多但从来没人去看没人执行。在2008年我们最初从IBM学习引入数据管理体系时敏锐地意识到数据管理脱胎于IT但数据不是IT数据是根据业务流程的需求由业务人员产生的反应的是业务执行的结果其管理责任应该回归到业务部门由业务主管承担数据管理责任才能从根本上解决无人对数据负责的问题。IT部门有时会很积极会主动承担数据管理责任也有可能是受行政指令承担管理责任但不管哪种场景其组织定位决定了其缺乏承担管理责任的能力。勉强带病运营的后果就是导致企业长期无法建立起可以运作的机制在数字化时代延误时机。02 Ownership的建立不是靠一纸任命而是需要长期的松土辅导人力物力的倾斜支持需要倾注集团领导大量的心血是一个长期的变革过程很多企业觉得Ownership建设很简单发个文件、任命几个数据Owner、挂个头衔就算落地了。缺乏对背后机理的理解和长远安排从一开始就埋下了失败的种子。真正的数据Ownership建设不是简单的岗位任命而是一场颠覆固有习惯、重塑部门权责、平衡局部与全局利益的长期组织变革。这件事没有捷径不可能速成应知难而上不应该回避。第一转变业务认知是缓慢的过程。对绝大多数业务管理者而言营收、利润、交付、市场份额是核心本职数据治理天然被视作“额外负担”。大家愿意为业务结果负责却不愿意为自己产生的数据负责这是企业的普遍现状。IT部门宁愿增加100个开发工程师改bug却不愿意增加10个数据架构师来优化系统数据架构这就是管理上的惯性是组织的现状。大多数的基层管理者都不愿意改变因为改变工作模式意味着未知的风险。认知的改变不是培训、宣贯就能完成的。华为早期推行数据Owner体系时同样面临大量抵触业务觉得标准约束了灵活的作业、数据治理增加了大量的工作量。业务部门长期抵制不认可数据工作。我们是通过长年的高层背书、制度固化、述职汇报考军长培训赋能问责机制以及集团给以预算支持专家下乡平台打造等软硬兼施一点点磨掉业务部门的固有思维用“阳谋”驱动组织按设定的方向转变。我们深刻地理解到“变革”要“慢”慢就是快要给以基层组织适当的宽容在漫长的时间演进中逐步融化松解思维变革推行过快往往会流于形式应付交差反而达不到预期目标。只要“方向大致正确组织充满活力”我们就能越过前方的艰难险阻去。认知的改变急不来。第二数据治理人才需要长期培养沉淀。数据Owner、数据架构师等不是简单的兼职岗位是典型的复合型岗位要懂业务流程、懂数据管理要有标准化思维、要懂业务管理口径、要懂法律合规要求还要有全局协同能力。这类人才无法在人才市场获取也无法批量速成只能在一次次实战中手把培养、项目落地中慢慢历练、沉淀。结语做了十几年数据治理我得出的一个结论数据治理的根本问题不在技术而在组织。工具平台可以购买也可以自研数据标准、数据模型可以投入专家去设计几个月到一年就能落地成型。但业务owner不认可是其责任不愿意投入业务专家资源不愿意花时间去认真思考如何更好地管理数据整个数据管理体系就会失去龙头牵引力缺乏驱动力自然就无法正常运转。读懂华为数据管理的企业明白一个道理Ownership不是一个岗位标签而是一份对企业的责任是一套可以闭环运作的机制。

相关新闻

最新新闻

BepInEx启动失败:系统性诊断与修复指南

BepInEx启动失败:系统性诊断与修复指南

1. 项目概述:当BepInEx启动失败时,我们到底在解决什么?如果你正在为Unity游戏制作Mod,或者管理一个依赖BepInEx的插件生态,那么“BepInEx启动失败”这个报错,大概率是你开发路上的一块绊脚石。它不像一个普…

2026/7/13 4:34:50
锂电池组主动平衡方案与BQ25887应用实践

锂电池组主动平衡方案与BQ25887应用实践

1. 项目背景与核心器件选型在锂电池组应用中,电池单元之间的电压不平衡是影响系统性能和寿命的关键问题。当多个电池串联时,由于制造工艺差异、温度分布不均等因素,各单体电池的充放电特性会出现偏差。这种不平衡会导致部分电池过充或过放&am…

2026/7/13 4:34:50
MCP3428与PIC18F86K22高精度数据采集系统设计

MCP3428与PIC18F86K22高精度数据采集系统设计

1. 为什么选择MCP3428与PIC18F86K22组合在工业现场和实验室环境中,数据采集系统的精度和稳定性往往直接决定最终数据的可靠性。MCP3428作为一款18位Δ-Σ ADC(模数转换器),其核心优势在于集成了可编程增益放大器(PGA)和内部基准电…

2026/7/13 4:34:50
Google VR SDK for Unity 实战指南:从Cardboard开发到现代VR技术迁移

Google VR SDK for Unity 实战指南:从Cardboard开发到现代VR技术迁移

1. 项目概述:为什么现在还要学一个“已归档”的SDK?看到“Google VR SDK for Unity”这个标题,很多朋友可能会一愣:这不是那个已经停止维护的Cardboard和Daydream的SDK吗?没错,官方仓库在2019年就归档了&am…

2026/7/13 4:34:50
脚手架架构设计_小白版

脚手架架构设计_小白版

🏗️ 脚手架架构设计——小白完全版原文:脚手架架构设计.md 来源:Day21 课程笔记 本版目标:零基础看懂架构演进、Base 模块、Redis、Minio 等概念📌 一句话先搞懂:什么是"脚手架"? 脚…

2026/7/13 4:34:50
四大Python EDA加速工具实战指南:告别重复性数据探索

四大Python EDA加速工具实战指南:告别重复性数据探索

1. 项目概述:为什么EDA总在“重复造轮子”上卡住手脚?做数据分析的人,几乎都经历过这种时刻:刚拿到一份新数据,满心期待地打开Jupyter Notebook,敲下import pandas as pd,接着是df.head()、df.i…

2026/7/13 4:29:49

月新闻