Confused by request management vs. incident management? Don’t be!

Guest post by Pete Budic, HP R&D Functional Architect

 

 

In planning your IT Service Management (ITSM) solution, it is important to understand the differences between Service Request Management and Incident Management, as well as the types of processes served by each discipline. I know that users are often confused by these two types of management, so I want to clearly describe their differences to you.

 

The overall goal of ITSM is to provide a business service that provides meaningful value to the users of that service.  It is important not only to define the service itself, but also several important sub-processes that the consumers have access to such as:

 

  • How can someone become a user of the service?
  • How can someone stop being a user of the service?
  • How can someone ask questions about the usage of the service?
  • How can someone make a complaint about the service?
  • How can someone get help on an issue they are having with the service?
  • How can someone request a modification to how they are using/receiving the service?
  • How can someone can make a suggestion on how to improve the service?

 

All of the above are part of the overall service definition.  The IT department expects the service consumers to use these processes as part of the day-to-day operation and consumption of the service.

 

From these questions we can derive the high level definition of the Service Request Management process. 

 

 Service Request Management encompasses the consumer-facing processes that make up the expected, day to day activities involved in providing a service to an individual or group.

service request management 1.png

 

These activities can be defined at a high level as either Service Requests or Support Requests. 

Service Requests are the set of pre-defined activities that can be performed against the service itself (such as increasing the size of a standard email mailbox, requesting additional memory for a virtual machine, or resetting a password for a specific application).  Service Requests will usually require the same type of information from the user each time (such as a user id or application name), and often lend themselves to automation.

 

Support Requests, on the other hand, encompass those requests that have not been pre-defined or even expected by the service owner.  This can include questions, suggestions or even complaints.  For many of these, a good Knowledge Base will allow a consumer to find answers on their own to their questions.  This removes the need for a service desk agent to manually respond to the request. 

 

However, many times a support request involves a perceived issue that a user is having with the service.  Here we start to see some confusion over whether the issue should be processed by the Service Request or Incident Management department.  To clearly see where the issue belongs, we can compare the definition we have above with our definition of Incident Management:

 

Incident Management encompasses the processes used by the service provider to track and resolve any issue that impacts the ability of a user to consume the service.

 

Incident home.jpg

 

It is important to note that an issue that impacts the operation of a service may or may not be reported by a service consumer.  For most hardware or application issues, the incident will most likely be created directly by the service provider either manually or by some type of event management software.  However, for those Incidents that were either reported by a service consumer, or for those that affected a consumer that then reported it via a Service Request, both processes (IM and SRM) will need to be followed.  To understand this we need to look at the end goal of each process.

 

The goal of Service Request Management is to ensure that the user can consume the service to their satisfaction.

 

The goal of Incident Management is to restore normal operation of a service as quickly as possible.

 

The line between the two processes becomes more clearly defined at this point.  Using these definitions, one of the easiest ways to help determine if an issue needs to be handled by Incident Management is simply to determine whether or not the issue could affect the availability of the service as defined in any Service Level Agreements.  While this is not the only determination that we might use, if the answer to this question is "yes" then the issue in question needs to be handled within Incident Management.

 

Here are some examples that might be encountered, and which processes should be followed for each:

 

Example

Processes

Comments

A   user has forgotten their password for their email system

SRM   (Service Request)

A   good candidate to automate

A   user cannot connect to an application.    Investigation by the agent determines that the issue is caused by an   improper proxy definition on the user's machine.

SRM   (Support Request)

The   issue is not caused by the service provider

Event   Management detects that one of the servers in an application has   crashed.  Redundant systems keep the   application online, but users are taking longer than normal to login.

Incident   Management

While   the service is still available, there is an impact on the ability to provide   it

A   user calls in reporting that they are taking a long time to log into the   application.

SRM   (Support Request) - with link to IM

The   Service Request Management process will be used to handle the consumer.  They may want to be notified when the issue   has been corrected, or may simply be satisfied by the explanation.  The Service Request is linked to the   Incident to facilitate either.

 

In each case we can use the definitions that we derived earlier to determine the correct process:

  • Service Request Management encompasses the consumer facing processes that make up the expected, day to day activities involved in providing a service to an individual or group. The goal of Service Request Management is to ensure that the user can consume the service to their satisfaction.
  • Incident Management encompasses the processes used by the service provider to track and resolve any issue that impacts the ability of a user to consume the service.  The goal of Incident Management is to restore normal operation of a service as quickly as possible.

 

Applying these definitions to any incoming issue should make it apparent which ITSM process needs to be followed to ensure that the service is being provided in the most efficient way possible.

 

Are you are looking to improve your processes like incident and request management as part of a technology refresh?  Consider an HP Service Desk solution as both our options include out of the box best practices that can make your journey easy.  For a SaaS solution read about HP Service Anywhere and also test drive a free 30 day trial. Just register, and your credentials will come to your email in minutes. Looking for an on premise solution?  Read more about HP Service Manager Subscription. If you have any further questions, feel free to reach out to me the comments section below.

 

Comments
Hee Kiang(anon) | ‎04-15-2014 02:26 AM

hi Pete,

 

I like your explanation and clear positioning on SRM, and using this process to distinguish between Service Provider's triggered issues as opposed to Customer's triggered issues.

 

I like to also hear your thoughts on the following scenario

 

The helpdesk may have attempted to resolve a email-related problem and applying a workaround that does not work for the customer. The customer does not accept the solution and asked for more help and escalation.

 

This issue may be beyond helpdesk's technical capabilities.

 

So technically in ITIL, this would require a functional escalation.

 

Now that the issue has not be confirmed a Service Provider's issue yet, it could still be related to some settings in the customer's PC. Would you recommend that the Ticket be escalated within the SRM process or be escalated to the Incident Management Process?

 

regards

Hee Kiang

Guest Blogger (HPSW-Guest) | ‎04-23-2014 02:24 PM

At this point, the question of whether or not the issue should remain in the SRM process is going to be guided by any agreements the Service Provider has with the customer.  If there is any agreement with the customer that the Provider is responsible for ensuring the service works on their PC, then this can be seen as a degradation of a provided service and should be escalated to Incident Management.

 

In your example, I would imagine that this would most likely not be the case and the issue in question would not be counting against the customer's SLAs. So the escalation would take place inside of the Service Request process. 

 

Pete

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
This account is for guest bloggers. The blog post will identify the blogger.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.