概述

变更管理过程向导旨在为那些已经拥有某种变更管理过程并且需要对Zendesk Support进行高级裁剪(配置，而不是定制)的组织所使用。亚博

步骤1。在变更发生之前，您希望收集哪些信息?

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

想:

• 更改是否针对特定的技术堆栈?
• 进行更改的业务理由是什么?
• 谁在实施变更?
• 是否需要中断服务?
• 中断持续多长时间?
• 谁会受到变化的影响?(业务单元?全球区域?网站?)
• 更改是否需要在特定日期和时间内完成?
• 更改是否需要等到特定的日期和时间才能实现?
• 需要什么类型的更改?(标准?小吗?专业吗?紧急?)

只选择那些实际上有助于推动是否应该继续进行更改的决策、有助于推动沟通、或有助于报告具有与之相关的行动计划的特定度量标准的字段。人们总是希望尽可能多地跟踪有关变化的信息，但要现实一点。当您真正需要的变更管理过程非常简单时，很容易走极端。

做的事:

对于你想要捕捉的每一条信息，创建一个新的票证字段。

---

步骤2。谁参与你的CAB /审批程序?

接下来，确定需要参与批准变更请求的所有人员组。

想:

• 你们有正式的变革顾问委员会吗?
• 在实施变更之前，您是否需要获得业务批准?
• 谁(如果有的话)需要批准特定于技术的更改?

做的事:

对于确定的每一组，创建一个新组。接下来，将所有潜在的审批者(这些应该是具有代理角色的Zendesk用户)添加到各自的组中。亚博

---

步骤3。你们的审批流程是怎样的?

现在是时候考虑一下你的审批程序了。

最好从创建单个下拉字段开始，该字段将跟踪更改批准的总体状态。继续并创建一个名为“Approval State”的新字段(或任何适合您的字段)，并添加一些选项。已请求、待定批准、已批准和已拒绝是Approval State字段的推荐选项。

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

辉煌。转到步骤4。

你有多个审批步骤吗?

您确定需要多个审批步骤吗?这是一个很好的时间来白板你的过程和寻找浪费。

除了approval State字段之外，最好为所需的每种审批类型提供自定义下拉字段，以帮助驱动工作流。例如，如果您有一个技术批准和一个CAB批准，那么您应该再创建两个新字段:technology approval和CAB approval。

除了前面添加的approval State字段之外，继续为所需的每种审批类型创建一个新的票据字段。

---

步骤4。什么信息驱动你的CAB /审批程序?

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

想:

• 在CAB中审查哪些类型的更改?(紧急更改是否自动批准?小的改动怎么办?)
• 所有变更是否立即提交CAB批准?
• 在CAB中审查变更之前，是否需要批准某些类型的变更(可能是通过技术堆栈)?
• 在去CAB申请批准之前，你们有几个并行的批准吗?

做的事:

这是一门艺术，而不是科学，所以在这一步使用你自己的判断。对于上面的每个“规则”，创建一个触发器来自动执行该规则。例如，您可能决定创建一个触发器，它查找审批状态为“Requested”的任何开放的小更改请求，并自动将审批状态设置为“Approved”。或者，您可以查找任何批准状态为“Requested”的开放的主要变更请求，然后将该变更分配给CAB组，并将其批准状态移动到“Pending Approval”。

示例1

	条件	行动
触发1	状态是新的 “变更类型”为“重大变更” 请求批准状态	状态:开放 审批状态:待批 组:出租车
触发2	状态是新的 “变更类型”为“次要变更” 审批状态为请求或空白	状态:开放 批准状态:已批准
触发3 (每组重复 必要时)	状态为Open “变更类型”为“重大变更” 审批状态为已批准 技术是Unix服务器	组:Unix Server Support
触发4	状态为Open “变更类型”为“重大变更” 审批状态为拒绝	解决状态:

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

如果您有一个具有并行审批的多步骤审批流程，那么设置一些触发器来查找要批准的所有n个审批字段，然后自动将approval State移动到“approved”。或者，相反，如果您看到至少一个拒绝，则将Approval状态移动到“已拒绝”。

没有什么灵丹妙药可以解决这个问题，所以确定你的简单流程是什么，然后创建触发器来实现工作流的自动化。

---

第5步。额外的信用

我们遇到的最大问题之一是如何确保在每一步都由合适的人批准变更。当然，您总是可以通过事件审计日志看到是谁批准的，但有时最好有一些其他检查。

宏

您可以为指定的变更审批人创建个人或组宏，允许他们在一次单击中进行审批。宏可以更改审批字段本身，还可以向票据添加个性化的注释。例如，宏可以应用注释“代理X代表Unix服务器团队批准”。

电子邮件批准

你还可以更进一步，要求通过电子邮件获得批准。换句话说，允许审批人用“批准”或“拒绝”回复电子邮件通知，并让触发器相应地更改审批字段。