(57)【要約】【課題】ビジネスプロジェクトに内在するリスクを可視化する。【解決手段】リスク可視化装置１００は、ビジネスプロジェクトのリスク状態を表現するために、リスクマップ１８０上にビジネスプロセスの位置座標を設定し、画面表示させる。未完了のビジネスプロセスが発生したときには、その未完了のビジネスプロセスに関わるリスクを定めたプロセスリスク情報を参照することにより、検証対象となるビジネスプロジェクトのリスクを再評価し、リスクマップ上におけるビジネスプロジェクトの位置座標を変化させる。【選択図】図６
2010118012.tif 000002
【特許請求の範囲】
【請求項１】
業務を遂行するための標準手続きを示すビジネスプロセスと、前記ビジネスプロセスを適切に実行しなかったときに生じ得るリスクの大きさを示すプロセスリスク影響度と、前記ビジネスプロセスを適切に実行しなかったときに前記リスクが顕在化する可能性の高さを示すプロセスリスク顕在化率とが対応づけられたプロセスリスク情報を保持するプロセスリスク保持部と、
１以上の業務を含むビジネスプロジェクトと、前記ビジネスプロジェクトに内在するリスクの大きさを示すプロジェクトリスク影響度と、前記ビジネスプロジェクトの前記リスクが顕在化する可能性の高さを示すプロジェクトリスク顕在化率とが対応づけられたプロジェクトリスク情報を保持するプロジェクトリスク保持部と、
プロジェクトリスク影響度とプロジェクトリスク顕在化率を変数とする座標系として形成されるリスクマップ上に、検証対象となるビジネスプロジェクトの位置座標を前記プロジェクトリスク情報に基づいて設定するリスクマップ設定部と、
前記リスクマップを画面表示させるリスクマップ表示部と、
前記検証対象となるビジネスプロジェクトに含まれる業務の遂行に際し、未完了のビジネスプロセスが発生したとき、外部装置から前記未完了のビジネスプロセスの通知を受け付ける未完了プロセス検出部と、
前記未完了のビジネスプロセスを通知されたとき、前記プロセスリスク情報を参照し、前記未完了のビジネスプロセスについてのプロセスリスク影響度およびプロセスリスク顕在化率の双方または一方に基づいて、前記検証対象となるビジネスプロジェクトのプロジェクトリスク影響度およびプロジェクトリスク顕在化率の双方または一方を更新するプロジェクトリスク管理部と、を備え、
前記リスクマップ設定部は、前記プロジェクトリスク情報が更新されたとき、前記リスクマップ上における前記ビジネスプロジェクトの位置座標を変化させることを特徴とするリスク可視化装置。
【請求項２】
前記プロジェクトリスク管理部は、予算額が大きいビジネスプロジェクトほどプロジェクトリスク影響度が高くなるように設定することを特徴とする請求項１に記載のリスク可視化装置。
【請求項３】
ビジネスパートナーと、前記ビジネスパートナーの信用度と、前記ビジネスパートナーが関わるビジネスプロジェクトとが対応づけられたパートナーリスク情報を保持するパートナーリスク保持部、を更に備え、
前記プロジェクトリスク管理部は、前記パートナーリスク情報を参照して、信用度が低いビジネスパートナーが関わるビジネスプロジェクトほどプロジェクトリスク顕在化率が高くなるように設定することを特徴とする請求項１または２に記載のリスク可視化装置。
【請求項４】
ユーザと、前記ユーザのビジネスプロセスに対する理解度とが対応づけられた理解度情報を保持する理解度保持部、を更に備え、
前記プロジェクトリスク管理部は、前記理解度情報を参照して、理解度が高いユーザがメンバーとなっているビジネスプロジェクトほどプロジェクトリスク顕在化率が低くなるように設定することを特徴とする請求項１から３のいずれかに記載のリスク可視化装置。
【請求項５】
業務を構成する１以上のビジネスプロセスを規定するビジネス規程情報を保持するビジネス規程保持部と、
ユーザによる前記ビジネス規程情報へのアクセスを検出する規程アクセス検出部と、
前記検証対象となるビジネスプロジェクトのメンバーによる前記ビジネス規程情報へのアクセス回数が多いほど、アクセス元のユーザのビジネスプロセスに対する理解度が高くなるように調整する理解度調整部と、
を更に備えることを特徴とする請求項４に記載のリスク可視化装置。
【請求項６】
前記ビジネス規程情報および前記プロセスリスク情報を参照し、業務の種類、ビジネスプロセスの種類、および、各ビジネスプロセスに関わるリスク属性を３次元配置することにより、規程マトリックスを生成する規程マトリックス生成部、を更に備えることを特徴とする請求項５に記載のリスク可視化装置。
【請求項７】
前記リスクマップ設定部は、前記リスクマップに新たな座標軸を追加し、プロジェクトリスク顕在化率およびプロジェクトリスク影響度の双方または一方を変動させる要因の大きさを示す指標値を、前記追加された座標軸に設定することを特徴とする請求項１から６のいずれかに記載のリスク可視化装置。
【請求項８】
業務を遂行するための標準手続きを示すビジネスプロセスと、前記ビジネスプロセスを適切に実行しなかったときに生じ得るリスクの大きさを示すプロセスリスク影響度と、前記ビジネスプロセスを適切に実行しなかったときに前記リスクが顕在化する可能性の高さを示すプロセスリスク顕在化率とが対応づけられたプロセスリスク情報、および、１以上の業務を含むビジネスプロジェクトと、前記ビジネスプロジェクトに内在するリスクの大きさを示すプロジェクトリスク影響度と、前記ビジネスプロジェクトの前記リスクが顕在化する可能性の高さを示すプロジェクトリスク顕在化率とが対応づけられたプロジェクトリスク情報、に基づいて実行され、
プロジェクトリスク影響度とプロジェクトリスク顕在化率を変数とする座標系として形成されるリスクマップ上に、前記プロジェクトリスク情報に基づいて検証対象となるビジネスプロジェクトの位置座標を設定する処理と、
前記リスクマップを画面表示させる処理と、
前記検証対象となるビジネスプロジェクトに含まれる業務の遂行に際し、未完了のビジネスプロセスが発生したとき、外部装置から前記未完了のビジネスプロセスの通知を受け付ける処理と、
前記未完了のビジネスプロセスを通知されたとき、前記プロセスリスク情報を参照し、前記未完了のビジネスプロセスについてのプロセスリスク影響度およびプロセスリスク顕在化率の双方または一方に基づいて、前記検証対象となるビジネスプロジェクトのプロジェクトリスク影響度およびプロジェクトリスク顕在化率の双方または一方を更新する処理と、をコンピュータに実行させ、
前記プロジェクトリスク情報が更新されたとき、前記リスクマップ上における前記ビジネスプロジェクトの位置座標を変化させることを特徴とするリスク可視化プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務管理、特に、ビジネス上の手続きを管理するための技術、に関する。
【背景技術】
【０００２】
ビジネスプロジェクトにはさまざまな業務が含まれるが、それらの中には定型業務も多い。たとえば、受注業務であれば、受注先の安定性や支払い能力を審査し、上司の決済を受け、受注先と契約書を交わすといった標準的な手続きが定型化されている。多くの企業においては、各種業務の標準的な手続きは、マニュアル（以下、「ビジネス規程」とよぶ）として規定されている。
【特許文献１】特開２００８−１１７３１６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
リスクを抑えながら、ビジネスプロジェクトを円滑に遂行するためには、ビジネス規程に則って各種業務を遂行することが望ましい。現場においてビジネス規程が守られているか、プロジェクトメンバーがビジネス規程をきちんと理解しているかといった要因は、ビジネスプロジェクトの成否を左右する。
【０００４】
本発明は、本発明者による上記課題認識に基づいて完成された発明であり、その主たる目的は、ビジネス規程と現実の適合度からビジネスプロジェクトに内在するリスクを可視化するための技術、を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のある態様は、リスク可視化装置に関する。
この装置は、プロセスリスク情報とプロジェクトリスク情報を保持する。プロセスリスク情報は、業務を遂行するための標準手続きを示すビジネスプロセスについて、そのビジネスプロセスを適切に実行しなかったときに生じ得るリスクの大きさとそのリスクが顕在化する可能性の高さを対応づけた情報である。プロジェクトリスク情報は、１以上の業務を含むビジネスプロジェクトと、そのビジネスプロジェクトに内在するリスクの大きさとそのリスクが顕在化する可能性の高さを対応づけた情報である。
この装置は、ビジネスプロジェクトにおけるリスクの大きさおよびリスクが顕在化する可能性の高さを座標軸として表現されるリスクマップ上に、検証対象となるビジネスプロジェクトの位置座標を設定し、画面表示させる。
ビジネスプロジェクトのリスクとして、プロジェクト固有のリスク、パートナーに関するリスク、未完了プロセスに関するリスク、規程理解度に関するリスクを可視化対象としてもよい。
たとえば、未完了のビジネスプロセスが発生したときには、その未完了のビジネスプロセスに関わるプロセスリスク情報に基づいて、検証対象となるビジネスプロジェクトのリスクを再評価し、リスクマップ上におけるビジネスプロジェクトの位置座標を変化させる。
【０００６】
ここでいう「未完了」とは、ビジネスプロセスがまったく実行されなかった場合に限らず、ビジネスプロセスがビジネス規程にしたがって適切に実行されなかった場合も含む。たとえば、契約遅延、請求遅延、入金遅延などが考えられる。
【０００７】
なお、以上に示した各構成要素の任意の組み合わせ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【０００８】
本発明によれば、ビジネス規程の遵守状況に基づいて、ビジネスプロジェクトに内在するリスクを可視化できる。
【発明を実施するための最良の形態】
【０００９】
図１は、リスク可視化システム１０のハードウェア構成図である。
リスク可視化システム１０においては、リスク可視化装置１００、進捗管理装置２００およびクライアント端末３００ａ、３００ｂ、・・・、３００ｎ（以下、まとめて「クライアント端末３００」とよぶ）が、ＬＡＮ（Local Area Network）３０２を介して互いに接続されている。
【００１０】
クライアント端末３００は、ユーザによって使用される端末である。ここでいうユーザとは、ビジネスプロジェクトメンバーに限らず、複数のビジネスプロジェクトを管理する立場にあるマネージャも含まれる。本実施例におけるクライアント端末３００は、ウェブブラウザを搭載する一般的なパーソナルコンピュータである。「ビジネスプロジェクト（以下、単に、「プロジェクト」とも称する）」とは、製品開発や販促企画のように、プロジェクトメンバーや予算が割り当てられるビジネス単位であればよい。
【００１１】
進捗管理装置２００は、プロジェクトの進捗状態を管理するためのデータベースである。会計上の証憑に基づく進捗を管理する場合は、会計情報の予実を対象とすることも可能である。プロジェクトメンバーは、プロジェクトを遂行するために必要な業務を進捗管理装置２００に登録する。「業務」としては、たとえば、受注管理や外注委託などを挙げることができる。業務は、１以上のビジネスプロセスを含む。「ビジネスプロセス（以下、単に、「プロセス」とも称する）」とは、業務の標準的な手続きを示す。たとえば、業務「受注管理」に含まれるプロセスとして、１．審査、２．決済、３．契約書締結、４．納品・請求書発行、５．検収書受領、６．入金確認という６つのプロセスがビジネス規程（以下、単に、「規程」とも称する）に設定される。このように複数のプロセスにより業務が形成され、１以上の業務を含んだかたちでプロジェクトが形成される。プロセスについては、図３等に関連して更に詳述する。
【００１２】
進捗管理装置２００は進捗状態情報２０２を管理する。進捗状態情報２０２の詳細については、図７に関連して後述する。
【００１３】
リスク可視化装置１００は、進捗状態情報２０２等を参照し、各種プロジェクトが抱えるリスクの度合い（以下、「リスク状態」とよぶ）を視覚的に示す。また、リスク可視化装置１００は規程を保持する。各ユーザは、クライアント端末３００により、リスク可視化装置１００の規程をウェブページとして取得できる。
【００１４】
図２は、リスク可視化装置１００の機能ブロック図を示す。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組み合わせによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【００１５】
リスク可視化装置１００は、ＩＦ（インタフェース）部１１０、データ処理部１３０およびデータ保持部１４０を含む。
ＩＦ部１１０は、進捗管理装置２００やクライアント端末３００とのインタフェースを担当する。データ処理部１３０は、ＩＦ部１１０、データ保持部１４０から取得されたデータをもとにして各種のデータ処理を実行する。データ処理部１３０は、ＩＦ部１１０およびデータ保持部１４０の間のインタフェースの役割も果たす。データ保持部１４０は、各種データを保持するための記憶領域である。
【００１６】
ＩＦ部１１０：
ＩＦ部１１０は、入力処理を担当する入力部１１２と出力処理を担当する出力部１２０を含む。入力部１１２は、進捗情報取得部１１４と規程アクセス検出部１１８を含む。進捗情報取得部１１４は、進捗管理装置２００から各プロジェクトの進捗情報を取得する。進捗情報取得部１１４は、更に、未完了プロセス検出部１１６を含む。未完了プロセス検出部１１６は、進捗情報から未完了プロセスを検出する。「未完了プロセス」とは、プロセスのうち、適切に実行されていない、または、まったく実行されていないものをいう。規程アクセス検出部１１８は、規程に対するユーザのアクセスを検出する。
【００１７】
出力部１２０は、規程マトリックス表示部１２２とリスクマップ表示部１２４を含む。規程マトリックス表示部１２２は、図４に示す規程マトリックス１６０をクライアント端末３００に画面表示させる。規程マトリックス１６０は、規程と業務、プロセス等の関係を三次元表示したものである。リスクマップ表示部１２４は、図６や図９に示すリスクマップ１８０をクライアント端末３００に画面表示させる。リスクマップ１８０は、プロジェクトに内在するリスクの大きさとそのリスクが顕在化する可能性の高さとを視覚的に示す図である。
【００１８】
データ処理部１３０：
データ処理部１３０は、リスクマップ設定部１３２、プロジェクトリスク管理部１３４、規程マトリックス生成部１３６および理解度調整部１３８を含む。リスクマップ設定部１３２は、リスクマップ上に各プロジェクトの位置をプロットする。プロジェクトリスク管理部１３４は、プロジェクトのリスク状態を管理する。規程マトリックス生成部１３６は、規程マトリックス１６０を生成する。理解度調整部１３８は、ユーザの規程に対する理解度を調整する。これらの詳細については順次説明する。
【００１９】
データ保持部１４０：
データ保持部１４０は、プロセスリスク保持部１４２、プロジェクトリスク保持部１４４、パートナーリスク保持部１４６、理解度保持部１４８およびビジネス規程保持部１５０を含む。プロセスリスク保持部１４２は、プロセスごとのリスクを示すプロセスリスク情報２２０を保持する。プロセスリスク情報２２０のデータ構造は図８に関連して後述する。プロジェクトリスク保持部１４４は、プロジェクトごとのリスク状態を示すプロジェクトリスク情報１９０を保持する。プロジェクトリスク情報１９０のデータ構造は図５に関連して後述する。
【００２０】
パートナーリスク保持部１４６は、パートナーリスク情報を保持する。パートナーリスク情報は、ビジネスの相手である「ビジネスパートナー（以下、単に、「パートナー」とも称する）」とその信用度およびそのパートナーが関連するプロジェクトとが対応づけられた情報である。ここでいう「信用度」としては、パートナーの貸し倒れリスクや法令遵守意識の高さ、知名度等に基づいて所与の値が設定される。パートナーの財務諸表や格付の変動、過去の取引実績、直近の事故情報に鑑みて、それらのデータソースに連動して自動更新されてもよいし、ユーザが手動で更新してもよい。
【００２１】
理解度保持部１４８は、ユーザの規程に対する理解度を示す理解度情報２３０を保持する。理解度情報２３０のデータ構造は図１０に関連して後述する。ビジネス規程保持部１５０は、規程の内容を示すビジネス規程情報１７０を保持する。ビジネス規程情報１７０のデータ構造は図３に関連して後述する。
【００２２】
図３は、ビジネス規程情報１７０のデータ構造図である。
ビジネス規程保持部１５０は、ビジネス規程情報１７０を格納する。ビジネス規程情報１７０は、各種業務、各種プロセスについて、規程の内容を示す情報である。業務欄１７２は業務、プロセス欄１７４は業務を構成するプロセス、説明欄１７６はプロセスの具体的な処理手順や趣旨を示す。同図によれば、業務「受注管理」は６つのプロセスから構成されている。ユーザは、クライアント端末３００に規程を表示させることができる。ビジネス規程情報１７０は、規程マトリックス生成部１３６により図４に示す規程マトリックス１６０のかたちに構造化され、規程マトリックス表示部１２２によりユーザに示される。
【００２３】
図４は、規程マトリックス１６０を示す図である。
規程マトリックス１６０は、ｘ軸、ｙ軸、ｚ軸の３軸パラメータにより構成される直方体である。
ｘ軸は規程の種類を示す。同図のｘ１は規程１、ｘ２は規程２、ｘ３は規程３、ｘ４は規程４を示している。ｘ１は規程「受注管理規程」、ｘ２は規程「外注委託規程」であるかもしれない。
ｚ軸はプロセスを示す。たとえば、ｘ１「受注管理」のｚ５、すなわち、同図のＰ１１はプロセス「審査」を示す。同様にＰ１２（ｘ１，ｚ４）はプロセス「決済」、Ｐ１３（ｘ１，ｚ３）はプロセス「契約」を示す。
ｙ軸は、プロセスの属性を示す。たとえば、ｘ１「受注管理」のｙ１、すなわち、同図のＮ１はプロセス「審査」の名称を示す。同様にＤ１（ｘ１，ｙ２，ｚ５）はプロセス「審査」の説明、ＲＥ１（ｘ１，ｙ３，ｚ５）とＲＰ１（ｘ１，ｙ４，ｚ５）は、それぞれ「プロセスリスク影響度」と「プロセスリスク顕在化率」を示す。プロセスリスク影響度とプロセスリスク顕在化率は、プロセスを適切に実行しなかった場合のリスクの大きさと、そのリスクが顕在化する可能性の高さを示すが、詳細については図８に関連して説明する。
【００２４】
プロジェクトリスク影響度はＲＣＭ（Risk Contorol Matrix）のデータ項目の影響度と、プロジェクトリスク顕在化率はＲＣＭのデータ項目の発生頻度と同一の位置づけである。ｙ軸の属性としては、このほかにも該当プロセスを原因として発生した過去の事故例や、取引先に関する情報が追加されてもよい。このようにして、ｙ軸にはプロセスのＲＣＭが包含される。これにより、内部統制により管理されるＲＣＭに、実情に即したプロジェクトリスク影響度とプロジェクトリスク顕在化率を含めることができる。プロジェクトリスク保持部１４４で更新されたこの２つの情報を内部統制側のRCMに反映させてもよい。規程マトリックス１６０においては、規程の種類、プロセスの種類およびプロセスに関わる属性、特に、リスクに関わるリスク属性が三次元構造にて示される。規程マトリックス生成部１３６は、ビジネス規程情報１７０やプロジェクトリスク情報１９０等の各種情報を参照して規程マトリックス１６０を構築する。規程マトリックス１６０は、規程マトリックス表示部１２２によりクライアント端末３００に画面表示される。
【００２５】
プロジェクト遂行者や部署のユーザは、マウス等の入力デバイスを介して規程マトリックス１６０にアクセスする。たとえば、（ｘ１，ｚ４，ｙ２）をアクセス先として指定すれば、規定「受注管理規定」のプロセス「決済」についての説明情報を画面表示させることができる。このように、規程の情報内容が３Ｄ構造化されて示されるため、ユーザは規程に関わる情報の中から求める情報にアクセスしやすくなる。規程マトリックス１６０において、所望の規程にアクセスすると、規程アクセス検出部１１８はどのユーザがどの業務のどのプロセスに関する規程にアクセスしたかを検出する。規程のアクセスは後述の「理解度」に関わる。
【００２６】
図５は、プロジェクトリスク情報１９０のデータ構造図である。
プロジェクトリスク保持部１４４は、プロジェクトリスク情報１９０を保持する。プロジェクトリスク情報１９０は、プロジェクトごとのリスク状態を示す。プロジェクト欄１９２はプロジェクト名、プロジェクトリスク影響度欄１９４はプロジェクトリスク影響度、プロジェクトリスク顕在化率欄１９６はプロジェクトリスク顕在化率を示す。
【００２７】
「プロジェクトリスク影響度」は、プロジェクトが組織全体に与える影響の大きさを示す。企業や部署は通常、多くのプロジェクトを同時に進行させている。こういったプロジェクトの中には組織の浮沈を左右する重大ものもあれば、実験的なものもある。プロジェクトリスク影響度は、プロジェクトに内在するリスクが顕在化した場合の影響の大きさを示す値である。プロジェクトリスク影響度は、ユーザによるＲＣＭ設定時の値を初期値とする。本実施例においては、重要クライアントが関わるプロジェクトや、予算額の大きなプロジェクトほど、プロジェクトリスク影響度が高くなるように設定され、また変動させることができる。
【００２８】
「プロジェクトリスク顕在化率」は、プロジェクトに内在するリスクが実際に現実のものとなる可能性の高さを示す値である。プロジェクトリスク顕在化率も、ユーザによるＲＣＭ設定時の値を初期値とする。プロジェクトリスク顕在化率が高いプロジェクトほど事故が発生する可能性が高いため注意が必要である。この値は、実際の事故発生や規程違反に応じて変動させることが出来る。プロジェクトリスク影響度とプロジェクトリスク顕在化率の両方が高いプロジェクトは、厳重な管理のもとに遂行される必要がある。
【００２９】
図５に示すプロジェクトＤは、プロジェクトリスク影響度は最も大きいが、プロジェクトリスク顕在化率は最も低く抑えられている。このため、プロジェクトＤは重要であるが、上手にリスク管理されていることになる。一方、プロジェクトＣは、プロジェクトリスク顕在化率が最も高いが、プロジェクトリスク影響度は最も低いため、失敗した場合の影響は限定的であることがわかる。
【００３０】
図６は、リスクマップ１８０を示す図である。
ｘ軸はプロジェクトリスク影響度、ｙ軸はプロジェクトリスク顕在化率を示す。リスクマップ表示部１２４は、同図に示すリスクマップ１８０をクライアント端末３００に画面表示させる。リスクマップ設定部１３２は、プロジェクトリスク情報１９０を参照して、各プロジェクトの位置をリスクマップ１８０上にプロットする。ユーザは、リスクマップ１８０を確認することにより、複数のプロジェクトのリスク状態を視覚的に把握できる。
各プロジェクトのリスク状態は、プロジェクトの進行に応じて適宜変化する。
【００３１】
図７は、進捗状態情報２０２のデータ構造図である。
進捗管理装置２００は、進捗状態情報２０２を格納する。進捗状態情報２０２は、各プロジェクトの内容やその進捗状況を示すデータである。プロジェクト欄２０４はプロジェクト名、予算欄２０５は予算額、業務欄２０６はプロジェクトに含まれている業務、未完了プロセス欄２０７は各業務における未完了プロセスの有無、パートナー欄２０８は各業務に関わるパートナーを示す。
【００３２】
同図によれば、プロジェクトＡは、予算額は５００億円であり、受注管理、外注委託などの業務を含む。また、受注管理業務では、プロセス「契約」が未完了となっている。受注管理に関わるパートナーは「Ｈ社」である。プロジェクトリーダーは、プロジェクトＡの進行にあたって、契約情報等の登録情報を参照し、各種情報を進捗状態情報２０２に登録する。規程を外れたかたちで業務が進められているときには、未完了プロセスが進捗状態情報２０２に自動的に（例えば予実績の対比により）、あるいは、手動により登録される。
【００３３】
未完了プロセスが発生すると、プロジェクトのリスク状態も変化する。未完了プロセスとリスクの関係については、図８に関連して後述する。
プロジェクトのリスクは、予算の変更によっても変化する。たとえば、プロジェクトＡの予算額が５００億円から６００億円に拡大されたとする。プロジェクトリスク管理部１３４は、進捗情報取得部１１４が取得した進捗状態情報２０２からこれを検出する。そして、プロジェクトＡのプロジェクトリスク影響度を変更する。本実施例においては、予算額が１．２倍となっているため、プロジェクトリスク管理部１３４はプロジェクトＡのプロジェクトリスク影響度「７０（図５参照）」を１．２倍して、「８４」に変更してもよい。このように、プロジェクトリスク管理部１３４は予算額とプロジェクトリスク影響度を正相関させる。
【００３４】
プロジェクトのリスクは、パートナーによっても変化する。信用度が８０％以上のパートナーの場合には、プロジェクトのリスク状態は変化しないが、８０％未満の場合には、プロジェクトリスク管理部１３４はプロジェクトリスク顕在化率が高くなるように設定変更する。たとえば、プロジェクトＡのパートナーＨ、Ｉ、Ｊ、Ｋのうち、Ｋ社の信用度のみが８０％を下回っているとする。この場合、プロジェクトリスク管理部１３４は、プロジェクトリスク顕在化率に「（８０−ｘ）×０．００５」を加算する。ｘは、Ｋ社の信用度を示す。Ｋ社の信用度が５０％であれば、プロジェクトＡのプロジェクトリスク顕在化率は、０．４＋（８０−５０）×０．００５＝０．５５となる。このように、プロジェクトリスク管理部１３４はパートナーの信用度とプロジェクトリスク顕在化率を逆相関させる。プロジェクトリスク顕在化率を下げるには、信頼できるパートナーを選ぶ必要がある。特に、プロジェクトリスク影響度が高いプロジェクトでは、信用度の低いパートナーに依存しないように注意する必要がある。
【００３５】
図８は、プロセスリスク情報２２０のデータ構造図である。
プロセスリスク保持部１４２は、プロセスリスク情報２２０を保持する。プロセスリスク情報２２０は、プロセスそのものに内在するリスクを定量的に示す情報である。業務欄２２２は業務名、プロセス欄２２４はプロセス名、プロセスリスク影響度欄２２６はプロセスリスク影響度、プロセスリスク顕在化率欄２２８はプロセスリスク顕在化率を示す。
【００３６】
「プロセスリスク影響度」は、そのプロセスを適切に実行しなかった場合に生じ得るリスクの大きさ、いいかえれば、プロセスが業務や組織に与え得る影響の大きさを示す。プロセスリスク影響度は、ＲＣＭ設定時の値を初期値とする。
「プロセスリスク顕在化率」は、プロセスに内在するリスクが実際に現実のものとなる可能性の高さを示す値である。プロセスリスク顕在化率も、ＲＣＭ設定時の値を初期値とする。プロセスリスク顕在化率が高いプロセスほど事故が発生する可能性が高いため間違いなく実行する必要性が高い。プロセスリスク影響度とプロセスリスク顕在化率の両方が高いプロセスの場合には尚更である。
【００３７】
同図によれば、受注管理業務のプロセス「契約」は、プロセスリスク影響度が４０、プロセスリスク顕在化率が０．１である。図７によれば、プロジェクトＡについてはこのプロセス「契約」が未完了プロセスとなっている。プロジェクトリスク管理部１３４は、未完了プロセス「契約」のプロセスリスク影響度やプロセスリスク顕在化率に基づいて、プロジェクトＡのプロジェクトリスク影響度やプロジェクトリスク顕在化率を調整する。本実施例においては、プロジェクトリスク影響度に「プロセスリスク影響度×０．１」、プロジェクトリスク顕在化率に「プロセスリスク顕在化率×０．１」をそれぞれ加算する。
【００３８】
プロジェクトＡのプロジェクトリスク影響度は７０、プロジェクトリスク顕在化率は０．４であるため、それぞれ７０＋４０×０．１＝７４、０．４＋０．１×０．１＝０．４１となる。このように、プロジェクトリスク管理部１３４は、未完了プロセスのプロセスリスク影響度とプロジェクトリスク影響度、プロセスリスク顕在化率とプロジェクトリスク顕在化率をそれぞれ正相関させる。プロジェクトリスク影響度やプロジェクトリスク顕在化率を下げるためには、未完了プロセスを発生させないことが重要であり、特に、重要なプロセスを確実に実行することが重要である。
【００３９】
図９は、プロジェクトＡの位置が変化するときのリスクマップ１８０を示す図である。
プロジェクトのリスク状態、すなわち、プロジェクトリスク影響度とプロジェクトリスク顕在化率は、プロジェクトリスク情報１９０に基づいて設定されるが、プロジェクトリスク情報１９０はプロジェクトリスク管理部１３４により適宜更新される。そして、プロジェクトのリスクマップ１８０上における位置も、それにともなって変化する。リスク状態を変化させる要因をまとめると、以下の通りである。
未完了プロセス：プロジェクトリスク影響度およびプロジェクトリスク顕在化率を増加させる要因となる。
予算額：プロジェクトリスク影響度を増減させる要因となる。
パートナーの評点：プロジェクトリスク顕在化率を増減させる要因となる。
プロジェクトの進行中において、どのような業務が登録され、どのように各プロセスが遂行されたかにより、あるいは予算の変更やパートナーの評点の変動により、プロジェクトのリスク状態が刻々と遷移することを表現する。
【００４０】
図１０は、理解度情報２３０のデータ構造図である。
理解度保持部１４８は、理解度情報２３０を保持する。ユーザＩＤ欄２３２はユーザＩＤ、規程欄２３４は規程ごとの理解度を示す。理解度は０〜１００点の範囲にあり、１００点が規程に対する理解度が最も高い状態を示す。たとえば、ユーザＩＤ＝０１のユーザ（以下、「ユーザ（０１）」と表記する）の規程１に対する理解度は１００であり、ユーザ（０１）は規程１に関わる規程を完璧に理解している。また、ユーザ（０２）の規程１に対する理解度は７０であり、ユーザ（０２）はユーザ（０１）ほどではないにせよ規程１の規程をほぼ理解している。しかし、ユーザ（０３）の規程１に対する理解度は１０であり、規程１に関わる規程をほとんど理解できていない。理解度は、権限のある所定ユーザにより任意に設定可能である。自己申告に基づいて設定してもよいし、定期的に理解度テストを実施することにより測定してもよい。
【００４１】
ここで、ユーザ（０１）、ユーザ（０２）、ユーザ（０３）をプロジェクトメンバーとするプロジェクトＬに規程１が含まれるとする。このとき、理解度調整部１３８は、プロジェクトＬにおける規程１の総合理解度を算出する。たとえば、３人の理解度の平均値６０（＝（１００＋７０＋１）÷３）を総合理解度として算出する。この総合理解度が高いほど、いいかえれば、プロジェクトメンバーが規程を理解しているほど、プロジェクトリスク顕在化率は低くなる。プロジェクトリスク顕在化率を下げるためには、プロジェクトメンバーの規程に対する理解を深める必要がある。あるいは、規程をよく理解しているユーザを重要なプロジェクトのメンバーに割り当てることも重要である。
【００４２】
規程１における未完了プロセスの発生と、規程１に対する総合理解度は、プロジェクトリスク顕在化率に対する影響を相殺する。原則的には、各規定を規程に則って遂行することが望ましい。しかし、ビジネスをスムーズに進めるためには、正式な契約書の締結を後回しにするなど、現場判断で業務の進め方を変えることはよくある。こういった場合には先行着手に関する規程に従うなどプロジェクトメンバーが規程をきちんと理解した上で仕事の進め方をしていることを確認することにより、プロジェクトのリスクはそれほど高まらない。このような観点から、規程に対する理解度をプロジェクトリスク顕在化率に反映させている。
【００４３】
本実施例においては、ユーザが規程マトリックス１６０を介して規程にアクセスしたとき、規程アクセス検出部１１８はこれを検出する。理解度調整部１３８は、規程へのアクセス回数に応じて、アクセス元のユーザの理解度を増加させる。たとえば、規程１の規程にユーザ（０３）がアクセスしたとき、理解度調整部１３８はユーザ（０３）の規程１の規程に対する理解度に１を加算する。プロジェクトリスク管理部１３４は、理解度に基づいて、プロジェクトリスク顕在化率を調整する。本実施例においては、プロジェクトリスク顕在化率から「総合理解度×０．００１」を減算する。プロジェクトＬのプロジェクトリスク顕在化率が０．４である場合、０．４−６０×０．００１＝０．３４となる。このように、プロジェクトリスク管理部１３４は、各種規程についてのプロジェクトメンバーの総合理解度とプロジェクトリスク顕在化率を逆相関させる。この機能を利用すれば、プロジェクトリスクの顕在化を低減させるためにプロジェクト管理者が、プロジェクトメンバーにリスクに関連した規程部分を読んで理解するようにアナウンスを出し、本リスクマップ上で、プロジェクトメンバーの規程理解度が向上したことを確認することも可能である。
なお、本実施例においては、未完了プロセス、予算額、パートナーの評点、総合理解度等が、プロジェクトリスク影響度やプロジェクトリスク顕在化率の双方または一方に対して影響を及ぼすとして説明しているが、その影響の仕方は本実施例に示した内容に限られるものではない。たとえば、未完了プロセス等のすべてがプロジェクトリスク影響度への影響要因であってもよいし、そのすべてがプロジェクトリスク顕在化率への影響要因であってもよい。
【００４４】
図１１は、３Ｄリスクマップ３１０を示す図である。
リスクマップ表示部１２４は、更に、図１１に示す態様にて３Ｄリスクマップ３１０を表示させることもできる。３Ｄリスクマップ３１０においては、２Ｄのリスクマップ１８０として示される平面に対して、リスク増減要因を定量的に示すための第３の軸（以下、「要因軸」とよぶ）が付与される。要因軸は、同図向かって右側がリスク増大要因を示し、同図向かって左側がリスク減少要因を示す。リスク増大要因がリスク減少要因により相殺された結果がリスクマップ１８０における各プロジェクトの位置座標、特に、プロジェクトリスク影響度の大きさを示す。
【００４５】
リスク増大要因としては、予算額やプロジェクト固有のリスク、未完了プロセスの発生、パートナーの信用度がある。これらのパラメータは数値化され、その合計値はリスク増大要因の大きさ、いいかえれば、要素軸右方向に伸びる棒グラフの長さにより示される。
リスク減少要因としては、規程に対する総合理解度がある。総合理解度はリスク減少要因の大きさ、いいかえれば、要素軸左方向に伸びる棒グラフの長さにより示される。
３Ｄリスクマップ３１０は、各プロジェクトのリスク状態だけでなく、そのリスク状態を形成する要因も視覚的に示すことができる。要素軸右側の空間は、「発見的統制手段」として、リスクを増大させている要因がなんなのかをユーザに示すための空間である。要素軸左側の空間は、「予防的統制手段」として、リスクを減少させるための措置がどの程度講じられているかをユーザに示すための空間である。
【００４６】
以上、リスク可視化装置１００を実施例に基づいて説明した。
リスク可視化装置１００によれば、１以上のプロジェクトのリスク状態をリスクマップ１８０上において視覚的に示すことができる。また、未完了プロセスが発生したときには、未完了プロセスに固有のリスク値、すなわち、プロセスリスク影響度とプロセスリスク顕在化率に基づいて、プロジェクトのリスク状態を調整する。このような態様によれば、規程と現実との適合度に基づいて、プロジェクトのリスクを定量化し、リスク状態を視覚的に示すことができる。このため、複数のプロジェクトを管理する立場にあるマネージャは、各プロジェクトのリスク状態を定期的かつ短時間にて把握しやすくなる。
【００４７】
プロジェクト管理者はリスクマップ上のプロジェクトについて、それを構成するリスクを３Ｄリスクマップ３１０として３次元表示することにより、プロジェクトに内在するリスク特性を理解しやすくなるため、適切に対応策を打ち出しやすくなる。例えば、予算額が大きいプロジェクトについては、高いプロジェクトリスク影響度を認識することにより、ビジネスの実態に即したリスクの把握が可能となる。同様にして、パートナーの信用度や規程に対する理解度を考慮することにより、より正確なリスク把握による対応の実施を支援できる。
【００４８】
更に、規程を規程マトリックス１６０として３Ｄ構造化してわかりやすく示すことにより、規程というマニュアルに対するユーザのアクセス意欲を喚起しやすくなる。
【００４９】
以上、本発明について実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５０】
プロジェクトのリスク状態を変動させる要因としては、本実施例以外にもさまざまなものが考えられる。たとえば、パートナーとの取引実績、プロジェクトリーダーの経験、プロセスや業務に対する習熟度、社内で知識・経験が蓄積されていない新規業務を含むか否か、プロジェクトのスケジュールと現実とのずれ、プロジェクトメンバーの新規加入や退職、相性などを挙げることができる。
【図面の簡単な説明】
【００５１】
【図１】リスク可視化システムのハードウェア構成図である。
【図２】リスク可視化装置の機能ブロック図を示す図である。
【図３】ビジネス規程情報のデータ構造図である。
【図４】規程マトリックスを示す図である。
【図５】プロジェクトリスク情報のデータ構造図である。
【図６】リスクマップを示す図である。
【図７】進捗状態情報のデータ構造図である。
【図８】プロセスリスク情報のデータ構造図である。
【図９】プロジェクトＡの位置が変化するときのリスクマップを示す図である。
【図１０】理解度情報のデータ構造図である。
【図１１】３Ｄリスクマップを示す図である。
【符号の説明】
【００５２】
１０  リスク可視化システム、  １００  リスク可視化装置、  １１０  ＩＦ部、  １１２  入力部、  １１４  進捗情報取得部、  １１８  規程アクセス検出部、  １１６  未完了プロセス検出部、  １２０  出力部、  １２２  規程マトリックス表示部、  １２４  リスクマップ表示部、  １３０  データ処理部、  １３２  リスクマップ設定部、  １３４  プロジェクトリスク管理部、  １３６  規程マトリックス生成部、  １３８  理解度調整部、  １４０  データ保持部、  １４２  プロセスリスク保持部、  １４４  プロジェクトリスク保持部、  １４６  パートナーリスク保持部、  １４８  理解度保持部、  １５０  ビジネス規程保持部、  １６０  規程マトリックス、  １７０  ビジネス規程情報、  １７２  業務欄、  １７４  プロセス欄、  １７６  説明欄、  １８０  リスクマップ、  １９０  プロジェクトリスク情報、  １９２  プロジェクト欄、  １９４  プロジェクトリスク影響度欄、  １９６  プロジェクトリスク顕在化率欄、  ２００  進捗管理装置、  ２０２  進捗状態情報、  ２０４  プロジェクト欄、  ２０５  予算欄、  ２０６  業務欄、  ２０７  未完了プロセス欄、  ２０８  パートナー欄、  ２２０  プロセスリスク情報、  ２２２  業務欄、  ２２４  プロセス欄、  ２２６  プロセスリスク影響度欄、  ２２８  プロセスリスク顕在化率欄、  ２３０  理解度情報、  ２３２  ユーザＩＤ欄、  ２３４  規程欄、  ３００  クライアント端末、  ３０２  ＬＡＮ。
【図１】
2010118012.tif 000003
【図２】
2010118012.tif 000004
【図３】
2010118012.tif 000005
【図４】
2010118012.tif 000006
【図５】
2010118012.tif 000007
【図６】
2010118012.tif 000008
【図７】
2010118012.tif 000009
【図８】
2010118012.tif 000010
【図９】
2010118012.tif 000011
【図１０】
2010118012.tif 000012
【図１１】
2010118012.tif 000013