ERP Dashboards and Steering: Real-Time Business BI

Why real-time steering changes the decision

In most SMBs, the data exists but stays scattered: an export from the point-of-sale software, a spreadsheet for inventory tracking, another for cash, a last one for team hours. At each month-end, someone spends half a day consolidating these sources to produce a report already stale by the time it is read. A custom ERP dashboard flips this logic: the data is no longer recopied, it is read at the source, at the moment it is entered in the relevant module. Decisions are then made on the real state of the business, not on an approximate reconstruction.

Data freshness is not a comfort, it is a performance factor. A stockout detected the same day is handled before the lost sale; noticed at month-end, it is already lost revenue. A late payment flagged in real time triggers an immediate reminder; reconstructed three weeks later, it becomes a doubtful receivable. This gap explains why two companies with the same revenue do not have the same margin: one steers in the present, the other comments on the past.

The 2026 context adds a dimension often ignored by managers. A company's structured data does not only serve internally: when it feeds a website, product sheets or content, it becomes a visibility asset. Search engines and AI now reward original, well-organized data, and the share of AI-assisted search is exploding. A company whose figures are clean, dated and usable gains the advantage on both sides: in internal steering and in external presence.

A concrete example, one of our ERP projects for a resort. Before the ERP, operations were coordinated across a mosaic of disparate tools and spreadsheets, with no consolidated dashboard at all: to know the state of the resort on a Tuesday morning, you had to cross-check several files kept by different people. Moving to a single platform shifted steering from the past to the present, giving the teams and management one shared, up-to-date view of the business.

The business KPIs to track, by function

A useful dashboard is not built by stacking charts until the screen saturates. It starts from a simple question, asked function by function: which decision should this indicator inform? Five broad KPI families structure nearly every SMB ERP we design. Each has its metrics, its reading frequency and its audience. Here they are in the order we scope them in the workshop.

1. Executive management. A synthetic view of the health of the business: cumulative revenue against target, gross margin, order book, available cash and one aggregated alert indicator. The manager must grasp the state of the month in under thirty seconds, without opening five tabs. It is the headline screen, deliberately sober, that drills down to the detail by function.
2. Sales and commercial. Pipeline by stage, conversion rate, average basket, performance by rep and by channel. The goal is to see where deals stall and which actions restart the flow. A pipeline emptying at the top signals a prospecting problem; a pipeline blocked at the bottom signals a closing problem, and the response is not the same.
3. Finance and cash. Customer receivables, average payment delay, overdue invoices, ninety-day cash forecast and recovery rate. This is the function where real time matters most: a receivable tracked day by day is recovered better than one discovered at quarter-end.
4. Operations, inventory and production. Stock level per reference, replenishment thresholds, service rate, work in progress and delivery times. These indicators avoid the two costly extremes: the stockout that loses a sale and the overstock that ties up cash.
5. Human resources. Hours worked, absenteeism rate, workload per team and schedule tracking. On a service or field activity, such as a resort, this area is central: it links the payroll mass to the real activity and makes it possible to adjust headcount to peaks and troughs.

The rule that separates a profitable dashboard from a chart factory fits in one formula: one screen, one decision. Every indicator displayed must be able to trigger a concrete action. If nobody knows what to do with a curve, it has no business on the dashboard. This discipline echoes a rule observed on the web, where concentrating information beats scattering it: structured, focused content grabs the bulk of AI citations, exactly as a focused screen carries the decision.

A concrete example: on a resort we supported, cross-referencing the operations and HR KPIs makes sense because hospitality activity varies sharply with the season and the occupancy rate. Tracking team hours without relating them to occupancy says nothing; the two together reveal whether the payroll mass is aligned with real activity. It is this logic of connected, not isolated, KPIs that makes the value of a custom dashboard against a generic report.

Our dataviz and reporting approach

Designing a good dashboard is as much a matter of business scoping as of development. A successful dataviz is recognized not by its number of colors but by how fast a user finds the information that triggers their decision. Here is the sequence we apply on every steering module, from scoping the business questions to go-live on our Next.js, strict TypeScript, Supabase and Vercel stack.

This steering module is not billed as an extra: it is part of the scope of a custom ERP, whose range runs from 15 000 to 150 000 EUR. A first structuring scope, with two or three business modules and their dashboard, generally fits within EUR 30,000 to 90,000. Delivering in lots makes it possible to ship the data-entry modules first, which feed the data, then the steering that presents it, funding each step once the previous one is in service.

Rights and data security: RLS and roles

A dashboard gives access, by nature, to the most sensitive figures of the business: margins, salaries, cash, individual performance. The question of rights is therefore not a technical detail at the end of the project, it is a design requirement. The principle we apply is least privilege: each user sees only the data strictly necessary to their function, no more, no less. A sales rep sees their pipeline, not the payroll mass; a site manager sees their teams, not those of other sites.

Technically, this rule is carried by Supabase Row Level Security (RLS), the heart of our stack. RLS applies data filtering at the level of the database itself, not only in the interface. Concretely, even if a query tried to bypass the screen, the database would refuse to return the rows not authorized for the connected user's role. This multi-tenant approach also guarantees the watertightness between entities or between clients when a single ERP serves several perimeters. Security is not a layer added on top: it is inscribed in the data.

The second pillar is GDPR, in force since 25 May 2018. An HR or sales dashboard handles personal data, which imposes clear rules: minimizing the data displayed, logging sensitive access, controlled retention duration and the right to erasure. The regulation provides for penalties reaching EUR 20 million or 4% of worldwide revenue, which makes access control a financial issue as much as a technical one. On finance or HR, the traceability of consultations itself becomes a compliance indicator, unreachable with a shared spreadsheet where everyone sees everything the moment they open the file.

A concrete example, on a resort we equipped: a single ERP serves several functions and profiles, from the site manager to management. RLS makes it possible to give each manager their own dashboard, scoped to their perimeter, without accessing the data of other departments or the overall payroll mass. It is this watertightness by role that makes steering diffusable to a wide circle of users without creating a risk on sensitive data.

Concretely, security by role is not a brake on usage, it is what makes the dashboard adoptable. Because everyone finds only their own view, the tool stays legible and nobody feels watched beyond their perimeter. It is also what makes it possible to open steering to more users without risk: a manager can give each supervisor their own dashboard, knowing the partitions hold.

Example: the unified steering of a resort

The dashboard takes on its full meaning in a concrete case. A resort in Thailand that we supported illustrates the most common move among our ERP clients: from a mosaic of spreadsheets to a single consolidated view. Before the project, coordinating operations relied on disparate tools and spreadsheets kept by different people, which made any overall reading slow and fragile. Nobody had, at any given moment, a reliable, shared picture of the resort's activity.

The answer was a custom ERP centralizing the management of operations in a single interface, with modules structured around the teams' real flows. The steering side now gives management and the departments one shared, up-to-date view of the business, where several files previously had to be cross-checked. In a sector where activity varies sharply with the season and the occupancy rate, this unification changes the nature of the decisions: you adjust on today's figures, not on a reconstruction of last week.

Out of a concern for integrity, we publish no quantified metric on this case until it is confirmed by the client: the results are described qualitatively. The lesson, however, transfers to any SMB. Real-time steering is not won by wiring a generic dashboard tool onto exports, but by building the data at the source, function by function, role by role. That is exactly what a free diagnosis helps to frame: identifying your business KPIs, their source and the dashboard that serves your decisions, with a reply within 24 hours and no commitment.