2.7. Integrating People, Information, and Processes

Per SAP AG, beyond realizing a good “return on information,” the success of any productive SAP installation also hinges on “maximizing return on relationships.” This chapter concludes with a discussion of how the integration of people with your IT and business processes completes the review of performance tuning and stress testing.

2.7.1. Selling the Value of Stress Testing

From the boardroom to the computer room, no one really questions performance tuning. It's pretty much a “given” for most SAP shops that some level of tuning and tweaking will occur throughout a system's useful life, driven as much in response to surprise performance issues as proactively planned for in support of major changes or system upgrades. The really hard sell, though, is to tie the value of performance testing—stress testing, specifically—with good performance tuning. This chapter is filled with information and facts that should help you do just that, sell the value inherent to stress testing. But to whom is it most effective to “sell” this information?

The answer is, it depends. If your system is managed and indeed carefully guarded by folks with titles like “Change Management Technical Liaison” or “Change Control Analyst” then the value of stress testing must be impressed on these folks sooner rather than later. Further, if the purse strings of your SAP IT organization are pulled primarily by a financial subteam within your IT organization, these folks need to be made aware of the favorable role stress testing plays in the risk-versus-reward equation. Next, given that most SAP systems are carefully and methodically managed simply to prove that they meet SLAs, the teams tasked with systems management, and especially high availability, need to understand how regular stress testing will keep them home after hours more than the alternative would. Finally, if upper management is made aware of all of these arguments before operational processes tend to evolve into de facto operational standards (normally before Go-Live or possibly prior to large-scale migrations or functional upgrades), selling the value of stress testing to all of the other IT and business-focused subteams will occur from the top down as well as the bottom up, and possibly become a much desired business-as-usual policy in the process.

2.7.2. Quantifying Time, Resources, and Dollars

Any way you slice it, stress testing is not cheap. It takes time, and the testing resources—people, hardware, software/tools, and so on—cost money. But I believe that forgoing stress testing is even more expensive. Unfortunately, in this latter case, the dollars spent are easily hidden behind budgets earmarked for reactive tuning, upgrades, or new hardware and software procurement. The truth of the matter, and the core message that needs to be especially communicated to the people controlling the purse strings, is that stress testing will prove cheaper in the long run.

You'll want to quantify the cost delta to really get this message across and make an impact in your own organization, however. Thus, the following factors are key: acquiring the level of staffing needed to support all stress-testing phases and tasks; finding the time required to plan, prepare, and maintain a stress-testing approach; and obtaining the money required to procure and maintain a testing environment and test tools along with the money necessary to learn how to stress test and tune. Dump all of these data into a spreadsheet, and then begin collecting data that represent the dollars spent (or lost) by not testing or tuning, or doing so irregularly. I suggest first taking a close look at the money your organization has spent on reactive performance tuning. Don't forget to go through the entire SAP Technology Stack, paying attention to the costs of internal IT and external consultants tasked with fixing a broken system, or making a slow system perform well again. Then, review the downtime windows dedicated to managing changes, addressing performance tuning (e.g., applying patches or updates with the hopes of fixing performance-related issues), and so on. Next, take a look at your end-user productivity, especially time lost because of performance-related downtime. In fact, grab all of the availability data you can get your hands on. A completely “down” system is tremendously expensive per hour, and tends to grow exponentially more costly every hour. And even a painfully slow system (measured by response time or throughput) over the course of a few hours can add up to big bucks. Finally, don't forget to calculate the tenths of a second in average response time that users tend to wait when the system is merely “slower than usual”—a few tenths of a second per transaction per a thousand users every day can easily add up to a few hundred thousand dollars a year in lost productivity!

With your data in hand, it should become clear quickly whether or not the cost of stress testing is worthwhile. In my own experience, it's an easy sell when everyone understands the full financial picture. Drop your numbers into a presentation, do your pricing homework, read the rest of this book, and be prepared to get the “green flag” for proactive testing and tuning.