Business Intelligence (BI) ‘combines business analytics, data mining, data visualisation, data tools, and infrastructure… to help organisations make more data-driven decisions’ [1]. A vital part of BI is reporting. Reports provide a visual and often interactive presentation of data, used to monitor key business metrics and performance. Reports can also be referred to as dashboards depending on the tool.
There is a large amount of data held by businesses in the modern-day, and likely even more in the future. This being said, businesses face certain risks if they don’t have a BI solution. Reports could be duplicated, wasting time and effort. There could also be multiple and inconsistent logic in calculations and metric definitions. A BI reporting solution aims to resolve this by working with the business to understand their data requirements. Additionally, reports can also help define metrics and automate data collection and transformation. Ultimately, providing a collection of reports acting as ‘one version of the truth’ built from trusted and verified data sources.
Sounds simple enough, right? The challenge is measuring BI’s impact and assessing if the reports are successful. Has all the hard work paid off? I have previously written about the importance of data visualisation best practice [2]. I have also touched on designing reports to improve user-engagement [3] as factors of measuring success. However, non-aesthetic considerations are equally important. Here, I focus on some of the processes behind reporting and list four key stages to consider.
Who is the BI report for? The report’s target audience will help guide the needs and detail level. The audience is vital because different groups will use reporting for different things. For example, senior management may rely on reports to check on key metrics and explore overall trends. Therefore, a report tailored for this type of audience would be a high-level overview. The overview would focus on several key metrics’ performance.
In comparison, a report for a manager of a specific business area would need a greater level of detail on their team’s performance. This type of report would provide a general overview as well as more specific details. For example, an IT Helpdesk report could require information on ticket items by category, status, assignee etc. A great report, thinks about the needs of its audience.
Concrete requirements on the BI report’s purpose and the data source are needed once the audience is established. These can be thought of as the main business questions that need to be answered or the key metrics that need monitoring. More specifically, requirements should also include different data aggregations, such as visualising the data over time by year/quarter/month.
As well as different ways to group the metrics by various attributes such as country and region. Details on the report layout and functionality should also be agreed upon, such as the required filters. Furthermore, vital to requirements gathering is confirming the metric definitions and logic with the business. To ensure the definitions are clear and understood, it is worthwhile to include them in the report or related documentation.
I am sure all Analysts dread the moment they deliver a report, and someone says, “that’s wrong”. The whole report loses integrity, and people start to question how trustworthy the report is. There are various elements to data quality. Broadly, it boils down to completeness, consistency, and correctness [4]. There are several reasons why data could be considered wrong, including:
Data quality and governance are vital for BI’s success, but it is only possible to report on the available data. The level of data quality is often not determined by BI itself. Instead, it relies on the wider business culture to recognise and prioritise data at the core of its decision making. However, there may be ways to tidy, reshape, or transform the data to make it more accurate. Therefore, it is crucial to profile the data behind any report.
You need to understand the areas of poor quality, the reasons behind this and potential ways to improve them. This equips you to respond to comments along the lines of “that’s wrong”, with evidence that it is correct from a reporting perspective (i.e. it represents the available data). You can also provide proactive solutions to improve the data quality.
Imagine you have built your BI report and checked the data. You are happy it meets the specified requirements for the target audience. Great! However, it is not quite there yet. You must allocate time to the development cycle to allow for testing and feedback. This could be from both internal colleagues (two pairs of eyes are always better than one!) and the client. This is to ensure the output is as they expect.
It is sensible to allow for feedback throughout development, to ensure you are on the right track. You don’t want any surprises or rushed changes nearing the reporting deadline.
To summarise, this post’s purpose has been to highlight four key elements to producing successful BI reports aside from aesthetics. These are: