A common seen user requirement for Master Data Management (MDM) solutions is an ability to copy the content of the attributes of an existing entity when creating a new entity. For example when creating new product you may find it nice to copy all the field values from an existing similar product to the new product and then just change what is different for the new product. Just like using copy and paste in excel or other so called productivity tools.
We all know the dangers of copy and paste and there are plenty of horror stories out there of the harsh consequences like when copying and pasting in a job application and forgetting to change the name of the targeted employer. You know: “I have always dreamed about working for IBM” when applying at Oracle.
The exact same bad things may happen when doing copy and paste when working with master data. You may forget to change exactly that one important piece of information because you miss guidance on the copied data within your system of entry.
Using an inheritance approach is a better way. This approach is for product master data based on having a mature hierarchy management in place. When creating a new product you place your product in the hierarchy where it will inherit the attributes common for products on the same branch of the hierarchy and leave it for you to fill in the exact attributes that is specific for the new product. If a new product requires a new branch in the hierarchy, you are forced to think the common attributes for this branch through.
For party (customer, supplier and other business partner) master data you may inherit from the outside world taking advantage of fetching what is already digitalized, which includes names, addresses and other contact data, and leaving for you to fill in the party master data that is specific to your way of doing business.
Anecdotes are powerful when working with getting awareness of opportunities in the data quality, data governance and Master Data Management (MDM) realm. Such anecdotes are most often either external or internal data and information train-wrecks, while the success stories are more seldom – at least until now in my experience.
Using anecdotal evidence is useful when identifying major pain points with potential for improvement and are indispensable when striving to get a common understanding about the issues to be solved.
However, it is within data management as in all other disciplines dangerous to jump to conclusions based on anecdotal evidence. We do need some more scientific evidence to nail the collection of issues and the prioritizing of proper solutions.
The anecdotal evidences with the highest weights are those included according to the HiPPO (Highest Paid Person’s Opinion) principle as examined in the post When Rhino Hunt and the HiPPO Principle makes a Perfect Storm. Here we may have a clash between getting executive sponsorship and support for a given programme and actually doing the right things, based on scientific evidence, within the programme.
What are your experiences and lessons learned? How have you managed to balance anecdotal evidence and scientific evidence in data management?
This week I had the pleasure of speaking in Copenhagen at an event about The Evolution of MDM. The best speaking experiences is when there are questions and responses from the attendees. At this event, such lovely interuptions took us around some of the tough questions about Master Data Management (MDM), like
- Is the single source of truth really achievable?
- Does MDM belong within IT in the organization?
- Is blockchain technology useful within MDM?
Single source of truth
Many seasoned MDM practitioners has experienced attempts to implement a single source of truth for a given MDM domain within a given organization and seen the attempt failed miserably. The obstacles are plentiful including business units with different goals and IT landscapes with heterogenic capabilities.
Single place of trust
I think there is a common sentiment in the data management realm about to lower that bar a bit. Perhaps a single place of trust is a more realistic goal as examined in the post Three Stages of MDM Maturity.
MDM in IT
We all know that MDM should belong to the business part of the organization and anchoring MDM (and BI and CRM and so many other disciplines) in the IT part of the organization is a misunderstanding. However, we often see that MDM is placed in the IT department because IT already spans the needs of marketing, sales, logistics, finance and so on.
My take is that the actual vision, goals and holistic business involvement trumps the formal organizational anchoring. Currently I work with two MDM programmes, one anchored in IT and one in finance. As an MDM practitioner, you have to deal with business and IT anyway.
Blockchain is a new technology disrupting business these days. Recently Andrew White of Gartner blogged about how blockchain thinking could go where traditional single view of master data approaches haven’t been able to go. The blog post is called Why not Blockchain Data Synchronization? As Andrew states: “The next year could be very interesting, and very disrupted.”
PS: My slides from the event are available here: MDM before, now and in the future.
Every organization needs Master Data Management (MDM). But does every organization need a MDM tool?
In many ways the MDM tools we see on the market resembles common database tools. But there are some things the MDM tools do better than a common database management tool. The post called The Database versus the Hub outlines three such features being:
- Controlling hierarchical completeness
- Achieving a Single Business Partner View
- Exploiting Real World Awareness
Controlling hierarchical completeness and achieving a single business partner view is closely related to the two things data quality tools do better than common database systems as explained in the post Data Quality Tools Revealed. These two features are:
- Data profiling and
- Data matching
Specialized data profiling tools are very good at providing out-of-the-box functionality for statistical summaries and frequency distributions for the unique values and formats found within the fields of your data sources in order to measure data quality and find critical areas that may harm your business. These capabilities are often better and easier to use than what you find inside a MDM tool. However, in order to measure the improvement in a business context and fix the problems not just in a one-off you need a solid MDM environment.
When it comes to data matching we also still see specialized solutions that are more effective and easier to use than what is typically delivered inside MDM solutions. Besides that, we also see business scenarios where it is better to do the data matching outside the MDM platform as examined in the post The Place for Data Matching in and around MDM.
Looking at the single MDM domains we also see alternatives. Customer Relation Management (CRM) systems are popular as a choice for managing customer master data. But as explained in the post CRM systems and Customer MDM: CRM systems are said to deliver a Single Customer View but usually they don’t. The way CRM systems are built, used and integrated is a certain track to create duplicates. Some remedies for that are touched in the post The Good, Better and Best Way of Avoiding Duplicates.
With product master data we also have Product Information Management (PIM) solutions. From what I have seen PIM solutions has one key capability that is essentially different from a common database solution and how many MDM solutions, that are built with party master data in mind, has. That is a flexible and super user angled way of building hierarchies and assigning attributes to entities – in this case particularly products. If you offer customer self-service, like in eCommerce, with products that have varying attributes you need PIM functionality. If you want to do this smart, you need a collaboration environment for supplier self-service as well as pondered in the post Chinese Whispers and Data Quality.
All in all the necessary components and combinations for a suitable MDM toolbox are plentiful and can be obtained by one-stop-shopping or by putting some best-of-breed solutions together.
Today the 14th January in our times calendar used to be the first day in the new year when the Julian calendar was used before different countries at different times shifted to the Gregorian calendar.
Such shifts in what we generally refer to as reference data is a well-known pain in data management as exemplified in the post called The Country List. Within data warehouse management, we refer to this as Slowly Changing Dimensions.
Master Data Management (MDM) and Reference Data Management (RDM) are two closely related disciplines and often we may use the terms synonymously and indeed sometimes working with the same real world entity is MDM in one context but RDM in another context.
I have worked in industries, as public transit, where the calendar and related data must be treated as master data. But surely, in many other industries this will be an overkill. However, I have seen other entities treated as a simple List of Values (LoV) where it should be handled as master data or at least more complex reference data. Latest example is plants within a global company, where the highest ambition is proposed to be a mark for active or inactive, which hardly reflect the complexity in starting or buying a plant and closing or selling the same and the data management rules according to the changing states.
So happy 14th of January even if this is not New Year to you – but hey, at least it is my birthday.
Master Data Management (MDM) is a bit more than 10 years old as told in the post from last year called Happy 10 Years Birthday MDM Solutions. MDM has developed from the two disciplines called Customer Data Integration (CDI) and Product Information Management (PIM). For example, the MDM Institute was originally called the The Customer Data Integration Institute and still have this website:http://www.tcdii.com/.
Today Multi-Domain MDM is about managing customer, or rather party, master data together with product master data and other master data domains as visualized in the post A Master Data Mind Map.
You may argue that PIM (Product Information Management) is not the same as Product MDM. This question was examined in the post PIM, Product MDM and Multi-Domain MDM. In my eyes the benefits of keeping PIM as part of Multi-Domain MDM are bigger than the benefits of separating PIM and MDM. It is about expanding MDM across the sell-side and the buy-side of the business eventually by enabling wide use of customer self-service and supplier self-service.
The external self-service theme will in my eyes be at the centre of where MDM is going in the future. In going down that path there will be consequences for how we see data governance as discussed in the post Data Governance in the Self-Service Age. Another aspect of how MDM is going to be seen from the outside and in is the increased use of third party reference data and the link between big data and MDM as touched in the post Adding 180 Degrees to MDM.
Besides Multi-Domain MDM and the links between MDM and big data a much mentioned future trend in MDM is doing MDM in the cloud. The latter is in my eyes a natural consequence of the external self-service themes and increased use of third party reference data.
If you happen to be around Copenhagen in the late January I can offer you the full story at a late afternoon event taking place in the trendy meatpacking district and arranged by the local IT frontrunner company ChangeGroup. The event is called Master Data Management: Before, now and in the future.
Now is the time of the year where you can try predicting what will happen in the next year within a certain field of interest to you.
When we talk about predictions within data management, we usually mean something based on analysing historical data with emphasis on seeing some recent trends.
My precognitions for the Master Data Management (MDM) market I have to admit is of the more traditional kind. Gut feelings. Qualified guessing if you like.
So, here are three foreseeings:
- Gartner, the analyst firm, will finally stop publishing two magic quadrants for MDM (one for customer and product MDM) and, using some suitable data from their surveys, admit that there now is only one true multidomain market for larger MDM vendors. They might however introduce a new quadrant for what was more or less known as Product Information Management (PIM). But under a new term and with focus on eCommerce capabilities.
- There will be more acquisitions in the market than seen since five years ago. At least one of the larger former product MDM specialists will buy a customer MDM specialist first and foremost in order to gain reference clients. Also MDM vendors will be looking for buying land in the new big data world.
- The numbers and scopes of MDM projects will increase and therefore there will be a shortage of people with MDM experience. This trend will pave the way for more agile approaches to MDM including implementing less complex MDM solutions and services whereof most, in contradiction to the multidomain trend, will be domain (customer/party, product, location) niche players.