3 Considerations for Real-Time Reporting
A SOX Compliance Use Case
By Jason Rohlf
A major part of my work at Onspring is providing demonstrations of our no-code platform and solutions. These demos tend to be as varied as the organizations and individuals I’m presenting to. Some demos last an hour with lots of interaction and focused conversation (my favorite kind). Others are two hours or longer and I end up doing most of the talking (which is probably taxing for everyone).
As I write this blog, I have a demo coming up, and to be honest I can feel a few butterflies jostling around in my stomach. I’ve demoed our platform and solutions on countless occasions, yet the fact that I am going into an unknown situation is enough to make me feel those first-time jitters. Much of what drives this is my desire to make a good first impression. I always want to put my best foot forward and represent our company and our product in the best manner possible, which puts my senses on high alert. Another big unknown for me is whether the folks on the other end of the line are open-minded and friendly or…something different.
More often than not (let’s say 95% of the time), the former situation holds. The people to whom I’m demoing are professional and cordial and simply want to understand what we have to offer and find a better way of doing things. The other 5%…well we’ll just leave them out of this conversation. :)
As I said before, I love when the folks on the other end of the line have thoughts, ideas and questions during the demo, as it keeps things lively and interesting and propels the conversation forward. A question I almost always receive has to do with reporting. Most commonly, it’s stated as “Can I run reports in Onspring?”
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 in an Onspring app.
- Within that app, 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 backwards to identify key structural aspects of the solution itself. Which 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.