ROI Case File No.482 'The Signature That Stopped Seventeen Tools'
The Signature That Stopped Seventeen Tools
Chapter One: The Automation That Stopped Running
"Seventeen tools all stopped working one morning, simultaneously."
Kenji Morimoto, IT Systems Director at TechSolutions, pointed to a server log screen. Red error text scrolled across. HTTPS signature error, authentication timeout, access denied—all same root cause.
"Security hardening mandated signed HTTPS communication for internal system access," Morimoto continued. "Result: every Selenium-based automation tool died. Seventeen of them. Internal system login, data retrieval, data registration—all stopped."
"Who built the tools?" Claude confirmed.
"A former employee. Retired three years ago," Morimoto answered. "Written in VBA, no design documents. Few comments in the code. You can tell what it does if you read the code, but reading takes time."
"What's the impact on operations?" I asked.
"For each tool, a staff member is doing the work manually," Morimoto answered. "For example, a CSV import from a partner used to take five minutes every morning—it's now an hour of manual work. Across all seventeen tools, the added monthly workload exceeds 120 hours."
"What about rebuilding in-house?" Gemini asked.
"Not an option," Morimoto answered immediately. "IT has four members. We're full with regular operations. Only one writes Python, and he's dual-assigned on another project. Outsourcing is the only path, but I'm afraid of failing by rushing."
"What kind of failure?" Claude confirmed.
"We outsourced another project before, and the deliverable came back as a black box," Morimoto answered. "Delivered in a state we couldn't maintain, so we had to keep depending on the vendor. I don't want to repeat that. But we're under time pressure. That's the dilemma."
"When you're rushed is precisely when you need a specification," I said quietly.
Chapter Two: The Proposal Arena RFP Defines
"This case needs an RFP."
Claude wrote three letters on the whiteboard. R, F, P.
"RFP stands for Request For Proposal—the requirement specification the buyer sends to vendors," I explained. "The essence of an RFP isn't writing specs, but setting up a level arena for comparison. Without a spec, each vendor proposes along their own strength, and you can't compare proposals. With an RFP, all vendors respond on the same ground. Precisely when you're rushed, building this arena first is the shortest path to reducing rework."
"Let's measure the current cost first," Gemini said, opening ROI Polygraph. Morimoto's operational records went in.
"Monthly replacement cost is out," Gemini read. "Tool downtime forces five staff members into 120 hours of manual work monthly. At ¥3,000/hour, that's ¥360,000 per month. Additionally, disrupted focus on core work drives 40 hours of overtime at ¥160,000. Potential decision-making error cost from rushed rebuild is provisionally ¥50,000. Total: ¥570,000 monthly as ongoing cost from tool downtime. Annualized: ¥6.84 million."
Morimoto looked at the calculation. "I counted manual hours but I wasn't counting overtime and rushed decisions."
"Rushing is expensive," I responded. "So let's design with RFP."
[RFP Layer One—Decompose the Requirements]
"First, sort seventeen tools into three groups," Claude said. "First: high business impact, urgent replacement—approximately five. Second: stopped but with workaround, lower urgency—approximately seven. Third: worth considering retirement—approximately five. Classification determines outsourcing priority and scope."
"We don't order all at once, you mean," Morimoto confirmed.
"Correct," I answered. "Ordering everything at once swells vendor quotes and stretches delivery. Narrow the first RFP to the priority five and defer the rest to later phases. Phased ordering works especially well on rushed cases."
[RFP Layer Two—Write the Axes of Comparison]
"Specify the evaluation axes inside the RFP," Gemini continued. "First, technical requirements—refactor in Python or UiPath, HTTPS signature support. Second, maintainability—design docs, code comments, and runbooks mandatory at delivery. Third, handover—three months of post-delivery code walkthrough sessions for internal members, monthly. Fourth, organizational—named contact persons, no single-point-of-failure staffing promise."
"Maintainability is the piece that prevents the last failure," Morimoto confirmed.
"Correct," Claude answered. "The reason last time's deliverable became a black box is that the RFP didn't contain maintenance requirements. What isn't in the requirements doesn't get delivered. Conversely, what's written gets honored."
[RFP Layer Three—Narrow the Candidates]
"Gather broad and narrow down," I continued. "Collect information from about ten vendors via industry press, technical communities, and referrals from existing partners. Primary screening on track record only—experience migrating VBA to Python or UiPath. Secondary screening with RFP distribution, proposal returns. Tertiary screening narrows to three companies and executive interviews meet the contacts. Three stages of narrowing."
[RFP Layer Four—Estimate the Payback]
"Let's simulate with ROI Proposal Generator," Gemini suggested.
Refactoring costs and savings lined up.
- Initial cost: Priority-five refactoring ¥4.5 million, RFP drafting and vendor selection at ¥500,000 internal labor, totaling ¥5 million
- Monthly cost: Maintenance support ¥80,000/month
- Monthly savings: Priority-five reactivation reduces 90 of 120 manual hours for ¥280,000, overtime reduction ¥120,000, rushed-decision cost relief ¥50,000, totaling ¥450,000
- Net monthly savings: ¥450,000 − ¥80,000 = ¥370,000
- Payback period: ¥5M ÷ ¥370,000 ≈ 13.5 months
"A little over one year for payback," Gemini summarized. "Not immediate. But phased ordering for the remaining twelve tools layers additional savings from year two. Plus, with design docs and runbooks in place, the same chaos won't repeat at the next security change."
Morimoto reviewed the numbers. "Rushing to outsource cheaply reproduces the same problem later. Writing maintenance requirements into the RFP raises initial cost but lowers the invisible costs from year two onward—that's the structure."
"What costs most on rushed projects is the rushed ordering itself," I responded.
Chapter Three: The Vendors a Specification Attracts
"Let me organize the approach," I said at the whiteboard.
"Week one—classify seventeen tools and select the priority five. Interview the business owners and rank by downtime impact. Week two—draft RFP document. Codify the four requirements: technical, maintenance, handover, organizational. Week three—collect information from ten candidates and primary screening. Weeks four and five—send RFP to top five, receive proposals. Week six—narrow to three and executive interviews. Week seven—contract and development kickoff. Week fifteen—delivery and parallel operation. Week seventeen—cutover complete."
"More than three months?" Morimoto confirmed.
"Yes," Gemini answered. "But if you rush and pick a vendor in one month, and maintenance issues recur after delivery, you'll end up with more than three months of rework anyway. Think of the first three months as investment that eliminates rework from year two on."
Morimoto closed his notebook. "I said earlier, 'I'm afraid of failing by rushing.' Today I think I've found the words for what that fear actually was."
Chapter Four: A Design That Prevents Repeating the Same Accident
Nine months later, a report from Morimoto arrived.
Priority-five refactoring was delivered in week sixteen, went through parallel operation, and cut over in week nineteen. The selected vendor met every RFP requirement and delivered with design docs, code comments, runbooks, and recorded handover sessions. Morimoto wrote, "When you open the code, comments explain why this processing exists. Compared to tools from three years ago, we've arrived at a different world."
Of the remaining twelve tools, seven were added to a second RFP ordered with the same vendor. Five were judged for retirement after business process review. "The moment they stopped working was also an opportunity to revisit whether they were needed," Morimoto wrote.
During parallel operation, a partial change was made to the internal system's security specs. When testing against the new specs became necessary, the vendor's contact responded within two business days. Morimoto's words: "A change that would once have caused panic was handled with quiet routine."
Monthly overtime for the four IT members dropped from an average of 60 hours before cutover to 25 hours. After the tools came back online, Morimoto said to his team, "Let's get back to our real work," according to the report.
The three weeks spent writing the RFP prevented a year of chaos.
"On rushed projects, a specification is what works. Proposals gathered without a spec can't be compared. A vendor chosen from proposals that can't be compared leads to post-delivery disputes. What an RFP designs is the arena for comparison. Write the four requirements—technical, maintenance, handover, organizational—and vendors respond on the same ground. A vendor chosen on that ground honors the promises made on that ground. The seventeen tools that stopped by signature came back with design documents, brought by the vendors the specification attracted. The second round of chaos never came."
Related Files
Tools Used
- ROI Polygraph — Visualizing replacement labor and overtime cost from tool downtime
- ROI Proposal Generator — Phased refactoring payback simulation
