JOnline: ERP Postimplementation Problems

Problems associated with enterprise resource planning (ERP) implementations become more rampant during the postimplementation phase because once users learn their way around the system, they can test its limits, setting off shockwaves that can devastate an otherwise successful control environment. While extensive integration and acceptance testing flushes programming errors and exercises pathways through the system, postimplementation brings an explosion of bug reports that hits the maintenance team, along with a slew of frenzied requests for new functions. As a result, the postimplementation phase requires an ongoing process of improvement and fine tuning. It is the greatest challenge to audit, because an audit is expected to unravel the root of problems in the ERP processes and provide effective solutions.

Postimplementation reviews reveal the unique learning curve that occurs for experienced users after the implementation of an ERP system. This learning curve is different from that of systems used by clerical workers for routine tasks. It often takes many months for experienced users to get comfortable with the system because early in a system’s life, these users tend to resist using it for their important work. They already have a set process and comfort level in getting their work done, and the complex ERP systems may appear threatening and intrusive.

Many experienced users (at all levels of seniority) secretly harbor a fear of appearing incompetent by failing to master such a tool. In response to these fears, many experienced users greet the new system’s implementation by continuing to do things as they always have, though they do log on to the new system occasionally to demonstrate to management that they are giving it a try. They usually use the features of the system that require the least effort to learn and that pose the least risk of error. These patterns can be seen if a monitoring function is included that reports statistically on which functions of the system are being used, how often and by whom (i.e., monitoring postimplementation).

Typically, some users use the system only to receive e-mail and look at calendars created by their secretaries. They do not use the document creation routines themselves or store files in the document database. They may often override sophisticated automatic processing and use only manual functions that give them a greater feeling of control. These users also may prefer looking at reports to using an online inquiry.

It takes a period of months for users to begin to feel comfortable with their new tools. However, at some point in the ERP system's life history, as users begin to see the advantages of the new system, they gingerly begin to explore its functions, gradually getting over their shyness as their efforts are greeted with success. After all, the system would not have been implemented in the first place if it were not a terrific aid. Finally, as the postimplementation period sets in, a critical mass of users emerges—users who are enthusiastic about the system and, more important, are beginning to understand from a functional standpoint how it operates.

At this point, an explosion takes place. Monitoring programs, if they are in place, suddenly show a tremendous upsurge in system use by all users. If the system includes communication features, such as electronic mail or work group computing, enough people in the user group are sufficiently comfortable with these features to begin to use them instead of the telephone or paper documents. If the system tracks investment or accounts, the users may start relying on online inquiry in place of hard-copy reports, and use all the sophisticated transactions with which they have been provided.

Finally, having mastered the system, the users begin to get creative with it. Now they are likely to apply their functional understanding of how the system appears to operate and try to push it a step further than it was designed to go. They start using the system to deal with (or attempt to deal with) situations that were not envisioned by the system’s designers, no matter how hard the designers tried to imagine the system in operation.

It is at this point, when a critical mass of users is fully using the system, bringing to it all their ingenuity and creativity, when postimplementation aftershock strikes and bug reports start flooding the maintenance group. The bugs they report are rarely trivial and are difficult to track down. Many of these bugs result from users doing tricky things with the system in hopes of "faking it out." For example, some users understand the way a parameter file controls what they can and cannot do with the system, and they begin to alter parameters temporarily so they can slip in transactions that contain combinations of field values needed in a particular case but not anticipated by the system’s designers. Without such finagling, the transactions would not make it through a series of online edits, but with the finagling they will. Having made their changes, the users then politely change the parameter file back to its earlier values. The records generated by these tricks cause problems of which the administrators are not aware in the subsystem. It takes major detective work to determine the source of these illegal records.

At the same time that these bugs occur, requests begin to Many experienced users (at all levels of seniority) secretly harbor a fear of appearing incompetent by failing to master such a tool. pour in from the same users for more function. The functions requested are often complex, and user management may start wondering why such "obvious" functions were not included in the original system's design.

But this slew of system requests is not a sign of bad design; rather, it is a sign of the system's success. It shows that users have accepted the system and are putting it to use. It also demonstrates that the experienced users are confident enough to go beyond a cookbook approach to using the system and are becoming creative and innovative partners in the system’s design. Now, having digested the system that their representatives said they wanted, these sophisticated users want to push the system’s limits further. It is highly unrealistic to expect representatives of system groups or user groups to be able to design into the initial version of a complex ERP system every feature that experienced users require; that is why commercial ERP systems are developed in a series of releases.

Why Aftershocks Can Devastate

The complex and challenging requirements posed by the ERP system's newly sophisticated users emerge just when there is no one left on the project with a good grasp of the project's existing design or with the analysis and debugging skills needed to meet the users' new needs.

Management, lulled by the system's initial months of quiet and certain that excellent ERP implementation methodology has finally paid off, tends to strip projects of capable people, sending them on to hot new projects. Thus, the users do not get the changes they need at the time they are most excited about using the system.

Just as damaging, they may get the changes, but either the changes do not work properly or they break other previously working parts of the system. This, unfortunately, can set the stage for an ongoing adversarial relationship between the users and the ERP system's department. In the worst cases, managers involved in the ERP system's implementation are blamed for producing a system that has become an embarrassment to the systems department.

How can one best prepare for postimplementation aftershock? There is no way to avoid aftershock in the project’s postimplementation phase. It is a maintenance phase phenomenon and should be treated as such. The position that maintenance can be omitted or bypassed by "correct" implementation is unrealistic and fails to give the maintenance phase of a project the respect it deserves. Aftershock also cannot be eliminated during the testing phase, unless the test phase is expanded to include the acquisition of a critical of mass of experienced users. In the test phase, those doing the testing are either those who developed the specifications for the system (who are too familiar with how the system is expected to operate to truly stress it in new and ingenious ways) or they are the "real users" who have not yet shifted gears from their current non-system-oriented methods to methods in which the ERP system is an integral part of their jobs. Only the emergence of a critical mass of users creates the stress that can result in postimplementation aftershock. Monitoring the system usage can determine when that critical mass has formed and whether the system can withstand its pressure.

It is vital to expect aftershock to occur and to budget for it. Ideally, project management will consider this phase a part of final testing and budget for it accordingly. It is essential to retain the services of the people who implemented the system, since it is at this stage that users request the most useful and, to them, necessary enhancements to the system. If the project depends heavily on outside consultants for programming support, heavy consultant support will be used for this phase—not just, as is often the case, for three months after implementation.

Prepare User Management

User management should be prepared for the advent of this phase, and should understand that its emergence is a sign of the system’s success and proof that the users are really using it. Some of the implementation budget should be saved for the resources that will be needed to participate in this final fine tuning of the system’s design.

Methodology should not be abandoned just because implementation is over. Most implementation groups now operate under the influence of some kind of ERP implementation methodology. Most also require some kind of design review and usually demand that documentation be produced along with system design. Unfortunately, since the aftershock occurs when implementation is over and maintenance has begun, methodology all too often becomes a thing of the past, replaced by a bug-oriented, change control system that controls code fixes at a module inspection level.

Thus, system enhancements made as a result of postimplementation aftershock are often made without the benefits of ERP methodology. These enhancements are often treated as independent code fixes rather than as a return to the system analysis and design phase. Usually, these enhancements are not made one at a time, but are proposed and added to the system at the same time as a whole constellation. Unless they are managed as a unit, using strict ERP life cycle methodology assures disaster. Since many of these new user-originated features are highly sophisticated and very important to the system’s ongoing integrity, it is vital that they work. For this to happen, they must be developed, coded and tested with the same rigor as the original system. Otherwise, they will fail spectacularly in a manner that will give the entire ERP system team a black eye.

Finally, during the frenzy of system testing, many implementation managers tend to postpone adding the many small changes that the users’ representatives come up with during the latter part of the implementation process. Rather than risk falling behind on tight implementation schedules by attempting to add them to the system during testing, they postpone these design change requests for six to 12 months after implementation. Their thinking is that, after six months, the system will have become stable, and these expected changes can be quietly added. Nothing could be further from the truth. It is better either to put expected changes in right after implementation during the “quiet period” that occurs before the users really take to the system, or wait until the aftershock has occurred. Otherwise, attempting to implement the new code required by these many small changes simultaneously with those for the enhancements to satisfy newly sophisticated users can quickly destabilize the most stable system. The many months of hectic debugging that can ensue can give what may have been a good ERP system a bad reputation from which it may never recover.

Monitoring Aftershock

If the thought of postimplementation aftershock makes one quake, take heart. There is a way to prepare and protect the project from disaster by measuring stress on a system. The best way to track aftershock is to design a function into the new ERP system that monitors system usage in terms of transactions or function used and frequency of use, breaking that usage down by individuals. This information is usually available in the system already but is not presented in an accessible report format. This function should generate reports that go to project management on a weekly basis during the first months of the system’s life, and it is a good idea to have a version of this information sent to user group management. These reports will give information that is helpful in several respects.

By identifying shy users, the ERP system makes it possible to give extra help to those individuals who most need it early in the ERP system’s life history, thus accelerating the learning curve for the group. Ideally, those responsible for training users can send someone to drop by users’ desks casually and give inconspicuous help to those who need it most without in any way singling them out as deficient.

Such monitoring may turn up surprising news that whole sections of the new ERP system are not being used, and indicate that a lot of aftershock activity is expected in these areas. For example, if the new system is being phased in and is being used only for new customer accounts until some older system is converted, a whole subset of transactions appropriate for older accounts may never be used. These transactions are the ones most likely to show up on bug reports a year down the line when the new accounts have matured. It is particularly important to track this because the conversion of older systems, along with the enhancements of the newly implemented ERP systems, is often scheduled for the period six months to a year after implementation because that is when the ERP system is expected to be stable. By avoiding a mix of conversions and aftershock, both phases of the project can be completed with a minimum of confusion.

SAP R/3 Overview and Audit

SAP R/3 is one of the most complex ERP systems, and auditing in this environment can prove to be quite a challenge. While SAP R/3 has been around for quite some time, the knowledge base regarding audits in this environment is still evolving.

An audit can be performed for various reasons based upon the organization’s needs. It might be a preimplementation or postimplementation audit or an ongoing audit performed to monitor system integrity or test controls based upon management’s control objectives.

One of the first challenges an auditor faces is to determine the scope of the audit. To fully understand scope, one needs to understand the SAP R/3 organizational hierarchy known as the organizational model. While the organizational model can be flexible and complex, once configured, it has a permanent impact on the organization. The organizational model is designed and configured in each module and, based upon this design, the system tables are set up accordingly.

SAP R/3 Organizational Model

System

At the top of the organizational model is the system or instance. A system is a stand-alone set of hardware and one instance of the SAP R/3 database. A system usually has a single database server. However, a system can have several application servers, each running the SAP R/3 software. In a typical SAP R/3 landscape, there are three systems: development (DEV), quality assurance (QAS) and production (PRD). Each has its own functionality and purpose in the SAP R/3 environment.

Configuration is usually done in DEV, all testing is performed in QAS, and production or live data and transactions are carried out in PRD. Unless it is a preimplementation review, the auditor can usually limit his/her work to the production system. In large implementations, each system resides in its own environment, and data transfer between the systems is controlled. If there are multiple PRD systems in an organization, each PRD system most likely requires its own audit.

Client

The next level in the SAP R/3 organizational model is the client. Technically speaking, a client is a logical separation of the database. There are some default clients in the SAP R/3 system that are recommended by SAP and typically one production client. The data of one client are not accessible by another client in the same system, because most of the data reside in client-dependent tables or are specific to that particular client. However, some data are managed at the system level and are shared by all the clients in the system. These reside in client-independent tables. Due to the nature of the system setup, each client usually requires its own separate audit.

The three default clients in a typical system are clients 000, 001 and 066. Just like the three SAP R/3 systems in the landscape, each client has its own functionality. Client 000 includes base parameters for all applications, standard settings and configurations for controls and, therefore, is a special client for the system. It contains the client-independent settings.

Client 001 is a copy of client 000 and, once configured and customized, its settings are client-dependent. This is the client that is used to set up or copy other clients in the system.

Client 066 is reserved by SAP and is used for troubleshooting. It is also called the Early Watch client.

In addition, another client exists in the system and is typically the production client. In rare instances, one might find more or less than four clients. A system administrator must justify to an auditor the specific reason for the deviation from the SAP recommended setup. System integrity may be compromised with the existence of each additional client beyond those previously mentioned.

Chart of Accounts

Typically the account number in a standard general ledger chart of accounts denotes all the organizational and account information. Therefore, in a large organization one is used to seeing a chart of accounts that contains a large number of digits. Since, in SAP R/3, the organizational information, such as company code, resides separately, the account numbers may not contain a lot of digits.

The chart of accounts resides higher than the company code, which allows different companies within an organization to use the exact same chart of accounts. The same chart of accounts may be maintained in different languages.

Company Code

Company code is the unit within the organizational model that contains the general ledger. It is typically a legal and accounting entity for which a balanced set of financial statements is produced.

There are other components in the organizational model that are configured at the module level and that an auditor needs to understand to set up the audit scope.

A typical SAP R/3 review is performed in two phases. One of the phases is to review the technical aspect of the system or the SAP R/3 Basis component, and the other phase is a review of the business processes or cycles, such as expenditure or revenue. Due to the complexity and extremely technical aspect of the system, SAP R/3 reviews require a person who understands this environment and is trained to perform such reviews.

SAP R/3 Authorization Concept

Fundamental to SAP R/3 security is the authorization concept. To get an understanding of SAP R/3 security, one needs to thoroughly understand the authorization concept. The authorization concept allows the assignment of broad or finely defined authorizations/permissions for system access. Several authorizations may be required to perform a task such as creating a material master record. Based upon design, these authorizations can be limited to:

Access to the transaction code (TCODE) to create a material master

Access to specific material

Authorization to work in a particular plant in the system

Authorization Object

Authorization objects can best be described as locks that limit access to SAP R/3 system objects, such as programs, TCODES and data entry screens. Depending on the SAP R/3 version, there are approximately 800 standard authorizations.

There can be 10 fields in an authorization object, but all 10 fields are not used in all objects. The most common field in an authorization object is the activity field. These are predefined activity codes that reside in a table named TACT. Examples of activity are "01" create or generate, "02" change, "03" read, "04" print or edit message, and "06" delete. The next most common field is an organization field, such as company code or plant.

Authorization objects are classified and cataloged in the system based upon functionality, such as FI (financial accounting) or HR (human resources). These classifications are called object classes.

Developers and programmers can create new authorization objects through the developers' workbench called ABAP Workbench in SAP R/3. ABAP/4 is a 4GL (fourth-generation programming language) that was used to develop all SAP R/3 applications. It stands for Advanced Business Application Programming Language.

Authorizations

Authorizations are the keys that can open the authorization objects, and they contain the specific information for field values. For instance, an authorization contains a specific set of values for one or all the fields of a particular authorization object. If a field is not restricted, an authorization will have an asterisk (*) as a field value.

An example of an authorization is as follows:

Field

Value

ACTVT (Activity)

01

BUKRS (Company Code)

0010

This particular authorization grants users access to create for company code 0010 the specific object that is locked by the authorization object, such as a purchase order.

The following authorization will grant total access to all the activities for all the company codes:

Field

Value

ACTVT (Activity)

*

BUKRS (Company Code)

*

Profiles or Activity Group

Authorizations are not directly assigned to a user, but to authorization profiles. There are simple profiles that can contain up to 150 authorizations. Two or more simple profiles are then assigned to a composite profile. SAP R/3 has standard composite profiles grouped together for functionality. For instance, a profile for accounts payable accountant contains all the authorizations to perform that job function. The most talked-about profile in SAP R/3 is called SAP_ALL. This profile contains all the standard authorizations with all field values with "*" and grants unlimited access to the system.

User Master Record

User master records contain specific information regarding the user, such as dialog and system. They also contain other user information such as address, valid dates, user group and, most important, the profile information for that particular user.

There are four default SAP R/3 users: SAP*, CPIC, DDIC and EARLYWATCH.

SAP* is the default system superuser with SAP_ALL profile. When a new client is created in an SAP system, the SAP* account is created by default. The Common Programming Interface Communication (CPIC) user is used for program-to-program communication within the R/3 system.

User DDIC is the ABAB/4 data dictionary maintenance and software logistics user. This is used for certain installation and setup tasks and should not be deleted.

Authorization Checks

How does SAP R/3 know how to check for authorizations? All this information is hard-coded to the programs or ABAPs via authority-check statements. Since most SAP R/3 ABAPs contain authority-check statements, it is a good policy for an organization to have standards to include authority-check statements in customized programs.

SAP R/3 Basis Component Review

An SAP R/3 Basis component review is a sanity check for the implemented system and must be performed after an implementation or upgrade and at least annually thereafter. One can perform an extensive Basis component review or a fairly high-level review.

Performing a high level Basis component review is discussed in the following section.

Basis Component Review

The Basis component is an integral part of the SAP R/3 system and is the layer in which all the system functionality resides. Each R/3 system has its own Basis component, which is shared by all clients and modules in the system. The Basis component is ubiquitous throughout the R/3 system. The Basis component controls system analysis and customization, structures and control, processing, programming, data and storage, and operations and control.

Steps that are recommended in performing a Basis component review include:

Run the RSUSR003 report. Within a minute of reviewing this report, the pulse of the system can be reviewed. It provides high-level information about the SAP R/3 system. Figures 1 and 2 are screen shots of this report.

Review the RSPARAM report. This report lists the system parameters with the default values and the changed values. While some of these are technical parameters, the parameters

Review the USR40 table for entries. The list of prohibited user passwords is populated in this table. Some organizations go to extreme lengths and populate this table with the entire dictionary. At minimum, this table is populated with some common entries such as months, days of the week and the organization name.

Review the company codes for the productive flag. During implementation, certain system flags are not set for a production environment. One of these flags is the productive flag for company codes. Not setting this flag allows one to "undo" transactions made to the system with deletion programs. Setting this flag to "productive" protects audit trails and should be checked. To check for productive status, execute transaction OBR3 and review the "productive" column to see if there are check marks by the company codes.

Ensure that the system is locked. Once configured and in the productive stage, the system is locked to prevent inadvertent changes. The screen to make these changes is accessible via transaction code SCC4.

Review users with the SAP_ALL profile. The most important transaction code that an auditor requires in an R/3 system is the report RSUSR002 or transaction SUIM—User Information System. This report is used for various audit queries on users, profiles and authorizations. Using this report for queries is quite tricky, and one needs to know how to use this effectively. SAP R/3 usually does not check for invalid input parameters. Therefore, one must pay particular attention when using this query tool. There are several ways to access this tool. The first way is via transaction SA38. Once in the SA38 screen, type RSUSR002 as the program name. The screen should then appear as shown in figure 3.

Secure User SAP*. The SAP system is delivered with a default superuser, SAP*. The default password for this account is well known. At installation, a user master record is defined for SAP*; however, SAP* is programmed into the system and does not need a user master record. If the user master record is deleted, it regenerates itself with a well-known password.SAP* is deactivated using the following steps:

A new password is assigned to SAP*.

All profiles are deleted from the SAP* user master record so that SAP* has no authorizations.

SAP* is assigned to the user group SUPER to prevent easy deletion or modification of its user master record.

The SAP* user ID is locked once the other previous actions are completed (the order is important).

The special attributes of the user ID SAP* are deactivated. This can be done by changing the default value 0 to 1 for the system profile parameter login/no_automatic_user_sap*.

Review the list of inactive users. In a large organization, the user list may contain several terminated users, inactive users or users who have never logged in. In some cases, the list of inactive users can grow to a significant number. An auditor can review user access logs and ensure that the user list contains only active users. This can be done by reviewing the table USR02.

Review the security of custom ABAPs. One of the methods used by SAP to control the execution of programs is establishing authorization groups and assigning programs to these groups. This way, access to critical programs is restricted by assigning them to a restrictive program authorization group. As a rule, all custom programs are assigned to authorization groups. The SAP-recommended naming methodology requires that all custom programs be named with the initial letter Y or Z.

Any program with an entry in the SECU column is assigned to an authorization group. While this is one way of securing custom programs, there are several other ways to secure them, such as assigning them custom transaction codes and securing these codes.

Review the security of custom tables. Just like custom programs, customized tables are secured by assigning them to authorization groups and typically have names beginning with a Y or Z. The query is executed just like the customized program tested previously. The table name to view is TDDAT and the field is CCLASS. Tables with &NC& in the CCLASS column are not assigned to any authorization group.

Check for users who have program execution access. Executing queries for who has access to critical functionality is a complicated task in the R/3 environment. Since transaction codes are paired with authorization objects, and these objects require specific authorizations, an auditor has to have a good understanding of the system to get the query parameters, as well as a good understanding of the use of the RSUSR002 report. A limitation of this report is that it can check only three parameters at a time. If a transaction code is associated with six authorization objects that all have authorization values, the query needs to be performed in three steps—first the transaction code and two authorization objects, then three other authorization objects and finally the last authorization object. The query results are saved in three separate spreadsheets or tables, and the common user records in all three tables are the users with ability to perform a specific task. An audit tool, such as ACL or Microsoft Access, can combine and extract the results of the queries.

Restrict access to maintaining critical/custom tables. Tables are a critical component of the SAP R/3 system since they contain controlling information for the system as well as the transactions entered by users. Changes to client-independent tables that contain global definition data can have unexpected side effects, since the changes affect all clients in an SAP system. Both client-dependent and client-independent tables control how the system functions, and inadvertent or unauthorized changes to them can result in serious consequences. Therefore, access to table maintenance is restricted. The client-independent tables are secured by authorization object S_TABU_CLI, and the client-dependent tables are secured by S_TABU_DIS.

To check for users who do not require access to maintain critical custom tables, do the following:

Execute Transaction Code SE16 » Enter 'USOBT' in the Table Field » Enter 'SM31' in the Name field » Press F8 (Execute)

The screen shown in Figure 5 will appear, allowing one to determine which users do not require access to maintain the critical custom tables.

Review system for locking of critical transaction codes. Several transaction codes in the system are extremely powerful and are seldom used after a system is in production. An organization determines which of these transaction codes are critical and locks these transactions. To view or change locked transaction codes, execute transaction SM01. The locked transaction codes have a check mark in the "locked" box.

Restrict access to user maintenance. User maintenance is one of the most critical functions within SAP R/3. Therefore, this functionality is highly restricted.

The steps outlined represent a high-level review of the Basis component. However, several other steps are performed for a detailed review of the Basis component.

Yusuf Musaji, CISA, CISM, CISSP, CGAis a manager with RSM McGladrey's New York office of technology risk management services. Musaji's functional and technical areas of expertise include enterprise risk management, IT security and privacy, financial system development, and implementation. He is widely published in IT, financial and security journals regarding IT/user relationships, and he has written two books: Auditing and Security: AS/400, NT, UNIX, Networks and Disaster Recovery Plans (2001) and Auditing the Implementation and Operation of ERP Systems (2003). Musaji can be contacted at Yusuf.Musaji@rsmi.com.

Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by ISACA®, Inc.. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA® and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by ISACA® Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.