ITに複数のエンジニアがいる場合、ユーザーがそれらを直接呼び出す状況に遭遇する可能性があります。 それはヴァシャの呼びかけです Vasyaはすべてを迅速に行いますが、Petyaは最後の2時間も失敗し、実際にはすべてを修正しませんでした。
このような専門家への直接の電話は、次のマイナスの結果につながります。
コールで作業を行う場合、エンジニアは多くの場合、コールに関する情報を入力しません（特に、削除に10分もかからなかった場合）。 熟練したエンジニアはより過負荷/過負荷です ユーザーは自分とのみ通信したい。
経験の少ないエンジニアは押し込まれ、経験を得るのに時間がかかります。 ユーザーがエンジニアに連絡しなかった場合、IT部門で誰も電話をかけないことを管理者に報告します。 同時に、彼は他のエンジニアに連絡しようとはしません。
その結果、何が起こっているのか、ユーザーからどのようなリクエストが来ているのか、スペシャリストがどれだけ負荷がかかっているのか、実際の状況はわかりません。 「盲点」が表示されるため、不適切な管理上の決定を下すことができます。
たとえば、リモートオフィスには、フルタイムのエンジニアがいます。 統計によると、彼は週に1〜2件の応募があります。 それを外部委託することにしました。 人はカットされています。 そして、結局のところ、彼は何日もの間、ユーザー間で実行したことを実行し、常に何かを修復して調整したことがわかりました。 報告する時間がありませんでした。
直接電話する場合のもう1つのマイナス点は、人が配置されていない可能性があることです。 彼は休暇中、病気休暇中です。 ユーザーは電話をかけますが、誰も答えません。
この場合、単一のアクセスポイントの役割は個別の番号であり、すべてのユーザーに何度も表明されています。 部門には人事異動があり、インフラストラクチャが変化し、順番に電話をかけるシステムが交換され、交換が置き換えられました。 ただし、ユーザーにとっては、コンピューターに問題が発生した場合に電話する番号が常に1つありました。
単一の非個人的なメールボックスも開かれ、すべてのユーザーがそこに呼び出しを送信する必要があります。 あらゆる方法で、ユーザーが電話をかけずに書く方が良いことを強調します。 メールでの作業がより簡単になりました。アプリケーションの入力フィールドを少なくし、より速く処理でき、用語がより正確に計算されます。
上記に基づいて、ServiceDeskサービスを構築する場合、単一のエントリポイントが必要です。 すべてのユーザーリクエストは（送信方法に関係なく）1か所にまとめる必要があります。 情報伝送チャネルごとに、1つのポイントのみが存在する必要があります。 つまり、電話が1つの電話番号しかない場合です。 メールが1つの住所のみである場合。 スカイプの場合、コールを受信するための共通アカウントは1つだけです。
さらに、IT部門自体が通話のルーティングと手紙の流通を設定します。
呼び出し用の単一ポイントを作成したら、次のステップは、すべてのアプリケーションの単一データベースを作成することです。 なぜなら 1つの番号への呼び出しと1つのメールボックス内のすべての呼び出しは適切ですが、それらを操作する必要があります。 分析を行い、問題のある領域を探すなど。
ベースのビューは実際には重要ではありません。 Excelファイル、1Cベース、自作ソリューションのいずれでもかまいません。 しかし、それはあなたのニーズに合うはずです。 便利な形式で情報を保存できるようにするには、必要なレポートを提供してください。
アプリケーションに必要なもの：
-アプリケーション番号（その一意の識別子）
-イニシエーター
-控訴の日付
-連絡先
-クリティカル
-サービス
これは、エンジニアがアプリケーションの作業を開始するために最低限必要なことです。 さらに、彼はすでに必要なコメントを入力し、追加情報を要求し、最終的にアプリケーションを閉じます。
私たちの実践では、ユーザーの1人が別の会社からまったく異なるメールに手紙を送り、IT部門が彼を無視していると不満を言うケースがありました。 理解せずに、ユーザーは経営陣に苦情を申し立て、議事の結果に続いて、ユーザーは問題が発生した場合に電話をかけ、書く場所について再び会話しました。
要約すると、単一のエントリポイントは、通信の問題の数を減らすのに役立ち、通話の全体像を把握できるようになります。 この情報に基づいて、管理上の決定を下すことはすでに可能です。