Sizing FAQ

SAP Quick Sizer Help Page 1 of 59
Quick Sizer Online Help Version 27
Table of Content
SAP Business Suite
SAP CRM
CRM Master Data
CRM Sales
CRM Service
CRM E-Commerce
CRM Interaction Center
CRM Mobile
CRM Marketing
SAP Web Channel Experience Management
SAP ERP
Financials
Contract Accounting
Human Capital Management
E-Recruiting
Logistics Execution
Product Development & Execution
Sales & Service
Corporate Services
SAP SCM
Demand Planning
Supply & Production Planning
Order Fulfillment
Service Parts Management
Integration to ECC
SAP Extended Warehouse Management
SAP Extended Warehouse Management - Inbound
SAP Extended Warehouse Management - Outbound
SAP Transportation Management
SAP SRM
SAP GRC Global Trade Services
Compliance and Customs Management
Risk Management Preference Processing
SAP In-Memory Computing

HANA Rapid Deployment Solutions
SAP NetWeaver BW powered by SAP HANA
Standalone HANA
SAP BusinessObjects Portfolio

SAP BusinessObjects Business Intelligence
Industry Solutions
SAP for Banking
Analytical Banking
Core Banking
SAP for Insurance
SAP for Retail
SAP for Retail
SAP Forecasting & Replenishment
SAP for Utilities
SAP NetWeaver
Portal & KMC
Business Warehouse
Process Integration
Application Server
NetWeaver Standalone Engines
Solution Manager
https://websmp205.sap-ag.de/~sapidb/011000358700000519272005e 16/03/2012
Expert Functions
The sizing elements from the questionnaires are written in italics.
Back to Top
SAP Customer Relationship Management
CRM in the
In Quick Sizer CRM is covered by the following questionnaires:
Quick Sizer
CRM Master Data / Account Management
CRM Sales
CRM Service
CRM E-Commerce
CRM Interaction Center
CRM Marketing
CRM Mobile
Check also the CRM sizing guideline on the SAP Service Marketplace.
Note for Response Times
If you want to achieve specific response times with CRM scenarios, in addition to an appropriate throughput capacity of the
hardware measured in SAPS, choose CPUs which deliver sufficient single-thread performance to fulfill your requirement.
Note for Throughput-Based Sizing
The throughput-based numbers in CRM sizing components CRM-CORACC, CRM-INDACC, CRM-ACT, CRM-LEAD, CRM-OPP,
CRM-APP, CRM-SLSQOT, CRM-SLS, CRM-SLSCON, CRM-SRVACT, CRM-SRVQOT, CRM-SRV, CRM-CONF, CRM-CPLT, CRM-
WCL, CRM-SRVCON, and IC-CALL reflect scenarios that consist of multiple dialog steps and are executed from CRM Web UI
in the browser. The total resource consumption with such scenarios is much higher compared to execution of similar
functionality in batch mode and therefore this sizing is not applicable to batch execution.
Note for IPC Handling
In Quick Sizer, whenever pricing is part of the CRM business process, the resource consumption of pricing is calculated with
simple rules configuration. The CRM sizing in Quick Sizer includes IPC resources (VMC in the same backend system), but for
a very basic pricing configuration.
With more complex customer specific pricing rules/pricing configuration the sizing guide of IPC
(https://service.sap.com/~form/sapnet?
_SCENARIO=01100035870000000112&_SHORTKEY=00200797470000071612&_OBJECT=011000358700002722012003E&)
or even better expert sizing should be applied.
CRM Master Definition

Data /Account Business partners are any parties in which your company has a business interest or with which your company has a
Management business relationship. You can create and manage your business partners centrally for different business transactions, and
ACC-USER, reflect the different roles they play, such as sold-to party and ship-to party.
CRM-CORACC,
A business partner can be an account. An account is a company, individual, or group with which you have a business
CRM-INDACC
relationship. An account can be, for example, a customer, prospect, vendor, or competitor. Accounts are subdivided into the
following types:
Corporate accounts (companies or organizations or firms, etc), typically used in B2B relationships
Individual accounts (private individuals), normally used in B2C relationships
Therefore, Quick Sizer distinguishes between sizing for individual accounts and for corporate accounts.
Specifics for CRM Mater Data / Account Management
New Acc (New Accounts)
Total number of new created accounts per year (individual or corporate accounts)
With creation of corporate accounts header information (name, title, etc.), address data, communication data,
roles, and contacts are maintained.
With creation of individual accounts typically only header information, address, and communication data are
filled in.
This is the reason why the resources calculated by Quick Sizer to create a corporate account are significantly
higher compared to resources for creation of individual account.
Changed Acc (Changed Accounts)

Total number of changed accounts per year (individual or corporate accounts)
The resource consumption with change account functionality is measured by search for account by account
identification number (ID), open the account in edit mode, change of the addresses and communication data
for this account and save.
Displayed Acc (Displayed Accounts)

Total number of displayed accounts per year (individual or corporate accounts)
The resource consumption of display account is based on search for the account by ID, view the account
summary data and navigate to detailed data for contact information and address.
Tot. Accounts (Total Accounts)
Total number of individual or corporate accounts managed in the CRM system
The ACC-USER sizing is based on the average resource consumption of all dialog steps included in create,
display, and change scenarios for CRM-CORACC and CRM-INDACC.
The CRM-INDACB sizing calculates the resource of consumption of creation of individual accounts with a
remote call to the backend system (no CRM Web UI is involved).
Note
The ACC-USER should be used as alternative and should not overlap with CRM-CORACC and CRM-INDACC throughput
sizing.
Unlike of the rest of the throughput sizing elements in CRM, the changes and displays to an account are handled as
absolute numbers and not as %.
CRM Sales In the Quick Sizer CRM Sales covers

Activity Management
Leads
Opportunity Management
Sales appointment
Sales quotation
Customer orders
Sales contract
CRM Sales - Definition

Activity Within Activity Management, your employees can:
Management Create business activities to document any interaction they have with customers
ACT-USER Create tasks to manage their own workload
CRM-ACT Manage their work in the Application Workplace
View appointments and activities in the calendar
Access the Business Workplace for using workflow items
Activities often are some kind of follow-on actions, for example a follow-up call after an initial sales conversation with a
customer. The two main elements in Activity Management are the application workplace and the calendar. Each provides a
different view of your workload and you can switch between them. The calendar displays all your appointments in a daily,
weekly, or monthly overview. In Quick Sizer the type of activity “Appointment” is handled in sizing element CRM-APP.
The sizing for CRM-ACT create scenario is based on creation of new task or new interaction log, maintain header data and
save.
The sizing for ACT-USER is based on average resource requirements of CRM-ACT and CRM-APP.
Changes to an activity are regular. Make sure you include this information in the sizing.
Note
With CRM-ACT throughput sizing the input data for number of displays and changes is required as percent of the number of
created objects.
Comment
User-based sizing element ACT-USER should be used as alternative to the throughput-based sizing element CRM-
ACT. Overlap should be avoided.
Any attachments to activity such as text files, presentations, documents in print format, photos, etc. which are
uploaded into CRM are not considered in this approach and should be calculated additionally.

Lead A business transaction which describes, stores, updates, and manages the potential interest of (and interaction with) a
CRM-LEAD business partner over a certain timeframe. Leads are used to qualify a business partner's interest in a particular product or
in making a purchase, with the aim of both establishing and then subsequently influencing this interest. Once a lead has
reached a certain status, it can be passed on to "Sales" as decision support for creating an opportunity.
The sizing calculation with create lead scenario includes the creation and saving of a lead of predefined type, maintenance
of header data, prospect data and sales organization data.
Note
With CRM-LEAD throughput sizing the input data for number of displays and changes is required as percent of the number
of created objects.

Opportunity The opportunity describes the sales prospects, their requested products and services, the sales prospect’s budget, the
Management potential sales volume and an estimated sales probability. This information becomes concrete in the course of the sales
OPP-USER cycle, and can be displayed and evaluated in the system.
CRM-OPP
Opportunity Management provides the framework for presenting sales projects from the very start, and tracking their
progress. In this way, it provides the basis for an analysis and optimization of your Enterprise.
Users in Opportunity Management can use the following functions:
Presentation of the sales cycle
Reason for status
Working with products
Management of attachments
Transferring data for sales volume forecast
Classification of opportunities
Texts in opportunities
Opportunities - Fast change
The sizing calculation with create opportunity scenario is based on the creation and save of opportunity after maintaining
the header data, volume, currency, etc.
Changes to an opportunity are regular - make sure you reflect this information in the sizing.
The sizing of OPP-USER is based on average resource consumption of CRM-OPP.
Note
With CRM-OPP throughput sizing the input data for number of displays and changes is required as percent of the number
of created objects.
Comment
User-based sizing element OPP-USER should be used as alternative to the throughput-based sizing element CRM-
OPP. Overlap should be avoided.
Any attachments to opportunity such as text files, presentations, documents in print format, photos, etc. which are
CRM Sales - Sales Definition

Appointment Type of planned activity in Activity Management that is maintained in an employee's calendar, including external
CRM-APP appointments and scheduled meetings with business partners. Appointments usually contain information regarding the
business partner involved, the date on which it is to take place, and whether or not it is private in nature.
The sizing calculation includes creation of new appointment, maintain data such as time, location, invitation list, sales
organization data, relate to an opportunity, and save the appointment.
Changes to an appointment are regular - make sure you reflect this information in the sizing.
Note
With CRM-APP throughput sizing the input data for number of displays and changes is required as percent of the number
of created objects.
Comment
Any attachments to appointment such as text files, presentations, documents in print format, photos, etc. which are

Quotation An offer by a sales area to a customer for delivery of goods and services according to fixed terms. The offer legally binds
CRM-SLSQOT the company for a certain period of time. A customer quotation can refer to a partner sales activity or it can be used by
the sales area to reply to a customer inquiry.
The sizing calculation includes creation of new quotation, maintain header data, add item(s) to the quotation, and save.
Note
With CRM-SLSQOT throughput sizing the input data for number of displays and changes is required as percent of the
number of created objects.

Customer Orders In CRM, customer orders can be created in different ways, for example by a telesales agent in the call center or by
SLS-USER customers via the Internet. Directly created orders in CRM Online are included here as well.
CRM-SLS
It is important to enter the customer orders in the line/application/module where they are closest to because this may
have a great influence on sizing.
The sizing calculation includes create of new sales order, maintain header data as sold to party, contact, etc., add item
(s), and save.
The sizing of SLS-USER is based on average resource consumption of CRM-SLS.
Note
With CRM-SLS throughput sizing the input data for number of displays and changes is required as percent of the number
of created objects.
Comment
The SLS-USER should be used as alternative and should not overlap with CRM-SLS throughput sizing. Overlap should be
avoided.

Contract and An outline sales agreement that contains special conditions negotiated between the vendor and a customer, for example,
Contract price, target value or target quantity. A sales contract is valid for a specified period. A customer submits a sales order to
Quotation release products from the amount agreed in the contract. Types of sales contract include value contracts and quantity
CRM-SLSCON contracts.
Definition Sales Contract Quotation

A legally binding offer to a customer for agreement of delivery of goods and services included in the sales contract. The
sales contract quotation can be preceded by a customer inquiry for a contract offer.
The sizing calculation includes create new sales contract, maintain header data, add item(s), and save.
Note
With CRM-SLSCON throughput sizing the input data for number of displays and changes is required as percent of the
CRM Service In the Quick Sizer CRM Service covers

Service activities
Service order quote
Service transactions
Service confirmations
Complaint, return and inhouse repair
Warranty claim
Service contract and contract quote
CRM Service - Definition

Service Activities Within Activity Management, your employees can:
CRM-SRVACT Create business activities to document any interaction they have with customers
Create tasks to manage their own workload
Manage their work in the Application Workplace
View appointments and activities in the calendar
Access the Business Workplace for using workflow items
The sizing scenarios with CRM-SRVACT are similar to the sizing scenarios for CRM-ACT.

Service Order An offer to a customer for delivery of goods services according to fixed terms. The offer legally binds the company for a
Quotation certain period of time. A customer quotation can refer to a partner sales activity or it can be used to reply to a customer
CRM-SRVQOT inquiry.
The sizing scenarios with CRM-SRVQOT are similar to the sizing scenarios for CRM-SLSQOT.

Service You can use the component Service transaction to represent business processes in the service area in your company.
Transactions Service transactions can be entered in the following ways.
SRV-USER By an employee in the CRM System
CRM-SRV By an employee in the Customer Interaction Center
By your customer via the Internet
The service transaction can be either a service order or a service request.
Definition
A short-term agreement between a service provider and a service recipient, in which the service recipient orders one-off
services which are billed when completed using resource-related billing. The line for service orders includes the following:
Service Order
Services
Spare parts
Products
Prices
Billing data
The sizing scenarios with CRM-SRV are similar to the sizing scenarios for CRM-SLS.
Comment
The SRV-USER should be used as alternative and should not overlap with CRM-SRV throughput sizing. Overlap should be
avoided.

Service Business transaction that is used to confirm a service process. It is used to document how many hours and parts it was
Confirmations actually necessary to use in order to provide the service.
CRM-CONF
The sizing calculation includes create new service confirmation, maintain header data, add item(s), and save.
Note
With CRM-CONF throughput sizing the input data for number of displays and changes is required as percent of the
CRM Service - Definition Complaints and Returns Management

Complaint, Return This business scenario is used to process customer complaints within the sales and service organizations. A complaint is
and Inhouse an expression of dissatisfaction that a customer makes in relation to a service or product. If a customer returns a product
Repair without first making a complaint, this is a return. Complaints Management is used in the company to represent the entire
CRM-CPLT complaints process from recording a complaint, the technical analysis and relevant follow-up process steps, through to
statistical evaluation.
Definition In-House Repair
This business scenario is used to perform the entire in-house repair process, from the creation of the repair order
through to billing (at the moment there is no sizing available for the billing process).
The sizing calculation includes create new complain, maintain header data, add item(s), and save.
Note
With CRM-CPLT throughput sizing the input data for number of displays and changes is required as percent of the

Warranty Claim Claim for reimbursement of material, labor and other costs that are incurred for the purpose of rectifying faults in an
CRM-WCL object. Prerequisite is that a valid warranty exists for the object. All warranty claims run through different versions which
are assigned to predefined categories. They are automatically checked according to rules. Depending on the result,
further processing is then carried out automatically or manually.
The sizing calculation includes create new claim, maintain header data, maintain billing data, add item(s), and save.
Note
With CRM-WCL throughput sizing the input data for number of displays and changes is required as percent of the number
of created objects.
CRM Service - Definition Service Contract

Service Contract A long-term agreement about the content and scope of services that are performed for a customer. A service contract
and Contract describes which services will be performed for which objects and with which conditions. It consists of a header and one or
Quotation more items. The header and each item can contain the following data:
CRM-SRVCON Price agreements
Additional data (validity period, notice period and so on)
Texts
Status
Partner data
You can also extend each contract item with a billing plan and object list.
Definition Service Contract Quotation
A legally binding offer to a customer for agreement of services included in the service contract. The service contract
quotation can be preceded by a customer inquiry for a contract offer.
The sizing scenarios are similar to the sizing scenarios for CRM-SLSCON.
Note
With CRM-SRVCON throughput sizing the input data for number of displays and changes is required as percent of the
CRM E-Commerce Definition

- Using SAP Internet Sales, manufacturers, shippers, wholesalers, and retailers can sell their products directly via the
Internet Sales World Wide Web. The following components are contained in CRM Internet Sales:
CRM-ISA Business-to-Consumer (B2C) Internet Sales
Business-to-Business (B2B) Internet Sales
Business-to-Reseller (B2R) Internet Sales
Specifics for E-Selling in Internet Sales
Shop visits
Number of visits to Internet shop (a visit normally consists of about 15 steps)
% ord.
Browsing the Percentage of visits that lead to orders
Catalog and Items
Placing Orders Average number of line items/sub objects per order/object
IPC
If checked, Internet Pricing Configurator (IPC) is used. Otherwise, catalog list prices are used.
Months
Number of months the data remains in the database (residence)
Archiving
Checks for existing archiving objects (no influence)
Comment
Typically Internet Sales users will visit the internet shop and browse through the catalog to gather information about
products. Some users will put products into the shopping basket and place an order.
Enter the number of user visits to the shop and also specify in percentage how many visits will lead to an order. This
varies for the different Internet Sales scenarios: For B2C typically 10% of the visits lead to an order, while with B2B this
percentage is much higher.
CRM Interaction Definition

Center - The Customer Interaction Center (CIC) is a key technology of Customer Relationship Management with the SAP Business
Customer Suite. It is designed as a multi-channel, blended business process interaction center to empower call centers to provide
Interaction the highest level of customer service. It provides robust technology for contact center operations. It tightly integrates a
Center highly customizable and full-featured front office with your back-office as well as your entire range of customer-centric
processes. The Customer Interaction Center is the common state-of-the-art technology for any business transactions via
IC-USER
phone, email, letter or face to face. It is used in the following CRM Business Scenarios: Service Interaction Center,
Telesales and Telemarketing. Highlights of CIC include:
Processing inbound and outbound telephone calls with customers and other business partners using Computer
Telephony Integration (CTI) technology as middleware.
An Email Office system for processing incoming and outgoing emails. Also included are Planned Activities for the
agent to execute.
A comprehensive Interaction History log to provide one view of a customer. This enables agents to view planned
and historical activities along with sales and service orders.
Comment
If there is "normal handling" of smaller objects (such as activities, small sales orders, service tickets ...), then the
deciding figure for the user-based sizing - "resource consumption per dialog step" - is nearly independent from the object
which is created within IC. Therefore the pure IC user sizing of the Quick Sizer applies.
But if you take a look at extreme cases, where for example within the B2C use case, sales documents with about 100
items are created in one step by using templates (which is quite familiar in some industry sectors), then the sizing of the
pure IC user will be insufficient. In such a case you should enter the affected users additionally, for example within the
CRM sales questionnaire (that means extra CPU and extra memory).
CRM Interaction Definition

Center - CIC Enter the number of incoming and outgoing emails and calls. Note that business objects created during a call, such as a
Emails and Calls customer order or a service order must be sized additionally.
IC-CALL
Example
Altogether, 100,000 customer orders are being created, 50,000 of them through CIC. To reflect this, you enter 100,000
under customer orders and 50,000 under calls.
Comment
Because of the flexible design of the CIC and the SAP Workplace, other systems (such as non-SAP or legacy systems)
can be incorporated in the process as well. Only objects created or changed in CRM need to be considered and
consecutive load in systems other than SAP CRM is not in the scope of this sizing. For example, if a call center agent
opens a customer order in a legacy system to display the delivery status, this has no influence on CRM sizing.
CRM Mobile - Definition

Mobile Sales and Mobile Sales allows sales teams to work offline and to synchronize their data with the backend system. In this way, it
Service supplies all the information required for optimal customer interaction. Such information can include real-time updates on:
MSA-USER Business partners
CRM-MSA Contact persons
Products and services
Opportunities
Activities, etc
This component implements functionalities allowing sales representatives to:
Coordinate their activities, including marketing and advertising campaigns
Present product lines and compare them to competitive products
Create quotations and orders immediately on site
Ensure that orders are correct and confirmable, including configuration, pricing, and delivery data
Coordinate the transmission, retrieval, and storage of inbound and outbound information
Mobile Service allows field service representatives to review daily service visit agendas, prepare service jobs, report on
time spent and materials used as well as reporting on malfunctions encountered. It also enables field personnel to enter
information on actions performed to fulfill service obligations.
The MSA-USER and CRM-MSA sizing scenarios cover creation and synchronization of objects in the backend.
Note
With CRM-MSA throughput sizing the input data for number of displays and changes is required as percent of the number
of created objects.
In general, the mobile sales users will upload their data to the CRM system in a time frame of a few hours, for example in
the evening. Enter the highest number of users you expect to login within one hour.
Users of handheld sales and handheld service functionality should be sized in this component.
CRM Marketing Definition

SAP CRM Marketing is an integrated, closed loop solution enabling marketers to analyze, plan, develop, execute, and
measure all marketing activities.
Key capability Marketing consists of the following scenarios:
Loyalty Management
Campaign Management
Marketing Resource Management
Segmentation and List Management
Trade Promotion Management
Find details within the documentation, Section 3.3 Marketing.
In Quick Sizer we offer sizing implementations for Campaign Execution and Loyalty and a link to the sizing guideline for
‘Trade Promotion Management’.
Note
There is an example project for SAP CRM Marketing for customer 188213 project name "CRM MARKETING V22 F.".

- Loyalty CRM Loyalty Management covers the complete process for tracking and encouraging customer (member) behavior. Find
Management details within this documentation, Section 3.3.2 Loyalty Management.
LOY-UPLOAD,
Loyalty Management delivers functionality for offline mass upload (Quick Sizer sizing element ‘LOY-UPLOAD’) and
LOY-PROC,
processing (Quick Sizer sizing element ‘LOY-PROC’) of member activities, which are exported in data packages from any
LOY-CMA,
source systems (other SAP CRM systems or 3rd party systems).
LOY-PMP,
LOY-RMD The Loyalty Management system could be also used for online (real-time) operations. The sizing element LOY-CMA
covers create member activity, process member activity (using Loyalty Engine) and query point account balances. Sizing
element LOY-PMP covers create member activity, post points and query point account balances. Sizing element LOY-
RMD covers get membership header details, get tier details, get point account details and get BP details (Header &
Addresses).
Specifics for CRM Loyalty Batch Jobs for Upload (LOY-UPLOAD)
Activities (Number of activities)
Enter value for the total number of member activities which should be uploaded in the defined time interval.
Mon. (Number of months the data remain in the database)
Enter the number of months that data remains in the database (residence time).
Note
The loyalty offline mass upload and processing is usually bound to requirement for the duration of the
execution and therefore in Quick Sizer it is more appropriate to use the peak sizing per period compared to
the average year sizing. Whenever possible avoid overlapping intervals for upload and processing to
minimize the resource consumption requirements.
To efficiently allocate hardware resources that are calculated in Quick Sizer the number of
MA_LSMW_UPLOAD_MAX_NO_WP which are used for CRM Loyalty Management and configurable in the CRM
system under ‘Spro -> IMG -> Customer Relationship Management -> Marketing -> Loyalty Management -
> Processing Settings -> Define Batch processing Parameters’ should be maintained.
For example, equal to the number of CPUs (out of the total machine capacity) which the customer would
like to dedicate to loyalty batch job.
Specifics for CRM Loyalty Batch Jobs for Processing (LOY-PROC)
Activities (Number of activities)
Enter value for the total number of member activities which should be uploaded in the defined time interval.
Rules p a (Average number of rules per activity)
Enter value for the average number of rules which are defined per single activity. A typical expected value range is
not more than 10, while maximum enabled value in Quick Sizer is 99.
Act p.r (Average number of actions per rule)
Enter value for the average number of actions defined per one rule. A typical expected value range is less than five
while Quick Sizer enables values up to nine.
Specifics for CRM Loyalty Online Processing (LOY-CMA (Create member activity), LOY-PMP (Post member
points), and LOY-RMD (Retrieve member data))
Objects (Sizing objects created per time unit (TI)
Enter the number of remote requests which the CRM Loyalty system needs to handle in the defined time interval.
The expectation is that each request registers exactly one member activity with or w/o points or retrieves
information for exactly one member.

- Campaign CRM Campaign Management covers the complete process for running a campaign, find details in the documentation,
Execution Section 3.3.1 Campaign Management.
CAMP-GEN,
From perspective of system resource requirements and configuration the critical process part is the execution of a
CAMP-HV
campaign. With SAP CRM 7.0 SR1, on top of the already existing functionality for campaign execution, SAP introduced
high volume campaign execution.
Specifics for CRM General Campaign Execution (CAMP-GEN) and CRM High Volume Campaign Execution
(CAMP-HV)
BP (Number of business partners in target group)
In all cases the sizing input requires the total number of business partners which are contained in the target group
or the segment which is used for the campaign.
E-mail (Send E-mail?)
Check the flag, if the campaign will make use of e-mails. If the flag is unchecked, the campaign will make use of
file export.
Act. (Generate activity) - only available for sizing element CAMP-GEN
If the flag is checked,the campaign will generate activities. If the flag is unchecked, the campaign will generate
interaction objects.
The CRM side part of the export to SAP NetWeaver BW is always included.
Note
The campaign execution is usually bound to requirement for the duration of the execution and therefore in Quick Sizer it
is more appropriate to use the peak sizing per period compared to the average year sizing. For each different campaign
create a new line of peak interval in the sizing table. When possible avoid overlapping intervals of execution of the
different campaigns to minimize the resource consumption requirements. To efficiently allocate hardware resources that
are calculated in Quick Sizer the number of ‘parallel processes’ which are used for CRM campaign execution and
configurable in the CRM system under ‘Spro -> IMG -> Customer Relationship Management -> Marketing -> Marketing
planning and Campaign management -> Campaign Execution -> Make Settings for Parallel Campaign Execution’ should
be maintained.
For example, equal to the number of CPUs (out of the total machine capacity) which the customer would like to dedicate
to campaign execution.
Back to Top
SAP Web Channel Experience Management
Íntroduction to Introduction
SAP Web Channel SAP Web Channel Experience Management installation uses the following software technologies from SAP: Web AS Java,
Experience AS ABAP in CRM or ERP usage and MDM Server. It could be run in four different variants of shopping cart, which influence
Management the sizing result and are reflected in Quick Sizer as sizing elements:
Java shopping cart with CRM order backend (sizing element J-SC-CRM)
CRM shopping cart with CRM order backend (sizing element CRM-SC)
Java shopping cart with ERP order backend (sizing element J-SC-ERP)
ERP shopping cart with ERP order backend (sizing element ERP-SC)
Additional resource consumption influencing factor is the choice between list pricing and dynamic pricing. With dynamic
pricing IPC resource consumption is accounted to the CRM backend, where IPC is actually located. Quick Sizer delivers
throughput-based sizing for all involved components, according to selected shopping cart and pricing configuration.
Note for Good Response Times
SAP Web Channel Experience Management is such type of product for which end user set very challenging response time
requirements. To achieve that choose CPUs with best Single Computing Unit performance (see also OSS note 1501701).
Shopping Carts in Definition

SAP Web Channel The different sizing elements J-SC-CRM, CRM-SC, J-SC-ERP, and ERP-SC represent only different shopping cart
Experience configuration but the input parameters for all sizing elements are similar.
Management
J-SC-CRM, Example project on how to use sizing of Web Channel is “WEB CHANNEL EXP.MGMT” for customer 188213.
CRM-SC, Specifics for Shopping Carts
J-SC-ERP,
ERP-SC Shop visits
A shop visit means access to the web shop, with or without user authentication, and doing several navigations
inside the shop. A visit to the shop could be creating order, but could also be only viewing catalog data without
creating order.
% of visist that lead to orders (% ord)
With B2C usages only few shop visits will end with purchase order. The '% ord' in such cases might be in
range of 10-20%.
With B2B usages it is more likely that almost every visit ends with purchase order, the '% ord'. then could
be in range of 90-100%.
Items
With B2C an order usually contains few items, though it might depend on the shop. An online chocolate
shop might have a typical order of 10 different products, while an online shop for shoes not likely to have
more than 1-2 product/s per order.
With B2B usages it is more likely that almost every visit ends with purchase order. Here the number of
items per orders can be significantly bigger.
Pricing method
Choose between 'List pricing' and 'Dynamic pricing' Dynamic pricing technically bases on SAP IPC and increases
the resource consumption on CRM backend. Only basic pricing configuration is used for preparing pricing sizing.
Expert sizing might be required for more complicated cases.
Navigations per shop visit (30 per default)
The number of navigations in the shop depend on the size of the shop, catalog, etc. It is more likely that the users
browse longer in a shop if their are more products and on contrary if the shop offers only few selected products,
the shop visits will be short. The navigations should not count adding products to basket and check out navigations
which are covered in the creation of the order itself (reflected in '% ord.').
Products per page (12 per default)
The products per page configuration is shop-specific and means how many product images and details are placed
on the same web page. Some web shops limit to only few products while other web shops prefer to offer all
choices at once and thus offer 10ths of products on same page. More products per page means higher resource
consumption. Anyway, more products per page could reduce the overall number of navigations in the shop.
%display
After users create an order usually they check the status of the order either on own initiative or after receiving any
kind of notification. If the users display the status of their order 2 times, the '% dsp'. should be set to 200%. If
there are no displays, nothing has to be entered.
Months
Number of months the data remains in the database (residence)
Notes on Quick Sizer results
The results in QS are provided like
Solution 'CRM' on Quick Sizer result page – Sizing for the CRM backend system, which is configured to run with
web channel. Disk space sizing, SAPS and memory are calculated.
Solution 'ERP' on Quick Sizer result page – Sizing for the ERP backend system, which is configured to run with web
channel. Disk space sizing, SAPS and memory are calculated.
Solution 'WEB-CHAN' on Quick Sizer result page – Sizing for the Web Channel which includes SAPS and Memory
for Java server and SAPS for MDM server. Disk sizing for Java server and MDM is not provided because with the
online shopping scenario there is no data growth on Java server and MDM side. The initial population of catalog
data in MDM, which requires disk sizing and memory sizing, is addressed in the MDM sizing document.
SAP ERP
Back to Top
SAP ERP Financials
Financials Definition
SAP ERP Financials comprises
Financial Supply Chain Management (FSCM)
Financial Accounting (FA)
Management Accounting (MA)
Corporate Governance (CG)
Financial Supply Chain Management includes functions such as Treasury and Risk Management, Cash and
Liquidity Management (CLM), Credit Management, and Dispute Management. The dominating functions of
Financial Accounting are General Ledger, Accounts Receivable and Payable, Fixed Asset Accounting, and
Financial Statements. Amongst others, Management Accounting includes Profit Center Accounting, Project
Accounting, Revenue and Cost Planning, and Transfer Pricing.
The Quick Sizer maps most of the sizings of FSCM and FA to FI, Management Accounting is predominatly reflected in CO.
From a sizing perspective Corporate Governance plays a subordinate role.
FI User Definition
FI-USER In general, all users in the above transactions can be sized with 1 FI user (e.g. FI-AA, CLM).
To size Treasury and Risk Management (TRM) users, enter 2 FI users per TRM user.
Note
Business Warehouse with its Strategic Enterprise Management comprises the functions that were formerly accounted for
by Enterprise Controlling.(see Business Warehouse)
Controlling Definition of CO documents

CO-USER A proof of a cost accounting posting. This posting can be made both within (for example, distribution) and outside of (for
CO example, primary cost posting in FI) CO.
Example
Documents to capture consumption of production factors
Documents to capture the services of an enterprise
Line items: Because of double accounting, every document contains at least two line items. The number of line items in
CO-OM and CO-OM-ABC (Activity-Based Costing) are posted to CO objects (such as orders, cost centers, and projects).
Postings to statistical orders consist at least of three line items, because a statistical order contains booking, counter-
booking and a separate display of the costs to enable descriptive reporting. Activity allocations add another line to the
posting, because additionally the amount of services (non-monetary) are booked separately.
Example
Posting from Posting to Number of line items

Cost center Cost center 2
Cost center Statistical order 3
Posting activity calculation from Posting activity calculation to Number of line items
Cost center Cost center 3
Cost center Statistical order 4
Comment
If you use detailed planning, you should add line items created during planning.
Enter the number of line items that are created online (D = standard sizing for throughput)
Enter the period closing activities (B = standard sizing for background)
Postings into CO, for example

(D) FI-postings into CO
(D) Material movements into CO
(D) Completion confirmations (PP,PM)
CO-internal allocations, for example
(D) Reposting
(D) Activity allocation
(B) Indirect activity allocation -> assessment
(B) Overhead rates -> overhead rate
(B) Settlement -> settlement
(B) Assessment -> assessment
(B) Distribution -> assessment
(B) Periodic reposting -> assessment
(B) Template allocation is currently not included. It mainly consists of a set of customer-defined functions,
so measurements for CPU consumption cannot be done
Profitability Comment
Analysis In our experience, the number of documents that you transfer to CO-PA from Sales and Distribution (SD) or Financial
CO-PA-BIL Accounting (FI) serves as a good indicator of the disk space and system load that CO-PA represents. Using this indicator
CO-PA-FI simplifies the sizing process because the Quick Sizer no longer needs to take into account the contributions from
CO-PA-SLS planning, cost center assessment, the information system, realignments, or settlement. If your requirements in one of
these areas are high (for example, a large volume of data needs to be processed by a large number of users during peak
system load times), you should contact your hardware partner or SAP. To gain a deeper understanding of the factors that
can influence sizing and performance, see the information contained in at service.sap.com/co-pa.
Transferred Objects: If you use Profitability Analysis, SD billing documents (SD-BIL) and FI documents are transferred to
CO-PA automatically. The transfer of orders (SD-SLS), on the other hand, is optional. For objects, enter the number of
documents transferred per year from the respective components to CO-PA. For sub objects, enter the average number of
document items in each case. You can also use the above methods to display how external data is transferred to CO-PA.
Profit Center Definition

Accounting Number of documents that are posted to Profit Center Accounting (EC-PCA). For sizing we assume that the majority of
Documents postings are created in other components and then posted to EC-PCA.
EC-PCA Enter the number of documents that are created in PCA with their respective lines items and the number of orders that
have been posted by other components.
Business Definition
Accounting The proof of a business transaction. A distinction is made between original documents and data processing (DP)
Documents documents:
FIN-BAC Original documents include incoming invoices, bank statements and carbon copies of outgoing invoices.
DP documents include accounting documents, sample documents and recurring entry documents.
Whereas accounting documents are a representation of the original document in the SAP System, sample and recurring
entry documents are simply templates to simplify entry of accounting transactions.
Assessment Definition
CO-OM Assessment is a method of internal cost allocation in which you transfer the costs of a sender cost center to receiver CO
objects (orders, other cost centers, and so on) under an assessment cost element. The system supports both the
hierarchical method (where the user determines the assessment sequence) and the iterative method (where the system
determines the sequence via iteration).
Estimation of line items for assessment, distribution and periodic reposting:
The segments of all cycles have to be added. For each segment the line items (sender (S) - receiver (R) relationship) may
be calculated:
assessment S-R = number of senders * number of receivers

distribution S-R = number of senders * number of receivers * average number of cost elements used by the sender
periodic reposting (equal to distribution)
Indirect activity allocation S-R = number of senders * number of receivers * average number of activities used by
the sender
Example
You have defined a cycle which consists of the segments A and B. Each segment consists of 5 senders and two receivers.
Each receiver(R) of segment A has received postings from each sender(S) with three different cost elements (CE). Each
receiver(R) of segment B has received postings from each sender(S) with four different cost elements.
Therefore the cycle has 30 + 40 = 70 S-R relations altogether.
Segment A: 5 (S) * 3 (CE) * 2 (R) = 30 S-R relationships
Segment B: 5 (S) * 4 (CE) * 2 (R) = 40 S-R relationships
Overhead Rates & Definition

Order Settlement Overhead rate refers to a rate at which overhead is allocated to direct costs to charge cost objects with the proportion of
CO-OM-RATE the overhead costs attributable to them. This can be a lump sum, percentage, or quantity-based rate.
CO-OM-SETT
An example of the use of overhead rates is to allocate overhead from material cost centers to orders by debiting the
orders in proportion to the material withdrawals and crediting the material cost centers with the same amounts. Also used
to allocate sales and administration overhead.
Order settlement is the complete or partial crediting of an order. The costs which have accrued to an order are debited
to one or several allocations.
Overhead rates: Enter the number of orders, cost centers and projects, that receive an overhead rate per period.
Order settlement: Enter the number of orders (from PP, PM, and CO) which are settled per period. We assume that your
orders are settled without using the original cost element.
Back to Top
Contract Accounting
Contract Definition
Accounting Find more information on Contract Accounting within the document "Sizing Contract Accounting with the Quick
Sizer" at the Service Marketplace www.service.sap.com/quicksizing -> Using the Quick Sizer -> Experts.
The whole sizing is split into one mandatory and four optional blocks:
EDR Billing (optional)
* EDR-UPL
* EDR-BILL
Upload of billing documents (optional)
* LOAD-BILL
Convergent invoicing (optional)
* CONV-INV
* Subledger
Upload of subledger documents (optional)
* LOAD-INV
FI-CA (mandatory)
* PAY-RUN
* CD-PL
* DUNNING
* DEF-POST
* CORR-PRINT
.
EDR Upload Definition

(optional) An event detail record (EDR) is a line which tells about an event for which the business partner has to pay a certain
EDR-UPL amount. This can be a phone call, the purchase of a good at an online store, a package or letter send or a road toll. These
records are loaded into the system and later, during the billing, they are grouped together according to certain grouping
criteria.
The tables keeping the EDRs on the database contain some required fields, such as an EDR ID, the event time, the
loading time etc. They are given by SAP. However, they are not sufficient to do the grouping during the EDR billing.
Therefore, customers can define their own additional fields according to the needs. As this can have a big impact on the
database, the length of these additional fields in bytes is requested. (Tip: keep the additional fields as short as
possible. These table can easily be 30 % or 50% of the whole database size)
Specifics for this sizing element for CPU Sizing

Objects
Here the total number of EDRs loaded per run is requested.
Specifics for this sizing element for Disk Sizing
Event detail records (EDRs)
Here the total number of EDRs loaded per year is requested. This could correspond to the number of calls
transmitted by a phone company or the number of sales of an online store.
Length of additional fields in EDR table [bytes] (AddFld)
For explanation see above. Currently, no example values exist.
.
EDR Billing Definition

(optional) During the billing run billing documents are created by aggregating EDR records. The aggregation is based on billing
EDR-BILL accounts and certain grouping criteria which cannot be specified more in detail as they are customer specific. The
resulting billing documents consist of a header and a certain number of billing lines. This number is usually lower then the
average number of EDRs that is processed per billing account.
A phone company might usually have one line for each of the following services: landline calls, mobile calls, internet
access and other services (such as the purchase of a new cellphone). Each EDR is sorted into one of the four buckets
during the billing, so the average number cannot be higher then four. However, in this example the answer to this
question is more likely to be three, as not many customers purchase a new cellphone every month.
Billing documents (Objects)
Total number of billing documents created per year is requested. If this is not known, you could estimate it by
number of business partners (assuming a 1:1 relationship between business partners and billing accounts which is
a good guess in most cases) and the average number of bills they get during the year.
Billing lines per billing account (Items)
Average number of billing lines of a billing document.
Event detail records (EDR) per billing document (EDRs/bd)
Average number of EDRs handled per billing document. This could correspond to the number of calls transmitted by
a phone company or the number of sales of an online store.
Total number of billing documents created per year is requested. If this is not known, you could estimate it by
number of business partners (assuming a 1:1 relationship between business partners and billing accounts which is
a good guess in most cases) and the average number of bills they get during the year.
Billing lines per billing account (Items)
Average number of billing lines of a billing document.
.
Upload of Billing Definition

Documents This section and hence the parameters are only important, if it is planned to upload billing documents from an external
(optional) source, e.g. SD. In a hybrid scenario where the majority of billing documents come from the EDR billing and only some
LOAD-BILL are uploaded from an SD, the values to be entered herein might be different from those entered in the EDR billing
section.
Specifics for this sizing element for CPU and Disk Sizing
Total number of billing documents uploaded per year is requested.
Billing lines per billing document (Items)
The average number of lines of an uploaded billing document.
Convergent Definition
Invoicing During invoicing billing documents are converted into invoicing and subleger documents. In most cases there is a 1:1
(optional) relationship amongst them, one billing document gives one invoicing document and one subledger document, therefore
CONV-INV this assumption has been built into the Quick Sizer.(Tip: in cases where multiple billing documents are aggregated into
one invoice, the number of billing lines per invoice document should be used as input in ‘Lines per invoicing document’.
This gives a better result)
The relation between billing lines and invoicing lines is difficult to estimate, it can be everything from less lines to more
lines. Invoicing can aggregate billing lines but also adds tax lines to the document, hence this behaviour. Example: For
each phone in a company's office a bill is created and there might be only one bill for the whole office. However, it would
be possible to create two invoices, one for the head of the office and one for the other employees. In this case, there
would always be two invoices per contract account.
These phone bills may consist out of landline calls, mobile calls, internet usage and cellphone purchase, but there might
be five lines on the invoice, one for mobile and landline calls, one for internet usage, one for cellphone purchase and one
additional for VAT.
Invoicing documents (Objects)
Invoices created per year.
Lines per invoicing document (Items)
Average number of lines on the invoice
Subledger Definition
Documents Subledger documents are financial documents that are finally posted in an aggregated form in the general ledger (GL).
(optional) They consist of a header and two different types of lines that represent the document as the business partner sees it and
SUBLEDGER as it is seen by the general ledger. If business partners purchase a book, they might see two lines on the bill, one is the
price of the book and one is the tax. These lines printed on the bill to the customer are the so-called business partner line
items. The vendor might see the book sale from a different view and post the tax on one GL account. The price however
is split into two parts, one to be transferred finally to the publisher, the second one to the author, hence s/he wants to
post them to two different GL accounts.
When a subledger document is balanced usually another subledger document is created for which only the GL items are
replicated.

Subledger documents (Postings)
The number of subledger documents created during a year. They can be uploaded or created during convergent
invoicing. Budget billing plans and down payments create subledger documents as well.
Business partner items per subledger document (BP itm)
The average number of business partner line items per subledger document.
General ledger items per subledger document (GL itm)
The average number of GL items a single document is posted to.
General ledger items per payment (Payments)
As payment documents may result from payment plans and these may incorporate additional fees to be posted to a
different GL account. This changes the number of GL accounts per payment document compared to the original
document and hence the number is requested separately.
Payments per subledger document (P itm)
Usually one open item is closed by one payment. In this case, each subledger document representing an open item
is balanced by one payment document. But if a customer can’t pay and a payment plan is created, a subledger
document may be settled by more then one payment document. The average number of payment documents per
subledger document is asked for.
Percentage pre-paid by credit card (% cre)
Typically online stores require the entry of credit card information before a purchase can be done. This information
is stored in separate tables per subledger document. Only in cases like this it is required to enter the percentage of
subledger documents that have already been paid for by credit card. If on the other hand, the business partner has
agreed that the company withdraws the due amount from her/his credit card account once the invoice is created,
the credit card information is kept in the business partner’s master record. Therefore, in this case the field remains
empty.
Upload of Definition
Subledger This section and hence the parameters are only important, if it is planned to upload subledger documents from an
Documents external source, e.g. a billing system. In a hybrid scenario where the majority of billing documents comes from the
(optional) convergent invoicing and only some are uploaded from a billing system, the values to be entered herein might be
LOAD-INV different from those entered in the previous sections.
Subledger documents (Objects)
The number of subledger documents created during a year. They can be uploaded or created during convergent
invoicing. Budget billing plans and down payments create subledger documents as well.
General ledger items per subledger document (Items)
The average number of GL items a single document is posted to.
.
Payment Run Definition

(mandatory) Sometimes business partners give permission to take the due amount automatically from their bank account or credit
PAY-RUN card. Their open items are closed automatically by the payment run which creates lists to be sent to the house bank and
credit card companies.
Subledger documents (Objects)
Number of subledger documents handled by the payment run.
Note: Objects in highload phase
To account for payment runs during the highload phase do not simply enter the number of open posts to be balanced.
Relevant is the number of all open items in the database, this includes also those open items which are not cleared by the
payment run.
Example
In the payment run those items are balanced that participate in the automatic debiting process. In addition, you have to
include the number of open posts occasioned by individual debiting. This number can be considerably larger than the
number of items to be balanced in general.
Payment Lot Definition

(mandatory)CD-PL A function which enters the bank files of self-payers into the system and creates payment documents that are cleared
against open items or is used in case the business partners send in checks to pay for goods or services received to
balance the open items.
Payments per year (Objects)
Total number of payments to be handled via payment lot.
.
Dunning Definition
(mandatory) Not always business partners pay their open items on time. In this case, a dunning procedure is started, usually a
DUNNING reminder is send to the customer first before other actions like cancellation of service are done. Experience from
customers shows this figure is between 5 and 10% of all documents.
Dunnings notices per year (Objects)
Total amount of overdue items per year is requested here.
Lines per dunning document (Items)
The average number of lines of a dunning document. This may be different from the number of lines of the original
subledger document as a dunning fee may be charged.
.
Deferred Revenues Definition

(mandatory) Once an open position has been created it is immediately due in most cases. In some cases however, this is different, e.g.
DEF-POST if the customers buy a periodical like a monthly magazine with advance payment. In this case they have to pay a certain
amount of money before the shipment starts. Once the company has received the money, they ship them one issue of the
periodical every month. In this case after each shipment a twelfth of the initial amount can be transferred to the general
ledger.
This is done by splitting the original document in partial amounts which are kept in the system as deferred revenues. A
job to be scheduled regularly then transfers these partial payments to the general ledger.
Number of deferred postings per run - CPU sizing - or per year - disk sizing - (Objects)
Average number of postings into which a subledger document is split for deferred revenue postings.
.
Correspondence Definition
Print (mandatory) A correspondence is any letter send to the business partner. This includes bills, invoices, dunning letters and other mail.
CORR-PRINT
Correspondences per year (Objects)
Number of correspondences created per year. In most cases this number is equal to the number of bills generated
plus the number of dunning notices.
.
Back to Top
SAP ERP Human Capital Management
Personnel Definition
Administration & Personnel Administration and Payroll Accounting from the SAP ERP HCM solution includes the following areas: Personnel
Payroll Administration, Benefits, Compensation Management, Recruitment, Personnel Time Management, Incentive Wages,
Accounting Business Trip Management and Payroll Accounting.
PA-USER
Personnel Definition
Planning & Personnel Planning and Development includes the following areas: Organizational Management, Personnel Development,
Development Workforce Planning, Training and Event Management and Room Reservations Planning.
PD-USER
General Remarks Quick Sizer offers templates for different categories of ESS/MSS scenarios
for the ESS/MSS The Quick Sizer does not reflect all existing ESS/MSS solutions as we follow the 80:20 rule. That means: 80 percent of
Scenarios load are caused by 20 percent of the SAP solutions. As a workaround you can try to map your scenarios to the existing
scenarios which are weighted as follows: "small" would mean a complexity corresponding to the "payslip (ESS) / CICO
(MSS)" scenario, "medium" would be equivalent to "CATS (ESS) / CATS Approval (MSS)", and "large" would be
eqvalenuit to "travel (ESS) / Manager Homepage (MSS)". Then, additional scenarios can be sized by using the ESS/MSS
component which corresponds best in complexity.
Note on Portal Sizing
Portal integration is per default included automatically. After calculating the sizing result, there are two lines within the
sizing result: one for ERP and one for NetWeaver. The NetWeaver line contains the portal sizing. On the result level
"Sizing element" you see the result for the individual ESS/MSS sizing elements and the corresponding (automatically
calculated) portal sizing element "NW-EP-ESS" or "NW-EP-MSS".
If ESS/MSS is used without Portal integration, the flag should be unchecked.
Note for usage of Web Dynpro ABAP

All sizings refelct Web Dynpro ABAP scenarios.
Employee Self- Definition ESS

Service (ESS) / A concept that allows employees to access information and perform routine tasks without requiring interaction with
Manager Self- another employee. For example, users can update their bank details or enter a leave request.
Service (MSS)
Definition MSS
A concept that allows managers to access information and perform routine tasks without requiring interaction with
another employee. For example, users can perform a CATS approval.
ESS - Small Specifics for ESS-SMALL Payslip

ESS-SMALL With this sizing element, employees request payslips in the self-service application.
In the "Objects" column, enter how many payslip requests are executed for all users per time period.
In the "Portal" column, per default Portal integration is selected. Uncheck the flag, if Portal intergration is not
used.
Note
Payslip request is a typical small ESS scenario (see “general remarks for the ESS/MSS scenarios”)
Portal integration is per default included automatically. After calculating the sizing result, there are two lines within
the sizing result: one for ERP and one for NetWeaver. The NetWeaver line contains the portal sizing. On the result
level "Sizing element" you see the result for the individual ESS/MSS sizing elements and the corresponding
(automatically calculated) portal sizing element "NW-EP-ESS" or "NW-EP-MSS".
ESS - Medium Specifics for ESS-MEDIUM CATS, Leave Request, Personal Information
ESS-MEDIUM With this sizing element, employees can enter CATS information, enter leave requests, or maintain personal information
in the self-service application.
In the "Objects" column, for exmaple enter how many CATS entries are executed for all users per time period.
used.
Note
CATS, Leave Request, and Personal Information are typical medium ESS scenarios (see “general remarks for the
ESS/MSS scenarios”)
ESS - Large Specifics for ESS-LARGE Travel Expenses

ESS-LARGE With this sizing element, employees enter travel expense information in the self-service application.
In the "Objects" column, enter how many travel expense reports are filled in for all users per time period.
used.
Note
Travel Expenses is a typical large ESS scenario (see “general remarks for the ESS/MSS scenarios”)
MSS - Small Specifics for MSS-SMALL CICO (Clock-in/Clock-out on behalf)

MSS-SMALL With this sizing element, managers can enter clock-in/clock-out data on behalf of their team members in the self-service
application.
In the "Objects" column, enter how many CICO scenarios are executed for all users per time period.
used.
Note
CICO is a typical small MSS scenario (see “general remarks for the ESS/MSS scenarios”)
MSS - Medium Specifics for MSS-MEDIUM CATS Approval

MSS-MEDIUM With this sizing element, managers approve/reject working time data entered by employees in their teams in the self-
service application.
In the "Objects" column, enter how many CATS approval scenarios are executed for all users per time period.
used.
Note
CATS Approval is a typical medium MSS scenario (see “general remarks for the ESS/MSS scenarios”)
MSS - Large Specifics for MSS-LARGE Manager Homepage

MSS-LARGE With this sizing element, managers view the most important data of their team members (assuming 30 team members)
in the self-service application.
In the "Objects" column, enter how many Manager Homepage scenarios are executed for all users per time period.
used.
Note
Manager Homepage is a typical large MSS scenario (see “general remarks for the ESS/MSS scenarios”)
Time Evaluation - Definition

Processed Time Time evaluation is a program which is generated daily to calculate attendance and absence times on the basis of
Pairs attendance and absence data, time types (flextime balance, productive hours) and wage types (bonuses for night,
HCM-PT Sunday and public holiday work). Assumption: Time Evaluation is processed every working day.
Payroll Definition
HCM-PY For payroll you need to enter the number of employees and the number of retro calculations per payroll. A retro
calculation is when a payroll run is repeated for a period for which payroll accounting has already been performed in the
payroll past. Retroactive accounting is triggered during the payroll run for the current period if certain master and time
data affecting the payroll past has been changed in the meantime.
Multiply the average number of retro calculations per employee per payroll times plus 1 times the number of employees:
(number_employees)* (1 + number_retro_calculations).
For example: You have 2 retro calculations per employee, this means a payroll run is executed for 3 periods in total. If
have 100,000 employeed for whom the payroll is done, then you calculate
(100,000) * (1 + 2) = 300,000. Please enter 300,000.
Comment
Financial postings resulting from loan postings have to be treated separately. For the number of employees we assume
that the payroll is executed once a month. Other periods should be scaled through the input data (Example: 50,000
employees should be calculated semi-monthly in 4 hours -> Input: 100,000 employees and 8 hours)
Back to Top
E-Recruiting
SAP E-Recruiting Definition

SAP E-Recruiting has recruitment instruments that help a company find new employees, employ them in positions that
suit their capabilities, and promote their professional development. The application handles almost the entire process
chain, from planning and budgeting, through attracting, hiring, and retaining employees.
General Remarks
SAP E-Recruiting Quick Sizer Scenarios:
Not all SAP E-Recruiting scenarios are reflected in the Quick Sizer as we follow the 80:20 rule. That is, 80 percent
of load is caused by 20 percent of the SAP solutions. Therefore, only the scenarios that are most relevant for sizing
are included.
Validity of Quick Sizer for SAP E-Recruiting:

SAP E-Recruiting Quick Sizer is only valid for ABAP Web Dynpro UI technology, which must be used for all
scenarios. This means that validity is restricted to ECC 6.0 enhancement package 4 and enhancement package 5.
Portal Sizing Not included:

All SAP E-Recruiting scenarios were executed without using Enterprise Portal. If you use portal-based roles for
recruiters, refer to Portal Sizing Guidelines in order to include the portal sizing factor.
Distributed Candidate Scenario:

For candidate and applicant scenarios, it is possible to separate user interaction (frontend server) and database
access (backend server). For such a distributed landscape, CPU and memory have to be computed separately for
the frontend and backend server. A ‘Distributed Candidate Scenario’ checkbox is now available for each of the
candidate and applicant scenarios (Candidate Registration, Application for Job Posting, Job Search). For a
Distributed Candidate scenario, checkboxes for all candidate and applicant scenarios (Candidate Registration,
Application for Job Posting, Job Search) have to be selected. It is not possible to select only part of the candidate
and applicant scenarios. In this case, the user will get an error message. If no Distributed Candidate scenario is
used, all ‘Distributed Candidate Scenario’ checkboxes have to be deselected. This is the default case.
Overview of SAP E-Recruiting Scenarios:

SAP E-Recruiting scenarios that are used for Quick Sizer can be divided into recruiter scenarios and candidate or
applicant scenarios:
Recruiter Scenarios:
• ERC-REQ Creation of Requisition (with Posting and Publication)
• ERC-CA-LST List of Candidate Assignments to Requisition (with Subsequent Processing Steps)
Candidate or Applicant Scenarios:

• ERC-CA-REG Candidate Registration
• ERC-APPL Application for Job Posting
• ERC-JOB-SE Job Search
Creation of Definition
Requisition (with A requisition is an internal document created by recruiters or managers in order to search for suitable candidates for one
Posting and or more positions. A requisition contains – besides the general job information – information on organizational data,
Publication) support team, job requirements, education requirements, as well as attachments for additional information and a list of
ERC-REQ job postings. Vacant jobs for which potential candidates can apply are announced using postings. Job postings are based
on the associated requisition. A job posting can be published in various posting channels and for various periods. Thus
various publications (for example, separated for external and internal candidates) can be created for a job posting.
The current sizing scenario comprises the creation of one requisition with general job information, assignment of three
support team members, various job requirements, and three education requirements. Three attachments and
questionnaires are assigned. One posting is created with two publications (one for internal candidates, one for external
candidates).
To simplify matters, different pieces of information of a requisition are treated in the same way in the current sizing
scenario. In order to determine the sizing of an average requisition, you add the various pieces of information (for
example, number of job requirements, number of education requirements, number of postings) and enter the sum as the
average number of line items. If you are unsure, just use 15 items for an average requisition.
Note that attachments of requisitions are not taken into account for disk sizing as the percentage for these attachments
should be very small compared to the attachments for candidate registrations.
Specifics for this sizing element

Objects
Enter the number of requisitions you expect to be created per peak time.
Items
Enter the average number of items for a requisition. If you are unsure, just enter 15 items per requisition.
List of Candidate Definition

Assignments to List of Candidate Assignments to Requisition is one of the SAP E-Recruiting worklists for recruiters and shows the
Requisition (with candidates (as well as information on those candidates) that are assigned to a requisition. From this list, you can execute
Subsequent other steps in the recruiting process for one or more candidates (for example, invite a candidate to an interview, send an
Processing Steps) interim notification, reject unsuitable candidates).
ERC-CA-LST
The current sizing scenario comprises calling a list of candidate assignments to a requisition as well as 100 subsequent
process steps being executed per worklist call (interim notifications, rejections).
In the current scenario, ‘Number of Sizing Objects Created per Time Unit’ refers to the frequency with which worklists are
called by the recruiter and subsequent processing steps are executed. It is assumed that candidate selection lists can be
seen – from a sizing point of view – as a prototypical worklist. It is further assumed that subsequent processing steps
often are related to only few candidates (for example, invite to an interview) but are from time to time related to the
majority of candidates (for example, rejection) who are assigned to a requisition. In order to determine the number of
sizing objects, consider how many processing steps are executed overall by recruiters during peak time (including mass
processing, for example of rejections). Divide this number by 100 and enter it as the number of sizing objects.

Objects
Enter the number of processing steps (such as send interim notification, rejection) executed by all recruiters
during peak times divided by 100.
Candidate Definition
Registration Candidate registration means that a person who is interested in a work relationship registers in the Talent Warehouse
ERC-CA-REG and stores his or her data there (‘Candidate Profile’). For internal candidates (employees of the company), part of his or
her data is usually already available and can be transferred to Talent Warehouse; external candidates (not belonging to
the company) have to enter all of their data. Candidate data, that is, the candidate profile, comprises personal data,
communication data, information on work experience, education, qualifications, and desired job conditions and work
location. Attachments (such as resumes) can be uploaded by candidates.
The current sizing scenario comprises the registration of an external candidate with the following profile data: personal
data, communication data, information on desired job conditions and work location, information about three different
work experiences, three educations and on various qualifications. Three attachments are also uploaded.
To simplify matters, different pieces of information of a candidate registration are treated in the same way in the current
sizing scenario. In order to determine the sizing of an average candidate registration, you add the various pieces of
information (for example, number of work experiences, number of educations, number of attachments, and so on) and
enter the sum as the average number of line items. If you are unsure, just enter 15 items for an average candidate
registration.
For a Distributed Candidate scenario, the ‘Distributed Candidate Scenario’ (DCS) checkbox has to be selected for all
candidate and applicant scenarios (Candidate Registration, Application for Job Posting, Job Search).
Objects
Enter the number of candidate registrations you expect during peak times.
Items
Enter the average number of line items per candidate registration. If you are unsure, just enter 15.
Attachments
Enter the average number of attachments per object.
Size
Enter the average size of attachments in KB.
Months
Application for Definition

Job Posting An application for a job posting is a candidate´s formal statement of interest in entering a working relationship or
ERC-APPL changing an existing work relationship. An application contains the following data: a letter of application, questionnaires
completed by the applicant, as well as information and documents stored by the candidate in his or her profile in the
Talent Warehouse (see Candidate Registration). Thus candidate profile (such as education, work experience) can be
maintained independent of an application as well as during the course of an application.
The current sizing scenario comprises the application of a registered candidate, which consists of an application letter,
one completed questionnaire, and the display of profile data that has already been maintained. This means that the
maintenance of profile data is not taken into consideration for the sizing of the application.
However, if your standard application scenario also includes the maintenance of all profile data, we recommend you
calculate the sizing as the total for the 'Application' scenario and the ‘Candidate Registration’ scenario.
In the current scenario, the number of sizing objects refers to the number of applications you expect within peak times.
The average number of line items refers to the number of steps executed for an application. If you are unsure, just enter
8 items.
Objects
Enter the number of applications you expect during peak times.
Items
Enter the average number of line items per application. If you are unsure, just enter 8 items.
Job Search Definition

ERC-JOB-SE Persons who are interested in a work relationship (employees or externals) can search for jobs.
In the current scenario, the number of sizing objects refers to the number of searches you expect during peak times.
Objects
Enter the number of searches you expect during peak times.
Back to Top
Logistics Execution
Logistics Definition
Execution Logistics Execution contains Warehouse Management as well as Inbound and Outbound Logistics
LE-USER
Stock Movement Definition

LE-WM The business object transfer order is an instruction to move materials from a source storage bin to a destination storage
bin within a warehouse complex at a specified point in time.
Line items: A transfer order consists of items that contain the quantity of the material to be moved and specifies the
source and destination storage bins.
Delivery Notes & Definition
Goods Issue Number of delivery notes and goods issue.
LE-SHP
Line items: Average number of line items for delivery notes and goods issue.
Back to Top
Product Development & Execution
PM Orders Definition
ALM-USER Orders in the sense of maintenance orders. Requirement to execute a maintenance task on a maintenance object for a
ALM-PM specific deadline. In addition, the maintenance order is a means of documenting maintenance work. In particular,
maintenance orders are used to
- plan maintenance tasks in a targeted manner
- monitor the execution of maintenance tasks
- enter and settle the costs incurred by maintenance tasks
The sub-object of a maintenance order is a component. A maintenance order contains operations that describe the
individual work steps. If greater detail is required, operations can be subdivided into sub-operations. Enter the average
number of components per operation.
Materials Definition
Management Materials Management contains Inventory Management as well as Purchasing.
MM-USER
Materials Definition
Movement Physical or logical movement of materials which leads to a change in material stock levels or results in direct consumption
MM-IM of the material. A goods movement can be a goods receipt, goods issue, or a transfer posting of materials. Please enter
the number of all material movements that originate from any used component within the SAP system (e.g. LE - SHP
Logistics Execution - Shipment)
Line items: A goods movement consists of items containing the quantity and value of the given material. The materials to
be actually placed in or removed from storage can be specified in each item as single units.
Comment
No postings in the previous month. When processing different IDOC-types (e.g. store order), enter any follow-on
documents separately (such as SD order line-items in SD-SLS).
Purchase Order Definition
MM-PUR Request or instruction from a purchasing organization to a vendor (external supplier) or a plant to deliver a certain
quantity of material or to perform certain services.
Line items: A purchase order consists of a number of items, each of which will have a procurement type defined.
Comment
We assume a purchase order has two text lines on average. 30% of the purchase orders are assigned to an account.
10% of the line items have delivery costs. There is one goods receipt line item per purchase order line item. There is one
invoice line item per purchase order line item.
Production Definition
Planning and Production Planning contains Sales & Operations Planning, Master Planning Capacity planning as well as Material
Control Requirements Planning.
PP-USER Production Control deals with Production Orders, KANBAN and Repetitive Manufacturing.
Confirmations Definition
PP-CONF Documents the processing status of operations or sub-operations. A final confirmation is used to determine:
At which work center the operation was carried out
Who performed the operation
Quantities of yield and scrap produced
Size of the standard values required for the operation
Comment
Enter the respective materials movements (goods receipt for the header material and goods movement for the
used components) in the line for MM-IM. This is not counted automatically.
Line items means the number of confirmed operations.This is not the number of material components as in the
sizing element PP-SFC.
The assumptions of the production order in the sizing element PP-SFC apply here, too.
Repetitive Definition
Manufacturing A component in the SAP System for planning and controlling repetitive manufacturing and flow manufacturing.
(Planned Orders)
It enables the period-dependent and quantity-dependent planning of production lines and reduces the work involved in
PP-REM
production control and simplifies backflushing (confirmation, goods receipt posting).
Production Orders Definition
PP-SFC Manufacturing order used for discrete manufacturing. A production order contains operation sequences. An operation
describes how to carry out a work step. By combining operations into operation sequences, you can create parallel or
alternative processes.
The sub-object of a production order is a component: The following graph gives an example of how to determine the
number of components by showing number of components of a multi-level BOM of a product F1.
The finished product F1 contains a semi-finished product F2, which is also an in-house-product. Therefore the production
orders for both products F1 and F2 must be considered for sizing.
The size of the "number of components" is determined by the summation of all individual components on the first
production layer (finished product and semi-finished product, respectively). The components used are either raw
materials, for example F1Cx or F2Cx, or assemblies, such as F2 used in the production of F1. Phantom assemblies (P1
and P2) are only used to structure the bill of materials; they are not produced seperately. The components of the
phantom assemblies (P1Cx or P2Cx) must therefore be added to the components of the next higher level.
Therefore, in this example we can determine the following number of components:
The production orders for the finished product F1 have seven components (F1C1, F1C2, F1C3, P1, P1C1, P1C2, and
F2). The phantom assembly P1 should be counted as a real component.
The production orders for the assembly F2 have six components (F2C1, F2C2, P2, P2C1, P2C2, and P2C3).
Note
The columns for the display of objects and the changes of objects should be filled, too. If, for example, you create
a production order in one transaction and release it afterwards, please enter "100" for "object changes" because
every order (i.e., 100% of the orders) is changed by being released. If you display the production order, then you
must fill in the field for object display.
Confirmations to a production order must be entered at the sizing element PP-CONF.
Order settlements are not considered and have to be considered by CO.
Comment
We assume:
10 status items per production order
3 status items per component
1 sequence for every 10 componentsr
1 operation for every 5 components
3 status items per operation
Project System Definition

PS-USER Projects: A complex structure of tasks within a controlling area which is used to control and monitor the schedule,
PS resources, capacities, cost, revenues, and funds availability.
Specifics for PS
WBS-Elements:
An individual structural element in the work breakdown structure (WBS) representing the hierarchical organization
of a project. It describes either a concrete task or a partial one that can be further subdivided.
Networks:
A network contains instructions on how to carry out activities in a specific way, in a specific order and in a specific
time period.
Activities:
Average number of activities per network.
An activity is a task in a network which has a defined start and finish. An activity can be broken down into activity
elements.
There are three categories of activities in the Project System:
- internal activities
- external activities
- general costs activities
Due to the nature of project plans the procedure for entering data is slightly different from that in other components.
Each year, usually only a few projects with many WBS elements are created. In contrast to other objects, such as FI
documents projects are changed frequently, sometimes several times per day. This aspect of Project System is addressed
in the Quick Sizer as follows
For average load
Enter the projects created per year, the average number of WBS elements per project and the residence period as
usual
Enter the average number of networks per project
Enter the average number of activities per network
Enter the average number of changes and average number of display per project (during its total lifetime)
For peak load
In the highload phase, for example at the end of the month when the projects statuses must be updated, enter the
number of objects that are created, displayed, and changed on that particularly busy day. To determine peak CPU
consumption, enter data that reflects the actions of a very busy day. Do not enter data that reflects a typical day -
this is automatically considered.
The way of entering data for peak load for projects is a little bit different from other sizing objects. The number of
new projects, the number of changes and displays are just added and the sum is entered in the field "Objects".
Average numbers of WBS, networks, and activities are entered as for the average load.
The fields "Changes" and "Display" stay empty.
For example:
Every year, 150 projects are created with an average of 500 WBS elements. They remain in the database for about five
years. On the average, each project consists of 20 networks and 100 activities per network. The estimation of the total
number of changes and displays per project bases on the assumption that a project is changed three times and displayed
once per working day over a period of 2 years. In a high load phase, 300 projects are changed five times and displayed
once during a day. Additionally, on these very busy days, 10 projects are created. The sum of the number of new
projects, changes, and displays is:
10 + 300*5 + 300*1 = 1.810

You enter the following data in the Quick Sizer:
Average load:
Number of objects per year: 150
Avg. no. of WBS elements: 500
Avg. no. of networks: 20
Avg. no. of activities/network: 100
Residence period in months: 60
Number of changes per project: 1.200 (3 changes / working day * 200 working days / year * 2 years)
Number of displays per project: 400 (1 display / working day * 200 working days / year * 2 years)
Peak load:
Number of objects during peak load: 1.810
Avg. no. of WBS elements: 500
Avg. no. of networks: 20
Avg. no. of activities/network: 100
Number of changes (total): no input
Number of displays (total): no input
Time period: 08:00 - 16:00
Comment
For calculation we assume:
Five status items per project
Five distribution rules per project
Three status items per WBS element
Three distribution items per WBS element
Three allocations per WBS element
Inspections in Definition
Quality Tasks for determining the actual status of a technical system (for example, a machine) or a material.
Management
Inspection Characteristics: The basis on which an inspection is performed.
QM-USER
QM-IM Comment
We assume that one inspection with several inspection characteristics is carried out per inspection lot. On average, there
is one single value recording per inspection characteristic.
Material Definition
Requirements Material Requirements Planning (MRP)
Planning Generic term for procedures in materials planning which take into account and plan every future requirement during the
MRP RUN creation of order proposals (independent requirements, dependent requirements, and so on).
Net Change Planning
Materials planning run where only those materials are planned which have undergone a change relevant to materials
planning since the last planning run.
Specifics for MRP
Planned orders per day
A planned order (PP-SOP) is a request created in the planning run for a plant to trigger the internal procurement of
a plant material for a certain quantity for a specific date. Enter the number of planned orders that are added per
day. The Quick Sizer automatically determines the total number of planned orders for the planning run (number of
planned orders per day * planning horizon in days).
Components/Bill of Material (BOM): Average number of components per BOM
see PP-SFC
Reorder items: Purchase requisitions for reorder-point driven materials
Special procedure in materials planning. If the reorder point is greater than warehouse stock, an order proposal is
created by materials planning. For this type of procurement multiple requests are summed up to build one
procurement request. This is the lean version of external procurement.
Non-reorder items: Purchase requisitions or schedule line items for non-reorder-point driven materials
For this type of procurement each individual request leads to a purchase requisition or a schedule line item. This is
the more demanding version of external procurement.
Planning horizon in days: Length of planning horizon in days
The planning horizon is the period which is used when the MRP planning mode "net change planning in the planning
horizon" is used. For this type of net change planning only those materials are planned in the planning run which
have a change related to materials planning within the period (in work days). The length of the planning horizon
should at least include the following: Period in which customer orders are being created, delivery times and
complete material processing time.
% BOM changes per day: Number of BOM structure changes per day in %
Each change of a BOM invalidates the planning data and requires a new calculation of all planned orders which are
based on this BOM. Enter the average number of BOMs which are changed per day.
% dependencies: % of BOM components with object dependencies (average)
When variant configuration is used the explosion of the BOM is a more complex process. The Quick Sizer assumes a
model of small or medium complexity of the underlying variant configuration and takes into account additional
resource requirements. If the customer's model of variant configuration lies within this small to medium category,
the average number of components (%) with object dependencies can be entered directly. If the customer's model
of variant configuration is very complex, the input can be multiplied by an additional factor which takes into
consideration extra resources.
For example:
If 10 % of the BOM components have object dependencies and the model is three times more complex enter 30 %
in this field.
% LTS: Number of orders with Lead Time Scheduling in %
Lead Time Scheduling calculates the exact production dates and creates capacity requirements by using the routing
information.
Comment
We assume the following:
The MRP run is conducted every day with the processing key "Net change" and planning mode "Adapt planning
data".
The number of components implicitely determines the scope of the routing. With an increasing number of
components, the number of operations in the routing rise.
The runtime and CPU consumption directly depend on the number of reservations in the system.
The MRP run can be parallized without end, dependencies on data constellation are not considered.
The MRP sizing of the Quicksizer only gives CPU numbers. Diskspace is not calculated, because the MRP run works
more or less on a steady state concerning the disk space. This means that the planning data created by the MRP
run is deleted when the corresponding production orders and purchase orders are created.
Back to Top
Sales & Service
Customer Service Definition

CS-USER Application component that can be used to process services. Customer Service mainly comprises the following functions:
CS-AG Structuring and management of technical objects for which services are to be performed (for example, technical
systems, machines)
Management of data regarding warranties and business partners
Creation of service requests
Planning and execution of the requested services
Billing of the costs that arise as a result of the services
Monitoring of call processing to ensure dates and agreed response times
Components:
The sub-object of an order is a component. In an order, components are usually materials assigned to an operation. Enter
the average number of components per order.
Comment
We assume that one operation is valid for five components.
Incentive and Definition

Commission Incentive and Commission Management delivers the capability to define various commission plans and render payment
Management ICM through the SAP payroll solution, thus rounding out the compensation solution. Please note that Sizing measurements are
based on the standard table widths of ICM.
ICM Case Specifics for ICM Case Processing

Processing Number of commission cases
ICM-CASE This is the number of cases multiplied by the number of processing steps. A processing step is each change made
to the case, such as create, change, reset, reactivate or mass postprocessing (for pending cases etc.) as well as
additional commission cases (Bonuses and target agreements etc.). A common approach to improve the sizing
result is to reduce the number of commission cases prior to posting. This is usually done by the operational system
(s) by condensing according to the business restrictions.
Remunerations per commission case

These are the remunerations a document creates. In general this is the number of (direct and indirect) recipients
per commission case.
Number of months the data remains in the database

How many months do the documents remain in the system on average before they are archived? Documents can
only be completely archived if all due line items have been cleared. Reversed documents can always be archived.
You can archive individual case versions for the commission case. "Old" case versions that are not valid can be
archived immediately. There are further restrictions for all other versions.
ICM Document Specifics for ICM Document Posting

Posting Number of documents
ICM-DOC Number of documents that are directly imported from the operational system(s) to ICM without using the
commission case process.
Remunerations per document

These are the remunerations a document creates. In general this is the number of (direct and indirect) recipients
per document.
Number of months the data remains in the database

How many months do the documents remain in the system on average before they are archived? Documents can
only be completely archived if all due line items have been cleared. Reversed documents can always be archived.
"Old" case versions that are not valid can be archived immediately. There are further restrictions for all other
versions.
ICM Settlement Specifics for ICM Settlement

ICM-SET Number of settlement items
Every commission created directly by the commission case or via document posting as well as each settlement
scheduling line item has to be summed up here. The settlement scheduling run uses compression based on certain
criteria such as same due date, same business partner etc… This may reduce the number of due line items created
by settlement scheduling. Each participant will receive at least one settlement item per case.
Number of commission contracts

Number of commission contracts which have to be settled. The contracts using settlement scheduling also have to
be included here.
Sales & Definition

Distribution Sales & Distribution contains Sales and Billing as well as Shipping.
SD-USER
Customer Definition
Inquiries A customer request to the company for a quotation or sales information that is not binding. The request can refer to
SD-CUST materials or services, conditions and, if necessary, delivery deadlines. It is accepted by the sales area that is then
responsible for any further processing.
A customer request comprises one or several items containing the required quantity of a material/service.
Line items: Number of line items per customer inquiry
Invoices Definition
SD-BIL Sales and distribution document used to charge a customer for a delivery of goods or for services rendered.
Line items: Number of line items per invoice.
Sales Data and Definition
IDocs Number of Sales Data and IDocs created per year. The Quick Sizer assumes that for every Idoc, one material document
SD-POS and one billing document are generated with subsequent postings to FI. The IDocs themselves are assumed to be
archived immediately.
The column "number of objects created per year" refers to the number of documents created per year. The next column
"number of subobjects....." refers to the number of line items per document.
The Quick Sizer considers aggregated upload (WPUUMS). In the case of WPUBON, you will have to consider the following:
1. Number of POS transactions. This corresponds to the number of customers per store.
2. Number of items per transaction. This corresponds to the number of articles purchased by each customer.
The total number of line items is the product of number of customers and the number of articles per customers.
Example: You have 500 stores with an average of 300 customers per day and an average of three articles per
customers. Assuming one IDoc per store this will give you:
500 IDocs, each with 900 lines per day. Assuming 300 working days
Number of objects created per year = 300 x 500 = 150000,
Number of sub objects = 900
Residence period is actually that of the follow-on documents - material-, billing- and financial-documents.
Comment
Number of Sales Data and Idocs created per year. The System creates one goods issue and one bill per document/IDOC
including the respective number of line items.
With each bill and material movement, one FI document with the respective number of line item is created. Additional
postings are not considered.
When processing different IDOC-types (e.g. store order), enter any follow-on documents separately (such as SD order
line-items in SD-SLS).
In the following graph you can see the factors that influence sizing.
Sales Orders Definition
SD-SLS A customer request to the company for delivery of goods or services at a certain time.
Back to Top
Corporate Services
Travel Receipts Definition

TV-RECEIPT Enter the number of receipts from business trips. These can be
Travel costs
Lunch expenses
Hotel costs
Line items are the average number of line items per receipt, for example travel costs, meals, or accommodations.
Back to Top
SAP Supply Chain Management
User in SCM
In SCM, load created by users is added to the throughput sizing. This is a different procedure from standard user sizing.
Back to Top
Demand Planning
Demand Planning
Sizing assumptions and principles
DP USER
The hardware sizing for SAP APO estimates the following three hardware components:
1) Live Cache server
2) Database server
3) Application server
liveCache is a memory-based Database and therefore the appropriate estimation of the memory requirement is very
important.
The SAP APO Demand planning application stores the historical data in NetWeaver BW InfoCubes. These are described as
user designed relational databases, composed of one large table of input and output values, called a Fact Table, and
several smaller tables that contain characteristics describing the data. These are called dimension tables. InfoCube data
are stored in tables on the disk, not in the Live Cache.
For performance reason the historical data is copied from NetWeaver BW InfoCube to liveCache. Since Demand Planning
uses Live Cache, the Live Cache size is increased due to the historic and planning result time series data in it. Instead of
storing the data in Star Scheme format (Fact and Dimension table combination) of the InfoCube, Live Cache stores the
data in a time series for a particular key figure and characteristic combination.
Characteristics are attributes that describe what is planned. Examples include item code, UPC, brand name, market
segment, location and customer name. Key figures hold the data input and output quantities that are stored in a single
fact table for each InfoCube. Examples include sales history, demand forecast and percent promotion increase.
Characteristics and key figures cannot be interchanged. In addition, characteristics can be bundled into groups, called
dimensions. For example, item name, UPC, brand name, and market segment can be bundled into a single dimension
called product. The number of info objects and dimensions and the number of unique values for each info object are used
to determine the required data storage needed for the APO Demand Planning system.
The characteristic combinations, key figures, and time horizon are the variables, which influence the scalability of
Demand Planning. The characteristic combination is the most dynamic variable, which has the range from a few hundred
thousands to several millions. Tests showed that the runtime of the DP planning jobs is acted in a linear form with the
increasing of the characteristic combination. In other words, the throughput (number of characteristic combinations be
planned per hour) scales with the size of the hardware.
Compression of The Time Series data stored in liveCache may be compressed. This compression technique is very simple and it should
Timeseries be understood that a Time Series is either compressed or it is not. There is no partial compression. The only parts of
the Time Series that is compressed are the empty time buckets. If less than 30% of the time buckets in a Time Series
are loaded with data, then the empty time buckets are compressed. Nothing is done to the time buckets that have data
in them. If more than 30% of the time buckets in a Time Series are loaded with data, the empty time buckets remain
uncompressed and are loaded with zeros. As data is loaded, time buckets are filled for a specific characteristic
combination key figure in a Time Series. Time Series compression is dynamic, i.e. when a Time Series is filled to greater
than 30%, SAP software un-compresses the empty time buckets. Likewise, if data is deleted from the Time Series and
usage falls below 30%, the Time Series is again compressed. For all practical purposes, there is no memory consumed
by empty time buckets for a Time Series when compressed. However, memory is consumed when the Time Series is
expanded even with the time buckets filled with zeros. For a characteristic combination key figure Time Series, data
resides in real memory until LiveCache is cleared. When compressing a characteristic combination key figure Time
Series, SAP software builds a structure representing the compressed data. This structure consists of the position of the
time bucket data for a characteristic combination key figure in a Time Series, and the data for that time bucket. There
are no entries in the structure for time buckets that have zero data. Currently, all characteristic combination key figures
for a Time Series and for a Planning area have the same number of time buckets.
Sizing Elements Mainly we size the memory requirements of the timeseries stored in liveCache. The CPU sizing is determined by the
batch planning run which calculates the forecast.
APO - Planning Specifics for the Planning Area Sizing - SAP liveCache Memory
Area Sizing - SAP
The total number of characteristic combinations is the number of values of each combination multiplied. For
liveCache Memory
example, a company plans 800 products across 12 plants to serve 20 customer locations. Then the number of
TIMESERIES
characteristic combinations would be 800*12*20 = 19,200. But usually not all products are available in all plants
and all customer locations. Instead the average number of products in each location has to be estimated, e.g. in
average 100 products are located in plants and in average 2 customer locations are delivered by one plant. Then
the total number of characteristic combinations would be 100*12*2= 2,400.
Total number of key figures is the sum of the key figures used in planning.
Total number of periods is a count of time buckets used in planning. The more time buckets, the more memory
space in liveCache are required to store data. For example, a DP planner may define an annual forecast in weekly
time buckets. Hence, the number of time buckets is 52. Alternatively, the planner may define the annual forecast
horizon as 12 weeks followed by 8 months. In that case, the number of time buckets would be 12+8*4 = 42,
because all data is stored in the smallest time unit.
Compression index
Either a 'Compression index' can be specified or the number of compressed time series (in percent) and the
number of periods can be specified in the compressed time series. A compression index of 0 means that all time
series are not stored in compressed form and the maximum main memory requirement is calculated. A
compression index of 9 means that 90% of the time series are stored in a compressed way. A compression index
of 5 is preset. This corresponds to a compression rate which we have observed with many
customers.
Note
Fill-in either values for the compression index or values for the following two fields.
Percentage of compressed timeseries: In a productive environment you can determine the percentage of
compressed timeseries with help of the report /SAPAPO/OM_TS_FILLRATE (see note 537210). If you can’t
determine this number than please use the compression index.
Number of time buckets in compressed timeseries: If the percentage of compressed time series and the
number of periods in the compressed time series is known, these values can be entered in the fields provided (see
note 537210).
Total number of planning versions stored in liveCache. The calculation for liveCache memory requirements
assumes that each version contains the same amount of data per version.
APO - Planning Specifics for the Planning Run Sizing - CPU

Run Sizing - CPU
Characteristic combinations relevant for planning run. A planning run can generate a forecast at any
DP RUN
aggregation level in the hierarchy. If the forecast is generated at the lowest aggregation level (typically
Item/Location) then all of the characteristic combinations are relevant for planning. Alternatively, if the planning
run is generated at higher level, then only a percentage of the characteristic combinations is used to generate a
plan. So, the amount of CPU processing time is reduced in direct linear proportion to the percentage of
characteristic combinations used to generate a forecast. The totals can be disaggregated to lower levels in the
planning book, or summed up to a higher level in the hierarchy. For example, if a planner generates forecasted
demand for a region, then the system does not plan forecasts for all of the different sales channels, product
families, brands, products, and customers in that region. Those values are calculated in the planning book when
displaying those characteristic combinations, and are based on the results of the forecast at the region.
Periods for planning run is a count of time buckets used in planning. CPU process time increases as the time
bucket count grows.
The duration of planning run time frame is determined by a Company's planning and operating requirements.
The shorter the required time frame, the more CPU processing power is required to complete the planning run. The
impact required for CPU processing power versus process time is in reverse linear proportion.
Back to Top
Production Planning and Supply Network Planning
Production
Sizing assumptions and principles
Planning and
Supply Network
The hardware sizing for SAP APO estimates the following three hardware components:
Planing
PP USER 1. Live Cache server
SNP USER
2. Database server
3. Application server
The Task of Supply Network Planning is to identify sources for supply for finished products. It plans and considers safety
stock levels in any location and distributes production over plants. Additionally it chooses production resources in plants
and explodes bill of materials in plants. The outputs are purchase requisitions, stock transport purchase requisitions and
planned production orders. We consider SNP heuristic to estimate the CPU requirements. The SNP heuristic usually runs
in background.
Mainly we size the memory requirements of the orders in liveCache. The CPU sizing is determined by the SNP heuristic
Sizing Elements
planning run. If more than one version is used then we recommend to input the data for each version separately and add
a comment which describes the version. You can easily add new input lines for each version.
APO - Master Data Specifics for Master Data - SAP liveCache Memory
- SAP liveCache
The number of location-product combinations can be determined by one of two ways. If all products can be
Memory
stored in all locations, then multiply the number of products by the number of modeled locations. Alternatively, if
MASTERDATA
selected products are stored at each facility, then sum up the number of products modeled at each location. For
example, each customer location may store only finished goods, while each distribution center stores both finished
goods, and components, and each plant produces and stores only a portion of the finished goods and components.
Total numbers of resources i.e. work center, production lines, and tools to be planned in APO.
Resources used in APO can define work centers, or production lines and tools used in the manufacturing of
products. Determine the number of resources used in APO planning for both Supply Network Planning and Detailed
Scheduling.
Specifics for Warehouse Stocks - SAP liveCache Memory

APO - Warehouse
Stocks - SAP The number of warehouse stocks is a count of the detailed stock locations used in planning. For each facility,
liveCache Memory you have to decide whether sub locations will be included in the planning process. These can be as detailed as
STOCK shelf and bin locations in a warehouse. Also, batches can be separated in product planning. If either the sub
location or the batch value is not used for planning then that category is set to 1. Multiply the number of sub
locations by the number of batches for each facility. Sum up the totals for the facilities used in active model. If sub
locations and batches are not used in planning, the total value is the number of facilities in the active model.
APO - Planned Specifics for Planned Orders - SAP liveCache Memory

Orders - SAP
The average number of planning relevant planned orders / manufacturing orders refers to all production
liveCache Memory
orders that are planned and scheduled. The larger the number, the greater the Live Cache memory requirements.
PLANNEDORD
Orders that are used in more than planning version have to be entered for each of its planning versions. Also,
orders that are confirmed by the backend system are no longer in the APO system. So, the number of planned and
released production orders in APO may be smaller than the number of production orders in R/3.
The average number of components per manufacturing order asks for a count of the bill of material
components included in each production process model.
The average number of operation steps per manufacturing order asks for the average number of operations
per Production Process Model.
The average number or operations steps per operation. Each operation is composed of operation steps
(activities). Activities include setup, tear down, production, and queue. Determine the average number of activities
per operation used in APO planning.
The average number of alternative resources per activity can be one or more, depending on the number of
resources that can perform the same activity used to produce a product. (A resource can be a production line, a
work center or any other manufacturing facility.)
Determine the average number of parallel capacity requirements per operation step (activity). This can
be one or more constraining resource in an operation. For example, this can be a work center and a specific tool or
person, all required performing a specific operation step.
APO - Sales and Specifics for Sales and Purchase Orders - SAP liveCache Memory
Purchase Orders -
The average number of forecast orders used for planning asks for the number of location-product
SAP liveCache
combinations, with a forecast that is released from Demand Planning to Supply Network Planning. Each location-
Memory
product combination is considered one forecast order.
FORECAST
The average number of schedule lines per forecast order refers to the number of partitions made for each
time bucket in Demand Planning. So, if the forecasts from Demand Planning are in monthly time buckets, and SNP
plans in daily time buckets, then the average number of scheduled lines per monthly forecast is 30.
The average number of planning relevant purchase orders or purchase requisitions. The number of
planning relevant purchase orders include only those purchase orders that are not yet filled. Those that are will be
PURCHORD deleted from liveCache. However, until payment is completed, they will still reside in R/3. For this reason, more
purchase orders often reside in the backend system than in APO.
The average number of delivery schedules per purchase order or purchase requisition asks for the
number of transports required for the average purchase order.
The average number of sales orders used for planning. Those orders that are satisfied are not relevant for
SALES planning, because they are deleted from liveCache. However, they still reside in R/3, until payment for the sale is
fulfilled. So, there are typically more sales orders in the backend system than in APO.
The average number of delivery schedules per sales order. Determine how many transports, on average,
are required for a sales order.
Average number of transfer orders used in planning. These are internal stock transfers generated by the
TRANSFER APO SNP planning process. This number is typically a count of vehicles generated from a Transportation Load
Builder (TLB) planning run.
Average number of products per transfer order asks for a count of products that are grouped into a transfer
order from a TLB planning run.
APO - Planning Specifics for the Planning Run Sizing - CPU

Run Sizing - CPU
SNP heuristic: Number of stock keeping units - for example location products - planned by one
SNP HEUR
heuristic planning run asks for the number of location-products planned in one planning run.
Duration of a SNP heuristic planning run is the time needed to plan for the entire time horizon during nightly
batch processing. The smaller this time (in hours), the more CPU processing capacity is required.
Back to Top
Order Fulfillment
Order Fulfillment Sizing assumptions and principles

Increasingly, companies operating worldwide are forced to globalize available information in order to conduct business
efficiently. Specifically, this means that information has to be made available across system boundaries as quickly as
possible to provide optimized decision support. Global ATP can be used in heterogeneous system landscapes to provide
required information as quickly as possible. The ATP check – also known as the availability check – represents an online
search that should ensure that your company can provide the requested product at the requested time in the quantity
requested by the customer.
Sizing Elements We size the memory requirements of the ATP time series in liveCache. The CPU sizing is determined by the different ATP
checks.
Specifics for the Location Products

APO - Location
Products Master Data: We ask for the number of locations for which an ATP check is possible.
ATP-MD
Specifics for the Available-to-Promise Checks - CPU

APO - Available-
to-Promise ATP simple
Checks - CPU The ATP check – also known as the availability check – represents an online search that should ensure that your
ATP-SIMPLE company can provide the requested product at the requested time in the quantity requested by the customer.
The simple ATP check is carried out based on the ATP quantity (Available-To-Promise). The ATP quantity is
calculated from stock, planned receipts (production orders, purchase orders, planned orders and so on), and
planned requirements (sales orders, deliveries, reservations and so on).
ATP-RULE Rule-based ATP-requests

This check is an iterative process, every check defines the next check according to the rules in the system.
Example
Rule I
Search for an alternative location. If none is found,
search for an alternative requirements method.
Rule II
Search for an alternative product. If none is found,
Search for an alternative product in an alternative location. If none is found,
Search for an alternative requirements method.
CTP ATP requests
ATP-CTP Number of Capable-to-Promise (CTP) checks. If a required product is not available in the required quantities, in
Production Planning and Detailed Scheduling, you can create planned orders or purchase requisitions for the
missing products with the help of CTP
Back to Top
Service Parts Management
Service Parts Defintion

Management Service Parts Planning delivers integrated planning capabilities to the service parts supply chain. While it considers the
specific aspects of the after-market and provides extended capabilities for handling the large parts volumes present in an
after-market supply chain, it also delivers a tight integration of the end-to-end planning process with areas, such as
Supply Network Collaboration, Procurement, Warehousing, and Order Fulfillment.
Service Parts Planning enables the service parts network to forecast parts demand, derive optimal stocking levels for
each location, plan parts replenishment, and distributes the parts within the network. Service Parts Planning addresses
specific needs such as slow- and fast-moving parts demand forecasting, parts life cycle planning, interchangeability /
supersession of parts, and inventory planning for multiple hierarchies.
Planning logic in various areas of Service Parts Planning can be applied based on triggers. With triggers, recalculation can
happen focused to products that need a recalculation, e.g.: parts distribution can be triggered after a goods receipt.
Planning processing in Service Parts Planning can also be done for partial product volumes, e.g.: fast moving parts with
weekly planning and slow moving parts with monthly planning.
Service Parts Specifics for Service Parts Planning

Planning This section covers the SPP processes Stocking/Destocking, EOQ/Safetystock and Deployment.
SPP-STK,
In addition, the following processes are part of the SPP solution:
SPP-EOQ,
SPP-DPLY Demand Realignment
Is not considered for quicksizing as it processes data volumes caused by changes to the supply chain. However,
time in the batch schedule must be allocated.
Demand Capture
Is not considered for quicksizing. However, time in the batch schedule must be allocated.
Enter in column "SKUs" for
Stocking/destocking (SPP-STK): all possible location products
For stocking, a trigger based process can be used. For a trigger driven stocking process the numbers of
location products triggered is used for “SKUs”.
For destocking, “SKUs” equals the stocked location products in the network.
Economic order quantity (SPP-EOQ): all stocked location products
Deployment (SPP-DPLY): all stocked location products
For deployment a trigger based process can be used. For a trigger driven stocking process the numbers of
location products triggered is used for “SKUs”.
Specifics for Service Parts Planning - Period Based Planning

Service Parts
Planning - Period Enter in column "SKUs" for both sizing elements all location products along the bill of distribution.
Based Planning Enter in column "Time buckets" for
SPP-FCST Forecasting (SPP-FCST): historical & planning horizon in monthly or weekly buckets
For recalculation of forecasts in the past a second entry SPP-FCST can be used. In “Time
buckets” then enter number of periods in the past times number of periods in planning
horizon. A trigger based process is available.
Specifics for Service Parts Planning - DRP

Service Parts
Planning - DRP This section covers the SPP process DRP.
SPP-DRP
Enter the following information
Matrices
Total number of matrices calculated by DRP. If a location has a virtual child location, then two matrices are
processed.
ROP Stk. M.
Number of Reorder-Point based matrices which are stocked (available from SCM 5.1)
PB Stk. M.
Number of Period-Based based matrices which are stocked
Loc.
Average number of locations in a the BoD-subtree below an entry location including the entry location. If a location
has a virtual child location, then it needs to be counted twice.
PoD 1
Periods of Demand / EOQ days on entry location (comment: "Periods of Demand" and "EOQ days" are synonyms).
Enter 1 if no rounding to Periods of Demand / EOQ days is applied.
PoD 2
Periods of Demand / EOQ days on non-entry location (comment: "Periods of Demand" and "EOQ days" are
synonyms).
Enter 1 if no rounding to Periods of Demand / EOQ days is applied.
Hor.1
Freeze horizon in working days
Hor.2
In the Stability Rule for Limited Freeze Horizon (Expedite) it can be defined that a maximum for the planning
horizon in case of the Net Demand Calculation and the Order Scheduling is used.
If this maximum is used, the limited freeze horizon in working days plus the buffer defined in the stability rule
needs to be entered in the Quick Sizer. If this maximum isn’t used a value of 0 needs to be entered in the Quick
Sizer field. To define this maximum is possible from SCM 7.0 SP 5.
Hor.3
Plan submission horizon in working days
Hor.4
Planning horizon in working days
Stab.
Usage of stability rules
STR
Saving of Stock Transport Requisistions
Additional information
For DRP a trigger based process is available. When triggers are used please consider that DRP always calculates the
whole BoD subtree below an entry location (one trigger can impact the calculation of multiple location products).
Example assumptions:
Service Parts
Planning - Assume you have five locations (one global distribution center and four regional distribution centers) and in total
Example 100,000 different products. The global distribution center stores all 100,000 products, each regional center stores
50,000 products.
In total we have 100,000 + 4*50,000 = 300,000 SKUs

All possible SKUs are 100,000 * 5 = 500,000
Enter following values in the corresponding fields on the Quick Sizer questionnaire:
Stocking/destocking (SPP-STK): 500,000 SKUs
Economic order quantity (SPP-EOQ), deployment (SPP-DPLY): 300,000 (all stored SKUs)
Forecasting (SPP-FCST):
SKUs: 300,000 (all stored SKUs)
Assume a historical horizon of two years in monthly buckets, 24 buckets and a planning
horizon of two years in monthly buckets, 24 buckets, so we have in total 48 buckets.
Back to Top
Integration to ECC
Sizing Elements The CPU sizing is determined by the load generated by the integration. Only the SCM system is considered in the sizing
result.
APO - Orders Specifics for Orders replicated to/from ECC

replicated Manufacturing orders: This refers to the number of production orders transferred from/to the ECC system. The
to/from ECC - number of line items refers to the average number of components in the production order.
CPU Sales orders: This refers to the number of sales orders transferred from/to the ECC system. The number of line
PI-PROD items refers to the average number of schedule lines in the sales orders.
Purchase orders: This refers to the number of purchase orders or purchase requisitions transferred from/to the
PI-SALES ECC system. The number of line items refers to the average number of schedule lines in the purchase order.
Stock movements: This refers to the number of stock movements transferred from/to the ECC system. The
PI-PURCH number of line items is always 1. Enter 1 in the column for line items.
PI-STOCK
Back to Top
SAP Extended Warehouse Management
Extended Definition
Warehouse Extended Warehouse Management (EWM) offers you flexible, automated support for processing various goods movements
Management and for managing stocks in your warehouse complex. The system supports planned and efficient processing of all logistics
(EWM) processes in your warehouse.
If you manage your warehouse stocks using the application component Inventory Management (MM-IM), then you
manage the material stocks based on quantity and value in several storage locations.
In contrast, EWM gives you the option of mapping your entire warehouse complex in detail in the system, down to
storage bin level. Not only do you gain an overview of the entire quantity of a material in the warehouse, you can also
always determine exactly where a certain material currently is in your warehouse complex. With EWM, you can optimize
the use of various storage bins and stock movements, and can store together material stocks from several plants in
random storage areas. Using EWM, you can control and optimize various processes in the warehouse.
EWM is completely integrated into Inventory Management and Delivery Processing. Business processes, which you trigger
in other application components, lead to physical goods movements in your warehouse. You organize, control, and
monitor these goods movements using EWM.
Note
In the Quick Sizer we distinguish between inbound and outbound delivery processes.
For good response times choose CPUs with a good single-thread performance.
Back to Top
SAP Extended Warehouse Management - Inbound
EWM Inbound The inbound delivery process consists of several steps:

Delivery Process Creation of inbound delivery (IEWM-DLV)
Optional: Creation and confirmation of unloading warehouse tasks (IEWM-UNTSK, IEWM-CONF)
Creation of putaway warehouse tasks (without preceding unloading task; IEWM-PATSK)
Confirmation of putaway warehouse tasks (IEWM-PACON)
Optional: Change of resource in putaway (IEWM-RESPA)
Optional: Deconsolidation ((un)packing and creation of follow-up move warehouse task for putaway; IEWM-
DECON)
Optional: Move warehouse task (from deconsolidation station to final bin; IEWM-MOVE)
Optional: Change of resource in movement from deconsolidation packing to final bin (IEWM-RESFI)
EWM - Mandatory Specifics

Inbound Step - Objects: Number of delivery documents
Creation of Items: Average number of items per delivery
Inbound Delivery
IEWM-DLV
EWM - Optional Specifics

Inbound Steps - Wareh. Tasks: Number of unloading warehouse tasks
Creation and
Confirmation Assumption: 100% RF
of Unloading
Warehouse Tasks
IEWM-UNTSK,
IEWM-CONF

Inbound Step - Wareh. Tasks: Number of putaway warehouse tasks without preceding unloading warehouse task
Creation of
Putaway
Warehouse Tasks
(Without
Preceding
Unloading Task)
IEWM-PATSK

Inbound Step - Wareh. Tasks: Number of putaway warehouse tasks
Confirmation of % RF: Percentage of radio frequency based putaway confirmation
Putaway
Warehouse Tasks
IEWM-PACON

Inbound Step - Wareh. Tasks: Number of warehouse tasks with resource changes
Change of RsChg: Average number of resource changes per warehouse task
Resource in
Putaway Assumption: 100% RF
IEWM-RESPA

Inbound Step - HUs: Number of highest-level handling units (HUs) after deconsolidation
Deconsolidation Items: Average number of putaway items packed per highest-level HU
((Un)Packing and Unpack. items: Number of unpacked items
Creation of
Follow-Up Move
Warehouse Task
for Putaway)
IEWM-DECON

Inbound Step - Wareh. Tasks: Number of warehouse tasks
Move Warehouse
Task (from Assumption: 100% RF
Deconsolidation
Station to Final
Bin)
IEWM-MOVE

Inbound Step - Wareh. Tasks: Number of warehouse tasks with resource changes
Resource in
Movement from Assumption: 100% RF
Deconsolidation
Packing to Final
Bin
IEWM-RESFI
EWM - Inbound Find this example to see how the fields could be filled-in.
Delivery Process
During the peak hour the following process steps are executed in the system:
Example
100 inbound deliveries with four items on average are created based on messages received from ERP. Each item is
packed in two highest-level HUs.
Enter for sizing element IEWM-DLV: objects = 100 deliveries , items = 4 items per delivery
50% make use of system based unloading with unloading warehouse tasks for the highest-level HUs.
Enter for sizing elements IEWM-UNTSK and IEWM-CONF: wareh. tasks = 400 (50% * 100 * 4 * 2)
For each received HU a (first) warehouse task is processed, either to deconsolidation station or for direct putaway
(in case the reveived HUs are applicable for storage). Bundling of these warehouse tasks is always a single
warehouse task per warehouse order. 30% of received HUs are applicable for storage and are not deconsolidated.
Confirmation of these 30% warehouse tasks is done by GUI (not RF) and the putaway is done with a single
resource.
Enter for sizing element IEWM-PACON: wareh. tasks = 800 ( 100 deliveries * 8 highest-level HUs), % RF = 70%
RF based confirmation
Enter for sizing element IEWM-PATSK: wareh. tasks = 400 (800 – 400)
The move warehouse tasks going to deconsolidation are processed with one resource change.
Enter for sizing element IEWM-RESPA: wareh. tasks = 560 ( 70% * 800 highest-level HUs), rschg = 1 (one
resource change)
560 received highest-level HUs are deconsolidated into 280 putaway HUs, each containing a single product.
Enter for sizing element IEWM-DECON: HUs = 280 putaway HUs after deconsolidation, items = 1 putaway item per
HU, unpack. items = 0
The 280 HUs created in deconsolidation are applicable for storage, so no split of those HUs into multiple putaway
warehouse tasks per HU is done.
Enter for sizing element IEWM-MOVE: wareh. tasks = 280 HU warehouse tasks
Put-away of those 280 HUs needs two times a resource change (for example those HUs are going to high rack).
Enter for sizing element IEWM-RESFI: wareh. tasks = 280 ( 280 HUs) , rschg = 2 (two resource changes)
Back to Top
SAP Extended Warehouse Management - Outbound
EWM Outbound Definition

Delivery Process The outbound delivery process consists of several steps:
Creation of outbound delivery order (OEWM-DLV)
Creation of picking warehouse tasks (OEWM-PICK)
Confirmation of picking warehouse tasks (OEWM-CONF)
Optional: Move warehouse task (from picking resource to picking destination bin, OEWM-DEST)
Optional: Change of resource in picking (OEWM-RESPI)
Optional: Packing and creation of follow-up move warehouse task (OEWM-PACK)
Optional: Move warehouse task (from packing station to staging area (OEWM-STAGE)
Optional: Change of resource in staging (OEWM-RESST)
Optional: Loading warehouse task (OEWM-LOAD)
Delivery based Goods Issue (OEWM-GOODS)

Outbound Step - Objects: Number of delivery documents
Creation of Items: Average number of items per delivery
Outbound
Delivery Order
OEWM-DLV

Outbound Step - Wareh. Tasks: Number of picking warehouse tasks
Creation of
Picking
Warehouse Tasks
OEWM-PICK

Outbound Step - Wareh. Tasks: Number of picking warehouse tasks
Confirmation of %RF: Percentage of radio frequency based picking confirmation
Picking
Warehouse Tasks
OEWM-CONF

Outbound Step - Wareh. Tasks: Number of warehouse tasks from resource to picking destination
Move Warehouse
Picking Resource
to Picking
Destination Bin)
OEWM-DEST

Outbound Step - Wareh. Tasks: Number of warehouse tasks with resource changes
Resource in
Picking Assumption: 100% RF
OEWM-RESPI

Outbound Step - HUs: Number of highest-level HUs created in packing
Packing and Items: Average number of pick items packed per ship highest-level HU
Creation of
Follow-Up Move
Warehouse Task
OEWM-PACK

Outbound Step - Wareh. Tasks: Number of staging original warehouse tasks
Move Warehouse
Packing Station to
Staging Area)
OEWM-STAGE

Resource in
Staging Assumption: 100% RF
OEWM-RESST

Outbound Step - Wareh. Tasks: Number of loading warehouse tasks
Loading
Warehouse Task Assumption: 100% RF
OEWM-LOAD

Outbound Step - Objects: Number of delivery documents
Delivery based Items: Average number of items per delivery
Goods Issue
OEWM-GOODS
EWM - Simple Find this example to see how the fields could be filled-in.
Outbound
Delivery Process
Example 500 outbound delivery orders with two items on average are created based on messages received from ERP.
Enter for sizing elements OEWM-DLV and OEWM-GOODS: objects = 500 deliveries , items = 2 items per delivery
Each delivery item is picked with a single picking warehouse task. Average size of a warehouse order is one
picking warehouse task. A full pallet is picked, pallets play the role of picking and shipping HU:
Enter for sizing element OEWM-PICK: wareh. tasks = 1000 pick warehouse tasks
Enter for sizig element OEWM-CONF: wareh. tasks = 1000 pick warehouse tasks , % RF = 100% RF
The full pallets are moved to staging area, including on average two resource changes (the pick resource plus two
others take part).
Enter for sizing element OEWM-DEST: wareh. tasks = 1000 HU movement warehouse tasks
Enter for sizing element OEWM-RESPI: wareh. tasks = 1000 , rschg = 2 (two resource changes)
Enter for sizing element OEWM-PACK: HUs = 0 (no repacking), items = 0
Enter for sizing element OEWM-STAGE: wareh. tasks = 0
Enter for sizing element OEWM-RESST: wareh. tasks = 0, rschg = 0

100% make use of system based loading with loading warehouse tasks.
Enter for sizing element OEWM-LOAD: wareh. tasks = 1000 HU loading warehouse tasks
Goods issue is performed for the 500 deliveries.
EWM - Highly Find this example to see how the fields could be filled-in.
Complex
Outbound
Delivery Process 100 outbound delivery orders with four items on average are created based on messages received from ERP.
Example Enter for sizing elements OEWM-DLV and OEWM-GOODS: objects = 100 deliveries , items = 4 items per delivery
On average, each delivery item is picked via two picking warehouse tasks (whole delivery quantity can not be
managed with a single warehouse task). Average size of a warehouse order is five picking warehouse tasks. All
five picking items are picked into a pick HU with RF (->160 pick HUs are created).
Enter for sizing element OEWM-PICK: wareh. tasks = 800 pick warehouse tasks
Enter for sizig element OEWM-CONF: wareh. tasks = 800 pick warehouse tasks , % RF = 100% RF
Pick HUs are beeing moved by pick resource (small fork lift). 40% of them are dropt to be overtaken by one other
resource which moves them to packing station, the 60% rest is directly moved to packing station.
Enter for sizing element OEWM-DEST: wareh. tasks = 160 HU movement warehouse tasks
Enter for sizing element OEWM-RESPI: wareh. tasks = 64 ( 40% * 160) , rschg = 1 (one resource change)
During RF based packing, the pick HUs with five items each (cross delivery ! ) are repacked into shipping HUs with
four items.
Enter for sizing element OEWM-PACK: HUs = 100 HUs, items = 8 ( 4 delivery items * 2 picking warehouse tasks
per delivery item)
Shipping HUs are beeing moved to staging area by a single resource (without resource changes).
Enter for sizing element OEWM-STAGE: wareh. tasks = 100 HU movement warehouse tasks
Enter for sizing element OEWM-RESST: rschg = 0 (no resource change)
30% make use of system based loading with loading warehouse tasks.
Enter for sizing element OEWM-LOAD: wareh. tasks = 30 HU loading warehouse tasks (30% of objects of sizing
element OEWM-STAGE)
Goods issue is performed for the 100 deliveries.
Back to Top
SAP Transportation Management
SAP Definition
Transportation SAP Transportation Management (SAP TM) supports you in all activities connected with the physical transportation of
Management goods from one location to another. You can use SAP TM to perform the following activities, for example:
Create forwarding orders for your ordering parties
Transfer orders and deliveries from an ERP system
Create freight bookings
Plan the transportation and select carriers
Tender transportation services
Dispatch and monitor the transportation
Calculate the transportation charges for both the ordering party and the supplier side
Consider foreign trade and dangerous goods regulations
You can use SAP TM to create and monitor an efficient transportation plan that fulfills the relevant constraints (for
example, service level, costs, and resource availability). You can determine options to save costs and to optimize the use
of available resources. You can react to transportation events and find solutions to possible deviations from the original
transportation plan.
Scenario: Direct creation of Freight Orders
Example situation: A shipper (e.g. a manufacturer) distributes products through its network of plants, distribution centers
and 3rd party warehouse operations. The Logistics organization of the shipper is responsible for the timely, cost effective
and efficient transport between and from their facilities to the end customer. The shipper receives orders electronically in
SAP Transportation Management (TM) via Sales Orders created in ERP Sales and Distribution. Within TM, these orders are
directly transferred into corresponding Freight Orders. The shipper determines carriers for the Freight Orders and
executes a tendering process. The finally selected carriers execute the transportation. In TM, the shipper calculates the
freight costs and finally creates freight settlement documents for payment of the transport.
This shipper scenario (for a throughput-based sizing) consists of the following steps, where some of them are optional:
1. Creation of Order Based Transportation Requirements (OTRs) in TM, based on Sales Orders received
from ERP
2. (Optional) Carrier selection for the Freight Orders
3. (Optional) Tendering of Freight Orders to Carriers
4. Calculation of Transportation Charges for the Freight Orders
5. Create Freight Settlement for the Freight Orders
Creation of Order Specifics

Based Objects:
Transportation Number of Sales Order Documents / OTR documents.
Requirements Items:
(OTRs) in TM Average number of items per Sales Order / OTR documents.
based on ERP Freight Orders (Freight Ord.):
Sales Orders Number of Freight Orders created for the OTR
TM-OTR Choose either
'Header: One Freight Order per OTR header' or

'Item: One Freight Order per OTR item'
(Optional) Carrier Specifics

Selection Objects:
TM-CAR-SEL Number of Freight Orders for Carrier Selection.
Carriers:
Average Number of involved Carriers.
Cost Determination (Cost Det.).:
Determination of costs: Internal Costs from Lanes or Charge Calculation.
Choose either
'Lanes: internal costs from Lanes',
'SCC: Simple Charge Calculation' or
'CCC: Complex Charge Calculation'.
Note: For medium charge calculation, choose 'CCC: Complex Charge Calculation'.
(Optional) Specifics
Tendering Objects:
TM-TENDER Number of Freight Orders to be tendered.
Carriers:
Average Number of carriers used in the tendering process.
Costs:
Determination of costs: Internal Costs or Charge Calculation
Choose either
'Lanes: internal costs from Lanes',
'SCC: Simple Charge Calculation' or
'CCC: Complex Charge Calculation'.
Note: For medium charge calculation, choose 'CCC: Complex Charge Calculation'.
Calculation of Specifics
Transportation Objects:
Charges Number of Freight Orders to be calculated
TM-CHA-CAL C.Complexity: (C.Compl.):
Complexity of Charge Calculation:
Choose either
List of simple charge elements with flat rates ('Simple: Charge elements with flat rates'),
List of charge elements with rates determined from related rate tables ('Medium: Charge elements with rate
from rate tables') or
List of charge elements with flat rates, relative rates, percentages, and rates determined from related rate
tables ('Complex: Rates: flat, relative, percentage and tables')
Freight Specifics
Settlement Objects:
TM-FRE-SET Number of Freight Settlement Documents
Cost Determination (Cost Det.):
Determniation of costs
Copy all charges from Freight Order
Copy fixed charges and redetermine others
Choose either
List of simple charge elements with flat rates ('Simple: Charge elements with flat rates'),
List of charge elements with rates determined from related rate tables ('Medium: Charge elements with rate
from rate tables'),
List of charge elements with flat rates, relative rates, percentages, and rates determined from related rate
tables ('Complex: Rates: flat, relative, percentage and tables') or
List of all charges from Freight Orders ('Order: All charges from freight orders')
Example The following example shows how the sizing elements could be filled:
Sales Orders / OTRs (Table 1: Throughput- Creation of OTRs and Freight Orders)
Sales Orders with 5 items in average are created in ERP and transferred to TM where corresponding 1.000 OTRs with 5
items each are created from these Sales Orders.
Fill-in average sizing element TM-OTR:
'Objects' = 1.000,
'Items' = 5
'Freight Ord.' = One Freight Order per OTR header
(Optional) Carrier Selection (Table 2: Throughput - Carrier Selection and Tendering)
For each of the 1.000 Freight Orders a Carrier Selection is executed with an average number of 5 carriers, based on
internal costs defined on the involved lanes.
Fill-in average sizing element TM-CAR-SEL:

'Objects' = 1.000
'Carriers' = 5
'Cost Det.' = Internal Costs
(Optional) Tendering (Table 2: Throughput - Carrier Selection and Tendering)
For each of the 1.000 Freight Orders a Tendering is executed with an average number of 5 carriers, based on internal
costs.
Fill-in average sizing element TM-TENDER:
'Objects' = 1.000
'Carriers' = 5
'Cost Det.' = Internal Costs
Transportation Charges Calculation (Table 3: Throughput - Calculation of Transport Charges for Freight
Orders)
For each of the 1.000 Freight Orders a Transportation Charges Calculation is executed with charge elements on the
Transportation Charges Calculation Sheet that determine their rates from related rate tables.
Fill-in average sizing element TM-CHA-CAL:
'Objects' = 1.000
'C.Compl.' = List of charge elements with rates determined from related rate tables.
Freight Settlement (Table 4: Throughput - Freight Settlement)
For each of the 1.000 Freight Orders a single individual Freight Settlement Document is created and transferred from
TM to ERP.The charges for the Freight Settlement are calculated with charge elements on the Transportation Charges
Calculation Sheet that determine their rates from related rate tables.
Fill-in average sizing element TM-FRE-SET:
'Objects' = 1.000
'Cost Det.' = 'Medium: Charge elements with rates from rate tables'
Back to Top
SAP Supplier Relationship Management

Resource in
Staging Assumption: 100% RF
OEWM-RESST
SRM in the Quick General Information

Sizer Starting with SAP SRM 7.0, sizing with the Quick Sizer has been changed from a technical-scenario-based approach
(classic, extended classic, or standalone scenario) to a business-object-based approach. This makes it easier to identify
the objects for which you need to perform sizing. The sizing only covers the SRM Server. All other components, such as
SAP ERP, SAPNetWeaver BW, MDM, TREX, have to be sized separately.
The Sizing is divided into two main areas SRM Operational Purchasing and SRM Strategic Purchasing for better usability.
Note: ITS is no longer used, hence the sizing element was removed.
Throughput-based sizing
In order to perform appropriate sizing for UI-based operations, for batch-processing, and for the creation of business
objects via interfaces, we have introduced two scenario types:
Scenario 1: Simple scenario with few complex steps
We refer to a scenario 1 if either of the following criteria apply:
The business objects are created via the Web Dynpro UI, and they are simple. This means that only a few
features of the business objects are used.
The business objects are created via batch processing or via interfaces (no direct user interaction). This
means that no origin UI server load is generated.
Scenario 1 assumes a different resource consumption, either because the objects are less complex or because no
Web Dynpro UI is used.
Scenario 2 : Complex sceanrio with many simple steps

We refer to a scenario 2 if the following applies:
The business objects are created via the Web Dynpro UI, and they are complex. This means that all or at least
most features of the business object are used (for example conditions, schedule lines, distribution functions,
internal notes, IPC pricing).
Use this scenario for all online users. If you use only a few object features, you can use scenario 2 approach for
complex business objects and the scenario 1 approach for simple objects.
Scenario 3: Mixed scenario

If you are not sure regarding the feature usage (whether complex or simple) split up the figures 50:50 over both
scenario types and you will get a quite suitable result in many cases.
Naming conventions in sizing elements (example: contract)
SRM-CTR-1U: Simple contract scenario with few complex steps – number of users
SRM-CTR-2U: Complex contract scenario with many simple stpes – number of users
SRM-CTR-1: Simple contract scenario with few complex steps – number of documents
SRM-CTR-2: Complex contract scenario with many simple stpes – number of documents
Example
If you transfer purchase requisitions from SAP ERP to SAP SRM, you can use the Professional Shopping Cart scenario 1 to
perform the sizing for these objects.
For the objects invoice, confirmation, and shopping cart wizard (occasional shopping cart), there is no need for a
distinction between the two scenarios hence the above naming convention does not apply to these objects.
Note for IPC sizing

Sizing of IPC is already contained in the sizing result.
Note for SAP NetWeaver Portal sizing
Portal sizing is included for the entire part of SRM only if you provide active user figures. If you run additional scenarios
like Intranet applications, you have to size those applications separately. After calculating the sizing result, there are two
lines within the sizing result: one for SRM and one for NetWeaver. The NetWeaver line contains the portal sizing. If you
switch the result level on top of the result page from “SAP solutions” to “Software components”, you get the component-
based view on the sizing result, which indicates clearly how many SAPS you need for SRM server and for the portal
server. On the result level "Sizing element" you see the result for the corresponding (automatically calculated) portal
sizing element "NW-EP-SRM".
Note for Good Response Times
For good response times choose CPUs with a good single-thread performance.
Note for SAP SRM 7.01 Sizing
Sizing is not required for portal auction as it is similar to RFx which is already included in the sizing measurements.
However, Live Auction(LA) for Bidders is a valid scenario. Most customers use Java LA and sizing document is already
available for this. A few customers use ABAP LA and there have been no issues reported so far. So sizing for ABAP LA is
not provided at this point of time. Procurement for Public Sector(PPS) has to be sized by consulting SAP if any extra
requirement is needed by the customers. This is because the requirement for usage of various PPS functionalities may
differ from one customer to the other.
Contract Definition
SRM-CTR-1U, A central contract is a legally binding agreement between a purchaser and a supplier. It defines the purchase and supply
SRM-CTR-2, of goods or services at agreed prices and conditions, such as rebates and quantities to be ordered. A strategic purchaser
SRM-CTR-1, typically creates a central contract as soon as it becomes clear that the relationship with a supplier will be long-term. The
SRM-CTR-2 quantity and value of purchase orders (POs), limit confirmations, and invoices are released against the central contract.
Specifics for Contract Input
Enter the number of users
Enter the number of documents which are created
RFx Definition
SRM-RFX-1U, Purchasers can create RFx documents for products and services. RFx can be created from scratch, in the SAP Bidding
SRM-RFX-2U, Engine, or directly from a central contract. Using RFx as a basis, suppliers bid on the products and services that are
SRM-RFX-1, required, allowing the purchaser to determine the most suitable source of supply.
SRM-RFX-2
The term RFx is used as a general term for the type of document a purchaser sends out to potential bidders. Purchasers
can create any type of document, or transaction type they choose, such as a simple request for information, or a request
for a quote.
Specifics for RFx Input
Purchase Order Definition

SRM-PO-1U, Display and process purchase orders.
SRM-PO-2U, After a shopping cart has been approved or a requirement has been successfully transferred from an external system,
SRM-PO-1, such as PM, PS or MRP, the system creates one or more purchase orders.
SRM-PO-2
Specifics for Purchase Order Input
Occasional Definition
Shopping Cart The shopping cart wizard is the default user interface for employees and is less complex than the professional shopping
SRM-OSC-U, cart.
SRM-OSC
Specifics for Occasional Shopping Cart Input
Professional Definition
Shopping Cart This user interface is available to fill shopping carts with products quickly and easily.
SRM-PSC-1U,
Specifics for Professional Shopping Cart Input
SRM-PSC-2U,
SRM-PSC-1, Enter the number of users

SRM-PSC-2 Enter the number of documents which are created
Confirmation
Definition
SRM-CONF-U,
Confirmation of goods delivery, services rendered and hours worked. Purchasers can create confirmations themselves,
SRM-CONF
even if the purchase order is in the back-end system. It is possible to create express confirmations directly in the Check
Status application without having to switch to another application.
Specifics for Confirmation Input
Enter the number of documents which are created.
Invoice Definition
SRM-INV-U, Display and process invoices.
SRM-INV
For invoices that you create with reference to a purchase order, the system automatically supplies the data from the
system in which the purchase order was originally created (local purchase order or back-end purchase order).
Specifics for Invoice Input
Enter the number of documents which are created.
Back to Top
SAP GRC Global Trade Services
Global Trade
Definition
Services (SAP
SAP Global Trade Services (SAP GTS) automates global trade processes and enables you to manage large numbers of
GTS) Compliance
business partners and material as well as high volumes of documents, while also helping you to comply with changing
and Customs
legal regulations. It facilitates foreign trade by providing you with the tools you require to respond to governments
Management
modernizing their systems and communicating electronically with businesses.
GTS-CUMA,
GTS-SLS, SAP GTS supports international trade compliance issues in three primary areas:
GTS-FI,
Sanctioned party list (SPL) screening
GTS-BP,
Import/export control
GTS-MAT,
Embargo checking
GTS-SCREEN
SAP GTS also supports automated and standardized customs processes including, for example, electronic communication
with the customs authorities. It speeds up the release of goods by the customs authorities in the following areas:
Import processing
Export processing
Transit procedure
The following are the technical elements used for SAP GTS sizing and their explanation:
GTS-CUMA – GTS Customs Documents (Import/Export Customs Declarations and Customs Shipments, Transit
Documents)
GTS-SLS – GTS Compliance Documents (Sales Orders, Deliveries, Purchase Orders)
GTS-FI - Screening of payment (Sanctioned Party List Screening for Financial Accounting)
Due to tighter control measures and legal regulations implemented by the European Union on foreign payment
transactions, it is necessary for companies that operate on a global level to provide evidence of checks performed
on incoming and outgoing payments. This involves checking business partners in accounting transactions against
published sanctioned party lists.
Your company can insure that sanctioned persons, groups and organizations are recognized in advance of payment
transactions taking place, and, as a result, prevent transactions being performed. These sanctioned parties are
published and updated on a regular basis in different countries and by different organizations, and may contain, in
some cases, the same sanctioned parties.
You should enter the number of FI payment documents and the average number of invoice line items you plan to
screen during automatic transactions (F110 and F111) and during manual payments with printout (FBZ4).
Technically, the number of entries in FI database table REGUH can give you a guideline for the number of payment
documents whereas the number of entries in FI database table REGUP can help to derive the average number of
invoice items.
GTS-BP – Business Partners Master data (Vendors, Customers, Employees, etc)
GTS-MAT – GTS materials
GTS-SCREEN – Periodic GTS screenings (B1, B2, C1, C2)
All the above are to be used considering annual volumes by using the Average (rows with A -Y after the technical
description) or Peak (row with P-P after the technical description) sizing methods, excepting for GTS-SCREEN, which is
explained in more detail below.
Note for GTS Business Partner & Documents Screening (GTS-SCREEN)
The column "documents" refers to the B2 (Periodic) and C2 (SPL update) scenarios, which check document addresses.
B2 Scenario
With the B2 scenario you can check periodically addresses in documents which have already been checked.
Therefore, from a business perspective, this scenario is to be run only when GTS is first implemented to check on
documents which have already been processed either manually or if you were using a different vendor software.
To do this, you will have first to mass transfer the documents and then run the B2 scenario. Since it is
recommended to transfer the documents and run the scenario BEFORE GTS is live and it is to be run only once, for
sizing purposes, you should run a separate calculation with the quick sizer ONLY with the number of documents in
GTS-SCREEN which you have mass transferred previously. This will give you a number of SAPS which should be
required for this process, since there are no other processes consuming resources at the same time. Notice that
since the documents have been already processed (and probably shipped), this B2 scenario is run for purely
informative purposes, as you cannot take any logistic action on the documents. Also notice that there will be audit
trail records available to be checked in case of an audit.
C2 Scenario
With the C2 scenario you can check addresses in documents which have already been checked when there has
been a recent SPL data update. Therefore, from a business perspective, this scenario is to be run only when an
SPL update has been implemented to check on documents which have already been processed. Have in mind that
since there is new SPL data, you may get new SPL matches in documents that did not get any matches before,
and that there will be an audit trail record which can be checked later in case of an audit.
Therefore, you should consider running this scenario only if:

1) The documents being checked have not been shipped yet, OR
2) There is a clear understanding for the authorities that you have no logistic control over the documents being re-
checked, since they are already shipped.
Given that SPL updates are normally issued monthly (this is just a rough guideline which depends on your data
provider), the recommended number of documents to be used for sizing purposes is one-twelfth (1 /12) of the
yearly number of documents being considered for GTS Compliance Management (GTS-SLS at standard throughput
sizing)
Global Trade Definition

Services (SAP SAP Risk Management - Preference Processing supports exporters in indicating goods for preferential tariff treatment.
GTS) Risk SAP Risk Management – Preference Processing assists exporters in determining whether all the prerequisites for
Management preferential customs duty rates have been fulfilled. Exporters can obtain a competitive advantage over competitors due
Preference to reduced or zero rates of customs duty on goods with preferential origin for the importing customer. For SAP Risk
Processing Management the Scenarios GTS-BP and GTS-MAT are to be included in the Sizing projects as common master data is
GTS-RI-BOM, used. For the purpose of Sizing it is assumed that one preference agreement is set up for preference processing.
GTS-RI-MM,
SAP GTS supports preference processing issues in the following main areas:
GTS-RI-SO,
GTS-RI-INV, Master data transferring - Bills of Material, Procurement Indicator and Price transfers.
GTS-RI-SOL, Transactional data from feeder system- Purchase Orders, Sales Orders, Invoices.
GTS-RI-AGG, BOM Preference Determination
GTS-RI-PRD, Long Term Vendor Declarations (LTVDs) processes - Solicitation, aggregation, issuing.
GTS-RI-ISS
The following are the technical elements used for GTS Risk Management sizing and their short text explanation:
GTS-RI-BOM – Bill of material transfer
For transferring Bills of Materials (BOMs). Here what you have to enter is the sum of the number of items
(including the top material itself of all the BOMs to be transferred. That means that for a one level BOM with five
subcomponents the number to be entered is six (five subcomponents + one top material).
GTS-RI-MM – Worklist for requesting long-term vendor declarations based on MM Purchase Orders and MM Goods
Receipts
For MM Documents (Purchase Orders and Goods Receipts) being sent to GTS. In case the Purchase Orders are also
to be screened with SAP GTS Compliance, you should make a separate entry in GTS-SLS.
GTS-RI-SO – Preference status determination in sales process (SD SO)
For Sales Orders Documents being sent to GTS. In case the Sales Orders are also to be screened with SAP GTS
Compliance, you should make a separate entry in GTS-SLS.
GTS-RI-INV – Worklist for issuing long-term vendor declarations based on SD Invoices
For Invoice Documents being sent to GTS. In case the Invoice Documents are also to be processed within SAP GTS
Customs, you should make a separate entry in GTS-CUMA.
GTS-RI-SOL – Request of long-term vendor declaration
For the solicitation of long-term vendor declarations.
GTS-RI-AGG – Aggregation of long-term vendor declarations
For the preference status aggregation into the GTS product master based on long-term vendor declarations.
GTS-RI-PRD – Preference determination of bills of material
For the preference determination of in house production according to Bills of Materials (BOMs).
GTS-RI-ISS – Issuing long-term vendor declarations
For issuing and revocation of long-term vendor declarations.
Back to Top
SAP In-Memory Computing
SAP In-Memory General Information

Computing in SAP HANA is an in-memory database platform. Please refer to http://www.sap.com/hana/ for more information on its
Quick Sizer architecture and capabilities.
HANA Sizing Notes
For a comprehensive description of the sizing algorithms for SAP HANA In-Memory Database please refer to SAP note
1514966.
HANA Rapid Definition

Deployment SAP rapid-deployment solutions for HANA provide fast time-to-value for customers implementing innovative SAP
Solutions solutions based on In-Memory technology.
OPER-REP,
CO-PA-ACC, They also
They contain preconfigured content for HANA and are targeted for a specific LoB- or Industry use case.
CUS-SEG-A, contain pre-defined, fix-price implementation services as well as enablement material, and depending on the
CRM-PIPE-A, scenario may also contain pre-configured Business Analytics frontends.

FS-FIN-REP,
FI-CO-ACC, The following HANA rapid-deployment solutions are available:
FS-TRA-HIS SAP ERP rapid-deployment solution for operational reporting with SAP HANA
SAP ERP rapid-deployment solution for profitability analysis with SAP HANA
SAP CRM rapid-deployment solution for customer segmentation with SAP HANA
SAP CRM rapid-deployment solution for pipeline analysis with SAP HANA
SAP Bank Analyzer rapid-deployment solution for financial reporting with SAP HANA
SAP ERP rapid-deployment solution for accelerated finance and controlling with SAP HANA
SAP Deposits Management rapid-deployment solution for transaction history analysis with SAP HANA
You can find further information here:
http://service.sap.com/rds-hana-erp
http://service.sap.com/rds-hana-copa
http://service.sap.com/rds-cust-seg
http://service.sap.com/rds-crm-pipeline
http://service.sap.com/rds-hana-finrep
http://service.sap.com/rds-hana-fin
http://service.sap.com/rds-hana-transhis
Specifics for HANA Rapid Deployment Solutions
Number of users
Enter the number of concurrent users
Source data footprint
Enter the source data footprint in GB
Compression factor
Enter the compression factor, i.e. the ratio of the sizes of uncompressed data tables (without their indexes) on the
source database and the memory requirements of these tables in HANA. We strongly recommend using the default
value if you do not have reliable information justifying a different compression factor.
SAP NetWeaver Definition

BW powered by HANA memory sizing is derived from the size of the tables in the source database. Note that only tables must be taken
HANA into account. Space for indexes, temporary table spaces etc. must be excluded. You can either run the sizing script
attached to SAP note 1637145 to obtain correct size information from your existing source database system catalog, or
you can enter details of the BW data model (InfoCubes and DataStore Objects) to create a sizing for HANA.

BW powered by The general idea is to define user groups which are determined by the number and size of data records they work with
HANA - User and the types of planning functions they execute. Additionally, you can define elements (users) for planning sequences
Groups Business (BPS or IP). Thereto, each planning function is considered one planning step. If you are not sure exactly how many data
Planning and IP are involved, you can take the proposed values, which are based on internal measurements and customer feedback.
Planning
Specifics for User Groups Business Planning and IP Planning Sequences (sizing elements H-PLANN 1, H-
Sequences
PLANN2, H-PLANN3)
H-PLANN 1,
H-PLANN 2, Users
H-PLANN 3 Estimate the highest number of active users per hour. Opposed to other sizing approaches in the Quick Sizer you
can arbitrarily include users in a specific group. Normally the user groups reflect the fact that you have power,
medium and occasional users (example at "Planning steps per user").
Planning steps per user

Estimate the peak number of planning steps per user and hour.
Example for "Users" and "Planning steps per user"

A user carries out six planning functions, the first three work on the same set of data (5,000 records), the other
ones each work on separate set of 600 records. If this sequence is carried out every 20 minutes, we were faced
with 18 planning steps per hour and user.
Average number of data records per planning step

A planning step always contains exactly one planning function, for example a formula function. If that planning
sequences are used, these cannot be calculated as a planning step, instead the number of planning functions
contained must be entered. The average number of data records manipulated by one single planning step has an
impact on the CPU time consumed by a user.
Example
In our example we have an average of 2,800 ( = (3 * 5,000 + 3 * 600) / 6) records per planning step.
Note
The term planning step is often understood from a business view, where it means a total run of a planning
area. Here, we take a functional perspective.
The memory requirement and CPU consumption is estimated on the basis of this data. To determine
memory requirements, we assume that there is an average data record length of 1KB.
Maximum data per planning step

Estimate the maximum number of data records manipulated by one single planning step.
Example
As mentioned above the planning functions work through different sets of data. The maximum number is 5,000
per hour and user.
Maximum data per user

Estimate the maximum number of data records a user holds in memory simultaneously. This is needed to estimate
the memory consumption of a user.
Example
Take the example mentioned above. If the user doesn't leave the transaction, he holds 6,800 (5,000 + 600 + 600
+ 600) records in memory. Please keep in mind, that the set of data is the sum of records read and records
created.
SAP NetWeaver Find information for the columns of this table below:
BW powered by BW Users (column "BW user") - Definition
HANA - User In NetWeaver BW, we distinguish roughly between user types according to their frequency of activity and the
Groups: Reporting reporting they will normally do.
& Analysis
H-BW-INFO, Active User Type Navigation Steps per Hour This user will
H-BE-BUSI., predominantly ...
H-BW-EXPER
Information Consumer 1 ... view predefined and static
reports
Business User 11 ... navigate within reports, do
slicing and dicing, but usually
cause moderate system load
BW Expert 33 and more ... run ad-hoc queries with a
high probability of causing
significant database load
A navigation step includes drilling down in the reports and corresponds to nine dialog steps in the SD
benchmark. If you don't know the user distribution, a typical ratio in the NetWeaver BW environment is
71% : 26% : 3% (Information Consumer : Business User : BW Expert).
Comment
The system automatically calculates the Java parts which are shown at the result level.
If BW Java is not used, you should add 5 % to the SAPS of the application server.
Report Viewing, OLAP Analysis, and Data Exploration (columns "Report.", "OLAP", and "Explor.") -
Definition
Collection of a selection of characteristics and key figures (InfoObjects) for the analysis of the data of an
InfoProvider. A query always refers exactly to one InfoProvider, whereas you can define as many queries as you
like for each InfoProvider.
For sizing purposes we distinguish between three query types which are defined by the load they create in the
system.
Report Viewing: Predefined, static, reports causing insignificant database load
OLAP Analysis: Slicing and dicing, navigating in reports
Data Exploration: Data mining, that is ad-hoc reports with unpredictable navigation paths, access of
detail data, full table scans
Any user can do any type of query. However, experience shows a certain activity pattern, as you can see in
the table below.
Query Report Viewing OLAP Analysis Data Exploration Total Percent

Type
Information 80% 20% 0% 100%
Consumer
Business 50% 50% 0% 100%
User
BW Expert 0% 0% 100% 100%
Web JAVA Reporting / Integrated Planning (columns "Web" and "IP") - Definition
In NetWeaver BW, reporting can be done either through the Excel based BEx Analyzer or through a Web browser
which receives HTML documents from a JAVA engine. If you use Web Reporting, you need to check the flag "Web"
and enter the corresponding number of users. If you use both, Web based Reporting and BEx Analyzer, you have
to enter the respective user numbers for both groups in individual lines of the QuickSizer. To create more lines in
table 2, mark the lines for the required user categories, select the number of copies and click on "Insert".
Another property of queries which has an impact on sizing is their input capability. Usually, queries used for
Integrated Planning are ready for input. If a query can accept input, then you need to check the flag "IP". Like in
the case above, you have to create separate lines in table 2 for users who use input queries and for those who
don't.

BW powered by In this section you can specify how many records you need to upload within your peak time interval.
HANA - Data
Upload
HBW-UPLOAD
SAP NetWeaver Specifics for the sizing element BW_HANA_TA

BW powered by If you intend to migrate an existing SAP NetWeaver BW installation to HANA, you should extract sizing information from
HANA - BW on the database system catalog of your source database. Please run the sizing script attached to SAP note 1637145 which
HANA Row Tables returns the current space requirements for tables in row and column store. Note that this reflects the current status, so
Foortprint and you should add an uplift to cover your planned system growth.
Column Tables Enter the values for Column Store tables and Row Store tables as reported by the sizing script.
Footprint Enter the compression factor, i.e. the ratio of the sizes of uncompressed data tables (without their indexes) on the
BW_HANA_TA source database and the memory requirements of these tables in HANA. We strongly recommend using the default
SAP NetWeaver Specifics for sizing element InfoCubes for HANA

BW powered by This section should be filled in, if you want to obtain a sizing for a given data model (i.e. a set of InfoCubes and
HANA - Defintion DataStore objects). The sizing is derived in the same way as for BW on a classic database.
of InfoCubes for Dimension
HANA A grouping of those evaluation groups (characteristics) that belong together, as regards contents, in one generic
INFOCUBES term. With the definition of an InfoCube, characteristics are summarized into dimensions in order to store them in
a table of the star schema (dimension table). An InfoCube has no more than 16 dimensions, of which three are
standard (package, time, unit) and included in the sizing by default. You can therefore enter only 13 dimensions at
most.
Key figures
Values or quantities, such as sales revenue, fixed costs, sales quantity, or number of employees. In addition to the
key figures saved on the database, you have the option of defining derived (calculated) key figures in the query
definition in the Business Explorer. Such key figures are calculated using a formula from the key figures of the
InfoCube. Examples of derived key figures are "sales revenue per employee" (sales revenue divided by number of
employees), "variance as a percentage", or "contribution margin".
Compression factor
Initial load & periodic load
Initial load: Specify the estimated number of records which you plan to load into the cube initially. Periodical load:
Specify the estimated number of records which are loaded in your periodical upload process. You should take into
account that you upload data volume grows with time.
Number of periods
Specify the total number of uploads which will be kept in the InfoCube. Example: if you want to keep weekly data
for 5 years, you should enter 260 (52*5)
SAP NetWeaver
BW powered by Definition sizing element DS-OBJECTS
HANA - Definition A DataStore Object serves to store consolidated and debugged transaction data at a document level (atomic level). It
of DataStore describes a consolidated dataset from one or more InfoSources. This dataset can be analyzed with a BEx Query or
Objects on HANA InfoSet Query.
DS-OBJECTS A DataStore contains a key (for example, document number/item) as well as data fields that can also contain character
fields (for example, order status, customer) as key figures. The data of a DataStore Object can be updated with a delta
update into InfoCubes and/or other DataStore Objects in the same system or across systems. Write-optimized
DataStore objects serve as storage for an inbound data layer. While these objects provide much faster data load, they
do not offer delta information.
In contrast to multi-dimensional data storage with InfoCubes, the data in DataStore Objects is stored in transparent,
flat database tables.
Specifics for DataStore Objects
NumFld (Numeric fields)
Enter the number of numeric fields in the DSO
TxtFlds (Text fields)
Enter the number of text fields in the DSO
CharLg (Character length)
Enter the average length of character fields in bytes
WO (write optimized)
Flag, if DataStore Object is write-optimized.
Compression factor
Enter the compression factor, i.e. the ratio of the sizes of uncompressed data tables (without their indexes) on
the source database and the memory requirements of these tables in HANA. We strongly recommend using the
default value if you do not have reliable information justifying a different compression factor.
Initial load
Enter the number of records initially loaded into the cube
Period. Upld (Periodic upload)
Enter the number of records loaded during the periodic upload process
Period
Enter the total number of uploads which will be kept in the InfoCube
Standalone HANA Definition

SOURCE_DB HANA memory sizing is derived from the size of the tables in the source database. Note that only tables must be taken
into account. Space for indexes, temporary table spaces etc. must be excluded. Run the sizing script attached to SAP
note 1514966 to obtain correct size information from your source database system catalog.
The number of users is optional. If you enter a user number, Quick Sizer checks if the CPU requirements are met by
certified hardware configurations.
Specifics for Standalone HANA
Enter the number of concurrent users
Enter the source data footprint in GB
Back to Top
SAP BusinessObjects Business Intelligence
SAP Find information about SAP BusinessObjects BI on the SAP Community Network -> BusinessObjects BI. Also see the
BusinessObjects Sizing Companion Guide .
Business
Intelligence (BI) Please refer to example project ‘BO_BI_V26.’ with customer number 188213.
BusinessObjects Each row of the table represents a different BI client tool. You can specify inputs for one or more of the client tools at the
Business same time depending on which BI client tools will be used in the deployment. Since the BI client tool names have been
Intelligence abbreviated in the table, you can see below for the full product names:
ANA-OLAP, SAP BusinessObjects Analysis, edition for OLAP (ANA-OLAP)
CRYST-2011,
CRYST-ENT, SAP Crystal Reports 2011 (CRYST-2011)
DASHBOARD,
WEB-INTEL SAP Crystal Reports for Enterprise (CRYST-ENT)
SAP BusinessObjects Dashboards (DASHBOARD)
SAP BusinessObjects Web Intelligence (WEB-INTELL)
Note
SAP BusinessObjects Explorer is not currently included in this version of the Quick Sizer. Please see SAP Note 1398242
for Explorer sizing materials.
Find information for the columns of this table below:
Information Consumers (column 'Info') – Definition
The least active of all the user types. Information consumers spend an average of 300 seconds (5 minutes) idle in
between navigation steps. These users typically view predefined and static content and perform relatively little
drilling and filtering on their own.
Business Users (column 'Business') – Definition
These users perform some moderate amount of drilling and filtering on their own. Business users spend an
average of 30 seconds idle in between navigation steps.
Expert Users (column 'Expert') – Definition
The most active of all the user types. Expert users spend an average of 10 seconds idle in between navigation
steps. These users are much more likely to perform resource-intensive operations in the system including ad-hoc
analysis and customization of reports, retrieving a large number of rows, and heavy client-side filtering.
Note on users (columns 'Info', 'Business', and 'Expert')
The number of users you specify for any user type represents active concurrent users, or put another way,
the number of users generating simultaneous requests in the system. The ratio of active concurrent users to
total user population can vary depending on many factors. One rule of thumb is to assume that 10% of all
users might actually be logged-in at the same time, and of those logged-in users 10% would be generating
simultaneous requests. In short, 1% of your total user population.
% of Small Reports (column '% S') – Definition
The expected percentage of small documents in the system.
% of Medium Reports (column '% M') – Definition
The expected percentage of medium-sized documents in the system.
% of Large Reports (column '% L') – Definition
The expected percentage of large documents in the system.
For more information about the report and dashboard document structures and sizes, please see the Sizing Companion
Guide.
Back to Top
Industry Solutions
SAP for Banking - Analytical Banking
SAP Basel II Definition

Solution SAP Basel II provides a standard platform for accurate calculations of credit risk and capital adequacy involving all types
of assets and calculation methods. The application's flexible structure and open reporting functions help banks improve
internal risk management and meet external risk-reporting requirements. Part of the SAP for Banking analytical
solutions, SAP Basel II gives banks broad, long-term support for regulatory compliance by integrating information for all
finance and risk-related business processes.
The most prominent business processes of this solution handle mass data. The main process in the SAP Basel II solution
is divided into the following steps:
1st step: Upload of the financial data from the front office systems to the source data layer (SDL; can be done
daily)
2nd step: Execution of the pre-run or general method (optional; no sizing available)
3rd step: Execution of the credit risk exposure calculation (can be done on a daily basis)
4th step: Historization run (is normally not done daily; no sizing available)
5th step: Data extraction to NetWeaver BW (can be done daily)
6th step: Regulatory reporting interface (is normally not done every day)
Specifics for CPU Sizing
For the CPU sizing only the peak values are taken into account. For each step you have to specify the start and end time.
In addition for each step you have to specify the number of objects that have to be processed.
Specifics for Disk Sizing

The disk sizing is done by the average sizing elements only. We neglect the master data here due to the fact that usually
the transactional data will dominate the disk sizing.
Note
The sizing of the Bank Analyzer solution is quite complicated because of the complex business structure of the Basel II
process, but also because of the very generic architecture of the Bank Analyzer. The structure of all mass data, business
objects, result data, and so on strongly depends on the customizing in the customer system. Also the runtime of the
methods working on these objects strongly depend on the way customers generate their particular modules. As a
consequence, the measured resource consumptions in the various tests can only provide an indication of the hardware
resources that may be required to fulfill the needed throughput.
Upload of Data Definition

(1st step) Upload of the financial data from the front office systems to the source data layer (SDL): For the calculation of the risk
FT/FI, weighted assets (RWA) the customer needs to have the current data in the SDL. In the first step, the financial data
POSITION (position data, business partner data, new transactions etc.) has to be uploaded from the front office systems etc. into
the SDL.
Specifics for Upload of Data

FT/FI
Enter the number of new or changed business transactions or instruments
Position
Enter the number of changed positions
Credit Exposure Definition

Run (3rd step) This business process calculates the risk weighted assets (RWA) in accordance with the Basel II paper and meets the
CE-RUN requirements for regulatory reporting. The system selects the relevant data from the source data layer (SDL) and builds
bundles for the transactions. Then the data for all the transactions and relevant partial objects in the bundle is read from
the Operational Data Store (ODS) and enriched for the RWA calculation.
Note the following for the main run:
The system builds the basis for the calculation process during pre-processing. Here all necessary data is collected,
enriched and provided for further processing.
Netting is not relevant for the performance test; the Exposure at default (EAD) calculation base is derived based
on the calculation approach for each financial transaction.
The system determines the risk parameters necessary for the RWA calculation.
The regulatory capital is calculated on the basis of optimized (capital saving) distribution of collaterals towards all
claims.
The results of the calculation process are EAD, RWAs, expected losses and regulatory capital. These results are stored in
the result layer (RDL).
For the performance of the calculation process it is important how many claims and collaterals are in the bundle as the
number of claims and collaterals influences the time needed for the selection of the bundle, the collateral assignment and
the number of results stored in the RDL (collaterized and uncollaterized part; external line, drawing, free line).
Specifics for Credit Exposure Run
For each credit exposure run specify not only the total number of financial transactions or instruments to be processed,
but also the number of objects that are relevant for effective maturity. These objects will strongly influence the runtimes,
because the cash flow has to be constructed or loaded. Therefore we need to know the average number of payments on
the cash flow that have to be constructed. If the customer uses the retail pre-run you should handle this just like an
additional credit exposure run.
Objects
Number of collaterals and claims:
Enter number of collaterals and claims
Lines:
Enter number of free lines
Months
Effective maturity
Cash flow
Disclosure and Definition

Reporting (5th In this step data from the source data layer (SDL), the results of the calculation process stored in the result data layer
step) (RDL) and other SAP systems or non SAP systems could be extracted into the Business Information Warehouse. In the
DR-RUN Business Information Warehouse there are more than 30 predefined Basel II reports covering the Pillar 3 requirements
for Basel II.
Specifics for Disclosure and Reporting Run
For disclosure and reporting (D&R) the sizing may strongly depend on the data that has to be read to enrich the RDL
results of the credit exposure run. We assume that only the complex key figure of the contract has to be read, not the
business partner. All information of the business partner was written into the RDL during the credit exposure run.
Objects
Number of level 2 results:
Enter the number of level 2 results
Regulatory Definition
Reporting Regulatory reporting consists of two parts:
Interface (6th Writing enriched data to the cluster
step) Creating of a file on a file system
REG-REPORT
Sizing considers only the first one.
Back to Top
SAP for Banking - Core Banking
Core Banking Definition

Core banking is a key functional area of SAP for Banking that provides a customer-focused transaction processing
environment. Core banking enables high-performance and cost-efficient processing for financial transactions and
supports development and introduction of new products and services using a range of distribution channels.
Mass Posting, Definition

Single Posting, Processing of payment items embraces the validation of the payment items, its posting to the dedicated account, and
Posting subsequently the update of balances for the account.
FS-BK-MPST,
Specifics for Mass Posting, Single Posting, Posting
FS-BK-SPST,
Enter the number of payment items per peak period.
FS-BK-PST
Statement Definition
FS-BK-STAT The on request bank statement process embraces the selection of all data (postings, balances, settlement details) that
are necessary to provide a bank statement data of an account.
Specifics for Statement
Enter the number of bank statements that are requested in a peak period.
Settlement Definition
FS-BK-SETT The settlement process embraces the calculation of interest and periodic charges for an account and the posting of the
results to the settled or a deviate account.
Specifics for Settlement
Enter ther number of accounts to be setlled per peak period.
Correspondence Definition
FS-BK-CORR The correspondence process embraces the creation of all types of customer correspondences (e.g. bank statements,
correspondences for contract changes, correpondences for special posting events). This correspondence is started
asynchronously e.g. once every day.
Specifics for Correspondence
Enter the number of created documents that have to be processed within a peak period.
Accruals Definition
FS-BK-ACCR The accrual process embraces the calculation of interest and periodic charges for an account. Results are transferred to
general ledger in a subsequent process for the purpose of accrual.
Specifics for Accruals
Enter the number of accounts to be accrued per peak period.
CMS Monitor Definition

FS-BK-CMS Collateral management monitoring run
Specifics for Credit Exposure Run

Collateral agreement
An agreement on the institution's own entitlement and third-party entitlements to the asset, on the calculation of
the collateral value and on the purpose of declaration.
Enter the number of collateral agreements per peak period.
Loans
Enter the number of loans per peak period.
Back to Top
SAP for Insurance

SAP Financial Services - Collection & Disbursement
General Remarks To correctly size Insurance with the Quick Sizer you must also fill-in the sizing elements Subledger, Dunning, Payment lot
for the Insurance (CD-PL) and Payment run (PAY-RUN) available on the Quick Sizer questionnaire under ERP -> Financials -> Contract
questionnaire Accounting.
Invoice and Definition

Account Note: We assume that the invoices and account statements are printed.
Statement
ACC-STAT
Insurance Object Definition

INS-INV There are several different kinds of insurance objects. The principal objects used are contract accounts and claims. You
can assign several insurance objects to a contract account.
Definition
Broker
The intermediary (for example broker) between the insurer and the insured. The insurance settlement process can be
BROK-ITEM
carried out either directly with the customer or via the intermediary (hereafter called broker). In Financial Services -
Collections & Disbursement there are two different scenarios:
Scenario 1: Communication and payment take place directly between the insurance company and the insured. In
this scenario the typical master record model is set up as follows: 1 business partner has 1...n accounts, to which
1...n insurance objects are assigned. Payments and correspondences are based on the CD documents posted to
the customer accounts.
Scenario 2: In the scenarios that involve brokers, the master data does not only consist of the customer master
data and the postings, but also of the "broker master data". For the broker additional master data is created:
Business Partner (Intermediary, Broker) --> Contract Account (Broker Account) --> Insurance Object (Broker
Contract). On the insurance contract level it is possible to specify and control for specific periods of time, whether
the broker is also responsible for collections and disbursements. Broker collections offers an additional function
called broker report. When a broker report is posted, the relevant items are transferred to the broker account, via
a transfer posting. In addition, the broker may also have a commission account. The commissions are also posted
to the broker account together with the broker report. In the end only the balance is settled with the broker,
which, compared to Scenario 1, considerably reduces the number of payment transactions, because a broker is
usually responsible for several customers at once.
Relevant is the number of broker report items which are reported by all brokers during the period. This includes all
reported premiums, claims, commission and cost items.
Payment Plan Definition

Transfer & During a payment plan transfer, the transaction data is transferred from the operational systems to the payment plan
Payment Plan store of the FS-CD, and this is followed by the payment plan execution. The number of open items is relevant for sizing.
Execution
There can be different scenarios for this process:
PAY-EXE
PAY-TRANS In the simplest and most common scenario, a transferred Payment Plan line item corresponds to exactly one open
item.
In the more complex scenario, a payment plan item is divided into several partial receivables. One payment plan
item can lead to the creation of several open items. For example, under a payment plan fixed payments have to
be made for the next 12 months. The payment plan is stored at the insurance object level and controls the
creation of open items from the payment plan line items.
Account Balance Definition

Display Enter the highest number of account balance displays that occur during the highest system load phase.
ACC-BAL
Back to Top
SAP for Retail
Definition
Retail The Retail system is a variation of SAP Standard code which is tailored to fit the volumes and processes which are specific
to a Retail functionality. Instead of dealing with materials and warehouses, this deals with locations/stores, articles and
distribution centers and is engineered to handle the high potential volumes of input data representing the point-of-sale
(POS) data collected at a register. There are six basic processes dealt with from a sizing viewpoint and these represent
the key processes in the daily cycle of a retail operation.
Note for the Questionnaire SAP for Retail within the Quick Sizer
Questionnaire
The questionnaire SAP for Retail contains input fields which must be filled with the results you get with the help of the
SAP for Retail in
retail sizing questionnaires (Sizing SAP Retail Questionnaire, Sizing Forecasting and Replenishment, Sizing SAP POS Data
the Quick Sizer
Management) which reside on the Service Marketplace: http://service.sap.com/sizing -> Sizing Guidelines -> Solutions &
Platform
Specifics for Standard Background Sizing - Disk

Standard
Background MRP for retail (R-MRP)
Sizing - Disk Basically for purchase requisitions created out of replenishment. (Table EBAN)
R-MRP, Allocation for retail (R-ALLOCAT)
R-ALLOCAT, Allocation tables are used in retail to determine how articles will be distributed to stores.(Tables AUKO, AUPO)
R-PHY-INV, Physical inventory for retail (R-PHY-INV)
R-PROMOT, One major process in retail is the maintenance of accurate store and distribution center (DC) inventory. Physical
R-VEND-INV counts are commonplace and frequent, hence increase in disk needs. (Tables IKPF, ISEG)
Promotions for retail (R-PROMOT) hold the appropriate data for maintaining promotions in the system before
processing through outbound to store level. (Tables WAKH, WAKP)
Vendor invoice for retail (R-VEND-INV)
Invoice data to complete cycle of DC activity in replenishment. (Tables WBRK, WBRP, WBPA, WBRF)
In the simplest and most common scenario, a transferred Payment Plan line item corresponds to exactly one open
item.
Please enter the number of objects and sub-items and the number of months that this data stay on the database.
Comments
Retail environment puts heavy load on the tables listed above and they are considered separately for proper disk sizing.
Results from Definition

Sizings for As mentioned above, this table contains input fields which must be filled with the results you get with the help of the
Aggregation in retail sizing questionnaires (Sizing SAP Retail Questionnaire, Sizing Forecasting and Replenishment, Sizing SAP POS Data
Quick Sizer Management) which reside on the Service Marketplace: http://service.sap.com/sizing -> Sizing Guidelines -> Solutions &
R-FR, Platform
R-POS-DM, Specifics for this table
R-POS-DL,
Forecasting & Replenishment (R-FR)
R-MASTER
When sizing for a forecasting and replenishment system, the results are expressed in SAPS required at the
database and server levels for peak processing time, and the disk requirements anticipated with consideration for
archiving plans. Those results should be entered in this section in the appropriate columns. Please ensure that peak
timeframes are entered to ensure overall peak CPU considerations.
Please enter the results you get if you follow the instructions within the sizing guideline "Sizing Forecasting &
Replenishment" in the corresponding columns SAPS (DB, ABAP, JAVA), memory (DB, ABAP, JAVA), and disk.
Point Of Sale Data Management (R-POS-DM)
POS DM is an add-on to BW. As such, the sizing of POS DM is considered as a delta-sizing of a BW-system. The
sizing of POS DM considers three critical steps:
1. Non-aggregated sales data is sent to POS DM and stored in the TLOG tables.
2. Process non-aggregated data to create aggregated sales IDocs (message type WPUUMS), payment type
IDocs (message type WPUTAB), FI-IDocs (message type WPUFIB).
3. Send IDocs across to the ERP system via report RSEOUT00 for further processing.
Results are the peak SAPS-requirements. Here, use ratio 1:3 for the distribution of the SAPS between DB and AS.
Please enter the results you get if you follow the instructions within the sizing guideline "Sizing SAP POS Data
Management" in the corresponding columns SAPS (DB, ABAP, JAVA), memory (DB, ABAP, JAVA), and disk.
Point Of Sale Download (R-POS-DL)
POS Download is the processing within ERP to prepare data (prices, new articles, promotions etc) to be sent down
to the stores. Each price change, new article, article in a promotion is considered as a "change" that needs to be
sent down to the stores.
Enter the SAPS numbers provided by the Retail Sizing Questionnaire in the corresponding fields "DB SAPS" and
"ABAP SAPS".
Retail Masterdata (R-Master)
This section estimates the disk capacity required to store the master data. Please fill in the fields as shown in the
Retail Sizing Questionnaire.
Comment
The actual processing cycle for POS Data Management (DM) is considered to be a once daily activity. If this is not the
case, then the POS DM sizing will need modification to correctly consider the execution cycle proposed.
Definition
Questionnaire SAP Forecasting and Replenishment (F&R) supports retailers in their daily replenishment. It must be executed exactly
once each day for all location product combinations which are defined as relevant for F&R and therefore has strong
SAP Forecasting requirements in terms of throughput.
& Replenishment
The application is located on an SAP SCM system, but also requires another leading ERP system for stock keeping,
purchase order creation or master data maintenance (this can be an SAP ERP system, but this is not a requirement). F&R
on SCM also contains additional software (Forecasting and Replenishment Processor (FRP)) which is executed on the
application servers at the operating system level and also needs current information for master data and transactional
data.
F&R needs to be updated with current data by the ERP system before it can execute its calculations and then transfer the
result as “order proposals” to the purchasing system. F&R sizing however refers only to processes which are running on
the SCM system.
The sizing in the Quick Sizer is a simplified calculation considering only the process steps which are usually the most
critical ones in terms of throughput for F&R. This gives you the possibility to get an estimation on the order of magnitude
for the required system landscape even before you have defined in detail how to run the application (there is also a more
detailed sizing for F&R considering significantly more data, but this requires a good insight to the application and the way
it will be configured. You can find the more detailed sizing for F&R on the service marketplace:
http://www.service.sap.com/~sapidb/011000358700000190022007E).
The simplified sizing in Quick Sizer refers to the following four steps:
1. Synchronization of F&R master data from F&R to FRP
2. Synchronization of order data from F&R to FRP
3. Processing of consumption data (and possibly stock data)
4. FRP run (including execution of all calculations, creation and transfer of the order proposals)
The business logic of F&R requires that these steps are performed in a certain sequence. The sizing model basically
assumes that these steps are executed in sequence, i.e. a given step can only be executed when the previous one has
finished completely. However, it is also possible to run certain steps together: You can run step 1 and 2 together.
You can even run the steps 1, 2 and 4 together, but step 3 must always run before step 4, so you need to run step 3
before this block.
Note:
There is an example project for SAP Forecasting & Replenishment for customer 188213 password "RETAIL F&R V20 F".
Definition
Master Data
In this process step all master data is transferred from F&R to FRP so that FRP has current information for its calculations.
synchronization
This data set does not contain order data, stock nor consumption information.
R-MDS
Specifics for master data synchronization
Location products
In this column you enter the number of all location product combinations which are relevant for F&R, i.e. for which
replenishment is performed with F&R.
Start time/ End time (S.t. / E.t.)
Start and end time describe the time frame in which this process step is executed.Location products:
Definition
Order Data
In this process step all data on open orders is transferred to FRP so that FRP has current information for its calculations.
synchronization
R-ODS Specifics for master data synchronization
Order proposal items (OP items)
In this column you enter the total number of order proposal items which are created by F&R per day in average.
Order proposals residence time (OP res.time)
In this column you enter the number of days which usually lies between the creation of an order and the complete
delivery.
Checkbox WMDS (With master data synchronization)
Activating the checkbox “WMDS” indicates that this step is executed together with the step described in element R-
MDS.
Start and end time describe the time frame in which this process step is executed. This entry is ignored if the
checkbox WMDS is active.
Definition
Processing
In this step all information on the consumption data (i.e. sales data and/or goods issue data) of the day is processed, i.e.
Consumption
a time series is updated.
(and Stock) Data
R-PCSD Specifics for master data synchronization
Depending on the process setup the current stock information is also updated by reducing the current amount for a
location product by the amount of the corresponding consumption data record. This is necessary if the process
configuration makes use of the option that stock data can already be updated in F&R before the consumption data for the
day is available.
There is also the option that the consumption data for the day is first processed in the ERP system and then the stock
data is transferred to F&R. This makes it necessary to update the stock information in F&R in this process step too.
Location products
In this column you enter the peak number of aggregated consumption data records per day. This means that there
is only one record for each location product combination.
Example: Let’s assume you have non-aggregated consumption data as follows:
product 1 – location 1 – 10 pcs

This would result in the following aggregated consumption data:

The column “Location products” with the value derived from element R-MDS is only considered if stock data
is also processed in this step. It is assumed that stock data is updated for each location product in this case.
Checkbox SDT (Stock data sent beforehand)
Checkbox “SDT” indicates if stock data is already processed beforehand, i.e. outside the process steps considered
for this sizing or not.
Location products of R-MDS
The value for this non-entry field is taken from the corresponding R-MDS input field.
Start and end time describe the time frame in which this process step is executed. This must be finished
completely before the process step described in element R-FRP can begin.
Definition
FRP Run
In this step all activities are considered which are necessary for forecasting, demand requirement determination, order
R-FRP
creation etc.
Specifics for master data synchronization
Location products of R-MDS
The value for this non-entry field is taken from the corresponding R-MDS input field.
Order proposal items (OP items of R-ODS)
The value for this non-entry field is taken from the corresponding R-ODS input field.
Start and end time describe the time frame in which this process step is executed. All information concerning the
data volume is derived from other elements (R-MDS, R-ODS).
Back to Top
SAP for Utilities
Specifics for Master Data and Transactional Data

Master Data and
Transactional Billing cycles per year (BillCycle)
Data for Disk Corresponds to the number of bills sent to a customer each year. Some customers send their business partners a
Sizing - Part I bill each month which would add to 12 invoices / year. An average value can be given here, if different groups of
UTIL-01 business partners have different invoicing frequencies.
Note
Typical values here are 1 (yearly billing), 2 (bi-yearly), 4 (quarterly), 6 (bi-monthly), 12 (monthly).
Budget billing amounts or partial bills per contract and year (Budget, Partial)
Usually the meters are read only once a year, but companies would like to get money from the customer more
frequently because of their own expenses. They have several choices to do it:
Real bills based on estimated consumption
Budget billing amounts
Real bills based on estimated consumption
The latter two ones are based on estimated amounts (not consumptions) and the difference between them
is that budget billing amounts are not posting relevant. Legally they are not earnings of the company while
partial bills are.
Example
When you read the meter once a year, you might have 11 partial bills between two bills.
Note
Due to the posting relevance, the treatment in IS-U is different and hence the significance for sizing. If
there are neither budget billing amounts nor partial bills, the answer to this question is not relevant.
Posting relevant line items per budget billing amount or partial bill (P.items)
For explanation see ‘Posting relevant line items on consumption bill’. However, the same figure of a partial bill is
asked for there. Usually, it is smaller then the one of the real, final bill. If no partial bills or budget billing amounts
are made, the correct answer here is 0.
Example
Enter “2” to reflect basic fee deposits and deposits on utiltiy services.
Posting relevant line items on consumption bill (C.item)

On each bill many lines are printed. Basically three types of lines exist:
Generic lines with some general information which is the same for all business partners. These lines are part
of the so-called print form and don’t play a role in sizing.
Posting relevant line items which contain monetary information that has finally to be passed to the general
ledger, like the total due amount. This is usual more then one line, as different services are posted on
different accounts. To give an example, a company might deliver gas and water to a customer, so they
might have four posting relevant line items for
Gas consumption
Water consumption
Waste water
Metering services
Additional info lines which are all non-posting relevant lines. This can include:
Consumption
Control readings
In any of these cases the average number of lines per single bill is requested in this sizing.
Additional info lines on consumption bill (Lines)

For explanation see above (Posting relevant line items on consumption bill). The average number of info lines is
asked for.
Contracts (Contracts)
A contract is an agreement between a business partner and the utility company that applies to a single division.
Therefore, this entity is quite similar to the legal contract the business partner has with the utility company to get
electricity, gas, water or some similar service. For example, if a company sells electricity to 500,000 customers
and gas to 100,000 customers, it would have 600,000 contracts with their business partners.
Taxes per contract (Taxes)

The number of different taxes that have to be paid on a contract. This could be VAT (value added tax), sales tax or
some kind of environment taxes.
Example
Enter “3” to reflect the jurisdiction code where the state, the county and the city each demand taxations.
Contract accounts (ContAcc.)

A contract account is an account in which posting data for contracts or contract items are processed for which the
same collection/payment agreements apply. Contract accounts are managed on an open item basis within contract
accounts receivable/payable. In the case of utility companies, a contract is assigned to one contract account only.
However, and depending on the contract account category, several contracts can be assigned to one contract
account. The relation between business partners and contract accounts is 1:n but in most cases the relationship is
almost 1:1. Nevertheless, this rule of thumb should only be used if there is no figures about “contract accounts”
available.
Meters (Meters)
The number of meters to be read. Meters in the stock are not to be counted here. Here it is asked for meters as
this device is quite familiar to everyone. A more correct input here would be the number of registers, but as
usually the relationship is 1:1 for the majority meters work as well. However, if the customer has a lot meters with
two registers, one e.g. for day- electricity and one for night-electricity, it would be better to enter the number of
registers instead.
Master Data and Specifics for Master Data and Transactional Data
Transactional Business partners (BusPartner)
Data for Disk A business partner is a natural person, organization, group of natural persons, or group of organizations in which a
Sizing - Part II company has a business interest. A business partner may be a person, organization, or group within a company,
UTIL-02 such as 'Mrs. Lisa Davies', 'Repro Electrical Products Inc.', or 'The tenants of 15 Charles St.'.
Overdue notices per year (Overdues)

The relative number of documents to be dunned per year is required. Experience from customers shows this figure
is between 5 and 10%.
Cash security deposits (Deposits)

A cash security deposit is a payment which the business partner has to make before the utility service starts. It is
usually requested when the company expects the business partner not to bill. This is different from pre-payment
where the customer purchases the right to e.g. use electricity up to an amount of $40. The total number of cash
securities is requested here.
Customer contacts per year (Cust.contct)

Usually when a business partner contacts the company by phone or mail a customer contact is created to keep
track of the communications. The total number of customer contacts created during one year is requested here. As
a rule of thumb from experience one contact per business partner and year can be assumed, but: In the past
when IS-U/CCS was developed, no CRM systems did exist and therefore customer contacts had to be written in
the IS-U/CCS system. Today however, most of the agents work with a CRM system and pass information from and
to the IS-U/CCS system. In this case the customer contact is completely handled in the CRM system and the
proper input here would be “0”.
CPU Sizing for Specifics for Background Processes

Background Business partners (BusPartner)
Processes Find the definition above at Disk Sizing -Part II → Business partners. The entries in these two fields have to be
UTIL-BP identical.
Days for batch (Days f. btch)
Minimum number of days available for one full billing cycle.
Example
If all 100,000 customers have to be billed once a month and each day the same number of customers should be
billed, the correct answer would be 28, because in February more customers have to be billed per day then in any
other month.
Minimal runtime per day (S.t. and E.t.)
Minimal daily time permitted to process the main batch cycle. This includes the whole billing and collection
process, starting from meter reading order preparation up to dunning activity run. The daily amount is calculated
as the number of business partners divided by the number of days for batch. This has to be the lowest maximal
runtime if the time window for this process is not the same every day.
Customer Comment
Overview (CPU Enter how often you use the transaction "Customer Overview".
Background
Sizing)
OVERVIEW
Customer Contact Find the definition above at Disk Sizing → Customer contacts per year.
(CPU Background
Sizing) Comment
CONTACT Enter how often you create customer contacts with the respective transaction. Attention: when using a CRM system
together with the IS-U system, the customer contacts are recorded in the CRM system and therefore the question is
irrelevant here.
Move-In and Definition

Move-Out (CPU Move-in is the registration for utility service by the customer. This is different from moving out of the residence, where
Background the utility service is cancelled.
Sizing)
MOVE IN
MOVE OUT
Back to Top
SAP NetWeaver
SAP NetWeaver Portal & KMC
Sizing NetWeaver Definition

Portal The questions for the NetWeaver Portal aim at determining the size of the Portal Server including the Portal database.
The load driving factors consist of user interaction steps to the Portal Server, which are called navigation steps. Note that
not all navigation steps create load on the Portal, but depending on the installation may create load on software
components other than the Portal (such as TREX or back-end systems). For more information on sizing the NetWeaver
Portal refer to Sizing SAP NetWeaver Portal.
Note
In a previous version of the NetWeaver Portal Sizing, the Quick Sizer assumed a distribution of 60% concurrent active
users with a think time of roughly 600 seconds between two Portal navigation steps, 34% with about 180 seconds think
time and 6% with a think time of 30 seconds. This results in an average think time of 211 seconds, which is quite
realistic for an Intranet scenario (NW-EP-INT). This version's results were based on an exemplary business process from
SAP CRM and the role of the Sales Representative, where each page contains three Java iViews.
Active Users - Definition

NetWeaver Portal The Quick Sizer allows you to define Portal scenarios yourself. For easier handling, there are default values which you can
NW-EP-URL, modify at your discretion. If you only have user numbers and no other information, we recommend that you use sizing
NW-EP-INT, element NW-EP-INT (Intranet scenario). Make sure, however, that you document all assumptions for the scenario as
NW-EP-PCC, detailed below. The list below contains an overview of typical example scenarios. Each of them rely on the following
assumptions:
NetWeaver Portal for launching back-end transactions using URL iViews
Portal navigations are used to launch transactions in the back-end system. In these scenarios Portal pages
typically contain one single URL iView (no Java iViews). To size the Portal Server, enter the number of users in this
(these) scenario(s) and their think time. The NetWeaver Portal for launching back-end transactions is an example
for a lightweight Portal application.
NetWeaver Portal for Intranet scenarios
In an Intranet scenario, the Portal is used as an Enterprise Information Portal. Users typically read news, access
documents, and occasionally launch transactions in other business systems. Enter the number of users. You can
modify the default suggestions at your discretion. The Intranet scenario is an example of a medium-weight Portal
application.
NetWeaver Portal for People-Centric CRM (PCC) scenario
This scenario is based on an example from SAP CRM with the end user role Sales Representative. An EP-PCC user
typically navigates in the Portal to perform actions such as
Launching BSP-based CRM transactions (1 URL iView, 0 Java iView)
Displaying overview information from CRM and NetWeaver BW backend system (Java iViews).
A NetWeaver BW (BEx) iView that does not use the Portal application cache is a URL iView. If it does use the Portal
application cache, it creates a load similar to a Java iView. The PCC scenario is an example of a medium-weight
Portal application.
Specifics for Active Users - NetWeaver Portal
Number of concurrently active users
To determine the high load phase, enter the highest possible number of users working simultaneously in the
system.
Average think time in seconds

This is the average elapsed time between two successive clicks of a user to the Portal Server, that is, between two
navigation steps. Note that the think time is often higher than most customers assume, as end users type, read,
use other applications, take a phone call and so on. As this field has a strong influence on the sizing result, you
should consider the figures carefully.
Number of Embedded iViews on an average Portal page
Specify the number of Embedded iViews of a typical Portal page of a specific scenario. An Embedded iView uses
the Isolation Method 'Embedded'. The iView's content is written "as is" into the HTML of the page. As a result, a
content-loading event in the iView, such as launching a link or submitting a form, refreshes the whole page (Check
also SAP Help Portal for more information on this :
http://help.sap.com/saphelp_nw73/helpdata/en/47/881b1e67731e1ee10000000a42189d/frameset.htm).
Number of URL iViews on an average Portal page
Specify the number of URL iViews of a typical Portal page of a specific scenario. For a URL iView, the Portal
generates the URL and sends it to the browser. The browser then sends the URL to the back-end system and
retrieves the HTML content from there.
Portal page design
Starting with SAP NetWeaver Portal 7.3 you can choose between different UI designs for your portal pages. These
are implemented with different technology frameworks which also have different impact on resource consumption.
We distinguish between
AFP: Ajax Framework Page with SAP Signature Design (the portal’s new framework page by default) and
Classic Design
Check also SAP Help Portal for more information on this
http://help.sap.com/saphelp_nw73/helpdata/en/48/1fee2f80093184e10000000a42189b/frameset.htm.
Maximal number of logons per hour

Active Users -
Enter the highest number of users (2,000, for example) who log on to the Portal within one hour (e.g. 8 am - 9 am). If
NetWeaver Portal
the users will log on to the Portal over a period of two hours (e.g. 8 am - 10 am), you then need to size only half of the
Logon
users (e.g. 1,000 logons per hour).
NW-EP-LOG
Sizing NetWeaver Definition Knowledge Management

Knowledge With its Knowledge Management capabilities, SAP NetWeaver provides a central, role-specific point of entry to
Management and unstructured information from various data sources. This unstructured information can exist in different formats, such as
Collaboration text documents, presentations, and HTML files. Workers in an organization can access information from different sources
(KMC) such as file servers, their corporate intranet, or the World Wide Web. A generic framework integrates these data sources
NW-KMC into Portal and provides all capabilities for access management and different functions (services) on all content of
integrated data sources.
Definition Collaboration
With its Collaboration capabilities integrated in Portal, SAP NetWeaver allows communication between members of
project groups regardless of their time zone and geographic location. Users can use virtual rooms for common access and
organization of documents, applications, and ideas.
Specifics for KMC
Accessed documents
This means operations such as search for a document, sort documents in folder, open folder, open document, view
document properties, edit document with no versioning enabled, cut&paste.
The resource consumption calculation is based on the assumption that 45% of the documents are accessed from
collaboration rooms and the rest are accessed via direct links, search, etc.
New documents
This means operations such as create document, upload document, copy&paste, create folder, give feedback or
rating to document, edit document with versioning enabled.
The resource consumption calculation is based on the assumption that 45% of new documents are structured in
collaboration rooms.
Size
Based on evaluations of several KMC implementations, we observed an average file size of 700KB. Our
measurements showed that there is a negligible CPU increase for files up until 5MB size. Therefore the size is not
included in the CPU calculation. Please note that if your Portal did contain more than 5MB average file size, you
must consider adding more CPU.
Rooms
The default value of 4000 rooms refers to the biggest currently known installation.
Comment
For the average sizing of KMC the time interval "period" was chosen instead of "year", because for "year"
the numbers would have been too high.
Back to Top
SAP NetWeaver Business Warehouse
SAP NetWeaver Find information about SAP NetWeaver Business Warehouse at the Service Marketplace -> Business Warehouse, for
Business example information about Performance Tuning.
Warehouse
User Groups Definition
Business Planning The general idea is to define user groups which are determined by the number and size of data records they work with
and IP Planning and the types of planning functions they execute. Additionally, you can define elements (users) for planning sequences
Sequences (BPS or IP). Thereto, each planning function is considered one planning step. If you are not sure exactly how many data
Planning 1, are involved, you can take the proposed values, which are based on internal measurements and customer feedback.
Planning 2,
Specifics for User Groups Business Planning and IP Planning Sequences
Planning 3
Users
Estimate the highest number of active users per hour. Opposed to other sizing approaches in the Quick Sizer you
can arbitrarily include users in a specific group. Normally the user groups reflect the fact that you have power,
medium and occasional users (example at "Planning steps per user").
Planning steps per user

Estimate the peak number of planning steps per user and hour.
Example for "Users" and "Planning steps per user"

A user carries out six planning functions, the first three work on the same set of data (5,000 records), the other
ones each work on separate set of 600 records. If this sequence is carried out every 20 minutes, we were faced
with 18 planning steps per hour and user.
Average number of data records per planning step

A planning step always contains exactly one planning function, for example a formula function. If that planning
sequences are used, these cannot be calculated as a planning step, instead the number of planning functions
contained must be entered. The average number of data records manipulated by one single planning step has an
impact on the CPU time consumed by a user.
Example
In our example we have an average of 2,800 ( = (3 * 5,000 + 3 * 600) / 6) records per planning step.
Note
The term planning step is often understood from a business view, where it means a total run of a planning
area. Here, we take a functional perspective.
The memory requirement and CPU consumption is estimated on the basis of this data. To determine
memory requirements, we assume that there is an average data record length of 1KB.
Maximum data per planning step

Estimate the maximum number of data records manipulated by one single planning step.
Example
As mentioned above the planning functions work through different sets of data. The maximum number is 5,000
per hour and user.
Maximum data per user

Estimate the maximum number of data records a user holds in memory simultaneously. This is needed to estimate
the memory consumption of a user.
Example
Take the example mentioned above. If the user doesn't leave the transaction, he holds 6,800 (5,000 + 600 + 600
+ 600) records in memory. Please keep in mind, that the set of data is the sum of records read and records
created
Comment
Editing/creating data records is achieved by planning functions or manual planning. We do not differentiate
between these two types for sizing, as both of them are used to manipulate data records.
We only size "User Groups Business Planning". NetWeaver BW server must be sized separately. However, the
sizing result includes the part of NetWeaver BW that is used to deliver the transaction data to "User Groups
Business Planning". For sizing the load generated on the NetWeaver BW system by "User Groups Business
Planning" we assume that 30% of all executed planning steps access NetWeaver BW. For the remaining 70% of
the planning steps we assume that they manipulate data records which have already been read by NetWeaver BW.
User Groups: Find information for the columns of this table below:
Reporting & BW Users (column "BW users") - Definition
Analysis In NetWeaver BW, we distinguish roughly between user types according to their frequency of activity and the
BW-INFO, reporting they will normally do.
BW-BUSIN.,
BW EXPERT Active User Type Navigation Steps per Hour This user will
predominantly ...
Information Consumer 1 ... view predefined and static
reports
Business User 11 ... navigate within reports, do
slicing and dicing, but usually hit
aggregates
BW Expert 33 and more ... run ad-hoc queries with a
high probability of full table
scans
A navigation step includes drilling down in the reports and corresponds to nine dialog steps in the SD
benchmark. If you don't know the user distribution, a typical ratio in the NetWeaver BW environment is
71% : 26% : 3% (Information Consumer : Business User : BW Expert).
Comment
The system automatically calculates the Java parts which are shown at the result level.
If BW Java is not used, you should add 5 % to the SAPS of the application server.
Report Viewing, OLAP Analysis, and Data Exploration (columns "Report.", "OLAP", and "Explor.") -
Definition
Collection of a selection of characteristics and key figures (InfoObjects) for the analysis of the data of an
InfoProvider. A query always refers exactly to one InfoProvider, whereas you can define as many queries as you
like for each InfoProvider.
For sizing purposes we distinguish between three query types which are defined by the load they create in the
system.
Report Viewing: Predefined, static, reports using optimal aggregates
OLAP Analysis: Slicing and dicing, navigating in reports, using various aggregates
Data Exploration: Data mining, that is ad-hoc reports with unpredictable navigation paths, access of
detail data, full table scans
Any user can do any type of query. However, experience shows a certain activity pattern, as you can see in
the table below.
Query Report Viewing OLAP Analysis Data Exploration Total Percent

Type
Information 80% 20% 0% 100%
Consumer
Business 50% 50% 0% 100%
User
BW Expert 0% 0% 100% 100%
Web JAVA Reporting / Integrated Planning (columns "Web" and "IP") - Definition
In NetWeaver BW, reporting can be done either through the Excel based BEx Analyzer or through a Web browser
which receives HTML documents from a JAVA engine. If you use Web Reporting, you need to check the flag "Web"
and enter the corresponding number of users. If you use both, Web based Reporting and BEx Analyzer, you have
to enter the respective user numbers for both groups in individual lines of the QuickSizer. To create more lines in
table 2, mark the lines for the required user categories, select the number of copies and click on "Insert".
Another property of queries which has an impact on sizing is their input capability. Usually, queries used for
Integrated Planning are ready for input. If a query can accept input, then you need to check the flag "IP". Like in
the case above, you have to create separate lines in table 2 for users who use input queries and for those who
don't.
BW Accelerator (column "BWA")

Set the flag, if you want to use BW Accelerator.
Comment
Data are already replicated and within BWA.
For more information on BWA sizing check SAP Note 917803.
Basis Providers (column "B.Prv.")
Enter the average number of basis providers per query used in BWA.
Comment
Basis providers are InfoCubes which are replicated to BWA.
Data Upload Definition

UPLOAD In this section you can specify how many records you need to upload within your peak time interval.
InfoCubes Definition
INFOCUBE The central objects upon which reports and analyses in NetWeaver BW are based, are called InfoCubes. An InfoCube
IC-APO describes (from a reporting point of view) a self-contained dataset, for example, of a business-orientated area.
IC-CO
An InfoCube has a particular type:
IC-CRM
IC-FI BasicCube which is a collection of relational tables arranged according to the star schema: A large fact table in the
IC-HR center, surrounded by several dimension tables.
IC-MM MultiCube which is based on the basic cube. It combines data from several BasicCubes/RemoteCubes, and brings it
IC-PP together into one context. The MultiCube itself does not contain any data; its data comes exclusively from the
IC-PS BasicCubes it is based on.
IC-SD RemoteCube to carry out reporting using data in external systems without having to physically store transaction
IC-SEM data in NetWeaver BW.
Only BasicCubes physically contain data on the database. MultiCubes and RemoteCubes simply display logical views of a
dataset. The InfoCube type is not important, as far as reporting is concerned. A query definition always refers to one
InfoCube. The difference between the InfoCube types becomes important at the point when you select data for the
query.
InfoCube types: From the list below you can choose additional InfoCubes, just take the information and fill it in the
questionnaire.
Long Text Short Name Cube name Dimensions Key Figures Length
Aerospace & Defense A&D 0AD_C01 6 2 94
Apparel and Footwear AFS 0AFMM_C01 8 48 896
Automotive 0AUPPC_3 12 11 307
Business Planning and Simulation 0SEM_C09 5 14 288
Category Management 0CM_C07 7 34 648
Consumer Products Industry CP 0CP_PURC1 8 52 964
Distribution Channel-Specific A 0CRM_CTI2 3 16 302
E-Analytics 0WEB_C01 12 5 205
External Market Data 0DB_MC01 9 5 175

Financials Management & Control 0FITV_C02 12 13 341
Healthcare 0HC_C01 9 16 362
Insurance 0IS_CS_C1 9 8 226
Inventory Management 0COPC_C04 7 6 172
Investment Management 0IMFA_C02 7 3 121
Marketing 0CRM_MC05 12 43 851
Marketplace 0MA_OP_C1 9 13 311
Media Enterprises 0MEMAMC04 11 16 382
Mobile Sales MSA 0MSA_C05 8 6 182
Oil & Gas Oil & Gas 0OI_SSC01 9 16 362
Personnel Management 0PACM_C01 10 17 389
Point of sale POS 0RT_C06 9 33 651
Retail - Logistics 0RT_C41 7 183 3181
Sales and Distribution Analyses 0CSAL_C09 12 29 613
Service 0CRM_PRI 14 47 939
Strategic Enterprise Management SEM 0SEMPA_C2 13 68 1286
Strategic Enterprise Management 0SEM_MC01 6 9 213
Traffic Analysis 0MA_C02 15 21 507
Treasury TR 0TRCM_MC1 6 2 94
Utility Company 0UCSA_C01 12 20 460
Specifics for InfoCubes

Dimension
A grouping of those evaluation groups (characteristics) that belong together, as regards contents, in one generic
term. With the definition of an InfoCube, characteristics are summarized into dimensions in order to store them in
a table of the star schema (dimension table). An InfoCube has no more than 16 dimensions, of which three are
standard (package, time, unit) and included in the sizing by default. You can therefore enter only 13 dimensions at
most.
Key figures
Values or quantities, such as sales revenue, fixed costs, sales quantity, or number of employees.
In addition to the key figures saved on the database, you have the option of defining derived (calculated) key
figures in the query definition in the Business Explorer. Such key figures are calculated using a formula from the
key figures of the InfoCube.
Examples of derived key figures are "sales revenue per employee" (sales revenue divided by number of
employees), "variance as a percentage", or "contribution margin".
Initial load & periodic load
Initial load: Specify the estimated number of records which you plan to load into the cube initially.
Periodical load: Specify the estimated number of records which are loaded in your periodical upload process. You
should take into account that you upload data volume grows with time.
Number of periods
Specify the total number of uploads which will be kept in the InfoCube. Example: if you want to keep weekly data
for 5 years, you should enter 260 (52*5)
BWA
Specify if this InfoCube should be replicated into BWA.
For more information on BWA sizing check SAP Note 917803.
% MD
Part of master data on total InfoCube size with the assumption data is the sum of master data and InfoCube data.
If you know that you have shared master data, you can enter "0" if you have already considered it once.
Distinct values
Average number of different values over all key figure columns.
% DVL
Percentage of key figures columns with very low number of distinct values (sparse).
% DV1
Percentage of key figure columns with one distinct value (super sparse).
Short text
If you have several different InfoCubes of the same type, use short text to attribute names in order to identify
them more easily.
DataStore Object Definition

DS OBJECT A DataStore Object serves to store consolidated and debugged transaction data at a document level (atomic level). It
describes a consolidated dataset from one or more InfoSources. This dataset can be analyzed with a BEx Query or
InfoSet Query.
A DataStore contains a key (for example, document number/item) as well as data fields that can also contain character
fields (for example, order status, customer) as key figures. The data of a DataStore Object can be updated with a delta
update into InfoCubes and/or other DataStore Objects in the same system or across systems. Write-optimized DataStore
objects serve as storage for an inbound data layer. While these objects provide much faster data load, they do not offer
delta information.
In contrast to multi-dimensional data storage with InfoCubes, the data in DataStore Objects is stored in transparent, flat
database tables.
Specifics for DataStore Objects

NumFld (Numeric fields)
Enter the number of numeric fields in the DSO
TxtFlds (Text fields)
Enter the number of text fields in the DSO
CharLg (Character length)
Enter the average length of character fields in bytes
WO (write optimized)
Flag, if DataStore Object is write-optimized.
Initial load
Enter the number of records initially loaded into the cube
Period. Upld (Periodic upload)
Enter the number of records loaded during the periodic upload process
Period
Enter the total number of uploads which will be kept in the InfoCube
Back to Top
SAP NetWeaver Process Integration
Sizing process Definition

Integration The current sizing procedure for SAP NetWeaver Process Integration (PI) determines the size of the Integration Server
(including the central Adapter Engine) and optional non-central Adapter Engines. Additionally, the size of an Advanced
Adapter Engine Extended (AEX) which is the Java-only deployment option up from PI 7.30 can be calculated. Resource
requirements for proxy applications on sender or receiver side are not taken into account.
The minimal requirements for the installation of SAP PI depend on the respective requirements for SAP NetWeaver
Process Integration 7.3. Details are available on SAP Service Marketplace at http://service.sap.com/instguidesNW73 .
Note
The results from both sizing tables (Integration Server and Adapter Engine sizing) are added up. Therefore, the
same scenario should not be entered in more than one sizing table. For an AEX deployment only the Adapter
Engine sizing table should be used.
Find more information about how to use SAP NetWeaver Process Integration 7.1 at SAP NetWeaver PI 7.1 in the
Quick Sizer, e.g. a Webinar.
Basic sizing information needed for PI:
Message size
Average size for XML representation of messages of a scenario. If the size for XML representation is unknown, you
can use the following guidelines to estimate the XML size:
- For flat files, calculate a factor of 10 for conversion to XML (multiply flat file size by 10).
- For IDocs, you can use the following approach: In a sender or receiver system, use the IDoc test tool
(transaction WE19) to write a sample IDoc to a file using an XML File port (or a File port if an XML File port is not
available); then use the file size as XML message size.
It is advisable to use quick sizing results for scenarios that include messages larger than 100 MB with great care.
These scenarios will not work in the default configuration and especially the memory requirements depend
significantly on several configuration and scenario details that cannot be considered in the Quick Sizer tool.
Therefore the Quick Sizer tool may overestimate memory requirements for these scenarios.
Number of messages
Peak number of outbound messages to be processed in a given timeframe for a scenario. For the Integration
Server, only messages sent out from the Integration Server are counted; for an Adapter Engine, AEX or using
integrated configurations in general, all processed messages must be counted. For peak load calculation it might
be helpful to distribute processing over time (e.g. by using batch functionality).
Processing mode
Synchronous or asynchronous processing mode determines how messages are handled in PI.
- Synchronous messaging means that a sender application has to wait until a message is delivered to a receiver
application, and that the receiver sends an immediate response like in a synchronous remote function call. This
applies to Quality of Service BestEffort.
- Asynchronous messaging means that a sender application sends a message to the Integration Server or Adapter
Engine and receives a technical OK that the message has been received; the sender does not wait for immediate
response by the receiver application. With this processing mode, the Integration Server or Adapter Engine needs
to store data and deliver the message later (asynchronously) to the receiver application. Asynchronous processing
is standard in PI and applies to Quality of Service ExactlyOnce and ExactlyOnceInOrder. If the mode is in order
processing (serialized), the Integration Server or Adapter Engine cannot make use of parallel processing
effectively.
Integrated Scenario
Beginning with version 7.1 Process Integration allows the use of integrated scenarios, also called integrated
configurations. These configurations bypass the ABAP based Integration Server and are executed on a central or
non-central Adapter Engine. For an AEX system, only integrated configurations are available. The resource
requirements for these scenarios are much lower than for classical scenarios, but they have a limited feature set
(no WS-RM Adapter, no use of ccBPM).
Business Process Management (optional)
Business Process Management (BPM) provides stateful message processing capabilities with PI. An integration
process is an executable cross-system process for the processing of messages, including process steps and
parameters relevant for process control. The status of an integration process is persisted on the Integration
Server. For sizing calculation, it is important to determine if messages of a scenario are handled by integration
processes in the Business Process Engine (BPE), the runtime component for process execution.
Memory sizing:
Memory sizing is based on the number of required CPU resources (SAPS value). Memory requirements increase as
additional Application Server instances (ABAP or Java) need to be installed. Additionally, individual memory requirements
by single messages due to their message size are considered. As result, the maximum for both memory requirements is
calculated. The number of parallel messages to be processed is derived from the given throughput value. Depending on
the type of adapter at least six to eight times the message size is required as memory for processing. Therefore,
available OS and Java heap limits must be taken into consideration.
Please note that memory sizing might overestimate memory requirements for several scenarios with large message sizes
(e.g. 50 MB) and low message volume, if it is possible to reach an equal or almost equal distribution of the different
scenario loads over the peak load time, because the Quick Sizer tool will sum up memory requirements for all scenarios
which is wrong if messages from several scenarios are processed sequentially (but is correct if they are processed in
parallel).
Advanced Sizing Definition

(Integration The Integration Server includes the basic processing components Integration Engine and Business Process Engine. Inside
Server) the Integration Server, the Integration Engine enables processing of XML messages. Additional protocols like IDoc, RFC,
PI-INT-SRV HTTP (plain) are supported by adapters. Adapters for processing the standard XI protocol (proxies), for IDocs, for the
plain HTTP protocol, and for the WS-RM protocol are implemented directly within the Integration Server. Additional
adapters are implemented in the central Adapter Engine as J2EE-based services.
Comment
The sizing information needed for advanced sizing of the Integration Server is the following:
Message size, Number of messages, Processing mode
Inbound Adapter
Inbound adapters receive requests from a sender application and are therefore also called sender adapters.
Available adapter types are:
- IDoc: Standard IDoc adapter.
- XI (Proxy): Standard XI message protocol (used within proxy communication) based on SOAP/HTTP.
- HTTP (Plain): Adapter for message exchange using the plain HTTP protocol. .
- WS-RM: Adapter for the Webservice Reliable Messaging protocol.
- J2EE: J2EE-based adapters (File, FTP, JDBC, JMS, RFC, SOAP, Mail).
- Industry Speak: B2B adapters (RNIF, CIDX).
- 3rdParty: Certified 3rd party adapters from partners.
Outbound Adapter
Outbound adapters send requests to a receiver application and are therefore also called receiver adapters.
The available adapter types are the same as for the inbound adapters.
Integrated Scenario
Integrated scenarios are executed locally on the central Adapter engine, but have a limited feature set.
BPM Processing
The sizing for cross component Business Process Management (ccBPM) is only a very rough estimate because the
process engine supports the modeling of arbitrary processes that can, of course, vary significantly in their resource
consumption and is done for process classes. Available classes are:
- Simple: Sample process with about 10 process steps, three inbound and one outbound message and two
mapping steps.
-.Medium: Sample process with about 30 process steps, nine inbound and one outbound message and six mapping
steps.
- Complex: Sample process with about 90 process steps, thirty inbound and one outbound message and about
twenty mapping steps.
Adapters are divided into different categories referring to the adapter type. Several adapters are grouped together in
subcategories as the sizing estimate is quite comparable (for example, J2EE-based adapters like File, FTP, JDBC).
Advanced Sizing Definition

(Adapter Engine An Adapter Engine or an AEX runs on the J2EE Engine. There may be any number of non-central Adapter Engines, each
Extended / Non- associated with exactly one Integration Server or AEX system. Non-central Adapter Engines communicate with the
Central Adapter Integration Server using the XI protocol. In an AEX environment, additional Adapter Engines run autonomous (using
Engine) integrated configurations). Each Adapter Engine has an own database (based on AS Java). All J2EE-based adapters can be
PI-ADAPTER used with this type of Adapter Engine. Classical scenarios involving the Integration Server on the non-central Adapter
Engine require the input of either an inbound adapter or an outbound adapter, integrated configurations require both.
Comment
The sizing information needed for advanced sizing of an AEX or non-central Adapter Engine is the following:
Message size, Number of messages, Processing mode
Inbound Adapter
- J2EE: J2EE-based adapters (File, FTP, JDBC, JMS, RFC, SOAP, Mail, IDoc, HTTP, XI).
- Industry Speak: B2B adapters (RNIF, CIDX).
- 3rdParty: Certified 3rd party adapters from partners.
Outbound Adapter
Outbound adapters send requests to a receiver application and are therefore also called receiver adapters. The
available adapter types are the same as for the inbound adapters.
Integrated Scenario
Integrated scenarios, also called integrated configurations are executed locally on the Adapter Engine. Note that
integrated configurations require the selection of an inbound and an outbound adapter.
Adapters are divided into different categories referring to the adapter type. Several adapters are grouped together in
subcategories as the sizing estimate is quite comparable (for example, J2EE-based adapters like File, FTP, JDBC). Only
adapters implemented in the J2EE Adapter Framework can be selected.
Back to Top
Application Server
Printed Definition
Documents Data storage medium containing information of a specific type.
BC-PRINT,
Specifics for the sizing element BC-PRINT
BC-USER
Enter the number of printed pages.
Comment
We assume that a page is always completely filled in and that the document is always completely printed. This considers
SAP script printing. Other print services such as Adobe print forms may require additional load. For more information
please check for the respective sizing guidelines.
Back to Top
NetWeaver Standalone Engines
Document Search Definition

Function (using The information retrieval system Text Retrieval and Classification (TREX) provides various software applications with
TREX) intelligent search, retrieval, and classification functions for documentation development. You can use TREX to search
TREX-SRCH extensive electronic collections of text documents flexibly, and to structure document classification in a way that gives a
clear overview of what is available. The TREX text-mining functions allow interesting and relevant information to be
extracted from text documents for the user.
In principle, TREX can process, search, and classify any file format that can be rendered as text. Filter software
integrated into TREX converts all current standard document formats (HTML; XML; DOC; TXT; RTF, and so on) into text.
Text documents in numerous European and non-European languages can also be processed by TREX. All central and
western European languages are supported, as are Korean, Japanese, and Chinese.
Find more information for TREX at the SAP Help Portal -> TREX.
Note
Enter the number of searches per time period.
Comments
For sizing TREX we currently consider only the search function on document data (HTML; XML; DOC; TXT; RTF,
and so on).
For Embedded Search, Enterprise Search, and other business search scenarios, follow the link provided in SAP
note 1266024 ‘Sizing TREX 7.1 for Embedded Search’.
Note that there is another acceleration engine available within the SAP NetWeaver BW: the BW accelerator. For
sizing this engine use the column ‘BWA’ within the SAP NetWeaver BW questionnaire.
Back to Top
SAP Solution Manager
SAP Solution Definition

Manager The SAP Solution Manager is a platform that provides the integrated content, tools, and methodologies that you need to
MAN-IMP-U, implement, support, operate and monitor your enterprise's solutions from SAP.
CHARM-U, With SAP Solution Manager, companies can minimize risk and increase the reliability of their IT solutions.
SERV-DES-U, SAP Solution Manager helps reduce TCO throughout the application life cycle.
SOLMAN-INI SAP Solution Manager helps companies manage their core business processes and link business processes to the
underlying IT infrastructure.
SAP Solution Manager supports both SAP and non-SAP software and helps companies get more from their existing
IT investments.
Find more information about the Application Life Cycle Management and the Solution Manager at
http://service.sap.com/alm .
Specifics for these sizing elements of the SAP Solution Manager

MAN-IMP-U (User in Solution Manager Implementation)
Enter the number of users with different user activity (low, medium, high).
CHARM-U (User in Solution Manager Change Request Management – a.k.a. CHARM)
Enter the number of users with different user activity (low, medium, high) which will use the CHARM functionality
in Solution Manager.
SERV-DES-U (User in Solution Manager service desk and ChaRM scenario)
Enter the number of users with different user activity (low, medium, high).
SOLMAN-INI (Initial Solution Manager Sizing)
This is a simple SAP Solution Manager sizing, which will be sufficient for most customers. The only input field that is
relevant for calculation is the number of managed systems attached to SAP Solution Manager. Together with
several assumptions the needed system size will be calculated out of this input.
Number of systems (columns '<XL S.', 'XL Sys.')
The number of systems connected to Solution Manager. So-called: “Managed Systems”. They are the
systems for which Root cause analysis (RCA) is activated. Those type of systems are actually
supported:
< XL : < 5000 sized up to 50 systems
(Note: Corresponding combinations are also sized, e.g. 10 XL + 25 <XL)
XL: 5000 – 50000 sized up to 20 systems
Robots:
The End-User-Experience-Monitoring (EEM) Robots. These “Robots” are Solution Manager Diagnostic’s
agents which execute on a regular basis scripts to simulate End-user activity and record the response
times from various locations around the world. It is not mandatory to make an entry in this field if you
do not use EEM.
Usage of Solution Monitoring (S.Mon):
Indicates if Solution Monitoring Scenario is supported.
Usage of Technical Monitoring (T.Mon):
Indicates if Technical Monitoring Scenario is supported.
XXL
Flag, if XXL systems are monitored in Solution Manager (> 50,000 named users).
Months (Mon.):
The number of months during which the technical monitoring data will be kept in the Business
Warehouse (BW) of Solution Manager. This parameter impacts directly the BW storage.
Note: If the number of systems is big or if one of the following columns is flagged
“XXL”: XXL managed systems attached to Solution Manager

“> 4 h”: managed systems with more than 4 virtual hosts attached to Solution Manager
“> 8 n”: managed systems with more than 8 virtual nodes attached to Solution Manager
The frame of this sizing approach is burst and we recommend a detailed sizing using the
documents you find at http://service.sap.com/sizing-solman. This toolkit will help you to
complete a detailed sizing of SAP Solution Manager taking into account landscape clustering
consideration.
Note: The base for this sizing is an XL system with 4 virtual hosts and 8 virtual nodes. This means that if
you use this sizing to size small systems the result will be slightly too high.
Definition
Solution Manager This represents the Business Process Monitoring scenario of Solution Manager. This scenario collects performance KPIs
Business Process for specific Business Processes.
Monitoring
Specifics for sizing element BP-MON
BP-MON
Business processes (BP)
This represents the number of Business Processes that will be described in the Business Blueprint or that will be
selected for Business Process Monitoring. This influences the necessary DB storage for Solution Manager.
Alerts:
Number of alerts produced per connected host.
Servers:
Number of hosts per system.
Systems:
Number of manager systems included in BP Monitoring scenario.
Months (Mon.):
The number of months that the service desk objects (incidents and so on) will be kept in the Database.
Definition
Solution Manager This section describes the usage of the Service Desk included in Solution Manager and is complementary to the SERV-
Service Desk DES-U entry. It describes how many users will be using the service desk for their daily work (entering incidents or
SERV-DESK problems for instance).
Specifics for sizing element SERV-DESK
You can enter several lines representing different types of users (Customer Interaction Center, or development support
for instance). By default there are two lines: one for the average usage and the other one for the peak usage. For each
line you can specify the following parameters:
Objects:
Represent the number of tickets (incidents, problems, messages…) that will be created during the specified time
period.
Months (Mon.)
The number of months that the service desk objects (incidents and so on) will be kept in the Database.
Back to Top
Expert Functions
Status "Final"
Final projects cannot be modified anymore.
Status "Inactive" You can use this function for projects that are not required anymore.
Inactive projects are not listed in your project list, if you search for all your projects (using your customer number and a
wildcard for the project name). Also, you cannot change the project or use it as original for a create-with-reference
procedure.
© Copyright 2012 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The
information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries,
System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix,
i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the
United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix
Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of
Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and
service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes
only. National product specifications may vary.
The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for
any purpose without the express prior written permission of SAP AG.
This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains
only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular
course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at
any time without notice.
SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information,
text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or
implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.
SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result
from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.
The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access
through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty
whatsoever relating to third-party Web pages.

Sizing FAQ

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sizing FAQ

Uploaded by

Copyright:

Available Formats

SAP Quick Sizer Help Page 1 of 59

Quick Sizer Online Help Version 27

SAP In-Memory Computing

SAP BusinessObjects Portfolio

SAP Customer Relationship Management

CRM Master Definition

Changed Acc (Changed Accounts)

Displayed Acc (Displayed Accounts)

CRM Sales In the Quick Sizer CRM Sales covers

CRM Sales - Definition

CRM Sales - Definition

CRM Sales - Definition

CRM Sales - Sales Definition

CRM Sales - Sales Definition

CRM Sales - Definition

CRM Sales - Sales Definition

Definition Sales Contract Quotation

CRM Service In the Quick Sizer CRM Service covers

CRM Service - Definition

CRM Service - Definition

CRM Service - Definition

CRM Service - Definition

CRM Service - Definition Complaints and Returns Management

CRM Service - Definition

CRM Service - Definition Service Contract

CRM E-Commerce Definition

CRM Interaction Definition

CRM Interaction Definition

CRM Mobile - Definition

CRM Marketing Definition

CRM Marketing Definition

CRM Marketing Definition

SAP Web Channel Experience Management

Shopping Carts in Definition

SAP ERP Financials

Controlling Definition of CO documents

Posting from Posting to Number of line items

Postings into CO, for example

Profit Center Definition

assessment S-R = number of senders * number of receivers

Overhead Rates & Definition

EDR Upload Definition

Specifics for this sizing element for CPU Sizing

EDR Billing Definition

Upload of Billing Definition

Specifics for this sizing element for Disk Sizing

Payment Run Definition

Payment Lot Definition

Deferred Revenues Definition

SAP ERP Human Capital Management

If ESS/MSS is used without Portal integration, the flag should be unchecked.

Note for usage of Web Dynpro ABAP

Employee Self- Definition ESS

ESS - Small Specifics for ESS-SMALL Payslip

ESS - Large Specifics for ESS-LARGE Travel Expenses

MSS - Small Specifics for MSS-SMALL CICO (Clock-in/Clock-out on behalf)

MSS - Medium Specifics for MSS-MEDIUM CATS Approval

MSS - Large Specifics for MSS-LARGE Manager Homepage

Time Evaluation - Definition

SAP E-Recruiting Definition

Validity of Quick Sizer for SAP E-Recruiting:

Portal Sizing Not included:

Distributed Candidate Scenario:

Overview of SAP E-Recruiting Scenarios:

10 + 3005 + 3001 = 1.810