Product Systems Engineering

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 users. Key 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.

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:

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.

Products, Services & Enterprises

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

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

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.

Key Terms and Concepts

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.

A “business” product can be thought of as follows:

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

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.

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)

Product System

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.

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.

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

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

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

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