The Dashboard Is Green. Are Teams Looking at the Same Operational Truth?
Dashboards create value only when teams agree on the population, timing and transaction meaning behind each KPI—not when every department publishes its own green chart.
The short answer
A green dashboard is not evidence of shared truth. Two teams can use the same Epicor database and still report different on-time delivery, inventory, backlog or margin because they use different populations, timestamps, status rules or exception logic.
Epicor Grow and Kinetic reporting capabilities can connect and visualize data. The harder management work is agreeing what each metric means before it becomes a chart.
Begin with the decision, not the visualization
Every KPI should exist because somebody needs to make a decision.
Write that decision first:
- Which orders need intervention today?
- Which inventory is actually available to promise?
- Which jobs threaten customer delivery?
- Which customer balances require action?
- Which plant is consuming margin through exception cost?
Then define the metric required to support that decision.
A dashboard built without a decision tends to become a collection of interesting numbers.
Define the population precisely
“On-time delivery” sounds simple until teams ask:
- order line or shipment?
- requested date or promised date?
- original promise or latest accepted promise?
- partial shipment counted how?
- cancelled orders included?
- customer pickup treated how?
- timezone and cut-off?
The formula is less important than the agreement.
Record the definition beside the KPI so a future report builder does not create another version.
Decide which event owns the timestamp
ERP data contains many dates: order date, request date, promise date, release date, production completion, ship date, invoice date.
Choose the transaction event that represents the business question.
If warehouse shipment is posted at the end of the shift rather than at dispatch, the dashboard may measure posting discipline rather than delivery performance.
This links analytics directly to point-of-work execution.
Make status semantics explicit
Words such as open, complete, available, committed, late and shipped are often operational shortcuts.
Turn them into rules.
For example, “available inventory” may need to exclude quality hold, allocated stock, expired material or stock at another site depending on the decision.
If the definition lives only in one analyst's SQL, the organization has not truly agreed the KPI.
Preserve exception visibility
Averages hide operational problems.
A useful dashboard should let managers move from the aggregate to the population causing the result.
If on-time delivery falls, users should see the affected orders and reason categories. If inventory accuracy is poor, they should see warehouses, items or transaction types driving adjustment.
Analytics should shorten the path from signal to action.
Use Epicor Grow as a governed BI layer
Epicor describes Grow as a cloud BI platform able to connect, transform and visualize data from multiple sources. That can be valuable when the management question crosses Epicor and external systems.
But connecting more data increases the need for governance.
Define:
- source system of record;
- refresh timing;
- transformation ownership;
- calculation owner;
- security;
- data-quality checks;
- version control for metric logic.
A powerful BI tool cannot decide which business definition is correct.
Reconcile finance and operations intentionally
Operational data often moves before financial recognition.
A job may be physically complete before labor is fully posted. A shipment may occur before invoicing. A purchase commitment may exist before AP liability.
Rather than forcing the figures to match at every moment, explain the bridge between them.
Management gains confidence when it can see why operational and financial views differ and when they should converge.
Build one KPI dictionary
Create a shared dictionary containing:
- KPI name;
- management question;
- owner;
- formula;
- population;
- included/excluded status;
- time basis;
- source fields/tables or governed semantic layer;
- refresh rate;
- exception drilldown;
- change history.
Treat changes to a high-impact KPI like process changes, because they alter how managers interpret performance.
Use dashboards to expose process latency
One of the most useful measures for mature Epicor users is not only outcome but delay.
Examples:
- physical receipt to ERP receipt time;
- production completion to labor/material final posting;
- service completion to billing readiness;
- shipment to invoice;
- approved change to updated forecast;
- month-end transaction to consolidated reporting.
Latency identifies where operational truth is waiting to enter the system.
That idea connects directly to the pillar Epicor Is Live. Where Does the Next Operational Gain Come From?.
ACC's role in reporting and data alignment
ACC's Epicor services include reporting, integration and process improvement. In practice, useful reporting work often starts before the report itself: agreeing the process event, authoritative source and management definition.
ACC can help existing Epicor users rationalize those definitions and build the supporting reporting or integration layer, while Epicor Grow or other approved analytics tools provide the visualization environment.
Establish a metric change-control process
KPIs evolve. Customer promises change, business units are acquired and management may decide that an old calculation no longer supports the decision.
Allow definitions to change, but record the effective date, owner, reason and impact on historical comparison. Without that record, a trend can appear to improve simply because the formula changed.
Test a KPI from dashboard back to transaction
Choose one visible number and trace it all the way to source transactions. Confirm that users can explain which orders, jobs, shipments or inventory records create the result.
Then reverse the test: pick one underlying transaction and verify that it appears in the expected metric population. This two-way test often exposes exclusions, duplicate joins or timing assumptions that chart review misses.
Distinguish management signal from audit report
A daily operational dashboard may tolerate near-real-time data and action-oriented grouping, while a statutory or audited report requires controlled period logic and formal reconciliation.
Do not force one dataset to serve every purpose without declaring the differences. The same Epicor environment can support several reporting views as long as the business meaning and authority of each are explicit.
Publish definitions where users can see them
Do not keep KPI logic only in developer documentation. Give managers a concise definition beside the dashboard or in a shared metric catalogue: what is included, when it refreshes and which exceptions matter.
When users challenge a number, the first conversation can then be about the underlying transactions rather than about which hidden formula was used. Transparency increases trust even when the metric is uncomfortable.
Review dashboards after process changes
A new warehouse workflow, service process, acquisition or global template change can invalidate an old metric without breaking the report technically. Add reporting impact to process-change checklists.
A dashboard that still refreshes successfully can still be wrong for the new operating model. Periodic semantic review is therefore as important as technical availability.
Give every exception an owner
A dashboard can show a red condition without improving anything if nobody owns the next action. For each major KPI, define who investigates exceptions, how quickly they should respond and where the resolution is recorded.
This keeps analytics connected to operations. The value of the chart is not the colour; it is the speed and quality of the decision that follows.
Keep manual overrides visible
Some management numbers legitimately require judgement, but manual adjustments should be explicit. Record who changed the value, why, when it expires and whether the underlying Epicor transaction will eventually replace it.
Hidden spreadsheet overrides create a second truth. Controlled overrides make uncertainty visible without pretending the data is more precise than it is.
Frequently asked questions
Should all management reporting come directly from Epicor?
Not necessarily. Some questions combine Epicor and external data. The key is to define source ownership and transformations so the result remains explainable.
Why do two reports disagree when they use the same ERP?
They may use different filters, dates, statuses, joins, refresh times or definitions. Compare the business logic before comparing chart design.
How many KPIs should a plant dashboard contain?
Use the few that drive daily decisions, then provide drilldown. More measures are not automatically more control.
Can Epicor Grow replace data governance?
No. It can connect and analyze data, but the organization still needs shared definitions, ownership and quality rules.
Can ACC help rationalize Epicor reports?
Yes. ACC supports Epicor reporting, integration and operational process work and can help consolidate duplicate definitions before rebuilding dashboards.
One definition is more valuable than one more chart
Existing Epicor users often have enough reporting technology. The larger opportunity is reducing the number of competing truths.
When a KPI has one owner, one definition and one path to the underlying transactions, a dashboard becomes a management tool instead of a reporting argument.