V3 Incident Types

[Wilburinio]

Trying to figure out if any changes should be made to the Incident Types currently in place as a result of V3.

Incident Types currently in place:
Fault
Service Request
Inquiry
Event

I have read the V3 Service Operation book and have been unable to get a firm grasp on whether we should make any modifications.

Any ideas?

Wilburinio

[itil_asia]

"if it ain't broke, don't fix it" ...

I have not yet read the V3 books, but is there any compelling reasons for you to change your current incident types list?

[Wilburinio]

Nothing driving the change (other than curiosity to see what other folks are doing).

Thanks for the reply.

-Wilburinio

[UKVIKING]

Spend the money... buy the books

The main thing that v3 has done in incident mgmt is separate

incident & service request

just ordered the boos.. waiting for delivery
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Wilburinio]

John-

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):

-Fault
-Event
-Service Request
-Inquiry
-->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 . . . .).

-Wilburinio