I spent a year and a half as a manufacturing process engineer before moving into controls. Two lessons from that stretch have stuck with me more than the rest.
Automation has a floor, and a ten-year-old is standing on it
Not every task is worth automating. Some jobs on the plant floor look tedious enough that a machine should obviously do them, and then you price out the fixture, the vision system, the robot arm, the integration time, and the math never closes. You are trying to buy a machine to do what a ten-year-old could do in an afternoon.
That is not a knock on the people doing that work. It is the opposite. No robot on the market matches the everyday combination a person brings to a station: fine dexterity, visual intuition about when something looks off, and the mobility to move around an odd-shaped part and adjust on the fly. We treat those skills as ordinary because they are common, but they are the hardest things to replicate in hardware. The jobs that resist automation are a good measure of how much human skill was actually in them.
The practical version: automate the parts of a process that are rigid, repeatable, and well defined. Leave the parts that need hands and judgment to the people who are already good at them, and stop apologizing for the line item.
A production-control policy can be modeled as a circuit
The second lesson is that a chosen production-control policy can be written down as a circuit. I formalized this in A Circuit-Inspired Framework for Manufacturing Systems. The distinction matters: the circuit describes how we choose to run the line, not a universal law of equipment.
| Circuit | Manufacturing model |
|---|---|
| Current source | Material actually admitted to the cell |
| Charge | Admitted physical WIP, waiting and in process |
| Current | Completed throughput |
| Capacitance | A fixed reference scale for WIP, independent of the physical WIP limit |
| Resistance | An analogue determined by throughput-control gain |
| Inductance | An analogue of the lag from throughput command to output |
Customer orders wait outside the physical WIP count until material is admitted. WIP accumulates when admissions exceed completions. The controller commands throughput in proportion to physical WIP, capped at machine capacity, and actual output follows with a lag. That gives a second-order model whose damping depends on the gain and lag. Increasing physical storage alone changes the headroom before blocking, not the damping. The familiar 63-percent measurement identifies the isolated first-order command response, not the complete demand-response loop.
This does not replace discrete-event simulation or measured production data. It gives me a way to ask sharper questions before building a detailed model: is the problem insufficient capacity, an aggressive controller, slow adjustment, or too little space for the expected WIP swing? A planned outage also needs actual starting stock, not just empty buffer capacity. The model helps organize those checks; the line has to validate the answers.
The throughline
Both lessons are about knowing what your tool is for. Automation is for the rigid, repeatable middle of a process. A circuit model is for fast structural reasoning, not final answers. Most of the waste I saw came from pointing a tool at the part of the problem it was worst at.
Yours Truly