小規模企業のリモートサポートを運用する

ビジネスが大きくなる前に、リモート サポートの管理が難しくなります。かつてはすべてのコンピューターを認識していた 2 人が、突然 2 番目のオフィス、新入社員、および共有ワークステーションと個人ワークステーションの混合を担当することになる場合があります。接続ツールは引き続き機能しますが、このリクエストに属するデバイスはどれか、サポートできるのは誰か、最後の修正はどこに記録されたかなど、周囲の疑問はあまり明確になりません。

中小企業には、これらの質問に答えるために複雑なサービス管理プログラムは必要ありません。リクエストを受信し、デバイスを識別し、責任を割り当て、作業を完了し、不要になったときにアクセスを削除するための明確な方法が必要です。このガイドでは、GoMyid のリモート サポート ビューとデバイス管理ビューを例として使用して、そのオペレーティング モデルを説明します。目標は、1 人の技術者の記憶に頼らずに、別の人が従うことができるプロセスです。

GoMyid キューを通じてサポート リクエストを処理する

文書化されたキューは、小規模なチームに作業を見つけて進捗状況を確認するための共有場所を提供します。チャット メッセージと記憶されているデバイス ID のみに依存するのではなく、リクエスト レコードを使用して、問題をそのユーザーとグループに関連付けてください。

1. [サポート] > [サポート] を開き、日付とステータスを設定します。対応が必要な依頼を探す場合は、新規または保留中から始めます。
2. タイトル、ユーザー、またはカテゴリの検索を使用して、検索をクリックします。
3. 必要に応じて、別のページ サイズを選択し、適用をクリックします。
4. 対象のリクエストで編集をクリックします。使用可能なフィールドやステータスを変更する前に、ユーザー、グループ、カテゴリ、問題を確認してください。
5. 保存してリストに戻り、リクエストに更新が反映されていることを確認します。

キャプチャされたガイドには、完了ステータスとして Complate というラベルが付けられます。インストールされているインターフェイスの文言を使用しながら、図に従ってそのラベルを認識してください。期待される結果は、現在のステータスと関連する詳細を含む追跡可能なリクエストです。リモート セッションを終了し、誰も作業を処理していないことを示して共有キューを離れるだけでは十分ではありません。

サポート サービスの対象範囲を定義します

チームが担当するデバイスとタスクから始めます。サポートはオフィスのワークステーション、従業員のラップトップ、支店のコンピューター、または一部のビジネス アプリケーションを対象としていますか?スコープを通常の言語で記述します。個人用デバイスが取り決めの範囲外である場合は、要求が届く前にその旨を明確に伝えてください。境界が曖昧だと、すでにストレスの多い問題が発生しているときに、意思決定が難しくなります。

リモートで提供すると予想されるヘルプの種類をリストします。アプリケーションの設定、通常のドキュメントの問題、および一部のデバイスのチェックが適切に当てはまる場合があります。ハードウェアの交換や物理ネットワークの問題により、現場に人員が必要になる場合があります。リモート サポート プロセスでは、失敗したリモート修正をすべて技術者の失敗として扱うのではなく、その境界を特定する必要があります。

いつヘルプが利用できるか、また何が緊急中断としてみなされるかについて合意します。小規模なチームでは、すべてのリクエストに即座に対応すると約束しなくても、対応できる可能性があります。明確な期待は、従業員が適切なチャネルを選択するのに役立ち、技術者が既存の作業を完了する余地を与えます。このプロセスは、はるかに大きな組織から借用したサービス レベルではなく、実際の人員配置を反映する必要があります。

信頼できるデバイス ディレクトリを構築する

便利なデバイス レコードは、このコンピュータとは何なのか、どこで使用されているのか、誰が責任を負っているのかなどの基本的な質問にすぐに答えます。複数の人にとって意味のある名前を選択してください。元の設置者だけが認識できるニックネームは、成長するサポート チームにとって弱い基盤となります。場所と役割は、一貫して使用すると役立つコンテキストを提供します。

ディレクトリ エントリと現在の可用性を混同しないでください。既知のデバイスは、スリープ状態、切断状態、またはローカルの注意を待っている可能性があります。セッションの前に、目的の宛先を特定し、準備ができているかどうかを判断するために十分なコンテキストを確認してください。この区別のトラブルシューティングについては、可用性チェックリストをご覧ください。

デバイス一覧の管理責任者を決めます。重複しているように見えるエントリ、古いデバイス、不明瞭な名前を誰かがレビューする必要があります。これは大規模な管理作業になる必要はありません。装備の変更時に行われる小さな修正は、チームがリストに自信を失った後の大規模なクリーンアップよりも簡単です。

サポートの役割とデバイスのスコープを一緒に割り当てる

各種類の作業を誰が実行できるか、およびどのコンピュータをサポートできるかを決定します。 1 つの支店を支援する人がすべてのオフィスにアクセスする必要はないかもしれません。文書を転送する技術者には、すべての管理能力が必要なわけではありません。 GoMyid の製品概要には、管理者の権限とグループの割り当てが表示されます。これらは、実際の責任を反映する場合に便利なコントロールです。

デプロイメントが個別の管理をサポートする場合は、非公式に共有するアカウントではなく、個人ごとの担当と責任が分かる管理方法を使います。サポート記録により、誰がリクエストを処理し、誰がフォローアップを担当しているかを理解できるようにする必要があります。重要なのは継続性と説明責任であり、通常の支援を困難にすることではありません。管理責任を明確にすると、技術者が不在の場合に他の人に作業を任せやすくなります。

役割が変更されたときにアクセス権を確認します。一時的な割り当ては、誰も取り消すのを覚えていなかったために、ひそかに永続的な割り当てになるべきではありません。従業員の退職、チームの異動、請負業者のオフボーディングにリモート アクセスを含めます。 管理された権限ガイドでは、機能とデバイス スコープがどのように連携するかについて説明しています。

従業員に助けを求めるための明確な方法を 1 つ提供する

リクエストでは、人、デバイス、タスク、観察された問題を特定する必要があります。フォームまたはメッセージの形式は、従業員が実際に使用できる程度に短くしてください。何をしようとしていたのか、代わりに何が起こったのか、作業が妨げられていないかを尋ねます。スクリーンショットは、無関係な個人情報を公開せずに、関連するエラーを表示する場合に役立ちます。

サポートを求める前に、従業員に技術的な原因の診断を要求することは避けてください。彼らは日常的な言葉で症状を説明するかもしれませんが、それは許容されます。技術者の仕事は、これらの観察を焦点を絞った調査に変えることです。有用な取り込みプロセスは、問題がネットワーク、オペレーティング システム、またはアプリケーションに属するものであるかどうかをユーザーに推測させることなく、コンテキストを収集します。

正当なリクエストと予期しない発信者を区別できるように、認識可能なサポート チャネルを使用します。技術者からの連絡方法と、どのような情報が要求される可能性があるかを従業員に伝えます。一貫性は使いやすさとアクセス検証の両方に役立ちます。技術者ごとにプロセスが変わるため、ユーザーは何か異常が発生したことを認識することが難しくなります。

メッセージの量ではなく、業務への影響に基づいて優先順位を付ける

どのような作業が影響を受けるのか、業務を進められない人の数を尋ねます。単一のワークステーションの問題は、それが重要なタスクを停止させる場合には緊急を要する可能性がありますが、いくつかの小さな質問がスケジュールされている場合もあります。決定は実際の結果と結びつけてください。最も強い口調のメッセージや最も上位の送信者だけがキューを決定する唯一の信号であってはなりません。

一時的な回避策と完了した修正を分けてください。従業員が承認された代替プロセスを続行できる場合は、根本的な問題が解決したと宣言せずに、その改善を記録します。これにより、チームは、残っているものの正確なビューを維持しながら調査する余地が得られます。また、同じ回避策がシフトごとに再発見されることも防ぎます。

2 つのリクエストが矛盾する場合は、1 人に推測を任せるのではなく、次のステップと予想される連絡先について説明してください。小規模なチームではすべての遅延を排除することはできませんが、遅延を理解できるようにすることはできます。ステータスを簡潔に更新すると、重複するメッセージが減り、技術者は現在のタスクに集中できるようになります。

一貫したリモート セッション開始を使用する

リクエストと宛先を確認し、目的の作業を説明し、従業員がセッションを一時停止できる方法を確立します。関連する作業を保存し、可能であれば無関係な資料を閉じるように依頼してください。次に、適切なモードを使用して接続し、変更を加える前にデスクトップを確認します。これらの手順は、日常的に行われるとほとんど時間はかかりません。

GoMyid の Windows クライアントは、フル コントロール、ファイル転送、およびコマンド モードを区別します。タスクに合ったワークフローを選択してください。技術者は、選択した機能が必要な理由を説明できる必要があります。リクエストが別の種類の作業に拡張される場合は、元の接続を表示されるすべてのものに対する許可として扱うのではなく、変更について話し合います。

最初のセッションの正確なシーケンスについては、接続のチュートリアルを使用してください。すぐに接続できるほどの経験がある場合でも、同じ目的地と完了のチェックを実行できるようにチームをトレーニングします。慣れることで混乱が軽減されるはずであり、作業を適切なデバイスに結び付けるためのチェックが解除されるわけではありません。

次の技術者に役立つ記録を保管します

役立つサポート ノートには、元の問題、関連するデバイス、行われた変更、およびユーザーが検証した結果が記載されています。すべてのマウス クリックを再現する必要はありません。次の技術者は、元のオペレータに電話したり、無関係な観察の長い記録を読まなくても、何が起こったのかを理解できる必要があります。

事実と理論を区別します。 「この設定を修正した後にアプリケーションが開いた」ということは、「ネットワークがすべての原因だった」ということとは異なります。不確実性が残っている場合は記録します。問題が再発した場合、正確なメモがあれば、自信はあるものの裏付けのない結論よりも、次の調査の良い出発点となります。

後続対応の責任者と継続的なアクセス取り決めを含めます。ベンダーがエラーを確認する必要がある場合、誰に連絡するかを指定してください。ユーザーが一時的な回避策を使用している場合は、何が未解決のままであるかを説明します。資格情報や個人的な文書を日常的なメモに保管しないでください。記録は、機密情報を不必要に保管することなく、作業を説明する必要があります。

支店や分散オフィスにプロセスを適応させる

各拠点には、必要に応じて物理的な作業を手伝ってくれる、認識できる連絡先が必要です。遠隔サポートでは、現場に人がいないと、緩んだケーブルを再接続したり、電源タップがオフになっているかどうかを確認したりすることはできません。障害が起こる前に、現地で協力を得る方法を決めておきます。連絡先は技術者である必要はありませんが、観察結果を正確に伝える方法を知っている必要があります。

ブランチ コンテキストが表示されるようにデバイスを整理します。 2 つのオフィスにある受付と呼ばれるワークステーションは、サポート チームにとって曖昧であってはなりません。ディレクトリとグループは一貫して使用し、取り込み時に場所を確認してください。これにより、忙しいサポート期間中に、見覚えはあるものの無関係なマシンに到達する可能性が低くなります。

各支店の実際の労働条件を考慮してください。接続状況、対応可能な現地スタッフ、営業時間は異なる場合があります。本社での試験運用は、すべての拠点で同じエクスペリエンスが得られることを証明するものではありません。ブランチで代表的なリモート タスクをテストし、実際的な制限を記録します。すべてのオフィスが同様に動作すると仮定するのではなく、その証拠を利用してサポートを計画してください。

ファイル転送のハンドオフを標準化する

サポートでファイルの移動が必要な場合は、コピー元、宛先、およびコピーの理由を特定します。受信者が正しいバージョンを認識する方法について同意します。技術者のデスクトップ上にある Final というファイルは、長期にわたる信頼性の高い引き継ぎにはなりません。ビジネスの通常の命名規則とストレージ規則が存在する場合は、それを使用します。

目的地で結果を検証し、関連する結果のみを記録します。診断のために一時コピーが必要な場合は、タスク後にそれをどこに保持するか削除するかを決定します。リモート セッションを終了しても、そのコピーは自動的に削除されません。 転送検証ガイドには、実際的な手順が記載されています。

サポート デバイスを非公式のドキュメント アーカイブにしないでください。時間が経つと、便利なローカル フォルダーに古い設定、プライベート ファイル、不明瞭なバージョンが収集される可能性があります。必要な資料は所定の業務用保存先に保管し、管理責任者を決めてください。これにより、サポートの継続が容易になり、技術者がコンピュータを変更するときに生じる混乱が軽減されます。

モバイルからどの作業を処理できるかを決定する

モバイル アクセスを利用すると、オンコール担当者はデスクに戻ることなくステータスを確認したり、狭い質問に答えたりすることができます。長時間の入力、詳細なファイル比較、または複雑な管理上の変更にはあまり快適ではありません。技術者がスマートフォンからすべての作業を実行する義務を感じないよう、モバイル作業の合理的な境界を定義します。

GoMyid の Android 概要には、接続ハブ、ランドスケープ セッション、タッチおよびキーボード コントロールが表示されます。チームがこれらのコントロールを使用して実際に実行すると予想されるタスクをテストします。利用可能な機能は、時間的制約の下でそれが最適な選択であることを証明するものではありません。正確さと明確な結果が決定の指針となります。

コンピュータ上で使用されているものと同じアクセス方法と文書化方法を維持してください。簡単なモバイル セッションでも、正しい目的地、合意されたタスク、および終了が必要です。実際の入力に関するアドバイスについては、モバイル サポート ルーチンをご覧ください。短く反復可能なプロセスにより、モバイル ヘルプがより信頼できるものになります。

チームが維持できるオペレーティング モデルを選択してください

クラウドとセルフホスト型の契約では、責任の配分方法が異なります。セルフホスト型の展開では、組織がインフラストラクチャをより直接的に制御できるようになりますが、インフラストラクチャを保守および復旧するために人員も必要になります。クライアントのエクスペリエンスと並行して、それらの責任を評価します。接続が成功することは、長期にわたってサポート プラットフォームを実行する過程の一部にすぎません。

選択した取り決めのサーバー環境、更新、バックアップ検証、およびインシデント対応の責任者をリストします。これらの責任に明確な責任者がいない場合は、展開を拡大する前にそのギャップを解決してください。中小企業は高度なツールを使用できますが、不在の可能性がある 1 人の担当者による文書化されていないインフラストラクチャ作業に依存すべきではありません。

そのパスを検討する場合は、GoMyid のセルフホスト情報と導入時の管理責任に関するガイドを確認してください。製品概要に示されているすべての機能がすべての展開に属していると仮定するのではなく、現在の製品と構成の詳細を直接確認してください。

サポートが役に立っているかどうかを測定する

運用上の疑問に答える指標から始めます。つまり、未処理のリクエストがどれくらいあるのか、どの問題が再発するのか、サポート後に従業員が元のタスクを完了できるかどうかなどです。接続数だけでは、作業が役に立ったかどうかはわかりません。短いセッションは単純な問題を解決する可能性がありますが、より長いセッションは正当な複雑な問題を反映している可能性があります。

指標は背景にある状況も踏まえて読み取ります。 1 つのブランチがより多くのリクエストを生成する場合、そのブランチにはより多くのデバイス、最近のロールアウト、または困難なアプリケーションがある可能性があります。その背後にある仕事を理解せずに、生の合計を従業員や技術者に関する判断に変えないでください。この情報を使用して、改善とトレーニングのニーズを特定します。

繰り返し発生する問題を一緒に確認し、実際的な変更を一度に 1 つ選択します。より明確なセットアップ ガイド、修正されたデバイス レコード、または一貫したファイルの保存先により、繰り返される混乱が解消される可能性があります。目標は、誰も意思決定に使用しない数字でいっぱいのダッシュボードではなく、避けられる余分な作業を減らすことです。

管理可能な初月のロールアウト

承認された小規模なデバイスのグループといくつかの代表的なタスクから始めます。ディレクトリ、オペレータスコープ、リクエストチャネル、セッション終了プロセスを確認します。指示が不明瞭な場合は、技術者と従業員の両方に質問してください。さらに多くの人を登録する前に、これらの点を修正してください。範囲を絞った試験導入は、その教訓をすぐに適用できるため貴重です。

次に、条件が少し異なる場所またはチームに拡張します。実際のサポート タスク、ファイルのハンドオフ、および通常のアクセス削除イベントをテストします。本番環境に不必要なデモンストレーション記録を追加することなく、結果を文書化して保管します。あなたは運用プロセスを検証しているのであって、大量のアクティビティを作成しようとしているわけではありません。

最初の月の終わりに、管理責任と未解決の課題を確認します。元の技術者が不在の場合、別の人が作業を続行できることを確認します。展開が成功すると、インストールされたソフトウェアだけでなく、使用可能なプロセスと維持された記録がビジネスに残ります。チームが信頼できる経験を積むにつれて範囲を調整します。

繰り返しのリクエストを有益なガイダンスに変える

同じ質問が何度も表示される場合は、ユーザー向けの説明に小さな改善がないか探してください。正しいダウンロード場所を示すスクリーンショットまたは一般的なアプリケーション設定の簡単な説明により、別の通話が妨げられる場合があります。技術者の社内用語ではなく、従業員のタスクに関するガイダンスを作成し、問題に詳しくない人に試してもらいます。

サポートに戻るルートを明確にしておいてください。ガイドは、ユーザーが慣れているタスクを完了するのに役立つものでなければならず、画面が異なる場合にユーザーを立ち往生させないようにする必要があります。いつ停止して助けを求めるべきかを述べます。アプリケーションやビジネス プロセスが変更されたときに手順を確認し、環境に適合しなくなったアドバイスを廃止します。正確な回答を集めた控えめなコレクションは、古い修正を集めた大規模なライブラリよりも役立ちます。

よくある質問

デバイス管理は非常に小規模なチームにとって役立ちますか?

特にデバイスが共有されている場合、複数の場所に分散している場合、または複数の人によってサポートされている場合に、デバイス管理が役立つ場合があります。この利点は、特定のデバイス数ではなく、正確なデバイス情報と明確な管理責任によってもたらされます。シンプルなディレクトリと明確な責任から始めて、環境内の実際の問題を解決する管理機能を使用します。

無料のリモート アクセスには、すべてのビジネス管理機能が含まれていますか?

個々のリモート アクセスと集中管理が同じ条件や可用性を持つと想定しないでください。ビジネスに必要な機能については、現在の GoMyid サービスを確認してください。 無料使用評価ガイドでは、セッション期間をより広範な管理および導入に関する決定から分離しています。

フルタイムの IT 技術者が必要ですか?

必ずしもではありませんが、それぞれの業務には責任者が必要です。誰がアクセスを承認し、リクエストを処理し、デバイス記録を管理し、チームのスキルを超えて問題をエスカレーションするかを決定します。外部サポートが関与する場合は、その範囲とアクセスの終了方法を定義します。パートタイムの取り決めは、その境界が明確である場合に、より効果的に機能します。

緊急のリクエストにはどのように対応すればよいですか?

業務への影響を利用してリクエストに優先順位を付け、エスカレーション パスを明確にします。誰の業務が止まっているか、および承認された回避策が存在するかどうかを確認します。緊急性は不必要な遅延を短縮するものであり、ID と宛先のチェックを排除するものではありません。間違ったコンピュータに急いで接続すると、サービスが復元されるどころか、さらなる作業が発生します。

セッションの詳細をすべて記録する必要がありますか?

タスク、変更、結果、フォローアップを理解するために必要な情報を保管してください。記録が完全であるように見せるためだけに、無関係な個人的な資料を収集することは避けてください。導入で利用可能なレコードを適切に使用し、組織の処理ルールに従ってください。簡潔で正確なメモは、多くの場合、誰もレビューしない大規模なコレクションよりも役立ちます。

最初に何を設定する必要がありますか?

デバイス ID、サポートの責任者、および認識可能なリクエスト チャネルから始めます。次に、終了を含む 1 つの完全なリモート サポート タスクを検証します。 リクエスト検証ガイドとソフトウェア評価チェックリストは、最初の制御されたロールアウトの実際的な開始点を提供します。

インターフェイス リファレンス: GoMyid ユーザー ガイド、12 ページ: サポート リクエストを追跡し、対応します。この記事では、文書化されたサンプル インターフェイスを使用します。ライブ展開テストはレポートしません。