概要
変更管理プロセスウィザードは、ある種の変更管理プロセスをすでに導入していて、Zendesk Supportの高度な調整（カスタマイズではなく構成レベルの調整）を必要としている組織によって使用されることを想定しています。
手順1. 変更を実施する前に、変更に関して収集しておきたい情報は何か
着手に際し、変更に関して集める必要のある情報の種類を特定する必要があります。集めた情報は、変更のリスクや影響を評価したり、承認の実装プランを評価するために使用されます。
検討事項：
- 変更は、特定のテクノロジスタックに対するものか。
- 変更を行うためのビジネス上の正当な理由は何か。
- 変更を実装する担当者はだれか。
- システムの停止が必要か。
- システム停止の期間はどのくらいか。
- だれが変更の影響を受けるのか。（事業部門、世界レベル、拠点レベルなど）
- 決められた期限までに変更を完了しなければならないのか。
- 指定された日時になるまで変更の実装を待つ必要があるか。
- 必要となる変更はどのタイプか。（標準、マイナー、重大、緊急など）
情報を収集するのは、変更を実施するかどうかの決定に役立つフィールド、コミュニケーションの促進に役立つフィールド、変更に関連するアクションプランを備えた特定の指標に基づくレポート作成に役立つフィールドだけにします。 変更については、人事を尽くしてできる限り多数の情報を追跡したいと高望みをしがちなものですが、現実的になってください。 変更管理プロセスに関して、実際にはそれほど複雑な手続きを必要としないにもかかわらず、情報を集めすぎてしまうのはよくあることです。
実施事項：
収集する個々の情報について、新しいチケットフィールドを作成してください。
手順2. CAB/承認プロセスに関与するメンバーはだれか
次に、変更リクエストの承認プロセスに参加を求めるメンバー（グループ）を明確にします。
検討事項：
- 正式なCAB（Change Advisory Board：変更諮問委員会）が設けられているか。
- これまでに、変更を実装する前に会社側の承認が必要だったことはあるか。
- 技術面の承認はだれが行うのか（必要な場合）。
実施事項：
各グループを明確にできたら、新しいグループを作成します。次に、承認者になる可能性のある者（エージェントロールを持つZendeskユーザー）全員を、それぞれ該当するグループに追加します。
手順3. 承認プロセスはどのように行われるか
ここでは、承認プロセスについて十分に検討します。
変更の承認について全体的な状況を追跡するためのドロップダウンフィールドを1個作成するとよいでしょう。まず、「承認ステータス」（またはわかりやすい任意の名前）という新しいフィールドを作成し、ステータスの項目をいくつか追加します。「承認ステータス」フィールドのおすすめの項目は、「要求済み」、「承認待ち」、「承認済み」、「却下済み」などです。
プロセスの承認段階は1段階のみですか。
承認手続きが1段階のみの場合は、手順4に進んでください。
プロセスの承認手続きが複数ありますか。
承認手続きはほんとうに複数必要でしょうか。プロセスをホワイトボードに書き出して、無駄を見つけるよい機会です。
一番よいのは、「承認ステータス」フィールドに、必要な承認タイプごとにカスタムドロップダウンフィールドを追加するやり方です。たとえば、技術者からの承認とCABからの承認が必要な場合、「技術部門の承認」、「CABの承認」という2個の新しいフィールドを追加します。
では、さきほど追加した「承認ステータス」フィールドに、必要な承認タイプごとに新しいチケットフィールドを作成してみましょう。
手順4. CAB/承認プロセスを推進させる情報は何か
さて、変更要求を追跡し、承認プロセス内での現在地を調べる基本的な構造を準備できたので、今度はプロセスをできる限り自動化してみましょう。まず、時間を少しかけて、変換管理プロセスで常に「真」でなければならないルールを決めます。
検討事項：
- どのようなタイプの変更がCABでレビューの対象になるのか。（緊急の変更は自動承認されるのか、マイナーな変更についてはどうするのか、など。）
- すべての変更はただちにCABのレビューにかけられるのか。
- 特定のタイプの変更（通常はテクノロジースタックに対する変更）は、CABレビューに進む前に承認を受ける必要があるのか。
- CABレビューに進む前に、同時に複数の承認が進行するのか。
実施事項：
これは科学というよりも手際の問題なので、この手順については各自の判断に負います。上述のルールそれぞれについて、ルールを自動化するトリガを作成します。たとえば、「承認ステータス」が「要求済み」になっているオープン中のマイナーな変更リクエストを探し、「承認ステータス」を自動的に「承認済み」に設定するトリガを作成することにしたとします。あるいは、「承認ステータス」が「要求済み」になっているオープン中の重要な変更リクエストを探し、見つかった変更リクエストをCABグループに割り当てて、「承認ステータス」を「承認待ち」に変更するトリガを作成するとします。
例1
| 条件 | アクション | |
| トリガ1 |
ステータス ＝ 新規 |
ステータス：オープン |
| トリガ2 |
ステータス ＝ 新規 |
ステータス：オープン |
| トリガ3 （グループごとに必要な回数 繰り返す） |
ステータス ＝ オープン |
グループ:Unixサーバーサポート |
| トリガ4 |
ステータス ＝ オープン |
ステータス：解決済み |
承認プロセスに複数の承認段階がある場合、まず、承認を得る必要のある最初のグループに変更を割り当てるトリガを作成します。次に、最初のグループから承認を得た後（今回は各承認段階ごとに別々のフィールドで追跡している）に実行され、承認を得る必要のある次のグループに変更を自動的に割り当てる別のトリガを作成します。
複数段階の承認プロセスで、同時に複数の承認が進行する場合、すべての承認フィールドが承認されている変更を探して「承認ステータス」を自動的に「承認済み」に移行するトリガを設定します。または、反対に、却下がひとつでもある場合に「承認ステータス」を「却下済み」に移行するトリガを設定します。
万能の手段はないので、自社にとってシンプルなプロセスとは何かを決めてから、ワークフローを自動化するトリガを作成するようにしてください。
手順5. 課外授業
よく質問されるのですが、承認プロセスの各段階で変更を承認する担当者が適任であることをどうやって確認すればよいのでしょうか。当然、イベント監査ログを見ればいつでも承認者を確認することができますが、適宜、別の方法で確認を行うのはよい考えです。
マクロ
指定された変更承認について、1回のクリックで承認できるような個人用またはグループ用のマクロを作成できます。このマクロは、承認フィールド自体を変更し、チケットにカスタムのコメントを追加することができます。たとえば、このマクロで「エージェントXがUnixサーバーチームの代理で承認」というコメントを適用できます。
メールによる承認
さらに一歩進んで、トリガを使用して、メール経由で承認を求めることができます。つまり、承認者は、メール通知に対して「承認」または「却下」と返答することができます。トリガはその返答を受けて、承認ステータスをそのように変更します。