The longer the duration between your initial SAP design and configuration decisions and the identification of any related audit concerns, the more difficult, time consuming, and resource intensive it typically becomes to correct the issue. Audit concerns identified after your SAP go-live date can be costly for your organization. At best, they may expose your organization to significant risk; at worst, you may have errors or undesired entries flowing unchecked through your business transactions until you correct the underlying issues. Some decisions, such as how to structure your general ledger chart of accounts or how to set up your organizational units, are so integral to your operation that it may not be practical to make significant changes after implementation. By configuring your SAP system appropriately and designing your related business processes in a way that effectively addresses your business risks, you can save your organization a significant effort. Given the complexity of SAP software and the number of configuration and customization options available, it’s not possible to discuss every potential audit concern. In addition, SAP’s ongoing changes and improvements to their applications make specific configuration advice a moving target. However, I can provide you with a framework that is independent of SAP module and version and can serve as an effective guide for designing and configuring appropriate business controls in and around your SAP system. I am firmly convinced that, by understanding common business risks and typical audit concerns and by carefully managing the SAP implementation or upgrade process to account for these risks and concerns, organizations can eliminate nearly 90% of all audit findings. Beyond just reducing audit findings, however, applying the principles discussed in this article will make your SAP implementation more successful. Most audit issues merely identify situations in which a business condition potentially exposes the organization to more risk than management finds acceptable; a process exists — or doesn’t exist — that goes against management’s stated or desired intentions, or you have specifically identified an error or anomaly. Independent of an audit, your organization should proactively identify and understand each of these three situations and address them effectively in advance of your go-live date. This article helps SAP project managers, administrators, and users understand the specific steps they can take during the implementation process to better prepare their organization for an SAP audit and reduce costly rework. Herein, I discuss techniques that, if performed well during an SAP implementation, can significantly decrease the number of audit issues identified after go-live. I share suggestions, based on participation in dozens of SAP implementations, about how to best structure your implementation team to ensure the design and configuration of appropriate business controls. I also provide tips about how to work with your auditors (both internal and external) during an implementation and how to develop audit-relevant documentation, which can provide your auditors with the information they need to do their jobs as quickly as possible.

Why Implement Controls?

There are a number of important reasons to consider controls as part of your SAP implementation process, including:

• Regulatory requirements
• Cost to the business
• Control redesign and optimization
• Process verification
• Upgrade-specific benefits

Let’s look at them one at a time.

Regulatory Requirements

Depending on the country or countries in which your organization operates, regulations may require that you have continuously effective internal controls — or receive significant fines, potential jail time for your executives, and lots of bad publicity. Some regulations establish the standards for financial reporting and corporate governance. These include the Sarbanes-Oxley Act of 2002 in the United States, Bill 198 in Canada, the Combined Code in the United Kingdom, the Financial Instruments and Exchange Law (J-SOX) in Japan, the Corporate Law Economic Reform Program (Audit Reform and Corporate Disclosure) Act 2004 (CLERP9) in Australia, and the Loi sur la Sécurité Financière (LSF) in France. Other regulations establish standards for data security and privacy, such as the Health Insurance Portability and Accountability Act (HIPAA) and Gramm-Leach- Bliley in the U.S. and the European Union Directive on Data Protection in Europe. Numerous industry-specific regulations also exist. In addition to the specific penalties that these regulations impose, failure to comply may result in a negative backlash from the major financial markets. I should point out that some regulations actually speak directly to the need for control considerations during an implementation. In the early days of Sarbanes-Oxley in the U.S., a number of organizations argued that the nature, complexity, and resource-intensive nature of system implementations could make it difficult to have controls in place and fully tested if the implementation occurred close to the regulatory reporting deadline. In a Securities and Exchange Commission (SEC) guide to frequently asked questions (May 2005), the SEC stated, “Companies are required to prepare reliable financial statements following the implementation of the new information systems.” In essence, the SEC was reminding companies that financial reporting integrity is nothing new. It is always expected, and that expectation doesn’t change merely because a company undertakes a challenging project. The SEC went on to say, “The staff does not believe it is appropriate [for management] to provide an exclusion … of new IT systems and upgrades from the scope of its assessment of internal controls over financial reporting … With respect to system changes, management can plan, design, and perform preliminary assessments of internal controls in advance of system implementations or upgrades.”

Cost to the Business

A typical audit may occur late in your implementation or even after it’s complete. This makes it difficult to incorporate audit-relevant suggestions into your SAP configuration and related process-design decisions. These decisions become more difficult and costly to change as time passes between the point of the initial design determination and the identification of a potential audit concern. Most implementations have significant audit findings post go-live. Considering internal controls during the implementation minimizes the need to reconfigure SAP after go-live and reduces overall business risk.

Control Redesign and Optimization

Many organizations undertake an SAP implementation as a means of reengineering processes and improving them. This is also the perfect time to update or eliminate inefficient and ineffective controls. Like your standard business processes, controls should evolve and change as your business environment changes, and as new technology supports techniques that weren’t available when you designed your previous controls. For example, at one time companies set specific dollar limits above which invoices required secondary approval. SAP-enabled techniques, such as stochastic invoice- blocking (which involves both random and predictable elements in choosing the invoices to block), now allow organizations to avoid arbitrary limits and automatically place invoices on hold for additional review (e.g., management checking the authenticity and accuracy of the invoice) based on statistically valid techniques. In addition, controls typically consider management’s appetite for risk, which changes as your management changes. Controls often depend on your business environment, which also changes over time. Even the tolerances and thresholds you set for your business processes are typically based on the business conditions that existed at the time of initial control creation and may no longer be appropriate in the current business environment. For example, many organizations implement tolerances on the three-way purchase order/receipt/invoice match. Historically, this tolerance may have allowed organizations to pay an invoice in full even if there were, for example, a 2% variance in received quantity. Today’s economic climate may now cause a company to reconsider this threshold and tighten, reduce, or eliminate it completely. The implementation is the best — and often the only practical — time to optimize your controls and fit them to your business without costly after-the-fact modifications.

Process Verification

If you consciously design your controls during the implementation, they serve as an important validation of process integrity. Control-design techniques force you to examine the things that can go wrong in a process and often help to identify process deficiencies (see the section “Control Design” below). Even for processes that are new to your organization, a good control-design framework forces you to think through potential challenges and ultimately to minimize the problems and errors that will occur after go-live. I have participated in numerous implementations in which process problems would not have been detected if someone responsible for evaluating controls hadn’t identified a potential discrepancy.

Upgrade-Specific Benefits

SAP upgrades raise several concerns that further enhance the benefits of being control-conscious. Functionality that may have served as an internal control in the past (such as using Reverse Business Engineering [RBE] to monitor the risk of potentially excessive access to SAP transactions and functions) might cease to exist and need to be replaced with an alternate means of control. Conversely, new functionality that an upgrade provides may allow you to eliminate previously enacted controls, particularly if those controls were designed to mitigate a risk that no longer exists. For example, new functionality may eliminate the need to review a specific SAP exception report because the upgrade now prevents that condition from occurring. In addition, the upgrade may have unanticipated effects on custom ABAP programs. Therefore, having a deep understanding of your business risks, control needs, and current control techniques, and applying that knowledge to the upgrade process is essential to ensure an effective upgrade. Now, let’s lay the foundation for establishing an effective team and process environment.

A Control-Conscious Implementation

In a perfect world, you could hire — whether permanently or temporarily — individuals who are experts in SAP risk, audit, and control for every process that the SAP implementation affects to ensure that you design and configure the necessary controls. In reality, however, blanketing the project with such individuals may not be practical. Budget dollars and resources are typically tight as it is, and using full-time, expert control advisors throughout an entire implementation is an expensive solution. Instead, I recommend that you develop a control-conscious project team, supplementing the project team as needed with oversight from SAP risk, audit, and control specialists. By educating the implementation team about basic internal-control concepts and providing the tools to guide its members through the control decisions during the traditional design phase, you can make a relatively small resource investment stretch a long way. This approach requires a commitment from the management team of your SAP project to take ownership of the control-design process. You can also kick-start your control-design process by bringing in an SAP control implementation expert at the beginning of the project to train the implementation team to have the proper “mindset” for designing controls.

Team Skills and Knowledge

Designing effective controls requires a few skills and knowledge points that you must now integrate into the implementation process. I have found that historically, these skills have not consistently been included to the degree required. The first skill you need is that of risk assessment.

Risk Assessment

Throughout the implementation, team members should consider a variety of risk-related questions each time they change the design of a process:

• What risks are associated with this process?
• Are all previously accepted risks still appropriate?
• How might this decision affect the organization’s overall risk environment, and is it consistent with the current risk appetite of management?
• What inherent and control risks should the process address?

For example, to design the most effective controls for an accounts payable implementation, the team (or a team member with a strong influence over design decisions) should be aware of any accounts payable-related challenges that have caused problems in the past. If fraud has had an impact on the process, you need to know and consider any specific situations that allowed the fraud to continue (these situations are often not common knowledge). If previously designed controls focused most heavily on payments over $1,000, someone should reassess the risk for payments less than $1,000. You also need to determine whether you can configure SAP functionality to enable a control to be both efficient and effective while further mitigating a risk considered acceptable in the past. As another example, if you are considering using Evaluated Receipts Settlement (ERS), the team should assess the additional risks associated with ERS (e.g., the loss of a three-way purchase order to receipt to invoice match increases the risk that errors in the ordering, pricing, and receiving processes will result in inaccurate payments) and determine how to address these risks. At each step in the process being designed, the team should be aware of the risks inherent to the process itself, those specific to the company’s business, and those resulting from the process-design choices. (For more information on different kinds of risk, see “Understanding Risks and Controls”.)

Control Design

Similar to the risk assessment skill discussed above, effective control design makes it necessary to consider a series of questions. These questions include the following:

• At what point during the process should the control occur?
• Is the control sufficient to mitigate the identified risk?
• What is the business impact of the control, relative to the impact and likelihood of the risk it mitigates?
• What other controls must be in place for this control to be effective? Are these controls already configured, or do they need to be designed?
• Does this control apply to all variations of this process, or should additional controls be designed?

To continue with the accounts payable example, let’s assume the team is looking at the risk of fraudulent payments to vendors. The team may decide to focus on controls that prevent this risk during initial vendor setup. Perhaps you only allow a small handful of trusted employees to set up vendors and subject the data entered into SAP to a rigorous, independent, quality assurance process. When you consider whether this control can sufficiently constrain a particular risk, you may find that the control doesn’t address the risk of making a fraudulent payment to an approved vendor. You should consider additional controls to handle that risk. The team also needs to assess the potential impact of this control on the payment-processing time for new vendors. It may cause you to weigh centralized vendor management (potentially higher quality and consistency) and decentralized vendor management (potentially quicker processing) differently. The team should recognize that for this control to be effective, SAP security controls must also be in place. The team needs to understand that the termination or transfer of an employee responsible for vendor management may necessitate a quicker change in SAP security assignments for that individual than the standard security maintenance process. Lastly, the team may find that this control works better for frequent vendors. It may not work as well with one-time vendors, so you may need to design additional controls for the latter. If you’ve been through an SAP implementation, you might find that these considerations are a new way of thinking (at least for many implementation processes). I share some techniques below to ensure that these considerations are effective.

How to Set the Stage

In a control-conscious implementation, each team member has a basic knowledge of the relevant risks and has the tools to design, communicate, and gain consensus on the appropriate controls. I suggest you hire an SAP risk, audit, and controls expert to lay the foundation for the control design effort and provide initial informational sessions for each functional team (e.g., procurement team, receiving team, inventory management team, and so on). This expert can provide the background for controls, discuss techniques for ensuring effective control design, and walk through the key risks your team members should address as part of the design phase. Longer term, they can assist in providing quality assurance over the final control design decisions. The idea is to provide each team member with the knowledge and tools to think through the control issues in the processes for which he or she is responsible. This allows the SAP risk, audit, and controls expert to spread his or her time across the implementation in more of a mentoring and quality assurance capacity. True risk and control experts might spend a short amount of time with each functional team each week to ensure that the control-design effort is on track and the tools are used appropriately. (For more information on designing effective controls and using a simple tool to guide the team along the necessary thought processes, see “Effective Control Design” below.)

Reporting Issues and Progress

One key decision you need to make as part of your implementation-planning cycle is how you intend to incorporate control design, configuration, testing, and validation into your overall SAP implementation project plan. I cannot suggest strongly enough that you detail specific control-design tasks in the project plan, rather than bundling them into other components of the process design plan. Organizations often begin with the assumption that if you communicate the importance of controls and you educate the team on control design, the team will naturally build controls as part of the process. Unfortunately, in the mad dash of an implementation, controls often take a back seat to looming deadlines. Typically, as the implementation deadline approaches, the completeness and effectiveness of control design decreases dramatically due to dueling priorities. Therefore, I recommend that you explicitly identify control design-related tasks and report them in the project plan itself. The overall level of detail is up to you, but at a minimum I recommend tracking the following milestones for each process:

• Process risks identified and prioritized
• Risk assessment and prioritization validated with internal and external audit
• Controls designed for each key risk
• Control design validated with SAP risk, audit, and controls specialist (as discussed previously, this is a specific role on the team)
• Configurable controls set up in SAP
• Manual and process controls incorporated into user training and education
• Configurable controls successfully pass testing

These milestones represent the minimum level of control-design detail that I would include in the project plan for each process in the scope. Notice that I included a testing line item for configured controls, but not for manual and process controls. That’s because the confirmation process for manual and process controls is actually the successful training and education of the users who will perform them. So, this confirmation process is likely to be included as a training milestone within the standard SAP project plan. By including your control-design activities in your project plan, you reinforce the fact that designing controls needs to be an integral part of the implementation, not a separate initiative. This approach sets a strong tone for the project and is likely to be a benefit if and when auditors become involved. In addition, it ensures a certain level of status-reporting through the normal project status-reporting process. Some of the most successful SAP implementers use a centralized content management system to provide the team with easy access to critical documentation about business risks and controls. Change management becomes an integral part of any implementation project since design decisions may change several times during the course of the implementation and content management makes the task infinitely easier. There are a number of high- quality, low-cost, Web-based content management applications from a variety of vendors, including SAP, on the market today.

Work with the Auditors

At some point in your SAP implementation, you are likely to find yourself collaborating with your internal and external auditors. Sometimes, the auditors may be leery about becoming too involved in the implementation because they need to retain their independence and remain objective (an audit requirement that restricts an auditor from assessing the results of work in which he or she has been closely involved — in fact or appearance). If you structure the interaction as I discuss below, however, I strongly recommend that you welcome audit participation. Even if your auditors are not SAP experts, they generally have more in-depth knowledge of business risks than anyone else. Thus, they have valuable knowledge that can contribute to the success of your project. While I recommend involving your auditors, the key is to establish the right relationship from the start and agree upon the rules of engagement (discussed below). Integrating control activities into your overall project plan is important. As your auditors become involved, I suggest that you include their activities in the project plan as well — again reinforcing the premise that the project plan should include all tasks necessary for a successful SAP implementation. Make sure you involve your auditors in educating your team members about which risks and controls to consider during the implementation. Your auditors are also a great source for identifying the inherent risks you should address during the process-design phase. They are likely to have a list of risks that you can use as a starting point for each of your processes. If they don’t, they should at least be able to provide some valuable insights into your brainstorming sessions. As far as ground rules go, there are a few upon which you should agree with any auditors participating in your project. The first set of rules relates to the auditor’s involvement in the implementation. Clearly, time is a highly prized commodity during an implementation. As such, the auditor should be highly respectful of the team’s time when conducting his or her activities. If possible, I recommend that the auditor relocate to the project team area for the duration of the implementation. This creates a sense of teamwork and helps facilitate knowledge transfer to the auditor. I also recommend requiring the auditor to attend all relevant team meetings for the full duration of the meeting. Having to repeat what happened in a meeting to someone who wasn’t present is time-consuming enough, and potentially having to revisit team decisions because the auditor raises concerns that weren’t part of the initial discussion can be severely detrimental to continued progress. Where an auditor simply cannot attend all relevant meetings, service level agreements (SLAs, which would outline your working relationship with your auditor) should ensure that they provide any desired input prior to the meeting so that the rest of the team can consider it. Then, the auditor should review meeting minutes and ask relevant questions within the period of time specified by the SLA. Another set of ground rules relates to how, when, and in what format to communicate potential audit issues. I prefer to report audit issues jointly and integrate them into the standard implementation-reporting process. This approach reinforces that the organization is working toward a common goal throughout the implementation. In addition, I recommend that the auditor work with the project manager to identify proposed solutions to include in the reporting process. The goal is not to make the project manager or the implementation team look bad, nor is it to make the auditor look good. The goal is to quickly address risks before delays increase the cost of corrections. The timing of when the auditors communicate issues is also critical. The reality of an implementation is: The more time that passes between making a decision and identifying an issue that may result in changing that decision, the more rework you may need to perform, the greater the cost of the change, and the higher the likelihood of pushing the project behind schedule. The expected behavior should be that the auditors immediately report any potential issue that affects project scope or configuration, even if they have not fully validated the issue. This may be a change for the auditor because most auditors issue their findings after they complete the entire audit, rather than in real time. Depending on your auditor’s experience, he or she may not even be aware of the impact on the project of typical audit-reporting cycles. The importance of timely reporting of concerns makes this one of the highest-priority ground rules. The goal here is to ensure that there are no late surprises.

Effective Control Design

Designing controls during an SAP implementation typically follows the process in Figure 1. In general, an early project-scoping effort determines control-design priorities. For the processes, locations, and risks that are in scope, you develop a set of expected controls (and depending on the size, scope, and nature of certain processes, locations, and risks, management may determine not to spend resources developing controls over these areas at this time). These controls may be configurable, manual, or system-dependent, with different mechanisms for assessing the controls depending on the type of controls you use. The results of initial control testing may require you to redesign the control before implementing it to ensure that it effectively meets your business needs. Ultimately, ongoing monitoring can influence how a control evolves over time. The key to effectively designing controls during your SAP implementation is to ensure that each team member who has control- design responsibility follows a consistent thought process. For this discussion, I refer to a control-design process documented using a Microsoft Excel- based template. You can use any documentation technique that works for you; however, you may find it helpful to follow along with the Excel template for the remainder of this discussion. If you haven’t already done so, you can download the Process Risk and Control Template file, which can aid the thought processes of your team members when they are considering control issues for their respective processes, at the bottom of this article. When completed, it also provides a great document for your auditors to better understand what you have designed and configured as part of the implementation. Having a complete set of documented controls at the end of your implementation is a great way to ensure an efficient audit when the time comes. As you review the Excel template, keep in mind that it contains some sample data designed to illustrate the concepts without overburdening you with too much detail. If this document were completed as part of an actual implementation, it would contain a significantly larger number of risks and controls, with much more detail supporting each one. In the template, the Risks & Controls tab uses Excel’s grouping function to expand and collapse columns and rows. Clicking the + or – to the left of the columns or across the top of the rows expands or contracts those areas, respectively.

Risk Inventory

Ideally, you would complete the first few columns of the spreadsheet during the implementation planning phase, before the design phase begins. Expand the rows containing data in column A (which contains the sub-processes) and column B (which contains the risks). The next several paragraphs discuss how to use these two columns. Each functional team should break its respective processes down into major sub-processes in Column A. In the example, the Purchase-to-Pay cycle is divided into the Procurement/Purchasing, Goods/Service Receipt, Payment, Vendor Master File, and Material Master File sub- processes. Your specific sub-processes may differ, depending on your application and your company. They will likely be more comprehensive than they are for this simple example. Under each sub-process, list the risks associated with it in Column B. Identifying and documenting the key risks associated with each sub-process before beginning the design phase allow the team members (once they begin designing controls) to focus on ensuring that they have addressed each risk — either with a configurable SAP control or with a manual control. You can do this entirely within your team, but your auditors might be able to provide a good starting point and give direction on process risks. Many internal audit departments — and most larger audit firms — have comprehensive risk matrices associated with common business cycles, such as Purchase-to-Pay, Order-to-Cash, Recruit-to-Retire, and so on. Sample risks for Purchase-to-Pay are shown in the template that can you downloaded. Upon completion, you can think of Column B as your checklist. You will eventually need at least one — and potentially several — controls for each documented risk in Column B.

Control-to-Risk Links

The next few columns in the template are completed during the design phase. If not already expanded, click the “2” in the header bar above the row numbers to allow you to see columns C through G. Column C lists the controls intended to mitigate the identified risk. In the example, note that the plan is to mitigate the risk of unauthorized purchases using four SAP controls: security, approval limits, workflow, and monitoring report X. I have numbered each of these controls (C1 through C4) to enable cross-referencing with other documents. For illustration purposes, let’s pretend we are part of the implementation team and walk through what our thought process might be for each of these controls.

• Security: One way to reduce the risk of unauthorized purchases is to limit the number of individuals who can initiate and approve purchases. After identifying this as a control, the team would ask how well this control addresses the overall risk. Limiting this ability within the organization ensures that most employees cannot make unauthorized purchases — without the proper security, employees can’t make any purchases — so, security reduces this unauthorized purchase risk to the population of employees who can initiate and make purchases. The team probably rightly concludes that security alone is not enough to fully address this risk, and thus they consider what other controls they can put into place.
• Approval limits: By establishing approval limits within the SAP system, the implementation team can further reduce the impact of unauthorized purchases. Combined with security, approval limits ensure that only a limited number of employees can initiate and approve purchases, and each employee has a role-specific monetary cap on the purchases he or she can make.
• Workflow: You can use workflow to further reduce the likelihood of unauthorized purchases. You could route approval to defined levels of management, depending on specific monetary amounts (e.g., the highest dollar purchases might require approval from C-level management). While team members may feel that the above three controls, if they operate correctly, would effectively reduce the risk of unauthorized purchases, they also recognize that the integrity of the controls to be built depends to a large degree on manual processes (described in the next few sentences), which may be prone to error. You need to set up security correctly to limit the number of employees who have the ability to create and approve purchases; if security is not set up properly, there is still a potential for problems to occur. You need to establish approval limits that are relevant to an individual’s role in the organization, and you need to maintain these limits as roles change. Lastly, the managers who are responsible for workflow approval must perform real reviews of purchases before they grant this approval.
• Monitoring report X: Just to be safe, the team decides to add one more control: monitoring a particular report within an SAP system (any report that the team feels contains appropriate information for an effective review) that management can review to ensure that overall spending doesn’t exceed approved limits. While this control doesn’t prevent unauthorized purchases, it does help management to detect potential problems and limit the overall impact of the risk. For illustrative purposes, note that using this logic results in the team identifying issues that it should monitor via an SAP report. If this report doesn’t already exist in your SAP system, you would probably want to create it as a custom report during implementation.

The team should follow this thought process for each risk identified within each sub-process. Determining the correct level of control involves a fair amount of subjectivity. Also, during an actual implementation, you should capture significantly more details about each control than shown here. At a minimum, I recommend that you note the following:

• When (specifically) should you perform the control (e.g., upon executing a particular transaction)?
• Who should perform the control (e.g., a specific employee, or a role such as “accounts payable manager”)?
• What action should you perform (e.g., route the purchase to the specified manager based on corporate authorization guidelines)?
• What conditions should exist to make sure the system performs the control (e.g., based on configured approval limits set up within your SAP system at the specific place) or to ensure the appropriate employee performs the manual control (e.g., as specified in the corporate purchasing policy acknowledged in writing each year by every employee)?

Status of the Control

As the implementation progresses through the design phase into configuration and testing, columns D through G facilitate tracking the status of each control. Column D would be complete after you have documented the details of the control. Column E specifies that you have configured the control (it is marked N/A [not applicable] for any manual controls). Column F indicates the current status of control testing. Column G denotes the inclusion of control-specific information in the relevant training and education programs. These details enable you to track control-design status more granularly than you would typically track in the formal implementation project plan, and they provide a means to ensure that designed controls are fully put into place before authorizing the related steps in the project plan. Before you go live with the implementation, every control should have a status of Complete or N/A in columns D through G. Of course, if the process changes before go-live, you may need to revisit these controls, potentially resetting the control status, until they have been validated against the new process.

Risk Evaluation of the Control

Following the control-design process above for every process affected by your SAP implementation or upgrade enables you to be much more resilient during an SAP audit than organizations that don’t consciously consider controls during the implementation process. To fully address your business risks — and shock and amaze your auditors — however, I also recommend that you think about the risks associated with the processes and functions you use as controls. With the control-design template, expand the final set of columns by clicking on the “3” in the header bar above the row numbers. This allows you to display columns H through M. Column H represents any additional risks that come with the control you’ve chosen. For example, if you use security as a control, you also need to consider the risk that security isn’t set up appropriately and to determine which additional controls would mitigate that risk. The risks are documented in column H, the relevant controls in column I, and the control status (discussed in the section above) in columns J-M. If you use authorization limits, you might consider two additional risks: that the limits themselves are inappropriate or that an employee may circumvent the intent of the authorization limits by purchasing an amount just below his or her monetary limit or by splitting purchases to stay within limits. For all of these control risks, the team should follow the process described above to identify additional controls that address these risks. In the example provided, I’ve left the Control Risk column (column H) blank for the workflow control. Can you think of any risks that the team should consider? How about the risk that a workflow approver goes on an extended leave of absence without assigning an alternate? Workflow wouldn’t receive approval on a timely basis. What about the risk that the workflow settings aren’t properly updated when an employee terminates or transfers, resulting in an outdated workflow? There are probably a number of other risks you can identify as well. In one organization where I worked, one of the employees was the son of the CEO, and they had the same name — senior and junior. The SAP workflow assigned some tasks to the son rather than the father. If the initial implementation team had thought through the risk of an inaccurate workflow setup, it might have established a control that would have prevented or detected this problem.

Upgrade-Specific Elements

Beyond what has already been covered, the mere nature of an upgrade adds a few other elements that you should consider:

• If you use an SAP segregation of duties (SoD) tool, such as SAP GRC Access Control, the upgrade may add some new SAP transactions that you need to assess and include in the SoD rule set.
• You may need to add some new controls (which are included in the upgrade or designed as part of the upgrade process) to the control documentation repositories used to track compliance with regulations such as Sarbanes-Oxley.

• Training should be a core component of the upgrade, regardless of its perceived complexity. SAP probably says it best in the guidance they provide as part of the SAP R/3 Handbook, Upgrading to SAP R/3 Enterprise: “Training is an issue largely ignored by many project teams, but it has a very big impact ….”

Out of Control

Failure to consider controls during an SAP implementation leaves your organization exposed to a potentially serious level of risk. It can also result in excessive costs and rework, and make audits of your SAP system time consuming and burdensome to your organization. Creating appropriate control understanding throughout the implementation team and providing a consistent set of tools and processes are necessary to ensure the proper control design. Include your auditor in the process, but set the ground rules early and manage and report on audit issues throughout traditional project status reporting. By following a simple set of guidelines and focusing on designing internal controls commensurate with the level of risk to your organization, you can not only significantly enhance the quality of your implementation, but complete your implementation effort with minimal impact to overall project activities. here