The workbook did more for manufacturing than almost anything else on the floor. Ask a plant manager how the changeover schedule works and more than a few will open a file named something like Master_Schedule_v14_FINAL_USE_THIS.xlsx. Somebody built it because the official system could not answer the scheduling question at the resolution the floor needed, and years later it still can’t, so the file is still running the line. It is what people build when the systems they were given fall short and the deadline does not move. Where the spreadsheet is still the right tool A spreadsheet is fast, free, and shaped exactly to how one person’s job actually runs. For a one-off analysis, a small team’s shared list, or a process that changes every few weeks, that is still the right tool, and it will be for a long time. If the job fits on one screen, has one owner who is also the only user, and nothing downstream depends on it being current, leave it alone. Replacing something that already works, for no reason other than that it is a spreadsheet, is its own kind of waste. The test is not the file format. It is whether more than one person depends on the number being right at a moment they did not choose. A spreadsheet used by one person, for their own decisions, on their own schedule, has none of the problems below. The trouble starts when a second person, a second shift, or a customer starts depending on that same file. Where it breaks The trouble starts small. Somebody copies the file to work on it at home, emails it to a supplier, or opens last week’s version because this week’s would not open on their phone. Now there are three files with three answers, which is version drift, and the meeting where everyone reconciles them is where the real hours go. Every serious workbook has an author, and the author is usually the only person who fully understands the logic behind the columns nobody else dares touch. Ask what happens if that person is out for two weeks. Most plants have not tried it. The formulas keep calculating. Nobody can tell you, with confidence, whether they are still calculating the right thing, because the person who would know is not there to ask. A spreadsheet records the current number, not who changed it or why. When a customer asks why a shipment moved, or an auditor asks why a specification changed on a given date, “the cell says 42” is not an answer. The history that would answer the question was overwritten the last time somebody saved the file, because saving over the old version is how the tool is meant to be used. Most of what fills the workbook did not start there. It was typed in from an ERP screen, copied out of an email, or read off a machine display and keyed in by hand. Every one of those hops is a chance to fat-finger a number, and there is no way to tell, later, which numbers came from a system of record and which came from someone’s memory of what the gauge said an hour ago. None of this shows up as a line item. It shows up as the hour somebody spends every morning rebuilding yesterday’s numbers by hand, the decision that waits on that hour to finish, and the standing meeting where three versions of the truth get reconciled out loud before anyone can act on any of them. Added up over a year, that cost is usually larger than the tool everyone is nervous about buying instead. It is just spread across enough people and enough weeks that no single line item ever carries it. Signs it’s time to move on Three signs. How many people could rebuild the file from memory. If the honest answer is one, there is already a single point of failure with a name and, eventually, a retirement date. How often the workbook disagrees with the system it was supposed to be summarizing. If reconciling those two happens every week, reconciling has become the job. How much of what is in the file was typed in by hand from somewhere else. That is integration work being done manually, every day, by a person instead of a system, and it will keep being done that way until somebody decides it shouldn’t be. None of these on its own means retire the file today. Together, and getting worse, they mean the workbook has become load-bearing for something it was never built to carry. How to move without the big rebuild The failure mode on the other side is a multi-year platform project that tries to replace everything at once, misses the deadline, and leaves the old spreadsheet running anyway because nobody wants to cut over live. Start with the file that hurts the most. The workbook causing the most weekly pain, the most reconciliation meetings, or the most risk if its one owner left, is a better first target than the most impressive-looking one. A small win that removes real pain builds the case for the next one. Keep the person who built it in the room. They are the only documentation the process has ever had, and the fastest way to lose their knowledge is to replace their file without asking them what it actually does and why. Move where the number comes from. A dashboard that displays the same numbers a spreadsheet already shows has not changed anything. The improvement is connecting to where the numbers actually come from, so the number updates itself instead of waiting for somebody to refresh it. Run both for a while. Let the new system and the old file sit side by side until they agree, consistently, on real data, before anyone is asked to trust the new one alone. Trust in a number that used to come from a person takes longer to build than the software takes to install. Retire the file on purpose. Pick a date, tell the people who used it, and turn off editing on the old version instead of letting it keep running in a folder somewhere while everyone means to stop using it. A spreadsheet that is merely deprecated never actually goes away. The workbook did its job when nothing else could answer the question fast enough. What matters now is whether the person who built it is still the only one who can run it, and what is being done about that while they are still around to ask.