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 - All RFC through ServiceDesk?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

All RFC through ServiceDesk?

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
rmch
Newbie
Newbie


Joined: Aug 04, 2006
Posts: 5

PostPosted: Thu Aug 31, 2006 4:53 am    Post subject: All RFC through ServiceDesk? Reply with quote

According to ITIL, incidents which become problems which require changes can be initiated by the SD by creating an RFC and submitting it to the change process.

What about RFCs that are not related to incidents or problems? (ex: new features requested by a user).

Would a user phone the SD and tell them they want a change to a system, at which point the SD would turn around and create an RFC with all the details? Or would the user create the RFC directly without talking with the SD at all? Or worse yet, the user would fill out the detailed RFC on paper, give it to the SD, who then types the information into the electronic RFC system?

If RFCs are electronic (let's say), I don't see why a user cannot enter an RFC without involving the SD. It would be the responsibility of the Change Manager to filter out, and categorize these RFCs, not the SD.

Any comments?

Currently, we're debating what the term "single point of contact" means as it pertains to SD. Some say that RFC should all go through the SD before going to the Change Management system.
Back to top
View user's profile
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Thu Aug 31, 2006 7:05 am    Post subject: Reply with quote

Hi rmch,

Believe it or not, but this is merely a mather of choice. If and when you agree with all parties involved, that the service desk is THE s.p.o.c. for any contact, you can channel all RFC's through service desk. Obviously, it would decrease effort needed by the IT dept when you make customers / users fill in their own wishes.

In reality, I suggest you make a distinction between standard changes / agreed services on one hand, and non-standard changes / newly requested services on the other.

The first category could be requested by users, or central contacts ("power users", IT-coordinators, managers etc. with budget responsibility) amongst the users. They could send their request to the service desk. These changes/services will usually have a small impact and have a very operational focus.

The second category should be requested by customers (i.e. those who pay the bill) only. These changes can have a serious impact on the business side. Customers would usually send their requests to a (tactical level) service or account manager.

I must admit that it will be a lifelong struggle for the service desk to make the distinction between standard changes/services (rightfully adressed to them) and non standard stuff which they ought to redirect to service / account manager.

Hope this helps,

cheers,

Michiel
Back to top
View user's profile Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Thu Aug 31, 2006 5:03 pm    Post subject: Reply with quote

Good Day Rmch,

Most RFC requests come into existence long before SD gets involved. SD is primarily a support function and RFCs can and often do bypass them, especially if people can generate them through an electronic form, as you described. Typically, RFCs are meant for the development and engineering teams that need to design, implement, and test the changes before they get implemented by SD in a production environment.

As a result, RFCs can be generated by anyone in the enterprise that is involved with a service or product, regardless of how they're involved. Ultimately, Product Owners and their teams are not in SD. It is the Product Owners that will have Product Managers work on Release decisions for them, such as what Changes will make it into any given Release. Such decisions will typically be communicated to SD as part of the Product Management funtion, since the Product Manager will want SD's input, like any and all other relevant stakeholders, on what they feel is important for the Release.

I hope this helps.

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


Joined: Aug 04, 2006
Posts: 5

PostPosted: Wed Sep 06, 2006 2:51 am    Post subject: Electronic RFC Reply with quote

Thanks for the replies.
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Thu Sep 07, 2006 8:43 pm    Post subject: Reply with quote

Although I agree with Frank that the RFCs are primarily for the Solution Providers, in our Company as a Service Provider ourselves, our Service Desk wants sight of our RFC's at the earliest opportunity.

This gives them sight of an action that may have already impacted them by virtue of calls raised by disgruntled users, or may impact them in the near future in the case of a new application going live / into User acceptance Testing.

To recap for newbies that don't know me - we have a paper systemfor Change / Release only + a Service Desk that has grown out of multiple help-desks. that now handles all the calls for all the Customers very successfully.

We ensure that our SD sees the RFC at authorisation point (they do not sign it off until release stage).

This is seen as a must by them.

Regards

Ed
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Fri Sep 08, 2006 6:14 am    Post subject: Reply with quote

Ed wrote:
Although I agree with Frank that the RFCs are primarily for the Solution Providers, in our Company as a Service Provider ourselves, our Service Desk wants sight of our RFC's at the earliest opportunity.


Hi Ed,

You bring up an excellent and very important point about wanting to make sure that all generated data is seen as early as possible by all impacted stakeholders. This is a huge issue for many paper and spreadsheet based ITIL implementations. It works fine for smaller companies but starts to break down as companies reach a larger scale. Part of the issue is the fact that it becomes very difficult to ensure that the data being used is the most up-to-date, accurate, and definitive copy.

This is purely informational but I'd like to qualify that the way we address this is that we offer our clients a fully integrated and web based ITIL platform that is open for data mining and reporting to all stakeholders, regardless of their geographic location. This means that any and all stakeholders (such as Service Desks, Service Delivery teams, Business Units, Developers, etc.) can easily see any and all data, such as RFCs being generated, by any and all stakeholders, world-wide, as soon as they're put into the system. (They can even add and manage RFCs, themselves.) As a result, they know exactly which products, releases, systems, services, etc. are being modified and can track who's doing the work, timeframes, the progress across environments, any documentation being generated, etc. as it's all generated and added to the Changes.

Because it's all in one place, downstream stakeholders can start to perform impact analysis, prepare future work schedules, and know which end-user Resources, Organizations, Facilities, and Assets will be impacted by the Changes, etc. long before the Changes actually go into their targeted production environment.

The beauty of a real time electronic system is that the data is live, fresh, and transactional. Think of it as "real time ITIL". So, as people work, generate, and modify any data, any and all related stakeholders get live, accurate, and real time updates. It also means they have a live CMDB and knowledge management system that can find both the most recent information as well as all historical information. One thing I personally like very much is having a paperless environment, where I have access to any and all operational information, regardless of where I am. I never realized how much more efficient it would make us until we actually started using the electronic solution. But, I do realize it's not for everyone.

Anyhow, I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Page 1 of 1

 
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.