Things to Consider When Building Reports

Dec. 10, 2018
Reports are used for all types of manufacturing processes. To make it useful, be sure to follow three important guidelines.

Clear and easy-to-follow reports are integral to every business as a way to prove product quality, review processes for improvements, or to troubleshoot issues as they arise. For a report to be useful, it needs to contain three components.

Make the report uniquely identifiable

The report needs some sort of naming convention that allows you to easily understand what the report will contain and the context of the data. There needs to be a way to pull each report while knowing which report is going to be generated. The report must have set start and end times for the data (be it a set timeframe such as a weekly report or a manufacturing-defined time such as a batch report), which should be referenced in the report name to give context.

A typical way to accomplish this is to allow a report type to be selected (weekly alarm report, batch report, etc.) and then allow the report instance to be selected from the list of possible options. Reports should not be generated in a way that removes this context, such as an ad hoc report or a generic report used for all instances.

A report must contain useful data that will be utilized

Too often, reports are bogged down by useless data in an effort to report everything, overshadowing the useful and critical data. A recurring example is the reliance on data trends within reports instead of using data aggregates and exceptions. Although these trends might look nice and be more typical of what the reader is used to seeing, trends have a tendency to mask data and throw it out of context because they are open to interpretation by the reader instead of the report telling a story of what happened.

Because there are only so many pixels on a page, a trend cannot show every data point, and most trends will interpolate data points within what is able to be shown. This masking might be practical to remove inconsequential outliers, but too nobody puts thought into the data that might be missed or overlooked due to this limitation.

Using data aggregates (max/min valves, standard deviations, averages, etc.) as well as exceptions (deviation warning/alarm conditions) will paint a better picture of the process and whether it remained within specifications. This is typically referred to as reporting by exception. It allows a much more condensed report that still has useful information and is easier to contextualize within the process.

Make the report immutable

If you wish to look at a report at two different times, the report should contain the same data each time. Similarly, if two individuals were to look at the same report, it should contain the same information for both.

This can be accomplished a few ways. A common, though less efficient method often used is to generate the report and then print, sign and store the paper copy, or save it as a PDF that is electronically stored in a shared repository. This allows one master record to exist. A more user-friendly method would be to allow the report selection based on the unique identifier alone, which would pull up or generate the report and allow no modification of the report from that point.

Often, you will see a reporting application that allows the user to select a report, which will set the start and end times for data. Once the report is generated, the start and end times can be manipulated. Though this allows for more flexibility for the end user to view data, it allows two reports of the same name to show different timeframes, and thus different data. Reports should not be allowed to be ad hoc, allowing the manipulation of the data or timeframes by the end user to suit their individual custom needs outside of the context of the report. The report should remain as the report alone, and other general data queries should be treated separately to keep the integrity of the data.

By paying attention to these three critical components, you will be on the road to creating meaningful and compliant reports for your process and team.

Dan Krohnemann is lead engineer at Panacea Technologies, a certified member of the Control System Integrators Association (CSIA). For more information about Panacea, visit its profile on the Industrial Automation Exchange.

Sponsored Recommendations

Put the Plant Floor in Your Pocket with Ignition Perspective

Build mobile-responsive HTML applications that run natively on any screen.

Ignition: Industrial-Strength System Security and Stability

Ignition is built on a solid, unified architecture and proven, industrial-grade security technology, which is why industrial organizations all over the world have been trusting...

Iron Foundry Gains Competitive Edge & Increases Efficiency with Innovative Technology

With help from Artek, Ferroloy implemented Ignition to digitally transform their disconnected foundry through efficient data collection and analysis while integrating the new ...

Empowering Data Center Growth: Leveraging Ignition for Scalability and Efficiency

Data center growth has exploded over the past decade. Initially driven by organizations moving their computer assets to the cloud, this trend has only accelerated. With the rise...