Foundry Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a foundry project get scoped like a machine shop?

Almost every quote a foundry receives describes a work order that consumes materials and produces units. It is the shape of every manufacturing system a general developer has built, and it is structurally wrong for a metalcaster in ways that will not show up until the first month of live production.

You do not consume materials and produce units. You buy scrap and pig by the ton, you melt in heats, you pour moulds that carry a number of cavities per pattern, and a large fraction of the metal comes straight back as gating and risers. Your yield, metal melted to good castings shipped, is the number your entire margin rests on, and a standard bill of materials has nowhere to express it. Revert has nowhere to go. Cavities have nowhere to go. Treatment steps between tap and pour have nowhere to go.

The reason this keeps happening is that the melt deck is the hardest part of the operation to describe to an outsider and the easiest part to assume. A plant manager walking a developer through the shop will spend twenty minutes on the moulding line, which looks like manufacturing, and two minutes on the furnace, which looks like a furnace. The developer writes down what they understood.

The fix is a whiteboard test before you sign anything. Ask them to model a heat and a mould. The right answer has a heat record carrying charge makeup by material and weight, furnace, times, treatment steps and chemistry readings, and a mould record that references both a heat and a pattern with its cavity count. If they draw a work order with a quantity and a material list, they are building a machine shop system and every foundry specific number you care about will end up in a spreadsheet beside it.

What goes wrong when you migrate patterns, part routings and production history?

Pattern and tooling data is the migration that hurts, because in most foundries it does not exist in a system at all. It exists as a rack tag, a spreadsheet, and a pattern shop foreman who knows which tool is worn.

Three problems surface every time. Ownership is unclear on a meaningful share of tools, because a customer paid for a pattern eleven years ago, the contact who signed for it has retired, and there is no document. Cavity counts and current condition are recorded inconsistently or not at all, so shot count accumulation has no baseline to start from. And the same physical pattern appears twice under two naming conventions from two eras of the business, with production history split across both.

Historical scrap data is the second trap. Foundries typically hold years of scrap tonnage without defect codes or the station where the scrap was found, which means the history cannot answer the questions the new system is being bought to answer. Importing it anyway produces a defect Pareto with a single enormous bar labelled other, and people conclude the reports do not work.

The fix is a pattern audit before the build, not during it. Walk the rack, record owner, cavity count, condition and the parts each tool produces, and resolve the duplicate names while you have the foreman standing next to you. It is two or three days of unglamorous work and it is the highest value preparation anyone can do. On scrap history, import the tonnage as an opening reference only and start defect coding fresh from go live, so the new Pareto is real from day one rather than diluted by six years of blanks.

Why do the plant equipment integrations break after launch?

The spectrometer, the pour furnace, the moulding line controls and the shipping scale are where a foundry build stops being ordinary software. They are also where these projects most reliably degrade in month three.

The failures are consistent. A serial interface that works fine until someone replaces the PC beside the instrument and the port mapping changes. A spectrometer whose result file naming convention shifts after a service visit or a software update, so the parser silently stops matching heats. A moulding line controller on a plant network that a well meaning IT change isolates from the server. In each case the system does not throw an error a plant person will see. It just stops receiving data, and the melt deck goes back to writing chemistry on a card because it is quicker than complaining.

The reason this is specific to foundries is the environment. These interfaces sit in heat, vibration and dust, they were installed by three different vendors across two decades, and nobody in the building owns them jointly. Ordinary business software integrates with systems that have owners. Plant integrations do not.

The fix is monitoring and a named owner. Every equipment feed needs a heartbeat check that raises an alert when data stops arriving rather than waiting for someone to notice a blank column, and a documented runbook for the three failures above. Ask any developer to name the specific instrument and protocol they have integrated, by make, not to claim integrations generally. Then budget maintenance for those connectors in year two rather than assuming warranty covers a plant that changed around them.

What happens when certificates and customer owned tooling obligations are not covered?

Two compliance gaps recur, and both surface in front of a customer rather than internally.

The first is certificates. Automotive and pressure containing work brings material test reports, chemistry per heat and formal submission requirements. In most foundries the chemistry exists as a printout and the certificate gets typed from it. That typing is exactly where the traceability chain breaks, because a typed certificate is an assertion rather than a record, and when a customer asks you to demonstrate the chain behind it you have a person's memory and a folder named by date.

The second is customer owned tooling. Where a pattern belongs to the customer, you carry obligations: maintain it, report its condition, be answerable if it wears out of tolerance, and never run it for anyone else. That is an asset with a contract attached, not an inventory item. When it is tracked on a rack tag, disputes follow, and they are the kind of dispute that ends a programme rather than costing a credit.

The fix is generation rather than transcription, and tooling as a first class asset. Certificates should be produced from captured chemistry against the heat, so the document and the evidence are the same record. Patterns should carry owner, cavity count, condition, accumulated shot count since last maintenance, storage location and the specific contractual terms, with shot counts accumulating automatically from production so maintenance becomes a scheduled event driven by use rather than a discovery made when a casting falls out of tolerance.

Should you build custom or configure what you already own?

B&L Information Systems built Odyssey ERP (Enterprise Resource Planning) specifically for metalcasters, and that focus is genuine. It understands heats, patterns and casting units in a way no general manufacturing package does. If your operation looks like a conventional production foundry, configure it and spend the difference on your melt deck. We have told foundries exactly that.

The same applies at the small end. A jobbing shop under about 15 people pouring a handful of patterns does not need any of this. A disciplined pour log, a good travel sheet and QuickBooks genuinely work, and the owner already carries the information accurately. Buying software to formalise a system that fits in one person's head is money spent on ceremony.

Where a build earns its place is at the edges of that fit. Foundries where downstream machining and outside processing add as much value as the casting, so the routing spans two or three outside vendors before shipment. Unusual melt practice or alloy portfolios the standard chemistry model does not represent. Operations that want live capture from the spectrometer, furnace and moulding line rather than keyed entry, which is where the actual defect intelligence lives. And commercial models such as consignment stocking or per customer tooling amortisation that the package expresses awkwardly.

The realistic middle path is to keep the incumbent for accounting and quoting and build the floor layer, the heat, the pour, the pattern and the scrap, on top with real integration. That is a smaller first phase than a replacement and it de risks the whole programme.

How do hidden costs get into the quote?

Four things reliably arrive after the proposal is signed. Equipment integration, quoted as a line and delivered as three separate vendor conversations, each with its own manual and its own surprise. Multiple moulding lines or a second site, where the second one is cheap but the first assumption that they are identical is not. Automotive customer requirements, including formal part submission packages, which are a programme rather than a feature. And the pattern audit described above, which somebody pays for whether or not it is in the quote.

The fifth cost is not money. It is floor time. Scrap coding, pour logging and pattern shot counts only work if the people at the grinding station and the pour furnace use them, and the hours spent designing those two screens with the actual operators are the difference between real data and an empty table.

The fix is to make the quote name things. Which instruments, by make. How many moulding lines and part numbers in release one. Who performs the pattern audit and when. How many hours are budgeted for floor terminal design with operators. A developer who answers those four has scoped a foundry. One who answers in categories has scoped a factory in general.

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

The builds that work are floor first and deliberately narrow. One moulding line, your top 30 part numbers by volume, the heat and pour model, pattern and tooling assets, scrap by defect code and station, and yield. That covers most of the money and all of the process learning, and it means the data is trustworthy before anyone is asked to trust a report built on it.

They design capture for gloves. A grinder will not use a form. Scrap recording has to be a station terminal or a scanner with defect codes as large buttons and a total interaction of a few seconds, and the station where the defect was found has to be recorded as well as the code, because a defect caught after machining and heat treat costs many times what the same defect costs at shakeout. Until you record the station, that cost is invisible.

They run parallel with the paper log for two to three weeks rather than converting on a weekend. The floor builds the habit while the paper record still exists, and the discrepancies between the two are exactly the training material you need. Foundries that attempt a single weekend cutover are usually back on clipboards within a month.

And they settle ownership before kickoff. The repository, the cloud accounts and the data, in writing. At Digital Heroes the client owns all of it from the first commit. Your alloy target windows, defect taxonomy, pattern records and yield history are your melt deck's accumulated knowledge in structured form, and they should never sit in an account you cannot open.