Open Framework, Information Management Strategy & Collaborative Governance | Data & Social Methodology - MIKE2.0 Methodology
Wiki Home
Collapse Expand Close

Members
Collapse Expand Close

To join, please contact us.

Improve MIKE 2.0
Collapse Expand Close
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.

Complexity estimation model for MDM

From MIKE2.0 Methodology

Share/Save/Bookmark
Jump to: navigation, search

Contents

= Master Data Management Complexity Estimation

Sample complexity estmation according to 3 dimensions (Governance, Architecture, Data)
Complexity estimation for Master Data Management initiatives is used to assess cost, time for projects but it can also help to identify and assess risks for Master Data Management initiatives. Master Data Management projects can span a very wide range of scope. The estimation should therefore always begin with the scope clarification. In order to clarify the scope, 3 dimensions are relevant:

Governance Complexity

This dimension groups and assesses the organizational and change management effort, that is required to implement a master data solution. It assesses the time and effort it takes to implement and manage the “soft factors”. As master data initiatives always tend to create change in the way an organization handles its most basic information assets, the Governance complexity contains a lot of the risks. While it is difficult to measure soft factors, there are some indicators that provide guidance: The first indicator to take into consideration is the gap between the current maturity level and the target maturity level. Moving up the maturity level will increase the complexity especially on the change management aspects in terms of organizational re-alignement, education and training. An essential part of the maturity are gaps in centralization or decentralization that should be closed with the master data initiative: To introduce a centralized master data management in a completely de-centralized enterprise, is likely to drive the change management efforts by factors. The second indicator for the governance complexity is the number of stakeholders that need to be included into the solution. While it is the nature of master data that multiple stakeholders are involved, there are nevertheless differences per object and industry that can change the picture substantially. As an Example: the material data object contains in a discrete manufacturing enterprise a substantially higher number of stakeholders than for example in a financial services enterprise. etc. The next indicator for the governance complexity is the enterprise scope of the master data solution.While the aim of a master data initiative is always at enterprise level, the complexity of the enterprise in itself may differ (not all companies operate globally!) and this exercise can also help to scope and lay out development and roll-put paths for the overall approach. In this factor, 9 levels of scope are differentiated.

  • Global Vertical integrated: this is the highest level of complexity. The scope of the master data solution covers all operational units across all lines of businesses, and spans all business processes from tactical shop floor systems to strategic planning and reporting.
  • Global Horizontal integrated: here also scope of the solution is delimted as it focuses the master data onto specific processes, but still goes across all regions and lines of business.
  • Global divisional: here the scope is further managed as it delimits the Master data solution onto a specific line of business. This is considered a scope management because of the following reasons:
  • There is a higher degree of common understanding about the type of business, relevant standards and definitions inside one line of business
  • Governance structures, policies and practices can easier be aligned with exsting lines of management.
  • Regional vertical integrated: this has the same scope as global vertical integrated (all operational Units, all functions and processes) but is limited to a regional scope.
  • Regional horizontal integrated: this has the same scope as global horizontal integrated (all operational Units, limited to a specific process) but is limited to a regional scope.
  • Regional divisional integrated: this has the same scope as global divisional integrated (all units inside 1 line of business) but is limited to a regional scope.
  • Local vertical integrated: this has the same scope as global vertical integrated (all operational Units, all functions and processes) but is limited to 1 country.
  • Local horizontal integrated: this has the same scope as global horizontal integrated (all operational Units, limited to a specific process) but is limited to 1 country.
  • Local divisional integrated: this is the lowest level, it usually contains 1 operational unit

In relation to the enterprise scope but nevertheless independent complexity factors are finally language and charactersets. The number of languages indicates the on the one hand the cultural complexity in terms of organization, training etc. but also simply the effort it takes to define standards and produce translations across different languages. The number of different charactersets to be supported are included as additional factor because the integration between Latin (Western) charactersets and Chinese, Japanese, Korean and Russian languages and cultures provide additional challenges beyond translation between western languages.

Data Complexity

The data objects that are included into the scope also have an impact onto the complexity. Next to the number of objects, the complexity of each data object needs to be assessed. Drivers for complexity of an object are:

  • Number of Records for an Object
  • Number of tables and attributes (fields) in an object
  • Number of business processes and functions that use the data object
  • External Regulatory and Compliance framework

While the first 2 criteria will have an influence onto the data quality and migration efforts, the other 2 aspects have an influence onto the governance and change management efforts. Here the drivers work as follows: The more processes and functions that use a specific data object, the larger the number of stakeholders becomes that need to be included into the definition of standards and data maintenance processes. On the other side the larger the external regulatory and compliance framework is, the more existing standards and procedures can be employed as part of the solution. Further information about assessing the data dimension can be found in the estimation model for migration.

Architecture Complexity

To assess the complexity drivers on the architecture level, the following gaps need to be assessed.

  • Gap between current state data architecture and target master data architecture.
  • Integration efforts between Master Data solution and Enterprise system architecture.

These 2 factors are not necessarily coupled. It can be that a master data architecture like a central master data management solution that is implemented into a heterogeneous enterprise architecture is causing prohibitive system integration efforts. In order to assess the integration effort, the following factors are identified:

Number of Vendors / Application Platforms

Each vendor / application works with a specific data model, that builds upon a Master Data Management framework which is either implicit or explicit engraved into the system. Any attempt to establish shared standards and maintenance processes is therefore tightly coupled with the effort to synchronize the different architectures and processes. The more different vendors and applications there are, the more complex the integration will be. 

Number of Systems / Installations

On the next level below the Vendor or application specific models, the physical number of systems or installations for each application is a complexity driver. Each productive instance of an application, will have different master data and variations in processes, definitions and standards.

Age of Systems On the level of each instance, the age of the system is driving the next lower level of complexity. Since no system is stable both in terms of system change management and master data and undergoes an constant evolution, the age of the system has an influence on the complexity. The older the system, the higher the degree of customization will be, the lower the quality of data and the lower the quality of explicit documentation and standards will be as a general rule.

Number of interfaces between systems This factor is an essential driver of the technical complexity. Especially in an architecture that is not yet on a systematic SOA and managed master data maturity level. There will be likely a substantial number of point-to-point interfaces for master data. Since a master data program does not necessarily replace existing business application, such interfaces will need to be assessed for master data relevancy. After this, there needs to be an assessment and decision if the interface needs to be included into the master data distribution and what effects the standardizations will have onto the interface.

Graphical charting

As we have seen, there are many factors that drive complexity of a master data initiative. It is therefore very helpful to structure the discussion and visualize the outcome in a graphical chart. For this, the following formulas are proposed to quantify the factors in an index and chart them with 3 dimensions. Governance Complexity Index The governance complexity index is giving an insight into the cumulative effort that is needed for Governance and change management. It is therefore the indicator of the organizational risk, ie the risk that the initiative will fail to deliver the expected results due to organizational resistance.

Formula: (Governance complexity index) = ((Governance Maturity Gap + 1) x (Number of Stakeholders) x (Enterprise Scope) x (Regulation framework)) + (( Number of languages) x (Number of Charactersets to be supported))

 

Architecture Complexity Index The architecture complexity index is grouping the technical integration effort and risks based on the platforms, systems and interfaces. We also include the average age of the systems into this chart based onto the frequent experience that with increasing age of any system the quality of documentation, interface specifications is decreasing and customization using “in-official” standards are increasing. All of which are increasing the effort to identify, resolve and test all such issues

Formula: (Architecture complexity index) = ((number of platforms) x (number of installations) x (average age of the systems)) + (number of interfaces)


Data Complexity Index The data complexity index indicates mainly the time and manpower effort to review, cleanse and harmonize the existing master data records to the new standards. The base data needs to be assessed per object and per system. The index itself is displayed as the size of the bubble in the chart an is grouped by data object. The information about data complexity can be used as baseline for the data cleansing and migration effort (for this only an estimate for the average number of minutes it will take to clean 1 record needs to be added for a total assessment of the manpower required.

Formula:

(Data Complexity of Object “y”)= SUM ( (number of records for object “y” in system “n”) x (number of attributes for object “y” in system “n”) x (age of system “n” in years))

Assessment of estimation result
Quadrant for assessment of master data project complexity with generic implementation strategies

This chart can be used for the clarification of the expectations and risk of a Master data initiative to establish roadmaps and also to manage the scope. The result of this complexity estimation should be charted against the expected benefits. Probably it makes sense during the strategy blueprint and roadmap discussion to develop several scenarios (e.g. limiting geographical scope, object scope, system scope) to find a balanced effort. In order to manage the discussion the result of the estimation is then overlayed with a 2x2 matrix that illustrates the extremes and provides generic strategic options. forfait sosh rio sosh portabilité du numéro calcul IMC rio orange

Wiki Contributors
Collapse Expand Close