ERP dashboards get used when they answer the questions managers actually have to decide on, with numbers they trust. That means starting from decisions rather than from available data, defining each KPI precisely (owner, formula, source, refresh frequency and target), building every report on one governed data model, and designing pages that highlight exceptions and let people drill down to the transactions behind a figure. The last step is adoption: a dashboard becomes useful when it is the agreed reference in regular management meetings.
Most companies already have plenty of reports. The problem is usually that the numbers differ between them, nobody knows which one is right, and people go back to exporting data into their own spreadsheets. This guide sets out a practical, tool-neutral approach for finance, operations and IT leaders who want ERP reporting that management relies on.
Start from decisions, not data
The usual way to build a dashboard is to connect to the ERP, see what data exists and chart it. The result is a page of interesting figures that nobody acts on.
Reverse the order. For each audience, ask:
- What decisions does this person make regularly? For example, a CFO decides on cash collection priorities and spending approvals; a plant manager decides on shift allocation and maintenance priorities.
- What would they need to know to make those decisions better or earlier?
- Which measures would tell them that, and at what level of detail?
- How often do they make the decision? That sets how fresh the data must be.
- What would they do if a number moved? If the answer is “nothing”, the measure probably belongs in a report, not on a dashboard.
This exercise usually shrinks the KPI list dramatically. An executive page with a handful of well-chosen measures is more useful than one with thirty. Detail can live one click away.
Define every KPI before you build it
A KPI that is not defined in writing will be calculated differently by different people. “Sales” might mean orders, invoices or cash received; it might include or exclude VAT, returns and intercompany transactions. Agree the definition first and the dashboard becomes a matter of implementation, not debate.
Each KPI needs at least five elements:
- Owner: the person accountable for the result and for the definition.
- Formula: the exact calculation, including what is included and excluded.
- Source: the ERP tables, modules or other systems the data comes from.
- Refresh frequency: how often the figure is updated, and when.
- Target: the target or threshold, and what counts as good, watch or act.
KPI definition template
Use a simple register like the one below. The example rows are illustrative; your formulas and targets should come from your own policies and management discussions.
| Field | Example: Days sales outstanding | Example: On-time delivery |
|---|---|---|
| Purpose | Shows how quickly customers pay, to prioritize collections | Shows whether customer orders ship on the promised date |
| Owner | Credit and collections manager | Logistics manager |
| Formula | Trade receivables ÷ credit sales for the period × days in the period | Order lines shipped on or before the promised date ÷ all order lines shipped |
| Inclusions and exclusions | Excludes intercompany balances; amounts excluding VAT | Excludes customer-requested delays |
| Source | ERP receivables and sales invoice data | ERP sales orders and delivery records |
| Refresh | Daily, overnight | Daily, overnight |
| Target and thresholds | Set by finance policy, with watch and act levels | Set by operations, with watch and act levels |
| Drill-down | By customer, salesperson, ageing bucket, invoice | By customer, warehouse, product, order |
Keep the register alongside the dashboards, give it an owner, and change a definition only through an agreed process. The register is also what new managers and auditors will ask for.
Example KPI families by function
The table below lists common KPI families as illustrative starting points, not a recommended set. Choose from it only where a measure supports a real decision.
| Function | Example KPIs | Typical drill-down |
|---|---|---|
| Finance | Revenue and gross margin, operating expenses against budget, cash position, receivables ageing, days sales outstanding, payables ageing | Entity, cost center, account, customer, supplier |
| Sales | Orders and invoiced sales against target, pipeline, quotation conversion, average order value, discounts given | Region, salesperson, customer, product |
| Inventory | Stock value, inventory turnover, slow-moving and obsolete stock, stock-outs, stock accuracy from counts | Warehouse, item category, item, batch |
| Production | Output against plan, schedule adherence, scrap and rework, equipment effectiveness, work orders past due | Plant, line, shift, product, work order |
| Procurement | Spend by category and supplier, purchase order cycle time, supplier on-time delivery, price variance | Category, supplier, buyer, purchase order |
For ERP-heavy industries such as manufacturing, project-based work may add a project family: budget against actual cost, committed cost, billing against milestones and margin by project.
Build on a single source of truth
Dashboards fail most often because of what sits underneath them. If each report pulls raw ERP data and applies its own logic, the same KPI will show different values on different pages, and trust disappears quickly.
A governed data model solves this:
- Extract once, define once. Data is loaded from the ERP and other sources into a shared model where business rules, such as revenue recognition, currency conversion and VAT handling, are applied in one place.
- Shared dimensions. Customers, products, sites, cost centers, projects and calendars are defined once and reused by every report, so slicing by region or product works the same everywhere.
- Measures defined centrally. KPI calculations live in the model, not in individual charts. In tools such as Power BI, that means shared semantic models and measures rather than copies of the logic in every report.
- Reconciliation. Key figures such as revenue, receivables and inventory value are reconciled to the ERP’s own reports, so finance can confirm the dashboard matches the books.
- Clean master data. Duplicate customers, inconsistent item categories and missing cost center mappings will appear on every dashboard. Fix them at the source in the ERP, not with workarounds in the report.
Design for exceptions and drill-down
Managers do not have time to study every chart. Good dashboard design directs attention to what needs action.
- Layer the pages. Start with a summary page for each audience, a second level by function or business unit, and a detail level down to transactions. Each level answers the question raised by the one above it.
- Highlight exceptions. Use the thresholds from your KPI register to flag items that are off track, such as overdue receivables above a limit or work orders past due. Color should mean something; avoid decorative red and green.
- Show context. A number without comparison is hard to judge. Show target, prior period or trend alongside the current value.
- Make drill-down predictable. Clicking a figure should lead to the customers, products or orders behind it, and finally to the ERP document itself. When people can verify a number, they trust it.
- Use alerts sparingly. Scheduled emails or alerts for breached thresholds help, but too many become noise. Agree which exceptions justify an alert and who receives it.
- Design for the device. If managers review figures on a phone or in a meeting room, design layouts for those settings, and support Arabic labels and right-to-left layouts where your audience needs them.
Refresh latency and row-level security
How fresh does the data need to be?
Real-time data sounds attractive, but it adds cost, load on the ERP and complexity. Match the refresh frequency to the decision.
| Refresh approach | Suits | Trade-offs |
|---|---|---|
| Daily or overnight | Most management and finance KPIs | Simple and stable; figures are as of the last load |
| Several times a day | Sales, order backlog, warehouse activity | More load on source systems; refresh windows need monitoring |
| Near real time | Production lines, dispatch, live operational screens | Requires direct query or streaming design; higher cost and performance tuning |
Whatever the schedule, show the time of the last refresh on every page and alert the support team when a refresh fails. A dashboard that silently shows stale data loses trust quickly.
Row-level security
Different people should see different data. A regional sales manager sees their region; a plant manager sees their plant; the executive team sees everything. Row-level security applies these rules inside the data model, so one dashboard serves many audiences without copying reports.
Base access on roles that mirror your organization and ERP permissions, review them when people change jobs, and test them with real user accounts before rollout. Salary, payroll and other personal data need particular care; confirm your obligations under the Personal Data Protection Law with your legal and compliance advisers.
Make dashboards part of the meeting rhythm
Launch emails and training sessions do not create adoption. Usage follows when the dashboard becomes the agreed reference for regular decisions.
- Tie each dashboard to a meeting. The weekly sales review, monthly operations review and month-end close discussion should each run from a specific dashboard page, displayed on screen.
- Retire competing reports. If the old spreadsheet still circulates, people will keep using it. Agree a date to stop producing it.
- Assign owners who explain the numbers. Each KPI owner comes prepared to explain movements and actions on the exceptions shown.
- Collect and act on feedback. Keep a short backlog of requested changes, review it regularly, and remove pages nobody opens. Many BI tools provide usage metrics that show which pages people open.
- Train people to self-serve. Show key users how to filter, drill down and export, so simple questions do not become report requests.
Common mistakes
- Building from available data. Charts of whatever the ERP holds, rather than measures tied to decisions.
- Too many KPIs. If everything is a key indicator, nothing is. Keep summary pages focused.
- Undefined metrics. Without an owner and written formula, figures will be disputed in the first meeting.
- Logic in every report. Duplicating calculations across reports leads to inconsistent numbers. Centralize them in the data model.
- Ignoring data quality. A polished dashboard on poor master data simply shows poor data more clearly.
- Real time by default. Paying for real-time refresh where daily data would support the same decision.
- Security as an afterthought. Adding access rules after rollout risks exposing sensitive data and forces redesign.
- No ownership after launch. Dashboards drift as the business changes. Someone must maintain definitions, refreshes and access.
Frequently asked questions
How many KPIs should a management dashboard have?
There is no fixed number. Include only the measures that support decisions this audience makes regularly, keep the summary page short enough to review in a meeting, and move supporting detail to drill-down pages.
Should we use Power BI or build dashboards into the ERP?
Built-in ERP dashboards suit operational views within one system. A BI tool such as Power BI suits management reporting that combines the ERP with other sources, needs a shared data model and requires row-level security across many audiences. Many companies use both, with each KPI defined once.
Can dashboards show real-time ERP data?
Yes, through direct query or streaming designs, but it adds cost and load on the ERP. Use near-real-time data for operational decisions that need it, and scheduled refreshes for most management KPIs.
Why do our dashboards show different numbers from the ERP reports?
Usually because definitions differ (for example, invoiced versus ordered sales, or amounts with and without VAT), filters differ, or data was loaded at a different time. A written KPI register, a central data model and regular reconciliation to the ERP’s own reports resolve most of these differences.
Who should own the dashboards?
The business owns the KPIs and their definitions; IT or a BI team owns the data model, refresh, security and performance. Both need named owners, and changes to definitions should go through an agreed approval step.
Building dashboards your team will use
AIMLTS builds live dashboards, financial and operational reports, and the governed data models behind them, pulling from your ERP, databases and cloud tools, with Power BI and custom-built dashboards, role-based access and training so people can self-serve. Learn more about our Dashboards & Reporting and ERP Solutions services, or book a discovery call to discuss your reporting.