ROI Case File No.544: No One Had Built the Premise That People Would Disappear Into the Design
No One Had Built the Premise That People Would Disappear Into the Design
Chapter 1: People Are Decreasing, yet We Stayed Dependent on People
"We want to build an operational structure that doesn't depend on people. But we don't know where to start."
Yutaka Kamaishi, representative director of EcoWaste Solutions, said this with a sense of crisis showing through. An industrial-waste processing company operating an incineration facility. "The working population is shrinking, and our employees are aging too. Even when we hire, retention is low—securing talent is genuinely hard."
"What's the age makeup on the floor?" Claude asked.
"The average is thirty-six or thirty-seven, but near-retirement veterans and younger staff are mixed," Kamaishi answered. "I want to improve the work before the veterans nearing retirement leave. But not knowing what to do, we're stuck searching for cases from other companies in the industry."
"Have you ever split and measured the work that can be automated from the work only people can do?" I confirmed.
"No," Kamaishi answered. "We lump it all together as 'we're short on people.' Paper manifests and electronic manifests are mixed, the server sits on-premises, the issues pile up. But we can't split out where to automate."
"If the premise is that people will decrease, then we first need to split the work and narrow down where automation works," I responded. "Let's break this down with STP."
Chapter 2: What STP Asks—Segmentation, Targeting, Positioning
"This case needs STP."
Claude wrote "S, T, P" on the whiteboard.
"STP is a framework that narrows a target across three stages: Segmentation, Targeting, and Positioning," I explained. "It originally came from marketing, but it works for operational improvement too. Split the work into 'parts that depend on people' and 'parts that can be automated,' select the parts where automation works highly, and set the positioning of the measures. It's a tool that builds the premise of people decreasing into the design."
"First, let's measure the current cost," Gemini said, opening the ROI Polygraph. He entered the data Kamaishi had provided.
"The monthly cost is in," Gemini read out. "Personnel-dependency and handover labor for people-dependent work: 230 hours per month on average, at ¥4,000 per hour, ¥920,000 per month. Processing and transcription labor from mixed paper and electronic manifests: ¥500,000 per month on average. Vacancy and re-hiring cost from recruiting difficulty and lower retention: ¥600,000 per month on average. Physical risk and maintenance cost of the on-premises server: ¥350,000 per month on average. Expected value of the skill-succession risk tied to senior-employee retirement: ¥480,000 per month on average. A total of ¥2,850,000 per month. Annualized, about ¥34,200,000."
Kamaishi stared at the figures. "We only saw it as a labor shortage. Turn the lower retention and the succession risk of veterans leaving into amounts, and it's this much?"
"Now, let's design with STP," I continued.
[Segmentation—Split the Work Into People-Dependent and Automatable]
"First, we split the work," Claude said. "We divide it into parts that need on-the-floor judgment and parts that can be automated as routine, and measure the volume of each. Paper-and-electronic manifest processing, server maintenance, reporting work—we carve up the people-dependent mass by whether it can be automated."
[Targeting—Select the Work Where Automation Works Highly]
"Next, we select the work where automation works," Gemini continued. "The mix of paper and electronic manifests works greatly if we push electronification. We focus on the high-effect work. Rather than automating everything at once, we aim from the single point that works."
[Positioning—Position the Measures Company-Wide]
"For the selected work, we position the measures," I continued. "We reduce physical risk by moving from on-premises to the cloud, and put RPA into routine work. As a structure that runs even as people decrease, we position the measures company-wide."
[Building in Succession—Move the Veterans' Knowledge Into the Mechanism]
"Finally, we move the veterans' knowledge into the mechanism," Claude continued. "We drop the judgment that near-retirement employees hold into procedures and data. Before people leave, we build their knowledge into the automation design. This is the core of the transition away from people-dependency."
[Calculating the Investment Recovery]
"Let's run the estimate with the ROI Proposal Generator," Gemini proposed.
- Initial cost: Work-split research, electronic-manifest infrastructure, cloud migration, RPA adoption, knowledge-succession mechanization, and training—¥6,000,000 total
- Monthly cost: Cloud operation, licensing, and update ongoing fees combined, ¥300,000 per month
- Monthly reduction effect: Automation and standardization of people-dependent work = ¥640,000 per month (assuming 70% reduction), transcription reduction from electronic-manifest adoption = ¥380,000 per month, retention improvement and vacancy mitigation effect = ¥420,000 per month, maintenance and risk reduction from cloud migration = ¥280,000 per month, totaling ¥1,720,000 per month
- Net monthly reduction: ¥1,720,000 − ¥300,000 = ¥1,420,000 per month
- Payback period: ¥6,000,000 ÷ ¥1,420,000 = approximately 4.2 months
"Recovery in just over four months," Gemini summarized. "What works is splitting the work and aiming only at the parts where automation works. Rather than peeling everything off of people's hands, we enter from the high-effect electronic manifests and cloud migration. Because we build the premise of people decreasing into the design, it runs even after the veterans leave."
Kamaishi confirmed the figures. "I lumped it as 'short on people.' Split it and narrow down what can be automated, and where we can reduce headcount becomes visible."
"STP is a tool that builds the premise of people decreasing into the design," I responded.
Chapter 3: A Deployment Plan That Automates From the Point That Works
"Let me organize the approach," I said, standing at the whiteboard.
"Months one and two—splitting the work, carving up people-dependent versus automatable and measuring volume. Month three—selecting the work where automation works, fixing electronic manifests and cloud migration. Months four and five—cloud migration and RPA adoption, infrastructure build. Month six—mechanizing veteran knowledge, dropping it into procedures and data. Month seven—trial operation on part of the work and effect verification. Month eight onward—expanding the automation scope, establishing a structure that doesn't depend on people."
"Will it make it in time before the veterans quit?" Kamaishi confirmed.
"That's why we build the knowledge succession into the design," Claude responded. "Rather than panicking after people leave, we move the judgment into the mechanism while they're still here. Because the split has pinpointed 'which work needs the veterans' knowledge,' we can succeed it as a priority. Build the premise of people decreasing into the design, and retirement stops being a crisis."
Kamaishi said, taking notes, "We hadn't built the premise that people would disappear into the design. Split the work and narrow the automation, and we can transition."
Chapter 4: The Day a Structure Not Dependent on People Came Into View
Ten months later, a report arrived from Kamaishi.
Work that had depended on people saw automation advance through RPA adoption and standardization. "Routine work came to run by mechanism. The premise of 'it stops without a person' began to crumble," Kamaishi wrote.
The mix of paper and electronic manifests was resolved too. With electronification pushed, the transcription chore vanished. "The work of finding paper and re-keying it into electronic form disappeared. Mix-ups from the blend also went away," the report read.
The biggest change appeared in how they faced veteran retirement. The anxiety of 'it stops once they leave' thinned. "We were able to move near-retirement employees' judgment into procedures and data. The tightrope walk of 'it won't run if that person quits' vanished," Kamaishi wrote.
The physical risk of the on-premises server was resolved too. With cloud migration, the worry of maintenance and disaster dropped. "We stopped depending on our in-house server room. We were freed from physical risk," the report read.
As a secondary effect, the recruiting picture changed. With the outdated operational culture improved, retention turned upward. "We can now say 'we're a company that doesn't lean entirely on people.' Young staff became less likely to quit," Kamaishi wrote.
At the end of Kamaishi's report it said: "A labor shortage couldn't be solved as a lump. The moment we split the work with STP and narrowed the parts where automation works, we built the premise of people decreasing into the design. The premise that people will disappear becomes preparation only once it is put into the design."
The day a company where no one had built the premise of people disappearing into the design became a company that could picture a structure not dependent on people, DX promotion had changed from lamenting the labor shortage into a design that splits the work and narrows the automation, the report noted.
"DX consultations in industries where securing talent is hard share something in common. Though they know people will decrease, the design stays dependent on people. They merely lament 'we're short on people' as a lump, and which work to peel off of people never gets decided. What STP asks is segmentation, targeting, positioning. Carve the work into people-dependent and automatable, choose the parts that work, and position the measures. The day a company that hadn't built the premise of people disappearing into the design could picture a structure not dependent on people, what changed was not RPA but the very perspective that builds the premise of people decreasing into the design."
Related Files
Tools Used
- ROI Polygraph — Visualizing people-dependent labor, manifest-mix cost, and skill-succession risk
- ROI Proposal Generator — Investment-recovery simulation for work-split-rooted DX promotion
