Comments on: BOM: Overstructured, Understructured or Lean?

By: Vikas

Vikas — Wed, 18 Jan 2012 11:54:19 +0000

What could the possible problems be when we try to combine the bills from multiple sources to create a single bill?

Thank you.

Vikas

By: Alec Gil

Alec Gil — Wed, 21 Oct 2009 22:48:11 +0000

Oleg, this is exactly right. Very well summarized.

By: olegshilovitsky

olegshilovitsky — Wed, 21 Oct 2009 21:34:56 +0000

Alec, my takeaways from your great comment are as following: 1/the ultimate structure of BOM can be only defined for specific customer and rarely can be predefined; 2/Ability to synchronize between whatever we call them (BOM structures) will be the key; 3/All parties (suppliers, ERP, CAD…) need to be involved and integrated.
Basically, you said, when all these pre-requisites done, we have ONE master bill of material in organization… I hope, I got it right… thanks, Oleg.

By: Alec Gil

Alec Gil — Wed, 21 Oct 2009 19:01:22 +0000

Excellent topic with outstanding contributions from everyone. I too liked Herve’s analogy of the BOM to the final shopping list. However, the question that must be answered related to Oleg’s original quandary is: well, where do you shop? That is, do you source everything from outside, build everything internally or both (most likely). If shopping externally, do you just buy standard components or outsource entire sub-systems of your products.

All of these questions (and there are others) ultimately answer the question of how the organization manages their Bills of Materials. In an ideal case of everything being done internally, I would suggest organizations should strive toward the single BOM. Of course, there are issues of different organizational roles contributing to the BOM, and organizational ability to reconcile these contributions. I will try to expand on this topic. CAD structures are really just a useful starting point in BOM creation. Once CAD assemblies reach some defined level of maturity, the initial version of the BOM can then be extracted. I will not call this version of BOM EBOM because, philosophically, I believe it is a misnomer. It is simply initial, likely incomplete, version of the BOM. Moreover, after the initial “extraction”, people contributing to the BOM, should be able to add to or subtract from this initial version. Designers, in the meantime, if needed, must be able to continue working on the momentarily disconnected CAD structure. However and here is the key, at any point, a system (hopefully PLM or perhaps some other) must be able to reconcile these two structures on demand. In addition, that same system (PLM again) must be able to support all checks and balances that allow different organizational roles (engineering, manufacturing, purchasing, QA, etc.) to indicate to the involved stakeholders that they are done with their portion of the BOM. At the point when everyone is finished, the BOM is complete. If any changes are required in the future, a new revision must be made.

But what about functions that are usually done in an ERP system? Well, if we are truly serious about having only one Master BOM, all of the involved business systems – at a minimum PLM and ERP – must be integrated to the point where, from the process standpoint (i.e. overall BOM creation and maintenance) they look like a single system. Let me give a few examples. If a Purchasing department needs to issue a Purchase Order in ERP for a long lead-time component, Engineering must be able to set the appropriate Item (a component in the BOM) attribute(s) in the PLM system, and their agreement to purchase will, based on some pre-defined process trigger, then be communicated to ERP. This is shopping externally. Similarly, for the job orders to be issued (internal shopping), related attributes must also be set in PLM and communicated to ERP. I agree this is difficult, but not impossible or utopian. It has been done. All that is necessary is for the PLM system to support all of the needed interactions. The more of these interactions such system supports, the easier these implementations will become.

Lastly, what if the external BOM communications are necessary? This is one obvious place where disconnects can occur, but, if it is important for business, integrations and associated rules can be established with the involved customers or suppliers.

By: olegshilovitsky

olegshilovitsky — Wed, 21 Oct 2009 12:07:21 +0000

Jovan, I see what you mean – we may decide to have about any number of internal logical structures and processes, but finally we need to take care about “functional set of products” and “shopping list for manufacturing”…. right? The question, I’m raising is how to make these logical structures and process lean and efficient? Because if customer is ready to wait unlimited time and we have no competitors, we have all time in the world to design, plan and manufacturing … the optimization of internal processes starts when we need to compete and deliver on time, right? Oleg

PS. I’m sorry. I’m not in Lowell this week, getting back to Boston on Fri only…. Best, Oleg

By: Hervé Menga

Hervé Menga — Wed, 21 Oct 2009 12:01:45 +0000

I did not say that a CAD BOM was not necessary, i said that the CAD designer does not need a CAD BOM.
So why in some companies we are speaking of the CAD BOM, and of the difficulties to “transform it” into an EBOM (same, who needs the EBOM ?), and then “at the end” to the MBOM (ah, here, we could assume that the MBOM is necessary to procurement/logistics people to be able to order the components (personnally, i think that this could be THE BOM…).
I must admit i have some problems with the idea of an EBOM being composed of logical elements (?).
But this idea behind that the mockup is composed of “logical elements” could be explained like the following:
Of course, i know that before to make any mechanical design that involves geometric problems, a mechanical designer is doing some system engineering activities, i.e. is considering the product with a systemic approach (product = system), so he is first constructing the functional model of this system. Then he is allocating to each function a sub-system or a system component (this gives him a system architecture model), and for each sub-system, he must study it geometrically if this sub-system is a mechanical system. Why geometrically ? Because the function of this mechanical system is the transformation of mechanical energy by means of this mechanical system, so it involves mechanical interfaces… Of course, because the geometric model of the system is somehow the translation of the function “Transform the energy”, the geometric model is the functional response of a mechanical system to the question.
By analogy, if you imagine that the systems technology is electronic (transformation of a signal into another electric signal), the functional model made by the designer will be an electronic diagram (electronic model), which corresponds to the geometric mock-up for a mechanical system.
So, the list of geometrical “parts” that composes a mechanical system could be understood as the list of the functional elements of this mechanical system.
It implies that the functional “view” of a mechanical system can be modelled as the digital mock-up of this system (including of course the GD&T information that is carried by the interfaces), which i call the “design model” of the system. What a great idea!
But now what is the architectural “view” of this mechanical system ? I think personnally that the architectural view could be modelled as the process model of this mechanical system.
For a “small mechanical system” as you say, Jovan, it seems quite obvious that the process model is very similar to the design model. Why ? May be because a small mechanical system involves only basic assembly operations, so the process to make an assembly of components is similar to a composition : if you want to make the full system, the process is easy : you just “add” the components. But if the process is slightly more complicated (for example, you glue two components before, and then assemble and paint afterwards), the process model is just more complicated than the simple “add” of the design model – at least because you must include in this process as “new components” the glue and the paint (which are not included in the design model)…
Do not think that the process model must be constructed by manufacturing guys! I use to consider that the design model and the process model are two faces of the product definition : the combined answers : how the mechanical system is performing the allocated function (desig model) + how the mechanical system must be “materialized” to be able to perform the allocated function (process model).
This “dual” behaviour of design/process models of the product definition could explain why we have problems to make the difference between the CAD BOM/EBOM.
Sorry again for this long message, you can freely remove it if you have problems with it.
Hervé.

By: olegshilovitsky

olegshilovitsky — Wed, 21 Oct 2009 11:59:27 +0000

Herve, I think you made excellent comment! What I like is that you emphasized very well – this is all about internal processes in the company and tools. You can call BOM- Model or report, but this is still will be the same issue with internal process in the organization to get this FINAL SHOPPING LIST right and on time!… In the past time, reports and paper lists used. Today – advanced modeling, Digital mockups, collaborative tools etc. In addition, I agree, this space is very much influenced by terminology coming from software tool (for good and for bad).
Now, my point is how to organize BOM(s) / Model/ Reports or whatever else we call it to have efficient processes in organization.
Best, Oleg

By: olegshilovitsky

olegshilovitsky — Wed, 21 Oct 2009 11:46:26 +0000

Nawal, Thanks for your view! Great discussion… Best, Oleg

By: Jovan

Jovan — Wed, 21 Oct 2009 11:02:51 +0000

Without thinking, like Herve, that a CAD BOM is non necessary, I don’ think that it should be the EBOM.

I think a point has been raised but missed in this conversation.

The Engineering BOM is a logical view of the mind and must be process as such.
For me an EBOM is not composed of Parts, otherwise the definition of Part is too stretched. A part is something that a someone can manipulate either physically or virtually (CAD Parts).
The EBOM for me is composed of logical elements that I’ll call features.
You will see this approach in most of the complex product industries (Indus Equipment, Aerospace, Ship Building, Energy,…). Nobody cares about an EBOM of parts. They care about the features that are in the end product. The part is a transitional element to go from this structure to an MBOM.
For small assembly definition, the Part Structure is very similar to the CAD, this is right. But if it crosses several logical functions, the engineer will not design it by “Object” but by logical function.
The success of many PLM implementation result in the understading of this statement. I have seen many failed implementation because an EBOM of Parts has been introduced and was never needed. The EBOM of Parts became some kind of monster between a functional decomposition and a Manufacturing BOM.
The layer that the feature add will help the engineer to define their product without really care of the part that will be used, and help to chose the right design afterward. By not manipulating the same object you give the flexibility to manage different structure and reducing the interferences of managing 2 (or many) structure of the same object.
If you remember well Oleg, I think that idea was raised in one of my first comment in your blog

I’ll be in Lowell tomorrow and Friday, hope to see you there.

By: Jovan

Jovan — Wed, 21 Oct 2009 10:50:44 +0000

Without thinking, like Herve, that a CAD BOM is non necessary, I don’ think that it should be the EBOM.

I think a point has been raised but missed in this conversation.