本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
运营工作流
运营工作流支持技术基础和用户历程工作流。大多数对整体迁移成功至关重要的非技术活动都是该工作流的一部分。
此工作流程涉及的决策可以轻松进行更改或撤销，且不会造成任何影响。基于人们工作和参与方式的产品的规格很少能一遍通过——有许多利益相关者和意见需要考虑。尽早参与并经常进行广泛咨询是非常重要的，因此，敏捷和迭代的方法对于这个工作流来说是很有意义的。您可以从运营模型或培训材料的早期草稿开始，然后频繁而快速地进行迭代以获得最终产品。
运营工作流包括五个阶段：项目治理、一致性、运营模式定义、服务介绍和培训。
项目治理
项目治理活动贯穿迁移项目的整个时间表。无论项目处于哪个阶段，活动都应定期（定期举行会议）、透明（让项目团队有机会坦率地提出风险和问题），并具有参与性地进行治理（领导者有权并愿意做出相应的决策或升级）。这些对于迅速有效地突出和解决问题至关重要。
一致性
这是该项目的第一项正式活动，重点是使项目范围与业务成果保持一致。一致性基于与相关利益者的讨论，提供了验证和调整早期计划和估算的机会。
本次活动期间的关键行动包括：
-
了解高级客户使用案例、当前的技术和业务痛点，以及改进的机会。
-
讨论并商定预期的业务成果，确定其相对优先级，并确定成功标准。
-
开发高级解决方案设计，用于定义早期阶段的范围和技术选择。这种高级设计为加快后期阶段的低级设计活动提供了指导。
-
验证时间表和实施成本。
运营模式定义
此阶段的活动定义了谁将使用联络中心解决方案以及解决方案将如何得到管理。运营模型不是程序文档、运行手册或配置文件。例如，它不应解释如何推送日志并将其附加到支持票证中，也不应提供此过程的屏幕截图。相反，它应该确定谁应推送日志，以及应该将日志发送给哪个队列或供应商。
运营模式的定义应包括：
-
责任、问责、支持、咨询和知情（RASCI）矩阵，以便各个团队了解自己的角色和职责，以及他们将如何与其他团队互动。下面是来自一个 RASCI 矩阵的摘录：
-
流程泳道，用于定义 end-to-end活动以及谁负责每项活动。例如，应该有一个吸引 out-of-hours支持人员的流程，这样就可以清楚地知道谁会收到呼叫，如果无法联系到他们会发生什么，谁记录了支持请求单，以及如何判断业务重要性。另一个例子是紧急排队消息。流程应展示出谁可以决定需要启动流程，以及应该使用哪些数据来做出决定。
运营模式通常是在项目的后半部分定义的，因为您必须先完成解决方案设计和用户历程，然后才能定义流程以对其进行准确管理。但是，我们建议您在流程的早期阶段就组织好利益相关者，并将他们的时间留给项目的后期阶段。
收集组织中可用作模板的类似文档的示例。这将便于利益相关者进行审查和签署，因为他们熟悉文件结构。
确保您的利益相关者在新联络中心进入生产阶段之前签署运营模式，并使其成为您决定发布的必要条件。每个团队成员都需要了解自己的角色以及在生产环境中运营联络中心的流程。
服务介绍（SI）
通过 SI 活动实施在运营模式中定义的更改。将运营模型的定义视为新模型的设计和构建阶段，将 SI 视为运营模型的部署阶段。
SI 团队通常是组织中的一个专属团队，独立于项目团队工作。项目必须通过 SI 团队的标准和清单，然后才能获得发布批准。例如，清单包括用户验收测试（UAT）结果、确认冲突事件（例如变革冻结，或有其他预定的发布活动）不会与项目发布同时发生、确认用户接受了必要的培训，以及确认运营团队已准备好继续进行。
不要将 SI 活动留到项目末尾。在项目初期就让 SI 团队参与进来，并将他们列入设计文档的分发列表中。尽早参与可确保 SI 团队能够协助准备上线，例如帮助选择最合适的AWS 支持计划
训练
创建培训材料和举办参与度足够高的培训课程对于成功迁移至关重要。若技术可以完美运行，但是如果用户却不知道如何接听呼叫和执行日常任务，则迁移将被视为失败。
培训活动可能包括直接用户培训、培训师培训、主管培训、支持人员培训以及系统管理员或产品所有者培训。每个组织都是独一无二的，因此有些选择可能在组织文化方面更胜一筹。
我们推荐覆盖贵组织内部培训人员的培训师培训方法。您的员工了解贵组织的文化，以及最适合您的用户的培训形式和技巧。项目团队成员可以担任主题专家（SME）角色，提供技术材料（例如用户手册、管理员控制台手册和屏幕指南），这些材料可用作培训师课程的源材料。如果您的组织没有培训团队，则项目 SMEs 应培训主管和首席支持人员，然后他们可以培训联络中心的用户。
我们还建议系统管理员和产品所有者参加由讲师指导的正式产品培训课程，以更深入地了解 AWS 环境和 Amazon Connect 控制台，以便他们可以有效地使用产品功能并进行故障排除。
