 | |
The emerging field of ‘master data management’ is simply how to deal with data that needs to be shared between different computer systems, data such as products or customers. So, four years after the big rationalisation of IT systems in the late 1990s, how many different computer systems does a large company have? One subsidiary of a large energy company, after putting in every module of SAP, still had 175 interfaces to other systems. A CIO of a large multinational recently admitted to having 650 different installed enterprise applications.
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’, that is, things such as products, channels, locations, customers, organisational units (as distinct from the business transactions themselves), is a giant headache. This inconsistency makes it hard to analyse business performance, but can cause many operational problems also, for example, duplication of product lines. Most organisations are slaves rather than masters of their corporate data today.
Shell Lubricants is an interesting case in point. It had a broadly decentralised structure and had in total 30,000 packed product combinations. When it wished to globalise the business processes, and also move more sales to the web, it was clear that it would need to improve the management of the master data in this area, such as product codes, formulations, and brand names. However standardisation 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 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 then come out with a new set of products.
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.
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:
l 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.
l The business users who are actually living with the lack of flexibility that the inability to manage master data brings, frequently don’t realise that there is a better way, and too easily retreat into departmental stovepipes, blaming the problem on ‘those people in marketing, manufacturing, distribution, or sales.’
l 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.
When working for Shell I went to a well-known ERP vendor and explained a problem that one of our businesses was having, which involved sharing and comparing data across different modules of the software: the response was ‘our software cannot do that, therefore it cannot be a valid business requirement,’ something that came as a surprise to the Shell marketing VP sitting next to me whose problem it was. The only alternative generally available today is EAI spaghetti, with a range of interfaces that to describe needs something resembling a wiring diagram for a space shuttle rather than a corporate IT architecture. Data movement should not be confused with data management.
Application software vendors, always quick to spot a revenue opportunity, have recently sniffed that there may be money in this area, so a range of ‘master data,’ ‘data hub,’ and other products have been running off the presses of their slick marketing departments. However, while their products admit to the possibility that there may be more than one instance of their own applications installed in customers (progress of a sort) they essentially skim over the inconvenient notion that a customer may have applications from different vendors. Of course there may be an agenda here: ‘ah well, if only you’d throw out that ERP/CRM/supply chain system from vendor X and standardise on ours globally…’. The way forward starts, as at Shell Lubricants, by an admission by the business that they have a problem: master data scattered across departmental boundaries and responsibilities. Cross-functional business teams need to sift the legitimately different requirement from the ‘not invented here,’ and decide what has to be maintained separately but linked due to genuine differences and what master data can be cleaned up. IDC calls this business function a ‘policy hub.’
ERP systems don’t solve the master data issue since they assume a uniform, standard business model (which in the real world does not exist in large companies) and tend to deal only with data held in their own system.
Data warehouses are a useful step forward provided they can handle multiple, concurrent, linked business definitions. However they are not sufficient to solve the overall problem since an application is then needed to deal with the workflow to support the business policy hub, that is, can deal with version control, authorisation, security as well as analysis of the company’s master data. The application needs to be able to deal with apparently ‘invalid’ data that is effectively authored and evolved through a number of stages until it is reconciled; data warehouse applications rightly reject such invalid data.
Master data management solutions are needed that allow customers to understand and analyse their multiple business definitions across the various source systems, propose changes to this master data, get authorisation where necessary, and then publish new versions of product catalogs and customer segmentation that can be fed into the core operational systems where appropriate. Understanding this business process and realising that there is quite elaborate workflow process required to do this still seems to elude most of our industry, as well as most IT departments. Perhaps talking to business customers seriously about the problem might help.
VTR
Andy Hayler is founder and chief strategist, Kalido.
For further information visit www.kalido.com or call 020 7934 3300.
|
