"We want to bring our multiple business systems together and view data across the organization"—this is a frequent inquiry from small and medium-sized businesses pursuing DX. Yet, once work begins, the first few weeks do not advance toward building new systems. Instead, work halts before questions like this: "Does 'customer' here refer to companies under active contracts, or does it include prospective leads?" The sales department and accounting department use the same phrase "customer count" to refer to different numbers. In order management systems, a single business partner is registered in triplicate under distinct IDs for each department. Before integrating data, the vocabulary and meanings are not aligned in the first place.
Confronting this issue directly is Zenn's article, Data Engineers Should Face Organizational Ontology Head-On. It points out that beyond the practice of making data AI-ready, the final barrier remaining is organizational ontology—aligning the system of words and concepts used by the organization. From our perspective building data platforms and business systems in custom development, we consider this the most unglamorous yet most outcome-defining phase, coming well before technology selection.
Where "integrating data" always stumbles
Multi-system integration stumbles not because systems cannot be linked technically, but because the results of linking them cannot be trusted.
Take "sales revenue," for instance. One department counts on an order basis, another on a cash receipt basis, while forms mix tax-inclusive and tax-exclusive figures. Mechanically adding these together yields nothing more than a "plausible total" that nobody believes. The same applies to "business partners." Spelling variations (presence or absence of "Inc.", full-width vs. half-width characters), histories of mergers and renamings, and different companies sharing the same name. Gathering data without deduplication leaves single companies split across records, distorting aggregate figures.
What is happening here is not an issue of data volume or format; it is an issue of semantics. Each individual system functions correctly for its respective department. The problem emerges the moment data crosses departmental boundaries, exposing a state where "the same word refers to different things, and different words refer to the same thing." This is directly connected to ingesting unstructured data (PDFs and emails), an aspect we also address in Structuring Unstructured Data with LLMs in Client Projects (GH Media).
Ontology means aligning organizational vocabulary
Ontology may sound complex, but what we do in custom development is concrete: establishing single definitions for what each word used in the organization refers to and how it relates to other words.
"A customer refers to a corporate entity with an active contract. Prospective customers are distinguished by calling them 'leads.'" "A business partner possesses a unique ID at the corporate entity level, with departments and contacts hanging beneath it." We agree on such definitions with stakeholders and translate them into both documentation and data structures. What is critical is that the IT team does not decide this in isolation, but rather involves the frontline teams actually using those terms (sales, accounting, operations) to reach consensus. Definitions that frontline staff genuinely accept as accurate will last far longer than models that are merely technically correct.
| Common discrepancy | Outcome if left unaddressed | Decisions made in ontology |
|---|---|---|
| Scope of "customer" differs across departments | Aggregates do not match, undermining trust in numbers | Definitions and boundaries for customers vs. leads |
| Duplicate registrations of business partners | Revenue is fragmented, obscuring the true picture | Unique corporate IDs and entity-matching rules |
| Proliferation of status terminology | Conversion nightmare upon every integration | Official status names and transition definitions |
Designing states (statuses), including the treatment of deletion and termination, greatly impacts data quality. For practical pointers on table design, Redesigning with State Tables Instead of Soft Deletes in Client Development (GH Media) is also a helpful reference.
Why this matters right now
Aligning terminology has always been important. What made it even more pressing in 2026 is that we have begun having AI handle business data.
Between humans, implicit adjustments happen naturally: "This 'customer count' includes prospective leads, right?" AI cannot do that. If you feed data with ambiguous definitions to AI, it will return incorrect answers ambiguously yet authoritatively. Asking "What was last month's revenue per customer?" might yield a figure where the numerator and denominator used entirely different definitions of "customer." Such accidents inevitably occur in organizations where data semantics are unaligned. The accuracy of AI utilization is determined by the clarity of the semantics in the data provided, long before model intelligence comes into play. For a holistic view of enterprise-scale data integration, please also read Custom Design of Enterprise Data Integration (GH Media).
How we proceed in client work
In our custom development, rather than jumping straight into building integration platforms or new systems, we place the process of aligning semantics as an independent first step.
The first step is conducting interviews on the current state and taking an inventory of terminology. We gather the words used by each department and map out "same words meaning different things" and "different words meaning the same thing." Next, we convene stakeholders to agree on unified definitions, compiling them into a glossary and data model. Up to this point, no major development takes place. For a client in the service sector, this terminology inventory alone revealed that "customer" was used with three different meanings across departments, fundamentally altering the requirements of the integrated system. Because we aligned meanings first, we were able to define correctly what needed to be built.
Building on that foundation, we proceed step-by-step with deduplication and master data unification of existing records, finally overlaying system integration and analytics platforms. Maintaining this sequence is vital; skipping consensus on semantics to build platforms first will inevitably require rework later. The discipline of assessing scope—including what not to build or what to build later—shares principles with Requirements and Scope Design to Prevent Over-Engineering in Client Projects (GH Media).
Common pitfalls to avoid
First, stalling by trying to establish perfect definitions from the start. Aligning every single term across the entire enterprise at once is impossible, so prioritize consensus on the target integration scope first (such as revenue and customers). Second, letting the IT team decide in isolation. Definitions not used by frontline teams will not be respected, turning into mere paper rules. Third, stopping after creating a glossary. Definitions only take effect when reflected in both data structures and software systems. It is vital not to decouple documentation from code.
Summary — Align vocabulary before building
The root cause behind failures in data utilization and system integration often lies not in technology, but in semantic drift where "the same word refers to different things." Especially when having AI handle business data, ambiguities in this foundation turn directly into confident hallucinations. In custom development, before building platforms or systems, we place ontology design—aligning organizational vocabulary and meaning—as an independent initial phase, defining what should be built correctly before writing code.
If numbers do not match across your departments or you want to integrate data but do not know where to start, please feel free to reach out via our contact form. We can start with a terminology inventory.
Sources
- Data Engineers Should Face Organizational Ontology Head-On (Zenn / dely)
- What Is Master Data Management (MDM)?（IBM）
- Structuring Unstructured Data with LLMs in Client Projects (GH Media)
- Redesigning with State Tables Instead of Soft Deletes in Client Development (GH Media)
- Custom Design of Enterprise Data Integration (GH Media)
- Requirements and Scope Design to Prevent Over-Engineering in Client Projects (GH Media)
