米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 株式会社エヌ・ティ・ティ・データ

発明の名称 購入条件折衝方法及びプログラム
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2003−150807(P2003−150807A)
公開日 平成15年5月23日(2003.5.23)
出願番号 特願2001−346642(P2001−346642)
出願日 平成13年11月12日(2001.11.12)
代理人 【識別番号】100064908
【弁理士】
【氏名又は名称】志賀 正武 (外2名)
発明者 吉武 宏昭 / 水野 升裕 / 中島 雄作
要約 課題
取引先と複数の要求元とが容易に交渉を行うことができる、購買条件折衝方法を提供する。

解決手段
購買側が購入条件折衝システム4を通じて購買案件を取引先3へ提示し、取引先3は購買案件に応じて販売内容を複数の要求元1へ提示する。複数の要求元1からの「承諾」または「非承諾」の回答が購入条件折衝システム4において集計され、その集計結果に基づいて再検討決定または最終決定を購買部担当者2が行う。この過程における集計結果および決定結果は取引先3へ提示さる。最終決定が行われるまで、上記の過程が繰り返される。
特許請求の範囲
【請求項1】 購買側の購買案件を取引先へ提示する第1の過程と、前記取引先が前記購買案件に応じて提示した販売内容を複数の要求元へ提示する第2の過程と、前記複数の要求元からの「承諾」または「非承諾」の回答を集計する第3の過程と、その集計結果に基づいて再検討決定または最終決定を行う第4の過程と、前記第3の過程における集計結果および前記第4の過程における決定結果を前記取引先へ提示する第5の過程とを有し、前記第4の過程において最終決定が行われるまで、前記第2〜第5の過程を繰り返すことを特徴とする購入条件折衝方法。
【請求項2】 前記取引先は、前記販売内容を提示するにあたり、前回の提示よりどの程度金銭的に改善されているかを示す増加価値相当金額を提示することを特徴とする請求項1に記載の購入条件折衝方法。
【請求項3】 前記増加価値相当金額が予め決められた一定値を越えた場合に、前記要求元の注意を引く表示を行うことを特徴とする請求項2に記載の購入条件折衝方法。
【請求項4】 前記要求元が前記増加価値相当金額の期待値を提示し、前記取引先の提示した前記増加価値相当金額が前記期待値を越えていた場合は前記要求元の回答を「承諾」と判断し、前記取引先からの販売内容を前記要求元へ提示しないことを特徴とする請求項2に記載の購入条件折衝方法。
【請求項5】 コンピュータに、購買側の購買案件を取引先へ提示する第1の処理と、前記取引先が前記購買案件に応じて提示した販売内容を複数の要求元へ提示する第2の処理と、前記複数の要求元からの「承諾」または「非承諾」の回答を集計する第3の処理と、その集計結果に基づいて再検討決定または最終決定を行う第4の処理と、前記第3の過程における集計結果および前記第4の過程における決定結果を前記取引先へ提示する第5の処理と、前記第4の過程において最終決定が行わなかった場合に、前記第2〜第5の過程を繰り返す処理を実行させるための購入条件折衝プログラム。
発明の詳細な説明
【0001】
【発明の属する技術分野】この発明は、ネットワーク経由で行われる購買システムに係り、特に購買側と物品供給側間において発生する購買条件の交渉の円滑化を図った購入条件折衝方法及びプログラムに関する。
【0002】
【従来の技術】従来の購買システムにおける物品調達では、購買側と供給側との見積もり、発注、請求に関わる電子処理がトランザクションベースで行われていた。
【0003】
【発明が解決しようとする課題】ところで、上記従来技術は、購買側における複数要求元の要求を束ねた集約購買において、個々の購買側要求元と取引先とのネゴシエーション機能を持ち合わせていない。購買側と取引先が交渉を行う場合には購買側の購買部担当者と取引先担当者とが1対1で交渉を行っていたため、購買側の中に要求元が複数存在する場合には購買部担当者が一括交渉することになり、要求元の意見を十分加味して交渉することができていなかった。また、購買側要求元が複数存在している場合において、要求元と取引先が直接交渉する場合は、取引先がn:1で交渉することになり、取引先は効率的にプロモーションをかけられるようにしないと交渉に莫大な作業量がかかってしまうという問題があった。この発明は上記の事情を考慮してなされたもので、その目的は取引先と複数の要求元とが容易に交渉を行うことができる購買条件折衝及びプログラムを提供することにある。
【0004】
【課題を解決するための手段】この発明は、上記の課題を解決するためになされたもので、請求項1に記載の発明は、購買側の購買案件を取引先へ提示する第1の過程と、前記取引先が前記購買案件に応じて提示した販売内容を複数の要求元へ提示する第2の過程と、前記複数の要求元からの「承諾」または「非承諾」の回答を集計する第3の過程と、その集計結果に基づいて再検討決定または最終決定を行う第4の過程と、前記第3の過程における集計結果および前記第4の過程における決定結果を前記取引先へ提示する第5の過程とを有し、前記第4の過程において最終決定が行われるまで、前記第2〜第5の過程を繰り返すことを特徴とする購入条件折衝方法である。
【0005】また、請求項2に記載の発明は、請求項1に記載の購入条件折衝方法において、前記取引先が、前記販売内容を提示するにあたり、前回の提示よりどの程度金銭的に改善されているかを示す増加価値相当金額を提示することを特徴とする。また、請求項3に記載の発明は、請求項2に記載の購入条件折衝方法において、前記増加価値相当金額が予め決められた一定値を越えた場合に、前記要求元の注意を引く表示を行うことを特徴とする。また、請求項4に記載の発明は、請求項2に記載の購入条件折衝方法において、前記要求元が前記増加価値相当金額の期待値を提示し、前記取引先の提示した前記増加価値相当金額が前記期待値を越えていた場合は前記要求元の回答を「承諾」と判断し、前記取引先からの販売内容を前記要求元へ提示しないことを特徴とする。
【0006】また、請求項5に記載の発明は、コンピュータに、 購買側の購買案件を取引先へ提示する第1の処理と、前記取引先が前記購買案件に応じて提示した販売内容を複数の要求元へ提示する第2の処理と、前記複数の要求元からの「承諾」または「非承諾」の回答を集計する第3の処理と、その集計結果に基づいて再検討決定または最終決定を行う第4の処理と、前記第3の過程における集計結果および前記第4の過程における決定結果を前記取引先へ提示する第5の処理と、前記第4の過程において最終決定が行わなかった場合に、前記第2〜第5の過程を繰り返す処理を実行させるための購入条件折衝プログラムである。
【0007】
【発明の実施の形態】以下、図面を参照し、本発明の一実施の形態について説明する。図1は、同実施形態による購入条件折衝システムの概略を示す機能ブロックと処理の流れを示す図である。この図において、符号1は購買側の要求元、2は購買側の購買部担当者、3は物品を供給する取引先、4は購入条件折衝システムである。購入条件折衝システム4において、5は要求元の情報が登録される要求元DB(データベース)であり、図2に示すように、要求元ID、ログイン名、パスワード、要求元担当者、所属組織、メールアドレスなどが記録される要求テーブル14を有している。6は案件情報が登録される案件DBであり、図2に示すように、案件ID、要求元IDが記録される案件・要求元関係テーブル15と、案件ID、案件名、公表開始日、公表終了日、提案受付開始日、提案受付終了日、調達数量が記録される案件テーブル16と、案件ID、取引先IDが記録される案件・取引先関係テーブル17を有している。7は取引先情報が登録される取引先DBであり、図2に示すように、取引先ID,ログイン名、パスワード、取引先名、担当者名、メールアドレスなどが記録される取引先テーブル18を有している。8は取引先と要求元間の交渉に関する情報が登録される交渉DBであり、図3に示すように、提案ID、案件ID、取引先ID、提案回数、提案登録日、承諾受付開始日、承諾受付終了日、承諾要求元数、非承諾要求元数、購買部最終判断、提案内容、前回提案価格、提案価格、増加価値相当金額が記録される追加提案テーブル19と、提案ID、案件ID、取引先ID、提案回数、提案登録日、提案価格、が記録される正式提案テーブル20を有している。9は案件公開機能、10は提案管理機能、11は交渉支援機能、12は提案通知機能、13は案件管理機能であり、これらの各機能については以下に記述する。
【0008】次に上述した購入条件折衝システムの動作を図4、5、6を参照しながら詳細に説明する。図4は本システムにアクセスした際の表示画面のイメージである。符号21は取引先3に表示される表示画面イメージ。22は購買側の要求元1に表示される表示画面イメージ。23は購買側の購買部担当者2に表示される表示画面イメージである。図5は本システムの動作を説明するための説明図、図6は本システムの動作フローチャートである。図6のフローチャートにおいて、まず、案件情報が案件DB6に登録され、案件公開機能9に情報が公開される(ステップS1)。その後、案件公開機能9が案件の公表に必要な取引先情報を取引先DB7から得る(ステップS2)。取引先3の営業担当者が本システムにアクセスすると、案件公開機能9により公表された案件の情報が得られる(ステップS3)。案件に関する取引を行いたい取引先3は、購買取引に加わるため、提案の登録を行う(ステップS4)。ステップS4によって提案された情報が交渉DB8の正式提案テーブルに登録される(ステップS5)。取引に加わると、本システムの案件公開機能9により、他取引先の提案状況など、当初提案の有利さ、不利さが取引先3にフィードバックされる(ステップS6)。ここで、取引先3がこの要求に対して、取引の新たな条件を購買側へ提示する追加提案を登録する(ステップS7)。その追加提案において、取引先3の営業担当者は、新たな提案の価格と、その金銭的改善がどのような額になるのかをシステムに登録する(図5参照)。
【0009】いま、例えば、128MBのメモリを内蔵するパソコンについて、前回提案価格が10万円であり、今回、メモリを256MBへ増設し10万5000円の価格で提案したとする。そして、この場合のメモリ容量増加分の市況価格が6000円であったとする。この場合、増加価値相当金額は 増加価値相当金額=市況価値増加分−(今回提案価格−前回提案価格)
=6000−(105000−100000)
=1000なる式によって求められる。また、例えば、30GBのハードディスクを内蔵するパソコンについて、前回提案価格が12万円であり、今回、ハードディスク容量を20GBに減らし、9万円で提案したとする。そして、この場合のハードディスク容量減少分の市況価格が2万5000円であったとする。この場合、増加価値相当金額は、 増加価値相当金額=−25000−(90000−120000)
=5000として求められる。そして、取引先3の営業担当者は、図4に符号21にて示すように追加提案に、前記提案価格提案内容増加価値相当金額今回提案価格を記入し、登録ボタンをクリックする。なお、上述の増加価値相当金額の算出方法は一例であり、前回の提示価格よりどの程度金銭的に改善されているかの数値を表すことができる算出方法であれば上述の算出方法でなくても良い。
【0010】この追加提案の登録を受け、システムは、今回提案の増加価値相当金額をチェックし、ある一定の度合いを越したときには要求元の注意を引くように強調した通知(例えば、<重要>を入れる)を要求元1に送る。次にシステムは、ステップS7の登録を元に交渉支援機能11が交渉DB8の追加提案テーブル19に追加提案を登録する(ステップS8)。次に提案通知機能12に対して要求元1と購買部担当者2への通知が依頼される(ステップS9)。追加提案の通知依頼を受けた提案通知機能12は、その案件に関する情報を案件DB6から、案件の要求元に関する情報を要求元DB5から(ステップS10)、また交渉DB8から交渉情報を取得する(ステップS11)。次に提案通知機能12は案件に関連する複数の要求元1に対して、追加提案を通知し、承諾、非承諾の問い合わせを行い(ステップS12)、それに対して要求元1が承諾、非承諾の登録を行う(ステップS13:図4の22参照)。
【0011】提案通知機能12は交渉DB8の承諾、非承諾のカラムにその結果を加算する(ステップS14)。ステップS12、ステップS13、ステップS14は複数の要求元1ごとに対して、この処理を行う。次に提案通知機能12は交渉DB8に登録された集計結果を集計し(ステップS15)、その集計結果を購買部担当者2へ通知する(ステップS16)。図4の符号23に購買部担当者2の端末に表示される画面イメージを示す。購買部担当者2はこの画面の数値および今までの取引先の提案実績に基づいて購入するか否かの判断を行ない、その結果を提案通知機能12に登録する(ステップS17)。次に提案通知機能12は交渉DB8の追加提案テーブル19に購買部担当者2より得られた結果を登録する(ステップS18)。さらに追加提案の内容を交渉DB8の正式提案テーブル20に反映させる(ステップS19)。その後、提案通知機能12は要求元1に対して最終結果を通知し(ステップS20)、交渉支援機能11に対して取引先3の営業担当者への結果通知を依頼する(ステップS21)。交渉支援機能11は取引先3の営業担当者へ結果を通知する(ステップS22)。ここで、承諾結果、承諾数、非承諾数などが取引先3の営業担当者に通知されることにより、取引先3は今までの要求元1の提案受領傾向、予想行動を判断し、今後の無駄なプロモーションを避けるための判断材料とすることが可能となる。
【0012】上述したステップS7〜ステップS22の過程は取引先3の営業担当者、要求元1、購買部担当者2の間でシステムを介在し反復的に行われる。そして、要求元1の承諾数の比率により、購買部担当者2が最終的な承諾、非承諾の判断をし、結果を登録する。要求元1の全てが追加提案に対して承諾、または非承諾になるとは限らないため、ここで購買部担当者2の最終判断が要求される。この最終的な承諾、非承諾の結果はシステムにより取引先3に通知される。なお、このシステムは、交渉の最終結果を今回の購買物品を要求した要求元だけでなく、購買側企業の各部署に公開することが可能である。これは同時期に実施している類似物品の集中購買に参加している要求元に通知することで実現される。また対象者以外の全てにWebで公開してもよい。これによって、購買側はさらなるボリューム集約による価格低減効果が得られ、取引先3は納入台数の増加を目指すことが可能となる。また、システムで行われた全ての処理をデータベース化することにより、過去情報を蓄積し、次回の入札に活かすことも可能である。
【0013】次に図7〜図12の処理フローを参照しながらシステムに備えられる各機能の処理について説明をする。図7は案件公開機能9の処理フローである。案件公開機能9の処理フローには案件公表画面作成時の処理と、取引先3への案件公表時の処理が備えられる。案件公表画面作成時の処理フローを説明する。まず案件DB6から、公表に必要な情報を取得する(ステップS23)。さらに取引先DB7より公表対象の取引先3の情報を得る(ステップS24)。この2つの情報を元に公表対象の案件が存在するか否かを判断し(ステップS25)、存在する場合には公表対象の案件の公表画面を作成し(ステップS26)、公表画面を該当する取引先3のみにWebで公開し(ステップS27)、その後終了する。公表対象の案件が存在しない場合にはそのまま終了する。取引先3への案件公表時の処理フローを説明する。まず取引先3からのアクセスを受け付ける(ステップS28)。そしてログインIDとパスワードの入力を受け付ける(ステップS29)。ステップS29を元にアカウントが正しいか否かを判断する(ステップS30)。アカウントが正しくない場合はアカウントが正しくない旨の通知を取引先3へ行い(ステップS31)、終了する。アカウントが正しい場合は指定案件情報へのアクセス権があるかどうかを判断する(ステップS32)。アクセス権がない場合は、アクセス権がない旨の通知を取引先3に行い(ステップS33)、終了する。アクセス権がある場合には、公表画面を取引先3に表示する(ステップS34)。
【0014】図8は提案管理機能10の処理フローである。まず、取引先3からのアクセスを受け付けた後(ステップS35)、ログインIDとパスワードの入力を受け付ける(ステップS36)。ステップS36によるアカウントが正しいか否かを判断し(ステップS37)、正しくない場合にはアカウントが正しくない旨の通知を取引先3へ行い(ステップS38)、終了する。アカウントが正しい場合には指定案件情報へのアクセス権があるかどうかを判断し(ステップS39)、アクセス権がない場合にはその旨の通知を取引先3へ行い(ステップS40)終了する。指定案件情報へのアクセスがある場合にはすでに提案した情報が登録されているかどうかを判断し(ステップS41)、すでに提案された情報がない場合には新規提案受付機能を表示し(ステップS42)、変更がなければそのまま終了し、変更がある場合にはステップS44の処理へ移行する。ステップS41において既に提案された情報がある場合には提案内容と提案変更内容画面を表示する(ステップS43)。ここで変更のない場合にはそのまま終了する。ステップS42、ステップS43において共に変更のある場合には取引先3からの提案情報を登録する(ステップS44)。そして結果を表示し(ステップS45)、終了する。
【0015】図9は交渉支援機能11の処理機能における追加提案登録時の処理フローである。まず取引先3からのアクセスを受け付け(ステップS46)、ログインIDとパスワードの入力を受け付ける(ステップS47)。ステップS47よりアカウントが正しいかどうかを判断し(ステップS48)正しくない場合はその旨を取引先3へ通知して(ステップS49)、終了する。アカウントが正しい場合には指定案件情報へのアクセス権があるかどうかを判断し(ステップS50)、アクセス権がない場合には、その旨を取引先3へ通知して(ステップS51)、終了する。ステップS50においてアクセスがある場合には、既に提案した情報が登録されているかどうかが判断される(ステップS52)。登録されていなければ提案受付を催促するメッセージを表示し(ステップS53)、終了する。ステップS52において情報が登録されていれば、提案内容を表示すると共に追加提案内容登録の画面を表示する(ステップS54)。ステップS54において取引先3からの登録がなければそのまま終了する。登録がある場合には取引先3からの追加提案情報を登録し(ステップS55)、結果の表示を行う(ステップS56)。そして提案通知機能12に要求元1への追加提案通知を依頼し(ステップS57)、終了する。
【0016】図10は交渉支援機能11における追加提案結果通知時の処理フローである。まず提案通知機能12から承諾結果を取引先3へ通知するよう依頼を受け(ステップS58)、取引先3に結果が出た旨を通知する(ステップS59)。次に取引先3のアクセスを受け付け(ステップS60)、ログインIDとパスワードの入力を受け付ける(ステップS61)。これによりアカウントが正しいかどうかを判断し(ステップS62)、正しくなければその旨を取引先3へ通知し(ステップS63)終了する。アカウントが正しい場合は、指定案件情報へのアクセス権があるかどうかを判断し(ステップS64)、アクセス権がない場合は、その旨を取引先3へ通知し(ステップS65)、終了する。ステップS64よりアクセス権がある場合には、承諾するか否かの判断をし(ステップS66)、承諾しなければ、非承諾の旨を取引先3に通知し(ステップS67)、終了する。ステップS66において承諾する場合は、追加提案が受け付けられた旨を取引先3に通知し(ステップS68)、終了する。
【0017】図11は提案通知機能12の処理フローである。提案通知機能12の処理フローには要求元通知時の処理と、要求元結果登録時の処理が備えられる。要求元通知時の処理フローについて説明する。まず案件DB6から案件情報を得て(ステップS69)、交渉DB8から追加提案情報を得る(ステップS70)。また要求元DB5より要求元1の通知先リストを得る(ステップS71)。その後、要求元1に通知メールを送信し(ステップS72)、終了する。要求元結果登録時の処理フローについて説明する。まず要求元1からのアクセスを受け付け(ステップS73)、ログインIDとパスワードの入力を受け付ける(ステップS74)。アカウントが正しいかどうかを判断し(ステップS75)、正しくない場合は、その旨を要求元1へ通知し(ステップS76)、終了する。アカウントが正しい場合は、指定案件情報へのアクセス権があるかないかを判断する(ステップS77)。アクセス権がない場合は、その旨を要求元1へ通知し(ステップS78)終了する。アクセス権がある場合には、要求元1の承諾、非承諾の結果を受け付け(ステップS79)、承諾か否かを判断(ステップS80)、承諾しない場合には、交渉DB8の追加提案テーブルの非承諾要求元数に1を加算し(ステップS81)、終了する。ステップS80にて承諾する場合には、交渉DB8の追加提案テーブル19の承諾要求元数に1を加算して(ステップS82)終了する。
【0018】図12は提案通知機能12の処理における購買担当者最終結果登録時の処理フローである。まず、購買部担当者2のアクセスを受け付け(ステップS83)、ログインIDとパスワードの入力を受け付ける(ステップS84)。ステップ84によるアカウントが正しいかどうかを判断し(ステップS85)、アカウントが正しくない場合はその旨を通知し(ステップS86)、終了する。アカウントが正しい場合には、指定案件情報へのアクセス権があるかどうかを判断し(ステップS87)、アクセス権がない場合にはその旨を通知して(ステップS88)、終了する。ステップS87においてアクセス権がある場合は、追加提案判断受付終了日を過ぎたかどうかを判断する(ステップS89)。受付日を過ぎていない場合は、現在の承諾、非承諾の状況を表示し(ステップS90)、終了する。受付日を過ぎた場合は、最終的な承諾、非承諾の集計数を表示し(ステップS91)、追加提案を承諾するか否かの購買部担当者2の最終判断を登録する(ステップS92)。そして、交渉DB8の追加提案テーブル19に最終結果を登録し(ステップS93)、交渉DB8の正式提案テーブル20に追加提案内容を反映させて(ステップS94)、さらに交渉支援機能11に結果を通知し(ステップS95)、終了する。なお、上記実施形態において、予め個々の要求元1がそれぞれ自動受け入れする提案の増加価値相当金額の期待値(金銭的改善効果のMin値)をシステムに登録させておき、取引先3の提案内容がその期待値を上回る提案をした場合には、要求元に通知せず、承諾したものとして処理するようにしてもよい。また、上記実施形態は最終判断を購買部担当者2が行っているが、これに対して、承諾数の比率に基づいて自動的に決めるようにしてもよい。また、上記実施形態は購買側の要求元が一企業内の複数要求元である例を説明しているが、要求元が複数企業となる複数企業の共同購買という形式でもよい。
【0019】
【発明の効果】以上説明したように、この発明によれば、購買側の購買案件を取引先へ提示する第1の過程と、前記取引先が前記購買案件に応じて提示した販売内容を複数の要求元へ提示する第2の過程と、前記複数の要求元からの「承諾」または「非承諾」の回答を集計する第3の過程と、その集計結果に基づいて再検討決定または最終決定を行う第4の過程と、前記第3の過程における集計結果および前記第4の過程における決定結果を前記取引先へ提示する第5の過程とを有し、前記第4の過程において最終決定が行われるまで、前記第2〜第5の過程を繰り返す過程とを設けたので、購買側の複数要求元と取引先との購買条件のネゴシエーションが電子的に行われ、購買側の案件提案から取引成立までの一貫した電子取引の実現が可能になり、購買に関わる各処理を迅速に行うことが可能となる。また取引先の営業担当者と購買側の購買部担当者の間でのみ実施されていたネゴシエーションに購買側の要求元を含めることによって、より要求元の要求条件にあった商品を購入することが可能になると共に、従来購買部担当者が勘と経験で実施していた追加提案の判断に、蓄積された過去の追加提案の受け入れ状況といった電子情報の活用を行うことによって、採用判断のミスを防ぎ、過去の購買ノウハウの有効活用が可能となる。




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013