In this sixth post on the topic of "Demystifying the term process", I’ll explain requirement 7 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 practices are not processes, and that a customer focus requires that processes should be defined from a customer-relevant perspective. Now let’s presume we have determined what these processes are (I’ll discuss that in a later post), so we can take the next step and put these processes together, in one model. The 7th requirement for one process model is easy to understand: an efficient management system must be singular – by definition. . As the management system is based on the process model, we simply can’t have two or more of either of these.

There must be one captain on the ship, one steering wheel in the car

Frogs in a bucket

Many organizations suffer from having more than one management system. This is often caused by the island perspectives that the involved teams take: these teams reside on a lower level of maturity in terms of the Value Model Model, as they perceive their contribution to the enterprise from an isolated perspective, an island. They then manage that contribution in a rather independent way, as if they were king on their own island. They act like frogs in a bucket – jumping in any direction they think is best, from their perspective – not the singular enterprise perspective.

It is relatively easy to determine their maturity position, as their service agreements (if they have any at all) are stuffed with internal KPIs, emphasizing their internal focus. This is what we see in DevOps: a tilted silo with lots of new IT shops that focus on change, each using similar techniques, but often failing to act as a coherent set.

Collaboration requires integration

If the involved teams want to contribute to the enterprise’s achievement, they will need to cooperate in an effective and efficient way: in a complex environment, interoperability is key. And this is exactly where so many organizations fail: they allow their teams to act as islands, each having their own, local interpretation of a management system. But effective and efficient collaboration requires normalization of the way the teams contribute to the enterprise goal. And normalization requires some level of standardization, especially on the aspect of each team’s management system. The links of the supply chain simply need to fit together. Not just within organizations, but also between organizations. The above images show exactly what would happen if you do not normalize the management system of the actors in the supply chain: both images specify a supply chain, but if you would be hanging from the edge of a cliff by one of these chains, most of us would prefer the bottom one…

The USM concept of the link

The links in these supply chains are the management systems of the contributing teams. It may be obvious that the upper image is composed of many types of management systems, and the lower image has a normalizedmanagement system for each team. And you know which one you would entrust with your life if you would be hanging from that cliff.

Unfortunately, this is easier said than done. Creating supply chains from normalized links has an inherent danger: the links must be strong (you wouldn’t want to trust your life to a chain made of paper) and the links must limit themselves to your interoperability function: the outside of your team domain (nobody wants to be told what internal decisions they should take). This concept of a singular normalized management system as an acceptable link is the core concept of the Unified Service Management method, and it is based on the concept of an integral and integrated process architecture.

In the next post, I’ll discuss why we need an integral process model.

<< previous post

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