ROI Case File No.470 'The Warehouse Where Seven Spreadsheets Slept'
The Warehouse Where Seven Spreadsheets Slept
Chapter 1: Why the Last Consultant Quit
"Two years ago, we brought in a logistics consultant. They gave up in three months. Their explanation: the operations were too complex to work with."
Yoshihiro Hashimoto, Managing Director of Administrative Headquarters at InnovaLogistics, placed a thick folder on the table as he spoke. It contained documents the consultant had left behind—multiple pages of operational flow diagrams, each one stopping partway through. Arrows suspended in mid-air, never reaching the next step.
"What kind of operation is it?" I asked.
"Creating shipping invoices for the dispatch team," Hashimoto answered. "Four dispatchers log daily shipping records into Excel. Each person has their own Excel file. At month-end, the clerical staff consolidates all four files into one and generates invoices and payment statements. That consolidation process—"
"Isn't working," Claude continued.
"Opening multiple files simultaneously causes bugs," Hashimoto said. "Numbers shift, formulas break, someone overwrites someone else's data—the same thing happens every month-end. Verification work alone consumes over 20 hours a month. Once, a customer invoice was delayed by a full day."
"You mentioned DX and eliminating personalization as goals," Gemini confirmed.
"Goals on paper," Hashimoto said with a wry smile. "In reality, each department operates on its own Excel, and systems have proliferated. When we try to unify them, someone says 'our operations are too specific for off-the-shelf solutions.' That voice stops the conversation every time."
"I don't think the real reason the previous consultant failed was that operations were too complex," I said.
Hashimoto narrowed his eyes. "What do you mean?"
"They tried to design the operations from the outside," Claude answered quietly. "There's a method that starts from inside."
Chapter 2: The Five Stages Design Thinking Demands
"This case calls for Design Thinking."
Claude wrote five words on the whiteboard: Empathize, Define, Ideate, Prototype, Test.
"Design Thinking is a five-stage process: empathize with users, define the problem, ideate solutions, prototype, and test," I explained. "My hypothesis for why the previous consultant failed is that they skipped Empathize and Define and brought in a solution from the outside from the start. Design Thinking begins with the friction that frontline people feel. Solutions born from the field take root in the field."
"Let's first measure the current cost," Gemini said, opening ROI Polygraph and entering the operational logs and month-end work records Hashimoto had provided.
The numbers returned.
"Monthly labor breakdown is in," Gemini read. "Four dispatcher Excel entry: 80 hours/month at ¥2,600/hour = ¥208,000. Three clerical staff consolidation and invoice creation: 60 hours/month at ¥2,800/hour = ¥168,000. Bug handling and verification: 20 hours/month at average ¥2,700/hour = ¥54,000. Total: ¥430,000/month consumed by this invoice creation process alone. Annualized: ¥5,160,000."
Hashimoto exhaled looking at the numbers. "Add month-end overtime and it climbs further."
"If you combine the previous consultant's fees and the two years of inefficiency cost since then," Claude said quietly, "the cost of the failed engagement may have been larger than it appeared."
"Then let's begin with Design Thinking," I continued.
[Stage 1 — Empathize: Listen to Frontline Friction]
"In the first week, have individual conversations with all four dispatchers and all three clerical staff members," Claude said. "One question only: what moment during month-end work feels most stressful to you?"
"Is that enough?" Hashimoto confirmed.
"That's enough," I answered. "We're not asking for solutions. We're asking for the friction they feel. Solutions come from outside the field. Friction only exists inside the field. The previous consultant brought in solutions before listening for friction. That's why the field didn't follow."
A week later, Hashimoto returned with the interview results. The responses from all seven people converged on three patterns.
Dispatchers: "Data I entered correctly the day before has changed when I check the next day." Clerical staff: "I can't tell which file is the current version." Everyone, universally: "Work suddenly explodes at month-end."
"All three come from the same root cause," Gemini organized. "Data is dispersed and nobody has a view of the whole—a structural problem."
[Stage 2 — Define: Put the Real Question into Words]
"We condense the friction collected in Empathize into a single question," Claude said. "The question for this case is: how do we create an environment where dispatchers and clerical staff can see the same data in real time?"
"Isn't that what invoice automation is for?" Hashimoto said.
"Automation is a solution," I replied. "Confuse a question with its solution, and the solution gets locked in before the question is properly shaped—and the system built to that solution doesn't answer the actual question. Define the question precisely first, and the solution space opens up."
"Real-time access to the same data—that is the definition," Claude repeated. "Viewed through this definition, the answer isn't 'how do we make the Excel consolidation more efficient'—it's 'eliminate the dispersed Excels altogether.'"
[Stage 3 — Ideate: Expand the Solution Space]
"Against the defined question, generate solutions without constraint," Gemini continued. "Temporarily set aside budget and technical limitations, picture the ideal state, and then select realistic paths toward that ideal."
"The ideal state," Claude continued, "is this: a dispatcher enters a day's records, and the consolidated data reflects in real time. When clerical staff review at month-end, the numbers are already there. Verification work means only checking for accuracy."
"Three paths toward that ideal," I continued. "First: migrate to a cloud-based dispatch management system. Second: replace existing Excel files with Google Sheets for real-time sharing. Third: standardize the input form only, and handle consolidation through an automated script. Compare these three on cost and frontline burden."
"Let's pull comparable logistics company cases from Strategic ROI Intelligence," Gemini proposed. "We can get benchmarks for which approach companies with similar challenges have chosen—choosing from proven options is more credible than reasoning from scratch."
The tool returned results. Among logistics companies with revenue under ¥500M facing similar challenges, the third option—unified input form plus automated consolidation script—was most frequently adopted. Lowest initial investment, fewest changes to frontline operations.
[Stage 4 — Prototype: Test with the Smallest Possible Version]
"It's critical not to deploy the chosen approach company-wide immediately," Claude said. "Start with just one dispatcher and one clerical staff member paired together for one week only. Create the unified input form, run the auto-consolidation script, and observe what happens over that week. This small experiment is the heart of Design Thinking."
"That's the difference from the previous consultant," I continued. "The previous consultant tried to deploy a complete system to the whole company. Design Thinking starts with a prototype it's okay to break. The places where it breaks teach you the real problems."
"When we do the prototype," Hashimoto said with a slight smile, "something will break. I can feel it."
"It's okay for it to break," Gemini replied. "What you fix after it breaks is what fits the field. Trying to complete it before it breaks is what causes projects to fail."
[Stage 5 — Test: Judge with Numbers]
"After the one-week prototype, confirm three numbers," I concluded. "Did input time change? Did consolidation time change? Were there errors in the verification work? If all three have improved, make the decision to expand to the remaining six. If not, return to the prototype."
"Let's project the post-deployment numbers with ROI Proposal Generator," Gemini proposed.
Post-automation savings were laid out.
- Initial cost: Unified input form and auto-consolidation script development ¥800K
- Monthly cost: Maintenance and cloud fees ¥30K/month
- Monthly savings: Dispatcher entry 70% reduction = ¥145,600; consolidation work 80% reduction = ¥134,400; bug handling 90% reduction = ¥48,600; total ¥328,600/month
- Net monthly savings: ¥328,600 − ¥30,000 = ¥298,600
- Payback period: ¥800K ÷ ¥298,600 = approx. 2.7 months
"Payback within three months," Gemini summarized. "Annual savings of approximately ¥3.58M. Given two years of inefficiency costs since the failed engagement, acting now is the most rational choice."
Hashimoto looked at the numbers. "The cost of two years of inaction became visible today for the first time."
Chapter 3: A Design That Came From the Field
"Let's map out the Design Thinking progression," I said, stepping to the whiteboard.
"Week 1: Individual interviews. Listen to friction from all seven people. Don't ask for solutions. Week 2: Define the question and ideate. Organize interview results into three patterns, define the question in one sentence. Week 3: Prototype. One dispatcher and one clerical staff member test for one week. Week 4: Test and expansion decision. Evaluate against three numbers, and if they check out, decide to expand to the remaining five. Post-expansion: run monthly PDCA, continue improving script precision."
"All of that in one month," Hashimoto confirmed.
"Up to the prototype in one month," Claude replied. "The previous consultant spent three months before giving up. Design Thinking reaches a prototype in one month. At that point, you know whether the field will move with it. If not, design again. If yes, expand."
"Why is it faster than the previous consultant?" Hashimoto asked.
"Because we're not aiming for completion," I answered. "Aiming for completion requires everyone's agreement. Aiming for a prototype requires one person's agreement. Start with one, and expand to the person next to them when it works. That pace is what determines whether it takes root in the field."
Hashimoto nodded quietly. "Starting next week, I'll begin the interviews. All seven people."
"When choosing the first person for the prototype," Claude added, "choose the person most dissatisfied. The person who feels operations aren't working most sharply teaches you the sharpest friction. A prototype that resolves their friction resonates with everyone."
Chapter 4: The Month-End When the Spreadsheets Went Quiet
Six months later, a report arrived from Hashimoto.
During the first week of interviews, the most dissatisfied dispatcher volunteered to participate in the prototype. "I want to be first," he said. Hashimoto recorded this in his report.
The prototype of the unified input form and auto-consolidation script hit an error on day three. When the dispatcher entered a specific product code, the consolidation script placed numbers in the wrong row. That error turned out to have the same structure as a hidden bug that had been occurring undetected in the old Excel files every month—discovered for the first time through the prototype.
The corrected prototype was deployed to all seven in week three. Month-end consolidation work dropped from 60 hours to 11. Error count in verification work: zero. One dispatcher said "month-end isn't scary anymore." Hashimoto recorded this in his report.
Annual savings exceeded the projected ¥3.58M—including month-end overtime reduction, the total reached approximately ¥4M.
The final line of Hashimoto's report read: "Now I understand why the previous consultant hit a wall with operational complexity. They tried to design from the outside. Design Thinking started design from the inside. A design that began with frontline friction feels like theirs to all seven people. They all think of it as a system they built themselves. That's why it's being used."
The month-end when seven spreadsheets went quietly to sleep finally came.
"A complex operation cannot be designed from the outside. Complexity can only be solved from the inside. The five stages Design Thinking demands—Empathize, Define, Ideate, Prototype, Test—start from the friction that frontline people feel. Where there is no friction, there is no solution. The person most dissatisfied holds the sharpest question. Only a design that starts from their question takes root in the field. The night seven spreadsheets fell silent, a system that the field built with its own hands quietly began to run."
Related Files
Tools Used
- ROI Polygraph — Invoice creation process labor and cost visualization
- Strategic ROI Intelligence — Comparable logistics company case benchmarking
- ROI Proposal Generator — Automation deployment payback simulation
