How do you define what requires a Change vs Service Request?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-04-2013 06:23 AM
Hello,
How do you define what must go through Change as oppose to a Service Request?
We're less mature when it comes to ITSM though many folks are on board. A recent topic of discussion is when does something require a change and thus various approvals and extended timelines vs a Service Request (no approvals). Our processes might be part of the problem in that the biggest reason for not wanting to use Change is that it requires going throuhg the CAB which means extended timelines. Our CAB don't currenlty approve individually, but rather they all meet once a week to discuss and approve changes.
None the less, I"m interested in feedback about how you decypher between a change and a service request.
Thanks,
Scott
- Labels:
-
Change Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-04-2013 07:03 AM
Service request can be any request from the user for any information, documention, advice or access.
Example: password reset.
But when it comes to change, its an addition, modification or removal of an approved, supported or basedlined CI. For Eg : Addition of new Service, upgrade server..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-04-2013 07:13 AM
for us it is pretty simple if it is going to require touching a server it requires a change ...
we had far to many short term outages to services by unscheduled changes.. so now.. pretty much anything that involves a server means a change form.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-23-2014 09:54 PM
Service requests can also be looked at as a type of routine change..
Right now we are starting to create change records for documentation purposes as part of our service requests for ci's that we currently maintain. So if we setup a request to build a new virtual server it manages the build activity,approvals etc via the service request workflow but also documents in a change record the build and release in addition to manipulating the cmdb for creation of the new ci and any appropriate service relationship mapping..
We originally created a normal change for each and the programmatically closed out each change task. Since our cab only looks at things with specific values that denote the need to review we did not have elongated timelines.
After talking with our change manager we will soon be creating the changes in a type not accessible to people creating a new change that does not have spawn a workflow so it will be more pure output and make sure we have things appropriately documented in each area..
Where to draw the line between create or don't..I guess I would say what happens if that request process breaks the thing you are changing.. could it affect ANYTHING else in the environment if so.. its a change..
Long as it is integrated well enough the division wont matter as much...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-24-2014 02:47 AM
Hi SCott,
Its a fair confusion. Let me try to give you how differentiate between these 2
Whenever you are requesting something that is not already available (Like requesting a new report ,a new server ,new licensed software or simply say creation of a new CI), you are requesting a service and this falls under service request.
Now whenever you want any modification in something which is already present (adding another parameter in the report, upgrading the server, extension of license or simply CI retirement or upgrade), you are modifying an already existing service or CI, hence it falls under Change Request.