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