When a Machine Stops, Your Schedule Should Know

Mark an asset critical and its downtime propagates to the work center and consumes available capacity. Leave it non-critical and it does not. The press going down stops the line; the folder going down does not — and the system finally knows the difference.

• Critical asset flag drives capacity
• Downtime rolls up the hierarchy
• Non-critical faults stay informational

Running, setup, idle, down and maintenance, rolled up worst-first so a parent shows the most severe state beneath it. Status changes arrive live and the chip pulses in its new colour, readable from a distance.

• Worst-of rollup with defined severity
• Live push updates
• High-visibility status chips

Calendar for time-based service, runtime hours for wear-based service, and cycle count for throughput-based service. Each plan can carry a step checklist and generate its events automatically.

• Calendar, runtime hours or cycle count
• Step checklists
• Automatic event generation

Marking a scheduled job done creates the completed event, posts the asset transaction, rolls the last-done and next-due dates forward, and notifies anyone watching — in a single action rather than four screens.

• Mark done from the hub
• Ledger and schedule update together
• Live notification on completion

Available capacity is the working calendar times availability, minus planned maintenance, minus current downtime. Utilization is demand over effective capacity, bucketed into clear risk bands. The formula is published, so a planner can check it.

• Published capacity formula
• Risk bands from none to high
• Per-work-center heatmap

Because every stoppage is an event with a cause and a cost, mean time between failures, mean time to repair, downtime hours, repair cost and a Pareto of root causes need no separate data entry — with a toggle to roll up child assets.

• MTBF and MTTR
• Downtime hours and repair cost
• Pareto by root cause