Illustrative sample. The plant, the weeks and the footage are synthetic.
Approved fixes get an update every week. Paused, Declined and Done do not. In this sample the weekly reports are already written, so changing a status here does not change them.
We watch how often the eight worst molds stop a press mid-run, from the press cameras and the ERP downtime log. Target: about 4 stops a week.
Extra profit a year once this is running, after what it costs to run. Profit, not revenue.
Times a week a mold quits mid-run for a broken part or a cleaning it never got. Those recovered press hours are capacity, not cash, until sales fill them.
Capex
$18,000
Payback
4 months
Difficulty
2 / 5
Time to implement
~10 weeks
This plant molds plastic parts on about 26 injection presses, and the tool that shapes each part is the mold, a precision steel block the melted plastic is forced into under high pressure.
Run a written mold-maintenance program off shot count, not the calendar, so worn tools get serviced before they make scrap.
The math
0.225 points × $120,000
500 hrs × $55/hr
$27,000 + $27,500
Deep dive
A maintenance program removes the scrap and downtime that come from worn or dirty tools. If the defects are really coming from an unstable process, cleaning and servicing the tool does not remove them.
Flash or shorts return within a run of a freshly serviced tool, and the scrap codes are dominated by process faults (shorts, sink) rather than tool faults (flash, drag).
Sort the scrap codes before you start, and hand the process-driven scrap to the scientific-molding card.
Most of the scrap half of the value, about $27K.
Half the value is recovered mold downtime. If the plant has no backlog to load onto the freed presses, those hours stay idle and never become margin.
Molds stop breaking mid-run and uptime climbs, but the schedule has gaps and the extra hours run nothing.
Treat the downtime half as capacity, not cash, and pair it with a sales plan to fill the hours; bank the scrap half, which does not depend on demand.
The downtime half of the value, about $27K.
Shot-count logic only works if service fires off the counter. Left to memory, PM slides to changeover-only cleaning and the worn-tool scrap creeps back.
Overdue PMs pile up, tools get cleaned only at changeover, and nobody can name the current shot count on a tool.
Automate the triggers off the shot counter and tie a monthly supervisor review to overdue-PM count.
The whole $55K erodes back toward the starting point over a year or two.
Without wear-part spares stocked, a broken ejector pin or spring means an emergency order and a high-runner press sitting idle for days while the part ships.
Emergency spare-part orders, jobs bumped off the schedule, and a press down waiting on a $40 pin.
Min/max stock the common wear parts on the top tools so a break is a shelf part, not an order.
Days of lost press time per event, plus late shipments to customers.
A tool that only gets attention when it fails has already made a run of scrap and idled a press before anyone touches it. An emergency repair costs several times the same repair done on schedule (you pay for the rush, the overtime, and the bumped jobs), and the run that was in the press when the mold let go is usually scrap. A shot-count program moves the work to before the failure: you service the tool while it is still making good parts, on a schedule tied to how hard it has actually been run.
Two tools both "serviced in March" can be in completely different shape by June if one ran three shifts and the other sat. Calendar maintenance services the tool that sat and misses the one that is worn out. A shot counter measures the thing that actually wears a tool, cycles, and triggers service off that. Set the milestones by the steel and the resin: a hardened tool running an unfilled commodity resin goes far between services; a softer tool running a glass-filled resin (the glass fiber is abrasive and eats steel) needs attention much sooner.
The history record ties it together. Once you know a tool's shot count and what it throws, you can set intervals from data instead of guesswork, and make a rebuild-versus-replace call before the tool fails, not after.
You cannot scientifically mold or shorten a cycle on a worn, flashing tool. A cavity-pressure sensor (which reads the plastic pressure inside the mold) only means something if the same tool makes the same shot twice, and a worn tool does not. That is why this card lands before scientific molding and cycle time: it is the cheapest one here and it is what makes the expensive ones possible. And restoring a tool to its approved condition is maintenance, not a process change, so it does not trip a customer re-validation (PPAP) and can start immediately, on every tool, without waiting on anyone's sign-off.
The records we did not have for this read and would ask for on day one. Each one replaces an estimate on this card with your own number.
To confirm how much of the scrap and unplanned downtime is tool-driven (flash, drag, dropped parts) versus process-driven, and to rank which tools carry the pain. This one dataset decides whether the card is worth building and which tools to start on.
To know which molds have working counters and which need one, and to set the first service intervals. Without shot counts the program has nothing to trigger off.
To size the starter spares shelf and see how much is going to emergency repairs today, which is the money the program takes back.
To find out whether the tool-history and PM triggers can run on software already paid for, the cheapest path, before buying a CMMS or ProShop.