PRACTICE / DIGITAL TRANSFORMATION

数据治理与数据产品。

让数据从分散记录成为业务部门可以信任、理解和复用的服务。

所属方法论:支策数字能力重构方法
THE REAL CHALLENGE

先把问题界定清楚。

数据治理容易停留在目录、标准和质量评分上。真正需要追问的是:数据是否改善了检修安排、交易判断或经营分析?同一项设备状态,如果采集时间不同、缺陷口径不同,即使进入同一平台,也不能直接支持比较。支策以具体决策为牵引,把关键数据组织为有责任人、有消费说明、有质量承诺的数据产品。治理工作从“清理多少条数据”转向“哪项业务可以稳定使用”,同时保留数据生成、修订和授权使用的完整依据。

BEYOND THE SYMPTOMS

从现象进入
经营逻辑。

数据产品的起点是一次具体的使用,而不是一份尽可能齐全的目录。资产管理人员关注设备状态能否支持检修排序,交易人员关注预测与结算口径能否对应,财务人员关注收益分析能否追溯到业务事实。支策从使用者的决策要求反向定义数据粒度、时效和质量,让治理的工作量与业务需要相匹配。不是所有数据都要达到相同质量,而是重要限制必须被识别、解释并获得合理处置。

责任设计决定数据产品能否持续可信。产生数据的岗位负责原始记录,业务领域负责定义和适用范围,技术团队负责稳定交付,使用方负责反馈实际问题。支策将这些分工写入服务规则,对口径、接口和版本变化设置协商机制。质量问题需要追到源头,而不是长期由使用部门在报表末端修补;暂时无法修复的问题则应向消费方显式说明,避免以看似完整的数据掩盖不确定性。

A TOOL FOR THE WORKING SESSION

把诊断落到可核查的事项。

DECISION TOOL

数据产品诊断:检查数据是否具备稳定使用条件

左右滑动,查看完整表格

诊断环节常见使用障碍需要核对的证据治理安排
用途与消费条件供数方按系统字段交付,使用方却需要不同粒度、时间窗口或业务解释。核对具体决策、使用岗位、观察频率及现有人工加工步骤。先约定用途、适用范围和质量条件,再确定数据加工与服务接口。
业务语义与标识同一设备、项目或合同存在多个标识,相同指标在不同部门含义不一致。对照源头单据、主数据、计算规则和跨系统映射关系。明确关键对象及口径责任,维护映射、版本与变更通知机制。
质量与问题关闭报表末端持续人工修补,源头错误反复出现,问题处理没有验证环节。查看异常样本、修正记录、分派过程及使用方复核结果。将质量检查放入业务流程,明确源头修复和消费方确认责任。
权限与持续服务数据可以被找到,却无法判断可供谁使用、何时更新、变化后如何获知。核对目录说明、访问授权、服务记录、版本和异常通知。建立服务责任、用途授权和反馈渠道,保留更新与变更的可追溯记录。
诊断围绕具体使用场景开展。数据目录、访问量或质量得分只能作为线索,不能单独证明业务价值已经实现。

项目开始前的四个确认

01这项数据产品服务哪一个明确决策;如果停用,哪个岗位的工作会受到什么影响?

02关键字段的口径、来源和修订历史是否可追溯,使用者是否知道缺失或估计数据的限制?

03同一质量问题再次发生时,责任人能否在源头修复,谁来确认修复对业务已经有效?

04当用途、接口或版本发生变化时,谁负责通知消费方,原有授权和验收条件是否需要重审?

HOW WE WORK

从诊断走向实施。

三个层次共同构成完整工作路径。点击查看具体做法。

01

选定高价值消费场景

从资产健康、发电预测、交易偏差和经营分析等问题出发,逐项记录使用者、决策频率、所需粒度和可接受的时间延迟。

02

核对业务语义与来源

对装机容量、可用率、故障和停机等关键概念明确口径,追溯到采集系统与确认岗位,标注缺失、估计和人工修订情况。

03

评估治理成本

区分可以在源头纠正的问题、需要跨系统映射的问题和暂时无法消除的不确定性,防止以无限清洗替代业务取舍。

TANGIBLE OUTPUTS

交付物应当进入
实际工作。

项目启动时共同确认深度、数据条件与验收标准。交付范围以双方确认的任务为准。

01

关键数据产品目录与规格书

02

业务语义、血缘和质量规则

03

数据责任与服务运营机制

04

试运行验收及价值复盘模板

ILLUSTRATIVE SCENARIO

设备健康数据产品

示意情境

假设企业希望统一设备健康分析,但各场站的缺陷记录与设备编码存在差异。以下为方法示意,不包含真实客户数据。

  1. 01

    由检修、运行和资产管理人员共同确定健康判断所需信息及业务口径。

  2. 02

    梳理设备标识、运行工况、缺陷和检修记录之间的关系,标记缺失与不确定信息。

  3. 03

    发布带有质量说明和使用权限的数据产品,由选定岗位在实际分析中试用。

  4. 04

    根据误判原因和使用反馈调整规则,再评估是否扩展到其他设备类别。

BOARDROOM QUESTIONS

把讨论落在这些选择上。

01这项数据产品究竟服务谁的哪一个决策?

02质量问题出现时,谁有能力在源头修复?

03数据可以复用到哪里,哪些用途必须重新评估?

RESEARCH FOUNDATIONS

研究如何进入
咨询实践。

以管理研究与技术进展为依据,将其转化为能源企业的工作方法。以下框架为支策结合行业问题的归纳。

MIT CISR · Peter Weill / Stephanie WoernerFuture Ready? Pick Your Pathway for Digital Business Transformation · 2017-09-21

应用于支策方法以经营效率与客户体验两个维度审视转型路径,推动从系统清单转向业务能力和组织改变。

适用边界使用公开研究的分析视角;不引用其跨行业利润差异作为能源企业或支策项目的预期收益。

阅读原始研究
Google Cloud · DORAState of AI-assisted Software Development 2025 · 2025

应用于支策方法把技术工具放回组织、流程与交付系统中评估,强调持续反馈和完整运营责任。

适用边界研究对象主要为软件交付;能源生产侧的发布与变更要求需另行评估,不直接类推。

阅读原始研究
W3CData Catalog Vocabulary (DCAT) — Version 3 · 2024-08-22

应用于支策方法借鉴数据集、数据服务、版本与目录互操作的表达方式,改善数据可发现性和复用条件。

适用边界DCAT 是元数据互操作规范,不能替代数据质量管理、权属判断或企业内部授权制度。

阅读原始研究
NISTGuide to Operational Technology (OT) Security · SP 800-82 Rev.3 · 2023-09-28

应用于支策方法在 IT / OT 协同中同时考虑性能、可靠性和安全要求,形成接口、变更与恢复边界。

适用边界引用正式 Rev.3。官网已发布 Rev.4 初始公开草案的信息;草案不作为正式要求,中国项目应结合当地适用要求。

阅读原始研究
OUR PRACTICE

从关键议题深入。

每个专题都展开诊断方法、方案设计、实施安排与交付要求。