Hi Subin,
The initial and biggest challenge would be to recognise what is a master data and what is not.
Typically only Master data should go to MDM and transaction data should be avoided as it unecessarily loads the system (unless required).
Master data can be described by the way that it interacts with other data. For example, in transaction systems, master data is almost always involved with transactional data. This relationship between master data and transactional data may be fundamentally viewed as a noun/verb relationship. Transactional data capture the verbs, such as sale, delivery, purchase, email, and revocation; master data are the nouns. This is the same relationship data-warehouse facts and dimensions share.
What to manage and what to call is a business call,and once such decision has been taken it is MDM principles and toolset which enable overall management of master data.
What to manage?
It is governed by :
1.Behavior - The way data interacts with other data.
2.Lifecycle - Master data can be described by the way that it is created, read, updated, deleted, and searched.
3.Cardinality - As cardinality (the number of elements in a set) decreases, the likelihood of an element being treated as a master-data elementu2014even a commonly accepted subject area, such as customeru2014decreases. For example, if a company has only three customers, most likely they would not consider those customers master datau2014at least, not in the context of supporting them with a master-data management solution, simply because there is no benefit to managing those customers with a master-data infrastructure
4.Volatility - Master data is less volatile than transactional data.As it becomes volatile,likelihood of considering it as transactional data oincreases.
5.Complexity - Simple entities, even valuable entities, are rarely a challenge to manage and are rarely considered master-data elements. The less complex an element, the less likely the need to manage change for that element
6.Value - The more valuable the data element is to the company, the more likely it will be considered a master data element. Value and complexity work together.
7.Reuse - One of the primary drivers of master-data management is reuse
Ultimately, when deciding on what entity types should be treated as master data, it is better to categorize them in terms of their behavior and attributes within the context of the business needs than to rely on simple lists of entity types.
You can break such a data migration project in the folowing way:
Proj Prep and Blueprinting
1.Legacy system connectivity
2.scope
3.Data Quality assessment
4.Data Governance plan
5.Post go-live governance
6.Reporting requirements
7.Cut Over Plan
8.Load Strategy
9.DQ metrics
10.Project Plan.
Realisation:
1.Data Governance Setup
2.Cleanse
3.Validate
4.Build Business Rules
5.Master Data Construction
6.Unit test
7.Multiple Loads
8.Business User Reviews
Final Prep:
1.Ongoing Data Quality
Assessment
2.Integration Test
3.Reconciliation test
4.User Acceptance
5. Documentation
Go-Live :
1. Final Loads
2.Go Live
3.Reconciliation
Thanks,
Ravi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.