ROI Case File No.569: 'They Searched for a Vendor While What They Wanted Stayed Vague'

They Searched for a Vendor While What They Wanted Stayed Vague

---

Chapter 1: I Have Something I Want to Build—but I Can't Put It into Words

"I want to build a system to automate design. But I don't know where to ask."

Taichi Yoken, R&D director at TechFusion, a general electronic-components maker, described the situation. "We used to focus on parts for AV and in-vehicle equipment, but now we're opening up new fields with IoT—infrastructure, government, agriculture. I want to streamline design work, so I'm considering an AI design-automation system. Learn from past design data and defect cases, and just enter the requirements to get an initial design drawing. I want to multiply each designer's throughput several times over."

"Are those requirements in a form you can convey to a vendor?" Claude asked.

"...They aren't," Yoken answered. "In my head there's 'this is what I want,' but I can't put it into words. I consulted several firms, but because our requests were vague, the proposals were all over the place. There was no way to compare them."

"How does your design work look now?" I asked, to confirm.

"Completely manual," Yoken answered. "It takes too much labor, and there's a ceiling on how much one person can handle. We're opening new fields, but design can't keep up. So I'm rushing to find a vendor, but what to ask isn't settled."

"Search while what you want stays vague, and good proposals won't gather," I replied. "Let's break this down with RFP."

Chapter 2: RFP Asks—Fix the Requirements into a Specification Before Choosing

"This case calls for RFP."

Claude wrote on the whiteboard: "Requirements, Specification, Comparison, Selection."

"RFP—Request For Proposal—fixes what you want into a specification, gathers each firm's proposals against it, compares, and chooses," I explained. "The key is not to search while the request stays vague. Drop what, why, and how far you want onto a specification. Only once the criterion is fixed can you compare each firm's proposals on the same yardstick. A tool for fixing the requirements before searching."

"First, let's measure the current cost," Gemini said, opening ROI Polygraph. The data Yoken provided was entered.

"Here is the monthly cost," Gemini read out. "Labor for manual design work: 200 hours per month on average, at ¥4,200 per hour, ¥840,000 per month. Opportunity loss from delayed design response for new business due to the ceiling on designer capacity: ¥440,000 per month. Vendor-selection floundering and rework cost from vague requirements: ¥360,000 per month. Duplicated design from not leveraging past design data and defect cases: ¥340,000 per month. Non-transferable-know-how risk from person-bound design: ¥320,000 per month. A total of ¥2,300,000 per month. Roughly ¥27.60 million per year."

Yoken stared at the figures. "I was only looking at the labor of manual work. Add the cost of vendor selection floundering on vague requirements, and it comes to this much."

"Then let's design it with RFP," I continued.

---

[Requirements—Put what you want into words]

"First, put the requirements into words," Claude said. "AI-driven design automation. A feature to learn from past design data and defect cases. Auto-generation of an initial design drawing from requirements input alone. Multiplying each designer's throughput several times over. Write out and fix the 'this is what I want' in your head."

---

[Specification—Drop the requirements onto a specification]

"Next, drop it onto a specification," Gemini continued. "Turn the requirements into a concrete spec a vendor can read and estimate against. What, at what precision, how far. The vague request becomes a comparable criterion. This is the foundation of the proposals."

---

[Comparison—Gather proposals on the same criterion]

"After specification, compare," I continued. "Receive proposals from multiple vendors against the fixed specification. Because they're issued on the same criterion, you can line them up and compare. Different from the scattered proposals gathered while vague."

---

[Selection—Choose the one firm that meets the requirements]

"Finally, select," Claude continued. "Compare and examine the proposals and choose the partner that best meets the requirements. Because the criterion is clear, you can explain the reason for the selection. Because the requirements are fixed, there's no rework after choosing, either."

---

[Estimating the payback]

"Let's run the numbers on ROI Proposal Generator," Gemini proposed.

• Initial cost: RFP-drafting support, building the design-automation system, learning from past data and defect cases, the drawing auto-generation feature, and partner-selection support—¥5.8 million total
• Monthly cost: system operation and maintenance combined, ¥230,000
• Monthly savings: automation of design work = ¥590,000 (assuming a 70% reduction); new-business response via expanded capacity = ¥440,000; eliminating selection floundering via clarified requirements = ¥360,000; reduced duplicated design via leveraging past data = ¥260,000; totaling ¥1,650,000 per month
• Net monthly savings: ¥1,650,000 − ¥230,000 = ¥1,420,000 per month
• Payback period: ¥5.8 million ÷ ¥1.42 million = about 4.1 months

"Just over four months to recoup," Gemini summarized. "What works is not searching while vague, but fixing the requirements into a specification before choosing. With vague requirements, proposals scatter and can't be compared, and selection flounders. Fix the criterion with RFP, and you can compare on the same yardstick. The investment doesn't miss."

Yoken checked the figures. "I thought finding a good vendor was enough. Unless you fix the requirements, you can't even judge good from bad."

"RFP is a tool for fixing the requirements into a specification before choosing," I replied.

Chapter 3: An Implementation Plan That Fixes the Requirements Before Choosing

"Let me lay out the approach," I said, standing at the whiteboard.

"Month one—put the requirements into words and draft the RFP (requirements specification). Month two—detail the specification and set evaluation criteria. Month three—request proposals from multiple vendors and compare them. Month four—select a partner and begin building the design-automation system. Month five—learn from past data and defect cases and implement the drawing auto-generation feature. Month six—trial operation and effect verification. Month seven onward—expand the scope of design response and extend to new business."

"Is it all right to spend time fixing the requirements?" Yoken asked.

"That's the shortcut," Claude replied. "Search in a hurry while vague, and proposals scatter; even after choosing, it doesn't match the requirements and you rework. Fix the requirements first with RFP, and vendors can estimate accurately while you compare on the same criterion. The effort of fixing is an investment that eliminates selection floundering and rework. Make haste slowly—you end up moving faster and steadier."

Yoken took notes. "Before searching for a vendor, fix the requirements into a specification. Now I see the order."

Chapter 4: The Day What They Wanted Became Words

Ten months later, a report arrived from Yoken.

After the system went in, design work grew far more efficient. "Fully manual design became something where you enter the requirements and an initial drawing appears. Each person's throughput multiplied several times, just as intended," Yoken wrote.

Vendor selection stopped floundering, too. Proposals based on the specification could be lined up and compared. "Proposals that had been all over the place could be compared on the same criterion. We could clearly explain the reason for our choice," the report read.

The biggest change showed in how they made requests. From searching while vague, to fixing the requirements before choosing. "It was only in my head, and I couldn't put it into words. Once dropped onto a specification, what I wanted became clear, and selection stopped floundering," Yoken wrote.

Past data came alive as well. Learning from design data and defect cases reduced duplicated design. "'The same kind of design from scratch' decreased. The past accumulation became usable," the report read.

As a side effect, the way procurement was viewed changed. Rather than searching for a good vendor, fixing the requirements took root. "We stopped starting from 'where to ask.' We started fixing 'what to ask' first," Yoken wrote.

At the end of Yoken's report was this: "I thought the design-automation struggle was that we couldn't find a good vendor. But the real problem was that we were searching for a vendor while what we wanted stayed vague. The moment we fixed the requirements into a specification with RFP, the partner to choose came into view. Before searching for a vendor, fixing the requirements came first."

The day a company that searched for a vendor while its wants stayed vague became a company that could choose after fixing the requirements, system adoption had shifted from a random vendor hunt to a design that fixes the requirements into a specification before choosing.

"System-adoption requests usually arrive as 'I want to find a good vendor.' But before searching for a vendor, there's a question to ask: can you put what you want into words? What RFP asks is requirements, specification, comparison, and selection. Fix the requirements into a specification, and you can compare proposals on the same yardstick. The day a company searching while vague could put its wants into words, what changed was not the vendor's quality but the very perspective that fixes the requirements into a specification before choosing."

---

Related Files

Tools Used

• ROI Polygraph — Visualizing manual design labor, vendor-selection floundering cost, and duplicated design
• ROI Proposal Generator — Payback simulation for design-automation system adoption, starting from turning the requirements into a specification