Expert Opinion

Understand the organizational dimension of Master Data Management (MDM)

  • #Data Intelligence
  • #Information Management

Master Data Management (MDM), or the management of reference data, has developed substantially these last ten years, but is still too often treated as a purely "IT" project.

However, by re-defining the ways in which information is managed and controlled, MDM has effects on the organization. Taking them into account right from the upstream phase of the project is a pre-requisite to securing the commitment of stakeholders, the alignment of operational practices and the desired efficiency gains.

The purpose of MDM is to organize the management of the business's strategic information (clients, products, suppliers, etc.) shared by different units and/or applications. These data, termed 'reference', serve as a basis for common processes, the production of quality reporting, the launch of new services (Web sites) and the implementation of innovations and commercial strategies (omni-channel). Often seen as an additional element of the corporate Information System (IS), in the same way as a CRM or a datawarehouse, MDM, the true backbone of the business's data, nevertheless has a significant organizational impact. Other than certain of its primitive forms limited to technical challenges, it indeed possesses a distinguishing mark : it is, by its very nature, a centralizing force.

Through a common definition of the purpose of a business (ex : a product, in the corporate view of it, defined in a precise manner), Master Data Management involves imposing a truth on the rest of the organization and of the information systems (an MDM is, moreover, called 'point of truth'). To launch an MDM initiative, culminating in the construction and the utilization of a business repository, is to beginde facto a process of centralization which may conflict with established organizational structures and practices in place.

Let us take the case of the management of customer data. A group in the ready-made garment sector, composed of subsidiaries competing with eachother to a greater or lesser extent, wishes to make its customer data more reliable.  These are obtained in diverse ways : from the till in the stores through paper forms to information supplied online. MDM provides solutions to fill in the addresses missing for some customers, retrieve and validate the telephone numbers of others, and gather it all together in a single customer record. However, given the competition between the entities, induced by the organization, the question of exchanging and sharing customer data between them can be explosive.


By reason of its centralizing nature, MDM notably involves considering what must be undertaken by the business's corporate-level departments or by its local departments. It is, amongst other things, this thought process which determines the choice of MDM architecture - another term which is often misinterpreted, and which can seem far-removed from the preoccupations of business functions and limited to technical problem issues. In fact, the very opposite is true, and here is why.

The MDM architecture oscillates between information consolidation and centralization. In the first case, the interactions with the business's players are rather limited, even non-existent. In the second case, the business repository positions itself as a tool for data entry, and potentially verification, hence the generally considerable interactions with the business functions.

However, even if the organizational impact is different as between these two configuration modes, the central departments/local departments dichotomy remains very present. Deciding upon the degree of freedom to be enjoyed by the holders of the "local" truths relative to the corporate point of truth is often a difficult exercise. Who will have the right to enter and manage the reference data on a daily basis ? To verify them and potentially to invalidate certain creations (products, suppliers...) ? Will the local units be able/have to share certain information? These practical questions call for trade-offs which are likely to call into question the pre-existing relations, responsibilities and modes of functioning.

Let us illustrate this with a business in the industrial sector which markets highly-regulated products. Organized according to a model of relatively independent subsidiaries, the local units find it difficult to free up resources to be able to conform to the increasing regulations, whilst at the same time wanting to retain their freedom to launch products onto the market. A project for a product repository, backed by solid regulatory expertise proposed by the head office, will subtly have to take these two aspects into account so as not to provoke too strong an internal resistance and jeopardize the goal of enhanced data reliability pursued by the business.


The organization, as a management science, does not have a unified theory. Depending on the points of view and the leanings of the researchers in the area, the analysis models produced focus to a greater or lesser extent on certain organizational aspects. For example, while the advocates of the Agency theory describe the organization as a collection of contracts (between decision-makers and shareholders, between bosses and employees, etc.), others, like James March1, Henry Mintzberg2 or Michel Crozier3  emphasize the political aspects and the networks of influence of the players between themselves. For his part, Masahiko Aoki4 suggests comparing the effectiveness of organizational models on the basis of their management of information.

For a long time, MDM projects, and IT ones in general, were scarcely receptive to these concepts. Gradually, organizational assistance with the integration of software solutions expanded. Yet, in the common language of MDM projects, the term 'organization' often remains synonymous with organigram and confined to the manner in which the project will be coordinated and the governance regulating the chosen software solution. As for the notion of 'governance', it too is quite misleading : by its use, we often cut the organization down to procedures and steering committees. In the operational rush, most businesses have at most thought to define processes and workflows for the management of the reference data and identify administrators. However, such an approach carries the risk of missing what is really the organization at the opportunity study phase of an MDM initiative vis-à-vis decision-makers and stakeholders.

Let us imagine a company trading in raw materials. Its traders, spread throughout the world, work with counterparties who may default. Without a common view of these third parties, each geographical zone reserves to itself the right to contract with whoever it wishes. Putting into place a corporate repository of counterparties, with the objective of reducing the risk of payment defaults, involves limiting the opportunities/scope of action of each zone. A corporate "Risks" department will be able to use the repository to block transactions which certain traders (themselves paid on the basis of these transactions) would like to make with counterparties known in other geographical zones as being "risky".


These examples illustrate the organizational difficulties with which a business function or a project support can be confronted in an MDM initiative.

In the first instance, the organization must be approached in its entirety. What is its general style of information management : anarchic, feudal, federative ?5 Is it a desired state of affairs or one to be improved ? What previous projects came up against this style of management, or on the contrary, benefited from it ?

Next, it is necessary to have a good understanding of the issues for the stakeholders, notably in terms of autonomy and responsibility, in order to conceive the right organizational design, namely an 'intelligent centralization'. These stakeholders must commit themselves and understand the nature of their commitment : the organization is going to change, what place do they wish to take in it ? While the organization to be put in place for the build (project) is often the sole subject of discussion, it can also be necessary to present the one for the run (routine functioning). The players may want to analyze the organizational gaps as early as possible.

Particular attention must be paid to the unit which will eventually administer the reference data. What resources, in particular human, are to be allocated to it ? Will that necessitate regrouping skills presently dispersed in different entities ? To whom should it report ? Will the unit be confined to IS/tool aspects, to the simple coordination of business functions, or will it comprise people with real business skills, capable of taking informed decisions ?

Finally, it needs to be kept in mind that, like Business Intelligence, MDM is the practice and the tool of a population : support functions & corporate business functions. This is not insignificant regarding the way to 'sell' the project internally and, once the infrastructure and the relevant technical processes have been put in place, guarantee the sustainability of the initiative.

1 March, J. G., Simon, H. A. (1958). Organizations, John Wiley & Sons Inc, New York.

2 Mintzberg H., (1990). Le pouvoir dans les organisations, Paris, Les Éditions d'Organisation.

3 Crozier M., (1977). L'acteur et le système, Le Seuil, Paris, Coll Sociologie politique.

4 Aoki M., (2000). Information, Corporate Governance, and Institutional Diversity: Competitiveness in Japan, the Usa, and the Transitional Economies, Oxford University Press,


5 Thomas Davenport, dans son article "Information Politics" (Sloan Management Reviaw, 1992) décrit des modes que l'on retrouve couramment dans les organisations.