JP2006072902A - リニューアル提案支援システム - Google Patents

Abstract

【課題】 顧客に対してリニューアルの提案を行なう営業担当者の案件絞り込み業務の負荷およびリニューアルする機器の組合せ可否の判断の負荷を軽減させ、リニューアル提案業務を効率化させる。
【解決手段】 営業端末装置と通信を行なうリニューアル提案支援システムであって、
顧客が備える製品の構成品に関する情報を記憶する構成情報記憶手段と、現在取り扱う構成品および過去に取り扱った構成品に関する情報を記憶する構成品情報記憶手段と、前記構成品情報記憶手段が記憶する構成品同士の組合せの可否に関する情報を記憶する構成ルール記憶手段と、顧客が備える製品の構成品の変更についての処理を行なう制御手段とを備え、前記制御手段は、前記構成情報記憶手段を参照し、顧客が備える構成品を前記営業端末装置に表示するとともに、前記営業端末装置から、いずれかの構成品の変更指示を受け付けた場合に、他の構成品であって、変更にかかる構成品との組合せが不可の構成品を前記営業端末装置の操作者に通知することを特徴とするリニューアル提案支援システム。
【選択図】 図１

Description

本発明は、製品のリニューアルの提案業務を支援するシステムに関する。

近年、コンピュータや自動車といった製品は普及が進んでいるため、製造企業の営業担当者にとっては、顧客の新規開拓に加え、買い替えの需要への対応が重要になっている。さらに、これら製品が市場価値を有する期間は短縮される方向にあるため、顧客に納入した製品のリニューアルによる需要掘り起こしは、一層重要である。

一方、コンピュータや自動車といったような組み立て型製品では、顧客１人１人の要望に合わせて製品仕様をカスタマイズする受注仕様生産が普及してきている。受注仕様生産のためには、顧客の要望を製品構成に正確に反映することが課題となる。

したがって、組み立て型製品の販売促進のためには、顧客に納入した製品のリニューアルを喚起するために、顧客１人１人の要望に合わせた製品構成案を素早くかつ正確に作成することが重要である。

顧客に納入した製品のリニューアルを提案する技術として、例えば、特許文献１には、顧客の製品情報からその製品のリニューアル時期を予測し、適正な代換え製品の情報を通知する技術が開示されている。

また、顧客１人１人の要望に合わせて素早くかつ正確に製品構成を作成する技術として、特許文献２には、複数種の装備から選択した装備を製品本体に装着して、多様な仕様を実現する製品において、ある装備が装着可能か不能かを判断して、仕様設定の支援を行うことが開示されている。

特開２００１−２２２５７９号公報 特開２０００−１３７７３９号公報

営業担当者は多数の商談を抱え、その中から有望な案件を絞り込んで実際のリニューアルの提案を行なう。しかし、どの案件が有望であるかどうかの判断は、一般には困難であるため、有望な案件を絞り込みを支援するための技術の開発が望まれている。

また、顧客にリニューアルを提案する場合には、新たに導入する機器と変更しない他の機器との組合せの可否を判断しなければならないが、変更しない他の機器にはすでに販売を終了しており、あらたに導入する機器との組合せの可否の判断が困難なものもある。

本発明は、顧客に対してリニューアルの提案を行なう営業担当者の案件絞り込み業務の負荷およびリニューアルする機器の組合せ可否の判断の負荷を軽減させ、リニューアル提案業務を効率化させることを目的とする。

上記課題を解決するため、本発明によれば、
営業端末装置と通信を行なうリニューアル提案支援システムであって、
顧客が備える製品の構成品に関する情報を記憶する構成情報記憶手段と、
現在取り扱う構成品および過去に取り扱った構成品に関する情報を記憶する構成品情報記憶手段と、
前記構成品情報記憶手段が記憶する構成品同士の組合せの可否に関する情報を記憶する構成ルール記憶手段と、
顧客が備える製品の構成品の変更についての処理を行なう制御手段とを備え、
前記制御手段は、前記構成情報記憶手段を参照し、顧客が備える構成品を前記営業端末装置に表示するとともに、前記営業端末装置から、いずれかの構成品の変更指示を受け付けた場合に、他の構成品であって、変更にかかる構成品との組合せが不可の構成品を前記営業端末装置の操作者に通知することを特徴とするリニューアル提案支援システムが提供される。

ここで、前記構成品情報記憶手段は、構成品毎に現在取り扱う構成品であるか過去に取り扱った構成品であるかを示す販売状況情報を記憶し、前記制御手段は、前記販売状況情報を前記営業端末装置に表示することが望ましい。

また、前記構成品情報記憶手段は、構成品をその製品種別を示す項目単位で管理し、
前記制御手段は、顧客が備える構成品について、その構成品を含む項目であって、現在取り扱う構成品を、変更の選択肢として表示することができる。

さらに、前記構成品情報記憶手段は、構成品毎に性能指標と価格とを記憶し、
前記制御手段は、いずれかの構成品の変更指示を受け付けた場合に、変更前の構成品の性能指標と、変更後の構成品の性能指標および価格とから、変更の際のコストと性能向上との関係を前記営業端末装置に表示することができる。

また、顧客との商談に関する情報であって、商談の総額を含む情報を記憶する商談情報記憶手段と、顧客に関する情報を記憶する顧客情報記憶手段をさらに備え、
前記制御手段は、商談情報記憶手段と顧客情報記憶手段とを参照して、商談毎の金額と商談の見込みに関する指標を算出することができる。

このとき、前記顧客情報記憶手段は、顧客の取引実績、顧客のシェア、顧客の業績の少なくともいずれかの情報を記憶し、
前記制御手段は、顧客の取引実績、顧客のシェア、顧客の業績の少なくともいずれかの情報を参照してその顧客についての商談の見込みに関する指標を算出することができる。

以下、本発明の実施の形態について図面を参照して説明する。図１は、本発明を適用したリニューアル提案支援システムの構成を示すブロック図である。

本図に示すように、リニューアル提案支援システムは、営業システム１０、設計システム２０、営業端末装置３０、設計端末装置４０が、コンピュータネットワーク７０に接続されて構成される。

営業システム１０は、顧客にリニューアルを提案する営業に関する情報を管理する。設計システム２０は、リニューアルの提案に必要な、各種装置に関する設計情報を管理する。

本実施形態において、リニューアル対象の製品は、コンピュータシステムを例に説明する。ただし、本発明はコンピュータシステムに限られず、その構成部品を変更可能な組み立て製品全般に適用することができる。

営業システム１０および設計システム２０は、例えば、汎用的なサーバコンピュータを用いて構成することができる。コンピュータネットワーク７０は代表的にはインターネットとすることができる。また、営業システム１０と設計システム２０とは、ＬＡＮ等で接続し、コンピュータネットワーク７０を介さずに、直接的に情報をやり取りできるようにしてもよい。

営業端末装置３０は、営業担当者が用いる端末装置であり、例えば、Ｗｅｂブラウザ機能を備えた一般的な情報処理装置等を用いて構成することができる。営業端末装置３０は、有線、無線等の通信手段により、コンピュータネットワーク７０を介して営業システム１０と通信を行なうことができるようになっている。なお、営業端末装置３０として、可搬型の情報処理装置を用い、また、無線によりコンピュータネットワーク７０に接続することで、顧客先に出向いて本システムを利用することができる。

設計端末装置４０は、リニューアル提案に用いる各種装置の設計担当者が用いる端末装置であり、例えば、Ｗｅｂブラウザ機能を備えた一般的な情報処理装置等を用いて構成することができる。設計端末装置４０は、コンピュータネットワーク７０、ＬＡＮ等を介して営業システム１０と通信を行なうことができるようになっている。

本図において、営業端末装置３０と設計端末装置４０とは、それぞれ１台示されているが、これらは、例えば、営業担当者、設計担当者毎に複数備えるようにすることが望ましい。

本図において、営業システム１０は、Ｗｅｂ処理部１１０、商談処理部１２０、構成作成支援部１３０、商談情報ＤＢ（データベース）１４０、顧客情報ＤＢ１５０、構成情報ＤＢ１６０を備えている。

Ｗｅｂ処理部１１０は、Ｗｅｂページを介して、営業端末装置３０と情報のやり取りを行なうための処理を行なう。商談処理部１２０は、商談情報ＤＢ１４０、顧客情報ＤＢ１５０を参照し、商談に関する情報を管理する処理を行なう。構成作成支援部１３０は、構成情報ＤＢ１６０を参照し、また、設計システム２０から製品に関する情報を取得し、顧客に提案するリニューアルに関する情報を生成する。

本図において、設計システム２０は、Ｗｅｂ処理部２１０、製品情報編集部２２０、製品情報ＤＢ２３０、構成品情報ＤＢ２４０、構成ルールＤＢ２５０を備えている。

Ｗｅｂ処理部１１０は、Ｗｅｂページを介して、営業端末装置３０と情報のやり取りを行なうための処理を行なう。製品情報編集部２２０は、製品情報ＤＢ２３０、構成品情報ＤＢ２４０、構成ルールＤＢ２５０に記録する情報を編集するための処理を行なう。

本図において、営業システム１０は、１台のシステムとして構成されているが、例えば、Ｗｅｂ処理部１１０として機能するＷｅｂサーバ、商談処理部１２０、構成作成支援部１３０として機能するアプリケーションサーバ、商談情報ＤＢ１４０、顧客情報ＤＢ１５０、構成情報ＤＢ１６０として機能するデータベースサーバのように、複数台のサーバコンピュータにより階層構造とするようにしてもよい。これにより、それぞれのサービスを分担して実施することができ、迅速なサービス提供が可能となる。設計システム２０についても同様に、複数のサーバコンピュータにより構成することができる。

次に、本システムが備える各データベースのデータ構成について説明する。

図２は、商談情報ＤＢ１４０のデータ構成の一例を示す図である。商談情報ＤＢ１４０は、顧客との商談情報を記録するデータベースである。本図に示すように商談情報ＤＢ１４０は、管理番号１４０ａ、状況１４０ｂ、時期１４０ｃ、導入内容１４０ｄ、用途１４０ｅ、総額１４０ｆ、顧客コード１４０ｇを１レコードとして、商談情報を管理する。すなわち、商談情報ＤＢ１４０は、１件の商談情報を１つのレコードとして記録する。

ここで、管理番号１４０ａは、商談情報を識別するための管理番号である。状況１４０ｂは、その商談の状況を、例えば、「○（受注）」「×（失注）」「△（進行中）」で示す。時期１４０ｃは、受注、失注の確定時期を示す。導入内容１４０ｄは、新規・増設・買取・レンタル等の分類を示す。用途１４０ｅは、商談対象となるシステムの用途を示す。総額１４０ｆは、商談対象の案件の総額を示す。顧客コード１４０ｇは、商談相手の顧客を特定するための識別子である。

なお、商談情報ＤＢ１４０に記録されるこれらのレコードの各項目は、商談情報毎に、営業担当者が営業端末装置３０を用いて入力することができる。

図３は、顧客情報ＤＢ１５０のデータ構成の一例を示す図である。顧客情報ＤＢ１５０は、顧客に関する情報を記録するデータベースである。本図に示すように顧客情報ＤＢ１５０は、顧客コード１５０ａ、名称１５０ｂ、取引実績１５０ｃ、顧客シェア１５０ｄ、顧客業績１５０ｅを１レコードとして管理する。すなわち、顧客情報ＤＢ１５０は、顧客単位でレコードを管理する。

ここで、顧客コード１５０ａは、顧客の識別子である。名称１５０ｂは、顧客の名称である。取引実績１５０ｃは、顧客の取引実績を、あらかじめ定めた規則にしたがってＡからＣにランク分したものである。あらかじめ定めた規則としては、例えば、受注回数×受注価格で計算される受注総額の値に応じてランク分することがあげられる。顧客シェア１５０ｄは、顧客内の全コンピュータ台数に占める当該メーカの占有比率をＡ、Ｂ、Ｃの３ランクで示したものである。占有比率１５０ｅは、自社製品台数／顧客内総台数で計算されたものであり、分母が不明の場合は推定値を用いることができる。顧客業績１５０ｆは、顧客の最近の業績（増収増益、増収減益、減収減益等）をＡ、Ｂ、Ｃの３ランクで示したものである。

なお、顧客情報ＤＢ１５０に記録されるこれらのレコードの各項目は、新たな情報を入手した場合に営業端末装置３０を用いて入力することができる。

図４は、構成情報ＤＢ１６０のデータ構成の一例を示す図である。構成情報ＤＢ１６０は、顧客に備えられているシステム構成を記録するデータベースである。本図に示すように構成情報ＤＢ１６０は、構成ＩＤ１６０ａ、顧客コード１６０ｂ、モデル名１６０ｃ、ベース名１６０ｄ、ベース構成１６０ｅ、オプション構成１６０ｆを１レコードとして管理する。すなわち、構成情報ＤＢ１６０は、１つのコンピュータシステムの構成を１レコードとして管理する。

ここで、本実施例が対象とするコンピュータシステムの構成について説明する。本実施例におけるコンピュータシステムは、モデル名で示される機種単位で取り扱うものとする。そして、各モデルは、ベース名で示されるメイン構成を有している。ベースは、ＣＰＵ、メモリ、ＨＤＤ（ハードディスクドライブ）、ＯＳ等のベース構成項目から構成されるが、それぞれのベース構成項目は複数のベース構成品目を選択的に採用することができるものとする。例えば、あるベースについて、ＣＰＵとしてＣＰＵ１、ＣＰＵ２のいずれかが（あるいは両方）が採用することができるという具合である。

また、ベースには、ベース構成品目の他に、オプション的な構成としてオプション構成項目を付加することができる。オプション項目についても、複数のオプション構成品目から選択的に採用することができる。例えば、あるベースについて、オプションとしてボード１とドライブ１とを追加するという具合である。

それぞれのベースについてのベース構成項目、あるいは、オプション構成項目の内容は、販売形態で定められたり、仕様上の組合せの可否で定められたりする。また、ベース、ベース構成項目、オプション構成項目のそれぞれの製品は、モデルチェンジ等で旧機種が販売終了になったり、ある機種についての後継機種が登場したりする。

このようなモデルチェンジが頻繁に発生する組み立て型製品の情報管理に好適な設計システム２０について説明する。設計システム２０は以下に示すような３種類のデータベースを備える。

製品情報ＤＢ２３０は、モデルごとに組合せ可能な構成部品が記録されたデータベースである。構成品情報ＤＢ２４０は、構成部品ごとの詳細な情報が記録されたデータベースである。構成ルールＤＢ２５０は、構成部品同士の組合せルールが記録されたデータベースである。

本実施形態における設計システム２０は、これら３つのデータベースが製品情報編集部において有機的に結合されることで効果を発揮する。以下、各データベースについて詳細に説明する。

設計システム２０の製品情報ＤＢ２３０は、モデル毎のベースとオプションに関する情報を記録するデータベースである。

図５は、製品情報ＤＢ２３０のデータ構成の一例を示す図である。本図に示すように、製品情報ＤＢ２３０は、モデル名２３０ａ、ベース名２３０ｂ、ベース構成項目２３０ｃ、ベース構成品目２３０ｄ、数量２３０ｅ、標準２３０ｆ、オプション構成項目２３０ｇ、オプション構成品目２３０ｈ、数量２３０ｉ、標準２３０ｊを管理する。

本図の例を参照して、構成品情報ＤＢ２４０について具体的に説明する。

モデル名「サーバＢ」は、ベースＢを備えるシステムである。ベースの構成項目としては、「ＯＳ」「ＣＰＵ」「メモリ」「ＨＤＤ」等があり、ベースＢでは、それぞれ「ＯＳ１／ＯＳ２」「ＣＰＵ１／ＣＰＵ２」「２５６ＭＢ／５１２ＭＢ」「５０ＧＢ、ＳＣＳＩ／８０ＧＢ、ＳＣＳＩ／５０ＧＢ、ＲＡＩＤ／８０ＧＢ、ＲＡＩＤ」が選択できるものとする。それぞれの数量は「１」である。また、標準２３０ｆで「○」が付されているベース構成品目２３０ｄは、ベースＢにおける標準のベース構成品目であることを示している。

また、ベースＢには、オプション構成項目として「ボード」「ドライブ」等を追加することができ、それぞれ「ボード１／ボード２／ボード３」「ドライブ１／ドライブ２／ドライブ３」が選択できるものとする。それぞれの数量は「１」である。また、標準２３０ｊで「○」が付されているオプション構成品目２３０ｈは、ベースＢにおける標準のオプション構成品目であることを示している。

製品情報ＤＢ２３０の各項目は、設計者等が設計端末装置４０を用いて入力することができる。

設計システム２０の構成品情報ＤＢ２４０は、ベース構成項目およびオプション構成項目の構成品目ごとの情報を記録するデータベースである。

図６は、構成品情報ＤＢ２４０の構成の一例を示す図である。本図に示すように、構成品情報ＤＢ２４０は、項目２４０ａ、品目２４０ｂ、諸元２４０ｃ、性能指標２４０ｄ、価格２４０ｅ、状況２４０ｆ、後継２４０ｇを管理する。

本図の例を参照して、構成品情報ＤＢ２４０について具体的に説明する。

項目２４０ａは、構成品の製品種別を示す情報で、例えば、「ベース」「ＯＳ」「ＣＰＵ」等がある。

品名２４０ｂは、項目毎の具体的な構成品の名称である。例えば、項目「ベース」として、「ベースＢ」「ベースＣ」があり、項目「ＣＰＵ」として「ＣＰＵ１」「ＣＰＵ２」「ＣＰＵ３」があるという具合である。

諸元２４０ｃは、それぞれの構成品のスペックを示す情報である。これらのスペックに応じて性能指標が設計担当者等により定められ、その値が性能指標２４０ｄに記録される。性能指標２４０ｄは、構成品を変更した場合、あるいは、構成品を増設した場合等にどの程度性能が向上するかの目安となる相対的な値である。

価格２４０ｅは、構成品の単価を示す。

状況２４０ｆは、構成品が現行品であるか、販売終了したかを示す。ここで、「ＬＩＶＥ」は、その構成品が販売中の現行品であることを示し、「ＳＴＯＰ」は、その構成品の販売が終了していることを示す。

後継２４０ｇは、構成品が販売終了となった場合の、後継構成品を示す。本図の例では「ベースＢ」は販売終了品であり、その後継機は「ベースＣ」であることが示されている。

構成品情報ＤＢ２４０は、設計担当者が、新たな構成品を採用等した場合、ある構成品が販売中止になった場合等に更新するようにする。

設計システム２０の構成ルールＤＢ２５０は、ベースに組合せ可能な機器等の情報を記録するデータベースである。

図７は、構成ルールＤＢ２５０の構成の一例を示す図である。本図に示すように、構成ルールＤＢ２５０は、ベース２５０ａ、組合せ対象２５０ｂ、条件２５０ｃを管理する。すなわち、ベースに対して組合せ可能な構成品が組合せ対象２５０ｂに記録される。このとき組合せのために満たすべき条件がある場合には、条件２５０ｃに記録される。一方、構成ルールＤＢ２５０に記録されていないベースと構成品とは組み合わせることができない。

本図の例を参照して、構成ルールＤＢ２５０について具体的に説明する。例えば、ベースとＯＳの組合せにおいて、「ベースＣ」は、「ＯＳ１」「ＯＳ２」「ＯＳ３」と無条件に組み合わせることができる。また、ベースとＨＤＤとの組合せにおいて、「ベースＣ」と「８０ＧＢ、ＳＣＳＩ」との組合せは、条件２５０ｃに「ＰＯＳＳＩＢＬＥ」と記録されている。これは、その組合せは販売上行なわれていないが、性能的には組み合わせることが可能であることを示している。

また、「ベースＡ」と「ドライブ１」との組合せにおいて、条件２５０ｃに「ＮＥＥＤ（ボード１）」と記録されているが、これは、「ベースＡ」と「ドライブ１」とを組み合わせる際には「ボード１」が必要であることを示している。

「ベースＢ」と「ドライブ３」との組合せにおいては、条件２５０ｃに「ＮＥＥＤ（ボード２ ＯＲ ボード３ ＯＲ ボード４）」と記録されている。これは、「ベースＢ」と「ドライブ３」とを組み合わせる際には「ボード２」「ボード３」「ボード４」のいずれかが必要であることを示している。

さらに、「ベースＢ」と「ドライブ５」との組合せにおいては、条件２５０ｃに「ＮＥＥＤ（ボード５） ＡＮＤ ＮＯＴ（ボード２、ボード３）」と記録されている。これは、「ベースＢ」と「ドライブ５」とを組み合わせる際には「ボード５」が必要であり、かつ、「ボード２」「ボード３」のいずれも備えていてはならないことを示している。

同図ではルールが表形式で表記されているが、「ベース」と「組合せ対象」を行列として、条件をマスとする表形式で情報を表記、管理してもよい。上記の「ベースＢ」、「ボード２」、「ボード３」は構成品情報ＤＢ２４０において「ＳＴＯＰ」となっており販売が終了した構成部品である。このように、本実施形態では、販売が終了した構成品についてもその組合せに関する情報を管理することにより、リニューアル提案の際の営業担当者の負荷を軽減するようにしている。

構成ルールＤＢ２５０は、設計担当者が、新たな構成品を採用等した場合、ある構成品が販売中止になった場合等に更新するようにする。

つぎに、本実施形態における処理について説明する。

まず、設計担当者は、設計端末装置４０を用いて、製品情報ＤＢ２３０、構成品情報ＤＢ２４０、構成ルールＤＢ２５０に必要なデータをあらかじめ入力しておくようにする。設計システム２０のＷｅｂ処理部２１０は、そのための入力編集画面を設計端末装置４０に表示させることができる。

図８は、設計システム２０のＷｅｂ処理部２１０が表示させる製品情報等の入力編集画面３００の一例を示す図である。

本図に示すように、入力編集画面３００は、製品を指定するためのボタン、編集項目（編集対象データベース）を指定するための領域、編集画面３０３等を備えており、設計担当者が製品情報等を簡易に入力編集できるようになっている。

また、営業担当者は、営業端末装置３０を用いて、商談情報ＤＢ１４０、顧客情報ＤＢ１５０、構成情報ＤＢ１６０に必要なデータをあらかじめ入力しておくようにする。

これらの前処理により各種データが記録された製品情報ＤＢ２３０、構成品情報ＤＢ２４０、構成ルールＤＢ２５０、商談情報ＤＢ１４０、顧客情報ＤＢ１５０、構成情報ＤＢ１６０に基づいて、営業システム１０は、以下に示すような処理を行なう。

図９は、営業システム１０が行なう処理の概要を示す図である。すなわち、営業システムは、商談情報概要表示処理４００、商談情報詳細表示処理４０１、対象構成特定処理４０２、構成情報表示処理４０３、構成変更処理４０４、変更指標表示処理４０５、見積・提案書表示処理４０６を行なう。

まず、商談情報概要表示処理４００について説明する。商談情報概要表示処理４００では、進行中あるいは過去に扱った商談の概要を表示して、営業担当者がどの商談を提案対象とするかを絞込むための支援を行なうものである。

このため、商談情報概要表示処理４００では、商談情報ＤＢ１４０から商談情報を読み込む。さらに、各商談情報の顧客コード１４０ｇをキーにして、顧客情報ＤＢ１５０から顧客情報を抽出し、それぞれの商談についての顧客情報を取得する。

つぎに、抽出した情報に基づいて、表示指標を算出する。ここで、表示指標は、その商談についてリニューアルの商談が成立する確度の目安となる値である。

表示指標は、例えば、次のようにして求めることができる。すなわち、表示指標「確度」＝時間経過因子＊用途因子＊取引実績因子＊顧客シェア因子＊顧客業績因子（ただし、＊は、それぞれの要素を考慮することを示す演算子とする）。

ここで、時間経過因子は、商談情報の時期１４０ｃに基づいて、導入時期から現在までの経過時間を計算し、５年超過で１．０、２〜５年では０．５、２年以下では０．２の評点を付与したものである。これは、時間経過とともにシステムが陳腐化してリニューアルの確度が高くなると考えられるからである。

用途因子は、商談情報の用途１４０ｅごとに評点を付与したものであり、例えば、ＤＢでは１．０、Ｗｅｂでは０．８、ＳＣＭ、ＣＲＭでは０．５、ＥＲＰでは０．２とすることができる。これは、時間経過とともにスケールアップ要因が多いシステムほどリニューアルの確度が高くなると考えられるからである。例えば、ＤＢは時間経過とともに容量不足となり増設される可能性が高い一方、ＥＲＰのようなものでは一度構築された環境が変更される頻度は低いと考えられるからである。

取引実績因子は、顧客情報の顧客との取引実績１５０ｃについて、「Ａ」「Ｂ」「Ｃ」にそれぞれ１．０、０．５、０．２の評点を付与したものである。これは、従来の取引実績が良好な顧客ではリニューアル受注の確率が高くなると考えられるからである。

顧客シェア因子は、顧客情報の顧客シェア１５０ｄについて、「Ａ」「Ｂ」「Ｃ」にそれぞれ１．０、０．５、０．２の評点を付与したものである。これは、顧客シェアが高いほど従来システムとの親和性によりリニューアル受注が有利と考えられるからである。

顧客業績因子は、顧客情報の顧客業績１５０ｅについて、Ａ、Ｂ、Ｃにそれぞれ１．０、０．５、０．２の評点を付与したものである。これは、業績が好調の企業では設備投資の確度が高くなると考えられるからである。

以上の結果、例えば、管理番号２４５の例について計算すると、リニューアル確度は以下となる。

なお、表示指標「確度」は、相対比較のための数値である。これにより、多くの商談同士を相対比較することができ、リニューアルが有望な商談を絞り込んで、営業リソースを集中して投下できる利点がある。

商談情報概要表示処理４００では、算出した表示指標「確度」と、商談情報の総額１４０ｆとに基づいて、商談散布図を生成して、営業端末装置３０に表示させる。図１０は、商談散布図の一例を示す図である。

本図に示すように商談散布図５００は、商談毎に、算出した表示指標「確度」と総額１４０ｆに基づく値とを二次元座標上にプロットしたものである。本図において、横軸は確度を示し、右に行くほど確度が高いことを示している。また、縦軸は金額を示し、上に行くほど金額が高いことを示している。そして、プロットされた○および△が１つの商談を示している。なお、△は、その商談が営業担当者により選択されていることを示している。

商談散布図では、今後注力できる限られた商談が、どの領域に分布するのかを視覚的に把握できる。これにより、営業担当者は金額が低くても確度が高い商談に対して集中的にリニューアル提案するか、確度は低くても金額が高い商談に対してリニューアル提案するかの判断が容易となる。これら２つのケースはどちらを重視すべきかは企業の判断により変わる。決算間近であると右下の商談を確実に刈り取ることを重視するし、決算まで時間があると左上の商談にも重きを置く。重要なことは、各商談がどういう位置づけを持っているかを明確に示すことである。

商談散布図上で商談が選択されて、所定の操作、例えば、マウスによるダブルクリックを受け付けると、商談情報詳細表示処理４０１を行ない、さらに、商談に関する詳細な情報を営業端末装置３０に表示させる。

商談に関する詳細な情報は、例えば、状況１４０ｂ、導入内容１４０ｄ、総額１４０ｆ等の商談情報ＤＢ１４０に記録された各種商談情報、名称１５０ｂ、取引実績１５０ｃ、顧客業績１５０ｅ等の顧客情報ＤＢ１５０に記録された各種顧客情報とすることができる。これにより、営業担当者は、その商談についてのより詳細な情報を取得することができる。

商談散布図上で商談が選択されて、所定の操作、例えば、所定のボタンのクリックを受け付けると、営業システム１０は、その商談をリニューアル提案の対象として特定する（４０２）。

ある商談が、リニューアル提案の対象として特定されると、まず、その商談についての顧客の現在の構成情報の表示処理４０３を行なう。

構成情報の表示処理４０３では、特定された商談についての顧客コード１５０ａをキーに構成情報ＤＢ１６０から構成情報が抽出され、抽出された情報に基づく画面を営業端末装置３０に表示させる。

図１１は、構成情報を表示する画面６００の一例を示す図である。本図に示すように画面６００の構成表示欄６０１には、ベース、ＯＳ、ＣＰＵ等のそれぞれについて、顧客の現在のシステム構成が示される。本図の例では、ベースとしてベースＢ（ＳＴＯＰ）が採用され、ＯＳとしてＯＳ２（ＳＴＯＰ）が採用され、ＣＰＵではＣＰＵ１（ＬＩＶＥ）が採用されていることを示している。なお、（ＳＴＯＰ）はその機器の販売が終了していることを示し、（ＬＩＶＥ）はその機器が現行機であることを示している。この情報は、構成品情報ＤＢ２４０の状況２４０ｆを参照することで取得することができる。

構成情報を表示する画面６００には、構成情報の他にも、システム構成のイメージ、操作用の各種メニュー・ボタン等を配置することができる。また、本画面で、システム構成のリニューアルの提案を行なうために、構成を変更した場合の評価等を行なうことができる。

このための構成変更処理４０４について説明する。本実施例において、営業システム１０は、変更案として、独立変更と従属変更の２種類を選択することができる。営業担当者は、独立変更を選択する場合は「独立」ボタン６０２をクリックし、従属変更を選択する場合は「従属」ボタン６０３をクリックするようにする。

ここで、独立変更は、変更対象の機器について、現行機種と後継機種とを提示して、選択を受け付け、選択された機種について、他のシステム構成機器との組合せのチェックを行なう変更案受け付け処理である。すなわち、図１２（ａ）に示すフロー図にしたがって処理が行なわれる。さらに、図１３（ａ）の具体例を参照して、独立変更について説明する。

図１３（ａ）は、図１１に示した構成において、「ベースＢ（ＳＴＯＰ）」を変更対象とした場合の例である（Ｓ３０１）。この場合、営業システム１０は、構成品情報ＤＢ２４０を参照して、ベースＢに対応する現行装置およびベースＢの後継機を抽出して、メニュー形式で選択可能な状態で表示する（Ｓ１０１）。この結果、ベースＢの後継機である「ベースＣ（ＬＩＶＥ）」が表示される（Ｓ３０１）。この表示の仕方は、例えば、ベースＢが表示されている領域に対応したプルダウンメニュー方式とすることができる。

この状態で、営業システム１０は、営業担当者からの選択を受け付ける（Ｓ１０２）。そこで、営業担当者がベースＣを選択すると、営業システム１０は、組合せのチェックを行なう（Ｓ１０３、Ｓ３０４）。

組合せチェックでは、変更後の機器、すなわち、ベースＣとその他の機器との組合せの可否を構成ルールＤＢ２５０を参照して判断する。その結果、組合せが不可とされている装置を表示し、営業担当者に通知する（Ｓ１０４）。本例では、ボード２がベースＣとの組合せが構成ルールＤＢ２５０において設定されていないため、ボード２はベースＣと組み合わすことができないと判断し、ボード２を、例えば、ハイライト表示することで、営業担当者にその旨を通知する（Ｓ３０５）。なお、ＨＤＤ：８０ＧＢ、ＳＣＳＩについては、構成ルールＤＢ２５０において「ＰＯＳＳＩＢＬＥ」と設定されており、販売上は認められないが、機能的にはベースＣと組み合わせることが可能であるため、機能的に組合せ不可能な場合とは異なるハイライト表示（異なる色等）で区別する。この場合、特注仕様として顧客に提案するかどうかを検討することになる。

一方、従属変更は、変更対象の機器について、他のシステム構成機器との組合せが可能な現行機種と後継機種を提示して選択を受け付ける処理である。すなわち、図１２（ｂ）に示すフロー図にしたがって処理が行なわれる。さらに、図１３（ｂ）の具体例を参照して、従属変更について説明する。

図１３（ｂ）は、図１３（ａ）に示した例と同様に、図１１に示した構成において「ベースＢ（ＳＴＯＰ）」を変更対象とした場合の例である（Ｓ４０１）。この場合、営業システム１０は、構成品情報ＤＢ２４０を参照して、ベースＢに対応する現行装置およびベースＢの後継機を抽出する（Ｓ２０１）。そして、抽出された機器について、その他の機器との組合せの可否を構成ルールＤＢ２５０を参照して判断する（Ｓ２０２）。図１３（ｂ）の場合、ベースＣが抽出され、組合せがチェックされる（Ｓ４０２）。

この結果、組合せが可能であると判断されたベースＢに対応する現行装置およびベースＢの後継機を表示する（Ｓ２０３）。本例では、
図１４は、「ボード２（ＳＴＯＰ）」を変更対象とした場合の具体例を示している。図１４（ａ）は独立変更の例であり、図１４（ｂ）は従属変更の例である。

独立変更の場合、「ボード２（ＳＴＯＰ）」を変更対象とすると（Ｓ５０１）、営業システム１０は、構成品情報ＤＢ２４０を参照して、ボード２に対応する現行装置およびボード２の後継機を抽出して、メニュー形式で選択可能な状態で表示する。この結果、現行機である「ボード１（ＬＩＶＥ）」とボード２の後継機である「ボード４（ＬＩＶＥ）」とが表示される（Ｓ５０２）。この表示の仕方は、例えば、ボード２が表示されている領域に対応したプルダウンメニュー方式とすることができる。

そこで、営業担当者が「ボード１（ＬＩＶＥ）」を選択すると（Ｓ５０３）、営業システム１０は、組合せのチェックを行なう（Ｓ５０４）。その結果、「ボード１（ＬＩＶＥ）」は、「ドライブ３」との組合せが規定されていないため、ドライブ３がハイライト表示される。一方、「ボード１（ＬＩＶＥ）」は、「ドライブ１」との組合せは構成ルールＤＢ２５０に規定されているため、営業システム１０は、ドライブ３が表示されている領域に対応したプルダウンメニューに「ドライブ１」を追加表示して、ドライブ３が組合せ不可であることと、ドライブ１が組合せ可能であることを営業担当者に通知する（Ｓ５０５）。これにより、営業担当者は、「ボード１（ＬＩＶＥ）」の変更に加え、ドライブ３をドライブ１に変更することにより、リニューアルが可能であることを顧客に提案することができる（Ｓ５０６）。

従属変更の場合には、「ボード２（ＳＴＯＰ）」を変更対象とすると（Ｓ５０１）、組合せチェックが行なわれ（Ｓ６０２）、他の構成品との組合せが可能な「ボード４（ＬＩＶＥ）」が抽出され、ボード４のみが選択肢としてボード２が表示されている欄に対応するプルダウンメニューに表示される（Ｓ６０３）。

以上、独立変更と従属変更について説明した。独立変更は、顧客が特定の構成部品の追加を要求した場合、他の部品交換が生じる可能性を許容した上で構成の変更案を評価する場合などに有効である。特定部品の追加が可能なメリットがある一方、全ての部品の組合せを終息させるために手間がかかるデメリットがある。従属変更は、営業が顧客の現状構成に対してリプレース提案を立案する場合などに有効である。顧客に現状構成に対して、現在販売が行われている構成部品のうち組合せ可能なもののみが表示されているため、選択後の終息の手間が不要である。しかし、作成できる変更案には独立変更に比べて制約がある。

営業担当者は、このように、営業端末装置３０を用いて営業システム１０にアクセスし、種々のリニューアル提案を顧客に提示することができる。

提示したリニューアル案のうち、実際の候補となる案について、営業システム１０は、リニューアル効果についての指標を作成し、営業端末装置３０に表示する（図９：４０５）。

本実施例におけるリニューアル効果についての指標は、変更にかかる費用（価格）と変更後の性能の向上分とを算出したものであり、図１５に示すような２次元座標にプロットすることで営業担当者および顧客に提示するものとする。ここで、変更にかかる費用と変更後の性能の向上分とは、構成品情報ＤＢ２４０の価格２４０ｅおよび性能指標２４０ｄを参照することで算出することができる。

図１５に示した価格性能対応図７００において、△はリニューアル前の性能を示している。本図は、例えば、ある構成項目に注目した場合に、どの構成品に変更することで、どの程度の価格が必要でどの程度の性能向上が望めるかを示すものである。ここで、○は、構成品を増設した場合を示し、□は構成品をリプレースした場合を示している。

本図の例では、構成品ＣＰＵについて着目して価格性能対応図を表示させた場合である。これらは、構成品情報ＤＢ２４０の性能指標２４０ｄおよび価格２４０ｅを参照して算出することができる。ここで、増設の場合には増設する構成品の性能指標から変更後の性能指標が求められ、リプレイスの場合には、変更後の構成品の性能指標と変更前の構成品の性能指標との差分により変更後の性能指標を求めることができる。

この価格性能対応表７００に対して、顧客が計画する投資額と性能向上の範囲（図中の破線領域部分）を対照することで、どのようなリニューアルを行なうかの決定を支援することができる。

一般に顧客はリニューアルに投資してどの程度の効果が得られるのかを知りたい。また、既存製品をベースに、手持ちの予算と将来計画を考慮して、今回は増設にすべきかリプレイスにすべきかを知りたい。価格性能対応表は、顧客のこのような要求に応えるものである。

例えばマルチＣＰＵタイプのコンピュータ製品では、処理性能はベース基板のデータ伝送効率とＣＰＵ個数により決まる。増設ではベース基板はそのままでＣＰＵを追加することで処理速度の向上を図ることを考える。一方、リプレイスではデータ伝送効率の高いベース基板に変更した上でＣＰＵを追加して処理速度の向上を図ることを考える。両者を比較すると、増設では処理速度が高く高価なＣＰＵを追加してもデータ伝送効率が劣るため処理速度の向上は緩やかである。一方、リプレイスではデータ伝送効率が高いため安価なＣＰＵを追加しても大幅な処理速度の向上が図れることが表から読み取ることができる。

同図の場合、○の点列がデータ伝送効率の低い現状のベース基板、□の点列がデータ伝送効率の高いベース基板、ＣＰＵ１、ＣＰＵ２、ＣＰＵ３が処理速度が高く高価なＣＰＵ、ＣＰＵ４、ＣＰＵ５、ＣＰＵ６が安価なＣＰＵを意味している。

ただし、リプレイスでは初期投資が必要となる。顧客は出費を抑えつつ性能を高めたい。このため、予算範囲と必要性能により同図の今回計画と将来計画が決定する。今回計画だけを考えると、増設案が予算、性能とも満足するため増設が望ましい。しかし、将来計画を考慮すると、増設では予算内だが性能が不足し、リプレイスでは性能は満足するが予算オーバとなることがわかる。しかし、リプレイスではその後の性能向上でのコストパフォーマンスが良いメリットがある。この場合、増設を選択するかリプレイスを選択するかは顧客の考え方次第である。すなわち、直近の財源が限られている場合は増設を選択するであろうし、財源に比較的余裕がある場合はリプレイスを選択するであろう。いずれにしても、顧客に既存システムに対して増設、リプレイスにおける選択肢とそのコストパフォーマンス、将来性を明確に説明することが重要である。

顧客が、リニューアル案を絞ると、営業システム１０は、図１６に示すような見積書８００を作成することができる。見積書８００に記載する値は、構成品情報ＤＢ２４０を参照して、リニューアル案に必要な構成品の価格２４０ｅを取得することで算出することができる。

さらに、営業システム１０は、図１７に示すような、リニューアル効果についての指標と提案リニューアルについての見積とを記載した提案書９００を作成することができる（図９：４０９）。

以上のように、本発明によれば、顧客に納入した製品のリニューアルを顧客の事情や製品の特性を考慮してきめ細かく提案するシステムが提供される。また、リニューアルが有望な顧客をその規模や多様な確度で絞込み販売を効率化すること、既納品の構成とリニューアル後の構成の価格―便益を可視化して需要を喚起すること、販売が中止されている既納品であっても、現行製品との関係を把握してリニューアル後の構成を構築可能な環境を提供することが可能となる。これにより、リニューアルの効率が向上できる上、顧客訴求力を高めることができ、受注機会獲得による売上向上が期待できる。

本発明を適用したリニューアル提案支援システムの構成を示すブロック図である。 商談情報ＤＢ１４０のデータ構成の一例を示す図である。 顧客情報ＤＢ１５０のデータ構成の一例を示す図である。 構成情報ＤＢ１６０のデータ構成の一例を示す図である。 製品情報ＤＢ２３０のデータ構成の一例を示す図である。 構成品情報ＤＢ２４０の構成の一例を示す図である。 構成ルールＤＢ２５０の構成の一例を示す図である。 設計システム２０のＷｅｂ処理部２１０が表示させる製品情報等の入力編集画面３００の一例を示す図である 営業システム１０が行なう処理の概要を示す図である。 商談散布図の一例を示す図である。 構成情報を表示する画面６００の一例を示す図である。 独立変更・従属変更について説明するためのフロー図である。 独立変更・従属変更の具体例を示す図である。 独立変更・従属変更の別の具体例を示す図である。 価格性能対応表の一例を示す図である。 見積書８００の一例を示す図である。 提案書９００の一例を示す図である。

符号の説明

１０…営業システム
２０…設計システム
３０…営業端末装置
４０…設計端末装置
７０…コンピュータネットワーク
１１０…Ｗｅｂ処理部
１２０…商談処理部
１３０…構成作成支援部
１４０…商談情報ＤＢ
１５０…顧客情報ＤＢ
１６０…構成情報ＤＢ
２１０…Ｗｅｂ処理部
２２０…製品情報編集部
２３０…製品情報ＤＢ
２４０…構成品情報ＤＢ
２５０…構成ルールＤＢ

Claims (6)

1. 営業端末装置と通信を行なうリニューアル提案支援システムであって、
   顧客が備える製品の構成品に関する情報を記憶する構成情報記憶手段と、
   現在取り扱う構成品および過去に取り扱った構成品に関する情報を記憶する構成品情報記憶手段と、
   前記構成品情報記憶手段が記憶する構成品同士の組合せの可否に関する情報を記憶する構成ルール記憶手段と、
   顧客が備える製品の構成品の変更についての処理を行なう制御手段とを備え、
   前記制御手段は、前記構成情報記憶手段を参照し、顧客が備える構成品を前記営業端末装置に表示するとともに、前記営業端末装置から、いずれかの構成品の変更指示を受け付けた場合に、他の構成品であって、変更にかかる構成品との組合せが不可の構成品を前記営業端末装置の操作者に通知することを特徴とするリニューアル提案支援システム。
2. 請求項１に記載のリニューアル提案支援システムであって、
   前記構成品情報記憶手段は、構成品毎に現在取り扱う構成品であるか過去に取り扱った構成品であるかを示す販売状況情報を記憶し、
   前記制御手段は、前記販売状況情報を前記営業端末装置に表示することを特徴とするリニューアル提案支援システム。
3. 請求項２に記載のリニューアル提案支援システムであって、
   前記構成品情報記憶手段は、構成品をその製品種別を示す項目単位で管理し、
   前記制御手段は、顧客が備える構成品について、その構成品を含む項目であって、現在取り扱う構成品を、変更の選択肢として表示することを特徴とするリニューアル提案支援システム。
4. 請求項１に記載のリニューアル提案支援システムであって、
   前記構成品情報記憶手段は、構成品毎に性能指標と価格とを記憶し、
   前記制御手段は、いずれかの構成品の変更指示を受け付けた場合に、変更前の構成品の性能指標と、変更後の構成品の性能指標および価格とから、変更の際のコストと性能向上との関係を前記営業端末装置に表示することを特徴とするリニューアル提案支援システム。
5. 請求項１に記載のリニューアル提案支援システムであって、
   顧客との商談に関する情報であって、商談の総額を含む情報を記憶する商談情報記憶手段と、顧客に関する情報を記憶する顧客情報記憶手段をさらに備え、
   前記制御手段は、商談情報記憶手段と顧客情報記憶手段とを参照して、商談毎の金額と商談の見込みに関する指標を算出することを特徴とするリニューアル提案支援システム。
6. 請求項５に記載のリニューアル提案支援システムであって、
   前記顧客情報記憶手段は、顧客の取引実績、顧客のシェア、顧客の業績の少なくともいずれかの情報を記憶し、
   前記制御手段は、顧客の取引実績、顧客のシェア、顧客の業績の少なくともいずれかの情報を参照してその顧客についての商談の見込みに関する指標を算出することを特徴とするリニューアル提案支援システム。

Images