Which process to automate first? The smallest sensible first step in manufacturing
- Published:
- Updated:
- Reading time
- 18 min read
- Author:
- Abbas Mohammadi
Process automation in manufacturing does not start with an MES project. It starts with a single shopfloor workflow that runs often, stumbles over media breaks, and whose data already exists. This article gives you a four-criteria scoring grid for choosing that process, and sets out what a pilot must contain so that it does not slide back into Excel and paper once it has gone live.
What process automation in manufacturing actually means - and what it does not
Process automation in manufacturing means that a recurring shopfloor routine runs from the triggering piece of information all the way to the booking in the target system without anyone retyping, re-copying or chasing it by phone. The trigger is an event in production: an order is scheduled, a measured value falls outside tolerance, a shift ends. The result is a record in the right place - in the ERP system, in a database, on a dashboard - without anyone capturing it a second time.
Type the term into a search engine and you land on software for holiday requests, invoice approvals and ticketing. That kind of back-office automation, and the Robotic Process Automation (RPA) that goes with it - a software robot clicking its way through existing screens - solves a different problem. Anyone automating manufacturing processes is dealing with controllers, gauges, job travellers and operators as data sources. The cost of an error is different too: a mis-booked job confirmation shifts the next schedule, a missing inspection record blocks the shipment.
A media break is any point at which information changes medium and is carried across by hand: from screen to paper, from paper into the ERP system, from the controller into a spreadsheet. Five workflows found in almost every discrete manufacturing plant serve as the frame of reference below.
| Workflow | Trigger | Data source today | Target system | Typical media break |
|---|---|---|---|---|
| Order release | Production order has been scheduled | ERP order table, bill of materials, drawing | Job traveller or terminal at the workstation | Manufacturing paperwork printed out, changes written on by hand |
| Changeover | Order change at the machine | Setup sheet, tool list, controller parameters | Machine parameters, setup time in shopfloor data capture | Parameters retyped from a folder or spreadsheet |
| Inspection record | Inspection characteristic falls due under the inspection plan | Gauge, inspection plan, operator entry | Quality database, inspection report for the order | Readings on paper, transferred into the system later |
| Job confirmation | Operation finished or interrupted | Operator entry, machine counter, fault reason | ERP booking, performance data (BDE/MDE, shopfloor and machine data capture) | Batched confirmation from memory at the end of the shift |
| Shift handover | End of shift | Shift log, fault reports, open orders | Shift report, maintenance order | Paper shift log, information lost between shifts |
Why large digitalisation programmes stall in mid-sized manufacturing
Most attempts at automation in mid-sized production fail on scope, not on willingness. In its KfW Digitalisation Report on the German Mittelstand 2025 (news release of 23 April 2026), KfW Research reports that only 30% of mid-sized companies recently carried out digitalisation projects - back to the level seen before the pandemic. KfW also finds digitalisation spending in decline, and the digital gap between large and small mid-sized firms still wide. That is a market figure across the whole Mittelstand in all sectors, not a statement about any individual plant; but it describes a pattern manufacturers will recognise.
The pattern runs - in stylised and simplified form - like this. A company sets out to "digitalise production". That turns into an MES selection project with several hundred requirements, run alongside the day job. After about a year there is a finished requirements specification and not one automated process; the next budget is cut. Small projects with a visible result within a few weeks keep the organisation in learning mode instead - and produce exactly the data foundation a larger programme will need anyway. The KfW figure points to a scoping problem, not an argument against digitalisation.
Which process first? Four criteria with a point score
The first process is the one that scores highest across four criteria taken together: frequency, media breaks, error costs and data availability. Each criterion is worth 1 to 5 points. The grid is no substitute for a business case; it sorts candidates in an hour and forces you to break down every shopfloor workflow you want to digitalise into trigger, data source and target system before anything else happens.
| Criterion | 1 point | 3 points | 5 points |
|---|---|---|---|
| Frequency | less than weekly | several times a week | several times per shift |
| Media breaks | none or one | two | three or more |
| Error costs per incident | rework under one hour | extra shift, scrap or a delivery date at risk | complaint, recall or several workstations standing still |
| Data availability | has to be captured first (paper, free text, not at all) | exists but needs structuring (spreadsheets, free-text fields) | exists in structured form (ERP table, PLC tag, database) |
The fourth criterion is the one most often underestimated. Whether a process can be automated depends less on the software than on whether the triggering information already exists as a record. Legacy machines without an interface do not rule a process out: in its retrofit primer, Mittelstand-Digital Zentrum Chemnitz describes how retrofitted sensors for temperature, pressure or speed make operating states visible and report them to higher-level systems over MQTT or OPC UA, right through to calculating overall equipment effectiveness (OEE). The routes for doing that are set out in retrofitting machine data. For a first step the rule still holds: a process whose data is already there beats one that first needs sensors fitted.
A hypothetical worked example for a machining shop with 40 employees shows how the grid behaves. The points are assumed, not measured.
| Process | Frequency | Media breaks | Error costs | Data availability | Total |
|---|---|---|---|---|---|
| Capturing inspection records | 5 | 5 | 5 | 3 | 18 |
| Confirming operations | 5 | 3 | 3 | 5 | 16 |
| Booking goods receipt | 3 | 5 | 3 | 3 | 14 |
| Shift handover | 5 | 3 | 3 | 1 | 12 |
| Transferring setup parameters | 3 | 3 | 5 | 1 | 12 |
How to read it: take the candidate with the highest total - but only if it scores at least 3 points on data availability. In the example the inspection record wins with 18 points. Shift handover is just as frequent, but its data exists only as free text in a paper log, so it becomes the second project. Where two candidates tie, the error-cost column decides, because it maps most directly onto the benefit.
Read as a decision tree, the same grid has four branches:
- Does the process run at least several times a week? If not, it is not a first project.
- Does the triggering data exist in structured form, or at least in a spreadsheet? If not, capture the data first, automate afterwards.
- Are there at least two media breaks, or error costs at extra-shift level and above? If not, the benefit will not carry a project of its own.
- Can one person from the shopfloor list every exception the process has? If yes, it is a candidate. If no, write the catalogue of exceptions first.
Data source, target system, exceptions: the three questions before any project
Before you ask anyone for a quotation, three questions should be answered in writing for the chosen process: where does the record come from, where does the result flow to, and which exceptions does the routine have. The first two take an hour. The third decides how much work the project will be.
- Data source
- The place where the triggering information arises today: an ERP table, a PLC tag, a form field, a paper document or free text. Note the format, the update cycle and who owns the data.
- Target system
- The place where the result takes effect: an ERP booking, a database table, a dashboard, a PDF in the order folder. Establish whether writing there is permitted - many ERP contracts allow reading through an interface but writing only through released functions.
- Exception
- Any case in which the operator departs from the standard route today: partial quantities, rush orders, missing drawings, rework, deliveries with no purchase order reference. In the project, every exception becomes either a rule in the system, a manual side route, or a case deliberately left out of scope.
The catalogue of exceptions is the real driver of effort. The standard case - order arrives, operator confirms, ERP books - is implemented in a few days. The ten special cases solved today with a note taped to the terminal consume the rest. Discover them only during test operation and you pay twice: once for the rebuild, and once in the operators' trust.
Catalogue of exceptions - working list to fill in
- Which cases depart from the standard routine? Ask three operators from different shifts separately - their lists will differ.
- How often does each exception occur: per week, per month, per year?
- Who decides today how the exception is handled, and how do they recognise it?
- Which exceptions get a rule in the system, which get a manual side route, and which are left out of scope?
- What happens to records with no matching rule: rejection, a collected list, or escalation to a named person?
- Which exception may stop the routine, and which is only logged?
- Who maintains the catalogue after go-live when new cases appear?
Four entry-level projects compared
Four projects come up again and again as a first digitalisation step in production: replacing a spreadsheet in production control, digital shift handover, paperless manufacturing paperwork and digital goods receipt. They are the standard examples of process automation in manufacturing, and they differ mainly in the preparatory work needed on data source and exceptions. Replacing a spreadsheet scores well on data availability, shift handover on frequency; paperless manufacturing paperwork touches many workstations and is therefore rarely the first project. The durations are rough guide figures for a pilot at one site, not a commitment - an incomplete catalogue of exceptions can double any of them.
| Entry-level project | Data source | Target system | Preparatory work needed | Pilot duration (range) |
|---|---|---|---|---|
| Replacing a spreadsheet in production control | Existing spreadsheet file, ERP order data | Database with a web front end, write-back to the ERP system | Document the columns and formulas, identify duplicated data entry | roughly 4-10 weeks |
| Digital shift handover | Paper shift log, fault reports, open orders | Shift report, maintenance orders, one metric per shift | Define mandatory fields, turn free text into categories | roughly 3-8 weeks |
| Paperless manufacturing | ERP production order, drawings, inspection plans | Terminal at the workstation, release and inspection records | Clarify approvals, signatures and retention periods, clean up drawing revisions | roughly 8-16 weeks |
| Digitalising goods receipt | Delivery note (paper or PDF), purchase order in the ERP system | Goods receipt booking, inspection order, label | Review supplier formats, define handling for deliveries with no order reference | roughly 4-10 weeks |
What a well-cut pilot project contains
A pilot is well cut when three things are settled before it starts: how its success will be measured, who will run it after go-live, and how it will be unwound if necessary. Those decisions cost an afternoon and prevent the most common form of failure: a system that runs but belongs to nobody.
Pilot acceptance - agree before the project starts
- Acceptance criteria in writing: which records must sit in the target system after the pilot with no rework, and what error rate is acceptable?
- A baseline before the pilot: measure the time taken and the number of errors in today's routine, otherwise there is nothing to compare against.
- A named operational owner after go-live - one person from production or work scheduling, not "IT".
- Training for every shift, not just the pilot shift.
- Rollback plan: how long does the old route stay available in parallel, who decides on reverting, and how is captured data preserved?
- An end date for parallel operation, after which paper or spreadsheets are no longer maintained.
- Rollout criterion: at what result is the process extended to further workstations?
- Works council informed and - where co-determination applies - involved before the system is introduced.
Co-determination: involve the works council early
As soon as a system is capable of monitoring the conduct or performance of employees, the Betriebsrat (works council) has a co-determination right. Section 87 (1) no. 6 of the Betriebsverfassungsgesetz (BetrVG, the German Works Constitution Act) expressly covers technical devices designed to monitor the conduct or performance of employees. A job confirmation with timestamp and operator ID, a shift log with names, a terminal recording setup times per person - all can fall under it. Do not rely on monitoring being unintended; settle the question with the works council before introduction. Whether a Betriebsvereinbarung (works agreement) is needed is for the works council and, if required, employment law advice - this article is not legal advice.
Why first automation projects fail
First automation projects rarely fail on the technology. They fail on five recurring gaps in how the project was cut. Each has a recognisable early warning sign and each can be closed before the start.
| Failure point | How you spot it | Remedy |
|---|---|---|
| Incomplete catalogue of exceptions | Notes taped to the terminal, "we will book that by hand later" | Gather exceptions from three operators separately; assign every exception to a rule, a side route or an exclusion |
| No owner after go-live | Change requests go to the supplier or quietly die | Name one person from production, with budgeted time and the authority to decide small changes |
| Integration treated as an afterthought | Results are exported as CSV and typed into the ERP system | Settle the target system and the write path before the quotation; a test booking into the ERP system is an acceptance criterion |
| A metric with no reliable data source | The dashboard shows figures the supervisor disputes | Show only metrics whose raw data is produced automatically; flag manual entries visibly |
| Parallel operation with no end date | Six months on, both the spreadsheet and the system are being maintained | Put a switch-off date for the old route in the project plan; rollback is possible only up to that date |
Where to go next: a sequence for the coming twelve months
A workable sequence runs from the smallest process with data already in place, through a second process that uses that data, to the integrated routine - not the other way round. Twelve months is a planning frame, not a promise; the duration depends on exceptions, interfaces and how available your own specialists are.
Month 1: score the candidates
Score five to eight processes with the grid in Tab. 02; for the best two, answer the three questions on data source, target system and exceptions in writing. Inform the works council.
Months 2 to 4: pilot on the first process
One process, one workstation or one line, with acceptance criteria and rollback agreed in advance. Result: a record that sits in the target system with no rework.
Months 4 to 6: rollout and switch-off of the old route
Extend to further workstations, set an end date for paper or spreadsheets, and hand the catalogue of exceptions to the named owner.
Months 6 to 9: a second process on the same data
If you automated job confirmations first, you can now pre-populate the shift handover with the open orders. The second process is cheaper because the data source and target system are already known.
Months 9 to 12: decide on the integrated routine
Only now can the question of MES, ERP extension or a bespoke application be answered with facts: you know your exceptions, your data sources and the effort per process.
Whether standard software or a bespoke application is the better choice for an individual step depends less on price than on how unusual your catalogue of exceptions is. If a standard module - the shopfloor data capture module of your existing ERP system, say - covers the process including its exceptions, it is almost always preferable. If a third of the cases fall outside it, the customisation costs more than a small, well-fitted application. The criteria are set out as a decision matrix in standard software or custom software.
Conclusion: start small, but start complete
Process automation in manufacturing starts with a process that runs often, stumbles over media breaks, and whose data already exists. The scoring grid finds that process in an hour; the catalogue of exceptions, a named owner and a rollback plan keep it alive after go-live. Everything that follows - rollout, second process, integrated routine - builds on the data this first step produces.
If you have scored your candidates and want a second opinion on data source, target system and exceptions: ralwo offers a free 30-minute initial consultation for exactly that; what it covers is described under process automation.
Frequently asked questions
Sources
- KfW Digitalisation Report on the German Mittelstand 2025 [KfW-Digitalisierungsbericht Mittelstand 2025] — KfW Research
- Section 87 BetrVG - co-determination rights [§ 87 BetrVG - Mitbestimmungsrechte] — German Federal Ministry of Justice / gesetze-im-internet.de
- Retrofit basics: digitally upgrading old machines [Retrofit Grundlagen: Alte Maschinen digital nachrüsten] — Mittelstand-Digital Zentrum Chemnitz