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.
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.
No comments:
Post a Comment