Stakeholder Responsibility

From SEBoK
Jump to: navigation, search

This topic is part of the Systems Approach Applied to Engineered Systems knowledge area (KA). It summarizes various aspects of stakeholder responsibility for acquisition and ownership during the system life cycle processes covered by such sources as the International Council on Systems Engineering Handbook (INCOSE 2012). Any of the activities described below may also need to be considered concurrently with other activities in the systems approach at a particular point in the life of a system-of-interest (SoI).

The activities described below should be considered in the context of the Overview of the Systems Approach topic at the start of this KA. The final topic in this KA, Applying the Systems Approach, considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elements of systems engineering (SE).

Products, Services, and Enterprises

Most often, the terms "product" and "service" describe the effects that are exchanged in a customer and supplier agreement. This may be a commercial agreement, one funded publicly by a charity, or provided by a government agency. The difference between a product and a service is that a product is an artifact acquired to achieve an outcome while a service is an outcome supplied directly to a user.

The terms “customer” and “user” are often used interchangeably in engineering and management disciplines. The INCOSE Systems Engineering Handbook (INCOSE 2012) makes the following specific distinctions among the stakeholders associated with a system:

  • The acquirer is the stakeholder that acquires or procures a product or service from a supplier.
  • The supplier is an organization or individual that enters into an agreement with the acquirer to supply a product or service.
  • The operator is an individual or organization that that uses knowledge, skills and procedures to perform the functions of the system to provide the product or service.
  • The user or customer is the individual or group that benefit from the operation of the system.

These terms define the roles stakeholders take; however, they may not always lie within these distinct entities (e.g. sometimes the acquirer may also be the user). This also applies to service systems, as some of the entities may also overlap in roles. Parnell et al., (Parnell et al. 2011) offer an alternative list of stakeholders that include decision authority, client, owner, user, consumer, and interconnected.

Product systems consist of hardware, software, and humans, and they have traditionally been the focus of SE efforts. These systems are delivered to the acquirer and operated to accomplish the goals that led to the requirements for the system. These requirements were derived from the need to provide products and services to one or more users as part of an enterprise.

The delivery (supplying) of a service is indicative of the direct delivery of an outcome, which is often related to the delivery of products (e.g., a maintenance, training, or cleaning service). This is not the same as the delivery of a service system (see the discussion below).

In traditional SE, the term “service” or “service system” refers to the wider system context that describes the acquirer's need to deliver user value. In this case, the service system is a fixed system definition that dictates the manner in which the acquiring enterprise will utilize the products to enable the delivery of services to users. Product systems are designed to be integrated and operated as appropriate to enable this service to be maintained or improved as required. In this view, a service system is static and contains dedicated products, people, and resources; that is, hierarchies of products are engineered to provide acquirers with the ability to offer predefined services to users or customers.

More recently, the term "service systems" has been used to describe a system that is engineered in a manner that allows enterprises to offer services directly to users, bypassing the need to hold all of the necessary products and services within the enterprise itself. This requires the expansion of the definition of a “supplier” as follows:

  • A product supplier is an organization or individual that enters into an agreement with an acquirer to supply a product or related product support services.
  • A service system supplier is an organization or individual that enters into an agreement with an acquirer to supply a service system.
  • A service supplier is an organization or individual that enters into an agreement with a user to supply a service.

These service systems tend to be configured dynamically to deal with problems that traditional static service find challenging to address. This view of a service system employs "late binding" with product systems that are not owned by the enterprise, but are used to enable the service to be offered as closely to given time demands as possible. This is the definition of a service system used in the Service Systems Engineering topic in Part 4, Applications of Systems Engineering.

Stakeholder Needs

One of the most critical stakeholder responsibilities is to identify the needs and requirements for the system that provides the products or services (INCOSE 2012).These needs and requirements are expressed in agreements between acquirers and suppliers.

There are other stakeholders who shape system requirements based on their needs, but who are not necessarily acquirers or suppliers. The stakeholders and the requirements engineers share the responsibility to identify their needs during the requirements process.

Acquirer/Supplier Agreements

Lawson (Lawson 2010) provides a perspective on what it means to own systems, trade in system products and services, and the implications of supply chains in respect to the value added and ownership of the systems, its products and services. INCOSE (INCOSE 2012) defines two life cycle processes related to acquisition and supply. The acquisition process includes activities to identify, select, and reach commercial agreements with a product or service supplier.

In many larger organizations, there is a tradition of system ownership vested in individuals or, in some cases, enterprise entities (groups or teams). Ownership implies the authority and responsibility to create, manage, and dispose of a system-of-interest (SoI), as well as sometimes to operate the SoI.

Product Acquire/Supply

In some industries, a supplier works directly with an acquirer to help understand the acquirer’s needs and then engineer one or more products to satisfy these needs. In certain cases, a single supplier will provide the complete worthy product system. In other cases, a supply chain will be formed to deliver product systems with a system integrator to ensure 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 is designed to fit into it. A good systems engineer may suggest changes to the enterprise as a better way to solve the problem and then modify the product system’s requirements 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 these cases, the other elements of the systems approach are performed by the acquirer/user and may not follow formal SE processes. It is important that a product supplier takes this into account when considering the best manner in which to engineer a system, as additional help or support services may need to be offered with the purchased product. The idea of a supplier offering support services for users with a type of product purchased elsewhere (e.g., an auto-mechanic servicing different makes of cars) begins to overlap with the service systems context, as discussed in the next topic.

For an institutionalized infrastructure in which SoIs are entirely owned by an enterprise or parties thereof, the entire responsibility of life cycle management, including operation, is often vested with the system owners. These systems belong to the system asset portfolio of an enterprise or multiple enterprises and provide the system resources, including the planned systems that are developed during life cycle management.

Service Acquire/Supply

Organizations providing service systems need not own the individual products and services that they deliver to their users and customers. With this viewpoint, the supplied service system includes the means to identify and gain access to appropriate products or services when needed. The service systems then would then be the bundle of products and services assembled for the user; for example, assembling software applications and service agreements for a mobile phone already owned by a user. The enterprises providing service systems may, in turn, offer infrastructure services to a wide range of different technologies or application domains. This can mean that the transition, operation, maintenance and disposal activities associated with system ownership may not be embedded in the acquiring service system enterprise, and will therefore need to be treated as separate system services. More detail can be found in Product Systems Engineering, Service Systems Engineering, and Enterprise Systems Engineering, in Part 4, Applications of Systems Engineering in the Guide to the Systems Engineering Body of Knowledge (SEBoK).

The service systems engineer helps the service supplier create and sustain the service system that can be used to discover, integrate, and use specific versions of generic products or services 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, as well as to interface with it effectively. The use of open interface standards, such as standard power supplies, interface connections (e.g., Universal Serial Bus (USB)), or file formats (e.g., Portable Document Format (PDF)) can help make this easier.

Enterprise Evolution

A useful distinction between product system design and enterprise system design is that “enterprise design does not occur at a single point in time like the design of most systems. Instead, enterprises evolve over time and are constantly changing, or are constantly being designed” (Giachetti 2010, xiii).

The enterprise developer may also aim to optimize back stage processes (the internal operations) of an organization or an institution by exploiting advances in technology, particularly information technology (IT) and associated processes. In these cases, the engineered systems are considered to be enterprise systems.

Enterprise systems may offer products (goods) and/or services. From an enterprise engineering viewpoint, an enterprise concurrent with its product SE must not only look at the development and delivery of the products but also look at the alignment and optimization of the product delivery within the enterprise objectives. Similarly, in service SE, the main focus is on an intangible value delivery to the end-customer (externally focused: front stage), in which internal and external processes must be synchronized. However, with the rapid advances in information and communications technologies (ICT), in many cases the boundaries between internal and external processes are quite blurred. Current SE research is extending product methods, processes, and tools into the enterprise transformation and service innovation fields to exploit advances in business process methodologies and technologies.

Enterprise SE must not only do the engineering of the enterprise itself, but may also be involved in the engineering of the service systems and products systems that are necessary for the enterprise to achieve its goals.


Works Cited

Giachetti, R.E. 2010. Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press.

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

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College.

Parnell, G.S., P.J. Driscoll, and D.L Henderson (eds). 2011. Decision Making for Systems Engineering and Management, 2nd ed. Wiley Series in Systems Engineering. Hoboken, NJ: Wiley & Sons Inc.

Primary References

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

ISO/IEC/IEEE. 2015.Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College.

Additional References

Carlock, P.G. and R.E. Fenton. 2001. "System of Systems (SoS) enterprise systems engineering for information‐intensive organizations." Systems Engineering. 4(4): 242–261.

Rouse, W.B. 2005. "Enterprises as Systems: Essential Challenges and Approaches to Transformation." Systems Engineering. 8(2): 138-150.

< Previous Article | Parent Article | Next Article >

SEBoK v. 1.7 released 27 October 2016

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