ROI Case File No.441 'The Job Sleeping in the Paper Graveyard'
The Job Sleeping in the Paper Graveyard
Chapter 1: The Factory Where Paper Piles Up
"Sometimes we can't find a daily report. They just disappear."
Seiichi Tanaka, Production Manager at TechFusion, placed a thick binder on the desk as he spoke. Daily production logs, quality inspection records, equipment maintenance reports — a stack of documents nearly twelve inches tall sat before us.
"Our company manufactures precision components, and we have around 150 people working on the factory floor. We run six production lines. Every day, the line operators fill out handwritten daily reports, and the quality control department collects and reviews them. We've been doing this for over twenty years."
"When did the problems start?" I asked.
Tanaka paused briefly. "Last autumn. When a quality complaint came in, it took us three days just to locate the relevant reports. The delay in responding to the customer damaged the business relationship."
"So the push for DX came from," Claude confirmed, "that incident with the delayed complaint response?"
"Yes. Although —" Tanaka lowered his voice. "Management says 'go digital.' But the floor staff are used to the paper system. I'm worried that even if we bring in a new system, no one will use it."
That single concern pointed straight to the heart of the case. On the surface, the request was about "digitization." But the real problem was buried somewhere deeper.
Chapter 2: The True Nature of the Job
"Let me start by organizing the current data in ROI Polygraph."
Gemini opened a laptop and began entering TechFusion's pre-supplied workflow data into ROI Polygraph, a tool we use daily to visualize inconsistencies between numbers and business processes.
"Some interesting numbers here," Gemini said, pointing at the screen. "On average, it takes twenty minutes per person to fill out a daily report. With six lines and three operators each, total daily input effort is 360 minutes — six hours. Yet only eighteen percent of that information is actually used for next-day production decisions."
"In other words," I continued, "the reports are being written but not used. The information exists, but it's dead."
Tanaka's eyes widened. "When you put it that way — maybe filling out the report has become the goal in itself."
"This is where we apply JTBD — Job To Be Done theory," Claude said, rising and moving to the whiteboard.
"JTBD stands for Job To Be Done. The concept is that people don't buy products or services; they hire them to get a specific 'job' done. So what is the real job TechFusion wants to accomplish by implementing a system?"
"Responding quickly to quality complaints?" Tanaka offered.
"That's a result," Claude continued. "If we go one level deeper — 'I want to be in a state where, when a problem occurs, I can identify the cause instantly.' That's the functional job. And behind that is an emotional job: 'I want to feel confident that the floor can solve problems on its own, before management has to get involved.'"
Tanaka nodded slowly. "Exactly. After last year's complaint, I was called in by the executive team. I never want to go through that again."
"In that case," I summarized, "the system requirements change entirely. Simply digitizing the reports is not enough. What's needed is a mechanism that, the moment an anomaly occurs, cross-references historical data to surface the likely cause."
Chapter 3: Three Jobs on One Sheet
Claude drew three layers on the whiteboard.
[Functional Job: Make data findable]
"The first layer is the most straightforward functional job," Claude explained. "Digitize the daily reports and quality records so they can be searched instantly by keyword or date. That alone would cut the three-day root-cause investigation from last year's complaint to a matter of minutes."
"As a concrete KPI," Gemini added, "set a target of reducing the lead time to identify root causes during complaints from the current average of 2.8 days to within four hours."
[Emotional Job: Enable the floor to act proactively]
"The second layer is the job Tanaka-san truly wanted to solve," Claude continued. "When floor operators enter a report, it's shared with the quality control team in real time — and if there's a sign of an anomaly, they receive an immediate alert. That way, the floor can address issues before they escalate."
"This is a fundamental design philosophy shift," I emphasized. "The daily report transforms from a 'report' into a 'sensor.' The floor moves from reactive to proactive."
Tanaka's expression changed. "If that's possible — the floor's motivation would change too. Right now, nothing changes when they write the reports, so it's become a formality."
[Social Job: Prove DX success as a model for the entire company]
"The third layer," Gemini noted, "is often overlooked but critical. TechFusion has made DX a company-wide theme. If this project succeeds, it becomes a rollout model for other departments. Building in 'horizontal scalability' from the start dramatically affects the return on investment."
"Let me run the numbers in ROI Proposal Generator," I suggested, opening ROI Proposal Generator. The inputs — reduced report labor hours, lower complaint response costs, quality improvements and defect rate reduction — yielded a projected payback period of fourteen months.
"If you expand from six lines to all factory floors," Gemini added, "the payback shrinks to nine months."
Chapter 4: The Morning the Job Wakes Up
Tanaka copied down the three-layer job framework and nodded deeply.
"I thought 'deploying a system' was the goal. But the real job was creating an environment where the floor could face problems with confidence."
"The essence of JTBD," I replied, "is not confusing means with ends. Digitization is not the job — it's a means to accomplish the job. Get this order wrong, and you end up building a system nobody uses."
"The reason floor operators resist new systems," Claude added, "is that their emotional job isn't being satisfied. The feeling that 'the data I entered is actually doing something' — without that, even the most convenient system becomes hollow."
"As a starting point," Gemini suggested, "run a three-month pilot on one line. Each week, gather feedback from the operators to confirm whether the functional, emotional, and social jobs are all being met. Use those results to decide whether to expand to the remaining five lines."
Tanaka stood, bowing deeply. "Thank you. Next week, I'll start by bringing the floor staff together to talk about jobs."
Five months later, a report arrived from TechFusion.
After the pilot, the system was expanded to all six lines. Lead time for root cause identification during complaints dropped from an average of 2.8 days to 3 hours and 40 minutes. Digitization of quality records made defect patterns visible, and the monthly defect rate improved by twenty-three percent compared to pre-implementation.
But what Tanaka valued most lay beyond the numbers. One floor operator, on their own initiative, noticed signs of an anomaly and made the call to stop the line. If the line had not been stopped, losses exceeding one million yen in defective product would have been possible.
Tanaka wrote this at the end of his report: "The floor changed. I think it's because the meaning of writing the daily report changed. Realizing that the data is alive — that's what changes people."
The job that had been sleeping in the paper graveyard had finally woken up.
"Deploying a system is not a job. A job is the work someone wants to get done in a given situation. What JTBD asks is whether you can place the three layers of jobs — functional, emotional, and social — at the starting point of your design. Start from the means, and you build a system nobody uses. Start from the job, and you build a mechanism the floor activates on its own. The difference lies not in the budget, but in the order of the questions."
Related Files
Tools Used
- ROI Polygraph — Visualizes contradictions in workflow and blind spots in the numbers
- ROI Proposal Generator — Calculates ROI and auto-generates proposal documents
