PLM is Product Lifecycle Management, so like CM and RM domains, one might think that Product would be a class in the PLM domain.
However, while OSLC QM represents a Quality domain, it doesn't define a quality resource. Perhaps that is an omission in the OSLC QM spec though since the spec doesn't define what quality is, how its measured, or how it is assessed. It only defines the resources that might contribute to such an assessment. The QM spec defines for example TestCase, TestCaseExecutionRecord (a type/instance pattern), TestResult and verdict property. So we can know what tests pass or fail, what requirements might go unfulfilled as a result, and what change requests should not yet be considered done. But the OSLC QM spec doesn't actually define quality in a quantitative way. Perhaps that would provide some insight for the PLM spec.
Let's start by understanding what an OSLC PLM Part is and what it represents. Then explore Product Lifecycle Management. Then finally identify what we think a Product might be and what information it might contain, and what states may be in its lifecycle to see if these are needed, already covered by Part, or a new vocabulary term is needed.
Bill of Material - BOM
A fundamental concept in PLM the Bill of Material or BOM: An extensive list of raw materials (not the materials themselves), components, and instructions required to construct, manufacture, or repair a product or service.
An OSLC PLM Part is an element in a BOM. OSLC PLM Part and PartUsage are a means of formally defining a BOM hierarchy.
A bill of materials shows the relationship between the finished product and its components. It's useful for estimating the amount and cost of materials, planning purchases, ensuring the availability of parts, managing supply chains, and avoiding production delays.
- A bill of materials (BOM) is a source of information containing a list of items and instructions to design or manufacture a product.
- A bill of materials lists the finished product at the top, followed by individual components and materials.
- BOMs can be presented as an explosion display or an implosion display.
- The two main types of BOMs are manufacturing and engineering
- Engineering BOM: Defines the design of a finished product. This BOM is commonly based on a computer-aided design (CAD) drawing. More than one BOM may be created as part of product lifecycle management.
- Manufacturing BOM: Lists all assemblies and parts required to complete all manufacturing activities to make a finished item. It also defines the required packaging materials to send the product to the customer.
A manufacturing BOM is essential in designing enterprise resource planning (ERP) systems and in materials requirement planning (MRP).
Every line of the bill of materials includes the product code, part name, part number, part revision, description, quantity, unit of measure, size, length, weight, and specifications. It includes all alternative and substitute part numbers and parts contained in the drawing notes.
BOM displays its information in one of two ways: an explosion display or an implosion display. An explosion display defines an assembly at the highest level broken down into individual components and parts. A BOM implosion display links the lower-level parts to an assembly at the higher level.
A Maven POM file is a BOM for the parts of a software product, the versions to use, and how to build the product. The POM file is usually versioned with the source code it is delivering, because of the close relationship between the POM file and the software components used in the build. POM file properties can be used to produce variants of the product.
A package.json file is a BOM for a JavaScript module. A requirements.text file is a BOM for a Python module.
Every BOM has a root artifact, a Part that from the context of the BOM does not represent any PartUsage. This root part plays a unique role in the BOM, possibly representing the product or service being delivered, or the unit of exchange between a consumer and provider.
Product Lifecycle Management PLM
The process of designing, developing, creating, producing, and disposing of a manufactured product is called product life cycle management. The product life cycle details when a product is introduced to consumers until it's removed from the shelves. A BOM represents the elements of the product whose lifecycle is being managed.
The BOM isn't the elements of the product itself, but rather information about those elements that is used to manage the product's lifecycle.
Product
From the definition of PLM, we can see that Product is a central concept, representing some unit of delivery or exchange from a provider to a consumer. This implies some properties and behaviors that might not be shared by all Parts such as:
- Products have a value proposition, set of capabilities, and commitments to qualities of service intended to match consumer demand based on goals, needs, and expectations. Product Lifecycle Management is often about understanding and managing the demand/supply gap
- Products would have marketing materials
- They would have delivery schedules
- Sales information
- Availability and location information.
- etc.
Without Product, OSLC PLM is like OSLC Quality Management, it would capture the components of the domain, but not address its fundamental purpose or meaning.
Now any Product may be a deliverable from the perspective of the entity producing the product, and it may be a part of another assembly from the perspective of an entity consuming the product.
So clearly Product is a kind of Part. Does Product have sufficiently different properties, behavior and state that are of interest to the PLM stakeholders to define it as an OSLC PLM domain vocabulary term? Or is any Part essentially a product from the perspective of its PartUsages, and we would expect PLM vendors to extend Part with whatever properties are need? Are there any of these product properties that would be useful for OSLC PLM to standardize to facilitate the exchange of products between providers and consumers, a key integration point?
PLM is Product Lifecycle Management, so like CM and RM domains, one might think that Product would be a class in the PLM domain.
However, while OSLC QM represents a Quality domain, it doesn't define a quality resource. Perhaps that is an omission in the OSLC QM spec though since the spec doesn't define what quality is, how its measured, or how it is assessed. It only defines the resources that might contribute to such an assessment. The QM spec defines for example TestCase, TestCaseExecutionRecord (a type/instance pattern), TestResult and verdict property. So we can know what tests pass or fail, what requirements might go unfulfilled as a result, and what change requests should not yet be considered done. But the OSLC QM spec doesn't actually define quality in a quantitative way. Perhaps that would provide some insight for the PLM spec.
Let's start by understanding what an OSLC PLM Part is and what it represents. Then explore Product Lifecycle Management. Then finally identify what we think a Product might be and what information it might contain, and what states may be in its lifecycle to see if these are needed, already covered by Part, or a new vocabulary term is needed.
Bill of Material - BOM
A fundamental concept in PLM the Bill of Material or BOM: An extensive list of raw materials (not the materials themselves), components, and instructions required to construct, manufacture, or repair a product or service.
An OSLC PLM Part is an element in a BOM. OSLC PLM Part and PartUsage are a means of formally defining a BOM hierarchy.
A bill of materials shows the relationship between the finished product and its components. It's useful for estimating the amount and cost of materials, planning purchases, ensuring the availability of parts, managing supply chains, and avoiding production delays.
A manufacturing BOM is essential in designing enterprise resource planning (ERP) systems and in materials requirement planning (MRP).
Every line of the bill of materials includes the product code, part name, part number, part revision, description, quantity, unit of measure, size, length, weight, and specifications. It includes all alternative and substitute part numbers and parts contained in the drawing notes.
BOM displays its information in one of two ways: an explosion display or an implosion display. An explosion display defines an assembly at the highest level broken down into individual components and parts. A BOM implosion display links the lower-level parts to an assembly at the higher level.
A Maven POM file is a BOM for the parts of a software product, the versions to use, and how to build the product. The POM file is usually versioned with the source code it is delivering, because of the close relationship between the POM file and the software components used in the build. POM file properties can be used to produce variants of the product.
A package.json file is a BOM for a JavaScript module. A requirements.text file is a BOM for a Python module.
Every BOM has a root artifact, a Part that from the context of the BOM does not represent any PartUsage. This root part plays a unique role in the BOM, possibly representing the product or service being delivered, or the unit of exchange between a consumer and provider.
Product Lifecycle Management PLM
The process of designing, developing, creating, producing, and disposing of a manufactured product is called product life cycle management. The product life cycle details when a product is introduced to consumers until it's removed from the shelves. A BOM represents the elements of the product whose lifecycle is being managed.
The BOM isn't the elements of the product itself, but rather information about those elements that is used to manage the product's lifecycle.
Product
From the definition of PLM, we can see that Product is a central concept, representing some unit of delivery or exchange from a provider to a consumer. This implies some properties and behaviors that might not be shared by all Parts such as:
Without Product, OSLC PLM is like OSLC Quality Management, it would capture the components of the domain, but not address its fundamental purpose or meaning.
Now any Product may be a deliverable from the perspective of the entity producing the product, and it may be a part of another assembly from the perspective of an entity consuming the product.
So clearly Product is a kind of Part. Does Product have sufficiently different properties, behavior and state that are of interest to the PLM stakeholders to define it as an OSLC PLM domain vocabulary term? Or is any Part essentially a product from the perspective of its PartUsages, and we would expect PLM vendors to extend Part with whatever properties are need? Are there any of these product properties that would be useful for OSLC PLM to standardize to facilitate the exchange of products between providers and consumers, a key integration point?