JP2022002094A - コンピュータプログラム、送信方法、送信装置 - Google Patents

Abstract

【課題】企業の問題・課題及び当該問題・課題に関連する事例を出力し、事例に基づくマッチング依頼を送信するコンピュータプログラムを及び送信方法を提供する。【解決手段】提供サーバ、ユーザ端末、業者端末及び顧客端末が、ネットワークにより、互いに通信可能に接続されている提供システムにおいて、コンピュータプログラムを実行する提供サーバ１は、ユーザ端末より企業の情報を取得し、取得した企業の情報及び補助記憶部１３を参照して企業の問題・課題を特定する。そして、特定した問題・課題、企業の情報に基づき、問題・課題に関連する事例を特定し、特定した事例をユーザ端末へ出力する。その後、ユーザ端末より事例に基づくマッチング依頼を受け付けると、受け付けたマッチング依頼を所定の送信先へ送信する。【選択図】図２

Description

本発明は、企業の問題・課題を出力するコンピュータプログラム等に関する。

企業の健全な発展に資するために、企業が抱える問題・課題や問題に関する提案を行う経営支援システムが提案されている（特許文献１）。一方、銀行等の金融機関においては、顧客企業の発展を促すために、行員が、顧客企業に対して経営改善等に必要な融資やコンサルティング、専門家や製品等を紹介するビジネスマッチングを行っている。

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

しかしながら、特許文献１に記載の技術では、行員のみコンサルティングは行えず、コンサルタントの工数を必要とする。また、行員が適切なコンサルティングやビジネスマッチングを行うためには、十分な知識や経験が必要であり、全行員が一定品質でコンサルティングやビジネスマッチングを提供することは困難である。また、それらを提供するためには、対象顧客企業の調査や分析、営業提案、他社事例の研究など多くの工数を必要とする。

本発明は斯かる事情によりなされたものである。その目的は、企業の問題・課題及び当該問題・課題に関連する事例を出力し、事例に基づくマッチング依頼を送信するコンピュータプログラム等の提供である。

本発明に係るコンピュータプログラムは、企業の情報を取得し、前記企業の情報に基づき、問題・課題を記憶する記憶部を参照して前記企業の前記問題・課題を特定し、特定した前記問題・課題、前記企業の情報に基づき、前記問題・課題に関連する事例を特定し、特定した前記事例を出力し、前記事例に基づくマッチング依頼を受け付け、受け付けたマッチング依頼を所定の送信先へ送信する処理をコンピュータに行わせることを特徴とする。

本発明にあっては、企業の情報に基づき、企業の問題・課題を特定し出力するので、経験や知識の乏しいユーザでも、顧客企業の問題・課題を把握することが可能となる。

提供システムの構成例を示す説明図である。 提供サーバのハードウェア構成例を示す説明図である。 ユーザ端末のハードウェア構成例を示すブロック図である。 業者端末のハードウェア構成例を示すブロック図である。 ユーザＤＢの例を示す説明図である。 ユーザ企業ＤＢの例を示す説明図である。 対象企業ＤＢの例を示す説明図である。 課題類型ＤＢの例を示す説明図である。 典型課題ＤＢの例を示す説明図である。 検索履歴ＤＢの例を示す説明図である。 事例ＤＢの例を示す説明図である。 依頼ＤＢの例を示す説明図である。 商材ＤＢの例を示す説明図である。 商材実績ＤＢの例を示す説明図である。 商材評価ＤＢの例を示す説明図である。 登録商材ＤＢの例を示す説明図である。 閲覧履歴ＤＢの例を示す説明図である。 ブックマークＤＢの例を示す説明図である。 業者ＤＢの例を示す説明図である。 業務処理の手順例を示すフローチャートである。 ブックマーク登録処理の手順例を示すフローチャートである。 企業情報入力画面の例を示す説明図である。 企業情報入力画面の例を示す説明図である。 企業情報入力画面の例を示す説明図である。 課題選択画面の例を示す説明図である。 事例一覧画面の例を示す説明図である。 事例詳細画面の例を示す説明図である。 事例詳細画面の例を示す説明図である。 依頼入力画面の例を示す説明図である。 依頼入力画面の例を示す説明図である。 通知メールの例を示す説明図である。 事例登録処理の手順例を示すフローチャートである。 事例登録画面の例を示す説明図である。 事例登録画面の例を示す説明図である。 課題判定処理の手順例を示すフローチャートである。 課題判定ＤＢの例を示す説明図である。 判定モデル生成処理に関する説明図である。 判定モデル生成処理の手順例を示すフローチャートである。 提案書作成処理の手順例を示すフローチャートである。 提案書の例を示す説明図である。 提案書の例を示す説明図である。 利用登録処理の手順例を示すフローチャートである。 商材一覧画面の例を示す説明図である。 商材詳細画面の例を示す説明図である。 通知ポイントＤＢの例を示す説明図である。 通知処理の手順例を示すフローチャートである。 アンケート収集処理の手順例を示すフローチャートである。 管理画面の例を示す説明図である。 管理画面の例を示す説明図である。 シナリオＤＢの例を示す説明図である。 共有設定ＤＢの例を示す説明図である。 シナリオ表示画面の例を示す説明図である。 事例属性ＤＢの例を示す説明図である。 助成金・補助金ＤＢの例を示す説明である。 連携処理の手順例を示すフローチャートである。 他システムの画面例を示す説明図である。 他システムの画面例を示す説明図である。 事例表示処理の手順例を示すフローチャートである。 事例表示処理の手順例を示すフローチャートである。 優先表示ＤＢの例を示す説明図である。 優先表示管理画面の例を示す説明図である。 書式設定ＤＢの例を示す説明図である。 同意書設定ＤＢの例を示す説明図である。 同意書ＤＢの例を示す説明図である。 同意書作成処理の手順例を示すフローチャートである。 同意書画面の例を示す説明図である。 事例評価ＤＢの例を示す説明図である。 集計処理の手順例を示すフローチャートである。 ログイン画面の例を示す説明図である。 連携確認画面の例を示す説明図である。 検索処理の手順例を示すフローチャートである。 検索画面の例を示す説明図である。 結果一覧画面の例を示す説明図である。 問題選択画面の例を示す説明図である。 事例検索処理の手順例を示すフローチャートである。

以下実施の形態を、図面を参照して説明する。以下の説明において、ユーザは主として金融機関の職員、特に銀行で融資、コンサルティング、ビジネスマッチングを担当し、顧客企業に対して種々の提案を行っている行員を想定している。ユーザ企業はユーザが所属する企業である。業者は主として企業向けに問題・課題解決のためのソリューションを提供している企業を想定している。顧客はエンドユーザを想定している。顧客は上記ユーザから見た顧客である。以下の説明において、「問題」は、企業が目標とするものと、現状との間にあるギャップのことであり、目標達成のために、解決しなければならない事柄を示す。「課題」は、目標と現状とのギャップを埋めるために、やるべきことを示す。

（実施の形態１）
図１は提供システムの構成例を示す説明図である。提供システム１００は提供サーバ１、ユーザ端末２、業者端末３及び顧客端末４を含む。提供サーバ１、ユーザ端末２、業者端末３及び顧客端末４は、ネットワークＮにより、互いに通信可能に接続されている。図１ではユーザ端末２、業者端末３及び顧客端末４は１台ずつしか記載されていないが、それぞれが２台以上であってもよい。

図２は提供サーバのハードウェア構成例を示す説明図である。提供サーバ１（出力装置）はサーバコンピュータ、ワークステーション、ブレードサーバ等で構成する。提供サーバ１を複数のコンピュータからなるマルチコンピュータ、ソフトウェアによって仮想的に構築された仮想マシン又は量子コンピュータで構成しても良い。また、提供サーバ１の機能をクラウドサービスにより提供してもよい。

提供サーバ１は制御部１１、主記憶部１２、補助記憶部１３、通信部１４及び読み取り部１５を含む。制御部１１、主記憶部１２、補助記憶部１３、通信部１４及び読み取り部１５はバスＢにより接続されている。

制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有する。制御部１１は、補助記憶部１３に記憶された制御プログラム１Ｐ（コンピュータプログラム）を読み出して実行することにより、提供サーバ１に係る種々の情報処理、制御処理等を行う機能部（取得部、特定部、出力部）として、機能する。

主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等である。主記憶部１２は主として制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。

補助記憶部１３はハードディスク又はＳＳＤ（Solid State Drive）等であり、制御部１１が処理を実行するために必要な制御プログラム１Ｐや各種ＤＢ（Database）を記憶する。補助記憶部１３は、ユーザＤＢ１３１、ユーザ企業ＤＢ１３２、対象企業ＤＢ１３３、課題類型ＤＢ１３４、典型課題ＤＢ１３５、検索履歴ＤＢ１３６、事例ＤＢ１３７、依頼ＤＢ１３８、商材ＤＢ１３９、商材実績ＤＢ１３Ａ、商材評価ＤＢ１３Ｂ、登録商材ＤＢ１３Ｃ、閲覧履歴ＤＢ１３Ｄ、ブックマークＤＢ１３Ｅ及び業者ＤＢ１３Ｆ等を記憶する。補助記憶部１３は提供サーバ１に内蔵されるのではなく、提供サーバ１に接続された外部記憶装置であってもよい。補助記憶部１３に記憶する各種ＤＢ等を、データベースサーバやクラウドストレージに記憶してもよい。

通信部１４はネットワークＮを介して、ユーザ端末２、業者端末３及び顧客端末４と通信を行う。また、制御部１１が通信部１４を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、補助記憶部１３に記憶してもよい。

読み取り部１５はＣＤ（Compact Disc）−ＲＯＭ及びＤＶＤ（Digital Versatile Disc）−ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読み取り部１５を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、補助記憶部１３に記憶してもよい。また、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでもよい。

図３はユーザ端末のハードウェア構成例を示すブロック図である。ユーザ端末２はノートパソコン、パネルコンピュータ、タブレットコンピュータ、スマートフォン等で構成する。ユーザ端末２は制御部２１、主記憶部２２、補助記憶部２３、通信部２４、入力部２５及び表示部２６を含む。各構成はバスＢで接続されている。

制御部２１は、一又は複数のＣＰＵ、ＭＰＵ、ＧＰＵ等の演算処理装置を有する。制御部２１は、補助記憶部２３に記憶された制御プログラム２Ｐを読み出して実行することにより、種々の情報処理、制御処理等を行う。

主記憶部２２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等である。主記憶部２２は主として制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。

補助記憶部２３はハードディスク又はＳＳＤ等であり、制御部２１が処理を実行するために必要な制御プログラム２Ｐ等を記憶する。

通信部２４はネットワークＮを介して、提供サーバ１と通信を行う。また、制御部２１が通信部２４を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム２Ｐをダウンロードし、補助記憶部２３に記憶してもよい。

入力部２５はキーボードやマウス等である。表示部２６は液晶表示パネル等を含む。表示部２６は提供サーバ１が出力した顧客が抱えていると予想される問題・課題やその解決事例などを表示する。また、表示部２６は入力部２５と一体化したタッチパネルディスプレイでもよい。なお、ユーザ端末２は外部の表示装置に表示を行ってもよい。

図４は業者端末のハードウェア構成例を示すブロック図である。業者端末３はノートパソコン、パネルコンピュータ、タブレットコンピュータ、スマートフォン等で構成する。業者端末３は制御部３１、主記憶部３２、補助記憶部３３、通信部３４、入力部３５及び表示部３６を含む。各構成はバスＢで接続されている。制御部３１、主記憶部３２、補助記憶部３３、通信部３４、入力部３５及び表示部３６はそれぞれ、ユーザ端末２の制御部２１、主記憶部２２、補助記憶部２３、通信部２４、入力部２５及び表示部２６と同様であるから説明を省略する。さらに顧客端末４もユーザ端末２とハードウェア構成が同様であるから、図示及び説明を省略する。

次に提供システム１００が用いるデータベースについて説明する。図５はユーザＤＢの例を示す説明図である。ユーザＤＢ１３１はユーザの情報を記憶する。ユーザＤＢ１３１はユーザＩＤ列、氏名列、氏名カナ列、企業ＩＤ列、部署名列、役職列、メールアドレス列、及び電話番号列を含む。ユーザＩＤ列はユーザを特定するＩＤを記憶する。氏名列はユーザの氏名を記憶する。氏名カナ列はユーザの氏名のカタカナ表記を記憶する。企業ＩＤ列はユーザが所属している企業（ユーザ企業）の企業ＩＤを記憶する。部署名列はユーザが所属する部署名を記憶する。役職列はユーザの役職を記憶する。ユーザが役職を持たない場合、「なし」空白、又は空の文字列を記憶する。メールアドレス列はユーザのメールアドレスを記憶する。電話番号列はユーザの連絡先電話番号を記憶する。なお、ユーザＩＤでユーザ一意に特定可能であることが望ましいが、ユーザＩＤ及び企業ＩＤでユーザを一意に特定可能であってもよい。

図６はユーザ企業ＤＢの例を示す説明図である。ユーザ企業ＤＢ１３２はユーザ企業の情報を記憶する。ユーザ企業ＤＢ１３２は企業ＩＤ列、企業名列、法人番号列及び金融機関コード列を含む。企業ＩＤ列はユーザ企業を一意に特定可能であるＩＤを記憶する。企業名列はユーザ企業の名称を記憶する。法人番号列は企業に付与された法人番号を記憶する。金融機関コード列は企業が金融機関であって、金融機関コードを付与されている場合に当該金融機関コードを記憶する。

図７は対象企業ＤＢの例を示す説明図である。対象企業ＤＢ１３３はユーザがコンサルティングの対象として企業の情報を記憶する。対象企業ＤＢ１３３はユーザがコンサルティングを行う対象と選定し、提供システム１００にデータを入力した際に、レコードの追加を行う。同一企業に複数回コンサルティングを行った場合、各回、対象企業ＤＢ１３３にレコードが追加される。各コンサルティングはそれぞれケースと呼ぶ。したがって、対象企業ＤＢ１３３が記憶する企業の情報は、同一企業であってもケースＩＤが発番される毎に追加されるので、トランザクションデータである。対象企業ＤＢ１３３はケースＩＤ列、企業名列、法人番号列、業種列、売上規模列、所在地列、従業員数列、創業年数列、業績傾向列及び登録日列を含む。ケースＩＤ列は各ケースを一意に特定可能なＩＤを記憶する。ケースＩＤは対象企業ＤＢ１３３にレコードを追加する際に発行される。企業名列は企業の名称を記憶する。法人番号列は企業に付与された法人番号を記憶する。業種列は企業の業種を記憶する。売上規模列は企業の売上規模を記憶する。図７に示す例では、売上規模列の値はランク分けした値としている。所在地列は対象企業の所在地を記憶する。図７に示す例では、所在地列の値は都道府県名としている。従業員数列は対象企業の従業員数を記憶する。図７に示す例では、従業員数列の値はランク分けした値としている。創業年数列は対象企業の創業年数を記憶する。図７に示す例では、創業年数列の値はランク分けした値としている。業績傾向列は対象企業の業績傾向を記憶する。業績傾向列は値を正規化するため、複数の選択肢の中から選択された値を記憶する。選択肢は例えば、「激増傾向」、「増加傾向」、「横ばい」、「激増傾向」及び「激減傾向」である。登録日列はレコードが追加された日付を記憶する。

図８は課題類型ＤＢの例を示す説明図である。課題類型ＤＢ１３４は企業が抱える問題・課題をテーマ毎に類型化した各類型を記憶する。課題類型ＤＢ１３４はテーマ列、番号列及び課題列を含む。テーマ列は複数の類型を束ねうる共通のテーマを記憶する。番号列は各問題・課題を識別する番号を記憶する。課題列は問題・課題の内容を記憶する。

図９は典型課題ＤＢの例を示す説明図である。典型課題ＤＢ１３５は業種、従業員数、売上規模など企業の基本的属性に対応して、典型的に発生する問題・課題についての情報を記憶する。典型課題ＤＢ１３５は業種列、売上規模列、従業員数列、創業年数列、業績傾向列、テーマ列、課題列を含む。業種列、売上規模列、従業員数列、創業年数列及び業績傾向列はそれぞれ問題・課題と対応する業種、売上規模、従業員数、創業年数、業績傾向を記憶する。これらの値は、対象企業ＤＢ１３３が記憶する値と同様な値とする。テーマ列は問題・課題のテーマを記憶する。課題列は問題・課題に付された番号を記憶する。テーマ列及び課題列の値は、課題類型ＤＢのテーマ列及び番号列と対応が取れる値とする。

図１０は検索履歴ＤＢの例を示す説明図である。検索履歴ＤＢ１３６はユーザが事例（過去のケース）を検索した場合のその履歴を記憶する。検索履歴ＤＢ１３６はケースＩＤ列、テーマ列、課題列及び検索日時列を含む。ケースＩＤ列はケースＩＤを記憶する。テーマ列は検索条件とした問題・課題のテーマを記憶する。課題列は検索条件とした問題・課題の番号を記憶する。検索日時列は検索日時を記憶する。

図１１は事例ＤＢの例を示す説明図である。事例ＤＢ１３７は過去のコンサルティングの事例を記憶する。事例ＤＢ１３７はケースＩＤ列、業者ＩＤ列、テーマ列、課題列、効果要約列、リード文列、課題１＿見出し列、課題１＿説明文列、課題２＿見出し列、課題２＿説明文列、課題３＿見出し列、課題３＿説明文列、背景列、解決策列、画像列、選定理由列、効果列、費用列、期間列及び取材日列を含む。ケースＩＤ列はケースＩＤを記憶する。業者ＩＤ列はケースを担当した業者の業者ＩＤを記憶する。テーマ列は解決した問題・課題のテーマを記憶する。課題列は解決した問題・課題に対応する課題番号を記憶する。効果要約列は問題・課題が解決したことにより得た効果の要約を記憶する。リード文列は事例内容を端的に表現した文を記憶する。課題１＿見出し列、課題２＿見出し列及び課題３＿見出し列はそれぞれ解決した問題・課題を説明する見出しを記憶する。課題１＿説明文列、課題２＿説明文列及び課題３＿説明文列は解決した問題・課題についての説明文を記憶する。解決した問題・課題が１つの場合、課題２＿見出し列及び課題２＿説明文列、並びに、課題３＿見出し列及び課題３＿説明文列の値は空文字列とする。解決した問題・課題が２つの場合、課題３＿見出し列及び課題３＿説明文列の値は空文字列とする。背景列は問題・課題が発生した背景を記憶する。解決策列は課題を解決するために採用した策を記憶する。解決策として業務システムや業務サービス等の商材を導入した場合、それらの情報も解決策列に記憶する。画像列はケースを説明するための画像を記憶する。画像データを記憶するのではなく、画像データを記憶しているファイルの名称を記憶してもよい。選定理由列は解決策を選定した理由を記憶する。効果列は解決策を採用して得られた効果を記憶する。費用列は問題・課題解決のために費やした費用を記憶する。期間列は問題・課題解決に要した期間を記憶する。取材日列は当該ケースの内容を取得した日付を記憶する。

図１２は依頼ＤＢの例を示す説明図である。依頼ＤＢ１３８はユーザから業者に対する依頼の内容を記憶する。依頼は、ユーザが顧客企業の問題・課題を解決するために、業者に対して顧客との面談依頼などである。依頼ＤＢ１３８は選択事例列、依頼内容列、ケースＩＤ列、ユーザＩＤ列、企業ＩＤ列、及びステータス列を含む。選択事例列は依頼を行うに際して、ユーザが参照した過去の事例のケースＩＤを記憶する。依頼内容列はユーザから業者への依頼の内容を記憶する。ケースＩＤ列はケースＩＤを記憶する。ユーザＩＤ列はユーザＩＤを記憶する。企業ＩＤ列はコンサルティングを受けている企業のＩＤを記憶する。ステータス列はケースの状況を記憶する。

図１３は商材ＤＢの例を示す説明図である。商材ＤＢ１３９は業者が販売する商材の情報を記憶する。商材ＤＢ１３９は商材ＩＤ列、商材名列、業者ＩＤ列、テーマ列及び課題列を含む。商材ＩＤ列は商材を一意に特定可能なＩＤを記憶する。商材名列は商材の名称を記憶する。業者ＩＤ列は商材を提供している業者の業者ＩＤを記憶する。テーマ列及び課題列は商材の導入により解決につながる問題・課題のテーマと課題の番号を記憶する。なお、商材ＤＢ１３９が記憶する商材については、ユーザ企業が販売代理店となることを希望すれば、業者の承認なく、提供システム１００が販売代理権を付与する仕組みとなっている。

図１４は商材実績ＤＢの例を示す説明図である。商材実績ＤＢ１３Ａは商材の採用実績を記憶する。商材実績ＤＢ１３ＡはケースＩＤ列及び商材ＩＤ列を含む。ケースＩＤ列はケースＩＤを記憶する。商材ＩＤ列はケースＩＤに対応した事例において採用された商材の商材ＩＤを記憶する。

図１５は商材評価ＤＢの例を示す説明図である。商材評価ＤＢ１３Ｂは商材に対する評価を記憶する。商材評価ＤＢ１３Ｂは商材ＩＤ列、評価列、利用者数列、価格帯列、顧客層列、商材画像列、説明テキスト列及び動画列を含む。商材ＩＤ列は商材ＩＤを記憶する。評価列は商材に対するユーザ又は顧客からの評価値を記憶する。例えば、評価値は５点満点として、各ユーザ又は各顧客からの評価点の平均値を評価値とする。利用者数列は商材を利用している顧客の数を記憶する。価格帯列は商材の価格帯を記憶する。顧客層列は商材の顧客層を記憶する。商材画像列は商材のロゴ等を記憶する。説明テキスト列は商材についての説明文を記憶する。動画列が商材についての説明動画を記憶する。動画列は動画データを記憶するのではなく、動画データを記憶したファイルのファイル名を記憶してもよい。

図１６は登録商材ＤＢの例を示す説明図である。登録商材ＤＢ１３Ｃはユーザ企業が販売代理契約を結んでいる商材を記憶する。登録商材ＤＢ１３Ｃは企業ＩＤ列及び商材ＩＤ列を含む。企業ＩＤ列は企業ＩＤを記憶する。商材ＩＤ列は販売代理契約を結んでいる商材の商材ＩＤを記憶する。

図１７は閲覧履歴ＤＢの例を示す説明図である。閲覧履歴ＤＢ１３Ｄはユーザが閲覧した事例を記憶する。閲覧履歴ＤＢ１３ＤはケースＩＤ列、ユーザＩＤ列、閲覧事例列、閲覧日時列及び滞在時間列を含む。ケースＩＤ列は対応するケースのケースＩＤを記憶する。ユーザＩＤ列は閲覧したユーザのユーザＩＤを記憶する。閲覧事例列はユーザが閲覧した事例のケースＩＤを記憶する。閲覧日時列はユーザが閲覧した日時を記憶する。滞在時間列は事例の詳細情報を表示するページをユーザが表示していた時間を記憶する。

図１８はブックマークＤＢの例を示す説明図である。ブックマークＤＢ１３Ｅは事例をブックマークとして記憶する。ブックマークを用いることで、ユーザは過去に閲覧した事例を容易に読み出すことが可能となる。ブックマークＤＢ１３ＥはユーザＩＤ列、ケースＩＤ列、メモ列及び登録日時列を記憶する。ユーザＩＤ列はブックマークを関するユーザのユーザＩＤを記憶する。ケースＩＤ列はブックマークしている事例のケースＩＤを記憶する。メモ列はユーザが記入したメモを記憶する。登録日時列はブックマークが登録された日時を記憶する。

図１９は業者ＤＢの例を示す説明図である。業者ＤＢ１３Ｆは商材を提供している業者の情報を記憶する。業者ＤＢ１３Ｆは業者ＩＤ列、名称列、住所列、電話番号列、電子メール列及び担当者名列を含む。業者ＩＤ列は業者を一意に特定するＩＤを記憶する。名称列は業者の名称を記憶する。住所列は業者の所在地住所を記憶する。電話番号列は業者の連絡先電話番号を記憶する。電子メール列は業者の連絡先電子メールアドレスを記憶する。担当者名列は業者の連絡先担当者名を記憶する。

次に、提供システム１００が行う処理について説明する。図２０は業務処理の手順例を示すフローチャートである。ユーザはコンサルティングを予定している顧客企業の企業情報をユーザ端末２に入力する。ユーザ端末２の制御部２１は企業情報を取得し、提供サーバ１へ送信する（ステップＳ１）。提供サーバ１の制御部１１は企業情報を受信する（ステップＳ２）。この際、制御部１１は新たなケースＩＤを発番し、当該ケースＩＤと受信した企業情報とを対応付けて、対象企業ＤＢ１３３に記憶する。制御部１１は企業情報に基づいて、当該企業が抱えていると予想される問題・課題を抽出し、ユーザ端末２へ送信する（ステップＳ３）。制御部１１は企業情報に含まれる業種、売上規模、従業員数、創業年数、業績傾向と、典型課題ＤＢ１３５に記憶されているこれらの情報とを対照し、値が一致するレコードを抽出する。５項目全てが一致するレコードだけでなく、４項目、３項目が一致するレコードを抽出してもよい。制御部１１は抽出したレコードのテーマ及び課題番号を取得する。制御部１１は課題番号に対応付けられた問題・課題を課題類型ＤＢ１３４から取得する。制御部１１はテーマを含む問題・課題をユーザ端末２へ送信する。ユーザ端末２の制御部２１は問題・課題を受信し表示する（ステップＳ４）。制御部２１は検索対象にする問題・課題を受け付け、提供サーバ１へ送信する（ステップＳ５）。提供サーバ１の制御部１１はテーマを含む問題・課題を受信する（ステップＳ６）。制御部１１はテーマと問題・課題とをキーに事例ＤＢ１３７を検索する（ステップＳ７）。この際、制御部１１は検索履歴をテーマ、問題・課題、ケースＩＤを対応付けて、検索履歴ＤＢ１３６に記憶する。制御部１１は検索結果をユーザ端末２へ送信する（ステップＳ８）。ユーザ端末２の制御部２１は検索結果を受信し、表示部２６に表示する（ステップＳ９）。検索結果は事例の一覧である。ユーザは事例一覧から顧客企業に適合しそうな事例を選択し、詳細表示を指示する。制御部２１は詳細要求を送信する（ステップＳ１０）。提供サーバ１の制御部１１は詳細要求を受信する（ステップＳ１１）。制御部１１は選択された事例についての履歴を閲覧履歴ＤＢ１３Ｄに記憶する（ステップＳ１２）。制御部１１は閲覧履歴ＤＢにケースＩＤ、ユーザＩＤ及び参照された事例のケースＩＤを対応付けて記憶する。制御部１１は選択された事例についての詳細画面を作成し、ユーザ端末２へ送信する（ステップＳ１３）。ユーザ端末２の制御部２１は詳細画面を受信し、表示部２６に表示する（ステップＳ１４）。ユーザは事例の詳細情報を確認し、顧客企業に適合するか否かを検討する。この際、ユーザは顧客企業にも当てはまると予想される事例についての提案書を作成し、顧客企業に提案を行ってもよい。ユーザは一覧画面と詳細画面とを行き来し、事例を１つ選択する。ユーザは選択した事例の詳細画面で、事例を掲載した業者への依頼（マッチング依頼）を行う。なお、事例を複数選択し、複数の業者へ依頼を行ってもよい。すなわち、制御部２１は事例に掲載された問題・課題を解決に導いた業者への依頼を提供サーバ１へ送信する（ステップＳ１５）。提供サーバ１の制御部１１は依頼を受信し、依頼先の業者端末３へ送信する（ステップＳ１６）。業者端末３の制御部３１は依頼を受信、表示部３６に表示する（ステップＳ１７）。業者は依頼を元に提案内容を検討し、提案の送信を業者端末３に指示をする。ここで、業者への依頼は提案を求めるものだけでなく、提案に向けての打ち合わせの依頼等でもよい。ユーザ及び顧客企業と業者とのやり取りは数度、行われてもよい。ユーザ又は顧客企業と業者とのやり取りが煮詰まった段階で、業者はユーザ及び顧客企業へ提案を行う。制御部３１は提案を提供サーバ１へ送信する（ステップＳ１８）。提供サーバ１の制御部１１は提案を受信し、ユーザ端末２へ送信する（ステップＳ１９）。ユーザ端末２の制御部２１は提案を受信し、表示部２６に表示する（ステップＳ２０）。ユーザは顧客企業ともに提案内容の確認を行い、提案に基づく発注を行う。この際に、必要な経費を調達するために、ユーザが所属する銀行から顧客企業に対して、融資を行ってもよい。制御部２１は発注する旨を提供サーバ１へ送信する（ステップＳ２１）。提供サーバ１の制御部１１は発注する旨を受信し、発注されたことを業者端末３へ通知する（ステップＳ２２）。業者端末３の制御部３１は通知を受信し表示する（ステップＳ２３）。業者は発注に基づき、顧客企業に対して商材の導入やコンサルティングを行い。問題・課題の解決を行う。業者は業務の完了後、当該業務を事例として登録する。業者は解決策等を業者端末３に入力する。業者端末３の制御部３１は事例を提供サーバ１へ送信する（ステップＳ２４）。提供サーバ１の制御部１１は事例を受信し、事例ＤＢ１３７に記憶する（ステップＳ２５）。ユーザから業者への依頼や発注、業者からユーザへの提案等は、両者が自発的に提供サーバ１にアクセスしなくとも迅速に伝達できるように、提供サーバ１がユーザ及び業者へ電子メールを送信することが望ましい。電子メールは依頼を受信した旨のみの内容でもよいし、依頼内容を含めたものでもよい。

ユーザは検索の結果として得られた事例を後に迅速に読み出せるように記憶することが可能である。図２１はブックマーク登録処理の手順例を示すフローチャートである。ユーザは事例の詳細画面において、ブックマーク登録を選択する。ユーザ端末２の制御部２１は登録指示を受け付ける（ステップＳ１２７）。制御部２１はブックマークに付加するコメント入力画面を表示する（ステップＳ１２８）。ユーザは必要に応じてコメントを入力し、送信を指示する。制御部２１は、ケースＩＤとユーザＩＤとコメントとを含む登録要求を提供サーバ１へ送信する（ステップＳ１２９）。提供サーバ１の制御部１１は登録要求を受信する（ステップＳ１３０）。制御部１１は登録要求に基づき、ブックマークＤＢ１３ＥにユーザＩＤ、事例ＩＤ、及びコメントが対応付けられたブックマークを登録する（ステップＳ１３１）。なお、コメントはなくともよい。制御部１１は完了をユーザ端末２へ送信する（ステップＳ１３２）。ユーザ端末２の制御部２１は完了を受信し、表示部２６に表示する（ステップＳ１３３）。制御部２１は処理を終了する。

続いて、業務処理において使用する画面について、説明する。図２２から図２４は企業情報入力画面の例を示す説明図である。企業情報入力画面ｄ０１は図２０のステップＳ１で使用される画面である。企業情報入力画面ｄ０１は会社名入力欄ｄ０１１、業種設定ボタンｄ０１２、その他業種リンクｄ０１３、売上規模設定ボタンｄ０１４、その他売上規模リンクｄ０１５、詳細入力ボタンｄ０１６及び課題検索ボタンｄ０１７を含む。会社名入力欄ｄ０１１は顧客企業の名称を入力する欄である。業種設定ボタンｄ０１２は顧客企業の業種を入力するボタンである。表示している業種に該当するものがない場合は、その他業種リンクｄ０１３を選択すると図２３に示すように業種設定ボタンｄ０１２の数が増える。業種設定ボタンｄ０１２の並び順、その他業種リンクｄ０１３を選択する前に表示する業種はユーザ毎、ユーザの所属部署毎に設定可能としてもよい。売上規模設定ボタンｄ０１４は顧客企業の売上規模を入力するボタンである。表示している金額に該当するものがない場合は、その他売上規模リンクｄ０１５を選択すると図２３に示すように売上規模設定ボタンｄ０１４の数が増える。売上規模設定ボタンｄ０１４の並び順、その他売上規模リンクｄ０１５を選択する前に表示する金額はユーザ毎、ユーザの所属部署毎に設定可能としてもよい。詳細入力ボタンｄ０１６は上述した情報以外の顧客企業情報を入力する場合に選択する。詳細入力ボタンｄ０１６を選択すると図２４に示す従業員数選択ボタンｄ０１９、創業年数選択ボタンｄ０１ａ、業績傾向選択ボタンｄ０１ｂが表示される。従業員数選択ボタンｄ０１９により顧客企業の従業員数を設定する。創業年数選択ボタンｄ０１ａにより顧客企業の創業年数を設定する。業績傾向選択ボタンｄ０１ｂにより顧客企業の業績傾向を設定する。課題検索ボタンｄ０１７を選択すると、企業情報に基づいて想定される問題・課題が表示される。

図２５は課題選択画面の例を示す説明図である。課題選択画面ｄ０２は図２０のステップＳ５で使用される画面である。課題選択画面ｄ０２は企業情報欄ｄ０２１、課題選択ボタンｄ０２２及び事例検索ボタンｄ０２３を含む。企業情報欄ｄ０２１は企業情報入力画面ｄ０１により設定した企業情報を表示する。課題選択ボタンｄ０２２は顧客企業が抱えている問題・課題を入力するボタンである。事例検索ボタンｄ０２３は選択された問題・課題を解決した過去の事例を検索し、一覧表示する。

図２６は事例一覧画面の例を示す説明図である。事例一覧画面ｄ０３は図２０のステップＳ９で表示される画面である。事例一覧画面ｄ０３は事例表示欄ｄ０３１及びページ制御ボタンｄ０３２を含む。事例表示欄ｄ０３１は課題表示欄ｄ０３１１、企業情報欄ｄ０３１２、テーマ表示アイコンｄ０３１３、効果表示欄ｄ０３１４及び詳細表示リンクｄ０３１５を含む。課題表示欄ｄ０３１１は解決した問題・課題の概要を表示する。課題表示欄ｄ０３１１に表示する内容は、事例ＤＢ１３７の課題１＿見出し列、課題２＿見出し列及び課題３＿見出し列の値に基づく。企業情報欄ｄ０３１２は対象となった企業の情報を表示する。企業情報欄ｄ０３１２に表示する内容は、対象企業ＤＢ１３３に記憶している値に基づく。企業情報は問題・課題が解決する前の情報である。テーマ表示アイコンｄ０３１３は解決した問題・課題のテーマを表示する。テーマ表示アイコンｄ０３１３は事例ＤＢ１３７のテーマ列の値に基づいて表示する。効果表示欄ｄ０３１４は問題・課題解決により得られた効果を表示する。効果表示欄ｄ０３１４に表示する内容は、事例ＤＢ１３７の効果要約列に記憶している値に基づく。詳細表示リンクｄ０３１５を選択する事例の詳細を表示する事例詳細画面に遷移する。ページ制御ボタンｄ０３２は一覧が複数ページにわたる場合にページ遷移を行うための複数のボタンを含む。各ボタンによる制御は公知であるから説明を省略する。

図２７及び図２８は事例詳細画面の例を示す説明図である。事例詳細画面ｄ０４は図２０のステップＳ１４で表示される画面である。事例詳細画面ｄ０４は効果表示欄ｄ０４１、効果リード文欄ｄ０４２、課題見出し欄ｄ０４３、課題説明欄ｄ０４４、背景表示ボタンｄ０４５、解決策欄ｄ０４６、選定理由表示ボタンｄ０４７、効果説明欄ｄ０４８、取材日表示欄ｄ０４９、企業情報表示欄ｄ０４ａ、依頼ボタンｄ０４ｂ及びブックマークアイコンｄ０４ｃを含む。効果表示欄ｄ０４１は、は問題・課題解決により得られた効果を表示する。効果表示欄ｄ０４１に表示する内容は、事例ＤＢ１３７の効果要約列に記憶している値に基づく。効果リード文欄ｄ０４２は効果について簡単な説明文を表示する。効果リード文欄ｄ０４２に表示する内容は、事例ＤＢ１３７のリード文列に記憶している値に基づく。課題見出し欄ｄ０４３は解決した問題・課題の概要を表示する。課題見出し欄ｄ０４３に表示する内容は、事例ＤＢ１３７の課題１＿見出し列、課題２＿見出し列及び課題３＿見出し列の値に基づく。課題説明欄ｄ０４４は問題・課題の内容を表示する。課題説明欄ｄ０４４に表示する内容は、事例ＤＢ１３７の課題１＿説明文列、課題２＿説明文列及び課題３＿説明文列の値に基づく。背景表示ボタンｄ０４５は背景を表示するボタンである。背景表示ボタンｄ０４５を選択すると、背景表示ボタンｄ０４５は非表示となり、図２８Ａで示すように検討の背景についての説明文が表示される。当該説明文は事例ＤＢ１３７の背景列の値に基づく。解決策欄ｄ０４６は解決策を表示する。解決策欄ｄ０４６の表示内容は、事例ＤＢ１３７の解決策列の値に基づく。選定理由表示ボタンｄ０４７は解決策の選定理由を表示するボタンである。選定理由表示ボタンｄ０４７を選択すると、選定理由表示ボタンｄ０４７は非表示となり、図２８Ｂで示すように選定の理由についての説明文が表示される。当該説明文は事例ＤＢ１３７の選定理由列の値に基づく。効果説明欄ｄ０４８は得られた効果を表示する。効果説明欄ｄ０４８の表示内容は事例ＤＢ１３７の効果列の値に基づく。取材日表示欄ｄ０４９は事例の内容を取得した日付を表示する。取材日表示欄ｄ０４９の表示内容は事例ＤＢ１３７の取材日列の値に基づく。企業情報表示欄ｄ０４ａは企業情報を選択する。企業情報表示欄ｄ０４ａの表示内容は、対象企業ＤＢ１３３に記憶している値に基づく。依頼ボタンｄ０４ｂを選択すると依頼入力画面に遷移する。ブックマークアイコンｄ０４ｃを選択すると、表示している事例がブックマークとして保存される。

図２９及び図３０は依頼入力画面の例を示す説明図である。依頼入力画面ｄ０５は選択事例表示欄ｄ０５１、種別選択ボタンｄ０５２、依頼内容入力欄ｄ０５３、企業情報表示欄ｄ０５４、担当者入力欄ｄ０５５及び確認ボタンｄ０５６を含む。選択事例表示欄ｄ０５１は選択した事例を表示する。依頼入力画面ｄ０５は事例詳細画面ｄ０４から遷移するので、依頼入力画面ｄ０５において、事例の変更はできない。種別選択ボタンｄ０５２は依頼の種別を選択するボタンである。依頼内容入力欄ｄ０５３は依頼の具体的内容を入力する欄である。企業情報表示欄ｄ０５４は顧客企業の情報を表示する。顧客企業の情報は、事例検索時に企業情報入力画面ｄ０１にて入力しているので、その内容を引き継ぐ。依頼入力画面ｄ０５において、企業情報入力画面ｄ０１において未入力であった項目を追加入力したり、入力済みの項目を変更したりしてもよい。担当者入力欄ｄ０５５はユーザの情報を入力する欄である。ユーザは提供システム１００にログインしている場合、ユーザＤＢ１３１に記憶している値が、担当者入力欄ｄ０５５に入力された状態で依頼入力画面ｄ０５が表示される。金融機関名はユーザＤＢ１３１の企業ＩＤ列の値に基づき、ユーザ企業ＤＢ１３２を検索し、ヒットしたレコードの企業名列の値が入力される。確認ボタンｄ０５６は依頼内容を確定し、確認画面に遷移するためのボタンである。

確認画面は図示を省略するが、表示内容は依頼入力画面ｄ０５と同様である。確認画面では確認ボタンｄ０５６はなく、修正ボタン及び依頼ボタンが表示される。修正ボタンを選択すると、確認画面から依頼入力画面ｄ０５へ戻る。依頼ボタンが選択すると、依頼内容が提供サーバ１へ送信され記憶される。そして、提供サーバ１は業者の電子メールアドレス宛（送信先）へ電子メールを送信する。電子メールアドレスは業者ＩＤを検索キーにより業者ＤＢ１３Ｆを検索し習得する。例えば、依頼内容が電子メールで送信される。または、依頼内容が送信された旨の電子メールが送信され、メールを表示している業者端末３において、メールに含まれるリンクを選択すると、業者端末３が提供システム１００に接続され、依頼内容が業者端末３に表示されるようにしてもよい。

図３１は通知メールの例を示す説明図である。図３１に示す例は、依頼内容がメールにすべて含まれている例である。メールに含まれるＵＲＬ３１１は過去の事例を表示するためのＵＲＬであり、当該ＵＲＬ３１１を選択することにより、提供システム１００に登録した事例が表示されるので、業者は過去のどのような事例に基づいて、依頼がされたことを把握することが可能となる。

業者が依頼内容を受け取った後、顧客企業と業者とは打ち合わせやＷｅｂ会議の日程調整を行う。業者が行うコンサルティングの内容、導入する商材、総費用について、双方が同意すれば受発注が行われる。その後、業者がソリューションを提供し、問題・課題が解決されて、ケースは終了する。これらの業務に関して、提供システム１００がサービスを提供するが、これらについては、公知のワークフローシステム、プロジェクト管理システムなどで実現可能であるので、ここでは説明を省略する。提供システム１００がサービスを提供するのではなく、ワークフローシステム、プロジェクト管理システムなどと連携してもよい。他のシステムと連携する場合でも、ケースの最新の状態（最新の状況）を提供システム１００が取得し、依頼ＤＢ１３８のステータス列が最新のステータスを記憶していることが望ましい。

続いて、事例登録機能について述べる。終了したケースは事例として登録する。図３２は事例登録処理の手順例を示すフローチャートである。事例登録処理はバッチ処理により、繰り返し実行する。または、各ケースのステータスを管理している依頼ＤＢ１３８が更新されたら実行する。提供サーバ１の制御部１１は完了ケースがあるか否かを判定する（ステップＳ３１）。制御部１１は依頼ＤＢ１３８を検索し、ステータスが完了となっているケースがあるか否かを判定する。例えば、ステータス列の値が「完了」であるケースである。制御部１１は完了ケースがないと判定した場合（ステップＳ３１でＮＯ）、処理を終了する。制御部１１は完了ケースがあると判定した場合（ステップＳ３１でＹＥＳ）、依頼メールを業者宛に送信する（ステップＳ３２）。業者端末３の制御部３１は依頼メールを受信する（ステップＳ３３）。依頼メールを読んだ業者は作業を開始する。制御部３１は登録画面の要求を提供サーバ１へ送信する（ステップＳ３４）。登録画面の要求は例えばＨＴＴＰリクエストである。提供サーバ１の制御部１１は要求を受信する（ステップＳ３５）。制御部１１は登録画面を生成し業者端末３へ送信する（ステップＳ３６）。前記要求にはケースを特定するケースＩＤが含まれており、対象企業ＤＢ１３３に記憶されている企業情報など既に既知の項目については、生成した登録画面において、入力済みとなっていることが望ましい。業者端末３の制御部３１は登録画面を受信し、表示部３６に表示する（ステップＳ３７）。業者は登録画面に事例情報を入力し、送信を指示する。制御部３１は事例情報を受け付け、提供サーバ１へ送信する（ステップＳ３８）。提供サーバ１の制御部１１は事例情報を受信し、事例ＤＢ１３７に記憶する（ステップＳ３９）。制御部１１はケースのステータスを、事例が登録されたことを示す登録済に変更し、処理を終了する（ステップＳ４０）。

図３３及び図３４は事例登録画面の例を示す説明図である。事例登録画面ｄ０６は概要セクションｄ０６１、課題セクションｄ０６２、解決策セクションｄ０６３、効果セクションｄ０６４、その他セクションｄ０６５及び企業セクションｄ０６６、並びに、確認ボタンｄ０６７を含む。概要セクションｄ０６１には事例の概要を入力する。概要セクションｄ０６１は項目としてテーマ、効果及びリード文を含む。テーマはプルダウンメニューにより最適なテーマを選択する。課題セクションｄ０６２には問題・課題の内容を入力する。課題セクションｄ０６２は項目として、見出し１〜３、見出しについての説明、背景及び検索タグを含む。検索タグは問題・課題の類型を付与する。検索タグの付与は、プルダウンメニューで表示される選択肢の中から問題・課題に対応したものを選択することで行う。選択肢の内容は課題類型ＤＢ１３４に基づく。解決策セクションｄ０６３には問題・課題に対して採用した解決策を入力する。解決策セクションｄ０６３は項目として説明、画像及び選定の理由を含む。解決策セクションｄ０６３では画像の登録が可能である。設定された画像のサムネイルｄ０６３１が表示される。設定ボタンｄ０６３２を選択することにより、登録する画像ファイルを設定する。削除ボタンｄ０６３３を選択することにより、画像ファイルの設定をクリアする。解決策セクションｄ０６３は項目として説明を含む。効果セクションｄ０６４には対象企業が得た効果を入力する。その他セクションｄ０６５にはその他の情報を入力する。その他セクションｄ０６５は項目として、費用、期間、取材日を含む。なお、取材日は完了後に業者が対象企業に対してヒアリングを行った日付、事例情報を入力した日等を入力する。確認ボタンｄ０６７を選択すると、入力内容を確認する確認画面へ遷移する。確認画面において確定ボタンを選択すると、入力内容が事例ＤＢ１３７に記憶される。

上述では、提供システム１００を通じて発生したケースが完了した場合での事例登録としたが、提供システム１００とは別のルートで発生したケースも事例登録画面ｄ０６を用いて事例ＤＢ１３７に登録してもよい。この場合、対象企業ＤＢ１３３にもレコードを追加する。

本実施の形態においては、コンサルティングの対象とする企業の基本的情報を入力すると、当該企業が抱えていると予想される問題・課題が得られる。また、問題・課題を選択すると、過去の事例から同様な問題・課題を解決した事例を検索することが可能となる。さらに、参照した事例に含まれる問題・課題を解決した業者に連絡が可能である。以上により、コンサルティングに不慣れなユーザであっても、企業に的確なコンサルティングが行なえ、業者と協力して顧客企業の問題・課題を解決することが可能となる。特にユーザが銀行等の行員である場合は、コンサルティングに伴い、顧客企業に対しての融資が可能となる。また、過去の事例に基づいて問題・課題解決を行うので、顧客企業は着実に効果を得られる可能性が高くので、融資が焦げ付くことなく回収することが期待される。また、ユーザは提供システム１００を利用することで、課題解決のためのコンサルティングを提供する業者や、課題解決に役立つ商品等の外部リソースを用いた幅広いコンサルティングを行うことが可能となる。ユーザは顧客企業と業者とを結びつけるビジネスマッチングを行うことにより、両者の発展に寄与するだけでなく、マッチングについての手数料収入を得ることが可能となる。提供システム１００は顧客企業、金融機関及び業者の三者が協力して、当該顧客企業が抱える問題・課題を解決するので、問題解決プラットホームとも称すべきものと言える。

（実施の形態２）
本実施の形態は顧客企業の問題・課題を、他システムのデータに基づいて特定する形態に関する。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。以下の説明においては、主として実施の形態１と異なる点について説明する。

ここで、他システムは予約システム、ＰＯＳ（Point of sale system）システム、勤怠システム、会計システム、給与システム、受発注システム、日報システム、ＳＮＳ（Social Networking Service）を含む。予約システムは医療機関の診察予約、飲食店の座席予約、貸会議室に関する施設予約、旅行に関するツアー予約、交通機関に関する切符予約、語学学習に関するレッスン予約、エステサロン・ネールサロンに関する施術予約など、種々の予約を行うシステムを含む。ＰＯＳシステムは物品販売の売上実績を単品単位で集計する一般的なシステム以外に、サービス業におけるサービスの売上実績をサービスメニュー単位で集計するものも含む。勤怠システムは正社員、契約社員、パートタイマーなどを含む従業員の勤怠を管理するシステムである。会計システムは管理会計システム、財務会計システム等である。給与システムは従業員に支払うべき給与を計算するとともに給与支払いの履歴を保存するシステムである。受発注システムは商品やサービスの受注及び発注を行うためのシステムである。日報システムは社員が就業日毎に作成する日報を作成、記憶するシステムである。

図３５は課題判定処理の手順例を示すフローチャートである。ユーザは問題・課題を特定したい企業の識別情報（会社名、法人番号等）を提供サーバ１へ送信する。提供サーバ１の制御部１１は対象企業の識別情報を取得する（ステップＳ５１）。制御部１１は他システムから対象企業の情報を取得する（ステップＳ５２）。制御部１１は取得した情報の変化傾向を解析する（ステップＳ５３）。例えば、売上の変化、離職状況、受注状況を解析する。制御部１１は解析内容より課題を特定する（ステップＳ５４）。課題の特定については後述する。制御部１１は特定した課題を出力する（ステップＳ５５）。ユーザは特定された課題に基づき、事例検索等を行う。以降の処理は実施の形態１と同様であるから、省略する。

図３６は課題判定ＤＢの例を示す説明図である。図３６に示すように、課題判定ＤＢ１３Ｇは複数のテーブルから構成されていてもよい。課題判定ＤＢ１３Ｇはシステム列、項目列、傾向列及び課題列を含む。システム列は情報源となる他システムの識別子、例えばシステムの略称を記憶する。項目列は解析対象の識別子、例えば項目名を記憶する。傾向列は解析対象の値の傾向を記憶する。課題列は予想される問題・課題を記憶する。図３６Ａは対象企業が飲食業の場合の例である。例えば、ＰＯＳシステムから売上（ＰＯＳ情報の一例）を取得し、前後する所定期間での変化が、１０％減少であった場合、売上減少を解決すべき問題・課題と判定する。また、日報システムから日々の日報で使われている特定の語を検索する。例えばクレームという語が増加傾向にある場合、人員不足による業務負荷増を解決すべき問題・課題と判定する。この場合、勤怠システムから得た人員数（人財情報の一例）の傾向も見ることにより、業務負荷増の原因は人員不足であると確定する。図３６Ｂは取引形態がＢ ｔｏ Ｂの企業向けである。例えば、営業情報システムから得た受注率（会計情報の一例）の傾向が、低下傾向であった場合、営業力低下を解決すべき問題・課題と判定する。

図３５のステップＳ５３で行う解析は、課題判定ＤＢ１３Ｇに特定されているレコードに合わせて行ってもよい。それにより、解析処理を最低限の処理量とすることができる。

（実施の形態３）
本実施の形態は顧客企業の問題・課題を、他システムのデータに基づいて特定する形態に関する。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。以下の説明においては、主として実施の形態１と異なる点について説明する。実施の形態２においては予め判定ロジックを決め、当該判定ロジックを記憶した課題判定ＤＢ１３Ｇを用意する必要があったが、本実施の形態においては機械学習により得た判定モデル（学習モデル）を用いて判定することにより、判定ロジックの検討が不要となる。

図３７は判定モデル生成処理に関する説明図である。図３７機械学習を行って判定モデル１６を生成する処理を概念的に示している。判定モデル１６は補助記憶部１３に記憶する。

提供サーバ１は、判定モデル１６として、定量データ及び定性データ並びに問題・課題を含む教師データとして、ディープラーニングを行う。それによって、定量データ及び定性データを入力とし、問題・課題を出力とするニューラルネットワークを生成する。ニューラルネットワークは例えばＣＮＮ（Convolution Neural Network）であり、対象企業に対する定量データ及び定性データの入力を受け付ける入力層と、対象企業が抱えている問題・課題を出力する出力層と、定量データ及び定性データの特徴量を抽出する中間層とを有する。

定量データは、ＰＯＳ、請求システム、予約データ、会計データ、勤怠データ、社員のモチベーションデータ、ＣＲＭ（Customer Relationship Management）やＳＦＡ（Sales Force Automation）から得られる営業情報等である。定性データは、電子メール、社内ＳＮＳ、従業員アンケートの回答結果、日報、コールセンターにおける対応履歴、Ｗｅｂページにより収集した問い合わせデータ、顧客アンケートの回答データ、ＳＮＳの口コミ、スコア、ソーシャルリスニングツールから得たデータ等である。

入力層は、定量データ及び定性データに含まれる各種データの入力を受け付ける複数のニューロンを有し、入力された各種データを中間層に受け渡す。中間層は複数のニューロンを有し、定量データ及び定性データの特徴量を抽出して出力層に受け渡す。例えば判定モデル１６がＣＮＮである場合、中間層は、入力層から入力された各種データを畳み込むコンボリューション層と、コンボリューション層で畳み込んだ定量データ及び定性データをマッピングするプーリング層とが交互に連結された構成を有し、定量データ及び定性データの特徴量を抽出する。出力層は判定器であり、問題・課題を出力する一又は複数のニューロンを有し、中間層から出力された特徴量に基づいて、問題・課題を判定する。本実施の形態では判定モデル１６がＣＮＮであるものとして説明するが、判定モデル１６はＣＮＮに限定されず、ＣＮＮ以外のニューラルネットワーク、ベイジアンネットワーク、決定木など、他の学習アルゴリズムで構築された学習済みモデルであってよい。

提供サーバ１は、定量データ及び定性データと、問題・課題の正解値とが対応付けられた教師データを用いて学習を行う。例えば図３７に示すように、教師データは、定量データ及び定性データと問題・課題とがラベル付けされたデータである。

提供サーバ１は、教師データである定量データ及び定性データを入力層に入力し、中間層での演算処理を経て、出力層から問題・課題を取得する。提供サーバ１は、出力層から出力された結果を、教師データにおいて定量データ及び定性データに対しラベル付けされた問題・課題、すなわち正解値と比較し、出力層からの出力値が正解値に近づくように、中間層での演算処理に用いるパラメータを最適化する。当該パラメータは、例えばニューロン間の重み（結合係数）、各ニューロンで用いられる活性化関数の係数などである。パラメータの最適化の方法は特に限定されないが、例えば提供サーバ１は誤差逆伝播法を用いて各種パラメータの最適化を行う。

図３８は判定モデル生成処理の手順例を示すフローチャートである。図３８に基づき、教師データから判定モデル１６を生成する機械学習処理の内容について説明する。提供サーバ１の制御部１１は過去の事例を収集する（ステップＳ６１）。制御部１１は処理対象とする事例を選択する（ステップＳ６２）。制御部１１は事例の対象となった企業の情報を収集する（ステップＳ６３）。収集する情報は、事例のおける問題・課題が解決する以前の定量データ及び定性データである。制御部１１は収集した定量データ及び定性データ、並びに事例に含まれる解決した問題・課題より教師データを作成する（ステップＳ６４）。制御部１１は教師データにより学習を行う（ステップＳ６５）。制御部１１は未処理の事例があるか否かを判定する（ステップＳ６６）。制御部１１は未処理の事例があると判定した場合（ステップＳ６６でＹＥＳ）、処理をステップＳ６２へ戻し、未処理の事例についての処理を行う。制御部１１は未処理の事例がないと判定した場合（ステップＳ６６でＮＯ）、判定モデル１６についてのパラメータ等を記憶し（ステップＳ６７）、処理を終了する。

判定モデル１６を用いた課題判定処理について説明する。図３５に示した処理手順の一部が異なる。図３５のステップＳ５３は不要である。ステップＳ５４及びステップＳ５５は次のように変更する。制御部１１はステップＳ５２で取得した情報を判定モデル１６に入力し、出力として予測される問題・課題を取得する。制御部１１は取得した問題・課題を出力する。

本実施の形態においては、企業の問題・課題が含まれた過去の事例と、事例の対象となった企業についての種々の情報とに基づいて、学習を行った判定モデル１６を用いる。ユーザは、コンサルティング対象の企業についての情報を収集し、判定モデル１６に入力することで、対象の企業が抱えていると予想される問題・課題を得ることが可能となる。

本実施の形態において、判定モデル１６としてＲＮＮ（Recurrent Neural Network）を採用し、定性データ及び定量データを時系列データとし、各時系列データと問題・課題とを対応付けた教師データで、判定モデル１６の学習を行ってもよい。判定モデル１６で問題・課題を判定する際には、定性データ及び定量データの時系列データを判定モデル１６に入力し、判定モデル１６に出力として、問題・課題を習得する。

（実施の形態４）
本実施の形態は、事例から顧客企業向けの提案書を作成する機能に関する。当該機能は、上述の実施の形態１から３に追加されるものである。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。

図３９は提案書作成処理の手順例を示すフローチャートである。ユーザは提案書の作成対象とするケースを選択する。例えば、対象企業ＤＢ１３３に基づいて作成した顧客企業の一覧から１つの顧客企業を選択する。選択情報はユーザ端末２から提供サーバ１へ送信される。制御部１１は選択された顧客企業に対応するケースＩＤを取得する（ステップＳ８１）。制御部１１は顧客企業が抱えていると予想されるテーマ及び問題・課題を取得する（ステップＳ８２）。制御部１１はケースＩＤをキーに検索履歴ＤＢ１３６を検索し、ヒットしたレコードのテーマ列の値、課題列に記憶してある課題番号を取得する。さらに、課題番号に対応した問題・課題を、課題類型ＤＢ１３４の課題列から取得する。制御部１１は事例を取得する（ステップＳ８３）。ユーザが閲覧した事例については、閲覧履歴ＤＢ１３Ｄの閲覧事例列に記憶してあるケースＩＤを取得し、当該ケースＩＤに対応付いた事例情報を事例ＤＢ１３７から取得する。閲覧履歴に加えて、ブックマークしている事例を取得してもよい。ブックマークＤＢ１３ＥのケースＩＤ列に記憶してあるケースＩＤを取得し、当該ケースＩＤに対応付いた事例情報を事例ＤＢ１３７から取得する。制御部１１は取得した事例をユーザ端末２へ送信し、ユーザ端末２は取得した事例を表示する。ユーザは提案書に含める事例を選択する。事例の選択情報はユーザ端末２から提供サーバ１へ送信される。制御部１１は事例の選択情報を取得する（ステップＳ８４）。制御部１１は選択された事例に対応した商材及び業者の情報を取得する（ステップＳ８５）。制御部１１はケースＩＤを検索キーにして商材実績ＤＢ１３Ａを検索し、各事例で採用された商材の商材ＩＤを取得する。取得した商材ＩＤを検索キーに商材ＤＢ１３９を検索し、商材の情報を取得する。また、制御部１１は事例情報に対応した業者ＩＤを検索キーに業者ＤＢ１３Ｆを検索し、業者の情報を取得する。制御部１１は上記で取得した情報を元に提案書を作成する（ステップＳ８６）。提案書は例えばＰＤＦ形式とする。制御部１１は作成した提案書を出力し（ステップＳ８７）、処理を終了する。

図２０で示したステップＳ１４とステップＳ１５との間で提案書を提案書作成処理により、作成することが可能である。すなわち、ユーザは、検索結果として得た事例の一覧から、顧客企業に適合しそうな事例を選択し、詳細を確認する。ユーザは事例の詳細情報を確認し、顧客企業に適合する事例を選択する。ユーザは選択した事例に基づく提案書の作成を指示する。図３９のステップＳ８５以降が実行され、提案書が作成される。

図４０及び図４１は提案書の例を示す説明図である。図４０Ａは表紙ページの例を示す。表紙ページは宛名４０１、ロゴ４０２及びタイトル４０３を含む。タイトル４０３は選択した事例等に基づき作成する。または、ユーザの入力による。宛名４０１はケースの対象となっている顧客企業の名称が入力される。当該名称は対象企業ＤＢ１３３の企業名列から取得する。ロゴ４０２はユーザ企業のロゴマークである。ロゴマークは例えばユーザ企業ＤＢ１３２に記憶しておく。図４０Ｂは問題・課題の表示ページである。当該ページは、顧客企業が抱えていると予想される経営課題のテーマ、問題及び課題をノードで示し、互いの関係をリンクで表現したグラフ図４０４を含む。グラフ図４０４は事例を検索する際に指定した問題・課題や、選択した事例に基づき作成される。図４０Ｃは解決事例ページの例を示す。例えば、ユーザが選択した課題が３つであり、各課題についての事例が１つずつ選択したのであれば、解決事例ページは３つの事例を含む。解決事例ページに記載される内容は、図２７及び図２８に示した事例詳細画面ｄ０４の表示内容と同様である。図４１Ａは企業・商品の紹介ページである。選択した事例に対応付けられた商品の情報や、事例を登録した業者の情報が表示される。図４１Ｂはその他ページの例を示す。その他ページは事例に対応付いた補足情報が記載される。提案書のフォーマットはユーザ企業毎に用意され、ユーザの所属するユーザ企業のフォーマットを制御部１１は選択して、提案書を作成する。

本実施の形態においては、提案書作成に不慣れなユーザであっても、顧客企業向けの提案書を簡単かつ迅速に作成可能である。

（実施の形態５）
上述したように、商材ＤＢ１３９が記憶する商材については、ユーザ企業が販売代理店となることを希望すれば、業者の承認なく、提供システム１００が販売代理権を付与する仕組みとなっている。本実施の形態は当該業務を支援する機能に関する。当該機能は、上述の実施の形態１から４に追加されるものである。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。

提供システム１００の運営会社（管理者）は、商材を販売する業者と包括的な販売契約を行い、提供システム１００のユーザであれば、運営会社は業者の許可なく、ユーザに商材の販売代理権を付与できるものとする。業者は対象とする商材を商材ＤＢ１３９に登録する。

一方、ユーザは商材ＤＢ１３９に登録してある商材を提供システム１００で利用登録することで、顧客企業へ販売することが許可される。図４２は利用登録処理の手順例を示すフローチャートである。ユーザはユーザ端末２の表示部２６に表示された機能一覧から商材の利用登録を選択する。ユーザ端末２の制御部２１は商材一覧要求を提供サーバ１へ送信する（ステップＳ１０１）。提供サーバ１の制御部１１は商材一覧要求を受信する（ステップＳ１０２）。制御部１１は一覧を作成し、ユーザ端末２へ送信する（ステップＳ１０３）。ユーザ端末２の制御部２１は一覧を受信し、表示部２６に表示する（ステップＳ１０４）。ユーザは一覧から登録したい商材を選択する。制御部２１は選択情報を取得し、提供サーバ１へ送信する（ステップＳ１０５）。提供サーバ１の制御部１１は選択情報を受信する（ステップＳ１０６）。制御部１１は選択された商材の詳細画面を作成し、ユーザ端末２へ送信する（ステップＳ１０７）。ユーザ端末２の制御部２１は詳細画面を受信し、表示部２６に表示する（ステップＳ１０８）。ユーザ端末２は処理を選択する。制御部２１は選択された処理が登録であるか否かを判定する（ステップＳ１０９）。制御部２１は選択された処理が登録であると判定した場合（ステップＳ１０９でＹＥＳ）、登録要求を提供サーバ１へ送信する（ステップＳ１１０）。提供サーバ１の制御部１１は登録要求を受信する（ステップＳ１１１）。制御部１１は登録を行う（ステップＳ１１２）。制御部１１はユーザＩＤに対応付いている企業ＩＤと、選択されている商材の商材ＩＤとを対応付けて、登録商材ＤＢ１３Ｃに記憶する。制御部１１は登録完了をユーザ端末２へ送信する（ステップＳ１１３）。ユーザ端末２は完了を受信し、表示部２６に表示した（ステップＳ１１４）後に、処理を終了する。制御部２１は選択された処理が登録であると判定しなかった場合（ステップＳ１０９でＮＯ）、選択された処理が戻るであるか否かを判定する（ステップＳ１１５）。制御部１１は選択された処理が戻るであると判定した場合（ステップＳ１１５でＹＥＳ）、処理をステップＳ１０１へ戻す。制御部１１は選択された処理が戻るでないと判定した場合（ステップＳ１１５でＮＯ）、処理を終了する。

図４３は商材一覧画面の例を示す説明図である。商材一覧画面ｄ０７は図４２のステップＳ１０４で表示される画面である。商材一覧画面ｄ０７は商材画像ｄ０７１、商品概要ｄ０７２及び属性アイコンｄ０７３並びに切替タブｄ０７４を含む。商材画像ｄ０７１は商材のロゴ画像等である。商品概要ｄ０７２は商材の名称、評価、利用者数を含む。属性アイコンｄ０７３は商材の属性を表すアイコンを含む。属性は価格、機能、ユーザ層などである。切替タブｄ０７４は商材グループを切り替えるためのタブである。グループは、おすすめ、ランキング、カテゴリ、高収益、新着などである。

図４４は商材詳細画面の例を示す説明図である。商材詳細画面ｄ０８は図４２のステップＳ１０８で表示される画面である。商材詳細画面ｄ０８は商材画像ｄ０８１、商材概要ｄ０８２、動画ｄ０８３、詳細説明ｄ０８４、登録ボタンｄ０８５及び戻るボタンｄ０８６を含む。商材画像ｄ０８１は商材のロゴ画像等である。商材概要ｄ０８２は商材の名称、評価、利用者数を含む。動画ｄ０８３は商材を紹介する動画である。詳細説明ｄ０８４は商材の説明文章である。登録ボタンｄ０８５を選択すると、登録の指示が送信される。戻るボタンｄ０８６を選択すると、商材一覧画面ｄ０７へ戻る。

本実施の形態にあっては、ユーザは契約手続の手間を掛けることなく、新たな商材の販売代理権を習得することが可能となる。

（実施の形態６）
上述の実施の形態では、提供システムのユーザは顧客企業に提案を行う金融機関の行員を想定していたが、それに限らず顧客企業の社員、業者の社員等をユーザに含めてもよい。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。以下、金融機関の行員を銀行ユーザ、顧客企業の社員等を企業ユーザ、業者の社員等を業者ユーザと呼ぶ。銀行ユーザ、企業ユーザ及び業者ユーザの情報は、ユーザＤＢ１３１に記憶する。ユーザＤＢ１３１に例えば、種別列を追加し、種別列の値で銀行ユーザ、企業ユーザ又は業者ユーザの区別が行えるようにする。また、顧客企業、業者についての情報はユーザ企業ＤＢ１３２に記憶する。それに伴い列を追加し、記憶できるデータ項目を増やしてもよい。例えば、ユーザ企業ＤＢ１３２に、顧客企業を担当する金融機関の銀行ユーザのユーザＩＤを記憶してもよい。

本実施の形態は、企業ユーザの閲覧履歴が所定の条件を満たす場合、銀行ユーザへ通知を行う形態に関する。企業ユーザの閲覧履歴から、顧客企業が抱えている問題・課題が浮き彫りになった場合に、当該企業を担当する銀行ユーザに通知する。企業ユーザが特定の問題・課題に対する検索を行っている場合、当該問題・課題を企業が抱えている可能性が高いと想定する。また、企業ユーザが特定の事例を短期間に繰り返し参照している場合、事例と同じ問題・課題を抱え、同様な解決手段を求めている可能性が高いと想定する。

図４５は通知ポイントＤＢの例を示す説明図である。通知ポイントＤＢ１３Ｈは閲覧履歴を点数化するための情報を記憶する。通知ポイントＤＢ１３Ｈは条件列及びポイント列を含む。条件列はポイントを付与する条件を記憶する。ポイント列は閲覧履歴が条件にマッチした場合に付与するポイントを記憶する。

図４６は通知処理の手順例を示すフローチャートである。通知処理はバッチ処理等により繰り返し実行する。提供サーバ１の制御部１１は処理対象とする企業を選択する（ステップＳ１４１）。制御部１１は企業に所属する企業ユーザの閲覧履歴を取得する（ステップＳ１４２）。制御部１１は通知ポイントＤＢ１３Ｈと閲覧履歴とを対照し、通知ポイントＤＢ１３Ｈの条件列に適合する履歴に基づき、事例毎にポイントを合算したスコア算出する（ステップＳ１４３）。制御部１１はスコアが閾値を超えているか否かを判定する（ステップＳ１４４）。閾値は予め設定しておく。制御部１１はスコアが閾値を超えていると判定した場合（ステップＳ１４４でＹＥＳ）、アラートを送信する（ステップＳ１４５）。アラートは例えば電子メールよる通知である。電子メールの宛先は企業を担当する銀行ユーザである。企業と銀行ユーザとの対応関係は、ユーザ企業ＤＢ１３２に予め記憶しておく。担当する銀行ユーザの電子メールアドレスはユーザＤＢ１３１のメールアドレス列から取得する。制御部１１はスコアが閾値を超えていないと判定した場合（ステップＳ１４４でＮＯ）、処理をステップＳ１４６へ移す。制御部１１は未処理の企業があるか否かを判定する（ステップＳ１４６）。制御部１１は未処理の企業があると判定した場合（ステップＳ１４６でＹＥＳ）、処理をステップＳ１４１へ戻し、未処理の企業に対する処理を行う。制御部１１は未処理の企業がないと判定した場合（ステップＳ１４６でＮＯ）、処理を終了する。

本実施の形態においては、企業ユーザの閲覧履歴から、顧客企業が抱えている問題・課題が浮き彫りになった場合に、当該企業を担当する銀行ユーザに通知するので、銀行ユーザは通知に基づき、顧客企業への提案を行うことが可能となる。

（実施の形態７）
本実施の形態は顧客企業へのアンケートを行う形態に関する。本実施の形態において、システム構成、提供サーバ１のハードウェア構成等は実施の形態１と同様である。以下の説明において、企業端末は上述のユーザ端末２と同様である。

図４７はアンケート収集処理の手順例を示すフローチャートである。アンケート収集処理はバッチ処理により、繰り返し実行する。または、各ケースのステータスを管理している依頼ＤＢ１３８が更新されたら実行する。提供サーバ１の制御部１１は完了ケースがあるか否かを判定する（ステップＳ１５１）。制御部１１は依頼ＤＢ１３８を検索し、ステータスが完了となっているケースがあるか否かを判定する。例えば、ステータス列の値が「完了」であるケースである。制御部１１は完了ケースがないと判定した場合（ステップＳ１５１でＮＯ）、処理を終了する。制御部１１は完了ケースがあると判定した場合（ステップＳ１５１でＹＥＳ）、依頼メールを企業端末宛に送信する（ステップＳ１５２）。企業端末は依頼メールを受信する（ステップＳ１５３）。依頼メールを読んだ企業ユーザは作業を開始する。企業端末はアンケート画面の要求を提供サーバ１へ送信する（ステップＳ１５４）。登録画面の要求は例えばＨＴＴＰリクエストである。提供サーバ１の制御部１１は要求を受信する（ステップＳ１５５）。制御部１１はアンケート画面を生成し企業端末へ送信する（ステップＳ１５６）。企業端末はアンケート画面を受信し、表示部に表示する（ステップＳ１５７）。企業ユーザはアンケート画面に表示された質問を読み、回答を入力し、送信を指示する。企業端末は回答を受け付け、提供サーバ１へ送信する（ステップＳ１５８）。提供サーバ１の制御部１１は回答を受信し、補助記憶部１３に記憶する（ステップＳ１５９）。制御部１１はケースのステータスを更新する（ステップＳ１６０）。ステータスが「完了」であれば、「完了・アンケート済」とする。ステータスが「登録済」であれば、「登録済・アンケート済」とする。それに伴い、事例登録処理のステップＳ４０の処理内容を適宜変更する。制御部１１はアンケート結果に基づき、業者の評価、商材の評価、参照された事例の評価等を更新し（ステップＳ１６１）、処理を終了する。

アンケートにより収集する項目としては、ＮＰＳ（登録商標）（Net Promoter Score）、満足度、改善点、現在困っていること等である。ＮＰＳは、コンサルティングを受けた業者に対して、どれくらいの愛着や信頼があるかを数値化する指標である。ＮＰＳは、「今回、コンサルティングを受けた業者や購入した商材を同僚や他部署に薦めたいと考えますか？０〜１０の１１段階でお答えください。」、「その理由を教えてください。」等の質問により、他者への推奨度を数値化した指標である。満足度はコンサルティングの満足度や購入した商材に対する満足度である。改善点はコンサルティングや商材に対して改善すべき点である。現在困っていることはコンサルティング受けた後、商材を購入した後に新たなに発生又は気づいた業務上の問題である。購入した商材に対する評価については数値評価（５点満点で何点か）を収集してもよい。

（管理画面）
次に提供システム１００の管理機能について説明する。管理機能はユーザ種別により異なる。図４８及び図４９は管理画面の例を示す説明図である。図４８Ａは企業ユーザ向けの管理画面の例を示す。管理画面ｄ０９はメニュー一覧ｄ０９１及び戻るボタンｄ０９２を含む。メニュー一覧ｄ０９１に含むメニューは例えば、メニュー１「ビジネスマッチング案件管理」、メニュー２「お気に入り事例、商品管理」、メニュー３「キャンペーン等お知らせ」である。メニュー１は問題・課題を解決するための依頼を、業者に送信した案件を一覧表示したり、各案件の状況を確認したりする機能を提供するメニューである。メニュー２は事例のブックマークを参照したり、提供システム１００を介して購入した商品を参照したりする機能を提供するメニューである。メニュー３はキャンペーンのお知らせ等の提供システム１００からの通知を表示する機能を提供するメニューである。戻るボタンｄ０９２はホーム画面等に戻るためのボタンである。

図４８Ｂは銀行ユーザ向けの管理画面の例を示す。管理画面ｄ１０はメニュー一覧ｄ１０１及び戻るボタンｄ１０２を含む。メニュー一覧ｄ１０１に含むメニューは例えば、メニュー１「ビジネスマッチング実績集計、レポート作成」、メニュー２「ビジネスマッチングの傾向分析、予測」、メニュー３「ビジネスマッチング商品の追加」、メニュー４「ビジネスマッチングの案件管理」である。メニュー１は提供システム１００を利用して、ユーザ企業に業者を紹介した案件の実績を集計したり、実績についてのレポートを作成したりする機能を提供するメニューである。当該メニューにより、銀行ユーザは例えば、マッチング件数、閲覧履歴、売上高、手数料、満足度、ＮＰＳ、成約率、提案数、成約リードタイム、及び売れ筋等の指標を参照することが可能である。これらの指標は、行員別、エリア別、商材別に算出した値を参照することも可能である。メニュー２はビジネスマッチングの傾向分析、予測を提供するメニューである。ビジネスマッチングの傾向は、閲覧履歴から、成約した案件に多く引用されている事例の傾向等を分析する。予測機能は実施の形態３で述べた判定モデル１６を用いた顧客企業の問題・課題の予測である。メニュー３はビジネスマッチング商品を追加する機能を提供するメニューである。当該機能は、実施の形態５で述べた商材の利用登録機能である。メニュー４はビジネスマッチングの案件管理機能である。当該機能は、企業ユーザ向けの管理画面ｄ０９のメニュー１で提供する機能と同様である。戻るボタンｄ１０２はホーム画面等に戻るためのボタンである。

図４９Ａは業者ユーザ向けの管理画面の例を示す。管理画面ｄ１１はメニュー一覧ｄ１１１及び戻るボタンｄ１１２を含む。メニュー一覧ｄ１１１に含むメニューは例えば、メニュー１「ビジネスマッチング実績集計、レポート作成」、メニュー２「ビジネスマッチングの傾向分析、予測」、メニュー３「ビジネスマッチング商品の編集」、メニュー４「キャンペーン管理」、メニュー５「ビジネスマッチングの案件管理」、メニュー６「事例管理」である。メニュー１及びメニュー２で提供する機能は、銀行ユーザ向けの管理画面ｄ１０のメニュー１及びメニュー２で提案される機能と同様である。メニュー３は提供している商品の情報を編集する機能を提供する。メニュー４はコンサルティングや商品の販促などのキャンペーン情報の追加、編集等の機能を提供する。メニュー５で提供する機能は、銀行ユーザ向けの管理画面ｄ１０のメニュー４で提供する機能と同様である。メニュー６は業者が過去に担当した案件を事例として登録したり、登録した事例を修正したりする機能を提供する。戻るボタンｄ１１２はホーム画面等に戻るためのボタンである。

図４９Ｂは提供システム１００の運用者向けの管理画面の例を示す。管理画面ｄ１２はメニュー一覧ｄ１２１及び戻るボタンｄ１２２を含む。メニュー一覧ｄ１２１に含むメニューは例えば、メニュー１「ビジネスマッチング実績集計、レポート作成」、メニュー２「ビジネスマッチングの傾向分析、予測」、メニュー３「事例管理」、メニュー４「商品管理」である。メニュー１、メニュー２及びメニュー３で提供する機能は、業者ユーザ向けの管理画面ｄ１１のメニュー１、メニュー２及びメニュー６で提供する機能と同様である。戻るボタンｄ１２２はホーム画面等に戻るためのボタンである。なお、企業ユーザ、銀行ユーザ、業者ユーザ、運用者により、参照及び変更するデータの範囲は異なる。そのため、同様な機能であっても、各ユーザが扱えるデータの範囲は異なる。

（実施の形態８）
本実施の形態は教育機能に関する。提供システム１００を用いることにより、銀行ユーザや業者ユーザは顧客企業の問題・課題を予測し、当該問題・課題を解決した過去の事例を含む提案書を作成することが可能である。しかし、提案活動にはプレゼンテーションが必要なことが多い。プレゼンテーションの技能は、経験の蓄積により向上する。しかし、効果的なプレゼンテーションの例を見て学ぶことから、ある程度の技能向上は期待される。本実施の形態は、プレゼンテーションの技能向上を目指した教育機能に関する。より具体手には優秀な営業員のプレゼンテーションの内容が分かるシナリオを提供する。営業員とは銀行ユーザ又は業者ユーザであり、顧客企業においてプレゼンテーションを行う者である。

本実施の形態において、システムの全体構成は実施の形態１等と同様であるが、動画コンテンツを作成する際に、営業員が使用するユーザ端末２又は業者端末３に求められる構成が異なる。以下、営業員が使用するユーザ端末２又は業者端末３を営業員端末と呼ぶ。営業員端末はカメラやマイクを備えており、営業員がプレゼンテーションしている様子を動画として記憶可能としてある。それと同時に、プレゼンテーションで使用したスライド又はスライドを表示した画面を画像として時間データと対応付けて記憶することが可能である。

図５０はシナリオＤＢの例を示す説明図である。シナリオＤＢ１３Ｉは、過去に営業員が行ったプレゼンテーションについてのシナリオを記憶する。シナリオＤＢ１３Ｉは提供サーバ１の補助記憶部１３等に記憶する。シナリオＤＢ１３ＩはシナリオＩＤ列、ユーザＩＤ列、ケースＩＤ列、顧客企業ＩＤ列、番号列、配分列、利用画面列、トーク列及び音声列を含む。シナリオＩＤ列はシナリオを一意に特定可能なシナリオＩＤを記憶する。ユーザＩＤ列はプレゼンテーションを行ったユーザのユーザＩＤを記憶する。ケースＩＤ列はプレゼンテーションに対応するケースがある場合に当該ケースのケースＩＤを記憶する。顧客企業ＩＤ列はプレゼンテーションの対象となった顧客企業の企業ＩＤを記憶する。番号列はプレゼンテーションの場面を示す順番号を記憶する。配分列は各場面の所要時間を記憶する。利用画面列はプレゼンテーションに使用されたスライド画像を記憶する。利用画面列は画像データを保存するのではなく、画像データを記憶した画像ファイルのファイル名を記憶してもよい。トーク列はプレゼンテーションにおける営業員の音声をテキストに起こしたものを記憶する。音声列はプレゼンテーションにおける営業員の音声を記憶する。音声列は音声データを保存するのではなく、音声データを記憶した音声ファイルのファイル名を記憶してもよい。

図５１は共有設定ＤＢの例を示す説明図である。共有設定ＤＢ１３ＪはシナリオＤＢ１３Ｉに記憶しているシナリオの共有範囲、シナリオを参照できるユーザの条件を記憶する。共有設定ＤＢ１３Ｊは提供サーバ１の補助記憶部１３等に記憶する。共有設定ＤＢ１３ＪはシナリオＩＤ列、企業ＩＤ列、エリア列、支店列及びユーザＩＤ列を記憶する。シナリオＩＤ列はシナリオＩＤを記憶する。企業ＩＤ列はシナリオが参照可能な企業の企業ＩＤを記憶する。エリア列はシナリオが参照可能なエリアを記憶する。支店列はシナリオが参照可能な支店を記憶する。ユーザＩＤ列はシナリオが参照可能なユーザを記憶する。

共有設定ＤＢ１３Ｊの値設定は例えば次のように行う。所定企業の所属する全てのユーザがシナリオを参照可能とする場合、企業ＩＤ列の値を設定し、エリア列、支店列及びユーザＩＤ列には値を設定しない。所定企業の所定エリアに所在する支店所属のユーザがシナリオを参照可能とする場合、企業ＩＤ列及びエリア列の値を設定し、支店列及びユーザＩＤ列には値を設定しない。所定企業の所定の支店所属のユーザがシナリオを参照可能とする場合、企業ＩＤ列及び支店列の値を設定し、エリア列及びユーザＩＤ列には値を設定しない。所定企業の所定のユーザがシナリオを参照可能とする場合、企業ＩＤ列及びユーザＩＤ列の値を設定し、エリア列、支店列及びユーザＩＤ列には値を設定しない。

図５２はシナリオ表示画面の例を示す説明図である。シナリオ表示画面ｄ１３はシナリオＤＢ１３Ｉに記憶しているシナリオを表示する。シナリオ表示画面ｄ１３は時間配分領域ｄ１３１、画面表示領域ｄ１３２、テキスト表示領域ｄ１３３、音声提供領域ｄ１３４及び戻るボタンｄ１３５を含む。時間配分領域ｄ１３１は各場面における所要時間を表示する。画面表示領域ｄ１３２は各シーンで表示された画面を表示する。テキスト表示領域ｄ１３３は各シーンで営業員が話したことをテキスト化したものを表示する。音声提供領域ｄ１３４は各シーンで営業員が話した音声を提供する。各シーンに表示されているボタンを選択すると音声の再生が開始する。戻るボタンｄ１３５はホーム画面等に戻るためのボタンである。

本実施の形態においては、経験の浅い営業員に、効果的なプレゼンテーションの例を視聴できる動画シナリオを提供することで、プレゼンテーション技能の向上を図ることが可能となる。

以上の実施の形態に関して補足する。ユーザは主として金融機関の職員であると述べた。金融機関の職員以外でユーザとして、個人事業主や法人が相談相手として接する可能性がある士業従事者、コンサルタント、営業マン、保険外交員、又は投資関係者が想定される。士業従事者は公認会計士、行政書士、社会保険労務士、又は中小企業診断士等である。コンサルタントは経営コンサルタント、労働安全コンサルタント、又はビジネスコンサルタント等である。投資関係者は、ハンズオン型ベンチャーキャピタルのファンドマネージャーや、投資ファンドのバリューアップ担当者である。ユーザとして、金融機関の職員以外の者を受け入れる実装においては、ユーザ企業ＤＢ１３２に業種を記憶する列が追加される。また、金融機関以外のユーザ企業については、金融機関コード列は値なしか空白となる。

提供システム１００へアクセスする者として、ユーザ、業者、顧客（エンドユーザ）を示したが、それ以外に提供システム１００の運営者が、提供システム１００へアクセス可能である。運営者は、ユーザ、業者、顧客と異なる立場から、各者の業務支援やコミュニケーションのサポート等を行い、又、提供システム１００の機能改善や利便性向上等を検討する。

図２０のステップＳ１６において、マッチング依頼を業者端末３へ送信するとしたが、それに限らない。提供サーバ１の制御部１１は、マッチング依頼を運営者の端末へ送信し、運営者が業者宛に転送、又は、改めてマッチング依頼送信の指示を制御部１１に行ってもよい。運営者から業者へ電話・ＦＡＸで連絡をしてもよい。ユーザ又は顧客の求めに応じて、マッチング依頼の送信先として、業者及び運営者以外の者を設定可能としてもよい。例えば、ユーザが所属する銀行の本部である。また顧客企業を含めてもよい。さらに、マッチング依頼の送信は１者のみに限らず、業者と運営者との２者へ、業者と運営者と業者及び運営者以外の者との３者へ送信してもよい。送信先等は後述する事例属性ＤＢ１３Ｋに記憶する。

実施の形態６において、企業ユーザの閲覧履歴に基づき、事例毎にスコア算出し、算出したスコアが閾値を超えている場合、当該企業を担当するユーザに通知するとしたが、それに限らない。通知先に運営者、ユーザが所属する企業の本部にも通知してもよい。通知先は、ユーザ、運営者、本部から選択した１者又は２者でもよい。これらの設定は、事例属性ＤＢ１３Ｋの送信先列と同様な項目列を、ユーザ企業ＤＢ１３２に設けて設定する。

事例によっては、商材が複数であり、複数の業者が関わったケースがある。このような事例においては、各業者の役割や立場が一律ではない場合もある。そのため、マッチング依頼を関わった業者のうち、特定の業者へのみ送信すべきケースもありうる。そのため、事例毎にマッチング依頼の送信方法が設定できることが望ましい。

実施の形態４において、制御部１１は提案書作成する際、ユーザ企業毎に用意された提案書のフォーマットを用いて、提案書を作成すること、当該フォーマットにはユーザ企業のロゴ４０２が含まれていることを説明した。当該フォーマットには、使用する書体、文字サイズ、文字色の情報を含んでよい。ロゴ４０２については、カラーのものと白黒のものとを用意し、カラー印刷及び白黒印刷に対応可能であることが望ましい。

提供システム１００においては、事例の活用と新たな事例データの収集が重要な点の１つである。その実現のためには、事例に種々の属性の付与することが望ましい。そこで、事例の属性を記憶する属性データベースを設ける。図５３は事例属性ＤＢの例を示す説明図である。事例属性ＤＢ１３ＫはケースＩＤ列、業種列、所在地列、売上規模列、従業員数列、創業年数列、業績傾向列、営業エリア列、検索ヒット列、参照列、ブックマーク列、依頼列、成約列、転換率１列、転換率２列、転換率３列、ユーザ列、補助金列、助成金列及び送信先列を含む。業種列から業績傾向列は事例と対応付いている企業について、典型課題ＤＢ１３５の同名の列と同様の値を記憶する。営業エリア列は企業の営業エリアを記憶する。ここまでの列の値は事例となる問題・課題の解決に着手する前の値とする。検索ヒット列は事例が検索にヒットした回数（検索ヒット回数）を記憶する。参照列は詳細内容が参照された回数（参照回数）を記憶する。ブックマーク列はユーザによりブックマーク登録された回数（ブックマーク登録数）を記憶する。依頼列はマッチング依頼に至った回数（依頼回数）を記憶する。成約列は事例に基づきエンドユーザが業者との契約に至った回数（成約数）を記憶する。転換率１列、転換率２列及び転換率３列は転換率を記憶する。転換率はコンバージョン率、変換率ともいう。本明細書では転換率として３つの値を扱う。転換率１列、転換率２列及び転換率３はそれぞれ次に定義する転換率１、転換率２、転換率３の値を記憶する。転換率１はマッチング依頼数÷参照回数である。転換率２は成約数÷参照回数である。転換率３は参照回数÷検索ヒット数である。転換率はこれらの定義に限らず他の定義でもよい。ユーザ列はユーザ、顧客ユーザから寄せられた評価を点数として表した数値（ユーザ評価点）を記憶する。補助金列は事例に対応付く商材を購入する場合に、補助金が使えるか否かを記憶する。助成金列は事例に対応付く商材を購入する場合に、助成金が使えるか否かを記憶する。補助金、助成金が使える場合、補助金列、助成金列それぞれは補助金、助成金の識別情報を記憶する。送信先列はマッチング依頼の送信先についての設定を記憶する。送信先列は運営者列、業者列及びその他列を記憶する。運営者列はマッチング依頼を運営者へ送信するか否かを記憶する。運営者へ送信する場合、運営者列は○を記憶する。運営者へ送信しない場合、運営者列は×を記憶する。業者列は業者へ送信するか否かを記憶する。業者へ送信しない場合、業者列は×を記憶する。事例に関係する全ての業者へ送信する場合、業者列は○を記憶する。事例に関係する全ての業者の中でもっと重要な役割を果たした業者のみへ送信する場合、業者列は筆頭を記憶する。なお、事例ＤＢ１３７の業者ＩＤ列において、重要な役割を果たした業者の業者ＩＤが筆頭に記憶されている、又は業者ＩＤに果たした役割の重要度を示す値が付されているものとする。その他列は運営者及び業者以外へ送信する場合に送信先を記憶する。ユーザが属する企業の本部へ送信する場合、その他列は本部を記憶する。本部のメールアドレスはユーザ企業ＤＢ１３２に記憶する参照したユーザに関わらず固定した先に送信する場合、その他列は送信先のメールアドレスを記憶する。

事例属性ＤＢ１３Ｋは、検索ヒット列から転換率３列の値については、随時更新を行う。また、検索ヒット列から転換率３列の値は、期間を限り、例えば直近３ヶ月に限り、算出することとし、期間をおいて更新してもよい。補助金列、助成金列についても、随時更新を行うことが望ましい。なお、事例属性ＤＢ１３Ｋが記憶する属性の一部又は全てを事例ＤＢ１３７に記憶するようにしてもよい。また、事例属性ＤＢ１３Ｋが記憶する属性を複数のグループに分割し、グループ毎にデータベースを設けてもよい。事例属性は事例の検索方法や、連携するシステムにより必要なものが異なるため、データベースを分割すると処理効率が上がる場合がある。また、事例属性は変更されない静的データと、随時変更される動的データとを含むので、この観点で分割してもよい。検索ヒット数列から転換列３列に記憶する値は、ユーザ企業毎に集計してもよい。この場合、ユーザ企業毎の集計値は、事例属性ＤＢ１３Ｋとは別に、ユーザ企業毎に設けたデータベースに記憶してもよい。

（実施の形態９）
本実施の形態は、事例の表示件数を絞り込む形態に関する。図２０のステップＳ９の説明において、問題・課題に対応付けられた事例が一覧表示されるとしたが、一覧ではなく１つの事例のみを表示してもよい。検索にヒットした事例が複数の場合でも、その中から１つを選択して表示してもよい。例えば、事例属性ＤＢ１３Ｋの検索ヒット列からユーザ列までの値に基づき、事例毎の評価点を算出し、制御部１１は最も評価点が大きいものを選択する。また、制御部１１は検索にヒットした事例が３つ以下の場合は、すべて表示し、３を超える場合には評価点の大きいものから３つ事例をユーザ端末２に表示させてもよい。なお、３という閾値は５、８等でもよい。または、カールセルを用いて、選択した複数の事例を順番に１つずつ表示してもよい。複数の事例を一覧表示する際に、評価値の降順にソートを行い、評価値が大きいものから表示するようにしてもよい。評価値は検索ヒット列からユーザ列までの値を全て参照して求めるだけでなく、一部の値を用いてもよい。さらに、評価値を算出する際に用いる値を、ユーザ毎、ユーザ企業毎に設定可能としてもよい。

また、事例を表示する場合において、次のような情報を合わせて表示してもよい。制御部１１は商材実績ＤＢ１３Ａに基づき、事例に対応付けられた商材の情報、例えば商材詳細画面ｄ０８（図４４）に示した情報をユーザ端末２に表示させユーザ端末２に表示させる。また、制御部１１は、事例に関わった業者や商材についての顧客の口コミ情報をユーザ端末２に表示させてもよい。制御部１１は、例えば実施の形態７で示したアンケート処理（図４７）において、業者や商材についての評価や感想（口コミ）を自由記述のテキストとして収集し、業者に関する評価は業者ＤＢ１３Ｆに、商材についての評価は商材評価ＤＢ１３Ｂに記憶する。制御部１１は、事例ＤＢ１３７に記憶してある業者ＩＤを用いて、業者ＤＢ１３Ｆを検索し、事例に関わった業者の口コミ情報を取得し、商材実績ＤＢ１３Ａに基づき、事例に対応付けられた商材の口コミ情報を取得し、ユーザ端末２に表示させる。

顧客が利用可能性のある助成金・補助金の情報を表示してもよい。助成金、補助金ともに返還不要で交付される資金である。助成金は原則通年を通して申請可能で、条件に合致していれば、ほぼ採択される。一方、補助金は、助成金よりも種類が豊富、支給額が助成金に比べて大きい場合が多い、経費の適用範囲が広いものの、公募期間が短く年に数回のみという場合が多く、採択されるのが難しいと違いがある。図５４は助成金・補助金ＤＢの例を示す説明である。助成金・補助金ＤＢ１３ＬはＩＤ列、区別列、名前列、条件１列、条件２列、条件３列、条件４列、及び条件５列を含む。ＩＤ列は助成金及び補助金を一意に特定可能なＩＤを記憶する。区別列は助成金であるか、補助金であるかの区別を記憶する。助成金の場合、区別列は助成金と記憶する。補助金の場合、区別列は補助金と記憶する。名前列は助成金又は補助金の名前を記憶する。条件１列から条件５列は助成金又は補助金を受けるための条件を記憶する。助成金又は補助金を受けるための条件が５個もない場合、条件５列等は空白又は未設定を示す「−」などを記憶する。条件列の数は１から４個でもよいし、６個以上でもよい。図５４において、条件１列から条件５列で示す条件（ただし、空白、未設定は除く）をすべて満たす場合に、助成金又は補助金を受けられる条件を満たすと判定する。ただし、条件１列から条件５列の値で「＋」は、「＋」が付加されている複数の条件のいずれか１つを満たした場合に、条件を満たすと判定する。図５３において、ＩＤ＝Ａ１の６５歳超雇用推進助成金は、中小企業であって、高齢者雇用を行っている企業が対象となる。条件２は全国であるので、日本で営業していれば対象となる。助成金・補助金ＤＢ１３Ｌは運営者が構築する他、補助金申請や事業支援のサポートを目的としたＷｅｂサイトと連携して、データをインポートしてもよい。

事例とともに助成金・補助金の情報を表示する際には、提供サーバ１の制御部１１は、助成金・補助金ＤＢ１３Ｌの条件１列から条件５列に記憶されている条件を顧客が満たす否かを判断するための情報を、対象企業ＤＢ１３３から取得する。対象企業ＤＢ１３３に記憶されていない情報は、例えば顧客のＩＲ情報サイト、ＥＤＩＮＥＴ（Electric Disclosure for Investors’ Network）で公開されている有価証券報告書、信用調査会社のデータベースから、制御部１１は必要な情報を取得する。制御部１１は取得した情報と助成金・補助金ＤＢ１３Ｌの条件１列から条件５列に記憶されている条件とを対照し、顧客が条件を満たすか否かを判定する。制御部１１は条件を満たす助成金・補助金の情報をユーザ端末２に表示させる。助成金・補助金の情報を、助成金・補助金の情報を発信しているＷｅｂサイトから取得してもよい。

さらに、選択した事例とともに、ホットな事例、関連事例を表示してもよい。ホット事例とは、全ての事例の中で、直近（例えば直近３ヶ月）に参照回数が最も多い事例や、顧客と業者との成約のきっかけとなった回数が多い事例等である。当該回数は、依頼ＤＢ１３８の選択事例列に記憶されたケースＩＤを数える上げることで求めることが可能である。関連事例は、特定された問題・課題と同じテーマに含まれる別の問題・課題に対応付けられた事例である。制御部１１は課題類型ＤＢ１３４及び事例ＤＢ１３７を参照して、関連事例を選択し、ユーザ端末２に表示させる。関連事例は、選択した事例に対応付けられた業者が手掛けた他の事例であって、最もホットな事例としてもよい。

さらに、ユーザと類似する他のユーザが参照した事例を表示してもよい。ユーザ間の類似度はユーザＤＢ１３１、ユーザ企業ＤＢ１３２に記憶しているユーザ属性、ユーザ企業の属性から判定する。ユーザＤＢ１３１にユーザの性別、年齢、職種、勤務場所、担当エリアを記憶する列を追加し、類似度を判定する際にこれらのデータを用いてもよい。提供システム１００でのユーザの行動履歴から類似度を判定してもよい。行動履歴による類似度の判定は、例えば、閲覧履歴ＤＢ１３Ｄ、ブックマークＤＢ１３Ｅに記憶されたデータから行う。

ユーザ間の類似度を算出するのではなく、ユーザ属性、ユーザ企業の属性やユーザの行動履歴により、ユーザを類型化しておき、同じ類型に属する他のユーザ参照した事例を表示してもよい。例えば、ＭＺ銀行のユーザＡは、東京勤務、類型Ａタイプであり、Ａという事例を参照していた場合、ＲＳ銀行のユーザであって、東京勤務、類型ＡタイプのユーザＢに対して、Ａという事例をおすすめ事例として表示する。

本実施の形態においては、１つの事例を表示することにより、ユーザは事例に基づくマッチング依頼を行うか否かを十分に検討することが可能となる。また、選択肢は多くとも少なくともユーザが判断する可能性があることを考慮して３つの事例を表示することにより、ユーザは迷いなく事例を選択することが可能となる。

事例と共に事例と結びつく商材の情報を表示することにより、問題・課題を解決するための工程、作業等を具体的に思い描くことが可能となる。また、口コミ情報を表示することにより、業者や商材の評価を具体的に把握でき、選択した事例に基づきマッチング依頼を行うか否かの判断の一助となる。

顧客が利用可能性のある補助金・助成金を示すことで、問題・課題を解決するために要する資金の調達見込みを立てることが可能となる。ホットな事例、関連事例を表示することより、特定された問題・課題以外に顧客が抱えている問題・課題に、ユーザが気付く可能性がある。

本実施の形態において、事例を１つ表示する場合、事例一覧画面ｄ０３の表示は省略し、事例詳細画面ｄ０４をユーザ端末２に表示させてもよい。

（変形例１）
本変形例は実施の形態１に関連する。実施の形態１において、ユーザは顧客企業が抱えていると予想される問題・課題を、提供システム１００から得るためには顧客企業の情報の入力が必要である。入力項目は、必須項目として業種及び売上規模、任意項目として、所在地、従業員数、創業年数、業績傾向等である。本変形例では、これらの項目の入力を省略可能する。すなわち、ユーザは顧客企業の識別情報を入力するだけで、抱えていると予想される問題・課題を得ることが可能となる。識別情報は会社名、証券コード協議会が付与する証券コード（登録商標）、国税庁が付与する法人番号、信用調査会社が付与する企業コード等である。

本変形例では、ユーザはコンサルティングを予定している顧客企業の識別情報をユーザ端末２に入力する。ユーザ端末２の制御部２１は識別情報を取得し、提供サーバ１へ送信する。提供サーバ１の制御部１１は受信した識別情報を元に、企業情報ベンダや信用調査会社が提供する企業情報データベースを検索し、業種、売上規模、所在地、従業員数、創業年数、業績傾向等の企業情報を取得する。この際、図２０のステップＳ２の実行時と同様に、制御部１１は新たなケースＩＤを発番し、当該ケースＩＤと受信した企業情報とを対応付けて、対象企業ＤＢ１３３に記憶する。制御部１１はステップＳ３以降を実行する。なお、企業情報ベンダはデータマイニングにより企業情報データベースを構築し、提供する企業である。企業情報ベンダは、有価証券報告書、電話帳データ、ホームページ、地図情報、法人番号公表サイト、新聞・官報、名刺情報等から企業情報を多数収集し、名寄せやデータクレンジング等の処理を行い、企業情報データベースを構築・更新している。信用調査会社が調査員による調査を重視しているのに対して、企業情報ベンダは調査員による調査はそれ程、重視していないという違いがある。なお、顧客企業の識別情報として、会社名を入力する際、ユーザが会社名の一部を入力した時点で、企業情報データベースを検索し、検索結果に基づいて会社名を表示したとき、複数の会社がヒットしたときは、プルダウンメニューにより選択可能としてもよい。

本変形例では、ユーザは会社名等の識別情報を入力するだけで、他の情報を入力しなくても、顧客企業が抱えていると予想される問題・課題を、提供システム１００から得ることが可能となる。それにより、コンサルティング業務の初心者等で企業情報の収集が不慣れのユーザであっても、顧客企業に対して精度の良い改善提案を行うことが可能となる。

さらに、問題・課題の選択をユーザが不要としてもよい。課題類型ＤＢ１３４又は典型課題ＤＢ１３５において、順位列を設け、課題毎に重要性などに基づく順位を付与する。制御部１１は、典型課題ＤＢ１３５を参照し、企業情報から問題・課題を複数取得した場合、順位に基づき、１つの問題・課題を選択する。制御部１１は、選択した問題・課題と対応した事例を事例ＤＢ１３７から取得し、ユーザ端末２に表示する。この際、実施の形態９と同様に、表示する事例を１つにしてもよい。問題・課題の選択を不要とし、表示する事例を１つすることにより、不慣れなユーザであっても、さらに容易に改善提案を行うことが可能となる。また、課題判定ＤＢ１３Ｇを参照せず、顧客企業の企業属性情報と事例属性ＤＢ１３Ｋとを対照し、表示する事例を選択することにより、問題・課題の選択を不要としてもよい。

なお、問題・課題の選択をユーザが不要とする機能を、実施の形態１又２に組み込んでもよい。

（変形例２）
本変形例は実施の形態２に関連する。実施の形態２では他システムから顧客企業毎のデータを取得して、顧客企業が抱えていると予想される問題・課題を判定している。本変形例では、顧客企業毎のミクロデータではなく、業界動向といったマクロデータから、問題・課題を判定する。

本変形例において、ユーザは問題・課題を特定したい顧客企業の業種、営業エリア等の企業属性情報を、ユーザ端末２を介して提供サーバ１へ送信する。制御部１１は他システムから企業属性情報に基づいて、マクロデータを外部データベースから取得する。外部データベースは、シンクタンク、信用調査会社、企業情報ベンダが提供するデータベース等である。取得するマクロデータは業界動向、市場動向、消費トレンド等である。これらのマクロデータはシンクタンクのアナリストが分析したもの、信用調査会社の調査員が調査したデータに基づくものや、企業情報ベンダがデータマイニングにより得たデータである。企業情報ベンダは、過去の経済ニュースや決算情報（上場企業の決算短信や有価証券報告書）と、過去の経済事象、業界動向、市場動向、消費トレンド等とを収集し、それらの関連性を分析している。分析結果に基づき、最新の経済ニュースや決算情報より、特定又は予測される業界動向、市場動向、消費トレンドを提供している。制御部１１は取得したマクロデータと、図３６に示した課題判定ＤＢ１３Ｇの傾向列の値とを参照して、問題・課題を特定する。例えば、顧客企業が飲食業であって、取得したマクロデータとして、「飲食業の先月売上は前月比１０％減」を得た場合、制御部１１は課題を「売上減少」と特定する。その後、制御部１１は図３５のステップＳ５５を実行する。

本変形例において、課題判定ＤＢ１３Ｇは図３６に示したものではなく、マクロデータと問題・課題とを対応付けたものでもよい。本変形例においても、問題・課題の選択を不要としよいし、表示する事例を１つとしてもよい。

本変形例では、ユーザは会社名等の識別情報を入力するだけで、他の情報を入力しなくても、顧客企業が抱えていると予想される問題・課題を、提供システム１００から得ることが可能となる。実施の形態２と異なり、他システムからミクロデータを取得できない企業であっても、改善提案を行うことが可能となる。

なお、課題判定ＤＢ１３Ｇを参照せず、マクロデータと事例属性ＤＢ１３Ｋとを対照し、表示する事例を選択してもよい。また、変形例１と変形例２とを組み合わせてもよい。それにより、顧客企業が抱えている問題・課題をより精度よく判定することが可能となる。

（実施の形態１０）
本実施の形態は、他システムとの連携機能に関する。他システムとは、ＳＦＡシステム（営業管理システム）、ＣＲＭシステム（顧客管理システム）、会計システム、勤怠システム、ＰＯＳシステム、経営計画作成システム等である。連携機能は、これら他システムの表示画面の一部に、提供システム１００の表示領域を設け、当該表示領域に、他システムで選択されている企業が抱えていると予想される問題・課題や、それらを解決した事例を表示する機能である。なお、本実施の形態において、ユーザとは他システムのユーザである。

図５５は連携処理の手順例を示すフローチャートである。連携処理では、ユーザは他システムへ既にログインしているものとする。ユーザは表示する企業を選択する。ユーザ端末は選択情報を取得する（ステップＳ１７１）。ユーザ端末２は選択情報を他システムへ送信する（ステップＳ１７２）。他システムは選択情報を受信する（ステップＳ１７３）。他システムは選択情報を基に、選択された企業の情報を取得する（ステップＳ１７４）。他システムは企業の情報を含むリクエストを提供サーバ１へ送信する（ステップＳ１７５）。提供サーバ１の制御部１１はリクエストを受信する（ステップＳ１７６）。制御部１１はリクエストに含まれる企業の情報を取得する（ステップＳ１７７）。制御部１１は取得した情報から、問題・課題を特定する（ステップＳ１７８）。制御部１１は事例を取得するか否かを判定する（ステップＳ１７９）。返信する結果を問題・課題とするか、事例とするかについては、リクエストに含まれている。または、他システム毎に予め定めておいてもよい。制御部１１は事例を取得しないと判定した場合（ステップＳ１７９でＮＯ）、処理をステップＳ１８１へ移す。制御部１１は事例を取得すると判定した場合（ステップＳ１７９でＹＥＳ）、事例を検索する（ステップＳ１８０）。事例を検索する処理については上述した処理と同様である。制御部１１は問題・課題又は事例を結果として他システムへ送信する（ステップＳ１８１）。他システムは結果を受信する（ステップＳ１８２）。他システム受信した結果を埋め込んだ画面を生成し、ユーザ端末へ送信する（ステップＳ１８３）。ユーザ端末は画面を受信、表示し（ステップＳ１８４）処理を終了する。

図５６は他システムの画面例を示す説明図である。図５６は他システムとしてＳＦＡシステム又はＣＲＭシステムを想定した顧客情報画面である。顧客情報画面ｄ３０は企業名ｄ３０１、企業コードｄ３０２、業種ｄ３０３、接触履歴ｄ３０４、ニーズｄ３０５、メモｄ３０６及び連携情報表示領域ｄ３０７を含む。企業名ｄ３０１は他システムで選択されている企業の名称を表示する。企業コードｄ３０２は当該企業の企業コードを表示する。業種ｄ３０３は当該企業の業種を表示する。接触履歴ｄ３０４、ニーズｄ３０５、メモｄ３０６は、他システムが記憶している当該企業との接触履歴、当該企業のニーズ、当該企業に関するメモをそれぞれ表示する。連携情報表示領域ｄ３０７は、提供サーバ１から取得した情報を表示する。図５６では、連携情報表示領域ｄ３０７には、問題・課題が表示されている。連携情報表示領域ｄ３０７は問題・課題ｄ３０７１及び実行ボタンｄ３０７２を含む。問題・課題ｄ３０７１の１つを選択し、実行ボタンｄ３０７２を選択すると、選択された問題・課題ｄ３０７１に対応する事例が、連携情報表示領域ｄ３０７に表示される。なお、実行ボタンｄ３０７２を選択すると、提供システム１００用の新たな画面が表示され、当該画面に事例を表示してもよい。

ＳＦＡシステム又はＣＲＭシステムにおいては、企業の情報として、業種、営業エリア、従業員数、売上規模、業績情報等の営業情報又は顧客情報を保有しているから、これらの情報をリクエストと共に提供サーバ１へ送信する。提供サーバ１はこれらの情報に基づいて、企業の問題・課題、企業に関連する事例を特定する。なお、企業の情報として、ユーザのメモや日報等のテキストデータを含めてよい。制御部１１は受信したテキストデータから、テキストマイニングにより、企業の問題・課題を示すキーワードを取得し、取得したキーワードを用いて、問題・課題を特定する。

図５７は他システムの画面例を示す説明図である。図５７は他システムとして会計システムを想定した月次推移画面である。月次推移画面ｄ３１は企業名ｄ３１１、企業コードｄ３１２、業種ｄ３１３、売上推移ｄ３１４、利益推移ｄ３１５、短信ｄ３１６及び連携情報表示領域ｄ３１７を含む。企業名ｄ３１１は他システムで選択されている企業の名称を表示する。企業コードｄ３１２は当該企業の企業コードを表示する。業種ｄ３１３は当該企業の業種を表示する。売上推移ｄ３１４、利益推移ｄ３１５、短信ｄ３１６は、他システムが記憶している当該企業の売上推移、利益推移、当該企業に関する短信をそれぞれ表示する。連携情報表示領域ｄ３１７は、提供サーバ１から取得した情報を表示する。図５７では、連携情報表示領域ｄ３１７には、事例が表示されている。連携情報表示領域ｄ３１７は事例概要ｄ３１７１及び詳細ボタンｄ３１７２を含む。事例概要ｄ３１７１は選択された事例の概要を表示する。詳細ボタンｄ３１７２を選択すると、表示されている事例の詳細な内容が、連携情報表示領域ｄ３１７に表示される。なお、詳細ボタンｄ３１７２を選択すると、提供システム１００用の新たな画面が表示され、当該画面に事例の詳細を表示してもよい。

会計システムにおいては、図５７に示したように、企業の情報として、売上推移や利益推移を保有しているから、これらの情報をリクエストと共に提供サーバ１へ送信する。提供サーバ１はこれらの情報に基づいて、売上傾向、利益傾向を判定し、それに基づいて、問題・課題又は事例を特定する。なお、企業の情報として、短信等のテキストデータを含めてよい。制御部１１は受信したテキストデータから、テキストマイニングにより、企業の業績動向等を示すキーワードを取得し、取得したキーワードを用いて、問題・課題又は事例を特定する。

他システムが勤怠システムであれば、勤怠システムから得られる情報から、残業時間を減らす、離職率を下げる、人員を補充するなどの問題・課題を特定することが可能である。他システムがＰＯＳシステムであれば、売上傾向、商品ラインナップ、サービスメニューに関する問題・課題を特定することが可能である。他システムが経営計画作成システムであれば、原価削減、売上増などの問題・課題を経営計画情報から特定することが可能である。

本実施の形態においては、種々の業務システムと連携することにより、様々な視点から問題・課題を見出し、事例を基に問題・課題を解決することが可能となる。コンサルタントは顧客企業に対して、利用している業務システムと提供システム１００との連携を依頼することにより、提供システム１００を利用したコンサルティングが可能となる。それによって、顧客企業の業務システムが保持しているデータを一括で受け取って分析する作業が不要となるので、問題・課題の発見、それらの解決に要する時間を短縮することが可能となる。

（実施の形態１１）
本実施の形態は上述の実施の形態、変形例を組み合わせ、会社名から事例を得られる形態に関する。図５８及び図５９は事例表示処理の手順例を示すフローチャートである。ユーザはユーザ端末２の会社名入力画面で会社名の一部や略称（以下、「名称」という）を入力する。ユーザ端末２は取得した名称を提供サーバ１へ送信する。提供サーバ１の制御部１１は名称を取得する（ステップＳ１９１）。制御部１１は名称を検索キーにして、対象企業ＤＢ１３３や外部の企業情報データベースを検索する（ステップＳ１９２）。制御部１１は検索がヒットしたか否かを判定する（ステップＳ１９３）。制御部１１は検索がヒットしなかったと判定した場合（ステップＳ１９３でＮＯ）、処理をステップＳ１９１へ戻す。制御部１１は検索がヒットしたと判定した場合（ステップＳ１９３でＹＥＳ）、検索結果に基づき、企業の選択メニューを送信する（ステップＳ１９４）。ユーザ端末２では例えばプルダウンメニューが表示される。メニューは会社名に加えて、同名の会社が区別可能なように所在地を表示してもよい。ユーザはメニューから一社を選択する。ユーザ端末２は選択情報を提供サーバ１へ送信する。提供サーバ１の制御部１１は選択情報を取得する（ステップＳ１９５）。制御部１１は選択された企業の静的データを企業情報データベースから取得する（ステップＳ１９６）。静的データは、例えば、業種、所在地、売上規模、従業員数、創業年数等である。制御部１１は取得した静的データと、典型課題ＤＢ１３５を参照し、問題・課題を特定する（ステップＳ１９７）。制御部１１は選択された企業の定性データ・定量データの取得を試みる（ステップＳ１９８）。定性データ・定量データは実施の形態３で説明したものである。制御部１１は定性データ・定量データの取得が取得できたか否かを判定する（ステップＳ１９９）。制御部１１は定性データ・定量データの取得が取得できなかったと判定した場合（ステップＳ１９９でＮＯ）、処理をステップＳ２０１へ移す。制御部１１は定性データ・定量データの取得が取得できたと判定した場合（ステップＳ１９９でＹＥＳ）、定性データ・定量データを上述の判定モデル１６に入力する。制御部１１は判定モデル１６か出力した問題・課題を取得する（ステップＳ２００）。制御部１１は選択された企業の業種、営業エリアを検索キーとして、変形例２で述べた外部データベースからマクロデータの取得を試みる（ステップＳ２０１）。制御部１１はマクロデータを取得できたか否かを判定する（ステップＳ２０２）。制御部１１はマクロデータを取得できなかったと判定した場合（ステップＳ２０２でＮＯ）、処理をステップＳ２０４へ移す。制御部１１はマクロデータを取得できたと判定した場合（ステップＳ２０２でＹＥＳ）、マクロデータから問題・課題を特定する（ステップＳ２０３）。当該処理は変形例２における処理と同様である。制御部１１はこれまでに特定又は取得した問題・課題を集約する（ステップＳ２０４）。集約とは一つにまとめる共に重複するものは一部を削除する。制御部１１は集約した問題・課題より、事例を取得する（ステップＳ２０５）。制御部１１は取得した事例を評価する（ステップＳ２０６）。事例属性ＤＢ１３Ｋに記憶された検索ヒット数などを用いて評価する。制御部１１は評価に基づき、事例を絞り込む（ステップＳ２０７）。制御部１１は絞り込んだ事例をユーザ端末２へ送信し（ステップＳ２０８）、処理を終了する。本実施の形態においても、変形例１や変形例２と同様に、問題・課題を経由せずに、ダイレクトに事例を取得する処理も行い、取得した事例をステップＳ２０４で集約する事例に含めてもよい。

本実施の形態においては、顧客企業の会社名を入力するだけで、種々な方法で事例を取得し、取得した事例を評価に基づき絞り込んだ結果を表示するので、ユーザは顧客企業へのコンサルティング時に示すべき最適な事例を得ることが可能となる。

（実施の形態１２）
本実施の形態は、問題・課題に対応する事例を表示する際に、ユーザ企業が重要視する事例を追加する形態に関する。図６０は優先表示ＤＢの例を示す説明図である。優先表示ＤＢ１３Ｍはユーザ企業が重要視する事例を記憶する。優先表示ＤＢ１３Ｍは企業ＩＤ列、ＨＰユーザ列及び優先事例列を含む。企業ＩＤ列はユーザ企業の企業ＩＤを記憶する。ＨＰユーザ列はハイパフォーマーが参照、ブックマーク登録又はマッチング依頼した事例を特定するケースＩＤを記憶する。ハイパフォーマーとは、能力が高く効率的に高い業務成績を残す社員等をいう。優先事例列は上位表示する事例のケースＩＤを記憶する。

ＨＰユーザ列に記憶する値は、例えば次のように決定する。ユーザ企業の本部等がハイパフォーマーのユーザＩＤを指定し、指定したハイパフォーマーのユーザＩＤに基づいて、閲覧履歴ＤＢ１３Ｄ、ブックマークＤＢ１３Ｅを検索した結果に基づき、決定する。

優先事例列の値は、例えば次のように決定する。ユーザ企業の本部が売上の良い商材を選択する。提供サーバ１は選択した商材に対応した商材ＩＤに基づいて、商材実績ＤＢ１３Ａを検索し、選択した商材と対応付いた事例を表示する。ユーザ企業の本部は表示された事例の中から、上位に表示すべき事例を選択する。

優先表示ＤＢ１３Ｍが記憶するデータは、次のように利用される。提供サーバ１が検索により事例を取得した後、ユーザ企業の企業ＩＤをキーに優先表示ＤＢ１３Ｍのレコードを取得する。取得したレコードのＨＰユーザ列又は優先事例列が記憶する事例ＩＤが、検索により取得した事例に含まれていたら、表示順を上位に設定し、ユーザ端末２へ送信する。

ＨＰユーザ列及び優先事例列が記憶する事例ＩＤが多数の場合、事例を検索後に、その中から、ＨＰユーザ列又は優先事例列に記憶されている事例ＩＤに対応する事例に絞り込んでもよい。

また、ＨＰユーザ列にはハイパフォーマーのユーザＩＤを記憶しておき、ハイパフォーマーに関連する事例が必要な場合に、ハイパフォーマーのユーザＩＤに基づいて、閲覧履歴ＤＢ１３Ｄ、ブックマークＤＢ１３Ｅをその都度、検索してもよい。

上述では、ハイパフォーマーの商材、上位に表示する商材については、ユーザ企業毎に管理するとしたが、複数のユーザ企業間で共有してもよい。この場合、ハイパフォーマーの設定や上位に表示する商材のデータは、運営者が設定することが望ましい。

本実施の形態においては、ハイパフォーマーが参照等をした事例をユーザに提示することで、ハイパフォーマーの経験・実績を活用可能となる。また、売上に貢献する商材に対応した事例を上位に表示することで、当該商材の販売促進を確実に行うことが可能となる。

図６１は優先表示管理画面の例を示す説明図である。優先表示管理画面ｄ２は、条件設定領域ｄ２０、条件表示領域ｄ２１、売上高表示ｄ２２、商品表示ｄ２３、事例表示ｄ２４、アクションメニューｄ２５、決定ボタンｄ２６及びキャンセルボタンｄ２７を含む。条件設定領域ｄ２０は商品（商材）を検索する条件を設定する。条件設定領域ｄ２０は期間指定ｄ２０１、エリア指定ｄ２０２及び利用者指定ｄ２０３を含む。期間指定ｄ２０１は売上を算出する期間を指定するためのボタンである。期間指定ｄ２０１を選択すると期間を指定するためのポップアップ画面が開く。エリア指定ｄ２０２は売上を算出するエリア指定するためのボタンである。エリア指定ｄ２０２を選択するとエリアを指定するためのポップアップ画面が開く。利用者指定ｄ２０３は売上を算出する対象とするユーザを指定するためのボタンである。利用者指定ｄ２０３を選択すると対象ユーザを指定するためのポップアップ画面が開く。条件表示領域ｄ２１は条件設定領域ｄ２０によって設定した条件を表示する。条件表示領域ｄ２１は期間表示ｄ２１１、エリア表示ｄ２１２及びユーザ表示ｄ２１３を含む。期間表示ｄ２１１は売上算出期間を表示する。エリア表示ｄ２１２は売上算出エリアを表示する。ユーザ表示ｄ２１３は売上算出ユーザを表示する。売上高表示ｄ２２は算出した売上を表示する。商品表示ｄ２３は各商品の売上高、販売数を表示する。商品表示ｄ２３は売上高の降順に商品を表示する。事例表示ｄ２４は成約件数の降順に事例を表示する。事例表示ｄ２４は商品と対応付けられている事例、成約件数、閲覧数、利用率を表示する。利用率はマッチング依頼数／閲覧数である。アクションメニューｄ２５は事例に対する動作を設定する。決定ボタンｄ２６を選択すると設定した内容が記憶される。キャンセルボタンｄ２７を選択すると、１つ前の画面に戻る。アクションメニューｄ２５にて「この事例を上位に」を選択し、決定ボタンｄ２６を選択すると、優先表示ＤＢ１３Ｍの優先事例列にケースＩＤが記憶される。

（実施の形態１３）
本実施の形態は提案書作成機能に関する。本実施の形態は上述した実施の形態４を変形した形態である。

図６２は書式設定ＤＢの例を示す説明図である。書式設定ＤＢ１３Ｎは、企業毎に提案書の書式設定を記憶する。書式設定ＤＢ１３Ｎは、企業ＩＤ列、テンプレート列、ロゴ列及びカラー列を含む。企業ＩＤ列は企業ＩＤを記憶する。構成列は提案書の構成を記憶する。テンプレート列は提案書のテンプレートを記憶する。テンプレート列にテンプレートファイルのファイル名を記憶する。テンプレート列にテンプレートファイルの実体を記憶してもよい。ロゴ列は企業のロゴ画像を記憶する。カラー列は企業のコーポレートカラーを記憶する。

テンプレートとは、例えば、プレゼンテーションソフトウェアで用いる雛形ファイルである。提案書の構成は、例えば、表紙ページ、代表者挨拶ページ、会社概要ページ、サービス概要ページ、市場動向ページ、問題・課題整理ページ、事例ページ及び補足ページである。これらの各ページのレイアウトやフォント及びサイズ等の文字設定をテンプレートとして作成する。また、案件毎に変化はなく内容が共通となる代表者挨拶ページ、会社概要ページ、サービス概要ページについては、完成した内容のページをテンプレートとして記憶する。

次に、提案書作成処理について説明する。提案書作成処理の流れは、図３９に示したものと同様である。以下では、ステップＳ８６の各ページの作成について、説明する。市場動向ページは、顧客企業の業種に合わせた内容で作成される。顧客企業の業種は、対象企業ＤＢ１３３の業種列の値（図７参照）を取得、又は、企業情報入力画面ｄ０１の業種設定ボタンｄ０１２による入力結果より取得する。市場動向に関する情報は業種と対応付けて、提供サーバ１の補助記憶部１３に記憶しておく。それに限らず、シンクタンク、市場調査会社、信用調査会社等から提供をうけてもよい。提供サーバ１は、顧客企業の業種を検索キーとして、シンクタンク、市場調査会社、信用調査会社等が運用するデータベースを検索し、市場動向に関する情報を取得する。

問題・課題整理ページは、事例ＤＢの課題列の値（図１１参照）、又は、課題選択画面ｄ０２の課題選択ボタンｄ０２２により入力結果より取得した値に基づいて、顧客企業の問題・課題を表示する。問題・課題整理ページには、従業員数別の問題・課題を含めてもよい。顧客企業の従業員数は、対象企業ＤＢ１３３の従業員数列、又は、企業情報入力画面ｄ０１の従業員数選択ボタンｄ０１９による入力結果より取得する。

事例ページは、問題・課題に対応する事例の詳細を表示する。事例の詳細の例は、図２７に示したとおりである。ここでは、プレゼンテーションソフトウェアで表示する提案書を想定している。ここでの事例ページでは、図２７に示した内容を横長のフォーマットに変換する。

補足ページは、事例を補足する補足内容を表示する。補足内容は事例で採用された商材と連動したものである。例えば、事例において、ＳＦＡが採用された場合、ＳＦＡの導入の効果が補足内容となる。ＳＦＡ導入により、営業リードタイムの短縮、間接業務の削減及び成約率・単価・継続率の改善による時間削減により、営業一人当たりの売上高アップ及び時間当たりの売上高アップの効果を得られることが補足内容となる。ＣＲＭであれば、営業履歴、利用履歴、Ｗｅｂ閲覧履歴、クレーム等の顧客情報が一元化されリアルタイム管理されるので、営業員やカスタマーセンターから最適提案、接客を顧客に対して行えるようになる。その結果、顧客のロイヤリティがアップし、顧客生涯価値（ＬＴＶ＝Life Time Value）が最大化する効果が得られることが補足内容となる。

補足内容は商材と対応付けて、商材ＤＢ１３９に記憶する。または、商材の種類ごとに補足内容を記憶してよい。ＳＦＡ、ＣＲＭ、ＭＡ（Marketing Automation）ツール等をそれぞれ複数社が製造・販売しているとしても、導入効果を含む補足内容には大きな違いはないと考えられるからである。

本実施の形態は、以下の効果を奏する。提案書作成に不慣れなユーザであっても、顧客企業向けの提案書を簡単かつ迅速に作成可能である。特に、市場動向ページ及び補足ページについても、提供システム１００が自動生成するので、より効果的な内容の提案書を作成可能となる。なお、提案書の構成として、表紙ページ、代表者挨拶ページ、会社概要ページ、サービス概要ページ、市場動向ページ、問題・課題整理ページ、事例ページ及び補足ページと述べたが、全てのページを含む必要はない。例えば、問題・課題整理ページのみの提案書を作成してもよい。

（同意書作成機能）
同意書作成機能は、上述の実施の形態に追加される機能である。同意書は、顧客企業がユーザ企業にマッチング依頼を行う際に、ユーザ企業に対して交付する書類である。同意書は、ビジネスマッチングにおいて、ユーザ企業が顧客企業に同意を求める事項が記載されている。同意を求める事項とは、例えば、顧客企業の情報をユーザ企業が業者へ提供すること、業者との商談、取引等は顧客企業の判断と責任のもとで行い、ユーザ企業は一切の責任を負わないこと等である。

図６３は同意書設定ＤＢの例を示す説明図である。同意書設定ＤＢ１３Ｏは同意書に関する情報を記憶する。同意書設定ＤＢ１３Ｏは企業ＩＤ列、事項数列、本文列及びチェック事項列を含む。企業ＩＤ列は企業ＩＤを記憶する。事項数列はチェック事項の項数を記憶する。本文列は同意書の本文の内容を記憶する。チェック事項列はチェック事項として表示する内容を記憶する。チェック事項は、同意書の中で、顧客企業に特に確認して欲しい内容を記載したものであって、チェックボックスにチェックを入れさせることで、顧客企業が確認したことを記録して残す事項である。同意書作成機能を使用するユーザ企業は、予め同意書設定ＤＢ１３Ｏに自社用のデータを記憶しておく。

図６４は同意書ＤＢの例を示す説明図である。同意書ＤＢ１３Ｐは交付された同意書をデータとして記憶する。同意書ＤＢ１３ＰはケースＩＤ列、同意書列及び交付日列を含む。ケースＩＤ列はケースＩＤを記憶する。同意書列は同意書を画像データとして記憶する。当該画像データは顧客企業が内容に同意した旨を署名データと共に提供サーバ１に送信してきた時に作成される。交付日列は同意書が交付された日（通常は同意書の画像データが作成された日と同じである）を記憶する。なお、同意書ＤＢ１３Ｐが記憶する同意書は画像データであるとしたが、同意書の内容が復元可能であり、改ざんが困難で、改ざんの検知が可能であれば、他のデータ形式で記憶してもよい。

図６５は同意書作成処理の手順例を示すフローチャートである。同意書交付処理は顧客企業がマッチング依頼を行う際に実行される。実施の形態１等において、顧客企業はユーザ企業から提案を受けて、事例に基にしたマッチング依頼を行う。または、実施の形態６等において、顧客企業は自ら提供システム１００にアクセスし、自社の問題・課題の把握と、それを解決した過去の事例を参照し、事例を基にしたマッチング依頼を行う。顧客端末４はマッチング依頼を提供サーバ１へ送信する（ステップＳ２２１）。マッチング依頼には、事例を特定するケースＩＤ、顧客企業を特定する企業ＩＤが含まれている。提供サーバ１の制御部１１はマッチング依頼を受信する（ステップＳ２２２）。制御部１１は、企業ＩＤをキーにユーザ企業ＤＢ１３２を検索し、顧客情報を取得する。制御部１１は、顧客情報に含まれる顧客企業担当の銀行ユーザのユーザＩＤをキーに、ユーザＤＢ１３１を検索し、銀行を特定する企業ＩＤを取得する。制御部１１は企業ＩＤをキーに同意書設定ＤＢ１３Ｏを検索し、同意書の設定を取得する。制御部１１は企業ＩＤをキーにユーザ企業ＤＢ１３２を検索し、銀行情報を取得する。制御部１１はケースＩＤをキーに事例ＤＢ１３７を検索し、事例情報を取得する。制御部１１は事例情報に含まれる業者ＩＤをキーに業者ＤＢ１３Ｆを検索し、業者情報を取得する。業者ＩＤが複数、含まれる場合は複数の業者情報を取得する。また、制御部１１は、ケースＩＤをキーに商材実績ＤＢ１３Ａを検索し、事例で採用された商材の商材ＩＤを取得する。制御部１１は商材ＩＤをキーに、図示しないメーカＤＢを検索し、商材を提供しているメーカの情報を取得する。メーカＤＢはメーカの情報（名称、所在地等）を商材ＩＤと対応付けて記憶するデータベースである。制御部１１は取得した情報、顧客情報に含まれる顧客企業名、銀行情報に含まれる銀行名、業者情報に含まれる業者の名称、及び、メーカの名称、並びに、同意書の設定を用いて、同意書画面を作成する（ステップＳ２２３）。なお、業者が自社の商材を提案する場合、メーカの名称は含まなくともよい。制御部１１は同意書画面を顧客端末４へ送信する（ステップＳ２２４）。顧客端末４は同意書画面を受信し、表示する（ステップＳ２２５）。顧客企業は同意書の内容を確認する。内容に承諾する場合、顧客企業はチェック事項のチェックと署名とを行う。顧客端末４はチェックの入力と、署名の入力とを受け付ける（ステップＳ２２６）。顧客端末４はチェック情報と署名の画像（署名画像）とを含む同意情報を提供サーバ１へ送信する（ステップＳ２２７）。提供サーバ１の制御部１１はチェック情報と署名の画像とを受信する（ステップＳ２２８）。制御部１１は署名済み同意書の画像（署名済画像）を作成する（ステップＳ２２９）。当該画像は、顧客企業がチェック事項のチェックと署名とを行った後に、顧客端末４に表示されていた画面イメージと同等なものである。なお、作成される画像データには、改ざん防止及び改ざん検知のために電子透かしを付加してもよい。制御部１１は作成した画像を同意書ＤＢ１３Ｐに記憶する（ステップＳ２３０）。制御部１１は同意書が作成された旨の通知を顧客端末４へ送信する（ステップＳ２３１）。顧客端末４は通知を受信し、表示する（ステップＳ２３２）。同意書作成処理は終了する。ステップＳ２３１で送信される通知には、提供サーバ１が作成した同意書の画像を含めてもよい。同意書作成処理の終了後、顧客企業は業者への依頼の送信を顧客端末４へ指示する。顧客端末４は提供サーバ１へ顧客企業の指示内容を送信する。提供サーバ１の制御部１１は、依頼先の業者端末３へ顧客企業の依頼内容を送信する。顧客企業が同意書の作成を行わない場合、業者への依頼送信は行わない。顧客企業は図２９で示した依頼入力画面ｄ０５を用いて、依頼内容を作成する。業者が依頼内容を受信した後の業務や処理は上述したとおりである。

同意書作成処理をユーザが実行してもよい。ユーザが顧客企業に出向き、事例に基づく提案を行った際に、マッチング依頼を行う場合などを想定する。ユーザは事例を選択し、依頼を行う旨を選択する。また、顧客企業の情報を入力する。顧客企業の情報がすでに対象企業ＤＢ１３３に登録されている場合、対象企業ＤＢ１３３から顧客企業の情報を読み込んでもよい。ユーザ端末２は事例を特定するケースＩＤ、顧客企業の情報、及び、依頼を行う旨を提供サーバ１へ送信する。提供サーバ１は同意書画面を作成し、ユーザ端末２へ送信する。ユーザ端末２は同意書画面を受信し、表示する。ユーザは顧客企業に、同意書の内容を確認してもらう。顧客企業はチェック事項のチェックと署名とを行う。ユーザ端末２はチェック情報と署名の画像とを含む同意情報を提供サーバ１へ送信する。以降の処理は、図６５のステップＳ２２８以降と同様である。

図６６は同意書画面の例を示す説明図である。同意書画面ｄ１８は規約欄ｄ１８１、確認事項欄ｄ１８２、追加同意欄ｄ１８３、署名欄ｄ１８４及び確定ボタンｄ１８５を含む。規約欄ｄ１８１はビジネスマッチングに関する規約を表示する。確認事項欄ｄ１８２は、顧客企業が確認したことを、ユーザ企業が記録したいと考える事項の内容と確認したことを入力させるチェック欄とを含む。追加同意欄ｄ１８３は、ユーザ企業との同意内容が、事業者、商材メーカにも適用されることの確認を、顧客企業に求める欄である。署名欄ｄ１８４は顧客企業の担当者が署名を入力する欄である。確定ボタンｄ１８５をチェック情報と署名の画像とが提供サーバ１へ送信される。

同意書作成機能により、マッチング依頼時に同意書の作成を行うので、顧客企業から同意書の交付を受けることが可能となる。また、顧客企業が同意書の作成を行わない場合、依頼内容が業者端末３へ送信されないので、同意書なしで顧客企業と業者とをマッチングしてしまうことを抑制することが可能となる。なお、提供システム１００に顧客企業の情報が登録される際、顧客企業は提供システム１００の運営会社に対する同意書の作成も必要となるが、上述の同意書作成機能と同様な処理により、作成可能である。

（事例一覧のソート表示）
図２６に事例一覧画面ｄ０３の例を示した。事例一覧において、事例の表示順については、特に説明していないが、ここでは、表示順の一例について説明する。表示順を決める値として、事例の成約数を用いる。提供システム１００では、事例に基づいてマッチング依頼が行われる。マッチング依頼の後、顧客企業が業者に対して、有料コンサルティング依頼や商材の購入等の契約をした場合、マッチング依頼の基になった事例の契約とみなし、その契約の数を事例の契約数とする。

図６７は事例評価ＤＢの例を示す説明図である。事例評価ＤＢ１３Ｑは事例毎の契約数を記憶する。事例評価ＤＢ１３ＱはケースＩＤ列、集計期間列及び契約数列を含む。ケースＩＤ列は事例を特定するケースＩＤを記憶する。集計期間列は契約数を集計した期間を記憶する。契約数列は集計期間における事例の契約数を記憶する。契約数列は図５３に示した事例属性ＤＢ１３Ｋの契約列と同様な値を記憶するが、契約数列は、値を集計した期間が対応付いている。

期間を定めて契約数を集計するために、図１２に示した依頼ＤＢ１３８に契約日列を追加する。顧客企業が業者とコンサルティング契約や購入契約等を締結した場合、その契約日が契約日列に記憶される。未契約の場合や、契約に至らず終了した場合は、契約日列は空白又は値なしとなっている。

図６８は集計処理の手順例を示すフローチャートである。提供サーバ１の制御部１１は集計期間を算出する（ステップＳ２４１）。例えば、四半期単位で集計している場合、現在日付が４月１日であれば、集計期間を１月１日から３月３１日とする。制御部１１は依頼ＤＢ１３８の契約日列の値を参照して、契約日が集計期間に含まれる集計対象事例を抽出する（ステップＳ２４２）。制御部１１はケースＩＤに基づいて、事例毎の契約数を算出する（ステップＳ２４３）。制御部１１は算出した契約数を事例評価ＤＢ１３Ｑに記憶する（ステップＳ２４４）。集計処理は集計期間の長さに応じた間隔で実行する。

契約数の集計期間は複数設けてもよい。四半期毎に加えて、１ヶ月毎に集計してもよい。集計期間が複数の場合、事例評価ＤＢ１３Ｑは異なる期間毎の契約数を記憶する。また、即時性を重視して、直近１週間、直近１ヶ月の契約数等を日次で集計してもよい。

事例一覧画面ｄ０３において、事例を契約数の降順に表示することより、マッチング依頼数の増加、商材の成約率の向上が期待できる。なお、ソートに用いる値を契約数としたが、事例が閲覧された回数（閲覧数）、ブックマーク登録された回数（ブックマーク数）、マッチング依頼に至った回数（依頼数）、転換率、顧客企業による評価点を用いてもよい。これらの値は、契約数と同様に集計処理を行い、集計結果を事例評価ＤＢ１３Ｑに記憶する。

（実施の形態１４）
本実施の形態は、他システムのアカウントで、提供システム１００を利用可能な形態に関する。提供システム１００へのログインの際に、例えば、ＯＡｕｔｈを用いる。ＳＦＡシステム、ＣＲＭシステム、会計システム、勤怠システム、ＰＯＳシステム、経営計画作成システム等の他システムにアカウントを持っているユーザは、他システムに保有している情報（ログイン情報等）の利用権限を提供システム１００へ付与することにより、他システムのアカントで、提供システム１００の利用が可能となる。

図６９はログイン画面の例を示す説明図である。ログイン画面ｄ１４はログイン情報入力欄ｄ１４１、ログインボタンｄ１４２及び連携ボタンｄ１４３を含む。ログイン情報入力欄ｄ１４１は、既に提供システム１００に登録したユーザがログインする際に、ユーザＩＤとパスワードとを入力する欄である。ログインボタンｄ１４２を選択すると、ログイン情報入力欄ｄ１４１に入力されたユーザＩＤとパスワードとが提供サーバ１へ送信される。連携ボタンｄ１４３を選択すると、選択したボタンに対応する他システムのアカントで提供システム１００への登録／ログインを行う。選択した他システムにログインしていない場合は、他システムのログイン画面が表示されるので、ログイン操作をする。他システムでのログイン認証が済むと、提供システム１００へリダイレクトされ、提供システム１００にログインできる。選択した他システムのアカウントでのログインが初めての場合、データ連携の許可を求める連携確認画面が表示される。

図７０は連携確認画面の例を示す説明図である。連携確認画面ｄ１５は連携データｄ１５１、編集リンクｄ１５２、ログインボタンｄ１５３及びキャンセルリンクｄ１５４を含む。連携データｄ１５１は、提供システム１００が他システムから取得するデータを表示する。編集リンクｄ１５２を選択すると、提供システム１００が他システムから取得するデータの取捨選択が行える編集画面（図示しない）が表示される。ログインボタンｄ１５３を選択すると、他システムのアカウントで提供システム１００にログインする。他システムのアカウントでログインするのが初めての場合、ユーザ登録画面が表示されるときがある。他システムから取得可能なデータ以外に、提供システム１００が求める情報があるとき、ユーザ登録画面が表示される。キャンセルリンクｄ１５４を選択する他システムのアカウントでのログイン動作は中止される。

本実施の形態では、他システムのアカウントを利用して、ユーザ登録及びログインが可能なので、操作負担の軽減が可能となる。また、実施の形態１０と同様に、他システムから取得したデータをもとに、顧客ユーザは、自社の問題・課題を見出すことが可能となる。

（商材・企業検索機能）
提供システム１００は顧客企業が抱える問題・課題を特定又は推定し、同様な問題・課題を解決した事例を表示する。ここでは、問題・課題ではない他の観点から検索を行い、事例を表示する機能について説明する。本機能に対応するため、上述したデータベースに以下のような拡張を行う。商材ＤＢ１３９にカテゴリ列及び用途列を追加し、それぞれ商材のカテゴリ、用途を記憶する。また、実施の形態１４で述べたメーカの情報（名称、所在地等）を商材ＩＤと対応付けて記憶するメーカＤＢ（図示しない）を用いる。

図７１は検索処理の手順例を示すフローチャートである。提供サーバ１の制御部１１は商材検索を行う（ステップＳ２５１）。制御部１１は商材ＤＢ１３９と商材評価ＤＢ１３Ｂとを商材ＩＤで結合したワークテーブルを作成する。制御部１１は指定された検索条件で、ワークテーブルを検索する。指定された検索条件のうち、名称についは商材名を対象に検索する。キーワードについては、商材名や説明テキストを対象に検索する。制御部１１は企業検索を行う（ステップＳ２５２）。制御部１１はメーカＤＢと商材ＤＢ１３９とを商材ＩＤで結合したワークテーブルを作成する。制御部１１は指定された検索条件で、ワークテーブルを検索する。指定された検索条件のうち、名称についはメーカを対象に検索する。キーワードについては、メーカの説明等を対象に検索する。制御部１１はステップＳ２５１の検索にヒットしたレコードに含まれる商材ＩＤと、ステップＳ２５２の検索にヒットしたレコードに含まれる商材ＩＤとを結合する（ステップＳ２５３）。制御部１１は検索にヒットした商材が採用された事例を検索する（ステップＳ２５４）。制御部１１は検索結果を検索者の端末（ユーザ端末２、顧客端末４）へ送信し（ステップＳ２５５）、処理を終了する。

図７２は検索画面の例を示す説明図である。検索画面ｄ１６は商材・企業検索を行う画面である。検索画面ｄ１６は名称欄ｄ１６１、キーワード欄ｄ１６２、カテゴリ指定領域ｄ１６３、その他リンクｄ１６４、用途指定領域ｄ１６５、その他リンクｄ１６６、業種指定領域ｄ１６７、その他リンクｄ１６８、検索ボタンｄ１６９及びキャンセルボタンｄ１６Ａを含む。名称欄ｄ１６１には、商材名や企業名で検索を行いたい場合に、名称の一部又は全部を入力する。キーワード欄ｄ１６２には、検索のキーワードを入力する。検索対象は事例情報に含まれるテキストデータである。カテゴリ指定領域ｄ１６３は商材のカテゴリを指定する領域である。その他リンクｄ１６４を選択すると、表示されていない他のカテゴリを指定するためのボタンが表示される。用途指定領域ｄ１６５は商材の用途を指定する領域である。その他リンクｄ１６６を選択すると、表示されていない他の用途を指定するためのボタンが表示される。業種指定領域ｄ１６７は対象企業の業種を指定する領域である。その他リンクｄ１６８を選択すると、表示されていない他の業種を指定するためのボタンが表示される。検索ボタンｄ１６９を選択すると、検索条件が提供サーバ１へ送信され、検索処理が実行される。キャンセルボタンｄ１６Ａを選択すると一つ前の画面へ戻る。なお、検索ヒット数が極端に多くならないように、カテゴリ及び用途は設定が必須の条件とすることが望ましい。

図７３は結果一覧画面の例を示す説明図である。結果一覧画面ｄ１７は事例表示欄ｄ１７１、ページ制御ボタンｄ１７２及びおすすめ欄ｄ１７３を含む。事例表示欄ｄ１７１及びページ制御ボタンｄ１７２は、それぞれ図２６に示した事例表示欄ｄ０３１及びページ制御ボタンｄ０３２と同様であるから説明を省略する。おすすめ欄ｄ１７３は、おすすめ商材の情報を表示する。例えば、検索処理のステップＳ２５１で検索にヒットしたものの、対応する事例が検索条件にヒットしなかったため、検索結果の事例とは結びつかない商材の情報を表示する。実施の形態１１においては、おすすめ欄ｄ１７３に他システム（ＳＦＡシステム、ＣＲＭシステム、会計システム、勤怠システム、ＰＯＳシステム、経営計画作成システム等）の紹介ページとリンクしたバナーを表示してよい。

商材・企業検索機能は、以下の効果を奏する。商材の購入の検討段階において、当該商材の導入事例を複数参照可能であるので、導入効果の実績が確認可能である。また、商材導入による直接的効果だけてなく、間接的な効果も得られる可能性がある。

（問題のクイック選択）
上述において、顧客企業の問題・課題を選択するため、企業情報入力画面ｄ０１及び課題選択画面ｄ０２を用いた。しかし、事例の表示まで迅速に辿り着くように、入力項目を減らした画面を用意してもよい。図７４は問題選択画面の例を示す説明図である。問題選択画面ｄ１９は、業種設定ボタンｄ１９１、その他業種ｄ１９２、従業員数選択ボタンｄ１９３、その他人数ｄ１９４、テーマ選択ボタンｄ１９５、問題・課題選択ボタンｄ１９６及び検索ボタンｄ１９７を含む。業種設定ボタンｄ１９１は顧客企業の業種を入力するボタンである。表示している業種に該当するものがない場合は、その他業種ｄ１９２を選択すると業種設定ボタンｄ１９１の表示数が増える。従業員数選択ボタンｄ１９３により顧客企業の従業員数を設定する。表示している従業員数に該当するものがない場合は、その他人数ｄ１９４を選択すると従業員数選択ボタンｄ１９３の表示数が増える。テーマ選択ボタンｄ１９５は問題・課題のテーマを選択するボタンである。問題・課題選択ボタンｄ１９６は問題・課題を選択するボタンである。問題・課題選択ボタンｄ１９６の内容は、テーマ選択ボタンｄ１９５により選択されたテーマに応じて変動する。テーマと問題・課題との対応付けは、課題類型ＤＢ１３４が記憶している。検索ボタンｄ１９７を選択すると、問題選択画面ｄ１９で設定された検索条件が提供サーバ１へ送信される。提供サーバ１は事例を検索し、検索結果の一覧を返送する。当該検索結果は結果一覧画面ｄ１７で表示される。

図７５は事例検索処理の手順例を示すフローチャートである。事例検索処理は、問題選択画面ｄ１９で設定された検索条件で事例を検索する処理である。提供サーバ１の制御部１１はユーザ端末２から検索条件を受信する（ステップＳ２６１）。制御部１１は検索条件に含まれるテーマ、問題・課題を検索キーに事例ＤＢ１３７を検索する。事例ＤＢ１３７において、テーマはテーマ列に、問題・課題は課題列に記憶されている。制御部１１は検索にヒットしたレコードに含まれるケースＩＤにより、事例と、対象企業ＤＢ１３３が記憶している当該事例の対象となった対象企業の情報とを結合する（ステップＳ２６３）。制御部１１は結合して得たワークテーブルを検索し、対象企業の業種、従業員数が、検索条件に含まれている業種、従業員数に適合する事例に絞り込む（ステップＳ２６４）。制御部１１は絞り込んだ結果より、結果一覧画面を生成する（ステップＳ２６５）。制御部１１は結果一覧画面をユーザ端末２へ送信し（ステップＳ２６６）、処理を終了する。

各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１００ 提供システム
１ 提供サーバ
１１ 制御部
１２ 主記憶部
１３ 補助記憶部
１３１ ユーザＤＢ
１３２ ユーザ企業ＤＢ
１３３ 対象企業ＤＢ
１３４ 課題類型ＤＢ
１３５ 典型課題ＤＢ
１３６ 検索履歴ＤＢ
１３７ 事例ＤＢ
１３８ 依頼ＤＢ
１３９ 商材ＤＢ
１３Ａ 商材実績ＤＢ
１３Ｂ 商材評価ＤＢ
１３Ｃ 登録商材ＤＢ
１３Ｄ 閲覧履歴ＤＢ
１３Ｅ ブックマークＤＢ
１３Ｆ 業者ＤＢ
１３Ｇ 課題判定ＤＢ
１３Ｈ 通知ポイントＤＢ
１３Ｉ シナリオＤＢ
１３Ｊ 共有設定ＤＢ
１３Ｋ 事例属性ＤＢ
１３Ｌ 補助金ＤＢ
１３Ｍ 優先表示ＤＢ
１３Ｎ 書式設定ＤＢ
１３Ｏ 同意書設定ＤＢ
１３Ｐ 同意書ＤＢ
１３Ｑ 事例評価ＤＢ
１４ 通信部
１５ 読み取り部
１６ 判定モデル
１Ｐ 制御プログラム
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
２ ユーザ端末
２１ 制御部
２２ 主記憶部
２３ 補助記憶部
２４ 通信部
２５ 入力部
２６ 表示部
２Ｐ 制御プログラム
３ 業者端末
３１ 制御部
３２ 主記憶部
３３ 補助記憶部
３４ 通信部
３５ 入力部
３６ 表示部
４ 顧客端末

Claims (24)

1. 企業の情報を取得し、
   前記企業の情報に基づき、問題・課題を記憶する記憶部を参照して前記企業の前記問題・課題を特定し、
   特定した前記問題・課題、前記企業の情報に基づき、前記問題・課題に関連する事例を特定し、
   特定した前記事例を出力し、
   前記事例に基づくマッチング依頼を受け付け、
   受け付けたマッチング依頼を所定の送信先へ送信する
   処理をコンピュータに行わせることを特徴とするコンピュータプログラム。
2. 企業の情報を取得し、
   前記企業の情報に基づき、問題・課題を記憶する記憶部を参照して前記企業の前記問題・課題を特定し、
   特定した前記問題・課題を出力し、
   特定した前記問題・課題、前記企業の情報に基づき、前記問題・課題に関連する事例を特定し、
   特定した前記事例を出力し、
   前記事例に基づくマッチング依頼を受け付け、
   受け付けたマッチング依頼を所定の送信先へ送信する
   処理をコンピュータに行わせることを特徴とするコンピュータプログラム。
3. 企業の情報、及び前記企業の問題・課題を取得し、
   取得した前記企業の情報及び前記問題・課題、に基づき、前記問題・課題に関連する事例を特定し、
   特定した前記事例を出力し、
   前記事例に基づくマッチング依頼を受け付け、
   受け付けたマッチング依頼を所定の送信先へ送信する
   処理をコンピュータに行わせることを特徴とするコンピュータプログラム。
4. 特定した前記事例を評価値に基づき並べ替えを行い、並べ替えた順で表示されるように前記事例を出力する
   ことを特徴とする請求項１から請求項３の何れか１項に記載のコンピュータプログラム。
5. 特定した前記事例が所定数を超えた場合、前記評価値に基づき、所定数の前記事例を選択し、
   選択した前記事例を出力する
   ことを特徴とする請求項４に記載のコンピュータプログラム。
6. 前記評価値は、検索ヒット回数、参照回数、ブックマーク登録数、依頼回数、成約数、ユーザ評価点又は転換率から算出する
   ことを特徴とする請求項４又は請求項５に記載のコンピュータプログラム。
7. ユーザの属性を取得し、
   取得した属性と類似する他ユーザの閲覧履歴を取得し、
   前記特定した事例の中で、前記閲覧履歴に含まれるものが優先的に表示されるように前記特定した事例を出力する
   ことを特徴とする請求項１から請求項３のいずれか１項に記載のコンピュータプログラム。
8. ハイパフォーマーが参照した事例又はユーザが所属する企業が指定した事例を取得し、
   取得した事例を、前記特定した事例と合わせて出力する
   ことを特徴とする請求項１から請求項３のいずれか１項に記載のコンピュータプログラム。
9. 前記マッチング依頼に含まれる前記事例の識別情報を含み、対応付けられた業者の識別情報を取得し、
   前記送信先は、取得した前記業者の前記識別情報に対応付けられた送信先とする
   ことを特徴とする請求項１から請求項８のいずれか１項に記載のコンピュータプログラム。
10. 前記企業に関する営業情報、顧客情報、経営計画情報、会計情報、ＰＯＳ情報又は人財情報を含む前記企業の情報を取得し、
    取得した前記企業の情報から、前記企業に関する値の傾向を求め、
    値の傾向と予想される問題・課題とを対応付けて記憶する記憶部を参照し、前記求めた値の傾向に基づく、前記企業の問題・課題を特定する
    ことを特徴とする請求項１から請求項９のいずれか１項に記載のコンピュータプログラム。
11. 前記企業のユーザが閲覧した前記事例についての閲覧履歴に基づいて、前記ユーザに関する前記事例についてのスコアを算出し、
    算出した前記スコアが所定の閾値を超えた場合に、前記企業の他のユーザ又は前記企業と対応付けられていないユーザへ通知を送信する
    ことを特徴とする請求項１から請求項１０のいずれか１項に記載のコンピュータプログラム。
12. 前記特定した事例に対応付けられた商材の識別情報を取得し、
    取得した前記商材の識別情報と対応付けられた前記商材の情報、補助金及び助成金の情報、口コミ情報を取得し、
    前記特定した事例に関連する事例を取得し、
    取得した前記商材の情報、前記補助金及び助成金の情報又は前記口コミ情報、若しくは、前記関連する事例を出力する
    ことを特徴とする請求項１から請求項１１のいずれか１項に記載のコンピュータプログラム。
13. 前記事例の閲覧履歴に基づいて、前記問題・課題と前記事例とを含む提案書を作成する
    ことを特徴とする請求項１から請求項１２のいずれか１項に記載のコンピュータプログラム。
14. 記憶部にアクセス可能なコンピュータが、
    企業の情報を取得し、
    前記企業の情報に基づき、問題・課題を記憶する前記記憶部を参照して前記企業の前記問題・課題を特定し、
    特定した前記問題・課題を出力し、
    特定した前記問題・課題、前記企業の情報に基づき、前記問題・課題に関連する事例を特定し、
    特定した前記事例が所定数を超えた場合、各事例の評価値に基づき所定数に絞り込み、所定数の前記事例を出力し、
    前記事例に基づくマッチング依頼を受け付け、
    受け付けたマッチング依頼を所定の送信先へ送信する
    処理を行うことを特徴とする送信方法。
15. 企業の情報を取得する第１取得部と、
    前記企業の情報に基づき、問題・課題を記憶する記憶部を参照して前記企業の前記問題・課題を特定する第１特定部と、
    特定した前記問題・課題を出力する第１出力部と、
    特定した前記問題・課題、前記企業の情報に基づき、前記問題・課題に関連する事例を特定する第２特定部と、
    特定した前記事例が所定数を超えた場合、各事例の評価値に基づき所定数に絞り込み、所定数の前記事例を出力する第２出力部と、
    前記事例に基づくマッチング依頼を受け付ける受付部と、
    受け付けたマッチング依頼を所定の送信先へ送信する送信部と
    を備えることを特徴とする送信装置。
16. 問題・課題を記憶する記憶部にアクセス可能なコンピュータが、
    他コンピュータから企業の情報を取得し、
    前記企業の情報に基づき、前記記憶部を参照して前記企業の前記問題・課題を特定し、
    特定した前記問題・課題を前記他コンピュータへ出力し、
    前記他コンピュータから前記問題・課題の選択情報を取得し、
    前記選択情報に対応する前記問題・課題に関連する事例を特定し、
    特定した前記事例を前記他コンピュータへ出力する
    処理を前記コンピュータに行わせることを特徴とするコンピュータプログラム。
17. 問題・課題を記憶する記憶部にアクセス可能なコンピュータが、
    企業の識別情報を取得し、
    識別情報に基づき、前記企業の情報を他コンピュータより取得し、
    取得した前記企業の情報に基づき、前記記憶部を参照して前記企業の前記問題・課題を特定し、
    特定した前記問題・課題、前記企業の情報に基づき、前記問題・課題に関連する事例を特定し、
    特定した前記事例を出力する
    処理を前記コンピュータに行わせることを特徴とするコンピュータプログラム。
18. 企業の情報及び問題・課題を取得し、
    取得した前記企業の情報及び前記問題・課題に基づき、事例を特定し、
    前記企業の情報に含まれる業種に基づき、市場動向に関する情報を取得し、
    特定した前記事例で採用された商材に関する補足情報を取得し、
    前記問題・課題、前記事例、前記市場動向に関する情報、又は、前記補足情報を含む提案書を作成し、
    作成した提案書を出力する
    処理をコンピュータに行わせることを特徴とするコンピュータプログラム。
19. 前記提案書の出力後、前記事例に基づくマッチング依頼を受け付け、
    受け付けたマッチング依頼を所定の送信先へ送信する
    ことを特徴とする請求項１８に記載のコンピュータプログラム。
20. マッチング依頼を受け付けた場合、同意書を出力し、
    前記同意書の内容に承諾したこと示す署名画像を含む同意情報を取得し、
    前記同意書及び前記署名画像を含む署名済画像を生成し、
    生成した署名済画像を記憶する
    ことを特徴とする請求項１９に記載のコンピュータプログラム。
21. 前記マッチング依頼による成約数を、前記事例毎に集計し、
    前記問題・課題に関連する事例を複数特定した場合、特定した前記事例を前記成約数で定まる順に並べた事例一覧を出力し、
    前記事例一覧において選択された事例を取得し、
    取得した事例に基づく提案書を作成する
    ことを特徴とする請求項１９又は請求項２０に記載のコンピュータプログラム。
22. 商材についての検索条件を取得し、
    取得した検索条件にヒットする前記商材を取得し、
    検索にヒットした前記商材と対応付けられた事例を特定し、
    特定した前記事例の一覧を出力し、
    出力した一覧において選択された事例を取得し、
    取得した事例に基づく提案書を作成する
    ことを特徴とする請求項１８から請求項２１のいずれか一項に記載のコンピュータプログラム。
23. 商材を提供するメーカについての検索条件を取得し、
    取得した検索条件にヒットしたメーカが取り扱う前記商材を取得し、
    取得した前記商材と対応付けられた事例を特定し、
    特定した前記事例の一覧を出力し、
    出力した一覧において選択された事例を取得し、
    取得した事例に基づく提案書を作成する
    ことを特徴とする請求項１８から請求項２１のいずれか一項に記載のコンピュータプログラム。
24. コンピュータが、
    企業の情報及び問題・課題を取得し、
    取得した前記企業の情報及び前記問題・課題に基づき、事例を特定し、
    前記企業の情報に含まれる業種に基づき、市場動向に関する情報を取得し、
    特定した前記事例で採用された商材に関する補足情報を取得し、
    前記問題・課題、前記事例、前記市場動向、又は、前記補足情報を含む提案書を作成し、
    作成した提案書を出力する
    処理を行うことを特徴とする送信方法。

Images