Done correctly, Master Data Management (MDM) removes inconsistencies and duplications from data, reduces unnecessary frustration when searching for information, simplifies business procedures, and improves communication throughout the organization. With MDM in place, more faith can be placed in the data analysis provided by the system, improving confidence in decisions made based on that data. However, MDM also requires planning, support, maintenance and funding. I’ve worked as a Master Data Administrator (MDA) for more than 10 years, and I’ve seen first-hand the mess that MDM can become when some or all of these are missing.

This article attempts to shed some light on how Master Data Management (MDM) works, and on its benefits and challenges. It illustrates the consequences of poor MDM systems, compares that to what’s possible with efficient MDM systems, and offers my best attempt to quantify the cost savings to the business that has efficient MDM. I hope this article will be read by executives and management who may be tempted to gloss over MDM and its benefits, but it is also intended for other MDAs as an informative document describing some of what they can expect during their time in this position.

Having experienced directly some of MDM’s pitfalls, as well as its benefits, what I know for sure is that MDM is a solution and not a problem nor an unnecessary expense, as many executives tend to argue. All companies rely on certain data in order to achieve their goals and that goal is ultimately to make money. The quality of a company’s Master Data lies at the very core, the root, of the success of that company.

What is Master Data Management?

I recall vividly the time when, having explained my responsibilities in the organization to my new departmental head, I was asked the question, ” So, what is master data management ?” At the time, it rather dented my confidence in my prospects as the MDA! However, it also taught me the need for a very simple definition of MDM; one that speaks solely of its value to the business. Too many descriptions of MDM use terms and jargon which only the highly trained experts can hope to understand but the definition on TechTarget’s company website is better than most:

“Master data management (MDM) is a comprehensive method of enabling an enterprise to link all of its critical data to one file, called a master file, which provides a common point of reference. When properly done, MDM streamlines data sharing among personnel and departments. In addition, MDM can facilitate computing in multiple system architectures, platforms and applications.”

A company will always have master data in some form because every department of a company has its own inherent set of records or data. The examples of master data that I’ll be using in this article, come from my own experiences as an MDA for an engineering company, which designs and produces assembly lines, mainly for the automotive industry. In this case, our master data originates from departments across the business:

• Design engineering department – records for all the parts and products that make up the assembly lines and that we sell. These form the bulk of our data
• Control Technology department – records for the computer programs, required to control and give commands to the machines which we produce
• Purchasing department – records for the suppliers and manufacturers of the parts we require
• Sales department – customer records
• Accounts department – the financial records (creditors, debtors, banking, assets records)
• Human Resources department – the staff records
• Warehouse – stock records

These might seem to be rather disparate sets of data, but they are all interconnected. We design a part, which must be purchased from a supplier, kept in stock until required, incorporated into a machine, which is built by staff, then the machine is sold to a custom er after the control technicians have installed and activated the computer programs. The accounts department must collect the money from the customer, pay the supplier and the staff and hopefully there is still some money left over to pay a dividend to shareholders.

The collective term for all these interconnected records is master data; it is a collection of all the single bits of information, from every department within an organization, drawn together into one database, as illustrated in Figure 1.

Figure 1: MDM connects data throughout the organization

Don’t confuse MDM with Data Warehousing (DW), although they have a lot in common. DW relates to the storage of historical data, whereas MDM deals with current data. MDM contains the current and complete information for all business “entities” within a company. DW contains only historical data, necessary for analysis.

The job of the MDA is to manage and control all of this information in a way that ensures the accuracy and integrity of the master data. This leads me to my own, very simple definition of MDM:

“Master Data Management is the joining together of all the company’s information and data to a coherent whole. It helps prepare the data, thereby ensur ing that the organization has a consistent, accurate over view of all information and in addition, can depend on the business decisions taken, based on the analysis of th at data. “

What does master data look like?

The previous definition of MDM, from TechTarget, refers to the fact that MDM enables an enterprise to ” link all of its critical data to one file, called a master file, which provides a common point of reference“

The reference to a single master file is perhaps a little misleading. MDM as a whole is a “single” file, made up of numerous sub-files, one for each entity about which we collect data, such as parts, suppliers, customers, staff, and so on. A “Parts” master file, for example, in turn comprises a number of sub-files describing various attributes of a part (such as serial number, supplier, description, inventory location, 2D drawing, price, serial number and unit of measure), as illustrated in Figure 2. The source of this data is derived from various departments.

Figure 2: What does master data look like?

In this way, our MDM system as a whole provides not only a single, unified definition of each entity and the origin, or “canonical source” of the data for each attribute of that entity, but also a consistent way to link all entity data. The common point of reference is provided by the unique identifier for each entity instance, i.e. a customer’s account number, a product number or a staff number, which one can use to link to all the other sub-files.

MDM therefore, eliminates duplication and confusion, as well as futile efforts being spent in capturing data that already exists in the system. Returning to my engineering experience, it means, for example, that design engineers avoid duplicating component designs, since the master data contains a single definition of each part. Also, materials management staff can refer to the master data as a definitive source of information when ordering the required materials from suppliers. The MDM system consolidates the customer data, supplier data and even the employee data, the goal being to create a uniform database that will provide reliable analyses and reporting.

Maintaining master data

An MDM system only reaches its potential, in terms of the benefits it offers an organization, if the data is both reliable and readily available to all departments. To achieve this the MDA must maintain strict quality standards, and enforce governance policies.

Data quality checks

An MDA needs to check data quality on a regular basis, against various criteria such as accuracy, completeness and timeliness. If the volume of new records generated weekly is low, and modification of records infrequent and regulated, then the MDA can simply check records for discrepancies once or twice a week. Clearly, though, it becomes extremely time consuming for an MDA to check each record individually if the volume of record creation, and frequency of modification, is high. In my case, there could be between 200-400 new part records created every day, and up to 200 existing parts records that have been subject to an amendment or correction, since our company has an open access policy, allowing anyone who uses the CAD programs to make whatever changes they deem fit.

How you handle this, as an MDA, will vary from company to company. In our case, the open access policy means we’re not able to use any of the available database software packages, which would effectively lock the record once the MDA has reviewed and corrected it, thus ensuring the integrity of the data. Instead, we use a bespoke, Excel-based “mass data correction tool”. It allows the MDA to create various tables of parts using numerous criteria, such as description, supplier name or part number, date of capture and date amended (see Figure 3). The table can then be quickly sorted using good old Excel functions. Corrections can be made and the records written back to the database. This type of mass correction tool can be written for any database.

Figure 3 : Mass Correction Tool

Governance policies

The degree of data quality is primarily determined at the point of data entry. To improve data quality, one needs detailed, documented guidelines, setting out the procedures and policies that must be followed for data creation. For example:

1. Which fields of a record require input and in what format.
2. The methodology for naming parts to ensure consistency and ease of identification (ref. Figure 2).
3. Requirements for supporting documents that form part of a record, such as quotations, diagrams, and so on

This document must be readily available to everyone who is involved in data creation. Strict adherence to the guidelines as outlined above and regular training will lead to marked reduction in errors and discrepancies. Master data management is essential for compliance requirements, as well as being able to carry out meaningful business intelligence evaluations.

Benefits of well-maintained master data

With the correct data quality checks and governance procedures in place, the organization can rely on their master data for the following:

• Data integrity – ensures that unintentional changes to information are prevented
• Data quality – improves the accuracy, reliability, consistency and accessibility of data for making decisions
• Data integration – the process whereby data, from various sources, is combined into one unified database
• Entity resolution and matching – matches and merges data, if an organization has numerous sources of information, which relate to the same set of data.
• Governance – monitors that the data entered by staff members, meets the exact requirements of the organization and ensures that the data can be trusted
• Metrics and analysis – metrics are quantifiable measurements of the data, which in turn is analyzed to produce usable, accurate information to assist the decision making process.

When MDM is fully supported and funded within an organization and has all of the previously described attributes, an organization can truly rely on their master data to provide data consistency, uniformity of methodology, analysis and communication across all their departments. Master data management is essential for compliance requirements, as well as being able to carry out meaningful business intelligence evaluations.

Well-managed, qualitative MDM will make any employee who has to work with the data more productive and efficient. All employees will be able, at all times and without a lengthy search process, to access from a single definitive source, all the relevant information for key business entities, such as those relating to products, suppliers, customers and staff.

Conversely, when MDM is poorly understood and supported, it can cause inconsistency, confusion, duplication of work and loss of productivity, and so will lose management support very quickly.

An example of how NOT to create and manage master data

The sad reality in many companies is that there is no MDM, or that it exists but is implemented and managed poorly. Often, this is due to lack of managerial-level understanding of its real value and, subsequently, a lack of investment.

I’ll recount some of the problems that we encountered with our MDM system, at least partly due to this lack of understanding and investment from management. Although the example is specific to engineering manufacturing, I know that similar fundamental flaws affect other MDM systems in other environments.

The primary master data in this case comprises the parts and products used in our assembly lines, which are provided and created by our in-house and external design engineers. A core issue with our MDM system is the source of this master data.

Each of our design engineers is required to be proficient in the use of two CAD systems, Inventor and SolidWorks. Both are excellent programs but they have differing setups for the information to be recorded, each CAD system uses a different interface to transfer data to the master data database, and each interface has an independent database. Newly-created master data flows from the two CAD programs, to the master data file via the two interfaces, as shown in Figure 4.

Figure 4: Poorly implemented MDM

Unfortunately, as you can see in Figure 4, when new data enters the system, it also flows from interface B to interface A, but does not flow from A to B. This is a major flaw. Somebody in their infinite wisdom decided that things would be simpler if the database of interface A were treated as the main database, but largely ignored data entity resolution, matching and integration, which all takes place in the Master Data file.

To make matter worse, any subsequent updates to the master data only flow directly, from either interface, into the master database, which all other departments access, and any corrections to the data directly in the master data file are not transferred back to either interface A or B. This means that the database in interface A, now treated as the main database, does not contain all the necessary information.

The result is three non-identical databases and extreme confusion for all users, causing endless time wastage and duplication. When a pressurized design engineer requires a part for his or her design, they will always try to use the data available in interface A, but will sometimes need to use interface B, and will often find the data in each is inconsistent, and that the data in the master database is different again. The joke is, that some of our design engineers, who are incredibly innovative individuals, often cannot find a part in the system, which they themselves created. Therefore, parts are not reused as they cannot be found again and the wheel gets reinvented with every new project – but at what cost?

In a poorly-managed MDM system, as described above, there are many such inefficiencies:

• A part could potentially be created ten times – by ten design engineers with ten different descriptions (our engineers are very creative people) and with reference to ten different suppliers. The time wasted is dependent on the complexity of the part.
• Materials management will now generate ten purchase orders – after negotiating the price with numerous suppliers. This process also requires a lot of time.
• The organization misses out on volume discounts – Purchasing ten items from one supplier instead of from ten different suppliers would result in a volume discount. At the end of a quarter, half or full year, negotiating an annual turnover discount would produce additional savings.
• Removing duplicate items causes more work – once the MDM system has identified the duplicate item, the design engineers need to rectify their designs. They then have to remove the old duplicated part from their design and replace it with the correct part, as advised by the MDM system.

The question is often raised in management meetings as to why the main master database isn’t used exclusively by all departments, including the engineers? The reasons most often put forward by the design engineers are:

• The search function is too slow – it’s quicker to duplicate a part than to find an existing one
• Lack of support and training – this has many consequences:
  • Users don’t know which of the three databases to use
  • Many users maintain they do not have access to the master data database
  • Many of those with access, lack knowledge of how to use the master database.

As you can probably tell, this is an undesirable situation. It can be fixed but requires support from your organization that you may have to work hard to win. However, it is not all doom and gloom, if an MDM system is not functioning properly in your organization. As in my case, I had to persevere, and work with management patiently until they eventually saw the benefits.

An example of a well-designed and managed MDM

It should now be clear that the software used and the processes which are implemented, are critical to the concept of MDM/MDA. Figure 5 depicts the ideal data flow situation, which maximizes productivity, growth and time effectivity.

Figure 5: Well-designed MDM

What is also vitally important, is provision for the additional work required to ensure the integrity, quality and accessibility of the master data, as described earlier. A big part of this is the necessary training, supervision and motivation of the staff.

With management support and investment, it is possible to improve both the design and efficiency of the MDM system, and the data quality. I’ve witnessed this firsthand, and I’ve seen the increased efficiency and flexibility of business processes, and the smoother functioning of the global business processes. To give just one example, it has allowed design engineers to increase their productivity due to more efficient and accurate part identification. This has also lead to fewer incorrect parts being purchased which would have had to be returned or even scrapped.

All of this has a cost benefit to the business, but inevitably you will be asked, in seeking support for MDM, to quantify in some way the size of that benefit. Unfortunately, this is a tricky exercise.

Attempting to quantify cost benefits of MDM

Jean-Christophe Steels from Digital Patient Solutions at UCB ( Union C himique B elge), Belgium, wrote in February 2010:

“The processing of data needs to be efficient and cost effective…from my perspective the cost of data management should be covered by the cost saving achieved by MDM management”.

Absolutely true and yet all too often the management of a company sees MDM as a pure cost center. It is very easy to highlight the costs of MDM, by referring to the staff salaries, office space, consumables, software programs and licenses required, just to name a few.

Conversely, one can argue endlessly in favor of the efficient methods, user-friendly procedures and improved productivity that result from an effective MDM process, but it is notoriously difficult to quantify the financial benefits. Figure 6 summarizes the main outcomes of a poorly-managed versus a well-managed MDM system, in my experience.

Results of efficient MDM processes	Results of poor MDM systems
Clarity	Confusion
Efficiency – time saved	Inefficiency – time wasted
Do it once only	Repetition
Productive	Loss of productivity
Gains / retains incone	Loses income
Higher company profits	Lower company profits
High staff moral	Low staff moral
Skilled trained staff	Unskilled / untrained staff
Optimizes part costs – lower prices	Increase part costs – higher prices
Only necessary parts ordered	Duplication of parts ordered
No wastage – savings	Wastage – additional costs
Smaller storage area required	Larger storage area required
Lower warehousing costs	Higher warehousing costs

Figure 6: Comparative Table of MDM Efficiency

While there is no simple formula we can apply, some attempt must be made to quantify and realistically evaluate the cost savings of an efficient MDM system. Of course, savings would obviously depend on each individual company’s salary structure, the size of the organization, the number of staff members who are directly affected by the poor data quality and the volume of data which is generated on a daily basis. In addition, the extent of savings that are achievable are also, as in the case of my employer, dependent on the software which management chooses to use and how the various programs interface. The proper flow of information must be guaranteed and be readily available, accessible and integrated for use by all employees.

Here are the factors I took into account in my attempt to quantify savings:

1. The average working hours per day of employees as stipulated by German law of 8 hours.
2. The average salary per department e.g. our company employs 20 design engineers under 1 manager, as well as 5 to 10 freelancers, depending on current work volumes. All their annual salaries (manager included) have been totaled and the average used in this calculation to determine an average hourly rate.
3. In design engineering, an estimated time for finding existing part numbers required in a design, as well as time spent on correcting duplications, has been worked out based on my interviews with a sample percentage of design engineers, in order to gain a fair overview of the time spent on this task when using an ineffective system.
4. In the purchasing department the effect was even more dramatic, as staff often called for quotations from manufacturers or suppliers based on incorrect information. Placing a time estimate was far more difficult due to the various processes involved. In 80% of the cases, the errors in the data base were unearthed in this department. Added to this, the company’s image is severely tarnished, as the whole acquisition process implies incompetence. At this point, I have not even attempted to factor in the potential savings through volume discounts, which I mentioned above.

Figure 7 highlights the cost savings I calculated for each department.

Figure 7: Estimated cost savings of MDM per business function

In summary, the estimated salary savings, due to improved efficiency for all departments is less than 10%. This may seem a disappointingly low figure, but it needs to be considered in the context of the size of the company. Saving 10% on a salary bill of $1 million is obviously not as significant as on a bill of say $30 million.

Furthermore, what value can one really place on lost staff morale if they have to spend a considerable amount of time looking for information required, in order to complete their daily work? How do you evaluate potential losses, which the company could incur due to an ineffective data system? If losses are not incurred, this could be solely due to the diligence and hard work of the staff, and MD manager and team. An ineffective MDM system is guaranteed to incur losses at some level, such as the incorrect or duplication of purchases.

So is MDM still relevant?

In recent years, I’ve noticed that it’s become increasingly popular to declare MDM to be “dead”. This implies, that MDM no longer serves any purpose and everyone should be able to create whatever data, codes and descriptions they require, without any common standard. The result is large volumes of data, which is cumbersome to manage and occupies far more storage capacity than is truly necessary.

On the contrary, it is my firm belief that MDM will never die, although someone might change the name and introduce some new fancy buzzwords. We will always have to manage the data that a business generates and on which it relies. MDM is at the root of the quality of the services and products provided by an organization and is an important contributing factor to a company’s profitability and reputation.

However, MDM requires managerial-level understanding of its true benefits, and subsequently management’s full support. It is often hard work to gain this support, especially given the difficulty in quantifying benefits, as described above. As a result, in our company, MDM almost did die. Our inefficient MDM process, was not due to a lack of effort in trying to establish a functioning, usable master database, but as a result of management having no real grasp or knowledge of the important role MDM plays within a company’s daily operation.

At one time, our master data was pretty awesome, the system working as described in Figure 4. A new CEO joined the company who saw MDM as a totally unnecessary expense and did his best to kill the project. He didn’t quite succeed, but through staff cuts within the small department plus lack of investment and support, the state of our master data deteriorated considerably (Figure 3).

Fortunately, we now have a new CEO who does have the necessary understanding of MDM and his foresight when he took over the reins means that we are making good progress back towards the ideal situation.

Our MDM department was called into being by a small group of visionary employees and not by our leading executives. Part of what I’ve tried to do to improve its status, organizationally, is to champion Master Data Administration as an autonomous function, rather than just a ‘side function’ of the IT department. MDM/MDA is a vital and ongoing process, not something you can try using for a month or two and then abandon if it proves difficult.

Conclusion

I would sum up by reiterating that a dependable MDM system will pay for itself in the long term by the savings attained in all departments of an organization. The deciding factor is whether management agrees to it or not. I have tried to find a reliable method of quantifying the costs and savings of good and bad MDM/MDA systems. The results, however, are inconclusive and neither are they accurate, despite all my research. I have yet to find a reliable quantifiable method which proves my instinct that savings can be made.

If cost avoidance is management’s choice, the real costs will be masked and hidden but still ultimately paid for in lost time and productivity, with the slow down and strain of poor staff motivation and morale. In addition, this further depletes profit margins as the cause is not apparent or visible.

Should the positive route of commitment to MDM be decided upon, some immediate and long term benefits would become apparent, with the added result of boosted staff morale.

Whatever path management chooses to take however, they will still end up having to either bear the costs of inefficiency or the cost of a proven, suitable MDM system. It would be preferable to tackle the problem in an objective, open, well organized way, with purposeful intention and direction. A defined path, means that everyone is aware of the company’s goals and intentions.

Considering all this, I end back where I started, by asking the question “is MDM/MDA a help or a hindrance?”

The answer is for you, dear reader, to decide.