Is consolidating ITSM tools in the best interest of CIOs?

As enterprises continue to evolve into digital organizations, the field of IT service management (ITSM) must keep pace. That requires CIOs to assess which, and how many, ITSM tools they're deploying within their IT functions. In this Ask the Expert, Kenneth Gonzalez, research director for IT service management at Gartner, a research and advisory firm, discusses best practices for CIOs to consider when deciding which, and how many, ITSM tools they need within their organizations.

Editor's note: The following has been edited for clarity and length.

Let's start with the basics: What are ITSM tools meant to accomplish?

Kenneth Gonzalez: ITSM tools are designed to give a reliable and repeatable way of performing the tasks and managing the work associated with ITSM competencies. And they're often built into one tool so that it's easy to deal with the need of the different areas to collaborate with each other.

If they're often built into one tool, why is there a proliferation of ITSM tools within any given IT organization?

Gonzalez: A good example of this is configuration management. There's a portion of the configuration items or raw assets that would be used to build a configuration management database and populate the configuration items. There are parts of that that can be discovered by using tools and a portion of that that cannot be discovered. Let's say 80% of that can be discovered, but many organizations have a lot of different tools for discovery. So, how do you choose which one you use? It requires thought and some experimentation. It's not just as easy as saying, 'I'm going to choose this one because it's the best,' because it implies we know what we need and this is the closest match to what we need. In many cases that's just not true.

Kenneth Gonzalez

So, it sounds then that having multiple tools can be good?

Gonzalez: Absolutely. Your ITSM tool is not going to be all things to all people.

Are there drawbacks to having multiple ITSM tools?

Gonzalez: The potential drawback is the total spend. There's always a balance between the tasks and the capabilities the tools provide and what the requirements are to satisfy the mapping between the two. That's the art of the matter. You have to think about that. So, when you purchase a tool, what capabilities does it provide and am I duplicating those capabilities? For what the tool can do, is it giving me the right output?

If you have a lot of duplication, then it becomes a business decision. So, this is where we look at the business outcomes. An alternative way of saying it is: Does it deliver the right business outcomes?

My fundamental definition for ITSM is to reliably and repeatably deliver applications and services at a defined level of quality, cost and performance. It's often characterized in terms of specific business outcomes.

Are most IT decision-makers evaluating thoroughly when deciding on ITSM tools?

Gonzalez: No, because more often than not, what you have is someone who is a technical specialist working in their own area saying, 'I need this new ITSM tool in order to do what I need to do.' This is where the whole issue of the silo thinking is coming into play. While that tool may provide a benefit for them, [IT needs to ask:] Does it fit into the larger picture of how we manage our application services from end to end? Do we actually need that capability? [IT needs to ask that specialist:] Will a new tool make a tangible difference in your ability to do your job? More often than not, the answer will be, 'I hadn't looked at this from that perspective.'

IT leaders have been talking about consolidation and driving out complexity for years now. So, how has it come to this point in ITSM?

Gonzalez: We state what our high-level objectives and goals are and what individuals have for individual goals and there's a big gap in between. And we have a hard time associating this with what the customer needs.

We need to know if the customer is happy and getting what they need, and whether we're producing the key organizational outcomes. If we can't satisfy those three, IT will be dead in the water in making the case for how they add value.

Here's where number is important: If you have duplicate capabilities, then you're paying for tools you aren't getting value from or that make your job harder. If you have tools that overlap in terms of capabilities, then you're spending money you don't need to spend.

So, IT leaders need to use such metrics when assessing which and how many ITSM tools are needed all the time?

Gonzalez: Remember, in my definition I talked about quality, cost and performance. We have to consider the request for new tools against the background of cost and how it materially affects delivery of business value.

This is why I believe capabilities are important. If you don't know what capabilities you need or the level of performance of the tools, then you can go and select a very complex, feature-rich product that doesn't fit with the level of maturity you're at. Too many CIOs don't understand their current level of delivery maturity.

We need CIOs to understand that more so they can actually buy a tool that's well suited for the level they're currently at and then where they want to be at in the next 18 to 24 months so they have some room to grow into it.

A common trap customers fall into is similar to the way [many] go into a buffet thinking, 'I want it all and I want it now.' But can they realistically consume and get value from the entire buffet?

Here's another way to think about it: Based on their current level of maturity, should they be buying a Rolls Royce or a Kia? The difference between the two can be substantial. Do they need the Rolls Royce in order to get done what they need done? Odds are probably not.

We use delivery maturity as a means to help customers narrow down the range of choices to where they're at and where they want to be.

Does this way of evaluating ITSM tools suggest that CIOs shouldn't focus on the number of tools at all?

Gonzalez: Here's where number is important: If you have duplicate capabilities, then you're paying for tools you aren't getting value from or that make your job harder. If you have tools that overlap in terms of capabilities, then you're spending money you don't need to spend. It drives up your maintenance costs and your training costs. And it also drives up complexity. So, we want to be very deliberate about how we go about selecting our tools and using them in our environments.