(57)【特許請求の範囲】
【請求項１】
識別情報を格納した記憶媒体が付され、ユーザサイドと供給サイド間を循環するユニットを用いたリユース製品の流通管理システムであって、
製品情報、顧客情報およびユニットの情報を格納したデータベースを有するサーバと、表示手段およびユニットの識別情報読取手段を有する回収クライアントと、表示手段およびユニットの識別情報読取手段を有する出荷クライアントと、を備え、
回収クライアントがユニットの回収時にユニットの識別情報をサーバに送信し、サーバが回収クライアントからの送信データに基づき、供給サイドにおける製品の合計数量、およびユーザサイドにおける製品の合計数量を算出し、データベースを更新するステップと、
出荷クライアントがユニットの出荷時に顧客情報およびユニットの識別情報をサーバに送信し、サーバが出荷クライアントからの送信データに基づき、ユーザサイドにおける製品の合計数量を算出し、データベースを更新するステップと、を有し、
回収クライアントおよび出荷クライアントは、サーバからの送信データに基づき、ユーザサイドおよび供給サイドにおける製品の合計数量並びに製品の総数量を出力可能であることを特徴とするリユース製品の流通管理システム。
【請求項２】
識別情報を格納した記憶媒体が付され、ユーザサイドと供給サイド間を循環するユニットを用いたリユース製品の生産管理システムであって、
製品情報、顧客情報およびユニットの情報を格納したデータベースを有するサーバと、表示手段およびユニットの識別情報読取手段を有する回収クライアントと、表示手段およびユニットの識別情報読取手段を有する生産クライアントと、表示手段およびユニットの識別情報読取手段を有する出荷クライアントと、を備え、
回収クライアントがユニットの回収時にユニットの識別情報をサーバに送信し、サーバが回収クライアントからの送信データに基づき、供給サイドにおける製品の合計数量、およびユーザサイドにおける製品の合計数量を算出し、データベースを更新するステップと、
生産クライアントがユニットの倉庫移送時にユニットの識別情報をサーバに送信し、サーバが生産クライアントからの送信データに基づき、供給サイドにおける製品の合計数量を算出し、データベースを更新するステップと、
出荷クライアントがユニットの出荷時に顧客情報およびユニットの識別情報をサーバに送信し、サーバが出荷クライアントからの送信データに基づき、ユーザサイドにおける製品の合計数量を算出し、データベースを更新するステップと、を有し、
回収クライアント、生産クライアント、および出荷クライアントは、サーバからの送信データに基づき、ユーザサイドおよび供給サイドにおける製品の合計数量並びに製品の総数量を出力可能であることを特徴とするリユース製品の生産管理システム。
【請求項３】
サイクル（ｎ）で回収クライアントがユニットの回収時に送信したユニットの識別情報に基づき、サイクル（ｎ＋１）で回収予定の製品数（Ａ）を算出し、データベースを更新する第１ステップと、
サイクル（ｎ＋１）で生産クライアントがユニットの倉庫移送時に送信したユニットの識別情報に基づき、生産された製品数（Ｂ）を算出し、該生産された製品数（Ｂ）と第１ステップで算出した製品数（Ａ）とから製品の総数量の増減を算出し、データベースを更新する第２ステップと、を有することを特徴とする請求項２に記載のリユース製品の生産管理システム。
【請求項４】
上記の各クライアントは、サーバからの受信データに基づき、ユーザサイドの在庫数、ユーザサイドの使用中の製品数、供給サイドの生産中の製品数、供給サイドの在庫数、および次のサイクルで回収予定の製品数を出力可能であることを特徴とする請求項１、２または３に記載のリユース製品の流通管理システム。
【請求項５】
上記の各クライアントは、上記のリユース製品は、複数アイテムからなり、上記の各クライアントは、サーバからの受信データに基づき、リユース製品のアイテム単位で、ユーザサイドの在庫数、ユーザサイドの使用中の製品数、供給サイドの生産中の製品数、供給サイドの在庫数、および次のサイクルで回収予定の製品数を出力可能であることを特徴とする請求項４に記載のリユース製品の流通管理システム。
【請求項６】
上記の各クライアントは、サーバからの受信データに基づき、指定日における、ユーザサイドの在庫数、ユーザサイドの使用中の製品数、供給サイドの生産中の製品数、および供給サイドの在庫数を出力可能であることを特徴とする請求項４または５に記載のリユース製品の流通管理システム。
【請求項７】
前記データベースに前記識別情報と生産時ないしは出荷時からの使用期限情報とが紐付けて格納されること、および／または、その格納する情報を前記記憶媒体に書き換え可能に表示できることを特徴とする請求項１ないし６のいずれか一項に記載のリユース製品の流通管理システム。
【請求項８】
前記リユース製品が、リネン類であることを特徴とする請求項１ないし７のいずれか一項に記載のリユース製品の流通管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リユース製品の流通管理システムに関し、例えば、リネンサプライ業におけるリネン類のアイテム毎の所在地別数量管理が可能な流通管理システムに関する。
なお、本明細書におけるリネン類とは、シーツ、包布、テーブルクロス、タオル、おしぼり、おしめ、浴衣、病衣、制服など、洗濯（ドライクリーニング含む）をして再利用が可能な一切の布製品をいう。
【背景技術】
【０００２】
従来、リネンサプライ業においては、製品の在庫管理は適切に行われておらず、大まかな数量の管理と製品を顧客サイドに輸送するドライバーの経験に基づき運用が行われているのが実情であった。リネン類は消耗品であり、その性質上顧客サイドでの紛失・破棄が行われることが当然の前提となるため、在庫管理を適切に行うことは困難であった。
近年、情報産業の発展に伴い、製品にＩＣやチップ等のタグを付することにより、製品を１点１点管理することにより、在庫管理を適切に行うことが試みられている。
【０００３】
例えば、特許文献１には、レンタル用衣類に付され、データを読書き可能なデータタグと、前記レンタル用衣類が修理されたときは、前記データタグに衣類の修理履歴を書込む書込手段と、前記レンタル用衣類の品質或いは耐久性の向上を図るときは、前記データタグから衣類の修理履歴を読出す読出手段とを備えたことを特徴とするレンタル用衣類管理システムが開示される。
【０００４】
また、特許文献２には、共通コードと連番コードのビットパターンが刺繍され該連番コードが互いに異なる複数の刺繍チップを、複数のクリーニング品にそれぞれ取り付け、該刺繍チップに基づいて該クリーニング品を管理するクリーニング管理システムであって、前記共通コードを顧客情報に対応付ける対応関係と、前記連番コードをクリーニング品の識別情報に対応付ける対応関係とをそれぞれ記憶する記憶手段と、前記クリーニング品のクリーニング後の工程において該クリーニング品の前記刺繍チップのビットパターンが示す共通コードと連番コードを読み取る読み取り手段と、該読み取り手段で読み取った共通コードと連番コードにそれぞれ対応する顧客情報と識別情報とを前記記憶手段から読み出し、該読み出した顧客情報および識別情報を記載した情報付加物を形成する情報付加物形成手段と、を備えたことを特徴とするクリーニング管理システムが開示される。
【特許文献１】特開２００１−２６１１１７号公報
【特許文献２】特開２００１−１０９８１９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来は、顧客サイド（ユーザサイド）のリネン室の在庫状況を管理することで、顧客サイドにおける製品の不足が生じないようにしていたが、顧客サイドにおける製品の数量は、工場サイド（供給サイド）では把握することができず、必要最低限な量を大幅に上回る在庫をストックする必要があった。しかし、顧客サイドに管理システムを導入し、顧客に管理作業を依頼するのは現実的ではない。現状では、顧客サイドに出向き、人手により棚卸作業を行うことで、在庫の調整を行っている。
【０００６】
一方、特許文献１および２に開示されるように、リネン類の１点１点にＩＣ等のタグを付することは導入コストが高く、また運用負荷も高いという課題があった。特に、タオルやおしぼりなどは、紛失を防ぐことは困難であるが、紛失を前提とすると管理コストは一層高いものとなる。
【０００７】
また、リネンサプライ業においては、使用回数で交換するのではなく、洗浄不能な汚れが付いた場合や、危険物が付着した場合には、顧客サイドにおいて廃棄が行われるため、リネン類の総量を正確に把握することはできないという、業界特有の課題がある。
また、複数の設備（各設備が離れている場合もある）で並行して生産が行われている場合には、出荷数と回収数を管理するのは困難であった。
【０００８】
本発明は、リネン類などのリユース製品にＩＣタグ等を付すことなく、顧客サイドに流通しているリネン類の数量を管理することができる流通管理システムを提供することを課題とする。
【課題を解決するための手段】
【０００９】
第１の発明は、識別情報を格納した記憶媒体が付され、ユーザサイドと供給サイド間を循環するユニットを用いたリユース製品の流通管理システムであって、製品情報、顧客情報およびユニットの情報を格納したデータベースを有するサーバと、表示手段およびユニットの識別情報読取手段を有する回収クライアントと、表示手段およびユニットの識別情報読取手段を有する出荷クライアントと、を備え、回収クライアントがユニットの回収時にユニットの識別情報をサーバに送信し、サーバが回収クライアントからの送信データに基づき、供給サイドにおける製品の合計数量、およびユーザサイドにおける製品の合計数量を算出し、データベースを更新するステップと、出荷クライアントがユニットの出荷時に顧客情報およびユニットの識別情報をサーバに送信し、サーバが出荷クライアントからの送信データに基づき、ユーザサイドにおける製品の合計数量を算出し、データベースを更新するステップと、を有し、回収クライアントおよび出荷クライアントは、サーバからの送信データに基づき、ユーザサイドおよび供給サイドにおける製品の合計数量並びに製品の総数量を出力可能であることを特徴とするリユース製品の流通管理システムである。
第２の発明は、識別情報を格納した記憶媒体が付され、ユーザサイドと供給サイド間を循環するユニットを用いたリユース製品の生産管理システムであって、製品情報、顧客情報およびユニットの情報を格納したデータベースを有するサーバと、表示手段およびユニットの識別情報読取手段を有する回収クライアントと、表示手段およびユニットの識別情報読取手段を有する生産クライアントと、表示手段およびユニットの識別情報読取手段を有する出荷クライアントと、を備え、回収クライアントがユニットの回収時にユニットの識別情報をサーバに送信し、サーバが回収クライアントからの送信データに基づき、供給サイドにおける製品の合計数量、およびユーザサイドにおける製品の合計数量を算出し、データベースを更新するステップと、生産クライアントがユニットの倉庫移送時にユニットの識別情報をサーバに送信し、サーバが生産クライアントからの送信データに基づき、供給サイドにおける製品の合計数量を算出し、データベースを更新するステップと、出荷クライアントがユニットの出荷時に顧客情報およびユニットの識別情報をサーバに送信し、サーバが出荷クライアントからの送信データに基づき、ユーザサイドにおける製品の合計数量を算出し、データベースを更新するステップと、を有し、回収クライアント、生産クライアント、および出荷クライアントは、サーバからの送信データに基づき、ユーザサイドおよび供給サイドにおける製品の合計数量並びに製品の総数量を出力可能であることを特徴とするリユース製品の生産管理システムである。
第３の発明は、第２の発明において、サイクル（ｎ）で回収クライアントがユニットの回収時に送信したユニットの識別情報に基づき、サイクル（ｎ＋１）で回収予定の製品数（Ａ）を算出し、データベースを更新する第１ステップと、サイクル（ｎ＋１）で生産クライアントがユニットの倉庫移送時に送信したユニットの識別情報に基づき、生産された製品数（Ｂ）を算出し、該生産された製品数（Ｂ）と第１ステップで算出した製品数（Ａ）とから製品の総数量の増減を算出し、データベースを更新する第２ステップと、を有することを特徴とする。
第４の発明は、第１、２または３の発明において、上記の各クライアントは、サーバからの受信データに基づき、ユーザサイドの在庫数、ユーザサイドの使用中の製品数、供給サイドの生産中の製品数、供給サイドの在庫数、および次のサイクルで回収予定の製品数を出力可能であることを特徴とする。
第５の発明は、第４の発明において、上記の各クライアントは、上記のリユース製品は、複数アイテムからなり、上記の各クライアントは、サーバからの受信データに基づき、リユース製品のアイテム単位で、ユーザサイドの在庫数、ユーザサイドの使用中の製品数、供給サイドの生産中の製品数、供給サイドの在庫数、および次のサイクルで回収予定の製品数を出力可能であることを特徴とする。
第６の発明は、第４または５の発明において、上記の各クライアントは、サーバからの受信データに基づき、指定日における、ユーザサイドの在庫数、ユーザサイドの使用中の製品数、供給サイドの生産中の製品数、および供給サイドの在庫数を出力可能であることを特徴とする。
第７の発明は、第１ないし６のいずれかの発明において、前記データベースに前記識別情報と生産時ないしは出荷時からの使用期限情報とが紐付けて格納されること、および／または、その格納する情報を前記記憶媒体に書き換え可能に表示できることを特徴とする。
第８の発明は、第１ないし７のいずれかの発明において、前記リユース製品が、リネン類であることを特徴とする。
【００１０】
なお、上記のサーバとクライアントは、リユース製品の生産管理システムにおける機能分担を意味するものであり、各機能を別筐体の装置で実現することは必要ではなく、同一筐体の装置で複数の機能を実現できることは言うまでもない。
【発明の効果】
【００１１】
本発明によれば、リネン類などのリユース製品にＩＣタグ等を付すことなく、顧客サイドに流通しているリユース製品の数量を管理することができる流通管理システムを提供することが可能となる。すなわち、導入容易性に優れ、運用負荷の低いリユース製品の流通管理システムを提供することが可能となる。
【発明を実施するための最良の形態】
【００１２】
本発明を実施するための最良の形態を、客室で製品が使用される業務の例で説明する。以下では、製品７と使用済品８を総称してリネン類という場合がある。
図１は、本発明のシステムの業務プロセスを示す概要図である。システム化の対象となる業務では、工場サイドで生産された製品７が顧客サイドに出荷され、客室２２で使用された使用済品８が回収され、再び製品７として出荷されるというサイクルを繰り返している。かよい箱６の所在場所（滞在する場所）は５箇所であるが、製品７が所在場所（滞在する場所）は６箇所であるため、これらのサイクルは常に１つずれることとなる。
工場サイドには清算設備３と倉庫５がある。生産設備３は、使用済品８を回収し、洗濯し、乾燥し、折り畳んで製品７とする。製品７はかよい箱６に詰められ、倉庫３にストックされる。所定数のかよい箱６が、トラック等の輸送車９により工場サイドから顧客サイドへ配送される。
【００１３】
顧客サイドにはリネン室２１と客室２２がある。工場サイドから出荷された所定数のかよい箱６は、リネン室２１に在庫として置かれる。顧客サイドでは、需要に応じて、製品７を客室２２で利用する。
輸送車９のドライバーは、所定数のかよい箱６の出荷時に、顧客サイドに空のかよい箱６および使用済品８を回収する。回収された使用済品８は、生産設備３で再度洗濯工程、乾燥工程、折り畳み工程を経て再び製品７として倉庫５にストックされる。
なお、倉庫５にストックする際には、かよい箱６に入れてもよいし、棚等にストックしてもよい。
【００１４】
本発明の流通管理システムは、かよい箱６を管理することにより、リネン類の数量を管理することが特徴的である。リネン類の１点１点をデータタグ等で管理することも考えられるが、コストが高く現実的でないため、かよい箱６を管理単位とした。かよい箱６の中身は、各々異なり、リネン類の種類のみならず、数量も異なる場合がある。他品種が同時に管理される場合もあり、例えば、浴衣１０枚、帯１０枚が一つの管理単位（ユニット）とされる。
本発明のかよい箱６は、物理的なかよい箱に限定されず、出荷および回収がなされる一つの管理単位（ユニット）示すものであればよい。すなわち、「ユニット」は箱の形状をしていなくてもよく、例えば、シーツ１０枚或いはタオル２０枚を紐で束ね、紐に記憶媒体（例えば、コード付きのプレート）を付したものを「ユニット」としてもよい。
かよい箱６には、一意のＩＤが付されており、かよい箱６の状態はサーバ１により管理される。かよい箱６には、バーコードやＩＣタグ等の記憶媒体が付けられ、バーコードリーダ等の読取手段によりＩＤを認識可能とされる。格納情報を目視できるように、使用期限や顧客名、品名などを表示できる書き換え可能なラベル（リライトカード）を付けたものでもよい。倉庫５からの出荷時には、一意に付けられた顧客ＩＤと関連付けが行われる。なお、顧客専用品の場合、生産時に顧客情報が付加されることもある。
【００１５】
顧客サイドへの移送が毎日行われる場合には、必要最小限の製品総量は客室利用分の３倍程度となる。１つの単位数量がリネン室在庫ととなり、１つの単位数量が客室利用分となり、１つの単位数量が生産分となる。通常は安全を見越して客室利用分の３倍以上の製品を保持する。
製品によっては、交換サイクルが週１回程度のものもある（例えば、テーブルクロス）。製品の種別によって、回収頻度および製品総量は適切に決定される。
【００１６】
ところで、顧客サイドに供給する製品は、大別すると、共通品と専用品に分類される。共通品とは、複数の顧客で利用される製品で、例えば、おしぼりやタオルである。専用品とは、特定の顧客でのみ利用される製品で、例えば、テーブルクロスや制服である。共通品の場合、リネン室における在庫数量が重要となり、専用品の場合、製品総量の把握が重要となる。
【００１７】
図２は、本発明のシステムの構成を示す概要図である。工場サイドには、サーバ１が設置され、リネン類の種類・数量、工場サイド情報、顧客サイド情報などの各種データが格納されている。サーバ１は、回収端末１１、生産端末１２および出荷端末１３とネットワークにより接続されている。
回収端末１１は、生産設備３に回収されたかよい箱６の数量を管理する。回収されたかよい箱６に登録されていた製品の数量を、次のサイクルで回収される使用済品８の数量（概算入荷数）とする。これにより次のサイクルにおける概算入荷数を把握することが可能となる。
生産端末１２は、生産設備３から倉庫５に移送される製品７の数量およびその中に格納された製品７の種類や数量などのデータを管理する。また、生産端末１２は、客先、品種、数量などの情報が記載された伝票（電子的伝票の場合もある）を発行する。
出荷端末１３は、工場サイドから顧客サイドへ配送されるかよい箱６の数量およびその中に格納された製品７のデータを管理する。
なお、生産端末１２は必須の構成ではなく、回収端末１１があれば本システムは稼働可能である。生産端末１２を設けない場合には、出荷端末により伝票を発行する。
【００１８】
本発明のシステムは、リネン類の廃棄・紛失が生じることを前提としている。顧客サイドでは、例えば、宿泊客が持ち帰ったり、洗濯しても落ちないほど汚れた場合に廃棄されることが想定される。工場サイドでは、例えば、生産の際にリネン類に一定以上の汚れや破れが見つかった場合に廃棄されることが想定される。本発明のシステムによれば、概算入荷数と生産数の差異をみることで、顧客サイドでの紛失状況の概要を把握することができる。顧客サイドでの製品紛失は、顧客サイドでの在庫の不足に直結するものであるので、製品紛失状況を把握したいとのニーズは高い。
管理単位（ユニット）をかよい箱の単位とすれば、誤差の上限をかよい箱の単位とすることができる。例えば、かよい箱に２０枚のタオルが収納されているとすれば、顧客サイドにおけるタオルの数量を±２０枚の精度で把握することが可能である。把握精度をかよい箱の収納量以内にするためには、複数のかよい箱内に収納された製品を、並行に利用することは避けなくてはならない。製品が入った開放中のかよい箱は常に１つとする必要がある。好ましくは、かよい箱を先入れ先出し（ＦＩＦＯ）で管理する。なお、品質管理の観点から、洗濯時ないしは出荷時より使用期限を設け、ＦＩＦＯを促すようにしてもよい。
【００１９】
顧客サイドに製品７を納品した際に、空のかよい箱６を回収する。空のかよい箱６の数量×収納量（管理数量）が、現在客室で利用されている製品６の最大数量である。顧客サイドの業種にもよるが、訪問サイクルが一定の場合には、回収したかよい箱６の数量×収納量が次のサイクルの訪問時に回収する使用済品８の概算値（理論上の最大値）である。
なお、顧客サイドで使用済品８の数量を数えてもらうことは、通常不可能であること、工場サイドでも衛生上などの理由から数量を数えることは難しいことから、次のサイクルでの回収量を予測することは大切である。
【００２０】
客室２２での利用状況によっては、次のサイクルで回収する使用済品８の数量と予測数量が一致しないことも想定される。しかし、この場合においても、リネン室２１における在庫数で調整がなされるのであり、リネン室２１の在庫数を一定の範囲の数量に保つことは可能である。
リネン室２１の在庫数が足りなくなることは、顧客サイドにとって致命的である一方、過剰な在庫を抱えることは品質面の観点からも好ましくない。リネンサプライ業においては、リネン室２１の在庫数を所定の範囲に管理しながら、リネン類を順次回転させることが大切であるが、本発明によればそれが実現可能である。
【００２１】
本発明のシステムにおけるリネン類の運用サイクルを、図３ないし図９を参照しながら、具体例で説明する。
図３に示すように、最初は全ての製品（総量７００点）が工場サイドの倉庫に格納された状態にある。倉庫内の四角囲みは製品が収容されたかよい箱（データの管理単位）であり、二重線で囲んだものは複数のかよい箱を示している。リネン室の在庫基準数は２００であり、１つのかよい箱は５０点の製品を収容可能であることとする。
【００２２】
図４は、倉庫から、リネン室在庫数２００点分の製品が収容されたかよい箱がリネン室に移送された状態である。かよい箱の出荷時に倉庫に設置された出荷端末が、倉庫の在庫データから２００点減算し、かよい箱のＩＤと関連付けられた一のリネン室の在庫データに２００点加算する。
【００２３】
図５は、運用開始時点から１回目の配送が行われた状態を示している。在庫基準数の２００点がリネン室にあるため、１回目の配送において納品は行われない。客室利用相当分（１００点分）の空のかよい箱が回収され、輸送車により生産設備に移送される。生産設備では、回収端末がかよい箱に付されたＩＤを読み取ることで、次回１００点の使用済品が回収されることが予想される。
システムが把握する顧客サイドの情報は、リネン庫に１００点、客室利用分（仕掛かり）に１００点、顧客サイド合計数２００点である。
【００２４】
図６は、運用開始時点から２回目の配送が行われた状態を示している。
一つ前のサイクル（図５）における仕掛かりが１００点であることから、倉庫から１００点の製品が輸送車によりリネン室に移送される。顧客サイドでは、客室利用相当分（５０点分）の空のかよい箱が回収され、輸送車により生産設備に移送される。また、１００点分の使用済品が回収され、輸送車により生産設備に移送される。
最初に回収された１００点分の製品を収容可能な空のかよい箱は、プールされた状態にあり、再利用可能な空のかよい箱として管理される。
システムが把握する顧客サイドの情報は、リネン庫に１５０点、客室利用分（仕掛かり）に５０点、顧客サイド合計数２００点である。
【００２５】
図７は、運用開始時点から３回目の配送が行われた状態を示している。
一つ前のサイクル（図６）における仕掛かりが５０点であることから、倉庫から５０点の製品が輸送車によりリネン室に移送される。顧客サイドでは、客室利用相当分（１００点分）の空のかよい箱が回収され、輸送車により生産設備に移送される。また、５０点分の使用済品が回収され、輸送車により生産設備に移送される。
生産設備で生産された１００点分の製品は、プールされたかよい箱に格納されて倉庫に移送され、この際、生産端末により顧客、品種、数量などの情報が登録される。
５０点分の製品を収容可能な空のかよい箱は、プールされた状態にあり、再利用可能な空のかよい箱として管理される。
システムが把握する顧客サイドの情報は、リネン庫に１００点、客室利用分（仕掛かり）に１００点、顧客サイド合計数２００点である。
なお、上記で生産された製品が１００点に満たない場合には、紛失があったものとして記録する。実際には製品が紛失したわけではなく、次回のサイクルで計上される場合もあるので瞬間的な製品の総数量を正確に把握することはできないが、数サイクルにわたる増減を見れば、製品の総数量の変化の傾向を把握することが可能である。
【００２６】
以上に示すように、本発明のシステムは、リネン室から回収される空のかよい箱の管理数量（収容量）を把握することで、次回に回収される使用済品の量を予測可能とし、顧客サイドおよび工場サイドにおけるリネン類の流通管理を適時把握することを実現している。なお、リネン類が複数アイテム（例えば、タオル、シーツ、浴衣等）からなる場合には、アイテム毎に、所在場所毎のリユース製品の総数量および／またはかよい箱の総管理数量を出力可能とすることが好ましい。
【００２７】
以下では、本発明の詳細を実施例により説明するが、本発明は何ら実施例に限定されるものではない。
【実施例】
【００２８】
本実施例のシステムは、図２に示す如く構成され、工場サイドには、サーバ１、回収端末１１、生産端末１２および出荷端末１３がネットワークに接続されて配設されている。サーバ１は、リネン類の種類・数量、工場サイド情報、顧客サイド情報などの各種データが格納されている。回収端末１１、生産端末１２および出荷端末１３は、専用のソフトウェアが導入されたパーソナルコンピュータであり、かよい箱に付されたバーコードを読み取るための、バーコードリーダが接続されている。
かよい箱６には、一のＩＤが付けられており、かよい箱６の外面に付されたバーコード（一意のコード）を読み取ることで、ＩＤを認識することが可能である。サーバ１の備えるデータベースには、かよい箱のＩＤと、収納された製品の種別・数量、顧客先ＩＤ、ポジション属性（流通ステータス）などの情報が関連付けして格納されている。
【００２９】
図８は、本実施例のシステムの在庫管理画面の一例である。図８の画面上では、顧客に流通する製品の点数、リネン室にある製品の点数、製品の流通総量などの情報をグラフィカルに把握することが可能である。図８の画面左で日付を指定することにより、当該指定日における製品の流通情報を把握することが可能である。また、画面左のドロップダウンリストを利用することにより、複数の工場から一の工場を選択して在庫管理を行うこと、複数の顧客から一の顧客を選択して在庫管理を行うこと、アイテム（製品種別）を指定して在庫管理を行うことも可能である。
【００３０】
図９は、本実施例のシステムの所在別製品量の一例を示す画面である。生産設備３、倉庫５、リネン室２１および客室２２における製品の分布をグラフィカルに把握することを可能としている。図９の左側に示すグラフでは、上から順番に「生産」、「利用中」、「リネン質」、「倉庫」の数量の割合が示されている。図９の右側に示すグラフは、図９の左側のグラフの上限付近を拡大したものであり、アイテムのトータル数量が逓減していく状態を確認することができる。
生産設備３における数量と客室２２における数量は、空のかよい箱６を回収した際に、回収端末１１が把握したかよい箱６の情報に基づき算出している。すなわち、輸送車９が空のかよい箱６を顧客から回収した際に、回収端末１１が読み取った当該かよい箱６の管理数量（ａ１）を客室２２の数量とし、当該顧客から次の空のかよい箱６が回収された際に、回収端末１１が読み取った当該かよい箱６の管理数量（ａ２）を客室２２の数量とし、前回分の空のかよい箱６の数量（ａ１）を生産設備３の予想数量としている。（実際は生産量において把握される。）
倉庫５における数量は、製品７を倉庫５に移送する際に生産端末１２が把握した製品７の数量に基づき算出している。リネン室２１における数量は、製品７を倉庫５から出荷する際に、出荷端末１３が把握した製品７の数量に基づき算出している。
【００３１】
本実施例のサーバ１の備えるデータベースは、ＳＱＬによるクエリが可能なものであり、各端末からのクエリにより、かよい箱ＩＤに関連付けられたポジション属性が変位する。ポジション属性としては、１をリネン類が倉庫にある状態、２を出荷状態、４をリネン室にある状態、８を客室にある状態、１６を回収状態、３２を生産状態、０をかよい箱に格納した状態と設定することが例示できる。
ポジション１では生産処理された日に開始日が生産日となり、終了日は未定として管理される。ポジション４では出荷時に開始日（当日または次回ルート訪問日）が登録され、終了日は未定として管理される。ポジション８では空き箱回収から回収登録された時点で開始日が設定され、終了日は次回ルート訪問日が設定される。同時にポジション３２が処理され開始日には次回ルート訪問日が設定され、終了日として次次回ルート訪問日が設定される。（これは以降のデータを追う手段がないために空き箱回収時にルート情報を元に流通残存期間としてあらかじめ設定される。）
以上のように管理されたデータに対してポジション属性、日付などで問い合わせすることにより場所と数量を把握することが可能となる。なお、各ポジション中、２重に存在する期間は無いことが前提となる。
因みに、上記の流通管理を手作業によって再現する事も理論上は可能であるが、ルート（曜日指定）の状況が一様でないため、適時に数量計算を管理することは困難であり、事実上は実現不可能である。
【００３２】
従来、リネンサプライ業界においては、一旦流通を止めて納品数の多い顧客を中心に顧客サイドのリネン室の在庫を確認しなくてはならなかった。この点、本実施例のシステムによれば、流通を止めなくとも空のかよい箱６の情報に基づき生産設備３における数量と客室２２における数量を把握することが可能であり、また、顧客サイドと工場サイドの夫々におけるリネン類の数量を把握することができる。
しかも、製品７の１点１点にタグを付する必要が無く、しかも顧客サイドに特別な設備を設ける必要が無いため、導入容易性に優れ、運用負荷も低く、その実用性は極めて高いということができる。
【産業上の利用可能性】
【００３３】
本発明は、単価が安く、且つ、廃棄・紛失を前提としたリユース製品のレンタル業における流通管理に好適である。ビールの瓶、掃除用具、履物、滅菌して再利用される医療器具などのＩＣタグ等付し、現場に管理端末を設置することの見合わないリユース製品を、低コストで管理することが可能となる。
【図面の簡単な説明】
【００３４】
【図１】本発明のシステムの業務プロセスを示す概要図である。
【図２】本発明のシステムの構成を示す概要図である。
【図３】本発明のシステムの運用サイクルの第１サイクルの説明図である。
【図４】本発明のシステムの運用サイクルの第２サイクルの説明図である。
【図５】本発明のシステムの運用サイクルの第３サイクルの説明図である。
【図６】本発明のシステムの運用サイクルの第４サイクルの説明図である。
【図７】本発明のシステムの運用サイクルの第５サイクルの説明図である。
【図８】実施例のシステムの在庫管理画面の一例である。
【図９】実施例のシステムの所在別製品量の一例を示す画面である。
【符号の説明】
【００３５】
１  サーバ
３  生産設備
５  倉庫
６  かよい箱
７  製品
８  使用済品
９  輸送車
１１  回収端末
１２  生産端末
１３  出荷端末
２１  リネン室
２２  客室
【図１】
0005055150.tif 000002
【図２】
0005055150.tif 000003
【図３】
0005055150.tif 000004
【図４】
0005055150.tif 000005
【図５】
0005055150.tif 000006
【図６】
0005055150.tif 000007
【図７】
0005055150.tif 000008
【図８】
0005055150.tif 000009
【図９】
0005055150.tif 000010