Item Master Data: 96 Drone Configurations, 66 That Can Actually Fly

An electronics plant builds one quadcopter. Then customers start asking: a bigger frame for longer flights, a thermal camera instead of a day camera, a different radio band, a larger battery, a GNSS module that holds up better against interference. Every request is reasonable. A year later, engineering maintains dozens of nearly identical BOMs, and one firmware update means editing all of them by hand.

Item master data is the central record of every item a plant buys, makes, stores or sells: its code, description, unit, characteristics, and the BOM and routing that define how it is made. Product variants are versions of one basic product that differ in a few options. In electronics and defense-tech assembly, where almost every module of the product has an option, the way you model variants decides whether your item master is a tool or a second full-time job.

How product variants multiply: the drone arithmetic

Take one quadcopter platform and count the options on its main modules:

• Frame: 7-inch or 10-inch (2)
• Camera: day, thermal, zoom, or day + thermal dual (4)
• Radio link: three frequency bands (3)
• Battery: 5,000 mAh or 8,000 mAh (2)
• GNSS: standard or interference-resistant with a special antenna (2)

2 × 4 × 3 × 2 × 2 \= 96 combinations. But not all of them can fly. The dual camera is too heavy for the 7-inch frame, and the 8,000 mAh battery doesn't fit it either. So the 7-inch frame allows 3 cameras × 1 battery × 3 radios × 2 GNSS \= 18 variants, and the 10-inch allows 4 × 2 × 3 × 2 \= 48. That's 66 valid variants out of 96.

That's the first lesson: variants aren't just a multiplication. They come with configuration rules, and those rules are engineering knowledge. If they live only in the heads of two engineers, sales will sooner or later promise a 7-inch drone with a dual camera.

One matrix BOM instead of 66 copies

If each variant has its own BOM of about 45 lines, you're maintaining 66 × 45 \= 2,970 lines, and most of them are copies. When firmware v2.4 replaces v2.3, the change has to reach all 66 BOMs, and the one that gets missed ships with old firmware.

A matrix BOM (also called a configurable or variant BOM) holds all the possible components of the platform once, and each line has a rule for when it's used:

• motors and propellers: by frame size (7-inch or 10-inch set)
• camera and mount: by camera option; the dual camera also brings a two-axis gimbal
• radio module and antennas: by frequency band
• battery pack: by battery option
• flight controller with firmware: one line for every variant

The configuration "10-inch, thermal, band 2, 8,000 mAh, interference-resistant GNSS" gets its BOM from those rules in seconds. A firmware change is one edit, and it reaches all 66 variants at once. A matrix routing does the same for operations: every drone goes through assembly, flashing, calibration and a test flight, but gimbal calibration exists only for the dual camera. The full BOM and routing of one drone are laid out in drone BOM and routing.

Think of buying a laptop online. You pick memory, storage and screen, and the store doesn't keep a spec sheet for every combination. It keeps one configurator with rules. Nobody calls that less precise.

Myth: "Every variant needs its own BOM"

It feels safer. It's the opposite. With 66 copied BOMs, a correction reaches the 60 you remembered and misses the 6 you didn't. With one matrix, the correction reaches all of them. The precision is in the rule, not in the number of copies.

When "the same" isn't the same item

The opposite mistake is merging things that only look alike. Two thermal cameras with the same housing and connector can differ in sensor resolution: 640 × 512 and 384 × 288. Mechanically they're interchangeable. For a contract that specifies 640 × 512, they're not. If they share one code, the stock report says "yes" and the customer's acceptance test says "no."

The test: combine two things under one code only if they can replace each other for every use. The same question applies to sub-assemblies like the propulsion set, as discussed in semi-finished goods.

Alternatives: 1:1 and 1:many

Some components can replace others without being the same item:

• 1:1. Motors from supplier A or B, both qualified with the same KV rating and thrust. Two codes, because you need to know which motor went into which drone, but either satisfies the BOM.
• 1:many. A combined GNSS-and-compass module can be replaced by a separate GNSS module, a separate compass board and a connecting cable. One component is replaced by three.

Customer versions without new SKUs

Five customers want their own labels, packaging language and preset radio channels. Multiply 66 variants by 5 and you get 330 codes that differ only in a sticker and a settings file. Keep the 66 variants and record the customer version on the production batch instead. The hardware stays the same, the plan stays readable, and anyone can still see which drones were prepared for which customer. How that record pays off when a customer asks questions later is covered in batch traceability.

How factory.online handles drone variants

In factory.online, the 66 valid variants are generated from characteristics in one step instead of being entered one by one. A matrix BOM and a matrix routing supply the motors, camera, radio and operations for each configuration. When a sales order arrives for "10-inch, thermal, band 2", it creates manufacturing demand for that exact configuration, and MRP shows which modules are short. The two motor suppliers are set up as a 1:1 alternative, and the separate GNSS module and compass as a 1:many alternative. Designs can be imported from PDM or PLM systems rather than re-entered. The same approach suits any product with many modules and options, which is why make-to-order vs make-to-stock is worth a look for deciding which modules to stock.

If your item master grows faster than your team can maintain it, book a demo and bring one platform with its options.