IT Service Management
cancel
Showing results for 
Search instead for 
Did you mean: 

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

HPE-SW-Guest

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

About the Author

HPE-SW-Guest

This account is for guest bloggers. The blog post will identify the blogger.

Comments
Hee Kiang

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

HPE-SW-Guest

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

Stantonl

This post was very well-written and right on target. But the distinction between the two distinct processes has been obliterated in two of the most prominent ITSM tools on the market today: Remedy and ServiceNow. Thus we have the necessity of posts like this to clarify something that was not confusing until recently.

I believe that the confusion began in 2005 with the release of the ISO/IEC 20000 "Code of Practice" which purported to provide guidance for organizations in achieving ITIL compliance. It actually did so, to an extent, in spite of numerous objections to some vagueries contained therein (such as extensively using the term "event" without defining it). But the real can of worms was opened by its definition of the objective of Incident Management: "To restore agreed service to the business as soon as possible or to respond to service requests."

The first phrase in this definition is straight out of ITIL, but the second appears out of nowhere, and has nothing to do with Incident Management. As IT professionals and ITSM tool-developers began to incorporate this skewed definition, the British Office of Government Commerce (OGC) responded to the newly-sowed confusion with the release of ITIL version 3 two years later. This release clearly spelled out the difference between Incident Management and Service Request Management, which had not been necessary in prior releases, as no one had been conflating Service Desk functions with the technology-centric process of Incident Management.

The confusion persists, however, because some major tools have gone down that path and it would be too disruptive for them to return to best practices. Many in the sales forces of these organizations seem have no memory of a time when these processes were separate - and the certification organization Pink Elephant gladly certifies organizations and tools that have taken this wrong turn.

I now wonder if this particular ship will ever be righted.

Tanmoy Bhattacharya

I am not concluding but reaching a point that user can always raise a Service Request which Servicedesk will decide and put in proper category.

Normally Service Request(SR) invloved with IMAC process and there is no business impact but in case of Inciednt Mgmt interruption of service is there as well "Workaround".

SLA for SR and IM is different and very critical for IM.  IM is closely related with Problem Mgmt and before PM it should be a major incident.

Please correct me if I am wrong.

Thanks.

 

 

Events
June 6 - 8, 2017
Las Vegas, Nevada
Discover 2017 Las Vegas
Join us for HPE Discover 2017 in Las Vegas. The event will be held at the Venetian | Palazzo from June 6-8, 2017.
Read more
Each Month in 2017
Online
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all