When talking about information hierarchy with clients, I often use the analogy of the "tip of the spear". What I want to express to them is the idea that reporting is most effective when it answers the most important questions first. Once that's done, it's best to make available increasing levels of detail, on-demand. In other words, the focus of reporting should start narrow, and widen to include more specific data. The POV to focus on is that of the user, and their critical questions.
Of course, this isn't the way things develop organically. If left to itself, any reporting or data operation in a company will follow an "accretion" model, where functionality and capability gradually builds up in an organization as a function of time -- not a function of efficiently doing the job. Databases with unrelated clusters of tables that enter the system as functionality arises. Reports made to meet an immediate demand, but then left behind to be rebuilt later by someone who didn't realize the original existed. The scenario accumulates junk, just like a hippie's... well, you know. And so it is that the first step to avoiding or fixing this situation is in organizing a coherent information architecture.
Aim at "first things first." Identify the top users, the top data interaction workflows, the top metrics/KPIs, and the top reports. Then, you can proceed in order of priority down into the details of who needs to see what data, and how. Essentially, you want to put together something like chart of business metrics which might overlay an Org chart.
This "information hierarchy org chart" should help you identify who needs to see what data, at what detail and business level. It should help identify drilldown/drillthrough paths that might be necessary in resulting reports and/or dashboards. It should help shape the reporting offering being made at each level of the business. And it can also help prevent redundant efforts by showing where common views of data are required and how they are connected to other views.
You can usually expect that a summary level of KPIs can be decomposed into lower level metrics, with each lower level being of importance to somebody (if not everybody). So follow this trail from the data at the bottom up as well. Because it's somewhat likely that natural "fault lines" within the data will also exert an "upward" force counter to the business rules, that might actually suggest reporting elements that are not as easily revealed from a purely business perspective.
The goal is to arrive at a catalog of reporting elements aimed at answering the user audience's most important questions first, and then facilitating answers to the "why?" questions that come next. As an added bonus, the implementation of those elements can easily be organized into several different development workpaths that allow flexibility. Would the client like to implement the entire summary level first, to satisfy executive needs? Or is it more critical to build an entire "stack" of reports around one area, in order to fully explore that particular metric from summary level down to ultimate detail? Either direction is possible -- provided the appropriate foundational knowledge of the wider system goals is in place.
