ホームブログUPS Tracking APIとOMS統合：どちらを選ぶべきか？

UPS Tracking APIとOMS統合：どちらを選ぶべきか？

17TRACK

配送状況だけが必要な場合は、UPS追跡APIを選択してください。複数のチャネルにまたがる注文、在庫、フルフィルメント、ルーティング、キャンセル、返品を調整する必要がある場合は、OMS統合を選択してください。多くのeコマース業務では、実際の答えは二者択一ではありません。OMSが注文ライフサイクルを管理し、キャリアまたはマルチキャリア追跡APIが配送イベントを提供します。

UPS追跡APIとOMS統合：どちらを選ぶべきか

適切な判断は、チームが取る必要のあるアクションによって異なります。追跡ページを構築する開発者と、マーケットプレイス、倉庫、3PL、カスタマーサービスシステムを接続するオペレーションチームでは、要件が異なります。UPS追跡APIとOMSを互換性のあるものとして扱うと、不要な開発作業が発生したり、重要な業務上のギャップが残ったりする可能性があります。

違いを一文で説明すると

UPS追跡APIはキャリアデータへの接続です。OMS統合は注文ワークフローへの接続です。

追跡APIは通常、アプリケーションが追跡番号に関連付けられた配送情報を取得または表示するために役立ちます。この情報は、顧客への通知、ブランド化された追跡ページ、社内での配送監視、または例外処理をサポートできます。範囲は主に配送の可視化です。

注文管理システムは、より広いプロセス層に位置します。複数の販売チャネルからの注文を調整し、在庫を割り当て、フルフィルメント拠点と通信し、倉庫や3PLに注文を送信し、ステータスをストアフロントやマーケットプレイスに同期することがあります。正確な機能セットはOMSごとに異なるため、名称から推測するのではなく、製品ドキュメントで機能を確認する必要があります。

UPS追跡APIが適している場合

主な業務上の課題が、UPSの配送物の所在を把握し、その情報を別のアプリケーションで利用可能にすることである場合は、UPSとの直接追跡統合を選択してください。

  • 顧客向け追跡：顧客がその体験から離れることなく、ウェブサイトやアプリで配送の進捗を表示する必要がある。
  • サポートワークフロー：担当者がヘルプデスク、CRM、または注文画面内で最新の追跡イベントを確認する必要がある。
  • 配送通知：メール、SMS、その他の顧客コミュニケーションの入力として、システムに配送イベントが必要である。
  • 例外監視：オペレーション担当者が、遅延、配達試行、その他フォローアップが必要なイベントを特定する必要がある。
  • 単一キャリア運用：関連する配送の大部分またはすべてをUPSが処理しており、キャリア固有の統合が業務上合理的である。

この方法は通常、完全なOMSプロジェクトよりも範囲を限定しやすく、設計も容易です。チームは、必要な追跡番号の形式、イベントフィールド、認証方式、更新動作、エラー処理、顧客向けステータス表現を定義できます。注文割り当てや在庫プロセスを再設計する必要はありません。

ただし、追跡APIを注文管理システムとして扱うべきではありません。追跡データは配送物に何が起きたかを示せますが、どの倉庫が注文をフルフィルメントすべきか、在庫を確保するか、注文を分割するか、キャンセルを承認するか、返品ワークフローを作成するかを、それ自体で決定することはできません。

OMS統合が適している場合

問題が配送物の作成前から始まる場合、またはキャリアの可視性を超えて続く場合は、OMS統合を選択してください。

以下のいくつかを調整する必要がある場合、OMSの関連性が高くなります。

  • 複数のストアフロント、マーケットプレイス、販売チャネルからの注文
  • 店舗、倉庫、フルフィルメントパートナー間の在庫可用性
  • 場所、在庫、サービスレベル、業務ルールに基づく注文ルーティング
  • 部分発送、バックオーダー、キャンセル、注文変更
  • 倉庫や3PLシステムに送信するフルフィルメント指示
  • OMSと販売チャネル間のステータス同期
  • キャリアステータスを超える返品、返金、購入後ワークフロー

このモデルでは、UPSはより大きなプロセス内にある一つのキャリア接続です。OMSがフルフィルメント記録を作成または受け取り、キャリア統合が輸送の詳細を提供する場合があります。その後、OMSは配送マイルストーンを使用して注文ライフサイクルを更新できますが、正確な動作は関係するシステムとマッピングルールによって異なります。

したがって、OMS統合はより大規模な導入判断です。データ所有権、在庫同期、注文状態の定義、倉庫プロセス、例外キュー、照合が関係する可能性があります。より優れた追跡ページが欲しいというだけの理由で、OMS接続を購入または構築すべきではありません。

UPS追跡APIとOMS統合の比較

判断領域UPS追跡APIOMS統合
主な目的UPSの配送ステータスを公開または処理する注文ライフサイクルとフルフィルメント業務を調整する
主なデータオブジェクト追跡番号、荷物、配送イベント注文、明細、在庫、フルフィルメント、配送、場合によっては返品
主な担当部門プロダクトエンジニアリング、顧客体験、またはサポートシステムeコマース業務、フルフィルメント、エンタープライズアーキテクチャ、エンジニアリング
一般的な範囲単一キャリアまたは追跡サービス複数のチャネル、施設、システム、フルフィルメントパートナー
自動的には解決しないこと在庫割り当て、ルーティング、注文オーケストレーション統合が提供しない限り、正確なキャリアイベントの正規化
導入リスクフィールドマッピング、認証、ポーリングまたはイベント処理、ステータス解釈データ所有権、状態同期、在庫精度、システム間の照合

この表は一般的なアーキテクチャ上の違いを示すものであり、すべてのベンダーに当てはまることを保証するものではありません。注文管理と配送可視化を組み合わせたプラットフォームもあれば、複数のキャリアをサポートする追跡プロバイダーもあります。統合パターンを選択する前に、具体的なドキュメントを確認してください。

多くの成長企業に必要な選択肢：OMSとマルチキャリア追跡

UPSを他のキャリアと併用する企業では、UPS専用接続よりも広範な追跡レイヤーが必要になることがあります。マルチキャリア追跡サービスはキャリア間の配送イベントを正規化でき、OMSは注文およびフルフィルメントプロセスを引き続き担当します。

17TRACKは追跡APIを提供し、プログラムによる追跡統合を必要とする企業向けに開発者向けドキュメントを公開しています。これは、UPSだけに関係するワークフローではなく、キャリアをまたいだ配送可視化が要件である場合に関連します。特定のプロジェクトについて、現在のAPI範囲、サポートされる操作、認証要件、導入の詳細を確認するには、公式ドキュメントを使用してください。

このアーキテクチャは、複数のフルフィルメントパートナーを持つ小売業者や、仕向地によってラストマイルキャリアが異なる越境業務に役立ちます。OMSは注文とフルフィルメントの状態を保持し、追跡レイヤーは顧客向けまたは社内アプリケーションに配送更新を提供できます。ただし、2つのシステムには明確な所有権ルールが必要です。たとえば、注文ステータスの正となるシステム、キャリアイベントの正となるシステム、競合する更新を解決する方法を定義します。

単純なUPS専用ストアでは、OMSとマルチキャリア追跡サービスの両方を追加する必要はないかもしれません。一方、複数のキャリアとチャネルを持つ企業では、正規化された追跡レイヤーを避けることで、個別の統合、不整合なステータスラベル、保守作業の増加につながる可能性があります。

過剰な構築を避けて選択する方法

1. 業務イベントから始める

アクションを発生させる必要があるイベントを書き出します。「注文ページに最新のUPSステータスを表示する」は追跡APIを示します。「支払済みの各注文を最適なフルフィルメント拠点に送り、在庫を同期する」はOMSを示します。「荷物が3PLを出発した後に顧客を更新する」には両方が必要になる場合があります。

2. すでにデータを所有しているシステムを整理する

ストアフロント、マーケットプレイス、ERP、倉庫管理システム、3PL、カスタマーサービスプラットフォーム、OMS、キャリア接続を一覧にします。それぞれについて、注文、在庫、フルフィルメント記録、追跡イベントを作成、変更するのか、それとも読み取るだけなのかを特定します。これにより、新しい統合によって正しい情報源が2つ競合するのを防げます。

3. キャリアの多様性と地域を確認する

対象となるキャリアがUPSだけであれば、UPSとの直接接続で十分な場合があります。複数のキャリア、郵便事業者、または仕向地固有のラストマイルパートナーを利用している場合は、より広範な追跡APIによって個別統合を減らせるか評価してください。プロバイダーがすべてのキャリア、国、イベントタイプをサポートしていると想定せず、実際の配送プロファイルに関係する対応範囲を確認してください。

4. 最小限のステータスモデルを定義する

キャリアイベントは、顧客に表示するステータスより詳細であることがよくあります。開発前に、生のイベントをラベル作成済み、輸送中、配達中、配達済み、例外、返品済みなどの業務状態にマッピングします。イベントが遅延、重複、欠落、または順不同で受信された場合の処理を決めます。この作業は、データがUPSから直接提供される場合でも、追跡プラットフォーム経由の場合でも必要です。

5. 業務上の例外をテストする

成功するデモでは通常の配送が中心になります。役立つ概念実証では、無効な追跡番号、イベントがない配送、スキャンの遅延、配送例外、部分発送、交換注文、返品もテストすべきです。OMSプロジェクトでは、分割注文、在庫不足、キャンセルの試行、重複注文メッセージも追加します。

6. 運用全体の負荷を比較する

初期統合の作業量だけを比較しないでください。監視、API変更、サポートツール、照合、キャリアの追加、データ保持、アクセス制御、障害復旧を含めます。限定的な問題には、狭い範囲のAPIが最もリスクの低い選択肢となる可能性があります。すでに複数のキャリアとフルフィルメントシステムがある場合は、より広範なプラットフォームのほうが保守しやすいことがあります。

実践的な判断ルール

既存のアプリケーションで信頼性の高いUPS配送可視化が目的なら、UPS追跡APIを使用してください。チャネルや拠点をまたいだ注文およびフルフィルメント実行の調整が目的なら、OMS統合を使用してください。OMSで注文を管理し、別の追跡レイヤーでカスタマーサービスや購入後の体験向けに配送イベントを統合する必要がある場合は、両方を使用してください。

選択肢を評価する企業にとって、次のステップは広範な技術的コミットメントではなく、小規模で文書化された統合テストであるべきです。代表的な注文を選び、期待するフィールドとステータスを定義し、通常ケースと例外ケースをテストし、各判断をどのシステムが所有するかを記録します。後にプロジェクトが追加キャリアへ拡大した場合は、キャリア接続を一つずつ独立して追加するよりも、マルチキャリア追跡APIが適切かどうかを再評価してください。

最も優れた選択は、次に起こり得る要件を妨げることなく、現在の業務上の問題を解決する最小限のアーキテクチャです。追跡APIをOMSとして売り込むべきではなく、追跡ページを表示するだけのためにOMSを導入すべきでもありません。

よくある質問

UPS追跡APIはOMSと同じですか？

いいえ。UPS追跡APIはUPSからの配送情報に重点を置きます。OMSは、在庫、ルーティング、フルフィルメント、キャンセル、返品などを含む、より広範な注文およびフルフィルメントプロセスを調整します。企業はOMS主導のアーキテクチャ内で追跡APIを使用できます。

OMSでUPSの配送物を追跡できますか？

OMSにUPS統合があるか、別の追跡サービスに接続していれば可能です。機能は製品固有のため、OMSのドキュメントで確認する必要があります。OMSという名称だけでは、必要なUPSイベントやワークフローをサポートしていることは証明されません。

ブランド化された追跡ページを作成するためにOMSは必要ですか？

通常は必要ありません。ブランド化された追跡ページには、一般的に配送データを受信して顧客に表示できるアプリケーションまたは追跡サービスが必要です。OMSは注文コンテキストを提供できますが、ページ自体に必須というわけではありません。

マルチキャリア追跡APIはいつ使用すべきですか？

複数のキャリアを利用して配送し、アプリケーションで配送イベントを一貫した方法で取得または表示する必要がある場合に検討してください。実際に運用する配送ルートについて、プロバイダーのキャリア対応範囲、イベントモデル、ドキュメント、サービス制限、例外処理を確認してください。

開発者は統合前に何を明確にすべきですか？

認証、リクエストとレスポンスのフィールド、ステータス定義、更新頻度、エラー処理、重複イベント、追跡番号の検証、保持期間、セキュリティ、システムの所有権を明確にします。また、追跡イベントが顧客向けの注文ステータスをどのように変更するかも文書化してください。

出典

Loading