テクニカルサポートの品質の測定方法

そして、それが何をもたらし、何をもたらさなかったのか...

シリーズ「ITクラウド（コンピュータースペシャリスト）」からのショット



テクニカルサポートは何をし、どの程度効率的に機能しますか？ -仕事でのテクニカルサポートのタスクから離れるほど、この質問は2013年まで気になり、これらの「ローファー」が何をしているのかわからないことに気づきました。 いいえ、テクニカルサポートの担当者が作業に責任を持っていることは疑いませんでした（これはお客様のレビューで確認されました）が、当社のサービス品質が時間の経過とともに改善するか、低下するか、テクニカルサポートで発生するタスクと量、ライオンの仕事の分担-私はこれを理解していませんでした。 この記事は、技術サポートの状況を理解しようとする私の試みに専念しています。 しかし、最初に、歴史への少しの余談：

技術サポートの品質が世界でどのように測定されているのか、そしてこの方法が私に合わなかった理由

私が直面している問題は新しいものではありません。 30年前、英国人も同じ質問をしました。「実際、州の機関のITスペシャリストとは何ですか？ 英国はこの問題に根本的に取り組み、調査を実施しました。その結果、ITサービスの効果的な作業とその作業を監視する方法を整理するための推奨事項が30（30）冊になりました。 時間の経過とともに、これらの推奨事項は5巻に減少し、「ITIL方法論」という名前で世界的に名声を得ました。 方法論の本質は、スペシャリストに狭い責任範囲を割り当てることに限定されています：ディスパッチャはアプリケーションを登録し、テクニカルサポートには1行目、2行目、3行目があり、インシデント管理者、問題管理者、変更管理者、構成管理者などがあり、さまざまな役割のリストを継続できます。 このような狭い役割のカットは、一方では個々の専門家のタスクを制限し（したがって、彼の仕事を簡素化し、個人の生産性を高めます）、他方では、IT部門が一部の専門家のような全役割会計システムなしで作業することを不可能にしましたコンベアは他の人にタスクを転送できます。 専門家の雇用を管理し、IT部門全体および特に個々の従業員のさまざまなパフォーマンスメトリックを測定するのに役立つ会計システム（イギリス人が誇りに思っているServiceDeskと呼んでいます）を使用する必要があります。



30年前に英国が提案した技術には唯一の欠点があります。専門家が顧客の問題を解決するのではなく、作業手順を実行することを目的としています。 グローバルに、方法論はクライアント指向ではなくプロセス指向であり、そこで提案された労働を組織化する方法の欠如は、アルカディ・ライキンのミニチュア「 誰が訴訟を起こしたのか？ 」 たとえば、ITIL方法論によれば、ユーザーはスペシャリストと直接通信することはできませんが、まずシステムにアピールを登録し、スペシャリストに転送してさらなる実行を監視するディスパッチャーを経由する必要があります。 この合併症には合理的な粒度が含まれています-アプリケーションの登録が技術専門家自身に渡される場合、この儀式はユーザーまたは技術専門家のいずれでも必要ないため、一部のリクエストは単に登録されません。



原則として、ITIL方法論のすべての欠点は、派遣者、管理者、および直接、技術サポートスペシャリストのスタッフをサポートするのに十分なお金があり、またユーザーがどこにも行かないことが確実な場合にはそうではありません。 しかし、私には小さなITアウトソーシング会社があり、すべての技術サポートは10人の専門家です。 （マネージャーは言うまでもなく）専用のディスパッチャを維持することは容認できない贅沢です。 さらに、お客様は質問に対して迅速かつ適切な回答を受け取ることに慣れています。 テクニカルサポートに電話するときにディスパッチャの応答を謙虚に待つようにユーザーに命令し、彼が最初にアプリケーションを登録してからスペシャリストに渡すと、6か月でかなりの数の顧客を失う可能性があります。 したがって、私に残った唯一のことは、テクニカルサポートスペシャリストに、例外なく、受信したすべてのコールを個別に追跡するように奨励することでした。

何かを測定しようとする私の最初の無駄な試み、ヒント

2013年に、私の会社には既にテクニカルサポートタスクの会計システム（以下、ServiceDeskと呼びます）がありました。 確かに、それは名目上使用されました-ユーザーからの書面による要求を自動的に記録し、定期的な予防タスクを作成しましたが、電話で受信したアプリケーションは、特に単一の呼び出しで解決された場合、システムにほとんど落ちませんでした。 さらに、システム自体を操作する文化も苦しみました-数か月間（時には何年も）、専門家は既に完了したアプリケーションを閉じることができず、タスクの現在のステータスを更新する問題はありませんでした。 2013年にシステムが機能した形式では、システム内の何も測定することができませんでした。



ServiceDeskでのアプリケーションの登録と終了をスペシャリストに勧めるという点で最初に思い浮かんだのは、登録されて閉じられたアプリケーションごとにスペシャリストにボーナスを支払うことでした。 しかし、このアプローチは、明らかに、ユーザーが技術サポートに連絡する理由をできる限り多く作成するように専門家に暗黙的に動機付けますが、ユーザーが技術サポートに連絡する理由がないように専門家に働きかけることははるかに正しいです。 このため、私はプレミアムファンドを月額固定額にすることを決めました。これはアプリケーションの数に依存しません。 各スペシャリストによる登録および完了済みアプリケーションの割合に基づいて、すべてのテクニカルサポートスタッフ間で固定額が共有されると想定されました。 つまり、1か月で各専門家が1つのアプリケーションを登録して完了した場合、すべての専門家がボーナス基金を平等に共有します。 1つの完成したアプリケーションは、これらの割合内で2つの登録アプリケーションに等しいと想定されました。



私が象徴的に行ったアプリケーションの最初のプレミアム基金-10 000 p。/月。 みんながこれを仕事の優先順位を決定する何らかのボーナスシステムと見なさないように、このシステムを「社会的競争」と呼び、2013年5月に次の内容の手紙を全員に送りました。

「みんな、ゆっくりと、しかし確実に、励ましと動機付けのシステムの開発に向かっています。



企業の動機付けシステムの目標は、内部効率を高めることです。 各自のモチベーションシステムの目標は、会社への貢献を客観的に評価し、より多くのことを行い、より良いものにすることでより多くの収益を上げることができるようにすることです。

私たちの分野で行われた仕事の量を評価することは恩知らずな仕事であることを理解しています。 このため（無実を罰せず、関係のない人に報償を与えないため）、まずは現在の負荷を客観的に理解し、それらに直面しているすべてのクライアント、現在の顧客満足度、および不均等な作業量の理由について分析を行いたいと思います。



これらの目的のために、私たちは賞金10,000ルーブルの小さな「社会主義者」コンテストを実施します。これは、次の原則に基づいてコンテストの全参加者に分配されます。 ポイント率は、その月に登録および終了したすべてのアプリケーションのすべてのポイントの合計で割った賞金額として定義されます。 たとえば、1か月で900のアプリケーションが閉じられ、200のアプリケーションが登録された場合、ポイント交換レートは1ルーブル、1つの登録アプリケーションのコストは5ルーブル、1つのクローズ-10ルーブルです。



したがって、できるだけ多くのアプリケーションを登録（およびクローズ）するために、6月のあなたの利益のために。 私たちはクライアントのオフィスに入り、3つの質問をされ、それらに答えました。3つのアプリケーションを登録し、それらを閉じて、ソーシャルコンペで45ポイントを獲得し、ルーブルに変換されます。 ユーザーのきしみ音を登録してください-将来的に統合ボーナスシステムを作成できるように、現在発生しているすべての問題を確認する必要があります。

「社会的競争」の最初の月の結果は...ドラムロール...何もない。 スペシャリストの仕事には何も変更はありませんでした-仲間はそれ以上のアプリケーションを登録しませんでした。 誰もが以前と同じように働き、アプリケーションにとんでもないが余分なお金を与えたとき、誰も眉や感情の涙を持っていませんでした。 おそらく、普通のビジネスマンは部下が彼の寛大な寛大さに感謝しなかったことに激怒するでしょうが、この状況は私を苛立たせただけでした。私は専門家のさらなる行動を観察し、社会主義競争の予算を徐々に増やすことにしました。 3か月後、予算は月に15,000ルーブルに増加し、さらに3-20,000ルーブル/月に増加しました。 予算の増加は依然として専門家の反応を引き起こさず、月ごとのボーナスの分配はほぼ同じでした（以下の要求に応じて従業員の本名は置き換えられます）。





表1（クリック可能）。 2013年11月にServiceDeskシステムを使用した場合のボーナスの計算。



毎月、私は「社会的競争」の結果についてのニュースレターを発行しました。そして、男たちは、アプリケーションを維持するための小さなボーナスを受け取り、感謝を言って、ダイニングルームで昼食のためのボーナスを手に逃げました。 ボーナスのサイズから判断すると、すべてがほぼ同じように機能していましたが、同時に、ボーナスシステムではユーザーリクエストのみが考慮され、従業員が実行する定期的な予防タスクは考慮されませんでした。 「社会的競争」の開始から約8か月後に、次の内容の従業員の1人から手紙を受け取りました。

「そして、基金を予防と通常の申請に分けることができますか、それともなんとなく退屈で、陰謀はありませんか？」

陰謀、陰謀が必要です！ そして、 Ostapは私を苦しめました。

アプリケーションシステム、詐欺師、船の暴動を扱うための死産の動機付けシステム

約2か月、Habrの記事を読んでからの空き時間に、「社会的競争」のシステムを多様化し、それに陰謀を加える方法を考えていました。 まず、その時点で測定できるアプリケーションの作業を評価するためのすべての客観的な基準を収集しました。 彼らは少し判明しました。

1. 登録済みアプリケーションの数。
2. 閉じられたアプリケーションの数。
3. 完了した定期メンテナンスタスクの数。
4. アプリケーションに関する専門家の作業のユーザーによる評価。

したがって、次のような追加の基準をモチベーションシステムに導入することで、陰​​謀を作成することにしました。

1. 各カテゴリ（登録、アプリケーションの終了、予防措置の実施）の2人のドラマーのスコアが50％増加する1.5のプレミアム係数。
2. 剥奪係数0.5。このカテゴリの最も弱い専門家のスコアを50％削減します。
3. その月のサービス品質ServiceDeskの主観的評価の係数。 このような評価は、今月「ディスパッチャー」の役割を割り当てられた専門家の1人によって行われると想定されていました（この役割には追加のボーナス率が依存されていました）
4. 予防タスクの基準を満たしていない場合の0.5の非決定係数（1か月あたり40タスク）。 この標準は、最もクールな3人の専門家には存在しませんでした。
5. 予防タスクの実施に関する規制からの逸脱に対する0.5の剥奪係数。 同時に、違反している従業員から差し引かれたポイントが、規制からの逸脱を発見した従業員に追加されました。

モチベーションシステムに戻って、あらゆる種類のオフィスの知恵（この方法で、ユーザーに指示を正しく構成するように一度に教えました）とプロジェクトに参加するために、ブログで記事を書くための保護係数がありました。 これらすべての係数がどのように関連していたか、今はお話ししません-私はすぐにこのシステムを放棄しなければならなかったので、これは本当に重要ではありません。



新しいルールを導入して、私はもう一度プレミアム基金を増やし、ニュースレターを作成しました。 ゲームの新しいルールを研究したイリヤ・ムロメッツ（従業員の名前が変更されたことを思い出します）はすぐに彼女の欠陥を見つけ、その欠点を示すためにプレミアムシステムを「ハッキング」したと述べました。 これを行うために、イリヤは、他の同僚が予防措置の基準を満たせず、保険料の低い係数を受け取ることができないように、1か月を通してできるだけ多くの予防タスクを実行しました（つまり、保険料を減らして引き上げました）。 イリヤはほぼ成功し、3月に最大の賞を受賞しました。





表2（クリック可能）。 2014年3月にServiceDeskシステムを使用するためのプレミアムの計算。 以下：N-アプリケーションの数、P-ポイント単位の価格、K-係数の増加（低下）。



確かに、イリヤは4月には十分ではなく（まあ、または同僚が彼を暗くした-物語は沈黙している）、4月の賞は古いレポートに似ていた。





表3（クリック可能）。 2014年4月にServiceDeskシステムを使用するためのプレミアムの計算。



3か月目に、ドブリニャニキチッチはすでにすべての予防措置を1人で行ったため、全員に鼻を残しました。 ドブリニャはこれに対して技術的な優位性がありました-彼はノボシビルスクに住んでいて、モスクワ事務所より3時間早く目覚めました（現在4）。 どうやら、メインチームからの時間と領土の遠隔性がドブリニャから自己保護の感覚を奪い、2014年5月にボーナス資金の半分を切り捨てたようです。





表4（クリック可能）。 2014年4月にServiceDeskシステムを使用するためのプレミアムの計算。



そのような動機付けシステムに関する作業の4か月目はありませんでした-大衆の間で、既存のシステムが動機付けをするだけのつぶやきがありました。 原則として、今では、このような報酬システムは、誰もが他の人を困らせる方法しか考えていない不健康なチームでのみ定着することを理解しています。 私たちのケースでは、他の人のアプリケーションシステムでの作業の品質を評価したくありませんでした。また、彼の作品にジャムが見つかった場合、隣人を「ノック」したくありませんでした（もちろん、この場合、ミスはボーナスの減少につながりました）全体として、一部の人々は、実行のエラーがプレミアムの減少につながる可能性がある場合、単にタスクを引き受けないことを好みました。 その結果、人々を罪に導かないために（大衆はすでに私を含む暗い人を会社の巧みな経営のために手配する方法について話し始めています）、3ヶ月後に私は放棄しなければなりませんでした：

1. 労働結果の評価およびボーナスの規模への影響における同僚の直接参加。
2. やる気を起こさせる要因（ユーザーによる作業の質の客観的評価を除く）;
3. ボーナスシステムの特権従業員。

その後、「社会的競争」システムには3つのカテゴリのみが存在し、各カテゴリに2人のリーダーがおり、ユーザーによるアプリケーションの作業の質の評価が行われました。 2015年4月まで、このようなシステムは変更なしで機能しました。





表5（クリック可能）。 2015年4月にServiceDeskシステムを使用した場合のボーナスの計算。



2015年初頭の動機付けシステムの唯一の成果は、アプリケーションシステム内のすべてのユーザーリクエストの一般的な登録でした。 しかし、アプリケーションのステータスがタイムリーに更新され、システム内で閉じられると、事態も悪化しました。 月の半ばにServiceDeskでアプリケーションを勉強しているとき、頭の毛は、私たちが打ち込んだタスク、何らかの形でそれをしたタスク、またはすでにやったことの量に逆らっていました。 同時に、テクニカルサポートスペシャリスト（私は毎月末に行いました）を蹴ると、アプリケーションはすぐに大量に閉じられ、何が起きているのかがより親切になりました。 しかし、2015年に、この状況がようやく気になり、ボーナスシステムへの別の襲撃を決定しました。

アプリケーションシステム内のタスクのステータスをタイムリーに更新するための闘争

アプリケーションシステムのステータスのタイムリーな更新とタスクの終了を競うために、ユーザーのアプリケーションを2つのタイプのボーナスシステムにさらに分割しました。 アプリケーションを時間通りに閉じました。他のすべてのタスクよりも3倍も価値があります。 同時に、リーダーシップの係数は3つのカテゴリに留まりました-登録されたアプリケーション、時間通りに閉じられ、予防タスク。 期限に違反して作成されたアプリケーションには、リーダーシップ係数がありませんでした。 新しいシステムによれば、良いボーナスを得るためには一ヶ月中一生懸命働くだけでは不十分であり、月末に急いで行われたタスクを終了することはできませんでした-ServiceDeskシステムの情報をその月を通して最新に保つ必要がありました。



私の過去の経営上の「成功」を念頭に置いて、既存のボーナスシステムで何かを変更する前に、私は最初に古い期間にわたる変更のサイズを推定しました。 表6は、2015年4月の新しいシステムの保険料の計算を示しています（上記の表5には、古いシステムの同じ期間の計算が含まれています）。 さらに、レポートでは、「ハング」の数を推定しました。これは、レポート期間中に期限切れで閉じられなかったアプリケーションです。





表6（クリック可能）。 新しい会計システムを使用して、2015年4月にServiceDeskシステムを使用した場合のボーナスの計算。



悲しい絵がレポートに登場しました-期限切れのアプリケーションとハングしているアプリケーションの数は、時間通りに閉じられたアプリケーションの数を超えました。 しかし、状況のすべての悲しみにもかかわらず、新しいボーナスシステムは、プレミアムファンドの現在の分配を根本的に変更しなかったため、テクニカルサポートスペシャリストとの新たな対立を脅かすことはありませんでした。 したがって、私は自分自身を越えて、ボーナスシステムの変更について通知を行い（今回は予算を変更せずに）、観察を開始しました。



ここに書いてみたいのは、変化はすぐに来るものであり、新しいボーナスシステムの導入により、人生はついに改善されたということです。 しかし実際には、ボーナスシステムの変更を知った人たちは緊張し、ほとんどの「ハング」アプリケーションを閉じて、新しいアプリケーションを保存し始めました。 延滞し、「ハング」するアプリケーションは、やや少なくなりましたが、この面でいくつかの重大な勝利を宣言することはできませんでした。 意味のある結果がなかった理由は平凡であることが判明しました-一部の従業員は、ServiceDeskのアプリケーション管理の品質に負担をかけるだけでなく、余分な1000ルーブルを無視する準備ができていました。 。



システムでの作業からボーナスを必要としない専門家のアプリケーションシステムで作業を推進するために、アプリケーションシステム内のタスクの総数に対する時間どおりに閉じられたタスクの比率に応じて基金のサイズが変化するときに、プレミアムファンドを動的にしました」）。 このアプローチにより、ServiceDeskを適切に実施していない（時間どおりにアプリケーションを閉じず、中断したアプリケーションを残す）従業員は、自分自身だけでなく同僚にもボーナスを減らすことがわかりました。 私の計算では、賞を必要としない専門家は、賞を必要とする同僚との関係を損なうことはなく、多かれ少なかれ高品質の応募記録を保持しようとしています-陰湿な計画でしょうか？ :)



イノベーションが既存の条件を悪化させないように、現在のプレミアムファンド（30,000ルーブル）がServiceDesk管理の現在の品質に対応する「プレミアムベース」のレベルを計算しました。47,000ルーブルが出ました。 次のニュースレターを作成した後、私は再び待って、2、3か月後に、はるかに根本的な質的変化を見ました-期限切れのアプリケーションと「ハングアップ」の数がシステムで半分になりました。





表7（クリック可能）。 2015年10月にダイナミックボーナス基金を使用してServiceDeskシステムを使用した場合のボーナスの計算。



これで、私は動機付けシステムの変更をやめました。 次の2年で、私はかつてプレミアムベースを引き上げ、残りの時間はタイムリーにプレミアムの検討と支払いを行い、イベントの展開も見ました。

結果、何が起こったのか、現時点でうまくいかなかったのか

ボーナスシステムのおかげで、4年間（ほぼ5年間）、私の会社のアプリケーションアカウンティングシステムはより有益になりました-すべての新しいタスクがそれに登録され始め、システム内のほとんどのタスクがタイムリーに閉じられ始めました。 これで、いつでもアプリケーションシステムで、実行されたタスクの現在のステータスに関する多かれ少なかれ関連情報を取得できます。 しかし、主なことは、サービスの品質を多かれ少なかれ客観的に測定することが可能であることです：アプリケーションがいくつ作成されたか、どれだけ時間がかかったか、どのサービスがアプリケーションであったか、私たちのサービスの経時的なダイナミクスは何ですか、各サービスをサポートするコストは何ですか？など。 たとえば、過去2年間の結果を比較できます。

	2016年	2017年
修正されたインシデント	3267	2535
満たされたサービスリクエスト	1411	2373
相談を提供	113	148
完了したルーチンタスク	4138	3940
修正されたバグ	190	340
インシデントの排除	569	432
期限に違反して完了したサービスリクエスト	196	200
インシデント復旧時間の中央値	78分	37分
サービスリクエストフルフィルメント時間の中央値	61分	43分

表8. 2016年と2017年のテクニカルサポートの結果の比較。



前の段落では、「多かれ少なかれ」の売上高の使用におそらく注意を向けました。 実際のところ、アプリケーションシステムでのアカウンティングの正確性には、まだ多くのことが望まれています。 したがって、上記の表から、2017年は2016年と比較してインシデントが741減少し、サービスリクエストは962増加したことになります。この変更の理由は簡単です。メールで受信したリクエストは自動的にインシデントとして記録されます。 。 2016年には、閉鎖時にアプリケーションの種類を確認することはめったにありませんでしたが、2017年には、より頻繁にそれを実行し始め、そのような再配布に至りました。 タスクカテゴリの定義でも同じパセリが観察されます-テクニカルサポートスペシャリストは、タスクとそれが影響するサービスを常に正しく関連付けるとは限りません。 技術サポートに派遣者と管理者がいた場合、彼らは作業プロセスのそのようなエラーを追跡し、説明作業を実行し、会計の正確性はより高くなります。



また、上記のレポートによると、締め切りがわずかであるにもかかわらず、締め切りに違反する多数のアプリケーションがあります（大丈夫、大丈夫-数十）。 違反のほとんどは、タスクの正式な会計の機能の相違と実際の実行に関連しています。 例：

1. タスクがあり、その運用上の実装は、クライアントに大きな損害を与えます。 たとえば、サーバー上のファンの1つがひどく回転していることがわかりましたが、サーバー/ドライブはウォームアップせず、実行してファンを必死に変更する（会社を停止する）理由はありません。 したがって、アプリケーションは作業に都合のよい瞬間を見越してハングし、アプリケーションシステムでは「ハング」します。
2. タスクが私たちの責任範囲を離れるとき、専門家が常に「保留」（保留）を要求するとは限りません。 たとえば、彼らはコミュニケーションの質について苦情を受け、診断を実施しました-プロバイダーに問題があり、訴えを送りました。 この時点で、アプリケーションを「保留」にすることができる/すべきであるため、タイマーが停止します（プロバイダーのネットワークが責任範囲外にあるため）。 現実には、プロバイダはすぐに修正することを期待して、多くの場合これを行いません。 プロバイダーが問題を長時間解決した場合、会計システムに遅延が生じます。
3. 一部のアプリケーションは、完了しても、時間どおりに閉じられません。 それは時々起こることです-あなたは早く仕事から逃げ、要求をし、別のタスクを取り、時間通りにそれを閉じるのを忘れなければなりませんでした。 まあ、何人かの専門家（明らかに非常に高い給料をもらっている）は、私のすべてのトリックにもかかわらず、それでもアプリケーションシステムで動作します。
4. ピーク負荷。 ある種の流行性咳が私たちのチームの半分を占め、逆に、私たちの従業員は健康で、エネルギーに圧倒されており、今日、彼らは以前は到達できなかった問題に対処したいと考えています。 そのような日には、ServiceDeskのすべての手続きが電話に応答できるわけではありません。
5. 一部のアプリケーションはミニプロジェクトであり、標準アプリケーションに割り当てられているよりも時間がかかります。 たとえば、クライアントが新しいオフィスを開くと書いた場合、アプリケーションは自動的に登録され、オフィスのオープンに関連する宴会まで「ハング」し続けます。
6. 一部のアプリケーションは本質的に問題です（ITIL用語内）。 たとえば、1人の従業員の1Cデータベースが1日に数秒間「フリーズ」する場合、またはユーザーの最初のOutlookの起動に通常より時間がかかる場合-テクニカルサポートに連絡した時点でエラーは観察されませんが、定期的に発生するため、専門家はその原因を取り除きます。 多くの場合、このような理由で検索するには数週間かかりますが、アプリケーションシステムでは、アプリケーションのフルフィルメントに割り当てられる最長時間は3日間です。

上記のすべての欠点にもかかわらず、アプリケーションシステムを使用するテクニカルサポートスペシャリストの現在の仕事の質は私に合っており、同様に重要なことは、アプリケーションシステムを使用する動機付けシステムがスペシャリスト自身に合っていることです。もちろん、まだ改善と改善が必要ですが、ユーザーリクエストのアカウンティングの品質を改善するのではなく、ユーザーがテクニカルサポートに連絡する理由がないことに注意を向ける方がはるかに正しいと思います。確かに、企業の情報システムの仕事の質が向上しても、技術サポートへの電話の数は変わらず、電話の性質とそれに伴う感情的背景のみが変わることが経験からわかっています。しかし、これは完全に異なる話です...



成功！



イワン・コルマチェフ

IT部門の会社

www.depit.ru