According to a survey by Tower Group, companies maintain master data separately in at least 11 or more source systems. The picture is actually even more complex than this, since large companies rarely have just one instance of an enterprise resource planning (ERP) or customer relationship management (CRM) system. It is not unusual for global companies to have 50 or more separate ERP instances, each of which will have a slightly different implementation from the next. So how exactly do the codes for "customer" and "product" get managed across this panoply of systems?
The short answer is: with difficulty. The management of what is becoming known as "master data" (things such as products, channels, locations, customers, organizational units - as distinct from the business transactions themselves) is a giant headache. This inconsistency makes it hard to analyze business performance and can cause many operational problems, such as duplication of product lines. Most organizations are slaves rather than masters of their corporate data today.
Shell Lubricants was an interesting case in point. They had a broadly decentralized structure and had made acquisitions, such as Pennzoil with its own extensive product line, and had in total 30,000 packed product combinations. When they wished to globalize their business processes and also move more sales to the Web, it was clear that they would need to improve the management of the master data in this area, such as product codes, formulations and brand names. Over the years, local subsidiaries had created many local variations of products to suit local markets (a lubricant formula that works well in the steamy heat of Vietnam may not flourish in a Norwegian winter and vice versa), but it was likely that not all these product variations were necessary. However, standardization to one universal set of master data was entirely impractical, as the costs of modifying the codes, safety sheets, packaging and brand data embedded in dozens of ERP and other operational systems would be huge.
There were two major stages to this project: the first was understanding the problem; the second was using these insights to make operational changes to the business. Initially the team went through a process of mapping each product against a set of criteria to see whether differences were really needed, identifying overlaps and developing a new set of products. Local management was challenged to determine whether the local market variations were real or could in fact already be accounted for by a product that existed elsewhere.
The next stage was to improve the operational business based on this insight. By the time they finished, the count of truly different products was just one-fifth of the product count in the operational systems. A sophisticated system was developed to manage the mapping between the new definitions and the multiple aliases of each in the various operational systems. By linking up this global product catalog to an established EAI tool from IBM, product managers are now able to not just view, but also update product definitions across the globe with changes driven back from the master catalog into the operational systems.
It is important to understand that this is not just some trivial mapping of product codes. This is best illustrated by a true story. The lead consultant on the project was in a French refinery and meeting with a gentleman who had the wonderful job title of "grease designer," hoping to leave with a copy of his product portfolio. On the desk was a pile of papers a foot high. When asked whether this was the product portfolio, he laughed and explained that this was the information on just one product, covering formulation, components, properties, test methods, material safety sheets, etc. This is the master data that describes this particular product that was made and sold, and all of this has to be managed.
The key to success of this project was both the business buy-in, but also the ability of the technology used to accept that there were multiple "versions of the truth" due to the inherently different needs of different business functions (manufacturing, distribution, marketing), i.e., that there was not just one single global definition of every product sold. This hard reality tends to elicit a state of denial from three places:
Central CIO functions frequently feel uncomfortable admitting that the world cannot be represented on a single PowerPoint slide. They consequently prefer not to confront the business and admit the extent of the problem.
The business users who are actually living with the lack of flexibility that the inability to manage master data brings, frequently don't realize that there is a better way. They too easily retreat into departmental stovepipes, blaming the problem on "those people in marketing " (or manufacturing or distribution or sales).
Software vendors are uncomfortable because their installed base of applications works on the assumption that there is a single holy grail version of all data definitions and that any variation to that is "legacy" i.e., something that can be quietly ignored. After all, designing an application that can deal with 11 separate definitions of the same piece of data simultaneously is hard. It is much easier to expect the customers to wave a magic wand and simplify their world to fit the limitations of the software applications.
