Party Master Data and the Data Subject

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

Data Subjects

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.

What is in a business directory?

When working with Party Master Data Management one approach to ensure accuracy, completeness and other data quality dimensions is to onboard new business-to-business (B2B) entities and enrich such current entities via a business directory.

While this could seem to be a straight forward mechanism, unfortunately it usually is not that easy peasy.

Let us take an example featuring the most widely used business directory around the world: The Dun & Bradstreet Worldbase. And let us take my latest registered company: Product Data Lake.

PDL at DnB

On this screen showing the basic data elements, there are a few obstacles:

  • The address is not formatted well
  • The country code system is not a widely used one
  • The industry sector code system shown is one among others

Address Formatting

In our address D&B has put the word “sal”, which is Danish for floor. This is not incorrect, but addresses in Denmark are usually not written with that word, as the number following a house number in the addressing standard is the floor.

Country Codes

D&B has their own 3-digit country code. You may convert to the more widely used ISO 2-character country code. I do however remember a lot of fun from my data matching days when dealing with United Kingdom where D&B uses 4 different codes for England, Wales, Scotland and Northern Ireland as well as mapping back and forth with United States and Puerto Rico. Had to be made very despacito.

Industry Sector Codes

The screen shows a SIC code: 7374 = Computer Processing and Data Preparation and Processing Services

This must have been converted from the NACE code by which the company has been registered:  63.11:(00) = Data processing, hosting and related activities.

The two codes do by the way correspond to the NAICS Code 518210 = Data processing, hosting and related activities.

The challenges in embracing the many standards for reference data was examined in the post The World of Reference Data.

Alternatives to Product Data Lake

Within Product Information Management (PIM) there is a growing awareness about that sharing product information between trading partners is a very important issue.

So, how do we do that? We could do that, on a global scale, by using:

  • 1,234,567,890 spreadsheets
  • 2,345,678 customer data portals
  • 901,234 supplier data portals

Spreadsheets is the most common mean to exchange product information between trading partners today. The typical scenario is that a receiver of product information, being a downstream distributor, retailer or large end user, will have a spreadsheet for each product group that is sent to be filled by each supplier each time a new range of products is to be on-boarded (and potentially each time you need a new piece of information). As a provider of product information, being a manufacturer or upstream distributor, you will receive a different spreadsheet to be filled from each trading partner each time you are to deliver a new range of products (and potentially each time they need a new piece of information).

Customer data portals is a concept a provider of product information may have, plan to have or dream about. The idea is that each downstream trading partner can go to your customer data portal, structured in your way and format, when they need product information from you. Your trading partner will then only have to deal with your customer data portal – and the 1,234 other customer data portals in their supplier range.

Supplier data portals is a concept a receiver of product information may have, plan to have or dream about. The idea is that each upstream trading partner can go to your supplier data portal, structured in your way and format, when they have to deliver product information to you. Your trading partner will then only have to deal with your supplier data portal – and the 567 other supplier data portals in their business-to-business customer range.

Product Data Lake is the sound alternative to the above options. Hailstorms of spreadsheets does not work. If everyone has either a passive customer data portal or a passive supplier data portal, no one will exchange anything. The solution is that you as a provider of product information will push your data in your structure and format into Product Data Lake each time you have a new product or a new piece of product information. As a receiver you will set up pull requests, that will give you data in your structure and format each time you have a new range of products, need a new piece of information or each time your trading partner has a new piece of information.

Learn more about how that works in Product Data Lake Documentation and Data Governance.

alternatives
Potential number of solutions / degree of dissatisfaction / total cost of ownership

 

A System of Engagement for Business Ecosystems

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.

pdl-whyOne 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.

Social Selling: Does it Work?

Social Master Data Management (Social MDM) has been on my radar for quite a long time. Social MDM is the natural consequence of Social CRM and social selling.

Social MDMNow social selling has become very close to me in the endeavour of putting a B2B (Business-to-Business) cloud service called Product Data Lake on the market.

In our quest to do that we rely on social selling for the following reasons:

  • If we do not think too much about, that time is money, social selling is an inexpensive substitution for a traditional salesforce, not at least when we are targeting a global market.
  • We have a subscription model with a very low entry level, which really does not justify many onsite meetings outside downtown Copenhagen – but we do online meetings based on social engagement though 🙂
  • The Product Data Lake resembles a social network itself by relying on trading partnerships for exchange of product information.

I will be keen to know about your experiences and opinions about social selling. Does it work? Does it pay off to sell socially? Does it feel good to buy socially?

Bookmark and Share

Using a Business Entity Identifier from Day One

One of the ways to ensure data quality for customer – or rather party – master data when operating in a business-to-business (B2B) environment, is to on-board new entries using an external defined business entity identifier.

By doing that, you tackle some of the most challenging data quality dimensions as:

  • Uniqueness, by checking if a business with that identifier already exist in your internal master data. This approach is superior to using data matching as explained in the post The Good, Better and Best Way of Avoiding Duplicates.
  • Accuracy, by having names, addresses and other information defaulted from a business directory and thus avoiding those spelling mistakes that usually are all over in party master data.
  • Conformity, by inheriting additional data as line-of-business codes and descriptions from a business directory.

Having an external business identifier stored with your party master data helps a lot with maintaining data quality as pondered in the post Ongoing Data Maintenance.

Busienss Entity IdentifiersWhen selecting an identifier there are different options as national IDs, LEI, DUNS Number and others as explained in the post Business Entity Identifiers.

At the Product Data Lake service I am working on right now, we have decided to use an external business identifier from day one. I know this may be something a typical start-up will consider much later if and when the party master data population has grown. But, besides being optimistic about our service, I think it will be a win not to have to fight data quality issues later with guarantied increased costs.

For the identifier to use we have chosen the DUNS Number from Dun & Bradstreet. The reason is that this currently is the only worldwide covered business identifier. Also, Dun & Bradstreet offers some additional data that fits our business model. This includes consistent line-of-business information and worldwide company family trees.

Bookmark and Share

Multi-Side MDM

As reported in the post Gravitational Waves in the MDM World there is a tendency in the MDM (Master Data Management) market and in MDM programmes around to encompass both the party domain and the product domain.

The party domain is still often treated as two separate domains, being the vendor (or supplier) domain and the customer domain. However, there are good reasons for seeing the intersection of vendor master data and customer master data as party master data. These reasons are most obvious when we look at the B2B (business-to-business) part of our master data, because:

  • You will always find that many real world entities have a vendor role as well as a customer role to you
  • The basic master data has the same structure (identification, names, addresses and contact data
  • You need the same third party validation and enrichment capabilities for customer roles and vendor roles.

These reasons also applies to other party roles as examined in the post 360° Business Partner View.

When we look at the product domain we also have a huge need to connect the buy side and the sell side of our business – and the make side for that matter where we have in-house production.

Multi-Side MDM

Multi-Domain MDM has a side effect, so to speak, about bringing the sell-side together with the buy- and make-side. PIM (Product Information Management), which we often see as the ancestor to product MDM, has the same challenge. Here we also need to bring the sell-side and and the buy-side together – on three frontiers:

  • Bringing the internal buy-side and sell-side together not at least when looking at product hierarchies
  • Bringing our buy-side in synchronization with our upstream vendors/suppliers sell-side when it comes to product data
  • Bringing our sell-side in synchronization with our downstream customers buy-side when it comes to product data

Bookmark and Share

The World of Reference Data

Google EarthReference Data Management (RDM) is an evolving discipline within data management. When organizations mature in the reference data management realm we often see a shift from relying on internally defined reference data to relying on externally defined reference data. This is based on the good old saying of not to reinvent the wheel and also that externally defined reference data usually are better in fulfilling multiple purposes of use, where internally defined reference data tend to only cater for the most important purpose of use within your organization.

Then, what standard to use tend to be a matter of where in the world you are. Let’s look at three examples from the location domain, the party domain and the product domain.

Location reference data

If you read articles in English about reference data and ensuring accuracy and other data quality dimensions for location data you often meet remarks as “be sure to check validity against US Postal Services” or “make sure to check against the Royal Mail PAF File”. This is all great if all your addresses are in the United States or the United Kingdom. If all your addresses are in another country, there will in many cases be similar services for the given country. If your address are spread around the world, you have to look further.

There are some Data-as-a-Service offerings for international addresses out there. When it comes to have your own copy of location reference data the Universal Postal Union has an offering called the Universal POST*CODE® DataBase. You may also look into open data solutions as GeoNames.

Party reference data

Within party master data management for Business-to-Business (B2B) activities you want to classify your customers, prospects, suppliers and other business partners according to what they do, For that there are some frequently used coding systems in areas where I have been:

  • Standard Industrial Classification (SIC) codes, the four-digit numerical codes assigned by the U.S. government to business establishments.
  • The North American Industry Classification System (NAICS).
  • NACE (Nomenclature of Economic Activities), the European statistical classification of economic activities.

As important economic activities change over time, these systems change to reflect the real world. As an example, my Danish company registration has changed NACE code three times since 1998 while I have been doing the same thing.

This doesn’t make conversion services between these systems more easy.

Product reference data

There are also a good choice of standardized and standardised classification systems for product data out there. To name a few:

  • TheUnited Nations Standard Products and Services Code® (UNSPSC®), managed by GS1 US™ for the UN Development Programme (UNDP).
  • eCl@ss, who presents themselves as: “THE cross-industry product data standard for classification and clear description of products and services that has established itself as the only ISO/IEC compliant industry standard nationally and internationally”. eCl@ss has its main support in Germany (the home of the Mercedes E-Class).

In addition to cross-industry standards there are heaps of industry specific international, regional and national standards for product classification.

Bookmark and Share

Making a Firmographic Analysis

What demographics are to people, firmographics are to organizations.

I am currently working with starting up a Business-to-Business (B2B) service. In order to assess the market I had to know something about how many companies there are out there who possibly could be in need of such a service.

The service will work word-wide, but adhering to the sayings about thinking globally/big and starting locally/small I have started with assessing the Danish market. Also there are easy and none expensive access to business directories for Denmark.

My first filter was selecting companies with at least 50 employees.

As the service is suitable for companies within ecosystems of manufacturers, distributors and retailers, I selected the equivalent range of industry codes. In this case it was NACE codes which resembles SIC codes and other classifications of Line-Of-Business used in other geographies.

There were circa 2,500 companies in my selection. However, some belong to the same company family tree. By doing a merge/purge with the largest company in a company family tree as the survivor, the list was down to circa 2,000 companies.

For this particular service, there are some other possibly competing approaches that are stronger for some kinds of goods than other kinds of goods. For that purpose, I made a bespoke categorization being:

  • Priority A: Building materials, furniture, houseware, machinery and vehicles.
  • Priority B: Electronics, books and clothes.
  • Priority C: Pharmaceuticals, food, beverage and tobacco.

Retailers that span several priorities were placed in priority B. Else, for this high level analysis, I only used the primary Line-Of-Business.

The result was as shown below:

Firmographic

So, from my firmographic analysis I know the rough size of the target market in one locality. I can assume, that other markets look more or less the same or I can do specific firmographics on other geographies. Also, I can apply first results of dialogues with entities in the breakdown model and see if the model needs a modification.

Bookmark and Share

Related Parties, Products and Locations

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.

puzzleThere are relationships between entities within the single MDM domains and there are relationships between entities across multiple MDM domains.

Related Parties

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.

Related Products

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.

Multi-Domain Relations

Here we may have:

Bookmark and Share