What does this word actually mean?

Practical question: when sales says “active customer”, finance says “billed customer”, and operations says “ongoing customer”, are they talking about the same thing? If the answer hesitates, you do not have a tool problem; you have a vocabulary problem. Insee notes that metadata defines what a figure refers to and that data quality is about fitness for use, not some abstract absolute truth. CNIL, meanwhile, ties documentation to real operations through the processing register and data mapping.

  • A data dictionary answers one question per field: what it means, who creates it, where it lives, and when it can be trusted.
  • Without that base, every dashboard becomes a disguised meeting.
  • The goal is not perfection; it is the same definition understood by the teams that produce, use, and control the data.

The minimum format that actually works

Start small. A useful dictionary fits in a shared table, not a cathedral of documentation. For each field, keep six columns: field name, business definition, type/format, source, owner, and usage rules. Insee shows the value of a repository that structures and centralizes metadata with identification rules; NIST defines metadata as information describing data characteristics, including structure and acceptable uses.

  • Field name: short, stable term, without ambiguous acronyms.
  • Business definition: one plain sentence a salesperson and controller can both read.
  • Source: the origin system or file, not an interpretation.
  • Owner: a named person, not “the data team”.
  • Usage rules: filters, exceptions, authorized calculations, forbidden cases.
  • Status: proposed, validated, obsolete.

A four-workshop method, without the bureaucracy

Workshop 1, scope: choose one narrow business area, such as sales, invoicing, or support. CNIL recommends starting from real processing, actors, and flows; that is exactly the right logic for a dictionary. Workshop 2, collection: ask each team for the ten fields it uses most, then identify duplicates and false synonyms. Workshop 3, arbitration: hold a short session where one accountable owner resolves definition conflicts, with the relevant business lead, finance, and IT in the room. Workshop 4, publication: store the validated version in one visible place, with a review date and a named owner.

  • Ban “everyone knows this field” entries: they are usually the most dangerous ones.
  • Do not allow two definitions for the same term unless the usage is truly different.
  • Add one concrete example per definition: one valid value and one invalid value.

Fictional numerical example: the field “active customer”

Imagine a services SME with 1,200 accounts. Sales calls “active customer” any account signed in the last 12 months; billing only counts accounts that have produced at least one invoice in the last 90 days; support treats any customer who opened one ticket as active. The result is three reports, three totals, three arguments. After a 45-minute workshop, the company sets one definition per indicator. For “commercial active customer”, the rule becomes: account invoiced at least once and not marked as cancelled. The other uses keep their own labels. Within a month, reconciliation gaps shrink because everyone knows which indicator they are looking at. That is an inference based on the sources’ logic, not a magic guarantee: clarity reduces conflicts, it does not erase missing data.

  • Separate similar concepts by usage, not by instinct.
  • Document exceptions before they become the rule.
  • If an indicator drives a decision, define it before you calculate it.

Limits, governance, and plain business common sense

A data dictionary is not a universal umbrella. It will not fix incomplete entry, missing IDs, or a badly exported spreadsheet. It also does not replace GDPR duties: once a field can identify a natural person, it becomes personal data and must be documented with the rest of the processing. For an SME, the main limit is organizational: if nobody owns the vocabulary, the dictionary dies in two weeks. Good governance looks like this: an executive sponsor, one business owner per domain, one referee for conflicts, and a short monthly review.

  • Do not confuse a data dictionary with an IT tool catalog.
  • Do not open ten projects: start with the 20 fields that drive 80% of decisions.
  • Keep a change history; an undocumented term shift creates false comparisons.

Seven-day action checklist

Day 1 — Owner: leadership or IT, depending on size. Observable result: one-sentence scope. Day 2 — Owner: business lead. Observable result: list of the 20 most-used fields. Day 3 — Owner: data/IT. Observable result: a shared table with the six minimum columns. Day 4 — Owner: affected business teams. Observable result: three ambiguous definitions split or clarified. Day 5 — Owner: DPO if personal data exists, otherwise the compliance lead. Observable result: sensitive fields identified. Day 6 — Owner: sponsor. Observable result: version 1 validated and dated. Day 7 — Owner: each user team. Observable result: a simple test where two people find the same definition without calling each other.

  • If the test fails, the documentation is still too technical.
  • If the test succeeds, publish version 1 and plan version 2.
  • Success is not a pretty document; success is fewer visible disagreements.