JP2023520086A - 自動化されたアウトバウンドプロファイル生成のためのシステムおよび方法 - Google Patents

Abstract

本開示の一態様は、自動化されたアウトバウンドプロファイルを生成するためのコンピュータ実装システムに関する。そのシステムは、以下のステップ、フルフィルメントセンタ（ＦＣ）の容量を含むデータを受信することと、ＦＣへの複数の到着製品に関連する複数の製品識別子を受信することと、製品識別子を使用して、ＦＣで製品のトランザクショナルログを定期的に収集および格納することと、製品識別子を使用して、ＦＣで格納された製品の現在の在庫を決定することと、機械学習アルゴリズムを使用して、トランザクショナルログおよび現在の在庫の少なくとも１つを使用してＦＣのアウトバウンドプロファイルを生成することであって、アウトバウンドプロファイルが、複数のカテゴリの製品の出荷製品の予想されるパーセンテージを含む、ことと、アウトバウンドプロファイルをＦＣの実際のアウトバウンド容量と比較することによって、ＦＣの生成されたアウトバウンドプロファイルを使用して、ネットワークアウトバウンドを管理することと、を含むステップを実行することができる。

Description

本開示は、一般に、自動化されたアウトバウンドプロファイル生成のためのコンピュータ化されたシステムおよび方法に関する。特に、本開示の実施形態は、フルフィルメントセンタにおける履歴出荷データに機械学習方法を適用して、それらのアウトバウンド容量を正確に表すプロファイルを生成することに関する新規な、非従来型のシステムに関する。

フルフィルメントセンタ（ＦＣ）は、注文が行われるとすぐに消費者の注文を履行し、配送業者が出荷品を集荷できるように動作するため、毎日数百万を超える製品に対処する。ＦＣ内の在庫を管理するための動作は、販売者から商品を受け取ること、受け取った商品を容易にピッキングできるように保管すること、アイテムをパッキングすること、注文を確認すること、および荷物配送を含むことができる。現在の既存のＦＣおよびＦＣ内の在庫管理のためのシステムは、大量の到着商品および出荷商品を処理するように構成されているが、注文が複数のＦＣ間で適切に分配されないために、ＦＣが処理できるよりも多くの注文を受け取る場合に共通の問題が生じる。例えば、ＦＣに関連する業者は、ピークシーズンの間、供給者から大量の製品を注文することができるが、しかしＦＣは、注文された製品をタイムリーに受け取るのに十分なリソースを持たない。これは、受信プロセスを遅くすることによってＦＣにおける大規模なバックログ問題につながり、最終的に問題を悪化させる可能性がある。バックログ問題は、業者が製品を流通させて利益を得ることを妨げるため、販売の損失をもたらす可能性がある。

このような問題を軽減するために、従来の在庫管理システムは、予測データに依存して、複数のＦＣへの製品の分配、ならびに各ＦＣの手動で生成されたアウトバウンドプロファイルを決定する。これらのシステムは、特定の製品のインバウンド容量またはアウトバウンド容量などの各ＦＣの個々の要因を考慮していないという技術的問題を抱えている。これらの要因を考慮することなく、これらのシステムは、ＦＣ間で製品の分配を生成する可能性があり、特定のＦＣは、特定の製品の需要を満たすのに十分な在庫、インバウンド容量、またはアウトバウンド容量がない可能性がある。これはまた、販売の損失をもたらす可能性がある。さらに、これらのシステムは、ＦＣのアウトバウンドプロファイルの手動決定を必要とし、これは非常に不正確であり、コストを大幅に増加させる可能性がある。

したがって、各ＦＣの個別の能力および特質にさらに基づく複数のＦＣのアウトバウンドプロファイルをインテリジェントに、および自動的に生成するための改善された方法およびシステムが必要である。

本開示の一態様は、自動化されたアウトバウンドプロファイルを生成するためのコンピュータ実装システムに関する。システムは、少なくとも１つのプロセッサと、少なくとも１つのデータベースと、少なくとも１つのプロセッサによって実行される場合、以下のステップ、フルフィルメントセンタ（ＦＣ）の容量を含むデータを受信することと、ＦＣへの複数の到着製品（incoming products）に関連する複数の製品識別子を受信することと、製品識別子を使用して、ＦＣで複数の製品のトランザクショナルログを定期的に収集および格納することと、製品識別子を使用して、ＦＣで格納された複数の製品の現在の在庫を決定することと、機械学習アルゴリズムを使用して、トランザクショナルログおよび現在の在庫の少なくとも１つを使用してＦＣのアウトバウンドプロファイルを生成することであって、アウトバウンドプロファイルが、複数のカテゴリの製品の出荷製品の予想されるパーセンテージを含む、ことと、アウトバウンドプロファイルをＦＣの実際のアウトバウンド容量と比較することによって、ＦＣの生成されたアウトバウンドプロファイルを使用して、ネットワークアウトバウンドを管理することと、を含むステップを実行する命令を含むメモリと、を備えることができる。

本開示の別の態様は、自動化されたアウトバウンドプロファイルを生成するためのコンピュータ実施システムに関する。その方法は、フルフィルメントセンタ（ＦＣ）の容量を含むデータを受信することと、ＦＣへの全ての到着製品に関連する製品識別子を受信することと、製品識別子を使用して、ＦＣで全ての製品ごとにトランザクショナルログを定期的に収集および格納することと、ＦＣの履歴トランザクショナルログを検索することと、製品識別子を使用して、ＦＣで全ての製品の現在の在庫を決定することと、機械学習アルゴリズムを使用して、トランザクショナルログおよび現在の在庫のうちの少なくとも１つを使用して、ＦＣのアウトバウンドプロファイルを生成することと、を含む。

本開示の別の態様は、自動化されたアウトバウンドプロファイルを生成するためのコンピュータ実装システムに関する。そのシステムは、少なくとも１つのプロセッサと、少なくとも１つのデータベースと、少なくとも１つのプロセッサによって実行される場合、以下のステップ、フルフィルメントセンタ（ＦＣ）の容量を含むデータを受信することと、ＦＣへの複数の到着製品に関連する複数の製品識別子を受信することと、製品識別子を使用して、ＦＣで複数の製品のトランザクショナルログを定期的に収集および格納することと、製品識別子を使用して、ＦＣで格納された複数の製品の現在の在庫を決定することと、複数のトランザクショナルログおよび複数のＦＣからの現在の在庫をデータベースに格納することであって、複数のトランザクショナルログおよび現在の在庫がトランザクショナルデータを含む、ことと、トランザクショナルデータを訓練データセットおよび検証データセットに分割することであって、訓練データセットが検証データセットよりも多くのデータを有する、ことと、機械学習アルゴリズムを使用して、訓練データセットに基づいて予測モデルを生成することと、検証データセットを使用して、予測モデルを検証することと、予測モデルを関連するトランザクショナルログおよび現在の在庫に適用することによって、ＦＣのアウトバウンドプロファイルを生成することであって、アウトバウンドプロファイルが、複数のカテゴリの製品の出荷製品の予想されるパーセンテージを含む、ことと、アウトバウンドプロファイルをＦＣの実際のアウトバウンド容量と比較することによって、ＦＣの生成されたアウトバウンドプロファイルを使用して、ネットワークアウトバウンドを管理することと、を含むステップを実行する命令を含むメモリと、を備えることができる。

他のシステム、方法、およびコンピュータ可読媒体も、本明細書で説明される。

開示された実施形態と一致する、出荷、輸送、および物流オペレーションを可能にする通信のためのコンピュータ化されたシステムを備えるネットワークの例示的な実施形態を示す概略ブロック図である。

開示された実施形態と一致する、対話型ユーザインターフェース要素と共に、検索要求を満たす１つまたは複数の検索結果を含むサンプルの検索結果ページ（ＳＲＰ）を示す図である。

開示された実施形態と一致する、対話型ユーザインターフェース要素と共に、製品および製品に関する情報を含むサンプルの単一ディスプレイページ（ＳＤＰ）を示す図である。

開示された実施形態と一致する、対話型ユーザインターフェース要素と共に、仮想ショッピングカート内のアイテムを含むサンプルのカートページを示す図である。

開示された実施形態と一致する、対話型ユーザインターフェース要素と共に、購入および出荷に関する情報と共に、仮想ショッピングカートからのアイテムを含むサンプルの注文ページを示す図である。

開示された実施形態と一致する、開示されたコンピュータ化されたシステムを利用するように構成された例示的なフルフィルメントセンタの概略図である。

開示された実施形態と一致する、製品在庫を最適レベルに保つためのコンピュータ化されたシステムを含むネットワーク環境の例示的な実施形態を示す概略ブロック図である。

開示された実施形態と一致する、１つまたは複数のフルフィルメントセンタのアウトバウンドプロファイルのインテリジェントな自動生成のための例示的なコンピュータ化されたプロセスのフローチャートである。

開示された実施形態と一致する、アウトバウンドプロファイルに基づいて在庫レベルを管理するために使用され得る例示的なプロセスおよび／またはロジックのフローチャートである。

以下の詳細な説明は、添付の図面を参照する。可能な限り、図面および以下の説明では、同一または類似の部分を参照するために、同一の参照番号が使用される。いくつかの例示的な実施形態が本明細書で説明されるが、修正、適応、および他の実装が可能である。例えば、置換、追加、または修正が図面に示された構成要素およびステップに行われてもよく、本明細書に記載された例示的な方法は、開示された方法にステップを置換、並べ替え、除去、または追加することによって修正されてもよい。したがって、以下の詳細な説明は、開示された実施形態および実施例に限定されない。むしろ、本発明の適切な範囲は、添付の特許請求の範囲によって定義される。

本開示の実施形態は、フルフィルメントセンタで履歴出荷データに機械学習方法を適用して、それらのアウトバウンド容量を正確に表すプロファイルを生成するように構成されたシステムおよび方法に関する。

図１Ａを参照すると、出荷、輸送、および物流動作を可能にする通信のためのコンピュータ化されたシステムを含むシステムの例示的な実施形態を示す概略ブロック図１００が示されている。図１Ａに示すように、システム１００は様々なシステムを含むことができ、その各々は、１つまたは複数のネットワークを介して互いに接続することができる。システムはまた、例えばケーブルを使用して、直接接続を介して互いに接続されてもよい。図示のシステムは、出荷権限技術（ＳＡＴ）システム１０１、外部フロントエンドシステム１０３、内部フロントエンドシステム１０５、輸送システム１０７、モバイルデバイス１０７Ａ、１０７Ｂ、１０７Ｃ、販売者ポータル１０９、出荷および注文追跡（ＳＯＴ）システム１１１、フルフィルメント（履行）最適化（ＦＯ）システム１１３、フルフィルメントメッセージングゲートウェイ（ＦＭＧ）１１５、サプライチェーン管理（ＳＣＭ）システム１１７、倉庫管理システム１１９、モバイルデバイス１１９Ａ、１１９Ｂ、１１９Ｃ（フルフィルメントセンタ（ＦＣ）２００の内部にあるものとして図示）、第三者フルフィルメントシステム１２１Ａ、１２１Ｂ、１２１Ｃ、フルフィルメントセンタ認証システム（ＦＣ認証）１２３、労務管理システム（ＬＭＳ）１２５を含む。

ＳＡＴシステム１０１は、いくつかの実施形態では注文状態および配送状態を監視するコンピュータシステムとして実装されてもよい。例えば、ＳＡＴシステム１０１は注文がその約束配送日（ＰＤＤ）を過ぎているかどうかを判定し、新しい注文を開始すること、配送されていない注文でアイテムを再出荷すること、配送されていない注文をキャンセルすること、注文カスタマとのコンタクトを開始することなどを含む適切な処置をとることができる。ＳＡＴ装置１０１は、出力（特定の期間中に出荷された荷物の数など）および入力（出荷に使用するために受け取った空のボール紙箱の数など）を含む他のデータを監視することもできる。また、ＳＡＴシステム１０１はシステム１００内の異なるデバイス間のゲートウェイとして機能し、外部フロントエンドシステム１０３およびＦＯシステム１１３などのデバイス間の通信（例えば、ストアアンドフォワードまたは他の技術を使用する）を可能にしてもよい。

いくつかの実施形態では、外部フロントエンドシステム１０３が、外部ユーザがシステム１００内の１つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装することができる。例えば、システム１００がシステムの提示を可能にして、ユーザがアイテムの注文を行うことを可能にする実施形態では、外部フロントエンドシステム１０３が検索要求を受信し、アイテムページを提示し、決済情報を要請するウェブサーバとして実装されてもよい。例えば、外部フロントエンドシステム１０３は、アパッチＨＴＴＰサーバ、マイクロソフトインターネットインフォメーションサービス（ＩＩＳ）、ＮＧＩＮＸ等のソフトウェアを実行する１つまたは複数のコンピュータとして実施することができる。他の実施形態では、外部フロントエンドシステム１０３が外部デバイス（例えば、モバイルデバイス１０２Ａまたはコンピュータ）からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得した情報に基づいて受信した要求に対する応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。

いくつかの実施形態では、外部フロントエンドシステム１０３がウェブキャッシングシステム、データベース、検索システム、または支払いシステムのうちの１つまたは複数を含むことができる。一態様では外部フロントエンドシステム１０３がこれらのシステムのうちの１つまたは複数を備えることができ、別の態様では外部フロントエンドシステム１０３がこれらのシステムのうちの１つまたは複数に接続されたインターフェース（例えば、サーバ間、データベース間、または他のネットワーク接続）を備えることができる。

図１Ｂ、図１Ｃ、図１Ｄ、および図１Ｅによって示されるステップの例示的な組は、外部フロントエンドシステム１０３のいくつかの動作を説明するのに役立つ。外部フロントエンドシステム１０３は提示および／またはディスプレイのために、システム１００内のシステムまたはデバイスから情報を受け取ることができる。例えば、外部フロントエンドシステム１０３は、検索結果（ＳＲＰ）を含む１つまたは複数のウェブページをホスティングまたは提供することができ（例えば、図１Ｂ）、単一ディテールページ（ＳＤＰ）（例えば、図１Ｃ）、カートページ（例えば、図１Ｄ）、または注文ページ（例えば、図１Ｅ）を含む。ユーザデバイス（例えば、モバイルデバイス１０２Ａまたはコンピュータ１０２Ｂを使用する）は外部フロントエンドシステム１０３にナビゲートし、サーチボックスに情報を入力することによってサーチを要求することができる。外部フロントエンドシステム１０３は、システム１００内の１つまたは複数のシステムから情報を要求することができる。例えば、外部フロントエンドシステム１０３は、検索要求を満たす情報をＦＯシステム１１３に要求することができる。また、外部フロントエンドシステム１０３は検索結果に含まれる製品ごとに、約束配送日または「ＰＤＤ」を（ＦＯシステム１１３から）要求し、受信することもできる。ＰＤＤはいくつかの実施形態では、特定の期間内に、例えば、その日の最後（午後１１時５９分）までに注文された場合、製品を含む荷物が、いつユーザの所望の場所に到着するか、または製品がユーザの所望の場所に配送されることを約束される日付かのいずれかの推定値を表すことができる。（ＰＤＤはＦＯシステム１１３に関して以下でさらに説明される）。

外部フロントエンドシステム１０３がその情報に基づいてＳＲＰ（例えば、図１Ｂ）を準備することができる。ＳＲＰは、検索要求を満たす情報を含むことができる。例えば、これは、検索要求を満たす製品の写真を含むことができる。ＳＲＰはまた、各製品についてのそれぞれの価格、または各製品についての強化された配送オプション、ＰＤＤ、重み、規模、オファー、割引などに関する情報を含んでもよい。外部フロントエンドシステム１０３は（例えば、ネットワークを介して）要求側ユーザデバイスにＳＲＰを送信することができる。

次いで、ユーザデバイスは、例えば、ユーザインターフェースをクリックもしくはタップすることによって、または別の入力デバイスを使用して、ＳＲＰで表される製品を選択することによって、ＳＲＰから製品を選択することができる。ユーザデバイスは、選択された製品に関する情報の要求を定式化し、それを外部フロントエンドシステム１０３に送信することができる。これに応じて、外部フロントエンドシステム１０３は、選択された製品に関する情報を要求することができる。例えば、情報は、それぞれのＳＲＰで製品について提示されたもの以外の追加情報を含むことができる。これは、例えば、保存可能期間、原産国、重量、サイズ、荷物内のアイテムの数、取り扱い説明書、または製品に関する他の情報を含むことができる。また、情報は（例えば、この製品および少なくとも１つの他の製品を購入した顧客のビッグデータおよび／または機械学習分析に基づく）類似の製品に対する推奨、頻繁に聞かれる質問に対する回答、顧客からのレビュー、製造業者情報、写真などを含むことができる。

外部フロントエンドシステム１０３は受信した製品情報に基づいて、ＳＤＰ（単一ディテールページ）（例えば、図１Ｃ）を準備することができる。ＳＤＰはまた、「今すぐ買う」ボタン、「カードに追加する」ボタン、数量欄、アイテムの写真等のような他の対話型要素を含んでもよい。ＳＤＰは、製品を提供する販売者のリストをさらに含むことができる。リストは各販売者が提供する価格に基づいて注文されてもよく、その結果、最低価格で製品を販売することを提案する販売者は最上位にリストされてもよい。リストは最高ランクの販売者が最上位にリストされるように、販売者ランキングに基づいて注文されてもよい。販売者ランキングは、例えば、約束されたＰＤＤを満たした販売者の過去の実績を含む複数の要因に基づいて定式化することができる。外部フロントエンドシステム１０３は、ＳＤＰを要求元ユーザデバイスに配信することができる（例えば、ネットワークを介して）。

要求元ユーザデバイスは、製品情報を記載したＳＤＰを受け取る場合がある。ＳＤＰを受信すると、次いでユーザデバイスはＳＤＰと対話することができる。例えば、要求元ユーザデバイスのユーザは、ＳＤＰの「カートに入れる」ボタンをクリックするか、そうでなければ対話することができる。これにより、ユーザに関連付けられたショッピングカートに製品が追加される。ユーザデバイスはこの要求を送信して、製品をショッピングカートに追加し、外部フロントエンドシステム１０３に送ることができる。

外部フロントエンドシステム１０３はカートページ（例えば、図１Ｄ）を生成することができる。いくつかの実施形態では、カートページは、ユーザが仮想「ショッピングカート」に追加した製品を列挙する。ユーザデバイスは、ＳＲＰ、ＳＤＰ、または他のページ上のアイコンをクリックするか、または他の方法で対話することによってカートページを要求することができる。いくつかの実施形態では、カートページが、ユーザがショッピングカートに追加した全ての製品、ならびに各製品の数量、各製品のアイテム当たりの価格、関連する数量に基づく各製品の価格、ＰＤＤに関する情報、配送方法、出荷費用、ショッピングカート内の製品を修正するためのユーザインターフェース要素（例えば、数量の削除または修正）、他の製品を注文するかまたは製品の定期的な配送を設定するためのオプション、利息支払いを設定するためのオプション、購入を進めるためのユーザインターフェース要素などのカート内の製品に関する情報を列挙することができる。ユーザデバイスのユーザはショッピングカート内の製品の購入を開始するために、ユーザインターフェース要素（例えば、「今すぐ買う」と読むボタン）をクリックするか、または他の方法でユーザインターフェース要素と対話することができる。そうすると、ユーザデバイスは、この要求を送信して、外部フロントエンドシステム１０３への購入を開始することができる。

外部フロントエンドシステム１０３は購入を開始するための要求の受信に応じて、注文ページ（例えば、図１Ｅ）を発生することができる。注文ページはいくつかの実施形態ではショッピングカートからのアイテムを再リストし、支払および出荷に関するインプットを要求する。例えば、注文ページはショッピングカート内のアイテムの購入者に関する情報（例えば、名前、住所、電子メールアドレス、電話番号）、受取人に関する情報（例えば、名前、住所、電話番号、配送情報）、出荷情報（例えば、配送および／または集荷の速度／方法）、支払情報（例えば、クレジットカード、銀行振込、小切手、記憶クレジット）、現金受領を要求するためのユーザインターフェース要素（例えば、税務目的のための）などを要求するセクションを含むことができる。外部フロントエンドシステム１０３は、注文ページをユーザデバイスへ送信することが可能である。

ユーザデバイスは注文ページに情報を入力し、その情報を外部フロントエンドシステム１０３に送信するユーザインターフェース要素をクリックするか、または他の方法で対話することができる。そこから、外部フロントエンドシステム１０３はショッピングカート内の製品との新しい注文の作成および加工を可能にするために、システム１００内の様々なシステムに情報を送信することができる。

いくつかの実施形態では、外部フロントエンドシステム１０３が、販売者が注文に関する情報を送受信することを可能にするようにさらに構成されてもよい。

内部フロントエンドシステム１０５はいくつかの実施形態では内部ユーザ（例えば、システム１００を所有し、運営し、またはリースする団体の従業員）がシステム１００内の１つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装することができる。例えば、システム１００がシステムの提示を可能にして、ユーザがアイテムの注文を行うことをできるようにする実施形態では、内部フロントエンドシステム１０５は、内部ユーザが注文に関する診断および統計情報を見たり、アイテム情報を修正したり、またはアイテムに関する統計を見直したりできるようにするウェブサーバとして実装されることができる。例えば、内部フロントエンドシステム１０５は、アパッチＨＴＴＰサーバ、マイクロソフトインターネットインフォメーションサービス（ＩＩＳ）、ＮＧＩＮＸ等のソフトウェアを実行する１つまたは複数のコンピュータとして実現することができる。他の実施形態では、内部フロントエンドシステム１０５がシステム１００に示されるシステムまたはデバイス（ならびに図示されない他のデバイス）からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得された情報に基づいて受信された要求への応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。

いくつかの実施形態では、内部フロントエンドシステム１０５がウェブキャッシングシステム、データベース、検索システム、支払いシステム、分析システム、注文監視システムなどのうちの１つまたは複数を含むことができる。一態様では内部フロントエンドシステム１０５がこれらのシステムのうちの１つまたは複数を備えることができ、別の態様では内部フロントエンドシステム１０５がこれらのシステムのうちの１つまたは複数に接続されたインターフェース（例えば、サーバ間、データベース間、または他のネットワーク接続）を備えることができる。

輸送システム１０７は、いくつかの実施形態ではシステム１００内のシステムまたはデバイスとモバイルデバイス１０７Ａ～１０７Ｃとの間の通信を可能にするコンピュータシステムとして実施することができる。いくつかの実施形態では、輸送システム１０７が１つまたは複数のモバイルデバイス１０７Ａ～１０７Ｃ（例えば、携帯電話、スマートフォン、ＰＤＡなど）から情報を受信することができる。例えば、いくつかの実施形態では、モバイルデバイス１０７Ａ～１０７Ｃが配送作業員によって操作されるデバイスを含んでもよい。配送作業員は、正社員、臨時社員、または交替社員であってもよく、モバイルデバイス１０７Ａ～１０７Ｃを利用して、ユーザによって注文された製品を含む荷物の配送を行うことができる。例えば、荷物を配信するために、配送作業員は、どの荷物を配送すべきか、およびそれをどこに配送すべきかを示す通知をモバイルデバイス上で受信することができる。配送位置に到着すると、配送作業員は荷物を（例えば、トラックの後ろに、または荷物の箱に）配置し、モバイルデバイスを使用して荷物上の識別子に関連するデータ（例えば、バーコード、イメージ、文字列、ＲＦＩＤタグなど）を走査または他の方法で捕捉し、荷物を（例えば、前扉に置いたままにし、警備員に残したままにし、受信者に渡すなどによって）配送することができる。いくつかの実施形態では、配送作業員が荷物の写真をキャプチャすることができ、および／またはモバイルデバイスを使用してシグネチャを取得することができる。モバイルデバイスは例えば、時刻、日付、ＧＰＳ位置、写真、配送作業員に関連付けられた識別子、モバイルデバイスに関連付けられた識別子などを含む配送に関する情報を含む情報を輸送システム１０７に送信することができる。輸送システム１０７はシステム１００内の他のシステムによるアクセスのために、この情報をデータベース（図示せず）に記憶することができる。輸送システム１０７はいくつかの実施形態ではこの情報を使用して、特定の荷物の位置を示す追跡データを準備し、他のシステムに送信することができる。

いくつかの実施形態ではあるユーザが１つの種類のモバイルデバイスを使用することができる（例えば、永久作業員はバーコードスキャナ、スタイラス、および他のデバイスなどのカスタムハードウェアと共に専用のＰＤＡを使用することができる）が他のユーザは他の種類のモバイルデバイスを使用することができる（例えば、一時的または移動作業員は既製の携帯電話および／またはスマートフォンを利用することができる）。

いくつかの実施形態では、輸送システム１０７がユーザをそれぞれのデバイスに関連付けることができる。例えば、輸送システム１０７はユーザ（例えば、ユーザ識別子、従業員識別子、または電話番号）とモバイルデバイス（例えば、国際移動装置アイデンティティ（ＩＭＥＩ）、国際移動加入識別子（ＩＭＳＩ）、電話番号、汎用一意識別子（ＵＵＩＤ）、またはグローバル一意（ＧＵＩＤ）によって表される）との間の関連を記憶することができる。輸送システム１０７はこの関連付けを、配送上で受信されたデータと併せて使用して、とりわけ、作業員の位置、作業員の有効性、または作業員のスピードを決定するために、注文内のデータベースに格納されたデータを分析することができる。

販売者ポータル１０９は、いくつかの実施形態では販売者または他の外部エンティティがシステム１００内の１つまたは複数のシステムと電子的に通信することを可能にするコンピュータシステムとして実装され得る。例えば、販売者は、コンピュータシステム（図示せず）を利用して、販売者が販売者ポータル１０９を使用してシステム１００を通して売りたい製品について、製品情報、注文情報、連絡先情報などをアップロードまたは提供することができる。

出荷および注文追跡システム１１１はいくつかの実施形態では（例えば、デバイス１０２Ａ～１０２Ｂを使用するユーザによって）顧客によって注文された製品を含む荷物の位置に関する情報を受信し、記憶し、転送するコンピュータシステムとして実装されてもよい。いくつかの実施形態では、出荷および注文追跡システム１１１は顧客が注文した製品を含む荷物を配送する出荷会社によって運営されるウェブサーバ（図示せず）からの情報を要求または記憶することができる。

いくつかの実施形態では、出荷および注文追跡システム１１１がシステム１００に示されたシステムからの情報を要求し、記憶することができる。例えば、出荷および注文追跡システム１１１は、輸送システム１０７に情報を要求することができる。上述のように、輸送システム１０７はユーザ（例えば、配送作業員）または乗り物（例えば、配送トラック）のうちの１つまたは複数に関連付けられた１つまたは複数のモバイルデバイス１０７Ａ～１０７Ｃ（例えば、携帯電話、スマートフォン、ＰＤＡなど）から情報を受信することができる。いくつかの実施形態では、出荷および注文追跡システム１１１がフルフィルメントセンタ（例えば、フルフィルメントセンタ２００）内の個々の製品の位置を決定するために、倉庫管理システム（ＷＭＳ）１１９から情報を要求することもできる。出荷および注文追跡システム１１１は輸送システム１０７またはＷＭＳ １１９のうちの１つまたは複数からデータを要求し、それを処理し、要求に応じてそれをデバイス（例えば、ユーザデバイス１０２Ａおよび１０２Ｂ）に提示することができる。

フルフィルメント（履行）最適化（ＦＯ）システム１１３はいくつかの実施形態では他のシステム（例えば、外部フロントエンドシステム１０３および／または出荷および注文追跡システム１１１）からの顧客注文のための情報を記憶するコンピュータシステムとして実装されてもよい。また、ＦＯシステム１１３は、特定のアイテムがどこに保持されているか、またはどこに記憶されているかを記述する情報を記憶することもできる。例えば、特定のアイテムは１つのフルフィルメントセンタにのみ格納でき、他の特定のアイテムは複数のフルフィルメントセンタに格納できる。さらに他の実施形態では、特定のフルフィルメントセンタが特定の組のアイテム（例えば、生鮮食品または冷凍製品）のみを格納するように設計されてもよい。ＦＯシステム１１３はこの情報ならびに関連する情報（例えば、数量、サイズ、受領日、有効期限など）を格納する。

また、ＦＯシステム１１３は、製品ごとに対応するＰＤＤ（約束配送日）を計算してもよい。ＰＤＤは、いくつかの実施形態では１つまたは複数の要因に基づくことができる。例えば、ＦＯシステム１１３は製品に対する過去の需要（例えば、その製品がある期間中に何回注文されたか）、製品に対する予想需要（例えば、来るべき期間中にその製品を注文するために何人の顧客が予想されるか）、ある期間中にいくつの製品が注文されたかを示すネットワーク全体の過去の需要、来るべき期間中にいくつの製品が注文されることが予想されるかを示すネットワーク全体の予想需要、各製品を格納する各フルフィルメントセンタ200に格納された製品の1つ以上のカウント、その製品に対する予想または現行注文などに基づいて、製品に対するＰＤＤを計算することができる。

いくつかの実施形態では、ＦＯシステム１１３が定期的に（例えば、１時間ごとに）製品ごとにＰＤＤを決定し、それを検索または他のシステム（例えば、外部フロントエンドシステム１０３、ＳＡＴシステム１０１、出荷および注文追跡システム１１１）に送信するためにデータベースに格納することができる。他の実施形態では、ＦＯシステム１１３が１つまたは複数のシステム（例えば、外部フロントエンドシステム１０３、ＳＡＴシステム１０１、出荷および注文追跡システム１１１）から電子要求を受信し、オンデマンドでＰＤＤを計算することができる。

フルフィルメントメッセージングゲートウェイ１１５はいくつかの実施形態ではＦＯシステム１１３などのシステム１００内の１つ以上のシステムから１つのフォーマットまたはプロトコルで要求または応答を受信し、それを別のフォーマットまたはプロトコルに変換し、変換されたフォーマットまたはプロトコルで、ＷＭＳ １１９または第三者フルフィルメントシステム１２１Ａ、１２１Ｂ、または１２１Ｃなどの他のシステムに転送し、またその逆も同様である、コンピュータシステムとして実装することができる。

サプライチェーン管理（ＳＣＭ）システム１１７は、いくつかの実施形態では予測機能を実行するコンピュータシステムとして実装することができる。例えば、ＳＣＭシステム１１７は例えば、製品に対する過去の需要、製品に対する予想される需要、ネットワーク全体の過去の需要、ネットワーク全体の予想される需要、各フルフィルメントセンタ２００に格納された計数製品、各製品に対する予想または現行注文などに基づいて、特定の製品に対する需要の水準を予測することができる。この予測された水準および全てのフルフィルメントセンタにわたるそれぞれの製品の量に応じて、ＳＣＭシステム１１７は特定の製品に対する予測された需要を満たすのに充分な量を購入し、ストックするための１つまたは複数の購入注文を生成することができる。

倉庫管理システム（ＷＭＳ）１１９は、いくつかの実施形態ではワークフローをモニタするコンピュータシステムとして実装されてもよい。例えば、ＷＭＳ １１９は個別イベントを示す個別デバイス（例えば、デバイス１０７Ａ－１０７Ｃまたは１１９Ａ－１１９Ｃ）からイベントデータを受信することができる。例えば、ＷＭＳ １１９は、荷物を走査するためにこれらのデバイスの１つの使用を示すイベントデータを受信してもよい。フルフィルメントセンタ２００および図２に関して以下で論じるように、フルフィルメントプロセス中に、荷物識別子（例えば、バーコードまたはＲＦＩＤタグデータ）は特定の段階で機械によってスキャンまたは読み取ることができる（例えば、自動またはハンドヘルドバーコードスキャナ、ＲＦＩＤリーダ、高速カメラ、タブレット１１９Ａ、モバイルデバイス／ＰＤＡ １１９Ｂ、コンピュータ１１９Ｃなどのデバイス）。ＷＭＳ １１９は荷物識別子、時刻、日時、位置、ユーザ識別子、または他の情報と共に、荷物識別子の走査または読取りを示す各々の事象を対応するデータベース（図示せず）に記憶することができ、この情報を他のシステム（例えば、出荷および注文追跡システム１１１）に提供することができる。

ＷＭＳ １１９はいくつかの実施形態では１つまたは複数のデバイス（例えば、デバイス１０７Ａ～１０７Ｃまたは１１９Ａ～１１９Ｃ）を、システム１００に関連付けられた１つまたは複数のユーザに関連付ける情報を記憶してもよい。例えば、いくつかの状況では、ユーザ（パートまたはフルタイムの従業員など）は、ユーザがモバイルデバイスを所有する（例えば、モバイルデバイスがスマートフォンである）という点で、モバイルデバイスに関連付けられてもよい。他の状況では、ユーザは、ユーザが一時的にモバイルデバイスの管理下にある（例えば、ユーザは日の始めにモバイルデバイスを借り、日中にそれを使用し、日の終わりにそれを返す）という点で、モバイルデバイスに関連付けられてもよい。

ＷＭＳ １１９は、いくつかの実施形態ではシステム１００に関連する各ユーザの作業ログを維持することができる。例えば、ＷＭＳ １１９は任意の割り当てられたプロセス（例えば、トラックのアンローディング、ピックゾーンからのアイテムのピッキング、リビン（ｒｅｂｉｎ）ウォールワーク、パッキングアイテム）、ユーザ識別子、位置（例えば、フルフィルメントセンタ２００内のフロアまたはゾーン）、従業員によってシステム内を移動されたユニットの数（例えば、ピックされたアイテムの数、パックされたアイテムの数）、デバイスに関連付けられた識別子（例えば、デバイス１１９Ａ～１１９Ｃ）などを含む、各従業員に関連付けられた情報を記憶することができる。いくつかの実施形態では、ＷＭＳ １１９がデバイス１１９Ａ～１１９Ｃ上で動作するタイムキーピングシステムなどのタイムキーピングシステムからチェックインおよびチェックアウト情報を受信することができる。

第三者フルフィルメント（３ＰＬ）システム１２１Ａ～１２１Ｃは、いくつかの実施形態ではロジスティクスおよび製品のサードパーティプロバイダに関連するコンピュータシステムを表す。例えば、一部の製品がフルフィルメントセンタ２００に保管されている間（図２に関して以下で説明するように）、他の製品はオフサイトに保管されてもよく、オンデマンドで生産されてもよく、またはそうでなければフルフィルメントセンタ２００に保管するために利用できない可能性がある。３ＰＬシステム１２１Ａ～１２１ Ｃは、ＦＯシステム１１３から注文を受信するように構成されてもよく（例えば、ＦＭＧ １１５を介して）、製品および／またはサービスを顧客に直接提供してもよい（例えば、配送または設置）。いくつかの実施形態では３ＰＬシステム１２１Ａ～１２１Ｃのうちの１つまたは複数がシステム１００の一部とすることができ、他の実施形態では３ＰＬシステム１２１Ａ～１２１Ｃのうちの１つまたは複数がシステム１００の外部（例えば、サードパーティプロバイダによって所有または運営される）とすることができる。

フルフィルメントセンタ認証システム（ＦＣ認証）１２３は、いくつかの実施形態では様々な機能を有するコンピュータシステムとして実装され得る。例えば、いくつかの実施形態では、ＦＣ認証１２３がシステム１００内の１つまたは複数の他のシステムのためのシングルサインオン（ＳＳＯ）サービスとして動作することができる。例えば、ＦＣ認証１２３はユーザが内部フロントエンドシステム１０５を介してログインすることを可能にし、ユーザが出荷および注文追跡システム１１１においてリソースにアクセスするための同様の特権を有していることを決定し、ユーザが２回目のログイン処理を必要とせずにそれらの特権にアクセスすることを可能にしてもよい。他の実施形態では、ＦＣ認証１２３は、ユーザ（例えば、従業員）が自分自身を特定の作業に関連付けることを可能にしてもよい。例えば、従業員の中には、電子デバイス（デバイス１１９Ａ～１１９Ｃなど）を持たない者もおり、その代わりに、１日の過程中に、フルフィルメントセンタ２００内でタスクからタスクへ、およびゾーンからゾーンへ移動してもよい。ＦＣ認証１２３は、それらの従業員は、彼らがどの仕事をしているか、および彼らが様々な時刻にどの区域にいるかを示すことを可能にするように構成されてもよい。

労務管理システム（ＬＭＳ）１２５は、いくつかの実施形態では従業員（フルタイムおよびパートタイムの従業員を含む）のための出勤および残業を記憶するコンピュータシステムとして実装されてもよい。例えば、ＬＭＳ １２５は、ＦＣ認証１２３、ＷＭＳ１１９、デバイス１１９Ａ－１１９Ｃ、輸送システム１０７、および／またはデバイス１０７Ａ－１０７Ｃから情報を受信することができる。

図１Ａに示される特定の構成は単なる例である。例えば、図１ＡはＦＯシステム１１３に接続されたＦＣ認証システム１２３を示すが、全ての実施形態がこの特定の構成を必要とするわけではない。実際、いくつかの実施形態では、システム１００内のシステムがインターネット、イントラネット、ＷＡＮ（ワイドエリアネットワーク）、ＭＡＮ（メトロポリタンエリアネットワーク）、ＩＥＥＥ ８０２．１１ａ／ｂ／ｇ／ｎ規格に準拠する無線ネットワーク、専用線などを含む１つまたは複数の公衆またはプライベートネットワークを介して互いに接続され得る。いくつかの実施形態では、システム１００内のシステムの１つ以上がデータセンター、サーバファームなどに実装された１つ以上の仮想サーバとして実装されてもよい。

図２は、フルフィルメントセンタ２００を示す。フルフィルメントセンタ２００は、注文時に顧客に出荷するためのアイテムを格納する物理的な場所の実例である。フルフィルメントセンタ（ＦＣ）２００は多数のゾーンに分割することができ、その各々を図２に示す。これらの「ゾーン」はいくつかの実施形態ではアイテムを受け取り、アイテムを保管し、アイテムを取り出し、アイテムを出荷する処理の様々な段階の間の仮想分割と考えることができる。したがって、「ゾーン」は図２に示されているが、ゾーンの他の分割も可能であり、いくつかの実施形態では図２のゾーンを省略、複製、または修正することができる。

インバウンドゾーン２０３は、図１Ａのシステム１００を使用して製品を販売しようとする販売者からアイテムを受け取るＦＣ ２００の領域を表す。例えば、販売者は、トラック２０１を使用してアイテム２０２Ａおよび２０２Ｂを配送することができる。アイテム２０２Ａはそれ自体の出荷パレットを占有するのに十分な大きさの単一のアイテムを表すことができ、アイテム２０２Ｂは、空間を節約するために同じパレット上に一緒に積み重ねられた１組のアイテムを表すことができる。

作業員はインバウンドゾーン２０３でアイテムを受信し、コンピュータシステム（図示せず）を使用して、アイテムの破損および正当性を任意選択で検査することができる。例えば、作業員は、コンピュータシステムを使用して、アイテム２０２Ａおよび２０２Ｂの数量をアイテムの注文数量と比較することができる。数量が合致しない場合、その作業員は、アイテム２０２Ａまたは２０２Ｂのうちの１つまたは複数を拒否することができる。数量が一致すれば、作業員はそれらのアイテムをバッファゾーン２０５まで（例えば、代車、手押し車、フォークリフト、または手動で）移動させることができる。バッファゾーン２０５は例えば、予測される需要を満たすのに十分な量のアイテムがピッキングゾーンにあるため、ピッキングゾーンで現在必要とされていないアイテムのための一時保管領域であってもよい。いくつかの実施形態では、フォークリフト２０６がバッファゾーン２０５の周り、およびインバウンドゾーン２０３とドロップゾーン２０７との間でアイテムを移動させるように動作する。ピッキングゾーンにアイテム２０２Ａまたは２０２Ｂが必要な場合（例えば、予想される需要のため）、フォークリフトは、アイテム２０２Ａまたは２０２Ｂをドロップゾーン２０７に移動させることができる。

ドロップゾーン２０７は、アイテムがピッキングゾーン２０９に移動される前にそれらを保管するＦＣ ２００の領域であってもよい。ピッキングタスクに割り当てられた作業員（「ピッカー」）はピッキングゾーン内のアイテム２０２Ａおよび２０２Ｂに接近し、ピッキングゾーンのバーコードをスキャンし、モバイルデバイス（例えば、デバイス１１９Ｂ）を使用してアイテム２０２Ａおよび２０２Ｂに関連するバーコードをスキャンすることができる。次いで、ピッカーはアイテムをピッキングゾーン２０９まで（例えば、それをカート上に置くか、またはそれを運ぶことによって）取り込むことができる。

ピッキングゾーン２０９は、アイテム２０８が保管ユニット２１０に保管されるＦＣ ２００の領域であってもよい。いくつかの実施形態では、保管ユニット２１０が物理的な棚、本棚、箱、運搬箱、冷蔵庫、冷凍庫、冷蔵庫などのうちの１つまたは複数を含むことができる。いくつかの実施形態では、ピッキングゾーン２０９が複数のフロアに編成されてもよい。いくつかの実施形態では、作業員または機械が例えば、フォークリフト、エレベータ、コンベアベルト、カート、手押し車、台車、自動ロボットもしくはデバイス、または手動を含む多数の方法で、ピッキングゾーン２０９内にアイテムを移動させることができる。例えば、ピッカーは、アイテム２０２Ａおよび２０２Ｂをドロップゾーン２０７の手押し車またはカートに載せ、アイテム２０２Ａおよび２０２Ｂをピッキングゾーン２０９まで歩くことができる。

ピッカーは、保管ユニット２１０上の特定の空間のようなピッキングゾーン２０９内の特定のスポットにアイテムを配置する（または「収納する」）命令を受信することができる。例えば、ピッカーはモバイルデバイス（例えば、デバイス１１９Ｂ）を使用してアイテム２０２Ａを走査することができる。デバイスは例えば、通路、棚、および位置を示すシステムを使用して、ピッカーがアイテム２０２Ａを収納すべき場所を示すことができる。次に、デバイスはアイテム２０２Ａをその位置に格納する前に、その位置でバーコードを走査するようにピッカーを促すことができる。デバイスは（例えば、ワイヤレスネットワークを介して）図１ＡのＷＭＳ １１９のようなコンピュータシステムにデータを送信し、アイテム２０２Ａがデバイス１１９Ｂを使用してユーザによってその位置に格納されたことを示すことができる。

ユーザが注文を行うと、ピッカーは、保管ユニット２１０から１つまたは複数のアイテム２０８を検索するための命令をデバイス１１９Ｂ上で受信することができる。ピッカーはアイテム２０８を検索し、アイテム２０８上のバーコードを走査し、それを搬送機構２１４上に置くことができる。搬送機構２１４はスライドとして表されているが、いくつかの実施形態では搬送機構がコンベヤーベルト、エレベータ、カート、フォークリフト、手押し車、台車、カートなどのうちの１つまたは複数として実装される。次いで、アイテム２０８は、パッキングゾーン２１１に到達することができる。

パッキングゾーン２１１は、アイテムがピッキングゾーン２０９から受け取られ、最終的に顧客に出荷するために箱または袋にパッキングされる、ＦＣ ２００の領域であってもよい。パッキングゾーン２１１において、受信アイテム（「リビン（ｒｅｂｉｎ）作業員」）に割り当てられた作業員はピッキングゾーン２０９からアイテム２０８を受信し、それがどの注文に対応するかを決定する。例えば、リビン（ｒｅｂｉｎ）作業員はアイテム２０８上のバーコードを走査するために、コンピュータ１１９Ｃなどのデバイスを使用することができる。コンピュータ１１９Ｃはどの注文アイテム２０８が関連付けられているかを視覚的に示すことができる。これは例えば、注文に対応する壁面２１６上の空間または「セル」を含むことができる。注文が完了すると（例えば、セルが注文のための全てのアイテムを含むため）、リビン（ｒｅｂｉｎ）作業員は、注文が完了したことをパッキング作業員（または「パッカー」）に示すことができる。パッカーはセルからアイテムを回収し、出荷のために箱または袋に入れることができる。その後、パッカーは例えば、フォークリフト、カート、台車、手押し車、コンベヤーベルトを介して、手動、または他の方法で、箱またはバッグをハブゾーン２１３に送ることができる。

ハブゾーン２１３は、パッキングゾーン２１１から全ての箱または袋（「荷物」）を受け取るＦＣ ２００の領域であってもよい。ハブゾーン２１３内の作業員および／またはマシンは荷物２１８を検索し、それぞれの荷物が行こうとする配送領域の一部を決定し、荷物を適切なキャンプゾーン２１５にルーティングすることができる。例えば、配送領域が２つのより小さいサブ領域を有する場合、荷物は２つのキャンプゾーン２１５のうちの１つに進む。いくつかの実施形態では、作業員またはマシンが（例えば、デバイス１１９Ａ～１１９Ｃのうちの１つを使用して）荷物を走査して、その最終的な宛先を決定することができる。荷物をキャンプゾーン２１５にルーティングすることは、例えば、荷物が向けられている地理的エリアの一部を（例えば、郵便番号に基づいて）決定することと、地理的エリアの一部に関連付けられたキャンプゾーン２１５を決定することとを含むことができる。

キャンプゾーン２１５はいくつかの実施形態では１つまたは複数の建物、１つまたは複数の物理的な空間、または１つまたは複数のエリアを備えることができ、荷物は、ルートおよび／またはサブルートに分類するためにハブゾーン２１３から受け取られる。いくつかの実施形態ではキャンプゾーン２１５がＦＣ ２００から物理的に分離されているが、他の実施形態ではキャンプゾーン２１５がＦＣ ２００の一部を形成することができる。

キャンプゾーン２１５内の作業員および／またはマシンは例えば、目的地と現存するルートおよび／またはサブルートとの照合、ルートおよび／またはサブルートごとの作業負荷の算出、時刻、出荷方法、荷物２２０を出荷する費用、荷物２２０内のアイテムに関連付けられたＰＤＤなどに基づいて、荷物２２０がどのルートおよび／またはサブルートに関連付けられるべきかを決定することができる。いくつかの実施形態では、作業員またはマシンが（例えば、デバイス１１９Ａ～１１９Ｃのうちの１つを使用して）荷物を走査して、その最終的な宛先を決定することができる。荷物２２０が特定のルートおよび／またはサブルートに割り当てられると、作業員および／またはマシンは、出荷される荷物２２０を移動させることができる。例示的な図２において、キャンプゾーン２１５は、トラック２２２、自動車２２６、および配送作業員２２４Ａおよび２２４Ｂを含む。いくつかの実施形態では、トラック２２２が配送作業員２２４Ａによって駆動されてもよく、配送作業員２２４ＡはＦＣ ２００の荷物を配送する常勤の従業員であり、トラック２２２はＦＣ ２００を所有し、リースし、または運営する同じ企業によって所有され、リースされ、または運営される。いくつかの実施形態では、自動車２２６が配送作業員２２４Ｂによって駆動されてもよく、ここで、配送作業員２２４Ｂは必要に応じて（例えば、季節的に）送達する「屈曲」または時折の作業員である。自動車２２６は、配送作業員２２４Ｂによって所有され、リースされ、または操作され得る。

図３は、製品在庫を最適なレベルに保つためのコンピュータ化されたシステムを含むネットワーク環境３００の例示的な実施形態を示す概略ブロック図である。環境３００は、様々なシステムを含むことができ、それらのそれぞれは、１つまたは複数のネットワークを介して互いに接続され得る。システムはまた、例えばケーブルを使用して、直接接続を介して互いに接続されてもよい。図示のシステムは、ＦＯシステム３１１、ＦＣデータベース３１２、外部フロントエンドシステム３１３、サプライチェーン管理システム３２０、および１つまたは複数のユーザ端末３３０を含む。ＦＯシステム３１１および外部フロントエンドシステム３１３は、設計、機能、または動作において、図１Ａに関して上述したＦＯシステム１１３および外部フロントエンドシステム１０３と同様であってもよい。

ＦＣデータベース３１２は、図２に関して上述したように、ＦＣ ２００での様々な活動から生じる様々なデータを収集、発生、および／または生成する１つまたは複数のコンピュータシステムとして実装され得る。例えば、ＦＣデータベース３１２で発生したデータは、とりわけ、特定のＦＣ（例えば、ＦＣ ２００）によって処理される全ての製品の製品識別子（例えば、在庫保管ユニット（ＳＫＵ））、経時的な各製品の在庫レベル、ならびに各製品の在庫切れイベントの頻度および発生を含むことができる。

いくつかの実施形態では、ＦＣデータベース３１２は、ＦＣ Ａ～Ｃに関連するデータベースを表す、ＦＣ Ａデータベース３１２Ａ、ＦＣ Ｂデータベース３１２Ｂ、およびＦＣ Ｃデータベース３１２Ｃを含むことができる。３つのＦＣおよび対応するＦＣデータベース３１２Ａ～Ｃのみが図３に示されているが、その数は例示的なものに過ぎず、より多くのＦＣおよび対応する数のＦＣデータベースが存在する可能性がある。他の実施形態では、ＦＣデータベース３１２は、全てのＦＣからのデータを収集および格納する集中型データベースであってもよい。ＦＣデータベース３１２が個々のデータベース（例えば、３１２Ａ～Ｃ）を含むか、または単一の集中型データベースを含むかにかかわらず、データベースはクラウドベースのデータベースまたはオンプレミスデータベースを含むことができる。また、いくつかの実施形態では、そのようなデータベースは、１つもしくは複数のハードディスクドライブ、１つもしくは複数のソリッドステートドライブ、または１つもしくは複数の非一時的メモリを含むことができる。

サプライチェーン管理システム（ＳＣＭ）３２０は、設計、機能、または動作において、図１Ａに関して上述したＳＣＭ １１７と同様であってもよい。代替的または追加的に、ＳＣＭ ３２０は、特定の製品の需要レベルを予測し、開示された実施形態と一致するプロセスで１つまたは複数の購入注文を生成するために、ＦＯシステム３１１、ＦＣデータベース３１２、および外部フロントエンドシステム３１３からのデータを集約するように構成され得る。

いくつかの実施形態では、ＳＣＭ ３２０は、データサイエンスモジュール３２１と、アウトバウンドプロファイル生成器（ＯＰＧ）３２２と、需要予測生成器３２３と、ターゲット在庫計画システム（ＴＩＰ）３２４と、インバウンド優先順位付けおよび入れ替えシステム（ＩＰＳ）３２５と、手動注文提出プラットフォーム３２６と、購入注文（ＰＯ）生成器３２７と、報告生成器３２８とを備える。

いくつかの実施形態では、ＳＣＭ ３２０は、１つまたは複数のプロセッサと、１つまたは複数のメモリと、１つまたは複数の入出力（Ｉ／Ｏ）デバイスとを含んでもよい。ＳＣＭ ３２０は、サーバ、汎用コンピュータ、メインフレームコンピュータ、グラフィカルプロセッシングユニット（ＧＰＵ）などの専用コンピューティングデバイス、ラップトップ、またはこれらのコンピューティングデバイスの任意の組み合わせの形態をとることができる。これらの実施形態では、ＳＣＭ ３２０の構成要素（すなわち、データサイエンスモジュール３２１、ＯＰＧ ３２２、需要予測生成器３２３、ＴＩＰ ３２４、ＩＰＳ ３２５、手動注文提出プラットフォーム３２６、ＰＯ生成器３２７、および報告生成器３２８）は、１つまたは複数のメモリに格納された命令に基づいて１つまたは複数のプロセッサによって実行される１つまたは複数の機能ユニットとして実装されてもよい。ＳＣＭ ３２０は、独立型システムであってもよいし、より大きなシステムの一部であってもよいサブシステムの一部であってもよい。

別法として、ＳＣＭ ３２０の構成要素は、ネットワークを介して互いに通信する１つまたは複数のコンピュータシステムとして実装されてもよい。この実施形態では、１つまたは複数のコンピュータシステムの各々は、１つまたは複数のプロセッサ、１つまたは複数のメモリ（すなわち、非一時的コンピュータ可読媒体）、および１つまたは複数の入力／出力（Ｉ／Ｏ）デバイスを備えることができる。いくつかの実施形態では、１つまたは複数のコンピュータシステムの各々は、サーバ、汎用コンピュータ、メインフレームコンピュータ、ＧＰＵなどの専用コンピューティングデバイス、ラップトップ、またはこれらのコンピューティングデバイスの任意の組み合わせの形態をとることができる。

データサイエンスモジュール３２１は、いくつかの実施形態では、ＳＣＭ ３２０の他の構成要素による使用のための様々なパラメータまたはモデルを決定するように構成された１つまたは複数のコンピューティングデバイスを含むことができる。例えば、データサイエンスモジュール３２１は、各製品の需要レベルを決定する需要予測生成器３２３によって使用される予測モデルを開発することができる。いくつかの実施形態では、データサイエンスモジュール３２１は、予測モデルを訓練し、将来の需要のレベルを予測するために、ＦＯシステム３１１からの注文情報および外部フロントエンドシステム３１３からのグランスビュー（すなわち、製品のウェブページビューの数）を検索することができる。注文情報は、経時的に販売されたアイテム数、販売促進期間中に販売されたアイテム数、および一定期間中に販売されたアイテム数などの販売統計を含むことができる。データサイエンスモジュール３２１は、売上統計、グランスビュー、季節、曜日、今度の休日などのパラメータに基づいて予測モデルを訓練することができる。いくつかの実施形態では、データサイエンスモジュール３２１はまた、ＰＯ生成器３２７によって生成されたＰＯを介して注文された製品が注文されるときに、図２のインバウンドゾーン２０３からデータを受信することもできる。データサイエンスモジュール３２１は、そのようなデータを使用して、特定の供給者のフルフィルメント率（すなわち、注文された数量と比較して販売可能な状態で受信された製品の一部である）、推定リードタイムおよび出荷期間などの様々な供給者統計を決定することができる。データサイエンスモジュール３２１は、繰り返しまたは定期的に、ＦＣデータベース３１２からデータを受信することができる。このデータは、例えば、データ、特定のＦＣ（例えば、ＦＣ ２００）によって取り扱われる全ての製品の製品識別子（例えば、ＳＫＵ）、経時的な各製品の在庫レベル、ならびに各製品の在庫切れイベントの頻度および発生を含むことができる。次いで、ＯＰＧ ３２２は、データサイエンスモジュール３１１によって受信されたパラメータに基づいて各ＦＣのプロファイルを生成することができる。プロファイルを生成することは、いくつかの実施形態では、ＦＣデータベースから受信したデータおよびパラメータを１つまたは複数のデータセットに集約することができ、プロファイルは１つまたは複数のデータセットからなる。

いくつかの実施形態では、ＦＣデータベースは、ＦＣの履歴在庫を格納するための履歴在庫データベースを含むことができる。例えば、履歴在庫データは、ＦＣに現在および以前に格納された製品、製品が格納されてＦＣから出荷された時間、製品がＦＣに格納された期間、製品の価格、製品のブランドなどのうちの少なくとも１つを含むかまたは識別することができる。

需要予測生成器３２３は、いくつかの実施形態では、データサイエンスモジュール３２１によって開発された予測モデルを使用して特定の製品の需要レベルを予測するように構成された１つまたは複数のコンピューティングデバイスを含むことができる。より具体的には、予測モデルは、各製品の需要予測数量を出力することができ、需要予測数量は、所与の期間（例えば、１日）に１人または複数の顧客に販売されると予測される製品の特定の数量である。いくつかの実施形態では、需要予測生成器３２３は、所定の期間にわたる所与の期間ごとの需要予測数量（例えば、５週間の期間にわたる各日の需要予測数量）を出力することができる。各需要予測数量はまた、製品在庫レベルを最適化する際により柔軟性を提供するために、標準偏差数量（例えば、±５）または範囲（例えば、最大３０および最小２５）を含むことができる。

いくつかの実施形態では、ＯＰＧ ３２２は、データサイエンスモジュール３２１によって開発されたモデルを使用して、システム内の各ＦＣ（例えば、ＦＣ Ａ、ＦＣ Ｂ、ＦＣ Ｃ）のプロファイルを生成するように構成された１つまたは複数のコンピューティングデバイスを含むことができる。より具体的には、プロファイルモデルは、各ＦＣについて、ＦＣが指定された期間で受信することができるＳＫＵの数量を表すインバウンド容量、ＦＣが指定された期間で配送することができるＳＫＵの数量を表すアウトバウンド容量、ＦＣにおけるＳＫＵの現在の在庫を表す数量、および各ＦＣにおける現在注文されているＳＫＵの数量を出力することができる。これらの特質は、１つまたは複数のＳＫＵのインバウンドフローおよびアウトバウンドフローに関する各ＦＣの容量を示すことができる各ＦＣの動作を表す履歴データに基づくことができる。

ターゲット在庫計画（ＴＩＰ）システム３２４は、いくつかの実施形態では、各製品の推奨注文数量を決定するように構成された１つまたは複数のコンピューティングデバイスを含むことができる。ＴＩＰ ３２４は、最初に製品の予備発注数量を決定し、実際の制約を用いて予備発注数量を制約することによって推奨発注数量を決定することができる。

ＴＩＰ ３２４は、需要予測生成器３２３から各製品の需要予測数量を受信することができる。いくつかの実施形態では、需要予測数量は、一方の次元では、ＳＫＵによって編成された数値、他方の次元では、所与の日に販売されると予測されるユニットの数の表の形態であり得る。表はまた、標準偏差、最大値、最小値、平均値などの需要予測数量の他のパラメータに当てられる追加の次元を含むことができる。別法として、需要予測数量は、ＳＫＵによって編成され、各パラメータ専用の複数の値の配列の形態をとることができる。同じデータを編成する他の適切な形態は、当技術分野で知られているように等しく適用可能であり、本発明の範囲内である。

いくつかの実施形態では、ＴＩＰ ３２４は、データサイエンスモジュール３２１から、製品を供給する１人または複数の供給者の供給者統計データを受信することができる。供給者統計データは、各供給者に関連する情報（例えば、上記のフルフィルメント率）のセットを含むことができる。いくつかの実施形態では、各データセットが供給者によって供給される特定の製品に関連付けられている、特定の供給者についての供給者統計データの複数のセットが存在し得る。

ＴＩＰ ３２４はまた、いくつかの実施形態では、ＯＰＧ ３２２から、各ＳＫＵのインバウンド容量、アウトバウンド容量、現在の製品在庫レベル、および現在注文されている数量を含むプロファイルを受信することができる。現在の製品在庫レベルは、データ検索時の特定のＳＫＵの瞬時カウントを指すことができ、現在注文されている数量は、過去に生成された１つまたは複数のＰＯを通して注文され、対応するＦＣへの配送を待っている特定の製品の合計数量を指すことができる。

ＴＩＰ ３２４は、各製品の予備発注数量を決定し、パラメータの範囲に基づいて予備発注数量を減らすことによって、各製品の推奨発注数量を決定することができる。いくつかの実施形態では、特定の製品の予備発注数量は、その需要予測数量、補償期間、安全在庫期間、現在の在庫レベル、現在の発注数量、臨界比、およびケース数量のうちの少なくとも１つの関数であってもよい。例えば、ＴＩＰ ３２４は、式（１）を用いて予備注文数量を決定することができる。

この数量から、製品Ｘの２２４ユニット、ＴＩＰ ３２４は、現在の在庫レベル（例えば、６０ユニット）および現在注文されている数量（例えば、４０）を減算することができ、それにより１２４ユニットになる。次いで、この数は、事例数量で除算され、整数に切り上げられ、事例数量で再び乗算されることによって、事例数量の倍数（すなわち、箱またはパレット内のユニットの数など、製品が包装されるユニットの数）に切り上げられることができ、これは、この例では、事例数１０を例として想定すると１３０ユニットになる。

いくつかの実施形態では、補償期間は、対応する供給者がＰＯ生成日から製品を配送するのに要する可能性がある予想される時間長以上の所定の時間長であることができる。追加的または代替的に、ＴＩＰ ３２４は、曜日、予想される遅延などの他の要因に基づいて補償期間を調整することもできる。さらに、安全在庫期間は、安全対策として予備発注数量を増加させるように設計された別の所定の時間長であってもよい。安全在庫期間は、需要の突然の増加または予期しない出荷遅延などの予期しないイベントの場合に在庫切れのリスクを低減することができる。いくつかの実施形態では、ＴＩＰ ３２４は、補償期間に基づいて安全在庫期間を設定することができ、例えば、補償期間が１～３日である場合には０日間の安全在庫期間が追加され、補償期間が４～６日である場合には１日間が追加され、補償期間が７日間を超える場合には３日間が追加される。

上述した予備発注数量を決定する複雑なプロセスにもかかわらず、予備発注数量は、主に顧客の需要に基づいており、現実世界の制約を考慮していない可能性がある。したがって、製品在庫を最適化するために、このような制約を考慮するステップが望ましい。ＴＩＰ ３２４は、いくつかの実施形態では、販売統計、現在の製品在庫レベル、および現在注文されている数量などのデータに基づいて、予備発注数量を微調整するように構成された規則のセットを使用して予備発注数量を調整することができる。結果として得られる数量、推奨注文数量は、ＰＯ生成器３２７に送信され得る。

さらに、ＩＰＳ ３２５は、いくつかの実施形態では、各製品の人気度を決定し、決定された人気度に基づいて注文数量に優先順位を付け、優先順位付けされた注文数量を１つまたは複数のＦＣ ２００に分配するように構成された１つまたは複数のコンピューティングデバイスを含むことができる。

手動注文提出プラットフォーム３２６は、いくつかの実施形態では、１つまたは複数の手動注文のユーザ入力を受信するように構成された１つまたは複数のコンピューティングデバイスを含むことができる。手動注文提出プラットフォーム３２６は、図１Ａの内部フロントエンドシステム１０５などの１つまたは複数のコンピューティングデバイスを介してユーザによってアクセス可能なユーザインターフェースを備えることができる。一態様において、手動注文は、ユーザが必要と考えることができ、予備発注数量、推奨注文数量、優先順位付け注文数量、または分配された注文数量の手動調整（例えば、特定の量だけ増加または減少する）を可能にすることができる特定の製品の追加の数量を含むことができる。別の態様では、手動注文は、ＳＣＭ ３２０によって決定された注文数量の代わりに、内部ユーザによって決定されたように注文されるべき特定の製品の合計数量を含むことができる。これらのユーザが決定した発注数量をＳＣＭ生成発注数量と一致させる例示的なプロセスは、図５に関して以下でより詳細に説明される。さらに、ユーザは、いくつかの実施形態では、手動注文が特定のＦＣに割り当てられるように、特定のＦＣを受取場所として指定することができる。いくつかの実施形態では、手動注文提出プラットフォーム３２６を介して提出された注文数量の一部は、それらがＴＩＰ ３２４またはＩＰＳ ３２５によって調整されないように（すなわち、制約されている）、（例えば、注文数量の部分に関連するパラメータを更新することによって、）マークまたはフラグを付けることができる。

いくつかの実施形態では、手動注文提出プラットフォーム３２６が、アパッチＨＴＴＰサーバ、マイクロソフトインターネットインフォメーションサービス（ＩＩＳ）、ＮＧＩＮＸ等のソフトウェアを実行する１つまたは複数のコンピュータとして実装され得る。他の実施形態では、手動注文提出プラットフォーム３２６は、１つまたは複数のユーザ端末３３０からユーザ入力を受信して処理し、受信したユーザ入力に応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。

ＰＯ生成器３２７は、いくつかの実施形態では、ＩＰＳ ３２５による分配の推奨注文数量または結果に基づいて、１つまたは複数の供給者へのＰＯを生成するように構成された１つまたは複数のコンピューティングデバイスを含むことができる。ＳＣＭ ３２０は、この時点までに、追加の在庫を必要とする各製品および各ＦＣ ２００の推奨注文数を決定しており、各製品は、特定の製品を調達または製造し、それを１つまたは複数のＦＣに出荷する１つまたは複数の供給者を有する。特定の供給者は、１つまたは複数の製品を供給することができ、特定の製品は、１つまたは複数の供給者によって供給されることができる。ＰＯ生成器３２７は、ＰＯを生成する際に、供給者に郵送またはファックスで送付する紙ＰＯ、または、供給者に送信する電子ＰＯを発行することができる。

報告生成器３２８は、いくつかの実施形態では、所定のプロトコルに応答して定期的に、または例えば図１Ａのユーザ端末３３０または内部フロントエンドシステム１０５を介したユーザ入力に応答してオンデマンドでレポートを生成するように構成された１つまたは複数のコンピューティングデバイスを含むことができる。報告は、特定の製品の推奨注文数などの特定の情報を出力する単純なものから、履歴データの分析を必要とし、そのような情報をグラフに視覚化する複雑なものにまで及ぶことができる。より具体的には、報告生成器３２８は、ＳＣＭ ３２０によって実行される調整の各ステップで注文数量が予測数量から最終数量にどのように変化したかなどの情報、各ＦＣ ２００のリソースがどれだけ利用されたかの履歴、製品カテゴリ別の予測数量と最終数量の差（すなわち、現実世界の制限を説明するために、予測された量から低減されなければならなかった量）などを含むレポートを生成することができる。

いくつかの実施形態では、ユーザ端末３３０は、ＦＣ ２００で作業しているユーザなどの内部ユーザが、手動注文提出プラットフォーム３２６または報告生成器３２８を介してＳＣＭ ３２０にアクセスすることを可能にするように構成された１つまたは複数のコンピューティングデバイスを含むことができる。ユーザ端末３３０は、パーソナルコンピュータ、携帯電話、スマートフォン、ＰＤＡなどのコンピューティングデバイスの任意の組み合わせを含むことができる。いくつかの実施形態では、内部ユーザは、ユーザ端末３３０を使用して、手動注文提出プラットフォーム３２６によって提供されるウェブインターフェースにアクセスして、１つまたは複数の手動注文を提出することができる。

図４は、１つまたは複数のＦＣ（例えば、ＦＣ ２００）のアウトバウンドプロファイルのインテリジェントな自動生成のための例示的なコンピュータ化されたプロセス４００のフローチャートである。好ましい実施形態では、プロセス４００は、ＯＰＧ ３２２、ＴＩＰ ３２４、またはＩＰＳ ３２５などのＳＣＭ ３２０の１つまたは複数の構成要素によって実行され得る。したがって、例として、プロセス４００は、ＯＰＧ ３２２によって実行されるものとして説明される。しかしながら、プロセス４００またはその一部は、ネットワーク環境３００全体によって、またはプロセスの少なくとも一部（例えば、１つまたは複数のプロセッサ、ＯＰＧ ３２２、需要予測生成器３２３など）を実行することができる環境３００の任意の構成要素によって実行され得る。

プロセス４００はステップ４０１で開始され、ＯＰＧ ３２２は、ＦＣの容量を含むデータを受信するフルフィルメントセンタの容量を含むデータを受信することができる。ＦＣの容量は、ＦＣが保持することができる最大もしくは推定最大在庫量、または指定された期間にＦＣから出荷され得る製品の最大もしくは推定最大数を含むことができる。

ステップ４０１の後、プロセス４００はステップ４０２に進むことができる。ステップ４０２で、ＯＰＧ ３２２は、ＦＣへの複数の到着製品に関連付けられた複数の製品識別子を受信することができる。例えば、顧客が注文を行うと、出荷場所、注文された製品、各ＦＣでの各製品注文の入手可能性などの要因に基づいて、注文または注文内のアイテムを１つまたは複数のＦＣに割り当てることができる。割り当てられると、特定のＦＣへの注文またはアイテムの割り当ては、システム１００内のデータベースに格納することができる（例えば、ＦＣデータベース３１２）。したがって、いくつかの実施形態では、ＯＰＧ ３２２は、各アイテムおよび関連する識別子の割り当てを受信することができ、どのアイテムが各ＦＣに到着するかを示す。

ステップ４０２の後、プロセス４００はステップ４０３に進むことができる。ステップ４０３において、ＯＰＧ ３２２は、受信した製品識別子を使用して、ＦＣで複数の製品のトランザクショナルログを収集および格納することができる。トランザクショナルログは、例えば、ＯＰＧ ３２２によってアクセス可能なデータベース（例えば、ＦＣデータベース３１２）に格納することができる。いくつかの実施形態では、トランザクショナルログは、ＦＣに割り当てられた少なくとも１つの顧客注文、ＦＣに割り当てられた到着製品、製品がＦＣで受け取られた時間、製品が保管された期間、製品がＦＣから出荷された時間、ＦＣに入荷したブランドの数、ＦＣから出荷されたトップブランド、ＦＣでの製品の入手可能性、またはＦＣから出荷された異なるブランドの製品数のうちの少なくとも１つを含むことができる。これらのトランザクショナルログの収集および格納は、連続的または定期的に（例えば、１日１回または１週間に１回）行われ得る。

ステップ４０３の後、プロセス４００はステップ４０４に進むことができる。ステップ４０４において、ＯＰＧ ３２２は、製品識別子を使用してＦＣに格納された複数の製品の現在の在庫を決定することができる。ＯＰＧ ３２２は、例えば、ステップ４０３に関して考察したトランザクショナルログを参照して、ＦＣの在庫に残っている１つまたは複数の製品識別子に関連付けられた製品の量を決定することによって、この決定を行うことができる。

ステップ４０４の後、プロセス４００はステップ４０５に進むことができる。ステップ４０５において、ＯＰＧ ３２２は、機械学習アルゴリズムを使用して、トランザクショナルログおよび現在の在庫のうちの少なくとも一方を使用して、ＦＣのアウトバウンドプロファイルを生成することができる。アウトバウンドプロファイルは、複数のカテゴリの製品の出荷製品の予想されるパーセンテージなど、ＦＣのアウトバウンド容量および期待値に関する複数のメトリクスを含むことができる。カテゴリは、いくつかの実施形態では、ＦＣ、ブランド、トップ販売者、価格帯、または出荷場所における総在庫を含むことができる。いくつかの実施形態では、ＦＣのアウトバウンドプロファイルは、ＦＣからの特定の期間中の予想される出荷製品のパーセンテージではなく、数を含むことができる。特定の期間は、時間、日、週、月、または年など、任意の期間で設定および測定することができる。いくつかの実施形態では、履歴在庫データを使用して、今後のイベントについてアウトバウンドプロファイルを生成することができる。今後のイベントは、例えば、特定のアイテムが割引価格で顧客に販売される予想された販売であってもよい。今後のイベントは、売り上げが大幅に上昇または下降すると予想される予想期間（例えば、より多くの製品が休日期間中にギフトとして販売されることが予想され得る）であってもよい。

ステップ４０４を参照して上記に考察したように、ＯＰＧ ３２２は、機械学習アルゴリズムを使用してアウトバウンドプロファイルを生成することができる。いくつかの実施形態では、アウトバウンドプロファイルは、強化アルゴリズムを使用して生成され得る。いくつかの実施形態では、これは、ＯＰＧ ３２２が機械学習アルゴリズムによって生成された予測モデルを利用してプロファイルを生成する場合に起こり得る。いくつかの実施形態では、機械学習アルゴリズムは、予測モデルを生成するためにデータサイエンスモジュール３２１によって実行され得る。予測モデルを生成することは、トランザクショナルログデータを訓練データセットと検証データセットとに分割することであって、訓練データセットは検証データセットよりも多くのデータを有することと、訓練データセットに基づいて予測モデルを生成することとを含むことができる。例えば、トランザクショナルログは、データベース（例えば、ＦＣデータベース３１２）から検索されることができ、トランザクショナルデータは、ＦＣを介した以前の出力に関連する情報を示す。データサイエンスモジュール３２１は、予測モデルを生成するために、このデータのより大きな部分（すなわち、訓練データセット）を使用することができる。予測モデルは、線形回帰（例えば、Ｌａｓｓｏ回帰、Ｒｉｄｇｅ回帰、Ｅｌａｓｔｉｃ Ｎｅｔ回帰、Ｈｕｂｅｒ回帰、Ｐａｓｓｉｖｅ Ａｇｇｒｅｓｓｉｖｅ回帰、ＲＡＮＳＡＣ回帰、ＳＧＤ回帰など）、非線形回帰（例えば、Ｋ番目の最近傍、分類および回帰ツリー、ＳＶＭ回帰など）、アンサンブル回帰（例えば、ＡＤＡ、袋詰め、ランダムフォレスト、勾配ブースティングなど）、または電子要求情報と関連するＦＣとの間の関係を表すロジスティック回帰などの１つまたは複数の一般的な統計モデルの形式の式であってもよい。

データサイエンスモジュール３２１が予測モデルを生成した後、データサイエンスモジュールは、いくつかの実施形態では、検証データセットを使用して予測モデルを検証することができる。検証データセットは、予測モデルの生成に使用されなかったトランザクショナルログデータの少なくとも一部であってもよい。予測モデルを検証するために、データモジュール３２１は、検証データセット内の各電子要求について各ＦＣのアウトバウンドプロファイルのセットを生成し、予測された関連するアウトバウンドプロファイルを実際のアウトバウンドデータＦＣと比較することができる。予測モデルは、例えば、所定の信頼閾値（例えば、モデルは、関連するＦＣの少なくとも９５％を正しく予測した）を満たす場合に検証され得る。いくつかの実施形態では、検証は、予測モデルの性能を検証データセットと比較し、最も低い誤差（例えば、二乗平均平方根誤差）を有する予測モデルを選択することによって発生する可能性がある。予測モデルが検証された後、ＯＰＧ ３２２は、モデルを受信および適用して、ＦＣの少なくとも１つのアウトバウンドプロファイルを生成することができる。

いくつかの実施形態では、機械学習アルゴリズムは、報酬システムを使用して機械学習アルゴリズムを訓練することによって連続的または定期的に改善され得る。例えば、データサイエンスモジュール３２１は、生成された予測モデルがＦＣにおけるアウトバウンド出荷を高い確度まで予測する場合、「ポイント」をアルゴリズムに割り当てることができる。データサイエンスモジュール３２１は、同様の結果を再現し続けるように、所与の予測に対して受信する「ポイント」の量に基づいて機械学習アルゴリズムを調整または改善するように構成され得る。

いくつかの実施形態では、アウトバウンドプロファイルは、ＦＣレベル、地域レベル、および国レベルで生成され得る。例えば、アウトバウンドプロファイルの生成は、ＦＣを参照して考察された。しかしながら、いくつかの実施形態では、アウトバウンドプロファイルは、複数のＦＣを含む地域に対して生成され得る。上記に考察したように、アウトバウンドＦＣプロファイルは、ＦＣのトランザクショナルログおよび在庫レベルを使用して生成され得る。ただし、これらのトランザクショナルログおよび在庫は、指定された地域のアウトバウンドプロファイルを決定するために地域レベルで集約されてもよいし、国全体のアウトバウンドプロファイルを生成するために国レベルで集約されてもよい。

ステップ４０５の後、プロセス４００はステップ４０６に進むことができる。ステップ４０６において、システムは、アウトバウンドプロファイルをＦＣの実際のアウトバウンド容量と比較することによって、ＦＣの生成されたアウトバウンドプロファイルを使用して、ネットワークアウトバウンドを管理する。このステップは、いくつかの実施形態では、ＴＩＰ ３２４によって実行され得る。例えば、ＴＩＰ ３２４は、各ＦＣのアウトバウンドプロファイルをそれらの実際のアウトバウンド容量と比較することに基づいて、配送の遅延、アイテムの紛失などが生じる可能性があるので、それらの容量外の注文を実行するために割り当てられることを防止するために、いくつかの注文は異なるＦＣに割り当て、または再割り当てされなければならないと決定することができる。別の例では、ＴＩＰ ３２４は、各ＦＣのアウトバウンドプロファイルをそれらの実際のアウトバウンド容量と比較し、ＦＣでの需要を満たすために予想されるアウトバウンドがＦＣのアウトバウンド容量を超え、したがって、需要を満たすためにＦＣのアウトバウンド容量を増加させるために追加のリソース、ストレージスペース、または作業者が必要であると決定することができる。この決定を行うと、ＴＩＰ ３２４は、いくつかの実施形態では、ＦＣ容量を増加させるために追加のリソース、ストレージスペース、作業者などのうちの１つまたは複数が必要であるという通知をデバイスに表示させる命令をデバイス（例えば、ＷＭＳ １１９のデバイス１１９Ａ、１１９Ｂ、および１１９Ｃ）に送信することができる。地域レベルまたは国レベルで、例えば、ネットワークアウトバウンドを管理することは、アウトバウンド容量を増加させるために新しいＦＣおよび／または倉庫を構築すべきかどうか、ならびにどこにそれらを構築すべきかを決定することを含むことができる。

ネットワークアウトバウンドを管理することはまた、各ＦＣにターゲット在庫レベルを設定し、需要を満たすことができるように１つまたは複数のＦＣへの製品のインバウンド出荷を管理するなどの在庫計画を含むことができる。例えば、ＩＰＳ ３２５は、ＦＣプロファイルから導出された予想されるアウトバウンドレベルを満たすように設定されたターゲット在庫レベルを決定し、さらに、ターゲット在庫レベルに基づいて、所与のアイテムのうちのより多くのまたはより少ないものがインバウンドとしてＦＣに送信されるべきかどうかを決定することができる。

図５は、アウトバウンドプロファイルに基づいて在庫レベルを管理するために使用され得る例示的なプロセスおよび／または論理５００のフローチャートを提供する。このプロセスは、例えば、ＩＰＳ ３２５の１つまたは複数のプロセッサによって実行され得る。プロセス５００は、ＩＰＳ ３２５がアウトバウンドプロファイルに基づいて特定の製品のターゲット在庫を決定した後、ステップ５０１で開始することができる。次いで、ステップ５０２で、１つまたは複数のプロセッサは、ＦＣにおける製品の現在の在庫がターゲット在庫に等しいかどうかを判定することができる。現在の在庫がターゲット在庫と「等しい」かどうかのこの判定は、いくつかの実施形態では、現在の在庫の正確な数量または絶対値が、ターゲット在庫の正確な数量または絶対値と一致することに基づくことができる。現在の在庫がターゲット在庫に等しい場合、そのときステップ５０３において、１つまたは複数のプロセッサは、ＦＣにおける製品の現在の在庫を維持するための命令を送信する。１つまたは複数のプロセッサは、ステップ５０５で、ＦＣにおける製品の現在のインバウンド数量がＦＣにおける製品のアウトバウンド数量に等しいかどうかをさらに判定することができる。そうである場合、ステップ５０６で、現在の在庫が一定に維持されるように、インバウンド数量を維持するために、１つまたは複数のプロセッサがデバイスに命令を送信することができる。そうでなければ、ステップ５０７で、１つまたは複数のプロセッサは、インバウンド量がアウトバウンド量に等しくなるようにインバウンド量を修正する命令を送信することができる。

別法として、ステップ５０２において、１つまたは複数のプロセッサは、現在の在庫がターゲット在庫に等しくないと決定することができる。この場合、ＯＯＳまたは過剰在庫を防止するために、ステップ５０４で、１つまたは複数のプロセッサは、ＦＣにおける製品のインバウンド数量を修正するための命令をデバイスに送信することができる。例えば、現在の在庫がターゲット在庫よりも少ないと決定された場合、そのとき送信された命令は、インバウンド数量がアウトバウンド数量よりも多くなるように製品のインバウンド数量を修正することであり得る。対照的に、製品の現在の在庫がターゲット在庫よりも多い場合、命令は、インバウンド数量がアウトバウンド数量よりも少なくなるようにインバウンド数量を修正することであり得る。プロセスはステップ５０２に戻ることができ、現在の在庫は、ターゲット在庫に等しくなるまで調整され続けることができる。さらに、このプロセスはステップの順序として説明されているが、１つまたは複数のプロセッサは、上述の決定（例えば、ステップ５０２および５０５において）を連続的に行うことによって現在の在庫レベルを連続的に評価および修正するように構成され得る。プロセス５００は、ＦＣアウトバウンドプロファイルに基づいてＦＣにおけるインバウンド出荷数量を管理するものとして説明されているが、同じプロセスまたは同様のプロセスは、生成された地域および国のアウトバウンドプロファイルにそれぞれ基づいて地域エリアまたは国エリアへのインバウンド出荷数量を管理するために使用され得る。

本開示はその特定の実施形態を参照して示され、説明されてきたが、本開示は修正なしに、他の環境において実施され得ることが理解されるのであろう。前述の説明は、例示の目的で提示されている。これは、網羅的ではなく、開示された正確な形態または実施形態に限定されない。当業者には、開示された実施形態の明細書および実施を考慮することによって、修正および適合が明らかになるのであろう。さらに、開示された実施形態の態様はメモリに記憶されるものとして記載されているが、当業者はこれらの態様が二次記憶デバイス、例えば、ハードディスクまたはＣＤ ＲＯＭ、または他の形態のＲＡＭまたはＲＯＭ、ＵＳＢ媒体、ＤＶＤ、ブルーレイ、または他の光学駆動媒体などの他のタイプのコンピュータ可読媒体に記憶されてもよいことを理解するのであろう。

記載された説明および開示された方法に基づくコンピュータプログラムは、熟練した開発者の技術の範囲内である。様々なプログラムまたはプログラムモジュールは当業者に知られている技法のいずれかを使用して作成することができ、または既存のソフトウェアに関連して設計することができる。例えば、プログラム・セクションまたはプログラムモジュールは、．Ｎｅｔ Ｆｒａｍｅｗｏｒｋ、．Ｎｅｔ Ｃｏｍｐａｃｔ Ｆｒａｍｅｗｏｒｋ（およびＶｉｓｕａｌ Ｂａｓｉｃ、Ｃ などの関連言語）、Ｊａｖａ、Ｃ＋＋、Ｏｂｊｅｃｔｉｖｅ－Ｃ、ＨＴＭＬ、ＨＴＭＬ／ＡＪＡＸの組み合わせ、ＸＭＬ、またはＪａｖａアプレットを含むＨＴＭＬの中で、またはその手段によって設計することができる。

さらに、例示的な実施形態が本明細書で説明されてきたが、本開示に基づいて当業者によって理解されるように、同等の要素、修正、省略、組み合わせ（例えば、様々な実施形態にわたる態様の）、適応、および／または変更を有する任意のおよび全ての実施形態の範囲が可能である。クレームの限定はクレームに使用されている文言に広く基づいて解釈されるものとし、本明細書に記載されている例に限定されるものではなく、または出願手続中に解釈されるものとする。実施例は、非排他的であると解釈されるべきである。さらに、開示された方法のステップは、ステップを並べ替えること、および／またはステップを挿入または削除することを含む、任意の方法で修正されてもよい。したがって、本明細書および実施例は単に例示的なものとみなされ、真の範囲および精神は以下の特許請求の範囲およびそれらの均等物の全範囲によって示されることが意図される。

Claims (20)

1. 自動化されたアウトバウンドプロファイルを生成するためのコンピュータ実装システムであって、
   少なくとも１つのプロセッサと、
   少なくとも１つのデータベースと、
   命令を含むメモリと、を備え、
   前記命令は、前記少なくとも１つのプロセッサによって実行されると、
   フルフィルメントセンタ（ＦＣ）の容量を含むデータを受信することと、
   前記ＦＣへの複数の到着製品に関連付けられた複数の製品識別子を受信することと、
   前記製品識別子を使用して、前記ＦＣで前記複数の製品のトランザクショナルログを定期的に収集および格納することと、
   前記製品識別子を使用して、前記ＦＣで格納された前記複数の製品の現在の在庫を決定することと、
   機械学習アルゴリズムを使用して、前記トランザクショナルログおよび前記現在の在庫の少なくとも１つを使用して前記ＦＣのアウトバウンドプロファイルを生成することであって、前記アウトバウンドプロファイルが、複数のカテゴリの製品の出荷製品の予想されるパーセンテージを含む、ことと、
   前記ＦＣの前記生成されたアウトバウンドプロファイルを使用して、前記アウトバウンドプロファイルを前記ＦＣの実際のアウトバウンド容量と比較することによって、ネットワークアウトバウンドを管理することと、
   を含むステップを実行する、コンピュータ実装システム。
2. トランザクショナルログが、
   前記ＦＣに割り当てられた少なくとも１つの顧客注文、
   前記ＦＣに割り当てられた到着製品、
   前記製品が前記ＦＣで受け取られた時間、
   前記製品が保管された期間、
   前記製品が前記ＦＣから出荷された時間、
   前記ＦＣに入荷したブランド数、
   前記ＦＣから出荷されたトップブランド、
   前記ＦＣでの製品の入手可能性、または、
   前記ＦＣから出荷された異なるブランドの製品数のうちの少なくとも１つを含む、請求項１に記載のコンピュータ実装システム。
3. 前記ＦＣの前記アウトバウンドプロファイルは、前記ＦＣからの特定の期間中のいくつかの予想される出荷製品をさらに含む、請求項１に記載のコンピュータ実装システム。
4. 前記特定の期間は、日、月、または年のうちの少なくとも１つで測定され得る、請求項３に記載のコンピュータ実装システム。
5. 製品のカテゴリは、前記ＦＣにおける総在庫、ブランド、トップ販売者、価格帯、または出荷場所のうちの少なくとも１つを含む、請求項１に記載のコンピュータ実装システム。
6. 前記命令が、ＦＣレベル、地域レベル、および国レベルでアウトバウンドプロファイルを生成することをさらに含む、請求項１に記載のコンピュータ実装システム。
7. 前記命令が、前記トランザクショナルログに格納された情報に基づいて、前記アウトバウンドプロファイルを定期的に更新するように、前記機械学習アルゴリズムを訓練することをさらに含む、請求項１に記載のコンピュータ実装システム。
8. 前記データベースが、前記ＦＣの履歴在庫データを格納する履歴在庫データベースを含み、
   前記履歴在庫データは、少なくとも、前記ＦＣに格納された製品、前記製品が前記ＦＣから格納および出荷された時間、前記製品が前記ＦＣに格納された期間、前記製品の価格、および前記製品のブランドを識別する、請求項１に記載のコンピュータ実装システム。
9. 前記アウトバウンドプロファイルは、前記履歴在庫データを使用して、今後のイベントについて生成される、請求項８に記載のコンピュータ実装システム。
10. アウトバウンドプロファイルを生成することが、
    複数のＦＣからの複数のトランザクショナルログおよび現在の在庫をデータベースに格納することであって、前記複数のトランザクショナルログおよび現在の在庫がトランザクショナルデータを含む、ことと、
    トランザクショナルデータを訓練データセットおよび検証データセットに分割することであって、前記訓練データセットが前記検証データセットよりも多くのデータを有する、ことと、
    機械学習アルゴリズムを使用して、前記訓練データセットに基づいて予測モデルを生成することと、
    前記検証データセットを使用して前記予測モデルを検証することと、
    前記予測モデルを前記関連するトランザクショナルログおよび現在の在庫に適用することによって、前記ＦＣの前記アウトバウンドプロファイルを生成することと、
    を含む、請求項１に記載のコンピュータ実装システム。
11. 自動化されたアウトバウンドプロファイルを生成するためのコンピュータ実装方法であって、
    フルフィルメントセンタ（ＦＣ）の容量を含むデータを受信することと、
    前記ＦＣへの全ての到着製品に関連付けられた製品識別子を受信するステップと、
    前記製品識別子を使用して、前記ＦＣで全ての製品ごとにトランザクショナルログを定期的に収集および格納することと、
    前記ＦＣの履歴トランザクショナルログを検索することと、
    前記製品識別子を使用して、前記ＦＣで全ての製品の現在の在庫を決定することと、
    機械学習アルゴリズムを使用して、前記トランザクショナルログおよび前記現在の在庫のうちの少なくとも１つを使用して、前記ＦＣのアウトバウンドプロファイルを生成することと、
    を含む、コンピュータ実装方法。
12. トランザクショナルログが、
    前記ＦＣに割り当てられた少なくとも１つの顧客注文、
    前記ＦＣに割り当てられた到着製品、
    全ての製品が前記ＦＣで受け取られた時間、
    全ての製品が保管された期間、
    全ての製品が前記ＦＣから出荷された時間、
    前記ＦＣに入荷したブランド数、
    前記ＦＣから出荷されたトップブランド、
    前記ＦＣでの製品の入手可能性、および
    前記ＦＣから出荷された異なるブランドの製品数のうちの少なくとも１つを含む、請求項１１に記載のコンピュータ実装方法。
13. 前記ＦＣの前記アウトバウンドプロファイルは、前記ＦＣからの特定の期間中のいくつかの予想される出荷製品を含む、請求項１１に記載のコンピュータ実装方法。
14. 前記特定の期間は、日、月、または年のうちの少なくとも１つで測定され得る、請求項１１に記載のコンピュータ実装方法。
15. 予想される出荷製品の数が、前記ＦＣにおける総在庫、ブランド、トップ販売者、価格帯、および出荷場所のうちの少なくとも１つに基づく、請求項１３に記載のコンピュータ実装方法。
16. ＦＣレベル、地域レベル、および国レベルでアウトバウンドプロファイルを生成することをさらに含む、請求項１１に記載のコンピュータ実装方法。
17. 前記トランザクショナルログに格納された情報に基づいて、前記アウトバウンドプロファイルを定期的に更新するように前記機械学習アルゴリズムを訓練することをさらに含む、請求項１１に記載のコンピュータ実装方法。
18. 前記ＦＣの履歴在庫データを格納することをさらに含み、
    前記履歴在庫データが、少なくとも、前記ＦＣに格納された製品、前記製品が前記ＦＣから格納および出荷された時間、前記製品が前記ＦＣに格納された期間、前記製品の価格、ならびに前記製品のブランドを識別する、請求項１１に記載のコンピュータ実装方法。
19. 前記アウトバウンドプロファイルは、前記履歴在庫データを使用して、今後のイベントについて生成される、請求項１８に記載のコンピュータ実装方法。
20. 複数の自動化されたアウトバウンドプロファイルを生成するためのコンピュータ実装システムであって、
    少なくとも１つのプロセッサと、
    少なくとも１つのデータベースと、
    命令を含むメモリと、を備え、
    前記命令は、前記少なくとも１つのプロセッサによって実行されると、
    フルフィルメントセンタ（ＦＣ）の容量を含むデータを受信することと、
    前記ＦＣへの複数の到着製品に関連付けられた複数の製品識別子を受信することと、
    前記製品識別子を使用して、前記ＦＣで前記複数の製品のトランザクショナルログを定期的に収集および格納することと、
    前記製品識別子を使用して、前記ＦＣで格納された前記複数の製品の現在の在庫を決定することと、
    複数のトランザクショナルログおよび複数のＦＣからの現在の在庫をデータベースに格納することであって、前記複数のトランザクショナルログおよび現在の在庫がトランザクショナルデータを含む、ことと、
    トランザクショナルデータを訓練データセットおよび検証データセットに分割することであって、前記訓練データセットが前記検証データセットよりも多くのデータを有する、ことと、
    機械学習アルゴリズムを使用して、前記訓練データセットに基づいて予測モデルを生成することと、
    前記検証データセットを使用して、前記予測モデルを検証することと、
    前記予測モデルを前記関連するトランザクショナルログおよび現在の在庫に適用することによって、前記ＦＣの前記アウトバウンドプロファイルを生成することであって、前記アウトバウンドプロファイルが、複数のカテゴリの製品の出荷製品の予想されるパーセンテージを含む、ことと、
    前記ＦＣの前記生成されたアウトバウンドプロファイルを使用して、前記アウトバウンドプロファイルを前記ＦＣの実際のアウトバウンド容量と比較することによって、ネットワークアウトバウンドを管理することと、
    を含むステップを実行する、コンピュータ実装システム。

Images