概览

变更管理流程向导的目标是供那些已经建立了某种变更管理流程,并需要对 Zendesk Support 进行高级定制(配置,而不是自定义)的组织使用。

第 1 步。您希望在更改发生之前收集哪些信息?

首先,确定您需要收集的关于更改的信息类型,以评估更改的风险、影响和实施计划以供批准。

考虑:

    • 更改是否针对特定的技术堆栈?
    • 进行此更改的业务理由是什么?
    • 谁在实施更改?
    • 是否需要中断?
    • 中断持续时间是多少?
    • 谁会受到更改的影响?(业务部门? 全局区域? 网站?)
    • 更改是否需要在某个日期和时间之前完成?
    • 更改是否需要等到某个日期和时间才能实施?
    • 需要进行什么类型的更改?(标准?次要?少校?紧急?)

仅选择实际有助于决定是否应推进更改、有助于推动沟通,或有助于报告具有相关操作计划的特定指标的字段。 人们总是希望尽可能多地跟踪关于更改的信息,但要切合实际。 当您实际需要的变更管理流程往往非常简单时,这很容易过火。

这样做:

对于您要捕获的每条信息, 创建一个新的工单字段 。


第 2 步。谁参与了您的 CAB/批准流程?

接下来,识别需要参与批准更改请求的所有人员组。

考虑:

    • 你们有正式的变革咨询委员会吗?
    • 在实施更改之前,您是否需要获得企业批准?
    • 谁(如果有人)需要批准特定于技术的更改?
同样,需要审阅和批准更改的组越少越好。 过于简单了。 更改请求者更有可能遵循精简且有目的的流程。

这样做:

对于已识别的每个组, 创建一个新组 。 接下来,将所有潜在的批准者(应是具有专员用户角色的 Zendesk 用户)添加到其各自的组中。


第 3 步。您的批准流程是什么?

现在是考虑批准流程的时候了。

最好先创建一个下拉字段,跟踪更改的总体批准状态。 继续创建一个名为“批准状态”的新字段(或任何适合您的字段),并添加一些选项。 Requested、Pending Approval、Approved 和 Rejected 是 Approval State 字段的推荐选项。

您的流程中是否只有一个批准步骤?

太棒了。 转到第 4 步。

您是否有多个批准步骤?

您确定需要多个批准步骤吗? 现在是用白板写您的流程并查找浪费的好时机。

除了“批准状态”字段之外,最好为每种所需的批准类型设置一个自定义下拉字段,以帮助推动工作流程。 例如,如果您有一个技术批准和一个 CAB 批准,则应再创建两个新字段: 技术批准和 CAB 批准。

除了您之前添加的“批准状态”字段之外,为每种所需的批准类型创建一个新的工单字段。


第 4 步。哪些信息推动了您的 CAB/批准流程?

现在我们已经有了跟踪更改请求的基本结构,以及它们在批准流程中的位置,是时候尽可能地自动化这个流程了。 首先,花一些时间来识别任何始终适用于您的变更管理流程的规则。

考虑:

    • 在 CAB 中审阅了哪些类型的更改? (紧急更改是否已自动批准?次要更改会怎样?)
    • 是否所有更改都会立即提交给 CAB 进行批准?
    • 某些类型的更改(可能根据技术堆栈)是否需要先批准才能在 CAB 中进行审阅?
    • 在转到 CAB 进行批准之前,您是否有多个并行批准?

这样做:

这是一门艺术,而不是科学,因此请根据您自己的判断进行此步骤。 对于上面的每个“规则”, 创建一个触发器以自动执行该规则 。 例如,您可能决定创建一个触发器,以查找任何批准状态为“已请求”的已开启次要更改请求,并自动将“批准状态”设置为“已批准”。  或者,您可以查找批准状态为“已请求”的任何已开启的主要更改请求,然后将该更改分配给 CAB 组,并将其批准状态变为“待批准”。

 

示例 1

  条件 操作
触发器 1

状态为新建
更改类型为主要更改
批准状态为已请求

状态:已开启
批准状态:待批准
组:CAB

触发器 2

状态为新建
更改类型为次要更改
批准状态为“请求”或空白

状态:已开启
批准状态:已批准

触发器 3

(对每个组重复
必要时)

状态为已开启
更改类型为主要更改
批准状态为已批准
技术就是 Unix 服务器

组:Unix 服务器支持
触发器 4

状态为已开启
更改类型为主要更改
批准状态为已拒绝

状态:已解决

如果您有一个多步骤的批准流程,请创建一个触发器,首先将更改分配给第一个需要批准的组。 然后,创建另一个触发器,当第一个组已批准时触发(请记住,我们将使用单独的字段跟踪每个批准步骤),并自动将更改分配给下一个需要批准的组。

如果您有一个带有并行批准的多步骤批准流程,请设置一些触发器以查找所有要批准的批准字段,然后自动将“批准状态”移动到“已批准”。  相反,如果您看到至少一个拒绝,请将“批准”状态移动到“已拒绝”。

这没有灵丹妙药,因此请确定您的简单流程,然后创建触发器以自动化工作流程。


第 5 步。额外额度

我们遇到的最大问题之一是如何确保每个步骤都有合适的人员批准更改。 当然,您始终可以通过事件审核日志查看谁批准了,但有时,最好进行一些其他检查。

宏

您可以为指定的更改批准者创建个人或组的宏,使其一键批准。 宏可以更改批准字段本身,还可以添加个性化的评论到工单。 例如,宏可以应用评论“专员 X 已代表 Unix 服务器团队批准”。

电邮批准

您也可以更进一步,要求通过电邮获得批准。 换言之,允许您的批准者用“批准”或“拒绝”回复电邮通知,并让触发器相应地更改批准字段。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

由 Zendesk 提供技术支持