Let me apologize from the start for attracting your attention by this title. I will not answer that question. An ITSM thread on a social platform has been running on this subject for several years, with nearly 1000 contributions, with no end in site – and no resolution, either. Not only do I think the question unimportant, I think it is simply the wrong question to ask. Here’s why.
Most organizations are trapped in the logic of the software tools they use. Those tools need to be configured separately for handling change requests, service requests and for any other type of object. If you want to handle the request using your tool, you have to make a choice. It is important to the tool that you decide if you are dealing with a service request, an incident, a change or whatever. But, should it be this way? If the question in the title of this essay is utterly irrelevant to the end user, why is it of such importance to the IT service provider? My answer is that it should not be important. So how do we get out of the trap laid by our own tool, in which we have become ensnared? Therein lies a tale. So please be patient while I tell it.
Fundamentally, there are two types of work we do in IT. On the one hand, we have tasks where the inputs are highly standardized, the outputs are highly standardized and the steps used to handle those inputs and create those outputs are highly predictable. Each time that work is needed, it is done in the same way. Such tasks do exist in IT, but I can hardly imagine the value of performing them manually, rather than fully automating them. Computers are really good at doing such work quickly, efficiently and reliably. People are not.
On the other hand, we in IT do a lot of work where the inputs and the outputs are highly variable and the steps we take to perform the work need to be adapted to each set of circumstances. Whether it be troubleshooting a problem, designing a network, creating some software or negotiating a service level agreement, these are tasks that computers cannot (yet) do on their own. People, however, are potentially good at performing them.
Since this sort of work is essentially concerned with handling data and information, ideas and concepts, we call it “knowledge work”. Unlike manual labor, where we can find a single way of doing the work that is most efficient, where we can practice doing the work and try to perfect its execution, where we are tempted to get everyone benefiting from doing that work in the same way – in short, where we can strive to become like machines – knowledge work is a horse of a different color. We, as human beings, do knowledge work because it requires our flexibility, our imagination, our ability to efficiently get to the heart of the matter. We do it because every case is different.
Now, every case might be different, but there are still some repeatable patterns in the way we do knowledge work. People are really good at seeing those patterns, at seeing their usefulness and benefiting from their reuse. And they are even better at adapting those patterns according to circumstances.
When we do knowledge work, we do not want to be constrained by tools that force us to put work in irrelevant categories. We want tools to do the donkey work for us and to make the relevant data and information readily available to us. We want them to help us improve the flow of our work, to collect relevant data for us automatically and to generate automatically the analyses that will help us improve flow and knowledge. Unfortunately, the vast majority of the tools we use in service management do nothing of the sort. Instead, they make us try to do knowledge work as if we were doing manual labor. For most people working in IT, the paradigms of the service management tools are simply wrong. They help us to do the wrong thing faster and more accurately.
So, the next time someone asks you if a password reset is a change or a service request (or an incident, for that matter), ask them, instead, why they are living in the stone age. Ask them why they are trying to be a poor simulacrum of a machine, rather than being a flesh and blood person doing knowledge work.
