ROI Case File No.586: They Waited to Have Everything Ready and Never Shipped the First One
They Waited to Have Everything Ready and Never Shipped the First One
Chapter 1: They Want to Automate, but Can't Get Started
"We're looking for a company to help us build RPA from outside."
Minoru Koide, business improvement section chief at TechWave, said this as he laid out the situation. "As of this year our annual holidays went up to 120 days. With more days off, we have to finish the same work in less time. But the work is concentrated on a handful of employees, and they can't finish within hours."
"How far along are your automation preparations?" Claude asked.
"The list of target tasks is already finished," Koide answered. "RoboPat is already running in another department, and automation is a group-wide policy. We have the tool and the policy. The problem is that nobody has time to build the RPA in-house. We finished the list, and nothing has moved for six months."
"Have you shipped the first one out of that list?" I confirmed.
"...We haven't," Koide answered. "The plan was to identify everything and then start all at once. Moving one of them first and seeing the effect—we've never started that way."
"If you wait to have everything ready, you never begin," I replied. "Let's break this down with MVP."
Chapter 2: MVP Asks—Ship the Smallest One Early
"This case calls for MVP."
Claude wrote "Minimal / Speed / Validation / Iteration" on the whiteboard.
"MVP—the minimum viable product—is a framework for shipping the smallest form in which value can be confirmed, measuring it in the field, and then widening," I explained. "The essence is not waiting for everything to be ready. Even a finished list produces zero effect if there's no time to start. Move one, and the hours freed there become the time to build the next. The first one creates the time to begin."
"First, let's measure the current cost," Gemini said, opening ROI Polygraph. The data Koide provided went in.
"The monthly costs are out," Gemini read off. "Routine work still done by hand despite being marked for automation averages 180 hours per month; at ¥3,600 per hour, that's ¥648,000 per month. Overtime from work concentrating on a handful of employees averages ¥440,000 per month. Operational pressure from the increase in annual holidays averages ¥340,000 per month. Automation deferred because nobody can start averages ¥360,000 per month. Falling behind the group-wide policy averages ¥300,000 per month. The total is ¥2,088,000 per month. Annualized, roughly ¥25,060,000."
Koide stared at the figures. "I was only looking at the work not finishing within hours. Once you add what we're deferring by never starting, it comes to this much."
"Then let's design with MVP," I continued.
[Minimal—Pick exactly one from the list]
"First, the minimum," Claude said. "Among the tasks on the list, pick one whose steps are routine, whose volume is high, and whose failure wouldn't stop the business. Don't touch everything—narrow to one. The selection criterion isn't the size of the effect; it's the certainty of shipping it."
[Speed—Ship something that runs within two weeks]
"Next, speed," Gemini continued. "Don't write a perfect design document. Defer exception handling too, and just run the happy path. Put it on the floor in two weeks. The very situation of having no time is the reason to cut it short and borrow outside hands."
[Validation—Run it in the field and measure the effect]
"After speed, validation," I continued. "Measure the processing time and volume of the task you automated, before and after. Produce the hours saved as a number. That number becomes the grounds for approving the next investment, and the proof that the overloaded employee's burden dropped."
[Iteration—Let the measurement choose the next one]
"Last, iteration," Claude continued. "Put the freed hours into the next build. Each lap gives you more usable time, so the second one is faster than the first. The list shrinks in order. Not all at once—one at a time is, in the end, the fastest."
[Calculating the payback]
"Let's run the numbers with ROI Proposal Generator," Gemini proposed.
- Initial cost: Target-task selection, minimal-configuration RPA build support, systematizing effect measurement, preparing the rollout procedure, and handover to in-house staff — ¥4,600,000 total
- Monthly cost: RPA operation plus ongoing maintenance — ¥200,000 per month
- Monthly savings: Automation of routine work = ¥460,000 per month (assuming a 70% reduction), reduced overtime = ¥340,000 per month, relief of work concentration on specific employees = ¥260,000 per month, recovery of deferral costs by eliminating the delay in starting = ¥260,000 per month — ¥1,320,000 per month in total
- Net monthly savings: ¥1,320,000 − ¥200,000 = ¥1,120,000 per month
- Payback period: ¥4,600,000 ÷ ¥1,120,000 = approximately 4.1 months
"A payback of just over four months," Gemini summarized. "What makes it work is not waiting for everything to be ready, but shipping one early. A plan to start everything at once never begins as long as there's no time. Ship one, and the hours freed there become the time to start the next. The investment doesn't swing at air."
Koide looked over the figures. "I thought we'd start once the list was complete. Unless you ship one, the time to start never exists."
"MVP is a tool for shipping the smallest one early," I replied.
Chapter 3: An Implementation Plan That Ships One at a Time
"Let me lay out how to proceed," I said, standing at the whiteboard.
"Month one—narrow the list, fix the first task, and prepare effect measurement. Month two—build in minimal configuration, put it on the floor, and measure results within two weeks. Months three and four—add exception handling and extend to the second and third tasks. Month five—templatize the build procedure and hand it over to in-house staff. Month six—company-wide rollout and effect verification. Month seven onward—keep working through the list and integrate with the other department's RoboPat operation."
"Doesn't one at a time take longer to finish everything?" Koide asked.
"Starting everything at once ends up slower," Claude replied. "Begin all of it and your limited people scatter, and everything halts half-finished. One at a time, the freed hours become the next resource, and each lap gets faster. Shipping the first one comes before lining them all up."
Koide took notes. "Before completing the list, ship one. I can see the order now."
Chapter 4: The Day They Shipped One and Time Appeared
Ten months later, a report arrived from Koide.
The first automation reached the floor in two weeks. "We deferred exception handling and ran only the happy path. Even so, an hour and a half of daily work vanished," Koide wrote.
The freed time produced the next one. The savings from the first went into building the second. "'We can't start because we have no time' flipped around. Time appeared because we started," the report said.
The largest change showed up in how they got started. From waiting to have everything ready, they moved to shipping the smallest one. "We stared at that list for six months. Once we shipped one, the rest naturally started shrinking," Koide wrote.
The concentration of work eased as well. Automation took over the tasks that had piled onto specific employees. "Tasks that only one person could do decreased. Overtime went down even after the holidays increased," the report said.
As a secondary effect, their way of planning changed. Shipping without waiting for the finished form took root. "We stopped saying 'once everything is decided.' Now we think in terms of shipping one and measuring," Koide wrote.
At the end of Koide's report, he had written: "I thought the RPA problem was that we had no time to build. But the real problem was that we waited to have everything ready and never shipped the first one. The moment MVP put out just one, the time to build the next was born. Before completing the list, shipping one came first."
The day a company that had waited to have everything ready became a company that ships one at a time and widens, RPA deployment had changed from a single all-at-once build plan into a design that ships the smallest one early and widens while measuring, the report noted.
"Automation consultations almost always arrive in the form of 'we've identified the work but we have no time.' But before you complete the plan, there is something to ask. Has the first one shipped? What MVP asks about is the minimum, the speed, the validation—and the iteration. Ship one, and the hours freed there become the time to start the next. The day a company that had waited to have everything ready managed to ship one, what changed was not the size of the workforce but the very perspective of shipping the smallest one early."
Related Files
Tools Used
- ROI Polygraph — Visualizing residual routine-task hours, overtime, and deferral costs from delayed starts
- ROI Proposal Generator — Investment-recovery simulation for RPA build support driven by early deployment in minimal configuration
