Beginner’s Guide to SAP Sizing Principles

Introduction

SAP sizing isn’t just a buzzword; it’s the compass guiding your SAP system towards peak performance, cost-effectiveness, and long-term sustainability. If you’re on a quest to ensure that your SAP system operates at its best in terms of performance and cost-efficiency, then this comprehensive guide on SAP sizing is your trusted navigator through this critical terrain.

In this article, we embark on a journey to demystify the significance of SAP sizing. We’ll delve into its methodologies, tools, and techniques. By the end, you will not only understand the intricacies of SAP sizing but also be empowered to optimize your SAP system, tailored to your organization’s specific requirements. Join us as we unlock the secrets of SAP sizing and equip you to optimize your SAP system to its fullest potential.

Understanding SAP Sizing

Overview

At its core, SAP sizing means translating your business requirements into precise hardware specifications. This encompasses the meticulous determination of hardware pre-requisites, covering various aspects such as network bandwidth, physical memory, CPU power, and I/O capacity.

The sizing process, and the results it yield, are inextricably linked to the application lifecycle, rendering it an iterative process. The ultimate success of your sizing exercise hinges on the quality of the data at your disposal.

Crucially, the size of your hardware and database are influenced by both business and technological considerations. This implies that factors such as the number of users, utilizing various application components and the data load they impose on the network must be carefully factored into the equation.

Sizing Methodology

Introduction to SAPS

SAPS stands for “SAP Application Performance Standard”. It serves as a crucial unit of measurement within an SAP environment, specially designed to the evaluate of a given system configuration. SAPS is distinctive for its hardware-independent nature, effectively describing the processing power required to execute various SAP transaction workloads.

To delve further into SAPS, the output of SAP’s customer sizing tools is expressed in terms of SAPS. These units are instrumental in quantifying the CPU power of a system, providing a tangible metric for comprehensively assessing a system’s processing capabilities.

Benchmark of SAPS

The benchmark used as a foundation for SAPS calculation is based on the Sales and Distribution (SD) workload. Within this benchmark, a rating of 100 SAPS signifies the system’s ability to process 2,000 order line items per hour while performing full business processing.

In practical terms, this implies that a system with 100 SAPS can efficiently handle 6,000 screen changes (dialog steps), process 2,000 posts in an hour, or execute 2,400 SAP transactions seamlessly. The significance of SAPS becomes apparent as it empowers organizations to precisely determine the requisite hardware resources necessary for the effective operation of SAP applications. These performance metrics can be tailored to align with the specific demands of their business.

The Role of Hardware Vendors

Notably, hardware vendors play a pivotal role in the SAPS ecosystem. They rigorously test their hardware to ascertain its SAPS rating, employing proprietary methodologies. This evaluation involves assigning a weight to each module and converting the number of users in each module into a Normalized SD (NSD) value. Through this meticulous process, hardware vendors obtain the essential SAPS value, which is vital for making informed decisions regarding their hardware configurations.

SAP Benchmarking

• Sizing information can be determined using SAP standard application benchmarks and scalability tests.
• Benchmarking is a mechanism for scrutinizing the efficiency of new hardware and software components by subjecting them to taxing workloads.
• Through this evaluation, we can acquire knowledgeable judgments when it comes to selecting the optimal components tailored to our specific necessities. This enables us to make calculated and informed determinations.
• To have a reference of SAPS benchmarks results, visit here.

Benefits:

• Customer Benefits:
  • Benchmark outcomes shed light on the scalability and manageability of large installations:
    • Allows users to make side-by-side comparisons of different platforms.
    • Activates the proof-of-concept scenarios.
    • Provides a vision for the future performance levels.
    • Provides the fundamentals to facilitate configuration and sizing of SAP suite.

• Partner Benefits:
  • Benchmarks are done by hardware vendors, who evaluate various business application scenarios on specific hardware. The final goal is to find the best hardware configuration for a customer’s SAP system.

• SAP Benefits:
  • This is a tremendous opportunity for quality assurance. As a new release is developed, they are performed internally to monitor resource utilization.

SAP Sizing KPI’s

Below are the key performance indicators (KPI’s) of SAP Sizing

Sizing Factors

Factors that determining SAP sizing are highlighted here

Sizing Collaboration Pillars

Sizing is a shared responsibility of customer, SAP, hardware vendors, and service providers. They all have a mutual goal of ensuring that SAP software runs smoothly at the customer site and that customers do not run into performance or total cost of ownership (TCO) issues due to under or over-sized hardware.

Stakeholder Collaboration

To achieve this goal, the stakeholders associated must collaborate to make sure that SAP software is configured correctly and that the hardware it runs on is appropriately sized. For instance, the hardware vendors must ensure that the equipment they provide meets the required specifications and can handle the expected workload. Simultaneously, it is the ownership of the service providers to ensure that the software is installed correctly and configured appropriately to operate seamlessly with the hardware.

Achieving a Seamless Collaboration

In the end, through through collaborative efforts and careful consideration of the software and hardware sizing, all parties involved can guarantee a favorable experience. This collaborative approach mitigates the risk of technical glitches that might otherwise disrupt their operations, ensuring that the SAP ecosystem runs smoothly and efficiently for all involved stakeholders.

Risks In SAP Sizing Projects

The success of any project hinges on meticulous assessment and proactive management aimed at tackling the challenges and risks that may arise during SAP sizing project. Here we outline some key risks that demand attention:

• Incomplete or inaccurate data: To lay a strong foundation, it’s imperative to ensure that the data used for sizing is not only accurate but also current, relevant, and validated. In cases where resource utilization information falls short, it becomes essential to carefully document any assumptions made.
• Changing requirements: The shifting sands of project requirements can have a profound impact on sizing estimates, often necessitating extensive rework. This, in turn, can lead to unwelcome delays, performance issues, and additional costs.
• Custom programs: Predicting the impact of custom coding and specialized data can be quite challenging, which is why it’s important to have a verification process in place. To effectively manage these risks in SAP sizing projects, it’s crucial to conduct expert sizing and take accurate sizing measurements.
• Hardware and software incompatibility issues: The presence of incompatible software and hardware components can cast a shadow over system performance and stability. Hence, proactive measures are essential to address and rectify these issues.

To effectively mitigate these risks, several crucial steps come into play: it is important to have a well-defined project plan, an experienced project team, and a rigorous testing and validation process. Regular communication and collaboration between stakeholders can also help identify and manage risks throughout the project.

• Well-Defined Project Plan: Craft a comprehensive project plan that delineates the project’s objectives, timelines, and resource allocation.
• Experienced Project Team: Assemble a team with a wealth of experience in SAP sizing and project management, ensuring they possess the expertise needed to navigate potential pitfalls.
• Rigorous Testing and Validation: Implement a rigorous testing and validation process to uncover and rectify any issues early in the project’s lifecycle.
• Regular Communication and Collaboration: Foster an environment of open communication and collaboration among stakeholders. This helps in the early identification and management of risks that may crop up throughout the project.

By adhering to these principles and maintaining a keen focus on risk management, SAP sizing projects can be steered toward success, ensuring that the anticipated benefits are fully realized.

Standard Sizing Tools

Below are the SAP standard sizing tools:

1. Initial Calculation Method: Educated guess.
2. T-Shirt Sizing: Simple Algorithms with many assumptions.
3. Formulas: Simple or more complex.
4. Questionnaire without formulas: For structured questions.
5. Quick Sizer: Used for user-based and throughput-based sizing.

SAP Quick Sizer

• SAP Quick Sizer tool is a user-friendly, free web-based tool, simplified for greenfield sizing, to provide faster results.
• Developed by SAP in close collaboration with platform technology partners, using proven sizing methodology that guarantees reliability.
• Accessible 24×7, this tool translates intricate business requirements into precise technical specifications.
• To harness the power of this tool, you only need to complete an online questionnaire, to generate results for CPU, disk, and memory requirements.
• By determining your sizing requirements, you can ensure that your hardware purchase will meet your business and performance requirements, and also reduce your costs and TCO (total cost of ownership).
• There are three versions of SAP Quick Sizer tool:
  • Classic version (for Business Suite)
  • SAP HANA (stand-alone platform)
  • SAP HANA Cloud

Sizing Methods

User-based Approach

Quick Sizer uses this approach to assess business requirements based on the number of users performing specific business tasks and their level of activity. Accordingly, it groups users and generates a sizing recommendation. For small businesses this method is the most appropriate one.

Based on the business activity, users are grouped into:

• Low Activity Users: Users who spend less than two hours working in SAP. [TT -> 300 secs].

• Medium Activity Users: Users who spend around four hours in SAP. [TT -> 30 secs].

• High Activity Users: Users who spend more than fours hours in SAP. [TT-> 10 secs].

Note: TT is the “Think Time”. Think time refers to the time a user typically takes to decide on the next task to perform. During this time the system remains available to user. The total time required to complete a task is the sum of think time + wait time. Wait time is influenced by the system resources and programming logic, while think time is directly proportional to user-friendliness of the product.

Throughput-based Approach

In addition to the number of users, this quick sizer method uses additional information about the number of business processes and business objects. For midsize, large and complex businesses this approach is recommended.

How does Quick Sizer work?

Step 1: Create a Quick Sizer project and input the customer’s business requirements into the project to determine the appropriate sizing needed for their system.

Step 2: Quick Sizer calculates the hardware resource sizing requirement based on the input.

Step 3: To find hardware providers that offer configurations matching the sizing result, check the list of certified hardware for AnyDB or HANA. [ Virtualized environment: Virtualization software requires 10% approximate extra resources, based on workload. So consider this while providing sizing inputs ].

Step 4: Share the sizing result or Quick-Sizer project number with the hardware vendor to receive proposals for the appropriate hardware configuration and corresponding prices.

Follow the video to know step-by-step how QuickSizer tool work

T-Shirt Sizing

Initial Generic Sizing

Many small and medium sized SAP 3-tier systems, do not necessitate the details of complex sizing. So generic sizing category has been created for such system. T-shirt system is usually used for such generic sizing.

T-Shirt sizing gives a coarse grained estimation based on single input ie concurrent users. It means users who are actively working in the system at any point in time. T-shirt sizing is efficient but gives ball park (rough) estimation for CPU (in SAPS) and memory (in GB). Each SAP product has a T-shirt sizing guide on SAP service marketplace (SMP).

To make the sizing process of small and medium sized SAP 3-tier systems more comprehensive, four T-shirt sizing categories are proposed:

• Small (S): SAP systems estimated to have an approximate SAPS of 13,000 to 45,000.

• Medium (M): SAP systems estimated to have an approximate SAPS of 45,000 to 90,000.

• Large (L): SAP systems estimated to have an approximate SAPS of 90,000 to 150,000.

• Extra Large (XL): SAP systems estimated to have an approximate SAPS of 150,000 to 250,000.

Types of SAP Sizing

The process of sizing an SAP system can differ based on the nature of the project a company is undertaking, and each approach presents its unique set of parameters, challenges and considerations.

It’s intrinsic to understand the different SAP sizing methods, whether the company is starting a new SAP implementation (greenfield), upgrading an existing system (brownfield), or working on any other similar custom project type. This awareness will help the company make informed decisions about the hardware requirements, ensuring that the SAP system is perfectly sized to run its business processes smoothly and efficiently.

Greenfield Sizing

• It is a process of determining the resources required for entirely new application, starting from scratch. This crucial step involves identifying the primary factors that will drive the application’s workload and then assigning appropriate sizing values to these factors.

• To accomplish this, we reply on QuickSizer tool, complimented by well-established sizing guidelines. It efficiently streamlines the determination of sizing requirements for critical components such as CPU, memory, diskspace and I/O resources.

• Greenfield sizing primarily takes into account two primary metrics: user-based and throughput-based.
  • User-based sizing considers the number of users the application is expected to support and their corresponding resource needs.
  • Throughput-based sizing, on the other hand, focuses on the volume of data or transactions the application must handle and allocates resources accordingly.

• To explore more about Greenfield implementation and how it works in this blog section.

Brownfield Sizing

• Brownfield sizing is a strategic approach that involves enhancing your existing SAP system by introducing new functionalities, adding users, or migrating to a new platform. Its a method tailored to the current state of your operations, ensuring a smooth transition and future resource preparedness.

• This sizing approach is categorized based on the solution’s lifecycle and can fall under the labels of upgrade, -delta, -re or migration sizing. Each category addresses specific needs and objectives within your SAP environment, offering a tailored solution for your organization’s unique circumstances.

• In context to brownfield sizing, its crucial to prepare for future resource requirements. This preparation involves a comprehensive evaluation of your resource utilization. Factors like table growth, CPU utilization, and memory usage needs to be closely monitored to ensure you system remains robust and responsive as you implement changes and upgrades.

• By staying vigilant about these resource indicators, you can make informed decisions and allocate resources efficiently, preventing potential bottlenecks or performance issues down the road.

• Explore more about Brownfield by clicking the link.

Bluefield Sizing

• Bluefield sizing represents a unique and hybrid approach that blends the strengths of both greenfield and brownfield implementation strategies. It particularly shines in complex IT ecosystem often found in large enterprises.

• Unlike greenfield and brownfield approaches, which involves starting from scratch or upgrading everything. Bluefield offers companies the flexibility to choose which components they want to migrate when transitioning to SAP S/4HANA or BW/4HANA.

•  Bluefield embraces a gradual and selective data transformation process, preserving the value of the existing system while integrating new functionalities seamlessly. This pragmatic approach ensures that your organization’s investments in the current system are not lost and that you can leverage them to optimize your SAP landscape.

• Consequently, when it comes to bluefield sizing, you only need to consider the requirements for the added or new functionality you plan to incorporate. This simplicity streamlines the sizing process, allowing you to focus your resources and efforts precisely where they are needed.

• Explore more about Bluefield by clicking the link.

Expert Sizing

• Expert sizing stands out as a meticulous and thorough analysis of SAP system business processes, considering both the technical and functional aspects in depth.

• Unlike conventional sizing methods that lean on standardized tools, expert sizing recognizes that there’s no universal solution that fits all scenarios.

• Sizing SAP applications through the expert approach is not usually a straightforward process, one-size-fits-all process. It typically demands substantial expertise in the field of SAP to navigate its intricacies effectively.

• Each organization is unique, and expert sizing acknowledges this by tailoring solutions to specific needs.

• Explore more about Expert Sizing, by click the link.

Post Go-Live Sizing

Approach for Sizing Productive Systems

Pre-requisites

• SAP system is live and optimally tuned.

• Emphasis is on the total consumption of the business processes on the hardware.

• Factors influencing resource consumption are:
  • Business process comprising of customizing, customer extensions.
  • Hardware and software configuration combination.
  • Used resources are recommended, not allocated one.

• Different goals:
  • Re-Sizing: No modified processes, only add volumes.
  • Delta Sizing: add different functions.
  • Upgrade Sizing: only upgrade SAP software.

Procedure

Here are different procedures for achieving different sizing goals.

Re-sizing

• It involves expanding your system capacity to accommodate extra workload generated by new users and projects. This is achieved by incorporating the additional load into the existing load structure.
• Utilize relevant SAP system monitors to track crucial performance indicators, including memory and CPU utilization, as well as table growth etc.

Delta Sizing

• It can be thought of as a fresh sizing approach where you add the computed load, as if it were entirely new.
• It is particularly useful when you’re expanding your system capacity by integrating different functions, such for example as adding SAP SCM to your existing SAP CRM.
• Utilize relevant SAP system monitors for tracking memory and CPU utilization, table growth etc.

Upgrade Sizing

• It involves determining the additional new requirements necessitated by an upgrade and adding the computed load accordingly.
• Ensure you’re using relevant SAP system monitors, SAP Notes, and upgrade software to effectively manage the transition and optimize performance during the upgrade process.

System Monitors for Resource Utilization

Typically, it is observed that 20% of the processes are caused by 80% of the workload.

• Monitor and analyze the growth rate of 20 largest tables.
• Keep track of the average and peak CPU load.
• Track the average and peak memory utilization.