Master Data

MDM as Managed Service

Henrik Gabs LiliendahlLeave a comment

This month I am going to London to attend the Master Data Management Summit Europe 2017.

As a teaser before the conference Aaron Zornes made a post called MDM Market 2017-18: Facts vs. Beliefs (with apologies to current political affairs fans!).

In his article, Aaron Zornes looks at the slow intake of multi-domain MDM, proactive data governance, graph technology and Microsoft stuff ending with stating that MDM as MANAGED SERVICE = HOT:

“Just as business users increasingly gave up on IT to deliver modest CRM in a timely, cost effective fashion (remember all the Siebel CRM debacles), so too are marketing and sales teams especially looking to improve the quality of their customer data… and pay for it as a “service” rather than as a complex, long-time-to-value capital expenditure that IT manages”.

Master Data ShareI second that, having been working with the iDQ™ service years ago, and will add, that the same will be true for product data as well and then eventually also multi-domain MDM.

How that is going to look like is explained here on Master Data Share.

Data Quality for the Product Domain vs the Party Domain

Henrik Gabs LiliendahlLeave a comment

Same Same But Different

The difference between solving data quality issues for party (customer, supplier and other business partner) master data and product master data was discussed 7 years ago on this blog in the post Same Same But Different.

Data Quality Dimensions
Some data quality dimensions

Since then I have worked intensively with both party master data and product master data and the data quality challenges organizations have within these domains.

Building on the findings from 7 years ago and recent experiences, I think there are two areas it is worth emphasizing on:

  • Data Quality Dimensions: All dimensions are important and they support each other in solving the issues. But there are some differences as explained in the post Multi-Domain MDM and Data Quality Dimensions. In my mind, uniqueness is the worst pain for party master data and completeness is the worst pain for product master data.
  • External Data Sources: The use of data sources was examined in the post 1st Party, 2nd Party and 3rd Party Master Data. In my mind, extensive utilization of third party data is paramount for party master data quality and effective exchange of second party data is paramount for product master data quality.

A Sharing Concept

For solving both party master data and product master data quality issues you need Multi-Domain MDM for business ecosystems as proposed in the Master Data Share concept.

Ecosystems are The Future of Digital and MDM

Henrik Gabs LiliendahlLeave a comment

A recent blog post by Dan Bieler of Forrester ponders that you should Power Your Digital Ecosystems with Business Platforms.

In his post, Dan Bieler explains that such business platforms support:

·      The infrastructure that connect ecosystem participants. Business platforms help organizations transform from local and linear ways of doing business toward virtual and exponential operations.

·      A single source of truth for ecosystem participants. Business platforms become a single source of truth for ecosystems by providing all ecosystem participants with access to the same data.

·      Business model and process transformation across industries. Platforms support agile reconfiguration of business models and processes through information exchange inside and between ecosystems.

A single source of truth (or trust) for ecosystem participants is something that rings a bell for every Master Data Management (MDM) practitioner. The news is that the single source will not be a single source within a given enterprise, but a single source that encompasses the business ecosystem of trading partners.

Gartner Digital Platforms.png

Gartner, the other analyst firm, has also recently been advocating about digital platforms where the ecosystem type is the top right one. As stated by Gartner: Ecosystems are the future of digital.

I certainly agree. This is why all of you should get involved at Master Data Share.

 

Multi-Domain MDM and PIM, Party and Product

Henrik Gabs LiliendahlLeave a comment

Multi-Domain Master Data Management (MDM) and Product Information Management (PIM) are two interrelated disciplines within information management.

While we may see Product Information Management as the ancestor or sister to Product Master Data Management, we will in my eyes gain much more from Product Information Management if we treat this discipline in conjunction with Multi-Domain Master Data Management.

Party and product are the most common handled domains in MDM. I see their intersections as shown in the figure below:

Multi-Side MDM

Your company is not an island. You are part of a business ecosystem, where you may be:

  • Upstream as the maker of goods and services. For that you need to buy raw materials and indirect goods from the parties being your vendors. In a data driven world you also to need to receive product information for these items. You need to sell your finished products to the midstream and downstream parties being your B2B customers. For that you need to provide product information to those parties.
  • Midstream as a distributor (wholesaler) of products. You need to receive product information from upstream parties being your vendors, perhaps enrich and adapt the product information and provide this information to the parties being your downstream B2B customers.
  • Downstream as a retailer or large end user of product information. You need to receive product information from upstream parties being your vendors and enrich and adapt the product information so you will be the preferred seller to the parties being your B2B customers and/or B2C customers.

Knowledge about who the parties being your vendors and/or customers are and how they see product information, is essential to how you must handle product information.  How you handle product information is essential to your trading partners.

You can apply party and product interaction for business ecosystems as explained in the post Party and Product: The Core Entities in Most Data Models.

3 Old and 3 New Multi-Domain MDM Relationship Types

Henrik Gabs Liliendahl4 Comments

Master Data Management (MDM) has traditionally been mostly about party master data management (including not at least customer master data management) and product master data management. Location master data management has been the third domain and then asset master data management is seen as the fourth – or forgotten – domain.

With the rise of Internet of Things (IoT), asset – seen as a thing – is seriously entering the MDM world. In buzzword language, these things are smart devices that produces big data we can use to gain much more insight about parties (in customer roles), products, locations and the things themselves.

In the old MDM world with party, product and location we had 3 types of relationships between entities in these domains. With the inclusion of asset/thing we have 3 more exiting relationship types.

Multi-Domain MDM Relations

The Old MDM World

1: Handling the relationship between a party at its location(s) is one of the core capabilities of a proper party MDM solution. The good old customer table is just not good enough as explained in the post A Place in Time.

2: Managing the relationship between parties and products is essential in supplier master data management and tracking the relationship between customers and products is a common use case as exemplified in the post Customer Product Matrix Management.

3:  Some products are related to a location as told in the post Product Placement.

The New MDM World

4: We need to be aware of who owns, operates, maintains and have other party roles with any smart device being a part of the Internet of Things.

5: In order to make sense of the big data coming from fixed or moving smart devices we need to know the location context.

6: Further, we must include the product information of the product model for the smart devices.

Expanding to Business Ecosystems

In my eyes, it is hard to handle the 3 old relationship types separately within a given enterprise. When including things and the 3 new relationship types, expanding master data management to the business ecosystems you have with trading partners will be imperative as elaborated in the post Data Management Platforms for Business Ecosystems.

IoT and Multi-Domain MDM

Henrik Gabs LiliendahlLeave a comment

The Internet-of-Things (IoT) is a hot topic and many Master Data Management (MDM) practitioners as well as tool and service vendors are exploring what the rise of the Internet-of-Things and the related Industry 4.0 themes will mean for Master Data Management in the years to come.

globalIn my eyes, connecting these smart devices and exploiting the big data you can pull (or being pushed) from them will require a lot for all Master Data Management domains. Some main considerations will be:

  • Party Master Data Management is needed to know about the many roles you can apply to a given device. Who is the manufacturer, vendor, supplier, owner, maintainer and collector of data? Privacy and security matters on that basis will have to be taken very seriously.
  • Location Master Data Management is necessary at a much deeper and precise level than what we are used to when dealing with postal addresses. You will need to know a home location with a timespan and you will need to confirm and, for moving devices, supplement with observed locations with a timestamp.
  • Product and Asset Master Data Management is imperative in order to know about the product model of the smart device and individual characteristics of the given device.

It is also interesting to consider, if you will be able to manage this connectivity within a MDM platform (even multidomain and end-to-end) behind your corporate walls. I do not think so as told in the post The Intersections of 360 Degree MDM.

The Pros and Cons of Master Data (Management)

Henrik Gabs Liliendahl4 Comments

As a comment on my LinkedIn status about my previous post Jan van Til asks:

Wouldn’t the world be far better of without the concept of master data? What problems are solved by it? What problems are introduced by it? The balance? So … why do we keep toiling with master data?”

What problems are solved?

A common definition of data quality is that data are fit for the intended purpose of use. However, with master data we have multiple purposes of use of these core data entities. In an enterprise architecture with no focus on master data, the same real world construct will be described in many different databases in many different ways.

This causes a myriad of challenges. There are no one face to our customers, which makes us look stupid. We may offer the same product unintentionally with different prices and with different features, which is stupid. Our reporting, business intelligence, data science will be based on ambiguous data and therefore potentially cause stupid decisions.

If we have data quality issues with no centralized management of master data we will fund data cleansing and prevention initiatives many times for the same real world construct – and probably with varying outcome. In a centralized master data management set up, we can avoid reinventing the wheel as explained in the post The Database versus the Hub.

What problems are introduced?

Implementing Master Data Management (MDM) is not without tears. This involves the whole enterprise, and will increasingly caused by the rise of digitalization involve the business ecosystem as well. You will have to spend money and resources, which are not always easily justified.

MDM is a complex discipline involving many stakeholders. There is a high risk of running over budget and time and missing the goals.

As MDM is the remedy against data silos, you may end up with MDM as just another data silo within your enterprise. And still, your MDM hub may be a data silo in your business ecosystem.

The balance

Think big, start small. Make it agile. A good example of an agile approach to MDM is proposed by the MDM vendor Semarchy as described here on What is Evolutionary MDM™?

While you need a strong inner hub for master data in your enterprise, do not try to impose that hub on everything and everyone as for example examined in the post A Different End-to-End Solution for Product Information Management (PIM).

Multi-Side MDM

What is a Master Data Entity?

Henrik Gabs LiliendahlLeave a comment

What is a customer? What is a product? You encounter these common questions when working with Master Data Management (MDM).

The overall question about what master data is has been discussed on this blog often as for example in the post A Master Data Mind Map.

Master Data

The two common questions posed as start of this blog post is said to be very dangerous. Well, here are my experiences and opinions:

What is a customer?

In my eyes, customer is a role you can assign to a party. Therefore, the party is the real master data entity. A party can have many other roles as employee, supplier and other kinds of business partner roles. More times than you usually imagine, the party can have several roles at the same time. Examples are customers also being employees and suppliers who are also customers.

From a data quality point of view, it does not have to matter if a party is a customer or not at a certain time. If your business rules requires you to register that party because the party has placed an order, got an invoice, paid an invoice or pre-paid an amount, you will need to take care of the quality of the information you have stored. You will also have to care about the privacy, not at least if the party is a natural person.

Uniqueness is the most frequent data quality issue when it comes to party master data. Again, it is essential to detect or better prevent if the same party is registered twice or more whether that party is a customer according to someone’s definition or not.

What is a product?

Also with products business rules dictates if you are going to register that product. If you are a reseller of products, you should register a product that you promote (being in your range). You could register a product, if you resell that product occasionally (sometimes called specials). If you are a manufacturer, you should register your finished products, your semi-finished products and the used raw materials. Most companies are actually both a reseller and a manufacturer in some degree. Despite of that degree practically all companies also deals with indirect goods as spare parts, office supplies and other stuff you could register as a product within your organisation in the same way your supplier probably have.

What we usually defines as a product is most often what rather should be called a product model. That means we register information about things that are made in the same way and up by the same ingredients and branded similarly. A thing, as each physical instance of a product model, will increasingly have business rules that requires it to be registered as told in the post Adding Things to Product Data Lake.

Big Data Fitness

Henrik Gabs LiliendahlLeave a comment

A man with one watch knows what time it is, but a man with two watches is never quite sure. This old saying could be modernized to, that a person with one smart device knows the truth, but a person with two smart devices is never quite sure.

An example from my own life is measuring my daily steps in order to motivate me to be more fit. Currently I have two data streams coming in. One is managed by the app Google Fit and one is managed by the app S Health (from Samsung).

This morning a same time shot looked like this:

Google Fit:

google-fit

S Health:

s-health

So, how many steps did I take this morning? 2,047 or 2413?

The steps are presented on the same device. A smartphone. They are though measured on two different devices. Google Fit data are measured on the smartphone itself while S Health data are measured on a connected smartwatch. Therefore, I might not be wearing these devices in the exact same way. For example, I am the kind of Luddite that do not bring the phone to the loo.

With the rise of the Internet of Things (IoT) and the expected intensive use of the big data streams coming from all kinds of smart devices, we will face heaps of similar cases, where we have two or more sets of data telling the same story in a different way.

A key to utilize these data in the best fit way is to understand from what and where these data comes. Knowing that is achieved through modern Master Data Management (MDM).

At Product Data Lake we in all humbleness are supporting that by sharing data about the product models for smart devices and in the future by sharing data about each device as told in the post Adding Things to Product Data Lake.

Golden Records in Multi-Domain MDM

Henrik Gabs Liliendahl5 Comments

The term golden record is a core concept within Master Data Management (MDM). A golden record is a representation of a real world entity that may be compiled from multiple different representations of that entity in a single or in multiple different databases within the enterprise system landscape.

GoldIn Multi-domain MDM we work with a range of different entity types as party (with customer, supplier, employee and other roles), location, product and asset. The golden record concept applies to all of these entity types, but in slightly different ways.

Party Golden Records

Having a golden record that facilitates a single view of customer is probably the most known example of using the golden record concept. Managing customer records and dealing with duplicates of those is the most frequent data quality issue around.

If you are not able to prevent duplicate records from entering your MDM world, which is the best approach, then you have to apply data matching capabilities. When identifying a duplicate you must be able to intelligently merge any conflicting views into a golden record.

In lesser degree we see the same challenges in getting a single view of suppliers and, which is one of my favourite subjects, you ultimately will want to have a single view on any business partner, also where the same real world entity have both customer, supplier and other roles to your organization.

Location Golden Records

Having the same location only represented once in a golden record and applying any party, product and asset record, and ultimately golden record, to that record may be seen as quite academic. Nevertheless, striving for that concept will solve many data quality conundrums.

GoldLocation management have different meanings and importance for different industries. One example is that a brewery makes business with the legal entity (party) that owns a bar, café, restaurant. However, even though the owner of that place changes, which happens a lot, the brewery is still interested in being the brand served at that place. Also, the brewery wants to keep records of logistics around that place and the historic volumes delivered to that place. Utility and insurance is other examples of industries where the location golden record (should) matter a lot.

Knowing the properties of a location also supports the party deduplication process. For example, if you have two records with the name “John Smith” on the same address, the probability of that being the same real world entity is dependent on whether that location is a single-family house or a nursing home.

Product Golden Record

Product Information Management (PIM) solutions became popular with the raise of multi-channel where having the same representation of a product in offline and online channels is essential. The self-service approach in online sales also drew the requirements of managing a lot more product attributes than seen before, which again points to a solution of handling the product entity centralized.

In large organizations that have many business units around the world you struggle with having a local view and a global view of products. A given product may be a finished product to one unit but a raw material to another unit. Even a global SAP rollout will usually not clarify this – rather the contrary.

GoldWhile third party reference data helps a lot with handling golden records for party and location, this is lesser the case for product master data. Classification systems and data pools do exist, but will certainly not take you all the way. With product master data we must, in my eyes, rely more on second party master data meaning sharing product master data within the business ecosystems where you are present.

Asset (or Thing) Golden Records

In asset master data management you also have different purposes where having a single view of a real world asset helps a lot. There are namely financial purposes and logistic purposes that have to aligned, but also a lot of others purposes depending on the industry and the type of asset.

With the raise of the Internet of Things (IoT) we will have to manage a lot more assets (or things) than we usually have considered. When a thing (a machine, a vehicle, an appliance) becomes intelligent and now produces big data, master data management and indeed multi-domain master data management becomes imperative.

You will want to know a lot about the product model of the thing in order to make sense of the produced big data. For that, you need the product (model) golden record. You will want to have deep knowledge of the location in time of the thing. You cannot do that without the location golden records. You will want to know the different party roles in time related to the thing. The owner, the operator, the maintainer. If you want to avoid chaos, you need party golden records.