Overview—The Sizing and Blueprinting Process

If you have been diligent in following the processes outlined up to this point, all of the information collected with regard to your SAP project’s requirements, assumptions, constraints, and so on should be documented in your Knowledge Repository. The Knowledge Repository serves as your plan-of-record, and feeds either creating your Request for Information (RFI), or capturing your solution requirements via a hardware vendor’s Sizing Questionnaire (sometimes called a survey). From this information, any number of SAP technology partners can fashion a custom solution for you, a process collectively known as sizing. From a big-picture perspective, the sizing process is nothing more than a workflow of sorts, as illustrated in Figure 7.1.

Sizing is all about translating business requirements into technical requirements, and then into a solution consisting of various technology components, which in turn are configured or “sized” for a particular set of customer-unique requirements. To ensure an apples-to-apples result at the end of the process, it’s advisable to include the folks at SAP AG in this process (as illustrated in Figure 7.1); otherwise, different hardware vendors may interpret the data you provide to them differently. In the real world, though, you should know that many solutions are sized without the benefit of SAP AG’s direct input and expertise, as many of SAP’s technology partners are quite adept at addressing the entire sizing process themselves. In any case, throughout this chapter, I will walk you through the sizing process to help you understand what is occurring at each phase, how you can be better prepared for the different challenges along the way, and what you can expect after the process is over.

Sharing Your Vision—The RFI and Sizing Questionnaires

The importance of sizing cannot be overstated. Crafting a system too robustly only wastes money. On the other hand, missing your sizing target directly impacts end-user performance and in its own way also wastes money: Consider thousands of expensive users standing by an incremental second or two for each transaction they execute on the SAP system, and you’ll begin to understand how the money accumulates over time. This is why it is so important to nail down what you really require of an SAP system.

Your RFI or completed Sizing Questionnaire helps hardware and software SAP technology partners quantify the level of performance, availability, scalability, and so on that you require, and then map that directly into hardware and software solutions that support your SAP project. We have covered the kind of information that goes into an RFI back in Chapter 3. Sizing Questionnaires seek to gather much of the same information, though generally focused at helping a technology partner fashion a hardware/software solution:

• Number and type of end users, or simply users, who will eventually log in to the system and use it in support of their day-to-day job requirements.

• Level of activity of these end users, including think times, or the time spent in between executing transactions on the system, and other quantifiable work rate or interaction rate characteristics.

• Different functional areas or modules of each mySAP component to be sized.

• Customizing, interface details, and other system requirements unique to your future SAP environment.

Sizing Questionnaires differ from RFIs in both their scope and level of completeness. That is, an RFI often seeks to understand where a vendor can help a company with their SAP project beyond sizing and designing an SAP Solution Stack. Sizing Questionnaires, as alluded to earlier, tend to be more focused on the hardware stack or perhaps a piece of the software stack.

Obtaining Vendor’s SAP Sizing Questionnaires

Every hardware or software company serious about their relationship with SAP AG maintains an SAP Competency Center (or Competence Center), which is simply an organization tasked with understanding the evolving mySAP product lines coming out of Waldorf, and how SAP business processes can be mapped into a hardware or software solution design. Competency Centers go by many names—Solution Centers, Enterprise Solutions Groups, Centers of Excellence, and so on—but serve the same purpose, to create SAP solution designs based on data gleaned from RFIs, Sizing Questionnaires, and surveys. To help you build bridges to the SAP Competency Centers found within SAP’s largest hardware technology partners in North America, I have assembled the following alphabetical list:

• Bull hosts Web access to its SAP Competency Center at http://www.bull.com/sapsizing, and offers two business-day turnaround on budgetary sizings.

• Fujitsu-Siemens’ SAP Competency Center is at http://www.fujitsu-siemens.com/sap/quicksizing.html.

• HP’s SAP Solutions Center can be reached via the Web at http://www.hp.com/go/sap/sizing. HP offers access to both online and traditional methods of SAP solution sizing, including phone, email, and onsite customer engagements. They offer rapid turnaround on budgetary sizings as well.

• IBM’s SAP sizing Web site can be accessed at http://www6.software.ibm.com/reg/ibmsap/ibmsap-i, after you register with their site.

• Sun can be contacted for SAP sizing assistance at http://www.sun.com/software/solutions/third-party/sap/competency/sizing.html. They prefer that you contact the local Sun sales organization with your sizing figures in hand, and work through their iSizing for SAP sizing process, which commences by filling out an online form.

• Unisys’s link from SAP’s Quick Sizer, as of the writing of this book, is no longer valid. I suggest trying http://www.unisys.com/about__unisys/partners/alphabetical__listing/sap.htm, and from here obtain contact information for one of Unisys’s four SAP Competency Centers.

Microsoft and Oracle offer Internet-based access to information regarding their SAP Competency Centers as well. The best place to start in my experience, though, is with SAP’s own online sizing resource, the SAP Quick Sizer. Although this tool cannot help you size an actual hardware configuration, it is the perfect tool for helping you understand basic hardware needs as well as facilitating an apples-to-apples comparison between different technology partners’ approaches to sizing. And links from the Quick Sizer can point you to even more SAP hardware partners than those I pointed out previously, accessible through a simple link from the SAP Quick Sizer’s main page as seen in Figure 7.2.

Fostering Apples-to-Apples Sizings

The key to ensuring that all hardware and software vendors start off on an equal footing lies in the data you provide to them. This data is often provided through an RFI or questionnaire. However, at the end of the day this data can be quite raw or incomplete, and therefore subject to interpretation. Consider the following example—if a potential SAP customer shared with my colleague the fact that they expected 1,000 active users on their SAP R/3 system, but were not clear as to how active these users might be, what kind of wait times in between transactions to expect, or which mySAP functional areas to assume, and so on, my colleague could only take a stab at designing a system for them. He would leverage his own experiences and assumptions, document these in the sizing that he delivered to them, and wish them the best of luck.

On the other hand, if I were asked to do the same thing, I would discuss the various types of users with my customer, ask for clarification, and in some way gently “push” them toward giving me better numbers. Like my colleague, I would document my assumptions, craft a solution sizing, and publish it. I would also document my “newly” uncovered sizing data as well, which in effect would give me an advantage over the sizing attempts of my previous colleague—I would better understand my customer’s needs, and would probably create a sizing more reflective of their true requirements.

But what if my customer shared all of this data, and the two sizings now in their hands, with yet another colleague of mine? Given that more time would have probably passed, and my customer’s solution requirements could be even better understood now, my new colleague might be able to pull even more data from the customer, or perhaps bring to light constraints or assumptions true today, but not in the recent past. But his assumptions as to the activity levels or work rates of different end users might differ. All of this iterative and new activity would equate to yet a third solution sizing, very different from the previous sizing exercises.

This scenario I just described illustrates exactly why it is so important to understand as much as you can about your system’s and your end user’s requirements. In this scenario, a lot of time was wasted, and undoubtedly some credibility was lost on the part of the hardware vendor. Imagine if multiple hardware vendors had been engaged, each with their own biases, assumptions, and experience with different computing platforms! The sizings would have looked nothing alike, and the customer would be left frustrated rather than in a position to move to the next step.

One good thing uncovered from this illustration, however, was the fact that the sizing process is very much an iterative process. In other words, even in the best of worlds, new requirements come to light as time passes, or current requirements are better understood. As you see in Figure 7.3, it is up to the customer and SAP technology partners to work through these changes and other variables as efficiently as possible.

At this point, SAP’s Quick Sizer comes into play and really proves its value. To remove a lot of the variables from SAP solution sizing, and create a near-perfect foundation for apples-to-apples comparisons, I suggest running all of your pertinent solution data through the Quick Sizer. Available to anyone with an SAP Service ID, this online Web-based tool allows you to input user data, mySAP.com components to be sized, transaction loads, and much more. With this information, the Quick Sizer can then calculate general CPU, memory, and disk resource requirements.

At the conclusion of the SAP Quick Sizer process, you are also provided with an idea as to the horsepower required of a hardware solution to host what you just described as your system requirements. This horsepower is measured in something that SAP refers to simply as SAPS, or the SAP Application Benchmark Performance Standard. Note that 100 SAPS are equivalent to 2,000 fully processed order line items per hour, or 6,000 dialog steps (screen changes), or 2,400 SAP transactions. Herein lies the great equalizer—by sharing the number of SAPS required of your solution with all of your potential hardware and other SAP technology partners, you have in effect eliminated much of the error-prone sizing processes that serve as a solution’s foundation but are subject to broad interpretation. In other words, communicating your mySAP solution requirements in terms of SAPS helps each vendor size a solution for you that is consistent in its requirements. SAPS and other sizing-specific terminology is discussed in more detail next.

Sizing Terminology

Certain terms and vernacular are inherent to the SAP sizing process. Many of these are covered here, though others are covered in context as they are introduced throughout this chapter.

Perhaps the most misunderstood word with regard to SAP sizing is user. The term user is a very abstract notion, unless qualified as follows:

• A named user is a user with an account in a specific system; named users have User IDs in the system.

• Logged-on users, sometimes called active users, are a subset of named users. In my experience, the number of logged-on users might equate to only 20–50% of all named users.

• Concurrent users are a subset of logged-on or active users, working simultaneously or concurrently in the system. I like to think of this as the number of users who press the Enter key within the same 30 second time period—they are all actively processing or otherwise executing transactions.

• The number of active or open sessions consists of the number of SAPGUI or other interface windows open. Many users actually run two or three sessions, and thus look in many respects like 2–3 logged-on users. This can become an important factor in sizing, as you can easily run transactions within different sessions and therefore place quite a bit of load on a system through only a single named user.

Other factors further complicate definitions of the term user. For example, Enterprise Portal or SAP Workplace might be used to facilitate single sign-on to your enterprise mySAP solution, routing users to the proper mySAP component based on user-based roles and transactions to be executed. And mobile, pervasive, and WAP (wireless access protocol) users also generate load in the form of connections to your SAP system. Internet users in general create a load different in weighting than SAPGUI users, too. All of this makes it difficult to quantify the characteristics of a particular set of users.

Thus, it’s useful to define a user in terms of think time, or the idle time that passes by after a user executes one transaction, but before he executes a second transaction, for example. SAP provides us with three categories that represent typical user activity patterns, measured in terms of the number of processed transactions, or more specifically the number of dialog steps, each user executes. A dialog step is roughly equivalent to pressing the Enter key (or equivalent key) on the keyboard, resulting in a screen change:

• A low user or occasional user processes on average 10 dialog steps an hour or one every six minutes. Depending on the number of dialog steps in a transaction, this equates to something like one to two transactions per hour. Most users fall into this category in my experience.

• A medium user processes an average of 120 dialog steps an hour or one every 30 seconds, executing about 10–15 transactions per hour. This includes accountants, clerks, and so on. Medium users represent the next most popular category of users, behind low users.

• A high user (or “power user”) processes an average of 360 dialog steps an hour or one every 10 seconds (something like a full transaction each minute). High-productivity users, like those associated with data entry and telephone sales roles, constitute high users.

Other ways to measure throughput exist as well. As we saw earlier, SAPS are used by SAP’s Quick Sizer tool (and incidentally has been part of the SAP sizing process for many years now) to describe the load placed on a system. Hardware vendors sometimes publish numbers like those seen in Figure 7.4 to help customers and other SAP consulting organizations understand how well their hardware platforms scale in terms of SAPS. The fictional matrix shown in Figure 7.4 illustrates the relationship between the number of SAPS supported by a particular platform versus the number and speed of the CPUs supported by the platform.

For particular implementations of mySAP solutions, it might also be helpful to characterize a system’s load in terms of the number of SD, FI, or PP dialog steps—each of these is a functional area with R/3. With this kind of granular data, even the least savvy of SAP technology partners can cobble together something approximating a pretty good SAP solution sizing.

Specifically, use of SD Dialog Steps processed per hour is perhaps the most common measurement of throughput outside of SAPS. SAP AG publishes its benchmarks in reference to the total number of SAP Benchmark Users and related SD Dialog Steps executed by these benchmark users. Because of this, most of the SAP hardware providers publish their own SAP benchmarks and sizing data in a similar fashion.

Given the known relationships between SD and other functional areas, any SAP technology partner can easily move between using different throughput measurements and rates, based on what kinds of numbers or sizing formats a customer wants. I suggest sticking with SAPS whenever possible, nonetheless.

There is one last unit of measurement that is worth mentioning, though, known both as Concurrent SD Users and Normalized SD Users (I’ve heard this called “Normalized Active Users,” too). Regardless of the name, the idea is to convert the users of different functional areas into SD, taking into account the “weight” of that particular functional area. In doing so, a single measurement stick is created. Thus, when an R/3 customer provides a list of users running a mix of MM, SD, FI, PP, and other functional areas, one of the first things that my sizing colleagues and I often do is to convert these figures into normalized SD users. From there, we can easily convert to other numbers and formats, like SAPS. In case you ever need to do the same kind of conversion, I have included a simple Excel-based tool on the Planning CD.