Build Analytics Products, Not Reports

Build Analytics Products, Not Reports

With one simple mindset adjustment, you can transform your reporting approach from reactive and tactical to proactive and strategic. Along the way, you can change how the wider organization sees the value you provide.

How can you accomplish all this? By treating the dashboards, reports, and analytics you provide as a unified product.

Too often, reports and dashboards are considered requirements within some other product or project. Even worse, sometimes reports and dashboards are simply delivered upon request, without being tracked or grouped together.

Instead, create an analytics product: a grouping of all the related reports, dashboards, trend jobs, and reference tables related to fulfilling a set of requirements for a defined audience.

There is clear value in approaching reporting and analytics as a product, including:

  • A more strategic approach to design
  • Higher expectations for your reporting and analytics
  • Clearly communicated value to the organization

A More Strategic Approach to Design

Product management provides structured processes for thinking through the requirements that a product should fulfill to provide value.

Regardless of which product management approach you apply, treating your reports and dashboards a product prompts you to think strategically about what you are building and why.

The first step will be defining what exactly the product is. Simply setting out to create “some incident management reports” is too nebulous for product-focused thinking.

Instead, one analytics product might be Major Incident Triage Analytics, using dashboards to easily drive quick responses based on information drawn from Incident, Change, Outage, and CMDB tables. Another product might be an analysis of incident trends, looking for patterns that would inform support staffing levels or changes to key technology.

Each of these analytics products will likely encompass multiple dashboards, each aimed at a different audience, with underlying trend jobs, reports, and reference tables. Thinking of these dashboards and reports as one product prompts considering how they work together – does the technician’s dashboard prompt actions that improve the KPIs tracked by the executives?

Product-focused thinking will prompt you to ask questions like: what do different audiences need from our analytics product? How do we make this analytics product more functional? How do we expect the users the product to interact with it?

Higher Expectations for Reporting

A natural by-product of this strategic approach to designing dashboards is that you will find that you are asking more of your dashboards and reports.

Reporting and analytics can be simple or extensive; it can provide insights shallow or deep. By focusing on the potential use cases that an analytics product can solve, you will naturally find yourself asking more of the reports.

When reports are simply the last checklist item when deploying some other project, the result is usually simple reports – simple lists, pie or bar charts. For example, an incident management dashboard might go live with a few charts that break up incidents by category, location, and priority.

On the other hand, designing an effective product will prompt you to create more advanced reports to accomplish more. Rather than waiting for a stakeholder to come with a requirement, you’ll already be building high-impact dashboards that go beyond the lowest common denominator.

For example, one large international food service company used Explore Analytics to create an analytical product about their company’s end-customer experience. Because their focus was on a product – comprehensive insight into customer activity – including information from ServiceNow, their call system, and their chat solution was a day one requirement. Why? Because the analytics product only made sense to their users if it included all the information. As a result, they were able to break down silos of information and communicate to stakeholders outside their IT organization in business terms.

The following screenshot shows a similar dashboard example, including information from chat queues, a call system, and ServiceNow incidents to meet the basic requirements of a call center analytical product:

Clearly Communicated Value to the Organization

Once you’ve defined the analytics product, including clear use cases for defined audiences, you are already on your way to communicating the value of your analytics products to the organization.

Defined analytical products give you a concrete and limited set of products to describe, each with a host of use cases and value to deliver. This is much easier to communicate than potentially thousands of reports and trend jobs with no clear relationship.

In the customer experience example above, the analytics product had value that was naturally easy to communicate to executive management. By providing an end-to-end, packaged solution, executives could see the impact on strategic thinking across departments that such mature analytics could bring.

With such comprehensive solutions in hand, asking for the resources you need to reach the next level becomes a straight-forward conversation. Rather than reports being an afterthought that deliver low value and merit little investment, you can place analytics in an important place on your development roadmap.

Create Strategic and High-Value Analytics Through a Product-Driven Approach

As we’ve seen, packaging analytics into products creates a framework for strategic thinking. Thinking about products is the gateway towards an ambitious, proactive approach to reports that deliver high value to the organization. Finally, communicating to executives in terms of analytics products enables clear communication about the value of such analytics and the investments required to deliver more powerful, impactful dashboards in the future.

 Advanced Service Catalog Reporting Techniques with Explore Analytics

The Service Catalog in ServiceNow allows you to manage and automate IT request fulfilment. While doing so, it collect valuable information about what requestors are asking for. These requests drive the work that your IT organization is performing, therefore advanced analysis of these requests can provide valuable insight as to the demand and how to address is proactively and efficiently.

Moreover, analyzing your service catalog data can answer questions such as are you getting the most out of your service catalog? Or are you leaving valuable insights on the table?

Understand Your Requestor’s Choices through Point-and-Click Variable Reporting

Requested Items in ServiceNow have important information on the parameters of what users want and why they want it – all stored in Catalog Variables. Those “variables” are not normal fields. While they provide great flexibility for detailing requests, they may be a challenge to standard reporting tools that don’t understand ServiceNow Catalog Variables.

Explore Analytics understands Catalog Variables. Using Explore Analytics you can use variables in reports much like you’d use normal fields. This enables point-and-click reporting to unleash the information in the variables and gain critical insights.

For example, this report shows a pivot grouped by variables named “Project Code” in requested items across the entire service catalog. This can provide key information on which projects are driving service requests:

To select a variable, just type its name in the Variables field dialog:

Enrich Your Service Catalog Variable Reports with Data from Other Processes 

After unlocking the richness available within the Service Catalog, you can get further power by combining that data with data in other processes – for example, project or incident data.

For instance, the previous Project Code example stored only a text string of information from the project. By using the Explore Analytics “lookup()” function, you can enrich the catalog data with information from project management. Here, the “Project Code” variable is being used to pull the “Portfolio” field from the project table:

Consider how data from other processes can enrich your service catalog data. Any information stored within a variable can unlock even more data from throughout your ServiceNow environment!

Compare Service Catalog Requests with Other Processes

In addition, you can leverage that data outside the Request process to look holistically across multiple processes.

The next dashboard uses the term “End User Demand” to group together incidents and catalog requests.

The first tab looks at trends – how many requests and incidents are cumulatively being opened. This can be critical as you look to staff and understand what demands are being placed on your organization.

The second tab looks into what is actually being requested and how. The first report looks at what categories of incidents or requests are being opened (combining together the “category” field on Incident with the “item.category” field on requested item). The second report analyzes how requests and incidents are being opened by requestors. Try using the drop-down to focus on incidents or requested items!

Don’t Let Valuable Information Go to Waste – Get Deeper Insights on your Catalog!

As these examples illustrate, your Service Catalog has deep insights on how your requests are being opened and why.

If you’ve invested in driving requests through the Service Catalog, you’re ready to take the next step: unleashing insights on your user need and shifting to a proactive service delivery model!