Sales reports increasing sales, management sees weaker payment receipts and project management reports well-filled order books. All three statements can be correct. They refer to different sizes. Business intelligence therefore does not begin with a particularly impressive diagram, but rather with the question of what a key figure actually means.

For medium-sized companies, a common reporting basis can help to understandably combine data from several systems. Definitions, quality and responsibilities are crucial for this. A dashboard makes data visible; Whether this results in a good decision depends on its context and interpretation.

From the decision to the key figure

It should start with a specific operational question. Should utilization be planned, a liquidity risk recognized or the development of individual product groups assessed? Different questions require different dates and time periods. A generic management dashboard with as many numbers as possible can tend to obscure the actual task.

The meaning, unit and calculation are described for each key figure. When it comes to sales, for example, it must be clarified whether this refers to incoming orders, invoices issued or another technically defined quantity. Cancellations, credits and internal processes can influence the result. The definition must be understood and supported by the responsible departments.

Capture data sources and responsibilities

A data map shows which application provides which information. Customers, items and organizational units can be named differently in several systems. Stable mappings are needed to merge them. Comparing names alone is often unreliable because spellings and organizational names change.

The leading source is also important. If two systems contain different values, the reporting platform needs to know what meaning and validity they have. A technical merger must not smooth out contradictions unnoticed. Unclear assignments belong in a comprehensible checking process before they appear as clear truth in a management graphic.

A data model with clear granularity

The grain describes what a line technically represents: for example, an order item, a daily inventory or a monthly value per location. If data with different grain sizes are combined carelessly, totals can be counted multiple times. This error can remain hidden for a long time in a visually plausible evaluation.

A common modeling approach distinguishes between facts and dimensions. Facts contain measurable processes or states; dimensions describe, for example, time, product and location. The Microsoft star schema documentation explains this separation. It is a useful orientation, but does not replace the concrete examination of relationships and calculations in your own database.

Do not add up stocks like movements

A monthly turnover arises from processes in a period of time. An inventory, on the other hand, describes a condition at a point in time. If daily stocks are simply added together, the result is a different size than the month-end stock. Such differences must be taken into account in the model and representation. The unity and temporal significance of a key figure are therefore part of the technical definition.

Make topicality visible

Not every evaluation has to be done in real time. A different update frequency may make sense for a monthly results review than for an operational inventory display. Often, an unnecessary real-time requirement increases complexity without improving the decision. The required rhythm should be derived from the task.

The dashboard should show until when data has been taken into account and whether an import has been completely completed. A current timestamp on the website does not prove that all sources are current. If there are different update levels, appropriate labeling is required. Otherwise, you may end up comparing numbers that don't cover the same time period.

Treat data quality as an ongoing process

Before the first report, mandatory fields, duplicates and implausible values must be checked. Interfaces or technical rules can also change later. Quality checks should therefore be carried out on a recurring basis and deliver understandable results. It must be possible to assign a noticeable change to a responsible person.

Comparisons with approved reference values are helpful. For example, do the monthly totals and number of transactions taken into account match the source? Are excluded data sets justified? A report should not silently lose problematic values. If a key figure is uncertain due to missing data, this restriction must remain visible.

Choose diagrams that match the question

A time progression is suitable for a line, a comparison of a few categories is often suitable for bars. The representation should make differences understandable without exaggerating them through inappropriate axes or decorative effects. A chart is not a neutral container: selection, scaling and sorting influence interpretation.

In addition, precise values and an understandable description should be achievable. Color alone is not enough to convey categories or warnings. Simplified sections can be useful for mobile views. Squeezing a large desktop graphic onto a small screen does not improve comparability or readability. The most important decision must remain visible there too.

Think filters and permissions together

Filters by time period, location or department help to examine connections. However, their impact must be transparent. Users should see which selection is active and whether it affects all of the metrics displayed. Different filter logic can otherwise create apparent contradictions.

Permissions must not only limit the visible selection. Exports and direct queries must also be limited to the permitted data. The purpose and admissibility must be carefully examined, particularly when it comes to personal performance or employee data. A BI project must not casually become an unclear monitoring solution. Responsible experts and, if necessary, interest groups should be involved at an early stage.

Keep reports and exports controllable

PDF or spreadsheet exports are handy for meetings. They should include time period, filters and update status. Otherwise, several versions will circulate later with no apparent connection. Additionally, exported files leave the application's immediate protection. Appropriate storage and distribution rules are therefore required for confidential information.

Automatically distributed reports require current recipient lists and defined responsibility. A former employee may not continue to receive confidential evaluations. Delivery is also different from simply starting a shipping process. A comprehensible reporting process includes creation, checking, distribution and subsequent corrections.

Explain deviations instead of just highlighting them

A red value on a dashboard initially shows a deviation, but not yet a cause. Interpretation requires a standard of comparison and context. Is there a seasonal effect, has a large invoice been postponed or has the database changed? An automatic warning should therefore be able to lead to a comprehensible investigation.

Tiered views are helpful: from the key figure through affected areas to the underlying, authorized processes. This connection must be technically consistent. If the details use different filters than the overview, users cannot reproduce the overall value. Such a deviation weakens confidence in the entire evaluation.

Target values also require maintenance. A previous year's target adopted unchanged may not fit into a new organizational structure. If locations are merged or product groups are reassigned, it must be clarified how comparisons will be made across the change. Historical evaluations must not tacitly change their meaning.

Before publication in the management circle, it is therefore advisable to carry out technical coordination with sample calculations. Those responsible should be able to explain how value is created and what restrictions apply. This makes a dashboard less spectacular but more resilient. It is precisely this traceability that is more important for decisions than a large number of diagrams visible at the same time.

Start with a question and a few key figures

A good pilot answers a specific question with a few technically coordinated variables. The people involved compare results with their previous evaluations and explain any deviations. Only when the terms and data flow are correct is it worth expanding to additional areas. So the project is not driven by a large surface area.

GRITTMANN can design individual analysis surfaces and data connections. Ours BI application example only uses demo data and shows a possible representation. For a concrete solution, the first focus is on your company's decisions, data sources and calculation rules.

Sources and further documentation

Technical basics and additional information from the respective editors. Links last checked on 25.10.2026.