E2E Traceability: Product Genealogy & Recall Precision

What E2E traceability actually means — and why the stakes got higher in 2026

End-to-end traceability (E2E traceability) is the complete, unbroken digital record of a product's material and information flow across the entire value chain — from the batch of steel or resin arriving at the goods-in dock, through every machine, station, operator, process parameter, inspection result, and handling event inside the factory, to the packaged unit arriving at the customer. Done properly, E2E traceability produces what the automotive and aerospace industries call product genealogy: a digital twin of the product's history, persistent for the lifetime of the product (typically 10–15 years for automotive, indefinite for aerospace and medical devices), in which any serial number or batch can be queried in either direction — backward to root-cause a defect, or forward to identify every affected unit in the field when something goes wrong upstream.

The topic has never been more consequential than it is now, and the reason is a convergence of three regulatory and commercial pressures that arrived more or less simultaneously between 2023 and 2026: the EU's Digital Product Passport (DPP) obligation under the Ecodesign for Sustainable Products Regulation (ESPR), which began rolling out for batteries in 2024 and will extend across textiles, electronics, construction products, and eventually every regulated product category by the early 2030s; the EU's Deforestation Regulation (EUDR) from 2024 requiring raw-material origin traceability for timber, soy, coffee, cocoa, palm oil, beef, and rubber; and the ongoing tightening of the IATF 16949 automotive quality standard, which since its 2016 revision has required traceability "at a level that enables nonconforming and/or suspect product to be identified" — a sentence that sounds modest but that has been interpreted by major OEMs into specific serial-number-level requirements for safety-relevant components that are effectively non-negotiable for any Tier-1 or Tier-2 supplier. Combined with the CSRD reporting obligations and the continuing tightening of FDA 21 CFR 820.65 for medical devices and EU MDR UDI requirements, the practical reality for manufacturers in 2026 is that traceability is no longer a nice-to-have differentiator. It is the minimum viable product for selling into most regulated industries.

I spent seven years at Johnson Controls running exactly this problem at global scale. From 2006 to 2013 I was Team Leader Business Analyst for MES and traceability in the Automotive Electronics division, responsible for rolling out and operating MES and traceability systems across more than 900 machines, 750+ end users, and 30+ distinct manufacturing processes — surface-mount soldering lines, through-hole assembly, injection-moulded housings, pressure-tested fluid components — spread across plants in China, Mexico, the United States, Tunisia, Macedonia, France, and Russia. The problems I saw recur across plants, across product families, across regulatory regimes are the problems I am going to describe in this piece, because they are the problems that trip up almost every traceability programme that attempts to scale beyond a single plant or a single product family. The methodology is not the hard part. The data discipline and the governance are the hard part. This piece is for the people who have to build or fix a traceability system in a real factory, not for the people who write the marketing brochures about it.

The directional distinction: backward vs. forward traceability

Any competent traceability system works in both directions, and the distinction matters more in practice than most introductory explanations suggest, because the two directions are typically used by different people, for different purposes, under very different time pressures.

Plants that have only one direction working reliably — usually backward, because it is the direction that the quality team builds naturally as they do root-cause investigations — discover the hard way during their first serious forward-traceability event that the two are not symmetric. Backward traceability answers one question about one unit; forward traceability answers one question about potentially millions of units, and the economics of the answer are proportional to its precision. A plant that can answer "all units produced on Line 3 between March 12 and March 18 are suspect" recalls tens of thousands of units. A plant that can answer "units with a specific SGTIN range, produced during shift 2 on machine M-014 between 14:23 and 15:47, using raw material lot LT-2026-0312-A" recalls hundreds. The cost differential in a recall with unit economics in the hundreds of dollars runs into tens of millions, every single time, and this is the specific mathematical reason traceability granularity is a board-level investment decision, not a quality-department preference.

The granularity hierarchy — batch vs. lot vs. serial vs. item-level

The single most consequential architectural decision in a traceability system is the granularity at which objects are identified and tracked, because this decision determines everything else — the cost of the system, the regulatory compliance it can support, the precision of recalls, the feasibility of predictive-quality analytics, and the amount of storage the historian layer has to carry. Four distinct granularity levels are worth naming explicitly because the industry uses the terms loosely:

The mistake I saw repeatedly at Johnson Controls, and that I continue to see now at SYMESTIC customer sites, is a plant designing a traceability system for the granularity it currently needs rather than for the granularity that its regulatory environment is moving toward. A European electronics plant that launched a lot-level traceability system in 2022 for a consumer product that will need item-level tracking under the Digital Product Passport by 2028 has a four-year window to re-architect — which is probably fine if the system was built with the architectural hooks for a later granularity upgrade, and probably catastrophic if it was not. The safe architectural pattern is: design for serial-level capability even if you only implement lot-level today, because retrofitting serialisation into a system built assuming batches is roughly equivalent to rebuilding the traceability layer from scratch.

Product genealogy — as-built vs. as-designed

Every serious traceability system eventually runs into a distinction that sounds academic but that determines whether the system can actually support the regulatory and analytical use cases it was built for. As-designed genealogy records what should have gone into a product according to the bill of materials and routing — Component A lot 42, Component B serial 7831, assembled at station S-14 using tool T-09. As-built genealogy records what actually went into the product at the specific moment it was produced — which is not always the same thing, because the real factory floor includes substitutions (engineering-approved alternate part used because the primary was out of stock), reworks (unit failed inspection, went to rework station, got Component B serial 7831 replaced with serial 7992, returned to line), and deviations (tool T-09 was out of calibration during a 47-minute window, replacement tool T-14 was used, records not always updated in the ERP). A traceability system that only captures as-designed data is technically a traceability system, but it cannot support a precision recall, because the relationship between the finished unit and its actual component genealogy is assumed rather than measured.

The aerospace industry has been rigorous about as-built genealogy for decades for obvious reasons — when a jet engine turbine fails, you need to know exactly which blade in which disk was produced by which supplier from which ingot, not what the engineering drawing said should be there. Automotive has tightened gradually, driven by the cost of Takata-scale recalls. Medical devices have tightened under MDR UDI. The pattern is consistent: the industries that invested early in as-built genealogy now have recall economics that the as-designed-only industries cannot match, and the EU Digital Product Passport regulation is going to force this transition across categories that have historically gotten away with coarser tracking. Plants starting new traceability programmes in 2026 should architect for as-built from day one; the incremental cost at build time is small, the retrofit cost is enormous.

The regulatory landscape as of 2026 — what actually matters

Six regulatory and industry-standard regimes define the traceability requirements that manufacturers selling into developed markets have to meet in 2026. Any competent traceability architecture treats these as design inputs, not as post-hoc audit concerns:

The architectural consequence of this regulatory stack is that any new traceability implementation must assume serial-level-or-finer granularity as the target state even if the current regulatory requirement only demands lot-level, because the regulatory trajectory is unambiguously toward finer granularity and the cost of retrofitting is multiples of the cost of over-engineering at build time. The one exception is food and feed, where batch/lot traceability remains the norm and is likely to remain so, because the economics of serialising individual food units do not work. But everyone making durable goods should plan for item-level.

GS1 EPCIS — the global data standard that almost nobody knows about

The most consequential piece of infrastructure for modern E2E traceability is a standard that operates so far in the background of most manufacturers' consciousness that they often do not realise they are using it. GS1 EPCIS (Electronic Product Code Information Services), currently at version 2.0 published in 2022, is the global data standard for capturing and sharing traceability events across supply chains. It defines how events are structured — the "what, when, where, why" of every handling step a product undergoes from raw material to customer — using GS1's universal identification codes (GTIN for trade items, SGTIN for serialised trade items, SSCC for shipping containers, GLN for locations). Any traceability system built to exchange data across enterprise boundaries — supplier to OEM, OEM to logistics provider, logistics provider to retailer — eventually interoperates through EPCIS, because it is the only standard that the major players have agreed on.

The practical implication for a factory-floor traceability implementation is that the MES's internal traceability data model should map cleanly to EPCIS event types (ObjectEvent, AggregationEvent, TransactionEvent, TransformationEvent, AssociationEvent) and should use GS1 identifiers natively for any object that leaves the factory. The alternative — proprietary internal identifiers that have to be translated to GS1 codes at the shipping dock — is the failure mode I watched derail three separate customer projects at Johnson Controls in the late 2000s, each time with the same symptom: the internal MES worked, the OEM's traceability query system worked, but the mapping between the two was done in Excel spreadsheets by a quality engineer who eventually left the company, and nobody could reproduce the mapping logic afterward. EPCIS-native identification from day one is the cheap insurance against this failure mode. GS1 publishes the full EPCIS specification and operates regional member organisations (GS1 US, GS1 Germany, etc.) that handle identifier allocation.

The MES, ERP, SCADA, historian stack — who does what

E2E traceability is not a single-system problem. It requires coordinated data flow across four distinct system layers, each of which contributes information that the traceability record needs and none of which can produce the complete record alone.

The hardest integration problem in practice is not any single interface — it is the consistency of the data model across all four layers. A unit produced on Line 3 at 14:23:07 must be identified with the same canonical identifier in the ERP (production order operation), the MES (unit genealogy event), the SCADA (batch context), and the historian (time-range of process data). Plants that neglect this alignment end up with traceability systems that technically work but that produce different answers depending on which system you ask — which is worse than not having traceability at all, because it gives the quality team false confidence in data that does not actually reconcile. The investment in a consistent canonical data model across all four systems is the single biggest predictor of whether a traceability programme will still be functional in five years.

From seven years of global traceability rollouts at Johnson Controls Automotive Electronics: the pattern that I watched recur across more than 900 machines, 30+ distinct manufacturing processes, and seven countries — plants in Changchun, Monterrey, Holland (Michigan), Sousse (Tunisia), Skopje, Rennes, and Nizhny Novgorod — and the pattern I still see at SYMESTIC customer sites today, is that the traceability architecture decision that determines whether the system will scale or collapse is made in the first three months of the project and is never revisited, even though it should be. The decision is: at what granularity and with which identifier system will the factory bind process events to units. The three archetypes I saw at Johnson Controls, in decreasing order of frequency: (1) plants that started with proprietary internal identifiers and planned to "add GS1 mapping later" — all of them eventually rebuilt the binding layer at multi-hundred-thousand-dollar cost within five years; (2) plants that used GS1 SGTIN natively from day one but bound process events at lot-level rather than serial-level — about half of them had to re-architect when an OEM customer imposed a specific-characteristic serial requirement; (3) plants that used GS1 SGTIN natively and bound every process event to the specific unit in real time at capture — these were the plants that handled the 2013 Takata-era recall waves without existential pain, because they could answer precise-scope forward-traceability queries in hours rather than weeks and recall economics were proportional to actual defects rather than worst-case scope. The single most consequential architectural choice on a traceability programme is the binding granularity, and most plants make it wrong — they underinvest because the regulatory trigger has not yet arrived, and then the trigger arrives and they are left with a system that technically works but that cannot support the precision the business actually needs. The specific recommendation I give every SYMESTIC customer that is designing a new traceability implementation: build for SGTIN-native, serial-level binding of every process event, even if you currently only need lot-level, because the marginal cost of over-building at architecture time is small (maybe 10–15% of total implementation cost) and the cost of retrofitting is multiples of the original build cost. One more concrete number from the Johnson Controls era that has stayed with me: we calculated in 2011 that every increment of granularity (batch → lot, lot → serial, serial → item-with-process-data) reduced the average recall scope by roughly 7–12x in the incidents we actually had to handle. A $50M recall at batch-level becomes a $5M recall at serial-level for the same underlying defect. That is the quantitative basis for why serial-level tracking is not a nice-to-have; it is a balance-sheet-protection mechanism, and the plant managers who understand this have radically different traceability-investment conversations with their CFOs than the ones who don't.

The Recall Width Problem — why granularity equals money

The definitive economic argument for fine-grained traceability is what I call The Recall Width Problem. When a defect is identified in the field — a component failure, a quality escape, a regulatory non-conformance — the plant must answer one question: which other units are affected? The breadth of that answer is the "recall width", and it is determined almost entirely by the granularity of the traceability system that captured the original production data. A plant that captured batch-level data must recall everything in the affected batches. A plant that captured serial-level data with process-parameter genealogy can isolate exactly the units that experienced the specific anomaly and recall only those. The economic consequence is dramatic, consistent across industries, and almost always underestimated at the time of the traceability-system investment decision:

The Takata airbag inflator recall (2014–2020) is the reference case for recall-width economics in modern automotive. Initially bounded by batch-level supplier information, the recall eventually spanned over 100 million inflators across 19 OEMs because the traceability data to narrow the scope did not exist at sufficient granularity. Industry estimates place the total cost — including replacement inflators, labour, logistics, litigation, and brand damage — above $25 billion. A fraction of that cost would have been sufficient to build item-level process-genealogy tracking at every Takata production line from the late 1990s onward. The economics of fine-grained traceability are not theoretical; they are the largest single industrial risk-management case study of the last quarter-century, and every manufacturer selling into regulated markets should treat it as the baseline cautionary example.

Traceability Debt — the silent liability that grows every year

A second named concept worth surfacing because it is almost never discussed explicitly but predicts the majority of traceability-system failures I have seen: Traceability Debt. Analogous to technical debt in software systems, traceability debt is the accumulated cost of historical gaps, inconsistencies, and missing linkages in a plant's traceability records. It grows quietly over years — a batch for which the component lot was recorded by hand on a paper sheet that was lost, a six-month period when the historian integration was broken and process data was not bound to units, a supplier change that was implemented without updating the genealogy model, a plant acquisition that added a factory with a different identification scheme that was never harmonised. Each of these events is individually minor. Together they create a patchwork of historical records that works fine until a recall event requires traversing them, at which point the accumulated gaps turn into expensive forensic work, inflated recall scopes (because uncertain data has to be treated as worst-case), and in the extreme, regulatory findings that the plant cannot demonstrate compliance with its own traceability obligations.

The specific manifestations I have encountered most often:

1. The Excel Shadow System. A plant's official traceability runs in the MES, but there is an Excel spreadsheet that someone maintains "because the MES doesn't quite capture X." When that person leaves, the spreadsheet is forgotten. Two years later a recall requires the data that was only in the spreadsheet, and it is gone.
2. The Unsynced Rework Path. Units that fail inspection go through a rework station that is not connected to the MES. They reappear on the production line with their original serial numbers but with unrecorded component substitutions. The genealogy record shows the original as-designed assembly; the actual product has an undocumented as-built state. During a recall, these units cannot be correctly classified.
3. The Plant Acquisition Integration Gap. An acquired plant runs a different MES or a different identification scheme. The integration project is scoped as "harmonisation within 18 months" and then postponed indefinitely. Years later the units from that plant cannot be queried against the same traceability data model as the rest of the network.
4. The OPC UA Configuration Drift. A machine's signal mappings change during maintenance, the MES's traceability configuration is not updated, and the process data captured for subsequent units points to the wrong parameters. Discovered during a quality investigation when the genealogy no longer matches reality.

The discipline that prevents traceability debt is the same discipline that prevents its software analogue: explicit governance, with periodic audits of the data pipeline, explicit ownership of every identifier flow, and intolerance for shadow systems and workarounds. Plants that treat traceability as a one-time implementation and a steady-state operational concern accumulate debt continuously; plants that treat it as an ongoing engineering discipline with dedicated ownership stay clean. The cost of the discipline is real but modest — typically a 0.5–1 FTE per plant dedicated to traceability data governance. The cost of the debt is unpredictable but capped only by the worst recall scenario the plant is exposed to, which in automotive and medical devices can be existential.

The EU Digital Product Passport — what changes between now and 2028

The single most consequential traceability-related regulatory development currently rolling out is the EU Digital Product Passport under the ESPR framework. Battery passports began mandatory compliance in February 2027 for batteries above 2 kWh (with preparation work since 2024); textiles and apparel are scheduled for 2027–2028; electronics and construction products for 2028–2030; and the framework is designed to broaden progressively across the regulated product scope. For any manufacturer selling into the EU market in any of these categories, the practical requirement is:

1. Item-level digital passport. Every unit carries a machine-readable identifier (QR code, NFC, RFID) linking to structured data accessible to consumers, repairers, recyclers, and regulators.
2. Material and process genealogy. Passport content includes material composition, origin of significant raw materials, process parameters that affect circularity (temperatures that affect recyclability, chemical treatments that constrain reuse), repair history, and end-of-life handling instructions.
3. Structured data standard. Passports use JSON-LD-based schemas defined per product category, maintained by the European Commission and industry working groups. The infrastructure layer is designed to be interoperable with GS1 EPCIS.
4. Persistent access. The passport must remain accessible for the useful lifetime of the product — indefinitely in practice, with obligations on the manufacturer to maintain access even after the product is sold and resold through secondary markets.

The architectural consequence for a factory-floor traceability system is that the MES and historian layers must be capable of producing the data that populates the passport, at item level, with regulatory-grade auditability, and that the data must survive the manufacturer's own ERP and MES lifecycle changes for decades. Plants that are today on lot-level traceability and that will be covered by DPP categories in the 2028–2030 horizon have approximately a three-year window to architect the upgrade. That is a short window for a full MES and historian re-architecture, which is why I recommend every European manufacturer I work with to treat DPP readiness as a design input to any MES investment made in 2026 or 2027, not as a future problem to be solved separately.

How this fits into the SYMESTIC platform

SYMESTIC implements E2E traceability as a native capability of the cloud-MES platform rather than as a bolt-on module, which is the only architecture that actually works at scale. The platform uses GS1-native identifiers (SGTIN, GTIN, SSCC, GLN) throughout, binds process events to units at serial-level granularity by default with lot-level as a configurable simplification for food-and-beverage-style use cases, and exposes EPCIS 2.0-compliant event data for supplier-OEM-retailer interoperability. The historian layer — see industrial data historian for the architecture — stores item-level as-built process genealogy with tiered retention matched to the regulatory horizons of each customer's industry (15+ years for automotive IATF 16949, indefinite for aerospace and medical device UDI). Change control is the mechanism by which recipe and process-parameter revisions are linked into the genealogy so that as-built records remain accurate across engineering changes; recipe management provides the master-data foundation that defines what should have gone into each unit; process documentation provides the ISA-95 baseline that makes the traceability model coherent with the rest of the factory architecture. For EU Digital Product Passport readiness, the platform includes the data-export and persistent-URL mechanisms that DPP rollout timelines require, configurable per product category. For customers with legacy plants on older traceability systems — the Johnson Controls-scale situation I described in the amber — SYMESTIC handles integration via the REST API and OPC UA subscriptions without requiring wholesale replacement of existing OT systems, which is usually the right retrofit path. See also predictive quality for the analytics layer that turns traceability data into forward-looking quality signal, rolled throughput yield for the upstream quality metric that benefits directly from genealogy-aware measurement, alarm management for the event-layer that captures the process-anomaly signals that narrow the recall width, and A3 problem solving for the investigation discipline that uses backward-traceability data to drive corrective action. The customer-facing product modules most relevant to traceability are process data, production metrics, and production control.

FAQ

What is E2E traceability?
End-to-end traceability is the complete digital record of a product's material and information flow across the entire value chain — from raw material arrival through every production step, inspection, and handling event to final delivery. A mature implementation produces product genealogy: a persistent digital twin of each unit's production history, queryable backward for root-cause analysis and forward for containment or recall. The regulatory baseline for durable goods in 2026 includes IATF 16949 (automotive), FDA 21 CFR 820.65 and EU MDR UDI (medical devices), GS1 EPCIS 2.0 (global data interchange), ISO 22005 (food and feed), and the progressively-rolling-out EU Digital Product Passport under ESPR.

What is the difference between backward and forward traceability?
Backward traceability starts from a specific defective unit and traces back to components, machines, operators, shifts, and process parameters that produced it — the root-cause-analysis direction. Forward traceability starts from a suspect cause (a bad raw-material lot, a machine out of spec) and identifies all finished units that are affected — the containment and recall direction. Both directions matter, but they are used by different people under very different time pressures; forward traceability in particular has economics that are dominated by precision (the recall width problem).

What is product genealogy?
The complete digital record of a specific unit's production history — which component serial numbers or lots were assembled into it, which machines processed it, which operators handled it, which process parameters (torque, temperature, cycle time) the process produced for this specific unit, and which inspection results applied. Aerospace has maintained item-level genealogy for decades; automotive has tightened progressively since the Takata era; medical devices are now required to under UDI; the EU Digital Product Passport is extending this to broader product categories through 2030.

What is the difference between as-built and as-designed genealogy?
As-designed genealogy records what the engineering bill of materials and routing say should have gone into a product. As-built genealogy records what actually went into the product at the moment of production, including substitutions, reworks, and deviations. Only as-built genealogy supports precision recalls; as-designed alone assumes the actual product matches the plan, which is often false in high-volume manufacturing. Plants designing new traceability systems should architect for as-built from day one; retrofitting it is far more expensive than including it at build time.

What is GS1 EPCIS and why does it matter?
EPCIS (Electronic Product Code Information Services), currently at version 2.0 published in 2022, is the global GS1 standard for capturing and sharing traceability events across supply chains. It defines event structures (ObjectEvent, AggregationEvent, TransactionEvent, TransformationEvent, AssociationEvent) and uses GS1 identifiers (SGTIN for serialised trade items, SSCC for shipping containers, GLN for locations). Any traceability system that exchanges data across enterprise boundaries interoperates through EPCIS; building an MES with EPCIS-native identification from day one is dramatically cheaper than retrofitting GS1 mapping later.

What traceability granularity does IATF 16949 require?
IATF 16949 §8.5.2 requires traceability "at a level that enables nonconforming and/or suspect product to be identified." The sentence sounds modest but is interpreted by major OEMs (VW Group, Stellantis, Ford, GM, Toyota) through customer-specific requirements that typically mandate serial-level tracking for safety-relevant characteristics — airbag components, braking systems, steering, battery modules in EVs. For Tier-1 and Tier-2 automotive suppliers in 2026, planning for lot-level only is effectively planning to exit the automotive market within a few years.

What is the EU Digital Product Passport?
An item-level digital record linked to every regulated product via QR code or NFC, containing material composition, process genealogy, repair and end-of-life information, and other circularity-relevant data. Mandated by the EU Ecodesign for Sustainable Products Regulation (ESPR, 2024), with staged rollout starting from batteries in 2027 and extending progressively across textiles, electronics, construction, and eventually most regulated product categories by the early 2030s. For manufacturers selling into the EU, DPP readiness is becoming a design input for any MES and traceability investment made in 2026 onward.

What is The Recall Width Problem?
The economic principle that the cost of a product recall scales almost linearly with the scope of the recall, and that scope is determined almost entirely by the granularity of the traceability system that captured the original production data. A batch-level system forces recalling entire batches (10,000–100,000 units) for a defect that may affect dozens; a serial-level-with-process-data system isolates exactly the affected units. The recall-cost multiplier between batch-level and item-with-process-genealogy is typically 20–50x for a given underlying defect, which is the quantitative reason investment in fine-grained traceability is a balance-sheet-protection decision rather than a quality-department preference.

What is Traceability Debt?
The accumulated cost of historical gaps, inconsistencies, and missing linkages in a plant's traceability records — the traceability analogue of technical debt in software. It grows silently through lost paper records, broken historian integrations, unsynced rework paths, plant acquisitions with different ID schemes, and OPC UA configuration drift. The debt is invisible until a recall requires traversing the historical records, at which point it inflates recall scope, extends investigation time, and can trigger regulatory findings. Prevention requires explicit governance with dedicated ownership (typically 0.5–1 FTE per plant) and intolerance for shadow systems and Excel workarounds.

Do I need an MES for E2E traceability?
Beyond a certain complexity threshold, yes. Paper records, Excel spreadsheets, and SCADA-only systems do not scale reliably to serial-level genealogy with as-built accuracy across multiple plants. The specific threshold depends on industry and regulatory exposure: a single-plant food producer on batch-level traceability may operate adequately without an MES; an automotive Tier-2 supplier with IATF 16949 obligations essentially cannot. The right question is not whether an MES is necessary but whether the existing traceability architecture will scale to the regulatory and commercial obligations the plant will face over the next 5–10 years.

Related: MES: definition, functions & benefits · OEE: definition, calculation & practice · MES software compared · OEE software · Process documentation · Alarm management · Shop floor control (SFC) · Predictive quality · Schedule adherence · On-Time Delivery · Rolled Throughput Yield · Scrap rate vs. rework rate · Industrial data historian · Recipe management · Change control · A3 problem solving · MDE (machine data acquisition) · BDE (production data acquisition) · Process data module · Production metrics module · Production control module · Automotive · Metal processing · Food & beverage · For COOs & plant managers · For operational excellence. External references: IATF 16949 global oversight (automotive quality management standard including §8.5.2 traceability requirements) · GS1 EPCIS 2.0 specification (global standard for traceability event data interchange) · FDA UDI system for medical devices (21 CFR 820.65 and 21 CFR 830) · European Commission Digital Product Passport (ESPR regulation rollout portal) · ISO 22005 traceability in food and feed chains.

About the author

Christian Fieg

Head of Sales at SYMESTIC since 2021. Previously Senior Sales Manager at Dürr AG, Sales Manager MES DACH at iTAC Software, and Manager Center of Excellence at Visteon Corporation with end-to-end global responsibility for the MES programme. From 2006 to 2013 Team Leader Business Analyst Global Electronics at Johnson Controls Automotive Electronics, with global MES and traceability responsibility for 900+ machines, 750+ users, and 30+ manufacturing processes across soldering, assembly, and injection moulding in China, Mexico, USA, Tunisia, Macedonia, France, and Russia. Started as maintenance engineer at Johnson Controls Rastatt in 1998, Six Sigma Black Belt in headliner production for three years, SPS engineer in the JIT Center of Excellence. 2006 expatriate assignment at FAWER Johnson Controls in Changchun, China, bringing the plant to best-in-class performance. Author of OEE: Eine Zahl, viele Lügen (2025), a novelistic treatment of how OEE values get systematically inflated in real factories. Expertise: Manufacturing Execution Systems, OEE, shopfloor digitalisation, Six Sigma (Black Belt), end-to-end traceability, product genealogy, IATF 16949, GS1 EPCIS, smart factory, production data acquisition, PLC programming, JIT/JIS processes, automotive production, global MES rollouts, cloud MES. · LinkedIn