A Closer Look at How Problem Managers Measure Performance

アナリストやエンジニアがどのように問題に取り組み、根本的な原因を見つけ、適切な行動でフォローアップするかを理解することは、簡単なことのように聞こえます。ITIL Problem Managementを文書化するためのアプリケーションにアクセスすれば、ケースの内容を読むことができます。ケース管理ツールへのアクセスと、そのツールを使用するためのスキルがあればよいようです。

However, asking Problem Managers how they handle problems will typically uncover the true procedures that describe what steps they take when finding and working on problems. These documented processes and procedures are very helpful when expectations are very clearly set on the steps to be taken to progress problems that require attention.

Reading problem tickets or asking Problem Managers how they fill in the steps in the procedures seems a logical next step to find out more about how value is created in Problem Management. This is where information is really gathered, data is analyzed and conclusions are drawn. So, how does the performance of Problem Management get measured? Many organizations seem to measure timing-related parameters around the problems, or counting the number of problem tickets, in a given state. Examples include:

  • アプリケーションのグループごとの未解決の問題チケット(バックログ)の数、時系列で検討
  • 未解決の問題チケットの平均年齢、時間経過とともに考慮されることが多い
  • 問題チケットの根本原因を見つけるための平均時間
  • 繰り返し発生する問題の数

Considering the goals of Problem Management: to find causes of problems and proactively take actions to avoid future incidents and problems, how well do the examples above tell how successful a team is towards achieving these goals? Are we asking for one thing and measuring something completely different?


About two days into an assessment of how Problem Management was being handled in a global IT department of a worldwide company, we decided to take a break to compare our findings amongst the participants in the assessment. Fields that were considered for inspection included the ticket summary and problem description, as well as individual progress updates and the resolution descriptions.

The pattern was seen in most problem tickets. The summary was clearly indicating the affected application or hardware and what was wrong with it, followed by some underlying data in the detailed problem description. Further updates would typically indicate how the problem was traveling through the procedural steps of Problem Management as time was progressing and reaching a conclusion in the resolution description.

Although this seems like an individual case, it represents the pattern that was seen amongst the team doing the assessment. After talking through other experiences, the following picture was made to represent the observations seen


  • 原因究明を効率的に行うためには、どのようなデータを集めればよいのでしょうか。
  • 適切な時期に適切なデータを収集したことを確認するにはどうすればよいのでしょうか。
  • そのマジックはどのようなものか?どんな文書化されていない手順を踏んだか?どのような文書化されていない思考が行われたのか?
  • 他にどのような原因が考えられますか?
  • What level of confidence did the resolving team have that found the cause really was the “true cause”?
  • 問題を解決するために行った行動が、どのような副作用を引き起こす可能性がありますか?


In our next blog, learn what “magic” is really all about. Finding stability after recurring problems and realizing that there is no common way to handle a single problem will reveal exactly how Problem Management “magic” is performed.

Measuring Problem Management Quality in an ITIL Environment, Part 2
Measuring Problem Management Quality in an ITIL Environment, Part 4