For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Fri Nov 03, 2006 5:22 am Post subject:
OK
Let me try this again
Using my case example
the first few SD calls (few being a relative fuzzy number) about the BSDing desktops would get noticed by the Lead or Duty NOC Lead
Some one who is acting as the senior SD for the SD team, if he/she 10 tickets with the same symptoms (BSD), then a Major Incident may be invoked - that is if there are process/procedures for that.
The Major Incident ticket would run parallel to each of the individual BSD tickets. The purpose of the MI ticket is to track the volume of tickets that are having the same problem
In my world, the SD Lead woudl initiate the MI ticket, the Problem Manager, SD manager and the Incident Manager would get contacted and involved. The Problem Manager may take over the MI ticket because it is a Major Incident but that would depend on whether the MI the SD Lead called actually met the criteria - Service Impact and Users/Customers Affected are a couple of criteria.
HOWEVER, the incident tickets (individual) will be handled through Incident Management processes and procedures... an yes that does mean going from the Service Desk to the Network, Application or System team. When these people get the ticket, they will do the minimal diagnosis thinking - what can I do to restore service now.
Meanwhile, the PM may assign the Major Incident to the Same team which is restoring service but instead of restoring the service they may be trying to figure out what is causing the service impact.
It even could be the same person........
Remember we are defining the roles and responsibilities for people in a specific situation.
If you have a highly technical SD, the SD tech may log into the device, pull logs and sending to the PM team while starting the device.
If you dont have a highly technical SD, the SD may just take the details, the NMS log details, device identitty data and symptoms and pass it to the appropriate team. The team may contact the Data Center to have the device reboot if remote capability is hindered. This is STILL Incident Management. The key is RESTORE SERVICE ASAP.
I think you are suffering from a tool limitation in regards to Incident Management // Problem Management.
The tool may not have / can not be // configured to meet your requirements and adjusted to when they change.
ITIL is a guide for Best Practice. If you have to separate the SD doing the IM work and the #th Level team as Problem Mgmt... you may just have to accept that _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Posted: Fri Nov 03, 2006 6:24 am Post subject: Go IT ;)
I think I got it...
We have a CMDB (Configuration Management Database) that includes every physical device that exists in our organization that are called CI's (Configuration Items)
When SD receives a call, they create a "Service Call" record and if it happens to be an incident, they will classify the SC as an incident and create an Incident record. The incident record would include the related SC and would have an associated CI. If they can restore the service they do, if not it will be escalated to LX. LX will try and restore the service meanwhile many other calls may be incoming and SD is creating SC's and relating then to the already existing "Incident" record by using the tools CI search capabilities. When LX restores the service, they mark the incident record as "Resolved" and SD verifies with a few users if in fact it is. If so, the incident is closed by SD.
If this particular incident was to re-occur on another day or week, it will probably require "root-cause" analysis and a Problem record would be created.
In the above we have the parent/child you were talking about except that instead of incidents related to parent incidents we have "Service Calls" relating to incidents. BTW, I am skipping over the "Incident/Problem" managers to keep my logic simple although there would be other steps within the process of escalation. Also, our CI's are associated with Services and the CI's/Services have priorities set so there would be no need for Major Incidents because any incident would have it's priority level. One of which would be "WORK STOPPAGE" which requires immediate attention.
All times are GMT + 10 Hours Goto page Previous1, 2
Page 2 of 2
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum