In this post, we will look at some of the customization areas which add risk and the cost to an upgrade project.

1. Direct Modifications to SAP Standard Objects

Direct modifications to SAP standard objects bear the highest risk.  During the upgrade, these modifications will be lose–either because they will be overwritten by their respective upgraded SAP standard objects; or because these objects no longer exist and are not used by standard SAP in the upgrade system.

Typically, there are two reasons for performing direct modifications to SAP standard objects:

1. The application of authorized individual OSS corrections to fix problems.
2. Direct customer modification to provide business process enhancements.

1.1. Application of Individual OSS Corrections and Support Packs

Individual OSS corrections are patches supplied by SAP to fix recognized problems with SAP objects.  Sometimes, individual OSS correction instructions are included and delivered within a specific level of support packs.   That means that applying support packs to the specified level will apply the desired correction, and manual intervention is not needed.  Sometimes OSS correction instructions are not yet included in any specific level of support packs, and these will need to be applied either manually or with the SAP Note Assistant.

It is important to carefully analyze the validity range of an OSS note to determine both how it was applied in the legacy system, and how it is to be applied in the upgrade system.  This analysis will help determine how far to patch the upgrade system to make sure that the desired corrections are included in the upgrade system.   Any needed correction that exists at a patch level beyond the highest patch level in the upgrade system will need to be addressed  manually or with the SAP Note Assistant.

The decision of which support pack levels should be applied to the upgrade system must be made carefully.  One approach is to apply the highest level of support packs that are available.    The rationale for applying the latest available support packs is to insure that the most recent problem fixes are applied to the upgrade system.  This is a two-edged sword, as the most recent  support packs may also introduce other problems into the upgrade system.

1.2. Direct Customer Modification of SAP Standard Objects to Provide Business Process Enhancements

Direct modifications of SAP standard objects to provide enhancements are most costly and bear the highest level of risk.  While direct modifications of SAP standard objects may have been technically expedient at the time of implementing the enhancement, they will always require additional work effort and analysis at upgrade time to determine:

1. Whether or not the functionality provided by the enhancement is still required by the business.
2. Whether or not the functionality provided by the enhancement is already included in the upgrade system as standard SAP.  You will need the help of functional subject matter experts here.
3. Whether or not the modified SAP object still exists in the upgrade system.
4. How to move these required enhancements into the customer namespace, using the SAP preferred enhancement procedures.  Moving these types of enhancements to the customer namespace also moves them from the very costly and highest risk category to a lower cost and lower risk category.

2. Custom Interfaces

Custom interfaces are loaded with opportunity for high upgrade risk.  Take, for example, the SAP standard IDOC Basic Type, which was copied as the baseline for an enhanced customized basic type containing additional custom segments and fields.  In the upgrade system, a new version of this SAP standard IDOC Basic Type may now contain additional segments and fields.

Likewise, the associated standard processing module for that standard basic type, which was copied as the baseline for an enhanced processing module to handle the custom segments and fields of the enhanced custom basic type, may also have changed in the upgrade to accommodate the new standard IDOC version.

So, in the upgrade system, especially if you need to implement the new upgrade IDOC version, it may be necessary to start with the new standard basic type and standard processing module, and reapply the customizations.

3. ABAP Code Objects

Of all customized objects discovered in most SAP systems, ABAP Code objects are the most numerous.  These objects include classes, methods, function modules, report programs, dialog programs, and include files which support the all of the other ABAP object types.

At greatest risk are the SAP standard ABAP code objects which were modified directly in the SAP namespace; and those that were copied into the customer namespace and subsequently modified. This is because the standard SAP code objects may have changed in the upgrade.    These changes can range anywhere from simple error corrections to complete process and code redesigns.  In these instances, each modified object must be compared to its counterpart in the upgrade system to determine its existence, and the nature and extent of what might have changed.   If the customization is still needed in the upgrade system, and to stay current with the enhanced standard code, it is probably best to start with the upgrade standard code and reapply the customizations.

ABAP code objects that were developed entirely in the customer namespace (not copied from standard SAP code) are usually low on the risk ladder.  Problems occur when data selected by these objects has moved elsewhere or behaves differently in the upgrade system, when ABAP constructs used are now obsolete in the upgrade system, or when standard called functions are changed in the upgrade system.

Ultimately, the business must decide why SAP standard code was directly modified, why SAP standard code was copied into the customer namespace and modified, why custom code was developed entirely within the customer namespace, whether or not any of these modifications are needed, and how they might be implemented differently in the upgrade system.  This evaluation presents another opportunity to remove some rocks from the customization rock bag.

4. Automated Standard SAP Transactions

Custom ABAP programs which automate standard SAP transactions bear an above-average risk.  This is because the behavior of some SAP transactions may have changed in the upgrade.  These changes can be manifest in the functional performance of the transaction, the technical location and existence of data fields on screens, screen field properties, IMG configuration specific to the transaction, the transaction code associated with the transaction, or even the existence of the transaction or an equivalent in the upgrade system.  The nature and the extent of the changes to the transaction in the upgrade system will determine the amount of effort needed to automate it.

Also, if an “old” SAP transaction has been replaced by a “new” upgraded equivalent, it is usually wise to make the change to the new transaction at upgrade time.  At some point in the future, the “old” version of the transaction will become obsolete and no longer useable or supported.

5. Data Dictionary Customizations

Many customizing projects within SAP require the storage and manipulation of data that is not included in the standard SAP dictionary.   One way in which these requirements can be addressed is by building complete custom transparent tables and data structures.  Another way is by adding append structures and append fields to existing standard SAP tables.  With either approach, it is always an excellent idea to evaluate the need to move these customizations into the upgrade; and another opportunity to lighten the customizing bag of rocks.

6. Customer and User Exits

Customer and user exits are provided by SAP as the SAP-approved mechanism for enhancing standard functionality.  Enhancements performed within these boundaries are guaranteed by SAP to bear low technical risk in an upgrade situation.  While SAP guarantees that the custom code will arrive technically intact in the upgrade system, functional analysis must still be performed to determine the continued need for the enhancement in the upgrade system.

Any enhancement implemented in a customer or user exit that is either functionally covered or determined to be unnecessary in the standard upgrade system should be retired.  This is consistent with the goal of lightening the load in the bag of rocks.  Since a customer or user exits may implement several different enhancements, take extra care to make sure that only the right code or other objects are retired.

7. The Environmental Effects – Operating System Change

OK, changing the operating system during an upgrade project is not customization of SAP objects.  But it does add risk and cost to the project.

Why?

If the upgrade operating system changes from UNIX to Windows or vice versa, then any ABAP program or interface which reads or writes a data file to an operating system folder must be changed.  The changes needed to these ABAP programs are very narrow in scope,  and reflect the manner in which the operating system specifies its file paths.  Additional BASIS work, such as determining the proper file system authorizations, may also be needed.

Using the SAP logical file name facility can help enormously by removing the need to make changes to hard-coded file names and path names in many different ABAP programs.

Share Your Experience

At the top of this post, I stated that I would discuss some of the customization areas which add risk and cost to an upgrade project.  I look forward to hearing from our readers to reply to this post with their own experience with customizations, how they were handled, and how this affected an upgrade project.

In my next post on this topic, I will reveal some of the techniques I use to “discover” customizations, even in the absence of documentation.

[Editor's Note] This blog is the second of a multi-part series:

1. Part 1
2. Part 2
3. Part 3

Nowadays SAP wants you to use SOLMAN to manage your landscape and use it as the main conduit to interact with the mother ship in Walldorf.  Lots of SAP installations use SOLMAN as a way to generate developer keys and as a document repository: valid uses, but only a small fraction of the available functionality.  Let’s explore some more of that SOLMAN magic.

SAP Business Process Design

An ongoing SAP mantra relates to taking a business process based perspective: rather than look at point functions and optimization of individual steps you take a more holistic view of the entire business process and attempt to optimize the whole.  With SOLMAN (and encouraged by SAP) you can take a hierarchical approach from business scenarios to business processes to business process steps.  For example, you can have an order-to-cash (OTC) business scenario and within that you have a standard material order fulfillment process made up of several process steps.  In SOLMAN you can build a structure that looks something like this:

Within SOLMAN you can identify the specific SAP transactions executed in the steps (both custom and standard transactions).  You can attach descriptive documentation at any level, for example, an overview of the OTC business scenarios as executed within your organization.  At the business process level you may want to provide one overview of the order fulfillment process for standard material delivery orders, and another for a services order.  Finally, at the process step level you can provide details about how a transaction is executed as part of the overall process.  These steps don’t have to be SAP transactions: they could be manual offline activities or steps performed in another application.  You can also include development objects that have to be incorporated into the process flow.

Here’s the point: laying out the scenarios, processes and steps in SOLMAN creates a structure that can be pulled directly into the SAP test workbench using transaction SWTB_2.  This transaction automatically takes your SOLMAN project content and creates test plan content.

SAP Test Plan Content Creation

And what is even better about this step to pull information into the SAP test workbench is that you can pick and chose the elements you want to include in your test plan.  Once you have a test plan, you can create test packages with tester assignments and test sequencing.  The graphic below shows a test plan structure created automatically based on the SOLMAN project structure shown above.

In this graphic you can see that the transaction codes and the supporting documentation have been pulled into the test plan.

Now that I have my test plan content I can create test packages and assign testers to the packages.  In the graphic below you can see four test packages and the assignment of testers.

Now within that test package I can sequence the tests and supporting documentation and assign testers to each step as shown below.

This can be pretty powerful stuff.  With some forethought and preparation I can generate a test plan based on the contents of my SOLMAN project.  I can pick and chose the pieces I want from SOLMAN to build my test plan content and further pick and chose what I want to include in my test packages.

Test Execution

Now when the project goes into test execution each tester assigned to a test package can execute transaction SWTB_WORK to see all the packages where she/he has been assigned as a tester (see below).

Clicking on a specific package drills in to show the detail test steps, the sequence, the assignments along with other useful information, for example, the status of each test step (see below).  Not only is this information all available in one place but the transactions can be invoked by clicking on the check mark and, assuming the correct technical set up, the system will automatically log you on to the test system ready to perform the test.

Test Reporting

On top of the test plan preparation and execution the SOLMAN tools also support overall test reporting.  The SAP Solution Manager Work Centers transaction (SOLMAN_WORKCENTER) includes some delivered reporting capabilities to allow centralized monitoring of test plan and test package execution for a project.

The reporting allows you see report test status across test packages within a project and supports drill down capability to see the details associated with each test including documentation for test results and any test defects reported.

Summary

The SAP SOLMAN tools allow your project to be used as the basis for your test plan content and automatically include your project documentation in your test plan.  The inherent integration means that you can use SOLMAN as a document repository for business process design, key decisions, test case identification, etc. and use as much of that as you want when you build your test plan.  One source for documentation and information; no need to organize and use different tools.

Clearly the example case I used here is something of a simplification and I am not going to underestimate the thought that needs to go into test planning content, but whichever tool you use for testing you have to put in this effort regardless.  I hope this example serves to illustrate some of the capability available in SOLMAN and reveals some of the potential available in the tool.

However a key point to note is that the SOLMAN Test Workbench allows you to build test content, but it does not offer the capability to schedule the tests.  Again this is something you need to do regardless of the tool you use.

What’s Next?

This blog discussed use of SOLMAN project content to automatically generate test plan content.  In my next blog I’ll discuss how you can use template projects to rapidly create implementation projects and save huge amounts of project preparation time.

In short, if you have done a good job with your earlier implementation activities you should have a plethora of materials that can be reused.  Remember that after an upgrade your basic goal is to still be able to do what you could do on the previous release along with anything new you are introducing.  The way you execute business functions may be slightly different, but the underlying objective should be much the same.

For more on SAP Upgrades download the white papers:

SAP Upgrade Checklist

Customization Risk Analysis in an SAP Upgrade Project

SAP Project Artifacts for Upgrades

In short, don’t reinvent the proverbial wheel if you have one available to you already.

As you went through your initial SAP implementation and ongoing support work you probably generated piles of documentation and if you managed this well throughout the ongoing project lifecycle there is a good chance that you can reuse it.  In essence, the better job you have done identifying, capturing and testing the functionality used in your SAP system the easier it should be to reuse those artifacts to confirm continuity of business processes in the new release.  It sounds easy, but it is a rare project that consistently maintains and updates project documentation as functionality is introduced through point releases, production fixes, etc.

Whatever information you have is worth reviewing to see if it can be reused or at least used as a basis for building out the scope of testing for the upgrade.  In addition to the testing scope, you may have test plans, procedures and protocols that can be adapted.  Typical project artifacts for consideration include:

Functional Scope

Any SAP project starts with an initial functional scope which grows over time.  This is a great start point for defining what you need to test and circling back to find where you implemented non-standard functionality.  The standard functionality is likely to stand up to the upgrade and work straight away, whereas the non-standard stuff is where you want to pay special attention.  In this scope you want to make sure you capture any special periodic processing, e.g. daily, weekly, monthly, quarterly and annual processes to be tested

Business Process Procedure Documents

In conjunction with your functional scope, you probably have business process procedure documents that provide detailed step by step instructions on how to execute job functions.  You can use these as a tool to verify whether business process steps have changed.  In the event that the steps have changed it is clear what documentation needs to be updated.

Technical Objects Scope

Similar to the functional scope you should have a catalog of technical objects, e.g. reports, custom programs, user exits, SAP modifications (if you went down that path), etc.  This provides a list of objects to examine and evaluate as part of the upgrade.  This is a topic covered in depth in a separate blog posting.

Test Plans, Scripts, Procedures and Tracking

Now that you have a functional and technical scope defined you can also revisit any test plans you have.  Testing comes in many flavors (click here to discuss some flavors) and you probably have prior test artifacts for functional testing, end-to-end testing, security and authorizations testing, etc. which are worth a review.  On top of this any regression test scripts and automated test tools may be re-deployable in support of upgrade testing

On top of this most projects have established procedures for tracking issues, resolution steps, and progress reporting.

Testing Organization

In conjunction with your test plans you probably have documented roles and responsibilities, test team organization structure, escalation routes and sign-off procedures.  Again, reuse all that you can.

Partner Systems, Interfaces, Batch Processing, Performance Metrics and System Outputs

Very few SAP installations are islands of functionality, instead there are numerous partner systems that interface with SAP as well various outputs in both electronic and hardcopy forms.  An inventory of these items provides another checklist for testing and identifies both internal and external partner systems you need to include in your upgrade test cases.

System performance is often critical for interfaces and batch processing and any historical activity that identified and tested these elements provides a potential guide for ensuring no degradation of these things as a result of the upgrade.

SAP Upgrade Go-Live

Again the experience from other go-live events may form a good basis for building the upgrade production implementation plan.

Supplement these artifacts with additional content for new functionality and modify for anything that has changed because of the upgrade.

Get Organized for Your SAP Upgrade

By no means am I saying that everything you have built and accumulated over the lifetime of your SAP installation is going to lend itself easily to being recycled in support of your upgrade activities.  However, I am saying that you put in a lot of work to get to this point, you already have a good idea of how to test SAP, you know the quirks and nuances of your organization, so don’t feel like you need to start from scratch.  Cast a careful eye over what you have in your project inventory and see what make sense to apply and what to discard.

And if your SAP project inventory is not a robust as it could be, think about how to strengthen it ready for the next time you have go through an exercise like this.

The choice to upgrade your company’s SAP platform is a very important business decision.  Many criteria need to be considered when determining if an SAP upgrade is the right move and, if so, what type of upgrade needs to take place (ECC 6.0, Enhancement Packs, etc.).  A successful SAP upgrade requires the determination of your upgrade requirements, proper planning, and an assessment of technical and functional risk.  Below is a sample of our SAP Upgrade Checklist white paper:

Determine Your Upgrade Requirements

1. What are the business reasons for upgrading? Support from the business for an upgrade project is most important.  If there are no business reasons for upgrading, then you should probably not do it.  Included here are the business risks incurred by not upgrading.
2. What are the technical reasons for upgrading? Included here are the technical risks incurred by not upgrading.  (Posture increasing maintenance fees for old versions or complete support withdrawal as a business risk – not a technical risk.)

For the complete list, download the full white paper:

SAP Upgrade Checklist

Related Links:

1. SAP Upgrade Project Plan
2. SAP Upgrade Project Management Considerations
3. Contact Us