"Shift Left" is the concerted effort of an organization to increase customer satisfaction and productivity to ensure incidents and requests are handled according to business needs.
Thus, shift left means a changed service philosophy with the customer at its center. Additionally, this leads to an inversion of proof: No more has the customer to complain or proof something does not work, but the service provider has to continuously proof that the service meets (even changing) customer needs.
Conclusion
What is the implication of shifting left?
This 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 the happened, 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.
Avoidance
What is the implication of "shifting left"?
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.
Automation
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.
Self-Service
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 a an instance where a standard activity cannot be resolved as described or has not been handed over yet.
Operations
Some requests and incidents become cases that can only be fixed by changing the way the solution is designed and require 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".
Engineering
Architecture
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".
Acceptance
Sometimes, incidents and problems have to be accepted. There can be only 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".
3
