Joined: Dec 22, 2006 Posts: 12 Location: Wisconsin, USA
Posted: Sat Aug 04, 2007 4:08 am Post subject:
Thanks for the reply.
Already spent the money and bought the book (Service Operation, at least!). That's where some of my confusion resides.
From the Service Operation book (highlighted in blue below):
Incident Management (IM) Incident: an unplanned interruption to an IT service or reduction in the quality of an IT service.
IM is the process for dealing with all incidents; this can include failures, questions or queries . . . .
IM includes any event which disrupts, or which could disrupt, a service.
In the case of incidents where the user is just seeking information, the Service Desk should be able to provide this fairly quickly and resolve the Service Request – but if a fault is being reported, this is an incident . . . .
Technical staff may notice potential failures and raise an incident . . . so that the fault can be addressed.
Request Fulfilment The term "Service Request" is used as a generic description for many varying types of demands that are placed upon the IT department.
. . . small changes (low risk, frequently occurring, low cost, etc.).
. . . a question requesting information.
Objectives of Request Fulfilment:
-To provide a channel for users to request and receive standard services for which a pre-defined approval and qualification exists
-To provide information to users and customers about the availability of services and the procedure for obtaining them
-To source and deliver the components of requested standard services
-To assist with general [/list]information, complaints, or comments.
Some organizations will be comfortable to let the Service Requests be handled through their IM processes (and tools) – with Service Request being handled as a particular type of 'incident.'
Incident is usually an unplanned event.
Service Request is usually something that can and should be planned!
In an organization where large numbers of Service Requests have to be handled . . . it may be appropriate to handle Service Requests as a completely separate work stream – and to record and manage them as a separate record type.
Service Request will usually be satisfied by implementing a Standard Change….
OK, then. My take-aways from all of this:
1. The terms Fault, Failure, and Event (which disrupts or could disrupt service) are used relatively interchangeably.
2. There appear to be two main categories here:
Incident (unplanned) – handled via Incident Management
-Failures/Faults/Events (that disrupt or could disrupt a service)
Service Request (planned) – handled via Request Fulfilment
-Requests for Information/Queries
-Requests for Service (incl. some small, Standard Changes)
3. Incident Management may be the entry point for both Incidents and Service Requests. (Service Requests may shoot off the process as some point. Or not . . . . ).
4. Service Requests may be tracked on the same tool as Incidents.
Wow. That's enough info to cause a serious overload.
For me, to answer my own question, seems like our current list of Incident Types could be left alone (or tweaked ever so slightly to accommodate V3 terminology):
-->Might consider dropping Event from the list (which are threshold-busting alerts generated by our monitoring tool) and have them classified as Faults, with the Incident Input method set to 'Monitoring Tool' (which would be added to our current list of: phone call, e-mail, web, etc.).
Thanks again for your thoughts. Definitely made me dig a little deeper and think things through a bit more (which is always a good thing . . . .).
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