Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: TNlc
New Today: 29
New Yesterday: 59
Overall: 146188

People Online:
Visitors: 50
Members: 2
Total: 52 .

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - Which comes first? Incident or Service Request
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Which comes first? Incident or Service Request

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
rpmason
Senior Itiler


Joined: May 25, 2007
Posts: 105
Location: USA

PostPosted: Fri Oct 30, 2009 12:06 am    Post subject: Which comes first? Incident or Service Request Reply with quote

From another topic
Quote:
What we call as incidents are also service requests in more ways than one.


Interesting. When I was taking my IPSR and again when taking my Service Managers courses, I talked to the instructors about how it was easier for me to think of an Incident as another type of Service Request.

Both times, the answer was STOP thinking that way.

Maybe they didn't want to encourage that thinking before the V2 tests. In V2, the Service Request procedure is just an odd little tangent off the Incident procedure.

Or is it just a game of which came first? Does it really matter? If I sound snarky, I don't mean to be. I'm actually curious about what people think as opposed to what's in the V2 books.
_________________
Ruth Mason
USA
Back to top
View user's profile
thechosenone69
Senior Itiler


Joined: Jun 06, 2007
Posts: 268

PostPosted: Fri Oct 30, 2009 12:26 am    Post subject: Reply with quote

RP,

ITIL V3 has broken the two up into separate and distinct categories. An incident is an incident which is not planned and means that the service is being disrupted,

Where as a Service Request has a planned process or procedure ready to be executed. ex: new equipment, training etc.

Incident -> My PC is not working
Service request -> Add toner to the printer

In ITIL V3(I still hate it) made things clearer. They said that a Service Request should not be classified as an Incident or a change. So if the call comes to the service desk and its a service request then its a different process with seperate activities which is called a service request.
Back to top
View user's profile
aucade
Senior Itiler


Joined: Dec 16, 2008
Posts: 50

PostPosted: Fri Oct 30, 2009 3:52 am    Post subject: Reply with quote

In v3 the process is "Request Fulfilment". As thechosenone69 pointed out, Service Requests have a defined procedure ready to be executed. They could be procedures which involve multiple departments (ie IT, HR, Purchasing Dept.,...) and/or multiple authorisation steps. They also generally have a timeline from n days, always depending on how many instances are involved.

Typical SR`s based on a self service interface which we all know from the internet are "shopping carts" ala Dell, Online banking etc.
Back to top
View user's profile Send e-mail
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Sat Oct 31, 2009 2:26 am    Post subject: Reply with quote

So in the end, doesn't it all come to defining which "items" are SRs and which are Incidents? Depending on your definition, Incidents too can be (to a degree) managed through a self service portal. Personally, I don't care much what they are called. In both instances it is user/customer needing something and support organization has to capture/detect that need, record it, and then put it through a "give the customer what he/she wants" process.

IT Skeptic has an interesting piece about Response Management on his ITSM Watch blog. Worth a read, IMHO.
Back to top
View user's profile
Anticlue
Newbie
Newbie


Joined: Sep 29, 2009
Posts: 10
Location: Jacksonville, FL, USA

PostPosted: Sun Nov 01, 2009 11:53 pm    Post subject: Reply with quote

Hi All,

In practice, I'd agree with Timo and suggest service requests, incidents differ based upon the nature at the item.

For example, a new employee needs an account. That would be request fullment, service request. However for that already created account the individual forgets their password, this would be an incident.

The lines become blurred because with password management there are now tools which enable users to reset their own password based on other things they know to identify themselves. Hences if the tool exists within the organization it is a service request through request fullfment.

Hope this helps,
_________________
Collaboration is the key to success!
Back to top
View user's profile Visit poster's website
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Nov 03, 2009 3:49 am    Post subject: Reply with quote

the distinction in the terms, or the lack of it, is context sensitive.

If you want to regard "my machine is broken" as meaning "please fix my service" that can work perfectly well as regards efficiency and effectiveness in getting the machine fixed, always assuming the underlying procedures are geared up properly. After all, these underlying procedures don't care what you call the thing.

However, there still needs a way of recording that the service was deficient so that you can measure the quality of your service and both persuade the customer that it has been adequate and strive to improve it. So these "service requests(to restore service)" need to be flagged and counted in a way that other service requests do not.

One fairly reasonable approach to a portfolio of services that can be made available on request is to provide them under procedures that are designed very specifically for just that service. This ensures that they are provided slickly and reliably and enables the monitoring and management of demand etc. The thing about a "please fix my service" type of service is that it can only be governed by much more generic procedures which have to contain a great breadth of possible circumstances.

It is perfectly possible and legitimate to raise an incident before any user has been impacted. since one tends to think of a service request as emanating from a requester, there may be some shuffling done in the system to "fake" a request. (I know that some people have spoken before as if that were true of incidents as well, but that seems to be a result largely of their struggles with their incident management software.)

"Please fix my service" has to be subject to immediate evaluation as to timing and priority through impact assessment. Other service requests can have pre-agreed impact and may therefore be treated slightly differently.

By the time you have accommodated these and any other distinctions that come to mind, do you still have a benefit in calling incident reports service requests?

For sure, responding to an incident report and responding to a service request require the same attitude and focus on the customer requirement and are both part of the service to be delivered. But I suspect that understanding that fact is sufficient convergence for most organizations.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 113

PostPosted: Fri Nov 06, 2009 5:11 am    Post subject: Reply with quote

ITIL has historically been descriptive and not prescriptive. In Diarmid's example " Please fix my machine", isn't it a service request where the customer is requesting service from the service desk. The service desk might open an incident and try to immediately fix the issue, try to give a work around or escalate to higher level of support. These are indeed incidents which is essentailly defined as failure or degradation in existing services. What we are confusing with is a service request and a new service request. A service request aka an incident could be about fixing something which is broken and a new service request is about providing something which was never there. This is one of the reasons that the users are given a hotline number to report what is broken while they are normally given a self help tool in order to make their own new service request which follows a workflow of user's manager's approval, procurement manager's approval ( need based), license management's approval ( again need based) and finally helpdesk's manager's approval.

V2 and V3 (I've never been fond of it) both tell about a request for service and a new service request.
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Fri Nov 06, 2009 10:38 pm    Post subject: Reply with quote

Viv,

v.2 is pretty vague and generic in its use of "service request" The glossary definition leaves many questions unanswered and I don't think it is used entirely consistently through the manuals.

v.3 I cannot properly speak for as I do not have access. However the "An Introductory Overview of ITIL V3" version 1 (2007) gives the following definitions;

Incident
"An incident is 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."

Service Request
"A service request is a request from a user for information or
advice, or for a standard change, or for access to an IT service."

Note that "change request" is not included in this definition. If "new service request" actually is intended to mean a request for a new service, then that could be considered a form of "change request". there is, of course, a whole other discussion on "standard change".

If we also take the word "access" to include the running of an ad hoc service whether interactive or batch, then these definitions seem reasonably useful.

This almost allows us assign any service desk call into one of two or three categories, those related to incidents and those that are requests. Personally, I like at least four (I think I once thought of a fifth, but can no longer recall it - maybe it is "wrong number") to assist in good management information and control: incident report, change request, service request and information request.

Such categorizations are of course subject to circumstances, particularly the scale and complexity of the IT services environment in question and I would expect to come to a different arrangement in different organizations.

I'm inclined to say this came straight out of ITIL (the original) because, although I do not think it was said explicitly, I derived it from considering how to apply the best practice guidance I received by studying it.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
rayfleming
Newbie
Newbie


Joined: Nov 20, 2009
Posts: 1

PostPosted: Mon Nov 23, 2009 6:49 pm    Post subject: Reply with quote

Interesting thread.

Given that a Service Request is [ITIL v3] is
"A service request is a request from a user for information or advice, or for a standard change, or for access to an IT service."

What would a password reset be classified as, an incident or a request? On the one hand someone cannot access the service (e.g. an online application) because their password is no longer valid (is that a service disruption?) or is it simply that the service is being provided (i.e. the online application is available) but can't be accessed.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Mon Nov 23, 2009 7:16 pm    Post subject: Reply with quote

rayfleming wrote:
What would a password reset be classified as, an incident or a request? On the one hand someone cannot access the service (e.g. an online application) because their password is no longer valid (is that a service disruption?) or is it simply that the service is being provided (i.e. the online application is available) but can't be accessed.


Why wring hands and anguish over this?

For the most part there is no need for a theoretical assertion on password reset. It is equally possible to call it an incident and respond to it or to call it a request and respond to it. you just design your processes accordingly, achieving the best control and smoothness whichever way you choose. If there is a high frequency compared to other incidents/requests then you do, of course, have to take account of where you have placed it when analysing and reporting on statistics.

If it is frequent, is this because
    your users are not well trained?
    your algorithms are very complex?
    your users are many but their use of the systems is infrequent?

Is there something that you can do about any of these - or is just the nature of the beast? - you have to decide.

But what if you provide a fully automated password reset facility? Then perhaps it is just an available service. But do you still need to gather data and does it now lie in the domain of application service management rather than incident or request management?

The exception is where some action within your system has changed user passwords without notifying them but without the intention of barring them from the service. That would be an incident and Change Management would probably want to know about it as well.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
smehdi
Newbie
Newbie


Joined: Dec 09, 2009
Posts: 16

PostPosted: Thu Dec 10, 2009 4:27 am    Post subject: Reply with quote

Hi All,

I think the difference between an Incident and a service request lies in the world "NEW"

Requesting for any new service which user never had will fall under service request (It will also include any further modification to this service).

If I take an example of Password reset. The very second and so on........request to reset the password from the user shall be treated as an Incident.
Back to top
View user's profile
nisarg
Newbie
Newbie


Joined: Jan 25, 2009
Posts: 11

PostPosted: Thu Dec 10, 2009 6:07 am    Post subject: Reply with quote

I cannot really agree to the conflict in defination of Incident and Service Request .
Taking the eaxmple of password reset.Underlying cause for password reset is the lack of users memory and I dont think IT can be blamed of users memory and so no way can a pwd reset be an Incident

So a user forgetting a password is definately a service request by an user and not a fault of IT that it cannot provide the agreed availibilty or capaicity of that particular application.
Back to top
View user's profile
smehdi
Newbie
Newbie


Joined: Dec 09, 2009
Posts: 16

PostPosted: Thu Dec 10, 2009 6:26 pm    Post subject: Reply with quote

Hi Nisarg,

I totally agree with you. The blame goes to user , if he forgets password .

But there are few situations , where user remembers his password but the password gets expired or disabled for some reason .Which in turn is impacting user normal operations.Can this be considered under a service request.
Back to top
View user's profile
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Sat Dec 12, 2009 11:47 pm    Post subject: Reply with quote

A lot of good things have been said in this discussion to help distinguish incidents from service requests. That includes the fact that it is ultimately your own organization that determines whether for instance a password reset is an incident or a service request. In most other cases the distinction is crystal clear.

When reading some questions in this thread and especially the following quote, I realized some people do not have a fundamental understanding of the difference between a service, a process, and a function.

Quote:
A service request aka an incident could be about fixing something which is broken and a new service request is about providing something which was never there.


I hope the following example will make clear what the difference is between those three concepts, which will then give a much better understanding of incident versus service request.

WebMagic is a (fictive) company that hosts websites for their customers. They take care of all the infrastructure and software needed to provide the service of 'web hosting'. They offer several flavors of this service, for instance with different amounts of storage: 1GB, 10GB, and 100GB. As their customer I am not interested in their infrastructure. The only thing that matters to me is that my website is available and performs well in accordance with the service levels agreed upon between me and WebMagic. To support the service they provide WebMagic has a number of internal processes in place to help ensure they can provide the service their customers are paying for. Examples of processes are Change Management and Incident Management. They also have a part of their organization that handles a wide variety of customer contacts, the Service Desk, which is a function. If my website is unavailable, I can call this Service Desk to let them know and tell them to fix the darn thing as quickly as possible. In this situation I am not asking them to provide me a service; I am telling them to restore a service I am already paying for. On another occasion I might be calling the Service Desk and ask them to upgrade my 1GB website to a 10GB website. In this case I am asking for a different service for which I will have to pay extra.

It should be clear from these examples that the Service Desk function is not a service provided to me. It is the function that facilitates communication about services between the provider and the customer. The Service Desk function ties directly into the Incident Management and Request Fullfilment processes that span across the provider's organization. Incident Management helps support the services that the customers are already paying for. Request Fulfillment sets up new services for customers that have been selected from a predefined offering, the Service Catalog.

If you understand the principles of function, process, and service, then you should be able to make a good distinction between incident and service request.
_________________
Manager of Problem Management
Fortune 100 Company
ITIL Certified
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.