モジュラーシステムのテクニカルサポートの詳細

こんにちは



私の名前はアレックス、私はテクニカルサポートエンジニアです。 今日は、プラットフォームソフトウェアの詳細を考慮して、ヘルプデスクがDoksVisionでどのように構築されるかについて説明します。 おそらく、この情報は、ヘルプデスクで既に密接に連携している企業や、顧客とのコミュニケーションのためのチャネルを構築しようとしている企業に役立つでしょう。 ちなみに、多くのDocsvisionパートナーが既に私たちの経験を活用しており、ヘルプデスクでヘルプデスクを実装しています。







さまざまなITサービスの提供に焦点を当てたビジネスを展開するすべての企業は、顧客志向を目指しており、DoksVisionも例外ではありません。 他の多くのベンダーと同様に、私たちは自分でソフトウェアを作成するだけでなく、その技術サポートのためのサービスも提供し、高品質で時間通りに提供するよう努めています。



多くの場合、企業は技術的な観点からさまざまな種類のユーザーサポートサービスを提供しているという事実に出会いました。 Habréには、このテーマに関するいくつかの記事がありますが、ここで別の記事をご覧ください。

開始する

ソフトウェア開発プロセス（特に大規模なソフトウェア）は、さまざまなスキームに従って実行できますが、最終的には使用できるいくつかの重要なポイントとツールになります。

•開発環境。

•バージョン管理システム。

•タスクトラッカー。

•自動および手動のテストシステム。

•バグトラッカー。

•ヘルプデスク。



もちろん、いくつかの側面に触れるだけで、ポイントを補完、結合、または削除できます。小さなホリバーを開始できます:)

しかし、今日の私の目標は異なります。

いくつかのバージョンの同時サポート

ソフトウェアを発明し、開発し、テストし、大航海（「船」と呼ぶ）にリリースし、サポートを開始する必要があります。 会社とDocsvision EDSの歴史はかなり前から始まっていたため、2014年にはプラットフォームのいくつかのバージョンがサポートされています。

• Docsvision 4.5
• Docsvision 5.0
• Docsvision 5.1
• Docsvision 5.2
• Docsvision 5.3
• Docsvision 5.X

プラットフォームの各バージョンには、フルネームで少なくとも2つのリリースバージョンがあります。たとえば、Docsvision 5.3.2529、つまり 一度に約10バージョンが判明します。 プラットフォームの約40個のモジュールを追加する価値があります。 さまざまな製品とリリースバージョンのDocsvisionをすべて、並行して毎日サポートしています。

一部のお客様は、以前のバージョンから協力してきました。 企業の電子文書管理システムは、ソフトウェアベンダーとの長期的なパートナーシップを意味し、着信文書と発信文書の流れが1日止まらない組織に対する技術サポートが重要な役割を果たします。

初期

Docsvisionの最初のバージョンから今日まで、私たちは技術サポートを提供してきました。通常のエントリポイントは通常のメールでした。 メールのユーザーが問題を報告し、スクリーンショットとログを添付しました。 通信中に、緊急の問題は解決され、知識ベースが蓄積されました。また、当社の拡大と顧客数の増加に伴い、それらからの呼び出しの数も増加しました。 それらを処理するには、受信したすべてのデータを構造化するのに役立つソリューション（またはソリューションのセット）が必要でした。

会社の今日までのヘルプデスクプロセスの始まりは、DVManagementという名前の強力な「石」です。 そして今が、社内で使用しているものにスムーズに切り替えるときです。

内部ツール

DVManagementは、Docsvisionプラットフォームがインストールされたサーバーであり、当社の腸内にあり、技術サポートエンジニア（だけでなく）が職場で働いています。 これで、プラットフォームの最新リリースバージョンがサーバーにインストールされ、特別な「カード」が追加されます。これを発行と呼びます。 DVManagementは、実際には、内部および外部の呼び出しを処理するためのバグトラッカーとヘルプデスクの機能が追加された当社のプラットフォームです。

•機能の実装に関する新しい要件の記録。

•記録エラー。

•修正の記録（知識ベース）。

•テストケース（少量）。

•To Doプラン（少量）。



「プラットフォーム」は非常に大きいため、社内のすべての部門が「当社」のバグトラッカーのみを使用するわけではないため、作業の一部はTeam Foundation Serverリポジトリ（および以前のSourceSafe）で行われます。



TPの従業員は、次のような発行カードを毎日使用しています。







問題は、2つのサポートツール間のリンクであり、「TP-Software Engineer Engineer」という形式の相互作用としても機能します。



カードには、記入する必要のある必要なフィールドがあります（製品バージョン、顧客会社の名前など）。

問題に対するソリューションのステータスに関する追加情報を含むいくつかのタブがあり、次のような標準オプションがあります。



•ファイルとコメントの添付（バージョン付き）;

•通信履歴エンジニア->開発者（テスターまたはアナリストもこのプロセスに含まれる場合があります）;

•「エラー」のステータスの設定。

•このエラーの迅速な修正の要求。

•複数のカードをリンクする機能。



以前は、外部の対話ツールが導入される前は、クライアントとのすべての通信はメールからDVManagementに転送されていました。 これはすべて保存され、大規模な知識ベースとして使用されます。 外部サービスの出現により、プロセスがわずかに変更されました。追加のフィールドとオプションが発行カードに追加されました。 問題のステータスが変更されるたびに、またフィールドが変更されるたびに、この問題の作成者は変更のメール通知を受け取ります。 言い換えれば、何も気付かれることはありません。



現在、システムにはすでに約7000件の問題が作成されており、テクニカルサポートスタッフが使用しています。合計で、2006年から2014年までに約60,000個のオブジェクトがシステムに作成されています。 「より良い」とは言いませんが、知識ベースは毎日更新されます。 これは、たとえば、新しいサポートスタッフをトレーニングする場合に非常に役立ちます。

外部機器（Full Zen）

DVManagementとともに、着信アプリケーションをより便利にキャプチャするツールが必要でした。そして、2011年に作業を開始したZendeskが選択されました。







Zendeskは、私たちとお客様の両方が利用できるサイトの形でサービス（SaaS）として提供されます。 これは非常にアクセスしやすいシステム（Amazonでホスト）であり、Zendesk内で質問が呼び出されるため、通話、アプリケーション、またはチケットの操作を特に目的としています。

DoksVisionには独自のテクニカルサポートポータルがあり 、登録しなくても確認できます。 また、登録ユーザーはフォーラムで当社に書き込み、有料のサービスパックを使用して、この期間（たとえば1年以内）にアプリケーションを作成できます。



いくつかのキーポイント：

•作業するには、「エージェント」と呼ばれるサポートエンジニアのアカウントを作成する必要があります。 合計で、DoxVisionにはこのようなエージェントが約30個あります。

•顧客がサポートエンジニアから質問したり回答を受け取ったり、相互に通信したりできるフォーラムの広範なシステムがあります- 開発フォーラムの典型的な例（登録が必要です）。 合計で、このようなセクションが12個以上あります。

•イベント電子メール通知システムの強化。

•カスタムSLAのサポート。

•アクセスコントロールシステム（アカウントにはさまざまなカテゴリがあります-エージェント、エンドユーザー、フォーラム管理者、グローバル管理者）。

•エンドユーザーと企業の便利な結合。

•必要に応じて、同じ会社の複数のユーザーが並行して通信に参加できます。

•外部からの特定のイベントを待機する拡張アプリケーションステータス（「オープン」、「クローズ」、「解決済み」を除く）。

•マクロとトリガーのシステム（例：より「自由なエンジニア」のためのアプリケーションの配布）。

•多くのイベントに関する拡張レポート。

•すべてのプラットフォーム用のモバイルアプリケーション（どこからでもリクエストに応答できるようになりました）。

•ソーシャルネットワークとの統合。





Windows Phone 8のサンプルモバイルアプリケーション



以下は、サポートエージェントインターフェイスのスクリーンショットです。







ポータルに登録されたユーザーは、自動的に機能するアプリケーションを作成できます。 この場合のエントリポイントは、サポートポータル自体（アドレスで利用可能）とメールです：特別なアドレスに送信された手紙はすぐにリクエストに変換されます-これはZendeskの別の機能です。



ヘルプデスクでアプリケーションを作成する場合、ユーザーは特定のフィールドに入力し、問題の性質を説明し、必要に応じて追加情報（スクリーンショットまたは何らかのログ）を添付する必要があります。



Zendeskでは、作成されたチケットに完全にカスタムフィールドを含めることができます。ドロップダウンリスト、ラジオボタン、または管理者が事前定義した値のリストから選択することができます。

このシステムで作成されたすべてのアプリケーションは、指定されたSLA内で、購入したサービスパッケージに応じて処理されます。 ところで、ユーザーは重要度を選択することができます。



リクエスト数のダイナミクスについて話すと、下の写真で見ることができます（2011年はZendeskの実装年です）。 たとえば、2013年が採用されますが、これはこれまでにアプリケーション数で「リード」しています。











月ごとに解決されたアプリケーションの数を観察することはより興味深いです。 上記のチャートでは、1か月あたりの作成数と、同じ月にそれらのどの部分が解決されたかを確認できます。



また、各エンジニアの統計が保持されるため、1週間以内にKPIを収集できます。 原則として、より複雑な問題はより長い時間解決されるため、量は週にエンジニアがうまく働いたか悪いかを常に示すわけではないことに注意してください。

EDMSのコンテキストでのヘルプデスクの機能

Zendeskは、お客様やお客様とのコミュニケーションのチャネルを新たなレベルに構築するのに役立ちます。 ユーザーが作成したアプリケーションは、既存のSLA（ サービスレベル契約 -ITサービスプロバイダーとこのサービスのユーザーの相互責任を定義）を考慮して処理されます。 また、責任について話し始めたので、NDA（秘密保持契約 ）についても言及します。送信されたデータの機密性を気にする顧客の前に、第三者に転送しないことを約束します。 Docsvisionには、作業中に転送されたユーザーデータを「非個人化」するツールもあります。TPエンジニアは、ユーザーの個人データを見たり、クライアントディレクトリの機密情報を読み取ったりすることはできません。



規則によれば、TPサービスの営業日は8時間ですが、エンジニアの作業は、すべてのエンジニアの時間を分散し、可能な最大時間（たとえば、8：00から20:00まで）をカバーするように設計されています。 これは、異なるタイムゾーンのお客様がテクニカルサポートを必要とする可能性があるためです。



時刻に応じて、アクティビティも変わります。





ご覧のとおり、ピークは営業日の真ん中にあります。 仕事は本格的です。



多数のDocsvisionバージョンが同時に動作するため、エンジニアはDocsvisionのすべての可能なバージョンとインストールされたモジュールの組み合わせを「手元に」持っている必要があります。そのような場合、約40台の仮想マシンを使用します。VmWareテクノロジーのハイパーバイザーを使用します。



しかし、多くの場合、Windowsのすべてのバージョン、すべてのNet Frameworkおよびバーコードスキャナー（これも使用します）の大きな「動物園」でさえ、ある時点では不十分な場合があります。



たとえば、物理マシン（仮想マシンではない）またはタッチスクリーンを備えたデバイス（モノブロック）でのみ安定して再現される予期しない動作が見つかることがあります。

修正プログラムの柔軟性

システムの操作で重大なエラーが見つかった場合、場合によっては、パートナー（およびユーザー）が製品の新しいバージョンのリリースを待ったり、システム全体を更新したりする時間がありません。これは多くの場合時間がかかり、全員が待つ準備ができていません。

多くのエラーは、その除去にそれほど労力を必要としないため、運用上の修正を利用して解決します。 サーバーについて話している場合は、1つまたは2つのライブラリを変更するだけで、パッチがインストールされます。 クライアントジョブを使用すると、さらに簡単になります。 修正は、リクエストに応じて取得でき、累積パッチの形でパブリックドメインに配置できます。

緊急技術サポート

重要なシステムのダウンタイムを最小限に抑えるため（企業でのドキュメント管理も例外ではありません）、DoxVisionは緊急サポートサービスを提供しています。 より高速なSLAの一環として顧客との対話を開始します。このような場合の反応時間は1時間を超えず、ほとんどの場合、エンジニアはオンラインで作業します。 この場合、お客様とのあらゆる可能な通信方法（Skype、Lync、リモート接続）を使用して、問題を迅速に解決します。 必要に応じて、時間外に作業が行われます。 したがって、問題を特定し、修正プログラムをリリースする（必要な場合）時間は大幅に短縮されます。

テクニカルアカウントマネージャー

この名前で、テクニカルサポートサービスの専任のスペシャリストが働いています。 この場合、顧客とテクニカルサポート間の対話プロセスの制御性が向上します。 エンジニアは、 1人の顧客からのアプリケーションのコーディネーターであり、着信アプリケーションを監視し、必要に応じて、より効果的なソリューションの手段を講じます。 いわゆる 「単一のウィンドウ」では、標準の質問と関連する質問の両方を尋ねることができます。 この場合のエンジニアは、「普遍的な兵士」の形で表示され、技術的および組織的な問題の両方を処理します（電話会議の開催、行われた毎週の作業に関するレポートの提供など）。

今後の計画

近い将来、技術サポートプロセススキーム自体は変更されることはほとんどないでしょうが、会社内および部門内で作業を適切に配置することにより、すべてを少しでも良くしようと常に努力しています。



チケットを完了するたびに、チケットを作成したユーザーは、「好き」または「嫌い」をクリックして、エンジニアの仕事を評価するように招待されます。 このように形成された評価は、96％から99％の範囲に保持されます。これは、別のページですべてのユーザーが利用できます （データは動的に変化します）。



内部規制に従って、四半期ごとにユーザーにインタビューし（ Polldaddyを使用）、応答速度、礼儀正しさ、情報の完全性、最初の反応の時間などの項目に関する作業を評価するように依頼します。 このデータを収集することにより、特定の結論に基づいた応答が得られます。 興味深い要件の1つは、エージェント（Zendesk内で直接チャットまたはSkype）とリアルタイムで通信する機能、問題をより高いレベルにエスカレートする機能、他のヘルプデスクシステムと統合する機能、または（顧客からの）レポートを作成する機能です。



しかし、技術的なツールとは別に、ヘルプデスクの従業員の仕事は別の方法で影響を受ける可能性があります。ある種のダッシュボードは優れた視覚的ツールであり、エンジニア（およびマネージャー）がリアルタイムで（たとえば、テレビ画面で）「書き込み」アプリケーションを追跡できると思います視覚的なグラフの形で。



また、将来の計画もあります-毎日の会議（SCRUMに似ています）で、現在の作業について話し合うことができます。ところで、QAと開発の同僚は、そのような会議を長い間開催しています。



弊社で構築されたヘルプデスクモデルは、お客様にとって便利であり、特定の段階でそれぞれが内部サポートの組織に直面しているため、パートナーと共鳴します。 いくつかのパートナー企業は、当社の経験と知識を活用して、同様のヘルプデスクを既に実装しています。



あなたの経験を共有する準備ができたら、コメントしてください-私たちはそれを議論します。