ITILの長い歴史の中で 、Service Deskは多くの企業によって実装されてきました。 誰かが既製のツールに依存し、誰かが自分の道を進んだ。 誰かが最初にそれをやったが、誰かが「詰め物をした」。 後者の経験は、Service Deskの実装で最も一般的なエラーのリストを作成するのに役立ちました-些細で簡単に修正できるものから、非常に深刻なものまで、この記事で共有します。
/ウィキメディア/ アンソニー・デロレンツォ / CC
1.独立した実装
Flycast Partnersの上級ITサービスコンサルタントであるLinda Kirkpatrickは、300を超えるさまざまな企業と協力しており、多くのクライアントはITSMツールを実装する準備ができていなかったと主張しています。 または、彼女の言葉で、「ITSMを実装する準備ができていない会社と仕事をするたびに4分の1ドルを与えられたら、今では自分で上級ITサービス管理コンサルタントを雇うことができます。」
企業は、サードパーティパートナーが他のプロセスとは別にService Deskを展開することを望んでいます。 その結果、組織はITILと矛盾するアプローチを取ります。サービスに焦点を合わせるのではなく、調整されていないアクションを実行する異種サービスが表示されます。
解決策。 ITSMツールのサプライヤと緊密に連携し、組織で何が起こっているのかを全体的に把握することが重要です。 サービスデスクの実装は、それ自体が目的ではなく、サービスを継続的に改善する計画の一部であるべきです。 これを行うには、プロジェクトチームは会社の従業員と協力する必要があり、従業員は新しいポリシーとツールを理解するだけでなく、サービスを提供するプロセス全体がどのように編成されるかを理解する必要があります。 したがって、すべてのサービスの開発は単一のコースに沿って進み、相乗効果とツールの調整された作業を提供します。
2.時間の無駄「従業員との戦争」
Service Deskの実装は、職場文化の面で組織に大きな変化をもたらしています。 スタッフは常にこれらの変更を簡単に受けられるとは限りません。 サービスアプローチを意味するITILの原則は、誰にとっても明確ではありません。 これの確認はRedditでの議論であり、ヘルプデスクのヘッドは部下について不満を述べました。彼らは学習したり、主導権を握ったり、助言を求めたりする意欲はありません。
プロフェッショナルなサービスデスクシステムに切り替えると、従業員から懐疑的な見方がされる場合があります。 これはEuroJamイベントの主催者で起こりました-サポートサービスのボランティアは新しいツールを使いたくありませんでした。
このような状況で従業員の抵抗に対応する方法はいくつかあります。たとえば、Service Deskのメリットを部下に無視する、強制的に導入する、または説得するなどです。 原則として、最初の2つの方法は肯定的な結果をもたらしません。技術的にはサービスデスクが実装されますが、実際には人々は革新に抵抗し続けます。 従業員の意見が考慮されない場合、協調作業は機能しません。
EuroJamの場合、イノベーションは徐々に導入され、イベントの特性を考慮に入れたという事実によって問題が解決されました。経営陣はプロセス全体を「理想的に」構築する必要がありませんでした。 これにより、実装プロセスを簡素化することも可能になりました。いくつかの単純なステップの形の変更を想像し、それらを組織の特性に適応させると、プロセスが正常に完了する可能性が高くなります。 たとえば、イベント終了時のEuroJamボランティアは、文字通り「サービスデスクエバンジェリスト」になりました。
解決策 。 従業員は新しいものを受け入れません。なぜなら、従業員はその中に自分自身の価値を見ないからです。 新しいサポートチームがパフォーマンスを改善する方法を説明することが重要です。 既存の問題を指摘し、Service Deskがそれらを解決し、チーム全体の生活を楽にする方法を示します。
3.従業員の不均等な負荷
インシデント管理はチケットシステムに直接依存しています。 チケットの主なタスクは、すべての着信リクエストを管理することです。 IT部門は通常、多数の要求を処理するため、生成から解決まで、個々の要求のライフサイクルを管理するシステムが必要です。 効果的なチケットシステムにより、すべての問題をタイムリーに解決できます。 また、将来の使用に備えてすべての情報が単一のセンターに保存されるため、部門の作業も容易になります。
チケットシステムが十分に構築されていない場合に起こることは、WordPressのプラグインの開発者であるWarfare Pluginsの経験を示しています。 同社は、ユーザーからの質問に対応するインシデント管理システムを立ち上げました。 チームのすべてのメンバーが単純なリクエストに対応でき、複雑なリクエストを担当したのは1人だけでした。
彼はしばらく離れなければならなかった。 彼が戻ったとき、彼は膨大な数の蓄積されたチケットを見つけました。 その結果、従業員は1か月かけて状況を修正しました。 これは、1つのリクエストの平均処理率と間接的に製品の品質に影響しました。チケットは、プラグインの欠点を指していたため、排除する必要がありました。
/ウィキメディア/ アクセルボルト / CC
解決策。 メールボックスを分解した後、チームは新しいルールを導入しました。週末でも、1〜2時間以内に問題を解決します。 これは当たり前のことのように思えるかもしれませんが、実装段階でも、明確なKPIを設定する必要があり、その中にチケット処理時間が必要です。 インシデントの解決が1人に依存せず、ワークロードの量が部門の能力に対応するように、有能な従業員間で要求の有能な分散を構築することも必要です。
4.権力の分配における論理の欠如
ITIL は 、サービス指向システムの各チームと個々の従業員が理解できる一連の責任と権限を持っていると想定しています。 Service Deskの実装段階では、責任ある役割を正しく割り当てることが重要です。 ITSMでは、役割と責任の領域を組み合わせることができますが、従業員の能力を考慮することが重要です。
これの重要性は非常に明白であり、例えばニュアンスは、金沢大学（日本）の研究者によって書かれており 、上海Wicresoftの中国人の同僚とともに、アジア企業でのサービスデスクの実装を研究しました。 彼らは、Service Deskの完全な実装の前に、独自のインシデント管理システムのプロトタイプが使用されていた中国の組織の1つの事例研究を提供します。
コンピテンシーと責任分野の理解が不足していたため、サポートサービスから資格のあるエンジニアに簡単なリクエストが送信されました。 問題は、「安価な」および「単純な」質問の解決が、中核的な責任から脱却しなければならなかった「高価な」専門家の時間を無駄にすることでした。
この決定には、専門の専門家からの時間の解放だけでなく、他の関連指標の増加も伴いました：VIPクライアントの満足度（より資格のある従業員が処理すべきでした）は60％から90％に増加し、知識ベースはより効率的に使用され始め、減少しました要求処理時間。 混乱から秩序を回復するためだけに追加の部隊を引き付けなければならず、「サービスデスクの再構築」プロセス全体に6か月かかりました。
解決策。 実装段階での複雑さとフォーカスによる要求の自動ソートの導入により、チームのワークロードの問題が解決されます。 自動化された監視ツールにより、複雑さに関係なく、すべてのリクエストが確実に処理されます。 また、ナレッジベースを作成すると、技術的な質問に対する回答を蓄積し、必要な専門家が職場にいなくても、従業員が通常モードで簡単な問題を解決できるようにします。
もちろん、これらは、企業がサービスデスクを実装するときに直面する問題のすべてではありません。 しかし、それらは最も「人気のある」ものの1つであり、さらなる困難を伴います。 したがって、ここでかつてないほど、「他人の過ちから学び」、イベントの発展のための同様のオプションを予測する機会は、これまで以上に重要になっています。
当社のブログからの追加の関連ソース：