Enterprise Systems Engineering

Here are the sections of this top-level article, which provides an introduction to the discipline of enterprise systems engineering (ese) :

Purpose

This article, and its sub-articles (listed as "Topics" below), provides an introduction to systems engineering (SE) at the enterprise level in contrast to “traditional” SE (TSE) (sometimes called “conventional” or “classical” SE) performed in a development project or to “product” engineering (often called product development in the SE literature).

This Knowledge Area includes the following Topics:

The concept of enterprise was instrumental in the great expansion of world trade in the 17th century (see note 1) and again during the Industrial Revolution of the 18th and 19th centuries. The world may be at the cusp of another global revolution enabled by the Information Age and the technologies and cultures of the Internet (see note 2). The discipline of SE now has the unique opportunity of providing the tools and methods for the next round of enterprise transformations. (ESE) is an emerging discipline that focuses on frameworks, tools, and problem-solving approaches for dealing with the inherent complexities (see also Complexity) of the enterprise. Furthermore, ESE addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. A good overall description of ESE is provided by Rebovich and White (2011).

Note 1. “The Dutch East India Company… was a chartered company established in 1602, when the States-General of the Netherlands granted it a 21-year monopoly to carry out colonial activities in Asia. It was the first multinational corporation in the world and the first company to issue stock. It was also arguably the world's first mega-corporation, possessing quasi-governmental powers, including the ability to wage war, negotiate treaties, coin money, and establish colonies.” (emphasis added, http://en.wikipedia.org/wiki/Dutch_East_India_Company)

Note 2. This new revolution is being enabled by cheap and easily usable technology, global availability of information and knowledge, and increased mobility and adaptability of human capital. The enterprise level of analysis is only feasible now because organizations can work together to form enterprises in a much more fluid manner.

Key Terms

Enterprise

An enterprise consists of a purposeful combination (e.g., a network) of interdependent resources (e.g., people, processes, organizations, supporting technologies, and funding) that interact with:

each other to coordinate functions, share information, allocate funding, create workflows, and make decisions, etc.
their environment(s) to achieve business and operational) goals through a complex web of interactions distributed across geography and time (Rebovich and White 2011, 4-35).

Enterprise vs Organization

It is worth noting that an enterprise is not equivalent to "organization” according to the definition above. This is a frequent misuse of the term enterprise. The figure below shows that 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, intellectual property, and so on.

Some enterprises are organizations, but not all enterprises are organizations. Likewise, not all organizations are enterprises. Some enterprises have no readily identifiable "organizations" in them. Some enterprises are self-organizing (i.e., not organized by mandate) in that the sentient beings in the enterprise will find for themselves some way in which they can interact to produce greater results than can be done by the individuals alone. Self-organizing enterprises are often more flexible and agile than if they were organized from above (Dyer and Ericksen 2009, Stacey 2006).

One type of enterprise architecture that supports agility is a non-hierarchical organization without a single point of [[]Control (glossary)]. Individuals function autonomously, constantly interacting with each other to define the work that needs to be done. Roles and responsibilities are not predetermined but rather emerge from individuals’ self-organizing activities and are constantly in flux. Similarly, projects are generated everywhere in the enterprise, sometimes even from outside affiliates. Key decisions are made collaboratively, on the spot, and on the fly. Because of this, knowledge, power, and intelligence are spread through the enterprise, making it uniquely capable of quickly recovering and adapting to the loss of any key enterprise component . (http://en.wikipedia.org/wiki/Business_agility)

In spite of this lack of "organization" in some enterprises, SE can still contribute much in the engineering of the enterprise, as described in the articles below. However, SE must be prepared to apply some non-traditional approaches in doing so. Hence the need for embracing the new discipline called Enterprise Systems Engineering (ESE).

Extended Enterprise

Sometimes it is prudent to consider a broader scope than merely the "boundaries" of the organizations involved in an enterprise. In some cases, it is necessary (and wise) to consider the "extended enterprise" in your modeling, assessment, and decision making. This could include upstream suppliers, downstream consumers and end user organizations, and perhaps even "sidestream" partners and key stakeholders. The extended enterprise can be defined as:

Wider organization' representing all associated entities - customers, employees, suppliers, distributors, etc. - who directly or indirectly, formally or informally, collaborate in the design , development, production, and delivery of a product (or service ) to the end user. (http://www.businessdictionary.com)

Enterprise SE

Enterprise Systems Engineering (ESE), for the purpose of this article, is defined as the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise (see note 3). To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a system ,” rather than merely as a collection of functions connected solely by information systems and shared facilities (Rouse 2009). While a systems perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers.

Note 3. This form of systems engineering (i.e., ESE) includes 1) those traditional principles, concepts, and methods that work well in an enterprise environment, plus 2) an evolving set of newer ideas, precepts, and initiatives derived from complexity theory and the behavior of complex systems (such as those observed in nature and human languages).

Services vs Products vs Enterprises

A service system is a collection of items (or entities) that perform the operations, administration, management and provisioning (OAM&P) of resources that together provide the opportunities to co-create value by both the service provider and the service consumer.

A collection of services is not necessarily a service system. In fact, this collection of services is often merely a product system that is one of the resources being OAM&P'ed by the service system. A product system can be composed of hardware, software, personnel (see note 4), facilities, data, materials, techniques, and even services. Each of these product system elements can be "engineered."

Note 4. Even personnel are engineered in the sense that their roles and responsibilities are specified precisely and trade-offs are made about which functions are performed by these people versus by hardware or software. People are "produced" in the sense that untrained people are trained to perform their allocated system functions, unknowledgeable people are educated to find or create the information they need to do their assigned task, and uninformed people are taught how to get access to the data they need and how to extract relevant information from that data.

So, it is important to understand the difference between the services "enabled" by a service system versus the services that are the elements of a service system entity. See the Service Systems Engineering article for more information about services and how they are engineered.

Likewise, a collection of services is not necessarily an enterprise system. An enterprise may be composed of service systems, along with product systems, as well as policies, procedures, properties, knowledge, financial capital, intellectual capital, and so on. An enterprise might even contain sub-enterprises. 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.

Creating Value

The basic concepts that drive the enterprise context of SE are shown in Figure 1. There are three types of organization of interest – businesses, projects, and teams (see note 4). A typical business participates in multiple enterprises through its portfolio of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.

Note 4. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.

Resource Optimization

A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources – people, knowledge, assets – across teams, projects, and business units. (Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its stakeholders.) At one extreme in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, and managing all assets required for their delivery of products or services.

At the other extreme in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called Systems Engineering Organizational Strategy.

Note: Red text in this figure is to indicate changes from the version of this diagram in SEBOK draft v0.25.

Figure 1. Organizations Manage Resources to Create Enterprise Value (Figure Developed for BKCASE)

Enabling SE in the Organization

SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE capability can make a substantial contribution at the enterprise level as well as the project level. The article called Systems Engineering Organizational Strategy discusses enabling SE in the organization, while the article called Enabling Businesses and Enterprises to Perform Systems Engineering focuses on the cross-organizational functions at the business and enterprise levels. Competence of individuals is discussed in the article called Enabling Individuals to Perform Systems Engineering.

Kinds of Knowledge Used by the Enterprise

Knowledge is a key resource for SE. There are generally two kinds of knowledge, explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.

Projects, Programs & Businesses

The term “program” is used in various ways in different domains. In some domains a team can be called a program (e.g., customer support team is their customer relationship "program"), in others an entire business is called a program (e.g., wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases the terms project and program are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are Program Managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A Program Manager may have a portfolio of items (services, products, facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.

Practical Considerations

When it comes to performing SE at the enterprise level there are several good practices to keep in mind (Rebovich and White 2011):

Set enterprise fitness as the key measure of system success. Leverage game theory and ecology, along with the practices of satisfying and governing the commons.
Deal with uncertainty and conflict in the enterprise though adaptation: variety, selection, exploration, and experimentation.
Leverage the practice of layered architectures with loose couplers and the theory of order and chaos in networks.

Enterprise governance involves shaping the political, operational , economic, and technical (POET) landscape. One should not try to control the enterprise like one would in a TSE effort at the project level.

Topics in the ESE Knowledge Area

This series of articles will first provide (1) some background on the scope of ESE, imperatives for enterprise transformation, and potential SE enablers for the enterprise. It will then discuss (2) how ESE relates to system of systems (SoS) and a federation of systems (FoS). Next it will describe (3) related business activities and necessary extensions of TSE that enable (4) ESE activities. Each of the ESE process activities is discussed (5) in the overall context of the unique circumstances in the operation of a large and complex enterprise. Finally, it will show (6) how ESE can be used to establish and maintain enterprise operational capabilities. These six Topics are listed below.

The topics contained within this knowledge area include:

References

Citations

Dyer, L. and Ericksen, J. 2009. "Complexity-based Agile Enterprises: Putting Self-Organizing Emergence to Work." In A. Wilkinson et al (eds.). "The Sage Handbook of Human Resource Management." London, UK: Sage: 436–457.

Rebovich, G., and B. E. White, eds. 2011. "Enterprise Systems Engineering: Advances in the Theory and Practice." Boca Raton, FL, USA: CRC Press, Taylor & Francis Group, Auerbach.

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

Stacey, R. 2006. "The Science of Complexity: An Alternative Perspective for Strategic Change Processes." In R. MacIntosh et al (eds.). "Complexity and Organization: Readings and Concersations." London, UK: Routledge: 74–100.

Primary References

Rebovich, G. and B. E. White, eds. 2011. "Enterprise Systems Engineering: Advances in the Theory and Practice." Boca Raton, FL, USA: CRC Press, Taylor & Francis Group, Auerbach.

Rouse, W. B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation". Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE) 8 (2): 138-50.

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

Bernus, P., Nemes L., and Schmidt G., eds. 2003. "Handbook on Enterprise Architecture", Berlin & Heidelberg, Germany: Springer-Verlag.

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

Additional References

Drucker, P. F. 1994. "The theory of business". Harvard Business Review (September/October 1994): 95-104.

Fox, M., J. F. Chionglo, and F. G. Fadel. 1993. "A common sense model of the enterprise". Paper presented at A 3rd Industrial Engineering Research Conference, Norcross, GA, USA.

Gøtze, J, ed. Journal of Enterprise Architecture. https://www.aogea.org/journal.

Joannou, P. 2007. "Enterprise, systems, and software—the need for integration". Computer, IEEE, May 2007.

Nightingale, D., and J. Srinivasan. 2011. "Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation." New York, NY, USA: AMACOM Press.

Nightingale, D., and R. Valerdi, eds. Journal of Enterprise Transformation. London, UK: Taylor & Francis. http://www.tandf.co.uk/journals/UJET.

Article Discussion

[Go to discussion page]

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

Signatures

--Blawson 20:41, 15 August 2011 (UTC)

--Janthony 15:57, 6 September 2011 (UTC)