JP7219289B2 - 運転在庫および安全在庫決定システム - Google Patents

Description

[001] 本開示は、一般に、複数のフルフィルメントセンタ（ＦＣ）の運転在庫および安全在庫を決定することによって製品をインテリジェントに分配するためのコンピュータ化されたシステムおよび方法に関する。特に、本開示の実施形態は、地域目標在庫および各ＦＣの生成されたプロファイルに基づいて、複数のＦＣにわたって製品を分配することに関連する発明的および非従来型のシステムに関する。

[002] フルフィルメントセンタ（ＦＣ）は、注文が行われるとすぐに消費者の注文を履行し、運送業者が貨物を受け取ることができるように作業するため、毎日数百万を超える製品に遭遇する。ＦＣ内の在庫を管理するための作業は、売り手からの商品の受け取り、簡単にピッキングアクセスするための受け取った商品の収納、アイテムの梱包、注文の確認、および小包の配達を含むことができる。現在、既存のＦＣおよびＦＣの在庫管理システムは、大量の入荷および出庫商品を処理するように構成されているが、注文が複数のＦＣに適切に分散されていないため、ＦＣが処理できる以上の注文を受け取ると一般的な問題が発生する。例えば、ＦＣに関連する小売業者は、ピークシーズンに供給業者に大量の製品を注文する場合があるが、ＦＣには、注文した製品をタイムリーに受け取るための十分なリソースがない。これにより、受け取りプロセスが遅くなり、ＦＣで大量のバックログの問題が発生し、最終的に問題が悪化する可能性がある。バックログの問題は、小売業者が製品を流通させて利益を上げるのを妨げるため、売上の損失につながる可能性がある。

[003] このような問題を軽減するために、従来の在庫管理システムは、予測データのみに依存して、複数のＦＣへの製品の流通を決定する。これらのシステムには、特定の製品のインバウンド容量やアウトバウンド容量など、各ＦＣの個々の能力が考慮されていないという技術的な問題がある。これらの要因を考慮しないと、これらのシステムはＦＣ間で製品の分散を生成する可能性があり、特定のＦＣには、特定の製品の需要を満たすのに十分な在庫、インバウンド容量、またはアウトバウンド容量がない場合がある。これにより、売上が減少する可能性もある。

[004] したがって、各ＦＣの別個の能力および特性にさらに基づく、複数のＦＣに製品をインテリジェントに分配するための改善された方法およびシステムが必要である。

[005] 本開示の一態様は、製品のインテリジェントな分配のためのコンピュータ実装システムに関する。システムは、命令を格納するメモリと、命令を実行するように構成された少なくとも１つのプロセッサと、を含むことができ、命令により、在庫管理単位（ＳＫＵ）の予想需要を含む予測データを受信し、受信した予測データに基づいて、予想需要を満たすためのＳＫＵの目標在庫を決定し、目標在庫は、ＳＫＵの運転在庫と、ＳＫＵの安全在庫と、を含み、ＳＫＵの目標在庫に基づいて、複数のフルフィルメントセンタを含む地域のＳＫＵの地域目標在庫を決定し、地域目標在庫は、ＳＫＵの地域運転在庫と、ＳＫＵの地域安全在庫と、を含み、複数のフルフィルメントセンタ内のフルフィルメントセンタのインバウンドおよびアウトバウンド出荷履歴を含む履歴データを受信し、受信したデータに基づいて、フルフィルメントセンタのプロファイルを生成し、プロファイルは、インバウンド容量と、アウトバウンド容量と、ＳＫＵの経常在庫と、を含み、フルフィルメントセンタのプロファイルに基づいて、地域目標在庫の一部をフルフィルメントセンタに割り当て、一部に基づいてフルフィルメントセンタにいくつかのＳＫＵをストックするように別のデバイスに命令を送信する。

[006] 本開示の別の態様は、製品のインテリジェントな分配のためのコンピュータ実施方法に関する。本方法は、在庫管理単位（ＳＫＵ）の予想需要を含む予測データを受信することと、受信した予測データに基づいて、予想需要を満たすためのＳＫＵの目標在庫を決定し、目標在庫は、ＳＫＵの運転在庫と、ＳＫＵの安全在庫と、を含むことと、ＳＫＵの目標在庫に基づいて、複数のフルフィルメントセンタを含む地域のＳＫＵの地域目標在庫を決定し、地域目標在庫は、ＳＫＵの地域運転在庫と、ＳＫＵの地域安全在庫と、を含むことと、複数のフルフィルメントセンタ内のフルフィルメントセンタのインバウンドおよびアウトバウンド出荷履歴を含む履歴データを受信することと、受信したデータに基づいて、複数のフルフィルメントセンタにおけるフルフィルメントセンタのプロファイルを生成し、プロファイルは、インバウンド容量と、アウトバウンド容量と、ＳＫＵの経常在庫と、を含むことと、フルフィルメントセンタのプロファイルに基づいて、地域目標在庫の一部をフルフィルメントセンタに割り当てることと、一部に基づいてフルフィルメントセンタにいくつかのＳＫＵをストックするように命令を送信することと、を含むことができる。

[007] 本開示のさらに別の態様は、製品のインテリジェントな分配のためのコンピュータ実装システムに関し、システムは、命令を格納するメモリと、命令を実行するように構成された少なくとも１つのプロセッサと、を含むことができ、命令により、在庫管理単位（ＳＫＵ）の予想需要を含む予測データを受信し、受信した予測データに基づいて、予想需要を満たすためのＳＫＵの目標在庫を決定し、目標在庫は、ＳＫＵの運転在庫と、ＳＫＵの安全在庫と、を含み、ＳＫＵの目標在庫に基づいて、複数のフルフィルメントセンタを含む地域のＳＫＵの地域目標在庫を決定し、地域目標在庫は、ＳＫＵの地域運転在庫と、ＳＫＵの地域安全在庫と、を含み、複数のフルフィルメントセンタ内のフルフィルメントセンタのインバウンドおよびアウトバウンド出荷履歴を含む履歴データを受信し、受信したデータに基づいて、フルフィルメントセンタのプロファイルを生成し、プロファイルは、インバウンド容量と、アウトバウンド容量と、ＳＫＵの経常在庫と、を含み、フルフィルメントセンタのプロファイルに基づいて、地域目標在庫の一部をフルフィルメントセンタに割り当て、ＳＫＵの経常在庫と一部に基づいて、ＳＫＵの経常在庫が割り当てられた部分を満たしているかどうかを判定し、経常在庫が割り当てられた部分を満たしていないとの判定に基づいて、ＳＫＵの経常在庫が割り当てられた部分を満たすまで、フルフィルメントセンタでＳＫＵのインバウンドフローおよびアウトバウンドフローの一方または両方を修正または維持するように別のデバイスに命令を送信する。

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

[009] 図１Ａは、開示された実施形態と一致する、出荷、輸送、および物流作業を可能にする通信のためのコンピュータ化されたシステムを含むネットワークの例示的な実施形態を示す概略ブロック図である。 [0010] 図１Ｂは、開示された実施形態と一致する、対話型ユーザインターフェース要素と共に検索要求を満たす１つまたは複数の検索結果を含むサンプル検索結果ページ（ＳＲＰ）を示す図である。 [0011] 図１Ｃは、開示された実施形態と一致する、対話型ユーザインターフェース要素と共に製品および製品に関する情報を含むサンプル単一表示ページ（ＳＤＰ）を示す図である。 [0012] 図１Ｄは、開示された実施形態に一致する、対話型ユーザインターフェース要素と共に仮想ショッピングカート内のアイテムを含むサンプルカートページを示す図である。 [0013] 図１Ｅは、開示された実施形態と一致する、対話型ユーザインターフェース要素と共に、購入および出荷に関する情報と共に仮想ショッピングカートからのアイテムを含むサンプル注文ページを示す図である。 [0014] 図２は、開示された実施形態と一致する、開示されたコンピュータ化されたシステムを利用するように構成された例示的なフルフィルメントセンタの概略図である。 [0015] 図３は、開示された実施形態と一致する、製品のインテリジェントな分配のためのコンピュータ実装システムを含むネットワーク化された環境の例示的な実施形態を示す概略ブロック図である。 [0016] 図４は、開示された実施形態と一致する、複数のフルフィルメントセンタ（ＦＣ）の運転在庫および安全在庫を決定することによって製品をインテリジェントに分配するための例示的なコンピュータ化されたプロセスのフローチャートである。 [0017] 図５は、開示された実施形態と一致する、ＦＣで経常在庫製品を監視および管理する方法を決定するための例示的なコンピュータ化されたプロセスのフローチャートである。

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

[0019] 本開示の実施形態は、複数のフルフィルメントセンタ（ＦＣ）の運転在庫および安全在庫を決定することによって製品をインテリジェントに分配するように構成されたコンピュータ化されたシステムおよび方法に関する。

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

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

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

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

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

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

[0026] 次いで、ユーザデバイスは、例えば、ユーザインターフェースをクリックまたはタップすることによって、または別のインプットデバイスを使用して、ＳＲＰから製品を選択して、ＳＲＰ上に表される製品を選択し得る。ユーザデバイスは、選択されたプロダクトに関するリクエストを作成し、それを外部フロントエンドシステム１０３に送ることができる。これに応じて、外部フロントエンドシステム１０３は、選択された商品に関する情報をリクエストすることができる。例えば、情報は、それぞれのＳＲＰ上の製品について提示される情報を超える追加の情報を含むことができる。これには、例えば、貯蔵寿命、原産国、体重、大きさ、荷物中のアイテムの個数、取扱説明書、または生成物に関する他の事項が含まれ得る。また、情報は、（例えば、この製品および少なくとも１つの他の製品を購入した顧客のビッグデータおよび／または機械学習分析に基づく）類似の製品に対する推奨、頻繁に質問される質問に対する回答、顧客からのレビュー、製造業者情報、写真などを含むことができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0059] ユーザが注文を置くと、ピッカーは、保管ユニット２１０から１つまたは複数のアイテム２０８を取り出すための命令をデバイス１１９Ｂ上で受け取ることができる。ピッカーは、アイテム２０８を取り出し、アイテム２０８上のバーコードを走査し、それを搬送メカニズム２１４上に置くことができる。搬送機構２１４は、スライドとして表されているが、いくつかの実施形態では、搬送機構がコンベヤーベルト、エレベータ、カート、フォークリフト、ハンドトラック、台車、カートなどのうちの１つまたは複数として実施することができる。次いで、アイテム２０８は、充填領域２１１に到達することができる。

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

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

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

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

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

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

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

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

[0068] いくつかの実施形態では、ＳＣＭ３２０は、データサイエンスモジュール３２１、ＦＣプロファイルジェネレータ３２２、需要予測ジェネレータ３２３、目標在庫計画システム（ＴＩＰ）３２４、インバウンド優先順位付けおよびシャッフリングシステム（ＩＰＳ）３２５、手動注文提出プラットフォーム３２６、購入注文（ＰＯ）ジェネレータ３２７、ならびにレポートジェネレータ３２８を含む。

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

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

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

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

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

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

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

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

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

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

[0079] ここで、Ｑ_ｐは特定の製品の予備注文数量であり、Ｑ_ｆｎは計算時からｎ日目の製品の需要予測数量であり、Ｑ_ｃは製品の経常在庫レベルであり、Ｑ_ｏは現在注文されている数量であり、Ｐ_ｃはカバレッジ期間であり、Ｐ_ｓは安全在庫期間であり、Ｃはケース数量である。

[0080] 本明細書で使用される場合、カバレッジ期間は、１つのＰＯがカバーするように計画されている時間の長さ（例えば、日数）を指すことができ、安全在庫期間は、需要の突然の増加や配達の遅延などの予期しないイベントが発生した場合にＰＯがカバーする必要のある追加の期間（例えば、追加の日数）を指すことができる。例えば、次の製品Ｘのサンプル需要予測数量の表を考えると、Ｄ－日で生成されたＰＯのカバレッジ期間は５、安全在庫期間は１であってもよく、この場合、

は３７＋３７＋３５＋４０＋４１＋３４＝２２４に等しくなる。

[0081] この数量、すなわち製品Ｘの２２４ユニットから、ＴＩＰ３２４は、経常在庫レベル（例えば、６０ユニット）と現在注文されている数量（例えば、４０）を差し引くことができ、これは１２４ユニットになる。次に、この数は、ケース数量で除算し、整数に切り上げて、ケース数量を再度乗算することにより、ケース数量で割って丸めることにより、ケース数量の倍数（つまり、ボックスまたはパレット内のユニットの数など、製品がパッケージ化されるユニットの数）に切り上げることができ、この例では、一例としてケース数量を１０とすると、１３０ユニットになる。

[0082] いくつかの実施形態では、カバレッジ期間は、対応する供給業者がＰＯ生成の日から製品を配達するのにかかると予想される時間以上の所定の時間であってもよい。追加的または代替的に、ＴＩＰ３２４はまた、曜日、予想される遅延などの他の要因に基づいてカバレッジ期間を調整することができる。さらに、安全在庫期間は、安全対策として予備注文数量を増やすように設計された別の所定の期間であってもよい。安全在庫期間は、需要の急増や予期せぬ出荷遅延などの予期せぬ事態が発生した場合に、在庫切れのリスクを軽減することができる。いくつかの実施形態では、ＴＩＰ３２４は、カバレッジ期間に基づいて安全在庫期間を設定することができ、例えば、カバレッジ期間が１～３日の場合は０日の安全在庫期間が追加され、カバレッジ期間が４～６日の場合は１日が追加され、カバレッジ期間が７日を超える場合は３日が追加される。

[0083] 上記の予備注文数量を決定する複雑なプロセスにもかかわらず、予備注文数量は主に顧客の需要に基づいており、実際の制約を考慮していない場合がある。したがって、製品の在庫を最適化するために、このような制約を考慮するための手順が望まれる。いくつかの実施形態では、ＴＩＰ３２４は、販売統計、現在の製品在庫レベル、および現在注文された数量などのデータに基づいて予備注文数量を微調整するように構成された一連の規則を使用して、予備注文数量を調整することができる。

[0084] 得られた数量、すなわち推奨注文数量は、ＰＯジェネレータ３２７に送信することができる。他の実施形態では、得られた数量は、ＩＰＳ３２５によってさらに処理されて、図４に関して以下に説明するように、特定の製品に優先順位を付け、および／または数量を１つもしくは複数のＦＣに分配することができる。

[0085] さらに、一部の実施形態では、ＩＰＳ３２５は、各製品のポピュラリティを決定し、決定されたポピュラリティに基づいて注文数量に優先順位を付け、優先順位付けされた注文数量を１つまたは複数のＦＣ２００に分配するように構成された１つまたは複数のコンピューティングデバイスを含むことができる。製品のポピュラリティを決定し、優先順位を付け、そして分配するためのプロセスは、図４に関してより詳細に以下に説明される。

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

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

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

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

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

[0091] 図４は、複数のＦＣ（例えば、ＦＣ２００）の運転在庫および安全在庫を決定することによって製品をインテリジェントに分配するための例示的なコンピュータ化されたプロセス４００のフローチャートである。好ましい実施形態では、プロセス４００は、ＴＩＰ３２４およびＩＰＳ３２５などのＳＣＭ３２０の１つまたは複数の構成要素によって実行され得る。したがって、例として、プロセス４００は、ＴＩＰ３２４およびＩＰＳ３２５によって実行されるものとして説明される。しかしながら、プロセス４００またはその一部は、ネットワーク環境３００全体によって、またはプロセスの少なくとも一部を実行することができる環境３００の任意の構成要素（例えば、１つまたは複数のプロセッサ、ＦＣプロファイルジェネレータ３２２、需要予測ジェネレータ３２３など）によって実行され得る。

[0092] プロセス４００はステップ４０１から始まる。ステップ４０１において、ＴＩＰシステムは、例えば、在庫管理単位（ＳＫＵ）の予想需要を含む予測データを受信することができる。予測データは、データサイエンスモジュール３２１によって開発された予測モデルを使用して、予測ジェネレータ３２２によって生成された特定のＳＫＵの予測需要数量であってもよい。需要数量はまた、標準偏差、最大値、最小値、平均値などのパラメータを含むことができる。

[0093] ステップ４０１が完了した後に、プロセス４００はステップ４０２に進むことができる。ステップ４０２で、ＴＩＰ３２４は、例えば、受信した予測データに基づいて、ＳＫＵの目標在庫を決定することができる。目標在庫は、いくつかの実施形態では、ＩＴＩＰ３２４によって計算されたＳＫＵの数量であってもよく、予測ジェネレータ３２２によって生成された予測需要数量に等しいＳＫＵの数量、ならびにＳＫＵの実際の需要が予想需要を上回る状況をカバーするために計算された追加の数量を含むことができる。例えば、目標在庫はＳＫＵの運転在庫を含んでもよい。ＳＫＵの運転在庫は、実質的な確実性で需要を満たすことが期待される、または満たされる可能性が高いＳＫＵの数量であってもよい。例えば、運転在庫は、時間のかなりの部分（例えば、８０％、９０％、または９５％）の需要を満たすＳＫＵの量であり得る。確実性の程度は柔軟であり、いくつかの理由に基づいて決定することができる。運転在庫は、予測ジェネレータ３２２から受信したデータに基づくことができ、さらに、標準偏差、最大値、最小値、または平均値などのパラメータに基づくことができる。

[0094] しかし、多くの場合、運転在庫はＳＫＵの実際の需要を満たすのに十分でない場合がある。これらの状況で顧客の需要が確実に満たされるようにするために、いくつかの実施形態では、目標在庫は、運転在庫に加えて、最小量の過剰在庫または安全在庫も含むことができる。安全在庫は、基本的なサプライチェーンモデルに基づいて設定することができる。例えば、計算された安全在庫は、在庫切れ（ＯＯＳ）とＳＫＵの過剰在庫のリスクのバランスを十分にとる特定の在庫レベルを設定するために使用される重要な比率に基づくことができる。ＯＯＳは売上の損失により収益の損失をもたらす可能性があるが、過剰在庫はまた、過剰在庫のＳＫＵに費やされた追加資本および保管費用のために収益の損失をもたらす可能性がある。したがって、好ましい実施形態では、ＴＩＰ３２４は、ＯＯＳおよび過剰在庫のリスクを可能な限り低減するために、安全在庫を計算することができる。

[0095] ステップ４０２が完了した後に、プロセス４００は次にステップ４０３に進むことができる。ステップ４０３において、ＴＩＰ３２４は、例えば、ＳＫＵの目標在庫に基づいて、複数のフルフィルメントセンター（例えば、ＦＣ２００）を含む地域のＳＫＵの地域目標在庫を決定することができる。前述の目標在庫の運転在庫と安全在庫と同様に、地域目標在庫は、ＳＫＵの地域運転在庫と地域安全在庫も含むことができる。いくつかの実施形態では、地域運転在庫および地域安全在庫を含む地域目標在庫は、以前に決定された目標在庫、運転在庫、および／または安全在庫に、地域に対応する国内および／または世界の顧客人口の一部を掛けることによって決定され得る。例えば、国内の顧客人口の半分を含む地域は、国内の目標在庫の半分である地域目標在庫を有してもよい。他の実施形態では、地域目標在庫、地域運転在庫、および地域安全在庫は、他の地域と比較した地域内の１つまたは複数のＳＫＵの過去のまたは可能性のある需要を表す統計など、地域に固有のパラメータに基づいて決定することができる。

[0096] ステップ４０３が完了した後に、プロセス４００は次にステップ４０４に進むことができる。ステップ４０４で、ＴＩＰ３２４は、例えば、複数のフルフィルメントセンタ内のフルフィルメントセンタのインバウンドおよびアウトバウンド出荷履歴を含む履歴データを受信することができる。インバウンド出荷履歴は、ＦＣが指定された期間または履歴全体を通じて受け取った１つまたは複数のＳＫＵの数量を含むことができる。同様に、アウトバウンド出荷履歴は、ＦＣが指定された期間または履歴全体を通じて出荷した１つまたは複数のＳＫＵの数量を含むことができる。いくつかの実施形態では、受信した履歴データは、いくつかの実施形態では、ＳＫＵの平均インバウンドおよびアウトバウンドボリューム、ＳＫＵのインバウンドおよびアウトバウンドボリュームの標準偏差または分散、サードパーティ販売業者の識別子、および／またはＳＫＵの供給業者、ＳＫＵの配送場所などの他の雑多な出荷データも含むことができる。

[0097] ステップ４０４が完了した後に、プロセス４００は、ステップ４０５に続くことができる。ステップ４０５で、ＴＩＰ３２４は、例えば、受信した履歴データに基づいて、ＦＣのプロファイルを生成することができる。生成されたＦＣプロファイルは、ＦＣのインバウンド容量、ＦＣのアウトバウンド容量、ＦＣにおける１つまたは複数のＳＫＵの経常在庫、ＦＣに出荷されるＳＫＵの現在の注文のリスト、ＦＣから出荷される現在の注文のリストなどの、ＦＣのデータおよび／または特性を含むことができる。好ましい実施形態では、ＦＣプロファイルは、所望の在庫レベル、インバウンド入荷および／またはアウトバウンド出荷の量、ＦＣの個々の運転在庫および／または安全在庫などを決定するのに有用であり得る、上記の情報を含むが、これらに限定されない任意の情報を含む。一般に、プロファイルは、特定のＦＣの履歴、能力、および／または特性に関連する情報を含むことができる。

[0098] 上記のパラメータに基づいて、ＴＩＰ３２４は、生成されたプロファイルに含めるために、１週間などの指定された期間の最終在庫目標を計算することができる。したがって、プロファイルの生成は、毎週などの定期的に発生するステップであってもよいし、あるいは受信した履歴データの変更に基づいて生成されたプロファイルを継続的に更新および維持することを含んでもよい。例えば、ＴＩＰ３２４は、式（２）を使用して最終在庫目標を決定することができる。
Ｉ_ｅｎｄ＝Ｉ_０＋Ｑ_ｉｎ-Ｑ_ｏｕｔ （２）
ここで、Ｉ_ｅｎｄは最終在庫目標であり、Ｉ_０は指定された期間の開始時の初期在庫であり、Ｑ_ｉｎはＦＣのＳＫＵの予測インバウンド数量であり、Ｑ_ｏｕｔはＦＣのＳＫＵの予測アウトバウンド数量である。いくつかの実施形態では、プロファイルはまた、特定のＦＣの在庫蓄積目標を表す値を表すことができる。在庫蓄積は、特定のＦＣのアウトバウンド需要数量とは関係なく、それに加えて、追加の在庫割り当てになり得る。この追加の在庫蓄積数量は、ピーク日や供給のギャップ（例えば、供給業者の休日）、顧客への配送を開始する前の新しいＦＣの在庫の蓄積、その他の特別なシナリオなど、特定の状況を説明するために使用され得る。追加の在庫割り当てにこの数量を含めることにより、供給業者からの配送数を減らし、ＦＣの在庫管理を最適化することができる。

[0099] 在庫蓄積目標は、少なくとも受信した履歴データまたは上記で定義したパラメータに基づいて計算することができる。例えば、国内のアウトバウンド予測に基づいて、ＴＩＰ３２４は、国内のインバウンド予測を取得することができる。国内レベルの予測に基づいて、ＴＩＰ３２４はＦＣのインバウンドおよびアウトバウンドの予測も決定することができる。ＦＣのインバウンド予測は、そのＦＣからの予測需要をサポートするために必要な追加の在庫を、ＦＣで計画されている経常在庫蓄積に追加することによって決定することができる。計画された在庫蓄積は、ＦＣのインバウンド容量にも依存する場合がある。

[00100] ステップ４０５が完了した後に、プロセス４００は次にステップ４０６に進むことができる。ステップ４０６において、ＩＰＳ３２５は、例えば、フルフィルメントセンタのプロファイルに基づいて、地域目標在庫の一部をフルフィルメントセンタに割り当てることができる。地域目標在庫の一部を割り当てることは、すべての地域目標在庫が少なくとも１つのＦＣに割り当てられるように、地域目標在庫の特定の数量またはパーセンテージを複数のＦＣ内の各ＦＣに割り当てることを含むことができる。地域目標在庫の一部を特定のものに割り当てることは、ＦＣが、ＦＣのそれぞれの割り当てられた部分に対応する経常在庫を維持するかまたは維持することを目的としなければならないことを示すことができる。ＩＰＳ３２５は、地域目標在庫の一部を週に１回など定期的に割り当てることができ、または受信した予測データの変更、目標在庫および／または地域目標在庫の変更、フルフィルメントセンタのプロファイルの変更などに基づいて割り当てられた部分を継続的に更新することができる。

[00101] いくつかの実施形態では、地域目標在庫の一部を割り当てることは、ＳＫＵが複数のＦＣにあるべきであるという決定にさらに基づくことができる。例えば、ＩＰＳ３２５は、複数のＦＣのうちの１つのＦＣが、特定の地域のすべての地域目標在庫を維持するためのインバウンド容量および／またはアウトバウンド容量を有さないと判定することができる。いくつかの実施形態では、この判定は、その地域におけるＳＫＵのポピュラリティに基づくことができる。例えば、１つのＦＣには、地域全体の運転在庫を維持する容量はあるが、地域目標在庫全体を維持するために必要な安全在庫を維持する容量はない。この例では、ＦＣのインバウンド容量またはアウトバウンド容量が不足しているのは、ＳＫＵのポピュラリティが高すぎてＦＣが地域の需要を満たすことができないことの結果であり得る。同様の例では、ＦＣには、運転在庫または安全在庫の一部を維持する容量しかない。例えば、１つのＦＣがＳＫＵの必要な地域目標在庫を維持できないことに基づいて、ＩＰＳ３２５は、ＳＫＵが地域内の複数のＦＣにあるべきであると判断し、それに応じて目標在庫の一部を個別のＦＣに割り当てることができる。

[00102] いくつかの実施形態では、地域目標在庫の一部を割り当てることは、さらに、複数のフルフィルメントセンタ内の各フルフィルメントセンタに対して生成されたプロファイルの集合に基づくことができる。これは、上記の例のように、どれだけの数のＳＫＵを地域内の各ＦＣに割り当てるべきかを最も効率的に決定するために、ＩＰＳ３２５が各ＦＣのインバウンド容量、アウトバウンド容量、経常在庫、およびその他の特性を追加で考慮しなければならない場合など、多くの状況で必要になり得る。生成されたプロファイルの総計に基づく部分割り当ては、例えば、上記の要因の１つまたは複数を使用して、一連のルール、アルゴリズムなどを通じて、各ＦＣの地域目標在庫の最適化された部分を決定することを含むことができる。いくつかの実施形態では、ＩＰＳ３２５は、上記の方法の１つまたは複数を利用して、地域目標在庫に対する各ＦＣのＳＫＵの比率を決定し、各ＦＣの決定された比率に基づいて地域目標在庫の一部を各ＦＣに割り当てることができる。上記の最適化された部分または比率は、定期的に決定されるか、または継続的に更新され得る。

[00103] いくつかの実施形態では、ＩＰＳ３２５は、ＳＫＵの現在のアウトバウンド注文の記録を参照するようにさらに構成されてもよく、地域目標在庫の一部の割り当ては、ＳＫＵの経常在庫およびＳＫＵの現在のアウトバウンド注文にさらに基づく。アウトバウンド注文の記録は、地域内の各ＦＣに関連するアウトバウンド注文の数量、または地域内の各ＦＣの集計を含むことができる。予想される地域需要と同様に、現在のアウトバウンド注文の記録を利用して、地域目標在庫、地域運転在庫、または地域安全在庫を決定することができる。しかし、いくつかの実施形態では、アウトバウンド注文は、複数のＦＣ内の特定のＦＣにのみ関連付けられるか、または以前に割り当てられ得る。これは、例えば、特定のＦＣがＳＫＵの特定の注文を履行できる地域内の唯一のＦＣまたは数少ないＦＣの１つである場合（例えば、１つのＦＣのみが地域内の特定の場所または住所に配送する場合）に当てはまる。

[00104] いくつかの実施形態では、地域目標在庫の一部を割り当てることは、各ＦＣでの各ＳＫＵの予測されるアウトバウンド需要をサポートするための推奨注文数量（ＲＯＱ_ｏｕｔ）を決定することを含むことができる。例えば、ＴＩＰ３２４は、式（３）を使用してＲＯＱを計算することができる。
ＲＯＱ_ｏｕｔ＝Ｑ_ｏｕｔ－Ｉ_０－Ｑ_{ｏｒｄｅｒｅｄ} （４）
ここで、Ｑ_ｏｕｔはＦＣでのＳＫＵのアウトバウンド予測であり、Ｉ_０はＦＣでのＳＫＵの既存の在庫であり、Ｑ_{ｏｒｄｅｒｅｄ}はＦＣにマッピングされたＳＫＵの既存の未処理注文の数量である。各ＦＣについて計算された推奨注文数量に基づいて、ＩＰＳ３２５は、国内の推奨注文数量からマッピングされた各ＦＣに推奨注文数量を割り当てることができる。

[00105] この割り当て後に国内の推奨注文数量のいずれかが残っている場合には、ＩＰＳ３２４は、各ＦＣの計算された在庫蓄積要件に基づいて、各ＦＣにさらに多くのＳＫＵを割り当てることもできる。各ＦＣは、必要な在庫蓄積をサポートするために、追加の推奨注文数量（ＲＯＱ_{ｂｕｉｌｄｕｐ}）を有することができる。この推奨注文数量は、例えば、式（２）から計算された最終在庫目標（Ｉ_ｅｎｄ）と、例えばＦＣの予想需要数量との差であってもよい。各ＦＣに基づいて、ＩＰＳ３２５は、残りの国内推奨注文数量からマッピングされた各ＦＣに、必要な在庫蓄積の推奨注文数量を割り当てることができる。必要な在庫蓄積に基づいて各ＦＣにＳＫＵを割り当てた後に、国内の推奨注文数量のいずれかが残っている場合には、残りの国内推奨は、アウトバウンド需要への各ＦＣの寄与に比例して、安全在庫として各ＦＣに分配される。

[00106] ステップ４０６が完了した後に、プロセス４００は、ステップ４０７に続くことができる。ステップ４０７で、ＩＰＳ３２５は、例えば、割り当てられた部分に基づいて、ＦＣにいくつかのＳＫＵをストックするようにデバイスに命令を送信することができる。好ましい実施形態では、ＳＫＵにストックされるＳＫＵの数は、ＳＫＵの地域目標在庫の割り当てられた部分に実質的に対応するか、または等しくなる。デバイスは、システム１００において以前に開示したデバイスのいずれか１つまたは複数であってもよい。いくつかの実施形態では、デバイスは、手動注文提出プラットフォーム３２６または購入注文ジェネレータ３２７の機能を実行することができる。例えば、いくつかの実施形態では、命令を手動注文提出プラットフォーム３２６に送信することができ、ユーザが手動注文を入力するときに命令を参照することができる。他の実施形態では、命令を購入注文ジェネレータ３２７に送信することができ、そこで地域目標在庫の割り当てられた部分に基づいてフルフィルメントセンタに出荷するために、ＳＫＵに関連する供給業者への購入注文を生成するためにその命令が使用され得る。購入注文ジェネレータ３２７、または命令が送信される別のデバイスは、これらの命令を実行して購入注文を自動的に提出するか、またはレビューおよび手動提出のために購入注文を提示することができる。

[00107] 本開示と一致して、送信された命令は、ＳＫＵの地域目標在庫の割り当てられた部分と等しいままであるように、ＳＫＵの経常在庫を維持する命令であってもよいし、またはＳＫＵの地域目標在庫の割り当てられた部分と等しくなるように、ＳＫＵの経常在庫を調整する命令であってもよい。いくつかの実施形態では、経常在庫を維持することは、ＳＫＵのアウトバウンド数量と等しいままであるように、ＳＫＵのインバウンド数量を維持することを含んでもよいし、またはＳＫＵのアウトバウンド数量と等しくなるように、ＳＫＵのインバウンド数量を修正することを含んでもよい。さらに、経常在庫を調整することは、経常在庫がＳＫＵの地域目標在庫の割り当てられた部分に近づくように、フルフィルメントセンタのＳＫＵのインバウンドを修正または維持することを含んでもよい。

[00108] 上記の実施形態は、図５を参照して例として説明することができ、それは、どの命令が送信されるかを決定するために使用され得る例示的なプロセスおよび／または論理５００のフローチャートを提示する。このプロセスは、例えば、ＩＰＳ３２５の１つまたは複数のプロセッサによって実行され得る。プロセス５００は、ＩＰＳ３２５が地域目標在庫の一部を割り当てた後に、ステップ５０１で開始することができる。次に、１つまたは複数のプロセッサは、ステップ５０２で、ＦＣでのＳＫＵの経常在庫が、地域目標在庫の割り当てられた部分に等しいかどうかを判定することができる。経常在庫が地域目標在庫と「等しい」かどうかのこの判定は、いくつかの実施形態では、経常在庫の正確な数量または絶対値が地域目標在庫の正確な数量または絶対値と一致することに基づくことができる。経常在庫が割り当てられた部分と等しい場合には、１つまたは複数のプロセッサは、ステップ５０３で、ＦＣでＳＫＵの経常在庫を維持するための命令を送信する。１つまたは複数のプロセッサはさらに、ＦＣでのＳＫＵの現在のインバウンド数量が、ステップ５０５で、ＦＣでのＳＫＵのアウトバウンド数量に等しいかどうかを判定することができる。そうである場合には、１つまたは複数のプロセッサは、経常在庫が同じままであるように、ステップ５０６でインバウンド数量を維持するようにデバイスに命令を送信することができる。そうでなければ、１つまたは複数のプロセッサは、ステップ５０７でアウトバウンド数量と等しくなるようにインバウンド数量を変更するための命令を送信することができる。

[00109] あるいは、ステップ５０２で、１つまたは複数のプロセッサは、経常在庫が地域目標在庫の割り当てられた部分と等しくないと判定することができる。この場合、ＯＯＳまたは過剰在庫を防ぐために、１つまたは複数のプロセッサは、ステップ５０４で、ＦＣでのＳＫＵのインバウンド数量を変更するようにデバイスに命令を送信することができる。例えば、経常在庫が割り当てられた部分よりも少ないと判定された場合、送信される命令は、ＳＫＵのインバウンド数量を変更して、インバウンド数量がアウトバウンド数量よりも大きくなるようにすることができる。対照的に、ＳＫＵの経常在庫が割り当てられた部分よりも多い場合には、インバウンド数量がアウトバウンド数量よりも少なくなるようにインバウンド数量を変更するように命令され得る。プロセスはステップ５０２に戻ることができ、経常在庫は、割り当てられた部分と等しくなるまで調整され続けることができる。さらに、このプロセスはステップの順序として説明されているが、１つまたは複数のプロセッサは、上記の決定を継続的に行うことによって（例えば、ステップ５０２およびステップ５０５で）経常在庫レベルを継続的に評価および変更するように構成され得る。

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

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

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

Claims (20)

1. 製品のインテリジェントな分配のためのコンピュータ実装システムであって、前記システムは、
   命令を格納するメモリと、
   前記命令を実行するように構成された少なくとも１つのプロセッサと、を含み、前記命令により、在庫管理単位（ＳＫＵ）の予想需要を含む予測データを受信し、
   前記受信した予測データに基づいて、前記予想需要を満たすための前記ＳＫＵの目標在庫を決定し、前記目標在庫は、
   前記ＳＫＵの運転在庫と、
   前記ＳＫＵの安全在庫と、を含み、
   前記ＳＫＵの前記目標在庫に基づいて、複数のフルフィルメントセンタを含む地域の前記ＳＫＵの地域目標在庫を決定し、前記地域目標在庫は、
   前記ＳＫＵの地域運転在庫と、
   前記ＳＫＵの地域安全在庫と、を含み、
   前記複数のフルフィルメントセンタ内の各フルフィルメントセンタのインバウンドおよびアウトバウンド出荷履歴を含む履歴データを受信し、
   前記受信した履歴データに基づいて、各フルフィルメントセンタの能力を決定するように構成されたデータモデルを生成し、
   前記受信した履歴データで前記データモデルを訓練し、
   前記訓練したデータモデルを用いて、各フルフィルメントセンタのプロファイルを生成し、前記プロファイルは、
   インバウンド容量と、
   アウトバウンド容量と、
   前記ＳＫＵの経常在庫と、を含み、
   各フルフィルメントセンタの前記プロファイルに基づいて、前記地域目標在庫の一部を各フルフィルメントセンタに割り当て、
   前記一部に基づいて各フルフィルメントセンタにいくつかのＳＫＵをストックするようにデバイスに命令を送信する、
   システム。
2. 前記地域目標在庫の一部を割り当てることは、ＳＫＵが複数のフルフィルメントセンタにあるべきであるという決定にさらに基づく、請求項１に記載のシステム。
3. ＳＫＵが複数のフルフィルメントセンタにあるべきであるという前記決定は、前記地域における前記ＳＫＵのポピュラリティに基づく、請求項２に記載のシステム。
4. 前記地域目標在庫の一部を割り当てることは、前記複数のフルフィルメントセンタ内の各フルフィルメントセンタに対して生成されたプロファイルの集合にさらに基づく、請求項１に記載のシステム。
5. 前記少なくとも１つのプロセッサは、前記ＳＫＵの現在のアウトバウンド注文の記録を参照するようにさらに構成され、前記地域目標在庫の一部を割り当てることは、前記ＳＫＵの前記経常在庫および前記ＳＫＵの前記現在のアウトバウンド注文にさらに基づく、請求項１に記載のシステム。
6. 前記運転在庫は、前記予想需要を満たすように決定された前記ＳＫＵの量であり、前記安全在庫は、前記予想需要の超過を満たすように決定された前記ＳＫＵの追加量である、請求項１に記載のシステム。
7. 前記送信された命令は、
   前記ＳＫＵの前記地域目標在庫の前記割り当てられた部分と等しいままであるように、前記ＳＫＵの前記経常在庫を維持する命令、または
   前記ＳＫＵの前記地域目標在庫の前記割り当てられた部分と等しくなるように、前記ＳＫＵの前記経常在庫を調整する命令、
   のうちの一方を含む、請求項１に記載のシステム。
8. 前記経常在庫を維持することは、
   前記ＳＫＵのアウトバウンド数量と等しいままであるように、前記ＳＫＵのインバウンド数量を維持すること、または
   前記ＳＫＵのアウトバウンド数量と等しくなるように、前記ＳＫＵのインバウンド数量を修正すること、
   のうちの一方を含む、請求項７に記載のシステム。
9. 前記経常在庫を調整することは、前記経常在庫が前記ＳＫＵの前記地域目標在庫の前記割り当てられた部分に近づくように、前記フルフィルメントセンタの前記ＳＫＵのインバウンドを修正または維持することを含む、請求項７に記載のシステム。
10. 前記送信された命令は、前記地域目標在庫の前記割り当てられた部分に基づいて、各フルフィルメントセンタに出荷するために前記ＳＫＵに関連する供給業者への購入注文を生成する命令を含む、請求項１に記載のシステム。
11. 製品のインテリジェントな分配のためのコンピュータ実施方法であって、前記方法は、
    在庫管理単位（ＳＫＵ）の予想需要を含む予測データを受信することと、
    前記受信した予測データに基づいて、前記予想需要を満たすための前記ＳＫＵの目標在庫を決定し、前記目標在庫は、
    前記ＳＫＵの運転在庫と、
    前記ＳＫＵの安全在庫と、を含むことと、
    前記ＳＫＵの前記目標在庫に基づいて、複数のフルフィルメントセンタを含む地域の前記ＳＫＵの地域目標在庫を決定し、前記地域目標在庫は、
    前記ＳＫＵの地域運転在庫と、
    前記ＳＫＵの地域安全在庫と、を含むことと、
    前記複数のフルフィルメントセンタ内の各フルフィルメントセンタのインバウンドおよびアウトバウンド出荷履歴を含む履歴データを受信することと、
    前記受信した履歴データに基づいて、各フルフィルメントセンタの能力を決定するように構成されたデータモデルを生成することと、
    前記受信した履歴データで前記データモデルを訓練することと、
    前記訓練したデータモデルを用いて、各フルフィルメントセンタのプロファイルを生成し、前記プロファイルは、
    インバウンド容量と、
    アウトバウンド容量と、
    前記ＳＫＵの経常在庫と、を含むことと、
    各フルフィルメントセンタの前記プロファイルに基づいて、前記地域目標在庫の一部を各フルフィルメントセンタに割り当てることと、
    前記一部に基づいて各フルフィルメントセンタにいくつかのＳＫＵをストックするようにデバイスに命令を送信することと、
    を含むコンピュータ実施方法。
12. 前記地域目標在庫の一部を割り当てることは、前記ＳＫＵが複数のフルフィルメントセンタにあるべきであるという決定にさらに基づく、請求項１１に記載のコンピュータ実施方法。
13. 前記地域目標在庫の一部を割り当てることは、前記複数のフルフィルメントセンタ内の各フルフィルメントセンタに対して生成されたプロファイルの集合にさらに基づく、請求項１１に記載のコンピュータ実施方法。
14. 前記ＳＫＵの現在のアウトバウンド注文の記録を参照することをさらに含み、前記地域目標在庫の一部を割り当てることは、前記ＳＫＵの前記経常在庫および前記ＳＫＵの前記現在のアウトバウンド注文にさらに基づく、請求項１１に記載のコンピュータ実施方法。
15. 前記運転在庫は、前記予想需要を満たすように決定された前記ＳＫＵの量であり、前記安全在庫は、前記予想需要の超過を満たすように決定された前記ＳＫＵの追加量である、請求項１１に記載のコンピュータ実施方法。
16. 前記送信された命令は、
    前記ＳＫＵの前記地域目標在庫の前記割り当てられた部分と等しいままであるように、前記ＳＫＵの前記経常在庫を維持する命令、または
    前記ＳＫＵの前記地域目標在庫の前記割り当てられた部分と等しくなるように、前記ＳＫＵの前記経常在庫を調整する命令、
    のうちの一方を含む、請求項１１に記載のコンピュータ実施方法。
17. 前記経常在庫を維持することは、
    前記ＳＫＵのアウトバウンド数量と等しいままであるように、前記ＳＫＵのインバウンド数量を維持すること、または
    前記ＳＫＵのアウトバウンド数量と等しくなるように、前記ＳＫＵのインバウンド数量を修正すること、
    のうちの一方を含む、請求項１６に記載のコンピュータ実施方法。
18. 前記経常在庫を調整することは、前記経常在庫が前記ＳＫＵの前記地域目標在庫の前記割り当てられた部分に近づくように、前記フルフィルメントセンタの前記ＳＫＵのインバウンド数量を修正または維持することを含む、請求項１６に記載のコンピュータ実施方法。
19. 前記送信された命令は、前記地域目標在庫の前記割り当てられた部分に基づいて、各フルフィルメントセンタに出荷するために前記ＳＫＵに関連する供給業者への購入注文を生成する命令を含む、請求項１１に記載のコンピュータ実施方法。
20. 製品のインテリジェントな分配のためのコンピュータ実装システムであって、前記システムは、
    命令を格納するメモリと、
    前記命令を実行するように構成された少なくとも１つのプロセッサと、を含み、前記命令により、
    在庫管理単位（ＳＫＵ）の予想需要を含む予測データを受信し、
    前記受信した予測データに基づいて、前記予想需要を満たすための前記ＳＫＵの目標在庫を決定し、前記目標在庫は、
    前記ＳＫＵの運転在庫と、
    前記ＳＫＵの安全在庫と、を含み、
    前記ＳＫＵの前記目標在庫に基づいて、複数のフルフィルメントセンタを含む地域の前記ＳＫＵの地域目標在庫を決定し、前記地域目標在庫は、
    前記ＳＫＵの地域運転在庫と、
    前記ＳＫＵの地域安全在庫と、を含み、
    前記複数のフルフィルメントセンタ内の各フルフィルメントセンタのインバウンドおよびアウトバウンド出荷履歴を含む履歴データを受信し、
    前記受信した履歴データに基づいて、各フルフィルメントセンタの能力を決定するように構成されたデータモデルを生成し、
    前記受信した履歴データで前記データモデルを訓練し、
    前記訓練したデータモデルを用いて、各フルフィルメントセンタのプロファイルを生成し、前記プロファイルは、
    インバウンド容量と、
    アウトバウンド容量と、
    前記ＳＫＵの経常在庫と、を含み、
    各フルフィルメントセンタの前記プロファイルに基づいて、前記地域目標在庫の一部を各フルフィルメントセンタに割り当て、
    前記ＳＫＵの前記経常在庫と前記一部に基づいて、前記ＳＫＵの前記経常在庫が前記割り当てられた部分を満たしているかどうかを判定し、
    前記経常在庫が前記割り当てられた部分を満たしていないとの判定に基づいて、ＳＫＵの前記経常在庫が前記割り当てられた部分を満たすまで、各フルフィルメントセンタで前記ＳＫＵのインバウンドフローを修正または維持するようにデバイスに命令を送信する、
    コンピュータ実装システム。

Images