June 9, 2025
In today’s globally distributed enterprises, procurement and operations leaders are under pressure to reduce cost, increase compliance, and build resilient supplier relationships. But many of these same organizations are flying blind lacking a unified view of their vendor landscape. Why? Because their data systems don’t reflect how their vendors are actually structured in the real world.
Consider this common scenario: your subsidiaries in Germany, the U.S., and Vietnam each purchase from a vendor called ACME. But in each system, the supplier is listed as a different legal entity—ACME ABC, ACME DEF, ACME GHI. As far as your dashboards are concerned, those are three unrelated vendors.
In reality, all three roll up to the same parent company: Global Manufacturer.
You can’t optimize what you can’t see. And if you can’t see your true relationship with a supplier, you can’t negotiate better terms, manage risk coherently, or ensure global compliance.
The Problem: Fragmented Supplier Views
When each business unit or region manages its own suppliers, you end up with fragmented records across systems. Each subsidiary has:
- Its own vendor master data
- Separate contracts
- Independent compliance audits
The result? Your procurement systems treat ACME ABC (Germany) and ACME GHI (USA) as totally different entities, even though they’re just arms of the same global supplier. There’s no roll-up, no visibility, and no leverage.
And when you try to run AI-driven spend analysis or supplier risk scoring across these records, you’re feeding fragmented data into the engine. The output? Garbage in, garbage out.
Why Traditional Systems Fail at This
ERP and P2P systems were built to track transactions, not relationships. They can tell you how much was spent, when, and by whom—but they can’t infer that ACME ABC and ACME DEF are part of the same global supplier group. Nor can they adapt when legal names, addresses, or ownership structures change.
You could try to normalize this data manually. But with thousands of vendors and a global footprint, this quickly becomes unsustainable. Matching records with fuzzy logic is slow, error-prone, and brittle.
What you need isn’t just cleaner data. You need a smarter structure.
Enter Knowledge Graphs
What’s old is new again. In my book “Enterprise Information Integration: A Pragmatic Approach”, which came out in 2005, I discuss the power of capturing the critical relationships between your data as a separate base of data so that you can start to gain real insights into your business data. Hundreds of millions of dollars spent on master data management efforts that produced very little ROI, and very few of these efforts managed to build the most critical metadata data set required to truly turn data into information and information into knowledge.
What is a knowledge graph?
The image presented at the beginning of this article is a visualization of a knowledge graph. There are multiple ways to capture this information in textual form so that it can be stored and queried in a way that understands the nature of the request in context of the information shown.
A knowledge graph is a way of modeling data that emphasizes entities and the relationships between them. It’s how modern AI systems represent the world—not as tables and rows, but as a web of connections.
In our vendor example, here’s what the knowledge graph captures:
- Your regional subsidiary in Germany
→ has_contract_with → ACME ABC - ACME ABC
→ is_subsidiary_of → Global Manufacturer
Repeat for Vietnam, USA, and other regions. With this model, your systems can infer that all these vendors roll up to the same supplier—even if the transactional records don’t say so explicitly.
Now, you can ask:
What’s our total global spend with Global Manufacturer, across all of its subsidiaries?
Which supplier families have more than one compliance flag across different countries?
This is not possible—at least not reliably—with a spreadsheet or SQL joins.
How Tools Like LangGraph Use Graphs for Inference
Modern frameworks like LangGraph let you build stateful LLM-driven agents that work directly with graph-structured data. This means your AI agents can:
- Traverse supplier relationships
- Aggregate contract or spend data across linked entities
- Generate reports or recommendations that account for ownership structures and risk exposure
For example, a LangGraph-based AI agent can:
- Start at your German business unit
- Find the supplier node (ACME ABC)
- Follow the is_subsidiary_of link to Global Manufacturer
- Aggregate all related contracts and compliance issues across other subsidiaries
This type of contextual, relationship-aware inference is only possible when the data is modeled as a graph.
What Businesses Need to Do
1. Resolve Entities Across Systems
Start by identifying which vendor records across your ERP, SRM, and P2P platforms actually belong to the same supplier group.
2. Model Relationships Explicitly
Define and capture relationships like:
- has_contract_with
- is_subsidiary_of
- shares_risk_profile_with
These become the edges of your graph.
3. Adopt a Graph Database or Layer
Use tools like Neo4j, Amazon Neptune, or TigerGraph to store and query your knowledge graph, or overlay it as a semantic layer on top of your data warehouse.
4. Connect to Your AI Systems
Expose the knowledge graph to your AI/LLM tools (via LangGraph or similar), so they can use it to enrich analysis, generate insights, and answer questions with full context.
Smarter Queries, Better Decisions
Once implemented, the knowledge graph unlocks dramatically better outcomes:
- Procurement can see total vendor exposure across subsidiaries
- Compliance can surface multi-entity violations or audit gaps
- Finance can trace spend hierarchies across the enterprise
Even simple questions become easy to answer:
“Who are our top 5 suppliers by global spend—including all subsidiaries?”
“Which vendors do we contract with in more than three countries?”
“What ESG violations exist across all vendors tied to Global Manufacturer?”
Final Thought
Knowledge graphs aren’t just for big tech firms. They are the key to enabling real enterprise intelligence across silos. If your AI initiatives are underperforming, it’s likely because your data doesn’t reflect your business reality.
Build the relationships into your data and your systems will finally understand the business you’re actually running.
