Organizations turn to master data management (MDM) to solve many business problems - to reach compliance goals, improve customer service, power more accurate business intelligence, and introduce new products efficiently. In many cases, the need for an MDM implementation is dictated by the business challenge at hand, which knows no single data domain. Take a manufacturing customer, for example.
The company decided to deploy an MDM solution in order to solve buy-side and sell-side supply chain processes, to more effectively manage the procurement of direct and indirect materials and to improve the distribution of products. To meet these goals the solution must be capable of managing vendor, customer, material and product master data. Unfortunately, quite a few vendors sell technology solutions that focus exclusively on either customer data integration (CDI) or product information management (PIM), which solves only a piece of the business problem.
This mistake, almost certainly, limits the customer's ability to extend the technology to other business problems in the future, and hence decreases the effectiveness of the MDM implementation. In the above example, starting with only one of the master data domains will not effectively improve the systemic supply chain, and would severely constrain the usefulness of an MDM solution for supply chain performance management.
Two Approaches to Multidomain MDM: Application and Platform
There are two distinct approaches to multidomain master data management: the first being an MDM application approach, and the second being the MDM platform approach. The MDM application approach comes with a defined data model, business logic or functionality, and specific graphical user interface, all perfectly suited to solve a single, well-defined business problem. The concept is similar to buying an off-the-shelf Sales Force Automation application for managing the sales pipeline, or a procurement application to manage the purchase of direct or indirect materials for the supply chain.
The MDM platform approach, on the other hand, allows organizations to flexibly define their own data model, generate logic and functionality based on this defined model, and provide support to configure the graphical user interface based on the functionality.
While the application approach and the platform approach can both quickly satisfy the initial needs that drive organizations to embrace MDM, only the platform approach enables companies to evolve and scale their MDM systems to address a wide range of additional business problems. In fact, the application approach inevitably leads to MDM silos and cost overruns. While there are undoubtedly scenarios where it might make sense for a company to pursue a quick-fix MDM implementation to solve some pressing business challenge with a limited scope, when there is any question of scaling that MDM implementation to address other business needs or future contingencies, the platform approach is unquestionably the best path in order to lower the total cost of ownership and shorten the time to value.
MDM is Not ‘One-Size-Fits-All'
To better understand how these two approaches differ, let's look at a hypothetical business problem. A global pharmaceutical company organizes its business into multiple divisions including a conventional pharmaceutical division, an over-the-counter medicines, biotechnology, and medical devices. The conventional pharmaceutical division, which offers medicines for serious and widespread diseases such as cancer, HIV/AIDS, and bacterial infections, encountered serious problems with compliance reporting. These problems arose because the antiquated systems its sales force used to track sales activities such as outreach to doctors, hospitals, and pharmacists was plagued with duplicate records. Management and IT decision-makers within the conventional pharma division decided to address the problem though an MDM initiative that would result in an integrated physician master. This physician master would cleanse, standardize and consolidate information from a variety of sources and provide it back to the division's sales force systems. With accurate data on physician outreach, the division would be better able to generate accurate compliance reports in a timely manner. In short, the division mapped out a neat solution to its immediate problem. Let's consider how this scenario would play out based on which MDM approach is employed-application or platform.
Upside-Down: In the MDM application approach, the pharmaceutical division would first isolate the business logic for the creation and management of the physician (customer) data in a separate MDM hub. They would then develop the graphical user interface (GUI) to support the business logic based on the data model dictated by the existing application infrastructure. This is called the "Outside-In" approach, where the division started with a specific problem (compliance reporting on physician outreach) and business logic tied to that problem, then built a GUI to manage the business logic, and (by default in this case) the data model to support it all.
Right-Side Up: The MDM platform approach takes exactly the opposite tack from the application approach. In the platform approach, the pharmaceutical division would begin its effort with the data model. Once complete, it would then configure the graphical user interface to manage the master data. Finally, it would build support for assembling business logic on top of the data model that closely resembles the business problem tied to the industry. Called the "Inside-Out" approach, this MDM strategy starts with the data in mind and provides the flexibility to configure the GUI and business logic on top of the data that was previously defined.
The MDM Cul-de-Sac
Let's get back to our hypothetical business problem posed by the conventional pharmaceutical division and the larger company within which it exists. Had it taken the application approach, the division would have met its immediate business objective and ended up with an MDM system that provided a neat solution to its compliance reporting problems. However, that is all it would have gotten. What if a year after going live with this new system IT decision-makers within the division realized that duplications and other errors and discrepancies in supply chain data was beginning to adversely impact its production schedules? This latest business problem would also be an excellent candidate for another MDM initiative. Yet the business logic, GUI, and data model employed for the original MDM project to address the earlier compliance problem would not be able to address this new problem. Since the original MDM solution was purpose-built to handle a single business entity-the unique particulars of the division's physician outreach/compliance processes-using the application-approach, the MDM initiative could not scale to the next problem. The solution solved the initial problem, but once in place it becomes a static point-solution. As a result, the pharmaceutical division would have to create an entirely new and separate MDM solution around this new supply chain data problem. The result being that the company would end up with two distinct MDM silos, thus compounding the problem posed by non-standardized data.
The Far-Sighted Approach
Now imagine that the pharmaceutical division adopted the platform approach to its compliance reporting problem. As we discussed, and similar to the "right-side up" strategy, the first consideration is the data model and the need to build a detailed guide to where structured data is sourced from, how the various system organize it, which applications draw on it and when, and so forth. Once this critical step is resolved, then the GUI can be configured to manage the data based on the business logic dictated by the business problem. Using this platform-based approach, the pharmaceutical division's MDM system could have easily been expanded to handle any subsequent problems that might arise. This holds true not just for problems within the division, but also for business problems facing the larger organization itself. For instance, the company could optimize the supply chain for the core pharmaceutical operation, perform contract management within the medical device operation, and/or optimize the sales force for over-the-counter division. Since the MDM platform is flexible, it can be used to create the most versatile multidomain MDM solution allowing users to start with any domain, not just customer or product. In doing so, they can evolve the same multidomain MDM platform to include any other type of business problem that may arise.
MDM Done Right-Side Up
One of the great promises of master data management is that it removes the data errors and conflicts inherent to so many enterprises, and ultimately enables redundant data stores and systems to be eliminated. However, implementing MDM using the application approach makes it impossible to realize these benefits. In fact, the MDM application approach often leads the customer to procure different MDM applications to solve different problems, hence creating the same data silos it was suppose to correct. For these reasons, progressing along a business logic, GUI, data model is actually backward, or upside-down, if you will.
The conventional upside-down/outside-in approach might work for application solutions such as enterprise resource planning (ERP), customer relationship management (CRM), and supply chain management (SCM) because they solve a single business problem. Multidomain MDM, however, is by nature horizontal (i.e., platform-centric) and doesn't fit the application paradigm. For these reasons only a multidomain MDM platform can provide the most flexible approach to creating and evolving MDM solutions throughout the enterprise and over time.