(57)【要約】【課題】商品の販売から廃棄に至るまでの情報を有効に利用する。【解決手段】商品を発注する際、契約ＩＤと商品コードを含む発注リストデータを配送会社の伝票管理サーバに送信する。伝票管理サーバは商品コードに機番を紐付け、契約ＩＤと、発注を行った旨のステータス情報と共に機器管理テーブルに記録する。発注というアクションに呼応して、商品を一意に特定する情報が機器管理テーブルに記録される。【選択図】図１
2008250515.tif 000002
【特許請求の範囲】
【請求項１】
商談を一意に識別する商談ＩＤを含む商談テーブルと、
前記商談テーブルの一つのレコードについて一つ以上関連付けられる契約について、前記契約を一意に識別する契約ＩＤを含む契約テーブルと、
前記契約テーブルの一つのレコードについて一つ以上関連付けられる商品について、前記商品を一意に識別する商品コードを含む契約商品等テーブルと、
前記契約ＩＤと、前記商品コードと、前記商品である機器の機番と、前記機器のステータスと、日付をフィールドとして持つ機器管理テーブルと、
前記契約ＩＤと前記商品コードを含む発注リストデータを作成する発注部と、
前記発注リストデータから伝票を作成すると共に、前記契約ＩＤ及び前記商品コードと対応する前記機番を紐付けて前記機器管理テーブルに記録する伝票作成部と
を具備することを特徴とする、機器管理装置。
【請求項２】
前記機器のステータスは、機器の稼動状態を示す機器稼動ステータスと、機器の移動状態を示す機器物流ステータスを含むものであり、
前記機器管理テーブルは更に、前記機器の設置先を示す設置先ＩＤを含むものであることを特徴とする、請求項１記載の機器管理装置。
【請求項３】
商談を一意に識別する商談ＩＤを含む商談テーブルと、
前記商談テーブルの一つのレコードについて一つ以上関連付けられる契約について、前記契約を一意に識別する契約ＩＤを含む契約テーブルと、
前記契約テーブルの一つのレコードについて一つ以上関連付けられる商品について、前記商品を一意に識別する商品コードを含む契約商品等テーブルと、
前記契約ＩＤと、前記商品コードと、前記商品である機器の機番と、前記機器のステータスと、日付をフィールドとして持つ機器管理テーブルと
を具備するテーブル管理サーバと、
前記テーブル管理サーバから前記契約ＩＤと前記商品コードを読み出して、発注リストデータを作成して送信する発注サーバと、
前記発注リストデータを受信して伝票を作成すると共に、前記テーブル管理サーバに対し、前記契約ＩＤ及び前記商品コードと対応する前記機番を紐付けて前記機器管理テーブルに記録する伝票作成サーバと
を具備することを特徴とする、機器管理システム。
【請求項４】
前記機器のステータスは、機器の稼動状態を示す機器稼動ステータスと、機器の移動状態を示す機器物流ステータスを含むものであり、
前記機器管理テーブルは更に、前記機器の設置先を示す設置先ＩＤを含むものであることを特徴とする、請求項３記載の機器管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、商品の商談から販売、運用そして廃棄等に至るまでを管理する、機器管理システムに適用して好適な技術に関する。
【背景技術】
【０００２】
多くの場合、商品は、生産、在庫、商談、契約、発注、納入、運用、廃棄という経緯を辿る。
生産については、生産現場、つまり工場において生産する商品の個数やシリアルナンバー（機番）を管理するシステムを運用する。
在庫と発注については、配送会社が倉庫に収められる商品の個数や機番を管理するシステムを運用する。
商談と契約、そして納入については、販売会社の営業担当者が顧客に商談をもちかけ、商談を成立させる際に、商談及びこれに付随して発生する契約、そしてその契約にかかる商品を管理するシステムを運用する。
運用と廃棄については、商品納入後、商品のメンテナンス等にかかる役務を担当するサービス会社が、商品の機番と、発生した役務を管理するシステムを運用する。
業務形態によってはこれら業務が別々の会社で行われたり、複数の業務が一つの会社で行われたりすることもある。
ここで注目すべき点は、各々の業務において、それぞれ独立した管理システムが運用されている、ということである。
【０００３】
なお、本発明の先行技術文献として、特許文献１を示す。
【特許文献１】特開２００６−３２３７７１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
前述した、各々の管理システムは、商品に関し、単一或は少数の、自己の業務に関する事象だけが記録され、管理される。このため、ある時点である商品に何らかのトラブル等が発生し、その商品に関する情報を遡って検証をしたい場合等に、これら分散されたシステムは非常に使い勝手が悪い。
また、システムを跨った情報の入力が人手を伴うため、入力間違い、タイムラグを伴う等、これもまた使い勝手が悪い。
更に、商品が今どのような状態にあるのかを示す情報を俯瞰的に取得し、統計を取る等の情報活用ができない、という問題も生じる。
【０００５】
本発明はかかる点に鑑みてなされたものであり、前述したような、機器に対して時系列的に関わる複数の業務を縦断する形で、機器の情報を取得し管理する、機器管理システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するための本発明は、商談を商談ＩＤを伴って商談テーブルに格納し、商談と一対多の関係にある契約を契約ＩＤを伴って契約テーブルに格納し、契約と一対多の関係にある商品を商品コードを伴って契約商品等テーブルに格納する。
そして、発注部にて契約ＩＤと商品コードを含む発注リストデータを作成し、伝票を作成すると共に、契約ＩＤと商品コードに対応する機番を紐付けて、機器管理テーブルに記録するものである。
【０００７】
顧客に販売する機器の全てを、商品コードと機番にて一意に識別し、その機器に生じた事象をステータス情報にて記録する、機器の一生をログ記録するテーブルを設けた。
そして、商品の発注という業務に付随して、機番をシステムに登録する仕組みを設けた。
【発明の効果】
【０００８】
本発明により、商談から廃棄に至るまでの複数の業務を縦断する形で、機器の情報を取得し管理する、機器管理システムを提供できる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施の形態を、図１〜図１１を参照して説明する。
【００１０】
図１は、本実施の形態の例である、機器管理システムの全体を示す概略図である。
本実施形態の機器管理システム１０１は、幾つかのｗｅｂサーバ１０２及び１０３と、データベースサーバ（以下「ＤＢサーバ」）１０４と、これらにアクセスする多くのクライアントＰＣ１０５、１０６及び１０７よりなる。また、クライアントＰＣに類する端末として、ハンディターミナル１０８もある。
社内ＬＡＮ１０９は周知のプライベートＩＰアドレスを主体とするＴＣＰ／ＩＰネットワークを構成し、グループ会社をも網羅するものである。
クライアントＰＣ１０５は典型的なパソコンであり、ｗｅｂサーバ１０２にアクセスするための、図示しないｗｅｂブラウザを稼動させている。
ｗｅｂサーバ１０２はそれらグループ会社毎、或は担当業務毎に分離され、分散されている。
【００１１】
クライアントＰＣ１０５はｗｅｂサーバ１０２にアクセスする。
ｗｅｂサーバ１０２はＤＢサーバ１０４にアクセスする。
つまり、ｗｅｂサーバ１０２はクライアントＰＣ１０５に対してＤＢサーバ１０４にアクセスする際のユーザインターフェースを提供する。
【００１２】
ｗｅｂサーバ１０２及び１０３とＤＢサーバ１０４は、負荷分散や安全確保等を目的として、また安全確保のための二重化等の構築を容易にするため、それぞれ分散されている。
勿論、システムの規模が小さい場合には、これらを一体化することもできる。
【００１３】
図２は、ｗｅｂサーバ１０２等とＤＢサーバ１０４の詳細を示す機能ブロック図である。
ｗｅｂサーバ１０２は、ｗｅｂサーバプログラム２０２と、多くのｃｇｉ（Common Gateway Interface：ｗｅｂサーバがｗｅｂブラウザの要求に応じて、プログラムを起動するための仕組み。）を内包する。
各々のｃｇｉは、社内ＬＡＮ１０９にアクセス可能な従業員を認証するための従業員認証ｃｇｉ２０３を始め、各種ユーザインターフェースを構成するｈｔｍｌ文書を作成するｃｇｉが存在する。
ＤＢサーバ１０４は機器管理システム１０１の中心的な役割を担う、各種データを格納するテーブルを多数備えている。図２ではその一部を示している。
ＤＢサーバ１０４は周知のＳＱＬ（リレーショナルデータベースの操作に特化された言語。）サーバを構成する。
【００１４】
図３は、ＤＢサーバ１０４に含まれているテーブル群のフィールド名を一部抜粋した概略図である。
従業員テーブル３０２は、従業員を一意に識別する、従業員ＩＤを中心とするテーブルである。フィールドには、「従業員ＩＤ」の他に、従業員の「氏名」と「所属」を示すフィールド等が存在する。また、図示はしないがパスワードのハッシュ値等も含まれ、従業員のログイン認証等に用いられる。
【００１５】
顧客企業テーブル３０３は、顧客企業を一意に識別する、顧客ＩＤを中心とするテーブルである。フィールドには、「顧客ＩＤ」の他に、「顧客企業名」を示すフィールド等が存在する。クライアントＰＣ１０５の表示画面上に所望の顧客企業名を表示させる場合は、このテーブルから「顧客企業名」フィールドの値を取得する。
顧客担当者テーブル３０４は、顧客担当者を一意に識別する、担当者ＩＤを中心とするテーブルである。「担当者ＩＤ」の他に、顧客担当者の「担当者名」と、顧客企業を識別するための「顧客ＩＤ」フィールドが存在する。
顧客設置先テーブル３０５は、顧客に販売した機器を設置する際の設置場所（設置先）を一意に識別する、設置先ＩＤを中心とするテーブルである。「設置先ＩＤ」の他に、「設置場所」と「顧客ＩＤ」フィールドが存在する。
【００１６】
商談テーブル３０６は、商談を一意に識別する、商談ＩＤを中心とするテーブルである。営業担当者が顧客と商談を始めた際に、新規なレコードを起こす。フィールドは、
・「商談ＩＤ」の他に、
・商談の詳細内容の一つとして、商談を開始した日付を示す「商談日付」フィールドや、
・商談の進行状況、またその成果（仮契約、契約成立、契約失敗等）を示す「商談ステータス」フィールド、そして
・顧客企業テーブルの「顧客ＩＤ」、
・顧客担当者テーブルの「担当者ＩＤ」、
・従業員テーブルの「従業員ＩＤ」
が存在する。
【００１７】
契約テーブル３０７は、契約を一意に識別する、契約ＩＤを中心とするテーブルである。一契約につき、一つの新規なレコードを起こす。フィールドは、
・「契約ＩＤ」の他に、
・契約の種別を示す「契約種別ＩＤ」や、
・契約の詳細内容の一つとして、契約を作成した日付を示す「契約日付」フィールド、
・契約の進行状況、またその成果（仮契約、契約成立、契約失敗等）を示す「契約ステータス」フィールド、
・正式に発行された契約書の発行回数を格納する「発行回数ステータス」
が存在する。
【００１８】
商談契約テーブル３０８は、商談と契約との一対多の関係を記述する、「商談ＩＤ」と「契約ＩＤ」の組よりなるテーブルである。つまり、一つの商談について、複数の契約が発生し得る。このテーブルの存在により、契約ＩＤから商談ＩＤ、またその逆の参照が可能になっている。
【００１９】
禁則条件テーブル３０９は、営業担当者が商談を進める際に作成する見積もりにおいて、一緒に販売してはいけない商品や役務の組み合わせを記述するテーブルである。後述する商品基本情報テーブル３１２の「商品コード」或は役務基本情報テーブルの「役務コード」同士の組み合わせが列挙される。
【００２０】
締め日条件テーブル３１０は、コピー機等のカウンタを確認する作業の締め日に関する契約条件を記述するテーブルである。フィールドは、
・その機器がどの契約に属するかを示す「契約ＩＤ」と、
・機器を特定する「商品コード」と
・機器のシリアルナンバー（以下「機番」と呼ぶ。詳細は後述する。）の他に、
・契約の詳細内容の一つとして、締め日の条件を示す「締め日条件」フィールドと、
・「締め日条件」の優先順位を示す「優先順位」フィールド
が存在する。
【００２１】
契約種別テーブル３１１は、契約の種別を列挙するテーブルである。フィールドは、「契約種別ＩＤ」と「契約種別名」が存在する。
【００２２】
商品基本情報テーブル３１２は、商品を一意に識別する、商品コードを中心とするテーブルである。各々の商品を識別するための「商品コード」の他に、「商品名」「商品詳細情報」フィールド等が存在する。
役務基本情報テーブル３１３は、役務を一意に識別する、役務コードを中心とするテーブルである。各々の役務を識別するための「役務コード」の他に、「役務名」「役務詳細情報」フィールド等が存在する。
【００２３】
商品等構成テーブル３１５は、商品または役務と商品との一対多の関係を記述する、「商品コード」または「役務コード」と、「商品コード」または「役務コード」の組よりなるテーブルである。
例えば、コピー機本体には、ソーター、自動両面原稿送り装置、ステープラ等のハードウェアオプション品、またファクシミリ機能、プリンタ機能、スキャナ機能を実現するソフトウェアオプション品等が存在する。更に、当該コピー機に適用可能な保守サービスも存在する。このように、商品の中にはオプションとなる商品又は役務を含むものもある。
また、例えば「安心パック」という名称で、パソコンのメンテナンスサービスとウイルス防御ソフトウェア商品の提供を含む役務が考えられる。このように、役務の中には商品を含むものもある。
以上のような、商品または役務のシステム的構成を記述するために、このようなテーブルを設けている。
【００２４】
契約商品等テーブル３１４は、契約と商品或は役務との一対多の関係を記述する、「契約ＩＤ」と「商品コード」或は「役務コード」の組よりなるテーブルである。つまり、一つの契約について、複数の商品或は役務が発生し得る。また、このテーブルには「機番」と「設置先ＩＤ」等のフィールドが存在する。
【００２５】
機器管理テーブル３１６は本実施形態において中核的な役割を担うテーブルである。
一つの機器（商品）について、「商品コード」と「機番」にて一意に識別し、その機器の顧客に対する納入から、機器の廃棄或はリサイクルまで、「機器の一生」を日付とステータス情報にて逐一記録し、管理するテーブルである。フィールドは、
・「商品コード」と
・「機番」の他に、
・この機器が属する契約を示す、契約テーブル３０７の「契約ＩＤ」、
・この機器が設置されている場所を示す、顧客設置先テーブル３０５の「設置先ＩＤ」、
・この機器の状態を示す「機器稼動ステータス」と
・「機器物流ステータス」、そして
・それらステータス情報を記録した「日付」
が存在する。
【００２６】
カウンタ確認ログテーブル３１７は、主にコピー機に内蔵されている、使用の度にインクリメントされる「カウンタ」の数値を記録するテーブルである。コピー機は使用回数、つまりコピー出力によって消費される用紙の枚数に応じて、使用量が課金される仕組みになっている。そこで、毎月決まった締め日に、コピー機に内蔵されているカウンタの値を確認し、カウンタ確認ログテーブル３１７に記録する。フィールドは、
・「商品コード」と
・「機番」の他に、
・この機器が属する契約を示す、契約テーブル３０７の「契約ＩＤ」、
・「カウンタ値」と
・カウンタ値を取得した状態を示す「カウンタステータス」
が存在する。
【００２７】
契約書テンプレートテーブル３１８は、契約書に必要な雛形のパーツを識別するパーツコードと、テンプレートを識別するテンプレートコードを記録するテーブルである。パーツコードとテンプレートコードに対応する契約書の雛形がテンプレートファイルとして契約書テンプレートテーブル３１８に記録される。
契約書は、以下に記載する５つのパーツが組み合わされて作成される。ただし、ある契約書では必要とされるが、別の契約書では必要とされないパーツも存在する。これら５つのパーツを「基本パターン」とも称する。
・「表紙」…甲乙などの契約関係を表現するパーツ。
・「基本条項」…販売にあたって必要な「基本条項」を表現するパーツ。
・「サービス条項」…モノ（例えば、コピー機、ＰＣ）ではなく、保守サービスなどの付加価値に対する「基本条項」を表現するパーツ。
・「契約料金」…見積時の料金を表現するパーツ。
・「保守対象明細」…保守サービスを契約する場合は、そのサービスは何に対して行うのかを表現するパーツ。
【００２８】
図４は、機器管理テーブル３１６に含まれる、機器稼動ステータスと機器物流ステータスの凡例を示す表である。
機器稼動ステータスは、顧客に納入した機器がどのような状態であるかを示すステータス情報である。「未稼働」「稼働中」「一時停止」「停止」の四つがある。
機器物流ステータスは、顧客に納入した機器がどこにあるかを示すステータス情報である。「出荷完了」「納品完了」「納品仮完了」「設置完了」「回収予定」「解体完了」「保管完了」「回収完了」「検品完了」「移動申請中」「移動予定」「移動完了」の十二個がある。
【００２９】
［商談支援］
営業担当者が顧客に商品を売る際、複数の商品や役務を組み合わせて販売することが多くある。
例えば、企業の情報システムの場合は、サーバ、ネットワーク機器、クライアントＰＣ１０５、それらのためのソフトウェア等をセットにして販売する他、それらのメンテナンスの役務も含め、セット販売することが考えられる。
役務の内容によっては、既にソフトウェア等の商品が含まれている場合もある。
つまり、商品構成によっては商品が重複してしまったりすることが考えられる。
また、多くの商品等を購入して貰っている上得意先の場合、既に購入済みの商品等と重複したり、組み合わせてはいけないものを選ばないようにしなければならない。
このため、機器管理テーブル３１６から顧客の過去の購入情報を読み込み、それらと組み合わせてはいけない商品等を禁則条件テーブル３０９から読み出し、見積もりデータから除外する。
【００３０】
［契約書作成支援］
見積書を作成して顧客に提示したら、顧客はその内容に対し、導入するか否かを判断し、営業担当に回答する。
見積書にて作成した商品構成に応じて、選択可能な契約の組み合わせがメニューとして提示される。
顧客が所望の契約内容を選択したら、契約テーブル３０７に契約書を作成するに必要な情報、特に各種条件を示すフラグ情報群を記録し、契約書の雛形を選択的に読み出し、契約書を自動作成する。
また、このときに作成される契約書の条件情報は、販売する機器によっては締め日条件テーブル３１０にその条件を書き出し、カウンタ確認ログテーブル３１７を用いたカウンタ確認督促処理に使用される。
【００３１】
［機器管理］
商談が成立し、いよいよ顧客に商品を出荷する段になったら、営業担当は商談成立をｗｅｂサーバ１０２を通じて入力する。
すると、商談テーブル３０６のステータスが変更され、これに呼応して商品を発注するための商品発注依頼データが、契約テーブル３０７及び契約商品等テーブル３１４から作成され、配送会社が管理する伝票管理サーバに送信される。
伝票管理サーバは商品発注依頼データを受信すると、伝票テーブルに新規に伝票番号を起こし、受信した商品コードを記録する。そして、在庫テーブルに格納されている商品の機番を読み出し、伝票テーブルに記録する。こうして商品コードと機番の関係付けが行われる。なお、これ以降、二つ以上のテーブルの共通するフィールドについて関係付けることを「紐付け」と呼ぶ。
次に、伝票管理サーバは機番をＤＢサーバ１０４の契約商品等テーブル３１４に記録する。そして、機器管理テーブル３１６に新規にレコードを追加し、ステータス情報を記録する。こうして、「当該商品を設置先に出荷した」情報が、機器管理テーブル３１６に記録され、機器の管理が始まる。
これ以後は、役務等の作業が発生する度に、ハンディターミナル等を用いて商品コードと機番を入力することで機器が特定され、日付とステータス情報が追記録される。このような「機器の状態の記録」が、機器の廃棄或はリサイクルによる消滅まで行われる。
【００３２】
［カウンタ確認］
毎月の締め日の前にはコピー機のカウンタの値を確認しなければならない。
ところが、顧客によっては締め日までにカウンタ値を確認できない場合もある。
そのようなときには、予め契約書を作成する際に作成していた、締め日条件テーブル３１０に記録されている「アクション条件」を参照する。
締め日から何日経ったらどのようなカウンタ確認作業をするのか、そしてその作業は既に完遂したのか否かを確認し、適切な指示を担当者に提示する。
【００３３】
［買い替え阻止］
顧客に対する他社の売り込みにより、販売した機器がリプレースされてしまうと、顧客を失うこととなる。これを予防するために、対象契約におけるリース契約解除の際に、リース会社に対して契約解除の手数料の問い合わせが発生した事実を、リース会社担当者がシステムに入力する。
入力のアクションにより、契約テーブル３０７から営業担当者が特定され、当該営業担当者がクライアントＰＣ１０５にて情報システムにアクセスすると、ワーニングメッセージとしてその情報を表示する。
所定の営業活動を行った後に、そのワーニングメッセージは消去される。
【００３４】
以上の概略説明にてわかるように、本実施形態の機器管理システム１０１は、商談から契約、商品の納入、商品の運用、買い替えの予防、そして廃棄に至る迄の、「商品の一生」を営業的側面から管理すると共に、営業活動等を支援する総合的なシステムである。
【００３５】
［機器管理の詳細］
図５は、本実施形態の機器管理システム１０１のうち、機器管理機能に注目した部分の機能を説明するブロック図である。
販売会社に勤務する営業担当者５０１は、クライアントＰＣ１０７を操作して、販売会社に設置されている販売管理ｗｅｂサーバ５０２にアクセスする。
販売管理ｗｅｂサーバ５０２は、クライアントＰＣ１０７から来るアクセス要求（ＨＴＴＰリクエストメッセージ）に呼応して、所定の処理を行う。
所定の処理の内容によっては、ＤＢサーバ１０４内に格納されている各種テーブルに対し、ＳＱＬの規格に則ったデータ取得或は書き込み等のアクセスを行う。発注ｃｇｉ５０４から各テーブルに伸びている矢印の線がこれに該当する。これらは概念的な線ではあるが、実際は図１に示したように、ｗｅｂサーバ１０２とＤＢサーバ１０４は社内ＬＡＮ１０９に接続されており、矢印にて示されるこれらアクセス動作は、社内ＬＡＮ１０９を通じて行われる。
【００３６】
販売管理ｗｅｂサーバ５０２には、ｗｅｂサーバプログラム２０２と発注ｃｇｉ５０４が含まれている。ｃｇｉはこれ以外にも多数存在するが、図５では本実施形態において直接的に関係するものだけを抜粋して記載している。
ｗｅｂサーバプログラム２０２はＨＴＴＰのサーバを構成する。ＴＣＰ／ＩＰネットワークである社内ＬＡＮ１０９を通じて来るクライアントの要求（ＨＴＴＰリクエストメッセージ）に応じ、ｈｔｍｌ文書や、ｃｇｉの実行結果を、ＨＴＴＰレスポンスメッセージの形式にて送信する。一例としてはＡｐａｃｈｅ(http://www.apache.org/)等である。
発注ｃｇｉ５０４は、クライアントＰＣ１０７のｗｅｂブラウザにて表示されるｈｔｍｌ文書を作成する。
また、発注ｃｇｉ５０４はＳＱＬクライアントの機能を含み、ＤＢサーバ１０４の各テーブルにアクセスし、所望のデータを取得する。
更に、発注ｃｇｉ５０４は、後述する伝票管理サーバ５０５に対するｗｅｂクライアントの機能を含み、伝票管理プログラム５０６へ、後述する発注データの送信処理を行う。
【００３７】
なお、発注リスト作成部６０６及び発注リスト送信部６０７から従業員等識別部６０２に向けて書かれている矢印は、各々の処理が完遂したか否かを報告することを意味するものである。
従業員等識別部６０２は、ＨＴＴＰリクエストメッセージがＰＯＳＴメソッドであり、発注を実行するものであると判断すると、ｈｔｍｌ文書作成部６０３に対し、クライアントに「発注処理中、暫くお待ちください」等のメッセージを表示するｈｔｍｌ文書を作成する命令を下す。
次に、発注リスト作成部６０６が発注リストの作成を完遂したら、その旨を示す「発注リスト作成済み、これより発注リスト送信開始、暫くお待ちください」等のメッセージを表示するｈｔｍｌ文書を作成する命令を下す。
最後に、発注リスト送信部６０７が発注リストの送信を完遂したら、その旨を示す「発注リスト送信を完了しました。」等のメッセージと、発注処理前の画面に移動するボタンを表示するｈｔｍｌ文書を作成する命令を下す。
【００３８】
ＤＢサーバ１０４は前述の通り、周知のＳＱＬサーバを構成する。図５においては、発注ｃｇｉ５０４と後述する伝票管理プログラム５０６が扱うテーブルを明確にするため、ＳＱＬサーバのプログラム部分は標記を省略している。実際のＤＢサーバ１０４は、入力されるＳＱＬ言語を解釈して実行する、対話式データベースエンジンプログラムと、テーブルを構成するデータファイル群の組み合わせよりなる。
【００３９】
伝票管理サーバ５０５は、配送会社内に設けられている。
伝票管理サーバ５０５は、伝票管理プログラム５０６と、在庫管理テーブル５０７、そして伝票テーブル５０８を含む。
伝票管理プログラム５０６は、発注ｃｇｉ５０４から発される発注データを受信して、所定の仕事を実行する。
在庫管理テーブル５０７には、倉庫に納められている商品の商品コードと機番が列挙格納されている。
伝票テーブル５０８は、発注データ毎に伝票を起票し、管理するためのテーブルである。この伝票テーブル５０８には、伝票番号と、契約ＩＤと、発注データに含まれる商品コードと、それに対応する機番、そして顧客ＩＤや設置先ＩＤ等が列挙格納されている。情報の冗長化を避けるため、伝票番号、契約ＩＤ、顧客ＩＤ、そして設置先ＩＤ等、伝票単位で発生するデータは別テーブルに設けるとよい。
【００４０】
なお、
・配送会社は倉庫を所有し、
・その倉庫には商品がダンボール箱等で梱包された状態で保管され、
・そのダンボール箱には商品の商品コードと機番がバーコードにて記録されており、
・その梱包を解かなくても、ハンディターミナル１０８によって、商品コードと機番を直接的に機械的に読み取りが可能な状態になっている
ものと想定する。
或は、無線タグ等が商品に貼付されて、その梱包を解かなくても商品コードと機番を直接的に機械的に読み取りが可能な状態になっている場合でもよい。
このような状況を想定する理由は、梱包を解かずに、機器管理システムに機番を入力する必要があることに起因する。
すなわち、配送会社は倉庫内に保管されている商品について、予め商品コードと機番が在庫管理テーブルに記憶されている。そして、発注データを受信したら、即座に発注データ内に含まれている商品コードに対応する機番を登録し、契約ＩＤを紐付けて、機器管理システムに送信する。
このようにシステムを構成することで、発注された商品について、発注データの送信に呼応する状態で、機器管理テーブル３１６による管理が開始される。
【００４１】
図６は、発注ｃｇｉ５０４の機能を説明するブロック図である。
従業員等識別部６０２は、クライアントＰＣ１０７から来るアクセス要求（ＨＴＴＰリクエストメッセージ）を読み込み、ＨＴＴＰリクエストメッセージのヘッダ部分（ＨＴＴＰリクエストヘッダ）に含まれている認証データを読み取り、従業員テーブル３０２等を参照して、アクセスしてきた従業員を特定する。本実施形態では、ユーザ認証は今日広く使われている「クッキー認証」を用いているものとする。このため、従業員等識別部６０２は従業員認証ｃｇｉ２０３が作成した、図示しないクッキーデータと照合し、その後従業員テーブル３０２等を参照して、従業員を識別する。
【００４２】
また、従業員等識別部６０２は、ＨＴＴＰリクエストヘッダを見て、ＧＥＴメソッド（ＨＴＴＰリクエストメッセージにおける、所定のデータを取得する要求を示すメッセージ。）かＰＯＳＴメソッド（ＨＴＴＰリクエストメッセージにおける、所定のデータを送信することを示すメッセージ。）かを確認する。
ＧＥＴメソッドであれば、ｈｔｍｌ文書作成部６０３に、ｈｔｍｌ文書を作成してクライアントＰＣ１０７に送信するべく命ずる。
ＰＯＳＴメソッドであれば、入力データ判定部６０４にクライアントＰＣ１０７から送信されてきた入力データを読み込ませて、クライアントＰＣ１０７から受信したデータの内容を検証し、発注処理をすべきか否か判断する。
従業員等識別部６０２がＰＯＳＴデータの内容を見て、発注処理すべきと判断したら、次にステータス変更部６０５に対し、商談テーブル３０６と契約テーブル３０７にその旨を示すステータス情報を書くべく命令する。
【００４３】
ステータス変更部６０５は、商談テーブル３０６と契約テーブル３０７に「商談成立」を示すステータス情報を書く。なお、契約テーブル３０７は一つの商談に複数存在し得るので、契約テーブル３０７にアクセスするために、商談契約テーブル３０８を参照する。
ステータス変更部６０５によるステータス変更処理が終わったら、次に入力データ判定部６０４は、ＰＯＳＴデータを発注リスト作成部６０６に引き渡す。
【００４４】
発注リスト作成部６０６は、ＰＯＳＴデータにて得られた商談ＩＤを基に、
・商談テーブル３０６、
・商談契約テーブル３０８、
・契約テーブル３０７、
・契約商品等テーブル３１４、
・顧客設置先テーブル３０５及び
・商品基本情報テーブル３１２
等にアクセスし、配送会社に送信するための発注リストを作成する。
発注リスト作成部６０６が作成した発注リストデータは、発注リスト送信部６０７に引き渡される。
非対話型ｗｅｂクライアントソフトウェアを構成する発注リスト送信部６０７は、ＨＴＴＰにて、伝票管理サーバ５０５に発注リストデータを送信する。
【００４５】
図７は伝票管理サーバ５０５の機能を説明するブロック図である。
伝票管理プログラム５０６は、ｗｅｂサーバプログラム２０２と発注処理ｃｇｉ７０２を含む。ｃｇｉはこれ以外にも多数存在するが、本実施形態とは直接関係しないものなので、その記載を省略している。
発注処理ｃｇｉ７０２は、発注リスト受信部７０３と、伝票作成部７０４と、機番等登録部７０５よりなる。
発注リスト受信部７０３は、発注ｃｇｉ５０４から送信される発注リストデータを受信する。
伝票作成部７０４は、発注リスト受信部７０３から得られた発注リストデータを基に、在庫管理テーブル５０７を参照して、伝票テーブル５０８に伝票作成処理を行う。具体的には、発注リストデータ内の商品について、倉庫内に在庫としてある商品の機番を、伝票テーブル５０８に紐付けて記録する。
機番等登録部７０５は、ＤＢサーバ１０４に対してアクセスをするＳＱＬクライアントを構成し、発注リストデータ内の商品について、対応する契約商品等テーブル３１４のレコードに機番を登録する。そして、機器管理テーブル３１６に新規なレコードを追記する。
【００４６】
図８は、図５のＤＢサーバ１０４における、各テーブルのフィールドの関係を示す概念図である。
発注ｃｇｉ５０４は、顧客との商談が成立した商談ＩＤをキーに、商談テーブル３０６を検索して、商談にかかる諸情報を得る。
次に、発注ｃｇｉ５０４は、商談ＩＤにて商談契約テーブル３０８を検索し、対応する契約の契約ＩＤを一つ以上得る。
次に、発注ｃｇｉ５０４は、契約ＩＤにて契約テーブル３０７を検索し、契約にかかる諸情報を得る。
更に、発注ｃｇｉ５０４は、契約ＩＤにて契約商品等テーブル３１４を検索し、
・一つ以上の商品コード又は役務コードと、
・一つの設置先ＩＤ
を得る。
次に、発注ｃｇｉ５０４は、商品コードにて商品基本情報テーブル３１２を検索し、商品にかかる諸情報を得る。
そして、発注ｃｇｉ５０４は、設置先ＩＤにて顧客設置先テーブル３０５を検索し、設置先にかかる諸情報を得る。
このようにして、各テーブルの情報が紐付けられた状態でデータを取得することができ、商品の発注データを作成することができる。
一方、伝票管理プログラム５０６が伝票作成処理を行った後の処理として、機番が契約商品等テーブル３１４に記録され、その後機器管理テーブル３１６に新たなレコードが追記される。追記録されるレコードの内容は、
・発注データから得られた契約ＩＤ、商品コード、設置先ＩＤと、
・伝票作成の際に得られた機番と、
・この処理を行った当日の日付と、
・機器稼動ステータスとして「未稼働」及び機器物流ステータスとして「出荷完了」
である。
この追記動作は、発注データに列挙される商品の個数に対応する。このことは、ある顧客が同じ商品（機器）を複数購入した場合、その機器一つ一つについて新規にレコードが作成されることを意味する。同じ機器であっても、それらの機番は全て異なるからである。
【００４７】
図９は、販売会社ｗｅｂサーバ１０２とＤＢサーバ１０４と伝票管理サーバ５０５において、機番を契約商品等テーブル３１４と機器管理テーブル３１６に登録する動作の流れを示すフロー図である。
クライアントＰＣ１０７から発注指示を受けた販売会社ｗｅｂサーバ１０２の発注ｃｇｉ５０４は、ＤＢサーバ１０４の商談テーブル３０６及び契約テーブル３０７の該当レコードのステータスを変更する（Ｓ９０１）。
次に、発注ｃｇｉ５０４は、ＤＢサーバ１０４に対して、発注データ作成のための問い合わせを行う（Ｓ９０２）。
【００４８】
ＤＢサーバ１０４から発注ｃｇｉ５０４に、発注データの作成に必要なデータが送信される（Ｓ９０３）。
発注ｃｇｉ５０４は発注データを作成した後、伝票管理サーバに発注データを送信する（Ｓ９０４）。
伝票管理プログラム５０６は発注データを受信し、伝票を作成し、機番の紐付けを行う（Ｓ９０５）。
伝票管理プログラム５０６は、発注データに列挙されている商品コードに紐付けられた機番を、契約商品等テーブル３１４の該当レコードに記録する（Ｓ９０６）。そして、機器管理テーブル３１６に追記録する（Ｓ９０７）。
【００４９】
図１０は、発注ｃｇｉ５０４の動作を示すフローチャートである。
営業担当者５０１の操作によって起動されると（Ｓ１００１）、最初に商談テーブル３０６及び契約テーブル３０７のステータスを、「契約確定」を示すステータス値に変更する（Ｓ１００２）。
次に、契約対象商品のリスト、すなわち発注リストの元になるデータを、契約商品等テーブル３１４から読み取る（Ｓ１００３）。そして、得られた商品コード等の情報を読み込んで、発注リストを作成する（Ｓ１００４）。
最後に、完成した発注リストを、配送会社の伝票管理サーバの伝票管理プログラム５０６に送信して（Ｓ１００５）、終了する（Ｓ１００６）。
【００５０】
図１１は、伝票管理プログラム５０６の動作を示すフローチャートである。
ｗｅｂサーバプログラムは販売会社ｗｅｂサーバから発注リストデータの送信があるか、常時監視し続けている（Ｓ１１０１、Ｓ１１０２）。
ｗｅｂサーバプログラムと発注リスト受信部が発注リストデータを受信すると、伝票作成部は新規の伝票番号を起こし（Ｓ１１０３）、伝票テーブルの新規レコードに発注リストデータに含まれている商品コードを記録する（Ｓ１１０４）。
そして、在庫テーブルを商品コードにて検索し、得られた機番を伝票テーブルに書いて、紐付けを行う（Ｓ１１０５）。こうして、伝票作成の準備が整う。実際の伝票は、この時点でプリンタに印字出力する。
【００５１】
次に、紐付けを行った機番を、契約商品等テーブル３１４に書く（Ｓ１１０６）。
そして最後に、
・発注データから得られた契約ＩＤ、商品コード、設置先ＩＤと、
・伝票作成の際に得られた機番と、
・この処理を行った当日の日付と、
・機器稼動ステータスとして「未稼働」及び機器物流ステータスとして「出荷完了」
を機器管理テーブル３１６に書いて（Ｓ１１０７）、終了する（Ｓ１１０８）。
【００５２】
以上のようにして登録された機器（商品）は、その後は商品コードと機番をシステムに送信することで機器が一意に特定され、役務に応じて様々なステータス情報が機器管理テーブル３１６に追記録される。
更に、顧客の事情等で機器の設置場所が変わる等、機器の移動が発生すると、契約商品等テーブル３１４の設置先ＩＤが書き換えられると共に、機器管理テーブル３１６には、最新の設置先ＩＤと、移動が発生したことを示す機器物流ステータスを含む新規レコードが追記録される。
つまり、ある機器の移動が生じると、その移動の履歴が記録される。機器の廃棄やリサイクル等も同様である。
【００５３】
本実施形態においては、機器管理システムを開示した。
以上の概略説明にてわかるように、本実施形態の機器管理システム１０１は、商品の発注に呼応して、機器を一意に識別する商品コードと機番が機器管理テーブルに記録され、それ以降の商品の運用、買い替えの予防、そして廃棄に至る迄の、「商品の一生」を詳細に記録し、管理することができる。
【００５４】
以上、本発明の実施形態例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含むことは言うまでもない。
【図面の簡単な説明】
【００５５】
【図１】本発明の一実施の形態による機器管理システムの全体を示す概略図である。
【図２】ｗｅｂサーバ等とＤＢサーバの詳細を示す機能ブロック図である。
【図３】ＤＢサーバに含まれているテーブル群のフィールド名を一部抜粋した概略図である。
【図４】機器管理テーブルに含まれる、機器稼動ステータスと機器物流ステータスの凡例を示す表である。
【図５】本実施形態の機器管理システムのうち、機器管理機能に注目した部分の機能を説明する、ブロック図である。
【図６】発注ｃｇｉの機能を説明するブロック図である。
【図７】伝票管理サーバの機能を説明するブロック図である。
【図８】ＤＢサーバにおける、各テーブルのフィールドの関係を示す概念図である。
【図９】販売会社ｗｅｂサーバとＤＢサーバと伝票管理サーバにおいて、機番を契約商品等テーブルと機器管理テーブルに登録する動作の流れを示す、フロー図である。
【図１０】発注ｃｇｉの動作を示すフローチャートである。
【図１１】伝票管理プログラムの動作を示すフローチャートである。
【符号の説明】
【００５６】
１０１…機器管理システム、１０２、１０３…ｗｅｂサーバ、１０４…ＤＢサーバ、１０５、１０６、１０７…クライアントＰＣ、１０８…ハンディターミナル、１０９…社内ＬＡＮ、２０２…ｗｅｂサーバプログラム、２０３…従業員認証ｃｇｉ、３０２…従業員テーブル、３０３…顧客企業テーブル、３０４…顧客担当者テーブル、３０５…顧客設置先テーブル、３０６…商談テーブル、３０７…契約テーブル、３０８…商談契約テーブル、３０９…禁則条件テーブル、３１０…締め日条件テーブル、３１１…契約種別テーブル、３１２…商品基本情報テーブル、３１３…役務基本情報テーブル、３１４…契約商品等テーブル、３１５…役務商品テーブル、３１６…機器管理テーブル、３１７…カウンタ確認ログテーブル、５０１…営業担当者、５０２…販売管理ｗｅｂサーバ、５０４…発注ｃｇｉ、５０５…伝票管理サーバ、５０６…伝票管理プログラム、５０７…在庫管理テーブル、５０８…伝票テーブル、６０２…従業員等識別部、６０３…ｈｔｍｌ文書作成部、６０４…入力データ判定部、６０５…ステータス変更部、６０６…発注リスト作成部、６０７…発注リスト送信部、７０２…発注処理ｃｇｉ、７０３…発注リスト受信部、７０４…伝票作成部、７０５…機番等登録部
【図１】
2008250515.tif 000003
【図２】
2008250515.tif 000004
【図３】
2008250515.tif 000005
【図４】
2008250515.tif 000006
【図５】
2008250515.tif 000007
【図６】
2008250515.tif 000008
【図７】
2008250515.tif 000009
【図８】
2008250515.tif 000010
【図９】
2008250515.tif 000011
【図１０】
2008250515.tif 000012
【図１１】
2008250515.tif 000013