JP2021082189A - 業務支援装置および業務支援方法 - Google Patents

Abstract

【課題】最小の労力で最適な実施アクションを行うための制約条件を決定し、業務の現実状況に基づいて適切な実施アクションを行うように業務支援を行う。【解決手段】業務支援装置は、担当者ごとの実施アクションを保持する活動トランザクションテーブルと、業務活動に関する顧客の情報を保持する顧客プロパティテーブルと、担当者ごとに、担当する顧客を保持する担当先顧客テーブルとを備え、担当者の担当先顧客に基づいて、担当者をクラスタリングして、担当者クラスタを作成し、担当者クラスタごとに共通制約条件を制約条件テーブルに格納し、その制約条件に基づいて、担当者クラスタに含まれる担当者と実施アクションで制約条件に合致しない組合せを除いて、業務活動に関する実施アクションを候補として提示する。【選択図】 図１

Description

本発明は、業務支援装置および業務支援方法に係り、特に、業務活動において最適な実施アクションを行うための制約条件を決定するのに好適な業務支援装置および業務支援方法に関する。

近年、情報処理装置で実行される多変量解析エンジンを用いて、目的変数と相関の高い説明変数の組合せを発見することにより、業務改善のための施策を立案する分析サービスが行われている。このような分析サービスを行うシステムでは、実施アクションの選択のため、評価方法を設定して選出を行う。そして、実施するアクションの探索は、対象としている顧客ごとに実施可能な営業活動の中から最適なものを選択する。ここで、実施可能なアクションは制約条件を用いて決定される。このときに、予め制約条件を記述しておき、施策立案の分析に用いることもできるが、例えば、営業活動のような業務の場合には、営業担当者や顧客担当者によって活動の特性が異なるため、実情を反映した制約条件を予め決めておくことが困難である。

そこで、過去データから制約条件を推定する手法が提案されている。例えば、特許文献１に記載された統計モデルに関する技術は、過去データから線型回帰式の係数が取り得る定義域を過去データから推定する手法を用いており、これを応用して変数の定義域の推定が可能である。

特開２０１８−１０９８０５号公報

上記従来技術に係る特許文献１では、統計モデルによる解析のために説明変数にかかる係数に対する制約条件を定める技術が示されている。

しかしながら、この手法で提案された制約条件は他変数との組合せで記述されるものではなく、複雑で現実的な営業活動を分析するモデルとしては、不十分といわざるをえない。

また、営業活動の過去データから制約条件を作成する場合に、ある条件下で実施されていないアクションがあった場合、それが実施可能であるが、たまたまこれまで実施されていなかったのか、あえて実施していない、あるいは実施できない(=制約条件)状況にあるのか、データからは判断できなかった。このとき、制約条件としてふさわしいかの判断をユーザ（営業の計画立案者）に委ねようとしても、上述のように営業担当者や顧客担当者によって活動の特性が異なるため、どの営業担当者に判断を仰ぐか決定できなかったため、担当者全員に問合せる必要があった。

本発明の目的は、業務活動において最小の労力で最適な実施アクションを行うための制約条件を決定することができ、それに基づいた業務における実施アクションを行うことにより、業務の現実状況に基づいて適切な実施アクションを行うことのできる業務支援装置および業務支援方法を提供することにある。

本発明の業務支援装置の構成は、好ましくは、制約条件の下で業務活動に関する実施アクションを提示する業務支援装置であって、担当者ごとに過去に行った実施アクションを保持する第一のテーブルと、カテゴリで分類されるカテゴリ変数または数値で表される数値変数を含む営業活動にかかわる情報を保持する第二のテーブルと、担当者の情報を示す第三のテーブルとを備え、第三のテーブルに基づいて、担当者をクラスタリングして、担当者クラスタを作成し、担当者クラスタごとに共通制約条件を第四のテーブルに格納し、第四のテーブルに格納された制約条件に基づいて、前記第一のテーブルの情報から担当者クラスタに含まれる担当者と実施アクションで制約条件に合致しない組合せを除いて、業務活動に関する実施アクションを候補として提示するようにしたものである。

本発明によれば、業務活動において最小の労力で最適な実施アクションを行うための制約条件を決定することができ、それに基づいた業務における実施アクションを行うことにより、業務の現実状況に基づいて適切な実施アクションを行うことのできる業務支援装置および業務支援方法を提供することができる。

業務支援装置の機能構成図である。 業務支援装置のハードウェア・ソフトウェア構成図である。 顧客プロパティテーブルの一例を示す図である。 担当先顧客テーブルの一例を示す図である。 活動トランザクションテーブルの一例を示す図である。 アクション実施未実施顧客情報テーブルの一例を示す図である（その一）。 アクション実施未実施顧客情報テーブルの一例を示す図である（その二）。 顧客条件組合せリストの一例を示す図である。 顧客カテゴリ組合せリストの一例を示す図である。 対象顧客リストの一例を示す図である。 従属担当者クラスタリストの一例を示す図である。 クラスタ内対象顧客アクション実施未実施情報テーブルの一例を示す図である。 担当者クラスタリストの一例を示す図である。 制約条件テーブルの一例を示す図である（その一）。 制約条件テーブルの一例を示す図である（その二）。 実施アクションセット候補テーブルの一例を示す図である。 制約条件を作成する処理を示すフローチャートである（その一）。 制約条件を作成する処理を示すフローチャートである（その二）。 担当者クラスタリストを作成する処理を示すフローチャートである（その一）。 担当者クラスタリストを作成する処理を示すフローチャートである（その二）。 実施アクションを最適化する処理を示すフローチャートである。

以下、本発明に係る実施形態を、図１ないし図１７を用いて説明する。

本実施形態では、営業活動に携わる担当が、各顧客に対して、クーポン発行、ダイレクトメール送付などの営業活動の実施アクションを最適化する業務支援装置を例に採って説明する。

先ず、図１および図２を用いて本発明の一実施形態に係る業務支援装置の構成について説明する。
本実施形態の業務支援装置１００の機能構成は、図１に示されるように、制約条件作成部１０１、担当者クラスタリスト作成部１０２、実施アクション最適化部１０３、顧客条件入力部１１０、実施アクション出力部１１１、制約条件調整部１１２、活動トランザクション入力部１１３、記憶部１２０からなる。

制約条件作成部１０１は、最適な実施アクションを求めるための制約条件を作成する機能部である。なお、制約条件の詳細と具体例は、後述する。担当者クラスタリスト作成部１０２は、実施アクションを求めるために分類される担当者の集まり（担当者クラスタ）のリストを作成する機能部である。なお、担当者クラスタの詳細と具体例は、後述する。実施アクション最適化部１０３は、業務活動としての実施アクションを最適化する機能部である。顧客条件入力部１１０は、営業活動計画立案者１０が営業活動にあたって各顧客の考慮する条件を入力する機能部である。実施アクション出力部１１１は、求められた実施アクションを、営業活動計画立案者１０に対して出力する機能部である。制約条件調整部１１２は、求められた制約条件を営業担当者２０に対して提示してその修正を促す機能部である。活動トランザクション入力部１１３は、営業担当者２０が行った営業活動の情報をトランザクションとして入力する機能部である。記憶部１２０は、データを保持する機能部である。記憶部１２０は、業務支援データベース１３０を保持している。業務支援データベース１３０は、そして、業務支援装置１００が取り扱うデータを格納する各種テーブルを記憶している。なお、業務支援装置１００が使用するテーブルの詳細は、後に説明する。

次に、図２を用いて業務支援装置のハードウェア・ソフトウェア構成について説明する。
業務支援装置１００のハードウェア構成としては、例えば、図２に示されるパーソナルコンピュータのような一般的な情報処理装置で実現される。

業務支援装置１００は、ＣＰＵ（Central Processing Unit）２０２、主記憶装置２０２、ネットワークＩ／Ｆ２０６、表示Ｉ／Ｆ２０８、入出力Ｉ／Ｆ２１０、補助記憶Ｉ／Ｆ２１２が、バスにより結合された形態になっている。

ＣＰＵ２０２は、業務支援装置１００の各部を制御し、主記憶装置２０２に必要なプログラムをロードして実行する。
主記憶装置２０２は、通常、ＲＡＭなどの揮発メモリで構成され、ＣＰＵ２０２が実行するプログラム、参照するデータが記憶される。

ネットワークＩ／Ｆ２０６は、ネットワーク５と接続するためのインタフェースである。

表示Ｉ／Ｆ２０８は、ＬＣＤ（Liquid Crystal Display）などの表示装置２２０を接続するためのインタフェースである。

入出力Ｉ／Ｆ２１０は、入出力装置を接続するためのインタフェースである。図２の例では、キーボード２３０とポインティングデバイスのマウス２３２が接続されている。

補助記憶Ｉ／Ｆ２１２は、ＨＤＤ（Hard Disk Drive）２５０やＳＳＤ（Solid State Drive）などの補助記憶装置を接続するためのインタフェースである。

ＨＤＤ２５０は、大容量の記憶容量を有しており、本実施形態を実行するためのプログラムが格納されている。業務支援装置１００には、制約条件作成プログラム２６１、担当者クラスタリスト作成プログラム２６２、実施アクション最適化プログラム２６３がインストールされている。

制約条件作成プログラム２６１、担当者クラスタリスト作成プログラム２６２、実施アクション最適化プログラム２６３は、それぞれ、制約条件作成部１０１、担当者クラスタリスト作成部１０２、実施アクション最適化部１０３の機能を実現するためのプログラムである。

また、ＨＤＤ２５０には、業務支援データベース１３０が格納されている。

次に、図３ないし図１４を用いて業務支援装置が使用するデータ構造について説明する。
顧客プロパティテーブル３００は、顧客の属性を保持するテーブルであり、図３に示されるように、レコードＩＤ３００ａ、顧客名３００ｂ、業種３００ｃ、地域３００ｄ、年商３００ｅ、従業員数３００ｆの各フィールドを有する。

レコードＩＤ３００ａには、テーブルのレコードを一意的に識別する識別子が格納される。顧客名３００ｂには、顧客の名称が格納される。業種３００ｃには、顧客の従事している事業の種類が格納される。地域３００ｄには、顧客の営業の所在地が格納される。年商３００ｅには、顧客の一年の売り上げが「万円」単位で格納される。従業員数３００ｆには、顧客が雇用している従業員の数が格納される。

なお、顧客プロパティテーブル３００において、顧客の属性の内で、カテゴライズ（分類）ができる要素を、「カテゴリ変数」ということにし、顧客の属性の内で、数値で表される要素を、「数値変数」ということにする。

担当先顧客テーブル３０１は、営業の担当ごとの顧客を保持するテーブルであり、図４に示されるように、レコードＩＤ３０１ａ、担当者ＩＤ３０１ｂ、担当顧客名３０１ｃの各フィールドを有する。

レコードＩＤ３０１ａには、テーブルのレコードを一意的に識別する識別子が格納される。担当者ＩＤ３０１ｂには、担当者を一意的に識別する識別子が格納される。担当顧客名３０１ｃには、担当者ＩＤ３０１ｂに記載された担当者が担当している顧客名が格納される。

活動トランザクションテーブル３０２は、担当者が顧客に対して実際に行った営業活動に関する情報を日付と共に記録したテーブルであり、図５に示されるように、レコードＩＤ３０２ａ、日付３０２ｂ、対象顧客名３０２ｃ、担当者ＩＤ３０２ｄ、実施アクション３０２ｅの各フィールドを有する。

レコードＩＤ３０２ａには、テーブルのレコードを一意的に識別する識別子が格納される。日付３０２ｂには、営業活動の実施アクションを行った日付が格納される。対象顧客名３０２ｃには、実施アクションを行った顧客名が格納される。担当者ＩＤ３０２ｄには、実施アクションを行った担当者のＩＤが格納される。実施アクション３０２ｅには、担当がその顧客に行った具体的な営業活動の内容が格納される。実施アクションは、例えば、「クーポン発行」、「ダイレクトメール送付」、「ダイレクトＥメール送信」、「営業電話架電」、「顧客訪問」、「顧客説明会開催」などがある。

アクション実施未実施顧客情報テーブル３０３は、ある実施アクションを行った顧客、あるいは、その実施アクションを行っていない顧客に関する情報を保持するテーブルであり、図６Ａ、図６Ｂに示されるように、レコードＩＤ３０３ａ、担当者ＩＤ３０３ｂ、担当顧客名３０３ｃ、実施済み担当顧客名３０３ｄ、未実施担当顧客名３０３ｅの各フィールドを有する。

レコードＩＤ３０３ａには、テーブルのレコードを一意的に識別する識別子が格納される。担当者ＩＤ３０３ｂには、実施アクションを行った担当者のＩＤが格納される。担当顧客名３０３ｃには、担当者ＩＤ３０３ｂの担当者が担当する顧客名が格納される。実施済み担当顧客名３０３ｄには、担当顧客名３０３ｃの顧客の内で、ある実施アクションを行った顧客の顧客名が格納される。未実施担当顧客名３０３ｅには、担当顧客名３０３ｃの顧客の内で、ある実施アクションを未だに行っていない顧客の顧客名が格納される。なお、この図６Ａの例では、実施アクションが「クーポン発行」の場合の例を示している。

図６Ｂのアクション実施未実施顧客情報テーブル３０３は、図６Ａのアクション実施未実施顧客情報テーブル３０３から、顧客の内で、顧客の条件から見て今対象としている顧客のみを抜き出したテーブルである。

図６Ｂの例では、顧客の条件として、業種が「建設業」であり、地域が「関西」である顧客「Ａ〜Ｋ」を抜き出している。

顧客条件組合せリスト３０４は、顧客条件の組合せを保持するリストであり、図７に示されるように、レコードＩＤ３０４ａ、条件組合せ３０４ｂの各フィールドを有する。

レコードＩＤ３０４ａには、テーブルのレコードを一意的に識別する識別子が格納される。条件組合せ３０４ｂには、顧客プロパティテーブル３００から求まる顧客の条件組合せが格納される。

顧客条件組合せリスト３０４は、顧客の全ての条件の組合せを網羅的に保持する必要なく、初期設定として、実施アクションの最適化のために問題とする条件の組合せを保持すればよい。

顧客カテゴリ組合せリスト３０５は、顧客条件の内で、カテゴリ変数に関する組合せを保持するリストであり、図８に示されるように、レコードＩＤ３０５ａ、カテゴリ組合せ３０５ｂの各フィールドを有する。レコードＩＤ３０５ａには、テーブルのレコードを一意的に識別する識別子が格納される。カテゴリ組合せ３０５ｂには、ある顧客条件に対して取りうるカテゴリの組合せが格納される。

図８の例では、「業種＊地域」に関する顧客条件組合せリスト３０４のレコードＩＤが「１」の条件組合せにおいて、「業種」と「地域」の取りうる組合せが業種が「建設業」であり、地域が「関西」であるであることが記載されている。ここで、「＊」は、ＡＮＤ条件を意味し、「建設業＊関西」の表記は、（［業種］＝＝“建設業”）＆＆（［地域］＝＝“関西”）を意味している。この表記で、＝＝は、論理式のイコールを、＆＆は、論理式のＡＮＤを意味する。

対象顧客リスト３０６は、ある顧客条件に合致する顧客の顧客名を保持するテーブルであり、図９に示されるように、レコードＩＤ３０６ａ、対象顧客名３０６ｂの各フィールドを有する。

レコードＩＤ３０６ａには、テーブルのレコードを一意的に識別する識別子が格納される。対象顧客名３０６ｂには、ある条件を満足する顧客名が格納される。

図９の例では、業種が「建設業」で、地域が「関西」に該当する顧客の顧客名を保持している。

従属担当者クラスタリスト３０７は、担当者クラスタリストの従属関係を保持するテーブルであり、図１０に示されるように、レコードＩＤ３０７ａ、従属先担当者ＩＤ３０７ｂ、従属担当者クラスタ３０７ｃの各フィールドを有する。

レコードＩＤ３０７ａには、テーブルのレコードを一意的に識別する識別子が格納される。従属先担当者ＩＤ３０７ｂには、従属担当者クラスタリスト３０７の従属先となる担当者のＩＤが格納される。従属担当者クラスタ３０７ｃには、従属する方の担当者クラスタに属する担当者の担当者ＩＤが格納される。

ここで、「担当者クラスタ」と、担当者クラスタにおける従属関係について説明する。
本実施形態の業務支援装置では、制約条件を求める際に、担当者をその顧客との関係においてクラスタリングする。そのときのクラスタリングされた担当者の集合を、「担当者クラスタ」として、数学の集合の記法により、｛ロ，ハ，ニ，ホ，ヘ｝のように表すことにする。

また、図６Ｂのアクション実施未実施顧客情報テーブル３０３において、担当者イの対象顧客は｛Ａ，Ｂ，Ｃ，Ｄ，Ｅ｝、担当者ロの対象顧客は｛Ａ，Ｂ｝となっている。すなわち、担当者イの対象顧客の集合⊇担当者ロの対象顧客の集合となっている。

このように担当者甲の対象顧客の集合が、他の担当者乙の対象顧客の集合を包含しているとき、担当者甲を「従属先担当者」とし、担当者乙を従属担当者とする。そして、従属先担当者甲の従属担当者の集まりを、担当者甲を従属先とする「従属担当者クラスタ」と定義する。例えば、従属担当者クラスタリスト３０７のレコードＩＤ３０７ａが「１」では、従属先担当者が「イ」であり、従属担当者クラスタが｛ロ，ハ，ニ，ホ，ヘ｝であり、各々の担当顧客に対して、上で説明した包含関係があることが、図６Ｂのアクション実施未実施顧客情報テーブル３０３の担当顧客３０３ｃを見ることにより確認できる。

一般には、従属先となる担当者は、従属している担当者よりも顧客を多く抱えており、従属している担当者よりも社内における地位が上である、あるいは、営業成績がよいということが想定される。そして、それに従属する担当者クラスタは、ある上司の部下であるなどの共通の性質を有することが想定される。

クラスタ内対象顧客アクション実施未実施情報テーブル３０８は、ある担当者クラスタに属する個々の担当者における各顧客に対する実施アクションの状況と、数値変数である顧客の年商の情報を付加したテーブルであり、図１１に示されるように、各顧客ごとに、年商と、それぞれの担当者毎に、実施アクションを実施したのか否かの情報を保持する。

クラスタ内対象顧客アクション実施未実施情報テーブル３０８の第１レコードは、顧客プロパティテーブル３００の年商３００ｅに記載されたそれぞれの顧客名「Ａ」、顧客名「Ｂ」、顧客名「Ｃ」、顧客名「Ｄ」、顧客名「Ｅ」の各々の顧客の年商である。

第２レコード以降は、各担当がそれぞれの顧客に対して、実施アクション（図１１の例では、「クーポン発行」）を実施したか、あるいは、担当外であるかを示している。例えば、顧客名「Ａ」の顧客に対して、担当「ロ」は、実施アクション（「クーポン発行」）を実施しており（〇で示す）、担当「ホ」は、顧客名「Ａ」の顧客に対して、実施アクション（「クーポン発行」）を実施しておらず（×で示す）、担当「ハ」は、顧客名「Ａ」の顧客は、担当外（「担当外」で示す）であることを示している。

担当者クラスタリスト３０９は、担当者を共通年商閾値に基づいて分類した情報を保持するテーブルであり、図１２に示されるように、レコードＩＤ３０９ａ、担当者クラスタ３０９ｂ、共通年商閾値ＩＤ３０９ｃの各フィールドを有する。

レコードＩＤ３０９ａには、テーブルのレコードを一意的に識別する識別子が格納される。担当者クラスタ３０９ｂには、共通年商閾値に基づいて分類された担当者クラスタが格納される。共通年商閾値ＩＤ３０９ｃには、担当者クラスタ示す顧客の共通年商閾値が格納される。

ここで、クラスタ内対象顧客アクション実施未実施情報テーブル３０８による担当者のクラスタリングと、共通年商閾値の概念を説明する。

クラスタ内対象顧客アクション実施未実施情報テーブル３０８において、顧客の年商に関して、実施済み（○）と未実施（×）を誤り無く二分する閾値（これを「共通年商閾値」とする）を設定できるかという観点からクラスタリングを行うと、｛ロ，ハ，ニ，ヘ｝と｛ホ｝の二つの担当者クラスタに分割できる。そのとき、担当者｛ロ，ハ，ニ，ヘ｝は、年商の閾値に４００が設定できるので、共通年商閾値が４００として、担当者クラスタリストに追加する。すなわち、閾値４００以下の年商の顧客に対して、｛ロ，ハ，ニ，ヘ｝のいずれも、自分の担当（担当外以外）に対して、実施アクションを実施している。また、｛ホ｝は、閾値が設定できないので，共通年商閾値は空欄（−）として担当者クラスタリストに追加する。

制約条件テーブル３１０は、担当者クラスタごとに、実施アクションと、その制約条件を示したテーブルであり、図１３Ａ、図１３Ｂに示されるように、レコードＩＤ３１０ａ、担当者クラスタ３１０ｂ、対象アクション３１０ｃ、制約条件３１０ｄの各フィールドを有する。

レコードＩＤ３１０ａには、テーブルのレコードを一意的に識別する識別子が格納される。担当者クラスタ３１０ｂには、担当者クラスタリスト３０９により分類された担当者クラスタが格納される。対象アクション３１０ｃには、対象としている実施アクションの種類が格納される。制約条件３１０ｄには、対象アクションを実施するときの制約条件が格納される。

例えば、図１３Ａでは、レコードＩＤ３１０ａが「２」のレコードが示すように、担当者クラスタが｛ロ，ハ，ニ，ヘ｝であり、対象とする実施アクションが、「クーポン発行」のときの制約条件は、業種が「建設業」であり、地域が「関西」であり、年商が、４００万円以下であることを示している。ここでの年商の値は、担当者クラスタリスト３０９の担当者クラスタが｛ロ，ハ，ニ，ヘ｝のときの共通年商閾値ＩＤ３０９ｃの値である。

図１３Ｂは、共通年商閾値が出た後に、担当者にインタビューをして、年商に関する閾値を書き換えたものである。なお、このように、制約条件を書き換える過程は後に説明する。

実施アクションセット候補テーブル３１１は、各々の担当者の実施アクションを実施する顧客とその実施アクションをセットにして、候補として示すテーブルであり、図１４に示されるように、レコードＩＤと、担当者の実施アクションを実施する顧客とその実施アクションごとにペアとなるフィールドを有する。

なお、実施アクションセット候補テーブル３１１の実施アクションのセットは、一つのレコードの中に、図１３Ｂの修正後の制約条件テーブル３１０の制約条件に反するものがあるときには、実施アクションとしては、除外される。

例えば、レコードＩＤが「３」の担当者イの実施先顧客「Ｅ」に対して、実施アクション「クーポン発行」は、顧客「Ｅ」の年商が７００（顧客プロパティテーブル３００の年商３００ｅ）であるため、図１３Ｂの修正後の制約条件テーブル３１０のレコードＩＤ３１０ａが「１」のレコードの制約条件３１０ｄに反することになり、レコードＩＤが「３」のレコードの実施アクションセットの候補は、排除される。

次に、図１５Ａないし図１７を用いて業務支援装置が行う処理について説明する。

先ず、図１５Ａ、図１５Ｂを用いて制約条件を作成する処理について説明する。
先ず、業務支援装置１００は、図５に示した活動トランザクションテーブル３０２から、実施アクションに対する制約条件を作成する対象アクションを取得する（Ｓ１００）。

次に、活動トランザクションテーブル３０２から、対象アクションをキーとして実施アクション３０２ｅを検索し、該当するレコードと図４に示した担当先顧客テーブル３０１から、図Ｅに示したアクション実施未実施顧客情報テーブル３０３を作成する（Ｓ１０１）。

次に、図３に示した顧客プロパティテーブル３００から、図７に示した顧客条件組合せリスト３０４を作成する（Ｓ１０２）。

次に、顧客条件組合せリスト３０４の１行を選択する（Ｓ１０３）。

次に、顧客条件組合せリスト３０４の顧客条件の内から、顧客条件のカテゴリ変数を選択し、値のとりうる組合せを導出して、図８に示した顧客カテゴリ組合せリスト３０５を作成する（Ｓ１０４）。

次に、顧客カテゴリ組合せリスト３０５の１行を選択し、その条件で顧客プロパティテーブル３００を検索して、図９に示した対象顧客リスト３０６を作成する（Ｓ１０５）。

次に、図６Ａに示したアクション実施未実施顧客情報テーブル３０３から、対象顧客リスト３０６に記載の顧客のみ抽出して、図６Ｂに示されるように、アクション実施未実施顧客情報テーブル３０３を再作成する（Ｓ１０６）。

次に、アクション実施未実施顧客情報テーブル３０３のある担当者の担当顧客の集合が、別の担当者の担当顧客の集合を包含するとき、包含している担当者を従属先の担当者とし、包含されている担当者を従属先の担当者の従属担当者クラスタに加え、従属先の担当者とそれに対応する従属担当者クラスタを、図１０に示した従属担当者クラスタリスト３０７に書込む（Ｓ１０７）。

次に、図１２に示した担当者クラスタリスト３０９を作成する処理を実行する（Ｓ１０８）。なお、担当者クラスタリスト３０９を作成する処理については、後に、図１６Ａ、図１６Ｂを用いて詳細に説明する。
次に、担当者クラスタリスト３０９から１行選択する（Ｓ１０９）。
次に、選択した担当者クラスタリスト３０９の各々の担当クラスタの数値変数の共通閾値に従い、図１３Ａに示した制約条件テーブルにレコードを追加する（Ｓ１１０）。

次に、担当者クラスタリスト３０９の担当者クラスタに含まれる一部（ユーザ設定に従う）に、インタビューして、Ｓ１０９で作成した制約条件の成立の可否および数値変数に関する閾値を問いあわせる（Ｓ１１１）。ユーザ設定は、例えば、「担当者クラスタの中の１０％にインタビューする」、「担当者クラスタの中の５０％にインタビューする」などである。
ここで、本実施形態でクラスタリングした意図から、労力軽減のため、担当者クラスタは、全員ではなく、できるだけ少ない人数に問い合わせることが望ましい。

次に、各担当者クラスタからの回答結果を反映して、制約条件テーブルを更新する（例えば、図１３Ａに示した制約条件テーブル→図１３Ｂに示した制約条件テーブル）。

次に、担当者クラスタリスト３０９の全行に、Ｓ１１０〜Ｓ１１２の処理を実行したか否かを判定し（Ｓ１１３）、実行したときには（Ｓ１１３：Ｙｅｓ）、Ｓ１１４に行き、実行していないときには（Ｓ１１３：Ｎｏ）、Ｓ１０８に戻る。

次に、顧客カテゴリ組合せリスト３０５の全行に、Ｓ１０５〜Ｓ１１３の処理を実行したか否かを判定し（Ｓ１１４）、実行したときには（Ｓ１１４：Ｙｅｓ）、Ｓ１１５に行き、実行していないときには（Ｓ１１４：Ｎｏ）、Ｓ１０５に戻る。

次に、顧客条件組合せリスト３０４の全行に、Ｓ１０３〜Ｓ１１４の処理を実行したか否かを判定し（Ｓ１１５）、実行したときには（Ｓ１１５：Ｙｅｓ）、処理を終了し、実行していないときには（Ｓ１１５：Ｎｏ）、Ｓ１０３に戻る。

次に、図１６Ａ、図１６Ｂを用いて担当者クラスタリスト３０９を作成する処理について説明する。これは、図１５ＢのＳ１０８に該当する処理である。
先ず、顧客条件組合せリスト３０４から１行選択する（Ｓ２００）。
次に、選択した顧客条件組合せリスト３０４の数値変数を取得する（Ｓ２０１）。
次に、従属担当者クラスタリスト３０７の１行を選択する（Ｓ２０２）。

次に、各行インデックスに従属担当者クラスタリスト３０７の従属担当者クラスタの各担当者を、各フィールドに、その従属先担当者が担当する顧客を記載した図１１に示すクラスタ内対象顧客アクション実施未実施情報テーブル３０８を作成する（Ｓ２０３）。

次に、クラスタ内対象顧客アクション実施未実施情報テーブル３０８の各顧客フィールドを、選択した数値変数でソートする（Ｓ２０４）。図１１の例では、昇順にソートされている。

次に、クラスタ内対象顧客アクション実施未実施情報テーブル３０８において、対象としているアクション（図１１の例では、「クーポン発行」）を、図６Ｂのアクション実施未実施顧客情報テーブル３０３より、各担当がそれぞれの顧客に実施しているか否かを調べて、各番地の値に実施済み（○）、未実施（×）、担当外を記載する（Ｓ２０５）。

次に、実施済み（○）と未実施（×）を誤り無く二分する（担当外は無視）閾値を設定できる担当者の集合を作って、担当者クラスタとしてクラスタリングする（Ｓ２０６）。
次に、担当者クラスタを一つ選択する（Ｓ２０７）。
次に、実施済み（○）と未実施（×）を誤り無く二分する共通閾値を設定できる否かを判定する（担当外は無視）（Ｓ２０８）。

設定できるときには（Ｓ２０８：Ｙｅｓ）、その担当者クラスタとその共通閾値を、図１２に示される担当者クラスタリスト３０９に追加する（Ｓ２１０）。

設定できないときには（Ｓ２０８：Ｎｏ）、その担当者クラスタを、担当者クラスタリスト３０９に追加する（Ｓ２０９）。このときの共通閾値は、空欄（−）にする。

次に、全担当者クラスタに、Ｓ２０７〜Ｓ２１０の処理を実行したか否かを判定し（Ｓ２１１）、実行したときには（Ｓ２１１：Ｙｅｓ）、Ｓ２１２に行き、実行していないときには（Ｓ２１１：Ｎｏ）、Ｓ２０７に戻る。

次に、従属担当者クラスタリスト３０７の全行に、Ｓ２０２〜Ｓ２１０の処理を実行したか否かを判定し（Ｓ２１２）、実行したときには（Ｓ２１２：Ｙｅｓ）、処理を終了し、実行していないときには（Ｓ２１２：Ｎｏ）、Ｓ２０２に戻る。

次に、図１７を用いて実施アクションを最適化する処理について説明する。
これは、図１５Ａ、図１５Ｂの制約条件を作成する処理が終了し、実際の業務にあった制約条件を作成した後に行われる処理である。

先ず、顧客と担当者と実施アクションのすべての組合せをリストアップして、図１４に示される実施アクションセット候補テーブル３１１を作成する（Ｓ３００）。
次に、図１３Ｂの制約条件テーブル３１０に抵触する組合せのレコードを実施アクションセット候補テーブル３１１から除外する（Ｓ３０１）。

例えば、図１４の例では、レコードＩＤが「３」の担当者イの実施先顧客「Ｅ」に対する条件が適合しないために除外された例を説明した。

次に、実施アクションセット候補テーブルの全行に対して、予測アルゴリズムを用いて期待値を計算する（Ｓ３０２）。これは、例えば、過去の業務に対する実施アクションと、売り上げや利益を関連付けた学習データにより求めることができる。

そして、最大の期待値をとる実施アクションセット候補テーブル３１１のレコードを実施アクションセットして出力し（Ｓ３０３）、営業活動の計画、立案の資料とする。

以上のように本実施形態の業務支援装置によれば営業活動に携わる担当者を、担当する顧客との態様によって、担当者クラスタとしてクラスタリングして、それと数値変数の閾値と対応付けることより、性質の類似する担当者クラスタごとの制約条件を生成することができる。しかも、その制約条件の妥当性を担当者クラスタの一部に確認すれば、最小の労力でその制約条件が業務の実情に適合した制約条件か否かを確認することができるので、業務の実情に即した制約条件に基づいて、業務の実施アクションの計画を立案することが可能になる。

１０…営業活動計画立案者、２０…営業担当者、
１００…業務支援装置、１０１…制約条件作成部、１０２…担当者クラスタリスト作成部、１０３…実施アクション最適化部、１１０…顧客条件入力部、１１１…実施アクション出力部、１１２…制約条件調整部、１１３…活動トランザクション入力部、１２０…記憶部、
３００…顧客プロパティテーブル、３０１…担当先顧客テーブル、３０２…活動トランザクションテーブル、３０３…アクション実施未実施顧客情報テーブル、３０４…顧客条件組合せリスト、３０５…顧客カテゴリ組合せリスト、３０６…対象顧客リスト、３０７…従属担当者クラスタリスト、３０８…クラスタ内対象顧客アクション実施未実施情報テーブル、３０９…担当者クラスタリスト、３１０…制約条件テーブル、３１１…実施アクションセット候補テーブル

Claims (9)

1. 制約条件の下で業務活動に関する実施アクションを提示する業務支援装置であって、
   担当者ごとに過去に行った実施アクションを保持する第一のテーブルと、
   カテゴリで分類されるカテゴリ変数または数値で表される数値変数を含む営業活動にかかわる情報を保持する第二のテーブルと、
   前記担当者の情報を示す第三のテーブルとを備え、
   前記第三のテーブルに基づいて、前記担当者をクラスタリングして、担当者クラスタを作成し、
   前記担当者クラスタごとに共通制約条件を第四のテーブルに格納し、
   前記第四のテーブルに格納された制約条件に基づいて、前記第一のテーブルの情報から前記担当者クラスタに含まれる担当者と実施アクションで前記制約条件に合致しない組合せを除いて、業務活動に関する前記実施アクションを候補として提示することを特徴とする業務支援装置。
2. 前記制約条件が、前記第二のテーブルの数値変数の閾値として定められることを特徴とする請求項１記載の業務支援装置。
3. 前記制約条件が、前記第二のテーブルのカテゴリ変数の組合せにより表現されることを特徴とする請求項１記載の業務支援装置。
4. 前記担当者クラスタに含まれる担当者ごとに、前記第二のテーブルに含まれる数値変数を対応させ、担当者ごとの業務活動の情報を含む第五のテーブルを保持し、
   前記数値変数に従って、各担当者ごとのデータをソートし、前記担当者ごとの業務活動の情報に従って、前記数値変数にかかわる共通閾値を定めて、前記制約条件を前記数値変数にかかわる共通閾値により定めることを特徴とする請求項２記載の業務支援装置。
5. 前記担当者クラスタごとに共通となる制約条件を第四のテーブルに格納した後に、
   前記担当者クラスタに含まれる担当者に対してインタビューした情報に基づいて、前記第四のテーブルを修正することを特徴とする請求項１記載の業務支援装置。
6. 前記第二のテーブルが業務活動に関する顧客の情報を保持するテーブルであることを特徴とする請求項１記載の業務支援装置。
7. さらに、前記第三のテーブルは、担当者ごとに、担当する顧客を保持するテーブルであって、
   前記第三のテーブルを参照し、担当する顧客に基づいて、前記担当者クラスタを作成することを特徴とする請求項１記載の業務支援装置。
8. 制約条件の下で業務活動に関する実施アクションを提示する業務支援装置による業務支援方法であって、
   担当者ごとに過去に行った実施アクションを保持する第一のテーブルと、
   カテゴリで分類されるカテゴリ変数または数値で表される数値変数を含み、業務活動に関する顧客の情報を保持する第二のテーブルと、
   前記担当者ごとに、担当する顧客を保持する第三のテーブルと、
   前記担当者クラスタごとに共通制約条件を保持する第四のテーブルと、
   担当者ごとの業務活動の情報を含む第五のテーブルとを備え、
   前記制約条件が、前記第二のテーブルのカテゴリ変数の組合せにより表現され、
   前記第二のテーブルと前記第三のテーブルに基づいて、担当する顧客に基づいて、前記担当者クラスタを作成するステップと、
   前記担当者クラスタに含まれる担当者ごとに、前記第二のテーブルに含まれる数値変数を対応させ、担当者ごとの業務活動の情報を含む第五のテーブルに記憶するステップと、
   前記第五のテーブルの前記数値変数に従って、各担当者ごとのデータをソートし、前記担当者ごとの業務活動の情報に従って、前記数値変数にかかわる共通閾値を定めて、前記制約条件を前記数値変数にかかわる共通閾値により定めるステップと、
   前記担当者クラスタごとに共通となる制約条件を第四のテーブルに格納するステップと、
   前記第四のテーブルに格納された制約条件に基づいて、前記担当者クラスタに含まれる担当者と実施アクションで前記制約条件に合致しない組合せを除いて、業務活動に関する前記実施アクションを候補として提示するステップとを有することを特徴とする業務支援方法。
9. 前記担当者クラスタごとに共通となる制約条件を第四のテーブルに格納した後に、
   さらに、前記担当者クラスタに含まれる担当者に対してインタビューした情報に基づいて、前記第四のテーブルを修正するステップを有することを特徴とする請求項８記載の業務支援方法。

Images