Process model
Definition of a process
The term process is frequently misused in service management contexts. Defined as "a series of activities that are meaningful for the customer, with a specific goal", a process should be limited to activities.
Requirements for processes
To define a process architecture, we need more than just this simple definition. USM specifies 10 requirements that should be fulfilled for a process, before we can indeed call it a process and handle it as such:
- A process describes what has to happen successively, not the who or how.
- A process can be interpreted with a verb.
- A process can be counted.
- Processes are not depending upon practical conditions (◊).
- Processes have a customer-relevant and unique purpose.
- A process can be divided into sub-processes, but that does not change the process.
- A process model organizes the processes.
- An integral process model includes all service management activities.
- In an integrated process model, each activity occurs only once.
- All activities are steered using process control.
Processes versus practices
If we test the 'processes' from all current frameworks, standards, and reference architectures against these 10 requirements, it can be demonstrated that they all describe combinations of people, process and technology: the what, the who and the how. Therefore, they all fail the very first of the 10 requirements. They actually describe practices, and practices are not processes: practices are derived from processes by adding the who and the how to the what. The large majority also fails requirement 5: they are not customer-facing. Most of these "processes" are internal affairs for the service provider, and as such, they are only part of the customer-facing processes. Also, when people are using BPMN or any of the other so-called 'business process modeling' techniques or products that use 'swimlanes', they specify roles and documents, and they fail requirement 1.
The e-book "Demystifying the term PROCESS" explains this in detail.
Creating the process model with only five processes
Removing all who and how from these practices then leads to the core material of a process architecture: only the what.
Reformatting the remaining collection of activities in such a way that the result complies with the rest of the 10 requirements, then leads to a customer-driven, integral, integrated, and non-redundant process model for service management.
In that process model we find only five processes that are independent of the line of business of the organization. Four of these processes are reactive: they are triggered externally, by the customer. These reactive processes are used to respond to the customer's demand.
- Agree (Contract Management - CTM): drawing up and maintaining service agreements and steering their deployment. This process concerns both the service agreements with customers as well as the agreements with external suppliers and with internal solution teams that contribute to the service. The corresponding call is named wish, which includes the concept of complaint. The wish acts as the trigger of the process.
- Change (Change Management - CHM): the controlled development and release of changes to the infrastructure of the agreed service. This process relates to the facility and/or support as far as it is part of the managed infrastructure. The associated call is named request for change (RFC) (or change request). The request for change acts as the trigger of the process.
- Recover (Incident Management - INC): the repair and recovery of the service as agreed (primarily not as fast as possible but as fast as agreed). This process concerns both failures and imminent failures of any size, including disasters. The corresponding call is named incident (or failure report). The incident acts as the trigger of the process.
- Operate (Operations Management - OPS): the planned execution of all operational actions for the agreed service and the monitoring of the performance of the infrastructure and all its components. The corresponding call is named service request (or operations request). The service request acts as the trigger of the process.
One of the five processes is proactive: it is triggered internally, by the service provider's organization. This proactive process aims at structural improvements in the delivered services, managing all threats and innovations for service delivery.
- Improve (Risk management - RIM): the prevention of effects that are detrimental to the agreed services (mitigating threats), as well as the promotion of structural improvements in the agreed services (fostering innovations). The corresponding call is named risk. The risk acts as the trigger of the process. The Improve process is not triggered by other processes, but only by people: in terms of the process model it is 'self-triggering'. People submit risks, but risks are also actively searched for. The direct stakeholder here is the service provider’s own organization. The customer is only an indirect stakeholder: all improvements will eventually improve the service delivery.
In a process model that meets all the 10 requirements, performance is achieved with workflows: composite flows of activities, which consist of non-overlapping fragments of individual processes from the integrated process model. For example, a recovery action can be performed by having a change made or by resetting some infrastructure, but in both cases the execution is realized in one and only one process: Operations Management. This creates unambiguous control over the actual service delivery and prevents conflicts.
This unique integrated process modeling for service providers can be easily learned, applied, and supported with tools, using no more than 8 standardized USM workflow templates for all your service management activities. Just imagine the reduction in complexity and cost you'll achieve with such a management system.
Standardizing the layout of a process
Every process has the same basic layout, and consequently, every process also has similar activities. At the beginning and the end of every process, we always find the same similar activities: starting up and finishing the process. Processes differ mainly in one aspect: the customer-related purpose of the process, and with that, they differ in the nature of the process. That difference manifests itself in the activities in the body of the process.
In the image below, those activities in the body of each process are indicated with their color. In that image, the similar (but not identical) activities are grey. The details of these body activities are dealt with per-process in the USM book.
The cooperation between process model components
Because of the non-redundancy of the processes, each process (excluding OPS) requires one or more of the others to complete a required performance. Therefore, each of the processes (excluding OPS) is split into two sections: the initial section that triggers the following process block, and the sections that closes the process administratively. The arrows in the image below demonstrate how the process blocks trigger each other.
The consequence of this non-redundancy and internal dependency between process blocks leads to the concept of USM workflows, with astonishing results..
