A packaging line stops for twelve minutes. The operator clears a misfed carton, restarts the machine and returns to work. By the end of the shift, the same fault has occurred six more times. Production reports show lower output, maintenance records one short intervention, and the planning system still assumes that the order will finish on schedule.
All three records describe the same production day, yet none provides a useful account of what happened.
This is the kind of problem smart manufacturing is supposed to solve. The aim is to connect events on the factory floor with enough operational context to support a decision. In this example, the company might need to identify the recurring fault, calculate the lost production time and determine whether the cause lies in the machine, material, settings or operating procedure.
Installing sensors or purchasing an analytics platform will not answer those questions by itself.
What smart manufacturing means in practice
Smart manufacturing uses production data, connected systems and analytical tools to improve the way a factory is operated. Information may come from machines, PLCs, quality systems, maintenance applications, production orders or manual operator input.
The US National Institute of Standards and Technology describes smart manufacturing systems as adaptive systems built on cyber-physical infrastructure and data analytics. NIST’s work in this area covers real-time performance optimisation, production planning and the exchange of information across manufacturing systems. (NIST)
In a working factory, the term can cover projects of very different sizes. One plant may collect cycle times from three critical machines. Another may connect production lines, warehouses and business-planning systems across several sites. Both projects can qualify as smart manufacturing if the collected information changes how operations are monitored or controlled.
The presence of artificial intelligence is optional. A simple rule that alerts maintenance after three similar faults within an hour may be more useful than a predictive model trained on incomplete records.
Traditional automation usually controls a defined process. A PLC opens a valve, moves an axis or stops a machine when a safety condition is breached. Smart manufacturing extends the flow of information beyond that individual control task. The machine event can be linked to the current order, product, material batch, maintenance history and production plan.
That additional context is where much of the value lies.
From machine signals to usable information
Factories already generate large amounts of data. The difficulty is deciding which data deserves attention and what it means.
Suppose a machine controller reports the status “stopped”. That status says nothing about the cause. The machine may be waiting for material, undergoing a planned changeover, blocked by equipment farther down the line or shut down after a fault. Treating every stopped state as unplanned downtime produces an impressive dashboard and unreliable conclusions.
A useful record would include the start and end time, operating mode, active order, product, fault code and reason for the interruption. Some details can be collected automatically. Others may require an operator to select a reason, ideally from a short and well-designed list.
This creates an ordinary organisational question: who is responsible for the definition? Production, maintenance and IT may use the word “downtime” differently. The calculation has to be agreed before anyone builds a report.
Data also needs to move between systems. ISA-95, published internationally as IEC 62264, provides a commonly used framework for describing the relationship between factory equipment, control systems, manufacturing operations and enterprise planning. It helps teams define which information should pass between production systems and applications such as ERP. (ISA)
The standard does not prescribe a particular software brand or plant architecture. Its practical value is the common vocabulary it gives to engineers, operations staff and IT teams. During an integration project, that vocabulary can prevent a supplier from treating every interface as an isolated custom development.
The technology behind a smart manufacturing project
The technical design depends on the problem being investigated.
A relatively new machine may already provide production counts, cycle times and alarms through an industrial communication interface. An older machine might expose only a few electrical signals. It could require an additional sensor, gateway or carefully planned change to the control system.
Collecting the signal is the first step. The project still needs a way to store it, add context and make it available to the people who can use it.
A typical installation may involve:
- PLC or SCADA data from the production line;
- an MES or another manufacturing-operations application;
- maintenance and quality records;
- order and product information from ERP;
- a database or industrial data platform;
- reports, alerts or analytical models.
This does not mean that every factory needs all these components. Adding a plant-wide MES to investigate one unstable process may produce more expense and disruption than the problem justifies. At the other extreme, a temporary spreadsheet filled through manual exports will rarely support continuous operational decisions.
Response time affects the architecture as well. A management report prepared each Monday can tolerate delayed data. An alert intended to prevent a batch from moving outside its process limits cannot.
The same principle applies to cloud systems. Cloud services can simplify storage, analytics and access across several sites. A production process should not become unsafe because an external connection is unavailable. The design has to account for latency, outages and the functions that must continue locally.
What can a manufacturer improve?
The business case should begin with a problem that already has a visible cost.
Unplanned downtime is a common starting point because production losses can often be estimated. Quality inspection is another. A company may also investigate energy use, maintenance intervals, changeover performance, production reporting or schedule adherence.
The expected result needs a precise definition. “Improve productivity” is too broad for an investment decision. “Reduce unplanned stops caused by carton misfeeds from 18 hours to 10 hours per month” can be measured.
Consider a line that loses around 200 production hours a year to recurring faults. The finance team estimates that each lost hour reduces contribution margin by €600 after allowing for production that can be recovered on later shifts. The apparent annual loss is €120,000.
That number still requires examination. Some orders may be produced later without overtime. A portion of the downtime may have unrelated causes. The proposed system may detect faults without preventing them. A credible business case adjusts for these limitations.
If the company expects to recover half of the loss, the estimated gross benefit is €60,000 a year. Further savings may come from lower scrap or fewer emergency maintenance interventions, provided they can be measured separately.
The investment calculation should include more than hardware and software. Integration work, engineering time, production interruptions, training, cybersecurity, support and future licence costs all belong in the estimate. So does the time operators spend entering information.
A simple payback calculation is useful during the first assessment:
Annual net benefit = verified annual savings − annual operating cost
Simple payback period = initial investment ÷ annual net benefit
If implementation costs €100,000, annual support costs €10,000 and measured savings reach €60,000, the annual net benefit is €50,000. The simple payback period is two years.
Real projects rarely follow the estimate exactly. Savings may increase after operators learn to use the system, or disappear when production volume and product mix change. For larger investments, the company will usually need a discounted cash-flow model and several scenarios.
The baseline matters more than the sophistication of the formula. When the original loss was estimated from inconsistent shift reports, a precise return-on-investment percentage creates false confidence.
Why implementations stall
Many smart manufacturing projects work during a demonstration and then struggle in normal production.
One reason is dependence on a single employee. An engineer may build a useful dashboard by manually correcting machine names, combining exports and removing invalid records. Management sees the finished report, while the hidden preparation work remains undocumented. When the engineer changes role, the dashboard stops updating.
Pilots also avoid some of the conditions found at scale. Connecting one recent machine says little about the effort required to connect forty machines from six suppliers. Software licensing may change when the second production line is added. Network capacity, user administration and support responsibilities become harder across several plants.
Data quality problems appear quickly. Counters reset. Clocks are not synchronised. A product code is written differently in two systems. Operators choose “other” as the reason for every stoppage because the available options do not match their work.
These are operational design problems, not minor cleaning tasks. A useful pilot should reveal them.
Another source of failure is the relationship between the project team and production staff. Operators are sometimes shown a finished interface shortly before launch. If it creates extra work or reports their actions inaccurately, they will find a workaround. Maintenance technicians may receive alarms without enough information to act, leading them to ignore the system after a few weeks.
The people using the result should help define it. An operator can often explain in ten minutes why a proposed downtime classification will fail during a changeover.
Cybersecurity cannot be separated from integration
A machine that was previously isolated may become reachable from other parts of the organisation after integration. Remote support, cloud connections and shared user accounts can introduce additional paths into the operational environment.
Before connecting equipment, the company needs an accurate inventory of its operational assets and the relationships between them. This includes controllers, industrial computers, engineering workstations, network equipment, software versions, external connections and accounts with elevated access.
CISA’s guidance for operational technology recommends classifying assets according to their criticality and applying controls such as network segmentation and role-based access. It also stresses the need to understand dependencies between IT and OT systems. (CISA)
Segmentation is especially important when production equipment contains older operating systems or cannot be patched during normal update cycles. It limits communication between zones and reduces the chance that a compromise in the business network will spread directly to industrial systems.
Backup and recovery plans need operational testing. A database backup is of limited use if nobody knows how long restoration will take or whether the plant can run safely while the system is unavailable.
These requirements add cost. Leaving them until the end does not remove the cost; it usually makes redesign more expensive.
Choosing a sensible first project
The first project should be large enough to matter and small enough to understand.
A good candidate has a recurring problem, an identifiable process owner and a metric that can be measured before implementation. The required data should be available from a manageable number of systems. There should also be a plausible action once the information is produced.
A useful preparation process begins with a walk through the production area. Observe the work, review existing records and speak with operators and maintenance staff. Then map where the relevant information is created and how decisions are currently made.
The company can use those findings to write a short project definition:
- the operational problem;
- its current frequency and cost;
- the affected process and equipment;
- the decision that needs better information;
- the data required;
- the expected result;
- the method and date of evaluation.
The NIST Manufacturing Extension Partnership recommends assessing the current situation before selecting technology, identifying the processes where technology could have the greatest effect, developing a business case and measuring the results after implementation. (NIST Manufacturers’ Guide)
Supplier demonstrations should use the manufacturer’s own problem and data whenever possible. A polished presentation based on ideal sample data reveals little about integration with the actual production line.
The pilot should also have an exit condition. If the data cannot be collected reliably, operators reject the workflow or the expected savings prove too small, stopping the project may be the correct result.
Questions to answer before approving the investment
Management should be able to obtain clear answers to a few practical questions.
What happens differently when the system detects a problem? Who receives the information, and how quickly must that person respond? Which production metric should change? Who verifies the result?
The technical team should explain where the data originates, how it is interpreted and which interfaces have to be maintained. Production should confirm that the proposed workflow reflects what happens during a normal shift. IT and cybersecurity staff need to understand every new connection to the operational environment.
Finance should see the assumptions behind the savings estimate, including the production volume, value of recovered capacity and ongoing operating cost. Benefits that cannot yet be measured can be described, though they should not quietly appear in the return calculation.
One final test is particularly useful: ask the project owner to describe what the new system will change on an ordinary Tuesday morning.
If the answer concerns a specific decision made by a named role using defined information, the project may be ready for a pilot. If the answer consists mainly of dashboards, AI and “greater visibility”, the business case still needs work.
