Business Objects – Best Practice – Report Design
The purpose of this document is to provide a description of what I consider to be best practice when designing a business intelligence report. I will also try to describe the reasoning behind the suggestion.
photo credit: ArtemFinland
1 Document Structure
A business intelligence document is made up of many reports. Each report can have many pages.
1.1 Document Templates
Business Objects allows you to use document templates to store default layouts for individual documents or reports. Alternatively, you can simple use an existing document as your âtemplateâ? and then save it with a new name. Note: There is no way to cascade changes made to a template through to existing documents created from that template. If a new template layout is decided upon then all existing reports must be edited to include that change.
1.2 Title Report
The first report in every document should always be a title page. This enables you to display on screen and for print purposes all of the metadata that is relevant for the document. The easiest way to lay out the metadata is using a table structure rather than lots of individual floating cells. In some scenarios the title report will consist of multiple pages, page one containing the report name and the âcommonâ? metadata such as universe name, connection details, report version and then there is a second page which gives access to the full list of document level metadata.
For a full list of the suggested metadata see the Metadata section on page 5 on page 5.
1.3 Report Pages
There should then follow any number of report pages as required by the user requirements. Each report page should be titled correctly. The report tile should be reflected in the textual title that is on page one of the report. The order of the reports within the document is normally not important. Typically the more highly summarized the information the earlier it appears in the document, leaving the lower level detailed data to appear in the later reports.
1.4 Data Pages
There are some cases where the data may need to be extracted from the document into an external tool such as Microsoft Excel. There may be occasions when the last few reports of a document will contain tables of data that are formatted explicitly for exporting. This may include removing formatting, displaying exact precision of numbers and removing subtotals and grant totals.
The use of external tools should always be thouroughly investigated. All business questions should be able to be answered from the Business intelligence tool.
2 Look And Feel
Most large companies will have a corporate style which has been carefully crafted to reflect their band. Every effort should be made to ensure that every report that is produced from the Business Intelligence tool conforms with this banding, this will negate any rework that would be required if an internal document is required to be shared outside itâs original audience.
Components that are commonly customized would be:
Ensuring that the correct company logo is used in the correct manner. Typically a larger logo would be used on the first page of the first report in a document, ie the cover sheet. A smaller log may then be used on the first page of subsequent reports in a document. A small logo may be required in the header of every page of the document.
2.2 Font Style and Size
There will commonly be a reduced number of fonts faces and font sizes that should be used in differing scenarios. This will include but not be limited to: Title pages, section headings, table headers, table data, headers and footers.
Typically a single or reduced number of colours will be used for all text. When large tables of data are being displayed it may be of benefit from alternately shading the background of each row. On charts you may wish to apply a consistent rule that ensures that the same measure always appears as the same colour, ie sales always appears as light blue on a line chart.
You should also consider how your content will look if it is printed out in black and white.
You should also consider how to make your information accessible to all users who may for example be colour blind.
Care should be taken that the size of headers & footers is large enough to contain the required information in a readable format but leave enough room for the actual report content. Sometimes a border between the header and footer and main the page will make the content more legible.
2.5 Contact Details
There should be a consistent place for example on the front page where a report user can obtain contact details to raise any issues with the document. This may be the help desk, the BI Competency Centre or a subject area expert.
3 Data Protection / Anonymisation
Depending on the type of information that is being presented there may be legal requirements as to who can access the document and what they can do with it.
There may be the need to add a disclaimer to the document if there are doubts over the completeness and accuracy of the information contained within it.
There may need to be a statement that discourages unauthorised users from reading information that they should not have access to. This may be required to be placed on every page in case a page is left in a printer, copier or other public place.
If the data is particularly sensitive then certain figures may need to be anonymised. For example exact figures may be rounded to the nearest large multiple. Extreme values may be obfuscated, eg <100 or >90%. If this is being done then care should be taken that the figures cannot be determined by combining the supplied information with grant totals, or by cross referencing it with information contained in other reports in the same document.
The following list contains the suggested metadata that should be attached to all documents. Some metadata can be sourced automatically from the document itâs self, other had to be manually maintained as it is sourced from outside the Business Objects environment. Some metadata should be listed on the cover report others should be listed on every report.
4.1 Document Level – Automatic Metadata
â¢ Document Author
There should be contact details for the main report author or developer, this enables the development process to be speedy and ongoing technical issues can be addressed by the correct person.
â¢ Document Name
The document name should be unique within the enterprise. Commonly it will contain a unique reference number for speedy searching, a textual description and a version number to enable change control. Some enterprises choose to automatically append the refresh date every time a report is refreshed to allow historical versions of documents to be available, if you are using the Xi version of Business Objects then this functionality is replaced by the document âinstancesâ? functionality.
â¢ List Of Responses for each query Prompt
Every prompt that is used in any of the data providers should be listed in a table along with their responses. This is required to give context to the results shown.
The list of prompts cannot be gathered automatically but once the list is built the responses can be obtained automatically.
â¢ List Of Data Providers
Knowing how a document has been built can help to educate users as to how to build their own documents in the future. As the data providers will be visible to all users they should have appropriate and meaningful names.
The data provider name can be obtained automatically. The list must me manually maintained unless macros are used.
â¢ Data Providers last execution date and time
Normally, when a document is refreshed every data provider in the document is refreshed at the same time. It is possible however, to manually refresh only selective data providers. It must be easy and obvious to check if this has happened as the resulting document may contain inconsistent data.
â¢ Number Of Rows in each Data Provider
This is an item that is not commonly required however, it can help to aid investigations into document query performance or aid investigations into document data anomalies.
â¢ Connection Name (Database Name) for each Data Provider
The full text of the connection can be displayed here but what is most commonly required is the name of the database and schema that is being queried. This can help in scenarios where development documents are accessing live databases or live documents may be used to text development data sets.
â¢ OLAP source for each Data Provider
See the previous entry.
4.2 Document Level – Manual Metadata
â¢ Document Description
This should be a textual description of the purpose of the document in language that would be understood by the business community.
â¢ Document Version Number
As Business Objects does not version control its content, it is common to also store copies of the documents in an external version control system such as source safe or pvcs. The version number allocated by these applications, or a manual number should be referenced.
â¢ Document Change Control
As each document changes over time itâs version number should be incremented and a log kept of: the description of the change, the requestor of the change, the developer and the testing done.
â¢ Document Business Owner
Every document should have a nominated business owner. This may be the person that requested the document or it may be the business user that knows most about or owns any issues with the subject matter data.
â¢ Document Specification Location
There should be a link back to the specification of the document. If someone wants to request a change or request a document similar to an existing one then having access to this information will make the process easier.
â¢ Document Test Specification Location
Every document should be formally tested before it goes live. If a subsequent problem occurs then referencing the test specification and results can help to pinpoint the source of the problem.
4.3 Report Level â Automatic Metadata
â¢ Document Name
See entry in Document Level – Automatic Metadata. This information is commonly placed in either a header or a footer so that it appears on every page.
â¢ Partially Refreshed
It is possible for a data provider to return partial results due to universe limits or maybe the user cancelling a query. It is important that the user is informed that they are not seeing a full dataset. This is typically implemented as an alerter so the user only sees a warning if there are partial results.
â¢ Drill Filters
If a report is drillable then it is important to place a copy of the current drill filters on the report. When the user is using the tool they can see the drill filter toolbar. If the report is printed then this information is lost. Typically the drill filters are placed only on the first page of each report.
â¢ Global Filters
If a report had global filters in place then that means that the report is not referencing all of the data that is contained in the data providers. It is important that the user is aware that they are not seeing the complete dataset. Typically the global filters are placed only on the first page of each report.
â¢ Page / Number Of Pages
This information is typically placed in either a header or footer so that it appears on every page. It is important to include both the current page number and the total number of pages to ensure that a printed report is complete and no pages have been lost or excluded.
â¢ Last Execution Date & Time
This information is important as it can help resolve any discrepancies between different âversionsâ? of the âsameâ? report.
4.4 Report Level â Manual Metadata
â¢ Report Commentary
It is common to add textual information to enhance the report or to explain any anomalies. This may take the form of a simple text box into which the text is typed and then saved with the document. A more elaborate system could be implemented where the comments are stored in a database and accessed via the universe.
These are what I would consider to be the current best practices when designing business intelligence documents. As is always the case there are times when many of these can and should be ignored. This list should not be used dogmatically but pragmatically.