business impacts on sap deployments

7/28/2019 Business Impacts on SAP Deployments

http://slidepdf.com/reader/full/business-impacts-on-sap-deployments 1/30

Telephone 847.931.9100 180 South Western Avenue, # 275 Website www.sil-usa.com Carpentersville, Illinois 60110

Business Impacts on SAP DeploymentsQuantitative analysis and business differentiators for SAP platforms

1. Introduction

The move to enterprise applications such as SAP has been a prevalent trend for many years. As more and more organizations implement the integrated enterprise processingand business support, the challenge of selecting the correct platform has increased. The very nature of an ERP system makes the selection of the platform difficult, since thecollective processing mixes significantly different types of activities, ranging from OLTPto complex data analysis. The choice has to support the flexible capacity demands thatare produced by the combination of layers of diverse users and varied IT activities.

The selection of the optimal platform for SAP must include technical and businessfactors, but the overall decision is a business one. Since the impact of platform for anSAP deployment is a difficult one to quantify on this level, IBM engaged SolitaireInterglobal Ltd. (SIL) to conduct surveys, gather data and perform analysis to provide aclear understanding of the benefits and relative costs that can be seen whenorganizations implement IBM Power platforms as part of their SAP IT architecture. Thisanalysis has been primarily directed at the value of that platform use from a businessperspective, so that those whose role it is to provide business leadership can understandthe benefit of the IBM Power architecture in deployment and operation of their SAPERP systems.

During this study, the main behavioral characteristics of software and hardware wereexamined closely, within a large number of actual customer sites (54,150+). All of thesecustomers include organizations that have deployed SAP systems as part of theirproduction environments. This group has organizations that maintain both unalteredERP deployments and those that have been customized to support additionalfunctionality and business process, well as those ERP systems that have been integrated with third-party or custom components. The information from these customer reports,and the accompanying mass of real-world details is invaluable, since it provides arealistic, rather than theoretical, understanding of how the choice of platform can affectthe organization’s costs, risk and strategic positioning in the current marketplace.

In the collection and analysis of this data, a series of characteristics were derived. Thesecharacteristics affect the overt capacity, efficiency and reliability of the environment andits affects on operational and business performance. These characteristics have beenexamined within a business framework, since that is the perspective that is needed tomake an informed decision. The business perspective encompasses a myriad of factors,including downtime, staffing levels, time-to-market (agility) and other effects. This isthe basis for selection of an optimal platform for an organization’s SAP system.



SAP Efficiency without Compromise

© 2013, Solitaire Interglobal Ltd.

2. Summary of Findings

The purpose of this analysis was to examine the real-world impact on businesses thatdeploy IBM’s Power platforms to host SAP (with either Oracle or DB2 databases),compared to those deploying SAP on Sun (Oracle), HP x86, Dell x86 and HP Itanium,

all running with Oracle DB.1

The metrics used to analyze the differences in platforms were both objective and subjective. The objective metrics include reported data pointson costs, run times, resource usages, and so on. The subjective metrics includeresponses on various levels and sources of customer satisfaction and perception. Whileoverall customer satisfaction uses a variety of qualitative and quantitative measures, itstill provides an end-result measurement of deployment success for the customer. A few of the highlighted findings can be seen in the quick summary below.

Quick Summary

Category Commentary Quick Byte

CustomerSatisfaction

The larger the deployment and the more comprehensivethe SAP deployment, the higher the satisfaction for IBMPower platform deployments.

Fewer complaints from ITend users, reliable operationsmake happier management.

Total Cost of Acquisition (TCA)and Ownership(TCO)

While TCA can be more for Power deployments, theTCO rapidly changes that picture, especially when amulti-year view is taken.

Power TCO saves as much as62.18% compared to less cost-effective options.

Application Availability

As the environment gets more highly leveraged,availability becomes more critical. Power platformsshow consistently higher availability, with downtime aslittle as 1/6th of other options.

Industrial strengthavailability from Power.

Risk The reported risk of deployment is considerably betterfor Power platform implementations, reducing exposure

by as 42.65%.

Flexible functions to shareresources lower the risk of deployment on Powerplatforms.

Agility Power users are reporting faster deployment times by asmuch as 75.15%.

A well-managed Power

deployment system can bedirectly associated with fasterSAP time-to-market.

Complexity

The highly complex nature of the SAP ERP systemmakes the management of systems extremely challenging. The underlying platform can make asignificant difference.

Power filters SAP complexity by as much as 36.11%.

Scaling

The resiliency of the Power platform assists the SAPdeployment strategies by absorbing otherwisedisruptive performance problems and reducing outagessignificantly. Outages and performance issues in themonth post-deployment are much smaller.

The Power difference duringiterative roll out makesproblems smaller by up to90.79% fewer outages and85.16% fewer performanceproblems.

Security

The integrated Power security stack supports all forms

of control and isolation, keeping organization data andprocesses safer.

Power provides safer SAP

operations.

These key findings are all substantial reasons to consider Power platforms for anorganization’s SAP deployment.

1 Although DB2 runs on all of the platforms in the study, the results were limited to its performance on IBM Power platforms, which is are the focus of the study.





2.1. Study Scope

In order to understand the impact of IBM Power platforms as a key part of anorganization’s ERP deployment, a large number of deployments were examined. Thesedeployments included situations where the SAP deployment choices were homogeneous within an organization and ones where a mixture of different platforms, software toolsand components existed. The relative degree of difference in operating behavior for eachfactor, i.e., total number of outages, etc., was then compared to understand the net affectof the respective combinations. The effects were observed in general performance andcapacity consumption, as well as other business metrics.

2.2. Methodology

The approach taken by SIL uses a compilation and correlation of operational production behavior, using real systems and real business activities. For the purposes of thisinvestigation, over 54,150 environments were observed, recorded and analyzed tosubstantiate the findings. Using a large mass of customer and industry experiential data,

a more accurate understanding of real-world behavior can be achieved. The data fromthese systems was used to construct a meaningful perspective on current operationalchallenges and benefits. The reported behavior of the systems was analyzed to isolatecharacteristics of the architecture from both a raw performance and a net business effectperspective. All input was restricted to those organizations using systems in versionsthat were current in calendar years 2010-2012. Since many of the components in thisenvironment have releases at staggered points in time, only those components that wereeither the current version or a -1 version based on those calendar restrictions wereincluded in the study. Additional information on the methodology and study diversity can be found in additional methodology notes at the end of this document.

In a situation such as that presented by this study, SIL uses an approach that

incorporates the acquisition of operational data, including system activity informationat a very detailed level. It should be noted that customers, running on their productionplatforms, provided all of the information. It is essential to understand that none of thedata was captured from artificial benchmarks or constructed tests, since the value in thisstudy comes from the understanding of the actual operational process within anorganization, rather than the current perception of what is being done. Therefore, thesesites have tuning that is representative of real-life situations, rather than an artificial benchmark configuration. Since the focus of this analysis was not to tightly define thedifferences among different minor variations of operating system or hardware, the various releases were combined to show overall architectural differences. This providesa more general view of architectural strategy.

The study was further restricted to organizations that have larger implementations. While this restriction is not intended to make a statement on suitability of any deployment platform for small organizations, it is true that smaller processing demandsare more easily handled, and provide smaller differentiation in analysis. For thesereasons, the smaller implementations2 were filtered from the study.

2 The guidelines for organizational size classification that SIL uses are defined in the supplemental methodologynotes at the end of this document.





The analysis of this data has produced findings in two groups of viewpoints, covering both business and technical management. For a more concise summation, thosefindings have been discussed separately in the body of the paper.

2.3. Business Management Perspective

Ultimately, IT and technology management are designed to support business functions.So one of the primary perspectives of the study was the view of the technology by anorganization’s business management, both executive and line-of-business. For thepurposes of this part of the analysis, the patterns of operations from the study organizations have been grouped into similar categories and then compared to identify their affect on business metrics. These metrics are:

• Customer satisfaction

• Total cost of acquisition and ownership

• IT stability, risk and reliability

• Agility (time-to-market)

Each of these business metrics has measurable and significant differentiation when theprojected IBM Power deployment solution is viewed.

The more granular business metrics are those measurements that show how a specificmeasure of success is different in the general population of the implementers versusthose that have deployed Power. For further clarification, those deployments with Sun(Oracle), HP x86, Dell x86 and HP Itanium, all running with Oracle DB have been also broken out. These metrics are fairly broad in coverage and touch on areas of financialconsideration, as well as organizational quality. Each metric is presented with a shortdefinition and the focused net effect of IBM Power SAP deployment. In order to bemeaningful across a variety of industries, all of the metrics have been normalized on a

work-unit basis3

, and categorized by levels of organization size (medium, large and very large). The base measure has been set by the medium company average, so that all othermetrics are based on a variance from that standard set point. The implementationsincluded in this study have been restricted to those implementations in production.

Customer Satisfaction – Executive Management

The ultimate metric on a successful implementation is customer satisfaction. SIL tracksthis split out between the executive management and the operational input from acustomer, since the perspective of the customer may radically differ between those twogroups. The satisfaction of the customer executive management about their IT systemstends to focus on the application, rather than the deployment platform, although noapplication can work as well with a poorly configured or fragile SAP deployment. That being said, the satisfaction with IT implementation and operation provides the mostgeneral metric for evaluation. This satisfaction rating was obtained from a large group of customers and provides a singular perspective on the overall success of the SAP systemimplementation. While this is a subjective rating provided by high-level organizationalmanagement, it does provide the business’ actual perception of success.

3 Work-unit basis has been defined using the published International Function Point User Group standards and arebased on function point (FP) analysis.





The advantages seen by the reporting clients show increasing satisfaction in the SAPdeployments run on Power, much of which can be attributed to the number of complaints that the executives reported from their customers and users of thosesystems. The following chart shows the reported average monthly complaint count forthe different platform groups. These complaints have been restricted to continuedoperational issues, and exclude complaints associated with missing and desiredapplication functionality.





While the specific customer complaints can be affected by management techniques,application design and other factors, the relative comparison is a legitimate indicator of how well the operating system supports the processing at the organization. The threetop reasons cited by reporting customers for the satisfaction were:

1. Smooth running operation with little downtime and complaints

2. Adherence to planned budget levels3. Quality and responsiveness of the strategic and technical support

During the study data collection, many of the executives commented on their operation,satisfaction and other areas of the SAP implementation. Two of the typical commentsare encapsulated in the quotes below. One of the quotes is pertinent to SAP runningagainst an Oracle database on Power platforms, while the other addresses SAP runningon Power with a DB2 database.

“…the Oracle systems that we have running on Power platforms almost never are on the crit list, mostly because they don’t run over theirmaintenance windows and do not have spotty

performance. Granted I really have no ideawhy, not being very technical, but I do knowthat they just keep working, which is a bigblessing for me. Especially since they are not amajor source of complaints.”

Retail company CTO

“The Power boxes seem to just keep runningwithout a problem. I was not really happy withthe cost at installation, but it turns out that

DB2 on the Power box doesn’t keep dinging you for more money. It has really changed mymind about both the Power platform and DB2,especially.”

Trading firm director

Research Note: The level of end user IT complaints were correlated tothe size of an SAP implementation and the complexity of that installation,i.e., implemented module count, manual resource allocation actions, etc.The control of those complaint levels also showed an inverse correlation to

the number of platforms. This would indicate that satisfaction with an SAPimplementation is dependent on limiting the number of platforms to theminimum necessary to perform the needed operations, and thatmanagement tools and practices are needed to reduce apparent complexity as much as possible.

Customer Satisfaction - Operational

The operational perception of the customer, based on a variety of component metrics(e.g. support levels, communication, price, etc.), demonstrates satisfaction and successat the most generic level. This satisfaction metric is different from the overallsatisfaction metric described earlier, in that the previous metric was gathered from the

executive management level, while this metric examines the feedback from theoperational side of the organization. This specific metric comes from informationreported both by the IT departments and the line-of-business (LOB) groups.





The satisfaction of the IT operational staff and the LOB with the Power SAPdeployments reflect the reliability and resiliency of the platform as a deployment choice,in addition to the previously mentioned integration benefits. The most highly citedreasons for the satisfaction were:

1. Smooth running operation with little downtime and complaints2. Consistent runtimes and load3. Ability to shift resources as needed

More than 92% of the reporting customers cited one or more of these three reasons for

their satisfaction.

“The Power platforms running our SAP order processing have not been a problem for the full 19 months that we have been in production,unlike the other platforms that are running thesame processes for some of our business units.We are really considering whether to move all of our SAP to Power in the next upgrade.”

Insurance company IT Director

“We never have to worry about our SAP on DB2 because it delivers consistent run timesand processing. Our SLAs have been met 100%of the time over the last year.”

Bank IT Manager

Cost of Acquisition (TCA) and Overall Expense (TCO)

This cost perspective looks at the total cost to the corporation of SAP operations, as wellas the cost of acquisition. These metrics summarize very distinct perspectives on costand organizational impact. TCA differs from TCO because it focuses on the expensesnecessary to move an SAP system from installation to production deployment. Theseexpenditures include the actual cost for the deployed equipment, services necessary forinstallation and test, initial licensing costs for all infrastructure components (includingSAP licensing), personnel for initial staffing, education for deployment and operationalstaff, facility amendment, and so on. Any cost associated with IT end user training is





excluded, as is any burden for SAP customization or enhancement. Any expenseencompassed in this view of organizational impact reflects the amounts extended by theorganization, rather than a quoted amount from a vendor bid. In short, TCA measuresonly the expenses that occur from first equipment arrival to production cutover, whileTCO measures ongoing production costs. A visual summary can be seen in the diagram

below.TCA TCO

Application Deployment Ongoing Operations

Acquisition to initialdeployment

P r o d u c t i o n

C u t o v e r

Year 1Production

Year 2Production

The expenditures that are included in TCO span many divergent expense categories,including personnel, equipment (i.e., servers, network infrastructure, etc.), utilities,software, and maintenance (facilities, hardware, software, etc.), to name a few. Alloutlays in these categories pertain to the operation of SAP, but specifically exclude

development and initial production rollout costs. The burden for new enhancementfunctions is not included, leaving just the summation that identifies the organizationalrunning rate for an installed SAP system. The TCO financial metric is morecomprehensive than a straight operational metric. This metric it should not be viewed inisolation, since extraordinary expense patterns for individual organizations may causeminor variance in the exact comparison values. For this reason, the comparison metricshould be viewed as indicative and providing a general range rather that an exact value.However, with the large number of contributing organizations, the data is sufficiently large that, combined with the other business metrics, this comparison helps to set anappropriate perspective. Both TCA and TCO have been normalized in the study based onemployee count, sales revenue and legal entity count.

One challenge with looking at TCA is that many organizations look at TCA as defined by vendor quotations. SIL takes a different view, since the reporting organizations providethe actual costs for deployment. Since some initial quotations vary widely from theactual cost of deployment, the real implementation cost is a more valid measurement of TCA. The view of the variance by platform between quoted and actual demonstrates thedanger in using quoted figures as a TCA metric.





The actual TCA provides a much different perspective from the comparisons of vendorquotations. If the degree of variance is summarized into four categories based on thepercentage of variance from vendor quotation to deployed production infrastructure,significant differences in sizing methodology are highlighted





This significant difference between the quotation and the actual expense can causesignificant problems for an organization. The cost overruns, with their associatedschedule impacts can hamper the strategic deployments necessary to compete in today’smarket.

The large majority of IBM SAP quotations show a smaller variance between the initial

sizing and the actual deployment than other vendors, with the average variance for IBM being only 8.34%. This highly accurate sizing and cost projection provides theorganization with a significant advantage in budget compliance.

“We thought we had made a smart choicedeploying inexpensive platforms, choosing x86over the more costly UNIX systems.Unfortunately, by the time we had our first

production cutover, we had spent 1,015% of our planned budget. The repeated cost overrunswere terrible, with the last equipment “lift” happening in the middle of our actual

production cutover week. The performance is

still far below what we need and expected, but at least we are up and running – or in this casemore of a slow walk. I was lucky to keep my jobafter this mess!”

Retail and distribution CIO

“Our SAP deployment was a total nightmare for the finance side. The costs overruns were436% - that is over our initial budget, not including it. I am at least partially at fault,since I was the one that pushed for thealternative to the IBM Power equipment. Thedifference in cost was 18%, and I thought it wasunnecessary. That 18% looks pretty small compared to the overrun, especially since we

have never had to add equipment for an IBM project before, or at least one that did not change major requirements in mid-deployment. Next time I will be smarter, I hope.”

Finance company CEO

The TCA for the various SAP deployment options is most accurate when viewed from areal-world perspective, ignoring the preliminary quotations. This view does cause someconsternation, since the confusion caused by unreliable sizing and infrastructurequotation tends to provide customers with faulty information on which to makedecisions. However, if the actual deployment costs are used for TCA, the fallacy of a

substantially higher expense for Power platform deployment is exposed. The chart below shows the actual TCA expenditures reported for each platform type, summarizedacross all organization sizes. While the IBM Power solutions are not uniformly lowerthan all other options, the costs are not significantly higher than the competition.





Since TCA occurs only in the period from equipment installation to productiondeployment, the metric that examines the ongoing operation (TCO) is a repeatedmeasurement of the application burden for an organization. The comparison of the TCOfor the different platform options can be seen below.





The IBM Power SAP deployments show lower overall expenses, with the costs associated with the Power platforms as little as 37.82% of competitive offerings over a wide rangeof organization sizes. It should be noted that this TCO comparison should be viewed inconjunction with availability and downtime metrics. Since no cost has been associated with unavailability, each organization should factor in its associated downtime cost to

the TCO metric provided here. The downtime metric can be found later in thisdocument.

Research Note: The degree of virtualization and the choice of clouddeployment affect the costs and ROI of SAP deployments. Since expenses vary widely between virtualized and non-virtualized implementations, bestpractices would suggest that organizations seriously consider virtualization for their SAP deployment. This assumes that the virtualization method allows efficient movement of resources withoutsignificant drain on staffing.

The cost of hardware acquisition is frequently higher with the Power platforms than for

the smaller Intel platforms. This disparity in cost levels is obviated over time, as thedefining expense metric switches from TCA to TCO. This switch happens in alldeployments eventually, but is more rapid in the larger installations. The following chartshows the total cost of ownership over the initial production deployment period and fortwo years of production operations. The set point for comparison is once again the Dellx86, in this case the TCA for that platform solution.

When viewed from a two-year production plus acquisition perspective, the IBM Powersolutions have demonstrated an advantage of up to 52.49% for the full time period.





“Luckily for us, our cost justification processallows us to look at a longer term than the first year. If we would have selected based on just the cost of acquisition, we would have had anoutlay of a much larger total than we did withour IBM (Power) platforms over the last three

years. We are in much better shape now thanour other agencies SAP deployments, with lessthan one-third of the operating expenses peryear.”

Finance minister government ministry

“We have three divisions, each with their own SAP installation. Only one of these is on IBM Power platforms. It is also the only one that stays on budget year after year, and that iswith it supporting our largest division. And they manage it with less than 2/3 of the staff.

At least IBM seems to know how to size theirequipment.”

Manufacturing CFO

The difference in TCO among the solutions is based largely on the lower expenses for theefficient deployment and operations of the SAP implementation and the lower overallcost of the solution, including staffing. This is affected by the scope of the SAPdeployment, with increased expenditure efficiency present as the complexity and size of the deployment increases. SAP as an organization tends to use relative cost per SAP, anartificial unit of work that does not always correlate to a planned deployment. However,

since that is the standard metric used, a comparison of those relative SAP costs in thedeployed organizations reporting into this study shows the underlying efficiency of thedifferent deployment options. These values are limited by current year costs and workloads, and incorporate organizations in various maturities of implementation,although all are in production.





The trend in cost per SAP for the ERP implementation demonstrates the efficiency of the Power platform. The trend in declining cost per SAP for the increasingly complexand large deployments is also indicative of the strength of the platform.

Customers of all degrees of deployment reported a consistent pattern of differentiationin four main areas:

1. Higher utilization of platforms2. Lower staffing costs overall (due to tools, stability, etc.)3. Lower licensing costs4. Lower datacenter costs (environmental, facility, etc.)

More than 95% of the reporting organizations sited these factors as the most influentialfactor in their perception of cost.

“I was not really happy with the cost of theinitial installation, but I have to say that thelack of major expenditures in the last two yearshave changed my mind about the Power

platforms for our SAP application. Many of mycolleagues at SAP conferences are experiencingescalating costs, while ours are sticking to thebudget and plan.”

Financial industry CIO

“Thank goodness for DB2 on Power. When ourbudget cuts came through we would have beenin real trouble if we had to invest more money,but DB2 is much less expensive to operate on

and our SAP processing runs like clockwork.” Government ministry director

Staffing

An underlying factor that shows itself in many other areas is the effectiveness of theinterface between the technical user and the infrastructure, including software,hardware and operating system components, and the subsequent effect on staffing. Theefficiency of any of the specific components that provide that influence on the user

experience are difficult to break down into metrics other than in overly-detailedcomparisons that lose their effectiveness by virtue of the degree of detail. Therefore, ageneral view of the full-time staff position equivalents was reviewed to provide a generalmetric for the platform comparison. These levels are those required to maintain a “goldstandard” environment for each deployment option. In order to provide a commoncomparison field, the workload on the systems was normalized to identical levels. Theset point for comparison was selected as the staff level for a medium-sized organizationusing Dell x86 running an Oracle database.





Standards of implementation as set by SAP in their best practices guidelines have beenused to define the rigor of the deployment processes and functions. It is important tokeep the rigor of those standards in mind when reviewing the staffing. The noticeably lower staffing level for Power deployment and use is directly attributable to an efficientunified workflow, as well as a substantially different mechanism to handle the allocationof virtualized resources. The normalized staffing levels for Power deployment aresmaller than those for the competitive offerings by as much as 56.92%.

“The SAP Oracle systems require fewer staff requisitions for the LOBs running Power than

for the ones running Dell or HP. This meansthat the staff expense stays pretty flat for the

Power implementations, while we arescrambling to find qualified people to fill theother jobs. Unfortunately, it means that we arebackfilling with consultants, which is reallymessing up our budgets.”

Manufacturing HR director

“The SAP application has caused a 45-personincrease in (IT) staffing in the last two years.

None of that has been in operations and onlyone in database. DB2 has been a god-send inthis area.”

Retail manager

IT Stability, Risk and Reliability

Risk is composed of many factors. It includes the stability and reliability of the platform,as well as the chances of platform failure. IT stability and reliability metrics include alldowntime, both planned and unplanned. The dependability of the implementation is acombination of the individual reliability of each component, along with the quality andeffectiveness of the actual implementation. As such, both the planned and unplannedoutages affect the overall usability of the total system. SIL views SAP applicationavailability as a combination of all outages, i.e., network, hardware, OS, DBMS,





application services, etc. This view of availability includes the impact of a normalizednumber of outages, both planned and unplanned. Where virtualization has beenincluded in the architecture, each of the virtualized environments has been consideredas a separate platform. The net availability shows the ability of the user to access theSAP application system and is indicative of the synergy among the SAP application

suite, the vendor platforms and other components.

SAP application availability can be reversed and viewed as downtime. In the chart below, the aggregate outages have been expressed as a downtime total. The percentageof time that those outages represent includes all forms of unavailability, irrespective of source.





The IBM Power platforms report less than 1/6th of the total planned and unplanneddowntime of the other platforms in the study. The difference in SAP applicationunavailability allows an organization more flexibility in its operations and figuresprominently in the delivery of quality IT services. Since outages take valuable accesstime away from the corporate resources, outage and cost are highly correlated. The

decreased downtime demonstrated by the Power platforms translates to a significantfinancial advantage for the deploying organization.

The Power platform contributes to both stability and reliability of an organization’s SAPimplementation, due to the combination of high performance and native resilience. Thethree most cited sources of the high availability from customers are:

1. Fewer system crashes2. Limited need to reboot the full platform3. Fewer system patches and maintenance updates required

It should be noted that the practices of the individual organization when viewed from a best practices perspective makes a difference in the amount of planned downtime.

However, the overall trend in availability is a definite indicator of platform stability.The cost of that availability is difficult to articulate, since it rests on highly subjectivefeedback from the reporting organizations. Most organizations tied costs tounavailability by the minute, with different burdens for inward and outward-facingavailability. For inward-facing unavailability, the cost ranged from $582-6,320 perminute. For outward-facing unavailability, the range was greater at $13,540-57,402 perminute.





If the average outage time and reported financial impact is analyzed, a comparative costof application unavailability can be summarized. This is meaningful more whencategorized by organizational size, since reported unavailability cost estimates vary based on the size of the organizational customer base. The chart below shows theaverage cost for unavailability for month, including both inward and outward costs, as

reported by the organizations in the study.

The relative costs incorporate the split between inward and outward-facing cost effect. If downtime had no reported impact on either internal IT end users or outward customerand vendor users, it was not included in the costs accrued. Obviously, the largerorganizations, with increased user communities have an accelerated cost level.

SAP application availability is one metric that feeds into operational risk. Examined asan actuarial metric, SIL considers risk to be comprised of three components:

• Percentage chance of component failure• Percentage chance of budget or timeframe overrun• Potential exposure, expressed as a percentage amount of overall budget or

timeframe overrun

The risk components of both schedule and budget are a prevalent sore point to SAPoperations, since most complex systems do not adhere to budget well. This leavesmanagers and executives in a precarious position in many organizations.

These three percentages are added to form the overall risk factor for a scenario. The risk factor summary for the platform scenarios is shown below.





This graph shows that there is demonstrated risk mitigation from the general SAPoperations experience when using Power platforms. The risk exposure for IBM PowerSAP deployment is significantly smaller than the competition, showing less than 34% of the risk that has been reported for other deployment choices. Much of this lower risk can be attributed to the high resiliency of the deployment and increased efficiency of theresource allocation within the platform itself, which significantly lowers the risk of component failure.

“Unlike the four previous deployments that farexceeded budget and schedule, the last rollout was right on both. My team attributes thisdirectly to the change in platform to Power.”

Distribution company CEO

“The Power boxes running DB2 have matched to budget for the last three years. I just wish therest of the organization could be as good withthe budgets!”

Non-profit director

Agility

Agility is defined as the average number of calendar days from the start of an initiativeto the start of full production operations for a project. This is NOT staff days or hours, but the actual calendar span, including all weekends, holidays, etc. All of the

contributory factors, such as staffing and reliability, radically affect the speed in which acompany can move a business concept from inception to market. This nimbleness is akey element of increasing market share and continued corporate viability. While theperformance metrics were gathered on the production systems, additionalmeasurements were also collected to track the amount of time that the systems took tomove from initial conception to full production implementation. The resultsdemonstrate a significant increase in agility when Power platforms run SAP. Thisincrease in agility has been reported to be as much as 75.15% faster for the Power





deployment option when compared against the overall study group. This translates intoa faster time-to-market for business initiatives. The comparison is intended to beevocative and not quantitative, since other critical success factors, such as managementmethodology, resource availability, etc., can enter into this picture.

It is apparent from the reported data that there is a definite agility advantage to usingSAP Power-deployed systems as compared to the overall experience, especially when

organization standards for production system promotion are comprehensive. Whenasked for specific sources of the agility, the most frequently cited reasons fromcustomers were:

1. Ability to easily shift resources to accommodate new implementations

2. Speed of movement from non-production to productionenvironments

3. Lack of system failures during deployment

The adherence to best practices is a common affect throughout any implementationanalysis. With the complexity of SAP ERP deployments, best practices need to be

followed both from SAP and from the platform vendor. When virtualization is added in,a third level of best practice is mandated. This results in some significant differences inagility, since some virtualization methods include best practices that hamper agiledeployment. When repetitive deployments are part of the organizational strategy, suchas a world-wide roll-out, the net affect on deployment schedules can be significant. Inthe study organizations, this metric for repeated rollouts varied by as much as 342%, with the Power platforms providing the clear winner in the SAP deployment agility race.





“We get our new features out to all of ouroffices and reps worldwide faster than I would have believed two years ago, when we changed to the IBM boxes. These Power systems reallyseem to live up to their name. In the tool business, if we do not get out newest products

out for sale quickly, in new, eye-catching ways,we do not get the sales. We have been veryhappy with our investment in the IBM equipment, and are sticking with it.”

Manufacturing LOB division head

“The average deployment period for newgroups on our SAP system is less than 60% of what it was on the other system. We have

faster deployments and consistent operations,resulting in much higher quality ratings for mydepartment. This means that everyone is

happy, which is where we all [want] to be.” Financial organization CIO

2.4. Technical Management Perspective

One of the main perspectives for this analysis is from the viewpoint of the ITmanagement. This view looks at the operation management, including the technicalaspects of complexity management, control of scaling and the security of the SAP dataand processes.

Complexity

One of the most significant and pervasive influences in the operational arena is thecomplexity of the information lifecycle. This complexity is the foundation of every aspectof the systems within an organization. Due to the very pervasive nature of thisunderlying principal, it is frequently ignored. However, losing sight of the major effect of any increase in complexity challenges the forming of strategic solutions. Complexity tends to creep into any system. Small changes that viewed in isolation as insignificant,in aggregate can be seen to have large effects. In information management, thisfrequently takes the form of the introduction of additional platform types, languages,operating systems, database management systems, etc. The establishment of theenvironments of lifecycle management and the associated versioning produces anotherlayer of complication.

The metrics associated with complexity ratings are calculated on the basis of many factors. Most of these can be evaluated in a simplistic way by providing counts in theareas such as:

• Environments (development, testing, QA, production, HA, DR-BCP, etc.)• Applications• Platform types (mainframe, mid-range, Intel-based, etc.)• Operating system (Windows, UNIX, Linux, zOS, etc.)• DBMS (e.g., UDB, SQLServer, Oracle, Sybase)• Languages (Perl, Java, etc.)

The complexity rating is a calculation that incorporates these, and many other factors. Itis obvious that even with small changes, the complexity can quickly rise. Since thecomplexity is tied directly to the operational staff and costs, this rise will significantly affect the operational budget. This can be seen in an analysis of an SIL customersituation, tracked over a three-year period (SIL Response Tracking ID 20120174).





Example – Multi-year Customer Operational Complexity Analysis

Count Description Status 2010 Status 2011 Status 2012

Environment 5 5 6

Application Versions 112 115 115

Operating system versions 4 6 6

DBMS versions 3 5 8Platform – computing 4 5 5

Platform – storage 1 1 2

Language 4 4 5

Change control mechanism 1 1 1

Scheduler 1 2 2

Period application volatility (i.e., monthly) 2 3 5

Total complexity rating (CPI) 1,920 18,000 149,760

Note: Any value in the abbreviated complexity factor list that hasdemonstrated a change from the previous year has been highlighted with a red font.

Minor changes in support of tactical improvements and shifting business needs canaccumulate a significant affect on the complexity of the IT operation. Individually insignificant steps mark the evolution of the first-year complexity to the situation aftertwo years of operations.

For the second year, the changes were mostly additions, including:

• applications +3

• platform architecture +1

• platform vendor +1

• operating system versions +2 with old versions retained to supportuncertified applications

• DBMS versions +2 with old versions retained to support uncertifiedapplications

• application releases per month +1

During the next year, more small changes occurred in the operation. These were smallimprovements and enhancements for the operations. The net additions were:

• environment +1 for stress testing

• storage architecture +1 for SAN

• DBMS versions +3 with two old versions retained to supportuncertified applications

•

application releases per month +2• standard development language +1

This example shows a slow increase in a relatively quiet operation. However, thecomplexity factor grew over the two years by more than 77 times. Since the operationalstaff did not grow in proportion to the complexity from its starting point of 72 FTE,some aspects of best practice operations were economized over time. This resulted in asignificant number of operational shortfalls, significantly lowered end-user satisfaction,and the occurrence of several substantial service failures.





The cost impact of the complexity is also startling. A summary of the customer IT costsalong with the complexity shows the accelerating effects of the complexity. For thepurposes of this example, the costs and complexity of the first year are used as a setpoint, and subsequent years are expressed in relation to that set point. While thisexample has been significantly simplified for brevity, the correlation of complexity and

operational staffing is plainly an extremely important consideration.

ERP applications, such as SAP, are considered to be complex systems. Thisgeneralization is accurate in that the overall topology of the integrated nature of an ERPsystem makes a comprehensive understanding of the management challenges andcontrols difficult. Complexity in the SAP ERP world can be viewed as a combination of concurrent users, the data (both at rest in the system and in use), and the number of functional modules that have been deployed, in addition to the basic metrics cited in theexample. As seen in the complexity-cost correlation summary, the higher thecomplexity, the larger the effects on costs, as well as the exposure to performance risk and subsequent failure.

One method for controlling complexity is the addition of automated and intelligent

tools, which can handle repeated operational tasks, such as load balancing, productionmoves and storage optimization, etc. This means that the number of tasks, contextswitches and technical frameworks that have to be supported by the operationalpersonnel directly is reduced. The architectural tools can handle individual activities based on either a schedule or rules, and free the staff from those repeated and criticalactions. The relative complexity for a normalized SAP environment for each platformcan be seen in the following chart. Once again the Dell x86 platform running Oracle has been used as the set point for comparison.





The impact on complexity that accompanies each platform is based on the integratedoperational management suite and scripting capabilities. The IBM Power solutions forSAP incorporate tools and functionality that reduces the operational complexity for SAP by up to 36.11%.

“…SAP systems on the Power platformssomehow seem not to be on my Situation report

each day. The staff seems to have the systemwell in hand and they are not complaining ormaking excuses. The company that we just acquired is also running SAP, but on a different

platform. They seem to have the same procedures that we do here, but something isalways getting dropped and causing a

problem. I am not really sure on why theycannot seem to get a handle on it, but it maymean a re-evaluation of the staff for that subsidiary. We just cannot tolerate poorquality operations in our order systems.”

Banking CIO

“The Power boxes are running DB2 for our SAP system have been running with the same staff

and the same SLAs for three years. This isgreat, since we have been trying to control costs, but still provide increased services and

functions. They have setup rules and processesthat automatically adjust workload and doother things that are needed to get ourresources where they are needed, even thoughwe have increased our user base for SAP over

500% in the last two years.”

Manufacturing and Distribution CIO

Scaling

The broad coverage that is inherent with the SAP ERP system means that mostorganizations deploy SAP in phases. These phases can be based on module, function,organizational splits, acquisitions and added customization. Each rollout can have aripple affect on the previously installed operation, with thresholds stressed andtimeframes impacted. Since the rollouts use incremental capacity, the success of theplatform to handle the increased volatility of the workload and schedule pinpoints the





inherent resiliency of the platform, as well as the thoroughness of the integration withSAP. SIL defines resiliency as the ability of the architecture to absorb periodic spikes indemand without additional platform modifications. In a resilient system, occasionalcapacity demands can be accommodated without recourse to additional purchase andconfiguration.

Since in any rollout, the number of transactions, associated data, and processes cansignificantly increase, workload can develop highly spiked capacity demand. A view of the correlation between SAP rollout events and the study platforms highlights theresiliency of each architecture, based on the number of outages in the month following arollout event.

A further summary shows the incidence of unexpected performance problems on thesame platform and time period.





The Power platforms clearly show the architectural resiliency in the significantly lowernumber of outages and negative performance impacts after the rollout events. Thisdifference shows as much as 90.79% fewer outages and 85.16% fewer performanceproblems than the other options. While many of these outages and performanceproblems are small, the resiliency of the Power architecture absorbs the impact of themajority of issues, freeing up the operations personnel to handle any of the morechallenging issues.

“We are in the middle of a 42-step deployment for our SAP system. We have multiplecountries, multiple modules, and are trying tomerge several LOBs into one instance. The

Power platforms are doing very well with thisexpanding demand. In two years, we have onlyhad 4 times that there were significant

performance issues on those boxes, all associated with interfaces and batch

processing.”

Services Organization Director

“SAP has been in the process of deployment forover a year now, with three main waves of deployment completed and six more to go. Wehave had exactly one unplanned DB2 outage inthat time, and it lasted less than an hour. When

I talk with other people in my position, I realizehow lucky I am.”

Head Technical Architect for InternationalOrganization

Security

The security for ERP systems, including SAP, can be very challenging. By nature, themixture of application modules, user profiles, plug-in components and so on, providemany avenues for security breaches. Virtualization is also a factor, since it createsadditional vulnerabilities. If the SAP application security contributions are assumed to be the same across all the platforms, then the underlying security in the platform





architecture can be seen. This forms another layer of protection for customer process,data and intellectual property.

The following chart shows the platform security breaches that were reported in thestudy organizations for their SAP production environment.

It is notable that there were no reported security breaches for IBM Power operatingsystem in either a virtualized or un-virtualized environment during the study period.

“No security breaches in our SAP platformsthat were not from application errors oromissions. The Power box itself seems bullet

proof.”

Financial Services CIO

“SAP in our organization is imbedded in EVERYTHING. And it is a pain to secure. However, we have had no DB2 or Powersecurity problems at all in 3 years of

production. I just wish some of the other boxeswere as good.”

Senior Auditor – Legal Compliance, FinancialFirm

2.5. Conclusion

The Solitaire Interglobal Ltd. analysis of SAP ERP deployments shows that there is asubstantial advantage to incorporating the IBM Power offerings within an organization’sIT architecture, based on a broad set of business and performance metrics. Theseinclude the highest customer satisfaction ratings from both executive and operationalmanagement, as well as the lowest risk rating of all of the platforms included in thestudy. These advantages increase the effectiveness of SAP application deployment andtranslate to real-world positive results experienced and reported by the businesses inthis study.





The economic benefits of selecting IBM Power platform architecture as the SAPdeployment choice are also apparent in overall expense, both from a true cost of acquisition and from an operations perspective. With a close match between quotedand deployed costs, and significantly lower operational cost, the IBM Power platformprovides a strong and stable base for the critical SAP processes.

The strong virtualization functions included in the Power offering also make ameasurable difference. These functions provide the ability to sweep capacity resourcesto targeted processes, and result in the need for fewer overall system cycles. Coupled with the allocation automation, personnel time, hardware, software, and personnel costscan all be minimized. This produces efficient application deployment and cost-effectiveexpenditures, while displaying a risk profile that is substantially lower than the othersolutions examined in this study.

Overall, critical effects on staffing, security, cost and satisfaction, as well as impressivereliability makes the IBM Power platform a strong contender for an organization’s SAPdeployment choice.





About Solitaire Interglobal Ltd.

Solitaire Interglobal Ltd. (SIL) is an expert services provider that specializes in applied predictiveperformance modeling. Established in 1978, SIL leverages extensive AI technology and proprietary chaosmathematics to analyze prophetic or forensic scenarios. SIL analysis provides over 4,100 customers

worldwide with ongoing risk profiling, performance root cause analysis, environmental impact, capacity management, market trending, defect analysis, application Fourdham efficiency analysis, organizationaldynamic leverage identification, as well as cost and expense dissection. SIL also provides RFP certificationfor vendor responses to government organizations around the world and many commercial firms.

A wide range of commercial and governmental hardware and software providers work with SIL to obtaincertification for the performance capabilities and limitations of their offerings. SIL also works with these

vendors to improve throughput and scalability for customer deployments and to provide risk profiles andother risk mitigation strategies. SIL has been involved deeply in the establishment of industrial standardsand performance certification for the last several decades and has been conducting active informationgathering for the Operational Characterization Master Study (OPMS) – chartered to develop betterunderstanding of IT-centric organizational costs and behavioral characteristics. The OPMS has continuedto build SIL’s heuristic database, currently exceeding 95 PB of information. The increased statistical basehas continued to improve SIL accuracy and analytical turnaround to unmatched levels in the industry.Overall, SIL runs over 45,000 models per year in support of both ongoing subscription customers and adhoc inquiries.

Further Methodology Notes

In order to support the comprehensive nature of this analysis, information from diverse deployments,industries, geographies, and vendors were obtained. In any collection of this type, there is some overlapthat occurs, such as when multiple vendors are present at an organization. In such cases, the total of thediscrete percentages may exceed 100%. Those organizations with a multi-layered deployment, such asmultiple geographical locations or industrial classifications, have been analyzed with discrete breakouts of their feedback for all metrics. Additional filtering was performed to eliminate those implementations thatsubstantially failed to meet best practices. Since the failure rates, poor performance and high costs thatappear in a large number of those implementations have little to do with the actual hardware and softwarechoices, these projects were removed from the analytical base of this study.

The industry representation covers manufacturing (19.54%), distribution (17.88%), healthcare (14.71%),

retail (6.69%), financial (17.60%), public sector (13.97%), communications (9.05%) and a miscellaneousgroup (0.56%).

The geographies are also well represented with North and South America providing 39.85% of thereporting organizations, Europe 33.84%, Pacific Rim and Asia 24.48%, Africa 1.30%, and thoseorganizations that do not fit into those geographic divisions reporting 0.52% of the information.

Since strategies and benefits tend to vary by organization size, SIL further groups the organizations by thecategories of small, medium, large and extra large. These categories combine the number of employeesand the gross annual revenue of the organization. This staff count multiplied by gross revenue creates ametric for definition that is used throughout the analysis. In this definition, a small organization could beexpected to have fewer than 100 employees and gross less than $20 million, or a value of 2,000, e.g., 100(employees) X 20 (million dollars of gross revenue). An organization with 50 employees and grossrevenue of $40 million would have the same size rating, and would be grouped in the analysis with thefirst company. The classifications used by SIL use thresholds of 2,ooo (small), 10,000 (medium), 100,000

(large) and 1,000,000 (extra large).

The information in this study has been gathered as part of the ongoing data collection and system supportin which SIL has been involved since 1978. Customer personnel executed all tests at SIL customer sites.The results of the tests were posted to SIL via the normal, secured data collection points that have beenused by those customers since their SIL support relationship was initiated. As information was received atthe secure data point, the standard SIL AI processing prepared the data in a standard format, removing alldetailed customer references. This scrubbed data was then input to the analysis and findings.




Attributions and Disclaimers

IBM, eServer, POWER, PowerVM and System p are trademarks or registered trademarks of InternationalBusiness Machines Corporation in the United States of America and other countries.

Oracle and Oracle Applications are trademarks or registered trademarks of Oracle Corporation in theUnited States of America and other countries.

SAP is a trademark or registered trademark of SAP in the United States of America and other countries.

UNIX is a registered trademark in the United States of America and other countries, licensed exclusively through The Open Group.

Other company, product and service names may be trademarks or service marks of others

This document was developed with IBM funding. Although the document may utilize publicly availablematerial from various vendors, including IBM, it does not necessarily reflect the positions of such vendorson the issues addressed in this document.

business impacts on sap deployments

Documents