Data inventory template for an EMS provider

What an EMS data inventory needs to capture#

An EMS data inventory captures each system that holds records about how boards are quoted, built, inspected, tested and serviced, without moving any of the records themselves. For each row it records the system, the record types, the years still accessible, the link key that connects records across systems and whether the content is customer-owned.

Organizing rows by build stage works better for an EMS than a plain list of software. A stage view shows at a glance where the chain from RFQ to field return breaks, such as an AOI system that keeps results but drops them after a rolling period, or an RMA process that lives in email.

Most EMS inventories are completed by the IT or ERP lead together with the quality director and a process engineer who knows the SMT, inspection and test equipment. The CEO or general counsel then reviews the ownership flags against master supply agreements, because those calls depend on contract language the floor team rarely sees.

The template: systems by stage of the build#

The template below lists the systems most EMS providers run. Replace the examples with your own software, then check how far back each system's records really go before you fill in the years column; installation dates overstate history more often than not.

Link keys from quote to field return#

Link keys decide whether an EMS's traceability records form one connected history or several separate ones. The serial number connects test logs to RMAs, the panel ID connects SPI and AOI results to the build, the reel ID connects a component lot to the boards it went into, and the work order ties all of them to the ERP.

Watch the hand-offs. Boards are often serialized only after depaneling, so the panel-to-serial mapping must be stored somewhere or inspection results cannot be tied to test results. Internal part numbers, customer part numbers and manufacturer part numbers also need a cross-reference, and that table belongs in the inventory as a record in its own right.

Taking stock of quote data#

Quote data is the part of an EMS inventory that mixes the most ownership positions in one place. The RFQ package and customer BOM are customer-owned, the MPN cleanse with matched alternates and lifecycle notes is your engineering work, and supplier quotes and price breaks may be governed by distributor or supplier terms that limit reuse.

List each of those as a separate row even when they live in one quoting tool. Note whether lost quotes are kept, whether quoted labor and setup assumptions are stored as fields or only in a spreadsheet, and whether NRE quotes are linked to the program they started.

Two flags on every row#

Every row needs two flags: one for customer-owned content and one for program restrictions. The first separates design data from your process data. The second catches programs that should be excluded entirely, whatever the record type.

• 1Customer-owned: yes for Gerbers, BOMs, schematics, test specifications and firmware; no for maintenance, scheduling and equipment records; mixed for inspection images, test results, NCRs and RMAs that describe a customer's board.
• 2Program restriction: export-controlled programs, customer flowdowns that prohibit any secondary use, and programs under specific confidentiality terms that need individual review.
• 3Unknown: allowed in either column during a first pass, as long as someone owns resolving it.

Write a short datasheet for each record set#

A short datasheet for each major record set makes the inventory far more useful to anyone reviewing it later. The idea comes from the Datasheets for Datasets proposal, which borrows from the electronics industry's practice of shipping every component with a datasheet and suggests every dataset carry one documenting its motivation, composition, collection process and recommended uses.

For an EMS, a few lines per record set is enough: what the AOI system records and what it discards, when false-call review started, which lines feed the MES and which do not, and any period when a system was down or misconfigured. Engineers already think in datasheets, so the format is familiar.

Illustrative: a mixed-volume EMS builds its inventory#

Illustrative: a fictional EMS serving test and measurement OEMs builds its first inventory with its IT lead and quality director. The stage view shows strong history in the ERP and QMS, AOI results kept only for a rolling period, and RMAs tracked in a shared mailbox. Serial numbers link test logs to returns, but the panel-to-serial mapping was stored only for its newer line.

The team changes AOI retention settings, moves RMAs into a ticketing system with serial numbers as a required field, and writes datasheets for the five record sets with the longest history. Customer Gerbers, BOMs and test specs are flagged and left out of scope, and one program under export controls is excluded at the program level.

How SourceX uses an EMS inventory#

SourceX uses an inventory like this in the Supply step of the SourceX five-step transaction to judge fit from metadata alone; no files are shared during the initial assessment. The customer-owned and program flags then set the scope of the Rights review, and connected history from build to field return is weighed against preparation cost under the SourceX Enterprise Data Value Framework.

For anything that is later licensed, the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization, and the datasheets described above feed directly into its provenance section. The EMS keeps ownership of its records throughout; a license grants defined use, not title.