Important general rules discussed in this document that everyone should be aware of when creating dashboards:
[ReasonState] is the preferred metric when dealing with downtime/slow running/micro stoppage/etc. reasons. This means this is preferred over [Reason] metric.
99% of customers will ever only use filters at Dashboard or Widget levels. However, there is technically a way to add a filter directly on a formula within the Formula Editor. SLX development team already built out all common formulas and they are now Saved Formulas. Many of these Saved Formulas use filters directly
Continuous Improvement Dashboard
Fixed formula: Total Scheduled Downtime Hours
Widget affected:
Previous incorrect:
Updated: filtered correctly for downtime state
FORMULA:
([Total Scheduled Hours], [ReasonState Type])
THEN: click on the blue [ReasonState Type] field > Filter > by only Downtime
Fixed formula: Total Downtime Hours
Widget affected:
Previous incorrect:
Updated: filtered correctly for downtime state
FORMULA:
([Total Total Hours], [ReasonState Type])
THEN: click on the blue [ReasonState Type] field > Filter > by only Downtime
Updated metric: ReasonState Group
Widget affected:
Previous incorrect:
Updated: changed [Reason Group1] to [ReasonState Group1]
What does this mean?
Have been informed that our customers prefer the behavior of ReasonState over Reason.
Reason = show only reasons
State = show only states
ReasonState = show reasons when available. When not available (operator did not enter a reason), then show the state
Updated table: fixed columns that were not accurate
Widget affected:
Previous incorrect:
Updated:
Columns:
ReasonState
ReasonState Occurrences
Total Scheduled Hours
Total Hours
Updated table: fixed columns that were not accurate
Widget affected: DASHBOARD-LEVEL FILTERS
Updated:
Removed anything related to either Reasons (ReasonState, Scrap Reason, Reason Group, etc.)
Rationale:
The dashboards do not appear to filter well when there are Reason or State-type filters at dashboard filter level (scrap reasons, downtime reasons, state reasons, state, reasonstate, etc.)
It is highly recommended that customers who need to filter by these should do it at widget-level
Rule of thumb for deciding when to use Dashboard vs. Widget-level filters:
Dashboard filters should stay limited to “anything not directly related to a machine’s recorded status/state/issues”
Examples of safe dashboard filters: Machine Name, Area, Plant, Shift, Calendar DateTime, Job Name, Job Filter x, etc.
Widget filters are where you can better isolate your filtered data at machine’s “activity” level
Examples of safe widget filters: ReasonState, Scrap Reason, etc. along with any other filter (Date, Shift, etc. these are always safe)
Executive Dashboard
Substantive overhaul on dashboard layout and widgets