Forrester: SaaS adoption is rising, but TCO remains a concern

This is a guest post from Larry Dignan of TechRepublic’s sister site ZDNet. You can follow Larry on his ZDNet blog Between the Lines (or subscribe to the RSS feed).

Twenty one percent of companies are piloting software as service applications, up from 18 percent a year ago, according to a recent Forrester research report. However, even as SaaS adoption increases during the current recession worries about total cost of ownership remains among software buyers.

Forrester surveyed 239 applications decision makers and found the following worries about SaaS:

• Total cost of ownership: As SaaS deployments grow and extend to large enterprises TCO matters. What are the deployment costs associated with licensing, staffing and training?
• Backup and security policies: Vendors need to detail guidelines for security, backup and data recovery based on known standards.
• Contract guidelines: SaaS contract templates are currently hard to come by and buyers often accept vendor terms because they lack existing contracts.

Overall, those gaps appear to be holding back SaaS adoption a bit. For instance, Forrester found that 21 percent of companies are piloting or using SaaS, up from 18 percent in 2007. However, 26 percent of software buyers said they were interested and considering SaaS in 2008, down from 45 percent in 2007. Meanwhile, 54 percent of companies said they weren’t interested in SaaS or didn’t know if they planned to adopt it. That tally is up from 37 percent in 2007.

Add it up and it appears a lot of companies have evaluated SaaS and decided it wasn’t for them.

This slide highlights buyer worries:

And those that are adopting SaaS are sticking to the familiar commodity applications:

Larry Dignan is Editor in Chief of ZDNet and Editorial Director of TechRepublic. See his full profile and disclosure of his industry affiliations.

Lowering Incident Management Costs

February 27, 2009
By George Spafford

There are many means to improve how incidents are managed but the first is implementing an formal Incident Management process, writes ITSMWatch columnist George Spafford of Pepperweed Consulting.

In today’s economy, IT is under pressure to reduce costs and "do more with less". As a result, IT managers are looking for ways to cut expenses wherever possible. Incidents and reactive work are being scrutinized for opportunities to cut costs and therein lies both challenges and opportunities for the groups that understand the type of costing benefit their work may bring.

Costing Overview

One of the concepts often promulgated by consultants, software vendors, and others with an agenda revolve around the costs associated with transactions. The basic premise is if you can remove costs from a transaction then there must be a savings. A common example is to cut the time it takes to do something and then extend it by a loaded labor rate and then display the difference as a “cost savings”. Those numbers then go into business cases and so forth only to make knowledgeable executives roll their eyes as another example of IT not understanding costing.

At the risk of oversimplifying, unless a change causes a reduction in payments, such as to a vendor, or a reduction in labor expenses, then there isn’t a true accounting cost savings. When improvements yield time savings to existing resources or enable less-constrained, lower cost resources to be used (which then free up more constrained higher level resources), then the improvements relate to opportunity cost savings.

Opportunity costs are an economic concept. The premise is if a resource is performing one task, then it comes at the expense of another. For example, if a senior engineer is doing break-fix incident work versus project work to get the organization closer to its goals, then the opportunity cost is that very loss—break/fix firefighting vs. true improvement. All things being equal, we’d prefer the engineer to be working on the meaningful project work.

The organization has opportunity costs as well. If an IT service is unavailable, can the business conduct operations? For example, if an order entry website is down and sales are not possible then revenue is lost and may not be recoverable. When looking at incident costs, as this example shows, it is important to look outside of IT for impacts as well.

What to Improve

With that said, there are typically many opportunities that can be pursued to reduce the costs of managing incidents. Each organization is different but the first step is to assess the current state, compare current practices to best practices and then identify which gaps will yield the greatest benefits to the organization given its stated direction, constraints, available time, budget, ability to change and so on.

The first step is to implement a formal Incident Management process. However, there are limits to the possible improvements within the Incident Management process itself. To generate significant result long-term requires the involvement of other process areas and their respective IT teams. The ITIL v3 lifecycle has five phases that contain opportunities to reduce the costs associated with incidents. The following are examples of phases that could impact the accounting and opportunity costs associated with incidents:

Service Design – If total requirements are understood, proper tools are used and personnel with the right skills are used to create and maintain services then the resulting releases will be of higher quality. The processes in this phase such as Service Level Management, Capacity, and Availability, can all be leveraged to understand and review service design requirements. All things being equal, if services are built correctly then incidents in production will go down.

• Service Transition – Releases should be project managed with proper oversight to ensure budgets, timeliness and requirements are met. Releases that are properly tested and production changes managed will result in fewer incidents long term. The Configuration Management System spans phases and will aid all stakeholders in having a logical view of the IT services being provided to ensure proper planning and fewer errors.
  

• Service Operation – A well designed and implemented enterprise Incident Management process that is followed will create an environment wherein incidents can be managed in an effective and efficient manner. Moving past that, Event Management can assist with a logical approach to identifying criteria relating to changes of state and approved responses further reducing the response times, skills required to respond and certainty of success. In addition, Problem Management and a Known Error Database can be developed to help reduce the number and duration of incidents.
  

• Continual Service Improvement (CSI) – This phase can help ensure that the various processes that affect incidents remain designed in a manner that creates value and mitigates risks. Note, CSI should not be viewed as a project that gets triggered after a failure but rather as an ingrained philosophy. Thus, there should always be a drive to improve how incidents are managed.

Many additional improvement opportunities can be pursue by moving outside of the Incident Management process and working with stakeholders in other processes and functions to improve processes in their areas that will reduce incidents over time. These reductions will definitely benefit the organization. With the current economic crisis, improvements that can cut costs while improving service are sorely needed.

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.

Where's the Fit? ITIL and Project Management Skill

It is always good for professionals to combine the right sets of expertise. For someone involved with IT infrastructure projects, ITIL is a great complementary certification. What I find is that often the specialty knowledge drives the PRODUCT of efforts, but the project management skills drives the PROJECT that produces the PRODUCT. On solid technical teams, that second mindset is often missing.

Background
When you get any level experience in the workplace, you realize that the world is a collection of operations and projects. We are always seeking to systematize where possible, to streamline operations, and to improve results. We are always trying to create a "business as usual", "runs by itself" environment, although in reality the full achievement of this is elusive. For more detail go to www.positive-idea.com We are always cognizant of change in external conditions, and of the need to be proactive in changing our operations when necessary. This intersection of operations and project management, is, I believe, where ITIL and project management come together.

The IT Infrastructure Library® (ITIL®) describes a set of best practices processes for stable, high quality IT services. Project management, as a discipline, provides the capability to implement a defined change in a controlled way, so that cost, schedule, and quality of deliverable are as expected. It would seem that awareness of ITIL in an environment where it is embedded would be an input to project management. Likewise, project management is a great skill to use in implementing and continuously improving the best practices provided by ITIL.

PRINCE2 and ITIL
PRINCE2 and ITIL originate from a single source, the OGC (The Office of Government Commerce) in the UK. While I do not have hard core statistics, ITIL seems to be more strongly on the radar screen in the United States than PRINCE2, probably in part because the PMI PMBOK is more heavily established. But the practice of ITIL does seem to draw on PRINCE2 to an extent due to its common origins, despite the fact that a project management framework such as PMBOK can, in my opinion, be just as effective.

Both ITIL and Prince2 have a mechanism for evaluating the change or project. The Post Project Review in Prince2 is the same as the ITIL Post Implementation Review. A successful review can therefore lead to the end of the project.

Where ITIL and Project Management Meet
IT Infrastructure Library (ITIL) is all about providing service within the operations of IT in an organization. This includes management of the Service Lifecycle, Service Strategy,
Service Design, Service Transition, and Service Operation. It also means continual improvement of the whole set of services that are in place. Management challenges within this realm include Service Desk and Incident Management, Configuration and Release Management, Service Level and Capacity Management, Problem and Change Management, Continuity and Availability Management, and Financial and Security Management.

ITIL itself, as a discipline, addresses the operations within the defined services realm. However, any changes to that services realm can and should be handled by applying a good project management discipline. The difference is that the ongoing operations will be concerned with maintaining and improving services as an in-place, as-is process. The project management discipline will be concerned with defining the beginning of an initiative, delivering the product of that initiative, and turning over the results of that effort to be incorporated into the operation before finally closing out the project.

The two disciplines are substantially different, and using the wrong one can definitely result in lower effectiveness. In the case of ITIL and Project Management, both disciplines will provide inputs the other. For example, ITIL will provide the current situation to a project. It will also provide certain procedures, such as configuration management, that must be followed within the confines of the project. The results, or "product of the project", will become the key input to changes or improvements to be implemented within the ITIL implementation framework in the organization. The professional that understands both sides in depth will be quite valuable to the organization and will have a leg up in knowledge and credibility.

A Little about ITIL (ITIL certification, that is)
ITIL certification has 3 levels: the Foundation Certificate, the Practitioner Certificate, and the Manager's Certificate. Project Management Training Online offers ITIL training in preparation for the Foundation Certificate.

In a nutshell, here is what these 3 levels are about:

The Foundation Certificate: There are no entry requirements, and the foundation test consists of a one hour long multiple choice examination testing a candidate's basic understanding of the principles and terminology of the IT Infrastructure Library. It is designed to provide familiarity with the IT Infrastructure Library (ITIL) best practices for IT Service Management.

The Practitioner Certificates: This is aimed at those who are responsible within their organization for designing specific processes within the IT Service Management discipline, and performing the activities that belong to those processes. The Practitioner's Certificates focus on the depth of understanding and application of those subjects, treating each subject as a specialty. Prerequisites include the Foundation certificate and mandatory attendance at an accredited training course.

The Manager's Certificate: Aimed at managers and consultants, 2 - 3 hour examinations test the practical application of the theory of ITIL, and the exam is typically preceded by a 10-day training event other assessments may also be required. Candidates must hold the Foundation certificate and mandatory attendance at an accredited training course is required.

ITIL v3 is Your Next Step in ITSM

February 20, 2009
By Eddy Peters

ITIL v3 changes enable service-driven processes instead of process-driven services, writes ITSMWatch guest columnist Eddy Peters of CTG.

Most of us still remember June 2007, when the long-awaited ITIL v3 was released. This version would present an integrated approach to service management by covering all aspects of the service life cycle—from cradle to grave and everything in between. The journey was documented in five books called the "core volumes".

On launch day, the itSMF presented the ITIL v3 “roadshow," a document, which to this day provides quality information. The roadshow includes a complete overview of ITIL v3 and answers to questions like Why the need for change? and What is the purpose of ITIL v3? The future looked promising!

To better understand the capabilities of v3, we devoured the core volumes and then carefully evaluated them against the purpose and changes identified in the roadshow presentation. This exercise resulted in the following dashboard, which shows how well the core volumes deliver on itSMF’s promises:

Fig. 1 - Study summary covering all volumes

Early on, we saw that v3 didn’t quite meet expectations. The lack of more practical “how to” guidance was a bit of a surprise. Luckily, itSMF foresaw complementary publications, which would provide more guidance and understanding. But since the complementary material is still in development, we’ve been digging even deeper into the hidden opportunities in the core volumes’ 1,344 pages. Although there have been many informative sessions about v3, the potential is still not fully clear.

So, if you're asking yourself "is v3 your next step in IT service management?" You’ll be relieved to hear that ITIL v2 is still alive and kicking. In fact, v2 is here to stay; alongside v3. Why? Because it’s concise and focused on day-to-day management of existing IT services. Compared to v3, it is a useful "pocket guide" consisting of just two books and 686 pages. So, you can continue to use your existing v2 processes. However, v3 introduces some interesting ideas to further mature your daily activities. Some gems which are worth looking into:

• Request fulfillment: the explanation that was missing in v2 Service Request

• Event management (completely new): guidance for integrating warnings from monitoring tools into support activities.

Among others, these processes round out ITIL’s guidance for optimizing your daily operations. What else is in v3?

Process-Driven Services

ITIL v3 covers much more ground, from development to testing to facilities to operations. New processes like Service Catalog Management can increase awareness of what services are delivered. Service Asset and Configuration Management provide an approach to dealing with service management information. These actions will help build an improved, more mature, process-driven IT organization. This is good, but it could be better.

The full potential of v3 cannot be realized by focusing solely on process implementations or improvements—that’s just ITIL v2.5. The emphasis on processes leads to a new phenomenon: process silos. These are similar to the functional silos we all know so well, which each compete for a share of the budget. Implemented processes provide great benefits to the IT organization (streamlined activities, improved capabilities of specific IT groups, optimal resource usage, to name a few). But these improvements don’t necessarily roll up to the rest of the business. Why not? Because they’re mostly still focused inward; on IT.

Service-Driven Processes

ITIL v3 provides the next step in service management: think service, think life cycle. Service management in the IT organization is no longer driven by processes, but by the elements ITIL was created for in the first place—services.

As the creation of a service moves from business analyst to development to testing to operation, v3 provides an opportunity to align different departments within the IT organization. At that point, service silos are created, competing for a part of the budget. As an interesting side effect, services are outward focused, to the business. If the business derives value, the provided service is funded; if not, it gets retired. That’s what integration is all about.

Even with a few gray areas, ITIL should definitely have a place in the IT organization’s strategy to take the service delivery maturity forward. When optimizing processes, both v2 and v3 add value. When attempting to work out a service-oriented life cycle approach, v3 is there for you. When it comes to answering the question, “Is ITIL version 3 my next step in IT service management?”, it is not so much about If, but how you will do it.

Going for process-driven services (ITIL version 2 & 2.5) or service-driven processes (v3), it all comes down to what your organization wants to achieve, what its maturity level is in delivering service and what its capabilities are to cope with change. The choice is yours.

Eddy Peters is a senior ITSM consultant with CTG, an international IT company with headquarters in Buffalo, N.Y. Mr. Peters has been active in IT for almost 20 years, acquiring experience in both support and delivery capabilities. He had the opportunity to dig into the ITIL v3 framework early on as a beta reviewer, and to understand its potential. With the official release of the core volumes, he became the driving force within CTG to assimilate the knowledge and put it into a practical perspective.

What you can learn from the ITSM process

In order to add value to your company, you have to be as close to the transaction as possible. By having the larger percentage of IT services focused on support processes, you are one layer removed from the transaction and the IT department is doomed to be a cost center forever.

——————————————————————————————————————-

Every time I go down the path of reviewing an existing IT department against the ITSM (Information Technology Service Management) process, it still amazes me how wrong assumptions can be. The purpose of ITSM is to align your IT department and the services it provides to the business. The idea is that you can talk to the business folks and package the IT offerings that IT provides in a way that an IT outsourcer would.

I’ll try to explain that last statement a little more clearly. Let us assume that all the theories (sans Bernie Madoff’s) about the market are true. The whole supply versus demand economic model supports that if there is a need that can be performed more expertly and/or more inexpensively by someone else, then a market exists. You have one party willing to pay for these services and you have a company willing to provide these services. Theoretically, the company providing services exists because it has found a way to add value to a customer that the customer is willing to pay for.

So all of these IT outsourcers (OK, many of these IT outsourcers) have a slick sales presentation and a business model designed to provide a customer better service or more inexpensive services than the company’s existing IT department.

The idea of ITSM is to group your IT services into value-adding products that business managers already understand. You have successfully articulated your department’s value proposition and you as the CIO can objectively compare your services to those of outsource service providers. This is a great tool to make sure that the services you are providing are still relevant and cost effective. You compete on cost, quality, and ability to provide a service. If you can’t compete, then you can proactively seek out an outsource partner to improve your overall IT service portfolio.

So with explanation decently defined, we began the process of ITSM alignment. (By the way, here’s a good book on this alignment process.) You know how all the philosophers say that it’s not the end goal that is the most rewarding, but the journey itself? Well, that’s the case here. When you actually sit down and walk through the ITSM alignment process, much is revealed.

The first step is to look at the business. The core processes of the business can usually be defined or have already been articulated by executive management. Basically, what does your company do to get paid? Then there are other levels of processes. There are supporting processes such as Finance and Human Resources. There are also “Innovation” processes such as Marketing and Sales.

The next step is to identify the IT services that you provide the company. These services are not systems. These are actually the body of work supplied to the company. A financial application may include custom code from programmers, a SAN, a database management system, a set amount of disk space, some servers, software licensing, network resources, help desk support, etc. All of these represent the service of “Providing financial application services.”

After you list the services, you go down the path of mapping IT systems to the IT services. This gives you the necessary granularity to determine the costs of providing this service. How you determine the actual costs can be somewhat more art than science. You can be general by figuring out how many U the financial application takes up in a server rack and use the percentage of data center costs by that or you can get really granular and look at power consumption, CPU utilization, network bandwidth, and disk space. The important part is getting in the ball park.

What I’ve found twice now in performing this exercise with two different companies is that when you map the IT services to the business processes, there is a disconnect as to where the IT services are focused. A huge percentage of time and resources from IT are spent, not in direct support of the core business processes, but in support of the Support or Innovation processes.

A wise friend once told me that in order to add value to your company, you have to be as close to the transaction as possible. By having the larger percentage of IT services focused on support processes, you are one layer removed from the transaction and the IT department is doomed to be a cost center forever.

Instead, look for outsource partners that can support the support processes while you and your team focus on supporting the transaction and how the business makes its money. This way you insure IT’s role in adding value to the organization.

A successful IT executive with 15 years of technology leadership, team building and value creation, Jay Rollins has served as VP of IT/CIO of several mid-sized companies and technology start ups. He has varied industry experience including gaming, media and entertainment, healthcare and ecommerce. Jay received an MBA from Bentley College in Waltham, MA and founded PicoMatrix in 2008.