問題管理でいう「問題」は、管理する側が意図的に認め、識別する事ではじめて発生する。例えばサーバの障害などにおいて、ある症状のインシデントを繰り返す、という事象が発生した場合、個々の暫定的な対応としてはサーバの再起動などで可能であっても、根本的な解決には至っていない。臨時復旧によるサービスの中断は防ぐ事が出来ても、中長期的な観点で見ると、根本的な対策を行わない限り復旧作業などのコストがかさみ、大きな損失として計上されてしまう。
問題管理はインシデントに対しての問題点を認め、識別し、原因の調査と恒久的な対策を実施していき、インシデントの再発防止に努めるITサービスの品質を高めていく為のプロセスである。ただし、ITILでの問題管理の範疇としては問題点の解決策の提示までであり、それ以降の実際の対策実施の為の変更作業などは変更管理プロセスにてコントロールされる。
上述の通り、問題管理の目的は恒久対策であり、目的達成の為、以下の達成目標を掲げている。

• エラーに基づくインシデントの再発防止
• 資産利用の生産性向上
• 予防的な問題管理の実施

問題の発生から収束までを問題コントロールと呼び、特に問題の切り分け後から変更管理を経て解決に向かうまでのプロセスをエラー・コントロールと呼ぶ。問題管理では発生から収束まで大きく9つのプロセスに分けて管理・コントロールを行う事が推奨されている。

1～3を問題コントロール
4～6をエラーコントロールと呼ぶ

【 KEDB 】
Known Error DataBaseの略で既知のエラー情報を蓄積したデータベース。

原因がわかっている問題を既知の誤りといい、新たにわかった原因については解決のためにシステムの変更が必要であれば、変更要求(RFC:Request For Change)を行う必要がある。