概要

  • Antenna Software の持続的な価値は、受け入れ可能なモバイルフィールドワークフローにあった。部品注文、通話終了、勤怠入力、マーチャンダイザーレポート、サービス更新は、不安定な通信環境、多様なデバイス、本人確認、バックエンド統合、例外処理を乗り越える必要があった。
  • 同社はフィールドサービス展開や、ゲートウェイルーティング、エンタープライズコネクタ、デバイス管理、オフラインのストア・アンド・フォワード動作といったプラットフォームコンポーネントにおいて実証済みの証拠を持っていたが、それらの主張はすべての顧客環境で普遍的な信頼性を証明するものではない。
  • 商業的な根拠は、紙、再入力、電話による監督を、制御されたモバイルワークフローに置き換えることに依存していた。コストは統合、現場トレーニング、デバイスサポート、ライフサイクルメンテナンス、そして Pegasystems が同社を買収した後の所有権移行に存在した。
  • 現実的な代替手段には、パッケージ化されたフィールドサービススイート、CRM や ERP のモバイルモジュール、ローコードプラットフォーム、カスタムネイティブアプリ、後に登場した Pega のモバイル機能などが含まれた。それらはいずれも、同期、本人確認、バックエンドの真実に関する負担を取り除くのではなく、単に移し替えただけである。

価値の単位はアプリではなかった

Antenna Software は、エンタープライズモビリティが、重役向けメールや簡単なハンドヘルド検索から、記録をクローズしなければならない作業へと移行しつつあった時期に存在した。重要なトランザクションは、見栄えの良いモバイル画面ではなかった。それは、ネットワークが弱いかもしれない場所で始まり、技術者や事業部門が所有するデバイスを経由し、CRM、ERP、在庫、作業管理システムにおいて受け入れられた状態として終わる、現場でのアクションだった。技術者がサービスコールをクローズし、部品を注文し、時間を記録し、経費を計上し、資産を更新し、顧客メモをキャプチャし、マーチャンダイジング訪問を完了としてマークした場合、その価値は、バックエンドシステムがそのアクションを、正しい人物が正しいタイミングで行った正しいアクションとして受け入れたときに初めて生じた。

この区別は重要である。なぜなら、Antenna はしばしば「モバイルアプリケーション開発プラットフォーム」と表現されたからだ。この表現は正確だが不完全である。アプリ開発スピードは、製品の表面上の見せかけに過ぎなかった。より難しい問題は、運用上の継続性だった。すなわち、現場作業者が通信可能範囲を離れて戻ってきても、モバイルアクションをユーザー、ジョブ、顧客、デバイス、ワークフロールール、後の例外に結びつけたままにできるのか?システムは、記録が新規か、古いのか、競合しているのか、既にクローズされているのかを判別できるのか?マネージャーは、現場スタッフを電話や紙のメモに戻らせることなく、作業を監督するのに十分な状態を把握できるのか?同じアーキテクチャは、BlackBerry、Windows Mobile、ブラウザインターフェース、後のスマートフォン、通信事業者ネットワーク、地域展開、複数のバックエンドシステムを生き延びられるのか?

「受け入れ可能なモバイルフィールドワークフロー」という見方は、「モバイルアプリビルダー」よりも狭く、より有用なレンズである。これは、モバイルレイヤーが、現場作業を台無しにする引き継ぎの数を減らしたかを問うものだ。紙の帳票は遅延と再入力エラーを生み出す。電話は、指令担当者やコールセンターを中断させる。別個のモバイルアプリは、後で調整しなければならない別のキューを生み出す。優れたエンタープライズモビリティプラットフォームは、現場作業者の更新をシステムオブレコードに移しつつ、事務所がそれを信頼するのに十分なコンテキストを保持するはずだ。弱いプラットフォームは、単に帳票をデジタル化し、運用リスクを別の場所に残してしまう。

Antenna の最も強力な公開事例は、現場作業が反復的で測定可能であり、サービス成果に結びついていた環境から来ている。Pitney Bowes は、郵便システムに関連するフィールドサービスで Antenna のテクノロジーを使用した。Heineken Ireland は、Oracle Siebel CRM に接続されたフィールドサービスとマーチャンダイジング作業に Antenna アプリケーションを活用した。Korea Telecom は、マネージドエンタープライズモビリティサービスの中で Antenna のプラットフォームを利用した。これらの事例は、同じ運用上の課題を示している。すなわち、モバイルデバイスは、より大きなビジネスプロセスの制御されたエッジとして機能できて初めて有用であるということだ。

それゆえ、同社は 4 つの質問で評価されるべきである。第一に、そのプラットフォームは、既に作業を統制していたエンタープライズアプリケーションにモバイル活動を接続したか?第二に、ユーザーは、ネットワーク、デバイス、ローカル環境が不均一な場合でも作業を継続できたか?第三に、マネージャーと IT チームは、すべての現場更新をサポートチケットに変えることなく、バージョン、ユーザー、デバイス、トランザクションを制御する手段を得られたか?第四に、統合、デバイスサポート、トレーニング、ライセンス、プラットフォーム移行コストを含めても、経済性は成り立ったのか?答えは混在しているが、Antenna の真の貢献を、初期のエンタープライズモビリティを取り巻く幅広い誇大広告から切り離すには十分具体的である。

Antenna が実際に販売したもの

Antenna Software の製品ラインは、Antenna Mobility Platform、AMPower ソリューション、AMPchroma へと進化した。製品の境界は単一の顧客向けアプリではなく、モバイルランタイム、開発環境、ゲートウェイ、エンタープライズ接続、管理コンソール、ホスト型またはオンプレミス展開オプション、一般的なモバイルタスク向けの事前構築済みサービスの組み合わせだった。プラットフォームの公開説明では、「構築」だけではなく、「構築、実行、管理」が繰り返し強調されていた。このフレーズは、ビジネスにおける緊張関係を捉えている。企業はより迅速なモバイル提供を求める一方で、セキュリティ、アイデンティティ、バックエンド統合、更新管理、変化するデバイス群にわたるサポートも求めていた。

初期の導入では、ゲートウェイが中心的役割を果たした。それはモバイルアプリケーションとバックエンドシステムの間でトランザクションをルーティングし管理した。現場作業において、これは付随的なものとして扱えるような単なる配管ではない。ゲートウェイは、特にデバイスが一時的に通信可能範囲を失った場合に、モバイルアクションをどのようにキューに入れ、送信し、再試行し、記録するかを決定しなければならない。Enterprise Connect または類似のコネクタ機能がホストシステムを橋渡しし、管理センターはユーザー、アプリケーション、デバイス、レポート作成に対する制御を提供した。Studio と後の AMPchroma レイヤーは、開発者がアプリケーションを構築し、適応させるのを支援した。デバイスクライアントは、現場作業者にローカルの実行環境を提供した。

同社はまた、AMPchroma を、すべてのコンポーネントを自社で運用したくない企業向けのクラウドまたはマネージドサービスの道として位置づけた。それは商業的に理にかなっていた。多くの企業は、同時に複数のモバイルプロジェクトを進行中であり、各事業部門はアプリケーションごとに別々のベンダーを雇う誘惑に駆られがちだった。Antenna は、プロジェクト間で再利用可能な共通のモバイル基盤を提供した。その売り文句は、単に「アプリをより速く作る」ではなく、「セキュリティ確保、更新、統合を一貫して行えない、断片化されたモバイルチャネルの集合体を避ける」ことだった。

これは 2010 年代初頭の現実的な問題だった。企業は、BlackBerry 環境、Windows Mobile デバイス、台頭する iPhone や Android の需要、タブレット、ブラウザベースのアプリ、そして BYOD(個人デバイス業務利用)の圧力に直面していた。フィールドサービスやマーチャンダイジングの組織は、すべてのデバイス更新サイクルを制御できないかもしれなかった。ある地域では作業員が頑丈なハンドヘルド端末を使い続ける一方、別の地域ではスマートフォンに移行する可能性があった。同時に、Siebel、SAP、Oracle、在庫システム、データウェアハウスといったバックエンドシステムは、モバイルデバイスが登場したからといって置き換えられるわけではなかった。モバイルプラットフォームは、既存環境に適応しなければならず、その逆ではなかった。

企業としての Antenna の境界も重要である。2013 年に Pegasystems が買収した後、Antenna はより広範な BPM、CRM、ケース管理企業の一部となった。この買収により、Pega はモビリティに関するストーリーを強化したが、顧客の所有権パスも変化させた。独立したエンタープライズモビリティプロバイダーを当初選択した購入者は、後に買収側の優先順位、統合ロードマップ、サポートポリシーに依存することになった。これは Pega に限った批判ではない。それはプラットフォーム購入における構造的リスクである。プラットフォームがより大きなスイートの一部になったとき、顧客は統合の相乗効果の可能性と継続性のリスクを同時に受け取る。

したがって、Antenna を最もよく理解する方法は、確立されたシステムに現場のアクションを届ける必要があり、すべての電話やタブレットを個別の統合プロジェクトとして扱いたくない組織のための、エンタープライズモバイルワークフローレイヤーとして捉えることだ。製品はアプリ構築を支援したが、経済的な主張は、完了したアクションを、アイデンティティ、コンテキスト、バックエンドの受け入れに結びつけておくことに依存していた。