Wednesday, July 29, 2015

SAP Upgrades - How to estimate the time needed for a production upgrade


One of the biggest questions with an upgrade is to see if it can be completed over a cutover weekend. Are there enough resources available to complete the task within the needed time frame? Is there a way to tell beforehand or will additional resources need to be brought in?

For many clients answering these questions can be a challenge. Many do not have installations that match from one system to another (i.e. QAS doesn't have the same setup as PRD). Estimating the time needed to upgrade a production system needs to be based on the time it took to upgrade DEV and specifically QAS. Other clients have shared resources in one environment but not another.

In these cases, what you can do complete the upgrades in the non-production systems and create an estimate. Then, as you are stepping through the pre-processing phases of the production upgrade, revise those estimates.

Here is a quick example of what can be done.




 The screenshot shows the time it took to complete an upgrade in both the DEV and the QAS systems. What I've done here, is to pull the time from the report generated at the end of each of the upgrades. As you can see, the EQ1 system is a bit faster than the ED1 system. 

I'm not including the hardware here (at least not yet) because I want to make a quick point. Estimates for time it will take for the production upgrade based on the previous upgrades are just going to be general ball-park estimates. Those estimates are not going to be realistic until they are revised based on the time it takes for the few steps of the production upgrade.

Here is an update to the example above.
 Above, I've created a base estimate on the amount of time it should take for each step in the production upgrade. I know that production has more memory (24 GB versus 12 GB) and more CPU (8 cores versus the 4 in Q). So I've put in a rough 20% improvement in time for each phase.

I also updated the other two columns as a sanity check against my original estimate. Once I start feeding data in from the active upgrade, I'll know which estimates are closer (part of me always hopes that I'm closer to the right than the left!).



 Now comes the fun part. We've started the upgrade and completed the first three phases (normally in an upgrade you can complete these steps in a day or two).  I pull the time required from the first phases from the sapupconsole log file. It's messy, but I can calculate the time for each phase by extracting the time for each step in a phase and then adding them all up (and who said Basis wasn't any fun?).


















Based on what I calculate for the first three phases, I update the spreadsheet as shown below (adding a calculation to show the percentage difference between the 'real' time and the time it took to complete the same phase in EQ1). Then I check to see how far off I am from my original estimate (of 20%). As you can see, I'm off on the 20% estimate but pretty close to the 30% column (the number at the bottom of the column is an average).









What we now have is a more accurate view of the time it will take for each phase in the upgrade. The overall upgrade plan can be updated to reflect these times.

Thursday, July 23, 2015

SAP Upgrades - Key Players

When I left my last project, I sent out notes to my colleagues who were the most helpful. That note mentioned that if I had to put together a dream team for my next project, that I'd want them to be on that list. In the back of my mind, I started thinking of why specific people were so valuable.

So here is my list of who should go on a dream team for SAP upgrades:

I. The Team

1. Project Manager
2. ABAP Programmer (depending on what is being upgraded)
3. Database Administrator
4. Operating (Windows/Unix) Administrator
5. Storage/SAN Administrator
6. Basis Administrator (I almost forgot that one!)
7. SAP Architect (if different from above)
8. Company Sponsor


II. Explanation

Project Manager
The best projects I've worked on included project managers who constantly worked to keep the lines of communication open. When there was a delay in the project or a major stumbling block (failed updates, corrupted upgrade status files, etc.), they took care of the communication while the technical team worked the issue. When outside resources needed to be brought in, they also took the lead on providing background information and ensuring access.

ABAP Programmer
A good ABAP'er is needed during the SPDD/SPAU update process. It makes the upgrade smoother and the validation process shorter and more reliable. For ECC upgrades, it is especially important to have a programmer review needed changes and stage them for the next system in the landscape.

Database Administrator
This is a key player on the technical side. They need to be able to answer these questions:
- Does the DB have enough space/capacity to handle the upgrade?
- Has the DB been backed up!
- Is the DB out of log archive mode (going into the downtime)
- What is needed for any possible upgrade to a new database version (if that is included)?

Unix/Windows Administrator
As with the DB admins, these technical players need to know if the upgrade on an OS level is possible and answer these questions:
- Has the OS been setup according the the recommendations from SAP (you'd be surprised how often this is not true)
- For any HA environments, has the system been tested prior to the install (if that is possible)?

Storage/SAN Administrator
The storage admin needs to be able to:
- Ensure there is enough space (duh).
- Be able to resolve an I/O issues
- Make sure the system is being backed up at the OS level.

Basis Administrator
This is the key technical role during the upgrade. The Basis Admin prepares for and completes the upgrade on the technical side. They also need to have experience with previous upgrades, be able to work through routine upgrade issues, and know when to call for outside help when needed.

SAP Architect
For larger projects that involve external systems and/or High Availability setups, having an architect can be crucial. Being able to encompass all external systems during testing and ensuring that the environments all match can be critical during an upgrade project. An architect should ensure that the infrastructure

Company Sponsor
This person is critical because you need someone from the executive level to highlight the importance of an upgrade. When you don't have a key player that supports the application and the upgrade, you may face an uphill battle of getting resources assigned to the project and having those resources complete their tasks within the required time frame.