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.

Growing Weight on Business Rules in MDM

Business rules has always been an important subject when it comes to data quality and Master Data Management (MDM). However, it seems that business rules are considered even more important over the recent years and in the future.

Fellow MDM professional Roberto Lichtenstein recently published a LinkedIn pulse post called “MDM and business rules” survey outcome.

One of the survey results was about how the last 3 years behaviour of managing business rules has developed:

MDM and business rules

Two third of people answering the question indicated a growing inclusion of business rules (including yours truly in my current main role). So that’s a good growth. However nearly half of respondents did not answer that question, so a bit of caution may be relevant.

As Roberto mentions in his summary post there is a chicken and egg thing with process and data. I also find there is a chicken and egg theme with business rules and MDM. Letting business rules dictate the MDM behaviour is obvious. But MDM can sometimes initiate new business rules as examined in the post To-Be Business Rules and MDM.

Bookmark and Share

To-Be Business Rules and MDM

checklistAn important part of implementing Master Data Management (MDM) is to capture the business rules that exists within the implementing organization and build those rules into the solution. In addition, and maybe even more important, is the quest of crafting new business rules that helps making master data being of more value to the implementing organization.

Examples of such new business rules that may come along with MDM implementations are:

  • In order to open a business account you must supply a valid Legal Entity Identifier (like Company Registration Number, VAT number or whatever applies to the business and geography in question)
  • A delivery address must be verified against an address directory (valid for the geography in question)
  • In order to bring a product into business there is a minimum requirement for completeness of product information.

Creating new business rules to be part of the to-be master data regime highlights the interdependency of people, process and technology. New technology can often be the driver for taking on board such new business rules. Building on the above examples such possibilities may be:

  • The ability to support real time pick and check of external identifiers
  • The ability to support real time auto completion and check of postal addresses
  • The ability to support complex completeness checks of a range of data elements

Bookmark and Share

Data Governance: Day 2

Much of the talking and writing about data governance these days is about how to start a data governance programme. This includes the roadmap, funding, getting stakeholders interested and that kind of stuff. Focussing on how to get a data governance programme off the ground is natural, as this is the struggle right now in many organizations.

But hopefully when, and not if, the data governance programme has left the ground and is a reality, what does the daily life look like then? I think this drawing can be a good illustration:

Daily Data Governance

The drawing is taken from the Data Governance Institute Framework provided by Gwen Thomas.

As a fan of agile approaches within most disciplines including data governance, it is worth remarking that the daily life should not be seen as an end result of a long implementation. It should certainly be seen as the above concept being upgraded over time in more and more mature versions probably starting with a very basic version addressing main pain points within your organization.

When starting a data governance programme there is typically a lot of existing business rules to be documented in a consistent way. That is one thing. Another thing is to establish the process that deals with data aspects of changing business rules and taking on new business rules as touched in the post Two Kinds of Business Rules within Data Governance.

The ongoing service and the issue resolution part is very much relying on some kind of organizational structure. This could include one of my favourites being collaboration fora between data stewards, maybe a data governance office and usually a data governance council of some name. And perhaps having a Chief Data Officer (CDO) as mentioned in post The Good, the Bad, and the Ugly Data Governance Role.

Bookmark and Share

Two Kinds of Business Rules within Data Governance

Yin and yangWhen laying out data policies and data standards within a data governance program one the most important input is the business rules that exist within your organization.

I have often found that it is useful to divide business rules into two different types:

  • External business rules, which are rules based on laws, regulations within industries and other rules imposed from outside your organization.
  • Internal business rules, which are rules made up within your organization in order to make you do business more competitive than colleagues in your industry do.

External imposed business rules are most often different from country to country (or group of countries like the EU). Internal business rules may be that too but tend to be rules that apply worldwide within an organization.

The scope of external business rules tend to be fairly fixed and so does the deadline for implementing the derived data policy and standard. With internal business rules you may minimize and maximize the scope and be flexible about the timetable for bringing them into force and formalizing the data governance around the rules. It is often a matter of prioritizing against other short term business objectives.

The distinctions between these two kinds of business rules may not be so important in the first implementation of a data governance program but comes very much into play in the ongoing management of data policies and data standards.

Bookmark and Share

Names, Addresses and National Identification Numbers

When working with customer, or rather party, master data management and related data quality improvement and prevention for traditional offline and some online purposes, you will most often deal with names, addresses and national identification numbers.

While this may be tough enough for domestic data, doing this for international data is a daunting task.

Names

In reality there should be no difference between dealing with domestic data and international data when it comes to names, as people in today’s globalized world move between countries and bring their names with them.

Traditionally the emphasize on data quality related to names has been on dealing with the most frequent issues be that heaps of nick names in the United States and other places, having a “van” in bulks of names in the Netherlands or having loads of surname like middle names in Denmark.

With company names there are some differences to be considered like the inclusion of legal forms in company names as told in the post Legal Forms from Hell.

UPU S42Addresses

Address formats varies between countries. That’s one thing.

The availability of public sources for address reference data varies too. These variations are related to for example:

  • Coverage: Is every part of the country included?
  • Depth: Is it street level, house number level or unit level?
  • Costs: Are reference data expensive or free of charge?

As told in the post Postal Code Musings the postal code system in a given country may be the key (or not) to how to deal with addresses and related data quality.

National Identification Numbers

The post called Business Entity Identifiers includes how countries have different implementations of either all-purpose national identification numbers or single-purpose national identification numbers for companies.

The same way there are different administrative practices for individuals, for example:

  • As I understand it is forbidden by constitution down under to have all-purpose identification numbers for individuals.
  • The United States Social Security Number (SSN) is often mentioned in articles about party data management. It’s an example of a single-purpose number in fact used for several purposes.
  • In Scandinavian countries all-purpose national identification numbers are in place as explained in the post Citizen ID within seconds.

Dealing with diversity

Managing party master data in the light of the above mentioned differences around the world isn’t simple. You need comprehensive data governance policies and business rules, you need elaborate data models and you need a quite well equipped toolbox regarding data quality prevention and exploiting external reference data.

Bookmark and Share