How does your service desk effectively manage large queues of work each with multiple activities?
Mark_Wahlert
Customer Advanced IT Monkey ✭✭✭
Firstly, we only use the Portal, only admins access SCSM.
We have a growing issue where it's becoming very time consuming and difficult to track the large number of service requests in the TEAM WORK. The key issue is we can't see the activities, so from the Service Desk perspective, they have hundreds of work items, all they see is IN PROGRESS, but what does that actually mean? Most are between an RA or MA, waiting on other teams to complete the activity, so the service desk are left spending too much time revisiting old SRs, one by one, to see what activity the work item is up to. They have now resorted to updating the SR title with phrases like *Pending Approval*, *URGENT* or putting items ON HOLD to differentiate items waiting on something . Far from ideal.
Another work around is a SQL report to provide the RO, SR ID, SR title, Activity Sequence, Activity ID, Activity title, SR last updated. But telling them to use yet another tool hasn't been received well.
I can't imagine we are the only ones experiencing this. I'm open to other ideas or procedures people are using to better manage the work items, as it's really starting to frustrate our service desk.
One idea that was raised as a feature is KA 158.
https://community.cireson.com/discussion/158/portal-tables-show-wis-and-activities-in-tree-view
Comments
Also servicedesk can assign the SRs and MAs to the appropriate groups so they don't show up in the service desk queue.
We don't use the RAs yet but we are planning on doing it and I was doing some testing and this would be our workflow: ticket will be assign atomically to a generic service desk user and will show the RA as unsigned since RAs don't have the concept of implementer. Once the SR gets approved will trigger the next MA (assigned in the template to the same generic user) in progress and it will show up in the generic user's queue under/next the parent SR. At this point the servicedesk will classify the SR and route it to the appropriate group.
IT Department
Support
Level 1
Level 2
In this example, employees/analysts exist as a part of Level 1 or Level 2 but "IT Department" and "Support" are empty. Then configuring a queue scope for said employees, would allow analysts of Level 1 and Level 2 the ability to view the parent work item (as it exists in Support or IT department) if they wanted to. Then, activities from that SR get assigned out to Level 1 and Level 2. The portal (and even My Active Work Items in the console) let you configure the view to say "Show me activities/show me only items that are active".
It's with this example configuration you're only engaging people on work, when they actually need to work and keeping their view/queue tidy instead of the hundreds of work items as you described.
Sorry for the delay, thanks for the responses.
@Adam_Dzyacky Can you elaborate more on your approach? I just want to better understand to see if it will be something we could try. We haven't tiered Support Groups yet, we have a lot and it's a nightmare to change using the up/down to tier and alphabetise. When you say assign L1 and 2 support group to activities, do you mean the email group mapped to each? i.e. Support-Level1@blah
We don't allow console use for users at the moment so it's a matter of tailoring what can be seen in the Portal. So it might be a training exercise for some.
Alright, so let's breakdown a New Hardware request that highlights what I'm getting at:
The Service Request Support Group Tiers would be to the effect of:
Information Systems - a group that contains/maps no users with the help of Cireson plugins
Support - a group that contains/maps no users with the help of Cireson plugins
Level 1 - a group that contains Level 1 analysts with the help of Cireson plugins
Level 2 - a group that contains Level 2 analysts with the help of Cireson plugins
Given the above, Level 1 sees Level 1 Work Items, Level 2 sees Level 2 Work Items, and so on and so on.
Queues/Permissions: Create Work Item Queues (Library -> Queues) that target things like:
- All Level 1 Incidents
- All Level 1 Manual Activities (you'll have to extend the MA class with an enum of "Support Group". Once you do so this queue type becomes possible and you can if you aren't already, leverage Cireson's Manual Activity group mapping for the console's My Active Work Items and the Portal's respective Team Work view)
- All Information Systems Service Requests
Then, when assigning permissions (Administration -> Security -> User Roles) create roles and attach groups of users and the aforementioned queues to those roles. What I'd like to draw attention to here is creating a Service Request Analyst role that your entire IT department is scoped to, then attaching the queue of "All Information Systems Service Requests" to. In doing so, you've enabled the department the ability to go get/read parent level items but prevented them from falling into a support group and thus cluttering their list of items. Now onto the final part - building a SR template for said "New Hardware" request.Service Request Support Group: Information Systems
Service Request Assigned To: no one/null/blank
activities therein:
It's with this type of configuration, analysts have read access to the parent SR, it doesn't fall in any particular group, and engages analysts when they actually need to do work. What's more, configuring the above means it will hold true for the console AND the portal.
With all of these things said, I want to caveat it all with the following: This is by no means some recognized best practice and comes with the shortcoming that select Service Requests have no assigned to user because the activities are what truly drive the request. Thus opening it's own series of reporting scenarios and/or possibly issues.
With respect to your "nightmare re-ordering groups" it's worth sharing this is actually incredibly simple to do editing the management pack XML directly. It may seem a bit intimidating at first, but it is actually really simple once you get what's going on with parent/child enums in said XML. There are several blogs out there that discuss re-ordering SCSM enum lists that I think are worth your time to check out.
Also forgot your question about "assigning" - you could email those groups. Because with Cireson's Notify Analyst you could setup email notification about activities when they are created, reassigned, updated to a Support Group.