Difference between revisions of "Product Systems Engineering"

From SEBoK
Jump to navigation Jump to search
m
m (Text replacement - "SEBoK v. 2.9, released 13 November 2023" to "SEBoK v. 2.9, released 20 November 2023")
 
(121 intermediate revisions by 12 users not shown)
Line 1: Line 1:
 +
----
 +
'''''Lead Authors:''''' ''Bud Lawson, Ricardo Pineda''
 +
----
 +
[[File:PPI.png|thumb|250px|right|<center>This knowledge area is graciously sponsored by PPI.<center>]]
 +
Product systems engineering (PSE) is at the core of the new product development process (NPDP) that is needed to successfully develop and deploy products into different market segments. A market can be consumer based (e.g., private enterprises or general consumers) or it can be public (not-for-profit). Public markets address the strategic needs of a country or region, such as military, healthcare, educational, transportation, and energy needs. NPDP has two significantly overlapping and integrated activities: 
  
Systems to be engineered can be of several kinds: product systems, service systems, enterprise systems, systems of systems, and so on. This article focuses on Product Systems Engineering (PSE). The other application areas of SE are covered in articles in Part 4 of SEBOK as listed here: [[Applications of Systems Engineering]].
+
#'''Systems engineering:''' This includes concept generation, engineering design/development, and deployment
 
+
#'''Market development:''' This includes market research, market analysis, product acceptance and market growth (diffusion), and rate of adoption
== Introduction ==
 
Product Systems Engineering (PSE) is at the core of the New Product Development Process (NPDP) needed to successfully develop and deploy products into different markets segments for either profit or non-profit.  The NPDP in addition to the engineering design also includes manufacturability/producibility, logistics and distribution, product quality, product disposal, conformance to standards, stakeholder’s value added and meeting customer’s expectations.  But the product opportunity must also take into account the internal enterprise competence and capabilities such as customer support, sales & marketing, maintenance and repair, personnel training, etc. 
 
 
 
To remain competitive enterprises need to understand the effects of the global economy, trends in industry, technology development needs and/or the effects of new technology breakthroughs, market segments creation and their expectations, and above all ever evolving customer expectations.  In the [[Product Systems Engineering Background]] article we introduce and discuss how the Products offered or to be offered should be directly related to the enterprise business objectives, the relationships between Product Development and PSE and a general discussion about different Product Types.
 
 
 
The [[Product as a System Fundamentals]] article describes the product elements and components, the support and sustainment functions, the integration of different specialty engineering and the role of SE in the product development.
 
 
 
As mentioned above, product launching and product offerings have close linkages to different business processes.  The major linkages are to Business Development, Marketing, Product Lines, Quality Management, Project Management, Operations Management, Supply Chain Management, etc; these and other topics are described in the [[Business Activities Related to Product Systems Engineering]] article.
 
  
Products arise when they are realized based upon a system definition.  So, Product System Engineering is producing this definition.  Realizing the system results in instances of the system that are either delivered to a specific acquirer (based upon an agreement) are offered directly to buyers and usersKey Aspects of PSE are discussed and include aspects such as: Acquired vs. Offered Products, Product Lifecycle & Adoption rates, Integrated Product Teams (IPTs) and Integrated Product Development Teams (IPDTs), product architectures, requirement and standards, etc.
+
NPDP also includes manufacturability/producibility, logistics and distribution, product quality, product disposal, conformance to standards, stakeholder’s value added, and meeting customer’s expectationsThe internal enterprise competence and capabilities such as customer support, sales & marketing, maintenance and repair, personnel training, etc., must also be taken into account.  
 
 
The last article, [[Product Systems Engineering Special Activities]], covers some of the special activities carried out by PSE during the different stages from concept to product deployment.
 
  
 
==Topics==
 
==Topics==
 
+
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics:  
The following topics are included in the product systems engineering knowledge area:
 
 
*[[Product Systems Engineering Background]]
 
*[[Product Systems Engineering Background]]
 
*[[Product as a System Fundamentals]]
 
*[[Product as a System Fundamentals]]
Line 24: Line 18:
 
*[[Product Systems Engineering Special Activities]]
 
*[[Product Systems Engineering Special Activities]]
  
== Creating Value ==
+
The [[Product Systems Engineering Background]] article discusses product types and the need for a product to be aligned with the business objectives of the enterprise. It also discusses the relationships between PSE, product development and technology development.
  
An Enterprise that produces some form of products must create value in the eyes of the customer, a value that exceeds the costs of that product.  This applies to both private and public enterprises operated for profit or not-for-profit.  The creation and delivery of products may be a result of an acquisition agreement or result of an offering directly to buyers or users.  
+
Various types of connections between product elements, and the concept of enabling systems are introduced in the [[Product as a System Fundamentals]] article. It also discusses product architecture, modeling, analysis, and integration with various specialty engineering areas.  
  
Ring (1998) defines a system value cycle with three levels that a systems approach must consider to deliver real world benefit. These three levels are stakeholder value, customer need (system problem situation or purpose), and system solution (or intervention). Value will only be fully realized when it is considered within the context of time, cost, and other resources appropriate to key stakeholders.
+
Product launching and product offerings have close linkages to different business processes. The major linkages are to business development, marketing, product lines, quality management, project management, operations management, supply chain management, etc. These and other topics are described in the [[Business Activities Related to Product Systems Engineering]] article.
  
'''Aligning product characteristics with associated operational activities'''
+
Products emerge when they are realized based upon a system definition. Realizing the system results in instances of the system that are either delivered as products to a specific acquirer (based upon an agreement) or are offered directly to buyers and users.  Key Aspects of PSE are discussed in the [[Product Systems Engineering Key Aspects]] article, which discusses aspects such as acquired vs. offered products, product lifecycle and adoption rates, integrated product teams (IPTs) and integrated product development teams (IPDTs), product architectures, requirements and standards, etc.
  
The user of a product views the product as an asset that they can utilize in their own systems of interest.  Thus, in supplying the product the expected form of operation (behavior or use) becomes a driving factor in determining the characteristics of the product.  In several contexts, in particular for military related products, the desired operational activities are termed CONOPS (Concept of Operations) and in the case of commercial enterprises the intended use of the system is described through some form of “Market Service Description” of the product.  The intended use of the product then is market/customer driven so the product characteristics must be aligned with the operational intent.
+
The last article, [[Product Systems Engineering Special Activities]], covers some of the special activities carried out by PSE during the different stages from concept through product deployment.
  
'''Architectures as basis for value assessment'''
+
== Key Terms and Concepts ==
  
Architectures can be used by enterprises to shift product development from individual products to an underlying product line architectures that incorporates the flexibility required by the enterprise to rapidly tailor new technologies and/or features to specific customer requirements.(Phillips 2001)  In determining the architecture of the product system various alternative designs (solutions) may arise.  Each of the architecture alternatives is to be evaluated with respect to its value contribution to end users and other stakeholders.
+
===Product===
  
'''Role of evaluation criteria in selection between product alternatives'''
+
A {{Term|Product (glossary)|product}} is an artifact that is created by some person or by some process such as a manufacturing process, software source code compilation and integration, building construction, creative writing process, or data processing.
  
In assessing the product system value one must consider what measures are to be used to determine the “goodness” of the product alternatives (alternative architectures and technologies) with respect to quality, efficiency, performance, cost, schedule and most importantly the coverage provided in meeting the customer’s requirement  or market opportunity.
+
In general, a business product is defined as a ''thing produced by labor or effort'', or the ''result of an act or a process''. It stems from the verb ''produce'', from the Latin ''prōdūce(re) (to) lead or bring forth''. Since 1575, the word ''product'' has referred to anything produced, and since 1695, the word ''product'' has referred to ''a thing or things produced''.
  
'''Role of tradeoffs in maximizing value'''
+
In economics and commerce, products belong to a broader category of ''goods''. The economic meaning of the word ''product'' was first used by political economist Adam Smith. In marketing, a product is anything that can be offered to a market that might satisfy a want or a need. In retail industries, products are called merchandise. In manufacturing, products are purchased as raw materials and sold as finished goods. Commodities are usually raw materials, such as metals and agricultural products, but a commodity can also be anything widely available in the open market. In project management, products are the formal definitions of the project deliverables that make up or contribute to delivering the objectives of the project. In insurance, the policies are considered products offered for sale by the insurance company that created the contract.
  
The evaluation of alternatives must include the tradeoffs between conflicting properties.  For example, in striving for superior quality and efficiency tradeoffs must be made with respect to schedule and cost.  See discussion of measurement in Part 3.  Tradeoffs are made during the different stages of the development process: at the product/product system level at the subsystem and architecture definition level and at the technology level.  (Blanchard and Fabrycky 2011)
+
===Product System===
  
There are a variety of methods for performing tradeoff analysis such as: utility theory, analytic hierarchical process and the Pugh selection method, multi-objective decision, multi-attribute utility analysis, multi-variate analysis, and others. For software, the Software Engineering Institute provides a method entitled The Architecture Tradeoff Analysis Method (ATAM) (Kazman et al., 2000) for evaluating software architectures relative to quality attribute goals. ATAM evaluations expose architectural risks that potentially inhibit the achievement of an organization's business goals. The ATAM gets its name because it not only reveals how well architecture satisfies particular quality goals, but also provides insight into how those quality goals interact with each other—how they trade off against each other.
+
A {{Term|Product System (glossary)|product system}} is the combination of end products and the enabling products for those end products. This concept of a product system is illustrated in Figure 1. In the [[ANSI/EIA 632|ANSI/EIA 632-2003]] standard, just the term ''system'' is used, but the scope of the standard is clearly restricted to product systems.
  
'''Expanding role of software in creation of product value'''
+
[[File:PSE_Intro_Fig1.png|400px|thumb|center|'''Figure 1. Product System Components (ANSI/EIA 632).''' Excerpts from "Processes for Engineering a System" (EIA-632), Copyright © (1999) TechAmerica.  All Rights Reserved. Reprinted by Permission. All other rights are reserved by the copyright owner.]]
  
Software has had an increasing role in providing the desired functionality in many products.  The embedding of software in many types of products (such as vehicles of all types, production equipment, etc.) accounts for an ever increasing portion of the product functionality. The movement toward the internet of “things” where sensing and activating functions are incorporated is now starting to permeate.
+
The end product can also be considered as a system with its own elements or subsystems, each of which has its own enabling products as illustrated in Figure 2. The product development process usually focuses only on the engineering of the end product. PSE is essential when the enabling products are by themselves complex or their relationship to the end product is complex. Otherwise, the use of a traditional product development process is sufficient.
The use of various software products in providing service is described in Service Systems Engineering KA.
+
 +
[[File:PSE_Intro_Fig2.png|700px|center|thumb|'''Figure 2. End Products and Enabling Products (ANSI/EIA 632).''' Excerpts from "Processes for Engineering a System" (EIA-632), Copyright © (1999) TechAmerica.  All Rights Reserved. Reprinted by Permission. All other rights are reserved by the copyright owner.]]
  
== Products, Services & Enterprises ==
+
===Product Realization System===
  
NPDP is the complete process to bring a new product and/or product system to a market; a market as used here can be consumer based (e.g., private enterprises and or general consumers) or it can be public (not-for-profit) that addresses the strategic needs of a country/region (military, healthcare, educational, transportation, energy, etc.).
+
The product realization system is a related system that enables the ''realization'' of the product system. It consists of ''all the resources to be applied in causing the Intervention System [i.e., the product system, in this case] to be fully conceived, developed, produced, tested, and deployed'' (Martin 2004).  Lawson (2010) refers to this as a respondent system in the {{Term|System Coupling Diagram (glossary)|system coupling diagram}}. The intervention system is the system that is to be realized (or conceived and brought into being) in order to address some perceived problem in the context as shown in Figure 3.
  
NPDP has two highly overlapping and integrated activities: Systems Engineering (concept generation, engineering design/development, and deployment) and Market Development (Market research, market analysis, product acceptance and market growth (diffusion) and/or rate of adoption).  
+
[[File:PSE_Intro_Fig3.png|600px|thumb|center|'''Figure 3. Realization System That Creates the Intervention to Solve a Problem (Martin 2004).''' Reprinted with Permission of Aerospace. All other rights are reserved by the copyright owner.]]
  
Hence, Product SE is very much in line with traditional SE as captured in most textbooks on the subject, such as (Wasson 2006), (Sage and Rouse 2009), (Blanchard and Fabrycky 2011). However, these don’t cover the full breadth of Product SE since they tend to focus on hardware and software products only. Other kinds of products to be engineered include such things as personnel, facilities, data, materials, processes, techniques, procedures, media, and so on (Martin 1997) and (Lawson 2010). A product is not necessarily a tangible item. Intangible items include things like data, rules, tactics, techniques, procedures and organizations. More on the distinctions between the various kinds of products is provided in the [[Product SE Background]] article.  
+
The realization system can be a service system (as described in knowledge area [[Service Systems Engineering]]) or an enterprise system (as described in the knowledge are [[Enterprise Systems Engineering]]). When the realization system is a service system, then the service could partially realize the system by just designing the product system without developing or creating it. This design service system can pass the design to a manufacturing service system that turns the design into a physical artifact. Usually an enterprise is established to orchestrate the disparate services into a cohesive whole that is efficiently and effectively performed to achieve the strategic goals of that enterprise.
  
Some product system domains are data-intensive (e.g., transportation systems), some are facilities-intensive (e.g., chemical processing plant), some are hardware-intensive (national defense systems), some are technique-intensive (e.g., search and rescue system), and so on.  Most product systems are a composite (or mix) of several different kinds of products that must be fully integrated to realize the complete value added potential for the various stakeholders.
+
The product realization system utilizes a product realization process as described in (Magrab et al 2010) or a product development process as described in (Wheelwright and Clark 1992).
  
When compared to Service SE and Enterprise SE, Product SE has some unique considerations to keep in mind:
+
===Product Sustainment System===
  
• Often a product is part of a product line where both the product line and the products that make up that product line must be engineered in synch with each other.  
+
When the realization system delivers the product system into its intended environment, the product often needs a set of services to keep that product operational. This other system, when needed, is called the product sustainment system. It consists of various enabling products and operational services. The sustainment system in relation to the realization system and the deployed product system is illustrated in Figure 4. Notice that the realization may need to develop or modify the sustainment for the particular intervention (product) system under development.
  
• Products are often composed of parts and subassemblies produced by several suppliers. This entails the need to work closely with supply chain management to ensure a successful product offering.
+
[[File:PSE_Intro_Fig4.png|600px|thumb|center|'''Figure 4. Product Sustainment System in Support of the Deployed Product System (Martin 2004).''' Reprinted with Permission of Aerospace. All other rights are reserved by the copyright owner.]]
  
• Large, complex products often require a long and complicated series of steps for assembly, integration and testDuring integration many of the key assumptions made during the initial product design will be challenged.
+
== Product Systems Engineering, Service Systems Engineering and Enterprise Systems Engineering ==
 +
 
 +
PSE is in line with Traditional Systems Engineering (TSE) as captured in most textbooks on the subject, such as Wasson (2006), Sage and Rouse (2009), and Blanchard and Fabrycky (2011). However, they do not cover the full breadth of PSE since they tend to focus on hardware and software products only. Other kinds of products to be engineered include personnel, facilities, data, materials, processes, techniques, procedures, and media (Martin 1997; Lawson 2010). Further discussions on the distinctions between the various kinds of products is provided in the [[Product Systems Engineering Background]] article. Product system domains could be data-intensive (e.g. transportation system), facilities-intensive (e.g. chemical processing plant), hardware-intensive (e.g. defense systems), or technique-intensive (e.g. search and rescue system)Most product systems are a composite of several different kinds of products that must be fully integrated to realize the complete value-added potential for the different stakeholders.
  
• Products will usually require some sort of certification as to their safety or other factors like energy conservation, environmental compatibility, and so on. Electronic products must often undergo certification testing to ensure electromagnetic compatibility and limited electronic emissions into the radio frequency spectrum. Transportation products often undergo a certification program for safe operations.
+
When compared to Service Systems Engineering (SSE) and Enterprise Systems Engineering (ESE), PSE has some unique considerations:
  
• Products often have a complicated distribution network since they don’t always get delivered directly to the end user. There could be depots, warehousing, overseas transport, wholesalers, dealers, retail stores, and the like as part of this distribution chain. This network complicates the ways that the product is delivered, maintained and supported.
+
* Often a product is part of a product line where both the product line and the products that make up that product line must be engineered simultaneously.  
  
• Product systems must be engineered in concert with the so-called “realization” system and the sustainment system. Sometimes it is necessary to make tradeoffs between the features and functions of the product system and those in the realization and sustainment systems.
+
* Products are often composed of parts and sub-assemblies produced by several suppliers. This entails the need to work closely with the supply chain to ensure a successful product offering.
  
These considerations and others will be addressed in the articles covered in this KA. One of the responsibilities of Enterprise SE is to manage these various considerations across multiple product lines across the enterprise while maximizing profits and/or customer satisfaction. Service SE is often dependent on the products resulting from the Product SE. A service will often be based on a product “infrastructure” that includes things like data processing hardware and software, data storage, data entry and display devices, service delivery facilities and techniques, service desk technicians, maintenance personnel, service offering catalogs and printed materials, and so on. Each of these products in the service infrastructure may need to be separately engineered using its own Product SE lifecycle.
+
* Large complex products often require a lengthy and complicated series of steps for assembly, integration and test. During integration, many of the key assumptions made during the initial product design could be challenged.
  
== Key Terms and Concepts ==
+
* Products will usually require certification as to their safety or other factors like energy conservation and environmental compatibility. Electronic products often require certification to ensure electromagnetic compatibility and limited electronic emissions into the radio frequency spectrum. Transportation products require certification for safe operations.
  
'''Product'''
+
* Products often have a complicated distribution network since they are not always developed where the end user may require it. There could be depots, warehouses, multi-modal transportation, wholesalers, dealers, and retail stores as part of this distribution network. This introduces challenges in delivery, maintenance and support of the product.
  
A product is an artifact that has been created by someone or by some process. This artifact is “produced” in some manner such as by manufacturing process, software source code compilation and integration, operator training program, building construction, creative writing process, data processing, and so on.  
+
* Products must be engineered along with the realization system and the sustainment system. Sometimes it is necessary to make tradeoffs between the features and functions of the product system, the realization system and the sustainment system.
  
A “business” product can be thought of as follows:
+
These considerations and others will be addressed in the articles under this knowledge area. One of the responsibilities of ESE is to manage these various considerations across multiple product lines across the enterprise while maximizing profits and customer satisfaction. SSE is often dependent on the products resulting from the PSE. A service will often be based on a product infrastructure that includes elements like data processing, hardware, software, data storage, data entry devices, display devices, service delivery facilities and techniques, service desk technicians, maintenance personnel, service offering catalogs and printed materials. Each of these products in the service infrastructure may need to be separately engineered using its own PSE lifecycle.
  
In general, the product is defined as a "thing produced by labor or effort" or the "result of an act or a process", and stems from the verb produce, from the Latin prōdūce(re) '(to) lead or bring forth'. Since 1575, the word "product" has referred to anything produced. Since 1695, the word has referred to "thing or things produced".
+
== Creating Value ==
  
In economics and commerce, products belong to a broader category of goods. The economic meaning of product was first used by political economist Adam Smith. In marketing, a product is anything that can be offered to a market that might satisfy a want or need. In retailing, products are called merchandise. In manufacturing, products are purchased as raw materials and sold as finished goods.  
+
An enterprise that creates products must also create value that exceeds the cost of the product in the eyes of the customer. This applies to both for-profit and not-for-profit private and public enterprises. The creation and delivery of products may be the result of an acquisition agreement or an offering directly to buyers or users. To remain competitive, enterprises also need to understand the effects of the global economy, trends in industry, technology development needs, effects of new technology breakthroughs, market segments creation and their expectations, and most importantly, ever evolving customer expectations.
  
Commodities are usually raw materials such as metals and agricultural products, but a commodity can also be anything widely available in the open market. In project management, products are the formal definition of the project deliverables that make up or contribute to delivering the objectives of the project. In insurance, the policies are considered products offered for sale by the insurance company that created the contract. (http://en.wikipedia.org/wiki/Product_business)
+
Ring (1998) defines a system value cycle with three levels that a systems approach must consider to deliver real world benefit:
 +
# stakeholder value
 +
# customer need
 +
# system solution
 +
Value will be fully realized only when it is considered within the context of time, cost, and other resources appropriate to key stakeholders.
  
'''Product System'''
+
===Aligning product characteristics with associated operational activities===
  
A product system is the combination of end products plus the enabling products for those end products (ANSI/EIA 632 1998). This concept of a product system is illustrated below. In the EIA standard, the term “system” is used by itself but the scope of the standard is clearly restricted to product systems.
+
The user of a product views the product as an asset that can be utilized in one's own systems of interest (Lawson 2010). Thus, in supplying the product, the expected form of operation becomes a driving factor in determining the characteristics of the product. In several contexts, in particular for military related products, the desired operational activities are termed {{Term|Concept of Operations (ConOps) (glossary)|concept of operations}} (ConOps) and in the case of commercial enterprises the intended use of the system is described through some form of ''Market Service Description'' of the product.  The intended use of the product is market/customer driven and so the product characteristics must be aligned with the operational intent.
  
 +
===Architectures as basis for value assessment===
  
   
+
Architectures can be used by enterprises to shift product development from individual products to an underlying product line architecture that incorporates the flexibility required by the enterprise to rapidly tailor new technologies and features to specific customer requirements (Phillips 2001). In determining the architecture of the product system, various alternative designs may arise.  Each of the architecture alternatives is to be evaluated with respect to its value contribution to end users and other stakeholders.  
Figure 1. Product System Components (ANSI/EIA 632 1998)
 
  
The end product itself can also be considered as a system with its own elements (or subsystems), each of which has its own enabling products as illustrated below. The product development process by itself usually focuses only on the engineering of the end product. Product SE is essential when the enabling products are complex themselves or their relationship to the end product is complex. Otherwise, the use of a traditional product development process by itself is warranted.
+
===Role of evaluation criteria in selection between product alternatives===
  
 +
In assessing the product system value, one must consider the measures that are to be used to determine the ''goodness'' of the product alternatives (alternative architectures and technologies) with respect to producibility, quality, efficiency, performance, cost, schedule and most importantly, the coverage provided in meeting the customer’s requirement or market opportunity.
  
+
===Role of tradeoffs in maximizing value===
Figure 2. End Products and Enabling Products (ANSI/EIA 632 1998)
 
  
'''Product Realization System'''
+
The evaluation of alternatives must include the tradeoffs between conflicting properties.  For example, in striving for superior quality and efficiency, tradeoffs must be made with respect to schedule and cost.  See article on [[Measurement]] in Part 3.  Tradeoffs are made during different stages of the development process: at the product or system level, at the subsystem and architecture definition level, and at the technology level (Blanchard and Fabrycky 2011).
  
There is a related system that enables the “realization” of the product system. The product realization system consists of “all the resources to be applied in causing the Intervention System [i.e., the product system, in this case] to be fully conceived, developed, produced, tested, and deployed” (Martin 2004)(Lawson 2010) refers to this as a Respondent System in the System Coupling Diagram.  The so-called Intervention System is the system that is to be conceived and brought into being (i.e., realized) in order to address some perceived problem in the context as shown in the figure below.
+
There are a variety of methods for performing tradeoff analysis such as: utility theory, analytic hierarchical process, the Pugh selection method, multi-objective decision, multi-attribute utility analysis, and multi-variate analysis. For software, the Software Engineering Institute (SEI) provides 'The Architecture Tradeoff Analysis Method (ATAM)' (Kazman et al., 2000) for evaluating software architectures relative to quality attribute goals. ATAM evaluations expose architectural risks that potentially inhibit the achievement of an organization's business goals. The ATAM not only reveals how well an architecture satisfies particular quality goals, but also provides insight into how those quality goals interact with each other and how they trade off against each other.
  
+
===Expanding role of software in creation of product value===
 
 
Figure 3. Realization system that creates the intervention to solve a problem (Martin 2004)
 
 
 
The realization system itself can be a service system (as described in Service SE article, put reference here) or an enterprise system (as described in the Enterprise SE article, put reference here). When the realization system is a service system, then the service could be as simple as a design service where the product system is only partially realized (up to the point of having a design but not yet having a physical reality). This design service system can pass the design to a manufacturing service system that turns the design into a physical artifact. Usually an enterprise is established to orchestrate the disparate services into a cohesive whole that are efficiently and effectively performed to achieve the strategic goals of that enterprise.
 
  
The product realization system (i.e., the enterprise) utilizes a product realization process (PRP) like the one described in (Magrab et al 2010) or the product development process (PDP) like the one described in (http://en.wikipedia.org/wiki/New_product_development) or in (Wheelwright and Clark 1992).
+
Software has an increasing role in providing the desired functionality in many products. The embedding of software in many types of products (such as transportation vehicles, home appliance, and production equipment) accounts for an ever-increasing portion of the product functionality.  The current trend is the development of a network of systems that incorporate sensing and activating functions. The use of various software products in providing service is described in the [[Service Systems Engineering]] knowledge area.
 
 
'''Product Sustainment System'''
 
 
 
When the realization system delivers the product system into its intended environment, the product often needs a set of services to keep that product operating properly. This other system, when needed, is called the product sustainment system. It consists of the various enabling products and operational services as described in section 2.2 (put link here). The sustainment system in relation to the realization system and the deployed product system is illustrated in the figure below. Notice that the realization may need to develop or modify the sustainment for the particular intervention (product) system under development.
 
 
 
 
 
 
FIGURE 4. Product sustainment system in support of the deployed product system (Martin 2004)
 
  
 
==References==  
 
==References==  
 
    
 
    
 
===Works Cited===
 
===Works Cited===
ANSI/EIA 632. 1999. Electronic Industries Alliance.  Government Electronics and Information Technology Association. Engineering Department.
+
ANSI/EIA. 2003. ''[[ANSI/EIA 632|Processes for Engineering a System]]''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA). ANSI/EIA 632‐2003.
  
Blanchard, B. and Fabrycky, W. 2011. “Systems Engineering and Analysis”, Prentice Hall International Series in Industrial and Systems Engineering; ISBN 978-0-13-221735-4
+
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice Hall.
  
ISO/IEC 42010. Architecture Description
+
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and software engineering - Architecture description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.
  
Kazman, R, Klein, M., and Clements, P. 2000. ATAM; Method for Architecture Evaluation, Technical Report , CMU/SEI-2000-TR-004, ESC-TR-2000-004.
+
Kazman, R., M. Klein, and P. Clements. 2000. ''ATAM: Method for Architecture Evaluation''. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). CMU/SEI-2000-TR-004, ESC-TR-2000-004.
  
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.
+
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications.
  
Magrab, E., Gupta S., McCluskey, P., and Sandborn, P. 2010. Integrated Product and Process Design and Development- The Product Realization Process. CRC Press.
+
Magrab, E., S. Gupta, P. McCluskey, and P. Sandborn. 2010. ''[[Integrated Product and Process Design and Development]] - The Product Realization Process''. Boca Raton, FL, USA: CRC Press.
  
Martin, J. 1997. Systems Engineering Guidebook: A process for developing systems and products. CRC Press.
+
Martin, J.N. 1997. ''Systems Engineering Guidebook: A process for developing systems and products'', 1st ed. Boca Raton, FL, USA: CRC Press.
  
Martin, J. 2004. The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems. INCOSE Symposium.
+
Martin, J. 2004. "[[The Seven Samurai of Systems Engineering]]: Dealing with the Complexity of 7 Interrelated Systems." Proceedings of the International Council on Systems Engineering (INCOSE) International Symposium, 2004, Toulouse, France.
  
Phillips, F. 2001. Market-oriented Technology Management- Innovating for Profit in Entrepreneurial Times. Springer-Verlag Berlin. ISBN 3-540-41258-1
+
Phillips, F. 2001. ''Market-oriented Technology Management - Innovating for Profit in Entrepreneurial Times''. Berlin, Germany: Springer-Verlag.  
  
Pugh, S, 1990. Total Design: Integrated Methods for Successful Product Engineering. Prentice Hall. ISBN-10: 0201416395, ISBN-13: 978-0201416398.
+
Pugh, S. 1990. ''Total Design: Integrated Methods for Successful Product Engineering''. Upper Saddle River, NJ, USA: Prentice Hall.  
  
Ring, J. 1998. A Value Seeking Approach to the Engineering of Systems. Proceedings of the IEEE Conference on Systems, Man, and Cybernetics. p. 2704-2708.
+
Ring, J. 1998. "A Value Seeking Approach to the Engineering of Systems." Proceedings of the IEEE Conference on Systems, Man, and Cybernetics, 1998, San Diego, CA, USA. p. 2704-2708.
  
Sage, A. and Rouse, W. 2009. Handbook of Systems Engineering and Management. Wiley-Interscience.
+
Sage, A., and W. Rouse. (eds.) 1999. ''Handbook of Systems Engineering and Management''. Hoboken, NJ, USA: John Wiley and Sons, Inc.
  
Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons.  
+
Wasson, C.S. 2006. ''[[System Analysis, Design, and Development]]''. New York, NY, USA: John Wiley & Sons.
  
Wheelwright, S. and Clark, K. 1992. Managing New Product and Process Development: Text and Cases. Free Press.
+
Wheelwright, S., and K. Clark. 1992. ''Managing New Product and Process Development: Text and Cases''. Columbus, OH, USA: Free Press.
  
 
===Primary References===
 
===Primary References===
ANSI/EIA 632. 1999. Electronic Industries Alliance. Government Electronics and Information Technology Association. Engineering Department.
+
ANSI/EIA. 2003. ''[[ANSI/EIA 632|Processes for Engineering a System]]''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA). ANSI/EIA 632‐2003.
  
Blanchard,B. and Fabrycky, W. 2011. Systems Engineering and Analysis. Prentice Hall International Series in Industrial and Systems Engineering. ISBN 978-0-13-221735-4
+
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice Hall.
  
Magrab, E., Gupta S., McCluskey, P., and Sandborn, P. 2010. Integrated Product and Process Design and Development- The Product Realization Process. CRC Press
+
Magrab, E., S. Gupta, P. McCluskey, and P. Sandborn. 2010. ''[[Integrated Product and Process Design and Development]] - The Product Realization Process''. Boca Raton, FL, USA: CRC Press.
  
Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons.  
+
Martin, J. 2004. "[[The Seven Samurai of Systems Engineering]]: Dealing with the Complexity of 7 Interrelated Systems." Proceedings of the International Council on Systems Engineering (INCOSE) International Symposium, 2004, Toulouse, France.
 +
 
 +
Wasson, C.S. 2006. ''[[System Analysis, Design, and Development]]''. New York, NY, USA: John Wiley & Sons.
  
 
===Additional References===
 
===Additional References===
ISO/IEC 42010. Architecture Description
+
None.
  
Kazman, R, Klein, M., and Clements, P. 2000. ATAM; Method for Architecture Evaluation, Technical Report. CMU/SEI-2000-TR-004, ESC-TR-2000-004.
+
----
 
+
<center>[[Applications of Systems Engineering|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Product Systems Engineering Background|Next Article >]]</center>
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.
 
 
 
Martin, J. 1997. Systems Engineering Guidebook: A process for developing systems and products. CRC Press.
 
 
 
Martin, J. 2004. The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems. INCOSE Symposium 2004.
 
 
 
Phillips, F. 2001. Market-oriented Technology Management- Innovating for Profit in Entrepreneurial Times. Springer-Verlag Berlin. ISBN 3-540-41258-1
 
  
Pugh, S, 1990. Total Design: Integrated Methods for Successful Product Engineering. Prentice Hall. ISBN-10: 0201416395, ISBN-13: 978-0201416398.
+
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
 
 
Ring, J., 1998. A Value Seeking Approach to the Engineering of Systems. Proceedings of the IEEE Conference on Systems, Man, and Cybernetics. p. 2704-2708.
 
 
 
Sage, A. and Rouse, W. 2009. Handbook of Systems Engineering and Management. Wiley-Interscience.
 
 
 
Wheelwright, S. and Clark, K. 1992. Managing New Product and Process Development: Text and Cases. Free Press.
 
 
 
 
 
----
 
<center>[[Applications of Systems Engineering|<- Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Service Systems Engineering|Next Article ->]]</center>
 
  
 
[[Category:Part 4]][[Category:Knowledge Area]]
 
[[Category:Part 4]][[Category:Knowledge Area]]
 
 
{{5comments}}
 

Latest revision as of 22:14, 18 November 2023


Lead Authors: Bud Lawson, Ricardo Pineda


This knowledge area is graciously sponsored by PPI.

Product systems engineering (PSE) is at the core of the new product development process (NPDP) that is needed to successfully develop and deploy products into different market segments. A market can be consumer based (e.g., private enterprises or general consumers) or it can be public (not-for-profit). Public markets address the strategic needs of a country or region, such as military, healthcare, educational, transportation, and energy needs. NPDP has two significantly overlapping and integrated activities:

  1. Systems engineering: This includes concept generation, engineering design/development, and deployment
  2. Market development: This includes market research, market analysis, product acceptance and market growth (diffusion), and rate of adoption

NPDP also includes manufacturability/producibility, logistics and distribution, product quality, product disposal, conformance to standards, stakeholder’s value added, and meeting customer’s expectations. The internal enterprise competence and capabilities such as customer support, sales & marketing, maintenance and repair, personnel training, etc., must also be taken into account.

Topics

Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics:

The Product Systems Engineering Background article discusses product types and the need for a product to be aligned with the business objectives of the enterprise. It also discusses the relationships between PSE, product development and technology development.

Various types of connections between product elements, and the concept of enabling systems are introduced in the Product as a System Fundamentals article. It also discusses product architecture, modeling, analysis, and integration with various specialty engineering areas.

Product launching and product offerings have close linkages to different business processes. The major linkages are to business development, marketing, product lines, quality management, project management, operations management, supply chain management, etc. These and other topics are described in the Business Activities Related to Product Systems Engineering article.

Products emerge when they are realized based upon a system definition. Realizing the system results in instances of the system that are either delivered as products to a specific acquirer (based upon an agreement) or are offered directly to buyers and users. Key Aspects of PSE are discussed in the Product Systems Engineering Key Aspects article, which discusses aspects such as acquired vs. offered products, product lifecycle and adoption rates, integrated product teams (IPTs) and integrated product development teams (IPDTs), product architectures, requirements and standards, etc.

The last article, Product Systems Engineering Special Activities, covers some of the special activities carried out by PSE during the different stages from concept through product deployment.

Key Terms and Concepts

Product

A productproduct is an artifact that is created by some person or by some process such as a manufacturing process, software source code compilation and integration, building construction, creative writing process, or data processing.

In general, a business product is defined as a thing produced by labor or effort, or the result of an act or a process. It stems from the verb produce, from the Latin prōdūce(re) (to) lead or bring forth. Since 1575, the word product has referred to anything produced, and since 1695, the word product has referred to a thing or things produced.

In economics and commerce, products belong to a broader category of goods. The economic meaning of the word product was first used by political economist Adam Smith. In marketing, a product is anything that can be offered to a market that might satisfy a want or a need. In retail industries, products are called merchandise. In manufacturing, products are purchased as raw materials and sold as finished goods. Commodities are usually raw materials, such as metals and agricultural products, but a commodity can also be anything widely available in the open market. In project management, products are the formal definitions of the project deliverables that make up or contribute to delivering the objectives of the project. In insurance, the policies are considered products offered for sale by the insurance company that created the contract.

Product System

A product systemproduct system is the combination of end products and the enabling products for those end products. This concept of a product system is illustrated in Figure 1. In the ANSI/EIA 632-2003 standard, just the term system is used, but the scope of the standard is clearly restricted to product systems.

Figure 1. Product System Components (ANSI/EIA 632). Excerpts from "Processes for Engineering a System" (EIA-632), Copyright © (1999) TechAmerica. All Rights Reserved. Reprinted by Permission. All other rights are reserved by the copyright owner.

The end product can also be considered as a system with its own elements or subsystems, each of which has its own enabling products as illustrated in Figure 2. The product development process usually focuses only on the engineering of the end product. PSE is essential when the enabling products are by themselves complex or their relationship to the end product is complex. Otherwise, the use of a traditional product development process is sufficient.

Figure 2. End Products and Enabling Products (ANSI/EIA 632). Excerpts from "Processes for Engineering a System" (EIA-632), Copyright © (1999) TechAmerica. All Rights Reserved. Reprinted by Permission. All other rights are reserved by the copyright owner.

Product Realization System

The product realization system is a related system that enables the realization of the product system. It consists of all the resources to be applied in causing the Intervention System [i.e., the product system, in this case] to be fully conceived, developed, produced, tested, and deployed (Martin 2004). Lawson (2010) refers to this as a respondent system in the system coupling diagramsystem coupling diagram. The intervention system is the system that is to be realized (or conceived and brought into being) in order to address some perceived problem in the context as shown in Figure 3.

Figure 3. Realization System That Creates the Intervention to Solve a Problem (Martin 2004). Reprinted with Permission of Aerospace. All other rights are reserved by the copyright owner.

The realization system can be a service system (as described in knowledge area Service Systems Engineering) or an enterprise system (as described in the knowledge are Enterprise Systems Engineering). When the realization system is a service system, then the service could partially realize the system by just designing the product system without developing or creating it. This design service system can pass the design to a manufacturing service system that turns the design into a physical artifact. Usually an enterprise is established to orchestrate the disparate services into a cohesive whole that is efficiently and effectively performed to achieve the strategic goals of that enterprise.

The product realization system utilizes a product realization process as described in (Magrab et al 2010) or a product development process as described in (Wheelwright and Clark 1992).

Product Sustainment System

When the realization system delivers the product system into its intended environment, the product often needs a set of services to keep that product operational. This other system, when needed, is called the product sustainment system. It consists of various enabling products and operational services. The sustainment system in relation to the realization system and the deployed product system is illustrated in Figure 4. Notice that the realization may need to develop or modify the sustainment for the particular intervention (product) system under development.

Figure 4. Product Sustainment System in Support of the Deployed Product System (Martin 2004). Reprinted with Permission of Aerospace. All other rights are reserved by the copyright owner.

Product Systems Engineering, Service Systems Engineering and Enterprise Systems Engineering

PSE is in line with Traditional Systems Engineering (TSE) as captured in most textbooks on the subject, such as Wasson (2006), Sage and Rouse (2009), and Blanchard and Fabrycky (2011). However, they do not cover the full breadth of PSE since they tend to focus on hardware and software products only. Other kinds of products to be engineered include personnel, facilities, data, materials, processes, techniques, procedures, and media (Martin 1997; Lawson 2010). Further discussions on the distinctions between the various kinds of products is provided in the Product Systems Engineering Background article. Product system domains could be data-intensive (e.g. transportation system), facilities-intensive (e.g. chemical processing plant), hardware-intensive (e.g. defense systems), or technique-intensive (e.g. search and rescue system). Most product systems are a composite of several different kinds of products that must be fully integrated to realize the complete value-added potential for the different stakeholders.

When compared to Service Systems Engineering (SSE) and Enterprise Systems Engineering (ESE), PSE has some unique considerations:

  • Often a product is part of a product line where both the product line and the products that make up that product line must be engineered simultaneously.
  • Products are often composed of parts and sub-assemblies produced by several suppliers. This entails the need to work closely with the supply chain to ensure a successful product offering.
  • Large complex products often require a lengthy and complicated series of steps for assembly, integration and test. During integration, many of the key assumptions made during the initial product design could be challenged.
  • Products will usually require certification as to their safety or other factors like energy conservation and environmental compatibility. Electronic products often require certification to ensure electromagnetic compatibility and limited electronic emissions into the radio frequency spectrum. Transportation products require certification for safe operations.
  • Products often have a complicated distribution network since they are not always developed where the end user may require it. There could be depots, warehouses, multi-modal transportation, wholesalers, dealers, and retail stores as part of this distribution network. This introduces challenges in delivery, maintenance and support of the product.
  • Products must be engineered along with the realization system and the sustainment system. Sometimes it is necessary to make tradeoffs between the features and functions of the product system, the realization system and the sustainment system.

These considerations and others will be addressed in the articles under this knowledge area. One of the responsibilities of ESE is to manage these various considerations across multiple product lines across the enterprise while maximizing profits and customer satisfaction. SSE is often dependent on the products resulting from the PSE. A service will often be based on a product infrastructure that includes elements like data processing, hardware, software, data storage, data entry devices, display devices, service delivery facilities and techniques, service desk technicians, maintenance personnel, service offering catalogs and printed materials. Each of these products in the service infrastructure may need to be separately engineered using its own PSE lifecycle.

Creating Value

An enterprise that creates products must also create value that exceeds the cost of the product in the eyes of the customer. This applies to both for-profit and not-for-profit private and public enterprises. The creation and delivery of products may be the result of an acquisition agreement or an offering directly to buyers or users. To remain competitive, enterprises also need to understand the effects of the global economy, trends in industry, technology development needs, effects of new technology breakthroughs, market segments creation and their expectations, and most importantly, ever evolving customer expectations.

Ring (1998) defines a system value cycle with three levels that a systems approach must consider to deliver real world benefit:

  1. stakeholder value
  2. customer need
  3. system solution

Value will be fully realized only when it is considered within the context of time, cost, and other resources appropriate to key stakeholders.

Aligning product characteristics with associated operational activities

The user of a product views the product as an asset that can be utilized in one's own systems of interest (Lawson 2010). Thus, in supplying the product, the expected form of operation becomes a driving factor in determining the characteristics of the product. In several contexts, in particular for military related products, the desired operational activities are termed concept of operationsconcept of operations (ConOps) and in the case of commercial enterprises the intended use of the system is described through some form of Market Service Description of the product. The intended use of the product is market/customer driven and so the product characteristics must be aligned with the operational intent.

Architectures as basis for value assessment

Architectures can be used by enterprises to shift product development from individual products to an underlying product line architecture that incorporates the flexibility required by the enterprise to rapidly tailor new technologies and features to specific customer requirements (Phillips 2001). In determining the architecture of the product system, various alternative designs may arise. Each of the architecture alternatives is to be evaluated with respect to its value contribution to end users and other stakeholders.

Role of evaluation criteria in selection between product alternatives

In assessing the product system value, one must consider the measures that are to be used to determine the goodness of the product alternatives (alternative architectures and technologies) with respect to producibility, quality, efficiency, performance, cost, schedule and most importantly, the coverage provided in meeting the customer’s requirement or market opportunity.

Role of tradeoffs in maximizing value

The evaluation of alternatives must include the tradeoffs between conflicting properties. For example, in striving for superior quality and efficiency, tradeoffs must be made with respect to schedule and cost. See article on Measurement in Part 3. Tradeoffs are made during different stages of the development process: at the product or system level, at the subsystem and architecture definition level, and at the technology level (Blanchard and Fabrycky 2011).

There are a variety of methods for performing tradeoff analysis such as: utility theory, analytic hierarchical process, the Pugh selection method, multi-objective decision, multi-attribute utility analysis, and multi-variate analysis. For software, the Software Engineering Institute (SEI) provides 'The Architecture Tradeoff Analysis Method (ATAM)' (Kazman et al., 2000) for evaluating software architectures relative to quality attribute goals. ATAM evaluations expose architectural risks that potentially inhibit the achievement of an organization's business goals. The ATAM not only reveals how well an architecture satisfies particular quality goals, but also provides insight into how those quality goals interact with each other and how they trade off against each other.

Expanding role of software in creation of product value

Software has an increasing role in providing the desired functionality in many products. The embedding of software in many types of products (such as transportation vehicles, home appliance, and production equipment) accounts for an ever-increasing portion of the product functionality. The current trend is the development of a network of systems that incorporate sensing and activating functions. The use of various software products in providing service is described in the Service Systems Engineering knowledge area.

References

Works Cited

ANSI/EIA. 2003. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA). ANSI/EIA 632‐2003.

Blanchard, B.S., and W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5th ed. Prentice Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice Hall.

ISO/IEC/IEEE. 2011. Systems and software engineering - Architecture description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.

Kazman, R., M. Klein, and P. Clements. 2000. ATAM: Method for Architecture Evaluation. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). CMU/SEI-2000-TR-004, ESC-TR-2000-004.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Magrab, E., S. Gupta, P. McCluskey, and P. Sandborn. 2010. Integrated Product and Process Design and Development - The Product Realization Process. Boca Raton, FL, USA: CRC Press.

Martin, J.N. 1997. Systems Engineering Guidebook: A process for developing systems and products, 1st ed. Boca Raton, FL, USA: CRC Press.

Martin, J. 2004. "The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems." Proceedings of the International Council on Systems Engineering (INCOSE) International Symposium, 2004, Toulouse, France.

Phillips, F. 2001. Market-oriented Technology Management - Innovating for Profit in Entrepreneurial Times. Berlin, Germany: Springer-Verlag.

Pugh, S. 1990. Total Design: Integrated Methods for Successful Product Engineering. Upper Saddle River, NJ, USA: Prentice Hall.

Ring, J. 1998. "A Value Seeking Approach to the Engineering of Systems." Proceedings of the IEEE Conference on Systems, Man, and Cybernetics, 1998, San Diego, CA, USA. p. 2704-2708.

Sage, A., and W. Rouse. (eds.) 1999. Handbook of Systems Engineering and Management. Hoboken, NJ, USA: John Wiley and Sons, Inc.

Wasson, C.S. 2006. System Analysis, Design, and Development. New York, NY, USA: John Wiley & Sons.

Wheelwright, S., and K. Clark. 1992. Managing New Product and Process Development: Text and Cases. Columbus, OH, USA: Free Press.

Primary References

ANSI/EIA. 2003. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA). ANSI/EIA 632‐2003.

Blanchard, B.S., and W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5th ed. Prentice Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice Hall.

Magrab, E., S. Gupta, P. McCluskey, and P. Sandborn. 2010. Integrated Product and Process Design and Development - The Product Realization Process. Boca Raton, FL, USA: CRC Press.

Martin, J. 2004. "The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems." Proceedings of the International Council on Systems Engineering (INCOSE) International Symposium, 2004, Toulouse, France.

Wasson, C.S. 2006. System Analysis, Design, and Development. New York, NY, USA: John Wiley & Sons.

Additional References

None.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023