In my previous post on SAP upgrades I discussed how to get started on your project and to determine whether you are doing (ahem!) just a technical upgrade or intend to venture into deploying additional standard functionality, too. In this post I’ll talk about how you can plan, anticipate and potentially accelerate some of the execution activities to verify the upgrade is working.
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 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:
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.
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.