ERP integration: what we learned moving shop-floor data into the ERP

ERP integration requests usually start out innocently: “Just get the production counts into the ERP.” By the end of the meeting the list has grown: downtime reasons too, scrap too, a shift report too, and could we see it on a phone as well? That is not a bad thing; once a factory starts seeing its data, wanting more is only natural. The problem is trying to squeeze those requests into the middle of a job whose price and schedule are already fixed.

What follows is what we learned on projects that carry shop-floor data into the ERP. Just as on the project where we write paint consumption to the work order gram by gram, we asked the same questions on every one of them, again and again.

First requests are always basic; then come the “and this, and that as well”. We don’t try to stop them; we put them on record. The specification has to spell out, item by item, which data is written to which ERP field, from which source and how often. What is out of scope, as much as what is in. We don’t go on site until we have planned very clearly what can be done and agreed on it.

The ERP is usually a system running on the factory’s local network, and the factory’s IT team puts any software that touches it through set security procedures. That is why the first technical meeting of an integration is with the IT team, not the ERP consultant: which server do we reach, through which port, as which user, with which permissions?

Transfer to a dashboard or to the ERP usually runs over a REST API inside the same local network, with access granted by the IT team. Some corporate firms have very strict security protocols: closed ports, restricted user rights, antivirus that quietly blocks services, updates waiting for approval. Even whether your computer runs Linux or Windows brings its own problems. Before going on site, we go through this list with the IT team:

• Which server, which port, which route: a REST API, the database or file transfer?
• Who owns the service account, with what permissions; when, and by whom, will its password be renewed?
• Which machine will run the middleware: Linux, Windows or a virtual machine?
• Will the antivirus, firewall or update policy affect the service?
• Is there a test environment, or will we write straight to the live ERP?
• Will there be remote access for installation and maintenance, or does everything have to be done on site?

Pulling data from a machine in the factory is a project separate from writing it to the ERP, and it is priced separately. If the machine’s own controller holds the data, it is read through the PLC; if not, sensors specific to the job are added: load cells, counters, encoders, current, temperature. Each sensor has its own communication protocol, and a PLC or an industrial PC collects the data. Choosing the right equipment is the heart of the job: a sensor more precise than needed eats the budget; one that falls short eats the data.

This is the most important question to ask. If all we do is pull the data, the software is an observer standing beside the machine; even if it stops, production does not. But if the software is part of the machine’s operating logic (sending recipes, starting work orders, releasing a lock), it is now part of production. Failure scenarios, safety and test coverage then move to a completely different scale.

The two should never be sold under the same quote. We ask the customer this outright in the first meeting and write the answer into the specification.

Office software shuts down at the end of the working day; software on the shop floor has no such luxury. Device communication drops, the ERP server goes down for maintenance, a network switch restarts, a sensor sends a meaningless value. Every one of these scenarios has to be designed in from the start: data must be buffered without loss, sent in order when the connection returns, and never written twice.

When something goes wrong, the warning has to go out the way the company wants it: an email for some, an SMS for others, a red line on the dashboard for others still. “There was an error, we logged it” means nothing on the shop floor; nobody reads that log.

No two companies want the same integration. Some just want to stop keying in the month-end report by hand, some want to watch production live, some want to run the machine from the work order. On the software side there are plenty of options; the job takes its shape from the customer. We weigh up the company’s overall need first and choose the architecture to match. An integration that starts small and grows almost always turns out healthier than one that tries to do everything from day one.