ホーム > 特許ランキング > クーパン コーポレイション
知財求人 - 知財ポータルサイト「IP Force」
特許7058770インバウンド購入注文のインテリジェントな調整による製品在庫の最適化のためのシステムおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-04-14
(45)【発行日】2022-04-22
(54)【発明の名称】インバウンド購入注文のインテリジェントな調整による製品在庫の最適化のためのシステムおよび方法
(51)【国際特許分類】
G06Q 10/08 20120101AFI20220415BHJP
【ＦＩ】
G06Q10/08 330
【請求項の数】
20
(21)【出願番号】P 2020567804
(86)(22)【出願日】2020-09-21
(65)【公表番号】
(43)【公表日】2021-12-16
(86)【国際出願番号】 IB2020058780
(87)【国際公開番号】W WO2021069992
(87)【国際公開日】2021-04-15
【審査請求日】2021-03-11
(31)【優先権主張番号】16/599,048
(32)【優先日】2019-10-10
(33)【優先権主張国・地域又は機関】US
【早期審査対象出願】
(73)【特許権者】
【識別番号】520244544
【氏名又は名称】クーパン コーポレイション
(74)【代理人】
【識別番号】230104019
【弁護士】
【氏名又は名称】大野 聖二
(74)【代理人】
【識別番号】100131451
【弁理士】
【氏名又は名称】津田 理
(74)【代理人】
【識別番号】100167933
【弁理士】
【氏名又は名称】松野 知紘
(74)【代理人】
【識別番号】100174137
【弁理士】
【氏名又は名称】酒谷 誠一
(74)【代理人】
【識別番号】100184181
【弁理士】
【氏名又は名称】野本 裕史
(72)【発明者】
【氏名】ワン，ヤン
(72)【発明者】
【氏名】ウェイ，ウェイ
(72)【発明者】
【氏名】ツァン，グァンヤオ
(72)【発明者】
【氏名】カールソン，クリストファー
【審査官】塩田 徳彦
(56)【参考文献】
【文献】特表２０１７－５３４９９０（ＪＰ，Ａ）
【文献】特開２００２－１８３２５７（ＪＰ，Ａ）
【文献】特開２００２－１３３２３２（ＪＰ，Ａ）
【文献】米国特許出願公開第２００２／０１４３６６９（ＵＳ，Ａ１）
【文献】特開２００７－２８０４０１（ＪＰ，Ａ）
【文献】中国特許出願公開第１１０２６４２９７（ＣＮ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
購入注文のインテリジェントな生成のためのコンピュータによって実装されるシステムであって、命令を格納するメモリと、
少なくとも１つのプロセッサと
を備えており、
前記少なくとも１つのプロセッサは、前記命令を実行して、
１つまたは複数の製品識別子に対応している１つまたは複数の製品について、各単位時間における各製品の需要予測数量を含む１つまたは複数の需要予測数量を受け取り、
前記１つまたは複数の製品の一部に関する１つまたは複数のサプライヤについて、サプライヤ統計データを受け取り、
前記１つまたは複数の製品の現在の製品在庫レベルおよび現在の注文済み数量を受け取り、
前記需要予測数量、前記サプライヤ統計データ、および前記現在の製品在庫レベルに少なくとも基づいて、前記１つまたは複数の製品の注文数量を決定し、
フィードフォワードループで更新される１つまたは複数のサプライヤ固有パラメータに基づいて前記注文数量に優先順位を付け、
前記優先順位が付けられた注文数量を１つまたは複数の場所に分配し、
前記分配された注文数量に基づいて、前記１つまたは複数の製品について前記サプライヤへの購入注文を生成し、
前記購入注文に応答して受け取った前記１つまたは複数の製品に基づいて前記１つまたは複数のサプライヤ固有パラメータを更新する
ように構成されている、コンピュータによって実装されるシステム。
【請求項2】
前記命令は、前記注文数量を制約することをさらに含み、第１の製品の第１の注文数量を制約することは、
前記サプライヤのうちの前記第１の製品に対応する一部のサプライヤを特定することと、
前記サプライヤ統計データから、前記一部のサプライヤについて、過去の注文数量および実際に受け取った数量を抽出することと、
前記過去の注文数量に対する前記実際に受け取った数量の平均充足率を決定することと、
前記平均充足率を前記第１の注文数量に適用することと
を含む、請求項１に記載のコンピュータによって実装されるシステム。
【請求項3】
第１の製品の第１の注文数量は、第１の期間にわたる前記第１の製品の需要予測数量の合計および第２の期間にわたる前記第１の製品の安全在庫数量の合計の少なくとも一方を含む、請求項１に記載のコンピュータによって実装されるシステム。
【請求項4】
前記注文数量に優先順位を付けることは、前記製品識別子を１つまたは複数のグループにグループ化することと、
前記注文数量の合計が前記場所のインバウンド能力の合計を超えるかどうかを判断することと、
前記注文数量の合計が前記インバウンド能力の合計を下回るまで前記注文数量を削減することと
を含む、請求項１に記載のコンピュータによって実装されるシステム。
【請求項5】
前記注文数量を削減することは、現在の製品在庫レベルが正である第１のグループ内の第１の一部の製品の前記注文数量を、ゼロに削減することと、
現在の製品在庫レベルがゼロである第２のグループ内の第２の一部の製品の前記注文数量を、前記需要予測数量に基づいて決定される１つまたは複数の最小数量に削減することと、
現在の在庫レベルが正である前記第２のグループ内の前記第２の一部の製品の前記注文数量を、ゼロに削減することと
を含む、請求項４に記載のコンピュータによって実装されるシステム。
【請求項6】
前記優先順位が付けられた注文数量を分配することは、前記優先順位が付けられた注文数量を前記場所へと、前記現在の製品在庫レベルに基づいて分配することと、
第１の場所のインバウンド能力を超える数量の超過分を明らかにすることと、
前記数量の超過分を１つまたは複数の残りの場所に移すことと
を含む、請求項１に記載のコンピュータによって実装されるシステム。
【請求項7】
前記数量の超過分を前記残りの場所に移すことは、前記数量の超過分を均等に移すことを含む、請求項６に記載のコンピュータによって実装されるシステム。
【請求項8】
前記数量の超過分を前記残りの場所に移すことは、前記数量の超過分を前記残りの場所の各々にすでに分配された注文数量の比に基づいて移すことを含む、請求項６に記載のコンピュータによって実装されるシステム。
【請求項9】
前記命令は、前記製品のうちの一部について１つまたは複数の手動注文のユーザ入力を受け取ることをさらに含む、請求項１に記載のコンピュータによって実装されるシステム。
【請求項10】
第１の製品の購入注文を生成することは、第１のサプライヤを含む前記サプライヤに前記購入注文を送信することと、
前記購入注文に応答した前記第１のサプライヤからの前記製品の１つまたは複数の出荷を受け取ることと、
前記受け取った製品に基づいて前記第１のサプライヤに関する前記サプライヤ統計データを更新することと、
前記更新されたサプライヤ統計データに基づいて前記注文数量を決定するための工程を実行し、新たな注文数量一式を得ることと、
前記新たな注文数量一式に基づいて、前記優先順位付け、分配、および購入注文の生成の工程を実行することと
を含む、請求項１に記載のコンピュータによって実装されるシステム。
【請求項11】
購入注文のインテリジェントな生成のためのコンピュータによって実装される方法であって、１つまたは複数の製品識別子に対応している１つまたは複数の製品について、各単位時間における各製品の需要予測数量を含む１つまたは複数の需要予測数量を受け取ることと、
前記１つまたは複数の製品の一部に関する１つまたは複数のサプライヤについて、サプライヤ統計データを受け取ることと、
前記１つまたは複数の製品の現在の製品在庫レベルおよび現在の注文済み数量を受け取ることと、
前記需要予測数量、前記サプライヤ統計データ、および前記現在の製品在庫レベルに少なくとも基づいて、前記１つまたは複数の製品の注文数量を決定することと、
フィードフォワードループで更新される１つまたは複数のサプライヤ固有パラメータに基づいて前記注文数量に優先順位を付けることと、
前記優先順位が付けられた注文数量を１つまたは複数の場所に分配することと、
前記分配された注文数量に基づいて、前記１つまたは複数の製品について前記サプライヤへの購入注文を生成することと、
前記購入注文に応答して受け取った前記１つまたは複数の製品に基づいて前記１つまたは複数のサプライヤ固有パラメータを更新することと
を含む、コンピュータによって実装される方法。
【請求項12】
前記注文数量を制約することをさらに含み、第１の製品の第１の注文数量を制約することは、
前記サプライヤのうちの前記第１の製品に対応する一部のサプライヤを特定することと、
前記サプライヤ統計データから、前記一部のサプライヤについて、過去の注文数量および実際に受け取った数量を抽出することと、
前記過去の注文数量に対する前記実際に受け取った数量の平均充足率を決定することと、
前記平均充足率を前記第１の注文数量に適用することと
を含む、請求項１１に記載のコンピュータによって実装される方法。
【請求項13】
第１の製品の第１の注文数量は、第１の期間にわたる前記第１の製品の需要予測数量の合計および第２の期間にわたる前記第１の製品の安全在庫数量の合計の少なくとも一方を含む、請求項１１に記載のコンピュータによって実装される方法。
【請求項14】
前記注文数量に優先順位を付けることは、前記製品識別子を１つまたは複数のグループにグループ化することと、
前記注文数量の合計が前記場所のインバウンド能力の合計を超えるかどうかを判断することと、
前記注文数量の合計が前記インバウンド能力の合計を下回るまで前記注文数量を削減することと
を含む、請求項１１に記載のコンピュータによって実装される方法。
【請求項15】
前記注文数量を削減することは、現在の製品在庫レベルが正である第１のグループ内の第１の一部の製品の前記注文数量を、ゼロに削減することと、
現在の製品在庫レベルがゼロである第２のグループ内の第２の一部の製品の前記注文数量を、前記需要予測数量に基づいて決定される１つまたは複数の最小数量に削減することと、
現在の在庫レベルが正である前記第２のグループ内の前記第２の一部の製品の前記注文数量を、ゼロに削減することと
を含む、請求項１４に記載のコンピュータによって実装される方法。
【請求項16】
前記優先順位が付けられた注文数量を分配することは、前記優先順位が付けられた注文数量を前記場所へと、前記現在の製品在庫レベルに基づいて分配することと、
第１の場所のインバウンド能力を超える数量の超過分を明らかにすることと、
前記数量の超過分を１つまたは複数の残りの場所に移すことと
を含む、請求項１１に記載のコンピュータによって実装される方法。
【請求項17】
前記数量の超過分を前記残りの場所に移すことは、前記数量の超過分を前記残りの場所の各々にすでに分配された注文数量の比に基づいて移すことを含む、請求項１６に記載のコンピュータによって実装される方法。
【請求項18】
前記製品のうちの一部について１つまたは複数の手動注文のユーザ入力を受け取ることをさらに含む、請求項１１に記載のコンピュータによって実装される方法。
【請求項19】
第１の製品の購入注文を生成することは、第１のサプライヤを含む前記サプライヤに前記購入注文を送信することと、
前記購入注文に応答した前記第１のサプライヤからの前記製品の１つまたは複数の出荷を受け取ることと、
前記受け取った製品に基づいて前記第１のサプライヤに関する前記サプライヤ統計データを更新することと、
前記更新されたサプライヤ統計データに基づいて前記注文数量を決定するための工程を実行し、新たな注文数量一式を得ることと、
前記新たな注文数量一式に基づいて、前記優先順位付け、分配、および購入注文の生成の工程を実行することと
を含む、請求項１１に記載のコンピュータによって実装される方法。
【請求項20】
購入注文のインテリジェントな生成のためのコンピュータによって実装されるシステムであって、１つまたは複数の製品識別子に対応している１つまたは複数の製品の１つまたは複数の注文履歴および１つまたは複数の需要履歴を格納する第１のデータベースと、
前記１つまたは複数の製品を保管するように構成された１つまたは複数の倉庫に関連付けられ、前記１つまたは複数の製品の１つまたは複数の現在の製品在庫レベルおよび１つまたは複数の現在の注文済み数量を格納する第２のデータベースと、
命令を格納するメモリと、
少なくとも１つのプロセッサと
を備えており、
前記少なくとも１つのプロセッサは、前記命令を実行し、
前記第１のデータベースからの前記注文履歴および前記需要履歴を使用して、前記製品の１つまたは複数の需要予測数量を決定し、
前記第１のデータベースからの前記注文履歴を使用して、前記製品に関する１つまたは複数のサプライヤについて、該サプライヤおよび前記１つまたは複数の製品に関する１つまたは複数の充足率を含むサプライヤ統計データを決定し、
前記第２のデータベースから、前記１つまたは複数の製品の前記現在の製品在庫レベルおよび前記現在の注文済み数量を受け取り、
前記需要予測数量、前記サプライヤ統計データ、および前記現在の製品在庫レベルに少なくとも基づいて、前記製品の注文数量を決定し、
前記充足率に少なくとも基づいて、前記注文数量に優先順位を付け、
前記優先順位が付けられた注文数量を１つまたは複数の場所に分配し、
前記分配された注文数量に基づいて、前記１つまたは複数の製品について前記サプライヤへの購入注文を生成し、
前記生成された購入注文に応答して、前記倉庫において前記１つまたは複数の製品を受け取り、
前記受け取った製品に基づいてフィードフォワードループを用いて前記充足率を決定し、
前記決定された充足率で前記サプライヤ統計データを更新し、
前記更新された充足率に基づいて前記注文数量を決定するための工程を実行して、新たな注文数量一式を得、
前記新たな注文数量一式に基づいて、前記優先順位付け、分配、および購入注文の生成の工程を実行する
ように構成されている、コンピュータによって実装されるシステム。
【発明の詳細な説明】
【技術分野】
【0001】
[0001] 本開示は、広くには、入荷する製品に関する購入注文をインテリジェントに調整することによって製品在庫を最適化するためのコンピュータ化された方法およびシステムに関する。とくには、本開示の実施形態は、製品の需要予測のレベルに基づいて推奨注文数量を生成し、現実世界の制約に基づいて製品に優先順位を付け、注文のために製品を複数の場所に分配し、分配された数量について各々の場所の購入注文を生成する独創的な従来にないシステムに関する。
【背景技術】
【0002】
[0002] インターネットの普及に伴い、オンラインショッピングが、商取引の主要な手段の１つになっている。消費者および企業は、これまでよりも頻繁にオンラインベンダーから商品を購入しており、取引数および売上高は、前年比で驚異的な速度で増加すると予測されている。電子商取引の範囲および量が拡大し続けるにつれて、オンラインで入手可能なさまざまな製品の数および所与の期間内で行われる購入の平均数の両方が、指数関数的に増加している。したがって、製品の在庫を維持し、たとえ需要が変動してもアイテムを在庫しておくことが、きわめて重要になっている。
【0003】
[0003] 基本的に、製品の在庫を維持するために、将来の需要を予測し、現在の在庫レベルを確認し、適切な注文数量を決定し、追加の数量を注文または製造することが必要である。多くの先行技術のシステムは、追加の数量を注文するこのプロセスを自動化している。しかしながら、適切な数量を決定するためには、将来の需要を満たすための充分な在庫を維持しつつ、余分または不必要な保管料を防止するために在庫を最小限に抑えるという微妙なバランスが必要である。例えば、事前に充分な製品を注文しないと、在庫がなくなるリスクが生じ、これは収益の損失に直結する。他方で、注文が多すぎると在庫が過剰になり、維持費用が発生し、他のより有利な製品に向けることができるスペースを占有してしまう可能性がある。サプライヤにおいて必要なリードタイムまたは出荷時間も、需要の急増に対応して新たな製品を注文するプロセスをさらに複雑にする。
【0004】
[0004] しかしながら、単に存在する需要と同数の製品を注文したり、安全のために必要以上を注文したりすることは、理想的な解決策ではない。さらに、製品の注文は、受け取り側の処理能力によっても制限される。例えば店舗自体や倉庫など、受け取り側が、所与の期間において受け取り、販売のために在庫に蓄えることができる製品の数について、制約を有する。それにもかかわらず、店舗は、需要を満たすために必要な数の商品を注文することができるが、入荷数量がインバウンド処理能力を超える場合、それらを販売することはできないと考えられる。したがって、適切な数量を決定するプロセスは、製品在庫を絶えず監視し、過去の傾向およびパフォーマンスに基づいて将来の注文のパラメータを調整するフィードフォワードループによってさまざまなパラメータを調整し、インバウンド処理能力を継続的に評価することが必要であるが、これらを人間が実行することは実現不可能であり、効率的でもない。
【0005】
[0005] したがって、複数の場所の各々について製品の適切な注文数量を決定するようにインバウンド購入注文をインテリジェントに調整することによって製品在庫を最適なレベルに保つための改善された方法およびシステムについて、ニーズが存在する。
【発明の概要】
【0006】
[0006] 本開示の一態様は、購入注文のインテリジェントな生成のためのコンピュータによって実装されるシステムに関する。システムは、命令を格納するメモリと、命令を実行するように構成された少なくとも１つのプロセッサとを備えることができる。命令は、１つ以上の製品識別子に対応している１つまたは複数の製品について、各単位時間における各製品の需要予測数量を含む１つまたは複数の需要予測数量を受け取ることと、前記製品の一部に関する１つまたは複数のサプライヤについて、サプライヤ統計データを受け取ることと、前記製品の現在の製品在庫レベルおよび現在の注文済み数量を受け取ることと、前記需要予測数量、前記サプライヤ統計データ、および前記現在の製品在庫レベルに少なくとも基づいて、前記製品の注文数量を決定することと、前記注文数量に優先順位を付けることと、前記優先順位が付けられた注文数量を１つまたは複数の場所に分配することと、前記分配された注文数量に基づいて、前記製品について前記サプライヤへの購入注文を生成することとを含むことができる。
【0007】
[0007] 本開示のさらに別の態様は、購入注文のインテリジェントな生成のためのコンピュータによって実装される方法に関する。この方法は、１つ以上の製品識別子に対応している１つまたは複数の製品について、各単位時間における各製品の需要予測数量を含む１つまたは複数の需要予測数量を受け取ることと、前記製品の一部に関する１つまたは複数のサプライヤについて、サプライヤ統計データを受け取ることと、前記製品の現在の製品在庫レベルおよび現在の注文済み数量を受け取ることと、前記需要予測数量、前記サプライヤ統計データ、および前記現在の製品在庫レベルに少なくとも基づいて、前記製品の注文数量を決定することと、前記注文数量に優先順位を付けることと、前記優先順位が付けられた注文数量を１つまたは複数の場所に分配することと、前記分配された注文数量に基づいて、前記製品について前記サプライヤへの購入注文を生成することとを含むことができる。
【0008】
[0008] またさらに、本開示の別の態様は、購入注文のインテリジェントな生成のためのコンピュータによって実装されるシステムに関する。このシステムは、１つまたは複数の製品識別子に対応している１つまたは複数の製品の１つまたは複数の注文履歴および１つまたは複数の需要履歴を格納する第１のデータベースと、前記製品を保管するように構成された１つまたは複数の倉庫に関連付けられ、前記製品の１つまたは複数の現在の製品在庫レベルおよび１つまたは複数の現在の注文済み数量を格納する第２のデータベースと、命令を格納するメモリと、前記命令を実行するように構成された少なくとも１つのプロセッサとを含むことができる。前記命令は、前記第１のデータベースからの前記注文履歴および前記需要履歴を使用して、前記製品の１つまたは複数の需要予測数量を決定することと、前記第１のデータベースからの前記注文履歴を使用して、前記製品に関する１つまたは複数のサプライヤについて、該サプライヤおよび前記製品に関する１つまたは複数の充足率を含むサプライヤ統計データを決定することと、前記第２のデータベースから、前記製品の前記現在の製品在庫レベルおよび前記現在の注文済み数量を受け取ることと、前記需要予測数量、前記サプライヤ統計データ、および前記現在の製品在庫レベルに少なくとも基づいて、前記製品の注文数量を決定することと、前記充足率に少なくとも基づいて、前記注文数量に優先順位を付けることと、前記優先順位が付けられた注文数量を１つまたは複数の場所に分配することと、前記分配された注文数量に基づいて、前記製品について前記サプライヤへの購入注文を生成することと、前記生成された購入注文に応答して、前記倉庫において製品を受け取ることと、前記受け取った製品に基づいて前記充足率を決定することと、前記決定された充足率で前記サプライヤ統計データを更新することと、前記更新された充足率に基づいて前記注文数量を決定するための工程を実行して、新たな注文数量一式を得ることと、前記新たな注文数量一式に基づいて、前記優先順位付け、分配、および購入注文の生成の工程を実行することとを含むことができる。
【0009】
[0009] 他のシステム、方法、およびコンピュータ可読媒体も、本明細書で説明される。
【図面の簡単な説明】
【0010】
【図1A】[0010] 図１Ａは、本開示の実施形態による出荷、輸送、および物流作業を可能にする通信のためのコンピュータ化されたシステムを備えるネットワークの例示的な実施形態を示す概略ブロック図である。
【発明を実施するための形態】
【0011】
[0021] 以下の詳細な説明は、添付の図面を参照する。可能な限り、図面および以下の説明では、同一または類似の部分を参照するために、同一の参照番号が使用される。いくつかの例示的な実施形態が本明細書で説明されるが、修正、適応、および他の実装が可能である。例えば、置換、追加、または修正が、図面に示された構成要素およびステップに対して行われてもよく、本明細書に記載された例示的な方法は、開示された方法に対するステップの置換、並べ替え、除去、または追加によって修正されてもよい。したがって、以下の詳細な説明は、開示された実施形態および例に限定されない。むしろ、本発明の適切な範囲は、添付の特許請求の範囲によって定義される。
【0012】
[0022] 本開示の実施形態は、需要および現実世界の制約に基づいて複数の場所からの最適な注文数量を決定することによって製品在庫を最適化するためのコンピュータによって実装されるシステムおよび方法に関する。
【0013】
[0023] 図１Ａを参照すると、出荷、輸送、および物流動作を可能にする通信のためのコンピュータ化されたシステムを含むシステムの例示的な実施形態を示す概略ブロック図１００が示されている。図１Ａに示すように、システム１００は様々なシステムを含むことができ、その各々は、１つまたは複数のネットワークを介して互いに接続することができる。システムはまた、例えばケーブルを使用して、直接接続を介して互いに接続されてもよい。図示のシステムは、出荷権限技術（ＳＡＴ）システム１０１、外部フロントエンドシステム１０３、内部フロントエンドシステム１０５、輸送システム１０７、モバイルデバイス１０７Ａ、１０７Ｂ、１０７Ｃ、売り手ポータル１０９、出荷および注文追跡（ＳＯＴ）システム１１１、フルフィルメント（履行）最適化（ＦＯ）システム１１３、フルフィルメントメッセージングゲートウェイ（ＦＭＧ）１１５、サプライチェーン管理（ＳＣＭ）システム１１７、労働力管理システム１１９、モバイルデバイス１１９Ａ、１１９Ｂ、１１９Ｃ（フルフィルメントセンタ（ＦＣ）２００の内部にあるものとして図示）、第三者フルフィルメントシステム１２１Ａ、１２１Ｂ、１２１Ｃ、フルフィルメントセンタ認証システム（ＦＣ認証）１２３、労働管理システム（ＬＭＳ）１２５を含む。
【0014】
[0024] いくつかの実施形態では、ＳＡＴシステム１０１は、注文状態および配送状態を監視するコンピュータシステムとして実装されてもよい。例えば、ＳＡＴ装置１０１は、注文がその約束配送日（ＰＤＤ）を過ぎているかどうかを判定し、新しい注文を開始すること、配達されていない注文でアイテムを再出荷すること、配達されていない注文をキャンセルすること、注文カスタマとのコンタクトを開始することなどを含む適切な処置をとることができる。ＳＡＴ装置１０１は、出力（特定の期間中に出荷された荷物の数のよう）及び入力（出荷に使用するために受け取った空のボール紙箱の数のよう）を含む他のデータを監視することもできる。また、ＳＡＴシステム１０１は、システム１００内の異なるデバイス間のゲートウェイとして機能し、外部フロントエンドシステム１０３およびＦＯシステム１１３などのデバイス間の通信（例えば、ストアアンドフォワードまたは他の技術を使用する）を可能にしてもよい。
【0015】
[0025] いくつかの実施形態では、外部フロントエンドシステム１０３は、外部ユーザがシステム１００内の１つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装することができる。例えば、システム１００がシステムの提示を可能にして、ユーザがアイテムのための注文を配置することを可能にする実施形態では、外部フロントエンドシステム１０３は、検索リクエストを受信し、アイテムページを提示し、決済情報を要請するウェブサーバとして実装されてもよい。例えば、外部フロントエンドシステム１０３は、アパッチＨＴＴＰサーバ、マイクロソフトインターネットインフォメーションサービス、ＮＧＩＮＸ等のソフトウェアを実行するコンピュータ又はコンピュータとして実施することができる。他の実施形態では、外部フロントエンドシステム１０３は、外部デバイス（例えば、モバイルデバイス１０２Ａまたはコンピュータ１０２Ｂ）からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得した情報に基づいて受信した要求に対する応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。
【0016】
[0026] いくつかの実施形態では、外部フロントエンドシステム１０３は、ウェブキャッシングシステム、データベース、検索システム、または支払いシステムのうちの１つまたは複数を含むことができる。一態様では、外部フロントエンドシステム１０３は、これらのシステムのうちの１つまたは複数を備えることができ、別の態様では、外部フロントエンドシステム１０３は、これらのシステムのうちの１つまたは複数に接続されたインターフェース（例えば、サーバ間、データベース間、または他のネットワーク接続）を備えることができる。
【0017】
[0027] 図１Ｂ、図１Ｃ、図１Ｄ、および図１Ｅによって示される例示的な一組のステップは、外部フロントエンドシステム１０３のいくつかの動作を説明するのに役立つことができる。外部フロントエンドシステム１０３は、提示および／またはディスプレイのために、システム１００内のシステムまたはデバイスから情報を受け取ることができる。例えば、外部フロントエンドシステム１０３は、検索結果ページ（ＳＲＰ）（例えば、図１Ｂ）、単一ディテールページ（ＳＤＰ）（例えば、図１Ｃ）、カードページ（例えば、図１Ｄ）、または注文ページ（例えば、図１Ｅ）を含む１つ以上のウェブページをホスティングまたは提供することができる。ユーザデバイス（例えば、モバイルデバイス１０２Ａまたはコンピュータ１０２Ｂを使用する）は、外部フロントエンドシステム１０３にナビゲートし、サーチボックスに入力することによってサーチをリクエストすることができる。外部フロントエンドシステム１０３は、システム１００内の１つまたは複数のシステムからリクエストすることができる。例えば、外部フロントエンドシステム１０３は、検索要求を満たす情報をＦＯシステム１１３に要求してもよい。また、外部フロントエンドシステム１０３は、検索結果に含まれる商品ごとに、約束配送日または「ＰＤＤ」を（ＦＯシステム１１３から）リクエストし、受信することもできる。いくつかの実施形態では、ＰＤＤは、特定の期間内に、例えば、その日の最後（午後１１時５９分）までに注文された場合、製品を含む荷物が、いつユーザの所望の場所に到着するか、または製品がユーザの所望の場所に配送されることを約束される日付かのいずれかの推定値を表すことができる（ＰＤＤはＦＯシステム１１３に関して以下でさらに説明される）。
【0018】
[0028] 外部フロントエンドシステム１０３は、その情報に基づいてＳＲＰ（例えば、図１Ｂ）を準備することができる。ＳＲＰは、検索要求を満たす情報を含むことができる。例えば、これは、検索要求を満たす製品の写真を含むことができる。ＳＲＰはまた、各製品についてのそれぞれの価格、または各製品についての強化された配送オプション、ＰＤＤ、重み、規模、オファー、割引などに関する情報を含んでもよい。外部フロントエンドシステム１０３は、（例えば、ネットワークを介して）要求側ユーザデバイスにＳＲＰを送信することができる。
【0019】
[0029] 次いで、ユーザデバイスは、例えば、ユーザインターフェースをクリックまたはタップすることによって、または別のインプットデバイスを使用して、ＳＲＰから製品を選択して、ＳＲＰ上に表される製品を選択し得る。ユーザデバイスは、選択されたプロダクトに関するリクエストを作成し、それを外部フロントエンドシステム１０３に送ることができる。これに応じて、外部フロントエンドシステム１０３は、選択された商品に関する情報をリクエストすることができる。例えば、情報は、それぞれのＳＲＰ上の製品について提示される情報を超える追加の情報を含むことができる。これには、例えば、貯蔵寿命、原産国、体重、大きさ、荷物中のアイテムの個数、取扱説明書、または生成物に関する他の事項が含まれ得る。また、情報は、（例えば、この製品および少なくとも１つの他の製品を購入した顧客のビッグデータおよび／または機械学習分析に基づく）類似の製品に対する推奨、頻繁に質問される質問に対する回答、顧客からのレビュー、製造業者情報、写真などを含むことができる。
【0020】
[0030] 外部フロントエンドシステム１０３は、受信したプロダクトインフォメーションに基づいて、ＳＤＰ（単一ディテールページ）（例えば、図１Ｃ）を準備することができる。ＳＤＰはまた、「今すぐ買う」ボタン、「カードに追加する」ボタン、数量欄、アイテムの写真等のような他の対話型要素を含んでもよい。ＳＤＰは、製品を提供する売り手のリストをさらに含むことができる。リストは各売り手が提供する価格に基づいて注文されてもよく、その結果、最低価格で製品を販売することを提案する売り手は最上位にリストされてもよい。リストは、最高ランクの売り手が最上位にリストされるように、売り手ランキングに基づいて注文されてもよい。売り手ランキングは、例えば、約束されたＰＤＤを満たす売り手の過去の実績を含む、複数の要因に基づいて定式化されてもよい。外部フロントエンドシステム１０３は、（例えば、ネットワークを介して）要求側ユーザデバイスにＳＤＰを配信することができる。
【0021】
[0031] 依頼元ユーザデバイスは、商品情報を記載したＳＤＰを受け取る場合がある。ＳＤＰを受信すると、ユーザデバイスはＳＤＰと対話することができる。例えば、要求ユーザデバイスのユーザは、ＳＤＰ上の「カートに入れる」ボタンをクリックするか、あるいは他の方法で対話することができる。これは、ユーザに関連付けられたショッピングカートに製品を追加する。ユーザデバイスは、このリクエストを送信して、商品をショッピングカートに追加し、外部フロントエンドシステム１０３に送ることができる。
【0022】
[0032] 外部フロントエンドシステム１０３は、カートページ（例えば、図１Ｄ）を生成することができる。いくつかの実施形態では、カートページは、ユーザが仮想の「買物かご」に追加した商品をリストし、ユーザデバイスは、ＳＲＰ、ＳＤＰ、または他のページ上のアイコンをクリックするか、または他の方法で対話することによって、カートページをリクエストしてもよい。いくつかの実施形態では、カートページは、ユーザがショッピングカートに追加したすべての製品、ならびに各製品の数量、各製品のアイテム当たりの価格、関連する数量に基づく各製品の価格、ＰＤＤに関する情報、配送方法、出荷費用、ショッピングカート内の製品を修正するためのユーザインターフェース要素（例えば、数量の削除または修正）、他の製品を注文するかまたは製品の定期的な配送を設定するためのオプション、利息支払いを設定するためのオプション、購入を進めるためのユーザインターフェース要素などのカート内の製品に関する情報を列挙することができる。ユーザデバイスのユーザは、ショッピングカート内の商品の購入を開始するために、ユーザインターフェース要素（例えば、「今すぐ買う」と読むボタン）をクリックするか、または他の方法でユーザインターフェース要素と対話することができる。そうすると、ユーザデバイスは、このリクエストを送信して、外部フロントエンドシステム１０３への購入を開始することができる。
【0023】
[0033] 外部フロントエンドシステム１０３は、購入を開始するためのリクエストの受信に応じて、注文ページ（例えば、図１Ｅ）を発生することができる。いくつかの実施形態では、注文ページは、ショッピングカートからのアイテムを再リストし、支払及び出荷に関するインプットを要求する。例えば、注文ページはショッピングカート内のアイテムの購入者に関する情報（例えば、名前、住所、電子メールアドレス、電話番号）、受取人に関する情報（例えば、名前、住所、電話番号、配送情報）、出荷情報（例えば、配送および／または集荷の速度／方法）、支払情報（例えば、クレジットカード、銀行振込、小切手、記憶クレジット）、現金受領を要求するためのユーザインターフェース要素（例えば、税務目的のための）などを要求する区画を含むことができる。外部フロントエンドシステム１０３は、注文ページをユーザデバイスへ送信することが可能である。
【0024】
[0034] ユーザデバイスは、注文ページに情報を入力し、その情報を外部フロントエンドシステム１０３に送信するユーザインターフェース要素をクリックするか、または他の方法で対話することができる。そこから、外部フロントエンドシステム１０３は、ショッピングカート内の製品との新しい注文の作成および加工を可能にするために、システム１００内の様々なシステムに情報を送信することができる。
【0025】
[0035] いくつかの実施形態では、外部フロントエンドシステム１０３は、売り手が注文に関する情報を送受信することを可能にするようにさらに構成されてもよい。
【0026】
[0036] いくつかの実施形態では、内部フロントエンドシステム１０５は、内部ユーザ（例えば、システム１００を所有し、運営し、またはリースする団体の従業員）がシステム１００内の１つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装することができる。例えば、ネットワーク１０１がシステムの提示を可能にして、ユーザが注文のための注文を配置できるようにする実施形態では、内部ユーザが注文に関する診断および統計情報を見たり、アイテム情報を修正したり、またはアイテムに関する統計を見直したりできるようにする、内部フロントエンドシステム１０５をウェブサーバとして実装することができる。例えば、内蔵フロントエンドシステム１０５は、アパッチＨＴＴＰサーバ、マイクロソフトインターネットインフォメーションサービス、ＮＧＩＮＸ等のソフトウェアを実行するコンピュータ又はコンピュータとして実現することができる。他の実施形態では、内蔵フロントエンドシステム１０５は、システム１００に示されるシステムまたはデバイス（ならびに図示されない他のデバイス）からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得された情報に基づいて受信された要求への応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。
【0027】
[0037] いくつかの実施形態では、内部フロントエンドシステム１０５は、ウェブキャッシングシステム、データベース、検索システム、支払いシステム、分析システム、注文監視システムなどのうちの１つまたは複数を含むことができる。一態様では、内部フロントエンドシステム１０５は、これらのシステムのうちの１つまたは複数を備えることができ、別の態様では、内部フロントエンドシステム１０５は、これらのシステムのうちの１つまたは複数に接続されたインターフェース（たとえば、サーバ間、データベース間、または他のネットワーク接続）を備えることができる。
【0028】
[0038] いくつかの実施形態では、輸送システム１０７は、システム１００内のシステムまたはデバイスとモバイルデバイス１０７Ａ～１０７Ｃとの間の通信を可能にするコンピュータシステムとして実施することができる。いくつかの実施形態では、輸送システム１０７は、１つまたは複数のモバイルデバイス１０７Ａ～１０７Ｃ（例えば、携帯電話、スマートフォン、ＰＤＡなど）から受信することができる。例えば、いくつかの実施形態では、モバイルデバイス１０７Ａ～１０７Ｃは、配送作業員によって操作されるデバイスを含んでもよい。配送作業員は、正社員、臨時社員、または交替社員であってもよく、モバイルデバイス１０７Ａ～１０７Ｃを利用して、ユーザによって注文された製品を含む荷物の配送を行うことができる。例えば、荷物を配信するために、配送作業員は、どの荷物を配信すべきか、およびそれをどこに配信すべきかを示す通知をモバイルデバイス上で受信することができる。配送位置に到着すると、配送作業員は荷物を（例えば、トラックの後ろに、または荷物の箱に）配置し、モバイルデバイスを使用して荷物上の識別子に関連するデータ（例えば、バーコード、イメージ、文字列、ＲＦＩＤタグなど）を走査または他の方法で捕捉し、荷物を（例えば、前扉に置いたままにし、警備員を置いたままにし、受信者に渡すなどによって）配信することができる。いくつかの実施形態では、配送作業員は、荷物の写真をキャプチャすることができ、および／またはモバイルデバイスを使用してシグネチャを取得することができる。モバイルデバイスは、例えば、時刻、日付、ＧＰＳ位置、写真、配送作業員に関連付けられた識別子、モバイルデバイスに関連付けられた識別子などを含む配送に関する情報を含む情報を輸送システム１０７に送信することができる。輸送システム１０７は、システム１００内の他のシステムによるアクセスのために、この情報をデータベース（図示せず）に記憶することができる。いくつかの実施形態では、輸送システム１０７は、この情報を使用して、特定の荷物の位置を示す追跡データを準備し、他のシステムに送信することができる。
【0029】
[0039] いくつかの実施形態では、あるユーザが１つの種類のモバイルデバイスを使用することができる（例えば、永久作業員はバーコードスキャナ、スタイラス、および他のデバイスなどのカスタムハードウェアと共に専用のＰＤＡを使用することができる）が、他のユーザは他の種類のモバイルデバイスを使用することができる（例えば、一時的または移動作業員は既製の携帯電話および／またはスマートフォンを利用することができる）。
【0030】
[0040] いくつかの実施形態では、輸送システム１０７は、ユーザをそれぞれのデバイスに関連付けることができる。例えば、輸送システム１０７は、ユーザ（例えば、ユーザ識別子、従業員識別子、または電話番号）とモバイルデバイス（例えば、国際移動装置アイデンティティ（ＩＭＥＩ）、国際移動加入識別子（ＩＭＳＩ）、電話番号、汎用一意識別子（ＵＵＩＤ）、またはグローバル一意（ＧＵＩＤ）によって表される）との間の関連を記憶することができる。輸送システム１０７は、この関連付けを、配送上で受信されたデータと併せて使用して、とりわけ、作業員の位置、作業員の有効性、または作業員のスピードを決定するために、注文内のデータベースに格納されたデータを分析することができる。
【0031】
[0041] いくつかの実施形態では、売り手ポータル１０９は、売り手または他の外部エンティティがシステム１００内の１つまたは複数のシステムと電子的に通信することを可能にするコンピュータシステムとして実装され得る。例えば、売り手は、コンピュータシステム（図示せず）を利用して、売り手が売り手ポータル１０９を使用してシステム１００を通して売りたい製品について、製品情報、注文情報、連絡先情報などをアップロードまたは提供することができる。
【0032】
[0042] いくつかの実施形態では、出荷および注文追跡システム１１１は、（例えば、デバイス１０２Ａ～１０２Ｂを使用するユーザによって）顧客によって注文された製品を含む荷物の位置に関する情報を受信し、記憶し、転送するコンピュータシステムとして実装されてもよい。いくつかの実施形態では、出荷および注文追跡装置１１１は、顧客が注文した製品を含む荷物を配送する出荷会社によって運営されるウェブサーバ（図示せず）からの情報をリクエストまたは記憶することができる。
【0033】
[0043] いくつかの実施形態では、出荷および注文追跡システム１１１は、システム１００に示されたシステムからの情報をリクエストし、記憶することができる。例えば、出荷および注文追跡システム１１１は、輸送システム１０７にリクエストすることができる。上述のように、輸送システム１０７は、ユーザ（例えば、配送作業員）または乗り物（例えば、配送車）のうちの１つまたは複数に関連付けられた１つまたは複数のモバイルデバイス１０７Ａ～１０７Ｃ（例えば、携帯電話、スマートフォン、ＰＤＡなど）から受信することができる。いくつかの実施形態では、出荷および注文追跡システム１１１は、フルフィルメントセンタ（例えば、フルフィルメントセンタ２００）内の個々の製品の位置を決定するために、労働力管理システム（ＷＭＳ）１１９にリクエストすることもできる。出荷および注文追跡システム１１１は、輸送システム１０７またはＷＭＳ１１９のうちの１つまたは複数からデータを要求し、それを処理し、要求に応じてそれをデバイス（たとえば、ユーザデバイス１０２Ａおよび１０２Ｂ）に提示することができる。
【0034】
[0044] いくつかの実施形態では、フルフィルメント（履行）最適化（ＦＯ）システム１１３は、他のシステム（例えば、外部フロントエンドシステム１０３および／または出荷および注文追跡システム１１１）からのカスタマ注文のための情報を記憶するコンピュータシステムとして実装されてもよい。また、ＦＯシステム１１３は、特定のアイテムがどこに保持されているか、またはどこに記憶されているかを記述する情報を記憶することもできる。たとえば、特定のアイテムは１つのフルフィルメントセンタにのみ格納でき、他の特定のアイテムは複数のフルフィルメントセンタに格納できる。さらに他の実施形態では、特定のフルフィルメントセンタが特定の組のアイテム（例えば、生鮮食品または冷凍食品）のみを格納するように設計されてもよい。ＦＯシステム１１３は、この情報ならびに関連する情報（例えば、数量、サイズ、受領日、有効期限など）を格納する。
【0035】
[0045] また、ＦＯシステム１１３は、商品毎に対応するＰＤＤ（約束配送日）を計算してもよい。いくつかの実施形態では、ＰＤＤは、１つまたは複数の要因に基づくことができる。例えば、ＦＯシステム１１３は、製品に対する過去の需要（例えば、その製品がある期間中に何回注文されたか）、製品に対する予想需要（例えば、来るべき期間中にその製品を注文するために何人の顧客が予想されるか）、ある期間中にいくつの製品が注文されたかを示すネットワーク全体の過去の需要、来るべき期間中にいくつの製品が注文されることが予想されるかを示すネットワーク全体の予想需要、各フルフィルメントセンタ２００に格納された製品の１つ以上のカウント、その製品に対する各製品、予想または現行注文などに基づいて、製品に対するＰＤＤを計算することができる。
【0036】
[0046] いくつかの実施形態では、ＦＯシステム１１３は、定期的に（例えば、１時間ごとに）商品ごとにＰＤＤを決定し、それを検索または他のシステム（例えば、外部フロントエンドシステム１０３、ＳＡＴシステム１０１、出荷および注文追跡システム１１１）に送信するためにデータベースに格納することができる。他の実施形態では、ＦＯシステム１１３は、１つまたは複数のシステム（例えば、外部フロントエンドシステム１０３、ＳＡＴシステム１０１、出荷および注文追跡システム１１１）から電子要求を受信し、オンデマンドでＰＤＤを計算することができる。
【0037】
[0047] いくつかの実施形態では、フルフィルメントメッセージングゲートウェイ１１５は、ＦＯシステム１１３などのシステム１００内の１つ以上のシステムから１つのフォーマットまたはプロトコルで要求または応答を受信し、それを別のフォーマットまたはプロトコルに変換し、変換されたフォーマットまたはプロトコルで、ＷＭＳ１１９または第三者フルフィルメントシステム１２１Ａ、１２１Ｂ、または１２１Ｃなどの他のシステムに転送するコンピュータシステムとして実装することができる。
【0038】
[0048] いくつかの実施形態では、サプライチェーン管理（ＳＣＭ）システム１１７は、予測機能を実行するコンピュータシステムとして実装することができる。例えば、ＳＣＭシステム１１７は、例えば、製品に対する過去の需要、製品に対する予想される需要、ネットワーク全体の過去の需要、ネットワーク全体の予想される需要、各フルフィルメントセンタ２００に格納された計数製品、各製品に対する予想または現行注文などに基づいて、特定の製品に対する需要の水準を予測することができる。この予測された水準およびすべてのフルフィルメントセンタにわたるそれぞれの製品の量に応じて、ＳＣＭシステム１１７は、特定の製品に対する予測された需要を満たすのに充分な量を購入し、ストックするための１つまたは複数の購入注文を生成することができる。
【0039】
[0049] いくつかの実施形態では、労働力管理システム（ＷＭＳ）１１９は、ワークフローをモニタするコンピュータシステムとして実装されてもよい。例えば、ＷＭＳ１１９は、個別イベントを示す個別デバイス（例えば、デバイス１０７Ａ～１０７Ｃまたは１１９Ａ～１１９Ｃ）からイベントデータを受信することができる。例えば、ＷＭＳ１１９は、荷物を走査するためにこれらのデバイスの１つの使用を示すイベントデータを受信してもよい。フルフィルメントセンタ２００および図２に関して以下で論じるように、フルフィルメントプロセス中に、荷物識別子（例えば、バーコードまたはＲＦＩＤタグデータ）は特定の段階で機械によってスキャンまたは読み取ることができる（例えば、自動またはハンドヘルドバーコードスキャナ、ＲＦＩＤリーダ、高速カメラ、タブレット１１９Ａ、モバイルデバイス／ＰＤＡ１１９Ｂ、コンピュータ１１９Ｃなどのデバイス）。ＷＭＳ１１９は荷物識別子、時刻、日時、位置、ユーザ識別子、または他の情報と共に、荷物識別子の走査または読取りを示す各々の事象を対応するデータベース（図示せず）に記憶することができ、この情報を他のシステム（例えば、出荷および注文追跡システム１１１）に提供することができる。
【0040】
[0050] いくつかの実施形態では、ＷＭＳ１１９は、１つまたは複数のデバイス（例えば、デバイス１０７Ａ～１０７Ｃまたは１１９Ａ～１１９Ｃ）を、システム１００に関連付けられた１つまたは複数のユーザに関連付ける情報を記憶してもよい。例えば、いくつかの状況では、ユーザ（パートまたはフルタイムの従業員など）は、ユーザがモバイルデバイスを所有する（例えば、モバイルデバイスがスマートフォンである）という点で、モバイルデバイスに関連付けられてもよい。他の状況では、ユーザは、ユーザが一時的にモバイルデバイスの管理下にある（例えば、ユーザは日の始めにモバイルデバイスを借り、日中にそれを使用し、日の終わりにそれを返す）という点で、モバイルデバイスに関連付けられてもよい。
【0041】
[0051] いくつかの実施形態では、ＷＭＳ１１９は、システム１００に関連する各ユーザの作業ログを維持することができる。例えば、ＷＭＳ１１９は、任意の割り当てられたプロセス（例えば、トラックのアンローディング、ピックゾーンからのアイテムのピッキング、仕分け装置ワーク、パッキングアイテム）、ユーザ識別子、位置（例えば、フルフィルメントセンタ２００内のフロアまたはゾーン）、従業員によってシステム内を移動されたユニットの数（例えば、ピックされたアイテムの数、パックされたアイテムの数）、デバイスに関連付けられた識別子（例えば、デバイス１１９Ａ～１１９Ｃ）などを含む、各従業員に関連付けられた情報を記憶することができる。いくつかの実施形態では、ＷＭＳ１１９は、デバイス１１９Ａ～１１９Ｃ上で動作するタイムキーピングシステムなどのタイムキーピングシステムからチェックインおよびチェックアウト情報を受信することができる。
【0042】
[0052] いくつかの実施形態では、第三者フルフィルメント（３ＰＬ）システム１２１Ａ～１２１Ｃは、ロジスティクスおよび製品のサードパーティプロバイダに関連するコンピュータシステムを表す。例えば、（図２に関して以下に説明するように）いくつかの製品がフルフィルメントセンタ２００に格納されている間、他の製品は、オフサイトで格納されてもよく、オンデマンドで生産されてもよく、またはフルフィルメントセンタ２００に格納するために利用できなくてもよい。３ＰＬシステム１２１Ａ～１２１Ｃは、ＦＯシステム１１３から（例えば、ＦＭＧ１１５を介して）注文を受信するように構成することができ、製品および／またはサービス（例えば、配送または設置）を顧客に直接的に提供することができる。いくつかの実施形態では、３ＰＬシステム１２１Ａ～１２１Ｃのうちの１つまたは複数がシステム１００の一部とすることができ、他の実施形態では、３ＰＬシステム１２１Ａ～１２１Ｃのうちの１つまたは複数がシステム１００の外部（例えば、サードパーティプロバイダによって所有または運営される）とすることができる。
【0043】
[0053] いくつかの実施形態では、フルフィルメントセンタ自動システム（ＦＣ認証）１２３は、様々な機能を有するコンピュータシステムとして実装され得る。例えば、いくつかの実施形態では、ＦＣ認証１２３は、システム１００内の１つまたは複数の他のシステムのためのシングルサインオン（ＳＳＯ）サービスとして動作することができる。例えば、ＦＣ認証１２３は、ユーザが内部フロントエンドシステム１０５を介してログインすることを可能にし、ユーザが出荷および注文追跡系１１１においてリソースにアクセスするための同様の特権を有していることを決定し、ユーザが２回目のログイン処理を必要とせずにそれらの特権にアクセスすることを可能にしてもよい。他の実施形態では、ＦＣ認証１２３は、ユーザ（例えば、従業員）が自分自身を特定の作業に関連付けることを可能にしてもよい。例えば、従業員の中には、電子デバイス（デバイス１１９Ａ～１１９Ｃなど）を持たない者もいれば、その代わりに、１日の過程中に、フルフィルメントセンタ２００内でタスクからタスクへ、およびゾーンからゾーンへ移動してもよい。ＦＣ認証１２３は、それらの従業員は、彼らがどの仕事をしているか、および彼らが様々な時刻にどの区域にいるかを示すことを可能にするように構成されてもよい。
【0044】
[0054] いくつかの実施形態では、労働管理システム（ＬＭＳ）１２５は、従業員（フルタイムおよびパートタイムの従業員を含む）のための出勤および残業を記憶するコンピュータシステムとして実装されてもよい。例えば、ＬＭＳ１２５は、ＦＣ認証１２３、ＷＭＡ１１９、デバイス１１９Ａ～１１９Ｃ、輸送装置１０７、及び／又はデバイス１０７Ａ～１０７Ｃから受信することができる。
【0045】
[0055] 図１Ａに示される特定の構成は単なる例である。例えば、図１Ａは、ＦＯシステム１１３に接続されたＦＣ認証システム１２３を示すが、全ての実施形態がこの特定の構成を必要とするわけではない。実際、いくつかの実施形態では、システム１００内のシステムがインターネット、イントラネット、ＷＡＮ（ワイドエリアネットワーク）、ＭＡＮ（メトロポリタンエリアネットワーク）、ＩＥＥＥ ８０２．１１ａ／ｂ／ｇ／ｎ規格に準拠する無線ネットワーク、専用線などを含む１つまたは複数の公衆またはプライベートネットワークを介して互いに接続され得る。いくつかの実施形態では、システム１００内のシステムの１つ以上は、データセンタ、サーバファームなどに実装された１つ以上の仮想サーバとして実装されてもよい。
【0046】
[0056] 図２は、フルフィルメントセンタ２００を示す。フルフィルメントセンタ２００は、注文時に顧客に出荷するためのアイテムを格納する物理的な場所の実例である。フルフィルメントセンタ（ＦＣ）２００は、多数のゾーンに分割することができ、その各々を図２に示す。これらの「ゾーン」はいくつかの実施形態ではアイテムを受け取り、アイテムを保管し、アイテムを取り出し、アイテムを出荷する処理の様々な段階の間の仮想分割と考えることができ、したがって、「ゾーン」は、図２に示されているが、ゾーンの他の分割も可能であり、いくつかの実施形態では、図２のゾーンを省略、複製、または修正することができる。
【0047】
[0057] インバウンドゾーン２０３は、図１Ａの装置１００を使用して製品を販売しようとする売り手からアイテムを受け取るＦＣ２００の領域を表す。例えば、売り手は、台車２０１を使用してアイテム２０２Ａ及び２０２Ｂを配送することができる。アイテム２０２Ａはそれ自体の出荷パレットを占有するのに十分な大きさの単一のアイテムを表すことができ、アイテム２０２Ｂは、空間を節約するために同じパレット上に一緒に積み重ねられた１組のアイテムを表すことができる。
【0048】
[0058] 作業員は、インバウンドゾーン２０３でアイテムを受け取り、コンピュータシステム（図示せず）を使用して、アイテムの破損および正当性を任意選択で検査することができる。例えば、作業員は、コンピュータシステムを使用して、アイテム２０２Ａおよび２０２Ｂの数量をアイテムの注文数量と比較することができる。数量が合致しない場合、その作業員は、アイテム２０２Ａまたは２０２Ｂのうちの１つまたは複数を拒否することができる。数量が一致すれば、作業員はそれらのアイテムを緩衝地帯２０５まで（例えば、１ドル、ハンドトラック、フォークリフト、手動で）移動させることができる。緩衝ゾーン２０５は、例えば、予測される需要を満たすのに十分な量のアイテムがピッキングゾーンにあるため、ピッキングゾーンで現在必要とされていないアイテムのための一時保管領域であってもよい。いくつかの実施形態では、フォークリフト２０６は、緩衝ゾーン２０５の周り、および入りゾーン２０３と落下ゾーン２０７との間でアイテムを移動させるように動作する。ピッキングゾーンにアイテム２０２Ａまたは２０２Ｂが必要な場合（例えば、予想される需要のため）、フォークリフトは、アイテム２０２Ａまたは２０２Ｂを落下ゾーン２０７に移動させることができる。
【0049】
[0059] ドロップゾーン２０７は、アイテムがピッキングゾーン２０９に移動される前にそれらを保管するＦＣ２００の領域であってもよい。ピッキングタスクに割り当てられた作業員（「ピッカー」）は、ピッキングゾーン内のアイテム２０２Ａおよび２０２Ｂに接近し、ピッキングゾーンのバーコードをスキャンし、モバイルデバイス（例えば、デバイス１１９Ｂ）を使用してアイテム２０２Ａおよび２０２Ｂに関連するバーコードをスキャンすることができる。次いで、ピッカーは、アイテムをピッキングゾーン２０９まで（例えば、それをカート上に置くか、またはそれを運ぶことによって）取り込むことができる。
【0050】
[0060] ピッキングゾーン２０９は、アイテム２０８が保管ユニット２１０に保管されるＦＣ２００の領域であってもよい。いくつかの実施形態では、貯蔵ユニット２１０は、物理的な棚、本棚、箱、運搬箱、冷蔵庫、冷凍庫、冷蔵庫などのうちの１つまたは複数を含むことができる。いくつかの実施形態では、ピッキングゾーン２０９は、複数のフロアに編成されてもよい。いくつかの実施形態では、作業員または機械が例えば、フォークリフト、エレベータ、コンベアベルト、カート、ハンドトラック、台車、自動ロボットもしくはデバイス、または手動を含む多数の方法で、ピッキングゾーン２０９内にアイテムを移動させることができる。例えば、ピッカーは、アイテム２０２Ａおよび２０２Ｂを降下ゾーン２０７の手押し車または台車に載せ、アイテム２０２Ａおよび２０２Ｂをピッキングゾーン２０９まで歩くことができる。
【0051】
[0061] ピッカーは、保管ユニット２１０上の特定の空間のようなピッキングゾーン２０９内の特定のスポットにアイテムを配置する（又は「収納する」）命令を受け取ることができる。例えば、ピッカーは、モバイルデバイス（例えば、デバイス１１９Ｂ）を使用してアイテム２０２Ａを走査することができる。デバイスは、例えば、通路、棚、及び位置を示す装置を使用して、ピッカーがアイテム２０２Ａを収納すべき場所を示すことができる。次に、デバイスは、アイテム２０２Ａをその位置に格納する前に、その位置でバーコードを走査するようにピッカーを促すことができる。デバイスは、（例えば、ワイヤレスネットワークを介して）図１ＡのＷＭＳ１１９のようなコンピュータシステムにデータを送信し、アイテム２０２Ａがデバイス１１９Ｂを使用してユーザによってその位置に格納されたことを示すことができる。
【0052】
[0062] ユーザが注文を置くと、ピッカーは、保管ユニット２１０から１つまたは複数のアイテム２０８を取り出すための命令をデバイス１１９Ｂ上で受け取ることができる。ピッカーは、アイテム２０８を取り出し、アイテム２０８上のバーコードを走査し、それを搬送メカニズム２１４上に置くことができる。搬送機構２１４は、スライドとして表されているが、いくつかの実施形態では、搬送機構がコンベヤーベルト、エレベータ、カート、フォークリフト、ハンドトラック、台車、カートなどのうちの１つまたは複数として実施することができる。次いで、アイテム２０８は、充填領域２１１に到達することができる。
【0053】
[0063] パッキングゾーン２１１は、アイテムがピッキングゾーン２０９から受け取られ、最終的に顧客に出荷するためにボックスまたはバッグにパッキングされる、ＦＣ２００の領域であってもよい。パッキングゾーン２１１において、受信アイテム（「リビン（ｒｅｂｉｎ）作業員」）に割り当てられた作業員は、ピッキングゾーン２０９からアイテム２０８を受信し、それがどの注文に対応するかを決定する。例えば、リビン（ｒｅｂｉｎ）作業員は、アイテム２０８上のバーコードを走査するために、コンピュータ１１９Ｃなどのデバイスを使用することができる。コンピュータ１１９Ｃは、どの注文アイテム２０８が関連付けられているかを視覚的に示すことができる。これは例えば、注文に対応する壁面２１６上の空間または「セル」を含むことができる。注文が完了すると（例えば、セルが注文のためのすべてのアイテムを含むため）、リビン（ｒｅｂｉｎ）作業員は、注文が完了したことをパッキング作業員（または「パッカー」）に示すことができる。梱包業者は、セルからアイテムを回収し、輸送のために箱または袋に入れることができる。その後、パッカーは、例えば、フォークリフト、カート、ドリー、ハンドトラック、コンベヤーベルトを介して、又は他の方法で、箱又はバッグをハブゾーン２１３に送ることができる。
【0054】
[0064] ハブゾーン２１３は、パッキングゾーン２１１から全てのボックスまたはバッグ（「荷物」）を受け取るＦＣ２００の領域であってもよい。ハブゾーン２１３内の作業員および／またはマシンは、荷物２１８を検索し、それぞれの荷物が行こうとする配送領域の一部を決定し、荷物を適切なキャンプゾーン２１５にルーティングすることができる。例えば、配送領域が２つのより小さいサブ領域を有する場合、荷物は２つのキャンプゾーン２１５のうちの１つに進む。いくつかの実施形態では、作業員またはマシンは、（例えば、デバイス１１９Ａ～１１９Ｃのうちの１つを使用して）荷物を走査して、その最終的な宛先を決定することができる。荷物をキャンプゾーン２１５にルーティングすることは、例えば、荷物が向けられている地理的エリアの一部を（例えば、郵便番号に基づいて）決定することと、地理的エリアの一部に関連付けられたキャンプゾーン２１５を決定することとを含むことができる。
【0055】
[0065] いくつかの実施形態では、キャンプゾーン２１５は、１つまたは複数の建物、１つまたは複数の物理的な空間、または１つまたは複数のエリアを備えることができ、荷物は、ルートおよび／またはサブルートに分類するためにハブゾーン２１３から受け取られる。いくつかの実施形態では、キャンプゾーン２１５がＦＣ２００から物理的に分離されているが、他の実施形態では、キャンプゾーン２１５がＦＣ２００の一部を形成することができる。
【0056】
[0066] キャンプゾーン２１５内の作業員および／またはマシンは、例えば、目的地と現存するルートおよび／またはサブルートとの照合、ルートおよび／またはサブルートごとの作業負荷の算出、時刻、出荷方法、荷物２２０を出荷する費用、荷物２２０内のアイテムに関連付けられたＰＤＤなどに基づいて、荷物２２０がどのルートおよび／またはサブルートに関連付けられるべきかを決定することができる。いくつかの実施形態では、作業員またはマシンは、（例えば、デバイス１１９Ａ～１１９Ｃのうちの１つを使用して）荷物を走査して、その最終的な宛先を決定することができる。荷物２２０が特定のルートおよび／またはサブルートに割り当てられると、作業員および／またはマシンは、出荷される荷物２２０を移動させることができる。例示的な図２において、キャンプゾーン２１５は、トラック２２２、かご２２６、および配送作業員２２４Ａおよび２２４Ｂを含む。いくつかの実施形態では、トラック２２２が配送作業員２２４Ａによって駆動されてもよく、配送作業員２２４ＡはＦＣ ２００の荷物を配信する常勤の従業員であり、トラック２２２はＦＣ ２００を所有し、リースし、または運営する同じ企業によって所有され、リースされ、または運営される。いくつかの実施形態では、自動車２２６が配送作業員２２４Ｂによって駆動されてもよく、ここで、配送作業員２２４Ｂは、必要に応じて（例えば、季節的に）送達する「屈曲」または時折の作業員である。自動車２２６は、配送作業員２２４Ｂによって所有され、リースされ、または操作され得る。
【0057】
[0067] 図３は、製品在庫を最適レベルに維持するためのコンピュータ化されたシステムを含むネットワーク化された環境３００の例示的な実施形態を示す概略のブロック図である。環境３００は、さまざまなシステムを含むことができ、その各々は、１つまたは複数のネットワークを介して互いに接続されてよい。システムは、例えばケーブルを用いた直接接続によって互いに接続されてもよい。図示のシステムは、ＦＯシステム３１１、ＦＣデータベース３１２、外部フロントエンドシステム３１３、サプライチェーン管理システム３２０、および１つまたは複数のユーザ端末３３０を含む。ＦＯシステム３１１および外部フロントエンドシステム３１３は、設計、機能、または動作において、図１Ａに関して上述したＦＯシステム１１３および外部フロントエンドシステム１０３に類似していてよい。
【0058】
[0068] ＦＣデータベース３１２は、図２に関して上述したように、ＦＣ２００での種々の活動から生じる種々のデータを収集、蓄積、および／または生成する１つまたは複数のコンピュータシステムとして実装され得る。例えば、ＦＣデータベース３１２に蓄積されるデータは、とりわけ、特定のＦＣ（例えば、ＦＣ２００）によって取り扱われるすべての製品の製品識別子（例えば、在庫管理ユニット（ＳＫＵ））、各製品の時間につれての在庫レベル、ならびに各製品の在庫切れイベントの頻度および発生を含み得る。
【0059】
[0069] いくつかの実施形態において、ＦＣデータベース３１２は、ＦＣ Ａ～Ｃに関連するデータベースを表すＦＣ Ａデータベース３１２Ａ、ＦＣ Ｂデータベース３１２Ｂ、およびＦＣ Ｃデータベース３１２Ｃを含み得る。図３には、３つのＦＣおよび対応するＦＣデータベース３１２Ａ～Ｃのみが示されているが、その数はあくまでも例示にすぎず、より多くのＦＣおよび対応する数のＦＣデータベースが存在できる。他の実施形態において、ＦＣデータベース３１２は、すべてのＦＣからのデータを収集および格納する集中型データベースであり得る。ＦＣデータベース３１２が個別のデータベース（例えば、３１２Ａ～Ｃ）を含むか、あるいは１つの集中型データベースを含むかにかかわらず、データベースは、クラウドベースのデータベースまたはオンプレミスデータベースを含むことができる。また、いくつかの実施形態において、そのようなデータベースは、１つまたは複数のハードディスクドライブ、１つまたは複数のソリッドステートドライブ、または１つまたは複数の非一時的メモリを含み得る。
【0060】
[0070] サプライチェーン管理システム（ＳＣＭ）３２０は、設計、機能、または動作において、図１Ａに関して上述したＳＣＭ１１７と同様であってよい。これに代え、あるいはこれに加えて、ＳＣＭ３２０は、本開示の実施形態によるプロセスにて特定の製品の需要のレベルを予測し、１つまたは複数の購入注文を生成するために、ＦＯシステム３１１、ＦＣデータベース３１２、および外部フロントエンドシステム３１３からのデータを集約するように構成されてよい。
【0061】
[0071] いくつかの実施形態において、ＳＣＭ３２０は、データサイエンスモジュール３２１、需要予測生成部３２２、目標在庫計画システム（ＴＩＰ）３２３、インバウンド優先順位付けおよびシャッフリングシステム（ＩＰＳ）３２４、手動注文提出プラットフォーム３２５、購入注文（ＰＯ）生成部３２６、およびレポート生成部３２７を備える。
【0062】
[0072] いくつかの実施形態において、ＳＣＭ３２０は、１つまたは複数のプロセッサ、１つまたは複数のメモリ、および１つまたは複数の入力／出力（Ｉ／Ｏ）デバイスを備えることができる。ＳＣＭ３２０は、サーバ、汎用コンピュータ、メインフレームコンピュータ、グラフィックプロセシングユニット（ＧＰＵ）などの専用コンピューティングデバイス、ラップトップ、またはこれらのコンピューティングデバイスの任意の組み合わせの形態をとることができる。これらの実施形態において、ＳＣＭ３２０の構成要素（すなわち、データサイエンスモジュール３２１、需要予測生成部３２２、ＴＩＰ３２３、ＩＰＳ３２４、手動注文提出プラットフォーム３２５、ＰＯ生成部３２６、およびレポート生成部３２７）は、１つまたは複数のメモリに格納された命令に基づいて１つまたは複数のプロセッサによって実行される１つまたは複数の機能ユニットとして実装されてよい。ＳＣＭ３２０は、スタンドアロンのシステムであってよく、あるいは、より大きなシステムの一部であってよいサブシステムの一部であってよい。
【0063】
[0073] あるいは、ＳＣＭ３２０の構成要素は、ネットワークを介して互いに通信する１つまたは複数のコンピュータシステムとして実装され得る。この実施形態において、１つまたは複数のコンピュータシステムのそれぞれは、１つまたは複数のプロセッサ、１つまたは複数のメモリ（すなわち、非一時的なコンピュータ可読媒体）、および１つまたは複数の入力／出力（Ｉ／Ｏ）デバイスを含み得る。いくつかの実施形態において、１つまたは複数のコンピュータシステムのそれぞれは、サーバ、汎用コンピュータ、メインフレームコンピュータ、ＧＰＵなどの専用コンピューティングデバイス、ラップトップ、またはこれらのコンピューティングデバイスの任意の組み合わせの形態をとることができる。
【0064】
[0074] データサイエンスモジュール３２１は、いくつかの実施形態において、ＳＣＭ３２０の他の構成要素による使用のための種々のパラメータまたはモデルを決定するように構成された１つまたは複数のコンピューティングデバイスを含み得る。例えば、データサイエンスモジュール３２１は、各製品の需要のレベルを決定する需要予測生成部３２２によって使用される予測モデルを作成することができる。いくつかの実施形態において、データサイエンスモジュール３２１は、ＦＯシステム３１１からの注文情報および外部フロントエンドシステム３１３からの一瞥ビュー（すなわち、製品のいくつかのウェブページビュー）を検索して、予測モデルをトレーニングし、将来の需要のレベルを予測することができる。注文情報は、時間につれてのアイテムの販売数、プロモーション期間におけるアイテムの販売数、および通常の期間におけるアイテムの販売数などの販売統計を含み得る。データサイエンスモジュール３２１は、販売統計、一瞥ビュー、季節、曜日、次の休日、などのパラメータに基づいて、予測モデルをトレーニングすることができる。いくつかの実施形態において、データサイエンスモジュール３２１は、ＰＯ生成部３２６によって生成されたＰＯによって注文された製品を受け取るときに図２のインバウンドゾーン２０３からデータを受け取ることができる。データサイエンスモジュール３２１は、そのようなデータを使用して、特定のサプライヤの充足率（すなわち、販売可能な状態で受け取られた製品の注文数量に対するパーセンテージ）、推定リードタイムおよび出荷期間、などのさまざまなサプライヤ統計を決定することができる。
【0065】
[0075] 需要予測生成部３２２は、いくつかの実施形態において、データサイエンスモジュール３２１によって作成された予測モデルを使用して特定の製品の需要のレベルを予測するように構成された１つまたは複数のコンピューティングデバイスを含み得る。より具体的には、予測モデルは、各製品の需要予測数量を出力することができ、需要予測数量は、所与の期間（例えば、１日）に１人または複数の顧客に販売されると予想される製品の具体的な数量である。いくつかの実施形態では、需要予測生成部３２２は、所定の期間にわたる所与の期間ごとの需要予測数量（例えば、５週間にわたる毎日の需要予測数量）を出力することができる。各々の需要予測数量は、製品在庫レベルの最適化におけるさらなる柔軟性をもたらすために、標準偏差数量（例えば、±５）または範囲（例えば、３０という最大値および２５という最小値）を含んでもよい。
【0066】
[0076] いくつかの実施形態において、ＴＩＰ３２３は、各製品の推奨注文数量を決定するように構成された１つまたは複数のコンピューティングデバイスを含み得る。ＴＩＰ３２３は、最初に製品の仮注文数量を決定し、仮注文数量を現実世界の制約で制約することにより、推奨注文数量を決定することができる。さらに、いくつかの実施形態において、ＩＰＳ３２４は、推奨注文数量に優先順位を付け、優先順位付けされた注文数量を１つまたは複数のＦＣ２００へとそれぞれのインバウンド処理能力に基づいて分配するように構成された１つまたは複数のコンピューティングデバイスを含み得る。推奨注文数量の決定、優先順位付け、および分配のためのプロセスは、図４～図６に関してより詳細に以下で説明される。
【0067】
[0077] 手動注文提出プラットフォーム３２５は、いくつかの実施形態において、１つまたは複数の手動注文に関するユーザ入力を受け取るように構成された１つまたは複数のコンピューティングデバイスを含み得る。手動注文提出プラットフォーム３２５は、図１Ａの内部フロントエンドシステム１０５などの１つまたは複数のコンピューティングデバイスを介してユーザがアクセスできるユーザインターフェースを備え得る。一態様において、手動注文は、ユーザが必要であると考え、仮注文数量、推奨注文数量、優先順位付けされた注文数量、または分配された注文数量の手動調整（例えば、特定の量だけ増やし、あるいは減らす）を可能にすることができる特定の製品の追加の数量を含み得る。別の態様において、手動注文は、ＳＣＭ３２０によって決定される注文数量の代わりに、内部ユーザによって決定される注文すべき特定の製品の総数量を含み得る。これらのユーザによって決定された注文数量をＳＣＭによって生成された注文数量と調和させる例示的なプロセスは、図５に関して以下でさらに詳細に説明される。またさらに、いくつかの実施形態において、ユーザは、手動注文を特定のＦＣに割り当てることができるように、特定のＦＣを受け取り場所として指定することができる。いくつかの実施形態においては、手動注文提出プラットフォーム３２５を介して提出された注文数量の一部分に、それらがＴＩＰ３２３またはＩＰＳ３２４によって調整（すなわち、制約）されることがないように、（例えば、注文数量のその部分に関するパラメータを更新することによって）マークを付け、あるいはフラグを立てることができる。
【0068】
[0078] いくつかの実施形態において、手動注文提出プラットフォーム３２５は、アパッチＨＴＴＰサーバ、マイクロソフトインターネットインフォメーションサービス（ＩＩＳ）、ＮＧＩＮＸ、などのソフトウェアを実行する１つまたは複数のコンピュータとして実装され得る。他の実施形態において、手動注文提出プラットフォーム３２５は、１つまたは複数のユーザ端末３３０からユーザ入力を受信および処理し、受信したユーザ入力への応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。
【0069】
[0079] いくつかの実施形態において、ＰＯ生成部３２６は、推奨注文数量またはＩＰＳ３２４による分配の結果に基づいて、１つまたは複数のサプライヤへのＰＯを生成するように構成された１つまたは複数のコンピューティングデバイスを含み得る。ＳＣＭ３２０は、この時点までに、追加の在庫を必要とする各々の製品および各々のＦＣ２００について推奨注文数量を決定していると考えられ、各々の製品について、その特定の製品を調達または製造して１つまたは複数のＦＣへと出荷する１つまたは複数のサプライヤが存在する。特定のサプライヤは、１つまたは複数の製品を供給でき、特定の製品は、１つまたは複数のサプライヤによって供給され得る。ＰＯを生成するときに、ＰＯ生成部３２６は、サプライヤへと郵送またはファックスされる紙のＰＯ、あるいはサプライヤへと送信される電子ＰＯを発行することができる。
【0070】
[0080] レポート生成部３２７は、いくつかの実施形態において、所定のプロトコルに応答して定期的にレポートを生成し、あるいはユーザ端末３３０または図１Ａの内部フロントエンドシステム１０５などを介したユーザ入力に応答してオンデマンドでレポートを生成するように構成された１つまたは複数のコンピューティングデバイスを含み得る。レポートは、特定の製品の推奨注文数量などの特定の情報を出力する単純なレポートから、履歴データの分析を必要とし、グラフで視覚化された複雑なレポートまで、さまざまであってよい。より具体的には、レポート生成部３２７は、ＴＩＰ３２３またはＩＰＳ３２４によって実行された調整の各ステップにおいて注文数量が予測数量から最終的な数量へとどのように変化したか、各ＦＣ２００のインバウンド処理能力がどれだけ利用されたかについての履歴、製品カテゴリごとの予測数量と最終的な数量との間の差（すなわち、現実世界の制限に鑑みて予測数量から減らさなければならなかった数量）、などの情報を含むレポートを生成することができる。
【0071】
[0081] いくつかの実施形態において、ユーザ端末３３０は、ＦＣで働くユーザなどの内部ユーザが手動注文提出プラットフォーム３２５またはレポート生成部３２７を介してＳＣＭ３２０にアクセスできるように構成された１つまたは複数のコンピューティングデバイスを含み得る。ユーザ端末３３０は、パーソナルコンピュータ、携帯電話、スマートフォン、ＰＤＡ、などのコンピューティングデバイスの任意の組み合わせを含み得る。いくつかの実施形態において、内部ユーザは、１つまたは複数の手動注文を提出するために、ユーザ端末３３０を使用して、手動注文提出プラットフォーム３２５によって提供されるウェブインターフェースにアクセスすることができる。
【0072】
[0082] 図４が、製品在庫を最適レベルに維持するためにインバウンド購入注文をインテリジェントに調整するための例示的なコンピュータ化されたプロセス４００の流れ図である。いくつかの実施形態において、プロセス４００は、上述のように、ＳＣＭ３２０によって他のネットワーク化されたシステム（例えば、ＦＯシステム３１１、ＦＣデータベース３１２、および外部フロントエンドシステム３１３）からの情報を使用して実行され得る。一態様において、すべてのステップは、ＴＩＰ３２３またはＩＰＳ３２４などのＳＣＭ３２０の任意の構成要素によって実行され得る。いくつかの実施形態において、ＳＣＭ３２０は、１日１回などの所定の間隔でステップ４０１～４０７を繰り返すことができる。またさらに、ＳＣＭ３２０は、以前に在庫または販売されたすべての製品または実質的にすべての製品についてプロセス４００を実行することができる。各製品に、在庫管理ユニット（ＳＫＵ）などの一意の製品識別子を関連付けることができる。
【0073】
[0083] ステップ４０１において、ＴＩＰ３２３は、需要予測生成部３２２から各製品の需要予測数量を受け取ることができる。いくつかの実施形態において、需要予測数量は、数値の表の形態であってよく、そのような表は、一方の次元においてＳＫＵによって整理され、他方の次元において所与の日について販売されると予測されるユニットの数によって整理されている。この表は、標準偏差、最大、最小、平均、などの需要予測数量の他のパラメータに向けられた追加の次元をさらに含んでもよい。あるいは、需要予測数量は、ＳＫＵによって整理され、各パラメータに向けられた値の複数のアレイの形態をとることができる。同じデータを整理する他の適切な形態が、技術的に知られているように等しく適用可能であり、本発明の範囲に含まれる。
【0074】
[0084] ステップ４０２において、ＴＩＰ３２３は、データサイエンスモジュール３２１から、製品を供給する１つまたは複数のサプライヤのサプライヤ統計データを受け取ることができる。サプライヤ統計データは、各々のサプライヤに関連する一連の情報（例えば、上述の充足率）を含み得る。いくつかの実施形態においては、特定のサプライヤについて複数組のサプライヤ統計データが存在でき、各組のデータは、そのサプライヤによって供給される特定の製品に関するデータである。
【0075】
[0085] ステップ４０３において、ＴＩＰ３２３は、ＦＣデータベース３１２から、各製品の現在の製品在庫レベルおよび現在の注文済み数量をさらに受け取ることができる。現在の製品在庫レベルは、データ検索の時点における特定の製品の瞬間的な数量を指すことができ、現在の注文済み数量は、過去に生成された１つ以上のＰＯによって注文されて、対応するＦＣへの配送を待っている特定の製品の合計数量を指すことができる。
【0076】
[0086] ステップ４０４において、ＴＩＰ３２３は、各製品の仮注文数量を決定し、かつさまざまなパラメータに基づいて仮注文数量を減らすことによって、各製品の推奨注文数量を決定することができる。いくつかの実施形態において、特定の製品の仮注文数量は、その製品の需要予測数量、カバレッジ期間、安全在庫期間、現在の在庫レベル、現在の注文済み数量、臨界比、およびケース数量のうちの少なくとも１つの関数であってよい。例えば、ＴＩＰ３２３は、式（１）
によって仮注文数量を決定することができ、ここで、Ｑｐは特定の製品の仮注文数量であり、Ｑｆｎは計算の時点からｎ日目の製品の需要予測数量であり、Ｑｃは製品の現在の在庫レベルであり、Ｑｏは現在の注文済み数量であり、Ｐｃはカバレッジ期間であり、Ｐｓは安全在庫期間であり、Ｃはケース数量である。
【数1】
によって仮注文数量を決定することができ、ここで、Ｑｐは特定の製品の仮注文数量であり、Ｑｆｎは計算の時点からｎ日目の製品の需要予測数量であり、Ｑｃは製品の現在の在庫レベルであり、Ｑｏは現在の注文済み数量であり、Ｐｃはカバレッジ期間であり、Ｐｓは安全在庫期間であり、Ｃはケース数量である。
【0077】
[0087] 本明細書において使用されるとき、カバレッジ期間は、１つのＰＯによってカバーされるように計画された時間長（例えば、日数）を指すことができ、安全在庫期間は、需要の急増または配送の遅延などの予期せぬ事象が発生した場合にＰＯがカバーしなければならない追加の時間長（例えば、追加の日数）を指すことができる。例えば、製品Ｘの需要予測数量の一例としての以下の表を考えると、Ｄ日において生成されたＰＯのカバレッジ期間は５であってよく、安全在庫期間は１であってよく、この場合、
は、３７＋３７＋３５＋４０＋４１＋３４＝２２４になると考えられる。
【数2】
は、３７＋３７＋３５＋４０＋４１＋３４＝２２４になると考えられる。
【表1】
【0078】
[0088] この数量、すなわち２２４ユニットの製品Ｘから、ＴＩＰ３２３は、現在の在庫レベル（例えば、６０ユニット）および現在の注文済み数量（例えば、４０）を差し引くことができ、結果は１２４ユニットになる。次いで、この数を、ケース数量（すなわち、箱またはパレット内のユニットの数など、製品がパッケージされてもたらされるときのユニットの数）で割り算し、整数に切り上げ、再びケース数量を掛け算することによって、ケース数量の倍数に切り上げることができ、この例では、ケース数量が例えば１０であると仮定して、結果は１３０ユニットになる。
【0079】
[0089] いくつかの実施形態において、カバレッジ期間は、対応するサプライヤがＰＯ生成の日から製品を届けるまでに要すると予想される時間長以上の所定の時間長であってよい。これに加え、あるいはこれに代えて、ＴＩＰ３２３は、曜日、予想される遅延、などの他の要因に基づいて、カバレッジ期間を調整することができる。さらに、安全在庫期間は、安全対策として仮注文数量を増やすように設計された別の所定の時間長であってよい。安全在庫期間は、需要の急増または予期せぬ出荷遅延などの不意の事象の場合の在庫切れのリスクを低減することができる。いくつかの実施形態において、ＴＩＰ３２３は、カバレッジ期間に基づいて安全在庫期間を設定することができ、例えば、カバレッジ期間が１～３日である場合に、０日の安全在庫期間が追加され、カバレッジ期間が４～６日である場合、１日が追加され、カバレッジ期間が７日を超える場合に、３日が追加される。
【0080】
[0090] 上述の仮注文数量を決定する複雑なプロセスにもかかわらず、仮注文数量は、主に顧客の需要に基づいており、現実世界の制約を考慮していない可能性がある。したがって、製品在庫を最適化するために、このような制約を考慮するためのステップが望まれる。いくつかの実施形態において、ＴＩＰ３２３は、販売統計、現在の製品在庫レベル、および現在の注文済み数量などのデータに基づいて仮注文数量を微調整するように構成された一連のルールを使用して、仮注文数量を調整することができる。
【0081】
[0091] 得られた数量、すなわち推奨注文数量を、ステップ４０５および４０６において実行される調整などのさらなる調整を伴わずに、ＰＯ生成部３２６に送信することができる。他の実施形態においては、図６、図７Ａ、および図７Ｂに関して後述されるように、得られた数量を、特定の製品に優先順位を付け、さらには／あるいは数量を１つまたは複数のＦＣへと分配するために、ＩＰＳ３２４によってさらに処理することができる。
【0082】
[0092] ステップ４０５において、ＩＰＳ３２４は、すべてのＦＣにわたる総インバウンド処理能力など、全国レベルの現実世界の制約に基づいて、推奨注文数量に優先順位を付けることができる。この優先順位付けは、２つの形態をとることができ、一方の形態は、一連のルールを利用し、他方の形態は、ロジスティック回帰モデルを利用する。２つの優先順位付けプロセスの詳細は、図６、図７Ａ、および図７Ｂに関して以下で説明される。
【0083】
[0093] ステップ４０６において、ＩＰＳ３２４は、各ＦＣのインバウンド処理能力などの地方レベルの制約に基づいて、優先順位付けされた注文数量を１つまたは複数のＦＣに分配することができる。いくつかの実施形態において、ＩＰＳ３２４は、最初に、各ＦＣの各製品の現在の製品在庫レベル、各ＦＣからの特定の製品に対する需要のレベル、などに基づいて、注文数量を各ＦＣに分配することができる。
【0084】
[0094] ＩＰＳ３２４がすべての優先順位付けされた注文数量を分配し、各製品の予定配送日を決定すると、ＦＣのうちの１つまたは複数において、特定の日の合計数量が、その特定の日のそのＦＣのインバウンド処理能力を超える結果となる可能性がある。この場合、ＩＰＳ３２４は、数量のうちのインバウンド処理能力を超える量を決定し、対応する数量を、その特定の日のそれぞれのインバウンド処理能力に達していない１つまたは複数の他のＦＣに移すことができる。この場合、ＩＰＳ３２４は、受け側のＦＣのインバウンド処理能力を結果として超えてしまわない限りにおいて、超過量を任意の適切なやり方で１つまたは複数の他のＦＣの間で分割することができる。例えば、ＩＰＳ３２４は、例えば、超過能力を残りのＦＣ間で均等に分割することができ、各ＦＣの利用可能な能力の比に基づいて、ＦＣ間で利用可能な能力の比が同じになる（例えば、すべてのＦＣがそれぞれのインバウンド処理能力の９０％に達する数量を有する）ように分割を行うことができる。いくつかの実施形態において、ＩＰＳ３２４は、超過能力のうちのより多くの部分を、能力を超えたＦＣに最も近いＦＣに移すことができ、あるいは生じ得る追加の輸送コストを最小化するやり方で各部分を調節することができる。
【0085】
[0095] ステップ４０７において、ＰＯ生成部３２６は、分配されて各ＦＣに割り当てられた注文数量に基づいて、ＰＯを生成することができる。一態様においては、複数のＰＯ生成部３２６が存在でき、その各々が特定のＦＣに関連付けられる。この場合、各ＦＣに割り当てられた特定のＰＯ生成部３２６が、自身のＦＣへと分配された注文数量について、適切なサプライヤへのＰＯを生成することができる。別の態様において、ＰＯ生成部３２６は、上述のステップ４０６において特定の数量の製品がどこに分配されたかに基づいてＰＯの配送アドレスを変更することによって、すべてのＦＣのすべてのＰＯを生成する集中型のシステムの一部であってよい。これら２つの実施形態の組み合わせも可能であり、その場合、２つ以上のＰＯ生成部３２６が存在でき、その各々が１つまたは複数のＦＣに関連付けられ、関連付けられたすべてのＦＣのＰＯの生成を担当することができる。
【0086】
[0096] 図５は、ユーザが提出した注文数量をシステムが生成した注文数量と組み合わせるための例示的なコンピュータ化されたプロセス５００の流れ図である。図３に関して上述したように、ユーザは、手動注文提出を使用して、任意の製品の１つまたは複数の手動注文を提出することができる。いくつかの実施形態において、手動注文は、需要の予期せぬ急増、サプライヤにおける問題、新製品、などのユーザによる手動注文の提出の理由を説明する１つまたは複数の理由コードを含むことができる。さらに、理由コードは、特定の手動注文が、ＴＩＰ３２３によって決定される推奨注文数量に加えて注文されるべき追加の数量を指定しているか、あるいは推奨注文数量の代わりに注文されるべき置き換えの数量を指定しているかを示すことができる。
【0087】
[0097] 特定の手動注文の理由コードが、手動注文によって指定された数量で特定の製品の対応する推奨注文数量を置き換えるべきであると示している場合、ＩＰＳ３２４は、特定の手動注文数量（ＭＯＱ５０１）で対応する推奨注文数量（ＲＯＱ５０２）を実際に置き換えるべきかどうかについて、プロセス５００を使用することができる。
【0088】
[0098] ステップ５０３において、ＩＰＳ３２４は、手動注文に数量の調整を防止するフラグが立てられているかどうかを判断することができる。フラグが立てられている場合、ステップ５０５においてＲＯＱ５０２の代わりにＭＯＱ５０１が使用され、特定の製品の推奨注文数量は、ステップ５０７においてＭＯＱ５０１に等しくなるように設定される。
【0089】
[0099] ステップ５０３における判断が否である場合、ＩＰＳ３２４は、ＲＯＱ５０２がＭＯＱ５０１よりも多いか否かをさらに判断することができる。否である（すなわち、ＭＯＱ５０１がＲＯＱ５０２よりも多い）場合、ステップ５０５においてＲＯＱ５０２の代わりにＭＯＱ５０１が使用され、特定の製品の推奨注文数量は、ステップ５０７においてＭＯＱ５０１に等しくなるように設定される。ステップ５０４における判断が肯定である（すなわち、ＲＯＱ５０２がＭＯＱ５０１よりも多い）場合、ステップ５０６においてＭＯＱ５０１の代わりにＲＯＱ５０２が使用され、ステップ５０７において特定の製品の推奨注文数量は変更されない。
【0090】
[0100] 図６が、仮注文数量に優先順位を付けた結果を示す１対の例示的なグラフであり、グラフ６００Ａは、図４のステップ４０５におけるＩＰＳ３２４による優先順位付けの前の注文数量を示し、グラフ６００Ｂは、優先順位付けの後の注文数量を示している。
【0091】
[0101] グラフ６００Ａおよび６００Ｂを全体的に参照すると、ＩＰＳ３２４は、特定の日付、すなわち受け取り日（Ｄ日）に関する製品の総数量をシミュレートすることができ、これは、その日付に届けられるようにスケジュールされ、あるいはその日付の需要を満たすために必要になると判断される製品の数量（例えば、推奨注文数量）を含むことができる。このシミュレーションは、受け取り日よりも所定の日数だけ前の日（すなわち、シミュレーション日またはＤ－Ｘ）に行われ得る。受け取り日に関して、対応するインバウンド処理能力ＦＣ Ａ ｃａｐ６０１、ＦＣ Ｂ ｃａｐ６０２、およびＦＣ Ｃ ｃａｐ６０３を有する１つまたは複数のＦＣ（例えば、ＦＣ Ａ～Ｃ）が存在し得る。各ＦＣのインバウンド処理能力は、ＦＣの作業員の数、利用可能な保管スペース、などといったいくつかの要因に基づき得る。図６には３つのＦＣだけが示されているが、この数はあくまでも例示にすぎず、ＩＰＳ３２４は、必要に応じてより多数またはより少数のＦＣを考慮することができる。すべてのインバウンド処理能力の合計が、合計インバウンド処理能力６０４を規定し得る。この能力を超える製品の数量は、対応するＦＣによる処理がスケジュールどおりの販売に間に合わないかもしれない。
【0092】
[0102] グラフ６００Ａを参照すると、受け取り日に関する製品の合計数量は、本明細書において合計ＲＯＱ（Ｄ－１）６１１Ａと称される受け取り日の前の日（すなわち、Ｄ－１）について決定されたすべての推奨注文数量（ＲＯＱ）の合計、本明細書において合計ＲＯＱ（Ｄ）６１２Ａと称される受け取り日について決定されたすべてのＲＯＱの合計、および本明細書において合計オープンＰＯ６１３と称される受け取り日に届けられるようにスケジュールされたすべてのオープン購入注文の合計を少なくとも含み得る。いくつかの実施形態において、合計数量は、該当する場合、製品の一部についての数量の全部または一部を例外として除外することができる。
【0093】
[0103] しかしながら、合計数量は、サプライヤによって届けられた製品の一部が販売不可能（例えば、破損、紛失、欠陥、など）である可能性があるため、受け取り日に関する製品の正確な推定でない可能性がある。したがって、ＩＰＳ３２４は、数量のより現実的な推定を得るために、合計数量に充足率を適用することができる。本明細書において使用されるとき、充足率は、サプライヤ統計データの一部としてデータサイエンスモジュール３２１から決定されるパラメータであり得る。いくつかの実施形態において、充足率は、注文数量に対する販売可能な状態で受け取った製品のパーセンテージに基づくことができる。例えば、特定のサプライヤが供給する特定の製品について６０％という充足率は、平均で、そのサプライヤによって届けられる製品の６０％のみが販売可能な状態で到着することを示す。いくつかの実施形態において、充足率は、とりわけ、製品の脆弱性（例えば、傷みやすい、壊れやすい、など）、曜日（すなわち、週末をまたぐ配送期間を有するＰＯは、配送により長い時間を要する可能性があり、したがって製品の損傷のリスクが高まるため）、サプライヤの信頼度（例えば、不良品）、などに基づいて変動し得る。
【0094】
[0104] いくつかの実施形態において、ＩＰＳ３２４は、データサイエンスモジュール３２１によって決定されたサプライヤ統計データから充足率を決定することができる。ＩＰＳ３２４は、サプライヤ統計データから特定の製品の過去の注文数量および実際に受け取った数量を抽出し、過去の注文数量と実際に受け取った数量との間の比の履歴傾向（例えば、移動平均）を決定することによって、充足率を決定することができる。いくつかの実施形態において、ＩＰＳ３２４またはデータサイエンスモジュール３２１は、新たな注文を受け取ると定期的に充足率を更新することができる。
【0095】
[0105] グラフ６００Ａに戻ると、合計ＲＯＱ（Ｄ－１）６１１Ａ、合計ＲＯＱ（Ｄ）６１２Ａ、および合計オープンＰＯ６１３を含む合計数量は、充足率適用後（ＦＲＡ）数量になるように調整され、ＦＲＡ数量は、合計ＦＲＡ ＲＯＱ（Ｄ－１）６２１Ａ、合計ＦＲＡ ＲＯＱ（Ｄ）６２２Ａ、および合計ＦＲＡオープンＰＯ６２３を含む。合計インバウンド処理能力６０４を超える数量（すなわち、削減目標６３０）は、数量のうち、ＩＰＳ３２４が図７Ａおよび図７Ｂに関して後述される一連のルールを使用して特定の製品に他の製品よりも高い優先順位を付けることによって削減しなければならない量であり得る。
【0096】
[0106] 優先順位付け後の数量であるグラフ６００Ｂを参照すると、優先順位付けはインバウンド処理能力に影響を及ぼさないため、ＦＣ Ａ ｃａｐ６０１、ＦＣ Ｂ ｃａｐ６０２、ＦＣ Ｃ ｃａｐ６０３を含む合計インバウンド処理能力６０４は、グラフ６００Ａのものと同一である。同様に、合計オープンＰＯ６１３および合計ＦＲＡオープンＰＯ６２３は、すでに注文された注文による数量は優先順位付けによって調整されることがないため、同じままであり得る。他方で、合計ＲＯＱ（Ｄ－１）６１１Ａ、合計ＲＯＱ（Ｄ）６１２Ａ、合計ＦＲＡ ＲＯＱ（Ｄ－１）６２１Ａ、および合計ＦＲＡ ＲＯＱ（Ｄ）６２２Ａは、対応する優先順位付けされた注文数量（ＰＯＱ）によって、合計ＰＯＱ（Ｄ－１）６１１Ｂ、合計ＰＯＱ（Ｄ）６１２Ｂ、合計ＦＲＡ ＰＯＱ（Ｄ－１）（図示されていない）、および合計ＦＲＡ ＰＯＱ（Ｄ）６２２Ｂと置き換えられる。いくつかの実施形態においては、合計ＦＲＡ ＰＯＱ（Ｄ－１）６２１Ｂおよび／または合計ＦＲＡ ＰＯＱ（Ｄ）６２２Ｂを、例えばグラフ６００Ｂには合計ＦＲＡ ＰＯＱ（Ｄ－１）が存在しないことにより、図示のように０に減らすことができる。ＩＰＳ３２４による優先順位付けの結果として、グラフ６００Ｂの合計の優先順位付けされた数量は、グラフ６００Ａに示される合計の数量と比べて実質的に減少し、優先順位付け後の合計ＦＲＡ数量は、合計インバウンド処理能力６０４よりも少ない。
【0097】
[0107] 図７Ａおよび図７Ｂは、それぞれ図４のステップ４０５において実行されるようにＲＯＱに優先順位を付ける表７００Ａおよび７００Ｂである。ルールを、上述のＴＩＰ３２３によって決定された各ＲＯＱに、製品ごとのやり方で適用することができる。
【0098】
[0108] 図７Ａを参照すると、一連のルールは、数量が図４のステップ４０４においてＴＩＰ３２３によって決定されたか、あるいは手動注文提出プラットフォーム３２５を介してユーザによって提出されたかに基づいて、各ＲＯＱに適用される表７００Ａに示されるルールを含むことができる。
【0099】
[0109] 最初に、ＴＩＰによって生成されたＲＯＱについて、ＩＰＳ３２４は、ルール７０１を適用して、休日のＰＯステージングを停止し、次のＰＯの到着日までのカバレッジ期間を満たすために注文に切り替えることができる。ＰＯステージングは、休日または割引期間などの特別な期間を見越して需要予測数量が急激に増加する場合にインバウンド注文を平滑化するために使用されるプロセスであってよい。ＰＯステージングがオンである場合、数量の増加を複数のＰＯに分散させるために、ＲＯＱが通常よりも高くなる可能性がある。したがって、ＩＰＳ３２４は、ＲＯＱを通常のレベルへと下げるために、ＰＯステージングをオフにすることができる。
【0100】
[0110] 合計ＦＲＡ ＰＯＱ（図６で上述）が依然としてすべてのＦＣの合計インバウンド処理能力６０４を超える場合、ＩＰＳ３２４は、ＴＩＰによって生成されたＲＯＱにルール７０２を適用し、安全在庫期間に関連するＲＯＱのすべての部分が削除されるか、あるいは合計ＦＲＡ ＰＯＱが合計インバウンド処理能力６０４を下回るか、のどちらか早い方が生じるまで、対応する安全在庫期間を短縮することができる。ＩＰＳ３２４は、すべてのＴＩＰによって生成されたＲＯＱについて安全在庫期間を均一に短縮することができ、あるいはすべての安全在庫期間が除去され、もしくは合計ＦＲＡ ＰＯＱが合計インバウンド処理能力６０４を下回るまで、特定の製品の安全在庫期間を短縮し、その後に順次に他の製品の安全在庫期間を短縮することができる。
【0101】
[0111] 合計ＦＲＡ ＰＯＱがルール７０２の後も依然として合計インバウンド処理能力６０４を超える場合、ＩＰＳ３２４はルール７０３Ａを適用し、すべてのＲＯＱが除去されるか、あるいは合計ＦＲＡ ＰＯＱが合計インバウンド処理能力６０４を下回るか、のどちらか早い方が生じるまで、ＲＯＱを所定のパーセンテージで削減することができる。ルール７０２と同様に、ＩＰＳ３２４は、すべてのＴＩＰによって生成されたＲＯＱについて所定のパーセンテージで均一にＲＯＱを減らすことができ、あるいはすべてのＲＯＱが除去され、もしくは合計ＦＲＡ ＰＯＱが合計インバウンド処理能力６０４を下回るまで、特定の製品のＲＯＱを減らし、その後に順次に他の製品のＲＯＱを減らすことができる。
【0102】
[0112] またさらに、合計ＦＲＡ ＰＯＱが依然として合計インバウンド処理能力６０４を超える場合、ＩＰＳ３２４は、ユーザによって提出されたＲＯＱ（すなわち、上述の図５のステップ５０７においてＴＩＰによって生成されたＲＯＱを置き換えたＭＯＱ）にルール７０３Ｂを適用し、すべてのＲＯＱが除去されるか、あるいは合計ＦＲＡ ＰＯＱが合計インバウンド処理能力６０４を下回るか、のどちらか早い方が生じるまで、ＲＯＱを別の所定のパーセンテージで削減することができる。ルール７０２および７０３Ａと同様に、ＩＰＳ３２４は、ＲＯＱを均一に削減しても、あるいは順番に削減してもよい。しかしながら、フラグが立てられた手動注文からのユーザによって提出されたＲＯＱは、ルール７０４によって指示されるとおり、削減することができない。
【0103】
[0113] 図７Ｂを参照すると、表７００Ｂは、ＲＯＱの優先順位付けのための別の一連の例示的なルールを列挙している。表６００の例示的なルールの各々は、表６００の第１の列に示された優先順位の並びにて以下で説明される。しかしながら、一連のルール、それらのそれぞれの優先順位、またはそれらにおける値およびしきい値のいずれも、あくまでも例示にすぎず、他のルール、優先順位、または値も、開示される実施形態の範囲内にある。いくつかの実施形態において、ＩＰＳ３２４は、或る特定のルールを、次のルールの適用を開始する前に、所与の受け取り日についての優先順位付け後の合計注文数量が合計インバウンド処理能力を下回るまで、ルールに該当するすべての製品のＲＯＱに適用することができる。
【0104】
[0114] 最初の問題として、１つまたは複数のカテゴリ（例えば、Ａ、Ｂ、Ｃ、Ｄ、Ｅ１、Ｅ２、Ｅ３、およびＦ）に分割された製品のＲＯＱを、別のパラメータに基づいて別の組へとグループ化することができる。一態様において、表７００Ｂに見られるグループＡおよびＢを、カテゴリに基づいて指定することができ、カテゴリＡ～Ｅ２の製品のＲＯＱがグループＡと見なされ、カテゴリＥ３およびＦの製品のＲＯＱはグループＢと見なされる。別の態様において、現時点において在庫がある製品のＲＯＱが非ＯＯＳ（在庫切れではない）と見なされ、在庫切れの製品のＲＯＱはＯＯＳと見なされる。さらなる態様において、図５のステップ５０５において決定された手動注文に基づいたＲＯＱを、例えば、特定の種類のプロモーション（例えば、ギフト、Ｃ１、Ｇｏｌｄ Ｂｏｘ）または他のプロモーションあるいはソーシャルメディアを通じて受け取った注文など、提出の理由に基づいて異なる組に分割することができる。さらに、ＳＣＭ３２０は、最小注文数量の組、すなわちＭＩＮ ＲＯＱおよびＭＩＮ ＤＯＣを含み得る。ＭＩＮ ＲＯＱは、ベンダーの要件（例えば、注文の最小数量）に基づいて製品ごとに事前に設定されてよいＲＯＱの最小数量であり得る。他方で、ＭＩＮ ＤＯＣは、予測される需要と、対応するＲＯＱがカバーするようにスケジュールされている日数とに基づいて決定される最小数量であり得る。
【0105】
[0115] ルール１、２．１、および２．２を参照すると、ＩＰＳ３２４は、ＯＯＳグループＡの製品のＭＩＮ ＲＯＱの予定配送日（ＥＤＤ）をシフトさせることができる。同様に、ルール２．２に関して、ＩＰＳ３２４は、非ＯＯＳグループＡの製品のＭＩＮ ＲＯＱのＥＤＤをシフトさせることができる。いくつかの実施形態においては、非ＯＯＳグループＡの製品を、プロモーション中の製品およびプロモーション中でない製品（すなわち、非プロモ）にさらに分割でき、プロモーション中の非ＯＯＳグループＡの製品のＲＯＱは、ルール２．１に関してゼロに削減される。ルール３を参照すると、ＩＰＳ３２４は、ＯＯＳグループＢの製品のＲＯＱをＭＩＮ ＲＯＱに削減することができる。
【0106】
[0116] 次に、ルール４に関して、ＩＰＳ３２４は、それぞれのＭＩＮ ＤＯＣよりも大きいグループＡのすべての製品のＲＯＱをＭＩＮ ＲＯＱへと削減することができる。いくつかの実施形態において、ＩＰＳ３２４は、それぞれのＭＩＮ ＲＯＱに達するか、あるいは所与の受け取り日に関する優先順位付け後の合計注文数量が合計インバウンド処理能力を下回るまで、該当の各製品のＲＯＱを１０％削減することができる。
【0107】
[0117] ルール５～８に関して、ＩＰＳ３２４は、下位のカテゴリ（例えば、カテゴリＤ）の製品が最初に削減されるように逆順でカテゴリＡ～Ｄの製品のＰＯステージングをオフにすることができる。
【0108】
[0118] ルール９を参照すると、ＩＰＳ３２４は、それぞれのＭＩＮ ＤＯＣよりも大きいグループＢのすべての非ＯＯＳ製品のＲＯＱをゼロに削減することができる。また、ルール１０および１１に関して、ＩＰＳ３２４は、ルール５～８の場合と同様に、カテゴリＥおよびＦの製品のＰＯステージングをオフにすることができる。
【0109】
[0119] ルール１２～１４を参照すると、ＩＰＳ３２４は、対応する手動注文がソーシャルメディアを通じて受信されたか、あるいはプロモーションのために受信されたかに基づいて、それぞれのＭＩＮ ＲＯＱに達するまで手動注文ＲＯＱを１０％削減することができる。
【0110】
[0120] ルール１５を参照すると、ＩＰＳ３２４は、それぞれのＭＩＮ ＤＯＣよりも大きいグループＢのすべての製品のＲＯＱをＭＩＮ ＲＯＱへと削減することができる。
【0111】
[0121] 次に、ルール１６および１７を参照すると、優先順位付け後の合計注文数量が依然として合計インバウンド処理能力よりも大きい場合、ＩＰＳ３２４は、フロントローディングまたはリベートボリューム注文に関して受け取った手動注文からの手動注文ＲＯＱを１０％削減することができる。それでも依然として合計インバウンド処理能力を満たすには不充分である場合、ＩＰＳ３２４は、ルール１８および１９に関して、新たな製品および他のすべての製品について受け取った手動注文からのすべての手動注文ＲＯＱをゼロに減らすことができる。
【0112】
[0122] いくつかの実施形態において、ＩＰＳ３２４は、図７Ａおよび図７Ｂに関して上述したルールの代わりに、各製品に割り当てられた一式の緊急度スコアに基づいて、異なる製品の推奨注文数量に優先順位を付けることができる。例えば、ＩＰＳ３２４は、緊急度スコアに基づいて製品ごとに推奨注文数量を並べ替え、対応する現在の在庫レベルに基づいて数量をさらに調整し、高い優先順位の製品から低い優先順位の製品へと順番に製品を注文することができる。いくつかの実施形態において、緊急度スコアは、機械学習モデルを通じて決定することができ、機械学習モデルは、データサイエンスモジュール３２１からのデータでトレーニングされ、緊急度スコアは、機械学習モデルのロジット値である。ロジット値は、技術的に知られているモデルの非正規化または生の予測または確率値を指す。例えば、ロジット値を
と表すことができ、ここでＰは特定の事象が発生する確率である。機械学習モデルは、勾配ブースティングマシン、ｋ最近傍（ｋＮＮ）モデル、最尤（ＭＬ）モデル、サポートベクターマシン（ＳＶＭ）、などの適切なモデルのうちの任意の１つであってよい。
【数3】
と表すことができ、ここでＰは特定の事象が発生する確率である。機械学習モデルは、勾配ブースティングマシン、ｋ最近傍（ｋＮＮ）モデル、最尤（ＭＬ）モデル、サポートベクターマシン（ＳＶＭ）、などの適切なモデルのうちの任意の１つであってよい。
【0113】
[0123] いくつかの実施形態において、機械学習モデルは、式（１）
緊急度レベル＝α＋β１・ｏｒｄｅｒ ｆｒｅｑｕｅｎｃｙ＋β２・ｆｕｌｌｆｉｌｌｍｅｎｔ ｒａｔｉｏ＋β３・ｌｅａｄ ｔｉｍｅ＋β４・（ｃｕｒｒｅｎｔ ｉｎｖｅｎｔｏｒｙ＋ＦＲＡ ｏｐｅｎ ｏｒｄｅｒ）＋β５・ｕｎｉｔ＋β６・ｔｏｐ ＳＫＵ＋β７・ｃａｔｅｇｏｒｙ＋β８・σｕｎｉｔｓ ｓｏｌｄ＋β９・ｄｅｍａｎｄ ｆｏｒｅｃａｓｔ ｑｕａｎｔｉｔｙ＋β１０・ｈｏｕｒｌｙ ｏｕｔ ｏｆ ｓｔｏｃｋ ｆｒｅｑｕｅｎｃｙ＋ε （１）
によって定義されるロジスティック回帰モデルであってよく、ここでαは切片であり、εは誤差項であり、βｎは各変数の重みである。いくつかの実施形態において、変数は、特定の製品が注文される頻度であるｏｒｄｅｒ ｆｒｅｑｕｅｎｃｙ、上述の充足率であるｆｕｌｌｆｉｌｌｍｅｎｔ ｒａｔｉｏ、対応するサプライヤが製品の出荷に要する期間であるｌｅａｄ ｔｉｍｅ、
現在の製品在庫レベルであるｃｕｒｒｅｎｔ ｉｎｖｅｎｔｏｒｙ、充足率適用後のオープンＰＯ数量であるＦＲＡ ｏｐｅｎ ｏｒｄｅｒ、ビジネス戦略に基づいて割り当てられた分類であるｕｎｉｔ、製品が優先順位付けされた製品のグループに属するかどうかの表示であるｔｏｐ ＳＫＵ、製品のカテゴリであるｃａｔｅｇｏｒｙ（例えば、カテゴリＡ～Ｆ）、販売されたユニットの標準偏差であるσｕｎｉｔｓ ｓｏｌｄ、上述の需要予測数量であるｄｅｍａｎｄ ｆｏｒｅｃａｓｔ ｑｕａｎｔｉｔｙ、および製品が在庫切れになる一時間ごとの頻度であるｈｏｕｒｌｙ ｏｕｔ ｏｆ ｓｔｏｃｋ ｆｒｅｑｕｅｎｃｙを含むことができる。モデルを、より多数またはより少数の変数ならびに対応する数の重みを使用して定義してもよい。モデルを、ＳＣＭ３２０によって決定されたデータを使用してトレーニングすることができる。
緊急度レベル＝α＋β１・ｏｒｄｅｒ ｆｒｅｑｕｅｎｃｙ＋β２・ｆｕｌｌｆｉｌｌｍｅｎｔ ｒａｔｉｏ＋β３・ｌｅａｄ ｔｉｍｅ＋β４・（ｃｕｒｒｅｎｔ ｉｎｖｅｎｔｏｒｙ＋ＦＲＡ ｏｐｅｎ ｏｒｄｅｒ）＋β５・ｕｎｉｔ＋β６・ｔｏｐ ＳＫＵ＋β７・ｃａｔｅｇｏｒｙ＋β８・σｕｎｉｔｓ ｓｏｌｄ＋β９・ｄｅｍａｎｄ ｆｏｒｅｃａｓｔ ｑｕａｎｔｉｔｙ＋β１０・ｈｏｕｒｌｙ ｏｕｔ ｏｆ ｓｔｏｃｋ ｆｒｅｑｕｅｎｃｙ＋ε （１）
によって定義されるロジスティック回帰モデルであってよく、ここでαは切片であり、εは誤差項であり、βｎは各変数の重みである。いくつかの実施形態において、変数は、特定の製品が注文される頻度であるｏｒｄｅｒ ｆｒｅｑｕｅｎｃｙ、上述の充足率であるｆｕｌｌｆｉｌｌｍｅｎｔ ｒａｔｉｏ、対応するサプライヤが製品の出荷に要する期間であるｌｅａｄ ｔｉｍｅ、
現在の製品在庫レベルであるｃｕｒｒｅｎｔ ｉｎｖｅｎｔｏｒｙ、充足率適用後のオープンＰＯ数量であるＦＲＡ ｏｐｅｎ ｏｒｄｅｒ、ビジネス戦略に基づいて割り当てられた分類であるｕｎｉｔ、製品が優先順位付けされた製品のグループに属するかどうかの表示であるｔｏｐ ＳＫＵ、製品のカテゴリであるｃａｔｅｇｏｒｙ（例えば、カテゴリＡ～Ｆ）、販売されたユニットの標準偏差であるσｕｎｉｔｓ ｓｏｌｄ、上述の需要予測数量であるｄｅｍａｎｄ ｆｏｒｅｃａｓｔ ｑｕａｎｔｉｔｙ、および製品が在庫切れになる一時間ごとの頻度であるｈｏｕｒｌｙ ｏｕｔ ｏｆ ｓｔｏｃｋ ｆｒｅｑｕｅｎｃｙを含むことができる。モデルを、より多数またはより少数の変数ならびに対応する数の重みを使用して定義してもよい。モデルを、ＳＣＭ３２０によって決定されたデータを使用してトレーニングすることができる。
【0114】
[0124] ひとたびモデルがトレーニングされると、特定の製品の緊急度スコアを
によって得ることができ、ここでＰ（ｘ）は、式（２）
によって与えられる。
式（２）において、ｚは、上述のトレーニング後のモデルであり、Ｐ（ｘ）は、ｘｎが与えられた場合に特定の製品が緊急である確率であり、ここでｘｎは、特定の製品の注文頻度およびリードタイムなどの変数である。
【数4】
によって得ることができ、ここでＰ（ｘ）は、式（２）
【数5】
によって与えられる。
式（２）において、ｚは、上述のトレーニング後のモデルであり、Ｐ（ｘ）は、ｘｎが与えられた場合に特定の製品が緊急である確率であり、ここでｘｎは、特定の製品の注文頻度およびリードタイムなどの変数である。
【0115】
[0125] 個々の製品の緊急度スコアが決定されると、ＩＰＳ３２４は、それらのスコアを使用して優先順位付けを行い、合計ＦＲＡ ＰＯＱが合計インバウンド処理能力６０４を下回るまで、図７Ａに記載の一連のルールに基づいて、スコアの順序で各製品のＲＯＱを削減することができる。
【0116】
[0126] 本開示を、本開示の特定の実施形態を参照して提示および説明してきたが、本開示を、修正を必要とせずに、他の環境において実施できることを、理解できるであろう。以上の説明は、例示の目的で提示されている。以上の説明は、すべてを網羅するものではなく、開示された正確な形態または実施形態に限定されない。本明細書を検討し、開示された実施形態を実施することで、修正および調整が当業者にとって明らかであろう。さらに、本開示の実施形態の態様は、メモリに格納されるものとして説明されているが、これらの態様を、例えばハードディスクまたはＣＤ－ＲＯＭなどの二次記憶デバイス、あるいは他の形態のＲＡＭまたはＲＯＭ、ＵＳＢ媒体、ＤＶＤ、Ｂｌｕ－ｒａｙ、または他の光ドライブ媒体などの他の種類のコンピュータ可読媒体に格納してもよいことを、当業者であれば理解できるであろう。
【0117】
[0127] 記載された説明および開示された方法に基づくコンピュータプログラムは、熟練した開発者の技術の範囲内である。さまざまなプログラムまたはプログラムモジュールが、当業者に知られた技術のいずれかを使用して作成可能であり、あるいは既存のソフトウェアに関連して設計可能である。例えば、プログラム部分またはプログラムモジュールを、．Ｎｅｔ Ｆｒａｍｅｗｏｒｋ、．Ｎｅｔ Ｃｏｍｐａｃｔ Ｆｒａｍｅｗｏｒｋ（および、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｃ、などの関連の言語）、Ｊａｖａ、Ｃ＋＋、Ｏｂｊｅｃｔｉｖｅ－Ｃ、ＨＴＭＬ、ＨＴＭＬ／ＡＪＡＸの組み合わせ、ＸＭＬ、またはＪａｖａアプレットを埋め込んだＨＴＭＬにて設計でき、あるいはこれらによって設計することができる。
【0118】
[0128] さらに、例示的な実施形態を本明細書において説明してきたが、本開示に基づいて、同等の要素、修正、省略、（例えば、種々の実施形態にまたがる態様の）組み合わせ、適応、および／または変更を有するあらゆるすべての実施形態の範囲を、当業者であれば理解できるであろう。請求項中の限定事項は、請求項中で使用されている文言に基づいて広く解釈されるべきであり、本明細書に記載され、あるいは本出願の審査の最中に説明される例に限定されない。例を、排他的であると解釈すべきではない。さらに、開示された方法の各ステップは、ステップを並べ替えること、および／またはステップを挿入または削除することを含む任意のやり方で変更可能である。したがって、本明細書および例は、あくまでも例示として考慮されるように意図され、真の範囲および精神は、以下の特許請求の範囲およびそれらの均等物の全範囲によって示される。
【図1A】
【図1B】
【図1C】
【図1D】
【図1E】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
