Master Data Management “Best Practices” Benchmarking Study – Publicly Available Part
How to Develop Master Data (Critical Business Data) Management to provide better support to business planning, execution and reporting Tomi Dahlberg
[email protected], 050 550 5718
Final Report 1 © Tomi Dahlberg, 15.03.2010
Note to the Reader Helsinki School of Economics merged with two other Universities and became Aalto School of Economics from January 1st, 2010 In this presentation the HSE presentation layout is, however, still used to provide consistency to those interim reports of the study, which were published in 2009.
Final Report 2 © Tomi Dahlberg, 15.03.2010
Contents 1.
Management Summary
2.
Introduction
3.
Key Findings and Conclusions of the Research (Summary)
4.
Master Data Challenge: Why Are Master Data Projects Started?
5.
Master Data Management Building Blocks Model Applied in this Study
6.
Master Data Management Good Practices and Comments 1. 2. 3. 4. 5. 6. 7.
7.
MDM Vision MDM Strategy MDM Governance MDM Organization MDM Processes MDM Information Infrastructure MDM Metrics
Conclusion: Researcher’s Three Step Development Program
Final Report 3 © Tomi Dahlberg, 15.03.2010
1. Management Summary: Current Status The management and coding of business critical and other master data is fragmented and inconsistent. Consequently data content quality is poor. This has very serious adverse business impacts such as lack of transparency to business operations, lost revenues, unnecessary costs, operational inefficiencies, and erroneous management reporting This also lowers possibilities to receive benefits from business process improvement and other IT related / enabled development initiatives Senior managers who do not understand the business criticality of critical business data tolerate this situation and regard it normal, which is not true A few enterprises improve systematically the management of master data by harmonizing and consolidating the coding and processing of master data aligned to their strategy, business and operational models. As the maturity of Critical and other Master Data Management increases in these enterprises they experience all the time stronger positive business impacts leading to competitive advantages
Final Report 4 © Tomi Dahlberg, 15.03.2010
Management Summary: Reasons for the Status and Way Forward The root cause of the fragmentation in master data is in lack of management. The strategy, business and operational models of an enterprise are not taken down to into master data management objectives, development plans and governance, nor are the consequences of (poor) master data quality monitored The technological flavor of the master data concept as well as the typical practice to develop master data in fragments with the focus of an ERP, CRM, PDM etc. project adds to fragmentation The improvement of critical business data coding and data content quality is significantly easier than for example the improvement of a business process enabled by an ERP system. Significant improvements can be achieved without any investments by managing better the coding of master data as well as data handling processes. The most important decision is to start.
Final Report 5 © Tomi Dahlberg, 15.03.2010
Management Summary: Three Step Development Program 1. Senior management understanding and buy-in 2. Analyze current and desired status and define development plan to close the gaps 3. Development projects to fix Critical Business and Master Data Note! Master data is not a project but continuous process that needs to be improved continuously. Projects are used to speed up development
Final Report 6 © Tomi Dahlberg, 15.03.2010
2. Introduction: Research Project in Brief Research and research support Aalto University / HSE Business technology – researcher and interviewer (Tomi Dahlberg) Solteq – facilitator and research support as well as CxO Mentor Oy Participants in alphabetical order: Elisa Fennia Kone Oyj Onninen Outokumpu Outotec Puolustusvoimat Rautakesko Rautaruukki Oyj Wärsilä
Final Report 7 © Tomi Dahlberg, 15.03.2010
Introduction: Timeline of the Project Project timeline Scope definition and project organizing from May 2009 to September 2009 with participant recruiting (limitation to 10) Kick-off in October 2009 Preliminary Report in November 2009 Preliminary Final report for comments and Final report in January 2010, Final Report in February, Participant specific reports thereafter (these are confidential) Data Collection and Other Methods Interviews in participating organizations from executive, managerial and operative levels as applicable and available Qualitative data analysis, framework modeling and literature study Final Report 8 © Tomi Dahlberg, 15.03.2010
Introduction: What is Master Data and Critical Business Data? Master Data means coded non-transactional data used by an organization to conduct its business. Master Data is used in transaction data, typically to identify and classify transactions. Critical Business Data is that Part of Master Data which contains the most used data objects of master data, for example customer data. Critical Business Data is used by various stakeholders in an enterprise, from local units to enterprise headquarter and in different process and function tasks. Problems and errors in Critical Business Data coding as well as in data content have serious adverse business consequences such as Lost revenues Higher and unnecessary costs Lower productivity and efficiency Misleading control and business reporting data, planning and monitoring difficulties
Anecdotes are provided on the next slide. Their abundance tells a story Final Report 9 © Tomi Dahlberg, 15.03.2010
Introduction: Anecdotes “Two sellers from the same company for the same product had a car collision at the parking place of our company. We never bought anything from them.” “After my appointment three sales managers from Vendor X called me within the two first weeks and told me that they are the key contact person for my enterprise in vendor X. I preferred other vendors since I had no interest to waste my time in discussions with them about their organization.” “We got the two first places in an expensive sales and RFP process for an X million contract. We learned only afterwards that we competed against ourselves. We lost time and more than 500.000 Euros.” “Customers expect us to know the designs of machines which we have installed and which we have maintained. We hardly have any up-to-date documents on what the designs are, what repairs we have carried out and what spare parts we have delivered. My estimate is, that because of this situation, we loose millions of euros annually due to extra work, costs and unnecessary replacements not to mention lost business opportunities.” “In our warehouse we have two boxes of the same item next to each other. They, however, have different identification codes. The other box is seldom used and is always full whereas the other is almost all the time short which causes assembly delays from time to time. Unnecessary waiting time probably has a price tag of X hundreds of thousands every year for this product alone.” ”Our HR had searched three weeks for me based on my maiden name before they found me from the same building as the person who had requested my search. We had to redo the entire internal search for my maternity leave replacement. Due to lost time I had too little time to train my replacement.” ”When the data content of two integrated information systems were compared less than 10 % of the data matched correctly. The other information system is our customer billing system. What a mess!”
Final Report 10 © Tomi Dahlberg, 15.03.2010
Introduction: Critical Business Data Objects and Other Names for Master Data Typical Critical Business Data objects – usually 5-10 data object groups Customers Vendors Sold products* and services* Manufactured products* and services* Purchased products* and services* Personnel Accounting keys (managerial accounting) Installed base**, service base** Other – enterprise specific objects, for example model/design library, functional location Typically there are all in all 60 – 200 master data objects in an organization
Other names for master data Basic data – does not describe the business criticality of this data Parameter data - even more technical term than master data Static data – bad name as Critical Business Data changes all the time •May consist of materials, components, items, products, services, their combinations and includes data structures Final Report 11 ** Contains also transactional data – stored part of data transforms into critical business data © Tomi Dahlberg, 15.03.2010
Introduction: Best Practice Concept Best practice means such Organizational structures (for example master data governance roles and responsibilities, master data organization) and/or, Processes (for example master data development, maintenance and reporting processes) and Relationship mechanisms (such as arrangements which produce alignment, cooperation and co-development between relevant master data stakeholders, typically between head-quarter, business unit and IT functions and between local and global users of master data) Which lead to more effective (business value created with and from master data) and efficient (cost-efficient processing and management of master data ) master data management in an organization Proven with measurable evidence (metrics) agreed by relevant master data stakeholders
At the moment it is premature to use the term best practice in the context of master data processing and master data management Available practical knowledge is too limited, fragmented and controversial Theoretical insight backed by empirical findings is not available, research is only beginning ”Good Practices related to key issues” is a better term and is used in this report Final Report 12 © Tomi Dahlberg, 15.03.2010
Introduction: Best Practice Concept Best practice means such Organizational structures (for example master data governance roles and responsibilities, master data organization) and/or, Processes (for example master data development, maintenance and reporting processes) and Relationship mechanisms (such as arrangements which produce alignment, cooperation and co-development between relevant master data stakeholders, typically between head-quarter, business unit and IT functions and between local and global users of master data) Which lead to more effective (business value created with and from master data) and efficient (cost-efficient processing and management of master data ) master data management in an organization Proven with measurable evidence (metrics) agreed by relevant master data stakeholders
At the moment it is premature to use the term best practice in the context of master data processing and master data management Available practical knowledge is too limited, fragmented and controversial Theoretical insight backed by empirical findings is not available, research is only beginning ”Good Practices related to key issues” is a better term and is used in this report Final Report 13 © Tomi Dahlberg, 15.03.2010
Introduction: Definition of Best Practice Concept Best practice means such Organizational structures (for example master data governance roles and responsibilities, master data organization) and/or, Processes (for example master data development, maintenance and reporting processes) and Relationship mechanisms (such as arrangements which produce alignment, cooperation and co-development between relevant master data stakeholders, typically between head-quarter, business unit and IT functions and between local and global users of master data) Which lead to more effective (business value created with and from master data) and efficient (cost-efficient processing and management of master data ) master data management in an organization Proven with measurable evidence (metrics) agreed by relevant master data stakeholders
At the moment it is premature to use the term best practice in the context of master data processing and master data management Available practical knowledge is too limited, fragmented and controversial Theoretical insight backed by empirical findings is not available, research is only beginning ”Good Practices related to key issues” is a better term and is used in this report Final Report 14 © Tomi Dahlberg, 15.03.2010
3. Key Findings: Partial Solutions Prevail and Cause Inefficiency 1. 2.
Project participants are among the forerunners of master data management in Finland and probably also globally – still each participant has major challenges when compared to good practices Partial solutions prevail and cause serious inefficiencies 1. 2.
3.
Ownership of master data is unclear 1.
4. 5.
Focus on operational master data governance and organization (roles and responsibilities) and master data processes (development and maintenance) At the same time, there are typically several conflicting role and responsibility structures as well multiple differently organized processes within an organization Even when ownership, other roles and responsibilities are defined and agreed the meaning and consequences may not be understood by role owners
Stakeholders’ interests regarding master data makes it difficult to achieve progress – especially if this issue is not managed Master data management vision (business targets), strategy (road-map to achieve targets) and reporting (efficiency and business impact) are areas which have received clearly too little attention 1. 2.
Master Data development typically starts from the operational middle, that is from daily governance, organization and process issues – and too often stops there Reporting on the use of master data in business and on the impacts of master data or its absence is almost entirely non-existing Final Report 15 © Tomi Dahlberg, 15.03.2010
Five Most Surprising Findings to the Researcher 1.
High tolerance for inefficiencies and conflicting solutions Results probably from limited executive level understanding and from the technical nature of the concept. Critical Business Data is introduced to underline the business criticality of MD Results also from perceptions that organizations have survived so far with poor master data Individuals working with master data experience additional challenges
2.
Complexity of master data objects
3.
Difficulty of master data identification
Customer and product data structures are examples of data complexity Especially installed base, design library and functional location master data objects are both complex and long-living (15, 50, 100 years). Yet, even long-living master data is maintained
4.
Progress in master data management seems to require exceptionally strong codevelopment at all main levels of an organization Strong and concrete support from senior management (“We need to fix this bit by bit for these business reasons without giving up”), and Good understanding of the key issues and implementation ability in managerial level (“We are committed to define, agree and implement good practices bit by bit”) Commitment to work with master data according to defined processes at operational level (“We understand why master data needs to be in good shape and for that reason we do our share”) Corporate/headquarter/global – business division/unit/process – local/sub-process level issues
5.
Lack of understanding regarding the need to manage information As an example, CIO stands for Chief Information Officer and IT is about information processing. Yet CIOs and IT departments do not manage information. Master Data and especially the content of this data may not be owned by anybody in an organization Final Report 16 © Tomi Dahlberg, 15.03.2010
How to Interpret these Findings? Root cause: poor executive level management with no links to strategy, business and operational model In participating organizations, persons working with master data management issues are Very committed to improving master data management Strive hard to achieve improvements often under heavy pressures caused largely by partial solutions and related internal politics Often insightful and inventive in master data management Sometimes very skillful in social networking and in persuading people to improve master data management within their organizations Have very often worked for long times with master data and have therefore good insight to the key issues of master data management – yet their role is seldom organization wide and not always even business unit wide
Organizations are not “doomed” to have fragmented poor quality Master Data When an organization knows what to do and follows that plan most of Critical Business Data is good shape within one fiscal year, since each new master data item either improves or worsens the situation The improvement of Master Data Management is a business issue – only business is able to know the content of master data - which also requires good information management and IT skills
Final Report 17 © Tomi Dahlberg, 15.03.2010
Conclusion 1 – From Master Data Management to Critical Business Data Management Even that part of Master Data which is Critical Business Data is poorly managed with significant business value potential Critical Business Data, such as customer, vendor, product data etc., is typically fragmented and non-harmonized and consequently the quality is poor Some parts may be excellently managed at the same time as other parts are practically not at all managed
Improvements in Critical Business Data and Master Data management as a whole have strong business cases Planning, execution and steering of daily business becomes more efficient Only harmonized Master Data facilitates transformation toward harmonized processes and operations. Unnecessary costs as well as other inefficiencies can also be made redundant. Management with information and management reporting improve and offer the ability to achieve fact based business insight Lost business opportunities are turned into additional business opportunities.
Improvements in master data are achievable For example, the combination of an organization wide plan and bit by bit implementation makes improvement possible within a reasonable time with organizational buy-in and learning effects.
Final Report 18 © Tomi Dahlberg, 15.03.2010
Conclusion 2 – Shift Focus from Operational to Strategic Master Data Management Issues Currently main focus areas are operational master data process, governance and organization as well as IT infrastructure issues Operational issues have to be taken care of but lead seldom to good organization wide business motivated solutions
Clearly more emphasis needs to be placed on the business targets of master data development, maintenance and usage, on organization wide master data management issues and on the business impact management of master data usage What are our Critical Business Data and Master Data objects? What are the business reasons, targets and uses of such data objects when various stakeholder interests are considered? How do we best achieve organization wide Master Data management targets? Involvement required from senior executives, managers and specialist The interests of various stakeholders from local units, processes and functions to corporate unit, process and functions need to be considered and balanced Final Report 19 © Tomi Dahlberg, 15.03.2010
Evidence Supporting the Two Conclusions and the Base-Line for Strong Business Cases How can the value of master data be determined? Asset value (the value of master data as a whole): Imagine that your organization would accidentally loose Critical Business Data (Master Data), for example customer names, addresses and other customer master data fields – By calculating the cost of rework and losses from not having access to master data during the rework period it is possible to estimate the direct financial value of master data. – The indirect financial costs and losses resulting from poor customer experience, brand damages, lost business opportunities etc. may also be estimated – Compare this to a situation where an organization has fragmented poor quality customer master data. On business transaction level the outcome is almost similar to that of having lost master data, but may remain invisible since one transaction at a time is impacted
Transaction value (the value of master data in new transactions) Master data stores knowledge of persons working in an organization in coded form and makes that available to other persons (for example product data is made available to those who use that information where then ever they are) – If master data is correct it is automatically used correctly in all transactions linked to that data (e.g. production, logistics, billing, payments, accounting etc.). This is sometimes called “master data inheritance” – Compare this to a situation where an organization has fragmented poor quality master data with some automated and some manual links between information systems. Transactions must to checked and/or complemented in many ways including manual work to verify data. If Master Data is perceived as unreliable persons typically take actions to be able to perform their jobs, for example by purchasing additional products just in case. Final Report 20 © Tomi Dahlberg, 15.03.2010
4. Master Data Challenge Why Is Master Data Fragmented? Key reasons to start a master data project are: Implementation of a new major system; ERP, PDM, SCM, CRM, BI/DW, … Master Data is a concept originally coined by SAP Implementation of a new system by migrating bad quality data without master data harmonization seriously jeopardizes the achievement of business benefits
Migration to new IT platform or technology base; for example from mainframe based systems to modern software architecture based systems Increased use of electronic commerce and electronic transacting Part of databases are opened for two way communication
Since these reasons to improve master data and its management seldom aim at organization wide solutions master data solutions resulting from these projects lead to partial solutions Limited to specific process(es), geographical/functional unit(s), information system(s) and/or information system module(s) (=the scope of the project) Project are typically started at different times with different priorities. Each master data implementation/migration typically results in a different solution
Final Report 21 © Tomi Dahlberg, 15.03.2010
Master Data Challenge One Enterprise Motivated Master Data Projects “One enterprise”, “one business unit”, “one contact point to a customer”, … objectives with the target to have globally, regionally and/or within business units similarly operating units, processes and/or strong cross-selling between units Harmonized and standardized master data management with well organized master data processes is one of the required steps to reach this objective.
More efficient and manageable enterprise and IT architectures through consolidation, standardization and harmonization of information systems and IT services – IT equivalent to the above Cost reduction by removing obsolete, redundant and overlapping information systems and/or by reducing the number instances Increased simplicity and maintainability of IT at lower cost level Managed architecture to increase agility both globally and locally
Since these reasons have an organization wide focus also resulting solutions are more likely organization wide and help to fix the root cause Impacts the funding of organization wide master data management development positively Lack of concrete understanding and slowness of progress may lead to frustration, the combination of organization wide plan and bit by bit implementation is advisable Need to conduct activities on all organizational levels and in all units to include multiple stakeholder perspectives may lead to reduced scope. The combination of organization wide plan and bit by bit implementation starting from critical business data is again advisable
Final Report 22 © Tomi Dahlberg, 15.03.2010
Enterprise and IT Architectures versus Flexibility The Road from Business Silos to Agility Takes Time Architecture maturity
Business Silos
Standardized systems
Optimized core
Business modularity Global flexibility
+
High overall agility and innovativeness
Local flexibility
Source: Weill & Ross: Architecture as a strategy MIT Sloan Center for Information System Research, Harvard Business Books Master Data harmonization follows a similar path -> make optimized core period short
Final Report 23 © Tomi Dahlberg, 15.03.2010
Master Data Challenge BI and Reporting Motivated Master Data Projects Business Intelligence and Reporting projects, for example a Data Warehouse & reporting project, address issues which can be solved only with better master data Examples of typical questions reflecting business requirements How much have we sold products and services to various customers, customer segments, etc.? What are our contacts and channels to customers? How profitable are customers? How loyal are our customers, do we have churn risk? Could we increase sales with customer profile based selling, crossselling or other means? How much have we purchased from various vendors? What are our contacts and channels to vendors? What materials, spare parts, components, products have we purchased? Are our vendors reliable and responsive? What materials, spare parts, components, products do we have in our warehouses? What should we have in our warehouses to facilitate production planning and production, maintenance of assets, asset management, deliveries, after-sales services, maintenance services? How profitable are various products, services and operations? What persons with specific skills have we available for positions, roles, projects, etc ?
These projects may have a partial or organization wide / business unit wide focus with strong information management emphasis Master Data and Critical Business Data object definition skills usually available The connection between reporting possibilities and master data may still not be fully understood due to high reporting granularity and business issues may also be perceived as IT issues Need to address the reporting needs of daily operational activities, business/regional units and organization level may be hard to solve The ETL approach (extract, transact, load) is often used to ”clean” the basic transactional data by regrouping or complementing fragmented master data to provide sensible reports which are reliable enough. Report users should understand the consequences of this ”cleaning”. Final Report 24 © Tomi Dahlberg, 15.03.2010
Master Data Challenge Integrated Processes Motivated Master Data Projects Initiatives to establish highly integrated processes with process and information system integration across information systems Enterprises who have ERP, PDM, SCM, CRM and ebusiness systems with layered IT architectures may start initiatives where so called second wave process integration is carried out Information systems are used to support more integrated processes preferably through unified platforms. Examples of possible second wave processes – Order to cash or contact to cash – Manufacture to inventory, manufacture to project or manufacture to customer – Purchase to pay or procure to pay
Harmonized and standardized master data across systems is required The Master Data databases of legacy systems could be too inflexible for these purposes, however, few better tools are available at the moment. A separate global master data database which is linked to relevant information systems and which includes the history of master data appears as one useful solution
Final Report 25 © Tomi Dahlberg, 15.03.2010
Two Specific Issues in Master Data Challenge The use of ”installed base”, “functional location” and “design library” in after-sales and maintenance business especially in project manufacturing type industries Original constructions or parts of them may be in use for decades Need to access original designs, for example CAD or other design drawings, in after-sales, repair and maintenance businesses Need to follow the replacement history of items, for example what the new item identification for the item which replaces the original item or the previous item identification
Does the history of customer relations create similar opportunities in service industries such as banking, insurance or telecom? I claims it does
The costs and ownership of master data Master data has several stakeholders and is used for multiple purposes. Consequently who should absorb the costs of master data process development and maintenance? Senior management input is required to achieve organization wide solutions If the ownership of master data is given to a major stakeholder how are the interests of other stakeholders fulfilled? Senior management input is required. One possible solution is organize the ownership of master data under a neutral owner such as centralized master data team. Relationship mechanisms are needed Final Report 26 © Tomi Dahlberg, 15.03.2010
Final Comments about the Master Data Challenge Analogy: Master data is the DNA of an organization DNA is unique for each organization although it has an identifiable structure DNA impacts the development of the organization and establishes also the coded history of non-transactional data within an organization. If DNA is poor the organization is vulnerable to inefficiencies and in the worst case to failure
Master data requirements are different at corporate/headquarter, business unit and local levels – balancing of requirements is needed The structures and processes of organizations chance continuously due to mergers and acquisitions, reorganizations, key person changes and market needs All these impact master data and increase the probabilities of inefficiencies The heritance/transformation history of master data is an important part of master data management especially for installed base, functional location and design libraries
Unified globally standardized codes for organizations, products, constructions etc are rare and unlikely to appear in the near future Rather, according to Metcalf’s law the amount of data doubles every 12 months
Final Report 27 © Tomi Dahlberg, 15.03.2010
5. Master Data Management Building Blocks Model; Gartner Group’s MDM Model Was Used to Structure Interviews and Good Practices The Seven Building Blocks of Master Data Management
Final Report 28 © Tomi Dahlberg, 15.03.2010
Remarks on Master Data Management Building Blocks 1. The framework is a useful and practical model of key master data management issues Is consistent with generic development models such as PDCA: Plan (MDM vision, strategy, governance), Do/Deliver (MDM organization, process, information infrastructure), Compare/Control (MDM metrics), Act (return to planning) Includes structures, processes and relationship mechanisms Is business oriented
2. The benefits of using a holistic framework are profound A holistic organization wide approach to master data offers the Possibility to implement effective and efficient practices and to get rid off the current situation with different master data processes and fragmented solutions Possibility to bring clarity to master data concept owner, process owner, other role and responsibility definitions and to get rid off the current unclear practices
Supports the inclusion of all key aspects From vision and strategy to metrics and reporting
In the development of Master Data management progress is needed simultaneously in several building blocks A holistic framework makes business objectives driven development possible with the combination of a organization wide plan and bit by bit implementation Final Report 29 © Tomi Dahlberg, 15.03.2010
Pre-requisites for Master Data Management Development Organization culture which promotes Master Data management development Executive level understanding and firm support so that master data development is driven firmly and decisively Managerial and expert level drive with relationship mechanisms Funding – enterprise or at minimum business unit level funding available
Proper understanding regarding the meaning of roles and responsibilities Too often the meaning of roles and responsibilities is understood only formally (roles may also be accepted by or be forced on persons who have no intentions or skills to act according to the role definition) With proper understanding the logic for allocating and agreeing ownership, other roles, decision making rights and tasks becomes possible in a way, which implements Master Data vision and strategy Experts of software vendors are often used to configure master data file structures due to the technical complexity of this task. It is imperative that business knowledge is involved Final Report 30 © Tomi Dahlberg, 15.03.2010
Best Practice Scales: Capability Maturity Matrix Applied (levels 0 to 5) Item
Scale/width within an organization and time applied
Continuous improvement, benchmarking
Level: 0
None (not recognized)
Level: 1
Project scope Ad-hoc Scope is the sum Repeated, but not of several projects defined Repeated and defined Partially harmonized use, early phase (same approach) Guided with clear Mostly used, metrics several years Optimized, metrics Organization wide, show high performance several years
None to ad-hoc
Maturity level
Level: 2 Level: 3 Level: 4 Level: 5
Status of activity, process or mechanism
Ad-hoc Internally systematic benchmarking started 1-2 benchmarking evaluations Several benchmarking evaluations
Agreed best practices do not exist at the moment and best organizations have reached or are approaching good practices. Therefore a scale for good practice is presented and used instead of this scale Final Report 31 © Tomi Dahlberg, 15.03.2010
Good Practice Scales: Capability Maturity Matrix Applied (levels 0 to 3) Item Maturity level
Status of activity, process or mechanism
Scale/width within an organization and time applied
Level: 0
None (not recognized)
Level: 1
Project scope Ad-hoc Project scopes, Several competing little cooperation ad-hoc approaches Scope is the sum Repeated, not defined of several projects (different approach) Repeated, main Scope harmonization approach identified started Repeated and defined Partially harmonized (same approach) use, early phase
Level: 1 ½ Level: 2 Level: 2 ½ Level: 3
Continuous improvement, benchmarking
None to ad-hoc Ad-hoc with project scope Ad-hoc Internally systematic, still partial Internally systematic benchmarking started
Final Report 32 © Tomi Dahlberg, 15.03.2010
6. Master Data Management Good Practices: 6.1. MDM Vision 1. Organization’s business objectives and drivers for master data management and related master data processes have been defined (effectiveness) 2. Key Master Data objects (Critical Business Data) have been identified, defined and agreed by the main stakeholders of the organization 3. Objectives for unified and harmonized master data processes and master data management have been defined (efficiency; costs and productivity) 4. Effectiveness and efficiency objectives are transformed into concrete measurable metrics which are used to measure the achievement of these objectives
Final Report 33 © Tomi Dahlberg, 15.03.2010
Findings Even most advanced organizations have fragmented vision documents for master data management Vision is typically not organization wide Very often written by person(s) who are responsible for operative master data management activities and since their mandate is not organization wide the document is not either organization wide although offers good starting point Improvements needed in business and strategy related issues as well as in including the input of some relevant stakeholders
Vision document may have been shown to and discussed with senior executives, usually with limited buy-in
This MDM building block has received too little attention
Final Report 34 © Tomi Dahlberg, 15.03.2010
Master Data Management Good Practices: 6.2.MDM Strategy (Development Plan) 1.
Key stakeholders of master data have been identified for most important Master Data objects (Critical Business Data) so that their interests as well as the most typical uses of master data have been documented (for example in a master data architecture document). This makes is possible to define concrete benefits and targets for development efforts as a whole and for each key stakeholder
2.
Funding, organizational-cultural and other prerequisites for master data management development have been established
3.
On overall strategic action plan / road-map for Master Data management has been defined with development responsibilities. This plan guides the implementation of master data management toward the achievement of MDM vision
4.
This overall plan is transformed into concrete measurable road-map metrics which are used to measure the achievement of objectives stated in master data management vision and strategy
Final Report 35 © Tomi Dahlberg, 15.03.2010
Findings Even most advanced organizations have fragmented development plans for master data management Development plans are mainly focused on How to improve operational master data processes with related organizations and governance, How to expand the scope of managed master data, for example by rolling out managed master data processes into new sites, units and/or geographical areas for an ERP, PDM. SCM or CRM system How to improve the quality of managed master data with harmonization and rule handling
Development plans are mostly written by person(s) who are responsible for operative master data management activities
This MDM building block has received too little attention. Significant rapid improvements can be achieved by focusing more on MDM vision and strategy with senior executive involvement and buy-in
Final Report 36 © Tomi Dahlberg, 15.03.2010
Master Data Management Good Practices: 6.3-6.4 MDM Governance and Organization (1) 6.3 Governance 1. Roles, decision-making rights and responsibilities have been defined for key master data development and maintenance tasks (concept ownership, process ownership, data content ownership, typically as a RACI chart) so that those who are given roles and responsibilities understand what their roles and responsibilities mean and behave accordingly 2. Organizational structures, processes and relationships mechanisms have been defined and established for master data management. These structures, processes and relationship mechanisms have started to operate and shown that they are able to balance differences in interests and make decisions 3. Governance model (RACI chart) includes the input of key stakeholders at least corporate headquarter, business units and IT unit as well as local and global perspectives 4. Governance model is aligned with other governance models. This means that master data governance model is consistent with Corporate and IT governance models
Final Report 37 © Tomi Dahlberg, 15.03.2010
Master Data Management Good Practices: 6.3-6.4 MDM Governance and Organization (2) 6.4 Organization 1.
Roles defined in master data governance model have been allocated. In addition to that master data development and maintenance teams are organized with sufficient resources evaluated from time to time so that each role and person has measurable performance objectives
2.
Master data teams and persons having master data related roles have received sufficient education and training on the basis of role, team and task related skill and knowledge definitions
3.
Links to key stakeholders are defined and regular contacts with them are executed to understand changes in their needs (user satisfaction)
4.
Organization and its performance is improved systematically based on performance metrics
Final Report 38 © Tomi Dahlberg, 15.03.2010
Findings 1.
Participating organizations do not have unified processes and/or some master data processes are not managed (at all). This is reflected also in governance and organization which are also partial Partial solutions in governance, organization and processes lead to variance in master data quality
2.
Consequently Master Data governance structures and organizations are fragmented and usually even partly missing Role, responsibility and other governance definitions cover only well managed processes and units Internal difficulties even conflicts due to dissimilar governance and organizational arrangements Data ownership, especially data content ownership as a whole least developed
3.
Alternative placements of master data teams within organizations In a business unit – major stakeholder (risk that the needs of other stakeholders receive less attention) In a business unit - neutral unit selected to avoid overly dominance of major stakeholder(s) In an IT unit – business understanding is a challenge, requires strong data content ownership within business units. Note ! Master Data management is more a business than IT issue. Between business and IT – appears ideal if good mastery of both business and IT is achieved. Job rotation may be needed from time to time to maintain this type of understanding
Final Report 39 © Tomi Dahlberg, 15.03.2010
Master Data Management Good Practices: 6.5 MDM Processes 1. Master data development and maintenance processes are defined and implemented for key Master Data (Critical Business Data) objects in a unified way or if processes differ such differences are based on decisions with strong business motivation. Master Data processes have effectiveness and efficiency targets 2. It is possible to follow the status of Master Data processes from task to task at Master Data transaction level as well as the heritance of master data to business transactions 3. The processes balance the needs of various stakeholders typically local - global needs, site - business unit – head quarter needs 4. Process performance is improved constantly on the basis of effectiveness (business impact) and efficiency (process performance) metrics
Final Report 40 © Tomi Dahlberg, 15.03.2010
Findings Two types of processes appear to work well – corrections immediately at the source of data 1.
2.
Centralized process divided into global and global master data domains with centralized input of global data Opening or modification of global data is requested by a local user e.g. with an electronic form Master Data is opened or modified centrally based on local request Automatic rule based controls on master data Request is returned to the local user with correction demand if data is missing or incorrect Inform the local user about new or modified data record(s) upon successful input e.g. by stamping the electronic form Opening, maintenance and removal locally for local data Workflow management and timeline targets for centrally opened global data Centralized process divided into global and global master data domains with local input Centralized team performs automatic rule based controls for global data immediately for all new or changed data records with the authority to requires corrections for incorrect global data Centralized team is responsible concepts, development, training and provides support to local users Inflexibility caused by excessive automatic rule based controls is a risk after some time
Why do other types of processes not work properly? Fully centralized, for example into accounting This may lead to local, unofficial registers due to the perceived inflexibility of a fully centralized process Decentralized/local without strong centralized power for global data Leads typically to massive master data quality problems with expensive periodic clean-ups. Still, master data is seldom in good condition even after clean-ups Clearly worst process is the one where master data record is opened blank with minimal data and filled gradually afterwards without any rule based controls
Almost all participating organizations have master data processes which work well but also processes which are far from working well Final Report 41 © Tomi Dahlberg, 15.03.2010
Master Data Management Good Practices: 6.6 MDM Information Infrastructure (Tentative) 1.
Master Data information infrastructure is consistent with overall IT architecture at infrastructure, applications, information, process and enterprise levels
2.
There are flexible data access, integration and reporting tools by which the transfer of transaction data between integrated information systems can be monitored to check that master data records match between integrated systems
3.
Master Data information infrastructure elements work reliably according to defined service and operational level agreements (SLA/OLA)
4.
Reporting tools provide information on how master data management vision and strategy objectives as well as process performance targets are met. Reporting also show the quality of master data inheritance (proportion of correct automatic master data creation in business transactions) Final Report 42 © Tomi Dahlberg, 15.03.2010
Findings 1.
Typically master data databases reside within some major information system (for example ERP, PDM, SCM, CRM, HR) Use of master data is usually perceived inflexible especially in other information systems The data bases of these information systems have not been designed to handle master data of multiple information systems
2.
Separate tools and/or Master Data databases/data warehouse tools (for example Arch for HR, SAP “MDM module”, Ineo, Microsoft SQL server add-ons, IBM MDM, Oracle MDM), development going on in this area
3.
Opening tools -> unified electronic forms within a platform with single input, use of email, workflow management
4.
Checking against separate registers for example for addresses, some data items
5.
Fragmentation and poor quality of master data seen in most organizations cannot be fixed with an additional information system or tool. Other MDM building blocks have to be fixed first
Final Report 43 © Tomi Dahlberg, 15.03.2010
Master Data Management Good Practices: 6.7 MDM Metrics 1.
Reports on metrics make it possible to evaluate progress in the achievement of master data management objectives (vision and strategy)
2.
Reports produce information on the use of master data in business with benefit impact or losses if master data is not correct (effectiveness metrics), for example based on inheritance analysis
3.
Reports produce information on the performance of master data processes and organization (efficiency in terms of costs and time to open / modify data)
4.
Reports delivered to key stakeholders are used and actions to improve master data management are started
Findings This MDM development block is least developed. Organizations typically have reports which show how many records have been processes and how many duplicates have been found
Final Report 44 © Tomi Dahlberg, 15.03.2010
7. Conclusion: Researcher’s Three Step Development Program 1. Get senior level understanding and buy-in Critical Business Data is the most important part of Master Data Organizations can achieve improvements fairly rapidly by doing right things
2. Analyze current and desired status and define development plan Benchmarking (unless you have done it already) which reveals immediate improvement potentials Domain specific data status check and evaluation to understand the quality of master data. This provides additional improvement suggestions Strategy and road-map development plan to create organization wide targets for MDM building blocks and to establish a bit by bit implementation plan. This reveals both quick wins and long term benefits
3. Development projects to fix Critical Business and Master Data Bit by bit implementation of development plan
Final Report 45 © Tomi Dahlberg, 15.03.2010
Three tips for quick fixes 1. Check identification coding of critical business data objects Inconsistent descriptive coding has significant negative effects and blocks development
2. Check errors immediately in new master data items with a control process and make those who input the data to also fix errors Errors are easier and cheaper to correct when information is fresh
3. Create awareness for the business importance of critical business data (master data) to support the two above.
Final Report 46 © Tomi Dahlberg, 15.03.2010
