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: VicentDick
New Today: 44
New Yesterday: 97
Overall: 149992

People Online:
Visitors: 28
Members: 3
Total: 31 .

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 - Tracking/logging Service Requests
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Tracking/logging Service Requests

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


Joined: May 10, 2006
Posts: 2

PostPosted: Thu May 11, 2006 9:46 pm    Post subject: Tracking/logging Service Requests Reply with quote

Our organization is trying to separate out the service requests from incidents. Right now the helpdesk logs everything as an incident. After reading different articles online, we first need to have our own definition of a service request. After that, none of the articles talk about what an organization does to separate them out. We use Assyst, so one choice we have is to log the service requests as a change record vs an incident record. If we do that then our definition of a service request would have to match that of something requiring a change not just a how do I question. Also, what sort of metrics are people putting against there open service requests? Time to close, how many open at one time etc??

Thanks
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Thu May 11, 2006 11:29 pm    Post subject: Reply with quote

OK - some ideas....would need a lot more info to make 'recommendations':

Service requests are more 'like' incidents than changes. Service request and incident resolution share the same measurements - time to resopond, etc. The metrics are slightly different, but as an implemented process the 'status' values are the same, the major process phases etc. Change management follows quite a different path. So service requests in the CM process are probably not going to be managed that effectively.

There are some key differences to consider: Incident classification is an interative process while classifying and assigning a service request should be 'correct' at the creation of the record.

Then again, both Incidents and Service Requests should be primarily calssified and reported on in terms of the Service they pertain to. Changes are more focused on the CIs.

Both Service Requests and Incidents can result in RFCs being raised. But a Service request is not an RFC. Many people ensure the scope of a Serivce request precludes its use as a defacto RFC.

Also, there is much debate, but I for one do not consider a 'how to' a Service Request but an Incident. The real distinction is between 'known' and 'unkown'. For a Service Request the actions required to deliver are known in advance. For an Incident Report what action is required to bring it to resolution is to a varying extent unknown. Most 'how to' responses are 'unkown' in this sense - hence they are incidents. In sites where incidents are locked into the semantics of break-fix this won't float. But if that's the case in you situation consider whether your definition of an incident is too restrictive.

Generally I follow a couple of core priciples: Don't compensate: If a process is deficient or lacking in some way strengthen the process, don't build epi-processes. Secondly Don't overload: keep a process focused on its actual objectives and don't oveload it's information architecture or decision and control points and business rules to make up for gaps in other parts of the organisation. (For example don't use incident management to compensate for a lack of configuration management by overloading the classification schema, and reports, with asset data.)

As for separation the only separation is that Service requests should have defined and documented delivery procedures. Actually it might be helpful to work back from that: If a client is not requesting a known and defined deliverable with a documented procedure for it's delivery then it's an incident report (well roughly speaking - obviously complaints and 'why don't you buy....' don't count either). Which comes back to basics: an incident is a disruption to a service (any disruption) - some of which will be failures - but only some.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
homer14
Newbie
Newbie


Joined: May 10, 2006
Posts: 2

PostPosted: Fri May 12, 2006 1:31 am    Post subject: Reply with quote

Thank you for the reply. It was all helpful information. The part that I'm stuck on is what do other places physically do with service request. Are they lumped in with incidents but just categorized as service requests? With our software we can have incident numbers and change numbers. our definition of service requests could match that of what requires a change record.

You also stated...
But a Service request is not an RFC.

Which would mean we shouldn't log service requests as change records.

Long story short is our organization doesn't want to have service requests counted in with our backlog of open incidents, thats why they want to log them different or separate them in some form.
Back to top
View user's profile
ozz
Itiler


Joined: Apr 02, 2006
Posts: 40

PostPosted: Fri May 12, 2006 3:15 pm    Post subject: Reply with quote

Also donít forget that how you categorize is totally up to you..
Service requests can and should have SLA / OLA .If customer needs toner it could be a service request. If the toner is not delivered before the other cartridge runs out then it can turn into an incident. You can use the idea that service requests do not have a root cause (and or unknown cause ) to assist in definition also.
The metrics would evolve from the SLA /OLA. How long does it take to get the toner shipped in? How long does it take to get the toner from the internal shipping department?
How much lead time does desk side support need to schedule the toner replacement?
So you would have to look at past performance and work from there.
Given that I had to chose between using change or incident to track service requests, my guess would be incidents as it would be better suited. Adding RAM , New PC, new user can be service requests .(re-edited)

Remember though, modify the tool to meets your needs /process, donít do it the other way around. The tool was never built to manage your company, the tool can only report on your process..

HTH

oz


Last edited by ozz on Fri May 12, 2006 9:15 pm; edited 2 times in total
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Fri May 12, 2006 8:10 pm    Post subject: Reply with quote

Homer, is there a way of filtering what shows up in your backlog (report/console/dashboard?) against a field in your current incident records?

In process terms, where service requests are handled efficiently as a 'branch' in the incident management process the following characteristics usually pertain:

* Incidents are initially 'types' - they don't become bound to specific things until investigation has yeilded some results. Service Requests are specific. For example, an Incident might be initially identified as simply Email -> Business Process: With a descritpion indicating an error in a business process has blocked the user, or Email -> End User Compentency - indicating the user did not know how to use a function, and etc. A Service request might be Email -> Forward Mail. The service request is specific.

* The incident classifications capture general categories of incidents, while for Service Requests there will be one specifc correct classification for each one. There is no such thing as a generic Service Request.

* Assignments are handled exactly the same way, as are SLA timers, and alerts and notifications.

Ozz, this is a critical differential between CM and IM and why Service Requests are not manageable as changes - CM process don't monitor the progress of RFC against preset time-based targets established in SLAs - and shouldn't. And changes aren't assessed against delivery time performance metrics. You will have either a very technically convoluted change management process or no mechanism for ensuring timely delivery of SRs against agreed targets.

Homer, you need to examine this issue against you existing change management system, and if you are going to loose the capability to keep service request delivery performance aligned to SLAs and customer expectations - take that back to the people driving this and make it brutally clear to them.

* Service Request procedures are modelled in tasks or groups of task records specific to the request, and assigned to the delivery staff. These are often specific records related as child to the Incident Record that instantiates the original request. They don't have to be though - they may simply be a 'skill' or sometimes a document attached to the record.

* Incident Management metrics and reporting include Service Request - because these deliver acknowledged business capability that the user does not have while waiting for delivery. I.E they impact the business in the sense that once the business requirement is identified via the request, the business is disrupted until the need is met - hence their status as incidents. (Changes don't come under 'prior agreement' and so do not need to be controlled this way. Where a change is in response to an incident the duration aspect remains controlled by whether the incident remains unrresolved - maybe through the emergency change model or through RFC priroitisation. But the measurements come from the tickers on the open incident. You would otherwise have to synthesis two distinct sets of metrics to produce meaningful Service Quality reports.)

* Because delivery of Service Requests is acknowledged as a Service Quality and business capability input the backlog is no less important than the back log of incidents. For Management purposes, VUI presentation may separate these - or at the very least group and sort them out from incident reports. Likewise there are frequently separate reports, and they tend to be filtered out prior to Probelm Management examining current incidents - as they are legitimately uninterested in Service Requests.

In the end, however, you do what you have to do. Be sure that any loss of capability to monitor the duration of delivery (and the consequent risk to the business users that SRs may start taking longer, SLAs if you have them, may be breeched without record, and general customer satisfaction may fall).

It could be the case that you have a legitimate reason not to care about your delivery performance on SRs - in which case you can certainly manage them as standard changes.

I think the biggest risk that you have is that when you move them over to change management it will emerge that they are 'monsters' in that process - but in a different way.

Ozz - mate Smile (I actually lived in Carrum for a few years in my teens) - I have to object. Yes everything that happens is a change - but in any technical or process context care has to be taken about use of natural language meanings - eg: Reconciling a bank statement v reconciling two enemies. What counts as a change has to be controlled and scoped appropriately in every site. Not every thing that changes is a 'change' - only those changes that it has been decided will be controlled by formal Change Management processes. Correct scoping is a 'critical success factor' for CM, and over-applying change controls, with attendent admin overheads, a specified 'potential problem'.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
ozz
Itiler


Joined: Apr 02, 2006
Posts: 40

PostPosted: Fri May 12, 2006 9:19 pm    Post subject: Reply with quote

yes I edited my post .. I meant to put incident and I alluded to that up the post a bit.. Too late in the evening.. Razz

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


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

PostPosted: Mon May 15, 2006 4:46 am    Post subject: Reply with quote

homer14 wrote:
The part that I'm stuck on is what do other places physically do with service request. Are they lumped in with incidents but just categorized as service requests? With our software we can have incident numbers and change numbers. our definition of service requests could match that of what requires a change record.

You also stated...
But a Service request is not an RFC.

Which would mean we shouldn't log service requests as change records.

Long story short is our organization doesn't want to have service requests counted in with our backlog of open incidents, thats why they want to log them different or separate them in some form.


Hello Homer,

There's a very good reason as to why your organization doesn't want to mix the two together. Very simply, it's because they're two very different different and distinct things. What we've found is that ITIL confuses the concept of "Service", by having topic domains such as Service Management, Service Delivery, etc.

If you go by traditional IT practices, think of "nouns" as your primary trackable entities. For example, an Incident, a Problem, a Change, a Product, an Asset, a Service, etc.

Unlike Incidents, which are strictly "disruptions" to an End User's "experience" (that disruption manifesting itself in a Product, Asset, Service, etc.), Services are a bit different. A Service, is something performed or provided to an End User that they rely on, either through a dialtone experience (meaning it's always there for them) or through an On-Demand experience (meaning through a Request that results in work). Therefore, if an organization provides one or more Services, such services are usually registered within a Service Catalog and managed, somewhat like Products located in a Product Catalog, meaning there are people associated with them, constant Releases, Changes and improvements to the Services, etc. Their quality, costs, and effectiveness is constantly being measured.

In wanting the execution of a Service, an IT or non-IT End User will typically have three primary channels to create a Service Request and have work performed to complete and deliver the output(s) of that Service.

1) The first channel is to call a Help Desk/Service Desk, who will put in a Service Request to the Service Provider to perform the work or who will perform the work themselves. In this case, the HD will log the Service Request to ensure it's tracked.

2) The second channel is for the End User to go directly to go to a Service Catalog (in a Self Service format), find the Service definition they're looking for and put in a Service Request, which will get routed directly to the Service Provider, who will perform the work.

3) The third channel is to go directly to the Service Provider and put in an informal Service Request, where the provider logs the Service Request and manages it to deliver the output.

A Service Request, typically maps to one or more Tasks, across one or more Service Groups/Organizations. These Tasks or work items get managed and closed as they are performed. It is through these Service Requests (Tasks) that you can measure the work being performed against the Services contained within the Service Catalog. This is a very critical point to understand, as without this information, your enterprise will not be able to measure their Services in an effective manner.

As stated earlier, an Incident is typically considered a "disruption" to a Service or to a Product's or Asset's performace. A Service Request is typically a request for work to be performed. A Help Desk/Service Desk should always distinguish between the two things as they are clearly distinct.

In our system, our customers have explicitly asked us to separate Services and Service Request Tasks from Incidents, Changes, Problems, Risks, Releases, Products, Projects, etc. so that all of them can be appropriately inventoried, tracked, and measured for things like performance and quality. Our customers have found it to be very productive to keep such things fully separated.

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.