Report and Dashboard governance

[SusanWinKY]

All of our ITIL users are able to create reports and dashboards.  Over time, as expected, we've accumulated quite a lot of reports.  We've been asked to put a governance process in place to deactivate reports and dashboards that are no longer needed. 

Has anyone implemented such a governance policy and would be willing to share your decision-making and implementation regarding this?

My initial thought is to set up a scheduled email that asks the owner of each report/dashboard if it's still needed, and provide two links (Yes | No).  Upon clicking No, the report or dashboard would be deactivated. 

Another thought is to automatically deactivate a report/dashboard whenever the owner/creator of it is deactivated, but then we run the risk of deactivating something that others may be using.  With the email method, we at least put the decision in the hands of the person who owns it.  We'd still have to figure out how to handle reports/dashboards that are owned by a deactivated user, but I think our team can manage that.

[Scott Jordheim]

We had similar issues. We restricted dashboard and report creation (unfortunately editing came with this) to the admin team only after much discussion and creation of a standardized dashboard and set of reports everyone would be using. We will be going through and deleting unused reports and dashboards as we are able. I'm assuming homepages will be following.

This was done in an effort to better standardize the information staff are seeing and what leaves the platform for decision-making etc. We were finding not everyone creating reports knew all of the database inner-workings, which was causing too many inconsistencies in reports supposedly going after the same data. It was also causing huge spikes in load times with improperly designed reports, along with repeated duplication of reports when they could be made dynamic and shared with a larger audience.

For dashboards, we wanted to have everyone viewing / working from the most standardized place possible so processes around resolution time and what not could be more easily enforced.

When it comes to deleting the dashboards and reports, the onus gets put on the team managers to verify what is and is not being used any longer, along with providing justification on why things should be kept if they go against the more standardized processes.

Quick edit: As far as requesting new dashboards or reports or edits to existing ones that have been kept, we created catalog items so we could better track these types of requests.

[SusanWinKY]

Scott, thanks for your input!

We also have a catalog request for reporting needs, but since ITIL users can create their own reports, it doesn't get a lot of use. 🙂 

We may consider restricting report/dashboard creation only to admins (maybe even those who have proven themselves to be super duper reporting gurus), but that would put a lot of new workload on the admin team.  I do occasionally check the logs to see which reports take the longest to execute and adjust them if I find ways to improve their efficiency.

[Scott Jordheim]

No problem. For us, it is surprisingly not that much extra volume after we put in efforts to establish what everyone wanted to work towards and see on a dashboard. (We have upwards of 40,000 employees and over 800 IT staff, with a relatively small admin team.) We established a core group of IT users to provide input and made updates per said input.

The standardized dashboard also comes with the added benefit of being maintained mostly by the admin team, so it receives a lot of updates most staff probably would never know about, which was a nice value add.

The clean-up efforts definitely will put a strain on us when it happens, but outside of that, it has been pretty manageable so far.

Another approach we considered was granting reporting rights in sub-Prod instances only, and requiring an admin to vet the report and push to Prod, similar to Infor Lawson and such.

One of the reasons we found for the extremely high volume of reports was the fact that staff didn't know much about utilizing filters instead when they needed pure lists of data or just raw numbers. Filters worked much better for those needs Vs. navigating to the report UI and figuring out which table to use from there.

[Rafael Lima de]

Hi Scott, 

Can you explain how is the standardization and governance in your company? 

In my company, we are implementing the ServiceNow and we would like to establish some process to control the reporting requests.

[Scott Jordheim]

This is just for reporting, but we restricted down reporting to a small list of SMEs that have a good idea of how tables are related to each other in ServiceNow (through training from my team, etc.). There is also a centralized team more in charge of approving new reports to ensure we aren't duplicating existing reports or causing any other issues. Part of that is done through due diligence by my team prior to us creating any new reports as well.

It isn't perfect unfortunately, but it does avoid some larger issues. A better version may be one or two staff from each team who have higher tier reporting rights in sub-Production instances that rely on the administration team to promote the reports to Production after vetting them. This would avoid numerous reports existing in Production that aren't returning valid results and/or are outdated.