In-Depth

Technology Is The Source Of Your Enterprise Management ROI ... Not!

• 10/01/1998

The news on enterprise systems management (ESM) is out, and it is not encouraging.

For years, IT managers have struggled with the high costs of managing distributed systems. As companies continue to migrate from mainframes to distributed platforms, and to roll out distributed applications, from SAP R/3 to Lotus Notes to corporate intranets, IT organizations have been overwhelmed by the challenges of keeping critical business services available and responsive.

Faced with an ever-increasing management burden and pressure from top-level executives to keep costs down, managers looked to ESM technology as the "magic bullet" to put them back in control and help them lower their enterprise management Total Cost of Ownership (TCO). Many have undertaken ambitious projects to centralize and automate management functionality using ESM "framework" technology and/or point solutions from a range of vendors.

Unfortunately, recent evidence indicates that the vast majority of such projects do not succeed. Gartner Group research shows that 70 percent of ESM packages are not fully implemented, even three years after project initiation. And a survey of IT managers performed by International Network Services (INS) could find none who rated themselves "very satisfied" with their NSM (Network and Systems Management) cost of ownership, and only 12 percent who were "somewhat satisfied."

What accounts for the low success rate? Vendors are partly to blame for "overselling" their solutions. However, analysts agree that the real barrier to achieving ROI on an ESM investment is a lack of planning and resource allocation by (overburdened, underfunded) IT organizations. In their rush to achieve the benefits of ESM technology, managers consistently overestimate the ease of implementation and underestimate the TCO of the software, focusing on the purchase price, but ignoring the costs and challenges of implementation and daily operation. As a result, their ESM projects wind up running over budget, eating up staff time and delivering far less functionality than managers expect.

ESM technology remains essential to the smooth operation of distributed systems, and analysts agree that, in the near term, most companies will find themselves spending more, not less, on management as they move to increase efficiency and accommodate new technologies through automation of management processes. However, technology alone is not a panacea. In evaluating a new enterprise management investment, managers must be certain the project addresses business goals, and that they have the skills and processes in place to take advantage of the new technology. After all, as one IT manager put it, "Automating a mess only makes things messier, faster."

It seems self-evident that, before undertaking a complex and expensive (or even a simple and cheap) management project, one would want to establish a goal for that project. Yet, all too often, IT managers embark on complex ESM initiatives without knowing precisely what they hope to accomplish. Under pressure from top management and end users to "do something," managers may jump on the ESM technology bandwagon without developing a strategic plan. This is a recipe for disaster.

According to Ray Paquet of the Gartner Group, there are only three legitimate reasons to undertake a systems or network management project:

Lower Costs: An IT organization may undertake a project in order to lower the cost of management. Frequently, organizations seek to reduce the number of Full Time Equivalents (FTEs) required to perform a particular management task, or to head off the need for new hires. Cost savings may also be achieved through reduction or elimination of costly or redundant management hardware/software or processes (for example, reducing calls to field technicians by filtering and correlating alarms). In some cases IT may have established explicit Service Level Agreements (SLAs) with internal or outside customers, and cost savings may come from avoidance of penalties related to these SLAs.

An example of an ESM project focused on cost reduction is Ontario Hydro, which recently completed a project to consolidate network and systems problem management across its vast, heterogeneous, enterprise network. Aaron Cheng, the IT Manager at Ontario Hydro, based his cost justification in part on a chart that showed the number of FTEs per managed technology (microwave, UNIX servers, SAP R/3, etc.) with and without the ESM project. The chart projected that the company’s managed technologies would grow from three to thirty-nine, and that, without automation to reduce the FTE/technology ratio, staff costs would spiral out of control. This formed the base justification for the project.

Improved Quality of Service: Another possible basis for cost-justifying an ESM project is projected improvements in service. Again, these improvements must be tied back to business benefits in order to offer a quantifiable return. For example, a projected 1 percent increase per year in system uptime might be worth as much as $10 million to a Wall Street brokerage, $100,000 to a bank supporting a network of ATMs, and $1,000 to a workgroup LAN in a law firm. Similarly, an improvement in network response time will be worth different amounts of money to an online retailer, a credit card processing company or a service provider.

An example of an ESM project focused on improved service is TSR Wireless, which undertook a project to consolidate alarm data from its transmitters across the country. Prior to undertaking the project, transmitters were frequently down for hours or days, receiving maintenance only after customers complained. IT’s justification for the project was based in large part on the business value to the company of increased network availability from improved uptime of the transmitters.

Reduced Risk of Catastrophic Failure: Some management projects – backups and disaster recovery, for example – are designed solely to protect the company’s data and computing processes from failure. The business case for these projects is similar to that for purchasing insurance. The risk of failure must be weighed against the potential cost to the company from loss of data or systems availability. Wall Street firms, with the most to lose from disaster, typically spend large sums to ensure total recoverability and uninterrupted processing in the event of failure.

An ESM project may address more than one goal, and may well address all three. However, keeping the focus on one of the above categories makes ROI justification easier and, during deployment, reduces the chances that "mission creep" will pull the focus of the project away from achievement of the benefits specified in the ROI analysis.

Once clear, measurable goals have been defined for a project, managers can begin to evaluate tools. In evaluating various solutions, the single greatest mistake made by managers is underestimating the TCO of the tools. Gartner Group estimates that acquisition costs represent as little as 5-20 percent of TCO, and the more complex the solution, the closer that number will be to 5 percent. The true costs break down as follows:

*Planning and Evaluation: This includes the requirements analysis, ROI cost-justification, RFI and RFP, and the costs associated with evaluation of the different solutions and of the vendors themselves.

*Acquisition: This is the cost of the hardware and software itself.

*Implementation: This includes the costs of installing and customizing the solution, integrating it with the existing IT environment, running the pilot program, and training IT staff and end users. Frequently, it includes large expenditures on professional services.

*Operations: Once the solution has been implemented, IT incurs ongoing operations costs, including staff time running the solution, hardware maintenance, software upgrades and further customization of the solution, and management (backups, security, etc).

Unless the TCO of a solution is fully taken into account, management projects are unlikely to provide ROI, and may even make things worse. Jeffrey Kaplan of INS offers the example of performance management tools, which were adopted by many IT organizations seeking to optimize network or systems performance. Unfortunately, managers failed to consider the TCO of the tools, which require a significant amount of customization and configuration prior to implementation, and daily administration in response to moves, adds and changes. As a result, organizations may have improved performance, but they frequently wound up adding one or two FTEs to do it (again, the value of such a trade-off would be based on the cost of an FTE compared to the revenue gained from the increase in performance).

Inevitably, measurements of the potential costs and benefits of an ESM project will be based on assumptions: about the department’s ability to achieve its goals, the value of network uptime, the growth in size or complexity of the IT environment, the time to implementation, the staffing requirements, the ability of the business units to transform improved system performance or data delivery into corporate revenues. While itemized cost-justifications may not be necessary for small investments, the exercise is invaluable for medium and large projects. To the extent possible, IT organizations should benchmark existing practices and base estimates on historical information (revenue per employee, total system downtime, average time per help-desk call, etc.), although such information will not always be available.

Finally, TCO of an ESM project includes the risk that the project will fail to meet its goals. This risk may be quantifiable, but whether or not a dollar value is placed on it, a general rule holds: the more complex the project, the greater the risk of failure, and therefore the higher the ROI one should expect.

Of course, identifying a theoretical ROI from a management investment is one thing; delivering the benefits is something else. Even with clearly defined goals, solid technologies frequently fail as a result of a poorly thought-out or managed implementation. One common stumbling block has been mentioned above: failure to adequately consider the full TCO of the software. Others include:

Lack of Skilled/Experienced Staff: While companies can expect some out-of-the-box functionality, there is still a lot of customization and configuration work to be done to suit the environment. Products must be installed, configured, customized and integrated with the existing IT infrastructure and with other management tools. Frequently, managers overestimate the ability of their staff to take on these tasks, and underestimate the time required for staff training. The results are added expenditures for professional services, or abandonment or scaling-back of the project.

Failure to Demonstrate Quick Results: While the full ROI may be based on longer-term benefits (1-2 years), ESM projects must demonstrate tangible benefits early if they are to gain support from top management, IT staff, and end users. TSR Wireless, for example, was able to reduce its telephone bill by 50 percent as a result of consolidating the alarm stream from its transmitters; this generated support for later phases of the project with more significant, long-term benefits. Gartner Group suggests that if implementation time for an ESM project is over nine months, the company should consider alternatives.

Overambitious Implementations: Lured by vendor promises, many managers have undertaken large-scale ESM projects, attempting to standardize on an enterprise-wide systems management infrastructure or implement a comprehensive suite of solutions from a single vendor. Such projects may take years to complete; are highly complex; and frequently require a cadre of highly-skilled technicians to implement. By focusing instead on one issue at a time and selecting a tool that best fits that particular management discipline, IT managers have a better chance of meeting achievable goals. Of course, small projects can be seen as discrete steps in an overall ESM automation effort.

Failure to Perform Adequate Vendor/Software Evaluation: Seeking to reduce costs and get the ball rolling, IT managers may skip the evaluation phase, opting instead to purchase the "hot" solution, the least expensive one, or software from a vendor considered "safe." This false economy can cause numerous problems: "hot" new technology is frequently untested and less mature; cheap software may be very expensive to implement; and the "safe" choice is only safe if it meets IT requirements. Managers should also evaluate the vendors themselves, taking into consideration financial stability, customer loyalty, and the vendor’s willingness to work with the company. Vendors should also guarantee a migration path to future versions of their solutions and ongoing support for users of older software versions.

Failure to Tie ESM to Business Requirements: Another barrier to ESM success stems from the technology focus of many IT departments. Frequently, IT managers undertake projects that offer measurable ROI in terms of the managed technology – for example, an increase in network speed – but fail to make a connection with an actual business imperative. If the business units don’t need a speedier network, the project is a waste of time, despite the fact that it has accomplished its "goals." IT needs to work with business units to determine how investment in management can have the greatest impact on the bottom line.

Lack of Effective Processes/Organization: Finally, and most importantly, an IT organization must have established disciplined practices for carrying out management activities. Enforcing clearly-delineated management practices across the IT department make it easier to define requirements for management software, and to identify software in which the vendor’s methodology best suits the existing processes. Of course, any ESM tool will require some re-engineering of management practices, and will render others unnecessary, but if discipline is established beforehand, it will be easier for IT to make those adjustments.

Conclusion

As the widespread disappointment with ESM projects proves, management technology alone cannot suffice to solve the most pressing enterprise management problems. However, by establishing and enforcing standard management practices and undertaking small ESM projects with clearly-defined goals, managers can beat the odds. "You invest in the project and then you see results coming through that match exactly what you set out to do," explains Cheng of Ontario Hydro. "That’s quite gratifying."

ABOUT THE AUTHOR:

Saverio Merlo is Senior Vice President of Marketing for Boole & Babbage (San Jose, Calif.) and has been with the company for 17 years. He is closely involved in the development of new business opportunities, including acquisitions and partnership agreements with other software and hardware vendors.

To sidebar