Walk into almost any plant under a few hundred people and you'll find the real operating system in a spreadsheet. Schedules, downtime logs, spare-parts lists, open purchase requests, the list of jobs that are late and why. Often several spreadsheets, kept by different people, that don't quite agree.
The usual reaction from software vendors and consultants is to treat this as a problem of discipline: the plant just hasn't "matured" yet. I think that gets it backwards. Spreadsheets survive in small plants because, for a long list of everyday jobs, they are the best tool on offer. Understanding why is the first step toward building something better.
Spreadsheets win on the things that matter on the floor
A spreadsheet has four qualities that most packaged manufacturing software doesn't.
It's already there. No purchase order, no implementation project, no consultant. The person who has the problem can start solving it this afternoon.
It fits the plant exactly. The columns are the plant's own words for things. If the shop calls a stoppage "waiting on QC," that's what the column says, not a code from a vendor's list of 60 reasons.
It changes as fast as the plant does. A new customer requirement, a new machine, a new way of tracking scrap: someone adds a column and moves on. In a packaged system, the same change can mean a ticket, a services quote and a wait.
The person who uses it controls it. That ownership matters more than any feature. People keep data current in tools they built, and quietly stop feeding tools that were imposed on them.
Where spreadsheets break
None of that means spreadsheets are the answer. They fail in predictable ways, and every plant that runs on them eventually hits all of them.
- One person holds the key. The scheduling workbook works because one planner understands it. When that person is on vacation, or leaves, the plant finds out how much was in their head.
- Nobody sees the same version. The copy on the shared drive, the printout on the board and the one in someone's email drift apart within a week.
- Data arrives late. A spreadsheet is filled in after the fact, usually at the end of a shift or a week. By then it's a history, not a tool for steering.
- Nothing connects. The downtime log doesn't know about the maintenance parts list, which doesn't know about purchasing. Every connection is a person re-typing numbers.
- It doesn't scale with the business. What worked at one shift and twenty people starts to crack at three shifts and a second building.
Why the big systems don't fix it
The obvious move is to buy software that does these jobs properly. Many small plants try, and many end up back in their spreadsheets within a year. The reasons are consistent:
The software was designed for a different plant. Most manufacturing systems grew up serving large, multi-site companies with dedicated IT staff, process engineers and super-users. A plant with one person doing IT part-time can't carry that weight.
The price is out of proportion. When I've gone looking for tools to solve specific problems, maintenance tracking or purchasing for spare parts, the answers were usually six-figure implementations with annual fees to match. For a plant of a hundred people, that is hard to justify against a spreadsheet that mostly works.
It asks the floor to work for the system. Long forms, deep menus and codes nobody uses in conversation. Operators and mechanics comply for a while, then fall back to the whiteboard, and the expensive system fills up with incomplete data.
What better looks like
If spreadsheets win on speed, fit, flexibility and ownership, and lose on visibility, continuity and connection, the design target for better software is clear. It has to keep the first four and fix the last three.
- Start in minutes, not months. A tool a plant can begin using for one problem this week, without an implementation project.
- Speak the plant's language. Reason codes, part names and job steps the plant defines and can change itself.
- Be live, not after the fact. Data captured at the moment it happens, by the person closest to it, in a couple of taps.
- Give something back to the people entering data. If the operator or mechanic gets nothing from the system, the data will stop.
- Connect the pieces. Downtime should know about maintenance, maintenance about spare parts, spare parts about purchasing.
- Be priced for the plant you are. Modular, so a plant pays for the problem it has, not a suite it will never use.
That list is the thread through everything I write here. The next pieces look at each of the problem areas in turn: choosing between big packages, homegrown tools and software you configure yourself, the maintenance and purchasing spend that most plants never really manage, planning without an expensive scheduling system, and what a shop-floor display should actually show.
A test you can run this week
Ask three people in your plant where the "real" version of the production schedule lives. If you get three answers, or one answer that involves a single person's laptop, you have found the first place a better system would pay for itself.