Monthly Archive

I promised to write some more down-to-earth post this year related to current PLM practices. If you are eager for my ideas for the PLM future, come to PI PLMx in London on Feb 4^th and 5^th. Or later when reading the upcoming summary: The Weekend after PI PLMx London 2019.

ECO/ECR for Dummies was the most active post over the past five years. BOM-related posts, mainly related to the MBOM are second: Where is the MBOM? (2007) or The Importance of a PLM data model: EBOM – MBOM (2015)  are the most popular posts.

In this post, an update related to current BOM practices. For most companies, their current focus while moving from CAD-centric to Item-centric.

Definitions

The EBOM (Engineering BOM) is a structure that reflects the engineering definition of a product, constructed using assemblies (functional groups of information) and parts (mechanical/electrical or software builds – specified by various specifications: 3D CAD, 2D CAD / Schematics or specifications). The EBOM reflects the full definition from a product how it should appear in the real-world and is used inside an organization to align information coming from different disciplines.

Note: This differs from the past, where initially the EBOM often was considered as a structure derived from the Mechanical Part definition.

The MBOM (Manufacturing BOM) is a structure that reflects the way the product is manufactured. The levels in the MBOM reflect the processing steps needed to build the product. Here based on the same EBOM different MBOMs can exist, as a company might decide that in one of their manufacturing plants they only assemble the product, wherein another plant they have tools to manufacture some of the parts themselves, therefore the MBOM will be different. See the example below:In case your company delivers products to their customers, either in a B2B or B2C model, the communication towards the customer is based on a product ID, which could be the customer part number (in case of B2B) or a catalog part number.  The EBOM/MBOM for this product might evolve over time as long as the product specifications remain the same and are met.

Does every company need an EBOM and MBOM?

Historically most companies have worked with a single BOM definition, due to the following reasons:

• In an Engineering-To-Order process or Build-to-Print process the company the target is to manufacture a product at a single site – Most of the time one product for ETO or one definition to many products in BTP. This means the BOM definition is already done with manufacturing resources and suppliers in mind.
• The PLM (or PDM) system only contained the engineering definition. Manufacturing engineers build the manufacturing definition manually in the local ERP-system by typing part numbers again and structuring the BOM according to the manufacturing process for that plant.

Where the first point makes sense, there might be still situations where a separate EBOM and MBOM is beneficial. Most of the time when the Build To Print activity is long-lasting and allows the company to optimize the manufacturing process without affecting the engineering definition.

The second point is describing a situation you will find at many companies as historically the ERP-system was the only enterprise IT-systems and here part numbers were registered.

Creating a PLM-ERP connection is usually the last activity a company does. First, optimize the silos and then think about how to connect them (unfortunate). The different structures on the left and right lead to a lot of complex programming by services-eager PLM implementers.Meanwhile, PLM-systems have evolved in the past 15 years, and a full BOM-centric approach from EBOM to MBOM is supported although every PLM vendor will have its own way of solving digital connectivity between BOM-items.You should consider an EBOM / MBOM approach in the following situations:

• In case you have a modular product the definition of the EBOM and MBOM can be managed at the module As modules might be manufactured at different locations, only the MBOM of the module may vary per plant. Therefore, fewer dependencies on the EBOM or the total EBOM of a product.
• In case a company has multiple manufacturing plants or is aiming to outsource manufacturing, the PLM-system is the only central place where all product knowledge can reside and pushed to the local ERPs when needed for potential localization. Localization means for me, using parts that are sourced in the region, still based on the part specification coming from the EBOM.

Are EBOM and MBOM parts different?

There is no real academic answer to this question. Let’s see some of the options, and you can decide yourself.

An EBOM part is specified by documents – this can be a document, a 3D model combined with 2D drawings or a 3D annotated model. In case this EBOM part is a standard part, the specification may come from a part manufacturer through their catalog.

As this part manufacturer will not be the only one manufacturing the standard part, you will see that this EBOM-part has potentially several MBOM-parts to be resolved when manufacturing is planned. The terms Approved Manufacturing List (AML) – defined by Engineering and Approved Vendor List (AVL) – based on the AML but controlled by purchasing apply here.Now the case that the EBOM-part is not a standard part. In that case, there are two options:

• The EBOM-part holds only the specifications and the EBOM-part will be linked to one or more MBOM-parts (depending on manufacturing locations). In case the part is outsourced, your company might not even be interested in the MBOM-part as it is up to the supplier to manufacture it according to specifications
• The EBOM-part describes a specification but does not exist as such individuals. For example, 1.2-meter hydraulic tube, or the part should be painted (not specified in the EBOM with quantity) or cut out of steel with a certain thickness. In the MBOM you would find the materials in detailed sizes and related operations.

Do we need an EBOM and MBOM structure?

In the traditional PLM implementations, we often see the evolution of BOM-like structures along the enterprise: Concept-BOM, Engineering BOM, Manufacturing BOM, Service BOM, and others. Each structure could consist of individual objects in the PLM-system. This is an easy to understand approach, where the challenge is to keep these structures up-to-date and synced with the right information.

See below an old image from Dassault Systemes ENOVIA in 2014:

Another more granular approach is to have connected data sets that all have their unique properties and by combining some of them you have the EBOM, and by combining other elements, you have the MBOM. This approach is used in data platforms where the target is to have a “single version of the truth” for each piece of information and you create through apps an EBOM or MBOM-view with related functionality. My blog-buddy Oleg Shilovitsky from OpenBOM is promoting this approach already for several years – have a look here.

So the answer do you need multiple BOM structures is:
Probably YES currently but not anymore in the future once you are data-driven.

Ultimately we want to be data-driven to allow extreme efficient data handling and speed of operations (no more conversions / no more syncing to be controlled by human resources – highly automated and intelligent is the target)

Conclusion

Even this post is just showing the tip of the iceberg for a full EBOM-MBOM discussion. It is clear that this discussion now is more mature and understood by most PLM-consultants as compared to 5 – 10 years ago.

It is a necessary step to understand the future, which I hope to explain during the upcoming PI PLMx event in London or whenever we meet.

Happy New Year to all of you. It has been a period of reflection – first disconnected from PLM and then again slowly getting my PLM-twisted brain back to work. And although my mind is already running in a “What’s next mode,” I would like to share with you first some of the lessons learned from last year.

Model-Based confusion

Most of the topics related to model-based approaches, from systems engineering, through engineering and manufacturing, leading to digital twins, are very futuristic; an end-to-end model-driven enterprise is not in reach for most of us. There are several reasons for that:

• Not every company has this need or discovered the need to have digital continuity and almost real-time availability of information end-to-end. As a result, there are still slow businesses.
• Understanding the needs for a model-driven enterprise takes time and effort. There are no available solutions on the market yet, so there is no baseline available to discuss and compare. For sure, solutions will be a combination of connected capabilities based on model-driven paradigms. It will take time to develop and understand the benefits.
• Model-Based approaches are not just a marketing invention, as some disbelievers suggest. In particular, in Asia, where people deal with less legacy (and skepticism) than our western engineering/manufacturing world, companies embrace these concepts faster. One more time, if you didn’t look at Zhang Xin Guo’s keynote speech at the Incose annual symposium last year, watch the speech below and learn to understand the needed paradigm change. Is it a coincidence that a Chinese speaker gives the best explanation so far?

Technology hype?

The (Industrial) Internet of Things, Machine Learning, Artificial Intelligence, Augmented reality, Virtual Reality, and Digit Twin appear in the news. But, most of the time, they are associated with tremendous opportunities, changing business models and potentially high profits. For example, read this quote from Jim Heppelmann after the acquisition of Frustum:

“PTC is pushing the boundaries of innovation with this acquisition,” said Jim Heppelmann, president and CEO, PTC. “Creo is core to PTC’s overall strategy, and the embedded capabilities from ANSYS and, later, Frustum will elevate Creo to a leading position in the world of design and simulation. With breakthrough new technologies such as AR/VR, high-performance computing, IoT, AI, and additive manufacturing entering the picture, the CAD industry is going through a renaissance period, and PTC is committed to leading the way.”

Of course, vendors have to sell their capabilities; the major challenge for companies is to make a valuable business from all these capabilities (if possible). In that context, I was happy to read one of Joe Barkai’s recent posts: When the Party is Over — Industrial Internet of Things Industry Snapshot and Predictions, where he puts the IIoT hype in a business perspective.

Can technology change business?

If you look back over the past 50 years, various changes in technology have affected the world of PLM. Assuming the current definition of PLM could exist in 1970 even without a PLM system – PLM was invented in 1999. First, there was the journey from drawing boards to electronic drawings and 3D models. Next global connectivity and an affordable infrastructure boosted product development collaboration. Still, many organizations work in a silo-ed way, inside the organization and outside with their suppliers. Still, the 2D Drawing is the legal information carrier combined with additional specification documents. Changing the paradigm to a connected 3D Model is already possible, however not pushed or implemented by manufacturing companies as it requires a change in ways of working (people) and related processes.

A business change has to come from the top of an organization, which is the challenge for PLM. What is the value of collaboration? How do you measure innovation capabilities? How do you impact time to market?

Time to market might be understood at the board level. There is an existing NPI (New Product Introduction) process in place, and by analyzing the process, fixing bottlenecks, an efficiency gain can be achieved. Every innovation goes through the same process. This is where traditional PLM plays a significant role as it is partly measurable.

But how to improve collaboration or innovation speed?

At the board level, often numbers rule and based on numbers, decisions are taken. This mindset often leads to narrow thinking. Adjustments are made by prioritizing one topic above the other. Complex topics like the needed change of business and business models are not really understood and passed to the middle management (who will kill it to guarantee the status quo).

Organizations need a myth!

One of the significant challenges for PLM is that there is no end-to-end belief in its purpose. According to Yuval Noah Harari in his book Sapiens, the primary success factor why homo sapiens became the dominant species on earth is because they can collaborate in large groups driven by abstract themes. It can be religion. A lot is done on behalf of faith. It can also be a charismatic CEO who can create the myth – think about Steve Jobs, Elon Musk.

Organizations that want to go through a digital transformation need to create their myth and deliver product/business innovation through new ways of working should be part of that. I wrote about myths in the context of PLM in the past: PLM as a myth? . I believe the domain of PLM is too small for a myth still. However, it is a crucial part of digital transformation.

In the upcoming year, I will focus again on how organizations can benefit from new technologies. But, again, not focusing on WHAT is possible, but mainly on WHY and HOW – all based on the myth that we can do so much better as organizations when innovation and customer focus are part of everyone’s empowered mind.

I am looking forward to meeting in face-to-face discussions, Skype calls, or during events and conferences.
Let’s understand and create the myth together – first in London.