关于启用系统工程的第5部分探讨了如何在组织的三个级别上启用系统工程(SE):业务或企业(以后通常只称为“业务”——请参阅启用系统工程以获得更多信息)、团队和个人。

启用业务和企业知识区域描述在组织的最高级别启用SE所需的知识。第3部分(系统工程与管理)描述了使用第5部分中描述的技术启用SE之后如何执行SE。此外，一个企业本身就是一个系统，并且可以从这种方式中获益。(请参阅第4部分中的企业系统工程。)

主题

SEBoK的每个部分被划分为知识领域(KAs)，这是具有相关主题的信息分组。而Kas又被划分为不同的主题。这个KA包含以下主题:

• 系统工程组织战略
• 确定业务和企业中所需的系统工程能力
• 组织业务和企业实施系统工程
• 评估业务和企业的系统工程绩效
• 在业务和企业中开发系统工程能力
• 文化

主题之间的关系

• 系统工程组织战略描述了SE如何向业务交付价值，谁在业务中做出关于SE的决策，如何做出这些决策，如何分配资源，以及如何监控这些决策的可靠性和性能。
• 确定业务和企业中所需的系统工程能力描述了业务如何确定需要哪些特定的SE能力;例如，创建尖端产品的业务可能需要非常强大的架构功能，包括建模工具。拥有全球开发团队的企业可能需要非常健壮的协作工具集。
• 组织业务和企业执行系统工程描述了各种组织模型;例如，哪些SE功能应该集中，哪些应该分布，每个工程师应该知道多少SE。
• 评估业务和企业的系统工程性能描述了企业如何理解它在使用系统工程和管理中描述的技术实际执行的SE方面做得有多好。
• 在业务和企业中开发系统工程能力描述交付期望的SE能力的SE人才是如何成长和获得的
• 最后，文化描述了企业文化如何影响SE;例如，规避风险的企业可能会使用计划驱动的SE过程;一个创业型、快节奏的企业可能会使用敏捷的SE流程(参见生命周期模型)。

在某种程度上，这些主题具有“计划-行动-检查-行动”周期的特征，其中“行动”部分使用第3部分“系统工程与管理”(Deming第3部分)中描述的技术执行SE。例如，如果评估业务的SE性能显示出不足，那么可能需要开发额外的SE能力，可能需要调整组织，可能需要改进过程，等等，所有这些都在现有的文化规范中工作。如果这些规范阻止企业成功地执行SE，那么改变文化的转型努力也可能是必要的。

系统工程组织战略

几乎每个 创造 产品或服务的重要 企业或 企业都从执行各种系统工程 (SE) 活动中受益，以增加这些 产品和服务为其所有者、客户、员工、监管机构和其他利益相关者提供的价值。 （请参阅 利益相关者的需求和要求。）

企业是一种特定类型的企业，通常是具有管理结构的法人实体，允许对其组件进行相对严格的控制，包括它如何实现 SE。 本文中经常使用术语业务来代替企业，因为启用 SE 的特定操作通常由企业完成。 这将在父文章启用系统工程 中进一步讨论。 组织开展社企活动的策略对其有效性很重要。 例如，每个企业都有一个由其一些利益相关者确定的目的、背景和范围，并随着时间的推移进行修改，以增加企业为他们提供的价值。

有些企业是营利性企业。 其他是为公共利益服务的非营利性企业。 还有一些是非传统企业，但结构更松散，没有法律结构，例如国家医疗保健系统。 一些企业位于一个单一的地点，而另一些则是遥远的全球“帝国”。 有些人在医疗设备等高度监管的行业工作，而另一些人则在几乎没有政府监督的情况下工作，可以遵循更广泛的商业惯例。 所有这些变化形成了执行 SE 的策略。

主要考虑因素

SE 组织战略由业务目标以及可用于实现这些目标的资源和约束驱动。 SE 策略尤其受以下几个因素的影响：

• 企业宗旨
• 企业为其利益相关者提供的价值； 例如，利润、公共安全、娱乐或便利
• SE活动支持的系统的特征； 例如，尺寸、复杂性、主要设计因素、主要组件、所需产品、关键特性或生命周期领域
• 执行 SE 活动的生命周期阶段； 例如，产品或服务的开发、部署、运营或维护
• 业务规模、感兴趣的系统和服务； 例如，它是一家单一站点公司还是一家全球企业？ 企业是否正在为内部使用创建相对适中的产品，例如用于跟踪员工培训的新 Web 应用程序，或者是完全关注工程、制造、服务和分销的新型混合动力汽车？
• 执行 SE 活动的企业文化； 例如，企业是否规避风险？ 人们通常在孤立的组织中协作或工作吗？
• 业务结构以及当前结构与创建新产品和服务所需的匹配程度； 例如，业务结构是否与其主要产品和服务的架构一致？
• 企业在其运营、产品和市场中进行的变化或转型程度

Rouse (2006) 对企业战略进行了透彻的审视，特别是因为它涉及在生命周期的各个阶段为企业提供价值，从研发到运营。 Rouse 提供了许多技术来确定和提高使用 SE 方法为企业提供的价值，这在企业正在进行重大转型而不是“照常营业”时尤其有用； 例如，企业可能正在尝试：

• 更好地开展当前业务（降低成本或提高当前产品和服务的质量）；
• 应对市场中断、竞争威胁或不断变化的客户期望和经营方式；
• 在其价值链中重新定位（从零件供应商转变为组件供应商）； 或者
• 推出新一代产品或进入新市场。

Eisner (2008) 全面审视了不同的 SE 组织方法。

系统工程战略要素

基于主要考虑，SE 策略通常解决以下问题：

• SE 活动如何为业务提供价值
• SE 活动如何在各种业务实体之间分配
• 为了执行这些 SE 活动，业务的各个部分需要具备哪些能力
• 部分业务如何获得和提高能力
• 谁在业务的每个部分执行 SE 活动
• 执行 SE 活动的人如何与业务中的其他人互动
• SE 活动如何使企业解决转型问题

根据企业对 SE 的方法，可能没有一个统一的、连贯的 SE 战略在整个企业中通用。 不同的业务部门可能有自己的 SE 战略，或者战略的制定可能委托给各个项目。 SE 策略甚至可能没有明确记录，或者可能只在整个企业的多个文档中找到。 一些企业发布了描述其组织战略的指南和政策。 这些通常是专有的，除非企业是政府或准政府机构。 两个公开文件是 NASA (2007) 和 MITRE (2012)。 后者有许多关于不同主题的短文，包括一篇关于利益相关者评估和管理的文章和另一篇关于制定组织转型战略的文章。

产品和服务开发模型

大多数企业采用三种基本的产品和服务开发模型：

1. 市场驱动的商业
2. 生产线
3. 合同

三种业务模型之间的最大区别在于需求风险所在的位置以及用户需求和使用如何被反馈到设计和交付过程中。 SE 对业务的支持因情况而异。

市场驱动的商业 产品和服务出售给许多客户，并且通常由组织自行开发开发。 这些需求来自基于对市场、相关法规和立法的了解以及组织内部的好主意的营销（Pugh 1991，Smith 和 Reinertsen 1997）。 Sillitto (1999) 认为，市场驱动的商业产品开发是一种系统工程形式，具有适用于需求获取和验证的技术。

产品线 产品和服务是相同产品和服务的变体，通常为每个客户定制。 创建底层产品平台需要额外的投资。 以支持具有成本效益的定制的方式构建这样一个平台，在技术和组织上通常比市场驱动的商业产品和服务更复杂。

系统工程师通常在建立平台架构、了解平台选择对制造和服务的影响等方面发挥核心作用。在产品线产品和服务中有许多良好实践的例子； 例如，来自丰田、通用汽车和现代等几乎所有主要制造商的汽车模型； 波音和空客飞机，例如 B-737 系列和空客 320 系列； 诺基亚和摩托罗拉手机。 软件工程研究所对软件系统的产品线进行了广泛的研究，并开发了一个构建和分析它们的框架（Northrop et.al. 2007）。 有关产品线原理和方法的参考，请参阅 Simpson (et al. 2006)。

合同 产品和服务通常需要定制的系统/服务解决方案，这些解决方案通常由提供解决方案的单个客户指定。 供应商以提出的解决方案作出回应。 这种发展方式在国防、太空、交通、能源和民用基础设施中很常见。 购买许多系统的客户通常有一个特定的采购组织，对采购过程有精确的规则和控制，以及强制性的技术和过程标准。 在此模型中，供应商在 SE 流程、工具和实践方面的灵活性通常远低于其他两个。

任何单个企业或企业都可能应用这三种模型的某种组合，对其中的一个或多个赋予不同的重要性。

使用和提供 SE 的组织

使用 SE 或提供 SE 服务的组织有五种基本类型：

1. 拥有多个项目团队的企业
2. 跨越多个业务的项目
3. 上述任何一项中的 SE 团队
4. 拥有单一项目团队的企业
5. 向多个客户提供特定 SE 能力或服务（工具、培训、生命周期流程）的 SE 服务供应商，无论是作为外部顾问还是作为内部 SE 功能

业务类型决定了整个组织中 SE 的范围和多样性。 这在图 1 中以抽象形式显示，它说明了扩展企业的基本形式。 这也显示了组织结构如何趋向于匹配系统结构。

图 1. 组织耦合图。 （SEBoK 原创（改编自 Lawson 2010））

问题负责人是涉及 问题情况 并受其影响的人员、社区或 组织 。 他们可能正在寻求保卫国家，改善社区的交通联系，或应对环境挑战。 受访者系统 可能是新的 战斗机、新的或改进的交通基础设施，或新的低排放发电系统（分别）。 负责响应系统的组织将是空军、运输运营商或监管机构，或电力供应公司。 这些组织的主要作用是运营感兴趣的系统，为问题所有者提供价值。 可以合理地期望他们管理整个系统生命周期。

图 2 扩展了同样的概念。

图 2. 系统企业和组织。 （SEBoK 原创）

企业的目标、措施和一致性

业务内目标和措施的一致性强烈影响 SE 的有效性和 SE 为业务带来的利益，需要仔细理解：

• Blockley 和 Godfrey (2000) 描述了在通常受到敌对行为困扰的行业中成功地用于按时和在预算内交付主要基础设施合同的技术。

• 精益思维提供了一种使目标与客户价值保持一致的强大技术——前提是正确选择企业边界并考虑整个价值流（Womack and Jones 2003; Oppenheim et al. 2010）。

• Fasser 和 Brettner (2002, 18-19) 将组织视为一个系统，并提倡组织设计的三个原则：（1）为最终客户增加价值，（2）严格的纪律，以及（3）简单。

• EIA 632 (ANSI/EIA 2003) 提倡将系统每个元素的生命周期成功所需的所有方面作为一个集成的“构建块”进行管理。 同样，Blockley (2010) 建议，将 “系统作为过程” 的整体观点视为组织和系统设计的更连贯和更成功的方法，将每个元素视为更大的感兴趣系统的一部分，并作为一个“整个系统”（“holon”）本身。

• 艾略特等人。 (2007) 提倡使系统发挥作用的六项指导原则：(1) 辩论、定义、修改和追求目标，(2) 全面思考，(3) 遵循系统程序，(4) 具有创造性，(5) 采取(6) 管理项目和关系。

• 对于刚接触 SE 的组织，INCOSE 英国分会发布了一系列关于该主题的单页指南，包括 Farncombe 和 Woodcock (2009a; 2009b)。

治理

SE 治理是企业通过其制定决策权的过程和实践，使 SE 能够提供尽可能多的业务价值。 这些权利可以编入政策，通过业务结构实施，通过工具强制执行，并通过合规性和有效性的措施来理解。

大型企业中的 SE 治理通常是明确的并在政策中编纂成文。 在小型企业中，它通常是默认的，简单地理解为企业的运作方式。 企业定义其 SE 战略时的关键实施步骤之一是建立其 SE 治理模型，该模型应针对企业运营和交付价值的特定环境进行定制。 当然，在实践中，这通常是渐进的、不平衡的，并且会根据当前的业务状况和担任关键管理职位的人员而波动很大。

发展组织治理一词 最初是在参考信息技术 (IT) 如何在业务和企业中受到监督时得到普及的（Weill 和 Ross 2006；Cantor 和 Sanders 2007）。 在 1990 年代和过去十年中，人们认识到 IT 是大多数公司和政府机构绩效和价值的基本驱动因素，这导致首席信息官 (CIO) 转变为关键的高级经理。

IT 的明确治理对于使企业能够应对新技术机会、新兴市场、新威胁以及新产品和服务的快速交付变得非常重要。 “治理”一词现在被广泛用于描述 SE 如何融入企业。 对于存在高度不确定性的复杂项目（Cantor 2006）或系统项目的系统（其中重大决策的责任可能分布在企业内的多个组织中，其中没有一个人参与其中），治理变得尤其具有挑战性。在控制中”（参见 系统的系统（SoS） ）。 Morgan 和 Liker (2006) 描述了丰田的治理模式，它是世界上最大的公司之一。

SE 治理建立了管理设计权限、资金和批准、项目启动和终止等问题的框架和责任，以及系统将在其中开发和运行的法律和监管框架。 治理包括企业政策、流程、方法和工具为何以及如何适应环境的基本原理和规则。 SE 治理还可以指定产品和流程措施、文档标准以及技术审查和审计。

团队组织开展 SE 活动的方式要么符合上一级制定的政策，要么包含在该团队自己的治理政策、流程和实践中。 这些政策涵盖了组织环境和目标、利益层面的治理、流程、实践和产品的责任，以及赋予较低组织级别的自由和治理和报告义务。 以责任、问责、咨询、通知 (RACI) 矩阵 (PMI 2013) 或类似的形式记录人员的分配及其角色和责任是一种很好的做法。 大型组织的责任很容易分散。 萨默维尔等。 人。 (2009, 515-529) 讨论信息与责任之间的关系，

小型组织倾向于拥有相对非正式的治理文档和流程，而大型组织倾向于在其治理方法中更加结构化和严谨。 负责开发或获取大型复杂系统的政府组织，例如美国国防部或美国联邦航空管理局，通常会制定政策来描述其 SE 活动和 SE 组织的治理。 有关国防部 SE 政策，请参阅 DoD (2012)。

政府合同通常会带来额外的监管和监督，推动团队在其 SE 治理中更加严格、文件化和具体实践。 影响公共安全或安保的系统或运营服务的开发受到类似于政府合同中的限制。 想想医疗设备的创建或应急系统的运行、空中交通管理或核工业。 （例如见杰克逊（2010））。

治理模式差异很大。 例如，开源社区最成功的 Linux 拥有与传统企业截然不同的治理模式。 Smith (2009) 对如何决定进入 Linux 内核的内容做出了令人信服的解释。 所有决策权都是完全透明的，发布在 Linux 网站上，并且随着它们的发展已被证明非常有效。 Eric Raymond (2000)的经典论文 The Cathedral and The Bazaar 对 Linux 治理的演变以及 Linus Torvalds 如何应对不断变化的环境和环境以保持 Linux 在市场上的成功与治理模型非常新颖提供了深刻的见解。是时候了。

项目管理文献也有助于理解 SE 治理。 例如，Shenhar 和 Dvir (2007) 为项目管理提供了“钻石模型”，该模型确定了指导开发项目管理方式的四个维度：新颖性、技术、复杂性和速度。 将此模型应用于 SE 治理将影响开发项目的可用生命周期模型以及这些模型的应用方式。

有很多项目的好坏很大程度上取决于 收购方和 供应商 组织实施的治理。 SEBoK 的第 7 部分有几个例子，特别是新加坡水资源管理（进展顺利）和 FAA 高级自动化系统（AAS）（进展不太顺利）。

确定企业所需的系统工程能力

使业务或企业能够很好地执行系统工程(SE)，需要决定业务或企业为了成功需要哪些特定的SE功能。(在本文的其余部分中，业务或企业通常缩写为“业务”，因为业务是一种特定类型的企业，它具有足够强的中央权限和动机来采取步骤启用SE)。SE能力应该支持系统工程组织战略，并反映业务的性质、产品和服务、各种涉众、业务领导重点等。

本主题是第5部分中启用业务和企业知识领域(KA)的一部分，它总结了用于决定业务需要哪些SE功能的因素;例如，SE和业务中其他职能领域之间的互动，以及对团队和业务层面的社会动力和领导力的考虑。所需要的能力可以由企业集中决定和开发，也可以由团队和个人来决定和开发，或者通过两者的某种结合。团队SE能力的确定在团队能力一文中进行了讨论，而个人SE能力则在角色和能力一文中进行了讨论。

本主题与企业系统工程的关系

企业系统工程和 能力工程技术可用于建立所需的 SE 能力。 在高抽象层次上，以下是可用于确定业务中所需的 SE 功能的基本步骤：

1. 了解上下文；
2. 确定所需的 SE 角色；
3. 确定每个 SE 角色所需的能力和能力；
4. 评估所需 SE 组织、团队和个人的能力和可用性；
5. 根据实际能力和可用性调整所需的 SE 角色；
6. 组织 SE 功能以促进沟通、协调和绩效。

有关更多信息，请参阅文章组织业务和企业执行系统工程 。 下面提供了有关上下文和所需 SE 角色的更多信息。

上下文驱动因素

以下讨论说明了影响企业所需 SE 能力定义的一些背景因素。

SE活动在价值链中的执行位置

企业采用的 SE 方法应取决于组织所扮演的角色。 Ring (2002) 定义了一个价值周期，企业在该周期中所处的位置是 SE 能力需求的关键影响因素。

• 问题负责人： 专注于识别和界定系统问题（定义 感兴趣的系统 (SoI)），并使用企业系统工程和 能力工程 方法 了解适当响应系统的性质。
• 系统操作员： 专注于建立交付所需服务的所有必要能力 组件，以及在新系统资产可用时将其集成到系统操作中（请参阅服务系统工程 ）。 能力组成部分的定义因组织而异——例如，
  • 美国国防部将能力的组成部分定义为 DOTMLPF：条令、组织、训练、物资、后勤、人员和设施。
  • 英国国防部将能力的组成部分定义为 TEPDOIL； 即培训、设备、人员、信息、条令、组织、基础设施和后勤。
  • 其他领域和组织使用类似的等效分解来定义能力的组成部分，这些分解可以是显式的，也可以是隐式的。
• 总承包商或主要商业开发商： 专注于了解客户需求和交易替代解决方案方法，然后建立系统团队和供应链来开发、交付、支持并在某些情况下运行系统解决方案。 这可能需要企业 SE（请参阅企业系统工程）以及“传统”产品 SE（请参阅 产品系统工程）。
• 子系统/组件开发人员： 专注于了解感兴趣的子系统或组件的关键客户和系统集成商问题，定义组件或子系统边界，并集成关键技术。 这可以利用可重复使用的元素，并且可以以相同或修改的形式出售给多个客户。
• 专业服务提供商： 专注于通常按时间和材料或工作包出售给其他企业的特定流程能力和能力。

企业在生命周期中的运营位置

企业所需的 SE 功能将取决于其运行所在的系统生命周期阶段（参见第 3 部分中的生命周期模型 ）。

• 概念定义阶段： 需要 SE 能够识别“问题情况”，定义解决方案系统的背景和潜在操作概念，从广义上评估一系列可能解决方案的可行性，并细化定义以允许开发解决方案的系统要求（参见第 3 部分中的 概念定义）。
• 系统定义阶段： 要求 SE 能够影响概念研究（确保可行并被开发团队理解），建立在概念研究结束时保留的交易空间，执行系统定义 活动，包括架构设计，并创建一个系统元素的详细定义。
• 系统实现阶段： 需要 SE 能够为系统资产配置制造和物流系统，并制造系统资产（参见第 3 部分中的系统实现）。
• 系统部署和使用： 需要 SE 能力在过渡到运营期间保持业务连续性、使系统投入使用、支持系统、监控系统性能并响应新出现的需求（请参阅系统部署和使用 ）。 艾略特等人。 (2008) 描述了在“服务”阶段应该放在 SE 中的不同重点。 这一阶段特别要求企业能够以适当的运营节奏执行 SE。
• 报废阶段： 需要 SE 能力以确保系统安全报废，并使它们处于准备好重新激活（“封存”）、安全处置系统资产的状态。

对最终用户和社会的责任性质

根据业务模式和合同环境，企业可能会发现其对最终用户的责任是：

• 明确 的，或由明确的要求和规定性立法阐明； 或者

• 隐含的 ； 即，确保“符合目的”的法律或道德义务，可能由商业框架、国家或国际标准和特定产品责任立法强制执行。

通常，商业模式是合同驱动的企业专注于满足明确的要求，而市场驱动的企业必须更加意识到隐含的责任。

对客户的责任性质

企业可以与其客户签订合同以提供以下任何一项：

• 结果 ：系统预期提供的预期收益，需要企业系统工程 ；
• 输出：根据商定的 验收标准 交付或操作系统或系统的一部分 ； 需要 产品系统工程；
• 一项活动 ：执行一组指定的任务，需要服务系统工程；
• a resource ：提供指定的资源； 需要专注于个人能力 。

系统规模

业务或企业可能需要非常不同的 SE 方法，具体取决于业务运营的系统规模。 以下类别基于 Hitchins 的五层系统模型（Hitchins 2005）：

• 级别 1：子系统和技术工件 ——专注于 产品系统工程 和技术集成。
• 第 2 级：项目系统 ——专注于 跨学科和人类集成的 产品系统工程。
• 3 级：业务系统 ——专注于企业系统工程 、服务系统工程 以实施它们，以及服务管理（Chang 2010）和持续改进（SEI 2010b）； 另请参阅质量管理 ）以了解业务的日常运行。
• 第 4 级：行业系统 ——如果有意识地将整个行业视为一个系统，则重点将放在企业系统工程 以及整个行业的长期经济和环境可持续性上。
• 5 级：社会系统 —— 企业系统工程用于分析和尝试优化社会系统（参见第 7 部分中的 新加坡水资源管理）。

Sillitto (2011) 提议通过添加两个附加层“生态系统”和“地球系统”来扩展该模型以涵盖可持续性问题。

系统集成任务和 Stupples 级别的复杂性

创建有效的系统——21 世纪的工程系统原理确定了三种“类型”的 SE，最初由 Stupples（2006 年）提出，它们与所涉及的跨学科整合水平有关（Elliot 等人，2007 年）。

1. 在一个学科（例如，软件、硬件、光学 或机械）内，SE 的重点是从体系结构和实施的角度来管理单一工程学科内的复杂性和规模。
2. 在多个学科（例如，软件、硬件、光学 和机械）中，SE 的重点是全面整合多种技术和技能，以实现平衡的系统解决方案。
3. 在社会技术系统集成中，SE 的重点是让系统中的人和非人类部分协同工作。

Sillitto (2011) 建议通过增加一个额外的级别“环境整合”来适当扩展该模型以涵盖可持续性问题。 他描述了这个级别，并展示了 Stupples 级别与用于对系统和专业工程技能进行分类的其他维度之间的关系。

系统和认证要求的重要性

企业采用的 SE 方法的严格程度将取决于各类需求的关键程度。 （参见系统工程和专业工程 。）

• 安全和安保要求通常需要特定的可审计流程和员工能力证明。
• 道德和环境要求可能需要对整个供应链和价值链进行审计。
• 性能要求的极其苛刻的组合将需要更多的设计迭代和对组件特性的更关键的控制； 例如，参见质量管理 和 高科技企业质量管理（Fasser 和 Brettner 2010）。

合同或协议的性质

企业与其客户和最终用户之间合同关系的性质将影响 SE 的风格。

• 固定价格、成本加成或其他合同模式会影响对绩效和成本控制的关注，以及如何激励企业处理风险和机会。
• 在强制工作共享安排中，产品系统的架构可能会受到可行业务系统架构的影响或限制； 在跨国项目和备受瞩目的政府采购中经常出现这种情况（Maier and Rechtin 2009, 361-373）。
• 在自筹资金的方法中，优先事项将是旨在发现消费者和企业客户潜在需求的需求获取方法，以及旨在通过有竞争力的产品实现快速上市时间的开发方法，或提供足够的有竞争力的产品在客户选择过程中的最关键时间可用的成熟度。
• 在单阶段或整个生命周期的方法中，企业可能能够优化开发、实施和服务预算之间的权衡，以及能力的不同组成部分之间的权衡。

问题域的性质和可预测性

定义明确且变化缓慢的技术、产品和服务允许使用基于瀑布模型的传统 SE 生命周期模型，因为预计需求风险和变化较低（请参阅生命周期模型 ）。

定义不明确且快速变化的问题领域，以及运营商面临不可预测和不断变化的威胁，需要更灵活的解决方案和敏捷的流程。 SE 应专注于模块化架构，允许快速重新配置系统和系统系统，以及在子系统级别快速部署新技术以满足新的需求和威胁。

解决方案领域的基本风险和设计驱动因素

当解决方案领域稳定、技术演进速度慢且系统使用成熟技术时，重点是在已知参考架构中对已知且通常经过充分验证的构建块进行优化打包和配置，以及低风险的增量改进随着时间的推移。

当技术快速发展时，面临着将新技术快速推向市场和/或投入运营使用的压力，SE 方法必须关注技术成熟度、技术证明和集成准备情况，以及处理从从实验室到操作系统的概念验证。

通常需要在交货时间预期和完整性/认证水平之间进行权衡。 在新系统的开发中，较短的交付周期很少与高水平的系统完整性和严格的认证相适应。

竞争形势和业务目标

SE 部署的业务驱动因素可能是以下一项或多项：

• 更好地执行现有业务；
• 从竞争冲击或客户期望的转变中恢复过来；
• 开发新一代产品或服务；
• 进入一个新市场；
• 在价值链中重新定位企业或企业。

在第一种情况下，SE 可以逐步部署在可以实现早期有形收益的部分业务流程中。 这可能是 SE 业务范围战略计划的早期步骤。 （有关 设置 SE 策略和在业务和企业中开发系统工程能力以提高 SE 能力 的更多信息，请参阅 系统工程组织战略。）

在其他情况下，业务正在经历颠覆性变革，早期的优先事项可能是使用系统思维（请参阅系统思维 ）和企业 SE 方法在重大变革计划的背景下确定转型范围。

系统或服务类型

存在三种不同风格的产品或服务类型（请参阅系统工程组织策略）：

1. 在产品或产品化服务中，重点将放在预测市场在开发期间可能发生的变化，引出、预测和平衡各种潜在客户的需求，并根据成本和可靠性优化功能和产品吸引力。
2. 在定制解决方案（产品或服务）中，重点将放在可行和低风险（通常）的方法上，使用已知或预期在所需开发时间范围内可用的系统元素和技术来满足预算内的规定要求。
3. 基于标准产品和/或服务元素的定制解决方案需要更复杂的 SE 流程，该流程能够使用“产品线方法”将标准模块与计划调整相结合，以比可能更快、更便宜的方式满足客户的特定需求使用单一合同解决方案。 业务需要独立管理标准模块的生命周期和配置，但要与每个定制解决方案的生命周期和配置保持一致。

所需的系统工程角色

在了解了业务背景之后，下一步是确定业务中角色所需的 SE 能力。 用于采购、开发和服务的 SEI 能力成熟度模型（SEI 2007；SEI 2010a；SEI 2010b）为选择与不同类型业务相关的 SE 能力提供了一个框架。 现有的 SE 能力模型可用于帮助确定所需的能力。 一个例子是 INCOSE SE 能力框架（INCOSE 2010）。 （有关能力模型的更多信息，请参阅 角色和能力 。）

SE 重点的传播范围很广，从 SE 专注于专家、接口或胶水角色（Sheard 1996）到“SE 是具有特殊重点领域的优秀工程……包括学科之间的接口”（Blanchard和Fabrycky 2005），所以它被所有人共享。 在任何共享活动和技能的组织中，总是存在孤岛或重复的危险。

作为角色定义的一部分，企业必须定义从事 SE 的个人适合职业发展的位置（SE 之前的角色，之后的角色？）。发展个体 描述了个体如何提高 SE； 该组织必须确定实施该发展的手段。 企业需要从一系列发展战略中进行定制； 例如，参见 Davidz 和 Martin (2011)。

如下图 1 所示，如果执行 SE 角色所需的能力与个人的实际能力之间存在系统性不匹配，则需要对劳动力发展采取管理措施。 组织文化可能对团队绩效和企业增加的整体价值产生积极或消极的影响（参见文化 ）。

图 1. 文化、能力、团队绩效和个人能力。 （SEBoK 原创）

所需的 SE 流程和方法

如何实施 SE 能力的决策必须嵌入业务流程及其可用性方法和工具集。 将 SE 原则、流程和方法嵌入组织的质量管理体系意味着高级管理层和质量体系将帮助将 SE 嵌入组织的业务流程并确保其得到应用（INCOSE 2012；ISO/IEC 2008；参见质量管理） .

在定义流程和工具时，在对 SE 流程的系统化和标准化方法的需求（例如 INCOSE（2012）中所见的方法）与系统性思维固有的灵活性之间取得平衡至关重要。 系统思维有助于组织了解问题情况、消除组织障碍并充分利用组织的技术能力（参见 Beasley (2011)）。

需要明确的 SE 方法和实施 SE 的危险

清楚组织如何执行 SE 很重要。 通常，实施 SE 可能是组织改进的一部分，因此 Kotter 关于创建愿景、传达愿景和授权他人按照愿景行动的原则非常相关（Kotter 1995）。 组织选择执行 SE 的方式应该是组织愿景的一部分，并且必须被所有人理解和接受。

SE 部署中的许多主要障碍是文化方面的（请参阅 文化）。

SE 的精益促成因素之一是“追求完美”（Oppenheim et al. 2010）。 在其他地方详细讨论了业务或企业级别的改进方法，但起点必须是确定组织想要什么 SE 能力。 需要认识到，所需的能力会随着时间而变化（学习、提高或失去能力）。 因此，平衡 SE 与它所涉及的其他一切是一个不断变化的过程。

组织业务和企业实施系统工程

业务和企业 SE 能力的组成部分

组织问题——文化、知识、信息和基础设施

管理 SE 的方式在系统工程组织战略中进行了描述，它影响并响应了 SE 文化和方法。

知识和信息

知识和信息是企业的关键资产，其管理至关重要。 Fasser 和 Brettner (2002) 广泛讨论了知识管理。 他们断言 “我们可能认为知识转移只是一个信息技术问题，但实际上它也是一个心理、文化和管理问题——简而言之是一个人的问题”和“只有行动中的信息才能创造知识”。

组织需要管理 SE 专业知识、SE 与其他组织流程和活动的集成以及其业务领域的知识。 INCOSE 智能企业工作组在 SE 环境中的知识管理工作导致发表了 “系统工程教育社区的运营概念”（Ring 等人，2004 年）。

信息必须在复杂的组织中共享和保护。 共享是有效协作的关键，并且受到保护知识产权以及商业和国家敏感材料的需要的限制。 不同的文化和个人风格以不同的方式和不同的顺序使用信息。 （抽象层次、大图优先或细节、原则优先或实际示例等）Sillitto (2011b) 描述了大型跨国组织面临的知识管理挑战。

项目需要管理项目信息并建立对正式合同信息的配置控制，以及定义正在开发、供应或运营的产品/服务的信息。 系统工程师的一个关键作用是“为项目提供语言”（Ring 等人，2004 年）。 良好的数据管理和工具支持将允许人们记录一次，多次使用，并确保信息随着时间的推移和不同团队之间的一致性。

系统信息需要在系统的整个生命周期中进行维护，并提供给相关的利益相关者——包括那些设计必须与感兴趣的系统接口的新系统的人——以允许系统管理、维护、重新配置、升级和处置以及取证在事故和未遂事故之后。 艾略特等人。 (2008) 认为信息管理是服务系统 SE 中的主要问题，并且在开始实施变更之前建立当前状态和遗留约束的成本和难度往往被低估。

支持系统生命周期的“Infostructure”（信息基础设施）将包括以下内容：

• 信息资产，例如流程库、文档模板、首选部件列表、组件重用库、有关遗留系统的指定和测试信息、以前类似项目的组织绩效的资本化指标，所有这些都具有适当的配置控制
• 建模和仿真工具、数据集和运行时环境
• 共享的工作环境——用于同一地点的团队的工作空间、供人们相互交流以发展想法和探索概念的区域、适合分析任务的工作区域、会议室、访问控制提供等。
• IT 设施 - 计算机文件结构、软件许可证、IT 设备、支持协作工作的计算机和墙壁显示器、打印机，所有这些都具有适当的安全规定和备份设施、有效使用的程序以及可接受的性能和可用性
• 保护自己、客户、供应商和第三方知识产权的安全规定，并执行必要的保护性工作实践，同时允许需要了解的人有效访问信息

SE是一种知识活动。 系统工程师需要适当的设施来访问、共享和获取知识，以及与所有利益相关者进行有效交互。 Warfield (2006) 描述了协作工作空间、环境和过程，以形成对问题情况的共同理解。

启用基础设施

ISO/IEC 15288 (ISO 2008) 基础设施管理流程提供支持性基础设施和服务，以在整个生命周期内支持组织和项目目标。 支持系统生命周期的基础设施通常包括以下内容：

• 集成和测试环境——工作台和实验室设施、开发测试设施以及测试环境的不同集成、校准和配置管理级别的验收测试
• 试验和验证环境——进入试验场、试验轨道、校准目标、试验支持和储存——设备、港口、机场和道路设施、燃料安全储存、条例等。
• 培训和支持基础设施——培训模拟器、嵌入式培训、用于运营支持和维护的工具和测试设备等。

人们

人们担任的角色通常由业务/企业定义（请参阅 确定业务和企业中所需的系统工程能力 ），尽管这些决策可能会下推给团队。启用团队 解释了人们如何在团队中使用；赋能个人 描述了个人 SE 能力的发展。

这些角色的实施需要进一步考虑。 Sheard (1996) 列出了十二个系统工程角色。 Sheard (2000) 对发现阶段（以高度不确定性为特征）、程序阶段（更具确定性和定义性）以及整体系统工程方法所涉及的角色进行了重要区分。 卡塞尔等人。 （2009 年）确定了五种类型的系统工程师，它们的特点是需要在越来越高的抽象、模糊性、范围和创新水平上工作。 Sillitto (2011a) 在更广泛的工程和商业专业环境中讨论了一些 SE 角色及其所需的特征。

系统工程存在于企业“生态系统”中。 需要考虑的两个关键方面：

• 企业/企业应该在多大程度上培养和重视系统工程师？
• 业务/企业应该从系统工程师那里获得多少价值，而不是等待系统工程师“推动”业务/企业的价值？

过程

许多 SE 组织维护一套组织标准流程，这些流程集成在他们的质量和业务管理系统中，适应他们的业务，并带有用于帮助项目将标准流程应用于其独特环境的定制指南。 组织流程管理指南由能力成熟度模型集成 (CMMI) (SEI 2010) 等框架提供，该框架有两个组织流程的流程领域： 组织流程开发 (OPD) 关注组织定义和 SE 生命周期的剪裁过程（在本文档的其他地方详细讨论）和组织过程焦点 (OPF)，它与在组织中建立过程文化有关。

为了记录、评估和改进 SE 流程，企业通常会建立一个系统工程流程组。 这些小组的成员通常会创建标准流程资产，并可能指导团队和业务部门如何采用这些标准流程并评估这些流程的工作效率。 基于各种流程改进模型，有大量关于 SE 流程改进的文献。 最流行的两个是 ISO/IEC 9000 (2000) 和 CMMI (SEI 2010)。 创建 CMMI 的软件工程研究所在 http://www.sei.cmu.edu/cmmi 上提供了许多关于 CMMI 的免费技术报告和其他文档。

评估和测量过程性能包含在 评估业务和企业的系统工程性能中。

工具和方法

SE 组织经常投资于 SE 工具和模型，开发自己的工具和/或将现成的工具集成到其特定的业务/企业流程中。 工具需要高度重视文化和培训； 发展一致的使用“风格”，以便人们能够理解彼此的工作； 正确配置和管理信息，以便人们处理通用和正确的信息。

使用方法和工具很重要，尤其是支持 系统思维 。

大型 SE 组织的常见做法是拥有一个工具支持基础架构，以确保工具支持组织标准流程并与培训完全集成，并且项目和团队可以使用这些工具来完成他们的工作并且不会被工具管理分心更有效地集中处理的问题。 较小的 SE 组织的运作方式通常较为非正式。

将它们组合在一起

下面图 1 中的概念图显示了组织、资源、责任和治理的各个方面之间的关系。

图 1. SE 中的企业、团队和个人。 （SEBoK 原创）

企业结构及其对 SE 的影响

企业以许多不同的方式管理 SE 资源。 一个关键驱动因素是他们寻求跨团队和整个企业优化资源（人员、知识和资产）使用的程度。 组织资源以支持多个项目的五种常见方式是：项目； 矩阵; 功能性的； 融合的; 以产品为中心（CM Guide 2009、Handy 1985、PMI 2013，第 2.1.3 节）。 大型企业可能会在其子企业和团队中应用这五种方式的某种组合。 Browning (2009) 提供了一种优化项目组织结构的方法。 Eisner (2008) 很好地概述了不同的组织模型。

项目组织

项目组织是一个极端，项目负责招聘、培训和解雇员工，以及管理交付所需的所有资产。 在此模型中，系统工程师向项目经理报告项目，并针对项目交付优化资源。 这种模式的优点是项目的权力和责任与项目经理高度一致。 然而，它的运作是以对如何在更大的企业中部署员工、如何跨项目进行技术选择等进行次优化为代价的。 系统工程基础(DAU 2001) 提供了国防部对良好实践项目组织的看法。

职能组织

功能性组织表现出相反的极端。 在职能组织中，项目几乎将所有工作委托给职能组，例如软件组、雷达组或通信组。 当功能技能快速发展并依赖于复杂的基础架构时，这是合适的。 这种方法通常用于制造、测试工程、软件开发、财务、采购、商业和法律职能。

矩阵组织

矩阵组织用于为系统工程师在项目分配之间提供一个“家”。 通常，SE 职能负责人负责组织中系统工程师的职业发展，这是一个影响单个项目任务的多样性和长度的因素。

综合组织

在一个整合的组织中，人们在没有特定职能效忠的情况下完成分配的工作。 执行 SE 任务的人主要被识别为另一种类型的工程师，例如土木或电气工程师。 他们了解系统工程，并根据需要在日常活动中使用它。

以产品为中心的组织

按照“产品和过程必须匹配”的 启发式 （Rechtin 1991, 132），创建组织结构的常用方法是使其匹配系统分解结构（SBS）。 根据 Browning (2009)，在 SBS 的每个元素都有一个指定的集成产品团队 (IPT) 。 每个 IPT 都由设计产品系统所需的技术学科的成员组成。 IPT 的目的是确保在设计中考虑到所有技术学科之间的交互，并避免不希望的交互。

与其他组织的接口

在企业内部的官方工程和 SE 组织之外，还有其他组织的章程不是技术性的。 然而，这些组织具有重要的 SE 作用。

• 客户界面组织： 这些组织具有营销和客户工程等头衔。 他们与当前或潜在客户有最直接的联系。 他们的职责是确定客户需求并将这些需求传达给 SE 组织，以转换为产品要求和其他系统要求。 Kossiakoff 和 Sweet (2003, 173) 讨论了了解客户需求的重要性。

• 合同组织： 这些组织与客户和供应商组织交互。 他们的职责是为开发商或供应商制定明确的合同。 这些合同传达了各方所有 SE 角色的任务和责任。 合同附有技术规格。 规定了验证和确认的责任。

• 供应商管理组织： 这些组织负责选择和管理供应商，并确保合同和技术产品都到位。 这些组织平衡成本和风险，以确保交付、验证和验证供应商产品的质量。 Blanchard 和Fabrycky (2005, 696-698) 讨论了供应商选择和协议的重要性。

评估业务和企业的系统工程绩效

在项目层面，系统工程(SE)度量关注与项目及其涉众相关的项目和系统成功的指标。在企业层面，还有其他的问题。SE治理应该确保企业内系统工程的性能为组织增加价值，与组织的目的一致，并实现组织战略的相关部分。

对于传统企业来说，这比较容易，因为这类组织通常比结构松散的企业拥有更多的控制手段。可以用来提高绩效的治理杠杆包括人(选择、培训、文化、激励)、过程、工具和基础设施，以及组织;因此，企业系统工程绩效的评估应该包括这些维度。

当试图指导团队活动时，能够聚合关于SE活动的团队表现的高质量数据肯定是有益的。然而，访问可比数据通常是困难的，尤其是在相对自主、使用不同技术和工具、在不同领域构建产品、拥有不同类型的客户等的组织中。即使在团队之间可靠地收集和聚合数据的能力有限，拥有一个有意识地决定企业将如何处理数据收集和分析的策略也是有价值的。

绩效评估措施

评估企业 SE 绩效的典型措施包括：

• SE过程的有效性
• 能够在正确的时间为新项目或新项目阶段调动正确的资源
• SE过程输出的质量
• SE过程输出的及时性
• SE为项目增加价值
• 系统为最终用户增加价值
• SE 为组织增加价值
• 组织的 SE 能力发展
• 个人 SE 能力发展
• 资源利用率，当前和预测
• 系统工程师的生产力
• 工具和方法的部署和一致使用

措施如何适应治理过程和改进周期

由于收集数据并对其进行分析通常需要付出巨大的努力，因此最好在其目的明确并且是整体战略的一部分时进行测量。 应该应用“目标、问题、度量”范式（Basili 1992），其中收集测量数据以回答特定问题，答案有助于实现目标，例如降低创建系统架构的成本或增加系统对特定利益相关者的价值。 图 1 显示了适当措施为企业级治理提供信息并推动改进周期的一种方式，例如 6 Sigma DMAIC（定义、测量、分析、改进、控制）模型。

图 1. 评估企业或企业中的系统工程性能：闭环治理的一部分。 （SEBoK 原创）

绩效考核办法探讨

评估 SE 内部流程（质量和效率）

过程 是 “将输入转化为输出的一组相互关联或相互作用的活动”。 SEI CMMI 能力成熟度模型 (SEI 2010) 为业务和企业评估其 SE 流程提供了一种结构化的方法。 在 CMMI 中，过程域是一个领域中的一组相关实践，当它们共同实施时，可以满足一组被认为对改进该领域很重要的目标。 有用于获取、开发和服务的 CMMI 模型（SEI 2010, 11）。 CMMI 定义了如何根据从 0 到 3 的能力级别和从 1 到 5 的整体组织成熟度来评估各个过程域。

评估为新项目或新项目阶段动员的能力

成功和及时的项目启动和执行取决于在正确的时间有合适的人员。 如果关键资源部署在其他地方，它们就不能在这些资源发挥最大作用的早期阶段应用到新项目中。 排队理论表明，如果资源池以满载或接近满载运行，延迟和排队是不可避免的。

在整个生命周期中管理团队的能力是一种组织能力，它对项目和组织的效率和有效性具有重大影响。 这包括能够

• 迅速动员团队；
• 建立和定制一套适当的流程、指标和系统工程计划；
• 支持他们保持高水平的表现；
• 将获得的知识资本化；
• 随着团队的结束，迅速重新部署团队成员。

专家和专家习惯于审查过程、批评解决方案、创建新颖的解决方案和解决关键问题。 专家和专家通常是稀缺资源。 很少有企业能够拥有足够多的具备所有必要技能和行为的专家，以便在需要时分配给所有团队。 如果技能是企业竞争地位或治理方法的核心，那么通过治理流程来管理它们是有意义的，以确保他们的技能在整个企业中发挥最大作用。

企业通常会发现自己在有足够的空间以在事情没有按计划进行时保持项目按计划进行和有效地利用资源之间取得平衡。

项目 SE 输出（成本、进度、质量）

项目中的许多 SE 输出是在生命周期的早期产生的，以支持下游活动。 在项目遇到集成、验证和确认问题或过渡到运营之前，早期 SE 工作产品中的隐藏缺陷可能不会完全显现。 密集的同行评审和严格的建模是检测和纠正 SE 工作产品中的缺陷和缺乏一致性的正常方法。

可以在组织层面监控领先指标，以帮助直接支持遇到麻烦的项目或团队。 例如，INCOSE 领先指标报告 (Roedler et al. 2010) 提供了一组在项目层面有用的指标。 精益西格玛提供了一种评估整个企业价值流中的利益交付的工具。 现在正在开发系统工程的精益推动器（Oppenheim et al. 2010）。 一种新兴的良好实践是使用 精益价值流图 来帮助优化项目计划和流程应用。

在一个成熟的组织中， SE 质量 的一个很好的衡量标准 是必须“异相”纠正的缺陷数量。 即，在生命周期的后期阶段，而不是引入缺陷的阶段。 这可以很好地衡量过程性能和 SE 输出的质量。 在单个项目中，工作产品批准、审查行动关闭和缺陷错误趋势包含允许估计残余缺陷密度的信息（Roedler 等人 2010；Davies 和 Hunter 2001）。

由于前端 SE 对整体项目绩效的影响，关注 SE 可交付成果的质量和及时性非常重要（Woodcock 2009）。

SE 项目附加值

正确 管理 和执行的 SE 应该在质量、风险规避、改进的连贯性、更好地管理问题和依赖关系、首次正确的集成和形式验证、利益相关者管理和有效范围管理方面为项目增加价值。 因为 SE 的质量和数量不是影响这些结果的唯一因素，而且因为效果是延迟的（项目早期的良好 SE 在后期阶段得到回报），所以已经进行了大量研究来建立证据支持SE 在项目中所声称的好处。

系统工程 的经济价值一文中提供了主要结果的摘要 。

系统为最终用户增值

对最终用户的系统附加价值取决于系统的有效性以及要求和设计与最终用户的目的和使命的一致性。 系统最终用户通常只间接参与采购过程。

对 SE 价值主张的研究表明，良好的项目成果不一定与良好的最终用户体验相关。 有时，系统开发人员不愿与最终用户交谈，因为收购方害怕需求蔓延。 有相反的经验——最终用户的参与可以带来更成功和更简单的系统解决方案。

表明最终用户满意度的两种可能措施是：

1. 使用用户验证的任务场景（名义和“未雨绸缪”的情况）来验证需求，推动权衡并组织测试和验收；
2. 使用 技术性能测量 (tpm)来跟踪与运营效用直接相关的关键性能和非功能性系统属性。 INCOSE SE 领先指标指南（Roedler et al. 2010, 10 和 68）将“技术测量趋势”定义为 “在满足有效性测量 (moe) /性能测量 (mop)/关键性能参数 (KPP) 和 技术性能测量（tpm）。 典型的 TPM 进度图如图 2 所示。

图 2. 技术性能测量 (TPM) 跟踪（Roedler 等人，2010 年）。 本材料经国际系统工程委员会 (INCOSE) 许可转载。 所有其他权利均由版权所有者保留。

SE 对组织的附加值

企业/企业层面的 SE 旨在开发、部署和启用有效的 SE，从而为组织的业务增加价值。 业务/企业中的 SE 职能应了解其在更大范围内必须发挥的作用，并确定适当的绩效衡量标准——源自业务或企业目标，并与组织其他部分的目标保持一致——以便优化它的贡献。

组织的 SE 能力发展

CMMI (SEI 2010) 提供了一种评估业务和企业的流程能力和成熟度的方法。 较高的 CMMI 级别涉及跨业务或企业的能力的系统集成。

CMMI 衡量能力发展的一个重要维度，但 CMMI 成熟度水平不是业务有效性的直接衡量标准，除非 SE 衡量标准与业务绩效衡量标准适当整合。 这些可能包括投标成功率、市场份额、价值链中的位置、开发周期时间和成本、创新和重用水平，以及将 SE 能力应用于业务感兴趣的特定问题和解决方案空间的有效性.

个人社企能力发展

评估个人 中描述了对个人 SE 能力发展的 评估。

资源利用、当前和预测

罗德勒等人。 (2010, 58) 为员工的增加和在项目中的使用提供了各种指标。 在整个业务或企业中，关键指标包括项目的整体人力趋势、前向负荷的稳定性、加班水平、资源净空（如果有的话）、员工流动率、培训水平以及持续时间承诺关键资源。

工具和方法的部署和一致使用

使用一系列软件工具来管理系统开发和服务管理的复杂性是一种常见的做法。 这些范围从简单的办公套件到复杂的逻辑、虚拟现实和基于物理的建模环境。

部署 SE 工具需要仔细考虑目的、业务目标、业务有效性、培训、能力、方法、风格、业务有效性、基础设施、支持、工具与现有或修订的 SE 流程的集成，以及确保一致性和寿命的方法和适当的信息配置管理。 系统的使用时间可能超过 50 年，但 10-15 年前的存储介质和文件格式在大多数现代计算机上是不可读的。 许多用户希望能够使用单个通用模型； 可能是两个工程师坐在一起使用相同的工具，他们使用的建模风格完全不同，他们无法处理或重复使用彼此的模型。

随着时间的推移以及跨站点和项目的许可证使用情况是工具部署范围和效率的关键指标。 更难评估的是使用的一致性。 罗德勒等人。 (2010, 73) 推荐关于“设施和设备可用性”的指标。

实际考虑

在业务/企业层面评估 SE 绩效很复杂，需要考虑软问题和硬问题。 利益相关者的关注和满意度标准可能不明显或不明确。 明确和明确的互惠期望以及目的、价值观、目标和激励措施的一致性有助于在整个组织内实现协同效应并避免误解。

“被衡量的事情就完成了。”由于指标驱动行为，因此重要的是要确保用于管理组织的指标反映其目的和价值观，并且它们不会驱动不正当的行为（Roedler 等人，2010 年）。

流程和测量需要花费金钱和时间，因此获得正确数量的流程定义以及流程、测量、人员和技能之间的正确投资平衡非常重要。 任何足够灵活以允许创新的过程也将足够灵活以允许错误。 如果流程被视为过度限制或规定性的，它可能会抑制创新并削弱创新者努力防止错误的动力，从而导致过度规避风险。

过程改进工作本身可能成为目的，而不是提高业务绩效的手段（Sheard 2003）。 为了防止这种情况发生，建议明确关注目标（Blockley 和 Godfrey 2000）和附加值（Oppenheim et al. 2010），并确保高层管理人员明确和持续地致力于推动过程改进方法以实现目标所需的商业利益。 良好的流程改进与建立绩效文化和流程一样重要。

系统工程过程是个人技能、创造力、直觉、判断力等的重要补充，而不是替代品。创新的人需要理解这个过程以及如何让它为他们工作，既不能忽视它，也不能成为奴隶给它。 系统工程测量显示了需要应用发明和创造力的地方。 SE 过程创建了一个框架来利用创造力和创新来提供超越创造性个人能力的结果——结果是过程、组织和领导力的新兴属性。（西利托 2011）

在企业内部开发系统工程能力

对许多组织来说，持续改进的追求是永恒不变的。对丰田的描述(Morgan and Liker 2006)，“追求完美”的精益原则(Oppenheim et al. 2010)，以及“不松懈”的原则(Kotter 1995)，都推动了持续改进的需求。

在整个生命周期中管理团队的能力——快速调动团队，建立并定制一套适当的过程、度量标准和系统工程计划，支持他们保持高水平的绩效，利用获得的知识，并在团队结束时迅速重新部署团队成员——是一种关键的组织能力，对项目和组织的效率和有效性有重大影响。

企业为团队提供必要的资源、背景信息、设施、现金、支持服务、工具等。它还提供了一个团队可以有效工作的物理、文化和治理环境。企业的关键功能包括生成和维护相关资源，将它们分配给团队，提供支持和治理功能，维护专业知识和知识(关于过程、应用领域和解决方案技术)，确保团队执行的工作，组织财务，以及维护企业的生存能力。

为了使改进能够持续，它们必须存在于企业中，而不仅仅是个人，因此改进可以随着人员的离开而持续下去。这反映在能力成熟度模型集成(CMMI) (SEI 2010)从“英雄文化”到“量化管理和优化过程”的发展中。

本主题概述了在能力开发和组织学习中要考虑的问题。

概述

图 1 显示了一个“分析 - 组织 - 执行 - 评估 - 开发”循环，它本质上是对 Deming (1994) PDCA（Plan Do Check Act）循环的重新表述。 分析步骤应涵盖当前和未来的需求，只要这些需求可以确定或预测。如评估业务和企业的系统工程性能中 所讨论的，目标和性能评估 可以基于许多评估框架，例如业务性能和有效性的直接测量以及 CMMI 能力成熟度模型。 有证据表明，许多组织发现业务绩效和 CMMI 级别之间存在正相关关系（SEI 2010）。 这将在系统工程的经济价值中进一步讨论。

图 1. 业务和企业主题的概念图。 （SEBoK 原创）

改变杠杆

SE 经理有许多可以用来开发 SE 能力的变革杠杆。 移动杠杆和看到效果之间的时间延迟量因级别类型、企业规模、企业文化和其他因素而异。

调整上下文、范围、目的、责任、问责制企业

如果其他变革杠杆不能达到预期的效果，企业或企业可能不得不重新协商其对更高层次战略和使命的贡献。

审查和调整所需的能力

在最初的分析中，所需的能力可能被高估或低估了。 每次循环循环后，都应重新评估需求，以确保规划假设仍然有效。

调整企业内部组织

调整组织和职责，使“正确的人做正确的事” ，并确保组织充分利用他们的知识和技能，通常是最容易做出的改变（而且可能会产生最快的效果） .

一个潜在的风险是，过多的组织流失会破坏关系，破坏组织的稳定性并损害绩效。 流程改进可能会因考虑不周的重组而受挫，并可能危及组织已获得的任何证明其流程能力或绩效的认证。

开发/培训/重新部署/获取新的资源、服务和个人

资源、服务和个人可能包括组织业务和企业执行系统工程 中列出的组织 SE 能力的任何组成部分 。

杠杆包括分包工作要素、改善信息流、升级设施以及启动短期培训和/或长期员工发展计划。 许多组织认为他们如何处理这些改进是专有的，但 NASA 等组织在其 APPEL 网站上提供了见解（NASA 2012）。

个人的发展在 赋能个人中进行了讨论。

改善文化

文化 变革非常重要和强大，但需要作为长期游戏来处理，并给予长期承诺。

调整和改进措施和指标的一致性

测量 驱动行为。 改善业务/企业不同部分的目标和激励机制的一致性，以便每个人都为共同的目标而工作，这可能是提高业务/企业绩效的一种非常有效和强大的方式。 这种一致性确实需要一些自上而下的指导，也许是自上而下的整体方法，将业务/企业视为一个系统，清楚地了解企业能力的要素如何相互作用以产生协同价值（请参阅 评估业务的系统工程绩效和企业 ）。 通常报告说，随着组织改进其关于 CMMI 的流程，其度量和测量方法必须发展。

改变方法

把日常事情做得更好

有大量的资源和技术，包括 Kaizen、Deming PDCA (Deming 1994)、Lean (Womack and Jones 2003, Oppenheim et al. 2010)、Six-Sigma (Harry 1997) 和 CMMI。

价值流图是一种强大的精益技术，可以找到改善界面流动和交接的方法。

管理技术准备

在高科技产业中，许多问题是由于在技术成熟之前试图将新技术转化为产品和系统而引起的； 没有充分考虑从技术演示到产品可重复和可靠性能所需的努力； 或高估现有产品的可重用性。 NASA 的 TRL（技术准备水平）结构由 John Mankins 于 1995 年首次提出（Mankins 1995），被广泛且成功地用于理解和降低技术转型风险。 NASA 以外的一些组织，例如美国国防部，甚至有自动化来帮助工程师评估技术准备情况。

TRL 的变体已经出现，例如系统就绪级别 (SRL) (Sauser et al. 2006)，它认识到成功交付系统的能力不仅仅取决于用于创建这些系统的技术基础的成熟度； 例如，使用两种相对成熟但以前从未集成在一起的技术可能会带来惊人的风险。

计划中的变革：在组织中站起来或正规化 SE

计划中的变更可能包括：

• 将 SE 引入企业（Farncombe 和 Woodcock 2009）；
• 改进/转型；
• 规范企业或项目执行 SE 的方式；
• 处理合并/分立/重大重组；
• 开发新一代或颠覆性产品、系统、服务或产品线（Christensen 1997）；
• 进入新市场；
• 管理项目生命周期过渡：启动、转变到下一阶段的开发、过渡到制造/运营/支持、结束和退役。

CMMI 广泛用于为系统工程环境中的计划变更提供框架。 计划变革需要采取整体方法，将人员（知识、技能、文化、能力和动机）、流程、衡量标准和工具视为一个连贯的整体。 现在人们普遍认为，工具和流程不能替代技能和经验。 相反，它们只是提供了一个框架，让有技能和有动力的人可以更有效地工作。 因此，改变应该从人开始，而不是从工具开始。

在开始变更之前，建议以当前业务绩效和 SE 能力为基准，并建立指标，以便及早显示变更是否达到预期效果。

应对不可预见的干扰

不可预见的中断可能是内部或外部施加的。 外部造成的干扰可能由以下原因引起：

• 客户——赢/输合同、强制组队或重定向；
• 竞争对手——当前的产品变得更具竞争力/竞争力降低，可能会在市场上推出颠覆性创新； 或者
• 治理和监管变化——新流程、认证、安全或环境标准。

内部或自我引起的干扰可能包括：

• 由于人员、设施、资金的损失而导致能力下降；
• 产品或服务在操作或处置中出现故障； 或者
• 战略变更（例如新任 CEO、对市场动态的反应或优先权优先）。

嵌入变化

在 SE 环境中，一旦实现， 需要持续努力以保持改进，例如更高的 CMMI 水平、精益和安全文化等。有几个有用的变化模型，包括 Kotter 的 8 个变化阶段（Kotter 1995）：

1. 建立紧迫感；
2. 建立联盟；
3. 制定清晰的愿景；
4. 分享愿景；
5. 使人们能够清除障碍；
6. 确保短期胜利；
7. 巩固并继续前进；
8. 锚定更改。

前六个步骤很简单。 混沌模型 (Zuijderhoudt 1990; 2002) 利用复杂性理论表明，如果短期胜利没有得到巩固、制度化和锚定，则很可能出现倒退。 这解释了经常看到的现象，即组织沉迷于众多变革举措，但没有一个能坚持下去，因为在前一个被锚定之前，注意力转移到了下一个。

变革管理文献

SE 领导者（董事、职能经理、团队领导和专家）有责任和控制杠杆来实施它们，这取决于他们组织的业务模型和结构。 他们将大量时间和精力花在管理变革上，以追求短期、中期和长期的组织目标：“把日常工作做得更好”； 让改变发生； 嵌入变革并带来收益； 并应对中断的影响。 合并、收购和项目启动、阶段变化、从“发现”阶段到“交付”阶段的过渡、向运营的过渡、资金水平的突然变化，都可能对可能破坏团队、流程、 文化稳定的组织施加突然的变化 和性能。 下面的表 1 提供了一般管理文献和特定的系统工程知识。

文化

建立和管理文化、价值观和行为是系统工程的一个关键方面，特别是在组织内部署SE的环境中(Fasser和Brettner 2002)。哥伦比亚事故调查报告(NASA 2003, 101)将文化定义为“一个特定机构运作的基本价值观、规范、信仰和实践”。

稳定的安全性和过程文化是有效的SE的关键，可能会被过快的变更速度、高度的流失(参见Nimrod崩溃报告，Haddon-Cave 2009)，或者被工程师认为是由管理层随意强加的变更(参见Challenger，下面讨论)所破坏。另一方面，高度竞争、对抗性或“指责”文化会阻碍信息的自由流动，破坏工作场所的协同效应。

在跨国、多业务、多学科的协同项目日益盛行的企业实践中，这些因素显得尤为重要。

对文化问题的有效处理是影响SE工作成败的一个主要因素。

系统思维和学习型组织的文化

提高 SE 效率和有效性可能是文化变革的目标。 这种文化变革鼓励人们学会从制度、组织和企业的角度去思考和行动； 并且，采用第 2 部分 中的系统方法概述和 Lawson (2010) 中描述的系统方法。 请参阅知识领域 系统思维 。

获得学习型组织 文化可能是文化变革的另一个目标。 一旦学习型组织存在，文化变革通常会变得更容易实现。

学习型组织旨在吸收、传播、生成和利用知识（Sprenge 和 Have 1996）。 组织需要管理正式信息并促进隐性知识的增长和利用。 他们应该从经验中学习并创建一种企业记忆 形式——包括流程、问题领域和解决方案空间知识，以及有关现有产品和服务的信息。 Fassner 和 Brettner (2002, 122-124) 认为共享心智模型 是企业知识和文化的一个关键方面。

学习型组织文化由以下学科促成：

• 自我超越， 一个人不断澄清和深化个人愿景，将精力集中在它上面，并在寻求它时培养耐心，以便以越来越客观的方式看待现实；
• 心智模型， 人们意识到心智模型确实占据了他们的思想并塑造了他们的行为；
• 共同愿景，共享 经营价值观和使命感，以建立基本的相互关系； 和
• 团队学习， 人们的想法一致，给人一种感觉，即团队作为一个整体取得的成就大于其个人成员所取得成就的总和。

系统思维 支持这四个学科，因此成为 第五个学科 ，在促进学习型组织方面发挥着关键作用（Senge et al. 1994）。

文化缺陷以及如何改变它们

杰克逊（2010）等人将对系统有害的文化缺陷描述为消极范式 。 例如， 在挑战者和哥伦比亚案例中看到的 拒绝风险 范式的标志是文化上不愿识别真正的 风险。 当个人认为一个系统是安全的但实际上是不安全的，那就是 泰坦尼克效应 范式，它当然是以 1912 年的远洋班轮灾难命名的。

改变的方法

Jackson 和 Erlick (Jackson 2010, 91-119) 发现缺乏证据表明可以从成功的角度改变文化。 然而，他们确实提出了实践社区 (Jackson 2010, 110-112)，这是一种基于组织心理学原理的方法，并讨论了其他文化变革方法的优缺点，包括培训、辅导、苏格拉底式教学、使用团队、独立审查、标准流程、奖励和激励措施、成本和进度利润的使用、对有魅力的高管的依赖以及管理层的选择。 Shields (2006) 提供了类似的全面审查。

哥伦比亚事故 (NASA 2003) 和三角火灾 (NYFIC 1912) 官方报告，除其他外，呼吁通过改进领导来解决文化问题，通常通过更客观的审计方法来加强。 一种审计形式是独立技术权威，它：

• 独立于项目组织；
• 只解决技术问题，而不是管理问题；
• 有权采取行动避免失败，包括否决发射决定。

独立技术机构不能向相关项目的项目经理报告，它可以在完全独立的企业或企业内制定，可以客观地查看该项目。 这些规定的重点是确保独立技术机构确实是独立的。

管理和领导专家已经确定了在组织中领导文化变革的方法，除了与安全相关的文化变革。 例如，Gordon (1961) 在他关于使用称为Synectics 的类比推理的工作中是强调创造性思维的几个人之一。 Kotter (1995) 提倡采用一系列步骤来改造一个组织。

文化如何在个人和群体中体现

随着社区的物质、社会和宗教环境在几代人之间发生变化，文化信仰、价值观和习俗也会随之发生变化，尽管速度较慢。

Helmreich 和 Merritt 描述了文化因素在航空安全背景下的影响，并提出了对医学等其他领域安全文化的影响。 参见（Helmreich 和 Merritt，2000）以及同一作者的其他著作。

我们可以从以下方面来描述一个人的文化取向：

• 民族和/或民族文化；
• 职业文化；
• 组织文化。

下面概述了这些文化方面的一些细节。

民族和/或民族文化

遗产、历史、宗教、语言、气候、人口密度、资源可用性、政治和民族文化等因素的产物是在一个人的成长时期获得的，很难改变。 民族文化影响态度、行为和与他人的互动。

国家文化可能有助于确定一个人如何处理或反应：

• 条款和规则;
• 不确定; 和
• 表达情感，包括自己的情感。

民族文化也可能影响一个人是否

• 以直接和特定的方式进行交流，或者相反；
• 以分级方式或协商方式提供领导；
• 接受在上下级关系中做出的决定，或质疑它们。

职业文化

职业文化是种族或民族文化的叠加，通常表现为社区意识和基于共同身份的结合（Helmreich and Merritt 2000）。 著名的职业文化例子包括医生、飞行员、教师和军人。

职业文化的要素可能包括：

• 共同的专业术语
• 具有约束力的行为规范
• 共同的道德价值观
• 自我调节
• 进入壁垒，例如选择性、竞争和培训
• 机构和/或个人对变革的抵制
• 声望和地位，有时以徽章或制服表示
• 一般和/或基于性别的对专业成员的刻板印象

需要通过广泛的培训来灌输专业文化中特别重要的元素（例如，影响安全或生存能力的元素），并以适当的时间间隔加以强化。

组织文化

一个组织的文化是由其领导力、产品和服务、与竞争对手的关系以及在社会中的角色等因素决定的。

与其他组织相比，组织文化没有标准化，因为在一个组织中有效的东西很少在另一个组织中有效。 即便如此，以下要素的优势通常会产生强大的组织文化：

• 企业形象;
• 领导;
• 士气和信任；
• 团队合作与合作；
• 就业保障;
• 专业发展和培训；
• 赋予个人权力；
• 信心，例如对质量和安全实践，或对管理沟通和反馈的信心。

当将组织中人员的文化视为一个整体时，组织文化就充当了所有人共享的共同层。 尽管如此，不同的国家文化会产生领导风格、经理与下属关系等方面的差异，尤其是在跨国整合程度高的组织中。

因为组织具有正式的责任和权力等级，组织文化比专业或国家文化更容易受到精心策划的变革。 如果以同情当地文化的方式进行更改（例如，与遥远的集团总部相反），它们可以带来显着的绩效优势。 这是因为组织文化将国家和专业文化的影响转化为标准的工作实践。

文献中有许多关于文化的定义。 哥伦比亚事故调查委员会 (NASA 2003) 为理解文化和工程提供了有用的定义。

文化与安全

Reason (1997, 191-220) 将关注安全的文化描述为具有四个组成部分：

1. 一种报告文化，鼓励个人报告错误和未遂事件，包括他们自己的。
2. 一种公正的文化，提供一种信任的氛围，鼓励甚至奖励人们提供必要的安全相关信息。
3. 一种灵活的文化，它摒弃了传统的分层报告结构，转而支持更直接的团队间沟通。
4. 一种愿意从安全相关信息中得出正确结论并在必要时实施改革的学习文化。

Weick 和 Sutcliffe (2001, 3) 引入了术语高可靠性组织 (hros) 。 尽管 在受灾难性事件影响的领域中处于艰难的条件下 ， HRO的事故发生率低于其应有的份额。 例子包括电网调度中心、空中交通管制系统、核航空母舰、核电站、医院急诊科和人质谈判小组。 HRO 有五个特点（Weick 和 Sutcliffe 2001, 10）：

1. 全神贯注于失败 ——HRO 避免自满，从未遂事件中学习，不要忽视大大小小的错误。
2. 不愿简化解释 ——HRO 简化得更少，看得更多。 他们“鼓励人们对公认的智慧持怀疑态度”。
3. 对运营的敏感性 ——HRO 努力检测“潜在故障”，James Reason (1997) 将其定义为系统缺陷，相当于等待发生的事故。 他们具有良好的态势感知能力，并不断进行调整以防止错误累积和扩大。
4. 对复原力的承诺 ——HRO 尽量减少错误并即兴创作“保持系统正常运行的变通办法”。 他们对技术有深刻的理解，并不断考虑最坏的情况以进行纠正。
5. 尊重专业知识 ——人力资源组织“推动决策制定”。 决策是在“第一线”做出的。 他们避免僵化的等级制度，直接去找有专业知识的人。

美国核监管局（2011 年）在其安全文化政策声明中主要关注领导力和个人权威。

历史灾难与安全文化

下表中描述的案例是官方报告或权威专家将文化列为相关系统灾难性故障的一个因素的众多案例中的一部分。

表 1. 安全关键事件中的文化讨论示例。 （SEBoK 原创）

行为准则

企业文化有可能强化或破坏道德行为。 例如，鼓励公开透明的决策和行为的文化使得不道德行为更难被发现。 世界各地文化的许多差异反映在对道德行为是什么的不同观点上。 这通常反映在国际公司在全球开展业务时面临的困难，有时会导致丑闻，因为在一个国家被认为是道德的行为可能在另一个国家被认为是不道德的。 有关这方面的更多信息，请参阅 道德行为 。

对系统工程的影响

随着 SE 越来越多地寻求跨越国家、种族和组织边界的工作，系统工程师需要了解文化问题以及它们如何影响协作工作环境中的期望和行为。 社会企业需要以适合受众文化和个人风格的顺序和方式呈现信息。 这需要选择是否从原则或实际示例、抽象级别或用例、大图或详细视图开始。

对文化问题的敏感性是 SE 努力的成功因素（Siemieniuch 和 Sinclair 2006）。