Organize technology investment around business capabilities, with clear boundaries for group-wide coordination and local differences.
Methodology: The ZHICE Digital Capability MethodWhen separate systems support production, trading and finance, the problems often lie between them: an asset has several identifiers, trading outcomes cannot be connected to asset returns, and operating analysis depends on repeated reconciliation. Buying a new platform may simply move old management gaps into a new interface. ZHICE first determines which business capabilities need to change, then how systems should work together. Architecture must describe the future state as well as how legacy systems will be retired, who will bear transition costs and how critical production activities will remain continuous. A mature plan makes trade-offs explicit and migration executable.
Enterprise architecture translates business trade-offs into rules that can be applied consistently. For an energy group, the starting point is its operating model: which decisions require group coordination and which belong to regions or sites; which information must be shared and which activities must remain independent. ZHICE maps the relationships among capabilities, processes and applications, then tests those boundaries through actual business work. A target architecture does not begin with a platform into which the business is fitted. It explains how shared capabilities should support operations and how differentiated requirements can be accommodated coherently.
An architecture proposal must also explain the route from the present to the target. ZHICE includes migration, contractual dependencies, staff capabilities and production constraints in option comparisons, stating the reasons to retain, integrate, replace or retire each application. Necessary temporary interfaces and manual arrangements may remain during transition, but their scope and exit conditions must be recorded. Leadership can then see not only the future blueprint but the capability delivered at each step, the costs and risks to be borne, and when the original choices should be revisited.
Swipe to explore the complete table
| Object of review | Gap to identify | Evidence to check | Design response |
|---|---|---|---|
| Group and regional responsibilities | The same capability is expected to be standardized centrally while regions rebuild it, with decision rights disconnected from cost accountability. | Compare formal responsibilities, actual approvals and usage records to establish who sets rules and who operates the service. | Define ownership of shared services and give business differences an explainable implementation path that can be reviewed. |
| Critical cross-functional business flows | The front end appears integrated, but back-office work still depends on manual reconciliation and exceptions have no clear owner. | Trace inputs, handovers, approvals and results for a real transaction, recording where waits and rework occur. | Resolve process and accountability gaps before assigning work to interfaces, applications or data governance. |
| Legacy systems and technical dependencies | Similar functionality proves hard to replace because migration, contract restrictions and site interfaces have not been understood. | Review application capabilities, contract periods, data exports, maintenance records and production connection conditions. | Compare retention, integration and replacement, with an executable migration sequence and exit criteria. |
| New requests and architecture governance | Projects each pass review but cumulatively create duplicate capabilities and indefinite temporary arrangements. | Examine requests, architecture decisions, exception approvals and subsequent reviews to check whether the original rationale still holds. | Review demand and exceptions at capability level, connecting change decisions back to long-term architecture objectives. |
01Across a complete business process, which decisions belong to the group, region and site, and do system permissions match them?
02Do differences between similar applications reflect market and asset conditions or historical delivery choices? How should each type of difference be treated?
03After the first migration, which legacy systems can actually retire, which must remain and who bears the associated costs?
04If a temporary interface or exception persists, what triggers a review and who decides whether to change the target architecture?
Three connected levels form the working approach. Select a stage to explore the detail.
Start with asset operations, trading, customer service and capital management. Identify capability gaps and their effect on business outcomes, rather than mechanically reproducing the current organization chart or software menus.
Follow complete processes such as a maintenance intervention or a trade settlement. Record handovers, duplicate data entry, approval waits and system dependencies to locate the real constraints on performance.
Review system capabilities, contract terms, maintenance costs, data portability and production interface conditions. Distinguish technical debt, process debt and unclear organizational accountability.
Establish group standards for shared capabilities such as equipment master data, identity and access, and integration services. Preserve configuration options for activities that differ, such as regional trading and site maintenance.
Recommend retaining, integrating, replacing or retiring each application. Explain the options through business interruption risk, long-term costs, vendor dependencies and future adaptability, giving leadership a basis for choice.
Assign owners and review practices for business, data and technology architecture. Give temporary exceptions to the target architecture a defined scope, accountable owner and end date.
Connect one end-to-end business flow first. Verify cross-system identifiers, processes and responsibilities before extending to other asset classes or regions. Avoid obscuring dependencies behind many parallel projects.
Check separately whether the business process can be completed, data reconciles, people can use the system independently and legacy systems can retire safely. Retain evidence from continuity and recovery exercises.
Establish ongoing architecture reviews that assess new requirements against the capability map. Use evidence of reduced duplication, service adoption and process quality to shape the next phase of investment.
Agree depth, data conditions and acceptance criteria at initiation. The engagement scope follows the tasks confirmed by both parties.
Consider a renewable energy group seeking to connect asset operations, market trading and project returns. This scenario illustrates the working method; it is not a claim about a ZHICE project or actual client results.
Select one region and asset class, then trace the process from generation confirmation through trade settlement to project return analysis.
Align critical identifiers for assets, contracts and settlement periods, specifying which data operations, trading and finance each confirm.
Prioritize an operating analysis flow that can be reconciled, while assessing existing interfaces and transition costs.
Use reconciliation differences, analysis timeliness and records of business use for acceptance, then decide the scope of further adoption.
01Which capabilities are common across the group, and who will operate them after standardization?
02Which legacy systems can remain, and which now constrain business change?
03Which business flow should the first delivery change, and what would demonstrate that change?
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.
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 researchApplication 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 researchApplication 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 researchApplication 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 researchEach practice examines diagnosis, solution design, implementation and delivery requirements in detail.
Organize technology investment around business capabilities, with clear boundaries for group-wide coordination and local differences.
Diagnosis · Design · ImplementationExplore this practiceTurn scattered records into services that business teams can trust, understand and reuse.
Diagnosis · Design · ImplementationExplore this practiceTurn projects into enduring product capabilities, improving delivery within production safety boundaries.
Diagnosis · Design · ImplementationExplore this practiceDiscuss the choices, constraints and evidence needed, then agree the engagement scope and work programme together.