An organisation can change its structure and still leave people unable to act.
- Part 1: The RenDanHeYi Approach
- Part 2: The Haier Business Model
- Part 3: How Haier Delivers Scenarios: Smart Solutions
- Part 4: The Orchestration Engine of Haier
- Part 5: Haier Culture, Purpose and Strategy
- Part 6: How Haier Harnesses AI
- Part 7: How to Make the Transition to Ecosystem Organising (this article)
- Part 8: Strategies and Tools for Ecosystem Organising
A team becomes responsible for a customer outcome, but another department controls its budget. It can choose collaborators, provided procurement approves them. It must respond faster, using information scattered across systems that tell different versions of the same story.
The reporting lines have changed. The practical conditions of work have barely moved.
Moving towards ecosystem organising means progressively transferring the capacity to deliver a customer outcome. Authority, information, resources and participant economics must develop together. Evidence should determine whether the arrangement expands.
Three propositions guide that transition. Structural autonomy achieves little unless people can obtain the information, resources and commitments needed to act. A bounded experiment must test those conditions together. Expansion requires changes to the surrounding organisation, informed by results and the dependencies revealed through delivery.
Digital transformation is foundational. Teams need to follow requirements, decisions and commitments across organisational boundaries. Leaders need to understand performance without approving every action. Neither is dependable when the records connecting the work are inaccessible or unreliable.
The previous articles examined the components of Haier’s model. This article considers the transition: where to start, what must change together and how to decide whether to go further. The proposed approach synthesises lessons from Haier and adjacent organisational research. It is not an official Haier implementation method or a sequence demonstrated by its history.
Table of Contents
Start Where the Organisation Prevents a Customer Outcome
Haier’s experience provides a reason to question the search for a finished model to install.
Its strategic history records successive periods of development, while accounts of its organisational changes describe repeated reinvention. Frynas, Mol and Mellahi (2018) examine RenDanHeYi within its particular organisational, competitive, institutional and technological context. Fischer and Liu (2012) describe an earlier stage of Haier’s efforts to bring responsibility closer to customers.
These accounts support treating Haier as an evolving response to changing conditions. They do not establish a universal sequence for other organisations.
The useful starting question is therefore concrete: where does our existing way of operating prevent people from delivering an outcome customers value?
Consider a hypothetical home energy service. A household needs an appropriate installation that performs as promised. Delivery requires property assessment, equipment, financing, installation, software and continuing support. Each contributor may meet its own targets while the household experiences delays, conflicting promises or a system that performs poorly.
Before changing the structure, investigate where those failures arise. Are decisions waiting for approval? Does a handover lose information? Can someone promise a delivery date without confirming installation capacity? A specific constraint gives the transition something to explain and improve.
Choose a scope large enough to include the relevant dependencies, but bounded enough to test. Identify the customers, services and participants involved, alongside the commitments and controls that must remain dependable.
The organisation’s ecosystem role also matters. A partner joining an established arrangement needs to assess its own capability, integration requirements and participation terms. An orchestrator must also establish how shared commitments, disputes and changes will be governed. Participating does not require every company to build the coordinating infrastructure itself.
Design the First Arrangement as a Connected Whole
Once the outcome is clear, design the conditions needed to deliver it. This is the order of decisions; the resulting changes will often need to be implemented together.
The first experiment needs an accountable team, access to users, explicit authority, resources and commitments from the other participants required for delivery. It also needs working information connections. Introducing a team first and negotiating these conditions later risks making its performance depend on favours and exceptions.
Bain’s guidance on scaling agile offers an adjacent lesson: adding teams alone does not resolve the organisational constraints surrounding them. Its emphasis on resourcing, outcomes and interdependencies is useful here, although it does not establish how ecosystem governance or participant economics should work (Bain & Company, n.d.).
Transfer Decisions With the Means to Exercise Them
For consequential decisions, establish who decides now, who will decide during the experiment and what limits apply. A team might control priorities or spending within an agreed budget. Changes affecting another participant’s commitments may require joint agreement. Responsibilities concerning shared assets, legal duties or risks beyond the experiment may remain central.
The transfer must work in practice. Authority to choose a collaborator means little if several functions can indefinitely delay the contract. Accountability for delivery becomes unreasonable if the team cannot obtain capacity or reliable information.
Test each proposed responsibility against the means available to exercise it. Agree how conflicts will be resolved and when leaders may intervene, so that difficult decisions do not reopen the question of whether autonomy applies.
Make Commitments Dependable Across Participants
An ecosystem brings an additional difficulty: the team cannot simply instruct every contributor. Participants retain their own interests, constraints and authority.
In the home energy example, a revised assessment might require different equipment. The supplier accepts the change, but the installer cannot meet the original date. The finance provider needs a revised agreement. Who can change the customer promise, and who bears the consequences?
Specify who can accept an order, reserve capacity, alter a specification and renegotiate a commitment. Participants need a way to confirm acceptance, identify conflicts and settle changes before separate promises become incompatible.
Commercial terms must support those commitments. A supplier protecting its margin and an installer protecting its schedule may each behave reasonably while the complete service fails. Examine how costs, rewards and responsibility for failures are distributed, including what happens when a change creates extra work for one participant and value for another.
Agree a route for disputes, with clear authority and limits. Establish what withdrawal means for outstanding customer commitments. These are design questions for the proposed experiment, rather than a claim that every Haier ecosystem uses one standard agreement.
Different contributions also require different measures. Revenue and cost responsibility may suit some units; service quality, capability development or contributions to shared outcomes may suit others. A separate profit target for every activity needs scrutiny where it rewards participants for shifting costs onto one another.
The experiment should test whether delivery works and whether the participating organisations have a reason to sustain it.
Build the Digital Capacity Required to Operate It
The design now makes the technology requirements specific. Participants must be able to connect the information needed to deliver their commitments and understand the consequences of change.
Chen et al. (2022) describe COSMOPlat applications across user interaction, design, procurement, manufacturing, logistics and service. They also describe software services supplied to microenterprises and arrangements for data exchange. The authors are affiliated with Haier COSMO IoT Ecosystem Technology, making this a useful account of the architecture from its developers. It does not independently establish that technology caused Haier’s organisational results.
The transition lesson proposed here is that distributed responsibility needs dependable information and access to capabilities. Three requirements deserve particular attention.
Connect the Records Required for Delivery
A common data thread links the records needed to understand and deliver an outcome. For the home energy service, it would connect the customer requirement, property assessment, proposed solution, agreement, equipment order, installation, commissioning and subsequent performance.
If the assessment changes, participants should be able to trace the effects on equipment, cost, financing and delivery. Otherwise, each may proceed using a different version of what was agreed.
This does not require one application or a single database. It requires consistent identifiers, agreed definitions, reliable connections between systems and clear responsibility for maintaining information. Participants also need permission to access the relevant records.
Connect Visibility With Action
Seeing the revised assessment reveals the installation conflict. It does not resolve it.
The information arrangements must support the responsibilities already designed: who receives a change, who confirms its consequences, who approves a revised commitment and who informs the customer. Shared visibility, coordinated action and accountability are related capabilities, but each requires attention.
Decision records, access controls and traceability help participants establish what was accepted and investigate failures. External organisations may legitimately restrict what they share; the design must identify the information required for delivery within those limits.
Make Shared Capabilities Accessible
Small teams need services such as finance, engineering, legal advice, analytics and technology. Those services need visible responsibilities, response commitments and escalation routes. A digital directory is of limited use if the capability it lists cannot be obtained when needed.
This foundation also matters for AI. Automating a decision requires clarity about the information informing it, the authority to act and the commitments affected. Unreliable records and ambiguous permissions create problems before automation enters the picture.
Prepare enough digital capacity to operate the first experiment dependably. Broader architecture can develop as experience reveals further requirements. Foundational technology deserves early investment, directed by the delivery arrangement it must enable.
Resolve Conflicts With the Existing Organisation
Even a carefully designed experiment will usually depend on functions operating through established processes. The transition becomes real where those arrangements collide.
A specialist receives competing priorities from a functional manager and an outcome team. Finance expects adherence to an annual budget while the service needs to respond to changed demand. Procurement optimises equipment price while the team needs dependable delivery across the complete installation.
These conflicts require decisions about allocation, funding and responsibility. Encouragement to collaborate cannot settle them.
Agree which work the experiment can commission, how shared specialists are allocated and how priorities are resolved. Funding should allow adaptation within explicit limits. Service arrangements should specify what the team can expect and how unresolved requests are escalated.
Technology leaders need to participate from the outset. They must protect continuing operations while establishing data access, common standards and a route for extending capabilities that prove useful. If every connection depends on a temporary workaround, later expansion inherits those constraints.
The same clarity is needed for people. Managers may lose approval authority while gaining responsibility for coaching, capability development or coordination. Team members may need to interpret costs, negotiate commitments or make decisions they previously escalated. Assessment, reward and career progression should reflect the responsibilities people are actually being asked to exercise.
Not everyone will want entrepreneurial responsibility. The organisation will still need specialist expertise and dependable operational work.
The human consequences deserve more than a reassuring paragraph about empowerment. Hamel and Zanini’s historical account reports more than 10,000 employee dismissals alongside new employment in Haier’s ecosystem. It does not establish that the people dismissed obtained those new opportunities or experienced equivalent employment conditions (Zanini, 2020).
Explain what happens if an experiment closes, a role disappears or a person needs to move. Credible support affects whether people can discuss problems openly rather than protect themselves from the transition.
Set a review point for coexistence between the experiment and established functions. A hybrid arrangement may remain appropriate, but its responsibilities should be deliberate and workable.
Test Whether Results Survive Without Exceptional Support
The first experiment must produce evidence about repeatability as well as customer results.
Imagine that the home energy service improves installation times, but only because its executive sponsor repeatedly secures scarce installers and overrides procurement delays. The customer improvement matters. The experiment has also exposed unresolved constraints in capacity allocation and contracting.
Expansion would reproduce those constraints unless the organisation changes the arrangements behind the intervention.
Record starting conditions and agree review criteria before launch. Examine customer outcomes, decision delays, delivery reliability, costs and participant economics. Include the effort spent reconciling information, negotiating exceptions and resolving disputes. Apparently attractive margins may depend on coordination work that nobody has counted.
Review whether participants can follow a commitment through the relevant systems, whether records are dependable and whether problems can be traced to their causes. Ask people whether they can exercise their responsibilities with the resources and authority provided.
Senior sponsorship may be necessary to establish the experiment. Continuing operational dependence on the sponsor is evidence to investigate. Distinguish decisions that created the new arrangement from interventions repeatedly compensating for its weaknesses.
Agree conditions for expansion, revision or closure. A useful experiment can justify stopping if it reveals unworkable economics, unacceptable service risks or dependencies the organisation cannot resolve. Preserve that learning rather than treating expansion as the only successful outcome.
Expand by Resolving the Next Constraint
Expansion should follow the dependencies revealed through delivery.
A successful service may expose the need for a shared installation capability, better access to specialists or a dependable service record. Resolving that constraint can make the next area easier to establish. Replicating team structures while leaving the dependency untouched would carry the problem further.
Decide what must become common and what should remain adaptable. Data definitions, security requirements and interfaces may require consistency. Offers, local relationships and responses to users may need variation.
There is a tension to manage. Separate applications and records can create new silos; a shared platform that dictates every local choice can become another source of central control. Technology governance should make the boundary explicit and review it as experience develops.
Funding, service commitments, performance reviews and capability planning must evolve with expansion. Otherwise, more teams will operate through exceptions while the organisation describes the transformation as complete.
The opening problem was an organisation that changed reporting lines without changing people’s capacity to act. The transition becomes credible when teams can secure information, resources and participant commitments through arrangements others can use too.
A successful experiment earns expansion when its results can be reproduced without exceptional permissions, hidden coordination work or constant executive rescue. That is the practical test of whether the organisation has changed.
The next article will examine methods and tools for diagnosing constraints, mapping dependencies, designing responsibilities and testing the emerging system.
References
Bain & Company (n.d.) Scaling Agile. Available at: https://www.bain.com/insights/books/doing-agile-right/about/scaling-agile/ (Accessed: 23 October 2026).
Chen, L., Xie, H., Yang, W. and Xiao, L. (2022) ‘Data Space Based on Mass Customization Model’, in Otto, B., ten Hompel, M. and Wrobel, S. (eds.) Designing Data Spaces. Cham: Springer, pp. 437–450. doi: 10.1007/978-3-030-93975-5_26.
Fischer, W.A. and Liu, F. (2012) Creating a customer oriented company: ZZJYT at Haier. Lausanne: IMD. Case IMD 3 2351. Available at: https://www.imd.org/research-knowledge/strategy/case-studies/creating-a-customer-oriented-company-zzjyt-at-haier/ (Accessed: 23 October 2026).
Frynas, J.G., Mol, M.J. and Mellahi, K. (2018) ‘Management innovation made in China: Haier’s RenDanHeYi’, California Management Review, 61(1), pp. 71–93. doi: 10.1177/0008125618790244.
Zanini, M. (2020) Haier: Entrepreneurship at Scale. Coauthored with Gary Hamel and excerpted from their 2018 Harvard Business Review article ‘The End of Bureaucracy’. Available at: https://www.michelezanini.com/haier-hbr/ (Accessed: 23 October 2026).
