How to log Effort / ticket for mass updates

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
Sreeni2020
Newbie
Newbie
Posts: 3
Joined: Fri May 13, 2016 8:00 pm

Sat May 14, 2016 7:03 am

Greetings to all ITIL SD folks.

I often get security reports which says, there 40 to 50 machines missing the security patch. SCCM couldn't patch these machines due to numerous reasons. Action on our SD team is to manually patch those machines.

My question is how to track the effort? It is useless to create 40 incident or request tickets because, common sense says, just create one ticket and detail about the task and provide the number of PCs to be worked and close the ticket after all the PCs are fixed.

When we produce the monthly report, we see this as only one ticket. So, the IT effort is tracked as one ticket rather 40 tasks. What is the best way to log the ticket and report such a huge efforts.

Thanks in advance.


User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3634
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Sat May 14, 2016 9:59 am

However you want... it is to your customers. Therefore as the service provider

However, is the reporting accurate ?

Also why do you think it is useless to report 40 deployment failures ?

Do you report the % or number of systems patched and not patched ?

That is the key I would think
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Sreeni2020
Newbie
Newbie
Posts: 3
Joined: Fri May 13, 2016 8:00 pm

Sat May 14, 2016 7:51 pm

Reports are not accurate. Because, 40 efforts is shown as one ticket.

I think logging 40 tickets on users (every month) is not appropriate because, they didn't request for this nor report this as an incident. We have seen resistance from user in getting ticket info on his system, ticket closure info, and feedback. It is lot of admin work at service desk to keep creating, updating and closing 40 tickets (some time 90+) with a same inform and same solution.

We report both. % is required to show how many vs total and absolute number for discussion.

Still the question is open. This is a monthly affair. One option is I can show this as a bulk task or mini project every month. But, what is correct from ITIL way?
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3634
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Thu Jun 02, 2016 4:03 pm

Sreeni,

ITIL does not define how YOU should manage your own IT structure. It provides guidance ONLY on how to do certain things in a certain way

Incident mgmt separate from problem

etc

If you have any CMDB like structure, 1 ticket with links to the 40 would suffice as it would allow reporting from Incidents - 1 and from devices 40 each month
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Sreeni2020
Newbie
Newbie
Posts: 3
Joined: Fri May 13, 2016 8:00 pm

Sat Jun 04, 2016 8:21 am

Thank you UKVIKING.

we are using snow. I am using an approach of parent and child for this. This make it easy to report as 1 incident, child incidents show machine which are impacted.

Thank you for your advise.
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3634
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Sat Jun 04, 2016 9:02 am

If it works, then issue solved
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
paul0738
Itiler
Itiler
Posts: 6
Joined: Thu Jul 14, 2016 8:00 pm

Fri Jul 15, 2016 11:25 am

Hi Sreeni,

Your approach to use parent and child tickets is the ideal one, especially if you have a tier one support desk to perform triage.

Failing that you should define issues by severity p1, p2,p3 for example. You can decide upon the scope, extent, and impact to apply to each level. In your reports you can then list the number of high severity issues you resolved which gives some indication of effort, management tend to care more for high visibility issues anyway.

If you truly need to record hours spent per issue, then I don't think incident data is ideal for this, you should instead track the workload of each engineer by the use of time sheets, or tools like Salesforce.
Post Reply