评估扩展需求

学习目标

• 描述什么是软件扩展以及为什么需要这些扩展。

我们通过检查术语延长开始讨论扩展。什么是扩展？我们到底在扩展什么？最重要的是，我们为什么要扩展这款解决方案？

所有软件都考虑了范围。此范围定义两个内容，如下所示：

• 软件为客户提供所需的成果。

• 软件如何提供成果

从客户的角度来看，是实现成果，创造价值。对于软件供应商（如 SAP）而言，范围是向客户展示的价值主张的基础，并且是软件设计流程的关键部分。

毫无疑问，SAP ERP 相对于其历史最大的优势之一就是其范围。交付旨在涵盖物流、财务和人力资源领域所有业务流程的产品是一项艰巨的任务。此外，SAP 的客户群涵盖超过 30 个不同行业，任务的规模变得更加清晰。每个行业都有自己的执行特定业务流程的专业方法（例如，银行设计和执行采购流程可能与政府实体或军方不同），即使在同一行业内，各个公司也可以以不同方式设计和执行流程。但是，SAP 从未避免过范围方面的挑战。恰恰相反 – 它已经热情地拥抱。

灵活性需求

毫无疑问，SAP 应用程序所涵盖的范围广度是客户采用 SAP 解决方案的重要因素，但也有另一个值得重视的因素。灵活性：能够调整交付范围，以满足其独特需求。因此，SAP 面临另一个挑战：如何不仅为客户提供范围，还能根据客户的独特需求灵活调整范围？正如范围内的情况一样，SAP 热情地接受了灵活性挑战。但是，要应对这一挑战，SAP 需要具备一些"开箱即用的设计思维"。

一种可能的解决方案是为客户提供安装并上线后的系统，源代码将处于"冻结"状态。客户无法调整或更改此代码，他们只会进一步关注例行维护、更新和升级，所有这些都会在大部分情况下简单无痛。负责维护系统的 IT 部门将仅应用相关补丁，或在适当的时间升级软件。之后，他们将执行快速测试，以确保一切正常运行并完成作业。虽然 IT 部门对这种方法的易用性感到满意，但业务利益相关方和最重要的是，最终用户（实现软件系统的真正价值）很可能不会，因为这两个组都需要在调整方面具有更大的灵活性。不用说，SAP 没有采用这种方法。

另一个潜在的解决方案位于光谱的另一侧：一个系统交付了基线代码资源库，但该代码是"建议"。系统对所有人都免费。代码的更改、修改和批量删除将是公平的游戏。在此环境中，即使 SAP 最简单的维护版本（只是应用简单的技术补丁来更正缺陷）也会充满不确定性。应用此类补丁可能需要数月，此时只需要几分钟。全面升级可能是一场噩梦。根据客户的范围，简单升级中所做的更改可能需要半年。SAP 和客户均需要支付与此类方法相关的大量成本。除了让 IT 花费大量时间处理简单的运营任务之外，还有机会成本使系统无法快速响应需要快速适应的市场变化。与第一种方法一样，SAP 也没有采用这种方法。

需要的是"Goldilocks"方法，其中以下三个不同群体的需求是平衡的：

• 最终用户希望获得具有一致用户体验的软件（更多内容将在后面的课程中介绍），简单易用。

• 业务利益相关方（尤其是流程负责人），他们想要一个稳定的应用程序，但可以根据他们希望执行业务流程的独特方式进行定制。

• 必须安装和维护系统的 IT 部门，其中满足上述两个组的需求，但其中一个以最佳方式管理业务成本。

这种方法是由客户启动的代码调整的结果。该系统安装了标准功能（基于最佳实践），但也具有使客户（以明确和控制方式）以经济高效的方式调整该功能，以实现符合利益相关方需求的预期结果。虽然最初这种方法听起来是不可避免的，但很容易忘记，几十年前，当将 SAP R/3 引入市场时，它被认为是革命性的。但可以说，随着时间的推移，这种平衡方法已经成为 SAP ERP 显著成功的唯一最重要的因素之一。