多くの企業がスマートロッカーの遠隔運用を評価する際、ソフトウェアのサブスクリプション料金とエンジニアの出張の要否だけを比較します。しかし、ユーザーにサービスを提供している端末にとって、最大の隠れたコストはエンジニアが費やす時間ではなく、遠隔操作が受取画面を占有しているかどうかかもしれません。エンジニアがバックグラウンドで5分間処理することと、顧客が5分間荷物を受け取れないことは、ビジネスにまったく異なる結果をもたらします。
したがって、遠隔運用のROIは「現場派遣の回数がどれだけ減ったか」だけで表すべきではありません。エンジニア時間、ユーザー側の中断、カスタマーサポートと現場支援、さらに注文、履行、苦情、ブランドへの影響も同時に計算する必要があります。
なぜ画面を占有すると依然としてダウンタイムになるのか
AirDroid Business、TeamViewerなどのエンタープライズ遠隔操作製品は、エンジニアが無人で運用されるAndroidデバイスに接続し、現場への移動を減らすのに役立ちます。このような機能は、物理画面の確認、異常ページの終了、業務用Appの再起動、システムレベルの操作を実行するのに非常に適しています。
問題は、リモート担当者が端末の物理画面を操作している場合、ユーザーも通常、設定ページやログインページ、エンジニアのクリックを見ることになります。デバイスのネットワークが正常であっても、この間サービス入口は占有されています。一部のソリューションでは遠隔操作中に画面を黒くして運用内容を保護できますが、画面が黒いということは顧客が荷物を受け取れないことを意味します。
Teralivoの違いは、独立した仮想ディスプレイをサポートするメンテナンス用Appであれば、エンジニアがバックグラウンドでそのAppを開いて操作できる一方、物理画面は引き続き荷物の受取業務を表示できることです。これはすべての問題の代替ソリューションではありませんが、アカウント確認、同期リフレッシュ、一部の設定処理を「ユーザーに見えるダウンタイム」からバックグラウンドの作業に変えることができます。
完全なコスト計算式を構築する
以下のモデルを使用することをお勧めします：
1回の運用にかかる総コスト = エンジニアの処理時間コスト + ユーザー側の中断時間コスト + カスタマーサポートと現場支援のコスト + 注文・履行・苦情・ブランドのコスト
エンジニアのコストには、診断、操作、記録、振り返りの時間が含まれます。ユーザー中断のコストには、待ち時間、列への待機、受け取りの断念が含まれます。カスタマーサポートのコストには、問い合わせ、苦情、手動でのロッカー開放が含まれます。現場コストには、物件管理者や保守担当者の現場到着が含まれます。業務コストには、期限切れの履行、再配達、ブランド信頼の低下が含まれます。
これらの項目は必ずしもすべて正確に金額に換算できるわけではありませんが、記録する必要があります。そうしなければ、企業は「リモート接続の成功」を「業務の中断なし」と誤解してしまいます。
検証可能な試算例
企業が2,000台のスマートロッカーを運用し、各ロッカーで週に1回、5分間の画面操作を必要とするメンテナンスイベントが発生すると仮定します。すると毎週、10,000分、つまり約166時間の画面占有が発生する可能性があります。
バックグラウンド操作によって、これらのイベントの70%が画面を占有しなくなった場合、約116時間の潜在的なユーザー中断を削減できます。ここではエンジニアの時間がなくなるとは想定していません。エンジニアは依然として診断と操作を行う必要があり、削減されるのは運用アクションが顧客のダウンタイムに変わる部分です。
試算時には、ピーク時とオフピーク時を分けて記録する必要もあります。夜間の5分間と、仕事帰りの受け取りピーク時の5分間ではコストが異なります。住宅地、キャンパス、オフィスビルでは使用曲線も異なります。
| 指標 | 物理画面のリモート操作 | 対応Appのバックグラウンド操作 |
|---|---|---|
| エンジニアによる遠隔処理 | 可能 | 可能 |
| 顧客に運用ページが見えるか | 通常見えるか、ブラック画面になる | ユーザー向け画面は受取画面を維持可能 |
| システムレベルの障害への適合性 | より適している | 機能は限定的 |
| Appが独立表示に対応している必要があるか | 不要 | 必要 |
| 主な価値 | 現場出張の削減 | ユーザー中断も同時に削減 |
パイロット時に記録すべきデータ
マーケティングデモからデバイス群全体を推定してはいけません。異なるモデル、Androidバージョン、ネットワーク環境、業務量の実端末を選び、障害の種類、リモート接続成功率、平均処理時間、ユーザー向け画面が占有された時間、現場介入が必要な割合、復旧後の再発状況を継続的に記録してください。
また、対象Appが独立した仮想ディスプレイをサポートしているかどうかをマークしてください。Appが物理カメラ、セキュアキーボード、特定のハードウェアアクセラレーション、外部デバイスを使用する必要がある場合、バックグラウンド表示ではすべての操作を完了できない可能性があります。その場合は、伝統的な物理画面のリモート操作とメンテナンスウィンドウを維持し、すべての障害を無理にバックグラウンド処理に分類しないでください。
Teralivoと完全なMDMを比較する方法
完全なMDMの利点には通常、デバイス登録、グループ化、アプリ配布、バージョンリリース、キオスクポリシー、セキュリティ制限、ジオフェンス、一括設定が含まれます。Teralivoは、これらの機能の包括的な代替品として説明されるべきではありません。Teralivoは、対応Appを運用する際に顧客を中断する必要があるかどうかという問題を解決する、焦点を絞ったバックグラウンド遠隔操作の入り口としてより適しています。
調達の決定では、組み合わせ方式を採用できます。MDMでデバイスのライフサイクルとポリシー管理を実行し、従来のリモート操作で物理画面やシステムレベルの障害を処理し、Teralivoで独立ディスプレイ内で完了できるバックグラウンドプロセスを処理します。最終的な判断基準は、機能の数ではなくパイロットデータであるべきです。
ROIの核心はツールを1つ減らすことではない
真に価値のある結果は、1回のリモートメンテナンスが顧客、カスタマーサポート、現場運用に与える影響を最小限に抑えることです。端末が荷物の受け取り、支払い、チェックインなどのサービスを提供している限り、ユーザー向け画面は生産リソースです。バックグラウンド運用の商業的価値は、エンジニアが作業している間もこのリソースを利用可能に保つことにあります。