Five stages—value definition, capability design, connected data, phased delivery and value management—bring planning, delivery and operations onto one roadmap. Business and technology teams make decisions together. The approach draws on MIT CISR research on digital business transformation, DORA findings on organizational and technical collaboration, and public specifications for data interoperability and OT security. ZHICE translates these perspectives into work designs for energy businesses; the business’s actual constraints determine implementation priorities.
ZHICE / VALUE TO EXECUTIONChoose a stage to explore the work and conditions for progress.
THE QUESTION TO ANSWER
Which business outcome deserves attention first?
01 / 05
HOW THE WORK PROCEEDS
Map value streams across investment and construction, production and maintenance, energy trading and business analysis. Examine waiting, rework, information gaps and decision delays to establish an operating baseline.
WORK PRODUCTS
Value-stream assessment, priority problem register and digital benefit hypotheses.
CONDITIONS FOR PROGRESS
Business owners confirm the problem and baseline; finance confirms how benefits will be measured.
Across every stageBusiness valueAccountabilityData and evidenceRisk boundaries
Operating evidence informs judgement. The approach evolves with conditions.
THE DECISION CONTEXT
Understand the relationships. Then choose the tools.
Select a factor to see how it connects to the operating decision and shapes our analysis.
Business capabilityZHICE / DECISION LINKS
01 / THE CONNECTION
Defines the objective
Follow information, decisions and feedback to locate the changes the business actually needs.
02 / THE CONNECTION
Creates a common language
Specify sources, definitions, conditions of use and ownership so data can support work.
03 / THE CONNECTION
Connects capabilities
Balance shared capabilities, site differences and the conditions for evolving legacy systems.
04 / THE CONNECTION
Tests sustained value
Include adoption, benefit definitions and maintenance ownership in each investment decision.
Read the full analysis
Digital planning for an energy business must answer two sets of questions: can the group understand its assets and cash flows, and can operating sites maintain safe, continuous production? Business definitions, organizational responsibilities and system boundaries sit between the two. ZHICE selects an important value stream and traces how information is created, decisions are made and results feed back. We then distinguish management, data and technology barriers. This creates an evidence-based order of investment rather than a project list assembled from departmental software requests.
Digital capabilities can sustain value only when they become part of stable working practices. ZHICE connects target processes through a business capability map, specifies information sources and conditions of use through data products, and uses phased architecture to address legacy systems. Business owners participate in prioritization and acceptance; technology teams are accountable for operability and maintainability; finance helps agree benefit definitions. Planning, delivery and operations use the same questions and evidence, allowing each stage to decide whether to continue, adjust scope or stop low-value investment.
PRINCIPLES IN PRACTICE
How judgements are formed.
A method makes the relationships between evidence, choices and accountability open to discussion and testing.
01
The same business problem can have several solutions. A long settlement cycle may reflect a missing interface, inconsistent contract definitions or unclear confirmation responsibilities. If the problem is immediately attributed to outdated systems, another platform may not remove waiting or rework. ZHICE breaks the target outcome into specific roles and activities, testing causes against existing processes, information and decision rights. A technology proposal must identify the step it changes and explain why process adjustment, common standards or improvement to existing systems would be insufficient.
IMPLICATIONS FOR THE ENGAGEMENT
Investment proposals should state the business baseline, non-technical alternatives, the process to be changed and the person who will confirm benefits. Requests without clear users or acceptance evidence need further business clarification. Feature counts, platform scale and demonstration quality are not substitutes for an investment case.
02
Energy groups operate across regions and asset classes. They need common identifiers, financial definitions and access management, while accommodating different market rules, equipment characteristics and site conditions. Full centralization can erase important differences; complete decentralization can entrench duplication. ZHICE discusses standardization at capability level. The group maintains common rules, configurable services accommodate business differences, and exceptions specify their rationale and valid scope. Architecture becomes an explainable business choice rather than simply a diagram of system connections.
IMPLICATIONS FOR THE ENGAGEMENT
Every shared capability needs defined users, operating accountability and change practices. Every exception needs a recorded business rationale, cost implications and review conditions. These arrangements make group standards executable while keeping necessary regional and site differences manageable.
03
There is an easily overlooked distance between project delivery and business improvement. Data may require continuing correction, people must establish new ways of working, and legacy systems may not retire immediately. ZHICE identifies product ownership, operational support and improvement budgets at the design stage, including knowledge transfer, failure recovery and value reviews in delivery scope. Evaluation considers not only availability, but whether processes changed, people adopted the capability and costs can be explained. Accountability for improvement must survive project acceptance.
IMPLICATIONS FOR THE ENGAGEMENT
Before launch, confirm who receives issues, who decides improvements and who bears operating costs. Continue to check use and business outcomes afterward. A proposal without operating arrangements needs real responsibilities and resources, rather than another formal maintenance commitment.
FROM INQUIRY TO EXECUTION
Five stages, with clear progression.
Each stage produces an outcome and establishes what the next step requires. Expand a stage for activities, evidence requirements and review criteria.
01
PHASE / Which business outcome deserves attention first?
Define value
Value definition begins with actual business activity. Select a critical value stream in investment, maintenance, trading or settlement and observe how work crosses departments. Identify waits, rework and information gaps that affect outcomes, and determine whether they arise from process, data or technology conditions. This provides a common factual basis for architecture and investment choices.
How the work proceeds
Map value streams across investment and construction, production and maintenance, energy trading and business analysis. Examine waiting, rework, information gaps and decision delays to establish an operating baseline.
01
Select the value stream with the business owner. Follow a complete transaction, documenting roles, decision points, inputs and outputs, and retain original records and timelines for verification.
02
Classify issues by their effect on outcomes, conditions of occurrence and responsibility boundaries. Check policy definitions, role permissions and information handovers before assuming a new system is needed.
03
Agree the baseline and benefit hypotheses with finance and user departments. Specify data sources, observation periods and external influences, identifying important judgments that still need evidence.
Stage review
Business owners confirm the problem and baseline; finance confirms how benefits will be measured.
01The business owner has confirmed the central problem. Facts and assumptions are marked separately, and key baselines are traceable to records.
02Benefit hypotheses have measurement methods and accountable reviewers. Effects that cannot yet be quantified have an explicit validation path.
02
PHASE / What should be standardized, and where should differences remain?
Design capabilities
Capability design translates business objectives into arrangements that the organization and systems can follow together. It specifies what the group should standardize, what business units should retain and how legacy systems should evolve. Alternatives must expose their costs and constraints so that leadership can assess trade-offs, rather than seeing only an apparently complete but impractical target blueprint.
How the work proceeds
Map target processes to business capabilities, organizational responsibilities and application services. Compare options to retain, integrate, replace or build, clarifying the boundaries between the group and operating sites.
01
Map the target value stream to business capabilities and roles. Distinguish shared capabilities from regional and asset-specific differences, checking that common rules have an accountable maintainer.
02
Assess whether to retain, integrate, replace or retire each existing application. Compare migration, contractual dependencies, business interruption and long-term maintenance effects, documenting the rationale.
03
Design transition architecture and delivery dependencies. Specify which capabilities can be used independently at each stage, which legacy systems must remain and which temporary arrangements depart from the target.
Stage review
Every capability has an accountable owner and a use case, with explicit reasons for architecture choices.
01Each capability has a clear use case and accountable owner. Business teams have confirmed the boundaries between standardization and variation.
02The migration sequence is workable, critical dependencies and exit conditions are explicit, and temporary arrangements do not become indefinite exceptions.
03
PHASE / Can the data behind decisions be trusted and traced?
Connect data
Connected data organizes governance by working backward from consumer needs. For critical objects such as equipment, projects and contracts, it aligns not only names and identifiers but definitions, timing, provenance and applicability. ZHICE records these conditions in data product specifications, allowing users to judge which decisions the data supports and who should resolve issues at source.
How the work proceeds
Select critical objects such as equipment, projects, customers and contracts. Align identifiers and business definitions, then work back from specific uses to define quality, timeliness, access and service interfaces.
01
Define granularity, refresh frequency and acceptable delay for specific user roles. Check each critical field’s business meaning, source system, confirming role and amendment history.
02
Establish identifier mappings, quality checks and issue assignment rules. Distinguish errors that can be repaired at source from uncertainty that cannot yet be removed, and explain the limitations to users.
03
Have data providers and consumers trial the product together. Check that permissions, interfaces and version changes are communicated correctly, and bring issues from actual use into the governance backlog.
Stage review
Source owners and consumers agree their responsibilities and conditions of use, and critical data flows can be traced.
01Critical business concepts have no unexplained definitional conflicts. Users can identify missing data and conditions in which it is not applicable.
02Responsibilities for provision, quality repair and service operation are actionable, and significant changes can reach affected consumers.
04
PHASE / How can change proceed without compromising business continuity?
Deliver in stages
Phased delivery addresses the distance between design and the field. Energy businesses need to test new ways of working while maintaining production and business continuity. ZHICE sequences delivery around end-to-end outcomes, with separate validation, change review and recovery arrangements for production-related connections. Pilot findings support bounded implementation decisions; they do not replace assessment of the full rollout.
How the work proceeds
Sequence delivery around business outcomes and first test a minimum end-to-end process. For production-side connections, conduct isolated testing, change reviews, rollback design and joint exercises.
01
Select a clearly bounded business flow for the first delivery. List the process, people, data and system conditions that must coexist; completing one feature does not establish an end-to-end capability.
02
Design joint acceptance around normal, exceptional and recovery scenarios. Check whether work can be completed, data reconciled and users can operate independently, as well as how work continues after failure.
03
Arrange appropriate isolated validation and change reviews for production interfaces. Define release windows, rollback triggers and site responsibilities, using records to support a launch or deferral decision.
Stage review
Business acceptance, technical operations and security boundaries meet the conditions agreed in advance.
01Business outcomes have been verified within the initial scope. Exception and recovery arrangements are executable, with explicit decisions on unresolved issues.
02Rollout decisions draw on evidence within its applicable scope. Differences in new regions or asset classes are included in additional validation.
05
PHASE / Does value continue to materialize after launch?
Manage value
Value management brings post-launch use, quality and costs back into business decisions. ZHICE distinguishes system operation, process change and realized benefits, explaining whether deviations reflect insufficient adoption, data issues, business change or invalid original assumptions. Reviews should rebalance investment, enabling necessary improvement and an orderly end to low-value spending.
How the work proceeds
Business, technology and finance jointly track use, quality, cost and operating changes. Distinguish system availability, process improvement and realized financial benefits, and regularly rebalance the product portfolio.
01
Have the product owner consolidate use, issue, operating and cost records, interpreting changes through specific activities. Visits and feature usage are not automatically business benefits.
02
Bring business, technology and finance together to review benefit hypotheses. Examine the effects of external conditions, staffing and process changes, distinguishing confirmed improvements from those needing observation.
03
Update the product plan using adoption evidence and future needs. Recommend narrowing, combining or retiring low-value functions, retaining data migration and business continuity arrangements.
Stage review
Benefits have accountable owners, full costs are recorded, and low-value investment can be stopped promptly.
01Business and finance can review value judgments. Operating costs and additional manual work are included on the same basis.
02Further investment reflects actual use and business needs. Product accountability continues, and retirement does not damage critical operations.
ANALYTICAL FRAMEWORK
Exhibit 1 | Connect cross-functional work with reusable capabilities
Business integration and shared capabilities should reinforce one another. Quadrants guide the next discussion; they are not company ratings.
Swipe to explore the complete figure
01
Temporary integrationCoordination has expanded but relies on bespoke interfaces and manual intervention. Establish common meanings, stable services and enduring ownership so every new request does not require another connection effort.
02
Sustainable coordinationShared capabilities are reusable and business flows work end to end. Focus on service quality, negotiated change and value review, while checking suitability for new uses.
03
Fragmented developmentApplications develop within departments, with people bridging cross-system tasks. Start with a critical value stream and a shared problem, then decide which capabilities and data to standardize.
04
Local standardizationFoundational services share common elements but are not yet embedded in complete business flows. Clarify users and outcome ownership, then test whether reuse improves coordination.
A ZHICE methodological illustration. Reuse increases from left to right; coordination deepens from bottom to top. There is no quantitative scale, and the framework does not establish returns or rankings.
ANALYTICAL FRAMEWORK
Exhibit 2 | Trace the conditions behind a digital business capability
Every layer needs ownership and evidence. Higher-level requirements shape lower-level designs, while lower-level constraints must inform business choices.
Swipe to explore the complete figure
01
Decisions and outcome ownershipSpecify who makes which decision and when, the business outcome expected to change, and who will confirm whether improvement occurred.
02
Processes and application servicesDefine tasks, handovers, approvals and exceptions. Organize shared capabilities into services, clarifying responsibilities between the group and business units.
03
Data products and business meaningConnect equipment, contracts and projects. State definitions, provenance, quality, timeliness, permissions and versions so information can be interpreted and used correctly.
04
Technology and production boundariesConfirm interfaces, separation, reliability, maintenance and recovery conditions. Set change requirements according to business consequences to sustain the layers above.
An original ZHICE model for examining relationships among business, organization, data and technology. The layers are not software procurement categories or a mandatory system architecture for every business.
EVIDENCE & ACCEPTANCE
Make deliverables useful to decisions.
Go beyond document names to define purpose, evidence and verification. Agree the work scope against actual conditions at project initiation.
DECISION TOOL
Digital capability development: from stage outputs to leadership decisions
Swipe to explore the complete table
Stage and scope
Core outputs
Evidence for validation
Leadership decision
Define value: Follow an important business value stream to establish the main problems affecting outcomes and the conditions in which they arise.
Connect problems, responsibilities, baselines and benefit hypotheses, producing initial diagnostic and investment recommendations.
Provide business documents, process records and role confirmations, identifying the facts behind key judgments and remaining uncertainties.
Confirm the priority business problem and whether to fund further architecture design and data verification.
Design capabilities: Define shared group capabilities and business differences, comparing paths to retain, integrate and evolve legacy systems.
Produce the target capability map, option comparisons and transition architecture, with stage dependencies, responsibilities and exit conditions.
Provide application assessments, business differences and decision records explaining constraints, costs and continuity effects.
Select the delivery path and stage scope, assigning shared capability ownership and necessary exceptions.
Connect data: Start with specific uses to define the meaning, provenance, quality and applicability of critical objects.
Produce data product specifications and accountability arrangements, connecting definitions, interfaces, permissions and issue handling.
Provide end-to-end lineage samples, quality checks and trial feedback demonstrating that data issues can be detected and handled.
Determine whether data supports the target use and choose further governance, restricted use or business validation.
Deliver in stages: Organize the first implementation around complete business outcomes, preserving production and business continuity.
Deliver usable business capabilities, joint acceptance materials and plans for migration, recovery, training and handover.
Provide normal and exceptional task records, reconciliation results and recovery tests, explaining how unresolved issues will be handled.
Decide whether to launch, defer or narrow scope, and specify regional and asset differences requiring validation before rollout.
Manage value: Continue checking actual use, business outcomes and full costs against the original investment assumptions.
Produce value reviews and recommendations for product improvement or retirement, with a reviewable basis for the next allocation of resources.
Provide use and issue records, business outcomes and cost details, separating confirmed improvements, untested items and external effects.
Decide whether to invest further, adjust ownership or scope, or consolidate and retire low-value capabilities with continuity arrangements.
Deliverables are tailored to the problem and decision. These outputs describe ZHICE’s working approach, not results already achieved by a client, and do not replace the company’s own investment or safety approvals.
OUR PRACTICE
Explore the critical questions.
Each practice examines diagnosis, solution design, implementation and delivery requirements in detail.
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.
Google 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.
W3CData 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.
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.