Capturing ITSM Activity with Jira Service Desk
Jira Service Desk has become one of Atlassian's fastest growing products, and for good reason. It is built on the battle tested base of Jira, so we know it operates at scale. It provides enough structure to get up and running quickly with ITSM best practices, but is infinitely flexible to allow adapting to each organization's unique culture and processes. It enables the rapid delivery of service that is critical in an agile world.
And of course, it integrates well into the Atlassian stack, allowing organizations to track activity from customer input to development and release.
Perhaps its greatest strength is its flexibility and how it drives both standardization and agility in workflows.
Atlassian's own description highlights exactly this point.
"Jira Service Desk is a flexible, collaborative ITSM solution built for rapid service delivery."" - Atlassian
Jira Service Desk is flexible and collaborative, designed for rapid delivery of services.
Jira Service Desk Across Key Areas of ITSM
Jira Service Desk is a class leading tool for agile IT service management, providing visibility into the work required across the IT organization. Jira Service Desk's flexibility makes it a perfect fit for the challenges of dealing with the variety of issues that arise. From a service outage, to onboarding employees, to ever present security threats and the patches that come along with it.
JSD is optimized at delivering service in the 4 key areas of IT service management defined by the ITIL 4 best practices.
- Incident Management
- Problem Management
- Change Management
- Asset Management
Capturing activity in JSD makes it visible, but organizations who wish to stay competitive need to be able to also understand what they see and why something happened so they can evolve, adapt, and deliver value to their customers faster and more efficiently.
This is where good reporting becomes critical to success. ITIL 4 calls out monitoring and reporting as a key management practice. Reporting is the glue between the front line with service reps and admins who deal with an unplanned outages, planned firmware updates, or data migrations, and the decision makers that need to keep things running on time and budget.
The Challenge of Enterprise-Wide Adoption
Jira Service Desk's flexibility also makes it a great solution for boundary teams such as human resources, finance, and facilities, which further expands the amount of data captured and increases the challenge of reporting on it.
With the help of JSD, the data is already being captured in one place, the reporting on the data needs to have a similar holistic approach. Decision makers need to know not just what is happening, but also why it is happening.
Metric Reporting is Not Enough
Jira Service Desk includes some built-in reports that provide basic performance metrics to get started with. They follow a simple, but clear pattern of a line chart that shows a specific metric's history over time and a current status.
For example, this built-in reporting makes it easy to see how many tickets were resolved per interval. The same pattern is used for all of JSD's built-in reports such as:
- SLA success rate
- Incidents by priority
- SLA breached & goals
- Time to resolution
You can show a count for just about any field in Jira Service Desk. This is a good basic foundation for reporting.
But, with all these reports following the same pattern, answers can get lost in the noise, and none of these reports answer the question of why. There is so much context missing from the metrics, it is very difficult to make an informed decision. Are we missing our SLA success rate because of staffing, systems outage, unplanned work?
Because of these limitations, most teams resort to using Excel for reporting. They manually export the data as CSV and spend hours getting the data to look right for distribution. By the time the report is ready, the data could be out of date. These manual Excel reports also do not scale well, resulting in hundreds of copies residing all over the intranets and wikis.
On top of all that, these Excel reports still do not answer the question why and we are left with only part of the story. When we don't know why something happened, we are at risk of making an uninformed decision.
In-context reporting within Jira Service Desk is critical for making data-driven decisions, especially during something like a system outage. There is no time to manually create an Excel report. To be a high performing service organization, you have to go beyond performance metrics to get the complete story, combining metrics and context, and delivering it to the right people so they can make data-driven decisions.
Telling a Story with Reporting
In today's world, we need to go beyond single teams and single metrics so we can make better decisions. We need to tell the entire story and think holistically.
We need to tie ITSM workflows for Incident Management, Problem Management, Asset Management, and Change Management to reporting dashboards that answer the what and why for decision makers within and across teams.
A real-world example situation might look like this:
The built-in Service Desk report would say that resolving the problem from start to finish took 4 hours, which did not meet the SLA policy in place.
With this report, we know what happened. Now the process of figuring out why it happened begins. Was there a stall in the process? Was it in development? Performance metrics in JSD and Excel do not answer these questions.
How do we tell the story of why it took 4 hours to resolve the problem? The only way we can really understand what is going on is by telling the whole story with ALL of the data.
How Do We Tell the Whole Story?
To tell the whole story, we have to start by acknowledging that we will need different data. Because of how Jira Service Desk captures and stores activity, the good news is the data we need is all there. We just need to extract it and present it. Let's go back to our example situation and add some context:
- The incidents that are coming in are all bucketed to the same system.
- This helps us identify that there is a problem with the internal network.
- This can lead us to question why people are not using our portal for mosts requests?
- This problem has a high impact and a high urgency.
- Then we might ask ourselves how often do we have problems with high impact and high urgency that relate to this system?
- The change risk is high, and the reason is a repair.
Now we know not just that it took 4 hours to approve the change request but also that it was a high impact, risky change that required additional testing and approval. We now know why the SLA was not met. We know the complete story because of context around the metrics.
Data Helps Identify Deeper Questions
As you can see from this example that there are many different data points that ALL work together to tell a complete story. Together, these data point can help identify critical questions like:
- Is this the average length of time for this type of change/problem?
- Does our SLA not account for this situation?
- Do we budget to upgrade our internal network equipment next year?
- Do we need to make our portal more available to our customers so that it is used more often?
- Do we need to train our staff to keep firmware up to date? Do we need to revisit our change management process?
Contextual data is enabling us to ask informed questions on our journey to better data- driven decisions.
Different Data from Different Teams
Modern business has become increasingly cross-functional, especially as Agile methods have invaded many departments starting with IT. These Agile methods are breaking teams and work-to-be-done into smaller blocks and allowing work to happen in parallel. This means data often comes from different teams.
Let's revisit our example and look at the teams involved:
We must think holistically about where our data comes from and with whom it is shared, and our approach must be agile in nature so we can move fast and across teams. By combining data from all teams involved, including boundary teams, we give ourselves the right data for in-context reporting.
Different Representations of Data
With additional data from all teams involved, we can now consider the best representations of the data. The way data is presented provides another perspective that can help drive decisions and make the data consumable to the widest audience.
The flexibility to visualize data in different ways can help answer critical questions.
For example, a bar chart can help us see all the incidents that are high priority within our internal network system.