The best of data governance

Contents3 Executive summary

5 Data governance framework

7 Evolution of data relationship management

8 What makes good data governance?

Common terminology

Integrated applications

Mapping

Hierarchies

Change management and workflow

13 Data governance in action

Chart of accounts

Acquisition onboarding and scalability

Sales and organization hierarchies

16 Conclusion

Executive summaryThe best of data governance

A good place to start is with your structured financial chart of accounts data. Managing internal financial structures and extending to other operational areas — product definition, customer grouping, HR employee roll-ups and sales organization definition — enables you to achieve value-driven predictive and prescriptive analytical functions. The key to mastering data is not necessarily in the data itself, but how you relate it to the proper business context of what the data represents. Without the structures and hierarchies that are used for categorization and reporting, a piece of transactional data has no connection to the meaning of how your company uses the data. For example, an employee’s name can be used for HR purposes, while the same employee’s name can be used as part of a sales team that covers branch locations or pursues new customers.

Proper governance will enable change in the organization and alignment of processes to support business analytics. However, too much discipline can be restrictive and can sacrifice the agility and ability to support varying requirements across the enterprise. There is a point of optimal data governance that you should aim for (see Figure 1).

Obtaining value from business analytics and cloud services requires perspective and discipline. Grant Thornton LLP believes that data governance drives effective analytics and you can’t be effective in one area without the other. Mastering internally owned content is an important step to providing the ability to evaluate external sources of content as part of the big data evolution.

Figure 1: Business impact of data governance

Minimumdata governance

Amount ofdata governance

Negativebusiness impact

Busin

ess

impa

ct

Point of optimal data governance

0

Diminishing return

Source: Oracle Big Data Handbook, Oracle Press, 2014.

4 The best of data governance

Data goverance should be applied to both financial and nonfinancial areas and be part of the roadmap for getting value from big data (see Figure 2). Managing business hierarchies and data relationships with effective controls is the first step to good business analytics. The structured data sets, which cross financial and operational functions, will bring the proper context when merged with external customer data and related unstructured sources of information.

This white paper highlights data governance practices that were applied to leading companies and varying business functions to provide for structured data to be related to unstructured data. We’ve applied these practices and related solutions for over a dozen years, and evolved with enhancements in technology, corporate governance processes and government regulations. The best of data governance is intended to leverage existing investments in infrastructure platforms, business intelligence (BI) and data warehousing to provide the right level of governance to expand into big data.

Figure 2: The road to big data

• Information discovery

Structured data

Unstructured data

Big data

• Prebuilt analytics• Foundation analytics

Governance and integration

• Financial consolidation• Budgeting and forecasting

• Profitability and cost management

Data governance framework

Leading companies take the time to put a data governance framework in place. A framework should be relevant to both their business strategy and application footprint, and enable process improvement. To use analytics for competitive advantage, you must balance procedures that enable higher-quality data controls with maintaining agility for varying business stakeholders. A company’s framework should allow for data to be optimized for both corporate standards and local/divisional use.

Grant Thornton’s position on data governance enables interdependent solution components to provide for disparate operational processes and performance management applications to work together as one unified solution. As such, a company with various business-specific applications can utilize data governance principles to bring the pieces together into one single solution, while providing for a distributed change management solution across a diverse set of business stakeholders.

Terminology and hierarchy of data, change control and multiple versions of data

Processes for the workflow, maintenance, protection (security), support of organizational information

Tools/technologies related to software applications,

data synchronization and integrated data

architecture

Competencies and organizational structure to

support information delivery

Strategy

Measures

Structure(Terminology and hierarchy)

Process(Workflow, controls and maintenance)

Architecture(Technology and protocols)

People(Competencies and execution)

Figure 3: Data governance framework

6 The best of data governance

Furthermore, a data governance framework establishes strategies, objectives and policies for effectively managing an organization’s data. It consists of the people, processes, structure and architecture required to manage the availability, usability, integrity, consistency and auditability of secure data. A well-implemented data governance framework will transform data to information and ultimately knowledge, which will enable repeatable fact-based decision-making.

A data governance framework has the following characteristics around the data:

• Includes definitions of term, metrics, items, customers and related elements (Structure)

• Distinguishes dimension values from the analytics of hierarchy definition (Structure)

• Makes/collects/aligns rules (Process)

• Assigns accountabilities to resolve issues (Process)

• Organizes data stewards and governance bodies (People)

• Monitors/enforces compliance while providing ongoing support to and change management for broad stakeholders (Architecture)

The need for data governanceWe have worked with companies that struggle with operational issues related to growing the business, compliance and regulatory pressures, and restructuring the organization. Implementing data governance can help these companies deal with the issues by helping them manage change more effectively.

We recommend the move to formal data governance when one of these five major changes occur:

1. Traditional management cannot address cross-functional activities as the organization has grown.

2. An organization’s data systems get so complicated by numerous functional activities that multiple definitions of common business entities begin to permeate the data systems.

3. Regulation, compliance or contractual requirements call for formal controls to ensure data integrity and avoid risk.

4. An organization’s data architects, service-oriented architecture teams, or other horizontally focused groups need the support of a cross-functional program that takes an enterprise (rather than siloed) view of data concerns and choices.

5. Organizations wish to empower decentralized management of the business under a parameter-based overall governance framework.

Consideration of the company’s overall objectives is essential to effective data governance. Understand what your business needs from its data, then use that knowledge to create a data governance framework that directly ties into those needs. Governing data requires a rethink of your operating model, with new roles, responsibilities and processes emerging.

Evolution of data relationship managementOracle Data Relationship Management (DRM), a leading data governance solution, has been around for more than 15 years and had its beginnings in the pioneer days of master data management. DRM was originally developed to allow very acquisitive companies to deal with the high rate of change that goes along with constant reorganization. While these companies initially used spreadsheets to do the premerger planning and postmerger mapping, they quickly realized that without a repeatable, business-user driven process, the success of the acquisition was at risk. The initial release of DRM provided this acquisition framework, but its configurable, multidomain model allowed it to also be used for ongoing master data and hierarchy maintenance as well. By its second release, it was a full-blown governance application that was being used to manage all master data domains and hierarchies at the enterprise level.

Today, the average DRM customer manages 9+ data domains within DRM, including the chart of accounts, products, employees and customers. A few years ago, DRM was expanded to include a formal data governance module that fully supports the RACI matrix for data governance standards, and allows requestors, stewards and approvers to participate in workflows around master data and hierarchy change management.1

Grant Thornton’s Business Analytics team has been using dimensional modeling concepts and functions that are now part of Oracle’s DRM for over a dozen years, since deploying a global solution at one of the world’s largest alumina manufacturers. We implemented a data governance solution to manage financial, customer, and vendor change control procedures, while reducing audit costs and providing controls to reduce risk. The client benefited from the solution with (a) the ability to close the books in three business days and be the first to report earnings on Wall Street; and (b) a two-day reduction in days sales outstanding and over $1 million in annuity savings, among other results. Since this initial project, the Grant Thornton team has implemented more than 100 Oracle DRM solutions. We draw from that experience to describe the common functions that have been used in leading data governance solutions.

1 See section “Change management and workflow” for more information on RACI.

8 The best of data governance

Common terminology Without a common language, data cannot communicate successfully across systems and people can’t be optimized to improve organizational processes. When dealing with multiple, disparate applications — regardless of the number of software vendors or products involved — terminology matters. It’s meant to link processes and applications, but that linkage is not always easy to accomplish. Business terms referring to accounts, products, customers, employees, geography and other domains may vary across the transactional or BI applications. Additionally, some systems may have a finer level of granularity, adding more complexity to building clean analytics.

What makes good data governance?

Organizationand process

People

Product

SuppliersCustomers

Financials

People

ProductFinancials

Figure 4: Terminology across functions

Companies need a common language for systems to adopt in order to relate. As information is shared across enterprise performance management (EPM) and transactional ERP systems, this common language — defined by agreed-upon hierarchies and attributes — creates business context for how a company performs analytics. It is acceptable to have different terminology for various applications, but the differences must be linked through hierarchies or mappings to provide effective business analytics.

Integrated applicationsERP, EPM, BI applications and a customer-specific data warehouse all serve different business functions. But as part of the integrated technology platform, you need to establish governance and define the hierarchies that will be used across different applications in order for them to work together. For example, total revenue by month for external reporting should relate balance to total revenue by location and product for that same month. Furthermore, alternate hierarchies for data should be shared with the appropriate applications that require the analysis.

Oracle functionsIn the Oracle ecosystem, Oracle DRM can serve as the host and origination of the chart of accounts for ERP systems. However, this is not an absolute mandate; the transactional system can be the originator. It does not always matter which system hosts the chart, employee or sales structure, as long as there is a means to manage alternate hierarchies of the business for analytics, and that the appropriate system attributes are captured for each application and process to effectively communicate. Additionally, there should be a single point of entry, with controls over the entry process, and automation between transactional systems and the data governance solution.

The use of master hierarchies in a data governance solution can reduce maintenance and improve analytics for disparate EPM and BI applications. Specifically for Oracle Hyperion-based applications that predominately report financial trial balance information, a data governance solution can be used as the shared library to store all business dimensions for the vendor, customer, product and chart of accounts. The Hyperion-specific dimension repository manager provides the application-specific libraries, using the same hierarchies for summary trial balance and journal detail across multiple EPM and BI applications, or other databases can be deployed.

An important concept to note: For prebuilt BI applications where the data warehouse is provided out of the box, there are account groupings created for balance sheet and income statement reporting. Grant Thornton uses an accelerator with DRM to reuse financial account groupings so that hierarchies are managed once in DRM for use across multiple EPM and BI applications. This enables varying applications to have the same structures of data even if they go to a finer level of detail. This approach provides for increased transparency, reduced data reconciliation effort and a high level of auditable data.

Explore your options Consider your business structure and complexity, the systems and processes already in place, and your reporting needs. One approach might be to source all hierarchies and dimensions from a data governance solution that pushes to transactions, BI, EPM, etc. Another option is to have ERP host new accounts or products, then determine and load net changes into DRM. DRM augments the hierarchies, adds hierarchies, provides attributes, and then shares information with downstream applications (data warehouse, EPM, BI).

Most companies desire a single version of truth and try to achieve that objective through deploying function-specific applications that provide a certain level of content that expires with the passing of time. Other companies have built data magnets or data warehouses to store large volumes of detail and summary data. Grant Thornton recommends a paradigm shift to consider the use of data governance processes and technologies as the mechanism to obtain a single version of truth for multiple stakeholders.

While you can buy the latest and greatest software, without a data governance solution or a light version of governance, the applications won’t connect to each other. After a labor-intensive, manual process to synchronize the data — a short-term solution — you can have the truth for only a point in time. You need the right integrated applications, methodology and governance process to control the data and reduce risk.

Govern

Rationalize

ShareControls Hierarchystructure

EPM• Planning• Consolidation• Profitability

EDW• Subject area marts• Source marts

ERP• PeopleSoft• eBusiness• JD Edwards

BI• OBI financials

analytics

Figure 5: Data governance integrates applications

10 The best of data governance

Business unit

Department

Account

Affiliate

Operating unit

Operating unit affiliate

Project ID

Product

Subproduct

McKesson, EBS, Macola, Meditech

Mapping Mapping relates to differences in names (cost center, department, accounts, product, etc.) between applications, which occurs for a number of reasons:

• Converting or upgrading from one ERP to another

• Redefining a new corporate chart of accounts

• Acquiring a new company

• A subsidiary entity is not part of the standard ERP

• Applications are developed for business unit driver specifications

In many cases, the mapping or scrubbing of names is bundled under a transformation process called extract, transform and load (ETL) procedures, which is owned by IT. However, the names and organization of the new members are known best by finance, sales management, product management or other functional areas of the business. Organizations have a real opportunity to enable the business to define the terminology and structure that supports business analytics, which can then be shared with IT systems. This opportunity is particularly important for audit and government regulations in providing controls on changing certain types of data.

• Represents highest-level organization of recorded business information• Creates and provides multidimensional reporting

Corporate code

Department/ cost center

Account

• Smallest budgetary unit• Described by function

• Defines transactional classification• Natural account (monetary and/or statistical)

• Ties to business unit• Balances intercompany transactions automatically

• Regional designation• Matches operational flow of the organization

• Ties operating unit• Balances intercompany transactions automatically

• Captures cost collection activities with a beginning and end date• Additional project chart fields are available to track project attributes/tasks

• Defined by standard DRG codes• Used to classify patients based on service and procedure

• Tracks ICD-9 code and rolls up to DRG code

PeopleSoft FSCM DRM

Figure 6: Example of mapping

Oracle functionsOracle provides a data load and data transformation mechanism that is typically used by finance administrators called Oracle Financial Data Quality Management (FDQM). This application typically manages the data load and, if necessary, the data mapping of multiple general ledger accounts and related systems. The benefit of the FDQM application is that finance departments have a flexible means to load and map data for external financial reporting purposes. However, this mapping is purpose-specific and would need to be recreated for other uses. Other business applications would need to set up processes to remap the data. Oracle provides a robust ETL tool called Oracle Data Integrator for financial and nonfinancial mapping and transformation of data across the enterprise. In this case, the IT professional has to perform the definition and code updates for the remapping.

Regardless of the technology used, the data relationship and mapping of business dimensions can and should be defined by functional business teams, with controls in place for executive approval, while providing the logic to IT to automate. To avoid the remapping process, Grant Thornton recommends using DRM to define the business logic and provide the mapping definition and controls, which are then automated for use by FDQM, Oracle Data Integrator, or any transformation technology.

HierarchiesData governance should distinguish between and provide specific processes for both (a) dimension or chart of accounts values, and (b) hierarchies. The values have specific characters that are required for use within a customer relationship or ERP transactional system, where hierarchies provide the information for reporting. Hierarchies give you the context to understand data — big or small. Businesses have many applications that serve different purposes: planning and budgeting, workforce planning, capital asset planning, sales force analytics, HR retention analytics, general ledger, accounts payable analytics and inventory reporting. These applications may have different hierarchies and levels of detail for good business reasons and application-specific best practices.

Below is an example of a product hierarchy where the corporate application shows the level for analysis and Lidoderm, and the transactional system shows the stock keeping units and detailed values that map to the parent product.

Figure 8: Product hierarchy — Transactional system

Figure 7: Product hierarchy — Corporate application

Pain_Brands

Lidoderm

Pain Brands

Lidoderm

01000LID10687

63481-687-01

63481-687-02

63481-687-06

Pain Brands

Lidoderm

01000LID10687 Lidoderm 5%

63481-687-01 Lidoderm Envelope

63481-687-02 Lidoderm (Lidocaine Patch 5%) x 2

63481-687-06 Lidoderm (Lidocaine Patch 5%) x 30

Lidoderm Lidoderm

63481-687-01 63481-687-01

63481-687-02 63481-687-02

63481-687-06 63481-687-06

12 The best of data governance

Change management and workflow The core of data governance is change management through human workflow. The workflow aspect of governance allows requestors to participate directly with the change management process. Without automated workflow, end users typically communicate to data stewards via email or phone calls or Excel templates. Automated workflow as part of governance formalizes the change request process, allowing the rules and flows to be codified and reused.

However, governance is not just workflow; it also includes the concept of the RACI model to help identify roles and responsibilities during a change process.

RACI is an abbreviation for:R = Responsible: the person or group that owns the dataA = Accountable: the person or group that must approve the

requested changeC = Consulted: the person or group that has information that is

necessary to complete the dataI = Informed: the person or group that should be informed

about the data change

Figure 9 illustrates the workflow stages that Oracle supports in the RACI model (the “I” in RACI is supported via notifications at each stage).

Oracle DRM provides a module to configure business-driven workflow so that the right business audience has the information at the right time to approve, while providing the required IT controls to pass strict audit and regulatory requirements.

Figure 9: Workflow stages

Request Approve Enrich Commit

Chart of accountsAs technology evolves, we recommend having the latest ERP functions and support. The chart of accounts can be tested for adoption prior to making a full system refresh. Additionally, the chart of accounts can be migrated with an audit trail to both old and new chart field values. Figure 10 shows an example where multiple charts of accounts coexisted.

A leading health care company used this approach with its new chart. After using the same chart of accounts for over a decade, the company was looking to make a change to their financial reporting and controls process. The CFO wanted to implement a management reporting solution with a new chart of accounts prior to implementing it in the ERP and desired a test drive of the new chart, along with the old chart. This would allow the company to see how the new chart would work for the business as part of the process and prior to upgrading the ERP platform. The implementation of a data governance platform enabled multiple charts of accounts to coexist and provided for the company to ultimately implement improvements in the ERP.

We designed a new chart for this company and implemented Oracle DRM with Oracle BI Foundation Suite and Hyperion. The results: executive and end-user reporting to over 2,000 users, and a new chart of accounts with access to general ledger journal detail, vendor detail and additional accounts payable transactions. Reporting access at the detailed level provided both the old and the new chart values and descriptions to assist with change management and end-user adoption.

Most companies wouldn’t proceed this way. They would follow a textbook method of updating the ERP, implementing the new chart, building Hyperion planning and building out reporting capabilities. However, that approach is capital intensive. In this case, we inverted the solution for our client — and it worked. We ultimately updated their ERP because the management reporting of the chart was such a success.

Upgrade PeopleSoft

Redo COA design

Functional upgrade

Management reporting

ERP ERP ERP BI

Upgrade PeopleSoft

Data governance

Functional upgrade

COA Redesign

Management reporting

ERP BI ERP

Typical linear approach

Enhanced approach

Integrated ERP and EPMProvided management reporting in a new chartof accounts without changing the underlying ERP

Figure 10: Approaches to new chart of accounts

Data governance in action

14 The best of data governance

1. Request COAhierarchy exportfrom DRM

15. Review mappingsand conductdata validation

2.Generate COA hierarchy exportfor subsidiary

10.Add new subGL structure

12.Integrate newDRM mappingsto FDM

5.Create hierachiesin DRM

11.ValidateEPMA structure changes

ODI admin16.Configure ODI

14.Conduct FDMactual load testing

19. Promotesubsidiaryonboardingdevelopmentwork

3. Initiate subsidiary-specific applicationobjects

17. Set up sourceaccess security

4.Populate templatewith ERP values

13. Send FDMfiles to DRM

6. Map subsidiaryCOA to corporate COA

8. Updatemapping

15. Review mappingsand conductdata validation

7. Conduct mappingworkshop

18. Sign off on structures, mapping, security and data

9. Validatemapping files

Acquisition onboarding and scalabilityGrowing and dynamic organizations that are looking at strategic acquisitions should be particularly aware of the capabilities of their data governance solution, which should incorporate M&A functions. To support your growth strategy, you’ll need to enable the organization to take on additional financial systems. The solution should include corporate consolidation and planning applications that reconcile seamlessly to underlying journal and function-specific details. With a data governance solution, mapping and business hierarchy information should be able to relate from the newly acquired company for corporate use. Ideally, using the data governance processes and mechanism deployed, the newly acquired entity should be integrated smoothly into the standard ERP platform.

In our experience, we’ve been able to provide a repeatable process to onboard new companies. For one client, a leading life science organization, we helped create a data process to seamlessly integrate new acquisitions — not just for basic financial statement reporting, which is at the external financial statement level, but also for trial balance level, general ledger journal detail, and vendor and spend data. We helped this company implement an integrated solution with Oracle DRM to be able to link different applications together. We also created an acquisition integration playbook (see Figure 11) that defined steps and processes to onboard a new company. By following this playbook, the client was able to provide financial statement level information within seven days of acquisition and full trial balance information within 30 days of acquisition.

Fina

nce

DR

M a

dm

inIT

Subs

idia

ryG

over

nanc

e

Figure 11: Acquisition playbook example

Sales and organization hierarchiesData relationship management can be applied and used for sales territory and organization definition. For our financial services client, different trading, financial and customer applications are used. Oftentimes hierarchies are shared across these applications, such as team structure, which starts with HR and the definition of employee. However, for revenue-generating and sales management purposes, the employee becomes part of a team that is part of a branch or location. We’ve created multiple hierarchies for this same individual in order to support analytics and decision-making across varying business applications.

Instead of sharing the data relationship between applications, companies often copy and set up redundant information for application-specific uses. Best practices would be to classify how that employee relates to a branch, division, geographic entity and business unit. Then data relationship management should provide sales and organization hierarchies with all the relevant alternate hierarchies that are used to support the analytical needs of other applications.

For example, HR applications use hierarchies that include employee and position structures. Employees may also have a hierarchy for payroll and performance management, which can be different for the employee structure for a sales or product delivery team. Having all of the relevant data elements for an employee is part of data management. Hierarchies for the specific application use should be governed since the relationship of transaction data to your reporting hierarchies will drive your analytics. A data relationship management tool will manage alternate hierarchies used for different applications, and assign attributes and application-specific DNA (codes and symbols for applications). Data relationship governance is the foundation for managing your enterprise-level hierarchies and attributes.

16 The best of data governance

A data governance solution provides for effective change management within departments and across the organization. Organizations can be agile when dealing with growth strategies, including product acquisition and business unit reorganizations. Alignment of people, process and technology can be achieved effectively and in a timely basis with proper data governance protocols in place. The journey to big data begins with mastering your internal content so that your organization has the context to discover trends when external variables are added to the competitive equation. Using information as an asset requires a strong foundation. Without the right data governance, success with analytics may be both expensive and ineffective. The effective implementation of data governance techniques and tools (such as Oracle Data Relationship Management) can provide that necessary control and governance for master data management, while supporting the need for flexibility. With data relationship management, you can achieve both agility and financial reliability through alignment.

Opportunities and benefits can extend beyond the finance function as business measures and hierarchies exist everywhere. Then once governance is established with fundamental structured data, you are on your way to reaping the benefits of advanced analytics — competitive advantage, performance improvement and growth.

The best of data governance, and its principles, will provide the direction to establish the procedures to reduce risk while enabling analytics to drive organizational outcomes.

Conclusion

Joseph ConikerPrincipal, Technology SolutionsGrant Thornton LLPT +1 412 901 5216E joseph.coniker@us.gt.com

Contact

Doug CosbyVice President, Software DevelopmentOracleT +1 512 336 1778 E doug.cosby@oracle.com

ReferencesPeel, Robin; Dwight, Christopher; and Kamath, Rahul. Achieving Agility through Alignment: The Case for Data Relationship Management (DRM), December 2008.

About the AuthorsJoseph Coniker is a principal with Grant Thornton and national practice leader for business analytics. Coniker has over 20 years of experience, including 15 years in Oracle solution delivery. His projects have resulted in over $1 billion in working capital improvements, including account receivable collection, vendor payment, inventory optimization and cost allocation reduction — all of which served as components to delivering increased product and customer profitability, using information as an asset. Coniker is a graduate from New York University Stern School of Business and Harvard Business School.

Doug Cosby, in his role as vice president of software development at Oracle, manages the team that designs and develops the Oracle Data Relationship Management product. He was the founder of Razza Solutions, the company that originally created the DRM product, and has been working in the master data management space for 20 years.

About Grant Thornton LLPThe people in the independent firms of Grant Thornton International Ltd provide personalized attention and the highest-quality service to public and private clients in more than 100 countries. Grant Thornton LLP is the U.S. member firm of Grant Thornton International Ltd, one of the world’s leading organizations of independent audit, tax and advisory firms. Grant Thornton International Ltd and its member firms are not a worldwide partnership, as each member firm is a separate and distinct legal entity.

In the United States, visit grantthornton.com for details.

Content in this publication is not intended to answer specific questions or suggest suitability of action in a particular case. For additional information about the issues discussed, consult a Grant Thornton LLP client service partner or another qualified professional.

“Grant Thornton” refers to Grant Thornton LLP, the U.S. member firm of Grant Thornton International Ltd (GTIL). GTIL and its member firms are not a worldwide partnership. All member firms are individual legal entities separate from GTIL. Services are delivered by the member firms. GTIL does not provide services to clients. GTIL and its member firms are not agents of, and do not obligate, one another and are not liable for one another’s acts or omissions. Please visit grantthornton.com for details.

© 2014 Grant Thornton LLP | All rights reserved | U.S. member firm of Grant Thornton International Ltd

Connect with us

grantthornton.com

@grantthorntonus

linkd.in/grantthorntonus