Microsoft Windows and Linux-based SAP technical platforms have garnered a great deal of attention in total cost of ownership (TCO) circles. Hardware acquisition and maintenance costs for these platforms are historically a fraction of the cost of their big-iron counterparts, and access to people possessing commodity operating system (OS) and hardware skill sets is growing. Perceptions based on cursory TCO analyses have created a whirlwind of mystery and hype: For example, Windows is cheap, Linux is cheaper, and Unix no longer has a home in anything but the largest SAP technical implementations.
Behind this hype lies some truth. Windows-based SAP implementations and OS/database upgrades can prove much less costly to install and maintain than their Unix counterparts — 20% to 50% less than comparable Unix-based systems. With their similarly low start-up costs, Linux-based systems might appear extremely affordable at first glance as well. However, behind the unknowns, rumors, highly qualified if-then factors, and vendor-initiated smoke and mirrors lies a wealth of ambiguity — not to mention a number of precepts that simply are no longer true.
Any of the technical platform options supported by SAP might be viable for a given company, depending on the circumstances around how its staffing models, IT processes, and technology standards converge to create a unique cost model. The following five methodology tips will help you identify your company’s cost model and, in turn, your best SAP platform choice as you upgrade from SAP R/3 to mySAP ERP.
Methodology Tip 1: Ask These Questions at the Start
Even though each prospective TCO analysis, replatforming discussion, or similar endeavor begins in a unique way, internally focused questions similar to the following help to set the stage while confirming the potential for true platform-related cost reductions:
- Why are you having these replatforming discussions? What’s really on your minds? Do you have any hidden agendas that you need to get out on the table? Are you facing a mandatory technology or application refresh or is another key inflection point on the near horizon? Is your outsourcing contract near its expiration? Or do you simply find some of the new technology platforms for SAP interesting enough to discuss further?
- Do you know your TCO — what IT Infrastructure Library (ITIL) proponents term your “cost to serve”? Are you doing a good job today of serving your business?
- Why was the technology stack or solution approach that you currently use for SAP chosen? What kind of technology stack or solution approach do you think may be potentially better suited to your new mySAP ERP components going forward? Why?
- Are there any surprises among your enterprise-class technology and other IT standards, skill sets, and biases? Do you need to understand any old decisions or relationships in light of where your company is today or where the business or your CIO seeks to take you?
- To what degree might low-cost technology approaches improve — or at least help you maintain — the status quo in reliability, high availability (HA), disaster recovery (DR), performance, scalability, agility/flexibility, or ease of management? Are you happy with your system’s performance but under pressure to reduce costs, or do you need to balance availability, scalability, and your checkbook better?
- What are your technology showstoppers in terms of availability, scalability, performance, and so on with regard to how well you support your business? Will new technologies fill in the gaps, or provide more of what you need? If so, to whom can you talk who’s been there and done that?
- How good are you at individually and organizationally embracing and adopting change? Where are your biggest challenges in this regard? Operations? Hardware support? The help desk? Your SAP Basis team?
- How must your costs change to be worth a technology migration or replatforming effort? In other words, what kind of minimum return on investment (ROI) will get your CIO’s or the board of directors’ attention? What is the minimum cost savings worth pursuing — do you need to save $5 million over three years, or will a cool $1 million a year do the trick?
With questions like these, IT shops ill-equipped for change are better positioned to understand their internal state and its inherent challenges. The process of honestly answering these questions, and any follow-ups, is both difficult and time-consuming. A neutral consultant or other third party can greatly facilitate the discovery process, although the IT/business team has most of the knowledge necessary to evaluate high-level TCO. IT is just missing the comparative data and context to give meaning to its own numbers and findings — data points that the right third party can and should bring to the table.
As these types of questions come up, focus not only on the end-user and batch/reporting loads that your current systems host, but also on how these workloads might evolve in light of a mySAP ERP upgrade. Are company acquisitions or divestitures on the horizon? Are pending regulatory or similar policy changes expected to drive business-process changes? Are any new business units soon to join your SAP user community? Is there potential for significant growth in new SAP modules in the next few years? Such fundamental changes in the landscape can drastically affect both near-term and future technology viability and other factors driving today’s decisions — especially those intended to save money.
The scope is clear: To evaluate the responses to these questions, review each SAP system landscape relative to SAP-centric technology, IT staffing/people, IT management, and other processes, and help your IT organization to build an authentic business case that describes its actual state. Next, look at any number of alternative strategic directions and build just as many potential “what-if” business cases. Then, let the numbers do the talking as you iteratively re-evaluate and fine-tune each business case and its limiting factors to reflect real-world challenges — your strengths, biases, lessons learned from other SAP shops, and internal trials. Remember, the limiting factors are many, even if they aren’t always clear. Workloads change, HA and DR requirements grow stricter, business service-level agreements (SLAs) become tighter, and acceptable business risks ebb and flow with the economy and the company’s financials.
Methodology Tip 2: Keep These Key Factors in Mind
You can assess TCO for SAP in many ways using different processes, timelines, and data points. Over the last few years, I’ve refined the following approach:
- Focus on technology, people, and process costs. Create buckets of cost and take special care not to miss or count costs twice (which is easy to do). Processes (such as those associated with backup/recovery, high availability, or systems management) naturally hinge upon the need for technology and people. Segregate the cost of creating, executing, and maintaining these processes from the people who actually execute them and the technology used to make it all happen.
- Include acquisition or up-front costs, as well as ongoing or operational costs. Don’t forget to include incremental acquisition costs that might be planned three years down the road. For example, you might need to factor a leased-server refresh into the equation.
- TCO analysis is called for by organizations seeking to identify and reduce their TCO. For organizations new to SAP or TCO analysis, neither the process nor the data points are well defined; it might be difficult to know whether a particular cost is exponentially off the charts, for instance. To add context to these unqualified numbers, solicit third-party data points or assistance from folks with access to them. After all, a company executing its own analysis has little information against which to compare itself. Gartner can provide industry context, while other SAP shops can theoretically provide real-world comparative data.
- TCO-oriented projects are usually funded with the goal of quickly uncovering and minimizing the most significant cost factors. Of course, an organization might wish to drill down into more complex costing scenarios (such as indirect costs associated with training and system availability) once it has established a basic framework. To avoid a never-ending cycle of TCO analysis, establish the project’s scope and timeline up-front. You might decide, for instance, that you seek a TCO “stake in the ground,” setting an end-time on the evaluation after eight weeks focused primarily on uncovering operational costs and potential savings, rather than looking at historical acquisition costs.
An approach I have seen used successfully over and over again is by design something short of comprehensive. Instead of spending three to six months trying to piece together an organization’s end-to-end TCO, you can wrap up a meaningful assessment in three to eight weeks. To do this, limit the analysis timeframe to three to five years and limit the scope of the TCO analysis project itself to comparing only two potential future states rather than six or eight or 12 alternatives. Save all the other time-consuming what-if iterations (what if we dump Oracle in favor of SQL Server? what if we outsource infrastructure support? and so on) for later.
Methodology Tip 3: Take a Delta Approach to TCO Analysis
To quickly analyze platform-driven TCO, I sometimes calculate only the deltas between two or more different solution approaches, rather than assessing all SAP costs on all fronts. This method of uncovering differences in TCO is unique in that you can complete the entire process more rapidly than if you employ a more comprehensive TCO analysis approach.
A delta approach helps to speed decision-making. By reviewing an SAP environment from the technology, people, and process perspectives and then only spending time analyzing the relevant differences between two proposed systems, you not only save time but also focus on the potential business opportunities where business, technical, and staffing realities come together.
With such complex environments as those associated with SAP, even assessing only the delta factors between two potential approaches seems time-consuming at first glance. In my experience, the compelling TCO factors amount to only a few key layers in the SAP technology stack along with a number of people and process considerations. As I work with companies to identify and quantify a “rough order of magnitude” opportunity to reduce its costs, I focus first on broad differences or impactful decisions such as:
- Deploying very different operating environments (e.g., Windows versus IBM AIX, Sun Solaris, or HP-UX). A new Microsoft Windows Server environment configured to host the same workload and provide for essentially the same level of performance and planned uptime as a new or refreshed Unix or similar environment constitutes much of my real-world experience.
- Deploying Linux or Windows on an industry-standard platform, especially in terms of people (support) or database costs.
- Deploying very different relational database management system (RDBMS) platforms (e.g., Microsoft SQL Server versus Oracle or IBM DB2) and how that plays out in hardware needs, average online and batch job performance, and maximum scalability or “tunability” down the road.
- Deploying different server or disk subsystem platforms, and how these different approaches drive costs while influencing immediate needs versus future capabilities (such as system scalability, and the ability to support partitioning, consolidation, or enterprise agility).
- Using SAP outsourcing versus SAP hosting versus insourcing SAP systems on any number of platforms managed by an IT group with any number of skills, competencies, and adaptability to change.
When I use this technique for a client, I might present an alternative to the option a client is predisposed to favor (X versus Y versus Z), one I believe has greater potential to meet the organization’s needs while playing to its strengths. Once the alternatives are identified and bought into, I identify the delta dollars between the two or three alternatives over a theoretical three- to five-year life cycle (or three- to six-month OS/database platform migration followed by a steady state of three to five years), using client-provided, industry-published, and other data sources.
Given the delta nature of this analysis, the bottom-line TCO figures represent nothing more than the bottom-line difference between one platform and another — not a complete all-encompassing TCO model, but rather a quick and effective way to compare platform decisions while taking into account important people and process factors. This approach to TCO analysis illuminates key cost considerations in adopting one platform over another, factoring in a client’s unique requirements, advantages, and constraints. Thus, the resulting TCO model is not expressed in absolutes but rather in differences — differences in technology, people, and process costs.
Methodology Tip 4: Take Indirect Costs into Account
Each component and dimension so far has focused on direct (hard) rather than indirect (soft) cost factors. Direct costs are easiest to spot, as these are often the ones for which a company must write a check — procuring hardware and software, payroll, and the like are direct costs. Indirect costs are more difficult to identify and quantify. Soft costs include those for unplanned downtime in the first hour a system is unexpectedly unavailable (loss of productivity or expected loss in customer-retention), the different costs associated with the twelfth consecutive hour of unplanned downtime, the soft costs associated with peer-based training, which affects both short-term and long-term productivity. Additional examples of soft costs include:
- Physical-plant costs (shared resources, such as power, cooling, floor space, and other shared infrastructure or overhead)
- Cost-avoidance factors (such as the ability to avoid another necessary upgrade to hardware or software if a different platform is selected, or the ability to avoid load-testing or other risk-mitigation services if a particular platform decision is made)
- The desire to retire certain assets (older hardware, other old/out-of-maintenance infrastructure) versus the mandate to do so
- Any value you might assign to “risk of change” (e.g., it might make sense to add a 10% “risk factor” into a migration or technology-refresh plan to unknown or unfamiliar technologies, especially when the plan involves a mission-critical computing environment)
- Retention and recruiting costs specific to one SAP solution approach over another
- Simplification and standardization costs (how much does it cost to maintain multiple IT standards versus one or a few, and what is the trade-off in required formal and informal training?)
- Strategic “costs of delay” (e.g., every month the decision to pull an outsourcing contract back in-house costs or saves money, depending on the delta between the in-house and outsourcing costs)
- Other costs such as hidden costs, termination costs for an outsourcing agreement, or those incurred because you decide to introduce complementary unnecessary changes into an environment while making required changes
Don’t forget to factor in time. Time complicates a TCO assessment. For example, month-end business processes might constitute much of the “regular recurring” risks of replatforming for one customer, while another company by using shared services might seek to optimize its IT support organization based on monthly and quarterly workloads. Other organizations challenged to reduce planned downtime by applying fine-tuned systems-maintenance processes will evaluate system flexibility differently than less sensitive customers. Soft costs significantly affect a TCO model.
Methodology Tip 5: Be Comprehensive When It Comes to Data
It’s important to introduce real-world comparative data into TCO modeling, essentially building a framework from which you can derive context. Several data-collection methods and sources will help ensure that you make a decision based on real-world strengths and shortcomings. For example, an organization seeking to build its own TCO business case should take advantage of the great breadth of publicly available data (or nearly so) and constantly changing data points available from the following sources:
- Companies such as Gartner, IDC, Forrester, and SAP regularly publish data points to establish general and current bases of reference. Remember, the landscape is changing as quickly as ever, and yesterday’s strategic or first-rate differentiator might be in everyone’s driveway today.
- SAP platform providers can describe the breadth of their solutions including reference-account information and market-share numbers. I prefer independent sources when I can get them, but the information published by various SAP solution and service providers is typically good. Look to vendor competency centers and consulting organizations for the most real-world information.
- Data gleaned from current clients running SAP is enormously useful. With a bit of luck and relationship-building, these organizations can provide the kind of information that helps support a particular position by virtue of “been there, tried it, didn’t pan out like I expected” real-world data points.
- Some of my own data points reflect the findings and conclusions of organizations that have adopted new platforms for SAP and how these transitions paid off. I am particularly fond of data reflecting the transition from Unix/Oracle and IBM/DB2-based solutions to Microsoft or Unix/Linux. Other data points reflect the decision by clients to stay put. This data becomes especially compelling when I can draw parallels between more than a few companies or IT organizations – there’s much value in trends that actually prove successful.
- Quarterly platform-specific “trend” data tracked and published by SAP and HP’s Global Competency Center, for example, round out my own client-specific, as well as industry-trend-specific, data sources. Much of it is available through your partners and account teams, although it tends to be held rather closely.
- Other sources that are less than scholarly provide good points of interest. For example, third-party vendors with a vested interest in promoting a particular technology or platform can provide reference-able data. If you can corroborate a particular position or identify a common thread among different SAP vendors, you will naturally give greater credence to their combined findings than otherwise.
The best TCO data sources hail from actual long-time SAP clients. After analyzing a new client’s unique workload, user counts, and technology standards, I map this information back to an existing set of information reflecting perhaps 10 or so similar clients for which I have data points — clients that closely resemble one another from a business or workload perspective despite differences in their technology stacks.
Comparing Apples to Apples
The idea is to illuminate the various solution approaches used in the real world to host a particular SAP workload, and then drill down into their technology, people, and process costs to uncover the real-world high-level costs. I might compare them to some other organizations, taking care to compare organizations of similar size, technology platform, business applications, and so on — whatever is uppermost in the minds of those seeking validation or pursuing comparative analysis.
Although the different companies may vary greatly in the technology stacks deployed for SAP, they should be close to one another in workloads, overall database sizes, and monthly growth. I would also take into account the number and mix of mySAP ERP or mySAP Business Suite components deployed, whether the company’s SAP IT organization has been outsourced, and the depth and breadth of data points to which I already have access.
I’ve highlighted technology, people, and process considerations that help create low-cost TCO models predicated on any number of platforms. Remember, each company’s situation is unique. Staffing models differ greatly, as do process and technology practices. The best answer for SAP IT shops today might not be the best solution – even for them – tomorrow or next year.
|George W. Anderson is a senior technical consultant and project manager for HP Services’ SAP National Practice. An SAP Basis consultant by trade, he is a certified SAP technical consultant, as well as a PMI PMP, MCSE, HP Master ASE in SAP, and more. He is the author of the popular book SAP Planning: Best Practices in Implementation (Que, 2003), among others.