Lowering TCO Through People and Processes

Although the procurement and deployment of technology plays an obvious role in total cost of ownership analysis, you must remember that people and processes play equally key roles. No one area is greater than the other two, as is clearly illustrated in Figure 5.7. Instead, a balance must be achieved.

It is not uncommon, unfortunately, to be inclined to carefully estimate people and technology costs, only to downplay the process costs of a particular solution. Why? Because it’s easy to pull together the one-time implementation costs associated with technology, but usually a bit more difficult to quantify people expenses, and seemingly impossible to quantify process costs/savings.

Attracting and Retaining Talented SAP TSO Members

A key TCO concern when it comes to people is the cost related to employee hiring and retention. In a company where the SAP Technical Support Organization lags dramatically behind IT in general, especially in terms of technology, the ability to attract and retain high-quality IT people can be severely hindered. What highly motivated PC Technician or Systems Engineer wants to continue to support the SAPGUI on a Windows 3.x desktop? What database administrator wants to work in a SQL Server 6.5 environment any longer than necessary? True, there are plenty of qualified individuals, but as in any other IT organization, the most motivated and talented individuals typically propel themselves forward as they have always done, embracing and learning new technology along the way. Meanwhile, those individuals happy playing with the legacy solution stack components I just mentioned are probably the same people you had problems training and moving out of your IBM MVS/XA data center 10 years ago.

Not only is finding these older skillsets sometimes difficult, but the annual recurring costs to retain these skills can actually be higher than the costs of more mainstream solution components. For example, as you see in Figure 5.8, if you are adamant about maintaining a truly vintage solution environment (like SQL Server 6.5 or perhaps an aging server platform), or insist on bleeding-edge technology (like the latest release candidate of a new 64-bit enterprise version of SQL Server, or the latest server released last week), the people-related support costs will be higher than the costs associated with supporting the mainstream product (like SQL Server 2000, or a server platform that has been available for 6–12 months).

So take heed—it is nearly always cheaper to keep the incumbent DBA (or SAP Basis guru, client deployment specialist, and so on), rather than hiring and training a replacement. My recommendation is nothing short of common sense. Keep your talented IT people as long as you can, and have a backup plan. The backup plan should include developing a good relationship with local contract staffing and consulting firms, and leveraging the assistance of hardware and software manufacturers as needed.

▸	For more information on retaining your valuable SAP Technical Support members, see “How to Retain your SAP Staff!” p. 298 in Chapter 8.

Maintenance Costs

Maintenance costs exist throughout the SAP system landscape, and up and down the entire SAP Solution Stack. Server and disk subsystem hardware, operating systems, databases, and mySAP.com components all usually incur annual maintenance costs (one interesting exception, of course, is SAP’s SAPDB database).

Also, consider the costs of hardware spare inventories, especially after five years, the period when many hardware manufacturers quit manufacturing or remanufacturing spare parts. And then consider the fact that, as your ability to stock these spares decreases, the probability of a component-level hardware failure increases. This explains in a nutshell why so many enterprise and other solutions tend to undergo technology refreshes every three years or so—not to mention that most manufacturer’s warranties expire after three years as well.

When it comes to hardware spares, any component or part that is deemed critical to production needs to be carefully considered for “sparing.” Usually this means onsite stocking of any part that represents a single point of failure or is otherwise deemed critical.

Instead of stocking a part that sits in a cabinet, however, other methods of stocking are often employed. A key benefit of standardization is the use of identical components throughout test, training, and sandbox environments, for example. Some of my customers even go so far as to house onsite and offsite spare servers and disk subsystems, sometimes “cold” (thus requiring manual intervention to introduce these assets into production should a failure occur within the production environment), but more often “warm” (ready to be pulled into production automatically upon failure of a critical component).

Stocking is also often handled as part of the service-level agreement process, too. In these cases, fee-based arrangements are made with hardware or third-party hardware sourcing partners to provide a part onsite within perhaps four hours after being contacted. Such an approach makes a lot of sense in metropolitan areas where the overhead costs borne by the sourcing partner related to maintaining such a facility or service can be spread out over hundreds of enterprise customers.

Financial Terms

Financing alternatives, including leasing, offer an attractive method to retain cash in-house for profit-generating activities that would otherwise be tied up in fixed assets. Leasing in particular allows a company to not only stay near the technology edge, but also to let them treat the expenditure as a tax-deductible operating expense (usually).

For companies with little capital, leasing ensures that they have access to the newest technologies today. Even today, leasing remains an attractive method of financing SAP infrastructure implementations throughout businesses of all shapes and sizes.

It should come as no surprise that when it comes to TCO, leasing versus purchasing costs must be considered. As I said before, to assist you in this analysis, I have included a cursory Excel spreadsheet geared toward this exercise on the Planning CD.

Operations and Systems Management Costs

Although it’s admittedly difficult to quantify the operations and systems management costs of a solution that is only being planned at this stage, you still need to take a stab at it. Fortunately, questions like the following can help you put together a delta analysis specific to management costs, as discussed previously:

• Does each layer in the SAP Solution Stack support “manageability” of some degree or other? That is, are there tools, utilities, or management applications available to monitor and manage the various hardware, OS, database, and mySAP.com solution choices you are leaning toward for this particular solution stack?

• How much does each tool, utility, or management application cost to acquire?

• What annual maintenance fees can be expected of each tool, utility, or management application?

• Do the various management tools and approaches work well together? For instance, is there a common management framework that can be leveraged, allowing each tool to “snap in” to the framework? Or do any of the tools require specific agents or other components that conflict with other tools’ agents?

• Does each tool require a dedicated hardware platform upon which to run, or can a common management platform or console be used?

• How long will it take for the SAP Operations and other SAP TSO team members to learn each tool, utility, or management application?

• When it comes to access to professional support/services particular to each management product or approach, what is available? And what are the costs of these subject matter experts?

As for other costs, support for the following needs to be understood:

• Backup/restore-related tasks and responsibilities, like the time required to learn and actually use a particular backup solution, monitoring the backup/restore processes, swapping and managing tapes, and so on

• Testing disaster recovery and high-availability processes

• Supporting change management processes as necessary

• Connectivity to other systems

• Client access approaches via the SAPGUI, WebGUI, and other user interfaces

• Incremental facilities costs (if, for example, a particular server or disk subsystem platform requires power, cooling, or other facilities infrastructure different from the data center’s norm)

For additional management and operations tasks that may need to be evaluated, refer to Chapter 14.

TCO Risk and Risk Factors

A value is often placed on the risk inherent to a particular solution stack or process. Given that risk is usually difficult to quantify, a delta analysis is appropriate here, too. In this way, you can compare the risk of one method or approach or solution to the risk of employing a different one, and quickly determine the cost difference. I like to perform this exercise using something I call risk factors. Risk factors are numbers weighted to reflect the relative risk inherent to changing a particular solution stack layer component.

For example, consider the following scenario with Global Process and Chemical Corporation, or Global, a fictional entity. Global is in the process of evaluating a number of different solution stack alternatives when it comes to their planned APO solution. They are running SAP R/3 4.6C and BW 3.0B today, so they have expertise in the following:

• A number of different mid-range HP Unix server platforms

• Both EMC (used by SAP R/3) and HP StorageWorks (used by SAP BW) storage systems

• Two recent versions of the HP-UX Operating System

• Two recent versions of Oracle’s database product

• SAP Basis layers 4.6 and 6.20

The preceding list represents a baseline of sorts, and will be used to calculate how different changes to the solution stack affect risk. Obviously, Global incurs the lowest risk if they decide to leverage their talent and expertise represented by this baseline. Risk increases as Global deviates from their core competencies—perhaps not a whole lot in some cases, but the idea behind a delta analysis is to identify the impact that each change has on the project’s cost. Thus, as Global considers alternatives perceived to be lower cost, like a Windows 2000 platform, or implementing IBM DB2 on HP’s ProLiant line of servers, they need to factor back in the risk associated with changing their standards and everything that such changes demand.

What is out of scope for this exercise is an analysis or comparison of the procurement or management costs associated with each solution stack layer/component. Remember, this should have already been covered during the solution stack implementation analysis.

In Global’s case, let’s take a look at different solution stack combinations and alternatives, and assign a risk to each solution layer from 1 to 10, where low numbers are less risky than high numbers. Note that a zero is possible, too—in this case, there would be no change to a particular solution stack layer or component.

• Overall, in my experience the risk in changing server platforms equates to something like a risk factor of 1 if the same server line is brought in, a 3 if a new server line is introduced from the same hardware vendor, and a 5 if a completely new server vendor is called upon to deliver the new platform. If the server platform is changed, risk is increased more if the server vendor changes as well. That is, it’s less risky for Global to bring in one of HP’s UNIX-based servers than, say, IBM’s or Sun’s UNIX offerings.

• If a new storage or disk subsystem is introduced, more risk is incurred than in introducing a new server platform. I go into quite a bit of detail in this regard in Chapter 10. Suffice it to say here, though, that the disk subsystem represents the key performance and availability challenge within the solution stack. Risk inherent to introducing a completely new disk subsystem rates a 10 in my book, due to potential issues related to complexity, support, performance tuning, and troubleshooting. Marginal differences in storage (like a new disk drive standard, or incrementally updated disk array controller) rate a 2. A new storage line from the incumbent storage vendor rates a risk factor of 6, however.

• If a new operating system is introduced, risk ranges from 0 (same OS with the same patch or service pack levels), to a 2 (for introducing a new flavor of UNIX similar to the current UNIX standard, like HP-UX and Tru64 or Solaris), to a 4 (for introducing a very different UNIX flavor from the standard, like AIX), to a 6 (for completely different OSs, like Microsoft Windows 2000 Server compared to HP-UX 11i).

• The risk inherent to introducing a new database is also one of the highest. Version changes (that is, Oracle 8i to 9i) represent only a 1, but completely changing vendors (from Oracle to Microsoft’s SQL Server or IBM’s DB2) rates an 8. This is because the database selected for SAP impacts so many other areas—the SAP basis layer changes, backup/restore processes and utilities are changed, DBAs require retooling, the physical layout of disks differs and therefore needs to be addressed, and so on.

• Finally, establishing a new SAP Basis standard introduces its own risks. Minor release changes are nearly negligible (like 4.5x versus 4.6x). Major release levels incur more risk, though, as new approaches to installing, integrating, and managing the basis layer need to be taken into consideration. The introduction of the 4.x basis layer represented a fairly significant change from 3x, for example, rating a 3. The jump from 4x to 6x is a bit riskier, rating a 4.

What about multiple changes? For example, if Global is partial to the low acquisition and management costs inherent to SQL Server 2000, they will also need to bring in a new server platform as well as a new OS! Such a decision compounds the risk of merely swapping out the database layer. Add to this scenario the decision to go with the newest gear available in virtual Storage Area Networks, and practically the entire solution stack represents serious deviations from Global’s standard.

So, to get back to the math, if the most risk-averse strategy for Global is to go with a solution stack for APO as similar as possible to their current R/3 or BW standards, such a low-risk decision would rate a 4, which is simply the sum of the various risk factors, as detailed in the following list:

• Global’s current exact server platform is no longer available. The updated platform featuring faster processors and more memory is very close, however. This rates a 1 in terms of risk.

• Global’s current disk subsystem standard is still available. However, the standard disk drive size and form factor is different, and the firmware on both the disk drives and disk controllers has been updated as well. These minimal changes rate a 2.

• Global’s OS standard is also still available, though the server platform requires an updated OS patch level. This rates a risk factor of 1—a bit more risky than the same exact OS/patch level combination.

• Global’s database standard remains 8.1.7, and is not impacted by either the minor updates to the OS or the requirements of the release of APO to be implemented. Thus, its risk factor is zero.

• The particular release of APO to be implemented leverages the same basis layer as that employed by R/3, so again we have no impact when it comes to risk—another zero.

A risk factor of 4 represents a very low-risk way to go, in light of the fact that we could be looking potentially at a 50 (maximum of 10 for each of the five key solution stack layers). On the other hand, moving to a brand-new vendor’s server and disk subsystem platforms, and introducing Windows 2000 with the same Oracle 8.1.7 release would give us a 21 (5 + 10 + 6 + 0 + 0), more than 500% riskier than staying with a current updated platform. An even riskier decision would be to bring in the new servers, disk subsystem, and OS, and top it off by supplanting Oracle with SQL Server 2000. Such a solution stack would represent a 725% delta in risk compared to the baseline (5+10+6+8+0, or 29 as compared to 4).

Other layers can be added to my master list of five, to create custom TCO Delta Analyses. For example, a Web/Intranet layer would need to be factored in for many mySAP.com components, or if a decision is being considered to deploy one of SAP’s Web-based GUI interfaces. And an integration layer might need to be factored in if a requirement existed here, too.

Similarly, factors that help to mitigate the risks identified so far can be included in the analysis, too. Things as straightforward as obtaining training to support the new components, obtaining contractual access to expert consulting expertise in the event of an emergency, and so on can easily be factored in to reduce the risk unique to each component or layer.

To facilitate your own TCO risk analysis, I’ve included an Excel spreadsheet entitled “TCO Risk Factors” on the Planning CD. Before you begin to use this simple tool, though, I need to conclude our risk discussions by asking that you don’t read too much into the raw numbers in and of themselves. That is, whether a number is a 4 or a 21 or a 29 means little. What matters is the difference between the numbers, the deltas. And what really matters is how these deltas impact the overall TCO story—the end-to-end TCO big picture for a particular solution stack or approach.