Product Systems Engineering

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 markets segments. A market can be consumer based (e.g. private enterprises 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). NPDP has two significantly overlapping and integrated activities:

Systems Engineering: which includes concept generation, engineering design/development, and deployment
Market Development: which 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.

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 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, 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.

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

The Product Systems Engineering knowledge area contains the following topics:

Key Terms and Concepts

Product

A 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 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 has referred to thing or things produced.

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 a need. In retailing, 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 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 1998 standard, the just term system but the scope of the standard is clearly restricted to product systems.

Figure 1. Product System Components (ANSI/EIA 632 1998)

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 warranted.

Figure 2. End Products and Enabling Products (ANSI/EIA 632 1998)

Product Realization System

There is a related system that enables the realization of the product system, which is the product realization 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 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)

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)

Products, Services & Enterprises

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 do not 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.

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.

When compared to Service SE and Enterprise SE, Product SE has some unique considerations to keep in mind:

• 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.

• 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.

• Large, complex products often require a long and complicated series of steps for assembly, integration and test. During integration many of the key assumptions made during the initial product design will be challenged.

• Products will usually require 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.

• Products often have a complicated distribution network since they are not always delivered directly to the end user. There could be depots, warehousing, overseas transport, wholesalers, dealers, and retail stores as part of this distribution chain. This network complicates the ways that the product is delivered, maintained and supported.

• 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.

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.

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.

Creating Value

An Enterprise that produces 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.

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.

Aligning product characteristics with associated operational activities=

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.

Architectures as basis for value assessment

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.

Role of evaluation criteria in selection between product alternatives

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.

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 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)

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.

Expanding role of software in creation of product value

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 use of various software products in providing service is described in Service Systems Engineering KA.

References

Works Cited

ANSI/EIA 632. 1999. Electronic Industries Alliance. Government Electronics and Information Technology Association. Engineering Department.

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

ISO/IEC 42010. Architecture Description

Kazman, R, Klein, M., and Clements, P. 2000. ATAM; Method for Architecture Evaluation, Technical Report , 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.

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

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.

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.

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.

Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons.

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

Primary References

ANSI/EIA 632. 1999. Electronic Industries Alliance. Government Electronics and Information Technology Association. Engineering Department.

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

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

Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons.

Additional References

ISO/IEC 42010. Architecture Description

Kazman, R, Klein, M., and Clements, P. 2000. ATAM; Method for Architecture Evaluation, Technical Report. 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.

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.

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.

<- Previous Article | Parent Article | Next Article ->