サービスオペレーションワークスペース での変更要求の作成

サポートされている構成アイテム (CI) への変更を追跡します。変更要求フォームを使用して、変更理由、タイプ、優先度、リスクなどの情報を記録します。

始める前に

必要なロール：itil または admin

注:

DevOps データを表示したり、変更要求に追加したりするには、sn_devops.viewer ロールが必要です。

手順

1. 変更要求の作成を開始するには、次のいずれかのアクションを実行します。

   オプション	説明
   変更リストから	変更のリストに移動します。 注: 次のリストを変更できます。 オープン クローズ済み All (すべて) [新規] を選択します。
   インシデントから	インシデントを開きます。 レコードページから、[変更要求の作成] を選択します。
   インタラクションから	インタラクションを開きます。 レコードページで、[ インシデントを作成 ] の横にあるドロップダウンを選択し、[ 変更を作成] を選択します。
   問題から	問題を開きます。 次のいずれかのアクションを実行します。 レコードページで、[ 問題タスクを作成 ] の横にあるドロップダウンを選択し、[ 変更要求の作成] を選択します。 [ 修復タスク] タブから [変更要求] リストに移動し、[ 新規] を選択します。

2. 作成する変更モデルを選択し、[ 次へ] を選択します。

   変更モデルの詳細については、「変更モデル」を参照してください。

   オプション	説明
   通常	事前承認済みの変更や緊急の変更ではないサービス変更です。
   事前承認済み	事前に承認されたリスクの低い変更で、比較的一般的で、指定された手順または作業指示に従います。
   緊急	グループおよびピアのレビューと承認をバイパスする緊急の変更で、CAB 承認グループによる承認のために [認証] ステータスに直接進みます。
   DevOps または DevOps Simplified	DevOps 変更要求に使用される変更モデル。DevOps モデルの変更の詳細については、「DevOps 変更モデル」を参照してください。 注: DevOps モデルを使用するには、DevOps チェンジベロシティアプリケーションをアクティブ化する必要があります。

   注:

   • 変更タイプをフィルタリングして検索できます。
   • インタラクションから変更要求を作成する場合は、事前承認済みの変更タイプのみを使用できます。
3. [概要] タブで、フィールドに入力します。

   [概要] タブで、変更の初期詳細を入力する必要があります。

   フィールド	説明
   簡単な説明	変更の簡単な説明
   説明	変更の詳細な説明
   購入理由	計画された変更要求の理由。承認者が意思決定を下すのに役立ちます。

4. [Save (保存)] を選択します。

   変更要求は、[スコープと影響]、[アサイン]、[スケジュール]、[リスク評価]、および [変更タスク] セクションとともに作成されます。

5. [スコープと影響] セクションで [スコープを追加] を選択します。
   1. フォームのフィールドに入力します。

      表 : 1. [スコープの追加] フォーム

      フィールド	説明
      構成アイテム	変更が適用される構成アイテム (CI)。サービスオファリングを含む、任意のタイプの CI を変更の要求に関連付けることができます。また、SLA と可用性の要件への詳細なアクセスを可能にします。
      サービスオファリング	可用性、スコープ、価格設定、およびパッケージングに関して、サービスのレベルを一意に定義する 1 つ以上のサービスコミットメントで構成されています。サービスオファリングを使用すると、指定されたサービスのさまざまな機能とそのパフォーマンスレベルを受け取ることができます。
      サービス	変更要求に対して使用できるようにするビジネスサービス。
      カテゴリ	変更のカテゴリには、[ハードウェア]、[ネットワーク]、[ソフトウェア] [その他]、[DevOps] などがあります。 注: [DevOps データを追加] セクション (この手順のステップ 8) は、カテゴリが [DevOps] として選択されている場合にのみ有効になります。DevOps モデルの場合、カテゴリは自動的に [DevOps] に設定されます。
      影響を受ける CI	CI を単一の変更要求に関連付けます。
      一括 CI 更新を提案	特定の CI クラスの CI セットに同じ更新を適用します。
      単一の変更を提案	影響を受ける CI のリストから 1 つの CI への変更を提案します。
      影響するサービスの更新	影響するサービスをリフレッシュすると、[影響するサービス/CI]、[ビジネスアプリケーション]、および [サービスオファリング] 関連リストが、影響を受ける CI に基づいて更新されます。各関連リストのレコードは、影響を受ける単一の CI からの影響である場合でも一意です。

   2. [Save (保存)] を選択します。
6. [アサイン] セクションで [アサイン] を選択します。
   1. フォームの各フィールドに入力します。

      フィールド	説明
      アサイン先グループ	変更にアサインされたグループ それぞれの構成アイテム (CI) で利用可能なサポートグループに基づいて、[アサイン先グループ] フィールドを自動的に入力できます。CI に変更グループがない場合は、サービスオファリングで利用可能な変更グループがフィールドに入力されます。ビジネスルール [CI/SO に基づいてアサイン先グループを入力 (Populate Assignment Group based on CI/SO)] は、インシデント、問題、または変更要求が作成または更新されたとき、および [アサイン先グループ] フィールドと [担当者] フィールドが空のときに機能をトリガーします。次のプロパティは、[アサイン先グループ] フィールドに値が入力されるフィールドを識別します。 com.snc.change_request.ci_assignment_group.field_name：この変更プロパティは、[アサイン先グループ] フィールドに入力される CI フィールドを識別します。 com.snc.change_request.service_offering_assignment_group.field_name：この変更プロパティは、[アサイン先グループ] フィールドに入力されるサービスオファリングフィールドを識別します。 注: プロパティのデフォルト値は、それぞれインシデントまたは問題のサポートグループと変更要求の変更グループです。ビジネスルール [CI/SO に基づいてアサイン先グループを入力 (Populate Assignment Group based on CI/SO)] は、開発プラグイン ITSM CSDM Best Practice – Quebec プラグイン (com.snc.best_practice.itsm_csdm.quebec) の一部として出荷され、新規のお客様のみが利用できます。
      担当者	変更要求にアサインされたユーザー。アサインルールが適用される場合、変更が適切なユーザーまたはグループに自動的にアサインされます。
      作業メモ	変更の解決方法に関する情報、または変更の解決手順 (該当する場合)。このメモは内部で使用されます。作業メモ情報は顧客に表示されません。

   2. [Save (保存)] を選択します。
7. 変更の実装をスケジュールするには、[スケジュール] を選択します。
   1. フォームのフィールドに入力します。

      表 : 2. スケジュール

      フィールド	説明
      開始予定日	変更の処理を開始する日付
      終了予定日	変更の完了が予定されている日付 タスク タイプが [実装] である場合、[開始予定日] および [終了予定日] の値は、変更要求で指定された開始予定日と終了予定日の範囲内に値がなければなりません。
      実開始日	実装の開始日
      競合ステータス	競合のステータス。
      実終了日	変更が実装された日付。
      最近の実行の競合	競合が最後に実行された日付。

   2. [スケジュール] を選択します。

      競合がある場合に変更の実装を再スケジュールするには、[次の競合のないカード (Next conflict-free card)] から [スケジュール] を選択します。

      

   3. [詳細] タブを選択して、変更の詳細を表示します。
8. オプション: [DevOps データ (DevOps data)] セクションで [データを追加] を選択して、DevOps データを変更要求に追加します。
   注:

   DevOps データを変更要求に追加したり、作成済みの変更レコード内の DevOps データを表示したりするには、sn_devops.viewer ロールが必要です。
   1. [関連付けを選択 (Select associations)] ステップで、以下の値を指定します。

      表 : 3. 関連付けを選択

      フィールド	説明
      データタイプ	変更要求に関連付けるデータのタイプ。 アーティファクトバージョン リリースバージョン ビルド番号 作業アイテム
      データの関連付け	変更要求に関連付ける特定のデータ。複数のアーティファクトバージョン、ビルド番号、および作業アイテムを選択できます。 [データタイプ] として [ビルド番号] を選択した場合は、アプリケーション名、対応するパイプライン、およびビルド番号も指定する必要があります。[データタイプ] として [作業アイテム] を選択した場合は、アプリケーションとプラン別に選択可能な作業アイテムのリストをフィルタリングできます。

   2. [次へ] を選択して、[データの確認 (Review data)] ステップを開きます。
   3. タブ間を移動して、関連するデータが正確にマッピングされていることを確認します。
      必要に応じて設定を更新します。

      • 作業アイテム
      • コミット
      • プル要求
      • テストサマリ
      • アーティファクトバージョン
      • ソフトウェア品質サマリ
      • セキュリティスキャンサマリ
   4. [送信] を選択します。
   5. オプション: 変更要求に関連付けられているデータを変更するには、[DevOps データを編集] を選択します。
      1. [関連付けを選択 (Select associations)] ステップでの DevOps データの追加元のデータタイプとその関連付けを編集します。
      2. [データの確認 (Review data)] ステップで、この変更要求に関連付けられるか、この変更要求から削除される DevOps データを確認します。
      3. [送信] を選択します。
9. 変更のリスクを評価するには、[リスク評価] を選択します。

   リスクが計算され、レコード情報に表示されます。

   最後に評価されたリスク値がタイムスタンプとともに表示されます。

10. [変更タスク] セクションで [新規] を選択します。
    変更タスクの詳細については、「サービスオペレーションワークスペース での変更タスクの作成」を参照してください。
11. 変更要求が次のステータスに進む準備ができたら、[承認リクエスト] を選択します。
    変更要求のタイプに基づいてステータスが前に進みます。

    • [評価] ステータス：通常の変更要求に対するグループレベル承認。承認レコードは、変更承認ポリシーに基づいて自動的に生成されます。提案された変更のピア レビューと技術レビューを行うことができます。
    • 承認ステータス：ビジネスステークホルダーまたは変更諮問委員会による承認が必要です。
    • [スケジュール済み] ステータス：事前承認された標準的な変更。

    注:

    変更レコードをメールで送信するには、コンテンツフレームでその他のオプションアイコン ( を選択し、[ メール] を選択します。変更を要求したユーザーと、変更にアサインされたユーザーは、どちらも受信者のリストに自動的に設定されます。

    カレンダーを表示するには、[変更要求] フォームのタイトルバーにある [ カレンダーを表示 ] を選択します。

12. [Save (保存)] を選択します。

関連概念

• 標準的な変更のカタログ

関連タスク

• サービスオペレーションワークスペース での変更要求の処理
• サービスオペレーションワークスペース での変更タスクの作成
• サービスオペレーションワークスペース での変更タスクの処理