A manufacturing company’s finance director and sales director both present revenue figures to the CEO in the same week. The numbers cover the same period but one reflects pre-return revenue while the other reflects post-return. The meeting is consumed by arguing over which figure is correct; the actual agenda item, a growth strategy discussion, never gets addressed. This scene plays out regularly in mid-sized and larger businesses. The source of the problem is neither the database technology nor the reporting tool. The problem is that nobody has defined who owns the data and which definition of revenue is the official one.
A data warehouse consolidates raw data from multiple source systems into a single central structure and organises it for historical and comparative analysis. But the technical infrastructure alone is not enough. Extracting meaningful information from a warehouse requires institutional agreement on how data is defined, who approves it, and what transformation rules apply. The framework that creates and maintains this agreement is called data governance. Data governance is not a technical project; it is a corporate function that brings finance, sales, operations, and IT together around a shared set of rules.
For this function to work, the first requirement is a governance council. The council brings together a senior representative from each department along with the IT unit, meeting on a monthly or bi-monthly schedule with a structured agenda. The council’s job is not to handle complaints about data quality; its job is to make institutional decisions about data and ensure those decisions are applied consistently. Which metric is calculated how, which source system takes precedence when there is a conflict, and what the approval process looks like when a new data field is added — these are all within the council’s authority. Without a council, each department continues producing its own version of the truth and the warehouse gradually loses credibility.
One of the council’s most tangible outputs is the data ownership matrix. This document records which data set falls under which department’s responsibility and who holds the authority to approve changes. Does the customer master record come from the CRM system or from the accounting module? Does the product catalogue get entered by production or approved by purchasing? When these questions go unanswered, a warehouse project can be technically successful and operationally useless at the same time. The matrix also clarifies who data quality issues should be reported to, so problems reach the responsible person rather than disappearing into an email thread.
The third core element of the governance structure is the business glossary. The glossary is a document in which every critical term the organisation uses is defined in business language, not technical language. What does ‘active customer’ mean: someone who placed an order in the last six months, or someone who was invoiced in the last twelve? Does ‘net revenue’ include or exclude returns? When these definitions are not written down, each department works from its own interpretation and reports generated from the warehouse contradict each other. Preparing the glossary often takes more time than the technical work because it requires bringing decades of divergent usage to the surface. Once it is complete, however, the majority of reporting disputes disappear on their own.
The greatest difficulty in establishing data governance is organisational, not technical. Department managers often perceive the movement of their data into a central structure as a loss of control. The question ‘will someone else be making decisions about our data?’ comes up frequently in the early months of a project. Overcoming this resistance requires demonstrating concretely that council membership is a form of authority, not a burden: council members do not lose their data; they gain a voice in how that data is used across the entire organisation. Without visible support from the executive level, changing this perception is very difficult. The project sponsor must be someone from senior management.
For a manager considering an investment in data governance, the core decision criterion is straightforward: calculate how often different departments give different answers to the same question, and estimate how many meeting hours and decision cycles that inconsistency is costing. If the cost is real, establishing a governance council and documenting a data ownership matrix is not a technical luxury — it is an operational necessity. If the warehouse infrastructure is already in place, most of the remaining work is organisational and requires no additional software investment. If the warehouse has not yet been built, establishing the governance framework on paper first will accelerate the technical project and protect against the cost of rebuilding structures that were not designed around agreed definitions from the start.
This article was originally written in Turkish by Gökhan MERCANOĞLU on March 7, 2005 and has been automatically translated into English and other languages using machine translation.