A workshop can produce an impressive ecosystem map and still leave a simple question unanswered: who can agree a new delivery date when the original promise becomes impossible?
- 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
- Part 8: Strategies and Tools for Ecosystem Organising (this article)
The participants are named. Their connections are drawn. Yet the installer has not reserved capacity, the finance provider has not approved the revised price, and the customer team cannot explain what happens next.
For leaders moving towards ecosystem organising, the useful tools are those that expose these gaps and help resolve them. Their outputs must connect: a customer outcome leads to delivery dependencies, dependencies lead to commitments, and commitments establish what needs to be decided, shared, funded and tested.
Part 7 explained the conditions needed for the transition. This article examines how to design and investigate them. It combines established methods with practical adaptations proposed here. The combined sequence is a working approach, not an official Haier method or a validated implementation framework.
Table of Contents
Establish the Failure Before Choosing the Tool
Start with a problem precise enough to investigate.
Continue the hypothetical home energy service from Part 7. A household needs an appropriate installation that performs as promised. Suppose its providers are concerned about missed installation dates. One explanation is insufficient installer capacity. Others include late equipment changes, incomplete assessments and dates promised before anyone checks availability.
Each explanation points towards a different intervention.
Create a short record of recent cases: the promise made, what happened, relevant timestamps, additional work and the evidence available. Include cases that went smoothly. Ask the people doing the work to explain the differences, then check their accounts against records and customer experience.
The immediate output is a bounded diagnostic question. For example: what prevents a revised installation date being agreed after a property assessment changes?
That question determines the next tool. It also leaves open the possibility that a simpler process repair will suffice. A recurring internal approval delay does not, by itself, justify reorganising a company into an ecosystem.
Use a Service Blueprint to Find the Hidden Work
A service blueprint is useful when the customer sees one experience but delivery depends on work spread across functions or organisations.
Gibbons (2017) describes blueprinting as a way to connect customer touchpoints with the people, evidence and processes behind them. It makes visible work that a customer journey alone may leave unexplained.
Build the current service across a shared timeline. Separate customer actions, visible interactions, backstage work and supporting systems. Add the records and decisions needed at consequential handovers. Keep observed practice separate from the process people say should happen.
For the home energy service, trace the point where a customer receives a date. Does that follow an accepted equipment order and confirmed installer capacity? Or does the date originate in a sales conversation, leaving others to make it possible afterwards?
The distinction changes the diagnosis. What appears to be an installation failure may begin with an unsupported commercial promise.
Mark waiting, repeated information requests, rework and missing acknowledgements. Attach evidence where available and mark uncertainty where it remains. A workshop consensus is a hypothesis about how delivery works until checked against actual cases.
The blueprint should enable a choice about which handover or decision to redesign. Mapping every service variation adds little if the team cannot identify the failure it will investigate first.
Map Dependencies Before Filling the Page With Participants
A blueprint reveals the work. An ecosystem dependency map examines which contributions must align for the offering to work, particularly where participants retain independent authority.
Adner’s ecosystem framework starts with a value proposition and examines activities, actors, positions and links (Adner, 2017). Its practical value here is the shift from listing relationships to examining the structure of interdependence.
Take one specified version of the service. List the activities required to deliver it, then identify who could perform them. Distinguish an essential contribution from an optional enhancement. Show what each activity needs from others and what happens if that contribution is unavailable.
Assign roles relative to the offering. Producers deliver the core offering; partners provide critical enabling inputs; complementors extend it. Orchestrators coordinate the arrangement, while enablers or supporters provide supporting conditions. Customers receive the outcome. A company’s role can change when the offering changes.
For each critical connection, record the provider, receiver, required contribution, prerequisites, evidence of acceptance and process for changes. Label the connection: equipment, information, payment, capacity or authorisation. A generic arrow hides these differences.
In the example, knowing an installation company is not the same as having installation capacity. A line joining its name to the service team should show whether capacity has been discussed, provisionally offered or confirmed.
The output is a set of dependencies requiring action. It helps leaders decide where to negotiate, find alternatives, reduce the offering’s scope or stop. It also identifies which participants need to join the next design discussion.
Turn the Critical Decision Into an Agreement
Once a dependency is visible, examine the decisions that make it dependable.
Bain’s RAPID method distinguishes Recommend, Agree, Perform, Input and Decide. It separates advice from consent and final authority, and encourages explicit roles for important decisions (Bain & Company, 2023). This is useful where several people assume they own a decision or everyone can delay it.
Apply it to a precise decision, such as approving a revised customer offer. Record the decision holder, necessary inputs, genuine consent requirements, spending limits, people responsible for execution and escalation route. Agree when a response is required. Giving every interested function a consent role can preserve the original bottleneck under a new label.
Across organisations, there is a boundary to respect. An internal decision chart cannot give the service team authority to reserve another company’s installers or amend a finance provider’s terms.
Separate those decisions. The installer confirms capacity it is willing to commit. The finance provider accepts or rejects the amended financing. The service team decides what customer offer it can make within those accepted conditions.
If the decisions conflict, the participants need an agreed resolution route. Until then, the customer promise remains unresolved. Drawing a single senior decision maker above the network would conceal the problem.
The output is an accepted decision agreement, including limits and change rights. An orchestrator may need to establish this arrangement across participants. A partner joining an existing ecosystem should examine whether its own commitments, consent rights and escalation routes are workable.
Specify the Information Needed to Exercise Authority
The decisions now make the digital requirements concrete.
Chen et al. (2022) describe connected applications, data flows and software services within COSMOPlat. Their account, written by authors affiliated with Haier COSMO IoT Ecosystem Technology, illustrates the architecture described by its developers. It does not establish the effectiveness of the worksheet proposed below.
Create a data requirements table for the critical decision. Include the record, its authoritative source, the person responsible for maintaining it, a shared reference, version, permitted recipients and required acknowledgement.
For the changed assessment, ask how the supplier, installer and finance provider know they are considering the same revision. Identify which assessment replaces the earlier one and whether everyone has received it. Specify how an accepted change becomes a revised order or commitment.
Keep receipt and acceptance separate. A system notification can establish that a record was delivered. It does not establish that a participant accepts the resulting cost or obligation.
Trace one change through the proposed connections, using a rehearsal where live records would create risk. Check unavailable systems, rejected changes and the fallback procedure. Technology teams should join this work before interfaces and operating rules are fixed.
The output is a specific integration requirement. It may call for better connections between existing applications, clearer record ownership or a new shared capability. It does not automatically call for one database or platform.
The same table helps assess proposed AI support. It identifies what an AI system may read or recommend and where a person or authorised system must accept a commitment. Intelligence and permission to act remain separate design questions.
Examine the Economics From Every Participant’s Position
A technically feasible arrangement can still be unattractive to someone whose contribution it requires.
Use a participant economics table when the dependency map identifies capacity, investment or exposure that someone must accept. For each participant, record the contribution, payments received, costs incurred, investment required, timing of cash flows and responsibility for changes or failures. Include coordination work and compare participation with realistic alternatives.
In the home energy example, an installer may be asked to reserve slots before assessments are complete. That helps the service team offer earlier dates, but leaves the installer exposed to unused capacity. A healthy margin on completed jobs may conceal the cost of those reservations.
The table makes the choice discussable. Participants could change the booking sequence, agree a reservation payment, narrow the promise or choose another capacity arrangement. These are alternatives to evaluate, not universally preferable solutions.
Examine both the complete service and each participating organisation. At the service level, avoid counting payments between participants as additional value created. At the participant level, those payments determine whether its role is worth performing. Distinguish an acceptable contribution from recovery of integration costs and longer term viability.
Test changed assessments, cancellations, lower demand and additional support work. Identify who bears each consequence and who can renegotiate. Document what happens if a participant withdraws while customer commitments remain outstanding.
The output is a set of participation terms, with unresolved items visible. Agreement on a shared outcome cannot substitute for agreement on the exposure each participant accepts. Record who can amend these terms, which changes require renewed consent and how unresolved disputes are escalated.
Test the Weakest Assumption Before Launching the Whole Arrangement
The preceding tools should reveal uncertainty. Turn the consequential uncertainties into tests.
Strategyzer’s Test Card makes four things explicit: the hypothesis, the test, the measure and the threshold used to judge the result (Osterwalder, 2015). It is useful here because a broad ambition such as improving collaboration is difficult to disprove.
A more precise hypothesis might be: installers will confirm provisional capacity under the proposed reservation terms. Another concerns whether a revised assessment can reach the relevant participants before they make incompatible commitments.
These require different tests. Conversations about willingness can reveal objections, but accepted terms and observed behaviour provide different evidence. A technical demonstration of data exchange cannot establish that the commercial arrangement is attractive.
Choose the weakest assumption whose failure would undermine delivery. Specify the evidence required and who will review it. Thresholds should reflect the service’s requirements; an arbitrary success percentage gives a test the appearance of rigour without a meaningful basis.
Before live delivery, rehearse the proposed arrangement with the people who would operate it. Introduce a late assessment, unavailable installer or inconsistent record. Ask participants to use the proposed decision rights and agreements to resolve it. Record where they need information, authority or intervention that the design did not provide.
A rehearsal can expose gaps. It cannot establish customer demand, live reliability or viability at scale.
For live tests, define service and safety limits, protect existing commitments and establish stopping conditions. Record baseline performance and changes in case difficulty. If a small group improves, consider whether unusually attentive support, simpler cases or favourable conditions explain part of the result.
Use the Evidence to Revise the Arrangement
The review needs more than a verdict on whether the experiment succeeded.
Strategyzer’s Learning Card separates the hypothesis tested, observations, interpretation and resulting action (Amarsy, 2015). Keep these distinctions in the review record.
Suppose the hypothetical team agrees revised dates faster, but only after a director repeatedly secures installer capacity. The observation is the director’s intervention. An interpretation is that the capacity agreement remains inadequate. The action could be to revise the reservation terms and test again. The interpretation still needs checking: perhaps the director resolved a temporary disruption rather than a recurring design weakness.
Bring customer outcomes, participant economics and operational evidence together. Ask which commitment failed, what the failure means and which part of the arrangement should change.
A better record may resolve an information gap. A recurring disagreement over cost needs a commercial decision. Repeated escalation may indicate unclear authority. Assigning every problem to training or technology risks treating symptoms while preserving the constraint.
The decision may be to expand, revise or close. Each needs an explicit reason and an account of what remains uncertain.
Keep the Tools Connected and Proportionate
The toolkit becomes useful when its outputs refer to the same outcome, participants and commitments.
| Method | Working output | Decision it supports |
|---|---|---|
| Case tracing and service blueprinting | Evidenced failures and handovers | Where should we intervene? |
| Ecosystem dependency mapping | Required contributions and acceptance status | Who and what must align? |
| Decision roles and limits | Accepted authority and escalation | Who can commit or change what? |
| Data requirements table | Records, ownership and acknowledgements | What must the digital connections support? |
| Participant economics table | Costs, rewards and exposure | Are participation terms workable? |
| Test Card and Learning Card | Evidence, interpretation and action | What should change or expand? |
Do not require every team to complete every tool in full. Use the smallest set capable of resolving the decision at hand. Return to earlier work when evidence changes the assumptions: this is an order for developing understanding, not a fixed implementation timetable.
If these records later become Business Design Labs canvases, their layouts and workshop instructions will need testing with users. Giving an adaptation a name does not validate it.
The opening question concerned a changed delivery date. By the end of this work, the team should know what information is required, whose commitments must change, who may agree the revised offer and how its consequences will be paid for.
That is the practical value of the tools. They help participants replace an assumed connection with an accepted commitment, then examine whether it holds when delivery becomes difficult.
References
Adner, R. (2017) ‘Ecosystem as structure: An actionable construct for strategy’, Journal of Management, 43(1), pp. 39–58. Available at: https://doi.org/10.1177/0149206316678451 (Accessed: 23 October 2026).
Amarsy, N. (2015) Capture (customer) insights and actions with the Learning Card. Strategyzer, 9 March. Available at: https://www.strategyzer.com/library/capture-customer-insights-and-actions-with-the-learning-card (Accessed: 23 October 2026).
Bain & Company (2023) RAPID® Decision Making. 13 October. Available at: https://www.bain.com/insights/rapid-decision-making/ (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. Available at: https://doi.org/10.1007/978-3-030-93975-5_26 (Accessed: 23 October 2026).
Gibbons, S. (2017) Service blueprints: Definition. Nielsen Norman Group, 27 August. Reviewed 15 July 2026. Available at: https://www.nngroup.com/articles/service-blueprints-definition/ (Accessed: 23 October 2026).
Osterwalder, A. (2015) Validate your ideas with the Test Card. Strategyzer, 5 March. Available at: https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card (Accessed: 23 October 2026).
