The Case for Boring Manufacturing Software
Manufacturing tech is often sold through a carefully choreographed demo. There’s the dashboard with perfectly arranged KPIs. The colorful production schedule. The command center showing everything happening across the facility.
But some of the most valuable manufacturing software may be far less impressive in a demo.
It’s the screen an operator opens and immediately knows what to do next.
It’s the information that appears automatically instead of requiring someone to go find it.
It’s the production status that a manager can trust without asking three people whether it’s current.
It’s the integration that quietly eliminates a spreadsheet nobody particularly liked maintaining anyway.
In other words, good manufacturing software doesn’t necessarily give people more technology to use. It gives them fewer things to think about.
And that’s a very different way to evaluate a software investment.
Manufacturing Has a Cognitive Load Problem
Consider how much information a typical manufacturing operation asks people to keep track of:
What’s running?
What’s late?
What changed?
Is material available?
Which revision are we using?
What needs attention?
Did someone enter that into the ERP? Is that spreadsheet current?
Who knows what happened on second shift?
None of those questions is particularly unusual; the problem is the amount of human effort required to answer them.
When systems don't reflect how work actually happens, people become the integration layer:
Someone remembers that a certain field in the ERP isn't reliable, someone else knows which spreadsheet contains the real schedule.
A supervisor knows to call a particular person before trusting a status.
An operator has learned three extra steps that aren't documented anywhere.
A planner exports information from one system, manipulates it, and enters it somewhere else.
Eventually, the operation develops an invisible layer of human knowledge holding everything together. Production continues to move, and it’s easy to assume the system is working, because technically, it is.
The question is how hard your people are working to make it work.
Stop Counting Features. Start Counting Friction.
Manufacturing software evaluations often begin with functionality.
Does it support scheduling?
Can it track work orders?
Does it have dashboards?
Can it integrate with our ERP?
Does it have AI?
Those questions matter, but they don't necessarily tell you whether the software will actually improve your operation.
Try asking different questions instead:
How many places does someone have to look before making a decision?
How many times is the same information entered?
How often does someone leave a system to finish a task?
How many production questions require asking another person?
How much institutional knowledge is required to interpret what the system says?
How many workarounds have become so normal that nobody calls them workarounds anymore?
Those questions reveal something a feature comparison can't: operational friction.
And reducing that friction can be one of the highest-value jobs software performs.
Your Workarounds Are Requirements in Disguise
There's an interesting moment in almost every manufacturing software project.
You ask someone how a process works. → They explain the official process. → Then you watch them actually do it.
But the official process and what goes into actually executing it can be two very different things.
There might be a spreadsheet downloaded every morning, or a whiteboard used because it's faster than updating the system. A handwritten note attached to a traveler. A group chat where schedule changes actually get communicated.
It can be tempting to look at those behaviors as problems to eliminate. But first, they're worth studying.
A workaround exists because someone encountered a gap between what the system expects and what the operation requires.
That doesn't mean every workaround should become a software feature. Some are symptoms of bad processes that should disappear entirely. But taken together, they provide an unusually honest map of where your current systems aren't supporting the business.
Before writing requirements for a new manufacturing system, we should probably spend more time documenting everything employees do outside the existing one.That's often where the most useful requirements are hiding.
The Goal Isn't to Put the Entire Factory on a Screen
Q: If you can collect 200 data points, why not display 200 data points?
A: Because someone still has to decide what matters.
There is another trap in manufacturing technology: assuming more visibility is always better.
A production manager doesn't necessarily need more data. They might need to know which three jobs require attention.
An operator doesn't need an enterprise-wide dashboard. They might need to know what to run next and whether anything has changed.
Leadership doesn't necessarily need another report. They might need confidence that the number they're looking at means the same thing across every department.
The purpose of visibility isn't to make everything visible, it's to make the right things obvious. That distinction should influence everything from dashboards to alerts to production workflows.
Sometimes Custom Software Should Be Surprisingly Small
“Custom manufacturing software” can sound like a proposal to replace half of your technology stack, but it doesn't have to be.
Sometimes the highest-value solution is a relatively small piece of software sitting between systems that are already doing their jobs reasonably well.
Maybe the ERP should remain the system of record.
Maybe the machines don't need to change.
Maybe the existing scheduling process is fundamentally sound.
The question shouldn't be: “Could we replace this system?”
It should be: “Where would software remove the most friction?”
Those answers can lead to very different investments.
Good Software Should Eventually Become Boring
There's a tendency to judge technology by how impressive it looks immediately after implementation, but the real test is how helpful it is in 6 months, 1 year, 2 years, etc.
Do people trust it?
Has the emergency spreadsheet disappeared?
Are people still maintaining parallel processes “just in case”?
Can a new employee understand the workflow without learning a collection of undocumented tricks?
When something changes in production, does the right person know?
Can people answer routine questions without hunting for information?
If the answer to these questions is yes, the software may no longer feel particularly innovative. Instead, it has simply become part of how the operation works. And that's probably a compliment!
Maybe the Best Software Strategy Starts Without Software
Before deciding what to build, integrate, replace, automate, or buy, spend some time looking for friction.
Follow a work order through the facility.
Ask where information gets re-entered.
Find the spreadsheets that aren't supposed to be important but somehow are.
Notice where people have to remember things the system doesn't.
Ask supervisors which questions take surprisingly long to answer.
Look for places where employees have created their own tools.
Then ask: “What would have to change to make this easier?”
Sometimes the answer will be custom software; sometimes it will be an integration, a better use of something you already own, a process change, an off-the-shelf product, or no technology at all. But remember, that's the point.
Manufacturing doesn't need more software for software's sake. It needs systems that quietly remove obstacles between what needs to happen and the people trying to make it happen.
And if we've done that particularly well, eventually nobody will be talking about the software.
They'll just notice that the work got easier.
