(57)【要約】【課題】商談内容に変更があった場合に再度の承認の要否を容易に判断することができる商談承認要否判断方法の提供を目的とする。【解決手段】商談に対する承認の要否を判断する商談承認要否判断方法であって、コンピュータが、前記商談に関する商談情報と、当該商談情報と同一の商談に関する前回の商談情報との差分である差分情報を算出する差分算出手順と、前記差分算出手順において算出された前記差分情報が所定の条件を満たしているか否か判断する差分判断手順とを有することにより上記課題を解決する。【選択図】        図１
2004192540.tif 000002
【特許請求の範囲】
【請求項１】
商談に対する承認の要否を判断する商談承認要否判断方法であって、
コンピュータが、前記商談に関する商談情報と、当該商談情報と同一の商談に関する前回の商談情報との差分である差分情報を算出する差分算出手順と、
前記差分算出手順において算出された前記差分情報が所定の条件を満たしているか否か判断する差分判断手順とを有することを特徴とする商談承認要否判断方法。
【請求項２】
前記差分判断手順は、
前記差分情報の変動度合いに応じて前回の決裁ランクからの該決裁ランクの変動値を示すテーブルから前記差分算出手順において算出された前記差分情報に対応する該決裁ランクの変動値を取得するランク変動値取得手順と、
前記前回の決裁ランクと前記変動値とによって前記商談を決裁すべき承認者を決定する承認者決定手順とを有することを特徴とする請求項１記載の商談承認要否判断方法。
【請求項３】
前記差分算出手順において算出された前記差分情報と、前記差分判断手順において判断された判断結果とを、ネットワークを介して接続される端末に表示させる判断結果表示手順を有することを特徴とする請求項１又は２記載の商談承認要否判断方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、商談に対する承認者による承認の要否を判断する商談承認要否判断方法に関する。
【０００２】
【従来の技術】
営業担当者等が顧客との間で商談を進める場合、商談に関する種々の情報が発生する。従来から、このような商談情報を電子的に管理することより、商談に伴う作業を効率化させるための手法が存在する（例えば、特許文献１及び特許文献２）。
【０００３】
ところで、商談を進めるにあたり、営業担当者は、商談の進行中のある時点での見積もりとして商談の対象となっている製品及びその価格に基づいて損益を計算し、承認者の承認を受ける必要があるのが一般である。また、商談の進行に伴い、承認の価格、数量の変更等、商談の内容が見積もり当初と異なるものとなる場合がある。かかる場合には、最終的な損益に影響が及ぶため、変更後の内容について承認者に再度承認を受ける必要がある。但し、企業によっては、承認者の負担や迅速な処理等を考慮して、ほとんど損益に影響が及ばない程度の変更等については再承認を不要としているところもある。
【０００４】
再承認が不要である場合、従来は、再承認の要否について営業担当者に判断を委ねるか、又は判断基準を明記したマニュアル等を作成し、そのマニュアルに基づいて判断が行われていた。
【０００５】
【特許文献１】
特開２０００−１２３０８１号公報
【０００６】
【特許文献２】
特開２０００−１１３０３９号公報
【０００７】
【発明が解決しようとする課題】
しかしながら、営業担当者に判断を委ねると、それぞれの担当者によって判断基準がばらばらとなり、実際には損益に重大な影響が及ぶような重要な場合について報告がされないという問題が発生する。また、マニュアルによって判断する場合においては、その都度マニュアルを参照して判断しなければならず、営業担当者にとって非常な手間となっていた。
【０００８】
本発明は、上記の点に鑑みてなされたものであって、商談内容に変更があった場合に再度の承認の要否を容易に判断することができる商談承認要否判断方法の提供を目的とする。
【０００９】
【課題を解決するための手段】
そこで上記課題を解決するため、本発明は、商談に対する承認の要否を判断する商談承認要否判断方法であって、コンピュータが、前記商談に関する商談情報と、当該商談情報と同一の商談に関する前回の商談情報との差分である差分情報を算出する差分算出手順と、前記差分算出手順において算出された前記差分情報が所定の条件を満たしているか否か判断する差分判断手順とを有することを特徴とする。
【００１０】
このような商談承認要否判断方法では、コンピュータが今回の商談情報と前回の商談情報との差分情報が所定の条件を満たしているか否かを判断するため、所定の条件として商談の要否の判断の基準を設定しておくことにより、商談内容に変更があった場合に再度の承認の要否を容易に判断することができる。
【００１１】
【発明の実施の形態】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における商談管理システムの構成例を示す図である。図１の商談管理システム１は、商談管理サーバ１０と、承認者端末２０と、報告者端末３０とがインターネット、又はイントラネット等のネットワーク４０によって接続されている。
【００１２】
報告者端末３０は、顧客との間で商談を行っている営業担当者等、商談に関する情報を報告する者（以下「報告者」という。）が利用するＰＣ（Personal Computer）、ＰＤＡ（Personal Digital(Data) Assistants）、携帯電話等の端末である。報告者端末３０は、報告者によって入力された商談情報を商談管理サーバ１０に送信するとともに、商談管理サーバ１０から送信された各種情報を表示し、報告者に提示する。
【００１３】
承認者端末２０は、報告者の上司等、商談の内容について承認するか否かを決裁する権限を有する者（以下「承認者」という。）が利用するＰＣ、ＰＤＡ、携帯電話等の端末である。承認者端末２０は、報告者が商談管理サーバ１０に登録した商談情報を表示するとともに、商談情報を表示した商談に対する承認の入力を承認者から受け付け、商談管理サーバ１０に送信する。
【００１４】
商談管理サーバ１０は、報告者端末３０から受信した商談情報を管理すると共に、商談の進行に応じて商談の内容に変更が生じた場合に、再度その商談について承認者による承認が必要であるか否かを判断するコンピュータである。
【００１５】
なお、本発明の実施の形態においては、商談管理サーバ１０は、Ｗｅｂサーバの機能を有している。即ち、商談管理サーバ１０は、そのサービスをＷｅｂページによって承認者端末２０や報告者端末３０に提供することができる。従って、承認者や報告者は、それぞれ承認者端末２０又は報告者端末３０にインストールされているＷｅｂブラウザに表示されたＷｅｂページを通して商談管理サーバ１０のサービスを受けることができる。
【００１６】
更に、図１を参照しつつ、商談管理サーバ１０の機能構成例について説明する。図１において、商談管理サーバ１０は、送受信処理部１１０、報告者用処理部１２０、承認者用処理部１３０、顧客・担当ＤＢ２０１、損益情報ＤＢ２０２、損益明細情報ＤＢ２０３、決裁情報ＤＢ２０４、再承認条件情報ＤＢ２０５、変動チェック項目マスタ３０１、損益変動条件マスタ３０２、従業員マスタ３０３、職制マスタ３０４、理由メッセージマスタ３０５、及び承認者マスタ３０６等から構成される。
【００１７】
送受信処理部１１０は、商談管理サーバ１０と承認者端末２０及び報告者端末３０との間のデータの送受信に係る処理を実行するものであり、報告・結果情報送信手段１１１及び報告・結果情報受信手段１１２等から構成される。報告・結果情報送信手段１１１は、報告者端末３０から送信された商談情報（報告情報）を表示するＷｅｂページを承認者端末２０に送信したり、承認者端末２０から商談情報が送信された商談に対する決裁結果（結果情報）を表示するＷｅｂページを報告者端末３０に送信したりする。報告・結果情報受信手段１１２は、報告者端末３０から送信された商談情報や、承認者端末２０から送信された決裁結果を受信する。
【００１８】
報告者用処理部１２０は、主として報告者端末３０に関する処理を実行するものであり、損益計算手段１２１、承認要否判断手段１２２、データ更新手段１２３、報告依頼処理手段１２４等から構成される。損益計算手段１２１は、商談についての損益等の計算を行うための機能である。承認要否判断手段１２２は、商談について承認者による承認が必要であるか否かを判断するための機能である。データ更新手段１２３は、損益情報ＤＢ２０２等、各種データベースのデータを更新するための機能である。報告依頼処理手段１２４は、報告者端末３０に表示させる、商談の報告用のＷｅｂページの生成等を行うための機能である。
【００１９】
承認者用処理部１３０は、主として承認者端末２０に関する処理を実行するものであり、報告データ編集手段１３１、決裁処理手段１３２、データ更新手段１３３、結果処理依頼手段１３４等から構成される。報告データ編集手段１３１は、報告者が入力した情報より、承認者が確認すべき情報を編集する機能である。決裁処理手段１３２は、承認者端末２０より商談に対する承認の可否の決裁が送信された際の処理を実行するための機能である。データ更新手段１３３は、各種データベースのデータを更新するための機能である。結果処理依頼手段１３４は、承認者端末２０に表示させる、商談に対する決裁を行うためのＷｅｂページの生成等を行うための機能である。
【００２０】
なお、図１における顧客・担当ＤＢ２０１等の各種ＤＢや、変動チェック項目マスタ３０１等の各種マスタの詳細については後述する。
【００２１】
次に、商談管理サーバ１０のハードウェア構成例について説明する。図２は、本発明の実施の形態における商談管理サーバのハードウェア構成例を示す図である。図２の商談管理サーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、インタフェース装置１０５とを有するように構成される。
【００２２】
商談管理サーバ１０での処理を実現する商談管理プログラムは、CD―ROM等の記憶媒体１０１によって提供される。商談管理プログラムを記録した記憶媒体１０１は、ドライブ装置１００にセットされ、商談管理プログラムが記憶媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。
【００２３】
補助記憶装置１０２は、インストールされた商談管理プログラムを格納すると共に、必要なファイルやデータ等を格納する。例えば補助記憶装置１０２は、商談管理プログラムの処理に必要な、顧客・担当ＤＢ２０１等を格納している。
【００２４】
メモリ装置１０３は、商談管理プログラムの起動指示があった場合に補助記憶装置１０２から商談管理プログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納された商談管理プログラムに従って商談管理サーバ１０に係る機能を実行する。インタフェース装置１０５は例えばモデム、ルータ等で構成され、図１のネットワーク４０に接続するために用いられる。
【００２５】
なお、演算処理装置１０４が商談管理プログラムを実行することで、送受信処理部１１０、報告者用処理部１２０、承認者用処理部１３０等が商談管理サーバ１０において実現される。
【００２６】
以下、図１の商談管理システム１の処理手順について説明する。図３及び図４は、商談管理システムの処理を説明するためのフローチャート図である。
【００２７】
ステップＳ１０において、商談を得た報告者が報告者端末３０において商談の内容を表す商談情報を入力すると、報告者端末３０は、商談管理サーバ１０に商談情報を送信する。既に商談管理サーバ１０に登録済み（過去に報告済み）の商談の商談情報を入力する場合は、商談番号、帳票番号、型名、顧客提示単価、数量を入力する。
【００２８】
商談番号は、商談を一意に識別するための管理番号である。帳票番号は、帳票の種類を識別するための番号である。型名とは、商談の対象となっている商品を一意に識別するためのコードである。顧客提示単価とは、顧客に提示した商品の単価である。数量とは、商談の対象となっている商品の数量である。
【００２９】
また、新規の商談（商談管理サーバ１０には未登録の商談）の商談情報を入力する場合は、上記の他、顧客名、顧客住所等を入力する。なお、一つの商談において複数の商品が対象となる場合があるが、その場合は、それぞれの商品の顧客提示価格及び数量を入力する。
【００３０】
なお、ここでは既存の商談の商談情報を入力したこととして以下を説明する。
【００３１】
商談情報を受信した商談管理サーバ１０のデータ更新手段１２３は、受信した商談情報を損益明細情報ＤＢ２０３に登録する。
【００３２】
図５は、損益明細情報ＤＢの構成例を示す図である。損益明細情報ＤＢは、商談の明細情報を格納するデータベースであり、商談の対象となっている商品毎に、商談番号、帳票番号、版数、作成日、更新日、番号、型名、数量、標準単価、標準合価、顧客提示単価、顧客提示合価、価格率、仕切価格、粗利金額、及び粗利率等の情報を管理する。
【００３３】
「商談番号」、「帳票番号」、「型名」、「数量」、「顧客提示単価」は、上述したものと同義である。「版数」は、商談毎の明細情報をいわゆるバージョン管理するための番号である。「作成日」、「更新日」はそれぞれ各レコードが作成又は更新された日である。「番号」は、一つ商談に対して複数のレコードが登録される場合（例えば、一つの商談において複数の商品が対象となっている場合）、当該商談の中で各レコードを一意に識別するための番号である。「標準単価」は、商品の標準単価である。「標準合価」は、標準単価に数量を乗じた値である。「顧客提示合価」は、「顧客提示単価」に数量を乗じた値である。「価格率」は、「標準単価」に対する「顧客提示価格」の割合である。「仕切価格」は損益が０となる「数量」分の基準の価格である。「粗利金額」は、粗利、即ち、「顧客提示合価」から「仕切価格」を引いた値である。「粗利率」は、「顧客提示合価」に対する「粗利金額」の割合である。
【００３４】
「商談番号」、「帳票番号」、「型名数量」、「顧客提示単価」には、報告者端末３０から受信した値がそのまま登録される。「作成日」、「更新日」、「版数」は、データ更新手段１２３によって自動的に登録される。「標準単価」、「標準合価」、「顧客提示合価」、「価格率」、「仕切価格」、「粗利金額」、及び「粗利率」等には、損益計算手段１２１が報告者端末１０から送信された型名、数量、顧客提示単価と、図示しない商品情報マスタに登録されている情報とに基づいて計算した値が登録される。なお、商品情報マスタには、商品の標準単価や、商品一つあたりの仕切価格等が登録されている。
【００３５】
図５の例においては、１〜３行目までが、商談番号が１２３４５６の商談（以下、「商談１２３４５６」という。）の第一版、即ち、前回の商談情報についてのレコードであり、４〜８行目までが、今回商談内容の変更により新たに登録された、商談１２３４５６の第二版の商談情報についてのレコードである。図５より、商談１２３４５６については当初（前回）は、型名がＡ、Ｂ、Ｃの商品のみが対象であったが、現在（今回）は、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦの商品が対象となっていることが分かる。
【００３６】
更に、データ更新手段１２３は、損益明細情報ＤＢ２０３に登録した値を商談毎に合計した値を損益情報ＤＢ２０２に登録する。図６は、損益情報ＤＢの構成例を示す図である。損益情報ＤＢ２０２は、損益明細情報ＤＢ２０３で管理されている情報を商談毎に合計した値を管理するデータベースであり、商談毎に商談番号、帳票番号、版数、報告者、作成日、更新日、収入（提示価格）合計、支出（仕切価格）合計、標準価格合計、粗利合計、価格率、粗利率、費用、数量等の情報を管理する。
【００３７】
「商談番号」、「帳票番号」、「版数」は、上述したものと同義である。「報告者」は、報告者端末３０から商品情報を報告した報告者の社員番号等の識別情報が登録される。「作成日」、「更新日」はそれぞれ各レコードが作成又は更新された日である。「収入合計」、「支出合計」、「標準価格合計」、「粗利合計」は、それぞれ損益明細情報ＤＢ２０３の顧客提示合価、仕切価格、標準合価、粗利金額、数量を商談毎に合計したものである。価格率は、標準価格合計に対する収入合計の割合である。粗利率は、収入合計から支出合計を引いた値を収入合計で割ったものである。費用は、商談を推進又は取得するにあたり発生する経費や、各種手数料、インセンティブ等で商談の粗利を判定することが不可欠なものである。
【００３８】
図６においては、一行目に商談１２３４５６の前回（第一版）についてのレコードを、二行目に今回新たに登録された商談１２３４５６の第二版のレコードの例を示している。
【００３９】
なお、顧客と商談を担当している報告者との関連付けについては、図７の顧客・担当情報ＤＢ２０１で管理されている。また、各報告者又は承認者等、社員の情報については図８の従業員マスタ３０３及び図９の職制マスタ３０４によって管理されている。
【００４０】
ステップＳ１０に続いてステップＳ２０に進み、商談管理サーバ１０の報告者用処理部１２０は、報告者端末３０から受信した商談情報、即ち、商談１２３４５６は、既存の商談であるかどうかを判断する。商談１２３４５６は、既に第一版が登録されているため既存の商談であると判断し、ステップＳ３０に進む。なお、報告者端末３０から受信した商談情報が新規の商談情報である場合は、ステップＳ２０に続いて後述するステップＳ１３０の処理を実行する。
【００４１】
ステップＳ３０からＳ５０において、承認要否判断手段１２２は、今回の商談情報（商談１２３４５６（第二版））と前回の商談情報（商談１２３４５６（第一版））との差異が、所定の条件を満たしているかどうかを判断するための処理を実行する。まずステップＳ３０において、承認要否判断手段１２２は、変動チェック項目マスタ３０１を読み込み、損益情報ＤＢ２０２を構成するデータ項目のうち、どの項目をチェック対象として承認の要否の判断をすべきかを認識する（Ｓ３０）。
【００４２】
図１０は、変動チェック項目マスタの構成例を示す図である。変動チェック項目マスタ３０１は、承認の要否の判断する際にチェック対象とするデータ項目（以下「チェック項目」という）を特定するためのテーブルであり、チェック項目を一意に識別するためのコードである「種別」と、チェック項目の名前である「項目名」とをデータ項目として有する。図１０より、本実施の形態においては、粗利率、価格率、商談規模、数量がチェック項目であることが分かる。即ち、承認要否判断手段１２２は、前回の商談情報における粗利率等と今回の商談情報における粗利率等を比較して、承認者による承認が必要であるか否かを判断することを示す。なお、粗利率、価格率、数量は、損益情報ＤＢ２０２におけるものと同義である。また、商談規模とは、損益情報ＤＢ２０２における収入合計を意味する。
【００４３】
ステップＳ３０に続いてステップＳ４０に進み、承認要否判断手段１２２は、損益情報ＤＢ２０２を参照して、今回の商談情報と前回の商談情報の各チェック項目の差（変動量）を求める。即ち、今回の粗利率、価格率、商談規模、数量から前回の粗利率、価格率、商談規模、数量をそれぞれ引いた値を求める。従って、商談１２３４５６については第二版の値から第一版の値を引くことになり、粗利率の変動量は−５．５、価格率の変動量は０、商談規模（収入合計）の変動量は１００００００、数量の変動量は３５となる。
【００４４】
ステップＳ４０に続いてステップＳ５０に進み、承認要否判断手段１２２は、各チェック項目の変動量が損益変動条件マスタ３０２に管理されている条件に合致するか否かを比較し、承認の要否を判断する。但し、いずれのチェック項目についても変動量が０だった場合は、承認要否判断手段１２２は、損益変動条件マスタ３０２を確認することなく承認は不要であると即座に判断する。
【００４５】
商談１２３４５６は、粗利率及び商談規模について変動があるため損益変動条件マスタ３０２との対比を行う。
【００４６】
図１１は、損益変動条件マスタの構成例を示す図である。損益変動条件マスタ３０２は、承認の要否及び決裁ランクの変動量を判断するための条件（以下「決裁ランク変動条件」という。）を管理するためのテーブルである。ここで、決裁ランクとは、誰を承認者とするかを決めるためのパラメータである。即ち、決裁ランクの値によって、例えば部長クラスの承認が必要であるとか、支店長クラスの承認が必要であるとかが決まる。
【００４７】
損益変動条件マスタ３０２は、種別、コード、項目名、基準値（下限）、基準値（上限）、単位、及び決裁ランク変動量等のデータ項目を有する。「種別」は変動チェック項目マスタ３０１で管理されているチェック項目の種別である。「コード」は、同一のチェック項目について複数の条件が設定された場合に各条件を一意に識別するための値である。即ち、損益変動条件マスタ３０２においては、同一のチェック項目に対して複数の条件を設定することができ、一つの条件に一つのレコードが対応している。
【００４８】
「基準値（下限）」及び「基準値（上限）」は、チェック項目の変動量を対象とした、承認の要否及び決裁ランクの変動量を判断するための条件である。即ち、チェック項目の変動量が、いずれかのレコードの決裁ランク変動条件に合致すれば承認は必要であると判断され、そのレコードの「決裁ランク変動量」だけ前回の決裁ランクに対して今回の決裁ランクが変動する。また、全てのチェック項目の変動量について、いずれの条件にも合致しなければ、承認は不要であると判断される。「決裁ランク変動量」は、決裁ランク変動条件に合致した場合に、前回同一の商談について承認を受けた際の決裁ランク（以下「前回の決裁ランク」という。）に対する変動量である。なお、前回の決裁ランクは、後述する決裁情報ＤＢ２０４に管理されている。
【００４９】
例えば、図１１の損益変動条件マスタ３０２より、粗利率の変動量が−５．０以上０未満の場合（一行目の条件）は、決裁ランクが１加算されることが分かり、−１０．０以上−５．１以下の場合は、決裁ランクが２加算されることが分かる。価格率、商談規模、数量等の各チェック項目についてもそれぞれ決裁ランク変動条件が設定されている。
【００５０】
なお、本実施の形態における変動チェック項目マスタ３０１及び損益変動条件マスタ３０２には、承認の要否等の判断条件として、損益に大きな影響を与える要因となりうる条件が登録されている。これによって承認要否判断手段１２２は、チェック項目の変動が損益に大きな影響がある場合には承認者による承認が必要であると判断することができ、損益にあまり影響がない場合には承認者による承認は不要であると判断することができる。但し、承認の要否の判断条件は、損益に関するパラメータのみに限定されるものではない。例えば、特定の顧客の商談については、常に承認が必要である等、の条件を追加してもよい。その条件が、本実施の形態における損益変動条件マスタ３０２の形式に合致しない場合は、別の形式のテーブルによってその条件を管理すればよい。
【００５１】
ここで、商談１２３４５６については、粗利率及び商談規模のいずれの変動量についても、いずれかの決裁ランク判断条件に合致するため、ステップＳ６０に進む。ステップＳ６０において、承認要否判断手段１２２は、チェック項目の変動が複数の決裁ランク変動条件に合致したか否かをし、複数の決裁ランク変動条件に合致した場合はステップＳ７０に進む。一つの決裁ランク変動条件のみに合致した場合は、合致した決裁ランク変動条件に対する決裁ランク変動量を有効な決裁ランク変動量（以下「有効決裁ランク変動量」という。）としてステップＳ８０に進む。商談１２３４５６については上述したように、粗利率の変動量は−５．５であるため２行目の決裁ランク変動条件に合致し、商談規模の変動量は１０００００であるため６行目の決裁ランク判断条件に合致する。即ち合計二つの決裁ランク変動条件に合致するため、ステップＳ７０に進む。
【００５２】
ステップＳ７０において、承認要否判断手段１２２は、合致した決裁ランク変動条件のうち、決裁ランク変動量の値が最も大きいものを有効決裁ランク変動量として選出する。商談１２３４５６については、粗利率の変動によって該当した決裁ランク変動条件に対する決裁ランク変動量が＋２であり、他の決裁ランク変動条件における決裁ランク変動量よりも大きいため、＋２が有効決裁ランク変動量となる。
【００５３】
ステップＳ７０に続いてステップＳ８０に進み、承認要否判断手段１２２は、前回の決裁ランクに有効決裁ランク変動量を足して、今回の決裁ランクとする。商談１２３４５６については、前回の決裁ランクが例えば１であったとすると、１＋２＝３より、３が今回の決裁ランクとなる。
【００５４】
ステップＳ８０に続いて図４のＳ９０に進み、承認要否判断手段１２２は、決裁ランクに応じた承認者を、承認者マスタ３０６を参照して判定する。
【００５５】
図１２は、承認者マスタの構成例を示す図である。承認者マスタ３０６は、決裁ランク毎に決裁ランクに対応する承認者を管理するテーブルであり、決裁ランクと承認者とをデータ項目として有する。図１２の例では、決裁ランクが１又は２の場合は部長の承認が必要であり、決裁ランクが３又は４の場合は支店長の承認が必要であることが分かる。商談１２３４５６については、決裁ランクが３であるため、支店長が承認者として決定される。
【００５６】
更に、データ更新手段１２３は、再度の承認が必要となった理由等を再承認条件ＤＢ２０５に登録する。図１３は、再承認条件ＤＢの構成例を示す図である。再承認条件ＤＢ２０５は、再度承認が必要となった理由（以下、「要承認理由」という。）毎にその理由に関する情報を管理するデータベースであり、商談番号、帳票番号、版数、通番、更新日、作成日、及び理由コード等のデータ項目から構成される。商談番号、帳票番号、版数、更新日、及び作成日については上述したものと同義である。通番は、一つの商談について複数の要承認理由がある場合に、それぞれを識別するための番号である。
【００５７】
理由コードは、損益変動条件マスタ３０２においてそれぞれの要承認理由の根拠となった決裁ランク変動条件に対応する「種別」と「コード」を並べて二桁の数字にしたものである。例えば、今回の商談１２３４５６については、承認条件ＤＢ２０５の１行目と２行目にレコードが登録されており、それぞれの理由コードは、「１２」と「３１」となっている。今回の商談１２３４５６が該当した決裁ランク変動条件は損益変動条件マスタ３０２において、２行目と６行目のレコードであり、２行目の種別は１、コードは２である。従って、これを並べると「１２」となる。同様に６行目のレコードの種別は３、コードは１であり、これを並べると「３１」となる。よって、再承認条件ＤＢ２０５の理由コードには、それぞれ「１２」と「３１」とが登録されている。
【００５８】
ステップＳ９０に続いてステップＳ１００に進み、報告依頼処理手段１２４は、報告を受けた商談情報について再度承認が必要である旨を通知するＷｅｂページ（以下「承認要通知ページ」という。）を生成する。更に、報告・結果情報送信プログラム１１１が承認要通知ページを報告者端末３０に送信すると、承認要通知ページが報告者端末３０のＷｅｂブラウザに表示される。
【００５９】
図１４は、承認要通知ページの表示例を示す図である。承認要通知ページ３１は、理由表示領域３１１、承認者表示領域３１２、修正ボタン３１３、及び承認依頼ボタン３１４等から構成される。理由表示領域３１１は、「理由」、「今回」、及び「承認済」等の項目を有するテーブル形式となっている。「理由」には、承認が必要となった理由が表示される。「今回」には、「理由」の対象となったチェック項目の今回の値が表示される。「承認済」には前回のチェック項目の値が表示される。
【００６０】
なお、理由表示領域３１２には、全ての理由が表示させることができ、図１４の例では、承認済内容（前回の商談情報）より粗利率が５．５％悪化したこと、及び承認内容済内容より商談規模が１００万円増加したことが承認の必要となった理由として表示されている。
【００６１】
承認者表示領域３１２は、後述する決裁情報ＤＢ２０４に登録されている情報に基づいて前回と今回の商談について、「承認者」と「状態」とを表示する領域である。ここで「状態」には、承認の可否についての決裁の状態が表示される。従って図１４より、前回の承認依頼は部長によって承認済みであり、今回は支店長による承認が必要であるということが分かる。
【００６２】
修正ボタン３１３は、承認を依頼する前に報告者自身が商談情報について再検討する場合に押すボタンである。例えば、再検討する余地があり、それによって前回からの変動が承認を必要としない範囲内（損益変動条件マスタ３０２に登録されている条件の範囲外）とできる場合等が相当する。即ち、修正ボタン３１３を押すとステップＳ１０に進み、報告者は報告者端末３０において再検討した商談情報を入力することができる。承認依頼ボタン３１４は、このまま承認者に承認を依頼する場合に押すボタンである。
【００６３】
報告者は、承認要通知ページ３１を確認することで、自分が報告した商談情報について、承認者による承認が必要であること、及び承認が必要な理由を容易に確認することができる。
【００６４】
なお、「理由」に表示されるメッセージの雛形は、理由メッセージマスタ３０５に格納されている。図１５は、理由メッセージマスタの構成例を示す図である。理由メッセージマスタ３０５は、承認要通知ページ３１や後述するＷｅｂページに表示する、承認が必要な理由を表示するためのメッセージ（以下「理由メッセージ」という。）の雛形をチェック項目の種別毎に管理するテーブルであり、「種別」と「理由メッセージ」とのデータ項目から構成される。「種別」は、変動チェック項目マスタ３０１における「種別」に対応する値が登録されている。「理由メッセージ」には、メッセージ文字列が登録されている。従って、例えば、粗利率について変動があった場合は、「承認済み内容より粗利率がＸＸＸ．Ｘ％悪化」という理由メッセージが表示されることが分かる。なお、理由メッセージ中「Ｘ」については実際の値に置き換えられて表示される。
【００６５】
報告者が承認要通知ページ３１において承認依頼ボタン３１４を押すとステップＳ１３０に進み、データ更新手段１３３は、承認依頼に関する情報を決裁情報ＤＢ２０４に登録する。
【００６６】
図１６は、決裁情報ＤＢの構成例を示す図である。決裁情報ＤＢ２０４は、商談情報の報告毎に承認の可否の決裁についての情報を管理するデータベースであり、商談番号、帳票番号、版数、作成日、更新日、決裁ランク、決裁番号、承認者処理日、及び状態等のデータ項目から構成される。「商談番号」、「帳票番号」、「版数」、「作成日」、「更新日」、及び「決裁ランク」は上述したものと同義である。「決裁番号」には、承認者により決裁が行われた際にその手続きを一意に識別するための番号が登録される。「承認者処理日」には、承認者により決裁が行われた日が登録される。「状態」は、決裁の状態を示すコードが登録され、「０」は決裁が申請中であることを意味し、「１」は承認済みであることを意味し、「２」は却下されたことを意味する。なお、今回の商談１２３４５６については、２行目のレコードとして登録されている。
【００６７】
ステップＳ１２０に続いてステップＳ１３０に進み、承認者が承認者端末２０において今回の商談についての承認依頼に対して決裁を行うべく商談管理サーバ１０にアクセスすると、商談管理サーバ１０の決裁処理手段１３２は、承認の可否を入力するＷｅｂページ（以下「決裁ページ」という。）を生成し、承認者端末２０に送信する。
【００６８】
図１７は、決裁ページの表示例を示す図である。決裁ページ３２は、承認者が商談について承認の可否を決裁するためのページであり、商談情報表示領域３２１、損益情報表示領域３２２、理由表示領域３２３、承認者表示領域３２４、前回承認情報ボタン３２５、却下ボタン３２６、及び承認ボタン３２７等から構成される。商談情報表示領域３２１には顧客・担当情報ＤＢ２０１に登録されている顧客名等が表示される。損益情報表示領域３２２には損益情報ＤＢ２０２に登録されている今回の商談についての損益情報が表示される。
【００６９】
理由表示領域３２３と承認者表示領域３２４のそれぞれには承認要通知ページ３１における理由表示領域３１１、承認者表示領域３１２と同じ内容が表示される。前回承認情報ボタン３２５は、既に承認されている前回の商談情報を表示させる際に押すボタンである。却下ボタン３２６は、承認依頼を却下する際に押すボタンである。承認ボタン３２７は、承認する際に押すボタンである。
【００７０】
承認者は、決裁ページ３２を確認することで、過去に承認されている商談について何故再度承認が必要となったのかを容易に確認することができ、かつ的確な判断を下すことができる。
【００７１】
ステップＳ１３０に続いてステップＳ１４０に進み、承認者が承認すべく決裁ページ３２の承認ボタン３２７を押すと、承認者端末２０は、その旨を商談管理サーバ１０に送信する。ステップＳ１４０に続いてステップＳ１５０に進み、商談管理サーバ１０の決裁処理手段１３２は、決裁情報ＤＢ２０４における今回の商談についての「状態」を１（承認）とする（Ｓ１５０）。なお、承認が却下された場合、即ち、決裁ページ３２の却下ボタンが押された場合は、決裁処理手段１３３は決裁情報ＤＢ２０４における今回の商談についての「状態」を２（却下）とし、更に、却下された旨を報告者端末３０に送信する（Ｓ１６０）。
【００７２】
なお、ステップＳ５０において、承認要否判断手段１２２が承認者による承認は不要であると判断した場合、即ち、全てのチェック項目の変動量が０だった場合、又は、変動量が０以外であっても、損益変動条件マスタ３０２に登録されているいずれの決裁ランク変動条件にも合致しなかった場合は、ステップＳ１７０に進む。
【００７３】
ステップＳ１７０において、報告依頼処理手段１２４が承認は必要ない旨を通知するＷｅｂページ（以下「承認不要通知ページ」という。）を生成し、報告者端末３０に送信すると、承認不要通知ページが報告者端末３０に表示される。
【００７４】
図１８は、承認不要通知ページの表示例を示す図である。承認不要通知ページ３３は、チェック項目表示領域３３１、承認者表示領域３３２、修正ボタン３３３、及び確定ボタン３３４等から構成される。チェック項目表示領域３３１は、値が変動したチェック項目について、今回の値と前回（承認済）の値が表示される領域である。承認者表示領域３１２は、承認要通知ページ３１における承認者表示領域３１１と同様であるが、承認不要通知ページ３３においては、今回の承認者の覧に「再承認不要」と表示されている。
【００７５】
修正ボタン３３３は、商談情報について修正したい場合に押すボタンである。即ち、修正ボタン３３３を押すとステップＳ１０に進み、報告者は報告者端末３０において再検討した商談情報を入力することができる。確定ボタン３３４は、このまま商談情報を確定する場合に押すボタンである。
【００７６】
報告者は、承認不要通知ページ３３を確認することで、自分が報告した商談情報については、承認が不要であることを容易に確認することができる。
【００７７】
報告者が承認依頼ボタン３３４を押すとステップＳ１９０に進み、データ更新手段１２３は、決裁情報ＤＢ２０４に今回の商談についてのレコードを「決裁ランク」の値は０、「状態」の値は１（承認）として登録する。
【００７８】
次に、変動チェック項目マスタ３０１及び損益変動条件マスタ３０２を編集するための画面について説明する。図１９は、マスタデータ登録画面の表示例を示す図である。マスタデータ登録画面１１は、変動チェック項目選択領域１１１、決裁ランク変動条件入力領域１１２、及び登録実行ボタン１１３等から構成される。
【００７９】
変動チェック項目選択領域１１１は、チェック項目とするデータ項目を選択するための領域であり、「選択」、「項目名」、「属性」、及び「項目長」等の項目からなる表形式となっている。「選択」は、選択ボタンになっており、この選択ボタンを選択することで、チェック項目とするデータ項目を選択することができる。「項目名」には、データ項目の名前が表示される。「属性」には、データ項目のデータ形式が表示される。「項目長」には、データ項目のデータ長が表示される。変動チェック項目表示領域１１１において、選択ボタンが選択されているレコードのうち、任意のレコードを選択すると、選択されたレコードに係るチェック項目に対する変動条件を変動条件入力領域１１２において入力することができる。
【００８０】
変動条件入力領域１１２は、「コード」、「基準値（下限）」、「基準値（上限）」、単位、及び「決裁ランク変動量」等の項目からなる表形式となっている。各項目の意味は損益変動条件マスタ３０２におけるものと同じである。
【００８１】
登録実行ボタン１１３を押すと、マスタデータ登録画面において入力された情報が、変動チェック項目マスタ３０１及び損益変動条件マスタ３０２に登録される。
【００８２】
このように、マスタデータ登録画面１１を利用することで、社内における制度の変更等に伴って、決裁ランク変動条件の変更を容易に行うことができる。
【００８３】
上述したように、本実施の形態における商談管理システム１によれば、報告者は、報告者端末３０より商談情報を入力するだけで商談管理サーバ１０が承認者による承認の要否を判断するため、承認の要否の判断を容易に確認することができ、又判断基準の統一化、適正化を図ることもできる。
【００８４】
また、承認者は、決裁ページ３２を確認することで、前回既に承認されている商談について、何故改めて承認が必要となったのかを容易に確認することができ、的確な判断を下すことができる。
【００８５】
更に、変動チェック項目マスタ３０１及び損益変動条件マスタ３０２において承認の要否の判断基準を管理しているため、社内の制度の変更があった場合等は、これらのマスタを変更するだけで、迅速かつ確実に新たな制度に対応した判断基準による運用を行うことができる。
【００８６】
以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【００８７】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１）  商談に対する承認の要否を判断する商談承認要否判断方法であって、
コンピュータが、前記商談に関する商談情報と、当該商談情報と同一の商談に関する前回の商談情報との差分である差分情報を算出する差分算出手順と、
前記差分算出手順において算出された前記差分情報が所定の条件を満たしているか否か判断する差分判断手順とを有することを特徴とする商談承認要否判断方法。
（付記２）  前記差分判断手順は、
前記差分情報の変動度合いに応じて前回の決裁ランクからの該決裁ランクの変動値を示すテーブルから前記差分算出手順において算出された前記差分情報に対応する該決裁ランクの変動値を取得するランク変動値取得手順と、
前記前回の決裁ランクと前記変動値とによって前記商談を決裁すべき承認者を決定する承認者決定手順とを有することを特徴とする付記１記載の商談承認要否判断方法。
（付記３）  前記差分算出手順において算出された前記差分情報と、前記差分判断手順において判断された判断結果とを、ネットワークを介して接続される端末に表示させる判断結果表示手順を有することを特徴とする付記１又は２記載の商談承認要否判断方法。
（付記４）  前記差分算出手段は、前記商談情報のうち損益に関する情報について前記差分情報を算出することを特徴とする付記１乃至３いずれか一項記載の商談承認要否判断方法。
（付記５）  前記承認者決定手順によって決定された前記承認者へネットワークを介して少なくとも前記商談情報と前記差分判断手順において判断された判断結果とを通知することによって、承認を依頼する承認依頼手順を有することを特徴とする付記２乃至４いずれか一項記載の商談承認要否判断方法。
（付記６）  付記１乃至５いずれか一項記載の商談承認要否判断方法をコンピュータに実行させるための商談承認要否判断プログラム。
（付記７）  付記６記載の商談要否判断プログラムを記録したコンピュータ読み取り可能な記録媒体。
（付記８）  商談に対する承認の要否を判断する商談承認要否判断装置であって、
前記商談に関する商談情報と、当該商談情報と同一の商談に関する前回の商談情報との差分である差分情報を算出する差分算出手段と、
前記差分算出手段において算出された前記差分情報が所定の条件を満たしているか否か判断する差分判断手段とを有することを特徴とする商談承認要否判断装置。
【００８８】
【発明の効果】
上述の如く、本発明によれば、商談内容に変更があった場合に再度の承認の要否を容易に判断することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態における商談管理システムの構成例を示す図である。
【図２】本発明の実施の形態における商談管理サーバのハードウェア構成例を示す図である。
【図３】商談管理システムの処理を説明するためのフローチャート図である。
【図４】商談管理システムの処理を説明するためのフローチャート図である。
【図５】損益明細情報ＤＢの構成例を示す図である。
【図６】損益情報ＤＢの構成例を示す図である。
【図７】顧客・担当情報ＤＢの構成例を示す図である。
【図８】従業員マスタの構成例を示す図である。
【図９】職制マスタの構成例を示す図である。
【図１０】変動チェック項目マスタの構成例を示す図である。
【図１１】損益変動条件マスタの構成例を示す図である。
【図１２】承認者マスタの構成例を示す図である。
【図１３】再承認条件ＤＢの構成例を示す図である。
【図１４】承認要通知ページの表示例を示す図である。
【図１５】理由メッセージマスタの構成例を示す図である。
【図１６】決裁情報ＤＢの構成例を示す図である。
【図１７】決裁ページの表示例を示す図である。
【図１８】承認不要通知ページの表示例を示す図である。
【図１９】マスタデータ登録画面の表示例を示す図である。
【符号の説明】
１        商談管理システム
１０      商談管理サーバ
２０      承認者端末
３０      報告者端末
４０      ネットワーク
１００    ドライブ装置
１０１    記憶媒体
１０２    補助記憶装置
１０３    メモリ装置
１０４    演算処理装置
１０５    インタフェース装置
１１０    送受信処理部
１１１    報告・結果情報送信手段
１１２    報告・結果情報受信手段
１２０    報告者用処理部
１２１    損益計算手段
１２２    承認要否判断手段
１２３    データ更新手段
１２４    報告依頼処理手段
１３０    承認者用処理部
１３１    報告データ編集手段
１３２    決裁処理手段
１３３    データ更新手段
１３４    結果処理依頼手段
２０１    顧客・担当ＤＢ
２０２    損益情報ＤＢ
２０３    損益明細ＤＢ
２０４    決裁情報ＤＢ
２０５    再承認条件ＤＢ
３０１    変動チェック項目マスタ
３０２    損益変動条件マスタ
３０３    従業員マスタ
３０４    職制マスタ
３０５    理由メッセージマスタ
３０６    承認者マスタ
Ｂ    バス
【図１】
2004192540.tif 000003
【図２】
2004192540.tif 000004
【図３】
2004192540.tif 000005
【図４】
2004192540.tif 000006
【図５】
2004192540.tif 000007
【図６】
2004192540.tif 000008
【図７】
2004192540.tif 000009
【図８】
2004192540.tif 000010
【図９】
2004192540.tif 000011
【図１０】
2004192540.tif 000012
【図１１】
2004192540.tif 000013
【図１２】
2004192540.tif 000014
【図１３】
2004192540.tif 000015
【図１４】
2004192540.tif 000016
【図１５】
2004192540.tif 000017
【図１６】
2004192540.tif 000018
【図１７】
2004192540.tif 000019
【図１８】
2004192540.tif 000020
【図１９】
2004192540.tif 000021