Finance organizations often face this dilemma: No matter how extensive they make their global chart of accounts, how much dimensional detail they add to their financial-reporting application, or how many datamarts they create to satisfy various analysis needs, it's never enough. Ironically, this problem continues even with new, powerful, better-integrated products from business performance management (BPM) software vendors.

Current BPM solutions can provide tremendous benefits by accommodating an extensive number of data dimensions and improved meta-data coordination between products, enabling users to analyze and drill down on greater volumes of related data. But despite this advanced functionality, organizations often continue to have data-quality problems because of overlapping BPM applications, operational systems, and various datamarts. This problem is exacerbated when managing data quality across different software vendors and between operational and analytic application types.

Ideally, each related BPM and operational application should support its intended purpose, the meta data of each should be coordinated, and this type of overlap shouldn't exist. But it does.

Centralizing the organization of data while decentralizing its use is a fundamental objective. Once this is achieved, users can leverage multiple coordinated, task-specific applications and data sources without having to deal with data-quality problems resulting from duplication. A growing number of organizations are viewing this challenge within a larger master data management (MDM) context and looking to processes and tools that support this approach.

MDM involves the creation and maintenance of a persistent master list of meta data from participating applications to create a common method for cross-application information retrieval. In short, MDM allows data from various sources to be analyzed as if they existed in a single system.

For example, assume a key performance indicator, a financial account, and a budgeting line item refer to the same item of actual data but have three unique names. Assume the same account data exists in related G/L source systems, but it's contained in multiple transactional accounts that are named a bit differently to accommodate a specific account header that was added as a result of a quick fix during a recent acquisition.

An MDM solution would create a "super set" application that includes the meta data from each participating application, relate the meta data in each application to one another, and provide functionality to maintain these relationships in the future. It sounds like a quick-fix, but it's not; in fact, it's common for organizationwide MDM endeavors to get stuck near the starting line with overly expansive project scopes. As a result, best practices espouse an incremental approach to MDM while establishing an organizationwide vision.

Fixing Finance First

Because of the finance department's growing need for enhanced analytic capabilities, its unique position at the control panel of expanded BPM systems, and its role in regulatory compliance, it can be the ideal place to begin a comprehensive MDM program.

Starting here would address several problems:

• Finance is in need of applications that both summarize operational results and provide drill-though to multiple operational systems. The speed at which such analytic ability is required often results in the urgent expansion of existing BPM applications or the rapid creation of additional datamarts. Both approaches can result in redundant data stores and related data-quality issues.

• Even if overlap isn't an issue, the financial application in use may have become too unwieldy to manage from a data-administration, performance, workflow or security standpoint if it becomes used for something other than what it was intended for.

• Extensive requests for calculations and analyses that use the financial reporting product's business rule engine can result in a situation in which the reporting application becomes too complicated to incorporate end-user requests for necessary functionality.

These issues can become more problematic now that many organizations have documented their cross-functional workflows in accordance with Sarbanes-Oxley 404 regulations and want to strengthen these controls through enhanced automation. Also of great concern is the risk that financial-reporting applications burdened with too much data can cause a lack of focus on the key financial information that must be treated in accordance with Sarbanes-Oxley compliance rules.

Several MDM products currently are available to address these needs; however, how should MDM initiatives be approached?

Your MDM approach should be considered as evolutionary from the start because the MDM application will need to adapt to changing end-user requirements and accommodate new source systems and a variety of methods to access different applications.

Starting with the most identifiable application overlap problems can be the best way to begin; however, if your organization is ready for it, your MDM approach should become part of a new or an essential part of your existing overall data-quality improvement program throughout the organization. Although these considerations can make an MDM initiative seem daunting, starting small and gaining consensus by addressing one application's data-overlap issue at a time will make the effort more manageable, ROI easier to measure, and sponsors easier to find.

The Path to Decentralized Data

The concept of centralized data may be familiar because accounting best practices dictate the need for an organizationwide adoption of a global or master chart of accounts (COA). Organizations with different types of operations need to use their own account variations; however, these unique accounts must be mapped to the master COA in order to produce comprehensive financial statements for the entire organization.

The management of the master COA often requires a centralized, authoritarian approach. Any effort to determine an appropriate level of detail in financial reporting applications is closely linked to an analysis of the COA, other financial analysis applications, and future reporting needs.

The need for a managed meta-data environment outside of the finance function requires much flexibility. Users from other areas often need to develop their own analysis applications. This is possible as long as a standardized approach is used in defining the master data for the organization as a whole. Once that has been done, the meta data from individual applications can be mapped to this master data and subsequently maintained. This approach allows the users of "participating" applications to use their own meta-data definitions, whatever is most intuitive to them. In doing this, both flexibility and standardization is possible. In other words, this "virtually centralized" approach allows for managed centralization. The task of balancing application complexity and data analysis needs becomes one of centralizing the master meta data while managing the meta data of multiple decentralized data sources to allow end users to leverage them as effectively as possible.

In our previous scorecard/financial reporting/budgeting/G/L example, our master-data "super-set" application would include an agreed-upon master list of meta data definitions that includes the one master definition of the data item shared among the four applications. This would allow for a common method of data access, avoiding data duplication because the master data software tool will understand and track that relationship and will prevent the three participating applications from maintaining different data values. Source systems such as the G/L also can participate. The MDM tool will maintain these relationships and notify the business user of any violations so that they can be corrected on an ongoing basis.

An added benefit of the MDM approach to this problem is that it can be expanded to include additional applications and functional areas as the organization's MDM program expands. Long-term master data success will require a comprehensive approach to the organization's analysis and data-quality needs. Your approach will need to be determined by many factors, including organizational goals, capabilities, culture and many other factors. But the primary focus should be on your most immediate problems and applying MDM programs to overcome them.

5 Questions To Determine Your Need for an MDM Approach 1. Do your applications contain data that overlap with other functional areas, resulting in data-quality issues? 2. Do your BPM applications fail to satisfy your financial analysis needs either because they house too much data or because you can't access related information from other systems? 3. Is workflow automation difficult to automate across applications and functional areas for Sarbanes-Oxley 404 compliance purposes, and does that increase your Sarbanes-related costs? 4. Do your financial analysts have too many data administration tasks, and do these tasks slow the financial close cycle or significantly increase your department's costs? 5. Is it difficult for your IT area to quickly satisfy new analysis requests with flexible, enduring solutions? Answering yes to any of these questions should prompt you to consider a Master Data Management (MDM) approach. Although the consideration of current and future overall organizational needs is necessary, the identification of immediate problems that MDM can alleviate often is the best way to begin.

Chris Iervolino is a senior managing director at ITEC Consulting Inc., a BPM consulting organization specializing in all aspects of corporate performance application design, implementation, and integration.

William K. Thomas is a senior managing director at ITEC Consulting Inc. and a leading expert in financial process redesign and financial system implementation.