JP2010102556A - 物流事故管理装置、物流事故管理方法およびプログラム - Google Patents

Abstract

【課題】損害保険業務のサービス提供側からすると、物流の過程に起きた事故の正確な情報が必要である。また、顧客側としても、物流事故回避の対策のためには、起きた事故の分析をいち早く行えることが望ましい。
【解決手段】物流事故管理装置は、流通させる対象物品の物品情報と、経由地または目的地に関する経路情報が複数順序付けられて物品情報に関連付けられる運送地情報と、流通時に発生した事故に関する逐次外部から取得される事故情報とを管理し、これらに矛盾が無いかを判定して、矛盾が無いと判定された場合に、事故情報に含まれるそれぞれの経路情報のうち、最初の経由地または目的地として順序付けられている地点を事故発生地として出力する。
【選択図】図２

Description

本発明は、物流事故管理装置、物流事故管理方法およびプログラムに関する。

近時、物流に関する損害保険の業務においても、物流そのものの管理から、事故情報収集、保険金の請求に至るまで、サービス提供側と顧客側が共にネットワークを利用する形態が広がりつつある。例えば、特許文献１には、顧客側の地位に応じてサービスの提供に違いを与える情報処理装置が開示されている。
特開２００７−７２８１１

損害保険業務のサービス提供側からすると、物流の過程に起きた事故の正確な情報が必要である。また、顧客側としても、物流事故回避の対策のためには、起きた事故の分析をいち早く行えることが望ましい。

そこで本発明は、上記の課題を解決するための物流事故管理装置、物流事故管理方法およびプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。

上記課題を解決するために、本発明の第１の態様においては、 流通させる対象物品の物品情報と、経由地または目的地に関する経路情報が複数順序付けられて物品情報に関連付けられる運送地情報と、流通時に発生した事故に関する情報であって物品情報および経路情報に関連付けられる事故情報と、を格納する物流情報格納部と、物品情報と、少なくとも一つの経路情報と、事故による破損の程度および破損箇所の少なくともいずれか一方を含む破損情報と、を含む個別事故情報を取得し、取得した個別事故情報に含まれる物品情報と同一の物品情報を物流情報格納部から検索し、検索された物品情報に関連付けられている事故情報に、取得した個別事故情報に含まれる経路情報に対応させて破損情報を追加する事故情報取得部と、事故情報取得部によって複数の個別事故情報が取得された後に、物流情報格納部に格納されている、運送地情報に含まれる複数の経路情報の順序と、事故情報に含まれるそれぞれの経由地または目的地で発生した破損情報とに矛盾が無いかを判定する判定部と、判定部により矛盾が無いと判定された場合に、事故情報に含まれるそれぞれの経路情報のうち、最初の経由地または目的地として順序付けられている地点を事故発生地として出力する出力部とを有する物流事故管理装置が提供される。

また、第２の態様においては、操作処理部、物流情報格納部、事故情報取得部、判定部および出力部を備える物流事故管理装置による物流事故管理方法であって、操作処理部が、流通させる対象物品の物品情報と、経由地または目的地に関する経路情報が複数順序付けられて物品情報に関連付けられる運送地情報と、流通時に発生した事故に関する情報であって物品情報および経路情報に関連付けられる事故情報と、を物流情報格納部に格納する物流情報格納ステップと、事故情報取得部が、物品情報と、少なくとも一つ経路情報と、事故による破損の程度および破損箇所の少なくともいずれか一方を含む破損情報と、を含む個別事故情報を取得し、取得した個別事故情報に含まれる物品情報と同一の物品情報を物流情報格納部から検索し、検索された物品情報に関連付けられている事故情報に、取得した個別事故情報に含まれる経路情報に対応させて破損情報を追加する事故情報取得ステップと、判定部が、事故情報取得ステップによって複数の個別事故情報が取得された後に、物流情報格納部に格納されている、運送地情報に含まれる複数の経路情報の順序と、事故情報に含まれるそれぞれの経由地または目的地で発生した破損情報とに矛盾が無いかを判定する判定ステップと、出力部が、判定ステップにより矛盾が無いと判定された場合に、事故情報に含まれるそれぞれの経路情報のうち、最初の経由地または目的地として順序付けられている地点を事故発生地として出力する出力ステップとを有する物流事故管理方法が提供される。

また、第３の態様においては、上記第２の態様における物流事故管理方法をコンピュータに実行させるためのプログラムが提供される。

なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではない。また、これらの特徴群のサブコンビネーションもまた、発明となりうる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではない。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、本実施形態に係る物流事故管理システムの概略構成を示す図である。物流事故管理システムは、ネットワーク１１０を介して、物流事故管理装置であるサーバ１００と、各端末１２１〜１２４とが相互に接続されている。

サーバ１００のオペレータは、サーバ１００と直接的に接続されているモニタ１０１を見ながら、同じくサーバ１００と直接的に接続されている入力装置１０２を操作することにより、様々な入力、指示等をサーバ１００に与えることができる。また、ネットワーク１１０を介して、端末１２１〜１２４側で入力した各種情報、指示等をサーバ１００に送信したり、逆にサーバ１００から各種情報、指示等を受信することができる。

端末としては様々な機器が利用できる。例えば図示するように、デスクトップ型ＰＣである端末１２１、ノート型ＰＣである端末１２２のようなＰＣに限らず、ＰＤＡタイプの端末１２３、携帯電話である端末１２４であっても良い。これらの機器は、ユーザが所定の入力を行うための入力部と、ユーザーインターフェースとしてのモニタを備え、さらにネットワークとの接続機能を有する。

図２は、サーバ１００の概略構成図である。主たる構成として、物流情報データベース２０１、事故情報取得部２０２、判定部２０３、出力部２０４、グループ情報データベース２０５を含むグループ管理部２０６、および操作処理部２０７を備える。

物流情報データベース２０１には、対象物品の流通前にオペレータによって入力装置１０２から予め入力される当該対象物品に関する情報が、操作処理部２０７の処理を介して格納される。また、対象物品の流通過程または流通後には、ネットワーク１１０から送信されてくる複数の個別事故情報が、事故情報取得部２０２の所定の処理を介して、物流情報データベース２０１に格納される。このとき事故情報取得部２０２は、予め物流情報データベース２０１に格納されている対象物品に関する情報を参照する。

複数の個別事故情報が物流情報データベース２０１に格納された段階で、オペレータからの出力要求を操作処理部２０７が受け付ける。オペレータは、流通前に対象物品に関する情報を入力した者である場合もあるし、それ以外の者である場合もある。出力要求を受け付けると、グループ管理部２０６は、当該オペレータのグループ属性をグループ情報データベース２０５に格納されたグループ情報により認証し、要求された情報の存在を物流情報データベース２０１で確認する。そして、所定の条件を満たす場合には、グループ管理部２０６は、判定部２０３に対して判定を指示する。

判定の指示を受けると、判定部２０３は取得され格納された複数の個別事故情報の相互に矛盾が無いかを判定を行う。そして出力部２０４は、その判定に応じた情報をモニタ１０１またはネットワーク１１０に対して出力する。なお、出力部２０４は、物流情報データベース２０１に格納された対象物品に関する個々の情報についても、モニタ１０１またはネットワーク１１０に対して出力することができる。

ここで、本実施形態における物流管理の全体について説明する。
物流事故管理システム全体の管理者は、損害保険業務のサービス提供側である保険会社である。そして、顧客側としては、商品等の物品の流通を主体的に行うメーカー、運送会社等が想定される。メーカー、運送会社等は、物品を流通させるにあたり保険会社と保険契約を結ぶ。保険会社は、流通させる物品ごとに個別に管理を行う。具体的には、物品の情報としての商品名、シリアルナンバー等、流通経路としての出発地、目的地、中継地、またはその間に設定される経由地などの運送地情報、そして、どの地点で、物品のどこにどの程度の破損が生じたのかについての事故情報などを管理する。各々の事故情報は、対象物品の運搬を担当する担当者から逐次報告を受けることにより集積される。保険会社は、このような情報を管理することにより、正確な保険金の支払いが可能となり、また、顧客側もこのシステムを共有することにより、いち早く事故の状況を把握することができることから、さらなる物流への対策が可能となる。

物品の物流における運搬は、往々にして、出発地から最終的な目的地まで同一の者により行われるわけではなく、複数の者により中継されて行われる。そして、運搬を担当する各々の担当者は、自らが担当した区間において設定されている少なくともひとつ以上のチェックポイントで、事故が発生していないかをチェックする。

具体的には、事故が発生していた場合に、対象物品のどこにどの程度の破損が生じたのかを端末１２１等に入力する。入力された情報は、対象物品の経由地または目的地としての情報であるチェックポイント情報と共に個別事故情報として、端末１２１等からネットワーク１１０を介してサーバ１００に送られる。そして、サーバ１００は、複数の担当者から送られてくるそれぞれの個別事故情報を格納し、対象物品の流通が終了するまで漸次蓄積する。

このように、複数の担当者により中継されて運搬された場合、必然的にチェックにばらつきが生じる。ばらつきの発生は、担当者による見落としであったり、担当者間の判断基準の相違であったり、さまざまな原因が考えられる。このようにチェックにばらつきが生じると、事故の発生地点が不明確になり、正確な保険金の支払いや事故対策に支障をきたす。そこで、サーバは、このようにして蓄積される個別事故情報を分析して、それらに矛盾が無いかを判定した上で事故発生地を特定する。

以上のような物流管理の全体において、例として自動車を運搬する場合を以下具体的に説明する。図３は、流通させる自動車に関するデータテーブルの一例を示す図である。このデータテーブルは、物流情報データベース２０１に格納される。

図示するように、データテーブル３００は、大別すると物品情報、運送地情報および事故情報から構成される。そして、物品情報は、自動車の名称である車種と、個々の自動車ごとに与えられるシリアルナンバーとから成る。運送地情報は、運送の拠点などとなる拠点の名称と、その拠点が具体的にどの地点であるかを表す場所記号とから成る。事故情報は、自動車のどの部分が破損したかを表す破損箇所記号と、その破損の程度を表す程度ランクとから成る。もちろん、他の情報が付加的に加えられていても良い。

保険会社に所属するオペレータは、これから自動車を流通させようとする前に、まずそれぞれの物品情報を入力する。具体的には、オペレータは入力装置１０２から自動車の名称として、たとえば「スーパーＩＩ」、「ウルトラＶ」といった車種情報を入力する。そして、それぞれのシリアルナンバーを入力する。シリアルナンバーは固体識別番号であり、１台につき１つの番号が与えられている。したがって、同種の自動車を複数運搬するときには、車種としては重複してデータテーブル３００に複数現れることがあっても、シリアルナンバーが重複することが無い。

次にオペレータは、物品情報として入力した自動車をどこからどこへ、どこを経由して運搬するかの入力を行う。一つの対象物品に限って見れば、出発地と目的地の情報があり、必要に応じてその間に経由地の情報があれば事足りる。しかし、対象物品が大量の場合、所々に物流拠点を設けて、出発地点、目的地点の異なる対象物品を離合集散させて効率的に運搬することが一般に行われていることを考慮に入れる必要がある。そのような物流拠点を中間の目的地として考えると、最終の目的地に到達する前に複数の目的地を経由することになる。そして、さらに出発地と目的地または目的地と目的地の間である物流拠点間には、選択する運搬経路に依存して経由地が定められる。つまり、大量の対象物品を運搬する場合には、出発地と複数の目的地、およびそれぞれの間に設定される経由地の情報をまとめて管理することが望ましい。

オペレータは、運送地情報として、出発地を選択し、必要に応じて物流拠点となる中間の目的地を順次選択し、そして最終の目的地を選択する。具体的な選択に仕方については後述する。このように順次選択される地点には、「出発地」、「目的地１」、「目的地２」…というように名称が与えられる。出発地および目的地が設定されると、出発地と目的地の間、または、目的地と目的地の間に、必要に応じて経由地が選択できるようになる。オペレータは、その中からチェックポイントとしての経由地を順次選択する。具体的な選択に仕方については後述する。このように選択された経由地には、「経由地１」、「経由地２」…というように名称が与えられる。そして、選択された出発地、目的地、経由地のそれぞれが、具体的にどの地点であるかを示す場所記号が、与えられた名称と共にセットで格納される。

このようにして、運搬する対象物品の物品情報と運送地情報を入力すると、これらの情報と共に、事故情報を格納する格納領域が用意される。上述のように事故情報は、破損箇所記号と程度ランクとから成るが、これらは、運送地情報として選択され設定された出発地、目的地、経由地のそれぞれに対応するように格納領域が確保される。これらの領域は、流通前の段階であるこの段階では、当然ながら空欄である。この領域が具体的にどのように入力されるかについては後述する。

図４は、出発地入力のインターフェース画面の一例を示す図である。この画面は、サーバ１００により生成されて、モニタ１０１に表示される。オペレータは、この画面を見ながら入力装置１０２により入力を行う。入力された指示は、サーバ１００の操作処理部２０７へ送られる。

インターフェース画面４００は、オペレータに出発地を入力させるための画面である。入力要求部４０１は、オペレータに現在の表示画面が出発地の入力画面であることを示すと同時に、その入力を催促する。オペレータは、地名を直接入力する場合には、入力ボックス４０２に地名を入力する。地図から入力する場合には、地図領域４０３に表示された地図上の地点にカーソル４１０を移動させることにより選択する。入力ボックス４０２での入力もしくはカーソル４１０による選択が終わると、決定ボタン４２０をカーソル４１０により選択することで、出発地の入力が完了する。出発地の入力が完了すると、入力要求部４０１は、「目的地１を選択してください」に表示が切り替わり、オペレータは同様の操作で目的地１の入力を行う。オペレータは、最終目的地である目的地ｎを入力するまでこの操作を繰り返す。最終目的地までにいくつの目的地を経由するかは、運搬される対象物品に依るので、ｎは１以上の整数で可変である。オペレータは、目的地ｎの入力が完了した段階でさらに決定ボタン４２０を選択することにより、その入力が最終目的地であることを指示する。

図５は、目的地対応テーブルの一例を示す図である。上述のように入力される出発地および目的地は、予め物流情報データベース２０１に格納されている目的地対応テーブル５００により、場所記号に変換される。目的地対応テーブル５００は、具体的には、出発地または目的地として選択されうる地名と、それぞれに対応させて与えれれる場所記号がセットで格納されている。例えば、横浜市金沢区にある八景島工場は、場所記号としてａ０１が与えられている。したがって、データテーブル３００の運送地情報としては、名称である「出発地１」「目的地１」…と、その各々に対応して、オペレータにより入力された地点が変換された場所記号とがセットで格納される。

図６は、経由地入力のインターフェース画面の一例を示す図である。この画面は、サーバ１００により生成されて、モニタ１０１に表示される。オペレータは、この画面を見ながら入力装置１０２により入力を行う。入力された指示は、サーバ１００の操作処理部２０７へ送られる。

インターフェース画面６００は、オペレータに経由地を入力させるための画面である。入力要求部６０１は、オペレータに現在の表示画面が経由地の入力画面であることを示すと同時に、その入力を催促する。オペレータは、地図領域６０２に表示された地図上の経由地点にカーソル６１０を移動することにより選択する。

具体的には、サーバはモニタ１０１に、入力された出発地と目的地１を含む地図を地図領域６０２に表示し、その出発地点６３１と目的地１地点６３２を重畳表示する。そしてこの間を結ぶルート上に、選択可能な経由地点をその地点が選択できるように経由地ボックス６３３として複数表示する。オペレータは、必要に応じて拡大ボタン６０３または縮小ボタン６０４を用いて地図を拡大縮小させながら、必要なだけ経由地ボックス６３３を選択していく。オペレータは、必要な経由地ボックスの選択が終了すると、決定ボタン６２０を選択することで、出発地から目的地１までの経由地の入力を完了する。

出発地から目的地１までの経由地の入力が完了すると、出発地点６３１は、適切な地図の地点に目的地１地点として表示が切り替わり、同時に目的地１地点６３２は、適切な地図の地点に目的地２地点として表示が切り替わる。そしてこの間を結ぶルート上に、選択可能な経由地点をその地点が選択できるように経由地ボックス６３３として複数表示する。オペレータは同様の操作でこの間の経由地の入力を行う。オペレータは、最終目的地ｎのひとつ前の目的地である目的地ｎ−１と、最終目的地である目的地ｎとの間の経由地の入力が完了するまでこの操作を繰り返す。

図７は、経由地対応テーブルの一例を示す図である。上述のように入力される経由地は、予め物流情報データベース２０１に格納されている経由地対応テーブル７００により、場所記号に変換される。経由地対応テーブル７００は、具体的には、経由として選択されうる地名と、それぞれに対応させて与えれれる場所記号がセットで格納されている。例えば、東京都町田市にある町田集荷場は、場所記号としてａＡ０１が与えられている。したがって、データテーブル３００の運送地情報としては、名称である「経由地１」「経由地２」…と、その各々に対応して、オペレータにより入力された地点が変換された場所記号とがセットで格納される。なお、入力された出発地、経由地および目的地のそれぞれは経路情報として、例えば図３に図示するように、対象物品の運搬経路に従った順にソートされて格納される。つまり、出発地、経由地および目的地と、それらのそれぞれとセットで格納される場所記号とは、各々が経路情報を形成し、これらが運送地情報として運搬経路の順に並べられていると言える。

続いて、運搬前の段階では空欄であるが、事故情報の欄がどのように事故情報を格納するかについて説明する。
図８は、破損箇所対応テーブルの一例を示す図である。破損箇所対応テーブル８００は、予め物流情報データベース２０１に格納されている、破損箇所を破損箇所記号に変換するための変換テーブルである。図示するように、例えば破損箇所が「フロントガラス右側」であれば、この箇所に対応して与えれられている破損箇所記号「ＦＧ１」に変換され、この破損箇所記号「ＦＧ１」がデータテーブル３００の事故情報の欄に格納される。

図９は、程度ランク対応テーブルの一例を示す図である。程度ランク対応テーブル９００は、予め物流情報データベース２０１に格納されている、破損の程度を程度ランクに変換するための変換テーブルである。図示するように、例えば破損の程度が「直径１ｍｍ以下のキズ」であれば、この程度に対応して与えれられている程度ランク「Ａ」に変換され、この程度ランク「Ａ」がデータテーブル３００の事故情報の欄に格納される。なお、程度ランクは、「Ａ」から「Ｚ」に向かうに従って破損の程度が甚大になるように設定されている。したがって、破損の程度が大きいほど程度ランクが高いといえる。例えば、程度ランクが「Ｃ」より高い「Ｄ」の方が、破損の程度は大きい。

次に、対象物品の流通過程または流通後において、端末１２１〜１２４からネットワーク１１０を介してサーバ１００へ送られてくる個別事故情報の形式について説明する。
図１０は、個別事故情報のテーブルの一例を示す図である。個別事故情報は、区間情報１０１０と破損情報１０２０により構成される。上述したように、一般的に、対象物品の運搬には出発地から最終目的地に到達するまでに、区間を分けて複数の担当者が携わることが多い。それぞれの区間を担当する担当者は、端末１２１〜１２４のような端末を持ち、その端末から運搬結果としての個別事故情報をサーバに報告する。したがって、個別事故情報は、それぞれの区間を担当する担当者から、担当する区間、担当者単位などで複数かつ逐次サーバに送られてくることになる。

各区間の担当者の端末には、対象物品の運搬に先立ち、区間情報１０１０がサーバ１００から送られてくる。区間情報１０１０は、物品情報としての車種およびシリアルナンバーと、経路情報としてのその担当者が担当する区間の出発地、経由地および目的地の名称および場所記号により構成される。その担当者が、例えば、全体の運送地情報における「目的地２」から「目的地３」を担当する場合であって、その間に「経由地７」を唯一含むような場合を想定する。この場合、区間情報１０１０の「出発地」には全体の「目的地２」の情報が、「目的地」には全体の「目的地２」の情報がセットされる。また、全体の「目的地２」と「目的地３」の間には「経由地７」が経由地として１つ含まれるので、経路情報として「経由地１」が「出発地」と「目的地」の間に生成されて、ここに全体の「経由地７」の情報である場所記号がセットされる。経由地が複数存在する場合には、それに合わせて経路情報が生成される。

区間情報１０１０が対象物品の運搬に先立ってサーバ１００から送られてくるのと同時に、破損情報１０２０の格納スペースが生成される。破損情報１０２０は、区間情報１０１０の出発地、経由地および目的地が設定された、運搬している対象物品の破損状況を担当者がチェックする各チェックポイント、および、これに対応した破損箇所記号および程度ランクを格納する格納欄により構成される。

担当者は、出発時およびチェックポイントに到着するたびに運搬している対象物品を確認する。破損が生じていなければ破損情報を空欄とし、破損が生じているときには破損箇所とその程度を入力する。具体的な入力の仕方について以下に説明する。

図１１は、破損箇所入力のインターフェース画面の一例を示す図である。この画面は、端末内にインストールされたソフトウェアにより生成されて、端末のモニタに表示される。担当者は、この画面を見ながら入力を行う。

インターフェース画面１１００は、担当者に破損箇所を入力させるための画面である。入力要求部１１０１は、担当者に現在の表示画面が破損箇所の入力画面であることを示すと同時に、その入力を催促する。担当者は、展開図的に表現された自動車の画面上をカーソル１１１０を移動することにより選択する。具体的には、展開図的に表現された自動車の表示に重ねて、チェック対象箇所にチェックボックス１１０２を表示する。そして、担当者は、カーソル１１１０により、破損が生じている箇所のチェックボックスにチェックを入れていく。全てのチェックの入力が終了したら、決定ボタン１１２０の選択により破損箇所の入力を完了する。作業をキャンセルする場合には、キャンセルボタン１１３０を選択する。

破損箇所の入力が完了すると、チェックされた破損箇所に対して破損の程度を入力する画面に遷移する。担当者は、それぞれの破損箇所の破損の程度を、例えば、「直径１ｍｍ以上５ｍｍ以下のキズ」などを選択する。

各々のチェックポイントで入力された破損についての情報は、チェックポイントに対応付けられて破損情報１０２０に格納される。破損情報１０２０に破損の情報が入力されると、サーバ１００へ個別事故情報として送信することが可能となる。担当者は、各々のチェックポイントで破損の情報を入力するたびにサーバ１００へ送信しても良いし、担当する区間の目的地に到着した後に一括して送信しても良い。

次に、サーバ１００に対して事故情報を要求するオペレータについて説明する。オペレータとして考えられるグループは、システム全体の管理者としての保険会社と、顧客としてのメーカー、運送会社等、および実際に運搬を担当する担当者などである。これらの各グループは、階層的に権限の大小関係が予め規定されており、グループごとにサーバ１００に対して要求できる出力の範囲が異なる。

図１２は、グループ管理テーブルの一例を示す図である。グループ管理テーブル１２００は、対象物品の運搬に先立って予め作成され、グループ情報データベース２０５に格納される。

上述のようにグループは階層化されており、その権限の大きい順にグループＧｐ．Ａ〜グループＧｐ．Ｃが割り当てられている。権限の最も大きいＧｐ．Ａは、例えば保険会社である。このＧｐ．Ａには、対象物品の運搬経路の全行程における事故情報の出力が許可されている。すなわち、全行程が出力許可範囲として与えられている。一方、最も権限の小さいＧｐ．Ｃには、例えば各区間の担当者もしくはその担当者が所属する運搬業者である。Ｇｐ．Ｃには、担当する目的地間の事故情報の出力が許可されている。そして、それぞれのグループに属するオペレータがサーバ１００に事故情報を要求するときには、サーバ１００からパスワードの入力を求められ、オペレータは正しいパスワードを入力しなければならない。このパスワードは、予めグループと出力許可範囲とともに設定され、グループ管理テーブルの項目として格納されている。

次に、これまで説明した情報処理の流れ、および事故情報の出力を要求されたときの処理の流れをフロー図を用いて説明する。図１３は、出力要求を受けるまでの情報処理を表すフロー図であり、図１４は、出力要求を受けてからの情報処理を表すフロー図である。

ステップＳ１３０１では、図３を用いて説明したように、運搬する対象物品情報の入力を受け付ける。オペレータの入力は、操作処理部２０７が受け付ける。続いてステップＳ１３０２では、同じく図３を用いて説明したように、運送地情報の入力を受け付ける。このオペレータの入力も、操作処理部２０７が受け付ける。対象物品が複数存在する場合には、ステップＳ１３０１とステップＳ１３０２を繰り返してオペレータの入力を受け付けるようにしても良い。

対象物品の物品情報および運送地情報を受け付けると、ステップＳ１３０３で、これらに対応したデータテーブル３００を生成する。このとき、データテーブル３００は、事故情報の格納欄を包含する。操作処理部２０７は、生成したデータテーブル３００を、物流情報データベース２０１へ格納する。

ステップＳ１３０１〜ステップＳ１３０３は、対象物品の物流開始前に行われるステップであるが、ステップＳ１３０４以降は、物流開始後に行われるステップである。ステップＳ１３０４では、ネットワーク１１０を介して運搬担当者から送られてくる個別事故情報を、事故情報取得部２０２が取得する。

ここで、図１０を用いて説明した個別事故情報を、事故情報取得部２０２が取得したときの処理について説明する。事故情報取得部２０２が個別事故情報を取得すると、まずその個別事故情報に含まれる区間情報１０１０を参照する。事故情報取得部２０２はさらに、区間情報１０１０に含まれる物品情報である車種およびシリアルナンバーと同一の車種およびシリアルナンバーを、物流情報データベース２０１に格納されているデータテーブル３００の物品情報から検索、抽出する。そして、事故情報取得部２０２は、個別事故情報に含まれる破損情報１０２０のチェックポイントの場所記号と同一の場所記号を持つ運送地情報を検索し、これに対応する事故情報の欄に破損情報１０２０の破損箇所記号および程度ランクをコピーする。このようにして、逐次送られてくる個別事故情報を、データテーブル３００に取り込む。

このように漸次蓄積されていく事故情報に対して、操作処理部２０７は、事故発生地点、破損箇所、破損の程度についての出力要求を、入力装置１０２またはネットワーク１１０を介してオペレータから受け付ける。ステップＳ１３０５で出力要求があるか否かを判断し、ある場合は図１４のステップＳ１４０１へ進む。要求が無ければステップＳ１３０６へ進み、対象物品が最終目的地に到達したか、つまり、最終目的地を含む個別事故情報を取得したか否かを判断する。まだ取得していなければ、ステップＳ１３０４へ戻り、さらに個別事故情報が送られてくることを待つ。取得が完了していれば、ステップＳ１３０５へ戻り、オペレータからの出力要求を待つ。

ステップＳ１３０５で出力要求があると判断されると、ステップＳ１４０１で、操作処理部２０７は、オペレータが対象物品のどの運搬区間の出力を求めているかの入力を受け付ける。そして、ステップＳ１４０２で、グループ管理部２０６は、出力を求めているオペレータのグループ認証を行う。具体的には、オペレータにパスワードの入力を求め、そのパスワードが、グループ情報データベース２０５に格納されているグループ管理テーブル１２００に存在するかを検索する。存在すれば、そのパスワードに対応する出力許可範囲を参照し、出力が求められた運搬区間が出力許可範囲内に含まれるか否かを判断する。ステップＳ１４０３では、パスワードがグループ管理テーブル１２００に存在しない場合、またはパスワードが存在しても出力を求められた運搬区間の出力が出力許可範囲を超える場合には、出力を許可しない。この場合は、ステップＳ１４０１へ戻る。そうでない場合は出力を許可し、ステップＳ１４０４へ進む。

ステップＳ１４０４では、判定部２０３が、出力を求められた運搬区間においてデータテーブル３００に矛盾が無いかのデータ判定を行う。この処理については後に詳述する。そして、ステップＳ１４０５では、判定部２０３は、データ判定の結果が矛盾判定であったか否かを出力部２０４へ送る。矛盾がない、つまり正常判定であればステップＳ１４０６へ進む。そして、出力部２０４は、ステップＳ１４０６で、データテーブル３００を参照して最初の事故発生地を検索し、その事故発生地および事故情報をモニタ１０１またはネットワーク１１０へ出力する。具体的には、破損箇所記号または程度ランクが最初に出現した経由地または目的地の地名を、その場所記号を用いて、目的地対応テーブル５００または経由地対応テーブル７００を参照して特定する。同時にその破損箇所記号および程度ランクを、破損箇所対応テーブル８００および程度ランク対応テーブル９００を参照して変換する。そして、具体的な地名、破損箇所およびその程度を事故発生地および事故情報として、モニタ１０１またはネットワーク１１０へ出力する。なお、破損箇所が複数存在する場合には、それぞれの破損がどこで発生したかを破損箇所およびその程度と共に、複数出力するようにしても良い。

矛盾がある、つまり矛盾判定であればステップＳ１４０７へ進む。そして、出力部２０４は、エラー情報をモニタ１０１またはネットワーク１１０へ出力する。具体的なエラー情報としては、データテーブル３００にどのような矛盾するデータが格納されているかを示す情報などが考えられる。

出力部２０４による出力が完了すると、ステップＳ１４０８に進み、対象物品がすでに最終目的地に到着しているか否かを判断する。つまり、最終目的地を含む個別事故情報をすでに取得しているか否かを判断する。まだ取得していなければ、図１３のステップＳ１３０４へ戻る。取得が完了していれば、一連の処理を終了する。

ここで、ステップＳ１４０４のデータ判定について説明する。図１５は、データ判定の情報処理を表すフロー図である。なお、各々のステップは、判定部２０３が処理する。

ステップＳ１５０１では、先の事故情報の破損箇所を、後の事故情報の破損箇所が包含するか否かを判断する。データテーブル３００の運送地情報は、対象物品の運搬経路に従った順にソートされて格納されているが、その順番に事故情報の破損箇所を見たときに、一旦出現した破損箇所がその後のデータに存在していない場合には、事故情報として何らかの欠陥を含んでいることになる。正常なデータであれば、一旦出現した破損箇所は最終目的地まで出現し続ける。他の箇所に新たに破損箇所が生じることもあるので、別言すれば、後の事故情報の破損箇所は、先の事故情報の破損箇所を含んでいることが、正常な事故情報であると言える。この判断の結果、含む場合はステップＳ１５０２へ進み、そうでない場合は、ステップＳ１５０４へ進む。

ステップＳ１５０２では、先の事故情報の程度ランクより、後の事故情報の程度ランクのほうが低いか否かを判断する。データテーブル３００の運送地情報の順番に事故情報の程度ランクを見たときに、一旦出現した破損箇所の破損の程度がその後低くなっている場合には、事故情報として何らかの欠陥を含んでいることになる。正常なデータであれば、一旦出現した破損箇所の破損の程度ランクは、最終目的地に至るまで同じであるか、または更なる事故が発生して高くなることはあっても、低くなることは無い。複数の破損箇所があったとしても、それぞれ個別に破損の程度を順番に見たときには、先の程度ランクよりも後の程度ランクの方が低くなることは無い。この判断の結果、低い場合はステップＳ１５０４へ進み、そうでない場合は、ステップＳ１５０３へ進む。

ステップＳ１５０３では、データテーブル３００の事故情報が正常であるとする、正常判定との判定結果を生成する。ステップＳ１５０４では、データテーブル３００の事故情報が矛盾を含むものとして、矛盾判定との判定結果を生成する。そして、メインのフローに戻る。

図１６は、矛盾を生じさせる破損情報のパターンを説明するための図である。破損情報１６０１〜１６０４は、図１０を用いて説明した破損情報１０２０の具体例である。

破損情報１６０１および１６０２は、破損箇所および程度ランクの発生および推移において、正常な場合の情報である。破損情報１６０１では、対象物品の運搬経路は、ｃ０７→ｄＡ０３→ｅ０１の順であるが、チェックポイントｄＡ０３でＦＧ２に破損が生じ、その程度ランクはＣであると記入されている。そして、その後の地点であるチェックポイントｅ０１においても、チェックポイントｄＡ０３での判断と同じ判断がなされ、ＦＧ２に破損が生じ、その程度ランクはＣであると記入されている。このような情報に矛盾は無い。また、破損情報１６０２では、破損情報１６０１の状況に加え、さらにチェックポイントｅ０１において新たにＦＧ１に破損が生じ、その程度ランクはＢであると記入されているが、このような情報であっても矛盾は無い。

破損情報１６０３および１６０４は、破損箇所および程度ランクの発生および推移において、矛盾を含む場合の情報である。破損情報１６０３では、チェックポイントｄＡ０３においてＦＧ２に破損が生じ、その程度ランクはＣであると記入されているにも関わらず、その後のチェックポイントｅ０１では、破損箇所記号及び程度ランクの欄が空欄になっている。つまり、ｄＡ０３からｅ０１へ運搬される過程で破損が消えてしまったことになっている。このような情報には矛盾が存在すると言える。また、破損情報１６０４では、チェックポイントｄＡ０３で、ＦＧ２に破損が生じ、その程度ランクがＣであると記入されているにもかかわらず、その後のチェックポイントｅ０１では、同じ破損箇所の程度ランクがＡになっている。程度ランクは、「Ａ」から「Ｚ」に向かうに従って破損の程度が甚大になるように設定されているので、ｄＡ０３からｅ０１へ運搬される過程で破損が一部修復したことになってしまう。このような情報には矛盾が存在すると言える。

なお、矛盾を生じさせる破損情報のパターンを簡便に説明するために、破損情報１０２０を用いて説明したが、実際に判定部２０３が参照する情報は、データテーブル３００である。データテーブル３００の事故情報は、破損情報１０２０の内容を全て取り込んでいるので、その判断としては図１６を用いて説明した判断と同様に行うことができる。

以上説明においては、対象物品として自動車を挙げたが、もちろん、運搬される対象物品は自動車に限られるものではない。例えば、対象物品が小さい物品である場合には、破損箇所を細かく分けて管理する必要が無いこともあり、この場合には、データテーブル３００の事故情報の欄と破損情報１０２０の破損箇所の情報は持たなくても良い。また、修理の可能性が無く、一旦破損したら廃棄するしかないような物品である場合には、破損したか否かの情報が必要なのであって、破損の程度の情報を持つことに意味が無い場合もある。この場合には、データテーブル３００の事故情報の欄と破損情報１０２０の程度ランクの情報は持たなくても良い。これらの情報のアレンジに従って、判定部２０３による判定は適宜必要な修正がなされる。例えば、破損箇所の情報が無ければステップＳ１５０１が削除され、程度ランクの情報が無ければステップＳ１５０２が削除される。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

特許請求の範囲、明細書、および図面中において示した装置、システム、プログラム、および方法における動作、手順、ステップ、および段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り、任意の順序で実現しうることに留意すべきである。特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず、」、「次に、」等を用いて説明したとしても、この順で実施することが必須であることを意味するものではない。

物流事故管理システムの概略構成を示す図である。 サーバ１００の概略構成図である。 流通させる自動車に関するデータテーブルの一例を示す図である。 出発地入力のインターフェース画面の一例を示す図である。 目的地対応テーブルの一例を示す図である。 経由地入力のインターフェース画面の一例を示す図である。 経由地対応テーブルの一例を示す図である。 破損箇所対応テーブルの一例を示す図である。 程度ランク対応テーブルの一例を示す図である。 個別事故情報のテーブルの一例を示す図である。 破損箇所入力のインターフェース画面の一例を示す図である。 グループ管理テーブルの一例を示す図である。 出力要求を受けるまでの情報処理を表すフロー図である。 出力要求を受けてからの情報処理を表すフロー図である。 データ判定の情報処理を表すフロー図である。 矛盾を生じさせる破損情報のパターンを説明するための図である。

符号の説明

１００ サーバ、１０１ モニタ、１０２ 入力装置、１１０ ネットワーク、１２１，１２２，１２３，１２４ 端末、２０１ 物流情報データベース、２０２ 事故情報取得部、２０３ 判定部、２０４ 出力部、２０５ グループ情報データベース、２０６ グループ管理部、２０７ 操作処理部、３００ データテーブル、４００ インターフェース画面、４０１ 入力要求部、４０２ 入力ボックス、４０３ 地図領域、４１０ カーソル、４２０ 決定ボタン、５００ 目的地対応テーブル、６００ インターフェース画面、６０１ 入力要求部、６０２ 地図領域、６０３ 拡大ボタン、６０４ 縮小ボタン、６１０ カーソル、６２０ 決定ボタン、６３１ 出発地点、６３２ 目的地１地点、６３３ 経由地ボックス、７００ 経由地対応テーブル、８００ 破損箇所対応テーブル、９００ 程度ランク対応テーブル、１０１０ 区間情報、１０２０ 破損情報、１１００ インターフェース画面、１１０１ 入力要求部、１１０２ チェックボックス、１１１０ カーソル、１１２０ 決定ボタン、１１３０ キャンセルボタン、１２００ グループ管理テーブル、１６０１，１６０２，１６０３，１６０４ 破損情報

Claims (6)

1. 流通させる対象物品の物品情報と、経由地または目的地に関する経路情報が複数順序付けられて前記物品情報に関連付けられる運送地情報と、流通時に発生した事故に関する情報であって前記物品情報および前記経路情報に関連付けられる事故情報と、を格納する物流情報格納部と、
   物品情報と、少なくとも一つの経路情報と、事故による破損の程度および破損箇所の少なくともいずれか一方を含む破損情報と、を含む個別事故情報を取得し、取得した個別事故情報に含まれる物品情報と同一の物品情報を前記物流情報格納部から検索し、検索された物品情報に関連付けられている事故情報に、前記取得した個別事故情報に含まれる経路情報に対応させて前記破損情報を追加する事故情報取得部と、
   前記事故情報取得部によって複数の前記個別事故情報が取得された後に、前記物流情報格納部に格納されている、前記運送地情報に含まれる複数の経路情報の順序と、前記事故情報に含まれるそれぞれの経由地または目的地で発生した破損情報とに矛盾が無いかを判定する判定部と、
   前記判定部により矛盾が無いと判定された場合に、前記事故情報に含まれるそれぞれの経路情報のうち、最初の経由地または目的地として順序付けられている地点を事故発生地として出力する出力部とを有する物流事故管理装置。
2. 前記判定部は、前記矛盾として、経由地または目的地の順序が後である前記事故情報の破損の程度の方が、先である前記事故情報の破損の程度よりも軽い、または、経由地または目的地の順序が後である前記事故情報の破損箇所が、先である前記事故情報の破損箇所を含まないことを判定する請求項１に記載の物流事故管理装置。
3. 前記出力部は、前記判定部により矛盾が有ると判定された場合に、エラー情報を出力する請求項１または２に記載の物流事故管理装置。
4. 前記物流事故管理装置の操作を許可するオペレータを複数のグループに分けて管理し、オペレータがどのグループに属するかによって、グループごとに予め定められた範囲を限度として、前記出力部による出力を許可するグループ管理部をさらに有する請求項１ないし３のいずれか１項に記載の物流事故管理装置。
5. 操作処理部、物流情報格納部、事故情報取得部、判定部および出力部を備える物流事故管理装置による物流事故管理方法であって、
   前記操作処理部が、流通させる対象物品の物品情報と、経由地または目的地に関する経路情報が複数順序付けられて前記物品情報に関連付けられる運送地情報と、流通時に発生した事故に関する情報であって前記物品情報および前記経路情報に関連付けられる事故情報と、を前記物流情報格納部に格納する物流情報格納ステップと、
   前記事故情報取得部が、物品情報と、少なくとも一つ経路情報と、事故による破損の程度および破損箇所の少なくともいずれか一方を含む破損情報と、を含む個別事故情報を取得し、取得した個別事故情報に含まれる物品情報と同一の物品情報を前記物流情報格納部から検索し、検索された物品情報に関連付けられている事故情報に、前記取得した個別事故情報に含まれる経路情報に対応させて前記破損情報を追加する事故情報取得ステップと、
   前記判定部が、前記事故情報取得ステップによって複数の前記個別事故情報が取得された後に、前記物流情報格納部に格納されている、前記運送地情報に含まれる複数の経路情報の順序と、前記事故情報に含まれるそれぞれの経由地または目的地で発生した破損情報とに矛盾が無いかを判定する判定ステップと、
   前記出力部が、前記判定ステップにより矛盾が無いと判定された場合に、前記事故情報に含まれるそれぞれの経路情報のうち、最初の経由地または目的地として順序付けられている地点を事故発生地として出力する出力ステップとを有する物流事故管理方法。
6. 請求項５に記載の物流事故管理方法をコンピュータに実行させるためのプログラム。

Images