1st Party, 2nd Party and 3rd Party Master Data

Until now, much of the methodology and technology in the Master Data Management (MDM) world has been about how to optimize the use of what can be called first party master data. This is master data already collected within your organization and the approaches to MDM and the MDM solutions offered has revolved around federating internal silos and obtain a single source of truth within the corporate walls.

Besides that third-party data has been around for many years as described in the post Third-Party Data and MDM. Use of third party data in MDM has mainly been about enriching customer and supplier master data from business directories and in some degree utilizing standardized pools of product data in various solutions.

open doorUsing third party data for customer and supplier master data seems to be a very good idea as exemplified in the post Using a Business Entity Identifier from Day One. This is because customer and supplier master looks pretty much the same to every organization. With product master data this is not case and that is why third party sources for product master data may not be fully effective.

Second party data is data you get directly from the external source. With customer and supplier master data we see that approach in self-registration services. My recommendation is to combine self-registration and third party data in customer and supplier on-boarding processes. With product master data I think leaning mostly to second party connections in business ecosystems seems like the best way forward. There is more on that in a discussion on the LinkedIn  MDM – Master Data Management Group.

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

Takeaways from MDM Summit Europe 2016

Yesterday I popped in at the combined Master Data Management Summit Europe 2016 and Data Governance Conference Europe 2016.

This event takes place Monday to Thursday, but unfortunately I only had time and money for the Tuesday this year. Therefore, my report will only be takeaways from Tuesday’s events. On a side note the difficulties in doing something pan-European must have troubled the organisers of this London event as avoiding the UK May bank holidays has ended in starting on a Monday where most of the rest of Europe had a day off due to being Pentecost Monday.

MDM

Tuesday morning’s highlight for me was Henry Peyret of Forrester shocking the audience in his Data Governance keynote by busting the myth about the good old excuse for doing nothing, being the imperative of top-level management support, is not true.

Back in 2013 I wondered if graph databases will become common in MDM. Certainly graph databases has become the talk of the town and it was good to learn from Andreas Weber how the Germany based figurine manufacturer Schleich has made a home grown PIM / Product MDM solution based on graph database technology.

Ivo-Paul Tummers of Jibes presented the MDM (and beyond) roadmap for the Dutch food company Sligro. I liked the alley of embracing multi-channel, then omnichannel with self-service at the end of the road and how connect will overtake collect during this journey. This is exactly the reason of being for the Product Data Lake venture I am working on right now.

Bookmark and Share

Adding Business Ecosystems to Omnichannel

Omichannel has become a buzzword in marketing and beyond. The jury is still out on what omnichannel really is, but most will agree that it is a refinement and/or extension of earlier known buzzwords as multichannel and cross channel. You may learn more in this article.

In omnichannel you will try really, really hard to have a single customer view across all channels, and you will try really, really, really hard to present your product information in a uniform and consistent way across all channels.

One challenge here is that your business is not an island. You are part of a business ecosystem, or several of them, as examined in the post Data Management for Business Ecosystems.

“Your customer” may look at “your product” in the sphere of another member of your business ecosystem. It may be at one of your trading partners or at one of your competitors.

So, what can you do about this when it comes to data management?

In the hard case, your competitors, it is about knowing more about your customer. Knowing about your customers relationships. Knowing about your customers relations with products and their categories. Knowing about your customer’s locational belonging. All in all the case of multidomain MDM as seen in the post Multi-Domain MDM and Data Quality Dimensions.

Omni
Expand digitilization across business ecosystems from single purposes to cover an omnichannel view

Besides your own product information you must register what you know about that product information as it is stored and handled by other members in your business ecosystem – trading partners and competitors.

With product information, you must be able to exchange that with your trading partners. You cannot expect that everyone is handling the information about the same product in exact the same way as you. Actually you should not want that. You want to be better than your competitors in some ways and you want to add value for your trading partners. But you would for sure find value in joining a place of intersection where common known characteristics about products are exchanged between trading partners – such as the Product Data lake.

Bookmark and Share

Kinky Boots and Booths in London

Kinky BootsI am looking forward to visiting London in a fortnight and have already secured tickets for the new musical called Kinky Boots.

Another option is to pop in at the Master Data Management Summit Europe 2016 and the co-located Data Governance Conference Europe 2016 and visit the kinky booths where the exhibitors will tell you about their latest inventions. Someone to see could be:

SemarchySemarchy, who has always been kind of kinky with their evolutionary MDM approach as told in the post Eating the MDM Elephant. Last autumn I visited Semarchy in Lyon and it would be good to catch up with FX,  Richard and other good people from this exciting MDM vendor.

AtaccamaAtaccama has a kinky logo. Also on a recent engagement, we have been working with the data quality analyzer tool from Ataccama. So will be good to learn about all the other stuff as for example the big data analyzer.

Stibo SystemsStibo Systems, where I worked some years ago, has just released their new version 8.0 of STEP Trailblazer. This version has an enhanced web user interface. While STEP has always had lots of good functionality, I think many STEP users will welcome a more kinky user interface.

Bookmark and Share

Multilingual? Mais oui! Natürlich.

Is that piece of data wrong or right? This may very well be a question about in what language we are talking about.

In an earlier double post on this blog I had a small quiz about the name of the Pope in the Catholic church. The point was that all possible answers were right as explained in post When Bad Data Quality isn’t Bad Data. The thing is that the Pope over the wold has local variants over the English name Francis. François in French, Franziskus in German, Francesco in Italian, Francisco in Spanish Franciszek in Polish, Frans in Danish and Norwegian and so on.

In today’s globalized, or should I say globalised, world, it is important that our data can be represented in different languages and that the systems we use to handle the data is built for that. The user interface may be in a certain flavor/flavour of English only, but the data model must cater for storing and presenting data in multiple languages and even variants of languages as English in its many forms. Add to that the capability of handling other characters than Latin in other script systems than alphabets as examined in the post called Script Systems.

This challenge is very close to me right when we are building a service for sharing product information in business ecosystems. So will the Product Data Lake be multilingual? Mais oui! Natürlich. Jo da.

PDL Example

PS: The Product Data Lake will actually help with collecting product information in multiple languages through the supply chains of product manufacturers, distributors, retailers and end users.

Bookmark and Share

Starting up at the age of 56

It is never too late to start up, I have heard. So despite I usually brag about having +35 years of experience in the intersection of business and IT and a huge been done list in Data Quality and Master Data Management (MDM) which can get me nice consultancy engagements, a certain need on the market has been puzzling in my head for some time.

Before that, when someone asked me what to do in the MDM space I told them to create something around sharing master data between organisations. Most MDM solutions are sold to a given organization to cover the internal processes there. There are not many solutions out there that covers what is going on between organizations.

But why not do that myself? – with the help of some younger people.

FirstLogoSaveYou may have noticed, that I during the last year have been writing about something called the Product Data Lake. This has until recently mostly just been a business concept that could be presented on power point slides. So called slideware. But now it is becoming real software being deployed in the cloud.

Right now a gifted team in Vietnam, where I also am this week, is building the solution. We aim to have it ready for the first trial subscribers in August 2016. We will also be exhibiting the solution in London in late September, where we will be at the Start-up Alley in the combined Customer Contact, eCommerce and Technology for Marketing exhibition.

At home in Denmark, some young people are working on our solution too as well as the related launching activities and social media upbeat. This includes a LinkedIn company page. For continuous stories about our start-up, please follow the Product Data Lake page on LinkedIn here.

Bookmark and Share

What is Best Practice: Customer- and Vendor- or Unified Party Master Data Management?

Right now there is a good discussion going on in the Multi-Domain MDM Group on LinkedIn. A member asks:

“I’d like to hear back from anyone who has implemented party master data in either a single, unified schema or separate, individual schemas (Vendor, Customer, etc.).

What were the pros and cons of your approach? Would you do it the same way if you had it to do again?”

Multi-Side MDMThis is a classic consideration at the heart of multi-domain MDM. As I see it, and what I advise my clients to do, is to have a common party (or business partner) structure for identification, names, addresses and contact data. This should be supported by data quality capabilities strongly build on external reference data (third party data). Besides this common structure, there should be specific structures for customer, vendor/supplier and other party roles.

This subject was also recently examined here on the blog in the post Multi-Side MDM.

What is your opinion and experience with this question? Please have your say either here on the blog or in the LinkedIn Multi-Domain MDM Group.

Bookmark and Share

Data Management for Business Ecosystems

Business ecosystems is an important concept of the digital age. The father of business ecosystems, James F. Moore, defined business ecosystems as:

“An economic community supported by a foundation of interacting organizations and individuals—the organisms of the business world. The economic community produces goods and services of value to customers, who are themselves members of the ecosystem. The member organisms also include suppliers, lead producers, competitors, and other stakeholders”.

The problem with data management methodologies and tools today, as I see it, is that they emphasizes on the needs inside the corporate walls of a single company without much attention to, that every single company is a member of one or several business ecosystems as examined in the post called MDM and SCM: Inside and outside the corporate walls.

Opening your data management, including your Master Data Management (MDM), up to the outside is scary business, as the ecosystems often will include your competitors as well as mentioned in the post Toilet Seats and Data Quality.

Nevertheless, if you want your company to survive in the digital age by building up your company’s digitilazation effort you have to extend your data management strategy to encompass the business ecosystems where you are a member.

And now some promotion:

Helene light 03
The Product Data Lake: A tool for business ecosystems

Take A Quick Tour around the Product Data Lake

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