Engineered System Context
The Product View of Engineered Systems
This section defines products and product systems; and provides an overview of product systems contexts.
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, 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 next section.
Service View of Engineered Systems
The world economies have transitioned over the past few decades from manufacturing economies that provide goods -- to service based economies. Along with this transition there has been a new application of systems engineering, built on principles of Systems Thinking, but applied to the development and delivery of service systems . The disciplines of service science and service engineering have developed to support this expansion. This article defines services and service systems; provides a brief history of service science and service engineering and defines the service engineering context.
Services and Service Systems
A service can be any outcome required by a user, e.g. transport, communications, protection, data processing, etc. Business services are specific types of service in which the user and supplier sit within a shared organization , e.g. payroll, accounting, marketing, etc. Services usually include some agreed measures of performance or quality.
- A service can be defined as an activity required by one or more users defined in terms of outcomes and quality of service without detail to how it is provided. A service is also an act of help or assistance. (layman’s definition)
- Services are activities that cause a transformation of the state of an entity (people, product, business, and region or nation) by mutually agreed terms between the service provider and the customer (engineering definition) (Spohrer 2008)
- Services are processes, performances, or experiences that one person or organization does for the benefit of another – such as custom tailoring a suit, cooking a dinner to order, driving a limousine, mounting a legal defense, setting a broken bone, teaching a class, or running a business’ information technology infrastructure and applications. In all cases, service involves deployment of knowledge and skills (competences) that one person or organization has for the benefit of another (Lusch and Vargo 2006), often done as a single, customized job. In all cases, service requires substantial input from the customer or client (Sampson 2001) – for example, how can a steak be customized unless the customer tells the waiter how the customer wants the steak prepared? (business/marketing science definition)
- In the service-dominant logic (S-DL) for marketing (Vargo and Lusch 2004), service is the application (through deeds, processes, and performances) of specialized operant resources (knowledge and skills) for the benefit of another entity or the entity itself. (abstract definition)
Service systems provide outcomes for a user without necessarily delivering hardware or software products to the service supplier. The hardware and software systems may be owned by a third party who is not responsible for the service. The use of service systems reduces or eliminates the need for acquirers to obtain capital equipment and software in order to obtain the capabilities needed to satisfy users.
In Zeithaml et. al. (2005), services are defined as ""combinations of deeds, processes, and/or performances provided to customers in exchange relationships among organizations and individuals" (Zeithaml et. al. 2005)" (quote in Chang 2010, 1). Tien and Berg (2003) examine services and service systems engineering. They defined a number of unique aspects of services that must be considered when defining and implementing the systems engineering methods for services. Specifically:
...unique features that characterize services – namely, services, especially emerging services, are information-driven, customer-centric, e-oriented, and productivity-focused. (Tien and Berg 2003, 13)
Development of Service Science and Service Engineering
Within the past 10 years a new field that addresses service systems has emerged initially called Service Science and Service Engineering. One of the first articles to define the field of service science and service engineering was published in 2006 in the Communications of the ACM, titled "Service Systems, Service Scientists, SSME, and Innovation" (Maglio, et al. 2006). This article was written to "establish a new academic discipline and new profession" (Maglio, et al. 2006, 8). The authors of this leading work are all from the IBM Almaden Research Center in San Jose, CA.
Published in 2008, Service Science, Concepts, Technology, Management, by Harry Katzan (2008) claims to be the first book to define the newly emerging field of service science: "Service science is defined as the application of scientific, engineering, and management competencies that a service-provider organization performs that creates value for the benefit of the client of customer" (Katzan 2008, vii). Katzan (2008) continues:
A service is a client/provider interaction that creates and captures value, and a service system is a system of people and technology that adapts to the changing value of knowledge in the systems. Service science is the study of service systems. To be more specific, a service system is a socially constructed collection of service events in which participants exchange beneficial actions through a knowledge-based strategy that captures value from a provider-client relationship. (Katzan 2008, xi)
Katzan 2008 clearly defines the differences between products and services and he provides a five category method of classifying services.
According to the definitions provided in these references, service systems engineering is a subset of the overall service science field that they define.
Within the past few years a number of other books have appeared that address service science and service systems engineering. These recent books are based on the foundation laid by the earlier IBM work. In the book Introduction to Service Engineering, Spohrer and Maglio (2008) state that:
Service science is short for service science, management, engineering and design, also known as SSMED. It began as a "call to action," focusing academics, businesses, and governments on the need for research and education in areas related to service (Chesbrough, 2004: IBM 2005). After all, the service sector (as traditionally measured) has grown to be the largest share of the gross domestic product and employment for all major industrialized countries (Spohrer and Maglio, 2008) Service science has grown into a global initiative involving hundreds of organizations and thousands of people who have begun to create service innovation roadmaps and to invest in expanding the body of knowledge about service systems and networks (IfM and IBM, 2008). (Spohrer and Maglio 2010, 3)
Service System Context
A service system context is one in which the system of interest (soi) is the service system. This system contains all of the technology, infrastructure, people, resources, etc. needed to enable the service. The wider system of interest describes the enterprise providing the service and its relationship with other services to provide enterprise success.
If we apply a Systems Approach to a service system we do it with the purpose of engineering a service system to enable the outcomes required by an enterprise to satisfy its clients. When operating in the service system context, we should be free to consider all options to provide the service, providing they fit within the constraints of the enterprise. This will include interfaces to other services, people and resources in the enterprise. If an option for providing the service make use of existing products or resources within or outside of the enterprise we must ensure they are available for this use, and that this does not adversely affect other services. Part of getting the right service may require the negotiation of changes to the wider enterprise context, but this must be by agreement with the relevant authority.
For a service system, and when considering the service system context, the value is realized only through service transactions. The end-user co-creates value at the time of the request to use the service. One may have a smart phone (the product) but if one wants to make a flight reservation the service system is composed of many service system entities (the caller, the person called, the smart phone, the access network, core Internet Protocol (IP) network, Internet Service provider (ISP), www, data centers, etc.) that are linked as needed to enable the service. When one makes a reservation and then books the flight, the value has been created.
The service systems engineer helps the service supplier create and sustain the service system, which can be used to discover, integrate and use specific versions of generic products or service when needed. The realization of service systems requires the ability to make use of product systems. However, these product systems are developed and owned outside of the service system. The service system must be able to gain access to a product or service when needed, and to interface with it effectively. The use of open interface standards, such as standard power supplies, interface connections such as USB or file formats such as PDF can help make this easier.
This definiton of service system, as associated with dynamic IT services is dicussed more fully in Service Systems Engineering topic of Part 4.
References
Works Cited
Chang, C.M., 2010. Service Systems Management and Engineering: Creating Strategic Differentiation and Operational Excellence. Hoboken, NJ, USA: John Wiley and Sons.
Chesbrough, H. 2004. "A failing grade for the innovation academy." Financial Times (September 24):1, cited by Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In Introduction to Service Engineering. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
IBM. 2005. IBM Research: Services Science: A New Academic Discipline? www.almaden.ibm.com/asr/resources/facsummit.pdf (accessed September 12, 2011), cited by Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In Introduction to Service Engineering. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
IfM and IBM. 2008. "Succeeding through service innovation: A service perspective for education, research, business and government." University of Cambridge Institute for Manufacturing. Cambridge, UK, cited by Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In Introduction to Service Engineering. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
Katzan, H. 2008. Service Science. Bloomington, IN, USA: iUniverse Books.
Lusch, R.F. and S. L. Vargo (Eds). 2006. The service-dominant logic of marketing: Dialog, debate, and directions. Armonk, NY: ME Sharpe Inc.
Maglio P., S. Srinivasan, J.T. Kreulen, and J. Spohrer. 2006. “Service Systems, Service Scientists, SSME, and Innovation." Communications of the ACM. 49(7) (July).
Salvendy, G. and W. Karwowski (eds.). 2010. Introduction to Service Engineering. Hoboken, NJ, USA: John Wiley and Sons.
Sampson, S.E. 2001. Understanding Service Businesses. New York, NY, USA: John Wiley.
Spohrer, J. 2008. "Service Science, Management, Engineering, and Design (SSMED): An Emerging Discipline-Outline & References." International Journal of Information Systems in the Service Sector. 1(3) (May).
Spohrer, J. and P. P. Maglio. 2008. "The emergence of service science: Toward systematic service innovations to accelerate co-creation of value." Production and Operations Management 17 (3): 238-246, cited by Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In Introduction to Service Engineering. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In Introduction to Service Engineering. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
Tien, J.M. and D. Berg. 2003. "A Case for Service Systems Engineering". Journal of Systems Science and Systems Engineering. 12(1): 13-38.
Vargo, S.L. and R.F. Lusch. 2004. "Evolving to a new dominant logic for marketing." Journal of Marketing 68 (January 2004): 1-17.
Zeithaml, V. A., M. J. Bitner, and D. D. Gremler. 2005. Services Marketing: Integrating Customer Focus Across the Firm. 4th ed. New York, NY, USA: McGraw-Hill, quoted in Chang, C.M., 2010. Service Systems Management and Engineering: Creating Strategic Differentiation and Operational Excellence. Hoboken, NJ, USA: John Wiley and Sons.
Primary References
Chang, C.M., 2010. Service Systems Management and Engineering: Creating Strategic Differentiation and Operational Excellence. Hoboken, NJ, USA: John Wiley and Sons.
Tien, J.M. and D. Berg. 2003. "A Case for Service Systems Engineering". Journal of Systems Science and Systems Engineering. 12(1): 13-38.
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.