We can't say its a problem,it is an incident... Many a time it happens that we forgot our password and in case if don't remember we can go to reset the password. Instead of saying it a problem we can say its a safe game to play.
skin tags

A request is something that adds to the service being provided, an installation of a application, a piece of hardware, access to a file even the provision of a report. It is about 'giving' something.

An incident 'fixes' something, application config error, hardware error, poor performance.

A password reset is also an incident, there has been a failure, either a failure in process where the end-user has failed to change their password in a timely manner, or a failure in the users memory in that the end-user has forgotten their password.

A user being unable to log on due to insufficient filespace is an incident in the immediate timeframe, if it occurs for multiple times or multiple users then it would be a problem.

Which would then lead to a change, in that you need to change something so that it ceases to be a problem, so you either change the script to clear out logs, or you replace hard drives with larger ones.

Hope that helps

Kim

Soory but Password reset is a not an Incident , it is a service request :)

I am a Service Request Team Lead, looking at the ambiguity and confusion between SR and Incident, and I am impressed to see the discussion in this forum :)

Password reset is Incident and not a request :)

There's one question asking for standard Service Request SLA..... it's not all the same. While the typical requests are to be completed within 10 days, the VIPs request is to be treated within 24 hours with E2E management.

Crucial request, eg: New Starter accoint ( wintel account creation), my team's operational target is within 24-48 hours, despite client's SLA is within 72 hours.

By the way, my client is the second biggest mining company in the world ( Rio Tinto)

Happy weekend everyone!

Alan.Ridzuan@gmail.com

Would low disk space preventing logon to a computer be logged as an Incident or a request ?

Hi - Can anyone please share your standard service request SLA?

I am not sure, if a password reset is a service request, as it is stopping the user from performing the normal business process (i.e. logging into application), be it user error only, but it is disrupting service.

" an incident does not necessarily require an interruption in service or reduction in quality of service," - the same can be said of the ITIL definition of an Incident. Fom ITIL v3: Incident definition includes the words "Failure of a Configuration Item that has not yet impacted Service is also an Incident".

Version 2 was even more specific and is still probably widely used "An event which is not part of the standard operation of a service and which causes or may cause disruption to or a reduction in the quality of services"

ITIL doesn't define event? From v3 - "Event - A change of state which has significance for the management of a Configuration Item or IT Service. The term Event is also used to mean an Alert or notification created by any IT Service, Configuration Item or Monitoring tool. Events typically require IT Operations personnel to take actions, and often lead to Incidents being logged.

A question has come up in my organization related to the original question and that is:

Would you classify End-User Training as an Incident or Service Request?

The scenario is that an end-user isn't clear about how to perform a function within an application and calls the service desk for help.

As a information security analyst, I am really puzzled by what appears to be ITIL's failure to address the difference between the ITIL definition for "incident" and the traditional information security definition for "incident." In the InfoSec world, an incident does not necessarily require an interruption in service or reduction in quality of service, yet those are the key parts of the ITIL definition.

The closest I've come to marrying the two is to state that Information Security services are ensuring data Confidentiality, Integrity, and Availability (the standard infosec CIA triad), and to define a Security Incident to be an interruption or reduction in quality of any of those three services.

Furthermore, ITIL doesn't seem to define event. Traditionally in InfoSec, an event is something detected that can be considered "abnormal" and requires investigation (my definition). If one of the CIA tenets is broken, then it becomes a security incident. For example, a user may report that they clicked on a link that installed malware on their machine (or you may detect it with antivirus or other tools). That would be an event. If you determine that none of the CIA tenets were impacted (eg, no data loss), then it remains an event. However, if one of the CIA tenets is broken (eg, a keylogger is installed, and data makes it off the machine), then it is a security incident.

Curious how others are addressing these issues?

My company recently implemented Service Desk and the talk times have tripled (and more). The call flow is backwards now so we end up having a long conversation at the beginning of the call before the analyst knows whether to open an Incident or SR. This is causing some major frustration for the analysts and the customer because we are not able to capture all the information the customer is spewing out at the beginning of the call because we don't know which type of form to open until they state the problem. Then, we must frequently ask the customer to repeat what they just said. What is the quickest route from a call script point of view to determine whether we need to open an Incident or SR?
Thanks, Good thread.

Our "adopt and adopt" approach locally is currently:

Incident ticket - type Issue
I used to have it, now I don't!

Incident ticket - type Service Request
I've not had it before, but I want it

Problem ticket - type Problem
Something is causing Issue(s) which we want to continue investigate after the Issues are closed

Problem ticket - type Known Error
We know what is causing the issues, and have provided a workaround

Now I know the above isn't perfect, but we're limited by our tool and the need to slowly iteratively improve ITIL alignment within our organisation, due to resource restrictions.

I liked John Sansbury's response. It always bothers me to think as a problem being the result of repeated incidents. Thats how people understand. But Johns explanation of what a problem is - very clear and very smart.

I vote for incident being the symptom, problem being the cause.

There are several instances, proactively we delve into applications (in my case) and avert potential disasters. That would be problem management too according to me.

- Sharada

I like to use a law enforcement analogy - an incident is like making an arrest or stopping someone for speeding.

A problem is like crime solving - a series of incidents that have a common, underlying cause.

Service requests are like police escorts or traffic cops - more routine, scheduled service.

I like to differentiate them as Incident Reports and Service Requests.

An Incident Report is one where an Existing Service Is interrupted, eg: you are having a shower and the water stops, you are going in a car and you have a puncture.

Service Requests on the other hand can be divided into two categories, 1. Pre-Defined such as change password, Issue a new computer,

2. Ad Hoc - where an adhoc request is provided.

There is a real need to segregate between the two, please look at my colum - A backdoor approach to IT Transformation for what can happen when you dont segregate.

It will all be so much clearer in the new edition of ITIL V3.1 - thats my hope anyway. Its easily solved in my practice and in the USMBOK publication - an incident is a type of service request.

There seems to be some confusion here. Let me see if I can add some clarity.

Incident – unexpected disruption to normal business processes. There may be an underlying cause, but this is not the domain of incident management. Incident resolution (aka fix) is restoring normal business process.

Problem – one or more incidents (of the same issue) that have an unknown, underlying cause. Problem management is identification and resolution of the problem. This may be by means of a change, or by applying a workaround. In either case the service desk knowledgebase will be updated.

All requests for change are classified as RFC (Request For Change) by the service desk. A service request is a specific type of change request; it still needs approval from the change manager but does not require a full CAB.

A change request that is not a SR does require to be put through the full CAB process. These changes can appear through new developments and enhancements, service requests, and problems.

In the example of the user being unable to save their data, this is an incident, with the description of being unable to save data. Resolution would be to direct the user to be able to save on an alternate server, and/or to ask the user to delete unwanted data.

As an extra comment, I would suggest that may be capacity management processes may have failed, as there should be a process within the capacity plan covering housekeeping of servers. Additionally there are server tools that can raise an alert when space falls below a pre-determined level.

In this case, problem management should only be invoked where there are repeat incidents, especially when more than one user is affected.

The change to increase server space will be very much a last resort. It would be up to the capacity manager to raise this request. I would venture to suggest that this be raised as a change request, going through CAB in order to make sure the upgrade can be properly planned with minimal disruption to live service. This might also be a requirement of the asset requisition process.

In the other examples of ‘service requests’:

"I can't create a table in MS Word, can you help?"
This is a Request for Information (RFI). It is not an incident as nothing has failed. But neither is it a service request, as no change is required to MS-Word functionality. RFIs of this nature can point towards a need for training.

"I have a new team member who can't sign-on because they don't yet have a user-id, can you please create one for them?"

This would be an incident, but should not arise as it will be covered in the ‘new starter’ process.

"My printer has run out of toner, can you please send some more?"

This is a genuine service request, as the printer will have displayed the message to the user, and is part of the normal function of the printer. This is not an incident as it does not represent an unexpected disruption to normal business processes.

I know it all sounds long-winded and a little text-book like, but I firmly believe that without careful attention to service management, chaos ensues and business success can be seriously hampered or even completely undermined.

I came across this discussion whilst searching google for the definition of 'Resolved.' Don't know if anyone is still tracking this forum, but as an ITIL author, examiner, trainer and user since version 1, may I clear up some common misconceptions?
1) An incident NEVER becomes a problem! Repetitive incidents or major incidents or incidents that have exceeded their service level to fix are NOT problems. I always find it helpful to think of the incident as the event or symptom and the problem as the cause. Therefore EVERY incident has an associated problem, although in practice, a problem record is only raised if there is sufficient justification in carrying out separate investigation into the root cause to prevent incidents recurring, for instance, based on cost/benefit analysis.
2) An incident is NOT just a case of something broken or failed. ITIL 3 is careful to point out that an event that COULD cause a failure or service disruption is ALSO an incident. This is typically an exception event as defined in Event Management.
3) A service request is NOT an incident because the person making the request has not suffered an interruption to or failure of service. In the first instance quoted above, a user unable to save files IS suffering an incident. This is NOT a service request but a Change (increase the file space available). However, if the user had correctly diagnosed the cause of their inability to save the file as a lack of file space and asked for more, thier contact should indeed be logged as a service request. This means that the definition of incident or service request should be based on the customer's perspective (not the limitations of the toolset!)
4) A user requesting a password reset because they have been locked out of a system or service is NOT an incident but a service request since their has been no failure of the system, service or component.
5) Sadly, many if not most incident management tools do not distinguish between incidents, service requests or problems at the highest level, only at a sub-level, perpetuating the belief that they are synonymous. Better tools create different records that makes life easier for people like the Problem Manager in analysing trends.
6) Incidents are FIXED, problems are RESOLVED. The difference is that resolved also means 'Prevented from recurrence' which is most often what the Problem Manager does with a problem but rarely what the Service Desk does with an incident (particularly when applying a workaround.
Other examples of service requests:
"I can't create a table in MS Word, can you help?"
"I have a new team member who can't sign-on because they don't yet have a user-id, can you please create one for them?"
"My printer has run out of toner, can you please send some more?"
Hope this helps!
John Sansbury

Hi Leo, info on distinguishing incident-problem? Something like a simple universal rule, which always applies?

When you resolve a Incident - YOU FIX THE USER (Apply a workaround) - Get the user back to work ASAP

When you resolve a Problem - YOU FIX THE TECHNOLOGY (find the RCA, Workaround - Know Error - Submit a RFC to remove the Root Cause - FIX THE TECHNOLOGY

Cheers
2.2

If the user calls at service desk and says i am not able to save my files thenlog it as an incident ticket. otherwise if the user diagnose himself and says increase my network image then log it as a service request.... simple..
Renu
--------

You can also distinguish between Incidents and Problems from your organisation's point of view. This example may not apply in all organisations, but I hope I can get my point across anyway:

Servicedesk logs calls in as either Incidents or Service Requests. They do not classify calls as Problems. Once a stream of Incidents is live on the system, your Problem Manager starts to take a look at the them, and identify Problems that may have caused the Incidents, leading to Root Cause Analysis and problem solving (by either resulting in a Workaround or a Change to the system).

In this model, your Servicedesk does not need to worry about making the distinction between Incident and Problem, which makes their life a little bit easier.

In a previous post I mentioned an article by the ITsceptic: http://www.itskeptic.org/what-itil-v3-says-about-distinction-between-call-a . I just noticed that there is a poll on the site as well:

http://www.itskeptic.org/hundred-users-call-and-say-they-cant-get-emails-on

Really interesting to see in the results that the situation is by some seen as being one incident, and by others as a 100 incidents.

I would probably think of it as 100 calls that are linked to form 1 incident. Or maybe as 100 (linked) incidents caused by the same problem.
Which one is best?

So Kenneth, you are saying that an incident is a type of service request? And that they therefore should be treated the same?

I figured that a call would regarded as either an incident or a service request.
In the example I gave in my post about there not being enough network space. The underlying problem can for example be an largescale update of software.
But is a service request not some sort of question from the caller, where there may not be something wrong? For example a request to add a new account for a new employee, or something like that.

Am again a bit confused.

For the most part, I think it's probably better to think about an incident as a service request, where the type of service request is "incident".

For those that choose to do it that way, they get a way of introducing a standard means of responding to any/all service requests.

From there, it's a matter of altering the response/behavior by the request type and using common infrastructure to manage the requests.

kengon

Ken, I really like your comparison: "Fixing Incidents is like Fire FIGHTING. Fixing a Problem is like Fire PREVENTION", a really nice way to make the distinction!

This is becoming an interesting thread!

Leo

Chris,
I am struggling with these definitions too when we talk about "Information Security Incident" as stated by ISO 27002 (Control 13 Information Security Incident Management).

It seems there is no clear definition of the terms "security incident" and "security event"; are they the same ?

Incident implies always harm or the intent to do harm ?

How about if a door if found open and it should be close for policy ?
How about confidential data found unattended at the copy machine ?

Are there events or incidents ?

Hope someone could help

Tiziano Airoldi

I've just read this blogpost over at the site of the ITskeptic:
http://www.itskeptic.org/what-itil-v3-says-about-distinction-between-call-a

He says that 'One generally accepted practice is to log 100 incidents and have a Master Incident to which the others are linked'

Is this the best way this should be done? Or should just one incident be recorded?
Of course there is no answer to be found in the ITIL books, as usual.

Hi Leo - Agree with Chris's distinction between Incident and SRs (Under ITIL V2 all were broadly classified as Incidents but better to separate ).

As far as Incident vs Problem - An Incident is one instance where something breaks(eg). A Problem is the underlying root cause of multiple occurrences of that Incident.
eg if a Server crashes every Sunday at 12 Noon each of these is a separate Incident. The Problem is what is ultimately causing all those crashes.
You might fix each Incident (restart the server) but you have not fixed the Problem until you fix the underlying root cause and stop the Incidents happening.

another view - Fixing Incidents is like Fire FIGHTING. Fixing a Problem is like Fire PREVENTION.
Hope that helps...

Chris, thanks for your explanation, it has become a bit clearer to me, this stuff can be really tricky!

Last week, I asked an actual incident manager this same question. He runs the help desk, and claimed that all calls were classified as incidents.

And, does anyone have some useful info on distinguishing incident-problem? Something like a simple universal rule, which always applies?

Thanks!

The examples you gave are definitely service requests. However, the user could first report an Incident when they find out that they cannot save to their network drive, thinking that there is a problem. However, once you determine that disk space is the issue, the resolution of the Incident requires a Service Request for adding disk space. You can think of some service requests as changes that have minimal or no impact, therefore, they don't go through the CAB. If the user did in fact report an Incident first in this example, you cannot resolve the Incident until you have completed a Service Request, adding disk space. The key here is that you can relate Incident tickets and Service Request tickets in your system, showing that one was needed to resolve another.

We have clearly defined Service Requests as service provided and not something is broke and needs fixing, which are Incidents. Sure, some services are needed because the user can't work until they get them, but in essence, they are asking for more functionality so they can work. If the user knew in advance that they needed more disk space and did not first report an Incident, they would just open a Service Request asking for more disk space.

Hope this helps. We can discuss the difference between Problems and Incidents in a separate comment!