You are currently browsing the tag archive for the ‘Best Practices’ tag.
The past half-year I have been intensively discussing potential PLM roadmaps with companies of different sizes and different maturity in PLM. Some companies are starting their PLM journey after many years of discussion and trying to identify the need and scope, others have an old PLM implementation (actually most of the time it is cPDM) where they discover that business paradigms from the previous century are no longer sufficient for the future.
The main changing paradigms are:
- From a linear product-driven delivery process towards an individual customer focused offering based on products and effective services, quickly -adapting to the market needs.
- From a document-driven, electronic files exchange based processes and systems towards data-driven platforms supporting information to flow in almost real-time through the whole enterprise.
Both changes are related and a result of digitization. New practices are under development as organizations are learning how to prepare and aim for the future. These new practices are currently dominating the agenda from all strategic consultancy firms as you cannot neglect the trend towards a digital enterprise. And these companies need next practices.
And what about my company?
It is interesting to see that most of the PLM implementers and vendors are promoting best practices, based on their many years of experience working having customers contributing to functionality in their portfolio.
And it is very tempting to make your customer feel comfortable by stating:
“We will implement our (industry) best practices and avoid customization – we have done that before!”
I am sure you have heard this statement before. But what about these best practices as they address the old paradigms from the past?
Do you want to implement the past to support the future?
Starting with PLM ? Use Best Practices !
If the company is implementing PLM for the first time and the implementation is bottom-up you should apply the old PLM approach. My main argument: This company is probably not capable/ready to work in an integrated way. It is not in the company´s DNA yet. Sharing data and working in a controlled environment is a big step to take. Often PLM implementations failed at this point as the cultural resistance was too big.
When starting with classical PLM, avoid customization and keep the scope limited. Horizontal implementations (processes across all departments) have more success than starting at engineering and trying to expand from there. An important decision to make at this stage is 2D leading (old) or the 3D Model leading (modern). Some future thoughts: How Model-based definition can fix your CAD models. By keeping the scope limited, you can always evolve to the next practices in 5 -10 years (if your company is still in business).
Note 1: remark between parenthesis is a little cynical and perhaps for the timeframe incorrect. Still, a company working bottom-up has challenges to stay in a modern competitive global environment.
Note 2: When writing this post I got notified about an eBook available with the tittle Putting PLM within reach written by Jim Brown. The focus is on cloud-based PLM solution that require less effort/investments on the IT-side and as side effect it discourages customization (my opinion) – therefore a good start.
Evolving in PLM – Next Practices
Enterprises that have already a PDM/PLM system in place for several years should not implement the best practices. They have reached the level that the inhibitors off a monolithic, document based environment are becoming clear.
They (must) have discovered that changing their product offering or their innovation strategy now with partners is adding complexity that cannot be supported easily. The good news, when you change your business model and product offering, there is C-level attention. This kind of changes do not happen bottom-up.
Unfortunate business changes are often discussed at the execution level of the organization without the understanding that the source of all products or offering data needs to be reorganized too. PLM should be a part of that strategic plan and do not confuse the old PLM with the PLM for the future.
The PLM for the future has to be built upon next practices. These next practices do not exists out of the box. They have to be matured and experienced by leading companies. The price you pay when being a leader Still being a leader bring market share and profit your company cannot meet when being a follower.
The Bi-modal approach
As management of a company, you do not want a disruption to switch from one existing environment to a new environment. Too much risk and too disruptive – people will resist – stress and bad performance everywhere. As the new data-driven approach is under development (we are learning), the end target is still moving.
Evolving using the old PLM system towards the new PLM approach is not recommended. This would be too expensive, slow and cumbersome. PLM would get a bad reputation as all the complexity of the past and the future are here. It is better to start the new PLM with a new business platform and customer-oriented processes for a limited offering and connect it to your legacy PLM.
Over the years the new PLM will become more clear and grow where the old PLM will become less and less relevant. Depending on the dynamics of your industry this might take a few years till decades.
It must and will be a business-driven learning path for new best practices
Best Practices and Next Practices are needed in parallel. Depending on the maturity and lack of sharing information in your company, you can choose. Consider the bi-modal approach to choose a realistic time path.
What do you think? Could this simplified way of thinking help your company?
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.