I faced a couple of times the following question: "Where should I start with MDM?"
Well, this is an excellent question, and I will try in this post to provide some elements of thought.
Single Domain MDM Make it Simple, But...
The first-generation single-domain MDM solutions have been out there for years. They came up with ready-to-use solutions for Customer Data Management/Integration (CDM/CDI) and Product Information Management (PIM) needs, sometimes even specialized to single industries.
At that time, the "Where should I start?" question was simply answered: You start with what the solution is providing. You buy a CDI to do customers MDM, and nothing else !
After a few years, these products have faced some critics.
Lack of Customization and Cost of Integration
Similarly to the Enterprise Resource Planners (ERP) systems, these PIM/CDI solutions force the enterprise to adapt to them to a large extent.
These products claim to have customization capabilities, and guarantee that they will adapt to the enterprise, but it is not entirely true:
- First, customizing a prepackaged solution is risky and frequently not very well supported. For example, merging your customizations with the vendor's evolutions is a painful and tedious process.
- Second, customizing a solution engineered from top to bottom to work not as an "MDM appliance" is not an easy feat, and does not bring a lot of value.
Customization in this context has an arguable return on investment, and the enterprise soon realizes that adapting to the tool is cheaper on the short term than adapt the tool. Yet, on the long run, this approach is not viable: As the enterprise evolves and requires more and more agility, it cannot be coerced to work like one of its software products.
Domains Becoming Silos
Another (almost genetic) problem with the single-domain solutions is the creation of silos of master data, one for each domain. These silos should not exist, as they create new issues (master data domains integration) where MDM should not.
Let's take an example. I have
- A Customer Hub for managing customer/contact data.
- A Product Hub for handling product catalogs/parts etc.
- An Employee + Cost Centers + Locations Hub for the HR and Finance teams.
These are three different functional areas, right?
Well, not always:
- Customers have Employees who act as their Account Managers.
- Products are built in specific Locations
- Products and Customers are related by "special product offering" or "customized products" items.
These examples do not represent transactional data, but actual master data.
So here is a simple fact:
There is Master Data "between" the pre-packaged domains, and single-domain MDM solutions cannot handle it.
What do we mean when we say Multi-Domain MDM Platform?
- Multi-Domain means : able to support any of the domains, including the master data "between" domains.
- Platform means : not a pre-packaged - "closed" - solution, but a blank page where you can implement your needs. Eventually, model templates should be provided to accelerate the design and implementation of a solution. Note that blank page does not mean long development process, as I explained in a previous blog post. Platform also means support for all the features of a pre-packaged hub, for example for data consolidation.
The Fear of the Blank Page
The drawback of having a platform vs. a pre-packaged solution is the syndrom writers known as "the fear of the blank page" and its resulting question: "Where should I start with MDM?"
This question has a simple answer: "Where you need it the most !"
Seriously. Where Should I Start?
Well, seriously, there is not a rule carved in stone, but several tips that can help you prioritize MDM projects within your initiative:
- Get Corporate support: This one is easy to understand, and the biggest challenge. Without a certain amount of awareness on the subject of data governance, without C-Level and IT support, there is no chance that a domain implementation succeeds.
- Get LOB support: MDM is about enabling business, so you need the business to be on-board for success. LOB support for MDM is key.
- Start small: How many projects have failed because they were too ambitious?! Do not try at once a gigantic project, involving all LOBs with an unpredictible ROI! Try to sell to your CEO a small project with a good ROI, and involving a small LOB.
- Know your Sources: in MDM projects the source systems are frequently overlooked. These sources are the providers of raw data for your MDM, and probably the consumers of the master and golden data. You will have to interact with certain sources and they will have a huge impact on the MDM project.
- Available Resources: an MDM project will need funding, support, skilled resources, etc. Insist on the skilled resources, as MDM requires both technical *and* business competencies.
In essence, you should start MDM where you get Corporate and local support, where you know the sources and have good resources. In addition, you should start something small with a good ROI.
Act Local, Think Global
As you may have seen in the previous paragraph, I am not in favor of building The Great Master Data Fortress from nothing. I prefer to build a first nice functional cottage, and have it evolve slowly to a decent-sized castle.
Yet, while building my cottage, I will always keep in mind my objective, that is the castle.
So wherever you start from, always keep in mind the main reason of choosing multi-domain MDM: You want potentially to have all master data from your company in this hub.
Build your MDM like your career. In five words: Act Local and Think Global.