JP2020129348A - 情報処理装置 - Google Patents

Abstract

【課題】荷主側の情報と、物流業者側の情報とが考慮された、柔軟な納品計画を容易に作成すること。【解決手段】拠点間の商品の運送に関する計画を運送計画として立案する情報処理装置において、受発注情報取得部１０１は、在庫拠点Ｋ１乃至Ｋｎの夫々における、商品の受け入れ及び払い出しに関する情報を、受発注情報として取得する。立案部１０３は、受発注情報を含む情報に基づいて、商品の在庫の滞りを解消させる運送計画を在庫拠点Ｋ１乃至Ｋｎの夫々について立案する。これにより、上記の課題を解決することができる。【選択図】図４

Description

本発明は、情報処理装置に関する。

従来より、物流拠点となる倉庫で保有される在庫を管理する技術は存在する。例えば、特許文献１には、販売店が受注した顧客からの製品の注文に対して在庫製品を引当て、販売店に注文に対する引当結果及び納期を送信する物流管理システムが記載されている。

特開平９−１３６７０４号公報

しかしながら、特許文献１に記載された技術を含め、従来からある物流管理システムでは、商品の運送を行う物流業者側の情報が参照されるが、商品の発注や受け取りを行う荷主（例えば、商品の製造メーカーや販売店舗）側の情報が考慮されていなかった。
その理由の１つとして、運送（例えば、物流業者）側が、荷主側の情報を入手したうえで、当該情報を商品の納品に関する計画（以下、「納品計画」と呼ぶ）に反映させる手法がなかったことが挙げられる。
また、商品を在庫として保有し得る拠点（以下、「在庫拠点」と呼ぶ）が複数存在する場合には、各在庫拠点の在庫を一括で管理することもできなかった。

本発明は、このような状況に鑑みてなされたものであり、荷主側の情報と、物流業者側の情報とが考慮された、柔軟な納品計画を容易に作成することができる手法を提供することを目的とする。

上記目的を達成するため、本発明の一態様である情報処理装置は、
拠点間の商品の運送に関する計画を運送計画として立案する情報処理装置において、
１以上の前記拠点の夫々における、商品の受け入れ及び払い出しに関する情報を、受発注情報として取得する第１取得手段と、
前記受発注情報を含む情報に基づいて、前記商品の在庫の滞りを解消させる前記運送計画を前記拠点毎に立案する立案手段と、
を備える。

また、前記立案手段により立案された前記運送計画を、前記拠点に提示する提示手段をさらに備えることができる。

また、前記受発注情報には、前記１以上の拠点の夫々における前記商品の払い出しの見込みに関する情報が含まれる、とすることができる。

また、前記運送計画の遂行に必要となる情報として、前記商品の運送を行う者が管理し得る運送に関する情報を、運送物流センター情報として取得する第２取得手段をさらに備え、
前記立案手段は、取得された前記運送物流センター情報と、前記受発注情報に基づいて、前記拠点における前記商品の在庫の滞りを解消させる前記運送計画を立案することができる。

また、前記立案手段は、さらに、前記拠点に１回で運送される前記商品の数量を調整して、前記拠点における前記商品の在庫の滞りを解消させる前記運送計画を立案することができる。

本発明によれば、荷主側の情報と、物流業者側の情報とが考慮された、柔軟な納品計画を容易に作成することができる。

本発明の情報処理装置の一実施形態に係るサーバが実行する各種処理により実現できる本サービスの概要を示すイメージ図である。 図１のサーバを含む、情報処理システムの構成を示す図である。 図２のサーバのハードウェア構成を示すブロック図である。 図３のサーバの機能的構成の一例を示す機能ブロック図である。 本サービスにより立案された納品計画の具体例を示す図である。 所定の店舗の日毎の納品数量の予定値（予約数）を修正することで納品計画全体を調整する具体的手法を示す図である。 所定の店舗の日毎の納品数量の予定値（予約数）を修正することで納品計画全体を調整する具体的手法を示す図である。 所定の店舗の日毎の納品数量の予定値（予約数）を新たに追加することで納品計画全体を調整する具体的手法を示す図である。 顧客端末に表示される店舗に関する情報の具体例を示す図である。 顧客端末に表示される予約画面の具体例を示す図である。 本サービスの他の具体例を示す図である。 納品計画が立案される際の根拠となる受発注情報のうち、在庫情報及び見込情報の具体例を示す図である。 納品計画が立案される際の根拠となる運送物流センター情報のうち、車両情報の具体例を示す図である。 図１２及び図１３に示す各種情報に基づきサーバにより立案される納品計画の具体例を示す図である。

以下、本発明の実施形態について図面を用いて説明する。

［サービス内容］
図１は、本発明の情報処理装置の一実施形態に係るサーバ１が実行する各種処理により実現できる本サービスの概要を示すイメージ図である。

図１に示すように、本サービスでは、店舗Ｍが、顧客に販売するために在庫として保有している商品は、在庫拠点としての店舗Ｍが保有する在庫に関する情報（以下、「在庫情報」と呼ぶ）として管理される。
ここで、在庫拠点は、顧客に対し、商品を効率良く配送するために、商品を在庫として保有し得る拠点である。在庫拠点は、顧客に対する効率的な配送を実現すべく、一定範囲の地域内に複数存在する。在庫拠点は、商品を長期的、短期的、又は一次的に在庫として保有し得る空間であればよい。例えば、倉庫Ｗや店舗Ｍ等の建物の内部、貨物運搬車両Ｔ等の車両の荷台等は、いずれも在庫拠点の一例である。
店舗Ｍが在庫として保有する商品が少なくなってくると、店舗Ｍは、荷主Ｓに対して、商品の注文を行う。本サービスでは、店舗Ｍから荷主Ｓに対する注文があると、その内容が「注文情報」として管理される。

店舗Ｍからの注文を受けた荷主Ｓは、その注文の内容に基づいて、ベンダーＶ（例えば、商品を製造する工場）に対して、商品の製造を発注する。本サービスでは、荷主ＳからベンダーＶに対する発注があると、その内容が「発注情報」として管理される。
なお、図１に示す荷主Ｓは、商品を在庫として保有せずに、ベンダーＶから商品を発送する者を想定しているが、荷主Ｓ自身が商品を在庫として保有してもよい。このため、本サービスでは、荷主Ｓも在庫拠点の１つとして取り扱われる。

本サービスでは、商品を製造して店舗Ｍに発送するベンダーＶが、店舗Ｍに発送するために在庫として保有している商品は、在庫拠点としてのベンダーＶが保有する在庫情報として管理される。
荷主Ｓからの発注を受けたベンダーＶは、荷主Ｓからの注文の内容に基づいて、物流業者Ｌに対して、商品の配送を依頼する。本サービスでは、ベンダーＶから物流業者Ｌに対する商品の配送の依頼があると、その依頼の内容が「依頼情報」として管理される。

本サービスでは、ベンダーＶからの依頼を受けて店舗Ｍに商品を配送する物流業者Ｌが業務上保有する各種情報が管理される。具体的には、商品の運送に用いられる貨物運搬車両Ｔに関する情報（以下、「車両情報」と呼ぶ）として、貨物運搬車両Ｔ毎の車両番号、積載量、車格、運転手に関する情報（例えば名前、年齢、労働時間、残業時間等）等が管理される。
ベンダーＶからの依頼を受けた物流業者Ｌは、ベンダーＶからの依頼の内容に基づいて、店舗Ｍに商品を配送する。
ここで、物流業者Ｌは、商品の配送を行うための設備等として、物流センター、倉庫、トラック等を使用する者である。このため、本サービスにおいて、物流業者Ｌが使用する物流センター、倉庫、トラック等は、商品を長期的、短期的、又は一時的に在庫として保有し得る在庫拠点として取り扱われる。
本サービスでは、物流業者Ｌから店舗Ｍに対する配送に関する情報は、「配送情報」として管理される。

また、本サービスでは、物流業者Ｌが管理する設備と人（ドライバー、構内作業者も含む）に関する情報も、「設備・人情報」として管理される。

本サービスでは、上述した在庫情報、注文情報、発注情報、依頼情報、車両情報、配送情報、及び設備・人情報が一括で管理され、これらの情報が考慮された柔軟な納品計画が立案される。
即ち、本サービスによれば、物流業者Ｌが本来的に管理し得る情報（依頼情報、車両情報、配送情報、及び設備・人情報）と、荷主Ｓが本来的に管理し得る情報（在庫情報、注文情報、及び発注情報）とに基づく実効的な納品計画の立案が可能となる。つまり、物流業者側の情報と、荷主側の情報とに基づく実効的な納品計画の立案が可能となる。その結果、無駄のない効率的な運送を実現させることができる。

［システム構成］
次に、本サービスを提供するための各種処理を実行するサーバ１を含む、情報処理システムの構成について説明する。
図２は、本発明の情報処理装置の一実施形態に係るサーバ１を含む、情報処理システムの構成を示す図である。

図２に示す情報処理システムは、サーバ１と、拠点端末２−１乃至２−ｎ（ｎは１以上の整数値）と、顧客端末３−１乃至３−ｍ（ｍは１以上の整数値）が、インターネット等の所定のネットワークＮを介して相互に接続されることで構成される。

本実施形態における拠点端末２−１乃至２−ｎの夫々は、在庫拠点Ｋ１乃至Ｋｎの夫々に設置された情報処理装置であり、パーソナルコンピュータ、スマートフォン、タブレット端末等で構成される。拠点端末２−１乃至２−ｎの夫々は、在庫拠点Ｋ１乃至Ｋｎの夫々の担当者によって操作される。
なお、以下、在庫拠点Ｋ１乃至Ｋｎ、拠点端末２−１乃至２−ｎの夫々を個々に区別する必要がない場合、これらをまとめて、「在庫拠点Ｋ」、「拠点端末２」の夫々と呼ぶ。

拠点端末２には、その在庫拠点Ｋの在庫情報と、商品の払い出しの見込みに関する情報（以下、「見込情報」と呼ぶ）とが記憶されている。また、拠点端末２の中には、さらに、車両情報が記憶されているものもある。
ここで、商品を「受け入れる」とは、商品を運送するために一次的に保管したり、商品を販売するために在庫として保有したりすることをいう。具体的には例えば、ベンダーＶから商品の配送の依頼を受けた物流業者Ｌが、物流センター、倉庫、店舗の順で配送する場合、物流センター、倉庫、及び店舗は、いずれも商品を在庫として「受け入れる」こととなる。
また、商品を「払い出す」とは、在庫として保有する商品を、運送したり販売したりすることで手元から離すことをいう。
また、商品の「払い出しの見込み」とは、在庫拠点Ｋにおいて在庫として既に保有し、又は在庫として保有する予定となっている商品についての、将来における払い出しの見込みのことをいう。

このように、拠点端末２には、その在庫拠点Ｋにおける在庫情報と、見込情報とが記憶されており、さらに車両情報が記憶されているものもある。サーバ１は、複数の拠点端末２に記憶されているこれらの情報を取得して、在庫拠点Ｋ毎の納品計画を立案する。これにより、物流業者側の情報のみならず、荷主側の情報が考慮された実行的な運送を実現させることができる。

本実施形態における顧客端末３−１乃至３−ｍの夫々は、顧客Ｕ１乃至Ｕｍの夫々が操作する情報処理装置であり、パーソナルコンピュータ、スマートフォン、タブレット端末等で構成される。
なお、以下、顧客Ｕ１乃至Ｕｍ、顧客端末３−１乃至３−ｍの夫々を個々に区別する必要がない場合、これらをまとめて、「顧客Ｕ」、「顧客端末３」の夫々と呼ぶ。

［ハードウェア構成］
次に、本サービスを提供するための各種処理を実行するサーバ１のハードウェア構成について説明する。
図３は、図２のサーバ１のハードウェア構成を示すブロック図である。

サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

なお、図示はしないが、拠点端末２も図３に示すハードウェア構成を有している。

出力部１６は各種液晶ディスプレイ等で構成され、各種情報を出力する。
入力部１７は、各種ハードウェア鉛等で構成され、各種情報を入力する。
記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（例えば図２の拠点端末２−１乃至２−ｎ）との間で行う通信を制御する。

ドライブ２０は、必要に応じて設けられる。ドライブ２０には磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア３０が適宜装着される。ドライブ２０によってリムーバブルメディア３０から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。またリムーバブルメディア３０は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。

［機能的構成］
次に、このようなハードウェア構成を持つサーバ１の機能について、図４を参照して説明する。
図４は、図３のサーバ１の機能的構成の一例を示す機能ブロック図である。

図４に示すように、サーバ１のＣＰＵ１１においては、納品計画立案処理が実行される場合には、受発注情報取得部１０１と、運送物流センター情報取得部１０２と、立案部１０３と、提示部１０４とが機能する。
記憶部１８の一領域には、受発注ＤＢ４０１と、運送ＤＢ４０２とが設けられている。

受発注情報取得部１０１は、１以上の拠点の夫々における、商品の受け入れ及び払い出しに関する情報を受発注情報として取得する。
具体的には、受発注情報取得部１０１は、在庫拠点Ｋ１乃至Ｋｎの夫々における商品の受発注情報を取得する。受発注情報には、在庫拠点Ｋ１乃至Ｋｎの夫々における在庫情報及び見込情報も含まれる。
受発注情報取得部１０１により取得された、在庫拠点Ｋ１乃至Ｋｎの夫々における受発注情報は、受発注ＤＢ４０１に記憶されて管理される。
なお、受発注情報取得部１０１が受発注情報を取得する具体的手法は特に限定されない。例えば、拠点端末２に記憶されている情報を取得する手法を用いてもよいし、その他の手法を用いてもよい。

運送物流センター情報取得部１０２は、運送計画の遂行に必要となる情報として、商品の運送を行う者が管理し得る運送に関する情報を、運送物流センター情報として取得する。
具体的には、運送物流センター情報取得部１０２は、後述する立案部１０３により立案される運送計画を遂行する際に必要となる情報として、物流業者Ｌが管理している情報を、運送物流センター情報として取得する。運送物流センター情報には、上述の依頼情報、車両情報、及び配送情報が含まれる。
運送物流センター情報取得部１０２により取得された運送物流センター情報は、運送ＤＢ４０２に記憶されて管理される。
なお、運送物流センター情報取得部１０２が運送物流センター情報を取得する具体的手法は特に限定されない。例えば、物流業者Ｌが操作する拠点端末２に記憶されている車両情報等を運送物流センター情報として取得する手法を用いてもよいし、その他の手法を用いてもよい。

立案部１０３は、受発注情報を含む情報に基づいて、商品の在庫の滞りを解消させる運送計画を拠点毎に立案する。
具体的には、立案部１０３は、受発注情報取得部１０１により取得された受発注情報と、運送物流センター情報取得部１０２により取得された運送物流センター情報とに基づいて、商品の在庫の滞りを解消させる運送計画を、在庫拠点Ｋ１乃至Ｋｎの夫々について立案する。
これにより、物流業者Ｌが本来的に管理し得る物流業者側の情報に加え、店舗Ｍ、荷主Ｓ、及びベンダーＶが本来的に管理し得る荷主側の情報に基づく実効的な納品計画の立案が可能となる。その結果、無駄のない効率的な運送を実現させることができる。

また、立案部１０３は、特定の拠点（例えば、店舗Ｍ１）の費用負担を最小化させた納品計画を立案することができる。
これにより、商品の納入を受ける店舗Ｍ１の財務的な事情が考慮された、実効的な運送計画による運送が実現可能となる。
なお、立案部１０３により立案される納品計画の具体例は、図５以降の図を参照して後述する。

提示部１０４は、立案された運送計画を各拠点に提示する。
具体的には、提示部１０４は、立案部１０３により立案された運送計画を、拠点端末２−１乃至２−ｎの夫々に送信する。これにより、各在庫拠点Ｋにおいて、サーバ１により立案された納品計画を容易に参照することができる。
また、提示部１０４は、立案された運送計画を顧客に提示する。
具体的には、提示部１０４は、立案部１０３により立案された運送計画を、顧客端末３−１乃至３−ｍの夫々に送信する。これにより、顧客Ｕ１乃至Ｕｍの夫々は、サーバ１により立案された納品計画を容易に参照することができる。

受発注ＤＢ４０１には、受発注情報が記憶されている。
運送ＤＢ４０２には、運送物流センター情報が記憶されている。

以上のような機能的構成を有するサーバ１により、上述の各種処理が実行されることで、物流業者側の情報と、荷主側の情報とに基づく実効的な納品計画が立案されるので、無駄のない効率的な運送を実現させることができる。

［具体例］
次に、図５乃至図１４を参照して、本サービスにより立案される納品計画の具体例について説明する。

（具体例１）
図５は、本サービスにより立案された納品計画の具体例を示す図である。

納品計画が立案されると、図５に示すような画面が拠点端末２に表示される。拠点端末２に表示される画面は、表示領域Ｆ１乃至Ｆ４で構成されている。

表示領域Ｆ１には、物流業者Ｌが所定日（例えば１２月１２日）に商品を運送する場合における、貨物運搬車両Ｔの配車のシミュレーション結果が表示される。「セット」とは、商品の梱包単位であり、「１セット」が商品を運送する際の最少単位となる。「タクシー」、「軽自動車」、「２ｔトラック」、「４ｔトラック」、及び「１０ｔトラック」は、いずれも物流業者Ｌにより貨物運搬車両Ｔとして用いられる車両である。
表示領域Ｆ１のゲージＧに示すように、タクシーは、１台で商品を１セットだけ運送することができる。軽自動車は、１台で商品を最大５セット運送することができる。２ｔトラックは、１台で商品を最大１０セット運送することができる。４ｔトラックは、１台で商品を最大２５セット運送することができる。１０ｔトラックは、１台で商品を最大６０セット運送することができる。
図５に示す例では、１２月１２日の運送数量（セット数）の予定値（予約数）が１２セットであることがバーＢで示されている。このため、拠点端末２を操作する者は、４ｔトラック１台を配車する必要があることを一見して把握することができる。

表示領域Ｆ２乃至Ｆ４には、予約調整画面が表示されている。
このうち、表示領域Ｆ２には、日毎の天気予報が示されている。即ち、１２月１２日の天気予報は「曇り」、１２月１３日の天気予報も「曇り」であることがわかる。なお、他の日の天気予報の内容については、図５の表示領域Ｆ２に示すとおりである。
これにより、拠点端末２を操作する者は、日毎の天気予報を一見して把握することができる。

表示領域Ｆ３には、運送数量に関する昨年の実績（過去の実績）が日毎に表示されている。即ち、昨年１２月１２日の実績は「５セット（軽自動車１台で運送）」、昨年１２月１３日の実績は「６セット（２ｔトラック１台で運送）」であることがわかる。また、昨年１２月１５日の過去の実績は「４０セット（１０ｔトラック１台で運送）」、天気は「曇り」であったことがわかる。このように、過去の実績には天気を表示させてもよい。なお、他の日についての昨年の実績（過去の実績）は、図５の表示領域Ｆ３に示すとおりである。
なお、過去の実績は、拠点端末２を操作する者にとって参考となる情報であればよいので、図５の例のように昨年の値であってもよいし、過去数年の平均値であってもよい。
これにより、拠点端末２を操作する者は、運送数量に関する過去の実績を一見して把握することができる。

表示領域Ｆ４には、店舗Ｍ１乃至Ｍ１１の夫々に対する商品の納品数量の予定値（予約数）が日毎に表示されている。
即ち、１２月１２日における、店舗Ｍ１への納品数量が「２セット」、店舗Ｍ３への納品数量が「３セット」、店舗Ｍ５への納品数量が「１セット」、店舗Ｍ８への納品数量が「２セット」、店舗Ｍ９への納品数量が「４セット」であり、店舗Ｍ２、Ｍ４、Ｍ６、Ｍ７、Ｍ１０、及びＭ１１への納品数量が「０セット（納品なし）」であり、合計の運送数量が「１２セット」であることがわかる。
また、１２月１３日における、店舗Ｍ４への納品数量が「３セット」であり、店舗Ｍ１乃至Ｍ３、Ｍ５乃至Ｍ１１への納品数量が「０セット（納品なし）」であり、合計の運送数量が「１２セット」であることがわかる。
また、１２月１４日における、店舗Ｍ１への納品数量が「３セット」、店舗Ｍ２への納品数量が「３セット」、店舗Ｍ３への納品数量が「６セット」、店舗Ｍ５への納品数量が「３セット」、店舗Ｍ７への納品数量が「１セット」、店舗Ｍ１１への納品数量が「４セット」であり、店舗Ｍ４、Ｍ６、及びＭ８乃至Ｍ１０への納品数量が「０セット（納品なし）」であり、合計の運送数量が「２０セット」であることがわかる。なお、他の日についての納品数量は、図５の表示領域Ｆ４に示すとおりである。

これにより、拠点端末２を操作する者は、店舗Ｍ１乃至Ｍ１１の夫々に対する日毎の納品数量の予定値（予約数）を一見して把握することができる。
具体的には例えば、１２月１２日は、１２セットの予約が入っているので、４ｔトラックを１台で運送されることがシミュレーションされている。しかしながら、４ｔトラック１台で最大２５セット運送することができるので、あと１３セット運送することができる。つまり、仮に１３セットの追加予約が入れば、４ｔトラック１台で２５セット運送することになるので、効率的に運送することができる。

つまり、上述のケースにおいて、１２セットの商品を２ｔトラック１台で運送しようとすると、２ｔトラックの最大積載量（１０セット）を２セット超過してしまう。また、１２セットの商品を４ｔトラック１台で運送しようとすると、４ｔトラックの最大積載量（２５セット）まで１３セット足りないため、運送することはできるが、非効率的である。このため、本サービスでは、貨物運搬車両Ｔの種別（タクシー、軽自動車、２ｔトラック、４ｔトラック、及び１０ｔトラック）毎の納品数量の予定値（予約数）が、最大積載量の範囲内で最大になるように調整される。これにより、効率的な運送を実現させることができるので、物流業者Ｌにおける運賃収入の最大化を図ることもできる。

なお、上述のケースにおいて、１２セットのうち１０セットを２ｔトラック１台で運送し、残りの２セットを軽自動車１台で運送することもできる。しかしながら、合計で２台の貨物運搬車両Ｔを配車する必要があるため、合計で２人の運転手を確保する必要があり効率的でない。
このため、上述したように、各貨物運搬車両Ｔの最大積載量（例えば、軽自動車であれば５セット）に納品数量の予定値（予約数）を近付けるように調整することが好ましい。

本サービスでは、表示領域Ｆ４に示す店舗Ｍ１乃至Ｍ１１の夫々の日毎の納品数量の予定値（予約数）を適宜修正することで、納品計画全体を調整することができる。納品数量の予定値（予約数）の調整は、拠点端末２にダウンロードされたアプリケーションプログラム（以下、「アプリ」と呼ぶ）が起動させたり、Ｗｅｂブラウザを起動させたりすることで納品計画を表示させることができる。
さらに、拠点端末２を操作する店舗Ｍ１乃至Ｍ１１の夫々の担当者に対し、アプリ等を介して、納品数量の予定値（予約数）の調整を積極的に勧めることもできる。
以下、図６乃至図１０を参照して、店舗Ｍ１乃至Ｍ１１の夫々の日毎の納品数量の予定値（予約数）を適宜修正する具体的手法について説明する。

図６は、店舗Ｍ８の日毎の納品数量の予定値（予約数）を修正することで納品計画全体を調整する具体的手法を示す図である。

図５で示したように１２月１２日の納品数量の予定値（予約数）の合計は１２セットであるため、上述したように、１３セットの追加予約があれば４ｔトラック１台を用いて効率的に運送することができる。しかしながら、追加予約が期待できない場合には、１２セットのうち２セットを１２月１２日以外の日に運送することができれば、１２月１２日は１０セットだけ運送すればよいことになる。
例えば、図６の表示領域Ｆ４に示すように、店舗Ｍ８に対する納品の日を１日後ろ倒しにすることができれば、１２月１２日は２ｔトラック１台で１０セットだけ運送すればよいので、効率的に運送することができる。

ここで、納品日を１日後ろ倒しにすると、１２月１３日の納品数量の予定値（予約数）の合計が３セットから５セットに増えるので、１２月１３日は軽自動車１台で最大積載量となる５セットを運送することになる。つまり、１２月１２日のみならず、１２月１３日についても効率的に運送することができるようになる。
そこで、本サービスは、１２月１２日が納品日となっている店舗Ｍ１、Ｍ３、Ｍ５、Ｍ８、及びＭ９に対し、納品日を１２月１２日から１２月１３日に変更することを勧める案内を出す。具体的には、納品日を１２月１２日から１２月１３日に変更すると運賃が割引かれる等のメリットも含めた案内を拠点端末２に表示させる。
これに対し、仮に店舗Ｍ８から納品日を１２月１２日から１２月１３日に変更してもよい旨の回答があった場合には、１２月１２日は２ｔトラック１台で１０セットだけ運送すればよい。また、１２月１３日も軽自動車１台で５セットを運送すればよいので、効率的な運送を実現させることができる。

図７は、店舗Ｍ４の日毎の納品数量の予定値（予約数）を修正することで納品計画全体を調整する具体的手法を示す図である。
図８は、店舗Ｍ９の日毎の納品数量の予定値（予約数）を新たに追加することで納品計画全体を調整する具体的手法を示す図である。

図５で示したように、１２月１３日の納品は店舗Ｍ４に対する３セットのみであるため、店舗Ｍ４の納品日を１２月１３日から１２月１４日に変更することができれば、１２月１３日は貨物運搬車両Ｔを走らせずに済むことになる。運転手を休ませることもできる。
また、図７に示すように、１２月１４日の納品数量の予定値（予約数）の合計は２０セットであるため、この変更に伴い３セット増えたとしても、４ｔトラックの最大積載量（２５セット）まで、あと２セットの余裕がある。このため、２セットの追加予約があれば、１２月１４日は４ｔトラックの最大積載量（２５セット）で運送することができるので効率的である。

そこで、本サービスは、店舗Ｍ１乃至Ｍ１１に対し、納品日が１２月１４日となる新たな予約を入れた場合には、運賃が割引かれる等のメリットがある旨を記載した案内を出す。また、店舗Ｍ１乃至Ｍ１１を利用し得る顧客Ｕに対し、店舗Ｍ１乃至Ｍ１１の告知を行う。具体的には、店舗Ｍ１乃至Ｍ１１に関する情報を顧客端末３に表示させることで商品の購入を勧める。なお、顧客端末３に表示させる店舗Ｍ１乃至Ｍ１１に関する情報の具体例については、図９を参照して後述する。

また、店舗Ｍ１乃至Ｍ１１に対する案内に記載されるメリットは、運賃の割引といったような金銭的なものに限定されない。例えば、図８に破線で示すように、天気予報、及び過去の実績に基づいた情報を案内に含めてもよい。
具体的には、商品がスタッドレスタイヤのように、雪が降る前の時点で購入する必要がある商品である場合には、以下のような案内を出すと効果的である。即ち、昨年の１２月１６日から１２月１８日にかけて雪が降り続いたことで運送数量が飛躍的に多くなったが、今年も１２月１７日から１２月１８日にかけて雪が予報されていることを案内に含める。これにより、前倒しで１２月１４日に納品してもらいたいと申し出る店舗Ｍが出てくることが期待できる。
そして、仮に店舗Ｍ９から納品日を１２月１４日とする新たな注文（２セット）があった場合には、図８に示すように、１２月１４日は、４ｔトラックで最大積載量となる２５セットを運送することができる。これにより、効率的な運送を実現させることができる。

図９は、顧客端末３に表示される店舗Ｍ１乃至Ｍ１１に関する情報の具体例を示す図である。

図９に示すように、顧客端末３は、店舗Ｍ１乃至Ｍ１１の夫々に関する情報が一覧表示される。
即ち、図９には、店舗Ｍ１乃至Ｍ１１のうち、一例として、店舗Ｍ８、Ｍ１０、Ｍ７、及びＭ３に関する情報が表示されている。具体的には、店舗外観写真、顧客Ｕからの評価（星印の数）、店舗名、電話番号、所在地、顧客端末３からの距離、商品の最安値が表示されている。また、割引料金が適用される場合にはその旨を示すアイコン（「割引」と表示されたアイコン）が表示されている。図９に示すように、顧客端末３に一覧表示される店舗Ｍ１乃至Ｍ１１の表示の順番は、「顧客端末３からの距離」、「商品の料金」、「顧客Ｕからの評判」を並び替え項目として昇順や降順に並び替えることができる。

ここで、顧客Ｕが、店舗Ｍ８で商品を購入することを検討する場合には、顧客端末３を操作することにより、一覧表示された店舗Ｍ１乃至Ｍ１１のうち、店舗Ｍ８を示すアイコンを押下する。すると、店舗Ｍ８で商品を購入するための予約画面が表示される。なお、顧客端末３に表示される予約画面の具体例については、図１０を参照して後述する。

図１０は、顧客端末３に表示される予約画面の具体例を示す図である。

図１０に示す例では、顧客端末３に店舗Ｍ８に関する情報とともに、店舗Ｍ８で商品の予約を行うための複数のボタンＤ１乃至Ｄ６の夫々が、商品の提供が行われる時間帯毎に表示されている。また、商品の提供が行われる時間帯毎に割引料金の適用がある旨がアイコンで表示されている。
具体的には例えば、商品がスタッドレスタイヤであり、顧客Ｕが１２月１４日の９時から１０時の間に商品に交換する作業を予約する場合には、ボタンＤ２を押下する。また、図１０に示すように、この時間帯は「−５００円」の割引料金が適用される。
これにより、顧客Ｕは、商品を容易に購入することができるとともに、１２月１４日における店舗Ｍ８の新規予約を獲得することができるので、上述の図８に示すような効率的な運送を容易に実現させることができる。

（具体例２）
図１１は、本サービスの他の具体例を示す図である。
図１１に示す地域Ａには、物流センターＣ１と、倉庫Ｗと、店舗Ｍ１乃至Ｍ３と、貨物運搬車両Ｔ１乃至Ｔ３の夫々が存在する。なお、以下、店舗Ｍ１乃至Ｍ３、貨物運搬車両Ｔ１乃至Ｔ３の夫々を個々に区別する必要がない場合、これらをまとめて、「店舗Ｍ」、「貨物運搬車両Ｔ」の夫々と呼ぶ。

物流センターＣ１は、物流業者Ｌが保有する、東日本の顧客Ｕ宛の商品を在庫として保有する大規模な在庫拠点Ｋの１つである。なお、図示はしないが、西日本の顧客Ｕ宛の商品を在庫として保有する物流センターＣ２も存在する。

倉庫Ｗは、物流業者Ｌが保有する、地域Ａの顧客Ｕ宛の商品を在庫として保有する在庫拠点Ｋの１つである。倉庫Ｗが保有する在庫は、物流センターＣ１から運送されてきたものとなる。

店舗Ｍ１乃至Ｍ３は、地域Ａの顧客Ｕに商品を販売する小売店舗である。店舗Ｍ１乃至Ｍ３の夫々が販売する商品は、倉庫Ｗから運送されてきたものとなる。店舗Ｍ１乃至Ｍ３は、いずれも在庫拠点Ｋの１つである。

具体例２における貨物運搬車両Ｔ１乃至Ｔ３は、いずれも商品を運送するトラックである。貨物運搬車両Ｔ１は、ベンダーＶと、物流センターＣ１との間において、商品の運送を担当するトラックである。貨物運搬車両Ｔ２は、物流センターＣ１と倉庫Ｗとの間において、商品の運送を担当するトラックである。貨物運搬車両Ｔ３は、倉庫Ｗと、店舗Ｍ１乃至Ｍ３との間において、商品の運送を担当するトラックである。
なお、図１１における貨物運搬車両Ｔ１乃至Ｔ３は、説明の便宜上、夫々１台のみが表示されているが、いずれも１台に限定されず、様々な種類（積載量）のものが複数台稼働しているものとする。

従来の手法を用いた場合、図１１に示す地域Ａにおける商品の納品は、商品のベンダーＶ、物流センターＣ１、倉庫Ｗ、店舗Ｍ１乃至Ｍ３の順で行われていた。また、商品の納品計画は、上述したように、物流業者側の情報のみに基づいて作成されていた。

例えば、７月２０日の閉店時（午後６：００）の店舗Ｍ１における商品の在庫が８０セットであり、その翌日（７月２１日）と翌々日（７月２２日）との販売見込が、夫々２０セットと１００セットとである場合を想定する。この場合、７月２０日の閉店時（午後６：００）に在庫が８０セットあるので、翌日（７月２１日）の販売は問題ない。しかしながら、翌々日（７月２２日）の販売に備え、翌日（７月２１日）の閉店時（午後６：００）までに少なくとも４０セットを在庫として確保しなければならない。

このような場合、店舗Ｍ１は、荷主Ｓ（図１）に対し、７月２１日の閉店時（午後６：００）までに、７月２２日に販売するための４０セットを納品するよう注文する。店舗Ｍ１からの注文を受けた荷主Ｓは、ベンダーＶを介して物流業者Ｌに対し、７月２１日の閉店時（午後６：００）までに、店舗Ｍ１に４０セットを納品できるよう運送の依頼を行う。運送の依頼を受けた物流業者Ｌは、その依頼内容に基づいて、７月２１日の午後６：００までに、店舗Ｍ１に４０セットを納品するための納品計画を作成する。

具体的には、物流業者Ｌは、地域Ａを管轄する倉庫Ｗの在庫を確認し、在庫が十分にあれば、例えば以下のような納品計画を作成する。
即ち、物流業者Ｌは、商品名が「商品」、出発地が「倉庫Ｗ」、納品地が「店舗Ｍ１（受取人）」、出発日時が「７月２１日 午後４：００」、納品日時が「７月２１日 午後５：００」、使用トラックが「２ｔ（トン）トラック １台」といった納品計画を作成する。

これに対し、倉庫Ｗに十分な在庫がなければ、物流業者Ｌは、例えば以下のような納品計画を作成する。
即ち、商品名が「商品」、出発地が「物流センターＣ１」、経由地が「倉庫Ｗ」、納品地が「店舗Ｍ１（受取人）」、出発日時が「７月２１日 午後１：００」、経由地への到着日時が「７月２１日 午後２：００」、出発地から経由地までの使用トラックが「１０ｔトラック １台 混載便」、経由地の出発日時が「７月２１日 午後４：００」、納品日時が「７月２１日 午後５：００」、経由地から納品地までの使用トラックが「２ｔトラック １台 チャーター便」といった納品計画を作成する。
このように、従来の手法を用いた場合、物流業者Ｌは、物流業者側の情報に基づいて、納品計画を作成していた。

上述したように、従来型の納品管理では、物流業者Ｌが納品計画を作成する際、物流業者側の情報のみが考慮され、荷主側の情報は考慮されていなかった。このため、作成される納品計画は、場当たり的で非効率的なものが作成されることが多かった。
例えば、上述の店舗Ｍ１は、７月２０日の午後６：００の時点で、荷主Ｓに対し、翌日の７月２１日の午後６：００までに４０セット納品してもらう旨の注文を行っている。これは、翌日（７月２１日）と翌々日（７月２２日）の販売見込に基づいたものであるが、それ以降の販売見込が考慮されていない。即ち、７月２０日から１週間、２週間、１ケ月、四半期、半年、１年といった継続的な販売見込に基づいた納品計画がなされていない。このため、作成される納品計画は、場当たり的で非効率的なものになってしまうことが多かった。
そこで、本サービスによれば、従来からある納品管理の手法では実現することができなかった、継続的な販売見込に基づいた納品計画を作成することが可能になる。

具体的には、本サービスでは、店舗Ｍにおける受発注情報に基づいた納品計画が出力される。納品計画には、例えば店舗Ｍの費用負担を最小化させた納品計画が含まれる。また、納品計画が立案される際、貨物運搬車両Ｔの運転手の労働条件等が考慮されるため、コンプライアンスが遵守された納品計画が立案される。
本サービスで立案された納品計画は、拠点端末２を介して各在庫拠点の担当者に提示される。具体的には、例えば拠点端末２にダウンロードされたアプリが起動させたり、Ｗｅｂブラウザを起動させたりすることで納品計画を表示させることができる。

次に、図１２乃至図１４を参照して、サーバ１により立案される納品計画の具体的例について説明する。
図１２は、納品計画が立案される際の根拠となる受発注情報のうち、在庫情報及び見込情報の具体例を示す図である。

図１２（Ａ）は、サーバ１が納品計画を立案する際の根拠となる受発注情報のうち、店舗Ｍ１における商品Ｉの在庫情報の具体例を示す図である。
図１２（Ａ）に示す在庫情報によれば、本日７月２１日月曜日の開店前の午前８：００の時点で、店舗Ｍ１の在庫は１８０セットとなっている。
なお、図５（Ａ）に示す例には、店舗Ｍ１の在庫情報についてのみ示されているが、店舗Ｍ２及びＭ３、倉庫Ｗ、及び物流センターＣ１の在庫情報も管理されている。

図１２（Ｂ）は、サーバ１が納品計画を立案する際の根拠となる情報のうち、店舗Ｍ１の見込情報の具体例を示す図である。
図１２（Ｂ）に示す見込情報によれば、本日７月２１日月曜日の午前８：００の時点で、７月２１日月曜日から７月２７日日曜日までの１週間の払出見込（即ち販売予定数）は、夫々２０セット、１００セット、２０セット、１０セット、４０セット、２００セット、２５０セットとなっている。払出見込は、受注量、過去の払出実績（例えば前年同期の実績、前月同期の実績、先週の実績）等に基づいて算出される。

図１３は、納品計画が立案される際の根拠となる運送物流センター情報のうち、車両情報の具体例を示す図である。

図１３に例示する車両情報によれば、貨物運搬車両Ｔ１乃至Ｔ３として稼働している貨物運搬車両Ｔは、１０ｔトラック、４ｔトラック、２ｔトラック、軽トラックの４種類であり、積載量が夫々１０ｔ、４ｔ、２ｔ、３５０ｋｇとなっている。そして、１台の貨物運搬車両Ｔが一度に積載できる商品Ｉの最大量（最大積載量）は、夫々１００セット、４０セット、２０セット、３セットとなっている。
また、これら４種類の貨物運搬車両Ｔの台数は、１０ｔトラックについては、貨物運搬車両Ｔ１として５台、貨物運搬車両Ｔ２として４台、貨物運搬車両Ｔ３として３台の合計１２台稼働している。４ｔトラックについては、貨物運搬車両Ｔ２として３台、貨物運搬車両Ｔ３として２台の合計５台稼働している。また、２ｔトラックについても、貨物運搬車両Ｔ２として３台、貨物運搬車両Ｔ３として２台の合計５台稼働している。軽トラックについては、貨物運搬車両Ｔ３として５台稼働している。即ち、地域Ａにおいて商品Ｉの運送に用いられる貨物運搬車両Ｔは、合計で２７台ということになる。

また、車両情報には、これら２７台の貨物運搬車両Ｔの夫々について、貨物運搬車両Ｔ自体に関する情報と、貨物運搬車両Ｔの運転手に関する情報とが含まれている。貨物運搬車両Ｔ自体に関する情報には、車両番号、積載量、及び車格が含まれる。運転手に関する情報には、名前（運転手名）、年齢、今月の累計残業時間（累計残業）、今月残業できる時間（残業残り）が含まれる。
具体的には例えば、貨物運搬車両Ｔ１として配備されている５台の貨物運搬車両Ｔのうち、車両番号が「山梨１００かＸＸ−ＸＸ」の貨物運搬車両Ｔは、積載量が「１０ｔ」、車格が「１０ｔウイング」となっている。また、この貨物運搬車両Ｔの運転手は、名前が「山田次郎」、年齢が「３４歳」、今月の累計残業時間が「３８時間」、今月残業できる時間が「１時間」となっている。なお、貨物運搬車両Ｔ１乃至Ｔ３として配備されている他の貨物運搬車両Ｔの車両情報は、図１３に示すとおりである。
このように、納品計画が立案される際、貨物運搬車両Ｔの運転手の労働条件等が考慮されるので、コンプライアンスが遵守された納品計画が立案される。

なお、本例に特に限定されず、例えば残業については、日あたり、週あたり、月あたり、年間総残業等で管理してもよい。
また、例えば、労働、残業、出勤日数も管理して、スケジュールの管理をするようにしてもよい。
また、運転手本人の持病や体調で過剰労働できないという情報等も考慮して、スケジュールの管理をするようにしてもよい。体調については、運転手本人に手動で入力させてもよいが、運転手の端末（スマートフォン）にアプリケーション等をインストールさせて、ログイン時において、センシングして体調を測定するようにしてもよい。

図１４は、図１２及び図１３に示す各種情報に基づきサーバ１により立案される納品計画の具体例を示す図である。

図１４には、７月２１日月曜日の午前８：００時点の店舗Ｍ１における、７月２１日月曜日から７月２７日日曜日までの１週間の納品計画が示されている。

図１４に示す納品計画には、本日７月２１日月曜日から７月２７日日曜日までの夫々の日についての納品予定数と、納品に使用される貨物運搬車両Ｔ３に関する情報が記載されている。
納品予定数は、「納品パターン１」と「納品パターン２」との２種類のパターンが記載されている。
このうち、「納品パターン１」は、店舗Ｍ１の在庫数量と、その日の払出見込数量とに合わせて、略毎日納品される納品パターンを示している。即ち、納品パターン１とすることにより、店舗Ｍ１は、在庫を多く抱えるリスクを回避することができる。
また、「納品パターン２」は、１週間の払出見込数量から、可能な場合は複数日間分をまとめて１回で納品される納品パターンを示している。即ち、「納品パターン２」は、運送回数を減らすべく、サーバ１が、貨物運搬車両Ｔの空きスペースを効率良く利用できるような納品パターン（及び後述する配車パターン）を提示したものである。このような納品パターンとすることにより、店舗Ｍ１は、配送回数を減らすことができるので、運賃を減らすことが可能となる。

図１４に示す納品計画には、納品に使用される貨物運搬車両Ｔ３の種類及び台数について、「配車パターン１」と「配車パターン２」との２種類のパターンが記載されている。このうち、「配車パターン１」は、上述した「納品パターン１」に対応する配車のパターンである。また、「配車パターン２」は、上述した「納品パターン２」に対応する配車のパターンである。

具体的には、納品パターン１（及び配車パターン１）には、納品予定数（及び使用トラック）として、本日７月２１日月曜日に２ｔトラックを１台使用して２０セット、７月２２日火曜日１０ｔトラックを１台使用して８０セット、７月２４日木曜日に４ｔトラックを１台使用して３０セット、７月２５日金曜日に２ｔトラックを１台使用して１０セット、７月２６日土曜日に１０ｔトラックを３台使用して２５０セット、７月２７日日曜日に１０ｔトラックを２台使用して１８０セット納品されることが示されている。また、その運送料金がＸＸ万円であることが示されている。

これに対して、納品パターン２（及び配車パターン２）には、納品予定数（及び使用トラック）として、本日７月２１日月曜日に１０ｔトラックを１台使用して１００セット、７月２４日木曜日に４ｔトラックを１台使用して４０セット、７月２６日土曜日に１０ｔトラックを３台使用して２５０セット、７月２７日日曜日に１０ｔトラックを２台使用して１８０セット納品することが示されている。また、その運送料金がＸＸ万円であることが示されている。
なお、図１４に示す配車パターンには、使用するトラックの種類と台数のみが記載されているが、納品計画には、使用される貨物運搬車両Ｔの車両情報の具体的内容が含まれる。即ち、貨物運搬車両Ｔの運転手に関する情報も含めて配車パターンが立案されるので、貨物運搬車両Ｔの運転手の労働時間に関するコンプライアンスの遵守も含めた納品計画を立案することもできる。

以上のように、サーバ１により立案される納品計画には、２種類の納品パターンが示されるので、店舗Ｍ１は、そのときの財務的な事情や営業的な事情に適合した納品パターン（及び配車パターン）を選択することができる。
その結果、物流業者側の情報のみならず荷主側の情報を考慮した効率的な運送を実現させることができる。

また、従来のスケジュールの調整手法は、単に、店舗や個人等の荷物の発注又は発送先側の利便性で終わっていた。
これに対して、上述の本実施形態を適用することで、店舗や個人等の荷物の発注又は発送先側のみならず、その間の荷主やベンダー側、物流側の３者の要求の夫々に応じて、適切かつ効率的なスケジューリングが可能になる。
また、スケジューリングの要素として、設備と人の夫々を考慮したスケジューリングが可能になる。換言すると、従来は、何れか一方の要素しか考慮されておらず、意味があまりないスケジューリングであったが、このようなことがなくなる。

以上、本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、上述の実施形態では、物流業者Ｌが商品を運送するために貨物運搬車両Ｔを用いているが、車両に限定されず、例えば船舶、飛行体等であってもよい。

また例えば、上述した実施形態において立案される納品計画は、１週間程度の期間についてのものとなっているが、これは例示にすぎない。１ケ月、四半期、半年、１年等、あらゆる単位で納品計画を立案することができる。

また例えば、図１４に示す納品計画には、２種類の納品パターン（及び配車パターン２）が示されているが、これは例示にすぎない。さらに多くの種類の納品パターンが立案されてもよい。例えば図１４に示す納品計画のうち、納品パターン１（及び配車パターン１）において、７月２５日金曜日は、２ｔトラック１台により１０セット納品される予定になっているが、他の配車パターンが立案されてもよい。例えば、図示はしないが、軽トラック４台により１０セット納品されるという配車パターン３が立案されてもよい。この場合、２ｔトラック１台を使用した運送料金が３万円であり、軽トラック４台を使用した運送料金が２万４０００円（６０００円×４台）であれば、配車パターン３は、「最も運送料金が安い配車パターン」として立案される。
また同様に、パターン１において、７月２６日土曜日は、１０ｔトラック３台により２５０セット納品される予定になっているが、「最も運送料金が安い配車パターン」としての配車パターン３（図示せず）が立案されてもよい。例えば、１０ｔトラック２台と、４ｔトラック１台と、２ｔトラック１台とによって２５０セット納品されるという配車パターン３が立案されてもよい。ここで、１０ｔトラックを使用した運送料金が１台１０万円であり、４ｔトラックを使用した運送料金が１台７万円であり、２ｔトラック１台を使用した運送料金が３万円とした場合、運送料金は以下のとおりとなる。即ち、パターン１の料金は３０万円（１０万円×３台）となるが、パターン３の料金は２９万円（１０万円×２台＋６万円×１台＋３万円×１台）となりリーズナブルである。
また、物流業者Ｌの繁忙事情により、曜日によって運送料金が異なる場合には、例えば運送料金が比較的高い週末の運送よりも、平日の運送を勧める納品パターン（及び配車パターン）を立案することもできる。具体的には、図示はしないが、運送料金が比較的安い７月２３日水曜日や７月２４日木曜日の時点で、週末までに納品予定となっている４７０セットを一度に納品する納品パターン（及び配車パターン）を立案することもできる。

また、図３に示す各ハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。

また、図４に示す機能ブロック図は、例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは、特に図４の例に限定されない。

また、機能ブロックの存在場所も、図４に限定されず、任意でよい。例えばサーバ１側の機能ブロックの少なくとも一部を拠点端末２側に設けてもよいし、その逆でもよい。
そして、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体との組み合わせで構成してもよい。

各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、各ユーザにプログラムを提供するために装置本体とは別に配布される、リムーバブルメディアにより構成されるだけではなく、装置本体に予め組み込まれた状態で各ユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に添って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

以上まとめると、本発明が適用される情報処理装置は、次のような構成を取れば足り、各種各様な実施形態を取ることができる。
即ち、本発明が適用される情報処理装置（例えば図４のサーバ１）は、
拠点（例えば店舗Ｍ１乃至Ｍ１１）間の商品の運送に関する計画を運送計画（例えば納品計画）として立案する情報処理装置において、
１以上の前記拠点の夫々における、商品の受け入れ及び払い出しに関する情報を、受発注情報として取得する第１取得手段（例えば図４の受発注情報取得部１０１）と、
前記受発注情報を含む情報に基づいて、前記商品の在庫の滞りを解消させる前記運送計画を前記拠点毎に立案する立案手段（例えば図４の立案部１０３）と、
を備える。

これにより、荷主側の情報が考慮された、柔軟な納品計画を容易に作成することができる。その結果、無駄のない効率的な運送を実現させることができる。

また、前記立案手段により立案された前記運送計画を、前記拠点に提示する提示手段（例えば図４の提示部１０４）をさらに備えることができる。

これにより、拠点端末２を操作する者は、立案された納品計画を一見して把握することができるので、例えば、各在庫拠点Ｋ（店舗Ｍ等）におけるスケジュールの調整が容易になる。

また、前記受発注情報には、前記１以上の拠点の夫々における前記商品の払い出しの見込みに関する情報（例えば見込情報）が含まれる、とすることができる。

これにより、将来の見込を含む荷主側の情報が考慮された、柔軟な納品計画を容易に作成することができる。例えば、昨年の実績等の過去の実績や、天候等が考慮された納品計画を容易に作成することができる。

また、前記運送計画の遂行に必要となる情報として、前記商品の運送を行う者が管理し得る運送に関する情報を、運送物流センター情報として取得する第２取得手段（例えば図４の運送物流センター情報取得部１０２）をさらに備え、
前記立案手段は、取得された前記運送物流センター情報と、前記受発注情報に基づいて、前記拠点における前記商品の在庫の滞りを解消させる前記運送計画を立案することができる。

これにより、物流業者側の情報と、荷主側の情報とに基づく実効的な納品計画の立案が可能となる。

また、前記立案手段は、さらに、前記拠点に１回で運送される前記商品の数量を調整して、前記拠点における前記商品の在庫の滞りを解消させる前記運送計画を立案することができる。

これにより、物流業者側の情報と、荷主側の情報とに基づく実効的かつ柔軟な納品計画の立案が可能となる。その結果、さらに無駄のない効率的な運送を実現させることができる。例えば、店舗Ｍ等の了承の下に、２ｔトラックと軽自動車とに分けて運送する、といったように分割して運送することも可能となる。

１：サーバ、２，２−１，２−ｎ：拠点端末、３，３−１，３−ｍ：顧客端末、１１：ＣＰＵ、１２：ＲＯＭ、１３：ＲＡＭ、１４：バス、１５：入出力インターフェース、１６：出力部、１７：入力部、１８：記憶部、１９：通信部、２０：ドライブ、３０：リムーバブルメディア、１０１：受発注情報取得部、１０２：運送物流センター情報取得部、１０３：立案部、１０４：提示部、４０１：受発注ＤＢ、４０２：運送ＤＢ、Ｍ，Ｍ１乃至Ｍ１１：店舗、Ｓ：荷主、Ｖ：ベンダー、Ｌ：物流業者、Ｋ，Ｋ１乃至Ｋｎ：拠点、Ｕ，Ｕ１乃至Ｕｍ：顧客、Ｉ：商品、Ｎ：ネットワーク、Ａ：地域、Ｃ１，Ｃ２：物流センター、Ｆ１乃至Ｆ４：表示領域、Ｂ：バー、Ｇ：ゲージ、Ｄ１乃至Ｄ６：ボタン、Ｗ：倉庫、Ｔ，Ｔ１乃至Ｔ３：貨物運搬車両

Claims (5)

1. 拠点間の商品の運送に関する計画を運送計画として立案する情報処理装置において、
   １以上の前記拠点の夫々における、商品の受け入れ及び払い出しに関する情報を、受発注情報として取得する第１取得手段と、
   前記受発注情報を含む情報に基づいて、前記商品の在庫の滞りを解消させる前記運送計画を前記拠点毎に立案する立案手段と、
   を備える情報処理装置。
2. 前記立案手段により立案された前記運送計画を、前記拠点に提示する提示手段をさらに備える、
   請求項１に記載の情報処理装置。
3. 前記受発注情報には、前記１以上の拠点の夫々における前記商品の払い出しの見込みに関する情報が含まれる、
   請求項１又は２に記載の情報処理装置。
4. 前記運送計画の遂行に必要となる情報として、前記商品の運送を行う者が管理し得る運送に関する情報を、運送物流センター情報として取得する第２取得手段をさらに備え、
   前記立案手段は、取得された前記運送物流センター情報と、前記受発注情報に基づいて、前記拠点における前記商品の在庫の滞りを解消させる前記運送計画を立案する、
   請求項１乃至３のうちいずれか１項に記載の情報処理装置。
5. 前記立案手段は、さらに、前記拠点に１回で運送される前記商品の数量を調整して、前記拠点における前記商品の在庫の滞りを解消させる前記運送計画を立案する、
   請求項４に記載の情報処理装置。

Images