「サポート」、この言葉でいくら...

ですから、「創造的休暇から」という一連の記事を続けています。今回は、「製品サポート」、「技術サポート」、「サポートサービス」などの「ひどい」ことを検討します。



この記事では、チーム管理の問題、通話管理システムの展開、およびサポート部門の責任者の作業の詳細については扱いません。 むしろ、この記事は「IT製品のサポート」の問題の一種の紹介です

すべてはどこから始まりますか

それで、伝統的に、基本から始めましょう。 質問に答えてみましょう。

サポートサービスとは何ですか？

質問は簡単に聞こえますが、答えを出すのはそれほど簡単ではありません。 そして、この理由は、この活動分野の複雑さからはほど遠いです。 理由は、ここに小さな機能があるからです-「サポートサービス」と「サポート」は一般的な概念ではありません。 それらの値は、私たちが検討している特定の状況に大きく依存します。 これを示すために、非常に大ざっぱな例を示します。



「開発と生産」の部門と、販売されたバスの保証サービスを提供する「メンテナンス」の部門があるバス製造会社という会社があるとします。 キャンパス/オフィスキャンパス内の特定のルートに沿って従業員を運ぶためにバスの1つを購入した消費者という2番目の会社もあります。 したがって、この特定の例では、次の図を取得します。



消費者企業には次のものがあります。

• ユーザーはバスの乗客です
• 「サポートサービス」は、ディスパッチャ、またはヘルプデスク、およびバス自体のコンダクターです。

乗客が困難を解決できるようにします。



そして、製造会社には次のものがあります。

• 開発者は「開発と生産」の部門です
• また、「サポートサービス」-この場合、それはすでに「技術的なメンテナンス」の部門です

明らかに、あるタイプの企業で採用されている「サポートサービス」の仕事の組織へのアプローチを別のタイプの企業に完全に移そうとする試みは、少なくともスマートではありませんが、しばしば有害です。



しかし、これはバスの例で明らかに見られますが、何らかの理由で、ITの場合にはまったく明らかではありません。

もう少し理解してみましょう。



正式には、ソフトウェア製品のサポートおよびサポートサービスはITSMとCRMの接合部にあります。 そして、それが通常起こるように、いくつかの乳母は監督なしで子供を持ちます。 さらに、管理者の仕事の組織、IT機器の発行とメンテナンス-多くの場合、問題はありません。 それは一種のパラドックスであり、あちこちにIT領域があり、あちこちに非常に有能な従業員とマネージャーがいるように見えますが、ある場合にはすべてが基本的にそれ自体で十分に機能し、他の場合はそれがどのように機能するかです。 違いは何ですか？ 機器、オペレーティングシステム、Webサービスのサポートを提供できるのはなぜですか？同時に、会計システム、データ分析システム、ドキュメント管理、ビジネスプロセス管理などのビジネスプラットフォームのサポートと同時に、多くの困難がありますか？ 何がキャッチでしょうか？



もう少し例を挙げましょう。もう少し主題に近づきます。 そのため、ある種の「標準」構成の会計システムを使用する会社があります（どの会社でも）。 構成は標準であるため、会社には使用システムの修正や変更を行う開発者のスタッフがいません。 ユーザーがこのシステムを使用すると、さまざまな種類の問題や質問があることは明らかです。 ユーザー、これらはITからやや離れた人々（「販売員」、会計士、上司など）であり、実際に内部でどのように機能するかの詳細を理解することは簡単ではなく、時間がないだけです。



この時点で、もう少し詳しく見ていきましょう。 ですから、私たちにとってこれは純粋な会社、つまり消費者です。 つまり、会社自体は使用する製品を生産するのではなく、側で購入します。 この場合、「サポートサービス」がない場合、エンドユーザー自身が発生する問題を解決しようとします。 その結果、多くの時間、神経が失われ、データの奇跡が始まります。 一般に、すべてがいつものようになります。



そして、新しく組織された「サポートサービス」の責任者は、2つの主な質問を自問しています。

-「サポートサービス」の目的は何ですか？ 彼らは誰のために働いていますか？

-このサービスの理想的な従業員は何ですか？

答えに問題はないはずです。 このサービスは、製造業者/供給業者との作業を引き継ぎ、エンドユーザーが不要な技術的な操作から保護するために作成されます。 つまり、「サポートサービス」の結果の顧客（消費者）はエンドユーザーです。



さらに先に進みますが、このサービスの従業員の仕事をどのように評価するのでしょうか？ 問題を解決する速度は？ 会計システムの構成やプラットフォームの内部に入ることはできないし、すべきではないため、可能性は高いです。 したがって、私たちは少し誇張し、彼らのタスクも非常に明白であることが判明しました-それを確認してください：

• 推奨および/または利用可能なアクションを実行するとき、システムは期待どおりに機能しません。
• 有名な「タンバリンとのダンス」は役に立ちません。
• 問題の説明は、ユーザーの言語から使用するシステムの用語の言語に翻訳されます。
• 必要な情報はすべて収集され、できるだけ早くメーカー/サプライヤーに転送されます。
• ユーザーは、可能であれば別の方法で問題を解決する機会を得ました。

最後の点は、残念ながらまだまれですが、実生活では非常に望ましいものです。



ですから、現時点では、一般的に正しい方向に向かっています。 これについては、ITILからの本、多くの記事が読まれ、そしてロジックもこれを裏付けています。 そして実際、啓示はありません。 しかし、彼らは次に来るでしょう。



それで、私たちのマネージャーはすべてをうまくやりました、誰もが幸せであり、すでにこのまさに会計システムのメーカーである会社は彼/彼女に彼らの「サポートサービス」を確立するように招待しました。 そして、ここから奇跡が始まります。 新しい場所で、彼/彼女は再び以前と同じ質問をします。

-「サポートサービス」の目的は何ですか？ 彼らは誰のために働いていますか？

-このサービスの理想的な従業員は何ですか？

そして、この場合には、答えは私たちが前に見てきたものから、非常に多くの異なるものとしています。 メーカー - だから、私たちは、会社を扱っています。 つまり、同社は他の企業で使用される特定の製品に自分のアイデアを思い付くし、実装する開発者のスタッフを持っています。 そして、それは、「顧客サービス」が存在しない場合に、すなわち、開発者が一度に問題（自分の意見に）些細で彼らの主な仕事との契約から気を取られることを余儀なくされていることが判明し、「宇宙は完璧な会計システムを必要とします。」 つまり、この場合には、顧客サービス、「顧客サービスは、」もはやユーザー、開発者ではありません。 そして、部門が収集し、それらを与えていることを要求することはもはや必要であるが、ここでは、このサービスは、問題自体のほとんどを解決することができたことは必要ではありません。 あなたは違いを参照してください？



これは、類似した名前、および一見一つの機能として自分の仕事のための要件の完全に異なる部分であることが判明しました。 我々は二つの極を持っているので、2つの清潔で、かなり反対は「顧客サービス」の組織に近づきます。 残念ながら、この違いは非常に少数の人々が見て、それを見ている者の一人はしばしば無視されます。



消費者 - すべての後、同じITILは、この差は解釈の大部分は、正確に企業のためのアプローチに基づいています表すものではありません。 このような理由から、私は企業のための「支援」のバージョンを好む - メーカーは、「顧客サービス」、「ソフトウェアを維持省」と消費者の企業内の他«サービスデスク»からそれを区別するために、「技術サポート」と呼びます。

総括、私たちは以下の画像を取得します：

	カスタマー・サポート	ヘルプデスク（技術関連）
カスタマー（顧客サービス部門）	エンドユーザー	部門の開発/テスト
従業員のタスク	問題を理解します。 期待通りに利用できる推奨および/またはアクションの下で、システムが機能しないことを確認してください。 必ずこのような問題/課題を解決するための周知の方法があることにする - 助けをしないでください。 お使いのシステム言語の観点から言語の使用者に問題の翻訳説明。 すべての必要な情報を収集し、プロデューサにできるだけ早く送信されることを確実にします。 ユーザーは、それが可能な場合でも他の方法で、できるだけ早く彼らの問題を解決することができたことを確認してください。	問題を理解します。 外観/再生の問題のための条件を特定します。 システムおよび/または開発者の最小限の関与とを変更することなく問題の可能な解決策を見つけます。 知られているかどうかわから満足します/このような問題/課題を解決するための方法を発見しました。 問題の記述言語の開発者/システムアーキテクトを翻訳。 デザイン/建築家は問題が真である説明を理解していることを確認してください。
従業員のための要件	同じ言語でユーザー対象エリアと話の十分な知識。 用語やシステムの機能の十分な知識。 精神的に友好的かつ持続可能です。 質問をすることを恐れてはいけません。 説明できます。	用語やシステムの機能の十分な知識。 対象地域/企業顧客を理解していることが望ましいです。 ソフトウェア開発の経験と専門知識を持っているし、同じ言語の開発者と話を。 質問をすることを恐れてはいけません。 説明できます。 問題の根本に掘るための欲望と持続性を持っています。

もちろん、実際の生活の中で、私たちは、「食材」マネージャーは、すでに適切なプロセスを構築し、SLAを準備し、最高のは、特定の組織の条件を満たしている、独自のレシピを準備することができます知って、それにもかかわらず、妥協のいくつかの種類を使用する必要があり、これら二つの正反対の混合が、これは（サポート/サポート部門を含む）すべての利害関係者の利益を満たしています。

どのような通常来ます

まあ、ボーナスとして、失敗したの短いリストは、支持体の組織に近づきます。

1. チャットボットの使用。 最近、この傾向は勢いを増しており、その多くは、これは従業員の数を節約するための素晴らしい方法だと思います。 この場合、誰でも人々はサポートおよびメンテナンス部門に回したため目的について考えていません。 だから、チャットボットやその他の検索機能は厳密に必要であり、利用者はいない（いわゆる「知識ベース」の不十分な構造化または複雑で入り組んだ組織の場合）または不本意（過剰雇用や怠慢に起因する）ことができます自分で情報を検索します。 ユーザーが理解していないか、十分に迅速にオンラインドキュメントに記載されている情報を見つけることができない場合にのみ、つまり、それはこの高度な検索ツールやチャットボットに役立ちます。 任意の非標準または技術的な問題は、チャットボットは触れてはいけません。 これは、残念ながら、非常に少数の人々は理解しています。 もちろん、ユーザーが最終的には、関連するウェブサイト上に置くのドキュメントや記事を使用して取得するには、すでに描かれている部門と簡単な質問のスタッフに連絡していない偉大な要望があります。 しかし、より正確かつ容易にそれが行政手段ではなく、すべてを劣化させる試みによって解決されます。 そして第二の点は、ヘルプへの接続のサポート「は、各チワワ」のユーザーは、商業的に最も有利な解決策ではありません。 一方で、同社が提供ソリューションのための責任を取り、他の上 - それは補償されないようではありません。 言い換えれば、導入/専門サービス部門から、このアプローチを選択するパン。
   
   
   
   
2. 従業員貯蓄では。 非常に人気のサポートのレベルの職員の資格を分割し、第1のサポートラインに「非常識」（すなわち安い）のセット。 もともとそれはサポートのレベルへの分割が機能していない適格な文字であることを意味しますが。 それはチャットボットと前項の変種として判明します。 利用可能である価格のため、従業員の数を大きなngのB セット -スタッフの管理は、単に問題のあるヘッドオンを解決するために、部門のユーザー、および試行の従業員との相互作用を整理することはできません。 その結果、サービスの品質だけで低下し、経営者の完全な驚き、「資格」の従業員への負荷が増加のみ。
   
   私は特別な教育支援スタッフの話ではありません。
   
   
   
   
3. サポートのために適用する主な方法として、携帯電話を使用します。 組織部門の支援を受けて、多くの場合、それを見て実際には、かなり奇妙な/サポートは、コールセンターの作成を支持しました。 私たちはITシステムのサポートについて話している場合は、電話一本は、ポータル、フォーラムまたは電子メールを通じて提出2-3の事件を処理するなどの資源のほぼ同じ量が必要です。 コールは、通信の種類は、組織の観点からサポートユーザおよび/または顧客に合理的で便利です（部門用）いつも高価ではない、時には必要かつ重要ですが、。 あなたは、製品の品質の監視および/またはサービスの詳細には触れていない場合でも、ユーザー/顧客、経験とアクセスのさえ疑問に、チーム内の知識の普及と快適な通信の組織は、電話通信で、追加の労力とコストを必要としています。
   
   
   
   
4. 事務局としてのサポートを使用。 言い換えれば、ときのサポートの最初の行は、部門の派遣の一種としての役割を果たしており、右の人々にユーザーに指示し、遭遇した既存の問題や課題に応じました。 実際には、それは、同社が「何かが間違っていた」持っていることを警告する「ベル」です。 しかしサービスをサポートし、CRM（カスタマー・リレーションシップ・マネジメント）の不可欠な部分である - 顧客とのリレーションシップ・マネジメントが、それはむしろそれに代わるよりも、の一部です。 顧客は、彼が製品のライセンスの有効期間が終了したことを問題とヘルプデスクを呼び出すときしたがって、それはCRMは、ダニのための会社では略語、専門部署であることを意味します（この場合は、セールスチームは）その直接以外に従事しました作品。 他に - とスタッフのサポートので、/護衛は、一方では、顧客や商業部門、ライセンス部門、フルフィルメント部門間「の上に手を」動作します。
   
   
   
   
5. イミテーションスタッフのサポート部門は、このような「マリア」として、名前だけで署名された「個人」のサポート 、「ジョン」など もちろん、私は、海外一方で、一般的であり、ということを暗示「温かく友好関係」を理解し、他の上 - やや虚栄心西部のユーザーを（サーバントが名前を持っていなかった）うぬぼれ、それでもそこにそれだけで理にかなっています非常にまれなケース。 実際には、ITサポートがあるだけで困難を作成します。 最も単純な状況：4人の部門に名前を運ぶ「アレックス」（実際のケース）、およびオフィスでの環境の力にそれらの1つだけである（第2 - 休暇に、第三 - 病気は、第四 - 出張で）とのいずれかで問題があります一定に応える事件「アレックス」。 予想通り、オフィスで、何が起こっていたかわからなかった1。 何スーパーバイザ/リーダーや部門のヘッド、顧客は「アレクセイ」で受信したいくつかの言葉のアドバイスを参照する場合は？
   
   
   
   あなたが特定のアドレスとき一方、「ヒョードルを、」それはあなたがこの男を知らないので、誰が植物「親しみやすさ」と一般的には、どのようにあなたは必ずその「ヒョードル」ことができることを想像していない、常に快適ではありませんそれは彼の本当の名前ですか？
   
   従って、任意の応答の署名で、同社は、メッセージを送信した人のうち少なくとも姓と名である必要があり、常にあります。 でも手紙場合は/メッセージは、全体としての集団から来ています。 また、場合上訴プロセスは、その後、彼は会社からの参加者の一定のスイッチングせずに、最後までこの特定の事件に取り組んできた、1人の従業員を始めました。 変更は、一時的にしか必要に応じて（例えば、病気や過負荷のより重要な要求、または仕事が従業員「サポート」「拾った」）と、新たな責任者は常に自分自身を紹介しています。また、アプリケーションでの作業が終了するまでになりますかどうかを示す必要があり、またはときにのみ許可されていますそれを処理します。 一般的に、これはすべての非常に奇妙であり、行政の仕事の基本は、多くの経営者は、単に持っていないようです。
   
   
   
   
6. 作成部署«お客様の成功»、«技術イネーブルメント » と他«フルフィルメント»。 ここでも、それは主に、参照方法の「アジャイル」開発の歓喜に関連する最近の流行は、あるとフィードバックを提供しようとする試み、彼らは、言うである「額に。」 一般的に、人々はすでに働いて近く何とか彫るようになった - 残念ながら、現実には、通常の部門の導入として正常な動作を整理して失敗したことを示し、トレーニング、特にサポート/ユーザーサポート、およびCRMの実践の実装であります部門、新しいバックアップサービス。 残念ながら、かなり頻繁に同じ成功を持ちます。
   
   
   
   
7. 「カーゴ・カルト»ITIL / ITSM。 実際には - これは、サポートサービスの組織の最大の問題です。 フレームワークの成果物は、どのように、なぜそれがそうである、それらの導入および私たちは何のために、何をしているかを明確に理解する前に十分に深い分析を必要とします。 例えば、CMDBを取る - 設定/設定とその変更の履歴のデータベースを。 私たちがサポート特定のビジネスプラットフォームを提供する場合、我々は必要なものの情報/属性とその変化（例えば、会計システム）：簡単な質問を考えてみましょうか？ そこ可能であることすべてを追加する誘惑があるが、十何千もの顧客の持つ「1C」レベルの企業のために - それは、不必要な詳細のリポジトリなしにシステムを変換します。
   
   
   
   しかし、より頻繁にCMDBを作成するよりも、単純に文字とでも紙の上に、断片化ファイルの情報を格納することによって無視されます。 問題は、選択基準の設定/変更パラメータは、（同じ3番目の本«ITILサービストランジション»で、例えば）ITILのガイドラインに与えられていないということです。 そこ分類の唯一のいくつかの例ですと、管理作業の例にかかりました。 そのため、建築家のITILの実装の資格、経験と勘に - すべてを依存しています。
   
   
   
   私はこの小さな「は、それ自体でITIL / ITSM»の知識は保証は何もない、そしてそれは、この特定のケースであり、それはその仕事の成功の印である何のためのサポートがあることをまず理解する必要があるという事実に光当てる願っています。
   
   
   
   
8. 「カーブ»KPI。 こちらの商品は、全ての「競技外」だけでなく、すべてのパフォーマンス・メトリックです。 彼らは必要なもの - 今、誰もが理解しています。 しかし、ここで質問です：「なぜ」と「？何があるの」 - すでに経営者の膨大な数の「トリッキーな質問」です。 同じことは、サポート/メンテナンス部門の有効性の評価の場合も同様です。 最も単純な例：部門の単一の従業員の有用性を評価するためにどのように？ 処理されたインシデントの数？ もしそうなら、これは週の100の解決の問題がより良い10以上であることを意味するのでしょうか？ 実際の生活の中で - ません、その後。 ただ無意味 - ヘッドオンの数を比較し、単に最も簡単な - これらの10件の事件は非常に複雑かつ重要な、と百することができます。 残念ながら、少数の人々は、KPIの本質は日常的、反復の数値特性、及び作業/プロセスのと同じタイプであることを覚えておいてください。 したがって、数字はそれは一見思えるようサポートスタッフの寄与はそれほど簡単ではありません示し、それは一定の整数メトリックで表現されます。
   
   
   
   また、サポートサービスの分析は、私たちは、外部のサービスプロバイダおよび/または開発部門の仕事の品質を推定することができます。 活動の分析のこの部分は、しばしば無視します。
   
   

これで私はすべてを持っています。 あなたのコメントや妥当な観察は - 強く推奨します。



すべての人に幸運と成功を。











画像ソース：



1.「フローズン」犬- ここに

2.「厳しい」犬こちら

3.コール・センター： ここに

4.バスサービスはこちらから