2.2. The Challenge—Getting “Real” Return on Information

SAP AG penned the term return on information (a play on the more traditional return on investment acronym, or ROI) years ago, and I like that phrase, because it holds true today as much as ever. ROI implies that a fundamental financial equation exists at the heart of each SAP implementation or upgrade, that the SAP solution more than pays for itself over time, and that the real value provided by SAP lies in how the system's data may be manipulated and accessed to create useful information. Thus, the characteristics that are useful in describing the system—its performance, availability, scalability, cost, and so on—play central roles in exactly how well the system provides “ROI.” I'll be detailing each of these characteristics later in this chapter. Suffice it to say, though, that arguably if a system's performance is unacceptable, many of the other characteristics are immaterial: for example, a highly available but poorly performing system may essentially hurt the business more than it helps.

Over the last 7 years, I've been fortunate to play a part in fine-tuning and tweaking many an SAP customer's production system both prior to and post Go-Live. In cases where customers have already pulled the trigger and gone “live” on their SAP system without the benefit of sound testing and tuning, I might be found on the team that seeks to optimize things after the fact. This kind of work is reactive and usually extremely stressful, however, representing the flip side of my own goals: to assist a customer in going live and not being surprised by unforeseen performance issues. If these customers had truly load-tested their system first, and as a result understood exactly how well the system would perform under different end-user and batch-processing load conditions before Go-Live, my work would have been much easier, had it been needed at all. I call this the proactive approach to performance tuning and believe that sound stress testing is the most effective method to proactively and accurately performance tune your system.

2.2.1. Investing in Stress Testing

If we consider the value that an enterprise application provides to its end users, and therefore to the business at large, an investment in stress testing that application before Go-Live, and then again after each major change or upgrade to the application, makes good business sense. Sure, the financial impact needs to be considered. As I indicated earlier, stress testing is much like an insurance policy. But at the heart of the matter is this: Your company has made the decision to implement or introduce change into your SAP system, with the understanding that there is a huge amount of business risk in the business implementation, in the organizational changes that accompany the implementation/upgrade, and in meeting the company's ROI goals in a timely fashion. The risk on the business side is so high, in fact, that there is virtually no room for risk in terms of the technical implementation. Thus, the gut-wrenching issue faced by your IT department is that it has to provide a sound and optimized processing platform before your custom business solution is ever tested on a large scale. All of the modeling, extrapolating, and promises made by systems integrators and hardware partners simply cannot get around the inevitable issue at hand: you require proof that your mySAP solution will perform as advertised, and you need this proof before the system is turned over to the business community.

Thus, the IT folks responsible for SAP need all of the help they can get from people who have made similar journeys and understand the pitfalls, issues, and resolutions. They need to work under the guidance of someone who has dealt successfully with these uncertainties and who can provide the processes, insights, and wisdom that will enable them to get their job done right, on time, the first time. This book is that guide.

2.2.2. Embracing Stress Testing

Not only do the best performing and most highly available SAP shops invest in stress testing but they embrace it in one form or another, plain and simple. Both the IT and business organizations responsible for their SAP systems understand that their system is simply not ready to be handed over to its end-user community until it has undergone an appropriate level of true-to-life load testing (the level of which depends on the nature of the changes made to the system). For every company running SAP that understands the value of stress testing their system after each and every major implementation, upgrade, or change wave, however, I can point to another 10 companies that would (unknowingly, I presume) rather risk huge losses in customer satisfaction and instead blindly turn their system over to their users. You might wonder why they don't stress test. In my experience, the answer usually boils down to the following two factors: they don't understand the value of testing, they misunderstand the costs, or a combination of both. Specifically, these companies

• Overlook stress testing because of high perceived costs, from IT and business people resources to software costs, because they are unable to simply set aside enough time to make a difference

• Mistakenly believe that it costs too much to develop and maintain a body of knowledge around the kind of stress testing that purposefully dovetails with their change management organization

• Might feel, similarly, that the investment in a stress-testing environment or related processes equates to poor ROI, preferring instead to throw hardware and consulting fees at performance problems

• Believe that stress testing only applies to new implementations

• Think their downtime or maintenance windows cannot handle the incremental time that would presumably be required to execute a stress test after each production change (and prior to turning the system back over to its end users)