When the same word means different things in each system
Every organisation past a certain size has four definitions of customer, and everyone has learned to work around it. The cost is invisible until two numbers that should match do not, in front of someone senior.
The situation
The finance system, the CRM, the warehouse and the product database each have an entity that is called customer and means something different — with or without prospects, with or without churned accounts, deduplicated or not.
The traditional fix is a glossary in a wiki or a spreadsheet. It gets written once, is accurate for a month, and is then contradicted by every system it was supposed to govern, because nothing connects the definition to the thing being defined.
What changes the outcome is attaching the term to the model — so the definition sits with the columns that implement it, and the drift between them is visible rather than theoretical.
You are here if
- Two reports that should agree do not, and the reconciliation takes a week each time.
- A metric has to be qualified by which system it came from before anyone will accept it.
- New analysts ask what a field means and get different answers depending on who they ask.
- There is a glossary somewhere that nobody has opened this year.
How the work gets done
Start where the disagreement actually costs something
Do not begin with an A-to-Z of business terms. Begin with the handful of terms that have already caused a visible problem — the ones behind the reports that disagree. Those have an audience that will defend the definition once it exists.
A glossary that starts small and is used beats a complete one that is not.
Data ▸ Business Glossary
Attach terms to the columns that implement them
The data dictionary is where a term stops being an opinion. A definition attached to the specific columns that carry it can be checked; a definition in a wiki cannot.
This is also what makes the disagreement visible: when one term maps to four columns with four different rules, that is now a documented fact rather than an argument.
Data ▸ Data DictionaryData ▸ Metadata Repository
Use lineage to find where a definition travels
A term is not implemented in one place. It is implemented in the source, transformed on the way into the warehouse, and reinterpreted in a report. Lineage is how you find every point where the definition could have changed.
Data ▸ LineageData ▸ Impact Analysis
Make the terms bind to new work
A glossary only stops drifting if new models are checked against it. Fold the terminology check into the same validation that catches naming problems, so a new table introducing a fifth definition of customer is caught when it is proposed rather than when it is reported on.
Data ▸ Validate ModelData ▸ Bulk Editor
What you end up holding
- Definitions for the terms that were actually causing disagreement, agreed by the people who disagreed.
- A dictionary linking each term to the columns implementing it, across systems.
- A lineage trace showing every point at which a definition is transformed.
Not this, if
- Nobody has been made accountable for the definitions. A glossary with no owner becomes another artefact to reconcile.
- You need a full data catalogue with profiling and quality metrics over live data. This documents meaning and structure, not data quality.
- Glossary and dictionary are enabled per organisation, so check what yours has before planning a rollout.