Sutha's SQL BI Blog

4Ps of MDM

On my previous post I did talk about MDM project will not succeed unless organisations change their processes and policies.

There are 4Ps in MDM process. They are

1. Practices
2. Policies
3. Politics
4. Products

Products is the technology, all the other 3 listed above are processes.

Thanks
Sutha

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.

What MDM is NOT

1. It is not a transactional data store.
   MDM is used to produce transactional data but transactional data is not master data. Product master is in MDM, but Orders is NOT.
2. It is not a data warehouse.
   MDM is likely to be used as a dimensional data in the warehouse / BI environment. MDM doesn't hold any facts.
3. It is not a metadata management.
   MDM is about managing and storing metadata about the master data. It doesn't mean it is a central metadata repository.
4. It is not a taxonomy management.
   Master data entities and hierarchies look very similar to taxonomies but we don't have tool to gather and manage taxonomies.

MDS vs AS

MDM / MDS is an application for creating and maintaining master view of reference data / master data. This application maintains policies and procedures as well as work flow management. Master data is slowly changing reference data shared across the whole enterprise. In most organisations the classic example of MDM are Customers and Products.

I would recommend anyone to use MDS to manage the Master Data at all times and push the data out to source system and data warehouse using SSIS.

Staging Tables

Data which get loaded into MDS Staging tables must certain standards. There are three staging tables.

1. tblStgMember - Members staging table.
2. tblStgMemberAttribute - Attribute assignment staging table.
3. tblStgRelationship - Parent / Child relationship staging table.
4. tblStgBatch - I think it is related to Staging Batches. This is under Integration Management, which would enable import / exprot process.

Thanks
Sutha

MDS System Administrator Tasks

1. Create the dimension models and associated hierarchies, entities and attributes.
2. Manage model versions. This would involve copying versions, locking versions, validate for completeness and committing versions.
3. Manage users. Create users and assign appropriate security.
4. Process staging tables. Populate MDM database with dimension model data.
5. Load MDM data views. Load the model versions into the subscribing systems to be viewed.
6. Format and input data. Format the data from the source systems and populate the MDM staging tables with the dimension model data. 
7. Manage business rules. Create and manage business rules to enforce corporate wide standards. Business rules would ensure dimensional accuracy across MDM.

Thanks
Sutha

Name & Code in MDS

Nick Barclay has put together a wonderful blog entries. It gets you going on setting the model, entity, attributes etc.

Nick talks about how to create an attributes for a given Entity. By default you will get Name and Code as leaf attributes. YOU CAN NOT REMOVE THESE 2 LEAF ATTRIBUTES.

Name - This is a system attribute. It is required by MDS. It is assigned to a member that describes the member within a model. The member name "Customer Jo", could describe the customer called Jo.

Code - This is a system attribute. It is required by MDS. It is assigned to a member that uniquely identifies the member within the model. This code MUST be unique within the model.

Thanks
Sutha