Disaster! After 10 years of hard work to develop a decent understanding of the company’s finance, inventory, two HR and three pay systems, we switched to SAP (for finance and payroll) and PeopleSoft for HR) and another ERP system for inventory. It was bad enough that we were changing systems, but to implement separate systems for the major functions seemed idiotic and created much more work for me and the rest of the CAATTs team. In addition, we had roadblocks, particularly from IT who were busy trying to implement the new systems. I was hard to argue with them.
However, it did reinforce the notion that auditors need to be flexible, nimble, and willing to accept change – all things we expect of our clients when we make recommendations. It also reminded me of the importance of personal relationships and multiple methods of accessing data.
I spent a good portion of a year reviewing previous requests for data and analysis support (to determine what was required by auditors); working with auditors of different stripes (financial, operational, compliance, HR, etc.) to find out what data they required; and the technical folks (programmers, analysts, business owners, etc.) to re-negotiate access to the various systems and data. I also mapped our current data to the new applications (e.g. in the previous system we had access to the responsibility centre which was the Cost centre in SAP; record number/document number, invoice date/document date, etc.). For SAP this involved obtaining read access to the system and bring up an invoice – pressing F4 on each field and then selecting “technical data” to get the German field names and table names.
On the positive side – we were able to identify a number of control weaknesses and conversion problems. In the PeopleSoft conversion we noted that everyone’s previous position was incorrect. It looked like the index got corrupted and was pointing to the wrong record. In SAP, they simply converted the entire existing vendor master table – duplicates, expired vendors and all. This created problems with the control over duplicate invoices and payment terms.
ACL Commands: JOIN, RELATE, COUNT, and STATISTICS
Lessons-learned: personal relationships will constantly be of immense value. As systems/applications change, you will often dealing with the same people over and over again. Using a sledge hammer to obtain what you want in the first instance will likely come back to haunt you in the future. Always strive to maintain a co-operative relationship – understanding the operational constraints that the programmers/analysts are under and working with them to find a solution.
Going from total and easy access to nothing – reminds you of the importance of documenting your requirements, authorizations, capabilities, and the persons who granted you the original access. In particular, the legal folks who finally understood that auditors have a right to access personal information (treat these people well unless you want to go through the long drawn-out and painful process of convincing lawyers that audit should have access to personal information again and again). Also, it is useful to secure various methods of accessing the data including: read only access to application; the ability to run standard reports; the ability to run ad hoc queries or use a report writer; and access to the raw data or a data extract. We used all of these to obtain information from the new applications and verifying our understanding and analysis routines.
Additional warning – document all analysis routines so that when you need to rewrite them using the new application data, you will understand the original logic and intent. Something I had failed to do as I built up the analytics function. This will also help you determine what fields/information is required from the new application.
We also re-discovered that operations is often busy “just keeping the lights on” and has little to no time for audit. In situations where it is a custom build, even having standard reports developed will likely be the last thing on the list to develop; and audit will be left to its own devices. For one such application, we hired a consultant from the team who had worked on the system implementation to build us an extract file.
Sophisticated ERP systems can be accessed and data analysis performed if you have clear objectives and a systematic approach to obtaining, verifying and using the data. We knew nothing about SAP or PeopleSoft, but did a good job defining our requirements before trying to access the data. By reviewing the data requirements of previous audits, I was in a good position to know what types of information – even which fields – were required and how often. This allowed me to prioritize the tackling of SAP, PeopleSoft, Mincom and two other new applications.