The way that you manage your SAP implementation or upgrade can have a profound impact on your ability to successfully pass an audit. More importantly, it can affect the long-term success of your initiative for good or for ill.

In my experience as an auditor, one of the biggest risks I’ve seen in organizations that attempt to do the right thing and design effective controls is that they start too late. By sequencing key activities early in the implementation life cycle, you can create a foundation that supports internal control design in an efficient, effective, and relevant way.

SAP project managers and implementation team members are likely to benefit most from this article. The activities I discuss relate to specific actions that the implementation team should take during the SAP implementation process to reduce the potential for audit issues and minimize future rework.

First, I map the typical control design process to a standard implementation life cycle. Next, I walk you through each phase of the implementation life cycle and share typical risk and control activities that you should conduct during that phase. In addition, I share some of the most common issues I’ve seen at organizations I’ve audited.

Risk and Control Activities by Phase

While different organizations may use different terms, most implementations follow the general phases shown at the top of Figure 1. For every phase in the standard implementation plan, the control implementation plan at the bottom of the figure contains the risk and control activities that you should perform during that phase. Basically, this means that you should include risk and control considerations throughout the SAP implementation life cycle.

Figure 1

Mapping the phases of control implementation to the standard implementation plan

The potential impact of not considering risk and control issues during each phase can be dangerous in many ways. Here are a few highlights:

• Planning, or the lack of it, can hinder your ability to correctly balance your controls with your business risks, potentially focusing too much attention on areas of low risk and not enough attention on areas of high risk. Doing this can cause wasted effort designing unnecessary or overly complex controls. Failure to address a risk with effective controls, however, could result in a lack of control and increase your organization’s exposure to potential business problems.
• Design problems can occur — often without management’s knowledge — that leave management’s plans unfulfilled. Design problems can result in having controls that aren't appropriately configured to your specific business needs or that are ineffective at mitigating your process risks. Ultimately, situations like these could increase your organization’s exposure to risk and directly affect management’s perception of the implementation’s success.
• Configuration issues may result in a false belief that the team effectively set up the controls (in SAP systems) that management planned during the design phase. It could be because design changes were not carried through to configuration, configuration activities were inadequately tracked, or the process of configuring controls in SAP systems wasn’t understood. The reason why doesn’t ultimately matter because the result is always the same: the controls don’t work as intended.
• Data conversion inadequacies may result in incomplete, inaccurate, or fraudulent master data. Poor data conversion or data-cleansing processes can also lead to an ineffective audit trail that complicates the audit process. Ultimately, this can affect every transaction processed in your SAP system.
• Testing deficiencies increase your risk that the controls you configured in SAP systems don’t work as intended. In addition, testing deficiencies can fail to identify transactions and situations in which your controls may be inadvertently bypassed. This is even more problematic because it creates a false sense of security.
• Training completion often implies that employees know their control-related responsibilities. However, this may not be true. For manual controls (or system-related controls requiring manual interaction), a lack of training focus seems to imply that the processes are intuitive enough that employees can naturally perform the intended actions to the degree of precision that management wants. This may not be the case.
• Go-live processes, or the lack thereof, can increase the ongoing audit effort by not fully capturing and documenting the controls implemented while the details are still fresh in the minds of the implementation team. This results not only in a one-time increase in audit effort, but often also in an recurring cost to the business that you could have avoided.

Having highlighted the importance of considering risk and control considerations in each phase of the implementation life cycle, I will walk through these phases and discuss where you should apply risk and control strategies.

Planning Phase

Planning is crucial to any implementation, and the planning process sets the stage for the entire control-design effort. Your SAP system implementation plan should consider the two primary categories of controls: those built into the new SAP-enabled processes and those required to effectively support and maintain your SAP system after go-live. It should also include controls (e.g., security, change control, and so on) within the implementation process to ensure that you reduce project-specific risks (such as the risk of an untested configuration change being made or the risk of unauthorized access to sensitive master data).

During the planning phase, you establish the controls you need to build into the current implementation process and to regulate the activities of your project team members. You also set the ground rules for building controls into your SAP-enabled processes and the ongoing maintenance and upkeep of your SAP system. Project controls govern the entire implementation. They help to ensure that the project stays on track and is managed effectively to achieve the desired outcomes. While project-related controls may at times seem burdensome to the project team, they provide tremendous benefits to team members — reducing the risk of inadvertent mistakes by preventing them from occurring or detecting them quickly if they do occur (ideally before they affect the success of the project). I recommend that you include your auditors when you design the process controls for your SAP implementation. Key questions that you might want to incorporate are:

• How will you make project-related decisions? As you identify potential problems, how will you effectively track them and follow them through resolution? If you cannot resolve all your open issues before go-live, how will you determine whether to extend the project’s due dates and who to involve in such a decision?
• How can you best ensure the consistency and effectiveness of the controls that the implementation team designs? Whom should you include when you determine which controls to implement? If process changes are necessary after you identify the initial set of controls, how do you ensure that the controls are still effective for the new process?
• How do you know when you have a complete set of controls and can stop designing them? How do you track the status of control design? How do you best validate and ensure the quality of the controls you’ve designed?
• What specific risks does this implementation have and how do you address them? How do you best deal with the security and privacy of sensitive data throughout the implementation? How do you ensure that the data transfers completely and accurately into your SAP system, and how do you mitigate the risk of errors if you use data-cleansing?
• What other risks could affect the project and how would you deal with them? How do you handle the potential loss of a key team member? As your business environment and organization evolve between the start and completion of your SAP implementation, how do you ensure that control-design decisions are still relevant to the organization at the time of go-live?

When you have thoughtfully considered the answers to these questions, you have laid the foundation for a successful implementation. You have also established the key processes that should guide your control efforts. Before I conclude this section, I want to highlight a few common issues that have affected the implementations I’ve seen:

• Lack of project structure and standards
• Omission of control design and control testing from the work plan (discussed in greater detail in my previous article)
• Poor understanding of where to build the controls (discussed in greater detail in my previous article)
• Lack of communication or change management plan

Now, I’ll describe how to design the controls for your implementation.

Design Phase

The bulk of the control-design work begins during the design phase of your SAP implementation. During this phase, you follow the process set forth in the section “Effective Control Design” in my previous article. Because I’ve already told you about the primary activities in this process, this section is short and highlights only a few special areas for consideration. Hopefully, in the planning phase, you documented a list of risks that you need to address during the implementation. This list can serve as a completeness check during the control-design process as well. Remember, not all controls need to be in your SAP system; some of them may be more appropriate in manual processes.

While you are designing controls, I strongly encourage you to follow a reengineering mindset and think critically about how SAP-related features and functions can enhance the way your controls interact with your business processes. I find it ironic that many organizations spend time reengineering their business processes during an implementation, and then they implement the same controls they have always used and to which they have become accustomed. Not only is this risky, but it can lead to unproductive business processes. For example, requiring dual authorization of any checks that are above a certain dollar amount may have been the best available option for your old system. However, you may find that SAP’s stochastic invoice-blocking functionality is a better way of addressing that risk as you go through the implementation.

As you work with your auditors and any SAP-related risk, audit, and control experts, you should use their experience to ensure that you’ve identified the relevant, inherent, and company-specific risks for internal controls to address. You should also work with them to validate and quality-assure the controls across an end-to-end business process.

Another activity that can significantly reduce the audit effort (and your respective time commitment) after go-live is to work with your audit team to design and build continuous control-monitoring procedures. If you do this during the implementation, it allows you to integrate these procedures into your SAP system design and relevant training where appropriate, and to leverage the depth of knowledge that exists on your implementation team.

Last, I recommend tracking and communicating control “gaps” (areas where a control is needed and yet the proper control has not yet been determined) throughout the implementation process, and reviewing any remaining risks with management and your auditors to obtain approval. Remember, controls rarely address risks perfectly. You need to track those areas where you know control gaps exist, and validate with management that the remaining risk is within the level of acceptable tolerance.

Some of the most common issues I’ve seen during the control design process include:

• Focusing on only what’s in the SAP application instead of the end-to-end process (e.g., enabling SAP’s Evaluated Receipt Settlement (ERS) vendor functionality, but not determining how to qualify vendors as ERS vendors and evaluate them against relevant quality metrics)
• Ineffectively tracking control issues or control gaps (e.g., noting that ERS processing necessitates stronger controls over pricing changes, but neglecting to follow through and design these additional controls)
• Poorly documenting processes and controls, which increases the audit effort when it occurs and adds to the training effort during and after go-live (e.g., failing to document the specific procedures for managing and monitoring ERS-related vendors, beyond merely accessing ERS-relevant reports in SAP)
• Changing the process without changing the controls (e.g., a late implementation-related decision to add a custom transaction, with no consideration of how it would impact the originally designed security profiles)
• Failing to establish ongoing control-monitoring processes (e.g., neglecting to build escalation workflow or other detective controls to ensure that personnel effectively resolve the items that appear on SAP exception reports)

When the design phase is complete, you need to configure the controls in the SAP system.

Configuration Phase

During the configuration phase, you technically set up the controls you have planned and designed that require configuration in your SAP system. Like any other SAP functionality, many controls within an SAP system require a specific configuration effort to both enable them and set them to work for your business. In the SAP Sales and Distribution (SAP SD) module, for example, this effort may include enabling customer credit-checking and credit-defining at whichever of the many possible points in the process the SAP system can perform the credit check (e.g., when placing the order, before shipping the goods, and so on). In some cases, your SAP system may enable the controls, but specific parameters and tolerances still need to be set to an appropriate level for your organization (e.g., depending on your security policies, you may choose to increase the minimum password length required for user access).

I recommend that you document the specific setup details (e.g., the point in time the SAP system will perform credit-checking) and the location of the configured parameters (i.e., the screens, tables, and fields that contain the actual configuration parameters). I also recommend that you retain this documentation for the auditors, perhaps by recording it as part of the control details themselves. Doing so will make it easier for an auditor, who may be unfamiliar with your specific environment, to assess control setup and configuration while minimizing the time your team must commit to supporting the audit. (For more information on recording controls, see the sidebar “Control Documentation and Business Process Procedures” below.) If you can show your auditor specifically where you configured each control, you will save a lot of time and effort later. You should also retain any information you have on significant configuration decisions and rationale in case questions come up during the audit.

Now is also the perfect time to set up the SAP functionality your auditors may need. If you deal with setting up and configuring auditing functionality during the SAP implementation, it’s often significantly less time-consuming than if you wait to tackle them after go-live. You should also configure any read-only IDs that your internal and external auditors may need for their audit work (as defined by individual organizations and their audit teams).

Typical issues from the configuration phase include:

• Lack of documentation for updates made to the default SAP parameters
• Controls identified in design documents but not configured to specifications
• Failure to set up audit-specific profiles and IDs
• Failure to set up the Audit Information System (AIS) and other audit-centric functionality (where relevant)

Now that you’ve seen the control planning, design, and configuration phases of control implementation, I’ll look at the data conversion considerations.

Data Conversion Phase

In the last few years, data privacy has become a much more visible issue, and a typical implementation team should no longer have access to the entire set of organizational data for testing and development purposes. During planning, you should consider controls that govern unauthorized access to sensitive master data. By the time you reach the data conversion phase, these controls should be fully enacted, enabled by data security within your development environment, and periodically tested and monitored for effectiveness.

If you plan to convert data from an older system to your SAP system, spend some time ensuring that there are controls for the data-cleansing process to ensure the integrity of data ultimately moved to your new SAP system. Similar to how many people accumulate more and more junk in their homes the longer they live there, many organizations find that they have junk in their data from older systems, too.

For example, you may have duplicate vendors in the vendor master file, missing data for employees, outdated products in the product catalog, and so on. Data-cleansing refers to the process an organization follows to clean up this data as part of moving it to the SAP system. (For more information on finding problems with your data, see the sidebar “Leverage Existing Audit Tools” below.) Key areas related to data conversion and cleansing include implementing controls to ensure that all changes are accurate and complete; these controls can also help to ensure that you haven’t made any unauthorized changes. Data-cleansing and conversion controls should also enable an effective audit trail (a documentation record that traces specific data as it existed in your source system to how it currently appears in your SAP system, accounting for any data-cleansing changes). This allows both auditors and the SAP project management team to validate the integrity and completeness of the SAP data-cleansing and conversion process.

The most common audit issues related to data conversion are:

• Significantly underestimating the effort required, leading to a rushed data-conversion process. One organization with which I worked budgeted only two weeks for data conversion. As a result of rushing the process to keep budgeted excesses to a minimum, the organization ended up putting a lot of outdated parts data in its inventory catalog, requiring a tremendous amount of clean up years later.
• Garbage in, garbage out. I worked with an organization that literally had 12 different ways of spelling AT&T in its old system — you can do it if you’re creative. This company didn’t even try to clean up duplicate vendors when it moved to a new system. If an organization lacks a complete picture of procurement activity for a vendor, that can make it challenging to negotiate favorable vendor-pricing arrangements.
• Losing the audit trail during data-cleansing. Because the data-cleansing process adds, changes, and deletes data, the auditor typically wants to audit the details of these changes and validate, for example, that no intentional or inadvertent changes were made to the data against management’s intent. Providing this evidence for the auditor requires documentation and the tracking of all changes.
• Ineffective monitoring of changes to master data during the conversion process. If the data-cleansing process is also updating data, in conjunction with the audit trail issue discussed above, a quality assurance process should be in place that would detect any mistakes made by the employee entering the change (e.g., transposing a supplier tax ID number for a supplier or mis-keying bank account information).

Now, it’s time to test the controls you’ve implemented.

Testing Phase

If you followed the process I outlined in my previous article, your standard testing process already incorporates control testing: you have specifically designed and documented controls in the BPPs, you have configured them in your SAP system, and as a result you will test them as you would any other SAP-configured function. You should integrate your control testing into your testing scripts and document any testing issues on your issue management logs. Given the importance of having adequate controls, make sure that you resolve all issues identified during testing before go-live. Failure to do so could cause problems in your SAP audit.

Provided certain criteria are met, some regulatory compliance audits, such as those for the Sarbanes-Oxley Act in the United States, allow an auditor to rely on the testing performed during implementation in lieu of traditional audit testing. If this is the case, you should work with your auditors to ensure that your testing processes are sufficient for reliance and adjust them as needed to maximize the value of your testing. You should check with your auditors to determine what, if anything, you can do to enhance their reliance on your testing work, as auditors may have different internal requirements. It may also be wise to have an audit team independently test any critical controls prior to go-live.

Some common audit issues that occur during the testing phase include:

• Inadequately testing standard functionality. It doesn’t take much time reviewing the details of patches provided by SAP to see that not all of the supplied functionality works as intended. In addition, customizations you make to your SAP system may have an unintended effect on other functions in the system, even though they don’t appear to be related.
• Inconsistently testing procedures across teams or rollouts. I worked on an implementation for which the European team conducted tests that the US team did not, and visa-versa. Unfortunately for this company, a test that passed in Europe would have failed in the US because of the differences in processing requirements; however, since testing wasn’t consistent, the US team failed to identify the potential problem until after go-live.
• Failing to test the security roles that you will implement in production. While testing with super-user IDs or creating powerful testing IDs may reduce the need to log off and log on under different IDs to follow a transaction completely through the process, it also prevents you from identifying problems in the security setup of your SAP profiles and user access definitions. I’ve worked with more than one organization that had to grant broad security access for a large group of employees — and risk all the problems that overly broad access poses — simply because the organization found out after go-live that the security profiles as defined didn’t allow employees to complete their assigned tasks.
• Ineffectively resolving issues identified during testing. I’ve seen cases in which organizations proceed as if a test failure is an isolated incident, without sufficient follow-up to validate this assumption. Failure to follow up and resolve potential issues identified during testing can also prevent your audit team from placing any reliance on the testing performed during the implementation — increasing effort across the organization.

Think you’re ready to go live? Not quite! You still need to train the relevant staff members so they know what to do and understand what it means.

Training Phase

From a career of audit experience, I believe the issues that have the greatest adverse impact on organizations primarily result from poor user training and education. SAP-related security issues and ineffective configuration settings may be prevalent after an implementation, but they generally expose your organization to potential future risks. Training issues generally affect your organization today and pose the risk that every transaction processed by a particular employee is error-prone until you correct the behavior.

Keep in mind that many of the controls designed during your implementation — even the configurable SAP controls — may require some manual interaction, increasing the need to educate employees about any related responsibilities. Of course, holding training sessions isn’t enough; the key is to make sure that the appropriate employees attend and gain sufficient knowledge to conduct their control activities. Make sure that training attendance records, evaluations, post-training activity monitoring, and other indicators of training relevance and effectiveness indicate a successful completion of training.

When designing your control training, make sure that it contains enough information for a user to perform his or her respective control activity, as intended. Many of your system-dependent controls will involve reviewing standard SAP exception reports, such as report RM07MSAL – Goods Received but not Invoiced. Common training around SAP reports involves showing the user the transaction codes or menu paths to access the report, and the key report parameters that you can use to generate information (e.g., run report RM07MSAL and filter the results as desired by vendor, purchasing organization, purchasing group, material, purchasing document, or item). From a control perspective, however, this isn’t enough. To be effective as a monitoring control, the user also needs to know how often he or she should review the report, what specifically he or she should seek on the report that might indicate a problem, and how to use SAP functionality to perform follow-up and resolution procedures.

Common audit concerns related to training include:

• Focus on navigation rather than process, as in the reporting example described above.
• Limited education on system controls, such as neglecting to describe how an SAP system automatically replenishes goods based on the values in inventory (and that you should not move such items from the warehouse or between warehouses without first properly recording the change in your SAP system).
• Manual controls largely ignored, such as failing to describe in detail how manual quality assurance overpricing changes should work even before they get to the SAP system.
• Failure to monitor the effectiveness of training and ensure user retention. I’ve seen some organizations put in a testing and certification process whereby management doesn’t grant individual employees access to the system until they have proven that they can perform their work accurately.

Finally, all your ducks are in a row, and you’re ready for go-live.

Go-Live

By the time you’re ready for go-live, if you have followed the process described in this article and my previous article, you should be ready to pass any audit. Prior to go-live, however, make sure that you have assessed the risk related to any remaining open issues, particularly if they affect control effectiveness. Communication with the appropriate levels of management is a key element, as you should allow management to determine whether the level of risk fits within their risk-tolerance-level limits.

There are only three primary audit concerns I’ve noted that are consistently related to go-live:

• Readiness status based on date/budget instead of genuine preparedness
• Inadequate risk assessment for open issues
• Lack of a defined process to report post-go-live issues

Now, it’s time to complete any last-minute documentation and store it in an easily accessible location in case any questions arise in the future. While the steps I’ve gone through may have added a bit to your overall workload, I hope you’ll see considerable return on your effort the next time the auditors come knocking.

Implementation in Progress?

Insufficient effort at each relevant phase in the implementation is likely to result in increased effort later, over-controlled processes, or inefficient processes resulting from the implementation. Of course, if you are in the middle of an implementation and are just reading this article, you may have already completed a number of these phases. How do you apply this insight without returning to the first step of the implementation and starting over? While I never recommend attempting to shortcut the control-design process — in every case in which I’ve seen organizations use a shortcut, I have seen serious problems post-implementation — I understand that some circumstances are beyond your control. If you are down to the wire and have limited time and resources, consider focusing on the following areas:

• Consistency of controls across entities and rollouts (one audit “red flag” is two similar areas with different setup or configuration), unless clear logic supports a difference
• Customization of SAP parameters and tolerances to your organization’s risk
• High-quality master data maintenance procedures
• Security, including overall SAP security administration, controls over powerful roles and IDs (SAP*, SAP_ALL, and so on), and restrictions for developer access to production
• Monitoring of exception processes (e.g., adjusting inventory, creating reversing journal entries, or processing invoice adjustments, to name a few)
• User education and understanding of your key control processes
• Integrity of data conversion and cleansing
• Change control and transport process (on the newly implemented SAP system)

Focusing on these areas will help you mitigate some of the highest business risks typically resulting from an implementation, but you need to be prepared for some audit findings in areas you were not able to fully address.

Steve Biskie

Steve Biskie has been working with SAP ERP systems for more than two decades, and is considered an international expert in SAP audit issues, risk management, and GRC. He was an expert reviewer for the book Security, Audit, and Control Features: SAP ERP (3rd Edition), and the author of Surviving an SAP Audit.

Steve will be presenting at the upcoming SAPinsider GRC 2017 conference, June 14-16, 2017, in Amsterdam. For information on the event, click here. 

 

You may contact the author at steve.biskie@highwateradvisors.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.