オンザエッジとインコントロール

複雑なテクニカルサポートの管理

テクニカルサポートの担当者は、複雑化・異機種化していくアプリケーションやハードウェアプラットフォームの中で、未知の世界に足を踏み入れてしまうことが少なくありません。いつでも、どこでも、何でもできる」という利便性が顧客に約束されているにもかかわらず、その約束をどのようにサポートするかについてはほとんど考えられていません。

テクニカルサポートは、ネットワークトラフィックの滞留、システムリソースを奪い合うテクノロジー、データ、メディアの融合の海、そして顧客ごとに異なる設定状況の中で溺れています。バリューチェーンの最後尾に位置するテクニカルサポートは、何が販売され、それがどのように作られ、実装されるかについてほとんど発言できません。

インシデント管理とトラブルシューティングの活動は、「我々ではなく彼らのものだ」という非難合戦、個人的な推測、または怒り狂ったお客様による問題のエスカレーションになってしまうことがあります。問題解決は確実ではなく、確率的なものになってしまいます。

お客様は、接続されていながら異種のテクノロジーを使用しているため、ITインフラの複雑さにもかかわらず、ビジネスが均質にサポートされることを期待しています。顧客の複雑なIT環境が相互に接続されているという現実に気づかない企業は、この複雑さをアウトソースできると考えている企業と同様にリスクを抱えている。

私たちのクライアントに共通しているのは、テクニカルサポート部門がギリギリのところにいるということです。彼らはコントロールすることができるのでしょうか?私たちはそう信じています。

本稿では、ミッションクリティカルなサポート機能の観点から、サポート機能の弱点を考察し、あらゆる製品、プラットフォーム、技術に適用可能なスケーラブルな解決プロセスを紹介します。

サポートの向上。不足しがちなアプローチ

カスタマーサポート部門のマネージャーや意思決定者が、サポートの世界がますます複雑になっていることを認識しているのは良いニュースだが、悪いニュースは、改善イニシアチブの成功が散発的であるということだ。悪いニュースは、改善イニシアチブの成功が散発的であるということです。どんなに優れた組織でも、イニシアチブの成功はすぐに停滞し、投資収益率は当初の約束を下回ります。

ここでは、うまくいかなかった点を紹介します。

  1. 技術研修の充実
  2. スクリプトによるサポートに頼る
  3. ナレッジツールの増設
  4. 成功の鍵となる指標として、パフォーマンスアベレージを用いる

皮肉なことに、これらの一見「正しい」と思われるステップは、論理的な順序に従っているため、組織は効果のない改革や新しいイニシアチブの無限ループに陥り、リソースを浪費し、顧客に不満を抱かせることになる。

1.テクニカルトレーニングは、サポートプロセスを効果的に管理するために非常に重要です。一般的に、トレーニングはサポートセンターの予算の5-6%を占め、サポートセンターのスタッフは平均して1年に約3週間のスキルアップを行います。ほとんどのトレーニングは、社員のオリエンテーションや新製品の発売時に行われます。どんなに良いことをしても、人間の学習能力ではトレーニングは不十分です。サポート担当者は、2つ、3つ、あるいは4つの製品の認定を受けることができますが、その認定が専門知識をもたらすわけではありません。テクニカルトレーニングマニュアルでは、お客様独自のITインフラの複雑な構成やダイナミクスをシミュレートすることはできず、アナリストは即興で対応しなければなりません。その結果、顧客満足度の最大の原因であるサポートの一貫性が失われてしまうのです。

テクニカルサポートの担当者は、既知の水域を上手に泳いでいますが、知識や経験のない状況にさらされると、沈んでしまいます。サポートアナリストに聞いてみましょう。今日、アナリストが直面している最大の仕事上の問題は、次のチケットが自分の専門外のものになるという確信に近いものです。

スキルベースのルーティングは、割り当てやスケジューリングの問題を恒久的に解決するものではなく、応急処置的なものです。ルーティングルールでは通常、製品に関する問題を定義された専門家に割り当てます。このプロセスを促進するためにACD(Automatic Call Distributors)が設置される。このような状況では、"良い "リソースが燃え尽き、"他の "リソースが十分に活用されないという、"饗宴 "や "飢餓 "のような状況に陥りがちです。次のミッションクリティカルなサポートチケットを予測して、適切な製品スペシャリストをスケジュールするために履歴を使用することは、効率と効果に欠けます。技術やシステムを導入したにもかかわらず、案件のバックログが減らない。また、複雑な問題が発生した場合、ルーティングに失敗する。

2.製品ベースのスクリプトは、経営陣がパフォーマンスアベレージを向上させるために使用するもので、アウトソーシングモデルの創始者の原則です。経営陣のスクリプトに対する信念を打ち砕くには、ミッションクリティカルなチケットを解決しようとするスクリプトの試みを聞けばいいのです。

第一線の人々はスクリプトに従うことに問題はなく、しばしば誤りを犯します。スクリプトは、よく知られた状況や日常的な状況では有効です。しかし、状況がスクリプトから少しでも逸脱したり、お客様が複雑な問題を提起したりした瞬間に、スクリプトは崩壊してしまいます。お客様は、スクリプトや失敗したロジックを見て、その問題はアナリストの守備範囲外だと判断し、ヘルプデスクの信頼性に疑問を持ちます。信頼は失われます。

サポートの複雑化に伴い、スクリプトは作成したその日に日付が変わり、それ以降は実用性が薄れていきます。

保証コストの分析でも、スクリプトの失敗が明らかになりました。スクリプトの使用は、サービスパーツの出荷数やサイトサービスの予定数とほぼ完全な相関関係があります。電話はヘルプデスクレベルで解決されますが、そのためには組織にとって大きなコストがかかり、多くの場合、診断が間違っています。

3.知識管理(KM)ツールは、トレーニングや知識の共有がうまくいかず、サービスのコストがエスカレートしているときに解決策を提供します。経営陣は、人的要素を最小限に抑え、KMツールを導入するように迫られます。サービス技術は、サポートセンターの予算の6〜7%を占めており、毎年、約70%の組織がKMプロジェクトを実施しています。KMを導入しても、顧客満足度が飛躍的に向上したり、平均解決時間が短縮されたりすることはありません。それどころか、テクノロジーの増加は、サポートの失敗を露呈させ、加速させます。

典型的なシナリオを考えてみましょう。アナリストAがある問題を解決し、その解決策をKMソリューションデータベースに入れる。アナリストBが同じような問題に遭遇するが(一致する場合もあるし、しない場合もある)、Bは自分のやり方がトラブルシューティングの正しい方法だと考えているため、Aのソリューションや根本的な問題を使用しない。そこで、Bは解決策のバージョンを追加する。あるいは、アナリストBは両方の問題が同じだと考え、Aの解決策を見つけ、それが正しいものではないにもかかわらず、同じパッチを送り、結果的にお客様にさらなる問題を引き起こすことになります。

KMツールは、その精巧さに関わらず、おそらくサポート組織で最も誤用されているテクノロジーの一部です。

4.平均値ベースのパフォーマンス指標は、満足度スコアを向上させるためのスクリプトや、そのギャップを埋めるためのKMツールの失敗を隠蔽します。組織は、MTTR (mean time-to-resolve) がある程度良好であると報告することができますが、この統計の下には極端なチケットが隠れています。これらの問題は、長引き、エネルギーとリソースを浪費し、顧客満足度を損なう問題である(平均顧客満足度スコアの中に埋もれている極端なスコア)。

平均値ベースのレポートは、「まず修理、問題解決は後回し」という姿勢に報いるサイクルを生み出します。いったんチケットが開かれると、評価やプロセスはほとんど重視されません。目標は、トラブルシューティングではなく、SLA(サービスレベルアグリーメント)を満たし、状況の深刻度を下げることです。ケースログは、ログファイルを要求する延々とした電子メールのスレッドとなり、ケースを解決するために何もしなければ、無駄なデッドタイムが発生します。

ITILのインシデント管理プロセスは大きな可能性を秘めていますが、バラバラのトラブルシューティングプロセスの上にインシデント管理プロセスを標準化しても、持続的な成果は期待できません。ヘルプデスクやテクニカルサポート機能の長期的な解決策は、技術、プラットフォーム、言語、地域に依存しない、定義されたプロセスです。

このプロセスを確立する前に、お客様の目線でサポート機能を見てみてください。

サポート機能 - お客様がエスカレーションする理由

様々な業界や地域で行われているお客様の声の調査によると、お客様はサポートに関して7つの大きな問題を抱えていることがわかりました。

これらは

  1. "私のビジネスニーズに対応していない"システム/ソフトウェア/ネットワーク/サービスが故障すると、お客様のビジネスが停止します。あなたがサポートしているのは製品だけではなく、お客様のビジネスをサポートしているのです。製品ではなく、お客様をサポートしましょう。
  2. "サポートの質が安定していない"お客様は、常に同じ高い水準を求めています。一貫して提供する。
  3. "I don't know what you're doing on my problem."お客様は、何が起こっているのかわからない、あるいは、あなたがどこに向かっているのかわからないと思うと、不幸になります。お客さまを導く。
  4. "私の問題は解決されていない"お客様は正しい解決策を必要としています。積極的にトラブルシューティングを行います。
  5. "修理に時間がかかりすぎている"お客様は今すぐビジネスを取り戻したいと思っています。急いでください。
  6. "I want a permanent fix, but not workaround."お客様は、自分の問題が永久に解決されることを必要としています。それを証明してください。
  7. "なぜ私は問題を抱えているのか?"お客様は問題を避けたいと思っています。予防は治療に勝るのです。先手を打つ。

カスタマーケア機能のすべてのイニシアチブは、この7つの分野の懸念事項を常に前面に出していなければならない。これらのお客様の関心事は、ミッションクリティカルなサポートプロセスが構築される際のプラットフォームとなります。

Why Mediocrity

抵抗感。プロセスがあるのに、なぜ別のプロセスが必要なのか?

トラブルシューティングのプロセスがすでにあるという主張は、サポートの一貫性によって検証されます。製品別、サポート担当者別に解決までの時間をプロットしてみてください。正規の曲線を描くことで、ばらつきが浮き彫りになります。このばらつきは、もし本当にプロセスがあるなら、それが守られていないことを明らかにします。

アナリストは、自分が持っているプロセスを信じず、独自の方法でトラブルシューティングを行うことがよくあります。このような不正なプロセスは目に見えないだけでなく、何か異常があると頻繁に故障します。

多くの企業は、平凡さに甘んじているように見えます。カスタマーサポートをビジネス戦略の勝てる要素として確立するためには、根本的に異なる何かが必要です。

サポートセンターのパフォーマンスを自己評価するために行われた業界全体の調査では、多くの組織が平凡さに甘んじていることが明らかになった。カスタマーサポートをビジネス戦略の勝てる要素として確立するためには、根本的に何かを変える余地があり、それが必要であることは明らかだ。

オンザエッジで、コントロールする。プロセス

お客様の問題とその解決に関する優れた知識と理解は、合理的なプロセスアプローチを用いることで可能になります。そのためには、構造化された質問技術のスキルを身につけ、そのスキルをリアルタイムで使用する能力を高め、繰り返し使用することでコンピテンシーを構築する必要があります。

この構造化された質問は、顧客との対話に不可欠なものとなる。あらゆるサポート機能において、合理的なプロセスの使用を奨励するパフォーマンスシステムを構築することで、熟練度を高めることができる。合理的なプロセスのアプローチは、プラットフォーム、テクノロジー、サポートシステムに依存せず、ヘルプデスクやカスタマーケアの環境における最も複雑な課題を管理するために拡大することができる。

このプロセスは、個人と組織の有効性を高めるため、既存の知識と一般的な慣行に基づいて行われます。このプロセスは、組織内で行われている優れた学習、システム、顧客管理の手法をサポートし、統合します。

問題解決のロジックフロー

ミッション・クリティカルな問題を解決するための合理的なプロセス・アプローチは、お客様の状況を評価することから始まります。査定では、論理的にデータを収集し、問題を定義します。その後、可能性のある原因を特定し、問題の仕様に照らし合わせてテストし、最も可能性の高い原因を選択してテストするプロセスである「解決」が行われます。

トラブルチケットをできるだけ早く解決してクローズしなければならないという緊急性から、鑑定は一般的なサポート環境ではしばしば欠けている部分です。しかし、適切に行われた鑑定は、以下のような一般的な落とし穴を防ぐことで、解決を早めることができます。

  • 過剰な一般化 - 膨大なケースログやデータダンプなどの情報が氾濫すると、その後の行動を有効にするための具体的な情報が見えなくなってしまう。意図や現実を曖昧にするような用語には注意が必要です。原因と結果の関係を仮定すること - 出来事を望ましい関係に連鎖させたいという衝動は、効率を低下させ、誤った道を歩むことになります。原因に飛びつき、「...が原因」、「...が原因」、「...が原因」などの表現をする傾向が強いので注意が必要です。
  • 現実の混乱 - 24時間365日、太陽のように動き続けるサポート担当者と、地球上のどこにでもいる顧客との間では、認識の違いが混乱を招く。同じイベントを複数のバージョンで定義することに注意してください。
  • 合理性を奪う感情 - トラブルシューティングの各段階での強い感情が、データの解釈を狂わせる。口頭やケースログメールでの不合理な発言や、不機嫌な沈黙に注意してください。
  • 圧倒的な混乱の大きさ - 問題が大きくなりすぎて、一人や一組では対応できなくなった。テクニカルサポートブリッジの参加数と頻度に注目してください。

評価は完成品ではなく、効果的なトラブルシューティングの要となるものです。鑑定とは、お客様とフロントラインおよびバックラインのサポートとの対話です。これは、技術サポートを、複雑でしばしば不明瞭な現実から実行可能なステップへと導くコラボレーションです。適切に行われれば、鑑定は、適応性のあるソリューションと効果的な解決の岐路にある混乱を克服します。

効果的なアプレイザルは、サポート担当者が焦点を絞った質問やテクニックで問題を解決するのに役立ちます。

  • "What do you mean by...?", "What else do you mean by...? "は、一般化を分解し、アクションを特定化します。
  • "How are we so sure that is due to that?" "What test have been done to prove it?" 因果関係を仮定することを避けています。
  • "What evidence do you have...?" は、実際に起こっていることと、起こるべきことを区別します。
  • "What else is buggging you...?" は、オーバーロードの感覚を認め、反省を促します。

一刻も早い解決を求めて、原因究明に躍起になりがちです。解決へのプロセスアプローチは、以下の共通の落とし穴を避けることでトラブルシューティングを加速させることができます。

  • 症状か原因かのジレンマ - どちらか一方の立場に立つこと。お客様のビジネスのプロをうっかり無視しないように気をつけましょう。
  • 問題の定義が不十分であること - 無関係なデータが多すぎるか、事実がほとんどない。曖昧なデータ要求が繰り返されていたり、すべきことと実際のパフォーマンスが曖昧に表現されていたり、事実が刻々と変化していることに注意してください。
  • トラブルシューティングのロジックを覆すバイアス - 直感を裏付ける仮定を証明したいが、検証したくないという衝動に駆られる。弱い、事実に基づかない、不合理な仮定を持つ可能性のある原因に注意してください。
  • 確認前のクロージング - MTTRの指標で閉鎖を促す。最初に顧客に証明することなくチケットを閉じることに注意してください。

合理的なプロセスがエスカレーションをどのように導くのか?エスカレーションは通常、フロントラインの知識や経験が限界に達したときに起こります。合理的なプロセスアプローチを用いることで、フロントラインは、バックラインが構成したであろう方法で正確に構成されたチケットを手渡します。これにより、お客様とのやりとりの繰り返しを減らし、デッドタイムを回避することができます。

お客さま。ロジックが理解を深める

人事担当者は、これらの論理的な質問とテクニックを使って根本的な原因を特定します。

  • 理解しやすいオブジェクト/偏差値形式で問題を述べる
  • 問題が発生している対象物と、類似しているが影響を受けていない対象物について、識別、場所、時間、数量に関する比較可能な事実を集めて、問題を特定する。
  • 既知の環境では、知識と経験を駆使して原因を生成する。未知の領域には高度な技術を使う。
  • 環境を再現する前に、考えられる原因を事実に基づいて検証する。
  • 事実、観察、研究、実験などで真因を確認する。
  • 論理的な評価と解決のプロセスを適用することは、お客様との対話に大きな影響を与えます。

お客様が、自分は台本通りではなく話を聞いてもらっている、アナリストは論理的な質問をしている、と認識すると、アナリストや組織に対する信頼感や信用が生まれます。

いつでも、製品のスペシャリストだけでなく、ヘルプデスクのメンバーの誰もが、お客様からの電話を受け、同じロジックに沿って、正しい方向に大きく前進させることができます。

プロセスアプリケーション。いつ、どこで、どのくらい

このトラブルシューティング・プロセスは、フルスケールでも、非公式の迅速な対応モードでも適用可能です。

ミッションクリティカルなサポートが必要な場面では、本格的なアプリケーションが必要となります。

  • 優先度が高い - 重大度が高い
  • 再開されたチケット
  • 非常に複雑な問題
  • 明らかな解決策がない異常さ
  • 時間と資源に多大な投資を必要とする高価なもの。

業界や製品の成熟度にもよりますが、5~10%のチケットがこのカテゴリーに入ります。しかし、これらのチケットは、組織のリソースの30~50%を消費しています。このプロセスを本格的に活用することで、満足度、解決度、更新度、コストなどの指標に大きな影響を与えることができます。

ヘルプデスクの状況の大部分は、通常は

  • 優先度は高いが身近な存在
  • 早急な対応が必要な場合
  • 知識と経験があれば簡単に解決できる

一般的に15-50%のケースがこのカテゴリーに当てはまります。非公式なプロセスを適用することで、満足度のスコア、一貫性、信頼性の構築などが大幅に改善されます。

結果

Kepner-Tregoeは、トラブルシューティングのための論理的なフレームワークを提供します。KTプロセスは、トレーニング、ビジネスプロセスの統合、パフォーマンスシステムの改善を通じて、サン・マイクロシステムズ、デル、シスコ、EM Cなどのサポート環境で優れた結果をもたらしている。代表的な指標は以下の通り。

  • 40%バックログの削減
  • 58% 平均クローズアップ時間の短縮
  • 41% 初回修正率の改善
  • 25 % 製品開発グループへのケースのエスカレーションの減少
  • お客様の待ち時間を年間12,000日短縮
  • 37% インシデント/ディスパッチ率の低下
  • $1000万円のクリティカル・アカウント・リファーラルのコスト削減。

お客様の満足度向上につながることを想像してみてください。

Ready - 何を変える必要があるのか?

ベストプラクティスのプロセス使用を開発するためには、いくつかの哲学的、構造的な変化が必要です。

哲学的には、パラダイムシフトが必要です。ヘルプデスクは、製品やアプリケーションのサポートを主張するのをやめるべきです。ヘルプデスクは、お客様のビジネスをサポートするものです。ヘルプデスクとは、お客様のビジネスをサポートするためのものであり、トラブルシューティングを的確に行い、そのプロセスをお客様にご案内し、問題が解決されたことを証明するものです。

構造的な変化を実現するためには、考えられるすべてのことではなく、改善すべき重要な少数の領域を特定し、定義することに集中します。例えば、解決に時間がかかるエスカレーション案件や、壊滅的な深刻さのために通常は迅速に解決できるが、組織としては膨大な労力を要する案件に焦点を当てるというアプローチが考えられます。これらの分野に特化した対策と原因要因を確立し、現在のプロセスをマッピングします。時間とリソースを費やして、プロセスの空白部分やギャップを取り除き、価値のないステップや価値の低いステップを継続的に削除します。少数の重要事項に焦点を当てることで、カスタマーサポート部門は迅速に成果を上げ、持続的な価値を実現し始める。

戦う相手を選ぶ

結論 - それは旅である

最終的には3次元の旅をすることになります。

スキルアップ - カスタマーサポートチームのメンバーが、成功するために必要なスキルとコーチングサポートを受けられるようにする。

プロセスインテグレーション - 習得したスキルとビジネスプロセスの間に明確な関連性があることを確認する。

パフォーマンス・システム・インテグレーション - 新しいスキルやプロセスを使うための職場環境(期待値、対策、ツール・リソース、結果、フィードバック)を確保する。

特定の製品や技術に依存しない合理的なプロセスにより、製品、プラットフォーム、技術を横断したカスタマーケアが可能になります。また、テクニカルサポート環境の複雑化と継続的な変化を管理することで、お客様のビジネスをサポートするための強固なフレームワークを提供します。

 

Kepner-Tregoeについて

Kepner-Tregoe社は、問題解決のリーダーです。60年以上にわたり、Kepner-Tregoe社は、より効果的な根本原因の分析と意思決定のスキルを通じて、世界中の何千もの組織が何百万もの問題を解決するお手伝いをしてきました。Kepner-Tregoe社は、以下のような方法で、コストを大幅に削減し、業務パフォーマンスを向上させるために企業と提携しています。
問題解決のためのトレーニング、技術、コンサルティングサービスを提供します。

関連

Staying in Control - プレッシャー下での思考を改善するためのダッシュボードと指標のデザイン

カスタマー・マニフェスト

私たちは以下の専門家です:

お問い合わせ

お問い合わせ、詳細、ご提案はこちらから