2 Sizing Methods
Sizing projects are carried out at very different stages of
an SAP project. They represent an iterative process that
depends closely on the amount of information that is
available to you at a certain point in time to make reliable
statements on the actual hardware requirements.
Accordingly, in each sizing project, you will often face
new situations that you must react to with different meth-
ods and, consequently, using different tools. This chapter
focuses on these different methods.
2.1 Phases of Sizing Projects
SAP regularly receives information requests like the fol-
“We are a large customer in the consumer goods indus-
try with 30,000 business partners and 60,000 sales
orders containing 50 line items per month. How much
hardware do we need for our SAP application?”
This is a rather general question. The customer needs
information about hardware for a ﬁrst estimate. The
question itself does not indicate why this is a large
customer. Perhaps the customer is only looking for a
partial solution since the volumes mentioned indicate
that this customer is a large medium-sized company.
The business partners represent master data and are
not yet relevant to sizing because they do not gener-
ate any load during live operation. In contrast, the
sales orders and sales order items are much more
critical to CPU sizing since they represent transac-
tion data. In terms of revenue, an average of 2,000
sales orders per day is quite considerable; however,
from the point of view of software, this is not a high
throughput volume. SAP has several customers who
process more than a million sales order items per day.
“We can’t ﬁnd any guidelines for the FIN-FSCM-TRN
component in your sizing area (http://service.sap.com/
sizing). Moreover, we are using several custom develop-
ments. How should we carry out a sizing project?”
This question refers to a speciﬁc component in
accounting and is therefore more detailed. Perhaps
this customer has already carried out sizing projects
for other SAP applications and wants to perform
another one for this particular application. In addi-
tion, the customer wants to know how sizing can be
done for proprietary developments.
“We are planning to consolidate our seven data centers
into one. Can we simply add up existing sizings?”
This question (which comes from an existing SAP
customer) refers to a system consolidation process
in which additional hardware requirements must be
taken into account if the different existing systems
are combined. System consolidation and single-
instance concepts, which are used to check whether
all systems can be globally integrated with one data-
base, are currently red-hot issues with our customers.
“We are currently running Release SAP R/3 4.6C and
want to upgrade to SAP ERP 6.0. What are the upgrade
This customer uses a speciﬁc release that he wants
to upgrade across multiple releases in one step and
therefore wants to know if new hardware needs to be
purchased for that.
By further analyzing these kinds of requests, we ulti-
mately get to the different phases in which you can per-
form sizing projects (see Table 2.1). The informational
value of the sizing project can vary, depending on the
different phases. In addition, you should note that not
all the phases described in Table 2.1 have to occur in an
Thus, if the system GoLive is still way down the road
and you — as a customer — are not yet very familiar with
mation you have is that 100 users will use SAP CRM, but
you don’t know the other applications they will use and
what will be their average activity, you can certainly per-
form the sizing, but in the long run, the informational
value provided by the result of the sizing process will be
For this reason, budget sizings are usually performed
way ahead of the GoLive phase (most of the time in
Phase A) if the goal is to estimate the approximate scope
For budget sizings, you can use the user-based sizing
function in SAP’s Quick Sizer (see Chapter 5, Quick Sizer).
Alternatively, you can use T-shirt sizings (see Section 4.2,
T-shirt Sizing), which have the advantage of requiring you
to answer only a few questions. Of course, the disadvan-
tage is that the rough categorization into S through XL
provides only limited informational value. Occasionally,
such sizings can be sufﬁcient, depending on the speciﬁc
For this reason, it makes a lot of sense to compare the
time and effort you want to invest into a sizing project
with the potential hardware costs.
Hardware Budget Sizing Advanced Sizing Expert Sizing
̈ Very simple algorithms
̈ Assumptions, likelihoods
̈ Level setting of project
̈ Risk identification
Medium to Large Companies
̈ Throughput estimates
̈ Questionnaires, formulas
̈ Usage of standard tools
̈ Focus on core business
̈ Additional guidelines
̈ Custom calculations
̈ Analysis of custom coding
̈ Custom sizing guidelines
Resizing Delta Sizing Upgrade Sizing
All Projects All Projects
̈ SAP system monitors
̈ Goal: Extend an existing system
by functions (by different
functions, e.g., you are live with
CRM and want to add SCM)
̈ SAP system monitors
̈ SAP Notes
̈ Goal: Upgrade SAP software
Post GoLive Sizings
̈ SAP system monitors
̈ Goal: Extend an existing system
by load (e.g., by volume, 100
additional users who will do the
same as the current productive
Figure 2.1 Overview of Sizing Approaches and Methods
Budget Sizings Help in Estimating the Entire Size
Let’s suppose a budget sizing determines 4,000 SAPS
(SAP Application Performance Standard1
4,000 SAPS correspond more or less to a dual-core
machine (server) with two processors, which has a list
price of $15,000. Now you can make up your mind
whether it makes sense to tackle a rather intensive siz-
ing process or whether you want to take one of the
following two risks:
Result Is Too High
This means the server will not be fully utilized dur-
ing live operations. A result that is too high often
occurs because the initial estimates are usually too
Result Is Too Low
This means that you must buy additional hard-
ware. In this case, the question is whether you can
afford to use the wrong assumptions. Let’s sup-
pose your initial estimate is wrong by 100%. You
2.2 Methods for Initial Sizings
1 See Section 9.2, SAP Application Performance Standard, for a
more detailed description of SAPS.
Identiﬁed all processes that are critical for perfor-
Used standard tools for the core processes.
Determined the performance-critical areas in which
your processes deviate from the standard.
Expert sizings are performed just before the system
GoLive, that is, when the functionality has been clearly
deﬁned and perhaps even been implemented. In most
cases, expert sizing represents an iteration on a previ-
ously performed budget or advanced sizing so that you
can use the data of these previous processes as a basis
and simplify it, if necessary.
Basically, this method consists, on the one hand, of a
mixture of standard sizing and performance tools, and on
the other, of additional procedures and analyses. We can
roughly subdivide these two parts into:
The full utilization of the sizing tools’ functionality (in
particular, Quick Sizer’s) so that they meet speciﬁc
requirements at least in part.
The analysis and performance monitoring of core
processes in the customer system.
The following sections provide an overview of how you
can use standard tools in expert sizing to obtain useful
information, at least about parts of your system.
Standard Tools — Even for Experts
Whenever you have identiﬁed business transactions as
being close to the standard, you can use Quick Sizer (see
Chapter 5). That is, you can use Quick Sizer for partial
Another option for using Quick Sizer in expert sizing is
that you can use it for optimizing process ﬂows from the
point of view of sizing. For example, if you use overlap-
ping, performance-critical process chains, you can use the
24-hour load proﬁle provided by Quick Sizer to ascertain
whether it is possible to perform moves (see also Section
5.3, Average and Peak Sizing). Quick Sizer enables you to
map and document additional loads which, for example,
have been caused by custom coding.
Simpliﬁed Example of Expert Sizing
A company uses SAP CRM applications to enter sales
orders and uses SAP ERP for sales order fulﬁllment and
HR. The sales order processing functions in the ERP
system have been custom-coded.
For this reason, a mixed approach is used in expert
sizing in such a way that core processes are mapped
through the standard as much as possible, while the
other processes are approached step by step:
First the company uses Quick Sizer to create a
standard sizing for sales order entry in SAP CRM.
Because the sales orders that have been entered
in the CRM system are further processed in the
ERP system, a certain amount of extra capacity is
added to the sending system, that is, SAP CRM,
according to the corresponding sizing rules.
The sizing of SAP ERP is mapped in Quick Sizer on
the basis of the total number of orders. The fact
that the orders are transferred through an inter-
face does not negatively affect the performance
of the ERP system (on the contrary, it has, rather,
a positive effect because there is no user interac-
tion). This sizing represents the basic structure of
the ERP sizing.
Because the company does not know up front
what the impact of extending the sales order pro-
cessing will be, it performs performance measure-
ments that show that, because of the extension
made in the customer system, the same process
that was mapped in Quick Sizer now needs more
The customer is now able to increase the ERP
result for sales order processing by 30% in such
a way that the customer multiplies the Quick
Sizer result by a factor of 1.3. Other results (for
instance, in HR) are not affected by this.
Analyzing Customer Data
One of the most important tasks of expert sizing consists
of analyzing speciﬁc customer processes. Typical cases in
which it makes sense to analyze the performance ﬁgures
on the basis of custom data because of the strong inher-
ent customer-speciﬁc nature include the following:
2.2 Methods for Initial Sizings
changes, but not the processes (or customizing or
parameter settings, and so on).
In a delta sizing project, you add new functionality.
An upgrade sizing involves a change of the SAP
Common to all these sizing methods is that you must ﬁrst
analyze the status of the existing system before you can
plan the new hardware requirements.
Production System Sizings Versus Quick Sizer
The unbeatable advantage of sizing on the basis of pro-
duction data is that you can take your own data, pro-
cesses, and settings into account. Quick Sizer has been
designed for new installations and contains assump-
tions about the productive operation. For this reason,
we recommend Quick Sizer for initial sizings only.
Basic Analysis for All Production Sizings
For all production sizings, you must ﬁrst identify the uti-
lization of the sizing-relevant components in the exist-
ing system. Using the appropriate monitors, which are
described in detail in Chapter 6, you can determine the
What is the actual utilization of the CPU? Can the
existing hardware compensate for the future load?
Here, you must distinguish between the utilization of
the application server and that in the database.
How much room for maneuver do you have regard-
ing the memory requirement: Will it increase or stay
Take a look at the 30 biggest tables and indexes, and
make a note: How quickly did they grow during the
last several months?
Once you have determined the current utilization or the
database growth and the increasing memory require-
ments using the various vendor-speciﬁc monitors or the
SAP monitors, you should relate this information to a
simple business key ﬁgure. Usually this is the users, but
it can also be projects or calls. Alternatively, you can also
use the number of activities or sales orders, depending,
on the one hand, on which unit is best suited to reﬂect
the respective business activity, but also, on the other, on
how easily it can be determined.
Sample Analysis of a Production System
The following example forms the basis for the descrip-
tion of individual sizing methods. A customer uses
strategic procurement in the SRM environment. The
analysis of the current utilization provides the follow-
Utilization of the database server is 34%; that of
the two application servers is 56%.
213GB out of 512GB are occupied with a monthly
growth of 7GB.
26GB out of 32GB are being consumed.
By using a system monitor, the customer has found
out that approximately 1,254 named users out of a
total of 1,567 have been active during the period ana-
lyzed. Based on this information, you can now deter-
mine whether the existing hardware is sufﬁcient or
whether it must be extended.
A basic prerequisite for resizing is that only the through-
put and user volumes can change, but not the function-
ality. Based on the current load situation and the new
information, you can easily determine future require-
ments using a rule of three.
Typical resizings occur in system consolidations or in
what is referred to as phased rollouts, in which customers
install new software in different phases in their business
units or international subsidiaries.
Resizing a Production System
Based on the above example (see previous box, Sam-
ple Analysis of a Production System), a resizing could
look as follows: You want to add another 200 named
users to the 1,567 existing ones. We assume that the
ratio between named users and active users is identical
2.3 Sizings Based on Productive Customer Data
In upgrade projects, customers usually implement numer-
ous changes, which include the SAP software, database,
operating system, and an exchange of hardware. It often
happens that the conﬁguration and parameter settings are
changed as well. All this can have an impact on the num-
ber of work processes, buffer settings, or other things.1
Upgrade sizing refers to the additional requirements
of SAP software. SAP uses regression tests to check the
resource consumption of the most important transactions
and to create a delta. This information is made available
to all customers in SAP Notes, such as SAP Note 901070,
which describes the resource consumption between
SAP ERP Core Component (SAP ECC) 5.0 and SAP ERP
6.0. The SAP Notes provide information about the delta
regarding the number of database calls, CPU require-
ments, memory requirements, and database space.
Because these SAP Notes provide standardized infor-
mation about different transactions, they carry the risk of
you currently using a transaction that is counterbalanced
by other transactions.
Sample Upgrade Sizing
A (ﬁctitious) SAP Note on delta resource consumption
states that the resource consumption in the memory
increases by 5% on average. Transactions A and F do
not show any additional consumption, whereas Trans-
action G consumes an additional 30%. The CPU and
database consumptions remain unchanged.
If you — as the customer — now use Transaction G
extensively, this could cause problems when calculat-
ing the main memory. The best thing to do is to calcu-
late a best case and a worst case.
Memory (Best Case)
26GB (out of 32): 26GB × 1.05 ~= 27.3GB
Memory (Worst Case)
26GB × 30% = 33.8GB
Probably, the future memory requirement will be
within that range.
1 Since this is a very complex subject, SAP provides the SAP
GoingLive Functional Upgrade Check service as part of the
standard service coverage (see also Section 7.2, Veriﬁcation
via Support Services). The SAP GoingLive Functional Upgrade
Check includes a sizing process.
From the point of view of sizing, the majority of single-
instance projects in which companies change from a best-
to a single-instance strategy (one soft-
ware vendor, all data in one system) represent a mixture
of resizing and delta sizing, sometimes also upgrade siz-
ing. Note that an upgrade sizing must be performed ﬁrst
to make sure that identical conditions apply.
Considerations in the Context of a
A customer uses several SAP and legacy systems in
Europe. This customer now wants to consolidate its
European and American systems. Consequently, this
means the following:
If the SAP software has different release versions,
an upgrade sizing must be performed ﬁrst. The rel-
evant factors will be upgraded so that all systems
have the same version.
The next step involves resizing the SAP software
based on the same release version; that is, the cur-
rent consumptions of existing SAP systems must
be analyzed and totaled.
Finally, a delta sizing must be performed for the
legacy software. Ultimately, the additional require-
ments for the new software are added to the exist-
Because SAP software shows a high degree of scalabil-
ity, you can consider a linear change in consumption as
a given fact. The same applies to hardware: If you want
to extend the processing power of application servers,
you can add more servers, replace the CPU, or add more
CPUs, depending on your speciﬁc production model.
However, a new application server affects the data-
base’s memory requirements because it involves the
addition of new database users. A higher volume gener-
ally means an increase in read and write activities, which,
in turn, may have an impact on the disk subsystem.
2 In a best-of-breed strategy, you always choose the prod-
uct from the best vendor for each (technological) area. The
different products are then connected with each other via
Transaction ST05 57
Transaction ST06 52
Transaction ST07 54
Transaction STAD 56
Upgrade phase 8
Upgrade sizing 13, 15, 63, 67, 75
Usage type 47
interaction step 52, 57
User-based sizing 20, 38
User interaction step 57
of sizings 59, 63
Wide area network (WAN) 17, 73
in Quick Sizer 42