Integrated Product Definition
In my previous article, I discussed Product Master Data Management and the relevance of locating the Product Master directly within the PLM system. In this context, I introduced the Integrated Product Definition as the key strategy for BOM management and BOM configuration in Teamcenter. I would like to elaborate further on that topic in this article.
Integrated Product Definition
At its core, the Integrated Product Definition approach in Teamcenter promotes engineering authoring and formal release of product definition data as well as direct augmentation of the engineering released product definition with other product information that is relevant to multiple consumption purposes – such as engineering mockups, manufacturing, service planning, procurement, production at multiple plants etc. – so that the right context relevant information can be derived directly from the Engineering definition by appropriate consumers.
Integrated Product Definition – Enabling Technologies
Now, let’s take a look at some of the technologies available and being further developed in Teamcenter to provide for Integrated Product Definition (IPD). To explain IPD ‘in a nutshell’, I’d like to point to the ‘four quadrants’ view of the business process and technological components of it. This also usually helps my audience recognize this type of separation, in terms that their businesses are already used to, as well as relate to the benefits of integration of these key business process areas. Henceforth in this article, I will try and explain some of the ‘guiding principles’ in each of these IPD process areas and their associated value.
Product Configuration and Architecture
A central principle in the Product Configuration process area is the separation of product configuration decisions from product content decisions. Product configuration decisions are usually independent of content domains and content has to be provided to satisfy configuration decisions. Configuration decisions define Options and combinations offered and how these apply to specific products in the portfolio. Content decisions center on Parts, along with supporting CAD, Process and other documentation that are available to satisfy a particular configuration condition. Separating the two offers flexibility in both.
For further discussion, I recommend you take a look at articles my colleagues have written on this subject, including an overview of BOM configuration management as well as more detailed exploration of product variant management, guided product configuration, and configuration management best practices.
In the most general terms, Product Architectures govern the organization of products. This organization provides structure for several key planning, authoring and execution decision making concerning these products. At large OEMs, it is not uncommon to find the personnel organizational structure mirroring the product organizational structure.
Product architectures when used to organize and scope product Options facilitate planning including specification of targets such as mass/weight, volumes, market penetration etc. Such scoping of Options based on architecture also enables ‘modular release’ – ie. Controlled authoring and coordinated release of product content that is relevant to a module. This allows for better reusability of product content – e.g. Releasing content to a module and reuse of module across products. Architecture (or module) based organization of product content allows for tighter product definition completeness checks across domains – e.g. Whether Parts have been specified for all possible Option combinations that are relevant for the module, and whether process definition has consumed all of these for the module.
Anup Jain has authored an excellent article on product architecture breakdown and product engineering that discusses these aspects in further depth.
Part Master and BOM Management
Data that drive the most business impactful activities of an enterprise are often referred to as Master Data. In industries that manufacture and sell products, data that define the content and configuration of these products is central to the Master Data and is referred to as the Product Master. The Product Master is primarily driven by a Part Bill-of-Materials (BOM) and drives activities such as design, engineering mock-ups, prototypes, production, procurement, finance, short and long term planning and forecasting – activities that directly impact the top and bottom lines of the enterprise. A ‘high definition’ Product Master is richly qualified with context-relevant supporting information. Easy inline access to 3D visualization, design, manufacturing, procurement, service, or other relevant documentation makes the Product Master very ‘visual’ and fit for purpose.The availability of a high definition Product Master on demand accelerates operational decisions and activity, thus providing a competitive edge to the business.
With Integrated Product Definition, Teamcenter provides for Usage-based Part BOM management that works with Configuration and Architecture management principles described previously. The Usage-based model allows for independent declaration of use of Part in product and flexibility in deriving a context that is fit for purpose.
Design Data Management
Managing design BOM data as product size and complexity grows is a significant challenge faced by many firms today. Enabling multiple teams to work concurrently on designs, allowing for flexible organization and efficient set up of work context is a priority in almost all cases. Providing for independent lifecycle for the Designs while maintaining associativity to the Product context, including configuration and Part data, is essential to allowing decoupled yet coordinated authoring of the whole product definition.
With Integrated Product Definition, Teamcenter provides for Component-based Design management that is in step with Configuration, Architecture and Part management techniques described previously. In this article by Kaushik Amin, he explores design data management challenges and the IPD approach to a next generation PLM BOM solution.
Coordinated Change Management
In a product data rich environment, the authoring of change proposals can move to a different ‘latitude’. No longer do change proposals need to be confined to ‘hanging paper’ type vehicles. Authoring object based rich change proposals allows for a proposer to directly access product data and ‘mark-up’ the proposed change directly on the business objects to communicate very literally the intent of the proposal. This allows for richer communication up and downstream – from the initiator to the implementer, greater participation of the enterprise in the core engineering change, and traceability of engineering changes back to the proposals that initiated these while referencing the actual engineering data involved.
Authoring and fully evaluating the impact of a change across all disciplines requires a level of ‘isolation’ of the change from public data that is used for daily operations. Considering multiple alternative implementation approaches and their respective impacts independently, comparing and contrasting, and deciding on one due to its merits with full traceability of signoffs from all stakeholders and owners, is an important business driver.
With Integrated Product Definition, Teamcenter provides for Rich Change Proposals and Change Isolation constructs that can help elevate the visibility and business impact of product definition change management processes.
Chris Scheffer has explored BOM change management in a very thoughtful article on the future of change management that can prove an interesting read to further explore these constructs.
That is Integrated Product Definition ‘in summary’. Other articles referenced already (and to follow in our IPD series) delve into the many facets of these technologies.
Now, for any given enterprise to consume all of these business process improvements at once is a significant challenge, if not a non-starter. Current IT landscapes are very fragmented, often with multiple systems satisfying each of the IPD process functions with at best lightweight integration between these. The thought here to consider is that these IPD technologies are coupled yet distinct and adoption of the whole can be in incremental phases depending on the business value and end state desired.
That’s all for now and more to follow for sure…
