Product Systems Engineering Background

Product Types

A system is by definition composed of components (also referred to as elements). The system itself is a component of a larger system, and you can also view each component as a system on its own.

A single component consists of products. Products need to be produced or acquired. Some can be acquired or procured as-is, without need for fabrication or modification. Others need to be engineered, and in some cases systems-engineered. (Martin 1997). Basic product types are depicted in the figure below.

Types of products are not limited to hardware or software. Many other types of products perform functions necessary to meet stakeholder needs. Some are only relevant to certain industries or domains, such as structures for civil engineering, or ships for shipping or the naval domain. Systems engineers must remember not to allocate the required behavior for a system to hardware and software elements alone.

While we may associate the idea of a product with concrete objects like phones, aircraft, or even command, control and communications centers, an organization or a process can also be a product. Sometimes a product is not complex enough to justify performing Product SE, and only needs product design engineering. Enterprise SE and Service SE should determine whether a product needs Product SE.

Product Taxonomy

For any system being developed, the systems engineers must decide: What are the right components to include? This is not self-evident, because basic product types are not necessarily mutually exclusive. For example, some would consider that facilities contain hardware and people. Others would consider facilities to be separate from hardware and people. Some would include material as part of hardware, while others would not. Creating a taxonomy of product types can help the systems engineer think clearly and thoroughly about what components to include.

Business Objectives and Products

When it develops and launches a new product, an enterprise must align that product with its business goals, internal capabilities, and competition. It must align the end product with the systems expected to realize and sustain it.

The new product concept must be based on analysis that doesn’t merely explore product potential, but also explores the ability of the enterprise to exploit that potential, including looking at factors like organizational culture, focus, goals, and processes. Present and future markets and technology must be analyzed, and so must several dimensions of competition, such as the competition’s offerings and their plans for entry into new markets, as well as their plans for product expansion, including new functionality, features, or services. The competition’s plans, and the ability of the enterprise to react to them, must be monitored for the enterprise to remain competitive in the long term.

Accelerating economic globalization since the 1970s has forced enterprises to respond to global needs, not just local or regional ones. In the resulting hyper-competitive business environment, enterprises must analyze their financial goals, their market positions, and the business segments in which they participate in order to understand what products are required.

This is true for completely new products, and also for product enhancements, the penetration of new markets, and growth within existing markets.

Relationship between Product Systems Engineering and Product Development

Product development is the process of bringing a new product to market. Product systems engineering considers the complete product system, that is, the product in the context of all its enabling elements. Product systems engineering takes a full life cycle perspective, “from cradle to grave” or “lust to dust.”

Technology-based product development may be thought of as coming from two sources. In the first source, innovation enhances existing technology and is aimed at relatively short-term market windows. The second source involves long-term research to identify the technology developments required to realize the concept. These may be technologies whose availability is not predicted in the near future, and as such, substantial investment and long lead times may be required before the proof of concept, initial operational capabilities (IOC), or prototyping stages are reached; additionally, the commitment to realize the actual product offering can be greatly delayed. Some authors claim that the systems engineering process and the new product development (NPD) process for the aforementioned second source are one and the same.

It is from the second source that strategic initiatives (long-term applied research) realize new products in areas like military aircraft or bioengineering. When research resolves fundamental questions on matters of science or national/regional interest, technology breakthroughs occur.

This article concentrates on the first source of technology-based product development, that is, the one driven by ever-evolving market needs to enhance existing technology.

Product Development Patterns

When existing or near-future technology innovations are exploited to generate new product ideas, product development may follow any one of four scenarios (Phillips 2001):

• Product development may use well-established technologies to help the enterprise improve the efficiency of current operations.

• Product development may use well-established technologies to help the enterprise into new kind of operations.

• Product development may use leading edge technologies to improve the efficiency of current operations.

• Product development may use leading edge technologies to help the enterprise into new kinds of operations.

The product itself may simply be a modification of an existing product or its presentation, it may possess new or different characteristics that offer additional benefits to the customer, and/or it may be entirely new and satisfy a newly-defined customer want or market niche (http://www.businessdictionary.com/definition/product-development.html).

Existing realization or sustainment systems may not be adequate to develop a given product. For example, it might be necessary to change development practices, use different testing methods or facilities, or upgrade manufacturing equipment and procedures. There might need to be improved customer support procedures and newly trained support personnel, upgraded maintenance facilities and tools, or modified spare parts delivery techniques.

Market Pressures

The product development process must be dynamic, adaptive, and competitive on cost, time-to-market, performance, and quality on a global scale. This is because in the global economy continuous technology innovation and constantly evolving markets and customer needs demand a rapid response.

Products themselves are now multidisciplinary in nature; product development must have close participation, not only from the different specialty engineering fields (mechanical, electrical, industrial, materials, and so on), but also from the finance field to analyze the total cost of development (including production), marketing and sales to understand market behavior and acceptance, manufacturers and distributors, and legal and public relations experts.

All this has mandated enterprises to assess how they create their products and services. The result has been an effort to streamline the development process. One example of this is seen by the deployment of integrated product teams (IPT) and integrated product development teams (IPDT).

Product Systems Engineering

Product systems engineering strives for the efficient use of company resources in order to achieve business objectives and deliver a quality product. Product systems engineering activities range from concept to analysis to design and determine how conceptual and physical factors can be altered to manufacture the most cost-effective, environmentally friendly product that satisfies customer requirements. Engineering the product system requires an interdisciplinary approach that includes an analysis of the product and its related elements such as manufacturing, maintenance, support, logistics, phase-out, and disposal; these are all activities which belong to either the realization system or the sustainment system. The proper application of systems engineering and analysis ensures the timely and balanced use of human, financial, technological assets, and technology investments to minimize problems, harmonize overall results, and maximize customer satisfaction and company profits.

Products are as diverse as the customers that acquire them and there are no universally accepted methods, processes, and technologies (MPTs) for end-to-end analysis of products and their supporting subsystems. Every product needs to adapt existing MPTs based on prior experiences and best practices, such as Toyota (Hitchens 2007), Mitre (Trudeau 2010), and NASA (NASA SELDP 2011). Product systems engineering helps develop the end-to-end analysis of products and sub-systems by performing the following tasks:

• determining the overall scope of needs of the product system;

• defining product and system requirements;

• considering all interactions between the different elements of the product system;

• organizing and integrating engineering disciplines; and

• establishing a disciplined approach that includes review, evaluation and feedback, and ensures orderly and efficient progress.

Constantly evolving needs and requirements, along with constant technology innovations, may render a committed product development obsolete even before deployment. This has led to debate among systems engineering professionals on the need for the systems engineering process to become more rapidly adaptable. Platform-based solutions to resolve some of these challenges (infrastructure as a service, platform as a service, and software as a service) are being studied and proposed (MITRE 2010; Boehm 2010).

Product Development Process

The integrated product development process (IPDP) starts with customer/market needs with the objective to perform the following:

• deliver products that satisfy and exceed customer expectations;

• provide a rapid response to customer demands through adaptive product offerings;

• respond to changing business environments; and

• incorporate systems thinking, generate new ideas, and co-create value.

IPDP methods are continuous in nature with a goal to produce products whose cost, performance, features, and time-to-market help increase company profitability and market share. Figure 1 provides a snapshot of an IPDP. The IPDP is divided into four stages (Magrab et al. 2010).

Stage I: Product Identification

During this stage, the enterprise aims to identify a product idea that will be a good business investment for the company. Some of the outputs from a good product identification stage include demonstration of strong customer need, determination of potential markets, business profitability, and sustainable product competitive advantage.

During this stage, the systems engineering process plays a key role by working with product managers and the IPT to gain back of the envelope input to assess needed technology innovation, the viability of existing technologies, the estimated time of development, the cost of technology development and risk, and to propose a technology development road map with functionality/feature releases, if any. This initial assessment uses rough order of magnitude (ROM) estimates within +/- 40% taken by the product managers to analyze the feasibility of a business case and come to a decision about entering the concept development stage which is also known as Decision Gate -1.

Stage II: Concept Development

The main goal of the concept development stage is to generate and develop method, process, and technology (MPT) concepts that will satisfy the product’s performance goals. Some of the evaluation criteria that these concepts must fulfill are listed below:

• company’s core competencies can satisfy the requirements to produce the products

• low technical and business risk

• minimal change in market conditions and competitors

• manufacturing resource requirements are close to planned allocations

• prototypes indicate product’s economic viability and manufacturing feasibility

During this stage, systems engineering supports the IPDT in the analysis of alternatives (different concept solutions), identifying different operational scenarios and modes of operation, identifying the functional requirements of the products, defining technical performance measures (TPM), identifying technology risks and performance risks, identifying the main components of the products and required interfaces among them, etc. This stage is highly interacting and iterative among several IPDT and in some instances, because of the complexity of the products, a systems engineering integration team is required to ensure analysis of all the possible solutions.

Techno-economic feasibility in terms of the time and cost to develop the product are usually within +/-10%; in many instances at this stage, it is possible to already have a technology roadmap developed to guide the product managers on possible phases for product releases. At this stage, a decision is made regarding whether or not to continue with the full development of the product according to a product roadmap jointly worked by the IPT through joint preliminary design reviews.

Stage III: Design and Manufacturing

This stage includes the creation of engineering drawings for the product, product configuration items specs, design for manufacturability/producibility, Design for X (DFX), manufacturing design plans, production plans and schedules, completion of a test production run that ensures that product meets customer requirements and quality criteria, and a plan for full production.

Product systems engineering works closely with the project managers and product managers to create a Systems Engineering Management Plan (SEMP) to manage the technical effort. Systems engineering carries out many of the activities, including requirements traceability; product architecture requirements and views; operational requirements; integration, verification, and product validation plans; modeling, simulation, and test and evaluation of the product system under different scenarios to evaluate TPM; launch readiness plans, including end-user test plans and operational readiness; etc.

Stage IV: Launch

During this stage, the product is delivered to its potential markets. A launch is considered successful when the product meets its quality goals, satisfies customer requirements, and realizes the business plan goals. Product systems engineering plays a consultant role with the product manager for the analysis and validation of TPM, test results and accuracy, and during the continuous improvement process to monitor product and product system technical performance and product quality.

Figure 1. Integrated Product Development Process (Figure Developed for SEBoK)

Relationship between Product Systems Engineering and Technology Development

As technological advancement accelerates, product life cycles become shorter, especially for high technology products. As a result, enterprises risk having outdated or obsolete products that have lost pace with markets trends, technology trends, or customer expectations.

Product systems engineering should bring awareness of technology changes and trends to the analysis of new product ideas or innovations. This affects the time and cost inputs into the technical feasibility analysis of the product. The result should include a roadmap of required technology developments, which is then used to create the overall roadmap for the new product offering.

In these cases, new product ideas impose requirements on new technology developments.

On the other hand, when technology developments or breakthroughs drive product innovation or the generation of new markets, the technology developments may also generate requirements on product features and functionalities. Factors which dictate decisions about introducing products include the Technology Readiness Levels (TRL), the Integration Readiness Levels (IRL), the Manufacturing Readiness Levels (MRL), the System Readiness Levels (SRL), and the operational readiness of the enterprise to launch the product system. See the Product Readiness article.

Understanding the entities that compose the product is not a trivial task for systems engineers. It is not unusual for a new product to require developments in several technologies, including new materials, electronic components, software, maintenance and repair procedures, processes, or organizational structures. All of these developments must be factored into the IPDP for the successful deployment and proper use of the product.

Figure 2. Basic Product Types that Constitute a Product System (Martin 1996) This material is reproduced with permission of John Wiley &Sons, Inc.

Product Type Examples

Examples of each product type are shown below (Martin 1996).

Table 1. Product Types (Martin 1996) This material is reproduced with permission of John Wiley &Sons, Inc.

Materials could be thought of as basic raw materials, like steel, or as complex materials, like cladded metals, graphite composites, or building aggregate material. Personnel are not normally thought of as a “product,” but that can change depending on the type of system in question. The NASA space program “system” certainly produces astronauts. When personnel are considered system(s), it is not usually possible to simply find and hire personnel with the requisite knowledge, skills, and experience. These personnel “products” can often be developed using a product SE approach (Martin 1996). For example, you could specify requirements (i.e., required knowledge, skills, and experience) for each person that is part of the system. Interfaces can be specified for each person, and an assessment can be made as to the maturity of each person (i.e., each potential product). These are a few examples of how product SE can be applied to personnel products.

In enterprise systems engineering, we may need education and training systems to make up a part of our personnel system in order to produce people with the right competencies and capabilities.

References

Works Cited

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.

Boehm, B. 2010. Systems 2020 Strategic Initiative. Hoboken, NJ, USA: Systems Engineering Research Center (SERC), SERC-2010-TR-009. August 29, 2010.

Grady, J. 2010. Systems Synthesis- Product and Process Design. Boca Raton, FL, USA: CRC Press.

INCOSE. 2011. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

Magrab, E., Gupta S., McCluskey, P., and Sandborn, P. 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.

MITRE. 2010. Platform as a Service: A 2010 Marketplace Analysis, Cloud Computing Series. Bedford, MA, USA: Systems Engineering at MITRE.

Morse, L. and Babcock, D. 2007. Managing Engineering and Technology, fourth edition. Upper Saddle River, NJ, USA: Prentice Hall.

Academy of Program/Project & Engineering Leadership (APPEL). 2009. NASA's Systems Engineering Competencies. Washington, D.C.: U.S. National Aeronautics and Space Association. Available at: http://www.nasa.gov/offices/oce/appel/pm-development/pm_se_competency_framework.html.

Phillips, F. 2001. Market Oriented Technology Management: Innovating for Profit in Entrepreneurial Times. Springer. 3-540-41258-1

Trudeau, P.N. 2010. Designing and Enhancing a Systems Engineering Training and Development Program. Bedford, MA, USA: The MITRE Corporation.

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

Primary References

No primary references have been identified for version 0.75. Please provide any recommendation on primary references in your review.

Additional References

No additional references have been identified for version 0.75. Please provide any recommendation on additional references in your review.

---

< Previous Article | Parent Article | Next Article >

Comments from 0.5 Wiki

This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments.

SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus