功能等效

示例：物流系统替换

一家物流公司正在进行一项计划，以替换用于包裹验收、路线规划和交付的过时软件。作为这项计划的一部分，他们同意了一项由 IT 主导的计划，与业务利益相关者的参与度相对较低。技术观点认为，他们可以简单地进行“功能一致性”，从而解决他们迫切需要替换过时技术的需要。作为这项计划的一部分，他们完成了一项主要工作，以替换从客户处接收包裹的系统。我们在该计划的最后阶段参与进来。

我们认为，与业务利益相关者的低参与度对该计划构成风险，特别是因为我们从另一个项目中听说，企业对开发工作感到沮丧。作为这项工作的一部分，我们与关键利益相关者（包括财务团队）进行了交谈。正是在这个时候，我们意识到他们进行了一项审查，该审查表明只有相对较小比例的客户对公司有利可图。反过来，这意味着只有很小一部分“包裹类型”是有利可图的，许多包裹由于特殊处理要求而给公司带来了损失。因此，企业制定了一项计划，停止处理这些包裹。

事实证明，“功能一致性”项目中投入了大量精力来处理这些包裹，而这些包裹正是企业表示不再需要的包裹。企业希望在没有这些困难的边缘案例的情况下，流程和软件会变得更加简单。在这种情况下，“功能一致性”导致花费了大量时间和金钱来处理企业不再需要的需求，同时进一步损害了 IT 在企业眼中的声誉。

示例：电子商务组织重新平台化

这家公司经历了一段快速增长时期，但多年来没有优先考虑 IT 支出，这造成了替换当前解决方案的许多元素的相对紧迫需求。例如，在某些时期，他们不得不放慢销售速度，以避免压垮核心系统，从商业角度来看，这绝非理想。

许多关键业务运营由同一个大型机处理，该大型机最初是在他们电子商务运营的早期阶段投入使用的。从该系统中提取元素显然在技术上具有挑战性。与此同时，业务领导者在经历了几个破坏性的失败项目后，希望将对员工的任何进一步干扰降至最低。另一个挑战是，当前的流程和系统使得在使用更渐进的方法时，很难对要迁移的产品线进行优先排序。简而言之，很难理解他们销售的哪些东西有利可图，哪些东西没有利可图，因此人们认为唯一的选择是一次性迁移所有内容。基于这些挑战，人们认为仅仅复制他们所拥有的东西是最佳且风险最低的方法。

鉴于当前的业务流程表面上都是一起在同一个大型机中实施的，这意味着任何“功能一致性”替换的范围本质上是整个企业的所有主要活动和流程。他们开始努力记录替换系统的“范围内”现状流程，计划将其用作供应商选择流程的输入。

很快就有几件事变得很清楚。其中之一是，它实际上必须几乎涵盖企业所做的每一项活动，每一次记录“现状”功能的努力都会发现更多需要包含在内以实现“功能一致性”的内容。其次，由于历史上的工作区、多年来不断变化的需求以及许多未解决的错误，实际使用遗留系统的人员最不希望看到的是相同的东西。它几乎总是使他们的工作更加困难，并且是错误和延迟的主要来源。最后，由于错误和工作区，很明显，一些关键流程实际上是在手工构建的电子表格上“离系统”运行的。关键业务数据从大型机中提取出来，用于通过电子表格运行业务流程，然后稍后将修改后的数据上传回大型机。

此时，有些人认为“功能一致性”正在变得过于冒险，范围不断扩大。这是在需求收集过程完成之前，并且该过程没有明确的结束日期。我们的参与在这个阶段停止了，因为我们认为继续进行“功能一致性”风险太大，并且无法提供企业所需的成果，尤其是由于缺乏关键业务指标，使得无法对任何更渐进的方法进行优先排序。几年后，他们仍在进行“现状”需求流程，远远超过了最初的截止日期。

缺乏合适的指标和无法从业务角度对功能元素进行优先排序，通常会迫使企业采用“功能一致性”方法。在这种情况下，我们认为，最初努力收集围绕各种产品线的关键业务指标可能已经提出了分解问题的方法。这是一个很好的例子，说明在没有合适的业务背景和参与的情况下，你无法做出正确的技术决策。

示例：成功替换金融计算服务

我们的一支团队正在为一家大型金融机构工作。他们希望对一个执行复杂财务计算的现有服务进行现代化改造。财务计算的规范是固定的，服务的接口是相似的，只是需要更新技术 - 从 J2EE Session EJB 实现更新到最新（当时）版本的 Java 中的 SOAP Web 服务。

该团队围绕现有实现创建了一个丰富的测试套件，在设置、执行和断言职责之间进行了清晰的隔离。

图 1：功能一致性测试

一旦测试到位，就可以以最小的风险替换执行适配器，并创建一个新的实现，满足与旧系统相同的可执行规范。