Learning from the past to understand the future – some EBOM / MBOM clarifications (7)

August 23, 2020 in Blocking change, Change, Data centric, Digital Enterprise, EBOM, MBOM, MDM, Observations, Platform, PLM, Product Innovation | Tags: , , , , , , , | Leave a comment

In the series learning from the past to understand the future, we have almost reached the current state of PLM before digitization became visible. In the last post, I introduced the value of having the MBOM preparation inside a PLM-system, so manufacturing engineering can benefit from early visibility and richer product context when preparing the manufacturing process.

Does everyone need an MBOM?

It is essential to realize that you do not need an EBOM and a separate MBOM in case of an Engineering To Order primary process. The target of ETO is to deliver a unique customer product with no time to lose. Therefore, engineering can design with a manufacturing process in mind.

The need for an MBOM comes when:

  • You are selling a specific product over a more extended period of time. The engineering definition, in that case, needs to be as little as possible dependent on supplier-specific parts.
  • You are delivering your portfolio based on modules. Modules need to be as long as possible stable, therefore independent of where they are manufactured and supplier-specific parts. The better you can define your modules, the more customers you can reach over time.
  • You are having multiple manufacturing locations around the world, allowing you to source locally and manufacture based on local plant-specific resources. I described these options in the previous post

The challenge for all companies that want to move from ETO to BTO/CTO is the fact that they need to change their methodology – building for the future while supporting the past. This is typically something to be analyzed per company on how to deal with the existing legacy and installed base.

Configurable EBOM and MBOM

In some previous posts, I mentioned that it is efficient to have a configurable EBOM. This means that various options and variants are managed in the same EBOM-structure that can be filtered based on configuration parameters (date effectivity/version identifier/time baseline). A configurable EBOM is often called a 150 % EBOM

The MBOM can also be configurable as a manufacturing plant might have almost common manufacturing steps for different product variants. By using the same process and filtered MBOM, you will manufacture the specific product version. In that case, we can talk about a 120 % MBOM

Note: the freedom of configuration in the EBOM is generally higher than the options in the configurable MBOM.

The real business change for EBOM/MBOM

So far, we have discussed the EBOM/MBOM methodology. It is essential to realize this methodology only brings value when the organization will be adapted to benefit from the new possibilities.

One of the recurring errors in PLM implementations is that users of the system get an extended job scope, without giving them the extra time to perform these activities. Meanwhile, other persons downstream might benefit from these activities. However, they will not complain. I realized that already in 2009, I mentioned such a case: Where is my PLM ROI, Mr. Voskuil?

Now let us look at the recommended business changes when implementing an EBOM/MBOM-strategy

  1. Working in a single, shared environment for engineering and manufacturing preparation is the first step to take.

Working in a PLM-system is not a problem for engineers who are used to the complexity of a PDM-system. For manufacturing engineers, a PLM-environment will be completely new. Manufacturing engineers might prepare their bill of process first in Excel and ultimately enter the complete details in their ERP-system. ERP-systems are not known for their user-friendliness. However, their interfaces are often so rigid that it is not difficult to master the process. Excel, on the other side, is extremely flexible but not connected to anything else.

And now, this new PLM-system requires people to work in a more user-friendly environment with limited freedom. This is a significant shift in working methodology. This means manufacturing engineers need to be trained and supported  over several months. Changing habits and keep people motivated takes energy and time. In reality, where is the budget for these activities?  See my 2016 post: PLM and Cultural Change Management – too expensive?

  1. From sequential to concurrent

Once your manufacturing engineers are able to work in a PLM-environment, they are able to start the manufacturing definition before the engineering definition is released. Manufacturing engineers can participate in design reviews having the information in their environment available. They can validate critical manufacturing steps and discuss with engineers potential changes that will reduce the complexity or cost for manufacturing. As these changes will be done before the product is released, the cost of change is much lower. After all, having engineering and manufacturing working partially in parallel will reduce time to market.

Reducing time to market by concurrent engineering

One of the leading business drivers for many companies is introducing products or enhancements to the market. Bringing engineering and manufacturing preparation together also means that the PLM-system can no longer be an engineering tool under the responsibility of the engineering department.

The responsibility for PLM needs to be at a level higher in the organization to ensure well-balanced choices. A higher level in the organization automatically means more attention for business benefits and less attention for functions and features.

From technology to methodology – interface issues?

The whole EBOM/MBOM-discussion often has become a discussion related to a PLM-system and an ERP-system. Next, the discussion diverted to how these two systems could work together, changing the mindset to the complexity of interfaces instead of focusing on the logical flow of information.

In an earlier PI Event in München 2016, I lead a focus group related to the PLM and ERP interaction. The discussion was not about technology, all about focusing on what is the logical flow of information. From initial creation towards formal usage in a product definition (EBOM/MBOM).

What became clear from this workshop and other customer engagements is that people are often locked in their siloed way of thinking. Proposed information flows are based on system capabilities, not on the ideal flow of information. This is often the reason why a PLM/ERP-interface becomes complicated and expensive. System integrators do not want to push for organizational change, they prefer to develop an interface that adheres to the current customer expectations.

SAP has always been promoting that they do not need an interface between engineering and manufacturing as their data management starts from the EBOM. They forgot to mention that they have a difficult time (and almost no intention) to manage the early ideation and design phase. As a Dutch SAP country manager once told me: “Engineers are resources that do not want to be managed.” This remark says all about the mindset of ERP.

After overlooking successful PLM-implementations, I can tell the PLM-ERP interface has never been a technical issue once the methodology is transparent. A company needs to agree on logical data flow from ideation through engineering towards design is the foundation.

It is not about owning data and where to store it in a single system. It is about federated data sets that exist in different systems and that are complementary but connected, requiring data governance and master data management.

The SAP-Siemens partnership

In the context of the previous paragraph, the messaging around the recently announced partnership between SAP and Siemens made me curious. Almost everyone has shared an opinion about the partnership. There is a lot of speculation, and many questions were imaginarily answered by as many blog posts in the field. Last week Stan Przybylinski shared CIMdata’s interpretations in a webinar Putting the SAP-Siemens Partnership In Context, which was, in my opinion, the most in-depth analysis I have seen.

For what it is worth, my analysis:

  • First of all, the partnership is a merger of slide decks at this moment, aiming to show to a potential customer that in the SAP/Siemens-combination, you find everything you need. A merger of slides does not mean everything works together.

  • It is a merger of two different worlds. You can call SAP a real data platform with connected data, where Siemens offering is based on the Teamcenter backbone providing a foundation for a coordinated approach. In the coordinated approach, the data flexibility is lower. For that reason, Mendix is crucial to make Siemens portfolio behave like a connected platform too.
    You can read my doubts about having a coordinated and connected system working together (see image above). It was my #1 identified challenge for this decade: PLM 2020 – PLM the next decade (before COVID-19 became a pandemic and illustrated we need to work connected)
  • The fact that SAP will sell TC PLM and Siemens will sell SAP PPM seems like loser’s statement, meaning our SAP PLM is probably not good enough, or our TC PPM capabilities are not good enough. In reality, I believe they both should remain, and the partnership should work on logical data flows with data residing in two locations – the federated approach. This is how platforms reside next to each other instead of the single black hole.

  • The fact that standard interfaces will be developed between the two systems is a subtle sales argument with relatively low value. As I wrote in the “from technology to methodology”-paragraph, the challenges are in the organizational change within companies. Technology is not the issue, although system integrators also need to make a living.
  • What I believe makes sense is that both SAP and Siemens, have to realize their Industry 4.0 end-to-end capabilities. It is a German vision now for several years and it is an excellent vision to strive for. Now it is time to build the two platforms working together. This will be a significant technical challenge mainly for Siemens as its foundation is based on a coordinated backbone.
  • The biggest challenge, not only for this partnership, is the organizational change within companies that want to build an end-to-end connected solution. In particular, in companies with a vast legacy, the targeted industries by the partnership, the chasm between coordinated legacy data and intended connected data is enormous. Technology will not fix it, perhaps smoothen the pain a little.

 

Conclusion

With this post, we have reached the foundation of the item-centric approach for PLM, where the EBOM and MBOM are managed in a real-time context. Organizational change is the biggest inhibitor to move forward. The SAP-Siemens partnership is a sales/marketing approach to create a simplified view for the future at C-level discussions.
Let us watch carefully what happens in reality.

Next time potentially the dimension of change management and configuration management in an item-centric approach.
Or perhaps Martijn Dullaart will show us the way before, following up on his tricky poll question

 

Learning from the past to understand the future – moving to the MBOM (6)

August 9, 2020 in EBOM, Education, MBOM, PDM, PLM | Tags: , , , , , , | 1 comment

Already five posts since we started looking at the roots of PLM, where every step illustrated that new technical capabilities could create opportunities for better practices. Alternatively, sometimes, these capabilities introduced complexity while maintaining old practices.  Where the previous posts were design and engineering-centric, now I want to make the step moving to manufacturing-preparation and the MBOM. In my opinion, if you start to manage your manufacturing BOM in the context of your product design, you are in the scope of PLM.

For the moment, I will put two other related domains aside, i.e., Configuration Management and Configured Products. Note these domains are entirely different from each other.

Some data model principles

In part five, I introduced the need to have a split between a logical product definition and a technical EBOM definition. The logical product definition is more the system or modular structure to be used when configuring solutions for a customer. The technical EBOM definition is, most of the time, a stable engineering specification independent of how and where the product is manufactured. The manufacturing BOM (the MBOM) should represent how the product will be manufactured, which can vary per location and vary over time. Let us look in some of the essential elements of this data model

The Product

The logical definition of the product, which can also be a single component if you are a lower tier-supplier, has an understandable number, like 6030-10B. A customer needs to be able to order this product or part without a typo mistake. The product has features or characteristics that are used to sell the product. Usually, products do not have a revision, as it is a logical definition of a set of capabilities. Most of the time, marketing is responsible for product definition. This would be the sales catalog, which can be connected in a digital PLM environment. Like the PDM-ERP relation, there is a similar discussion related to where the catalog resides—more on the product side later in time.

The EBOM

Related to the product or component in the logical definition, there is an actual EBOM, which represents the technical specification of the product. The image above shows the relation represented by the blue “current” link.

Note: not all systems will support such a data model, and often the marketing sides in managed disconnected from the engineering side. Either in Excel or in a specialized Product Line Engineering (PLE) tools.

We discussed in the previous post that if you want to minimize maintenance, meaning fewer revisions on your EBOM, you should not embed manufacturer-specific parts in your EBOM.

The EBOM typically contains purchase parts and make parts. The purchased parts are sourced based on their specification, and you might have a single source in the beginning. The make parts are entirely under your engineering control, and you define where they are produced and by whom. For the rest, the EBOM might have functional groupings of modules and subassemblies that are defined for reuse by engineering.

Note: An EBOM is the place where multidisciplinary collaboration comes together. This post mainly deals with the mechanical part (as we are looking at the past)

Note: An EBOM can contain multiple valid configurations which you can filter based on a customer or market-specific demand. In this case, we talk about a Configured EBOM or a 150 % EBOM.

The MBOM

The MBOM represents the way the unique product is going to be manufactured. This means the MBOM-structure will represent the manufacturing steps. For each EBOM-purchase-part, the approved manufacturer for that plant needs to be selected. For each make-part in the EBOM, if made in this plant per customer order, the EBOM parts need to be resolved by one or more manufacturing steps combined with purchased materials.

Let us look at some examples:

The flat MBOM

Some companies do not have real machinery anymore in their plants, the product they deliver to the market is only assembled at the best financial location. This means that all MBOM-parts should arrive at the shop floor to be assembled there.  As an example, we have plant A below.

Of course, this is a simplified version to illustrate the basics of the MBOM. The flat MBOM only makes sense if the product is straightforward to assemble. Based on the engineering specifications, the assembly drawing(s) people on the shop floor will know what to do.

The engineering definition specifies that the chassis needs to be painted, and fitting the axles requires grease. These quantities are not visible in the EBOM; they will appear in the MBOM. The quantities and the unit of measure are, of course, relevant here.

Note: The exact quantities for paint and grease might be adjusted in the MBOM when a series of Squads have been manufactured.

The MBOM and Bill of Process

Most of the time, a product is manufactured in several process steps. For that reason, the MBOM is closely related to the Bill of Process or the Routing definitions. The image below illustrates the relationship between an MBOM and the operations in a plant.

If we continue with our example of the Squad, let us now assume that the wheels and the axle are joined together in a work cell. In addition, the chassis is painted in a separate cell. The MBOM would look like the image below:

In the image, we see that the same Engineering definition now results in a different MBOM. A company can change the MBOM when optimizing the production, without affecting the engineering definition. In this MBOM, the Axle assembly might also be used in other squads manufactured by the company.

The MBOM and purchased parts

In the previous example, all components for the Squad were manufactured by the same company with the option to produce in Plant A or in Plant B.  Now imagine the company also has a plant C in a location where they cannot produce the wheels and axle assembly. Therefore plant C has to “purchase” the Wheel-Axle assembly, and lucky for them plant B is selling the Wheel+Axle assembly to the market as a product.

The MBOM for plant C would look like the image below:

For Plant C, they will order the right amount of the Wheel+Axle product, according to its specifications (HF-D240). How the Wheel+Axle product is manufactured is invisible for Plant C, the only point to check is if the Wheel+Axle product complies with the Engineering Definition and if its purchase price is within the target price range.

Why this simple EBOM-MBOM story?

For those always that have been active in the engineering domain, a better understanding of the information flow downstream to manufacturing is crucial. Historically this flow of information has been linear – and in many companies, it is still the fact. The main reason for that lies in the fact that engineering had their own system (PDM or PLM), and manufacturing has their own system (ERP).

Engineers did their best to provide the best engineering specification and release the data to ERP. In the early days, as discussed in Part 4, the engineering specification was most of the time based on a kind of hybrid BOM containing engineering and manufacturing parts already defined.

Next, manufacturing engineering uses the engineering specifications to define the manufacturing BOM in the ERP system. Based on the drawings and parts list, they create a preferred manufacturing process (MBOM and BOP) – most of the time, a manual process.  Despite the effort done by engineering, there might be a need to change the product. A different shape or dimension make manufacturing more efficient or done with existing tooling. This means an iteration, which causes delays and higher engineering costs.

The first optimization invented was the PDM-ERP interface to reduce the manual work and introduction of typos/misunderstanding of data.  This topic was “hot” between 2000 and 2010, and I visited many SmarTeam customers and implementers to learn and later explain that this is a mission impossible. The picture below says it all.

We have an engineering BOM (with related drawings). Through an interface, this EBOM will be restructured into a manufacturing BOM, thanks to all kinds of “clever” programming based on particular attributes.  Discussed in Part 3

The result, however, was that the interface was never covering all situations and became the most expensive part of the implementation.

Good business for the implementing companies, bad for the perception of PDM/PLM.

The lesson learned from all these situations: If you have a PLM-system that can support both the EBOM and MBOM in the same environment, you do not need this complex interface anymore. You can still use some automation to move from an EBOM to an MBOM.

However, three essential benefits come from this approach

  1. Working in a single environment allows manufacturing engineers to work directly in the context of the EBOM, proposing changes to engineering in the same environment and perform manual restructuring on the MBOM as programming logic does not exist. Still, compare tools will ensure all EBOM-parts are resolved in the manufacturing definition.
  2. All product Intellectual Property is now managed in a single environment. There is no scattered product information residing in local ERP-systems. When companies moved towards multiple plants for manufacturing, there was the need for a centralized generic MBOM to be resolved for the local plant (local suppliers / local plant conditions). Having the generic MBOM and Bill of Process in PLM was the solution.
  3. When engineers and manufacturing engineers work in the same environment, manufacturing engineering can start earlier with the manufacturing process definition, providing early feedback to engineering even when the engineering specification has not been released. This approach allows real concurrent engineering, reducing time to market and cost significantly

Conclusion

Again 1600 words this time. We are now at the stage that connecting the EBOM and the MBOM in PLM has become a best practice in most standard PLM-systems. If implemented correctly, the interface to ERP is no longer on the critical path – the technology never has been the limitation – it is all about methodology.

Next time a little bit more on advanced EBOM/MBOM interactions

 

 

 

Learning from the past to understand the future – Towards a real (configured) EBOM (5)

July 25, 2020 in BTO, Change, CTO, EBOM, Education, ETO, PDM, PLM | Tags: , , , | 1 comment

In this post in the series Learning from the past to understand the future, I want to leave the 3D CAD structures behind. But before doing so, I want to mention some of the lessons learned:

In Part 1:  “Intelligent” drawing numbers were the source for “intelligent” part numbers as often there was a one-to-one relationship between the drawing and the part(s) on a drawing.

In Part 2: 3D CAD has been introduced in the automotive and aerospace industry due to process optimization, where a 3D CAD environment created better collaboration possibilities (DMU). The introduction of 3D CAD in the mid-market was different. Here 3D CAD is used as an engineering tool, not changing any processes.

The complexity grew because also file names needed to be managed, introducing the need for PDM-systems.

In Part 3: we discussed the challenges of working with file-based 3D CAD structures. The versioning problem with check-in/check-out of structure in particular in the case of data reuse. Here the best practice was introduced to have physical parts with a different lifecycle than 3D CAD parts and assemblies.

Now engineers need to create valid configurations based on links between the physical part and the 3D/2D object. This requires a PDM-system with BOM and CAD-files as standard information objects.

In Part 4: we discussed the relations between the BOM and 3D CAD structures without neglecting the fact the 2D Drawing is still the primary legal information carrier for manufacturing/suppliers. The point discussed in this post was the fact that most companies used a kind of ETO-approach. Starting from the 3D CAD-system, adding sometimes manufacturing parts in this structure, to generate a BOM that can be served as input for the ERP-system.

I want to follow up from the last conclusion:

Changing from ETO to CTO requires modularity and a BOM-driven approach. Starting from a 3D CAD-structure can still be done for the lowest levels – the modules, the options. In a configure to order process, it might not be relevant anymore to create a full 3D-representation of the product.

Starting from a conceptual structure

Most companies that deliver products to the market do not start from scratch, as we discussed. They will start from either copying an existing product definition (not recommend) or trying to manage the differences between them, meanwhile keeping shared components under revision control.

This cannot be done based on 3D CAD-structures anymore. At that time (we are in the early 2000s) in the mid-market, the PDM-system was used to manage these structures, in particular, they used the BOM-capabilities.

The BOM-structure was often called the EBOM, as engineers were defining the EBOM. But is it really an EBOM? Let us have a look wat defines an EBOM.

What characterizes an EBOM?

There are many personal definitions of what is considered as an EBOM.  Also, the Wiki-definition here does not help us a lot. So here is my personal 2004 definition:

  • The EBOM reflects the engineering view of a product and, therefore, can have a logical structure of assemblies and subassemblies based on functionality, modularity, and standardization.
  • The EBOM is a part structure specifying a product from its design intent, specifying parts, materials, tolerances, finishing.
  • The EBOM-structure is allowing multidisciplinary teams to work together on a joint definition of the product

The picture below illustrates the above definition.

In this EBOM-structure, we see that the first two levels actually are more a logical division of functional groups, either as units, product/discipline-specific definitions (cabling/software). These components should not be in the EBOM if you have support for logical structures in your PLM-environment. However, in 2004 – PLM was not that mature in the mid-market, and this approach was often chosen.

If we look at the Line Feed module, which could also be used in other products, there is the typical mechanical definition and in parallel the electrical definition. Having them inside a single EBOM gives the advantage of being able to do a “where-used” and status/impact-analysis.

1 – Purchased parts

Motor P280 is an interesting EBOM-part to consider. This motor is required; however, in an EBOM, you should not specify the supplier part number directly. As supplier part availability and preference will change over time, you do not want to revise the EBOM every time a supplier part gets changed.

Therefore, the Motor P280 should have an internal part number in the EBOM. Next, it will be engineering that specifies which motors fulfill the need for Motor P280.   Preferably they will create an Approved Manufacturing List for this motor to give manufacturing/purchasing the flexibility to decide per order where to purchase the motor and from which supplier.

The relation between the Approved Manufacturing List and the Approved Vendor List is shown in the diagram above.

Or follow the link to this image to read more in Arena’s glossary. In particular, for electronic components, this concept is needed as high-level specifications for electronic parts might be the same.

However, the details (tolerances/environment) can be decisive, which component is allowed. Besides, due to the relatively short lifecycle of electronic components, the EBOM needs to be designed in such a manner to anticipate changes in suppliers.

You can only benefit from this approach if, from the beginning of your designs, there are no supplier-specific parts in your EBOM. For Engineering, to Order companies that want to become more Build to Order, this is a challenging but critical point to consider.

Note: The functional characteristics for the motor will come from the electrical definition, and through a reference designator, we create the link between the functional definition and the physical implementation in the product.

2 – Make Parts

Secondly, if we look to the conveyor block D1020 rev A, this block is a make part, with probable a whole assembly of parts below it. As it is a make part, there is at least an assembly drawing and, more likely, a related technical data package linked to D1020 rev A. Make parts still carry a revision as here the Form-Fit-Function discussion can be used when implementing a change of the part.

Note: I used for the final assembly drawing the same number scheme as this is how most companies work. However, in my previous post, I described that if you have a PDM-system in place, the numbering can be different. Maintaining the relations between a part and the related drawing is, in this case, crucial.

The Configured EBOM

The image on the left, we used to illustrate the typical mid-market EBOM in a PDM-system, will become more complicated if we also add options and variants to the EBOM. I assume you know the difference between a variant and an option.

In this case, the EBOM the definition for the full product range. Actually, the top part of the EBOM does not exist as an instance. It is the placeholder to select a resolved EBOM for a specific product configuration.  For the ease of use, I have simplified the initial diagram, now zooming in on variants and options, apologizing for my artistic capabilities as the purpose of a blog is different from a book.

If we look at the diagram, this configured structure contains variants and options.

First, on the logical definition, we see a new grouping. There are two types of Line Feed available, one specific for the X-123 and a later, more generic designed LF100, suitable for all X-1nn variants.

As the LF100 is more generic designed, the customer can select between two motors, the standard P280 and the more advanced version P360, with better service capabilities.

For the Line Feed LF200, there is an option to order a Noise Reduction Cover. It was sold once to an existing customer, and as the cover fits all X-123, it has been linked here as an option to the X-123 definition. So, the customer solution with the Noise Reduction Cover does not have an isolated, copied structure in the EBOM.

Also, in the Logical Structure, we see there is a cabling definition for the X-123 or the default cabling set for all other products.

The diagram illustrates what many mid-market companies have been doing more or less in their PDM-system to avoid copying of EBOM structures per customer order.
It is an example of where a tool (the PDM-system) is slowly abused for administrative reasons. Let me explain why.

The link between Products and (E)BOMs

If we look at the upper part of the configured EBOM structure, this is a logical product definition. Or to say it in different words, it is a portfolio definition, which products and modules a company can sell to the market. Some of the grouping of the portfolio is purely based on business reasons, which products and options do we want to sell.

In most companies, the product portfolio is managed in (marketing) documents without a direct connection to the engineering world. However, we will see in an upcoming post, this relation is crucial for a digital enterprise. Meanwhile, look at on old blog post: Products, BOMs and Parts if you want to be faster

The Engineering definition below the red dashed line is a real EBOM, representing the engineering definition of a system, a module, or a component. When these systems and modules are defined in a single structure that can be filtered based on selection criteria, we talk about a Configured EBOM or sometimes a 150 % EBOM.

Each of the components in the configured EBOM can have a related 3D CAD structure or specification that can be developed traditionally.

The result of a resolved EBOM is a variant that can be delivered to the customer. In this EBOM-driven approach, there is not always a full 3D-representation of the customer product.

Again, size (1500+) words make me stop this story, where next time we will go from product to EBOM and introduce the need for an MBOM in specific industries.

Conclusion

A pure EBOM only specifies a product and contains all relevant information in context – designs & specifications. The EBOM should not be mixed or confused with a logical grouping, belonging to a portfolio definition (even if the system allows you to do it)

On my previous post shared on LinkedIn Ilan Madjar, a long-time PLM colleague reacted with the following point (full thread here)

Ilan is pointing to the right challenge in many companies. Changing the way you work is though exercise and requires a good understanding, vision, and execution to move forward. Do not trust the tool to work for you – it is about human understanding and process re-engineering to be more efficient. And if you do not practice this on the basic PDM-level as discussed so far, imagine the impossibility of going through a digital transformation.

 

Learning from the past to understand the future – The BOM and the configured EBOM (4)

July 12, 2020 in 3D CAD management, BTO, CAD data management, CTO, EBOM, PDM, PLM | Tags: , , , , , | 3 comments

Last time in the series Learning from the past to understand the future, we zoomed in on how the 3D CAD-structure in the mid-market had to evolve. In a typical Engineering To Order (ETO) scenario, it makes sense to extract from the 3D CAD-structure a BOM-structure to collect all the individual parts that are needed for manufacturing. Combined with the drawings generated based on the 3D CAD assemblies/parts, the complete manufacturing information could be provided. Let’s have a look.

The BOM in ERP (part 1)

To understand what most mid-market companies have been doing, I created the image below. When you click on it, you will have an enlarged version.

Note: for educational purposes an extremely simplified example

There is a lot to explain here.

First, on the right we see the 3D CAD assembly, two phantom assemblies, grouping the wheels and the axle. And at the end, the individual parts, i.e. chassis, axle, and wheel. The 3D CAD-structure is an instance-based structure; therefore, there are no quantities in the structure (all quantity 1)

For the individual parts, there are drawings. Also, for the product, we have an assembly drawing. The drawings are essential as we want to have them in the ERP-system for manufacturing.

Finally, the physical parts, now with a different ID than the drawing as we learned this one-to-one relation created a lot of extra work. The physical parts are often called Items or Materials (SAP naming). Unfortunately, for engineering, there is a different meaning behind Materials. Still, SAP’s data model was not built with an engineering mindset.

The physical part structure, which we call the BOM contains quantities. Most PDM-CAD-integrations can filter out phantom assemblies and summarize the parts on the same level

I am still reluctant to call the Part-structure an EBOM as the design of the product has been mainly focusing on extracting manufacturing information, parts, and drawings.

The BOM in ERP (part 2)

In customized PDM-implementations, some implementers created an interface from the BOM-structure to ERP, so the ERP-system would have the basic definition of the parts and a copy of the relevant drawings.

Now manufacturing could create the manufacturing definition without the need to go into the PDM-system.

Some “clever” – Dick Bourke would say “smart – therefore lazy” – proposed to “draw” also manufacturing entities in the 3D CAD-structure, so the PDM-CAD-interface would automatically deliver manufacturing parts too inside the ERP. In the example below, we added paint for the body and grease needed for the axels.

Although “smart, a new problem was introduced here – the 3D CAD-structure, instance-based, always has quantities 1. The extracted BOM would have rounded numbers when considering design parts. Now the grease comes with an estimate of  0.025 kg, assuming quantities are based on SI-units. We could also add other manufacturing information to this BOM, like 0.3-liter paint. Anyway, the result would look like below:

Important to notice from the diagram here: There are placeholders for grease and paint “drawn” in the 3D CAD-structure – parts without a geometrical definition and, therefore, not having an associated drawing. However, these parts have a material specification, and therefore in the BOM-structure, they appear as Materials.

Next in the BOM-structure, the engineers would enter the expected/required quantity – which is no longer a rounded number.

At this stage, you cannot call the BOM on the left an EBOM. It is a kind of hybrid structure, combining engineering and manufacturing data. A type of BOM we discover a lot in companies that started with a type of ETO-product.

The ETO-product

Many companies that developed specialized machinery have started with a base product, from where they developed the custom solution – their IP. Next, with more and more customers, the original solution was extended by creating either new or changed capabilities.

I worked a lot with companies that moved to the full definition of their products in 3D CAD, creating a correct 3D CAD-structure per customer order. Instead of creating new BOM variants, companies were often tempted/forced to make the configuration inside the 3D CAD-model.

The 3D CAD vendor often provided functionality to have multiple configurations of the same part/product inside a single file. A nice feature for designers as there are fewer files to maintain, however, a crime for data management.

Every time one of the configurations of the part would change, or a new configuration was added, the file has to be revised.

And if the change was at level five of a 3D CAD-structure, many assembly files needed to be updated. The versioning problem illustrates the challenge of managing configurations inside a 3D CAD-file, meanwhile creating complexity for the PDM/PLM-system.

Last week Tech-Clarity published the highlights of their survey: Bringing Custom-Engineered Products to Market with a link to the full report, sponsored by Propel.

As you can imagine, this survey is more about PLM collaboration, breaking down the silos and acting agile. Unfortunately, the report does not expose required methodologies, like modularity and “common sense” engineering practices that we discuss here. Still worthwhile to read as the report addresses precisely the type of companies I am referring too here.

If we look at the methodology of custom-engineered products, let us look at how their “best practice” from the past is blocking the future.

When a new customer request is coming in, sales engineering is looking for the best match of delivered products. Hopefully, 80-90 % remains the same, and engineering has to focus only on the differences.

First, the best-match 3D CAD-structure is copied to a new project. As you can see most 3D CAD-systems provide the functionality to create a derived structure from an original 3D CAD-structure. From there, a traditional ETO-process starts as described at the beginning of this post. We complete the 3D CAD-structure with manufacturing in mind, generate the BOM and drawings, and we can deliver. In the case of purchase parts, the generated BOM often contains already the supplier part number in the 3D CAD-structure as we are focusing on this single delivery.

The disadvantage of this approach that in theory, we have to check if the structure that we reused is really the best so far, otherwise we introduce errors again.

The second disadvantage is that if one supplier part in the structure becomes obsolete and needs to be revised, the company has to go through all the 3D CAD-structures to fix it.

Also, having supplier parts in the 3D CAD-structure makes it more difficult to standardize, as the chosen supplier part matched the criteria for that customer at that time. Will it match the criteria also in other situations?

From ETO to BTO to CTO

Many companies that started with custom-engineered products, the ETO-approach, want to move towards a Configure To Order (CTO) approach – or if not possible at least Build To Order (BTO). More reuse, less risk,  instead of creating every time a new solution for the next customer, as discussed before.

This is not a mission impossible; however, often, I have seen that companies do not set the right priorities to move towards a configure to order environment. There are a few changes needed to become a configure to order company (if possible):

  1. Analyze your solution and define modules and options. Instead of defining a full solution, the target now is to discover a commonality between the various solutions. Based on commonality, define modules and options in such a manner that they can be used in different situations. Crucial for these modules is that there is a standard interface to the rest of the product. Every company needs to master this specific methodology for their products
  2. Start defining products from a logical structure, defining how products, modules and options are compatible and which combinations are allowed (or preferred). For companies that are not familiar with logical structure, often a configured EBOM is used to define the solutions. Not the optimal way; however, this was the first approach most companies took ten years ago. I will explain the configured EBOM below.
  3. A product definition and its modules now should start from a real EBOM, not containing manufacturing characteristics. The EBOM should represent the logical manner of how a product is defined. You will notice this type of EBOM might be only 2 – 3 levels deep. At the lowest level, you have the modules that have their own lifecycle and isolated definition.
  4. You should no longer use supplier part numbers in your EBOMs. As the engineering definition of a module or option should not depend over time from a single supplier. We will discuss in the next post the relation between EBOM parts and the Approved Manufacturer List (AML)

To conclude for today

Changing from ETO to CTO requires modularity and a BOM-driven approach. Starting from a 3D CAD-structure can still be done for the lowest levels – the modules, the options. In a configure to order process, it might not be relevant anymore to create a full 3D-representation of the product.

However, when we look forward, it would be greatly beneficial to have the 3D-representation of every specific solution delivered. This is where concepts as augmented/virtual reality and digital twin come in.

Next time more on the BOM-structures – as we have just touched the upcoming of the EBOM – enough to clarify next week(s).

Learning from the past to understand the future – 3D CAD-structure and BOM (3)

July 5, 2020 in 3D CAD management, CAD data management, CTO, EBOM, Education, ETO, PLM, SMB | Tags: , , | 2 comments

In my last post related to Learning from the past to understand the future, I discussed what happened when 3D CAD became available for the mid-market. In the large automotive or aerospace & defense companies, 3D CAD has been introduced along the path of defining processes and selecting tools. In the mid-market 3D CAD started from the other side, first as a productivity tool, not thinking further to change methodologies or processes.

The approach starting with 3D CAD without changing processes, has created several complexities. Every company that is aiming to move towards a digital future needs to reduce complexity to remain competitive. Now let us focus on the relation between the 3D CAD-structure and a BOM.

The 3D CAD-structure

When building a product in a 3D CAD system, the concept is that you have individual parts designed in 3D.  Every single part has a unique identifier.

If possible, the (file) name would equal the physical part number.

Next, a group of parts could be stored as a subassembly. Such an assembly is sometimes called a phantom assembly, in case they only group together several 3D parts. The usage of this type of assemblies increased CAD productivity. For data management reasons, these assemblies need to have a unique identifier, preferably not with the same numbering scheme for physical part numbers. It would consume part numbers that would never be used during manufacturing.

Note: in the early days of connecting 3D CAD to ERP, there was a considerable debate about which system could generate the part number.

ERP has always been the leading system for parts definition, why change ? And why generate part numbers that might not be used later in production. “Wasting” part numbers was a bad practice as historically, the part number was like a catalog number: 6 to 7 digits.

Next, there is also another group of subassemblies that represent one or more primary components of a product. For example, a pump assembly, that might be the combination of the pump, the motor, and the base frame. This type of assembly appears most of the time high in the CAD-structure. They can be considered as a phantom assembly too, regarding a required identifier for this subassembly.

Finally, there might be parts in the CAD-structure that will not exist in reality as part but need to be created during the manufacturing process. Sheet metal parts are created during the manufacturing process. Cappings, strips and cables shown in the CAD-structure might come from materials that are purchased in standardized sizes (1 meter / 2 meter / 10 meter) and need to be cut during manufacturing. Here the instances in the CAD-structure will have a unique identifier. What type of identifier to use depends on the manufacturing process. It might be a physical part number, as it is a half-fabricate,  or it remains a unique identifier for the CAD-structure only.

The reason I am coming back to these identifiers is that as described before, companies wanted to keep a relation between the part number and the file name.

There was a problem with flexible parts. A rubber hose with a specific length could be shaped differently in an assembly based on its connection. Two different shapes would create two files and therefore break the rule of a part number equals file name. The 3D CAD vendors “solved” this issue by storing configurable views of the same part inside one file and allow the user to select the active view.

Later we will see that management of views inside the 3D CAD model is not a wrong choice. This, contrary to managing different configurations of a part/product inside a single file, which creates complexity in the PLM domain.

In the end, the product became an assembly with several levels of subassemblies. At that time, when I worked a lot with CAD-integrations, the average depth of 3D CAD-structures was 6 to 7 levels deep, with exceptions in both directions.

The entire product CAD-structure is mainly used for a final digital mock-up, to allow engineers to analyze the full product behavior.  One of my favorite YouTube movies is the one from Airbus – seven years ago, they described the power of a full digital mock-up used for the A380.

In ETO-processes, the 3D CAD-structure is unique for a given customer solution – like the A380.

In the case of large assemblies with a lot of parts and subassemblies,  there were situations where the full product could not be resolved anymore. For Airbus a must, for the mid-market not always easy to reach.  Graphics memory, combined with the way graphics were represented, are the major constraint. This performance issue is resolved in the gaming world, however then the 3D representation had no longer the required accuracy or definition.

The Version pop-up problem

Working with a 3D CAD structure created a new problem when designers were sharing parts and assemblies between themselves and suppliers. The central storage of the files required a versioning mechanism, supported by a check-in and check-out mechanism.

Depending on the type of 3D CAD integration, the PDM system generated a new minor revision of the file after check-in again. In this way, there was full traceability of the changes before release. The image below shows an example of how SmarTeam was dealing with minor and major revisions combined with lifecycle stages.

When revising a part, all assemblies that contained the changed part need to be updated too, in case you want to have traceability and preventing others from overwriting your version. Making sure this assembly file points to the right file again. In the cases of a 6-level deep CAD-structure, this has led to a lot of methodology problems on how to deal (or not to deal) with file changes.

In the case of a unique delivery for a customer, the ETO-process, the issue might not be so big. As everything in the 3D CAD-structure is work in progress, you only need to be sure during the release process of the 3D CAD-structure that all parts and assemblies are resolved to the latest version (and verified)

Making changes on an existing product is way more complicated, as assemblies are released, and parts exist in production.  In that case, the Bill of Material is the leading structure to control the versions and the change impact, as we will see.

Note: Most CAD- and PLM-vendors loved to show you their demos, where starting from the CAD-structure, a product gets created (the ETO-process). The reality is that most companies do not start from the CAD-structure, but from an existing Bill of Material. In 2010, I wrote a few posts, discussing the relation between CAD and the BOM:

to explain there is more than a CAD-driven scenario.

The EBOM

In most PDM-systems with CAD-integrations, it is possible to create a Bill of Materials from the 3D CAD-structure. The Bill of Materials will be based on the parts inside the 3D CAD-structure. There is often the option to filter out phantom assemblies.

The structures are not the same. The 3D CAD-structure is instance-based, where the extracted Bill of Materials will summarize the part quantities on the same level.  See the image below. There are four Wheel instances in the CAD structure, in the EBOM-structure, we have only one Wheel reference with quantity 4.

I named the structure on the right the EBOM as the structure represents the Bill of Materials from the engineering point of view. This definition is a little arbitrary, as we will see. In companies that started to develop products based on a conceptual BOM, often, this conceptual BOM was an “early” EBOM that had to be developed further. This EBOM was more representing a logical or modular structure driving the design, instead of an extract from the 3D CAD-structure. In the next post, I will zoom in on these differences. I want to conclude this time with a critical methodology needed to manage the 3D CAD structure changes in relation to an EBOM.

Breaking the rule Drawing ID (Model ID)  = Part ID

Although I have been writing mostly about the 3D CAD structure, I want to remind us that the 3D Model in the mid-market is mainly used for design purposes. The primary delivery for manufacturing or a supplier is still a 2D-drawing for most companies. The 3D Model might be “nice to have” for CAM- or quality usage. Still, in case of a dispute, the 2D Drawing will be leading.

For that reason, in many mid-market companies, there was the following relation below:

In an environment without file versioning through check-in/check-out, this relation was easy to maintain. In the electronic world, every change in the 3D Model (which could be an assembly) triggers a new file version and, therefore, most of the time, a new version of the drawing and the physical part. However, you do not want to have a physical part with many revisions, in particular when this part could be again part of a Bill of Material.

To solve this issue, the Physical Part and the related Drawing/Model should have different lifecycles. The relation between the Physical Part and the Drawing Model should no longer be based on numbers but on a relation in the PDM/PLM-system. One of the main characteristics of a PDM/PLM-system is that it allows users to navigate through relations to find information in context.  For example, solving a Where Used – question is a (few) mouse-click(s) in a PDM/PLM-system.

Click on the image to see the details.

Breaking this one-to-one numbering rule is a must if you want to evolve to an item-centric or data-driven PLM-environment. When to introduce this change and how to implement this new behavior is a methodology exercise, not an implementation of a new tool.

There is a lot to read about this topic as it is related to the Form-Fit-Function-discussion we had earlier this year. A collection of information can be found in these two LinkedIn-post, where the comments are providing the insights:

 

I will not dive deeper into this theme (reached 1700 words ☹) – next time I will zoom in on the EBOM and leave the world of 3D CAD behind (for a while)

 

 

PLM Storytelling

June 21, 2020 in Blocking change, Brain, Change, Digital Enterprise, Education, Myths, PLM, Storytelling | Tags: , , , , | 2 comments

This time a short post (for me) as I am in the middle the series “Learning from the past to understand the future” and currently collecting information for next week’s post. However, recently Rob Ferrone, the original Digital Plumber, pointed me to an interesting post from Scott Taylor, the Data Whisperer.

In code: The Virtual Dutchman discovered the Data Whisperer thanks to the original Digital Plumber.

Scott’s article with the title: “Data Management Hasn’t Failed, but Data Management Storytelling Has” matches precisely the discussion we have in the PLM community.

Please read his article, and just replace the words Data Management by PLM, and it could have been written for our community. In a way, PLM is a specific application of data management, so not a real surprise.

Scott’s conclusions give food for thought in the PLM community:

To win over business stakeholders, Data Management leadership must craft a compelling narrative that builds urgency, reinvigorates enthusiasm, and evangelizes WHY their programs enable the strategic intentions of their enterprise. If the business leaders whose support and engagement you seek do not understand and accept the WHY, they will not care about the HOW. When communicating to executive leadership, skip the technical details, the feature functionality, and the reference architecture and focus on:

  • Establishing an accessible vocabulary
  • Harmonizing to a common voice
  • Illuminating the business vision

When you tell your Data Management story with that perspective, it can end happily ever after.

It all resonates well with what I described in the PLM ROI Myth – it is clear that when people hear the word Myth, they have a bad connotation, same btw for PLM.

The fact that we still need to learn storytelling is because most of us are so much focused on technology and sometimes on discovering the new name for PLM in the future.

Last week I pointed to a survey from the PLMIG (PLM Interest Group) and XLifcycle, inviting you to help to define the future definition of PLM.

You are still welcome here: Towards a digital future: the evolving role of PLM in the future digital world.

Also, I saw a great interview with Martin Eigner on Minerva PLM TV interview by Jennifer Moore. Martin is well known in the PLM world and has done foundational work for our community

. According to Jennifer, he is considered as The Godfather of PLM.  This tittle fits nicely in today’s post. Those who have seen his presentations in recent years will remember Martin is talking about SysLM (System Lifecycle Management) as the future for PLM.

It is an interesting recording to watch – click on the image above to see it. Martin explains nicely why we often do not get the positive feedback from PLM implementations – starting at minute 13 for those who cannot wait.

In the interview, you will discover we often talk too much about our discipline capabilities where the real discussion should be talking business. Strategy and objectives are discussed and decided at the management level of a company. By using storytelling, we can connect to these business objectives.

The end result will be more likely that a company understands why to invest significantly in PLM as now PLM is part of its competitiveness and future continuity.

Conclusion

I shared links to two interesting posts from the last weeks. Studying them will help you to create a broader view. We have to learn to tell the right story. People do not want PLM – they have personal objectives. Companies have business objectives, and they might lead to the need for a new and changing PLM. Connecting to the management in an organization, therefore, is crucial.

Next week again more about learning from the past to understand the future

Learning from the past to understand the future. The introduction of 3D CAD and PDM (2)

June 14, 2020 in 3D CAD management, CAD data management, Education, PDM, PLM, SmarTeam, SMB | Tags: , , , , | Leave a comment

To understand our legacy in the PLM-domain, what are the types of practices we created, I started this series of posts: Learning from the past to understand the future. My first post (The evolution of the BOM) focused on the disconnected world between engineering  – generation of drawings as a  deliverable – and execution MRP/ERP – the first serious IT-systems in a company.

At that time, due to minimal connectivity, small and medium-sized companies had, most of the time, an informal connection between engineering and manufacturing. I remember a statement at that time, PLM was just introduced. One person during a conference claimed:

“You guys make our lives so difficult with your systems. If we have a problem, we gather around the machine, and we fix it.”

PLM started at large enterprises

Of course, large enterprises could not afford such behavior as they operate globally. The leading enterprises for PDM/PLM were the Aerospace & Defense and Automotive companies. They needed consistent processes and formal ways of working to guarantee quality output.

In that sense, I was happy with the reaction from Jean-Jacques Urban-Galindo, who shared in the LinkedIn comments a reference to a relevant chapter of John Stark’s PLM book. In the pdf describing the evolution of CAD / PDM / PLM at PSA. Jean-Jacques was responsible at that time for Responsible for the re-engineering of the Product & Process Engineering processes using digital tools (CAD/CAM, DMU, and more).

Read the PSA story here: PLM at GROUPE PSA. It describes nicely where 3D CAD and EBOM are coming in.  In large enterprise like PSA, the need for tools are driven by the processes. When you read it to the end, you will also see the need for a design and a manufacturing view. A topic I will touch in future posts too.

The introduction of 3D CAD in the mid-market

Where large automotive and aerospace companies already invested in (expensive) 3D CAD hard and software, for the majority of the midsize companies, the switch from 2D CAD (AutoCAD mainly) towards 3D CAD (SolidWorks, Solid Edge, Inventor) started at the end of the 20th century.

It was the time that Microsoft NT became a serious platform beside the existing mainframe and mini-computer based CAD-systems. The switch to PCs went so fast that the disruption from DEC (Digital Equipment Company) is one of the cases discussed by Clayton Christensen in his groundbreaking book: The Innovator’s dilemma

3D CAD introduced a lot of new capabilities, like DMU (Digital Mock-Up), for clash detection, and above all, a better understanding of a product’s behavior. The introduction of 3D CAD introduced a new set of challenges to be resolved.

For example, the concept of reusing 3D CAD parts. Mid-market companies, most of the time, are buying productivity tools. Can I design my product faster and with higher quality in 3D instead of using only the 2D definitions?

Mid-market companies usually do not redesign their business processes – no people available for strategy – the pain of lack of strategy is felt in a different way compared to large enterprises—a crucial differentiator for the future of PLM.

Reuse of (3D) CAD parts / Assemblies

In the 2D CAD world, there was not so much reuse of CAD parts. Standard parts were saved in libraries or generated on demand by parametric libraries. Now with 3D CAD, designers might spend more time to define the part. The benefits come from the reuse of small sub-assemblies (modules) into a larger product assembly. Something not relevant in the 2D CAD world.

As every 3D CAD part had to have a file name, it became difficult to manage the file names without a system. How do you secure that the file with name Part01.xxx is unique? Another designer might also create an assembly, where the 3D CAD tool would suggest Part01.xxx as the name. And what about revisions? Do you store them in the filename, and how do you know you have the correct and latest version of the file?

Companies had already part naming rules for drawings, often related to the part’s usage similar to “intelligent” numbers I mentioned in my previous post.

With 3D CAD it became a little more complicated as now in electronic formats, companies wanted to maintain the relation:

Drawing ID = Part ID = File Name

The need for a PDM-system,

If you look to the image on the left, which I found in one of my old SmarTeam files, there is a part number combined with additional flags A-A-C, which also have meaning (I don’t know ☹ ) and a description.

 

The purpose of these meaningful flags was to maintain the current ways of working. Without a PDM-system, parts of the assembly could be shared with an OEM or a supplier. File-based 3D CAD without using a PDM-system was not a problem for small and medium enterprises.

The 3D CAD-system maintained the relations in the assembly files, including relations to the 2D Drawings. Despite the introduction of 3D CAD, the 2D Drawing remained the deliverable the rest of the company or supply chain, was waiting for. Preferably a drawing containing a parts list and balloon numbers, the same as it has been done before.  Why would you need a PDM-system?

PDM for traceability and reuse

If you were working in your 3D CAD-system for a single product, or on individual projects for OEMs, there was no significant benefit for a PDM-system. All deliveries needed for the engineering department were in the 3D CAD environment. Assembly files and drawing files are already like small databases, containing references to the source files of the part (image above).

A PDM-system at this stage could help you build traceability and prevent people from overwriting files. The ROI for this part only depends on the cost and risks of making mistakes.

However, when companies started to reuse parts or subassemblies, there was a need for a system that could manage the 3D models separately. This had an impact on the design methodology.

Now parts could be used in various products. How do you discover parts for reuse, and how do you know you have the last released version.  For sure their naming cannot be related anymore to a single product or project (a practice still used a lot)

This is where PDM-systems came in. Using additional attributes per file combined with relations between parts,  allowing companies to structure and deliver more details related to a part. A detailed description for internal usage, a part type (classification), and the part material were commonly used attributes. And not to forget the status and revision.

For reuse, it was important that the creators of content had a strategy to define a part for future reuse or discovery. Engineerings were not used to provide such services, filling in data in a PDM-system was seen as an overhead – bureaucracy.

As they were measured on the number of drawings they produced, why do extra work with no immediate benefits?

The best compromise was to have the designer fill in properties in the CAD-file when creating a part. Using the CAD-integration with the PDM-system could be used to fill attributes in the PDM-system.

This “beautiful” simple concept lead later to a lot of complexity.

Is the CAD-model the source of data, meaning designers should always start from CAD when designing a product. If someone added or modified data in the PDM-system, should we open the CAD-file to update some properties? Changing a file means it is a new version. What happens if the CAD-file is released, and I update some connected attributes in PDM?

To summarize this topic. Companies have missed the opportunity here to implement data governance. However, none of the silos (manufacturing preparation, service) recognized the need. Implementing new tools (3D CAD and PDM) did not affect the company’s way of working.

Instead of people, processes, tools, the only focus was on new tools and satisfying the people withing the same process.

Of course, when introducing PDM, which happened for mid-market companies at the beginning of this century, there was no PLM vision. Talking about lifecycle support was a waste of time for management. As we will discover in the future posts, large enterprises and small and medium enterprises have the same PLM needs. However, there is already a fundamentally different starting point. Where large enterprises are analyzing and designing business processes, the small and medium enterprises are buying tools to improve the current ways of working

The Future?

Although we have many steps to take in the upcoming posts, I want to raise your attention to an initiative from the PLM Interest Group together with Xlifecycle.com. The discussion is about what will be PLM’s role in digital transformation.

As you might have noticed, there are people saying the word PLM is no longer covering the right context, and all kinds of alternatives have been suggested. I recommend giving your opinion without my personal guidance. Feel free to answer the questionnaire, and we will be all looking forward to the results.

Find the survey here: Towards a digital future: the evolving role of PLM in the future digital world

 

Conclusion

We are going slow. Discovering here in this post the split in strategy between large enterprises (process focus) and small and medium enterprises (tool focus) when introducing 3D CAD. This different focus, at this time for PDM, is one of the reasons why vendors are creating functions and features that require methodology solving – however, who will provide the methodology.

Next time more on 3D CAD structures and EBOM

Learning from the past to understand the future. The evolution of the BOM (1)

June 1, 2020 in CAD data management, CM, Configuration Management, Education, PLM | Tags: , , | 2 comments

In my last post, My four picks from PLMIF,  I ended with the remark that the discussion related to the Multiview BOM concept was not complete. The session presented by James Roche focused on the Aerospace & defense domain and touched the surface. There is a lot of confusion related to best practices associated with BOM-handling. Sometimes created to promote unique vendor capabilities or to hide system complexity.

Besides, we need to consider the past as, in particular, for PLM, the burden of legacy processes and data is significant. Some practices even come from the previous, paper-based century, later mixed with behavior from 3D CAD-systems.

Therefore, to understand the future, I will take you through the past to understand why certain practices were established. Next, in a few upcoming posts, I want to explain the evolution of BOM-practices. How each new technology step introduced new capabilities that enabled companies to improve their product delivery process.

I will describe the drawing approach (for PLM – the past), the item-centric approach (for PLM – the current), and the model-driven approach(for PLM – the future). How big this sequence will become is not clear at this stage.

Whenever I come close to 1200 – 1500 words, I will stop and conclude. Based on my To-do list and your remarks, I will continue in a follow-up post.  The target will be to have a vendor-neutral collection of information to help you identify your business and the next possible steps.

Working with drawings

MRP/ERP – the first IT-system

For this approach, I go back fifty years in time, when companies were starting to work with their first significant IT-system, the MRP-system. MRP stands for Material Requirements Planning. This system became the heart of the company, scheduling the production. The extension to ERP (Enterprise Resource Planning) quickly after, made it possible to schedule other resources and, essential for the management, to report financials. Now execution could be monitored by generating all kinds of reports.

Still, the MRP/ERP-system was wholly disconnected from the engineering world as the image shows below. Let us have a look at how this worked at that time.

The concept

Products have never been designed from scratch by jumping to drawings. In the concept phase, a product was analyzed, mainly on its mechanical behavior. Was there anything else at that time? Many companies thank their existence from a launching product which someone, most of the time, the founder of the company, invented in a workshop. The company than improved and enriched this product by starting from the core product, creating enhancements in various areas of applicability.

These new ideas were shared through sketches and prototypes.

The design

The detail design of a product is delivered by a technical documentation set, often a package of manufacturing drawings containing a list of parts on the drawing, assembly with instructions. Balloon numbers are used to indicate parts in an assembly or section view.  In addition, there are the related fabrication drawings. The challenge for this approach is that all definitions must be there uniquely and complete to avoid ambiguity, which could lead to manufacturing errors.

The parts list contains make-parts, supplier parts, and standard parts. The make-parts are specified again by manufacturing drawings, identified by a number that uniquely identifies the correct drawing version. A habit here: Part number = Drawing Number (+ revision)

As the part is identified by a drawing the part most of the time got an “intelligent” part number and a revision. Intelligent to support easy recognition and revisions as at the end we do not want to generate a new part number when there is an evolution of the part. Read more about this in What the FFF is happening and “Intelligent” part numbers?

The standardized parts can be either company standard parts or external standard parts. There is a difference between them.

A company standard part could be a certain bracket, a frame. Anything that the company decided to standardize on for its own products Company standard parts are treated like make parts; they have an identifier related to their manufacturing drawings.  Again, here the habit: Part Number = Drawing Number (+ revision)

The supplier part is coming from a supplier that manufactures this part based on the supplier or market specifications. You can specify this part by using the supplier’s catalog number or refer to the standard.

For example, the part that has been specified under a certain ISO/ANSI/DIN-standard. For example, a stainless-steel bolt M8 x 1,25 x 20, meaning a metric bolt with a head diameter of 8 mm, a speed of 1,25 mm, and a length of 20 mm. You specify the standard part according to the standard. Purchasing will decide where to buy this part

Manufacturing Preparation

This is the most inefficient stage when working in a traditional drawing approach. At this stage, the information provided in drawings needs to be entered into the MRP/ERP-system to start production. This is the place where information is thrown over the wall as some might say.

This means a person needs to create process steps in the ERP-system based on the drawing information. For each manufacturing step, there needs to be a reference to the right drawing. Most ERP-systems have a placeholder where you can type the drawing number(s). Later, when companies were using CAD, there could be a reference to a file.

The part number in the ERP-system might be the same as the drawing number; however, the ERP-system requires unique numbers. In the beginning, ERP-systems were the number-generator for new parts. The unique number was often 6 to 7 digits in size, because it fits in our human short-term memory.

The parts list on the drawings had to be entered in the ERP-system too. A manual operation that often required additional research from the manufacturing engineer. As the designer might have specified the SS Bolt M8 x 1,25 x 20 as such, manufacturing preparation has to search in the ERP-system for the company’s part number.

Suppliers have to be sourced for outside manufactured make-parts. In case you do not want to depend on a single supplier, you have to send drawings and specifications to the supplier before the product is released. The supplier will receive a drawing number with revision and status warning.

If everything worked well the first time, there would be no iterations between engineering and manufacturing preparation. However, this is a utopia: prototype changes, potential manufacturing issues will require changes in the drawings. These changes require updates in the drawings, which will lead to new versions. How do you keep consistency between all identifiers?

Manufacturing

During manufacturing, orders are processed based on information from the ERP-system. The shop floor gets the drawing provided to the link in ERP. Sometimes there are issues during manufacturing. In coordination with engineering, some adaptations will be made to the manufacturing process. e.g., a changed fit or tolerance. Instead of going back to engineering to provide a new documentation set, the relevant drawings are redlined. Engineering will update these drawings whenever they touch them in the future (yeah, yeah).

Configuration Management

But will they update them? Perhaps already a new version existed due to the product’s evolution. Everything needs to be coordinated manually. Smaller companies heavily rely on people knowing things and talking together.

Larger companies cannot work in the same manner; therefore, they introduce procedures to guarantee that the information flow is consistent and accurate. Here the practices from configuration management come in.

There are many flavors of configuration management. Formal CM was first used in the 1950s to control the technical documentation for complex space and weapons systems. (Source ESA CM initiative for SME’s – © 2000) We will see it come back in future posts dealing with more complex products and the usage of computer systems.

Last year I wrote a few times about PLM and configuration management (PLM and CM – a happy marriage?) not relevant at this moment as there is no PLM yet.

Where is the BOM

As you might have noticed, there was no mentioning of a BOM so far. At this stage, there is only one Bill of Materials managed in the ERP-system. The source from the BOM comes from the various parts lists on the drawings, completed with manual additions.

Nobody talks in this stage about an EBOM or MBOM as there is only one BOM, a kind of hybrid BOM, where manufacturing steps were driving the way parts are grouped. Because the information was processed step by step, why would you like to have a multilevel BOM or a BOM tree?
Note: The image on the left was one of my first images in 2008 when I started my blog.

Summary

Working with drawings introduced “intelligent” part numbers as the documents have to be identified by manual interpretations. The intelligence of the part number was there to prevent people from making mistakes as the number already was a kind of functional identifier. Combined with a revision and versioning in the number, nothing could go wrong if handled consistently.

The disadvantage was that new employees had to master a numbering system. Next, the risk for all employees that a released drawing will not change its status. Only manual actions (retract/replace) will avoid making mistakes. And then, there are the disconnected redline drawings.

The “drawing number equals part number”  relation created a constraint that will be hard to maintain in the future.  Therefore you should worry if you still work according the above principles.

Conclusion

I reached the 1500 words – a long story – probably far from complete. I encourage readers to provide enhancements that might be relevant in the comments. This post might look like a post for dummies. However, to understand what is applicable to the future, we first need to understand why certain practices have been defined in the past.
I am looking forward to your comments and enhancements to make this a relevant stream of public information for all.

My four picks from PLMIF

May 17, 2020 in Change, CTO, Data centric, EBOM, Education, MBOM, PLM, ROI on PLM | Tags: , , , , | Leave a comment

Two weeks ago, I wrote about the PLM Innovation Forum, a virtual conference organized by TECHNIA, where I described some of my experiences with the event and the different ways of interaction in a virtual conference.

The content remains available till May 31st, so I had time to stroll through the rich content offered. In particular, if you are already familiar with the Dassault Systèmes & TECHNIA offerings, the content is extremely rich.

From the “auditorium“, I selected four presentations that have a logical relation to each other. I believe they will help you understand some of the aspects of PLM independent of the PLM vendor. Let’s start.

Value-Driven Implementation

In this session, Johannes Storvik, you can identify three parts. In the first part, Johannes talks about how to select the best PLM-approach, discussing the various options from custom, standardized, or even fully Out-Of-The-Box, comparing these options with building types. An interesting comparison, however, there is a risk with this approach.

Many companies are now stating they only need a collection of Commercial of the Shelf (COTS) systems and prefer only OOTB. The challenge with this approach is that you start from the tools, constraining the business from the start.

I would state start from your business goals, and ultimately they will lead to requirements for the tools. And then, if available, you find solutions that require no or minor adaptation. Starting from the business is crucial, and Johannes elaborates more on that.

The second part discussing PLM benefits, and if you are looking for confirmation PLM brings value, have a look at the topics, areas, and numbers mentioned. Most benefits and areas are quite traditional, related to a coordinated organization (if you follow my coordinated to connected typology).

The last part, connecting the dots from business to enablers, a Benefits Dependency Network, is a methodology that I recommend. Originally developed by Cranfield School of Management, it allows you to connect your PLM-needs to the company’s business needs and strategies. You can read more about this methodology in this HBR article: A tool to map your next digital initiative.

Benefits Dependency Network: note the potential storyline you can build

My experience from this methodology is that it allows you to extract one, two perhaps three storylines. These storylines then help you to explain why the PLM enablers are needed connecting to a business case into one understandable storyline, suitable for all levels in the company

With Johannes, we went from PLM-characteristics towards connecting PLM to the business and exec management, making PLM implicit visible at the management level. Now the next step.

Industrialization of the Construction Industry

The theme of this session might be misleading. Arto Tolonen, from the LETHO group, has a long history in PLM as a practitioner and at the University of Oulu, where he specialized in Product Data Management and Product Portfolio Management.

The last part of his presentation is dealing with transformational thinking for the construction industry from a one-off construction towards thinking in repeatable processes, using PLM practices. With his dry humor, he asks:
“Why are all buildings prototypes ?” and more.

For many years, I have been preaching PLM practices to be valuable for other industries too. See this 2013 post: PLM for all industries?  The most common challenge was to respond to the question:  “What does your tool do?”   PLM practices only become valuable if you think in repeatable processes.

The exciting part is when Arto talks about the disconnect between the exec level in an organization and reality in the field. Understanding how products are performing, and how each product contributes to the profit of the company, is usually blurred with subjective information. Your company’s love baby might be the worst performer but never dropped from the product portfolio for sentimental reasons.

Arto explains the importance of (digital) portfolio management, connecting the economic data with the technical data. And by doing so, use portfolio management to drive the development of new offerings based on market needs and numbers. Or to decommission products.

I am fully aligned with Arto and believe that a digital transformation should include a connected product portfolio management environment, driving new development projects. Product Portfolio management is not the same as BOM-management.

The portfolio items are facing the outside world, your customers. How the products are built, is defined in the inside world of BOMs and design data.

Now combining product portfolio management with product management makes a lot of more sense if you are going to use it to support the modularization of your products. Based on solution platforms, you can design your products to become modular, leading to a lot of business benefits.

With Arto, we discovered the need to have digital portfolio management connecting business performance and product development. Another implicit reason for PLM to your business explained with humor. Now the next step.

Modularization

Closely related to product portfolio management is the topic of modularization.  If you want to optimize your offering with a great variety of choices for your customers, without spending more time to develop an individual solution, you need to implement modularization for your products.

Daniel Strandhammar van Brick Strategy explains this topic in his session. So many companies I am working with a claim that they want to move from and ETO (Engineering To Order) model to a CTO (Configure To Order) model. Unfortunately, many of them keep on talking about that without making steps towards more configurable products.

Although in many PLM-infrastructures, the capabilities exist to support the modularity of a product portfolio, it requires thinking and analysis outside the tools. The tools are there to support the modularization. Still, it depends on your engineering teams to transform the company’s portfolio step by step into a more modular product.  Brick Strategy is typical such a company that can help you and coach you in a modularization process.

If you look at the benefits Daniel is mentioning related to modularization, these benefits are significant. However, as Daniel also explains per type of business, the effects of modularization might be different, still in every situation worth to invest.

It is interesting to know that many of the modularization methodologies come from Scandinavian countries. Perhaps a region, with companies like Scania (master of modularization), IKEA and others leading the ways towards modularization. Is it a surprise that LEGO is also a Scandinavian company?

Daniel continues by explaining how a roadmap for modularization could look like. If you are struggling with that point, have a look at the video. It is a crucial part of the story.

Note: There is also a presentation from Anders Malmberg fro Scania talking about their Starling project. Not particularly related to modularization, more related to how to organize significant PLM transformations.

With Daniel’s presentation, we see the relation between a product portfolio and modularization. Another implicit reason for PLM to improve your business explained. Now let’s do it.

 

Making Multi-view BOM a reality

My ultimate dream was that James Roche from CIMdata would complete the storyline. We went from business initiatives through product portfolio management and modularization through a flow of organizational topics to enhance your business outcome using PLM.

With James, I was hoping we now would get the final necessary part, the need for a multi-view BOM, and how to establish this. As I mentioned before with modularization, many companies started with a kind of ETO-approach to deliver solutions for their customers. The downside of this approach is that, when designing a product, the manufacturing process was already leading the way the BOM will be structured. Many of the companies that I work with are in this situation. There is no clear EBOM and MBOM, the situation is a kind of hybrid BOM, blocking modularity and multi-plant manufacturing.

James’s presentation unfortunate started with a 10 min technical delay, and then the next part is crucial to understand. He explains nicely what it means to have a “hybrid” single BOM and more to a multi-view EBOM/MBOM. James addressed this topic, both using an example looking at it from a technological and organizational view.

As James is the CIMdata Practice Director for Aerospace & Defense, this was the industry in focus and even example provided above is not necessarily the best solution for every A&D company. Organizational change and managing risks are crucial in such a transition, and that is where James spent even more time. It would be great, and I consider it one of my next blog options, to discuss and share best practices for other types of industries. Is there always a need for a multi-view BOM and are they all the same?

With James we concluded the PLM value story, making it my fourth pick of the PLMIF conference, giving you an end-to-end storyline why PLM is important and how it is connected to your business results.

 

Conclusion

The four presentations that I highlighted here show a storyline that is crucial to understand and pitch when you talk about the business value of PLM. It is not about technical features and functions. It is part of a business strategy, building the right portfolio, manage it in a modular manner, and use multiple BOM views to optimize the delivery of your products.

 

Note: two more weeks to see the full presentations of PLMIF – go and have a look in case you haven’t done so: http://www.plmif.org

 

 

 

The weekend after the PLM Innovation Forum

May 3, 2020 in Digital Enterprise, Education, Green Development, Innovation, Platform, PLM, Product Innovation, Social Media | Tags: , , , , , | 1 comment

I usually write a post after participating in a PLM conference. Last week, I participated in TECHNIA’s PLM Innovation Forum, which was a 100 % virtual event with over 1500 registered participants from 58 countries. These numbers show the power of a virtual conference during these difficult times. It is an excellent option for a sustainable future – less travel to be there.

The additional beauty of this event is that, although the live sessions are over, all the content will be available until May 31st. You can still join!

It was (and is) a well-organized and massive event with over 70 sessions; the majority pre-recorded. As you can imagine 70 live sessions in two days would be too massive to grasp. Today the Friday after the event, I have been watching other sessions that have my interest, and it felt like another conference day.

TECHNIA, globally the largest Dassault Systèmes (DS)  implementer after DS themselves as Jonas Geyer, Technia’s CEO,  mentioned in his introduction speech, illustrated the breadth of their industry and technology skills complementary or based on the 3DEXPERIENCE platform.

TECHNIA was supported by Dassault Systèmes Execs and subject experts. In addition, a larger group of companies and interest groups supported the conference, even our humble PLM Green Alliance as you can see in the image above.

I followed the full two live days in real-time, meanwhile man sitting in my virtual booth to chat with virtual visitors. To my surprise, the anxiety during the conference felt like a physical conference – you get energized.

The positive point for me,  no finger food or a standing lunch and decent coffee when needed. The point to enhance and learn for this type of event, is to make the booth a little more human – perhaps supported by video?

At the end,  a great event, and if you are interested in the Dassault Systèmes/TECHNIA combined offering, supported by customer stories, take the chance till the end of May to register and browse the rich content.

 

Now I will share some of my picks from the live event. Another post will come based on my additional discoveries and networking discussions.

 

 

The B.CONNECT project

Fabien Hoefer and Philip Haller both from B.Braun, a medical device, and pharmaceutical company, with a wide range of products.  Their massive PLM-project, approx. sixty persons involved was driven by the fact that every product has a lot of related data stored in different silos that it becomes impossible to have the correct understanding and status and to maintain it for the product and service lifecycle, on average, 10 – 15 years.

Their target is a real PLM-platform implementation connecting the people, the processes, data, and systems. Their aim is really about the “connected” approach, a characteristic of a digital company.

As you can still watch the presentation, look at the following topics discussed:

  • focus on product archetypes instead of division (portfolio management)
  • data templates based on classification, global and specific data sets (data governance)
  • the need to have a Master Data Management in place (data governance)
  • the unique product identifier (remember the FFF-discussion in my blog)
  • data-driven documentation (a perfect example of a digital PLM implementation)
  • platform strategy (one application for one capability in a heterogeneous systems environment)
  • Ownership of the PLM implementation at board level (it is not an engineering tool)
  • in the Q&A – the mix of waterfall & agile – the hybrid approach (as in the medical world the validation of the system is required – a point we missed in the SmarTeam FDA toolkit – validation of a system is needed when the system/processes change)

In the Q&A session, it was clear that the big elephant in the room, the migration, has been identified, but no answers yet. See my presentation to understand the reference to the elephant.  I am curious about B. Braun’s approach, given my experience with PLM digital transformations. Will it be entirely digital or hybrid.

Looking forward to learning more from Fabien or Philip.

Business drivers for Sustainable Manufacturing

This session, presented by Hannes Lindfred from TECHNIA, was one of my favorite presentations,  as it links tightly to what we want to achieve with the PLM Green Alliance.

The subtitle of the presentation says it all: “How PLM can support Supply chain transparency, Circular economy, and System oriented product development”.

In a relaxed and entertaining manner, he explained the concepts and the needs of a circular economy, combined with examples from reality. In particular, I liked his closing statement linking the potential of digitization, modern PLM, and the circular economy. We have to learn to think and act circular. Highly recommended to watch!

Leading PLM Trends & Potential Disruptors

A PLM conference would not be a PLM-conference if Peter Bilello from CIMdata would not be speaking. We share a lot of insights related to digital transformation and the understanding it requires the involvement of PLM. However, it is not the traditional PLM that is needed.

PLM needs to be rethought, think about the concept of a Product Innovation Platform. A digital platform is required if we want end-to-end digitalization; otherwise, we keep working in optimized silos.

Peter shared some survey results (see below) from early this year. It illustrates that most companies currently invest in traditional PDM aspects. Restating the need for our PLM communities to learn and educate and rethink aspects of PLM and learn to communicate them.

Remarkably similar to some of the aspects I explained in my: From Coordinated to Connected presentations. Changing to data, changing workforce, changing processes meaning systems thinking. Another plea for everyone to invest in learning. See his concluding remarks:

The closing Q&A session was interesting, addressing additive manufacturing, the graph database, and potential PLM disruptors coming from outside the traditional PLM space.

I recommend, pay attention to the closing questions – so many good points to put PLM in perspective.

From Coordinated to Connected & Sustainable

Of course, I recommend you watch my presentation. It is one of the few opportunities to hear in a short time all the thoughts and concepts that I developed over the past 5 – 6 years. It saves you reading all my blog posts, which are less structured than this presentation.

I recommend you to watch this presentation in the context of Peter Bilello’s presentation as there are a lot of similarities, told in different words.

After my presentation, I appreciated the Q&A part, as it allowed me to point to some more of the related topics: Legacy CAD-issues – the incompatibility of the past and future data, Management vision and the Perception of ROI.

 

Professional PLM
Raise your standards and your horizons

An interesting presentation to watch, after seeing Peter Bilello’s presentation and my presentation,  is the one given by Roger Tempest. Roger is another veteran in the PLM-world and co-founder of the PLM Interest group. For many years Roger is striving to get the PLM professional recognized and certified. We both share the experience that being a PLM consultant is not a profession to become wealthy.

One of the reasons might be that the scope of PLM and what is the required skill level is not precise. PLM considered as an engineering tool and PLM having so many diverse definitions.

The challenge of Roger’s approach is that it tries to capture people within a standardized PLM framework, which becomes apparent in the Q&A session. Currently, he is in the stage of building a steering group, “looking for companies that are fairly committed to PLM”. So which companies are the ones interested in PLM to commit time and resources to build a professional PLM body? This can be only academic people and PLM Vendors/Implementers. The last group will probably not likely agree on standardization.

Also related to the question about the different industries and maturity levels for companies came with an unsatisfactory answer. He talks about “absolute” PLM and no need to compare PLM with other industries. Here I believe there is such a fundamental difference in the meaning of PLM when talking to the traditional manufacturing companies as compared to high-tech/software-driven industries. I inserted here Marc Halpern’s maturity/technology diagram that I have been referencing in my presentation too.

The final question about vendors joining the PLM standardization group seems to be a utopia. As I expressed in my presentation, referring to Marc Halpern’s business maturity diagram, the vendors show us the vision of various business aspects related to PLM.

Marc already indicated this is the phase of the Product Innovation Platform.

As long as the professional PLM organization is focusing on defining the standard, I foresee the outside world will move faster and be more diverse than a single PLM expert can handle. A typical issue with many other standards as you can see below.

What’s Next

I hope to see and participate more in virtual PLM conferences as it allows much larger audiences to connect compared to traditional conferences. However, there are things to improve, and therefore I want to propose some enhancements:

Make sure during the “live” sessions, there is the experience of “being live and connected”. Even when streaming a pre-recorded lecture, always follow-up immediately with a live Q&A session. I found the Q&A sessions very educative as they clarify or put the presentation in a broader context.

The current virtual booth as only a chat room is too primitive – it reminded me of the early days of internet communication – discussion groups in ASCII-terminal mode through Compuserve (remember). A booth could become a virtual meeting space on its own – all, of course, depending on the amount of bandwidth available. The feeling of “The Doctor is in”

It is great that the content is available for 30 days, and I agree there is a need for a time limit on the content; otherwise, the conference becomes more a library. What I would like to see after the “live” days to still have a kind of place for sharing. What are your favorite presentations, and why should others look at it?

 

Conclusion

A great event and learning experience for me. Virtual conferences are the future for sure, and I encourage others to develop this type of conferences related to PLM further. It is a way to share knowledge and discuss topics in a sustainable manner. In the upcoming 30 days, I will come back to the conference one more time, based on interesting topics discovered or discussion related to the content. 

Meanwhile, I encourage you too – if you are still in lockdown and if there is time to study – this is one of these unique opportunities.

 

Translate

  1. Bart Willemsen's avatar

    Interesting reflection, Jos. In my experience, the situation you describe is very recognizable. At the company where I work, sustainability…

  3. Unknown's avatar
  4. 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…

  5. 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…