CTI论坛(ctiforum.com) （编译/老秦）： 协作解决方案过渡中有许多活动的部分。之前概述了顶级问题，并在这里解决了网络难题。在本文中，我将讨论过渡过程本身的步骤。
由于协作服务是用户日常工作不可或缺的一部分，因此，大型组织的过渡过程需要精心策划--使用新服务遇到的问题将立即引起挫败感。这直接影响服务的采用率，也影响过渡期。如果在过渡期间运行多个解决方案，这将增加IT团队和企业的复杂性和成本，从而降低ROI。目标是通过快速，平稳地将用户和房间移至新解决方案，从而最大程度地缩短实现价值的时间。
准备是关键。在进入Beta测试之前，请确保您具有运行所需的功能和支持结构，从而可以最大程度地降低用户影响。在进行Beta版测试之前，请确保这些物品经过全面的测试和实验室测试：
- 许可管理，包括用户许可和反许可，会议室许可以及管理不同的用户功能（例如，执行管理员支持，内容共享，网络研讨会功能等）
- 与所有计划解决方案中与之必要集成的公司协调呼叫计划和更新
- 针对每种情况（笔记本电脑，移动设备，房间，公司内部，公司外部，VPN内，VPN外，不同类型的笔记本电脑/移动电话等）启动呼叫
- 确保呼叫功能正常运行，包括查看模式，纯音频，内容共享，内容共享启动，电话拨入，全部静音。从每种设备类型和位置/网络方案进行测试，并测试通话质量。
- 此外，需要进行分析以跟踪用户对新服务的采用和用户成功/经验。
谁执行过渡，何时过渡？
在大多数IT情况下，我们会在不同时间转换组织内部的各个部分，从而扩展了服务新用户所需的大量支持。通常，协作解决方案无法做到这一点，因为旧方法和新方法不兼容。
调度是一个典型的例子。如果我们要使用解决方案A安排协作会议室，并且希望移至解决方案B，则必须将组织中的所有用户转移到同时使用解决方案B的位置。如果我们不这样做，用户可能会尝试在解决方案A和解决方案B上为相同的时间安排相同的会议室，这将成为双人预订。如果笔记本电脑或移动用户需要新的客户端来支持新的解决方案，则会遇到同样的挑战。协作解决方案的最大价值在于我们可以在整个组织中进行协作，因此隔离用户组与我们的目标背道而驰。
但是，从部署支持方法来看，先过渡到较小的组具有巨大的优势，既可以帮助管理支持负载，又可以使IT查找并解决出现的问题，而无需让整个用户组都遇到这些问题。在可能的情况下，我强烈建议转换一部分用户群或部分解决方案。
诸如调度平台，视频会议室和特殊用户组（例如，最高执行组）之类的解决方案的某些部分是独立过渡的候选对象。
如果视频室是独立于最终用户转换的，则需要一种临时方法将最终用户整合到包括会议室的会议中。如果新老供应商都可以轻松地支持此操作，或者您可以通过内部或受管服务供应商的视频网络运营中心（VNOC）来管理这些基于会议室的呼叫，则可以制定流程支持此拆分过渡。避免用户在调度或呼叫发起时必须做一些不同的事情的情况，因为我们不想训练他们两次。
同样，如果他们的电话是由VNOC或他们的执行管理员高度管理的，则可以分别调换执行人员。警告：两次培训执行管理员也不是您想要的。
完整的解决方案准备就绪后，最终用户可以作为一个组进行过渡。一些组织将拥有一部分用户，这些用户会在组内进行大量交流，这是由于业务结构或自然引起部门分化的地理或语言差异所致。我在众多组织中发现，拉丁美洲或南美的团队通常是视频协作的狂热用户，由于文化和语言的差异，它们往往会作为一个团队来运作。但是仍然存在不可忽视的跨组协作要求。
最终用户也可以进行有机过渡。一旦有了管理和计划解决方案，用户就可以通过注册过程或客户端下载来迁移到他们认为合适的新功能。如果该解决方案具有吸引力，尤其是如果管理层正在积极使用该服务，则用户将随着时间的推移相对较快地接受。排定的时间可能不如您的ROI所需的速度快，使用此方法可能会使旧解决方案退役的时间更长，但这将减少不想被不熟悉的解决方案的用户所困扰。
概念验证测试
概念验证（PoC）测试对于验证您选择的解决方案是否如广告所宣传的一样重要，而且对于确定企业中所需的关键变更以及这些变更的影响非常重要。测试之前，您不知道你不清楚的是什么。
验证供应商承诺的关键技术功能对你的组织来说是至关重要的。与您当前设备的兼容性，会议规模，日程安排方法，集成难度，管理界面，自动化和其他功能可能都是验证时很重要的。确定这些项目并制定测试计划以确保每个项目都经过测试。
作为此测试的一部分，请确定您的供应商对支持需求的响应速度。尝试与供应商的支持团队而非他们的技术销售团队互动，以便您可以体验服务团队的技能和响应能力。
跟踪使新解决方案生效所需的防火墙更改。PoC测试通常在实验室环境中完成，因此团队可以快速进行更改并使解决方案快速运行。在此实验室设置中，可能无法仔细跟踪防火墙的更改。使用可以捕获所需防火墙更改的所有详细信息的过程，以便可以与您的安全团队一起检查这些细节，以确保符合公司标准。
此外，在PoC跟踪过程中，关注服务的可用性，尤其是如果您正在测试提供商的新功能时。这些功能是否已准备好用于生产部署？
使用PoC可以识别企业流程中将需要的更改。考虑如何启用和许可用户和房间，如何将其与活动目录集成，将需要进行多少工作以及如何使该管理自动化。考虑如何进行使用情况跟踪，尤其是当您考虑在企业的部门或企业之间分担服务成本时。服务是否提供足够的详细信息来进行这些分配？
服务台支持如何？当用户无法安排，发起或参与呼叫时，用户将如何与您的团队或供应商的团队联系以获得所需的支持？您当前的服务台需要多少培训才能为他们提供支持用户所需的知识？您是否需要与供应商共享ticket，并且是否可以自动进行ticket共享？
Beta测试
Beta测试在两个重要方面不同于PoC。首先，使用生产防火墙在生产网络上进行Beta测试。其次，一定程度的扩展很重要，这意味着您需要为服务提供商和支持用户的周围流程提供足够的负载。这将确定它们在服务需求量增大时是否能够满足需求。
如果您尝试将用户从旧技术转移到新技术，则Beta测试可能会具有挑战性，因为系统之间可能不兼容。选择一个主要在该组内进行协作的组（例如，部门或具有共同语言的地理区域）。这将有助于最小化跨组协作需求，并使Beta团队获得成功。
在Beta测试期间，我们正在寻找PoC中未出现的问题，因为我们的规模不足。例如，笔记本电脑的电源不足或与新解决方案不兼容的旧版OS软件。耳机和免提电话是另一个面临集成挑战的领域，尤其是当用户在多个应用程序上使用他们的耳机并从一个切换到另一个时。房间系统的兼容性可能已在PoC期间进行了测试，但可能还有一些较旧的系统或未经测试的供卖方使用的系统仍在使用。团队中可能还存在一些用例或功能，但新解决方案中没有这些用例或功能，无法复制它们。而且还会有更多。如果我们能够预测它们全部，我们将在此阶段之前解决它们。此步骤是在将解决方案推广到整个公司之前，找出未解决的问题并解决它们。
在过渡过程中
随着过渡的进行，请了解您不了解的内容，并且过渡过程肯定会为您找到这些问题。知道会出现问题后，为用户和支持团队制定介入流程，因此可以及早发现问题并迅速解决。这种方法看起来很像一个敏捷的开发过程，需要频繁召开会议，确定问题，根据受影响的用户数量（或用户等级）确定优先级，并在下一个时间段内解决这些问题的分配（例如下一个24小时）。
分析是确保取得进展且问题不会拖延的关键。看板是一个有用的工具。使用此面板，您可以保留所有列出的主题，并确定哪些主题可以等待，哪些主题需要立即关注。将团队排在前25位的优先级通常意味着没有任务要完成，因此应对前三位进行处理，然后在第二天再进行研究。
使用相同的过程来确定每个期间内打开，关闭或未清算的ticket数量以及每个ticket已打开多长时间。随着时间的推移绘制此数据，并使用它来确定何时需要更多的支持资源，以及何时可以重新分配它们，因为随着系统的成熟和用户的适应，问题正在减少。并行跟踪用户的采用情况，以确保支持电话的减少与使用率的下降不匹配。
总结
计划周密且得到良好支持的过渡将收获按采用率衡量的大笔红利，提高员工的生产率，缩短实现价值的时间，缩短解决方案的ROI以及实现这一目标的积极IT团队的积极可见性。
声明：版权所有 非合作媒体谢绝转载
作者：约翰·巴特利特（John Barlett）
原文网址：https://www.nojitter.com/team-collaboration-tools-workspaces/keys-transitioning-cloud-service-effectively%20
