インシデント管理の主な目標は、可能な限り迅速にサービスを復元することです。これは、シャベルで森林火災を消そうとするようなものになる場合があります。 単一の丘で発火を消したので、一般的な災害をなくすことはできませんが、発火の領域全体を消したので、次のシーズンまたは翌日でさえ新しい発生の出現の問題を解決しません。 火災の原因に対処する必要があります、それが観光客であり、動揺（訓練）を行う必要があるか、沼地の干上がった森林であり、その清掃（近代化）を実行する必要があるかどうかです。
または、たとえば、いくつかのトレイを備えたプリンターで印刷する場合、1つのトレイから紙詰まりが発生すると、インシデント管理内でトレイが変更されるため、一時的に紙詰まりの問題がなくなります。 そして、この状況は数日間繰り返され、ユーザーに不便をもたらし、ITプロフェッショナルの注意をそらしました。 この例では、Problem Manegementは、原因が給紙ローラーの摩耗であり、ローラーを交換した後、プリンターが正常に動作し始めたことを示しました。
もっと深く！
理論のビット
ITILによると、問題は1つ以上のインシデントの未知の原因です。 必要なものだけ！
したがって、問題管理の主なタスクを見ると、問題の発生を防ぐために、再発するインシデントの発生を排除し、防止できないインシデントの影響を最小限に抑えることができます。
ビジネスの観点から問題を管理する必要があるのはなぜですか？おそらく、これは、ITサービスの可用性の向上、ITを含む人員の生産性の向上、繰り返し発生するインシデントがないためのコスト削減です。
ここでは、事後対応型の問題管理、つまり問題が検出されたという事実への対応について検討します。
実装に移りましょう
-何、問題？
問題をどのように探していますか？ ここでは、監視ツール、ServiceDesk、インシデント、サプライヤからのデータ、またはプロアクティブな問題管理からのデータによって支援されます
私たちが本当にエージェントインターフェースで問題に直面していることが明らかになったとき、OTRSのadmin部分で多くの操作を行う必要がありました。
問題を登録するには、アプリケーションタイプの問題をアクティブにする必要があります。
次に、ユーザーに対してアプリケーションの種類を非表示にする必要があります。
チケット->フロントエンド::顧客::チケット:: ViewNewパラメータの設定チケット::フロントエンド:: CustomerTicketMessage ### TicketType-いいえ
したがって、ユーザーのタスクを簡素化し、ServiceDeskのタスクを複雑にします。
エージェントインターフェイスをアンロードするには、キュー「Problem Queue」を入力します。 現在、すべての問題は、別のタブでこれを実行できるエージェントのみが利用できます。
この場合、アプリケーションの説明をServiceDeskに割り当てるか、問題の説明の場合はProblem Managerに割り当てます。 つまり、「問題のキュー」にエージェントの権利を追加します
分類
順番に分類することもできますが、サービスの分類に焦点を合わせることにしました。 分類はインシデント管理と同じである必要があります。これにより、プレゼンテーションがより便利になり、インシデント管理と一緒に詳細な説明が行われます。
右側のウィンドウの[アプリケーション情報]には、サービス、SLA、SLAに基づくアプリケーションの決定時刻に関する情報が含まれています。
下部には、この問題に関連するインシデントが表示されます。ConfigItemも添付されています。つまり、この問題のコンテキストで作業しているプリンターです。リンクをクリックすると、追加情報が表示されます。
優先順位
レベル5。主要な問題-原則として即時の解決が必要-これらは、トップマネジメントに影響する問題、または多数のユーザーに影響する問題です。
レベル2-4 他のすべての問題
レベル1。少数のユーザーに影響。
理由を検索する
これが作業の始まりです。 問題の原因を特定する必要があります。
実行されたすべての作業はメモを通じて記録され、問題ログを補充します。このログは、ITサービスの従業員の有効性について話し、同様の問題が発生したときに役立ちます。 また、作業に費やした時間も記録します。 問題の合計時間は、すべてのノートの時間から合計されます。
運が良ければ、理由を特定したら、エージェントインターフェースに移動して説明します。
すべての問題の原因をグローバルに分析するための理由コードを提供し、必要に応じて説明を追加する必要があります。
問題の原因がまだ見つかっていないが、回避策が見つかった場合は、新しいインシデントを解決する時間を増やすためにそれを修正する必要があります。 ITILの場合、既知のエラーレコードを作成することをお勧めします。 ただし、クレームの種類をProblemからProblem.Known Errorに変更します。
繰り返しますが、いくつかの操作、つまり、アプリケーションに必要なフィールドとその値を追加しています。
これらの設定は、バージョン3.2 OTRSで登場した改訂された機能であるDynamicField（Dynamic Fields）によって回答されます。
原因（ドロップダウン）、原因の説明（TextArea）、回避策（TextArea）のフィールドが必要です。
すべてのフィールドを英語で記述し、/ opt / otrs / Kernel / Language /フォルダーにあるru.pmファイルを使用して翻訳します
ドロップダウンフィールドに、事前定義された値を設定します
設定チケットに追加->フロントエンド::エージェント::チケット:: ViewAddtlITSMField
これは、エージェントインターフェースでの表示です。
解決策
問題の解決策が見つかったら、そのステータスを「正常に閉じました」に変更して、問題を正式に閉じる必要があります。
報告
管理報告
- 特定の期間に記録された問題の数。
- レポート期間の問題を解決するためのコスト
- 優先度5の問題の割合
問題マネージャーの報告
- 特定の期間の問題の原因、サービス別、タイプCI別。
PSバージョン3.2では、WorkFlowを使用してアプリケーションを管理できるProcessManagmentという新機能が登場しました。そのため、フルフィルメントプロセスに戻る必要があります。