Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Thu Aug 31, 2006 4:53 am Post subject: All RFC through ServiceDesk?
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.
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Thu Aug 31, 2006 7:05 am Post subject:
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.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Thu Aug 31, 2006 5:03 pm Post subject:
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]
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Thu Sep 07, 2006 8:43 pm Post subject:
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).
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Fri Sep 08, 2006 6:14 am Post subject:
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]
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
