JP2005145688A - 原材料供給量管理システムおよびその方法 - Google Patents

Abstract

【課題】 原材料の供給先に対して原材料を出荷する際に、適切な出荷量を設定することを可能とする原材料供給量管理システムおよびその方法を提供することを目的とする。
【解決手段】 管理サーバ１００は、薬液管理ＤＢ１２０に記録されたデータに基づいて在庫量の少ない薬液を抽出する。管理サーバ１００は、各クライアント毎に設定された発注単位分を出荷した場合に、出荷手段（例えばトラック等）の積載量が所定範囲にあるか否かを判断する。積載量が所定範囲内にあると判断した場合には、その積載量にて出荷内容を決定する。積載量が所定範囲の下限を下回ると判断した場合には、当該所定範囲内となるように前記抽出した在庫量の少ない薬液について追加出荷分を調整する。
【選択図】 図３

Description

この発明は、原材料の供給先に対して原材料を出荷する際に、適切な出荷量を設定することを可能とする原材料供給量管理システムおよびその方法に関する。

原材料の供給元（例えば原材料供給メーカ）から供給先（例えば工場）に対して原材料を供給する場合、供給先から要求のあった量の原材料を単に供給するだけでなく、適切なタイミングで適切な量の供給が行われるのが望ましい。例えば、複数の異なる原材料を利用して作業が行われるような分野においては、それら複数の原材料の使用量および在庫量の管理が複雑であるから、原材料の在庫管理や供給スケジュール管理を適切に行うための技術の要求性が高い。

複数の原材料を使用する必要があり、さらにそれらの消耗度が大きく異なることに起因して、使用量や在庫量の管理が複雑となる分野の一例として、めっき作業（例えば、無電解めっき作業）を挙げることができる。無電解めっき作業においては、例えばめっき液、還元剤、錯化剤等の薬液がそれぞれ異なる速度によって消耗し、さらに、めっき作業中にそれらの薬液を補給する工程が必要となるのが一般的である。

従来、めっき作業の分野においては、薬液の補給作業を効率的に実行する目的で、めっき処理槽のめっき濃度やめっき消耗度等を管理し、自動的に当該めっき補給液を補給する自動液管理装置が開発されてきた。この自動液管理装置は、めっき槽中の所定成分の濃度を検知して、当該所定成分の消耗量を算出し、パイプ等を介して補給液タンクからめっき槽に所定量の補給液を供給する機能を有している。

薬液の補給という分野に関しては、上記のような自動液管理装置の機能に加えて、例えば薬液の補給時期を報知することによって補給作業に関する作業効率化を達成しようとする技術がある。具体的には、液の消耗量を予測することに関して、薬液槽内の薬液の量に関する薬液量情報と、その薬液量情報に基づいて算出される薬液使用速度とに基づいて、薬液槽への薬液の補給が必要となる薬液補給時期を予測する（例えば、特許文献１参照）。この技術によれば、生産設備担当者の薬液使用量の予測に誤り等に起因する、薬液供給の遅延や、薬液切れを防止することができる点で有用である。

特開２００２−２９３４３２（第５図）。

上記特許文献１の技術においては、さらに、上記薬液補給時期に基づいて、薬液供給メーカ側の端末に薬液手配要求を送信する技術が開示されている。この技術によれば、薬液供給メーカ側においては、薬液を供給する相手となる顧客側によって急な発注がなされるのを未然に防止することができ、その結果、急な発注に対応するための余剰生産力を維持する必要がなくなるというメリットがある。

ここで、薬液供給メーカにとっては、一般的には、供給対象となる薬液が複数存在するか、あるいは顧客が複数存在することが多く、さらに、それら個々の薬液または顧客毎に、薬液の使用量の速度のほか、顧客側で薬液をストックすることのできる許容量（在庫可能範囲）も異なるのが通常である。上記特許文献１においては、複数の顧客における薬液使用量速度および在庫可能範囲の両者を考慮することによって、薬液メーカ側での薬液生産管理を効果的に行う点が考慮されていない。

また、薬液供給メーカ側においては、薬液使用量速度および在庫可能範囲が個々の顧客毎に相違することに起因して、薬液の供給のための輸送コストがかさむという問題点がある。具体的には、薬液使用量速度および在庫可能範囲が個々の顧客毎に相違するから、個々の顧客毎に適切な薬液量を発送しなければならない事態が多く発生する結果、輸送用トラックを数多く抱える必要があるなど、複数の顧客に対して効率的に薬液を発送するという効率的な輸送が実現できない問題点がある。

本発明は、上記のような課題に鑑みて、原材料の供給先に対して原材料を出荷する際に、適切な出荷量を設定することを可能とする原材料供給量管理システムおよびその方法を提供することを目的とする。

１）本発明の原材料供給量管理システムは、
原材料供給量管理装置と、当該原材料供給管理装置と通信可能であって、原材料の供給先における端末装置とを備えた原材料供給量管理システムであって、
前記原材料供給量管理装置は、
供給先における各原材料の在庫可能範囲データを取得する在庫可能範囲データ取得手段、
供給先における各原材料の供給量データを取得する供給量データ取得手段、
供給先における各原材料の使用量データを取得する使用量データ取得手段、
前記供給量データと使用量データとの差分に基づいて実質在庫量を演算する在庫量演算手段、
前記在庫可能範囲と実質在庫量とを参照して追加供給量を判断し、当該追加供給量を供給内容として決定する追加供給量決定手段、
を備えており、
前記端末装置は、
前記原材料供給量管理装置に対して、各原材料の前記使用量データを送信する送信手段、
を備えたことを特徴としている。

これらの特徴により、前記原材料供給量管理装置は、前記供給内容として、前記在庫可能範囲と実質在庫量とに基づいて判断される、適切な量の追加供給量を決定することができる。

４）本発明の前記追加供給量決定手段は、さらに、
前記在庫量演算手段が演算する実質在庫量が前記在庫可能範囲の下限を下回るか否かを判断し、前記在庫可能範囲の下限を下回ると判断された原材料に限定して、前記追加供給量を判断すること、
を特徴としている。

この特徴により、前記原材料供給量管理装置は、前記供給内容として、前記在庫可能範囲の下限を下回る、すなわち、前記原材料の供給先において比較的早急に供給をすることが要求される原材料に限定して追加供給量を決定することができる。

５）本発明の前記原材料供給量管理装置は、さらに、
原材料の供給に利用する輸送手段が輸送可能な輸送可能範囲に関連する輸送可能範囲データを取得する輸送可能範囲データ取得手段、
を備えており、
前記追加供給量決定手段は、さらに、
追加供給の対象となる原材料の前記追加供給量の合計量を演算し、当該合計量が輸送可能範囲の下限を下回っていると判断した場合には、選択された特定原材料について、当該特定原材料の前記在庫可能範囲と実質在庫量とを参照して補充追加供給量を判断するとともに、当該補充追加供給量の追加によって合計量が前記輸送可能範囲内となるか否かを判定し、輸送可能範囲内となる場合には、当該補充追加供給量と前記追加供給量との組み合わせを供給内容として決定すること、
を特徴としている。

これらの特徴により、前記原材料供給量管理装置は、前記補充追加供給量を追加（加算）することによって、前記合計量が前記輸送可能範囲内に収まるような内容を前記供給内容として決定することができる。したがって、例えば前記輸送手段による輸送効率を考慮して前記輸送可能範囲を設定することとすれば、輸送効率の高い輸送スケジュールを決定することができる。

６）本発明の前記原材料供給量管理装置は、さらに、
前記追加供給量決定手段が、前記合計量が輸送可能範囲の上限を上回っていると判断した場合には、前記輸送手段を追加するものとして前記輸送可能範囲データを変更する輸送可能範囲データ変更手段、
を備えたことを特徴としている。

この特徴により、前記原材料供給量管理装置は、前記補充追加供給量を追加することによって前記合計量が前記輸送可能範囲の上限を上回っている場合であっても、前記輸送手段の追加を仮定して前記輸送可能範囲データを変更したうえで、前記合計量が前記輸送可能範囲内に収まるような内容を前記供給内容として決定することができる。

７）本発明の前記原材料供給管理装置は、さらに、
前記使用量データに基づいて演算される各原材料の使用履歴量の比較結果を取得し、当該比較結果に基づいて前記特定原材料を選択する特定原材料選択手段、
を備えたことを特徴としている。

この特徴により、前記原材料供給量管理装置は、前記使用履歴量の比較結果に基づいて前記特定原材料を選択することができる。

８）本発明の前記特定原材料選定手段は、前記使用履歴量が大きい原材料を前記特定原材料として選択すること、
を特徴としている。

この特徴により、前記原材料供給量管理装置は、前記使用履歴量の大きい原材料、すなわち、前記原材料の供給先において、他の原材料の中で比較的速く消費することが予測される原材料について前記補充追加供給量を加算することができる。

１１）本発明の前記端末装置は、さらに、
前記原材料の使用量データを取得するために、前記原材料の使用量を監視する使用量監視手段、
を備えたことを特徴としている。

この特徴により、前記端末装置は、前記原材料の使用量を自動で監視することができる。したがって、前記使用量の監視をするための作業労力を軽減することができる。

以下、用語の定義について説明する。

この発明において、
「在庫可能範囲」とは、原材料の供給先において、その原材料を在庫する量に関連する値の上限、または下限、または上限と下限とによって特定される範囲を含む概念である。在庫量可能範囲は、例えば、原材料の供給先における、原材料を使用する作業規模、または作業スピード、または原材料を保管するための倉庫類の大きさ、または原材料を保管するための予算等に基づいて自由に設定可能である。実施形態では、図８の薬液管理ＤＢ１２０に記録される「必要最低在庫量」または「許容最高在庫量」が、この「在庫可能範囲」の概念に含まれる。

「供給量データ」とは、原材料の供給先において、その原材料が供給された量に関連する情報を含む概念である。供給量は、原材料の供給元が管理する出荷実績、または原材料の供給先が管理する受領実績等に基づいて得ることができる。実施形態では、図８の薬液管理ＤＢ１２０に記録される「在庫量」が、この「供給量データ」の概念に含まれる。

「使用量データ」とは、原材料の供給先において、その原材料が使用された量に関連する情報を含む概念である。使用量データは、現実に使用された量、または所定量の原材料が使用された回数、または原材料が使用された回数をカウントするための情報等が含まれる。実施形態では、図１１ステップＳ１０９において顧客側コンピュータ２００のＣＰＵ２０が送信する分析信号、または図８の薬液管理ＤＢ１２０における「単位補給量」のデータ、または当該分析信号を受信して管理サーバ１００ＣＰＵ１０が記録する「補給回数」または「蓄積補給量」のデータが、この「使用量データ」の概念に含まれる。

「実質在庫量」は、原材料の供給先における実質的な在庫量を含む概念である。実質在庫量は、例えば、原材料が供給された量（供給量）と、当該実質在庫量の判断時までに原材料が現実に使用された量とに基づいて得られる。実施形態では、図１０の出荷量設定テーブル１５０に記録される「正味在庫量」が、この「実質在庫量」の概念に含まれる。

「輸送可能範囲」とは、輸送手段（例えばトラック等）によって原材料を輸送する量に関連する値の上限、または下限、または上限と下限とによって特定される範囲を含む概念である。輸送可能範囲は、例えば、輸送手段の最大積載量、または輸送手段の積載量の適性量、または輸送手段の輸送効率、または輸送手段の輸送コスト等に基づいて自由に設定可能である。実施形態では、図９の出荷用トラック管理ＤＢ１３０に記録される「最大積載量」、または図１３のステップＳ３１５においてＣＰＵ１０が判断基準として利用する「８５％（積載率）」、または「１００％（積載率）」という情報が、この「輸送可能範囲」の概念に含まれる。

本発明の原材料供給量管理システムおよびその方法は、原材料一般に関して、供給元から供給先への出荷量（補給量）を適切な量に設定することができるものである。本発明にかかる「原材料」としては、供給先に対して所定の量を供給可能な、固体物、液体物、気体物等一般が含まれる。

以下の実施形態では、本発明にかかる原材料の一例として「めっき薬液」を例示することにより、本発明の原材料供給量管理システムおよびその方法の実施形態としての「めっき液管理システム」を説明する。このめっき液管理システムは、めっき工場において使用される薬液について、その薬液の供給元から供給先に対する出荷量を適切な量に設定することを可能とするシステムである。より具体的には、めっき槽に補給するめっき補給液等の使用量を監視して、当該使用量に見合った補給液等を効率的に発送・補給するシステムである。

一般に、めっき作業を行う場合（例えば無電解めっき）、その作業に使用される無電解めっき液は、その使用により金属塩、還元剤等がわずかな時間で消耗し、めっき液の液組成の変動が激しい。そのため、頻繁に消耗薬液の補給を行うことにより、めっき被膜の性状等を一定にする必要がある。そのような消耗薬液の補給作業を簡易に行うために、様々なめっき液自動補給装置等が提案されている。

一方、めっき液を補給する側、すなわち、薬液供給メーカ（供給元）では、供給先に対して適切な量の薬液を適切なタイミングで出荷することが重要な課題の一つとなっている。本実施形態では、そのような課題を解決する手段として、上記のめっき液自動補給装置等が処理する情報を利用する。具体的には、実施形態としての「めっき液管理システム」は、めっき液自動補給装置が処理する補給量データや、供給メーカ側が記録する供給量データ等のデータを統合的に管理することによって、適切な供給量（出荷量）等を決定することを一つの特徴としている。

以下、めっき液管理システムの概略、装置のハードウェア構成、特許請求の範囲に記載した用語と実施形態との対応を説明し、次に各実施形態の説明等を行う。

目次
１．めっき液管理システムの概要
２．ハードウェア構成等
３．特許請求の範囲に記載した用語と実施形態との対応
４．実施形態（薬液管理処理プログラム）
５．実施形態（薬液管理データベース更新処理プログラム）
６．第１実施形態 〜最適出荷量設定処理〜
７．第２実施形態 〜最適出荷量設定処理〜
８．実施形態による効果
９．その他の実施形態等
−−−−−−−−−−−−−−−−−−−
−−１．めっき液管理システムの概要−−
１−１．めっき液管理システム
図１は、実施形態による、めっき液管理システムの概略である。めっき液管理システムは、クライアントユニット２０００およびクライアントユニット２０００に含まれる顧客側コンピュータ２００、顧客側コンピュータ２００と専用線３００（接続手段）で接続される管理サーバ１００で構成される。なお、接続手段は、専用線３００に限らず、インターネット、またはＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）、電話回線等のその他の手段を用いてもよい。

管理サーバ１００は、薬液に関する情報等を管理する装置であり、めっき液管理システムのシステム管理者等、具体的には、薬液の供給メーカ側のシステム管理者等が使用する。一方、顧客側コンピュータ２００は、めっき工場等を有する、薬液の供給先の担当者（購買部、または生産管理部の担当者等）が使用する。

管理サーバ１００は、クライアント管理データベース（以下、「ＤＢ」とする）１１０、薬液管理ＤＢ１２０、出荷用トラック管理ＤＢ１３０、出荷量設定テーブル１５０等を記録する。各データベースおよびテーブルの記録内容については後述する。各ＤＢおよびテーブルは、装置のハードディスク（またはメモリ）に記録するものとするが、これに限らず、管理サーバとは物理的に独立の装置類に記録するようにしてもよい。

クライアントユニット２０００は、顧客側コンピュータ２００の他、薬液在庫倉庫２１０、補給液槽２２０、めっき層２３０を有している。薬液在庫倉庫２１０には、建浴液および補給液の在庫が保存されている。薬液在庫倉庫２１０に保存されている補給液は、補給液槽２２０に送出される。

建浴液がめっき層２３０に供給される場合、カウント部２４０は、顧客側コンピュータ２００に対して建浴があったことを知らせる信号を送信する。カウント部２４０は、めっきライン担当者の操作に応じて信号を送信するようにしてもよく、その他、センサー類によって自動で信号を送信するようにしてもよい。

めっき槽２３０にはセンサー部２６０が設置されている。センサー部２６０は、バルブ、ポンプ駆動回路、リレー回路、レベルセンサー増幅回路、アナログ増幅回路、ＡＤ変換回路等を有しており、めっき層２３０の中のめっき液の一定量（サンプル）は、定期的にセンサー部２６０に送出される。

センサー部２６０は、分析部２７０と接続されている。分析部２７０は、検液計量部、中和滴定部、試薬タンク、交換水タンク等を有しており、センサー部２６０に送出されたサンプルに基づいてめっき液のめっき濃度やめっき液消耗量を分析する。

顧客側コンピュータ２００は、分析部２７０の分析結果を受信する。顧客側コンピュータ２００は、その分析結果に基づき、めっき槽２３０に補給液（薬液）を補給する必要があると判断した場合には、補給部２５０を制御することによって、補給液槽２２０に保存されている補給液をめっき槽２３０に補給する。補給部２５０は、例えば、電子制御による開閉バルブ等の機構を備えている。

その他、顧客側コンピュータ２００には、後述する警告部２８０が接続されている。なお、図では薬液の供給先であるクライアントは１カ所であるものとして説明したが、本実施形態は、クライアントが複数存在する場合（クライアントユニット２０００が複数存在する場合）、および（または）めっきラインが複数存在する場合にも同様に実行可能である。

以上説明した、めっき槽２３０に対する補給液の補給制御処理は、例えば、特許出願公告昭６０−１６５１７に開示されている技術を利用することができる。その他、同補給制御処理を行う装置として、「無電解ニッケルめっき用自動液管理装置「ケミロボ（商標）」（上村工業株式会社）」、あるいは、「無電解ニッケルめっき用自動めっき液管理装置「スターライン（商標）」（上村工業株式会社）」等を利用することができる。

１−２．めっき作業
めっき作業は、建浴液およびめっき液をめっき槽２３０に供給（建浴作業）した後に行われる。めっき作業の進行に応じて、金属塩、還元剤等が消耗する。消耗したそれらの薬液を補充するために、めっき槽には補給液が補給される。一定回数の補給液の補給が行われると液の老化度が高くなるため、再度建浴が行われる。

図２に基づいて、本実施形態におけるめっき液等の供給・補給の概要を説明する。最初に（１）めっき槽２３０に対して建浴液（以下、「Ｍ」とする。）およびめっき液（以下、「Ａ」とする。）が供給される（建浴）。（２）建浴カウント信号が、カウント部２４０から顧客側コンピュータ２００に送信される。顧客側コンピュータ２００は、カウント信号を管理サーバ１００に対して送信する。（３）管理サーバ１００は、在庫量データの更新を行う。具体的には、ＭおよびＡについては在庫量と建浴量の差を正味在庫量とし、補給液については在庫量と蓄積補給量の差を正味在庫量とする。（４）管理サーバ１００は、補給回数、蓄積補給量を０に書き換える（リセット）。めっき作業の進行に応じて、金属塩、還元剤等が消耗する。顧客側コンピュータ２００は、補給部２５０を制御することによって補給液を補給する。（６）補給液の補給がある毎に、補給部２５０は、顧客側コンピュータ２００に対して補給信号を送信する。（７）実施形態では、めっき液の老化度を考慮して、５ターンの補給が終了すると１サイクル（１回の建浴分で可能となるめっき作業）が終了したものとし、再度建浴を行う。上述した図２の各処理の詳細は、プログラムのフローチャートを用いて後述する。

１−３．めっき液管理システムの処理概要
図３に基づいて、本実施形態におけるめっき液管理システムの処理概要を説明する。顧客側コンピュータ２００は薬液管理処理２０１を実行し、一方の管理サーバ１００は薬液管理データベース更新処理１０１を実行する。また、管理サーバ１００は、最適出荷量設定処理１０３を実行する。

薬液管理処理２０１および薬液管理データベース更新処理１０１の概要は次の通りである。（１）顧客側コンピュータ２００は、分析部２７０から受信する分析信号に基づいて補給部２５０を制御する。（２）顧客側コンピュータ２００は、分析信号を管理サーバ１００に対して送信する。（３）管理サーバ１００は、分析信号に基づいてめっき作業のサイクルを管理する。（４）管理サーバ１００は、サイクルが完了（１回の建浴分で可能となるめっき作業）が完了したと判断した場合には、顧客側コンピュータ２００に対してサイクル完了信号を送信する。（５）顧客側コンピュータ２００は、サイクル完了信号を受信し、警告部２８０を制御することによってサイクル完了警告を出力する。（６）顧客側コンピュータ２００は、建浴作業が行われたことに伴い、カウント部２４０から受信する建浴カウント信号を受信して、管理サーバ１００に対して建浴カウント信号を送信する。（７）管理サーバ１００は、建浴カウント信号を受信して、薬液管理ＤＢ１２０の中の在庫量データ等を更新する。

管理サーバ１００による最適出荷量設定処理１０３の概要は次の通りである。（１）管理サーバ１００は、薬液管理ＤＢ１２０に記録されたデータに基づいて在庫量の少ない薬液を抽出する。（２）管理サーバ１００は、各クライアント毎に設定された発注単位分を出荷した場合に、出荷手段（例えばトラック等）の積載量が所定範囲にあるか否かを判断する。（３）管理サーバ１００は、積載量が所定範囲内にあると判断した場合には、その積載量にて出荷内容を決定する。（４）管理サーバ１００は、積載量が所定範囲の下限を下回ると判断した場合には、当該所定範囲内となるように（１）で抽出した在庫量の少ない薬液について追加出荷分を調整する（積載量を増加させる）。（５）一方、積載量が所定範囲の上限を上回ると判断した場合には、出荷手段を追加するものと仮定（積載量の加算）したうえで、当該追加後の積載量の所定範囲内となるように、（１）で抽出した在庫量の少ない薬液について追加出荷分を調整する。

以上の処理により、管理サーバ１００は、各クライアント毎に、適切な薬液の出荷量を設定することができる。各処理の詳細は、プログラムのフローチャートを用いて後述する。

本実施形態では、管理サーバ１００および顧客側コンピュータ２００によるデータの送受信、管理サーバ１００および顧客側コンピュータ２００のユーザによる画面閲覧のためのソフトウェアとして専用のプログラムを利用する。ただし、専用のプログラムに限らず、例えばＭｉｃｒｏｓｏｆｔ社のＦｒｏｎｔＰａｇｅ（商標）等を使用してもよい。

−−２．ハードウェア構成等−−
２−１．機能ブロック
図４は、めっき液管理システムの機能ブロック図を示す。顧客側コンピュータ２００は、各原材料の使用量データを送信する送信手段４０２、使用量データを取得するために使用量を監視する使用量監視手段４０４を備えている。

管理サーバ１００は、供給先における各原材料の供給量データを取得する供給量データ取得手段４５２、供給先における各原材料の使用量データを取得する使用量データ取得手段４５０、供給先における各原材料の在庫可能範囲データを取得する在庫可能範囲データ取得手段４５６、在庫量を演算する在庫量演算手段４５８、追加供給量を判断し、当該追加供給量を供給内容として決定する追加供給量決定手段４６０、所定の処理によって特定原材料を選択する特定原材料選択手段４５４、輸送可能範囲データを取得する輸送可能範囲データ取得手段４６４、所定の場合に輸送可能範囲データを変更する輸送可能範囲データ変更手段４６２を備えている。

２−２．管理サーバ
図５は、図４の管理サーバ１００をＣＰＵを用いて実現した場合のハードウェア構成の一例である。管理サーバ１００は、ＣＰＵ１０、キーボード／マウス１１、メモリ１２、ディスプレイ１３、ハードディスク１４、スピーカ１５、専用線３００に接続するための通信回路１６を備えている。

ＣＰＵ１０は、管理サーバ１００全体を制御する。メモリ１２には、出荷量設定テーブル１５０が記録されるほか、ＣＰＵ１０のワーク領域等を提供する。ハードディスク１４には、クライアント管理ＤＢ１１０、薬液管理ＤＢ１２０、出荷用トラック管理ＤＢ１３０、およびＣＰＵ１０を動作させるためのプログラムが記録されている。キーボード／マウス１１の操作により生成される操作情報はＣＰＵ１０に入力され、ＣＰＵ１０が生成した画像情報及び音声情報は、ディスプレイ１３、スピーカ１５にそれぞれ出力される。

２−３．顧客側コンピュータ２００
図６は、図４の顧客側コンピュータ１００をＣＰＵを用いて実現した場合のハードウェア構成の一例である。顧客側コンピュータ２００は、ＣＰＵ２０、キーボード／マウス２１、メモリ２２、ディスプレイ２３、ハードディスク２４、スピーカ２５、専用線３００等に接続するための通信回路２６を備えている。また、顧客側コンピュータ２００は、図１に示す警告部２３０、補給部２５０、カウント部２４０、分析部２７０と接続される。

ＣＰＵ２０は、顧客側コンピュータ２００全体を制御する。メモリ２２は、ＣＰＵ２０のワーク領域等を提供する。ハードディスク２４には、ＣＰＵ２０を動作させるためのプログラムが記録されている。キーボード／マウス２１の操作により生成される操作情報はＣＰＵ２０に入力され、ＣＰＵ２０が生成した画像情報および音声情報は、ディスプレイ２３、スピーカ２５にそれぞれ出力される。

本実施形態では、管理サーバ１００および顧客側コンピュータ２００のオペレーティングシステム（ＯＳ）の例として、マイクロソフト社のＷｉｎｄｏｗｓ（登録商標）ＸＰ、ＮＴ、２０００等を用いることとする。本実施形態のプログラムは、ＯＳと共働して各機能を実現しているが、これに限らず、プログラム単独で各機能を実現するようにしてもよい。

２−４．データベース等
本システムのデータベース等の構成例について説明する。

２−４−１．クライアント管理ＤＢ１１０
図７は、管理サーバ１００のハードディスク１４（またはメモリ１２、以下同様）に記録されるクライアント管理ＤＢ１１０の構成例である。クライアント管理ＤＢ１１０には、各クライアント（薬液の供給先）毎に、「クライアントＩＤ」、「クライアント名」、クライアントの「所在地」（例えば、めっき工場等の住所）、薬液供給メーカ（供給元）からクライアントの所在地までの距離を示す「出荷距離（ｋｍ）」、薬液の発注日から何日以内にその薬液が納入される必要があるかということを示す「許容日数」の各情報が記録されるカラムがある。

２−４−２．薬液管理ＤＢ１２０
図８は、管理サーバ１００のハードディスク１４（またはメモリ１２、以下同様）に記録される薬液管理ＤＢ１２０の構成例である。薬液管理ＤＢ１２０には、各クライアント毎に、「クライアントＩＤ」、めっき槽２３０の浴量を示す「めっき槽浴量（リットル（Ｌ））」、現在めっき作業中のめっき槽２３０に対する建浴が実施された日を示す「建浴日付」、当該建浴に対する薬液の補給回数に関連する「ターン数」、「薬液コード」、薬液の種類を示す「薬液種」の各情報が記録されるカラムがある。

建浴液（コードＭ）およびニッケルめっき（コードＡ）は、建浴時にめっき槽２３０に供給される。ニッケルめっき（コードＡ）および還元剤（コードＢ）、錯化剤（コードＣ）は、めっき作業の進行に伴って消耗するため、補給部２５０の制御によってめっき槽２３０に補給される。したがって、薬液管理ＤＢ１２０には、各クライアントの各薬液コード毎に、「建浴量（Ｌ）」、１回の補給に必要な量を示す「単位補給量（Ｌ）」、「補給回数」、単位補給量に補給回数を乗じて得られる「蓄積補給量（Ｌ）」、１日当たりの薬液の使用量を示す「単位使用量（Ｌ／日）、薬液在庫倉庫２１０および補給液層２２０にストックされている薬液量を示す「在庫量（Ｌ）」、「必要最低在庫量（Ｌ）」、「許容最高在庫量（Ｌ）」、「発注単位（Ｌ）」の各情報が記録されるカラムがある。

「単位使用量」は、管理サーバ１００のＣＰＵ１０が、例示として、建浴量または蓄積補給量を、建浴日から現在までに経過した日数で割ることによって得ることができる。ＣＰＵ１０は、例えば、蓄積補給量等の更新処理が行われる毎に単位使用量の更新処理を行う。「在庫量」は、薬液在庫倉庫２１０および補給液層２２０にストックされている薬液量を示すものである。この在庫量は、薬液供給メーカ側である管理サーバ１００が出荷する薬液の出荷量に基づいて定まる値であり、管理サーバ１００側で把握可能である。また、在庫量は、例示として後述する薬液管理ＤＢ更新処理プログラムにおいて、建浴が行われた後に書き換えられるものとする。

「必要最低在庫量」および「許容最高在庫量」は、例示として、各クライアントのめっき槽２３０のサイズや、めっき作業スケジュールの進行ペースに基づいて、管理サーバ１００側であらかじめ設定するものとする。以下、「必要最低在庫量」および「許容最高在庫量」の設定例を示す。

（設定例）
１．めっき浴管理基準
めっき浴標準濃度： ５ｇ／Ｌ
１回の補給量： ０．２ｇ／Ｌ
管理範囲： ４．８〜５．０ｇ／Ｌ
使用目標ターン数： ５ターン（１サイクル）
２．一槽あたり、建浴時に必要なめっき液量
（１）建浴液（Ｍ）：１Ｌあたり１００ｍＬの濃度が必要→１０００Ｌ槽では１００Ｌ必要
（２）ニッケルめっき（Ａ）：１Ｌあたり５５ｍＬの濃度が必要→１０００Ｌ槽では５５Ｌ必要
３．補給必要量
（１）ニッケル１ｇ消耗するのに比例して、Ａ、補給液Ｂ、Ｃがそれぞれ１１ｍＬ必要
（２）１回の補給に必要な量： ０．２ｇ／Ｌ×１０００Ｌ×１１ｍＬ＝２．２Ｌ
（３）（めっき浴標準能動５ｇ／Ｌ）／（１回の補給量０．２ｇ／Ｌ）＝２５であるから、１ターンあたり２５回の補給が必要→ ２．２Ｌ×２５＝５５であるから、１ターンあたりの補給量は５５Ｌ
（４）５５Ｌ×５ターン＝２７５Ｌより、１サイクル（５ターン）あたり、２７５Ｌの補給量が必要
４．必要最低在庫量
以上の計算結果に基づき、クライアントの必要最低在庫量を１０００Ｌ槽の１サイクル分（補給分）と仮定すると、以下のような値となる。

Ｍ液： １００Ｌ
Ａ液： ３３０Ｌ （内訳 ５５Ｌ＋２７５Ｌ）
Ｂ液： ２７５Ｌ
Ｃ液： ２７５Ｌ
５．許容最高在庫量
さらに、クライアントの許容最高在庫量を１０００Ｌ槽の５回建浴分、および３サイクル分（補給分）と仮定すると、以下のような値となる。

Ｍ液： ５００Ｌ （内訳 １００Ｌ×５）
Ａ液： １１００Ｌ （内訳 （５５Ｌ×５）＋（２７５Ｌ×３））
Ｂ液： ８２５Ｌ （内訳 ２７５Ｌ×３）
Ｃ液： ８２５Ｌ （内訳 ２７５Ｌ×３）
以上、図８の薬液管理ＤＢ１２０に記録される「必要最低在庫量」および「許容最高在庫量」の１設定例を示した。ただし、これらの値は、クライアント側からの要望等に応じて設定変更することも可能である。例えば、「必要最低在庫量」については、その在庫量を下回るとめっき作業が不能となる場合の量、またはめっき作業が不能となる場合の量に余裕量を加算した量、めっき槽２３０にサイズを考慮した量、めっき作業スケジュールの進行ペースを考慮した量、クライアントにおける原材料倉庫の大きさを考慮した量等を採用してもよい。

「発注単位（Ｌ）」は、薬液の１回の発注があった場合に、薬液供給メーカが発送する薬液の基準単位である。この基準単位は、例示として、各クライアントのめっき槽２３０にサイズや、めっき作業スケジュールの進行ペース、または薬液供給メーカと供給先との間の契約等に基づいて、管理サーバ１００側であらかじめ記録するものとする。したがって、管理サーバ１００は、１回の出荷作業を行う場合には、通常、「発注単位」の量（すなわち、発注単位×１）の薬液を出荷する。ただし、後述する最適出荷量設定処理において出荷量を調整する必要が生じた場合には、発注単位×ｎの量の薬液を出荷することになる。

２−４−３．出荷用トラック管理ＤＢ１３０
図９は、管理サーバ１００のハードディスク１４（またはメモリ１２、以下同様）に記録される出荷用トラック管理ＤＢ１３０の構成例である。実施形態では、本発明にかかる輸送手段として、薬液供給メーカが所有する複数の輸送用「トラック」を例示しているが、これに限られるものではなく、輸送貨物列車、または輸送飛行機、または輸送車両一般を利用してもよい。

出荷用トラック管理ＤＢ１３０には、トラック毎に、「トラックＩＤ」、「種別」、トラックの「最大積載量」、「輸送単価（円／ｋｍ）」、「運行予定日１」、「運行予定日２」の各情報が記録されるカラムがある。

「種別」は、例示として、薬液の出荷に通常利用する定期トラックの場合は種別０とし、定期トラックの積載量を超える出荷量がある場合に利用する特別トラックの場合は種別１とする。定期トラックとは、例えば、薬液供給メーカ側で管理（または所有）しているトラック、または、薬液供給メーカとの間の契約により、定常的に薬液の出荷を担当するものとして管理されているトラック（例えばトラック配送企業が所有するトラック）等に対応する。一方、特別トラックとは、例えば、薬液供給メーカ側で管理（または所有）しているトラックのうち、通常は薬液以外の物品の配送に利用されているトラック、または、薬液供給メーカとの間の臨時契約（または特別依頼等）により、定常的な薬液出荷とは別に薬液の出荷を担当するものとして割り当てられるトラック（例えばトラック配送企業が所有するトラック）等に対応する。

「輸送単価」は、例示として、１ｋｍの運行当たりに要する輸送費用を表す。「運行予定日１」および「運行予定日２」は、後述する最適出荷量設定処理によって設定された出荷内容に基づいて記録される、各トラックの運行予定日である。

２−４−４．出荷量設定テーブル１５０
図１０は、管理サーバ１００のメモリ１２（またはハードディスク１４、以下同様）に記録される出荷量設定テーブル１５０の構成例である。管理サーバ１００のＣＰＵ１０は、後述する最適出荷量設定処理において、出荷量設定テーブル１５０の内容を記録する。

出荷量設定テーブル１５０には、「トラックＩＤ」、「出荷日」、「出荷先クライアントＩＤ」、「出荷薬液コード」、「発注数」、「発注単位（Ｌ）」、「使用量順位」、「調整発注数」、「調整出荷量（Ｌ）」、「正味在庫量（Ｌ）」、「出荷後在庫量」、「必要最低在庫量」、「許容最高在庫量」、「合計積載量」、「積載率」、「輸送コスト（万円）」の各情報が記録されるカラムがある。出荷量設定テーブル１５０の記録内容は後述する。

−−３．特許請求の範囲に記載した用語と実施形態との対応−−
特許請求の範囲に記載した用語と実施形態との対応は以下の通りである。ただし以下に説明する対応は、各用語によって表される構成の一つの形態（一部の形態）、またはその構成が有する機能の中の一つの形態を示すものである。

「原材料供給量管理装置」は管理サーバ１００に対応し、「端末装置」は顧客側コンピュータ２００に対応する。「原材料」は、建浴液、またはニッケルめっき液、または還元剤、または錯化剤等の薬液に対応する。

「在庫可能範囲データ」は、図８の薬液管理ＤＢ１２０に記録される「必要最低在庫量」または「許容最高在庫量」のデータに対応する。「在庫可能範囲の下限」は、「必要最低在庫量」に対応する。「在庫可能範囲データ取得手段」は、在庫可能範囲データを取得する機能を有するものに対応し、例えば、図１３ステップＳ３０７の処理において薬液管理ＤＢ１２０における「必要最低在庫量」または「許容最高在庫量」のデータを参照する管理サーバ１００のＣＰＵ１０に対応する。

「供給量データ」は、図８の薬液管理ＤＢ１２０に記録される「在庫量」のデータに対応する。「供給量データ取得手段」は、供給量データを取得する機能を有するものに対応し、例えば、図１３ステップＳ３０５の処理において薬液管理ＤＢ１２０における「在庫量」のデータを参照するＣＰＵ１０に対応する。

「使用量データ」は、図８の薬液管理ＤＢ１２０に記録される「建浴量」、または「単位補給量」、または「補給回数」、または「蓄積補給量」のデータ、または図１１のステップＳ１０９において顧客側コンピュータ２００のＣＰＵ２０がが送信する「分析信号」に対応する。「使用量データ取得手段」は、使用量データを取得する機能を有するものに対応し、例えば、図１３ステップＳ３０５の処理において薬液管理ＤＢ１２０における「建浴量」または「蓄積補給量」のデータを参照するＣＰＵ１０に対応する。

「実質在庫量」は、図１０の出荷量設定テーブル１５０に記録される「正味在庫量」のデータに対応する。「在庫量演算手段」は、実質在庫量を演算する機能を有するものに対応し、例えば、図１３ステップＳ３０５の処理を実行するＣＰＵ１０に対応する。

「追加供給量」は、図１０の出荷量設定テーブル１５０に記録される「調整出荷量」のデータに対応する。「追加供給量決定手段」は、追加供給量を供給内容として決定する機能を有するものに対応し、例えば、図１３ステップＳ３０７、またはＳ３０９、またはＳ３１１、またはＳ３１３、またはＳ３１５、またはＳ３１７、またはＳ３１９、またはＳ３２１、またはＳ３２３の処理を実行するＣＰＵ１０に対応する。

「送信手段」は、使用量データを送信する機能を有するものに対応し、例えば、図１１ステップＳ１０９の処理（図８の薬液管理ＤＢ１２０に記録される「補給回数」の情報の元となる分析信号を送信する処理）を行う顧客側コンピュータ２００のＣＰＵ２０に対応する。

「輸送手段」は、原材料の輸送を行う機能を有するものに対応し、例えば、輸送用トラックに対応する。「輸送可能範囲データ」は、図９の出荷用トラック管理ＤＢ１３０に記録される「最大積載量」のデータに対応する。「輸送可能範囲データ取得手段」は、輸送可能範囲データを取得する機能を有するものに対応し、例えば、図１３ステップＳ３１３の処理において出荷用トラック管理ＤＢ１３０における「最大積載量」のデータを参照するＣＰＵ１０に対応する。「輸送可能範囲の下限」は、例えば、図１３のステップＳ３１５においてＣＰＵ１０が判断基準として利用する「８５％（積載率）」という情報に対応する。「輸送可能範囲の上限」は、例えば、図１３のステップＳ３１５においてＣＰＵ１０が判断基準として利用する「１００％（積載率）」という情報に対応する。「輸送可能範囲データ変更手段」は、輸送可能範囲データを変更する機能を有するものに対応し、例えば、図１３のステップＳ３１７、Ｓ３１９の処理において、最大積載量を変更する処理を行うＣＰＵ１０に対応する。

「追加供給量の合計量」は、図１０の出荷量設定テーブル１５０に記録される「合計積載量」のデータに対応する。

「特定原材料」は、図１４ステップＳ４０３においてＣＰＵ１０が選択する薬液に対応する。「補充追加供給量」は、図１０の出荷量設定テーブル１５０に記録される「調整発注数」または「調整出荷量」のデータに対応する。「使用履歴量」は、図８の薬液管理ＤＢ１２０に記録される「単位使用量」の情報に対応する。「特定原材料選択手段」は、特定原材料の選択を行う機能を有するものに対応し、例えば、図１４ステップＳ４０３の処理を行うＣＰＵ１０に対応する。「使用量監視手段」は、使用量を監視する機能を有するものに対応し、例えば、図１のセンサー部２６０、または分析部２７０、または図１１のステップＳ１０１、またはＳ１０３において分析信号を受信する顧客側コンピュータ２００のＣＰＵ２０に対応する。

−−４．実施形態（薬液管理処理プログラム）−−
図３に示す薬液管理処理２０１の詳細を説明する。図１１は、実施形態において、顧客側コンピュータ２００のＣＰＵ２０が実行する薬液管理処理プログラムのフローチャートである。この薬液管理処理プログラムは、１回の建浴がある毎に実行されるものである。１回のめっき槽の建浴に対して、１サイクル（５ターン）の補給が行われる。したがって、顧客側コンピュータ２００は、建浴の開始から終了にしたがって、建浴が実行されたことを示す「建浴カウント信号」、補給液を補給する必要があることを示す「分析信号（５ターン分）」、１サイクルが完了したことを示す「サイクル完了信号」を順番に受信することになる。１サイクルが完了した後、すなわち、１回のめっき槽の建浴に対するめっき作業が終了した後、薬液管理処理プログラムは終了することとなる。次の建浴作業が実行される場合には、顧客側コンピュータ２００のユーザ操作等に応じて薬液管理処理プログラムを再び実行する。以下、図１１に示す薬液管理処理プログラムのフローチャートを説明する。

顧客側コンピュータ２００のユーザは、建浴を開始する前に薬液管理処理プログラムを起動する。顧客側コンピュータ２００のＣＰＵ２０は、信号を受信したか否かを判断する（図１１ステップＳ１０１）。ＣＰＵ２０は、信号を受信したと判断した場合には、信号種を判断する（ステップＳ１０３）。信号種は、管理サーバ１００から送信されるサイクル完了信号、または分析部２７０から送信される分析信号、またはカウント部２４０から送信される建浴カウント信号のいずれかである。ＣＰＵ２０は、これらの信号種を、例えば各信号のヘッダ情報等を利用して判断する。

Ｓ１０３において、カウント部２５０から建浴カウント信号を受信したと判断した場合には、ＣＰＵ２０は、管理サーバ１００に対してその建浴カウント信号を送信し（Ｓ１１１）、Ｓ１０１からの処理を繰り返す。なお、Ｓ１１１では例示として建浴カウント信号を挙げたが、その他の信号、例えば建浴開始信号を管理サーバ１００に送信するようにしてもよい。

Ｓ１０３において、分析部２７０から分析信号を受信したと判断した場合には、ＣＰＵ２０は、補給部２５０を制御する（ステップＳ１０７）。この補給部２５０の制御によって、補給液槽２２０に保存されている補給液がめっき槽２３０に補給される（１ターン分の補給）。１ターン分の補給は、通常、単位補給量の２５回分前後に相当するものであり、めっき作業の内容に応じて微調整可能である。分析信号は、めっき槽の中の薬液の一部（サンプル）の分析の結果、補給液の補給が必要であることを示す信号である。したがって、分析部２７０は、補給が必要でない場合は分析信号を送信しない。Ｓ１０７の処理の後、ＣＰＵ２０は、管理サーバ１００に対してその分析信号を送信し（Ｓ１０９）、Ｓ１０１からの処理を繰り返す。なお、Ｓ１０９では例示として分析信号を挙げたが、その他の信号、例えば補給完了信号を管理サーバ１００に送信するようにしてもよい。

実施形態では、１サイクル当たり５ターンの補給制御を行う設定としている。したがって、５ターン分の補給が終了した後には、管理サーバ１００側からサイクル完了信号が送信される（図１２ステップＳ２０９参照）。

Ｓ１０３において、管理サーバ１００からサイクル完了信号を受信したと判断した場合には、ＣＰＵ２０は、警告部２８０を制御して処理を終了する（Ｓ１０５）。警告部２８０は、サイクル完了警告を出力する。これにより、めっきラインの作業者または管理者は、１サイクルが終了したことを把握することができる。なお、サイクル完了警告は、警告部２８０以外に、顧客側コンピュータ２００のディスプレイ２３にサイクル完了警告表示を出力したり、あるいは、スピーカ２５を介してサイクル完了警告音声（例えばブザー音、または音声案内等）を出力するようにしてもよい。

−−５．実施形態（薬液管理データベース更新処理プログラム）−−
図３に示す薬液管理データベース更新処理１０１の詳細を説明する。図１２は、実施形態において、管理サーバ１００のＣＰＵ１０が実行する薬液管理データベース更新処理プログラムのフローチャートである。

この薬液管理データベース更新処理プログラムは、１回の建浴がある毎に実行されるものである。以下、図１２に示す薬液管理データベース更新処理プログラムのフローチャートを説明する。

管理サーバ１００のＣＰＵ１０は、信号を受信したか否かを判断する（図１２ステップＳ２０１）。ＣＰＵ１０は、信号を受信したと判断した場合には、信号種を判断する（ステップＳ２０３）。信号種は、顧客側コンピュータ２００から送信される建浴カウント信号（図１１ステップＳ１１１参照）、または分析信号（図１１ステップＳ１０９参照）のいずれかである。ＣＰＵ２０は、これらの信号種を、例えば各信号のヘッダ情報等を利用して判断する。なお、管理サーバ１００は、クライアント側における建浴の開始から終了にしたがって、建浴が実行されたことを示す「建浴カウント信号」、補給液を補給する必要があることを示す「分析信号（５ターン分）」を順番に受信することになる。

Ｓ２０３において建浴カウント信号を受信したと判断した場合には、ＣＰＵ１０は、在庫量データを更新する（Ｓ２１３）。具体的には、ＣＰＵ１０は、図８の薬液管理ＤＢ１２０における各薬液の在庫量を現実の在庫量に書き換える処理を行う。各薬液についての演算処理の詳細は以下の通りである。

（１）建浴液（Ｍ）およびニッケルめっき（Ａ）
建浴カウント信号を受信した後（建浴が開始された後）、「在庫量」の値を「在庫量−建浴量」の値に書き換える。なお、Ｍ液およびＡ液は、建浴時に供給されるものであり、一定の値であるのが一般的である。具体的には、管理サーバ１００は、在庫量「２５０」、建浴量「１００」の場合、建浴が行われた後に「在庫量」のカラムを「２５０」から「１５０」に書き換える。

（２）補給液（還元剤（Ｂ）および錯化剤（Ｃ））
建浴後に補給液が補給されている間は、図８の「補給回数」および「蓄積補給量」のみを書き換え、一方の「在庫量」は書き換えないものとする。そして、建浴カウント信号を受信した後（建浴が開始された後）、「在庫量」の値を「在庫量−蓄積補給量」の値に書き換える。具体的には、管理サーバ１００は、補給液の補給時（単位補給量「２．２」と仮定）には、補給回数がカウントされる毎に、蓄積補給量を「０→５５（＝２．２×２５）→１１０→・・・」という順番で書き換える（１ターン＝単位補給量の２５回分の場合）。

管理サーバ１００は、在庫量「６５５」、蓄積補給量「５５」の場合、建浴が行われた後に「在庫量」のカラムを「６５５」から「６００」に書き換える。

Ｓ２１３の処理の後、ＣＰＵ１０は、図８の薬液管理ＤＢ１２０の「補給回数」および「蓄積補給量」のカラムを０に書き換えて（リセット処理）（Ｓ２１５）、Ｓ２０１からの処理を実行する。

Ｓ２０３において、分析信号を受信したと判断した場合には、ＣＰＵ１０は、薬液管理ＤＢ１２０における「ターン数」および「補給回数」のカラムをカウントアップ（＋１）する（Ｓ２０５）。具体的には、クライアントＩＤ「Ａ００１」に対応する顧客側コンピュータ２００から分析信号を受信した場合（カウントアップ前「０」）には、ターン数（および補給回数）「０」を「１」に書き換える。

ＣＰＵ１０は、ターン数が５であるか否かを判断し（Ｓ２０７）、５でない場合には、Ｓ２０１からの処理を繰り返す。一方、ターン数が５（すなわち、１サイクル分）であると判断した場合には、ＣＰＵ１０は、顧客側コンピュータ２００に対してサイクル完了信号を送信する（Ｓ２０９）。ＣＰＵ１０は、薬液管理ＤＢ１２０の「ターン数（および補給回数）」のカラムを「０」に書き換えて（リセット処理）（Ｓ２１１）、処理を終了する。

なお、図１２に示す薬液管理データベース更新処理プログラムは、１回の建浴がある毎に実行されるものとして、便宜上Ｓ２１１の後にプログラムを終了するものとした。ただし、薬液の供給先が複数ある場合や、供給先において建浴が連続して実行される場合には、Ｓ２１１の処理の後、再びＳ２０１の処理を繰り返すのが一般的である。

−−６．第１実施形態 〜最適出荷量設定処理〜−−
第１実施形態として、図３に示す最適出荷量設定処理１０３の詳細を説明する。図１３、図１４は、実施形態において、管理サーバ１００のＣＰＵ１０が実行する最適出荷量設定処理プログラムのフローチャートである。

この最適出荷量設定処理プログラムは、管理サーバ１００のユーザによる要求（処理実行命令）がある毎に、薬液管理ＤＢ１２０に記録されている全てのクライアント（薬液供給先）の薬液について実行されるものである。具体的には、薬液供給メーカ側である管理サーバ１００は、薬液管理ＤＢ１２０に記録されている各薬液について、在庫量と蓄積補給量（建浴量）とに基づいて現時点での在庫量（正味在庫量）を演算する。そして、管理サーバ１００は、その正味在庫量が必要最低在庫量を下回っている薬液について、対応するクライアントに対する出荷予定を設定する。

なお、実施形態では、ユーザによる要求（処理実行命令）がある毎に最適出荷量設定処理プログラムを実行することとするが、これに限らず、管理サーバ１００のＣＰＵ１０が、定期的に（例えば１日に１回、または１週間に１回等）自動で最適出荷量設定処理プログラムを実行するようにしてもよい。また、薬液管理ＤＢ１２０に記録されている全てのクライアントの薬液について最適出荷量設定処理プログラムを実行する場合に限らず、選択された特定のクライアントの薬液、または選択された特定の薬液に限定して最適出荷量設定処理プログラムを実行するようにしてもよい。以下、図１３、図１４に示す最適出荷量設定処理プログラムのフローチャートを説明する。

管理サーバ１００のＣＰＵ１０は、ユーザにより最適出荷量設定処理命令の入力があったか否かを判断する（図１３ステップＳ３０１）。図１６は、第１実施形態における管理サーバ１００のディスプレイ１３の画面表示例を示す。図１６Ａは、Ｓ３０１の処理中のディスプレイ１３の画面表示例である。ユーザによる最適出荷量設定処理命令の入力は、例えば実行ボタンのクリック動作の有無等によって判断すればよい。

Ｓ３０１において処理命令の入力があったと判断した場合には、ＣＰＵ１０は、ハードディスク１４に記録された出荷用トラック管理ＤＢ１３０に基づいてトラックのデータを抽出し、出荷量設定テーブル１５０に記録する（Ｓ３０３）。具体的には、出荷用トラック管理ＤＢ１３０において、運行予定日のカラムに情報が記録されていないトラックについての「トラックＩＤ」を抽出し、図１０に例示する出荷量設定テーブル１５０の「トラックＩＤ」のカラムに記録する。ここでは、トラックＩＤ「Ｔ０１」が記録されたものとする。

ＣＰＵ１０は、ハードディスク１４に記録された薬液管理ＤＢ１２０を参照し、記録されている各薬液について正味在庫量を演算し、演算結果をメモリ１２（またはハードディスク１４、以下同じ）に記録する（Ｓ３０５）。正味在庫量は、最適出荷量設定処理の実行時における現実の在庫量を示すものであり、以下の数式１または数式２によって演算される。

（１）建浴液（Ｍ）およびニッケルめっき（Ａ）
正味在庫量＝在庫量−建浴量 ・・・（１）
在庫量および建浴量は、薬液管理ＤＢ１２０に記録されている情報である。例えば、在庫量「１５０」、建浴量「１００」の場合は、正味在庫量は「５０」となる（図８のクライアントＩＤ「Ａ００１」のＭ液参照）。

（２）補給液（還元剤（Ｂ）および錯化剤（Ｃ））
正味在庫量＝在庫量−蓄積補給量 ・・・（２）
在庫量および蓄積補給量は、薬液管理ＤＢ１２０に記録されている情報である。

例えば、在庫量「１５０」、蓄積補給量「２４．２」の場合は、正味在庫量は「１２５．８」となる（図８のクライアントＩＤ「Ａ００２」のＢ液参照）。

管理サーバ１００のＣＰＵ１０は、Ｓ３０３で演算した結果に基づいて、各薬液につき、正味在庫量が必要最低在庫量より少なくなっているものを抽出して、出荷量設定テーブル１５０に記録する（Ｓ３０７）。例えば図８におけるクライアントＩＤ「Ａ００１」のＭ液の場合、正味在庫量は５０（＝１５０−１００）であり、必要在庫量「１００」よりも少ないものと判断される。

図１５は、第１実施形態における出荷量設定テーブル１５０の構成例を示す図である。図１５Ａは、Ｓ３０７、３０９、３１１、３１３の処理中の出荷量設定テーブル１５０の構成例を示す。ＣＰＵ１０は、正味在庫量が必要最低在庫量より少なくなっている薬液に関する情報を薬液管理ＤＢ１２０からコピーして、出荷量設定テーブル１５０に記録する。出荷量設定テーブル１５０中の「正味在庫量」は、Ｓ３０３において演算した情報を記録する。ここでは、クライアントＩＤ「Ａ００１」のＭ液、Ａ液、および「Ａ００２」のＡ液、Ｂ液、Ｃ液が出荷量設定テーブル１５０に記録されたものとする。「出荷日」は、実施形態では例示として最適出荷量設定処理プログラムを実行した翌日を記録する。「出荷日」の情報はこれに限らず、管理サーバ１００のユーザによって設定された日付を記録するようにしてもよい。

「発注数」は、例示として初期値「１」が記録される。ただし、管理サーバ１００のユーザまたはクライアント側のユーザの要求に応じて、「発注数」を変更してもよい。実施形態では、発注量を「発注単位」と「発注数」によって決定しているが、これに限らず、最適出荷量設定処理プログラムを実行する毎に、管理サーバ１００のＣＰＵ１０が顧客側コンピュータ２００にアクセスして、クライアントが所望する「発注量」を取得するようにしてもよい。

「使用量順位」は、ＣＰＵ１０が、抽出された薬液に関して単位使用量（図８参照）を比較し、最も単位使用量が大きいものから順番に「１、２・・・ｎ」を割り当てて記録する。

管理サーバ１００のＣＰＵ１０は、出荷量設定テーブル１５０に記録された情報に基づいて、「出荷後在庫量」を演算する（Ｓ３０９）。出荷後在庫量は、発注単位に相当する薬液を出荷したと仮定した場合に、その出荷によって在庫量がどう変化するかを示すものであり、以下の数式３によって演算される。

出荷後在庫量＝正味在庫量＋（発注単位×発注数）＋調整出荷量・・・（３） 実施形態では、あらかじめ設定した発注単位（Ｌ）１個分の出荷によって、通常は必要最低在庫量以上の在庫が確保できるように設定している。したがって、Ｓ３０７の処理によって正味在庫量が必要最低在庫量より少なくなっていると判断された薬液は、Ｓ３０９の処理によって設定される出荷内容によって必要最低在庫量以上の在庫が確保できるようになるのが一般的である。なお、数式３における調整出荷量については後述する。

ＣＰＵ１０は、出荷量設定テーブル１５０に記録された情報に基づいて、合計積載量を演算し、演算結果を同テーブルに記録する（Ｓ３１１）。合計積載量は、以下の数式４によって演算される。

合計積載量＝Σ（発注単位×発注数）・・・（４）
ここでは、図１５Ａに例示するように、合計積載量として１２００（＝３００＋３００＋２００＋２００＋２００）が記録される。

ＣＰＵ１０は、Ｓ３１１で演算した合計積載量の情報と、出荷用トラック管理ＤＢ１３０に記録された「最大積載量」との情報に基づいて積載率を演算し、演算結果を同テーブルに記録する（Ｓ３１３）。積載率は、以下の数式５によって演算される。

積載率（％）＝（合計積載量／最大積載量）×１００・・・（５）
ここでは、図１５Ａに例示するように、積載率として６０（＝（１２００／２０００）×１００）が記録される。

ＣＰＵ１０は、出荷量設定テーブル１５０に記録された積載率が８５％以上１００％以下となったか否かを判断する（Ｓ３１５）。この処理により、薬液のトラック輸送が効率的に行えるか、言い換えると、１回の出荷分が適切な範囲の積載量となっているか否かが判断される。実施形態では、積載量が少なすぎる等の原因によって生ずる輸送効率の低下を防止するために、８５％以上１００％以下の積載量を例示している。積載量の許容範囲は、これに限らず、その他の範囲（下限、または上限）を採用可能である。

以下、第１実施形態では、積載率が８５％より少ない場合（６０％）を例示して説明する。なお、積載率が１００％より大きい場合は、後述の第２実施形態において説明する。

Ｓ３１５において積載率が８５％より少ないと判断した場合には、ＣＰＵ１０は、Ｓ３２１に示す調整出荷量設定処理を実行する。図１４は、図１３においてサブルーチンとして示したＳ３２１の調整出荷量設定処理プログラムのフローチャートである。

ＣＰＵ１０は、メモリ１２（またはハードディスク１４、以下同じ）においてＮ＝１を割り当てる（図１４ステップＳ４０１）。Ｎは、使用量順位に基づいて薬液を選択するための変数である。ＣＰＵ１０は、出荷量設定テーブル１５０に記録された薬液の中で、使用量順位Ｎのものを選択可能であるか否かを判断する（Ｓ４０３）。ここでは、図１５Ａに例示するクライアントＩＤ「Ａ００１」のＡ液を選択する。

ＣＰＵ１０は、Ｓ４０３で選択した薬液について、出荷量設定テーブル１５０における「調整発注数」のカラムをカウントアップ（＋１）する（Ｓ４０７）。調整発注数は、薬液のトラック輸送を効率化するために、１回の出荷分を適切な範囲の積載量に調整するためのものである。

ＣＰＵ１０は、Ｓ４０７の処理を行った薬液に対応する「出荷後在庫量」を演算し、演算結果に基づいて「出荷後在庫量」のカラム情報を書き換える（Ｓ４０９）。出荷後在庫量は、上述した数式３によって演算する。「調整出荷量」は、発注単位×調整発注数によって演算する。実施形態では、調整出荷量は、発注単位を基準として演算する例を挙げたが、これに限られるものではない。その他の実施形態として、調整出荷量を決定する目的で使用する調整出荷単位（Ｌ）を、発注単位とは別に設定するようにしてもよい。この場合、調整出荷単位（Ｌ）を小さくすれば、一般的には、よりきめ細かい出荷内容の調整を行うことが可能となる。

ＣＰＵ１０は、Ｓ４０９で演算した結果に基づいて、出荷後在庫量が許容最高在庫量以下となっているか否かを判断する（Ｓ４１１）。ここでは、クライアントＩＤ「Ａ００１」のＡ液は、出荷後在庫量が８０３．２（＝２０３．２＋３００＋３００）であり、許容最高在庫量１１００以下となる（図１５Ｂ参照）。

ＣＰＵ１０は、出荷量設定テーブル１５０に記録された情報に基づいて、合計積載量を演算し（数式４参照）、演算結果に基づいて同テーブルの「合計積載量」のカラム情報を書き換える（Ｓ４１３）。ＣＰＵ１０は、Ｓ４１３で演算した合計積載量の情報と、出荷用トラック管理ＤＢ１３０に記録された「最大積載量」との情報に基づいて積載率を演算し（数式５参照）、演算結果に基づいて同テーブルの「積載率」のカラム情報を書き換える（Ｓ４１５）。

図１５Ｂは、Ｓ４１５の処理後の出荷量設定テーブル１５０の構成例を示す。ここでは、合計積載量として１５００（＝１２００＋３００）が記録され、積載率として７５（＝（１５００／２０００）×１００）が記録される。

ＣＰＵ１０は、出荷量設定テーブル１５０に記録された積載率が８５％以上１００％以下となったか否かを判断する（Ｓ４１５）。ここでは、積載率７５％（図１５Ｂ参照）であるから、ＣＰＵ１０は、Ｓ４０７からの処理を繰り返す。具体的には、ＣＰＵ１０は、Ｓ４０３で選択したクライアントＩＤ「Ａ００１」のＡ液について調整発注数を「２」に書き換えた上で、Ｓ４０９、Ｓ４１１の処理を行う。ここでは、調整発注数を「２」とした場合には、Ａ液の出荷後在庫量が１１０３．２（＝２０３．２＋３００＋３００×２）であり、許容最高在庫量１１００を上回ることになる。したがって、ＣＰＵ１０は、Ｓ４１１の処理後に選択した薬液の調整発注数をカウントダウン（−１）する（Ｓ４１９）。ここでは、クライアントＩＤ「Ａ００１」のＡ液について、調整発注数が再び「１」に書き換えられる。このＳ４１９の処理によって、出荷後の在庫量が、クライアントにおける許容最高在庫量を超過することを防止することができる。

ＣＰＵ１０は、メモリ１２に記録したＮをカウントアップ（＋１）して（Ｓ４２１）、Ｓ４０３からの処理を繰り返す。ここでは、ＣＰＵ１０は、使用量順位２の薬液（クライアントＩＤ「Ａ００１」のＭ液）を選択し（図１５Ｂ参照）、Ｓ４０７、Ｓ４０９、Ｓ４１１の処理を行う。Ｍ液の場合、出荷後在庫量が６５０（＝５０＋３００＋３００）となり、許容最高在庫量５００を超過することになる。したがって、ＣＰＵ１０は、Ｍ液について再び調整発注数を「０」に書き換えてＳ４２１からの処理を繰り返す。

次に、ＣＰＵ１０は、使用量順位３の薬液（クライアントＩＤ「Ａ００２」のＡ液）を選択し（図１５Ｂ参照）、Ｓ４０７、Ｓ４０９、Ｓ４１１の処理を行う。Ａ液の場合、出荷後在庫量が４４０（＝４０＋２００＋２００）となり、許容最高在庫量５４９．８以下となる。したがって、ＣＰＵ１０は、Ｓ４１３、Ｓ４１５、Ｓ４１７の処理を行う。

図１５Ｃは、使用量順位３の薬液を選択した後のＳ４１５の処理後の出荷量設定テーブル１５０の構成例を示す。ここでは、合計積載量として１７００（＝１５００＋２００）が記録され、積載率として８５（＝（１７００／２０００）×１００）が記録される。積載率が８５％であるから、ＣＰＵ１０は、Ｓ４１７の処理の後、メモリ１２に記録した出荷量設定テーブル１５０の内容等を出力し（図１３ステップＳ３２３）、処理を終了する。ここでは、図１５Ｃに示す出荷量設定テーブル１５０の内容等を、決定した出荷内容（出荷スケジュール）としてディスプレイ１３に表示するともに、出荷用トラック管理ＤＢ１３０におけるトラックＩＤ「Ｔ０１」の運行予定日のカラムに運行予定日（ここでは、２００３年１０月９日）を記録する。

図１６Ｂは、Ｓ３２３の処理後のディスプレイ１３の画面表示例である。この画面によって、薬液供給メーカのユーザは、各クライアント毎の薬液の出荷量の詳細を把握することができる。

なお、図１４の調整出荷量設定処理プログラムのＳ４１７において、積載量が１００％を上回る場合には、Ｓ４１９からの処理を繰り返すことによって調整発注数を再度修正することになる。

また、図１４のプログラムは、使用量順位の高いものから順番に薬液を選択してその調整発注数を調整し、積載率が８５％以上１００以下となるまで処理を繰り返す例を示した。したがって、全ての薬液を選択した場合にはＳ４０３の処理において使用量順位Ｎのものが選択不可となり、ＣＰＵ１０は、図１３ステップＳ３２３からの処理を行う。具体的には、図１５の例（Ｎ＝１〜５の薬液が抽出）ではＳ４２１の処理においてＮ＝６となった場合、Ｓ４０３の処理後に図１３ステップＳ３２３の処理を行う。

−−７．第２実施形態 〜最適出荷量設定処理〜−−
第２実施形態は、第１実施形態と同様の最適出荷量設定処理プログラムを実行するものである（図１３、図１４参照）。第２実施形態では、上述した図１３ステップＳ３１５において、積載率が１００％より大きいと判断された場合を説明する。したがって、以下の説明では、第１実施形態と相違する点のみを説明する。 管理サーバ１００のＣＰＵ１０は、図１３ステップＳ３１５において積載率が１００％より大きいと判断した場合には、ハードディスク１４に記録された出荷用トラック管理ＤＢ１３０を参照して、出荷量設定テーブル１５０に特別トラックのデータを追加して記録する（図１３ステップＳ３１７）。この処理によって、積載率１００％を超える出荷分に対して、定期トラック（Ｔ０２）の他に特別トラック（Ｔ０４）を割り当てることになる。

図１７は、第２実施形態における出荷量設定テーブル１５０の構成例を示す図である。図１７Ａは、Ｓ３０７、３０９、３１１、３１３の処理中の出荷量設定テーブル１５０の構成例を示す。ここでは、図１３ステップＳ３０３においてトラックＩＤ「Ｔ０２」が記録される例を示す。

ＣＰＵ１０は、Ｓ３１７の処理後、特別トラックのデータを追加した後の積載率を再度演算し、出荷量設定テーブル１５０の「積載率」のカラム情報を書き換える（Ｓ３１９）。図１７Ｂは、Ｓ３１７の処理後の出荷量設定テーブル１５０の構成例を示す。ここでは、図１３ステップＳ３１７においてトラックＩＤ「Ｔ０４」が追加して記録される例を示す。具体的には、図１７Ａにおいて積載率１２０％（＝（３００＋３００＋２００＋２００＋２００）／１０００）×１００）であった情報（トラックＴ０２の最大積載量：１０００）が、積載率６０％（＝（１２００／（１０００＋１０００））×１００）に書き換えられる（トラックＴ０４の最大積載量：１０００を加算して積載率を再度演算する）。

ＣＰＵ１０は、Ｓ３１９の処理後、Ｓ３１５からの処理を行う。ここでは、積載率６０％であるから、第１実施形態と同様、Ｓ３２１からの処理を繰り返すことになる。

図１７Ｃは、第２実施形態におけるＳ３２３の処理における出荷量設定テーブル１５０の構成例を示す。ここでは、クライアントＩＤ「Ａ００１」のＡ液、およびクライアントＩＤ「Ａ００２」のＡ液についての調整出荷量が設定されたうえで、積載率が８５％という出力結果になっている。図１８は、第２実施形態におけるＳ３２３の処理後のディスプレイ１３の画面表示例である。

−−８．実施形態による効果−−
実施形態は、上述したように複数の特徴を有しているが、各特徴についての効果として、例えば次の内容を挙げることができる。

実施形態によれば、管理サーバ１００（薬液供給メーカ側）において、供給先である各クライアントの薬液毎に自動で在庫管理を行うことができる。ここでいう在庫管理には、例えば、（１）分析信号（補給回数に対応する信号）に基づいてサイクル管理（建浴のタイミング）を把握可能であること（図１２ステップＳ２０９参照）、（２）サイクル完了信号によってクライアントに対して建浴のタイミングを報知可能であること、（３）在庫量および建浴量（または蓄積補給量）に基づいて判断時点での在庫量（リアルタイムでの在庫量）を演算可能であること（図１２ステップＳ２１３参照）、（４）現実の在庫量と在庫可能範囲との比較によって薬液の出荷タイミングを判断可能であること（図１３ステップＳ３０７参照）等が含まれる。

上記（３）に関しては、従来の技術では、補給液槽２２０内の補給液の残量や薬液在庫倉庫２１０の在庫量をオペレータが監視し、オペレータがその在庫量が少ないと判断した場合に、薬液供給メーカに対して薬液の発注を行うことを介して在庫の補充を行っていた。したがって、めっき処理の安定操業の観点から、補給液槽２２０の容量を大きくしたり、補給液の消耗量の増減を見越して補給液の在庫を多めにする傾向があった。

この点、実施形態によれば、薬液の在庫量、使用量等を管理サーバ１００側で自動で管理することが可能であり、クライアント側でのめっき処理を安定して実行することが可能である。

また、めっき槽は、長く使用すると不純物が混入したり、めっき反応で副生成物が生成したりするため、ある一定期間を過ぎるとめっきラインを停止させて槽全体のめっき浴を新しいめっき液に交換する（建浴しなおして更新）する必要がある。このような建浴作業に関しても、従来はクライアント側で建浴のタイミング等を判断する必要があった。

この点、実施形態によれば、上記（１）および（２）で述べたように、補給回数（ターン数）に基づいてサイクル管理（建浴のタイミング）を把握可能であるとともに、所定の信号によってクライアントに対して建浴のタイミングを報知可能である。したがって、適切なタイミングで建浴が実行されるという観点からも、クライアント側でのめっき処理が安定するというメリットがある。

実施形態によれば、管理サーバ１００は、１回の出荷量を、トラック積載量の所定範囲内に収めるように自動調整することによって、１以上のクライアントに対する薬液の輸送効率を高めることができる（図１３、図１４参照）。

実施形態によれば、管理サーバ１００は、上記積載量の自動調整において、使用量順位の高い薬液から順番に出荷量を上乗せする処理（調整出荷量設定処理）を行う（図１４ステップＳ４０３参照）。ここで、使用量順位の高い薬液とは、一般的には、クライアントにおける在庫可能範囲を最短期間で下回ることが予想される薬液である。したがって、実施形態では、そのような使用頻度が高い薬液についていわゆる見込み発送を行うことによって、必要最低在庫量を確保できる期間を長く保証する一方で、上述のように出荷時の薬液の輸送効率を高めることができるというメリットがある。

実施形態では、図９の出荷用トラック管理ＤＢ１３０における「輸送単価」の情報と、図７のクライアント管理ＤＢ１１０における「出荷距離」の情報とに基づき、「輸送コスト」の情報を出力することとしている（図１５、図１６、図１７、図１８参照）。具体的には、輸送コスト＝輸送単価×出荷距離で演算される。実施形態では、便宜上、薬液供給メーカからの出荷距離が最長のものを「出荷距離」として設定している。例えば、図１６においては、クライアントＩＤ「Ａ００１」の出荷距離３００ｋｍを採用し、往復６００ｋｍとして輸送コストを演算している。

−−９．その他の実施形態等−−
９−１．最適出荷量設定処理のバリエーション
実施形態では、トラックの積載量を基準にして最適出荷量を設定する例を示した。最適出荷量を設定する実施形態はこれに限らず、次のような実施形態を採用してもよい。

図７のクライアント管理ＤＢ１１０において、クライアントの所在地が近いものについてあらかじめグループ設定しておく。図７の例では、Ｘ社、Ｙ社、Ｚ社、Ｖ社についてはそれぞれ岐阜県、三重県、滋賀県、愛知県であり、薬液供給メーカ（所在地：大阪を想定）からみて上り方面（東側）に所在する。一方、Ｗ社、Ｑ社についてはそれぞれ兵庫県、岡山県であり、薬液供給メーカからみて下り方面に所在する。以上より、Ｘ社、Ｙ社、Ｚ社、Ｖ社をＡグループ、Ｗ社、Ｑ社をＢグループとして設定する。各設定は、クライアントＩＤのアルファベットによってＣＰＵが識別可能である。

グループ設定に基づき、管理サーバ１００のＣＰＵ１０は、各グループ毎に図１３、図１４の最適出荷量設定処理を実行する。この場合、ＣＰＵ１０は、図１３ステップＳ３０１の処理において管理サーバ１００のユーザによるグループ設定入力を受け付けるようにすればよい。以上のような処理により、ＣＰＵ１０は、トラックの積載量および発送経路の両者を考慮した最適出荷量の出力を行うことができる。さらに、グループ設定によって出荷距離を低く抑えることができるので、輸送コストの削減にもつながるというメリットがある。

その他、輸送コストに関しては、いわゆるカーナビゲーションシステムの導入による最適出荷経路の選択や、トラックへの薬液の積み方の工夫によって低減させることも可能である。

９−２．装置構成バリエーション
実施形態では、管理サーバ１００が薬液管理ＤＢ１２０を備えることとしたが、これに限られるものではなく、顧客側コンピュータ２００が薬液管理ＤＢ１２０を備えるようにしてもよい。具体的には、顧客側コンピュータ２００のＣＰＵ２０が、薬液管理処理（図１１参照）および薬液管理ＤＢ更新処理（図１２参照）の両処理を実行する。管理サーバ１００のＣＰＵ１０が最適出荷量設定処理を実行する際には、ＣＰＵ１０は、各クライアントの顧客側コンピュータ２００にアクセスして薬液管理ＤＢ１２０の記録内容を取得するようにすればよい。

実施形態では、「端末装置」として顧客側コンピュータ２００を例示したが、これに限られるものではなく、Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ（ＰＤＡ）等のモバイル端末等のその他の機器を利用してもよい。

９−３．プログラム実行方法等の実施例
本実施形態では、ＣＰＵ１０、ＣＰＵ２０の動作のためのプログラムを、それぞれハードディスク１４、ハードディスク２４に記憶させているが、このプログラムは、プログラムが記憶されたＣＤ−ＲＯＭから読み出してハードディスク等にインストールすればよい。また、プログラムは、ＣＤ−ＲＯＭ以外に、ＤＶＤ−ＲＯＭ、またはフレキシブルディスク（ＦＤ）、またはＩＣカード等のコンピュータ可読の記録媒体からインストールするようにしてもよい。さらに、通信回線を用いてプログラムをダウンロードさせることもできる。また、ＣＤ−ＲＯＭからプログラムをインストールすることにより、ＣＤ−ＲＯＭに記憶させたプログラムを間接的にコンピュータに実行させるようにするのではなく、ＣＤ−ＲＯＭに記憶させたプログラムを直接的に実行するようにしてもよい。

なお、コンピュータによって実行可能なプログラムとしては、ＣＰＵによって直接実行可能なプログラムだけではなく、ソース形式のプログラム、一旦他の形態等に変換が必要なもの（例えば、圧縮処理がされたプログラム、暗号化プログラム）、さらには、他のモジュール部分と組合して実行可能なプログラムも含む。

上記各実施形態では、図４の各機能をＣＰＵおよびプログラムによって実現することとしているが、各機能の一部または全部をハードウェアロジック（論理回路）によって構成してもよい。

実施形態によるめっき液管理システムの全体図である。 めっき液等の供給・補給の概要を示す模式図である。 めっき液管理システムの処理概要図である。 めっき液管理システムの機能ブロック図である。 管理サーバのハードウェア構成例を示す図である。 顧客側コンピュータのハードウェア構成例を示す図である。 クライアント管理データベースの構成例を示す図である。 薬液管理データベースの構成例を示す図である。 出荷用トラックデータベースの構成例を示す図である。 出荷量設定テーブルの構成例を示す図である。 実施形態による薬液管理処理のフローチャートである。 実施形態による薬液管理データベース更新処理のフローチャートである。 第１実施形態による最適出荷量設定処理のフローチャートである。 第１実施形態による最適出荷量設定処理（調整出荷量設定処理）のフローチャートである。 図１５Ａ、図１５Ｂ、図１５Ｃは、第１実施形態における出荷量設定テーブルの構成例を示す図である。 図１６Ａ、図１６Ｂは、第１実施形態における管理サーバの画面表示例である。 図１７Ａ、図１７Ｂ、図１７Ｃは、第２実施形態における出荷量設定テーブルの構成例を示す図である。 図１８は、第２実施形態における管理サーバの画面表示例である。

符号の説明

１００・・・管理サーバ
１１０・・・クライアント管理データベース
１２０・・・薬液管理データベース
１３０・・・出荷用トラック管理データベース
１５０・・・出荷量設定テーブル
２００・・・顧客側コンピュータ
２１０・・・薬液在庫倉庫
２３０・・・めっき槽

Claims (12)

1. 原材料供給量管理装置と、当該原材料供給管理装置と通信可能であって、原材料の供給先における端末装置とを備えた原材料供給量管理システムであって、
   前記原材料供給量管理装置は、
   供給先における各原材料の在庫可能範囲データを取得する在庫可能範囲データ取得手段、
   供給先における各原材料の供給量データを取得する供給量データ取得手段、
   供給先における各原材料の使用量データを取得する使用量データ取得手段、
   前記供給量データと使用量データとの差分に基づいて実質在庫量を演算する在庫量演算手段、
   前記在庫可能範囲と実質在庫量とを参照して追加供給量を判断し、当該追加供給量を供給内容として決定する追加供給量決定手段、
   を備えており、
   前記端末装置は、
   前記原材料供給量管理装置に対して、各原材料の前記使用量データを送信する送信手段、
   を備えたことを特徴とする原材料供給量管理システム。
2. 供給先に対する原材料の供給量を管理する原材料供給量管理装置であって、
   前記原材料供給量管理装置は、
   供給先における各原材料の在庫可能範囲データを取得する在庫可能範囲データ取得手段、
   供給先における各原材料の供給量データを取得する供給量データ取得手段、
   供給先における各原材料の使用量データを取得する使用量データ取得手段、
   前記供給量データと使用量データとの差分に基づいて実質在庫量を演算する在庫量演算手段、
   前記在庫可能範囲と実質在庫量とを参照して追加供給量を判断し、当該追加供給量を供給内容として決定する追加供給量決定手段、
   を備えたことを特徴とする原材料供給量管理装置。
3. コンピュータを、
   供給先における各原材料の在庫可能範囲データを取得する在庫可能範囲データ取得手段、
   供給先における各原材料の供給量データを取得する供給量データ取得手段、
   供給先における各原材料の使用量データを取得する使用量データ取得手段、
   前記供給量データと使用量データとの差分に基づいて実質在庫量を演算する在庫量演算手段、
   前記在庫可能範囲と実質在庫量とを参照して追加供給量を判断し、当該追加供給量を供給内容として決定する追加供給量決定手段、
   として機能させるためのコンピュータ読取可能なプログラム。
4. 請求項１〜３のいずれかの原材料供給量管理装置システム、または原材料供給量管理装置、またはプログラムにおいて、さらに、
   前記追加供給量決定手段は、さらに、
   前記在庫量演算手段が演算する実質在庫量が前記在庫可能範囲の下限を下回るか否かを判断し、前記在庫可能範囲の下限を下回ると判断された原材料に限定して、前記追加供給量を判断すること、
   を特徴とするもの。
5. 請求項１〜４のいずれかの原材料供給量管理システム、または原材料供給量管理装置、またはプログラムにおいて、
   前記原材料供給量管理装置は、さらに、
   原材料の供給に利用する輸送手段が輸送可能な輸送可能範囲に関連する輸送可能範囲データを取得する輸送可能範囲データ取得手段、
   を備えており、
   前記追加供給量決定手段は、さらに、
   追加供給の対象となる原材料の前記追加供給量の合計量を演算し、当該合計量が輸送可能範囲の下限を下回っていると判断した場合には、選択された特定原材料について、当該特定原材料の前記在庫可能範囲と実質在庫量とを参照して補充追加供給量を判断するとともに、当該補充追加供給量の追加によって合計量が前記輸送可能範囲内となるか否かを判定し、輸送可能範囲内となる場合には、当該補充追加供給量と前記追加供給量との組み合わせを供給内容として決定すること、
   を特徴とするもの。
6. 請求項５のいずれかの原材料供給量管理システム、または原材料供給量管理装置、またはプログラムにおいて、
   前記原材料供給量管理装置は、さらに、
   前記追加供給量決定手段が、前記合計量が輸送可能範囲の上限を上回っていると判断した場合には、前記輸送手段を追加するものとして前記輸送可能範囲データを変更する輸送可能範囲データ変更手段、
   を備えたことを特徴とするもの。
7. 請求項５または６のいずれかの原材料供給量管理システム、または原材料供給量管理装置、またはプログラムにおいて、
   前記原材料供給管理装置は、さらに、
   前記使用量データに基づいて演算される各原材料の使用履歴量の比較結果を取得し、当該比較結果に基づいて前記特定原材料を選択する特定原材料選択手段、
   を備えたことを特徴とするもの。
8. 請求項７のいずれかの原材料供給量管理システム、または原材料供給量管理装置、またはプログラムにおいて、
   前記特定原材料選定手段は、前記使用履歴量が大きい原材料を前記特定原材料として選択すること、
   を特徴とするもの。
9. 原材料供給管理装置と通信可能な端末装置であって、
   前記端末装置は、
   前記原材料供給量管理装置に対して、各原材料の使用量データを送信する送信手段、
   を備えたことを特徴とする端末装置。
10. 原材料供給管理装置と通信可能なコンピュータを機能させるプログラムであって、
    コンピュータを、
    前記原材料供給量管理装置に対して、各原材料の使用量データを送信する送信手段、
    として機能させるためのコンピュータ読取可能なプログラム。
11. 請求項１、または９、または１０のいずれかの原材料供給量管理システム、または端末装置、またはプログラムにおいて、
    前記端末装置は、さらに、
    前記原材料の使用量データを取得するために、前記原材料の使用量を監視する使用量監視手段、
    を備えたことを特徴とするもの。
12. 供給先に対する原材料の供給量を管理する原材料供給量管理方法であって、
    前記原材料供給量管理方法は、
    供給先における各原材料の在庫可能範囲データを取得し、
    供給先における各原材料の供給量データを取得し、
    供給先における各原材料の使用量データを取得し、
    前記供給量データと使用量データとの差分に基づいて実質在庫量を演算し、
    前記在庫可能範囲と実質在庫量とを参照して追加供給量を判断し、当該追加供給量を供給内容として決定すること、
    を特徴とする原材料供給量管理方法。
    

Images