JP2022501682A - コンピュータ化されたバランスの取れた配送ルート割り当ておよびインセンティブ構造のためのシステムおよび方法 - Google Patents

Abstract

出勤割り当てのためのシステム。本システムは、命令を格納するメモリと、命令を実行して動作を行うように構成されたプロセッサとを含み得る。動作は、複数の配送ルートおよび、配送ルートの一部である、複数の配送サブルートを取得することと、配送サブルートに割り振られたパッケージ数を計算することと、配送に対応可能な作業員の人数およびタイプを受け取ることであって、タイプが分類特性または効率特性の少なくとも１つを含む、ことと、追加の配達を有する複数のサブルートに複数の作業員を割り当てることであって、サブルートの割り当てが、複数の作業員に割り当てられたベースライン数およびルートの難易度に基づくものである、ことと、受け取った第１の入力、およびルートの難易度、複数の候補ルートを生成することと、変更された配送サブルートのうちの少なくとも１つを電子デバイスに転送することと、を含み得る。

Description

本開示は、一般に、配送を最適化し、配達インセンティブ構造を提供するように配送作業員を割り当て、配送ルートを管理するためのコンピュータ化されたシステムおよび方法に関する。特に、本開示の実施形態は、一般に、配達エリアを、利用可能なパッケージ分配および対応可能な配送作業員リソースに基づく区域に動的に区切り、配送作業員に利用可能なパッケージ、ルート、およびサブルートを割り当てるための発明的な非従来型のシステムに関する。本開示の実施形態は、ルートの難易度、各ルートに固有のベースライン数、サブルートの密度、およびサブルート内の宛先の数量を計算して、配送のための追加のパッケージを有する候補ルートを自動的に、または追加の仕事を要求する入力（ボリューム要求）に応答して生成することにも関する。特定のルートの計算されたベースラインを超えて配達された宛先またはパッケージごとに配送作業員に追加の支払いを含むインセンティブが提供され得る。

多くのコンピュータ化された在庫管理システムおよび配送センタが存在する。これらのシステムおよびセンタは、確立された配達エリアでの商品の効率的な分配を可能にし、例えば、地域の出荷センタで、これらの商品を消費者に配達するために利用可能なリソースを利用するように設計される。従来は、各配送センタがその確立された配達エリアを別々の区域または小区域に分割し、次いでこれらのシステムが、それらの区域または小区域のうちの１つまたは複数に商品を配達するよう配送作業員に指図し得る。

ただし、通常、これらの区域の各々は事実上固定されており、各区域は１人の配送作業員によってのみカバーされ、その配送作業員が区域の配達需要に追いつけない場合もある。さらに、従来のシステムは、区域境界をリアルタイムで動的に変更したり、配送作業員の区域割り当てを調整したりできない。さらに、従来のシステムは、動的な、または変化する配送数量に柔軟に対応することができないことがよくある。しかも従来のシステムには、配送車両の積載制限を分析したり、配送作業員の配送効率やスキルを考慮したりする備えもない。

しかも、トラックにパッケージを積み込み、配送ドライバがたどることになるサブルートを選択するための先行技術のシステムは、一般に手動であり、ドライバの経験に依拠している。配送作業員が配送トラックの積み込みおよび場所から場所への迅速な運転を効率よく行えるようになるには、同じルートを３〜５年間定期的に運転する必要があり得る。ルートおよびサブルートは、一般に固定されており、日々変化するものではない。あるルートに多くのパッケージがある場合、その特定のルートに割り当てられたドライバには過剰な負担がかかるが、別のドライバは十分に活用されない場合があり、現在のコンピュータ化されたシステムは、これらの問題に対応できない。加えて、配送ドライバが配送トラック内でパッケージを仕分けするタスクに時間を要する場合もある。

加えて、先行技術のシステムは、時間ベースのインセンティブモデルを用いる。そのようなシステムは、配送作業員の労働時間または残業時間に基づくものであり得る。しかしながら、先行技術のシステムは、残業時間内に配達された宛先またはパッケージごとのインセンティブも追加の支払いも提供しない。そのようなシステムは、すでに有能である作業員にとって有益であり、有能ではない配送作業員がより有能になるための動機付けになり得る。

したがって、必要とされているのは、配送作業員を動的に割り当て、配達エリアを動的に較正して、リアルタイムで配送を最適化するための区域、ルート、およびサブルートにすることができるシステムである。さらに、必要とされているのは、毎日のパッケージ分配および対応可能な配送作業員リソースの変化に基づいて配送条件の予測できない変化を迅速および柔軟に処理することができるデジタル配送ソリューションである。さらに、必要とされているのは、動的な配送数量を円滑化し、輸送車両の積載容量を増やし、配送作業員ごとの配送効率および対応可能な労働時間を増大させ、各配達区域に固有の環境特性および特徴をリアルタイムで監視および更新するための改善された方法およびシステムである。

最後に、必要とされているのは、配達のための追加のパッケージまたは宛先を有する候補ルートを生成するために、ルートの難易度、ルートごとの配達されるべきベースラインパッケージ数または配達されるべきベースライン宛先数、サブルートの密度、およびサブルート内の宛先の数量を計算することによってインセンティブプログラムを提供するための改善された方法およびシステムである。計算されたベースライン数を超えて配達された宛先またはパッケージごとに配送作業員に追加の支払いを含むインセンティブが提供され得る。そのようなシステムは、配送効率を高め、究極的には消費者にも利益を提供することになるはずである。

本開示の一態様は、出勤割り当てのためのシステムを対象とする。本システムは、メモリと、命令を実行して動作を行うように構成されたプロセッサとを含み得る。動作は、データベースから、複数の配送ルートおよび、配送ルートの一部である、複数の配送サブルートを取得することと、配送サブルートに割り振られたパッケージ数を計算することと、第１の入力として、配送に対応可能な作業員の人数およびタイプを受け取ることであって、タイプが、分類特性または効率特性の少なくとも１つを含む、ことと、追加の配達を有する複数のサブルートに複数の作業員を割り当てることであって、追加の配達を有するサブルートの割り当てが、複数の作業員に割り当てられたベースライン数およびルートの難易度に基づくものである、ことと、分類特性、受け取った第１の入力、およびルートの難易度に基づいて、複数の候補ルートを生成することと、変更された配送サブルートのうちの少なくとも１つを、配送作業員と関連付けられた電子デバイスに転送することと、を含み得る。

本開示の別の態様は、出勤割り当てのための方法を対象とする。本方法は、データベースから、複数の配送ルートおよび、配送ルートの一部である、複数の配送サブルートを取得することと、配送サブルートに割り振られたパッケージ数を計算することと、第１の入力として、配送に対応可能な作業員の人数およびタイプを受け取ることであって、タイプが、分類特性または効率特性の少なくとも１つを含む、ことと、追加の配達を有する複数のサブルートに複数の作業員を割り当てることであって、追加の配達を有するサブルートの割り当てが、複数の作業員に割り当てられたベースライン数およびルートの難易度に基づくものである、ことと、分類特性、受け取った第１の入力、およびルートの難易度に基づいて、複数の候補ルートを生成することと、変更された配送サブルートのうちの少なくとも１つを、配送作業員と関連付けられた電子デバイスに転送することと、を含む動作を行い得る。

本開示のさらに別の態様は、システムを対象とする。本システムは、地理データおよび配達履歴データを含むデータベースを含んでいてもよく、地理データは事前に定義された区域および小区域に格納される。配送システムは、複数の事前に定義された区域および複数の小区域から、地形データ、業務データ、住宅データ、駐車データ、または建物データのうちの少なくとも１つを含む、地理データを受信し、地理データに基づいて、１時間あたりに作業員によって訪問された宛先のパーセンタイル（ＡＰＨ）によって測定される、予想配送効率を決定し、配達履歴データに基づいて、選択された個々の事前定義された区域および小区域のＡＰＨを計算するように構成された、ソフトウェアまたはハードウェアで実施された予想配送効率ジェネレータを含み得る。本システムは、時間的ギャップの中央値または平均時間に基づく区域間時間および小区域時間を含む、作業員が第１の区域と第２の区域との間を移動するための予想時間を計算し、線形回帰および区域間時間に基づいて、第１の区域と第２の区域との間の運転時間を決定する、ように構成された、ソフトウェアまたはハードウェアで実施されたクロスタイムジェネレータを含み得る。本システムは、ルートの難易度ならびに、パッケージ分配、出勤値、およびボリューム要求を含むユーザ入力に基づいてグループに作業員の人数を割り振り、配送ルートおよび配送サブルートと関連付けられた配達区域および配達小区域を生成し、生成された配達区域と生成された配達小区域とを組み合わせて新しい配達区域にし、配送作業員と関連付けられた電子デバイスに少なくとも１つのサブルートを転送する、ように構成された、ソフトウェアまたはハードウェアで実施されたルートジェネレータをさらに含み得る。本明細書では他のシステム、方法、およびコンピュータ可読媒体も説明される。

開示の実施形態と一致する、出荷、輸送、および物流の業務を可能にする通信のためのコンピュータ化されたシステムを含むネットワークの例示的な実施形態を示す概略ブロック図である。 開示の実施形態と一致する、検索要求を満たす１つまたは複数の検索結果をインタラクティブなユーザインターフェース要素と共に含む検索結果ページ（ＳＲＰ）のサンプルを示す図である。 開示の実施形態と一致する、製品および製品に関する情報をインタラクティブなユインターフェース要素と共に含む単一表示ページ（ＳＤＰ）のサンプルを示す図である。 開示の実施形態と一致する、仮想ショッピングカート内のアイテムをインタラクティブなユーザインターフェース要素と共に含むカートページのサンプルを示す図である。 開示の実施形態と一致する、仮想ショッピングカートからのアイテムならびに購入および出荷に関する情報をインタラクティブなユーザインターフェース要素と共に含む注文ページのサンプルを示す図である。 開示の実施形態と一致する、開示のコンピュータ化されたシステムを利用するように構成された例示的なフルフィルメントセンタの概略図である。 各々が個々の配送作業員に割り当てられる、区切られた固定配達区域を含む従来の出荷エリアを識別する先行技術の概略図である。 開示の実施形態と一致する、本明細書に記載されるシステムおよび方法によって使用される、予想配送効率ジェネレータ、クロスタイムジェネレータ、およびルートジェネレータを含む配送モジュールの概略図である。 開示の実施形態と一致する、クロスタイムジェネレータによって決定されたデータ構造に格納されたクロスタイムデータの表現の概略図である。 開示の実施形態と一致する、配送管理者が使用するためのグラフィカルユーザインターフェース（ＧＵＩ）のシステム視覚表現の概略図である。 開示の実施形態と一致する、モバイルデバイス上のグラフィカルユーザインターフェース（ＧＵＩ）の視覚表現の概略図である。 開示の実施形態と一致する、配送作業員を割り当て、配送ルートを管理するための例示的なプロセスを示す流れ図である。

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

本開示の実施形態は、配送を動的に最適化するように配送作業員を割り当て、配送ルートを管理するように構成されたシステムおよび方法を対象とする。

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

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

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

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

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

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

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

外部フロントエンドシステム１０３は受信したプロダクトインフォメーションに基づいて、ＳＤＰ(単一ディテールページ）（例えば、図１Ｃ）を準備することができる。ＳＤＰはまた、「今すぐ買う」ボタン、「カードに追加する」ボタン、数量欄、アイテムの写真等のような他の対話型要素を含んでもよい。外部フロントエンドシステム１０３は（例えば、ネットワークを介して）要求側ユーザデバイスにＳＤＰを配信することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図３は、各々が配達を行うために個々の配送作業員に割り当てられる、区切られた固定配達区域を含む従来の出荷エリアの概略図である。図３に示されるように、町、地方自治体、地区、郡、または州などの地理的領域は、固定区域３０２および小区域３０４を含む様々な大きさの複数の区域に区切られ、各区域または小区域は固定された境界を含み得る。地理的領域は小区域にさらに分割されてもよく、配送作業員２２４Ａ、２２４Ｂは、固定された地理的境界に従って区域または小区域のうちの１つまたは複数に商品を配達し得る。従来、図３の各区域または小区域は、その区域または小区域への配達を行うために１人だけの配送作業員に割り当てられる。

一部の先行技術のコンピュータ化されたシステムは、時間ベースのインセンティブモデルを用いる。これらの先行技術のシステムでは、配送作業員２２４Ａ、２２４Ｂは、区域または小区域のうちの１つまたは複数（すなわち、固定区域３０２および小区域３０４）に商品を配達し、配送作業員２２４Ａ、２２４Ｂは、区域におけるベースライン数を超えて配達された追加のパッケージ数または配達された宛先数に基づいて追加の支払いを受け取り得る。ただし、これらの先行技術のシステムでは、残業時間内に、または計算されたベースライン数を超えて配達された宛先またはパッケージごとのインセンティブも追加の支払いもない。ベースライン数を超えた後に配達された宛先またはパッケージごとのインセンティブを有するシステムは、すでに有能である配送作業員にとって有益であり、有能ではない配送作業員がより有能になるための動機付けにもなり得る。加えて、記載の実施形態は、配達のためのパッケージの独創的な割り当てを可能にする。配送作業員がベースラインを超えた後にインセンティブを提供することにより、配達されるべきパッケージの処理残が減ることになる。さらに、この構造は、１人の配送作業員が配達を管理できない緊急時に有益である。処理残を増やす代わりに、システムは、アルゴリズムを臨機応変に実行し、遅延を回避するためにパッケージを再割り当てし得る。

図４は、開示の実施形態と一致する、ソフトウェアまたはハードウェアで実施される、本明細書に記載されるシステムおよび方法によって使用される、予想配送効率ジェネレータ４０６、クロスタイムジェネレータ４０８、およびルートジェネレータ４１６を含む配送モジュールの概略図４００である。図４（および他の図）に示されるアーキテクチャおよび個々のモジュールは単なる例示である。

図４に示されるように、データベース４０１は、地理データ４０２および配達履歴データ４０４を含む。地理データ４０２は、事前に定義された区域および小区域を含む地理情報を含み得る。小区域は、単一の事前に定義された区域のより小さい部分として存在し得る。単一の区域内には複数の小区域が存在していてもよく、小区域は、同じ地理的特性を有するエリアを構成し得る。いくつかの態様では、小区域はそれ以上分割できない場合もある。一例として、事前に定義された区域は、郡、州、または郵便番号を含み得る。別の例として、小区域は、町、地方自治体、都市、または他の場所を含み得る。区域および小区域は、前述の例に限定されない。実際、小区域が郡として存在していてもよく、または区域が町として存在していてもよい。区域および小区域の他の地理的な例も企図され、データベースからアクセス可能であり得る。配達履歴データ４０４は、配達場所、配達時間、配送ドライバ、および／または配達パッケージを含むデータを含み得る。他のタイプの履歴も可能である。いくつかの実施形態では、配達履歴データ４０４は、過去７０日間の１時間あたりの平均宛先数の履歴データを含み得る。したがって、配達履歴データ４０４は、ルートの難易度および配送作業員２２４Ａ、２２４Ｂのベースライン数を決定するために使用され得る。

予想配送効率ジェネレータ４０６は、データベースと通信し、各区域または小区域における予想配送効率を決定するために地理データ４０２および配達履歴データ４０４の各々を取得し得る。一例として、予想配送効率ジェネレータ４０６は、地形、業務エリア、住宅エリア、駐車エリア、または建物の記述のうちの１つまたは複数にさらに依拠して、予想配送効率を決定し得る。予想配送効率ジェネレータ４０６は、地理データ、履歴データ、および地形または業務データの各々を組み込み、格納された宛先データと比較して、予想配送効率を計算し得る。比較は、合計配達数またはフィルタリングされた期間にわたって特定の宛先に対して行われた個々の配達を評価し、地理データ、履歴データ、地形または業務データに基づいて、（１つまたは複数の）配達時間、（１つまたは複数の）距離、または他の基準もしくはメトリックを使用して効率値（１時間あたりの宛先数（ＡＰＨ）など）を計算し得る。予想配送効率ジェネレータ４０６は、予想配送効率として絶対効率に加えて相対効率値も計算し得る。相対効率値は、異なる配送地形または区域に基づくパーセンテージ値（例えば、６０％または７０％、Ｐ６０またはＰ７０とも呼ばれる）を含み得る。絶対効率値は、絶対値（例えば、１８パッケージ／時や２０パッケージ／時）を含み得る。各区域または地形は様々な配達地勢を有し得るので、絶対値の効率値よりも相対効率値の方が好ましい場合がある。さらに、予想配送効率ジェネレータ４０６はＡＰＨメトリックを計算してもよく、ＡＰＨメトリックは１時間または他の期間内に配送作業員が訪問できる宛先数を表し、このメトリックは、他の計算されたＡＰＨ値に対する値を含み得るか、または絶対値を表し得る。各区域または小区域におけるＡＰＨのパーセンタイル値が履歴データに基づいて計算され得る。いくつかの態様では、特定のパーセンタイルが、予想配送効率として決定され得る（例えば、相対効率値として第６０パーセンタイルまたはＰ６０）。他の態様では、予想配送効率は、配達のための時間および配送作業員のスキルまたは経験を考慮に入れ得る。

本開示によれば、予想配送効率ジェネレータ４０６は、３ヵ月以下の履歴データに基づいて区域および小区域のパーセンタイルを生成し得る。履歴データを使用する他の時間範囲も可能である。履歴データへの依拠は、例えば、「有効な」配達期間を含む任意の所望の特徴によるフィルタまたは入力された検索用語によってフィルタリングされ得る。「有効な」配達期間は、すべての配達期間が同じ日に同じ小区域において同じ配送作業員によって完了されることを必要とし得る。いくつかの態様では、「有効な」配達期間は、その期間が１５分間以上であることを必要とし得る。他の態様では、「有効な」配達期間は、任意の連続した配達間の時間的ギャップが３０分未満であることも必要とし得る。「有効な」期間の他の基準も企図され、フィルタリングに使用され得る。予想配送効率ジェネレータ４０６は、「有効な」配達期間ごとのＡＰＨ値を計算し、「有効な」配達期間ごとのＡＰＨのパーセンタイル値も生成し得る。配送効率を決定するための他のメトリックも企図され、予想配送効率ジェネレータ４０６によって利用され得る。

図５は、クロスタイム（Ｔ）５０１を計算するための開示の実施形態と一致する、クロスタイムジェネレータ４０８によって使用されるデータ構造５００に格納されたクロスタイムデータの表現の概略図である。図５に示されるように、クロスタイムジェネレータ４０８は、「小区域１」５０２および「小区域２」５０４として識別された２つの区域を含む。２つの小区域の各々について、線形スペクトルは、配送作業員によって行われるべきすべてのタスクである、「運転」５０６、「駐車」５０８、「仕分け」５１０、および「配達」５１２の各々に専用の時間部分を含む。これらのクロスタイムは、配送作業員が、例えば、２つの小区域５０２、５０４間の「運転」５０６、「駐車」５０８、「仕分け」５１０、および「配達」５１２の各々を含む、前述のタスクのいずれかを完了するのに要する時間量を決定するために計算され得る。しかしながら、クロスタイムジェネレータ４０８は、必ずしも「運転」５０６だけの時間を計算する必要はなく、「運転」５０６に加えて他の輸送モードの計算を行ってもよい。例えば、クロスタイムジェネレータ４０８は、追加のステップを含むか、または前述のステップのいずれかを除外し得る。クロスタイムジェネレータ４０８は、履歴クロスタイム測定値を生成する履歴クロスタイム生成モジュール４１０およびクロスタイム完了および較正測定値４１２を計算するクロスタイム完了および較正モジュール４１２を実施し得る。図５に示されるように、配送作業員がある区域から次の区域に、またはある小区域から次の小区域に移動するための予想時間とするために、区域間／小区域時間が計算され得る。

図４に戻って、クロスタイムジェネレータ４０８は、最近３ヵ月間の２つの区域または小区域間の時間的ギャップの中央値を使用して区域間／小区域時間をさらに計算し得る。この時間は、１つの注文の配達時間を含んでいてもよく、横断時間だけを含むのではない場合もある。時間的ギャップがないか、またはデータサンプル数が２以下である場合、クロスタイムジェネレータ４０８は、キャンプまたはキャンプゾーン２１５における平均区域間／小区域時間を使用し得る。クロスタイムジェネレータ４０８は、クロスタイム完了および較正も行い得る。一例として、「ｎ」個の区域または小区域がある場合、クロスタイムの総数はｎ^２／２であり得る。通常、配送作業員がすべての可能な交差をカバーする可能性は低いので、履歴クロスタイムはこの値よりもずっと小さくなり得る。図４に示されるように、任意の２つの区域／小区域間の運転時間を決定するためにマップサービスモジュール４３０が使用され得る。運転時間とクロスタイムとの関係を決定するために線形回帰も使用され得るので、マップサービスモジュール４３０から取得された運転時間は、クロスタイムに変換され、クロスタイム行列が完成し得る。本開示によれば、クロスタイム行列がクロスタイムを計算するために使用され得る。

本開示よれば、ルートジェネレータ４１６は、出勤割り振り最適化モジュール４１８、シード分配生成モジュール４２０、再分配最適化モジュール４２２、および訪問順序最適化モジュール４２４を含み得る。図４に示されるように、ルートジェネレータ４１６は、ルート４２８を生成するために、予想配送効率ジェネレータ４０６からのＡＰＨ値、時間（Ｔ）値、パッケージ分配４２６ならびにユーザ構成および優先設定４１４を参照し得る。出勤割り振り最適化モジュール４１８は、パッケージ分配４２６、および配送作業員の経験に関する分類カテゴリ（例えば、「初心者」、「通常」、「シニア」）の下で割り当てられた出勤番号、の各入力に基づいて、各グループに配送作業員の人数を割り振るために使用され得る。これらの分類カテゴリの一部として、配送作業員は、その配送能力および／または配送効率に見合う様々な重みと関連付けられ得る。重みは、配送作業員の配送経験にも関連し得る。例えば、「初心者」の分類は、新しい配送作業員または配送経験がほとんどもしくは全くない配送作業員を指示する。「通常」の分類は、多くはないがある程度の、または有意な配送経験がある配送作業員を指示する。「シニア」の分類は、長年にわたる有意な配送経験がある配送作業員を指示する。他の分類識別も可能であり得る。シード分配生成モジュール４２０は、ユーザによって構成された規則に基づいて余分な区域を削除し、新しい区域を作成し、区域を生成するために使用され得る。これらの規則は、ユーザによって、余分な区域を削除し、新しい区域を作成するように構成され、規則は、インターフェースに入力され、所望の配送作業員（例えば、「ロートップ」、「職人優先」、および「その他の規則」）をさらに指定し得る。「ロートップ」の分類は、大型トラックではなく、屋根が低い車両に配達物を積み込む経験を有する配送作業員を指示する。ロートップトラックを含む屋根が低い車両は、地階への配達を必要とする宛先への配達を行うのに必要とされ得る。シード分配生成モジュール４２０は、区域固有であり得る運用規則を生成してもよく、特定の区域で行われるすべての配達が「ロートップ」または「職人優先」であることを要求し得る。「職人優先」の分類は、あらゆる種類の便利屋または荷積みのスキルを持ち、様々な複雑さを有する様々なタイプのタスクを行うことができる配送作業員を指示する。シード分配生成モジュール４２０は、特定の区域が「職人優先」の配送作業員のみを含むよう要求し得る。「その他の規則」の分類は、目下の特定の配達要件に基づいて指定され得る「その他の規則」を指示する。他の分類識別も可能であり得る。

再分配最適化モジュール４２２は、生成されたシード分配内の区域に基づくものであってもよく、複数の候補区域を作成し得る。再分配最適化モジュール４２２は、すべての配達需要をカバーし、配送コストを最小化するために、すべての候補区域からの区域の最適な組み合わせを決定する０／１プログラミングモデルをさらに実施し得る。訪問順序最適化モジュール４２４は、新しく生成された区域の集合である再分配最適化４２２の出力を利用し得る。生成された各区域内で、訪問順序最適化モジュール４２４は、配送コストを最小化するために最善の配達訪問順序を決定し得る。訪問順序最適化モジュール４２４は、区域および小区域、ならびに特定の区域および小区域への特定の順序での配達を記述するコーディングを提供し得る。文字または数字が、区域または小区域を記述し、配送コストを最小化するための訪問配達順序を提示するためのコードとして使用され得る。出勤割り振り最適化モジュール４１８、シード分配生成モジュール４２０、最適化モジュール４２２、および訪問順序最適化モジュール４２４は、協働して最適なルート４２８を生成し得る。

本開示によれば、再分配最適化モジュール４２２は、作業員を割り振るために以下の式を実施し得る（「整数プログラミングモデル」）。

、式中、以下のとおりである。

以下でこれらの変数の各々について説明する。ｘ_ｉ、ｙ_ｉ、ｚ_ｉは、何人の配送作業員、半日作業員、および歩行作業員が、それぞれ、グループｉに割り当てられ得るかを記述する整数変数を表し得る。整数プログラミングモデルによって使用されるその他のパラメータには、キャンプ全体のドライバ１人あたりの平均パッケージ数／小荷物数（ＰＰＤ）を表す、ａｖｇ、グループｉ内の総パッケージ数、ｐ_ｉ、グループｉ内の重み付き作業員の総数、Ｗ_ｉ、ＰＰＤの所与の限界からの分散ペナルティ、ｄ_ｉ、下限を下回る分散、ｕ_ｉ、上限を超える分散、ｖ_ｉ、配送作業員、半日作業員、および歩行作業員のそれぞれの重み、α、β、およびγ、それぞれ、グループｉに事前に割り当てられている配送作業員、半日作業員、および歩行作業員の人数、ａ_ｉ、ｂ_ｉ、およびｃ_ｉ、下限および上限の比率、λ、δ、それぞれ、割り当てられる必要がある配送作業員、半日作業員、および歩行作業員の総数、ｃ、ｈ、およびｗ、ならびに割り当てから除去することができないルートの本数、ｆ_ｉ、が含まれ得る。Ｇは、利用可能なグループのセットも表し得る。

再分配最適化モジュール４２２の整数プログラミングモデルの目的は、各キャンプの平均ＰＤＤと各グループの平均ＰＰＤとの差を最小化し、所与の閾値からの分散を最小化することである。

再分配最適化モジュール４２２によって使用される整数プログラミングモデルは、追加の制約も含み得る。例えば、出勤割り振り最適化モジュール４２２は、すべての配送作業員の重み付き値を、ｗ_ｉ＝α（α_ｉ＋ｘ_ｉ）＋β（ｂ_ｉ＋ｙ_ｉ）＋γ（ｃ_ｉ＋ｚ_ｉ）として計算し得る。出勤割り振り最適化モジュール４２２は、計算によって、グループレベルの平均ＰＰＤが下限閾値と上限閾値との間、またはその範囲内にあるべきことも検証し得る。

再分配最適化モジュール４２２は、計算によって、各グループに割り当てられた異なる出勤の総数が同じタイプの出勤数と等しいことも検証し得る。出勤割り振り最適化モジュール４２２はまた、各タイプの作業員の妥当な上限を設定して、例えば、計算によって、各グループに割り当てられた配送作業員の総数が配送作業員の人数と等しくなる（Σ_ｉ∈Ｇｘ_ｉ＝ｃ）ようにし、計算によって、各グループに割り当てられた半日作業員の総数が半日作業員の人数と等しくなる（Σ_ｉ∈Ｇｙ_ｊ＝ｈ）ようにし、計算によって、各グループに割り当てられた歩行作業員の総数が歩行作業員の人数と等しくなるようにし得る。

再分配最適化モジュール４２２はまた、計算によって、配送作業員の人数が、除去することができないルートの本数以上である（ｘ_ｉ≧ｆ_ｉ、∀ｉ∈Ｇ）ようにし、計算によって、同じグループに多すぎる半日作業員が割り当てられないようにし（

）、計算によって、各配送作業員が配達に多くても１人の歩行作業員を連れて行く（ｚ_ｉ≦ｘ_ｉ、∀ｉ∈Ｇ）ようにし得る。

本開示によれば、再分配最適化モジュール４２２は、作業員を最適に再分配するために以下の式を実施し得る（「０／１プログラミングモデル」）。

０／１プログラミングモデルは、ここでは、最小化問題として理解され得る。以下で上記の変数の各々について説明する。ｘ_ｉ、ｙ_ｊ、ｚ_ｋ、ｕ_ｌは、ルート選択に関する２値変数を表し得る。例えば、ルートｉが選択される場合、ｘ_ｉの値は１であり、そうでない場合０である。Ｉは、配送作業員ルートとしての通常ルートのセットを表し、Ｊは、歩行作業員ルートとしての歩行作業員同伴ルートのセットを表し、Ｋは、新しいルートとしての新しく作成されたルートのセットを表し、Ｌは、半日ルートのセットを表し得る。Ｓは、サブルートのセットを表し得る。ｃ、ｗ、ｎ、およびｈは、それぞれ、配送作業員、歩行作業員、新しいルート、および半日作業員の数を表し得る。最後に、α_ｉｓ、α_ｊｓ、α_ｋｓ、およびα_ｌｓは、インジケータ変数を記述し、サブルートｓが、ルートｉ、ｊ、ｋ、ｌのうちの１つにある場合には、対応するインジケータ値は１である（そうでない場合には０である）。

再分配最適化モジュール４２２における０／１プログラミングモデルの１つの目的は、評価メトリックの無効化のペナルティを最小化することである。再分配最適化モジュール４２２は、正規化されたＰＰＤからの逸脱のペナルティ、複数親ルートのペナルティ、異なる親ルートからのサブルート間の横断時間のペナルティ、交換ルートのペナルティ、および移動難易度のペナルティのうちの１つまたは複数に基づいて、ルートごとのペナルティコストを計算し得る。

再分配最適化モジュール４２２は、様々な制約を課し得る。例えば、再分配最適化モジュール４２２は、生成されたルートの本数が同じタイプでの出勤数と等しいと計算することによるものを含む、「カウント制約」を課してもよい。例えば、再分配最適化モジュール４２２は、計算によって、配送ルートの本数が配送作業員の人数と等しくなる（Σ_ｉ∈Ｉｘ_ｉ＝ｃ）ようにしてもよく、計算によって、歩行作業員ルートの本数が歩行作業員の人数と等しくなる（Σ_ｊ∈Ｊｙ_ｊ＝ｗ）ようにしてもよく、計算によって、新しいルートの本数が必要な新しく作成されたルートの本数と等しくなる（Σ_ｋ∈Ｋｚ_ｋ＝ｎ）ようにしてもよく、計算によって、半日ルートの本数が半日作業員または初心者の人数と等しくなる（Σ_ｌ∈Ｌｕ_ｌ＝ｈ）ようにしてもよい。

第２に、再分配最適化モジュール４２２は、計算によって、各サブルートがただ一度だけカバーされるようにするために、例えば、「カバー制約」を課してもよい（Σ_ｉ∈Ｉα_ｉｓｘ_ｉ＋Σ_ｊ∈Ｊα_ｊｓｙ_ｊ＋Σ_ｋ∈Ｋα_ｋｓｚ_ｋ＋Σ_ｌ∈Ｌα_ｌｓｕ_ｌ＝１，∀ｓ∈Ｓ）。

いくつかの実施形態では、ＳＡＴシステム１０１は、サブルートを組み合わせて、配送作業員（すなわち、配送作業員２２４Ａおよび配送作業員２２４Ｂ）に割り当てられるべき配達のためのルートを作成し得る。各ルートは、１営業日に配達すべきベースラインパッケージ数または配達すべきベースライン宛先数を有し得る。例えば、ＳＡＴシステム１０１は、所与のルートに、１営業日に配達すべき１５０個のベースラインパッケージ数または配達すべき１２０件のベースライン宛先数を割り当て得る。

各ルートにおいて、ＳＡＴシステム１０１は、（１）各サブルート内の宛先の密度、（２）各サブルート内の宛先の数量、（３）あるサブルートから別のサブルートまでの移動時間、または（４）ルートの難易度評価を含む、そのルートのベースライン数を計算するための複数のデータ要因を決定し得る。計算されたルートの難易度、サブルート内の宛先の密度、およびあるサブルートから別のサブルートまでの移動時間に応じて、ＳＡＴシステム１０１は、その特定の日に、および／またはその特定のルート上で配達できる妥当なパッケージ数および／または配達できる妥当な宛先数（ベースライン数）を計算し得る。いくつかの実施形態では、ベースライン数が、配送作業員ごと、ルートごとに生成される（すなわち、各配送作業員の実績のある、または期待されるパフォーマンスを考慮する）。

一実施形態では、特定のエリアで配達するための１０，０００個のパッケージがあり、５０人の配送作業員がいる。１０，０００個のパッケージを５０人の配送作業員で単に割る代わりに、ＳＡＴシステム１０１は、上記の複数のデータ要因、すなわち、ルートの難易度、宛先の密度、および各サブルート内の宛先の数量に基づいて、パッケージを割り当て、サブルートの組み合わせを作成するように構成される。

いくつかの実施形態では、配達履歴データ４０４が、特定のルートのベースライン数を決定するために使用され得る。例えば、ＳＡＴシステム１０１は、平日の朝または夕方、週末の朝または夕方、祝日、混合気象条件、交通量の多さなどを含む様々な条件での特定のサブルートについての１時間あたりに平均して配達された宛先数の履歴データを利用し得る。一例では、１００個のベースラインパッケージ数または１００件のベースライン宛先数を配達する時間数が、交通量の多いまたは夕方の時間帯には、交通量の少ないまたは朝の時間帯よりも多くなり得る。

ベースライン数を計算するとき、ＳＡＴシステム１０１は、配達履歴データ４０４を使用して、例えば、７０日間の履歴データを分析し、１時間あたり平均宛先数を決定し得る。１時間あたりの平均宛先数は、より長期間にわたって取られてもよく、かなり正確である。この計算がかなり正確なのは、平均を取る際に使用される日数が多いほど、１時間あたりの平均宛先数がより正確になるからである。

ベースライン数をより正確にするために、ＳＡＴシステム１０１は、各配送作業員にルートを自動的に割り当て、（配送作業員タイプ、すなわち、通常、初心者などに応じて）同じタイプの履歴ＡＰＨ値を使用し得る。例えば、サブルートＡが主に新しい配送作業員によって、時々別の配送作業員によって配達された場合、ＳＡＴシステム１０１は、新しい配送作業員以外の配送作業員によって行われた以前の配達試行から得られた履歴ＡＰＨ値を使用し得る。

いくつかの実施形態では、履歴ＡＰＨ計算は、配送作業員のタイプを区別しない。配送作業員のタイプには、通常（１００％の容量で配送する）、初心者（複合就業週数に応じて、３０％、５０％、６５％の仕事量で配送する）、シニア（インセンティブの資格を得るために自発的により多くの仕事量の契約をする配送作業員）、軽（７５％の仕事量でより低い月給で配送する新しい配送作業員）が含まれ得る。この場合、サブルートのセットが経験の浅い初心者の配送作業員に日常的に割り当てられている場合、それらのサブルートの７０日間平均ＡＰＨは、１００％の仕事量で働く通常タイプの配送作業員に割り当てられた場合の平均ＡＰＨ（仮定として１９ＡＰＨ）よりも低くなり得る（例えば、１４ＡＰＨ）。

いくつかの実施形態では、サブルート内の宛先の密度が高い場合、そのルートのベースライン数はより高くなり得る。例えば、宛先が互いに近いほど、次の宛先に到達するのがより容易になり得る。いくつかの実施形態では、サブルート内の宛先またはパッケージの数量が大きい場合、そのルートのベースライン数はより低くなり得る。いくつかの実施形態では、あるサブルートから別のサブルートまでの移動時間が長い場合、そのルートのベースライン数はより低くなり得る。いくつかの実施形態では、ルートの難易度評価が高い場合、そのルートのベースライン数はより低くなり得る。宛先の密度は、いくつかの実施形態では、１時間あたりの宛先数（ＡＰＨ）に基づいて測定され得る。例えば、過去７０日間分のＡＰＨが、サブルートごとに、平均的な配送作業員がそのサブルートで配達すると予想され得る宛先数を評価するために使用され得る。その範囲は、例えば、１４から３０ＡＰＨ以内であり得る。

例えば、配達するのが非常に難しいサブルートに多くの数量がある場合、計算されるベースライン数は、数量が少なく、ルートがさほど難しくない別のルートよりも低くなるはずである。ルートの難易度が高い例が、配送速度が遅い場合、例えば、交通量が多い、速度制限が低い、道路が配送トラックには狭すぎる、または専用の駐車スペース、高速エレベータ、もしくは住宅ごとのラベルがない（よって、配送作業員がパッケージを配達すべき場所を決定するのにより多くの時間を要する）集合住宅の場合であり得る。低いルートの難易度評価に寄与し得る要因には、例えば、交通量が少ない、速度制限が高い、道路が配送トラックに十分な幅である、または専用の駐車スペース、高速エレベータ、もしくは住宅ごとのラベルがある（よって、配送作業員がパッケージを配達すべき場所を決定する時間が短くてすむ）集合住宅の場合が含まれる。いくつかの実施形態では、ＡＰＨは、密度と難易度評価の両方に関連する。

ベースライン数を上回って配達されたパッケージごとまたは配達された宛先ごとに、配送作業員は、インセンティブ、すなわち、追加の補償を受ける資格があり得る。一実施形態では、ＳＡＴシステム１０１は、特定のルート上の配送作業員に、配達すべき１５０個のベースラインパッケージ数を割り当て得る。そのような実施形態では、１５０個のパッケージが配達された後、配送作業員は、配達されたパッケージごとに追加の支払いで補償され得る。配送作業員は、例えば、１５０個のパッケージ（配達すべきベースラインパッケージ数）を超えて配達される追加のパッケージごとに５米ドルを受け取る資格があり得る。別の実施形態では、ＳＡＴシステム１０１は、特定のルート上の配送作業員に、配達すべき１２０件のベースライン宛先数を割り当て得る。そのような実施形態では、１２０件の宛先が配達された後、配送作業員は、配達された宛先ごとに追加の支払いで補償され得る。配送作業員は、例えば、１２０件の宛先（配達すべきベースライン宛先数）を超えて配達される追加の宛先ごとに５米ドルを受け取る資格があり得る。

別の実施形態では、ベースラインは、配達されたパッケージ数または配達された宛先数ではなく、労働時間数であり得る。例えば、配送作業員は、配達のためのベースライン時間数として６時間を有し得る。そのような実施形態では、６時間が経過した後、配送作業員は、配達されたパッケージごとまたは配達された宛先ごとに追加の支払いで補償され得る。一例では、配送作業員は、配達のためのベースライン時間数を超えて配達される宛先ごとまたは配達されるパッケージごとに５米ドルを受け取る資格があり得る。

いくつかの実施形態では、ＳＡＴシステム１０１は、（例えば、ルートジェネレータ４１６に関して上述したように）アルゴリズムを実行して、配送作業員を配送のために送り出す３０分前に各ルート割り当ておよびルートのベースラインを決定し得る。いくつかの実施形態では、アルゴリズムは、ＳＡＴシステム１０１が配送作業員に提供する割り当ての出力を提供する。配送作業員がルートの変更を要求する場合、ＳＡＴシステム１０１は、アルゴリズムを再実行し、配送作業員がその特定のルートを回避するために割り当ての異なる出力を作成し得る。

さらに、配送作業員の対応可能性に基づいて、または配送作業員のルート上のパッケージ数または宛先数が多すぎる場合、例えば、キャンプゾーン２１５のリーダはＳＡＴシステム１０１に入力を提供して、ある配送作業員をあるルートから別のルートに変更し、ベースラインに変更を加え、ルートごとに割り振られ得る実際の停止箇所を変更し、サブルートをあるルートから別のルートに変更し、またはサブルートを移動してそのサブルートを別のルートに配置し得る。したがって、アルゴリズムが割り当て出力を提供する間に、ＳＡＴシステム１０１はその割り当てを再構成し得る。いくつかの実施形態では、アルゴリズムが実行され、ルートごとのベースラインを割り振るたびに、ベースラインはデータベース上に保存される。

図６は、開示の実施形態と一致する、キャンプゾーン２１５のリーダが使用するためのグラフィカルユーザインターフェース（ＧＵＩ）６００のシステム視覚表現の概略図である。キャンプゾーン２１５のリーダは、特定の日の配送に対応可能な作業員の人数およびタイプに関する情報を入力し得る。各作業員は、通常の配送作業員、半日作業員、歩行作業員、初心者またはシニアの配送作業員として分類され得る。これらの職名は各々、異なる配送経験またはスキルのレベルに相関され得る。「初心者」の分類は、新しい配送作業員または配送経験がほとんどまたは全くない配送作業員を指示する。「半日」の分類は、「フレックス作業員」であり、半日だけ働ける配送作業員を指示する。「フレックス作業員」は、スケジュールに柔軟性があり、終日と半日の両方働くことができる作業員である。「フレックス作業員」は、一日の様々な時間に働くか、毎日異なる時間働くか、または任意の他のタイプの柔軟なスケジュールで働く作業員を指し得る。通常、「半日」作業員は、完全な配送ルートではなくサブルートで操業するが、「半日」作業員には両方のルートタイプが企図されている。「歩行作業員」は、長距離を歩いてパッケージを手渡しできる配送作業員の分類を指示する。「歩行作業員」の分類の配送作業員は、トラックを使用してパッケージを配送し、トラックドライバと共にトラックを離れてパッケージを降ろし、配達し得る。「シニア」の分類は、長年にわたる有意な配送経験がある配送作業員を指示する。他の分類識別も可能であり得る。各タイプの作業員には、その分類と関連付けられた効率に基づいて異なる重み付けがされ得る。図６に示されるように、ＧＵＩ６００の例示的なシステム視覚表現は、その日の配送に対応可能な作業員を確認するために作業員の人数およびタイプを入力するためのツールバーを含む。

図６に示されるように、返されたツールバー検索結果は、対応可能な配送作業員として、「ジョン・スミス」６０２、「ティム・トンプソン」６０４、「リチャード・ジョンソン」６０６、および「ジェイコブ・ケリー」６０７を含み得る。「ジョン・スミス」は「フレックス作業員」６０８として分類されており、「ティム・トンプソン」は「半日」作業員６１０として分類されており、「リチャード・ジョンソン」は「歩行作業員」６１２として分類されており、「ジェイコブ・ケリー」は、「終日」作業員６１３として分類されている。対応可能な配達区域、ルート、およびサブルートへの近接性を指示するために、各配送作業員に隣接して住所も記載されている。一例として、「ジョン・スミス」は、「ソウル特別市中区明洞３１−３４、３０５ビル、アパート１０５」に位置している。図６に示されるように、「ジョン・スミス」６０２は「ルート配送」６１４に割り当てられており、「ティム・トンプソン」６０４は「サブルート配送」６１６に割り当てられている。上記のように、「半日」作業員は（完全なルートではなく）１本または複数のサブルートに沿ってパッケージを配達し得るが、「半日」作業員には両方のルートタイプが企図されている。したがって、図６に示されるように、「ジョン・スミス」６０２は完全な「ルート配送」６１４を行うが、「ティム・トンプソン６０４」は柔軟な「サブルート配送」６１６を行い、これは「ジョン・スミス」６０２が割り当てられているルートの一部を含む場合も含まない場合もある。さらに、図６に示されるように、「ジェイコブ・ケリー６０７」はボリューム要求６２０を提供し、ＳＡＴシステム１０１は、そのボリューム要求に応答してジェイコブ・ケリーに配達のための追加のパッケージまたは宛先を割り当てた。したがって、「ジェイコブ・ケリー６０７」は、ジェイコブ・ケリーのベースライン数を超える配達されたパッケージごとまたは配達された宛先ごとに追加の補償を受け取ることになる。

さらに、図６に示されるように、キャンプゾーン２１５のリーダが、各配送作業員と関連付けられた分類、スケジュール、重み、効率、およびその他の特徴を閲覧できるようにする他のグラフィカルインターフェースコンポーネントが含まれている。例えば、ステータスバー６２０は、「人数／タイプ／作業員」、「進行中」、「完了」、「未完了」、「受領拒否」、および「分類」についての状況を含んでいてもよく、これらは各々異なる情報を提供する。

「人数／タイプ／作業員」は、配送作業員の人数およびタイプの状況または記述を指示し得る。「進行中」は、現在行われている配達の数を指示し得る。「完了」は、完了した注文の数を指示し得る。「未完了」は、未完了の配達の数を指示し得る。「受領拒否」は、注文の受領を拒否した受取人の人数を指示し得る。「分類」６２８は、利用可能な、現在リアルタイムの配達に用いられている分類の総数（例えば、フルタイム作業員の人数対フレックス作業員の人数）を指示し得る。配送作業員の割り当ておよび事前割り当てを可能にする他のＧＵＩ６００のグラフィカルコンポーネントも企図されている。

加えて、配送作業員は、図２のモバイルデバイス１０７Ａ上で動作しているモバイルアプリケーションを使用して、例えば、毎就業日の仕事のチェックインおよびチェックアウトを行うと共に、ボリューム要求およびインセンティブプログラムの契約も行い得る。

いくつかの実施形態では、作業員の効率特性は、計算されたベースライン数からの仕事量増加のパーセントに対応し得る。例えば、ＳＡＴシステム１０１は現在、インセンティブプログラムへの参加を自発的に申し込んだ配送作業員にシニア配送作業員とラベル付けしている。ＳＡＴシステム１０１は、シニアＡ、シニアＢ、シニアＣ、シニアＤを含む４タイプの配送作業員を有し得る。「Ａ」は最高の比率を有し、平均して、シニア「Ａ」は、ベースラインより２０％多い仕事量を割り当てられ得る。シニア「Ｂ」は、ベースラインより１５％多い仕事量を割り当てられ、シニア「Ｃ」は、ベースラインより１０％多い仕事量を割り当てられ、シニア「Ｄ」は、ベースラインより５％多い仕事量を割り当てられ得る。

いくつかの実施形態では、ＳＡＴシステム１０１は、配送作業員を、追加のパッケージを配達するか、または追加の宛先に配達する（すなわち、別の配送作業員を支援する）よう自動的に割り当て、それによって、配送作業員をインセンティブプログラムに自動的に割り当て得る。例えば、ＳＡＴシステム１０１がサブルートの組み合わせに基づいてルートを配置する場合、ＳＡＴシステム１０１は、効率上の理由でサブルートをより小さい構成要素に分割しない場合がある。さらに、サブルートの分割は過剰な計算を必要とすることになる。よって、サブルートＡまたはＢにその日の特定の数量がある場合、ＳＡＴシステム１０１はそれらを分割しない場合がある。たとえベースラインが１３０であっても、サブルートの組み合わせには追加の停止箇所がある。ＳＡＴシステム１０１はサブルートを分割しない場合があるので、ＳＡＴシステム１０１は代わりに、別の配送作業員に余分な宛先を割り当て得る。

別の実施形態では、新しい配送作業員またはそのルートであまり経験のない配送作業員がおり、その配送作業員がそのルートのベースラインを満たすことができず、ＳＡＴシステム１０１は、支援のために別の配送作業員に追加のパッケージまたは宛先を割り当て得る。そのような実施形態では、追加のパッケージまたは宛先を割り当てられた配送作業員は、ベースラインを超える配達されたパッケージごとまたは配達された宛先ごとに追加の支払いで補償され得る。

さらに、そのような実施形態では、ＳＡＴシステム１０１が配達を別の配送作業員に振り替えるときに、キャンプゾーン２１５のリーダによって使用されるグラフィカルユーザインターフェース（ＧＵＩ）６００はその変更を反映し得る。例えば、配送作業員Ａが自分のベースラインを満たすことができない場合、システムはパッケージＸの配達を配送作業員Ｂに振り替え得る。ＳＡＴシステム１０１は、グラフィカルユーザインターフェース（ＧＵＩ）６００上にパッケージＸの配達を配送作業員Ａにより「進行中」と記載しなくなり、グラフィカルユーザインターフェース（ＧＵＩ）６００上にパッケージＸの配達を配送作業員Ｂにより「進行中」として更新し得る。事実上、配送作業員Ｂは、それらのパッケージが配送作業員Ｂのベースラインを上回った場合には、パッケージの配達について追加の補償を受け取り得る。より具体的には、その日の配送の後、ＳＡＴシステム１０１は、実際に配達された宛先数を配送作業員Ｂのベースラインと比較し得る。ベースラインを超えて配達された宛先（またはパッケージ）ごとに、配送作業員Ｂは宛先ごとのインセンティブを支払われ得る。

図７は、開示の実施形態と一致する、モバイルデバイス上のグラフィカルユーザインターフェース（ＧＵＩ）の視覚表現の概略図である。図７に示されるように、モバイルデバイスインターフェース７００は、インターフェース６００と同様であるが、配送作業員に表示するように構成されたインターフェースを提供し得る。モバイルデバイスインターフェース７００は、配送作業員により閲覧可能であり得る。例えば、図７に示されるように、モバイルデバイスインターフェース７００は、「ジョン・スミス」という名前の作業員に割り当てられたインターフェースを含む。インターフェース７００は、ジョン・スミスの「フレックス作業員６０８」としての分類を含み、配達日７０２「２０１９ ０３ ０７」（すなわち、２０１９年３月７日）、配達開始点または宛先住所７０４「ソウル特別市江南区三星１洞テヘラン路４４７」を指示し、配送作業員の効率または重み評価７０６を含み、配送作業員を案内するための道路、レストラン、およびランドマークを含む配達先付近の地図７０８をさらに含む。配送作業員の配達を支援するために、図示されていない他のグラフィカルコンポーネントも企図され、モバイルデバイスインターフェース７００に含まれ得る。

上記のように、いくつかの実施形態では、ＳＡＴシステム１０１は、配送作業員を、追加のパッケージを配達するか、または追加の宛先に配達する（すなわち、別の配送作業員を支援する）よう自動的に割り当て、それによって、配送作業員をインセンティブプログラムに自動的に割り当て得る。そのような実施形態では、ＳＡＴシステム１０１が配達を別の配送作業員に振り替えると、振替元の配送作業員によって操作されるモバイルデバイスインターフェース７００および振替先の配送作業員によって操作されるユーザインターフェースモバイルデバイスインターフェース７００がその変更を反映し得る。例えば、配送作業員Ａが自分のベースラインを満たすことができない場合、システムはパッケージＸの配達を配送作業員Ｂに振り替え得る。配送作業員Ａのモバイルデバイスインターフェース７００はパッケージＸを記載しなくなり、配送作業員Ｂのモバイルデバイスインターフェース７００は配達のためのパッケージＸを記載することになる。

図８は、開示の実施形態と一致する、配送作業員を割り当て、配送ルートを管理するための例示的なプロセスを示す流れ図である。例示的な方法８００は、本明細書では一連のステップとして説明されているが、ステップの順序は他の実施態様では異なり得ることを理解されたい。特に、ステップは、任意の順序で、または並行して行われ得る。

ステップ８０２で、予想配送効率ジェネレータ４０６がデータベース４０１から地理データ４０２および履歴データ４０４を取得し得る。地理データ４０２および履歴データ４０４は、複数の配送ルートおよび複数の配送サブルートを各々含み得る。予想配送効率ジェネレータ４０６は、複数の事前に定義された区域および複数の小区域と関連付けられた地理データ４０２を受け取り得る。地理データ４０２は、地形データ、業務データ、住宅データ、駐車データ、または建物データのうちの少なくとも１つを含み得る。サブルートまたは小区域データは、ルートまたは区域データの一部として存在し得る。履歴データ４０４は、配達場所、配達時間、配送ドライバ、および／または配達パッケージのうちの１つまたは複数を含む、過去の配達に関するデータ得る。

ステップ８０４で、予想配送効率ジェネレータ４０６が、取得された地理データ４０２および履歴データ４０４に基づいて、予想配送効率（ＡＰＨ値）を計算し得る。予想配送効率ジェネレータ４０６は、その計算を、取得された配送ルートおよび配送サブルートに割り振られたパッケージ数にも基づいて行い得る。予想配送効率ジェネレータ４０６は、１時間あたりに作業員によって訪問された宛先のパーセンタイル（ＡＰＨ）によって測定される、予想配送効率を決定し得る。予想配送効率ジェネレータ４０６は、履歴データ４０４に基づいて、選択された個々の事前に定義された区域および小区域のＡＰＨをさらに計算し得る。いくつかの実施形態では、クロスタイムジェネレータ４０８が、履歴データ４０４に基づいて各区域および小区域におけるＡＰＨのパーセンタイル値を計算し得る。いくつかの実施形態では、特定のパーセンタイルが、予想配送効率として決定され得る（例えば、第６０パーセンタイル）。他の態様では、予想配送効率は、配達のための時間および配送作業員のスキルまたは経験を考慮に入れ得る。

ステップ８０６で、クロスタイムジェネレータ４０８が、履歴クロスタイム生成モジュール４１０を実施して、時間的ギャップの中央値または平均時間決定するに基づく区域間時間５０１および小区域５０２、５０４時間を含む、作業員が（図５に示されるように）第１の区域５０２と第２の区域５０４との間を移動するための予想時間を計算し得る。履歴クロスタイム生成モジュール４１０は、最近３ヵ月の期間内の２つの区域または小区域間の時間的ギャップの中央値を使用し得る。この期間は、横断時間だけでなく注文の配達時間も含み得る。時間的ギャップの中央値が存在しないか、またはデータサンプルの数が２以下である場合、履歴クロスタイム生成モジュール４１０は、キャンプゾーン２１５内の平均区域間／小区域時間を実施し得る。

ステップ８０８で、クロスタイムジェネレータ４０８のクロスタイム完了および較正モジュール４１２が、「運転時間」５０６、「駐車時間５０８」、「仕分け時間」５１０、および「配達時間」５１２を決定し得る。クロスタイム完了および較正モジュール４１２は、マップサービスモジュール４３０と通信して、任意の２つの区域または小区域間の「運転時間」５０６を取得し得る。次いでクロスタイム完了および較正モジュール４１２が、線形回帰を行って、「運転時間」とクロスタイム５０１との間の数学的関係を取得し得る。クロスタイム完了および較正モジュール４１２は、取得された数学的関係およびマップサービスモジュール４３０から取得された運転時間を利用してクロスタイム５０１を決定し、時間値のクロスタイム５０１行列を作成し得る。クロスタイム完了および較正モジュール４１２は、作成された時間値の行列をさらに利用して、新しく計算されたクロスタイム５０１を確定、完了、および較正し得る。

ステップ８１０で、ルートジェネレータ４１６が、グループに配送作業員の人数を割り振り得る。ルートジェネレータ４１６は、デバイス１１９Ａ〜１１９Ｃから、ユーザ構成および優先設定４１４入力、ならびに配達に対応可能な作業員の人数およびタイプを受け取り、タイプは、作業員と関連付けられた分類特性および効率特性を含む。ユーザ入力は、ＧＵＩにおける情報の手入力を含み得る。各作業員は、ユーザ構成および優先設定４１４基づいてによって、「半日」、「歩行作業員」、「初心者」、または「シニア配送作業員」のうちの１つに分類され得る。各タイプの配送作業員には、その分類と関連付けられた効率に基づいて異なる重み付けがされ得る。ルートジェネレータ４１６は、作業員を、分類特性に従って複数のカテゴリ（またはグループ）のうちの少なくとも１つに分類し（または割り振り）、分類特性に基づいて、効率特性に従って配送作業員に重み付けし得る。重みは、個々のユーザが期間中に取得できるパッケージの数を決定するために使用され得る。例えば、半日配送作業員は、通常の配送作業員（１００％）と同数の半分のパッケージ（すなわち、５０％）を配達および輸送してもよく、シニア配送作業員は、通常の配送作業員と比較して１２０％のパッケージを取得し得る。重みは、作業員ごとの予想される配達パッケージ数に基づくものであり得る。他の重みも企図され、分類特性は、経験または効率の少なくとも１つを含み得る。

ルートジェネレータ４１６の出勤割り振り最適化モジュール４１８は、受け取られたユーザ入力に加えて計算されたパッケージ数に基づいて、グループに配送作業員の人数を割り振り得る。出勤割り振り最適化モジュール４１８は、配送作業員を、異なる配送ルートおよび異なる配送サブルートに対応する複数のグループにさらに割り当て得る。これは、パッケージ分配および出勤値を含むユーザ入力に基づいてグループに作業員の人数を割り振ることを含み得る。一例として、５０人の配送作業員および４つのグループがある場合、出勤割り振り最適化モジュール４１８は、「グループ１」は１０人の配送作業員を含むと判断し、出勤割り振り最適化モジュール４１８は、１０人の配送作業員のための１０本の配送ルートを生成することになる。続いて、配送１０ルートが生成された後、キャンプリーダが、どの作業員がどのグループおよびルートに割り振られるかを決定し得る。例えば、キャンプリーダは、「ボブ」は「グループ１」で「ルート１」を占有し、「スティーブ」は「グループ１」で「ルート２」を占有すると決定し、この割り当てを、ユーザインターフェース（図６）でのユーザ入力に基づいて行い得る。他の数の配送作業員およびグループも企図され得る。本開示によれば、出勤割り振り最適化モジュール４１８は、特定のグループに事前に割り当てられた配送作業員への利用可能なパッケージおよびサブルートの割り当ても行い得る。この割り当てにより、配送トラックで製品を仕分けするタスクがドライバからキャンプゾーン２１５のヘルパーに振り替えられ、よって動的配送プロセスの効率が向上し得る。

出勤割り振り最適化モジュール４１８は、割り当てに基づいて、割り当てられた作業員を配送ルートおよび配送サブルートに対して比較し得る。出勤割り振り最適化モジュール４１８は、１本のルートおよびサブルートあたりのパッケージ数も決定し得る。出勤割り振り最適化モジュール４１８は、作業員を異なるグループに割り当る、出勤割り当てを行い、作業員配達あたりのパッケージ数の平均値に基づいてグループの平均偏差値を計算し得る。この計算は、キャンプの平均ｐｐｄからのグループのドライバ１人あたりの平均パッケージ数（ｐｐｄ）の平均偏差を最小化するように行われ得る。上記のように、出勤割り振り最適化モジュール４１８は、１グループあたりの配送作業員の人数を決定し、出勤割り振り最適化モジュール４１８は、個々のグループに割り振られた配送作業員の人数に対応するルートの本数を生成し得る。続いて、配送ルートが生成された後、キャンプリーダは、どの作業員がどのグループおよびルートに割り振られるかを決定し得る。他の数の配送作業員およびグループも企図され得る。他の実施形態では、配送作業員は、出勤割り振り最適化モジュール４１８および出勤割り当てに基づいて割り当てられるのではなく、グループに事前に割り当てられ得る。本開示によれば、キャンプリーダは、作業員を事前に割り当てるためにインターフェース（図６）に配送作業員情報を入力し得る。他の出勤割り当ておよび事前割り当ての手配も企図され得る。

ステップ８１２で、ルートジェネレータ４１６のシード分配生成モジュール４２０が、区域を作成し、余分な区域を削除し得る。シード分配生成モジュール４２０は、ユーザによって構成された規則と、配送作業員の分類（例えば、「ロートップ」、「職人優先」、および「その他の規則」）とに基づいて区域を生成し得る。上記のように、「ロートップ」の分類は、大型トラックではなく、屋根が低い車両に配達物を積み込む経験を有する配送作業員を指示し得る。「職人優先」の分類は、あらゆる種類の便利屋または荷積みのスキルを持ち、様々な複雑さを有する様々なタイプのタスクを行うことができる配送作業員を指示し得る。「その他の規則」の分類は、目下の特定の配達要件に基づいて指定され得る「その他の規則」を指示し得る。シード分配生成モジュール４２０は、分類、配送ルートおよび配送サブルートと関連付けられた配達区域および配達小区域を生成し、生成された配達区域と生成された配達小区域とを組み合わせ、生成された配達区域および生成された配達小区域を除去し得る。シード分配生成モジュール４２０はまた、分類、履歴データ、およびマップデータ最適化に基づいて配送ルートおよび配送サブルートを生成し得る。

ステップ８１４で、ルートジェネレータ４１６の再分配最適化モジュール４２２が、シード分配生成モジュール４２０によって生成または削除された区域に基づいて新しい候補区域を作成し得る。再分配最適化モジュール４２２は、候補ルートと関連付けられた新しい候補配達区域および候補配達小区域も作成し得る。再分配最適化モジュール４２２は、作業員の分類ごとの候補ルートを生成することによってルートバランシングも行い得る。再分配最適化モジュール４２２は、シード分配生成モジュール４２０によって生成された配送ルートの量および配送サブルートの量を、割り当てられた作業員の量と一致するようにさらに変更し得る。再分配最適化モジュール４２２は、割り当てられた作業員の量と一致するように配送ルートの量を増減させ、配送サブルートの量を増減させ得る。この変更は、ルートバランシング問題の複雑さを低減させるために行われるヒューリスティックな方法であり得る。例えば、上記のように、割り当てられた配送作業員が割り当てるべきルートと比較され、再分配最適化モジュール４２２は、配送からルートを追加または除去することによってそれら２つを等しくしようと試み得る。

ステップ８１６で、ルートジェネレータ４１６の再分配最適化モジュール４２２が、区域の最適な組み合わせを決定し得る。再分配最適化モジュール４２２は、生成された候補配達区域と生成された候補配達小区域とを組み合わせ、生成された候補区域および生成された候補配達小区域を除去し、配送コストを最小化するように生成された候補配達区域と生成された候補配達小区域との組み合わせを決定し得る。再分配最適化モジュール４２２は、配送コストを最小化するように候補配達区域および候補配達小区域のうちの少なくとも１つを再分配し得る。再分配最適化モジュール４２２は、（図４を参照して説明したように）「０／１プログラミングモデル」を解くことに基づいて区域の最適な組み合わせを決定し得る。他の最適化法も企図および実施され得る。

ステップ８１８で、ルートジェネレータ４１６の訪問順序最適化モジュール４２４が、区域内の最善の訪問順序を決定し得る。訪問順序最適化モジュール４２４は、変更された量および生成された候補ルートに基づいて、選択された配送サブルートを較正し得る。訪問順序最適化モジュール４２４は、配達および作業員割り当てのために配送サブルートのうちの１つまたは複数を自動的に選択し得る。訪問順序最適化モジュール４２４は、特定のサブルートを一緒に保つために、サブルート訪問順序調整を行い得る。サブルートを一緒に保つための他の調整も行われ得る。加えて、訪問順序最適化モジュール４２４は、（図４に示されるように）最適なルート４２８を生成し、区域内の最善の訪問順序を実施するために、訪問順序最適化の後でパッケージ（小荷物）分配４２６に関する入力を受け取り得る。

ステップ８２０で、ルートジェネレータ４１６は、（図１、図４、および図８に示されるように）最適なルート４２８をデバイス１１９Ａ〜１１９Ｃに伝達し得る。最適なルートは、割り当てられた配達パッケージを効率的に配達するよう配送作業員を案内するための最適なルートおよびサブルートを含み得る。

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

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

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

Claims (20)

1. 出勤割り当てのためのコンピュータ実装システムであって、当該システムは、
   命令を格納するメモリと、
   前記命令を実行して、
   データベースから、複数の配送ルートおよび、前記配送ルートの一部である、複数の配送サブルートを取得し、
   前記配送サブルートに割り振られたパッケージ数を計算し、
   第１の入力として、配送に対応可能な作業員の人数およびタイプを受け取り、前記タイプが分類特性または効率特性の少なくとも１つを含み、
   追加の配達を有する複数のサブルートに複数の作業員を割り当て、追加の配達を有するサブルートの前記割り当てが、前記複数の作業員に割り当てられたベースライン数およびルートの難易度に基づくものであり、
   前記分類特性、受け取った第１の入力、および前記ルートの難易度に基づいて、複数の候補ルートを生成し、
   前記変更された配送サブルートのうちの少なくとも１つを、配送作業員と関連付けられた電子デバイスに転送する
   ように構成された少なくとも１つのプロセッサと
   を含む、出勤割り当てのためのコンピュータ実装システム。
2. 第２の入力として、１つまたは複数のボリューム要求を受け取ることをさらに含む、請求項１に記載の出勤割り当てのためのコンピュータ実装システム。
3. 前記第１のユーザ入力が、パッケージ分配および出勤値をさらに含み、前記第２のユーザ入力が、配達のためのより多くのパッケージを要求する前記１つまたは複数のボリューム要求をさらに含む、請求項２に記載の出勤割り当てのためのコンピュータ実装システム。
4. 前記作業員を効率ランキングが割り当てられた複数のグループに割り当てることをさらに含む、請求項１に記載の出勤割り当てのためのコンピュータ実装システム。
5. 前記作業員に割り当てられた前記ベースライン数がルートごとに生成される、請求項１に記載の出勤割り当てのためのコンピュータ実装システム。
6. 追加の配達に追加の支払いを提供することをさらに含む、請求項１に記載の出勤割り当てのためのコンピュータ実装システム。
7. 前記作業員の前記効率特性が、前記ベースライン数からの仕事量増加のパーセントに対応する、請求項１に記載の出勤割り当てのためのコンピュータ実装システム。
8. 追加の配達を有する複数のサブルートに前記複数の作業員を割り当てることが、各サブルートにおける宛先の密度および宛先の数量にさらに基づくものである、請求項１に記載の出勤割り当てのためのコンピュータ実装システム。
9. 前記システムが追加の配達を自動的に割り当てる、請求項１に記載の出勤割り当てのためのコンピュータ実装システム。
10. 前記システムが、過去７０日間の１時間あたりの平均宛先数の履歴データを利用して、ルートの難易度および前記ベースライン数を決定する、請求項１に記載の出勤割り当てのためのコンピュータ実装システム。
11. 出勤割り当てのためのコンピュータ実装方法であって、当該方法は、
    データベースから、複数の配送ルートおよび、前記配送ルートの一部である、複数の配送サブルートを取得することと、
    前記配送サブルートに割り振られたパッケージ数を計算することと、
    第１の入力として、配送に対応可能な作業員の人数およびタイプを受け取ることであって、前記タイプが分類特性または効率特性の少なくとも１つを含む、ことと、
    追加の配達を有する複数のサブルートに複数の作業員を割り当てることであって、追加の配達を有するサブルートの前記割り当てが、前記複数の作業員に割り当てられたベースライン数およびルートの難易度に基づくものである、ことと、
    前記分類特性、受け取った第１の入力、および前記ルートの難易度に基づいて、複数の候補ルートを生成することと、
    前記変更された配送サブルートのうちの少なくとも１つを、配送作業員と関連付けられた電子デバイスに転送することと
    を含む、出勤割り当てのためのコンピュータ実装方法。
12. 第２の入力として、１つまたは複数のボリューム要求を受け取ることをさらに含む、請求項１１に記載の出勤割り当てのためのコンピュータ実装方法。
13. 前記第１のユーザ入力が、パッケージ分配および出勤値をさらに含み、前記第２のユーザ入力が、配達のためのより多くのパッケージを要求する前記１つまたは複数のボリューム要求をさらに含む、請求項１２に記載の出勤割り当てのためのコンピュータ実装方法。
14. 前記作業員を効率ランキングが割り当てられた複数のグループに割り当てることをさらに含む、請求項１１に記載の出勤割り当てのためのコンピュータ実装方法。
15. 前記作業員に割り当てられた前記ベースライン数がルートごとに生成される、請求項１１に記載の出勤割り当てのためのコンピュータ実装方法。
16. 追加の配達に追加の支払いを提供することをさらに含む、請求項１１に記載の出勤割り当てのためのコンピュータ実装方法。
17. 前記作業員の前記効率特性が、前記ベースライン数からの仕事量増加のパーセントに対応する、請求項１１に記載の出勤割り当てのためのコンピュータ実装方法。
18. 追加の配達を有する複数のサブルートに前記複数の作業員を割り当てることが、各サブルートにおける宛先の密度および宛先の数量にさらに基づくものである、請求項１１に記載の出勤割り当てのためのコンピュータ実装方法。
19. 前記方法が、過去７０日間の１時間あたりの平均宛先数の履歴データを利用して、ルートの難易度および前記ベースライン数を決定する、請求項１１に記載の出勤割り当てのためのコンピュータ実装方法。
20. 地理データおよび配達履歴データを含み、前記地理データが事前に定義された区域および小区域に格納される、データベースと、
    ソフトウェアまたはハードウェアで実施された予想配送効率ジェネレータであって、
    複数の前記事前に定義された区域および複数の前記小区域から、地形データ、業務データ、住宅データ、駐車データ、または建物データのうちの少なくとも１つを含む、地理データを受信し、
    前記地理データに基づいて、１時間あたりに前記作業員によって訪問された宛先のパーセンタイル（ＡＰＨ）によって測定される、予期される配送効率を決定し、
    前記配達履歴データに基づいて、選択された個々の事前定義された区域および小区域の前記ＡＰＨを計算する
    ように構成された、予想配送効率ジェネレータと、
    ソフトウェアまたはハードウェアで実施されたクロスタイムジェネレータであって、
    時間的ギャップの中央値または平均時間に基づく区域間時間および小区域時間を含む、前記作業員が第１の区域と第２の区域との間を移動するための予想時間を計算し、
    線形回帰および前記区域間時間に基づいて、前記第１の区域と前記第２の区域との間の運転時間を決定する
    ように構成された、クロスタイムジェネレータと、
    ソフトウェアまたはハードウェアで実施されたルートジェネレータであって、
    ルートの難易度ならびに、パッケージ分配、出勤値、およびボリューム要求を含むユーザ入力に基づいて前記グループに作業員の人数を割り振り、
    前記配送ルートおよび前記配送サブルートと関連付けられた配達区域および配達小区域を生成し、
    前記生成された配達区域と前記生成された配達小区域とを組み合わせて新しい配達区域にし、
    少なくとも１つのサブルートを配送作業員と関連付けられた電子デバイスに転送すること
    ように構成された、ルートジェネレータと
    を含むシステム。
    

Images