Difference between revisions of "Enabling Systems Engineering"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(60 intermediate revisions by 9 users not shown)
Line 1: Line 1:
The other Parts of the SEBoK, especially Part 3 on [[Systems Engineering and Management]], are a guide to knowledge about how to perform [[Systems Engineering (glossary)|systems engineering]] (SE); e.g., about how to develop [[Requirement (glossary)|requirements]], select an appropriate [[Life Cycle (glossary)|life cycle]] model, and [[Architecture (glossary)|architect]] a [[System of Systems (SoS) (glossary)|system of systems]].  Part 5 focuses on what an [[Enterprise (glossary)|enterprise]] needs to do in order to be effective at performing those SE activities described elsewhere in the SEBoK; e.g., whether an organization allows a project manager to select the systems engineers he or she employs, and, if so, what [[Competency (glossary)|competencies]]  the project manager might seek in those systems engineers.
+
----
 +
'''''Lead Authors:''''' ''Art Pyster, Hillary Sillitto, Alice Squires'', '''''Contributing Authors:''''' ''Dick Fairley, Bud Lawson, Dave Olwell, Deva Henry, Rick Adcock''
 +
----
 +
Part 5 of the Guide to the SE Body of Knowledge (SEBoK) is a guide to knowledge about how an {{Term|Enterprise (glossary)|enterprise}} prepares and positions itself to effectively perform the {{Term|Systems Engineering (glossary)|systems engineering}} (SE) activities described elsewhere in the SEBoK.
  
For purposes of this Part, there are just three levels of an organization defined: the enterprise, a [[Team (glossary)|team]], and individuals.  Enterprises and teams can be decomposed into constituent sub-enterprises and sub-teams indefinitely.  The Part 2 article [[Types of Systems]] elaborates further on the different types of enterprises.
+
SE activities — how to develop {{Term|Requirement (glossary)|requirements}}, select an appropriate {{Term|Life Cycle (glossary)|life cycle}} model, and {{Term|Architecture (glossary)|architect}} a {{Term|System of Systems (SoS) (glossary)|system of systems}}, and so on — are covered elsewhere, especially in Part 3, [[Systems Engineering and Management]]. An organization that desires to do these things effectively must work through questions like whether to allow a project manager to select the systems engineers he or she employs, and, if so, what {{Term|Competency (glossary)|competencies}} the project manager might seek in those systems engineers. These are the kinds of questions that Part 5 explores.
  
To download a PDF of Part 5, please [http://www.sebokwiki.org/075/images/7/7a/SEBoK075_Part5.pdf click here].
+
The discussion defines three levels of organization: {{Term|Enterprise (glossary)|enterprise}} or organization, {{Term|Team (glossary)|team}}, and individual. To adapt an example to a more complex organizational structure, simply decompose enterprises into sub-enterprises and teams into sub-teams, as needed. For more about the different types of enterprises, see [[Types of Systems]] in Part 2.
 +
 
 +
[[File:SEBoK_Context_Diagram_Inner_P5_Ifezue_Obiako.png|centre|thumb|600x600px|'''Figure 1 SEBoK Part 5 in context (SEBoK Original).''' For more detail see [[Structure of the SEBoK]]]]
  
 
==Knowledge Areas in Part 5==
 
==Knowledge Areas in Part 5==
Each part of the SEBoK is divided into knowledge areas ([[Acronyms|KAs]]), which are groupings of information with a related theme. The KAs in Part 5 explore how the three levels of an organization enable SE:
+
Each part of the SEBoK is composed of knowledge areas (KA). Each KA groups topics around a theme related to the overall subject of the part.  
 +
 
 +
The KAs in Part 5 explore how to the performance of systems engineering from three different lenses:
  
 
*[[Enabling Businesses and Enterprises]]
 
*[[Enabling Businesses and Enterprises]]
 
*[[Enabling Teams]]
 
*[[Enabling Teams]]
 
*[[Enabling Individuals]]
 
*[[Enabling Individuals]]
 +
 +
==Common Practices==
 +
 +
There are as many different ways to enable SE performance as there are organizations, and every organization's approach is detailed and unique. Nevertheless, common practices, methods, and considerations do exist. Part 5 uses them as a framework to structure the relevant knowledge.
 +
 +
SE activities that support business needs and deliver value are enabled by many factors, including:
 +
*Culture (see [[Culture]]),
 +
*SE competencies (see [[Determining Needed Systems Engineering Capabilities in Businesses and Enterprises]]) and how the organization grows and deploys its workforce to acquire them, and
 +
*SE tooling and infrastructure (see [[Systems Engineering and Management]] in Part 3).
  
 
==Enterprises and Businesses==
 
==Enterprises and Businesses==
  
The introductory paragraphs above noted that Part 5 divides organizations into three levels: enterprise, team, and individual. A [[Business (glossary)|business]] is a special type of enterprise which usually has a legal structure and a relatively centralized control structure; e.g., as a corporation or a unit of a company or government agency that creates a specific product line or offers specific services. An enterprise may be a traditional business, but can also cross traditional business boundaries; e.g., the healthcare system of a nation is an enterprise which does not have a centralized legal authority and has a very loose form of governance involving hospitals, insurance companies, medical equipment manufacturers, pharmaceutical companies, government regulators, etc. Another example of an enterprise which is not a traditional business is the set of companies that form the supply chain for a manufacturer, such as the thousands of companies that contribute parts and services enabling Apple to create, distribute, and support the iPhone.  Often significant actions that enable SE are conducted by traditional businesses rather than by less well-structured enterprises. Throughout this article and others in Part 5, the term "business or enterprise" may be shortened to just "business" or "enterprise" depending on the point being made. The reader should look at [[Enterprise Systems Engineering]] in Part 4 of the SEBoK for further elaboration on the distinction between businesses and enterprises and the value of systems engineering of enterprises to them. The Part 4 [[Systems of Systems (SoS)]] Knowledge Area also provides useful insight into the tighter control over SE that businesses usually have (the equivalent of a Directed SoS) relative to the looser control that enterprises that lack a traditional business structure usually have.
+
The fact that Part 5 uses two terms, “Enterprise” and “Business,” to name a single level of organization, indicates that the two are closely related. In many contexts it is not necessary to make any distinction between them: an {{Term|Enterprise (glossary)|enterprise}} may be a traditional business, and a {{Term|Business (glossary)|business}} can be seen as a special type of enterprise. For the sake of brevity, the more general term "organization" may be used to mean “business or enterprise” throughout Part 5.
  
An enterprise operates in an organizational context that affects how it approaches SE and therefore how it enables SE performance; e.g., a business that sells to the general commercial marketplace will typically have many fewer constraints on how it practices SE than one which performs contract work for a government agency. A business that creates systems with very demanding characteristics, such as aircraft, typically has a much more rigorous and planned approach to SE than one which is creating less demanding systems, such as an app for a smartphone.  
+
Traditional businesses usually have a legal structure and a relatively centralized control structure. Such a business may be a corporation, or a unit of a company or government agency, that creates a product line or offers services.
 +
 
 +
On the other hand, an enterprise can be structured in a way that excludes description as a business. This happens when an enterprise crosses traditional business boundaries, lacks a centralized legal authority, and has relatively loose governance. One example is the healthcare "system" in the US which encompasses hospitals, insurance companies, medical equipment manufacturers, pharmaceutical companies, and government regulators. Another is the set of companies that form the supply chain for a manufacturer, such as the thousands of companies whose parts and services Apple uses to create, distribute, and support the iPhone.
 +
 
 +
Significant actions that enable SE are often conducted by traditional businesses rather than by less tightly structured enterprises. Even so, organizational context affects how the business approaches SE and therefore how it enables SE performance. A business that sells to the general commercial marketplace typically has far fewer constraints on its SE practices than one which performs contract work for a government agency. A business that creates systems with very demanding characteristics, such as aircraft, typically has a much more rigorous and planned approach to SE than one which creates less demanding systems, such as a smartphone app.
 +
 
 +
Traditional businesses are intended to be permanent, and typically offer a {{Term|Portfolio (glossary)|portfolio}} of products and services, introduce new ones, retire old ones, and otherwise seek to grow the value of the business. Sometimes a single product or service has such value and longevity that it spawns a business or enterprise just for its creation, maintenance, and support. The Eurofighter Typhoon aircraft, for example, was developed by a consortium of three corporations that formed a holding company specifically to provide support and upgrade services throughout the in-service life of the aircraft.
 +
 
 +
For more on the distinction between businesses and enterprises and the value of systems engineering of enterprises to them, see [[Enterprise Systems Engineering]] in Part 4. [[Systems of Systems (SoS)]], also in Part 4, contrasts the tighter control over SE that is usual for businesses with the looser control that is usual for enterprises lacking a traditional business structure. [[Groupings of Systems]] in Part 2 discusses the Directed SoS to which the traditional business may be equivalent.
  
 
==Teams==
 
==Teams==
  
Teams are usually formed for a specific purpose of limited duration, such as creating a new system or upgrading an existing service or product.  Once the new system has been created and delivered or the existing service or product has been upgraded and fielded, the team responsible for that effort is usually disbanded and the individuals associated with the effort are assigned to new tasks. However, there are exceptions; e.g., a team of systems engineers housed in a corporate office to assist troubled programs throughout the corporation could persist indefinitely. On the other hand, businesses typically have permanence. They usually offer a [[Portfolio (glossary)|portfolio (glossary)]] of products and services, introduce new ones, retire old ones, and otherwise seek to grow the value of the business. In a corporation, management of that portfolio might be centralized under the direction of the corporate executives. In a non-business enterprise, such as a national healthcare system, there may be only loose coordination of execution among many businesses; e.g., a national healthcare system includes physicians, drug companies, hospitals, government regulatory agencies, etc. A business may offer its products and services to a single customer; e.g., a small supplier that makes a single product solely for a large manufacturer. Sometimes, a single product or service has such value and longevity that it spawns a business or enterprise just for its creation, maintenance, and support; for example, the Eurofighter Typhoon aircraft was developed by a consortium of three companies that formed a holding company specifically for the purpose of providing support and upgrade services throughout the in-service life of the aircraft.
+
Teams operate within the context of the businesses in which they reside. This context determines how the team is enabled to perform SE.
  
A team operates within the context of the business in which it resides; e.g., a business may choose to give a team a lot of autonomy on key technical decisions, most of which are either made by systems engineers on the team or in consultation with team systems engineers.  On the other hand, a team could be constrained by business policies, practices, and culture; e.g., a business could create a generic set of SE processes that all teams are to tailor and use. The business could even require that the team gain approval for its tailored SE process from a higher level technical authority.
+
For example, a business may grant a team wide autonomy on key technical decisions, which are made either by team systems engineers or in consultation with team systems engineers.  On the other hand, the same business could instead create a generic set of SE processes that all teams are to tailor and use, constraining the team to adhere to established business policies, practices, and culture. The business could even require that the team gain approval for its tailored SE process from a higher-level technical authority.
  
==Common Practices==
+
Teams are usually formed for a limited duration to accomplish a specific purpose, such as creating a new system or upgrading an existing service or product. Once the purpose has been fulfilled, the team responsible for that effort is usually disbanded and the individuals associated with the effort are assigned to new tasks. Exceptions do happen, however. For example, a team of systems engineers tasked with assisting troubled programs throughout a corporation could persist indefinitely.
SE activities that support a business' needs and deliver intended value are enabled by many factors, such as the organization's culture (See [[Culture]]), SE competencies (See [[Determining Needed Systems Engineering Capabilities in Businesses and Enterprises]]), SE tooling and infrastructure, and how the organization grows and deploys its workforce in order to arm it with those competencies.  There are as many different ways to enable SE performance as there are organizations, and every organization's approach is highly detailed and unique. Nevertheless, the many common practices, methods, and considerations that organizations use can provide a framework to structure the relevant knowledge. Part 5 discusses those enabling common practices and methods of businesses, teams, and individuals, and begins with an articulation of strategies that enable SE to be performed well by a business. Specific tools and information technology infrastructure to perform SE are not discussed here, but are addressed in Part 3, [[Systems Engineering and Management]].
 
  
 
==References==  
 
==References==  
 
 
===Works Cited===
 
===Works Cited===
 
 
None.
 
None.
 
 
===Primary References===
 
===Primary References===
 
 
None.
 
None.
 
 
===Additional References===
 
===Additional References===
 +
None.
  
None.
 
 
----
 
----
<center>[[Capability Engineering|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Enabling Businesses and Enterprises|Next Article >]]</center>
+
<center>[[Lean in Healthcare|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Enabling Businesses and Enterprises|Next Article >]]</center>
  
 
[[Category: Part 5]][[Category:Part]]
 
[[Category: Part 5]][[Category:Part]]
{{DISQUS}}
+
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>

Latest revision as of 21:54, 2 May 2024


Lead Authors: Art Pyster, Hillary Sillitto, Alice Squires, Contributing Authors: Dick Fairley, Bud Lawson, Dave Olwell, Deva Henry, Rick Adcock


Part 5 of the Guide to the SE Body of Knowledge (SEBoK) is a guide to knowledge about how an enterpriseenterprise prepares and positions itself to effectively perform the systems engineeringsystems engineering (SE) activities described elsewhere in the SEBoK.

SE activities — how to develop requirementsrequirements, select an appropriate life cyclelife cycle model, and architectarchitect a system of systemssystem of systems, and so on — are covered elsewhere, especially in Part 3, Systems Engineering and Management. An organization that desires to do these things effectively must work through questions like whether to allow a project manager to select the systems engineers he or she employs, and, if so, what competenciescompetencies the project manager might seek in those systems engineers. These are the kinds of questions that Part 5 explores.

The discussion defines three levels of organization: enterpriseenterprise or organization, teamteam, and individual. To adapt an example to a more complex organizational structure, simply decompose enterprises into sub-enterprises and teams into sub-teams, as needed. For more about the different types of enterprises, see Types of Systems in Part 2.

Figure 1 SEBoK Part 5 in context (SEBoK Original). For more detail see Structure of the SEBoK

Knowledge Areas in Part 5

Each part of the SEBoK is composed of knowledge areas (KA). Each KA groups topics around a theme related to the overall subject of the part.

The KAs in Part 5 explore how to the performance of systems engineering from three different lenses:

Common Practices

There are as many different ways to enable SE performance as there are organizations, and every organization's approach is detailed and unique. Nevertheless, common practices, methods, and considerations do exist. Part 5 uses them as a framework to structure the relevant knowledge.

SE activities that support business needs and deliver value are enabled by many factors, including:

Enterprises and Businesses

The fact that Part 5 uses two terms, “Enterprise” and “Business,” to name a single level of organization, indicates that the two are closely related. In many contexts it is not necessary to make any distinction between them: an enterpriseenterprise may be a traditional business, and a businessbusiness can be seen as a special type of enterprise. For the sake of brevity, the more general term "organization" may be used to mean “business or enterprise” throughout Part 5.

Traditional businesses usually have a legal structure and a relatively centralized control structure. Such a business may be a corporation, or a unit of a company or government agency, that creates a product line or offers services.

On the other hand, an enterprise can be structured in a way that excludes description as a business. This happens when an enterprise crosses traditional business boundaries, lacks a centralized legal authority, and has relatively loose governance. One example is the healthcare "system" in the US which encompasses hospitals, insurance companies, medical equipment manufacturers, pharmaceutical companies, and government regulators. Another is the set of companies that form the supply chain for a manufacturer, such as the thousands of companies whose parts and services Apple uses to create, distribute, and support the iPhone.

Significant actions that enable SE are often conducted by traditional businesses rather than by less tightly structured enterprises. Even so, organizational context affects how the business approaches SE and therefore how it enables SE performance. A business that sells to the general commercial marketplace typically has far fewer constraints on its SE practices than one which performs contract work for a government agency. A business that creates systems with very demanding characteristics, such as aircraft, typically has a much more rigorous and planned approach to SE than one which creates less demanding systems, such as a smartphone app.

Traditional businesses are intended to be permanent, and typically offer a portfolioportfolio of products and services, introduce new ones, retire old ones, and otherwise seek to grow the value of the business. Sometimes a single product or service has such value and longevity that it spawns a business or enterprise just for its creation, maintenance, and support. The Eurofighter Typhoon aircraft, for example, was developed by a consortium of three corporations that formed a holding company specifically to provide support and upgrade services throughout the in-service life of the aircraft.

For more on the distinction between businesses and enterprises and the value of systems engineering of enterprises to them, see Enterprise Systems Engineering in Part 4. Systems of Systems (SoS), also in Part 4, contrasts the tighter control over SE that is usual for businesses with the looser control that is usual for enterprises lacking a traditional business structure. Groupings of Systems in Part 2 discusses the Directed SoS to which the traditional business may be equivalent.

Teams

Teams operate within the context of the businesses in which they reside. This context determines how the team is enabled to perform SE.

For example, a business may grant a team wide autonomy on key technical decisions, which are made either by team systems engineers or in consultation with team systems engineers. On the other hand, the same business could instead create a generic set of SE processes that all teams are to tailor and use, constraining the team to adhere to established business policies, practices, and culture. The business could even require that the team gain approval for its tailored SE process from a higher-level technical authority.

Teams are usually formed for a limited duration to accomplish a specific purpose, such as creating a new system or upgrading an existing service or product. Once the purpose has been fulfilled, the team responsible for that effort is usually disbanded and the individuals associated with the effort are assigned to new tasks. Exceptions do happen, however. For example, a team of systems engineers tasked with assisting troubled programs throughout a corporation could persist indefinitely.

References

Works Cited

None.

Primary References

None.

Additional References

None.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024