ROI Case File No.314 | 'Koike's Invisible Knowledge'

Chapter 1: The Maze of Fragmentation—One Day to Search, Nothing Found

The week after AquaCall's KPT case was resolved, a consultation arrived from Chiba regarding information management at a chemical wholesaler. Case File 314 of Volume 26, "The Pursuit of Reproducibility," tells the story of connecting scattered databases by meaning and transforming search time into thinking time.

"Detective, our company has 6 databases. Customer information, inventory information, product specifications, past transaction records, complaint history, technical documents... However, they're managed by department and cross-database search isn't possible. It takes a full day for sales to research 'which customers did we deliver this product to in the past.'"

Seiichi Koike, Information Systems Manager of Koike Data Systems Co., born in Ichikawa, visited 221B Baker Street with exhaustion written across his face. In his hands were diagrams of the 6 system configurations and, in stark contrast, a business efficiency project report marked "unable to search."

"We're a chemical and industrial chemical wholesaler in Chiba. We handle about 8,000 types of chemicals for manufacturers, research institutions, and universities. We have 62 employees. However, information is fragmented by department."

Koike's Information Search Stagnation: - Established: 1985 (chemical wholesaler) - Annual Revenue: 3.8 billion yen - Employees: 62 - Product Range: About 8,000 types - Number of Databases: 6 (independent by department) - Average Search Time: 2.5 hours per case - Monthly Search Requests: About 180 cases - Problem: Data not shared between departments, decision-making delayed

Koike's voice carried deep anxiety.

"The problem is that each department built databases independently. Sales has 'Customer DB,' Logistics has 'Inventory DB,' Technical has 'Product Specification DB'... Each managed with different systems and different naming conventions. Even if we try cross-database search, data formats are too different to integrate."

Typical Search Difficulty:

One Day, Salesperson A:

Customer inquiry: "Is there a product with the same performance as 'Catalyst X' we purchased from you 5 years ago? Preferably at a lower price."

Salesperson A: "Understood. I'll research and get back to you."

Search Work Begins (10:00 AM):

Step 1: Check past transaction records (Sales Department's Customer DB) - Log into system - Search by customer name - Look for transactions from 5 years ago - Found: "Catalyst X, Product Code: CAT-2018-45"

Step 2: Check product specifications (Technical Department's Product Specification DB) - Log into different system - Search for product code "CAT-2018-45" - Result: "Not found"

Salesperson A: "Strange... why can't I find it?"

Calls Technical Department: "Excuse me, can you tell me the specifications for CAT-2018-45?"

Technical Department Staff: "CAT-2018-45? In our system it's registered as 'CAT2018-45' (no hyphen). Different naming convention."

Salesperson A: "...I see."

Step 3: Confirm product specifications (re-search without hyphen) - Found: "Catalyst X, Main component: platinum, Purity 95%, Particle size 1μm"

Step 4: Search for similar products (condition search in Product Specification DB) - Conditions: "Main component=platinum" "Purity≥90%" "Particle size≤2μm" - Results: 28 hits

Step 5: Check prices (Logistics Department's Inventory DB) - Log into yet another system - Check price for each of 28 items - Time required: 1 hour

Step 6: Check past complaint history (Quality Management Department's Complaint DB) - Exclude products with past complaints from 28 items - Time required: 30 minutes

Search Complete (2:30 PM) Time required: 4.5 hours

Salesperson A was exhausted.

"Finally found it... But taking this much time..."

Chapter 2: The Wall of Format—Data Doesn't Connect, Knowledge Sleeps

"Koike-san, have you previously attempted to integrate the databases?"

To my question, Koike answered.

"We tried 2 years ago. We attempted to migrate 6 DBs into one integrated DB. However, we failed. Data formats, naming conventions, field names... everything was too different to integrate. Cost was also estimated at 12 million yen, so we gave up."

Current Approach (Integration Type): - Countermeasure: Integrate all DBs into one - Problem: High cost, technically difficult - Result: Abandoned

I explained the importance of information restructuring.

"No need to integrate. Just connect. LOGIC—Link, Observe, Group, Interpret, Connect. Connect by meaning without changing data format. This is the essence of information search."

⬜️ ChatGPT | Catalyst of Conception

"Don't integrate. Connect. Link data by meaning with LOGIC."

🟧 Claude | Alchemist of Narrative

"Reducing search time means increasing thinking time. Information becomes knowledge only when connected."

🟦 Gemini | Compass of Reason

"LOGIC is the technology of information restructuring. Raise question quality through the 5 stages of Link, Observe, Group, Interpret, Connect."

The three members began their analysis. Gemini unfolded the "LOGIC Framework" on the whiteboard.

LOGIC's 5 Steps: 1. Link: Map relationships between data items 2. Observe: Analyze search logs and understand usage trends 3. Group: Cluster by attributes 4. Interpret: Semantic search with natural language 5. Connect: Connect results to BI for immediate reporting

"Koike-san, let's restructure Koike's 6 DBs with LOGIC."

Chapter 3: The Map of Relationships—Building Bridges Between Scattered Data

Phase 1: Link - Data Item Mapping (4 weeks)

First, we extracted items from the 6 DBs and organized their relationships.

6 DBs: 1. Sales Dept: Customer DB (customer information, transaction history) 2. Logistics Dept: Inventory DB (product codes, stock quantity, prices) 3. Technical Dept: Product Specification DB (product codes, main components, purity, particle size) 4. Quality Management Dept: Complaint DB (product codes, complaint content) 5. Accounting Dept: Sales DB (customers, products, sales amounts) 6. General Affairs Dept: Technical Document DB (products, PDF documents)

Problems: - Product code naming conventions differ - Sales DB: "CAT-2018-45" (with hyphen) - Technical DB: "CAT2018-45" (no hyphen) - Inventory DB: "CAT/2018/45" (slash-separated) - Customer name variations - Sales DB: "ABC Manufacturing Co., Ltd." - Accounting DB: "ABC Manufacturing Co." - Complaint DB: "ABC Manufacturing"

Creating Relationship Mapping:

Define product code normalization rules:

CAT-2018-45 = CAT2018-45 = CAT/2018/45
→ All normalized to "CAT201845" for searching

Define customer name normalization rules:

ABC Manufacturing Co., Ltd. = ABC Manufacturing Co. = ABC Manufacturing
→ All normalized to "ABC Manufacturing" for searching

Creating Relationship Tables: - Product Code Relationship Table: Convert product codes across DBs - Customer Name Relationship Table: Convert customer names across DBs

After 4 weeks: Relationship mapping between 6 DBs completed

Phase 2: Observe - Search Log Analysis (2 weeks)

Next, we analyzed search logs from the past 6 months.

Search Log Analysis Findings:

Frequently Searched Combinations: 1. "Product name" + "Customer name" (42%) 2. "Product name" + "Specifications" (28%) 3. "Customer name" + "Transaction history" (18%) 4. "Product name" + "Complaints" (8%) 5. Other (4%)

Search Purposes: - For quote creation (38%) - For customer inquiry response (32%) - For inventory confirmation (18%) - For complaint investigation (12%)

Finding: Sales Department searches account for 68% of total. High need to cross-search product and customer information.

Phase 3: Group - Clustering by Attributes (2 weeks)

We classified products by attributes and automatically grouped similar products.

Product Classification Axes: - Main component (platinum, palladium, oxides...) - Application (catalyst, abrasive, solvent...) - Purity (90%+, 95%+, 99%+...) - Price range (under 10,000 yen, 10,000-50,000 yen, 50,000 yen+...)

Clustering Results: 8,000 products classified into about 80 groups

Example: - Group 12: "Platinum-based catalysts, purity 95%+, price 20,000-40,000 yen" (38 products) - Group 23: "Oxide abrasives, particle size under 1μm, price under 5,000 yen" (52 products)

Phase 4: Interpret - Natural Language Search Implementation (3 months)

We built a mechanism to search with natural language.

Conventional Search (format search):

Product Code: CAT-2018-45
Main Component: platinum
Purity: ≥95%

New Search (semantic search):

"Same performance as platinum catalyst delivered 5 years ago but cheaper"

AI Interpretation: 1. "Delivered 5 years ago" → Search transaction history DB for relevant product 2. "Platinum catalyst" → Main component=platinum, Application=catalyst 3. "Same performance" → Products with similar purity and particle size 4. "Cheaper" → Sort by lower price

Search Results: - Matching product: "CAT-2023-12" (platinum catalyst, purity 94%, particle size 1.2μm, price 28,000 yen) - Original product: "CAT-2018-45" (platinum catalyst, purity 95%, particle size 1.0μm, price 35,000 yen) - Price difference: 7,000 yen cheaper (20% reduction)

Phase 5: Connect - BI Tool Integration (1 month)

We built a mechanism to immediately report search results.

BI Tool (Tableau) Integration: - One-click graphing of search results - "Sales trend of this product over past 5 years" - "Top 10 products purchased by this customer" - "Product ranking by high complaint occurrence rate"

Chapter 4: The Power of Meaning—4.5 Hours Becomes 5 Minutes

Results After 6 Months:

Dramatic Reduction in Search Time:

Before: Salesperson A searches for "same performance as 5-year-old Catalyst X but cheaper": - Search 6 DBs individually - Time required: 4.5 hours

After: Same search executed with integrated search system: - Input in natural language: "Same performance as 5-year-old Catalyst X but cheaper" - AI automatically cross-searches 6 DBs - Results display: 5 minutes - Reduction rate: 98%

Salesperson A's Daily Change:

Before: - Search work: 3 cases per day × average 2.5 hours = 7.5 hours - Customer service: 0.5 hours - Proposal creation: Almost zero

After: - Search work: 10 cases per day × average 5 minutes = 50 minutes - Customer service: 3 hours - Proposal creation: 4 hours

Salesperson A's voice: "Previously, my entire day ended with just searching. Now, search takes 5 minutes. With the freed time, I can create proposals for customers. Sales have increased too."

Overall Organizational Results:

Operational Efficiency: - Monthly search requests: 180 cases - Conventional total search time: 180 cases × 2.5 hours = 450 hours/month - New system total search time: 180 cases × 5 minutes = 15 hours/month - Time saved: 435 hours/month (97% reduction)

Sales Results: - Proposal creation count: 30 per month → 120 per month (+300%) - Conversion rate: 15% (unchanged) - Monthly contracts: 4.5 cases → 18 cases (+300%) - Average order value: 8.5 million yen - Monthly sales: 38.25 million yen → 153 million yen (+300%)

Financial Impact: - Investment: 28 million yen for integrated search system development - Annual sales increase: About 1.2 billion yen - Investment recovery period: 2.8 months

Improved Decision-Making Quality:

Use in Executive Meetings:

President: "Which products had strong sales this term?"

Koike (Information Systems Manager): Immediately searches with integrated search system: "Platinum-based catalysts up 42% year-over-year"

President: "What's the customer base?"

Koike: One-click displays BI report: "Automotive parts manufacturers account for 68%"

President: "Then let's develop new products for automotive"

Conventionally, this data collection would take 2 weeks. Now it's 5 minutes.

Chapter 5: The Detective's Diagnosis—Question Quality Changes Decision-Making

That night, I contemplated the essence of LOGIC.

Koike had knowledge sleeping across 6 DBs. Scattered data doesn't create value alone. But the moment it connected by meaning, it transformed into knowledge.

By restructuring information with LOGIC, search time was reduced by 98%. And the freed time was used for customer service and proposal creation.

"Reducing search time means increasing thinking time. LOGIC transforms data into knowledge, and knowledge into strategy."

The next case will also depict the moment when LOGIC liberates the value of information.

"Don't integrate, connect. Link by meaning, not format. LOGIC transforms scattered data into knowledge"—From the Detective's Notes

Related Files