The factory is a system.
Years ago, one of my mentors handed me a book and told me I needed to read it. The book was The Goal by Eliyahu M. Goldratt and Jeff Cox.
At the time, I expected a book about manufacturing efficiency. In a way, that is exactly what it is.
But the lesson I took away from it was almost the opposite of what I expected.
The goal of a factory is not to make every machine as efficient as possible.
It is not to automate everything. It is not to keep every operator busy. It is not to make every machine run at 100 percent utilization. And it is definitely not to manufacture as much material as physically possible.
The factory is a system. And improving one piece of that system does not necessarily improve the system itself.
That sounds simple.
It becomes much harder when you are standing in front of a machine capable of producing parts faster than anything you have owned before and asking yourself: Why wouldn't I make this run all the time?
That question is at the center of The Goal. And years later, I still find myself thinking about it.
The Factory Is Not a Collection of Machines
The Goal follows plant manager Alex Rogo as he tries to understand why a factory full of people, equipment, and seemingly productive processes is still failing.
Goldratt's Theory of Constraints ultimately asks management to look at the performance of the entire system rather than optimizing each operation independently. The framework centers on increasing throughput while reducing inventory and operating expense. That distinction is incredibly important.
Manufacturing naturally encourages local thinking. We measure machine utilization. Parts per hour. Cutting time. Arc-on time. Spindle utilization. Labor utilization. Setup reduction. Pieces per shift.
Those measurements are useful. But they can also mislead us.
A machine can become dramatically more efficient without the company becoming any more productive.
That was one of the examples that stuck with me from The Goal.
The fictional plant had invested in robots. Management viewed those robots as an improvement and wanted them highly utilized. But producing more at that operation did not automatically create more sales. Instead, parts accumulated because downstream constraints could not consume the additional production. The robots looked efficient locally while the overall plant accumulated inventory.
That idea bothered me when I first understood it.
Because it means one of the easiest mistakes in manufacturing is this:
We improve the thing we can measure instead of improving the thing that matters.
Background: The North River Press on the Theory of Constraints.
Producing More Is Not Necessarily Producing More
This is where the definition of throughput matters.
In the Theory of Constraints, throughput is tied to the system generating money through sales—not simply creating another physical part. Inventory is money tied up inside the system, while operating expense is the money required to turn that inventory into throughput.
In throughput accounting, sales revenue is reduced by totally variable costs, such as purchased materials. The distinction matters: making a part and selling it are different events. Goldratt UK explains this measure. That changes how I think about a machine running.
Imagine I have an operation capable of producing 500 pieces today. The next process can consume 200.
If I make all 500 because I want the first machine to look efficient, I did not necessarily improve my factory.
I may have created 300 pieces of inventory.
Now those parts need somewhere to go. Someone has to move them. Someone has to identify them. They need a cart. A pallet. A rack. Floor space. They may need to be counted. Tracked. Protected. Eventually somebody has to find them again.
And if engineering changes the design before they are consumed, I may have created 300 pieces of scrap with excellent machine utilization.
The machine did more work. The factory may be worse off.
Same output. Different inventory.
The first operation stays busy. The next process still handles 200 pieces, and the queue grows by 300 each day.
Illustrative steady-state model: one part type, no opening queue, downtime, or scrap; downstream capacity remains 200 pieces per day. Physical output is shown here, not financial throughput. Real production also needs buffers for variability.
Inventory Can Be the Evidence of Efficiency
This was one of the strangest concepts for me initially. We usually think of efficiency as inherently positive.
Sometimes excess inventory is evidence that we have been too efficient in the wrong place.
If one operation continuously outruns the operation after it, material has to accumulate somewhere. There is nowhere else for it to go.
The Theory of Constraints treats that relationship directly: a system's output is governed by its constraint, and driving non-constraints harder does not necessarily increase system throughput. It can simply create additional work-in-process.
This is why the bottleneck matters so much.
If my laser can produce ten times faster than my bending department can consume parts, increasing laser utilization may not be the first problem I need to solve.
I can buy another laser. I can automate the laser. I can run it overnight. I can celebrate that it never stops cutting.
And then Monday morning I can walk into the bending department and find a mountain of parts.
I did not eliminate the constraint. I moved more material toward it.
Automation Makes This More Dangerous
Automation is powerful because it allows us to perform an operation with less human intervention.
But that same ability can magnify a bad production decision.
A person eventually stops. Automation does not necessarily stop.
If the production instruction is wrong, automation can execute the wrong strategy extremely efficiently.
That is why I do not think the right question is: Can we automate this?
It is:
What happens to the system if we automate this?
Those are very different questions.
Take Automated Sheet Loading
Laser cutting gives us a good example because the technology has become extraordinarily fast.
Modern fiber lasers can cut thin material at speeds that would have seemed ridiculous not that long ago.
Naturally, manufacturers want to automate the material handling around them. And there are very good reasons to do it.
Automated sheet loading can reduce manual material handling, improve safety, enable lights-out production, and keep a laser supplied without an operator repeatedly loading sheets. TRUMPF, for example, offers automation ranging from raw-sheet loaders to complete loading, unloading, storage, and sorting systems. See LiftMaster and SortMaster.
In the right factory, that makes tremendous sense.
If I manufacture the same products repeatedly, consume complete sheets, and know exactly what material I will need next, the economics can become very attractive.
Load the storage system. Schedule the jobs. Cut through the material. Unload the sheets. Repeat.
That is a very different manufacturing problem from the one we often have at Xeon NC.
High-Mix Manufacturing Changes the Equation
We are not always cutting a complete sheet into one repeating production part.
We may need a few pieces from a sheet. Then another customer needs something different. Then we need another alloy. Another thickness. Another finish.
The first sheet may still contain significant usable material.
So now I have a remnant. That remnant still has value. I may want it back in inventory because the next customer may need exactly that material.
This changes the automation problem substantially.
The question is no longer simply: How quickly can I put a sheet onto the laser?
Now I need to ask:
- What happens to the partial sheet?
- Where is it stored?
- How is it identified?
- Does my automated storage system understand the remnant?
- Can I automatically retrieve it later?
- Is putting it back into the system faster than having an operator handle it?
- How much storage does the automation require?
- How frequently are we changing material?
- How many sheets do we actually consume completely?
The answer to whether automation makes sense now depends on the production mix.
That is exactly the kind of system-level question The Goal taught me to ask.
Sometimes the Laser Is Faster Than Everything Around It
There is also a physical reality to automation.
Automation has cycle time. The laser does too.
TRUMPF publishes different handling-cycle figures for different automation systems. Its LoadMaster large-format 3 × 1.5 m version lists 103 seconds for loading. LiftMaster describes roughly four minutes for a complete loading and unloading cycle, including pallet change. LiftMaster Compact lists 90 seconds for the complete cycle and is designed for fast sheet-processing applications.
| System | Published time | What it covers |
|---|---|---|
| LoadMaster 3 × 1.5 m | 103 sec | Loading cycle |
| LiftMaster | About 4 min | Loading, unloading, and pallet change |
| LiftMaster Compact | 90 sec | Loading, unloading, and pallet change |
These figures describe different operations and configurations; they are not a like-for-like speed ranking. Evaluate handling and cutting together, including any parallel operation. Manufacturer pages checked September 19, 2026.
Those numbers do not mean automation is slow.
They illustrate something more important:
Material handling is itself a manufacturing process.
It has capacity. It has a cycle time. It can become a constraint.
On some jobs, the laser might spend a significant amount of time cutting a sheet. In that case, the automation easily works around the cutting cycle.
But take relatively thin material with large, simple profiles and limited pierces. Now the cutting cycle can become extremely short.
The machine finishes. The laser is ready for another job.
But everything surrounding the laser still has to physically move steel.
At that point, the fastest component in the cell may be waiting for its automation.
We automated the machine to increase utilization. Then the automation became the thing determining utilization.
That is The Goal playing out in real hardware.
Every Automated System Introduces Another Dependency
There is another side of automation that I think gets discussed less. Failure.
Automation is still machinery.
Sensors fail. Vacuum is lost. Sheets stick together. Parts lift. Parts tip. Suction cups wear. Material behaves differently. A skeleton hangs up. Communication faults occur. A component gets damaged. An axis faults.
Anyone who has spent enough time around industrial equipment eventually learns one thing: Everything breaks.
The engineering question is not whether it will ever fail. It is what happens to the rest of the system when it does.
TRUMPF's own designs demonstrate some of the complexity involved. LiftMaster offers thin-sheet separation and individually controlled suction cups. SortMaster monitors part separation and can use a shaking motion to free a part from the scrap skeleton.
That technology exists because moving cut sheet metal automatically is not trivial.
Humans are exceptionally flexible material-handling systems.
We can see that two sheets are stuck together. We can notice that a part tipped up. We can grab a remnant from an unusual position. We can move something slightly and try again.
Automation needs a process for all of those conditions.
The more conditions we automate, the more sophisticated the system becomes. And sophistication has a cost.
Automation Can Create a Single Point of Failure
This is something I think about constantly when looking at factory automation.
Suppose I have a laser.
If the loading automation is optional and it fails, maybe an operator can still load the machine manually.
Production slows down. But production continues.
Now suppose I build the entire factory around a fully automated material-storage, retrieval, loading, unloading, and sorting system.
That system may be incredibly productive.
Until one critical component fails.
Now the automation system is not helping the laser. It may be controlling whether the laser has access to material at all.
I have taken several separate manufacturing operations and tied them together.
That integration can increase throughput when everything works.
But I have also changed the failure architecture of the factory.
A failure in one subsystem may now stop several systems.
That does not mean the automation was a mistake.
It means recovery needs to be part of the automation design.
- Can I bypass it?
- Can I manually load material?
- Can I access the storage?
- Can I unload the machine?
- Can production continue in a degraded state?
To me, those questions matter just as much as the maximum parts-per-hour number in the automation brochure.
The Goal Is Flow
One of the phrases associated with Goldratt's manufacturing thinking is to balance flow, rather than attempting to perfectly balance the capacity of every resource.
That idea has stayed with me.
I do not need every machine working every second. I need the product moving through the system.
Those sound similar. They are not.
If letting one machine sit idle for ten minutes prevents me from creating four hours of unnecessary work somewhere else, that may be exactly what the factory needs.
This is extremely uncomfortable if the primary metric on that machine is utilization.
Someone looks at the report and sees: 83% utilization.
Why was it not 95?
The operator had capacity. The machine was available. Why did we not run more parts?
Because maybe we did not need more parts.
That answer can feel wrong in a culture obsessed with efficiency.
But if running those parts would increase inventory without increasing throughput, then keeping the machine busy would only make the report look better.
It would not necessarily make the company better.
We Have to Stop Worshipping Utilization
I like machines. I like automation. I like watching a process run without human intervention.
There is something satisfying about watching material enter one side of a system and finished parts come out the other.
But I think manufacturing has a tendency to fall in love with the machine instead of the result.
The laser does not exist to cut. The press brake does not exist to bend. The mill does not exist to remove material. The robot does not exist to move parts.
Those machines exist because eventually a customer needs something.
That finished product is the reason the entire system exists.
Everything between the raw material and that customer is there to support that outcome.
Once I think about the factory that way, automation becomes easier to evaluate.
Ask What the Automation Removes
Today, if I am looking at automating something, I think there are several questions worth asking.
- What constraint does this remove?
- Does it increase actual throughput?
- Does it reduce necessary inventory?
- Does it reduce operating expense?
- Does it eliminate repetitive labor that could be used somewhere more valuable?
- Does it make the process safer?
- Does it make production more predictable?
- Can the upstream process feed it?
- Can the downstream process consume what it produces?
- What happens when it stops?
- Can I bypass it?
- Does it give us more flexibility—or less?
And maybe most importantly:
Am I automating this because it improves the system, or because I do not like seeing the machine sit still?
That last question is harder than it looks.
There Are Places Where We Absolutely Should Automate
None of this is an argument against automation. Quite the opposite.
When automation is applied to the correct constraint, it can transform a factory.
- If material loading is limiting laser throughput, automate it.
- If an operator is spending hours moving heavy sheets, automation can improve safety and free that person to do higher-value work.
- If you have repeat production that can run unattended for hours, automated storage and loading can unlock an entire shift of capacity.
- If part sorting is preventing the next operation from receiving work, automate sorting.
- If an inspection process is preventing shipment, work on inspection.
The point is to know why.
Automation should have a job.
“Become more automated” is not a job.
A Factory Can Become Too Efficient at Making the Wrong Thing
This may be the lesson from The Goal that I think about the most.
There is no value in being incredibly efficient at creating something the system does not need yet.
You can manufacture parts faster. Stack them higher. Move them automatically. Track them with software. Put them into an automated warehouse. Retrieve them with a robot.
And still have inventory.
We sometimes use technology to manage problems that our previous technology created.
That should make us uncomfortable.
Before building a more sophisticated way to manage inventory, I want to understand why that inventory exists.
Before automating material movement, I want to understand why the material needs to move.
Before increasing the output of a machine, I want to understand what consumes that output.
Sometimes automation is the answer. Sometimes the better answer is to stop producing.
I Still Want the Automated Factory
I want to be clear about something. I still believe heavily in factory automation.
At Xeon NC, we think about automation constantly.
Automated quoting. Scheduling. Material management. Programming. Machine tending. Inspection. Part tracking. Shipping.
There is an enormous amount of manufacturing work that software and machines can improve.
But I think reading The Goal gave me a much better filter for evaluating those ideas.
I do not want the factory with the most automation. I want the factory with the best flow.
Those are not necessarily the same factory.
A person moving a sheet with a forklift may look less technologically impressive than a fully automated storage tower.
But if that person can move the exact remnant I need, immediately, from one operation to another while an automated system would require three additional transactions, the manual process may currently be better.
That can change. Volume can change. Product mix can change. Labor availability can change. The constraint can move.
And when it moves, the correct automation strategy can move with it.
That is the point.
Automation Is Not the Goal
The title of Goldratt's book is almost deceptively simple. The Goal.
That is the question manufacturing companies have to keep asking.
What are we actually trying to accomplish?
If the objective were simply to make machines run, manufacturing would be easy.
Keep feeding them material. Make more parts. Build bigger warehouses. Automate the warehouses. Then build systems to move everything between them.
But production is not throughput. Motion is not progress. Utilization is not profitability. Inventory is not success. And automation is not the goal.
Automation is leverage.
Used at the correct point in the system, it can dramatically improve what a factory is capable of doing.
Used indiscriminately, it can allow us to create the wrong thing faster, build inventory more efficiently, and make the manufacturing system more complicated than it needed to be.
The question I learned to ask from The Goal is not: How do we make this machine more efficient?
It is:
What is preventing the entire system from achieving more throughput?
Find that. Understand it. Then decide whether automation is actually the answer.
Further reading & sources.
The book inspired the perspective in this article. Equipment examples refer to the manufacturer's published configurations.
- The Goal: A Process of Ongoing Improvement — Eliyahu M. Goldratt and Jeff Cox, The North River Press.
- About the Theory of Constraints — The North River Press.
- Sales vs. Throughput — Goldratt UK.
- LoadMaster — TRUMPF technical data, 3 × 1.5 m format.
- LiftMaster — TRUMPF cycles and handling options.
- LiftMaster Compact — TRUMPF complete-cycle specification.
- SortMaster — TRUMPF separation and sorting features.
Technical sources checked September 19, 2026.



