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
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 - why should Incident Ownership remains with the Service Desk
Posted: Thu Oct 01, 2009 3:11 pm Post subject: why should Incident Ownership remains with the Service Desk
Correct me if I am wrong a service desk is a level 1 team who logs in incident and try to diagnose it, they assigned to level 2 to troubleshoot further if they are not able to resolve or provide quick fix
Now the ticket is not with the level 1 team, it’s with L2/L3 team...shouldn’t they be responsible, accountable for the incident rather than L1
what if the incident cross the SLA is there any time limit to out of SLA incident, how to handle 1000 of incidents of this kind
These backlogs of tickets is not because of service desk (L1), it is coz of L2/L3 or may be no solution found to these kind of individual incident…if so should Incident Ownership remains with the Service Desk or should it be owned by the team who has the incident
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Thu Oct 01, 2009 7:20 pm Post subject:
Json wrote:
But do they really have to manage things which is out of their control and understanding
I think you have a misapprehension as to what they manage and what ownership entails.
Managing the incident does not require understanding any of the technical complexities involved in its solution. It does require knowing that the correct technical specialists are assigned to it; ensuring that they give it the correct priority among their tasks; extracting progress information from them both to pass on to the users/customer and to have confidence that the resolution will be timely; ensuring that the incident is properly documented at all stages; determining whether it relates to other incidents; determining whether there is an underlying problem to be addressed; ensuring that closure is properly achieved; liaise with users/customer over urgency, contingency and other issues; spot when escalation is required; and other stuff.
To make sure all this happens someone has got to keep their eye on the ball (that is ownership). The techies with their heads in the sand (sorry, silicon) are neither well placed nor (normally) well designed for this task. Also, it is always risky to keep passing the baton during an incident. Far better if someone manages the call from the interface (Service Desk) because they can then speak authoritatively to users/customer. In effect that person will delegate both the doing and managing of technical tasks, but will retain overall responsibility for the incident. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Think of the Service Desk as a router. It gets the information from the internet and passes the information to the machines hidden behind it.
As others mentioned they are the first point of contact and such as a router it will learn the path. So when getting requests that needs to be escalated to a higher level support they would know who exactly to assign it to. If they are not sure they can refer back to the line manager and this process shouldn't take long as you are expecting, it is done in minutes.
As far as issues being resolved at the first line, 1st line only deal with easy requests that come in on daily bases. They shouldn't be rocket scientist. example on those requests would be: password reset, Software installation, Creating new accounts etc. Service Desk staff should be trained for such requests or they can check their knowledge base/Training document or what I call the Monkey See Monkey do document, for more information if god perhaps they forgot the process to fix such requests.
Joined: Sep 16, 2006 Posts: 3292 Location: London, UK
Posted: Thu Oct 01, 2009 10:40 pm Post subject:
Json
If you looked at the ITIL books - v2 or V3 - or taken training, you would have had the answers
The service desk is like the control centre or command centre . It watches, manages and tasks out things to people
Even if the ticket is to be resolved by some senior wonk in Microsoft, it is STILL Incident mgmt and it STILL needs to be managed/monitored by the SD.
In addition, this arrangement protects the techies from the user - by having the SD act in the middle _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Speaking of Microsoft Support I was very impressed that they spend hours waiting with you on the phone until they get your incident resolved from the first time 3.5hours in my scenario that's a lot of patience. Though that doesn't mean that vista is not Sh*ty
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Sat Oct 03, 2009 1:51 am Post subject:
Hi json,
Looking through the conversation, I just wonder if I see it correct or not, and thus could help make it clearer so here it goes.
As usual, I will give an illustration.
First,
Somebody goes to the police office to report burglary. He goes to the front office, meet the officer and report the case.
Later he will be informed by the officer that "from now on his case will be handled by Sgt. X". From that time the one he will be dealing with is Sgt. X.
In this case, the report AND that somebody are escalated to Sgt. X by the front officer.
Second,
A woman goes to a hospital to check her condition. First, she will look for a general physician. After checkup, the physician came to a conclusion that her condition must be handled by an internist. She will then be informed that form now on you will be handled by Dr. Y". From that time she will deal with Dr. Y and not with the general physician anymore.
She and her disease are said to be escalated by the physician.
Both illustration are not the case with ITSM, especially ITIL. The Service Desk functions as the Single Point of Contact. This would interpret as "I don't care who's fixing the problem, the only one I want clarification and solution is the one I contacted first".
So, besides receiving and logging incident reports, the SD is responsible of tracking the incident resolution UNTIL service is restored and even more, confirming with the user that it is restored.
Thanks guys, I get the picture ....one question though how should a incident with no solution be handled .....no solution in the sense not yet found and no workaround.....let say incident is very old ...no urgency from user...can business say to its user that after x days a case can be closed..?
Json, only if the user agrees. In this case, the workaround is that your user has to work around it.
That said, if you choose to close incidents without consent, be sure it's in the SLA. Maybe you say that incidents will be closed after n documented attempts to confirm satisfaction with no responses. Watch out for that one unconfirmed-but-closed incident that creates an upset customer (and I mean Customer not just user). _________________ Ruth Mason
USA
Posted: Mon Oct 19, 2009 1:48 am Post subject: why should Incident Ownership remains with the Service Desk
Json,
Incident ownership should remain with the service desk as normally the service desk is fat and in a position to seek answers for the end users. This is what appears from outside. Internally, the complete ownership lies with the support team working on the incident and the service desk is empowered to seek updates as and when required. The service desk has a bunch of people who can answer queries and if they don't have the end to end ownership the end users will start calling the vital few support staff making their lives difficult and taking the recording and tracking mechanism to a toss. Regarding your question of no solutions around, the incident management ( read Service desk) should get hold of the person who commissioned the application or the service. We can very well say to one user that there is an alternate but what happens if the said application or service has multitude of users. The guy who commissioned the service should brought into picture and should do RCA and if required raise a change order. If the application is not used by many and the owner is missing, the CAB should have the authority to decommission it after the consent of the business. The CAB must be informed about such instances by the IM.
simply put, all incidents should go through service desk who is the owner of the incident even though a 1 min resolved incident since service desk is the 'interface' between end user and service provider.
for those incident without solution or workaround, what we are doing is that we open a problem ticket and assign it to relevant technicians to deal with, how long time will be spent on such problem is based on the SLA pre-defined. Frankly speaking, we never defined such SLA with customers so lack of experience to talk about it in depth.
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Tue Oct 20, 2009 12:58 am Post subject:
davidlet wrote:
for those incident without solution or workaround, what we are doing is that we open a problem ticket and assign it to relevant technicians to deal with, how long time will be spent on such problem is based on the SLA pre-defined. Frankly speaking, we never defined such SLA with customers so lack of experience to talk about it in depth.
There are several threads that discuss this, but an incident does not become a problem under any circumstances and problem resolution is best kept outside the scope of SLAs because it is too difficult to predict how much time and resource is involved and because Problem Management is only indirectly related to Service Delivery, being more to do with the long-term health of the services. Are you using problem tickets as an interface to second or third line for incident resolution? If so, do you have a separate kind of ticket for invoking Problem Management.
If you meant how much time is applied to resolving incidents, then it is better if that is the time it takes to resolve them rather than some SLA figure which should only be about priorities and averages and general commitments about down-time. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
