Intelligent Enterprise

There are many factors that pose a challenge for enterprisewide Master Data Management. Business ownership and ongoing participation, business process disruption, data integration and synchronization – these and other factors can make an MDM implementation painful, time-consuming and expensive. But there are also some factors that help reduce the pain and effort.

Fewer "masters" to master: Largely independent of the size of the company, there are typically only a handful of enterprisewide master or reference entities that can be considered "major dimensions," which need (dare we say deserve?) a formal program in master data management. Typical examples include Customer, Product, Employee, Asset and Location. Many of the other master data entities are often localized to departments or even to individual applications, and these can be considered and treated as "minor" reference data. Note, however, that "minor" does not necessarily mean insignificant, and there can be substantial value in assessing these for broad and common use (particularly from a reporting perspective).

Fewer systems of record: A careful analysis often reveals that although there may be a large number of systems that create and/or use the major dimensions, typically only a handful of systems – more typically, the "upstream" systems – carry most of the weight and relevance in master data management. The classis example is that of Employee: clearly one of the most important reference entities, the definitive copy of the employee is typically the enterprisewide HR/Payroll system. ERP often simplifies master data management for related major entities: if the ERP system is itself not the system of record for the entity (and hence the MDM repository by default), it is usually the owner, and hence supplier, of the largest and most significant "slice" of the entity.

Build vs. buy (it's worth a try): There are applications where the "buy" approach has overwhelming advantages – again, ERP solutions come to mind. In the case of MDM, however, we have been implementing master data solutions for years (often inadvertently), typically as a part of another application. This is not the best approach – clearly there are limitations to using a transactional system for MDM. A custom MDM solution can provide useful initiation into the complexities of master data definition and governance, and can be implemented over time (thus spreading the cost over time as well). The catch, though, is that custom implementations can quickly lose direction and momentum.

Show them the money. The key to getting users to see the value in a master data management program is to let them begin using the master data repository as soon as possible, for reporting and other applications. The trick is to avoid the "big bang barrier," which prevents users from seeing any return on the investment until a significant amount of time and money has been spent. This can be accomplished by implementing the solution in part or in stages, in terms of vertical or horizontal partitions of the master entities/data.

Rajan Chandras is a consultant with a global IT consulting, systems integration and outsourcing firm, and can be reached at rchandras@gmail.com.

E-MAIL  |