Start with a handover between systems that comes back every day and follows fixed rules. Think of orders from email that have to go into the ERP system, or a check whether the revisions in PDM and ERP still match. Choose the process with the best balance between return and risk, not the process with the most pain, and keep it small: one order stream that first comes in as drafts, or a check that only reads. Technical decisions, such as whether a special (a customer-specific product) can be made, stay with your people.
This article is about digital business processes and information flows, from engineering to administration and from order to delivery. Controlling production lines, PLCs (the control computers of machines) and industrial robots is a different field: industrial automation. MeeuseSolutions does not do that.
Where the manual work sits in a manufacturing company
An order in the manufacturing industry passes through several systems. At each transition, someone retypes or checks data. You almost always come across three systems:
- ERP (enterprise resource planning): customers, items, bills of materials (BOMs), operations, orders, planning, purchasing, stock and invoicing.
- PDM (product data management): 3D models, drawings, revisions and their release by engineering.
- CPQ (configure, price, quote): software that configures a product, calculates the price and creates the quote.
Around them are Excel lists, mailboxes and the portals of customers and suppliers. In many SME manufacturing companies, these systems were chosen at different times and do not talk to each other. The connection between PDM and ERP is then a process planner who retypes a BOM.
Each role sees a different part of the same manual work:
- The engineer releases a drawing and later gets questions about a BOM in the ERP that no longer matches.
- The process planner retypes BOMs and collects the right drawings for each production order.
- The operations manager sees orders fall behind and is not sure whether the shop floor works with the right revision.
- The IT manager manages systems that do not talk to each other, and gets the questions when an Excel macro or an export stops working.
- The finance lead sees differences between quote, order and invoice, and purchase invoices for subcontracted work that someone checks by hand.
| Handover | From and to | What now happens by hand | As a first step? |
|---|---|---|---|
| Customer order comes in | Email (PDF, Excel) to ERP | Looking up the customer, checking items and prices, retyping lines | Often good, with reasonably fixed formats |
| Quote becomes order | CPQ to ERP | Copying customer, configuration, prices and delivery date | Good for standard configurations |
| Drawing is released | PDM to ERP | Creating the item, building the BOM, updating the revision | Only once the master data (the basic data about items and customers) is in order |
| Order goes to the shop floor | ERP to process planning | Creating production orders, attaching drawings and work instructions | Good for products with a fixed routing |
| Subcontracted work | ERP to purchasing and supplier | Creating a purchase order, sending the right drawing, tracking the confirmation | Often good |
| Comparing systems | PDM, ERP and CPQ | Putting lists side by side for revisions and prices | Very suitable: only reads |
Process planning is partly skilled work and partly administration. The skilled work is deciding how something is made: which operations, which machine, which times. The administration is creating production orders, attaching drawings and checking whether the material is available. You can often automate that second part, certainly for products with a fixed routing (the defined sequence of operations).
In the handover from CPQ to ERP, the distinction between standard and special matters most. A standard configuration produces a known item or a known BOM, and software can create that as an order. A configuration that is marked as a special first goes through engineering. A useful check afterwards: is the order total in the ERP equal to the quoted amount?
When you buy in subcontracted work, such as laser cutting or powder coating, every operation needs a purchase order with the right drawing in the right revision. Creating that purchase order, attaching the drawing from PDM and tracking whether the supplier has confirmed are fixed steps. The choice of supplier and the discussion about lead times stay with purchasing.
The release in PDM comes with a clear moment. In a PDM system, a document usually passes through states such as "work in progress", "for review" and "released". In Autodesk Vault, for example, a revision is a marked milestone, usually with a letter such as A or B. An administrator can set up the system so that a state change automatically creates a new revision. Such a state change is a logical starting point for an automation.
Why it is harder in a manufacturing company than it looks
- The master data is not clean. Material codes in PDM differ from those in the ERP, item numbers have historical exceptions and units differ. A person corrects that without noticing. An automation gets stuck on it.
- Many specials. The larger the share of customer-specific products, the more cases have to go past a person. An automation for only the standard cases can still pay off, if the rest reaches the right person properly.
- Revisions and timing. What happens to open orders when a new revision arrives? That agreement is often not on paper, and it has to be clear first.
- Older or customised ERP systems. An ERP on its own server with a lot of customisation does not always have a usable integration. Then a software robot (RPA, robotic process automation: software that operates the screens like an employee, so not an industrial robot) is an option, with the limitations that come with it.
- Ownership. Who owns the product data: engineering or process planning? Without an answer, nobody knows who resolves an exception.
How do you choose the first process?
List the candidates and look at two things: how much manual work they contain, and how suitable the work is. Calculate the manual work like this: number per week × minutes per time × working weeks per year ÷ 60 = hours per year. Then give each candidate a score from 1 to 3 on three points:
- Rules: can you write out the decisions? (1 = a lot of judgement, 3 = completely fixed)
- Input: does the input arrive in a fixed form? (1 = free text or scans, 3 = system export or fixed format)
- Exceptions: do the exceptions follow fixed rules? The number counts for less than whether you can describe them without ambiguity. (1 = often needs interpretation, 3 = every exception has a fixed rule)
Also weigh the risk. An automation that only reads can break little. An automation that puts orders, BOMs or purchase orders into the ERP needs more checks.
| Candidate | How often | Minutes per time | Hours per year |
|---|---|---|---|
| A. Orders from email into the ERP | 80 per working day | 4 | ≈ 1,227 |
| B. PDM release to item and BOM | 25 per week | 15 | ≈ 288 |
| C. Comparing revisions in PDM and ERP | 1 per week | 120 | 92 |
| D. Purchase orders for subcontracted work | 30 per week | 6 | 138 |
| E. Assessing quote requests for specials | 10 per week | 45 | 345 |
Assumptions: 230 working days or 46 working weeks per year. Candidate A is the shared worked example of this knowledge base; the numbers for B to E are round example figures. These are gross hours, before the exceptions are deducted.
| Candidate | Rules | Input | Exceptions | Reads or writes |
|---|---|---|---|---|
| A. Orders | 3 | 2 | 2 | Writes orders |
| B. PDM release | 2 | 3 | 2 | Writes master data |
| C. Revision check | 3 | 3 | 3 | Only reads |
| D. Subcontracted work | 3 | 3 | 2 | Writes purchase orders |
| E. Specials | 1 | 1 | 1 | Judgement |
What the tables show:
- E drops out. It takes a lot of time, but it revolves around technical judgement. An automation can at most do the preparation, such as looking up earlier similar orders.
- A yields by far the most hours. After deducting the exceptions (15% of the orders) and 15 minutes of checking per day, about 985 hours per year remain in the shared worked example. But A writes to the ERP, and the input varies per customer.
- C is the safest learning project. It yields few hours, but it only reads. It also teaches you how clean your master data is.
- B waits. Writing BOMs to the ERP is only sensible once the master data is correct and the agreements about revisions are on paper. C makes that visible.
- D is a good second candidate. Fixed rules, input from your own ERP, and a clear owner in purchasing.
If you have doubts about the quality of your item data, start with a check such as C. How the order process works step by step is in automating manual order processing. You can work out whether the hours outweigh the costs with when automation pays off.
Which technique fits a handover?
For most handovers there are several routes. Take the release of a drawing in PDM, which has to become an item and a BOM in the ERP.
| Approach | Strong at | Limitations |
|---|---|---|
| Change the way of working | One leading system and fixed agreements about revisions; often the first step | Does not solve the retyping itself |
| Standard integration from the supplier | Maintained by the supplier; no build work of your own | Does not exist for every combination of PDM and ERP; follows the logic of the supplier |
| Export file and import | Simple: on release, PDM puts a BOM export in a folder, and the ERP reads it in | The file format must be fixed; you build the checks on existing items yourself |
| Integration through an API (a fixed technical entry point for other software) | Stable and fast; checks per line are possible | Both systems need a usable API; more build work |
| Software robot (RPA) | Also works if PDM or ERP has no integration or export | Sensitive to screen changes after an update; slower; licence and management |
Choose the highest route that works in your situation. A software robot recognises fields on the screen by technical characteristics. If those characteristics change through an update, the robot has to be adjusted. How to choose between a robot and an integration is in RPA or API integration: which is the best choice?
Whichever route you choose, do not let the automation process an assembly with an unknown material code or a part without a released drawing at all. Half a BOM in the ERP causes more problems than no BOM. Also do not change open production orders on an old revision. Report them to the process planner.
The step-by-step plan in brief
- Make a list of handovers with the people who do them: the inside sales team, process planning, purchasing and engineering. Count for two weeks how often they occur and how long they take.
- Choose the first process with the hours, the scores and the risk, as above.
- Record the rules, including the unwritten ones: what happens with a new revision, when is something a special, and who owns the product data?
- Check the master data that the process touches, such as material codes and item numbers, and clean it up where it is not correct.
- Build small and test with real cases, including exceptions. Let the automation first run in parallel or prepare drafts, and have an employee check them.
- Go live with an owner, a separate account for the automation and a fallback plan. Look at every exception in the first weeks. Then choose the next candidate.
The implementation, the management and the choice of a specialist are covered in more detail in the guide to automating business processes.
What you do not automate first
- The assessment of whether a special can be made, and how you make it.
- Cost estimates for new products without comparable earlier work.
- Planning decisions with trade-offs between customers, such as which rush order goes first.
- Writing BOMs to the ERP as long as the master data and the agreements about revisions are not in order.
- Processes around a system that will be replaced soon, such as an ERP whose successor has already been chosen.
- Actions that occur only a few times a month, unless an error in them is expensive.
For the first three, an automation can do the preparation: collecting data, looking up earlier similar orders and preparing an overview. The decision stays with the expert. More signs that it is better to wait are in when it is better not to automate a process.
When does outside help make sense?
Ask three questions internally before you start. Who owns the process and the product data? Will one of the systems be replaced within a year? And who handles the exceptions and the management after go-live?
An IT employee can often build a check that only reads, or a report, themselves. Outside help makes sense in four situations:
- the automation writes to the ERP;
- PDM and ERP have no standard integration;
- a software robot is needed;
- nobody in-house can do the management.
In that case, also ask a specialist about experience with the combination of systems that you use. More examples of handovers that you can automate are in 12 examples of work companies can automate.