Response Management
The more I think about it the more convinced I become that the way ITIL and COBIT and ISO20000 structure incident and request fails the basic test of being customer-focused or business-aligned.
From an inward-looking IT-absorbed perspective an incident looks very different to an request. From a user's point of view, they see no difference between "I need a new laptop", "My new laptop hasn't arrived yet", "I can't use this new laptop", "My laptop isn't working" and "I've lost my laptop".
We are mentally stuck on this separation of incident from everything else because within IT it looks different. It's time we pulled our heads out and looked from over the business side.
The word I like is "Response": we need to manage a response to a user contact. In fact I'll broaden that further and say we need to manage a response to something that needs responding to. It might be a user request, it might be a notification that a service level is not being met, it might be a failed IT component. The initiation comes from users, from event monitoring, from IT staff, from the payroll system... from multiple sources.
There are multiple categories of response. Each category has slightly different procedure for handling it. But we use the same overall process (create, match, categorise, prioritise, escalate, track, resolve, close...), the same policies, the same tools, the same metrics, to support the same services and serve the same customers.
Sure you would have a specialised Incident Resolution process (sub-process?), but that is as internal a process as Problem Resolution, not customer facing: it is about restoring the service. Sure you would have an Incident Manager, but they are answerable to a Response Manager and the primary discipline is Response Management. The job of the Service Desk is handling all responses to users. The two key SLTs for an SLA are availability (technology) and responsiveness (people/process). This silo-ing into incident, request and event is IT-centric and historical.
Made in New Zealand 
Comments
ITIL v3 2011
Was any of this addressed with ITIL v3 2011?
I think I'm sold on this idea of "Response Management" being the overarching process and beneath that you have "Action", "Support" and "Input"
I suppose then you would need a "Response" SLA (maybe all this entails is actual...response - like "We will call/email/contact you with an update within XX hours.")
Has anyone ever done anything close to this in 'real' life?
Standard practise
Yes, I have seen many companies doing this. In advanced state a Support Center has a multi-channel queue and SLA for all channels. They can tell you what was the average response time for phone, email etc. They can also tell what percentage of response times were under SLA target.
PS
I have been teaching this model in Finland with slightly different names (3P model):
Customer contact has three main types of content:
- Service = Action = customer wants something (Palvelu)
- Problem = Support = customer has a problem (Pulma)
- Feedback = Input = customer has an opinion (Palaute)
Aale
I heard of the 6P model
When I was younger, I was in the US Marine Corps - there they had a 6P model - Prior Planning Prevents P*** Poor Performance.
But more on point -
So, the Support Center has different "Incident" types based on if it is an Email or IM or whatever or it is all the same Incident just somewhere categorized as an Email/Phone interaction?
Does the 3P model break down further like Skep's?
No
You misunderstood me. I replied to you question about response management. The point is that there one, single queue for all channels, i.e. you do not have only a telephone queue but also an email queue.
And yes, the P's can be broken in subcategories.
Aale
ACD or Incident Mgmt tool?
Thanks.
We have different 'queues' for the work as well, as well as different SLA's for Emails/Call response. However, capturing if it is a call or email is not done in the Incident Mgmt tool but in the ACD system. So the queues are actually in the ACD system - all Incidents are generated/reported on the same way.
To be clear - you are capturing within the Incident/Request Mgmt technology how the customer contacted the provider (or Service Desk) and processing the Incident/Requests through a different queue based on that method of contact.
Or are you doing it more like we are - using an ACD system to capture the contact type - putting that in different queues (phone/email/im/whathaveyou) and from there processing Incidents/Requests normally?
Defining a Request vs an Incident
Agreed, Incidents (something is broken) should have a different response requirement than Requests (I want something I don't have). But I don't think folding all of it into Service Desk is always the right approach. Our company has a fairly small staff Service Desk, serving several thousand employees. Any time we can eliminate calls that are basically requests for new software and the like will improve the SD's ability to respond to actual issues.
I think that's ultimately one of the uses of Service Catalog; to automate standard, repeatable processes and reduce the load for the Service Desk. Fill out a form, get standardized status and notifications and send work assignments to the correct fulfillment groups automatically. Managers of the fulfillment groups should be tracking fulfillment of their requests, not the Incident Manager.
Best Regards,
BobGrins
the Service Desk still owns the management of them
I don't usually disagree with you Bob but this time I do. If the service desk staff is too small, pushing responsibility elsewhere isn't the answer. Not only does it provide a better servcie to centralise everything, it also introduces efficiencies. Sure automating user self-service is a good idea to reduce load, but the Service Desk still owns the management of them, especially when (not if) they go off the rails. They may not be the Incident Manager's responsibility but they sure are the Response Manager's :) or Request Manager or whatever you call a central person who owns all user cries for help...
ITIL Incident Management
I for some time have believed that Incident Management is not business aligned, nor appropriate. When I call the Service Desk it is always because I am having an issue performing a busines function such as getting access to the internet, or booking a flight in the travel system which is technology based or simply attempting to resolve yet another Blue Screen of Death (note to self, move to MAC). In all these cases it is a PROBLEM. Maybe I should get onto the Change Log and suggest that we completely rewrite Incident and Problem to Problem and Crisis......
As for COBIT - in the v4.0 rewrite we aligned with the perceived industry defacto standard which was ITIL. COBIT 5 will provide an opportunity to review the handling of Incidents, Problems, Change, Service Levels etc in the review process. All input welcome.
Robert E Stroud CGEIT
We need a bit of CRM...
I often hear that users and perhaps more importantly customers (sponsors of services) are dissatisfied with the way we expose them to internal process. Having implemented ITIL V2 on Remedy at Motorola following a strategic decision of everything should be kept vanilla as far as possible (ITIL process and products from BMC) this for me is the last (until the next one ;) nut to crack.
There is no doubt that adopting ITIL has brought huge (and measurable benefits - perhaps the details can be another post – if anyone is interested?). However, an unfortunate side effect of vanilla is that it does expose too much of the process unnecessarily. The user does not need to know that incident records once closed can’t be re-opened *, a problem ticket is different to an incident ticket etc. (*- don’t confuse with re-opening closed tickets with re-opening resolved tickets - an ITIL oxymoron but to be fair to BMC is easier for a user to understand )
It wouldn’t be difficult (BMC please take note) to add a layer on top of all this (good) ITIL stuff to pull it all together in a kind of layman’s overview. E.g. just have new record type called ‘Case’ and link in any of the internal ticket types (but don’t display all the meta-data like ticket type, number etc.)
Using Rob’s example of the nightmare PC order; this to a user can be in a ‘case’ they don’t need to know (or care to know) that we have had to raise x incident records, service requests, problem investigation etc.
A little bit of CRM on top of ITIL should do the trick.
ITILExpert on Twitter.
cry for help
I kinda agree. I don't think users mind being given a tracking number for their case.
And in my example the five calls about the laptop might be separated by months or years so the user doesn't expect them all to be treated as one case. But they DO expect them all to be treated the SAME WAY, and that's the point you and I are both making. The user doesn't need to know that one is a procurement request requiring financial approval ("I need a laptop" "I'm sorry you have to hang up and go get your boss to use the following form...") and one is an incident with potentially an underlying problem ("my laptop doesn't work"), and one is a security incident and probably all sorts of other incidents and requests ("I've lost my laptop"). It's OK to expose process if it involves them ("we'll ask your boss for approval for the laptop. Who should we ask?" - or better still "I see your boss is Bill Smith. is that correct?") but not all our internal process ("I can't handle this for you. it needs to go to security first and they are really busy this week because Sue had a baby and Cary is on leave and security won't give us admin rights to release the backup for you and ..."). And they don't want different SLAs ("Yes we fixed the broken laptop within a day because that is our SLA for incidents. But now you want help setting up Outlook and that is a request and the SLA for those is three days. We'll get back to you by Wednesday OK?"). To a user it is all just an issue, case, response, cry for help...
Yess
I agree with Rob. There is a flaw in the model. Service Desk should be able to handle all kinds of user issues as we have discussed before. In my experience, many seasoned Service Desk professionals have solved this matter by using a lot more classes than just incident and request.
This is also an area where V3 has stepped back from reality by redefining incident as a fault and separating request from incidents. An user screaming that the system does not work is not making a service request while it usually is a question of an user error.
I'm currently horrified to see that the ISO 20000 committee seems to be copying faulty V3 definitions to the new version of the standard. Please do not follow OGC & TSO blindly. It would be very silly if the new V3 edition would fix these errors and then ISO 20000 would repeat them.
Aale
A user perspective
It doesn't seem that long agao that the criticism was being made that ITIL DIDN'T distinguish between incidents and requests, with everything being treated as an incident. Indeed that still seems to be how a lot of service desks view the world which causes no end of problems when trying to analyse call and ticket volumes, which is one reason for making a distinction.
The second reason is about real world user perceptions. A lesson I learnt about five years ago, and I think others were learning it at about the same time, was that users are more forgiving of delays in fixing incidents than in the provisioning of standard requests such as adding a new user. There are two reasons for this. One is that they expect a slick process for dealing with highly predictable events, the other is that theperceptual impact of an unfufilled request often exceeds that of an incident, as anyone who has had new staff unable to work for their first week in the office can tell you.
Process wise though I agree they are essentially the same.
hyperspace
Actually ITIL v2 did clearly distinguish between incidents and everything-else. There is a delightful flowchart in Service Support, figure 5.3 on page 75. There is a decision box "request?". The "YES" branch goes to a box called "Service Request Procedure", which might as well be labelled "hyperspace", since it never gets mentioned ever again.
And yet it didn't. 5.2 has a garbled paragraph "A request for new or additional service..." that then tangles up RFCs, request and incidents until I'm not sure what it is referring to.
P.S. I agree about request processing: service we can restore in minutes or hours, but access to a secured folder takes weeks
Blue Book Figu 5.2
To Jim's point, Figure 5.2 shows the request as part of the Incident Lifecycle. Did I miss something or isn't/wasn't that part of the reason Jim suggests for the separation.
To the user it doesn't make much difference what we call it. Also it's the Service Desk that is customer-facing. Incident Management isn't (or shouldn't be).
Part of the problem is the too many people (and, therefore, organizations) make it about ITIL versus IT service management. While that isn't the point you specifically made, I believe that is implication -- and I agree with it!
David
I was so much better off using common sense...
For a moment you all confused me - more easily done as I get older. When I read ITIL V2 I punted on that diagram. Why - because we had always picked up the phone first and asked how we could help before opening up a 'ticket', or as many assume today - an incident - only to discover later it was not, then closing the incident and by doing so improving the overall turnaround stats (!).
No - we took a commonsensical approach and assumed every call was a 'request for service'. It was then classified perhaps as an incident, allowing us to easily produce reports on all the work we did for a customer or area of our business community. The pathway a request took through our organization was dependent in part on its type.... a multi-layer classification scheme.
We also recognized that what we heard of and reported was the very small tip of a very large iceberg, with so much more undiscovered, and that we needed specialized skills, which included CRM (as per earlier comment) and marketing intelligence, satisfaction surveys - you name it... to truly understand how happy our customers were, and the value we were providing.
So, an incident was just one type of request, I think I have now written to 13 or so...
Sometimes common sense trumps is a better practice, or is that 'best practice', or 'good practice'... ?? oh oh - I feel confusion coming on...