You are currently browsing the tag archive for the ‘MBOM’ tag.

observation The past few weeks I have been busy in an area which I believe is crucial for understanding PLM. I had meetings, web meetings with prospects, with implementers and existing customers – of course all in the mid-market. And the generalized key question on the table was: “

 

question

Yes, we understand document management, and yes, CAD management is understandable to us, but why do you need to work with the BOM further down the product lifecycle, as this is ERP, isn’t it ?

I realized several topics play a role here:

  • Mid-market companies usually do not think top-down in their approach. As an example: they will not look at their whole organization’s business processes and then try to map all the activities cross departments, cross suppliers, etc.  Usually they are looking per department to optimize the way they are working.
    Classical enterprise PLM implementations are designed to go top-down. Describe the as-is situation, describe the the to-be situation and then transform the company to meet the to-be situation. Decisions are pushed to the people in the company as the to-be situation seems to be clear. Many of the classical PLM implementers still believe in this approach – and the risk / challenge is always that the to-be situation was not well understood, or that at the time we reach the to-be situation the environment of the company has changed and another to-be is needed.
  • Mid-market companies understand a central storage for documents brings a lot of benefits. Most companies realize that all this departmental archives of documents and files create too much overhead and a higher quality risk. Finding the absolute right file for a certain product release might be a quest and of course each of the departments claims that their solution fits exactly their needs. This is what I believe the main driver behind the success of SharePoint. As Microsoft Office is used as a common document authoring tool among all departments, why not use the Office Document Management tool as our common backbone ? PLM and ERP vendors might say we also manage documents, but usually these documents are managed in a structured manner – related to revisions of a product or to a product order. Usually an infrastructure to manage unstructured documents does not exist in ERP systems.
  • Mid-market companies do not understand the value of managing the BOM outside ERP. As I mentioned, everyone understands documents, but items seem to be the domain of an ERP system. Understandable as ERP was often the first IT-system implemented.  As mid-market companies usually do not have a holistic view, items will remain to be managed there (“as we invested so much in the first implementation the management will say – no other source for items !!!”)
    And here i believe is the crucial go-no/go point for a PLM implementation. Once the company starts to understand that the definition of items is not done in the ERP system, but is a result of the work done in the engineering department, only then the value of managing the BOM outside ERP become apparent. And here is the catch 22, we already manage our documents in environments without items (BOM’s) (SharePoint / CAD Documents management) – so no place for PLM ?

  So what to do as a mid-market company ?

point It is hard to understand the full picture (because of the above points), can you trust the selling PLM partner ?(we have been promised easy implementations in the past with other IT-systems too) and at the end you do not believe the value PLM can bring (as you cannot imagine and digest the impact of PLM to your company)

And just when thinking about this – three articles came to my attention as they all address this topic, somehow from a different perspective:

The first two posts deal with a packaged approach for mid-market companies, allowing them to implement PLM faster and with a faster ROI. As Jim (and many others are stating – in an economical down turn you cannot focus on efficiency only (the ERP slogan). It is innovation – better and more customer oriented and attractive products – brings much higher revenue as compared to doing more of the same more efficient.

Oleg focuses on the steps to implement PLM and I agree with most of the statements there. It needs to be gradual and implementing the business processes comes as the last phase.

There is one difference I see in my approach compared to what Jim and Oleg are writing. Both believe that PLM brings value (and i support this statement 100 % based on experiences with customers I have worked).

However the missing point to be addressed is the lack of understanding (and often also trust) of companies talking with a PLM vendor and committing to PLM.  I tried to explain these points in the above 3 statements. As long as those points are not addressed, each stepped approach will lead to the question:  “When are we really going to do PLM instead of CAD Document management or enhanced ERP ? “

My experiences with guiding successful PLM implementations are the following:stepped

  1. Start with basic document management and CAD data management. It aligns with the understanding of companies that a centralized and secure repository for documents brings ROI. This step introduces to the company that a company wide approach of data management brings value (and ROI). Some basic processes might be introduced here already- basic document approval as required by all quality systems.
  2. Once basic CAD and Document Management are introduced, the company will realize that it is missing ‘place holders’ to hook the information. If you work in a document management system only, the system implementer will say: Use projects to collect your product data and use folders to collect your item related data. A PLM vendor would say; Now you are ready to introduce Items in your system, as they are the logical place holders for information. Here PLM starts to be introduced.
  3. Once understood that the item is a needed place holder to manage development data, the understanding for managing items in a structure becomes clear. Here we introduce the EBOM and as Items also contain logistical data, this is the first point to start connecting PLM and ERP to work with a shared ‘place holder’ but with different focus on characteristics.
  4. Once the Engineering BOM is understood, the discussion starts around the MBOM. Who is responsible for defining how a product is manufactured ? PLM believes this is part of their duty, ERP vendors will say, we own the item historically ,so we manage the MBOM. As a 100 % PLM believer, I think it should be in PLM as it is not part of the execution but part of the product definition (See the post I wrote on this topic: Where is the MBOM).
    At the end the defined MBOM can be pushed to ERP once required.
  5. Once you are able to manage and centralize all data related to product development and definition, a company becomes ready to guarantee the quality and flow of the data, by implementing company wide engineering change and development processes. Much in line with Oleg’s PLM action plan.

I have supported implementations of the above approach in several mid-market companies and key success factors were:coop

  • the company understanding PLM brings benefits but also understands it will take a time to realize this vision.
    Management vision and support were always there. 
  • a PLM system that allows you to start simple with centralizing documents and keeping things understandable but also allows you to scale up to a PDM system and finally supporting the whole PLM vision once accepted and understood .
    Think Top-Down – Implement Bottom-Up
  • an implementer who understands that in the mid-market a push of concepts will bring rejections from the end-users, and where listening to the end-users only, it will result in an unguided system. The implementation partner needs to say No at the right time and to push for Yes when needed.
    The implementer is 50 % of the success !

expressConclusion:  A management vision, a scalable PLM system and an experienced implementation partner are needed to bring the innovation to survive in the long term – document management and ERP alone will not bring this unique value. The phased approach allows a company with digestible steps to grow to their ‘to-be’ situation – as building trust and understanding is still required in the mid-market of PLM

See also: ENOVIA SmarTeam Express

This week was again a week with several customer visits and discussions around PLM implementations. As analysts like CIMdata, AMR Research, the Aberdeen group are all claiming that PLM will be the next thing for small and medium manufacturing companies, the discussion around PLM is ongoing. Of course, PLM vendors are adapting their messaging and sometimes their products towards the SMB.

Some vendors like PTC and UGS try to downscale their existing products mainly by changing the packaging of the product (but it remains a PLM system originally designed for enterprises) others like Dassault Systemes have a special SMB offering with full PLM capabilities, ENOVIA SmarTeam.

But let’s assume we have the ideal PLM solution for an SMB company. This was the start point, I had during my meetings this week.  How would you motivate a company to implement PLM, knowing all the constraints of SMB companies? Miki Lumnitz wrote about it in his blog –PLM for SMB who are those companies?

I noticed one of the main issues for discussion is the handling of the MBOM (Manufacturing BOM). So let’s look at the different viewpoints in a company.

EBOM (Engineering Bill Of Materials)

 “The EBOM reflects the way a product was functionally designed”

When engineers define a product, they design (or reuse) assemblies (modules) and add new parts and assemblies to the design. When working with a 3D CAD system, saving the product results in a document structure that resembles a lot the engineering BOM. Traditionally companies got the impression that by changing this EBOM structure a little, they would have a structure ready for manufacturing, called the MBOM.

MBOM (Manufacturing Bill of Materials)

“The MBOM reflects the way a product will be manufactured”

The MBOM is a structure derived from the EBOM. The main changes from EBOM to MBOM are:image

  • removal of subassemblies that do not exist in the physical world. For example a grouping of two parts that are logically grouped by the designer, but as a group does not make sense for manufacturing (Assembly B).
  • And in addition to non-design items which are needed for manufacturing the product. For example paint or grease. (Item F)

Traditionally – and also in the companies I was visiting – the EBOM is the domain for the engineering department and with additional modifications, they provide a BOM (is it EBOM or MBOM ?) to the ERP system.  Some companies add non-engineering items to their design – they draw a can of paint in their design to make sure the paint is part of the BOM. Some work with phantom production order to address the usage of subassemblies by engineering.

image

Both EBOM and MBOM definitions are preparations before production can start. The EBOM and MBOM contain the product knowledge, how to build and how to manufacture a product. For that reason, they should be handled in the PLM system. The main reasons for that are:

  • during process engineering, there is a need to use, analyze and sometimes adapt engineering data. This can be done in the most efficient way within one system where all product data is available
  • PLM systems, like ENOVIA SmarTeam, contain tools to create quickly based on certain rules an MBOM derived from the EBOM and when changes occur even compare both structures again, to adapt to these changes
  • Having a single environment for product definition and manufacturing improves the total product understanding

So where is the MBOM?

Ask yourself as a company ” where do I handle the MBOM ?”  Some of you might say, we do not have an MBOM as our EBOM with some modifications is already good enough for manufacturing.  Many companies might say, we manage the MBOM in the ERP system as this is (was) the only system we had where we could define such structures. These companies are candidates for improving their Concept to Manufacturing process, as for sure either users or working methods are compromised to work with the MBOM in the ERP system.

image

Some might says: Do we still need ERP systems?

Yes, as ERP systems are built to schedule and execute the production of well-defined products in the most efficient way. ERP systems are needed for the execution, often the core activity for manufacturing systems.

PLM systems are the reason that ERP systems can execute, they bring the product definition and information to produce a product. And in case the company designs and manufactures excellent and innovative products the future is bright.

But we should not consider engineering activities in the same way as production activities.

Einstein once said (and he is not an expert anyway):

Innovation is not the product of logical thought, even though the final product is tied to a logical structure

I am curious to learn where you manage your MBOM

Translate

  1. Unknown's avatar
  2. Håkan Kårdén's avatar

    Jos, all interesting and relevant. There are additional elements to be mentioned and Ontologies seem to be one of the…

  3. Lewis Kennebrew's avatar

    Jos, as usual, you've provided a buffet of "food for thought". Where do you see AI being trained by a…

  4. Håkan Kårdén's avatar