At a lot of the companies we visit, how a product actually gets made sits in three places at once: with the operator, in a spreadsheet, and on the sheet taped next to the machine. That is how it grew and it works, until you have to hand it over to a new shift or check afterwards what applied that day.
In AIONIX you capture that as a digital production process inside a connected MOM platform (Manufacturing Operations Management): production planning, execution on the floor, quality and maintenance all read the same process model, instead of each living in its own file or system. For manufacturers with complex, recurring processes, that is what separates it from a standalone process description.
Below is how you build such a production process, using a bakery making chocolate biscuits as the example.
What a production process is
A production process is the digital model of how your product gets made. You build it yourself, operation by operation, and it stands apart from the orders that run on it.
Think of it as a recipe. A recipe does not say how many biscuits you bake today, but it does say in what order you work, how hot the oven has to be, and how you can tell it worked.
For the chocolate biscuits it looks like this:
| Resource | Settings and check | |
|---|---|---|
| 10 Mix dough | MENG-01 | Mixing time 8 min, check weight |
| 20 Cut | STEEK-02 | Chocolate biscuit cutter, visual check |
| 30 Bake | OVEN-01 | 180 °C, 12 min, check colour |
| 40 Pack | VERP-01 | 12 pieces per pack, check weight |
A production process is not a production order
This is the distinction that goes wrong most often. The production process says how we make it. The production order says what and how many, and comes out of your ERP: 1200 packs of chocolate biscuits, ready by Thursday.
The same production process serves many orders. Move the baking time from 12 to 13 minutes and you change the model. Not every order separately, and not the sheet next to the machine.
What is already running keeps the version it started on. So PO-1041 bakes out its 12 minutes, and the new time applies from the next order. If a complaint comes in later, you can still tell which specification applied that day.
Machines and equipment
A production process does not fix which machine something runs on. For operation 30 you mark which ovens are allowed: OVEN-01, OVEN-02 and OVEN-03, the three that can handle this product. Which of the three it becomes is decided on the order. You pick one yourself, or you let production planning pick based on what is free.
Behind that choice sits a physical asset: OVEN-01, with a serial number and a maintenance history. That distinction counts the moment you start to analyse. If the pale biscuits always come out of the same oven, you want to be able to see that.
Equipment that changes per order is such an asset too. The cutter does not live in STEEK-02 permanently, so the production process states which cutter this operation needs. Whether it is really in there at the start is what shop floor monitoring watches.
How the processes follow each other
Every operation in that table is a production process of its own. What holds them together is the production route: the sequence they run in. Every step in that route points at the process that belongs to it, and a step can also point at a process that is made up of several operations itself. Under Pack sits a route of its own, with Load into trays and Fill boxes.
Because every process stands on its own, another product can point at the same one. Add butter biscuits later, with different dough and a different baking time but the same packing, and their route simply reuses Pack. Change the packing once and everything pointing at it follows. That is how you build a library instead of starting over each time.
During execution that route fills itself in: what is done with its asset and run time, what is running with its progress, what is still to come in grey. Specification and reality sit in the same model, so a deviation stands out right away. Did the oven run at 174 °C instead of 180? You see it at operation 30, on the order where it happened, not three days later on a complaint about pale biscuits.
How you build it
This is work for your work preparation or your production manager: filling things in, not writing code. Per operation you capture four things:
- The machines allowed to run it.
- The settings that decide the result: times, temperatures, quantities.
- What gets checked, and against what.
- Its place in the production route.
That is the work. You are not inventing anything: you write down what your best operator already does, so the next shift does it the same way.
Conclusion
The order comes out of the ERP and says what and how many. The production process says how. The shop floor executes and measures, and the measured production goes back to the ERP.
As long as that "how" lives in people's heads and in spreadsheets, every order differs a little from the last one and afterwards you cannot say why. Put it in the model and you get a specification that is the same every time, plus production data you can compare it against. And once planning, quality and maintenance sit on that same model, a deviation stops being one loose number: you see the machine, the shift, the check and the maintenance it belongs to.
Start with the product that runs most often and write down what actually happens today. The rest of your range follows faster than you would expect, because the operations that come back are already there.