Data management: what it is and where to start

Data management is everything you do to keep your business data reliable, findable and secure, from the moment someone enters it to the moment you delete it. For a mid-sized company it comes down to four agreements: who owns which data, what each term means, how you keep input clean and how long you keep what.

Most explanations of data management are written for large organisations, with a Chief Data Officer, a dedicated data team and a reference work of several hundred pages as a guide. If you work at a company of eighty people, you tune out at those words, and that is understandable. The problem does not go away when you avoid the word, though. It just turns up somewhere else.

Usually in the monthly meeting. Sales reports revenue slightly higher than finance does, because the CRM counts orders and the accounts count invoices. The customer called Jansen Installations in one system and Jansen Ltd in the other appears twice in one overview and once in the other. The first half hour goes on which figure is right, and the decision everyone came for slips to next month.

Sound familiar? Then you do not have a reporting problem, you have a data management problem. A new dashboard on the same data does not make that gap smaller, it only makes it visible faster. A good-looking screen is worth no more than the foundation underneath, and that foundation is what this article covers: what data management is, what it consists of, where it goes wrong in mid-sized companies, who does it and where to start.

What is data management?

Data management is the set of agreements, roles and working methods you use to manage data throughout its life cycle. That life cycle has four stages:

• Entry. Someone creates a customer, books an invoice or logs hours. This is where most errors are born.
• Storage and integration. The data sits in one system and travels from there to other systems and to your reports.
• Use. The figure ends up in a dashboard, a quote or a payslip, and someone makes a decision based on it.
• Retention and deletion. The data is archived and destroyed after a fixed period.

Data management is not the same as database administration. Database administration is technical work on one database: backups, performance, availability. Data management is about the data itself, across all your systems at once. A database can run perfectly while the customer data inside it is unusable.

Why data management matters

Because every decision you make on a figure is only as good as the data that figure is built from. The effects of poor data management rarely show up at once, they pile up: a controller who loses days every month straightening out figures in Excel, a mailing that reaches the same customer three times, a margin per customer that nobody believes and therefore nobody steers on.

There is a second reason. Everything you want to do with AI, from forecasts to asking questions of your own figures, runs on the same data. A model that learns from three versions of the same customer does not give a smarter answer. It gives a wrong answer faster, and with more conviction.

What does data management consist of?

The international reference work is the DAMA Data Management Body of Knowledge, which divides data management into a series of knowledge areas. For a mid-sized company, six of them really matter:

• Data architecture. Which systems you have, which system leads for which data and how data flows between them. Not as a diagram for the drawer, but as the answer to the question: when the CRM and the ERP disagree, which one is right?
• Data integration. The connections that bring data from your source systems together, preferably automatically and daily rather than through a monthly export. How that works for the two most common Dutch packages is covered in our articles on connecting AFAS to Power BI and Exact Online and Power BI.
• Data quality. Whether data is complete, correct and current, and what you do when it is not. Data quality is something you measure, not something you assume. How to do that, with one measurement rule per dimension, is covered in our article on data quality.
• Metadata and definitions. What each term means. Is revenue before or after discounts, does a customer count as active after one order or after three? Those agreements are called metadata, and they prevent more arguments than any tool.
• Security and privacy. Who may see and change which data, and how you protect personal data. In reports you handle that with row-level security: everyone opens the same report and sees only their own part.
• Retention and deletion. This is where two laws collide. Dutch tax rules require you to keep your basic records, such as the general ledger, debtors and creditors, for at least seven years. The GDPR says you may not keep personal data longer than necessary, and the Dutch Data Protection Authority expects you to set and justify a retention period for each type of data. So the CV of an applicant from three years ago no longer belongs in your system, while an invoice from three years ago does.

These six are connected. An integration without agreed definitions only moves the confusion to another screen, and definitions without an owner drift apart again within a year.

Master data management: where mid-sized companies go wrong

Of all those parts, there is one that chafes in almost every mid-sized company: the core records. Master data is the data your whole company uses: customers, products, suppliers, employees, cost centres. It changes little, but every report leans on it.

It almost always goes wrong the same way. Sales creates a customer in the CRM, and accounts receivable creates it again in AFAS or Exact, each with their own spelling. A branch gets its own customer record.

A product gets a new number with a new supplier, while the old one stays. Nobody does anything wrong, but after two years you have three versions of your largest customer and revenue per customer no longer adds up anywhere.

The best example we come across is the customer record with “DO NOT USE” in its name. It is there because someone once wanted to switch off a duplicate without deleting it. It has since collected fifty new orders of its own.

Master data management, or MDM, is managing those core records so that each one exists once, has one owner and carries the same name everywhere. There are two routes, and the difference matters:

• Cleaning up. You merge the duplicates, fill in the empty fields and correct the spellings. That is necessary, but it is a one-off. Without further agreements, things are just as messy again within a year.
• Fixing it at the source. You agree who may create a new customer or product, which fields are mandatory and which system leads. Using the Chamber of Commerce (KvK) number as the fixed key for customers already solves much of it in practice.

Master data management tools, such as the MDM modules of large ERP vendors or standalone MDM platforms, are built for organisations with dozens of systems across several countries. For a company with one ERP, one CRM and an accounting package, they are almost always overkill. There, a few fields, a permissions structure and a monthly check do the job.

Data management and data governance: the difference

The two terms are often used interchangeably, but they are not the same. Data governance is the rulebook: who decides about which data, which definitions apply, who may see what and what happens when someone does not follow the rules. Data management is the whole, including the hands-on work: integrating, cleaning, securing, archiving.

Governance sets the rules of the game, data management is the entire game. Without governance, nobody knows which agreement applies. Without the rest of data management, those agreements stay on paper. So start small: a handful of agreements about the data that causes the most debate today, and let governance grow with use.

Who does data management in a mid-sized company?

Not one person, and certainly not IT alone. Large organisations appoint a Chief Data Officer with a team of their own. In a company of fifty to five hundred employees that is too heavy, but the tasks do not disappear. They are spread over four roles:

• The board decides which data matters and where it has to be right first. That is not a technical question, it is a choice about what you want to steer on.
• The owner per data domain is someone from the department that steers on that data. The controller owns the financial definitions, the sales manager the customer segmentation, the buyer the products. A name, not a department.
• The data steward makes sure the agreements are followed day to day: flagging duplicates, keeping permissions up to date, adding new fields. In a mid-sized company this is often part of the job of an application manager or a strong administrative employee.
• IT or an external partner handles the technology: integrations, security, backups and the central data model.

You can outsource that last role, but not the other three. A partner can help you draw up the agreements, but a definition that only the partner understands is not an agreement. It is a dependency.

Where do you start with data management?

Not with a tool and not with a policy document, but with the data that causes the most debate today. Five steps, in this order:

1. Pick one data domain. Usually customers or products, because most reports lean on them. Do not start with everything at once.
2. Appoint an owner and record the definitions. What is a customer, when is one active, which field is mandatory, which system leads. That fits on one page, and it is the most important document you will produce in this process. How those definitions fit into a wider plan is covered in our article on data strategy.
3. Measure how bad it is. Count the duplicates, the empty mandatory fields and the customers without a Chamber of Commerce number. That figure is your baseline, and the only objective answer to the question of whether things are improving.
4. Clean up once and control input at the source. Improving data quality is not a project, it is a habit. The clean-up is the project; the input rules and the permissions structure are what stop you from having to do it again next year.
5. Check monthly, then expand. A fixed fifteen-minute check is enough. Once it works for customers, take the next domain. Only when three or four domains are in order and your sources no longer fit together in one model does a data warehouse become a sensible next step.

And when should you not start yet? If you have one system that holds everything, fewer than twenty employees and never any debate about figures. Then your data management is the discipline of whoever does the administration, and an outside project would cost more than it returns.

So how does it work for you: does everyone know which system is right when two figures differ, or does that debate start again every month? If you want to know which data domain needs attention first, get in touch.

Frequently asked questions