ITSM Reporting For Informed Decision Making

Created by Joshua Platt

  • Jira Service Desk (JSD) is very flexible and can be used to capture requests and tickets across an organization
  • Built-in JSD reporting is not as flexible as the rest of the platform and it only provides basic reports
  • Users often develop a practice of exporting data and using Excel for reporting
  • Excel is difficult to govern, often out of date, and susceptible to human error
  • Traditional metrics only provide part of the story, they provide the what, but not the why
  • Effective data-driven decision making requires in-context reports that answer why
  • A single reporting platform that spans charts, in-context reports, and light business intelligence allows standardizing information and reporting across the organization

Read the white paper below or download as a pdfPDF icon

VisualScript ITSM white paper

Capturing ITSM Activity with Jira Service Desk

ITSM activity

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.

IT management

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:

ITS steps

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:

Team data

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.

A pie chart can show all internal network incidents reported by different sources.

Pie chart

A timeline can show all incidents reported that relate to a single internal network outage (or problem).

Incidents timeline

You will also want a report that shows all linked incidents, linked changes, and backlog items.

Problem linked issues

Finally, you'll need a timeline of events from when the first incident was reported, all the way until problem resolution.

The visual representation of our data connected, literally connecting the dots, increases comprehension and the effectiveness for reports.

Events timeline

Organization of Reports

Organizing the reports is important as well. Just like a writer organizes elements for their story, the positioning of reports on the dashboard is part of the complete reporting story. The goal is to answer all possible questions by decision makers with how the reports are laid out. The layout will tell a key story.

We recommend having different dashboards or views for different roles, because different roles will ask different questions. Seeing the reports in a dashboard together, reading in an order that makes sense, and helps answer questions, contributes to the context of the reports. This decreases the time needed to make decisions, and offers collaboration with the data residing in the source of truth.

In Practice

Here are some example dashboard configurations using all of these best practices.

How are we performing?

  • Overall SLA Health (Gauge)
  • More details in SLA (SLA Report)
  • More granular details on performance (MTTR)
  • Time in Status Flowchart
  • Questions
  • Is training needed?
  • How well-written is our knowledge-base?
  • Do we need more people?
  • Do we need to focus resources on a certain system? Does our process need refinement?

What is Our Workload?

  • Open vs Resolved Chart (how many were opened and how many were resolved? this answers questions about our velocity.)
  • Tickets by Priority Chart
  • Capacity Flow
  • Tickets by Priority Report

Incidents and Problem

  • Show problem timeline
  • We have an incident reported
  • Many are reported that lead to a problem Problem leads to a Change
  • Change to Story
  • Problem Interconnectivity Report Incident Timeline

Data-Driven Decision-Making

The data working together, with the right representations, and organized in the right way, helps us make data-driven decisions.

These decisions are now based off of a complete view, the what and the why, working together.

If we decide to make that investment in that new internal network equipment, we will know it was based off of real data, collected over time, that together helped us come to this conclusion.

  • How do we become more agile across teams?
  • How do we better collaborate?
  • How do we make smarter data-driven decisions?
  • How do we see the big picture?

Performance metrics are important, but the context is even more important for making decisions. Your reporting needs to tell the whole story. That story might be in 1 report, or it might be in 15, but it will answer both the what and the why. The reporting also needs to be flexible, so it can be organized in different ways to be consumed by different audiences across your enterprise.

As an organization scales and matures in agility, the need for holistic, in-context reporting becomes critical to increasing velocity. We hope these best practices will help you on your journey.

Appendix