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

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

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

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

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

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

「問題管理」の「問題」とは、「発生したインシデントから問題となるもの」、また「運用中、サービス提供に影響を及ぼす可能性がある問題」と定義しました。
要求事項は、「インシデント管理」と同じようなことが要求されており、「問題」と判断したら、その問題を解決するための手順（記録、分類、更新、エスカレーション、解決、クローズ）を備えることが求められています。
この要求事項のポイントとしては、「問題」の判断方法を決定することです。
なぜならば、この判断が曖昧だと、「問題管理」がいつまでも発動せず、あやふやな状態で運用されてしまうからです。
「問題」の判断方法については、例をあげると「運用のチームリーダが問題と判断する」や「運用会議の中で運用状況を報告し、なにか不具合がったらそれを問題と判断する」といったことです。
日常業務の中で実施されている「運用の問題点をあげ、対策を考えていく活動」をもとに判断していく必要があります。
または、この「問題管理」の要求事項を見ていくと、ISO9001やISO27001の「是正処置」/「予防処置」と同じようなことが要求されております。
いくつか考慮しなければならない点はありますが、ISO9001やISO27001を既に取得している企業であれば、ISO20000の「問題管理」をISO9001/ISO27001の「是正処置」/「予防処置」で実現することも可能でしょう。
特に注意していただきたい点は、「是正処置」/「予防処置」の対象が、あくまでマネジメントシステムに対する不適合のみを対象としている場合です。
ISO20000の「問題管理」は、サービス提供にあたっての問題を管理する要求事項であり、企業によっては、「是正処置」/「予防処置」の動きと異なる可能性があります。
その場合、実際の運用に合わず、業務効率に影響が出てしまう可能性があります。
実運用にあった実現方法を定義するには、冒頭にもありましたとおり、まずは、皆様の実際の活動を見返していただき、運用業務にあった実現方法を検討ください。