In traditional, custom-built applications, software maintenance takes the form of development requests initiated by the business owner and implemented by the IS department. Most companies have a well-established protocol for this process. Typical steps include documentation of requirements, approval of changes, development, testing, and migration to production.

A number of individual development requests are often bundled into a single scheduled “release.” This procedure, called the software development lifecycle, has been refined over many years to ensure continuous error-free operation of the production environment.

When a company converts from a custom-built application to a licensed software product, the software development lifecycle undergoes some changes. The first four steps shift, to some degree, from the customer to the vendor. The customer expects the savings gained by eliminating these steps to be greater than the licensing fees. Individuals who use a product such as Microsoft Word may treat new versions like an oil change for their PC. When a new version becomes available, they just install it. Testing is not required because it is likely that Microsoft has tested the software enough to eliminate problems that might affect most users.

Corporations that invest in a customizable software package such as SAP, however, need to be more cautious. Each customer incorporates its own configuration and business processes into the application. Some customers even change the application logic through enhancements or modifications. This flexibility makes it much less likely that the testing performed by SAP can uncover all potential problems. This approach means that the development and testing functions have not totally shifted to the vendor, but rather are shared between the vendor and the customer.

SAP gathers requirements through OSS and ASUG (America’s SAP Users’ Group). Approved changes are sent through development and testing, then bundled into releases known as Human Resources Support Packages, or HRSPs. Almost immediately after conversion, each customer is faced with the need to keep R/3 current by applying HRSPs. This article explains how you can continue to ensure a high level of reliability in your production environment by fitting HRSPs into your existing change management process.

Determine Which HRSPs Are Available

The first step is to determine the current version and support pack level of your system. From any R/3 screen, choose the menu path System>Status. This displays the window shown in Figure 1. The section titled SAP System data displays the Component version of your system. Click on the magnifying glass to open the system component information window. Click on the Support Packages tab and scroll down to the end of the HR Support Packages. HRSPs have names that start with SAPKE, followed by the SAP version number and the HRSP number. The sample customer illustrated in Figure 2 is on version 4.6C and HRSP level 66. This means that all support packs up to and including number 66 have been installed. It is a good idea to perform this check on each instance in your system landscape to verify that they are all on the same HRSP level.

Next, determine if any new support packs have been released by SAP. Visit the Web site https://service.sap.com/patches or use transaction code OSS1 to access the OSS system. Ask your Basis team for an OSS ID if you don’t already have one. On the Web site, use the navigation bar on the right to display the support packs available for your version of R/3. Figure 3 shows that HRSPs up to number 71 are available for HR 4.6C. This means that the sample customer can install HRSPs 67 through 71.

Figure 1

System status window

Figure 2

System component information window

Figure 3

OSS list of HRSPs available for SAP 4.6C

Analyze Notes Included in HRSPs

Now that you know which HRSPs are available, you need to build a complete understanding of the software changes they represent. SAP makes this analysis relatively easy by assigning each change an SAP note number and then assigning each note to a support pack. Start the process by clicking on the name of the support pack. Figure 4 shows the additional information available for Support Package 67. A Basis team member uses the Download link to copy the support pack’s transport file to a local server. An ABAP team member uses the Object List link to anticipate changes that could affect modified SAP code. The Package Info link gives some general information about the support pack. The SAP Notes link provides a list of all notes that are included in the support pack.

The notes included in HR Support Package 67 are shown in Figure 5. They are organized by functional area. Expand the tree to display the notes for each functional area that is used at your installation. Click on the name of each note to display the note details, as shown in Figure 6.

It’s a good idea to hold a team meeting at which everyone has an opportunity to discuss the details of each note. Consider your specific installation. Ask questions such as: Has this problem occurred here? Is this change related to a function or feature that is used here? Does the proposed solution appear contrary to our way of doing business?

Notes that contain changes unrelated to your installation can be ignored. Notes that pose some risk of affecting the production environment should be documented for testing.

Notes that affect a piece of functionality that was enhanced through a user exit or modified through a change in the SAP standard code require special attention. The change contained in the HRSP may eliminate the need for the customization. On the other hand, the change may require an adjustment to or reapplication of the customization. A large number of customizations increases the complexity and duration of HRSP testing. This is why it is always best to find a standard solution for each functional requirement before considering an enhancement or a modification.

Once the HRSP has been imported, changes to the SAP database and the program logic become available in all clients of an instance. Client-dependent changes such as schemas, calculation rules, and configuration tables are only imported to client 000. These changes must be manually applied in other clients using client 000 or the related SAP note as a guide.

Figure 4

Additional information for HRSP

Figure 5

Notes in Support Package SAPKE46C67

Figure 6

Details of SAP note 587378

Create a Test Plan

A good test plan follows the existing change management process and includes test scenarios to thoroughly validate the changes being installed. The test schedule may include several steps like the ones shown in Table 1. The number and complexity of the changes involved determine the amount of time required for each step. If the volume of changes is too great, you might install some of the HRSPs now and some later. Just remember that HRSPs must always be installed in numerical order. The testing schedule and supporting documentation should be distributed early and often to ensure that everyone is aware of the planned changes. See Figure 7 for an example of documentation used for testing SAP note 431012.

Most customers install HRSPs on the sandbox client first. This gives the Basis team an opportunity to validate the installation process and the functional teams a chance to review the performance of any changes that may be of special interest. The sandbox-testing period is normally quite brief, as sandbox clients tend to be too unstable for rigorous testing.

Many customers have a special instance in their landscape known as test. This instance exists solely for the purpose of testing HRSPs. It is an exact copy of the quality assurance (QA) instance and is not in the change management path. The QA and test instances are refreshed from production at the same point in time just before the HRSPs are applied to the test instance. This provides an opportunity to compare results between the current and modified software. Problems can be caught before the changes are imported to the development instance.

The HRSPs are then loaded into the development environment. Any required client-dependent changes are entered at this time. These changes should be assigned to a transport that contains only changes related to the HRSPs. These customer transports are imported to QA and production just after the HRSP transports. Each relevant change is unit tested in the development instance. This testing period provides an opportunity to refine the individual testing scenarios.

After unit testing is complete, the HRSPs and related customer changes are moved into the QA environment. The QA environment is normally a close representation of the production environment, providing an opportunity to accurately predict the expected impact of moving the HRSPs into production. Integration test scenarios are performed in the QA environment to validate that the sum total of the HRSPs work together properly. Regression test scenarios are designed to confirm that all existing functionality in the system continues to operate as expected.

The final step in the testing process is approval for production based on a review of testing results. It is not unusual for the production import to be followed by some brief validation testing. This can be a payroll simulation, the execution of some audit reports, or a manual review of affected objects.

When a Bug Is Found

In each HRSP, you can usually find at least one note released as a correction for problems that were introduced by a prior note. Following the change management process for HRSPs makes it possible to locate these bugs in the testing phase before production is affected. When a bug is found, send an OSS message to SAP. A correction will be developed and released in a new SAP note. The new note will be assigned to a future HRSP. For the sake of illustration, let’s assume HRSP 70 introduced a bug, and SAP has assigned the note that corrects the bug to HRSP 74. There are two choices. You can delay installation of HRSPS 70 and 71 until after HRSP74 becomes available, or you can manually apply the note that corrects the bug just after import of the available HRSPs.

An HRSP Strategy

Clay Molinari

Clay Molinari has 20 years of experience in the IT industry and has been working as an SAP HR consultant since 1997. He is currently president of C&C Savant, Inc., an SAP consulting firm that specializes in combining standard SAP configuration and custom ABAP programming to help its clients solve unique or complicated requirements.

You may contact the author at claymolinari@comcast.ne.

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