Release and Configuration Management Best Practices
Product release and configuration management continue to be very common conversations across all industries. Earlier this spring I posted regarding BOM configuration and the many choices of processes and methods to efficiently and effectively manage your Bill of Materials. Since then we’ve had more detailed discussions around product variant management, guided product configuration and master data management. Let’s continue the discussion about BOM management and configuration with a closer look at release and configuration management best practices. The true value of PLM harnesses the collaborative energy of the many authors and decision makers in the organization while managing and information they need efficiently. The keys to successfully balancing collaboration and control are robust configuration management practices.
The central goal of best practice BOM configuration management is having a stable definitive and comprehensive product definition at all times throughout a program. The worst possible answer to the question – “What is in the current product configuration?” is “We don’t know.” The mainstream definition of a product should be under control at all times and changes and additions to that definition should be incorporated through a release process. In all cases a well-established practice is to release the content with a status indicating its maturity. Once this is done BOM content can be reliably configured to include the newly released content. These changes are effective the moment they are released. Many companies simply apply a “Released” status to communicate engineering release while others communicate maturity and intent with a progression of status such as “Prototype”, “Preproduction” and “Production”.
In many instances the decision to release new or changed content may occur at the same time as the expectation to execute that change throughout the organization. Factoring in stock, manufacturing impacts, supply chain and other logistical considerations the production unit or date when the change will be incorporated is documented for some point beyond the engineering release. While it is not uncommon to perform a simple release and to manage the effectivity in ERP or other corporate system this practice splits the configuration management decisions across two systems so that an engineer in PLM only knows the engineering release effectivity and not any subsequent qualification that was documented downstream in other systems.
If the effectivity decision is the same for all occurrences of the impacted content, a practice of using revision effectivity may be used. More commonly in some industries such as aerospace, occurrence effectivity is used so that a change is incorporated with specific effectivity for each usage of the content. Using both revision and occurrence effectivity for the same product is generally discouraged as the compounding of the two is unduly complex.
Whether using a basic release process or effectivity, the mainstream Bill of Material definition should be maintained as simply and elegantly as feasible to meet the business process needs of the organization. Changes are made concisely to incorporate an approved change so that the Bill of Material is immediately up to date upon release rather than evolving as the change is executed and reviewed. Should the product definition accumulate every iteration of every study, design alternative and analysis – whether it was adopted or not – the configuration logic employed to discern the released content often becomes very complex. This anti-pattern is usually accompanied with very complex revision rules or a proliferation of revision rules. Put another way – Reconsidering the answer to the earlier question “What is in the current product configuration?” – it is almost subject to debate if there are many possible criteria to configure the same content.
Now you might ask – “So if changes, studies and analysis activities shouldn’t be in the mainstream Bill of Material how should they be managed?” That is the second and perhaps more interesting configuration management practice to discuss. The two approaches are BOM Markup which is a very collaborative approach and Change Isolation which is a more controlled approach.
Using BOM Markup, changes to the content are logically “Red-Lined” to accumulate proposed changes. As an extended team makes their changes to the content they are fully aware of all other changes being proposed. Provided the team is all working to the same milestones and priorities, this is a very efficient collaboration to dynamically and clearly understand all changes made by the team. At planned milestones are as content is validated as fit for release the markup can be applied to incorporate into the next revision of the content. An additional benefit of this approach is only the scope of content that changes will generate new revisions – otherwise a common first step in a change activity is to create a new working revision so even if no changes are made an additional iteration is documented.
In some business scenarios changes and studies that share common content need to occur in isolation from each other. This is commonly the case when evaluating mutually exclusive design alternatives a context is established with a relevant subset of information from the product and new content and solutions are developed. Once the most appealing alternative is selected it is incorporated into the overall product definition. Of course BOTH activities are documented for historical purposes but only the solution content selected and released is in the mainstream structure.
Another similar scenario supports multiple concurrent changes. Suppose there is a long term product improvement initiative underway and prior to that work completing an urgent production issue requires immediate action on content currently being changed. In these cases each change activity is performed in isolation and as one is incorporated the overlapping changes update their context accordingly. Notification and subscription mechanisms are useful to coordinate these updates.
I hope this has been useful for you to understand the value of best practices for configuration management. Understanding “why” you should follow these practices is the first step of understanding “How” to do so in Teamcenter.
