Posted: Thu Jan 06, 2005 7:09 pm Post subject: Service Request verse Change Request
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.
Posted: Fri Jan 07, 2005 2:20 pm Post subject: Change request versus service request
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
Posted: Sat Mar 26, 2005 10:13 am Post subject: Service Request or Standard Change for password reset
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...
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.
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.
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Sun Jun 19, 2005 4:39 am Post subject:
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.
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Thu Jul 21, 2005 2:35 am Post subject:
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.)
Joined: Dec 22, 2005 Posts: 10 Location: South Yorkshire, UK
Posted: Wed Feb 01, 2006 8:11 pm Post subject:
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).
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Mon Feb 06, 2006 1:44 pm Post subject:
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]
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Mon Feb 06, 2006 8:44 pm Post subject:
Mmmm, not sure - 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).
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