The Spreadsheet That Became a Manufacturing System

Walk into almost any plant and you’ll find a spreadsheet doing a job it was never meant to do.

One tracks downtime. Another holds the production schedule. Someone has built a third to follow shortages, with a column for the latest update and a color code everyone is supposed to understand. These files are useful. They were usually created by the person closest to the problem, which is why they often fit the work better than the official software.

The trouble starts when the spreadsheet becomes the system.

A planner updates a schedule, but the materials team is looking at yesterday’s copy. A supervisor records a machine stoppage, but the reason is buried in a note that cannot be compared across shifts. By the time everyone agrees on what happened, the team has spent more time gathering information than acting on it.

The obvious answer is to build an app. In practice, that can turn a small operational problem into a large software project.

Before anyone builds the first screen, they have to learn what “line,” “part,” “shift,” and “available inventory” mean in that particular plant. They have to work out which fields matter, who enters them, and how the information moves between teams. Those conversations are necessary. But when every app starts from a blank page, the same groundwork gets done again and again.

A better starting point is the tool the team already made.

Take a downtime spreadsheet. It tells you which information operators thought was worth recording. Sit with them for a shift and you’ll learn what the columns miss: when a stoppage should be logged, which reason codes are too vague, and who needs to know before the next shift starts. From there, a useful first app is fairly clear. It should make an event quick to enter, tie it to the right line and shift, and give the next person enough context to act.

The same approach works for a shortage tracker or a hand-built schedule. Start with the real workflow, make a small version people can use, and improve it with their feedback. Connect it to existing systems where that removes duplicate entry. An app does not have to solve every plant problem on day one to be valuable.

This is the problem we’re working on at SubAssembly.ai. We’re building a way for manufacturing and supply chain teams to turn an idea, sketch, spreadsheet, or document into a working app. It starts with a model of plant equipment, parts, processes, and their relationships, so teams have a foundation to build on.

I think the best manufacturing apps will come from the people who already know where the work breaks down. They’ve been designing solutions in spreadsheets for years. It’s time to give those ideas room to grow.