(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-08-25
(45)【発行日】2023-09-04
(54)【発明の名称】コンピュータ化されたバランスの取れた配送ルート割り当ておよびインセンティブ構造のためのシステムおよび方法
(51)【国際特許分類】
G06Q 10/08 20230101AFI20230828BHJP
【FI】
G06Q10/08
(21)【出願番号】P 2020569157
(86)(22)【出願日】2020-09-21
(86)【国際出願番号】 IB2020058794
(87)【国際公開番号】W WO2021099855
(87)【国際公開日】2021-05-27
【審査請求日】2021-04-23
(32)【優先日】2019-11-21
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520244544
【氏名又は名称】クーパン コーポレイション
(74)【代理人】
【識別番号】230104019
【氏名又は名称】大野 聖二
(74)【代理人】
【識別番号】100131451
【氏名又は名称】津田 理
(74)【代理人】
【識別番号】100167933
【氏名又は名称】松野 知紘
(74)【代理人】
【識別番号】100174137
【氏名又は名称】酒谷 誠一
(74)【代理人】
【識別番号】100184181
【氏名又は名称】野本 裕史
(72)【発明者】
【氏名】リ,スン ソン
(72)【発明者】
【氏名】キム,スン ハン
(72)【発明者】
【氏名】レン,エリク
(72)【発明者】
【氏名】チン,イン
【審査官】毛利 太郎
(56)【参考文献】
【文献】米国特許第10467562(US,B1)
【文献】特開2003-002444(JP,A)
【文献】特許第6298917(JP,B1)
【文献】特開2018-081685(JP,A)
【文献】特開2013-254255(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
出勤割り当てのためのコンピュータ実装システムであって、当該システムは、
命令を格納するメモリと、
前記命令を実行して、
データベースから、複数の配送ルートおよび、前記配送ルートの一部である、複数の配送サブルートを取得し、
前記配送サブルートに割り振られたパッケージ数を計算し、
第1の入力として、配送に対応可能な作業員の人数およびタイプを受け取り、前記タイプが分類特性または効率特性の少なくとも1つを含み、
追加の配達を有する複数のサブルートに複数の作業員を割り当てることによって配送サブルートを変更し、追加の配達を有するサブルートの前記割り当てが、前記複数の作業員に割り当てられた荷物または宛先のベースライン数およびルートの難易度に基づくものであり、前記ベースライン
数は、配達作業員ベースで各ルートに対して生成され、
前記分類特性、受け取った第1の入力、および前記ルートの難易度に基づいて、複数の候補ルートを生成し、
前記変更された配送サブルートのうちの少なくとも1つを、配送作業員と関連付けられた電子デバイスに転送する
ように構成された少なくとも1つのプロセッサと
を含む、出勤割り当てのためのコンピュータ実装システム。
【請求項2】
第2の入力として、1つまたは複数のボリューム要求を受け取ることをさらに含む、請求項1に記載の出勤割り当てのためのコンピュータ実装システム。
【請求項3】
前記第1
の入力が、パッケージ分配および出勤値をさらに含み、前記第2
の入力が、配達のためのより多くのパッケージを要求する前記1つまたは複数のボリューム要求をさらに含む、請求項2に記載の出勤割り当てのためのコンピュータ実装システム。
【請求項4】
前記作業員を効率ランキングが割り当てられた複数のグループに割り当てることをさらに含む、請求項1に記載の出勤割り当てのためのコンピュータ実装システム。
【請求項5】
追加の配達に追加の支払いを提供することをさらに含む、請求項1に記載の出勤割り当てのためのコンピュータ実装システム。
【請求項6】
前記作業員の前記効率特性が、前記ベースライン数からの仕事量増加のパーセントに対応する、請求項1に記載の出勤割り当てのためのコンピュータ実装システム。
【請求項7】
追加の配達を有する複数のサブルートに前記複数の作業員を割り当てることが、各サブルートにおける宛先の密度および宛先の数量にさらに基づくものである、請求項1に記載の出勤割り当てのためのコンピュータ実装システム。
【請求項8】
前記システムが追加の配達を自動的に割り当てる、請求項1に記載の出勤割り当てのためのコンピュータ実装システム。
【請求項9】
前記システムが、過去70日間の1時間あたりの平均宛先数の履歴データを利用して、ルートの難易度および前記ベースライン数を決定する、請求項1に記載の出勤割り当てのためのコンピュータ実装システム。
【請求項10】
出勤割り当てのためのコンピュータ実装方法であって、当該方法は、
データベースから、複数の配送ルートおよび、前記配送ルートの一部である、複数の配送サブルートを取得することと、
前記配送サブルートに割り振られたパッケージ数を計算することと、
第1の入力として、配送に対応可能な作業員の人数およびタイプを受け取ることであって、前記タイプが分類特性または効率特性の少なくとも1つを含む、ことと、
追加の配達を有する複数のサブルートに複数の作業員を割り当てることによって配送サブルートを変更することであって、追加の配達を有するサブルートの前記割り当てが、前記複数の作業員に割り当てられた荷物または宛先のベースライン数およびルートの難易度に基づくものであり、前記ベースライン
数は、配達作業員ベースで各ルートに対して生成されることと、
前記分類特性、受け取った第1の入力、および前記ルートの難易度に基づいて、複数の候補ルートを生成することと、
前記変更された配送サブルートのうちの少なくとも1つを、配送作業員と関連付けられた電子デバイスに転送することと
を含む、出勤割り当てのためのコンピュータ実装方法。
【請求項11】
第2の入力として、1つまたは複数のボリューム要求を受け取ることをさらに含む、請求項10に記載の出勤割り当てのためのコンピュータ実装方法。
【請求項12】
前記第1
の入力が、パッケージ分配および出勤値をさらに含み、前記第2
の入力が、配達のためのより多くのパッケージを要求する前記1つまたは複数のボリューム要求をさらに含む、請求項11に記載の出勤割り当てのためのコンピュータ実装方法。
【請求項13】
前記作業員を効率ランキングが割り当てられた複数のグループに割り当てることをさらに含む、請求項10に記載の出勤割り当てのためのコンピュータ実装方法。
【請求項14】
追加の配達に追加の支払いを提供することをさらに含む、請求項10に記載の出勤割り当てのためのコンピュータ実装方法。
【請求項15】
前記作業員の前記効率特性が、前記ベースライン数からの仕事量増加のパーセントに対応する、請求項10に記載の出勤割り当てのためのコンピュータ実装方法。
【請求項16】
追加の配達を有する複数のサブルートに前記複数の作業員を割り当てることが、各サブルートにおける宛先の密度および宛先の数量にさらに基づくものである、請求項10に記載の出勤割り当てのためのコンピュータ実装方法。
【請求項17】
前記方法が、過去70日間の1時間あたりの平均宛先数の履歴データを利用して、ルートの難易度および前記ベースライン数を決定する、請求項10に記載の出勤割り当てのためのコンピュータ実装方法。
【請求項18】
地理データおよび配達履歴データを含み、前記地理データが事前に定義された区域および小区域に格納される、データベースと、
ソフトウェアまたはハードウェアで実施された予想配送効率ジェネレータであって、
複数の前記事前に定義された区域および複数の前記小区域から、地形データ、業務データ、住宅データ、駐車データ、または建物データのうちの少なくとも1つを含む、地理データを受信し、
前記地理データに基づいて、1時間あたり
に作業員によって訪問された宛先のパーセンタイル(APH)によって測定される、予期される配送効率を決定し、
前記配達履歴データに基づいて、選択された個々の事前定義された区域および小区域の前記APHを計算する
ように構成された、予想配送効率ジェネレータと、
ソフトウェアまたはハードウェアで実施されたクロスタイムジェネレータであって、
時間的ギャップの中央値または平均時間に基づく区域間時間および小区域時間を含む、前記作業員が第1の区域と第2の区域との間を移動するための予想時間を計算し、
線形回帰および前記区域間時間に基づいて、前記第1の区域と前記第2の区域との間の運転時間を決定するように構成された、クロスタイムジェネレータと、
ソフトウェアまたはハードウェアで実施されたルートジェネレータであって、
ルートの難易度ならびに、パッケージ分配、出勤値、およびボリューム要求を含むユーザ入力に基づい
てグループに作業員の人数を割り振り、
配送ルートおよ
び配送サブルートと関連付けられた配達区域および配達小区域を生成し、
追加の配達を有する複数のサブルートに複数の作業員を割り当てることによって
前記配送サブルートを変更し、追加の配達を有するサブルートの前記割り当てが、前記複数の作業員に割り当てられた荷物または宛先のベースライン数およびルートの難易度に基づくものであり、前記ベースライン数は、配達作業員ベースで各ルートに対して生成され、
前記生成された配達区域と前記生成された配達小区域とを組み合わせて新しい配達区域にし、
少なくとも1つのサブルートを配送作業員と関連付けられた電子デバイスに転送する
ように構成された、ルートジェネレータと
を含むシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、一般に、配送を最適化し、配達インセンティブ構造を提供するように配送作業員を割り当て、配送ルートを管理するためのコンピュータ化されたシステムおよび方法に関する。特に、本開示の実施形態は、一般に、配達エリアを、利用可能なパッケージ分配および対応可能な配送作業員リソースに基づく区域に動的に区切り、配送作業員に利用可能なパッケージ、ルート、およびサブルートを割り当てるための発明的な非従来型のシステムに関する。本開示の実施形態は、ルートの難易度、各ルートに固有のベースライン数、サブルートの密度、およびサブルート内の宛先の数量を計算して、配送のための追加のパッケージを有する候補ルートを自動的に、または追加の仕事を要求する入力(ボリューム要求)に応答して生成することにも関する。特定のルートの計算されたベースラインを超えて配達された宛先またはパッケージごとに配送作業員に追加の支払いを含むインセンティブが提供され得る。
【背景技術】
【0002】
多くのコンピュータ化された在庫管理システムおよび配送センタが存在する。これらのシステムおよびセンタは、確立された配達エリアでの商品の効率的な分配を可能にし、例えば、地域の出荷センタで、これらの商品を消費者に配達するために利用可能なリソースを利用するように設計される。従来は、各配送センタがその確立された配達エリアを別々の区域または小区域に分割し、次いでこれらのシステムが、それらの区域または小区域のうちの1つまたは複数に商品を配達するよう配送作業員に指図し得る。
【0003】
ただし、通常、これらの区域の各々は事実上固定されており、各区域は1人の配送作業員によってのみカバーされ、その配送作業員が区域の配達需要に追いつけない場合もある。さらに、従来のシステムは、区域境界をリアルタイムで動的に変更したり、配送作業員の区域割り当てを調整したりできない。さらに、従来のシステムは、動的な、または変化する配送数量に柔軟に対応することができないことがよくある。しかも従来のシステムには、配送車両の積載制限を分析したり、配送作業員の配送効率やスキルを考慮したりする備えもない。
【0004】
しかも、トラックにパッケージを積み込み、配送ドライバがたどることになるサブルートを選択するための先行技術のシステムは、一般に手動であり、ドライバの経験に依拠している。配送作業員が配送トラックの積み込みおよび場所から場所への迅速な運転を効率よく行えるようになるには、同じルートを3~5年間定期的に運転する必要があり得る。ルートおよびサブルートは、一般に固定されており、日々変化するものではない。あるルートに多くのパッケージがある場合、その特定のルートに割り当てられたドライバには過剰な負担がかかるが、別のドライバは十分に活用されない場合があり、現在のコンピュータ化されたシステムは、これらの問題に対応できない。加えて、配送ドライバが配送トラック内でパッケージを仕分けするタスクに時間を要する場合もある。
【0005】
加えて、先行技術のシステムは、時間ベースのインセンティブモデルを用いる。そのようなシステムは、配送作業員の労働時間または残業時間に基づくものであり得る。しかしながら、先行技術のシステムは、残業時間内に配達された宛先またはパッケージごとのインセンティブも追加の支払いも提供しない。そのようなシステムは、すでに有能である作業員にとって有益であり、有能ではない配送作業員がより有能になるための動機付けになり得る。
【発明の概要】
【0006】
したがって、必要とされているのは、配送作業員を動的に割り当て、配達エリアを動的に較正して、リアルタイムで配送を最適化するための区域、ルート、およびサブルートにすることができるシステムである。さらに、必要とされているのは、毎日のパッケージ分配および対応可能な配送作業員リソースの変化に基づいて配送条件の予測できない変化を迅速および柔軟に処理することができるデジタル配送ソリューションである。さらに、必要とされているのは、動的な配送数量を円滑化し、輸送車両の積載容量を増やし、配送作業員ごとの配送効率および対応可能な労働時間を増大させ、各配達区域に固有の環境特性および特徴をリアルタイムで監視および更新するための改善された方法およびシステムである。
【0007】
最後に、必要とされているのは、配達のための追加のパッケージまたは宛先を有する候補ルートを生成するために、ルートの難易度、ルートごとの配達されるべきベースラインパッケージ数または配達されるべきベースライン宛先数、サブルートの密度、およびサブルート内の宛先の数量を計算することによってインセンティブプログラムを提供するための改善された方法およびシステムである。計算されたベースライン数を超えて配達された宛先またはパッケージごとに配送作業員に追加の支払いを含むインセンティブが提供され得る。そのようなシステムは、配送効率を高め、究極的には消費者にも利益を提供することになるはずである。
【0008】
本開示の一態様は、出勤割り当てのためのシステムを対象とする。本システムは、メモリと、命令を実行して動作を行うように構成されたプロセッサとを含み得る。動作は、データベースから、複数の配送ルートおよび、配送ルートの一部である、複数の配送サブルートを取得することと、配送サブルートに割り振られたパッケージ数を計算することと、第1の入力として、配送に対応可能な作業員の人数およびタイプを受け取ることであって、タイプが、分類特性または効率特性の少なくとも1つを含む、ことと、追加の配達を有する複数のサブルートに複数の作業員を割り当てることであって、追加の配達を有するサブルートの割り当てが、複数の作業員に割り当てられたベースライン数およびルートの難易度に基づくものである、ことと、分類特性、受け取った第1の入力、およびルートの難易度に基づいて、複数の候補ルートを生成することと、変更された配送サブルートのうちの少なくとも1つを、配送作業員と関連付けられた電子デバイスに転送することと、を含み得る。
【0009】
本開示の別の態様は、出勤割り当てのための方法を対象とする。本方法は、データベースから、複数の配送ルートおよび、配送ルートの一部である、複数の配送サブルートを取得することと、配送サブルートに割り振られたパッケージ数を計算することと、第1の入力として、配送に対応可能な作業員の人数およびタイプを受け取ることであって、タイプが、分類特性または効率特性の少なくとも1つを含む、ことと、追加の配達を有する複数のサブルートに複数の作業員を割り当てることであって、追加の配達を有するサブルートの割り当てが、複数の作業員に割り当てられたベースライン数およびルートの難易度に基づくものである、ことと、分類特性、受け取った第1の入力、およびルートの難易度に基づいて、複数の候補ルートを生成することと、変更された配送サブルートのうちの少なくとも1つを、配送作業員と関連付けられた電子デバイスに転送することと、を含む動作を行い得る。
【0010】
本開示のさらに別の態様は、システムを対象とする。本システムは、地理データおよび配達履歴データを含むデータベースを含んでいてもよく、地理データは事前に定義された区域および小区域に格納される。配送システムは、複数の事前に定義された区域および複数の小区域から、地形データ、業務データ、住宅データ、駐車データ、または建物データのうちの少なくとも1つを含む、地理データを受信し、地理データに基づいて、1時間あたりに作業員によって訪問された宛先のパーセンタイル(APH)によって測定される、予想配送効率を決定し、配達履歴データに基づいて、選択された個々の事前定義された区域および小区域のAPHを計算するように構成された、ソフトウェアまたはハードウェアで実施された予想配送効率ジェネレータを含み得る。本システムは、時間的ギャップの中央値または平均時間に基づく区域間時間および小区域時間を含む、作業員が第1の区域と第2の区域との間を移動するための予想時間を計算し、線形回帰および区域間時間に基づいて、第1の区域と第2の区域との間の運転時間を決定する、ように構成された、ソフトウェアまたはハードウェアで実施されたクロスタイムジェネレータを含み得る。本システムは、ルートの難易度ならびに、パッケージ分配、出勤値、およびボリューム要求を含むユーザ入力に基づいてグループに作業員の人数を割り振り、配送ルートおよび配送サブルートと関連付けられた配達区域および配達小区域を生成し、生成された配達区域と生成された配達小区域とを組み合わせて新しい配達区域にし、配送作業員と関連付けられた電子デバイスに少なくとも1つのサブルートを転送する、ように構成された、ソフトウェアまたはハードウェアで実施されたルートジェネレータをさらに含み得る。本明細書では他のシステム、方法、およびコンピュータ可読媒体も説明される。
【図面の簡単な説明】
【0011】
【
図1A】開示の実施形態と一致する、出荷、輸送、および物流の業務を可能にする通信のためのコンピュータ化されたシステムを含むネットワークの例示的な実施形態を示す概略ブロック図である。
【
図1B】開示の実施形態と一致する、検索要求を満たす1つまたは複数の検索結果をインタラクティブなユーザインターフェース要素と共に含む検索結果ページ(SRP)のサンプルを示す図である。
【
図1C】開示の実施形態と一致する、製品および製品に関する情報をインタラクティブなユインターフェース要素と共に含む単一表示ページ(SDP)のサンプルを示す図である。
【
図1D】開示の実施形態と一致する、仮想ショッピングカート内のアイテムをインタラクティブなユーザインターフェース要素と共に含むカートページのサンプルを示す図である。
【
図1E】開示の実施形態と一致する、仮想ショッピングカートからのアイテムならびに購入および出荷に関する情報をインタラクティブなユーザインターフェース要素と共に含む注文ページのサンプルを示す図である。
【
図2】開示の実施形態と一致する、開示のコンピュータ化されたシステムを利用するように構成された例示的なフルフィルメントセンタの概略図である。
【
図3】各々が個々の配送作業員に割り当てられる、区切られた固定配達区域を含む従来の出荷エリアを識別する先行技術の概略図である。
【
図4】開示の実施形態と一致する、本明細書に記載されるシステムおよび方法によって使用される、予想配送効率ジェネレータ、クロスタイムジェネレータ、およびルートジェネレータを含む配送モジュールの概略図である。
【
図5】開示の実施形態と一致する、クロスタイムジェネレータによって決定されたデータ構造に格納されたクロスタイムデータの表現の概略図である。
【
図6】開示の実施形態と一致する、配送管理者が使用するためのグラフィカルユーザインターフェース(GUI)のシステム視覚表現の概略図である。
【
図7】開示の実施形態と一致する、モバイルデバイス上のグラフィカルユーザインターフェース(GUI)の視覚表現の概略図である。
【
図8】開示の実施形態と一致する、配送作業員を割り当て、配送ルートを管理するための例示的なプロセスを示す流れ図である。
【発明を実施するための形態】
【0012】
以下の詳細な説明は、添付の図面を参照する。可能な限り、図面および以下の説明では、同一または類似の部分を参照するために、同一の参照番号が使用される。いくつかの例示的な実施形態が本明細書で説明されるが、修正、適応、および他の実装が可能である。例えば、置換、追加、または修正が図面に示された構成要素およびステップに行われてもよく、本明細書に記載された例示的な方法は、開示された方法にステップを置換、並べ替え、除去、または追加することによって修正されてもよい。したがって、以下の詳細な説明は、開示された実施形態および例に限定されない。むしろ、本発明の適切な範囲は、添付の特許請求の範囲によって定義される。
【0013】
本開示の実施形態は、配送を動的に最適化するように配送作業員を割り当て、配送ルートを管理するように構成されたシステムおよび方法を対象とする。
【0014】
図1Aを参照すると、出荷、輸送、および物流動作を可能にする通信のためのコンピュータ化されたシステムを含むネットワークの例示的な実施形態を示す概略ブロック
図100が示されている。
図1Aに示すように、システム100は様々なシステムを含むことができ、その各々は、1つまたは複数のネットワークを介して互いに接続することができる。図示のシステムは、出荷権限技術(SAT)システム101、外部フロントエンドシステム103、内部フロントエンドシステム105、輸送システム107、モバイルデバイス107A、107B、107C、売り手ポータル109、出荷および注文追跡(SOT)システム111、フルフィルメント(履行)最適化(FO)システム113、フルフィルメントメッセージングゲートウェイ(FMG)115、サプライチェーン管理(SCM)システム117、労働力管理システム119、モバイルデバイス119A、119B、119C(フルフィルメントセンタ(FC)200の内部にあるものとして図示)、第三者フルフィルメントシステム121A、121B、121C、フルフィルメントセンタ認証システム(FC認証)123、労働管理システム(LMS)125を含む。
【0015】
SATシステム101は、いくつかの実施形態では注文状態および配送状態を監視するコンピュータシステムとして実装されてもよい。例えば、SAT装置101は注文がその約束配送日(PDD)を過ぎているかどうかを判定し、新しい注文を開始すること、配達されていない注文でアイテムを再出荷すること、配達されていない注文をキャンセルすること、注文カスタマとのコンタクトを開始することなどを含む適切な処置をとることができる。SAT装置101は、出力(特定の期間中に出荷された荷物の数のよう)及び入力(出荷に使用するために受け取った空のボール紙箱の数のよう)を含む他のデータを監視することもできる。また、SATシステム101はシステム100内の異なるデバイス間のゲートウェイとして機能し、外部フロントエンドシステム103およびFOシステム113などのデバイス間の通信(例えば、ストアアンドフォワードまたは他の技術を使用する)を可能にしてもよい。
【0016】
いくつかの実施形態では、外部フロントエンドシステム103は外部ユーザがネットワーク100内の1つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装することができる。例えば、ネットワーク100がシステムの提示を可能にして、ユーザがアイテムのための注文を配置することを可能にする実施形態では、外部フロントエンドシステム103が検索リクエストを受信し、アイテムページを提示し、決済情報を要請するウェブサーバとして実装されてもよい。例えば、外部フロントエンドシステム103は、アパッチHTTPサーバ、マイクロソフトインターネットインフォメーションサービス、NGINX等のソフトウェアを実行するコンピュータ又はコンピュータとして実施することができる。他の実施形態では、外部フロントエンドシステム103が外部デバイス(図示せず)からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得した情報に基づいて受信した要求に対する応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。
【0017】
いくつかの実施形態では、外部フロントエンドシステム103がウェブキャッシングシステム、データベース、検索システム、または支払いシステムのうちの1つまたは複数を含むことができる。一態様では外部フロントエンドシステム103がこれらのシステムのうちの1つまたは複数を備えることができ、別の態様では外部フロントエンドシステム103がこれらのシステムのうちの1つまたは複数に接続されたインターフェース(例えば、サーバ間、データベース間、または他のネットワーク接続)を備えることができる。
【0018】
図1B、
図1C、
図1D、および
図1Eによって示されるステップの例示的な組は、外部フロントエンドシステム103のいくつかの動作を説明するのに役立つことができる。外部フロントエンドシステム103は提示および/またはディスプレイのために、ネットワーク100内のシステムまたはデバイスから情報を受け取ることができる。例えば、外部フロントエンドシステム103は、検索結果を含む1つ以上のウェブページをホスティングまたは提供することができる: ページ(SRP)(例えば、
図1B)、単一ディテールページ(SDP)(例えば、
図1C)、カードページ(例えば、
図1D)、または注文ページ(例えば、
図1E)。ユーザデバイス(例えば、モバイルデバイス102Aまたはコンピュータ102Bを使用する)は外部フロントエンドシステム103にナビゲートし、サーチボックスに入力することによってサーチをリクエストすることができる。外部フロントエンドシステム103は、ネットワーク100内の1つまたは複数のシステムからリクエストすることができる。例えば、外部フロントエンドシステム103は、検索要求を満たす結果をFOシステム113に要求してもよい。また、外部フロントエンドシステム103は検索結果で返ってきた商品ごとに、約束配送日または「PDD」を(FOシステム113から)リクエストし、受信することもできる。PDDはいくつかの実施形態では、特定の期間内に、例えば、その日の最後(午後11時59分)までに注文された場合、荷物が、いつユーザの所望の場所に到着するかの推定値を表す(PDDはFOシステム113に関して以下でさらに説明される)。
【0019】
外部フロントエンドシステム103がその情報に基づいてSRP(例えば、
図1B)を準備することができる。SRPは、検索要求を満たす情報を含むことができる。例えば、これは、検索要求を満たす製品の写真を含むことができる。SRPはまた、各製品についてのそれぞれの価格、または各製品についての強化された配送オプション、PDD、重み、規模、オファー、割引などに関する情報を含んでもよい。外部フロントエンドシステム103は(例えば、ネットワークを介して)要求側ユーザデバイスにSRPを送信することができる。
【0020】
次いで、ユーザデバイスは例えば、ユーザインターフェースをクリックまたはタップすることによって、または別のインプットデバイスを使用して、SRPから製品を選択して、SRP上に表される製品を選択し得る。ユーザデバイスは選択されたプロダクトに関するリクエストを作成し、それを外部フロントエンドシステム103に送ることができる。これに応じて、外部フロントエンドシステム103は、選択された商品に関する情報をリクエストすることができる。例えば、情報は、それぞれのSRP上の製品について提示される情報を超える追加の情報を含むことができる。これには、例えば、貯蔵寿命、原産国、体重、大きさ、荷物中のアイテムの個数、取扱説明書、または生成物に関する他の事項が含まれ得る。また、情報は(例えば、この製品および少なくとも1つの他の製品を購入した顧客のビッグデータおよび/または機械学習分析に基づく)類似の製品に対する推奨、頻繁に質問される質問に対する回答、顧客からのレビュー、製造業者情報、写真などを含むことができる。
【0021】
外部フロントエンドシステム103は受信したプロダクトインフォメーションに基づいて、SDP(単一ディテールページ)(例えば、
図1C)を準備することができる。SDPはまた、「今すぐ買う」ボタン、「カードに追加する」ボタン、数量欄、アイテムの写真等のような他の対話型要素を含んでもよい。外部フロントエンドシステム103は(例えば、ネットワークを介して)要求側ユーザデバイスにSDPを配信することができる。
【0022】
依頼元ユーザデバイスは、商品情報を記載したSDPを受け取る場合がある。SDPを受信すると、ユーザデバイスはSDPと対話することができる。例えば、要求ユーザデバイスのユーザは、SDP上の「カートに入れる」ボタンをクリックするか、あるいは他の方法で対話することができる。これは、ユーザに関連付けられたショッピングカートに製品を追加する。ユーザデバイスはこのリクエストを送信して、商品をショッピングカートに追加し、外部フロントエンドシステム103に送ることができる。
【0023】
外部フロントエンドシステム103はカートページ(例えば、
図1D)を生成することができる。カートページはいくつかの実施形態ではユーザが仮想の「買物かご」に追加した商品をリストし、ユーザデバイスは、SRP、SDP、または他のページ上のアイコンをクリックするか、または他の方法で対話することによって、カートページをリクエストしてもよい。いくつかの実施形態では、カートページがユーザがショッピングカートに追加したすべての製品、ならびに各製品の数量、各製品のアイテム当たりの価格、関連する数量に基づく各製品の価格、PDDに関する情報、配送方法、出荷費用、ショッピングカート内の製品を修正するためのユーザインターフェース要素(例えば、数量の削除または修正)、他の製品を注文するかまたは製品の定期的な配送を設定するためのオプション、利息支払いを設定するためのオプション、購入を進めるためのユーザインターフェース要素などのカート内の製品に関する情報を列挙することができる。ユーザデバイスのユーザはショッピングカート内の商品の購入を開始するために、ユーザインターフェース要素(例えば、「今すぐ買う」と読むボタン)をクリックするか、または他の方法でユーザインターフェース要素と対話することができる。そうすると、ユーザデバイスは、このリクエストを送信して、外部フロントエンドシステム103への購入を開始することができる。
【0024】
外部フロントエンドシステム103は購入を開始するためのリクエストの受信に応じて、注文頁(例えば、
図1E)を発生することができる。注文頁はいくつかの実施形態ではショッピングカートからのアイテムを再リストし、支払及び出荷に関するインプットを要求する。例えば、注文ページはショッピングカート内のアイテムの購入者に関する情報(例えば、名前、住所、電子メールアドレス、電話番号)、受取人に関する情報(例えば、名前、住所、電話番号、配送情報)、出荷情報(例えば、配送および/または集荷の速度/方法)、支払情報(例えば、クレジットカード、銀行振込、小切手、記憶クレジット)、現金受領を要求するためのユーザインターフェース要素(例えば、税務目的のための)などを要求する区画を含むことができる。外部フロントエンドシステム103は、注文頁をユーザデバイスへ送信することが可能である。
【0025】
ユーザデバイスは注文頁に情報を入力し、その情報を外部フロントエンドシステム103に送信するユーザインターフェース要素をクリックするか、または他の方法で対話することができる。そこから、外部フロントエンドシステム103はショッピングカート内の製品との新しい注文の作成および加工を可能にするために、システム100内の様々なシステムに情報を送信することができる。
【0026】
いくつかの実施形態では、外部フロントエンドシステム103が売り手が注文に関する情報を送受信することを可能にするようにさらに構成されてもよい。
【0027】
内部フロントエンドシステム105はいくつかの実施形態では内部ユーザ(例えば、システム100を所有し、運営し、またはリースする団体の従業員)がシステム100内の1つまたは複数のシステムと対話することを可能にするコンピュータシステムとして実装することができる。例えば、ネットワーク101がシステムの提示を可能にして、ユーザが注文のための注文を配置できるようにする実施形態では、内部ユーザが注文に関する診断および統計情報を見たり、アイテム情報を修正したり、またはアイテムに関する統計を見直したりできるようにする、内部フロントエンドシステム105をウェブサーバとして実装することができる。例えば、内蔵フロントエンドシステム105は、アパッチHTTPサーバ、マイクロソフトインターネットインフォメーションサービス、NGINX等のソフトウェアを実行するコンピュータ又はコンピュータとして実現することができる。他の実施形態では、内蔵フロントエンドシステム105がシステム100に示されるシステムまたはデバイス(ならびに図示されない他のデバイス)からの要求を受信および処理し、それらの要求に基づいてデータベースおよび他のデータストアから情報を取得し、取得された情報に基づいて受信された要求への応答を提供するように設計されたカスタムウェブサーバソフトウェアを実行することができる。
【0028】
いくつかの実施形態では、内蔵フロントエンドシステム105がウェブキャッシングシステム、データベース、検索システム、支払いシステム、分析システム、注文監視システムなどのうちの1つまたは複数を含むことができる。一態様では内部フロントエンドシステム105がこれらのシステムのうちの1つまたは複数を備えることができ、別の態様では内部フロントエンドシステム105がこれらのシステムのうちの1つまたは複数に接続されたインターフェース(たとえば、サーバ間、データベース間、または他のネットワーク接続)を備えることができる。
【0029】
輸送システム107は、いくつかの実施形態ではシステム100内のシステムまたはデバイスとモバイルデバイス107A~107Cとの間の通信を可能にするコンピュータシステムとして実施することができる。いくつかの実施形態では、トランスポーテーションシステム107が1つまたは複数のモバイルデバイス107A~107C(例えば、携帯電話、スマートフォン、PDAなど)から受信することができる。例えば、いくつかの実施形態では、モバイルデバイス107A~107Cが配送作業員によって操作されるデバイスを含んでもよい。配送作業員は、正社員、臨時社員、または交替社員であってもよく、モバイルデバイス107A~107Cを利用して、ユーザによって注文された製品を含む荷物の配送を行うことができる。例えば、荷物を配信するために、配送作業員は、どの荷物を配信すべきか、およびそれをどこに配信すべきかを示す通知をモバイルデバイス上で受信することができる。配送位置に到着すると、配送作業員は荷物を(例えば、トラックの後ろに、または荷物の箱に)配置し、モバイルデバイスを使用して荷物上の識別子に関連するデータ(例えば、バーコード、イメージ、文字列、RFIDタグなど)を走査または他の方法で捕捉し、荷物を(例えば、前扉に置いたままにし、警備員を置いたままにし、受信者に渡すなどによって)配信することができる。いくつかの実施形態では、配送作業員が荷物の写真をキャプチャすることができ、および/またはモバイルデバイスを使用してシグネチャを取得することができる。モバイルデバイスは例えば、時刻、日付、GPS位置、写真、配送作業員に関連付けられた識別子、モバイルデバイスに関連付けられた識別子などを含む配送に関する情報を含む情報を輸送機関107に送信することができる。輸送システム107はシステム100内の他のシステムによるアクセスのために、この情報をデータベース(図示せず)に記憶することができる。輸送システム107はいくつかの実施形態ではこの情報を使用して、特定の荷物の位置を示す追跡データを準備し、他のシステムに送信することができる。
【0030】
いくつかの実施形態ではあるユーザが1つの種類のモバイルデバイスを使用することができる(例えば、永久作業員はバーコードスキャナ、スタイラス、および他のデバイスなどのカスタムハードウェアと共に専用のPDAを使用することができる)が他のユーザは他の種類のモバイルデバイスを使用することができる(例えば、一時的または移動作業員は既製の携帯電話および/またはスマートフォンを利用することができる)。
【0031】
いくつかの実施形態では、交通機関107がユーザをそれぞれのデバイスに関連付けることができる。例えば、輸送システム107はユーザ(例えば、ユーザ識別子、従業員識別子、または電話番号)とモバイルデバイス(例えば、国際移動装置アイデンティティ(IMEI)、国際移動加入識別子(IMSI)、電話番号、汎用一意識別子(UUID)、またはグローバル一意(GUID)によって表される)との間の関連を記憶することができる。トランスポートシステム107はこの関連付けを、配送上で受信されたデータと併せて使用して、とりわけ、作業員の位置、作業員の有効性、または作業員のスピードを決定するために、注文内のデータベースに格納されたデータを分析することができる。
【0032】
売り手ポータル109は、いくつかの実施形態では売り手または他の外部エンティティが注文に関する情報の他の側面と電子的に通信することを可能にするコンピュータシステムとして実装され得る。例えば、売り手は、コンピュータシステム(図示せず)を利用して、売り手がシステム100を通して売りたい製品について、製品情報、注文情報、連絡先情報などをアップロードまたは提供することができる。
【0033】
出荷および注文追跡システム111はいくつかの実施形態では(例えば、デバイス102A~102Bを使用するユーザによって)顧客によって注文された製品を含む荷物の位置に関する情報を受信し、記憶し、転送するコンピュータシステムとして実装されてもよい。いくつかの実施形態では、出荷および注文追跡装置111は顧客が注文した製品を含む荷物を配送する出荷会社によって運営されるウェブサーバ(図示せず)からの情報をリクエストまたは記憶することができる。
【0034】
いくつかの実施形態では、出荷および注文追跡システム111がシステム100に示されたシステムからの情報をリクエストし、記憶することができる。例えば、出荷および注文追跡システム111は、輸送システム107にリクエストすることができる。上述のように、交通機関107はユーザ(例えば、配送作業員)または乗り物(例えば、配送車)のうちの1つまたは複数に関連付けられた1つまたは複数のモバイルデバイス107A~107C(例えば、携帯電話、スマートフォン、PDAなど)から受信することができる。いくつかの実施形態では、出荷および注文追跡装置111がフルフィルメントセンタ(例えば、フルフィルメントセンタ200)内の個々の製品の位置を決定するために、労働力管理システム(WMS)119にリクエストすることもできる。出荷および注文追跡システム111は輸送システム107またはWMS 119のうちの1つまたは複数からデータを要求し、それを処理し、要求に応じてそれをデバイス(たとえば、ユーザデバイス102Aおよび102B)に提示することができる。
【0035】
フルフィルメント(履行)最適化(FO)システム113はいくつかの実施形態では他のシステム(例えば、外部フロントエンドシステム103および/または出荷および注文追跡システム111)からのカスタマ注文のための情報を記憶するコンピュータシステムとして実装されてもよい。また、FOシステム113は、特定のアイテムがどこに保持されているか、またはどこに記憶されているかを記述する情報を記憶することもできる。たとえば、特定のアイテムは1つのフルフィルメントセンタにのみ格納でき、他の特定のアイテムは複数のフルフィルメントセンタに格納できる。さらに他の実施形態では、特定のフルフィルメントセンタが特定の組のアイテム(例えば、生鮮食品または冷凍食品)のみを格納するように設計されてもよい。FOシステム113はこの情報ならびに関連する情報(例えば、数量、サイズ、受領日、有効期限など)を格納する。
【0036】
また、FOシステム113は、商品毎に対応するPDD(約束配送日)を計算してもよい。PDDは、いくつかの実施形態では1つまたは複数の要因に基づくことができる。例えば、FOシステム113は製品に対する過去の需要(例えば、その製品がある期間中に何回注文されたか)、製品に対する予想需要(例えば、来るべき期間中にその製品を注文するために何人の顧客が予想されるか)、ある期間中にいくつの製品が注文されたかを示すネットワーク全体の過去の需要、来るべき期間中にいくつの製品が注文されることが予想されるかを示すネットワーク全体の予想需要、各フルフィルメントセンタ200に格納された製品の1つ以上のカウント、その製品に対する各製品、予想または現行注文などに基づいて、製品に対するPDDを計算することができる。
【0037】
いくつかの実施形態では、FOシステム113が定期的に(例えば、1時間ごとに)商品ごとにPDDを決定し、それを検索または他のシステム(例えば、外部フロントエンドシステム103、SATシステム101、出荷および注文追跡システム111)に送信するためにデータベースに格納することができる。他の実施形態では、FOシステム113が1つまたは複数のシステム(例えば、外部フロントエンドシステム103、SATシステム101、出荷および注文追跡システム111)から電子要求を受信し、オンデマンドでPDDを計算することができる。
【0038】
フルフィルメントメッセージングゲートウェイ115はいくつかの実施形態ではFOシステム113などのネットワーク100内の1つ以上のシステムから通信を受信し、その通信におけるデータを別のフォーマットに変換し、変換されたフォーマットのデータを、WMS 119または第三者フルフィルメントシステム121A、121B、または121Cなどの他のシステムに転送するコンピュータシステムとして実装することができる。
【0039】
サプライチェーン管理(SCM)システム117は、いくつかの実施形態では予測機能を実行するコンピュータシステムとして実装することができる。例えば、SCMシステム117は例えば、製品に対する過去の需要、製品に対する予想される需要、ネットワーク全体の過去の需要、ネットワーク全体の予想される需要、各フルフィルメントセンタ200に格納された計数製品、各製品に対する予想または現行注文などに基づいて、特定の製品に対する需要の予測水準を決定することができる。この決定された予測水準およびすべてのフルフィルメントセンタにわたるそれぞれの製品の量に応じて、SCMシステム117は特定の製品に対する期待需要を満たすために1つまたは複数の購入注文を生成することができる。
【0040】
労働力管理システム(WMS)119は、いくつかの実施形態ではワークフローをモニタするコンピュータシステムとして実装されてもよい。例えば、WMS 119は個別イベントを示す個別デバイス(例えば、デバイス107A-107Cまたは119A-119C)からイベントデータを受信することができる。例えば、WMS 119は、荷物を走査するためにこれらのデバイスの1つの使用を示すイベントデータを受信してもよい。フルフィルメントセンタ200および
図2に関して以下で論じるように、フルフィルメントプロセス中に、荷物識別子(例えば、バーコードまたはRFIDタグデータ)は特定の段階で機械によってスキャンまたは読み取ることができる(例えば、自動またはハンドヘルドバーコードスキャナ、RFIDリーダ、高速カメラ、タブレット119A、モバイルデバイス/PDA 119B、コンピュータ119Cなどのデバイス)。WMS 119は荷物識別子、時刻、日時、位置、ユーザ識別子、または他の情報と共に、荷物識別子の走査または読取りを示す各々の事象を対応するデータベース(図示せず)に記憶することができ、この情報を他のシステム(例えば、出荷および注文追跡システム111)に提供することができる。
【0041】
WMS 119はいくつかの実施形態では1つまたは複数のデバイス(例えば、デバイス107A~107Cまたは119A~119C)を、システム100に関連付けられた1つまたは複数のユーザに関連付ける情報を記憶してもよい。例えば、いくつかの状況では、ユーザ(パートまたはフルタイムの従業員など)は、ユーザがモバイルデバイスを所有する(例えば、モバイルデバイスがスマートフォンである)という点で、モバイルデバイスに関連付けられてもよい。他の状況では、ユーザは、ユーザが一時的にモバイルデバイスの管理下にある(例えば、ユーザは日の始めにモバイルデバイスを借り、日中にそれを使用し、日の終わりにそれを返す)という点で、モバイルデバイスに関連付けられてもよい。
【0042】
WMS 119は、いくつかの実施形態ではシステム100に関連する各ユーザの作業ログを維持することができる。例えば、WMS 119は任意の割り当てられたプロセス(例えば、トラックのアンローディング、ピックゾーンからのアイテムのピッキング、仕分け装置ワーク、パッキングアイテム)、ユーザ識別子、位置(例えば、フルフィルメントセンタ200内のフロアまたはゾーン)、従業員によってシステム内を移動されたユニットの数(例えば、ピックされたアイテムの数、パックされたアイテムの数)、デバイスに関連付けられた識別子(例えば、デバイス119A~119C)などを含む、各従業員に関連付けられた情報を記憶することができる。いくつかの実施形態では、WMS 119がデバイス119A~119C上で動作するタイムキーピングシステムなどのタイムキーピングシステムからチェックインおよびチェックアウト情報を受信することができる。
【0043】
第三者フルフィルメント(3PL)システム121A~121Cは、いくつかの実施形態ではロジスティクスおよび製品のサードパーティプロバイダに関連するコンピュータシステムを表す。例えば、(
図2に関して以下に説明するように)いくつかの製品がフルフィルメントセンタ200に格納されている間、他の製品は、オフサイトで格納されてもよく、オンデマンドで生産されてもよく、またはフルフィルメントセンタ200に格納するために利用できなくてもよい。3PLシステム121A~121CはFOシステム113から(例えば、FMG 115を介して)注文を受信するように構成することができ、製品および/またはサービス(例えば、配送または設置)を顧客に直接的に提供することができる。
【0044】
フルフィルメントセンタ自動システム(FC認証)123は、いくつかの実施形態では様々な機能を有するコンピュータシステムとして実装され得る。例えば、いくつかの実施形態では、FC認証123がシステム100内の1つまたは複数の他のシステムのためのシングルサインオン(SSO)サービスとして動作することができる。例えば、FC認証123はユーザが内部フロントエンドシステム105を介してログインすることを可能にし、ユーザが出荷および注文追跡系111においてリソースにアクセスするための同様の特権を有していることを決定し、ユーザが2回目のログイン処理を必要とせずにそれらの特権にアクセスすることを可能にしてもよい。他の実施形態では、FC認証123は、ユーザ(例えば、従業員)が自分自身を特定の作業に関連付けることを可能にしてもよい。例えば、従業員の中には、電子デバイス(デバイス119A~119Cなど)を持たない者もいれば、その代わりに、1日の過程中に、フルフィルメントセンタ200内でタスクからタスクへ、およびゾーンからゾーンへ移動してもよい。FC認証123は、それらの従業員は、彼らがどの仕事をしているか、および彼らが様々な時刻にどの区域にいるかを示すことを可能にするように構成されてもよい。
【0045】
労働管理システム(LMS)125は、いくつかの実施形態では従業員(フルタイムおよびパートタイムの従業員を含む)のための出勤および残業を記憶するコンピュータシステムとして実装されてもよい。例えば、LMS 125は、FC認証123、WMA 119、デバイス119A-119C、輸送装置107、及び/又はデバイス107A-107Cから受信することができる。
【0046】
図1Aに示される特定の構成は単なる例である。例えば、
図1AはFOシステム113に接続されたFC認証システム123を示すが、全ての実施形態がこの特定の構成を必要とするわけではない。実際、いくつかの実施形態では、システム100内のシステムがインターネット、イントラネット、WAN(ワイドエリアネットワーク)、MAN(メトロポリタンエリアネットワーク)、IEEE 802.11a/b/g/n規格に準拠する無線ネットワーク、専用線などを含む1つまたは複数の公衆またはプライベートネットワークを介して互いに接続され得る。いくつかの実施形態では、システム100内のシステムの1つ以上がデータセンター、サーバファームなどに実装された1つ以上の仮想サーバとして実装されてもよい。
【0047】
図2は、フルフィルメントセンタ200を示す。フルフィルメントセンタ200は、注文時に顧客に出荷するためのアイテムを格納する物理的な場所の実例である。フルフィルメントセンタ(FC)200は多数のゾーンに分割することができ、その各々を
図2に示す。これらの「ゾーン」はいくつかの実施形態ではアイテムを受け取り、アイテムを保管し、アイテムを取り出し、アイテムを出荷する処理の様々な段階の間の仮想分割と考えることができ、したがって、「ゾーン」は
図2に示されているが、ゾーンの他の分割も可能であり、いくつかの実施形態では
図2のゾーンを省略、複製、または修正することができる。
【0048】
インバウンドゾーン203は、
図1Aの装置100を使用して製品を販売しようとする売り手からアイテムを受け取るFC 200の領域を表す。例えば、売り手は、台車201を使用してアイテム202A及び202Bを配送することができる。アイテム202Aはそれ自体の出荷パレットを占有するのに十分な大きさの単一のアイテムを表すことができ、アイテム202Bは、空間を節約するために同じパレット上に一緒に積み重ねられた1組のアイテムを表すことができる。
【0049】
作業員はインバウンドゾーン203でアイテムを受け取り、コンピュータシステム(図示せず)を使用して、アイテムの破損および正当性を任意選択で検査することができる。例えば、作業員は、コンピュータシステムを使用して、アイテム202Aおよび202Bの数量をアイテムの注文数量と比較することができる。数量が合致しない場合、その作業員は、アイテム202Aまたは202Bのうちの1つまたは複数を拒否することができる。数量が一致すれば、作業員はそれらのアイテムを緩衝地帯205まで(例えば、1ドル、ハンドトラック、フォークリフト、手動で)移動させることができる。緩衝ゾーン205は例えば、予測される需要を満たすのに十分な量のアイテムがピッキングゾーンにあるため、ピッキングゾーンで現在必要とされていないアイテムのための一時保管領域であってもよい。いくつかの実施形態では、フォークリフト206が緩衝ゾーン205の周り、および入りゾーン203と落下ゾーン207との間でアイテムを移動させるように動作する。ピッキングゾーンにアイテム202Aまたは202Bが必要な場合(例えば、予想される需要のため)、フォークリフトは、アイテム202Aまたは202Bを落下ゾーン207に移動させることができる。
【0050】
ドロップゾーン207は、アイテムがピッキングゾーン209に移動される前にそれらを保管するFC 200の領域であってもよい。ピッキングタスクに割り当てられた作業員(「ピッカー」)はピッキングゾーン内のアイテム202Aおよび202Bに接近し、ピッキングゾーンのバーコードをスキャンし、モバイルデバイス(例えば、デバイス119B)を使用してアイテム202Aおよび202Bに関連するバーコードをスキャンすることができる。次いで、ピッカーはアイテムをピッキングゾーン209まで(例えば、それをカート上に置くか、またはそれを運ぶことによって)取り込むことができる。
【0051】
ピッキングゾーン209は、アイテム208が保管ユニット210に保管されるFC 200の領域であってもよい。いくつかの実施形態では、貯蔵ユニット210が物理的な棚、本棚、箱、運搬箱、冷蔵庫、冷凍庫、冷蔵庫などのうちの1つまたは複数を含むことができる。いくつかの実施形態では、ピッキングゾーン209が複数のフロアに編成されてもよい。いくつかの実施形態では、作業員または機械が例えば、フォークリフト、エレベータ、コンベアベルト、カート、ハンドトラック、台車、自動ロボットもしくはデバイス、または手動を含む多数の方法で、ピッキングゾーン209内にアイテムを移動させることができる。例えば、ピッカーは、アイテム202Aおよび202Bを降下ゾーン207の手押し車または台車に載せ、アイテム202Aおよび202Bをピッキングゾーン209まで歩くことができる。
【0052】
ピッカーは、保管ユニット210上の特定の空間のようなピッキングゾーン209内の特定のスポットにアイテムを配置する(又は「収納する」)命令を受け取ることができる。例えば、ピッカーはモバイルデバイス(例えば、デバイス119B)を使用してアイテム202Aを走査することができる。デバイスは例えば、通路、棚、及び位置を示す装置を使用して、ピッカーがアイテム202Aを収納すべき場所を示すことができる。次に、デバイスはアイテム202Aをその位置に格納する前に、その位置でバーコードを走査するようにピッカーを促すことができる。デバイスは(例えば、ワイヤレスネットワークを介して)
図1AのWMS 119のようなコンピュータシステムにデータを送信し、アイテム202Aがデバイス119Bを使用してユーザによってその位置に格納されたことを示すことができる。
【0053】
ユーザが注文を置くと、ピッカーは、保管ユニット210から1つまたは複数のアイテム208を取り出すための命令をデバイス119B上で受け取ることができる。ピッカーはアイテム208を取り出し、アイテム208上のバーコードを走査し、それを搬送メカニズム214上に置くことができる。搬送機構214はスライドとして表されているが、いくつかの実施形態では搬送機構がコンベヤーベルト、エレベータ、カート、フォークリフト、ハンドトラック、台車、カートなどのうちの1つまたは複数として実施することができる。次いで、アイテム208は、充填領域211に到達することができる。
【0054】
パッキングゾーン211は、アイテムがピッキングゾーン209から受け取られ、最終的に顧客に出荷するためにボックスまたはバッグにパッキングされる、FC 200の領域であってもよい。パッキングゾーン211において、受信アイテム(「リビン(rebin)作業員」)に割り当てられた作業員はピッキングゾーン209からアイテム208を受信し、それがどの注文に対応するかを決定する。例えば、リビン(rebin)作業員はアイテム208上のバーコードを走査するために、コンピュータ119Cなどのデバイスを使用することができる。コンピュータ119Cはどの注文アイテム208が関連付けられているかを視覚的に示すことができる。これは例えば、注文に対応する壁面216上の空間または「セル」を含むことができる。注文が完了すると(例えば、セルが注文のためのすべてのアイテムを含むため)、リビン(rebin)作業員は、注文が完了したことをパッキング作業員(または「パッカー」)に示すことができる。梱包業者はセルからアイテムを回収し、輸送のために箱または袋に入れることができる。その後、パッカーは例えば、フォークリフト、カート、ドリー、ハンドトラック、コンベヤーベルトを介して、又は他の方法で、箱又はバッグをハブゾーン213に送ることができる。
【0055】
ハブゾーン213は、パッキングゾーン211から全てのボックスまたはバッグ(「荷物」)を受け取るFC 200の領域であってもよい。ハブゾーン213内の作業員および/またはマシンは荷物218を検索し、それぞれの荷物が行こうとする配送領域の一部を決定し、荷物を適切なキャンプゾーン215にルーティングすることができる。例えば、配送領域が2つのより小さいサブ領域を有する場合、荷物は2つのキャンプゾーン215のうちの1つに進む。いくつかの実施形態では、作業員またはマシンが(例えば、デバイス119A~119Cのうちの1つを使用して)荷物を走査して、その最終的な宛先を決定することができる。荷物をキャンプゾーン215にルーティングすることは、例えば、荷物が向けられている地理的エリアの一部を(例えば、郵便番号に基づいて)決定することと、地理的エリアの一部に関連付けられたキャンプゾーン215を決定することとを含むことができる。
【0056】
キャンプゾーン215はいくつかの実施形態では1つまたは複数の建物、1つまたは複数の物理的な空間、または1つまたは複数のエリアを備えることができ、荷物は、ルートおよび/またはサブルートに分類するためにハブゾーン213から受け取られる。いくつかの実施形態ではキャンプゾーン215がFC 200から物理的に分離されているが、他の実施形態ではキャンプゾーン215がFC 200の一部を形成することができる。
【0057】
キャンプゾーン215内の作業員および/またはマシンは例えば、目的地と現存するルートおよび/またはサブルートとの照合、ルートおよび/またはサブルートごとの作業負荷の算出、時刻、出荷方法、荷物220を出荷する費用、荷物220内のアイテムに関連付けられたPDDなどに基づいて、荷物220がどのルートおよび/またはサブルートに関連付けられるべきかを決定することができる。いくつかの実施形態では、作業員またはマシンが(例えば、デバイス119A~119Cのうちの1つを使用して)荷物を走査して、その最終的な宛先を決定することができる。荷物220が特定のルートおよび/またはサブルートに割り当てられると、作業員および/またはマシンは、出荷される荷物220を移動させることができる。例示的な
図2において、キャンプゾーン215は、トラック222、かご226、および配送作業員224Aおよび224Bを含む。いくつかの実施形態では、トラック222が配送作業員224Aによって駆動されてもよく、配送作業員224AはFC 200の荷物を配信する常勤の従業員であり、トラック222はFC 200を所有し、リースし、または運営する同じ企業によって所有され、リースされ、または運営される。いくつかの実施形態では、自動車226が配送作業員224Bによって駆動されてもよく、ここで、配送作業員224Bは必要に応じて(例えば、季節的に)送達する「フレックス」または時折の作業員である。自動車226は、配送作業員224Bによって所有され、リースされ、または操作され得る。
【0058】
図3は、各々が配達を行うために個々の配送作業員に割り当てられる、区切られた固定配達区域を含む従来の出荷エリアの概略図である。
図3に示されるように、町、地方自治体、地区、郡、または州などの地理的領域は、固定区域302および小区域304を含む様々な大きさの複数の区域に区切られ、各区域または小区域は固定された境界を含み得る。地理的領域は小区域にさらに分割されてもよく、配送作業員224A、224Bは、固定された地理的境界に従って区域または小区域のうちの1つまたは複数に商品を配達し得る。従来、
図3の各区域または小区域は、その区域または小区域への配達を行うために1人だけの配送作業員に割り当てられる。
【0059】
一部の先行技術のコンピュータ化されたシステムは、時間ベースのインセンティブモデルを用いる。これらの先行技術のシステムでは、配送作業員224A、224Bは、区域または小区域のうちの1つまたは複数(すなわち、固定区域302および小区域304)に商品を配達し、配送作業員224A、224Bは、区域におけるベースライン数を超えて配達された追加のパッケージ数または配達された宛先数に基づいて追加の支払いを受け取り得る。ただし、これらの先行技術のシステムでは、残業時間内に、または計算されたベースライン数を超えて配達された宛先またはパッケージごとのインセンティブも追加の支払いもない。ベースライン数を超えた後に配達された宛先またはパッケージごとのインセンティブを有するシステムは、すでに有能である配送作業員にとって有益であり、有能ではない配送作業員がより有能になるための動機付けにもなり得る。加えて、記載の実施形態は、配達のためのパッケージの独創的な割り当てを可能にする。配送作業員がベースラインを超えた後にインセンティブを提供することにより、配達されるべきパッケージの処理残が減ることになる。さらに、この構造は、1人の配送作業員が配達を管理できない緊急時に有益である。処理残を増やす代わりに、システムは、アルゴリズムを臨機応変に実行し、遅延を回避するためにパッケージを再割り当てし得る。
【0060】
図4は、開示の実施形態と一致する、ソフトウェアまたはハードウェアで実施される、本明細書に記載されるシステムおよび方法によって使用される、予想配送効率ジェネレータ406、クロスタイムジェネレータ408、およびルートジェネレータ416を含む配送モジュールの概略
図400である。
図4(および他の図)に示されるアーキテクチャおよび個々のモジュールは単なる例示である。
【0061】
図4に示されるように、データベース401は、地理データ402および配達履歴データ404を含む。地理データ402は、事前に定義された区域および小区域を含む地理情報を含み得る。小区域は、単一の事前に定義された区域のより小さい部分として存在し得る。単一の区域内には複数の小区域が存在していてもよく、小区域は、同じ地理的特性を有するエリアを構成し得る。いくつかの態様では、小区域はそれ以上分割できない場合もある。一例として、事前に定義された区域は、郡、州、または郵便番号を含み得る。別の例として、小区域は、町、地方自治体、都市、または他の場所を含み得る。区域および小区域は、前述の例に限定されない。実際、小区域が郡として存在していてもよく、または区域が町として存在していてもよい。区域および小区域の他の地理的な例も企図され、データベースからアクセス可能であり得る。配達履歴データ404は、配達場所、配達時間、配送ドライバ、および/または配達パッケージを含むデータを含み得る。他のタイプの履歴も可能である。いくつかの実施形態では、配達履歴データ404は、過去70日間の1時間あたりの平均宛先数の履歴データを含み得る。したがって、配達履歴データ404は、ルートの難易度および配送作業員224A、224Bのベースライン数を決定するために使用され得る。
【0062】
予想配送効率ジェネレータ406は、データベースと通信し、各区域または小区域における予想配送効率を決定するために地理データ402および配達履歴データ404の各々を取得し得る。一例として、予想配送効率ジェネレータ406は、地形、業務エリア、住宅エリア、駐車エリア、または建物の記述のうちの1つまたは複数にさらに依拠して、予想配送効率を決定し得る。予想配送効率ジェネレータ406は、地理データ、履歴データ、および地形または業務データの各々を組み込み、格納された宛先データと比較して、予想配送効率を計算し得る。比較は、合計配達数またはフィルタリングされた期間にわたって特定の宛先に対して行われた個々の配達を評価し、地理データ、履歴データ、地形または業務データに基づいて、(1つまたは複数の)配達時間、(1つまたは複数の)距離、または他の基準もしくはメトリックを使用して効率値(1時間あたりの宛先数(APH)など)を計算し得る。予想配送効率ジェネレータ406は、予想配送効率として絶対効率に加えて相対効率値も計算し得る。相対効率値は、異なる配送地形または区域に基づくパーセンテージ値(例えば、60%または70%、P60またはP70とも呼ばれる)を含み得る。絶対効率値は、絶対値(例えば、18パッケージ/時や20パッケージ/時)を含み得る。各区域または地形は様々な配達地勢を有し得るので、絶対値の効率値よりも相対効率値の方が好ましい場合がある。さらに、予想配送効率ジェネレータ406はAPHメトリックを計算してもよく、APHメトリックは1時間または他の期間内に配送作業員が訪問できる宛先数を表し、このメトリックは、他の計算されたAPH値に対する値を含み得るか、または絶対値を表し得る。各区域または小区域におけるAPHのパーセンタイル値が履歴データに基づいて計算され得る。いくつかの態様では、特定のパーセンタイルが、予想配送効率として決定され得る(例えば、相対効率値として第60パーセンタイルまたはP60)。他の態様では、予想配送効率は、配達のための時間および配送作業員のスキルまたは経験を考慮に入れ得る。
【0063】
本開示によれば、予想配送効率ジェネレータ406は、3ヵ月以下の履歴データに基づいて区域および小区域のパーセンタイルを生成し得る。履歴データを使用する他の時間範囲も可能である。履歴データへの依拠は、例えば、「有効な」配達期間を含む任意の所望の特徴によるフィルタまたは入力された検索用語によってフィルタリングされ得る。「有効な」配達期間は、すべての配達期間が同じ日に同じ小区域において同じ配送作業員によって完了されることを必要とし得る。いくつかの態様では、「有効な」配達期間は、その期間が15分間以上であることを必要とし得る。他の態様では、「有効な」配達期間は、任意の連続した配達間の時間的ギャップが30分未満であることも必要とし得る。「有効な」期間の他の基準も企図され、フィルタリングに使用され得る。予想配送効率ジェネレータ406は、「有効な」配達期間ごとのAPH値を計算し、「有効な」配達期間ごとのAPHのパーセンタイル値も生成し得る。配送効率を決定するための他のメトリックも企図され、予想配送効率ジェネレータ406によって利用され得る。
【0064】
図5は、クロスタイム(T)501を計算するための開示の実施形態と一致する、クロスタイムジェネレータ408によって使用されるデータ構造500に格納されたクロスタイムデータの表現の概略図である。
図5に示されるように、クロスタイムジェネレータ408は、「小区域1」502および「小区域2」504として識別された2つの区域を含む。2つの小区域の各々について、線形スペクトルは、配送作業員によって行われるべきすべてのタスクである、「運転」506、「駐車」508、「仕分け」510、および「配達」512の各々に専用の時間部分を含む。これらのクロスタイムは、配送作業員が、例えば、2つの小区域502、504間の「運転」506、「駐車」508、「仕分け」510、および「配達」512の各々を含む、前述のタスクのいずれかを完了するのに要する時間量を決定するために計算され得る。しかしながら、クロスタイムジェネレータ408は、必ずしも「運転」506だけの時間を計算する必要はなく、「運転」506に加えて他の輸送モードの計算を行ってもよい。例えば、クロスタイムジェネレータ408は、追加のステップを含むか、または前述のステップのいずれかを除外し得る。クロスタイムジェネレータ408は、履歴クロスタイム測定値を生成する履歴クロスタイム生成モジュール410およびクロスタイム完了および較正測定値412を計算するクロスタイム完了および較正モジュール412を実施し得る。
図5に示されるように、配送作業員がある区域から次の区域に、またはある小区域から次の小区域に移動するための予想時間とするために、区域間/小区域時間が計算され得る。
【0065】
図4に戻って、クロスタイムジェネレータ408は、最近3ヵ月間の2つの区域または小区域間の時間的ギャップの中央値を使用して区域間/小区域時間をさらに計算し得る。この時間は、1つの注文の配達時間を含んでいてもよく、横断時間だけを含むのではない場合もある。時間的ギャップがないか、またはデータサンプル数が2以下である場合、クロスタイムジェネレータ408は、キャンプまたはキャンプゾーン215における平均区域間/小区域時間を使用し得る。クロスタイムジェネレータ408は、クロスタイム完了および較正も行い得る。一例として、「n」個の区域または小区域がある場合、クロスタイムの総数はn
2/2であり得る。通常、配送作業員がすべての可能な交差をカバーする可能性は低いので、履歴クロスタイムはこの値よりもずっと小さくなり得る。
図4に示されるように、任意の2つの区域/小区域間の運転時間を決定するためにマップサービスモジュール430が使用され得る。運転時間とクロスタイムとの関係を決定するために線形回帰も使用され得るので、マップサービスモジュール430から取得された運転時間は、クロスタイムに変換され、クロスタイム行列が完成し得る。本開示によれば、クロスタイム行列がクロスタイムを計算するために使用され得る。
【0066】
本開示よれば、ルートジェネレータ416は、出勤割り振り最適化モジュール418、シード分配生成モジュール420、再分配最適化モジュール422、および訪問順序最適化モジュール424を含み得る。
図4に示されるように、ルートジェネレータ416は、ルート428を生成するために、予想配送効率ジェネレータ406からのAPH値、時間(T)値、パッケージ分配426ならびにユーザ構成および優先設定414を参照し得る。出勤割り振り最適化モジュール418は、パッケージ分配426、および配送作業員の経験に関する分類カテゴリ(例えば、「初心者」、「通常」、「シニア」)の下で割り当てられた出勤番号、の各入力に基づいて、各グループに配送作業員の人数を割り振るために使用され得る。これらの分類カテゴリの一部として、配送作業員は、その配送能力および/または配送効率に見合う様々な重みと関連付けられ得る。重みは、配送作業員の配送経験にも関連し得る。例えば、「初心者」の分類は、新しい配送作業員または配送経験がほとんどもしくは全くない配送作業員を指示する。「通常」の分類は、多くはないがある程度の、または有意な配送経験がある配送作業員を指示する。「シニア」の分類は、長年にわたる有意な配送経験がある配送作業員を指示する。他の分類識別も可能であり得る。シード分配生成モジュール420は、ユーザによって構成された規則に基づいて余分な区域を削除し、新しい区域を作成し、区域を生成するために使用され得る。これらの規則は、ユーザによって、余分な区域を削除し、新しい区域を作成するように構成され、規則は、インターフェースに入力され、所望の配送作業員(例えば、「ロートップ」、「職人優先」、および「その他の規則」)をさらに指定し得る。「ロートップ」の分類は、大型トラックではなく、屋根が低い車両に配達物を積み込む経験を有する配送作業員を指示する。ロートップトラックを含む屋根が低い車両は、地階への配達を必要とする宛先への配達を行うのに必要とされ得る。シード分配生成モジュール420は、区域固有であり得る運用規則を生成してもよく、特定の区域で行われるすべての配達が「ロートップ」または「職人優先」であることを要求し得る。「職人優先」の分類は、あらゆる種類の便利屋または荷積みのスキルを持ち、様々な複雑さを有する様々なタイプのタスクを行うことができる配送作業員を指示する。シード分配生成モジュール420は、特定の区域が「職人優先」の配送作業員のみを含むよう要求し得る。「その他の規則」の分類は、目下の特定の配達要件に基づいて指定され得る「その他の規則」を指示する。他の分類識別も可能であり得る。
【0067】
再分配最適化モジュール422は、生成されたシード分配内の区域に基づくものであってもよく、複数の候補区域を作成し得る。再分配最適化モジュール422は、すべての配達需要をカバーし、配送コストを最小化するために、すべての候補区域からの区域の最適な組み合わせを決定する0/1プログラミングモデルをさらに実施し得る。訪問順序最適化モジュール424は、新しく生成された区域の集合である再分配最適化422の出力を利用し得る。生成された各区域内で、訪問順序最適化モジュール424は、配送コストを最小化するために最善の配達訪問順序を決定し得る。訪問順序最適化モジュール424は、区域および小区域、ならびに特定の区域および小区域への特定の順序での配達を記述するコーディングを提供し得る。文字または数字が、区域または小区域を記述し、配送コストを最小化するための訪問配達順序を提示するためのコードとして使用され得る。出勤割り振り最適化モジュール418、シード分配生成モジュール420、最適化モジュール422、および訪問順序最適化モジュール424は、協働して最適なルート428を生成し得る。
【0068】
本開示によれば、再分配最適化モジュール422は、作業員を割り振るために以下の式を実施し得る(「整数プログラミングモデル」)。
【数1】
、式中、以下のとおりである。
【表1】
【0069】
以下でこれらの変数の各々について説明する。xi、yi、ziは、何人の配送作業員、半日作業員、および歩行作業員が、それぞれ、グループiに割り当てられ得るかを記述する整数変数を表し得る。整数プログラミングモデルによって使用されるその他のパラメータには、キャンプ全体のドライバ1人あたりの平均パッケージ数/小荷物数(PPD)を表す、avg、グループi内の総パッケージ数、pi、グループi内の重み付き作業員の総数、Wi、PPDの所与の限界からの分散ペナルティ、di、下限を下回る分散、ui、上限を超える分散、vi、配送作業員、半日作業員、および歩行作業員のそれぞれの重み、α、β、およびγ、それぞれ、グループiに事前に割り当てられている配送作業員、半日作業員、および歩行作業員の人数、ai、bi、およびci、下限および上限の比率、λ、δ、それぞれ、割り当てられる必要がある配送作業員、半日作業員、および歩行作業員の総数、c、h、およびw、ならびに割り当てから除去することができないルートの本数、fi、が含まれ得る。Gは、利用可能なグループのセットも表し得る。
【0070】
再分配最適化モジュール422の整数プログラミングモデルの目的は、各キャンプの平均PDDと各グループの平均PPDとの差を最小化し、所与の閾値からの分散を最小化することである。
【0071】
再分配最適化モジュール422によって使用される整数プログラミングモデルは、追加の制約も含み得る。例えば、出勤割り振り最適化モジュール422は、すべての配送作業員の重み付き値を、w
i=α(α
i+x
i)+β(b
i+y
i)+γ(c
i+z
i)として計算し得る。出勤割り振り最適化モジュール422は、計算によって、グループレベルの平均PPDが下限閾値と上限閾値との間、またはその範囲内にあるべきことも検証し得る。
【数2】
【数3】
【0072】
再分配最適化モジュール422は、計算によって、各グループに割り当てられた異なる出勤の総数が同じタイプの出勤数と等しいことも検証し得る。出勤割り振り最適化モジュール422はまた、各タイプの作業員の妥当な上限を設定して、例えば、計算によって、各グループに割り当てられた配送作業員の総数が配送作業員の人数と等しくなる(Σi∈Gxi=c)ようにし、計算によって、各グループに割り当てられた半日作業員の総数が半日作業員の人数と等しくなる(Σi∈Gyj=h)ようにし、計算によって、各グループに割り当てられた歩行作業員の総数が歩行作業員の人数と等しくなるようにし得る。
【0073】
再分配最適化モジュール422はまた、計算によって、配送作業員の人数が、除去することができないルートの本数以上である(x
i≧f
i、∀i∈G)ようにし、計算によって、同じグループに多すぎる半日作業員が割り当てられないようにし(
【数4】
)、計算によって、各配送作業員が配達に多くても1人の歩行作業員を連れて行く(z
i≦x
i、∀i∈G)ようにし得る。
【0074】
本開示によれば、再分配最適化モジュール422は、作業員を最適に再分配するために以下の式を実施し得る(「0/1プログラミングモデル」)。
【数5】
【表2】
【0075】
0/1プログラミングモデルは、ここでは、最小化問題として理解され得る。以下で上記の変数の各々について説明する。xi、yj、zk、ulは、ルート選択に関する2値変数を表し得る。例えば、ルートiが選択される場合、xiの値は1であり、そうでない場合0である。Iは、配送作業員ルートとしての通常ルートのセットを表し、Jは、歩行作業員ルートとしての歩行作業員同伴ルートのセットを表し、Kは、新しいルートとしての新しく作成されたルートのセットを表し、Lは、半日ルートのセットを表し得る。Sは、サブルートのセットを表し得る。c、w、n、およびhは、それぞれ、配送作業員、歩行作業員、新しいルート、および半日作業員の数を表し得る。最後に、αis、αjs、αks、およびαlsは、インジケータ変数を記述し、サブルートsが、ルートi、j、k、lのうちの1つにある場合には、対応するインジケータ値は1である(そうでない場合には0である)。
【0076】
再分配最適化モジュール422における0/1プログラミングモデルの1つの目的は、評価メトリックの無効化のペナルティを最小化することである。再分配最適化モジュール422は、正規化されたPPDからの逸脱のペナルティ、複数親ルートのペナルティ、異なる親ルートからのサブルート間の横断時間のペナルティ、交換ルートのペナルティ、および移動難易度のペナルティのうちの1つまたは複数に基づいて、ルートごとのペナルティコストを計算し得る。
【0077】
再分配最適化モジュール422は、様々な制約を課し得る。例えば、再分配最適化モジュール422は、生成されたルートの本数が同じタイプでの出勤数と等しいと計算することによるものを含む、「カウント制約」を課してもよい。例えば、再分配最適化モジュール422は、計算によって、配送ルートの本数が配送作業員の人数と等しくなる(Σi∈Ixi=c)ようにしてもよく、計算によって、歩行作業員ルートの本数が歩行作業員の人数と等しくなる(Σj∈Jyj=w)ようにしてもよく、計算によって、新しいルートの本数が必要な新しく作成されたルートの本数と等しくなる(Σk∈Kzk=n)ようにしてもよく、計算によって、半日ルートの本数が半日作業員または初心者の人数と等しくなる(Σl∈Lul=h)ようにしてもよい。
【0078】
第2に、再分配最適化モジュール422は、計算によって、各サブルートがただ一度だけカバーされるようにするために、例えば、「カバー制約」を課してもよい(Σi∈Iαisxi+Σj∈Jαjsyj+Σk∈Kαkszk+Σl∈Lαlsul=1,∀s∈S)。
【0079】
いくつかの実施形態では、SATシステム101は、サブルートを組み合わせて、配送作業員(すなわち、配送作業員224Aおよび配送作業員224B)に割り当てられるべき配達のためのルートを作成し得る。各ルートは、1営業日に配達すべきベースラインパッケージ数または配達すべきベースライン宛先数を有し得る。例えば、SATシステム101は、所与のルートに、1営業日に配達すべき150個のベースラインパッケージ数または配達すべき120件のベースライン宛先数を割り当て得る。
【0080】
各ルートにおいて、SATシステム101は、(1)各サブルート内の宛先の密度、(2)各サブルート内の宛先の数量、(3)あるサブルートから別のサブルートまでの移動時間、または(4)ルートの難易度評価を含む、そのルートのベースライン数を計算するための複数のデータ要因を決定し得る。計算されたルートの難易度、サブルート内の宛先の密度、およびあるサブルートから別のサブルートまでの移動時間に応じて、SATシステム101は、その特定の日に、および/またはその特定のルート上で配達できる妥当なパッケージ数および/または配達できる妥当な宛先数(ベースライン数)を計算し得る。いくつかの実施形態では、ベースライン数が、配送作業員ごと、ルートごとに生成される(すなわち、各配送作業員の実績のある、または期待されるパフォーマンスを考慮する)。
【0081】
一実施形態では、特定のエリアで配達するための10,000個のパッケージがあり、50人の配送作業員がいる。10,000個のパッケージを50人の配送作業員で単に割る代わりに、SATシステム101は、上記の複数のデータ要因、すなわち、ルートの難易度、宛先の密度、および各サブルート内の宛先の数量に基づいて、パッケージを割り当て、サブルートの組み合わせを作成するように構成される。
【0082】
いくつかの実施形態では、配達履歴データ404が、特定のルートのベースライン数を決定するために使用され得る。例えば、SATシステム101は、平日の朝または夕方、週末の朝または夕方、祝日、混合気象条件、交通量の多さなどを含む様々な条件での特定のサブルートについての1時間あたりに平均して配達された宛先数の履歴データを利用し得る。一例では、100個のベースラインパッケージ数または100件のベースライン宛先数を配達する時間数が、交通量の多いまたは夕方の時間帯には、交通量の少ないまたは朝の時間帯よりも多くなり得る。
【0083】
ベースライン数を計算するとき、SATシステム101は、配達履歴データ404を使用して、例えば、70日間の履歴データを分析し、1時間あたり平均宛先数を決定し得る。1時間あたりの平均宛先数は、より長期間にわたって取られてもよく、かなり正確である。この計算がかなり正確なのは、平均を取る際に使用される日数が多いほど、1時間あたりの平均宛先数がより正確になるからである。
【0084】
ベースライン数をより正確にするために、SATシステム101は、各配送作業員にルートを自動的に割り当て、(配送作業員タイプ、すなわち、通常、初心者などに応じて)同じタイプの履歴APH値を使用し得る。例えば、サブルートAが主に新しい配送作業員によって、時々別の配送作業員によって配達された場合、SATシステム101は、新しい配送作業員以外の配送作業員によって行われた以前の配達試行から得られた履歴APH値を使用し得る。
【0085】
いくつかの実施形態では、履歴APH計算は、配送作業員のタイプを区別しない。配送作業員のタイプには、通常(100%の容量で配送する)、初心者(複合就業週数に応じて、30%、50%、65%の仕事量で配送する)、シニア(インセンティブの資格を得るために自発的により多くの仕事量の契約をする配送作業員)、軽(75%の仕事量でより低い月給で配送する新しい配送作業員)が含まれ得る。この場合、サブルートのセットが経験の浅い初心者の配送作業員に日常的に割り当てられている場合、それらのサブルートの70日間平均APHは、100%の仕事量で働く通常タイプの配送作業員に割り当てられた場合の平均APH(仮定として19APH)よりも低くなり得る(例えば、14APH)。
【0086】
いくつかの実施形態では、サブルート内の宛先の密度が高い場合、そのルートのベースライン数はより高くなり得る。例えば、宛先が互いに近いほど、次の宛先に到達するのがより容易になり得る。いくつかの実施形態では、サブルート内の宛先またはパッケージの数量が大きい場合、そのルートのベースライン数はより低くなり得る。いくつかの実施形態では、あるサブルートから別のサブルートまでの移動時間が長い場合、そのルートのベースライン数はより低くなり得る。いくつかの実施形態では、ルートの難易度評価が高い場合、そのルートのベースライン数はより低くなり得る。宛先の密度は、いくつかの実施形態では、1時間あたりの宛先数(APH)に基づいて測定され得る。例えば、過去70日間分のAPHが、サブルートごとに、平均的な配送作業員がそのサブルートで配達すると予想され得る宛先数を評価するために使用され得る。その範囲は、例えば、14から30APH以内であり得る。
【0087】
例えば、配達するのが非常に難しいサブルートに多くの数量がある場合、計算されるベースライン数は、数量が少なく、ルートがさほど難しくない別のルートよりも低くなるはずである。ルートの難易度が高い例が、配送速度が遅い場合、例えば、交通量が多い、速度制限が低い、道路が配送トラックには狭すぎる、または専用の駐車スペース、高速エレベータ、もしくは住宅ごとのラベルがない(よって、配送作業員がパッケージを配達すべき場所を決定するのにより多くの時間を要する)集合住宅の場合であり得る。低いルートの難易度評価に寄与し得る要因には、例えば、交通量が少ない、速度制限が高い、道路が配送トラックに十分な幅である、または専用の駐車スペース、高速エレベータ、もしくは住宅ごとのラベルがある(よって、配送作業員がパッケージを配達すべき場所を決定する時間が短くてすむ)集合住宅の場合が含まれる。いくつかの実施形態では、APHは、密度と難易度評価の両方に関連する。
【0088】
ベースライン数を上回って配達されたパッケージごとまたは配達された宛先ごとに、配送作業員は、インセンティブ、すなわち、追加の補償を受ける資格があり得る。一実施形態では、SATシステム101は、特定のルート上の配送作業員に、配達すべき150個のベースラインパッケージ数を割り当て得る。そのような実施形態では、150個のパッケージが配達された後、配送作業員は、配達されたパッケージごとに追加の支払いで補償され得る。配送作業員は、例えば、150個のパッケージ(配達すべきベースラインパッケージ数)を超えて配達される追加のパッケージごとに5米ドルを受け取る資格があり得る。別の実施形態では、SATシステム101は、特定のルート上の配送作業員に、配達すべき120件のベースライン宛先数を割り当て得る。そのような実施形態では、120件の宛先が配達された後、配送作業員は、配達された宛先ごとに追加の支払いで補償され得る。配送作業員は、例えば、120件の宛先(配達すべきベースライン宛先数)を超えて配達される追加の宛先ごとに5米ドルを受け取る資格があり得る。
【0089】
別の実施形態では、ベースラインは、配達されたパッケージ数または配達された宛先数ではなく、労働時間数であり得る。例えば、配送作業員は、配達のためのベースライン時間数として6時間を有し得る。そのような実施形態では、6時間が経過した後、配送作業員は、配達されたパッケージごとまたは配達された宛先ごとに追加の支払いで補償され得る。一例では、配送作業員は、配達のためのベースライン時間数を超えて配達される宛先ごとまたは配達されるパッケージごとに5米ドルを受け取る資格があり得る。
【0090】
いくつかの実施形態では、SATシステム101は、(例えば、ルートジェネレータ416に関して上述したように)アルゴリズムを実行して、配送作業員を配送のために送り出す30分前に各ルート割り当ておよびルートのベースラインを決定し得る。いくつかの実施形態では、アルゴリズムは、SATシステム101が配送作業員に提供する割り当ての出力を提供する。配送作業員がルートの変更を要求する場合、SATシステム101は、アルゴリズムを再実行し、配送作業員がその特定のルートを回避するために割り当ての異なる出力を作成し得る。
【0091】
さらに、配送作業員の対応可能性に基づいて、または配送作業員のルート上のパッケージ数または宛先数が多すぎる場合、例えば、キャンプゾーン215のリーダはSATシステム101に入力を提供して、ある配送作業員をあるルートから別のルートに変更し、ベースラインに変更を加え、ルートごとに割り振られ得る実際の停止箇所を変更し、サブルートをあるルートから別のルートに変更し、またはサブルートを移動してそのサブルートを別のルートに配置し得る。したがって、アルゴリズムが割り当て出力を提供する間に、SATシステム101はその割り当てを再構成し得る。いくつかの実施形態では、アルゴリズムが実行され、ルートごとのベースラインを割り振るたびに、ベースラインはデータベース上に保存される。
【0092】
図6は、開示の実施形態と一致する、キャンプゾーン215のリーダが使用するためのグラフィカルユーザインターフェース(GUI)600のシステム視覚表現の概略図である。キャンプゾーン215のリーダは、特定の日の配送に対応可能な作業員の人数およびタイプに関する情報を入力し得る。各作業員は、通常の配送作業員、半日作業員、歩行作業員、初心者またはシニアの配送作業員として分類され得る。これらの職名は各々、異なる配送経験またはスキルのレベルに相関され得る。「初心者」の分類は、新しい配送作業員または配送経験がほとんどまたは全くない配送作業員を指示する。「半日」の分類は、「フレックス作業員」であり、半日だけ働ける配送作業員を指示する。「フレックス作業員」は、スケジュールに柔軟性があり、終日と半日の両方働くことができる作業員である。「フレックス作業員」は、一日の様々な時間に働くか、毎日異なる時間働くか、または任意の他のタイプの柔軟なスケジュールで働く作業員を指し得る。通常、「半日」作業員は、完全な配送ルートではなくサブルートで操業するが、「半日」作業員には両方のルートタイプが企図されている。「歩行作業員」は、長距離を歩いてパッケージを手渡しできる配送作業員の分類を指示する。「歩行作業員」の分類の配送作業員は、トラックを使用してパッケージを配送し、トラックドライバと共にトラックを離れてパッケージを降ろし、配達し得る。「シニア」の分類は、長年にわたる有意な配送経験がある配送作業員を指示する。他の分類識別も可能であり得る。各タイプの作業員には、その分類と関連付けられた効率に基づいて異なる重み付けがされ得る。
図6に示されるように、GUI600の例示的なシステム視覚表現は、その日の配送に対応可能な作業員を確認するために作業員の人数およびタイプを入力するためのツールバーを含む。
【0093】
図6に示されるように、返されたツールバー検索結果は、対応可能な配送作業員として、「ジョン・スミス」602、「ティム・トンプソン」604、「リチャード・ジョンソン」606、および「ジェイコブ・ケリー」607を含み得る。「ジョン・スミス」は「フレックス作業員」608として分類されており、「ティム・トンプソン」は「半日」作業員610として分類されており、「リチャード・ジョンソン」は「歩行作業員」612として分類されており、「ジェイコブ・ケリー」は、「終日」作業員613として分類されている。対応可能な配達区域、ルート、およびサブルートへの近接性を指示するために、各配送作業員に隣接して住所も記載されている。一例として、「ジョン・スミス」は、「ソウル特別市中区明洞31-34、305ビル、アパート105」に位置している。
図6に示されるように、「ジョン・スミス」602は「ルート配送」614に割り当てられており、「ティム・トンプソン」604は「サブルート配送」616に割り当てられている。上記のように、「半日」作業員は(完全なルートではなく)1本または複数のサブルートに沿ってパッケージを配達し得るが、「半日」作業員には両方のルートタイプが企図されている。したがって、
図6に示されるように、「ジョン・スミス」602は完全な「ルート配送」614を行うが、「ティム・トンプソン604」は柔軟な「サブルート配送」616を行い、これは「ジョン・スミス」602が割り当てられているルートの一部を含む場合も含まない場合もある。さらに、
図6に示されるように、「ジェイコブ・ケリー607」はボリューム要求620を提供し、SATシステム101は、そのボリューム要求に応答してジェイコブ・ケリーに配達のための追加のパッケージまたは宛先を割り当てた。したがって、「ジェイコブ・ケリー607」は、ジェイコブ・ケリーのベースライン数を超える配達されたパッケージごとまたは配達された宛先ごとに追加の補償を受け取ることになる。
【0094】
さらに、
図6に示されるように、キャンプゾーン215のリーダが、各配送作業員と関連付けられた分類、スケジュール、重み、効率、およびその他の特徴を閲覧できるようにする他のグラフィカルインターフェースコンポーネントが含まれている。例えば、ステータスバー620は、「人数/タイプ/作業員」、「進行中」、「完了」、「未完了」、「受領拒否」、および「分類」についての状況を含んでいてもよく、これらは各々異なる情報を提供する。
【0095】
「人数/タイプ/作業員」は、配送作業員の人数およびタイプの状況または記述を指示し得る。「進行中」は、現在行われている配達の数を指示し得る。「完了」は、完了した注文の数を指示し得る。「未完了」は、未完了の配達の数を指示し得る。「受領拒否」は、注文の受領を拒否した受取人の人数を指示し得る。「分類」628は、利用可能な、現在リアルタイムの配達に用いられている分類の総数(例えば、フルタイム作業員の人数対フレックス作業員の人数)を指示し得る。配送作業員の割り当ておよび事前割り当てを可能にする他のGUI600のグラフィカルコンポーネントも企図されている。
【0096】
加えて、配送作業員は、
図2のモバイルデバイス107A上で動作しているモバイルアプリケーションを使用して、例えば、毎就業日の仕事のチェックインおよびチェックアウトを行うと共に、ボリューム要求およびインセンティブプログラムの契約も行い得る。
【0097】
いくつかの実施形態では、作業員の効率特性は、計算されたベースライン数からの仕事量増加のパーセントに対応し得る。例えば、SATシステム101は現在、インセンティブプログラムへの参加を自発的に申し込んだ配送作業員にシニア配送作業員とラベル付けしている。SATシステム101は、シニアA、シニアB、シニアC、シニアDを含む4タイプの配送作業員を有し得る。「A」は最高の比率を有し、平均して、シニア「A」は、ベースラインより20%多い仕事量を割り当てられ得る。シニア「B」は、ベースラインより15%多い仕事量を割り当てられ、シニア「C」は、ベースラインより10%多い仕事量を割り当てられ、シニア「D」は、ベースラインより5%多い仕事量を割り当てられ得る。
【0098】
いくつかの実施形態では、SATシステム101は、配送作業員を、追加のパッケージを配達するか、または追加の宛先に配達する(すなわち、別の配送作業員を支援する)よう自動的に割り当て、それによって、配送作業員をインセンティブプログラムに自動的に割り当て得る。例えば、SATシステム101がサブルートの組み合わせに基づいてルートを配置する場合、SATシステム101は、効率上の理由でサブルートをより小さい構成要素に分割しない場合がある。さらに、サブルートの分割は過剰な計算を必要とすることになる。よって、サブルートAまたはBにその日の特定の数量がある場合、SATシステム101はそれらを分割しない場合がある。たとえベースラインが130であっても、サブルートの組み合わせには追加の停止箇所がある。SATシステム101はサブルートを分割しない場合があるので、SATシステム101は代わりに、別の配送作業員に余分な宛先を割り当て得る。
【0099】
別の実施形態では、新しい配送作業員またはそのルートであまり経験のない配送作業員がおり、その配送作業員がそのルートのベースラインを満たすことができず、SATシステム101は、支援のために別の配送作業員に追加のパッケージまたは宛先を割り当て得る。そのような実施形態では、追加のパッケージまたは宛先を割り当てられた配送作業員は、ベースラインを超える配達されたパッケージごとまたは配達された宛先ごとに追加の支払いで補償され得る。
【0100】
さらに、そのような実施形態では、SATシステム101が配達を別の配送作業員に振り替えるときに、キャンプゾーン215のリーダによって使用されるグラフィカルユーザインターフェース(GUI)600はその変更を反映し得る。例えば、配送作業員Aが自分のベースラインを満たすことができない場合、システムはパッケージXの配達を配送作業員Bに振り替え得る。SATシステム101は、グラフィカルユーザインターフェース(GUI)600上にパッケージXの配達を配送作業員Aにより「進行中」と記載しなくなり、グラフィカルユーザインターフェース(GUI)600上にパッケージXの配達を配送作業員Bにより「進行中」として更新し得る。事実上、配送作業員Bは、それらのパッケージが配送作業員Bのベースラインを上回った場合には、パッケージの配達について追加の補償を受け取り得る。より具体的には、その日の配送の後、SATシステム101は、実際に配達された宛先数を配送作業員Bのベースラインと比較し得る。ベースラインを超えて配達された宛先(またはパッケージ)ごとに、配送作業員Bは宛先ごとのインセンティブを支払われ得る。
【0101】
図7は、開示の実施形態と一致する、モバイルデバイス上のグラフィカルユーザインターフェース(GUI)の視覚表現の概略図である。
図7に示されるように、モバイルデバイスインターフェース700は、インターフェース600と同様であるが、配送作業員に表示するように構成されたインターフェースを提供し得る。モバイルデバイスインターフェース700は、配送作業員により閲覧可能であり得る。例えば、
図7に示されるように、モバイルデバイスインターフェース700は、「ジョン・スミス」という名前の作業員に割り当てられたインターフェースを含む。インターフェース700は、ジョン・スミスの「フレックス作業員608」としての分類を含み、配達日702「2019 03 07」(すなわち、2019年3月7日)、配達開始点または宛先住所704「ソウル特別市江南区三星1洞テヘラン路447」を指示し、配送作業員の効率または重み評価706を含み、配送作業員を案内するための道路、レストラン、およびランドマークを含む配達先付近の地
図708をさらに含む。配送作業員の配達を支援するために、図示されていない他のグラフィカルコンポーネントも企図され、モバイルデバイスインターフェース700に含まれ得る。
【0102】
上記のように、いくつかの実施形態では、SATシステム101は、配送作業員を、追加のパッケージを配達するか、または追加の宛先に配達する(すなわち、別の配送作業員を支援する)よう自動的に割り当て、それによって、配送作業員をインセンティブプログラムに自動的に割り当て得る。そのような実施形態では、SATシステム101が配達を別の配送作業員に振り替えると、振替元の配送作業員によって操作されるモバイルデバイスインターフェース700および振替先の配送作業員によって操作されるユーザインターフェースモバイルデバイスインターフェース700がその変更を反映し得る。例えば、配送作業員Aが自分のベースラインを満たすことができない場合、システムはパッケージXの配達を配送作業員Bに振り替え得る。配送作業員Aのモバイルデバイスインターフェース700はパッケージXを記載しなくなり、配送作業員Bのモバイルデバイスインターフェース700は配達のためのパッケージXを記載することになる。
【0103】
図8は、開示の実施形態と一致する、配送作業員を割り当て、配送ルートを管理するための例示的なプロセスを示す流れ図である。例示的な方法800は、本明細書では一連のステップとして説明されているが、ステップの順序は他の実施態様では異なり得ることを理解されたい。特に、ステップは、任意の順序で、または並行して行われ得る。
【0104】
ステップ802で、予想配送効率ジェネレータ406がデータベース401から地理データ402および履歴データ404を取得し得る。地理データ402および履歴データ404は、複数の配送ルートおよび複数の配送サブルートを各々含み得る。予想配送効率ジェネレータ406は、複数の事前に定義された区域および複数の小区域と関連付けられた地理データ402を受け取り得る。地理データ402は、地形データ、業務データ、住宅データ、駐車データ、または建物データのうちの少なくとも1つを含み得る。サブルートまたは小区域データは、ルートまたは区域データの一部として存在し得る。履歴データ404は、配達場所、配達時間、配送ドライバ、および/または配達パッケージのうちの1つまたは複数を含む、過去の配達に関するデータ得る。
【0105】
ステップ804で、予想配送効率ジェネレータ406が、取得された地理データ402および履歴データ404に基づいて、予想配送効率(APH値)を計算し得る。予想配送効率ジェネレータ406は、その計算を、取得された配送ルートおよび配送サブルートに割り振られたパッケージ数にも基づいて行い得る。予想配送効率ジェネレータ406は、1時間あたりに作業員によって訪問された宛先のパーセンタイル(APH)によって測定される、予想配送効率を決定し得る。予想配送効率ジェネレータ406は、履歴データ404に基づいて、選択された個々の事前に定義された区域および小区域のAPHをさらに計算し得る。いくつかの実施形態では、クロスタイムジェネレータ408が、履歴データ404に基づいて各区域および小区域におけるAPHのパーセンタイル値を計算し得る。いくつかの実施形態では、特定のパーセンタイルが、予想配送効率として決定され得る(例えば、第60パーセンタイル)。他の態様では、予想配送効率は、配達のための時間および配送作業員のスキルまたは経験を考慮に入れ得る。
【0106】
ステップ806で、クロスタイムジェネレータ408が、履歴クロスタイム生成モジュール410を実施して、時間的ギャップの中央値または平均時間決定するに基づく区域間時間501および小区域502、504時間を含む、作業員が(
図5に示されるように)第1の区域502と第2の区域504との間を移動するための予想時間を計算し得る。履歴クロスタイム生成モジュール410は、最近3ヵ月の期間内の2つの区域または小区域間の時間的ギャップの中央値を使用し得る。この期間は、横断時間だけでなく注文の配達時間も含み得る。時間的ギャップの中央値が存在しないか、またはデータサンプルの数が2以下である場合、履歴クロスタイム生成モジュール410は、キャンプゾーン215内の平均区域間/小区域時間を実施し得る。
【0107】
ステップ808で、クロスタイムジェネレータ408のクロスタイム完了および較正モジュール412が、「運転時間」506、「駐車時間508」、「仕分け時間」510、および「配達時間」512を決定し得る。クロスタイム完了および較正モジュール412は、マップサービスモジュール430と通信して、任意の2つの区域または小区域間の「運転時間」506を取得し得る。次いでクロスタイム完了および較正モジュール412が、線形回帰を行って、「運転時間」とクロスタイム501との間の数学的関係を取得し得る。クロスタイム完了および較正モジュール412は、取得された数学的関係およびマップサービスモジュール430から取得された運転時間を利用してクロスタイム501を決定し、時間値のクロスタイム501行列を作成し得る。クロスタイム完了および較正モジュール412は、作成された時間値の行列をさらに利用して、新しく計算されたクロスタイム501を確定、完了、および較正し得る。
【0108】
ステップ810で、ルートジェネレータ416が、グループに配送作業員の人数を割り振り得る。ルートジェネレータ416は、デバイス119A~119Cから、ユーザ構成および優先設定414入力、ならびに配達に対応可能な作業員の人数およびタイプを受け取り、タイプは、作業員と関連付けられた分類特性および効率特性を含む。ユーザ入力は、GUIにおける情報の手入力を含み得る。各作業員は、ユーザ構成および優先設定414基づいてによって、「半日」、「歩行作業員」、「初心者」、または「シニア配送作業員」のうちの1つに分類され得る。各タイプの配送作業員には、その分類と関連付けられた効率に基づいて異なる重み付けがされ得る。ルートジェネレータ416は、作業員を、分類特性に従って複数のカテゴリ(またはグループ)のうちの少なくとも1つに分類し(または割り振り)、分類特性に基づいて、効率特性に従って配送作業員に重み付けし得る。重みは、個々のユーザが期間中に取得できるパッケージの数を決定するために使用され得る。例えば、半日配送作業員は、通常の配送作業員(100%)と同数の半分のパッケージ(すなわち、50%)を配達および輸送してもよく、シニア配送作業員は、通常の配送作業員と比較して120%のパッケージを取得し得る。重みは、作業員ごとの予想される配達パッケージ数に基づくものであり得る。他の重みも企図され、分類特性は、経験または効率の少なくとも1つを含み得る。
【0109】
ルートジェネレータ416の出勤割り振り最適化モジュール418は、受け取られたユーザ入力に加えて計算されたパッケージ数に基づいて、グループに配送作業員の人数を割り振り得る。出勤割り振り最適化モジュール418は、配送作業員を、異なる配送ルートおよび異なる配送サブルートに対応する複数のグループにさらに割り当て得る。これは、パッケージ分配および出勤値を含むユーザ入力に基づいてグループに作業員の人数を割り振ることを含み得る。一例として、50人の配送作業員および4つのグループがある場合、出勤割り振り最適化モジュール418は、「グループ1」は10人の配送作業員を含むと判断し、出勤割り振り最適化モジュール418は、10人の配送作業員のための10本の配送ルートを生成することになる。続いて、配送10ルートが生成された後、キャンプリーダが、どの作業員がどのグループおよびルートに割り振られるかを決定し得る。例えば、キャンプリーダは、「ボブ」は「グループ1」で「ルート1」を占有し、「スティーブ」は「グループ1」で「ルート2」を占有すると決定し、この割り当てを、ユーザインターフェース(
図6)でのユーザ入力に基づいて行い得る。他の数の配送作業員およびグループも企図され得る。本開示によれば、出勤割り振り最適化モジュール418は、特定のグループに事前に割り当てられた配送作業員への利用可能なパッケージおよびサブルートの割り当ても行い得る。この割り当てにより、配送トラックで製品を仕分けするタスクがドライバからキャンプゾーン215のヘルパーに振り替えられ、よって動的配送プロセスの効率が向上し得る。
【0110】
出勤割り振り最適化モジュール418は、割り当てに基づいて、割り当てられた作業員を配送ルートおよび配送サブルートに対して比較し得る。出勤割り振り最適化モジュール418は、1本のルートおよびサブルートあたりのパッケージ数も決定し得る。出勤割り振り最適化モジュール418は、作業員を異なるグループに割り当る、出勤割り当てを行い、作業員配達あたりのパッケージ数の平均値に基づいてグループの平均偏差値を計算し得る。この計算は、キャンプの平均ppdからのグループのドライバ1人あたりの平均パッケージ数(ppd)の平均偏差を最小化するように行われ得る。上記のように、出勤割り振り最適化モジュール418は、1グループあたりの配送作業員の人数を決定し、出勤割り振り最適化モジュール418は、個々のグループに割り振られた配送作業員の人数に対応するルートの本数を生成し得る。続いて、配送ルートが生成された後、キャンプリーダは、どの作業員がどのグループおよびルートに割り振られるかを決定し得る。他の数の配送作業員およびグループも企図され得る。他の実施形態では、配送作業員は、出勤割り振り最適化モジュール418および出勤割り当てに基づいて割り当てられるのではなく、グループに事前に割り当てられ得る。本開示によれば、キャンプリーダは、作業員を事前に割り当てるためにインターフェース(
図6)に配送作業員情報を入力し得る。他の出勤割り当ておよび事前割り当ての手配も企図され得る。
【0111】
ステップ812で、ルートジェネレータ416のシード分配生成モジュール420が、区域を作成し、余分な区域を削除し得る。シード分配生成モジュール420は、ユーザによって構成された規則と、配送作業員の分類(例えば、「ロートップ」、「職人優先」、および「その他の規則」)とに基づいて区域を生成し得る。上記のように、「ロートップ」の分類は、大型トラックではなく、屋根が低い車両に配達物を積み込む経験を有する配送作業員を指示し得る。「職人優先」の分類は、あらゆる種類の便利屋または荷積みのスキルを持ち、様々な複雑さを有する様々なタイプのタスクを行うことができる配送作業員を指示し得る。「その他の規則」の分類は、目下の特定の配達要件に基づいて指定され得る「その他の規則」を指示し得る。シード分配生成モジュール420は、分類、配送ルートおよび配送サブルートと関連付けられた配達区域および配達小区域を生成し、生成された配達区域と生成された配達小区域とを組み合わせ、生成された配達区域および生成された配達小区域を除去し得る。シード分配生成モジュール420はまた、分類、履歴データ、およびマップデータ最適化に基づいて配送ルートおよび配送サブルートを生成し得る。
【0112】
ステップ814で、ルートジェネレータ416の再分配最適化モジュール422が、シード分配生成モジュール420によって生成または削除された区域に基づいて新しい候補区域を作成し得る。再分配最適化モジュール422は、候補ルートと関連付けられた新しい候補配達区域および候補配達小区域も作成し得る。再分配最適化モジュール422は、作業員の分類ごとの候補ルートを生成することによってルートバランシングも行い得る。再分配最適化モジュール422は、シード分配生成モジュール420によって生成された配送ルートの量および配送サブルートの量を、割り当てられた作業員の量と一致するようにさらに変更し得る。再分配最適化モジュール422は、割り当てられた作業員の量と一致するように配送ルートの量を増減させ、配送サブルートの量を増減させ得る。この変更は、ルートバランシング問題の複雑さを低減させるために行われるヒューリスティックな方法であり得る。例えば、上記のように、割り当てられた配送作業員が割り当てるべきルートと比較され、再分配最適化モジュール422は、配送からルートを追加または除去することによってそれら2つを等しくしようと試み得る。
【0113】
ステップ816で、ルートジェネレータ416の再分配最適化モジュール422が、区域の最適な組み合わせを決定し得る。再分配最適化モジュール422は、生成された候補配達区域と生成された候補配達小区域とを組み合わせ、生成された候補区域および生成された候補配達小区域を除去し、配送コストを最小化するように生成された候補配達区域と生成された候補配達小区域との組み合わせを決定し得る。再分配最適化モジュール422は、配送コストを最小化するように候補配達区域および候補配達小区域のうちの少なくとも1つを再分配し得る。再分配最適化モジュール422は、(
図4を参照して説明したように)「0/1プログラミングモデル」を解くことに基づいて区域の最適な組み合わせを決定し得る。他の最適化法も企図および実施され得る。
【0114】
ステップ818で、ルートジェネレータ416の訪問順序最適化モジュール424が、区域内の最善の訪問順序を決定し得る。訪問順序最適化モジュール424は、変更された量および生成された候補ルートに基づいて、選択された配送サブルートを較正し得る。訪問順序最適化モジュール424は、配達および作業員割り当てのために配送サブルートのうちの1つまたは複数を自動的に選択し得る。訪問順序最適化モジュール424は、特定のサブルートを一緒に保つために、サブルート訪問順序調整を行い得る。サブルートを一緒に保つための他の調整も行われ得る。加えて、訪問順序最適化モジュール424は、(
図4に示されるように)最適なルート428を生成し、区域内の最善の訪問順序を実施するために、訪問順序最適化の後でパッケージ(小荷物)分配426に関する入力を受け取り得る。
【0115】
ステップ820で、ルートジェネレータ416は、(
図1、
図4、および
図8に示されるように)最適なルート428をデバイス119A~119Cに伝達し得る。最適なルートは、割り当てられた配達パッケージを効率的に配達するよう配送作業員を案内するための最適なルートおよびサブルートを含み得る。
【0116】
本開示はその特定の実施形態を参照して示され、説明されてきたが、本開示は修正なしに、他の環境において実施され得ることが理解されるであろう。前述の説明は、例示の目的で提示されている。これは、網羅的ではなく、開示された正確な形態または実施形態に限定されない。当業者には、開示された実施形態の仕様および実施を考慮することによって、修正および適合が明らかになるであろう。加えて、開示された実施形態の態様はメモリに格納されるものとして記載されているが、当業者はこれらの態様を、二次記憶デバイス、例えば、ハードディスクもしくはCD ROM、または他の形態のRAMもしくはROM、USB媒体、DVD、ブルーレイ、または他の光学ドライブメディアなどの他のタイプのコンピュータ可読媒体に格納することもできることを理解するであろう。
【0117】
記載された説明および開示された方法に基づくコンピュータプログラムは、熟練した開発者の技術の範囲内である。様々なプログラムまたはプログラムモジュールを、当業者に公知の技法のいずれかを使用して作成することができ、または既存のソフトウェアに関連して設計することができる。例えば、プログラムセクションまたはプログラムモジュールを、.Net Framework、.Net Compact Framework(およびVisual Basic、Cなどの関連言語)、Java、C++、Objective-C、HTML、HTML/AJAXの組み合わせ、XML、またはJavaアプレットを含むHTMLで、またはそれらによって設計することができる。
【0118】
さらに、例示的な実施形態が本明細書で説明されてきたが、本開示に基づいて当業者によって理解されるような同等の要素、修正、省略、組み合わせ(例えば、様々な実施形態にわたる態様の)、適応、および/または変更を有する任意のおよびすべての実施形態の範囲。請求項の限定は、請求項で使用されている文言に基づいて広く解釈されるべきであり、本明細書に記載されている、または出願審査中の例に限定されない。例は、非排他的であると解釈されるべきである。さらに、開示された方法のステップは、ステップを並べ替えること、および/またはステップを挿入もしくは削除することによるものを含む、任意の方法で修正されてもよい。したがって、本明細書および例は単に例示的なものとみなされ、真の範囲および精神は以下の特許請求の範囲およびそれらの均等物の全範囲によって示されることが意図される。