ROI Case File No.507 'The Factory Whose Other-Brand Machines Wouldn't Share Data'
The Factory Whose Other-Brand Machines Wouldn't Share Data
Chapter One: Visible Machines, Invisible Machines
"Inside the same factory, there are visible machines and invisible machines."
Kota Horii, DX Promotion Director at TechGear, opened the factory layout map. Kansai site. About forty machines from five different manufacturers. "Each manufacturer provides a visualization system for its own machines—but it only shows that manufacturer's equipment. The operating status of adjacent machines has to be checked on different screens."
"How far does the DX team want to take this?" Claude asked.
"Ultimately we want unified management across all group sites, but first we want something working at the Kansai site," Horii answered. "But the manufacturers are reluctant to expose their own data. We've asked for API releases, but answers stay in 'under consideration.' Data formats differ by manufacturer, so even before unification, standardization is needed."
"What does the floor look like operationally?" I asked.
"Supervisors check five visualization screens in sequence," Horii answered. "Each screen needs login. It takes time. As a result, check frequency drops, and stoppages get noticed later. Root cause analysis also requires aggregating each manufacturer's reports by hand."
"Are you trying to build the perfect unified system from the start?" Gemini asked.
"Yes," Horii answered. "Unify all manufacturers' data and manage every machine in real time. That's the proper end state, but vendor negotiations stalled and the project froze."
"Aiming at perfection from the start might be the cause of the stall," I replied. "Let's build something that runs first. With MVP."
Chapter Two: MVP Asks—Start Small and Functional
"This case calls for MVP."
Claude wrote three letters on the whiteboard. M, V, P.
"MVP stands for Minimum Viable Product—a development approach that verifies value with the minimum necessary functionality," I explained. "It's a Lean Startup concept, but it works for enterprise DX too. Trying to build a fully-featured release from the start gets bogged down in vendor talks and standardization, and the project freezes. Build the minimum that runs, use it on the floor, and expand from there. You reach completion faster that way."
"First, let's measure the current cost," Gemini said, opening ROI Polygraph. He input the data Horii provided.
"The monthly management cost has come out," Gemini read. "Three supervisors patrolling five screens average 180 hours per month at 3,800 yen per hour, or 684,000 yen monthly. Production losses from delayed stoppage detection average 2.2 million yen monthly—lowered check frequency from multi-screen patrolling is the cause. Per-manufacturer report aggregation labor for root cause analysis averages 80 hours per month, or 304,000 yen monthly. Opportunity cost from improvement delays because data isn't unified averages 600,000 yen monthly. Loss from DX project stagnation undermining executive trust averages 200,000 yen monthly—the cost of next-investment decisions being delayed. Total: 3.988 million yen monthly. Annualized: approximately 47.9 million yen."
Horii looked at the figures. "The patrolling cost is larger than I imagined."
"Now let's design with MVP," I continued.
[M—Minimum: Identify the Minimum Functionality]
"First, decide the minimum functionality," Claude said. "Unification of all manufacturer data is the ideal but not the starting target. What's possible now is screen scraping from each manufacturer's display, extracting just the operating state, and consolidating it into a single dashboard. We don't dig into the data contents—just the operating status. We can build that in one month."
"Screen scraping?" Horii confirmed.
"As long as APIs aren't forthcoming, we capture screen information," I replied. "Manufacturer talks continue in parallel, but we don't wait. Visualization of operating status alone meaningfully cuts the floor's check labor."
[V—Viable: Ensure Usability]
"Next, usability," Gemini continued. "Even minimum functionality must be valuable enough for the floor to keep using it. The minimum required: real-time display of operating status for all machines across all five manufacturers on a single screen. Alerting, historical analysis, and root cause analysis aren't in the minimum version. They'll be added later."
[P—Product: Make It a Real Product]
"We finish it as a product the floor can use," I continued. "Viewable from a tablet anywhere on the floor, a single login that reaches everything, color-coded status changes legible at a glance—at least these. Even with minimum functionality, without product-level polish, the floor won't use it."
[Expansion Roadmap]
"MVP is not a fixed end state," Claude continued. "We build an expansion roadmap in parallel. Phase 2: as manufacturer talks advance, integrate APIs and pull richer data. Phase 3: add alerting and root cause analysis. Phase 4: with Kansai operating results in hand, roll out to other sites. Each phase is an independent investment decision."
[Estimating the Payback]
"Let's run it through ROI Proposal Generator," Gemini proposed.
"MVP phase estimate."
- Initial cost: 3.2 million yen (MVP development—screen capture, dashboard unification, tablet devices, floor training)
- Monthly cost: 80,000 yen (MVP runtime platform)
- Monthly savings: screen patrol reduction = 480,000 yen (70% reduction assumed); delayed-detection reduction = 1.32 million yen (60% reduction assumed); report aggregation reduction = 210,000 yen. Total: 2.01 million yen monthly
- Net monthly savings: 2.01 million − 80,000 = 1.93 million yen
- MVP payback period: 3.2 million yen ÷ 1.93 million yen ≈ 1.7 months
"Under two months," Gemini summarized. "An early MVP payback makes later phases easier to approve. Build the perfect unified system for 50 million yen, or build an MVP for 3 million yen, verify the effect, and then expand—the latter is the more rational executive decision."
Horii looked at the numbers. "I'd been treating stalled vendor talks as the project's reason for being stalled. I never thought about moving the parts that could move first."
"If something runs, talks move," I replied.
Chapter Three: A Plan That Starts With What Runs
"Here's the implementation plan," I said, standing at the whiteboard.
"Week 1: technical validation of screen capture across the five manufacturers' displays. Weeks 2–3: dashboard design, operating-status extraction logic. Week 4: tablet deployment, on-floor trial. Weeks 5–6: adjustments from floor feedback, production launch. Weeks 7–8: accumulate Kansai operating results. Week 9 onward: continue manufacturer talks; manufacturers willing to integrate APIs proceed to Phase 2."
"Do we stop vendor talks?" Horii confirmed.
"Continue in parallel," Claude replied. "But don't wait for their outcome. Once the MVP shows results, manufacturers see their own machines displayed alongside competitors with limited information, which becomes their motivation to release APIs. The fact that something is running accelerates the talks."
Horii took notes. "We froze by aiming for perfect. I see that now."
Chapter Four: The Day Five Screens Became One
Eight months later, a report arrived from Horii.
Three months after MVP launch, supervisor screen-patrol labor fell 72% versus baseline. A single dashboard showed every machine's operating status across all five manufacturers. "It's not a patrol—one glance shows the whole picture. Check frequency rose dramatically," Horii wrote.
Stoppage detection accelerated sharply. Status changes were color-coded in real time, so a flag turning red was noticed instantly. "Average detection time dropped from twelve minutes to two minutes," the report said.
The most surprising change appeared in manufacturer behavior. After MVP launch, two manufacturers proactively proposed API integration. "Seeing that their own machines were the ones with less visible information became the manufacturers' motivation," Horii wrote. Phase 2 began earlier than projected.
In Phase 2, the two API-integrated manufacturers' data became available at detailed levels. Operating rates, stoppage reasons, and maintenance histories were unified. The remaining three manufacturers are now considering API release. "The psychology of 'wanting to join something that's already running' kicked in," the report said.
Site rollout also accelerated. After seeing the Kansai results, the East Japan and Chubu sites requested the same configuration. As Phase 3, simultaneous rollout across three sites is underway. "Demonstrated value at Kansai made it easier for other sites' executives to decide," Horii wrote.
As a side effect, the relationship between the floor and headquarters changed. Previous dissatisfaction—"HQ's DX initiatives don't understand the floor"—softened once the MVP was being used on the floor, and HQ-led DX initiatives became easier to accept. "Putting something that runs onto the floor produced effects beyond technology," the report said.
The final line of the report read: "A project frozen by aiming at perfection accelerated the moment a minimum viable product began running. The fact that something is running moved talks that had been stalled. MVP wasn't a compromise—it was a strategy."
The day patrolling five screens became checking one screen, what had been stalled wasn't the system but the decision, the report said.
"DX projects stall not on technology but on perfectionism. Trying to build a fully-featured release from the start multiplies coordination work, lengthens stakeholder negotiations, and freezes the project. MVP asks for minimizing what runs. Even minimum functionality, if it survives real use and feels like a product, produces value on the floor. The fact that something is running moves talks that have been stalled. The day five screens became one, what changed wasn't the number of screens but the speed of decision."
Related Files
Tools Used
- ROI Polygraph — Visualizing screen-patrol labor, delayed detection, and project-stagnation cost
- ROI Proposal Generator — Payback simulation for MVP staged deployment
