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: O15A
New Today: 94
New Yesterday: 92
Overall: 141438

People Online:
Visitors: 79
Members: 2
Total: 81 .

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 - Ending Request Fulfillment and Beginning Change Management
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Ending Request Fulfillment and Beginning Change Management
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
ItilyWoman
Newbie
Newbie


Joined: Mar 10, 2008
Posts: 9

PostPosted: Tue Mar 11, 2008 7:49 am    Post subject: Ending Request Fulfillment and Beginning Change Management Reply with quote

My company is just learning ITIL, and we are defining our Incident, Problem and Request workflows. Next, we will introduce Change.

I'm having a hard time understanding where requests end and change begins. In the workflow that I am designing, I expect three types of Requests to come into the HelpDesk. 1. Requests that they can answer 2. Standard Requests 3. New (nonstandard) Requests. In all three cases a Request record is completed.

Nonstandard Requests must be analyzed for impact, then if approved and changing a configuration item, sent to the Change Management process.

Standard Requests will not need the analysis for impact completed, so if needed they are sent straight to Change Management process.

In both of these cases a new Change Record is completed that is associated back to the request record. When the change is completed, both the change record and the request record will be closed.

In this design, the only way into the Change Management process is through the Request process. And, in this design the impact analysis is done in the Request process.

Is this a common design? Should we be performing impact analysis in the Request process? Any advice for us?

I've been researching but just cannot seem to find best practices on where request ends and change begins - so any help on this work be greatly appreciated!

Thank you.
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Tue Mar 11, 2008 11:11 am    Post subject: Reply with quote

Hi,

Just simple. If you make things the way you do now, then the answer to your question is there will be a nested ticket, meaning that the request can only be closed after the RFC is closed.

However, ITIL stated that impact analysis on a change should be done by the Change Management process.
Plus, if everything must be done through Request Management, it might extend the lead time a bit.

Cheers,
Asril
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Tue Mar 11, 2008 9:30 pm    Post subject: Reply with quote

Hi,

It seems to me that the request process you describe consists of (or, rather, contains) two phases of the overall change management process, namely impact analysis and approval.

This is just a matter of documentation structure and labels. You have to decide how important it is to map your structure to the ITIL conceptual structure.

ISO20000 states that the objective of Change Management is "to ensure all changes are assessed, approved, implemented and reviewed in a controlled manner." The standard does not care what you call the processes that effect this.
Back to top
View user's profile Send e-mail
Skinnera
Senior Itiler


Joined: May 07, 2005
Posts: 121
Location: UK

PostPosted: Tue Mar 11, 2008 11:12 pm    Post subject: Reply with quote

Hi ItilyWoman,

Can I just ask you what you mean by the 'Request' process...? And what you mena by a user rignign Service Desk and logging a 'Request' (as distinct from an incident, for example)

I'm aware that terminology may be used differently, so want to be clear before I offer any input Smile
Back to top
View user's profile Send e-mail
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Wed Mar 12, 2008 12:13 am    Post subject: Reply with quote

If I'm not mistaken, it was the "Request Fulfillment" from V3.
I used the name "(Service) Request Management" in my company

But let's wait for her answer.
Back to top
View user's profile
ItilyWoman
Newbie
Newbie


Joined: Mar 10, 2008
Posts: 9

PostPosted: Wed Mar 12, 2008 12:34 am    Post subject: Reply with quote

I am referring to the Request Fulfillment process. We are separating out requests from incidents. When a call comes into the Help Desk, they will either open a request type record or an incident record. Each has their own distinct workflows and processes.

Does this make it more clear?

Thank you!
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Wed Mar 12, 2008 1:16 am    Post subject: Reply with quote

Then I'll go with my reply.
In incident management, if it was realized that an incident should be escalated to problem management, then with a workaround, the incident ticket could be closed. Problem Management would then find the solution. In this case, Incident and Problem Management go in series.

In your case, the request could not be said as fulfilled until it's implemented, and to implement it should go through Change Management.. That would mean that a request ticket cannot be closed until the related RFC is closed. You can say that Change Management is nested into Request Management.

Hope this helps
Back to top
View user's profile
ItilyWoman
Newbie
Newbie


Joined: Mar 10, 2008
Posts: 9

PostPosted: Wed Mar 12, 2008 1:42 am    Post subject: Exactly! Reply with quote

But is this best practice?

I think some will argue that we should be able to go straight to the change management process without having to go through request. (enter a change record without having to enter a request record).

The reason that we can't go straight to the change management process is because the impact analysis step is in the request process. The reason it's in the request process is because many requests will need to be analyzed before approving to move forward to the change process.

In the end, this means that only approved changes are tracked in the change management process. It also means that a change priority is set with the request priority.

Is this a suggested method?

Thanks!
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Wed Mar 12, 2008 2:03 am    Post subject: Reply with quote

Because ITIL doesn't direct HOW to do the processes, it is up to you how you want to manage your service.
Some will also argue that bringing up V3 to V2 would not give a better practice because V2 has already reached maturity. V3 (in my opinion) is almost a completely different story, that's why you need bridge between them.

No matter what, as I said earlier, inserting the Request Management as a single entry of service requests prior to Change Management, would extend the lead time.

Don't worry, as long as you don't miss the impact analysis, doesn't matter which process is doing it, you'll be ok
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Mar 12, 2008 2:09 am    Post subject: Reply with quote

Hi,

the way you describe it, your change request process is just a part of change management. Impact analysis is a requirement of change management.

You say that change management can only be accessed via requests. This means that problem management, capacity management, improvement processes, user requirements and all other possible sources of change requirement all submit a request to your system. This gives you one point of control and that is obviously good.

So long as, at this point, you have separated out other kinds of request (such as service requests, information requests) then you are already in change management when you do impact analysis and prioritizing. It doesn't matter what you call it because you do it in one place under one control system and you will not be adding any bureaucracy if you simply treat the request record as the start of the change record.
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


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

PostPosted: Wed Mar 12, 2008 2:38 am    Post subject: Reply with quote

Hi again,

I'm a slower writer than asrilrm. I think our two answers complement one another.
_________________
"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
ItilyWoman
Newbie
Newbie


Joined: Mar 10, 2008
Posts: 9

PostPosted: Wed Mar 12, 2008 4:14 am    Post subject: Reply with quote

Thanks for "listening" and helping me out. I wanted confirmation that we're going in the right direction, and it sounds as if we can safely proceed with our current design and remain within the ITIL guidelines.

THANKS!!!
Back to top
View user's profile
ITILjnj
Newbie
Newbie


Joined: Mar 25, 2008
Posts: 2

PostPosted: Wed Mar 26, 2008 6:54 am    Post subject: Reply with quote

Sorry to resurrect this topic but I wanted to define things a bit more... We are carving out Intake from Request Fulfillment. Which essentially means, that since I'm the GPO for Request Fulfillment, I don't care how the request got to the fulfillment team, it's time to work on it. Intake will be defined and owned by the Service Catalog GPO.

We are planning on using our Service Catalog as our storefront, once the request is made via Incident (Request Type choosen) the necessary Change Tasks will be triggered. Approvals, etc. will be done at this level.

With this set up, what do I need to be careful of in implementing Request Fulfillment?

Thanks in advance for your help!
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Wed Mar 26, 2008 11:31 am    Post subject: Reply with quote

Hi,

In V2, requests are treated as incidents, so Incident Management process deals with it, as might be your current process's doing.
I have the feeling that Request Fulfillment process in V3 was created to accomodate services that doesn't fit the incident, change or problem criteria. Examples are server reboot, password reset, ad-hoc reports.
Since this is not a new thing, I don't see anything dangerous or problem potential in taking it in.
Your might have to define the criteria of requests, there is where you have to take care. Other things are just common sense.

Well, that's my opinion.

Cheers,
Asril
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Mar 26, 2008 5:15 pm    Post subject: Reply with quote

Hi,

where I used to work, there were four classes of service desk calls:

incidents
change requests
service requests
information requests

Request fulfillment is a V3 term. I only have access to some overview material on V3. My impression is that request fulfillment is a fairly abstract concept that you might apply to measuring success and timeliness in addressing the three non-incident classifications above.

Change requests would be addressed under the change management framework, service requests would be addressed by the processes for that service and information requests would be routed to the relevant service area. Of course, some incidents, services and information would be dealt with during the first call by service desk staff, but it would still be classified in the call records.

I'm not sure how a request fulfillment team would function in that environment. But, like asrilrm, I don't see any new pitfalls to be aware of.

PS forgive my ignorance, but what does GPO stand for? Is it a V3 term?
_________________
"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
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management 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.