Do we need better business decisions about MDM?

In an Information Management article today Aaron Zornes, president of the MDM Institute, writes about that Master Data Management (MDM is) driving better business decisions.

In here Aaron says: “Many of the MDM programs we see are increasingly tactical rather than enterprise in nature. That is, organizations are more likely to fund MDM programs to solve a specific business problem than a wide range of business problems”.

MDMDG 2013 wordleWhile I agree with the observation and have been involved in making exactly such business cases, it stills puzzles me that this is quite a contradiction to the idea behind MDM, which is to consolidate master data across the enterprise.

What do you think? Do tactical MDM implementations cater for better business decisions? Or do we need better business decisions when scoping MDM programs around?

GDPR Data Portability and Master Data Sharing

PortabilityOne of the controversial principles in the upcoming EU GDPR enforcement is the concept of data portability as required in article 20.

In legal lingo data portability means: “Where the data subject has provided the personal data and the processing is based on consent or on a contract, the data subject shall have the right to transmit those personal data and any other information provided by the data subject and retained by an automated processing system, into another one, in an electronic format which is commonly used, without hindrance from the controller from whom the personal data are withdrawn.”

In other words, if you are processing personal data provided by a (prospective) customer or other kind of end user of your products and services, you must be able to hand these data over to your competitor.

I am sure, this is a new way of handling party master data to almost every business. However, sharing master data with your competitor is not new when it comes to product master data as examined in the post Toilet Seats and Data Quality.

Sharing party master data with your competitor will be yet a Sunny Side of GDPR.

Product Data Quality

The data quality tool industry has always had a hard time offering capabilities for solving the data quality issues that relates to product data.

Customer data quality issues has always been the challenges addressed as examined in the post The Future of Data Quality Tools, where the current positioning from the analyst firm Information Difference was discussed. The leaders as Experian Data Quality, Informatica and Trillium (now part of Syncsort) always promote their data quality tools with use cases around customer data.

Back some years Oracle did have a go for product data quality with their Silver Creek Systems acquisition as mentioned by Andrew White of Gartner in this post. The approach from Silver Creek to product data quality can be seen in this MIT Information Quality Industry Symposium presentation from the year before. However, today Oracle is not even present in the industry report mentioned above.

Multi-Domain MDM and Data Quality DimensionsWhile data quality as a discipline with the methodology and surrounding data governance may be very similar between customer data and product data, the capabilities needed for tools supporting data cleansing, data quality improvement and prevention of data quality issues are somewhat different.

Data profiling is different, as it must be very tightly connected to product classification. Deduplication is useful, but far from in same degree as with customer data. Data enrichment must be much more related to second party data than third party data, which is most useful for customer and other party master data.

Regular readers of this blog will know, that my suggestion for data quality tool vendors is to join Product Data Lake.

MDM / PIM Platform Vendors Need to Grow Up Too

Participating in digital ecosystems is the way forward for enterprises who wants to be tomorrow’s winners through digital transformation.

Some figures from Gartner, the analyst firm, tells this about digital transformation:

  • 79% of top performing companies indicate that they participate in a digital ecosystem
  • 49% of typical companies indicate the same
  • 24% of trailing companies does it

These figures were lately examined by Bryan Kirschner of Apigee (now part of Google) in a Cio.com article called Ecosystems: when digital transformation grows up.

Master Data Share
Master Data Share for Business Ecosystems

As a Master Data Management (MDM) and/or Product Information Management (PIM) platform vendor you should support your current and prospective clients with means to participate in digital ecosystems.

Current offerings from MDM and PIM platforms vendors have become quite mature in supporting inhouse (enterprise wide) handling of master data and product information. Next step is supporting sharing within business ecosystems. A concept for that is introduced in Master Data Share.

The Sunny Side of GDPR

Happy SunDon’t panic about GDPR. Don’t neglect either. Be happy.

Recently Ditte Brix Andersen of Stibo Systems wrote a blog post called Preparing for GDPR – Burden or Opportunity?

As Ditte writes, the core implication of GDPR is: “Up until now, businesses have traditionally ‘owned’ the personal data of their customers, employees and other individuals. But from May 25th, 2018 individuals will be given several new personal data rights, putting the ownership right back in to the hands of each individual”.

I agree with Ditte that the GDPR coming into force can be seen as an opportunity for businesses instead of a burden. Adhering to GDPR will urge you to:

  • Have a clear picture about where you store personal data. This is not bad for business too.
  • Express a common understood idea about why you store personal data. Also very good for business.
  • Know who can access and update personal data. A basic need for risk handling in your business.
  • Document what kind of personal data you handle. Equally makes sense for doing your business.
  • Think through how you obtain consent to handle personal data. Makes your business look smart as well.

In fact, after applying these good habits to personal data you should continue with other kind of party master data and all other kinds of master data. The days of trying to keep your own little secret, even partly to yourself, versions of what seems to be the truth is over. Start working in the open as exemplified in the concept of Master Data Share.

Country of Origin: An Increasingly Complex Data Element

When you buy stuff one of the characteristics you may emphasis on is where the stuff is made: The country of origin.

Buying domestic goods has always been both a political issue and something that in people’s mind may be an extra quality sign. When I lived in The UK I noticed that meat was promoted as British (maybe except from Danish bacon). Now when back in Denmark all meat seems to be best when made in Denmark (maybe except from an Argentinian beef). However, regulations have already affected the made in marking for meat, so you have to state several countries of origins in the product lifecycle.

Luxury shoes
Luxury shoes of multi-cultural origin

For some goods a given country of origin seems to be a quality sign. With luxury goods as fine shoes you can still get away with stating Italy or France as country of origin while most of the work has been made elsewhere as told in this article from The Guardian that Revealed: the Romanian site where Louis Vuitton makes its Italian shoes.

Country of origin is a product data element that you need to handle for regulatory reasons not at least when moving goods across borders. Here it is connected with commodity codes telling what kind of product it is in the custom way of classifying products as examined in the post Five Product Classification Standards.

When working with product data management for products that moves cross border you are increasingly asked to be more specific about the country of origin. For example, if you have a product consisting of several parts, you must specify the country of origin for each part.

Obstacles to Product Information Sharing

In a recent poll on this blog we had this question about how to share product information with trading partners:

As a manufacturer: What is Your Toughest Product Information Sharing Issue?

The result turned out as seen below:

Survey final

Product information flow in supply chains will typically start with that manufacturers shares the detailed hard facts about products to the benefit of downstream partners as examined in the post Using Internal and External Product Information to Win.

This survey points to that the main reason why this does that take place is that manufacturers need to mature in handling and consolidating product information internally, before they are confident in sharing the detailed data elements (in an automated way) with their downstream partners. This subject was elaborated in the post Product Information Sharing Issue No 1: We Need to Mature Internally.

Another obstacle is the lack of a common standard for product information in the business ecosystem where the manufacturer is a part as further examined in the post Product Information Sharing Issue No 2: No Viable Standard.

Issue no 3 is the apparent absence of a good solution for sharing product information with trading partners that suites the whole business ecosystem. I guess it is needless to say to regular readers of this blog that, besides being able to support issue no 1 and issue no 2, that solution is Product Data Lake.

The Problem with English

– and many other languages

This blog is in English. However, as a citizen in a country where English is not the first language, I have a problem with English. Which flavour or flavor of English should I use? US English? British English? Or any of the many other kinds of English?

It is, in that context, more a theoretical question than a practical one. Despite what Grammar Nazis might think, I guess everyone understands the meaning in my blend of English variants and occasional other spelling mistakes.

The variants of English, spiced up with other cultural and administrative differences, does however create real data quality issues as told in the post Cultured Freshwater Pearls of Wisdom.

EnglishWhen working with Product Data Lake, a service for sharing product information between trading partners, we also need to embrace languages. In doing that we cannot just pick English. We must make it possible to pick any combination of English and country where English is (one of) the official language(s). The same goes for Spanish, German, French, Portuguese, Russian and many other languages in the extend that products can be named and described with different spelling (in a given alphabet or script type).

You always must choose between standardization or standardisation.

The days of castle and moat are over, just as brick and mortar is slowly diminishing too

A recent post called Ecosystem Architecture is replacing Enterprise Architecture from Oliver Cronk of Deloitte has these statements:

Kronborg_Castle“Organisations need architectural thinking beyond their organisational boundaries” and “The days of Enterprise Architecture taking a castle and moat approach are over”.

The end of the castle and moat thinking in Enterprise Architecture (and Business Information Architecture) is also closely related to the diminished importance of the brick and mortar ways of selling, being increasingly overtaken by eCommerce.

However, some figures I have noticed that cause the brick and mortar way to resist the decline by still having a castle and moat thinking is:

Merchants, distributors and manufacturers need to move on from the castle and moat thinking in Enterprise Architecture and Business Information Architecture and start interacting effectively in their business ecosystems with product information.

This is the thinking behind Product Data Lake. You can keep your castle by breaking down the walls and replace the moat with a stream as shown in our 5 + 5 Business Benefits.

Master Data or Shared Data or Critical Data or What?

What is master data and what is Master Data Management (MDM) is a recurring subject on this blog as well as the question about if we need the term master data and the concept of MDM. Recently I read two interesting articles on this subject.

Andrew White of Gartner wrote the post Don’t You Need to Understand Your Business Information Architecture?

In here, Andrew mentions this segmentation of data:

  • Master data – widely referenced, widely shared across core business processes, defined initially and only from a business perspective
  • Shared application data – less widely but still shared data, between several business systems, that links to master data
  • Local application data – not shared at all outside the boundary of the application in mind, that links to shared application and master data

Teemu Laakso of Kone Corporation has just changed his title from Head of Master Data Management to Head of Data Design and published an article called Master Data Management vs. Data Design?

In here, Teemu asks?

What’s wrong in the MDM angle? Well, it does not make any business process to work and therefore doesn’t create a direct business case. What if we removed the academic borderline between Master Data and other Business Critical data?

The shared sentiment, as I read it, between the two pieces is that you should design your “business information architecture” and the surrounding information governance so that “Data Design Equals Business Design”.

My take is that you must look from one level up to get the full picture. That will be considering how your business information architecture fits into the business ecosystem where your enterprise is a part, and thereby have the same master data, shares the same critical data and then operates your own data that links to the shared critical data and business ecosystem wide master data.

Master Data or