1. Introduction

By digital transformation we mean, for now, whatever an organisation means when it announces a programme under that name. That is the problem this paper addresses. The phrase has been attached to the scanning of paper archives, to the replacement of a call centre by an app, to the conversion of a manufacturer into a subscription service, and to the construction of a marketplace that sells other companies’ goods. These are not variants of one undertaking. They change different things, cost money in different shapes, return value on different calendars, and can be undone to very different degrees. A board that funds them under one label will, we argue, govern most of them wrongly, and the failures that follow will look like execution failures when they are failures of classification.

The practitioner record gives the puzzle its edge. Surveys from consultancies and business schools have for a decade reported that most transformation programmes fall short of their goals, with the fraction said to succeed rarely above a third (Westerman, Bonnet & McAfee, 2014; Kane et al., 2015), and that large IT projects carry a fat tail of overruns that averages conceal (Flyvbjerg & Budzier, 2011). The academic literature has responded with definitions, frameworks and research agendas (Matt, Hess & Benlian, 2015; Hess et al., 2016; Vial, 2019; Verhoef et al., 2021), almost all of which treat digital transformation as one phenomenon with dimensions, rather than as several phenomena sharing a name. We think the second reading explains more.

The Netherlands sharpens the puzzle further. The country ranks among the top European economies on the Commission’s Digital Economy and Society Index, with near-universal connectivity, high digital skills and a public sector that moved its citizen services online early. At the same time its large public ICT programmes have failed often enough, and visibly enough, that Parliament held an inquiry into them (Tweede Kamer, 2014) and established a standing advisory body to review them before and during execution. A country that is excellent at digital and bad at transformation is not a contradiction if “digital” and “transformation” are, in practice, different types of work.

This paper asks one question: what distinct undertakings does “digital transformation” name, and what happens when one of them is funded, governed and measured as another? Our answer is a classification of six types (Section 3), a theory of category error that predicts how programmes fail when types are confused (Section 5), a classification key and a decomposition rule (Section 6), a reading of the Dutch record through the classification (Section 7), and a constructed case (Section 8). Section 10 draws out what boards and programme leaders should do differently; Section 12 states the limits of the argument and how it could be tested.

Three things the paper does not claim should be said at the outset. It does not claim that six is the true number; it claims that the number is more than one and that these six are distinct enough to require different governance. It does not claim that programmes are never genuinely mixed; it claims that mixed programmes must be decomposed, not averaged. And it does not claim that classification alone makes programmes succeed; it claims that misclassification reliably makes them fail, which is a different and more defensible proposition.

2. Background

2.1 One name, many definitions

The research literature on digital transformation has grown fast and has not converged on a definition. Vial’s (2019) review of 282 works found twenty-three distinct definitions and proposed a synthesis: “a process that aims to improve an entity by triggering significant changes to its properties through combinations of information, computing, communication, and connectivity technologies.” The synthesis is deliberately broad. It covers the entity’s processes, its products, its business model and its organisation, and it says nothing about which of these is being changed in a given case. Verhoef et al. (2021) proposed three stages, digitization, digitalization and digital transformation, in rising order of ambition, where only the last involves a new business model. Hess et al. (2016) offered boards four dimensions along which to formulate a strategy: use of technologies, changes in value creation, structural changes and financial aspects. Matt, Hess and Benlian (2015) argued that a transformation strategy must be distinguished from an IT strategy because it concerns products, processes and organisation, not systems.

These contributions are careful, and the classification proposed here is compatible with them. What they share, and what we depart from, is the assumption of a single underlying object with several dimensions or several stages. A dimension can be dialled; a stage is reached after the previous one. Neither framing lets one say that two programmes called digital transformation are simply different kinds of thing that happen to share a label, with the consequence that the governance appropriate to one is inappropriate to the other. That is the claim of this paper.

2.2 Older distinctions that the label erased

Several of the distinctions we need were drawn decades ago and have been flattened by the newer vocabulary. Zuboff (1988) separated the capacity of information technology to automate, replacing human effort in a process, from its capacity to informate, generating information about the process that changes what people know and decide. The two had different organisational consequences and required different management; they are, in the terms of this paper, different types. Hammer (1990) insisted that automating an existing process and redesigning it were opposite undertakings, and that most “automation” projects paved cow paths. Brynjolfsson and Hitt (2000) showed that the returns to IT investment came largely from complementary organisational change, so that the same technology spending produced different outcomes depending on what else the firm changed; the complement, not the computer, determined the type. Vandermerwe and Rada (1988) named servitization, the move of a product firm into services and outcomes, as a business-model change distinct from any technology that enabled it. Rochet and Tirole (2003) and Parker, Van Alstyne and Choudary (2016) established that platforms have an economics of their own, two-sided and network-driven, that a pipeline business does not acquire by adding a website. Bharadwaj et al. (2013) argued that digital business strategy had become inseparable from business strategy, which is true of some of our types and false of others.

Each of these distinctions corresponds to a boundary between types in Section 3. The contribution of this paper is not the distinctions themselves but the observation that the label “digital transformation” lets programmes cross them without anyone noticing, and the argument that crossing them unnoticed is a specific and predictable cause of failure.

2.3 The Dutch record

The Dutch parliamentary inquiry into government ICT projects (Tweede Kamer, 2014) found that the state had insufficient control over its ICT projects, that ambitions were set without regard to feasibility, that governance was weak and that the expertise to judge proposals was lacking. Its recommendation to create an independent review body led to what is now the Adviescollege ICT-toetsing, which publishes its assessments of large public programmes. Those assessments are, for the purposes of this paper, a valuable archive: they describe, in public and in some detail, programmes that were conceived as one kind of thing and governed as another. Section 7 reads several through the classification, and Section 12 proposes coding the whole archive as the first empirical test of the argument.

3. Six undertakings

We characterise each type by six properties: the object it changes; the locus in the organisation where the change happens; the shape of investment and when the value arrives; its reversibility; its primary risk; and the natural owner who can legitimately decide it. Table 1 summarises; the text gives the reasoning. The types are ordered roughly by how far from the organisation’s existing identity they reach, but the order is not a sequence and later types do not presuppose earlier ones, a point we return to in Section 5.

Table 1. The six undertakings called digital transformation, characterised by what they change and how they behave as investments.

Type	Object changed	Locus	Investment and value	Reversibility	Primary risk	Natural owner
T1 Digitisation of records	The form of information: paper, voice or local files become structured data	Back office, archives, administration	Cost-led; value as avoided handling cost and later as data availability; linear with scope	High	Data quality; scope creep into T2	Operations, records management
T2 Process automation	The steps of a process: who or what does them, in what order	Operations and shared services	Business-cased on labour and error cost; value from go-live; stepwise by process	Medium	Paving cow paths; brittleness; exceptions	Process owner, COO
T3 Channel shift	How customers and citizens interact; which channel carries which contact	Front office, customer operations	Value from adoption, not go-live; adoption curve decides	Medium–low	Replicating the old process online; channel conflict; exclusion	Marketing, customer operations
T4 Business-model change	What is sold, to whom, and how revenue is earned	Whole firm; often a new unit	Option-like; losses first, value conditional on market acceptance	Low	Market rejection; cannibalisation; the old model’s defenders	CEO, board
T5 Platform or ecosystem	The firm’s boundary: third parties create or consume value through it	Boundary of the firm	Two-sided; value only beyond critical mass; winner-take-most dynamics	Very low	Failing to reach critical mass; governance of participants	CEO, board; a distinct P&L
T6 Data-driven decisioning	How decisions are made: by whom, on what evidence, with what model	Management and professional judgement	Value as improved decisions, hard to attribute; continuous	High for tools, low for culture	Models trusted or ignored; accountability gaps; regulation	Functional heads, CDO

3.1 T1: Digitisation of records

The first undertaking changes the form of information. Paper files become scanned images and then structured data; telephone instructions become recorded transactions; spreadsheets kept on local drives become fields in a system of record. Nothing about the process or the organisation need change. The value is of two kinds, and the second is usually the larger: an immediate reduction in handling cost, and a later availability of the data to other undertakings, especially T2 and T6, which cannot begin until records exist in a usable form.

T1 behaves as an investment in the most tractable way of the six. Cost scales linearly with scope; value arrives as each tranche is done; the work can stop at any point without loss of what was done. Its risk is almost entirely data quality: records captured wrongly are worse than records not captured, because they are trusted. Its secondary risk is political rather than technical: because digitisation is easy to start and easy to show, it attracts the label of transformation and is then expected to deliver what only later types can.

3.2 T2: Process automation

The second undertaking changes the steps of a process: which are performed by people, which by systems, and in what order. Workflow systems, straight-through processing, robotic process automation and most of what enterprise software has sold for forty years belong here. Hammer’s (1990) distinction applies within the type: a process can be automated as it stands or redesigned and then automated, and the two have different returns, but both are T2 because the object is the process.

T2 is the type the business case was invented for. Labour and error costs before and after are measurable; value starts at go-live; projects can be scoped process by process. Its characteristic failure is brittleness: the automated process handles the cases that were designed for and fails on the exceptions that were handled, invisibly, by the people it replaced. Its characteristic overclaim is to be presented as transformation of the business when it is transformation of the back office, a point that matters because the governance that T2 deserves, firm scope, firm budget, on-time and on-budget delivery, is exactly the governance that destroys T4 and T5.

3.3 T3: Channel shift

The third undertaking changes how the organisation and its customers or citizens meet: which contacts move from branch, counter, post and telephone to web and app, and what happens to the channels that remain. Its object is the interaction, not the process behind it, which is why a channel can be shifted while the process stays manual (the online form that prints in a back office) and a process automated while the channel stays physical.

T3 differs from T2 in one property that changes everything about its governance: its value arrives with adoption, not with go-live. A channel that is built and not used has cost and no value, and adoption is decided by customers, not by the programme. The investment therefore cannot be business-cased on delivery; it must be cased on an adoption curve, with the uncertainty that implies. Its characteristic failure is to replicate the old interaction online, so that the new channel is a worse version of the counter, and its characteristic organisational cost is channel conflict, as the staff and managers of the old channels resist the shift of volume that the business case assumed.

3.4 T4: Business-model change

The fourth undertaking changes what is sold, to whom, and how money is made. A manufacturer sells uptime instead of machines; a publisher sells subscriptions instead of copies; a retailer sells through its own channel what it formerly sold through intermediaries. Technology is usually the enabler and sometimes the trigger, but the object is the model, and a model can be changed with little technology or left unchanged after a great deal of it.

T4 is the type the business case was not invented for. Its investment is option-like: losses first, value conditional on the market accepting the new offer, and the acceptance not knowable in advance. Its reversibility is low because it changes commitments to customers, partners and staff, and because the old model is usually dismantled to fund the new. Its characteristic risk is not technical but market rejection, and its characteristic internal enemy is the part of the organisation whose revenues the new model cannibalises. Christensen’s (1997) argument applies: the existing model’s defenders are not wrong about the existing model, which is why they win internal arguments and why T4 is so often run as a separate unit. Its natural owner is the chief executive and the board; nobody below that level has the standing to decide what the firm sells.

3.5 T5: Platform or ecosystem

The fifth undertaking changes the boundary of the firm: it builds something through which third parties create value for one another, with the firm as orchestrator rather than producer. Marketplaces, app stores, payment schemes and data exchanges are the familiar forms. The firm may still produce, but its distinctive revenue comes from the participation of others.

The economics of T5 are those of two-sided markets (Rochet & Tirole, 2003; Parker, Van Alstyne & Choudary, 2016) and are unlike anything in T1–T4. Value is close to zero below critical mass and rises steeply above it; the subsidy of one side to attract the other is a feature, not a cost overrun; the winner tends to take most of the market, so that being second is often worth little. Its reversibility is the lowest of the six, because a platform’s value lies in commitments made by participants who are not the firm. Its characteristic failure is to build a marketplace as if it were a bigger website: a catalogue of partners’ products with no economics of participation, which never reaches critical mass and is quietly folded back into the firm’s own channel. Its natural owner is the board, and its natural organisational form is a separate profit-and-loss account, because its early losses look like failure by any T2 measure.

3.6 T6: Data-driven decisioning

The sixth undertaking changes how decisions are made: by whom, on what evidence, with what model, and with what accountability. Zuboff’s (1988) informating is its ancestor; Davenport and Harris’s (2007) competing on analytics is its practitioner statement; the present wave of machine learning is its current form. Its object is judgement, not process or channel, and its locus is management and professional work rather than operations.

T6 has the most elusive value of the six, because a better decision is hard to attribute and a worse one easy to blame. Its tools are highly reversible; the cultural change that makes the tools matter is not. Its characteristic failure is a data platform built in the expectation that decisions will change by themselves, which they do not; its characteristic risk, growing under European regulation, is that a model makes a decision nobody can explain or own. Its natural owners are the heads of the functions whose decisions change, supported rather than led by a data function.

3.7 What the types share and what they do not

All six use information technology; that is why they share a name. All six can be large, expensive and strategically important. Beyond that, the properties in Table 1 do not line up. Value arrives at go-live for T2, with adoption for T3, with market acceptance for T4, beyond critical mass for T5, and diffusely for T6. Reversibility runs from high (T1, T6 tools) to very low (T5). The legitimate owner runs from a records manager to the board. A single governance regime cannot be right for a set that varies this much, and Section 5 shows what happens when one is applied anyway.

Nor are the types a ladder. It is tempting to read them as stages, as Verhoef et al. (2021) do, with digitisation first and business-model change last. But a firm can change its business model with paper records (many did, before computing), build a platform without automating its own back office (several marketplaces did), and shift channels without touching the process behind them (most early government portals did). Later types often benefit from earlier ones; they do not require them. The error of treating the types as a ladder is itself a category error, discussed as the stack error below.

4. The economics of the six types

The properties in Table 1 can be made sharper by asking, for each type, what the value curve looks like: how value accrues against money and time. The shapes differ enough that a single funding instrument cannot fit them, and the shapes are what a governance regime is implicitly betting on. Figure 1 draws them schematically; the text says why each has the shape it has and what the shape implies for how the type should be funded and judged.

4.1 T1 and T2: the shapes finance was built for

Digitisation returns value in proportion to scope, because each tranche of records captured is a tranche of handling cost avoided and a tranche of data made available. The curve is a line, the marginal value is roughly constant, and the right question at every gate is whether the next tranche is worth its cost. Process automation returns value as a step: little before go-live, because the old process still runs in full, and most of the benefit the day the new one takes over. The curve is a step, the whole investment is at risk until the step, and the right questions are whether the step will happen on the planned date and whether the benefits booked for it are real. The business case, the stage gate and the on-time-on-budget report were designed for exactly these two shapes, and they serve them well.

4.2 T3: value follows adoption, and adoption follows its own clock

Channel shift returns nothing at launch and everything as customers adopt, and adoption has a shape of its own, the S-curve that Rogers (2003) documented across innovations: slow among the first users, fast through the middle, slow again as the late adopters are reached. The programme controls the launch; it does not control the curve, whose steepness depends on the channel’s relative advantage, its compatibility with how customers already behave, its trialability and the visibility of other users. Two consequences follow for funding. The value at launch is not a point but a distribution, and the business case should be written as one, with the adoption assumption named and its sensitivity shown. And the cost of the old channels does not fall at launch; it falls, if the enterprise lets it, when volume has shifted, which means the benefits of T3 are realised by a decision taken a year after go-live, usually by a different manager, and usually not taken.

4.3 T4: an option, and therefore a loss budget

Business-model change has the payoff of an option: a premium paid up front, in the losses of launching an offer the market has not yet accepted, and a payoff that is large if the market accepts and small or negative if it does not. The right instrument is the one developed for investment under uncertainty (Dixit & Pindyck, 1994): stage the commitment, pay for information before committing, and value the ability to abandon. In practical terms this means a loss budget rather than a business case, a market test before the scope is fixed, and gates that ask “what did we learn” rather than “are we on plan.” The T2 regime inverts all three. It fixes scope first, because the business case needs one; it has no concept of a loss budget, because losses are variances; and its gates ask about the plan. A T4 programme under it is an option exercised before the information arrives, which is the most expensive way to hold one.

4.4 T5: a plateau, a threshold, and losses that are the mechanism

A platform’s value is close to zero below critical mass and rises steeply above it, because each participant’s value depends on how many others participate (Rochet & Tirole, 2003; Evans & Schmalensee, 2016). The plateau is long, the threshold is uncertain, and the losses during the plateau are not a cost of the programme but its mechanism: the subsidy to one side that brings the other side in. A regime that reads the plateau as under-delivery and the subsidy as overrun will cut both, which is the single most reliable way to ensure that critical mass is never reached. The right instruments are a separate profit-and-loss account so that the losses are seen as investment, a target expressed in participants and transactions rather than in deliverables, and a willingness to decide, at a named point, that the threshold will not be reached and to stop.

4.5 T6: value that drifts and cannot easily be attributed

Decision change returns value as a drift: decisions improve a little, in many places, over a long time, and the improvement is confounded with everything else that changed. Attribution is the difficulty. A better underwriting model shows up in a loss ratio that also moved with the weather, the market and the competition; a better scheduling model shows up in a utilisation figure that also moved with demand. The right regime measures the decisions, not the outcomes: whether the model is used, whether its recommendations are followed or overridden and why, whether the decision cycle shortened. These are process measures, owned by the function whose decisions changed, and they are invisible to a regime that measures delivery and then looks for a benefit in the accounts.

4.6 What the shapes imply

The six shapes imply six ways of asking “is this going well,” and the question a regime asks is the question it is built to answer. The T2 regime asks whether the step will happen on time. Asked of a line, the question is harmless. Asked of an adoption curve, an option, a plateau or a drift, it produces the wrong answer with confidence, and Section 5 shows the forms the wrong answer takes.

5. Category errors

5.1 The governance regime of each type

Each type, we argue, has a governance regime that fits it: a way of funding, a definition of success, a cadence of decision and a locus of authority that match the properties in Table 1. Table 2 states them. The regimes are not exotic; each is standard practice somewhere. The point is that they are different, and that an organisation usually has one of them, the one for T2, as its default.

Table 2. The governance regime that fits each type, and the failure signature when a programme of that type is governed as T2, the default regime of most organisations.

Type	Funding	Success is	Authority	Signature when governed as T2
T1 Records	Capacity budget, tranche by tranche	Records captured to a quality standard	Operations	Mild: scope creeps into T2; quality sacrificed to throughput
T2 Process	Business case, fixed scope	On time, on budget, benefits at go-live	Process owner	None: this is its regime
T3 Channel	Staged on adoption milestones	Adoption and shift of volume	Customer function	Delivered on time, unused; old channels kept at full cost; benefits never realised
T4 Model	Option: stage-gated, loss budget, market test	Market acceptance; revenue from the new model	CEO, board	Scope frozen early; no market test; measured as a delivery; cannibalisation fought in the steering group; new model launched late and watered down
T5 Platform	Separate P&L, subsidy budget, critical-mass target	Participation and critical mass	Board	Early losses read as failure; partner subsidy cut as “cost overrun”; critical mass never reached; folded into own channel
T6 Decisions	Continuous, function-owned; tools funded centrally	Decisions changed; outcomes improved	Functional heads	Platform built, decisions unchanged; value unattributable; declared a success at go-live and a failure a year later

5.2 The mechanism of failure

A category error occurs when a programme of type $k$ is governed by the regime of type $j \neq k$. The error is rarely deliberate. It arises because the organisation has one regime it knows, because the label “digital transformation” licenses the programme without requiring its type to be named, and because the people who approve programmes are more familiar with the regime than with the types. The regime then does what regimes do: it funds the programme in the wrong shape, measures it against the wrong success, decides at the wrong cadence and places authority in the wrong hands. The consequences are predictable from the two types’ properties, which is what makes them signatures rather than accidents.

The most consequential errors involve the T2 regime, because it is the default. Governed as T2, a T3 programme is delivered to specification and judged a success at go-live; six months later the adoption curve has not moved, the old channels are still staffed, and the benefits that were booked on the assumption of volume shift are quietly written off. A T4 programme governed as T2 has its scope frozen at the point when least is known about the market, is measured on delivery rather than acceptance, and is defended in a steering group whose members’ revenues it threatens; it launches late, diluted, and is then reported as having underperformed a business case it should never have had. A T5 programme governed as T2 reads its own necessary early losses as overrun, cuts the subsidy that was the mechanism for reaching critical mass, and never reaches it. A T6 programme governed as T2 delivers a data platform on time and discovers that nobody’s decisions have changed, because changing decisions was never in scope.

Errors in the other direction exist and are quieter. A T2 programme governed as T4, with a loss budget and no fixed scope, overspends on what was a bounded problem and is called transformation when it was automation; this is the overclaim error, and it matters because it consumes the credibility that later, genuine T4 programmes will need. A T1 programme governed as T6, with a data strategy and a chief data officer, builds governance for data that nobody yet uses.

5.3 The stack error

A second family of error treats the types as a ladder. The stack error in one direction holds that T4–T6 require T1–T3 as foundations and therefore defers them until the foundations are complete; since foundations are never complete, the business-model change is deferred indefinitely while the firm digitises. The stack error in the other direction attempts T5 without any of the operational capability that would let the platform’s commitments be honoured. Both errors come from reading Table 1 as a sequence. The correct reading is that later types use earlier ones where they exist and substitute for them where they do not, and that the decision to build foundations first is a decision about sequencing under uncertainty, not a law.

5.4 Why the errors persist

Three features of organisations keep category errors in place. First, the T2 regime is the one that finance functions and project offices are built to run; it is where the templates, the gates and the careers are. Second, naming a programme’s type exposes who may own it, and ownership is contested: a T4 programme named as such belongs to the chief executive, which is uncomfortable for the divisional head who proposed it. Third, the label itself is rewarded. A digitisation programme called digital transformation is funded more easily, reported more proudly and reviewed less sharply than the same programme called digitisation. The label is, in this sense, a licence to misclassify, and the paper’s practical recommendation (Section 10) begins by withdrawing it.

5.5 What category error looks like in the reporting

Category errors leave traces in a programme’s own reporting before they appear in its outcome, and a board that knows the traces can act a year earlier. Table 3 lists them. The common feature is a report that is simultaneously green and wrong: green because it measures what the regime measures, wrong because the regime is measuring the wrong thing.

Table 3. Early traces of category error in a programme’s own reporting, by the type that is being governed as T2, and the question a board should ask on seeing each.

Type	Trace in the reporting	Question to ask
T3 as T2	Status green through build; a launch milestone celebrated; adoption appears as a single number with no curve and no target date for volume shift; the old channels’ cost is unchanged in the forecast	What share of volume has shifted, against what curve, and when does the old channel’s budget fall?
T4 as T2	Scope “baselined” in the first quarter; no customer has seen the offer; the steering group includes the heads of the channels the offer bypasses; benefits booked as revenue in year two with no acceptance test	What has the market told us, and who in this room loses if it says yes?
T5 as T2	“Partner onboarding” reported as a count of signed agreements; losses reported as variance against a cost plan; a request to cut the partner incentive budget; the platform’s traffic reported as the firm’s own	How many participants transact with each other, how far is critical mass, and what is the subsidy for?
T6 as T2	The data platform’s delivery reported as the programme; “use cases” listed without the decision-maker named; benefits expressed as “insight”; the functions whose decisions should change are not in the governance	Which decisions have changed, who makes them, and how often is the model overridden?
T2 as T4	A bounded automation presented with a transformation narrative; a loss budget with no market uncertainty to justify it; strategic language around a process change	What is uncertain here that a business case could not resolve?

6. A classification key and a decomposition rule

6.1 The key

A classification is useful only if a programme can be placed in it before it is funded. The key below does so with five questions, asked in order; the first “yes” places the programme. The questions are ordered from the most to the least consequential type, so that a programme with any T5 or T4 content is identified as such before its T1–T3 content lets it pass as routine.

Q1. Will third parties create or consume value through what we build, and does our revenue depend on their participation? If yes: T5. The programme needs a separate P&L, a critical-mass target and a subsidy budget, and belongs to the board.

Q2. Will we sell something different, to someone different, or earn money differently than we do now? If yes: T4. The programme needs stage-gating with a loss budget, a market test before scope is fixed, and the chief executive as owner.

Q3. Will the way decisions are made change: who decides, on what evidence, with what model? If yes: T6. The programme belongs to the heads of the functions whose decisions change; the data platform is a means, not the programme.

Q4. Will customers or citizens interact with us through a different channel, and does our benefit depend on their choosing it? If yes: T3. Fund on adoption milestones; count success in shifted volume; plan the fate of the old channels explicitly.

Q5. Will the steps of a process change: who or what performs them? If yes: T2. The business-case regime fits. If no, and the programme changes only the form of records: T1. Fund as capacity, measure quality.

The order encodes a principle: a programme is governed by its most demanding type. A platform that also automates a back office is T5, and the automation is a workstream inside it, governed as T2 within a T5 envelope. The reverse, a T2 programme with a “platform ambition” attached to justify its budget, should be sent back for the ambition to be removed or the programme to be reclassified.

6.2 The decomposition rule

Most large programmes are mixed, and the key will place a mixed programme in its most demanding type. That is correct for the envelope and wrong for the parts. The decomposition rule is: a mixed programme is split into typed workstreams, each governed by its own regime, with the envelope governed by the most demanding type present. A T4 programme with T2 and T1 content has three regimes running inside one mandate: the records workstream is funded as capacity and measured on quality; the process workstream has a business case and a go-live; the business-model workstream has a loss budget, a market test and the chief executive’s attention. The envelope reports to the board on the T4 question, market acceptance, and not on the average of three incommensurable measures.

Averaging is the specific failure the rule prevents. A programme that is sixty per cent T2 and forty per cent T4, reported as one, will show the T2 content on time and on budget and the T4 content behind, and the average will look acceptable until the T4 content fails outright. Separately reported, the T4 workstream’s position is visible from the first gate.

6.3 What the key does not do

The key places a programme; it does not judge it. A T4 programme is not better than a T1 programme; it is riskier, less reversible and owned higher up, and it should be undertaken only when the firm needs its model changed. Many organisations should be doing T1 and T2 well and nothing else, and would be better served by calling that what it is. The key’s purpose is to make the type explicit so that the governance can match it, not to encourage ambition.

7. The Dutch puzzle

7.1 Excellent at digital, bad at transformation

The Netherlands scores among the leading European economies on the Commission’s digital index: connectivity is near universal, digital skills are high, and the public sector’s citizen services have been online for two decades, with a national digital identity, DigiD, in use since 2005 and a personal government portal since 2011. By the standards of T1 and T3, and increasingly T2, this is a digital leader.

The same country has a public record of large ICT programmes that ran years late, cost multiples of their estimates, or were abandoned, a record serious enough to produce a parliamentary inquiry (Tweede Kamer, 2014) and a standing review body whose published assessments regularly find programmes whose scope, governance and feasibility do not match. The paradox dissolves under the classification. The successes are T1, T2 and T3: records digitised, processes automated, channels shifted, undertaken by organisations that know the T2 regime well and apply it to work that fits it. The failures, on our reading, cluster where a programme is T4, T5 or T6 in substance but governed as T2, or is a hybrid of several types reported as one.

7.2 Public programmes as hybrids governed as the wrong type

Several of the public programmes that the review body has assessed share a shape. A new law requires a new way of working across many organisations; the way of working requires a shared digital facility through which those organisations exchange information; the facility is specified in detail before the way of working has been tried; and the programme is governed with fixed scope, fixed dates and a delivery milestone as its success. In the terms of this paper, that is a T5 or T6 undertaking, a platform through which many parties participate or a change in how decisions across a chain are made, governed as T2. The signature in Table 2 follows: scope frozen early, no test of whether the participants will or can participate, early difficulties read as delivery failure, and dates moved repeatedly while the substance is diluted. We do not claim that classification was the only cause in any given programme, and the review body’s own findings name others, but we note that the pattern it describes repeatedly, ambition fixed before feasibility, governance that cannot absorb learning, is the pattern category error predicts.

7.3 Private successes as the demanding types

The Dutch private sector’s conspicuous digital successes are, by contrast, concentrated in T4 and T5, and were governed accordingly. The national online payment scheme iDEAL was built in 2005 by banks acting collectively as a platform, not as any one bank’s channel, and reached critical mass because every side joined at once. A later peer-to-peer payment app, launched by one bank, was run as a product with its own adoption target rather than as an IT delivery, and became a verb. The country’s largest online retailer built a marketplace that sells other sellers’ goods, a T5 move from a T3 base, as a distinct economic model. Its best-known technology exporter sits at the centre of an ecosystem of suppliers and customers that behaves as a platform in all but name. None of these was called digital transformation at the time, and each was governed as the type it was.

The contrast is the paper’s argument in miniature. The organisations that succeeded at T4 and T5 named the type, owned it at the top, funded it as an option or a platform, and measured it on acceptance or participation. The organisations that failed applied the regime of T2 to work that was not T2. Digital excellence and transformation failure coexist because they are different competences.

7.4 The private sector’s quiet T3

Between the public failures and the platform successes lies a large, undramatic Dutch success that the classification also explains: the near-complete shift of retail banking, insurance and government contact to digital channels, achieved over two decades without being called transformation. Dutch banks closed most of their branch networks as mobile banking became the default channel for the great majority of customers; the tax authority moved filing online and then pre-filled the return; municipalities moved permits and registrations to web forms. These are T3 undertakings, and they were governed, in the main, as T3: launched, measured on adoption, with the old channels reduced as volume shifted rather than on a programme date. The country’s high standing on digital indices rests largely on this quiet competence, which is a competence in one type.

7.5 Reading an assessment through the key

To make the coding protocol of Appendix A concrete, consider how a typical public assessment reads under the key. The programme implements a new law that changes how several organisations in a chain, say municipalities, a national agency and private parties, work together, and it builds a shared digital facility through which they exchange information. Q1 asks whether third parties create or consume value through what is built and whether the programme’s success depends on their participation; for a chain facility the answer is yes, and the envelope is T5. Q3 asks whether the way decisions are made changes; if the facility is meant to let decisions be taken on shared information that was formerly held separately, the answer is also yes, and T6 content is present. The assessment then describes the governance: a fixed scope specified in detail, a delivery date set by the law’s commencement, a steering group of the commissioning ministry, and success defined as the facility working on that date. That is the T2 regime, recorded on all four properties of the protocol, and the mismatch $(\mathrm{T5}, \mathrm{T2})$ is coded. The assessment’s own findings, that the participants’ readiness was not tested, that the scope could not absorb what was learned, that the date moved and the ambition narrowed, are then compared with the signature in Table 2. We have not performed this coding on the archive, and Section 12 proposes it; the point here is that the archive contains what the protocol needs.

7.6 Why the public sector is prone to the error

Three features of public programmes make category error more likely there than in the private sector, and none is incompetence. The law sets the date, so a T2 milestone is imposed from outside on undertakings that are not T2. The budget cycle requires the scope and the cost to be fixed at appropriation, which is the earliest and worst moment for a T4, T5 or T6 undertaking. And there is no market test available: a public facility cannot be launched to a thousand customers to see whether it is accepted, because its users are obliged to use it. The first two can be mitigated by appropriating a loss budget and a learning gate rather than a scope; the third can be mitigated by piloting with volunteer participants before the obligation takes effect, which some Dutch programmes have done and which the review body has repeatedly recommended.

8. A constructed case

The following case is constructed, not observed. It exists to show the six types and the category errors in one programme, and to show how the decomposition rule re-cuts it. It is not a report on any insurer, and its figures are illustrative.

8.1 The programme as announced

Insurer V is a mid-sized Dutch non-life insurer with a direct channel, an intermediary channel and a back office that processes claims largely on paper and telephone. Its board announces a three-year digital transformation programme with a single budget and a single steering group chaired by the chief operating officer, with the following ambitions: digitise the claims archive; automate claims handling; move customer contact to an app; launch a usage-based motor product priced on telematics; open the app to third-party services (roadside assistance, repair networks) as a marketplace; and use claims data to automate underwriting decisions. The programme is business-cased as a whole, with benefits dominated by claims-handling labour savings and a line for “new revenue” from the usage-based product and the marketplace.

8.2 The programme by type

Read through the key, the programme contains every type. The archive is T1. Claims automation is T2. The app is T3. The usage-based product is T4: a different thing sold, priced differently. The marketplace is T5: third parties earning through the insurer’s channel. Automated underwriting is T6: a decision formerly made by underwriters now made by a model. By the ordering principle the envelope is T5, and the programme belongs to the board, not the chief operating officer.

8.3 What the single regime does

Governed as one T2 programme, the case proceeds as Table 2 predicts. Year one: the archive and the automation go well, the steering group reports green, and the app is built to specification. Year two: the app launches on time, adoption is a quarter of the business-case assumption, and the contact centre is not reduced because the volume has not shifted; the usage-based product’s scope, frozen in year one before any customer had seen it, proves to price badly for the customers it attracts, and the intermediary channel’s managers, whose commission it bypasses, argue successfully in the steering group for a delay; the marketplace is built as a catalogue of partner links, attracts three partners, and its partner-acquisition budget is cut as an overrun; the underwriting model is delivered and underwriters, who were not in scope, decline to use it. Year three: the programme is reported as sixty per cent delivered on time and on budget, which is true of its T1 and T2 content, and as having underperformed its benefits case, which is true of everything else. A review concludes that execution was weak in the later phases.

8.4 The programme decomposed

Re-cut by the decomposition rule, the same ambitions become six workstreams under a T5 envelope owned by the board. The archive is funded as capacity and measured on quality. Claims automation keeps its business case. The app is funded in stages released on adoption, with the fate of the contact centre planned as a function of shifted volume rather than assumed. The usage-based product is given a loss budget and a market test with a thousand customers before its pricing is fixed, is run as a unit outside the intermediary channel’s line of authority, and reports to the chief executive on acceptance. The marketplace is given its own profit-and-loss account, a critical-mass target in partners and transactions, and a subsidy budget that is understood as the mechanism, not a cost. The underwriting model is owned by the head of underwriting, with underwriters’ decisions in scope from the start and the data platform as a means.

Nothing in the decomposition makes the usage-based product or the marketplace succeed; the market decides that. What it does is make their position visible from the first gate, keep the T2 regime from strangling them, and keep their difficulties from being averaged into a programme that looks acceptable until it is not.

9. A second constructed case: a municipality and a chain

The insurer’s case is private and mixed. The second case is public and shows the error in the form Section 7 describes. It is constructed, not observed, and is not a report on any municipality or programme.

9.1 The programme as mandated

A new national law changes how applications for a category of permits are assessed: instead of each municipality assessing against its own rules, applicants submit once to a national facility, which routes the application to the municipality, the regional authority and the relevant national agencies, who assess their parts against shared data and return a single decision. Municipality M, with sixty thousand residents, must have its processes, systems and staff ready by the law’s commencement in eighteen months. The ministry’s programme builds the national facility; each municipality’s programme connects to it and adapts its own working. M’s council approves a programme with a fixed budget, a project leader from the IT department, and success defined as “connected and compliant on the commencement date.”

9.2 The programme by type

Under the key, the national facility is T5: third parties, the municipalities and agencies, create and consume value through it, and its value depends entirely on their participation. The assessment on shared data is T6: a decision formerly made by one organisation on its own records is now made jointly on shared ones. M’s own programme contains T2, its permit process changes, and T3, applicants now meet it through the national facility rather than its own counter, and some T1, its permit records must exist in a form the facility can read. The national envelope is T5 governed as T2; M’s local envelope is T3 governed as T2.

9.3 What happens

At the national level the T5 signature appears: the facility’s scope is fixed in the first months, before any municipality has tried to connect; the participants’ readiness is assumed rather than tested; the commencement date is treated as the delivery milestone and defended until it cannot be, then moved; the scope is narrowed so that the facility can be said to work on the new date, with the parts that required the agencies to change their decisions deferred to “a later release.” At the local level the T3 signature appears: M is connected on the date and reports green; applicants, finding the national facility unfamiliar and M’s counter still open, continue to come to the counter; M keeps its counter staffed, because the volume has not shifted; its benefits case, which assumed the counter’s reduction, is not realised; and M’s council, a year later, asks why the programme that was reported as a success has saved nothing. The national review finds governance weaknesses and recommends stronger project control, which is to say more T2.

9.4 The programme decomposed

Under the decomposition rule the national facility is governed as T5 from the outset: a participation target, a pilot with volunteer municipalities and agencies before the obligation takes effect, a staged commencement by region, and a gate that asks what the pilot taught rather than whether the plan holds. The joint assessment on shared data is a T6 workstream owned by the assessing agencies, with their decision-makers in the governance and the facility as a means. M’s own programme separates its T2 content, which keeps its business case, from its T3 content, which is funded on an adoption curve and comes with a plan for the counter that is triggered by shifted volume rather than by a date. None of this changes the law’s date. What it changes is that the national facility is tested by participants before everyone is obliged to use it, that the agencies’ decisions are in scope, and that M’s council sees adoption rather than connection as the measure, and so is not surprised a year later.

10. Implications

Withdraw the label. The first recommendation is the cheapest: do not fund anything called digital transformation. Require the proposal to name its type under the key, and fund the type. A proposal that resists naming its type is usually a T2 programme seeking a T4 budget or a T4 programme seeking to avoid board ownership, and both should be refused until they are named.

Match the regime to the type. Finance functions and project offices should maintain, explicitly, more than one regime: the business-case regime for T2, an adoption-staged regime for T3, an option regime with loss budgets and market tests for T4, a platform regime with separate accounts for T5, and a function-owned continuous regime for T6. Most organisations have only the first. Building the others is a capability investment that precedes any genuine transformation.

Own at the right level. The key assigns ownership, and the assignment should be enforced. A T4 or T5 programme owned below the chief executive will be defeated by the parts of the organisation it threatens, not through malice but through the ordinary working of a steering group in which those parts are represented.

Decompose and report separately. Mixed programmes are split into typed workstreams and reported by type. The board sees the T4 and T5 content on its own measures, acceptance and participation, and does not see them averaged with the T2 content’s delivery metrics.

Sequence under uncertainty, not by ladder. Foundations in T1 and T2 are built where the demanding types need them and not as a precondition for beginning. The question is not “are we ready” but “what must exist for the market test to be honest,” which is usually less than the foundations argument claims.

Be content with T1 and T2 when that is what is needed. Much of the value available to most organisations lies in records and processes, and a firm that does those well and calls them what they are is better governed than one that calls them transformation and governs them as such.

11. Building the repertoire of regimes

The implications of Section 10 assume that an organisation can run the regime its programme needs. Most cannot. Finance functions, project offices and boards have one regime, the business-case regime of T2, with its templates, gates, reporting and careers, and the other regimes have to be built before they can be applied. We think of the set of regimes an organisation can run as its transformation repertoire, and we suggest that the repertoire, rather than the technology budget, is what decides which types an organisation can undertake. Table 4 lists what each regime needs. The list is practical rather than theoretical, and it is where a board’s attention should go before it funds a T4 or T5 programme.

Table 4. What each governance regime needs in order to exist, and the organisational capability it implies. An organisation’s transformation repertoire is the set of regimes it can actually run.

Regime	Funding instrument	Reporting and gates	People and authority
T1 Capacity	A standing budget line scaled to throughput; no business case per tranche	Quality sampling of captured records; throughput against capacity	A records or operations owner; data-quality skills
T2 Business case	Approved case with fixed scope and benefits; change control	Schedule, cost, benefits at go-live; RAG status	Process owner; project office; benefits tracking after close
T3 Adoption-staged	Funding released in stages against adoption milestones; a budget for the old channel’s run-down	An adoption curve with a named assumption; shifted volume; a trigger for reducing old channels	A customer-function owner with authority over the old channels, not only the new one
T4 Option	A loss budget with a ceiling; funding for a market test before scope is fixed; an abandonment decision scheduled	Learning gates: what the market said; acceptance metrics; a go/no-go on evidence	CEO as owner; a unit outside the line of the revenues it threatens; tolerance for a visible loss
T5 Platform	A separate P&L; a subsidy budget understood as the mechanism; a critical-mass target with a stop date	Participants and transactions between them; distance to critical mass; subsidy per acquired participant	Board as owner; a platform leader with partner authority; the discipline to stop if the threshold recedes
T6 Continuous	Central funding for tools; function-owned funding for use; no programme end	Decisions changed; model use and override rates; decision cycle time	Functional heads as owners; a data function in support; model accountability named

Two observations follow from the table. First, the regimes differ most in the authority they require, and authority is the hardest thing to build: a T4 regime needs a chief executive willing to own a loss, and a T5 regime needs a board willing to fund a subsidy, and no template supplies either. Second, the repertoire explains why organisations that are good at one type are often bad at the next: the competence is in the regime, and the regime does not transfer. An organisation that has shifted its channels superbly has built the T3 regime, not the T4 one, and its next business-model programme will be run, by default, as a channel launch.

12. Limitations and research agenda

This is conceptual research. Three limitations follow, each with a test.

First, the boundaries between types are not sharp. A loyalty app that changes pricing by behaviour is T3 shading into T4; a shared data exchange is T5 shading into T6. The key resolves such cases by the ordering principle, but the principle is a convention. The test is inter-rater reliability: have independent coders apply the key to the same set of programme descriptions and measure agreement; where agreement is low, the boundary needs a sharper question.

Second, the claim that category error causes failure is stated as a mechanism with signatures, not demonstrated. The test is available because the Dutch review body publishes its assessments. A coding protocol would classify each assessed programme by type under the key, classify the regime under which it was governed from the assessment’s description of its funding, success measures and authority, and record its outcome. The hypothesis is that programmes whose type and regime match fail at a lower rate than those where they do not, controlling for size, and that mismatched programmes show the signatures of Table 2 rather than generic overrun. The same protocol applies to any organisation’s programme portfolio, and Appendix A states it.

Third, the Dutch reading of Section 7 is interpretive. The successes and failures named are public, but the claim that the failures were hybrids governed as T2 is our reading of the assessments, not a finding of them. The coding protocol would turn the reading into a result or refute it.

Beyond these, two questions would extend the argument. Whether the types have characteristic durations, so that a T4 programme planned on a T2 timescale is wrong by a predictable factor, is open and measurable. And whether organisations can be characterised by which regimes they are able to run, so that a firm’s transformation capacity is its repertoire of regimes rather than its technology, is a hypothesis we find plausible and have not tested.

13. Conclusion

Digital transformation is not one undertaking. It is at least six, which change different things, return value on different calendars, can be undone to different degrees and belong to different owners. Boards fund the wrong one not by choosing badly among the six but by not choosing: the label admits a programme without requiring its type to be named, and the organisation’s default regime, built for process automation, is then applied to work it does not fit. The failures that follow have signatures, and the signatures are visible in the public record of a country that is excellent at the first three types and struggles with the last three.

We at Nashua have proposed a classification, a key for applying it before a programme is funded, and a rule for decomposing programmes that are genuinely mixed. None of this makes a business-model change or a platform succeed; the market does that. What it does is stop a governance regime from strangling them, and stop their difficulties from being averaged away until they are beyond remedy. The classification is testable against assessments already in the public domain, and we would rather it were tested than believed.

Appendix A. Coding protocol for testing the classification

The protocol below is intended for a sample of programme assessments or post-implementation reviews; the Dutch review body’s published assessments are the obvious first sample, and any organisation’s own portfolio the second.

Unit. One programme, as defined by its mandate at approval. Programmes that were re-scoped are coded at the original mandate and again at each re-scope.

Type. Apply the key of Section 6 to the mandate as approved. Record the envelope type (first “yes”) and every type present. Two coders independently; record agreement.

Regime. From the assessment’s description, code the regime actually applied on four properties: funding shape (fixed business case; staged on adoption; option with loss budget; separate P&L; continuous), success measure (delivery; adoption; acceptance; participation; decision outcomes), decision cadence (gates on delivery; gates on learning), and locus of authority (process owner; function head; CEO; board). Map the four to the regime of Table 2 that they most resemble.

Match. Matched if the envelope type’s regime equals the regime applied; otherwise mismatched, with the pair $(k, j)$ recorded.

Outcome. Code outcome on three variables available in most assessments: schedule variance, cost variance, and whether the assessment judges the programme’s substantive aim as achieved, partly achieved or not achieved. Record also whether the signature of Table 2 for the pair $(k, j)$ is described.

Analysis. Compare outcomes between matched and mismatched programmes, controlling for budget size and duration. The classification is supported if mismatch predicts non-achievement of the substantive aim beyond what size predicts, and if the described failures in mismatched programmes correspond to the predicted signatures more often than chance.

Appendix B. Type signatures in programme documents

Reviewers who must classify a programme from documents rather than from its sponsors can use the following signals; none is decisive.

T1. Benefits expressed as handling cost per record; scope expressed in volumes of documents or transactions; no change to any decision or interaction.

T2. Benefits expressed as full-time equivalents and error rates; a process map “as is” and “to be”; a go-live date as the central milestone.

T3. Benefits depend on a percentage of customers using a new channel; the old channel’s reduction is assumed rather than planned; a launch date rather than an adoption target.

T4. A new product, price or revenue line appears in the benefits; the proposal comes from a division whose existing revenue it would reduce; the market has not yet seen the offer.

T5. Third parties appear as sources of revenue or content; a “partner strategy” section; benefits that are near zero in early years and steep later; no separate accounts.

T6. A data platform is the main deliverable; benefits are expressed as “better decisions” without a decision named; the people whose decisions would change are not in the governance.

Appendix C. The type–regime mismatch matrix

Table 5 completes Table 2 by giving the signature for every pair: the type of the programme in the rows and the regime applied in the columns. The diagonal is the matched case. The matrix is the paper’s claim in its most testable form: each cell is a prediction about what a mismatched programme’s assessment will describe.

Table 5. Failure signatures when a programme of the row type is governed by the column regime. Diagonal cells are matched. “Overspend” means a bounded undertaking funded as an unbounded one; “starved” means an unbounded undertaking funded as a bounded one.

Type $\backslash$ regime	T1 Capacity	T2 Business case	T3 Adoption	T4 Option	T5 Platform	T6 Continuous
T1	matched	Over-specified; tranches forced into a project with a go-live that means nothing	Adoption measured of something nobody adopts	Overspend; a loss budget for a bounded task	Overspend; a P&L for an archive	Governance for data nobody yet uses
T2	Under-governed; no benefits case; scope drifts	matched	Go-live delayed waiting for “adoption” that is not the point	Overspend; strategic narrative on a process change; credibility spent	Overspend; partners sought for a back office	No end; a process change run as a standing programme
T3	Launch without any adoption plan	Green at launch, unused; old channels kept; benefits written off	matched	Over-tested; a channel treated as uncertain when its risk is adoption, not acceptance	Partners sought for a channel that is the firm’s own	Decision metrics applied to an interaction change
T4	Starved; no capacity for a market test	Scope frozen early; no market test; cannibalisation fought in the steering group; launched late, diluted	Measured on adoption of an offer the market may not accept at any adoption level	matched	A P&L for an offer that has no third-party side	Owned by a function; never a decision of the firm
T5	Starved; built as a catalogue	Losses read as overrun; subsidy cut; critical mass never reached; folded into own channel	Participation read as adoption of the firm’s own channel; the other side ignored	Treated as an option on a product; the two-sided mechanism unfunded	matched	No threshold named; a platform run as a continuous improvement
T6	A data platform built as records capture	Platform delivered; decisions unchanged; success at go-live, failure a year later	Adoption of a tool counted; decisions not	Over-tested; a decision change treated as a market bet	A P&L sought for an internal capability	matched

References

Bharadwaj, A., El Sawy, O. A., Pavlou, P. A., & Venkatraman, N. (2013). Digital business strategy: Toward a next generation of insights. MIS Quarterly, 37(2), 471–482. https://doi.org/10.25300/MISQ/2013/37:2.3

Brynjolfsson, E., & Hitt, L. M. (2000). Beyond computation: Information technology, organizational transformation and business performance. Journal of Economic Perspectives, 14(4), 23–48. https://doi.org/10.1257/jep.14.4.23

Christensen, C. M. (1997). The innovator’s dilemma: When new technologies cause great firms to fail. Harvard Business School Press.

Davenport, T. H., & Harris, J. G. (2007). Competing on analytics: The new science of winning. Harvard Business School Press.

Dixit, A. K., & Pindyck, R. S. (1994). Investment under uncertainty. Princeton University Press. https://doi.org/10.1515/9781400830176

European Commission (2022). Digital Economy and Society Index (DESI) 2022. Publications Office of the European Union. https://digital-strategy.ec.europa.eu/en/library/digital-economy-and-society-index-desi-2022

Evans, D. S., & Schmalensee, R. (2016). Matchmakers: The new economics of multisided platforms. Harvard Business Review Press. ISBN 978-1-63369-172-8.

Flyvbjerg, B., & Budzier, A. (2011). Why your IT project may be riskier than you think. Harvard Business Review, 89(9), 23–25.

Furr, N., & Shipilov, A. (2019). Digital doesn’t have to be disruptive. Harvard Business Review, 97(4), July–August 2019. https://hbr.org/2019/07/digital-doesnt-have-to-be-disruptive

Hammer, M. (1990). Reengineering work: Don’t automate, obliterate. Harvard Business Review, 68(4), 104–112. https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate

Hess, T., Matt, C., Benlian, A., & Wiesböck, F. (2016). Options for formulating a digital transformation strategy. MIS Quarterly Executive, 15(2), 123–139.

Kane, G. C., Palmer, D., Phillips, A. N., Kiron, D., & Buckley, N. (2015). Strategy, not technology, drives digital transformation. Research report. MIT Sloan Management Review and Deloitte University Press. https://doi.org/10.63383/uzyq6766

Matt, C., Hess, T., & Benlian, A. (2015). Digital transformation strategies. Business & Information Systems Engineering, 57(5), 339–343. https://doi.org/10.1007/s12599-015-0401-5

Parker, G. G., Van Alstyne, M. W., & Choudary, S. P. (2016). Platform revolution: How networked markets are transforming the economy and how to make them work for you. W. W. Norton.

Rochet, J.-C., & Tirole, J. (2003). Platform competition in two-sided markets. Journal of the European Economic Association, 1(4), 990–1029. https://doi.org/10.1162/154247603322493212

Rogers, E. M. (2003). Diffusion of innovations (5th ed.). Free Press.

Tweede Kamer der Staten-Generaal (2014). Naar grip op ICT: Parlementair onderzoek naar ICT-projecten bij de overheid. Eindrapport van de Tijdelijke commissie ICT-projecten bij de overheid (Commissie Elias). Kamerstukken II 2014/15, 33 326, nr. 5. https://zoek.officielebekendmakingen.nl/kst-33326-5.html

Vandermerwe, S., & Rada, J. (1988). Servitization of business: Adding value by adding services. European Management Journal, 6(4), 314–324. https://doi.org/10.1016/0263-2373(88)90033-3

Verhoef, P. C., Broekhuizen, T., Bart, Y., Bhattacharya, A., Dong, J. Q., Fabian, N., & Haenlein, M. (2021). Digital transformation: A multidisciplinary reflection and research agenda. Journal of Business Research, 122, 889–901. https://doi.org/10.1016/j.jbusres.2019.09.022

Vial, G. (2019). Understanding digital transformation: A review and a research agenda. Journal of Strategic Information Systems, 28(2), 118–144. https://doi.org/10.1016/j.jsis.2019.01.003

Westerman, G., Bonnet, D., & McAfee, A. (2014). Leading digital: Turning technology into business transformation. Harvard Business Review Press.

Zuboff, S. (1988). In the age of the smart machine: The future of work and power. Basic Books.