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
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 - Distinguish between ‘Standard Changes’ and ‘Service Requests
Hi,
Though I'm relatively new to ITIL, this should be answerable from ITIL Foundation material;
a service request is any request not resulting in a change. Examples are resetting a password or reuesting information or training. These requests are in principle also not incidents because they technically do not constiture a disruption of service (unless you reason that not having the training or information is disruptive).
So basically the CMDB doesn't even 'notice' service requests, apart from inquiries into the ICT architecture.
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Wed Jun 14, 2006 10:38 am Post subject:
Flip is correct, and has put it very well in saying the CMDB doesn't 'notice' service requests. It's an excellent way of summarising the scope issue.
There is one rider however: Service requests are a mechanism for end-users making their requirements for defined deliverables known to IT through the Service Desk.
The Service Desk is intended to be the Single Point of Contact. This is a very important principle in ITIL and (IMHO) should not be watered down.
This means that if you have any work processes that lead to changes that you do want end-users to be able to initiate you need to accomodate this at the Service Desk.
To do this without blending service and change requests, carry out such service requests by raising seperate RFCs (which for practical reasons would be limited to pre-approved standard changes).
This will accomodate service requests like 'procure and deploy an new PC for a new staff member I have coming in'. A lot of CMDBs will have desktops in scope and will definitely want to 'notice' a new one.
(BTW: there are other intiation points than the service desk for activity in IT - primarily through the service (level) management cycle. But these provide key interfaces between IT and the customer - not the end-user. Another important distinction: Customer = representative of the business function to whom the services are charged (or 'charged') )
NB: You might also want to search the existing posts on this forum - this question comes up quite frequently, and there has already been quite a lot of discussion (and debate) on this question. (If I were to write an ITIL FAQ this would be in the top 5)
It's an excellent way of summarising the scope issue.
There is one rider however: Service requests are a mechanism for end-users making their requirements for defined deliverables known to IT through the Service Desk.
The Service Desk is intended to be the Single Point of Contact. This is a very important principle in ITIL and (IMHO) should not be watered down.
This means that if you have any work processes that lead to changes that you do want end-users to be able to initiate you need to accomodate this at the Service Desk.
To do this without blending service and change requests, carry out such service requests by raising seperate RFCs (which for practical reasons would be limited to pre-approved standard changes).
This will accomodate service requests like 'procure and deploy an new PC for a new staff member I have coming in'. A lot of CMDBs will have desktops in scope and will definitely want to 'notice' a new one.
I agree with Flip's summary but it's critical that it includes RJP's rider. The end-user-based interaction through the Service Desk is critical when thinking about a service request. For example, there may be internal corporate or enterprise systems that require some action that still may not be visible to the CMDB, but a Change Reqeust is still required. A CMDB may not contain the evidence or detail the elements of the change that's required. For example, a "server" class CI may not track the BIOS version of a particular server, but obviously, you'd expect an RFC would be generate if the BIOS needed to be updated.
To add to this point, some organizations set a threshold for the number of users affected (or touched) to determine if an SR or RFC is required. For example, if you have an IMAC function rolling out application push to 1 user, an SR would suffice, but if the same IMAC group is rolling this application push out to 20 people, an RFC might be warranted.
its bit different as far as I understand
Services can be provided with service request if requested service is fall under service catalogue
whatever is not in service catalogue needs change request
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
