Digital Transformation in Manufacturing Is a Sequencing Problem, Not a Technology Problem

Sequencing is the hard part, and the part vendor material skips, because the honest version means telling a customer to buy less this year. This page is that order.

Why digital transformation projects in manufacturing stall

Four causes account for most of them. All four are programme failures rather than product failures, which is the point: they are the ones a plant controls. Software does fail on its own terms, and that list belongs in the procurement: transaction design, performance at scale, a vendor whose engagement ends at go-live.

The first is a sponsor with no owner beneath them. A sponsor approves a budget and attends a monthly meeting; an owner has floor time, authority to change a process, and a personal outcome attached to whether the plant runs differently in a year. The second is a business case that assumes data which does not exist, so a plan to analyse downtime meets a free-text column on a shift sheet. The third is a pilot never built to scale. The fourth is buying a platform before knowing the question, so the plant owns a capable system with no first use.

How to choose the first digitalisation project

The first project should come from the plant's constraint, not from the module list. In most factories the loss is unglamorous: changeovers longer than the standard, material that cannot be found, two-minute stops nobody reports.

Three questions filter candidates quickly. Does the loss already appear in the plant's own accounting, as scrap, overtime, expedited freight or a late-delivery penalty? Would someone act differently within the same shift if they had the answer? Can you tell within one production cycle whether it worked? Cycle rather than quarter: three months is a fair test in high-mix repetitive work and meaningless in aerospace or a pharmaceutical campaign, where the unit is one campaign or one order.

Software is sometimes the wrong answer: if the constraint is physical, no data will make the machine faster. What measurement does is show where the capacity goes, and that usually redirects the capital request rather than confirming it. The candidate machine's own running time looks worse than anyone believed, once short stops are counted, and yet most of the hours it lost were not its own: it was starved from upstream, blocked downstream, in changeover, or waiting for an operator covering two stations. The machine was never the constraint, and the money belongs elsewhere.

What to measure before you start, so you can prove the change later

The trap is definitional. Before go-live, availability comes off a shift sheet where short stops are not written down; afterwards, stops are detected automatically, so measured OEE falls because losses that were always there are finally counted. If nobody recorded the old definition and the old number, month three looks like a regression, and the programme spends its credibility defending itself.

So write out the current number and its definition in full: the time base the percentage uses, where the ideal cycle time comes from, how downtime is classified, whether planned maintenance is excluded, and how rework is treated. The first two decide most of it: calendar, scheduled and manned time give the same plant three different figures from identical data, and the ideal cycle time is nameplate, best demonstrated, or a routing number set once and never revisited.

Then capture the facts that are harder to redefine and can be reconciled to finance: units shipped, hours paid against hours run, order lines delivered late, credit notes and overtime. Harder is not impossible, so freeze the definition and source system for each alongside the OEE definition. On-time delivery needs its own written decision, because the date basis is the most re-argued definition in any plant: original commit or last revised date, order or line, despatch or receipt.

What comes first: connectivity, master data, then analytics

Connectivity and master data sit underneath everything, analytics sits on top and is worth what those layers are worth, and master data is the dependency consistently underestimated. An execution system cannot dispatch an operation missing from a routing, and a scheduler cannot sequence without standard times somebody measured this decade. So before committing to a date, count the parts with no routing, the round-number standard times, the locations that exist in practice but in no system, and the duplicated bills of material.

The other seam to scope at the beginning rather than the end is ERP integration, where the difficulty is agreement, not code: what a confirmation means on each side and whether the floor posts it or a back-flush does, how partial quantities and order splits land, what happens to a reversal once material has moved, where scrap posts against standard cost. Each answer is a decision between departments that have never had to agree.

Two long-lead dependencies rarely appear on a technical roadmap. An execution record that attributes output, stops and scrap to a named operator is, in Germany and much of Europe, a system capable of monitoring individual performance, so it needs a works agreement negotiated with the works council before go-live. Approval takes months, so start it in year one alongside master data. The substance is short: whether operator identity is stored at all, who sees it, for how long, and whether reporting is aggregated by design.

The second applies to regulated production. In pharmaceuticals, medical devices and much of food, a system that records or enforces a quality disposition is validated scope: validation plan, qualification, audit trail, signature obligations, slower change control afterwards. Reporting, downtime capture and scheduling sit outside that line; batch hold, disposition and the model version an inspection system uses sit inside it. Scope it before the module is bought, because validation is often the longest single item in the programme.

Why MES comes before APS, and quality data before AI quality prediction

Give advanced planning yesterday's assumption about where the work is, and the sequence gets re-sorted by hand before the shift starts, the planner is back in the spreadsheet within weeks, and the verdict is that the scheduling software was bad. It was not bad, it was blind.

Live inputs make a schedule feasible, not runnable, and that gap is where most APS disappointment lives. A schedule on perfect data is still ignored if it optimises the wrong objective, minimising setup while the plant is judged on due dates; if secondary constraints are missing, since real sequences are decided by tooling, the skill matrix and shared labour; or if nothing is frozen, since an optimiser re-solving continuously hands the supervisor a new plan every time they look. Agree a frozen period, and let the optimisation churn outside it.

Quality prediction has the same shape: a model forecasting scrap needs scrap recorded at the operation where it happened, with a cause and process context, from machine and tool to material lot.

Maintenance has a distinction that gets sold past. Anomaly detection on vibration or current signatures runs without failure history, which is not the same as running without data: it needs weeks of healthy-state data covering the full operating envelope, or it alarms on every changeover instead of on damage, and sensors mounted and sampled for the fault modes you care about. Even then it only says something is unusual, and knowing which anomalies mattered needs work order history with failure modes.

A camera showing pass or fail on a screen has not changed the plant either: the verdict has to attach to a work order, a batch and a model version inside the execution and quality record, which makes inspection a late capability rather than an entry point. Separate guides cover finite capacity scheduling, what an APS schedule has to satisfy, and where a CMMS ends and predictive maintenance begins.

Who runs the programme, and why operators resist shop floor data entry

IT is a partner, not the owner: when IT owns the programme it optimises for integration and security, does those well, then stalls at adoption, because nobody in that line is accountable for whether an operator uses the screen. Underneath the owner sit the key users, one per area, named, with allocated hours: they decide what a screen asks for and in what order, and the floor listens to them.

The stated obstacle to adoption is almost always people; the real obstacle is usually the design of the transaction. Watch a confirmation during a changeover, gloves on, next order waiting. If entering a stop reason changes nothing visible, the entry is a tax on the shift, paid as late as possible and usually as a batch of fiction at the end. If it notifies maintenance, updates the shift board or re-sequences the next order, it becomes part of the job.

Good entry design is specific: terminals at the machine, one-handed gloved operation, defaults pulled from the order, and a short reason list per machine type rather than a taxonomy where only a handful of codes get used. When the transaction fits the job, training is short enough to do at the machine during a shift. When it does not, no amount of classroom time fixes it, and a request for more training is often a design problem misdiagnosed as a people one.

Two things are missed in most training plans. The first is corrections: confirming a good quantity is easy to teach, while reversing a wrong one or unpicking a confirmation booked against the wrong order is where an untrained user does real damage. The second is that training is not an event, because supervisors need more than operators, and new starters, agency staff and a multilingual floor arrive continuously.

Scaling a pilot to the whole plant: what makes a pilot copyable

Pilots fail to scale for reasons designed into them: the best line, the old machines avoided, the vendor on site daily, master data curated by hand. A pilot built to scale runs on a representative line, includes at least one awkward asset, and records hours per line, because that unit cost is the only honest input to the rollout plan.

Exit criteria and a rollout decision date are agreed before the pilot starts, and the closing stretch runs without the vendor. What matters about that stretch is its coverage rather than its length, because pilots rarely fail during ordinary running. They fail at the first period-end close, when figures must reconcile to ERP and somebody finds scrap posted twice, and at the first restart after a shutdown, when the gateways come back but the buffered counts do not. So specify coverage: one period-end close with its reconciliation, the full product mix that line runs, and one planned stop and restart. In most plants that is a month or one full cycle, not a fortnight.

What a digital transformation budget covers, and the run rate afterwards

The licence is the line negotiated hardest, and the lines that decide the outcome are elsewhere: integration to ERP and to machines; hardware, from gateways and panels to retrofit sensors; master data cleanup; training and the production time it consumes; and internal effort. Internal effort is the line most often omitted: key users, the owner, IT, technicians fitting gateways, lost production at cutover. If nobody has costed those hours, the budget is wrong however well the licence was negotiated.

The physical work splits into two categories that schedule differently. Cable runs, switch ports and segmentation between control and business networks are ordinary engineering with long lead times, and can proceed alongside production. Anything inside a machine cabinet cannot: that is isolated work, requiring lockout and tagout and a planned stop, and in most plants a standing ban on opening an energised panel. So the real constraint on the connectivity schedule is how many shutdown windows remain this year and how much of each maintenance has claimed. Connectivity is planned against the maintenance calendar, not the software plan.

Then the run rate, which no project budget contains and the finance director asks for first: the cost in year four. Subscription or annual support continues, and industrial panels and gateways wear out faster than office hardware. Most of all, somebody internal runs the system once the vendor leaves: master data upkeep, reason code and routing changes, user administration, taking each release. Budget separately for change in the twelve months after go-live, because the requests worth funding arrive only once the floor believes what the system tells it.

How to sequence a three-year smart factory roadmap

A calendar adds what the dependency order cannot: who decides at each boundary, and how money and hours phase. Year one settles the decisions expensive to revisit, and the owner settles them with finance, IT and the works council rather than the project team: KPI definitions, master data structure, the ERP seam, operator identity, and, in a regulated plant, validation scope. Internal effort peaks here relative to licence spend, so a budget shaped like a conventional IT project is already wrong. One item belongs in year one that plants defer: metering the largest electrical loads to establish a baseline, which is instrumentation rather than modelling, and often non-discretionary under an energy standard or audit.

The boundary into year two is a judgement, not a date, crossed when the floor argues with the system's number instead of ignoring it. Closing a loop means a supervisor or quality manager hands a decision to a rule, so that scope is negotiated with the people whose authority moves, and spend shifts from internal hours towards licence and integration. Year three earns the model-based layer on two years of record, and its boundary condition is ownership: each capability needs a named person owning the threshold and the retraining schedule. Energy attributed per part belongs here, because attribution needs the execution record the first two years built.

Two stop conditions belong in the approval. If the floor does not trust year one's data, year two does not start. And pulling year three forward because a board asked for an AI initiative produces the stalled project described at the top of this page.

How to know whether to continue: gate criteria for each stage

Each stage needs a gate with evidence you could show a sceptic. After connectivity, does captured production match a manual count over a full shift, within a tolerance agreed before the test. After the first reported number, is the old spreadsheet still maintained alongside it; when it quietly stops being updated, the number has been accepted.

One gate belongs with the first execution go-live and is almost always skipped: what the line does when the system is not there. Once operators confirm at the machine and quality holds batches by rule, a failed switch or interface stops production: the plant has traded a clipboard for a single point of failure. So define and test the degraded mode first: what the terminal buffers locally and for how long, what the paper fallback is, who may authorise running without the system, and how the backlog is re-entered without double-counting. Test it by pulling the connection during a running shift, because untested failover is the ordinary reason a go-live becomes a production incident.

After the execution record, can you reconstruct one order, including stops, scrap and who ran it at the identification level agreed, without asking a person. Before planning, is work in progress accurate at the start of a shift. One trend matters more than any single gate: if each new line costs what the last one cost, the programme has built bespoke installations rather than a method.

Where Meta Smart Factory fits

Meta Smart Factory covers the layers above as separate modules, from MES, MRP and APS through quality, maintenance, warehouse and vision to ERP integration. Modularity makes that sequencing purchasable, but the first purchase is not just a module. It is one module against one named constraint in one area, plus the foundation underneath it: connectivity, master data cleanup, the ERP seam and the agreed definitions. That foundation is most of the first year's effort and appears on no price list, so it belongs in the approval as its own line, not assumed inside a licence.

The hard parts survive any platform choice. Settling what the numbers mean, cleaning master data, designing transactions operators will complete without being chased, and choosing what to stop doing are shared work. If that is where you are, a conversation about sequencing for your constraint beats a product demonstration.