When will ITIL wake up that Service Desk is about Requests not Incidents?
Call, contact, request, incident, issue, task, ticket, job - they are all the same thing really. The latest one I heard was the "case". They are all requests of one form or another. The incident is just a request that it be fixed. What is it about ITIL and its fixation with the Incident? We have seen the evolution of the humble request from an after thought to an equal (roughly) peer with the Incident in ITIL3. My recent ITSM Watch article suggests there is further change to go before ITIL reflects reality.
How many organisations require users to contact
- payroll for a pay error,
- HR for a leave request,
- building services for a blown lightbulb,
- security for a swipe card,
- IT for a deleted file,
- project office for a new application
- admin for more staples,
- reception to get their drycleaning,
- the operator to get a phone number
- the security company to come empty the secure destruction bin
- materials for more toner,
- the vendor for the broken coffee machine,
- and their manager for a new desk?
Depending on our perspective and business requirements, the Service Desk should in general be the first point of contact and the central clearing house for communciations with users.
If we centralise all transactional interaction with the user we can manage transactions from end to end, see and optimise process, make better use of infrastructure, eliminate duplication, build a profile of the users and the services, improve reporting, optimise user interaction, and focus expertise.
The Service Desk are - or can be - the centre of excellence for
- details capture,
- tracking,
- workflow and coordination,
- communciations,
- followup,
- closure,
- dealing with upset and difficult people,
- policy enforcement
- ...and record keeping
Incidents are such a small part of what a Service Desk can and should be doing. ITIL reflects its real inward-loooking and geeky bias by giving the incident such disproportionate emphasis.
True service orientation would look at a much bigger picture.
Made in New Zealand 
Comments
Don't stop there...
G'day Skeptic et al,
Let's not stop at your redefinition of the Service Desk scope of responsibilities. Why not have just a single Service Desk that handles all the requests from every user within every organisation throughout the whole country - no! no! - wait a minute - make that the whole World! This would simplify request processing for everyone - except the Service Desk.
I have heard the phrase "dumbing down the Service Desk" used when consolidating multiple helpdesks - but when looking at extending the service desk request processing for all possible requests from all users - then we would be "dumbing down the Users". Users need to be responsible for making some decisions in the process - such as which department/ service desk/ helpdesk/ support team should I contact for certain types/ classifications of requests.
Although I can see some advantage in the same process for requests being followed - even using the same workflow management tool and repository - but each type/classification of request may need it's own work instructions/ procedures to be followed. You could still measure the efficiency and effectiveness of the process across the whole organisation for all requests - but will they need to be consolidated - does the handling of a payroll request need to be compared and consolidated with those from HR, building services, security, etc.?
Then we have the "who watches the watcher" conundrum - who do the Service Desk call for their requests?
I'm sorry - but I am not sold on the concept of a single Service Desk to handle all types/ classifications of request from across the organisation or wider group of users.
Regards,
Darryl
Why should users have to
Why should users have to work out which of a dozen numbers to call? What levels of user frustration are there when being fobbed off to another number?
Handling a wider variety of calls makes the job more interesting for staff and helps reduce churn: they can have a new challenge once they master one topic. Have specialists among the team who deal with subsets such as user access provisioning ("security") or travel. Have the ability to pass calls to specialist service desks where necessary (say, payroll). Have decent knowledgebase tools to prompt people through call resolution. There are many ways to make it work.
let's take Darryl's ad absurdum arguement in the other direction shall we? Why do we have a service desk? Wouldn't it be much more efficient to just publish level 3 phone numbers? Users should be able to work out what is wrong and call the appropriate person. if they can analyse the issue enough to choose between ten numbers, they can try a bit harder and choose between a hundred. let's do away with service desk altogether - all we need is smarter users.
Junk the 'desk' part
I like the idea of junking the 'desk' part. As an avid customer I just want help with my issue or a timely response to my request. I don't care how many levels or who actually responds as long as someone does. The word 'desk' can imply a physical location and perhaps even some bureaucracy :-)
Lets get back to the crux - supporting a service by providing a support service!
Lets also remember that when designing your support you have a discussion with the customer way upstream during the requirements management stage of the service lifecycle. HDI has it right - Service Support Management is the topic, not Service Desk, which is but one nickname for a supposed style. It is much more sophisticated than that.
Also, don't forget - service access points (SAP Source:SMBOK) are critical. SAPs are places from which a service may be legitimately accessed. Knowing what SAPs are authorized, their characteristics, technology, continuity, security, and geographic location - are CRITICAL to designing support.
Differing levels and styles of support should be part of the service description in the service catalog. Operational capabilities are part of the 'service model', or how we are planning to deliver service in general to a part of our customer community.
So lets junk how we do it for a moment and start helping folks understand what we need to do to support a service beyond reactive break-fix...
we'll have to call it X-
But Ian, if you want to call it X-Desk and then you want to drop the Desk bit, we'll have to call it X-
Tangles in my own web of acronyms and concepts!
Skep - at least someone is reading my prose....my thread management system failed again :-) Agreed - so its X- from now on in.... the next version will be XX-, the IT version will be XX-IT and sooner or later I suppose we shall get to XXXX-IT
Don't dis the Service Desk
I agree with Darryl,
Although the same approach, processes, tools etc. can be used for handling requests on a number of service desks across an organisation, it does not work to try and amalgamate all desks into 1 super-desk. I have seen this attempted, and abandoned in a government department in the uk. Just some of the reasons against:
Staff turnover - it reduces the staff to call centre agents, half of whose time is taken up owning an incident about a blocked toilet on the 3rd floor. Great that someone owns it, but the staff who want to progress to a career in IT will leave - This started to happen within days in the example I saw.
Level of expertise - callers and staff will get frustrated that the desk does not have the expertise to follow the Known Error information - if they can understand the "how to unblock the loo KE", they are unlikely to understand the "how to rescue a file from the recycle bin" one!
If all staff are doing is reading out something they do not understand, why not just have the information available to the user ("How to use a plunger poster" on the wall)
As a result f the lack of expertise, in any of the areas, staff will struggle to appreciate the impact and urgency, so as to prioritise work. Their Assignment matrix will be like a Yellow Pages directory!
I have seen the tools and processes of a Service Desk successfully adopted by an HR enquiry desk, but to dumb down the Service Desk as a request-handling machine is pointless and demeans the staff and their skill levels. We would not suggest that our 2nd line techie carries a plunger, lightbulbs and passkeys with him so he can handle a wider range of requests? The Service Desk is an important part of the IT service - don't reduce it to a call reception function
Liz Gallacher
Freelance Trainer and Consultant
The Service Desk is a designed response
The service desk is a style of support operation. Thats why we refer to it as a X-Desk or Service Support Management in the SMBOK. Its one or more folks at one or more locations of choice, answering requests for support. Support is not limited to break fix and encompasses ANYTHING deemed within the service agreement as support worthy. Support is designed, scoped, and cost justified. Support ranges across the organization with the Service Desk facing both end customers in the business realm, other Service Desks (yes they can be networked or implemented at the elemental level), and the IT organization, oh and suppliers!.
Service desk and 'help desk' operations again are just labels put on the style of response, one hugs a customer and may ring out first to ask if there are problems or needs, the other waits for incoming. A service desk approach may be used for one customer while a help desk for another, all serviced from the same team.... So I hope I did not say anything that implied a super uber desk.... thats an option, but again - designed.....
Nice toilet analogy, I have my plunger in a convenient location. Service requests do not imply dumbed down activities. Requests can include functional 'how do I do this' items, these are not service level issues. Each request may have its own lifecycle and path through the organization. Healthcare uses requests and 'service pathways' to control costs, handle more requests, and nowhere is their a need for the person greeting you at the front (information) desk to solve your problem (analogous to pushing all knowledge to 'level 1). No, instead your 'request' and the needs it contains are understood, recorded, classified, and a pathway determined - an efficient one.
Seems like the both of you have been reading far too much ITIL...? But are lucky enough to have actually experienced the real world.
An incident is a type of service request
Skep
Well put and long overdue that ITIL gets with the program. I was one many who were hopeful that ITIL V3 would get it right and give service request management the full respect it deserves. Instead, 'Request fulfillment' gets just over one stunted and stale page. As your article illustrates, the majority of operational workload and cost is as a result of the (humble) service request.
Our practical work has indicated that as much as 85% of the traffic hitting a 'service desk' operation is not related to a break-fix (incident) situation. The % factor between incident and service request for any service is proportional to the amount of 'customer hugging' designed into the service offering. As improvements are applied one might also expect the overall ratio between incidents and service requests to change and for requests to become the dominant items, as quality improves.
The most effective approach taken in practice is to reposition an incident as a type (classification)_ of service request. Reports flow smoother, improvement programs deliver faster.
None of this is discussed in V3, neither in strategy, design, operations, or improvement. A recent opinion paper published at SM-I discusses all this. Unfortunately I think it might only be available to members.
Let me know if you need more help in stirring up interest in this extremely significant topic and I'll see if I can get it released for wider consumption. In the meantime folks can email me... ian@sm-i.org