Machine connectivity is the easy part now. Protocols are open, hardware is cheap, and most modern equipment will happily publish more data than anyone will ever look at. The hard part is that the data changes nothing.
A number is not a decision
An availability figure of 78% tells a supervisor nothing they can act on before the end of shift. What they can act on is: this station stopped eleven times today, nine of them were the same infeed jam, and it cost forty minutes.
Design backwards from the decision
Start by asking who looks at the screen, at what moment in their day, and what they are allowed to change as a result. Build the view for that. Everything else is an export, not a dashboard.
Downtime reasons have to be cheap to record
If categorising a stoppage takes an operator more than a couple of seconds, the data will be wrong within a fortnight. Pre-populate the likely causes, make the common ones one tap, and accept a short list over a complete taxonomy.
- Name the decision the screen supports before designing it
- Show causes, not just percentages
- Make downtime reason capture a single tap
- Put the screen where the decision is made, not in an office
- Review it after a month and delete what nobody used
