• Inok Systems

Service request and Incident separate them!

User Rating:  / 0
PoorBest 

Let’s first take a look at the definitions in ITIL:

Call (Service Operation): A telephone call to the Service Desk from a User. A Call could result in an Incident or a Service Request being logged.

Incident (Service Operation): An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example Failure of one disk from a mirror set.

Service Request (Service Operation) A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

A customer calls in and reports that he is not able to login to the system due to error password. Since this has caused a “interruption” to his use of the application’s “IT service”, shouldn’t it be classified as an incident? This is a long debated question in my ITIL circle of friends, and password reset is kind of the simplest form. There are other scenarios such as “out of disk space”, “faulty mouse”, “add more memory to server due to application slowness”, “email full”.

There is no right or wrong answer, every company can have their own way of doing it based on their process guidelines and determine their own list of services provided in their service catalogues.  Here’s my thoughts and way of debate if I am the one setting the process and teaching my Helpdesk staffs.

Password Reset: This is clearly a PEBCAK error (problem exist between chair and keyboard). It has nothing to do with the IT service as our service is still running fine. I do not want to add 1 count to my incident reports as the higher my reporting numbers are for incident tickets, it shows that I am managing my IT environment badly. Yes, there is a disruption of service due to a CI error. That CI is the user’s brain where he fails to remember his password. I will say this goes to a service request box. I would like to have my SR report go up to show the amount of services I have provided to my users with my limited headcount.

Out of Disk-space: Requesting for more disk-space before any incidents occur is definitely a SR, but if its due to my bad capacity management planning and caused an application to hang, I will say it’s an incident. We should have event monitoring tools to prevent this and good monthly capacity planning reports to predict the growth of disk-space usage. In a case that such incident occurs, we should get a temp hard-disk or allocate more VM disk-space immediately to the affected area within the SLA as a workaround resolution. Going the SR method where we do a hard-disk procurement process will take too long and availability will be affected.

Faulty mouse: IT equipment fails due to wear and tear. There should be hardware refresh projects going on (e.g. Every 3yrs). Some users might be reluctant to change their devices and once they pass the upgrade period, any replacement should require a Service request form filled up and supervisor’s approval is required.

There’s 101 ways under the sky for a customer to report their calls, and we can’t list out all of them in a bible, so I will suggest the following general guidelines to my helpdesk agents:

Incident: Our fault, we should get it resolved or at least provide a work around within the SLA.

Service Request: Problem lies with the user, ad-hoc requests that gives us more work, triggers approval.

 

Service Request (Service Operation) A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

Random Blogpost

When was the last time you hear something like this…

“No, I did not do anything to the server that caused it to crash/malfunction/slowdown!”

“But only you or the other person accessed the server during that period!”

“It must be the other guy, not me!”

Read more...