In most small and mid-sized manufacturers, the whole order is held together by a single printed sheet in a plastic sleeve. It travels with the material from the warehouse through cutting, machining and assembly to packing, collecting signatures, hand-corrected dimensions and a note saying "careful, complaint — do not use this batch" along the way. At the end of the week somebody re-types it into Excel so an invoice can be issued and work in progress estimated. This system works. It works right up until the sleeve is left lying on a different desk, or until a customer calls asking which melt the part that cracked came from.
Manufacturing automation in a plant like this does not start with a robot or predictive maintenance. It starts with a dull question: how many times is the same piece of information — order number, quantity, material batch, hours worked — written down again somewhere in the company? Usually four to six times: in the order email, in the ERP, on the work order, on the operator's timesheet, on the stock card and finally on the delivery note. Every re-entry is a place where a gap opens between what is on the shop floor and what is in the system. And that gap never closes on its own.
Where the data actually gets lost
Before talking about software, it pays to spend a day physically walking the flow of an order and marking every point where a person re-types something, makes a phone call or asks someone else. The typical finding looks like this:
- Order intake. The customer sends an email or PDF, sales re-types it into the ERP and keeps a parallel Excel of promised dates that production knows nothing about.
- Order preparation. The process engineer prints the drawing and work order, adds the routing by hand and sets operation sequence based on what he remembers about machine load.
- Shop floor. The operator writes the start and end of an operation on paper or in a notebook at the machine. Good quantity and scrap are filled in from memory at the end of the shift.
- Warehouse. Material issues are booked into the ERP in bulk every few days, so actual stock and system stock never match.
- Dispatch. The delivery note is written from the order rather than from what was actually produced and packed.
This is not carelessness on anyone's part. It is the logical consequence of none of these points having access to the same record. The difference between merely moving paper onto a screen and genuinely changing the flow of work is captured well by the distinction between digitisation and automation — and most failed projects stop at the former.
The work order as the single source of truth
The first real step is turning the production order into a digital object with a state, a history and one place of existence. Not a PDF on a drive, not a shared Excel — a record with a clear owner, to which events are appended: released to production, material issued, operation 20 started, 48 pieces booked, 2 scrapped, inspection passed, packed, dispatched.
The key rule is this: if a paper copy that someone treats as binding survives alongside the digital order, the project has failed. People will always trust whichever medium answers them faster. If that is the sheet on the table, they will update the sheet and the system becomes administrative overhead describing the past with a two-day delay.
In practice this means the digital order must also carry what people used to write in the margin by hand: the current drawing revision, the engineer's note, the concession agreed with the customer. If any of that cannot be entered into the system, paper will be back within two weeks.
Paper does not disappear because you deployed a system. It disappears the day the system is faster than a pencil.
Scheduling and priority rules
The second thing production needs before anything else is a comprehensible order of work. Most small firms schedule verbally — the supervisor allocates work in the morning based on who is phoning loudest. The system is not there to replace the supervisor, but to make the rules behind his decisions visible.
In practice, simple, explainable rules are enough: customer due date, material availability, a preference for finishing work in progress before starting something new, minimising machine changeovers. Sophisticated finite-capacity scheduling only makes sense once operation-time data is reliable — and you will only have that after several months of shop-floor capture. Deploying advanced planning on data that does not exist is the fastest way to lose production's trust.
The shop-floor terminal: an interface for gloves
This is where most projects fail. An operator interface is designed by entirely different rules than an office application, and normal web habits do not apply.
Practical requirements worth treating as a fixed brief:
- A shared terminal, not a personal account. A touch panel stands at the machine and the whole shift uses it. Login is a PIN or a card tap, not a username and a password with capital letters.
- Working in gloves. Touch targets must be large and well separated. Capacitive displays and thin gloves do not get along — verify the panel technology physically, not from a datasheet.
- At most three taps per action. Scan the order, confirm the quantity, book it. If an operator has to cross three screens to record scrap, he will not record it.
- One screen per activity. No dropdown with twenty items, no modal windows stacked on modal windows.
- Tolerance of network outages. The terminal must survive a few minutes offline and send the data afterwards, otherwise production stops the first time a switch reboots.
- Readable from two metres. High contrast, large type, order status distinguished by shape and not only by colour.
| Data capture method | What it handles | Where it fails | When it makes sense |
|---|---|---|---|
| Paper plus re-typing into Excel | Low entry cost, always works | Delays of days, transcription errors, no traceability | Very small operations, a handful of orders a day |
| Shared terminal with PIN and barcode scanner | Accurate operation times, booked quantities, scrap in real time | Requires discipline and physical infrastructure at the machines | Most small and mid-sized plants — the best benefit-to-cost ratio |
| Operator's phone or handheld scanner | Mobility, suits assembly and the warehouse | Loss and damage, charging, device management | Warehouse, dispatch, large-footprint assembly |
| Automatic capture straight from the machine | Data with no human involvement, exact cycles | High integration cost, older machines often have no interface | Bottlenecks and expensive CNC machines |
Most companies stop at the second row in the first phase, and that is the right call. Automatic machine capture is worth deploying deliberately on two or three critical workstations, not across the board.
Traceability, batches and quality
Once data is captured at the source, traceability stops being a separate project and becomes a by-product. The goal is to be able to answer three questions for every dispatched piece: what material and batch it came from, who made it on which machine and when, and what inspections it passed.
The practical minimum model is simple: goods receipt carries the supplier's batch number, the issue to an order links that batch to the work order, and booking an operation records the operator, machine and time. The result is a batch record that can be printed or sent to the customer without anyone assembling it by hand from three notebooks.
Non-conformances and what happens when something is off
A substantial part of the system's value lies not in how it handles a trouble-free order, but in what happens when something does not conform. Inspection must be able to block a batch in one action, the system must prevent its dispatch, and it must be obvious who decides what happens next — repair, rework, a concession agreed with the customer, or scrapping. If this gets handled outside the system by phone, the whole traceability story is decoration. The same logic applies to approval workflows inside a company: only decisions with a clearly assigned owner can be automated.
Connecting to ERP and dispatch
A production system should not replace the ERP and should not keep its own master data. The split of responsibilities that works in practice: the ERP or SAP owns customers, price lists, items, bills of materials and the accounting view of stock; the production system owns the progress of the order on the shop floor, times, scrap and traceability. Between them runs a two-way integration — order and BOM in; booked quantities, material consumption and work-in-progress status out.
Technically this is usually a REST API, file exchange, or in the case of SAP the standard interfaces; what matters is agreeing which system wins in a conflict and how a repeated message is handled. We covered the topic in more detail in the article on system integration of ERP, CRM and e-commerce, and it is closely related to stock and warehouse management, which in make-to-order manufacturing is often a bigger problem than the shop floor itself.
Dispatch is then merely a consequence. If the system knows what is finished, inspected and packed, the delivery note, labels and any material certificates are generated from the same data — not from the order, which describes the original intention, but from the actual result of production.
Adoption on the shop floor is harder than the software
This is the part buyers most often underestimate. Technically, nothing described above is difficult. What is difficult is getting someone who has written on paper with a pencil for twenty years to still be tapping the terminal three weeks after go-live — including when the shift is in full swing and something is on fire.
What helps: involving two or three operators in the interface design before development starts, running a pilot at one workstation rather than across the whole hall, switching the paper version off on a clear date, and above all giving the shop floor something back. If the terminal only collects data for management, it will be worked around. If it also shows what is next in the queue, where the material is and whether the drawing is the current revision, it becomes a tool that saves operators walking and asking.
And the uncomfortable point has to be said too: a process people do not follow on paper will not be fixed by digitising it. If nobody reliably records scrap today, the software will not start recording it — it will only make visible that it is not being recorded. That is useful, incidentally, but it is not what management ordered. This is why it makes sense first to choose which processes are suitable for automation and decide what the process should look like, and only then write it into software.
When this approach is a bad fit: in very small operations with a few orders a day, where the overhead of introduction outweighs the benefit; in a company currently changing its product range or technology, where the process has not settled; and when nobody in the company has the capacity to lead the project from the inside. In those cases it is more honest to wait or to start with a smaller step — for example, an in-house internal tool instead of Excel for a single agenda.
Summary
Manufacturing automation from order to dispatch is not one big system but the removal of every point where the same information gets written a second time. The sequence tends to be the same: a digital work order as the single source of truth, a visible plan, data capture right at the machine through an interface designed for gloves and a shared terminal, traceability as a by-product of that capture, non-conformances resolved inside the system, two-way integration with the ERP, and dispatch documents generated from the real result of production.
Technology is the easier half of this. The harder half is discipline on the shop floor and management's willingness to decide what the process should look like before the first line of code. If you are weighing up a step like this and would like to walk your order flow first and estimate what is worth automating initially, get in touch and let us go through the specifics.