Many companies use the number of help-desk tickets per area as the metric for identifying problem areas after an implementation. I’ve worked on several implementations of Access Enforcer and have seen some usability concerns arise. Some companies believe that simply implementing a tool such as Access Enforcer immediately diminishes help-desk tickets and usability issues, but without proper training and modifications some problems may still exist.

I’ll present three tips to improve your usability of Access Enforcer:

• Modify the welcome page to simplify status checks
• Communicate server restarts to address performance issues
• Complement the multiple-system request process

Implementing some best practices can cut down on ticket requests and simplify the way users work within the system. Doing so during your initial implementation allows you to avoid usability concerns to begin with and have your system running smoothly from go-live.

Modify the Welcome Page to Simplify Status Checks

The first usability fix you can make involves modifying the Access Enforcer welcome page to expedite the process of checking the status of end-user requests. A company I worked with was in the mature stage of an SAP implementation, and users had no problem finding the Access Enforcer Web page, which included a user request form. However, users found it difficult to check the status of their requests because they were required to select a radio button and then log into the Access Enforcer system. Forgetting to select the button kept the users from checking the status.

After careful review, we did not identify any risks with allowing users to review their requests without logging into the system. With the help of SAP, we modified the Access Enforcer welcome page by placing a simple text box in the corner of the page where an end user could enter his request number and the report to pull up the status of his user request (Figure 1). After applying this change, tickets associated with checking on the status of a request were all but eliminated.

Figure 1

Status Check request number as a text box

Communicate Server Restarts to Address Performance Issues

In some cases you need to schedule application server restarts to address performance issues. When performing these restarts, you need to communicate when they will happen and how long they will take so your users are prepared. One company I worked with searched for a solution by reviewing the Access Enforcer code with a member of the Web team.

We found an area in the HTML code on the Access Enforcer server to place notifications on the logon screen that the system was going to be down for emergency maintenance. The SAP security team also knew that the possibility of restarting the Web server at any time was high, so we created documentation points within the code so that they could easily find the notification areas in the future. We used the following process to create the documentation points:

• Step 1. Log into the Access Enforcer server as the administrator
• Step 2. Make a backup of the file endusertop.htm (.Net version)
• Step 3. Open endusertop.htm in Notepad
• Step 4. Find the code that contains the text seen on the login screen
• Step 5. Add identifiable comments within the logon screen code

You can see a sample comment in Figure 2.

Figure 2

Sample code comments

Complement the Multiple-System Request Process

Users often need access to more than one system, but Access Enforcer doesn’t easily communicate that they need to click on a separate icon to select a different system. As an example, this can result in a proper request for access to the R/3 system, but a missing request for access to BW (Figure 3). If you click on the magnifying glass icon next to the Systems field, the system asks the user which system he would like to request access (Figure 4). One company I worked with implemented several initiatives that reduced the number of requests for other systems, including a security role redesign, documentation update, monthly meetings with security liaisons, and additional training for the help-desk group.

Figure 3

SAP user request form

Figure 4

System access screen

During focus groups with power users and managers, the security team learned that new users understood their job responsibilities much better than the single line description of the security roles provided to them within Access Enforcer. Individuals wanted to select job responsibilities rather than a technical description of the access contained within the role or a particular transaction code. Although the client only had two systems, R/3 and BW, the roles on each system did not tie into one another with respect to job responsibilities. Users did not know that they had to select access from the BW systems.

Changing the icon on the user ID request form was not enough to improve the usability of the user request form, but modifications to Access Enforcer required significant code changes.

Rather than replace the functionality, the SAP security team complemented the process. We redesigned the security roles to match job responsibilities and the business areas developed business descriptions for each of the new security roles. Instead of composite roles that accumulated access over time, we switched to more granular single roles that contained all the transactional access needed to complete a business process. Users may now select a role called Display General Ledger – New York, rather than S:FICO_FINANALYT1.

We modified the role-naming convention to help security liaisons identify roles by job responsibility as well as to assist the SAP security and compliance teams in identifying roles that were sensitive in nature.

For example, the role-naming convention now includes a sensitivity indicator with the following options:

• 1 = Public
• 2 = Sensitive (manager approval needed)
• 3 = Critical (require a discussion with the end user before granting access)

With the sensitivity indicator, the security team could instantly flag any requested security roles. The team then updated the Access Enforcer default HTML documentation to reflect changes suggested by focus groups.

Over time, the SAP security team plans to develop a simple Web application wrapper that asks more user-friendly questions and then populates the initial screens on the user request form. Another option for the team is to produce a wizard using HTML that would ask the users various questions to identify the roles that they need to request. Nevertheless, the end result of redesigning the security roles was a drop in the number of issues related to incorrectly completed access request forms within Access Enforcer.

With the overall reduction in administrative support on the tool, the client began to realize its anticipated return on investment after some simple fixes and workarounds for its usability settings.

Jean-Paul Calabio

Jean-Paul Calabio is a senior SAP security/GRC consultant with more than 10 years of international experience implementing SAP security and four years of implementation experience in SAP GRC Access Controls applications. Jean-Paul is a Certified Information Security Manager (CISM) and a Certified Information Systems Auditor (CISA) and was the lead for the first implementation of Access Enforcer.

You may contact the author at jp.calabio@calrosa.com.

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