You Find Out You Passed the Service Interval When the Parts Start Failing
Preventive maintenance due every fifty thousand shots is scheduled on a calendar, in a system that has never been told how many shots the machine has run. Maintenance is not a cost centre attached to a factory. It is a constraint on the plan, and treating it otherwise is why the plan misses.
· 6 min read · Written by Faceela Research & Editorial Team
A mould is due for preventive maintenance every fifty thousand shots. The maintenance plan says every three months. In a quiet quarter the service happens early and wastes a day; in a busy one the interval passes unnoticed and the factory finds out when parts start failing inspection — after which it has scrap, an investigation, a quarantine decision on everything made since the last good check, and unplanned downtime in the middle of a committed order.
Two things are wrong and they are separable. The first is that the interval is measured in cycles and the plan is measured in time, so the two only coincide by accident. The second is that maintenance is modelled as a cost rather than as capacity, so the plan schedules straight through the window and the resulting miss is attributed to production. Fixing the first requires the machine's counter to reach the system. Fixing the second requires planned maintenance to appear in the capacity calendar as unavailable time before the schedule is built.
Three kinds of interval, one invisible cost, and a tooling problem that sits in nobody's module — that is the rest of this piece.
Three kinds of interval, and only one of them is a date
Calendar. Every three months, every year. Correct for things that degrade with time — seals, fluids, calibration, statutory inspection. It is also the only kind most maintenance modules are configured for, because it is the easiest to set up.
Usage. Every fifty thousand shots, every thousand running hours, every so many kilometres or metres or tonnes. This is what actually governs wear on the machines that matter, and it requires a counter. The counter may come from the machine, from the production declarations, or from a meter reading somebody enters weekly — all three work, and the third is far better than nothing.
Condition. Triggered by a measurement: temperature, vibration, a dimensional check drifting towards tolerance. The most valuable and the most demanding, and worth doing on the small number of assets where a failure stops the factory rather than a line.
The practical point is that a maintenance plan should carry whichever of the three is shortest, evaluated continuously, rather than whichever was easiest to configure. A factory that converts every usage interval into an estimated calendar equivalent is guessing at its own utilisation, and the guess is worst exactly when the machine is busiest — which is when a failure costs the most.
If counters cannot reach the system automatically, take the weekly manual reading. It is imprecise and it is enough. The failure mode being avoided is not an interval missed by five per cent; it is an interval missed by half because a machine ran double the expected volume.
Downtime that nobody records did not happen
Ask a factory how much unplanned downtime it had last month and you will usually get an estimate. Ask which assets caused it and you will get names of the two everybody complains about, which may or may not be the two that cost the most.
Downtime becomes measurable when a stop has a start, an end, an asset and a reason, and when recording it is quick enough that it happens during the stop rather than afterwards. Three design points decide whether that happens:
A short reason list, for the same reason a scrap reason list has to be short — the person recording it is holding tools. The vocabulary can be extended later from the catch-all, provided somebody reviews the catch-all weekly.
A distinction between the stop and the repair. The machine was down for four hours; the repair took forty minutes and the rest was waiting for a part or a person. Those are different problems with different fixes, and merging them sends every improvement effort towards the wrong one. Waiting is usually the larger share and is usually a spares or a staffing decision.
Attribution to the asset, not to the line. A line's downtime is an aggregate; a spares policy needs the asset.
With those, the maintenance argument becomes arithmetic rather than advocacy: this asset caused this many hours, those hours cost this much in lost output, and the preventive regime costs less. Without them, maintenance spend is negotiated on the basis of who is most persuasive, which is how it ends up cut in exactly the year it should have risen. The same before-and-after discipline applies here as to any other spend with a claimed return, and it is set out in measuring what a change actually saved rather than asserting it.
Maintenance is capacity, and the plan has to know
This is the connection most factories have not made, and it is nearly free to make.
If planned maintenance windows are not in the capacity calendar, the schedule fills them. Then one of two things happens: the maintenance is deferred, which is how usage intervals get missed, or it happens and the schedule misses, which is recorded as a production shortfall. Both outcomes teach the organisation that maintenance and production are in conflict, when the actual problem is that only one of them was given time in the plan.
Putting the windows in the calendar before the schedule is built converts an argument into a constraint. It also makes the trade-off explicit at the right moment: when a customer order genuinely justifies deferring a service, that becomes a decision somebody takes with the interval in front of them, rather than a thing that happens by default. This is one of the four inputs that decide whether finite capacity scheduling produces anything usable, alongside routings that describe the machine as it is now.
The tooling problem next door
A related gap that costs real money and sits in nobody's module. Moulds, dies, jigs and fixtures are assets that wear, need maintenance on usage intervals, and are frequently owned by the customer and stored at your factory — where the only record of them is that everyone knows where they are.
Each of those is a liability. A customer's tool damaged in your care is a commercial conversation you want records for. A tool due for refurbishment that nobody is counting shots on is the same failure as the machine, with the added difficulty that it moves between presses. And a tool that cannot be found quickly is a changeover that overran for a reason that will never appear in any report.
The fix is unglamorous: tools are assets with a location, an owner, a usage counter and a maintenance plan, exactly like machines. Most systems can do this the day somebody decides to. It also closes a certification gap, since the record of which tool made which batch is part of the chain relied on in tracing a batch and answering for it within two days.
Where to start
Take the three assets whose failure stops the most output. For each: find the real interval basis, get a counter to the system by whatever means, put the window in the capacity calendar, and start recording stops with a four-item reason list. That is a fortnight of work and it will produce an argument about spares within a month, which is the point.
Everything above is configuration and discipline rather than development, and it is the part of a manufacturing implementation most often deferred to a second phase that does not arrive — which is the sequencing failure described in the order a manufacturing system has to be built in. Deciding what your own factory should do first belongs in the diagnosis stage of a project scoped before it is priced rather than in its second phase, because the three assets above are usually the reason the first phase was funded.