ROI Case File No.462 'The System Nobody Touched'
The System Nobody Touched
Chapter 1: The Person Who Built It Is Gone
"The person responsible for the system left three years ago. Nobody here understands what's inside it."
Yasuko Tadokoro, General Affairs Manager at TechNova, said this while pointing at a screen. An aging, fully custom-built core system was running. The font was small. The button layout had no logic. There was no way to tell, just by looking, what pressing anything would do.
"Our in-house SE built it almost single-handedly," Tadokoro continued. "He was exceptionally talented, but there wasn't enough time for a proper handover when he left. Now we outsource maintenance to an external vendor, and every version update costs a significant amount. Last month's update was ¥800,000."
"Eight hundred thousand for a single update," Claude confirmed.
"It happens one to two times a year," Tadokoro nodded. "And that's not all. Every time a staff member gets stuck on an operation, it generates an inquiry to the maintenance vendor. Those response costs accumulate monthly. HR tells me it takes new employees an average of two months to learn how to use it."
"How do frontline staff feel about this system?" I asked.
Tadokoro gave a rueful smile. "They say it's scary. Like something might disappear if they press the wrong button. So they limit what they touch to only the features they absolutely have to use. Probably less than a third of the system's intended functionality is actually being used."
"Complexity is calling forth more complexity," Gemini said quietly. "Unused features remain, making the whole system harder to understand. Because it's hard to understand, even more goes unused."
Tadokoro nodded. "I want to break that cycle. We're considering migrating to a no-code platform, but I can't see what needs to be organized before we do."
Chapter 2: The Four Blades ECRS Demands
"This case calls for ECRS."
Claude wrote four letters on the whiteboard: E, C, R, S.
"ECRS stands for Eliminate, Combine, Rearrange, and Simplify—a four-stage framework for cutting waste from operations or systems," I explained. "Before introducing a new system, dissect what you already have. What to discard, what to keep, what to reorganize, what to simplify—thinking in this sequence means that migration to no-code begins with design, not deployment."
"Let's measure the current cost," Gemini said, opening ROI Polygraph and entering the maintenance logs and staff interview results Tadokoro had provided.
"Here are the numbers," Gemini said, reading the screen. "Twenty general staff members generating errors and inquiries due to operational confusion: monthly average 30 hours. At ¥2,800/hour, that's ¥84,000/month. External vendor handling of support requests: 40 hours/month at ¥4,500/hour, ¥180,000/month. Total: ¥264,000/month in operating costs from this system alone. Annualized: ¥3,168,000."
Tadokoro's expression stiffened. "I was only looking at the maintenance fees. I'd never calculated the cost of staff time."
"Then let's begin the dissection with ECRS," I continued.
[E — Eliminate: Remove Unused Features]
"First, inventory every feature in the current system that is actually being used," Claude said. "If usage logs aren't available, distribute a one-page form to all staff. Two columns: 'Features I use every week' and 'Features I have never used.'"
A week later, Tadokoro returned with the aggregated results. The system had 47 features in total. 19 of them: not a single respondent had ever used them. 8 more: used once a month or less.
"27 out of 47 are functionally unused," Gemini summarized. "Migrating them to a no-code tool would mean importing all that complexity. We start by discarding those 27."
"Is there resistance to discarding them?" I asked Tadokoro.
"Yes," she answered immediately. "There's always a sense that they might be needed someday."
"That feeling is exactly where complexity comes from," Claude said quietly. "A feature that might be needed someday is a feature that is not being used today. We cannot allow the system to tell a comforting lie."
[C — Combine: Merge Overlapping Features]
"Of the 20 remaining features, we consolidate those that serve overlapping purposes," Gemini continued. "For example, if customer entry and project entry are on separate screens but could logically live on one screen, merge them. Duplication was created for the developer's convenience. We redesign it for the user's convenience."
Tadokoro scanned the list. "The customer master and the supplier master are separate. In practice, we often register the same company in both."
"That's a consolidation candidate," Claude said. "Merging them also reduces data entry errors. Eliminating the need to enter the same information in two places will reduce vendor support inquiries too."
[R — Rearrange: Reorder the Sequence of Operations]
"Next, rearrange the screen layout by frequency of use," I continued. "The most-used features are often the furthest away, because they were added in the order the developer implemented them."
"No-code platforms let you change this arrangement freely," Gemini added. "Only the three features everyone uses every day appear on the top screen. Everything else sits two layers in. This alone changes how long it takes a new hire to get up to speed."
"Right now it takes two months," Tadokoro said.
"We're projecting we can compress that to under three weeks," Claude replied. "When things are arranged by frequency, you learn naturally through use. A design that doesn't cause confusion lowers training costs."
[S — Simplify: Reduce the Whole to Its Simplest Form]
"Finally, we select the no-code platform to migrate to," I summarized. "After applying ECRS, the required feature count is 20—projected to consolidate to around 15. At this scale, a standard off-the-shelf no-code tool handles it. No custom development, minimal configuration. That is the endpoint of Simplify."
"Let's run a cost comparison through ROI Proposal Generator," Gemini proposed.
Current system annual costs vs. post-migration projections side by side:
- Current: Maintenance contract ¥2M/year + update fees ¥1.2M/year + staff operational loss ¥1M/year = ¥4.2M/year
- After no-code migration: Tool license ¥360K/year + initial setup ¥500K (year one only) + reduced staff operational loss ¥500K/year = ¥1.36M year one, ¥860K from year two onward
- Reduction effect: ¥2.84M in year one, ¥3.34M from year two onward
"What's the payback period?" Tadokoro leaned forward.
"Initial investment of ¥500K against a monthly reduction of approximately ¥130,000," Gemini answered. "Payback in four months."
Chapter 3: What Discarding Reveals
Tadokoro looked at the ECRS diagram on the whiteboard and said:
"I was afraid to discard things. A kind of respect for the person who built them. But keeping features nobody uses isn't respect for him, is it."
"What honors him is carrying forward the purpose behind what he built," Claude said. "Not the features themselves. At the time, that system was the best answer. Today's best answer looks different."
"The essence of ECRS," I continued, "is not about cutting. It's about finding what deserves to remain. Of 47 features, 20 were truly needed. Those 20 are the skeleton of TechNova's current operations. The new system gets built on top of that skeleton."
Tadokoro nodded quietly. "We'll start selecting a no-code platform next week. We'll bring the list of 20 features with us."
"Tell us how it goes in three months," Gemini said.
Chapter 4: The Day Everyone Could Touch It
Five months later, a report arrived from Tadokoro.
The migration to the no-code platform was completed in six weeks from initial configuration to go-live. New employee ramp-up time shortened from two months to eighteen days. The word "scary" no longer appeared in staff feedback, Tadokoro wrote.
Vendor support inquiries dropped from a monthly average of 15 to under 3. Monthly maintenance costs compressed from ¥180,000 to under ¥50,000. Staff operational loss hours fell from 30 to 12 per month. Total monthly reduction: ¥132,000—exactly in line with projections.
The final line of Tadokoro's report read: "During the migration, there were moments when we realized some discarded features were actually needed after all. But when we checked, we found the no-code tool already had equivalent functionality as a standard feature. 'Might be needed someday' turned out to be 'already exists.'"
The system nobody touched became a system everyone could use.
"A complex system was not built to solve complex problems. It was built simply—then accumulated features layer by layer over time. The four blades of ECRS—Eliminate, Combine, Rearrange, Simplify—work in reverse order, unwinding those accumulated layers. The fear of discarding comes from respect for whoever built what came before. But protecting features nobody uses is not respect—it is stagnation. What truly needs to remain is found in what survives after everything unnecessary has been removed."
Related Files
Tools Used
- ROI Polygraph — Maintenance cost and staff operational loss visualization
- ROI Proposal Generator — Current system vs. no-code migration payback simulation
