Looking at how we want incidents and requests to be handled at our Service Desk, an order of preference becomes clear: Rather than fixing the same things on an ongoing basis, we want to eliminate their root causes. Rather than fixing things manually, we want them to be fixed automatically. Rather than fixing, we want to prevent or avoid. For service requests we want users rather to be able to use self-service than to have to wait for another person.
Therefore, we distinguish the following stages:
Sometimes, incidents and problems have to be accepted. There can only be workarounds (like reboot a server or restart a service regularly), but no elimination of the root cause. This is the least preferable option. There is no further escalation possible. Ideally, this leads to better architecture decisions in the future. In ITIL, this is done in "Service Strategy".
Sometimes, incidents and problems can only be fixed by changing the architecture. The root causes have been identified to be in the underlying tools or how the tools are implemented. This is usually complex and costly, thus escalation to architecture requires a business case. In ITIL, this is done in "Service Design".
Some requests and incidents become cases that can only be fixed by changing the way the solution is designed through additional engineering effort. The root causes have been identified to be how the tools are implemented or designed. This usually requires effort but is manageable without requiring a project. In ITIL, this is called "Service Transition".
Some incidents and requests require manual intervention by technicians to be resolved. Usually, there is a defined set of standard activities that are executed at this level. Everything else is a "case" that needs to be escalated. A case can also be an instance where a standard activity cannot be resolved as described or has not been handed over yet.
More and more incidents and requests can be resolved in a self-service manner – for example, access requests or password resets. In case the customer does not know where or the self-service does not work as expected, the incident or request is escalated to operation.
Instead of manual activities, incidents and requests are detected and resolved in an automated fashion. Examples include increasing disk space on a virtual machine or creating project support entities (in various systems) based on a single request.
Avoidance is the holy grail of incident and request management: Systems are designed, built and operated in a way to minimize requests and incidents. Even if they happen, instead of reactive activities, incidents and requests are detected and resolved in an automated fashion before they even have a service impact. Examples include automatically scaling infrastructure to prevent performance issues or stopping a deployment ahead of time because of automated tests indicating an issue.
Drawn out, the following picture emerges:
As we can see, "Shift Left" is our concerted effort to increase customer satisfaction and productivity to ensure incidents and requests are handled according to business needs.
Ideally, this leads to an inversion of proof: No more has the customer to complain or proof something does not work, but service providers have to continuously proof that their service meet (even changing) customer needs.