Choose valuable uses
Start with questions about asset health, generation forecasts, trading imbalances and business analysis. Record the user, decision frequency, required granularity and acceptable delay for each use.
PRACTICE / DIGITAL TRANSFORMATION
Data governance and data products.
Turn scattered records into services that business teams can trust, understand and reuse.
Methodology: The ZHICE Digital Capability MethodTHE REAL CHALLENGE
Define the problem first.
Data governance can become confined to catalogs, standards and quality scores. The more useful question is whether data improves maintenance planning, trading judgment or business analysis. Equipment condition records collected at different times or using different defect definitions do not become directly comparable simply because they enter the same platform. ZHICE starts with specific decisions and organizes critical data into products with an owner, clear instructions for consumers and quality commitments. The emphasis moves from how many records have been cleaned to which business activity can use the data reliably, while retaining the basis for data creation, amendment and authorized use.
BEYOND THE SYMPTOMSLook beyond symptoms.
Look beyond symptoms.
Understand the business logic.
A data product begins with a specific use, not the most comprehensive possible catalog. Asset managers need equipment condition data to support maintenance priorities; traders need forecasts and settlement definitions to align; finance needs returns analysis that is traceable to business facts. ZHICE works backward from decisions to define granularity, timeliness and quality, matching governance effort to business needs. Not all data requires the same quality. Important limitations must instead be identified, explained and appropriately addressed.
Accountability determines whether a data product remains trustworthy. Source roles own original records, business domains own definitions and applicability, technology teams own stable delivery, and consumers report actual issues. ZHICE incorporates these responsibilities into service rules, with consultation on changes to definitions, interfaces and versions. Quality issues should be traced to their source rather than indefinitely repaired by user departments at the reporting stage. Problems that cannot yet be resolved should be explicit to consumers, avoiding apparently complete data that conceals uncertainty.
A TOOL FOR THE WORKING SESSION
Turn diagnosis into verifiable questions.
Data product diagnostic: test the conditions for reliable use
Swipe to explore the complete table
| Area of review | Barrier to use | Evidence to check | Governance arrangement |
|---|---|---|---|
| Purpose and conditions of use | Providers deliver system fields while users need different granularity, time windows or business interpretations. | Check specific decisions, user roles, observation frequency and current manual processing. | Agree purpose, applicability and quality conditions before determining processing and service interfaces. |
| Business meaning and identifiers | Equipment, projects or contracts have several identifiers, and the same metric means different things to different departments. | Compare source documents, master data, calculation rules and cross-system mappings. | Assign ownership of critical objects and definitions, maintaining mappings, versions and change notifications. |
| Quality and issue closure | Reports require continuing manual repair, source errors recur and issue handling lacks verification. | Examine exception samples, correction records, assignment workflows and consumer review findings. | Embed quality checks in business processes, assigning source repair and consumer confirmation responsibilities. |
| Access and continuing service | Data can be found, but it is unclear who may use it, when it is refreshed or how changes will be communicated. | Check catalog descriptions, access approvals, service records, versions and exception notifications. | Establish service accountability, use-specific authorization and feedback channels, retaining traceable updates and changes. |
Diagnosis is specific to the use case. Catalogs, access volumes and quality scores are useful clues but do not independently establish realized business value.
Four checks before the engagement begins
01Which specific decision does the data product serve? If it were withdrawn, whose work would be affected and how?
02Are critical definitions, sources and amendment histories traceable, and do users understand the limits of missing or estimated data?
03When a quality issue recurs, can the owner repair it at source, and who confirms that the repair works for the business?
04When purpose, interfaces or versions change, who notifies consumers, and must existing permissions and acceptance conditions be reviewed?
HOW WE WORK
From diagnosis to implementation.
Three connected levels form the working approach. Select a stage to explore the detail.
Check business meaning and provenance
Define critical concepts such as installed capacity, availability, faults and outages. Trace them to source systems and confirming roles, identifying missing values, estimates and manual amendments.
Assess the cost of governance
Distinguish issues that can be corrected at source, those requiring cross-system mapping and uncertainty that cannot yet be removed. Do not substitute endless cleansing for business decisions.
Specify data products
Document their business purpose, field meanings, lineage, refresh frequency, quality rules, access permissions and feedback channels. Consumers should know when data is fit for use and when to suspend judgment.
Assign responsibility at each level
Business owners confirm definitions and permitted uses, data owners resolve quality issues, and technology teams maintain delivery. The group provides common standards while domain teams remain accountable for content.
Design catalogs for discovery and reuse
Draw on public metadata specifications to describe datasets, versions and service interfaces. Before selecting a cross-domain integration approach, clarify purposes, permissions and exit arrangements.
Trial one data product against a real business problem. Record rework and decision errors caused by data defects, and use them to calibrate the business meaning of quality rules.
Embed quality checks in the production process, with assignment, repair, verification and closure of exceptions. Notify affected consumers of significant changes to definitions or interfaces and retain version history.
Review value through use frequency, repeated consumption, issue resolution and business outcomes. Decide whether to expand, redesign or discontinue support; catalog size is not the final measure of success.
TANGIBLE OUTPUTS
Deliverables designed for
real work.
Agree depth, data conditions and acceptance criteria at initiation. The engagement scope follows the tasks confirmed by both parties.
Critical data product catalog and specifications
Business definitions, lineage and quality rules
Data accountability and service operating practices
Trial acceptance and value review templates
ILLUSTRATIVE SCENARIO
An equipment health data product
Illustrative scenarioSuppose a business wants consistent equipment health analysis, but sites use different defect records and equipment identifiers. This is a methodological illustration and contains no actual client data.
- 01
Maintenance, operations and asset management jointly define the information and business definitions needed to assess equipment health.
- 02
Map relationships among equipment identifiers, operating conditions, defects and maintenance records, marking missing or uncertain information.
- 03
Release a data product with quality notes and access permissions for selected roles to test in actual analysis.
- 04
Adjust the rules in light of misclassification causes and user feedback, then assess whether to extend to other equipment classes.
BOARDROOM QUESTIONS
Focus the discussion on these choices.
01Whose specific decision does this data product support?
02Who can correct a quality issue at its source?
03Where can the data be reused, and which uses require a fresh assessment?
RESEARCH FOUNDATIONS
Research brought into
consulting practice.
We translate management research and technological advances into working methods for energy businesses. The frameworks below are ZHICE's synthesis of the research and industry questions.
MIT CISR · Peter Weill / Stephanie WoernerFuture Ready? Pick Your Pathway for Digital Business Transformation · 2017-09-21
Application in the ZHICE approachUse operating efficiency and customer experience as two lenses on transformation pathways, moving the discussion from system inventories to business capabilities and organizational change.
Scope and limitationsUse the analytical perspective of the published research; do not treat its cross-industry profitability differences as expected returns for energy businesses or ZHICE projects.
Read the original researchGoogle Cloud · DORAState of AI-assisted Software Development 2025 · 2025
Application in the ZHICE approachAssess technical tools within their organizational, process and delivery context, emphasizing continuous feedback and complete operating accountability.
Scope and limitationsThe research primarily concerns software delivery. Release and change requirements in energy production need a separate assessment and cannot be inferred directly.
Read the original researchW3CData Catalog Vocabulary (DCAT) — Version 3 · 2024-08-22
Application in the ZHICE approachDraw on ways to describe datasets, data services, versions and catalog interoperability to improve data discovery and conditions for reuse.
Scope and limitationsDCAT is a metadata interoperability specification. It does not replace data quality management, ownership decisions or internal authorization policies.
Read the original researchNISTGuide to Operational Technology (OT) Security · SP 800-82 Rev.3 · 2023-09-28
Application in the ZHICE approachConsider performance, reliability and security together in IT/OT collaboration, defining boundaries for interfaces, changes and recovery.
Scope and limitationsThis reference uses the final Rev. 3. The official site also identifies an initial public draft of Rev. 4; a draft is not treated as a final requirement. Projects in China must consider applicable local requirements.
Read the original researchOUR PRACTICE
Explore the critical questions.
Each practice examines diagnosis, solution design, implementation and delivery requirements in detail.
01 / DIGITAL TRANSFORMATION
Digital strategy and enterprise architecture
Organize technology investment around business capabilities, with clear boundaries for group-wide coordination and local differences.
Diagnosis · Design · ImplementationExplore this practice02 / DIGITAL TRANSFORMATION
Data governance and data products
Turn scattered records into services that business teams can trust, understand and reuse.
Diagnosis · Design · ImplementationExplore this practice03 / DIGITAL TRANSFORMATION
Digital product operations and IT/OT collaboration
Turn projects into enduring product capabilities, improving delivery within production safety boundaries.
Diagnosis · Design · ImplementationExplore this practiceSTART WITH A DECISION
Start with a decision.
Define the work around it.
Discuss the choices, constraints and evidence needed, then agree the engagement scope and work programme together.