Running Discrete and Process Manufacturing in One System

Most manufacturing software picks a side early. Some platforms are built around discrete manufacturing: countable, assembled units with a bill of materials and a routing. Others are built around process manufacturing: a recipe, a formula, a batch that can’t be un-mixed once it’s made. Very few are built to handle a company that does both, which is a more common situation than the software market seems to assume.

A device manufacturer that assembles electronics but also formulates a protective coating. A food producer that batches a sauce and then assembles it into a packaged kit. A drone manufacturer that mixes a composite resin for the airframe and bolts together the electronics that go inside it. None of these companies fit neatly into “discrete” or “process.” They need both, in the same system, without maintaining two separate tools that don’t talk to each other.

Why the two modes don’t mix by default

The difference isn’t cosmetic. Discrete manufacturing produces distinct, countable units that can, in principle, be taken apart again: a screw removed, a bracket unbolted. Process manufacturing is irreversible: once flour, water, and yeast become dough, there’s no un-mixing them. That single difference cascades into everything downstream.

A discrete bill of materials is a structured list of parts and quantities, versioned, with each component traceable back to its own lot or serial number. A process formula is a percentage-based recipe, where the core planning problem is yield loss and unit conversion, not component-level traceability. Quality control differs too: discrete manufacturing checks assembly tolerances and functional tests; process manufacturing checks temperature, viscosity, and contamination. Build software around one mental model and the other one gets bolted on as an afterthought, usually with visible seams.

Where the seams show up

The most common failure point is the moment a discrete product contains a process-manufactured component, or vice versa. A drone’s airframe might start as a resin formula, cured into a shape, and then become one line item in a discrete bill of materials alongside the flight controller and motors. If your system treats formulas and BOMs as fundamentally different objects that can’t reference each other, someone ends up tracking that link manually, usually in a spreadsheet sitting next to the “real” system.

The same problem shows up in costing. A discrete BOM rolls cost up from individual component prices. A process formula rolls cost up from an ingredient percentage and a batch yield, which means an unexpected amount of scrap or a lower-than-planned yield changes the true cost per unit in a way a simple parts list never has to account for. A system built only for one mode tends to handle the other mode’s costing logic poorly, if at all.

Phantom assemblies and formulas that never touch a shelf

Both modes share one underappreciated concept: things that exist on paper but never get stocked as a standalone item. In discrete manufacturing, this is a phantom assembly, a sub-assembly that exists in engineering’s structure for clarity but is built and consumed in the same operation, never sitting in inventory on its own. In process manufacturing, the equivalent is an intermediate batch that’s mixed and immediately consumed downstream rather than bottled and shelved.

A system that only models one of these concepts forces the other one to be faked, usually with a dummy inventory item that has to be manually zeroed out after every run. It’s a small thing until you’re running it at volume, at which point it becomes a source of phantom stock and reconciliation headaches.

What a hybrid-capable structure actually needs

Handling both modes natively means a few specific things. The bill of materials engine needs to support both a structured parts list and a percentage-based formula, and let one reference the other when a process-manufactured item becomes a component in a discrete assembly. Routings need to support both discrete operations, tied to a work center and a cycle time, and process steps, tied to a vessel, a temperature curve, and a hold time. Traceability needs to work the same way in both directions: lot-based for a batch, serial-based for an assembled unit, and able to connect the two when one contains the other.

Costing has to roll up correctly regardless of which mode produced a given input, so that a discrete product with a process-manufactured sub-component gets an accurate total cost rather than a placeholder.

Why this matters more as you scale, not less

At low volume, workarounds are cheap. A dummy inventory item here, a manual spreadsheet reconciliation there, nobody really notices the cost. The problem compounds as product lines multiply and the number of components that cross between modes grows, because each workaround is a manual step that has to be repeated correctly, every time, by someone who remembers it exists.

This is the specific gap Bimp was built to close: a single specification and routing structure that treats discrete assembly and process formulation as two expressions of the same underlying model rather than two separate systems duct-taped together. For a manufacturer whose product genuinely crosses both, that’s less a nice-to-have and more the difference between a system that reflects how the product is actually made and one that requires a workaround for half of it.