Bill of Materials BOM, BOM BOM BOM, BOOOOOOMMMMM

August 9, 2011 4:53 PM

We're trying to figure out the best way to program our ERP to handle BOMs (Bill of Materials) as it relates to *committed* (aka "reserved") qtys. Is there an industry standard or best practices?

It really comes down to: when a BOM parent is committed (e.g. a customer orders 100 pcs), how should that reflect on the BOM parent and how should it be reflected on the BOM child?

Assume that the BOM parent in question is a boxed set of 3 medals ("Medal Set"). So the BOM children are medal #1, medal #2, medal #3, and the box.

We stock all parts in our warehouse. BUT sometimes we'll order complete sets from the factory.

For this example, assume a customer orders 100 sets, and assume we have 0 completed sets in inventory, and 100 pcs each of all the BOM children parts.

The way our system is current set up: BOM parent shows 100 pcs reserved. BOM children also show 100 pcs reserved each.

The problem with this scenario is, if we decide to bring in 100 or more completed sets from the factory. BOM parent would then show 100 pcs on order (from the factory), but the BOM children would not. Someone looking at inventory for the BOM children might be under the impression that we're running low and need to order more inventory (since they'd see 100 pcs on hand, minus 100 pcs reserved equals 0 pcs available).

This has become a problem because we have multiple sets that use the box, and sometimes we'll see qty available for the box in the negatives between the time we place an order for the completed set from the factory and the time the sets arrive (which could take weeks). So in this scenario it's hard to tell the true availability of the boxes.

We've also discussed having the system NOT reserve the BOM children (so in this case, BOM parent would show 100 pcs reserved, but BOM children would show 0 pcs reserved). But this causes probably even bigger problems as anyone looking to order more BOM children wouldn't know inventory was low until it actually happened, since there's a lag time between when an order is reserved and when an order is shipped.

Is there a better way to set this up to get at the info we want (ideally in one place/screen) without having to do a lot of cross-referencing?

posted by edjusted to Computers & Internet (5 answers total)

In manufacturing companies I'm accustomed to, you kit and assemble according to orders and once the kit is created, the components are marked as WIP - work in process - and not available for new orders. Once the assembly is complete, you have the "finished goods" state, where the components are not available to new orders -and- are no longer shown as WIP. That is, the components are flagged as WIP on kitting and are consumed upon assembly, not upon shipment. You would not like the ERP system to suggest the availability of 100 finished kits -and- 100 each of all the components when only 100 finished goods assemblies are available.

This is desirable because there is value added in creating the assembly and knowing how much burden to assign to that value added is critical in figuring out how close to forecast you are performing in assembly.

There is a complication with this process in that dissecting finished goods into their component parts requires an ERP-trackable transaction to return components to stock. In your case, there is an additional wrinkle: if the final assemblies from the factory are not -identical- down to the part level, you would have to have two finished goods part numbers: one for the factory-shipped assemblies and one for the in-house-assembled ones.
posted by jet_silver at 5:51 PM on August 9, 2011

Response by poster: @jet_silver: Thanks. It sounds like what you're used to is more of a assemble-on-demand. We do assemble-on-demand, but have found that producing and stocking finished goods is more practical for some items. What you're saying makes total sense, but adds a level of complexity that we're not ready for. And for our purposes, the finished goods, whether straight from the factory or assembled here are identical.
posted by edjusted at 3:26 PM on August 10, 2011

I wonder, then, if your ERP supports phantom assemblies. It's very hazy to me at this point but if your assemblies are not too deep, something might be done as a kind of work-around with phantoms to get you what you want.
posted by jet_silver at 10:36 PM on August 10, 2011

Response by poster: @jet_silver: thanks, I'll have to look into that. But for now, I'm just trying to figure out the starting point of how the system should show this info "as-is" without making workflow changes. Any idea?
posted by edjusted at 10:36 AM on August 16, 2011

Classically, as soon as any parts get made up into a next-higher-assembly they disappear from stock (and are reflected as WIP). The shipped article is the assembly, ne? If you track -available assemblies- that would take care of the situation where the complete assemblies get bought in, and incidentally allows you to capture the value added in creating the assembly. It means you have to put -greater- reliance on your ERP system, because now you don't have an explicit answer about how many piece parts exist in the entire system.

This is why I'm turning the idea of phantom assemblies over in my head. As I mentioned the idea's kind of hazy, but phantom assemblies are there for convenience and their demand gets reflected at the next level of indenture. The issue here, and it's why I puzzle over it, is the likelihood that you're going to un-kit or dis-assemble assemblies, and what your return-to-stock mechanism looks like.

Take to MeMail from now? You have an interesting issue here, and it would help if you got into a few details that would, I think, bore everybody but you and me.
posted by jet_silver at 10:43 PM on August 18, 2011