問題管理
Information Technology Infrastructure Library (ITIL) は、インシデントと問題を区別しています。インシデント管理の目的は、サービスまたは中断されたエクスペリエンスを迅速に回復させることです。インシデントに関する詳細は、「インシデント管理」を参照してください。
問題管理の目的は、インシデントの再発を防止することです。問題は一般的に、カスタマーではなく、内部の ITメンバーにより報告されます。
ITIL 問題管理ワークフローは、IT インフラストラクチャーの問題の調査、記録、および防止を目的としています。IT Service Desk テンプレートには問題を処理するためのワークフローが組み込まれています。テンプレートの既定のワークフローから開始して、ビジネスニーズに合わせて適宜変更を加えることをお勧めします。
問題登録を作成する手順:
- From the sidebar, select Create () > Issue.
- 問題課題タイプを使用して課題を作成します。
正しく管理されていれば、問題レコードはエージェントに対してナレッジベースに既知のエラーおよび回避方法を詳述するようにプロンプトを出します。これらのドキュメントの意義は次のとおりです。
- サービスエージェントが問題を解決し、サービスを回復できるよう支援する
- ダウンタイムを削減する
- IT インフラストラクチャーの品質と信頼を向上させる
このページでは、Jira Service Desk を使用して問題を管理するためのベストプラクティスをいくつか紹介します。ITIL の推奨事項を最適な形でビジネスに生かす方法を習得する正式なトレーニングを探すこともできます。
問題管理プロセス
IT Service Desk テンプレートには問題管理ワークフローが組み込まれています。このワークフローは、以下の問題管理プロセスを補完するために設定されています。ワークフローを使用して問題登録を以下の ITIL 推奨アクティビティに沿ってトランジションします。
- 問題の調査
- 回避方法の特定
- 既知のエラーの記録
既定のワークフローから開始して、使用していく中で特定のニーズに合わせて適宜変更を加えることをお勧めします。
ITIL 問題管理プロセス (要約):
- インシデントの傾向、ベンダー、または技術サポートスタッフにより、サービスデスクに問題が報告されます。
- サービスデスクのチームメンバーは問題の詳細を記録し、すべての関連インシデントをリンクします。
- サービスデスクエージェントは、問題を適切に分類するラベルを付けます。問題にリンクされているインシデントのラベルを再使用することもあります。チームはレビュー中と報告書作成でこれらの分類を使用します。
- サービスデスクエージェントは問題の優先順位付けを行います。関連インシデントの頻度とその影響に基づいて優先順位を決定します。
- サービスデスクチームは問題の根本原因を判別します。
- サービスデスクチームは、関連インシデントの解決に使用された回避策を記録します。これらの回避策は、サービスデスクが完全に問題を解決するまでサービスの中断を低減します。
- サービスデスクチームは既知のエラーをナレッジベースに追加します。これらには、関連インシデントの症状および関連回避策が含まれます。
- サービスデスクチームは、問題を解決するためにインフラストラクチャーに変更を加えることを提案します。
- サービスデスクは問題をクローズします。
チームメンバーは重大な問題について綿密なレビューを実施してください。
JiraService Desk の既定の問題ワークフロー
サービスデスクエージェントは問題課題タイプを使用して課題を作成できます。これにより、推奨される問題ワークフローに問題レコードが配置されます。
このワークフローは上記の基本プロセスに従います。ワークフローは、ビジネスのニーズに合うようにカスタマイズできます。
問題ワークフローのカスタマイズ
- In your service project, select Project settings ( ) > Workflows.
- Jira Service Desk 用の問題管理ワークフローというタイトルの項目で、編集アイコン (鉛筆) を選択します。
- ワークフロー エディターを使用して、ステップとトランジションを追加または編集します。
既知のエラーをリンク済みの Confluence ナレッジベースにドキュメント化する
Create a restricted section of your Confluence knowledge base that holds known error records. Agents can quickly find and execute workarounds for future incidents. This:
- サービスを迅速に回復
- 取り組みの重複を削減
- 未承認または危険な回避策の回避
- その他
既知のエラーのレコードは問題とその根本原因を定義します。これらのレコードは関連するインシデントの既知の症状を収集します。レコードには回避策とそのステータス (一時的または恒久的) が詳述されます。
以下の例は、既知のエラーのレコードです。
Confluence でのナレッジベースの作成について詳細を読む。
問題レポートの既定のフォームフィールド
Jira Service Desk を使用することで、カスタマーから収集した情報のフィールドをカスタマイズできます。さらに、エージェントが使用する情報のフィールドもカスタマイズできます。Jira Service Desk は課題タイプのフィールドと画面を通じてこれを実行します。エージェントは、報告書作成または照会のためにフィールドを利用して問題の調査、評価、および分類を行うことができます。
既定では、エージェントの問題のビューには次のフィールドが含まれます。必要に応じてカスタムフィールドを追加できます。Jira のフィールドについて詳細を読む。
フィールド名 | 説明 |
---|---|
要約 | リクエストの短い説明。 |
報告者 | リクエストの送信者。 |
コンポーネント | リクエストに関連する IT インフラストラクチャのセグメント。たとえば、"請求サービス" または "VPN サーバー" などです。これらはラベル付け、分類、およびレポートに使用されます。 |
添付ファイル | リクエストに追加されるファイルまたは画像。 |
説明 | リクエストの長く詳細な説明。 |
リンクされた課題 | A list of other requests that affect or are affected by the request. If your business uses other Atlassian products, this list may include linked development issues. |
担当者 | リクエストの作業に割り当てられているチーム メンバー。 |
Priority | リクエストの解決状況の重要性は通常、ビジネスのニーズと目標に関係しています。優先度が影響と緊急性によって計算されることもあります。 |
ラベル | レコードの分類またはクエリに使用される追加カスタム ラベルのリスト。 |
リクエスト参加者 | リクエストに参加している追加のカスタマー (他のチームやベンダーの人々など) のリスト。参加者について詳細を読む。 |
承認者 | リクエストを承認する責任を持つユーザーの一覧。通常は、ビジネス、財務、または技術担当者。 |
組織 | リクエストの解決状況に関心のあるカスタマー グループのリスト。Jira Service Desk 内の組織に関する詳細はこちらをお読みください。 |
影響 | 問題の影響。通常は、サービスレベルアグリーメントに関連。 |
緊急性 | ビジネスに問題の影響が感じられる前に利用可能な時間。 |
ソース | 問題が発生した資産またはシステム。 |
調査理由 | 調査を要求するためのトリガー。たとえば、インシデントの再発、非ルーチンインシデントなど。 |
保留理由 | 問題が進行していない理由を示す短い説明またはコード。 |
製品分類 | リクエストが影響する IT 資産またはシステムのカテゴリ。 |
操作分類 | リクエストを遂行するために必要なアクションまたは機能の分類。 |
根本原因 | 問題に関連するインシデントの元の原因。 |
回避策 | サービスを回復するための一時的な、既知の解決策の詳細な説明。Confluence を所有している場合、ご使用のナレッジベースに回避方法をドキュメント化することをお勧めします。 |
IT サービス管理 (ITSM) について
ITSM を成功させるために多くのヒントやコツを参照し、ワンランク上のサービス デスクを実現する方法を習得しましょう。「IT アンプラグドの ITSM リソース」を参照してください。