Understanding ITIL Processes For Your BAU In Simple Terms

When your house plumbing develops some snag you would see the symptoms. There would be a water leakage or no supply of water to a tap. Especially in case of concealed pipes you may find dampness in your walls. These all are the incidents that indicate that there is something wrong with the plumbing. These incidents typically would reflect an underlying problem for which the root cause is not yet known.

You would call a plumber to identify what is wrong with the plumbing, i.e. to identify the root cause. This is Problem Management. Plumber might give some filler (like m-seal) or you yourself can opt for one which is a temporary workaround. This is Incident Management where your goal is to have an asap resolution. Though it can provide a relief in terms of stopping the leakage, but this does not resolve the problem. Please note that problem is different from incident (which may simply be an indicator of something major to come). Plumber would look into identifying the source of leakage. Now you have the error and identify how it can be rectified, i.e., the resolution. This is known error.

Some part would need replacement, i.e. change, which could be a pipe, tap or combination of multiple parts. Plumber would provide you the details of parts to be replaced. This is RFC. This detail has to be taken to a hardware shop and given to shopkeeper. This is change management. Plumber may give you a time when he would come and replace the fittings. This is forwards schedule of change. Shopkeeper will validate the details and check the fitment of the parts before giving it to you. Shopkeeper may give you multiple options along with information regarding cost, quality, etc. and seek your approval for a particular type or brand. This is CAB approval. All these constitute Change Management.

You will take this to your plumber who would change the fittings, test and ensure that there is no more leakage. This is Release & Deployment Management. In case there is any warranty for the parts, you would ensure that it is properly documented and stored. This is Service Asset And Configuration Management. 

Request Fulfillment Ticket – Should It Be Reopened Or Incident Ticket Raised?

In my various interactions with my customers and fellow professionals, I have come across many queries where people ask me “If Request Fulfillment Ticket is not correctly fulfilled, should one reopen the ticket or raise another request fulfillment or Incident ticket?”

Service request is a request for any service or standard change. Some examples are password reset, software installation, hardware request, access/authorization requests, location movement, etc.

Let us consider some examples when service requests are inadequately or unsatisfactorily provisioned:

• Reset password does not work
• Software installation was not proper or wrong version was installed
• Hardware provided was faulty or of different configuration
• Others

Let us first understand the Ticket Closure part of Request Fulfillment process. After the ticket has been fulfilled or provisioned, the resolver group has to seek confirmation from the user before one can assign ‘Resolved’ status to the ticket. This is one of the instances where user can ask for a proper or satisfactory resolution.

In cases where due to whatever reason (e.g. 3-Contact Process), ticket has been assigned ‘Resolved’ status, user can reopen the ticket citing reasons for the same. Reopening of the ticket can happen ‘n’ number of times.

What happens when ticket is reopened?

When a ticket is reopened, the SLA clock starts ticking again. Please note that the SLA clock does not restart. Thus, the chances of SLA breach for the resolver group increases. Also, ticket is escalated after n^th time it is reopened (‘n’ depends on the process defined in an organization,).

How does ticket reopen affect the KPIs?

When a ticket is reopened, two major KPIs that would be impacted are:

• %age and number of tickets reopened (measurement of how effectively the resolver groups are able to fulfill or provision service requests)
• %age and number of tickets that breach the SLA (another measurement of effectiveness of resolver groups)

Analysis of these two KPIs and the factors that drive up the number/percentage would lead to SIPs related to ‘People’ or the ‘Process’ itself depending on the analyzed root cause.

Why not create an Incident Ticket?

Incident is defined as an unplanned interruption to IT service or degradation of the quality of IT service (or a CI).

When any request is incorrectly provisioned, it is not an instance of service disruption. The particular user does not have access to that service itself and thus needs the access to the same. This is a service request and not an incident.

Please note that when any process is defined, as part of the process definition itself measures have to be put in place to monitor and measure process performance besides the aspects that would drive continual improvement of the process.