Engineered System Context

The system context describes the system in its external environment. The system context includes the boundaries of the system of interest (soi) and the relationship of that system of interest to the environment in which it exists.

System of Interest

Many natural systems and social systems are formed through the inherent cohesion between elements, which leads them to form stable structures and hold those structures when disturbed. We can observe a process in nature where simple systems form into more complex systems over time (Simons 1962).

Laszlo (Laszlo 1972) summarizes the properties which prompt us to consider a set of related elements as a whole:

1. Systemic state (or wholeness): a property of the system elements and how they are related in the system structure which leads them to create a cohesive whole.
2. Adaptive Self regulation: all systems will tend to return to a defined steady state in response to external stimulus.
3. Adaptive self organization: some systems not only return to a previous steady state but also reorganize to create new steady states which are more resistant to change.
4. Holon: systems displaying characteristics 2 and 3 will tend to develop increasing hierarchical structures.

Thus, a collection of elements which tend to group together will form themselves into coherent wholes. Once formed they will tend to stay in those structures and to combine and evolve further into more complex stable states to exploit this cohesion to sustain themselves in the face of threats or environmental pressures. (Simon 1962) has shown that systems which evolve via a series of stable “hierarchical intermediate forms” will be more successful, adapting more quickly to environmental change.

Natural and social systems can be understood and managed through an understanding of this wholeness. We can also deliberately create engineered systems to take advantage of this holism .

When humans observe or interact with a system, they allocate boundaries and names to parts of the system. This naming should follow the natural hierarchy of the system, but will also reflect the needs and experience of the observer to associate elements with common attributes of purposes relevant to their own. Thus, we will identify a number of systems of interest (soi) (Flood and Carson 1993), which must be both relevant to our interest but also include a set of elements which represent a system whole. This way of observing systems is call Systemic Resolution in which the complex system relationships are focused around a particular system boundary. When we use this approach to focus on part of a larger system we employ a balance of reductionism and holism which sits at the heart of a systems approach.

The Systems Thinking Paradox

If we wish to examine a particular group of element in more detail, to understand, use or change them in some way, we are faced with an apparent “Systems Thinking Paradox”. We can only truly understand a system by considering all of its possible relationships and interactions, inside and outside of its boundary and in all possible future situations (of both system creation and life); but this makes it apparently impossible for people to understand a system or to predict all of the consequences of changes to it.

If this means that we must consider all possible system relationships and environmental conditions to fully understand the consequences of creating or changing a system, how can we ever do anything useful in the real world?

In many ways this is the essence of all human endeavours, technical, managerial, social or political, the so called known and unknown unknowns. The systems approach is a way of tackling real world problems which makes use of the tools of systems science to enable useful systems to be engineered and used. The key principle of the systems approach is that we must hide some of the detail of complex situations to allow us to focus on changes to a system element; but that we can consider the impact of any changes we might make across sufficient related system components to fit within acceptable commercial and social risks. Engineering and management disciplines deal with this by gathering as much knowledge as necessary to proceed at a risk acceptable to the required need. The assessment of what is enough and how much risk to take can, to some extent, be codified with rules and regulations; and managed through processes and procedures, but is ultimately a combination of the skill and judgement of people.

A systems context provides the tool for doing this, and is thus an essential part of any systems approach and hence of systems engineering.

System Context

We use the idea of a system context to define an engineered system of interest, and to capture and agree on the important relationships between it; the systems it works directly with and the systems which influence it in some way. All application of a systems approach (and hence of systems engineering) are applied to a system context, and not to an individual system. All system contexts are constructed around the following set of open system relationships (Flood and Carson 1993):

• The Narrower System of Interest (NSoI) is the system of direct concern to the observer. The focus of this system is driven by the scope of authority or control, recognizing that this may not capture all related elements.
• The Wider System of Interest (WSoI) describes a logical system boundary, containing all elements needed to fully understand system behavior. The observer may not have authority over all elements in the WSoI, but will be able to agree the relationships between WSoI elements and NSoI elements.
• The WSoI sits in an Environment. The immediate environment contains engineered, natural or social system with which the WSoI (and thus some elements of the NSoI) directly interact, exchanging material, information and/or energy to achieve its Goals or Objective.
• A Wider Environment completes the context, containing systems which have no direct interaction with the SoI, but which might influence decisions related to it during its life.
• (Flood 1987) extends the context to include a Meta-System (MS), which sits outside of the WSoI and exercises direct control over it.

The choice of the System of Interest SoI for particular activities depends upon what can be changed and what must remain fixed. The SoI will include the NSoI, but may also include WSoI and MS if appropriate. Thus, a context allows an observer to take a reductionist view of the SoI he/she has direct concern for and authority over, while providing the system relationships and influences needed to enable them to keep a holistic view of the consequence of any actions they take.

System and System of Systems Context

How is system context applied to different kinds of engineered system problems?

(Flood and Carson 1993) identify two ways to identify system boundaries. A bottom-up, or structural approach, in which we start with significant system elements and build out. A top down, or behavioral approach, in which we identify major systems needed to fulfill a goal, and then work down. They identify a number of rules, proposed by (Beishon 1980) and (Jones 1982) to help in the select of the best approach.

The single most important principle of the systems approach is that it is applied to a context and not to a single system (INCOSE 2011). The systems approach is applied to a SoI, defined within a system context. One of the key distinctions between product, service, and enterprise systems engineering is how widely the SoI boundary is drawn.

For lower level, less complex, systems the WSoI can represent levels of product system hierarchy; e.g. an engine management unit as part of an engine; an engine as part of a car.

The WSoI in a system context may encapsulate some aspects of system of systems ideas, for sufficiently complex systems. In these cases the WSoI represents a collection of system with their own objectives and ownership, with which our NSoI must cooperate with towards a shared goal, e.g. a car and driver contributing to a transport service .

This view of a system of systems context as a means to support the engineering of a NSoI product system is one way in which a systems approach can be applied. We can also apply it directly to the system of systems, e.g. a flexible, multi vehicle transport service, or transport as part of a commercial retail enterprise . In this case the NSoI aspect of the context no longer applies. The WSoI will consist of a set of cooperating systems, each of which might be changed or replaced to synthesis a solution. The context may also need to represent loose coupling, with some systems moving in or out of the context depending on the need; or late binding with systems joining the context only at or close to delivery of the service.

It is important that the ideas of a balance between reductionist and holistic thinking are maintained. The Types of Systems topic includes a discussion of how contexts can be described for these kinds of system.

References

Works Cited

Beishon, J. 1980. Systems Organisations: the Management of Complexity. Milton Keynes; Open University press.

Flood, R. L. 1987. "Some Theoretical Considerations of Mathematical Modeling." In Problems of Constancy and Change (proceedings of 31st Conference of the International Society for General Systems Research, Budapest), Volume 1, p. 354 - 360.

Flood, R. L. and E.R. Carson. 1993. Dealing with Complexity: An Introduction to the Theory and Application of Systems Science, 2nd ed. New York, NY, USA: Plenum Press.

INCOSE. 2011. INCOSE Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.

Jones, L. 1982, "Defining System Boundaries in Practice: Some Proposals and Guidelines." Journal of Applied Systems Analysis, 9: 41-55.

Laszlo, E., ed. 1972. The Relevance of General Systems Theory: Papers Presented to Ludwig von Bertalanffy on His Seventieth Birthday, New York, NY, USA: George Brazillier.

Simon, H. A. 1962. "The Architecture of Complexity." Proceedings of the American Philosophical Society, 106(6) (Dec. 12, 1962): 467-482.

Primary References

Flood, R. L. and E.R. Carson. 1993. Dealing with Complexity: An Introduction to the Theory and Application of Systems Science, 2nd ed. New York, NY, USA: Plenum Press.

Engineered Systems

Engineered systems:

1. Are created, used and sustained to achieve a purpose, goal or mission that is of interest to an enterprise , team , or an individual.
2. Require a commitment of resources for development and support.
3. Are driven by stakeholders with multiple views on the use or creation of the system, or with some other stake in the system, its properties or existence.
4. Contain engineered hardware, software, people, services or a combination of these.
5. Exist within an environment that impacts the characteristics, use, sustainment and creation of the system.

Engineered systems typically:

1. Are defined by their purpose, goal or mission.
2. Have a life cycle and evolution dynamics.
3. May include human operators (interacting with the systems via processes) and other natural components that must be considered in the design and development of the system.
4. Are part of a system-of-interest hierarchy.

The systems approach includes models and activities useful in the understanding, creation, use and sustainment of Engineered Systems. Disciplines which use a systems approach (such as Systems Engineering) deal with the apparent System Context. This is done by creating a system context focused on a selected Engineered system of interest (soi) .

Historically, “Economists divide all economic activity into two broad categories, goods and services. Goods-producing industries are agriculture, mining, manufacturing, and construction; each of them creates some kind of tangible object. Service industries include everything else: banking, communications, wholesale and retail trade, all professional services such as engineering, computer software development, and medicine, nonprofit economic activity, all consumer services, and all government services, including defense and administration of justice....” (Encyclopedia Britannica 2011). A product or service is developed and supported by an individual, team, or enterprise. For example, express package delivery is a service offered worldwide by many enterprises, both public and private, both small and large.

The nature of engineered systems has changed dramatically over the past several decades from systems dominated by hardware (mechanical and electrical) to systems dominated by software. In addition systems that provide services, without delivering hardware or software, have become common as the need to obtain and use information has become greater. Recently organizations have become sufficently complex that the techniques that were demonstrated to work on hardware and software have been applied to the engineering of enterprises.

Three specific types of engineered system context are generally recognized in systems engineering: product system , service system and enterprise system . This categorization permeates the SEBoK; e.g., Part 4 Applications of Systems Engineering explores how systems engineering is applied differently in product, service, and enterprise systems. The notion of enterprises and enterprise systems permeates Part 5 Enabling Systems Engineering.

Products, Services and Enterprises

In general usage, the terms "product" and "service" describe the thing exchanged through an Customer/Supplier agreement. This might be a commercial agreement, one funded publicly or by a charity or other arrangement. One of the differences between a product and service is that a product is an artifact acquired to be used towards achievement of an outcome while a service is an outcome supplied directly to a user.

The terms customer and user are often used interchangably in engineeing and management discipline. The INCOSE Handbook (INCOSE 2011), makes the following specific distinctions between people associated with a system:

• Acquirer, the stakeholder that acquires or procures a product or service from a supplier
• Supplier, an organization or individual that enters into an agreement with the acquirer for the supply of a product or service
• Operator: an individual who, or organizaton that, contributes to the functionality of a system and draws on knowledge, skills and procedures to enable the function
• User, individual who, or group that, benefits from a system during its utilization

Product systems, consisting of hardware, software and humans, have traditionally been the focus of systems engineering efforts. These systems are delivered to the acquirer and operated to accomplish the goals that led to the requirements for the system. These requirements in turn being derived from the need to provide services to one or more users as part of an enterprise. The supply of a service implies the direct supply of an outcome often related to the supply of products, e.g. a maintenance or training or cleaning service. This is not the same as the supply of a service system, see discussion below.

In traditional system engineering, the term service or service system describes the wider system context which describes the acquirer's need to deliver user value. In this case, the service system is the fixed system definition of how the acquiring enterprise will use products to enable the supply 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 pre-defined services to users.

More recently the term "service systems" has been used to describe a system that is engineered so enterprises can offer services directly users, without the need to hold all of the products and services this entails within the enterprise. This requires expanding the definition of supplier to:

• Product Supplier, an organization or individual that enters into an agreement with an acquirer for the supply of a product or related product support services.
• Service System Supplier, an organization or individual that enters into an agreement with an acquirer for the supply of a service system.
• Service Supplier, an organization or individual that enters into an agreement with a user for the supply of a service.

These service systems tend to be configured dynamically to deal with problems that traditional static services find difficult. This view of service system employs "late binding", with product systems not owned by the enterprise but used to enable the service to be offered as close as possible to the time it is needed. This is the defintion of Service System used in the Service Systems Engineering topic in Part 4.

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.

The 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.

1. 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)
2. 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)
3. 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)
4. 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.

The Enterprise View of Engineered Systems

This article defines enterprises and enterprise systems; provides an overview of enterprise systems engineering and compares and contrasts enterprises and system of systems.

Enterprises and Enterprise Systems

An enterprise consists of a purposeful combination (e.g., network) of interdependent resources (e.g., people, processes, organizations, supporting technologies, and funding) that interact with 1) each other (e.g., to coordinate functions, share information, allocate funding, create workflows, and make decisions), and 2) their environment(s), to achieve (e.g., business and operational) goals through a complex web of interactions distributed across geography and time (Rebovich and White 2011, 4, 10, 34-35).

It is worth noting that an enterprise is not equivalent to “organization” according to this definition. This is a frequent misuse of the term enterprise. An enterprise includes not only the organizations that participate in it, but also includes people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, and intellectual property.

An enterprise may contain or employ service systems, along with product systems. An enterprise might even contain sub-enterprises.

Both product and service systems require an enterprise system to create them and an enterprise to use the product system to deliver services either internally to the enterprise or externally to a broader community. Thus the three types of systems are linked in all instances regardless of which type of system the developers considers the object of the development effort and which is delivered to the customer.

Enterprise Systems Engineering

enterprise systems engineering (ese) is the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise.

To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a system,” rather than as a collection of functions connected solely by information systems and shared facilities (Rouse 2009).

There are several names in the literature for ESE, and this field is evolving:

The body of knowledge for enterprise engineering is evolving under such titles as enterprise engineering, business engineering, and enterprise architecture. Many systems and software engineering principles are applicable to enterprise engineering, but enterprise engineering’s unique complexities require additional principles. Enterprise engineering’s intent is to deliver a targeted level of enterprise performance in terms of shareholder value or customer satisfaction. Enterprise engineering methods include modeling; simulation; total quality management; change management; and bottleneck, cost, workflow, and value-added analysis. (Joannou 2007)

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 engineering may also be aimed at optimizing back stage processes, the internal operations, of an organization or an institution by exploiting advances in technology (particularly IT and processes). In these cases the engineered systems are enterprise systems.

Enterprises may offer products (goods) and/or services and the product systems engineering must not only look at the development and delivery of the products but also the alignment and optimization of the product delivery with the enterprise objectives. Similarly, in service systems engineering the main focus is on intangible value delivery to the end-customer (externally focused: front stage) where internal and external processes must be synchronized. However, with the rapid advances in Information and Communications Technologies (ICT) the boundaries between internal and external processes are in many instances very blurry. Current research on systems engineering 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 do the engineering not only across the enterprise itself but may also get involved in the engineering of the service systems and products systems that the enterprise depends on in order to achieve its goals.

Enterprise systems are unique, compared to product and service systems, in that they are constantly evolving, they rarely have detailed configuration controlled requirements, they typically have the goal of providing shareholder value and customer satisfaction, which are constantly changing and are difficult to verify, and they exist in a context (or environment) that is ill-defined and constantly changing. The enterprise systems engineer must consider and account for these factors in their processes and methods.

Enterprises and System of Systems

According to Maier’s definition, an enterprise would not necessarily be called a system of systems (sos) since the systems within the enterprise do not usually meet the criteria of operational and managerial independence. In fact, the whole purpose of an enterprise is to explicitly establish operational dependence between systems that the enterprise owns and/or operates in order to maximize the efficiency and effectiveness of the enterprise as a whole. Therefore, it is more proper to treat an enterprise system and an SoS as different types of things, with different properties and characteristics (DeRosa 2005).

It is true that an enterprise can be treated as a system itself and is comprised of many systems within the enterprise, but this discussion will reserve the term SoS to those systems that meet the criteria of operational and managerial independence. This distinction was also used within the MITRE Corporation in their Enterprise Systems Engineering (ESE) Office (Rebovich and White 2010, 477).

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.

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

Joannou, P. 2007. "Enterprise, Systems, and Software—The Need for Integration." IEEE Computer. 40(5) (May): 103-105.

Rebovich, G., and B.E. White (eds.). 2011. Enterprise Systems Engineering: Advances in the Theory and Practice. Boca Raton, FL, USA: CRC Press.

Rouse, W. B. 2009. "Engineering the Enterprise as a System." In Handbook of Systems Engineering and Management, 2nd ed. A.P. Sage and W.B. Rouse (eds.). New York, NY, USA: John Wiley and Sons.

DeRosa, J. K. 2005. “Enterprise Systems Engineering.” Air Force Association, Industry Day, Day 1, 4 August 2005, Danvers, MA. Available at: https://www.paulrevereafa.org/IndustryDay/05/presentations/index.asp.

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.

Rebovich, G., and B.E. White (eds.). 2011. Enterprise Systems Engineering: Advances in the Theory and Practice. Boca Raton, FL, USA: CRC Press.

Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation". Systems Engineering. 8(2): 138-50.

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.

Rouse, W.B. 2009. "Engineering the Enterprise as a System". In Handbook of Systems Engineering and Management, 2nd ed. A.P. Sage and W.B. Rouse (eds.). New York, NY, USA: Wiley and Sons.

Bernus, P., L. Nemes, and G. Schmidt (eds.). 2003. Handbook on Enterprise Architecture. Heidelberg, Germany: Springer.

Valerdi, R. and D.J. Nightingale. 2011. "An Introduction to the Journal of Enterprise Transformation." Journal of Enterprise Transformation 1(1):1-6.

DeRosa, J. K. 2006. “An Enterprise Systems Engineering Model.” Proceedings of the 16th Annual International Council on Systems Engineering, 9-13 July 2006, Orlando, FL, USA.

---

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