The starting point for all your reports is the report tree. It contains the tools you use to make budget decisions, analyze departmental trends, run course and student database applications, and more. It is an unassuming, yet important, place for reporting. Without any structure to this tree, the reporting experience can be a headache for all those involved. There need to be policies in place to shape report usability, the development process, and report security.

The report tree should be more than a random collection of items where users have trouble finding the reports they need and developers interfere with each other’s ongoing projects. Restructuring the report tree is a great opportunity to prevent or resolve these issues and make reporting more efficient. This is especially true when moving from one reporting tool to another. (See https://evisions.com/gather-data-reporting-tools/) Working on the report tree can easily be part of the migration process.

So where do you start? Begin planning the new structure by gathering feedback from all relevant parties, such as report users, report developers, and administrators. The aim is to reinforce new standards on the creation and usage of reports, and to help with the implementation of the new structure. There isn’t just one way to structure a report tree, but there are several ideas to consider.

Grouping Reports

Grouping reports together should be the primary task during the restructuring process. Imagine having users from every department in your institution using the tool. How do you group reports so that everyone is able to find them efficiently? An obvious method is to organize reports by department, such as Advancement, Finance, and Human Resources. This is a clear way of denoting the areas in which people work. However, you may run into issues like report duplication. Several departments may use the same, or similar, reports for their own functional purposes.

Another common method includes grouping by category or function, where you’re concerned with the report type, usage type, and other interests. The tree may be easier to understand and navigate as levels are clearly described. Compared with grouping by departments, problems can arise when departments don’t want others outside their group, regardless of category or function, to execute their reports.

Perhaps, then, it might work best to have a mixture of these two groupings – a structure that meets your needs by first separating by department, and then further organizing reports by category or function. This process also provides you with an opportunity to take key implementation actions to help with reporting efficiency:

1. Review reports to determine how they fit in the new tree structure
2. Consolidate reports into a smaller number of objects
3. Check usage statistics, and with users, to remove unused reports
4. Implement standards such as:
   1. Naming conventions (Naming parent/child levels with clear descriptors)
   2. Aiming for report levels no more than three deep on the tree

In the end, the intent is for end users to be able to quickly find and execute their desired reports.

Dealing with People

In designing the report tree, you will need to consider two main sets of users: end users and report developers. End users execute interactive forms, generate report outputs, and analyze data dumps. Report developers create the underlying objects to these items through user-requested requirements. Handling the separation between end user and developer is tough. The former should not touch incomplete reports or disrupt the development process. The latter should neither affect live reports nor create objects all over the tree.

The first method is like the grouping methods we discussed earlier, where it is simple to implement a clear structure. However, there is still the potential for users to “cross contaminate” each other’s reports or to create unwanted report clutter.

For the second method, implementation depends on the report tool’s capabilities and license. This provides the greatest amount of administrative control from report development to live reports, giving rise to an approval process of clearing developed reports before moving them into production. With a separate instance, developers are given a dedicated space to run tests without affecting production reports. Doing this requires an extra set of resources for development, and will also give greater responsibilities to administrators for maintenance. In fulfilling either method, a certain level of security is needed to control user and report access.

Security Matters

Let’s say we are grouping reports by department, and we want users to access only their department’s reports. How do we enforce this? We can solve this by implementing report-level security. A reporting tool typically has security aspects such as application authentication, access to database connections, and database-defined security. For restructuring the report tree, these do not help. Report-level security involves granting and denying access to all levels of the report tree, down to individual reports and their objects. A sample tree may look like the following:

• Root Level: Two sections for Users and Developers, where these groups are not able to access each other’s areas
  • Users: Group by department with controlled access
    • Department: Group by report type with no additional security
  • Developers: Group by individual user with controlled access

This type of security will help you set standards and flesh out your report tree plans. It will even improve ease of use by guiding users to their relevant reports and providing dedicated areas on the development side.

Lastly, be sure to consult with IT administrators in charge of security to see if any institutional security policies should be applied to these instances. It is best to consider any available security options on the tool to fine tune the configuration to meet your reporting needs.

Conclusion

Restructuring a report tree is a difficult task, especially if it has been established for some time. Implementing change entails users agreeing to move their reports, consolidating those reports, and even placing restrictions on them. However, there are benefits to all parties involved. The end user will have a better experience with application usability, while the developer is able to create reports more efficiently. Even administration becomes easier, in terms of maintaining the balance between these two groups while also securing the tree. There is always room for improvement when it comes to reporting, and improving the structure of the report tree can be a worthwhile endeavor.