Digital manufacturing strategy: choosing what to digitise, in what order, and who owns it afterwards

Start from decisions currently made on information nobody trusts

The useful entry question is not which technology to adopt but which recurring decision rests on information people distrust. Which machine to fix first. Whether a batch is acceptable. Where the constraint sits this week. Whether a supplier's parts are drifting. Each carries a cost when it goes wrong, and that cost is the size of the prize. Ranking proposals this way exposes the ones with no decision attached at all, which covers most ideas arriving with a supplier logo on them. It also forces whoever will use the output to be named before money is committed.

Order of work follows dependency, not enthusiasm

Identification and master data come first, because nothing downstream survives a plant where the same machine carries three different names. Connectivity and the network follow, together with the security arrangements that must accompany them. Then visibility, meaning data collected and put in front of people who act on it. Only after that does closed-loop control, where a system adjusts a setpoint or releases work without a human, become sensible. Sites jumping straight to the last stage build something impressive that nobody trusts, and rebuilding trust is expensive because operators quietly keep the parallel paper record going forever.

Why pilots stop at pilot

Pilots stall for organisational rather than technical reasons. The pilot was funded and the rollout was not. The pilot ran with an engineer present every day and no plan for who does that across a site. The pilot was built around one line's peculiarities and does not generalise. Nobody in operations was accountable for the outcome, so when the engineer moved on it simply stopped. Before starting, write down what scaling would demand in people and money, and who would sign for it. If that answer is uncomfortable, you are running an experiment, and saying so is more honest.

Funding and ownership are the same argument in two forms

Digital work is frequently funded as capital and then needs operating money indefinitely, which is where it breaks. Licences, support, sustaining engineering and periodic refresh all recur, and where no cost centre carries them the system decays quietly. Ownership restates the same question: engineering builds it, information technology hosts it, and operations has to live with it, so the argument about whose budget carries the running cost belongs before implementation rather than at the first renewal notice. Name an owner in operations holding real authority to insist the underlying data stays correct.

Writing down what you are not going to do

A strategy is mostly a list of refusals. Machines approaching replacement are not worth connecting. Paper processes that work, are understood and carry modest risk can stay on paper. Site-built tools duplicating a corporate system create a support burden nobody will fund. Recording the refusals, each with its reason, achieves two things: the same proposal stops returning every planning round, and the accepted items become defensible when budgets are challenged. Revisit the list when circumstances shift, particularly when a machine that was near replacement quietly gets a reprieve. A published refusal list also shields the small engineering team whose capacity every accepted project silently assumes it can draw on.

Frequently asked questions

How do we choose between competing digital proposals?

Score each on the decision it improves, the evidence that the decision is presently made poorly, whether the required data actually exists, and who will own the result. Proposals unable to name a decision or an owner fall out straight away, which usually clears a large part of the list. Among what remains, favour those whose dependencies are already satisfied, since a proposal needing the network and the master data fixed first is really three projects wearing one name.

Should the plant or the group decide the digital roadmap?

Both, with the division stated explicitly. Groups sensibly standardise whatever must interoperate: identification, data definitions, platforms and security. Plants know which decisions hurt and which equipment can realistically be connected. Trouble starts when a group mandates an application without funding the site-level work it depends on, or when a site builds something the group will never support. Agree which layer is standard and which is local before either side commits money to anything.

What is the commonest reason a manufacturing digital programme stalls?

Master data that no longer matches the plant. Routings accurate once, work centres that no longer exist, machines named differently in three systems, and a bill of materials nobody has reconciled will defeat any application laid on top. It is unglamorous work no supplier wants to sell and no manager wants to fund, and it is the difference between a system people use and one they route around. Correct it before the software arrives.