How to Choose the Right Traceability Software for Your Manufacturing Process

Before You Choose Software, Know Which Kind of Traceability You Need

When you search for traceability software, you will eventually end up getting the results that are not related to or about manufacturing traceability at all.

Many are requirements traceability tools - such as Jama Connect, Siemens Polarion, IBM DOORS and PTC Codebeamer. These are tools that helps track a requirement through design, code and testing, and backward to the requirement that led to it. Requirements traceability is used in standards such as DO-178C for airborne software, ISO 26262 for automotive functional safety, IEC 61508 and IEC 62304 for medical device software.

But that is not what most manufacturing teams mean when they talk about traceability.

"Requirements traceability traces intent. Manufacturing traceability traces physical products."

In buyers term, the difference is simple:

• If your question is "Can we prove this requirement was tested?", you need an ALM or requirements traceability tool.
• Whereas if your question is "Which units contain this suspect lot?", then you need manufacturing traceability.

There can, however, be some overlap. A medical device manufacturer working under ISO 13485 and IEC 62304 may need requirements traceability for its Design History File and production traceability under ISO 13485 clause 7.5.9. The two sets of information may need to link - but the systems serve different purposes.

An ALM tool does not create an as-built genealogy of physical products.

So, if a vendor demo shows you a requirements matrix when you need to trace what went into a physical product, then you are looking at the wrong type of software.

There is one more point to keep in mind. Having traceability links does not automatically mean the information is correct or consistent. As the Automotive SPICE Pocket Guide, PAM v4.0, points out, traceability links alone do not guarantee consistency. The same principle applies here: "Having a genealogy record is not the same as having a correct one."

Your Production Process Determines the Traceability You Need

This is one of the first things to look at before comparing software. It determines whether a system can actually support your production process - and it is something many buyers skip. Discrete, batch, and continuous production do not follow the same traceability model.

Three Things Matter More Than Any Feature Comparison

Discrete production has individual units. Continuous production follows time. Batch production has neither, so you have to create and manage its own identity.

That is one reason batch manufacturers can get poor results from generic traceability tools.

A pharmaceutical plant may move from continuous synthesis to batch formulation and then to discrete, serialised packaging.

An electronics plant may use batch-tracked inputs, such as solder paste and component reels, to produce discrete, serialised assemblies.

Almost no system handles all three production modes natively. The traceability chain can break when information moves from one mode to another. So, don't just ask a vendor whether the system supports batch and serialised production. Ask them to demonstrate how the transition works.

It is not just a matter of preference. The level of detail you need affects how narrowly you can identify and contain affected product.

We'll look at this in more detail later, because working out the right level of granularity is one of the most useful things you can do before choosing a system.

Not sure about the terms in the table? Traceability codes explained covers lot codes, batch codes, serial numbers, and GTINs, including what they mean and which ones may be legally required.

What Each Type of Traceability System Is Built to Do

Not every traceability system for manufacturing is built to do the same job. MES traceability is different because it captures traceability data as production happens. This can include unit or lot genealogy, process parameters, test results, operators, equipment and tooling.

That matters because it also affects how much traceability detail the system can handle.

1. The Difference Between PLM and MES Matters

There is one distinction worth keeping in mind during every vendor conversation:

PLM traceability defines what the product should be. MES traceability records what actually happened during production.

Mixing up these two is one of the most common mistakes done when evaluating traceability systems. Another useful way to look at traceability is through three views of the product:

• As-designed - what the product is supposed to be
• As-built - what was actually produced
• As-maintained - what happened to the product after it entered service

PLM mainly owns the as-designed view. MES mainly owns the as-built view. Field service or EAM systems usually own the as-maintained view.

In practice, many traceability problems happen when these three views do not connect properly. The issue is often not within one system - it is the failure to reconcile the three.

This is Not a New MES Capability

MESA International's MES Explained white paper listed "Product Tracking and Genealogy" as one of the eleven core MES functions.

Published in September 1997, it described the need to track details such as who worked on a product, the components and materials used, their supplier, lot and serial number, current production conditions, alarms, rework, and other exceptions.

That is still very close to what manufacturers expect from traceability software today. In other words, this is not a new capability. It is a problem the industry has been trying to solve for a long time.

Where Traceability Data Fits in the Manufacturing Stack

Structurally, traceability sits close to production operations.

Under ISA-95 - also known as ANSI/ISA-95 and IEC 62264 - it sits at Level 3: Manufacturing Operations Management. This is between supervisory control at Level 2 and business planning at Level 4.

Part 3 of the standard identifies Production Tracking as a Level 3 activity. Section 6.10.3 also covers the merging and splitting of production information. It is important to note that the ISA-95 Part 1 was updated in 2025. The update focused on the boundary between enterprise and manufacturing systems, rather than traceability itself.

One important point: ISA-95 does not define a genealogy data model.

That means there is no single ISA-95-defined way to structure genealogy data. Each vendor has created its own model, which is something worth looking at closely when comparing systems.

What Your Industry Standard Actually Requires

Traceability requirements vary by industry. So, a generic evaluation of "traceability software for manufacturing" can be misleading. Here is what the main standards and regulations require.

If You Serialise, You May Already Need to Comply

Often, a lot of manufacturers end up planning the traceability projects around a future compliance date. However, most of those dates have already passed for serialisation.

FDA UDI is now fully in force across all medical device classes.

For Class I and unclassified devices:

• 24 September 2022: Labeling and direct-marking compliance date
• 8 December 2022: GUDID submission date

All grace periods have expired.

A UDI has two parts:

The main issue still to address is direct part marking for devices intended for reprocessing. This is not simply a labelling issue, but is a production-record issue.

DSCSA has been fully in force for pharmaceutical manufacturers and re-packagers since 27 May 2025, when their exemption expired. The one-year stabilisation period had already ended in November 2024.

The only relief still in place applies to small dispensers. Their exemption was extended in August 2026 until 27 November 2027 while the FDA completes its assessment.

But small retail pharmacies are not the manufacturers and re-packagers this article is addressing. So, if you are a pharmaceutical manufacturer, you do not have much time to prepare.

EU MDR uses UDI and EUDAMED as part of its regulatory framework. Four of EUDAMED's six modules became mandatory on 28 May 2026.

The remaining two - Vigilance and Clinical Investigations - are not yet released, and no date has been announced.

The EU system also includes something the FDA system does not: a Basic UDI-DI. This acts as a primary key for regulatory documentation and sits above the UDI-DI and UDI-PI.

For US defence property, MIL-STD-130N Change 1 requires a Unique Item Identifier. The marking requirements include:

• A 2D Data Matrix ECC 200 symbol
• ISO/IEC 15434 syntax
• A minimum verification grade of B
• Human-readable information alongside the mark

The contractual requirement comes through DFARS 252.211-7003, rather than the standard alone. From a software perspective, this is different from UDI or DSCSA.

This is a direct part-marking requirement. You need to manage:

• Mark generation
• Mark verification and grading
• An as-built record linking the identifier to the part and contract

That is a different capability set from label printing. This is why defence suppliers often use separate marking systems alongside their MES.

Digital Product Passports (DPPs) are mainly a planning issue today, with one important exception.

The first DPP requirement already set in law is the battery passport under Regulation (EU) 2023/1542.

From 18 February 2027, the following batteries cannot be placed on the market without one:

• LMT batteries
• Industrial batteries above 2 kWh
• EV batteries

Under the ESPR, the working plan currently puts these product groups on the roadmap:

• Iron and steel: 2026
• Textiles and tyres: 2027
• Aluminium: 2027
• Furniture: 2028
• Mattresses: 2029

The key traceability requirement is information about materials and their origins. That makes DPP an upstream supply-chain data collection problem, not simply a labelling problem.

Most of the delegated acts that will define the actual data models have not yet been published. So, when a vendor says its software is “DPP-ready” today, it is really selling a roadmap for requirements that are still being defined.

Before You Shortlist, Work Out How Much Traceability You Need

Before comparing software, you can run a batch dispersion analysis using your own historical production data. This turns software selection from a feature comparison into a clear requirement.

For a representative production period, take each input lot and track how widely it spreads through your finished output.

Start measuring:

• How many output lots it reaches
• How many units it affects
• How many customers receive those units
• How many days the affected production covers

Then repeat the same analysis at different levels of traceability, such as:

• Per shift
• Per work order
• Per machine
• Per unit

This shows you the containment scope you would get from each level of traceability depth. In other words, instead of asking, "How much traceability do we need?", you can put a number on it. That number should drive your software choice - not the other way around.

The results can also reveal a problem with your current setup.

For example, if one suspect input lot could affect six weeks of finished output, that is your real containment exposure. And that is the number you should use when building your business case.

One way to understand the potential cost of a wider containment scope is to look at automotive warranty disclosures.

In 2025:

• Ford paid $5.73 billion in warranty claims
• GM paid $5.32 billion
• Their fourth-quarter claims rates were 3.4% and 3.2% of product sales, respectively

Another useful figure is the change in estimates for prior-year warranty accruals:

• GM: +$3.25 billion
• Ford: +$2.3 billion
• Tesla: +$1.1 billion

A change in the estimate for a prior-year warranty accrual can mean a company has found that its already-shipped product population is worse than it originally thought.

That is the type of exposure unit-level traceability is meant to limit - by helping you identify and contain the affected population more precisely.

What About Recall Costs?

You may have seen the claim that the average recall costs $10 million.

The source does not support that claim. What the GMA study actually found was that:

• 77% of respondents estimated a financial impact of up to $30 million
• 23% estimated a higher impact
• The survey covered 36 companies in 2011

The more useful finding for this discussion is where the costs came from. Business interruption was the largest cost category, ahead of product disposal and customer reimbursement.

That is an important traceability point.

The longer and wider your containment effort, the greater the potential disruption while you work out what is affected and what is not.

Faster, more precise traceability helps reduce that scope.

Why Traceability Projects Fail

One of the most useful explanations comes from NIST Interagency Report 8419, published in April 2022. The report focuses on blockchain, but its findings on why traceability fails apply to any technology. It identifies three main problems:

Traceability often depends on "bilateral exchanges of information." In simple terms, one company shares data with another, rather than everyone working within a coordinated ecosystem.

According to NIST, this can lead to incomplete coverage, different ways of implementing traceability, and gaps in how information is understood.

Company A sends information to Company B. B then passes information to Company C. The problem is that the original traceability information may not fully reach C.

C then has to trust information from A through B. This is a breakdown in trust transitivity - the traceability chain becomes weaker as information moves between organisations.

A supplier several tiers away may create a traceability record that is not fully understood or recognised further down the supply chain. This creates a semantic gap.

The data may exist, but if the next system cannot interpret it properly, it loses much of its value.

All of the three problems happen at the boundaries between organisations and systems - not necessarily inside the systems themselves. This also supports the earlier point about hybrid production: traceability often fails at transitions.

Be Careful With Project Failure Statistics

You will often see claims about a certain percentage of MES or traceability projects failing. Be sceptical of them.

It is because these figures are widely repeated, but many do not have a clear or traceable methodology behind them. They often come from vendor content rather than published research.

The same applies to the widely quoted claim that the cost of poor quality is 15–20% of revenue. If a vendor uses either figure to make a business case, ask for the source and the methodology behind it.

Questions You Should Actually Ask a Vendor

Ask these questions before the demo, not after.

Show a batch input becoming serialised output, or a continuous process moving into a batch. Don't show each production mode separately. Show the handover between them.

If the answer is the inventory transaction, you are looking at an ERP module - regardless of what the vendor calls it.

This is where genealogy trees often break. So, ask the vendor to show you how the system keeps the traceability record intact.

Internal genealogy is the easier part. Material traceability in manufacturing also means tracking the origin of purchased materials, where requirements such as AS5553D and IPC-1782 external traceability become important.

Can the product record link to the right configuration or revision state? If not, the system cannot properly support aerospace or regulated device requirements.

Don't just ask whether the data exists. Ask how long it takes to produce a containment list for a suspect lot across all your sites.

Be wary of a vendor that claims to meet every requirement without qualification. One final tip: ask these questions before you see the demo. If a vendor answers the first question with a slide instead of showing you the process in a live system, they are not really answering the question.

For reference, our manufacturing traceability platform is built around the type of record structure described in this guide.

Where to Start

Work through the decision in the following order:

1. Start by understanding your production process.
2. Identify the production shape - or combination of shapes - you actually run.
3. Check your industry requirements.
4. Read the specific traceability clause that applies to your sector.
5. Measure your granularity.
6. Run a dispersion analysis to see how much detail you need and what your current containment scope looks like.
7. Then compare systems.

Don't start by choosing a production traceability system. First, work out how much detail you need. Otherwise, you could end up with a system that keeps good records - but not at the level you need.

However, if you want to understand the identifiers first, start with traceability codes explained. It covers lot codes, serial numbers, GTINs, what each one does and which ones may be legally required.

If you produce food, start with food traceability software. Food has a different regulatory driver and needs its own approach. And if you want to see how this type of record structure works in practice, our manufacturing traceability platform is built around it.