Showing posts with label Problem. Show all posts
Showing posts with label Problem. Show all posts

Tuesday, June 24, 2014

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. 

Thursday, June 6, 2013

Problem Ticket – Should It Be Reopened?

I have come across many queries where people ask me “Can we reopen a problem ticket?”

Before I answer or give my opinion, I have a question – Why would one need to reopen any ticket? Typically this happens when a resolution provided is not as per the user’s satisfaction, i.e., issue for which the ticket was raised is not resolved or fulfilled. This is true for Service Requests or Incidents.
In case of a problem ticket, the ticket is closed only when the root cause is identified and workaround or permanent fix is provided, i.e., the underlying issue is resolved.

Thus, under what circumstances would one need to reopen the problem ticket? I got the response that in cases when the problem resolution is not effective and similar incidents still occur.

Problem resolution has two parts – first part is Corrective Action, i.e., the resolution provided is restricted to the source ticket or CI. Second part is Preventive Action, i.e., resolution is replicated across similar CIs throughout the estate. This is known as CAPA or Corrective Action Preventive Action.
Thus, despite problem resolution, a similar incident can occur under following circumstances:
  1. Preventive Action is not performed
  2. Root cause identified may not be the real root cause

In the first case, Problem Manager has to ensure effective CAPA.

For occurrences of second case, the old problem ticket should not be reopened. The old ticket was worked upon, served the purpose for which it was created, though the impact of its resolution could not eliminate all possible sources of the incidents similar to the one which lead to its creation. In all such cases a new problem ticket has to be created.

Please note that Problem Manager should ensure that all instances similar to the second case is proactively identified by him/her through Proactive Problem Management techniques like trend analysis.