Building a KPI dashboard for your business

A KPI dashboard for a business works when it shows a few metrics that someone actually uses to steer, and when the data arrives automatically from existing systems. Many dashboards fail not because of the technology but because they show too much, nobody owns the numbers, and it is unclear what should happen when a figure goes off track.

Which KPIs belong on an operations dashboard?

An operations dashboard should only show metrics where it is clear who does what differently when they change. A metric without an associated action is information, not steering. A simple rule of thumb: if nobody can say which decision depends on a number, it does not belong on the first page.

Which metrics those are depends on the business model. A manufacturer steers differently from a retailer or a service company. Typical areas from which businesses choose their few steering KPIs include:

• Order book: open orders, incoming orders, delivery dates at risk
• Output: units produced, lead time, share of on-time deliveries
• Resources: utilisation of machines or teams, planned versus actual hours
• Quality: complaints, rework, scrap
• Cash: outstanding receivables, payments due, stock as tied-up capital

A business does not pick everything from these areas, only the handful of metrics that match its current problems. Which questions a business should answer with data in the first place is covered in our article on data-driven decisions for SMEs. A metric may also leave the dashboard once the problem behind it is solved.

How do you connect the data sources?

A dashboard is only as good as its connection to the source systems. Copying numbers into a spreadsheet by hand every week is not a dashboard but an extra task that sooner or later gets dropped. The data should therefore flow automatically through interfaces from the ERP, point-of-sale system, time tracking, machine controllers or accounting.

There are several ways to do this: some systems offer a documented API, others allow direct read access to the database, and older machines only provide data via their controller or additional sensors. Ideally a separate data layer sits between the sources and the dashboard, where data is cleaned, terms are standardised and history is stored. That keeps the dashboard stable even when a source system changes.

Real-time or daily snapshot – what does a business really need?

Real-time only makes sense where someone reacts immediately. A shift lead who steps in when a machine stops needs current data. Management that discusses orders and cash once a week needs a reliable snapshot, not a live ticker. Real-time data is more work to connect and run, and it easily distracts from trends because every short fluctuation becomes visible.

• Real-time or near real-time: machine states, faults, stock levels of scarce material, service queues
• Several times a day: incoming orders, progress of running jobs, capacity planning
• Daily snapshot: units, hours, revenue, complaints
• Weekly or monthly: contribution margins, cash development, longer-term trends

Who looks at the dashboard, and when?

A dashboard needs a fixed place in the working day. Without clear ownership it is often opened at the start and then forgotten. It helps to define a separate view and a fixed rhythm for each audience.

• Shift or team leads: at the start of a shift and during disruptions, focused on today
• Department heads: in the weekly meeting, focused on deviations and bottlenecks
• Management: weekly or monthly, focused on trends, cash and decisions

For every metric it should also be clear who is responsible and at what deviation someone takes action. These thresholds are derived from the business's own data and adjusted over time. A dashboard nobody reacts to is decoration.

How do you go about building one?

1. 01Write down the few decisions that are made regularly and are hard to make today.
2. 02For each decision, define the metric that supports it and write down what the term means.
3. 03Identify the source systems and check whether the data there is captured completely and correctly.
4. 04Set up interfaces and a data layer that take over data automatically and store its history.
5. 05Build a first, simple view and use it for a while alongside the current practice.
6. 06Agree ownership, rhythm and action thresholds, and refine them after the first experience.

Whether the end result is an off-the-shelf business intelligence tool or a lean custom solution is a secondary question. The choice of tool should follow the source systems, the users and how it will be run – not the other way round.

What does a good operations dashboard look like?

A good dashboard fits on one screen and can be read at a glance. Each metric shows not only the current value but also a point of comparison – the previous period, the plan or the trend – because a single number without context says little. Colour is used sparingly and only where a deviation calls for action.

• One view per audience instead of one dashboard for everyone
• Current value plus comparison with plan, previous period or trend
• Clear labels using the written definition of each term
• The ability to drill down from a metric to the underlying records
• A visible data timestamp so nobody decides on stale figures

The visible timestamp in particular is often forgotten. If an interface fails and the dashboard quietly shows yesterday's numbers, someone makes a decision on the wrong basis. A note showing when the data was last updated prevents that.

What are the most common mistakes when building a dashboard?

• Starting with the tool instead of the decisions it should support
• Showing all available data because it happens to be there
• Adopting metrics without defining the term for your own business
• Entering data by hand and leaving its upkeep to one person
• Demanding real-time where a daily snapshot is perfectly adequate
• Launching the dashboard without agreeing rhythm and ownership

These mistakes usually share one cause: the dashboard is treated as a technical project rather than part of running the business. Thinking from the decisions outwards avoids most of them automatically.

How NDVDL builds and runs it for you

NDVDL starts with an appointment at your premises: which decisions should improve, where is the data created, who should use the dashboard? You then receive a written proposal for metrics, data sources and the technical solution: a standard tool where it fits, a custom solution where it does not.

During implementation we connect the ERP, till, time tracking or machines through interfaces and build the data layer. After that, NDVDL runs and maintains the connections and the dashboard and makes sure the connections keep working when a source system is updated or new equipment is added. You have one fixed contact person who knows your systems.