Three considerations for real-time reporting

A SOX compliance use case for real-time reporting

While the concept of reporting seems to be pretty straightforward, the term “report” can have a variety of meanings, so I’m always careful to validate my understanding so I don’t veer off in some unwanted direction. After all, reporting capabilities often represents the organization’s A-1 deal breaker requirement.

When discussing reporting in Onspring, there are a few important points I make about our capabilities, as well as reporting in general. What follows are some general concepts and considerations for reporting. To help illustrate the point, I’ll use SOX compliance as an example use case.

1. Understand Your Reporting Goals

When it comes to reporting, I often start by asking some simple questions:

What information do you need to report on?
Who will consume the report data?
Why is this reporting important to you?

Knowing what you need your reports to communicate doesn’t just inform the design of the report, but that of the underlying solution as well.

One of our SOX clients indicated they needed a report that could present the status and magnitude of all SOX-related findings to Senior Management. They wanted to break issues down by severity (i.e general finding, significant deficiency, and material weakness) as well as by business unit, so that management could understand which operating units were experiencing the most significant issues. Out of this simple yet articulate reporting request, I can see that there are certain data elements that are essential to meet this need:

We need to capture SOX-related findings
We need to be able to classify findings by severity
We also need to be able to capture information on their operating units

By understanding the desired output, we can easily work backward to identify key structural aspects of the solution itself. This leads me to my next point…

2. Consider Whether the Data Structure Will Support Your Need

Most people I speak with understand the general needs of their reports. Far fewer people have a strong understanding of how to properly structure their data in such a way that it enables them to meet their specific needs. It’s essential that you carefully consider the nature of the data on which you want to report before you start configuring the reports themselves.

Let’s say for example you want to not only report on the nature and applicability of your SOX findings but also need to report on key dates when certain elements of the finding were captured or modified. If you simply capture the attributes of the Finding in an app and allow those data points to be changed but you have not developed a mechanism for capturing the dates associated with those changes, you won’t have the ability to mine the data you need for that specific reporting purpose. Also, using the example outlined above, if management is keen on understanding which operating unit a finding impacts, your solution design should account for this by enforcing the capture of the impacted operating unit within the finding record.

3. Let the Report’s Function Drive Its Form

When reporting on the results of any process, it’s critical to consider the actual use case driving the report’s creation when determining its design. Thinking in these terms will help you build a report that is meaningful and useful for its intended audience.

For instance, you may determine that you need reporting on the state and status of SOX testing. This is a very general, vague requirement, as there could be multiple angles from which you need to report on testing status.

Control testers may need a report that shows the open test records that are assigned to them and awaiting action.
Those who are responsible for managing the testing program may want to know how many tests are outstanding by Tester and where each one sits in the overall testing cycle.
Control owners may want to get a sense of the rate of failure within their assigned controls over a period of time or grouped by a particular attribute.
Executive management may want to understand how testing failures impact the organization’s ability to meet its stated objectives.

In each of these cases, you are ultimately reporting on the same data set. However, the filter criteria, data elements and/or presentation of the report results will vary greatly. Understanding what drives each user’s need will be essential in designing and delivering a meaningful report.

When it comes to reporting, we here at Onspring understand that this is often your most critical requirement for a system you will use to manage any business process (and certainly a Compliance-centric process). To that end, we believe that reports should not only be structurally sound, but they should be simple for any user to build, easy to understand, and dynamic enough to meet the varying needs of your end-users. We encourage you to check out our reporting capabilities, as well as the other elements of the Onspring platform that can help you do your best work.