Sharing Product Master Data

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

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

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

The True Leader in Product MDM

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

Data Models and Real World Alignment

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

Leads, Accounts, Contacts and Data Quality

business partnersMany CRM applications have the concepts of leads, accounts and contacts for registering customers or other parties with roles in sales and customer service.

Most CRM systems have a data model suited for business-to-business (B2B) operations. In a B2B environment:

  • A lead is someone who might become your customer some day
  • An account is a legal entity who has or seems to become your customer
  • A contact is a person that works at or in other ways represent an account

In business-to-consumer (B2C) environments there are different ways of making that model work.

The general perception is that data about a lead can be so and so while it of course is important to have optimal data quality for accounts and contacts.

However, this approach works against the essential data quality rule of getting things right the first time.

Converting a lead into an account and/or a contact is a basic CRM process and the data quality pitfalls in that process are many. To name a few:

  • Is the lead a new account or did we already have that account in the database?
  • Is the contact new or did we know that person maybe at another account?
  • How do we align the known data about the lead with external reference data during the conversion process?

In other words, the promise of having a 360-degree customer view is jeopardized by the concept of most CRM systems.

Bookmark and Share

Happy 10 Years Birthday MDM Solutions

326px-10piece-blank-R_k.svgEvery year Information Difference publishes a report about the Master Data Management (MDM) Landscape. This year’s report celebrates the 10th year of MDM solutions around. Of course, the MDM industry didn’t start on a certain date 10 years ago, but the use of MDM as a common accepted notation for a branch of IT solutions within data management, and in my eyes as a much needed spinoff of the data quality discipline, was commonly being accepted.

A birthday is a good occasion to look ahead. The Information Difference report takes on some of the trends in the MDM solutions around, being that:

  • Most MDM vendors today claims to be multi-domain MDM providers, but certainly they are on different stages coming from different places
  • Providing MDM in the cloud is slowly but steadily adapted
  • Integrating big data into MDM solutions has, in my words, reached the marketing and R&D departments at the MDM vendors and will someday also reach the professional service and accounting folks there

Read the MDM landscape Q2 2014 report from Information Difference here.

Bookmark and Share

Foreign Addresses

The New YorkerThere is a famous poster called The New Yorker. This poster perfectly illustrates the centricity we often have about the town, region or country we live in.

The same phenomenon is often seen in data management as told in the post Foreign Affaires.

If we for example work with postal addresses we tend to think that postal addresses in our own country has a well-known structure while foreign addresses is a total mess.

In Denmark where I am born and raised and has worked most of my life we have two ways of expressing an address:

  • The envelope way where there are a certain range of possibilities especially on how to spell a street name and how to write the exact unit within a high rise building, though there is a structure more or less known to native people.
  • The code way, as every street has a code too and there is a defined structure for units (known as the KVHX code). This code is used by the public sector as well as in private sectors as financial services and utility companies and this helps tremendously with data quality.

But around 3.5 percent of Danes, including yours truly, has a foreign address. And until now the way of registering and storing those addresses in the public sector and elsewhere has been totally random.

This is going to change. The public authorities has, with a little help from yours truly, made the first standard and governance principles for foreign addresses as seen in this document (in Danish).

At iDQ A/S we have simultaneously developed Master Data Management (MDM) services that helps utility companies, financial services and other industries in getting foreign addresses right as well.

Bookmark and Share

Where to put Master Data?

The core of most Master Data Management (MDM) solutions is a master data hub. MDM solutions as those appearing in analyst reports revolves around a store for master data that is a new different place than where master data usually are. That is for example being in CRM, SCM and ERP systems.

For large organizations with a complex IT landscape having a MDM hub is usually the only sensible solution.

However for many midsize and smaller organizations, and even large organizations with a dominant ERP system as well, the choice is often naming one of the application databases to be the main master data hub for a given master data domain as customer, supplier, product and what else is considered a master data entity.

In such cases you may apply things as data quality services as described in the post Lean MDM and other master data related services as told in post Service Oriented MDM.

scaleThere are arguments for and against both approaches. The probably most used argument against the MDM hub approach is that why you should solve the issue of having X data silos with creating data silo X + 1. The argument against naming a given application as the place of master data is that an application is built for a specific purpose and therefore is not good for other purposes of master data use.

Where do you put your master data? Why?

Bookmark and Share

Service Oriented MDM

puzzleMuch of the talking and doing related to Master Data Management (MDM) today revolves around the master data repository being the central data store for information about customers, suppliers and other parties, products, locations, assets and what else are regarded as master data entities.

The difficulties in MDM implementations are often experienced because master data are born, maintained and consumed in a range of applications as ERP systems, CRM solutions and heaps of specialized applications.

It would be nice if these applications were MDM aware. But usually they are not.

As discussed in the post Service Oriented Data Quality the concepts of Service Oriented Architecture (SOA) makes a lot of sense in deploying data quality tool capacities that goes beyond the classic batch cleansing approach.

In the same way, we also need SOA thinking when we have to make the master data repository doing useful stuff all over the scattered application landscape that most organizations live with today and probably will in the future.

MDM functionality deployed as SOA components have a lot to offer, as for example:

  •  Reuse is one of the core principles of SOA. Having the same master data quality rules applied to every entry point of the same sort of master data will help with consistency.
  •  Interoperability will make it possible to deploy master data quality prevention as close to the root as possible.
  •  Composability makes it possible to combine functionality with different advantages – e.g. combining internal master data lookup with external reference data lookup.

Bookmark and Share