問題管理
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/02/22 03:14 UTC 版)
問題管理でいう「問題」は、管理する側が意図的に認め、識別する事ではじめて発生する。例えばサーバの障害などにおいて、ある症状のインシデントを繰り返す、という事象が発生した場合、個々の暫定的な対応としてはプロセスの再起動などで可能であっても、根本的な解決には至っていない。臨時復旧によるサービスの中断は防ぐ事が出来ても、中長期的な観点で見ると、根本的な対策を行わない限り復旧作業などのコストが嵩み、大きな損失として計上されてしまう。 問題管理はインシデントに対しての問題点を認め、識別し、原因の調査と恒久的な対策を実施していき、インシデントの再発防止に努めるITサービスの品質を高めていく為のプロセスである。ただし、ITILでの問題管理の範疇としては問題点の解決策の提示までであり、それ以降の実際の対策実施の為の変更作業などは変更管理プロセスにてコントロールされる。 上述の通り、問題管理の目的は恒久対策であり、目的達成の為、以下の達成目標を掲げている。 エラーに基づくインシデントの再発防止 資産利用の生産性向上 予防的な問題管理の実施 問題の発生から収束までを問題コントロールと呼び、特に問題の切り分け後から変更管理を経て解決に向かうまでのプロセスをエラー・コントロールと呼ぶ。問題管理では発生から収束まで大きく9つのプロセスに分けて管理・コントロールを行う事が推奨されている。 Noプロセス内容概要1 問題の識別と記録 インシデントレコードを元に問題レコードを起票する。 2 問題の分類 問題を分類し、カテゴリ、緊急度、影響度、優先度を設定する。 3 問題の調査と診断 問題分析手法を用いて問題発生となった原因の調査を行う。 4 エラーの識別と記録 発生していたエラーを識別し、KEDBに記録する。 5 エラーの評価 エラー内容を調査し、恒久的な解決策を検討・立案する。 6 エラーの解決策を記録 現象の発生する条件などとともに解決策をKEDBに記録する。 7 変更要求（RFC） エラー対策の為、変更管理プロセスにシステム変更の要求を行う。 8 問題解決の進捗監視 変更管理プロセスを経た解決策に対し、リリース管理プロセスが行う実際の変更作業を監視する。 9 問題のクローズ リリース管理プロセスを経た解決策をレビューし、問題をクローズする。
※この「問題管理」の解説は、「サービスサポート」の解説の一部です。
「問題管理」を含む「サービスサポート」の記事については、「サービスサポート」の概要を参照ください。
- 問題管理のページへのリンク
