ROI Case File No.442 'The Ghost of Ten Years'
The Ghost of Ten Years
Chapter 1: Ten Years of Weight
"Just the customization costs alone — we probably could have bought an entirely new system by now."
Shinji Sasaki, Project Manager at Globex Corporation, said this with a wry smile as he laid out a list of system maintenance and modification costs spanning the past decade. The first two years showed standard maintenance fees, but by year three the numbers began to swell, reaching nearly triple in the most recent fiscal year.
"We implemented NEC's FactoryOne Intelligent Factory R3.0 ten years ago. We planned to run it on standard features, but we've been adding customizations every time the floor asked for something new. Today, no one outside the development vendor really understands what happens when you touch any given part of it."
"And now a server refresh is due," I confirmed.
"Yes. We're considering whether to migrate or upgrade while we have the opportunity. But —" Sasaki pulled out a document. "The vendor's quote came in at more than double what we expected. The cost to port the customized sections is enormous."
Claude quietly spoke up. "Could you show me the current system screen?"
Sasaki turned his laptop around. The screen displayed a dense grid of input fields. I counted the columns — over thirty.
"When a new employee joins," Sasaki said with a tired smile, "they spend the first month constantly asking senior staff where to input what. There are manuals, but they stopped keeping up with the customizations long ago. Now they're only useful as a rough reference."
The outline of the case came into focus. The problem was not system aging. The real issue was that no one had asked "what is this system for?" in ten years.
Chapter 2: The Fog Between Goals and Results
"This case calls for OKR."
Gemini wrote a large O and KR on the whiteboard.
"OKR stands for Objectives and Key Results," I began explaining. "The Objective is a qualitative declaration of the direction the organization should move. Key Results are quantitative indicators that prove you've reached the objective. Together they ensure that 'what we want to achieve' and 'what would count as achieving it' are aligned."
"This system has been missing exactly that," Claude pointed out, turning to Sasaki. "What was the purpose of the system when it was first deployed ten years ago?"
"Improving production management efficiency, I think. But the person in charge then has already retired, and I don't know the details."
"That's the root of it," I continued. "With an ambiguous objective, customizations piled up in response to floor requests, the system grew more complex, and nobody could see the whole picture anymore. Without OKR, the next system will repeat the same story."
[Objective: Make the production management system a tool the floor can run on its own]
"First, we set the Objective," Gemini wrote. "'Improve system usability and reduce costs' is a means, not an objective. What is the real Objective? Sasaki-san — in one sentence, what does the ideal state look like?"
Sasaki thought for a moment. "A system that a new member can start using without a manual. And maintenance costs that stay within a predictable range."
"That's it," Claude echoed. "'Build a self-running, predictable production management platform' — that is your Objective."
[Key Result 1: Reduce input fields from thirty-two to fifteen or fewer]
"The first Key Result is simplifying the screen," Gemini wrote. "Of the thirty-two input fields, let's check with ROI Polygraph how many are actually used in monthly aggregation."
After entering the past six months of system logs into the tool, the answer emerged. Eleven fields were regularly referenced. The remaining twenty-one were dormant — never used in any aggregation.
"Ten years of customizations, sitting there unused," I murmured. "This is what complexity actually looks like."
[Key Result 2: Reduce new user onboarding time from one month to one week]
"The second Key Result is the speed of onboarding," Claude continued. "Currently it takes new hires an average of four weeks to input data independently. Cut that to one week. Measure it by recording the input error rate at one week after joining."
"The third," Gemini added, "is to keep post-migration customization costs to thirty percent or less of current annual costs. To achieve that, commit to zero customizations on the new system, and create an operating rule that business processes adapt to the system instead."
Sasaki looked up. "Business adapts to the system — that's a complete reversal."
"The core failure of the past ten years," I replied, "was continuously adapting the system to the business. The more carefully you responded to floor requests, the more complex the system became. With the next system, it takes courage to keep only what the Objective demands, and change the process side for everything else."
Chapter 3: Laying the Ghost to Rest
Sasaki photographed the OKR on the whiteboard, then said quietly: "Honestly, I was focused entirely on which system to migrate to. But I understand now — before deciding the destination, this OKR needs to be agreed on internally."
"Exactly," I emphasized. "The first thing to show the migration vendor is not a requirements document — it's this OKR. You say: 'We are seeking these three Key Results to achieve this Objective.' That changes the quality of what the vendor proposes."
"The second effect of OKR," Claude added, "is aligning priorities across stakeholders. Management wants cost reduction, the floor wants usability, IT wants maintainability — when these conflict, the OKR becomes the decision-making standard. If everyone is looking at the same Objective, the discussion doesn't get lost."
"As a pilot plan," Gemini proposed, "complete the inventory of used fields and business processes for one line's worth of data over three weeks. Bring the Key Result figures you establish there into vendor negotiations. That sequence dramatically changes the likelihood of achieving cost reduction."
Sasaki stood and bowed deeply. "Thank you. This week, I'll share this OKR with both the executive team and the floor."
Chapter 4: The Quiet the Numbers Tell
After he left, Gemini murmured: "No one questioned the objective for ten years."
"That's right," I replied. "The floor staff who submitted the requests had no ill intent. Neither did the vendor who fulfilled them. Everyone was focused on solving the problem in front of them. Without an Objective as a north star, good intentions accumulate into a labyrinth."
Outside, the factory district was turning amber in the evening light.
Seven months later, a report arrived from Sasaki.
After sharing the OKR with the executive team, the floor, and the IT department, the three groups aligned on priorities for the first time. Migration to the new system was completed with zero customizations. Input fields were reduced from thirty-two to thirteen. New user onboarding dropped to an average of five days.
Annual maintenance costs fell forty-one percent compared to pre-migration — not a projection, but an actual result.
Sasaki wrote in his report: "In the process of creating the OKR, departments talked for the first time about 'what we actually want this system to achieve.' I realized we hadn't done that in ten years. We should have had that conversation before bringing in the next system."
The ghost of ten years was finally laid to rest — by the light of a clearly stated goal.
"System aging does not begin with technology. It begins with the loss of purpose. OKR provides a north star — the Objective — and a range-finder — the Key Results. With these two in place, you can ask each time a customization request comes in: does this move us closer to the Objective? The habit of asking that question is the greatest maintenance cost that protects the system ten years from now."
Related Files
Tools Used
- ROI Polygraph — Visualizes dormant fields and frequency-of-use inconsistencies
