(57)【特許請求の範囲】
【請求項１】
多種形状を有する複数の積載物として複数の車両種類から構成される複数の自動車を台車に積載し発送を行う複数の発送拠点に設けられる発送拠点コンピュータと、
各発送拠点コンピュータとネットワークで接続され、当該複数の発送拠点における積載物である自動車の積載状態を管理する集中管理部のホストコンピュータと、
を含む発送管理システムであって、
前記各発送拠点コンピュータは、
自動車の全長又は高さ又はシャシの種類に関連して車両種類が同一のものを同一のグループ番号のグループとして個々の自動車を分類するグループ化ルールを有し、複数の発送積載物としての複数の自動車について、発送する自動車が抽出されたときのその自動車の車両種類を前記グループ化ルールと比較して、各自動車それぞれを該当するグループ番号のグループにそれぞれ変換するグループ化手段と、
前記台車に積載する予定の複数の発送自動車について、各グループごとにそのグループ番号に属する自動車の数を集計して、グループ番号とそのグループ番号に属する自動車の数とを組合せ、その組合せの集合で前記複数の発送自動車の構成を表わす組合せパターンを形成するパターン形成手段と、
前記集中管理部のホストコンピュータに対し、前記形成された組合せパターンと、前記発送自動車を積載する予定の台車の種別とを送信する問い合わせ手段と、
前記集中管理部のホストコンピュータから、問い合わせ結果を受信し、それに基づき発送指示を行う指示手段と、
を含み、
前記集中管理部のホストコンピュータは、
台車種別毎の積載可能組合せパターンを蓄積するホストデータベースと、
前記各発送拠点コンピュータから送られてきた台車種別をキーに前記ホストデータベースを検索して該台車種別に積載可能な組合せパターンを取得し、
取得した積載可能組合せパターンと、前記各発送拠点コンピュータから送られてきた組合せパターンとを比較し、
前記送られてきた組合せパターンにおけるグループ番号と自動車数とが、前記取得した積載可能組合せパターンにおけるグループ番号と自動車数とに含まれる場合には、前記送られてきた台車種別の台車に積載可と判断し、前記取得した積載可能組合せパターンにおけるグループ番号と自動車数とに含まれない場合には、前記送られてきた台車種別の台車に積載不可と判断し、
問い合わせのあった発送拠点コンピュータに前記判断結果を送信して通知する通知手段と、
を含むことを特徴とする発送管理システム。
【請求項２】
多種形状を有する複数の積載物として複数の車両種類から構成される複数の自動車を台車に積載し発送を行う複数の発送拠点に設けられる発送拠点コンピュータと、各発送拠点コンピュータとネットワークで接続され、当該複数の発送拠点における積載物である自動車の積載状態を管理する集中管理部のホストコンピュータと、を含む発送管理システムであって、
前記各発送拠点コンピュータは、
自動車の全長又は高さ又はシャシの種類に関連して車両種類が同一のものを同一のグループ番号のグループとして個々の自動車を分類するグループ化ルールを有し、前記複数の車両種類から構成される複数の自動車について、発送を希望する自動車が抽出されたときのその車両種類を前記グループ化ルールと比較して、各自動車それぞれを該当するグループ番号のグループにそれぞれ変換するグループ化手段と、
台車に積載を希望する複数の自動車について、各グループごとにそのグループ番号に属する自動車の数を集計して、グループ番号とそのグループ番号に属する自動車の数とを組合せ、その組合せの集合で前記複数の自動車の構成を表わす組合せパターンを形成するパターン形成手段と、
前記集中管理部のホストコンピュータに対し、前記形成された組合せパターンと、積載予定の台車の種別とを送信し、台車に積載が可能であるか問い合わせる問い合わせ手段と、
前記集中管理部のホストコンピュータから、問い合わせ結果を受信し、それに基づき発送指示を行う指示手段と、
を含み、
前記集中管理部のホストコンピュータは、
各発送拠点における発送実績に基づいて台車種別毎の積載可能組合せパターンを蓄積するホストデータベースと、
前記各発送拠点コンピュータからの台車種別と組合せパターンが積載可能であるかの問い合わせを受信し、
前記各発送拠点コンピュータから送られてきた台車種別をキーに前記ホストデータベースの蓄積内容を検索し、
検索された積載可能組合せパターンと、前記各発送拠点コンピュータから送られてきた組合せパターンとを比較し、
前記問い合わせの内容として送られてきた組合せパターンにおけるグループ番号と自動車数に合致する積載可能データがある場合には、前記送られてきた台車種別の台車に積載可と判断し、前記問い合わせの内容として送られてきた組合せパターンにおけるグループ番号と自動車数に合致する積載可能データがない場合には、前記送られてきた台車種別の台車に積載不可と判断し、
問い合わせのあった発送拠点コンピュータに送信して通知する通知手段と、
を含むことを特徴とする発送管理システム。
【請求項３】
請求項１又は請求項２に記載のシステムにおいて、
前記各発送拠点コンピュータは、
前記集中管理部のホストコンピュータに対し、台車種別毎の組合せパターンで表わされた発送実績を送信する手段を含み、
前記集中管理部のホストコンピュータは、
前記発送実績を受信し、ホストデータベースに追加記録する手段を含むことを特徴とする発送管理システム。
【請求項４】
多種形状を有する複数の積載物として複数の車両種類から構成される複数の自動車を台車に積載し発送を行う複数の発送拠点に設けられる発送拠点コンピュータと、当該複数の発送拠点における積載物である自動車の積載状態を管理する集中管理部のホストコンピュータとの間でネットワークを介して情報の交換を行いながら発送状態の管理を行う発送管理方法であって、
前記各発送拠点コンピュータは、
自動車の全長又は高さ又はシャシの種類に関連して車両種類が同一のものを同一のグループ番号のグループとして個々の自動車を分類するグループ化ルールを有し、前記複数の車両種類から構成される複数の自動車について、発送を希望する自動車が抽出されたときのその車両種類を前記グループ化ルールと比較して、各自動車それぞれを該当するグループ番号のグループにそれぞれ変換するステップと、
台車に積載を希望する複数の自動車について、各グループごとにそのグループ番号に属する自動車の数を集計して、グループ番号とそのグループ番号に属する自動車の数とを組合せ、その組合せの集合で前記複数の自動車の構成を表わす組合せパターンを形成するステップと、
前記集中管理部のホストコンピュータに対し、前記形成された組合せパターンと、積載予定の台車の種別とを送信し、台車に積載が可能であるか問い合わせる問い合わせステップと、
前記集中管理部のホストコンピュータから、問い合わせ結果を受信し、それに基づき発送指示を行うステップと、
を含んで処理し、
前記集中管理部のホストコンピュータは、
各発送拠点における発送実績に基づいて台車種別毎の積載可能組合せパターンをホストデータベースに蓄積するステップと、
前記各発送拠点コンピュータからの台車種別と組合せパターンが積載可能であるかの問い合わせを受信するステップと、
前記各発送拠点コンピュータから送られてきた台車種別をキーに前記ホストデータベースに蓄積した組合せパターンを検索するステップと、
前記検索された積載可能組合せパターンと、前記各発送拠点コンピュータから送られてきた組合せパターンとを比較するステップと、
前記問い合わせの内容として送られてきた組合せパターンにおけるグループ番号と自動車数に合致する積載可能データがある場合には、前記送られてきた台車種別の台車に積載可と判断し、前記問い合わせの内容として送られてきた組合せパターンにおけるグループ番号と自動車数に合致する積載可能データがない場合には、前記送られてきた台車種別の台車に積載不可と判断するステップと、
問い合わせのあった発送拠点コンピュータに送信して通知するステップと、
を含んで処理することを特徴とする発送管理方法。
【請求項５】
請求項４記載の方法において、
前記各発送拠点コンピュータは、
前記集中管理部のホストコンピュータに対し、台車種別毎の組合せパターンで表わされた発送実績を送信するステップを含み、
前記集中管理部のホストコンピュータは、
前記発送実績を受信し、ホストデータベースに追加記録するステップを含んで処理することを特徴とする発送管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、積載物の発送管理システム及び発送管理方法、特に、多種形状を有する複数の積載物を台車に同時積載し発送を行う複数の発送拠点と、当該複数の発送拠点における積載物の積載状態を管理する集中管理部と、の間で情報交換を行い、効率のよい発送管理を行う技術の改良に関する。
【０００２】
【従来の技術】
多種形状を有する積載物、例えば、自動車を生産工場や倉庫等の発送拠点から他の場所に搬送する場合、自動搬送車両（キャリアカー）等の台車に複数台同時積載して搬送する。このような場合、同時に積載可能な種類の組合せが予め知られていれば、積載作業を開始してから積載が不可能であることに気がつくといった事態の発生を防止することができる。
【０００３】
通常、１台のキャリアカーは、１〜１０台程度の自動車の積載が可能になっている。例えば、５台積載できるキャリアカーを例にとると、積載スペース１〜５に対して、車種Ａ，Ｂ，Ｃ，Ｄ，Ｅの５種類の自動車を積載しようとした場合、その積載の組合せは、５×４×３×２通りが存在する。キャリアカーの場合、通常、自動車を上段、下段の２層に分けて積載するが、その上段部分のフロア（道板という）が上下動自在になっており、道板の高さや傾きを変化させることで、積み合わせ不可能な車種の組合せが積み合わせ可能になることがある。また、自動車の積み込み位置も前後方向に調整可能であることから、積み込み位置を調整することで積み合わせ不可能な車種の組合せが積み合わせ可能になることがある。道板の上下動や自動車の積み込み位置の調整は、検討している積載スペースに隣接するスペースに積載する車種との関係で位置調整が可能か否かが変化する。例えば、道板を標準位置から１０ｃｍ下げればその上段に車種Ａを積載できる時に、下段に車種Ｂが積載されていれば、道板を下げられるのに、下段に車種Ｃが積載されていると道板を下げられないという事態が発生する。
【０００４】
そのため、５台の自動車を積載できるキャリアカーに、車種Ａ〜Ｅの５種類の自動車を組合せて同時に積載可能か否かを検証する最も単純な問題でさえ、実際に検証しようとすると、様々な場合を想定して計算する必要があり、判断に多大な時間を要していた。従って、所定のキャリアカーに積載可能な積載物の種類とその組合せを予め求めておく必要がある。
【０００５】
なお、言うまでもなく、自動車には、様々な形状パターン（例えば、１ＢＯＸタイプや３ＢＯＸタイプ）が存在し、更に同じ形状パターンでもその大きさは大小様々に変化する。また、キャリアカーの基本種類も複数存在し、更に、頻繁に積載される自動車に合わせて改造が施されたりして、実際の種類は更に増加する。
【０００６】
従来、上述したような所定キャリアカーに対する積載可能な積載物の種類とその組合せは、各発送拠点毎のベテラン作業者が過去の経験と知識に基づいて積載の可否判断を行っていた。
【０００７】
【発明が解決しようとする課題】
前述したように、多種形状を有する複数の積載物に対するキャリアカーの積載の可否判断は、各発送拠点で独自に個々に行われ、また各発送拠点において要求される積載物の組合せは、納入先の要望により常時変化する。そして、その度の可否判断は大変時間とコストを要する非合理的なものであった。そのため、過去に同様な積載物の組合せで発送を行った発送拠点から発送情報を取得することが望ましい。しかし、前述したように、各発送拠点では、独自に可否判断を行っているので、何処の発送拠点から発送情報を得たらよいかの判断が困難であり、また、各発送拠点で使用するキャリアカーは、それぞれ、発送内容に応じて、改造が施されている場合が多く、積載物の組合せとキャリアカーの組合せ数も膨大な数になり、自らが所望する最適な積載物の組合せとキャリアカーの組合せが存在するか否かの判断すら困難であるという問題を有する。また、使用できるキャリアカーも各発送拠点間で使い回しが行われる場合が多く、使用できるキャリアカーの種類も頻繁に変更になり、前述のような積載可否判断を頻繁に行う必要があり、その作業が繁雑であるという問題がある。
【０００８】
さらに、新たな種類の積載物が発生した場合、いずれかの発送拠点で積載物の組合せの計算を実行するが、上述したように他の発送拠点とは、相互に管理を行っていないので、その結果を他の発送拠点で有効に利用できないという問題を有する。また、発送拠点間で発送情報の交換を行う場合も、その発送情報は、個々の積載物の詳細な特徴を含んだものが多く、その情報量も膨大であり、情報交換も容易に行えないという問題を有する。
【０００９】
本発明は、上記課題に鑑みなされたものであり、各発送拠点間での積載物の組合せに関する情報交換が容易であり、経済的かつ効率的な積載物の発送管理を行うことのできる積載物の発送管理システム及び発送管理方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
上記のような目的を達成するために、本発明の発送管理システムは、多種形状を有する複数の積載物として複数の車両種類から構成される複数の自動車を台車に積載し発送を行う複数の発送拠点に設けられる発送拠点コンピュータと、各発送拠点コンピュータとネットワークで接続され、当該複数の発送拠点における積載物である自動車の積載状態を管理する集中管理部のホストコンピュータと、を含む発送管理システムであって、前記各発送拠点コンピュータは、自動車の全長又は高さ又はシャシの種類に関連して車両種類が同一のものを同一のグループ番号のグループとして個々の自動車を分類するグループ化ルールを有し、複数の発送積載物としての複数の自動車について、発送する自動車が抽出されたときのその自動車の車両種類を前記グループ化ルールと比較して、各自動車それぞれを該当するグループ番号のグループにそれぞれ変換するグループ化手段と、前記台車に積載する予定の複数の発送自動車について、各グループごとにそのグループ番号に属する自動車の数を集計して、グループ番号とそのグループ番号に属する自動車の数とを組合せ、その組合せの集合で前記複数の発送自動車の構成を表わす組合せパターンを形成するパターン形成手段と、前記集中管理部のホストコンピュータに対し、前記形成された組合せパターンと、前記発送自動車を積載する予定の台車の種別とを送信する問い合わせ手段と、前記集中管理部のホストコンピュータから、問い合わせ結果を受信し、それに基づき発送指示を行う指示手段と、を含み、前記集中管理部のホストコンピュータは、台車種別毎の積載可能組合せパターンを蓄積するホストデータベースと、前記各発送拠点コンピュータから送られてきた台車種別をキーに前記ホストデータベースを検索して該台車種別に積載可能な組合せパターンを取得し、取得した積載可能組合せパターンと、前記各発送拠点コンピュータから送られてきた組合せパターンとを比較し、前記送られてきた組合せパターンにおけるグループ番号と自動車数とが、前記取得した積載可能組合せパターンにおけるグループ番号と自動車数とに含まれる場合には、前記送られてきた台車種別の台車に積載可と判断し、前記取得した積載可能組合せパターンにおけるグループ番号と自動車数とに含まれない場合には、前記送られてきた台車種別の台車に積載不可と判断をし、問い合わせのあった発送拠点コンピュータに前記判断結果を送信して通知する通知手段と、を含むことを特徴とする。
また、本発明の発送管理システムは、多種形状を有する複数の積載物として複数の車両種類から構成される複数の自動車を台車に積載し発送を行う複数の発送拠点に設けられる発送拠点コンピュータと、各発送拠点コンピュータとネットワークで接続され、当該複数の発送拠点における積載物である自動車の積載状態を管理する集中管理部のホストコンピュータと、を含む発送管理システムであって、前記各発送拠点コンピュータは、自動車の全長又は高さ又はシャシの種類に関連して車両種類が同一のものを同一のグループ番号のグループとして個々の自動車を分類するグループ化ルールを有し、前記複数の車両種類から構成される複数の自動車について、発送を希望する自動車が抽出されたときのその車両種類を前記グループ化ルールと比較して、各自動車それぞれを該当するグループ番号のグループにそれぞれ変換するグループ化手段と、台車に積載を希望する複数の自動車について、各グループごとにそのグループ番号に属する自動車の数を集計して、グループ番号とそのグループ番号に属する自動車の数とを組合せ、その組合せの集合で前記複数の自動車の構成を表わす組合せパターンを形成するパターン形成手段と、前記集中管理部のホストコンピュータに対し、前記形成された組合せパターンと、積載予定の台車の種別とを送信し、台車に積載が可能であるか問い合わせる問い合わせ手段と、前記集中管理部のホストコンピュータから、問い合わせ結果を受信し、それに基づき発送指示を行う指示手段と、を含み、前記集中管理部のホストコンピュータは、各発送拠点における発送実績に基づいて台車種別毎の積載可能組合せパターンを蓄積するホストデータベースと、前記各発送拠点コンピュータからの台車種別と組合せパターンが積載可能であるかの問い合わせを受信し、前記各発送拠点コンピュータから送られてきた台車種別をキーに前記ホストデータベースの蓄積内容を検索し、検索された積載可能組合せパターンと、前記各発送拠点コンピュータから送られてきた組合せパターンとを比較し、前記問い合わせの内容として送られてきた組合せパターンにおけるグループ番号と自動車数に合致する積載可能データがある場合には、前記送られてきた台車種別の台車に積載可と判断し、前記問い合わせの内容として送られてきた組合せパターンにおけるグループ番号と自動車数に合致する積載可能データがない場合には、前記送られてきた台車種別の台車に積載不可と判断し、問い合わせのあった発送拠点コンピュータに送信して通知する通知手段と、を含むことを特徴とする。
【００１１】
また、本発明の発送管理方法は、多種形状を有する複数の積載物として複数の車両種類から構成される複数の自動車を台車に積載し発送を行う複数の発送拠点に設けられる発送拠点コンピュータと、当該複数の発送拠点における積載物である自動車の積載状態を管理する集中管理部のホストコンピュータとの間でネットワークを介して情報の交換を行いながら発送状態の管理を行う発送管理方法であって、前記各発送拠点コンピュータは、自動車の全長又は高さ又はシャシの種類に関連して車両種類が同一のものを同一のグループ番号のグループとして個々の自動車を分類するグループ化ルールを有し、前記複数の車両種類から構成される複数の自動車について、発送を希望する自動車が抽出されたときのその車両種類を前記グループ化ルールと比較して、各自動車それぞれを該当するグループ番号のグループにそれぞれ変換するステップと、台車に積載を希望する複数の自動車について、各グループごとにそのグループ番号に属する自動車の数を集計して、グループ番号とそのグループ番号に属する自動車の数とを組合せ、その組合せの集合で前記複数の自動車の構成を表わす組合せパターンを形成するステップと、前記集中管理部のホストコンピュータに対し、前記形成された組合せパターンと、積載予定の台車の種別とを送信し、台車に積載が可能であるか問い合わせる問い合わせステップと、前記集中管理部のホストコンピュータから、問い合わせ結果を受信し、それに基づき発送指示を行うステップと、を含んで処理し、前記集中管理部のホストコンピュータは、各発送拠点における発送実績に基づいて台車種別毎の積載可能組合せパターンをホストデータベースに蓄積するステップと、前記各発送拠点コンピュータからの台車種別と組合せパターンが積載可能であるかの問い合わせを受信するステップと、前記各発送拠点コンピュータから送られてきた台車種別をキーに前記ホストデータベースに蓄積した組合せパターンを検索するステップと、前記検索された積載可能組合せパターンと、前記各発送拠点コンピュータから送られてきた組合せパターンとを比較するステップと、前記問い合わせの内容として送られてきた組合せパターンにおけるグループ番号と自動車数に合致する積載可能データがある場合には、前記送られてきた台車種別の台車に積載可と判断し、前記問い合わせの内容として送られてきた組合せパターンにおけるグループ番号と自動車数に合致する積載可能データがない場合には、前記送られてきた台車種別の台車に積載不可と判断するステップと、問い合わせのあった発送拠点コンピュータに送信して通知するステップと、を含んで処理することを特徴とする。
【００１２】
ここで、積載物をグループに分類するルールとは、同一視できる特徴、例えば、全長と高さが同一なものを同じグループにするというものである。例えば、積載物が自動車の場合、車種が異なっても、同一のシャシを使用したものや部分的な部品が異なるのみである場合がある。このようなものは、実質的には、同一の積載物と判断し、同一グループとする。また、１ＢＯＸタイプと、３ＢＯＸタイプ等でもグループ分けを行うことができる。そして、各発送拠点側では、前記積載物をグループに分類するルールに基づきグループの組合せパターンを形成し、この組合せパターンにより集中管理部側との間で情報の交換を行う。つまり、集中管理部側は、組合せパターンの形態で発送情報を蓄積すればよく、発送情報の蓄積量を著しく縮小することが可能であり、その検索速度も向上することができる。なお、集中管理部側は、ある台車に積載できるグループの最大パターンを保持し、それより積載数が少ない場合は、積載可能と判断することが好ましい。
【００１３】
この構成によれば、各発送拠点側は、所望する積載物の組合せパターンを作り、その組合せパターンによる積載の可否を集中管理部側に問い合わせるのみでよいので、各発送拠点側において、問い合わせ先は一つであり、かつ複雑な発送計算を行う必要がなくなり、効率的な発送管理を行うことができる。また、情報の交換を組合せパターンの状態で行うので、集中管理部側における情報の蓄積量の削減や検索速度の向上、及び相互間の情報交換速度の向上も容易に行うことができる。
【００１４】
上記のような目的を達成するために、本発明の発送管理システムは、上記構成において、前記各発送拠点コンピュータは、前記集中管理部のホストコンピュータに対し、台車種別毎の組合せパターンで表わされた発送実績を送信する手段を含み、前記集中管理部のホストコンピュータは、前記発送実績を受信し、ホストデータベースに追加記録する手段を含むことを特徴とする。
【００１５】
また、本発明の発送管理方法は、上記構成において、前記各発送拠点コンピュータは、前記集中管理部のホストコンピュータに対し、台車種別毎の組合せパターンで表わされた発送実績を送信するステップを含み、前記集中管理部のホストコンピュータは、前記発送実績を受信し、ホストデータベースに追加記録するステップを含んで処理することを特徴とする。
【００１６】
前述したように、台車（キャリアカー）の形態は、複数存在するため、集中管理部側から提供される台車と組合せグループの組合せが完全に一致しない場合がある。この時、集中管理部側から得た発送情報に基づき、積載が不可であると判断できても、発送拠点側において多少の変更を加えることで積載が可能になる場合がある。このような場合、その発送実績を集中管理部側に提供すれば、集中管理部側における情報精度を向上することが可能になる。
【００２０】
【発明の実施の形態】
以下、本発明の好適な実施の形態（以下、実施形態という）を図面に基づき説明する。
【００２１】
図１は、本実施形態の積載物の発送管理システム（以下、単に管理システムという）１０の構成概念図を示している。本実施形態において、積載物は、組み立てが完成した自動車を例に取り、自動車を組立工場または倉庫等の任意の発送拠点から他の場所に発送する場合を示している。図１に示したように、管理システム１０は、多種形状を有する複数の自動車（積載物）１２をキャリアカー（台車）１４に積載し発送を行う複数の発送拠点１６Ａ，１６Ｂ，１６Ｃ（図１では、３拠点のみを示している）と、各発送拠点１６Ａ，１６Ｂ，１６Ｃ・・・における積載物である自動車１２の積載状態を管理する集中管理部１８と、で構成されている。各発送拠点１６Ａ，１６Ｂ，１６Ｃ・・・と集中管理部１８とは、ネットワークを介して接続されている。
【００２２】
本実施形態の特徴的事項は、各発送拠点で積載物（自動車１２）の形状特徴に基づいてグループ化を行い、そのグループに基づき組み合わせた組合せパターンを使用し、前記集中管理部１８に前記組合せパターンによる台車（キャリアカー１４）の積載可否の問い合わせを行い、集中管理部１８は、予め蓄積した台車に対応した複数の組合せパターンに基づき、各発送拠点からの問い合わせに対応することにより迅速な積載可否判断を容易な情報交換で各発送拠点に行わせるところである。
【００２３】
図１には、集中管理部１８及び発送拠点１６Ａの概略構成が示されている。発送拠点１６Ａにおいて、発送指示待ち積み荷（自動車１２）が存在する場合、発送拠点１６Ａのコンピュータは、その内部機能に、例えば、今回の発送の対象となる自動車１２の選択を行う積載物選択部２０と、選択した自動車１２をグループに分類するグループ変換部（グループ化手段）２２と、前記グループを用いた組合せを作成するパターン形成部（パターン形成手段）２４と、作成した組合せパターンを用いて集中管理部１８に積載の可否に関する問い合わせを行う問い合わせ部（問い合わせ手段）２６と、集中管理部１８からの回答に対する結果評価を行い、積載指示を出すか、再度積載を検討させるかを決める結果評価部２８と、実際にキャリアカー１４に積載指示を出す指示部（指示手段）３０と、を含んでいる。なお、結果評価部２８を省略して、集中管理部１８からの回答を直接積載指示に反映させるようにしてもよい。
【００２４】
また、発送拠点１６Ａのコンピュータは、実際に積載が可能になった場合、その出荷実績（積載実績）を取得する出荷実績取得部３２と、その出荷実績の自動車１２のグループ化を行うグループ変換部２２ａ、前記グループを用いた組合せを作成するパターン形成部（パターン形成手段）２４ａと、作成した組合せパターンを集中管理部１８に提供する実績提供部（実績提供手段）３４と、を含んでいる。なお、グループ変換部２２ａとパターン形成部２４ａは、前記問い合わせ時に使用するグループ変換部２２とパターン形成部２４を利用してもよい。また、このような構成は、各発送拠点１６Ｂ，１６Ｃ・・・にも備えられている。
【００２５】
一方、集中管理部１８は、発送拠点１６Ａのコンピュータからの問い合わせに対し、回答を得るための検索を行うために複数の組合せパターンを蓄積したホストＤＢ（データベース；パターン蓄積手段）３６を有し、検索結果を発送拠点１６Ａのコンピュータの結果評価部２８に返信する。発送拠点１６Ａでは、取得した検索結果に基づき、問い合わせの内容で積載が可能か否かを判断し、可能であれば、指示部３０を介して積載指示を出し、不可能な場合、再度積載物等の検討を行わせる。
【００２６】
以下、図２〜図５に示すフローチャートに基づいて、各発送拠点及び集中管理部１８における処理を詳細に説明する。
【００２７】
図２、図３には、発送拠点１６Ａにおいて、所望の積載物を搭載しようとした場合の処理とそれに対する集中管理部１８の処理を示している。
【００２８】
まず、発送拠点１６Ａのコンピュータの積載物選択部２０は、発送指示待ち積み荷（自動車１２）の中から輸送優先度の高い積み荷（例えば、注文のあった自動車の中で納品日の近いものや輸送時間が長いもの等；車両α、車両β、車両γ）を抽出する（Ｓ１００）。続いて、グループ変換部２２は、抽出した車両α、車両β、車両γ（積載物）を決められたルールに従ってグループに変換する（Ｓ１０２）。ここで、決められたルールとは、例えば、積載物が自動車の場合、自動車の全長や高さが同じものを同一グループにしたり、同じシャシの自動車を同一グループにしたりするルールである。このルールは、各発送拠点と集中管理部１８との間で統一されていれば、任意である。また、長さ等に基づきルールを定める場合、所定の範囲（例えば、±５ｃｍ）を含めてルール決めを行ってもよい。例えば、自動車の全長や高さが同じものを同一グループとしてグループ変換した場合、車両α＝グループ１、車両β＝グループ１、車両γ＝グループ２のようになる（Ｓ１０４）。
【００２９】
さらに、発送拠点１６Ａのパターン形成部２４は、変換したグループに基づき組合せグループを作成する（Ｓ１０６）。上述の場合、（グループ１×２、グループ２×１）という組合せグループＡが作成される。また、パターン形成部２４は、今回使用を予定しているキャリアカー１４の抽出を行う（Ｓ１０８）。この場合、抽出されるキャリアカー１４は、簡略的方法により抽出されるものであり、例えば、現在使用可能なキャリアカー１４が選ばれる。
【００３０】
続いて、問い合わせ部２６は、作成した組合せグループＡ及び積載予定キャリアカー種を集中管理部１８に送信し、両者の組み合わせで積載が可能か否かを問い合わせる（Ｓ１１０）。
【００３１】
一方、集中管理部１８のホストコンピュータ１８ａは、図１に示すように、各発送拠点で作成される組合せパターンと同じルールに従って作成される組合せパターンを所定のキャリアカー１４と関連付けて蓄積したホストＤＢ３６を有している。集中管理部１８ホストコンピュータ１８ａは、発送拠点（例えば、発送拠点１６Ａ）から積載可否の問い合わせ、すなわち組合せグループＡ及び積載予定キャリアカー種を受信した場合（Ｓ２００）、まず、問い合わせの積載予定キャリアカー種と一致するキャリアカーがホストＤＢ３６に存在するか否かの判断を行う（Ｓ２０２）。もし、ホストＤＢ３６に積載予定キャリアカー種と一致するキャリアカーが存在しない場合、集中管理部１８には、積載予定のキャリアカー１４を用いた発送の実績情報が無いと判断して、積載不可フラグをＯＮし（Ｓ２０４）、問い合わせのあった発送拠点（例えば、発送拠点Ａ）に対し、積載フラグ（この場合、不可フラグ）を送信する（Ｓ２０６）。
【００３２】
一方、（Ｓ２０２）で、ホストＤＢ３６に積載予定キャリアカー種と一致するキャリアカーが存在すると判断した場合、ホストＤＢ３６内で、問い合わせのあった組合せパターンＡの検索を開始する（Ｓ２０８）。なお、キャリアカーの一致は、完全一致としてもよいし、種類の一致のみで、多少の改造を含んでも一致とみなすとしてもよい。ただし後者の略一致の場合は、その旨を後述する発送拠点に対する回答送信の時に添付することが望ましい。図２の場合、ホストＤＢ３６の内部は、組合せパターンの特徴毎に分類した複数のブロック（Ｎmax個）に整理され蓄積されている場合を示している。従って、最初は、一番目のブロック（Ｎ＝１）を検索し、発送拠点１６Ａから問い合わせのあった組合せパターンと一致する組合せパターンが存在するか否かの判断を行う（Ｓ２１０）。
【００３３】
ブロックを検索した結果、発送拠点１６Ａから問い合わせのあった組合せパターンと一致する組合せパターンが存在する場合、問い合わせのあったキャリアカーにその組合せパターンで自動車の積載が可能であると判断して、積載可フラグをＯＮし（Ｓ２１２）、問い合わせのあった発送拠点（例えば、発送拠点Ａ）に対し、積載フラグ（この場合、可フラグ）を送信する（Ｓ２０６）。
【００３４】
また、（Ｓ２１０）で検索したブロックの中に一致する組合せパターンが存在しなかった場合、Ｎ＝ｎに置き換え（Ｓ２１４）、Ｎ＝ｎ＋１とし、検索位置の移動を行う（Ｓ２１６）。そして、Ｎ＝Ｎmaxか否かの判断、つまり、ホストＤＢ３６全ての検索を終了したか否かの判断を行う（Ｓ２１８）。Ｎ＝Ｎmaxでない場合は、まだ、ホストＤＢ３６全ての検索が終了していないと判断し、（Ｓ２１０）に戻り、残りの組合せパターンと一致するか否かの検索を行う。また、Ｎ＝Ｎmaxの場合は、ホストＤＢ３６全ての検索を行ったが、集中管理部１８には、積載予定のキャリアカー１４を用いた発送の実績情報が無いと判断して、積載不可フラグをＯＮし（Ｓ２０４）、問い合わせのあった発送拠点（例えば、発送拠点Ａ）に対し、積載フラグ（この場合、不可フラグ）を送信する（Ｓ２０６）。なお、問い合わせのあった組合せパターンを包含する組合せパターンがホストＤＢ３６に存在する場合、つまり、問い合わせのあった組合せパターンＡが（グループ１×２、グループ２×１）でホストＤＢ３６の有する組合せパターンＡ1が同一のキャリアカーを使用して（グループ１×３、グループ２×１）である場合は、それより積載数が少ない組合せパターンは、積載可能と判断することができるので、組合せパターンＡと組合せパターンＡ1が一致すると見なしてもよい。このような場合、ホストＤＢ３６は、あるキャリアカーに積載できるグループの最大パターンを保持すれば十分であり、ホストＤＢ３６における情報蓄積量を削減することができる。
【００３５】
（Ｓ２０６）で、集中管理部１８から積載フラグが送信されると、問い合わせを行った発送拠点（例えば、発送拠点Ａ）は、図３に示すように、ネットワーク通信を介して積載フラグを受信する（Ｓ３００）。積載フラグを受信すると、発送拠点Ａの結果評価部２８は、受信した積載フラグが積載可フラグか積載不可フラグかの判断を行い（Ｓ３０２）、もし、積載可フラグを受信した場合、指示部３０を介して、待機しているキャリアカー１４に対して、所定のタイミングで積載指示を行い（Ｓ３０４）、一連の発送管理処理を終了する。
【００３６】
また、（Ｓ３０２）で積載可フラグでないフラグ、つまり積載不可フラグを受信した場合、結果評価部２８は、集中管理部１８の支援に基づく積載処理を中止するか否かの判断を例えば管理担当者に求める（Ｓ３０６）。積載を中止する場合、一連の発送管理処理を終了する。この場合は、例えば、発送拠点Ａにおいて、従来技術で示したような独自の積載計算を実施する等の非常処理を行う。
【００３７】
一方、集中管理部１８の支援に基づく積載を中止しない場合、結果評価部２８は、図２の（Ｓ１０８）で選択したキャリアカー１４を変更するか否かの判断を例えば管理担当者に求める（Ｓ３０８）。キャリアカー１４を変える場合、つまり、他の種類のキャリアカー１４が使用可能である場合は、図２の（Ｓ１０８）に戻り、キャリアカーの再選択を行い、前述した処理を繰り返し実行する。また、キャリアカー１４の変えない場合、つまり、他の種類のキャリアカー１４が使用不可能である場合（意図的に使用しない場合も含む）は、指示待ちの積み荷の中から他の積み荷を抽出する積み荷の変更抽出を行う（Ｓ３１０）。この変更抽出は、例えば、発送優先順位を下げた抽出を行ったり、抽出数を変更する等により行うことが好ましい。変更抽出後は、図２の（Ｓ１０２）に戻り、グループ化等からやり直し、前述した処理を繰り返し実行する。なお、この場合、（Ｓ１０８）におけるキャリアカーの決定は、前回の結果がそのまま使用される。
【００３８】
このように、発送拠点１６Ａは、積載したい積載物で構成される組合せグループＡを作成すると共に、使用を予定するキャリアカー１４の選択を行い、その情報のみを集中管理部１８に送信し、集中管理部１８は、組合せグループＡとキャリアカー１４のみの組合せをホストＤＢ３６上で検索し、その組合せの可否を判断するため、発送拠点１６Ａと集中管理部１８とで扱う情報量は著しく簡略化され、また、集中管理部１８における検索も迅速に行うことができる。また、各発送拠点１６Ａ，１６Ｂ，１６Ｃ・・・と集中管理部１８とは、多対１の関係にあるため、各発送拠点１６Ａ，１６Ｂ，１６Ｃ・・・は常に集中管理部１８に対して問い合わせを行えばよいので、問い合わせ作業をスムーズに行うことが可能で経済的かつ適切な発送管理を行うことができる。
【００３９】
図４には、集中管理部１８におけるホストＤＢ３６のデータ構築を行うための手順を示すフローチャートが示されている。このデータ構築は、各発送拠点１６Ａ，１６Ｂ，１６Ｃ・・・における出荷実績を使用している。
【００４０】
前述したように、各発送拠点１６Ａ，１６Ｂ，１６Ｃ・・・においては、集中管理部１８の支援により積載物の積載の可否を判断する他、集中管理部１８に対応する発送情報が無い場合、例えば、全く新たなキャリアカー１４を使用する場合や、過去に実績の無い組合せグループでの発送を考慮しなければならない場合等には、従来技術で述べたように自ら積載可否の計算を実行する場合があり、その計算の結果、あるキャリアカー１４に積載が可能な組合せグループが発見される場合がある。このような場合の情報を有効に活用するために、集中管理部１８に対して発送情報を提供する。
【００４１】
図４において、例えば、発送拠点１６Ａにおいて、実際に発送が行われた場合、まず、発送拠点１６Ａのコンピュータの出荷実績取得部３２は、出荷実績（この場合、出荷物個々の情報、例えば、車両α、車両β、車両γ）を取得する（Ｓ４００）。グループ変換部２２ａは、取得した実績車両α、車両β、車両γを決められたルールに従ってグループに変換する（Ｓ４０２）。ここで、決められたルールとは、前述と同様に、例えば、積載物が自動車の場合、自動車の全長や高さが同じものを同一グループにしたり、同じシャシの自動車を同一グループにしたりするルールである。このルールは、各発送拠点と集中管理部１８との間で統一されていれば、任意であるが、先に説明したグループ変換部２２で使用しているルールと同じであることが望ましい。例えば、自動車の全長や高さが同じものを同一グループとしてグループ変換した場合、車両α＝グループ５、車両β＝グループ６、車両γ＝グループ６のようになる（Ｓ４０４）。
【００４２】
さらに、パターン形成部２４ａは、変換したグループに基づき組合せグループを作成する（Ｓ４０６）。上述の場合、（グループ５×１、グループ６×２）という組合せグループＢが作成される。ここまでの処理は、図２で説明した発送を希望する車両を抽出した場合と同じ処理である。さらに、パターン形成部２４ａは、今回使用したキャリアカー種を取得する（Ｓ４０８）。続いて、実績提供部３４は、作成した組合せグループＢ及び使用キャリアカー種を集中管理部１８に送信する（Ｓ４１０）。なお、実績提供部３４は、情報の提供作業を行うのみなので、前記問い合わせ部２６の機能を使用してもよい。
【００４３】
一方、集中管理部１８のホストコンピュータ１８ａは、発送拠点（例えば、発送拠点１６Ａ）から実績情報、すなわち組合せグループＢ及び使用キャリアカー種を受信した場合（Ｓ５００）、まず、使用されたキャリアカー種と一致するキャリアカーがホストＤＢ３６に存在するか否かの判断を行う（Ｓ５０２）。もし、ホストＤＢ３６に使用キャリアカー種と一致するキャリアカーが存在しない場合、集中管理部１８にとって、全く新たな発送情報であると判断して、そのキャリアカーの情報をホストＤＢ３６に追加すると共に（Ｓ５０４）、受信した組合せパターンＢをキャリアカーに関連付けてホストＤＢ３６に追加登録し（Ｓ５０６）、データ蓄積処理を終了する。
【００４４】
（Ｓ５０２）で使用されたキャリアカー種と一致するキャリアカーがホストＤＢ３６に存在すると判断した場合、受信した組合せパターンＢと一致する組合せパターンがホストＤＢ３６内に存在するか否か検索を開始し（Ｓ５０８）、受信した組合せパターンＢがホストＤＢ３６に登録されているか否かの判断を行う（Ｓ５１０）。受信した組合せパターンＢがホストＤＢ３６に登録されていない場合、組合せパターンＢをキャリアカーに関連付けて新たにホストＤＢ３６に登録し（Ｓ５１２）、次回から、各発送拠点からの積載可否の問い合わせに利用する。一方、受信した組合せパターンＢがホストＤＢ３６に既に登録されている場合、受信した組合せパターンＢに関する情報は破棄して（Ｓ５１４）、データ蓄積処理を終了する。
【００４５】
このように、各発送拠点からの実績情報を順次蓄積していくことにより、ホストＤＢ３６の構築を効率よく行うことができる。なお、各発送拠点から送られてくる実績情報はレアケースの情報も多く含まれているので、ホストＤＢ３６においては、蓄積した情報の活用率（問い合わせに対する一致頻度）に応じて、優先順位を付け、図２の（Ｓ２０８）以降の検索において、一致頻度の高い情報から順に検索を実行するようにすることが好ましい。つまり、ホストＤＢ３６内部における分類の特徴として一致頻度を採用し、一致頻度の高い情報が先行して検索されるブロックに含まれるように整理することが望ましい。
【００４６】
ところで、集中管理部１８は、新たに市場に出回る新規積載物に関する情報を予め取得することが可能である。そこで、本実施形態においては、新規積載物に対して予め仮想的な組合せパターンを集中管理部１８で形成し、ホストＤＢ３６に蓄積している。図５には、仮想組合せパターンの形成手順を示すフローチャートが示されている。
【００４７】
まず、集中管理部１８のホストコンピュータ１８ａに上位コンピュータ（例えば、生産計画コンピュータ等）から新規積載物に関する情報を入力する（Ｓ６００）。ホストコンピュータ１８ａの新規グループ変換部（新規グループ化手段：機能的には、各発送拠点の有するグループ変換部２２と同じ）は、入力された新規積載物の情報、すなわち新規車両α、新規車両β、新規車両γを決められたルールに従ってグループに変換する（Ｓ６０２）。ここで、決められたルールとは、例えば、積載物が自動車の場合、自動車の全長や高さが同じものを同一グループにしたり、同じシャシの自動車を同一グループにしたりするルールである。
【００４８】
さらに、ホストコンピュータ１８ａの仮想パターン形成部（仮想パターン形成手段：機能的には、各発送拠点の有するパターン形成部２４と同じ）は、積載許可キャリアカーの指定を行う（Ｓ６０４）。この場合、各発送拠点において、頻繁に使用されるキャリアカーを指定することが望ましい。さらに、仮想パターン形成部は、（Ｓ６０２）で作成したグループが新規グループであるか否かを判断する（Ｓ６０６）。例えば、自動車の全長や高さ等によりグループ化を行う場合、過去に使用しているグループと重複する場合がある。新規グループでない場合、すなわち、重複するグループが存在する場合、新規積載物である新規車両は、過去に使用しているグループに含み、そのグループで処理が可能なので、各発送拠点に対し、新規積載物と、その新規積載物が使用するグループ番号を送信し、以降、前記新規積載物の発送を希望する場合は、指定された既存のグループ番号を使用するように指示する情報を送信し（Ｓ６０８）、新規積載物に対する処理を終了する。
【００４９】
一方、（Ｓ６０６）において、（Ｓ６０２）で作成したグループが新規グループであると判断した場合、ホストコンピュータ１８ａの仮想パターン形成部は、（Ｓ６０４）で指定したキャリアカーに積載可能な仮想組合せパターンの作成を開始する（Ｓ６１０）。ここで、作成する仮想組合せパターンは、例えば、頻繁に使用されるグループとの組み合わせであり、指定されたキャリアカーに対し新規グループを核として作成する。例えば、（新規グループ×３、既存グループ１）とか、（新規グループ×２、既存グループ２）とか、（新規グループ×１、既存グループ３）等の組み合わせや、別途指定されたキャリアカーに対し同様に組み合わせられたものであり、担当者が任意に作成パターンを選択できるようにしておくことが望ましい。そして、所定の仮想組合せパターンが完成したら（Ｓ６１２）、仮想組合せパターンを新規組合せグループとして、ホストＤＢ３６に登録して（Ｓ６１４）、新規積載物に対する処理を終了する。
【００５０】
このように、各発送拠点における発送実績は無いが、近い将来確実に発送が行われる新規積載物に対し予め仮想組合せパターンを作成しておくことにより、実際に各発送拠点から新規積載物を含む積載可否の問い合わせがあった場合に、迅速にその回答を出すことが可能になり、効率的な発送管理を行うことができる。
【００５１】
なお、本実施形態において、積載物は自動車である場合を例にとって説明したが、積載物は任意であり、部品や梱包品でも同様の効果を得ることができる。また、各発送拠点や集中管理部の構成も任意であり、発送拠点対集中管理部の関係が多対１であり、両者が組合せグループの形態で情報の送受を行い、キャリアカーに対する積載の可否を判断する構成であれば、各発送拠点や集中管理部の構成を適宜変更しても本実施形態と同様な効果を得ることができる。
【００５２】
【発明の効果】
本発明によれば、各発送拠点は、所望する積載物の組合せパターンを作り、その組合せパターンによる積載の可否を集中管理部に問い合わせるのみでよいので、各発送拠点において、問い合わせ先は一つであり、かつ複雑な発送計算を行う必要がなくなり、効率的な発送管理を行うことができる。また、情報の交換を組合せパターンの状態で行うので、集中管理部における情報の蓄積量の削減や検索速度の向上、相互の情報交換速度の向上を容易に行うことが可能になり、発送管理を効率的に行うことができる。
【図面の簡単な説明】
【図１】  本発明の実施形態に係る発送管理システムの構成概念図である。
【図２】  本発明の実施形態に係る発送管理システムにおける発送拠点及び集中管理部における処理を説明するフローチャートであり、発送拠点からの問い合わせに関する処理を説明するフローチャートである。
【図３】  本発明の実施形態に係る発送管理システムにおける発送拠点及び集中管理部における処理を説明するフローチャートであり、発送拠点からの問い合わせに関する処理を説明するフローチャートである。
【図４】  本発明の実施形態に係る発送管理システムにおける発送拠点及び集中管理部における処理を説明するフローチャートであり、発送拠点からの発送実績に基づいて集中管理部のデータ構築を説明するフローチャートである。
【図５】  本発明の実施形態に係る発送管理システムにおける集中管理部における処理を説明するフローチャートであり、新規積載物に基づく集中管理部のデータ構築を説明するフローチャートである。
【符号の説明】
１０  発送管理システム、１２  自動車（積載物）、１４  キャリアカー（台車）、１６Ａ，１６Ｂ，１６Ｃ  発送拠点、１８  集中管理部、１８ａ  ホストコンピュータ、２０  積載物選択部、２２，２２ａ  グループ変換部、２４，２４ａ  パターン形成部、２６  問い合わせ部、２８  結果評価部、３０  指示部、３２  出荷実績取得部、３４  実績提供部、３６  ホストＤＢ。
【図１】
0003933859.tif 000002
【図２】
0003933859.tif 000003
【図３】
0003933859.tif 000004
【図４】
0003933859.tif 000005
【図５】
0003933859.tif 000006