Product development requires an eco-system of inter-dependent capabilities and complementary functions to bring teams together around a product creation and industrialisation platform. The so-called platform contribute to converting new ideas into product designs, up to production readiness and serviceability, managing the engineering-enterprise relational data throughout their lifecycle.
Most products have multiple variants and successive modifications of previous versions and successive model years. Independently of which new attributes, new requirements and new technologies are used to bring competitive advantage to new products and new model year models, it is commonly required to strategically plan and manage carry-over parts and components, common data, version and release processes:
- Carry-over parts are used across multiple products and platforms in order to gain cost leadership advantage and various efficiencies with economies of scale and scope, hence their history and traceability need to be robustly managed.
- Parts will have multiple versions and maturity status: either obsolete, in progress, in use at different stages of the product lifecycle, either in design, production, service, or a combination of the above; they are “effective” from one date to another (lifespan) for certain products and perhaps at a different date range for other products based on required compatibility and requirements.
- Parts mature during their lifecycle through a given release process: design and engineering teams typically work on the latest work-in-progress version(s), while previous released versions will continue to be in production or service and managed via product configurations and effectivity attributes.
- Part usage defines how product attributes are met: some product variants might still use previous part versions while other might use the latest part versions; additionally, products are likely to be “upgraded” to more recent versions as they mature during their lifecycle (based on product configuration compatibility, cost and serviceability requirements).
The above can only be effective by optimising how Bills of Materials (BoM) are used and reused through carry-over product structures and BoM templates; Product Lifecycle Management (PLM) solutions typically use a “copy” BoM capability to create new product structures from existing ones and templates. Parts are replaced by newer versions as they mature and as the products evolve.
PLM systems have to manage how part versions are used and replaced within different product structure assemblies to align with new configuration lifecycle specifications.
The effectiveness of “part version substitution” – also referred as “replace where used” – is critical for engineering and design teams to update the product structure assemblies in PLM following the release of a previous part version, or the creation of a new part version with same part number.
The idea is that a new part version is to replace an old one in the design tree wherever required (not necessarily across all product structures). Typically, design teams prefer to have this process semi-automated within the PLM system upon release in alignment with the usage period of the new part version.
Effective “replace where used” capability and process can lead to the following operational benefits:
- Simplify the up-issue process (following the release of the previous issue, the new issue become the one “in work“ – the current issue)
- Reduce essential non value-add user operations and the risk of manual mistakes by automating the substitution of all occurrences of a previously released part issue by its new issue (the new part “in work“ with same part number)
- Find and replace existing / used part versions in relevant assemblies where instanced using ‘new part version with same part version’ functions; keeping consistency with item naming, part numbering, history and associativity between old and new issues.
It is important to consider the following when implementing change management processes (non-exhaustive list):
- What are the key change types and can they be minimised?
- How are cary-over parts managed throughout product and platform lifecycle?
- How are multiple part versions managed across multiple product lines and plants?
- How is product configuration controlling part usage?
- How are BoM changes and CAD changes integrated?
- How are change impact analysis performed and how are issues (and risks) identified before and after part version substitution?
- Given a specific item or part, how are successive changes and usages tracked?
- How are BoM assemblies using different versions of the same parts and how to search relevant data up and down a BoM structure or tree?
- How is data accessed and security controlled across the above capabilities?
- How are old parts or part versions replaced in context by new ones, and how this impacts and relies on the release and maturity control processes?
Understanding and implementing effective “replace where used” requirements and capabilities is often the elephant in the room when deploying new PLM solutions. It is complex as it sits at the intersection of release, change, version, maturity, shared and carry-over strategies, as well as product configuration and baseline.
If not thought carefully, bad process design and heavy PLM system customisation around “replace where used” related user scenario can lead to various uncontrolled BoM changes, complex CAD data change and release processes, technical data associativity issues (broken links), performance issues and duplicated engineering activities which can severely hinder product development effectiveness. “Replace where used” issues are often complex and difficult to solve as they concern fundamental PLM data model and process principles, which in themselves represent the “Achilles heel of PLM“. They require exhaustive root cause analysis and holistic set of countermeasures for long term resolution and solution stability.
What are your thoughts?
This post was originally published on LinkedIn on 6 January 2017.