Developing a Comprehensive Report Inventory
A properly created report inventory can improve efficiency and productivity within your organization. Here are the key elements to include in your inventory.
- By George Firican
- November 21, 2016
As soon as the number of reports in your enterprise starts ballooning, you realize it's not a bad idea to create a report inventory. A comprehensive inventory leads to a more organized report development team and a better understanding of required resources and availability. An inventory also increases efficiency and productivity and keeps your report consumers happy and coming back for more.
If you already have an inventory in place or you're looking to putting one together, here is my advice on some of the key attributes each report inventory should include the following fields.
ID: A unique ID is always a great idea to have for putting together any inventory in order to reference reports quicker between developers and business users.
Title: Even if this is obvious, it is sometimes overlooked, but it goes without saying that recording the title of your report is important because it's usually what the business users will reference.
Description: A short phrase or paragraph will offer context and further insight into the report which becomes very useful when new developers are on board, but it's also information that can be surfaced to the business and reference in training and onboarding materials in order to point the consumer to the right report to access.
Absolute path/URL: This is a link to the report for quick access.
Category: This element is dependent on your organization structure and reporting needs, but try to find a meaningful way to categorize your reports by function, purpose, or business area.
Version: Each report will go through changes or updates when new criteria are provided, underlying data changes, or simple cosmetic changes are required. It is a best practice to keep track of these report updates by assigning a version number.
Status: Use this field to track how many reports are in production, development, or testing. I recommend using the following options: published, under development, under review, and historical (for retired reports).
Business owner: Who has sign-off authority when a report is completed and who can approve change requests?
End user(s): Know what stakeholders to reach out to for testing and usability validation, but also note which users should have access to the report.
Business rules and definitions: This fiel can reference the business requirements documentation, but be sure you have clear business requirements and document how certain fields are calculated, what terms mean, and when context needs to be provided, among other details.
Requested on (date): This field is not mandatory, but it helps you keep track of when report requests are submitted, which can help in resource planning.
Data source(s): Useful for developers, this information should be made available to the consumer to reinforce the validity and awareness of the underlying data.
Data as of (date): This date increases awareness in the validity and timeliness of the underlying data.
Data refresh method: Indicates if the report requires a manual update or automatically at specific time intervals.
Data refresh frequency: This could be real time, on a regular schedule (daily, monthly, quarterly, yearly), or a single point-in-time report with no further data refreshes.
Report platform: If you have different platforms and tools for report delivery, note them (for example, Tableau, SQL Server Reporting Services, Excel, Crystal Reports, Oracle Reports, or QlikView).
Code: The stored procedure, embedded SQL, or just a link towards to code repository could be kept here.
Published on (date): Note the date the report is published and made available to consumers.
Last updated on (date): As mentioned above, changes are inevitable, so keep track of the data of the last update and offer this information to the consumer to raise awareness of the age of the report.
Technical support contact: Especially when multiple report developers are present, note who is responsible for each report in case further development information is needed or changes need to be assigned.
Change log: Similar to the need of keeping a version number, a change log should track all the details of any change request.
This list is not exhaustive and should be adapted to your own report development environment and culture. Even though it might be tedious to document these items, the benefits of doing so are at least directly proportional to the number of reports in the organization's portfolio. Happy inventorying!
About the Author
George Firican is the director of data governance and business intelligence at the University of British Columbia. His innovative approach to data management received international recognition through award-winning program implementations in the data governance, data quality, and business intelligence fields. As a passionate advocate for the importance of data, he founded www.lightsondata.com, he is a frequent conference speaker, advises organizations about how to treat data as an asset, and shares practical takeaways on social media, industry sites, and in publications. He can be followed on Twitter (@georgefirican) or reached via email, or on LinkedIn.