The Monday report: downtime, MTBF, MTTR and PM on time

Why it matters

A downtime report assembled by hand has two problems. It is late, so the decision it should inform was made without it. And it is soft: the hours are estimates, the reasons are whatever the technician remembered at closing time, and nobody can say which machines the numbers cover. A report that is built from timestamps made at the moment of the stop, that names its own basis, and that is ready on Monday morning changes what the meeting is about.

How it works in LK Up

1. The data is made on the floor, not in the office. A stop is stamped when an operator ticks Is the machine stopped? on a report or a technician presses Machine stopped on the asset, with a reason from your list; Machine running again ends it. Work orders carry their labour, parts and problem codes. The report reads these; nobody fills in a form for it.
2. Open Reports, pick a period and a site. This week, this month, this quarter or a custom range. Every block below says what it is based on ("Based on 4 stops; 2 are still ongoing and count up to now").
3. Downtime by reason and by machine. Hours and stops per reason (breakdown, changeover, your own reasons), or per asset, top ten. A reason marked Planned downtime in Settings counts as a planned stop and does not lower availability.
4. Reliability. Failures, MTBF, MTTR and availability for the period and site, then per machine, with the Top problem codes from the closed work orders. Breakdowns count; planned stops do not.
5. PM on time, parts, people. On time, late, still open past due. Parts consumed and stale stock. Labour hours and costs by machine. Technician load for this week and the next three, from hours per week and the roster. Did it help? by machine and technician. Spend by month and, if you book costs, Budget against GL codes.
6. Take it to the meeting. Export as CSV, PDF or Excel on any block takes exactly what it shows. A saved report from the report builder can be mailed every week or month as a PDF and a CSV to the people you choose, in each person's language.
7. Your own cut of the data. The report builder picks the data (work orders, downtime, parts movements, labour, requests, assets), filters it like its list, groups by up to two things (machine, category, person, month…), measures a count, sum or average and shows a table, bars or a line. Save it, share it with the managers of a site, put it on a dashboard.

Why we built it this way

• Every block names its basis. "Availability 94%" means nothing until you know it is based on four stops, two of them still running. A number without its denominator is how reports lose arguments; so each block carries one.
• Planned stops are a flag on the reason, not a separate system. A changeover is downtime for production and not a failure for maintenance. Marking the reason planned keeps both reports honest from one set of stamps.
• The stamp is made by the person who saw it. The operator who ticked "stopped" at 14:07 is the only accurate clock. Asking the technician for the duration at closing gives you 2 hours, 4 hours, half a day.
• Parts count as spend when received, labour when logged. The budget block and the spend block say so in their notes, and they deliberately differ (spend by month counts only receipts against purchase orders), because the two questions are different: what did we commit, and what did we take off the shelf.
• Reports read the data on the device. They work offline on a manager's laptop in a meeting room with no Wi-Fi; online, the reliability figures are checked against the server's.

What it does not do

LK Up does not measure the machine itself: a stop is what a person recorded. It does not compute OEE, because it has no production counts. The planned link to LK On, the touchscreen that logs machine stops and alarms, would bring the machine's own view in. The full list of blocks and the report builder: chapter 12 of the user manual.