This is the first in a series of blogs that aim to make your incidents smoother, quicker and efficient and your customers more satisfied. We’ll bring you tips and best practice based upon real-world engagement with many users of both JIRA Software and JIRA Service Desk. Whilst you can implement some tips on their own, the greatest value is when you implement them all or in combination.
Tracking what needs to be tracked
Incident Management with JIRA enables the tracking of incidents from reporting to resolution. A standard implementation will support most incidents in most organisations. However, there are good reasons to look at customisation too.
This blog looks at the types of Issue that we can track in JIRA. We will also look at how enhancing, integrating and streamlining JIRA makes it more powerful, embedded and valuable. It can deliver greater visibility on the process of handling incidents.
First, decide what you need to track
The following table provides the information you need to implement this in JIRA. Users of JIRA Service Desk will already have some of these Issue types but JIRA Software and JIRA Core users can create the same Issue Types.
Problem and Incident Icons are provided as part of the installation of JIRA Service Desk. We have used additional icons from www.flaticon.com which is a good source of icons for reuse in JIRA at a low cost.
- Alert Icon made by “freepik” from www.flaticon.com
- Remedial Action Icon made by “madebyoliver” from www.flaticon.com
Treat Incidents and Alerts separately
By splitting the Incidents and Alerts we can track these with different workflows and timelines for resolution. You may consider an automated Alert to be of higher or lower importance than an Incident reported by an end-user.
What about correcting things that have gone wrong?
Similarly, with the implementation of a Remedial Action you can track the resolution of the Problem without needing to also fix any corrupted data or changes to processes.
Creating an Issue Type Scheme
Once we have created the Issue Types the next step is to group these in an Issue Type Scheme that can then be applied to our project. This allows our new set of Issuetypes to be applied to a project.
Having created our Issue Types for tracking the different types of activity we should consider the way in which these link together. By providing a set of links we can clearly describe the relationship between each pair of Issue Types.
|Name||Outward Description||Inward Description|
|Alerts Link||Alert for Problem||Problem for Alert|
|Incident Link||Incident of Problem||Problem for Incident|
|Remedial Action Link||Remedial Action of||Remedial Action for|
With the definitions above we can quickly understand the relationships between known problems and the Incidents/Alerts that were caused by the Problem and the Remedial Actions required to address the Problem.
In the next blog we look at how having these Issue Types helps us triage new incidents or alerts more effectively.