Packaging Manufacturing Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a die library project turn into an enterprise resource planning (ERP) replacement?

It begins with the die library, which is the right place to begin. Then estimating, correctly, because the die is what makes estimating accurate. Then scheduling, because estimating without substrate constraints is theoretical. Then somebody notices the invoice would be easier if it came from the same place, and now you are replacing accounts receivable, accounts payable and the general ledger, which are the parts of your enterprise resource planning system that already work.

The pull is strongest in converters because the incumbent system is disliked for its interface, and interface dislike is a bad reason to rebuild working accounting.

The fix is a boundary stated before scoping: the enterprise resource planning system keeps the customer master, the invoices and the ledger. The build owns the die as a real asset record, the estimating rules engine, substrate lots and partials, and real time job cost. That scope is the $60k to $130k, 12 to 16 week first release, and it stays there because it integrates read only rather than replacing. Full replacement roughly triples cost and hands you back features you already have running.

What goes wrong migrating thousands of dies and years of job history?

Digitising computer aided design files and job history is engineering work of a few weeks. The physical reconciliation is what surprises people. Somebody has to walk the racks with a scanner and tag actual steel, and what comes back rarely matches the belief. In our experience the count is higher than expected, a large share has not been hit in years, and there are duplicates cut because nobody could find the original. Duplicate dies are pure loss and they are sitting in your building right now.

The second problem is drawing provenance. The folder holds several revisions with names that do not indicate which one was actually cut, so nobody can say with confidence that the drawing on the shared drive matches the rule in the rack.

The fix is to budget the walkdown as a line item of two to four weeks per plant rather than assuming it happens during development, and to attach a file hash to the die record so drawing and steel are provably linked from that day forward. Treat the dead and duplicate portion of the library as a finding rather than a nuisance, because retiring it is usually the first hard number the project produces.

Why do the enterprise system and press integrations break after launch?

Integration is where converter projects die and it is knowable in advance. If your incumbent system offers clean application programming interface access, the work is predictable. If it does not, you are into database level integration and a nightly synchronisation, which means the new system's view of an order is up to a day stale and everyone quietly learns not to trust it for anything urgent.

Press integration fails differently. A modern line with an open data layer is straightforward. Older lines need a counter tap, and the failure there is physical: a tap installed at the wrong point counts sheets rather than impressions, or counts during make ready, so cost per thousand is confidently wrong.

The fixes: demand a written integration spike before signing anything larger than a discovery, naming your system and the method, whether that is a REST interface, an open database connection or a file drop. Validate press counts against a known job by hand before anyone reports off them. And design for the nightly synchronisation case explicitly, showing users when data was last refreshed instead of presenting stale figures as live.

What happens when lot genealogy and spec versioning are not covered?

Substrate is not a commodity quantity and treating it as one breaks the moment a customer with incoming inspection asks which lot ran their job. A roll or skid needs to be a serialised unit with a lot, a remaining quantity that decrements from press counter reads rather than a shift end estimate, and a partials pool the scheduler can see. Without that, a long run consumes stock across three shifts and the on hand figure is wrong for most of the day, so scheduling commits to dates it cannot hold.

Spec versioning fails more visibly. A customer sends a revision on a Friday afternoon, the note gets forwarded, prepress may or may not see it, and plates are made from the wrong revision. That is a plate charge, a schedule slot and a customer conversation.

The fix is to make the item specification the contract: a versioned record pinning die revision, substrate specification, ink set and print condition, with an approval state and a customer facing approval against a specific revision. Pin the sample table cut file to the same revision so the mockup the buyer signed off matches the geometry the steel was cut to. If you run food contact work, lot genealogy with immutable records and electronic signature belongs in phase one, because it cannot be added later without rebuilding the inventory model.

Should you build custom or configure what you already own?

Buy, and stop here, if you run one plant, one substrate family, fewer than roughly 60 jobs a week and under 500 active dies. Amtech, EFI Radius or a well configured NetSuite with a competent implementation partner will serve you, and a custom build is an expensive route to the same outcome plus maintenance you now own. The same applies if your work is genuinely commodity, meaning long runs of a few items for a couple of customers, because the estimating variance a build solves for does not exist in your mix.

Before commissioning anything, exhaust the tooling and estimating configuration you already pay for. Most converters have not fully populated the tooling module or the standard routings, because the estimator's workbook was faster and nobody had two weeks to do it properly. Whatever remains impossible after that is your real specification.

Build when the signals appear together: the estimator is a single point of failure and everyone knows it, repeats are quoted from history rather than cost, margin on the same part varies by more than a few points across the year, dies move between plants with no system of record, and job cost closes later than ten days. The settling signal is paying for a module you do not use because the plant runs on a spreadsheet the system cannot replace.

How do hidden costs get into the quote?

Press connectivity is the biggest source of schedule surprise. A modern line is a couple of weeks; four legacy lines with proprietary counters and no network drop is several weeks plus hardware and an electrician, and the electrician is not on your software timeline.

Plant count is second, not through duplication but through a data model decision: are dies and substrate shared across plants or local to each. That choice is cheap to make at design time and expensive to reverse once history has accumulated behind it.

Third is the die walkdown described above, which is genuine fieldwork. Fourth is compliance: if you serve food contact or pharmaceutical customers, lot genealogy that survives an audit, with retention rules and electronic signature, is scope rather than a setting, and it belongs in the first release.

Fifth, and the one that actually blows budgets, is an incumbent system that will not give clean interface access. That converts a two week integration into weeks of database level work plus a synchronisation strategy, and it is entirely knowable before you sign if you insist on the spike.

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

Make the developer model a die on the first call. Not describe one, sketch the record. If they do not immediately ask about rule height, caliper range, up count per press deck, hit count against a rework threshold and rack location, they have not built this and you will fund their education. The same test works on substrate: anyone who has done this asks about lots and partials within ten minutes.

Second, the estimating rules have to be versioned and owned by the estimator through an interface, with an audit trail of who changed a waste factor and why. Every quote should record which rule version priced it, so a job that loses money traces back to a specific factor you can correct rather than to a person you can blame.

Third, shop floor capture has to survive the shop floor. Gloved hands, a tablet that loses wifi mid shift, four taps to record waste by reason code. A system that loses one shift of data will never be trusted again, and untrusted capture makes every downstream cost figure decorative.

Fourth, settle ownership in the contract. Repository, database schema and deployment in your own source control organisation from week one, not handed over at the end. If a developer resists that, the reason is never a good one.