JP2010218272A - リスク報知システム - Google Patents

Abstract

【課題】ユーザの業務上のリスクを管理し、そのリスク変動をユーザに報知する。
【解決手段】
本発明の一実施の形態である業務支援装置３０は、業務の遂行において発生しうるリスクの影響度と、リスクが現実のものとなる顕在化率とが対応づけられたリスク情報を記憶するリスク記憶部３２と、業務の関連情報と、リスク情報を調整するための調整情報とを対応づけて記憶する調整情報記憶部３８と、業務の関連情報が発生した場合、これを取得する業務関連情報取得部５０と、当該関連情報に対応づけられた調整情報にしたがい、リスク情報を更新するリスク更新部５２と、リスク情報の更新状況に応じて、業務に関連するユーザに対してリスクの変動を報知するユーザ通知部６０とを備える。
【選択図】図２

Description

この発明は、データ処理技術に関し、特に、業務上のリスク変動をユーザに報知する技術に関する。

企業が他会社との取引を開始したり継続したりするために、取引先会社の与信管理をすることは重要である。取引先会社の財務状況が悪化し、または不祥事を起こしてその会社の信用が低下すれば、売掛金を回収できないなどの問題が生じるからである。そのため、各取引先会社の業績や評判等について様々なデータを収集し、それらデータに基づいた取引先に対する与信管理が行われている。

例えば、特許文献１には、会社情報を記憶したデータベースを備える会社情報提供システムにおいて、データベースの各会社データが、この会社の仕入れ先、販売先の関係を持った会社データとリンク付けされているシステムが記載されている。これによると、リンク関係のある会社の情報に更新があるとその情報がユーザに提供されるため、ユーザはリンク関係のある会社の問題を把握できるとしている。

特開２００２−０７４１５６号公報

しかしながら、特許文献１では、ユーザの抱えるリスクをシステムにおいてどのように管理しているかについては開示されていない。単純に情報の更新をトリガにユーザに通知すると、ユーザへの情報通知の数が増大し、かえってユーザの業務効率を低下させることにもなりうる。

本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、ユーザの業務上のリスクを管理し、業務環境の変動に伴うリスク変動をユーザに報知するための技術を提供することにある。

上記課題を解決するために、本発明のある態様のリスク報知システムは、業務の遂行において発生しうるリスクの影響度と、リスクが現実のものとなる顕在化率とが対応づけられたリスク情報を記憶するリスク記憶部と、業務の関連情報と、その関連情報が取得された際、リスク情報を調整するための情報とを対応づけて記憶する調整情報記憶部と、関連情報が発生した場合、これを取得する関連情報取得部と、関連情報が取得された場合、当該関連情報に対応づけられた調整するための情報にしたがい、リスク情報を更新するリスク更新部と、リスク情報の更新状況に応じて、業務に関連するユーザに対してリスクの変動を報知するリスク変動報知部と、を備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、ユーザの業務上のリスクを管理し、業務環境の変動に伴うリスク変動をユーザに報知できる。

本発明の実施の形態である業務支援システムの構成を示す図である。 図１の業務支援装置の機能構成を示すブロック図である。 リスク情報の構造を示す図である。 リスクマップを示す図である。 ユーザ情報の構造を示す図である。 業務関連情報取得部から出力される業務関連情報の構造を示す図である。 調整情報の構造を示す図である。 リスク変動情報の構造を示す図である。 タスク情報の構造を示す図である。 通知メッセージの一例を示す図である。 業務支援装置の動作を示すフローチャートである。 業務支援装置の動作を示すフローチャートである。 第１の変形例における業務支援装置の機能構成を示すブロック図である。 複数のセグメントが設定されたリスクマップを示す。 第２の変形例における業務支援装置の機能構成を示すブロック図である。

本発明の実施の形態について、その構成を説明する前に概要を説明する。
企業の業務担当者、例えば営業担当や契約担当等のライン部門の担当者は、様々なリスクを抱えながら業務を遂行する。例えば、業務担当者の顧客企業の経営状態が悪化すると、その顧客企業への売掛債権の回収が困難になりまた遅延することがある。また、業務担当者が社内規定に違反した手順で業務を進めている場合、将来的に問題が発生することもある。

業務担当者は、日々の業務に追われており、自身の抱えるリスクの大きさを把握することは困難である。そこで、業務担当者は、自身の抱えるリスクを確認し、そのリスクの大きさに応じた適切なアクションを実行するために、顧客企業の信用度合いを自社のリスク管理担当者に問い合わせることがある。

しかし、企業の経営状況は刻々と変化し、それに伴って顧客企業の信用度合いも刻々と変化するため、業務担当者が抱えるリスクの大きさは刻々と変化する。したがって、リスク管理担当者にとっても業務担当者が抱えるリスクの大きさを逐次把握することは困難である。また、業務担当者が顧客企業へのアクションを行うたびにリスク管理担当者に問い合わせをすると、リスク管理担当者の負担が増大するとともに、業務担当者にとっても顧客企業に対するアクションを実施するまでに時間を要してしまう。

以下提案する業務支援システムにおいては、業務担当者の抱えるリスクを管理し、業務環境の変動に伴いリスクの大きさを逐次更新する。そして、そのリスク変動を適宜業務担当者に通知する。これにより、業務担当者は、リスク変動を認識して、顧客企業に対する迅速なアクションを実行できる。

また、この業務支援システムにおいては、リスク変動を業務担当者に通知する際に、そのリスク変動に対応するためにユーザが実行すべき作業内容（以下、適宜「タスク」とも呼ぶ。）も通知する。これにより、業務担当者は、リスク変動に応じて、顧客企業に対する適切なアクションを実行しやすくなる。

図１は、本発明の実施の形態である業務支援システムの構成を示す。この業務支援システム１００は、システム・インテグレータ（以下、単に「ＳＩ」と呼ぶ。）企業に設置された業務支援装置３０と、ユーザ端末１０で総称されるユーザＡ端末１０ａ、ユーザＢ端末１０ｂ、ユーザＣ端末１０ｃと、リスク管理担当者端末１２と、顧客評価ＤＢ１６と、業務遂行状況ＤＢ１８と、社内規程ＤＢ２０とを含む。また、ＳＩ企業の社外に設置された顧客環境ＤＢ１４をさらに含む。これらの各装置は、図１で示すように、ＬＡＮ・ＷＡＮ・インターネット等、公知の通信手段を介して、適宜相互に接続される。

業務支援装置３０は、システムの開発や営業を業務として実行する業務担当者が抱えるリスク（以下、適宜「ユーザリスク」とも呼ぶ。）を管理し、業務担当者の業務（以下、適宜「ユーザ業務」とも呼ぶ。）を支援する。業務支援装置３０の詳細な機能構成は後述する。ユーザ端末１０は業務担当者によって操作される一般的なＰＣ（Personal Computer）であり、リスク管理担当者端末１２はリスク管理担当者によって操作される一般的なＰＣである。

顧客環境ＤＢ１４は、様々な企業のビジネス環境を示す属性、例えば経営状況、株価情報、格付け情報等について社外で設定されたデータ（以下、適宜「顧客環境情報」とも呼ぶ。）を記憶するデータベースである。顧客環境ＤＢ１４には、様々なニュース記事、市場情報、決算資料等のデータを保持する複数のデータベースサイトや、これらの情報を公開する複数のウェブサイトが含まれてもよい。顧客評価ＤＢ１６は、開発中のシステムの納入先企業や、提案中のシステムの提案先企業等の顧客企業に対して自社で設定した属性、例えば与信限度額や業務上の注意事項等のデータ（以下、適宜「顧客評価情報」とも呼ぶ。）を記憶するデータベースである。

業務遂行状況ＤＢ１８は、ユーザ業務の遂行状況を示すデータ（以下、適宜「業務遂行状況情報」と呼ぶ。）を記憶するデータベースである。例えば、システム開発プロジェクトの進捗状況や開発費用の状態、システム提案プロジェクトの提案状況や提案価格の状態等を保持する。社内規程ＤＢ２０は、システム・インテグレータ企業内で定められた、望ましい業務遂行のあり方を示す規定のデータ（以下、適宜、「社内規定情報」と呼ぶ。）を記憶するデータベースである。例えば、システム開発や契約において遵守すべき手順や期間等を定めた社内規定情報を保持する。なお、顧客環境ＤＢ１４、顧客評価ＤＢ１６、業務遂行状況ＤＢ１８、社内規程ＤＢ２０を総称する場合、「外部情報ＤＢ」と呼ぶこととする。

詳細は図６に関連して後述するが、顧客環境情報の更新情報、顧客評価情報の更新情報、業務遂行状況情報の更新情報、および社内規程情報の更新情報は、業務支援システム１００により取得される。そして、業務支援システム１００において、各更新情報は共通フォーマットの業務関連情報に変換され、ユーザリスクの更新に使用される。なお、業務関連情報への変換の際、顧客環境情報の更新情報に基づく業務関連情報にはそのカテゴリとして「顧客環境属性」が設定され、顧客評価情報の更新情報に基づく業務関連情報にはそのカテゴリとして「顧客評価属性」が設定される。また、業務遂行状況情報の更新情報に基づく業務関連情報にはそのカテゴリとして「業務遂行状況」が設定され、社内規程情報の更新情報に基づく業務関連情報にはそのカテゴリとして「社内規定」が設定される。

図２は、図１の業務支援装置３０の機能構成を示すブロック図である。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

業務支援装置３０は、各種情報を記憶する記憶領域に関する機能ブロックとして、リスク記憶部３２と、リスク変動記憶部３４と、変換情報記憶部３６と、調整情報記憶部３８と、タスク記憶部４０と、重要情報記憶部４２と、ユーザ情報記憶部４４とを備える。また、業務支援装置３０は、ユーザインタフェース処理および通信処理を含む各種データ処理を実行する機能ブロックとして、ユーザ情報受付部４８と、業務関連情報取得部５０と、リスク更新部５２と、リスク変動判定部５４と、タスク特定部５６と、通知データ設定部５８と、ユーザ通知部６０とを備える。

リスク記憶部３２は、ユーザリスクについて、リスク影響度とリスク顕在化率とが対応づけられたデータ（以下、適宜「リスク情報」とも呼ぶ。）を記憶する。リスク影響度はＲＣＭ（Risk Control Matrix）のデータ項目における影響度と、リスク顕在化率はＲＣＭのデータ項目における発生頻度と同一の位置づけである。以下、リスク影響度とリスク顕在化率について詳述する。

リスク影響度は、ユーザリスクが現実のものとなった際にＳＩ企業に与える影響の大きさを示す値である。ＳＩ企業は通常、多くのシステム開発プロジェクトやシステム提案プロジェクトを同時進行させており、すなわち多くのユーザ業務が各担当者によって分散実行されている。これらのユーザ業務の中には、企業の浮沈を左右する重大なものもあれば実験的なものもあり、ユーザリスクが現実のものとなった際の影響の大きさはユーザ業務ごとに異なる。本実施の形態では、リスク影響度の初期値は、リスク管理担当者によるＲＣＭ設定時の値であり、重要な顧客企業がかかわるユーザ業務や、予算額の大きなユーザ業務ほど、リスク影響度が高くなるように設定される。

リスク顕在化率は、ユーザリスクが現実のものとなる可能性の高さを示す値である。リスク顕在化率の初期値も、リスク管理担当者によるＲＣＭ設定時の値である。リスク顕在化率が高いユーザ業務ほど業務上のトラブルが発生する可能性が高いため注意が必要である。リスク影響度とリスク顕在化率との両方が高いユーザ業務は、業務上のトラブルの発生確率およびその影響が大きいため、厳重な管理のもとに遂行される必要がある。

図３は、リスク情報の構造を示す。同図では、ユーザ業務の識別情報である業務ＩＤに、各ユーザ業務についてのリスク影響度とリスク顕在化率とが対応づけられている。例えば、ユーザ業務Ｂはリスク影響度が大きいもののリスク顕在化率が低く抑えられており、重要な業務であるが上手にリスク管理なされていることを示している。一方、ユーザ業務Ｃはリスク顕在化率が高いがリスク影響度は低いため、トラブルが発生してもその影響は限定的であることを示している。

図４は、リスク影響度とリスク顕在化率とを変数とする座標系、言い換えれば、リスク影響度とリスク顕在化率とを２軸とする２次元平面（以下、適宜「リスクマップ」とも呼ぶ。）を示す。同図のリスクマップにおいては、ユーザ業務が左下側に位置するほど安全であり、右上側に位置するほど危険であることを意味する。このリスクマップには、図３に示すユーザ業務Ａ〜Ｃそれぞれの位置座標がプロットされており、最も危険なユーザ業務はＡであると把握できる。このように、リスクマップが設定されることにより、ユーザリスクの状態、すなわちユーザリスクの絶対的な大きさ、および、他のユーザリスクとの相対的な関係が可視化される。したがって、業務担当者は自身の抱えるリスクの大きさを容易に把握でき、リスク管理担当者は複数のユーザ業務のうち特に注意すべきユーザ業務を容易に把握できる。図２に戻る。

ユーザ情報記憶部４４は、ユーザリスクの変動に応じてそのリスク変動を通知するべき業務担当者の属性情報（以下、適宜「ユーザ情報」とも呼ぶ。）を記憶する。ユーザ情報受付部４８は、ユーザ端末１０から送信されたユーザ情報を受信して、そのユーザ情報をユーザ情報記憶部４４に記憶させる。

図５は、ユーザ情報の構造を示す。同図の「ユーザ端末情報」欄には、ユーザ端末１０を識別するための情報が記録される。ユーザリスクの変動をユーザ端末１０に通知するために必要となるＩＰアドレス等のネットワーク情報を含めて記録されることが望ましい。「業務ＩＤ」欄には、ユーザ業務の識別情報が記録される。「通知時刻」欄には、業務担当者がユーザリスクの変動通知を受けたい時刻が記録される。「カテゴリ優先度」は、後述する業務関連情報の情報カテゴリそれぞれについて、通知の優先度が記録される。図２に戻る。

業務関連情報取得部５０は、顧客環境ＤＢ１４に保持された顧客環境情報の更新状況を定期的にポーリングし、顧客環境情報に更新があると、その更新情報を顧客環境ＤＢ１４から取得する。同様に、顧客評価情報の更新情報を顧客評価ＤＢ１６から取得し、業務遂行状況情報の更新情報を業務遂行状況ＤＢ１８から取得し、社内規程情報の更新情報を社内規程ＤＢ２０から取得する。業務関連情報取得部５０は、後述する変換情報記憶部３６を参照して、外部情報ＤＢから取得した各種情報を適宜変換し、変換後の情報を業務関連情報としてリスク更新部５２に出力する。

図６は、業務関連情報取得部５０から出力される業務関連情報の構造を示す。「顧客名」フィールドには、業務関連情報に関係する顧客名が設定される。「業務ＩＤ」フィールドには、業務関連情報が影響を及ぼすユーザ業務の識別情報が設定される。ひとつの業務関連情報が複数のユーザ業務に影響を及ぼす場合には、複数のユーザ業務のＩＤが設定される。「情報カテゴリ」フィールドには、更新情報を取得した外部情報ＤＢに応じた情報が設定される。「変動項目」フィールドには、格付けや売上高等、更新情報においてその変動が記録されたデータ項目名が設定される。「変動内容」フィールドには、変動項目における変動の内容が設定される。図２に戻る。

変換情報記憶部３６は、業務関連情報取得部５０から参照される各種テーブルを記憶する。このテーブルは、業務関連情報取得部５０において、外部情報ＤＢから取得した各種情報を、図６で示した共通形式の業務関連情報に変換する際に参照される。例えば、ＳＩ企業の顧客名と業務ＩＤとが対応づけられた顧客業務対応テーブルや、業務関連情報において設定されうる変動項目と各変動項目において設定されうる変動内容とが対応づけられた変動特定テーブルや、類義語が対応づけられた類義語定義テーブルや、最新の社内規程情報が記録された社内規定テーブルが含まれる。

業務関連情報取得部５０において、顧客環境ＤＢ１４から顧客環境情報の更新情報を取得して、その更新情報に対応する業務関連情報を設定する処理を説明する。業務関連情報取得部５０は、形態素解析や構文解析等、公知の文書データ解析技術を使用して、更新情報から名詞句を抽出する。その他の方法としては、「企業破綻」や「倒産」等の予め定められたキーワードによる文字列検索を実行して、そのキーワードに合致する文字列を抽出してもよい。業務関連情報取得部５０は、顧客業務対応テーブルを参照して、抽出した名詞句の中から特定される顧客名を顧客名フィールドに設定し、その顧客名により特定される業務ＩＤを業務ＩＤフィールドに設定する。また、変動特定テーブルを参照して、抽出した名詞句の中から特定される変動項目名を変動項目フィールドに設定し、同様に特定される変動内容を変動内容フィールドに設定する。また、情報カテゴリフィールドには、「顧客環境属性」を常時設定する。なお、業務関連情報取得部５０は、類義語定義テーブルを適宜参照して類義語を同一視し、また適宜変換することにより、様々な更新情報における語句の揺らぎや表現の揺らぎを吸収する。

業務関連情報取得部５０は、顧客評価ＤＢ１６の更新情報および業務遂行状況ＤＢ１８の更新情報についても、顧客環境情報の更新情報と同様に変換処理をしてもよい。本実施の形態においては、顧客評価ＤＢ１６および業務遂行状況ＤＢ１８はともにＳＩ企業内のＤＢであるため、更新情報が業務関連情報の形式で設定されていることとし、変換処理は不要であることとする。なお、それぞれの情報カテゴリには、「顧客評価属性」と「業務遂行状況」とが設定される。

業務関連情報取得部５０は、社内規程ＤＢ２０から社内規定情報の更新情報を取得すると、変換情報記憶部３６の社内規定テーブルを更新する。業務関連情報取得部５０は、業務遂行状況ＤＢ１８から業務遂行状況情報の更新情報を取得したとき、社内規定テーブルを参照して、更新情報の変動項目および日付関係などの変動内容が社内規定に違反していないかを判定する。違反している場合、その更新情報を業務関連情報として出力する際に、その情報カテゴリを「社内規定」に設定する。

調整情報記憶部３８は、リスク記憶部３２において記憶されたリスク情報を調整するためのデータ（以下、適宜「調整情報」とも呼ぶ。）を記憶する。図７は、調整情報の構造を示す。同図の「業務関連情報」欄には、業務関連情報の変動項目と変動内容とが対応づけて記録される。「影響度調整値」欄にはリスク影響度の増減値が記録され、「顕在化率調整値」欄には、リスク顕在化率の増減値が記録される。なお、「業務関連情報」欄には、顧客名や情報カテゴリがさらに設定されてもよい。この場合、顧客や情報カテゴリごとにリスク情報を細かく調整できる。図２に戻る。

リスク更新部５２は、調整情報記憶部３８を参照して、業務関連情報取得部５０から出力された業務関連情報と対応づけられた影響度調整値と顕在化率調整値とを取得する。そして、リスク記憶部３２にアクセスして、リスク情報において業務関連情報の業務ＩＤと対応づけられたリスク影響度とリスク顕在化率とのそれぞれを、影響度調整値と顕在化率調整値とにより更新する。例えば、業務関連情報が格付けのＡＡからＢＢへの変化を示すとき、リスク顕在化率を０．１５増加させる。また、業務関連情報が業務予算の３０％増加を示すとき、リスク影響度を１５増加させ、かつ、リスク顕在化率を０．１増加させる。

リスク更新部５２は、業務関連情報によってリスク情報を更新した際、リスク情報の更新状態を示すデータ（以下、適宜「リスク変動情報」とも呼ぶ。）をリスク変動記憶部３４に逐次記憶させる。図８は、リスク変動情報の構造を示す。同図の「更新ＩＤ」欄には、リスク情報の更新処理の識別情報が記録される。「更新日時欄」には、リスク情報の更新日時が記録される。「業務関連情報」欄には、顧客名と情報カテゴリと変動項目と変動内容とが対応づけて記録される。「影響度変動幅」欄および「顕在化率変動幅」欄には、リスク情報の更新によるリスク影響度の変動幅およびリスク顕在化率の変動幅とがそれぞれ記録される。図２に戻る。

リスク変動判定部５４は、所定の判定タイミングになったことを検出すると、リスク変動記憶部３４に記憶されたリスク変動情報を参照し、ユーザリスクの変動状況に応じて、業務担当者にユーザリスクの変動を通知すべきか否かを判定する。リスク変動判定部５４は、ユーザリスクの変動を通知すべきと判定した業務の業務ＩＤと、そのリスク変動を生じさせた業務関連情報の更新ＩＤとを対応づけてタスク特定部５６に出力する。判定タイミングは、業務支援装置３０の設計において予め定められた任意の時刻でよく、１日あたり１回でもよく、１日あたり複数回でもよい。

リスク変動判定部５４における判定処理を詳細に説明する。リスク変動判定部５４は、各ユーザ業務について判定の日時データを記録する日時記録テーブルを保持する。特定のユーザ業務についてユーザリスクの変動を通知すべきと判定した際には、日時記録テーブルにおけるそのユーザ業務の日時データを現在日時で更新する。リスク変動判定部５４は、判定処理を開始する際、各ユーザ業務について日時記録テーブルに記録された日時を第１時点、現在日時を第２時点として特定する。変形例として、第１時点には、常に現在日時より所定間隔前、例えば３日前が設定されてもよく、前回の判定処理開始日時が設定されてもよい。第２時点にも、第１時点より後であれば任意の時点が設定されてよい。

リスク変動判定部５４は、リスク変動情報にアクセスして、第１時点から第２時点までの影響度変動幅を合算するとともに顕在化率変動幅を合算し、所定の重みづけ係数に基づき、それぞれの合算値の線形和（以下、適宜「総リスク変動値」とも呼ぶ。）を算出する。例えば、図３で示したように、リスク影響度が０から１００までの値をとり、リスク顕在化率が０から１までの値をとるときには、リスク影響度の係数を１、リスク顕在化率の係数を１００としてもよい。この場合、図８のリスク変動情報について業務ＩＤ「Ａ」の総リスク変動値は、１×１５＋１００×（０．１５＋０．１）＝４０となる。

リスク変動判定部５４は、総リスク変動値が所定の閾値以上であるとき、業務担当者にユーザリスクの変動を通知すべきと判定する。この閾値は、業務担当者にユーザリスクの変動を通知してアクションを実行させるべきユーザリスクの変動幅であり、国の経済状態や自社・顧客企業の経営状態、自社におけるリスク許容度等に応じて定まる。具体的な値については、企業の知見や、業務支援システム１００を使用した実験により適切な値が決定されてよい。リスク変動判定部５４は、ユーザリスクの変動を通知すべきと判定したユーザ業務の業務ＩＤと、リスク変動情報においてその業務ＩＤと対応づけられ、第１時点から第２時点までに存在する１以上の更新ＩＤとを出力する。

タスク記憶部４０は、業務関連情報と、その業務関連情報に伴って発生したリスク変動に対してユーザが実行すべきタスクとが対応づけられたデータ（以下、適宜「タスク情報」とも呼ぶ。）を記憶する。図９は、タスク情報の構造を示す。同図の「業務関連情報」欄には、業務関連情報の変動項目と変動内容とが対応づけて記録されている。なお、顧客名や情報カテゴリがさらに設定されてもよい。この場合、顧客や情報カテゴリごとに異なるタスクを業務担当者に通知できる。図２に戻る。

タスク特定部５６は、リスク変動記憶部３４のリスク変動情報を参照して、リスク変動判定部５４から通知された１以上の更新ＩＤそれぞれに対応づけられた業務関連情報を取得する。タスク特定部５６は、タスク記憶部４０のタスク情報を参照し、各業務関連情報に対応づけられたタスクを取得する。タスク特定部５６は、リスク変動判定部５４から出力された業務ＩＤと、各更新ＩＤをもとに特定した業務関連情報およびタスクとを対応づけて通知データ設定部５８に出力する。

通知データ設定部５８は、タスク特定部５６から出力されたデータに基づいて、ユーザリスクの変動を業務担当者に通知するためのデータ（以下、適宜「通知メッセージ」とも呼ぶ。）を設定する。具体的には、タスク特定部５６から出力された業務ＩＤ、業務関連情報、タスクについて、その業務ＩＤで特定されるユーザ業務に対する通知メッセージとして、業務関連情報とタスクとを対応づけて設定する。

図１０は、通知メッセージの一例を示す。通知データ設定部５８は、通知メッセージ８０のデータとして、１以上の業務関連情報８２を設定し、各業務関連情報８２に対応づけてタスク８４を設定する。この業務関連情報８２とタスク８４とが対応づけられた一組を、適宜「単位メッセージ」と呼ぶこととする。なお、通知メッセージのデータ形式に制限はなく、例えばプレーンテキスト、ＨＴＭＬ、ＸＭＬ等様々な形式で設定されてよい。

通知データ設定部５８は、ユーザ情報記憶部４４のユーザ情報を参照して、ユーザ業務ごとに設定した通知メッセージを、同一の業務ＩＤが設定された業務担当者の分だけ複製する。この際に、各業務担当者が設定したカテゴリ優先度にしたがって、通知メッセージにおける単位メッセージの設定状態を適宜変更する。典型的には、高いカテゴリ優先度が指定された業務関連情報に関する単位メッセージほど、業務担当者から視認しやすい態様となるよう設定する。このように、通知データ設定部５８は、業務担当者ごとの通知メッセージを作成して、そのユーザＩＤとともにユーザ情報記憶部４４に出力する。

例えば、図１０の（ａ）は、図５の山田太郎への通知メッセージを示している。山田太郎は、顧客環境属性および顧客評価属性について高い優先度を指定しているため、顧客環境属性に関する単位メッセージ８６が、業務遂行状況に関する単位メッセージ８６よりも上位に設定されている。図１０の（ｂ）は、図５の川田花子への通知メッセージを示している。川田花子も、カテゴリ優先度の指定が山田太郎と同様であるため、顧客環境属性に関する単位メッセージ８６が、社内規定に関する単位メッセージ８６よりも上位に設定されている。図１０の（ｃ）については後述する。

重要情報記憶部４２は、業務関連情報取得部５０において出力されうる業務関連情報のうち、特に重要であると想定される情報（以下、適宜「重要情報」とも呼ぶ。）を予め記憶する。この重要情報は、典型的にはリスク管理担当者によって設定されるが、各業務担当者によって設定されてもよい。この重要情報は、情報カテゴリ単位で設定されてもよく、変動項目単位で設定されてもよく、変動項目および変動内容単位で設定されてもよい。さらに、顧客名を加えて設定されてもよい。

通知データ設定部５８は、重要情報として設定された業務関連情報に関する単位メッセージ８６については、業務担当者によって設定されたカテゴリ優先度よりも優先して通知メッセージに配置する。図１０の（ｃ）は、重要情報として、「変動項目＝未入金」が設定されたとき、図１０の（ｂ）の通知メッセージについてその単位メッセージが再配置された状態を示している。図２に戻る。

ユーザ通知部６０は、通知データ設定部５８から出力されたデータに基づいて、適宜、通知メッセージを業務担当者に通知する。通知メッセージのデータを電子メールや、ＩＭ（Instant Messenger）のデータに設定して、業務担当者に通知してもよい。具体的には、ユーザ情報記憶部４４のユーザ情報を参照して、通知データ設定部５８から出力されたユーザＩＤに対応づけられた通知時刻を特定する。そして、現在時刻がその通知時刻となったことを検出したとき、ユーザ情報のユーザ端末情報を参照して、ユーザＩＤで特定される業務担当者のユーザ端末１０に対して通知メッセージのデータを送信する。

以上の構成による動作を以下説明する。
図１１（ａ）は、業務支援装置３０の動作を示すフローチャートである。業務関連情報取得部５０は、外部情報ＤＢを定期的にポーリングする。その際に、外部情報ＤＢに記憶された情報の更新が検出されなければ（Ｓ１０のＮ）、次回のポーリングまで待機する。外部情報ＤＢにおける情報の更新が検出されると（Ｓ１０のＹ）、業務関連情報取得部５０はその更新情報を取得し、変換情報記憶部３６を参照して更新情報を適宜変換する。そして、更新情報そのものまたは変換後データを業務関連情報として出力する（Ｓ１２）。リスク更新部５２は、調整情報記憶部３８を参照し、リスク記憶部３２に記憶されたリスク情報を業務関連情報に応じて更新するとともに、その更新情報をリスク変動記憶部３４に記憶させる（Ｓ１４）。

図１１（ｂ）は、業務支援装置３０の動作を示すフローチャートである。リスク変動判定部５４は、所定の判定タイミングとなったことを検出すると、リスク変動記憶部３４を参照してリスク変動の大きさを特定する。その大きさが所定の閾値未満であれば（Ｓ２０のＮ）、次回の判定タイミングまで待機する。その大きさが所定の閾値以上であるとき（Ｓ２０のＹ）、タスク特定部５６は、タスク記憶部４０を参照して、そのリスク変動を生じさせた業務関連情報と対応づけられたタスクを特定する（Ｓ２２）。通知データ設定部５８は、ユーザ情報記憶部４４を参照して、適宜、業務関連情報とタスクとが対応づけて設定された通知メッセージを作成する（Ｓ２４）。ユーザ通知部６０は、ユーザ情報記憶部４４を参照して、業務担当者により設定された通知時刻となるのを待つ（Ｓ２６のＮ）。通知時刻になると（Ｓ２６のＹ）、ユーザ通知部６０は、通知メッセージをユーザ端末１０に送信する（Ｓ２８）。

以上説明した業務支援装置３０によれば、社内・社外における様々な種類の情報、例えば顧客環境情報、顧客評価情報、業務遂行状況情報、社内規程情報の更新に伴うユーザリスクの変動を管理できる。ひとつのカテゴリの情報からは小さなリスク変動しか生じない場合であっても、他のカテゴリの情報によるリスク変動とあわせれば、ユーザリスク全体としては大きな変動が生じる場合もある。業務支援装置３０においては、様々な種類の情報がリスク変動の要因として扱われ、ユーザ業務のリスク変動を適切に管理できる。また、ユーザリスクがリスク影響度とリスク顕在化率との２軸で管理されることにより、ユーザリスクの実際の危険度を各担当者が把握しやすくなる。

また、業務支援装置３０によれば、ユーザリスクが大きく変動すると、その変動を生じさせた業務関連情報と、その変動に応じて業務担当者が実施すべきタスクとが業務担当者に報知される。この報知は、業務担当者の要求をトリガとするリクエスト・レスポンス型ではなく、ユーザリスクの変動をトリガとするプッシュ型であり、自律的な情報配信が実現される。これにより、業務担当者は、自身の抱える業務のリスク変動を把握できるとともに、とるべきアクションが示唆されるため、適切なアクションを迅速に行うことができる。このように、業務支援装置３０は、ホテルのコンシェルジュが利用客に対して適切なアドバイスをするように、企業の業務担当者による業務遂行を支援する。すなわち、現在のビジネス状況に応じた適切なアクションを業務担当者に示唆する。

なお、図９で記載したように、業務担当者に通知されるタスクには、顧客企業のビジネス状況におけるネガティブな変動に対応するためのタスクだけでなく、売上高の増加、株価の上昇、与信限度額の増加等、ポジティブな変動に対応するためのタスクもある。言い換えれば、業務支援装置３０は、ユーザリスクが安全サイドに変動、すなわち小さくなる場合には、顧客企業に対する積極的な営業や提案を業務担当者に示唆する。

さらにまた、業務支援装置３０によれば、業務担当者により設定されたカテゴリ優先度に応じた態様で、通知メッセージがユーザ端末１０に送信される。これにより、業務担当者が興味あるカテゴリの業務関連情報ほど、視認しやすい態様で通知メッセージに設定される。また、業務担当者によって他のカテゴリよりも優先度が低く設定されたカテゴリの業務関連情報であっても、重要情報として設定されていれば、優先して通知メッセージに設定される。これにより、リスク管理担当者が重要な情報として予め想定した業務関連情報については、業務担当者の指定にかかわらず他の業務関連情報よりも優先して取り扱われ、視認しやすい態様で通知メッセージに設定される。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。

第１の変形例を説明する。上述の実施の形態においては、リスク影響度の差分とリスク顕在化率の差分との重み付けされた合計値が所定の閾値以上であるとき、ユーザリスクの変動を業務担当者に報知することが決定された。変形例においては、既述したリスクマップ上でのユーザ業務の位置座標の変化に応じて、ユーザリスクの変動を業務担当者に報知することが決定されてもよい。

図１２は、第１の変形例における業務支援装置３０の機能構成を示すブロック図である。業務支援装置３０は、実施の形態で説明した機能ブロックに加えて、リスクマップ設定部６２とリスクマップ記憶部６４とをさらに含む。リスクマップ設定部６２は、ユーザリスクの大きさに応じて複数のセグメントが設定されたリスクマップにおいて、各ユーザ業務の位置座標をプロットし、そのリスクマップをリスクマップ記憶部６４に記憶させる。そして、リスク更新部５２によるリスク記憶部３２のリスク情報更新を検出したとき、その更新内容に応じて、ユーザ業務の位置座標を逐次更新する。

図１３は、複数のセグメントが設定されたリスクマップを示す。同図においては、ユーザ業務Ａの位置座標が、（リスク影響度＝６０，リスク顕在化率＝０．４５）から（リスク影響度＝７５，リスク顕在化率＝０．７）に変化している。そして、この変化に伴って、ユーザ業務Ａの位置座標が存在するセグメントも変化している。リスク変動判定部５４は、所定の判定タイミングにおいて、第１時点のリスクマップと第２時点のリスクマップとを参照して、リスクマップ上の位置座標が一のセグメントから別のセグメントに変化したユーザ業務を特定する。そして、リスクマップ上の位置座標が一のセグメントから別のセグメントに変化したユーザ業務について、そのリスク変動を業務担当者に通知すべきと判定する。図１２のその他の機能ブロックについては、実施の形態と同様である。

なお、セグメントの数やその値幅は、企業の知見や業務支援システム１００を使用した実験等に基づいて適宜決定されればよい。本変形例によれば、ユーザ業務の位置座標が存在するセグメントの変動を契機に、言い換えれば、リスク影響度および／またはリスク顕在化率が所定の閾値以上または所定の閾値未満となったことを契機に、そのリスク変動を業務担当者に報知できる。差分幅で判定した実施の形態とは異なり、リスク情報の現在値で判定するため、わずかなリスク変動であっても、企業の経験上、危険なセグメントになった場合には、業務担当者にそのリスク変動と実行すべきタスクとが報知される。

なお、ユーザ業務の位置座標が、所定の第１セグメントから所定の第２セグメントに変動したことを条件としてそのリスク変動を報知してもよい。また、本変形例においては、同一セグメント内でのリスク情報の変化はリスク変動報知の対象とならないが、差分幅を判定の基準とする実施の形態の判定方法と適宜組み合わされてもよく、双方の判定によるメリットが享受できる。

第２の変形例を説明する。上述の実施の形態においては、ユーザ情報記憶部４４に登録されたユーザ情報を使用して、リスク変動を通知する業務対象ユーザが決定された。変形例においては、業務担当者が現在遂行中の業務を業務支援装置３０において動的に推定して、その業務のリスク変動と実行すべきタスクとを業務担当者に報知してもよい。

図１４は、第２の変形例における業務支援装置３０の機能構成を示すブロック図である。業務支援装置３０は、実施の形態におけるユーザ情報受付部４８とユーザ情報記憶部４４とに代えて、想定業務記憶部６６と表示情報検出部６８と業務推定部７０とを含む。想定業務記憶部６６は、ユーザ端末１０に表示される情報と、その情報が表示された際に業務担当者が遂行していると想定される業務とを対応づけて記憶する。例えば、ユーザ端末１０に表示される情報の識別情報（以下、適宜「表示情報ＩＤ」とも呼ぶ。）として、ウェブページのＵＲＬや、接続先装置のＩＰアドレス等を記憶する。さらに、そのウェブページが表示されたとき、または、接続先装置と接続されたときに、業務担当者によって遂行中であると想定される業務のＩＤを、上述した表示情報ＩＤとを対応づけて記憶する。

表示情報検出部６８は、業務担当者が業務遂行中のユーザ端末１０から表示情報ＩＤを取得する。なお、表示情報検出部６８は、プロキシサーバとして機能して、ユーザ端末１０と接続先装置間で送受される情報を中継してもよく、その中継の際に表示情報ＩＤを取得してもよい。業務推定部７０は、表示情報ＩＤをもとに、業務担当者が遂行中の業務を推定する。具体的には、想定業務記憶部６６を参照して、表示情報検出部６８において取得された表示情報ＩＤと対応づけられた業務ＩＤを特定する。リスク変動判定部５４は、リスク変動記憶部３４のリスク更新情報を参照して、業務推定部７０において特定された業務ＩＤで特定されるユーザ業務について、そのユーザリスクの変動状況に応じて、そのリスク変動をユーザ端末１０に通知すべきか否かを判定する。

本変形例によれば、ユーザ情報の登録がない場合でも、業務担当者の遂行中の業務を動的に検出して、その業務のリスク変動と実行すべきタスクとを業務担当者に報知でき、その業務遂行を支援できる。なお、業務支援装置３０は、ユーザ情報受付部４８とユーザ情報記憶部４４をさらに含んでもよい。この場合、ユーザ情報において指定された通知時刻以外であっても、業務担当者の遂行中業務のリスク変動と実行すべきタスクとを業務担当者に報知できる。

第３の変形例を説明する。通知データ設定部５８は、総リスク変動値への寄与率が最大の業務関連情報に応じた態様で通知メッセージのデータを設定してもよい。例えば、通知メッセージに設定する複数の業務関連情報のうち総リスク変動値への寄与率が最大の業務関連情報については、他の業務関連情報よりも上位に表示させたり、文字サイズを大きくしたり、色を変えたりすることで、その業務関連情報を業務担当者から視認しやすい態様にしてもよい。

また、通知データ設定部５８は、総リスク変動値への寄与率が最大の業務関連情報に対しては、その情報カテゴリに応じて、所定の外部装置から取得したタスク以外の情報を付加してもよい。例えば、その業務関連情報のカテゴリが顧客環境属性であれば、リスク記憶部３２に記録されたリスク情報のリスクマップとその顧客企業との取引内容の一覧情報とを付加してもよい。カテゴリが顧客評価属性であれば、与信限度額の変化を示す情報と、その顧客企業との処理中案件の一覧情報とを付加してもよい。カテゴリが業務遂行状況であれば、業務管理を担当する業務管理課からのメッセージを付加してもよい。カテゴリが社内規定であれば、望ましい業務遂行のあり方を示した規程メッセージを付加してもよい。

総リスク変動値への寄与率が最大の業務関連情報は、ユーザリスクを最も大きく変動させた業務関連情報であるため、それへの対処は業務担当者にとって特に重要であるといえる。本変形例によれば、この業務関連情報に応じた態様で通知メッセージが設定されるため、業務担当者はこの業務関連情報に対して特に注意しやすくなり、また適切なメッセージが付加されることで、適切なアクションを実行しやすくなる。

第４の変形例を説明する。上述の実施の形態における通知メッセージには、業務関連情報とタスクとが含まれた。変形例においては、通知データ設定部５８は、業務担当者に確認させるべきさらに詳細な情報へのリンクをこれらの情報に設定してもよい。例えば、図１０の（ｃ）における（１）で示す単位メッセージ８６に対して、通知データ設定部５８は、社内決裁の手順を示したウェブページへのハイパーリンクをこの単位メッセージ８６に設定してもよい。本変形例によれば、通知メッセージを確認した業務担当者は、単位メッセージ８６に設定されたリンクをクリックすることで、その業務関連情報の詳細やタスクの詳細を容易に確認でき、迅速かつ適切にタスクを実行しやすくなる。

第５の変形例を説明する。上述の実施の形態における通知メッセージは、各業務担当者の指定した通知時刻にユーザ端末１０に対して配信された。変形例においては、通知データ設定部５８において通知メッセージが設定されると、ユーザ通知部６０はすぐにユーザ端末１０に対して通知メッセージを配信してもよい。この場合、リスク変動判定部５４における判定のインターバルは比較的短期間であってもよく、例えば、リスク記憶部３２およびリスク変動記憶部３４が更新された都度でもよく、数分から１時間程度でもよい。この変形例によれば、業務関連情報が発生してから、比較的短時間のうちに、リスク変動と実行すべきタスクとが業務担当者に通知される。

上記第５の変形例の具体的な態様として、ユーザ端末１０にＲＳＳ（Rich Site Summary）リーダ機能を持つメーラやブラウザ等が導入される場合、業務支援装置３０は、通知メッセージをＲＳＳでユーザ端末１０にリアルタイム配信してもよい。例えば、ユーザ業務ごとのＸＭＬデータに、ＲＳＳタグを使用して業務関連情報およびタスクを記録してもよい。業務担当者は、ＲＳＳリーダ機能を持つメーラやブラウザを介して、リアルタイムにユーザリスクの変動を確認できる。

第６の変形例を説明する。上述した実施の形態においては、ユーザ業務は業務担当者個々の業務として記載した。変形例においては、ユーザ業務は複数の業務担当者が協働作業を実施するプロジェクト全体を意味してもよい。同様に、ユーザリスクもそのプロジェクト全体のリスクを意味してもよい。本変形例によれば、プロジェクト全体のリスクが管理され、そのリスク変動は、プロジェクトに所属する業務担当者それぞれに通知される。

第７の変形例を説明する。上述した実施の形態においては、ユーザ業務に対してリスク影響度とリスク顕在化率とが対応づけられて、ユーザ業務全体に対するユーザリスクとして管理された。変形例においては、これに加えて、ユーザ業務における業務関連情報の情報カテゴリごとにリスク影響度とリスク顕在化率とが対応づけられて、情報カテゴリ個別のユーザリスクが管理されてもよい。すなわち情報カテゴリ「顧客環境属性」に関するユーザリスク、情報カテゴリ「顧客評価属性」に関するユーザリスク・・・等のレベルでも管理されてよい。

第７の変形例においては、リスク更新部５２は、業務関連情報に応じてユーザ業務全体に対するユーザリスクを更新するとともに、情報カテゴリ個別のユーザリスクを更新する。リスク変動判定部５４は、ユーザ業務全体に対するユーザリスクについては、総リスク変動値が所定の閾値未満であっても、情報カテゴリ個別のユーザリスクについて、そのリスク変動値が別の閾値以上である場合には、ユーザリスクの変動をユーザに通知してもよい。情報カテゴリ個別のリスク変動値に対する閾値は、総リスク変動値に対する閾値よりも小さく設定されることが望ましい。なお、情報カテゴリ個別のユーザリスクが管理される場合には、ユーザ業務全体に対するユーザリスクは管理されなくてもよく、情報カテゴリ個別のユーザリスクそれぞれの変動値の線形和がユーザ業務全体に対するユーザリスクとして算出されてもよい。

第７の変形例によれば、ユーザ業務全体に対するユーザリスクが許容範囲内である場合でも、情報カテゴリ個別のユーザリスクの変動が予め設定された危険値を上回る場合、そのリスク変動をユーザに通知できる。これにより、ユーザリスクを細かいレベルで管理し、ユーザに対して早期にアラートを通知しやすくなる。なお、情報カテゴリ個別のユーザリスクを管理するか否か、また、どの情報カテゴリのユーザリスクを管理するかは、ユーザ情報として設定され、ユーザごとのカスタマイズが可能であってもよい。

上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。例えば、上述した第１の変形例は、リスク変動通知の判定方法が実施の形態と異なるだけであり、他の全ての変形例との組み合わせが可能であることは当業者には理解されるところである。

請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。例えば、請求項に記載の「リスク変動報知部」および「リスクの変動を報知する機能」は、上述したリスク変動判定部５４、通知データ設定部５８、ユーザ通知部６０等の連係によって実現されてもよい。

３０ 業務支援装置、 ３２ リスク記憶部、 ３４ リスク変動記憶部、 ３６ 変換情報記憶部、 ３８ 調整情報記憶部、 ４０ タスク記憶部、 ４２ 重要情報記憶部、 ４４ ユーザ情報記憶部、 ４８ ユーザ情報受付部、 ５０ 業務関連情報取得部、 ５２ リスク更新部、 ５４ リスク変動判定部、 ５６ タスク特定部、 ５８ 通知データ設定部、 ６０ ユーザ通知部、 ６２ リスクマップ設定部、 ６４ リスクマップ記憶部、 ６６ 想定業務記憶部、 ６８ 表示情報検出部、 ７０ 業務推定部、 １００ 業務支援システム。

Claims (6)

1. 業務の遂行において発生しうるリスクの影響度と、前記リスクが現実のものとなる顕在化率とが対応づけられたリスク情報を記憶するリスク記憶部と、
   前記業務の関連情報と、その関連情報が取得された際、前記リスク情報を調整するための情報とを対応づけて記憶する調整情報記憶部と、
   前記関連情報が発生した場合、これを取得する関連情報取得部と、
   前記関連情報が取得された場合、当該関連情報に対応づけられた前記調整するための情報にしたがい、前記リスク情報を更新するリスク更新部と、
   前記リスク情報の更新状況に応じて、前記業務に関連するユーザに対してリスクの変動を報知するリスク変動報知部と、
   を備えることを特徴とするリスク報知システム。
2. 前記関連情報取得部は、前記業務に関連する顧客の属性情報のうち社外において設定された顧客環境属性情報と、当該属性情報のうち自社において設定された顧客評価属性情報と、前記業務の遂行状況情報と、望ましい業務遂行のあり方を定めた規程情報とのうち少なくとも１つを前記関連情報として取得し、
   前記リスク更新部は、前記関連情報として取得されたそれぞれの情報と対応づけられた前記調整するための情報にしたがい、前記リスク情報を更新することを特徴とする請求項１に記載のリスク報知システム。
3. 前記リスク更新部は、前記調整するための情報にしたがい、前記リスクの影響度と顕在化率との双方または一方を増減させることにより前記リスク情報を更新し、
   前記リスク変動報知部は、第１の時点とそれより後の第２の時点とにおける前記リスクの影響度の差分と顕在化率の差分との重み付けされた合計値が所定値以上であるとき、前記ユーザに対してリスクの変動を報知することを特徴とする請求項１または２に記載のリスク報知システム。
4. 前記リスク変動報知部は、前記リスクの変動を報知する際、前記第１の時点と前記第２の時点との間に前記関連情報として取得された情報のうち、前記合計値への寄与率が最大の関連情報に応じた態様で報知することを特徴とする請求項３に記載のリスク報知システム。
5. 前記リスクの影響度と顕在化率とを変数とする座標系として形成され、リスクの大きさに応じて複数のセグメントが設定されたリスクマップ上に、前記リスク情報にしたがって前記業務の位置座標を設定するリスクマップ設定部をさらに備え、
   前記リスクマップ設定部は、前記リスク情報が更新されたとき、前記リスクマップ上における前記業務の位置座標を変化させ、
   前記リスク変動報知部は、前記リスクマップ上における前記業務の位置座標が前記リスクマップ上の一のセグメントから別のセグメントに変化したとき、前記ユーザに対してリスクの変動を報知することを特徴とする請求項１または２に記載のリスク報知システム。
6. 所定の記憶装置に記憶される情報であって、業務の遂行において発生しうるリスクの影響度と、前記リスクが現実のものとなる顕在化率とが対応づけられたリスク情報と、
   所定の記憶装置に記憶される情報であって、前記業務の関連情報と、その関連情報が取得された際、前記リスク情報を調整するための情報とが対応づけられた情報と、に基づいて実行され、
   前記関連情報が発生した場合、これを取得する機能と、
   前記関連情報が取得された場合、当該関連情報に対応づけられた前記調整するための情報にしたがい、前記リスク情報を更新する機能と、
   前記リスク情報の更新状況に応じて、前記業務に関連するユーザに対してリスクの変動を報知する機能と、
   をコンピュータに実現させるためのコンピュータプログラム。

Images