In any ERP implementation, master data preparation is one of the most labor-intensive phases before go-live. Material cards, customer and supplier records, chart of accounts, cost centers — all of these must be reviewed, corrected, and completed before the system can be activated. Project teams sometimes spend months on this cleanup work alone. Then the system goes live, everyone breathes a sigh of relief, and within a few months that carefully prepared data begins to deteriorate. Duplicate material records accumulate, customer addresses become inconsistent, and unused account codes pile up in the finance module. This cycle repeats itself in every company that treats master data management as a one-time project activity rather than an ongoing organizational responsibility.
Master data refers to the foundational information set on which all transactional records in an ERP system are built. When a sales order is created, the system reads the customer record; when a production order is opened, it references the bill of materials and work centers; when an accounting entry is posted, it draws on the chart of accounts. If this core data is inaccurate or incomplete, the impact is not limited to a single transaction — every process that relies on that data is affected. Master data quality is therefore the most direct indicator of whether an ERP system is genuinely functioning or merely running.
So how does a company build a permanent model? The first step is transferring master data ownership from the project team to the company’s own organization. This does not necessarily mean creating a new department; assigning clear responsibilities to specific people within existing teams is sufficient. One person responsible for material management, another for customer and supplier records, and a finance representative handling the chart of accounts and cost accounting — this core group can form the backbone of a master data team. What matters is that these roles are defined in writing and that senior management actively supports the structure.
The second critical element is establishing entry checkpoints that control how new data enters the system. When a new material card needs to be created, which fields are mandatory, who approves it, and what naming convention applies — all of this must be decided in advance. In practice, the most common failure is that these rules either never get written down or are documented once and then forgotten in a folder. Entry checkpoints can be implemented through the ERP system’s own workflow tools or through a simple approval procedure. What matters is that every user knows which steps to follow before opening a new record.
Quality indicators are what make this model measurable. How many inactive material cards exist in the system? What proportion of customer records have had no activity in the past six months? Have unused account codes in the finance module been cleaned up? These questions serve as simple but effective indicators for regularly assessing master data health. Reviewing these indicators monthly or quarterly allows problems to be caught before they grow. When these indicators are included in management reports, master data quality becomes a management issue rather than a purely technical one — and that shift in framing makes all the difference.
The hardest part of this model is not technical but organizational. After an ERP project is completed, the company quickly returns to its everyday pace; everyone focuses on their own work and master data responsibility fades into the background. Keeping the master data team’s meetings regular, monitoring compliance with entry checkpoints, and reporting quality indicators all require genuine time and attention. When this commitment is absent, the system deteriorates again and a few years later the company finds itself planning another ‘data cleanup project.’ By that point the cost is higher and the resistance is greater, because users have grown accustomed to the system and have come to treat bad data as normal.
As a SME manager making decisions in this area, the question to ask is straightforward: to get a return on the investment made in an ERP project, is it more sensible to keep the system running cleanly, or to restart the cleanup process every few years? The answer is clear. Building a permanent organizational model for master data management may look like an added cost on top of the project budget, but without this structure the ERP system quickly loses credibility and users begin maintaining parallel spreadsheets alongside it — which is the clearest sign that the project has failed in practice. A small team, clear rules, and a handful of simple indicators are enough to break this cycle for good.
This article was originally written in Turkish by Gökhan MERCANOĞLU on March 28, 2005 and has been automatically translated into English and other languages using machine translation.