A sensor does not make a business decision on its own. Industrial IoT creates value when a signal is verified, given context and used to trigger a defined action in ERP or a maintenance system. If temperature, vibration or cycle count does not change an operator procedure, a maintenance plan or a work order status, the company has collected data but has not closed the business process.
Industrial IoT, or the internet of things in manufacturing, should therefore start with one question: what will we do differently when data crosses a defined threshold? That question determines which sensors should be installed, which data should be retained and what the ERP integration needs to deliver.
A raw value is rarely enough to support a decision. A temperature reading, for example, has limited meaning without answers to several questions:
The data path may look like this:
sensor -> gateway -> local processing -> IoT platform -> business rule -> ERP or maintenance system -> human decision
A gateway collects data from sensors and forwards it to other systems. Local processing, often called edge processing, performs part of the filtering or assessment close to the machine. This can avoid sending every raw reading onward, while an immediate response does not need to depend on a permanent connection to a central system.
However, the technical path alone is not enough. Every handoff needs an owner and a method of verification. If a gateway stops sending data, the system should not silently assume that the machine is operating normally. A missing signal may indicate a connection failure, a sensor fault or an unknown condition. The business rule needs to distinguish between these states.
IoT systems often expand faster than the processes that can use them. It is therefore more useful to choose one event that occurs often enough to test and matters enough to change work than to connect a large number of machines immediately.
That event might be:
Before purchasing or configuring sensors and an ERP integration, document the decision in operational terms:
This record prevents a common failure mode: a technically valid signal reaches a dashboard, but nobody is responsible for responding and it is not clear whether the response changed the process outcome.
Sensors and ERP should exchange data selectively. ERP is not necessarily the place for every millisecond of raw measurement. The business system generally needs the event, a summary, the time it occurred, the data quality status and a link to details when analysis is required.
Connecting a signal with a work order, item, operation, shift, material and plan changes the meaning of the same reading. A higher temperature may be expected during one operation and a deviation during another. A cycle count may matter for maintenance only when the relevant machine, assembly and maintenance plan are known.
A practical flow can be as follows:
For connecting production events with orders, operations and other business data, see ORKA for manufacturing and Business modules connected to ERP . The starting point remains the process: integration should serve a decision, not merely increase the volume of available data.
Local processing close to the machine is useful when a response must be fast, network connectivity is unreliable or the volume of raw data is high. It can filter data, mark a communication interruption and keep a short-term response close to the process.
A central IoT platform or cloud layer is useful for retaining history, comparing multiple machines or locations, and connecting events with business data over time. This does not mean that everything needs to sit in one layer.
A hybrid approach often has a clear operational purpose:
The choice depends on the consequence of delay, connection availability, the necessary volume of data and the decision the process needs to support. There is no useful general rule that every signal must end up in the cloud or in ERP.
A value that looks correct is not necessarily reliable. A sensor may lose calibration, become physically damaged or operate in conditions that change measurement quality. For every relevant reading, it is therefore useful to retain the time, device identity, device status and a signal quality label.
It is equally important to define in advance what happens when data is missing or late. Depending on the process, an automatic action may stop, the process may move to a safe default value or the system may request operator confirmation. What matters is that an unknown state is not presented as a normal state.
Devices are also part of the organization's security surface. An industrial IoT plan should cover device identity, secure updates, network segmentation, certificate management and the lifecycle from installation to retirement. A device without an owner, a documented maintenance method and a retirement decision can become a weak point in an important process over time.
Data ownership should be agreed between production, maintenance and IT. The answers to these questions should not remain unclear:
A pilot is not complete when data reaches a screen. It is complete when the organization can show which decision the signal changed and how that decision was recorded.
For one selected event, track at least:
These records provide a basis for adjusting thresholds, improving signal quality and deciding whether to expand to other machines. Without them, it is difficult to distinguish a useful event from an additional source of noise.
Start with one signal and one business decision. If you cannot name the person who will respond, the data that confirms the context and the way you will measure the change, it is too early to expand the number of devices. When the process is ready, ERP and process screening can help structure the decision, data ownership and integration scope before a broader implementation.