Demystifying the term PROCESS: sub-processes

In this fifth post on the topic "Demystifying the term process", I’ll explain requirement 6 of the 10 requirements that something must meet, before we can use the term ‘process’ in a mature service management context, 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 process can 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.

In the previous posts we’ve learned that a customer-driven strategy can only recognize processes that have a customer-relevant output. Any intermediate result is only of interest to the provider, not to the customer. For the customer, only the end-result counts.

Software development is not a customer-relevant process

The consequence of the 6th requirement is that most of the things experts focus on (especially in IT), are not relevant to the customer. E.g., software development is an internal activity. The customer couldn’t care less how the functionality is generated, as long as it is. Software on itself is an empty shell. It can only be of value if it cooperates with hardware, network, middleware, housing, hosting, or any other component that is required to create a fully operational facility for a customer. And all of that can only be of real value to the customer, if its functionality is guaranteed by the required support when that facility is used in practice in the customer’s business.

Testing is not a customer-relevant process

The same applies to many other things we’ve learned to call ‘processes’ for the last couple of decades, including testing, monitoring & event management, service design, knowledge management, etc. All of these only deliver a direct output for the provider, and at best an indirect output for the customer. Therefore, at best, they can only be considered to be activities, steps, or provider-centric sub-processes of any customer-relevant process.

Fragmentation rules the show

The fact that – especially in IT – so many providers focus on only very small portions of the customer-relevant facilities and processes, pushes providers to lower levels of the Value Maturity Model discussed in the previous post. We outsource as much as we can, and the number of outsourcing partners is growing exponentially (read the post on Devil’s triangles), creating a fragmented society. As a consequence, the relationships between components and parties also grow exponentially, creating a connected society. And because of all of this, the dependency between parties leads to a dependent society. Whatever approach we follow to make sure the whole thing with all its growing complexity keeps doing what we need it to do, we at least need a control approach at an end-to-end level: an enterprise service management strategy that focuses on complexity reduction. That is where the USM method kicks in: it provides the concept of the universal link that can be used to build endless supply chains and service ecosystems, based on a simple service management architecture. With only customer-relevant processes.

In the next post, we’ll discuss requirement 7: A process model organizes the processes.

<< previous post

or download the e-book "Demystifying the term PROCESS"