You are currently browsing the category archive for the ‘ETO’ 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.
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)
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 ?
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
Usually, 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
In 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
This 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
Finally, 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 previous post, I wrote about the different ways you could look at Service Lifecycle Management (SLM), which, I believe, should be part of the full PLM vision. The fact that this does not happen is probably because companies buy applications to solve issues instead of implementing a consistent company wide vision (When and Where to start is the challenge). Oleg Shilovitsky just referred one more time to this phenomena – Why PLM is stuck in PDM.
I believe PLM as the enterprise information backbone for product information. I will discuss the logical flow of data that might be required in a PLM data model, to support SLM. Of course all should be interpreted in the context of the kind of business your company is in.
This post is probably not the easiest to digest as it assumes you are somehow aware and familiar with the issues relevant for the ETO (Engineering To Order) /EPC (Engineering Procurement Construction) /BTO (Build To Order) business
A collection of systems or a single device
The first significant differentiation I want to make is between managing an installation or a single device as I will focus only on installations.
An installation can be a collection of systems, subsystems, equipment and/or components, typically implemented by companies that deliver end-to-end solutions to their customers. A system can be an oil rig, a processing production line (food, packages, …), a plant (processing chemicals, nuclear materials), where maintenance and service can be performed on individual components providing full traceability.
Most of the time a customer specific solution is delivered to a customer, either direct or through installation / construction partners. This is the domain I will focus on.
I will not focus on the other option for a single device (or system) with a unique serial number that needs to be maintained and serviced as a single entity. For example a car, a computer device. Usually a product for mass consumption, not to be traced individually.
In order to support SLM at the end of the PLM lifecycle, we will see a particular data model is required which has dependencies on the early design phases.
Let´s go through the lifecycle stages and identify the different data types.
The concept / sales phase
In the concept/sales phase the company needs to have a template structure to collect and process all the information shared and managed during their customer interaction.
In the implementations that I guided, this was often a kind of folder structure grouping information into a system view (what do we need), a delivery view (how and when can we deliver), a services view (who does what ) and a contractual view (cost, budget, time constraints). Most of these folders had initially relations to documents. However the system view was often already based on typical system objects representing the major systems, subsystems and components with metadata.
In the diagram, the colors represent various data types often standard available in a rich PLM data model. Although it can be simplified by going back to the old folder/document approach shared on a server, you will recognize the functional grouping of the information and its related documents, which can be further detailed into individual requirements if needed and affordable. In addition, a first conceptual system structure can already exist with links to potential solutions (generic EBOMs) that have been developed before. A PLM system provides the ideal infrastructure to store and manage all data in context of each other.
The Design phase
Before the design phase starts, there is an agreement around the solution to be delivered. In that situation, an as-sold system structure will be leading for the project delivery, and later this evolved structure will be the reference structure for the as-maintained and as-services environment.
A typical environment at this stage will support a work breakdown structure (WBS), a system breakdown structure (SBS) and a product breakdown structure (PBS). In cases where the location of the systems and subsystems are relevant for the solution, a geographical breakdown structure (GBS) can be used. This last method is often used in shipbuilding (sections / compartments) and plant design (areas / buildings / levels) and is relevant for any company that needs to combine systems and equipment in shared locations.
The benefit of having the system breakdown structure is that it manages the relations between all systems and subsystems. Potentially when a subsystem will be delivered by a supplier this environment supports the relationship to the supplier and the tracking of the delivery related to the full system / project.
Note: the system breakdown structure typically uses a hierarchical tag numbering system as the primary id for system elements. In a PLM environment, the system breakdown elements should be data objects, providing the metadata describing the performance of the element, including the mandatory attributes that are required for exchange with MRO (Maintenance Repair Overhaul) systems.
Working with a system breakdown structure is common for plant design or a asset maintenance project and this approach will be very beneficial for companies delivering process lines, infrastructure projects and other solutions that need to be delivered as a collection of systems and equipment.
The delivery phase
During the delivery phase, the system breakdown structure supports the delivery of each component in detail. In the example below you can see the relation between the tag number, the generic part number and the serial number of a component.
The example below demonstrates the situation where two motors (same item – same datasheet) is implemented at two positions in a subsystem with a different tag number, a unique serial number and unique test certificates per motor.
The benefit of a system breakdown structure here is that it supports the delivery of unique information per component that needs to be delivered and verified on-site. Each system element becomes traceable.
The maintenance phase
For the maintenance phase the system breakdown structure (or a geographical breakdown structure) could be the place holder to follow up the development of an installation at a customer site.
Imagine that, in the previous example, the motor with tag number S1.2-M2 appears to be under dimensioned and needs to be replaced by a more powerful one. The situation after implementing this change would look like the following picture:
Through the relationships with the BOM items (not all are shown in the diagram), there is the possibility to perform a where-used query and identify other customers with a similar motor at that system position. Perhaps a case for preventive maintenance?
Note: the diagram also demonstrates that the system breakdown structure elements should have their own lifecycle in order to support changes through time (and provide traceability).
From my experience, this is a significant differentiator PLM systems can bring in relation to an MRO system. MRO and ERP (Enterprise Resource Planning)systems are designed to work with the latest and actual data only. Bringing in versioning of assets and traceability towards the initial design intent is almost impossible to achieve for these systems (unless you invest in a heavy customized system).
Conclusion
In this post and my previous post, I tried to explain the value of having at least a system breakdown structure as part of the overall PLM data model. This structure supports the early concept phase and connects data from the delivery phase to the maintenance phase.
Where my mission in the past 8 years was teaching non-classical PLM industries the benefits of PLM technology and best practices, in this situation you might say it is where classical BTO companies can learn from best practices from the process and oil & gas industry.
Note: Oleg just published a new blog post: PLM Best Practices and Henry Ford Mass Production System where he claims PLM vendors, Service partners and consultants like to sell Best Practices and still during implementation discover mass customization needs to be made to become customer specific, therefore, the age of Best Practices is over.
I agree with that conclusion, as I do not believe in an Out-Of-The-Box approach, to lead a business change.
Still Best Practices are needed to explain to a company what could be done and in that context without starting from a blank sheet.
Therefore I have been sharing this Best Practice (for free)
Some weeks ago there was a vivid discussion around the need for SLM (service lifecycle management) besides PLM started in a PLM LinkedIn group. Of course, the discussion was already simmering in the background in other LinkedIn groups and fora (forums) triggered by PTC´s announcement to focus on SLM and their “observation” that they were probably the only PLM vendor to observe that need. The Internet of Things is in one pen stroke connected with SLM. (Someone still using a pen?)
Of course it is not that simple and I will try to bring some logic in the thought process, the potential hype and the various approaches you could take related to SLM
SLM
First SLM as a TLA (Three Letter Acronym). If you would Google what is the meaning of SLM the most common meaning is Hello, often said on IRC, this is short for “salaam”, or hello.
In the context of PLM it is a relative new acronym and the discussion on LinkedIn was also about the fact if we needed a new TLA. In general. What we try to achieve with SLM is: the ability to trace and follow existing products at customers and to provide advanced or integrated services to them. In a basic matter this could be providing documentation and service information (spare parts information). In an advanced manner, this could be thinking about the Internet of Things, be products that connect to the home base and provide information for preventive maintenance, performance monitoring and enhancements, etc.
The topic is not new for companies around the world that have a “what can we do beyond PDM” vision, as I was involved already in 2001 in discussion with a large Swiss company providing solutions for the food processing industry. They wanted to leverage their internal customer centric delivery process and extend it to their customer support using a web interface for relevant content: spare parts lists and documentation.
I am sure one or two readers of this blog post will remember “the spindle case” (the only part in the demo concept that had real data behind it at that time)
For many industries and businesses the customer services (and the margin on spare parts) are the main areas where they make a sustainable profit to secure the company’s future. Most of the time, the initial sale and/or delivery of their products are done with relative low margin due to the competitive sales situation they are during selling. And of course the sale itself is surrounded with uncertainty which vendors have to accept.
If they would ask for more certainty – it would require a more detailed research, which is costly for them or considered as a disadvantage by their potential customer. As other competing vendors do not insist on further research, your company might consider not being “skilled” enough to estimate properly a product.
The above paragraph implicitly clarifies that we are mainly talking about companies, where their primary process is Engineering to Order or Build to Order. For companies where the product is delivered through a Configure to Order or an Off-the-Shelf approach, there is no need to work in a similar manner. Buying a computer or a car has no sales engineering involved anymore. There is a clear understanding of the target price and of course resellers will still focus on differentiating themselves by providing adjacent services.
So for simplicity I will focus on companies with a BTO or ETO primary business process
SLM and ETO
In a real Engineering to Order process, traditionally the company that delivers the solution to the client will not be really involved in the follow up of the lifecycle of the products delivered. The delivered product (small machinery, large machinery or even an installation or plant) is delivered to the customer and with the commissioning and handover a lot of information is transferred to the customer, based on the requirements of the customer.
Usually during this handover, a lot of intelligence of the information is gone, as the customer does not have the same engineering environment and therefore requires information is “neutral” formats: paper (less and less), PDFs (the majority) and (stripped) CAD data combined with Excels.
The information battle here between the ETO-delivery company and the customer is, that the ETO-delivery company does not want to provide too much information to the customer, to make the customer fully independent, as the service and spare parts business is the area where they can make their margin. The customer, however, often wants to have ownership of the majority of data, but also there is the awareness if they ask too much; they will pay for it (as an engineering company will consider this as extra work). So finding the right balance is the point.
However, the balance is changing, and this is where SLM comes in.
More and more we see that companies who purchased in the past an Engineering to Order product (or even plant) are changing their business model towards using the product or running the plant and ask from the Engineering to Order company to provide the solution as a service. A kind of operation lease including resources. This means solutions are no longer sold as a collection of products, but as an operational model (40.000 chickens / day, 1 Mio liter/day, 100 000 Tons / year, etc., etc.)
The owner of the equipment is no longer the owner, but pays for the service to perform the business. Very similar to SaaS (software as a service) solutions. You do not own the software anymore; you pay for using it, no matter what kind of hardware / software architecture there is behind the offering.
In that case, the Engineering to Order company can provide much more advanced services when they extend their delivery process with capabilities for the operational phase of the product. As a more integrated approach eliminates the need for this disruptive handover process. Data does not need to be made “stupid” again, it is a continuous flow of information.
How this can be done, I will describe in an upcoming, more technical, blog post. This approach brings value to both the Engineering to Order company and the owner/operator of the product / plant.
As it is a continuous flow of information, I would like to conclude this topic by stating that, for Engineering to Order companies, there is no need to think about an extra SLM solution. You could label the last part of the PLM process the SLM domain.
As the customer data is already unique, it is just a normal continuation of the PLM process.
Two closing notes here:
- I have seen already Engineering to Order companies that provide the whole maintenance and service of the delivered product / plant to their customer integrated in their data environment. (so it is happening !)
- Engineering to Order companies are still discovering the advantages of PLM to get a cross-project, cross-discipline understanding and working methodology for their delivery process. Historically they were thinking in isolated projects, where the brain of experienced engineers was the connection between different projects. Now PLM practices are becoming the foundation for sharing and capitalizing on knowledge.
And with the last remark on capitalizing the knowledge, we move from the Engineering to Order industry to the Build to Order
SLM and BTO
In the Build to Order industry, the company that delivers a solution to their customer, has tried, in a way, to standardize certain parts of their total solution. These parts can be standardized/configurable machinery or standardized/configurable equipment, or even a level higher standardized systems and subsystems.
More configurable/modular standardization is what most companies are aiming for. As the more you modularize your solution parts, the clearer it will be that there are two different main processes inside the same organization:
- One process, the main process for the company, fulfilling the customer need. In this process it is about combining existing solution components and engineering them together in a customer specific solution. This could be a PLM delivery model like ETO.
- One process to enhance, maintain and develop new solution components, which is a typical R&D process. Here I would state PLM is indisputable needed, to bring new technology and solutions to the main business process
So within a company, there might be the need for two different PLM solution processes. From my observations in the past 10 years, companies invest in PDM for their R&D process and try to do a little of PLM on top of this PDM implementation for their delivery process. This basic PLM process usually focuses again on the core of the engineering process of delivery, starting somewhere from the specifications till the delivery of the solution.
So “full” PLM is very rare to find. The front end of the delivery process, systems engineering, is often considered complex and often the customer does not want to engage fully in the front end definition of the solution.
“You are the experts, you know best what we want” is often heard.
Ironically in an analogue situation this is often the case of PLM implementations at risk. Here the company expects the PLM implementer to know what they want, without being explicit or understanding what is needed.
To extend the discussion for PLM and SLM, I would like to change the question to a different dimension first:
Do we need two PLM implementations within one company ?
One for R&D and one for the delivery process ?
Reasons to say No are:
- Simplicity – it is easier to have one system instead of two systems
- The amount of R&D activity is so low compared to the delivery process; the main PLM system can support this.
Reasons to say Yes are:
- The R&D process is extremely important as is the delivery process
- The R&D process is extremely important and we have a large customer base to serve
Reading these two options, it brings some clarity.
If the R&D process is a significant differentiator and you are aiming to serve many customers, it makes sense to have two PLM implementations.
Still two PLM implementations could be based on the same PLM infrastructure and I would challenge readers of this post to explain why it should be a single instance of a PLM infrastructure.
Why two PLM systems
- I believe based on the potential huge amount of data a single instance would create a data monster, where we can see that connected systems (using big data) is the future.
- In other concepts there is an enterprise PLM and local PDMs exactly because there is no single system that can do all in an efficient manner.
Still I haven´t talked about SLM, which could be part of the delivery process, where you manage customer specific data. For that, more detail in my next blog post, there is are some data model constraints for the PLM system.
I would state you only can use a separate SLM system if you are not interested in data from the early phases of the delivery process. In the early phase, you use conceptual structures to define the product /installation/plant. These conceptual structures are to my opinion the connection between the concept phase and the service phase. Usually tag numbers are used to describe the functional usage of a product or system, and they are the ones referenced by service engineers to start a service operation.
Only when this view or need does not exist, I can imagine, SLM is needed, where potential based on serial numbers, services are tracked and monitored and are fed back to the R&D environment. The R&D environment then would publish product data into the SLM system
You might be confused at this time, as I did not bring the various information structures into this post to clarify the data flow for the delivery process. This I will do in my upcoming post.
Why not CTO and SLM ?
I haven´t discussed Configure to Order (CTO) here, as I consider CTO a logistical process, which logically is addressed by the ERP system. The definitions of the configurations and its related content probably will be delivered through a PDM/PLM system, so the R&D type of PLM system will exist in the company.
SLM most logically would be performed in this situation by the ERP system, as there is no PLM delivery layer. Having said this, a new religion discussion might come up. Is SLM a separate discipline or is it part of the ERP system?
This topic is no discussion for the big ERP vendors – they do it all J, but it is up to your company if a Swiss knife is the right tool to work within your organization.
Conclusion
For the moment I would like to conclude:
- PLM and SLM –> No (only Yes in isolated cases)
- PLM and PLM –> Yes (as SLM requires the front end of PLM too)
Do we need SLM ? Perhaps yes as a way to describe a functional domain. No when we are talking about another silo system. I believe the future is in connectivity of data and in the long term PLM, ERP and SLM will be functional domains describing how connected data will serve particular needs.
Looking forward to your thoughts
Jos Voskuil's Weblog 
Jos, great thoughts about BOM management. Here are some of my thoughts. I can see how BOM management will evolve…
As a complement, even if more and more of the diversity of a product is managed at the software level…
1) A wiring diagram stores information (wires between ports of the electrical components) that does not exist in most of…
BOM has NEVER been the sole "master" of the Product. The DEFINITION FILE is ! For example the wiring of…
Interesting discussion about part numbers and where they originate. Though there seems to be consensus about the EBOM and MBOM,…