The Bones of Enterprise Data
Before bolting AI onto enterprise systems, it probably helps to understand the philosophical foundations those systems were built on.
SAP and Oracle — the two dominant ERP platforms — encode fundamentally different models of how business relationships work. These aren't just implementation details. They're different personalities, and AI that ignores them is likely to struggle when reasoning about the business.
The SAP Personality: The Actor Model
SAP thinks in terms of roles. A single entity — say, IBM — can be a Customer, a Supplier, and an Employee source simultaneously. These aren't three different records but three roles played by one Business Partner. Think of it as an actor with different hats.
This role-based architecture is efficient and integrated. When IBM's address changes, it changes once and propagates to every role. The data model is disciplined — one entity, multiple functions.
For AI readiness: Relationships are clean and deduplication is built in.
The challenge: AI needs to understand role context to reason correctly. A question about "our relationship with IBM" has multiple valid answers depending on whether you mean as a customer, supplier, or partner.
The Oracle Personality: The Network Model
Oracle thinks in terms of relationships. The same entity might appear as multiple distinct accounts — Account 1 for procurement, Account 2 for services — connected through a web of Trading Agreements. Think of it as a complex social network where the connections between entities matter more than the entities themselves.
This relationship-based architecture is flexible and granular. It can represent nuances like "we buy hardware from IBM's infrastructure division under Agreement A, and consulting from their services division under Agreement B." The data model captures the full complexity of real business relationships.
For AI readiness: The challenge is different but equally significant. The model can't easily tell if "IBM" is a single partner or a parent with 50 distinct accounts. Without understanding the network topology, AI may struggle to reason about the full scope of a relationship. It sees nodes without understanding edges.
The AI Brain Freeze
Here's where both architectures create problems for AI: the model doesn't natively understand either philosophy.
It doesn't know that SAP's "Business Partner" is one entity with multiple roles, or that Oracle's network of accounts represents one relationship viewed from multiple angles.
Without this structural understanding, AI tends to produce what might be called a "brain freeze" — it encounters data that contradicts its assumptions and either hallucinates a resolution or produces incoherent results.
The Question Worth Asking
The question for enterprises deploying AI probably isn't "which ERP is better for AI?" Both architectures have strengths.
The more useful question might be: has the organization made its data structure legible to AI?
This could mean building a semantic layer that translates the ERP's personality into something AI can reason about. For SAP, that might mean making role context explicit. For Oracle, it might mean mapping the network topology so AI understands which accounts are aspects of the same relationship.
Think of the data structure as the skeleton and AI as the brain. If the brain doesn't understand the skeleton, it's hard to imagine how intelligence alone produces coordinated movement.