In this second post on the topic "Demystifying the term process", I’ll explain requirements 2 and 3 of the 10 requirements that something must meet, before we can use the term ‘process’, according to the Unified Service Management method:
1. A process describes what has to happen successively, not the who or how.
2. A PROCESS CAN BE INTERPRETED WITH A VERB.
3. A PROCESSCAN BE COUNTED.
4. Processes are not depending upon practical conditions (◊).
5. Processes have a customer-relevant and unique purpose.
6. A process can be divided into sub-processes, but that does not change the process.
7. A process model organizes the processes.
8. An integral process model includes all service management activities.
9. In an integrated process model, each activity occurs only once.
10. All activities are steered using process control.
Requirement 1 was simple: a process only describes the ‘what’, not the ‘who’ or the ‘how’, otherwise it would have been a procedure or a work instruction, respectively.
When you only describe the ‘what’, you only describe the things you do, i.e., the activities.
Requirement 2: A process can be interpreted with a verb
“Doing an activity” requires a verb. It’s that simple: that's what verbs are for. That verb can then be applied to anything, in terms of applying the verb. But it still is only a verb.
But there’s another side to this coin, a very meaningful one: if it is only about the what, and not about the how, then there cannot be a noun in the title of the process… After all, if it would involve a noun, the thing would include a specific application of the verb to a practical object – the noun. And that would immediately turn the thing into a work instruction.
This object can be anything, from a tangible good to a more or less intangible quality.
Requirement 3: A process can be counted.
The third requirement is also very simple. A process starts with a trigger. This trigger can be an activity (someone asks for something), a situation (an event, e.g., something passed a threshold), an output of another process, an alert or signal, or any other conceivable thing that is capable of triggering the sequence of activities of the process. These triggers can occur any number of times, and as a consequence, the process occurs the very same number or times – even if that process is under a release strategy in terms of bundling its course with one or more other instances of that process. Therefore, the number of times the process occurs can be counted.
The litmus test
Now let’s hold these two requirements against the things that have been called ‘process’ by some many people for such a long time, following up on the best practice guidance of popular frameworks. For instance, there’s millions of IT experts that call Security Management a process. This means I can ask the question “How many securitieshave you done today?”. And I have indeed asked this question many times, at the stage of the conferences where I was invited to speak in the last three decades. And the audience would look at me, thinking “What is that crazy Dutchman asking now? That's a silly question!”.
Indeed – it was a silly question. Even sillier than they perceived – because it couldn’t be answered. For the simple reason that the thing couldn’t be counted – and therefore, the thing wasn’t a process.
I got the same effect when I asked the audience “How many capacities have you done today?” Or “How many service levels have you done today?”. Or “How many personnel and talents have you done today?”,. Or “How many knowledges have you done today?”. Or even “How many Service Desks have you done today?”. Very silly questions indeed!
All of these considerations contribute to the conclusion that the things that were accepted by that audience as ‘processes’, namely Security Management, Capacity Management, Service Level Management, Personnel and Talent Management, Knowledge Management, and even Service Desk, were actually not processes at all. They all contained a noun that indicated an object (a good or a quality aspect): security, capacity, service level, personnel, talent, knowledge, service desk. And they all are not processes, but practices.
Maybe even best practices – but still practices. And, therefore, they fail the litmus test of process.
In next week’s post, I’ll discuss the fourth requirement for anything to be called a process: "Processes are not depending upon practical conditions (◊)"
next post >>
or download the e-book "Demystifying the term PROCESS"