In my series describing the best practices related to a (PLM) data model, I described the general principles, the need for products and parts, the relation between CAD documents and the EBOM, the topic of classification and now the sensitive relation between EBOM and MBOM.

First some statements to set the scene:

  • The EBOM represents the engineering (design) view of a product, structured in a way that it represents the multidisciplinary view of the functional definition of the product. The EBOM combined with its related specification documents, models, drawings, annotations should give a 100 % clear definition of the product.
  • The MBOM represents the manufacturing view of a product, structured in a way that represents the way the product is manufactured. This structure is most of the time not the same as the EBOM, due to the manufacturing process and purchasing of parts.


A (very) simplified picture illustrating the difference between an EBOM and a MBOM. If the Car was a diesel there would be also embedded software in both BOMs (currently hidden)

For many years, the ERP systems have claimed ownership of the MBOM for two reasons

  1. Historically the MBOM was the starting point for production. Where the engineering department often worked with a set of tools, the ERP system was the system where data was connected and used to have a manufacturing plan and real-time execution
  2. To accommodate a more advanced integration with PDM systems, ERP vendors began to offer an EBOM capability also in their system as PDM systems often worked around the EBOM.

These two approaches made it hard to implement “real” PLM where (BOM) data is flowing through an organization instead of stored in a single system.

By claiming ownership of the BOM by ERP, some problems came up:

  • A disconnect between the iterative engineering domain and the execution driven ERP domain. The EBOM is under continuous change (unless you have a simple or the ultimate product) and these changes are all related to upstream information, specifications, requirements, engineering changes and design changes. An ERP system is not intended for handling iterative processes, therefore forcing the user to work in a complex environment or trying to fix the issue through heavy customization on the ERP side.
  • Global manufacturing and outsourced manufacturing introduced a new challenge for ERP-centric implementations. This would require all manufacturing sites also the outsourced manufacturers the same capabilities to transfer an EBOM into a local MBOM. And how do you capitalize the IP from your products when information is handled in a dispersed environment?

The solution to this problem is to extend your PDM implementation towards a “real” PLM implementation providing the support for EBOM, MBOM, and potential plant specific MBOM. All in a single system / user-experience designed to manage change and to allow all users to work in a global collaborative way around the product. MBOM information then will then be pushed when needed to the (local) ERP system, managing the execution.

Note 1: Pushing the MBOM to ERP does not mean a one-time big bang. When manufacturing parts are defined and sourced, there will already be a part definition in the ERP system too, as logistical information must come from ERP. The final push to ERP is, therefore, more a release to ERP combined with execution information (when / related to which order).

In this scenario, the MBOM will be already in ERP containing engineering data complemented with manufacturing data. Therefore from the PLM side we talk more about sharing BOM information instead of owning. Certain disciplines have the responsibility for particular properties of the BOM, but no single ownership.

Note 2: The whole concept of EBOM and MBOM makes only sense if you have to deliver repetitive products. For a one-off product, more a project, the engineering process will have the manufacturing already in mind. No need for a transition between EBOM and MBOM, it would only slow down the delivery.

Now let´s look at some EBOM-MBOM specifics

EBOM phantom assemblies

PhantomWhen extracting an EBOM directly from a 3D CAD structure, there might be subassemblies in the EBOM due to a logical grouping of certain items. You do not want to see these phantom assemblies in the MBOM as they only complicate the structuring of the MBOM or lead to phantom activities. In an EBOM-MBOM transition these phantom assemblies should disappear and the underlying end items should be linked to the higher level.

EBOM materials

In the EBOM, there might be materials like a rubber tube with a certain length, a strip with a certain length, etc. These materials cannot be purchased in these exact dimensions. Part of the EBOM to MBOM transition is to translate these EBOM items (specifying the exact material) into purchasable MBOM items combined with a fitting operation.

EBOM end-items (make)

For make end-items, there are usually approved manufacturers defined and it is desirable to have multiple manufacturers (certified through the AML) for make end-items, depending on cost, capacity and where the product needs to be manufactured. Therefore, a make end-item in the EBOM will not appear in a resolved MBOM.

EBOM end-items (buy)

For buy end-items, there is usually a combination of approved manufacturers (AML) combined with approved vendors (AVL). The approved manufacturers are defined by engineering, based on part specifications. Approved vendors are defined by manufacturing combined with purchasing based on the approved manufacturers and logistical or commercial conditions

Are EBOM items and MBOM items different?

MBOM-MOBMThere is a debate if EBOM items should/could appear in an MBOM or that EBOM items are only in the EBOM and connected to resolved items in the MBOM. Based on the previous descriptions of the various EBOM items, you can conclude that a resolved MBOM does not contain EBOM items anymore in case of multiple sourcing. Only when you have a single manufacturer for an EBOM item, the EBOM item could appear in the MBOM. Perhaps this is current in your company, but will this stay the same in the future?

It is up to your business process and type of product which direction you choose. Coming back to one-off products, here is does not make sense to have multiple manufacturers. In that case, you will see that the EBOM item behaves at the same time as an MBOM item.

What about part numbering?

clip_image011Luckily I reached the 1000 words so let´s be short on this debate. In case you want an automated flow of information between PLM and ERP, it is important that shared data is connected through a unique identifier.

Automation does no need intelligent numbering. Therefore giving parts in the PLM system and the ERP system a unique, meaningless number you ensure guaranteed digital connectivity.

If you want to have additional attributes on the PLM or ERP side that describe the part with a number relevant for human identification on the engineering side or later at the manufacturing side (labeling), this all can be solved.

An interesting result of this approach is that a revision of a part is no longer visible on the ERP side (unless you insist). Each version of the MBOM parts is pointing to a unique version of an MBOM part in ERP, providing an error free sharing of data.


Life can be simple if you generalize and if there was no past, no legacy and no ownership of data thinking. The transition of EBOM to MBOM is the crucial point where the real PLM vision is applied. If there is no data sharing on MBOM level, there are two silos, the characteristic of the old linear past.

(See also: From a linear world to a circular and fast)

What do you think? Is more complexity needed?



I will be soon discussing these topics at the PDT2015 in Stockholm on October 13-14. Will you be there ?

And for Dutch/Belgium readers – October 8th in Bunnik:


Op 8 oktober ben ik op het BIM Open 2015 Congres in Bunnik waar ik de overeenkomsten tussen PLM en BIM zal bespreken en wat de constructie industrie kan leren van PLM

linkedinThis is a post I published on LinkedIn on July 28th related to a discussion around Excel and PLM usage and usability.
Reposted for my blog subscribers.


This post is written in the context of two posts that recently caught my attention. One post from Lionel Grealou – comparing PLM and Excel collaboration and reaction on this post and its comments by Oleg Shilovitsky – PLM Need for speed.

Both posts discuss the difference between Excel (easy to use / easy to deploy ) and a PLM system (complex to use / complicated deployment). And when you read both posts you would believe that it is mainly deployment and usability that are blocking PLM systems to be used instead of Excel.

Then I realized this cannot be the case. If usability and deployment were blocking issues for an enterprise system, how would it be possible that the most infamous system for usability, SAP, it one of the top-selling enterprise applications. Probably SAP is the best-selling enterprise application. In addition, I have never heard about any company mentioning SAP is easy to deploy. So what is the difference?

I assume if Excel had existed in its current state in the early days of MRP, people might be tempted to use Excel for some ERP functions. However they would soon realize that Excel is error prone and when you buy the wrong materials or when make errors in your resource scheduling, soon you would try to solve it in a more secure way. Using an ERP system.

ERP systems have never been sold to the users for their usability. It is more that the management is looking for guarantees that the execution process is under control. Minimize the potential for errors and try to automate all activities as much as possible. As the production process is directly linked to finance, it is crucial to have it under control. Goodbye usability, safety first.

Why is this approach not accepted for PLM?
Why do we talk about usability?

First of all, the roots for PLM come from the engineering department (PDM) and, therefore, their primary data management system was not considered an enterprise system. And when you implement a system for a department, discussions will be at the user level. So user acceptance became necessary for PDM and PLM.

But this is not the main reason. Innovation, Product Development, Sales Engineering, Engineering are all iterative activities. In contrary to ERP, there is no linear process defined how to develop the ultimate product the first time right. Although this believe existed in the nineties by an ERP country manager that I met that time. He told me

“Engineers are resources that do not want to be managed, but we will get them.”

An absurd statement I hope you agree. However, the thoughts behind this statement are correct. How do you make sure product development is done in the most efficient manner?

If you look at large enterprises in the aerospace or automotive industry, they implemented PLM, which for sure was not user-friendly. Why did they implement PLM? As they did not want to fix the errors, an Excel-like implementation would bring.

Using Excel has a lot of hidden costs. How to make sure you work with the right version as multiple copies exist? How do you know if the Excel does not contain any type indicating wrong parts? You will learn this only once it is too late. How do you understand the related information to the Excel (CAD files, specifications, etc., etc.)? All lead to a lot of extra manual work depending on the accuracy and discipline of every employee in the company. Large enterprises do not want to be dependent on individual skills.

Large enterprise have shown that it is not about usability in the first place if you wish to control the data. Like for ERP systems, they are aware of the need for PLM with reduced usability above being (fl)Exel with all its related inconvenience.

I believe when there is a discussion about PLM or Excel, we have not reached the needed conceptual level to implement PLM. PLM is about sharing data and breaking down silos. Sharing allows better and faster collaboration, maintaining quality, and this is what companies want to achieve. Therefore the title: How do you measure collaboration. This is the process you wish to optimize, and I suspect that when you would compare user-friendly collaboration with Excel with less user-friendly PLM, you might discover PLM is more efficient.

Therefore stop comparing Excel and PLM. It is all about enabling collaboration and changing people to work together (the biggest challenge – more than usability).

Conclusion: Once we have agreed on that concept, PLM value is about collaboration, there is always to hope to enhance usability. Even SAP is working on that – it is an enterprise software issue.

classificationIn my previous post describing the various facets of the EBOM, I mentioned several times classification as an important topic related to the PLM data model. Classification is crucial to support people to reuse information and, in addition, there are business processes that are only relevant for a particular class of information, so it is not only related to search/reuse support.

In 2008, I wrote a post about classification, you can read it here. Meanwhile, the world has moved on, and I believe more modern classification methods exist.

Why classification ?

searchFirst of all classification is used to structure information and to support retrieval of the information at a later moment, either for reuse or for reference later in the product lifecycle. Related to reuse, companies can save significant money when parts are reused. It is not only the design time or sourcing time that is reduced. Additional benefits are lower risks for errors (fewer discoveries), reduced process and approval time (human overhead), reduced stock (if applicable), and more volume discount (if applicable) and reduced End-Of-Life handling.

An interesting discussion about reuse started by Joe Barkai can also be found on LinkedIn here, including interesting comments

Classification can also be used to control access to certain information (mainly document classification), or classification can be used to make sure certain processes are followed, e.g. export control, hazardous materials, budget approvals, etc. Although I will speak mainly about part classification in this post, classification can be used for any type of information in the PLM data model.

Classification standards

din4000Depending on the industry you are working in, there are various classification standards for parts. When I worked in the German-speaking countries (the DACH-länder) the most discussed classification at that time was DIN4000 (Sachmerkmal-liste), a must have standard for many of the small and medium sized manufacturing companies. The DIN 4000 standard had a predefined part hierarchy and did not describe the necessary properties per class. I haven’t met a similar standard in other countries at that time.

Another very generic classification I have seen are the UNSPC standard, again a hierarchical classification supporting everything in the universe but no definition of attributes.

15926Other classification standards like ISO13399, RosettaNET, ISO15926 and IFC exist to support collaboration and/or the supply chain. When you want to exchange data with other disciplines or partners. The advantage of a standard definition (with attributes) is that you can exchange data with less human processing (saving labor costs and time – the benefit of a digital enterprise).

I will not go deeper into the various standards here as I am not the expert for all the standards. Every industry has its own classification standards, a hierarchical standard, and if more advanced the hierarchy is also supported by attributes related to each class. But let´s go into the data model part.

Classification and data model

clip_image002The first lesson I learned when implementing PLM was that you should not build your classification hard-coded into the PLM, data model. When working with SmarTeam is was very easy to define part classes and attributes to inherit. Some customers had more than 300 classes represented in their data model just for parts. You can imagine that it looks nice in a demo. However when it comes to reality, a hard-coded classification becomes a pain in the model. (left image, one of the bad examples from the past)

1 – First of all, classification should be dynamic, easy to extend.

2 – The second problem however with a hard-coded classification was that once a part is defined for the first time the information object has a fixed class. Later changes need a lot of work (relinking of information / approval processes for the new information).

3 – Finally, the third point against a hard-coded classification is that it is likely that parts will be classified according to different classifications at the same time. The image bellow shows such a multiple classification.


So the best approach is to have a generic part definition in your data model and perhaps a few subtypes. Companies tend to differentiate still between hardware (mechanical / electrical) parts and software parts.

Next a part should be assigned at least to one class, and the assignment to this class would bring more attributes to the part. Most of the PLM systems that support classification have the ability to navigate through a class hierarchy and find similar parts.

When parts are relevant for ERP they might belong to a manufacturing parts class, which add particular attributes required for a smooth PLM – ERP link. Manufacturing part types can be used as templates for ERP to be completed.

This concept is also shared by Ed Lopategui as commented to my earlier post about EBOM Part types. Ed states:

Think part of the challenge moving forward is we’ve always handled these as parts under different methodologies, which requires specific data structures for each, etc. The next gen take on all this needs to be more malleable perhaps. So there are just parts. Be they service or make/buy or some combination – say a long lead functional standard part and they would acquire the properties, synchronizations, and behaviors accordingly. People have trouble picking the right bucket, and sometimes the buckets change. Let the infrastructure do the work. That would help the burden of multiple transitions, where CAD BOM to EBOM to MBOM to SBOM eventually ends up in a chain of confusion.

I fully agree with his statement and consider this as the future trend of modern PLM: Shared data that will be enriched by different usage through the lifecycle.

Why don’t we classify all data in PLM?

There are two challenges for classification in general.

  • The first one is that the value of classification only becomes visible in the long-term, and I have seen several young companies that were only focusing on engineering. No metadata in the file properties, no part-centric data management structure and several years later they face the lack of visibility what has been done in the past. Only if one of the engineers remembers a similar situation, there is a chance of reuse.
  • The second challenge is that through a merger or acquisition suddenly the company has to manage two classifications. If the data model was clean (no hard-coded subclasses) there is hope to merge the information together. Otherwise, it might become a painful activity to discover similarities.


Modern search based applications

There are ways to improve classification and reuse by using search-based application which can index archives and try to find similarity in properties / attributes. Again if the engineers never filled the properties in the CAD model, there is little to nothing to recover as I experienced in a customer situation. My PLM US peer, Dick Bourke, wrote several articles about search-based applications and classification for, which are interesting to read if you want to learn more: Useful Search Applications for Finding Engineering Data

So much to discuss on this topic, however I reached my 1000 words again Sad smile


Classification brings benefits for reuse and discovery of information although benefits are long-term. Think long-term too when you define classifications. Keep the data model simple and add attributes groups to parts based on functional classifications. This enables a data-driven PLM implementation where the power is in the attributes not longer in the part number. In the future, search-based applications will offer a quick start to classify and structure data.


imageSomeone notified me that not everyone subscribed to my blog necessary will read my posts on LinkedIn. Therefore I will repost the upcoming weeks some of my more business oriented posts from LinkedIn here too. This post was from July 3rd and an introduction to all the methodology post I am currently publishing.


The importance of a (PLM) data model

thinkWhat makes it so hard to implement PLM in a correct manner and why is this often a mission impossible? I have been asking myself this question the past ten years again and again. For sure a lot has to do with the culture and legacy every organization has. Imagine if a company could start from scratch with PLM. How would they implement PLM nowadays?

My conclusion for both situations is that it all leads to a correct (PLM) data model, allowing companies to store their data in an object-oriented manner. In this way reflecting the behavior the information objects have and the way they mature through their information lifecycle. If you making compromises here, it has an effect on your implementation, the way processes are supported out-of-the-box by a PLM system or how information can be shared with other enterprise systems, in particular, ERP. PLM is written between parenthesis as I believe in the future we do not talk PLM or ERP separate anymore – we will talk business.

Let me illustrate this academic statement.

A mid-market example

imageWhen I worked with SmarTeam in the nineties, the system was designed more as a PDM system than a PLM system. The principal objects were Projects, Documents, and Items. The Documents had a sub-grouping in Office documents and CAD documents. And the system had a single lifecycle which was very basic and designed for documents. Thanks to the flexibility of the system you could quickly implement a satisfactory environment for the engineering department. Problems (and customizations) came when you wanted to connect the data to the other departments in the company.

The sales and marketing department defines and sells products. Products were not part of the initial data model, so people misused the Project object for that. To connect to manufacturing a BOM (Bill of Material) was needed. As the connected 3D CAD system generated a structure while saving the assemblies, people start to consider this structure as the EBOM. This might work if your projects are mechanical only.

However, a Document is not the same as a Part. A Document has a complete different behavior as a Part. Documents have continuous iterations, with a check-in/checkout mechanism, where the Part definition remains unchanged and gets meanwhile a higher maturity.

The correct approach is to have the EBOM Part structure, where Part connect to the Documents. And yes, Documents can also have a structure, but it is not a BOM. SmarTeam implemented this around 2004. Meanwhile, a lot of companies had implemented their custom solution for EBOM by customization not matching this approach. This created a first level of legacy.

When SmarTeam implemented Part behavior, it became possible to create a multidisciplinary EBOM, and the next logical step was, of course, to connect the data to the ERP system. At that time, most implementations have been pushing the EBOM to the ERP system and let it live there further. ERP was the enterprise tool, SmarTeam the engineering tool. The information became disconnected in an IT-manner. Applying changes and defining a manufacturing BOM was done manually in the ERP system and could be done by (experienced) people that do not make mistakes.

Next challenge comes when you want to automate the connection to ERP. In that case, it became apparent that the EBOM and MBOM should reside in the same system. (See old and still actual post with comments here: Where is the MBOM) In one system to manage changes and to be able to implement these changes quickly without too much human intervention. And as the EBOM is usually created in the PLM system, the (commercial/emotional) PLM-ERP battle started. “Who owns the part definition”, “Who owns the MBOM definition” became the topic of many PLM implementations. The real questions should be: “Who is responsible for which attributes of the Part ?” and “Who is responsible for which part of the MBOM definition ?” as data should be shared not owned.

The SmarTeam evolution shows how a changing scope and an incomplete/incorrect data model leads to costly rework when aligning to the mainstream. And this is happening with many implementation and other PLM systems. In particular when the path is to grow from PDM to PLM. An important question remains what is going to be mainstream in the future. More on that in my conclusion.

A complex enterprise example

flexibleIn the recent years, I have been involved in several PLM discussions with large enterprises. These enterprises suffer from their legacy. Often the original data management was not defined in an object-oriented manner, and the implementation has been expanding with connected and disconnected systems like a big spaghetti bowl.

The main message most of the time is:

“Don’t touch the systems it as it works for us”.

The underlying message is;

“We would love to change to a modern approach, but we understand it will be a painful exercise and how will it impact profitability and execution of our company”

The challenge these companies have is that it extremely hard to imagine the potential to-be situation and how it is affected by the legacy. In a project that I participated several years ago the company was migrating from a mainframe database towards a standard object-oriented (PLM) data model. The biggest pain was in mapping data towards the object-oriented data model. As the original mainframe database had all kind of tables with flags and mixed Part & Document data, it was almost impossible to make a 100 % conversion. The other challenge was that knowledge of the old system had vaporized. The result at the end was a customized PLM data model, closer to current reality, still containing legacy “tricks” to assure compatibility.

All these enterprises at a particular time have to go through such a painful exercise. When is the best moment? When business is booming, nobody wants to slow-down. When business is in a lower gear, costs and investments are minimized to keep the old engine running efficiently. I believe the latter would be the best moment to invest in making the transition if you believe your business will still exist in 10 years from now.

Back to the data model.

Businesses should have today a high-level object-oriented data model, describing the main information objects and their behavior in your organization. The term Master Data Management is related to this. How many companies have the time and skills to implement a future-oriented data model? And the data model must stay flexible for the future.

knowledgeCompare it to your brain, which also stores information by its behavior and by learning the brain understands what it logically related. The internal data model gets enriched while we learn.

Once you have a business data model, you are able to implement processes on top of it. Processes can change over time, therefore, avoid hard-coding specific processes in your enterprise systems. Like the brain, we can change our behavior (applying new processes) still it will be based on the data model stored inside our brain.


A lot of enterprise PLM implementations are in a challenging situation due to legacy or incomplete understanding and availability of an enterprise data model. Therefore cross-department implementations and connecting others systems are considered as a battle between systems and their proprietary capabilities.


The future will be based on business platforms and realizing this take years – imagine openness and usage of data standards. An interesting conference to attend in the near future for this purpose is the PDT2015 conference in Stockholm.

Meanwhile I also learned that a  one-day Master Data Management workshop will be held before the PDT2015 conference starts on the 12th of October. A good opportunity to deep-dive for three days !



In my earlier posts, I described generic PLM data model and practices related to Products, BOMs en recently EBOM and (CAD) Documents. This time I want to elaborate a little bit more on the various EBOM characteristics.


The EBOM is the place where engineering teams collaborate and define the product. A released EBOM is supposed to give the full engineering specification how a product should behave including material quality and tolerances. This makes it different from the MBOM, which contains the specification of how this product should be manufactured based on exact components and materials.

Depending on the type of product there are several EBOM best practices which I will discuss here (briefly) in alphabetical order:

EBOM & Buy Part

PDM_ERP_AML_AVLUsually, an EBOM consists of Make and Buy parts –an attribute on the EBOM part indicates the preferred approach. Make parts are typically sourced towards qualified suppliers, where Buy parts can be more generic and based on qualified vendors. Engineering specifies who are the approved Manufacturers for the part (AML) and purchasing decides who are the approved Vendors for this part (AVL). In general Buy parts do not need an engineering efforts every time the part is used in a product.

EBOM & CAD related

My previous post already discussed some of the points related to EBOM and CAD Documents. Here I want to extend a little more addressing the close relation between MCAD parts and EBOM parts. In particular in the Engineering To Order industry, there is, most of the time, no standard product to relate to. In that case, Mechanical CAD can be the driver for the EBOM definition and usually EBOM Make parts are designed uniquely. The challenge is to understand similar parts that might exist and reuse them. Classification (and old post here) and geometric search capabilities support the modern engineer. I will come back to classification in a later post

EBOM – Configuration Item

cmiiIn case a product is designed for mass production throughout a longer lifetime, it becomes necessary to manage the product configuration over time. How is the product is defined today and avoid the need to have for each product variant a complete EBOM to manage. The EBOM can be structured with Options and Variants. In that case, having Configuration Items in the EBOM is crucial. The Configuration Item is the top part that is versioned and controlled. Parts below the configuration item, mostly standard parts do not impact the version of the Configuration Item as long as the Form-Fit-Function from the Configuration Item does not change. Configuration Management is a topic on its own and some people believe PLM systems were invented to support Configuration Management.

EBOM – Company Standard Part

Standard Parts are often designed parts that should be used across various products or product lines. The advantage of company standard parts is that it reduces costs throughout the whole product lifecycle. Less design time, less manufacturing setup time and material sourcing effort and potential lower material cost thanks to higher volumes. Any EBOM part could become at a certain moment a Company Standard part and it is recommended to use a classification related to these parts. Otherwise they will not be found again. As mentioned before I will come back to classification.

EBOM – Functional group

Sometimes during the design of a product, several parts are logically grouped together from the design point of view, either because they are modular or because they always appear as a group of parts.

The EBOM, in that case, can contain phantom parts, which do not represent an end item. These phantom parts assist the company in understanding changing one of the individual parts in this functional group.

EBOM – Long Lead

In typical Engineering to Order or Build To Order deliveries there are components on the critical path of the product delivery. Components with a long lead time should be identified and ordered as early as possible during the delivery process. Often the EBOM is not complete or mature enough to pass through all the information to ERP. Therefore Long Lead items require a fast track towards ERP and a special status in the EBOM reflecting its ordering status. Long Lead items are the example where a company can benefit from a precise interaction between PLM and ERP with various status handshakes and approvals during the delivery process

EBOM – Make parts

Make Parts in an EBOM are usually specified by their related model and drawings. Therefore Make Parts usually have revisions but be aware that they do not follow the same versioning of the related model or drawing. A Make Part is in an In Work status as long as the EBOM is not released. Once the model is approved, the EBOM part can be approved or released. Often companies do not want to release the data as long as manufacturing is not completed. This to make sure that the first revision comes out at the first delivery of the product.

EBOM – Materials

In many mechanical assemblies, the designer specifies materials with a particular length. For example a rubber strip, tubing / piping. When extracting the information from the 3D CAD assembly, this material instance will get a unique identifier. Here it is important that the Material Part has an attribute that describes the material specification. In the ideal data model, this is a reference to a Materials library. Next when manufacturing engineering is defining the MBOM, they can decide on material quantities to purchase for the EBOM Material.

EBOM – Part Number

QRThis could be a post on its own. Do we need intelligent part numbers or can we use random generated unique numbers? I have a black and white opinion about that. If you want to achieve a digital enterprise you should aim for random generated unique numbers. This because in a digital enterprise data is connected without human transfer. The PLM and ERP link is unambiguous. Part recognition at the shop floor can be done with labels and scanning at the workstation. There is no need for a person to remember or transfer information from one system or location by understanding the part number. The uniquely generated number make sure every person will have a look at the digital metadata online available. Therefore immediately seeing a potential status change or upcoming engineering change. Supporting the intelligent numbering approach allows people to work disconnected again, therefore not guaranteeing that an error-free activity takes place. People make mistakes, machines usually not.

EBOM – Service Parts

It is important to identify already in the EBOM which parts need to be serviced in operation and engineering should relate the service information already to the EBOM part. This could be the same single part with a different packaging or it could be a service kit plus instructions linked to the part. In a PLM environment, it is important that this activity is done upfront by engineering to avoid later retrieval of the data and work again on service information. A sensitive point here is that engineers currently in the classical approach are not measured on the benefits they deliver downstream when the products are in the field. Too many companies work here in silos.

EBOM – Standard Parts

3dFinally, as I reach already the 1000 words, a short statement about EBOM standard parts. These standard parts, based on international or commercial standards do not need a revision and often they have a specification sheet, not necessary a 3D model for visualization. Classification is crucial for Standard Part and here I will write a separate post about dealing with Standard Parts, both mechanical and electrical.

Concluding: this post we can see that the EBOM is having many facets and based on the type of EBOM part different behavior is expected. It made me realize PLM is not that simple as I thought. In general when defining an EBOM data model you would try to minimize the specific classes for the EBOM part. Where possible, solve it with attributes (Make/Buy – Long Lead – Service – etc.). Use classification to store specific attributes per part type related to the part. Classification will be my next topic as it appears

Feel free to jump on any of the EBOM characteristics for an extended discussion

note: images borrowed from the internet contain links to the original location where I found them. The context there is not always relevant for this post.

In my series of blog posts related to the (PLM) data model, I talked about Product, BOMs and Parts. This time I want to focus on the EBOM and (CAD) Documents relation. This topic became relevant with the introduction of 3D CAD.

Before companies were using 3D CAD systems, there was no discussion about EBOM or MBOM (to my knowledge). Engineering was producing drawings for manufacturing and not every company was using the mono-system (for each individual part a specifying drawing). Drawings were mainly made to assist production and making a drawing for an individual part was a waste of engineering time. Parametric drawings were used to specify similar parts. But now we are in the world of 3D!

imageWith the introduction of 3D CAD systems for the mainstream in the nineties (SolidWorks, Solid Edge, Inventor) there came a need for PDM systems managing the individual files from a CAD assembly. The PDM system was necessary to manage all the file versions. Companies that were designing simple products sometimes remained working file-based, introducing the complexity of how to name a file and how to deal with revisions. Ten years ago I was investigating data management for the lower tiers of the automotive supply chain. At that time still 60 % of the suppliers were using CATIA were working file-based. Data management was considered as an extra complexity still file version control was a big pain.

This has changed for several reasons:

  • More and more OEMs were pushing for more quality control of the design data (read PDM)
  • Products became more modular, which means assemblies can be used as subassemblies in other products, pushing the need for where used control
  • Products are becoming more complex and managing only mechanical CAD files is not enough anymore – Electronics & Software – mechatronics – became part of the product

Most PDM systems at that time (I worked with SmarTeam) were saving the 3D CAD structure as a quantity-based document structure, resembling a lot a structure called the EBOM.

CAD DOC structure


This is one of the most common mistakes made in PLM implementations.

The CAD structure does not represent the EBOM !!!

Implementers started to build all kind of customizations to create automatically from the CAD structure a Part structure, the EBOM. Usually these customizations ended up as a mission impossible, in particular when customers started to ask for bidirectional synchronization. They expected that when a Part is removed in the EBOM, it would be deleted in the CAD assembly too.

And then there was the issue that companies believed the CAD Part ID should be equal to the Part ID. This might be possible for a particular type of design parts, but does not function anymore with flexible parts, such as a tube or a spring. When this Part is modeled in a different position, it created a different CAD Document, breaking the one-to-one relation.

Finally another common mistake that I have seen in many PDM implementations is the addition of glue, paint and other manufacturing type of parts to the CAD model, to be able to generate a BOM directly from the CAD.

imageFrom the data model perspective it is more important to understand that Parts and CAD documents are different type of objects. In particular if you want to build a PLM implementation where data is shared across all disciplines. For a PDM implementation I care less about the data model as the implementation is often not targeting enterprise continuity of data but only engineering needs.

A CAD Document (Assembly / Part / Drawing / …) behaves like a Document. It can be checked-in and checked out any time a change is made inside the file. A check-in operation would create a new version of the CAD Document (in case you want to trace the history of changes).

Meanwhile the Part specified by the CAD Document does not change in version when the CAD Document is changed. Parts usually do not have versions; they remain in the same revision as long as the specifying CAD Document matures.

Moving from PDM to PLM

For a PLM implementation it is important to think “Part-driven” which means from an initial EBOM, representing the engineering specification of the Product, maturing the EBOM with more and more design specification data. Design specification data can be mechanical assemblies and parts, but also electrical parts. The EBOM from a PCB might come from the Electrical Design Application as in the mechanical model you will not create every component in 3D.

And once the Electrical components are part of the EBOM, also the part definition of embedded software can be added to the BOM. For example if software is needed uploaded in flash memory chips. By adding electrical and software components to the EBOM, the company gets a full overview of the design maturity of ALL disciplines involved.

The diagram below shows how an EBOM and its related Documents could look like:


This data model contains a lot of details:

  • As discussed in my previous post – for the outside world (the customer) there is a product defined without revision
  • Related to the Product there is an EBOM (Part assembly) simplified as a housing (a mechanical assembly), a connector (a mechanical art) and a PCB (a mechanical representation). All these parts behave like Mechanical Parts; they have a revision and status.
  • The PCB has a second representation based on an electrical schema, which has only (for simplification) two electrical parts, a resistor and a memory chip. As you can see these components are standard purchasable parts, they do not have a revision as they are not designed.
  • The Electrical Part Flash Memory has a relation to a Software Part which is defined by Object Code (a zip-file?) which of course is specified by a software specification (not in the diagram). The software object code has a version, as most of the time software is version managed, as it does not follow the classical rules of mechanical design.

Again I reached my 1000 words, a sign to stop explaining this topic. For sure there are a lot of details to explain to this data model part too.

Most important:

  • A CAD structure is not an EBOM (it can be used to generate a part of the EBOM)
  • CAD documents and EBOM parts have a different behavior. CAD documents have versions, Parts do not have versions (most of the time
  • The EBOM is the place where all disciplines synchronize their data, providing during the development phase a single view of the design status.

Let me know if this was to abstract and feel free to ask questions. Important for this series of blog post is to provide a methodology baseline for a real PLM data model.

I am looking forward to your questions or remarks to spark up the discussion.


As described in my latest LinkedIn post if you want to install PLM successful there are two important points to address from the implementation point of view:

  • An explicit data model not based on system or tools capabilities, but on the type of business the company is performing. There is a difference in an engineering to order company, a built to order company or a configure to order company.
  • In PLM (and Business) it is all about enabling an efficient data flow through the organization. There is no ownership of data. It is about responsibilities for particular content per lifecycle stage combined with sharing

Historically PLM implementations started with capturing the CAD data and related EBOM as this is what the CAD-related PLM vendors were pushing for and this was often for the engineering department the biggest pain. The disadvantage of this approach is that it strengthens the silo-thinking process. The PLM system becomes an engineering tool instead of an enterprise system.

I believe if you really want to be able to implement PLM successful in a company, start from a common product/part information backbone. This requires the right business objects and, therefore, the right data modeling. The methodology described below is valid for build to order and configure to order companies, less applicable for engineering to order.


In a build to order company there are the following primary information objects:

  • A Product ( representing the customer view of what is sold to the outside world)
  • An EBOM ( representing a composition of Parts specifying the Product at a particular time)
  • An MBOM (representing the manufacturing composition of the Product at a given time)

And, of course, there are for all the information objects related Documents. Various types and when you can work more advanced, the specification document, can be the source for individually extracted requirements (not in this post)

Let´s follow an End to End scenario from a typical Build to Order company process.

Quoting phase

A potential customer sends an RFP for a product they need. The customer RFP contains information about how the product should behave (Specification / Requirements) and how it should be delivered (packaging). A basic data model for this RFP would be:


Note the following details:

  • All information objects have a meaningless number. The number is only there to support unique identification and later integration with other systems. The meaning should come from the other attribute data on the object and its relations. (A blog post on its own)
  • The Product can have instead of the meaningless number the number provided by the customer. However, if this number is not unique to the company, it might be just another attribute of the product
  • In general Products do not have revisions. In time, there might be other BOMs related to the product. Not in this post, products might have versions and variants. And products might be part of a product family. In this case, I used a classification to define a classification code for the product, allowing the company to discover similar products from different customers done. This to promote reuse of solutions and reuse of lessons learned.
  • The customer object represents the customer entity and by implementing it as a separate object, you will be able to see all information related to this customer quickly. This could be Products (ordered / in RFQ / etc.) but also other relevant information (Documents, Parts, …)
  • The initial conceptual BOM for the customer consists of two sub-BOMs. As the customer wants the products to be delivered in a 6-pack, a standard 6-pack EBOM is used. Note: the Status is Released and a new conceptual EBOM is defined as a placeholder for the BOM definition of the Product to design/deliver.
  • And for all the Parts in the conceptual EBOM there can be relations towards one or more documents. Usually, there is one specifying document (the CAD model) and multiple derived documents (Drawings, Illustrations, …)
  • Parts can have a revision in case the company wants to trace the evolution of a Part. Usually when Form-Fit-Function remains the same, we speak about a revision. Otherwise, the change will be a new part number. As more and more the managed information is no longer existing on the part number, companies might want to use a new part number at any change, storing in an attribute what its predecessor was.
  • Documents have versions and revisions. While people work on a document, every check-in / check-out moment can create a new version of the file(s), providing tractability between versions. Most of the time at the end there will be a first released version, which is related to the part specified.
  • Do not try to have the same ID and Revision for Parts and Documents. In the good old days of 2D drawings this worked, in the world of 3D CAD this is not sustainable. It leads to complexity for the user. Preferably the Part and the specifying Document should have different IDs and a different revision mechanism.

And the iterations go on:

Now let´s look at the final stage of the RFQ process. The customer has requested to deliver the same product also in single (luxury) packaging as this product will be used for service. Although it is exactly the same physical product to produce, the product ID should be different. If the customer wants unambiguous communication, they should also use a different product ID when ordering the product for service or for manufacturing. The data model for this situation will look as follows (assuming the definitions are done)


Note the following details:

  • The Part in the middle (with the red shadow) – PT000123 represents the same part for both, the product ordered for manufacturing, as well as the product ordered for service, making use of a single definition for both situations
  • The Part in the middle has now a large set of related documentation. Not only CAD data but also test information (how to test the product), compliance information and more.
  • The Part in the middle on its own also has a deeper EBOM structure which we will explore in an upcoming post.

I reached my 1000 words and do not want to write a book. So I will conclude this post. For experienced PLM implementers probably known information. For people entering the domain of PLM, either as a new student or coming from a more CAD/PDM background an interesting topic to follow. In the next post, I will continue towards the MBOM and ERP.

Let me know if this post is useful for you – and of course – enhancements or clarifications are always welcomed. Note: some of the functionality might not be possible in every PLM system depending on its origin and core data model


Two weeks ago I got this message from WordPress, reminding me that I started blogging about PLM on May 22nd in 2008. During some of my spare time during weekends, I began to read my old posts again and started to fix links that have been disappearing.

Initially when I started blogging, I wanted to educate mid-market companies about PLM. A sentence with a lot of ambiguities. How do you define the mid-market and how do you define PLM are already a good start for a boring discussion. And as I do not want to go into a discussion, here are my “definitions”

Warning: This is a long post, full of generalizations and a conclusion.

PLM and Mid-market

The mid-market companies can be characterized as having a low-level of staff for IT and strategic thinking. Mid-market companies are do-ers and most of the time they are good in their domain based on their IP and flexibility to deliver this to their customer base. I did not meet mid-market companies with a 5-year and beyond business vision. Mid-market companies buy systems. They bought an ERP system 25-30 years ago (the biggest trauma at that time). They renewed their ERP system for the Y2K problem/fear and they switched from drawing board towards a 2D CAD system. Later they bought a 3D CAD system, introducing the need for a PDM system to manage all data.

PLM is for me a vision, a business approach supported by an IT-infrastructure that allows companies to share and discover and connect product related information through the whole lifecycle. PLM enables companies to react earlier and better in the go-to-market process. Better by involving customer inputs and experience from the start in the concept and design phases. Earlier thanks to sharing and involving other disciplines/suppliers before crucial decisions are made, reducing the amount of iterations and the higher costs of late changes.

PLM_profSeven years ago I believed that a packaged solution, combined with a pre-configured environment and standard processes would be the answer for mid-market companies. The same thought currently PLM vendors have with a cloud-based solution. Take it, us it as it is and enjoy.

Here I have changed my opinion in the past seven years. Mid-market companies consider PLM as a more complex extension of PDM and still consider ERP (and what comes with that system) as the primary system in the enterprise. PLM in mid-market companies is often seen as an engineering tool.

LESSON 1 for me:
The benefits of PLM are not well-understood by the mid-market

To read more:

PLM for the mid-market – mission impossible?

PLM for the SMB – a process or culture change ?

Culture change in a mid-sized company – a management responsibility

Mid-market PLM – what did I learn in 2009 ?

Implementing PLM is a change not a tool

Mid-market deadlocks for PLM

Who decides for PLM in a mid-market company ?

More on: Who decides for PLM in a mid-market company ?

Globalization and Education

globalIn the past seven years, globalization became an important factor for all type of companies. Companies started offshoring labor intensive work to low-labor-cost countries introducing the need for sharing product data outside their local and controlled premises. Also, acquisitions by larger enterprises and by some of the dominant mid-market companies, these acquisitions introduced a new area of rethinking. Acquisitions introduced discussions about: what are real best practices for our organization? How can we remain flexible, meanwhile adapt and converge our business processes to be future ready?

Here I saw two major trends in the mid-market:

Lack of (PLM) Education

dummies_logoTo understand and implement the value of PLM, you need to have skills and understanding of more than just a vendor-specific PLM system. You need to understand the basics of change processes (Engineering Change Request, Engineering Change Order, Manufacturing Change Order and more). And you need to understand the characteristics of a CAD document structure, a (multidisciplinary) EBOM, the MBOM (generic and/or plant specific) and the related Bill of Processes. This education does not exist in many countries and people are (mis-)guided by their PLM/ERP vendor, explaining why their system is the only system that can do the job.

Interesting enough the most read posts on my blog are about the MBOM, the ETO, BTO and CTO processes. This illustrates there is a need for a proper, vendor-independent and global accepted terminology for PLM

Some educational posts:

Bill of Materials for Dummies – ETO  ranked #1

ECR/ECO for Dummies ranked #2

BOM for Dummies – CTO  ranked #4

BOM for Dummies: BOM and CAD  ranked #7

BOM for Dummies – BTO

Where does PLM start beyond document management ?

The dominance of ERP

swissAs ERP systems were introduced long before PLM (and PDM), these systems are often considered by the management of a mid-market company as the core. All the other tools should be (preferably) seen as an extension of ERP and if possible, let´s implement ERP vendor´s functionality to support PLM – the Swiss knife approach – one tool for everything. This approach is understandable as at the board level there are no PLM discussions. Companies want to keep their “Let´s do it”-spirit and not reshuffle or reorganize their company, according to modern insights of sharing. Strangely enough, you see in many businesses the initiative to standardize on a single ERP system first, instead of standardizing on a single PLM approach first. PLM can bring the global benefits of product portfolio management and IP-sharing, where ERP is much more about local execution.

PLM is not understood at the board level, still considered as a tool

Some post related to PLM and ERP

Where is the MBOM ?  ranked #3

Connecting PLM and ERP (post 1)(post 2)(post 3) ranked #8

Can ERP vendors do PLM ?

PLM and ERP – the culture change

PLM and ERP – continued

5 reasons not to implement PLM – Reason #3 We already have an ERP system

The human factor

whyworryA lot of the reasons why PLM has the challenge to become successful have to do with its broad scope. PLM has an unclear definition and most important, PLM forces people to share data and work outside their comfort zones. Nobody likes to share by default. Sharing makes day-to-day life more complicated, sharing might create visibility on what you actually contribute or fix. In many of my posts, I described these issues from various viewpoints: the human brain, the innovators dilemma, the way the older generation (my generation) is raised and used to work. Combined with the fact that many initial PLM/PDM implementations have created so many legacies, the need to change has become a risk. In the discussion and selection of PLM I have seen many times that in the end a company decides to keep the old status quo (with new tools) instead of really having the guts to move toward the future. Often this was a result of investors not understanding (and willing to see) the long term benefits of PLM.

PLM requires a long-term vision and understanding, which most of the time does not fit current executive understanding (lack of education/time to educate) and priority (shareholders)

Many recent posts are about the human factor:

The Innovator´s dilemma and PLM

Our brain blocks PLM acceptance

PLM and Blockers

The PLM paradox for 2015

PLM and Global Warming

Τα πάντα ρεί

PLM is doomed, unless ……

How to get users excited or more committed to a new PLM system?

The digital transformation

econimistThe final and most significant upcoming change is the fact that we are entering a complete new era: From linear and  predictable towards fast and iterative, meaning that classical ways we push products to the market will become obsolete. The traditional approach was based on lessons learned from mechanical products after the second world-war. Now through globalization and the importance of embedded software in our products, companies need to deliver and adapt products faster than the classical delivery process as their customers have higher expectations and a much larger range to choose from. The result from this global competitiveness is that companies will change from delivering products towards a more-and-more customer related business model (continuous upgrades/services). This requires companies to revisit their business and organization, which will be extremely difficult. Business wise and human change require new IT concepts – platform? / cloud services? / Big data?

Older enterprises, mid-market and large enterprises will be extremely challenged to make this change in the upcoming 10 years. It will be a matter of survival and I believe the Innovator´s Dilemma applies here the most.

The digital transformation is apparent as a trend for young companies and strategic consultants. This message is not yet understood at the board level of many businesses.


Some recent post related to this fast upcoming trend:

From a linear world to fast and circular ?

Did you notice PLM is changing?

Documents or Intelligent Data ?

The difference between files and data-oriented – a tutorial (part 1)(part 2)(part 3)

PLM is dead, long live …… ?

PLM, Soccer and game changing

PLM and/or SLM? – (part 1)(part 2)

Breaking down the silos with data

ROI (Return On Investment)

No_roiI also wrote about ROI – a difficult topic to address as in most discussions related to ROI, companies are talking about the costs of the implementation, not about the tremendous larger impact a new business approach or model can have, once enabled through PLM. Most PLM ROI discussions are related to efficiency and quality gains, which are significant and relevant. However these benefits are relative small and not comparable with the ability to change your business (model) to become more customer centric and stay in business.

Some of the ROI posts:

To PLM or Not to PLM – measuring the planning phase  ranked #5

Free PLM Software does not help companies  ranked #6

PLM: What is the target?

PLM selection–additional thoughts

PLM Selection: Proof Of Concept observations

Where is my PLM Return On Investment (ROI) ?

A PLM success story with ROI


A (too) long post this time however perhaps a good post to mark 7 years of blogging and use it as a reference for the topics I briefly touched here. PLM has many aspects. You can do the further reading through the links.

From the statistics it is clear that the education part scores the best – see rankings. For future post, let me know by creating a comment what you are looking for in this blog: PLM Mid-Market, Education, PLM and ERP, Business Change, ROI, Digitalization, or …??

Also I have to remain customer centric – thanks for reading and providing your feedback


Above Image courtesy of the – Tom Fishburne
Image related to digital transformation: The Economist – the onrushing wave

I was sitting outside in the garden during Ascension Day, which is (still) a national holiday in the Netherlands (Thanks God). It was again nice and warm, and it made me think about the parallels between Global warming and PLM.

whyworryClimate change has always been there if we look at the history of our planet. We started to talk about Global Warming when scientist indicated that this time the climate change is caused by human intervention. As a result of vast amounts of carbon dioxide emissions, a greenhouse effect started to become visible. When the first rumors came that global warming began to come up, environmentalists started preaching we have to act NOW before it is too late. Meanwhile at the other side, people began arguing that it was just a coincidence, an opinion.

There is no scientific proof, so why worry?

GlobalWarmingIn the past ten years, the signs and proofs of global warming have become evident and climate conferences filled with people who want to act and on the other side the blockers, try to create progress in the battle against global warming. In particular in Europe governments and companies are starting to become aware that they can contribute to a more sustainable society.

Not enough according to the environmentalists and scientists. As our brains still operate mostly in a prehistoric mode (day-to-day survival, food, home, social status), slow changes and sustainability for next generations are not part of most people concerns. And those people, who make us aware of this lack of priority for sustainability, are considered annoying as they disrupt our lives.

Companies that have invested (heavily) in sustainable business models often have a challenging path to survive against traditional businesses. As the majority of consumers wants cheap. Some examples:

  • Energy: most power plants are heated by burning coal as this is the cheapest option. Shale gas winning became attractive because we need cheap fuel. Alternatives like solar, wind and others cannot compete on price level as long as we do not pay for the damage to nature.
  • Food: produced in bio-farms, where animal wellness or health is not part of the plan. The goal is to deliver xx kilos of meat for the lowest price. Alternative like more natural ways of growing meat or even revolutionary ways (the grown hamburger) cannot compete on price currently unless we are willing to pay for it.
  • The Fashion industry where down in its supply chains human beings are treated like slaves. When you buy a cheap garment, you know somebody has been suffering.

Governments sometimes subsidize or push sustainable technologies as they realize that something has to happen (most of the time for the public opinion – their voters) but there is no consistent strategy as liberals believe every form of support is against open competition. And as long as we let our prehistoric brain run our choices, the earth gets warmer with the consequences being visible more and more.

We know we have to act, but we do not act seriously

Now let´s switch to PLM. The association started when I saw Chad Jackson’s retweet from Lifecycle insights related to top PLM challenges.


Clearly the message illustrates that costs, time, and technology have priority. Not about what PLM really can establish (even in the context of global warming).

PLM_profPLM started end of the previous century, initially invented by some of the major CAD vendors, Dassault Systemes, PTC, and Siemens. Five years later it was taken more seriously, as also enterprise software vendors, like SAP and Oracle, started to work on their PLM offering. And some years ago even the most skeptic company related to PLM, Autodesk, began to sell a PLM offering.

So like global warming we can conclude: PLM is recognized, and now we can act.

The early adopters of PLM are also in a challenging situation. Their first PLM implementations were very much focused on an IT-infrastructure, allowing data to flow through a global organization, without disrupting the day-to-day business model too much. These implementations are now a burden to many of them: costly and almost impossible to change. Look at the PLM stories from some of the major automotive companies, like Daimler, JLR, PSA, Renault, , Volvo Cars and more.

email_lockThey are all somehow kept hostage by their old implementations (as business continues) however due to changing ownership, business models and technology they cannot benefit from modern PLM concepts as it would be a disruption.

Meanwhile, PLM has evolved from an IT-infrastructure into a business-driven approach to support global, more flexible and customer-driven business processes. Younger companies that are now starting in Asia do not suffer from this legacy and are faster established based on the know-how from the early adopters.

And this is not only happing in the automotive industry. In the recent years, I have seen examples in the Oil & Gas industry, the High-Tech industry (which in theory is relative young) and the Manufacturing industry.

No_roiComing back to the 2015 PLM challenges tweeted by Chad Jackson, it looks like they are related to time and costs. Obviously it is not clear what values PLM can bring to a company outside efficiency gains (ERP/Lean thinking). Modern PLM allows companies to change their business model as I wrote recently: From a linear to fast and circular. No longer is the PLM mission to support companies with product information from cradle to grave but from cradle to cradle. Sustainability and becoming connected to customers are new demands: Operational services instead of selling products, linking it with the need for IoT to understand what is happening.

In the 2015 PLM, the discussion with executives is about purchasing technology instead of the need to change our business for long-term survival. Most investors do not like long-term visions as their prehistoric brains are tuned to be satisfied in the short-term.

changeTherefore, as long as the discussion about PLM is about IT and infrastructure and not about business change, there will be this stall, identical to what happens with addressing global warming. Short term results are expected by the stakeholders, trying to keep up the current model. Strategists and business experts are all talking about the new upcoming digital era, similar to global warming.

We know we have to act, but we do not act seriously

When I posted a short version of this post on LinkedIn on Ascension Day, I got some excellent feedback which I want to share here:

Dieter de Vroomen (independent advisor, interim manager & neighbor) wrote me an email. Dieter does not have a PLM-twisted brain. Therefore I like his opinion:

PLM and Global Warming are both assumptions, mental constructs that we can make plausible with technology and data. Both mindsets save us from disasters through the use of technology. And that’s what both sell. But is that what they produce, what we want? Apple and associates think vice versa, making what first we want and explain later the underlying technology. I miss that with global warming, but certainly PLM. That’s why it sells so bad CxO’s.

I think the point Dieter is making is interesting as he is a non-PLM guy -showing the way CxO might be  thinking. As long as we (PLMers) do not offer a packaged solution, an end-to-end experience, it is hard to convince the C-level. This is one of the significant differences between ERP (its purpose is clearly is tangible) and PLM (see my post PLM at risk! It does not have a clear target).

A more motivating comment came from Ben Muis, consultant and entrepreneur in the fashion industry. We met at the PI Apparel 2013 conference, and I like his passion for bringing innovation to the fashion industry. Read his full comments on my post on LinkedIn as he combined in his career sustainability and PLM. Two quotes from Ben:

As you may know I did quite a bit of work on how the fashion industry could and should be more sustainable in its approach. This was at a time where only a handful of people at best were willing to even think about this. Knowing that in reality the decisions around cost and commercialism were driving the agenda, I drew the conclusion that by improving processes within the industry I could actually cause a sustainability improvement that was driven by commercial desire.

Explaining how you can become involved in the bigger picture and for Ben it is the possibility to keep on working on his passion in a real-time world. And finally:

So there you have it… my reasons for initially thinking your title was very close to the reason I shifted my focus from pure sustainability advice to PLM implementations to begin with. I could drive a real result much quicker. This, as I am sure you will agree, in itself supports the reason for taking PLM seriously

My conclusion:

The topics PLM and Global Warming have a lot in common. The awareness exists. However when it comes to action, we are blocked by our prehistoric brain, thinking about short term benefits. This will not change in the next 1000 years. Therefore, we need organizations and individuals that against all odds take the steep path and have a vision of change, breaking the old models and silos. It will cost money, it will require a sacrifice and the reward will only be noticed by next generations. What a shame

A final quote before going back to standard PLM matter in upcoming posts:

“Everything is theoretically impossible, until it is done.”

Robert A. Heinlein

Mindmap image courtesy of www.mindmapart.comJane Genovese

PxMDid I choose the wrong job? Busy times still and the past 15 years I have focused on PLM and every year I had the feeling there was progress in the understanding and acceptance for PLM. Although the definition of PLM is a moving target, there are probably thousands of PLM experts around the world. From my recent blog posts, the past two years you might share my opinion that PLM is changing from an engineering, document-centric system towards a beyond PLM approach where a data-driven, federated platform leads to (yet unknown) benefits.

So where to draw the border of PLM?

Is there a possibility that somewhere a disruptive approach will redefine PLM again? PLM is considered complex (I don´t think so). The complexity lies first of all in the rigidness of PLM systems not being able to excite people. Next the desires from implementers to provide services to satisfy users and, as a result, make it more complicated. Finally and the most important reason the lack of understanding that implementing PLM requires a business change.

Change (don´t mention the word), which does not happen overnight.

Oleg Shilovitsky wrote about PLM and organizational change. He is leaving it for further discussion if the difficulty is related to the PLM technology or the resistance towards change for people in business. Read his conclusion:

Change is hard. We should re-think the way we implement PLM and exclude process alignment from PLM implementation. Stop changing people and stop forcing people to take complicated decisions during PLM sales process. Future PLM products will become a foundation for agile change management that will be done by companies.

Edward Lopategui is even more provocative in his blog post: The PLM Old Fart Paradox. Have a read of his post including the comments. Edward is somehow sharing the same belief, stating PLM has an identity crisis

PLM has an identity crisis. Talking PLM at a random networking event tends to engender one of two reactions. The first is from anyone who recognizes the acronym, spent 5 years consulting for company X, and begins a vigorous head-nod that instills fear their neck may unhinge in agreement. The other reaction is quite the opposite; you can almost sense a capillary dilation of the so-called blush response. Fluctuation of the pupil… Involuntary dilation of the iris… it’s the Voight-Kampff test for interest expiring at the mere utterance of the acronym. You don’t get this kind of reaction when you talk Cloud or Internet of Things, which while overused, tend to at least solicit questions and interest among the uninitiated. There’s public relations work to be done.

Both Oleg and Edward believe that new technology is needed to overcome the old PLM implementation issues: a need for change, a need to break down the silos.

Meanwhile in Europe

Meanwhile in Europe, an international research foundation for PLM ( has been initiated and is making itself heard towards the United States. What is the mission of this research foundation? To define the future of PLM. Read the opening statement:

The PLM International Research Foundation (PLM-IRF) initiative aims to establish a central mechanism to support global research into the most advanced future capabilities of PLM.

This is the first initiative ever to ask the question:

What research does the world need, to achieve the future PLM capabilities that the world wants?”

This simple question highlights that fact that the PLM industry needs coherent view of the future. Without a clear sense of direction, PLM development is likely to fall far short of what it could be.

2050I consider this as a mission impossible. In May this year I will be blogging for seven years about PLM and looking back to my early posts the world was different. Interesting some of the predictions (PLM in 2050 – predictions done in 2008) I made in the past are still valid however for every right prediction there might be a wrong one too.

And now this International Research Foundation is planning to define what PLM should offer in the future?

What happens if companies do not agree and implement their business approach? It reminded me of a keynote speech given by Thomas Schmidt (Vice President, Head of Operational Excellence and IS – ABB’s Power Products Division) at PLM Innovation 2012 (my review here). Thomas was challenging the audience explaining what ABB needed. Quoting Thomas Schmidt:

“And if you call this PLM, it is OK for me. However, current PLM systems do not satisfy these needs.”

So you can imagine the feeling I got: PLM has an identity crisis.

Or do I have an identity crisis?

changeI believe we are in a transition state where companies have to redefine their business. I described this change in my earlier post: From Linear to fast and circular. Implementing this approach first of all requires a redefinition of how organizations work. Hierarchical and siloed organizations need to transform towards flat, self-adapting structures in order to become more customer-centric and reactive to ever faster-changing market needs.

For that reason, I was surprised by a presentation shared by Chris Armbruster that same week I read Oleg´s and Edward´s posts. In many ways, Chris and I come from the opposite sides of PLM.

My background European, with a classical start from engineering, a focus on the mid-market. Chris according to his Slideshare info, US-based, Supply Chain Executive and focus on the Fortune 500.

Have a look at Chris´s presentation – rethinking business for Exponential times. It is amazing that two persons not connected at all can come to the same conclusions.

This should be an indication there is a single version of the truth!


You might say PLM has an identity crisis. We do not need a better definition of PLM to solve this. We need to change our business model and then define what we need. PLM, ERP, SLM, MES, SCM, ….. There are enough unused TLAs for the future. And I am still happy with my job.




… and you ? Looking for a new job or changing too ?


Get every new post delivered to your Inbox.

Join 438 other followers

%d bloggers like this: