(57)【特許請求の範囲】
【請求項１】
製品の過去の販売実績を時間的情報毎、地理的情報毎、商品情報毎に格納する販売実績格納手段と、
時間的な製品需要の喰い合いに関する集約ルール情報、地理的な製品需要の喰い合いに関する集約ルール情報、商品的な製品需要の喰い合いに関する集約ルール情報の内、少なくとも２つ以上の集約ルール情報を格納する集約ルール情報格納手段と、
上記集約ルール情報格納手段に格納された製品需要の喰い合いに関する集約ルール情報に基づき、時間的な製品需要の喰い合いに関する集約ルール情報の場合には複数の時間単位で製品をグループ化し、地理的な製品需要の喰い合いに関する集約ルール情報の場合には複数地域で製品をグループ化し、商品的な製品需要の喰い合いに関する集約ルール情報の場合には商品の種類によって製品をグループ化して製品グループ情報を生成するグループ生成手段と、
上記グループ生成手段において生成された製品グループ情報を格納するグループ情報格納手段と、
上記グループ情報格納手段に格納された製品グループ情報と、上記販売実績格納手段に格納された製品の過去の販売実績情報と、に基づいて、グループ毎に製品の需要予測を行なう需要予測手段と、
を有することを特徴とする情報処理装置。
【請求項２】
製品毎の構成部品情報を格納する構成部品情報格納手段と、
少なくとも利用者に、上記構成部品情報格納手段に格納された製品毎の構成部品情報を提示する機能を有する構成部品情報管理手段と、
を更に有し、
上記構成部品情報管理手段は、上記グループ情報格納手段に格納された製品グループ情報に基づいて、グループに含まれる製品毎の構成部品情報を利用者に提示することを特徴とする請求項１記載の情報処理装置。
【請求項３】
上記構成部品情報管理手段は、上記グループ情報格納手段に格納された製品グループ情報に基づいて、グループに含まれる製品で使用されている構成部品の割合に関する情報を利用者に提示することを特徴とする請求項２記載の情報処理装置。
【請求項４】
上記構成部品情報管理手段は、複数の製品で使用されている共通の構成
部品の割合に関する情報を利用者に提示することを特徴とする請求項２記載の情報処理装置。
【請求項５】
上記構成部品情報には、企業間で共有する製品に関する情報を含むことを特徴とする請求項２乃至４の何れか１項記載の情報処理装置。
【請求項６】
上記構成部品情報には、最終製品又は最終製品を構成する部品に関する情報を含むことを特徴とする請求項２乃至４の何れか１項記載の情報処理装置。
【請求項７】
情報処理装置における情報処理方法であって、
前記情報処理装置の制御部が、製品の過去の販売実績を時間的情報毎、地理的情報毎、商品情報毎に販売実績格納手段に格納する販売実績格納ステップと、
前記情報処理装置の制御部が、時間的な製品需要の喰い合いに関する集約ルール情報、地理的な製品需要の喰い合いに関する集約ルール情報、商品的な製品需要の喰い合いに関する集約ルール情報の内、少なくとも２つ以上の集約ルール情報を集約ルール情報格納手段に格納する集約ルール情報格納ステップと、
前記情報処理装置の制御部が、上記集約ルール情報格納手段に格納された製品需要の喰い合いに関する集約ルール情報に基づき、時間的な製品需要の喰い合いに関する集約ルール情報の場合には複数の時間単位で製品をグループ化し、地理的な製品需要の喰い合いに関する集約ルール情報の場合には複数地域で製品をグループ化し、商品的な製品需要の喰い合いに関する集約ルール情報の場合には商品の種類によって製品をグループ化して製品グループ情報を生成するグループ生成ステップと、
前記情報処理装置の制御部が、上記グループ生成ステップにおいて生成された製品グループ情報をグループ情報格納手段に格納するグループ情報格納ステップと、
前記情報処理装置の制御部が、上記グループ情報格納手段に格納された製品グループ情報と、上記販売実績格納手段に格納された製品の過去の販売実績情報と、に基づいて、グループ毎に製品の需要予測を行なう需要予測ステップと、
を有することを特徴とする情報処理方法。
【請求項８】
前記情報処理装置の制御部が、製品毎の構成部品情報を構成部品情報格納手段に格納する構成部品情報格納ステップと、
前記情報処理装置の制御部が、上記グループ情報格納手段に格納された製品グループ情報に基づいて、グループに含まれる製品毎の上記構成部品情報を利用者に提示する構成部品情報管理ステップと、
を更にすることを特徴とする請求項７記載の情報処理方法。
【請求項９】
上記構成部品情報管理ステップでは、上記グループ情報格納手段に格納されたグループに関する情報に基づいて、グループに含まれる製品で使用されている構成部品の割合に関する情報を利用者に提示することを特徴とする請求項８記載の情報処理方法。
【請求項１０】
上記構成部品情報管理ステップでは、複数の製品で使用されている共通の構成部品の割合に関する情報を利用者に提示することを特徴とする請求項８記載の情報処理方法。
【請求項１１】
上記構成部品情報には、企業間で共有する製品に関する情報を含むことを特徴とする請求項８乃至１０の何れか１項記載の情報処理方法。
【請求項１２】
上記構成部品情報には、最終製品又は最終製品を構成する部品に関する情報を含むことを特徴とする請求項８乃至１０の何れか１項記載の情報処理方法。
【請求項１３】
情報処理装置のコンピュータに請求項７乃至１２の何れか１項記載の情報処理方法の各ステップを実行させることを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【０００２】
【従来の技術】
従来より例えば、パーソナルコンピュータやカセットテープレコーダ等の様々なプロダクトの製造側においては、プロダクトの設計から製造、及び販売にわたり、ＰＤＭ／ＣＰＣを用いて、プロダクトの製造に関する様々な情報が管理されている。
【０００３】
ＰＤＭ（Ｐｒｏｄｕｃｔ  Ｄａｔａ  Ｍａｎａｇｅｍｅｎｔ）とは、プロダクトを構成する部品の管理、部品構成管理、図面管理、技術資料管理、ＣＡＤデータ管理、設計変更管理、及び電子承認／ワークフロー等が行なえるシステムである。
【０００４】
ＣＰＣ（Ｃｏｌｌａｂｏｒａｔｉｖｅ  Ｐｒｏｄｕｃｔ  Ｃｏｍｍｅｒｃｅ）とは、上記のＰＤＭの仕組みを、さらに企業間で共有するための仕組みである。
例えば、ＣＰＣは、以下に挙げるような様々なニーズを加味することで、顧客のニーズに応えた、より良い製品を早く、且つ低価格で提供することを実現できるようにしたものである。
【０００５】
・プロダクトの開発プロセスの管理（進捗の可視化、役割分担／責任範囲の明確化等のための管理）
・製品のクレーム管理（再発防止の仕組み、これをマネージメント／新製品開発に活かす等のための管理）
・製品種毎の部品構成の管理（保守／サービスに活かし顧客満足度を上げる等のための管理）
・ナリッジ・マネージメント的な実現
・サイクル性／環境負荷物質の管理
・グローバル対応（海外展開、グローバル品番対応等）
・企業間連携
【０００６】
上述のようなＰＤＭ／ＣＰＣにより、例えば、プロダクトの設計の開発段階におけるプロダクトの仕様情報や設計図に関する情報、製造段階における部品構成や製造マニュアルに関する情報、及び販売段階における情報を一元管理することができると共に、企業内の各部署、或いは１つのプロダクトに関わる複数の企業が、当該一元管理情報を共有することができる。これにより、プロダクトに関する情報の不整合を防ぎ、顧客のニーズに応えた、より良い製品を早く、且つ低価格で提供できる。
【０００７】
一方、プロダクトを製造して販売するにあたり、需要と供給のバランスをとるために、例えば、ＳＣＭを利用して、需要予測することが一般的に行なわれている。
【０００８】
ＳＣＭ（Ｓｕｐｐｌｙ  Ｃｈａｉｎ  Ｍａｎａｇｅｍｅｎｔ）とは、プロダクトを構成する部品のサプライヤから、実際にプロダクトを販売する販売店までの、一貫した需要を過去の実績値等から予測し、プロダクトの過剰在庫／欠品の両リスクを低減するための仕組みである。
【０００９】
【発明が解決しようとする課題】
ところで、上述したようなＰＤＭ／ＣＰＣを用いて製品製造管理を行なう従来の製品管理方法では、プロダクトを設計するにあたり、プロダクトを構成する複数の部品の調達価格を低減するため、或いはプロダクトの販売後の保守負荷を軽減するための目的で、複数のプロダクト間で共通の部品を用いる、所謂部品の共通化という考えが浸透してきている。
【００１０】
しかしながら、部品の共通化を単純に進めていくと、個々のプロダクトの魅力を低下させることになってしまう、という問題が生じる。また、共通化を図ろうにも、共通化の基準が明確でないために、どの程度共通化をすべきかが分かりにくい、という問題もあった。
【００１１】
本発明は上記の問題点に鑑みなされたもので、喰い合いを考慮し、精度良く需要予測の結果を導出することを目的とする。
【００１２】
【課題を解決するための手段】
そこで、上記問題を解決するため、本発明は、製品の過去の販売実績を時間的情報毎、地理的情報毎、商品情報毎に格納する販売実績格納手段と、時間的な製品需要の喰い合いに関する集約ルール情報、地理的な製品需要の喰い合いに関する集約ルール情報、商品的な製品需要の喰い合いに関する集約ルール情報の内、少なくとも２つ以上の集約ルール情報を格納する集約ルール情報格納手段と、上記集約ルール情報格納手段に格納された製品需要の喰い合いに関する集約ルール情報に基づき、時間的な製品需要の喰い合いに関する集約ルール情報の場合には複数の時間単位で製品をグループ化し、地理的な製品需要の喰い合いに関する集約ルール情報の場合には複数地域で製品をグループ化し、商品的な製品需要の喰い合いに関する集約ルール情報の場合には商品の種類によって製品をグループ化して製品グループ情報を生成するグループ生成手段と、上記グループ生成手段において生成された製品グループ情報を格納するグループ情報格納手段と、上記グループ情報格納手段に格納された製品グループ情報と、上記販売実績格納手段に格納された製品の過去の販売実績情報と、に基づいて、グループ毎に製品の需要予測を行なう需要予測手段と、を有することを特徴とする。
【００１３】
係る構成とすることによって、喰い合いを考慮し、精度良く需要予測の結果を導出することができる。
【００１９】
また、上記問題を解決するため、本発明は、情報処理方法及びプログラムとしてもよい。
【００２０】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００２１】
本発明は、例えば、図１に示すような製品管理システム１００に適用される。本実施の形態の製品管理システム１００は、特に、ＳＣＭによりプロダクトの需要予測を行なう需要予測側１１０で得られた情報を、ＰＤＭ／ＣＰＣによりプロダクトの設計等に関する情報を管理する製品情報管理側１２０に提供する構成により、個々のプロダクトの魅力を低下させないような最適な部品の共通化の度合いを容易に確認でき、複数のプロダクト間で部品の共通化を最適に図ることができるようになされている。
以下、本実施の形態の製品管理システム１００の構成及び動作について具体的に説明する。
【００２２】
＜製品管理システム１００の構成＞
製品管理システム１００は、上記図１に示すように、需要予測側１１０及び製品情報管理側１２０が、任意の通信網或いは任意の記憶媒体を介して互いに情報授受可能に接続された構成としている。
【００２３】
需要予測側１１０は、詳細は後述するが、あるルールに基づき処理対象のプロダクトをグループ化して需要予測するシステムであり、プロダクトの需要の実績値（ＰＯＳ情報等）を格納する実績値ＤＢ（データベース）１１１と、グループ化で得られた製品のグループに関する情報を格納する製品グループＤＢ１１２と、プロダクトをグループ化するにあたり用いるルールに関するカニバリーゼーション（喰い合い）情報を格納するカニバリーゼーションＤＢ１１３と、グループ化で得られた製品のグループについて需要予測を行うＳＣＭ１１４と、プロダクトをグループ化するグループ生成部１１５と、グループ生成部１１５で得られた結果（製品グループ情報）を製品情報管理側１２０に与える情報提供部１１６とを含む構成としている。
【００２４】
一方、製品情報管理側１２０は、設計ＤＢ１２１、部品構成ＤＢ１２２、及びＰＤＭ（ＰＤＭ／ＣＰＣ）１２３を含む構成により、プロダクトの設計等に関わる情報を管理するシステムであり、特に、需要予測側１１０から提供された情報（製品グループ情報）を用いて、プロダクトを構成する部品の共通化を最適に行いながらプロダクトの設計等を行なえるように構成されている。
【００２５】
上述のような需要予測側１１０及び製品情報管理側１２０はそれぞれ、例えば、図２に示すようなコンピュータ機能２００により、上記図１に示した構成による機能（本実施の形態における機能）を実現している。
【００２６】
コンピュータ機能２００は、上記図２に示すように、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、キーボード（ＫＢ）２０９のキーボードコントローラ（ＫＢＣ）２０５と、表示部としてのＣＲＴディスプレイ（ＣＲＴ）２１０のＣＲＴコントローラ（ＣＲＴＣ）２０６と、ハードディスク（ＨＤ）２１１及びフレキシブルディスク（ＦＤ）２１２のディスクコントローラ（ＤＫＣ）２０７と、ネットワーク２２０との接続のためのネットワークインターフェースコントローラ（ＮＩＣ）２０８とが、システムバス２０４を介して互いに通信可能に接続された構成としている。
【００２７】
ＣＰＵ２０１は、ＲＯＭ２０２或いはＨＤ２１１に記憶されたソフトウェア、或いはＦＤ２１２より供給されるソフトウェアを実行することで、システムバス２０４に接続された各構成部を総括的に制御する。
すなわち、ＣＰＵ２０１は、所定の処理シーケンスに従った処理プログラムを、ＲＯＭ２０２、或いはＨＤ２１１、或いはＦＤ２１２から読み出して実行することで、本実施の形態での動作を実現するための制御を行う。
【００２８】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ或いはワークエリア等として機能する。
ＫＢＣ２０５は、ＫＢ２０９や図示していないポインティングデバイス等からの指示入力を制御する。
ＣＲＴＣ２０６は、ＣＲＴ２１０の表示を制御する。
ＤＫＣ２０７は、ブートプログラム、種々のアプリケーション、編集ファイル、ユーザファイル、ネットワーク管理プログラム、及び本実施の形態における所定の処理プログラム等を記憶するＨＤ２１１及びＦＤ２１２とのアクセスを制御する。
ＮＩＣ２０８は、必要に応じて、ネットワーク２２０上の装置或いはシステムと双方向にデータをやりとりする。
【００２９】
＜需要予測側１１０の特徴とする構成＞
まず、需要予測側１１０の特徴とする構成の説明の前に、一般的なＳＣＭによる需要予測について説明する。
【００３０】
例えば、ＳＣＭによりプロダクトの需要予測を行うことで、適切な在庫を持つことができ、顧客がプロダクトを購入希望するタイミングで、当該プロダクトを即に出荷することができる。また、最適な在庫を持つことで、顧客がプロダクトを購入希望したときに当該プロダクトが欠品状態であることにより、これに代えて他社のプロダクトが購入されてしまうことを防ぐことができる。
【００３１】
特に、パーソナルコンピュータ等のライフサイクルの短いプロダクトに関しては、在庫を持つことがリスクになる場合があるため、ＳＣＭによる需要予測は重要である。
【００３２】
具体的には、ライフサイクルの短いプロダクトに関しては、在庫がないと販売することができず、これとは逆に在庫がありすぎても売れ残りの場合に安く販売する或いは破棄する必要があるため、ＳＣＭにより最適な在庫量を確保することが重要である。
【００３３】
しかしながら、ＳＣＭにより需要予測して適切な在庫量を精度良く求めることは、小売やメーカ側等から強く要望されていることであるが、これをシステム的に実施することは非常に困難であり、多くの場合が未だ人間のカン等に頼っているのが現状である。
【００３４】
具体的には例えば、販売店のＰＯＳ情報を参照することで、どのプロダクトが、いつ、いくつ売れた、などのプロダクトの実績値を得ることができるが、このプロダクトの実績値を単純に積み上げるだけでは需要予測することは大変難しい。  これは、ＰＯＳ情報には、様々な要因、特に、以下に挙げるような３つのカリバリーゼーション（需要の喰い合い）を受けているためである。
【００３５】
（１）時間的カニバリーゼーション
消費者は、あるプロダクトを、今日買う、又は明日買う、又は来週買う、又は来月買う、などというように、何らかのきっかけで購入する。
（２）地理的カニバリーゼーション
消費者は、あるチェーン店Ａでプロダクトを購入する、又は他のチェーン店Ｂでプロダクトを購入する、などというように、どこの販売店でプロダクトを購入するか、また、例えば、あるチェーン店Ａの中でも、ａ店、ｂ店、・・・の中のどの店舗でプロダクトを購入するかは、その時々によって変わってしまう。
（３）商品的カニバリーゼーション
消費者は、Ａ社のプロダクトを購入するか、又はＢ社のプロダクトを購入するか、又はＡ社のプロダクトの中でも、モデルＸ、又はモデルＹ、又は新モデル、又は旧モデルを購入するかは、その時々によって変わってしまう。
【００３６】
したがって、精度良い需要予測の結果を得るためには、（１）〜（３）のカニバリーゼーションを加味して、需要予測することが必要であるが、これらのカニバリーゼーションの影響を全て分析し、需要予測の結果を導出することは現実的には難しい。
【００３７】
すなわち、（１）〜（３）のカニバリーゼーションの軸で様々な喰い合いが起こっているため、精度良く需要予測の結果を導出することは大変難しい。
【００３８】
例えば、Ｓ社、Ｐ社、及びＴ社の３２型のテレビジョン受像機（ＴＶ）についての販売店での販売実績値を考えてみる。
トータル的な実績値としては、３月と９月に伸びる傾向にあるが（すなわち、商品群レベルでは需要は明確な季節性を示し安定しているが）、Ｓ社、Ｐ社、及びＴ社の個々のＴＶの実績値を細かくみていくと、その需要の出入りが激しいことがある。これは、例えば、Ｓ社から新しいＴＶが販売されると、その分、Ｐ社やＴ社（或いはＳ社も含め）の古いＴＶは伸びなくなるが、３２型ＴＶ全体としては、ある時期に（３月と９月等）に伸びる傾向にある、ということを意味する。
【００３９】
したがって、細かいレベル（単品）では需要の出入りが激しいため、単品での需要予測は困難であり、この結果、需要予測は「当たらない」と結論つけられ、高価なシステムを購入して導入するよりか、人間の「勘」等を中心とした需要予測に頼ることになる。
【００４０】
そこで、本実施の形態における需要予測側１１０は、以下に説明するようにして、プロダクトをグループ化して需要予測することで、精度良い需要予測の結果を提供し、さらに、当該グループ化により生成した製品グループに関する情報（製品グループ情報）を製品情報管理側１２０に提供する。
【００４１】
まず、本実施の形態では、プロダクトを、単品レベルでなく、（１）〜（３）のカニバリーゼーションの影響を包含したかたちの断面で捉えることで、需要予測の精度の向上を実現する。
【００４２】
すなわち、本実施の形態では、人間の「勘」等を中心とした需要予測であっても、（１）〜（３）のカニバリーゼーションを科学的に考慮できているわけではなく、また、適正な在庫量は需要予測精度に依存するため、可能な限り精度向上対策をとることが望ましいことにより、（１）〜（３）のカニバリーゼーションの影響を加味できる視点を模索する。
【００４３】
そこで、例えば、ＰＯＳ情報を集約することで、以下に挙げるようなカニバリーゼーションを包含した情報を取得する。
【００４４】
（１）時間的カニバリーゼーション
例えば、消費者が、今日購入するか、又は明日購入するか等で振れているようであれば、週又は月単位でまとめる（グループ化する）。これにより、時間的カニバリーゼーションの影響を包含した情報が得られ、そのトータルの枠を見ることができる。
（２）地理的カニバリーゼーション
例えば、流通／小売サイドから見た需要予測であれば、自社のチェーンを全てまとめる。また、メーカサイドから見た需要予測であれば、小売や地域別でまとめる。これにより、地理的カニバリーゼーションの影響を包含した情報を得ることができる。
（３）商品的カニバリーゼーション
例えば、メーカサイドから見た需要予測であれば、自社商品シリーズをまとめる。これにより、商品的カニバリーゼーションの影響を包含した情報を得ることができる。
【００４５】
上述のような（１）〜（３）のカニバリーゼーションの影響を包含した情報と、個々のプロダクトの全体の中での位置付け、販促情報、及び新製品導入情報とを付け合せて、それぞれの需要計画値を確定する。
【００４６】
尚、カニバリーゼーションを包含してグループを抽出するにあたり、例えば、「既存のシリーズが適切であるか？」、「複数シリーズをまとめたグループが適切であるか？」、「シリーズを分割してみるのが適切であるか？」等をも考慮する
【００４７】
したがって、メーカ側に対しては、他社のプロダクト以外のカニバリーゼーションを包含したトータルの需要予測の結果を提供することができ、流通／小売側に対しては、他チェーン以外のカニバリーゼーションを包含したトータルの需要予測の結果を提供することができる。
【００４８】
上述のように、本実施の形態では、プロダクトを、あるルールに従ってグループ化して需要予測する。これにより、需要予測に対して、（１）〜（３）のカニバリーゼーションの影響を少なくすることができ、需要予測精度を向上させることができる。
【００４９】
本実施の形態のようにプロダクトをグループ化することで、例えば、以下のようなメリットが得られる。
【００５０】
・トータルを抑えることができるため、個々のプロダクトの需要というものの振れ幅を小さくすることができる。これにより、精度良い需要予測の結果を得ることができる。
・その時々の条件に応じて突発的にプロダクトの販売量が伸びること等により、プロダクトの需要予測をしにくい場合があるが、その上位のレベルでグループ化することで、統計的な手法というものを適合できる。
【００５１】
また、上述のようなグループ化により得られた製品グループでの精度良い需要予測は、以下に説明するような、プロダクトを構成する部品の共通化に有効である。
【００５２】
例えば、図３に示すように、製品Ａ、製品Ｂ、及び製品Ｃがグループ化された場合、このトータルの需要予測（同図（ａ）参照）に対して、実際の需要では、トータルでみると予測通りの需要であったが、製品Ｂの需要が予測よりも多く、その分、製品Ｃの需要が予測よりも少なかったものとする。
【００５３】
すなわち、上記図３（ｂ）に示すように、需要予測と実際の需要の差異が生じた場合、製品Ｂは欠品状態にあるため、他社に同様な製品があれば、市場を奪われる可能性がある（機会損失）。一方、商品Ｃは過剰在庫状態にあるため、販促（価格ダウン）による損失と共に、場合によっては破棄損に繋がる可能性がある。
【００５４】
換言すれば、プロダクトのトータルな実際の需要が需要予測値と等しいならば、欠品ボリュームと過剰在庫量はほぼ同じ値をとるため、製品Ｂが欠品状態にあることを認識できた段階で、製品Ｃが過剰在庫であることを認識できる。
【００５５】
通常、欠品状態にあるプロダクトについては、例えば、商品棚に「もの」（＝当該プロダクト）がないことにより、販売員等は、当該プロダクトが欠品状態であることを直ぐに把握することができる。これに対して過剰在庫状態にあるプロダクトについては、その場で直ぐに、この状態を認識することは難しい。
【００５６】
しかしながら、本実施の形態では、プロダクトをグループ化して需要予測しているので、上記図３に示したような状態である場合、製品Ｂの欠品を認識できた段階で、製品Ｃの過剰在庫を直ぐに認識（過剰在庫の早期発見）できるため、その対応を迅速に行うことができる。
【００５７】
また、過剰在庫の早期発見というメリットを利用して、例えば、計画に見直しを通常よりも頻繁に行なうことで、欠品と過剰在庫を、より迅速に把握することができる。
【００５８】
これにより、例えば、プロダクトを構成する部品の製造側に対して、当該部品の製造をストップする指示を出す、などのようなアクションを早期に起こすことができる。
【００５９】
また、例えば、上記図３に示したように、製品Ａ、製品Ｂ、及び製品Ｃがグループ化されていた場合、図４に示すように、製品Ｂと製品Ｃの間で「部品の共通化」を行い、計画見直しを多頻度化して行なう中で、上記図３に示したように、トータル的には需要予測通りの実績が得られたが、製品Ｂは欠品状態で製品Ｃが過剰在庫であることが分かった時点で、生産変更指示を出す。
【００６０】
具体的には、製品Ｂと製品Ｃの間で、製品Ｃに使用する予定であった部品を、製品Ｂに使用し、製品Ｂの生産を行なうよう生産変更指示する。これにより、部品在庫のリスクとしてあったものが、逆に利益として返ってくることになる。
【００６１】
特に、部品の調達については、部品によっては海外から調達する必要があり、時間がかかるものがあるが、欠品状態にある製品Ｂを製造するための部品が直ぐに入手しにくいものであっても、製品Ｂと製品Ｃの間で、当該部品の共通化がなされていれば、その場で直ぐに必要な部品を手に入れることができるため有効である。
【００６２】
そこで、本実施の形態では、需要予測側１１０において、プロダクトをグループ化して需要予測すると共に、さらに、当該グループ化の結果（製品グループ情報）を、部品を共通化しながらプロダクトの設計等を行うための情報を管理する製品情報管理側１２０に提供する。
【００６３】
＜製品情報管理側１２０の特徴とする構成＞
製品情報管理側１２０は、ＰＤＭ１２３（ＰＤＭ／ＣＰＣ）により、プロダクトを設計するにあたり、どのような部品を使うか、どのようなプロセスで製造するか等の情報を管理するが、特に、需要予測側１１０からの製品グループ情報をも管理すると共に、これを部品を共通化するための基準情報として、プロダクトの設計等を行うユーザ（設計者等）に対して提供する。
【００６４】
具体的には、まず、「部品の共通化」は、プロダクトの製造原価を下げたいというニーズや、プロダクトの部品を大量に購入すると、すなわち発注数量を多くすると、その分単価が安くなる、などという理由から行なわれている。
【００６５】
すなわち、図５に示すように、ＰＤＭ／ＣＰＣでは、「調達規模のメリットの追求」ということに主眼が置かれており（動機）、これから「部品の共通化」が行なわれている。
【００６６】
しかしながら、過度の共通化はプロダクトの魅力の低下を招く。例えば、消費者からみると、他と異なる部分を有するプロダクトを求めるのが通常であるが、部品の共通化を単純に行えば、それぞれが同じようなプロダクトとなってしまう。
したがって、部品共通化を図るべき「基準」が必要となってくる。
【００６７】
そこで、本実施の形態における製品情報管理側１２０は、部品の共通化のための「基準」として、需要予測側１１０で得られた製品グループ情報を用いる。
【００６８】
すなわち、本実施の形態では、需要予測側１１０において、カニバリーゼーションを包含した需要予測の際に抽出された製品グループ単位で、部品の共通化の度合いを確認する構成を、製品情報管理側１２０で実現する。
【００６９】
これにより、ユーザ（設計者等）は、部品の共通化のための適切な指標（製品グループ情報）を用いて、最適な部品の共通化を行いつつ、プロダクトの設計等を行うことができる。
【００７０】
また、製品グループ単位での部品の共通化がなされることにより、上記図３及び図４を用いて説明したような、欠品及び過剰在庫のプロダクト間で部品を移行しての製造を行なえる。
【００７１】
＜需要管理システム１００の動作＞
図６は、需要管理システム１００の動作をフローチャートにより示したものである。
【００７２】
ステップＳ３０１：
需要予測側１１０は、プロダクト毎や、日毎、或いは地域毎（県等）等の単位で、プロダクトの販売実績を収集し、この収集情報（実績値）を実績値ＤＢ１１１に保持する。
【００７３】
ステップＳ３０２：
需要予測側１１０は、グループ生成部１１５のＤＨＷ（データウェアハウス：意思決定支援機能）により、実績値ＤＢ１１１内の情報、及びカニバリゼーションＤＢ１１３内の情報（予め登録されたルール等を含む情報）に基づき、プロダクトをグループ化し、その結果情報（製造グループ情報）を製品グループＤＢ１１２に一旦保持する。
【００７４】
具体的には例えば、処理対象のプロダクトがパーソナルコンピュータ（パソコン）の場合、グループ生成部１１５は、日毎を、週毎又は月毎とし、地域（県）を、地方、又は全国、又は各国とし、さらに、プロダクト（パソコン）について、
ａ：高中下位（値段的なスペック）
ｂ：デスクトップ、ノートパソコン
ｃ：発売時期（新旧）
ｄ：色
でグループ化する。
【００７５】
ステップＳ３０３、ステップＳ３０４：
需要予測側１１０は、所定の期間単位（例えば、半期単位）で、以下に説明するようなステップＳ３０３及びステップＳ３０４の処理を実行する。
【００７６】
先ず、需要予測側１１０は、所定の期間単位（例えば、半期単位）で、ＳＣＭ１１４により、ステップＳ３０２で得られたグループ単位で需要予測する（ステップＳ３０３）。
【００７７】
具体的には例えば、ステップＳ３０２において、
aでグループ化したグループＡ
ａ＋ｃでグループ化したグループＢ
ｂ＋ｄでグループ化したグループＣ
が得られた場合、ＳＣＭ１１４は、グループＡ〜Ｃの３つのグループについて、シミユレーションを行い需要予測する。
【００７８】
そして、需要予測側１１０は、情報提供部１１６により、ステップＳ３０３で得られた３つのグループＡ〜Ｃについて需要予測結果の中から、最も適切な結果（製品グループ情報、例えば、グループＢを示す情報）を抽出し、これを製品情報管理側１２０に提供する（ステップＳ３０４）。
【００７９】
ステップＳ３０５：
製品情報管理側１２０は、需要予測側１１０から提供された製品グループ情報をＰＤＭ１２３に登録する。
これにより、ＰＤＭ１２３は、詳細は後述するが、当該製品グループ情報により示されるグループ単位で、適切な部品の共通化であるかの確認等のための情報をユーザ（設計者等）に適用できる。
【００８０】
ステップＳ３０６：
製品情報管理側１２０は、需要予測側１１０から提供された製品グループ情報に基づき、設計ＤＢ１２１内の情報、及び部品構成ＤＢ１２２内の情報を更新する。
【００８１】
ステップＳ３０７：
製品情報管理側１２０は、ＰＤＭ１２３により、グループ毎に部品の共通度合い情報（共通化を行なうにあたり適切な指標）等を出力する。これにより、ユーザ（設計者等）は、適切な部品共通化を意識して、プロダクトの設計等を行なえる。
【００８２】
ここで、製品情報管理側１２０において、需要予測側１１０で得られた製品グループ情報を用いた処理の一例を挙げる。
【００８３】
製品情報管理側１２０は、プロダクトが、どのような部品から構成されているか、などという情報を管理している。
【００８４】
すなわち、設計ＤＢ１２１には、例えば、プロダクトがカセットテープレコーダである場合、当該カセットテープレコーダを構成する、モータ、ケース、マニュアル、電源装置、・・・等の個々の部品に対して、重さや、出力、或いは形状等の仕様情報が付加されて管理されている。
しかしながら、実際には、設計ＤＢ１２１で管理されている部品には、部品番号が異なっていても、同様の仕様である部品が多いのが現状である。
【００８５】
一方、部品構成ＤＢ１２２には、プロダクトが、どの部品から製造されるか等を示す情報が格納されている。
【００８６】
製品情報管理側１２０のユーザ（設計者等）は、ＰＤＭ１２３により、設計ＤＢ１２１内の情報及び部品構成ＤＢ１２２内の情報を参照して、プロダクトの設計等を行う。
【００８７】
このとき、製品情報管理側１２０は、需要予測側１１０で得られた製品グループ情報を、例えば、以下に挙げるような形態で、ユーザに対して提示する。
【００８８】
（提示例１）
製品情報管理側１２０は、製品グループ情報により示されるグループ内（製品Ａ、製品Ｂ、製品Ｃ等）で使用されている部品の割合に関する情報を提示する。具体的には例えば、「モータａは３０％の割合で使用されている」旨を示す情報を提示する。
【００８９】
（提示例２）
ユーザが最終的なチェックを行う際に、製品情報管理側１２０は、部品の共通化の割合に関する情報を提示する。具体的には例えば、モータａが使用されている割合をグループ毎にリスト情報提示する。
【００９０】
尚、本発明の目的は、本実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、達成されることは言うまでもない。
この場合、記憶媒体から読み出されたプログラムコード自体が本実施の形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体及び当該プログラムコードは本発明を構成することとなる。
プログラムコードを供給するための記憶媒体としては、ＲＯＭ、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード等を用いることができる。
また、コンピュータが読みだしたプログラムコードを実行することにより、本実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって本実施の形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって本実施の形態の機能が実現される場合も含まれることは言うまでもない。
以上説明したように本実施形態では、需要予測側（ＳＣＭ等）で製品（複数の部品から構成されるプロダクト等）の需要予測を行ない、製品情報管理側（ＰＤＭ／ＣＰＣ等）で当該製品に関する情報を管理するにあたり、需要予測側が、複数の製品を所定のルールに基づきグループ化し、当該グループ単位で需要予測すると共に、当該グループに関する情報（需要予測の結果として最も良い結果が得られたグループに関する情報等）を製品情報管理側に提供し、製品情報管理側が、需要予測側から提供されたグループ情報に基づき製品情報の管理を行うように構成した。
上記のような構成により、製品情報管理側は、需要予測側において需要予測という側面から得られた製品のグループ情報を、ユーザに提供することができるため、ユーザは、当該製品の設計を行うにあたり、需要が見込めるという効果を担保しつつ、個々のプロダクトの魅力を低下させないような最適な部品の共通化の度合いを容易に確認でき、複数のプロダクト間で部品の共通化を最適に図ることができる。
【００９１】
【発明の効果】
本発明によれば、喰い合いを考慮し、精度良く需要予測の結果を導出することができる。
【図面の簡単な説明】
【図１】本発明を適用した需要管理システムの構成を示すブロック図である。
【図２】上記需要管理システムの需要予測側及び製品情報管理側が有するコンピュータ機能の構成を示すブロック図である。
【図３】上記需要予測側において、プロダクトのグループ化を行った結果の一例を説明するための図である。
【図４】上記グループ化を行った結果を用いたアクションの一例を説明するための図である。
【図５】上記需要予測側と上記製品情報管理側の連携を説明するための図である。
【図６】上記需要管理システムの動作を説明するためのフローチャートである。
【符号の説明】
１００  需要管理システム
１１０  需要予測側
１１１  実績値ＤＢ
１１２  製品グループＤＢ
１１３  カニバリゼーションＤＢ
１１４  ＳＣＭ
１１５  グループ生成部
１１６  情報提供部
１２０  製品情報管理側
１２１  設計ＤＢ
１２２  部品構成ＤＢ
１２３  ＰＤＭ／ＣＰＣ
【図１】
0004393749.tif 000002
【図２】
0004393749.tif 000003
【図３】
0004393749.tif 000004
【図４】
0004393749.tif 000005
【図５】
0004393749.tif 000006
【図６】
0004393749.tif 000007