When an OEM product first enters manufacturing, a part number is rarely enough to define the production.
The first production order usually comes with a complete Production Package: BOMs, Gerber files, PCB and assembly drawings, enclosure drawings, labels, packaging specifications, test requirements, and customer quality requirements.
For one LoRa-based IoT wireless geotechnical and structural monitoring system, this was exactly how the project started. The product family included battery-powered data acquisition devices and wireless gateways designed for outdoor applications such as tunnels, dams, mines, railways, and construction sites. The finished products combined PCBA, protective metal enclosures, testing, labeling, and packaging.
During the first few production cycles, the complete production package was close to 40 MB even after compression. It was too large to send as a normal email attachment and had to be transferred through a file-sharing platform.
Later, after samples, pilot production, and the first repeat orders, the situation became very different.
A later production order could be released with a PO of around 10 KB.
The PO contained little more than:
SKU
Quantity
Delivery Requirement
The information had not disappeared.
It had gradually been clarified, confirmed, standardized, and incorporated into the manufacturing process.
The product had moved from something that needed to be explained through a large production package to something that could be repeatedly manufactured by referring to a defined SKU.
That transition is what this case is really about.
The product family contained eight SKUs, covering different data acquisition devices and a wireless gateway.
From the customer’s perspective, these were eight separate products.
From a manufacturing perspective, however, they were highly similar.
Several of the data acquisition products were based on only a few fundamental platforms. Differences between SKUs mainly involved PCB dimensions, enclosure structures, regional wireless configurations, module configurations, and firmware. Different SKUs also had different packaging requirements, and the product and outer-carton labels had to correspond to the correct model.
Some of the hardware differences were very small.
A few capacitors. A few inductors. A different module configuration. In some cases, even the hardware module could be from the same series and the same part number, with the distinction coming mainly from the firmware configuration.
This created a very practical manufacturing issue:
The more similar the SKUs are, the more important variant control becomes.
The challenge was not simply to build eight products.
It was to prevent eight highly similar products from being treated as one product during production, testing, labeling, and packing.
At this stage, the part number was therefore only a reference point.
The production team still needed the complete Production Package to understand which BOM, PCB version, enclosure, label, packaging method, test procedure, and quality requirements belonged to each SKU.
The first sample production did not reveal one major problem that stopped the project.
Instead, it exposed several smaller details that had not yet been defined precisely enough for repeat manufacturing.
The original product used a finished cast-aluminum enclosure from an overseas supplier. Once the product entered a new manufacturing supply chain, a local alternative was needed.
There was no identical replacement available.
This had already been discussed with the customer before sourcing. The customer defined the key requirements for protection, impact resistance, and environmental resistance, while allowing the replacement structure to be as close as practical to the original product.
We therefore sourced a structurally similar enclosure for evaluation.
The sample showed that the mounting-hole positions did not match the existing PCB.
Because the difference had been anticipated during the earlier discussion, the customer decided to modify the PCB mounting-hole positions rather than continue looking for an identical enclosure.
The important point was not simply that the holes did not match.
The sample had helped define how the agreed requirements should be implemented in the new manufacturing environment.
The customer had already specified a label requirement, but the material was not fully defined.
After seeing the sample, the customer found that the label could detach too easily and provided a more specific requirement for subsequent production.
The original quotation material mentioned painting, but did not define the exact areas clearly enough.
This was confirmed with the customer during production and then incorporated into the subsequent manufacturing requirements.
These were relatively small details.
But they demonstrated an important point:
A production package can contain a large amount of information without defining every manufacturing detail completely.
Some requirements only become precise when the product is physically built and reviewed.
After the samples were confirmed, the project moved into pilot production.
The eight SKUs were produced separately, with quantities of approximately 100–200 units per SKU.
At this stage, the product itself was already well understood.
The focus shifted to whether the requirements could be reproduced under actual production, packaging, and transportation conditions.
After receiving the pilot production, the customer found that some units had insufficient battery power.
Further investigation showed that the product firmware used a sleep mode, while the relatively heavy battery was not held firmly enough by the original battery holder.
During transportation, movement of the battery could cause intermittent contact and repeated restarts of the device.
The proposed solution was to add an approximately 0.3 cm silicone pad above the battery to provide additional support and reduce movement during transportation.
The customer accepted the solution.
This was not simply a case of a component being defective.
The issue only appeared when the product structure, battery, firmware behavior, and transportation conditions interacted.
Once understood, however, the solution could become part of the subsequent manufacturing requirements rather than remaining a one-time fix.
The blue logo printed on the metal enclosure revealed another type of gap.
The original artwork defined the logo and its position, but did not specify an exact color reference.
After the pilot order, the customer noticed a difference between the production color and the expected sample.
The customer subsequently specified a Pantone reference.
From that point onward, “blue” was no longer a visual description.
It became a manufacturing requirement that could be produced and checked consistently.
This is a small example, but it illustrates a broader transition:
Something can be understandable to a person without yet being specific enough for repeatable manufacturing.
The same issue appeared in packaging.
Because several SKUs were highly similar, different SKUs were initially packed together in a larger outer carton to make better use of available space.
The customer then clarified a requirement that had not previously been defined in enough detail:
Different SKUs could not be mixed in the same outer carton. One outer carton had to correspond to one SKU.
From that point onward, the requirement became part of the standard production method.
This is important for multi-SKU products because variant control does not end when the PCBA is assembled.
It extends through the complete product flow:
Product → Product Label → Outer Carton Label → Shipment
A product can be assembled correctly and still become the wrong shipment if the SKU is not controlled through the final packaging stage.
The finished product used a metal enclosure, which made the completed unit relatively heavy.
After the first full pilot shipment, some cartons arrived damaged or deformed.
A review of the original packaging documentation showed that the carton material and specification had not been clearly defined.
The packaging supplier had therefore followed a more general industry specification, which was not sufficient for the actual product weight.
The carton material was subsequently upgraded to a specification more suitable for the finished product. The change increased packaging cost by approximately USD 0.40 per set, and the customer accepted the change.
The important change was not simply using a stronger carton.
The packaging requirement itself had become more complete through actual production and transportation.
This is one reason pilot production matters in OEM manufacturing:
It does not only validate the product. It also validates whether the production requirements themselves are complete enough.
The product also used waterproof cable glands.
After the first production, the customer commented that the glands had been tightened more than necessary and could be difficult for an end user to loosen.
The intended requirement was not “the tighter, the better.”
It was simply:
tight enough to prevent loosening during transportation, without unnecessary over-tightening.
A requirement like this is difficult to control if it exists only in an email or in someone’s memory.
It therefore became a specific SOP requirement, including the corresponding torque information, and was confirmed by the customer.
A one-time comment had become a repeatable production instruction.
Traceability was another requirement raised early in the project.
The customer wanted information that could be linked to the individual unit, production batch, and production date.
The existing customer workflow already included software for device programming and label generation. Because the product had to be paired with its corresponding label during production, the existing process provided a practical starting point.
A logging function was added to the workflow.
During sample production, the process was already tested in the same form intended for later production, and the relevant records were retained with the production documentation.
As a result, if an end user later reported a problem, information from the product label or package could be used to identify the corresponding unit and link it back to the relevant production batch and date.
The important point was not a particular software system.
It was that the customer’s traceability requirement had become part of an actual production workflow.
The project already had quality and test requirements at the beginning.
For example, the customer had defined basic appearance expectations and functional testing requirements.
But the first set of requirements did not necessarily cover every practical acceptance condition that would matter in repeat production.
As sample and pilot production progressed, additional questions became clear:
What condition should a label meet?
How should a color difference be judged?
What constitutes an unacceptable cosmetic defect?
How should different SKUs be packed?
What packaging condition is acceptable?
How should certain assembly operations be performed?
These requirements were not all created at the beginning.
They became clearer through actual production and customer feedback.
Before mass production, the customer consolidated the requirements into a more complete QC Standard, including quality criteria, defect definitions, and handling requirements.
The customer defined and approved the quality standard.
The manufacturer’s responsibility was different:
to determine whether those requirements could be translated into an executable production and inspection process.
In simple terms:
QC Standard answers: What is acceptable?
SOP answers: How should it be produced and inspected?
For this particular project, SOP became especially important because the eight SKUs were so similar.
Several products had nearly identical appearances and assembly structures.
The differences could be limited to a few passive components, a module configuration, or firmware.
In such a situation, production should not depend on an operator remembering which small differences belong to which model.
The eight SKUs were therefore treated as separate production projects.
One SKU was completed before moving to the next.
Each SKU also had its own SOP, even when many assembly steps were exactly the same.
The purpose was not to create eight completely different manufacturing methods.
The purpose was to make the differences explicit instead of leaving them to operator memory.
Similarity is not the same as interchangeability.
For a multi-SKU OEM program, repeatability means more than producing the correct product repeatedly.
It also means preventing a similar product from becoming the wrong variant.
Packaging was controlled in the same way.
After packing, approximately 30% of finished units were randomly checked to verify the relationship between:
Outer Carton Label → Product Label → PCBA Serial Number
The customer requirements had now moved through a complete chain:
Customer QC Standard → SKU-Specific SOP → Production & Inspection Execution
The customer defined the acceptance criteria.
The SOP translated those criteria into manufacturing actions.
Production and inspection execution made those actions repeatable.
The most visible change came with the second mass-production order.
During the first production, the customer and manufacturing team still needed to review and confirm a large amount of information.
By the second production order, the manufacturing definition was already established.
The customer could simply send a PO.
The manufacturing team would then reference the controlled manufacturing information, including:
Gerber name and revision
BOM name and revision
Enclosure drawing number
Packaging reference
Label artwork reference
These references were confirmed in the PI before production.
The customer no longer needed to explain the product from the beginning.
The PO itself could remain simple:
SKU
Quantity
Delivery Requirement
There is an important distinction here.
A simple PO does not mean simple manufacturing control.
The opposite is true.
The PO can be simple because the BOM, Gerber, enclosure, packaging, labeling, QC Standard, and SOP references have already been defined and controlled.
The PO is simple because the manufacturing definition behind it is no longer ambiguous.
Looking back, the change from an approximately 40 MB Production Package to an approximately 10 KB PO represents two very different stages of the same manufacturing program.
At the beginning:
“Here is our product. Please understand it through this package of information.”
Later:
“Here is the PO. Please manufacture this SKU according to the established definition.”
Between those two points was a process:
Production Package
↓
Sample Production
↓
Customer Feedback
↓
Pilot Production
↓
Customer QC Standard
↓
SKU-Specific SOP
↓
Production & Inspection
↓
Repeat Production
Each sample made the product requirements more specific.
Each pilot run tested whether those requirements were practical under real manufacturing and transportation conditions.
Each customer feedback cycle converted an individual observation into a clearer requirement.
And once those requirements were incorporated into SOPs and validated through production, the product no longer needed to be re-explained from the beginning every time an order arrived.
The information had not disappeared.
It had been embedded into the manufacturing definition behind the SKU.
For multi-SKU industrial electronics—such as IoT devices, wireless data acquisition units, industrial gateways, field monitoring equipment, and other products combining PCBA, metal enclosures, functional testing, labeling, and packaging—this transition is often one of the most important steps between NPI and stable repeat production.
The first successful production proves that a product can be built.
Repeat production proves that the manufacturing definition is stable enough to build it again.
And eventually, a mature Part Number becomes more than a product identifier.
It becomes a compact reference to a manufacturing definition that has already been defined, validated, customer-approved, document-controlled, and made repeatable.
