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.
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’.