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

Conclusion

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