MDM Project Approach
Ideally we would like the MDM to feed our source systems and data warehouse. I personally think it is a wishful thinking. I don’t think we will ever achieve that. MDM is the place of entry for any master data. It is not only an entry point, but it also records all the changes.
The above scenario is very optimistic and probably unrealistic expectation to run our business in this manner.
Best possible way to succeed in any MDM project is to start small (specially when you are new to the technology) and gradually increase the scope. If you decide to do comprehensive solution it will be very expensive and likely to fail. For most organisations the great place to start is Products. Ask questions such as does this domain add value to the organisation and can this project be reused when we come to do Customers? It is generally easier to get budget approval for small amount from a department or organisation. The general principle is I am only going to pay to fix my departmental issue.
Ideally you should select a domain / model for MDM and work on it initially. Identify the entities within the model. Identify attributes and hierarchies related to the Entity. This could be a repetitive process until you have a good design.
Once entity, model, attributes and hierarchies are identified, you can move on to business rules, process flows and user / group permissions.
The above diagram explains how we could go about implementing MDM project. We could do in small chunks or phases. In Phase1, we could get data from operational source systems such as Microsoft Dynamics and SAP into MDM. These source systems import could act as an initial system entry point for MDM. Once data is in MDM data governor or steward can modify or add additional information through the front end provided. The modified data in MDM is the source for a data warehouse across the enterprise.
During Phase 2 of the project, MDM is the system of record and entry for Microsoft Dynamics. In other words MDM is the master data owner for any reference data in Microsoft Dynamics.
Even though we would like to be in ideal scenario as I mentioned in my first diagram, but in reality it is near to impossible to achieve that goal. In reality MDM can be the system of entry for some of the data like Products, but not all of the data in ERP systems like Customers. When customer calls with an enquiry SAP system would need to log about it. They can’t and won’t wait until the data is in MDM.
During the analysis phase of the MDM project establish Stakeholders, Business Drivers, Processes (Current & Desired), Decide what is nice to have and what is out of scope of each Phase.
As I mentioned before start the project SMALL, have a sponsor (Someone at the top of the organisation). Solve a real business problem by embarking on a project like this. You should have really good technical resources on this project as well as someone from business who knows the entity very well. Make sure you have a business user involved in the MDM project as most technical people will NOT have business knowledge which is vital for the success of this type of project.
Please note MDM is software it is NOT a solution. MDM project will NOT succeed unless you change your processes and policies. For the project to succeed you would need the support from the top management to data steward. Select your project carefully, where you are going to get the backing for your project. I cant emphasise enough the important of the process. Process is more important than technology in MDM project.