|
本主题是应用于工程系统 知识领域 (KA) 的系统方法的一部分。 它详细描述了与识别和理解问题或机遇相关的知识。本主题中的活动所描述的问题情况可以作为综合可能解决方案 的起点 。下面描述的任何活动也可能需要在一个相关系统(SoI)生命周期的特定时刻与系统方法中的其他活动同时考虑。
下面描述的活动应在 本 KA 开始时的系统方法概述主题的背景中考虑。 该知识领域的最后一个主题是 应用系统方法，它考虑了如何将这些活动用作系统方法的一部分的动态方面，以及这如何与系统工程 (SE) 的 元素详细关联
这里使用的短语“问题或机遇”承认“问题”并不总是消极的情况，也可以是改善情况的积极机遇。
介绍
根据 Jenkins (1969) 的说法，系统方法的第一步是“识别和制定问题”。 SE 知识体系指南 (SEBoK) 中描述的系统方法主要是一种 硬系统方法。 该方法的分析、 综合和证明部分假定问题或机遇已被识别并达成一致，并且需要“新的” 工程系统 解决方案。
然而，系统方法不一定适用于新设计和构建的技术解决方案的开发和使用。 可能会理解针对潜在问题的抽象 或实验性解决方案，以帮助就问题背景达成一致。 解决方案可能涉及重组现有 系统(SoS) 背景或修改或重用现有 产品和服务。 该方法的问题和机遇部分与 软系统方法重叠。 这将在下面更详细地讨论。
关于系统复杂性 必须考虑的一件事 是机遇情况可能难以完全理解； 因此，系统解决方案可能不会在第一次解决问题，但仍然有助于加深对问题问题的理解以及下一步要尝试什么来解决问题。
因此，问题理解和识别通常不是指定问题的一次性过程，而是与解决方案综合和分析结合使用，以便随着时间的推移更全面地理解问题和解决方案（参见应用系统方法更完整地讨论该方法的这一方面的动态）。
问题理解
软系统思维不寻找“问题”，而是考虑有问题的情况。 形成这种情况的系统 视图以帮助 利益相关者更好地理解彼此的 观点，并为当前系统环境中的定向干预提供一个起点 。 如果进行完整的软系统干预，例如 软系统方法论 (SSM) (Checkland 1999)，它将不包括形式分析、综合和证明。 然而，SSM 方法最初是基于硬方法论，特别是 Jenkins (1969) 提出的一种方法。 它遵循系统方法的基本原则：“分析” 概念模型共同理解，“综合”干预策略，并“证明”问题情况的改善。
通常，硬方法和软方法之间的区别并不像理论所暗示的那样清晰。 作为信息系统设计开发的一部分，Checkland 本人参与了 SSM 的应用（Checkland 和 Holwell 1998）。 现在很多人都同意，虽然“纯软系统”方法可以发挥作用，但现在解决的服务和企业问题只能通过软问题模型和硬系统的结合来成功处理 解决方案。 Mingers and White (2009) 给出了一些相关的例子。 特别是，他们引用了“过程和内容：使用 SSM 的两种方式”（Checkland 和 Winters 2006）。 将来，工程系统问题很可能会被陈述、解决并用作主要软干预的一部分，这将对解决方案空间所需的开发速度施加压力。这在主题生命周期模型中进行了更全面的讨论 。
批判性系统思维和多方法论方法（Jackson 1985）通过提倡“挑选和混合”方法进一步推动了这一点，其中选择最合适的模型和技术来适应问题，而不是遵循单一的方法论（Mingers 和 Gill 1997 年）。 因此，即使使用下面描述的硬问题识别方法，也应该在其中考虑使用一些软系统技术（例如丰富的图片、根定义或概念模型）。
问题识别
硬系统思维的前提是存在问题，并且可以由一个或多个利益相关者以客观的方式陈述。 这并不意味着硬系统方法从定义的问题开始。 与关键利益相关者一起理解潜在问题仍然是该方法的重要组成部分。
根据 Blanchard 和 Fabrycky (2006, 55-56) 的说法，定义问题有时是最重要和最困难的一步。 简而言之， 除非可以清楚地描述它应该完成的工作，否则无法定义 一个系统。
根据 Edson (2008, 26-29) 的说法，需要提出三种问题来确保我们完全理解问题的情况。 首先，问题的难度或理解程度如何？ 这个问题的答案将有助于确定问题的易处理性。 问题可以是“温和的”、“常规的”或“邪恶的”：
- 对于温和的问题，解决方案可能是明确且显而易见的。
- 常规问题是定期遇到的问题。 它们的解决方案可能并不明显，因此应认真关注它们的各个方面。
- 棘手的问题（Rittel and Webber 1973）无法完全解决，甚至可能无法完全定义。 此外，对于棘手的问题，不可能理解将系统应用于问题的全部效果。
接下来，谁或什么受到影响？ 可能存在导致问题的情况 元素、受问题影响的元素以及仅在循环中的元素。 除了这些因素之外，什么是 环境以及影响问题的外部因素是什么？ 在检查这些方面时， 可以有效地应用系统思维的工具和方法。
最后，问题的各种观点是什么？ 大家觉得有问题吗？ 也许存在相互矛盾的观点。 所有这些观点都需要定义。 受系统影响、从系统中受益或可能受到系统伤害的人被称为利益相关者。 Wasson (2006, 42-45) 提供了一份完整的利益相关者类型列表。 如上所述，软系统模型的使用可以在其中发挥重要作用。 在考虑这些问题时，使用情境视图来描述问题可能很有用，即使选择了单个问题观点以供进一步考虑。
运筹学是一种硬系统方法，它专注于通过部署已知的解决方案来解决问题情况。 典型方法的问题分析步骤询问有关当前系统的局限性和 成本的问题，以确定需要进行的效率改进（Flood 和 Carson 1993）。
传统的 SE 方法倾向于更多地关注描述问题的抽象模型，然后使用该模型开发一个解决方案，该解决方案将产生利益相关者期望看到的好处（Jenkins 1969）。 人们通常期望必须创建一个新的解决方案，尽管情况并非如此。 Jenkins 建议 SE 同样适用于现有系统的重新设计。 清楚地了解利益相关者在这方面的期望应该可以更好地理解部分问题。 利益相关者是否期望新的解决方案或对其现有解决方案的修改，或者他们是否真正对考虑两者优缺点的解决方案替代方案持开放态度？ 如综合可能 的解决方案中所述，此类期望将影响解决方案的建议 文章。
定义所需的利益相关者结果、利益和约束的一个重要因素是存在问题或机遇 的 操作环境或场景。 Armstrong (2009, 1030) 提出了两种情景：第一种是描述性情景，即现在存在的情况，第二种是规范性情景，即未来某个时间可能存在的情况。
问题理解的所有这些方面都可以与系统背景的概念相关。
问题背景
工程系统背景主题确定了一种 可以围绕感兴趣系统(SoI)解决复杂系统情况的方法。“问题背景”的初始识别可以被认为是系统方法的这一部分的结果。
系统方法不应只考虑软或硬情况。 更恰当地说，应该使用两者的方面来理解问题或机遇。 一般而言，以工程系统背景为重点的系统方法的应用将导致硬系统背景，其中可以定义已识别的 SoI 和所需的结果。
更广泛的 SoI 和环境的初始描述用作问题或机遇问题范围。 期望的利益相关者利益在更广泛的系统中被表达为结果，并且可以确定 SoI 预期用途的一些初始表达。 Jenkins (1969) 定义了一种问题表述方法，其中：
- 说明 SoI 的目标
- 定义了更广泛的 SoI
- 定义更广泛的 SoI 的目标
- 定义系统的目标
- 定义经济、信息和其他条件
在硬系统问题背景中，可能包括对逻辑或理想系统解决方案的描述。 这个理想系统不能直接实现，而是描述了任何可实现的系统解决方案所需的属性。
为了支持这个问题或机遇描述，SoI 的软背景视图将有助于确保考虑更广泛的利益相关者的关注。 如果定义了软系统背景，它可能包括一个概念模型（Checkland 1999），该模型描述了解决问题情况的系统的逻辑元素以及不同利益相关者如何看待它们。 与硬系统视图不同，这并没有描述理想的解决方案，而是提供了关于潜在利益相关者如何看待任何解决方案的各个方面的替代视图。
在具有强强制性维度的问题背景下，问题背景应包括对利益相关者的相对权力和重要性的识别。
问题背景应包括 利益相关者所需的成本、部署时间、使用时间和运营有效性的一些界限。一般而言，既描述了完整的问题背景，也描述了接下来要解决的问题的商定版本。 （请参阅 应用系统方法。）
| 
