Traceability Implementation – In-House vs Package and How to Select a Vendor

You have started looking at traceability for your plant, and then the project stalls on a single question — do you build it yourself, buy a packaged product, or hand the whole thing to an outside vendor? Product comparison sites are no help here. They list features, not answers about whether any of it fits the way your line actually runs. This article stays on the buyer’s side of the table. It covers what each implementation model costs, how to judge a vendor’s real engineering capability, the questions worth asking before you sign, and the six practical steps of a rollout.

The first decision in a traceability implementation is what you are tracking for

If you start from product comparisons, you will almost certainly get stuck. Systems marketed as traceability range from production management software with lot control, to tools built purely for shop-floor data collection, to supply chain visibility platforms. Their scope is so different that lining up feature lists puts nothing on a common footing.

The first thing to decide is not a product but a purpose. In practice, a traceability implementation is usually driven by one of three objectives.

Objective 1 – meeting regulatory and customer requirements

Here the driver is a customer audit or an industry standard. For automotive parts that means IATF 16949 requirements; for medical devices and food it means statutory record retention; for electronics it often means a customer demanding component history on delivery.

In this category the requirement arrives from outside — what has to be recorded and in how much detail, how long it is retained, and how many minutes you have to produce it on request. That external pressure is actually an advantage, because the specification is comparatively easy to pin down. The one trap is having several sources of requirements at once. If you do not design to the strictest of them, you will rebuild later.

Objective 2 – recall containment and root cause investigation

Here the driver is narrowing the blast radius when a quality problem appears. The target state is being able to answer, quickly, which finished products used a given material lot, and how far a work-in-progress item processed on a given machine travelled downstream.

The decisive variable in this category is tracking granularity. Whether you track down to a per-unit serial number or a daily lot changes how many scan operations the floor has to perform, and that in turn changes both the cost and the operational burden dramatically. Approach a vendor without having settled granularity and the quotes you receive will vary by a multiple, not a percentage.

Objective 3 – process improvement and yield

Here the recorded data feeds analysis — early detection of defect trends and improvement of process capability. The commonly cited benefits of traceability are easier data retrieval, unified inventory visibility, risk management through early warning of quality issues, and quality improvement through a PDCA cycle. For an improvement-driven implementation, it is the last two that carry the value.

Because the requirement comes from inside the company, it is looser, and scope creep is the characteristic risk. The flip side is real freedom — you get to draw the boundary yourself.

Translate the objective into scope, unit, and retention

Deciding the objective is not a motivational exercise. It is worth doing first because three concrete parameters fall out of it automatically.

• Tracking scope (incoming material only, WIP movement between processes, or tracking that continues after shipment)
• Tracking unit (serial, lot, or a daily aggregate)
• Record retention period (the number of years driven by customer or regulatory requirements, and the storage design that follows)

Call a vendor before these three exist and they cannot quote you. If a number does appear, it reflects that vendor’s standard configuration rather than your plant.

The layered structure of a traceability system and the breakdown of build costs are covered separately in what it costs to build a traceability system and how to approach it. This article stays one step earlier, on which model to choose and who to ask.

The three implementation models and what they cost

Once the objective and scope are provisionally set, the next choice is the delivery model. In practice the options fall into three groups — fully custom in-house development, a cloud package, and an on-premise package. Custom development also has a middle form, half-scratch, where a packaged product is extended only where needed. Including that, indicative costs look like this.

The important caveat is that these figures attach to the software delivery model. They are not the total cost of a traceability implementation. A real quotation adds the following as separate line items.

• Reading hardware such as handheld terminals, fixed scanners, and label printers
• Recurring consumables such as label stock and RFID tags
• Installation work on the floor, including network cabling, power, and dust and water protection
• Cleanup and preparation of item, process, and supplier master data
• Integration development against an existing production management system or ERP
• Operator training and hands-on support until the new routine sticks

Master data preparation is the one most often missed. Traceability is a mechanism for linking material lots to WIP to finished product, and it cannot run if the item codes it links through are not in order. If part numbering differs between sites, or the same material carries several codes, that cleanup consumes effort that sits outside the system budget entirely.

Choose the model by how far you sit from the standard

Which of the three models to choose is easier to reason about from process fit than from budget — specifically, how far your processes sit from a standard flow. The rough decision axes look like this.

It is also true that the companies most convinced their processes are unusual are often the ones a package absorbs without trouble. Separate the parts you consider special into those that are business rules you could change, and those fixed by product specification or customer requirement. Where it is the former, changing the process to fit the system is cheaper and faster overall.

What to look for when selecting a vendor

With the model roughly settled, vendor selection comes next. Getting this wrong is said to carry a real risk of taking delivery of a system that is not the one you had in mind, which is exactly why confirming a vendor’s engineering capability before you place the order matters so much.

Price is no longer the first criterion

In the EMS sector — electronics contract manufacturing — the basis for choosing a partner has been shifting. Price is no longer the main criterion when selecting an EMS partner. What increasingly counts is a resilient and transparent supply chain, the ability to meet regulatory requirements, and traceability of the production process itself.

That observation is about contract manufacturing, but it transfers directly to the buyer of a traceability system. Choosing the cheapest quote and then discovering that the system cannot satisfy a required standard, or cannot absorb an additional process later, is not a rare outcome. Price gets used as the deciding axis because it is easy to compare, and easy to compare is not the same as important.

Judge capability by the quality of their questions, not their reference list

The usual way to gauge a vendor is the reference list, but a page of familiar company names in your industry does not tell you whether the engineers who delivered those projects are still there. A more reliable signal is the quality of the questions the vendor asks you in the first meetings.

A capable vendor asks about your processes before explaining their features. Concretely, questions like these come up.

• At material receiving, who records the lot number and at what moment
• When WIP moves between processes, what event is treated as entry into the next process
• Are there processes that split or merge (one lot becoming several, or several lots becoming one)
• If rework or re-entry occurs, how is that history intended to be recorded
• If an operator forgets to scan, where in the flow is that supposed to be caught

The warning sign is the reverse pattern — a vendor who opens with a product demo and stays on standard features without asking about your line. The work of mapping the system onto your processes tends to come back as your homework after the contract is signed.

Can they describe the implementation plan

Traceability implementation plans share a common shape across industries. Typically it runs as requirements analysis, defining whether the objective is regulatory compliance, risk management, or optimisation; then architecture design aligned to the relevant standard level, together with the ERP integration design; then a pilot deployment for validation on the floor; and finally training and evaluation. In electronics manufacturing the design is commonly aligned to the traceability levels defined in IPC-1782.

Asking a vendor how a project runs at their company, and listening for something that maps onto those four stages, is a useful check. Whether they can explain the role of the pilot matters most. A plan that only ever describes a simultaneous rollout across every process leaves no room to absorb the surprises the shop floor will produce.

Questions to ask before you sign

Once you are comparing quotations, sending every vendor the same list of questions exposes the differences. The ones that earn their place in practice are below.

• What is excluded from this quotation (check hardware, installation, master data cleanup, training, and integration development individually)
• Which processes would the pilot cover, and over what period
• How does integration with our existing production management system or ERP work (API or CSV, and at what frequency)
• How long is the record data retained, and what happens to it afterwards
• If we add one process after go-live, what is the additional cost and lead time
• Is there a team able to respond inside Thailand when something breaks on the floor, and in what languages
• In what format can we export our data if the contract ends

The last two matter disproportionately at an overseas site. Order from a vendor based only in Japan and the time difference plus the language gap can delay first response when a line is down. And if you have not confirmed data portability, changing vendors later means leaving history behind and breaking the very chain you built.

The six steps of a traceability rollout

Once the vendor is chosen — or in parallel with choosing one — there is work only the buyer can do. The implementation process is generally organised into six steps.

Of these six, the ones you cannot delegate entirely to a vendor are steps 1, 2, and 4. Below are the points where projects tend to trip.

Step 1 – clarify roles and responsibilities

Most companies get as far as naming a project owner. What gets missed is the contact person on the production side. Traceability adds new work for operators, so a project driven only by production engineering and IT tends to meet floor resistance just before go-live.

Bring in team leaders from the production section early, and decide together who scans and when. Their involvement at this stage also lowers the training cost later.

Step 2 – write the concept document

The concept document states the objective and the scope. Think of it as putting into prose the primary objective from the previous section, along with the scope, tracking unit, and retention period that follow from it.

The document you produce here is directly reusable for aligning expectations with vendors. In fact, going out to RFP or competitive quotation without it means every vendor builds a quote on different assumptions, and the prices cannot be compared. It does not need to be long. A few pages covering objective, in-scope processes, tracking unit, retention period, systems to integrate with, and desired go-live timing does the job.

Step 3 – draw up the implementation plan

This is where schedule, budget, and team structure become a plan, and where you choose the pilot processes. A representative process with branching and merging is worth far more as a pilot than an unusually simple one. Success on a simple process tells you little, and the problems then surface during full deployment.

Step 4 – write the operating procedures

This defines what the floor actually does. What a vendor supplies is an operating manual for the software. The procedure that maps it onto your own work instructions has to come from you.

At minimum, settle the following: when scanning happens and who performs it, the recovery procedure when a scan is missed, the correction procedure and approver when wrong data is recorded, and the fallback when a device fails. The correction procedure especially — leave it undefined and the floor will invent its own workaround, and the credibility of your records erodes with it.

Step 5 – fix the deployment schedule

Confirm the go-live date and the migration method. When migrating from paper forms or spreadsheet control, the live question is how long to run both in parallel. Parallel running doubles the workload on the floor, so it cannot be sustained. Set the cut-off up front and state explicitly when the paper stops.

Step 6 – train everyone involved

Operators and supervisors need different training. Operators need the procedure and the exception handling. Supervisors need to know how to read the data and where a missing record becomes visible. Skip the supervisor half and you end up with a system that runs correctly while nobody uses what it produces.

How to judge whether GS1 and other international standards apply

Any serious traceability discussion eventually reaches international standards. Because the answer changes the design, decide early.

How the GS1 Global Traceability Standard is structured

The GS1 Global Traceability Standard rests on two pillars. One is Critical Tracking Events (CTEs) — the events that actually happen, such as receiving, packing, shipping, and transport. The other is Key Data Elements (KDEs) — the data that describes those events.

Put differently, it is a framework for defining when something happened as an event, and what gets recorded at that moment as data. The thinking helps even if you are not aiming for GS1 conformance, because laying out your processes and identifying which points deserve to be recorded as events is very nearly the same exercise as deciding your tracking unit.

When conformance actually becomes necessary

Export destinations and large customers increasingly ask for GS1 conformance, so treat it as something to confirm whenever you participate in an international supply chain. Practical indicators are below.

• You supply large overseas retailers or major manufacturers directly, or expect such discussions
• A regulator in an export market may require product history
• A customer has already asked for history in a specific data format
• Your industry association recommends an identification code scheme

If none of these apply and your business is mainly domestic plus a defined set of customers, full conformance from day one is hard to justify. Even so, keep the identification code scheme extensible so a later migration remains possible. Concretely, rather than running purely on internal part numbers, provide a field in the master data where a standard code can be carried alongside.

Check the standards specific to your industry

Electronics manufacturing has IPC-1782, which defines traceability in graded levels, and automotive parts fall under IATF 16949, which carries its own traceability requirements. The level you target changes how many data points you record and how many times the floor has to scan. The specific automotive requirements and the design thinking behind them are covered in automotive parts traceability and IATF 16949 compliance.

What changes by industry and process

The same phrase, traceability implementation, points at different starting places depending on the industry and the process. What follows is not a set of case studies but a comparison of where to focus first when you place the order.

Assembly – moving to serial-level control

In assembled-product industries there are reported cases of moving from handwritten forms to a cloud production management system and achieving control at the serial number level. Assembly is a natural fit for individual identification because the component set can differ from one finished unit to the next.

The point to focus on is whether, at the moment of assembly, you can record which lot of which component went into which individual unit. With that in place, linking downstream inspection results and shipping destinations lets you narrow a quality issue to specific units. Without it — if the record is a daily aggregate — your containment resolution never gets finer than a day.

Metal fabrication – lot accuracy and disciplined FIFO

In metal fabrication there are reported cases of using handheld terminals and barcodes to raise the accuracy of lot control and enforce first-in-first-out. Because material properties vary by raw material lot, linking material lots to process conditions matters more here than identifying individual pieces.

The point to focus on is how you record the split — one material lot becoming several WIP items as it moves from receiving through cutting and machining. Install a system while that splitting rule is still vague and you will find, when you try to trace backwards later, that the path to the material lot is broken. Linking material lots to WIP is one of the most common places traceability designs fail.

Electronic components – several tracking units at once

In electronic components, several tracking units exist simultaneously — supply units such as reels and trays, the mounting position on the placement machine, and the individual board number. How far down you record changes the effort substantially, so decide it against the requirements of whoever is asking. The way these units break down is set out in designing traceability for electronic components.

The extra questions at a Thai or ASEAN site

Industry events and policy discussion position Thai manufacturing as advancing digital traceability for sustainability and export under the Thailand 4.0 agenda. At export-heavy sites, it is worth assuming that customer requirements may arrive earlier than they would at a domestic plant.

On the practical side, four questions stack on top of a typical domestic rollout: whether screens and training material are in the right language where operators are Thai speakers, whether replacement devices can be sourced locally when hardware fails, whether network latency and line stability become an issue when connecting to systems at the parent company, and whether master code schemes are aligned across sites.

Master code schemes deserve particular attention, because sites that run implementations independently will always diverge. If there is any prospect of reconciling history across the group later, it is safer to set the scheme as a group standard when the first site decides it.

Common failure modes in a traceability implementation and how to avoid them

The problems reported during implementations, and the direction of the fix, break down as follows.

Alongside those, the failures that come from the ordering process itself are worth listing. They are not technical problems but process problems, which means knowing about them in advance is enough to avoid them.

Failure 1 – calling vendors before the objective exists

The most frequent one. Contact several vendors before the objective and scope are settled and each will produce a proposal angled towards their own strengths. The documents may be impressive, but the assumptions differ, so nothing is comparable and the decision collapses back to price. Write the concept document first, then make the calls.

Failure 2 – making the tracking unit too fine

This is the plan that puts every process on serial-level tracking, on the logic that if you are going to do it you may as well do it properly. More scans mean more operator time and more missed scans. More gaps mean less credible records, and records nobody trusts eventually go unused. Work back from the objective and stop at the granularity it requires.

Failure 3 – involving the floor too late

Explain the design to the floor after the specification is frozen and there will always be points that conflict with how people actually move. Changes at that stage mean extra cost and a longer schedule. Scanner mounting positions and work procedures belong in a discussion with the floor before the specification is fixed.

Failure 4 – not budgeting the effort for master data

Item master and process master cleanup is frequently excluded from a system quotation. At a company whose part numbering has never been rationalised, that work alone can run for months. Start it in parallel with vendor selection.

Failure 5 – going live without operating rules

Three things need to be decided: the recovery procedure for a missed record, the correction procedure and approver for a wrong record, and the fallback when a device fails. Go live without them and the floor builds its own conventions while the reliability of your records quietly drains away. Finish the operating procedure document before go-live, not after. Trends from implementations that settled into day-to-day operation are collected in traceability implementation case studies and the KPIs that work.

Frequently asked questions

What does a traceability system cost

It varies by delivery model. As a guide, fully custom development starts at JPY 5 million, half-scratch from JPY 2 million, a cloud package runs roughly JPY 0 to 50,000 initial with about JPY 3,000 to 50,000 per month, and an on-premise package roughly JPY 1 million to 10 million. Those are software figures only. Reading hardware, installation work, master data preparation, integration with existing systems, and training are added on top. When you take quotations, always confirm whether those five items are included.

Should we build in-house or buy a package

The deciding axis is not budget but how far your processes sit from a standard flow. If the flow is a conventional receive, process, ship sequence, a package is likely to cover it and wins on both speed and cost. Consider half-scratch or custom development only where a process genuinely cannot be expressed by standard functions. It also helps to separate the processes you consider special into those that are business rules you could change and those fixed by product specification or customer requirement. Where it is the former, adapting the process to the system keeps the total lower.

Can we use the same vendor for an overseas site

You can, but four things need checking. Whether there is a local team for on-site problems, what languages they work in, whether the time difference delays first response when a line stops, and whether replacement scanners can be sourced locally. Order everything through a vendor based only in Japan and routine software maintenance can be done remotely, but physical failures need someone on site. Confirm before signing whether the vendor has a local office or a local partner.

Can we start small and expand later

Yes, and it is the recommended approach. The usual pattern is to validate representative processes with a pilot, fold in what you learn, and then extend to the remaining processes. If expansion is the plan, though, the identification code scheme and the data storage format have to be settled at the start. Decide those ad hoc, process by process, and reconciling the data during later consolidation becomes impossible.

Is GS1 conformance mandatory

Not for every company. It is increasingly requested by export destinations and large customers, so it is something to confirm whenever you participate in an international supply chain. Even where no requirement exists today, if one is plausible later, avoid running purely on internal part numbers and provide a master data field where a standard code can be carried alongside. That single provision makes the migration far easier.

Summary

Framed as a set of buyer-side decisions, a traceability implementation comes down to the following.

• Decide the primary objective before the product. Whether the driver is regulatory and customer requirements, recall investigation, or process improvement changes the design.
• The objective determines the tracking scope, the tracking unit, and the retention period, and without those three no vendor can quote you.
• Indicative costs by model are custom development from JPY 5 million, half-scratch from JPY 2 million, cloud at roughly JPY 0 to 50,000 initial plus JPY 3,000 to 50,000 monthly, and on-premise at roughly JPY 1 million to 10 million.
• Reading hardware, installation work, master data preparation, integration development, and training accumulate on top of the software cost.
• Choose the model by how far your processes sit from the standard rather than by budget.
• Price has stopped being the first criterion in vendor selection. Regulatory readiness and process transparency are what get tested.
• Engineering capability shows up more reliably in the questions a vendor asks early on than in a reference list.
• Implementation plans run as requirements analysis, architecture and ERP integration design, pilot deployment, then training and evaluation.
• The rollout process has six steps: roles and responsibilities, the concept document, the implementation plan, the operating procedures, the schedule, and training.
• The GS1 standard rests on Critical Tracking Events and Key Data Elements, and conformance should be confirmed wherever exports or large customers are involved.
• Focus differs by industry. Assembly points at serial-level records, metal fabrication at recording material lot splits, electronics at sorting out multiple tracking units.
• The five common failures are calling vendors before the objective exists, over-fine tracking units, involving the floor too late, ignoring master data effort, and going live without operating rules.

The first thing to do is not to collect competitive quotations. It is to agree internally on the primary objective and the scope, tracking unit, and retention period that follow from it, and to write them into a concept document a few pages long. With that document in hand, every proposal you receive can be compared on the same footing.

TOMAS TECH supports shop-floor digital transformation for Japanese-affiliated manufacturers operating in Thailand, including the PEGASUS production management system. On traceability, we are happy to be involved from the model selection stage — which delivery model fits your site, and how fine your tracking really needs to be. Information gathering before you have picked a product is perfectly fine as a starting point, so please contact us whenever it is useful.

References

• Hnavi – Traceability System Implementation Costs and Steps
• Assel EMS – Traceability in the Electronic Manufacturing Services Industry
• GS1 – GS1 Global Traceability Standard
• SMART F – Benefits, Challenges and Industry Examples of Traceability Adoption
• Manufacturing IT Summit Thailand – Digitalisation Trends in Thai Manufacturing