You are currently browsing the category archive for the ‘EBOM’ category.

sleepAfter two posts on objections for PLM, I want to come back to the basics around connecting PLM and ERP systems. Most of the people are enjoying their holiday at this moment and for that reason I have the time to complete the PLM and ERP story. I guess, for a company in the mid-market, it is hard to decide which approach to follow.

ERP vendors will claim that by managing items and relations to the design documents, they are able to provide an  environment that supports engineering on top of their system. For mid-market companies this might be the ‘cheapest’ option – buy or get your solution from a single vendor. Especially when the ERP vendor provides the PLM module for free. And this is exactly one of the reasons why it will fail. When no PLM knowledge or best practices are provided to the company, but just a set of function and features, how would these companies know how to implement PLM ?
If you give a module for free it obviously also shows you do not understand the value of it.

My two last posts with the common title 5 reasons not to implement PLM are addressing some of these issues.

But now back to the PLM and ERP connection. In my two previous posts, I described how would be shared between a PLM and an ERP system, combined with issues as: intelligent part-numbers and classification. You will find similar discussions on the manufacturing center.

The connection between PLM and ERP has little value in case only items are exchanged. Of course engineering can have the benefit of early visibility of item logistical data, like costs, stock and status. But the real value comes when engineering, through the PLM environment, feeds the ERP system with the definition of how to manufacture a product. The way to manufacture a product is based on the MBOM (Manufacturing Bill of Materials), combined with operations that need to be performed on the items in the BOM.

In my post Where is the MBOM I already discussed the classical challenge many companies are facing. Historically they enter all the data for manufacturing in their ERP system, as this was the first system driving production. The input for the ERP system came from the engineering department, sometimes provided as Excel sheet or in case of more automation with the CAD environment as an EBOM (Engineering Bill of Material)

As the concept of connection CAD through PLM with ERP might be new for many companies, I will describe below some ‘bad practices’ that I found in past implementations and what we can learn from them.

Bad practice 1: A CAD file equals and Item number

As PLM is often introduced starting from the design department, the initial thought to connect CAD files and Items is based on the simple rule: “Every CAD file represents an item number”. In the ‘good old’ 2D world this might have been true, as in the ERP system, related to each item to be manufactured a drawing existed.

However in the 3D world this approach leads to the following problems:

  • Flexible parts like rubber tubes or belts have a different file representations when used in a different position. This means for one item number several CAD files may exist.
  • Some CAD systems like CATIA, SolidWorks allow the designer to store within one file different configurations of a design, as they share a common design but vary on some specific points. Each variation of course is a different item number. This means for one CAD file several item numbers may exists.

The conclusion from the above exceptions is:

  • Handle CAD files and Item numbers as separate entities in your PLM system
  • A CAD file CAN NOT BE equal to an Item Number

Bad practice 2: The CAD structure can be used as the BOM to be send to ERP

As in many companies the EBOM and the MBOM resemble a lot, the temptation exists to push the engineer instead of defining a design in the concept of the EBOM, to work in a mixed environment.

This approach will lead to the following problems:

  • Drawing of non-design items in the 3D CAD assembly as they are needed to represent an item. For example a paint-can symbol, an oil-can, etc. As these materials are needed for manufacturing, the designer has to add them to the product structure as in this way they will appear in the BOM. This approach leads to a dependency on the CAD assembly that is not needed. Imagine another type of paint is needed – this would require the designer to change the CAD assembly files as they represent the manufacturing structure – or you do not update the CAD assembly files and in that case you have no reliable data anymore.
  • The designer might use in the design subassemblies that group two or more items logically together. For example a bolt, a nut and two rivets. As the subassembly does not exist as an item number in the ERP system, the ERP system treats this assembly as a phantom assembly. No operations needed, but an extra intermediate step is defined in the ERP system, as-if for each usage the bolt, the nut and rivets need to be assembled.

The conclusion from the above points is:

  • Handling the MBOM in the CAD system to send it automatically to ERP leads to complexity either in the design environment or in the ERP system
  • There is no need to have this complexity when the concept of EBOM and MBOM is implemented in PLM
  • Handling EBOM/MBOM transformation in the interface leads to costly complexity, see Where is the MBOM ?

Bad practice 3: The Items in CAD structure are tightly linked to the MBOM

This practice often appears in combination with the two bad practices above. As the company focuses on a resemblance of the CAD structure and the MBOM, people start to imagine also the other way around. They expect the PLM system to keep the CAD structure in-sync with the BOM. In case an item is deleted or replaced in the BOM, the CAD system should be updated automatically..

I guess this is one of the things I learned that is an utopia and probably not needed if a clear understanding of CAD structure, EBOM and MBOM exists. Removing or changing items in a BOM does not give enough information about the impact on the CAD structure. For example if one item appears 3 times in an assembly and one instance is replaced by another item, how would the CAD structure know which item should be replaced ?

The conclusion from the above point is:

  • changes in a product assembly can be initiated from the BOM but should be executed in the CAD system
  • Automatic synchronization of CAD structure based on BOM changes is an utopia


In general my conclusion is (after many years of trying to satisfy customers learning from the above points and more) :

In order to create a smooth connection between PLM and ERP you need:

  • Item creation in PLM – completion in ERP
  • ERP provides feedback on costs and availability
  • In case of production issues an ECR/ECO should be launched – going through PLM to assure engineering impact has been analyzed
  • PLM needs to manage the capture of the CAD structure towards the EBOM
  • EBOM/MBOM transformation needs to be done in PLM
  • The connection between PLM and ERP should go through the MBOM

This week I was in South-Africa working with Aerosud, one of the prominent companies in the Aerospace industry in South Africa, working with the major OEM’s One of the topics discussed in the workshop with Aerosud was the connection between PLM and ERP. As this is a question that occurs so often, see also previous posts, I will address in this post and the upcoming posts the logical steps for an PLM – ERP integration and issues a company might face.

For some people I guess the big surprise will be that most of the difficulties and discussions are not on the technical level, but on how a company has organized their data and organizes their data in the future.

The first rule for implementation is:
The PLM system manages all product related IP (Intellectual Property) and the ERP system manages the executing in the most effective way, taking into account resources, time, material scrap etc often linked with financial transactions

Although some ERP vendors might want you to believe they offer also PLM functionality in their system, it is always a small subset of the total PLM capabilities. Linking manufacturing documents to an item is not PLM. PLM is managing all product related IP and this requires connections to all information sources during the whole product lifecycle, not only during manufacturing.

So if we agree on the above, we understand there is a need to connect PLM and ERP, as both systems have a vital task in a manufacturing company and both work around common information, the product, composed of all its physical items.

Items The Item

The physical item, is the shared and understandable entity understood through the whole company. Some companies call their items parts. In order not to confuse between an item and a part designed in the CAD system, i will talk about items, when I mean the physical representation.

Items can be a single item, a rivet, a specific metal plate or it can be a complete product or smaller component of a complete product. They have one thing in common, we all identify them with a unique number the item number.

In engineering oriented companies you might hear designers say, the item number is equal to the part number of the part or product they are designing, as often in their case what they design on the lowest level of the assemblies, becomes an item.

In general you can subdivide the items in two major groups:

  • standard purchase items
  • company or project specific items.

 Standard Purchase Item Standard purchase items

The characteristic of a standard purchase item is that it has been designed and developed by external companies and that these items can be found in catalogs produced my one or more manufacturers around the world, based on defined standard. For example a M12 Nut, a bearing with specific diameter and performance characteristics. The company that uses these standard parts creates an own definition of the part and makes references to manufacturers who provide these parts in the right quality and standard. These manufacturers appear on the Approved Manufacturer List (AML), which is an engineering task inside PLM to define this list.

In addition, based on this approved manufacturer list, the purchasing department will allocate vendors for these parts and based on vendor performance and reliability, they create a List of Approved Vendors (AVL)for these parts. This is a execution task to be defined in the ERP system.

So in day to day operation, engineering will define new standard purchase items if not available and this request will lead into an AML and then in ERP towards a AVL of the standard item. It is a combined activity where each of the disciplines has participate. For existing standard items, there is also a process triggered from ERP that influences their usage. For example a certain manufacturer might stop producing a certain item and this affects the AVL – purchasing raises a flag that the item becomes hard to acquire or even unavailable, which leads to engineering to define a new AML, which might end up in an engineering change as by changing some of the product functionality other standard items can be used to replaced the original defined item.

So for standard purchase items we see:

  • new standard items are introduced through PLM – starting from AML into ERP with the AVL.
    Both system add information to the item information
  • exiting standard item can become obsolete through PLM – as the company decides not to use them (anymore) or become phase out or obsolete based on a trigger coming from the ERP side, as the AVL has changed.
  • Standard purchase items do not have revisions


Item Items

With items here we mean the non-standard purchase items, which can be divided again in two major groups:

  • company standard items
  • project specific items

Project specific items are items defined by engineering during the definition of a product. These items need to be manufactured specifically for this product based on the specification provided by engineering. Outside the project these items are not used again anymore as they are too specific.

However companies try to standardize even their project specific items, in order to share and reuse them in other products. At this stage, the project specific item becomes a company standard item and is managed to be reused.

Both company and project specific items can have revisions as their maturity may grow. As long as the new definition complies to the Form-Fit-Function rules, the new revision of the defined item can replace previous revisions, meanwhile better support future usage.

So for items we see:

  • project specific items are introduced through PLM and on the moment of production pushed to ERP to be manufactured according the design specification with the right revision
  • company standard items are introduced through PLM and can be produced on stock (if there is a wide usage through various products) or pushed to ERP when needed to be manufactured according the design specification with the right revision
  • Items are revision managed and follow the Form-Fit-Function rules

The conclusion of the above for this post is:

  • Items have a common usage in both PLM and ERP
  • Items are initially created in PLM and at a certain time transferred to ERP to be completed with logistical information
  • Item usage can change based on availability triggers from ERP or use cases in PLM
  • an item is a hybrid entity – with a common shared identification, PLM relevant data and ERP relevant data
  • Some of the ERP data might be relevant for information to be viewed the engineer and the other way around


Once agreed on the above concept, we have the guidelines how to connect items between an PLM system and an ERP system.  In my next post I will talk more about that, also about how to connect BOMs between PLM and ERP.

Subscribe to this blog if you want to follow this sequential on how PLM and ERP connect and work together
Subscribe in a reader

%d bloggers like this: