You are currently browsing the category archive for the ‘CTO’ category.
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.
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.
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):
- 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
- 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.
- 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.
- 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).
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:
- What the FFF is happening
- How to step beyond the complexity of Bill of Materials, Revisions and Change Management
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)
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
Sorry guys, I am aware of the fact that the definition of PLM is very ambiguous. Every vendor, implementor and probably PLM consultant has a favorite definition. Just to illustrate this statement, read Brain Soaper´s recent post: What are the top 5 things to know about PLM ?
Interesting Brian starts with stating the definition of PLM is priority #1, however as you can see from the comment session, it is all about having inside your company a common definition of PLM.
And now I start writing about digital PLM, again a definition. You might have read in my blog about classical PLM and modern PLM.
Classical PLM
For me, classical PLM is the way PLM has been implemented in the past 15 years, often as an extension of engineering with the purpose of centralizing and sharing information.
In particular for CAD data, classical PLM is focusing on managing files in a controlled way, through check-in and check-out mechanisms. On top of file management, classical PLM provides more data-driven functionality, like project management, process governance (workflows / approvals / ECx processes) and BOM management (to link to ERP).
Classical PLM can still bring great benefits to a company as time for searching, paper-based processes and data retyping in ERP can be avoided, leading to reuse and fewer errors. The ROI time for a classical PLM implementation lays between two years to three years; my observations from the past. This time can still vary a lot as not every company or implementor/vendor uses the ideal approach to implement PLM, due to cultural issues, wrong expectations or lack of experience from both parties.
The connotations I have with classical PLM are:
linear, rigid, mechanical,(old) automotive, previous century
Modern PLM = Digital PLM
Modern PLM is based on the vision that all information should be managed and stored as data objects, not necessary in a single system. Still the PLM infrastructure, using structured and unstructured data, should give each user in the organization with almost real-time information in context of other relevant information.
My non-stop blog buddy Oleg recently wrote a post in that context: Data as a platform & future manufacturing intelligence. Oleg is nicely describing some of the benefits of a data-driven approach.
Accenture provides insight with their infographic related to Digital PLM. Read it here as it is very concise and gives you a quick impression what Digital PLM means for an organization. Here is my favorite part, showing the advantages.
The substantial advantages from digital PLM are all coming from the fact that information is stored as data objects, all having their individual versions, relations and status. The advantage of data elements is that they are not locked in a document or specific file format. Information can flow to where or whom needed without translation.
The connotations I have with digital PLM are:
real-time, data continuity, flexible, software and future.
Still some caution:
Reported ROI numbers for digital PLM are significant larger than classical PLM and I observed some facets of that. Digital PLM is not yet established and requires a different type of workforce. See other blog post I wrote about this theme: Modern PLM brings Power to the People.
But what about digital PLM – where is the word digital relevant ?
ETO – model-based engineering
Where to focus first depends very much on your company´s core business process. Companies with an Engineering To Order (ETO) process will focus on delivering a single product to their customer and most of the time the product is becoming more like a system, interacting with the outside world.
Big challenges in ETO are to deliver the product as required, to coordinate all disciplines preferable in a parallel and real-time manner – in time – on budget. Here a virtual model that can be accessed and shared with all stakeholders should be the core. The construction industry is introducing BIM for this purpose (a modern version of DMU). The virtual model allows the company to measure progress, to analyze and simulate alternatives without spending money for prototypes. In the ideal world engineering and simulation are done on the same model, not losing time and quality on data translations and iterations.
The virtual model linked to requirements, functions and the logical definition allows virtual testing – so much cheaper and faster and therefore cost efficient. Of course this approach requires a change in how people work together, which is characteristic for any digital business. Breakdown the silos.
Typical industries using the ETO model: Construction, Energy, Offshore, Shipbuilding, Special Equipment
CTO – model-based manufacturing
In a Configure To Order (CTO) business model you do not spend time for engineering anymore. All options and variants are defined and now the focus is on efficient manufacturing. The trend for CTO companies is that they have to deliver more and more variants in a faster and more demanding global market. Here the connectivity between engineering data and manufacturing data becomes one of the cornerstones of digital PLM. Digital PLM needs to make sure that all relevant data for execution (ERP and MES) is flowing through the organization without reformatting or reworking the data.
The digital thread is the dream. Industry 4.0 is focusing on this part. Also in the CTO environment it is crucial to work with a product model, so all downstream disciplines can consume the right data. Although in CTO the company´s attention might go to MES and ERP, it is crucial that the source of the product model is well specified and under control from (dgital) PLM.
Typical CTO industries are: Automotive, Consumer Goods, High-Tech, Industrial Equipment
BTO – models everywhere
If your company has a Build To Order main delivery process, the optimum for digital PLM lies in the middle of ETO and CTO, depending on the type of products your company delivers.
In BTO there is always engineering to do. It can be customer specific engineering work (only once) or it can be changing/ adding new features to the product.
Modularity of the product portfolio might be the answer for the first option, where the second option requires strong configuration management on the engineering side, similar to the ETO model. Although the dream of many BTO companies is to change a CTO company, I strongly believe change in technology and market requirements will always be faster than product portfolio definition.
ETO, BTO and CTO are classical linear business models. The digital enterprise is changing these models too. Customer interaction (myProduct), continuous upgrade and feedback of products (virtual twin), different business models (performance as a service) all will challenges organizations to reconsider their processes.
Digital PLM utilizing a model-based or model-driven backbone will be the (potential) future for companies as data can be flowing through the organization, not locked in documents and classical processes. In my upcoming blog post I will spend some more time on the model-based enterprise.
Conclusion:
It depends on your company´s core business process where the focus on a model-based enterprise supported by (digital) PLM benefits the most. In parallel business models are changing which means the future must be flexible.
Digital PLM should be one of your company´s main initiatives in the next 5 years if you want to stay competitive (or relevant)
What do you think ? Am I too optimistic or too pessimistic ?
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
In my previous post, BOM for Dummies related to Configure To Order, I promised to come back on the special relation between the items in the BOM and the CAD data. I noticed from several posts in PLM and PDM groups that also the importance of CAD data is perceived in a different manner, depending on the background of the people or the systems they are experienced with.
So I would like to start with some general statements based on these observations.
People who are talking about the importance of CAD data and product structures are usually coming from a background in PDM. In an environment where products are designed, the focus is around data creation, mostly CAD data. The language around parts in the BOM is mostly targeting design parts. So in a PDM environment CAD data is an important topic – therefore PDM people and companies will talk about CAD data and vaults as the center of information.
When you are working in a PLM environment, you need a way to communicate around a product, through its whole lifecycle, not only the design phase but also supporting manufacturing phases, the possible changes of an existing product through engineering changes, the traceability of as-built data and more. In a PLM environment, people have the physical part (often called the ERP part) in mind, when they talk about a part number.
As PLM covers product information across various departments and disciplines, the information carrier for product information cannot be the CAD data. The BOM, usually the mBOM, is the main structure used to represent and produce the product. Most parts in the mBOM have a relation to a CAD document (in many companies still the 2D drawing). Therefore PLM people and companies understanding PLM will talk about items and products and their lifecycle as their center of information.
CAD data in relation to Engineering to Order
The above generalizations have to be combined with the different main business processes. In a strict Engineering To Order environment, where you design and build a solution only once for a specific customer, there is no big benefit of going through an eBOM and mBOM transition.
During the design process the engineer already has manufacturing in mind, which will be reflected in the CAD structure they build – sometime hybrid representing both engineering and manufacturing items. In such an environment CAD data is leading to build a BOM structure.
And in cases where engineering is done in one single 3D CAD system, the company might use the PDM system from this vendor to manage their Bill of Materials. The advantage of this approach is that PDM is smoothly integrated with the design environment. However it restricts in a certain matter the future as we will see in further reading.
Not everyone needs the Engineering to Order process !
Moving to an integrated, multi-disciplinary engineering process or changing the main process from Engineering To Order to Built To Order / Configure To Order will cause major challenges in the company.
I have seen in the recent past, several companies that would like to change their way of working from a CAD centric Engineering To Order process towards a more Built to Order or Configure To Order process. The bottle neck of making this switch was every time that engineering people think in CAD structures and all knowledge is embedded in the CAD data. They now want to configure their products in the CAD system.
For Configure to Order you have to look at a different way to your CAD data:
Questions to ask yourself as a company are:
- When I configure my products around a CAD structure, what should I do with data from other disciplines (Electrical/Tooling/Supplier data) ?
- When I upgrade my 3D CAD system to a new version, do I need to convert all old CAD data to the newest versions in order to keep my configurations alive?
- When configuring a new customer solution, do I need to build my whole product in CAD in order to assure it is complete?
- In Configure to Order the engineering BOM and manufacturing BOM are different. Does this mean that when I go through a new customer order, all CAD data need to be handled, going through eBOM and mBOM transition again?
For me it is obvious that only in an Engineering to Order environment the CAD data are leading for order fulfillment. In all other typical processes, BTO (Built to Order), CTO (Configure to Order) and MTS (Make to Stock), product configuration and definition is done around items and the CAD data is important associated data for the product definition and manufacturing
In the case of order fulfillment in a Configure to Order process, the CAD structure is not touched as configuration of the product is available based on items. Each item in the mBOM has it relations to CAD data or other specifying information.
In the case of Built To Order, a huge part of the product is already configured, like in Configure To Order. Only new interfaces or functionality will go through a CAD design process. This new design might be released through a process with an eBOM to mBOM transition. In cases where the impact or the amount of data created in engineering is not huge, it is even possible to configure the changes immediately in an mBOM environment.
A second point, which is also under a lot of discussion in the field ( PLM interest groups), is that PDM is easily to introduce as a departmental solution. The engineering BOM is forwarded to manufacturing and there further (disconnected) processed. The step from PDM to PLM is always a business change.
When PDM vendors talk about ERP integration, they often mean the technical solution of connecting the two systems, not integrating the processes around the BOM (eBOM/mBOM transition) 0r an integrated engineering change (ECR/ECO). See how easy it is according to some PDM vendors:
or
PLM requires an adaptation of all departments to work different and together around a single product definition. Especially in a mid-market company, this is a big issue, as all product knowledge is stored in the CAD data and the knowledge how to produce the product is stored in the mBOM on the ERP side. These environments are often disconnected.
Conclusion: In the context of PDM the importance of CAD data is clear and for companies following a strict Engineering To Order process the main source of product knowledge. Companies following the Built To Order / Configure To Order process should configure their products around items to keep flexibility towards the future.
Companies with the intention to move to Built To Order or Configure To Order should not invest too much in CAD data configuration as it creates a roadblock for the future.
In my next post I will address the question that comes up from many directions, addressed by Jim Brown and others, as discussed in one of his recent posts around a PLM standard definition and more ….
This is the third post on Bill of Material handling for different types of companies, this time the focus on Configure To Order (CTO). In the CTO process, products are assembled and configured based on customer requirements. This means there is no more engineering needed when customer requirements are known. CTO examples are, the ordering process of a car with all its options, or ordering a personal computer over the internet.
So what has Configure To Order to do with PLM as there is no engineering?
The main PLM activity takes places when designing the configurable product. Designing a product that is configurable, requires a complete different approach as compared to Engineering to Order or Build to Order. Although we see a similar Configure to Order activity in the R&D departments of companies that follow the Build to Order process. They are also designing products or modules that can be used as-is in customer specific orders as part of the solution.
The challenge of CTO is to design products that are modular, and where options and variants are designed on a common platform with common interfaces. If you look to the dashboard of a car you will see placeholders for additional options (in case you have the minimal car version) and also you might see that for example the radio display in a basic car version differs from the complete board computer in the luxury version. The common platform is one dashboard, fitting to numerous options.
An engineering department will not focus on designing and defining each of the possible combinations of options as this would be impossible to manage. What can be managed is the common platform (the baseline) and all different options on top of this baseline.
So what happens with the BOM?
The initial design of configurable products goes through similar steps as the BTO process, which means starting from a conceptual BOM, moving to an Engineering BOM (eBOM) and finally produce a BOM for manufacturing (mBOM). The difference is that in the CTO process the mBOM is not developed for just one product, but contains all definitions for all possible products. In this situation we talk about a generic mBOM.
Only when a customer order exists, the generic mBOM is resolved into a specific mBOM for this customer order, which then can be sent to the ERP system for execution.
In a generic BOM the relations are managed by filters. These filters define the effectivity of the link, in simple words if the relation between two parts in the BOM is valid (and shown) or not. There are various ways to define effectivity – with again a differentiation in usage
- revision based effectivity – which means the relation between two items is valid in case the revisions match
- date effectivity – which means the relation is valid during a certain time interval
Both methods are used most of the time for non-configurable products. The revision and date effectivity are used to be able to track the product history through time and therefore to have full traceability. But this does not work if you want to configure every time a customer specific order.
In that case we use unit or option based filtering.
- unit effectivity – which means the relation between two items is valid for a unit (or a range of units) produced. For example a batch of products or a unique product with a serial number
- option effectivity – which means the relation between two items is valid in case a certain condition is valid. Which condition depends on the configuration rules for this option. Example of options are: color, version, country
It is clear that unit and option based filtering of a BOM can lead to a conceptual complex product definition which goes beyond the BOM for Dummies target. Below an illustration of the various filter concepts (oops the animated gif does not work – i will investigate):
The benefit of this filtering approach is that there is a minimum of redundancy of data to manage. This makes it a common practice in the aerospace and automotive industry. An example describing all the complexity can be found for example here, but I am sure on this level there are enough publications and studies available.
And what about the CAD ?
I will write a separate post on this topic, as all the possible interactions and use cases with CAD are a topic on its own. You can imagine, having the 3D virtual world combined with a configurable BOM brings a lot of benefits
What PLM functions are required to support Configure to Order ?
- Project management – not so much focus here as the delivery project for a customer does not require much customer interaction. Of course, the product development processes requires advanced capabilities which I will address later in a future post.
- Document management – same approach as for project management. The product related documentation needs to exist and secured. Customer specific documentation can be generated often automatically.
- Product Management – managing all released and available components for a solution, related to their Bill of Materials. Often part of product management is the classification of product families and its related modules
- Item management – The main activities here are in the mBOM area. Capabilities for BOM generation (eBOM/mBOM), baseline and compare using filtering (unit based / option based) in order to support the definition if the manufactured product
- Workflow processes – As we are dealing with standardized components in the BOM, the Engineering Change Request (ECR) and Engineering Change Order (ECO) processes will be the core for changes. And as we want to manage controlled manufacturing definition, the Manufacturer Change Order process and Standard Item Approval process are often implemented
Optional:
- Requirements Management – specially for complex products, tracking of individual requirements and their implementation, can save time and costs during delivery to understand and handle the complex platform
- Service Management – as an extension of item management. When a customer specific order has been delivered it might be still interesting for the company that delivered the product to keep traceability of the customer configuration for service options – managing the Service and As-Built BOM
- Product Configurator – the reason I write it as optional, is because the target is order execution, which is not a PLM role anymore. The ERP system should be able to resolve the full mBOM for an order. The PLM product configuration definition is done through Product and Item management. Depending on the customer environment the role of configurator might be found in PLM in case ERP does not have the adequate tools.
Conclusion:
It is hard to describe the Configure To Order process in the scope of BOM for Dummies. As various detailed concepts exist per industry there is no generic standard. This is often the area where the PLM system, the PLM users and implementers are challenged the most: to make it workable, understandable and maintainable
Next time some industry specific observations for a change
Jos Voskuil's Weblog 
Hi Jos, Having been involved in multiple tool implementations, one other drawback to smart numbering is that tools need to…
Good day Jos, I was involved in many implementations over the years (including) Philips…. Indeed smart part numbers was a…
If one were starting out a brand new company, you could start a part numbering sequence at 100 and just…
Jos, as always a great report. Agree with you, the agenda and the presentations was a bit of Classic PLM…
Another Interesting article, I also see this kind of development in our company where terminology shifts and approach methods change.…