Quick Sizer Guide For SAP

SAP Quick Sizer Help Page 1 of 76
Table of Content
SAP Business Suite

CRM
ERP
Financials
Human Capital Management
Logistics Execution
Product Development & Execution
Sales & Service
Corporate Services
Supply Chain Management
Demand Planning
Supply & Production Planning
Order Fulfillment
Inventory Collaboration Hub
Integration to ECC
Extended Warehouse Management
Extended Warehouse Management - Inbound
Extended Warehouse Management - Outbound
Supplier Relationship Management
Global Trade Services
Compliance and Customs Management
Risk Management Preference Processing
Industry Solutions
SAP for Banking
Analytical Banking
Core Banking
https://websmp202.sap-ag.de/~sapidb/011000358700000519272005E 10/30/2007
Insurance
Retail
Utilities
NetWeaver
Portal
Business Intelligence
Process Integration
Application Server
NetWeaver Standalone Engines
Expert Functions
The sizing elements from the questionnaires are written in italics.
Customer Relationship Management
Note for IPC Handling

CRM in the The current Quick Sizer version is based on SAP CRM 5.0. SAP NetWeaver Application Server ABAP includes the software
Quick Sizer component Internet Pricing & Configurator (IPC), but the Quick Sizer result currently does not. Therefore, you have to size
IPC with the sizing guideline Sizing the Internet Pricing & Configurator and add the result to the Quick Sizer result.
In former CRM releases, the IPC was a separate component which was also installed separately.
Activity Definition
Management Within Activity Management, your employees can:
ACT-USER Create business activities to document any interaction they have with customers
CRM-ACT 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 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. The inbox, on the other hand,
provides you with a personal workplace or file manager, where all your activities, whether they have been given fixed
appointments or not, are clearly sorted into different folders.
Activities often are some kind of follow-on actions, for example a follow-up call after an initial sales conversation with a
customer.
Changes to an activity are regular. Make sure you include this information in the sizing.
Comments
Users are very rarely entered in this component because they are usually more involved in order processing or
opportunity processing. Therefore, you should attribute users to these components rather than to Activity
Management.
Note that attached documents (typically PC type documents such as text files, presentations, or documents in print
format) which are uploaded into CRM are not considered in this approach.
Opportunity Definition
Management The Opportunity describes the sales prospects, their requested products and services, the sales prospect’s budget, the
OPP-USER potential sales volume and an estimated sales probability. This information becomes concrete in the course of the sales
CRM-OPP cycle, and can be displayed and evaluated in the system.
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
Comment
Make sure you (determine and) enter the number of times the opportunities are displayed or changed (in percent).
This is important for the sizing because the typical lifecycle of an opportunity includes several changes (for example
the status or phase) as well as several display actions (for example, to check the ongoing status or the final
success).
Note that attached documents (typically PC type documents such as text files, presentations, or documents in print
format) which are uploaded into CRM are not considered in this approach.
Internet Sales Definition

CRM-ISA Internet Sales: This component allows electronic business activities to take place between companies and consumers as
well as only between companies. Using SAP Internet Sales, manufacturers, shippers, wholesalers, and retailers can sell
their products directly via the World Wide Web. The following components are contained in CRM Internet Sales:
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
Browsing the Shop visits
Catalog and Number of visits to Internet shop (a visit normally consists of about 15 steps)
Placing Orders % ord.
Percentage of visits that lead to orders
Items
Average number of line items/sub objects per order/object
CLP
If checked, 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. While most of the users will not fill the shopping basket or order products, there are of course a percentage of
users who will put products into the shopping basket and place an order.
Enter the number of user visits to the shop and also specify how many percantage of the visits will lead to an order. This
varies for the different Internet Sales scenarios (B2C, B2B, …). For B2C typically 10% of the visits lead to an order.
Service Definition
Transactions You can use the component Service transaction to represent business processes in the service area in your company.
SRV-USER Service transactions can be entered in the following ways.
CRM-SRV By an employee in the CRM System
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
Service Order 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:
Services
Spare parts
Products
Prices
Billing data
Customer Definition
Interaction Center The Customer Interaction Center (CIC) is a key technology of Customer Relationship Management with the SAP Business
IC-USER Suite. It is designed as a multi-channel, blended business process interaction center to empower call centers to provide
the highest level of customer service. It provides robust technology for contact center operations. It tightly integrates a
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
phone, email, letter or face to face. It’s 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
For user-based sizing we assume that the CIC creates additional load. Basic load is created by the business transactions
called through CIC, such as Opportunity Management, Activity Management, Customer Order, and Service Transaction.
Therefore we recommend you enter a CIC user in the line for CIC as well as in the line of the respective business
transaction.
To reflect CIC orders in the Quick Sizer use the line for customer orders and add the number of calls.
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.
CIC Emails and Definition

Calls Enter the number of incoming and outgoing emails and calls. Note that business objects created during a call, such as a
IC-CALL customer order or a service order must be entered separately. This equally applies to business objects that are displayed
or changed during that call. Make sure you specify this in the columns for display and changes for the respective objects.
Note that only objects created or changed in CRM need to be considered. 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. But
consecutive load in systems other than SAP CRM are not in the scope of this sizing. Therefore, activities may very well
produce load in systems other than SAP CRM. 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.
Mobile Sales and Definition

Service In general, the Mobile Sales users will upload their data to the CRM system in a time frame of a few hours in the evening.
MSA-USER Enter the highest number of users you expect to login within one hour.
CRM-MSA
Mobile Sales allows sales teams to work offline and to synchronize their data with the backend system. In this way, it
supplies all the information required for optimal customer interaction. Such information can include real-time updates on:
Business partners
Contact persons
Products and services
Opportunities
Activities
This component contains functions 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.
Note
Here you can also enter users who use Handheld Sales and Handheld Service.
Customer Orders Definition

SLS-USER In CRM, customer orders can be created in different ways, for example by a telesales agent in the Call Center or by
CRM-SLS customers via the Internet. Directly created orders in CRM Online are included here as well.
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.
Back to Top
Enterprise Resource Planning

Back to Top
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 Intelligence with its Strategic Enterprise Management comprises the functions that were formerly accounted for
by Enterprise Controlling.(see Business Intelligence)
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

Posting activity calculation to Number of line items
from
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 planning,
CO-PA-SLS 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
Human Capital Management
Personnel Definition
Administration & Personnel Administration and Payroll Accounting from the Human Resource (HR) component includes the following areas:
Payroll Personnel Administration, Benefits, Compensation Management, Recruitment, Personnel Time Management, Incentive
Accounting Wages, Business Trip Management and Payroll Accounting.
PA-USER
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, Sunday
HCM-PT and public holiday work). Assumption: Time Evaluation is processed every working day.
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
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
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
ICM-DOC Number of documents

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
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 BI 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 BI 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 be
Timeseries 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 product-location 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, you
liveCache Memory have to decide whether sub locations will be included in the planning process. These can be as detailed as shelf and
STOCK 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
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 product-location
SAP liveCache
combinations, with a forecast that is released from Demand Planning to Supply Network Planning. Each product-
Memory
location 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 APO
TRANSFER 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 heuristic
SNP HEUR
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
Inventory Collaboration Hub
Inventory Sizing assumptions and principles

Collaboration Hub
In the ICH sizing we cover the Supplier Managed Inventory (SMI) scenario which shifts the responsibility for inventory
planning from the manufacturer to the suppliers.
SMI enhances demand and inventory visibility for the suppliers by using the internet and helps to manage the
replenishment process. Suppliers can see the status of their parts at all plants, receive automatic alerts when inventory
levels get low, and respond quickly via the web.
SAP SCM immediately integrates the latest inventory and replenishment information with back-end transaction and
planning systems, so all parties remain up-to-date.
Sizing Elements We size the disk and the CPU requirements in order to process and to store the messages.
Specifics for Location Products

APO - Location
Products Master Data: We ask for the number of locations used in ICH.
ICH MD
APO - Message Specifics for Message Processing with Periods - CPU

Processing with ICH DS (Delivery Schedule Notification): A message from the buyer to the supplier. The delivery schedule
Periods - CPU notification contains product net demand information (“forecast demand”) and/or product release information, either
ICH DS for short term and/or for medium to long term product scheduling
ICH PROACT (Product Activity Notification): The "Product Activity Notification" may contain inventory and time
ICH PROACT series data, such as sales, sales forecasts, promotion sales forecasts or consumptions. Inventory and time series
data refer to a given product and location.
APO - Message Specifics for Message Processing - CPU

Processing - CPU ICH ASN (Advanced Shipping Notification): A message from the supplier to the buyer. The purpose of the
ICH ASN "Dispatched Delivery Notification", also called Advance Shipping Notification, is to notify the consignee that a
delivery has been planned and assigned. The task includes to communicate at the detailed product level the
contents of this delivery, when the delivery is expected to arrive, and other delivery information.
ICH GR (Goods Receipt Notification): A message from the buyer to the supplier. The purpose of this message is
ICH GR to notify the shipper that a delivery has been received and to report the status on a delivery as well as on delivery
content level, i.e. on a detailed product level.
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 - CPU number of line items refers to the average number of components in the production order.
PI-PROD Sales orders: This refers to the number of sales orders transferred from/to the ECC system. The number of line
items refers to the average number of schedule lines in the sales orders.
PI-SALES Purchase orders: This refers to the number of purchase orders or purchase requisitions transferred from/to the
ECC system. The number of line items refers to the average number of schedule lines in the purchase order.
PI-PURCH Stock movements: This refers to the number of stock movements transferred from/to the ECC system. The
number of line items is always 1. Enter 1 in the column for line items.
PI-STOCK
Back to Top
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.
Back to Top
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
Example
During the peak hour the following process steps are executed in the system:
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
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

Outbound Step - Wareh. Tasks: Number of warehouse tasks with resource changes
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 Example 100 outbound delivery orders with four items on average are created based on messages received from ERP.
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
Supplier Relationship Management
SAP Supplier Definition

Relationship SAP Supplier Relationship Management provides you with innovative methods to coordinate your business processes with
Management (SAP your key suppliers and make them more effective. SAP SRM enables you to optimize your procurement strategy, to work
SRM) more effectively with your vendor pool, and thus to gain long-term benefits from all your vendor relationships.
With SAP SRM you can examine and forecast purchasing behavior, shorten procurement cycles, and work with your
partners in real time. This allows you to develop long-term relationships with all those vendors that have proved
themselves to be reliable partners.
The efficient processes in SAP SRM enable you to cut down your procurement expenses and to work more intensively with
more vendors than ever before.
SAP Supplier Definition

Relationship The SAP Supplier Relationship Management Server (SAP SRM Server) includes both SAP Enterprise Buyer and SAP Bidding
Management Engine.
Server
SAP Enterprise Buyer is based on SAP NetWeaver Application Server (AS). It is an application and database instance
installation released on several database and operating system platforms (see SAP Service Marketplace at
service.sap.com/platforms -> Product Availability Matrix. It enables easy, full-cycle, inter-enterprise procurement. With it
you can:
Create and process requirement requests, purchase orders, and reservations with or without electronic catalogs
Approve and reject purchases
Receive and enter service information at the desktop
Use status, invoicing, and reporting functions
SAP Enterprise Buyer is the procurement and sourcing system that is the central part of any SAP SRM scenario. It
empowers employees with self-service procurement, enables centralized direct procurement and provides the professional
purchaser with tools to make the right sourcing decisions.
The SAP SRM solution requires the SAP Enterprise Buyer system for downloading materials data and (optionally)using the
Business Intelligence capabilities offered by SAPNetWeaver.
Purchasers can use SAP Bidding Engine to create and process bid invitations, and bidders can use SAP Bidding Engine to
submit bids in response to these bid invitations. Both purchasers and bidders can use reverse auction functions in a
separate Live Auction application. Purchasers can define rules pertaining to bidding and bidders can submit bids in real
time.
Note
The sizing result for the SAP SRM Server includes sizing of SAP ITS.
Contract Description
Management The Contract Management business scenario allows you to create, process, and monitor purchasing contracts and global
CTRCT-USER, outline agreements (GOA). It also provides a means to renegotiate existing contracts directly with the vendor or by
SRM-CNTRCT creating a bid invitation. A contract can be automatically assigned as a source of supply or displayed as a possible
selection.
A strategic purchaser creates a contract or a GOA whenever a long-term relationship is anticipated and the vendor can be
considered as a source of supply. Contract management enables purchasers from various parts of the company at different
locations to take advantage of the terms of globally-negotiated contracts for specific product categories.
You can provide users with specific levels of authorization to contracts and GOAs, and also categorize these documents as
confidential. You can distribute a GOA to the release-authorized purchasing organizations and these organizations can use
the contracts and scheduling agreements created from the distributed GOA. You can use hierarchies to organize, structure,
display, and search for your contracts.
If you use SAP Business Intelligence (SAP BI), you can view various consolidated reports of contract management. For
example, you can view the aggregated value released against all the contracts in a contract hierarchy.
Typical tasks for the Contract Management business scenario include:
A strategic purchaser negotiates a long-term contract with a vendor to deliver goods of a specific commodity.
A strategic purchaser monitors contract compliance.
An operational purchaser searches for applicable contracts within a central contract database and puts contracts into
effect.
The Quick Sizer scenario includes the business objects Purchaser Order and Contract.
Plan-Driven Definition
Procurement Plan-Driven Procurement automates and streamlines ordering processes for regularly needed core materials. You can use
PLAN-USER, this business scenario to procure requirements for materials that have been generated in systems other than SAP Supplier
SRM-PLAN Relationship Management (external systems). By integrating the SRM System with planning, design, and maintenance
systems, you can accelerate your procurement and integrate the operational procurement with your Supply Chain
Management solution. The business scenario supports third-party order processing, a special kind of procurement. Here
the product goes directly from the vendor to the customer of the purchasing company. The purchase order to the vendor
contains the necessary information for this.
You can set up the business scenario in such a way as to link one or more Materials Management systems (SAP-MM) with
Materials Requirements Planning (SAP-PP-MRP) to one or more vendor systems (SAP Supplier Self-Services).
You can continue to plan requirements in SAP Advanced Planner and Optimizer (SAP APO).
Examples of tasks for Plan-Driven Procurement include:
A manufacturing company with many disparate planning systems consolidates all procurement (direct and indirect)
in one e-procurement hub.
A company performing planned and unplanned maintenance centralizes procurement activities in a single
application.
The Quick Sizer scenario includes the business objects Shopping Cart, Purchaser Order, Purchase Order Confirmation,
Confirmation and Invoice.
Self-Service Definition
When using Self-Service (Indirect) Classic Procurement solution, employees use a self-service application to select items
Classic
such as office material, for example, from a catalog and add them to a shopping cart in the EBP system. When the
Procurement
shopping process has finished, the shopping cart is transferred to an SAP R/3 Material Management (SAP MM) backend
CLASSIC-U,
system where it is further processed in the form of a purchase order.
CLASSIC
Note
Note that you must account for the orders processed in MM and possible follow-on documents separately so that the
backend system is sized properly. The backend systems being in these cases both MM and FI backend systems.
Self-Service Definition
Both scenarios, Extended Classic Procurement and Standalone Procurement, can be sized with the same methodology.
Extended Classic
Procurement & Extended Classic Procurement
Standalone
Whereas in the Classic Procurement scenario, all materials management takes place in the backend system, with this
Procurement
scenario the shopping cart and purchase order are created locally. If the data in the shopping cart is insufficient to
EXT-USER,
generate a complete purchase order, the data is supplemented manually within Enterprise Buyer before being transferred
EXTENDED
to the backend system. The purchase order in Enterprise Buyer is the leading purchase order. The version that is
transferred to the backend is not an exact copy, rather it is a much leaner version of the leading purchase order, a read-
only copy. This copy supplies the reference needed for the creation of goods receipts, service entry sheets, and invoices in
the backend system. Confirmations and invoices can also be pre-entered in Enterprise Buyer.
Standalone Procurement
This scenario handles the entire procurement process in Enterprise Buyer: The shopping cart and follow-on documents are
created locally. You have no materials management in your ERP system and are using the Materials Management functions
in the Enterprise Buyer system for all procurement. Accounting processes (incl. FI, CO and AM) must still be handled by a
backend system. All validations and approvals are handled directly within Enterprise Buyer rather than in a backend
system. Migration tools are provided to bring materials management data from SAP backend systems into the application
product master.
Note
If you want to size both scenarios, just add the figures or, if they differ to a great extent, create a new sizing
project
Note that you must account for any follow-on documents or objects processed in the backend system separately.
The backend systems being in these cases both MM and FI backend systems.
The Standalone Scenario can be deployed using single or multiple FI backend systems. Or alternatively, in the case
of a marketplace scenario no FI backend system is necessary.
Strategic Sourcing Definition

SOURCE-USER, You can use this business scenario to process all your requirements and optimize your source of supply for each individual
SOURCING item. You can identify cost-saving opportunities and evaluate suppliers’ ability to provide materials and services at low
cost, high quality, and on schedule. Once you have determined the best source of supply for your requirements, you can
collaborate in project teams both internally and with your suppliers to establish on-going relationships based on contracts
and global outline agreements.
Sample tasks for the Strategic Sourcing business scenario include:
A company locates different suppliers for upcoming new product development.
A financial institution maintains lists of suppliers for different maintenance, repairs, and operation (MRO) materials.
A consulting company reduces its supplier base by aggregating airline tickets to one airline.
The Quick Sizer scenario includes the business objects Bid Invitation/Auction, Bidders and Quotation.
Service Definition
Procurement You can use this business scenario to cover the entire service procurement process. Before ordering external staff or
SERVC-USER, services, you can send a request to one or more suppliers for detailed information on a specific service or the availability of
SRM-SERVIC individual service agents, for example. After receiving the suppliers’ responses and accepting one of these bids, the
corresponding purchase order is automatically created. Next, time and expenses have to be entered into the system and,
finally, the invoice is created.
You can integrate your suppliers into the procurement process by connecting a supplier system like Supplier Self-Services
to your procurement system. In this way, the service agents can enter services performed and create invoices for these
services. You have to approve all documents created by your suppliers and you always retain a complete overview of all
business processes.
The Quick Sizer scenario includes the business objects Shopping Cart, Purchaser Order, Purchase Order Confirmation,
Confirmation and Invoice.
Note:
If you also want to size sub-items, simply add them to the number of items and insert this number in column "items".
Back to Top
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. SAP
GTS) Risk Risk Management – Preference Processing assists exporters in determining whether all the prerequisites for preferential
Management customs duty rates have been fulfilled. Exporters can obtain a competitive advantage over competitors due to reduced or
Preference zero rates of customs duty on goods with preferential origin for the importing customer. For SAP Risk Management the
Processing Scenarios GTS-BP and GTS-MAT are to be included in the Sizing projects as common master data is used. For the purpose
GTS-RI-BOM, 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 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 BI (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
Insurance
SAP Financial Services - Collection & Disbursement
Subledger Definition
Document & A subledger document consists of one header with 1...n Business Partner items (e.g. receivables, payables) and 1..m
Payment General Ledger items. A payment document is a subledger document which represents a payment from/to the customer.
Document In the most common case the payment documents are directly cleared against open items and point to the Business
SUBLEDGER Partner item of the cleared item. Therefore payment documents normally don't create physical entries for their Business
Partner items in the database.
Enter the total number of subledger documents to be created per year in the field "Postings", enter the total number of
payment documents to be created per year in the field "Payments". Specify additionally the average number of Business
Partner items per posting document and the average number of General Ledger items per posting and payment document.
Invoice and Definition
Account Note: We assume that the invoices and account statements are printed.
Statement
ACC-STAT
Dunning Definition
DUNN The number of dunning notices that are produced. Note: We assume that the notices are printed. The calculation includes
the dunning proposal run, the dunning activity run, and the print run for the dunning procedures.
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 Lot Item Definition

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.
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.
Payment Run Definition

PAY-RUN The process during which for all open items which are selected by the payment run, payment documents are created and
cleared against the due items. The data which is created with the payment run is also the bases for the creation of the
payment media (e.g. bank files). Enter the number of open items.
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.
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
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 Retail Questionnaire within the Quick Sizer

Retail in the Quick This questionnaire contains input fields which must be filled with the results you get with the help of the retail sizing
Sizer questionnaires (Sizing SAP Retail Questionnaire, Sizing Forecast and Replenishment, Sizing SAP POS Data 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 retail
Aggregation in sizing questionnaires (Sizing SAP Retail Questionnaire, Sizing Forecast 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, Forecast & Replenishment (R-FR)
R-MASTER When sizing for a forecast 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 Forecast &
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 BI. As such, the sizing of POS DM is considered as a delta-sizing of a BI-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.
Back to Top
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 the
Background utility service is cancelled.
Sizing)
MOVE IN
MOVE OUT
Back to Top
Portal
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 the assumptions for each scenario.
NW-EP-PRT 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 BI backend system (Java iViews).
A NetWeaver BI (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.
NetWeaver Portal for custom-defined scenario
You should use this scenario if you have more detailed information available on the Portal usage by specifying not
only the users and the think time, but also the different numbers and types of iViews in different custom application
scenarios. To reflect different scenarios, use the insert button to create any number of scenarios.
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 Java iViews on an average Portal page
Specify the number of Java iViews of a typical Portal page of a specific scenario. A Java iView retrieves business
content from back-end systems via JCo/RFC and renders the unformated business content in HTML.
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.
Percentage of requests using Knowledge Management & Collaboration (% KMC)
Enter how many clicks out of 100 access KMC content.
Maximal number of logons per hour
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 the
Active Users -
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 users
NetWeaver Portal
(e.g. 1,000 logons per hour).
Logon
NW-EP-LOG
Back to Top
Business Intelligence
SAP NetWeaver Find information about SAP NetWeaver Business Intelligence at the Service Marketplace -> Business Intelligence, for
Business example information about Performance Tuning.
Intelligence
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
Planning 1, the types of planning functions they execute. If you are not sure exactly how many data are involved, you can take the
Planning 2, proposed values, which are based on internal measurements and customer feedback.
Planning 3
Specifics for User Groups Business Planning
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 BI server must be sized separately. However, the sizing
result includes the part of NetWeaver BI that is used to deliver the transaction data to "User Groups Business
Planning". For sizing the load generated on the NetWeaver BI system by "User Groups Business Planning" we
assume that 30% of all executed planning steps access NetWeaver BI. For the remaining 70% of the planning steps
we assume that they manipulate data records which have already been read by NetWeaver BI.
BI Users Definition
BI-INFO, In NetWeaver BI, we distinguish roughly between user types according to their frequency of activity and the reporting they
BI-BUSIN., will normally do.
BI 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
BI 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 BI environment is 71% : 26% : 3% (Information
Consumer : Business User : BI Expert).
Comment
The system automatically calculates the Java parts which are shown at the result level.
If BI Java is not used, you should add 5 % to the SAPS of the application server.
Definition
User Groups
Collection of a selection of characteristics and key figures (InfoObjects) for the analysis of the data of an InfoProvider. A
Reporting &
query always refers exactly to one InfoProvider, whereas you can define as many queries as you like for each InfoProvider.
Analysis
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
BI Expert 0% 0% 100% 100%
Data Upload Definition

UPLOAD In this section you can specify how many records you need to upload within your peak time interval.
InfoCube Definition
INFOCUBE The central objects upon which reports and analyses in NetWeaver BI 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-HCM 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 BI.
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)
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.
In contrast to multi-dimensional data storage with InfoCubes, the data in DataStore Objects is stored in transparent, flat
database tables.
Back to Top
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/or additional non-central Adapter Engines. 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
Application Server (AS) 7.0. Details are available on SAP Service Marketplace at http://service.sap.com/installnw70 .
Comment
There are two different approaches:
Initial Sizing requires only basic knowledge about the PI architecture and the used scenarios.
Advanced Sizing requires advanced knowledge about the PI architecture and the used scenarios.
You can combine both approaches to obtain sizing figures for generic and detailed scenarios.
Note
The results from all sizing tables (initial sizing, advanced Integration Server sizing, and advanced non-central Adapter
Engine sizing) are added up. Therefore, the same scenario should not be entered in more than one sizing table.
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.
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 a non-central Adapter Engine, 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 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 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 you use this mode in order processing (serialized), the
Integration Server cannot make use of parallel processing.
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. Within the sizing procedure, BPM
usage is categorized in predefined BPM patterns (see process definitions in software component SAP_BASIS for
namespace http://sap.com/xi/XI/System/Patterns in the Integration Repository).
Disk sizing:
The Quick Sizer result includes an offset for the initial system setup (installation) and additional disk requirements per day
(calculated by scenario timeframes) driven by temporary storage of messages. The needed database size then depends on
the residence period for the data. In general, processed messages should be archived and/or deleted on a daily basis.
Asynchronous messages are calculated to use two persistence steps (message is persisted twice). If data is persisted more
than twice by activating logging, additional disk space will be required.
Memory sizing:
Memory sizing is based on the number of required CPU resources (SAPS value). Memory requirements raise 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 or mapping, at least six to eight times the message size is required as memory for processing. Therefore,
available OS heap limits must be taken into consideration. Use of 64-bit environments is strongly recommended. For more
information, see SAP Service Marketplace at http://service.sap.com/installnw70 → Operations → Process Integration →
Tuning Guide.
Initial Sizing Definition

PI-INITIAL Initial sizing is based on an exemplary PI scenario that is very common at customer side. This basic scenario uses the IDoc
adapter (asynchronous) or the proxy interface (synchronous) and a J2EE-based adapter provided by the Adapter Engine.
Message mapping is also included in the scenario. As additional input, a percentage value for BPM processing can be added
(meaning the percentage of messages that require BPM processing).
Comment
The scenario for initial sizing includes the following:
IDoc adapter in/outbound processing (asynchronous)
The IDoc adapter transforms IDoc binary data to IDoc-XML format.
Proxy in/outbound processing (synchronous)
Proxies are generated components (defined in the Integration Repository) used for message exchange with PI.
J2EE-based adapter in/outbound processing
J2EE-based adapters are, for example, the File, FTP, JDBC, and JMS adapter.
Message mapping
Mapping maps a source structure to a target structure.
BPM percentage (percentage of messages handled by integration processes)
Typically refers to asynchronous scenarios; for synchronous processing mode, BPM uses the SyncAsyncBridge
pattern.
TREX
The Search and Classification engine (TREX) provides various software applications with intelligent search, retrieval,
and classification functions. With PI, TREX can be used for Payload-based Monitoring. Cost calculation for monitoring
on one component is included.
As IDoc processing is possible only in asynchronous processing mode, a proxy interface was used in the sample scenario
for synchronous processing.
Advanced Sizing Definition

Advanced sizing allows to create individual scenarios beyond the predefined initial sizing scenario. Therefore, advanced
sizing requires additional knowledge about the PI architecture and processing capabilities. It is divided in two categories.
One category refers to sizing the Integration Server including the central Adapter Engine. The second category refers to
sizing a non-central Adapter Engine with an own database.
Comment
Additional non-central Adapter Engines can be used for several reasons. For example, if you use independent network
zones or for performance considerations in order to distribute and control the processing of specific interfaces.

(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, and for the
plain HTTP 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
Content-Based Routing (CBR)
CBR requires access via XPATH expressions to the message payload or document. XPATH is a Web standard for
navigating in XML documents. As input, the number of Routing conditions for a scenario needs to be entered.
Mapping Type
Mapping maps a source XML structure to a target XML structure. There are different mapping types available:
- Mapping Tool: Graphical mapping tool which generates Java mapping classes.
- XSLT Mapping: This type of mapping uses the J2EE Engine’s standard XSL Transformation processor.
- Java Mapping: User defined java class for mapping transformation.
- Value Mapping: Additional use of value mapping in the Mapping Tool. Mapping rules for different objects are stored
in value mapping tables (requires DB access during mapping).
Acknowledgements
Acknowledgements enable the confirmation that an asynchronous message has been received. Acknowledgements
must explicitly be requested by an application. Acknowledgements require that additional messages are transferred.
BPM Pattern
Specific usage types for ccBPM are defined as BPM patterns in the Integration Repository. In general, resource
consumption of BPM processes depends on the complexity of the process design and the resulting number of
process steps. Typically, process steps for receiving messages require more resources than process steps for
sending messages due to correlation evaluation (correlations are used to assign messages that belong together to
the same process instance). Most BPM scenarios are asynchronous scenarios (except the SyncAsync pattern).
Available BPM patterns:
- Collect: Collects messages and merges them into one message.
- Multicast: Sends one message to a receiver list and receives response messages.
- Serialize: Serializes a number of messages.
- Split: Splits one message into several messages.
- SyncAsync: Synchronous to asynchronous bridge.
- Other: Generic BPM scenario based on message forwarding (receive to send ratio 1:1, receive and send one
message); includes additional process steps.
BPM Ratio
The BPM ratio is used to adapt or configure specific BPM patterns (if no value is entered, an internal default is
used):
- Collect: Defines the average collect factor; specify 10 for a 10:1 merge (merge 10 messages into 1 message).
- Multicast: Defines the average number of receivers; specify 5 for an average of 5 receivers per process execution.
- Serialize: Defines the average number of serialized messages; specify 3 for serialization of 3 messages per
process execution.
- Split: Defines the average split factor; specify 10 for a 1:10 split (split 1 message into 10 messages).
- SyncAsync: Not relevant for this pattern.
- Other: Defines the average number of additional process steps per process execution.
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.
- J2EE: J2EE-based adapters (File, FTP, JDBC, JMS, RFC, SOAP, Mail).
- J2EE w/conversion: J2EE-based adapters including content conversion (for example, conversion of flat files to
XML).
- 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.
TREX
and classification functions. With XI, TREX can be used for Payload-based Monitoring. Cost calculation for monitoring
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).

(Non-Central A non-central Adapter Engine runs on the J2EE Engine. There may be any number of non-central Adapter Engines, each
Adapter Engine) associated with exactly one Integration Server, with which the Adapter Engine communicates using the XI protocol. The
PI-ADAPTER Adapter Engine has an own database (based on AS Java). All J2EE-based adapters can be used with this type of Adapter
Engine.
Comment
The sizing information needed for advanced sizing of a non-central Adapter Engine is the following:
Message size, Number of messages, Processing mode
Acknowledgements
Acknowledgements enable the confirmation that an asynchronous message has been received. Acknowledgements
must explicitly be requested by an application. Acknowledgements require that additional messages are transferred.
Adapter Type
- J2EE: J2EE-based adapters (File, FTP, JDBC, JMS, RFC, SOAP, Mail).
- J2EE w/conversion: J2EE-based adapters including content conversion (for example, conversion of flat files to
XML).
- Industry Speak: B2B adapters (RNIF, CIDX).
- 3rdParty: Certified 3rd party adapters from partners.
TREX
and classification functions. With XI, TREX can be used for Payload-based Monitoring. Cost calculation for monitoring
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.
PI Sizing Example
Examples This section describes some sizing examples derived from customer projects.
Split Process Scenario

A backend system sends material master data IDocs to the Integration Server. Within the Integration Server, a BPM split
process is defined to split the IDoc on record level. Single records are transferred using the JMS adapter with content
conversion to a legacy system.
Scenario Details:
Average message size of split messages is 1 kB
Peak load during one hour is 10.000 split messages
Asynchronous processing mode is used
In a Quick Sizer project, enter:
- 1 as XML message size
- 10.000 as number of messages
- Asynchronous as processing mode
- BPM pattern Split
- BPM factor 16
- Inbound adapter type IDoc

- Outbound adapter type J2EE w/conversion
Comment
Average customer message sizes are between 50-100 kB.
A typical business process is as follows:
- Backend system sends sales order IDocs via RFC
- Use predefined mapping to transform IDoc-XML to other XML format
- XML message is converted to flat file and transferred via FTP adapter to legacy system
Back to Top
Application Server
Printed Documents Definition

BC-PRINT Data storage medium containing information of a specific type.
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.
Business Definition
Workplace The Business Workplace provides a standard working environment in which every SAP user can carry out their share of the
BWP business and communication processes in the enterprise. There, they receive all the work items that are assigned to them
in the course of SAP Business Workflow and process the documents that were sent to them from people or from SAP
applications.
This can include the following actions:
Processing work items
Receiving and sending mails
Administrating documents and work processes
Distributing and processing companywide and group internal information
Comment
- In line BWP enter the number of lines per mail in the field for sub components.
- In the lines for the emails enter the number of recipients for external and internal mails in the field for sub components.
Back to Top
NetWeaver Standalone Engines
Search function Definition

(using TREX) The information retrieval system Text Retrieval and Classification (TREX) provides various software applications with
TREX-SRCH intelligent search, retrieval, and classification functions for documentation development. You can use TREX to search
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.
Comment
For sizing TREX we currently consider only the search function.
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 2007 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.

Quick Sizer Guide For SAP

Uploaded by

Document Information

Original Description:

Original Title

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

Quick Sizer Guide For SAP

Uploaded by

Copyright:

Available Formats

SAP Quick Sizer Help Page 1 of 76

SAP Business Suite

Customer Relationship Management

Note for IPC Handling

Internet Sales Definition

 By an employee in the Customer Interaction Center

CIC Emails and Definition

Mobile Sales and Definition

Customer Orders Definition

Enterprise Resource Planning

Controlling Definition of CO documents

Posting from Posting to Number of line items

Posting activity calculation

 Postings into CO, for example

Profit Center Definition

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

Overhead Rates & Definition

Human Capital Management

Time Evaluation - Definition

Stock Movement Definition

Product Development & Execution

invoice line item per purchase order line item.

 Confirmations to a production order must be entered at the sizing element PP-CONF.

Project System Definition

For peak load

10 + 300*5 + 300*1 = 1.810

 Three status items per WBS element

Sales & Service

Customer Service Definition

Incentive and Definition

ICM Case Specifics for ICM Case Processing

 Remunerations per commission case

 Number of months the data remains in the database

ICM Document Specifics for ICM Document Posting

ICM-DOC  Number of documents

 Remunerations per document

 Number of months the data remains in the database

ICM Settlement Specifics for ICM Settlement

 Number of commission contracts

Sales & Definition

Sales Data and Definition

Sales Orders Definition

Travel Receipts Definition

Supply Chain Management

APO - Planning Specifics for the Planning Run Sizing - CPU

Production Planning and Supply Network Planning

Specifics for Warehouse Stocks - SAP liveCache Memory

APO - Planned Specifics for Planned Orders - SAP liveCache Memory

APO - Planning Specifics for the Planning Run Sizing - CPU

Order Fulfillment Sizing assumptions and principles

Specifics for the Location Products

Specifics for the Available-to-Promise Checks - CPU

ATP-RULE  Rule-based ATP-requests

Inventory Collaboration Hub

Inventory Sizing assumptions and principles

Specifics for Location Products

APO - Message Specifics for Message Processing with Periods - CPU

APO - Message Specifics for Message Processing - CPU

APO - Orders Specifics for Orders replicated to/from ECC

Extended Warehouse Management

Extended Warehouse Management - Inbound

EWM - Mandatory Specifics

By an employee in the Customer Interaction Center

Postings into CO, for example

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

Confirmations to a production order must be entered at the sizing element PP-CONF.

10 + 3005 + 3001 = 1.810

Three status items per WBS element

Remunerations per commission case

Number of months the data remains in the database

ICM-DOC Number of documents

Remunerations per document

Number of months the data remains in the database

Number of commission contracts

ATP-RULE Rule-based ATP-requests

Optional: Change of resource in staging (OEWM-RESST)

Retail Masterdata (R-Master)

Posting relevant line items on consumption bill (C.item)

Additional info lines on consumption bill (Lines)

Taxes per contract (Taxes)

Contract accounts (ContAcc.)

Overdue notices per year (Overdues)

Cash security deposits (Deposits)

Customer contacts per year (Cust.contct)

Planning steps per user

Average number of data records per planning step

Maximum data per planning step

Maximum data per user