Are You Master of Your Data or its Slave?
The emerging field of ‘master data management’ (MDM) deals with the issue of how to handle data that needs to be shared between different computer systems. It has become important because, five years after the big rationalization of IT systems in the late 1990s, most large companies still have dozens, and in some cases hundreds, of different IT systems installed.
The management of what is becoming known as ‘master data’ – the core definitions of things such as products, channels or customers, which all these systems gather information about – is a giant headache. 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 financial and banking 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.
How can managers, tasked with tracking company performance by taking information from multiple IT systems, actually get the answers they need when there are so many different versions of what they are measuring? When managing currency risk across a wide range of countries, how can the treasurer be sure that exposure is correctly measured across this panoply of systems? The short answer is: with difficulty. Most financial organizations are slaves rather than masters of their corporate data today.
When financial companies wish to manage and report on global business performance, it is clear that they would need to improve the management of the master data, such as the general ledger, product codes, formulations and customers. However, standardization on one universal set of master data is entirely impractical, as the costs of modifying the codes, associated information, packaging and brand data embedded in dozens of ERP and other operational systems would be huge.
For banking and treasury companies wishing to execute MDM projects, there are two major stages. The first is understanding the problem: the idea of mapping all the information against a set of criteria to see whether differences are really needed, identifying overlaps, and then establishing a new set of products. The second is using these insights to make operational changes to the business. However, it is important to understand that this is not just some trivial mapping of codes or simple currency conversion.
After a decade of vast global projects (for example one large company spent US$1.5bn rolling out SAP globally), virtually every large financial company has a wide range of established applications each with its own master data definition, even if those multiple systems implementations are from fewer vendors. Large organizations frequently have dozens or even hundreds of slightly different implementations of the same software deployed throughout their global operations. This diversity makes global planning extremely awkward: if different subsidiaries allocate their costs differently, how can the central finance function be certain of whether risks balance out, are natural hedges, or require hedging to reduce risk? How can global credit risk be carried out if it is unclear how much business is really being transacted with a multi-national customer that may operate across dozens of subsidiaries and countries?
What is needed are applications that don’t try to fit the world around a simplified version of reality, but are based on the assumption that business models are indeed complex and can probably never be standardized due to the inherently different needs of different markets, customers and varying business needs. Instead, technologies are required that manage the complexity of real-world business models, and expect there to be 11 or 57 different definitions of core master data.
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’ – one that can deal with version control, authorization, security as well as analysis of the company’s master data. Master data management solutions are needed that allow customers to understand and analyze their multiple business definitions across the various source systems, propose changes to this master data, and then publish new versions of cost allocation structures, product catalogs and customer segmentation. Understanding this business process and realising that a rather elaborate workflow process is required to do this still seems to elude most IT departments in the financial sector. Talking to business customers seriously about the problem is perhaps the first step.