X-bar and R charts
Variable data from a measured characteristic — dimension, weight, torque — tracking both average and spread
Connected manufacturing data from material to finished product
Manufacturing IT & Traceability Solutions
Link shop-floor events, production data and quality signals so teams can trace what happened, investigate faster and improve the process while it is still running.
Manufacturing traceability
What should a manufacturing traceability system be able to answer?
Three questions, and a system that cannot answer all three is not a traceability system.
Given a finished unit, what went into it? Which component lots, from which suppliers, through which stations, on which shift, with which process parameters and which operator sign-offs. This is backward genealogy, and it is what a customer complaint or a warranty claim turns into.
Given a suspect component or batch, which units carry it and where did they go? This is forward traceability, and it decides the size of a containment action. The difference between recalling a day of production and recalling a quarter is whether this question can be answered in minutes.
Given a process drifting out of tolerance, when did the drift start and what changed around it? This is where traceability meets statistical process control — the records exist not only to reconstruct the past but to catch a problem while the line is still running.
Data capture
Where does the data come from?
Traceability fails when data is captured where it is convenient rather than where the work happens. An operator retyping a serial number at the end of a shift produces a record that is complete and wrong.
Data capture at the station covers barcode and QR scanning at pick, assembly and pack; RFID where line-of-sight scanning is impractical; direct reads from equipment and instruments; weight, torque, temperature and other process measurements taken automatically rather than transcribed; and operator and inspector identity captured at the point of sign-off rather than reconstructed later.
Label printing belongs in the same conversation. A traceability system that depends on labels applied correctly has to own the printing — format, content, verification scan and reprint control — rather than treating it as somebody else's problem downstream.
SPC and genealogy
How does statistical process control fit alongside traceability?
Traceability
SPC
Traceability records what happened. SPC tells you whether what is happening now is still within the behaviour the process is supposed to have.
The two share the same data. Measurements captured at a station for genealogy are the same measurements that populate a control chart. Where they differ is in use: genealogy is queried after an event, control charts are watched during production.
Individual and moving range
Where measurements are taken one at a time rather than in subgroups
p and np charts
Attribute data — proportion or count of defective units
c and u charts
Counts of defects per unit or per area
Cp and Cpk
Whether the process is capable of holding the specification, and whether it is centred within it
Out-of-control conditions matter more than out-of-specification ones. A process can be producing parts inside tolerance while drifting steadily towards the limit; the chart shows that days before the inspection does.
Plant integration
How does a traceability layer connect to the systems already running the plant?
Very little of this work is greenfield. A plant already runs PLCs and SCADA, often a historian, sometimes an MES, an ERP, and a set of spreadsheets doing work nobody has migrated. The job is usually to add a traceability and analysis layer across those systems rather than to replace any of them, which makes integration design the thing that decides whether the project succeeds.
Interfaces are built on what the equipment supports — OPC UA where available, OPC DA on older installations, MQTT for lightweight event streams, direct database or file exchange where a vendor offers nothing else, and REST APIs to enterprise systems. Older lines frequently offer nothing modern at all, and the integration has to be designed around what is physically there rather than what the reference architecture assumes.
PLC and SCADA
Process values, machine state, cycle events, alarms
Historian
Time-series process data for correlation against genealogy records
MES
Work orders, routing, station confirmations where an MES is already in place
Traceability layer
ERP
Production orders, material master, batch and lot records, goods movements
Quality systems
Inspection results, non-conformance records, disposition decisions
Label and print
Format, content, verification scan, reprint control
MES strategy
Do we need to replace our MES?
Usually not. Where an MES is already in place and working, a traceability layer sits alongside it and fills the gaps it leaves — typically finer-grained genealogy, SPC across stations, or a view that spans lines the MES does not cover. Where there is no MES, a targeted traceability application often delivers what the business actually needed without the cost and disruption of an MES programme.
Compliance context
What drives traceability requirements in regulated manufacturing?
Different sectors, same underlying obligation to prove what happened.
IATF 16949
Automotive suppliers work to IATF 16949, which expects identification and traceability through production, control of non-conforming output, and records that support containment when something escapes.
ISO 13485 · FDA 21 CFR Part 820
Medical devices carry Unique Device Identification requirements and device history records, with expectations set by ISO 13485 and, for products entering the United States, FDA 21 CFR Part 820.
GMP
Pharmaceutical and food manufacturing carries batch genealogy and serialisation obligations, with GMP expectations on record integrity.
ISO 9001
General manufacturing under ISO 9001 still requires identification and traceability where it matters to conformity, and increasingly customers impose their own requirements through supply agreements regardless of any standard.
The common thread is that the record has to be reconstructable years later by someone who was not there. That is a design constraint on data retention, schema stability and export format, not only on data capture.
Project start point
Where does this work start?
With a walk of the line rather than a requirements document. Which stations exist, what each one already records, what is currently written on paper or retyped, where the identity of a unit is created and where it gets lost, and what happens today when a customer asks where a part came from.
That produces a station and data map, a gap register, and a recommendation on what to capture automatically versus what to leave alone. Most plants discover that the data they need is already being produced somewhere and simply never reaches a place where it can be queried.
Case studies
Selected work
FANUC India dispatch management
An end-to-end dispatch system covering ERP order import, barcode pick and pack, finished-goods storage, vehicle handling, reporting and stage-level traceability.
View project →
Barcode label printing and component tracking
Desktop and mobile applications for barcode master data, controlled label printing and reprint handling, integrated with customer order documents.
View project →
RFID secure document dispatch tracking
An RFID tracking and two-stage load-verification system for confidential examination material, replacing manual counting with automated box identification.
View project →
Manufacturing traceability for a battery manufacturer
Production planning, assembly-line data capture, work-in-process tracking, dashboards, dispatch workflows and SAP integration for a multi-site battery manufacturer.
View project →FAQ
Frequently asked questions
How long does a traceability implementation take?
A single line with existing barcode infrastructure and cooperative equipment can be in production in eight to twelve weeks. A multi-line plant with older equipment and no existing data capture runs considerably longer, and the variable is almost always integration with equipment rather than the application itself. The station and data map produced during discovery is what makes that estimate reliable.
Can we start with one line and extend later?
Yes, and it is the sensible way. One line proves the data model, the capture method and the integration pattern, and the plant learns what it actually wants to query before the pattern is replicated. Extending to further lines is then mostly configuration rather than design.
What happens when equipment does not support modern protocols?
This is normal rather than exceptional. Older machines are handled through whatever they do offer — serial output, file drops, direct database reads, or a gateway device that translates. Where a machine genuinely offers nothing, capture happens at the station around it, through scanning and operator confirmation, rather than pretending the data will appear.
Who owns the data?
You do. The database, the schema, the integration code and the documentation are yours, and we hand them over. Traceability data has to outlive the vendor that captured it, which is why we do not build systems that hold data in a form only we can read.
Does this work alongside our ERP?
Yes. ERP holds the business record — orders, materials, movements — and the traceability layer holds the production record at a granularity ERP is not designed for. The integration exists so that both tell the same story, and reconciling the two is usually part of the scope rather than an afterthought.