BI Best Practice: Delete Most of Your Reports
Deleting reports will allow your enterprise to focus on new value instead of maintaining old assets that are rarely used.
By Ike Ellis, Partner, CraftingBytes
Any boat owner will tell you that the second best day of their boat-owning life is the day they buy their boat. The best day is the day they sell it. Boats just take a lot of management. You have to clean them, gas them, fix them, and use them, and if you have a boat in the driveway that you never use, you just feel guilty. Guilty for not using something you spend so much time and money on.
It turns out that not every asset is valuable.
I was recently called into the office of the CEO of a Fortune 500 company. He asked me to delete every report in their report repository except 15, which he listed on a piece of paper.
After a pause, I asked him what led to this decision. Recently, he submitted a report to his board of directors. A couple of the board members pointed out that his numbers didn't align with numbers he had earlier reported. He was deeply embarrassed. Then he was angry.
He immediately went back to his BI director and said he never wanted that to happen again. He told her that he wanted every single report to align correctly with every other report the executive team used. The BI director told him that she thought that was a great idea. She asked that she be allowed to hire five extra report authors. He asked why that was necessary and she said that they had 750 reports that were created at the request of the executive team. These were just executive reports and did not include reports for line managers, analysts, outside vendors, and other decision makers.
He couldn't fathom why it was necessary to have 750 reports to run this company. His immediate reaction was that he could run the entire company on fifteen reports. After looking at a small subset of reports, he determined a few things:
- There was a lot of overlap between most of the reports. Sometimes just the coloring was different. Sometimes it was sort order. Sometimes reports were almost the same, with most columns in common.
- Because there were so many reports, he imagined his team thought it was easier to just request a new report rather than search through so many reports to see if there was an existing one that was good enough.
- With this many reports, it was impossible to keep them all aligned with each other, no matter how many employees the BI director had under her.
The BI director said she couldn't possibly delete all of those reports without help, so they contracted me. I spent three months interviewing all of the executives while meticulously going over every report they had available. I combed over audit logs to see which reports were actively being used. I continued to ask the executives which reports could be consolidated into one report and which we could delete.
The entire process took three months.
The CEO was actually close to being right. By the time we were finished, we were able to delete 700 reports from the repository. The executive team went down to about 50 reports in total.
This process also taught me that most companies follow a very specific pattern. The business will face a strong challenge. Executives will panic and strongly react to the challenge in front of them. They will request reports to grapple with it from many different angles. It will take about six to 12 weeks to wrap their minds around it, address it, and either resolve it, or get it under relative control. Once that's finished, the executives will never go back to the BI team to tell them that the reports are no longer needed. Those reports will stay in the repository, becoming a management nightmare
How can your BI department address this typical business pattern? By doing two things: meticulously auditing every report execution and deleting reports that are not being used.
Every report execution needs to be audited. A report is not a good report if it has spark lines, bar graphs, awesome drill-throughs, and great 3-D visuals. A report is only a good report if it delivers the right data to the right person at the right time. Audit logs will tell you which reports are the important reports.
Beware of e-mail subscriptions. They will give you false positives in your report logs. Instead, e-mail links to your report server. If that's not possible, have the report download a JPEG from a Web server and audit that download. Every time a report is created, it needs to have an audit policy attached to it.
Don't be afraid to delete reports. Leave them in source control so that they can be replaced if necessary, but don't hesitate to delete it. The worst that can happen is that someone was looking for it and they call you about it. That's a good sign. It lets you have another conversation about the report with the business stakeholder. It also lets you discover ways your report is being used that you did not intend.
We had some interesting by-products of deleting 700 reports at this company. Our average report delivery time -- from the time a report was requested to the time it was delivered -- went from two weeks to 24 hours. This happened because our report authors were no longer spending so much time maintaining reports that no one really used. They had more time to do what they were meant to do: create new value for the company and address the current needs of the company.
We added a new policy: we put the report stakeholder's name in the footer of every report. That way, if someone requested a report we thought could be satisfied with an existing report, we knew whom to call to consolidate the new report. With an executive mandate from the CEO, the other executives were more willing to compromise and use the same report.
Feel free to start deleting. Enjoy the liberation. You'll feel less burdened and you'll feel that sense of freedom to spend your time creating new value for your organization.
Ike Ellis is a Microsoft MVP for SQL Server. He's a published author and popular conference speaker. He's a partner at CraftingBytes, a small consulting studio. You can contact the author at [email protected].