Smart Factory Solutions: A Buyer’s Guide to Automation Software, Costs and Sequencing

Search for smart factory solutions and you get two kinds of answer. Consultancies sell a maturity model with five levels and no software. Vendors sell whichever module they happen to make. Neither tells you the thing a plant manager actually needs to know: what to buy first, what it depends on, and what breaks if you do it in the wrong order.

This guide is the sequencing.

What "smart factory" actually means in a purchase order

Strip the marketing and a smart factory is four capabilities stacked on each other. Each one only works if the one below it is real.

Connectivity: machines report what they are doing without a person typing it. Visibility: that data becomes a number a supervisor trusts, such as OEE, scrap or downtime by reason. Control: the system makes decisions, such as releasing work, holding a batch or reserving stock. Optimisation: the plan itself improves, because scheduling and quality learn from what the floor actually did.

The failure mode is buying level four while level one is still a clipboard. An AI scheduling engine fed by shift-end data entry produces confident answers about a factory that stopped existing eight hours ago.

Smart factory automation is not the same as factory automation

This distinction costs people money. Factory automation is robots, conveyors, pick-and-place: machines doing physical work. Smart factory automation is software removing the human decision and the human transcription between machines.

A plant can be heavily automated and not remotely smart: six robot cells, and a supervisor still walks the floor with a printout at 14:00 to find out whether the shift will make its numbers. Conversely a plant with mostly manual assembly can be genuinely smart, because every station reports in real time and the schedule reacts within the shift.

If your bottleneck is throughput per machine, you need automation engineering. If your bottleneck is that nobody knows the true state of the plant until tomorrow, you need smart factory software. Most factories diagnose the first and suffer from the second.

The order that works

Connect the machines first. Only the ones on the constraint. Native PLC drivers matter here because the alternative, a middleware layer per vendor, becomes its own maintenance project. Siemens S7, Allen-Bradley Logix, Mitsubishi MC, Beckhoff ADS, Omron FINS and Modbus cover most brownfield plants without touching the control programme.

Then make one number true. Pick one of OEE or on-time delivery and drive it until the shop floor stops ignoring the system and starts arguing with it. That argument is the milestone: it means people believe the data enough to care when it is wrong.

Then close a loop. Quality holds a batch automatically. Stock reserves itself against a work order. A downtime reason triggers a maintenance request. This is where a smart factory stops being a reporting project and starts changing outcomes.

Only then schedule and optimise. APS on top of live shop-floor state is a different product from APS on top of assumptions, even when it is the same software.

What each stage costs in weeks

Licence cost is the number everyone asks for and the least useful one, because it varies by plant size and deployment. The number that predicts success is elapsed time to the first believed report.

How many weeks each stage takes depends on scope; the order does not change. Machine connectivity on a defined line comes first, and its pace is set by physical access and network segmentation more than by software. Live OEE that supervisors act on comes next, and most of that time goes into agreeing what counts as downtime. The first closed loop follows. Scheduling on live data comes last, and it should.

A vendor promising a full smart factory in six weeks is describing an installation. Adoption takes longer. The software can be running in six weeks. The plant believing it cannot.

Where smart factory consulting helps and where it does not

Consulting earns its fee on two things: deciding what to measure, and rewriting the processes that the old measurement protected. It does not earn its fee producing a roadmap deck that no software can execute against.

A practical test before signing: ask what the consultant will change on the shop floor in the first month. If the answer is a workshop and an assessment, the engagement is a study. If the answer is a line connected and one report replaced, it is a rollout.

Buying for one plant versus buying for a group

The single-plant decision is about fit. The group decision is about sameness, and they pull in opposite directions.

Let each site choose locally and every plant gets software it likes, while group management gets a spreadsheet reconciliation exercise and a set of OEE figures that are not comparable because each site defines downtime differently. Standardise centrally and you fight local exceptions for a year, but a director in one country and a plant manager in another finally open the same figure, calculated the same way.

Groups that run one platform as a single standard across many plants and countries choose sameness deliberately, and pay for it in the first year of rollout rather than every year afterwards in reconciliation.

The four mistakes that strand a rollout

Digitising the paper when it should be removed. If the new screen has the same fields as the old form, nothing structural changed and the data will be just as late.

Starting where it is easy. The pilot line that runs well proves nothing and convinces nobody. Start on the line that hurts. That is where a real improvement is visible without a slide.

Buying modules that do not share a data model. Two systems that each hold "the" work order will disagree, and the reconciliation lands on a person.

Treating go-live as the finish. The plants that get value keep a small standing change budget for the year after go-live, because the second round of questions (the useful ones) only arrives once people trust the first round of answers.