WHY NOT TO PUT TRANSACTIONAL DATA IN AN MDM HUB

ENTITY WHITE PAPER

ENTITY WHITE PAPER WHY NOT TO PUT TRANSACTIONAL DATA IN AN MDM HUB

WHY NOT TO PUT TRANSACTIONAL DATA IN AN MDM HUB...

Organisations hold a number of different categories of data. For example, Metadata, Reference Data, Master Data, Transaction Data, Audit Data and Log Data are all typical categories of data. The classification of data defines how important the data is to an organisation and therefore the level of effort the organisation should spend to care for it and govern it.

In the examples above, log data is typically the least valuable. A low quality or incorrect message in a log file is unlikely to cause significant issues within the business. However a low quality or incorrect piece of reference data could result in an entire report being wrong. If that report is used regularly as the basis for important business decisions then the financial consequences will be significant.

MDM establishes a governance platform to manage master data and improve its quality. However this benefit does not come for free and mastering data on the platform incurs a cost for each entity and attribute it manages. These costs include the initial cost of integrating, cleansing, validating, matching and synchronising the data and the on-going maintenance, profiling and stewardship thereafter.

Typically, the business case to manage master data in an MDM hub is an easy one, due to its critical importance to the business. However the cost is typically not justified for transactional data due to its higher volumes and lower importance to the business.

Of course, there may be a requirement to view master data along alongside transactional data. Examples of this presentation style are EDW reports and self-service portals (where the latter perhaps shows a list of recent support calls, quotes and letters alongside the master data details). A good MDM architecture allows this to be achieved by integrating the MDM cross-reference data with transactional systems in order for them to be combined and visualised in the target system.

As a result we strongly recommend that transactional data is not stored within the MDM hub. Indeed we have seen a number of MDM projects fail due to the size and complexity of the data model. The line between transactional data and master data is often unclear. The section below defines a set of criteria to help with the differentiation.

...AND HOW TO DISTINGUISH IT FROM MASTER DATA

The bare minimum attributes requires identifying and distinguishing parties are typically (in order of importance):

Even this minimal dataset will allow the hub to de-duplicate and cross reference customers between systems and provide a full 360 degree view of customer at the data warehouse or another suitable UI.

2

• Identification Numbers (e.g. internal bank references, passport numbers, citizen ID numbers, account numbers etc)

Name (including all name fields, languages and name field combinations)

• DOB (individuals only)

• Electronic Contact Details (email address, telephone numbers etc)

• Addresses

• Gender (individuals only)

MANAGEMENT SOLUTIONS

However there may be a business case to add other entities and attributes to the hub. In order to calculate whether a business case exists for an entity or attribute, we recommend that the following set of criteria are considered together before making a decision:

Behaviour – Master data can be described by the way it interacts with other data. For example a customer buys a product. An employee reports to his manager. Master data typically makes up the nouns in the interaction and transactional data makes up the verbs. Sale, delivery, purchase, call, email, quote are all examples of transactional data. In banking sectors, Customer, Product and Account are typically master data. Master data has a defined lifecycle and should be describable in the way it is created, read, deleted and searched.

Value – Each attribute added to the hub carries a significant IT and business cost. This includes the initial costs of integrating, cleansing, validating, matching and synchronising the attribute and the on-going maintenance, profiling and stewardship thereafter. Therefore all attributes within the hub should have a high business value. Value can be expressed in positive and negative terms. For example, attributes may allow a meaningful business benefit to be realised (e.g. better customer experience) or a negative cost to be avoided (e.g. fines due to legislative incompliance).

Volatility – Master data is less volatile than transactional data and as a result it changes less frequently. For example, some companies may consider “contract” a master data entity because it lasts for several years. Other companies may establish contracts that last only days (or perhaps even seconds). The importance of the data is the same to both companies, however only the first has a business case to manage the data within an MDM system. The threshold to use for volatility varies between sectors and companies but within the banking sector we would expect master data attributes to typically change a maximum of twice during any twelve month period.

Volume – Although entities and attributes may fit the criteria described above they may not require inclusion within the MDM system. For example, a company with three customers would not consider them as master data. However a company with hundreds of thousands of customers would benefit from managing them within an MDM system. The importance of the data is the same to both companies, however only the second has a business case to manage the data within an MDM system.

Complexity – As complexity increases, the business case to include within an MDM system increases. Equally, the less complicated an entity, the less likely the need to manage it. For example a bank vault does not need to master information on each gold bar stored, but rather keep an aggregate count of them. The value, lifetime and volume of the gold bars are high yet the complexity is low.

Reuse – One of the primary drivers of master-data management is reuse. If a master-data entity or attribute is reused in multiple systems, it’s likely that it should be managed with a master-data management system. In fact the more systems it is used within, the higher the business case to master it.

Consensus – Finally, it is important that an entity or attribute is consistently understood across the business. If you try to make everybody happy by adding all the source attributes for an entity from all the different business departments you will often end up with a master data model that is too complex and cumbersome to be useful. For example there may be pressure to master calculated fields or alternate codes for the same attribute. In both of these examples, the data shouldn’t be held in the hub although the calculations to create one from the other may be usefully applied.

Defining the master data to manage and the roadmap for its inclusion is often the most difficult part of the process. Often it is the first time that departments across the business have had to agree on a definition. It is important that the decision process and priorities are clear and that there is a final decision maker agreed beforehand. It is also worth remembering that the definition of what is, and isn’t master data will change as the company matures.

WHY NOT TO PUT TRANSACTIONAL DATA IN AN MDM HUB ENTITY WHITE PAPER

3

MANAGEMENT SOLUTIONS

MANAGEMENT SOLUTIONS

Entity House 980 Cornforth Drive Kent Science Park Sittingbourne KENT ME9 8PX United Kingdom

www.entity.co.uk

For more information please contact:

Sam ThomsettMarketing Manager, Entity Groupsam.thomsett@entity.co.ukwww.entity.co.uk