14. Blockchain Strategy and Digital Transformation

Introduction: From Distributed Ledger to Strategic Capability

Blockchain is often introduced as a technical architecture for recording transactions without relying on a single central database. In organizational practice, however, its significance is strategic rather than merely technical. A blockchain initiative can alter how firms exchange information, establish trust, coordinate processes, enforce agreements, and create digital records across institutional boundaries. Its value therefore depends less on the novelty of the ledger and more on whether it addresses a meaningful business problem better than available alternatives.

Digital transformation involves the redesign of organizational processes, capabilities, relationships, and business models through digital technologies. Blockchain may contribute to this transformation when several independent parties need to share a trusted record, when data reconciliation is costly, when provenance is important, or when programmable rules can improve the execution of agreements. It is not a universal replacement for databases, enterprise applications, or governance mechanisms. A strategically sound decision requires comparison with conventional technologies, analysis of stakeholder incentives, evaluation of risks, and a disciplined implementation roadmap.

This chapter develops a decision-oriented approach to blockchain strategy. It considers how organizations select use cases, assess return on investment and total cost of ownership, choose governance arrangements, manage adoption, integrate blockchain with enterprise systems, and evaluate outcomes. The central argument is that successful blockchain transformation is an organizational change programme supported by distributed technology—not a technology project operating independently of strategy.

Learning Objectives

By the end of this chapter, learners should be able to:

1. Explain the strategic relationship between blockchain and digital transformation.

2. Evaluate blockchain use cases using business value, feasibility, and ecosystem criteria.

3. Apply ROI and total cost of ownership reasoning to blockchain investments.

4. Analyse stakeholder interests and select an appropriate governance model.

5. Design an implementation roadmap from discovery through scale-up.

6. Explain how blockchain systems integrate with enterprise applications and data architectures.

7. Identify adoption barriers, ethical concerns, regulatory risks, and common implementation failures.

8. Recommend best practices for managing blockchain as an enterprise capability.

Strategic Meaning of Blockchain in Digital Transformation

A blockchain is a shared, tamper-evident record maintained by a network of participants according to agreed rules. In a permissionless network, participation may be open and consensus may be achieved through mechanisms such as proof of work or proof of stake. In an enterprise setting, a permissioned network normally restricts participation and assigns roles to known organizations. The strategic distinction is important: enterprise blockchain is generally used to coordinate business relationships among identifiable parties rather than to create an entirely anonymous public marketplace.

The strategic contribution of blockchain can be understood through four capabilities. First, it creates a common version of transaction history, reducing the need for each organization to maintain and reconcile separate records. Second, it can provide provenance by linking an asset or event to a sequence of recorded actions. Third, smart contracts can automate agreed business rules, although they do not eliminate the need for legal interpretation or managerial judgment. Fourth, tokenization can represent rights, assets, or claims digitally, subject to applicable law and organizational controls.

These capabilities matter only under particular conditions. Blockchain is more promising when:

• multiple organizations participate in a process;
• participants do not fully trust one another or lack a single legitimate system owner;
• transaction histories must be shared and independently auditable;
• reconciliation, dispute resolution, or verification creates significant cost;
• assets or events can be represented digitally with sufficient accuracy; and
• common standards and governance can be established.

A conventional database is usually preferable when one organization legitimately controls the process, transaction volume and latency are dominant requirements, data is highly confidential, or the problem can be solved through ordinary workflow automation. Strategic analysis must therefore ask not “Can blockchain be used?” but “What coordination problem exists, and why is a distributed ledger the proportionate response?”

The Use-Case Selection Framework

Blockchain portfolios should begin with business pain points rather than technology demonstrations. A useful screening framework evaluates a proposed use case across five dimensions: strategic relevance, ecosystem structure, information value, technical feasibility, and economic attractiveness.

Strategic relevance

The proposed initiative should connect to an explicit organizational objective such as reducing settlement time, improving compliance, increasing supply-chain visibility, lowering fraud exposure, or enabling a new service. A project that merely creates a blockchain version of an existing database may produce little strategic value. The sponsor should identify the decision, process, or customer outcome that will improve.

Ecosystem structure

The number and diversity of participants matter. A process involving manufacturers, logistics firms, regulators, insurers, banks, and customers may benefit from a shared ledger because no single party can easily impose a common database. Conversely, a process contained within one department may need workflow redesign rather than blockchain. The analysis should identify who writes data, who reads it, who validates it, who bears cost, and who gains value.

Information and trust characteristics

The use case should involve records for which provenance, non-repudiation, shared visibility, or controlled access is important. Blockchain cannot guarantee that an input is true. If a sensor reports an incorrect temperature, recording that report immutably does not make it accurate. The quality of identity management, sensors, human procedures, and external data sources remains essential.

Technical feasibility

Feasibility includes throughput, latency, privacy, identity, interoperability, smart-contract complexity, data storage, resilience, and regulatory requirements. Sensitive personal data should rarely be placed directly on an immutable ledger. A common design stores hashes, references, or proofs on-chain while keeping detailed data in controlled off-chain systems. The design must also address key management, node security, access control, backup, and recovery.

Economic attractiveness

Economic evaluation should include measurable benefits, implementation expenditure, operating costs, transition costs, and risk-adjusted outcomes. Benefits may arise from fewer reconciliations, reduced fraud, faster settlement, lower audit effort, fewer disputes, improved working-capital utilization, or new revenue. Benefits that are merely reputational or speculative should be clearly separated from quantified benefits.

A practical scoring model can assign weights to these dimensions. For example, strategic fit and ecosystem need may receive high weights, while technical novelty receives no independent value. Each criterion can be scored from 1 to 5, accompanied by evidence and confidence levels. The score should support managerial discussion rather than mechanically determine the decision. A high score with weak evidence is a signal to conduct discovery, not permission to scale.

Business Case: ROI, TCO, and Real Options

The financial case for blockchain must distinguish investment appraisal from technology enthusiasm. Return on investment may be expressed as:

ROI = (Total quantified benefits − Total investment cost) / Total investment cost

The calculation is meaningful only when the time period, baseline, benefit ownership, and assumptions are explicit. For multi-year projects, discounted cash flow or net present value is more appropriate because benefits and costs occur at different times. Scenario analysis should consider conservative, expected, and optimistic adoption levels.

Total cost of ownership extends beyond the initial software build. It may include:

• business analysis, architecture, legal advice, and process redesign;
• platform subscriptions, cloud infrastructure, nodes, storage, and network charges;
• integration with ERP, CRM, identity, payment, and analytics systems;
• smart-contract development, testing, audits, and upgrades;
• cybersecurity, key custody, monitoring, incident response, and recovery;
• training, support, change management, and partner onboarding;
• data migration, standards development, and interoperability work; and
• governance administration and costs incurred by participating organizations.

The distribution of costs and benefits is a strategic issue. A manufacturer may bear integration costs while a retailer captures greater visibility benefits. A bank may finance a platform that reduces costs for a whole industry. Such asymmetry can prevent adoption even when the ecosystem-wide business case is positive. Organizations may need shared funding, incentives, service pricing, or reciprocal commitments.

Blockchain initiatives also create real options. A carefully designed pilot can preserve the option to scale if adoption and performance assumptions are validated, while limiting early expenditure. This does not justify endless experimentation. The pilot should have explicit decision gates, measurable hypotheses, and stop criteria. A small technical demonstration without operational users, baseline measures, or a path to production is not a strategic option; it is usually an isolated experiment.

Stakeholder Analysis and Governance Choices

Blockchain networks are inter-organizational systems. Governance determines who makes decisions about membership, technical standards, data access, validation, software upgrades, dispute resolution, liability, and termination. It is therefore a business arrangement as much as a technical configuration.

Stakeholder analysis begins by mapping participants according to influence, dependency, value received, risk exposure, and willingness to participate. Core stakeholders may include the platform owner, transaction originators, validators, customers, regulators, technology providers, auditors, and affected employees. Their interests can conflict. Regulators may require transparency, firms may require confidentiality, customers may demand control over personal data, and platform operators may seek commercial control.

Common governance models include:

1. Lead-organization model: One powerful organization operates or sponsors the network. This can accelerate decisions but may reduce trust among other participants.

2. Consortium model: Several organizations jointly define rules, fund operations, and appoint a governing body. This improves legitimacy but can slow decision-making.

3. Industry utility model: A shared service operates according to standardized rules for a sector. It may achieve scale, but requires strong neutrality and regulatory alignment.

4. Public or open-network model: Participation and validation are broadly distributed. This may support openness and composability but introduces challenges involving privacy, performance, governance, and legal accountability.

5. Hybrid model: Permissioned business processes may anchor proofs or selected events to a public network. This can increase verifiability while retaining operational control, but introduces interoperability and cost considerations.

A governance charter should specify admission and exit rules, voting rights, technical maintenance, service levels, data ownership, privacy responsibilities, liability, audit rights, funding, sanctions, and procedures for correcting erroneous data. Immutability does not mean that errors are impossible. Governance must define how an incorrect record is superseded, annotated, or legally resolved without destroying the audit trail.

Integrating Blockchain with Enterprise Architecture

Blockchain rarely replaces an enterprise architecture. It normally operates as a shared coordination layer connected to existing systems. A typical arrangement includes user and organizational identity services, APIs, an application or workflow layer, the blockchain network, off-chain data stores, enterprise systems, and analytics or reporting tools.

Integration should distinguish authoritative data from shared evidence. An ERP system may remain authoritative for inventory quantities, while the blockchain records agreed transfer events among trading partners. A logistics platform may retain detailed sensor data, while the ledger stores a hash and selected verification events. This separation reduces privacy and storage problems and allows operational systems to evolve.

Important integration patterns include event-driven interfaces, API gateways, message queues, oracle services, and standardized data schemas. Oracles transmit information from external systems to smart contracts, but they introduce a trust dependency. An oracle may be a sensor network, a regulated data provider, a group of independent attestors, or a human approval process. Its reliability and accountability must be governed.

Smart contracts should be treated as controlled software components. They require version management, testing with exceptional cases, access controls, security review, monitoring, and a mechanism for handling upgrades. Code should not automatically perform an action merely because a data field has changed unless the business, legal, and operational consequences have been examined. Integration design must also address duplicate transactions, delayed messages, inconsistent master data, identity compromise, and reconciliation when external systems fail.

A Roadmap for Implementation and Adoption

A strategic implementation progresses through learning stages rather than moving directly from concept to large-scale deployment.

Stage 1: Discover and frame. Define the business problem, current process, baseline performance, affected stakeholders, regulatory constraints, and alternative technologies. Establish a senior sponsor and a cross-functional working group.

Stage 2: Validate the ecosystem. Confirm whether participants will share data, follow common standards, contribute resources, and accept the proposed governance model. Conduct interviews and process workshops. A technically feasible project may still fail if essential participants have no incentive to join.

Stage 3: Design the target operating model. Specify roles, workflows, data responsibilities, legal arrangements, service levels, security controls, and integration architecture. Define what belongs on-chain and off-chain.

Stage 4: Build a controlled pilot. Use representative data and real or closely involved users. Test the complete process, not only ledger functions. Measure transaction performance, data quality, usability, exception handling, onboarding effort, and stakeholder satisfaction.

Stage 5: Evaluate through decision gates. Compare results with the baseline and predefined success criteria. Decide whether to stop, redesign, extend, or proceed. Independent security, legal, privacy, and financial reviews are particularly important before production.

Stage 6: Industrialize and scale. Introduce production support, monitoring, incident management, release governance, training, partner certification, and performance reporting. Scaling should occur in manageable waves, beginning with participants and processes that create network value.

Adoption depends on more than training. Employees may fear loss of authority or job redesign; partners may resist exposing process information; customers may not understand the value proposition. Change leaders should explain the purpose, involve users in design, provide role-specific support, establish feedback mechanisms, and measure adoption. Network effects make early participation especially important: a platform with too few active participants may produce little value regardless of technical quality.

Applied Case: Provenance Network for Pharmaceutical Distribution

Background

The following is an illustrative case. A pharmaceutical manufacturer, two distributors, a hospital group, and a regulator are considering a permissioned blockchain network to improve the traceability of temperature-sensitive medicines. Existing records are maintained separately by each organization. Product recalls require extensive reconciliation, and participants disagree about the timing and responsibility for custody transfers.

Situation and problem

The organizations want faster verification of product origin, custody, and temperature events. However, they face conflicting requirements. The regulator needs reliable audit evidence, distributors need confidentiality regarding commercial operations, hospitals need rapid verification, and the manufacturer does not want to fund a system that produces benefits primarily for others. Sensor data is also generated by different devices with inconsistent formats.

Analysis

The use case satisfies several selection criteria: multiple independent participants, a significant reconciliation problem, high value associated with provenance, and a need for controlled access. Blockchain is not sufficient by itself because sensor accuracy, packaging identity, organizational incentives, and regulatory acceptance remain unresolved. A conventional shared database is considered, but participants are reluctant to grant one organization unilateral control over the record.

The business case identifies potential benefits from reduced manual verification, faster recalls, fewer disputes, and improved audit preparation. Costs include sensor integration, identity management, platform operation, standards development, legal agreements, and onboarding. The financial model uses conservative assumptions and assigns benefits to each participant rather than treating ecosystem value as belonging to the sponsor alone.

Approach and solution

The consortium adopts a permissioned network with role-based access. Detailed temperature readings remain in an off-chain repository; the ledger records product identifiers, custody events, time stamps, and cryptographic references to validated sensor files. A governance committee with representation from all major participant groups approves membership, software changes, data-access policies, and dispute procedures.

The pilot begins with one product category and a limited distribution route. Success criteria include the percentage of transfers recorded automatically, time required to verify a batch, exception-resolution time, data completeness, system availability, onboarding effort, and user acceptance. An independent review tests smart contracts, identity controls, privacy arrangements, and the reliability of the sensor-oracle process.

Outcome

The pilot demonstrates that shared records can reduce reconciliation effort, but it also reveals that inconsistent product identifiers create more operational difficulty than the ledger itself. The consortium therefore postpones broad expansion, first establishing a common master-data standard and improving sensor certification. The result is a qualified success: blockchain is retained as part of the target architecture, but scaling is conditioned on data governance and participant commitments.

Learning points

The case illustrates five strategic lessons. First, a real inter-organizational problem is more important than technological novelty. Second, the network’s value depends on common identifiers and trustworthy inputs. Third, governance and funding must be agreed before scale. Fourth, off-chain and on-chain components should be designed together. Finally, a pilot should be allowed to reveal that non-blockchain problems—such as poor master data—may be the main constraints on transformation.

Risks, Limitations, and Professional Responsibilities

Blockchain strategy involves technical, organizational, legal, and social risks. Privacy is a major concern because immutable records may conflict with data minimization, correction rights, or confidentiality obligations. Encryption does not eliminate all privacy risks, particularly when metadata or transaction patterns reveal sensitive relationships. Personal information should generally be minimized, pseudonymized where appropriate, and stored under controlled retention policies.

Smart-contract vulnerabilities can cause financial or operational loss. Permissioned networks reduce some risks but do not remove insider threats, collusion, compromised credentials, or faulty governance. Key loss may make authorized actions impossible, while excessive administrative power may undermine trust. Security controls should include strong identity management, separation of duties, hardware-backed key protection where justified, monitoring, incident response, and tested recovery procedures.

Regulatory classification may be uncertain when tokens represent assets, payment instruments, securities, or access rights. Cross-border networks may raise questions concerning jurisdiction, evidence, data transfer, consumer protection, and liability. Legal teams should be involved during design rather than after deployment. Records that are technically immutable may still require a legally recognized process for correction, cancellation, or reversal.

Common strategic mistakes include selecting a solution before defining the problem, confusing a pilot with production readiness, ignoring incentives of non-sponsoring participants, overestimating automation, storing excessive data on-chain, assuming consensus guarantees truth, and measuring activity rather than outcomes. Another mistake is treating governance as an administrative detail. In multi-party systems, governance is part of the product.

Ethical practice requires attention to unequal power. A dominant firm may use a shared ledger to impose surveillance or unfavorable terms on smaller suppliers. Automated rules may reproduce biased eligibility criteria or deny legitimate exceptions. Participants should assess explainability, proportionality, accessibility, data rights, and avenues for human review. Professional responsibility includes communicating uncertainty and refusing to present speculative benefits as established results.

Measuring Strategic Outcomes

A balanced measurement system should include financial, operational, ecosystem, customer, and risk indicators. Financial measures may include net present value, avoided cost, revenue from new services, and payback period. Operational measures may include cycle time, reconciliation hours, error rates, dispute duration, throughput, availability, and exception frequency. Ecosystem measures may include active participants, transaction coverage, data completeness, standard adoption, and participant retention.

Measures should be compared with a baseline and interpreted in context. A fall in manual reconciliation may be positive, but not if it results from omitted transactions. High transaction volume may indicate adoption or merely automated low-value activity. Governance indicators—such as decision time, unresolved disputes, audit findings, and access-control violations—are essential because a technically functioning network can still be organizationally ineffective.

Current Developments and Emerging Directions

Blockchain strategy is increasingly connected with tokenization, digital identity, verifiable credentials, decentralized finance, supply-chain standards, and programmable payment systems. Enterprise adoption is also moving toward interoperable networks rather than isolated ledgers. Zero-knowledge techniques and privacy-enhancing methods may allow parties to prove selected facts without disclosing complete records, although implementation complexity remains substantial.

Artificial intelligence can complement blockchain by detecting anomalous transactions, forecasting demand, classifying documents, and assisting compliance analysis. Blockchain can provide provenance for selected data or model events, but it cannot guarantee that training data, model outputs, or external inputs are correct. Combining the technologies therefore requires separate controls for data quality, model governance, privacy, explainability, and ledger integrity.

The likely direction of digital transformation is not universal adoption of one ledger. It is the development of interoperable digital ecosystems in which distributed records, cloud services, enterprise applications, identity systems, analytics, and automated agreements work together under explicit governance. Strategic maturity will be demonstrated by choosing when not to use blockchain as confidently as choosing when to use it.

Best-Practice Principles

A robust blockchain strategy should follow these principles:

• begin with a measurable coordination or trust problem;
• compare blockchain with databases, workflow tools, and centralized platforms;
• involve ecosystem participants before selecting architecture;
• establish governance, legal accountability, and funding early;
• minimize on-chain data and protect personal information;
• treat identity, master data, oracles, and key management as first-class capabilities;
• pilot the complete operating process with realistic exceptions;
• define baseline metrics, success criteria, and stop or scale gates;
• design for interoperability and integration with existing systems; and
• manage blockchain as an evolving organizational capability rather than a one-time software installation.

Chapter Summary

Blockchain contributes to digital transformation when it improves coordination among independent participants, creates trusted shared evidence, supports provenance, or automates agreed rules. Its strategic value depends on business need, ecosystem incentives, governance, integration, data quality, and measurable outcomes. Use-case selection should assess strategic relevance, participant structure, information characteristics, technical feasibility, and economic attractiveness. ROI analysis must be complemented by total cost of ownership, benefit distribution, risk assessment, and real-options thinking.

Governance determines membership, decision rights, data access, liability, upgrades, disputes, and funding. Enterprise blockchain generally operates as a coordination layer connected to ERP, identity, analytics, and off-chain data systems. Successful implementation progresses from discovery and ecosystem validation through pilot, evaluation, and controlled scale-up. The major risks involve privacy, security, regulation, faulty inputs, weak incentives, and overestimating automation. Strategic maturity lies in selecting the appropriate technology and operating model for a real organizational problem, while recognizing when blockchain is not the best solution.

Key Terms

Blockchain: A distributed, tamper-evident ledger maintained according to agreed network rules.

Digital transformation: Organizational change using digital technologies to redesign processes, capabilities, and business models.

Permissioned blockchain: A ledger network in which participation and permissions are controlled.

Smart contract: Program code that executes defined rules or actions on a blockchain platform.

Tokenization: Digital representation of an asset, right, claim, or value unit.

Use-case selection: Systematic evaluation of potential applications against strategic, technical, ecosystem, and economic criteria.

Return on investment: Ratio comparing net quantified benefits with investment cost.

Total cost of ownership: Full lifecycle cost of acquiring, operating, integrating, securing, and governing a system.

Network effect: Increase in value as more relevant participants use a platform or network.

Governance: Rules and decision processes defining authority, responsibilities, participation, and accountability.

Consortium: Group of organizations jointly operating or governing a shared initiative.

Oracle: Service or mechanism that supplies external data to a blockchain or smart contract.

On-chain data: Information recorded directly on the blockchain ledger.

Off-chain data: Information stored outside the blockchain and linked or referenced by it.

Provenance: Verifiable history showing the origin, custody, or transformation of an asset or record.

Interoperability: Ability of systems, networks, and applications to exchange and use information.

Master data: Core shared information, such as product, customer, or organizational identifiers.

Decision gate: Formal review point at which a project is stopped, redesigned, extended, or advanced.

Review Questions

Short Answer Questions

1. What characteristics make a business process a strong candidate for blockchain?

2. Distinguish ROI from total cost of ownership.

3. Why is governance a central concern in a consortium blockchain?

4. What is the difference between on-chain and off-chain data?

5. Why does a blockchain not guarantee the truth of external data?

Long Answer Questions

1. Explain a structured framework for selecting blockchain use cases in an enterprise.

2. Discuss how stakeholder incentives and benefit distribution influence blockchain adoption.

3. Compare lead-organization, consortium, industry utility, and public-network governance models.

4. Describe the major stages of a blockchain implementation roadmap and the purpose of decision gates.

5. Analyse the relationship between blockchain, enterprise architecture, smart contracts, and oracle services.

Analytical / Application Questions

1. A bank wants to place its internal loan database on a blockchain even though it is the sole process owner. Using the chapter’s decision framework, assess whether the proposal is justified and recommend an alternative if appropriate.

2. A consortium pilot reduces reconciliation time but has low partner participation and inconsistent identifiers. Should the project scale? Develop a decision using economic, governance, data, and adoption criteria.

3. Design a preliminary ROI, TCO, stakeholder, and governance approach for a blockchain-based provenance system in a sector of your choice. State assumptions and identify the main risks.

22. Multiple Choice Questions with Answers

Question 1

Which condition most strongly supports considering blockchain for an enterprise process?

A. A single department controls all data and decisions

B. Several independent parties need a shared, auditable record

C. The process requires extremely low latency and no audit trail

D. The organization wants to replace every existing database

Correct Answer: B. Several independent parties need a shared, auditable record

Question 2

Why should a blockchain business case include total cost of ownership?

A. It measures only the price of a blockchain token

B. It excludes integration and training costs

C. It captures lifecycle costs beyond initial software development

D. It guarantees that all participants will adopt the network

Correct Answer: C. It captures lifecycle costs beyond initial software development

Question 3

What is a major limitation of recording sensor data immutably on a blockchain?

A. The ledger automatically changes recorded data

B. The ledger cannot preserve timestamps

C. The ledger cannot ensure that the original sensor reading was accurate

D. The ledger prevents all participants from viewing the data

Correct Answer: C. The ledger cannot ensure that the original sensor reading was accurate

Question 4

Which governance model involves several organizations jointly defining rules and funding operations?

A. Consortium model

B. Single-user database model

C. Uncontrolled anonymous model

D. Departmental workflow model

Correct Answer: A. Consortium model

Question 5

Why might detailed personal or operational data be stored off-chain?

A. To eliminate the need for identity management

B. To reduce privacy, storage, and immutability-related risks

C. To prevent any form of auditability

D. To make smart contracts unnecessary in every case

Correct Answer: B. To reduce privacy, storage, and immutability-related risks

Question 6

What is the main purpose of a pilot decision gate?

A. To guarantee project continuation regardless of results

B. To review evidence and decide whether to stop, redesign, extend, or scale

C. To transfer governance permanently to the software vendor

D. To avoid establishing baseline measures

Correct Answer: B. To review evidence and decide whether to stop, redesign, extend, or scale

Question 7

In enterprise blockchain integration, what is an oracle?

A. A service that supplies external information to a blockchain or smart contract

B. A replacement for all enterprise resource planning systems

C. A method for deleting immutable records

D. A participant who has unlimited voting rights

Correct Answer: A. A service that supplies external information to a blockchain or smart contract

Question 8

A manufacturer funds a network while retailers receive most benefits. What strategic issue is illustrated?

A. Excessive transaction latency only

B. Unequal distribution of costs and benefits

C. The impossibility of using permissioned networks

D. The absence of any need for governance

Correct Answer: B. Unequal distribution of costs and benefits

Question 9

Which measure is most useful for evaluating whether a provenance pilot improved operations?

A. Number of promotional presentations delivered

B. Amount of code written during development

C. Change in verification time compared with a defined baseline

D. Number of blockchain terms used in reports

Correct Answer: C. Change in verification time compared with a defined baseline

Question 10

Why should blockchain be treated as an organizational change programme rather than only a software project?

A. Its success depends on processes, incentives, governance, skills, and participant adoption

B. Technical architecture has no relevance to its outcomes

C. It can operate without users or stakeholder agreements

D. Its purpose is limited to replacing employee training

Correct Answer: A. Its success depends on processes, incentives, governance, skills, and participant adoption