Your General Data Protection Roadmap

Being ready for the EU GDPR (European Union – General Data Protection Regulation) is – or should be – a topic on the agenda for European businesses and international businesses operating with an European reach.

The finish date is fixed: 25th May 2018. What GDPR is about is well covered (perhaps too overwhelmingly) on the internet. But how do you get there?

Below is my template for a roadmap:

GDPR Readiness RoadmapThe roadmap has as all programs should have an as-is phase, here in concrete as a Privacy Impact Assessment covering what should have been done, if the regulation was already in force. Then comes the phase stating the needed to-be state with the action plan that fills the gaps while absorbing business benefits as well. And then implementation of the prioritized tasks.

GDPR is not only about IT systems, but to be honest, for most companies it will mostly be. Your IT landscape determines which applications will be involved. Most companies will have sales and marketing applications holding personal data. Human Resource Management is a given too. Depending on your business model there will be others. Remember, this is about all kind of personal data – that includes for example supplier contact data that identifies a person too.

The skills needed spans from legal, (Master) Data Management and IT security. You may have these skills internally or you may need interim resources of the above-mentioned kind in order to meet the fixed finish date and being sure things are done right.

By the way: My well skilled associates and I are ready to help. Get in contact:

Where GDPR Still Becomes National

EU GDPRThe upcoming application of the EU General Data Protection Regulation (GDPR) is an attempt to harmonize the data protection and privacy regulations across member states in the European Union.

However, there is room for deviance in ongoing national law enforcement. Probably article 87 concerning processing of the national identification number and article 88 dealing with processing in the context of employment is where we will see national peculiarities.

National identification numbers are today used in different ways across the member states. In The Nordics, the use of an all-purpose identification number that covers identification of citizens from cradle to grave in public (tax, health, social security, election and even transit) as well as private (financial, employment, telco …) registrations have been practiced for many years, where more or less unlinked single purpose (tax, social security, health, election …) identification numbers are the norm most places else.

How you treat the employment force and the derived ways of registering them is also a field of major differences within the Union, and we should therefore expect to be observant of national specialties when it comes to mastering the human resource part of the data domains affected by GDPR.

Do you see other fields where GDPR will become national within the Union?

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.

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.

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

Product Information Sharing Issue No 2: No Viable Standard

A current poll on sharing product information with trading partners running on this blog has this question: As a manufacturer: What is Your Toughest Product Information Sharing Issue?

Some votes in the current standing has gone to this answer:

There is no viable industry standard for our kind of products

Indeed, having a standard that all your trading partners use too, will be Utopia.

This is however not the situation for most participants in supply chains. There are many standards out there, but each applicable for a certain group of products, geography or purpose as explained in the post Five Product Classification Standards.

At Product Data Lake we embrace all these standards. If you use the same standard in the same version as your trading partner, linking and transformation is easy. If you do not, you can use Product Data Lake to link and transform from your way to the way your trading partners handles product information. Learn more at Product Data Lake Documentation and Data Governance.

Attribute Types
The tagging scheme used in Product Data Lake attributes (metadata)

Product Information Sharing Issue No 1: We Need to Mature Internally

A current poll on sharing product information with trading partners running on this blog has this question: As a manufacturer: What is Your Toughest Product Information Sharing Issue?

The most votes in the current standing has gone to this answer:

We must first mature in handling our product information internally

PDL MenuSolving this issue is one of the things we do at Liliendahl.com. Besides being an advisory service in the Master Data Management (MDM) and Product Information Management (PIM) space, we have a developing collaboration with companies providing consultancy, cleansing and, when you come to that step, specialized technology for inhouse MDM and PIM. Take a look at Our Business Ecosystem.

If you are a manufacturer with a limited need for scaling the PIM technology part and already have much of your needs covered by an ERP and/or Product Lifecycle Management (PLM) solution, you may also fulfill your inhouse PIM capabilities and the external sharing needs in one go by joining Product Data Lake.

Using Internal and External Product Information to Win

When working with product information I usually put the data into this five level model:

Five levels

The model is explained in the post Five Product Data Levels.

As a downstream participant in supply chains being a distributor or retailer your success is dependent on if you can do better than other businesses (increasingly including marketplaces) of your kind fighting over the same customer prospects. One weapon in doing that is using product information.

Here you must consider where you should use industry wide available data typically coming from the manufacturer and where you should create your own data.

I usually see that companies tend to use industry wide available data in the blue section below:

Internal and external product information

The white area, the internally created data, is:

  • Level 1: Basic product data with your internal identifiers as well as supplier data that reflects your business model
  • Level 5: Competitive data with your better product stories, your unique up-sell and cross-sell opportunities and your choice of convincing advanced digital assets
  • Level 3 in part: Your product description (perhaps in multiple languages) that is consistent with other products you sell and a product image that could be the one provided by the manufacturer or one you shoot yourself.

Obviously, creating internal product data that works better than your competitor is a way to win.

For the blue area, the externally created data, your way of winning is related to how good you are at on-boarding this data from your upstream trading partners being manufacturers and upstream distributors or how good you are in exploiting available product data pools and industry specific product data portals.

In doing that, connect is better than collect. You can connect by using Product Data Pull.