A major change such as an upgrade or implementation provides an opportunity to reassess to-be processes for compliance. It is best to remeasure and reengineer compliance processes at the early stages of a project. Waiting until later when these processes become embedded in the organization can be expensive in terms of the cost of implementation of the functionality in an SAP system. Furthermore, remeasuring or reengineering compliance processes in the late stages of a project may result in having to revamp the entire process.

Many manual business processes can be automated by leveraging the SAP system. This automation is not limited only to inherent configurable functionalities of the SAP system that can be enabled; additional activities may be enabled from custom development. For example, configuring a closing cockpit (standard SAP functionality) for facilitating smooth closure of books has a major impact on how the closing activities are performed and results in a complete reengineering of the closing process. However, a decision to implement nonstandard approval workflow or custom reports is an example of a custom requirement that may cost less if identified early in the implementation rather than later. Therefore, it would be prudent to reassess the to-be processes at the initial stages instead of later when the processes become ingrained in the organization.

An effective, efficient compliance program during an SAP implementation or upgrade has the following objectives:

• Design the right internal control structure
• Align and integrate  compliance initiatives with SAP implementation activities

What Is the Right Design of an Internal Control Structure?

The right internal control structure follows industry best practices and available frameworks such as the Committee of Sponsoring Organizations of the Treadway Commission’s (COSO) — Internal Control — Integrated Framework/Risk Management — Integrated Framework;  the IT Governance Institute’s Control Objectives for Information Technology (COBIT); ISO 17799; and the Canadian Institute of Chartered Accountants’ (CICA) IT control guidelines. The right internal control structure also is supported by an organization’s policy and procedure documents. It embeds the correct mix of controls with standardization, automation, and optimization. It also establishes effective assessment and monitoring procedures (Figure 1).

Figure 1

Design of internal control structure

I now discuss the compliance initiatives that should be taken during an SAP implementation or upgrade.

Set Up a Compliance Office

During an SAP system implementation, a compliance office is a team formed by the global compliance officer, a local compliance officer, unit controllers, and a business process control expert (usually an outside SAP system consultant with exposure to various compliance framework and audit procedures). Clear lines of communication and responsibility should be identified for correct reporting and remediation activities. Functions of a compliance office include:

• Deliberate on alternative proposed controls considering cost benefit analysis and feasibility
• Strive to standardize, automate, and optimize controls leveraging SAP and other applications
• Facilitate the selling of designed controls to process or business owners
• Approve the final controls structure
• Establish a reporting structure or single point of contact during the implementation project
• Liaise with external auditors for their acceptance

How to Leverage an SAP Implementation for Compliance

A key step in leveraging an SAP implementation for compliance is aligning the compliance initiatives with the SAP implementation activities. You save effort, time, and resources. You also eliminate duplication by enabling the business process control experts to participate in business process understanding and requirement-gathering workshops with the SAP system implementation team.

This step enables business process control experts to provide their input on the design of new processes at the right time so that the new controls are captured as a list of requirements from the very initial stage. Functionality relating to controls is tested as part of unit, integration, and user acceptance. Business process control experts can ensure the appropriateness of the requirements captured for controls and review the appropriateness of testing that the SAP team performed. This step results in reduced efforts on testing and saves money as making changes after processes have been finalized is expensive. It helps in not only establishing process controls but also embedding access controls into business processes from the start.

Standardization is required to streamline processes and ensure that there is no duplication of effort. Various audit reviews reveal that lack of standardization leads to duplication of effort, which results in cost inefficiencies. For example, if entity-level controls are identified, you do not need to test them again while testing for a unit or location in the organization. Another example is if a set of standard risks and control objectives is identified for the entire organization, then the requirement to discuss and build the risks, control objectives, and control activities performed for each unit or location can be eliminated. Each unit or location can simply identify the risk and control activities applicable to its business processes using the standard list with few changes. Therefore, standardization involves identifying standard processes, risks, control objectives, control activities, and master data for the organization. This initiative begins at the process level. It is wise to identify global blueprint documents identifying standard processes and then look for 10 to 15 percent customization for rolling out to each location or group of locations. Efforts are then made to list the standard process risks (based on global blueprint documents) applicable to the whole organization and then compile a list of standard control objectives to address those risks.

You should focus on generating a standard list of control objectives for the same risks and processes across units, geographies, and companies. It is control activities that may differ owing to applicability, feasibility, and a cost benefit analysis for a unit, geography, or company. However, you should try to standardize as much as possible. Compliance requirements also include maintaining adequate and comprehensive documentation in terms of policy and procedures. Therefore, efforts should be made to identify standard documentation (e.g., process documents, control documentation, and test templates) and results that can be centrally located for easy availability, maintenance, usage, and review. This step also enables an organization to identify and leverage an entity-level control efficiently.

The next essential step is to automate controls in an SAP system. This step results in efficient and effective use of your SAP ERP system. It also reduces the cost of compliance by cutting down your efforts on testing. SAP provides a wide range of controls to ensure compliance, including configurable, reporting, and security (access) controls.

Configurable Controls

Built-in configurable controls include:

• Edit checks (e.g., disallowing a field for change or allowing only specific types of input, such as only numbers can be entered in a specific field)
• Tolerances for document completeness or user actions (e.g., requirement of mandatory fields while creating a new account, vendor, customer, or company code or user tolerances for postings such as inventory differences)
• System population fields (e.g., at a specific user level, a price field in an invoice can populate with no changes allowed, or changes are allowed up to a specific tolerance limit with an approval requirement beyond it. The SAP system then sends automatic email alerts to seek approvals and automatic updates of changes once they are approved).
• Checks to prevent duplication of accounting postings (e.g., identifying duplicate invoices or vendors)
• Dual authorization for sensitive fields (e.g., bank key, bank country, and bank account)
• Reason codes (i.e., defining a list of reasons to be picked up from a drop-down menu for approval, rejection, or cancellation)
• User-defined errors (i.e., providing liberty to define error messages at specific events)
• Warning messages (e.g., a warning message may be defined for a down payment previously made to a vendor before payment). Similar warning messages can be configured based on control or business requirements.
• Automated posting keys for specific user-defined postings
• Default and predefined master data and related controls to check duplicates (e.g., vendor duplicates)
• Log reports for any changes in the documents, postings, and master data by the user with time stamps
• Store all postings in unique documents that can’t be altered. A document can only be reversed with a requirement of specific reasons for the change required and not deleted.
• Define work flow procedures for approval needs (e.g., customer credit limit block and release approval)
• Automated reconciliation of SAP General Ledger with subledgers
• Automated  programs (e.g., an automatic payment run program is used to make payment by creating checks, electronic transfers, or bank pay link files, for vendors or customers. This program’s flexibility enables you to define payment features that vary from country to country, such as payment method, payment form, or data carrier specifications. All the entries made by using this transaction create a clearing document for respective entry).
• Closing cockpit. A closing cockpit provides controllers with a bird’s eye view of the closing process. A control requirement for timely closure of books may result in building up a control with a person in a shared accounting group to initiate the closing process. Identified persons for each module (e.g. Accounts Payable, Accounts Receivable, General Ledger etc.) in an SAP system confirm on closure for their modules or track the progress of closing activities while period-end closing entries are completed. It is only after closure confirmation from all the modules that books are closed and data is rolled up for group consolidation.

Table 1 provides examples of some of the configurable controls in various process areas.

Table 1

Examples of configurable process controls in SAP

Reporting Controls

Automation activities also include introduction of semiautomated controls where full automation is not feasible. One example of a semiautomated control is the use of reports for review. In addition to custom reports, SAP provides various other standard reports that form part of detective controls. During implementation, efforts should be made to maximize the automation. Some examples of useful reports from SAP that can be part of detective controls are:

• Report for open and close periods
• Changes to master data
• Possible duplicate invoices
• Error log post importing an electronic bank statement

Access Controls

Access in an SAP system is governed by the authorization concept. Access to programs, transactions, reports, and services should be protected and provided only as needed. First, users of an SAP system are identified and grouped based on their job descriptions. Based on these groups, primary roles or base roles are identified.

Care should be taken to identify and remove inter- and intra-role conflicts where users are provided with more than one role. To further simplify, this activity can be first performed for a unit (can act as a prototype) to finalize the standard list of transactions, services, and programs, and grouped into roles based on job descriptions to be later rolled on to other units or locations across the organization. Business process control experts also need to ensure that appropriate access for performing specific controls (e.g., a log report review or approval for a customer credit block release) is provided to identified control owners.

Optimization of Controls

Once the automation efforts are baselined (i.e., you identify the control activities for automation), it is essential to identify the key controls. You achieve this by revisiting the internal control structure. As part of the process, various checkpoints may be enabled, but as part of the continuous monitoring and testing processes, it is essential to identify the critical checkpoints. Failure of these critical checkpoints means the failure of the control objective; therefore, the controls must be tested frequently. These critical checkpoints are key controls. Identifying key controls for testing helps keep the compliance costs within reasonable limits. At this point it is important to reassess the control structure for the right mix of controls, taking into consideration the following parameters:

• Prefer preventive controls over detective
• Prefer automated controls over manual controls
• Differentiate between key controls and other controls
• Leverage entity-level controls to reduce testing efforts

Once the final list of controls is available, each control can be divided for configuration, access, and report requirements. This feature enables a business process control expert to track and validate the functionality that has to be activated in the SAP system.

Table 2 shows how a control can be divided into various configuration, access, reporting, and manual (procedural, outside SAP) requirements.

Table 2

Division of control activity

Continuous Monitoring

A correctly designed internal control structure also establishes the processes for continuous monitoring in terms of periodic assessment cycles, supervisory review of controls, audit committee inquiry, and quality assurance reviews. It also includes capturing proactive compliance requirements based on changes in the compliance environment.

Using SAP BusinessObjects for Continuous Monitoring

An assessment should be made for addressing the need to use SAP BusinessObjects GRC solutions for continuous monitoring of controls to further reduce the cost of compliance.

SAP BusinessObjects Process Control

SAP BusinessObjects Process Control enables an organization to define, plan, and automate the assessment procedure, including remediation with appropriate sign-offs for completion. It is delivered with a standard rule set that can be adopted readily or tweaked based on applicability in the organization to test compliance or monitor underlying transactions to detect deficiencies. Some examples from each process are shown in Table 3. Besides the standard reports, SAP BusinessObjects Process Control also can query reports per required schedules.

SAP BusinessObjects Process Control also acts as a central repository for its compliance documentation (e.g., policies and procedure documents, central risk and control library, test templates, and test results). Furthermore, this activity of centrally storing the data, facilitates identification of entity-level controls as it becomes easier to identify the controls that are not specific to any unit or geography or business, but are applicable to an entire organization. SAP BusinessObjects Process Control enables continuous and real-time monitoring, with reduced testing efforts and cost by automating testing and monitoring procedures (via alerts, notifications, reports and workflows) for SAP and non-SAP systems. It provides a unified framework that allows alignment of various business processes, compliance, and risk methodologies.

SAP BusinessObjects Access Control

In SAP BusinessObjects Access Control 10.0, access risk management (formerly risk analysis and remediation) is used for running analysis to monitor access in an SAP system. It comes with a standard rule set that is tweaked for specific business requirements. A report can be scheduled for identifying conflicts or deficiencies in an SAP system using the defined rule set. These reports can be sorted by role, business process, and user, along with level of severity to help analyze and identify the root cause of the violation from different angles. The software further enables you to perform risk mitigation on the identified deficiencies.

Business role governance (formerly enterprise role management) automates the processes of defining roles, assigning authorizations, obtaining approvals for creation, generating roles in the target system, and finally in their ongoing maintenance. It is also used for defining derived roles and composite roles. Conflicts are easily identified by the system at the role creation stage itself. It provides the facility to simulate at the user, role, and position levels along with role comparison capabilities and, thus, analyze the impact of changes in access for preventive compliance.

User access management (formerly compliant user provisioning) automates the process of provisioning access to users and obtaining the approvals required. It allows users to request access directly through a workflow. The system automatically checks for segregation of duties (SoD) issues, removes SoD or critical access risks, and implements mitigating controls to assist the approver in his decision to approve.

Emergency access management (formerly superuser privilege management) automates the process of provisioning emergency access by allowing the use of firefighter log-in IDs with superuser privileges in a controlled and auditable environment. The system automatically sends supervisors the log-in data and logs of activity performed for increased visibility.

The application provides a wide a range of reports for management oversight — namely, user provisioning reports, potential risk reports, actual risk reports, policy reports (SoD rules library and mitigation controls review report), and emergency access reports. With all GRC solutions being recoded to the ABAP stack —  namely, version 10.0 of SAP BusinessObjects Access Control, version 10.0 of SAP BusinessObjects Process Control, and version 10.0 of SAP BusinessObjects Risk Management — all the redundancies in administration, configuration, setup, and end-user training are eliminated. All the SAP BusinessObjects GRC solution components together provide a unified compliance platform with adequate rule sets, mitigation controls, automation, and reporting capabilities for reducing the cost of compliance.

Based on SAP’s standard accelerated methodology (ASAP), any implementation or upgrade can be divided into project preparation, business blueprint, realization, final preparation, go-live, and support. The detailed activities that can be performed at each of these phases of an SAP system implementation are summarized in Figure 2.

Figure 2

Align compliance activities to an SAP system implementation