You may have seen a similar blog from the Professor a few years back that talked about the distinction between the idea
of an incident vs problem. Everything
from that article is still relevant. As
process and methods for development and deployment have matured so has the
usage of Incident and Problem Management.
This is one of the most often confused points in
for Agile, LEAN and ITIL adaptations.
The ITIL
definition is the same.
Incident: Any unplanned event that causes, or may cause, a disruption or interruption to service delivery or quality
Problem: The cause of one or more incidents, events, alerts or situation
Where and how we apply
Incident and Problem Management is evolving.
A decade ago, and still in some organizations, Incident and
Problem Management are processes exclusive to Service Operation. ITIL is so very relevant and today we find,
with the onset of DevOps and cultural shifts, many organizations are adopting
little or zero tolerance for allowing defects through the
development/deployment lifecycle. ITIL
processes and principles will help.
High performing service providers have discovered that by integrating
Incident and Problem Management early in the lifecycle, such as in design,
development, build and test activities, they can become much more proactive to
ensure true value to the customer. This aligns with and allows for the DevOps
principle for shortened and amplified feedback loops throughout the value
stream of Design and Delivery. If this concept is also applied to the process
improvements of that value stream then the time, the amount of resources and
certainly the cost will be much less for the service provider.
If Incident and Problem Management are applied early in the
lifecycle and a defect is discovered, “Problem Management” would determine the
root cause or the reason “Why” and propose a solution to prevent the repeat of
this type of defect (incident) or cause (problem) so that it will never happen
again. This in turn prevents the “defect/incident”
from occurring in the future. This is
very different then those that focus on Problem Management after the defect has
done its damage and consider it only as an operational task.
If we continue to look at Incident and Problem Management as
merely for Service Operation, it is likely that we will have a lot of business
impact and potentially frustrated technicians who do not feel enabled for
success and a likely dissatisfied customer. By thinking out of the box and considering how
you can increase the flow of work for Design and Delivery by applying Incident
and Problem Management activities early in the lifecycle, an organization can
truly become proactive.
For further information, ITIL training, resources and more … click here!
Comments