チャレンジ：
ビジネスによって表明された目標を技術サポートユニットに結び付け、パフォーマーの理解、彼らが達成にどのように影響するかを理解する。
初期設定と簡略化：
- 内部カスタマーサポートを検討します。
- アプリケーションの状態は、オブジェクトの実際の状態の変化と同時に瞬時に変化すると考えています（つまり、回覧の登録時間=必要性の発生時間、回覧の終了時間=必要なアクションの完了時間）。
- 詳細を巻き上げないようにしてください。
タスクを実装するには、タスクの優先順位（解決の順序）を意識的に「誘導」できる基準に基づいて基準を特定し、これらの基準を評価するためのルールを決定する必要があります。
正当化（理論）：
このビジネスの目標は、インシデントおよび時間どおりに完了しないサービスリクエストによる損失を最小限に抑えることです。
ターゲットインジケータに影響するものを判断してみましょう。
この理論的研究に近づき、彼らの成果を処理してみてください。
なぜなら 損失率各アプリケーションの値は一定と見なすことができます。その後、損失を減らすためのサポートユニットのレベルでは、アプリケーションの期間のみを管理できます。つまり、ビジネスで最も高価なアプリケーションを最初に完了することができます。
優先順位付けの支援方法または損失率Cの評価方法：
絶対的に言えば、タスクは解除されません（はい、特に必要ではありません）。そのため、見積もりを使用するオプションが提案されます。
さらに、アスペクト比自体の値についてはあまり心配しません。 この値を定数と見なし、損失から推定に渡すことが可能になります（O）：
このOiスコアをどうしますか？ 損失が実際に依存する、より理解しやすく評価しやすいパラメーターに分解します。
実際、損失のコストを評価することによって、それだけです。 その結果、理解できないコストが専門家による評価の「よく知られた」スキームに削減されました。
パラメータの例（一部はITILから取得）：
- 影響の度合いは、基本オブジェクト/サービスでの通常の機能からの損失の度合いです。
- 損失の重大度は、問題による1つの基本オブジェクト/サービスでの損失の大きさの相対的な推定値です。
- 問題の規模は、問題の影響を受ける基本オブジェクトの定量的評価です。
さらに、これらのパラメータの重みは実験的に決定されると言う価値があります。 しかし、最終的に優先コールのリストを取得します。
まとめ
損失を減らすためのクライアント/スポンサーの目標は、サポート部門の従業員によって影響を受ける可能性のある見慣れた指標に変換されます。
- 労働時間;
- 作業指示書。
推論の過程で新しいものは何も発明されなかったように見えますが、従業員がこの推論の道筋をたどると、彼の世界観「なぜこれがすべてなのか」と「そのようなものがすべてなのか」が劇的に変わります。
また、前述の方法を使用して、アプリケーションの優先順位付けを自動化できます。
概説した考えが役に立つことを願っています。