A manufacturing production dashboard should explain what is happening on the line and where an operator or supervisor can act. Output totals alone rarely show whether a delay comes from material shortages, planned changeovers, equipment faults or missing data. Begin with the decisions made during a shift, then define the events required to support them.
For a hypothetical assembly line, a slower hour might be expected during a product changeover. Treating every reduction as a machine problem can send the team toward the wrong response. Context belongs beside the chart.
Agree the production event model
Define the difference between started, completed, accepted and rejected units. Record rework separately where it changes the interpretation. Specify which system or station supplies each event and how duplicates are detected.
The MTConnect data item model is a reference for structured machine observations. A business dashboard still needs a reviewed mapping from those observations to its production process; an equipment signal does not automatically explain an operational cause.
Define shifts and comparison periods
Use the plant's actual timezone, shift calendar and planned breaks. Decide how events that span a shift boundary are assigned. Keep the original event timestamp available for reconciliation.
Compare like-for-like conditions where possible. Product mix, staffing and planned maintenance can change expected output. Avoid presenting a target for one product as a universal measure of another line's performance without the necessary context.
Make downtime reasons usable
Separate observed equipment state from a confirmed reason. An unavailable machine may require an operator to classify the event after inspection. Provide a short, agreed reason list and a path for unknown cases.
| View | Useful operational question |
|---|---|
| Current line state | Is the signal current and trustworthy? |
| Output against plan | Which product and shift are included? |
| Downtime review | Which events need a reason or correction? |
| Quality result | Which units were inspected and accepted? |
Keep manual corrections traceable without turning the interface into an overwhelming event log.
Check the reporting model
Machine events, production orders and quality checks may have different grains. Microsoft's star schema guidance offers a modelling reference. Our recommendation is to validate small sample orders through every join before trusting aggregated totals.
For example, one unit may have several inspection attempts. Counting inspection rows as finished units inflates output. Define whether the report uses the first attempt, final disposition or a separate inspection metric.
Show missing coverage honestly
Display the last event time and the status of each source. A disconnected adapter should appear as missing information rather than as a perfectly idle machine. Give supervisors a fallback process for confirming current conditions.
Pilot with the people who use it
Review a normal shift, a changeover, a fault and a late correction with operators and supervisors. Ask whether the dashboard leads to a supported action and whether its totals reconcile with trusted records. Keep any productivity example hypothetical until measured in the actual plant.
Use a short event walkthrough during that review. A hypothetical operator can select one production order, follow its start and completion records, and explain a planned changeover between batches. The reviewer then checks whether the chart attributes that period consistently with the agreed shift calendar. If a reason is corrected later, verify that both the updated summary and the original evidence remain understandable. This reveals problems that a large daily total can conceal.
Read the metric definition guide and computer vision quality control guide, or explore data and dashboards to scope a production view with clear evidence.