Master Data Management Use Case

Master Data Management (MDM) comprises “[…] business applications, information management methods, and data management tools to implement the policies, procedures and infrastructures that support the capture, integration, and subsequent shared use of accurate, timely, consistent, and complete master data” (Loshin 2010, p. 9). The overarching goal of MDM is therefore to ensure consolidated, harmonized, correct master data, interoperability between master data pools, and to provide this data to business critical functions in a timely manner. Consequently, MDM is the pre- requisite for efficient online transactional processing (OLTP) and online analytical processing (OLAP). Without consolidated master data for example, the correct execution of order management or global category management, based on harmonized spend reporting, would not be possible.

Another example in addition to supply management where MDM plays an important role is ‘product lifecycle management’ (PLM). In inter-organizational innovation generation of PLM, original scope requirements are collaboratively defined between business partners involved in the innovation process. Specifications are defined from here and are iteratively discussed in order to reach a final understanding about how the goals of the innovation should be achieved. Based on the agreed specification, at least one prototype is normally developed and iterated between the business partners in order to produce a tangible concept model of an acceptable final item (product, material, article, service etc.). Finally, the item is defined in detail, and the handover to production, roll-out, marketing etc. can happen.

7 Discussion 120

This simplified PLM example is presented in Figure 34, showing the master data management challenges and keeping track of the various output types of all phases of the innovation process, and the references between the semantic identities in various business partner applications.

Figure 34. Master Data Management in a PLM Example

The complexity would of course be much higher if taking into consideration more than two involved business partners, more than one successor object (multiple specifications or prototypes for example), and by looking at the complete master data set, describing basically the same natural entity, and not looking at just the identifications (ID) attributes.

In this example, the IDs of the output types in both business partner systems are captured according to the systematics of the corresponding business partner systems, and references need to be handled to identify that two data sets (one from each side) refer to the same output type entity. This also means that the describing attributes of the output types are managed twice in both systems, of business partner A and B, and relevant updates on one side need to be proclaimed to the other.

Today of course, this kind of innovation collaboration often takes place in collaboration environments. For the majority of the business partners involved in this kind of process however, the master data of the innovation steps needs to be harmonized with the internal systematic of the corresponding application systems.

In an extended enterprise for example, one leading company is driving the collaboration with several service providers to design a new product. The identification and

service providers contributing to the design of the new product.

Applying the networked business object (n-BO) design principle to the same example, the evolutionary status flow would schematically be like in Figure 35.

Figure 35. Master Data Management in a PLM Example with n-BO Type ITEM

The participating business partners in the PLM innovation generation process would collaborate on the same n-BO of type ITEM, with one unique identifier ‘AB1000’. Moving from the requirements, to specification, prototype and item states in the innovation generation process, replications of same or similar data would not be necessary as well as any cross referencing between the different data sets of the business partners.

Another example of where MDM is a critical factor is business partner data. Many companies are struggling to reduce duplicate data records and to harmonize business partner data in different data pools across organizational units. This becomes even more challenging of course when it comes to inter-organizational master data management across different companies.

A typical example of issues of managing master data between various business partners is visualized in Figure 36.

7 Discussion 122

Figure 36. Master Data Management in a Business Partner Example

Business partner A possesses two master data records for the same business partner B. The duplicate needs to be identified and consolidated to one ‘best’ data record, covering the most current data from both records. In this example, this would be possible with the identical reference ID ‘BA200’, the identification of the business partner A in the system of B. This kind of cross reference is often not maintained, thus making it all the more difficult to identify and eliminate duplicates.

Applying the n-BO design principle to this example, and including previous states of the n-BO of type BUSINESS PARTNER, the n-BO evolvement of the business partner data is shown in Figure 37.

history from contact to business partner would be referenced in one object, there would be no duplication of general business partner data in the collaboration network and specific one-to-one master data between business partner A and B, and update replications and cross referencing would not be necessary.

In addition to data and process integration, the combination with people integration aspects is also important in master data management. In PLM for example, collaboration and exchange of unstructured data takes place to a large extent during innovation generation and item definition. Similarly, the business partner data accuracy and exchange, based on the respective n-BO can be supported by reusing existing networked business partner data without the need for duplications. The collaborative management of business partner data in specific relations is also supported, again without the need for replications, duplications and cross referencing. The social augmentation design principles could obviously support the collaboration aspect in master data management, for example by providing corresponding social collaboration areas, messaging, feed update and search capabilities in the network.

In summary, the design principles, in particular the application of DP1 (networked Business Objects) would potentially support efficient master data management by providing collaborative data management capabilities and the avoidance of data replications, duplications and cross referencing. The design principles would be highly likely to help “[…] agile organizations [to] adapt to the flood of largely redundant, yet sometimes conflicting pieces of data [who] find that a combination of information sharing and operational collaboration is a differentiating factor for organizational success” (Loshin 2010, p. 1).