What Is Total Cost of Ownership?
With your vision for 80-90% of the SAP solution decided, core Technical Support Organization players in place, general availability and performance requirements nailed down, knowledge of your technical organization’s core competencies, and an initial budget approved, you are ready to perform the first of many TCO exercises.
But first, what exactly is TCO? Rather than attempting a long-winded all-encompassing definition, consider the following, and refer to Figure 5.1 for a comprehensive visual look at TCO:
TCO analysis is all about determining how to get the best business solution for the least money. But it’s much more complex than simply determining the relationship between computing power and budgets. Instead, a key goal of TCO analysis is to understand the cost-benefit trade-offs inherent to different solutions.
TCO exercises must first of all focus on one-time initial costs, or acquisition costs. One-time costs include both product procurement and product installation costs, including training dollars spent in support of installation.
A valid TCO analysis therefore factors in technology, including the SAP Solution Stack infrastructure and any hardware and software tools that make it up or aid in managing the stack.
An incomplete and misleading picture is painted if only acquisition costs are considered, however. Recurring costs, including the cost of SAP operations and management, maintenance costs, the business cost of downtime, and other day-after-day costs must be factored in as well.
A TCO analysis must also factor in the cost of people qualified to deploy and manage the SAP solution. In some cases, this might represent incremental people, though most often this instead reflects the cost of bringing in people with the necessary unique experience and skillsets.
Finally, a TCO analysis must consider the impact that various operational and other processes have on the overall solution costs.
Figure 5.1. Both acquisition and recurring costs in regard to technology, people, and processes all play a role in determining a solution’s true total cost of ownership.
Given the preceding description of TCO, a TCO analysis can help you evaluate different solution stacks, and even help you weigh diverse people/process alternatives like hosting SAP internally versus outsourcing it. This is possible because TCO addresses both internal (direct salaries) and external (outsourcing contracts) costs, one-time as well as recurring.
Note
In addition to the discussions of outsourcing found in Chapter 3, a “TCO SAP Outsourcing Analysis.xls” document can also be found on the Planning CD. This spreadsheet facilitates comprehensive comparisons between either outsourcing or hosting your own SAP landscape, which is sometimes called “in-sourcing.”
And on top of this, a TCO analysis can be both all-encompassing, or quite discrete. That is, TCO can be expressed in either absolute dollars, or in percentage differences (deltas) between various choices and alternatives. I use both approaches, depending upon the situation, but when I can I lean toward delta comparisons. Why? Because a delta comparison is simpler in that only the solution components that differ between two alternatives need to be examined. A delta analysis doesn’t cover the absolute costs of one solution over another. Instead, it seeks to identify the difference in costs between two different solutions. This usually yields enough information to make a smart decision one way or the other, especially with regard to procurement and people costs. In other cases, though, it becomes a judgment call as to whether one particular approach or solution stack is significantly more expensive than another in the long run.
For example, in the past when I was asked to build and analyze TCO models of a Sun/Oracle solution versus a Windows 2000/SQL Server 2000 solution, each capable of addressing 1,000 concurrent users, I only had to consider a handful of technologies, people, and process issues that differed between the solutions. In the end, the customer deliverable was shorter, more concise, and more applicable than a full-blown total cost of ownership analysis, because it was customer-specific and only took the deltas into consideration.
Consider Figure 5.2, where you see two very similar solutions paired in a delta analysis. Because the solutions are similar, only the differences need to be identified, analyzed, and charted here, making this approach simpler and more practical than a complete TCO analysis. Why? Because solution components with identical costs regardless of the solution alternative cancel each other out. In other words, tracking everything in the solution stack would be a waste of time—only the deltas need to be identified.
Figure 5.2. A TCO Delta Analysis represents a quick method of determining, for example, which solution alternative is least expensive from an operations and systems management perspective.
Solution alternative #1 looks to be more expensive than alternative #2 for a number of reasons. For example, #1 requires twice as many DBAs to administer the same size database for each solution stack, and the acquisition cost of #1 is four times that of the second alternative. However, from a database operations perspective, each is on par with the other. And the costs associated with the remainder of the solution stack are the same, too, in this case, and therefore not analyzed.