ROI Case File No.490 'High Functionality No One Could Use'
High Functionality No One Could Use
Chapter One: Twelve of a Hundred Features in Use
"We use 12 out of a hundred features."
Toshihiko Nishida, DX Promotion Project Lead at TechSphere, spread an OBIC7 feature list. Color-coded: green for in-use, yellow for tried-but-never-established, red for unused. Red dominated.
"Introduced three years ago," Nishida continued. "At the time, the parent company directed us to use a business system that could strictly comply with security standards, and OBIC7 was a candidate. It was correct in meeting the standard, but too many features for the field to use."
"Which departments struggle with operation?" Claude confirmed.
"The equipment sales department especially," Nishida answered. "Customer-info modification, quote changes, case-status updates—every daily operation has a complex screen, and even experienced staff find it cumbersome. Young staff struggle just opening the screen."
"Any option to simplify operations through customization?" Gemini asked.
"Vendor quote came back," Nishida answered. "¥2 million to simplify one screen, over ¥10 million to bundle multiple screens. That doesn't fit a mid-sized DX budget."
"What's the concrete content of the parent company's security standards?" I confirmed.
"Log retention period, multi-factor authentication, domestic data storage, audit log submission obligation—failing any of these blocks us from the parent group network," Nishida answered. "Many package products incur additional cost to meet these standards. OBIC7 supported them as standard, but running cost matched."
"How many in-house staff can draft system requirements?" Claude asked.
"Limited," Nishida answered. "The DX promotion project has four part-timers including me. Full-scratch development is unrealistic, and package selection is premised. Selection criteria aren't settled."
"Criteria don't settle when you don't look at self, competitor, and customer together," I said.
Chapter Two: The Three Perspectives 3C Demands
"This case needs 3C."
Claude wrote three letters on the whiteboard. C, C, C.
"3C is a framework for organizing strategy across three perspectives—Customer, Competitor, Company," I explained. "A marketing classic, but also applicable to system selection. Customer—in this case, the field staff who actually use the system—what do they want? Competitor—the system group in the market—how is it evolving? Company—TechSphere's constraints and strengths—what are they? Aligning three perspectives surfaces the optimal solution invisible in catalog comparison."
"Let's measure current cost first," Gemini said, opening ROI Polygraph. Nishida's operational logs went in.
"Monthly usability cost is out," Gemini read. "Equipment sales department's 25 staff use on average 350 hours monthly on OBIC7's complex operations. At ¥3,800/hour, ¥1.33 million monthly. Manual workarounds from customization-infeasibility 80 hours at ¥304,000. OBIC7 license ¥700,000. Maintenance and support contract ¥250,000. Total: ¥2.584 million monthly. Annualized: ¥31 million."
Nishida looked at the numbers. "Running cost alone over ¥30 million annually. Sufficient grounds for replacement."
"So, let's design with 3C," I continued.
[C—Customer: What Does the User Side Want]
"First, organize the voices of field staff who actually use the system," Claude said. "Interview the equipment sales department and narrow to three biggest pain points."
Nishida produced results of advance listening. "First, customer-info search is slow. Second, quote creation has many screen transitions. Third, mobile support is weak—can't check from the field."
"These three become mandatory requirements for new-system selection," I continued. "Not feature count, but improvement of the three points the field struggles with is the success criterion. Feature abundance has no value unused."
[C—Competitor: How Is the Market Evolving]
"Next, survey the system group in the market," Gemini continued. "The business-management system market broadly divides into three. First, major integrated package type like OBIC7—feature-rich but expensive. Second, industry-specialized cloud SaaS—mid-tier products specialized for facilities contractors exist. Third, no-code/low-code type—products that let you build screens in-house."
"Which suits?" Nishida asked.
"Considering TechSphere's scale and uniqueness balance, second or third," Claude answered. "But whether either meets the parent company's security standards requires verification beyond the catalog, through direct vendor confirmation."
[C—Company: What Are the Constraints and Strengths]
"Clarify company constraints," I continued. "First, parent company security standard—non-negotiable. Second, limited staff able to write system requirements—products requiring complex requirement definition can't be chosen. Third, DX budget scale—reintroducing a major package isn't realistic."
"Are there strengths too?" Nishida asked.
"Your field's experience using OBIC7," Gemini responded. "The experience of not being able to use it becomes material for concretizing the next system's selection criteria. 'This screen transition is too many,' 'This feature isn't used'—selection resolution is higher than a company without experience."
"Failed experience becomes the next asset," Nishida noted.
[Intersection of 3C—Narrow to the Optimal]
"When three perspectives align, candidates narrow," Claude continued. "Customer (field) demands usability, competitor (market) has industry-specialized SaaS and no-code type as leaders, company (TechSphere) requires parent security standards. Three or four products in the market meet these three conditions."
"Final selection is PoC?" Nishida confirmed.
"PoC," I answered. "After narrowing to three companies, three representatives from equipment sales each touch for one month and compare. Evaluate usability on three points: customer-info search, quote creation, mobile operation. In parallel, submit evaluation requests to the parent company security department. The product approved by both field and parent company is selected."
"Let's simulate with ROI Proposal Generator," Gemini suggested.
- Initial cost: New system introduction, data migration, parent security standard compliance, training totaling ¥7.8 million
- Monthly cost: New system ¥280,000/month (¥420,000 less than OBIC7)
- Monthly savings: Equipment sales operation labor reduction ¥800,000 (60% reduction assumed), manual workaround reduction ¥220,000, license and maintenance differential ¥670,000, totaling ¥1.69 million
- Net monthly savings: ¥1.69 million (license differential already included in savings)
- Payback period: ¥7.8M ÷ ¥1.69M ≈ 4.6 months
"Payback within five months," Gemini summarized. "From year two, approximately ¥20 million in annual net savings continues. Additionally, changing to a usable system accelerates sales activity speed. Hard to quantify directly, but appears as increased order opportunities."
Nishida reviewed the figures. "Selection criteria three years ago when we chose OBIC7 may have been insufficient. We only looked at security standards, not the field's usability. Organized with 3C, we can avoid repeating the same mistake next time."
Chapter Three: Toward a System That Fits
"Let me organize the approach," I said at the whiteboard.
"Month one—interview equipment sales and inventory used features. Among the 100 features of current OBIC7, list the 12 actually used and those originally wanted but not established. Month two—information collection on three candidate products and security evaluation requests. Months three and four—PoC execution, field evaluation. Month five—product decision and contract. Months six through nine—data migration and parallel operation. Month 10—complete switchover from OBIC7."
"What if PoC produces unexpected results?" Nishida confirmed.
"Assume unexpected results," Claude answered. "Products catalog-wise superior often don't fit the field in PoC. Agreeing at the start of the selection process to prioritize PoC results for judgment is important."
Nishida closed his notebook. "Three years ago, we decided by catalog. This time we decide by PoC—that alone seems to produce a different conclusion."
Chapter Four: The Day the Field Became the System's Ally
Ten months later, a report from Nishida arrived.
As a result of selection, an industry-specialized SaaS was adopted. The original first candidate had been no-code type, but in PoC the equipment sales department responded best to the industry-specialized one. "Industry-specialized standard features met the field's requirements more than catalog-level freedom," Nishida wrote.
For the parent company's security standards, at introduction the vendor implemented domestic data center migration and audit log output features. Additional cost was approximately ¥1.2 million, within the original budget.
Three months after launch, equipment sales operational labor dropped 68% from the previous level. Exceeded the projected improvement. "Fewer screen transitions, more work completing on mobile," Nishida wrote. Particularly, mobile support produced unexpected effects; on-site case registration established, and overtime for daily-report creation nearly vanished.
Customer-info search speed shortened from an average of 23 seconds to under 2 seconds. "Waiting time dropped, and we can now produce information on the spot during customer calls"—a sales representative's comment was attached to the report.
The biggest change was in field attitude. In the OBIC7 era, the feeling of "being used by the system" was strong; with the new system, multiple voices said "the system became an ally." Nishida concluded the report: "Three years ago, we chose high functionality. This time, we chose one's own size. Feature abundance isn't value; only features used in the field are value."
An inquiry came from the parent company, noting similar challenges at other group subsidiaries and a desire to reference TechSphere's selection process.
A day when high functionality no one could use became features that could be used.
"High functionality isn't value. Only used features are value. 3C's three perspectives—customer, competitor, company—align and the optimal invisible in catalog comparison appears. What is the customer-field struggling with? How is the competitor-market evolving? What are TechSphere's constraints and strengths? At the intersection of three is a system that fits one's own size. Three years ago choosing high functionality, now choosing one's own size. Not the number of features, but the number of used features, was moving the business."
Related Files
Tools Used
- ROI Polygraph — Visualizing usability labor and license cost
- ROI Proposal Generator — Business system replacement payback simulation
