Let’s talk about ITSM and ITIL processes. Hopefully, by now, the whole world and its dog have realized that ITIL is a. not a standard to be complied with and b. something that should be “adopted and adapted” as needed. In other words, if your company only needs IT service management (ITSM) or ITIL processes to support service desk operations (or a help desk) then they will only need a small number of ITIL’s 26 processes and four functions.
For me it’s a frequent state of intrigue as to which processes are commonly adopted, which aren’t, and why. And to support my “limited process adoption” view, I’ll often throw out the following opinion:
“Most organizations do incident management and do it well. Many do change too, reasonably well. Fewer still do problem management, or should I say ‘they pretend to do problem management.’ Many started with service level management but failed to see it through. Others might have started with configuration management, and a CMDB, but found it too difficult. Then, more recently, people have been investing in self-service technology but have struggled with end-user adoption. And knowledge management, while popular again, is still a difficult nut to crack.”
I could go on in terms of other ITSM and ITIL processes – such as financial management and capacity management, say – but outside of those already mentioned adoption levels quickly drop off.
This might be okay
The recommended “adopt and adapt” approach encourages people to only use what they need to use. It seems sensible but why don’t more companies need to use more than the commonly-adopted ITSM and ITIL processes?
My pet theory is because they don’t have to. That while they need to have some form of IT support capability – a help desk, service desk, or support center – they don’t necessarily need to do financial management or capacity management, say. They can live without it, with the only downside that they are probably spending more on IT than they should be – but who is ever going to find out? (And yes, I’m being a little facetious here).
Plus, of course, there will be different factors that dictate the need for additional processes. For instance, the size of a company and the industry it’s in will most likely mean more ITSM and ITIL processes are employed due to: the magnitude of IT spend, the complexity of the IT estate, and the need for greater governance. Then we have other factors such as geographic differences or the company’s level of IT and ITSM maturity.
So can we ever know true ITSM and ITIL process adoption levels?
I don’t think we can ever be 100% sure of anything purporting to be a true picture of adoption levels – well not without a massive global survey that slices by geography, size, and industry. The smaller scale surveys that are limited to “members” are sadly biased.
For instance, if we take the results of a tier-one analyst firm client survey as gospel, then we are ignoring the fact that the clients are most likely going to be the largest of global organizations, US-based, and certainly not representative of all global organizations.
Or if we look at an industry body survey, the ITSM and ITIL processes adoption results will reflect the constituent make up of that body. For instance, solely IT support professionals (help desk and service desk staff) who potentially work in a spectrum of SMB through to enterprise companies, across a wide range of industries, but in a single geographic region. Please appreciate that I’m not knocking either of these survey types, I love using them, but we should be conscious of the potential survey bias and relevance.
Alternatively, if we look at an ITSM tool vendor survey, it’s always going to be biased based on customer mix. In the main SMB and lower mid-market versus upper mid-market and enterprise organizations, say. This is not as clear cut as needing a help desk tool versus an ITSM tool (and the associated processes) because other factors come into play, but a bias will still probably be present. SaaS ITSM tool vendors in particular can also see which customers are using which modules or capabilities. For instance, I blogged the following statistics three years ago:
- Incident management – 92%
- CMDB – 82%
- Change management – 68%
- Service catalog – 64%
- Knowledge management – 55%
- Problem management – 40%
Here the customers were, in the main, enterprise and upper mid-market and thus more likely to be using more ITSM and ITIL processes. And, just as importantly, using a tool module doesn’t necessarily mean that a customer would say they are doing the related process (or vice versa). For instance, with the above stats, the CMDB use is very high and I’d bet most wouldn’t say they do configuration management – instead solely using the CMDB, or more specifically the data it holds, to support other ITSM processes. Then change and knowledge management and the service catalog capabilities might be provided by an existing third-party tool with no desire to stop their use.
So is there an answer to understanding adoption levels for ITSM and ITIL processes?
In terms of stating global process adoption across all the organizations that would benefit from ITIL and ITSM processes – not a chance without a massive global survey and the aforementioned ability to slice and dice.
However, if we want to look just at mid-market organizations in advanced ITIL-adoption countries – such as the USA, Netherlands, Australia, and the UK – then we would probably see the most-adopted ITSM and ITIL processes/capabilities looking something like:
- Incident management – 95%. Why? Because industry surveys consistently place incident management as the most-adopted process at between 90-98% (although some surveys are skewed with this ITIL terminology not always being equated to ticketing and “fix when broke”).
- Change management – 80%. It’s more difficult to pinpoint, but change management is usually sitting second behind incident management with some semblance of formal change control required, and thus in place.
- Self-service – 80%. Both SDI and HDI surveys now place self-service, which can range from a single to many capabilities, in the 80-percent decile due to its recent rapid growth in adoption.
- Knowledge management – 80%. This can be for IT or end users, or both and has also seen strong growth on the back of offering knowledge management as an end-user self-service capability.
- Problem management – 60%. Probably a little generous but if an organization says it uses problem management techniques following a major incident then it uses problem management, proactive or not.
Then after problem management there is a steep drop off in process use down to single digits (remember that these are just the top five of the 26 ITIL processes). Please note that these figures aren’t from a single survey, or a scientific amalgamation of surveys, but are instead merely my simple, gut-feel blending of stats that I’ve seen over the years.
You might question why service fulfilment isn’t in the list – for me it’s too hard to pin down given that the latest HDI research shows what many already know, that 27% of respondents don’t distinguish between incidents and service requests, and another 26% distinguish between them but don’t measure them separately. (Source: 2016 Technical Support Practices & Salary Report.)
So what do you think? Do my figures feel right relative to your experiences of ITSM and ITIL processes adoption? Please let me know in the comments.
Principal Analyst and Content Director at the ITSM-focused industry analyst firm ITSM.tools. Also an independent IT and IT service management marketing content creator, and a frequent blogger, writer, and presenter on the challenges and opportunities for IT service management professionals.
Previously held positions in IT research and analysis (at IT industry analyst firms Ovum and Forrester and the UK Post Office), IT service management consultancy, enterprise IT service desk and IT service management, IT asset management, innovation and creativity facilitation, project management, finance consultancy, internal audit, and product marketing for a SaaS IT service management technology vendor.