Master Data

PIM Supplier Portals: Are They Good or Bad?

Henrik Gabs Liliendahl13 Comments

A recent discussion on the LinkedIn Multi-Domain MDM group is about vendor / supplier portals as a part of Product Information Management implementations.

A supplier portal (or vendor portal if you like) is usually an extension to a Product Information Management (PIM) solution. The idea is that the suppliers of products, and thus providers of product information, to you as a downstream participant (distributor or retailer) in a supply chain, can upload their product information into your PIM solution and thus relieving you of doing that. This process usually replace the work of receiving spreadsheets from suppliers in the many situations where data pools are not relevant.

In my opinion and experience, this is a flawed concept, because it is hostile to the supplier. The supplier will have hundreds of downstream receivers of products and thus product information. If all of them introduced their own supplier portal, they will have to learn and maintain hundreds of them. Only if you are bigger than your supplier is and is a substantial part of their business, they will go with you.

Broken data supply chainAnother concept, which is the opposite, is also emerging. This is manufacturers and upstream distributors establishing PIM customer portals, where suppliers can fetch product information. This concept is in my eyes flawed exactly the opposite way.

And then let us imagine that every provider of product information had their PIM customer portal and every receiver had their PIM supplier portal. Then no data would flow at all.

What is your opinion and experience?

What Will you Complicate in the Year of the Rooster?

Henrik Gabs Liliendahl1 Comment

rooster-6Today is the first day in the new year. The year of the rooster according to the Lunar Calendar observed in East Asia. One of the characteristics of the year of the rooster is that in this year, people will tend to complicate things.

People usually likes to keep things simple. The KISS principle – Keep It Simple, Stupid – has many fans. But not me. Not that I do not like to keep things simple. I do. But only as simple as it should be as Einstein probably said. Sometimes KISS is the shortcut to getting it all wrong.

When working with data quality I have come across the three below examples of striking the right balance in making things a bit complicated and not too simple:

Deduplication

One of the most frequent data quality issues around is duplicates in party master data. Customer, supplier, patient, citizen, member and many other roles of legal entities and natural persons, where the real world entity are described more than once with different values in our databases.

In solving this challenge, we can use methods as match codes and edit distance to detect duplicates. However, these methods, often called deterministic, are far too simple to really automate the remedy. We can also use advanced probabilistic methods. These methods are better, but have the downside that the matching done is hard to explain, repeat and reuse in other contexts.

My best experience is to use something in between these approaches. Not too simple and not too overcomplicated.

Address verification

You can make a good algorithm to perform verification of postal and visit addresses in a database for addresses coming from one country. However, if you try the same algorithm on addresses from another country, it often fails miserably.

Making an algorithm for addresses from all over the world will be very complicated. I have not seen one yet, that works.

My best experience is to accept the complication of having almost as many algorithms as there are countries on this planet.

Product classification

Classifications of products controls a lot of the data quality dimensions related to product master data. The most prominent example is completeness of product information. Whether you have complete product information is dependent on the classification of the product. Some attributes will be mandatory for one product but make no sense at all to another product by a different classification.

If your product classification is too simple, your completeness measurement will not be realistic. A too granular or other way complicated classification system is very hard to maintain and will probably seem as an overkill for many purposes of product master data management.

My best experience is that you have to maintain several classification systems and have a linking between them, both inside your organization and between your trading partners.

Happy New Lunar Year

IT is not the opposite of the business, but a part of it

Henrik Gabs LiliendahlLeave a comment

Yin and yangDuring my professional work and not at least when following the data management talk on social media I often stumble upon sayings as:

  • IT should not drive a CRM / MDM / PIM /  XXX project. The business should do that.
  • IT should not be responsible for data quality. The business should be that.

I disagree with that. Not that the business should not do and be those things. But because IT should be a part of the business.

I have personally always disliked the concept of dividing a company into IT and the business. It is a concept practically only used by the IT (and IT focused consulting) side. In my eyes, IT is part of the business just as much as marketing, sales, accounting and all the other departmental units.

With the raise of digitalization the distinction between IT and the business becomes absolutely ridiculous – not to say dangerous.

We need business minded IT people and IT savvy business people to drive digitilization and take responsibility of data quality.

Used abbreviations:

  • IT = Information Technology
  • CRM = Customer Relationship Management
  • MDM = Master Data Management
  • PIM = Product Information Management

Party and Product: The Core Entities in Most Data Models

Henrik Gabs LiliendahlLeave a comment

Party and product are the most frequent master data domains around.

Often you meet party as one of the most frequent party roles being customer and supplier (or vendor) or by another term related to the context as for example citizen, patient, member, student, passenger and many more. These are the people and legal entities we are interacting with and with whom we usually exchange money – and information.

Product (or material) is the things we buy, make and sell. The goods (or services) we exchange.

In my current venture called Product Data Lake our aim to serve the exchange of information about products between trading partners who are customers and suppliers in business ecosystems.

For that, we have been building a data model. Below you see our first developed conceptual data model, which has party and product as the core entities.

PDL concept model.png

As this is a service for business ecosystems, another important entity is the partnership between suppliers and customers of products and the information about the products.

The product link entity in this data model is handling the identification of products by the pairs of trading partners. In the same way, this data model has link entities between the identification of product attributes at pair of trading partners (build on same standards or not) as well as digital asset types.

If you are offering product information management services, at thus being a potential Product Data Lake ambassador, or you are part of a business ecosystem with trading partners, I will be happy to discus with you about adding handling of trading partnerships and product information exchange to your current model.

← Back

Thank you for your response. ✨

 

Who will become Future Leaders in the Gartner Multidomain MDM Magic Quadrant?

Henrik Gabs Liliendahl10 Comments

Gartner emphasizes that the new Magic Quadrant for Master Data Management Solutions Published 19 January 2017 is not solely about multidomain MDM or a consolidation of the two retired MDM quadrants for customer and product master data. However, a long way down the report it still is.

If you want a free copy both Informatica here and Riversand here offers that.

The Current Pole Position and the Pack

The possible positioning was the subject in a post here on the blog some while ago. This post was called The Gartner Magic Quadrant for MDM 2016. The term 2016 has though been omitted in the title of the final quadrant probably because it took into 2017 to finalize the report as reported in the post Gartner MDM Magic Quadrant in Overtime.

Below is my look at the positioning in the current quadrant:

mdm-mq

Starting with the multidomain MDM point the two current leaders, Informatica and Orchestra, have made their way to multidomain in two different ways. Pole position vendor Informatica has used mergers and acquisitions with the old Siperian MDM solution and the Heiler PIM (Product Information Management) solution to build the multidomain MDM leadership. Orchestra Networks has built a multidomain MDM solution from the gound.

The visionary Riversand is coming in from the Product MDM / PIM world as a multidomain MDM wannabe and so is the challenger Stibo. I think SAP is in their right place: Enormous ability to execute with not so much vision.

If you go through the strengths and cautions of the various vendors, you will find a lot of multidomain MDM views from Gartner.

The Future Race

While the edges of the challengers and visionaries’ quadrants are usually empty in a Gartner magic quadrant, the top right in this first multidomain MDM quadrant from Gartner is noticeably empty too. So who will we see there in the future?

Gartner mentions some interesting upcoming vendors earning too little yet. Examples are Agility Multichannel (a Product Data Lake ambassador by the way), Semarchy and Reltio.

The future race track will according to Gartner go through:

  • MDM and the Cloud
  • MDM and the Internet of Things
  • MDM and Big Data

PS: At Product Data Lake we are heading there in full speed too. Therefore, it will be a win-win to see more MDM vendors joining as ambassadors or even being more involved.

MDM: The Technology Trends

Henrik Gabs LiliendahlLeave a comment

There are certainly many things going on in the Master Data Management (MDM) realm when it comes to technologies applied.

The move from on premise based solutions to cloud based solutions has been visible for some years. It is not a rush yet, but we see more and more master data services being offered as cloud services as well as many vendors of full stack MDM platforms offers both on premise, cloud and even hybrid solutions.

As reported in the post Emerging Database Technologies for Master Data new underlying database technologies are put in place instead of the relational database solutions that until now have ruled the MDM world. As mentioned graph databases as Neo4J and document databases as MongoDB (which now also support graph) are examples of new popular choices.

blockchainAs examined by Gartner (the analyst Firm) there are Two Ways of Exploiting Big Data with MDM, either doing it directly or by linking. Anyway, the ties between big data and master data management is in my eyes going to be a main focus for the technology trends in the years to come. Other important ties includes the raise of Industry 4.0 / Internet of Things and blockchain approaches.

We are still waiting for The Gartner Magic Quadrant for Master Data Management Solutions 2016 and the related Critical Capabilities document, so it will be very exciting, in fact more exciting that the vendor positioning, to learn about how Gartner sees the technology trends affecting the MDM landscape.

What are your expectations about Master Data Management and new emerging technologies?

Gartner MDM Magic Quadrant in Overtime

Henrik Gabs Liliendahl1 Comment

The Gartner Master Data Management Solutions Magic Quadrant 2016 did not go live in 2016. Estimated release date was 19th November 2016, but still there is no sign of the quadrant either on the Gartner site or at vendor bragging on social media.

We can only guess about why the quadrant is delayed, but a possible explanation is that vendor feedback on the suggested positioning has been harsh. I am not among the ones who believes Gartner actually takes money from vendors for inclusion and positioning in the quadrant. Still, Gartner has a substantial business relationship with those vendors. If a vendor feels they are really wrongly misplaced, they may question the judgement in the other payable services from Gartner.

While waiting, there is still time to have your guess on who has persuaded Gartner to be where in the quadrant as already many have done in the post The Gartner Magic Quadrant for MDM 2016.

And yes, the prize for best guess is still a genuine Product Data Lake t-shirt.

t-shirt

The Intersections of 360 Degree MDM

Henrik Gabs LiliendahlLeave a comment

In the Master Data Management (MDM) realm we have some common notions, being

  • 360 degree Customer Master Data Management, meaning how different views on customers in a company’s various business units and sales channels can be handled as a shared single view.
  • 360 degree Vendor (or Supplier) Master Data Management, meaning how different views on vendors/suppliers in a company’s various business units and supply chains can be handled as a shared single view.
  • 360 degree Product Master Data Management, meaning how different views on products in a company’s various business units, sales channels and supply chains can be handled as a shared single view.

Multi-Side MDM

Multi-Domain Master Data Management (MDM) is the discipline that brings all these views together. Here it is not enough that the same brand of technology is used for all three domains. Handling the intersections is the important part.

The intersection of Vendor/supplier and Customer is known as the Party Master Data domain. My recommendation 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.

The Vendor/supplier and Product Master Data intersection is related to buying products, namely how to on-board data about the vendor/supplier as a party, in the vendor role (financial stuff), the supplier role (logistic stuff) and then on-boarding his product information. My recommendation for on-boarding product information from suppliers being manufacturers is to make this a Win-Win solution for both parties as described in the post How a PLM-2-PIM Solution Becomes a WIN-WIN Solution.

The Customer and Product Master Data intersection is about supporting how you sell products. The term omnichannel is popular for that these days. Again, Product Information Management (PIM) plays a crucial role here and my recommendations for that is expressed in the post Adding Business Ecosystems to Omnichannel.

Cross Border Master Data Management

Henrik Gabs Liliendahl8 Comments

One of the most intriguing sides of data quality and Master Data Management (MDM) is, in my eyes, how you can extend a national solution to an international solution.

Google EarthMany implementations starts with a national scope and we also see many tools and services built for a national scope. Success on a national scale does unfortunately not always guarantee success on an international scale.

Besides all the important stuff around different culture challenges and how to drive change management in an international environment, there are also some things about the master data itself that are challenging.

  • Location Master Data is probably the most obvious domain where we face issues when going international. Postal addresses are formatted differently around the world. Approximately half of the world puts the house number in front of the street name, approximately half of the world puts the house number after the street name and then in some places you don’t use house numbers on a street, but in blocks. City and postal code has the same issue. The worst solutions here tries to put the rest of the world into the first implemented national solution as told in the post Nationally International.
  • Party Master Data, also when looking beyond postal addresses, must encompass many national constraints and opportunities, not at least when it comes to exploiting third party data:
    • Utilizing business directories is one common way. Here you have to balance the use of many different best of breed national providers or taking it from a more harmonized provider of an international directory. Where I (also) work right now, we have chosen the latter solution as reported in the post Using a Business Entity Identifier from Day One.
    • If you, as I am, are coming from Scandinavia you are also amazed by the difficulties around the world there are in healthcare, elections and other areas when there is no public available national identifier for citizens as examined in the post Counting Citizens.
  • Product Master Data does in many ways look the same across countries. However, standards for product data often still are specific to a single or a specific range of countries. Also, if the national implementation was not in a country with multiple languages and the international scope includes more languages, you must encompass multilingual capacities for product information management.

What have you experienced when going from national to international?

My 2017 PIM Clairvoyance

Henrik Gabs LiliendahlLeave a comment

When writing a blog post about predictions for next year a common way to start is to explain why your last year predictions in a way was true.

Well, my foreseeing for 2016 was called My 2016 MDM Clairvoyance. This included gut feelings about Master Data Management (MDM) including Product Information Management (PIM).

One hunch was about mergers. There is still two weeks left to see that coming true.

Bowl
Magic glass bowl

Another guess was about shortage of MDM people and more agile MDM implementations. Perhaps that was right.

The bet that certainly happened was about only one Gartner MDM magic quadrant. Though it is delayed – as reported in the post The Gartner Magic Quadrant for MDM 2016 – it will according to my sources land in 2016.

The burning issue for me in 2017 is how many companies that will abandon spreadsheets as the mean to exchange product information with trading partners and resist the temptation to set up a selfish supplier or customer product data portal? The potential numbers was examined in the post Alternatives to Product Data Lake.

Or put in another way: How many subscribers will we have at Product Data Lake by the end of 2017? My guess is 1111. In a year I will reveal if this number is expressed as a binary number, a decimal number or a hex number.