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

Why does the BOM ingestion scope get underestimated so often?

Because importing a bill of materials sounds like a file upload, and in a demo it is one. The proposal describes an import screen, a parts table and a quote output, and the price reflects that. What it does not reflect is that you are not importing your own bill of materials. You are receiving foreign ones from dozens of customers, each in their own dialect, and turning them around in hours.

One customer uses MFG PN and QTY. Another uses Manufacturer Part Number and Per Board. A third puts reference designators in a merged cell with line breaks. Then every line needs lifecycle status, availability, compliance flags and pricing at three quantity breaks, plus alternates for the parts that are not going to be there when you need them. That is the four to six hours per request for quote, and it is the work, not the import.

The scoping defence is to make the developer process three real customer files in front of you before pricing anything. Give them your messiest one. If the answer is a column mapping screen the operator fills in each time, you have bought a slightly faster spreadsheet. What you want is a per customer profile that learns the dialect, extraction that infers which column is which, normalisation against your internal part master and your own historical landed cost, and distributor lookups running in parallel rather than one part at a time. The engineer should be reviewing a risk flagged bill of materials, not transcribing one.

What goes wrong when you migrate part masters and try to backfill genealogy?

Two very different problems get bundled into one migration line, and only one of them is solvable.

The part master is the solvable half, and it is still messier than it looks. Years of manually created records mean the same manufacturer part number exists three times with different internal numbers, customer part numbers are mixed into the manufacturer field, and approved vendor lists are per customer but stored as free text notes. Purchase history is worth migrating because it carries your real landed cost, which is what makes quoting accurate, but it has to be reconciled to the deduplicated part master first.

Genealogy is the half that does not migrate. If your historical traceability lives in paper kitting sheets and machine logs that were never joined, you will not backfill it and you should not spend money trying. The honest plan is that boards built after go live are traceable and boards built before go live stay exactly as hard to trace as they always were. Say that to your quality manager during scoping rather than discovering it at the first audit.

What to require: deduplication of the part master as a named deliverable with a review step, purchase history mapped to the cleaned master, active bills of materials imported, and a documented cut over date after which genealogy is complete. Anyone promising to reconstruct historical genealogy from timestamps is selling you a liability.

Why do the machine data and ERP integrations break after launch?

These are the two integration families that consume budget, and they fail for different reasons.

• Every pick and place vendor is its own project. A mixed floor of Fuji, Juki and Yamaha is three data models, three connection methods and three support relationships, not one integration with three configurations.
• Line changes. A feeder setup changes, a program is revised, or a machine is swapped between lines, and the mapping from placement event to reference designator quietly stops resolving.
• Work order renaming. The classic manufacturing execution system to enterprise resource planning failure. Somebody renames or splits a work order and the nightly join produces orphan records nobody looks at until month end.
• Old ERP schemas. Epicor Kinetic is workable because there is a real interface. Reverse engineering a decade old install's database is real weeks, and it breaks on the vendor's next patch because you were never using a supported path.

The defences: count the machine integrations explicitly in the contract by vendor, make the serial number rather than the work order the durable key so a renamed order cannot orphan genealogy, and run reconciliation continuously so a line that stops resolving placements raises an exception the same shift instead of at the next audit.

What happens when AS9100 or ISO 13485 validation is left out of scope?

It is left out because it is invisible to everyone except your quality manager, and it is the omission that most often turns a working system into an unusable one.

Regulated scope means documented requirements traceability, installation and operational qualification protocols, an audit trail on the software itself, and change control over the codebase. In our builds that work adds a meaningful share of the timeline, in the region of a quarter to two fifths, and a developer who has never sat through an audit will underquote it by roughly half and leave you exposed at exactly the wrong moment.

The failure mode is specific. The software works, the shop uses it, and then an auditor asks how a change was authorised, tested and released, and there is no evidence. Now your traceability system is itself a finding. Retrofitting validation onto a system already in production is more expensive than building it in, because you are documenting history rather than recording it.

What to require: validation named as a deliverable with its own schedule, your quality manager in the requirements sessions rather than briefed afterwards, and change control on the repository from the first sprint. Ask any developer directly whether they have been through an audit with software they built, and ask what the auditor asked for.

Should you build custom or configure what you already own?

Buy, and mean it, if you are a single line shop under roughly eight million dollars, mostly building your own product with a stable bill of materials, and you get one traceability request a year. A mid tier enterprise resource planning system plus a spreadsheet is correct, and a custom build will cost more than the pain it removes.

Same answer if you are high volume and low mix, running a couple of stock keeping units at scale. Your problem is line efficiency, and a proper manufacturing execution system from Aegis or Cogiscan solves that better and cheaper than anything bespoke. Buy it and stop.

Keep Epicor Kinetic either way. It is good at financials, purchasing and work order management, and replacing it is not the project. Arena and Duro solve bill of materials management well for companies that own their designs, which is a different problem from receiving foreign bills of materials from dozens of customers under time pressure.

Build when your quoting engineers are spending serious hours a month on scrubbing, when a traceability request takes more than half a day to answer, when the business depends on spreadsheet macros only one person understands, or when your enterprise resource planning vendor quoted six figures for a customisation that covers a fraction of what you need. The clearest signal is when the thing that wins you business, high mix and fast turn difficult work, is the thing your tools cannot represent.

How do hidden costs get into the quote?

Four drivers, and they are consistent across shops.

• Machine data source count. Priced as one integration and delivered as three. Get the vendors named in the contract.
• ERP interface quality. A real interface is workable. An old install without one turns into schema archaeology, and that cost belongs in the estimate rather than in a change request.
• Validation. Regulated scope adds substantially to the timeline. It is not overhead, it is work.
• Paid data feeds. Lifecycle and compliance data services are an annual line item on top of the build, and quotes routinely assume you already have one.

Customer portal scope creep is the fifth and it is self inflicted. Everyone wants more from it once they see it working, so agree what version one does and put the rest in a backlog with a price attached.

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

The builds that work make the board serial number the primary key and hang everything off it. Receiving creates a lot record with date code, lot code, moisture sensitivity level and floor life clock. Kitting records reel to slot against a work order. Placement events resolve a component on a serial to the exact reel and therefore the exact lot and receiving record. Inspection and test results and rework events attach to the same serial. Then a traceability request is a search box rather than a filing cabinet, and an audit becomes a screen share.

They quote off your own history rather than list price and standard rates. Actual landed cost from your purchase history for parts you have bought, live distributor pricing for parts you have not, and a per line cycle time model built from your closed work orders. Shops that do this commonly find they were underquoting complex mid mix work and overquoting simple volume work, which is exactly backwards from where they want to win.

They catch engineering changes before purchasing reacts. A revision lands, the system diffs it line by line against what you are building to, and produces an impact report naming affected purchase orders, stock that becomes dead, and new parts whose lead time breaks the committed ship date. One prevented surprise per quarter usually covers a meaningful slice of the build.

And they settle ownership in the contract before the first sprint. You should own the source, the schema and the deployment. At Digital Heroes the client owns all three from the first commit. Your genealogy records and cost history are business critical, and if a developer wants to host them in a way you cannot leave, that is a tenancy agreement rather than a build.