Engineered System Context
This article defines products and product systems; and provides an overview of product systems contexts.
The relationship between product systems and service systems engineering is discussed briefly in the Types of Systems Knowledge Area introduction, and more fully in Product Systems Engineering and Service Systems Engineering topics of Part 4.
Products and Product Systems
The word product is define as "a thing produced by labour or effort; or anything produced" (Oxford English Dictionary). In a commercial sense a product is anything which is acquired, owned and used by an enterprise (hardware, software, information, personnel, an agreement or contract to provide something, etc.)
product systems are systems in which products are developed and delivered to the acquirer for the use of internal or external user. For product systems the ability to provide the necessary capability must be defined in the specifications for the hardware and software, or the integrated system that will be provided to the acquiring enterprise .
A significant aspect of product systems is a clear statement of how the product is intended to be used; and its actual delivery to the acquirer. The customer will be required to accept the system, typically through a formal verification process, against the agreed use. The systems engineering process for product systems must include methods of connecting the needs or requirements of the acquirer to the means for obtaining the customer acceptance of the product, which is usually the precondition for being paid.
Product System Contexts
A product system context would be one in which the system of interest (soi) is the product itself. The context for a product system can be a higher level of product hierarchy, a service of an enterprise system.
If we apply a systems approach to a product context we do it with the purpose of engineering a product to be integrated and used in a product hierarchy; or to enable the delivery of a service directly to a user by an enterprise . To create a product which satisfies the stakeholder needs and constraints we must fully understand this wider context and synthesize a product which fits within the larger system context while clearly defining and enforcing the boundaries and interfaces. This will include interfaces to people, other products and services, and the enterprises that contains them. Developing the right product may require the developer to negotiate changes to the interface and the elements of the wider context, but this must be done by agreement with the relevant authority that own the systems beyond the product boundaries.
Once the product is delivered its value is realized and continues to be realized when it enables the acquiring enterprise to provide a service to its users. The value continues to be realized throughout the Life Cycle of the product and may include possible future enhancements to the product via upgrades, replacement policies, and/or software updates (sustainment services). The acquirer receives a tangible product: the smart phone, the car, the fighter air craft, the robot, the satellite, for example; which it operates as part of the supply of a service.
To create these systems and provide the resulting outcomes the systems approach helps the acquirer define the broader context that includes the necessary services, other products and the enterprise. The product supplier then creates a product to fulfil the requirements of the broader context.
The different Life Cycle Models, Engineering, and Organizational and Commercial arrangements which can be used to acquire or develop a product system are covered in part 3, 4 and 5 of the SEBOK. The following discussion covers some of the key issues.
In some industries, a supplier works directly with an acquirer to help understand the need and then engineer one or more products to satisfy that need. In some cases a single supplier will provide the complete product system, in others a supply chain will be formed to deliver product systems, with a system integrator ensuring they fit together and integrate into the wider context. This is a theoretical view of Product Systems Engineering, in which the context is fixed and the product designed to fit into it. A good systems engineer may well suggest changes to the enterprise as a better way to solve the problem, and then modify the product system requirement accordingly. However, at some point an agreed context will be set and a product system developed to work within it.
For many commercial products, such as mobile phones, a supplier creates a representative user profile to generate the requirement and then markets the product to real users once it is realized. In this case, the other elements of the systems approach are performed by the acquirer/user and may not follow formal system engineering processes. It is important that a product supplier takes this into account in the way the product system is engineered, possibly offering additonal help or support services alongside the purchased product. The idea of a supplier offering such support services for users with a certain type of product purchased elsewhere (e.g. a garage servicing all makes of car) begins to overlap with Service Systems Engineering, as discussed in the next article.
Note, as discussed in the Types of Systems Knowledge Area introduction this view of the relationship between product and service is specific to Product Systems Engineering. While some engineering of the acquirer's static service system may occur, this is done from a product focus.
The definition of service system, as associated with Service Systems Engineering, describes a more dynamic view of service system. This is dicussed more fully in The Service View of Engineered Systems topic.
References
Citations
None.
Primary References
INCOSE. 2011. INCOSE Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.
Additional References
Martin J. N. 1997. Systems Engineering Guidebook. Boca Raton, FL, USA: CRC Press.
ANSI/EIA. 2003. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA). ANSI/EIA 632‐1998.
Article Discussion
Signatures
--Radcock 14:07, 23 August 2011 (UTC)
--Asquires 01:17, 12 September 2011 (UTC)