|
|
|
|
|
“静态”信息包括用于与公众交流有关服务的一系列工具，包括纸质小册子和时间表，在代理商网站上提供的PDF以及需要手动更新的网站。
|
|
|
|
|
|
|
|
|
|
|
|
在模板的帮助下，对于相当多的服务而言，手动创建材料通常是可行的。
|
|
|
|
pdf和静态网站不易被其他系统读取，无法包含在移动设备应用程序或服务的区域聚合中。
|
|
|
|
创建手册，PDF和静态网站的工具很容易获得。尽管在可读性和易于导航方面的最佳做法可能需要花费更多精力，但基本工具却易于掌握。
|
|
|
|
通常可以使用大多数代理商可以使用的技术（文字处理，桌面出版，Wordpress网站等）来制作材料。
|
|
|
|
|
|
|
|
软件和服务不依赖大量专业知识。需要时，培训材料通常是丰富且免费的。
|
|
|
|
|
|
|
|
这种方法包括创建一个可以在线查看的服务目录。结果在功能上类似于单个电子表格，其中每一行是一个服务，并且有一系列列描述该服务。如果服务列表很长，则可能会提供一些工具，以便用户可以根据其特定需求筛选服务列表。
|
|
|
|
|
|
|
|
|
|
|
|
具有正确过滤器并关注用户体验的联机目录可以扩展到列出数百种服务。需要注意的是，不要给用户太多无法消化的选择。
|
|
|
|
尽管目录条目可以出现在搜索引擎上，但其中的信息无法轻易集成到其他系统或应用程序中。
|
|
|
|
创建目录就像共享在线电子表格一样简单。对于诸如Wordpress之类的网站平台，可以使用许多目录插件。
|
|
|
|
因为已经存在许多用于构建目录的工具，所以基本成本可能非常低。与这种方法相关的大多数成本往往是非技术性的：收集数据，随着时间的推移保持准确性等。
|
|
|
|
在大多数情况下，用于建立目录的工具已经成熟，尽管需要注意目录所针对的人群的易用性。
|
|
|
|
目录通常不与日常操作紧密结合，也不特定于运输或人工服务运输。工作流挑战通常不在系统内，例如，确保目录的维护者收到任何列出的服务更改的通知。
|
|
|
|
|
|
|
|
这种方法涉及实施一个点对点的行程规划器，其中包括响应需求和专门的运输选项。与其他旅行计划器一样，用户可以输入其出发地和目的地，但除此之外，他们还可以输入资格因素，如老年人或残疾人。包括资格因素会产生一般公众无法获得的旅行选择，如ADA辅助客运系统或医疗运输服务。这些系统有时被称为“一次呼叫/一次点击”系统。
|
|
|
|
|
|
|
|
|
|
|
|
旅行计划者对其可伸缩性几乎没有技术限制。它们旨在在地区或州一级工作。对其部署的限制通常是对可以协调多少个利益相关者的制度约束的作用。
|
|
|
|
第一代包容性旅行计划者专注于直接向用户提供选项，而不是将其提供给其他软件系统。有关需求响应服务的信息以一次性数据格式存储，因此就平台可访问性而言，它们类似于联机目录。当前正在开发第二代旅行计划器，它将以标准化格式（GTFS-flex）存储此信息，这将提高多个系统使用同一数据集的能力。
|
|
|
|
2012年上线的第一批全包旅行计划者非常昂贵。自那时以来，成本已大大降低。但是，成功实施计划者需要付出巨大的努力-协调区域中的所有利益相关者，制定将所有提供商聚集在一起的营销计划，收集所有服务数据，并随着时间的推移保持系统的准确性和相关性。
|
|
|
|
现在工具已经更成熟了，成本也相对增加了。实施软件的费用约为25,000美元，托管和维护的软件费用每年也差不多。过去的项目表明，在动荡的技术和瞬息万变的移动技术世界中，协调和保持相关工具的成本比许多机构的计划要高。
|
|
|
|
这些系统所依赖的核心技术（Web应用程序框架，一个开源旅行计划者）现在已经成熟，并且不是项目风险的来源。风险最可能的来源来自于维护旅行计划器正在提供的协调服务网络的努力，以及在移动技术世界中普遍受到干扰的可能性。
|
|
|
|
尽管该软件是专门针对专用运输领域的，但它的重点是向公众展示选择方案，而不是在其运营中为代理商提供支持。更少地参与运营工作流程意味着更少的复杂性和更少的风险。
|
|
|
|
包容性旅行计划器正在逐渐普及，但是它们仍然是一个利基解决方案，因为许多地区没有机构能力来发展有助于这种系统成功的基本协调。
|
|
|
|
这类技术类似于包容性的旅行计划，但用户还可以预订他们刚刚制定的旅行计划，无需再打电话、发电子邮件或切换到其他网站填写旅行详细信息。
|
|
|
|
|
|
|
|
|
|
|
|
尽管这种技术类型的旅行计划器部分是可扩展的，但预订方面目前尚不可行，至少就目前而言，尚不具备将旅行计划者连接到许多不同机构的调度和调度系统的能力。这是因为还没有用于将预订请求发送到调度和调度系统的任何“即插即用”标准。每种集成都可能成本高昂，困难且相对危险。
|
|
|
|
预订外部系统的能力显着提高了此类技术的平台可访问性，并且可以为寻求访问移动服务的人员带来更加无缝的用户体验。
|
|
|
|
这种类型需要包容性旅行计划者进行所有工作，并且还必须在其自身与将接收预订请求的调度和派遣系统之间实现系统到系统的集成。
|
|
|
|
这种方法的预订方面的成本可能会相对较高，尽管这将取决于所集成的两个系统的具体情况以及诸如先前的集成是否已在另一个代理商处完成之类的事情。
|
|
|
|
目前，在两个独立系统之间发送预订请求仍不成熟。集成往往是一次性的，并且随着时间的推移可能难以维护，因为两个系统中的每一个都随时间独立发展。可以降低成本并显着提高成熟度的数据标准仍处于起步阶段。
|
|
|
|
因为这种类型的预订方面涉及调度和调度系统，所以可能与运输提供商的工作流程有关。示例包括但不限于：需要为这次旅行发送适当的资金来源，并且需要为何时由运输提供商正式“拥有”旅行做出清晰的设计。
|
|
|
|
作为移动即服务（MaaS）的普遍兴趣的一部分，人们对该方法越来越感兴趣，但是目前在美国这种融合的例子很少。
|
|
|
|
该平台完全集成了可通过应用程序使用的各种共享模式和提供商的计划，预订和付款。目标是创建一种无缝的服务结构，以使其易于使用，以至人们不再需要自己的汽车。
|
|
|
|
|
|
|
|
|
|
|
|
U-MaaS旨在在整个区域，多种模式和许多提供商中具有高度可扩展性。
|
|
|
|
作为技术最佳实践的集合，U-MaaS基于开放标准和系统到系统的界面，允许骑手应用程序，运输提供商系统和支付系统全部集成。
|
|
|
|
目前，U-MaaS很难完全实施。它不仅仅是现实，更是理想的模型和最佳实践集。在美国没有实现。
|
|
|
|
由于这种平台方法太新了，因此部署成本可能很高，而且只能在规模较大且组织严密的大都市范围内才能实现。
|
|
|
|
当前的MaaS平台目前仅在欧洲和亚洲运行。在美国进行首次实施时，需要吸取很多教训。
|
|
|
|
为了创建所需的无缝性，成功的U-MaaS平台将需要深入研究每种模式如何工作的复杂性，并将其连接到较大的系统，从而使系统整体上高度专业化。
|
|
|
|
MaaS在欧洲和亚洲都占有一席之地，统一支付之类的元素正开始占有一席之地，但在美国却没有受到关注。
|
|
|
|
|
|
这些用于运营的工具依赖于任何企业可以随时使用的工具-纸，笔，电子表格和电子邮件。没有专门的硬件或软件。
|
|
|
|
|
|
|
|
|
|
|
|
基于纸张和电子表格的系统通常随着车辆数量和报告要求的增长而扩展性很差。
|
|
|
|
纸张系统无法方便地用于外部数字平台，并且电子表格也存在重大障碍。
|
|
|
|
非常容易实现。所有工具和材料都可以在最近的办公用品店购买。
|
|
|
|
纸张系统的材料成本非常低，对于一家规模较小的代理商，人工成本也可能是合理的。随着需求超过系统容量，人工成本可能会快速增长。
|
|
|
|
成熟度在很大程度上取决于系统的设计方式。如果机构规模很小，经过深思熟虑的基于纸张或电子表格的系统可能会非常成熟。
|
|
|
|
由于它们在需要时易于理解和调整，因此基于纸张和电子表格的系统的工作流程依赖性较低。
|
|
|
|
尽管纸系统不太可能完全消失，但随着小型机构使用廉价的软件即服务应用程序，其使用量正在下降。
|
|
|
|
安装在机构工作站和服务器上的独立系统，如调度和调度以及资产管理应用程序。这些系统与外部系统（如车内远程信息处理）的连接很少或很难实现。
|
|
|
|
|
|
|
|
|
|
|
|
这种类型的系统经过精确设计，可以使机构进行扩展以管理大量的客户，行程，驾驶员或资产。
|
|
|
|
这类系统的致命弱点是无法利用外部系统和数据。这使其成为协调方案的障碍。
|
|
|
|
实施工作随应用程序的不同而不同，但是这些专用系统通常需要进行安装，培训和集成到组织工作流中的工作。计划和派遣系统特别需要整个机构的人员培训。
|
|
|
|
成本随应用程序及其功能的不同而有很大差异，但是作为一种相对成熟的利基解决方案，它具有一定的市场竞争能力，可以控制成本。
|
|
|
|
基于桌面的系统已经使用了很多年，在某些情况下已经使用了数十年，因此具有很高的成熟度。
|
|
|
|
调度和分派系统以及资产管理解决方案是高度专业化的，对机构的工作流程具有很高的影响。应认真注意这些系统的设计，以确保它们符合工程处的业务和战略方向。
|
|
|
|
所有类型的基于桌面的系统都在迅速下降。他们正被基于Web的SaaS系统迅速取代。探索基于台式机或本地服务器的系统的机构也应注意评估SaaS选项。
|
|
|
|
这种类型的技术解决方案涉及使用一个供应商来实现广泛的核心代理功能，例如跨多种模式的调度和分派（例如，固定路线和需求响应服务）、资产管理、司机管理、报告等。
|
|
|
|
|
|
|
|
|
|
|
|
这种类型的系统经过精确设计，可以使代理机构进行扩展以管理大量的客户，行程，驾驶员或资产。假设每个模块都非常适合该机构的需求，那么为其他功能添加“模块”的能力可以进一步增加其可伸缩性。
|
|
|
|
由于供应商鼓励其客户购买其自己的“模块”以满足任何技术需求，而不是支持与竞争性供应商的集成，因此这些系统往往会遇到平台可访问性落后的问题。这会使代理机构内部或机构之间的系统集成非常困难。
|
|
|
|
实施工作随应用程序的不同而不同，但是这些专用系统通常需要进行安装，培训和集成到组织工作流中的工作。计划和派遣系统特别需要整个机构的人员培训。
|
|
|
|
成本随应用程序及其功能的不同而有很大的差异，但是作为一种相对成熟的利基产品，它具有一定的市场竞争能力，可以控制成本。应当特别注意总拥有成本，在这种情况下，与单个供应商合作的较低管理和培训成本可能会因供应商锁定而被较高的许可成本所抵消。
|
|
|
|
这些解决方案可以由已经从事该行业很长时间的大型供应商提供，因此成熟度往往很高。“全合一”解决方案外围组件的成熟度可能会由于核心组件的更新或获得的公司资源减少而明显不那么成熟。
|
|
|
|
调度和调度系统以及资产管理解决方案是高度专业化的，并且对代理工作流具有很大的影响。应认真注意这些系统的设计，以确保它们与代理机构的运营和战略方向保持一致。
|
|
|
|
“一体式”解决方案在行业中已经站稳了脚跟，并且在最近几年中一直保持稳定。随着数据标准的成熟和不同供应商之间互操作性的提高，它们的主导地位可能会下降，但这尚未发生。
|
|
|
|
这种技术解决方案涉及使用专注于一个领域（例如调度和分派或资产管理）的SaaS解决方案。
|
|
|
|
|
|
|
|
|
|
|
|
这种类型的系统经过精确设计，可以使代理机构进行扩展以管理大量的客户，行程，驾驶员或资产。由于系统是针对单个问题空间而专门设计的，因此它们很难轻松扩展以解决代理商在另一个领域的问题。例如，专注于提供SaaS资产管理解决方案的供应商将无法帮助调度和分派。
|
|
|
|
与现有供应商相比，这些解决方案的供应商往往对市场较新，更愿意提供与第三方系统集成的工具，这既是因为它可以给他们带来竞争优势，也是因为他们使用的基础技术较新，使这样的努力容易得多。然而，由于这个行业的标准太少，而且对于什么才算是足够的互操作性水平没有明确的期望，所以每个机构都需要确定它们在系统之间需要什么样的可访问性，并深入研究给定供应商是否提供了这种可访问性的细节。
|
|
|
|
实施工作随应用程序的不同而不同，但是这些专用系统通常需要进行安装，培训和集成到组织工作流中的工作。计划和派遣系统特别需要整个机构的人员培训。因为它们是基于Web的并且由供应商托管，所以与较早的基于桌面的系统相比，设置和安装的大部分麻烦可以忽略不计。
|
|
|
|
每个应用程序及其功能的成本差异很大，但是专用SaaS解决方案的成本往往比前几代内部部署和多合一解决方案的成本更低（有时甚至更低）。
|
|
|
|
这些解决方案可能不如现有供应商通过旧版软件开发平台提供的解决方案成熟。但是，它们正在迅速赶上，并且还提供了老一代技术无法使用的新功能，尤其是在集成实时数据和加快软件更新速度方面。
|
|
|
|
调度和调度系统以及资产管理解决方案是高度专业化的，并且对代理工作流具有很大的影响。应仔细注意这些系统的设计，以确保它们与代理机构的运营和战略方向保持一致。
|
|
|
|
由于与上一代技术相比，其建立成本和工作成本可以低得多，因此，此类解决方案的使用呈爆炸式增长。
|
|
|
|
面向服务的体系结构涉及使用大量应用程序，每个应用程序都具有有限的特定功能，可以通过明确定义和标准化的API与其他应用程序很好地集成。随着需求的变化或新的供应商提供更好的解决方案，可以在不增加成本或停机的情况下将应用程序替换掉。
|
|
|
|
|
|
|
|
|
|
|
|
这种方法通过模块化支持可伸缩性。通过允许机构更改其技术足迹的各个部分而无需立即全面检查所有内容，增长和变化可以逐步发生，从而改善整个系统的可持续性。
|
|
|
|
这种模块化方法也许是平台可访问性的最好表达：具有将各种系统连接在一起的能力，因为每个系统都是从头开始设计的，可以向外部系统发送数据并从外部系统接受数据。
|
|
|
|
目前，由于缺乏数据标准和供应商支持，此方法仅在有限的情况下可行。
|
|
|
|
一旦支持这种方法的软件和硬件系统可用，成本就可能与现在的成本相似，但转移到不同的工作上。每个模块化应用程序的成本都将降低，但是随着管理它们之间交互的额外成本，它们中的成本将会更高。系统集成商的成本，无论是外部供应商还是内部人员，都需要考虑在内。
|
|
|
|
当前，这种方法正在增长，但在每个供应商和每个细分领域都偶然发生。目前，机构必须认真设计其系统，以使这种方法有效。
|
|
|
|
调度和调度系统以及资产管理解决方案是高度专业化的，并且对代理工作流具有很大的影响。应认真注意这些系统的设计，以确保它们与代理机构的运营和战略方向保持一致。
|
|
|
|
面向服务的体系结构在更大的软件世界中正变得占主导地位，因此这种趋势逐渐扩展到传输技术中。目前步伐缓慢。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
甚至美国最大的公交系统都允许现金支付，但是现金管理的成本是巨大的，并且随着使用量的增长呈线性增长。
|
|
|
|
|
|
|
|
这项工作涉及建立必要的财务系统来收集，记录和存放所收集的票价。
|
|
|
|
成本包括购买实物票箱，打印和分发纸质机票以及管理所收取的票价。对于许多小型系统而言，将这些系统安装到位的努力非常重要，以至于许多小型提供商更喜欢无票价系统的简单性。
|
|
|
|
|
|
|
|
现金和纸质票务系统的工具在各个代理商之间并没有太大差异。
|
|
|
|
出于公平和获取的原因，现金在美国通常还没有被取消为付款方式。目前，它的逐步下降是无票价系统的最新趋势的结果。
|
|
|
|
独立的电子票价系统，其中所购买的价值存储在票价工具本身中。如果票价工具丢失，存储在其上的值也将丢失。
|
|
|
|
|
|
|
|
|
|
|
|
这些电子票价系统主要是在具有轻轨或地铁模式的大型公交系统中实施的，因此可以按比例缩放到非常大的规模。
|
|
|
|
这些系统被设计为封闭的。通常只能通过公交车站的售货亭向卡上充值，并且这些卡不能轻易地用于操作系统之外的一个公交机构以外的其他任何方式的付款。
|
|
|
|
第一代系统的安装成本很高，在站，公共汽车和后勤部门花费了大量的硬件资源。
|
|
|
|
作为为大型运输系统设计的系统，对于小型机构而言，成本通常过高。
|
|
|
|
为这些系统的工具和技术进行了大量的设计投入。他们达到了高度的成熟度。
|
|
|
|
尽管系统之间存在相似之处，但是由于它们如此之大，因此每个实现都需要进行大量的定制。
|
|
|
|
卡上存储了价值的系统正在全国范围内被替换，而不是基于当前基于帐户的系统。
|
|
|
|
独立的电子票价系统，其中所购买的价值与用户帐户相关联。如果票价工具丢失，则可以将帐户与新帐户关联。
|
|
|
|
|
|
|
|
|
|
|
|
这些系统可以在较小的机构以及非常大的机构中轻松实现。
|
|
|
|
尽管它们可以在第一代系统上进行重大改进，因为可以在线或通过应用程序加载价值，但系统不同部分（应用程序，车辆硬件和后台系统）之间的连接都是专有的，这限制了集成能力与其他系统，例如自行车共享系统。
|
|
|
|
确定所需工作量的主要因素是是否将有车载硬件来读取票价工具。某些系统依靠智能手机应用程序来解决该问题，该应用程序可显示驾驶员查看的图像。
|
|
|
|
成本可能非常低，有时甚至低于正式采购的门槛。在某些情况下，卖方将承担最初实施的大部分成本，以换取全部票价收入的一定百分比。
|
|
|
|
这些系统现在已经足够成熟，可以在单个机构内实施相对较低的风险。尚未开发的数据标准将允许独立的票价系统无缝集成到骑手身上。如果两个相邻的代理机构希望使乘车人轻松使用任一系统的票价工具付款，那么当前这将需要两个代理机构与同一电子票价供应商签约。
|
|
|
|
与前几代人相比，当前的电子票价系统的设计使其更易于实施。当代理商需要供应商提供支持的独特票价规则时，将应用专业化。
|
|
|
|
由于它们相对容易并且实现成本低，这种类型的技术正在整个行业中迅速扩展。
|
|
|
|
电子票价系统，其中所购买的价值与用户帐户相关联。如果票价工具丢失，则可以将帐户与新帐户关联。多个代理和模式可以通过一组定义的应用程序编程接口（API）参与单个系统。
|
|
|
|
|
|
|
|
|
|
|
|
这些系统可以在较小的机构以及非常大的机构中轻松实现。
|
|
|
|
基于API的系统提供了高水平的平台可访问性，为电子票价系统打开了大门，该票价系统可用作通用的“交通钱包”，以支付交通，自行车共享，出租车和其他共享方式的费用。
|
|
|
|
确定所需工作量的主要因素是是否将有车载硬件来读取票价工具。某些系统依靠智能手机应用程序来解决该问题，该应用程序可显示驾驶员查看的图像。尽管这种技术可能与除运输之外的其他模式集成，但要实现该集成还需要付出大量努力。
|
|
|
|
成本可能非常低，有时甚至低于正式采购的门槛。在某些情况下，卖方将承担最初实施的大部分成本，以换取全部票价收入的一定百分比。尽管这种技术可以与除运输以外的其他模式进行集成，但它仍然是新事物，而且实施起来可能成本很高。
|
|
|
|
这些系统现在已经足够成熟，可以在单个机构内实施相对较低的风险。但是，对于创建多机构和多模式集成，还处于初期。
|
|
|
|
与前几代人相比，当前的电子票价系统的设计使其更易于实施。尽管如此，目前运输机构和不同模式之间的整合将高度专业化和试验性。
|
|
|
|
许多较大的机构正在开发这种集成方法。较小的代理商选择成本和风险较低的独立专有基于帐户的系统。
|
|
|
|
基于开放标准的支付系统，可为骑手提供非常高度的无缝性。此类系统是增强移动即服务（MaaS）平台的核心要素。
|
|
|
|
|
|
|
|
|
|
|
|
此方法旨在实现非常高的可扩展性，达到区域，州甚至全国的水平。
|
|
|
|
平台可访问性很高。通过数据标准，任何数量的运输提供商都可以“插入”系统。
|
|
|
|
这样的开放系统将依赖尚不存在的数据标准。因此，实施的便利性很高。
|
|
|
|
在开发成熟的数据标准并被大量参与者接受之前，开发成本将很高。
|
|
|
|
|
|
|
|
完全开放的系统将如何依赖代理工作流还有待观察。就目前而言，应该假设其依赖性很高。
|
|
|
|
已经提出了基于标准的开放式支付系统，但是还没有标准能够胜出。
|
|
|
|
|
|
驾驶员和调度员之间使用电话或模拟无线电进行基本通信。
|
|
|
|
|
|
|
|
|
|
|
|
对于较小的操作，收音机和电话可提供足够的连接性。随着车队规模的扩大，管理可能会变得痛苦。
|
|
|
|
这种技术允许驾驶员和调度员进行通信，但不涉及计算机系统。
|
|
|
|
使用易于发现的设备非常容易部署。收音机可能需要在办公室安装基础设施。
|
|
|
|
成本通常较低，不过随着车队的增长，手机费用会迅速增加。
|
|
|
|
|
|
|
|
|
|
|
|
在许多运输环境中，收音机和电话一直是非常有用的工具。
|
|
|
|
这种技术使调度员可以使用安装在车辆中的廉价硬件（有时称为“加密狗”），标准单元网络和价格合理的软件即服务系统来了解车辆的位置。通常称为“telematics远程通信”。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
许多远程信息处理供应商使其他服务可以轻松捕获设备的GPS数据。这样就可以实现以下情况：调度，实时乘员信息系统和车队管理都可以从单个设备访问数据。
|
|
|
|
|
|
|
|
设备成本往往较低。随着时间的推移，每月蜂窝网络成本可能是最大的单笔支出。
|
|
|
|
|
|
|
|
没有高度专业化。运输公司通常可以使用送货和物流公司使用的相同系统。
|
|
|
|
|
|
|
|
这种方法涉及到专门构建的硬件（移动数据终端，或MDTs），预先安装了专门的单用途固件，仅适用于特定的调度和调度软件。
|
|
|
|
|
|
|
|
|
|
|
|
这种类型的系统经过精确设计，可以使机构进行扩展以管理大量的行程，车辆，驾驶员或资产。它们的局限性在于它们无法加载其他应用程序。
|
|
|
|
有限的可访问性。尽管它们确实增加了有关驾驶员和车辆的实时信息的访问权限，但MDT往往被锁定，仅支持与单个专有调度和调度系统的通信。
|
|
|
|
主要工作是采购和安装硬件。部署MDT连接到的调度和调度软件将是一项单独的工作，而且可能需要大量工作。
|
|
|
|
坚固的MDT可能很昂贵，尽管随着时间的流逝，每月的蜂窝网络成本可能是最大的一笔支出。
|
|
|
|
尽管驱动程序的软件和用户界面通常不是很友好，但是硬件本身往往是可靠和成熟的。
|
|
|
|
MDT是包含调度和调度软件的较大系统的一部分。更大的系统高度专业化，并且与代理商的日常运作紧密相关。应注意确保大型系统适合您机构的工作方式。
|
|
|
|
|
|
|
|
这种方法涉及消费级或加固型平板电脑，其中装有必要的应用程序，以提供计算机辅助调度（CAD），自动车辆定位（AVL）跟踪以及与驾驶员进行消息传递。
|
|
|
|
|
|
|
|
|
|
|
|
这种类型的系统经过精确设计，可以使机构进行扩展以管理大量的行程，车辆，驾驶员或资产。它们能够加载各种应用程序的灵活性提高了可伸缩性。
|
|
|
|
|
|
|
|
主要工作是采购和安装硬件。部署MDT连接到的调度和调度软件将是一项单独的工作，而且可能需要大量工作。
|
|
|
|
成本可能会因所使用的硬件类型而异。预算应包括发生设备故障时要更换的设备，以及随着时间的推移使操作系统和应用程序保持最新状态的成本。
|
|
|
|
尽管应用程序和底层操作系统可能会迅速发展，但平板电脑通常已经成熟，需要额外的精力来保持最新状态。
|
|
|
|
平板电脑及其面向驾驶员的应用程序是包含调度和调度软件的大型系统的一部分。更大的系统高度专业化，并且与代理商的日常运作紧密相关。应注意确保大型系统适合您机构的工作方式。
|
|
|
|
|
|
|
|
这种方法涉及将总线上的所有数字技术视为一个系统。根据需要共享网络连接和GPS信号。
|
|
|
|
|
|
|
|
|
|
|
|
这种方法具有很高的可扩展性，既可以与任何规模的车队一起使用，又可以容纳车辆上越来越多的设备。
|
|
|
|
车载平台通过使任何设备都可以轻松实现网络和GPS连接，同时减少每个系统具有自己独立连接所带来的额外成本，从而支持平台可访问性。
|
|
|
|
目前，目前很少有将车辆技术连接在一起的标准，因此要想实现这一愿景，可能需要进行仔细的工程设计。
|
|
|
|
尽管在总线上集成不同系统可能会遇到挑战，但从长远来看，如果该机构要拥有许多都需要网络连接的系统，则可以降低成本。
|
|
|
|
当前，很少有将车辆技术连接在一起的标准，从而使这一构想目前还不成熟。
|
|
|
|
许多系统的集成可能会增加复杂性，并需要具有专门的配置。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
高度手动的系统的伸缩性较差，但是它们可能是检验概念证明的绝佳方法。
|
|
|
|
电子邮件，传真等不提供与其他数字系统集成所需的接口。
|
|
|
|
|
|
|
|
至少在工具方面，手动协调的成本很低。员工时间可能很长。
|
|
|
|
|
|
|
|
许多系统的集成可能会增加复杂性，并需要具有专门的配置。
|
|
|
|
|
|
|
|
这种方法使用了不是为运输设计的通用协作技术，或者不是为协调设计的专用运输技术。示例包括Google表格以及计划和调度软件。
|
|
|
|
|
|
|
|
|
|
|
|
如果仔细应用，这些系统可能会比手动协调有显着改进，即使它们可能涉及许多变通办法。
|
|
|
|
某些方法（例如Google表格）可能会与其他系统提供有限的互操作性。但是，在大多数情况下，可访问性将受到限制。
|
|
|
|
|
|
|
|
|
|
|
|
作为一种临时方法，成熟度会很低。计划大量时间来解决纠结和完善解决方法。
|
|
|
|
|
|
|
|
临时系统通常是启动协调工作的唯一方法，因此将继续存在。
|
|
|
|
这种操作协调方法涉及定制集成软件，以连接来自不同供应商的不同系统。
|
|
|
|
|
|
|
|
|
|
|
|
精心设计的自定义集成可能会使一种特定的协调方案更加有效。但是，这种安排可能是脆弱的，不能复制到任何其他机构或情况。
|
|
|
|
|
|
|
|
作为一次性的工作，随着时间的流逝，将需要相当大的努力来进行设计，测试和维护。
|
|
|
|
尽管成本会随项目范围的变化而变化，但是定制开发的需求可能会使成本较高。
|
|
|
|
作为一种临时方法，成熟度会很低。计划大量时间来解决纠结和完善解决方法。
|
|
|
|
|
|
|
|
为了协调目的而连接系统有时会发生，但这并不是一个广泛的趋势。
|
|
|
|
通过对所有参与机构使用单个供应商和旨在支持每个协调伙伴之间的数据交换的软件系统，这种操作协调方法可以起作用。
|
|
|
|
|
|
|
|
|
|
|
|
假设软件解决方案对所有参与机构都足够有效，则可以提供更大的可伸缩性。应认真注意每个参与者的需求，以确保该解决方案适用于所有人。
|
|
|
|
可访问性取决于软件的设计。有些计划是封闭的系统，这使得使用其他系统的任何机构都难以参与协调事业。
|
|
|
|
操作协调往往难以实现。与单个供应商合作可以减少障碍。
|
|
|
|
尽管成本会随项目范围的变化而变化，但与定制设计相比，无需进行软件开发可能会降低成本。
|
|
|
|
|
|
|
|
|
|
|
|
随着多家供应商销售用于协调的系统，这种方法正在发展。
|
|
|
|
这种方法不仅使每个提供商都有自己的操作系统，而且还可以通过所有供应商采用的标准接口与其他提供商进行协调。
|
|
|
|
|
|
|
|
|
|
|
|
通过允许许多不同的机构加入协作，基于标准的方法具有高度的可扩展性。
|
|
|
|
开放的接口使与平台连接并参与移动即服务计划成为可能。
|
|
|
|
当前缺乏成熟的交易数据标准意味着任何实施都将是同类实施中的第一种，除了需要进行一般操作协调的高水平工作外，还需要额外的技术努力。
|
|
|
|
尽早采用这种方法的成本可能很高。增量项目方法将有助于降低风险。
|
|
|
|
由于数据标准尚未完全成熟，因此这种方法的成熟度很低。
|
|
|
|
|
|
|
|
这种方法尚未起步，但是，如果要将人类服务运输作为服务方案纳入移动性，这将是必要的发展。
|
