B2B

What MDMographic Stereotype is Your Organization?

Henrik Gabs LiliendahlLeave a comment

In marketing we use the term demographic stereotype for segmenting individual persons according to known data elements as age and where we live. There is also a lesser used term called firmographic stereotypes, where companies are segmented according to industry sector, size and other data elements.

Solutions for Master Data Management (MDM) and related disciplines are often presented by industry sector. In my work with tool selection – either as a thorough engagement or a quick select your solution report – I have identified some MDMographic stereotypes, where we have the same requirements based on the distribution of party (customer and supplier/vendor) entities and product entities:

MDMographic Stereotypes and Venn

These stereotypes are further explained in the post Six MDMographic Stereotypes.

Real-World Multidomain MDM Entities

Henrik Gabs LiliendahlLeave a comment

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).

Multidomain MDM

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.

B2C vs B2B in Product Information Management

Henrik Gabs Liliendahl4 Comments

The difference between doing Business-to-Consumer (B2C) or Business-to-Business (B2B) reflects itself in many IT enabled disciplines.

Yin and yangWhen 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.

Party Master Data and the Data Subject

Henrik Gabs LiliendahlLeave a comment

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?

Henrik Gabs Liliendahl4 Comments

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

Henrik Gabs LiliendahlLeave a comment

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

Henrik Gabs LiliendahlLeave a comment

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?

Henrik Gabs Liliendahl3 Comments

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

Henrik Gabs LiliendahlLeave a comment

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

Henrik Gabs Liliendahl3 Comments

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