Hi guys,
We use JIRA Cloud for managing our dev work, but we're now trying to migrate our Service Desk from Citrix over to JIRA Service Desk. One of our main requirements is decent reporting so we can utilise ITIL for continual service improvement, but we're struggling to find a way to do it in the Service Desk!
We'd like to have at least a couple of "depths" in reporting that mean we can get an overview of each service, but also have the ability to dive a little deeper into what exactly is happening within each service. For example, the Head of Dept. wants an overview of the services: 365 Apps, IMS Apps, Office Network etc. He wants to know which of those are requiring the most support. If the answer is "365 Apps", the next logical question is which apps are causing the most hassle and why? So we'd then want to drill down into the 365 Apps and see a report that shows whether Webmail, Yammer or Skype are the cause of most of the work.
The best way of doing this would probably be to have a component list with sub-components. For example:
The problem is that JIRA Service Desk doesn't seem to have a built in way to do subcomponents. There are a couple of plugins on the marketplace, but the one we implemented to give us this functionality happened to break just as we were migrating and now we're a bit nervous of relying on a plugin that's been broken for the last two weeks.
It begs the question, how is everyone else managing this problem? How do you guys structure your list of Components in the Service Desk? Are you able to achieve multiple depths in reporting or do you make do with an overview of your Services?
Any input from your experience and the way you do things would be appreciated.
Hi Brent -
The only ways I know of to support multiple levels of components are:
1) one of the third-party plugins as you mentioned;
2) adding a Cascading Select custom field; or
3) simulating sub-components with a naming convention like "Deals - Create Deal", "Deals - Edit Deal" etc.
I suppose you could also try #4 - use Component for the parent and a simple select list for the child and rely on users to pick appropriate values.
I haven't tried #1. If you liked the plugin you had maybe try contacting their support and seeing if they seem like a reliable vendor.
For reference, here is the last comment from Atlassian stating that they aren't adding native subcomponents.
Thanks John, we hadn't considered #2, so I'm going to give that a test and see if it meets our reporting requirements. It sounds like a faff to setup, but once it's working it sounds like it'll be the best option.