https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/ticket_manage/index.html Recent content in 4.3.8 チケット管理 on JP1 Cloud Service 運用統合 利用ガイド Hugo -- gohugo.io ja https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/ticket_manage/ticket_notification/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/ticket_manage/ticket_notification/index.html OTOBOを使用して通知の設定をすることで、チケット作成や更新などチケットに対して操作が行われた際に、Ops IのGUIでの通知や、メールでの通知ができます。これにより、インシデントなどの重要な課題が発生した場合に、迅速に対処を開始できます。 （1）チケットの通知設定 チケットの通知機能を使用するため、以下のどちらかを利用します。 Ops Iの通知機能： Ops Iの通知機能を利用して、Ops IのGUIとメールでの通知を行えます。 メールサーバーを利用した機能： お客様が準備するメールサーバーを利用して、メールでの通知を行えます。 各通知機能の特徴について以下に示します。 （表）通知機能の特徴 項目 Ops Iの通知機能 メールサーバーを利用した機能 通知方法 Ops IのGUI通知、メール通知 メール通知に10分程度の遅れが発生する場合があります。 同一の宛先に対して10分間に複数の通知が発生した場合、これらの通知は1通のメールにまとめて送信されます。 メールの通知順は、通知の重要度によって送信順が前後します。 メール通知 サーバーの準備 不要 Ops Iのシステムを使用します。 必要 メールサーバー メールアカウントの準備 不要 メール送信用アドレスは以下が使用されます。 noreply@ops-integration.com 必要 メール送信用アドレス（メール通知機能を使用する場合） 通知方法の設定 以下の場合に必要デフォルトで設定されていない場合 詳細は「Ops Iバージョンアップ対応」を参照通知方法を変更したい場合 メール通知の設計のポイントと、処理の流れの例を以下に示します。 （表）通知の設計ポイントと処理の流れの例 項目 設計のポイント 処理の流れの例 Ops Iの通知機能を利用したOps IのGUIでの通知/メール通知 通知タイミング、宛先の情報を事前に整理します。 事前にチケット作成時に通知するよう設定する Ops Iでチケットを新規作成するとOTOBOがチケット作成を検知する Ops IのGUIで通知 Ops Iの通知機能で事前に設定されているユーザーのメールアドレスに送信する。メール通知は重要度が高い通知から順次送信されるため、Ops IのGUI通知に対し10分程度タイムラグが発生する場合がある。 メモ 同一の宛先に対して10分間に複数の通知が発生した場合、これらの通知は1通のメールにまとめて送信されます。 メールサーバーを利用したメール通知 通知タイミング、宛先、および使用するメールサーバー・認証方式の情報を事前に整理します。 事前にチケット作成時にメール通知するよう設定する Ops Iでチケットを新規作成するとOTOBOがチケット作成を検知する ユーザーが用意したメールサーバーのSMTPにチケット作成のメールを送信 SMTPから事前に設定されているユーザーのメールアドレスに送信する 通知機能の設定の詳細については「JP1 Cloud Service 運用統合 利用ガイド（ITSM操作編）」の「ユースケース＞通知とメールによるチケット作成のユースケース」を参照してください。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/ticket_manage/sla_incident/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/ticket_manage/sla_incident/index.html インシデントのSLAの管理機能により、インシデント発生から解決までの対応目標時間に対する遵守状況の確認が可能です。Ops Iのチケット管理機能におけるSLAとは、インシデントの解決に向けた4つの指標の目標値を意味します。SLAに対するインシデントチケットごとの遵守状況は、チケット詳細画面やチケット一覧で確認できます。チケット一覧のソート機能を用いることで、どのインシデントチケットを優先して対応すればよいかを確認できます。画面の詳細は「SLAs」を参照してください。また、ここで「チケット」はインシデントチケットを意味します。 SLA機能では以下を行うことができます。 複数のSLAの管理 チケットごとのSLA遵守状況の計算に用いる対象（営業日、営業時間、休日、タイムゾーン）の設定 チケットごとに適したSLAの設定（自動割り当て、手動割り当て） チケットごとのSLA遵守状況の確認 チケット一覧でのSLA遵守状況の確認 チケットごとに設定したSLAの期限、事前警告を超えた場合の担当者への通知 詳細を以下で説明します。 SLAの指標 SLAの作成方法 チケットごとのSLAの割り当て チケットごとのSLA遵守状況の確認 （1）SLAの指標 SLAの指標としてTime to Detect、Time to Acknowledge、Time to Know、Time to Resolveの4種類をサポートします。それぞれの指標はインシデント発生から解決までの一連の流れの中で、さまざまな対応にかかる期間を表します。 （図）SLAの指標 （表）SLAの指標 指標 説明 Time to Detect インシデント発生から問題判明の期間インシデント発生：「問題発生日時」フィールドに手動入力する日時 チケット作成日時より前の日時を設定します。チケット作成日時以降の日時を設定した場合、評価対象外になります。問題判明：チケットが作成された日時 Time to Acknowledge 問題判明から対応開始の期間問題判明：チケットが作成された日時対応開始：「担当者」フィールドに担当者が設定された日時 Time to Know 問題判明から原因特定の期間問題判明：チケットが作成された日時原因特定：「原因判明日時」フィールドに手動入力する日時 Time to Resolve 問題判明から解決の期間問題判明：チケットが作成された日時解決：「ステータス」フィールドにClosedが設定された日時 インシデントチケットの各フィールドの詳細は「incidentチケット」を参照してください。 （2）SLAの作成方法 SLAはチケットから割り当てる前にあらかじめ準備します。インシデントによって最適なSLAを割り当てるため、複数のSLAを定義できます。以下の手順でSLAを定義します。 1. カレンダーの設定 SLAに対するチケットの遵守状況を計算する際に、計算の対象を設定する必要があります。営業日、営業時間、対象外にする休日、タイムゾーンなどを定義するカレンダーを設定します。 2. SLAの作成 SLAの各指標について、対応するための目標時間（分）を設定します。SLAの目標時間に0を設定した指標は評価対象外となり、ステータス「不定」が表示されます。 警告しきい値（%）を、SLAの指標Time to Acknowledge、Time to Know、Time to Resolveについて設定します。Time to Detectは、インシデント発生日時を手動で入力した時点で、目標時間内かどうかが計算されるため、警告しきい値は設定しません。 目標時間、警告しきい値は、遵守状況の計算や担当者への通知の基準になります。 3. カレンダーのSLAへの割り当て 1つのカレンダーを複数のSLAに割り当てることができます。 これらの操作はITSMアプリケーションの[管理]機能で行うため、Primitiveロール「itsm_admin」の権限が必要です。 カレンダー設定、およびSLA作成、更新、無効化の手順の詳細は「JP1 Cloud Service 運用統合 利用ガイド（ITSM操作編）」の「[管理]＞カレンダーの設定」および「[管理]＞SLAの管理」を参照してください。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/ticket_manage/approval_flow/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/ticket_manage/approval_flow/index.html チケットの承認機能により、承認者がチケットの記載内容の確認ができるため、チケット管理上の品質を確保できます。例えばリクエストチケットのインシデントの承認は、インシデントの重要度や影響度を評価し、適切な優先度を設定するために行われます。これにより、リソースの適切な割り当てや対応の優先順位付けが可能となります。 チケットの承認機能は、タイプごとに有効/無効を設定できます。チケット機能を有効にする際に、承認が必要なステータス、承認された場合に遷移するステータス、却下された場合に遷移するステータスを設定します。 【承認機能の利用条件】 承認機能を利用するには以下の対応が必要です。 承認機能が有効になっている： 詳細は「承認機能の有効化・無効化」を参照してください。 承認フローダイアログの「ステータス」フィールドに、承認機能を適用するステータスを設定している： 詳細は「承認フロー」を参照してください。チケットタイプのデフォルトのステータス、およびユーザーが追加したステータスを設定できます。ステータスを追加する場合は「チケットのステータス」を参照してください。 注意事項 特定のチケットタイプで承認機能を利用する場合は、承認が必要なステータスは、チケットタイプごとに設定されたステータス遷移に含まれる必要があります。例えば、rfcチケットの承認機能が有効化されている場合、変更種別によってステータス遷移が異なるため、承認が必要なステータスがステータス遷移に含まれる変更種別のみ、承認フローボタンが表示されます。 承認機能で承認、却下された場合に遷移するステータスは、チケットタイプごとに設定されたステータス遷移とは関係ありません。 承認中のチケットがある状態で、承認フローに設定されたユーザーやグループを削除した場合、当該チケットは承認できなくなります。承認中のチケットがあるユーザーやグループは削除しないでください。また、承認ができなくなった場合は「承認中のチケットが承認できなくなった場合」の方法で回避してください。 承認機能を利用する場合のユースケースを以下に示します。 （表）承認機能のユースケース 作業 説明 承認機能が必要なチケットタイプに承認機能を設定する チケットの承認機能を有効化する 承認が必要なステータス"awaiting_approval"、承認された場合に遷移するステータス"awaiting_implementation"、却下された場合に遷移するステータス"declined"を設定する チケット作成後、チケット詳細画面で承認者を設定する チケットに承認者を設定する チケットに1人以上の承認者と承認順を設定するチケットを保存する 承認者に通知する※ チケットのステータスを"awaiting_approval"にする最初の承認者へ自動的に承認依頼が通知される 承認者はチケットの記載を確認し、承認または却下ができる 承認する承認日時が保存される次の承認者がいる場合：次の承認者に自動的に通知される 次の承認者がいない場合：次のステータス"awaiting_implementation"に自動的に遷移する却下する次のステータス"decline"に自動的に遷移する このとき承認済の日時はリセットされる担当者に却下通知が自動的に通知される担当者がチケットを修正し、再申請するためステータスを"awaiting_approval"にすることで、最初の承認者に再度承認依頼が通知される。このとき承認日時は再設定される ※チケットが承認者以外のユーザーによって編集された場合、承認依頼は更新後の内容で承認者に再度通知されます。 作業の詳細について以下に示します。 （1）承認機能の有効化・無効化 チケットの承認機能は、デフォルトで無効化されています。承認機能はREST APIで、チケットタイプごとに有効化できます。承認機能が有効化されると、新規チケット追加画面とチケット詳細画面の操作ボタンに「承認フロー」が表示され、承認者の設定を行えます。承認フローボタンはタスクアプリケーションにのみ表示されます。チケット詳細画面の構成の詳細は「（表）チケット詳細画面の構成」、新規チケット追加画面の詳細は「（表）新規チケット追加画面の構成」を参照してください。 承認機能の有効化、無効化、および設定の変更を行うには、Primitiveロール「itsm_admin」または「itsm_manager」が割り当てられている必要があります。ただしPrimitiveロール「free_user」または「manager」が割り当てられている場合は、承認機能の設定の取得、有効化、無効化、および設定の変更を行えません。 設定は以下のREST APIで行います。詳細は「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス詳細＞カスタムAPI」を参照してください。 【承認機能を有効化する】 POST /capi/v1/ticket-settings/approval 有効化すると以下が表示されます。 承認フローボタン（新規チケット追加画面、チケット詳細画面） 「承認者」フィールド※：現在の承認者の名前（チケット詳細画面） 「承認グループ」フィールド※：現在の承認グループ名（チケット詳細画面） ※読み取り専用です。承認が必要なステータス以外では空欄になります。承認者、承認グループの設定方法は「（表）承認フローダイアログの構成」を参照してください。 承認機能を有効化するタイプごとにAPIで以下を設定します。承認が必要なステータスは複数設定できます。 type：承認を有効化するチケットタイプ approval：承認が必要なステータス transition approved：承認された場合に遷移するステータスdeclined：却下された場合に遷移するステータス reset：遷移した際に承認済の承認日時がリセットされるステータス（任意） 以下にリクエストボディの例を示します。 ＜承認が必要なステータスが1つの場合＞ {   "type": "rfc",   "statuses": [     {       "approval": "awaiting_approval",       "reset": "new",       "transition": {         "approved": "awaiting_implementation",         "declined": "declined"       }     }   ] } ＜承認が必要なステータスが2つの場合＞ {