It is hard to recall the last time an ERP implementation team included an auditor as an active member. Could it be because of availability? No defined role? Never been asked? No perceived benefits? This article explores key points in a project's lifecycle where the audit function should be involved and the deliverables to be expected. Whether internal or external, an auditor, preferably experienced in IT matters, can provide benefits while the software is being implemented and, afterwards, when the software is being used.
For whatever reason, having an auditor as part of the ERP project implementation team is a rarity. In fact, involving an auditor in the selection of ERP software is fairly rare as well. These same folks are going to have to toil in the ERP software fields after the systems go live. Would it not make sense to involve auditors up front and, for sure, when the software is being implemented? Of course, it does and I will make a case as to why this proactive approach can save time and money in the long run.
First, for argument sake, let's define the basic ERP implementation project lifecycle as containing the following phases:
* Project Planning and Organization
* Business Process Pilot
* Solution Integration
* Integrated Pilot
* Go Live
The following paragraphs will identify how an auditor can be effectively utilized in the various phases and the expected results.
Project Planning and Organization
In the Project Planning and Organization (PPO) phase, the overall workplan and time schedule are defined and training for the project team is completed. As you would do with any business process owner/leader, assurance must be obtained as to the availability of resources to include the audit function. More importantly, in this phase it would be appropriate to specify the audit role or, better yet, have the auditor articulate his or her role.
Business process owners need to understand what the auditor will be examining in terms of input/output and processing controls. This will become more obvious when developing customized business conditions. Training for the auditor must be scheduled and should be held together with the team. While a detailed understanding of the each process may not be required, an overview of the entire ERP function must be gained and understood by the auditor, particularly the process-to-process flows and exchange of data.
If the above observation, namely that an auditor's involvement is, indeed, rare, inclusion of the audit function in the planning phase should become as commonplace as other business process owners. Furthermore, business process owners will be relieved to know that the burden of accountability and control is being shared with the subject expert.
Business Process Pilot
The Business Process Pilot (BPP) phase is where testing is performed solely within the confines of the process. In this phase you take a selfish approach to testing and verify that the process works within its own boundaries. At this point, you are not concerned what happens up or downstream.
Before this testing can be done, however, business conditions must be developed and/or tailored to your company's environment. In this regard, the auditor should review the conditions and suggest additional conditions to substantiate the financial integrity of the software. In the ordering process, a business process owner is concerned that, for each order, an invoice is produced. The audit implication is that the dollar value of order, typically already communicated to the customer, is reconcilable to the value of the invoice.
Whereas the business process owner is worried that the correct products are picked for an order, the auditor is concerned that appropriate costs are relieved from inventory. The former keeps the customer happy but the latter condition keeps the company profitable and the project team gainfully employed. Auditors are attuned to look for these types of checks and balance and are, in fact, the experts. Someone should do it. Why not let the experts do what they are trained to do? Why not let the auditor review the business conditions to ensure that the accountability aspects as well as the operational functions of the software are being verified?
For whatever reason, having an auditor as part of the ERP project implementation team is a rarity. In fact, involving an auditor in the selection of ERP software is fairly rare as well. These same folks are going to have to toil in the ERP software fields after the systems go live. Would it not make sense to involve auditors up front and, for sure, when the software is being implemented? Of course, it does and I will make a case as to why this proactive approach can save time and money in the long run.
First, for argument sake, let's define the basic ERP implementation project lifecycle as containing the following phases:
* Project Planning and Organization
* Business Process Pilot
* Solution Integration
* Integrated Pilot
* Go Live
The following paragraphs will identify how an auditor can be effectively utilized in the various phases and the expected results.
Project Planning and Organization
In the Project Planning and Organization (PPO) phase, the overall workplan and time schedule are defined and training for the project team is completed. As you would do with any business process owner/leader, assurance must be obtained as to the availability of resources to include the audit function. More importantly, in this phase it would be appropriate to specify the audit role or, better yet, have the auditor articulate his or her role.
Business process owners need to understand what the auditor will be examining in terms of input/output and processing controls. This will become more obvious when developing customized business conditions. Training for the auditor must be scheduled and should be held together with the team. While a detailed understanding of the each process may not be required, an overview of the entire ERP function must be gained and understood by the auditor, particularly the process-to-process flows and exchange of data.
If the above observation, namely that an auditor's involvement is, indeed, rare, inclusion of the audit function in the planning phase should become as commonplace as other business process owners. Furthermore, business process owners will be relieved to know that the burden of accountability and control is being shared with the subject expert.
Business Process Pilot
The Business Process Pilot (BPP) phase is where testing is performed solely within the confines of the process. In this phase you take a selfish approach to testing and verify that the process works within its own boundaries. At this point, you are not concerned what happens up or downstream.
Before this testing can be done, however, business conditions must be developed and/or tailored to your company's environment. In this regard, the auditor should review the conditions and suggest additional conditions to substantiate the financial integrity of the software. In the ordering process, a business process owner is concerned that, for each order, an invoice is produced. The audit implication is that the dollar value of order, typically already communicated to the customer, is reconcilable to the value of the invoice.
Whereas the business process owner is worried that the correct products are picked for an order, the auditor is concerned that appropriate costs are relieved from inventory. The former keeps the customer happy but the latter condition keeps the company profitable and the project team gainfully employed. Auditors are attuned to look for these types of checks and balance and are, in fact, the experts. Someone should do it. Why not let the experts do what they are trained to do? Why not let the auditor review the business conditions to ensure that the accountability aspects as well as the operational functions of the software are being verified?
No comments:
Post a Comment