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: Gabriel78
New Today: 59
New Yesterday: 68
Overall: 131819

People Online:
Visitors: 38
Members: 1
Total: 39 .

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 - Service Request verse Change Request
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Service Request verse Change Request
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
glennL
Guest





PostPosted: Thu Jan 06, 2005 7:09 pm    Post subject: Service Request verse Change Request Reply with quote

I am starting to set-up a Service Desk using ITIL as a basis for definitions. The definition of an Incident is clear as ITIL training makes it so ie Any event which is not part of the standard operation of the service and which .....

What is not clearly defined in ITIL is a Service Request and its relation to a Change Request. Should all non-Incidents be captured as Service Requests. Then if they relate to a change then a Change Request is created as well. Alternatively, are Service Requests mutually exclusive to Change Requests ie a Service Request might be a request for a new PC whereas a Change Request might be a request to provide a new report.

If there is no hard and fast rule then let me know.
Back to top
Tania
Guest





PostPosted: Fri Jan 07, 2005 2:20 pm    Post subject: Change request versus service request Reply with quote

Hi Glenn,

For me the rules are fairly simple:

A service request is a request which does not require a change to the infrastructure. For example in my current organisation, a service request is a password reset, a request for a quote, a request for printed output, office application education, etc

While a change request is any request where a change to the infrastructure is required. For example: New infrastructure installs, existing infrastructure changes, new user accounts, changes to user profiles, new or altered web pages, etc

Hope this helps, best wishes.

Tania
Back to top
blamblam
Itiler


Joined: Jan 16, 2005
Posts: 37
Location: New Zealand

PostPosted: Mon Jan 17, 2005 8:07 am    Post subject: Reply with quote

I agree with Tania. The request to provide a new report would be categorised as a Service Request, i.e. no change to infrastructure (Change) and no impact on service operations (Incident).
Back to top
View user's profile Visit poster's website
gliph
Newbie
Newbie


Joined: Mar 25, 2005
Posts: 1
Location: Ohio, USA

PostPosted: Sat Mar 26, 2005 10:13 am    Post subject: Service Request or Standard Change for password reset Reply with quote

I know this is bringing up an old thread, but I have a question with this as well. In our organization there is no automation behind user password resets, so I would think that any password reset is a Standard Change. If we had an automated tool and someone called in and said "how do i change/update my password" that would be a Service Request since it is giving the user information on a standard process and it doesn't require the Service Desk to actually make any changes....

OK, so here are my thoughts on this:
If a user called in and said "i need my password reset because i'm locked out", its an incident. the IT level of service is impacted and the user has less functionality than is usually available. to restore service, it would be a Standard Change because you are changing/resetting an item in the production environment.

i've tried to read up on the "true" definitions for service request and standard change, they are very similar, but with the change it is actually making changes to something (duh). so is a password reset considered a "change" in the world of ITIL?

I'd really appreciate any feedback on this. I'm still really new to this ITIL stuff and i'd appreciate any insight and thoughts... Smile
Back to top
View user's profile
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Wed Mar 30, 2005 11:15 pm    Post subject: Reply with quote

Hi Gliph,

I have to deal with definitions crap too, and let's just keep in mind that ITIL is open to interpretation at all times because no two environments are the same.

To me, on paper, a password reset is a change because the change in the password its self actually increases or decreases the vulnerability of that system. Also, it is a change because at the definitive level because you are changing the properties of that account, even if it were by only one character.

But you've got to draw a line somewhere, do you really want your Service Desk logging requests and then spending time logging Change Requests? A bit time consuming. Maybe you could get them to log the latter only and just incorporate them into your Service Desk reporting for work logged? Do people really care where the work is logged provided it's transparent and report-friendly? It's your call, you can be creative but don't beat yourself up over it otherwise you'll be going home and kicking the dog.

Cheers,

Urgent
Back to top
View user's profile
Roger
Itiler


Joined: Aug 02, 2004
Posts: 35

PostPosted: Thu Apr 21, 2005 3:08 pm    Post subject: Reply with quote

All good points, but let's make a quick return to the basics..

A user never calls the Service Desk with a Change. They call the Service Desk with an incident or a service request.

The Service Desk then works to resolve the incident or the service request in the shortest possible time - your classic Incident Management.

If the organization decides that a password reset is to be classifed as a Change then there is nothing to suggest that there should be a delay, while the Change Management processes is somehow magically invoked.

The Change Management process can define a type of change and call it "Password Reset Change". The change is opened at the start of the year, with a validity of 12 months. It is classified as a MINOR change with Change Authority granted to the Service Desk Personnel.

The Change has been approved by the CAB, is monitored by the Change Management process owner (reviews, audits, etc.) and the user is not hampered by delays.

The specific incident is then closed with a reference to the "Password Reset Change" number.

Later when/if the incident is reviewed by the Problem Management team they will be looking at the number of incidents that have been closed that make reference to the minor "Password Reset Change". They will combine that metric and cross tabulate it with other data (such as user department, etc.) and uncover patterns of recurring incidents (eg. the majority of "Password Reset Changes" come from the Human Resource department. Next the team approaches HR to establish why this may be happening and put in measures to prevent it... so lowering the incident count, etc. etc... )...

It's all very neat and my story could go on to incorporate all ITIL processes.

The challenge that most people face is that they see ITIL processes as a rigid set of time driven activities, rather than (what they are) as a set of continuous ongoing, interrelated set of activities - that transcend multiple people, working in multiple functional areas.

ITIL processes are CONCEPTS. They should not be viewed as stand alone processes that have definitive barriers between them.

My story above demonstrates that the LOGICAL thing to do is:
(a) resolve the incident quickly under change management defined changes,
(b) look for incident patterns,
(c) head into root cause analysis to try to find out why these incidents happen...

the CHALLENGE is that most organizations, continue to provide incident only, neglect the PROBLEM Management and see Change Management as something that only happens once a week.
Back to top
View user's profile
dreamsta
Guest





PostPosted: Thu May 12, 2005 9:35 pm    Post subject: Reply with quote

This may help

In our organisation we define a catalog of "pre-approved" changes. The pre-approved change catalog is reviewed and endorsed by the CAB.

Resetting a password would be a 'pre-approved' change that can then be managed by the Service Desk under the normal Service Request process.

jas
Back to top
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sun Jun 19, 2005 4:39 am    Post subject: Reply with quote

The Service Request Procedure block in the Incident Life Cycle diagram has certainly generated a lot of debate in ITIL circles.

In the end though it makes sense that an incident isn't identical to a 'fault'. It's a disruption and may not be caused by a fault.

Even not having a service may be a disruption from a business point of view - so some one putting in a standard request for access to this or that system, or some other thing like a special email account for a role they are taking on are still handled by the incident life cycle.

So incidents can be resolved by providing a bog standard - known-outcome service which is delivered by a pre-defined processes.

Are these changes? Depends on who intent you are to make sure that the natural language meaning of 'change' is retained or not. But all activity is a change - so some line has to be drawn. Within reason, it's not so much where you draw it, but that everyone is totally clear on where it's been drawn and why.

In our case a change was formally defined as something that alters the capability or components of a service.

A password reset does neither - ergo it is not a change.

This has to be complimented from the Configuration Management side as well. If someone changes the picture on their desktop is that a 'change'? But what if they disable the automatic connection to the System Update Server?

If a CI is in scope - that is if it has been included in the CMDB then it is subject to change mangement. In this case we refer to 'standard' changes as those that don't go throught the CAB - like change a failed component with another one of exactly the same make or model. (However, the Config Management auditing processes must be adhered to).

So a change is something that alters the capability or components of a service - or alters a recorded CI in anyway.

The current status of an end-users email password is not a recorded CI in the CMDB, so it is not subject to change management, and therefore not considered to be a 'change'.

Not the only way of answering this question - but hope it helps.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
ITIL_Practitioner
Newbie
Newbie


Joined: Jun 23, 2005
Posts: 2

PostPosted: Fri Jun 24, 2005 12:34 am    Post subject: Reply with quote

Generally Service Request can be applicable to any non break-fix type of request. In my opinion, a RFC = request for change can be a subset of Service Request.
Back to top
View user's profile
kayla
Newbie
Newbie


Joined: Jul 19, 2005
Posts: 1

PostPosted: Tue Jul 19, 2005 11:53 pm    Post subject: Thank you rjp Reply with quote

Your post clarified a few things that I've found fairly slippery.

rjp wrote:

In our case a change was formally defined as something that alters the capability or components of a service.

A password reset does neither - ergo it is not a change.



A password reset would be considered a change if it's for a service account that runs backup scripts, correct? The scripts would have to be changed to incorporate the new password.
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Thu Jul 21, 2005 2:35 am    Post subject: Reply with quote

Mmmm, kayla, Wink

That's an interesting example.

If I understand the scenario: The scripts authenticate programatically during their execution? (I assume form this we are not talking windows servers - where I would expect them to be run under service account permissions to give them access to the required resources)

But that's neither here nor there - The real question is; is that particular password reset a change? - particularly because it affects a dependent CI (the scripts), which would fail if the dependency was not documented and the password reset not accounted for.

You can go either way. The service password may be considered a CI because of the dependencies involved and brought under change control. However, you could also decided that the scripts were the CIs that required controlling, and the password event was simply a trigger for a change to the scripts. In which case the password reset is not the 'change' - after all the service account isn't really 'changed'.

The main thing is you achieve the goals of making the dependency visible, identifying the impact of a critical event, and controlling the processes required to manage that event to ensure no disruption to services / operations.

This is what you would call a question of scope in your configuration management processes. Your definition of what a change is, can never be independent of the scope of your managed CIs.

Also, I think your example is a good one of a 'minor' change: One that would be pre-approved, and for which a procedure, and even a schedule, would be in place - including status updates and work records for the affected CIs (whatever you deem them to be.)
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Jules
Newbie
Newbie


Joined: Dec 22, 2005
Posts: 10
Location: South Yorkshire, UK

PostPosted: Wed Feb 01, 2006 8:11 pm    Post subject: Reply with quote

I would suggest a rather circular definition of a Service Request: as any incident for which a Standard Operating Procedure exists.

Thinking along these lines I realise that one must have *that* specific class of document. It will be different from other classes of document - such as "knowledgebase" articles - which will be more about anlysis and investigation (which in turn complement Known Errors which represent the output of the investigations).
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Feb 06, 2006 1:44 pm    Post subject: Reply with quote

Glenn,

You have a lot of responses and I hope I don't clutter any of the information you've already put together.

A definition that many of my clients tend to adopt is that a service request is a request to perform a specific service, such as one from a service catalog. Keeping this in mind, such a request can come from anywhere: an end-user, an internal client business unit, any internal group requesting a service from any other internal group, etc.

In addition to this definition, it is important to understand that some service requests can require changes to the environment or infrastructure, such as the request to build and deploy a new system or somehow modify an existing one, while other requests might not, such as the request to send them product literature.

These same clients also view an Incident as the reporting of a disruption to a service they're getting or to something they're using, such as a product or system. Someone calling the help desk may be calling to report such a disruption or to ask for a service, which is not an Incident, to be performed that might be executed or triggered via the help desk.

Also, not everything needs to go through the help desk. A testing system may report an Incident that goes directly into the Incident Management system, totally bypassing the help desk.

As for Change requests, there are many drivers. Service Requests can cause change to occur. Reacting to Incidents can cause change to occur. Addressing Problems, Risks, and Requirements can also cause change to occur. The point is to try and capture all drivers and the work associated with the changes, themselves. To complicate all of this further, please note that some changes can be pre-approved and can be executed without jumping through formal hoops, while others may require formal approval and rollout processes.

I hope this helps to supplement all the other information you've collected.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Mon Feb 06, 2006 8:44 pm    Post subject: Reply with quote

Mmmm, not sure Smile - yet another hopefully freindly disagreement Frank,

Changes to Services are changes sure enough, but they have a direct impact on operational and infrastructure deployment planning. And for a start are going to trigger SLA rewrites, budget revisions and a whole host of ripple effects that require a fairly high level management involvement - all of which are outside the usual scope of the Change Manager's or CABs authority. Changes to Services will have strategic implications and decisions should be taken at that level.

Changes to the components that are production factors of a service that may lower cost or improve efficiency are a different matter - where they do not alter the Serivce itself - the capabilities being delivered to the business. That's a tactical decision - but these RFCs are precisely the ones that come from Incident, Problem, Capacity, Availability Management & etc, out of good practice within the ICT organisation.

Service development is intended to be managed in an orderly business review cycle by ICT and key business process owners.

RFCs do come from a number of places - but while it is an option to allow anyone in the business to place an RFC at the Service Desk this is not a good idea. The end point of IT Service Managment is to make the ICT organisation a partner in creating value for the business. The people who are charged with deciding the direction of the business are those who should be driving change in the ICT portfolio.

At best I think the Service Desk processes should capture compalints and suggestions for improvements - which would be an input in periodic service rreviews.

For clarity I would not like to see (and alas I have and it just makes managing expectations and raising customer satisfaction so hard) end-user "RFCs" confused with standard Requests for Service (implied meaning being what actually exists, and what the ICT org has agreed to provide).
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
samlindsay
Newbie
Newbie


Joined: Mar 18, 2006
Posts: 2
Location: Melbourne, Australia

PostPosted: Sun Mar 19, 2006 10:03 am    Post subject: Reply with quote

Ok, I'm very new to all of this so forgive me if this is such a newbie question....

I have an example that different people in my company are debating over, clarification would be appreciated.

A customer calls up and asks for a mouse. At the moment we are logging everything as incidents, and this would be logged as IT Order / Consumable.

When we implement change management, would this request be logged as a change as it is altering the infrastructure or a service request (or are they practically the same thing in this example?)

Thanks for any assistance.....
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
Goto page 1, 2  Next
Page 1 of 2

 
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.