Injection Molding Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope on a molding build blow out so often?

The pattern repeats. The plant needs cavity level scrap, live job costing and a tool shot counter. Somewhere in week three, someone points out that quoting is broken too, and that the customer portal would win work, and that maintenance is on a whiteboard, and that if we are touching costing anyway we may as well fix the routings in the enterprise resource planning system. By week nine nothing has shipped and the process techs have stopped attending the calls.

What makes this specific to molding is that the pain genuinely is everywhere at once, and the pieces genuinely are connected. Scrap feeds costing, costing feeds quoting, quoting depends on tool history, tool history depends on shot counts from presses. It is tempting to conclude that you have to do it all together. You do not, because there is a natural first cut: get the shot stream in from one plant, model scrap as an event with a cavity, count shots against tools, and put a live margin board in front of the people who quote. That is enough to change decisions in the first quarter it runs.

The tell that scope is running away is when the phrase replace the ERP appears. Nobody should be rebuilding a general ledger, purchasing or inventory. Keep the incumbent for what it is good at, build the shot level operations layer it was never designed for, and connect them.

What goes wrong when you migrate tool records and job costing history?

Two migrations matter and they fail differently. Tool master records look clean until you check them. The same mold appears twice because it moved plants and got a new asset number. Cavity counts in the record say eight when the tool has been running seven for months because a cavity is blocked and the note is taped to the press. Customer owned tools are recorded against a customer name that has since been acquired. Load that as is and your shot counters accrue against the wrong assets from day one, which means the first preventive maintenance the system proposes is wrong and the tool room stops believing it.

Historic job costing is the second, and here the mistake is loading too much rather than too little. Standards from the enterprise system are not history, they are assumptions somebody froze at quote time. Bring them in as a reference column if you like, but never as a baseline, because the entire purpose of the build is to stop deciding from them. What is worth migrating is roughly twelve to twenty four months of actual production history, because that is what lets you compute a demonstrated cycle rate per tool and press combination and show a quoting engineer how far reality has drifted from the standard.

The practical fix is a physical audit alongside the load. Walk the tool room with the list. Confirm cavity counts, confirm which tools are customer owned, confirm which ones are dead and should not be migrated at all. It takes a few days of a tool room supervisor's time and it prevents the class of error that is nearly impossible to unwind once shot counters have been accruing for two months.

Why do press and ERP integrations break after launch?

Press connections break for physical reasons. A modern press speaking Euromap 63, Euromap 77 or OPC UA is stable. The older machine on an edge device reading a relay or a proximity sensor is a piece of hardware sitting in a hot, vibrating environment with a network cable somebody will eventually unplug during a mold change. Those connections do fail, and the failure mode that hurts is silent: the counter stops, the margin board keeps showing a number, and nobody notices until a monthly review.

The fix is heartbeat monitoring per machine, not per system. If a press has produced no shot events for longer than its own normal cycle allows, that is an alert to a named person on the floor, not a line in a log. It costs almost nothing to build and it is the difference between a data gap of two hours and a data gap of three weeks.

Enterprise system integration breaks for a different reason. Reading from IQMS or DELMIAworks against a defined contract is durable. Writing back into a schema you do not control is where projects become fragile, because the vendor upgrades on their schedule and a column you depend on changes shape. Keep write backs deliberately narrow, put an anti corruption layer between their schema and yours so a change upstream breaks one mapping rather than the whole system, and test the integration against a copy of the target after every vendor upgrade rather than discovering it in production.

What happens when traceability and validation are not covered properly?

If you mold anything medical, automotive or food contact, two gaps will find you. The first is material traceability that resolves to a shift rather than to a shot. Your resin supplier flags a suspect lot, and because the hopper changeover was recorded to the nearest shift and the regrind hopper holds material ground from four different lots, the honest answer is that three weeks of shipments are in scope. You then recall parts that were fine, and the cost of that is not the parts, it is the customer relationship and the corrective action that follows.

The fix is to bind the material lot to the drying and blending equipment rather than to the work order, and to timestamp loader and blender events so any shot number resolves to an exact virgin lot, an exact regrind batch and a drying history. Cartons then carry a shot range, and the recall query returns two shipments instead of three weeks.

The second gap is validation. For Class II medical device molding, installation, operational and performance qualification documentation plus 21 CFR Part 11 audit trails are not optional, and in our experience they add materially to both cost and timeline. The failure is not that they are expensive. It is that they get discovered in week twenty two by a team that quoted in week two, and at that point the audit trail has to be retrofitted into records that were never designed to be immutable. For automotive work, the equivalent question is whether the system can produce the evidence an IATF 16949 auditor will expect from something feeding your production part approval package. Raise both before proposals, not after.

Should you build custom or configure what you already own?

Some molders should not build, and we tell them so on the first call. Under roughly fifteen presses at a single site, with a stable part mix and no customer asking for portal access or automated traceability exports, the answer is IQMS or DELMIAworks configured properly, Mattec set up with reason codes that reflect how your plant actually stops, and a plant manager who enforces data discipline. The six figures a build would cost is better spent on a second grinder and a tool room technician.

Mattec and RJG eDART are also frequently good enough as data sources, and where they are already installed a custom build usually sits on top of them rather than replacing them, which lowers the cost. Replacing a working monitoring layer to gain a slightly nicer interface is a poor trade.

Build when you have more than one plant and cannot get a single trustworthy scrap or overall equipment effectiveness number without a human reconciling spreadsheets, when a controller or analyst spends two days a month rebuilding job costing from exports, when you are requoting off standards you know are stale, or when an audit or recall has already cost more than the build would.

How do hidden costs get into the quote?

Press heterogeneity is the largest and the most consistently underquoted. A floor with Engel, Arburg, Husky, Nissei and two machines from the nineties is four or five integration paths with site time attached, not one line item. Get an accurate machine inventory with make, model, year and available interface before anyone quotes you, because a proposal written without it is a guess.

Second, bidirectional sync with the enterprise system. Read only is a fraction of the cost of write back, and every write back adds ongoing fragility. Decide deliberately which ones you actually need rather than accepting a general commitment to keep both systems in step.

Third, validated environments, which add real percentage points to a medical build and are frequently absent from the first number. Fourth, additional plants, because each site is a network, an information technology contact and a change management effort rather than a configuration row. Ask specifically what is included per additional plant and what is not.

What separates a build that works from one that fails here?

The builds that work put Tool, Cavity, Shot, Resin Lot and Press in the data model as first class objects with their own lifecycles. Ask a prospective partner where a blocked cavity lives in their model. A team that has done this answers instantly, because a blocked cavity is a state on a cavity with a start date, an effective cavity count on the tool, and a consequence for both costing and scrap attribution. A team that has not will offer to add a field.

They also make capture fast enough that operators use it. Cavity level scrap has to be a tablet at the press, a visual layout of the actual tool, and a reason list you control per tool family, completed in a few seconds. Anything that takes a minute gets skipped on a busy shift, and a scrap model with gaps is a scrap model nobody queries.

The builds that fail look like a generic work order system with a plastics badge on it. They record scrap as a quantity and a reason code, they treat the press as the asset rather than the tool, and they compute cost from standards because standards were already in the database. Six months in, the controller is still maintaining the spreadsheet, and the only thing that has changed is that there is now a dashboard nobody opens.