Digital Transformation in Operations: A Worked Example

Three changes that often get lumped together

A scanned inspection sheet is easier to store, but someone may still have to find it, interpret it and call the planner. Nothing guarantees that the response becomes faster. Be precise about which part of the job changes.

Digitization converts information into a digital form. Automation makes a defined task happen with less manual intervention. Operational transformation can include both, while also changing how teams coordinate, make decisions and maintain the new way of working. There is no single required set of five pillars that fits every organization.

A request can spend most of its life waiting

Consider a fictional maintenance-support request. The boundary starts when the request is accepted and ends when the requester receives a usable response. Use one clock, in elapsed minutes, for all four stages. This is teaching data, not a result from a Vrolen customer.

Specify the new handoff before selecting software

Name who accepts the request, what makes it ready, who decides and who tells the requester. Keep a visible exception path for an urgent issue or missing information. Otherwise the faster route can simply carry incomplete work to the next queue.

The minimum useful record might contain a request ID, affected operation, clear problem, acceptance time, assigned owner, decision and response time. Collect personal or sensitive information only when the task needs it, with approved access and retention rules. A value-stream map helps locate these handoffs without starting a software shopping exercise.

1. Observe a bounded set of requests

   Record arrival, readiness, decision and response, including exceptions and rework.

2. Agree the changed responsibilities

   Confirm an available decision owner and an absence or escalation rule.

3. Try a limited route

   Use a reversible trial and retain a fallback when the system is unavailable.

4. Compare the whole outcome

   Check elapsed time, corrections, user effort and missed requests, then decide whether to continue.

Agree which site differences need to change

A team harmonizes processes by bringing selected definitions, outputs or ways of working into agreement across sites. It can standardize a defined method by requiring the same approved rule wherever that rule applies. Organizations use these terms differently, so state the actual shared requirements and permitted local differences rather than relying on the label.

SAP's process-variant lesson starts by comparing how sites actually work. Abosh's existing two-site example makes the decision concrete: the sites share usable-stock checks and allocation authority while keeping local loading decisions. Use that example to discuss the boundary; do not assume that installing the same software requires identical work at every site.

Measure use and benefit separately

An adoption measure answers whether people use the agreed route. For example, count accepted requests completed through it, with a denominator covering all eligible requests. Keep the bypassed and abandoned cases visible.

The benefit measure answers whether the operating result improved. Compare the same start and finish events over similar request types. Report the median and slow cases, correction work and unresolved requests. A shorter average among easy completed cases can hide a worse backlog.

Choose the trial size and review period for the actual workload. Ten requests may expose a broken handoff, but cannot establish that a change holds through absences, demand peaks or rare failures. The operational-excellence guide explains how to connect local changes to a lasting operating system.

Where AI belongs, and where it adds little

A fixed routing rule may be enough when request categories and owners are clear. AI could help classify free text, suggest a similar issue or draft a response, but those uses need their own accuracy, privacy and human-review checks.

Do not put an uncertain model between a safety-critical request and a necessary response merely to call the project a transformation. Keep the decision owner explicit. The industrial AI guide goes deeper into model tasks; the software guide separates system responsibilities.

Do 70% of digital transformations fail?

BCG's 2020 research reported that 70% fell short of objectives under its composite success definition. Its methodology combined 70 supported transformations with external research among 825 executives. Some initiatives created value without meeting the full success criteria. Calling all of them complete failures loses that distinction.

Read that study within its historical scope. The interview discussed below explains where the repeated 84% claim appears, but it does not provide a reproducible study method. Before your trial, check the handoffs, assigned responsibilities, training and expected outcome against the work your team actually needs to change.

NIST MEP's digitization guidance discusses practical barriers such as training, infrastructure, information protection and employee involvement. Check those conditions before expanding a successful small test.

Five, six or seven pillars: name the source

The counts come from different models. APEC’s November 2024 manufacturing report groups its teaching around five pillars: value proposition, process improvement, leadership philosophy, people development and digital technology deployment. A team using that report can follow its grouping without treating it as a standard for every manufacturer.

McKinsey’s Rewired model instead identifies six capabilities: a value-led roadmap, talent, operating model, technology, data, and adoption and scaling. Use these categories to check the proposed change: who owns the benefit, who can maintain the system and who will use it during an ordinary shift?

A seven-pillar list needs the same attribution. Microsoft’s 2023 Kuwait government white paper covers citizen services, employee support, digital infrastructure, cybersecurity and privacy, legislation, data management and intelligence, and talent and skills. Its public-sector scope differs from a factory’s operating needs. Do not combine lists into a supposed mandatory sequence.

Types of change and McKinsey’s 4Ds

AWS groups digital transformation into business process, business model, business domain and organization. These describe what changes. A production-order handoff is a process task; a new service sold by subscription changes the business model. One initiative can touch several categories.

McKinsey’s 2017 four-D approach describes how to organize the work: Discover the ambition and value, Design the programs, Deliver through the required capabilities and partners, and De-risk the transition by sequencing changes. That named approach is different from AWS’s four types. For the order example above, choose a small reversible trial and agree a fallback before replacing the existing handoff.

Where the 84% transformation-failure headline came from

The 84% figure appears in a January 2016 Forbes interview by Bruce Rogers with Michael Gale. Gale discusses enterprise transformation research and unmet expectations, but the interview does not give a sample size, sampling method or reproducible failure calculation. It also uses several descriptions of success and failure. That is not enough to treat 84% as a current failure probability for manufacturers.

Behavior, incentives and adoption are useful issues raised by the interview. Test them locally: can a planner act on the new information, does the change remove work rather than add a duplicate entry, and does the measured benefit survive normal shifts? Report those results instead of borrowing an unverified headline percentage.