ROI Case File No.557: 'Every Demo Looked Good, and We Couldn't Choose'
Every Demo Looked Good, and We Couldn't Choose
Chapter 1: The More You Hear the Pitch, the Less You Can Choose
"We want to advance DX in the medical field. But we don't have anyone in-house who can judge which tool to choose."
Shunichi Minai, head of the corporate-planning office at MediTech Solutions, described his situation as he spoke. His company advances digitization in the medical industry. "We get demos and pitches from vendors, but they all look good. Once you hear the performance talk, every one of them seems like it should be adopted. We have no axis for comparison."
"So comparison is hard," Claude asked.
"It's hard," Minai answered. "And there are several national subsidies, and we can't tell which tool they apply to or how to use them. Medicine has a lot of analog work, and we want to cut headcount and improve efficiency with digitization, but we're stuck at the entrance."
"Do you separate the work by scene and look at what fits each?" I asked, to confirm.
"No, we look at it per tool," Minai answered. "'This AI is high-performance,' 'that RPA is cheap'—we compare by the merits of the tool. We hadn't taken the view of which scene of which work it works on."
"As long as you compare per tool, they all look good and you can't choose," I replied. "Let's break it down with SCENE_CAST."
Chapter 2: SCENE_CAST Asks—Cast the Optimal Set per Scene
"This case calls for SCENE_CAST."
Claude wrote "SCENE_CAST" on the whiteboard.
"SCENE_CAST—scene cast—is a framework that divides work by scene and swaps in the optimal set of tools to cast onto each," I explained. "The key is choosing from the scene, not the tool. The same AI works in the scene of patient-data analysis and is wasted in another scene. Every demo looks good because you compare performance without deciding the scene. Decide the scene first and the tool to cast gets decided."
"Let's measure the current cost first," Gemini said, opening ROI Polygraph, and entered the data Minai had provided.
"The monthly cost is in," Gemini read out. "Manual hours for patient-data analysis, record creation, and the like average 180 hours a month; at ¥4,300 an hour, that's ¥774,000 a month. Stalled adoption and idle comparison hours from being unable to judge vendor selection average ¥420,000 a month. Lost opportunity from un-utilized subsidies due to unclear application targets and usage averages ¥400,000 a month. Inefficiency from analog work centered on paper and manual labor averages ¥380,000 a month. The risk of delayed decision-making from the absence of specialist talent averages ¥320,000 a month. The total is ¥2,294,000 a month—roughly ¥27.53 million a year."
Minai stared at the figures. "I thought it was just the manual hours. Once you include being unable to choose itself and not being able to use the subsidies, I never imagined it would be this much."
"Then let's design it with SCENE_CAST," I continued.
[Decompose the scenes—Split the work by scene]
"First, we split the in-hospital work by scene," Claude said. "Patient-data analysis, conference record creation, reception handling—rather than lumping the work together, we split it into scenes. We first distinguish the scenes where digitization works from those where it doesn't."
[Define the set—Decide the tools each scene needs]
"Next, we define the set of tools to cast onto each scene," Gemini continued. "Generative AI for the data-analysis scene, RPA for the routine-processing scene. We decide the tools each scene needs. We choose by fit to the scene, not by height of performance."
[Swap—Replace with the optimal set per scene]
"After the set, we evaluate the vendor proposals on the scene's criteria," I continued. "On top of performance and cost, we add whether the subsidy applies to the evaluation axis. We swap in the optimal set per scene. The hesitation of every demo looking good vanishes on the scene criterion."
[Verify—Enter from the high-impact scenes]
"Finally, we phase in from the high-impact scenes and verify," Claude continued. "We enter from scenes with large automation impact, like patient-data analysis and record creation. We measure the effect per scene and confirm before the next. Rather than entering everything at once, we stack from the scenes that work."
[Estimating the payback]
"Let's run the numbers with ROI Proposal Generator," Gemini proposed.
- Initial cost: Work-scene inventory, tool evaluation and selection, phased rollout (patient-data analysis / record automation), and subsidy-application support—¥5,500,000 total
- Monthly cost: System operations and ongoing model updates combined—¥240,000 a month
- Monthly savings: Patient-data analysis and record automation = ¥620,000 a month (assuming an 80% reduction); selection stall resolved = ¥340,000 a month; effective cost reduced by subsidy utilization = ¥320,000 a month; analog work reduced = ¥300,000 a month; ¥1,580,000 a month total
- Net monthly savings: ¥1,580,000 − ¥240,000 = ¥1,340,000 a month
- Payback period: ¥5,500,000 ÷ ¥1,340,000 = about 4.1 months
"Payback in just over four months," Gemini summarized. "What works is casting the optimal set per scene rather than choosing by tool performance. Every demo looks good because you haven't decided the scene. Because you split the scenes first and enter from the scenes that work, the investment doesn't whiff. Subsidies, too, lower the effective cost when utilized to match the scene."
Minai said, checking the figures, "I'd been trying to choose by the merits of the tool. Seen from the scene, what to cast onto which scene gets decided."
"SCENE_CAST is the tool that casts the optimal tool per scene," I replied.
Chapter 3: A Rollout Plan That Casts from the Scene
"Let me lay out the approach," I said, standing at the whiteboard.
"Month 1—decompose the in-hospital work by scene and pin down where digitization works. Month 2—define the toolset for each scene and organize the subsidy applications. Months 3–4—phased rollout to the high-impact scenes (patient-data analysis, record creation). Month 5—verify the effect per scene. Month 6—deploy to the next scene. Month 7 onward—expanding the rollout scope and continuous tool updates utilizing subsidies."
"Can the subsidies really be utilized?" Minai asked, to confirm.
"They can be utilized," Claude replied. "Subsidies go unused because you look at which tool they apply to separated from the scene. With SCENE_CAST, we cast tools per scene and put the subsidy applicability into that evaluation axis. Because you choose a subsidy-eligible tool that fits the scene, the effective cost drops. Even without specialist talent, the scene becomes the axis of judgment."
Minai said, taking notes, "Before choosing from the tool, cast from the scene. I can see the order now."
Chapter 4: The Day the Hesitation Vanished
Nine months later, a report arrived from Minai.
Patient-data analysis and record creation were greatly streamlined after generative AI and RPA were introduced. "Data we'd analyzed by hand is now processed automatically. Conference record creation, too, left human hands," Minai had written.
The hesitation over vendor selection also vanished. Evaluating on per-scene criteria created an axis for comparison. "What we couldn't choose because every demo looked good, we could now judge by whether it fits the scene. The spinning of comparison stopped," the report said.
The biggest change appeared in how they chose. From hesitating over tool performance, it changed to a state of casting onto scenes and choosing. "We'd been stuck on 'which is high-performance.' Once we split the scenes first, what to cast onto which scene got decided. The hesitation vanished," Minai had written.
The subsidies could be utilized, too. Choosing eligible tools to match the scene lowered the rollout cost. "A subsidy we could use but weren't using worked," the report said.
As a secondary effect, the basis for judgment changed. The idea of casting tools from the scene took root in the organization. "We stopped arguing the merits of a tool on its own. We came to choose by which scene it works on," Minai had written.
At the end of his report, he wrote: "I thought the medical-DX trouble was the absence of talent who can judge. But the real problem was not splitting the scenes and comparing only by tool performance. The moment we split it into scenes with SCENE_CAST, the hesitation of every demo looking good vanished. Before choosing a tool, splitting the scenes came first."
The day a company where every demo looked good and couldn't be chosen became a company that could cast from the scene and choose, medical DX had changed from comparing tool performance into a design that swaps in the optimal set per scene, the report noted.
"DX requests usually come in the form of 'which tool should we choose.' But there's something to ask before choosing. Which scene of which work do you want it to work on? What SCENE_CAST asks is the optimal set of tools per scene. Split the scenes and the hesitation of every demo looking good vanishes. The day a company where every demo looked good and couldn't be chosen could cast from the scene, what changed wasn't the tool performance but the very perspective that chooses from the scene rather than the tool."
Related Files
Tools Used
- ROI Polygraph — Visualizing patient-data analysis hours, selection-stall cost, and lost opportunity from un-utilized subsidies
- ROI Proposal Generator — Payback simulation for medical DX starting from per-scene optimization
