多くの場合、プロセスサービスの義務において、大小のIT部門の従業員から非常に人気のある質問を1つ聞きます。
このトピックに関する議論は古く、すべてのIT管理方法論がまとめられているため、主な情報源を取り上げます。
ITIL（第3バージョンによる用語集の公式翻訳）が私たちに伝えること：
サービスリクエスト-ITサービスへのアクセス、情報、アドバイス、または標準的な変更を求めるユーザーのリクエスト。
インシデント -ITサービスの計画外の中断またはITサービスの品質の低下。
いつものように、この方法論は深く掘り下げておらず、ユーザーリクエストを分類するサービスデスクの従業員の実質的な質問に答えることを本当に好みません。 その間、たくさんの質問があります、ここにいくつかの例があります：
1）パスワードのリセットを求めるユーザーの洗礼式の呼び出し-サービスリクエストまたはインシデントとしてパスワードを分類する方法 それとも情報セキュリティインシデントとして？
2）企業メールを持たないユーザーからの呼び出し。 アピールの簡単な分析は、ユーザーがメールクライアントの初期構成を実行する必要があることを示唆しています。 それにもかかわらず、彼の観点から、これは事件です。 このサービスは利用できず、「メール自体が飛ぶことはありません」と通知した人はいません
言うまでもなく、一次分類は非常に重要です。 と締め切り。
この問題についての私の理解は、エンドユーザーのサービス中断を評価するという問題に帰着します。
インシデントは、ほとんどの場合、以前に承認済みモードでユーザーに提供されていたITサービスの中断または部分的な中断です（サービスは24/7、または5/8で利用可能です）。
例：会社の主席会計士が突然財務報告システムへのアクセスを失いました。 一方では、アクセスの提供は古典的なサービス要求ですが、この場合、サービスの明確な中断があり、その結果、ビジネスプロセスが部分的に低下します。
サービスリクエストは、追加のサービスを接続するか、既存のサービスの機能を改善することに関心があるユーザーからのアピールです。
例：特に好奇心の強いユーザーが同じ財務報告システムのモジュールの1つを開こうとしましたが、エラーメッセージを受け取りました。 彼のt.z これはインシデントです。なぜなら、彼は望んだ目標を達成できず、求めていた情報を受け取っていないからです。 上記の説明は、アクセスを提供するための古典的なサービスリクエストであり、承認を必要とし、合意された時間に標準手順に従って実行されます。
同時に、一般的に分類するのが難しいさまざまな特殊なケースを忘れてはなりません。上記の観点は定説のふりをするのではなく、誤って分類された呼び出しの数を最小限に抑え、ビジネスニーズに対する全体的なIT応答時間を改善するように努めます。
このトピックに関する考えを共有してください。
参照：
1. ITIL用語集v.3の公式翻訳