JP2013170050A - 配送計画システム - Google Patents

Abstract

【課題】一部の受取人が不在であっても、他の顧客への配達品があり玄関前配達で対応可能となる時間帯が判断し、荷物の持ち帰りを抑えて、配送を効率化する。
【解決手段】過去に配送を行った際の時刻と配達先の在宅／不在を配送実績データベースで管理し、顧客の行動パターンと在宅時間のパターンを現したカテゴリとを比較して、各顧客を複数のカテゴリに分類する。そして注文状況とその顧客の属するカテゴリから、推定在宅時間内での配達時間を計算し配送スケジュールを作成する。また、入り口にロックがかかっているマンション等では、複数顧客のいずれかが在室であれば入り口のロックが解除でき、入出が可能となる顧客を纏めた複数顧客ＤＢを備え、同一の施設に対してまとめ配達を行う。
【選択図】 図１

Description

この発明は、物品の配送システムに関し、配達先の在宅状況を推定し配送計画を立案するシステムに関する。

配送業において、荷物の配達時、受取人が不在だった場合に、荷物の持ち帰りが多いという問題があった。特に、オートロックのマンションの場合には入館もできないため、玄関先においてくることもできない。そのため、不在の場合、不在通知や連絡先を郵便ポストに入れている。

しかし、玄関前に荷物を置くことで配送効率をアップする配送方法では、受取人が不在の場合で、かつ玄関前配達ができない場合、荷物を再配達する必要があった。

そこで、特開２００２−２０５８２２号公報（特許文献１）では、配送受付時に受取人のメールアドレスも入手し、受取人に荷物管理番号をメールすることで、受取人がセンタに問合せて運送状況を把握する発明が開示されている。

特開２００２−２０５８２２号公報

しかし、特許文献１に記載の発明では、受取人がアクションしない限り、荷物の受け取りの可否が不明である。また、配送業者にとっては、配達時間に受け取りが可能であるかどうかが不明であった。

また、マンションの場合、受取人や契約者が複数いて、そのうち誰かが在室であれば、不在の家の玄関先にも荷物を置くことができたが、この複数顧客に対応した在室状況の管理は行っていなかった。

過去に配送を行った際の時刻と配達先の在宅／不在を配送実績ＤＢ（データベース）で管理し、顧客の行動パターンと在宅時間のパターンを現したカテゴリとを比較して、各顧客を複数のカテゴリに分類する。そして注文状況とその顧客の属するカテゴリから、推定在宅時間内での配達時間を計算し配送スケジュールを作成する。

また、入り口にロックがかかっているマンション等では、複数顧客のいずれかが在室であれば入り口のロックが解除でき、入出が可能となる顧客を纏めた複数顧客ＤＢを備え、同一の施設に対してまとめ配達を行う。

本発明により、一部の受取人が不在であっても、他の顧客への配達品があり玄関前配達で対応可能となる時間帯が判断できるため、荷物の持ち帰りを抑えることができ、配送を効率化することができる。

配送システムにおける配送センタの構成図。 顧客カテゴリＤＢの概念図。 配送スケジュールを作成するまでの処理フロー図。

図１に本発明を用いた配送システム全体及び配送センタの構成を示す。
配送センタ１では、注文データを受付け、その配達先住所、配達希望日時などにより配送スケジュールを立案し、配達品と共に配送車両に伝達する。そして配送車両は、受取った配送スケジュールに沿って、配達先の顧客の家屋あるいは複数の顧客がいるマンションを巡回し、配達品を配達して回る。

配送センタ１では、顧客から配送の注文データを受付けると、配送データ処理部２１で、顧客の住所や氏名の情報が登録されている顧客ＤＢ２６から該当する顧客のデータを抽出し、注文データに記録されている配達品名と共に、注文配送ＤＢ２７に格納する。注文配送ＤＢ２７には、一定期間、例えば一晩とか２４時間経過するごとに注文配送ＤＢ２７に貯められているものとする。

次に、配送作業の際、顧客の不在による荷物の再配送といった無駄を省くため、顧客の在宅時間の特徴に注目して顧客をカテゴリ別に分類する。そこでカテゴリ分類処理部２２により、各配達先の過去の配達時の在宅状況を蓄積している配送実績ＤＢ２８から注文データの配達先の在宅／不在時間を抽出してその特徴を算出し、その特徴が、在宅／不在時間の特徴別に作成されたカテゴリのいずれに属しているか分析して、配達先が属するカテゴリを決定し、顧客カテゴリＤＢ２９に格納する。

図２に、顧客カテゴリＤＢの概念を示す。
顧客カテゴリＤＢ２９には、カテゴリＩＤに対して、各パターンに対応したカテゴリ毎の推定在宅時間帯の在宅時間パターンが格納されている。そして、それぞれのカテゴリには、そのカテゴリに属する配達先や宅配システムの顧客ＩＤを紐付けされている。

ここでカテゴリとは、例えば、カテゴリ１．は、昼の買い物で１１〜１２時、夕の買い物で１７〜１８時に外出することが多く、それ以外は在宅している傾向のある昼夕のお買い物時間帯に不在の専業主婦。カテゴリ２．は、幼稚園の送り迎え時間帯に不在で、それ以外は在宅している傾向のある若い主婦。カテゴリ３．は、家事が済み午後からお稽古事に通っている専業主婦。カテゴリ４．は、夜間しか在宅していない独身の独り暮らし。カテゴリ５．は、深夜から早朝しか在宅していない忙しい人。カテゴリ６．は、夜勤で昼間睡眠のため昼間は対応できない人。カテゴリ７．は、昼間のパート、アルバイトの時間に不在の人。カテゴリ８．は、昼間ならマンションの管理人が代理で受取り可能な人、などそれぞれの顧客の典型的な生活習慣によって決められている。

図２の例では、カテゴリ１．には、顧客ＩＤが１１、２５、２８、２９の顧客が属していることになる。また、複数のカテゴリに顧客ＩＤが紐付けられている場合は、それぞれのカテゴリの不在時間帯を組み合わせる。顧客ＩＤ２９の顧客の推定在宅時間帯は、カテゴリ１．および２．に紐付けされているので、昼の買い物で１１〜１２時、夕の買い物で１７〜１８時に外出する傾向に加えて、幼稚園への送りで８〜９時、迎えで１３〜１４時の時間帯に外出しており、それ以外は在宅しているパターンとなる。同様に、顧客ＩＤ２５の顧客の推定在宅時間帯は、カテゴリ１．および３．に紐付けされているので、昼の買い物で１１〜１２時、夕の買い物で１７〜１８時に外出する傾向に加えて、家事が済んだ午後の１４〜１７時の間お稽古事に通っていて外出しており、それ以外は在宅しているパターンとなる。

各顧客に対し、単純に既存のカテゴリＩＤの番号を付与するだけでなく、カテゴリ１．における夕飯のお買い物とカテゴリ７．における昼間のパート、アルバイトの時間帯に不在の主婦の分類を複合して新たなカテゴリを作った上で、カテゴリ番号を付与してもよい。そして、これら定義されたカテゴリのカテゴリＩＤを各々顧客に付与して、顧客カテゴリＤＢ２９に格納しているので、各顧客がどの時間帯に不在／在宅なのか推定できる。顧客カテゴリは定期的に見直し、古い情報を捨て新しい情報を加えることで、より正確かつ直近の状況に沿ったＤＢとすることもできる。

カテゴリ分類処理部２２において顧客に対してカテゴリＩＤを付与する際には、配送実績ＤＢ２８から顧客の在宅／不在時間の履歴を抽出して、カテゴリの推定在宅時間帯の在宅／不在時間帯と一致する頻度を求め、その頻度が所定値以上となったカテゴリにその顧客が属しているものとしてカテゴリＩＤを付与するようにしてもよい。

そして在宅時間推定処理部２３では、配送データ処理部２１から送られ注文配送ＤＢ２７に貯められた１つ以上の注文と、顧客カテゴリＤＢ２９を利用して注文された配達先の顧客について在宅時間を推定する。

また、入り口にロックがかかっているマンション等のように、複数の顧客のいずれかが在室であれば、その人により入り口のロックが解除でき、マンション通路への入出が可能となり、不在な顧客の玄関まで入って玄関前に置いてくるという対応が可能である。そこで在宅または不在を一括して判断することが可能な建物への入り口を共有する顧客を纏めて管理する複数顧客ＤＢ３０を備え、複数顧客まとめ配送処理部２４では、この複数顧客ＤＢ３０のデータを用いて、入り口にロックがかかっているマンション等で複数の配達先がある場合、その配達先の顧客についていずれかの顧客が在宅となる推定在宅時間帯をまとめ、いずれかの顧客が在宅であれば全顧客を在宅とみなす推定在宅時間帯を求める処理を行う。

そして、配送スケジュール決定処理部２５にて、図示されていない地図や渋滞情報を加味して、不在による再配送が発生しないように配達先顧客が在宅していると推定される時間帯に到着すると推測され、最短距離ないしは最短時間となる車両の走行ルート及び各顧客への配達順序、配達時間といった配送スケジュールを算出する。

図３に、注文を受付けてから配送スケジュールを作成するまでの処理フローを示す。
顧客から注文データを受付ける。荷物を配送するためには、配達先の顧客についてその氏名、住所、電話番号が必要となるが、これに加えて、各顧客の在宅時間を推定するため、また同一マンション等については荷物を纏めて配送するために、顧客を特定するための顧客ＩＤが必要となる。そのため、配送データ処理部２１では顧客ＤＢ２６から該当する顧客の顧客ＩＤと氏名、住所、電話番号などの属性を抽出する（３０１）。そして、受付けた注文データと抽出した顧客ＩＤ、およびその顧客の属性を併せて注文配送データを作成し、注文配送ＤＢ２７に格納する（３０２）。その後、一定時間が経過する間注文配送データを貯め（３０３）、例えば毎日日中配送する場合、２４時間が経過して前日１日分など注文配送ＤＢ２７に貯まった注文データを、カテゴリ分類処理部２２に送付する（３０４）。そして、カテゴリ分類処理部２２では、配達先の顧客の在宅時間を推定するため、各配達先が属する顧客カテゴリを、顧客カテゴリＤＢ２９から抽出して、各注文配送データに付与する（３０５）。

この注文配送データを基に、在宅時間推定処理部２３では、それぞれの配達先顧客の在宅／不在時間を推定する（３０６）。続いて、複数顧客まとめ配送処理部２４では、複数顧客ＤＢ３０から該当する顧客ＩＤを抽出して、配達先が同一マンションに該当するような場合などには、まとめ配送可能な注文配送データを一組として合体させ、合体させた配達先の在宅時間を推定する（３０７）。そして配送スケジュール決定処理部２５では、配達先の住所と推定在宅時間と合体結果から、配送ルート及び配達時間を算出して配送スケジュールを作成し（３０８）、その配送スケジュールを、配送車両４あるいはその車両に持込む端末に送付する。配送車両を運転する配達員は、この配送スケジュールに沿って配送することで、配達先の不在による再配送といった無駄をなるべく省くことができる。

図１に示した例のような配達順序の場合、配送車両４が９時に配送センタ１を出発し、配送スケジュールに沿って配達先をまわる。最初の配達先は９時から１０時に在宅と推定されるカテゴリＩＤ１に分類されている顧客ＩＤ１１の顧客である。次に１０時に在宅と推定されるカテゴリＩＤ１に分類されている顧客ＩＤ１５の顧客に廻り、その後、複数の顧客がいるマンションに向う。このマンションに居住する各顧客の顧客ＩＤは１７、２０、２７であり、顧客ＩＤ２０の顧客がカテゴリＩＤ７に分類されていて昼間１０時から２０時まではパートで不在となるが、他の顧客ＩＤ１７、２７の顧客が在宅のため、この３件の顧客はまとめ配送の対象となり、複数顧客まとめ配送処理された在宅時間のうち１１時が配達時間となっている。次に１２時に在宅が推定される顧客ＩＤ２２の顧客へ配送し、最後に顧客ＩＤ１３、１６、２８の顧客がいるマンションに向かう。このマンションでは、顧客ＩＤ１３、１６は配達時間の１２時半から１３時半には不在となることが推定されるが、顧客ＩＤ２８の顧客の在宅が推定されるため、これら３件もまとめ配送の対象となっている。そして全ての配達先を廻った後、配送車両４が配送センタ１に帰着して配送処理が終了となる。

１ 配送センタ
２ 顧客
３ マンション
４ 配送車両
２１ 配送データ処理部
２２ カテゴリ分類処理部
２３ 在宅時間推定処理部
２４ 複数顧客まとめ配送処理部
２５ 配送スケジュール決定処理部
２６ 顧客ＤＢ
２７ 注文配送ＤＢ
２８ 配送実績ＤＢ
２９ 顧客カテゴリＤＢ
３０ 複数顧客ＤＢ

Claims (2)

1. 顧客情報を格納した顧客ＤＢと、
   各顧客への配達実績を格納する配送実績ＤＢと、
   配達の注文を受けた顧客への配達順序を決定するスケジュール処理部と、
   を備えた配送計画システムにおいて、
   前記配送実績ＤＢには、各配達の際に顧客の在宅または不在の状態を記録し、
   前記配送実績ＤＢにおける顧客の在宅または不在の状態の記録から、各顧客を推定在宅時間帯別に定義されたカテゴリに分類するカテゴリ分類処理部と、
   配達先の顧客について前記カテゴリ分類処理部により当該顧客が分類されたカテゴリから当該顧客の在宅時間を推定する在宅時間推定処理部と、
   推定された配達先の顧客の在宅時間に基づき、配送スケジュールを定める配送スケジュール処理部と
   を備えることを特徴とした配送計画システム。
2. 請求項１に記載の配送計画システムにおいて、
   更に、同一の施設に存在する顧客を纏めた複数顧客ＤＢと、
   前記複数顧客ＤＢに記録されている顧客の内、配達先の顧客の何れかが在宅する時間帯を纏める複数顧客まとめ処理部を備え、
   同一施設に存在する複数顧客を纏めて在宅時間を推定し、該推定された在宅時間を用いて前記配送スケジュール処理部により配送スケジュールを定め、複数顧客のいる施設にまとめ配送することを特徴とした配送計画システム。