A Preventive Maintenance Program a Small Food Plant Will Actually Run

Every food plant we walk into has a maintenance program. It's usually in a binder, it was usually written by the equipment vendor or a consultant three years ago, and it's usually not being run. Nobody's lazy — the program was built for a plant with a maintenance department, and this plant has one tech and a shift lead who's handy.

The program that gets run is the one that fits the crew. Here's how to build that one.

Start with what's actually broken

Don't start with the equipment manuals. Start with the last twelve months of downtime — even if it's only in people's heads. Sit the operators and the tech down and list every stop that cost more than an hour: what broke, on which machine, what it took to fix, and what it cost in lost production. You'll get twenty or thirty items. Rank them by cost.

Most plants find that the top five items account for well over half the downtime — and that they're the same five things, repeating. A bearing that goes every four months. A seal that fails on a specific SKU. A sensor that drifts in the summer. The PM program starts as five recurring tasks that prevent five recurring failures. That's it. Everything else is added later, if the data says so.

Criticality, not completeness

A vendor's PM schedule covers everything on the machine because the vendor doesn't know your plant. You do. Sort your equipment into three groups:

• Stops the line. Single point of failure, no workaround, long repair. These get real PM: scheduled inspections, condition checks, spares on the shelf.
• Slows the line. Failure hurts but you can limp. These get lighter PM and a spares plan.
• Annoying. Failure is a nuisance. Fix on failure. Don't spend PM hours here.

Be ruthless about group three. A program that asks a two-person crew to inspect forty items monthly will be abandoned by month two. One that asks for eight items on the critical machines will still be running next year.

Spares: lead time is the whole game

The question isn't "what might fail" — it's "what can't I wait for." For every group-one component, find the actual lead time. Not the catalog's; call and ask. Anything over a week that stops the line goes on the shelf. Anything you can get overnight doesn't. This usually produces a spares list of fifteen to thirty items and a one-time cost of a few thousand dollars — which is roughly what one unplanned shift costs.

Label the spares. Put them where the tech can find them at 2 AM. Write the part number on the machine next to where it goes. This is unglamorous and it's half the program.

The schedule that survives

Weekly and monthly tasks, tied to a calendar someone actually looks at, with a checkbox. Not a CMMS — not yet. A laminated sheet on the machine or a shared spreadsheet is fine for a small plant, and it has the enormous advantage of being visible to everyone. Each task fits on one line: what to check, what "good" looks like, what to do if it isn't. Ten minutes each. The tech can do the week's PM in an hour, and the shift lead can cover when the tech is out.

The trap here is ambition. A program with quarterly teardowns and annual overhauls is a program for a plant with a maintenance manager. If you don't have one, build for the crew you have and grow the program as the crew grows.

Corrective work: fix the cause, not the part

When something breaks, the pressure is to swap the part and run. Sometimes that's right. But if the same part has failed twice, the part isn't the problem — alignment, load, contamination, or a design issue is. The second failure is the signal to stop and find the cause. A twenty-minute root-cause conversation at that moment saves the third, fourth, and fifth failures. Build it into the program: any repeat failure triggers a why, not just a fix.

Keeping it alive

Programs die when nobody looks at the data. Put a fifteen-minute review on the calendar every quarter: What broke? Was it on the list? Did the PM catch it or miss it? What's the new top five? Add or drop tasks based on the answers. A program that gets revised is a program someone's running — we've built one for a confectionery client that's now in its third annual revision, and the revisions are the proof.

What this costs and returns

Building the program — failure history, criticality sort, spares list, schedule, one-page procedures, training — runs a few weeks of engineering time for a small plant, plus a few thousand in spares. Against that, most small food plants are carrying 15–25 hours a week of unplanned downtime. At even a modest line value, the program pays back in the first quarter and keeps paying.