BI Vendors and Compliance

BI vendors already have the infrastructure to deal with data quality issues, and to monitor those issues over time. Many have also taken regulatory requirements into account to enhance their functionality by adding actual modules or features designed to meet the ongoing reporting requirements of SOX. For example, vendors such as SAS, Applix, and Business Objects integrate SOX compliance functionality into their BI suites.

SAS ensures compliance with SOX by providing the capabilities to assess and validate financial statements with sophisticated reporting and analytics, and to create an audit process with a searchable repository for financial documents, processes and controls. Financial processes are tightly controlled, and reporting cycles are greatly reduced (compared to organizations able to run month-end reports only), due to the structures already in place for cleansing, consolidating, and assessing data. Also, SAS Financial Intelligence allows users to consolidate data from disparate sources more quickly and accurately; track, analyze and report on risks and material changes; and monitor the effectiveness of compliance and governance initiatives.

Applix TM1 has built-in automated logging of all data changes at the user level to provide ongoing audit trails, with the ability to selectively reverse any of the entries. Workflow is also automated to ensure proper review of reports prior to release. TM1 also has the ability to build ad hoc reports, accurately communicating business changes. Additionally, TM1's real time dashboards help management interact with and manage the financial and accounting business components, in an ongoing way.

The finance intelligence analytics of Business Objects give users the ability to view every area of an organizations' financial data, whether from a summary level or a detailed level. For specific SOX audit and control analyses, Business Objects has implemented a Sarbanes-Oxley Analytic Solution, enabling organizations to gain immediate insight into internal controls, policies, and procedures. Additionally, by integrating Crystal Reports into its software suite, organizations are able to perform in-depth analyses of their financial reporting.

Other BI vendors, such as Cognos and Hyperion, have teamed up with consulting firms to provide SOX-specific modules, and to take into account systems requirements as well as business requirements to meet the additional needs of their clients.

Cognos, along with Business Intelligence International (BII), a Cognos Silver Partner, has developed SOX-specific modules to provide clients with the ability to integrate SOX compliancy in the use of their software. These include the SOX scorecard and status reporting module, the SOX work product reporting module, and the SOX analytics module. Along with these modules, Cognos includes data migration activities for loading data from Excel spreadsheets into consolidated databases and prepackaged reports using Cognos Metrics Manager, PowerPlay, and ReportNet. The BII-Cognos solution also has embedded automated testing of reporting audit trails and detection of controls monitoring.

Hyperion has joined with leading business consulting and systems integration firms, including Accenture, Cap Gemini, BearingPoint, Deloitte, and IBM, to help clients meet the financial reporting and auditing requirements of SOX compliancy. Taking into account the essential systems requirements needed to meet SOX compliancy, along with the critical business requirements that can be identified by partnering with a consulting firm, Hyperion has developed an enhanced solution for meeting the needs of its clients. Some of the features provided by BearingPoint-Hyperion are the tracking and visibility of data with corresponding audit trails; event detection and error checking; real-time monitoring of financials; participation by business unit controllers in the certification process; and delegated certification capabilities. Also, performance controls are used to enhance decision making, through a CFO dashboard. System processes are enabled by the sophisticated use of workflow, process management, and the independence of auditing roles and responsibilities.

Other BI and business performance management (BPM) vendors also provide similar functionality to the vendors mentioned above; however, not all BPM vendors have embedded data integration functions, which are essential for ensuring compliance. Without accurate data, the reporting and structures put in place to meet compliance may not be met. Obviously, each organization has different needs when considering a BI or BPM solution. However, when an organization considering SOX compliance evaluates these solutions, data integration and data quality functionality and controls must be taken into account.

How BI Addresses the Needs of SOX Compliance

Traditionally, BI software has targeted the needs of financial decision makers. BI tools initially enabled organizations to analyze financial data, to identify trends, and to drill down on report data to reveal operational transactions, as well as to assign tasks to individual employees, in order to give management the ability to implement robust auditing processes. The driver behind these functions is the ability to capture data from several data sources across an organization, and to centralize them in a data warehouse. Aside from data centralization across the organization, data warehouses allow organizations to implement and monitor data quality activities to ensure accurate data. This reduces the potential for accidental data errors.

BI tools help vendors to meet the demands of organizations that need to comply with SOX regulations, scorecards, and business activity monitoring (BAM). General reporting and analysis functionality permits organizations to take a top-down approach to management, yet still meet SOX compliance. CEOs and CFOs who are responsible for assuring compliancy and who are accountable to the SEC often aren't directly responsible for actual report generation or in-depth budgeting. Task assignment and management of processes are internal driving forces within BI, and help companies manage employee tasks and responsibilities for each financial report and function, as well as ensuring data quality. Basically, BI allows the CEO to manage internal processes and data to meet SOX compliance, and gives CEOs the ability to micromanage tasks at each level to ensure compliance, and to identify any potential errors (as well as identifying who made them, and when they were made within the process). If proper data quality processes are implemented, organizations can guarantee that data errors do not occur within the data warehouse itself and that any key stroke errors and the like are cleansed as they enter the data warehouse, before financial analyses and reporting functions are performed to meet SOX requirements.

Although, as mentioned above, BI software can help organizations meet SOX compliancy, vendors have also taken SOX issues into account when upgrading their product suites to make sure that required standards can be met on an ongoing basis. Even though many other forms of financial reporting software meet SOX compliancy, BI solutions have the added bonus of built-in workflow processes and data integration features to ensure long-term compliancy. Data within spreadsheets can be changed, and structures are not always put in place to manage those changes. However, BI software suites have built-in task assignment and audit functions for managing, distributing, and auditing data (based on where the data comes from, who has ownership of the data, and how the data has been processed).

Using Business Intelligence Infrastructure to Ensure Compliancy with the Sarbanes-Oxley Act

The US Sarbanes-Oxley Act (SOX) of 2002 was established to protect investors from the potential for fraudulent accounting. After the exposure of several corporate scandals, such as the Enron and WorldCom affairs, the US government was compelled to pass legislation ensuring accurate financial reporting and auditing from organizations publicly traded in the United States. SOX affects any public corporation competing in the American marketplace. As a result of SOX, not only have financial controls and reporting schedules become stricter, but responsibility for accurately reporting financial results has been placed in the hands of organizational heads, namely the chief executive officers (CEOs) and chief financial officers (CFOs), to provide accurate financial and auditing data.

This means that financial departments have had to reevaluate the way they manage their controls and reporting. It is no longer possible for organizations to change data without accounting for these changes to shareholders. Now that the responsibility for accurate financial reporting has been placed on upper management, with heavy fines and potential prison terms being imposed for noncompliance, financial analysis tools, such as those provided by business intelligence (BI) vendors, are becoming increasingly important to the financial auditing process. Ensuring proper data controls, proper reporting and auditing structures, and the accurate capture of the ensuing data, are important aspects of SOX compliance and make up the essential elements of BI solutions.

There are three sections of SOX that deal directly with the use of information technology (IT). Section 302 requires management certification that procedures have been put in place to address accurate financial conditions and disclosure controls for all financial statements. Section 404 requires management certification that effective internal controls and procedures have been developed for financial report preparation. Finally, section 409 requires that timely reports be provided to investors, the US Securities and Exchange Commission (SEC), and other corporate stakeholders.

Applying Controls and Audit Emphasis

Recent scandals in the corporate world have created a refreshed awareness of the audit function. One example is the Sarbanes-Oxley Act of 2002 (SOX), which is an attempt to strengthen the integrity of financial reporting. While some may argue that the Act does not go far enough, it is a positive, aggressive start.

While this reemphasis may be good news for current and ongoing systems, the process of developing an audit awareness and the need for substantial controls should be established as software is being implemented. If you are the project manager or the project sponsor, possibly the company's CEO or CFO, it is in your best interest to create a financially healthy environment from the start of the implementation project. The expectation is that this good inbreeding will continue with the software into production and throughout its entire life cycle. Considering the extensive scope of enterprise software such as enterprise resource planning (ERP), supply chain management (SCM), and warehouse management systems (WMS) software, the need for adequate and substantial controls is even more apparent.

Part I explored the impact of SOX on project management and documentation. This analysis illustrates how an audit emphasis during the implementation of software can lay the solid foundation for SOX compliance.

This part demonstrates how controls and the audit emphasis can be applied during an implementation project and throughout the software's lifecycle.

Control Framework

The prevailing guideline for internal controls is the Committee of Sponsoring Organizations (COSO) of the National Commission on Fraudulent Financial Reporting (Treadway Commission). COSO has provided a standard definition of internal controls to assist organizations in achieving financial, operational, and compliance objectives of SOX. As illustrated by the model below, the COSO framework can, and should, be applied to project activities. The following sections provide examples of how internal controls and procedures can be instituted while the project is underway and carried forward in production. Hopefully, as the project manager and working in concert with the audit function, you can think of others that may be pertinent and cost-effective to your organization. If that is not enough, perhaps the threat of SOX and the attached penalties may be enough to jolt you and your organization into action.

Software Piloting

When implementing enterprise software, piloting of this software is one of, if not the most critical event in the project's life cycle. Piloting or conference room pilot (CRP) is the process by which you put the software through its paces in a pseudo production setting to verify that it can support the standard business practices and routines of the company. If done well, the pilot will uncover issues before they become problems, instill confidence in the users that the software is ready for prime time, and make the "go live" uneventful and a cause for celebration.

What role can the audit function play in this segment of the project? A traditional and necessary function of an auditor is the development and execution of comprehensive sets of test conditions and work programs. These conditions serve to test the software under an as "close to" normal operating environment as possible to ensure that the intended results are achieved. This testing function comes into play during two specific piloting processes: module piloting and integrated piloting.

First and shortly after the enterprise software is installed, verification is needed that specific modules perform as expected and can satisfy the business practices of the company. Can orders be taken and invoiced correctly? Is inventory being relieved at the proper points in the process? Are production costs being accumulated accurately? The same types of tests must be developed for the other modules of the enterprise software. The auditor's participation in the development of the test conditions can ensure that the financial and operationally significant aspects of the company are serviced and software executes successfully. While it may be impractical for the auditor to develop business conditions for each module, the audit function should provide overall guidance as to the generally accepted principles of controls, a statement of objectives of auditing through and around computer systems, and participation in a review of testing results and resolution of issues.

Traffic Audits Make Strange Bedfellows

The audit is a process for verification of the numbers that you report to your advertisers. Audits can be performed in a number of different ways.

* Server-based audits examine data that is available at the server, most importantly traffic logs and web logs. An auditing organization will prowl through the logs to check for various kinds of impressions that should not be reported. This investigation will include an examination of the parameters you use to run your traffic analysis programs. Auditors may insert software in the web server that causes independent logs, totally under the auditor's control, to be created.

* Panel-based audits measure the surfing behavior of a sample panel of users, and attempt to project that statistically to the entire Web population

* Browser-based audits attempt to confirm actual ad displays. For example, an applet can be attached to an ad or to a page; the applet will report when the ad is actually displayed on some user's browser.

Larger consumer sites like Yahoo and Amazon.com, and their advertisers, use panel-based audits, and the numbers are sometimes front-page news. Smaller consumer sites and B2B sites generally don't have the volume for panel-based audits to be statistically significant, and rely mostly on server-based audits. Browser-based audits are a newer technique and are not heavily used.

How good are the different techniques? Jim Spaeth, President of the Advertising Research Foundation, tells of comparisons where on site X a server-based procedure showed 15% of the traffic shown by a panel-based audit, but on a second site Y the order of the methods was reversed, with the server-based procedure showing 300% of the traffic that the panel-based audit did. "This kind of result gives people chills down the back of the neck," Mr. Spaeth said. He also noted that different procedures of the same class also tend to produce different numbers.