In Master Data Management (MDM) we strive to describe the core entities that are essential to running a business. Most of these entities are something that exists in the real-world. We can organize these entities in various groups as for example parties, things and locations or by their relation to the business buy-side, sell-side and make-side (production).
The challenge in MDM is, as in life in general, that we use the same term for different concepts and different terms for the same concept.
Here are some of the classic issues:
- An employee is someone who works within an organization. Sometimes this term must be equal to someone who is on the payroll. But sometimes it is also someone who works besides people on the payroll but is contracting and therefore is more like a vendor. Sometimes employees buy stuff from the organization and therefore acts as a customer.
- Is it called vendor or supplier? The common perception is that a vendor brings the invoice and the supplier brings the goods and/or services. This is often the same legal entity but not too seldom two different legal entities.
- What is a customer? There are numerous challenges in this question. It is about when a party starts being a customer and when the relationship ends. It is about whether it is a direct or an indirect customer. And also: Is it a business-to-consumer (B2C) customer, a business-to-business (B2B) or a B2B2C customer?
- Besides employees, vendors and customers (and similar terms) we also care about other parties being business partners. We care about those entities that we must engage with in order to influence our sales. In manufacturing or reselling building materials you for example build relationships with the architects and engineers who choose the materials to be used for a building.
- Traditionally product master data management has revolved around describing a product model which can be produced and sold in many instances over time. With the rise of intelligent things and individually configured complex products, we increasingly must describe each instance of a product as an asset. This adds to the traditional asset domain, where only a few valuable assets have been handled with focus on the financial value.
- Each party and each thing have one and most often several relationships with a geographic location (besides digital locations as for example websites).
The relationships within multi-domain MDM was examined further in the post 3 Old and 3 New Multi-Domain MDM Relationship Types.
The difference between doing Business-to-Consumer (B2C) or Business-to-Business (B2B) reflects itself in many IT enabled disciplines.
When it comes to Product Information Management (PIM) this is true as well. As PIM has become essential with the rise of eCommerce, some of the differences are inherited from the eCommerce discipline. There is a discussion on this in a post on the Shopify blog by Ross Simmonds. The post is called B2B vs B2C Ecommerce: What’s The Difference?
Some significant observations to go into the PIM realm is that for B2B, compared to B2C:
- The audience is (on average) narrower
- The price is (on average) higher
- The decision process is (on average) more thoughtful
How these circumstances affect the difference for PIM was exemplified here on the blog in the post Work Clothes versus Fashion: A Product Information Perspective.
To sum up the differences I would say that some of the technology you need, for example PIM solutions, is basically the same but the data to go into these solutions must be more elaborate and stringent for B2B. This means that for B2B, compared to B2C, you (on average) need:
- More complete and more consistent attributes (specifications, features, properties) for each product and these should be more tailored to each product group.
- More complete and consistent product relations (accessories, replacements, spare parts) for each product.
- More complete and consistent digital assets (images, line drawings, certificates) for each product.
How to achieve that involves deep collaboration in the supply chains of manufacturers, distributors and merchants. The solutions for that was examined in the post The Long Tail of Product Data Synchronization.
Within the upcoming EU General Data Protection Regulation (GDPR) the term data subject is used for the persons for whom we must protect the privacy.
These are the persons we handle as entities within party Master Data Management (MDM).
In the figure below the blue area covers the entity types and roles that are data subjects in the eyes of GDPR
While GDPR is of very high importance in business-to-consumer (B2C) and government-to-citizen (G2C) activities, GDPR is also of importance for business-to-business (B2B) and government-to-business (G2B) activities.
GDPR does not cover unborn persons which may be a fact of interest in very few industries as for example healthcare. When it comes to minors, there are special considerations within GDPR to be aware of. GDPR does not apply to deceased persons. In some industries like financial services and utility, the handling of the estate after the death of a person is essential, as well as knowing about that sad event is of importance in general as touched in the post External Events, MDM and Data Stewardship.
One tough master data challenge in the light of GDPR will be to know the status of your registered party master data entities. This also means knowing when it is a private individual, a contact at an organization or an organization or department hereof as such. From my data matching days, I know that heaps of databases do not hold that clarity as reported in the post So, how about SOHO homes.
Master Data Management (MDM) is increasingly being about supporting systems of engagement in addition to the traditional role of supporting systems of record. This topic was first examined on this blog back in 2012 in the post called Social MDM and Systems of Engagement.
The best known systems of engagement are social networks where the leaders are Facebook for engagement with persons in the private sphere and LinkedIn for engagement with people working in or for one or several companies.
But what about engagement between companies? Though you can argue that all (soft) engagement is neither business-to-consumer (B2C) nor business-to-business (B2B) but human-to-human (H2H), there are some hard engagement going on between companies.
One of the most important ones is exchange of product information between manufacturers, distributors, resellers and large end users of product information. And that is not going very well today. Either it is based on fluffy emailing of spreadsheets or using rigid data pools and portals. So there are definitely room for improvement here.
At Product Data Lake we have introduced a system of engagement for companies when it comes to the crucial task of exchanging product information between trading partners. Read more about that in the post What a PIM-2-PIM Solution Looks Like.
Managing relationships between entities is a very important part of Master Data Management (MDM) as told in the post Another Facet of MDM: Master Relationship Management.
There are relationships between entities within the single MDM domains and there are relationships between entities across multiple MDM domains.
Within customer (or rather party) MDM establishing the relationships between entities heavily increases the value of the data assets. Examples are:
- In B2B (Business-to-Business) environments knowing about company family trees supports both analytic and operational challenges. That knowledge is often provided by enriching data from third party data providers, but as most things in life there is no silver bullet available, as the real world is quite complex and in no way fully covered by any provider I know about.
- In B2C (Business-to-Consumer) environments knowing about how individuals are related in households is key to many analytic and operational issues too. Here having high quality location data is a necessity.
In today’s multi-channel world there is a rush for getting product entities enriched with a myriad of attributes to support customer self-service and thus as a minimum mimicking the knowledge of the traditional sales person in a brick and mortar store.
But we also need to mimic that sales persons knowledge about how products relates. That knowledge can be collected in different ways:
- From the manufacturer of the product. This source is often good when it comes to product relationship types as accessory and replacement (succession).
- From the customer. We know this approach from the online sales trick prompting us with the message “People who bought A also bought B”.
- From internal considerations. Facilitating up-sell can be done by enhancing product data with that kind of product relations.
Here we may have:
Many CRM applications have the concepts of leads, accounts and contacts for registering customers or other parties with roles in sales and customer service.
Most CRM systems have a data model suited for business-to-business (B2B) operations. In a B2B environment:
- A lead is someone who might become your customer some day
- An account is a legal entity who has or seems to become your customer
- A contact is a person that works at or in other ways represent an account
In business-to-consumer (B2C) environments there are different ways of making that model work.
The general perception is that data about a lead can be so and so while it of course is important to have optimal data quality for accounts and contacts.
However, this approach works against the essential data quality rule of getting things right the first time.
Converting a lead into an account and/or a contact is a basic CRM process and the data quality pitfalls in that process are many. To name a few:
- Is the lead a new account or did we already have that account in the database?
- Is the contact new or did we know that person maybe at another account?
- How do we align the known data about the lead with external reference data during the conversion process?
In other words, the promise of having a 360-degree customer view is jeopardized by the concept of most CRM systems.
One of the things that data quality tools does is data matching. Data matching is mostly related to the party master data domain. It is about comparing two or more data records that does not have exactly the same data but are describing the same real world entity.
Common approaches for that is to compare data records in internal master data repositories within your organization. However, there are great advantages in bringing in external reference data sources to support the data matching.
Some of the ways to do that I have worked with includes these kind of big reference data:
The business-to-business (B2B) world does not have privacy issues in the degree we see in the business-to-consumer (B2C) world. Therefore there are many business directories out there with a quite complete picture of which business entities exists in a given country and even in regions and the whole world.
A common approach is to first match your internal B2B records against a business directory and obtain a unique key for each business entity. The next step of matching business entities with that unique is a no brainer.
The problem is though that an automatic match between internal B2B records and a business directory most often does not yield a 100 % hit rate. Not even close as examined in the post 3 out of 10.
Address directories are mostly used in order to standardize postal address data, so that two addresses in internal master data that can be standardized to an address written in exactly the same way can be better matched.
A deeper use of address directories is to exploit related property data. The probability of two records with “John Smith” on the same address being a true positive match is much higher if the address is a single-family house opposite to a high-rise building, nursery home or university campus.
A common cause of false negatives in data matching is that you have compared two records where one of the postal addresses is an old one.
Bringing in National Change of Address (NCOA) services for the countries in question will help a lot.
The optimal way of doing that (and utilizing business and address directories) is to make it a continuous element of Master Data Management (MDM) as explored in the post The Relocation Event.
I stumbled upon an article from yesterday by Bryan Kramer called There is no more B2B or B2C: It’s Human to Human, H2H.
The article is about the implications for marketing caused by the rise of social media which now finally seems to eliminate what we have known as business-to-business (B2B) and more or less merges B2B and business-to-consumer (B2C).
As discussed here on the blog several times starting way back in 2009 in the post Echoes in the Database a problem with B2B indeed is that while business transactions takes place between legal entities a lot of business processes are done between employees related to the selling and buying entities. You may call that employee-to-employee (E2E), people-to-people (P2P) or indeed human-to-human (H2H).
Related to databases, data quality and Master Data Management (MDM) this means we need real world alignment with two kinds of parties:
While B2B and B2C may melt together in the way we do messaging the distinction between B2B and B2C will be there in many other aspects. Even in social media we see it as for example two of the most used social networks being FaceBook and LinkedIn clearly belongs mainly to B2C and B2B respectively for marketing and social selling purposes.
The different possibilities with B2B and B2C in the H2H world was touched in an interview on DataQualityPro last year: What are the Benefits of Social MDM?
A recent blog post called Top 14 Master Data Management Misconceptions by William McKnight has as the last misconception this one:
“14. Third-party data is inappropriate for MDM
Third-party data is largely about extending the profile of important subject areas, which are mastered in MDM. Taking third-party data into organizations has actually kicked off many MDM programs.”
Indeed, using third-party data, which also could be called big external reference data, is in my eyes a very good solution for a lot of use cases. Some of the most popular exploitations today are:
- Using a business directory as big reference data for B2B party master data in customer data integration (CDI) and supplier master data management.
- Using address directories as big reference data for location master data management also related to party master data management for B2C customer data.
- Using product data directories such as the Global data Synchronization Network (GDSN®) services, the UNSPSC® directory and heaps of industry specific product directories.
The next wave of exploiting external data, which is just kicking off as Social MDM, is digging into social media for sharing data, including:
- Using professional social networks as LinkedIn in B2B environments where you often find the most timely reference data not at least about contact data related to your business partners’ accounts.
- Using consumer oriented social networks as Facebook for getting to know your B2C customers better.
- Using social collaboration as a way to achieve better product master data as told in the post Social PIM.
Every time I walk in and out of a plane at London-Gatwick Airport I always nod at an advert from the HSBC bank saying that in the future, selling will be more social:
A natural consequence of this will also be that data quality improvement (and master data management) will be more social.
One example is how complex sales, being sales processes typically in business-to-business (B2B) environments, will be heavily depended on integrating the exploitation of professional social networks as discussed on the DataQualityPro interview about the benefits of Social MDM.
Traditional Master Data Management (MDM) and related data quality improvement in B2B environments has been a lot about a single view of the business account and the legal entity behind. As Social Customer Relation Management (CRM) is much about the relations to the business contacts, the people side of business, we need a solid master data foundation behind the people being those contacts.
The same individual may in fact be an important influencer related to a range of business accounts being the legal entity with who you are aiming for a sales contract. You need a single view of that. So many sales contracts are based on a relation to a buyer moving from one business account to another. You need to be the winner in that game and the answer to that may very well be your ability to do better social MDM and embrace the data quality issues related to that.
Social selling of course also relates to business-to-consumer (B2C) activities and in doing that we will see new data quality issues. When exploiting social networks, both in B2B and B2C activities you need to link the traditional attributes as name and address with new attributes in the online and social world as explained in the post Multi-Channel Data Matching.
Besides exploiting social networks we will also see social collaboration as a mean to improve data quality. Social collaboration will go beyond collaboration within a single company and extend to the ecosystems of manufacturers, distributors, resellers and end users. A good example of this is the social collaboration platform called Actualog, which is about sharing product master data and thereby improving product data quality.