Reporting | Dashboards | Indicators | Key features

Key characteristics of reporting

Written by

Passionned Group is a leading analyst and consultancy firm specialized in Business Analytics and Business Intelligence. Our passionate advisors assist many organizations in selecting the best Business Analytics Software and applications. Every two years we organize the election of the smartest company.

Known key success factors

We use reporting – just as dashboards – in order to display the known key success factors and the associated indicators. Both already prepared in the data warehouse. In this way, we can signal potential problems in business operations at an early stage.

Reports typically provide detailed information. This is why they use both data from data marts (or cubes) and detailed data from the ‘Central Data warehouse’. Reports generally display information in charts or tables, although alternative visualizations are also possible. An example of a report is shown below.

Key characteristics of reporting: a sample of an report

A report usually exists of a table with columns and rows – sometimes enriched with a (graphical) chart that illustrates the figures. The table can be grouped by department, business unit, product group and so on. Subsequently, the chosen arrangement or layout is often used to generate an index that allows managers and other interested parties to quickly ‘jump’ to a specific part in the report.

They offer a very limited degree of interactivity

Reports are mostly static. They offer a very limited degree of interactivity, even less than dashboards in most cases. If needed – due to lacking a dashboard or interactive analysis for example – the interactivity can incidentally be increased by placing one report after another (successively), each time from a slightly different angle, such as business unit, product group, customer group and so on. If we add indexes to these reports, users can still use and apply certain interactive functions, such as switching between angles and so-called ‘drill’ functionality.

Reports usually do not have a fixed structure or format. It is up to the employee who compiles the reports to come up with something. Nonetheless, it is highly convenient if all the reports an organization uses have the same (or nearly the same) structure, format and layout, simply because users – when they switch between reports – will be able to both interpret and understand the reports much quicker. It is therefore well worth the effort to draw up a standard for reports in which the desirable layout, colors, fonts, positions are documented.

Reports must be ‘aggregate aware’

During the creation and renewal of reports, we automatically – under the hood – generate SQL* , a standard language for data manipulation and data selection from databases. This makes that employees can create rather nice – even complex – reports relatively easily even without any technical knowledge on databases or SQL. As a result, employees are less dependent of the IT department – except in case of more complex reports that require technical knowledge. So-called reporting tools, which ‘fire’ SQL on the database based on report designs must be ‘aggregate aware’** . In order to achieve rapid response times, it is important that the report ‘knows’ whether it can draw from the summaries that are available in the data marts, or whether it has to rely on the detail data in the Central Data Warehouse.

Key characteristics of reports

  • Static and well-arranged;
  • Information needs are determined in advance;
  • Customizable design/interface;
  • Data is only refreshed (updated) when specific instruction is given by for example planning software or the user himself;
  • Make use of (relational) data marts (among other things).

See also: Important features of dashboards

* Some reporting tools do also generate MDX, a standard programming language for querying cubes.

** This applies to a default relational database management system. We do not address specific solutions that work with advanced indexing techniques -‘indexed views’ or ‘materialized views’ – whereby aggregations are made redundant in which case the database itself must be ‘aggregate aware’.

Comment on this post by Daan van Beek

Your email address will not be published. Required fields are marked *

A selection of our customers

Become a customer with us now

Do you also want to become a customer of ours? We are happy to help you with reporting (dashboards) or other things that will make you smarter.

Daan van Beek, Managing Director


Managing Director

contact me directly

Fact sheet

Number of organizations serviced
Number of training courses
Number of participants trained
Overall customer rating
Number of consultants & teachers
Number of offices
Number of years active