The Enterprise as a System

From SEBoK
Jump to navigation Jump to search

6.3 The Enterprise as a System (3.1.2)

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). What distinguishes the design of enterprise systems from product/service systems is the inclusion of people as a component of the system, not merely as a user/operator of the system.

The term “enterprise system” has taken on a narrow meaning of only the information system an organization uses. Research and project experience has taught us that to design a good enterprise system, we need to adopt a much broader understanding of enterprise systems. The greater view of enterprise systems is inclusive of the processes the system supports, the people who work in the system, and the information [and knowledge] content of the system. (Giachetti 2010)

6.3.1

Enterprise Engineering

Another distinction 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.” [emphasis in original] (Giachetti 2010) Giachetti calls this new discipline “enterprise engineering.” We consider the enterprise engineering set of practices to be equivalent to what we call ESE in this article.

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)

6.3.2

Value Stream Analysis

Value stream analysis provides insights regarding where in the sequence of enterprise activities value is added as it moves towards the final delivery to customer or user. (Rother and Shook 1999) It relates each step to the costs entailed in that step in terms of resource consumption (i.e., money, time, energy and materials). In additional to direct costs, there may also be indirect costs due to overhead factors or infrastructure elements. This activity involves drawing a flowchart of the value stream for the enterprise as illustrated in Figure 6.

Value Stream Example

Figure 6. Value Stream Example (Source: TBD, 2010)

Analysis of this value stream diagram can highlight unnecessary space, excessive distance traveled, processing inefficiencies, and so on. Value stream mapping is associated with so-called “lean enterprise” initiatives. At Toyota, where the technique originated, it is known as “material and information mapping.” (Rother 2009) Various value stream mapping tools are available. (Hines and Rich 1997)

6.3.3

System of Systems (SoS)

The phrase “system of systems” is commonly used, but there is no widespread agree¬ment on its exact meaning, or on how it can be distinguished from a conventional system. A system is generally understood to be a collection of elements that interact in such a manner that it exhibits behavior that the elements themselves cannot exhibit. Each element (or component) of the system can be regarded as a system in its own right. Therefore, the phrase “system of systems” can technically be used for any system and, as such, would be a superfluous term. However, the meaning of this phrase has been examined in detail by (Maier 1998, 267-284), and his definition has been adopted by some people (AFSAB 2005). Maier provides this definition:

A system-of-systems is an assemblage of components which individually may be regarded as systems, and which possess two additional properties:

  • Operational Independence of the Components: If the system-of-systems is disassembled into its component systems the component systems must be able to usefully operate independently. That is, the components fulfill customer-operator purposes on their own.
  • Managerial Independence of the Components: The component systems not only can operate independently, they do operate independently. The component systems are separately acquired and integrated but maintain a continuing operational existence independent of the system-of-systems. (Maier 1998, 267-284)

Maier goes on further saying that “the commonly cited characteristics of systems-of-systems (complexity of the component systems and geographic distribution) are not the appropriate taxonomic classifiers.” (Maier 1998, 267-284) For further details on SoS, see the Systems Engineering Guide for SoS developed by the US Department of Defense (DoD). (DUS(AT) 2008) Four kinds of SoS have been defined. (Dahmann, Lane, and Rebovich 2008)

6.3.4

Federation of Systems (FOS)

Different from the SoS concept, but related to it in several ways, is the concept called “federation of systems.” This concept might apply when there is a very limited amount of centralized control and authority. (Sage and Cuppan 2001, 325-345) Each system in an FOS is very strongly in control of its own destiny, but “chooses” to participate in the FOS for its own good and the good of the “country,” so to speak. It is a coalition of the willing. An FOS is generally characterized by significant autonomy, heterogeneity, and geographic distribution or dispersion. (Krygiel 1999) Krygiel defined a taxonomy of systems showing the relationships among conventional systems, SoSs, and FOSs. This taxonomy has three dimensions: autonomy, heterogeneity, and dispersion. An FOS would have a larger value on each of these three dimensions than a non-federated SoS. An “Enterprise System,” as described above, could be considered to be an FOS if it rates highly on these three dimensions. However, it is possible for an enterprise to have components that are not highly autonomous, that are relatively homogenous, and are geographically close together. Therefore, it would be a mistake to say that an enterprise is necessarily the same as an FOS.

Dove points out that in order for a large enterprise to survive in the 21st century, it must be more agile and robust (Dove 1999). Handy (1992, 59-67) describes a federalist approach called “New Federalism” which identifies the need for structuring of loosely coupled organizations to help them adapt to the rapid changes inherent in the Information Age. This leads to the need for virtual organizations where alliances can be quickly formed to handle the challenges of newly identified threats and a rapidly changing marketplace. (Handy 1995, 2-8) Handy sets out to define a number of federalist political principles that could be applicable to an FOS. Handy’s principles have been tailored to the domain of SE and management by Sage and Cuppan (2001, 325-345):

  • Subsidiarity
  • Interdependence
  • Uniform and standardized way of doing business
  • Separation of powers
  • Dual citizenship
  • Scales of SE

6.3.5

Scales of SE

According to Maier’s definition, an enterprise would not necessarily be called a 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. This distinction is illustrated in Figure 7, where three corresponding categories of SE are shown. (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 ESE Office. (Rebovich and White 2011)

Different Groupings and Patterns Revealed at Different Scales

Figure 7. Different Groupings and Patterns Revealed at Different Scales (Source: (DeRosa 2005))

6.3.4

Relationships between Enterprise and SoS

An enterprise may require a particular operational capability that is brought into being by connecting together a chain of systems that together achieve that capability. Any one of these systems in the chain cannot by itself provide this capability. The desired capability is the emergent property of this chain of systems. This chain of systems is sometimes called an SoS. However the enterprise that requires this capability rarely has direct control over all the systems necessary to provide this full capability. This situation is illustrated in Figure 8. (Martin 2010)

Relationships between an Enterprise and SoSs

Figure 8. Relationships between an Enterprise and SoSs (Source: (Martin 2010))

Enterprise E1 (in the example above) has full control over SoS2 but not full control over SoS1. TSE can be applied to the individual systems (S1, S2, …, S53) shown within each enterprise, but needs to be augmented with additional activities to handle SoS and enterprise kinds of issues.

6.3.1

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.

Additional References

All additional references should be listed in alphabetical order.

Article Discussion

[Go to discussion page]