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 - Ticket ownership with join effort for incident resolution
Posted: Sat Dec 15, 2012 1:21 am Post subject: Ticket ownership with join effort for incident resolution
Question:
Suppose a major incident was raised and can only be resolved by changing the setting of the application (backup + front end) with join effort between different support teams. Incident resolved but the SLA already breaches, who should own the ticket and why?
Much appreciate if anyone can advise on this. Thank you
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Sat Dec 15, 2012 3:28 am Post subject:
It's irrelevant.
The "blame" for SLA breaches only devolves to a person or a team when they have been at fault. Whether they "owned" the ticket or not. If the incident was resolved as expeditiously as possible, no one gets any blame anyway unless it was because the SLA was unrealistic.
But it is even more irrelevant when you consider the absurdity of a single incident being the subject of an SLA. To be useful, SLAs have to be about averages over time periods. It's not IT that suffers from the single incident based SLA, it's the business because IT are bound to up the figure from the average when they agree it, for obvious reasons. _________________ "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
The "blame" for SLA breaches only devolves to a person or a team when they have been at fault. Whether they "owned" the ticket or not. If the incident was resolved as expeditiously as possible, no one gets any blame anyway unless it was because the SLA was unrealistic.
But it is even more irrelevant when you consider the absurdity of a single incident being the subject of an SLA. To be useful, SLAs have to be about averages over time periods. It's not IT that suffers from the single incident based SLA, it's the business because IT are bound to up the figure from the average when they agree it, for obvious reasons.
Hi Diarmid,
Many thanks for your input on this, well no one actually getting blame for breaching SLA as there are bound to be complicated cases which require more time to fix. However, it will definitely impact the team's overall KPI for incident resolution on time and there is always an unavoidable debate between the teams who suppose to take the "shxxt". Its like team A and team B resolve the issue together but they are reluctant to own the ticket being the reason "why should my team own it?and not them?" kinda thing.
Joined: Sep 16, 2006 Posts: 3493 Location: London, UK
Posted: Sat Dec 15, 2012 8:25 pm Post subject:
The Service Desk owns all tickets - regardless of who is assigned the ticket to resolve - as it is their function
As for this one, if it was classified as a Major Incident and you have a Major Incident policy description as per the guidance of ITIL, then the owner of the Major Incident would be the combination of the Service Manager / Incident Manager and the Problem Manager as it is a Major Incident _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Sat Dec 15, 2012 10:27 pm Post subject:
I deliberately did not say anyone was being blamed or should be blamed. That's what the quote marks were for.
But you have repeated your implication about blame being the real concern. Just changing the word.
There should never be a sweat over a single incident overrunning the SLA except if it is badly handled.
If a major incident does not overrun the SLA then either you have a very long time to solve incidents or you did not have time to set up the major incident team before resolution.
John is totally correct about ownership.
If your teams have a KPI on incident resolution then the cost goes to each team involved, I would suggest. _________________ "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
The Service Desk owns all tickets - regardless of who is assigned the ticket to resolve - as it is their function
As for this one, if it was classified as a Major Incident and you have a Major Incident policy description as per the guidance of ITIL, then the owner of the Major Incident would be the combination of the Service Manager / Incident Manager and the Problem Manager as it is a Major Incident
yeah agreed the relevent SM Team would need to own and drive through the entire process but the issue here is that ticket need to be "parked" under somewhere within the resolver groups and whichever team takes the ticket, their KPI will be affected.
I deliberately did not say anyone was being blamed or should be blamed. That's what the quote marks were for.
But you have repeated your implication about blame being the real concern. Just changing the word.
There should never be a sweat over a single incident overrunning the SLA except if it is badly handled.
If a major incident does not overrun the SLA then either you have a very long time to solve incidents or you did not have time to set up the major incident team before resolution.
John is totally correct about ownership.
If your teams have a KPI on incident resolution then the cost goes to each team involved, I would suggest.
Initially they are not very concern on the ticket ownership as the ticket volume was sustantially high and a few tickets breaching SLA in their queue would not hurt much on their KPI but as the environment is stabilizing now and ticket is getting lesser by day, things like this start to happen.
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Mon Dec 17, 2012 7:37 pm Post subject:
Your system is encouraging a silo mentality. Change your system. _________________ "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
Joined: Sep 16, 2006 Posts: 3493 Location: London, UK
Posted: Mon Dec 17, 2012 8:02 pm Post subject:
I have to agree with Diarmid
Your setup for the resolution teams is completely wrong.
First, for the major incident, it does not matter to which team is assigned. Assign it to one of them and follow an Major Incident process. This porcess ensures that the Service Desk Mgmt manages the ticket.
Second, SLAs are against the entire service provider - not each individual resolution team
Third - it appears your teams are more concerned with the daily/monthly KPIs list than DOING THEIR EFFING JOB.
Finally, if this setup was designed by a consultant, you need to file breach of contract as this is the most asinine way to run a Service Procider _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Yeah, we are moving to a new system next year but for the time being we just need to stick with the current system. One thing for sure is that the team is working together to restore the service ASAP to ensure our main SLA does not screw up and our customer is happy. But when down to individual/team level, the ownership of ticket is always a concern as "Good KPI = Good Bonus". I reckon no OLA defined is the main culprit when the system was intially setup years ago.
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
