NCOE whitepaper Master Data Deployment and Management in a Global ERP Implementation Market Offering: Package(s): Oracle Authors: Rick Olson, Luke Tay Date: January 13, 2012
Contents Executive summary 1 Introduction 2 Problem definition 3 High-level solution 4 Solution details 8 Business benefits 18 Conclusion 19 About Deloitte Consulting LLP 20 NCOE leading practices
Executive summary Executive summary In limited geographical Enterprise Resource Planning (ERP) implementations, Master Data Management (MDM) is not formally addressed with a dedicated MDM team, instead the functional teams are tasked to manage MDM efforts, but using this approach may cause overall data quality issues for the larger and more complex organizations attempting a global implementation. Furthermore, in a multiinstance implementation, data is often neglected and its complexity is underestimated. Consideration to MDM data domain, organization structure, process, and conceptual design can be the key to an effective ERP implementation. Prior to embarking on a MDM initiative, an analysis of business drivers and current state assessment should be undertaken. The ultimate goal is to add to shareholder value. Improvements in efficiency, improvements in customer and supplier relationships, and enhanced execution from accurate product structures can facilitate the development of the business case to support the MDM and ERP initiatives (Figure 1). Figure 1 In many cases, businesses have not developed MDM governance practices at the same rate of progress as other key business processes. As an enterprise expands globally, it soon finds that underfunded data management practices can restrict the enterprise expansion and even delay desired ERP initiatives. This paper describes the domain options, the required organization structure, business processes, and data design of master data management to facilitate the implementation and subsequent rollouts of a global ERP initiative. 1
Introduction Introduction A master data deployment initiative requires technical infrastructure, organizational alignment, business processes, and a detailed data design to be effective on a global level. This effort should take the form of a business transformation project since it will require sponsorship, project management, and cross functional deployment teams. Depending on the number of sites and geography in scope, a global deployment project can take multiple months to implement. Initially, the infrastructure domain needs to be established. First, the budget for the investment of additional technology needs to be determined. This will define the vision of the governance maturity model to be implemented. In addition, it provides the framework to determine the origin of the data sources, define the necessary integrations, and determine the sequence and timing of updates. The maturity model will also have a direct impact on the organizational model and the business processes necessary for proper support. A critical success factor for an effective rollout is a cross functional master data organization with executive-level sponsorship. This is necessary to manage the development, execution, and quality of the master data lifecycle and demonstrate the significance of data quality to the enterprise. The organization levels should have a global, regional, and local structure incorporating information technology, finance, marketing, sales, engineering, and supply chain planning representatives. The size of the organization is directly related to the volume, quality, and complexity of data to be managed. Representatives of this organization should have defined roles in each operating location. In order to manage the lifecycle of master data and integrate properly into the enterprise, the organization should develop detailed end-to-end MDM business processes. These processes should be incorporated into the project scope, built into the configuration design of the implementation and become a permanent part of the key business processes. This should encompass customer, supplier, item, and financial related data elements. Due to the cross functional nature of the master data structure, sequencing and timing of the data lifecycle maintenance tasks should be mapped out in detail including specifications, policies, and process performance indicators. Data design and definition will potentially impact hundreds of data field elements potentially across multiple applications. Each element must have a defined definition, defined values, and an owner. The data design should be segregated into global, regional, and local requirements and each data element assigned accordingly. Care should be taken to keep the scope of the definitions as simple as possible with limited selection options. Over complicating the design or having a wide range of choices will add complexity to construction, analysis, and reporting. Consolidation of the chart of accounts (COA), product structure taxonomy, and the use of parent/child relationships are some of the more frequently used concepts. When proper focus is applied to managing master data in an ERP implementation, it can result in a smoother rollout, more efficient maintenance, and a higher degree of data integrity across the enterprise. The initial startup cost and maintenance of the MDM organization can be justified with higher quality analysis and decision making, reliable reports, improved productivity, fewer transactional errors, reduced financial variances improved revenue opportunities, and enhanced acquisition possibilities. 2
Problem definition Problem definition The areas of concern for deploying global MDM can include: IT investments to support leading MDM designs are necessary, but can become significant in a global approach if not assessed properly Improper global master data management and governance results in inconsistent financial reporting and reduced supply chain efficiency Lack of data consistency and integrity in item, customer, supplier, and financial data contribute to chronic process barriers and excessive costs between facilities within the organization Inadequate master data business processes cause delays of product introduction and an increased cost of quality Data domains are typically defined within a maturity model framework. The framework identifies models from a low cost complexity to a high cost and high complexity domain. The total investment is based upon the value of the data to the business. Typically, global organizations tend to have higher maturity models than national organizations. As a result, organizations expanding their global footprint will need to carefully consider cost versus value of the maturity model. In most regional or national organizations data is managed locally. As the organization grows, it typically finds that attempting to consolidate local data between facilities consumes valuable time. There are many data conflicts and the data source and owner is unclear. If a defined master data organization exists, it usually is centralized at the organization s headquarters with limited authority or structure at satellite facilities resulting in delayed or flawed business decisions and reporting. Data inconsistencies include multiple addresses for both, customers and suppliers, missing or incorrect attributes, item records that are inconsistent between facilities and facility-specific COA. This ultimately leads to order processing delays, inaccurate shipments, invoicing and payment discrepancies, higher inventory obsolesce reserves, and higher degrees of effort to generate consolidated financial period reports. When a new product, customer, vendor, or business unit is created they are typically initiated by different functional areas within each facility. The data maintenance processes which include the process to create, maintain, and inactivate master data is designed in isolation from other business processes and its impact to downstream business processes is not considered. In addition, formalized cross functional process management and performance metrics for master data are not monitored as closely as supply chain or finance business processes, despite the fact that these key business processes depend on correct master data to function properly. ERP implementations that neglect MDM or design data maintenance processes in isolation from key business processes will find challenges as transactions and operations are negatively impacted. 3
High-level solution High-level solution Master data domain Current and future data domains will define the platform from which the MDM initiative will be developed. Data domains are defined by maturity level. Data domains are based off of the enabling technology available to the enterprise. This in turn determines how the technology will be utilized (Figure 2). Figure 2 An enterprise should assess the current and future state architecture including executive sponsorship, data governance, existing capabilities, and data processes to determine the maturity level, the future state solution, and investment required. The target architecture and maturity level should be the scope for the master data design and the starting point for the data modeling which will determine the amount and complexity of the data integrations to legacy applications required. Data governance approach A centralized data governance methodology is necessary to provide the structure that supports a global data infrastructure. This is supported by an MDM governance organization. This organization should be comparable to any of the other functional organizations within the company. The global data strategy incorporated provides reduced operating costs, enhanced execution, and improved response to market demands. The benefits of this approach include: A global governance model can Provide standardized data and processes to enhance supply chain network capabilities and consistent financial reporting across global regions Establish a consistent methodology for product lifecycle management Establishing an MDM organization can Improve operational efficiencies across markets 4
High-level solution Enable continuous improvement processes and culture Create a single entity for standards integrity and execution models The typical IT strategy incorporates the policies that support the MDM activities. It is the delivery processes that are coordinated with the ERP initiative to provide the intended business driver results. The primary pathways to integrate MDM and ERP initiatives are the enterprise content and data management structures (Figure 3). Figure 3 The content governance model defines the amount and type of data required to operate each business function. Enterprise content management establishes the standards and procedures as to how the enterprise will execute the MDM processes. This results in providing the requirements for the prioritization, sequencing, and timing of data content throughout the enterprise (Figure 4). Figure 4 The data governance model utilizes input requirements from the IT and business functions to align data with organizational functions with business objectives. The data is typically defined by its geographical nature. The purpose of global data is primarily for strategic sourcing and planning. Regional data is for product planning and deployment into local markets. Local data is primarily for indirect sourcing and local sales promotions. This results in well-defined data parameters for the business function to utilize and makes data transacting more efficient (Figure 5). 5
High-level solution Figure 5 Information management Information Management (IM) capability resulting from the efforts of content and data governance includes tasks to plan, design, implement and monitor data in applications that confirm the fitness of data for use across the enterprise. The business objective of IM in an ERP initiative is to produce high quality master data that can be distributed throughout the enterprise for applications, analytical tools, and directly to business stakeholders. IM in the master data organization is primarily driven by the data governance model and includes the lower level tasks of the model. Essentially, it is the information quality and data migration efforts that are the dependency for the ERP implementation. These two components comprise the future state data design that will provide the operating framework for the master data organization (Figure 6). Figure 6 6
High-level solution Business processes and data definition Standardized business processes have been developed across industries over the years. They have become the building blocks for many sublevel process developments. Most organizations have employed some degree of these processes with varying degrees of automation. Beginning the master data initiative with key level 2 business processes defines the scope of the master data organizations responsibility (Figure 7). Source: Deloitte Consulting Figure 7 These processes will impact key data elements in the CRM, ERP, SCM, etc. applications. Within the master data domain, these critical applications are integrated with master data tables and data elements. Using the ERP application as an example, since it utilizes master data to perform business transactions, there are four main data domains for a global initiative (Figure 8). Figure 8 Designing cross functional processes to the task level, identifying the data fields to control and defining them with global, regional, and local responsibilities will provide the detailed level necessary to manage the master data properly. 7
Solution details Solution details Master data domain There are multiple technology solutions available to hold, integrate, and analyze master data. The more sophisticated the technology solution the more cost that is connected with it. In general, efforts should be made to have a data domain(s) to retain the master data with selectively synchronized information exchange between the appropriate applications. Organization maturity Introducing a global master data management initiative requires a reasonable level of maturity. It is not necessary to be at the high-quality maturity level. Certainly, a Level 1 will add a lot more effort to the initiative. However, starting at a Level 2 with a target of Level 3 is a reasonable maturity to build from (Figure 9). Figure 9 The applications domain that determines the difference between a Level 3 and Level 4 is essentially moving the master data from a transactional application to a specific data only application (Figure 10). As the maturity level increases, the number of data integration between application increases. However, by segregating master data to specifically developed data applications will improve management capabilities and security of the data. 8
Solution details Figure 10 The enabling technology selected for this architecture establishes the baseline definition of the data model and data. Data model A well-defined data model defines the location of data elements and the relationships among them and how the data elements can be accessed. In either a Level 3 or Level 4 maturity the source system, target system, and data element definition should be diagrammed (Figure 11). Source Transformation (If required) Target System name Field name Table name Data type Data length Migration frequency Description Location Algorithm System name Field name Table name Data type Data length Figure 11 This model will facilitate the constructions of the technical specifications and development and testing of the conversions and integrations. It is also fairly common that item, customer, and supplier numbers and descriptions will require some level of transformation to become harmonized across the global footprint. Data governance approach It is necessary that a cross functional MDM organization is created with executive-level sponsorship. This is to maintain the timing and quality of the master data lifecycle. The size of the organization is directly related to the volume, quality, and complexity of data to be managed. Global governance model The global governance design is centered on a model, which can provide a basis for defining business processes, infrastructure, and configured software to meet the majority of an organization s common global requirements while leaving room for localization during rollouts. 9
Solution details The governance model is made up of: High-level approach strategy A scope of responsibility A centralized organizational structure with responsibilities at the global, regional, and local level A common rollout strategy is necessary to attain the business objectives and benefits associated with it. Application Program Integrations (API) defines the technical scope of the global model (Figure 12). Approach A common global implementation model is required to attain the majority of the supply chain and financial improvements from business case benefits associated with it. Application Program Integrations (API) defines the technical scope of the global model as 80% fit of the global requirements. Result Standardized and compliant processes Common technology Enables regional and global growth strategies Knowledge sharing and transfer Figure 12 The scope of the global model incorporates key business functions built on a foundation of transformational change, information technology, and master data. These are the key business functions of ERP initiatives (Figure 13). Figure 13 The three foundation platforms require global representation and sponsorship within the enterprise to minimize regionalization of the model. Once the foundation is established, the business within the global initiative can operate in an autonomous environment networked together by organization, technology, and data resulting in sustainable and consistent business operations supported by organization sponsorship. 10
Solution details Master data management organization The MDM organization is aligned to the global governance structure and functions similar to a matrix organization model as it matures. This organization consists of global, regional, and site representatives with reporting responsibilities to each. The primary responsibility of the MDM organization is to manage, coordinate, support, and deliver global, local, and regional business initiatives within its scope (Figure 14). Figure 14 The purpose of managing master data by geography is to provide: Consistency of data between geographies and business units Global standardization of master data driven from the top down Improved automation of data processing Information management IM in an ERP initiative is primarily focused on data information quality and data migration. Prior to initiating the information improvements, a risk and impact assessment should be conducted. The objective of the risk assessment is to identify risks posed by data quality issues. The objective of the impact assessment is to identify the business impact caused by data quality issues and remediation activities needed to address them. These assessments will inform decisions on the extent of remediation and cleansing required. The data quality risk assessment defines the overall risks posed by data quality issues. It evaluates potential risks in specific categories i.e., financial, compliance, governance, operational, etc. It defines the master data component, the data source, and the level of risk to the business associated with it. The primary drivers for risk are: Data volume Regulatory requirements Audit controls A risk assessment should be conducted on each master data component impacted by the ERP initiative. 11
Solution details The data quality business impact assessment documents the impact of data quality on the business in regards to resources, effort, and organizational impact. It evaluates potential risks by geography, location, department, etc. It defines the master data component, the data source, and the level of risk to the business associated with it. It defines the master data component, the data source, and the business functions associated with it. The primary drivers for risk are: Level of automation Number of users Impacted processes An impact assessment should be conducted on each master data component and key business function included in the ERP initiative. Information quality Information quality addresses the value, usefulness, accessibility, and security of an organization s data and information assets. It includes tasks related to data and information requirements, standards, management, and security and controls (Figure 15). Source: Deloitte consulting Figure 15 In the initial plan phase, a detailed assessment is performed across many applications to determine the data accuracy and any gaps that exist. This is followed by a review of the data requirements across the enterprise. In the design phase, the data cleansing and migration plan is assembled for each geography. Timelines are determined to minimize data conflicts during transaction processing. This includes any functional specifications for conversion programs. During the build phase, the cleansing activities take place. This usually impacts the global, regional, and local team members. This activity consists of initial validation testing with the business applications and the testing of security accessibility. The testing consists of processing the cleansed data through the key transaction processing for the facility utilizing detailed testing scripts and appropriate success criteria. Any technical updates to data in mass volume and security deployment occur in the deliver phase, including detailed validation testing. Typically, these mass updates occur over a limited time span to minimize any disruption to the business. Additionally, data metrics are deployed to monitor the success of the update. Finally, during the operate phase data quality reports are monitored and any final adjustments are made before the global deployment begins. 12
Solution details Data migration The objective of master data migration is to identify the logical structure for the master data in scope. This includes geographies, alignment to business processes, and defined values for user entry. The identification, design, and development of conversions and interfaces are based on this effort (Figure 16). Source: Deloitte Consulting LLP Figure 16 The process of globalizing data consists of identifying requirements, verifying the completeness of the data, and analyzing the data accuracy and integrity. This can provide consistent and reliable information exchange between businesses. The sustained results of standardized data can provide: Centralized supplier and item creation policies Data-driven automated processes Global general ledger (GL) In the plan phase, the global, regional, and local data sources and requirements are defined. This begins the process of aligning data across the global footprint and can require additional business support as it relates to product introduction timing and inventory relabeling. During the design phase, the data synchronization plan is developed with the conversion and integration specifications. These specifications should utilize a consistent template or organizational standard to enhance the efficiency of the development cycle. The synchronization configuration provides documented rules and logic for harmonizing master data across the source systems. The build phase develops and tests the conversion and integration programs and the businesses across the enterprise initiate the inventory, customer, supplier reliable, and communication process. The testing consists of processing the harmonized data through the key business processes across enterprise utilizing detailed testing scripts and appropriate success criteria. This testing should be in coordination with the ERP testing phases and follow the same methodology. In the deliver phase the harmonization process occurs. At this point the global data for items, customers, suppliers, plants, and financial data gets deployed and the business units begin to use the global elements. Depending on the business units involved and the magnitude of change that can occur, this phase can take a significant amount of time relative to the other phases on the migration process. The organization of MDM will be highly complex and challenging until the harmonization effort is integrated. During the operate phase, the full MDM team assumes control of the master data and the policies and master data business processes are initiated. 13
Solution details Business processes and data definition MDM processes should be treated as key to the business. Modifications to data can occur across the organization at any time. Process must be robustly designed to consider master data release, synchronization, and obsolescence within many facilities. As with any process, they should contain well defined tasks, owners, and performance measures. In addition, master data processes require approvals from the appropriate global, regional, or local representatives. The typical master data process includes a request, an approval process, and the update (Figure 17). Figure 17 This process will take different paths depending on if the data is global, regional, or local. Local updates are typically the responsibility of the local team, regional data the regional team, and global data the global team. Create and maintain customer master data This is the overall process of requesting and creating and maintaining customer master data to establish global, regional, and local relationships. Customer information is collected from various channels and is ultimately located in the customer information domain. Sales input is the primary source for information. Local attributes include contact names, phone numbers, local reporting codes, etc. Regional data includes country-specific data such as tax codes, bank information, regional reporting codes, etc. Global data includes creation of the customer number, terms, business unit assignment, etc. (Figure 19). The review process is coordinated through the customer master data organization and the updates are performed by the owner of the data. Create and maintain material master data This is the overall process of requesting and creating and maintaining material master data to establish global, regional, and local relationships. Material master information is primarily developed through the product lifecycle management process and is typically segmented by finished goods, subassemblies, raw materials, and incorporated into bill of materials. This process is managed through utilizing revision levels and effectively dating so it can be managed across the entire supply chain. Local attributes include costs, local planning parameters, warehouse locations, local inventory parameters, etc. Regional data includes distribution planning parameters, business unit assignment, bill of material definition, regional segmentation codes, etc. Global data includes supply chain planning parameters, item number creation, descriptions, global segmentation codes, etc. (Figure 19). The review process is coordinated through the material master data organization and updates are usually time dependent. Create and maintain supplier master data This is the overall process of requesting and creating and maintaining vendor master data to establish global, regional, and local relationships. The creation and maintenance of vendor master data should support each function's business drivers, which can provide synergies across affected business areas and benefits the organization as a whole. Local attributes include indirect supplier information, contact names, phone numbers, local reporting codes, etc. Regional data includes bank 14
Solution details information, tax codes, regional reporting codes, etc. Global data includes creating the vendor number, terms and conditions, business unit assignment, etc. (Figure 19). The review process is coordinated through the vendor master data organization and the updates are performed by the owner of the data. Create and maintain employee master data This is the overall process of creating and maintaining vendor master data to establish global, regional, and local relationships. Employee data is used to support time reporting, item assignments, reimbursement processing, etc. (Figure 19). The HR function typically coordinates and owns this process due to potential confidentiality conflicts. Create and maintain plant master data This is the overall process of requesting and creating plant master data to establish global, regional, and local relationships. Plant data supports the operations in new and existing facilitates in a timely manner. It can include a new company creation, the business unit definition, COA incorporation, etc. (Figure 19). The review process is coordinated through the finance and business unit master data organization and the updates are performed by the owner of the data. Create and maintain financial data This is the overall process of requesting and creating financial configurations to establish global, regional, and local relationships. This process starts with the global COA design to define the GL for the enterprise. The COA size should be kept to a minimum and subledgers and reporting codes should be used for enhancing the detail and analysis of object accounts. Managing the GL includes the activities related to designing, implementing, and maintaining the accounting framework. This includes coding structure, interrelationships with primary information gathering systems (e.g., accounts payable, accounts receivable, payroll, fixed assets, etc.) and such GL structures as the use of single or multiple COAs and the use of subledgers. Some additional financial master data elements include profit centers, cost centers, equipment masters, cost elements, customer, and vendor financial views should be built into the account level detail (Figure 18). Figure 18 15
Solution details Define and maintain customer groups and hierarchy This is the overall process of requesting and creating customer hierarchies to establish global, regional, and local relationships. Customer hierarchies are based upon the legal structure of the customer. The creation of the customer hierarchy is typically owned by the global or regional team to minimize duplicates, coordinate contact information, and define pricing parameters. Local data attributes are usually limited to local reporting parameters. Regional and global data include creation and changes of the hierarchy, account assignment, report parameters, etc. (Figure 19). The review process is coordinated through the customer master data organization and the updates are performed by the owner of the data. Define and maintain vendor hierarchy This is the overall process of requesting and creating vendor hierarchies to establish global, regional, and local relationships. Vendor hierarchies will be based on the legal structure of the vendors. The creation of the customer hierarchy is typically owned by the global or regional team to minimize duplicates, coordinate contact information, and define certification. Local attributes are usually limited to local reporting and quality parameters. Regional and global data include creation and changes of the hierarchy, certification parameters, rebate management, report parameters, etc. (Figure 19). The review process is coordinated through the vendor master data organization and the updates are performed by the owner of the data. Release and rollout new products/changes to existing products This is the overall process of releasing new products or changes to existing products to meet customer requirements. This is the last subprocess in the product development cycle and can include product obsolescence. Prior to the process, analysis development and prototype testing have occurred including items, bill of material, routing, costing, storage, and transportation designs potentially incorporating the previous processes. The release process is coordinated through sales and marketing with support from the entire master data organization. Any updates occur as a result of a combination of customer requirements or cost savings. Data elements Within the customer, vendor, item and plant data masters there are hundreds of possible data elements that can qualify for incorporation into the data management organization. Typically, any element that is not defined as global or regional defaults to local ownership and the site can determine if they need to utilize any specific element that remains. Once a data element is classified geographically, it is flagged in the data master domain accordingly so the applications supported with master data are aligned to the classification. Identifying data elements this way will enable the MDM organization to limit and control the attributes. 16
Solution details Figure 19 17
Business benefits Business benefits There are many potential areas of soft cost reduction areas once proper MDM is exercised. This can be measured through customer service level improvements, inventory turns, productivity gains, revenue per employee, and reduced cost of goods just to name a few (Figure 20). Source: Deloitte Global Benchmark Survey Figure 20 Within the scope of an MDM and ERP initiative the business drivers can be directly impacted and improvements can be recognized in as little as 3 years. In addition to the hard benefits it can also enhance customer and supplier relationships by providing improved data accuracy and content (Figure 21). Source: Deloitte Consulting FIT template benchmarks Figure 21 18
Conclusion Conclusion With a broad approach to data management, an organization can position itself more competitively and take steps towards improving customer and supplier relationships. The key components of an effective management initiative include: Domain Governance Information management Business processes In organizations where data is not recognized as a key business driver, order fill rates, revenue per employee, item costs, and the cost of quality may lag behind high performing companies. For enterprises with a global footprint or expanding into one, MDM can help them in their efforts to sustain business activities and provide the foundation for growth and acquisition. 19
About Deloitte Consulting About Deloitte Consulting For more information, please contact: Rick Olson Specialist Leader Deloitte Consulting, LLP 550 S. Tryon Street, Suite 2500 Charlotte, NC 28217 +1 704 277 7044 rolson@deloitte.com Luke Tay Specialist Leader Deloitte Consulting, LLP 191 Peachtree St, NE #2000 Atlanta, GA 30303 +1 404 631 3790 luketay@deloitte.com This publication contains general information only and is based on the experiences and research of Deloitte practitioners. Deloitte is not, by means of this publication, rendering business, financial, investment, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte, its affiliates, and related entities shall not be responsible for any loss sustained by any person who relies on this publication. About Deloitte Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms, each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed description of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Copyright 2012 Deloitte Development LLC. All rights reserved. Member of Deloitte Touche Tohmatsu 20