Deploying, Using, and Sustaining Systems to Solve Problems

Engineered systems are eventually owned by an individual, team, or enterprise. Those who own the system during development may not be the ones who own it when the system is in operation. Moreover, the owners may not be the users; e.g., service systems may be used by the general public but owned by a specific business that is offering the service. Transition of a system from development to operations is often itself a complex task, involving such activities as training those who will operate the system, legal actions to complete the transfer, and establishing logistical arrangements so that the operators can keep the system running once the transition is completed.

Basic elements of Ownership and Use

The following sections overview various aspects of ownership and use covered in such sources as (INCOSE 2011). They briefly discuss the nature of system ownership in terms of key life cycle processes. Any activities described below many need to be considered concurrently through the systems' life, as discussed in Applying the Systems Approach. The implementation of these principles is described in Systems Engineering and Management.

Acquirer/Supplier Agreement

(Lawson 2010) provides a perspective on what it means to own systems, trading in system products and services, and the implications of supply chains in respect to value added and ownership. (INCOSE 2011) 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 authority and responsibility to create, manage, (perhaps operate) and dispose of a System of Interest (glossary) (SOI).

For institutionalized infrastructure SOI that are entirely owned by an enterprise or parties thereof, the entire life cycle management responsibility, 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 systems need not own the individual products and services which they deliver to their users and customers. The service system includes the means to identify and gain access to appropriate product or services when needed. These may not be enterprises in the traditional sense, but may include products embedded with the user (e.g., mobile phone hardware), or enterprises which 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 cannot be embedded in the acquiring enterprise, but need to be treated as separate system services. More detail can be found in Product Systems Engineering, Service Systems Engineering and Enterprise Systems Engineering.

Transition

Transferring custody of the system-of-interest and responsibility for its support from one organization to another is often called transition (INCOSE 2011). Transition of a product system includes integration into the acquiring organization's infrastructure.

Transition includes the inital installation of a system, ensuring that it is compatible with the wider system, and ensuring that it does not cause any significant wider system issues. This process of acceptance and release for use varies between domains and across businesses and enterprises, and can be thought of as an inital assessment of the system effectiveness , (Hitchin 2007). Generically, transition may be considered to have two parts. (a) Ensuring that the new system interoperates with the systems around it and (b) ensuring the resulting system is safe and has other critical operational properties.

It is particularly important to have considered the emergent properties when a new system is added to the existing organization's system of systems (sos) network, as well as the complexity (see also Complexity) of the organization into which the new system is transitioned. The more complex the receiving organization is, the more challenging the transition and the greater likelihood of unintended interactions and consequences from the new system's insertion. Dealing with the consequences of this complexity starts in transition, and continues into operation, maintenance and disposal.

Transition of a service system is often performed in two stages. First, the service system infrastructure is accepted and released. Second, each realization of the service is accepted and released. This second case can be a significant problem if the required responsiveness of the service does not leave sufficent time to ensure that the service meets necessary functional and quality attributes, including interoperability, safety, and security. (See Service Systems Engineering).

Transition can also require its own enabling systems , each of which can be defined using a systems approach.

Operation

Use of the system to help enable delivery of user services is often called "operations". (INCOSE, 2011) Systems effectiveness is normally considered throughout the operational life of a system. For a complex system, emergent behavior should be considered in three ways:

1. To identify and plan for emergent property within the system realization.
2. To build in mechanisms for identifying and handling unexpected emergent properties within the system during its use.
3. To provide necessary procedures for dealing with wider system consequences of unexpected emergent properties in the enterprise; e.g. emergency response or medical first aid.

Operations require their own enabling systems, each of which may need its own Systems Approach.

Maintenance

The purpose of maintence is to sustain the system through its useful life (INCOSE 2011). In system terms, maintenance implements systems to deal with entropy and maintaining the system of interest in a viable state. Since an open system maintains its existance by continual exchange of energy, information and materiel with its environment, one apsect of its maintenance must be the management of resources in the environment.

(Hitchins 2007) describes a generic approaches to Resource Management and Viability Management based on system concepts. Resource Management identifies the need to consider the acquisition, storage, distribution, conversion and disposal of resourse. Viability Management should consider internal homeostasis systems and external resilience to environmental disturbance and adaptability to environmental change.

Maintenance will require its own enabling systems, each of which may need its own Systems Approach. Maintenance success is more likely is it is considered well before the system enters service.

Disposal

The purpose of disposal is to remove a system element from the operational environment with the intent of permanently terminating its functions; and to deal with any waste products left behnd by the system. (NASA 2007) describes disposal from the vantage point of NASA space and ground systems.

Disposal requires its own enabling systems each of which may need its own Systems Approach. As discussed above, a large part of successful idsposal will need maintenance issues to have been considered before the system enters service.

References

Citations

Hitchins, D. (2007) Systems Engineering: A 21st Century Systems Methodology John Wiley and Sons.

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

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

Primary References

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

Additional References

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

---

Article Discussion

S. Friedenthal comment: Suggest deleting this section. (additional content added, and topic more integrated into value cycle, Rick A)

Brian Wells comments: This section should focus on the Operations, Maintenance and Disposal aspects of System Ownership. It should also point out the aspects of ownership as they relate to Product Systems versus Services Systems.

I would not delete the section, but I might retitle it to "Owning and Using Systems." I would start with pointing out that use does not require ownership, ie. with Service Systems. More on the sell-off of Product Systems can be added along with a better discussion of how ownership implies responsibility for operations, maintenance and disposal, but that the owner may also contract for the operation, maintenance and disposal. Maintenance and the necessary equipment and systems may be obtained as a service, for example.

The introduction can be improved. (I am willing to help with this as time allows.) The section on Acquirer/Supplier Agreement should be reduced or eliminated and instead more on how the transition from the developer to the owner takes place should be provided. (I am also willing to help with this.)

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures

--Radcock 14:08, 23 August 2011 (UTC)

--Apyster 18:04, 5 September 2011 (UTC)