Saturday, February 8, 2014

Process Improvement is not Service Improvement

What is the statute of limitations on ITSM transgressions? I hope they have long past, since I am now confessing some of my past sins.

I used "process improvement" interchangeably with "service improvement".

There. I've said it on the Internet, where everything is indisputable fact. Good to unburden myself like that. It's like a good cleanse.

I'm amazed by how often I come across CSI (Continuous Service Improvement) efforts that list things like fewer incidents or process efficiency as the primary goals. But again, I once did the same thing. Much ITIL and process maturity direction tries to sell the idea that "better" process is all we need to do to reach better service offerings. Process metrics like first contact resolution, mean time to restore, and self service growth are constantly presented as THE way to measure success in IT service management. Of course there are outliers who offer different measures, but the fact that they are outliers speaks volumes.

Here's the confusing part: We are providing a service that is also a product. Customer interactions with individuals delivering the service are part of that service. We call those interactions "providing service" or "customer service". This word service is used all over ITSM, so it's easy to confuse the service product with the activity of customer service.

Let's be clear. Incident management is not a service. It controls a process or series of activities done in order to restore a service to normal working state. Measures of incident management or customer service have no direct correlation to the willingness of customers to consume your service-product. Those measures may have an indirect connection. Please allow me to paraphrase Deming:

You can have great customer service and zero service customers.

(Or in ITIL speak: You can have great service processes and zero service customers.)

This is also true: You can have lots of service customers and lousy customer service (or lousy service processes).

While service process quality is certainly a variable of overall service quality, they are not synonymous. More or better process definition does not mean better service. More process can even lead to degraded overall service-product. (See "Is your IT Team and Budget a Victim of Process Over-Engineering?")
It's well documented that I am not a fan of First Contact Resolution as a success metric. I'll take it a step further and say that ITIL process metrics should never be used to measure service success. Process improvement does not mean service improvement. Service Request process improvement to CMMI level 4 doesn't mean you are delivering an improved service. It can be a tactic used to reach improved service, but it can just as easily end up being an expensive boondoggle that does nothing to improve your service-product.

Service Improvement is about value. Do my customers feel they receive sufficient benefit from their cost investment? Do they like doing business with me?

I've come across ITSM practitioners where their CIO had set a goal of reducing incidents by 2%. And that's their CSI initiative. What the heck does fewer incidents have to do with service value? Enough!

I've come clean. Are you ready to as well?

Edit: I've posted a follow up article to address some questions.