What kinds of content does a BI platform hold? Reports, dashboards, OLAP Cubes, ad-hoc queries, documents of all types (PDFs, Word Docs etc...), executables (Java or batch programs), event triggers (file or schedule-based for conditionally kicking off processes)... Most companies start developing and delivering the most pressing analytic content - reports or cubes - based on some priority matrix (a mix of feasibility vs business value), and more often than not, little time is spent planning up front how to maintain and organize the massive amount of BI content that the organization soon becomes hooked on.

Most BI analytic solutions are developed, tested, approved and deployed to the BI platform using generic names, for example, 'Accounts Receivables Report' or 'Actuals vs. Budget Cube'. While such names are great for giving busines users an idea of the type of content that will be presented within the analytic, more often than not, they result in poor organization in the long haul. A typical scenario that emerges is that a user or group of users would like to have some popular report tweaked for their particular purposes. While the customer is always right, we in BI have the responsibly to be forward-thinking and to manage these requests in a way that does not leave the customer or the BI provider with a nightmare to manage down the road. So we may end up with a scenario where we go from one master 'Accounts Receivables' report, to 2 or 3 reports representing slightly different views of essentially the same content. What is even worse than having multiple reports or cubes on essentially the same data domain is not being able to quickly and easily find and distinguish such reports. I've worked in organizations where the 2nd version of the report might have been called 'Accounts Receivables - Bob' or the 3rd, 'Accounts Receivables - New York'. What happens when “Bob” changes departments?

In a minute, I will present common and time-tested methods to avoid having to duplicate reports or dashboards for presentation to multiple audiences. But the problem still remains - how do you set up your content in an organized manner - for the short and long run? Not much rocket science: prefix your report names with a set of well-thought-out numbers. So instead of simply having 'Accounts Receivables' report, you'd have '19020 - Accounts Receivables', where 19020 uniquely identifies this report. Over time, BI users will revert to calling this report by the number, though they very well know the name!

So how do you come up with a numbering scheme for your BI content? You have two basic options, build some intelligence into the numbers or you could simply carve out ranges for particular divisions within your organization or categories across the divisions. The ranges should have some relevance to how your content is set up - whether the folder structure mimics your physical organization structure or not. I'd caution against building too much intelligence into the number, as this could back you into tight corners if you need to share content across divisions (we'll talk later about how to get around this). So what's an example of a numbering scheme?

1000 - 2999: Finance & Accounting (1,999 slots - a lot! - as these are highly analyzed corporate functions)
3000 - 3999: Engineering (999 slots)
4000 - 4999: Billing & Quality Assurance (999 slots)
5000 - 5499: Marketing (slots)

And you could set up sub-divisions under the major categories, such as:

1000 - 1099 - Accounts Payables
1100 - 1199 - General Accounting
1200 - 1299 - Budgeting

If every analytic solution - report, dashboard, cube, trigger, document in a BI system is numbered, users will have confidence that they're using or referring to the right tools to aid them in their decision making process. The area where numbering can be most helpful to users is in searching for content. Rather than searching for 'accounts receivables' and returning 4 reports that have some combination of these words in the title or description, they can simply type in the report number and find the only object with that number. This numbering system is also useful when the actual report is not known or to acquaint a new area user with the reports available to their department or group.

A numbering system is invaluable for BI Administrators and developers as well. For Administrators, the code repository outside of the BI Platform could be set up to match the numbering structure. When a new report / dashboard comes in, the first task is to create folder in the code repository for this deliverable using a newly assigned number. Once the task is assigned to a BI developer, she/he would know where in the code repository to go to start on their assignment. The developer would create their analytic solution - as well as all supporting documentation - using the newly assigned number.

So how do you avoid duplicating content to satisfy different business audiences? There will be requests to clone reports or other analytics for different audiences, resulting in a massive number of objects to maintain, all with practically the same logic. The easiest way to get around this is to use row and column-level security wherever possible. In order to have the widest impact, this should be done at the semantic layer level (Universe, Business View) whenver possible . Another technique that should always be used is incorporating dynamic parameters or prompts that drive users to make selections that affect what columns and/or rows get displayed in their favorite analytic solutions. In this case, parameters and prompts also serve to circumvent requests for cloning reports by allowing users to create a more personalized report.

Voila! A simple strategy for helping you manage BI content. I wish I could take credit for this idea - I learned it many years ago from a buddy, an ex Airforce Avionics Engineer, who applied his wealth of military experience whereever he went. Thanks, Nick!