复杂的自适应出租车服务调度程序

本文基于伦敦出租车服务案例研究(Rzevski和Skobelev, 2014)。该案例研究的重点是为伦敦出租车服务开发一个实时复杂自适应调度程序，能够在不可预测和不断变化的环境中管理数百次出租车旅程的复杂性，同时符合企业的目标和价值观。

背景

当这个项目启动时，这家伦敦最大、最知名的微型出租车运营商拥有超过2000辆车，每辆车都配有全球定位系统(GPS)导航系统。由各种各样的车队,包括小型货车和运动型多用途车(suv),一些与设备匹配特殊的客户需求。通常情况下，大约有700名司机同时工作，互相争夺客户。

该公司拥有现代化的企业资源规划(ERP)系统和一个拥有100多名操作员同时接收订单的呼叫中心。一些订单是通过公司网站收到的。一大批技术熟练的调度员为客户分配车辆。

出租车服务的主要特点如下:

• 每天超过 13,000 个订单
• 有时每小时超过 1,500 个订单（每 2.4 秒 1 个订单）
• 不可预测的订单到达时间和地点
• 各类客户，如个人、企业、重要人物（VIP）、各种优惠关税、适合残疾人的特殊要求、小孩（儿童座椅）、宠物运输等。
• 许多从公司租用汽车并被允许在适合他们的时间开始和结束轮班的自由司机，这可能每天都不同
• 伦敦市中心的客户在下单后 15 分钟内保证取货时间
• 从根本上说，该公司试图为每个客户找到最经济匹配的车辆。 但是，此基本要求的动态例外包括：
  • 匹配上下班司机与同向乘客（减少司机空转）；
  • 优先考虑在特定日期工作较少的司机（以提高司机对工作条件的满意度）

没有预先计划好的出租车时间表是可行的，因为以下任何不可预测的“破坏性事件”每 2 到 10 秒就会发生一次：

• 订单到达、更改或取消
• 驾驶员资料、状态或位置的变化
• 客户未出现
• 车辆故障
• 由于交通拥堵或在机场、火车站等地排队而造成的延误。

目的

重新安排多达 700 个独立实体在不可预测的条件下在伦敦旅行，每几秒就会发生变化，这是一项极其复杂的任务，使用任何已知的数学方法都不可行。

按照惯例，手动调度无法处理频繁的破坏性事件。 许多扰动，例如意外延误，不得不被人工调度员忽略。

因此，该项目的目标是提供有效的、实时的、自动化的协助，以适应推动日程安排的中断。 因此，该项目的目的变成了开发能够管理上述出租车运营复杂性的复杂自适应软件系统，目的是大幅提高：（1）运营盈利能力； (2) 客户服务质量； (3) 司机工作条件。

计划中的转变是从手动到半自动管理的出租车操作，以促进可选的人工调度员与复杂的自适应系统调度程序的交互。 对当代实践的深入分析表明，这种转变是前所未有的。 据项目团队所知，世界上任何地方都不存在出租车运营的实时调度程序。

挑战

为该客户开发新的实时调度程序的团队在设计和实施复杂的自适应软件方面拥有丰富的经验，因此预计不会遇到特别的挑战。 支持该系统的多智能体技术得到了团队的充分了解，并且制定了管理任务复杂性的方法（Rzevski 和 Skobelev，2014 年）。

系统工程实践

概述

出租车服务的复杂性排除了所有传统的系统工程实践。 客户出租车服务的实时自适应调度程序是使用多代理软件技术开发的。 在这里停止调度程序设计由以下主要组件组成（Rzevski 和 Skobelev，2014 年）：

1. 包含与客户出租车服务相关的领域有用信息的知识库
2. 模拟出租车服务的真实世界并能够管理其复杂性的多智能体虚拟世界
3. 虚拟世界和现实世界之间的通信通道，可以在有或没有人工干预的情况下对现实世界进行虚拟世界管理。

该系统的设计行为如下。 为应对每个中断事件，分配给每个收到的订单的订单代理和分配给每个工作司机的司机代理通过交换消息协商最合适的订单-司机匹配。 在开始协商之前，这些软件代理会查阅知识库以了解当前的协商规则。 一旦就最佳匹配（在普遍情况下）达成一致，结果就会传达给司机，他们可以自由接受或拒绝任务（Glaschenko et al. 2009）。 下图简单描述了这个过程。

在成功实现原型后，开发了复杂自适应调度器的基本版本，如下所述。

图 1. 出租车服务的事件驱动、实时、自适应调度的本质。 本材料经 G. Rzevski 和出版商 WitPress 许可复制。 所有其他权利均由版权所有者保留。

知识库

知识库包括： (1) 本体，包含作为语义网络的概念知识； (2) 标准数据库中的值。

基本本体包含两个对象类：订单和驱动程序。 订单属性为：

• 接送地点
• 接机（紧急或提前预订特定日期和时间）
• 服务类型（标准车、小型货车、贵宾等）
• 服务的重要性（从 0 到 100 的数字，取决于客户）
• 特殊要求（宠物、儿童椅等）

驱动属性是：

• 车辆类型
• 完成特殊工作的能力
• 驾驶员经验（新手或有经验）
• 司机住所
• 当前车辆位置（GPS坐标）
• 司机状态（不可用、休息、工作、空闲、5/10 分钟后免费、回家过境）

对象实例（个人订单和司机/车辆状态）的实际数据存储在客户的数据库中，包括场景（即出租车服务的瞬时模型，产生每个车辆位置和司机可用性）。

虚拟世界

在调度程序的基本版本中，将出租车分配给客户是通过分配给客户的 Order Agent 和分配给出租车司机的 Driver Agent 之间的协商完成的。 订单代理很活跃：他们编制了可用车辆的清单并开始与司机代理进行谈判。 在该系统的第一个版本中，驱动程序代理被设计为仅是响应式的：它们只回复来自订单代理的请求并实施订单代理选择的选项。

在后文描述的扩展版本中，订单代理和司机代理相互竞争或合作，这取决于对整个企业最有利的方式。 除了 Order 和 Driver Agents 之外，该版本还使用了一些新的代理类型，即：外部事件代理、区域加载代理和订单分配代理。

座席被设计为使用灵活的决策标准而不是直接的优先级，这在需要处理不同类别的客户时很有价值。 例如，如果一个 VIP 订单到达并且只有一个司机完全符合指定的要求，并且如果该司机已经分配到另一个工作，系统仍然会将 VIP 订单分配给该司机并启动重新安排如果需要，之前商定的匹配。

该系统首先试图最大化公司利润。 然后，考虑对业务很重要的其他标准，例如服务水平和驾驶员工作条件。 例如，当从两个大致相等的选项中进行选择时，系统将订单分配给了较长时间没有收到订单的司机，从而保证了订单的相对公平分配。

这种基于虚拟代理的调度系统旨在与人工调度员有效合作。 在一个调度员接到一个新订单并安排一辆车从北到南来接客户，而另一个调度员独立安排另一辆车从南到北去接另一个订单的情况下，虚拟座席可以发现这个调度异常并建议调度员改变他们的决定以提高效率。

为了提高性能，出租车分配系统在较短的周期内运行，而不是对每个事件都立即做出反应。 在周期之间，系统收集事件并将它们放入队列中。 在每个周期中，队列中的事件都被一个一个地处理，相应的代理又被指定的人类系统调度员控制。 因此，每个事件都会引发虚拟代理之间的一系列谈判。 当所有事件都处理完毕并且系统调度程序对为该周期生成了最佳调度感到满意时，调度扰动在现实世界中实现，系统进入休眠状态（空闲），直到有新事件到达导致启动下一个周期。

为了减小决策空间的维度，使用了预匹配机制，确定了 Order-Driver 匹配的适用性。 这种机制切断了没有希望的选择。

订单驱动程序对在做出最终决定之前进行了评估。 每个选项都有一个评价标记，好的选项会被记住，这样以后就不需要重复评价了。 评估分数是使用多标准模型确定的，并计算为所有标准值的总和乘以它们的（变量）权重。

以下标准用于评估选项：到订单的距离、预计接送延迟（如果有）、司机的偏好、司机的经验、司机到超载区域的距离（利用来自边远地区的司机）、服务等级一致性、订单的重要性和优先级、司机在队列中的位置（如果他在机场等候）、司机的家庭地址（如果他正在寻找往返家中的订单）。

调度工作流包括以下步骤：

1. 新订单到达并加入事件队列
2. 检查订单调度的可能性
3. 为订单分配了软件代理
4. 所有能完成此订单的司机都包含在预匹配中
5. 根据商定的标准对所有订单驱动程序对进行评估
6. 订单代理向选定的驱动程序代理请求订单完成成本。 此成本包括从先前分配的司机转移订单的成本（如果有）
7. Driver Agent 通过向其当前 Order Agent 发送请求来接收有关重新分配成本的信息
8. 如果修改后的决定比前一个更好，则应用它
9. 第 6 步继续适用于所有候选司机，他们的初始评估（无转移）优于当前评估
10. 如果在循环期间没有发生进一步的变化，则认为事件处理完成

为了获得可能的最佳解决方案，系统继续在先前商定的订单驱动程序匹配中寻找改进，直到它必须向驱动程序发出指令以完成订单的最后时刻（承诺时间）。 在此时间间隔内，驱动程序被认为可用于新分配，但前提是新分配改进了指定的性能指标。

必要时，司机代理试图就提议的重新分配订单相互“达成协议”。 有时，会向失去一位好客户的司机代理提供补偿，以提高业务的整体价值，尤其是司机代理的满意度。 很多时候，重新安排分配的资源会引发一波旨在解决新旧订单之间冲突的谈判。 重新调度链的长度仅受出租车到达伦敦等繁忙城市的客户所需时间的限制，这通常足以更改几次时间表。

总而言之，该系统建立了一个时间表并不断对其进行审查，只要仍有必要的重新安排时间，就试图提高关键绩效指标。

考虑到订单的优先级和服务类型以及一些其他参数，动态计算每个订单的承诺时间。 动态承诺时间的引入通过减少每位驾驶员的平均任务完成时间来提高车队效率。

系统引入了一个选项，可根据订单流预测分配车队。 有了有关当前订单流和过去订单分布的信息，就可以推断出预期的订单流，从而使系统能够生成通常合理正确的短期（30 分钟）预测。 根据预测，系统会向空置的司机发送短信，建议他们留在或搬到预计订单流量会增加的地区。 此功能改善了车队的分布，减少了响应时间和空闲里程，并增加了接机次数。

如果预测预计 VIP 订单到达距离建议司机聚集点很远的地方，系统会建议附近的司机靠近可能的订单点，为他/她提供保证以换取服从。 这是一个重要的功能，因为在没有超载的区域通常有足够的邻近司机来完成可用的订单，而超载区域的工作效率决定了实际的车队效率。 该系统还设计有一个选项，可以临时修改将订单分配给司机的标准（例如，

预测功能由基于代理的动态数据挖掘系统支持，该系统实际上是另一个与复杂自适应调度程序合作的复杂自适应系统。

在后来的版本中，该系统旨在检测和识别作弊的司机，即故意向调度员提供虚假信息以获取个人利益。 记录的案例包括尝试：

• 通过报告他们已经在机场排队等候来减少他们的最终等待时间，而实际上他们可能距离机场还有几十英里
• 通过在长时间作业开始时或附近指示“10 分钟内免费”来获得较早的下一个订单
• 通过在一天中多次表示“回家”来接收回家方向的命令。

为了减少作弊，司机代理被设计为监控司机的日程安排，并在被判断为不合适时忽略他们的信息。

复杂自适应出租车服务调度程序的最终版本仅与受中断事件影响的代理协商，然后仅修改受影响的部分时间表。 此功能是提高整体效率的关键功能。

连接虚拟世界和现实世界

虚拟世界是现实的模型，驻留在调度程序中，它与客户、调度员和司机的真实世界相连，如下所示。

当客户致电呼叫中心或访问网站下达、修改或取消订单时，调度员会将相关信息输入系统。 驾驶员使用 GPS、移动电话或专用手持设备与系统通信，传达有关其位置、行进方向、可用性等的信息，进而接收接载客户的指示。

得到教训

该系统于 2008 年 3 月开始运行和维护阶段，距项目开始仅 6 个月。

结果非常好：98.5% 的订单在没有调度员协助的情况下自动分配； 丢失订单的数量减少了 2%； 车辆空转数量减少了 22.5%。 每辆车每周能够完成两个额外的订单，花费相同的时间和消耗相同数量的燃料，这将每辆车的产量提高了 5-7%。

投资回收期为运营维护阶段开始后的2个月。 在运营的第一个月，车队的利用率提高了 5 – 7 %，这代表着每年高达 500 万美元的潜在额外收入。 这种实现的额外收入使公司和出租车司机都受益。 根据现有统计数据，自 2008 年以来，司机的工资增长了 9%，并且有可能整体车队增长。

延迟取件减少了 3 倍，显着改善了客户服务。 紧急订单平均响应时间（从预订到出租车接送到达）减少到 9 分钟，这是伦敦所有出租车服务中最好的时间。 对于高优先级订单，响应时间为 5 – 7 分钟或更短。 响应时间的减少在过载区域尤为明显。

执行“回家路上”指令，完善的分配机制，相比之前的系统，每天减少3-4000英里的车队运行，对司机和城市生态都有很大的好处。

以提高业务效率为目标的进一步发展可能包括分析车辆运动以确定实际车辆速度，这可以通过增加每个快递员的订单数量来改善快递员服务。

一家俄罗斯信息技术公司的成功业务转型

本文描述了一个成功的信息技术企业的业务转型。这个话题可能特别引人关注，尤其是因为这一转型是由一家俄罗斯公司在俄罗斯共和国快速增长的经济复苏期间完成的。

有关附加信息，请参阅与使能业务和企业以及企业系统工程密切相关的主题。

背景

2001年，位于莫斯科的IBS公司的最高管理层发起了一场根本性的变革，以改变公司的战略和商业模式。该公司是当时俄罗斯最大的信息技术(IT)系统集成商之一，拥有约900名员工。每年约8000万美元的收入主要来自信息技术(IT)基础设施项目(复杂计算系统、多服务网络等)和硬件和软件分销。公司的转型形成新功能的服务和相关的咨询领域是案例研究的主要话题。

在转型时期(2001年至今)，IBS被描述为一组自治的业务单元(BUs)，称为组成系统，它们是虚拟的、独立的业务，具有以下特征:

损益报告是每个部根据需要管理会计程序

BU管理层建立并独立执行人力资源、技术和产品政策

组织了一个集中的后台办公室，为每个BU提供支持功能。因此，BUs没有后台办公室;他们依赖公司治理中心(CGC)并“支付”这些服务。

一个彻底的企业系统(ES)转换作为一组活动来执行:任务分析和能力分解、业务架构、项目计划的规划，以及新业务模型的实现。

在转换之前和之后，IBS是一个典型的系统指导系统(sos):组成总线是自主的，但它们的操作由CGC监督。与此同时，IBS也具有公认的SoS的显著特征:组成BUs保留其独立的开发和维持方法，公司的变化基于CGC和每个组成部分之间的合作;甚至BUs的运营也不受CGC的控制，而只是通过“软”建议和协调进行监督/管理。

IBS在转型前是一个相当成熟的ES，它被彻底升级，形成了整个系统和组成部分的新能力。

目的

2000-2001年，IBS管理层预测，俄罗斯的IT服务和咨询市场将以快速增长的俄罗斯经济为基础，迅速从1998年的国家金融危机中恢复过来。最大的公司开始海外扩张，并从国际市场借款来为这种增长提供资金。IBS预测，业务流程及其相关软件和硬件系统的复杂性将相应增长，所有这些都需要更多的咨询和IT服务。

基于这一预测，管理层制定了一项战略目标:在一年内将IT服务和咨询的份额从25%翻倍到50%;这项业务的进一步增长被规划为一种长期趋势。

咨询和IT服务业务在技术上和组织上都非常复杂，与IBS以前关注的基础设施有很大不同。因此，一个根本的转变是必要的，并在2002年执行。

最初发现的问题出现在支出超过资源、项目交付缓慢和返工等方面。后来，正如预期的那样，新的问题出现了，比如BUs的管理者对开发新技术不感兴趣，或者对提高合格员工的积极性不感兴趣。这些问题在转型和进一步发展中都得到了解决。

转换的第一步包括战略分析和任务到能力的分解。定义了五个重点关注的主要能力组。组和每个组的范例功能在图1中表示。

图1。期望的任务和能力。(Belov 2014)泰勒和弗朗西斯，纽约，纽约转载。版权所有人保留所有其他权利。

挑战

所有主要的挑战都是由以下a、b和c三个因素所描述的知识/信息不足造成的。

a.缺乏企业转型的经验(以及基于能力的方法，甚至缺乏这些领域的任何教科书或指南)是IBS管理面临的主要挑战。要解决的任务没有下放到组织变化(这是一个发展良好和描述良好的领域)，而是适当地分配给企业系统或系统的系统(SoS)工程。尽管缺乏经验,决定准备和执行转换的基础上,公司的员工没有涉及外部顾问。以下论据支持这一决定。

要解决的任务不是典型的，所以没有被广泛使用和测试良好的算法或方法，也没有很多经验丰富的顾问确切需要什么。因此，只有具有一般经验(战略咨询、组织管理)的顾问才可能被聘用。

2001-2002年，俄罗斯的咨询业还不发达，所以只有外国专业人士。但外国顾问需要研究俄罗斯的具体情况;这种研究将不适当地延长转变的时间和增加费用。

必须组建一个联合转型团队，IBS员工必须参与其中:管理层必须接受采访，并参与决策。在任何情况下，所有员工都必须参与变更实现。

外部顾问不是利益相关者;所以他们帮助取得成功的兴趣水平可能不是很高，他们的输出也可能不是很出色。

不愿向直接竞争对手公开专业机密和其他知识产权问题是阻碍聘请外部顾问的其他因素。

因此，最终的决定是在没有外部咨询资源参与的情况下执行转型。建立了一个专门负责业务流程开发的业务ou，并采用了敏捷的项目管理方法来处理挑战、寻找机会以及降低风险。

b.作为企业系统或SoS的非常复杂的IBS。管理层认识到，公司及其环境非常复杂，有许多不同的代理人、许多组成部分和无数的关系;企业系统或SoS在转型后可能会变得更加复杂。这种复杂性发生公司变成了一个“扩展企业”,管理层次结构削弱,以及增加的需求更为复杂的关系。

c. IT市场发展预测错误的风险。咨询和服务市场的预期增长可能没有发生。在这种情况下，这种转变是毫无意义的。这一挑战产生额外的情绪压力管理。

系统工程实践

转换的SE任务以如下形式建立:为企业系统或SoS - IBS公司开发所需的能力。SE过程可以用以下具体的IBS对v (v)模型(“v模型”)的解释来表示，阶段1到7(图2)。

最初(第一阶段)将任务转化为能力(图1);执行了“理解组成系统(BUs)及其关系”。转换团队发现，功能可能不能直接转换到任何业务代理。总线(它们充当资源池)、项目(作为临时元素)、员工(他们每个人都有有限的技能、经验、责任等)可能都没有意识到必要的能力。

意识到这一点(阶段2)，转换团队定义了几个公司运营或活动的关键区域(图2)，这些应该被更改以形成新的能力。为每个领域开发并实现支持新功能的适当工件(过程、指南、文档、软件系统);这些新资产恰恰构成了新业务模式的公司基础设施。

图2。“V模型”对系统工程过程的改造。(Belov 2014)泰勒和弗朗西斯，纽约，纽约转载。版权所有人保留所有其他权利。

• 优先考虑并关注系统设计中最模糊的元素
• 在现实环境中进行试验和随后的推广
• 项目范围控制能力强
• 强有力的项目执行控制-时间进度和资源控制。

什么不起作用，为什么？

也许企业知识库开发是唯一或多或少严肃的任务，但在转型中没有解决。 公司管理层明白知识积累的用处，以及进一步疏远运营商在利用业务知识方面的作用，因此确立了发展自己的知识库的目标。 开发了带有适当指南、报告和数据收集表格的特殊数据库和软件系统； 但正式规定填写工程知识积累模板并没有奏效。 然而，这个问题后来进展得非常自然和简单：建立了公共文件夹来以自由格式存储项目数据。 这样的文件夹用于积累知识，但以扁平、非结构化的形式。

最佳实践和复制前景

以下方法和途径在转化中被证明是有效和方便的。

1. 可能建议将基于能力的开发方法和基于能力的架构用于创建和转换企业系统或 SoS。 这些将所有努力都集中在所需的能力上，并涉及系统工程过程中从任务到能力和功能的非常重要的关系。
2. 敏捷项目管理可用于解决 SE、ES 工程和 SoS 工程领域中各种不同规模的模糊和模棱两可问题，这些领域存在很多不确定性，缺乏专业知识和经过验证的方法或算法来解决这些问题。 “软”和非常有创意的设计与强大的计划和进度控制相结合是这种方法的关键基础。
3. 关键领域的定义和开发适合于为支持系统（核心咨询和服务技术、项目实施系统、业务单元增长系统、管理会计系统、激励系统）生成新功能。 精确定义这些领域并在这些领域开发集成系统可能被认为对于应用到更广泛的 ES 组来说是相当普遍的。

联邦调查局(FBI)虚拟案件档案系统

本案例研究展示了在2000-2005年间联邦调查局(FBI)虚拟案例文件(VCF)项目中遇到的系统和软件工程问题。在花费了超过1.7亿美元之后，VCF的开发于2005年被放弃。

背景域

FBI是美国司法部(DoJ)内的一个组织，由23个部门组成，包括反间谍、刑事调查和网络犯罪。局里有12400名特工，从反恐到绑架，无所不包。他们采访目击者，培养线人，进行监视，寻找线索，并与当地执法部门合作，寻找并逮捕罪犯。探员记录每一步，有条不紊地建立案件档案。他们花费大量时间处理文书工作。这种表格和批准系统可以追溯到20世纪20年代，当时该局所有调查报告的表格都已标准化。

在二年，本局有数百份标准化的纸质表格，而资讯科技系统已过时。联邦调查局的13000台电脑不能运行现代软件。大多数机构办公室都与联邦调查局的内部网相连，其连接速度约为每秒56千比特的调制解调器。特工不能给美国检察官、联邦机构、地方执法部门发送电子邮件，也不能互相发送电子邮件;相反，他们通常通过传真发送与案件相关的信息。该机构在2000年的问题在911委员会报告中得到了总结:“联邦调查局的信息系统严重不足。联邦调查局没有能力知道自己知道什么;没有有效的机制来获取或分享其机构知识”(2004年美国国家恐怖主义行为委员会)。

2000年9月，国会批准在三年内拨款3.8亿美元，用于当时被称为FBI信息技术升级计划的项目。该计划最终被分为三个部分，被称为“信息技术现代化三部曲计划”。第一部分将为所有56个FBI办事处提供更新的计算机终端,以及新的硬件如扫描仪、打印机和服务器。第二部分将重新实现FBI内部网，以提供安全的局域网和广域网，允许代理与他们的主管以及彼此共享信息。第三部分旨在取代FBI的调查软件应用程序，包括过时的自动案件支持(ACS)系统。

2001年6月，美国联邦调查局授予科学应用国际公司(SAIC)一份为期三年的合同，开发“三部曲”的调查软件应用。开发软件的目的是:

• 提供在事先不知道其位置的情况下在 FBI 数据库中查找信息的能力，并通过使用搜索引擎通过单个查询搜索所有 FBI 数据库；
• 启用现有调查应用程序的网络；
• 提高在 FBI 内外共享信息的能力；
• 提供对来自内部和外部数据库的授权信息的访问；
• 允许通过使用商业和 FBI 增强的分析和案件管理工具来评估案件和犯罪模式。

9 月 11 日恐怖袭击事件发生后，FBI 特工无法分享有关基地组织在美国活动的最基本信息成为头版新闻。 几天之内，联邦调查局过时的技术基础设施就在国会进行了讨论，联邦调查局面临着提高其信息共享能力的巨大压力。 2001 年 9 月 4 日，罗伯特·S·穆勒三世成为联邦调查局局长，面对强烈的公众和国会压力，穆勒加快了三部曲计划。 开发调查软件的计划三年期在政治上被认为是不可接受的。 2002 年 1 月，FBI 要求追加 7000 万美元来加速 Trilogy； 国会更进一步，批准了 7800 万美元。

为现有但过时且有限的 ACS 系统提供网络支持将无法提供满足 FBI 9 月 11 日后任务所需的调查案件管理能力。 2001 年 12 月，FBI 要求 SAIC 停止为旧程序构建基于 Web 的前端。 相反，SAIC 被要求设计一个新的案例管理系统，即虚拟案例文件 (VCF)，以取代 ACS。 VCF 将包含一个主要的新应用程序、数据库和图形用户界面。 为了使整个 FBI 都可以轻松访问犯罪和恐怖主义调查信息，需要对标准化的 FBI 流程进行重大更改。 本案例研究侧重于 Trilogy 计划的 VCF 组件。

案例研究背景

司法部监察长办公室(OIG)的报告对VCF的发展进行了最完整的描述。OIG向司法部长报告，独立于负责三部曲计划的FBI组织。报告的引言写道:“我们进行这次审计是为了评估FBI在满足三部曲的三个组成部分的成本、进度、技术和性能目标方面的进展情况。我们还研究了Trilogy将在多大程度上满足FBI当前和长期的IT需求”(OIG 2004)。

IEEE Spectrum的一篇文章对OIG的审计报告进行了补充，详细描述了VCF需求的发展、承包商的活动以及FBI和承包商的项目管理失败。承包商的观点是在美国参议院拨款委员会一个小组委员会的证词中提出的。

这些材料，总的来说，提供了一个全面的观点，VCF方案和其失败的原因。

案例研究说明

在911袭击之后的政治环境中，VCF项目的资金从来都不是问题。到2002年初，工商总局和联邦调查局承诺在22个月内建立一个全新的案件管理系统。尽管该项目遇到了各种问题，但高级别资助使其继续获得动力。VCF项目的日程安排集中在想要什么，而不是什么是可能的。三部曲的范围比最初的项目基线增长了大约80% (Moore 2010)。

VCF项目失败的原因与大量系统工程实践的不使用或误用有关，特别是在涉众需求、系统需求、计划、评估和控制以及风险管理中。考虑到9/11袭击之后的政治压力，进度被加速到开发人员几乎不可能遵循一个适当的系统工程过程的地步。

联邦调查局在四年时间里更换了五名首席信息官，大部分决定都是由委员会做出的。为了缩短时间，FBI甚至提议在周末使用一种叫做“闪切”的IT程序，将ACS替换为VCF。在这个提议的实现中，ACS系统将被脱机，并完全被VCF取代。一旦切换发生，即使VCF不能正常工作，也没有返回到ACS的机制。

SAIC在VCF的成本加奖励费用合同下工作，因为项目的范围在2002年初工作开始时还未确定。考虑到时间上的压力，FBI认为没有时间来开发正式的需求(术语表)，在不同的FBI用户社区中验证它们，然后估计开发VCF所需的成本和时间。上汽合同不需要特定的里程碑和完成成本加成合同允许范围增加。VCF是在完整性和正确性方面没有充分定义需求的情况。不断重新定义需求对已经设计和产生的需求产生了层叠效应。一旦有了可演示的软件，变更请求就开始到来——从2002年12月到2003年12月，大约有400个变更请求。

新的FBI内部网是在2001年指定的，在VCF项目开始之前，并且对信息共享导致的网络流量知之甚少。到2003年初，FBI开始意识到，一旦22,000名用户全部上网，网络流量将变得多么繁重。根据VCF完全运行时所需带宽的最佳猜测，对FBI Intranet的需求进行了修改。到2004年初，新的FBI内部网开始运作，尽管VCF软件还远未完成。

为了应对时间上的压力，上汽集团将VCF开发小组分成了8个团队，在不同的功能元素上并行工作。然而，这带来了许多集成的挑战，而且这八个线程后来被证明对SAIC来说很难合并成一个单一的系统。到VCF被取消的时候，SAIC已经基于一套不完整的需求开发了超过70万行软件，这些需求被记录在一个800页的卷中。

总结

OIG总结其结论如下:

各种原因占三部曲的延误和相关成本增加的项目,包括:

• 定义不佳且发展缓慢的设计需求，
• 收缩的弱点,
• IT投资管理的弱点，
• 缺乏企业架构
• 缺乏管理连续性和监督，
• 不现实的任务安排，
• 缺乏足够的项目集成，
• 我们之前在Trilogy. . . .上的报告中提出的问题没有得到充分的解决

根据政府问责局(GAO)的说法，企业架构是一组描述性模型，如图表和表格，在业务和技术术语中定义了组织今天如何运行，它打算如何在未来运行，以及它打算如何投资技术，以从今天的操作环境过渡到明天的. . . .

截至2005年初美国联邦调查局的操作仍然显著阻碍由于功能差、缺乏信息共享的能力当前IT系统。(2005年OIG)

2005年5月,美国联邦调查局局长穆勒宣布前哨,街舞,四年计划旨在满足VCF的目的,为美国提供一个基于web的情况和记录管理系统。在过去五年中，已经有了商业案例管理软件;因此，Sentinel打算利用商业现货(COTS)软件。OIG在2009年晚些时候的一份报告描述了哨兵和地位。《哨兵》于2012年7月1日面向所有员工上线，最终以4.51亿美元的价格结束，逾期两年半(Yost 2012)。