An Alternative Multi-Domain MDM Quadrant

Henrik Gabs Liliendahl4 Comments

No, this is not an(other) attempt to challenge Gartner, the analyst firm, in making quadrants about vendors in the Master Data Management (MDM) realm.

This an attempt to highlight some capabilities of Multi-Domain MDM solutions here focusing on party and product master data and the sell-side and the buy-side of MDM as discussed some years ago in the post Sell-side vs Buy-side Master Data Quality.

A simple quadrant will look like this:

Quadrant

  • The upper right corner is where MDM started, being with solutions back then called Customer Data Integration (CDI).
  • The Product Information Management (PIM) side is quite diverse and depending on the industry vertical where implemented:
    • Retailers and distributors have their challenges with sometimes high numbers of products that goes in and comes out as the same but with data reflecting different viewing points.
    • Manufacturers have other issues managing raw materials, semi-finished products, finish products and products and services used to facilitate the processes.
    • Everyone have supplies.
  • The supplier master data management has more or less also been part of the PIM space but looks more like customer master data and should be part of a party master data discipline also embracing other party roles as employee.

Also, this quadrant is by the way without other important domains as location (as discussed in the post Bringing the Location to Multi-Domain MDM) and asset (as discussed in the post Where is the Asset?)

Bookmark and Share

Don’t Mess (Up) with Jensen

Henrik Gabs LiliendahlLeave a comment

Jensens fiskA big talk in the media in Denmark this weekend is the story about that a little harbor restaurant specializing in serving fish has been denied continuing using the name Jensens Fiskerestaurant (Jensen’s Fish Restaurant in English). A lower court has earlier disallowed the name Jensens Fiskehus (Jensen’s Fish House in English).

Jensen BeefThe opponent is a large restaurant chain called Jensen’s Bøfhus (Jensen’s Beef House in English).

This has brought a so called shitstorm over the restaurant chain in social media, not at least on Facebook. Jensen is the most common surname in Denmark. A bit more than a quarter of a million people, which is 5 percent of the population, are called Jensen. So how can a big chain be the only one allowed to use the name Jensen for a restaurant?

PS: I remember this nasty restaurant chain name from when I coded name parsing routines in the old days. “Jensen’s Bøfhus” initially came out as “S. Bøfhus Jensen”. Some of the remedy was to apply external reference data to name parsing as checking if a business entity with a similar name exists on the address.

Bookmark and Share

Sharing Product Master Data

Henrik Gabs Liliendahl11 Comments

One of the top challenges in product Master Data Management (MDM) is the sharing of master data attributes and digital assets across the ecosystem of manufacturers, distributors, retailers and end users.

There seems to be a range of solutions emerging in order to cover that land. Three kinds of approaches will be:

  • Supplier engagement within Product Information Management (PIM) solutions.
  • Similar solutions within wider IT offerings.
  • Social PIM.

PIMMaster Data Management (MDM) platforms with strong offerings for the product domain comes with built-in functionality for engaging suppliers in the process of collecting product master data attributes and related materials as product sheets, images and other digital assets.

You may also find similar functionality within the broader software suites as for example the SAP Product Stewardship Network.

A somewhat different approach may be called Social PIM as explained in the post Time to Turn Your Product Master Data Social? Here the collection process is sort of independent of in-house systems. This may, in the long run, help with having your suppliers having to attend many different solutions and also help your customers depending on where you sit in the ecosystem.

What is your experience regarding sharing product master data?

Bookmark and Share

Bringing the Location to Multi-Domain MDM

Henrik Gabs Liliendahl8 Comments

When we talk about multi-domain Master Data Management (MDM) we often focus on the two dominant MDM domains being customer (or rather party) MDM and product (or maybe things) MDM.

The location domain is the third bigger domain within MDM. Location management can be more or less complex depending on the industry vertical we are looking at. In the utility and telco sectors location management is a big thing. Handling installations, assets and networks is typically supported by a Geographical Information System (GIS).

Master Data Management is much about supporting that different applications can have a unified view of the same core business entities. Therefore, in the utility and telco sectors a challenge is to bring the GIS application portfolio into the beat with other applications that also uses locations as explained in the post Sharing Big Location Reference Data.

Location2

The last couple of days I enjoyed taking part in the Nordic user conference for a leading GIS solution in the utility and telco sector. This solution is called Smallword.

It is good to see that at least one forward looking organization in the utility and telco sector is working with how location master data management can be shared between business functions and applications and aligned with party master data management and product master data management.

Bookmark and Share

CRM systems and Customer MDM

Henrik Gabs Liliendahl5 Comments

Last week I had some fun making a blog post called The True Leader in Product MDM. This post was about how product Master Data Management still in most places is executed by having heaps of MS Excel spreadsheets flowing around within the enterprise and between business partners, as I have seen it.

business partnersWhen it comes to customer Master Data Management MS Excel may not be so dominant. Instead we have MS CRM and the competing offerings as Salesforce.com and a lot of other similar Customer Relationship Management solutions.

CRM systems are said to deliver a Single Customer View. Usually they don’t. One of the reasons is explained in the post Leads, Accounts, Contacts and Data Quality. The way CRM systems are built, used and integrated is a certain track to create duplicates.

Some remedies out there includes periodic duplicate checks within CRM databases or creating a federated Customer Master Data Hub with entities coming from CRM systems and other databases with customer master data. This is good, but not good enough as told in the post The Good, Better and Best Way of Avoiding Duplicates.

During the last couple of years I have been working with the instant Data Quality service. This MDM service sits within or besides CRM systems and/or Master Data Hubs in order to achieve the only sustainable way of having a Single Customer View, which is an instant Single Customer View.

Bookmark and Share

Fitness, Data Quality, Big Data and IT Projects

Henrik Gabs Liliendahl2 Comments

This weekend I’m in Copenhagen where I, opposite to when in London, enjoy a bicycle ride.

In the old days I had a small cycle computer that gave you a few key performance indicators about your ride as time of riding, distance covered, average and maximum speed. Today you can use an app on your smartphone and along the way have current figures displayed on your smartwatch.

As explained in the post American Exceptionalism in Data Management the first thing I do when installing an app is to change Fahrenheit to Celsius, date format to an useable one and in this context not at least miles to kilometers.

The cool thing is that the user interface on my smartwatch reports my usual speed in kilometer per hour as miles per hour making me 60 % faster than I used to be. So next year I will join Tour de France making Jens Voigt (aka Der Alte) look like a youngster.

Viking tour
A Viking tour around Roskilde and Vallø Borgring. Click for report with a wonderful mixup of date formats.

Using such an app is also a good example of why we have big data today. The app tracks a lot of data as detailed route on map with x, y and z coordinates, split speed per kilometer and other useful stuff. Analyzing these data tells me Tour de France maybe isn’t a good idea. After what I thought was 100 miles, but was 100 kilometers, my speed went from slow to grandpa.

That’s a bit like IT projects by the way. Regardless of timeframe, they slows down in progress after 80 % of plan has been covered.

Bookmark and Share

The True Leader in Product MDM

Henrik Gabs Liliendahl10 Comments

Magic Quadrants from Gartner are the leading analyst report sources within many IT enabled disciplines. This is also true in the data management realm and one of quadrants here is the Gartner Magic Quadrant for Master Data Management of Product Data Solutions.

The latest version of this quadrant was out in November last year as reported in the post MDM for Product Data Quadrant: No challengers. A half visionary.

Most quotations after a quadrant release are vendors bragging about their position in the quadrant and this habit will possibly also repeat itself when the next quadrant for product MDM is out.

But I think Gartner has got it all wrong here during all the years. As I have seen it, Microsoft is the true leader and the rest of the flock are minor niche players.

Product MDM

Excel rules.

Bookmark and Share

American Exceptionalism in Data Management

Henrik Gabs Liliendahl2 Comments

The term American exceptionalism is born in the political realm but certainly also applies to other areas including data management.

As a lot of software and today cloud services are made in the USA, the rest of world has some struggle with data standards that only or in high degree applies to the United States.

Some of the common ones are:

celcius fahrenheitFahrenheit

In the United States Fahrenheit is the unit of temperature. The rest of the world (with a few exceptions) use Celsius. Fortunately many applications has the ability of switching between those two, but it certainly happens to me once in a while that I uninstall a new exciting app because it only shows temperature in Fahrenheit, and to me 30 degrees is very hot weather.

Month-Day-Year

The Month-Day-Year date format is another American exceptionalism in data management. When dates are kept in databases there is no problem, as databases internally use a counter for a date. But as soon as the date slips into a text format and are used in an international sense, no one can tell if 10/9/2014 is the 10th September as it is seen outside the United States or 9th October as it is seen inside the United States. For example it took LinkedIn years before the service handled the date format accordingly to their international spread, at there are still mix-ups.

State

Having a state as part of a postal address is mandatory in the United States and only shared with a few other countries as Australia and Canada, though the Canadians calls the similar concept a province. The use of a mandatory state field with only US states present is especially funny when registering online for a webinar about an international data quality solution.

Bookmark and Share

Reading the right Reading

Henrik Gabs Liliendahl7 Comments

TripItIn order to have all my travel arrangements in one place I use a service called TripIt. When I receive eMail confirmations from airlines, hotels, train planners and so, I simply forward those to plans@tripit.com, and within seconds they build or amend to an itinerary for me that is available in an app.

Today I noticed a slight flaw though. I was going by train from London, UK up to the Midlands via a large town in the UK called Reading.

The strange thing in the itinerary was that the interchanges in Reading was placed in chronology after arriving at and leaving the final destination.

A closer look at the data revealed two strange issues:

  • Reading was spelled Reading, PA
  • The time zone for the interchange was set to EST

Hmmm…  There must be a town called Reading in Pennsylvania across the pond. Tripit must, when automatically reading the eMail, have chosen the US Reading for this ambiguous town name and thereby attached the Eastern American time zone to the interchange.

Picking the right Reading for me in the plan made the itinerary look much more sensible.

Bookmark and Share

Data Models and Real World Alignment

Henrik Gabs Liliendahl13 Comments

Usually data models are made to fit a specific purpose of use. As reported in the post A Place in Time this often leads to data quality issues when the data is going to be used for purposes different from the original intended. Among many examples we not at least have heaps of customer tables like this one:

Customer Table

Compared to how the real world works this example has some diversity flaws, like:

  • state code as a key to a state table will only work with one country (the United States)
  • zipcode is a United States description only opposite to the more generic “Postal Code”
  • fname (First name) and lname (Last name) don’t work in cultures where given name and surname have the opposite sequence
  • The length of the state, zipcode and most other fields are obviously too small almost anywhere

More seriously we have:

  • fname and lname (First name and Last name) and probably also phone should belong to an own party entity acting as a contact related to the company
  • company name should belong to an own party entity acting in the role as customer
  • address1, address2, city, state, zipcode should belong to an own place entity probably as the current visiting place related to the company

In my experience looking at the real world will help a lot when making data models that can survive for years and stand use cases different from the one in immediate question. I’m not talking about introducing scope creep but just thinking a little bit about how the real world looks like when you are modelling something in that world, which usually is the case when working with Master Data Management (MDM).

Bookmark and Share