JP2008152782A - 複数のビジネスアプリケーション全体における手続き欠陥の検出 - Google Patents

Abstract

【課題】複数のビジネスアプリケーション全体における手続き欠陥を検出する方法およびシステムを提供すること。
【解決手段】方法は、複数のビジネスアプリケーション全体からデータを抽出するための複数のデータエクストラクタを取り出すステップを含む。複数のデータエクストラクタは、実行されて、複数の個別結果セットを生成する。複数の個別結果セットは、組み合わされて、組合せ結果セットになる。ルールが、複数のビジネスアプリケーション全体における手続き欠陥を検出するために、組合せ結果セットに適用される。
【選択図】図1

Description

本出願は、コンピュータベースのビジネスアプリケーション機能を実行する方法およびシステムに関する。

企業資源計画(ERP)システムは、会社の多くのビジネスプラクティスを統合し、自動化し、追跡し、規制する、マネージメント情報システムである。ERPシステムは、会計、販売、インボイス処理、製造、物流、配送、在庫管理、生産、出荷、品質管理、情報テクノロジ、および人的資源管理など、会社の業務の多くの面に対処することができる。ERPシステムは、産業スパイなどの外部犯罪に対する防御、および横領などの内部犯罪対する防御を行うための、コンピュータセキュリティを含むことができる。ERPシステムは、不正行為、過失、または悪用の様々な異なる発生を検出し、防止し、報告するために、設置されることができる。ERPシステムは、会社と顧客との対話(「フロントエンド」活動)、品質管理および会社のその他の内部作業(「バックエンド」活動)、供給業者および輸送業者との対話(「サプライチェーン」)、または事業のその他の局面を志向したものとすることができる。

「Sarbanes-Oxley」または「Public Company Accounting Reform and Investor Protection Act of 2002(上場企業会計改革および投資家保護法)」または「SOX」としても知られる「The Sarbanes-Oxley Act of 2002(サーベンスオクスリー法)」(Pub.L.No.107-204,116 Stat.745,July 30,2002)などの最近の法律に鑑みて、会社がERPシステムをコンプライアンス管理アプリケーションで補うことが、ますます有益になっている。Sarbanes-Oxleyは、企業情報開示の正確性および信頼性を向上させることによって、投資家を保護することを目指している。この法令は、公開会社会計監視委員会の設立、監査人の独立性、企業責任、および強化された財務情報開示などの問題を取り扱う。

とりわけ、Sarbanes-Oxleyは、CEOおよびCFOに財務報告書を保証するよう要求する。さらに、Sarbanes-Oxleyは、正確な財務情報開示を保証するように設計された1組の内部手続きを義務付ける。

最新のERPシステムは、会社がより良く組織されることを助け、そのいくつかは、Sarbanes-Oxleyなどの規制要求の難題にさえも対処するが、ERPシステムを運用し、管理し、または修正することは、きわめて複雑になり得る。実際、会社内における用途の広範性のため、ERPソフトウェアシステムは、絶えず書かれ続けるソフトウェアの最大規模の集団のいくつかに依存する。

いくつかの実施形態が、添付の図面の図に限定することなく、例として説明される。

以下の説明では、説明の便宜上、いくつかの実施形態例の完全な理解を提供するために、多数の具体的な詳細が説明される。しかし、本発明がこれらの具体的な詳細を伴わずとも実施され得ることは、当業者には明白であろう。

ERP監視ソリューションは、ダウンロードデータ上で動作する検出ソリューションの使用を通して、リスクをしばしば「事後的」に評価する。大企業の場合、ダウンロードは数時間かかることもあり得る。ダウンロードおよび分析が完了する時間までに、新規ユーザ、新規ロール割り当て、および新規トランザクションが、すでにシステムを変更している。いかなる修正作業も、すでに変更されたシステムに対して実行されるので、競合を除去することに失敗することがある。また、修正作業が成功したかどうかは、別のダウンロードおよび分析が完了されるまで分からない。負の影響を連続的に伝播させる大きな潜在性が存在する。

さらに、定期的に繰り返されるダウンロードは、情報テクノロジ(IT)およびシステム資源を枯渇させるので、事後監視の僅かな支持者だけしか、日次または週次より高い頻度で管理分析を実行することはない。ダウンロードおよび分析の頻度に依存して、違反は、発見されるまでにかなりの長さの時間にわたって持続することがあり得る。このような仕方でリスクが評価される時間までに、損害がすでに起きていることもある。この点で、いくつかの従来のソリューションは、リスクを評価するために、かなりのコンピューティング資源を費やしているが、それでもまだ十分に速くはない。

ERP製品は、様々なベンダによっても供給される。いくつかの例は、SAPからのSAP R/3（登録商標）(またはmySAP ERP（登録商標）)、Oracle CorporationからのPeopleSoft（登録商標）(またはOracle Financials（登録商標）)、SSA Global TechnologiesからのBPCS（登録商標）、Made2Manage SystemsからのEnterprise Business System（登録商標）、NetSuite Inc.からのNetERP（登録商標）、Microsoft Business DivisionからのMicrosoft Dynamics（登録商標）、Ramco SystemsからのRamco e.Applications（登録商標）、SYSPROからのSYSPRO ERP（登録商標）ソフトウェア、およびその他を含む。いくつかまたはすべてのケースで、これらの製品は、互いに互換性がない。それでも、1つの会社が、異なるベンダのERP製品を同時に使用することがあり得ると考えられる。

しかし、このことは、そうした会社をアプリケーション間リスク、すなわち異なるERPシステム間で生じるリスクにさらす。個々のERPシステムはどれも、これらのアプリケーション間リスクを検出することが可能ではない。

会社は、ERPシステムを利用して、継続的に事業プロセス管理を監視し、実施することができるが、そのようなERPアプリケーションが、効果的かつ高い信頼性で不正行為および過失に対する防護を行うほか、非効率性も最小化するように、適切に構成されることについての保証はない。ERPシステムの複雑性のため、リスク管理のシステム内に依然として欠陥が存在し、これらが容易に発見され得ない場合が存在する。これらの管理の故障は、より高い比率の不正行為、著しく高い監査コスト、財務諸表を訂正する可能性の増大、および低下する投資家信頼のため、きわめて高いコストになることがあり得る。

本開示の一態様は、様々なハードウェア/ソフトウェア構成要素および相互接続によって実施され得るビジネスアプリケーションシステムに関し、その一例が、図1のシステム100によって説明される。図1には、ビジネスアプリケーションマネージャ102、ローカルビジネスアプリケーションサブシステム104〜106、およびリアルタイムエージェント104a〜106aなど、様々なデータ処理構成要素が存在する。これらの構成要素は、1つもしくは複数のハードウェア装置、ソフトウェア装置、1つもしくは複数のハードウェアもしくはソフトウェア装置の部分、または上記のものの組合せによって実施されてよい。これらのサブ構成要素の構成は、図3〜図5を参照して、以下でより詳細に説明される。

システム100の構成要素は、会社、パートナシップ、ジョイントベンチャ、企業支部、行政単位、家族、非営利組織、個人、企業合同、またはその他の組織もしくは主体のために、動作させられる。言い換えると、ビジネスアプリケーションサブシステム104〜106によって管理されるデータは、顧客の事業またはその他の関心事に関係する。顧客が、システム100自体を動作させてもよく、または別の主体が、顧客のために、システム100を動作させてもよい。

システム100は、124〜128および129などのユーザインタフェースを介して受け取られたユーザの指図の下で、様々なビジネス活動を実施する。システム100の別の機能は、様々な会社のガイドライン160に違反しないように、ユーザ活動を誘導し、規制し、管理することである。ガイドライン160は、会社方針、政府規制、刑法、会計規則、公正な商慣行、(例えば、設立許可証、法人設立定款、補助金、非営利身分の要件などによって)課される条件、上記の一部もしくは全部の組合せ、またはシステム100のビジネス活動がそれのために行われる主体の活動を規制するその他の所望のガイドラインから成る1つまたは複数の組によって具現されることができる。本明細書全体を通じて「会社」という語が使用されるが、これは、典型的な実施のコンテキストにおいて与えられるもので、ガイドラインを企業またはその他の特定の組織のコンテキストに限定するものと解釈されるべきではない。これらの教示は、考え得るどのような主体にも同様に適用可能であり、そのいくつかの例が、上で提供されている。

説明を容易にするため、ガイドライン160は、システム100の一部として示されている。この点で、ガイドライン160は、システム100によって保存され、または参照されることができ、より具体的には、ストレージ111に格納されることができる。それにも関わらず、ガイドライン160は、システム100の一部を構成する必要はまったくなく、その場合、それらは、説明および理解を容易にするために示され、説明される。

システム100は、様々なローカルビジネスアプリケーションシステム104、106、108に結合される、共用ビジネスアプリケーションマネージャ102を含む。マネージャ102は、個々のビジネスアプリケーションサブシステム内および複数のビジネスアプリケーションサブシステム間で生じるリスクの分析および検出を含む動作を実行するようにプログラムされた、中央モジュールである。

具体的な一例では、マネージャ102は、Java（登録商標）で書かれたソフトウェアモジュールによって実施される。好ましくは、ローカルサブシステム104〜108が互いに非互換である場合でも、マネージャ102は、会社ガイドラインの遵守に関して非互換ビジネスアプリケーションシステムを監視するために、使用されることができる。以下でより詳細に説明されるように、マネージャ102は、リスク監視、シミュレーション、軽減、改善、報告などの様々な高水準タスクを実行するために、リアルタイムエージェント104a〜108aからデータを収集することができる。

図示される例では、ビジネスアプリケーションサブシステム104〜108は、異なるビジネスアプリケーション製品を実施する。実施形態例は、これらのビジネスアプリケーションサブシステムが互いに互換性のない状況を企図している。ビジネスアプリケーションサブシステム104〜108は、ネットワーク接続されたユーザの要求時に、様々な事前定義されたタスクを実行する専用メカニズムをサービスするソフトウェアを提供し、各サブシステムは、ユーザのうちの誰が、そのサブシステムのタスクを実行することを許可されているかも定義する。一例として、OBBAサブシステムは、ERP、ウェブサーバベースの物流、レガシアプリケーション、物理的プロビジョニング、規制もしくはその他の政府規制、またはその他のコンピュータベースのビジネスアプリケーションなどの機能を実行することができる。

ERPサブシステムのいくつかの例は、SAPからのSAP R/3（登録商標）、Oracle CorporationからのPeopleSoft（登録商標）、Oracle CorporationからのOracle Financials（登録商標）、SSA Global TechnologiesからのBPCS（登録商標）、Made2Manage SystemsからのEnterprise Business System（登録商標）、NetSuite Inc.からのNetERP（登録商標）、Microsoft Business DivisionからのMicrosoft Dynamics（登録商標）、Ramco SystemsからのRamco e.Applications（登録商標）、SYSPROからのSYSPRO ERP（登録商標）ソフトウェアなどを含む。レガシアプリケーションのいくつかの例は、ファイルディレクトリ、メインフレームコンピュータ、ファイルサーバ、およびその他のデータリポジトリを含む。

サブシステム104〜108へのビジネスアプリケーションマネージャ102の結合は、それぞれのリアルタイムエージェント104a〜108aを介して生じる。各リアルタイムエージェント104a〜108aは、それぞれのローカルビジネスアプリケーションホスト104〜108のソフトウェアに組み込まれるプログラムモジュールである。一例では、「組み込み」リアルタイムエージェントとは、リアルタイムエージェントが、同じソフトウェア、ファームウェア、論理回路、ハードウェア、またはホスト104〜108のその他の処理機能内に統合されることを意味する。

例えば、SAPソフトウェアパッケージを使用するビジネスアプリケーションサブシステムの場合、組み込みリアルタイムエージェントは、Advanced Business Application Programming(ABAP)などの独自開発のSAPネイティブ言語で記述されることができる。さらに、SAPサブシステム内のリアルタイムエージェントの機能は、SuO1、SU1O、プロファイルジェネレータ(PFCG)、およびユーザ権限付与トランザクションなどのSAPトランザクションに直接接続されてもよい。リアルタイムエージェントの構造および動作は、以下でより詳細に説明される。

サブシステム104〜108は、それぞれのユーザインタフェース124〜128に結合される。ユーザインタフェース124〜128は、ユーザが入力をローカル装置に入力し、出力をローカル装置から受け取るための任意の装置またはツールを含む。マネージャ102は、129などの1つまたは複数のユーザインタフェースにも結合される。例示的なユーザインタフェースは、マウス、キーボード、ビデオディスプレイ、タッチスクリーン、または本開示によって要求される機能を実行するその他の任意の装置、ツール、もしくはソフトウェアモジュールの一部または全部を利用することができる。

ビジネスアプリケーションサブシステム104〜108の各々は、ローカルビジネスタスク(104c〜108c)のステートメントを含む。タスクは、言語、シンタックス、またはホストビジネスアプリケーションサブシステム104〜108専用のその他のフォーマットで叙述される。タスク104c〜108cは、ビジネスアプリケーションサブシステム104〜108のビジネス活動を実施するためにサービスする。ERPシステムによって実施されるビジネスアプリケーションサブシステムの場合、タスク104c〜108cによって実施されるビジネス活動のいくつかの例は、インボイスの作成、インボイスの支払い、インボイスの作成、ベンダ情報の更新を含む。大多数の場合、これらのビジネス活動は、ビジネスプロセスの始めから終わりまでの自動化に関係する。いくつかの例は、調達から支払、受注から入金、生産処理、ならびに人的資源給付金支払いおよび処理を含む。レガシファイルサーバによって実施されるビジネスアプリケーションサブシステムの場合、ビジネス活動は、データの読み取り、データの削除、データの書き込み、およびディスクまたはストレージ管理操作などのファイル操作に関する。

各ビジネスアプリケーションサブシステム104〜108は、104b〜108bなどのロールおよびアサインメントのステートメントも含む。大まかに言えば、ロールおよびアサインメントは、どの人たちがタスク104c〜108cのうちのどれを実行することができるかを指定する。ロールは、ある人またはジョブタイトルが実行することを許可されたタスクの集まりとすることができる。単一ロールのグループである複合ロールも存在してよい。したがって、ロールは、それぞれのサブシステム104〜108におけるタスクの異なる集まりを略述し、アサインメントは、どの人たちがどのロールに割り当てられるかを示す。アサインメントは、人々をロールに直接結び付けてもよく、またはジョブタイトルをロールに結び付け、それとは無関係に、人々をジョブタイトルに結び付けてもよい。したがって、ロール/アサインメント104b〜108bの1つの機能は、対応するビジネスアプリケーションサブシステムが要求されたタスク104c〜108cを実行するために、要求ユーザがもたなければならない必要な許可を示すことである。

サブシステム104〜108のERP実施の場合、ロールおよびアサインメント104b〜108bは、(例えば)ある人がインボイス作成を実行し得ることを規定することができる。サブシステム104〜108のレガシ実施の場合、ロールおよびアサインメントは、(例えば)ネットワークユーザによって共用されるデータリポジトリなどのシステム資源への人々のITアクセス権を規定することができる。

マネージャ102は、1つまたは複数のサーバ、ハードドライブ、パーソナルコンピュータ、メインフレームコンピュータ、光ディスク、または本開示の必要に適したその他の任意の適切なデジタルデータストレージ装置などの、デジタルデータストレージ111を含み、またはデジタルデータストレージ111にアクセスする。ストレージは、この例では、サブ構成要素114、122を含む。これらのサブ構成要素は、同じまたは異なる物理装置、論理装置、記憶セクタもしくはその他の領域、レジスタ、ページ、リンクリスト、リレーショナルデータベース、または制限なくその他のストレージユニットによって実施されてよい。ストレージ111のサブ構成要素の動作および使用は、以下でより詳細に説明される。以下は手短な説明である。

コンフィギュレーションレコード122は、ビジネスアプリケーションマネージャ102の機能を設定または変更するために使用される、様々なデフォルト設定およびユーザ選択可能オプションなどを維持する。言い換えると、コンフィギュレーションレコード122は、ビジネスアプリケーションマネージャ102がどのように動作するかに関する様々な選択肢のレコードを提供する。コンフィギュレーションレコード122は、(1)ビジネスアプリケーションサブシステム104〜108のローカルユーザの要求、(2)(例えばユーザインタフェース129を介する)システムレベルユーザ、(3)デフォルト、(4)上記の組合せ、(5)別のメカニズムによって設定されるいくつかの設定を含むことができる。したがって、コンフィギュレーションレコード122は、本開示全体を通じて説明されるようなビジネスアプリケーションマネージャ102の動作の実質的にあらゆる面に関する、デフォルトおよび/またはオプション設定のレコードを提供することができる。

大まかに言えば、リスクフレームワーク114は、1つまたは複数のビジネスアプリケーションサブシステム104〜108がそれらを許可するように構成された場合、会社のガイドライン160に対する違反を犯そうとする者に扉が開かれる、活動および条件を定義する。

リスクフレームワーク114の1つの構成要素は、システム100を使用して犯すことが可能な(上述の)適用可能な会社のガイドラインに対する違反を略述する、違反モジュール114aである。それと関連して、ビジネス活動の危険な組合せモジュール114bは、1人の人に委ねられた場合に、違反114aのうちの1つを犯す潜在能力をその人に与える、ビジネス活動の組合せを略述する。

一例では、違反114aの利用を引き起こす潜在性を含むビジネス活動の組合せの定義は、過失または不正行為のリスクを防止または低減することを意図した、主要内部統制としての職務分離を含む。これは、1人の個人が、ビジネストランザクションのすべてのフェーズにわたる管理を行わないことを保証することによって達成され得る。一例では、権限付与、保管、記録維持、および照合という、4つの一般的な職務のカテゴリが存在する。理想的なシステムでは、異なる従業員が、これら4つの主要機能の各々を実行する。言い換えると、どの従業員も、これらの任務のうちの2つ以上を管理しない。資産がより流通性の高いものになるほど、特に現金、譲渡性小切手、および在庫を扱う場合、適切な職務分離の必要性が大きくなる。

職務分離が望ましいことのあるビジネス領域が存在する。現金取り扱いは、その一例であるが、それは、現金が高流動性資産であるからである。これは、金の行き先の痕跡を残さずに、金を取って使うことが容易であることを意味する。

資金を受け取り、会計記録にアクセスし、または任意のタイプの資産を管理するどのような部門も、職務分離に関与することができる。兼任できない職務のいくつかの例は、
*トランザクションを許可することと、そのトランザクションの結果もたらされる資産を受け取ることと、その資産を保管し続けること、
*小切手(内金払い)を受け取ることと、帳簿からの抹消を承認すること、
*現金を預金することと、銀行口座通知書を照合すること、
*タイムカードを承認することと、給与小切手の保管を行うこと、を含む。

一般的ビジネス活動の各リスクを伴う組合せ114bについて、リスクフレームワーク114は、ローカルマニフェステーションモジュール114cによって管理される、そのリスクのローカルマニフェステーションを説明する。特に、リスクを伴うビジネス活動の与えられた組合せ114bについて、ローカルマニフェステーションモジュール114cは、これらの組合せを実施するために使用され得る、すべての異なるビジネスアプリケーションサブシステム固有のタスク104c〜108cを識別する。この点で、ローカルマニフェステーションモジュール114cは、サブシステムタスク104c〜108cを、特定のコード、エントリ、コンフィギュレーション、組合せ、またはそのサブシステムのローカルビジネスアプリケーション言語に適合したその他の詳細によって識別することができる。ローカルマニフェステーションは、異なるサブシステム104〜108に個別に適用可能な異なる下位区分(別個に図示されず)を含むことができる。例えば、1つの下位区分は、SAPシステムに特有のローカルマニフェステーションを含むことができ、別の下位区分は、Oracleシステムに特有のローカルマニフェステーションを含むことができるなどである。

一例では、リスクフレームワーク114は、違反114aおよび組合せ114bを省いて、ローカルマニフェステーションモジュール114cによって全体的に実施されることができる。この場合、モジュール114a〜114bは、リスクフレームワーク114の背後にある概念の例示および説明の目的でのみ、ストレージ111内に示される。

サブシステム104〜108の1つがSAP ERPシステムによって実施される例では、モジュール114cのローカルマニフェステーションは、SAP AGのCompliance Calibrator（登録商標）バージョン5.0ソフトウェアからの職務分離規則の大規模なライブラリを使用して実施されてよい。

図1の全体的なビジネスアプリケーションアーキテクチャの他に、本開示の異なる態様は、個々のリアルタイムエージェント104a〜108aの構成に関する。各リアルタイムエージェントは、様々なハードウェア/ソフトウェア構成要素および相互接続によって実施されることができ、その一例が、図2のリアルタイムエージェント200によって説明される。この例では、各リアルタイムエージェント200は、それぞれのホストビジネスアプリケーションサブシステム104〜108に組み込まれるソフトウェアモジュールを含む。

リアルタイムエージェント200の例は、条件-アクションプログラミング202と、様々なその他のモジュール210〜213と、情報マップ220とを含む。以下でより詳細に説明されるように、プログラミング202は、ビジネスアプリケーションサブシステム104〜108内およびビジネスアプリケーションサブシステム104〜108間においてガイドライン160に違反する潜在性をマネージャ102が識別し、防止し、報告するのを助けるために、ビジネスアプリケーションマネージャ102と協力して、ビジネスアプリケーションサブシステムレベルの機能を実行する。説明を容易にするため、リアルタイムエージェント200は、サブシステム104をホストとするコンテキストにおいて説明される。

プログラミング202は、モジュール210〜213と一緒に、1組の動作命令をリアルタイムエージェント200に提供する。大まかに言えば、プログラミング202は、条件を識別し、それに応答して、モジュール210〜213のうちの1つまたは複数を起動する。リアルタイムエージェント200およびそのサブ構成要素の動作は、以下でより詳細に説明される。

情報マップ220は、検知、収集、実行、および報告モジュール210〜213によってアクセス可能である。マップ220は、様々なクライアントデータ、コンフィギュレーション設定、およびホストビジネスアプリケーションサブシステム内に保存されるその他の情報のロケーションを列挙する。

データは、物理もしくは論理アドレス、装置、ポインタ、セクタ、またはその他の有用な識別子によって列挙されることができる。例104では、マップ220は、サブシステム104のロール104b、タスク104c、コンフィギュレーションデータのロケーション、ならびにその他のクライアント情報、メタデータ、およびコンフィギュレーション設定のロケーションを示す。

本開示の構造的特徴を説明してきたが、今からは、本開示の動作的態様が説明される。本明細書で開示される実施形態に関連して説明されるどの方法、プロセス、またはアルゴリズムの動作も、直接ハードウェアで、ハードウェアによって実行されるソフトウェアで、または両方の組合せで実施されてよい。

ビジネスアプリケーションサブシステム104〜108の各々は、サブシステムの特定のソフトウェアパッケージおよび管理される顧客の課題に応じて、様々なコンピュータベースのビジネスアプリケーション動作を実行する。ソフトウェアパッケージに関しては、これは、SAPからのSAP R/3（登録商標）(またはmySAP（登録商標）)、Oracle CorporationからのPeopleSoft（登録商標）またはOracle Financials（登録商標）、SSA Global TechnologiesからのBPCS（登録商標）、Made2Manage SystemsからのEnterprise Business System（登録商標）、NetSuite Inc.からのNetERP（登録商標）、Microsoft Business DivisionからのMicrosoft Dynamics（登録商標）、Ramco SystemsからのRamco e.Applications（登録商標）、SYSPROからのSYSPRO ERP（登録商標）ソフトウェア、レガシソフトウェア、または別の製品などの製品のよく知られたタスクを含むことができる。顧客の課題に関しては、これは、会計システム、買掛金、在庫システム、政府命令もしくは契約遵守、規制遵守、人的資源、品質管理、またはその他の任意の課題を含むことができる。

具体的な一例では、ビジネスアプリケーションサブシステム104〜108は、インボイスの作成、インボイスの支払い、会計報告の作成など、様々なタスク104c〜108cを実行することをユーザに許可する。しかし、サブシステム104〜108は、ロールおよびアサインメント104b〜108bに従って、タスク104c〜108cがその下で実行される条件を限定する。したがって、サブシステム104のユーザが、タスク104cのうちの1つまたは複数を実行するよう要求し、サブシステム104が、その要求がユーザのロール104bの範囲外にあると決定した場合、サブシステム104は、このタスクの実行を防止し、終了し、または報告する。

図3は、一例による、リアルタイムエージェント104a〜108aの個々の1つを動作させるためのシーケンス300を示している。シーケンス300は、より広範なコンテキストにおいて実施されてもよいが、説明を容易にするため、以下の説明は、図1〜図2の特定の環境において行われる。具体的には、シーケンス300は、リアルタイムエージェント104aのコンテキストにおいて説明される。

動作301において、リアルタイムエージェント104aは、動作を開始する。動作301は、例えば、ホストビジネスアプリケーションサブシステム104がインストールされたとき、製造されたとき、コンフィギュレーションされたとき、初期ブートされたとき、再ブートされたときなどに生じることができる。異なる一例として、リアルタイムエージェントは、ホストビジネスアプリケーションサブシステムとは別に、動作を開始してもよい。

動作302において、条件-アクションプログラミング202は、様々な所定の条件のいずれかが存在するかどうかを決定する。大まかに言えば、条件は、検知または収集モジュール210/211によって先に決定されたホストビジネスアプリケーションサブシステムまたはその中で生じるイベントのステータス、ビジネスアプリケーションマネージャ102から受信した通信、モジュール210〜213の実行のステータスなどを含む。以下は条件のいくつかの例を説明する。

リアルタイムエージェント104aがビジネスアプリケーションマネージャ102からの命令の受信を検知(310)したという条件。
・タスク310〜313(以下で説明される)のうちの1つまたは複数が完了したという条件。
・タスク310〜313のうちの1つまたは複数が一定の結果を伴って完了したという条件。例えば、ユーザが104bのロールを変更する要求をサブミットしたことを検知タスク310が見つけたこと。
・リアルタイムエージェント104aが一定のデータ、動作コンフィギュレーション、またはサブシステム104もしくはそのいずれかのサブ構成要素のその他の状態もしくはコンテキストの存在を検知(310)したことを示す条件。
・サブシステム104および/またはそれとユーザもしくはビジネスアプリケーションマネージャ102との通信に関するその他の条件。

条件の発生を見落とさないように、条件のチェック(動作302)は、314によって示されるように、繰り返し実行される。動作302は、タイマまたはクロックに応答して、頻繁に発生するイベントまたはその他のトリガに応答して、定期的または非定期的スケジュールで実行されることができる。

動作302において、条件-アクションプログラミング202が事前定義された条件の発生を見つけた場合、プログラミング202は、プログラミング202の所定のロジックに従って、動作310〜313の1つまたは複数を起動する。タスク310〜313は、それぞれのモジュール210〜213によって実行され、上で説明されたモジュール210〜213の機能に従って動作する。

動作310において、検知モジュール210は、メッセージ、信号、イベント、およびホストサブシステム104内のその他の事象を受動的に観察する。例えば、モジュール210は、ユーザがロールまたはアサインメント104bを変更するよう要求した時を検知する。別の例として、モジュール210は、あるベンダに対してオフにされた、「重複インボイス検知」オプションなどの要注意のコンフィギュレーションパラメータの存在を検知することができる。モジュール210は、反復エントリが与えられた閾値を超えた時など、臨界データ値も検知することができる。別の例として、モジュール210は、ビジネスアプリケーションマネージャ102からコマンドが受信された時を検知することができる。

十分な頻度で動作310を実行するため、関連する条件(302)は、反復アラーム、スケジュールなどの到着とすることができる。条件-アクションプログラミング202に応じて、動作310の異なる結果の生成が、異なる条件を生成することがあり、それは、(動作302が再び実行されたとき)その他のタスク310〜313の実行をトリガする。例えば、動作310は、ロールを生成するためのユーザ要求を検知することがあり、それは、ビジネスアプリケーションマネージャ102へのこの状況の報告(313)を生じさせる条件(302)を構成する。

動作311において、適切な条件(302)に応答して、収集モジュール211が、ホストビジネスアプリケーションサブシステムにおける活動についての情報を能動的に獲得する。

例えば、収集モジュール211は、ホストサブシステム104のロールおよびアサインメント(104b)、タスク104c、サブシステム104のその他のデータ、サブシステム104のデフォルトまたはユーザコンフィギュレーションなどから、情報を取り出すことができる。収集モジュール211の動作311のさらなる例として、これらは、上で説明された管理のいずれかをサポートする情報を収集するよう求めることができる。タスク311を実行する際に、収集モジュール211は、マップ220を使用する。例えば、情報を求める一般的な要求に応答して(動作302)、モジュール211は、動作311において、マップ220を調べて、そのようなデータが配置されたホストビジネスアプリケーションサブシステム104内の特定の記憶ロケーションを識別することができる。

動作311に関して、先行条件(302)のいくつかの例は、ビジネスアプリケーションマネージャ102からの直接コマンド、またはタスク310〜313のいずれかの完了、タスク311〜313の特定の結果などを含む。条件-アクションプログラミング202に応じて、動作311の異なる結果の生成が、異なる条件を生成することがあり、それは、動作302が再び実行されたとき、その他のタスク311〜313の実行をトリガする。例えば、タスク311の完了は、ビジネスアプリケーションマネージャ102への結果の報告313、または後続のアクションの実行(312)をトリガ(動作302)することができる。

動作312において、実行モジュール212は、リアルタイムエージェント200の肯定的行為を実行する。一例として、実行モジュール212は、ロールおよびアサインメント(104b)の変更を防止し、ユーザへのロールの割り当てを防止するなどすることができる。別の例として、実行モジュール212は、「ケース」を生成し、ケース番号を割り当て、検知および収集モジュール210、211から獲得された様々な情報をケースに記入することができる。動作312の場合、条件(302)は、実行モジュール212が、要求、トリガ、もしくはビジネスアプリケーションマネージャ102によって開始されたその他の行為に応答して、または別のタスク310〜313の完了もしくは結果に応答して動作することを、指定することができる。

動作313において、報告モジュール213は、メッセージ、ファイル、データコンパイル、アラート、またはその他の報告をビジネスアプリケーションマネージャ102に送信する動作を指示する。動作313は、ビジネスアプリケーションマネージャ102からのコマンドなどの条件(302)に応答して、またはタスク310〜313のうちの先行タスクの完了もしくは結果に応答して実行される。

自由に使えるモジュール210〜213を用いて、プログラミング202は、先行する様々な条件(302)を有する様々な組合せでタスク310〜313を組み合わせることによって、複雑な動作を組織化することができる。いくつかの例は、検知と実行、検知と報告、収集と実行と報告などの複合動作を含む。例えば、ユーザがロール変更を要求したことを検出(310)した検知モジュール210に応答して、プログラミング202は、そのユーザについての情報を収集(311)するようモジュール211に指図し、次に、収集された情報についての報告をビジネスアプリケーションマネージャ102に送信(313)するようモジュール213に指図することができる。

図4は、本開示の方法態様の一例による、複数の非互換のビジネスアプリケーションサブシステム間で生じる動作を含む、様々なシステム機能を実行するためのシーケンス400を示している。シーケンス400はより広範なコンテキストにおいて実施されてもよいが、説明を容易にするため、以下の説明は、図1〜図2の特定の環境において行われる。より具体的には、シーケンス400は、ビジネスアプリケーションマネージャ102を参照して説明される。

大まかに言えば、動作401において、ビジネスアプリケーションマネージャ102は、システム100の管理を開始する。動作401は、ビジネスアプリケーションマネージャ102のインストール、コンフィギュレーション、再コンフィギュレーション、ブートアップ、別のリアルタイムエージェントの追加、マネージャ102などのシステム構成要素のアップグレード時などに開始することができる。ビジネスアプリケーションマネージャ102が開始(401)した後、マネージャ102は、様々なトリガのうちの1つが発生したかどうかを質問(402)する。各トリガ402は、様々な事前定義されたタスク、イベント、条件、またはその他の事象のうちの1つである。トリガのいくつかの例は、リアルタイムエージェント104a〜108aの1つからの与えられたメッセージの到着、所定の時刻への到達、カウンタの満了、ビジネスアプリケーションサブシステムにおいてガイドライン160の違反が発生する潜在性を有する条件の検出などを含む。異なるトリガの例は、以下でより詳細に説明される。

トリガ(402)の発生は、ビジネスアプリケーションマネージャ102にタスク404、412、414、416のうちの1つを実行させる。いずれの場合も、トリガ(402)のチェックは、プロセス404、412、414、416のうちの1つがそれ以前のトリガのためにすでに進行中であるかどうかに関わらず、発生する新しいトリガを見落とさないように繰り返し(403)実行される。

動作404において、ビジネスアプリケーションマネージャ102は、ロール104b〜108bを生成し、修正し、再定義し、修正する際に、ビジネスアプリケーションサブシステムユーザを支援する。動作404のためのトリガ402は、ローカルリアルタイムエージェントが、ビジネスアプリケーションマネージャ102に、ユーザが新規ロールの追加または既存ロールの修正を要求した旨の報告を送信(図3の動作313)したときに生じる。本開示では、そのような要求は、「ロール変更」要求と呼ばれる。ロール変更要求の検出(402)に応答して、動作404において、ビジネスアプリケーションマネージャ102は、ユーザのロール変更要求を受信し、分析し、処理する。

一例では、動作404は、SAP AGのROLE EXPERTバージョン4.0ソフトウェア製品を利用することができる。動作404の間、ビジネスアプリケーションマネージャ102は、実質的にリアルタイムなインタフェースをユーザおよびホストビジネスアプリケーションサブシステムに提供するために、適用可能なリアルタイムエージェントを利用する。ロール管理タスク(404)のいくつかの動作例は、以下のもの、すなわち、
*サブシステム境界に関わりなく、複数のロールと、ジョブまたは位置に対するそれらの共通関係とを示すこと、
*ロール定義を定義し、維持すること、
*タスクを定義し、維持すること、
*ロールおよびロール定義を比較すること、
*ユーザ情報を表示すること、
*ロールに割り当てられたオブジェクトを検討すること、
*複合ロールを定義すること、を含む。

これらに加えて、動作404は、いくつかの例として以下のサービスを用いて、多くの報告およびユーティリティを円滑化することができる。
*ロール報告を生成すること。
*メニューおよび権限付与においてTCodeをチェックすること。
*ユーザのロールを比較すること。
*ユーザに割り当てられたロールを列挙すること。
*ロールおよびトランザクションを列挙すること。
*ロールステータスをチェックすること。
*派生ロールを生成または修正すること。
*ロールまたはユーザに対する権限付与を数えること。
*所有者、ロール、およびユーザを分析すること。
*ユーザまたはロールによって実行されるトランザクションを識別すること。

適宜、ロール管理404は、ロール生成に関する様々な増強機能と共に適用されることができる。ロールが生成されるとき、ロールは、ジョブに関する一般的な位置または活動をカバーするように生成されることができる。組織内の多くの人々は、同じ活動を完了することができてよいが、1つのエンティティまたはロケーションに関連付けられた活動のみに限定される。これは、活動は同じであり続けるが、ロケーションまたはエンティティは変化し得ることを意味する。そのため、Accounts Payable Clerkは、数百の会社プラントに存在してよいが、その場合、そのロールの唯一の違いは、どのプラントか、である。プラントのための選択値が指定された後、リアルタイムエージェントは、組織的制限をロールに挿入することによって、すべての変形を生成する。数千のロールは、リアルタイムエージェントを使用して、変更される必要のある共通要素を有するすべてのロールを見つけることによって、維持されることもできる。例えば、再組織化または合併は、あるロール内容を変化させることがある。ネイティブシステムツールによって提供される従来の1つずつの方法を使用するのとは対照的に、リアルタイムエージェントは、影響されるロールを表示し、特有の値を有するすべてのロールをユーザが変更することを可能にする。

上記の機能に加えて、動作404は、以下で説明される動作405のリスク分析を利用する、様々なリスク報告を円滑化することもできる。サブシステム104〜108のユーザによって要求されるリスク報告は、リスクまたは競合、ユーザ、ロール、プロファイル、またはHRオブジェクトによる危険なトランザクションの発生などを提示する報告を含むことができる。

プロセス400は、動作404に関する多くの周辺タスクを含む。すなわち、ビジネスアプリケーションマネージャ102は、ロール管理プロセス404に着手すると、その他の関連プロセスをユーザに提供する。ユーザをタスク405〜408に導くのに加えて、タスク404は、様々なユーザ操作の実行に対する知的かつ系統立ったアプローチを実施するために、異なるタスク405〜408の使用を調整することができる。例えば、要求されたロール変更要求が、(以下で説明されるタスク405において学習される)リスクフレームワーク114に違反することが分かった後、タスク404は、承認者が、ロールを1つずつ選択解除し、その後、その修正されたプロファイルの結果をシミュレート(以下で説明されるタスク407)することを可能にすることができる。これは、提案されたロールが職務分離違反を起こし続けているかどうか、またどの時点で違反が止むかを、承認者がチェックすることを可能にする。このようにして、承認者は、どの特定のロールまたはロールの組合せが職務分離違反の原因であるかを切り分けることもできる。別の例では、動作404は、管理者がその存在を承諾することなく要注意のアクセスが導入されないよう保証し、使用するロールが利用可能にされる前に要注意のアクセスが承認されることを保証する。別の例では、動作404は、要注意のロールを利用するときに職員の活動を追跡する緊急「消防士」機能を提供することができる。

適宜、動作404は、コンピュータ支援の改善機能も含むことができ、それによって、ビジネスアプリケーションマネージャ102は、動作405の分析において見出されたリスクを取り扱う際に、(ロール承認者などの)ビジネスアプリケーションサブシステムユーザを支援する。改善において、ビジネスアプリケーションマネージャ102は、動作405において見出されたリスク違反を引き起こした要求もしくは提案されたロール追加もしくは変更の削除、または軽減406の開始などの、選択肢を調整する。これらの選択肢のうちの選択された選択肢を完了した後、結果のロール変更は、ガイドライン160をより良く満たす。

さらに、改善は、リスクを調査するためにとられるアクションのタイムリな報告および文書化を含むことができ、管理者が能動的にリスクを管理しており、かつ/または規制を遵守している証拠も提供することができる。プロセス制御の場合、危険な条件の報告は、ルールにおける「許容」レベルを超えたトランザクションに基づくことができる。一例は、支払い期間は通常30日であるのに、1つのトランザクションにおいて60日に変更されている場合である。責任者への通知は、責任者らが、その例外に関連する状況を評価し、それを変更し戻すこと、またはその状況および差異の正当理由を文書化することを可能にする。これは、財務報告制限または規制が違反されていないことを確認するために検討される必要がある、業務の通常の進行の外部で生成された特別な1回限りのトランザクションに対してのみ有力である。タスク405〜408のいくつかの詳細な例が以下で説明される。

ランニングリスク分析:動作405において、ビジネスアプリケーションマネージャ102は、(404からの)要求された各ロール変更を分析して、それがリスクフレームワーク114に違反するかどうかを決定する。例えば、ビジネスアプリケーションサブシステム104の場合、ビジネスアプリケーションマネージャ102は、ロール変更要求を分析して、提案されたロール変更が、104bにおいて実施された場合に、リスクフレームワーク114に違反するかどうかを決定する。説明を容易にするために、ロール「変更」は、ロール修正の他にロール追加も含むと理解されたい。

動作405は、ユーザもしくは承認者の要求時に、またはユーザがロール変更要求をサブシステムに対してサブミットしたときは常に自動的に、実行されることができる。動作405において、ビジネスアプリケーションマネージャ102は、要求の内容、対象ロールについての情報などを含む、ロール変更要求に関するすべての関連情報を、サブシステム104から収集するために(かつ報告し戻すために)、適切なリアルタイムエージェントを起動する。要求される情報は、例えば、リスクフレームワーク114によって規定されることができる。この情報を用いて、次にマネージャ102は、収集された情報をローカルマニフェステーション(モジュール114c)と比較して、一致が存在するかどうかを調べる。収集された情報が、関連ホストサブシステム104〜108に適したローカルマニフェステーション114cと一致する場合、提案されたロール変更は、会社ガイドライン160に違反する潜在性を含む。

好ましくは、すべてのサブシステム104〜108にわたるロール管理を中央で監督するビジネスアプリケーションマネージャ102の位置のため、リスクが1つ1つのビジネスアプリケーションサブシステム内には存在しない場合であっても、マネージャ102は、アプリケーション間分析を実行して、複数のビジネスアプリケーションサブシステム間で生じるリスク(例えば、ガイドライン160の違反に対する潜在性)を検出することもできる。この点で、動作405は、すべての関連情報をそれぞれのサブシステム104〜108から収集するようリアルタイムエージェント104a〜108aに指図し、このデータを一括し、一括されたデータを全体としてローカルマニフェステーション114cの集団と突き合わせて分析することによって、与えられたロール変更要求を検討する。

したがって、ビジネスアプリケーションマネージャ102は、サブシステム104〜108全体から問題を検出することができる。一例では、ビジネスアプリケーションマネージャ102は、各サブシステムに出掛け、そのシステムにおいて「ユーザid」を探し、ルールフレームワーク内の危険な組合せと比較するための技術情報を検出し、次に収集する。一致が存在するとき、収集された原データは、どのデータがどのシステムに属するかを追跡することができる。例えば、ユーザが1つのサブシステムにおいてベンダを更新し、別のサブシステムにおいて支払いを行うことができる場合、アプリケーションマネージャ102は、両サブシステムを発見し、その後、どちらのシステムのどのロールから一致が見出されたかを報告する。

このようにして、その後、ビジネスアプリケーションマネージャ102は、複数のビジネスアプリケーションサブシステム間で生じるどのようなリスク(114a)も検出することができる。さらなる利点として、動作405の分析を実行するのに必要とされる情報は、ビジネスアプリケーションサブシステム104〜108からの時間を浪費する情報のダウンロードを待つ必要なく、リアルタイムエージェント104a〜108aを使用して、実質的にリアルタイムに獲得される。

動作405は、以下のシーケンス500の説明(図5)においてより詳細に説明される。一例では、動作405は、COMPLIANCE CALIBRATOR（登録商標）バージョン5.0および/またはCONFIDENT COMPLIANCE（登録商標）バージョン1.2などのSAP AGソフトウェア製品の機能を利用する。

動作406において、ビジネスアプリケーションマネージャ102は、リスク軽減を実行する。一例では、この動作は、ユーザの提案したロール変更がリスクフレームワーク114に違反することをビジネスアプリケーションマネージャ102が(動作405において)検出したときは常に自動的にトリガされる。軽減は、リスクフレームワーク114の違反に対処するためのアクションである。軽減管理は、識別されたリスクまたは予期される監査例外を免除または無効化して、それがリスクフレームワーク114に違反する場合であっても発生することを許可する。

特定のリスクフレームワーク114の違反を選択して、承認者は、監査証跡を維持するためにシステムにおいて獲得された管理者承認を用いて、その違反を無効化することができる。軽減管理のいくつかの例は、新規または変更ロールの存在を与えられた期間に限定すること(すなわち、計画されたロールの満了)、ロールに関する活動に関する報告を自動的に生成することを含む。

別の例は、危険なタスクを分離することが可能でないために、危険な組合せの多くが1人の人によって実行されなければならない、小規模オフィスにおいて有用である。この場合、ビジネスアプリケーションマネージャ102によって提供される軽減動作406の一例は、この人がこれらの危険な組合せを実行するときに、ビジネスアプリケーションマネージャ102に警告するよう、リアルタイムエージェント104a〜108aをプログラムすることである。今度は、ビジネスアプリケーションマネージャ102が、発生が合法性であることを保証するためにトランザクション支援文書を求めるようその人の監督者を促す。別の例では、マネージャ102とリアルタイムエージェントは、監督者(またはそのロールが危険な組合せを含むその他の人)によって日常的に再検討され、支援文書と比較され得る変更の詳細な報告を、協力して生成する。別の例では、マネージャ102とリアルタイムエージェントは、危険な組合せが限定された期間のみ、例えば、指名された人が、危険な組合せの他の半分である別の人のタスクを引き受けている間のみ承認されることを可能にする。この場合、ビジネスアプリケーションマネージャ102とリアルタイムエージェントは、限定された期間が終了したとき、その人に警告し、そのアクセスを自動的に削除するようにプログラムされることができる。

加えて、軽減手続き406は、軽減アクションを開始するために、イベントを「監督者」または第3者に通知するように構成されることもできる。

これは集められたシステム情報であるので、システムロケーションとは関係なく、誰が組合せを実行したかに基づいて、別のロケーションではない1つのロケーションの、管理において指定された人に通知するための決定が行われることができる。これは、1つの共通の軽減管理を利用して、同じ方法でリスクを管理しながら、組合せを実際に実行したと分かった人に基づいて、異なる個人に実行を通知することを可能にする。別の例では、軽減406において、ビジネスアプリケーションマネージャ102は、事前承認代替管理を用いて検出されたリスクを管理するために、現在のユーザのための軽減管理を記録するためのコマンドを発行する。一例では、軽減動作406の実施は、SAP AGのCOMPLIANCE CALIBRATOR（登録商標）ソフトウェア製品の機能を利用する。

上で説明されたように、手続き406は、サブシステム104〜108内のデータへの実質的にリアルタイムのアクセスを獲得することによってなど、多くの方法でリアルタイムエージェントアーキテクチャから利益を得る。さらに、リアルタイムエージェントは、組合せが論理的に可能であることを報告するのではなく、2つの危険な組合せが実際に発生したときに、発生した事象を報告するために使用されることもできる。リアルタイム態様は、システム100が、上で説明されたある事業制限のために存在しなければならない危険な組合せに対する組み込み改善ソリューションを提供することを可能にする。別の利点は、個人が危険なアクセスを行う例外を生成する際に、それらの実行の事象を発生と同時にリアルタイムに速やかに報告するために、監視メカニズムが適所に存在することである。

動作407において、ビジネスアプリケーションマネージャ102は、シミュレーションを実行する。一例では、この動作は、ユーザの提案するロールがリスクフレームワーク114に違反することをビジネスアプリケーションマネージャ102が検出したときに自動的にトリガされる。別の選択肢として、ユーザは、要求によって手動で動作407を開始することもできる。

シミュレーション407において、スーパーバイザ、マネージャ、またはその他のルール承認者は、様々な仮定状況を提案し、ビジネスアプリケーションマネージャ102は、これがリスクフレームワーク114に違反するかどうかを決定する。例えば、仮定状況は、与えられたロール追加、ロール修正、ロール割り当て、軽減条件などの詳細を指定することができる。有利には、動作405のアプリケーション間分析と同様に、動作407のシミュレーションも、一括化およびその他の技法を実行して、仮定状況に含まれるリスクのアプリケーション間分析を同様に実行することができる。一例では、シミュレーション動作407の実施は、SAP AGのCONFIDENT COMPLIANCE（登録商標）およびCOMPLIANCE CALIBRATOR（登録商標）ソフトウェア製品の機能を利用する。

手続き407は、例えば、サブシステム104〜108内のデータへの実質的にリアルタイムのアクセスを獲得し、その結果、最新データによるきわめて正確なシミュレーションを提供することによって、上で説明されたリアルタイムエージェントアーキテクチャから利益を得る。

リスク終結:動作408において、ビジネスアプリケーションマネージャ102は、リスク終結プロセスを実行する。

特に、ユーザの提案するロール変更または追加がリスクフレームワーク114(動作405)に違反する場合、動作408は、(1)リスクがあるにも関わらずロール変更を許容するが、ロール変更について誰かに通知するか、または(2)ロール変更が達成されることを防止する。動作408の特定のアクションは、シーケンス500(図5)を参照して、以下でより詳細に説明される。一例では、動作408は、SAP AGのCOMPLIANCE CALIBRATOR（登録商標）ソフトウェア製品を利用することができる。

確信的遵守:上で述べられたように、ロール管理動作404およびそのサブプロセス405〜408は、いずれか1つのビジネスアプリケーションサブシステム104〜108のロール104b〜108bがリスクフレームワーク114に違反しないこと、またロール104b〜108bがプラットフォーム間リスクエクスポージャを提示しないよう保証することを助ける。それにも関わらず、ガイドライン160に違反する潜在性をやはり提示するロールがいくつかの状況において定義され得ることが依然として考えられる。例えば、軽減管理(406)のため、他の状況では禁止されるいくつかのトランザクションの組合せが許可されるが、それらが与えられた許容範囲を決して超えていないことを確認するために、管理者にそのようなトランザクションを監視させることが望ましい。別の例は、多くの能力を含むロールが緊急状況のために許可されなければならない場合である。これらの場合、ロールは、違反を伴って構成されるが、緊急時のみに個人に割り当てられるこれらのロールの承認を包囲する軽減管理が存在する。

確信的遵守プロセス412は、上記およびその他のそのような可能性に対処する。大まかに言えば、確信的遵守動作412において、ビジネスアプリケーションマネージャ102は、規定された条件についてサブシステム104〜108を監視する。この検討の結果に基づいて、次にビジネスアプリケーションマネージャ102は、1つまたは複数の報告を発行し、さらに指定された人による指定されたフォローアップアクションを開始することができる。手続き412は、サブシステム104〜108内のデータへの実質的にリアルタイムのアクセスを獲得することによって、上で説明されたリアルタイムエージェントアーキテクチャから利益を得る。

最初に、確信的遵守412のためのトリガ(402)は、有資格マネージャなど、認証されたユーザによるプロセスの起動である。この時、ユーザマネージャは、ビジネスアプリケーションマネージャ102と対話を行い、サブシステム104〜108において監視される条件を定義する。すなわち、ユーザは、所望のタスク104c〜108c、ロールおよびアサインメント104b〜108b、マスタデータ(例えば、顧客およびベンダ)、サブシステムコンフィギュレーションオプション、システムコンフィギュレーションオプションの変更など、監視されるアイテムを指定する。ユーザは、これらの条件が発生したときに常にとられるアクション、すなわち、(1)報告を生成すること、およびそのような報告のフォーマット、内容、受け手、(2)生成されるログまたはその他の監査証跡を準備すること、(3)ロール管理(404)、軽減(406)、もしくは別のプロセスの開始など、一定の条件が生じたとき常に、人的ワークフローを発動すること、ならびに/または(4)一定のアクションの発生を停止もしくは防止するために、サブシステム104〜108のネイティブソフトウェアと共に機能することなどを指定することができる。

この初期セットアップの後、確信的遵守412は、指定された条件のいずれかが発生したときに再トリガ(402)される。すなわち、リアルタイムエージェント104a〜108aは(ビジネスアプリケーションマネージャ102によってプログラムされたように)、与えられた条件を検出し、それらの発生をビジネスアプリケーションマネージャ102に報告し、それに基づいて、ビジネスアプリケーションマネージャ102は、報告の生成、ログの準備、人的アクションの発動など、事前指定されたアクションをとる。

ユーザ指定の条件に加えて、確信的遵守412は、知られた弱点、一般に面倒な領域、特に深刻な結果を有する欠陥など、デフォルトまたはシステム指定の条件の発生について、サブシステム104〜108を監視することもできる。これらの条件に応答して、プロセス412は、報告の生成、ログの準備、人的ワークフローの発動、アクションの発生の停止など、ユーザ指定の条件の場合と同様のフォローアップアクションを実行することができる。

さらなる一例として、指定された許容範囲または条件を検出したとき、リアルタイムエージェントは、改善ケースを生成することができ、それを指定された人またはグループにビジネスアプリケーションマネージャ102を介して流す。ビジネスアプリケーションマネージャ102は、その後、アクションまたは例外の正当理由に関して、そのケースを文書化する。ここでは、改善は、そのケースが閉じられる前に、例外が訂正されるか、または適切に正当化されることを確実にするため、確信的遵守412内で開始され、追跡される。

別の例として、サブシステム104〜108の1つにおける(会社ガイドライン160に違反する)重複支払いの検出を解消するために、管理者がコンフィギュレーション変更を開始する場合、関連リアルタイムエージェント104a〜108aは、これを検出し、それをビジネスアプリケーションマネージャ102に報告し、ローカルサブシステムで実施されるまで変更を防止するように自動的に動作する。

一態様によれば、確信的遵守412は、リアルタイムかつ連続的に監視されるプロセスの許容範囲および閾値を設定することによって、ビジネスプロセスにおけるボトルネックおよびチョークポイントを特定するのに役立つ。

確信的遵守412は、例えば、ビジネスアプリケーション監視メカニズムにおける規定されたホットスポットおよびホールを監視し、また追加的な管理者指定の基準にも注意を払う。動作412は、マスタデータ、コンフィギュレーション、および主要ビジネスプロセスにおけるトランザクションを監視することによって、管理の有効性に対する可視性も高める。適宜、動作412は、マネージャおよび監査人に管理欠陥への即座のアクセスを与えるために、ロールベースのダッシュボードを提供することができる。確信的遵守412は、さらなる包含機能、すなわち、(1)調達から支払、受注から入金、資金調達のためのビルトインマスタ管理、(2)自動かつ一貫性のあるテスト、(3)管理リポジトリとの統合、(4)例外ならびに関連トランザクションおよび文書の特定、(5)改善ワークフローおよび追跡、(6)その他などを提供するように実施されることができる。

動作414において、ビジネスアプリケーションマネージャ102は、1つまたは複数の出力報告を提供する。

これは、ステータス、コンフィギュレーション、トランザクション履歴、使用、現在のタスク104c〜108cならびに/もしくはロールおよびアサインメント104b〜108b、ビジネスアプリケーションサブシステム104〜108のその他のプロパティもしくはそれらのサブ構成要素、またはリスクフレームワーク114、コンフィギュレーション122などの報告を含むことができる。報告416は、要求時または指定された報告基準に応じて自動的に生成されることができる。

好ましくは、報告416は、サブシステム104〜108内のデータへの実質的にリアルタイムのアクセスを獲得することによって、上で説明されたリアルタイムエージェントアーキテクチャから利益を得る。

上で具体的に述べられた動作412〜414に加えて、ビジネスアプリケーションマネージャ102は、与えられた環境100内で多くのタスク416を実行するために、拡張または修正されることができる。

リスク終結:上で述べられたように、ビジネスアプリケーションマネージャ102は、ユーザ要求を受け取り、それを処理して、(動作404で)時間と共にロールを追加および変更し、それによって、時間と共にロールの集まり104b〜108bを構築し、改良し、改訂し、更新する。図5は、実施形態例による、トリガ(402)、分析(405)、および終結(408)動作の結合例を提供するシーケンス500を示している。シーケンス500もやはり、より広範なコンテキストにおいて実施されてもよいが、説明を容易にするため、以下の説明は、図1〜図2の特定の環境において行われる。

動作502において、ビジネスアプリケーションマネージャ102は、ロール変更要求の通知、すなわち、既存ロールを修正し、またはレコード104b〜108bの1つに新規ロールを追加するためのユーザ要求、権限付与データを変更するためのユーザ要求、プロファイルを追加し、または変更するためのユーザ要求などの通知を受け取る。より具体的には、これは次のように発生する。最初に、ユーザが、(124などの)インタフェースを操作して、ロールを変更または追加するための要求をサブミットする。例えば、マネージャ、スーパーバイザ、またはその他のロール承認者は、新規雇用者のためのロールを追加し、または新しい人を既存ロールに関連付けるために、ユーザインタフェース124を操作して、ビジネスアプリケーションサブシステム104に要求をサブミットする。リアルタイムエージェント104aは、ビジネスアプリケーションサブシステム104における一定の活動を検知(図3の動作310)するために、継続的に検知モジュール210(図2)を使用しながら、ロール変更要求を検出する。

検知されたロール要求に応答して、プログラミング202は、ロール変更要求をビジネスアプリケーションマネージャ102に報告(図3の動作313)するようモジュール213に指図する。動作502において、ビジネスアプリケーションマネージャ102は、この報告を受け取る。好ましくは、ロール変更要求は、ビジネスアプリケーションサブシステム104のソフトウェアに組み込まれたリアルタイムエージェント104aによって報告されるので、ビジネスアプリケーションマネージャ102は、ロール変更要求の通知をリアルタイムに受け取る。

シーケンス500は、ビジネスアプリケーションマネージャ102が別のロール要求を受け取ったときは常に、502において再スタートさせられ、したがって、継続的に動作する。動作503において、ビジネスアプリケーションマネージャ102は、要求を完全に処理するために、すべての適用可能な情報をサブシステム104から獲得するようリアルタイムエージェント104aに指図する。

ビジネスアプリケーションマネージャ102は、名前、タイプ、機能、またはその他の高水準指示によって情報を識別する。それに応答して、プログラミング202は、実行モジュール212を起動して、要求された情報をマップ220に対して相互参照し、この情報が実際にはサブシステム104のどこに保存されているかを決定する。その後、プログラミング202は、収集モジュール211を起動して、そのように識別された情報を取り出す。手中の情報を用いて、プログラミング202は、報告モジュール213を起動して、収集された情報をマネージャ102に送信する。

動作504において、ビジネスアプリケーションマネージャ102は、ロール要求がリスクフレームワーク114に違反しているかどうかを評価するために、動作503において収集された情報にリスクフレームワーク114を適用する。この動作は、上で説明された動作405に従って実行される。

動作505において、ビジネスアプリケーションマネージャ102は、動作504の結果に基づいて、とるべき適切なアクションを決定する。動作504が要求されたロール変更によってもたらされるリスクを見出さなかった場合、動作505は、505aを介して動作506に進む。動作506において、ビジネスアプリケーションマネージャ102は、ロール104bに対して要求された変更を実施する際に、許可、実施、または協力するようリアルタイムエージェント104aに命令する。

対照的に、動作504がリスク違反を見出した場合、マネージャ102は、コンフィギュレーション設定122に基づいて、以下の動作の一方を実行する、すなわち、(1)ロール変更要求を許可して、誰かに通知するか(507)、または(2)ロール変更要求を終結させる(508)。パス505bと505cの間の選択は、コンフィギュレーション122内のデフォルトまたはユーザ選択設定によって決定される。一例では、これらの設定は、パス505b〜505cの一方または他方を常に選択するように、選択を規定することができる。別の例では、設定122は、リスク、違反のタイプ、またはその他の条件もしくはコンテキストの本質に基づいて、パス505b〜505cの間の選択の方式を規定することができる。

パス505bが選択された場合、動作507において、ビジネスアプリケーションマネージャ102は、要求されたロール変更を許可する。すなわち、ビジネスアプリケーションマネージャ102は、要求されたようにロール104bの更新を許可するようリアルタイムエージェント104aに命令する。プログラミング202は、したがって、パス50cが選択された場合に発生する、実行モジュールを起動して、要求されたロール変更を阻止することを控える。ロール変更を許可するにも関わらず、ビジネスアプリケーションマネージャ102は、ロールに適した適当な個人、ロール変更要求者、関係事業単位、ITシステムなどを識別し、その後、それらに通知することによって、追加のアクションをとる。通知は、マネージャ、IT管理者、スーパーバイザ、リスク管理職員などに送られることができる。動作507の報告は、例えば、114aまたは114cからの適当なリストなど、違反されたすべてのリスクの一覧を含むことができ、さらに、この報告を準備する際、マネージャ102は、追加の必要とされる情報をサブシステムから収集するよう関係リアルタイムエージェント104a〜108aに指令することができる。

また動作507において、ビジネスアプリケーションマネージャ102は、ログ、トランザクション履歴、またはロール変更に関連するその他の監査証跡にコメントを入力するよう(ロール変更を要求した)ユーザに要求するなど、さらなるアクションを取ることもできる。代替として、動作507は、そのようなログを自動的に生成または更新するようリアルタイムエージェント104aに指令することもできる。

動作505b/507とは対照的に、動作508において、ビジネスアプリケーションマネージャ102は、要求されたロール変更が発生することを防止する。すなわち、ビジネスアプリケーションマネージャ102は、ロール104bの更新を阻止するようリアルタイムエージェント104aに命令する。一例では、リアルタイムエージェント104aは、実行モジュール212を起動することによって、これを実施する。より具体的には、これは、104のネイティブシステムへの出口および標準エントリポイントを利用することによって、またはネイティブシステム全体を制御して、ロール変更プロセスを完全に停止、アボート、または打ち切ることによって、実施されることができ、SAPサブシステム104のコンテキストでは、リアルタイムエージェント104aは、SUO1、SUb、およびPFCGなどのトランザクションの実行を防止する。

別の例では、動作508は、危険な組合せまたは要注意アクセスアトリビュートのビジネスルールに対する例外を管理者が入力することを防止するビジネスアプリケーションマネージャ102を含むことができる。別の例では、動作508は、別のサブシステム内の同じユーザへの別のロールの既存の割り当てを考慮すると、ロールが職務分離違反を引き起こす場合、1つのサブシステム104〜108内の与えられたユーザへのロールの提案された割り当てを停止することができる。

適宜、動作508において、ビジネスアプリケーションマネージャ102は、上で説明されたような適切な宛先に、提案されたが失敗したロール変更についての通知を送信する追加の動作を行うことができる。さらなる選択肢として、防止されたロール変更(動作508)に続いて、ビジネスアプリケーションマネージャ102は、ユーザを改善動作510に導くこともできる。改善は、上でより詳細に説明されている(例えば、図4の406を参照)。

上で説明された動作502の代替として、この動作508は、ユーザが最終的にロール変更要求をサブミットする前に行われることもできる。例えば、リアルタイムエージェント104aは、トランザクションがロールに追加されるときは常に検知し、権限付与オブジェクトが定義される前でさえも、ビジネスアプリケーションマネージャ102に通知(動作508)するように動作することができる。

この場合、ビジネスアプリケーションマネージャ102は、ユーザによって構成されるときに不完全なロールを分析し(504)、引き続き権限付与オブジェクト定義を行うかどうかの選択肢を与えて、潜在的な違反をユーザに警告(図示されず)する。これは、ロール変更が最終的に失敗して多くの時間を費やす前に、それまでの変更を廃棄する選択肢をユーザに提供する。

リスク終結機能の代替または追加実施として、ビジネスアプリケーションマネージャ102は、ロールおよびアサインメント変更以外の活動も検知し、終結させることができる。例えば、ビジネスアプリケーションマネージャ102は、ユーザがそのロールおよびアサインメントによって実行を許可されたタスクを修正するよう要求する状況、ユーザがガイドラインに違反する1つまたは複数のタスクを実行するよう要求する状況、またはユーザがユーザの既存ロールの範囲外のタスクを実行するよう要求する状況を扱うことができる。この場合、リアルタイムエージェント104a〜108aは、ビジネスアプリケーションサブシステム内でタスクを実行するために、ユーザ要求についての実質的にリアルタイムの通知を提供する。また、通知に応答して、ビジネスアプリケーションマネージャ102は、リスクフレームワークを利用して、要求されたタスクがガイドラインに違反する潜在性を有するかどうか、および/または要求されたタスクが要求ユーザのロール104b〜108bの範囲外にあるかどうかを決定する。これらのどちらかが真である場合、ビジネスアプリケーションマネージャ102は、ビジネスアプリケーションサブシステムがそのタスクを実施することを防止するために実質的にリアルタイムに動作するよう、適切な1つまたは複数のリアルタイムエージェント104a〜108aに指図する。または、ビジネスアプリケーションマネージャ102は、影響されるビジネスアプリケーションサブシステムが、タスクを実施し、タスクの実質的にリアルタイムの通知をスーパーバイザまたはその他の指定された人に送信することを可能にする。

上で述べられたように、システム100の一態様は、様々なユーザタスク(104c〜108c)を実行することが可能であるが、定義されたロールおよびアサインメント(104b〜108b)に従ってこれらの動作のユーザ実行を規制する、(104〜108などの)ローカルビジネスアプリケーションサブシステムを含む。また上で述べられたように、システム100の別の態様は、ロールおよびアサインメントへの変更を監視し、慎重に規制し、サポートし、増強する中央構成要素(102)を含む。この態様を実施する際、リスクフレームワーク114が、ロール/アサインメント変更が許可されるかどうかを決定するために使用される。

このコンテキストを念頭におき、システム100のさらなる態様は、リスクフレームワーク114を構成するプロセスを含む。このプロセスは、最初にリスクフレームワーク114を生成するための他、リスクフレームワーク114を改訂し、拡張し、または更新するためにも使用されることができる。シーケンス600(図6)は、このプロセスの一例を示している。説明の目的で、シーケンス600は、システム700のコンテキストで説明される。シーケンス600は、それにも関わらず、多くの異なる実施設定に制限なく適用可能である。

シーケンス600を説明する際の助けとして、図7は、会社ガイドライン160、ビジネス活動、およびビジネスアプリケーションサブシステム固有のタスクの間の関係を示している。最初に、図7は、図1からの会社ガイドライン160の記述を含む。702によって、ビジネス活動のライブラリ、コレクション、類別、メニュー、またはその他の選択が示されている。大まかに言えば、ビジネス活動は、ビジネスアプリケーションサブシステム104〜108の特定のタスク104c〜108cによって実施されることが可能な高水準のビジネス業務に相当する。

ビジネス活動の危険な組合せを表すビジネス活動702のサブセットが、706によって示されている。特に、活動706は、同じ人に委ねられた場合にリスクを提示する2つ以上のビジネス活動の様々な組合せを規定する。「リスク」は、より具体的には、規定された会社ガイドライン160に違反する潜在性の存在に相当する。異なる会社規則の違反は、低、中、高などの異なるレベルのリスクを割り当てられることができる。これらの格付けは、利用された場合に主体におよぼすリスクの深刻度などの客観的要因、または個々人の意見とは無関係のその他の基準に基づくことができる。これらの格付けは、デフォルトによって、事業所有者によって、または両方の組合せによって設定されることができる。いくつかのリスクレベル例は、1.高-不正行為、システム障害、資産喪失など、物理的もしくは金銭的喪失またはシステムワイドな破壊が生じ得るレベル、2.中-マスタデータの上書き、ビジネス承認のバイパス、複数のビジネスプロセス領域の破壊を含むいくつかの例を有する、データインテグリティもしくは操作または複数のシステム破壊が生じ得るレベル、3.低-内部プロジェクト費用の虚偽表示または1つのプラントもしくはロケーションのシステム停止を含むいくつかの例を有する、単一の単位または業務に影響する生産性喪失またはシステム障害が生じ得るレベル、を含む。

タスク707〜709は、ビジネス活動702を実施する際に可能性として起動され得る、ビジネスアプリケーションサブシステム固有のタスクの全範囲を表す。今の例では、タスク707〜709は、サブシステム104〜108によって実施され得るマシン実行可能タスク104c〜108cに(それぞれ)対応する。大まかに言えば、タスク707〜709は、(例えば、SAPサブシステム内の)トランザクション、(ORACLEサブシステム内の)ファンクション、(PEOPLESOFT（登録商標）サブシステム内の)コンポーネント、または使用においてサブシステムに適したその他のタスクを含む。しかし、「タスク」707〜709は、程度の異なる粒度で定義されることができる。例えば、SAPを使用するビジネスアプリケーションサブシステムの場合、「タスク」は、(1)アクション、(2)アクションと、更新、生成、表示などの許可、または(3)アクションと、許可と、文書、フィールドなど、さらなる詳細の1つもしくは複数のさらなるアイテム、とすることができる。

「ビジネス活動」702の高水準の概念は、サブシステムが詳細なタスク707〜709を実行することができ、したがって、タスク707〜709のサブセットがビジネス活動の危険なサブセット706に対応する範囲内で、サブシステム104〜108において具体的な意味のみを有する。危険なタスクの組合せは、716によって示されている。これらの危険なタスクの組合せ716は、(716〜718によって示される)様々なサブシステム内のタスク組合せの他、(712〜714によって示される)様々なサブシステム間のタスク組合せからも発生することができる。一例では、危険なタスクの組合せ716は、114c(図1)を実現したローカルマニフェステーションの組の一例を提供する。

(図7と共に)図6を参照すると、ルーチン600は、リスクフレームワーク114を構成するシーケンス例を示している。動作602において、ビジネス活動702が定義される。一例では、これは、どのビジネス活動をビジネスアプリケーションサブシステム104〜108が実施することが可能かを決定することを含む。一例では、動作602は、動作ビジネスアプリケーションサブシステムを反映して実施されることができる。別の例では、動作602は、ビジネスアプリケーションサブシステムを最初から設計する初期ステージにおいて実行されることができる。どちらの場合も、動作602は、手動で実行されることができ、より具体的には、プログラマ、システム管理者、設計者、ソフトウェアアーキテクト、またはその他の適切な人によって実行されることができる。一例では、ユーザは、インタフェース126(例えば、GUI機能)を操作して、ビジネス活動702をビジネスアプリケーションマネージャ102に入力する。

動作604は、各ビジネス活動が各ビジネスアプリケーションサブシステムにおいて実施され得る可能な方法を含む、ビジネス活動702の技術的解釈を提供する。より具体的には、各ビジネスアプリケーションサブシステムについて、動作604は、ビジネス活動を実施することが可能なすべてのビジネスアプリケーションサブシステム固有のマシン実施タスク707〜709を列挙する。与えられたビジネス活動を実施する多くの異なる方法が存在することができ、その各々が検討される。動作604は、手動で実施されることができ、より具体的には、プログラマ、システム管理者、設計者、ソフトウェアアーキテクト、またはその他の適切な人によって実施されることができる。一例では、ユーザは、インタフェース126(例えば、GUI機能)を操作して、タスク707〜709を入力し、各ビジネス活動702を対応するタスク707〜709に相関させる。

上で述べられたように(図7の707〜709)、「タスク」は、程度の異なる粒度で定義されることができる。例えば、SAPを使用するビジネスアプリケーションサブシステムの場合、「タスク」は、(1)アクション、(2)アクションと、更新、生成、表示などの許可、または(3)アクションと、許可と、文書、フィールドなど、さらなる詳細の1つもしくは複数のさらなるアイテム、とすることができる。動作604は、その場合、システム700がセットアップされたタスク粒度に応じて、異なって動作する。したがって、動作604の技術的解釈を実行する際、各ビジネス活動は、十分な流動に到達するのに必要なように分解される。例えば、「タスク」が単にSAPアクションに対応する場合、動作604は、各ビジネス活動をタスクに分解し、さらに関連する許可、文書、およびフィールドを指定する。「タスク」がSAPアクションと、許可と、文書およびフィールドを表す場合、動作604は、各ビジネス活動をタスクに分解する。

動作606は、危険なビジネス活動702の組合せ706を識別する。すなわち、動作606は、すべてが同じ人に委ねられた場合、その人が会社ガイドライン160に違反するやり方でシステム700を使用する能力を有する、ビジネス活動の組合せを識別する。1人の人がこれらのビジネス活動を実施することが可能である場合、例えば、その人は、表3に従って違反を達成することが可能であり、したがって、規定された職務分離規則に違反することが可能である。動作606は、手動で実施されることができ、より具体的には、プログラマ、システム管理者、設計者、ソフトウェアアーキテクト、またはその他の適切な人によって実施されることができる。例えば、ユーザは、インタフェース126のGUI機能を操作して、ビジネスアプリケーションマネージャ102と通信することによって動作606を完了し、動作602において提示された様々なビジネス活動の組合せを識別することができる。

動作606の後、動作608が実行される。(606からの)ビジネス活動の各識別された危険な組合せ(706)について、動作608は、(604からの)これらの組合せの技術的解釈を利用して、危険な組合せを実施することが可能なビジネスアプリケーションサブシステム固有のタスクのすべての可能な組合せを生成する、コンピュータドリブン動作を実行する。言い換えると、動作608は、動作604および606の結果を使用して、危険なビジネス活動706を、これらがビジネスアプリケーションサブシステム104〜108において発生し得る様々な方法のすべてにマッピングする。結果は、ビジネスアプリケーションサブシステムタスクの危険な組合せの一覧716である。動作608は、各危険なビジネス活動706が、与えられたビジネスアプリケーションサブシステム(例えば、716〜718)内で発生し得る可能性を検討する他、危険なビジネス活動706が、複数のビジネスアプリケーションサブシステム(例えば、712〜714)間で発生し得る可能性も検討する。具体的な一例では、動作608の1つの機能は、適切な機能レベルコードまたは権限付与オブジェクトに提案された値を割り当てることとすることができる。

動作602〜606とは異なり、動作608は、コンピュータで実行される。今の例では、動作608は、ビジネスアプリケーションマネージャ102によって実行される。結果のタスク一覧716は、膨大になることがある。例えば、約200個のリスク706がある場合、いくつかのシステムには2万近い結果のトランザクションの組合せ716が存在することがあり得る。

動作608の後、動作610は、ビジネスアプリケーションサブシステムにおけるユーザ活動を規制するマシン実施のルールを実施し、これらのルールは、生成されたタスクの組合せのいずれかを実行することが可能な与えられたロールまたはユーザの発生を禁止する。一例では、動作610は、リスクフレームワーク114を更新して、動作606の結果を反映させることによって、より具体的には、タスクの組合せ716をローカルマニフェステーション114cに保存することによって、実施される。単一のビジネスアプリケーションサブシステム例(図示されず)では、動作610は、ローカルビジネスアプリケーションサブシステムをプログラムすることによって、より具体的には、そのサブシステムにとってローカルなリスクフレームワーク114を更新することによって、実施されることができる。これは、サブシステムが、ビジネスアプリケーションサブシステムにおいてユーザ活動を規制することを可能にし、生成されたタスクの組合せのいずれかを実行することが可能な与えられたロールまたはユーザの発生を禁止する。

生成されたタスクの組合せのいずれかを実行することが可能な任意の与えられたロールまたはユーザの発生を禁止するルールに関して、これは、そのような発生を防止すること、そのような発生の通知を引き起こすこと、または両方を含む。この機能のさらなる詳細は、リスク終結機能のコンテキストにおいて上で説明されている。

上の例は、ERPサブシステム、政府規制を遵守するためのシステム、レガシデータリポジトリなどの、ビジネスアプリケーションサブシステム104〜108の様々な実施形態を説明した。

さらなる例として、ビジネスアプリケーションサブシステムの別の実施形態は、データ、プロセス、コンピューティングハードウェア、電子機器、装置、またはセキュリティ構築またはいわゆる「物理的プロビジョニング」に関するアクションを含む。この実施形態では、1つまたは複数のビジネスアプリケーションサブシステム104〜108は、様々なリモート動作の施設セキュリティコンポーネントを含む。ドアロック、アラームシステム、アクセスゾーン、コントローラ、ブームゲート、エレベータ、リーダ(カード、生体計測、RFIDなど)、ポジティブIDリーダ(PIR5)、ならびにこれらのコンポーネントによって生成されるイベントおよびアラームを含む。これは、コピー機、P08システム、HVACシステムおよびコンポーネント、輸送アクセス(チャージ)ポイント、およびスマートカードまたはその他の物理アクセス技術に組み込まれ得るその他のそのようなシステムなど、その他の装置も含むことができる。

物理的プロビジョニングのコンテキストでは、タスク(例えば、104c)は、ドアロックを開ける行為、アラームシステムを止める行為、物理的エリアへの接近を得る行為、および機器を動作させる行為などを含む。タスク104c〜108cの処理中、ビジネスアプリケーションサブシステムは、124、126、128などのインタフェースから個別ユーザ認証を受け取り、それを評価する。ユーザ認証は、キーパッドパスコード、生体計測識別(例えば、指紋、虹彩/網膜スキャン)、ユーザ名およびパスワード提示、磁気ストライプカード、近接型カード、スマートカードの提示、無線周波識別(RFID)の使用などを利用する。ビジネスアプリケーションサブシステムは、要求されたタスクをユーザのために実行すべきかどうかを決定するために、ユーザのロール、アサインメント、その他の特徴(例えば、104b)などの情報を検討する。セキュリティ態様を構築する限りにおいて、ビジネスアプリケーションサブシステムは、CARDAX、GE、またはHoneywellなどの市販製品などの技術を利用することができる。

物理的プロビジョニングのコンテキストでは、ロールの管理(例えば、図4の404を参照)は、物理的エリアおよび機械類などへの接近の許可および拒否に関する。上で説明されたロール(例えば、104b)と同様に、物理的プロビジョニングのロールも、職務分離違反を防止するために設計される。例えば、リスクは、同じ人が(例えば、アンモニウム、硝酸塩などの)化学薬品保管エリアと、接続施設の飛行場のタールマックエリアの両方に接近できる状況によって提示される可能性がある。物理的態様の追加によって、ビジネスアプリケーションマネージャ102は、物理的および論理的状況にわたる職務分離違反を同時に防止するために、ロールを規制することもできる。例えば、リスクは、ある人が1つのロールに従って物理的在庫保存エリアに接近する一方、同時にERPサブシステムにおいて在庫の帳簿からの抹消を実行することが可能なロールにも属している状況によって提示される可能性がある。物理的態様はまた、ビジネスアプリケーションサブシステムが、例えば、ある人があるサイトに連続的期間にわたって物理的に長く居すぎないかどうか、ある人が物理的訪問の間に作業サイトから長時間離れていなかったか、またはある人が有毒もしくは放射性物質に対する一定の規制された曝露限界を超えていないかなどについてのルールを参照することが可能なように、データをビジネスアプリケーションサブシステムに送る。

上で述べられたように、単一の主体(例えば、単一の会社)は、複数のビジネスアプリケーション(企業資源計画ソフトウェア、政府規制遵守ソフトウェア、または物理的プロビジョニングソフトウェア)を使用することができ、これらのビジネスアプリケーションの各々は、様々なベンダの1つから提供されている。そのような複数のビジネスアプリケーションの使用は、上で説明されたアプリケーション内リスクに加えて、アプリケーション間リスクにも会社をさらす。

これらのリスクに対処するため、様々なビジネスアプリケーションシステム104、106、108に結合される共用ビジネスアプリケーションマネージャ102が、図1を参照して説明された。マネージャ102は、個別ビジネスアプリケーション内で発生するリスク(例えば、アプリケーション内リスク)の他、複数のビジネスアプリケーション間のリスク(例えば、アプリケーション間リスク)の分析および検出も含む動作を実行することができる。

ビジネスアプリケーションマネージャ102は、例えば、すべてのビジネスアプリケーションサブシステム104〜108にわたるロール管理を中央で監督し、個別ビジネスアプリケーションサブシステム内ではリスクが存在しない場合でも、複数のビジネスアプリケーションサブシステム104〜108間で発生するリスク(例えば、ガイドライン160に違反する潜在性)を検出するためにアプリケーション間分析を実行することもできる。

ビジネスアプリケーションマネージャはさらに、ルールフレームワーク内で定義される「危険な組合せ」と比較するための技術的情報を収集することによって、ビジネスアプリケーションサブシステム104〜108全体における問題を検出する。

図8および図9は、ビジネスアプリケーションシステム内のビジネスアプリケーションマネージャ102によって、リスクを検出するアプリケーション分析が実行され得る、それぞれの実施形態例による、2つのアプローチを説明するブロック図である。

システム例800では、アダプタ808が、複数のビジネスアプリケーション802〜806全体から、それぞれのリアルタイムエージェント(RTA)を介して、ビジネスアプリケーションデータを収集する。アダプタ808は、その後、複数のビジネスアプリケーション802〜806からの収集データを共通データフォーマットに変換する。アダプタ808は、その後、データをビジネスアプリケーションマネージャ102内の事前定義されたルールロジック810に共通フォーマットで伝達して、ビジネスアプリケーションマネージャ102が、受信されたビジネスアプリケーションデータに基づいて、事前定義されたルールロジック810によって指定される様々なリスク評価を行うことを可能にする。

システム例900も同様に、複数のビジネスアプリケーション902〜906から、それぞれのリアルタイムエージェント(RTA)を介して、ビジネスアプリケーションデータを収集するように動作するアダプタ908を含む。しかし、アダプタ908は、アダプタ808によって実行されるように収集されたビジネスアプリケーションデータを共通フォーマットに変換するのではなく、ビジネスアプリケーションデータをある主体によって定義される柔軟なデータフォーマット(例えば、複数のビジネスアプリケーション902〜906を実行する会社によって定義されるデータフォーマット)で処理する。ビジネスアプリケーションマネージャ102は、アダプタ908から受け取られたビジネスアプリケーションデータに基づいて様々なリスク分析を実行するために、以下でさらに詳細に説明されるように、やはりある主体によって定義可能な柔軟なルールロジック910も含む。システム例900に関するさらなる詳細は、後続の図を参照して説明される。

図10は、図1に示されたシステム100の特定の実施形態例とすることができる、システム1000のさらなるアーキテクチャ詳細を示すブロック図である。システム1000は、ストレージ1004に通信可能に結合され、ストレージ1004にアクセスする、ビジネスアプリケーションマネージャ1002を含む。ビジネスアプリケーションマネージャ1002は、アダプタフレームワーク1006にも通信可能に結合され、アダプタフレームワークは、複数の外部システム1008とインタフェースをとる。図10は、アダプタフレームワーク1006をビジネスアプリケーションマネージャ1002の外部にあるものとして示しているが、その他の実施形態では、アダプタフレームワークは、ビジネスアプリケーションマネージャ1002の構成要素を構成することができる。

外部システム1008から始めると、これらの外部システムの各々は、リアルタイムエージェント1014、1016に関連付けられたそれぞれのビジネスアプリケーション1010、1012をホストすることができる。複数の外部システム1008が、単一の主体(例えば、会社、パートナシップ、ジョイントベンチャ、企業支部、行政単位など)のために動作させられてもよい。ビジネスアプリケーション1010および1012の各々は、異なるタイプとすることができ、かつ/または異なるベンダによって供給されることもできる。例えば、ビジネスアプリケーション1010は、SAP AGによって供給される企業資源計画(ERP)システムとすることができ、ビジネスアプリケーション1012は、Oracle CorporationのeBusiness Suite（登録商標）とすることができる。ビジネスアプリケーション1010および1012はさらに、各々が異なるERPシステムのサブシステムであることもできる。例えば、1つのビジネスアプリケーションは、SAP AGからのSAP R/3（登録商標） ERPサブシステムとすることができ、ビジネスアプリケーション1012は、Oracle CorporationからのOracle Financials（登録商標）サブシステムとすることができる。さらに、ビジネスアプリケーション1010および1012の各々は、関連主体の事業および業務プロセスを支援するために、運用主体によってカスタマイズされることができる。そのようなものとして、リアルタイムエージェント1014、1016の各々は、関連ビジネスアプリケーション1010、1012からビジネスデータを抽出し、この情報をアダプタフレームワーク1006に伝達するようにカスタマイズされる。

アダプタフレームワーク1006は、1つまたは複数のアダプタスクリプト1018を含むものとして示されており、アダプタスクリプトの各々は、1つまたは複数のリアルタイムエージェント1014、1016から受け取られたビジネスアプリケーションデータから結果セットを生成するために、多くのデータエクストラクタ1020、1022を実行することができる。エクストラクタ1020および1022の各々は、単一のリアルタイムエージェント1014および1016と通信するものとして示されているが、エクストラクタは、多くのリアルタイムエージェントからビジネスデータを受け取ることができ、複数のリアルタイムエージェントから受け取られたこのデータを利用して、それぞれの結果セットを生成することができる。エクストラクタ1020および1022の各々は、それぞれのビジネスアプリケーション1010、1012のアトリビュートをルール変数1036の汎用および/または技術的アトリビュートにマッピングするそれぞれのマッピング1021、1023を含み、汎用および技術的アトリビュートは、それぞれのビジネスアプリケーションのシステムタイプに基づく。

各アダプタスクリプト1018は、それぞれのエクストラクタによって生成された個別結果セットを、ビジネスアプリケーションマネージャ1002のデータ統合コンポーネント1024に伝達し、データ統合コンポーネント1024は、アダプタスクリプト1018から受け取られた多くの個別結果セットを組み合わせて、組合せ結果セットにするために適用される、複数のjoin条件1026を含む。

データ統合コンポーネント1024は、実行エンジン1028に結合され、実行エンジンは、複数の入力条件1030を含む。入力条件は柔軟であり、ビジネスアプリケーションマネージャ1002のオペレータによってカスタマイズされることができる。入力条件は、特定のコントロール1038のための特定のルール1034の実行に先立って、実行エンジン1028によって選択されることができる。

ビジネスアプリケーションマネージャ1002は、ストレージ1004に通信可能に結合され、ストレージ1004内に保存されたルール1034を実行するように動作する、ルールエンジン1032も含む。ルールの各々は、以下でより詳細に説明されるように、1つまたは複数のルール変数1036に関して動作する。各ルールは、1つまたは複数のコントロール1038にも関連付けられることができる。

上で説明されたように、データ統合コンポーネント1024によって生成された組合せ結果セットへの特定のルール1034の適用の結果として、欠陥または違反がルールエンジン1032によって検出された場合、特定のルールの違反は、違反データ1040内に書き留められ、含まれることができる。さらに、検出された欠陥または違反の監査を可能にするために、監査ログ1042が維持されることができる。コンフィギュレーションデータ1044も、ストレージ1004内に含まれることができる。コンフィギュレーションデータ1044は、特定のルール1034を構成するように機能することができ、例えば、(最大3つのレベルで定義され得る)欠陥タイプおよび(絶対値およびパーセンテージのどちらかまたは両方などの)範囲など、様々なオペレータタイプおよび条件によって規定されることができる。

ストレージ1004は、複数のビジネスアプリケーション1010、1012全体における手続き欠陥または違反の検出に応答して実行され得る改善アクションを指定する、改善データ1046も含む。これらの改善アクションは、例えば、指示された受け手に通知を提供すること、手続き欠陥または違反の発生を(例えば、違反データ1040および監査ログ1042に反映されるように)記録すること、特定の改善を実施するための自動または人的ワークフロー引き起こすこと、または指定された欠陥または違反の発生を防止するための自動手続きを起動することを含むことができる。この目的で、ストレージ1004は、ワークフロー制御データ1048も含むことができ、ワークフロー制御データは、起動され得る改善ワークフローを制御する。

ビジネスアプリケーションマネージャ1002に戻ると、ケースマネージャ1050は、ルール違反の結果として検出された各欠陥または違反「ケース」を管理するように動作し、改善モジュール1052は、改善データ1046によって指定される改善アクションを実施するように動作し、ワークフローエンジン1054は、ワークフロー制御1048によって定義されるワークフローを実施する。さらに、コントロールマネージャ1056は、コントロールデータ1038によって指定されるコントロールを実行するように動作する。

図11は、一実施形態例による、ルールエンジン1032のためのエンティティ関係図である。高いレベルから始めると、複数のコントロール1102が、各ロケーション1104に割り当てられることができる。複数のロケーション1104はさらに、組織単位グループ1106に関連付けられることができる。各組織単位グループ1106は、1組の汎用アトリビュートと、関連組織単位グループに関連付けられる(例えば、それぞれのビジネスアプリケーションをホストする)1つまたは複数の物理システム1108に基づいた多くの技術的アトリビュートとを含むことができる。汎用アトリビュートは、例えば、名前および説明を含むことができる。技術的アトリビュートは、1つまたは複数の物理外部システム1008(例えば、Oracleシステムの「動作単位」に対応する、SAPシステムの会社コードおよびプラント)に基づくことができる。

組織単位グループ1106はさらに、2つ以上の組織単位と関連する組織単位値を含むことができる。特定のロケーション1104について、組織単位グループ1106は、組織単位値に依存して、物理システム1108の異なる組を有することができる。

各ロケーション1104は、実行エンジン1028によるテスト実行をスケジュールするビジネスマネージャのスケジューラ(図示されず)によって使用され得るカレンダ(図示されず)にも関連付けられることができる。コントロールテストは、特定のタイムフレーム内で割り当てられたルールである。

各コントロール1102は、手動(例えば、それらをユーザにより手動でテストし、結果がアップロードされる)、半自動(例えば、コントロールは自動的に実行されるが、ユーザによって評価される)、または自動(例えば、コントロールは自動的に実行され、自動的に評価される)とすることができる、関連するテスト手続きを有する。さらに、各コントロール1102は、複数のロケーション1104に割り当てられることができる。したがって、特定のロケーション1104のためのコントロールアトリビュートに変更がある場合、関連コントロール1102は、そのロケーションのためにコピーされ、修正されることができる。

図11は、コントロール1102(またはコントロールテスト)が、特定のタイムフレームに関してルール1110に割り当てられることができることも示している。特定のステータスは、ルール1110へのコントロール1102の割り当てに帰せられることができる。能動的ルール割り当てのみが、その指定されたタイムフレームに関するコントロールテスト実行のために使用される。

各ルール1110は、複数のルールステップ1112を含む。各ルールステップ1112は、スクリプト1114および物理システム1108に結び付けられることができる。特定のルールステップ1112が物理システム1108に結び付けられる場合、結び付けられたスクリプト1114は、その物理システム1108で実行することができる。スクリプト1114は、アダプタスクリプト1018として実施されることができ、またはリアルタイムエージェントのリアルタイムエージェントスクリプト実施形態を構成することができる。

ルール1110は、タイムフレームベースとすることもでき、ルールの修正は、特定のタイムフレームに基づいた新しいルールバージョンの生成をもたらすことができる。各ルールステップ1112は、1つまたは複数のルールセット1116を有する。複数のルールセット1116は、異なる結果セットについて異なる値の組を使用するために定義されることができる。例えば、分析タイプおよび分析インジケータなどの様々なアトリビュートが、各ルールセットについて維持される。分析タイプおよび分析インジケータの例は、システムコンフィギュレーションの変更、権限付与レコードの生成、特定のビジネスパラメータおよび対応する値の存在、特定の重要なビジネスオブジェクトに施される変更の数多くの発生、およびトランザクションデータ分析を含む。

各ルールセットは、1組の選択ルール変数1118および1組の条件ルール変数1120に関連付けられる。選択ルール変数1118は、リアルタイムエージェントからビジネスアプリケーションマネージャ1002にエクストラクタによって返される特定の結果セットの選択のために使用されることができる。条件ルール変数1120は、欠陥タイプをチェックし、決定するために使用されることができ、欠陥タイプは、システム1000のオペレータによって自由に定義可能である。条件ルール変数は、条件演算子(例えば、所定の量より大きいか)、絶対値変数、パーセンテージ値変数、および英数字変数を含むことができる。条件演算子の一例は、例えば、関連する値が所定のパーセンテージだけ変化した場合に満たされるように特定の条件を制限する変数である。

選択ルール変数1118は、組織単位変数も有することができる。これらの組織単位変数は、ワイルドカード値(例えば、「アスタリスク」)を有するように指定されることができ、ロケーションレベルの組織単位グループで維持されることができる。したがって、制御された実行中、組織単位値は、ロケーション組織単位グループからの値によって置換されることができる。組織単位値が選択ルール変数値で明示的に定義される場合、そのような値は上書きされない。

選択ルール変数および条件ルール変数の各々を構成することができるルール変数1036について説明すると、ルール変数1036は、汎用アトリビュートおよび技術的アトリビュートを有することができる。ルール変数1036の技術的アトリビュートは、値/説明のリストを得るための、データタイプおよびシステムタイプ依存のテーブル/フィールドを定義することができる。データタイプの例は、文字、数値、小数、データなどを含むことができる。

さらに、上で述べられたように、ルール1110のいくつかは、カスタムビルトなシステム間ルールとすることができ、ローカルJ2EE（登録商標）システムで実行されることができることに留意されたい。システム間ルール1110の場合、1つまたは複数のデータエクストラクタ1020および1022を利用して結果セットが生成され、生成された結果セットにシステム間ルールが適用される。

図12は、例えば、ビジネスアプリケーションマネージャとビジネスアプリケーションマネージャによって管理される複数のビジネスアプリケーションとを含むビジネスアプリケーション環境を構成するための、一実施形態例による、方法1200を説明するフローチャートである。

方法1200は、動作1201で開始し、例えば、ビジネスアプリケーション環境のオペレータによって複数のルール変数1036の定義を行う、動作1202に進む。上で述べられたように、ルール変数1036の定義は、複数のビジネスアプリケーション1010、1012のシステムタイプに基づいて、汎用アトリビュートと技術的アトリビュートの両方の定義を含むことができる。

動作1204において、運用主体は、特定のルールセット1116に対して、選択ルール変数1118および条件ルール変数1120をその特定のルールセットに関連付けることができる。

動作1206において、次に主体は、少なくとも1つのルールセットを複数のルールステップ1112の各々に関連付けることができ、動作1208において、今度はルールステップが、特定のルール1110に関連付けられる。

動作1209において、特定のルールは、少なくとも1つの、潜在的に複数のタイムフレームに関連付けられることができる。このルールとタイムフレームとの関連付けは、異なるタイムフレームにおいて異なるルールを適用する際に柔軟性を提供する。例えば、月次ルールは、$5000の取引額をチェックすることができるが、四半期ルールは、$50000の額をチェックすることができる。異なるタイムフレームを特定のルールに関連付けるこの機能は、ルールが定期的テストおよび連続的監視の両方に適用されることを可能にする。

動作1212において、次に主体は、複数の異なるビジネスアプリケーション全体における異なる技術的アトリビュートに従って、複数の異なるビジネスアプリケーション1010、1012全体からデータを抽出するために、複数のデータエクストラクタ1020、1022をカスタマイズすることができる。次に方法1200は、動作1214で終了する。

図13は、複数のビジネスアプリケーション全体における手続き欠陥または違反を検出するための、一実施形態例による、方法1300を説明するフローチャートである。

方法は、動作1302で開始し、適切なエクストラクタ1020、1022を起動するために、ルールステップ1112に関連付けられたスクリプトの実行をそれぞれの物理システム1108上で行う、動作1304に進む。動作1304におけるエクストラクタの起動は、ストレージ1004からのエクストラクタの取り出しを含むことができる。

動作1306において、それぞれの個別結果セットを生成するために、データエクストラクタの各々1020または1022が実行される。この目的で、データエクストラクタの各々は、外部システム1008のビジネスアプリケーション1010、1012に関連する1つまたは複数のリアルタイムエージェント1014、1016とインタフェースをとることができる。

動作1308において、複数のデータエクストラクタによって生成された個別結果セットが組み合わされて、組合せ結果セットになる。この個別結果セットの組合せは、マッピング1021、1023を利用する、ルール変数1036への特徴変数のマッピングを含むことができる。さらに、複数の個別結果セットの組合せは、データ統合コンポーネント1024内での、1つまたは複数のjoin条件の適用を含むことができる。ルール変数への特徴変数のマッピングの例は、ルール変数COMPANY_CODEにマッピングされる、会社コードBUKRSに関してSAPシステムから抽出されたデータのマッピングを含むことができる。join条件の一例は、Oracleシステムのアイテム番号(ITEM)へのSAPシステムのマテリアル番号(MTNR)の結合とすることができる。

動作1310において、ルールエンジン1032が始動して、複数のビジネスアプリケーション1010、1012全体における手続き欠陥、違反、または遵守を検出するために、組合せ結果セットに1つまたは複数のルール1034を適用する。検出される手続き欠陥は、会社方針、政府規制、法律、職業規則、会計規則、公正な商慣行の声明、契約によって課される条件、または企業定款の違反を、単なる例として含むことができる。これらの違反は、関連ルール1034によって指定されることができる。

動作1312において、ビジネスアプリケーションマネージャ1002は、複数のビジネスアプリケーション全体における検出された手続き欠陥、違反、または遵守を報告することができる。この目的で、ケースマネージャ1050は、検出されたイベントに応答して、新しいケースをインスタンス化することができる。さらに、ビジネスアプリケーションマネージャ1002は、手続き欠陥または違反の検出に応答して、1つまたは複数の改善アクションの実行を開始することができる。具体的には、改善モジュール1052は、指示された受け手に手続き欠陥または違反の通知を提供すること、手続き欠陥または違反の発生を(例えば、監査ログ1042に)記録すること、改善を実施するための人的または自動ワークフローまたは特定のイベントの発生を防止するための(例えば、ワークフロー)を引き起こすことを含む、多くの改善アクションのうちのいずれか1つの実行を開始することができる。欠陥の報告は、電子通信(例えば、eメール、SMS、インスタントメッセージ、またはページアラーと)を指定された受け手に送信すること、または様々なビジネスアプリケーション全体における欠陥を監視するために使用されるダッシュボードもしくはユーザインタフェースをその他の方法で更新することを、単なる例として含むことができる。

図14は、本明細書で説明された方法のいずれか1つまたは複数をマシンに実行させる1組の命令がその内部で実行され得るコンピュータシステム1400の形態例をとるマシンのブロック図である。代替実施形態では、マシンは、単独型装置として動作し、またはその他のマシンに接続(例えば、ネットワーク接続)されることができる。ネットワーク接続された配備では、マシンは、サーバ-クライアントネットワーク環境におけるサーバもしくはクライアントマシンの立場で、またはピアツーピア(または分散)ネットワーク環境におけるピアマシンとして動作することができる。マシンは、パーソナルコンピュータ(PC)、タブレットPC、セットトップボックス(STB)、携帯情報端末(PDA)、セルラ電話、ウェブ機器、ネットワークルータ、スイッチもしくはブリッジ、またはそのマシンによってとられるアクションを指定する1組の命令を(順次もしくはその他の方法で)実行することが可能な任意のマシンとすることができる。さらに、単一のマシンが示されているが、「マシン」という用語は、本明細書で説明された方法のいずれか1つまたは複数を実行する1組(または複数の組)の命令を、各個でまたは協同して実行するマシンの任意の集まりも含むと理解されるべきである。

コンピュータシステム例1400は、プロセッサ1402(例えば、中央処理装置(CPU)、グラフィックス処理装置(GPU)、または両方)、メインメモリ1404、およびスタティックメモリ1406を含み、それらは、バス1408を介して互いに通信する。コンピュータシステム1400はさらに、ビデオ表示ユニット1410(例えば、液晶ディスプレイ(LCD)またはブラウン管(CRT))を含むことができる。コンピュータシステム1400は、英数字入力装置1412(例えば、キーボード)、ユーザインタフェース(UI)ナビゲーション装置1414(例えば、マウス)、ディスクドライブユニット1416、信号生成装置1418(例えば、スピーカ)、およびネットワークインタフェース装置1420も含む。

ディスクドライブユニット1416は、本明細書で説明される方法または機能のいずれか1つまたは複数を実施し、またはそれらによって利用される、命令およびデータ構造の1つまたは複数の組(例えば、ソフトウェア1424)が保存されるマシン可読媒体1422を含む。ソフトウェア1424は、全体もしくは少なくとも一部がメインメモリ1404内に存在してもよく、かつ/またはコンピュータシステム1400によるそれの実行中にはプロセッサ1402内に存在してもよく、メインメモリ1404およびプロセッサ1402も、マシン可読媒体を構成する。

ソフトウェア1424はさらに、多くのよく知られた転送プロトコル(例えば、HTTP)のいずれか1つを利用して、ネットワーク1426上をネットワークインタフェース装置1420を介して送信または受信されることもできる。

実施形態例では、マシン可読媒体1422は、単一の媒体として示されているが、「マシン可読媒体」という用語は、命令の1つまたは複数の組を保存する単一の媒体または複数の媒体(例えば、集中もしくは分散データベース、ならびに/または関連キャッシュおよびサーバ)も含むと理解されるべきである。「マシン可読媒体」という用語は、マシンによって実行され、本発明の方法のいずれか1つもしくは複数をマシンに実行させる1組の命令を保存し、符号化し、もしくは搬送することが可能な任意の媒体、またはそのような1組の命令によって利用され、もしくはそれらに関連付けられるデータ構造を保存し、符号化し、もしくは搬送することが可能な任意の媒体も含むと理解されるべきである。「マシン可読媒体」という用語は、したがって、ソリッドステートメモリ、光および磁気媒体、ならびに搬送波信号を、これらに限定することなく含むと理解されるべきである。本発明は、デジタル電子回路で、コンピュータハードウェア、ファームウェア、ソフトウェアで、またはそれらの組合せで実施されることができる。本発明は、コンピュータプログラム製品として、すなわち、例えば、プログラム可能プロセッサ、コンピュータ、もしくは複数のコンピュータなどのデータ処理装置によって実行される、またはそれらの動作を制御する、例えば、マシン可読記憶装置または伝播信号などの情報搬送体において有形に実施されるコンピュータプログラムとして、実施されることができる。コンピュータプログラムは、コンパイルまたはインタープリタ言語を含む、任意の形式のプログラミング言語で書かれることができ、スタンドアロンプログラム、またはモジュール、コンポーネント、サブルーチン、もしくはコンピューティング環境で使用するのに適したその他のユニットを含む、任意の形態で配備されることができる。コンピュータプログラムは、1つのコンピュータもしくは1つのサイトの複数のコンピュータ上で実行されるように、または複数のサイトにわたって分散され、通信ネットワークによって相互接続されるように配備されることができる。

本発明の方法動作は、入力データを用いて動作し、出力を生成することによって本発明の機能を実行するために、コンピュータプログラムを実行する1つまたは複数のプログラム可能プロセッサによって実行されることができる。方法動作は、例えば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)などの、専用論理回路によっても実行されることができ、本発明の装置は、専用論理回路として実施されることができる。

コンピュータプログラムの実行に適したプロセッサは、例として、汎用および専用マイクロプロセッサ、および任意の種類のデジタルコンピュータのいずれか1つまたは複数のプロセッサを含む。一般に、プロセッサは、読み取り専用メモリもしくはランダムアクセスメモリまたは両方から命令およびデータを受け取る。コンピュータの必須要素は、命令を実行するプロセッサと、命令およびデータを保存する1つまたは複数のメモリ装置である。一般に、コンピュータは、例えば、磁気、光磁気ディスク、もしくは光ディスクなど、データを保存する1つもしくは複数の大容量記憶装置も含み、またはそれらからのデータの受け取り、それらへのデータの転送、もしくは両方を行うように動作可能に結合される。コンピュータプログラム命令およびデータを実施するのに適した情報搬送体は、例として、例えば、EPROM、EEPROM、およびフラッシュメモリなどの半導体メモリ装置、内蔵ハードディスクおよび着脱可能ディスクなどの磁気ディスク、光磁気ディスク、ならびにCD-ROMおよびDVD-ROMディスクを含むすべての形態の不揮発性メモリを含む。プロセッサおよびメモリは、専用論理回路によって補われることができ、または専用論理回路に組み込まれることができる。

本発明は、例えば、データサーバとしてのバックエンド構成要素を含むコンピュータシステム、アプリケーションサーバとしてのミドルウェア構成要素を含むコンピュータシステム、ユーザがそれを通して本発明の実施と対話することができるグラフィカルユーザインタフェースもしくはウェブブラウザを有するクライアントコンピュータなどのフロントエンド構成要素を含むコンピュータシステム、またはそのようなバックエンド、ミドルウェア、もしくはフロントエンド構成要素の任意の組合せを含むコンピュータシステムで実施されることができる。システムの構成要素は、例えば、通信ネットワークなど、デジタルデータ通信の任意の形態または媒体によって相互接続されることができる。通信ネットワークの例は、ローカルエリアネットワーク(「LAN」)、ワイドエリアネットワーク(「WAN」)、およびインターネットを含む。

コンピューティングシステムは、クライアントとサーバを含むことができる。クライアントとサーバは一般に、互いに遠く離れており、典型的には、通信ネットワークを介して対話する。クライアントとサーバの関係は、それぞれのコンピュータ上で動作し、互いに対してクライアント-サーバ関係を有するコンピュータプログラムによって発生する。

あるアプリケーションまたはプロセスは、本明細書では、多くのモジュールまたはメカニズムを含むとして説明された。モジュールまたはメカニズムは、他のモジュールに情報を提供し、それらから情報を受け取ることができる異なる機能の単位とすることができる。したがって、説明されたモジュールは、通信可能に結合されると見なされることができる。モジュールは、入力または出力装置との通信を開始することもでき、リソース(例えば、情報の集まり)を用いて動作することができる。

本発明の一実施形態は特定の実施形態例を参照して説明されたが、本発明のより広範な主旨および範囲から逸脱することなく、様々な修正および変更がこれらの実施形態に施され得ることは明白であろう。したがって、明細書および図面は、限定的ではなく例示的な意味に考えられるべきである。本明細書の一部を形成する添付の図面は、限定ではなく例示として、主題が実施され得る特定の実施形態を示している。示された実施形態は、当業者が本明細書で開示された教示を実施することが可能なほど十分に詳しく説明されている。本開示の範囲から逸脱することなく、構造的および論理的置換および変更が施され得るように、その他の実施形態も利用され、本明細書の教示から導出されることができる。この「発明を実施するための最良の形態」は、したがって、限定的な意味に理解されるべきではなく、様々な実施形態の範囲は、特許請求の範囲に与えられる均等物の最大限の範囲と共に、添付の特許請求の範囲によってのみ確定される。

上記の開示は多くの例示的な実施形態を示しているが、添付の特許請求の範囲によって確定される本発明の範囲から逸脱することなく、様々な変更および修正が本明細書において施され得ることは、当業者には明らかであろう。したがって、開示された実施形態は、本発明によって広範に企図された主題を代表し、本発明の範囲は、当業者に明らかとなり得るその他の実施形態を完全に包含し、したがって、本発明の範囲は、添付の特許請求の範囲以外によっては限定されない。

加えて、情報および信号が様々な異なる技術および技法を使用して表され得ることは、当業者であれば理解されよう。例えば、本明細書で言及されたデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップはどれも、電圧、電流、電磁波、磁界もしくは磁気粒子、光場もしくは光学粒子、その他のアイテム、または上記のものの組合せによって表されることができる。

さらに、本明細書で説明された例示的な論理ブロック、モジュール、およびプロセス動作はどれも、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実施されることができることは、当業者であれば理解されよう。

ハードウェアとソフトウェアのこの交換可能性を明らかに示すため、様々な例示的なコンポーネント、ブロック、モジュール、回路、および動作は、一般にそれらの機能によって上では説明された。そのような機能がハードウェアとして実施されるか、それともソフトウェアとして実施されるかは、具体的な用途およびシステム全体に課される設計制約に依存する。当業者は、説明された機能を具体的な各用途のための様々な方法で実施することができるが、そのような実施の決定が本発明の範囲からの逸脱を引き起こすと解釈されるべきではない。

開示された実施形態の先の説明は、当業者が本発明を作成または使用することを可能にするために提供された。これらの実施形態に対する様々な修正は、当業者には容易に明らかとなり、本明細書で定義された包括的な原理は、本発明の主旨および範囲から逸脱することなく、その他の実施形態にも適用されることができる。したがって、本発明は、本明細書に示された実施形態に限定されることは意図されておらず、本明細書で開示された原理および新規な特徴と一致する最も広い範囲を与えられる。技術的開示の本質を読者が速やかに確認することを可能にする要約を求める、37 C.F.R.§1.72(b)に従って、開示の要約が提供されている。要約は、特許請求の範囲または意味を解釈または限定するために使用されないという理解のもとで提示されている。加えて、上記の「発明を実施するための最良の形態」では、開示を簡潔にする目的で、様々な特徴が単一の実施形態内に一緒にグループ化されていることが理解されよう。開示のこの方法は、特許請求される実施形態が各請求項で明示的に列挙されているよりも多くの特徴を必要とするという意図を反映したものであると解釈されるべきではない。むしろ、添付の特許請求の範囲が反映しているように、本発明の主題は、単一の開示された実施形態のすべての特徴より少ないものの中にある。したがって、添付の特許請求の範囲は、これによって、「発明を実施するための最良の形態」に組み込まれ、各請求項は、単独で別個の実施形態となる。

実施形態例による、データ処理システムの概略図である。 一実施形態例による、リアルタイムエージェントのアーキテクチャの概略図である。 一実施形態例による、リアルタイムエージェントを動作させるシーケンスを示す図である。 一実施形態例による、複数の非互換ビジネスアプリケーションサブシステム間で発生する動作を含む様々なシステム機能を実行するシーケンスを示す図である。 実施形態例による、トリガ、分析、および終結動作の結合例を提供するシーケンスを示す図である。 一実施形態例による、リスクフレームワーク114を構成するシーケンスを示す図である。 一実施形態例による、会社ガイドライン、ビジネス活動、およびビジネスアプリケーションサブシステム固有のタスクの間の関係を示す図である。 ビジネスアプリケーションシステム内のビジネスアプリケーションマネージャ102によって、リスクを検出するアプリケーション分析が実行され得る、実施形態例による、アプローチを説明するブロック図である。 ビジネスアプリケーションシステム内のビジネスアプリケーションマネージャ102によって、リスクを検出するアプリケーション分析が実行され得る、実施形態例による、アプローチを説明するブロック図である。 図1に示されたシステムの特定の実施形態例とすることができる、システムのさらなるアーキテクチャ詳細を示すブロック図である。 一実施形態例による、ルールエンジンのためのエンティティ関係図である。 例えば、ビジネスアプリケーションマネージャとビジネスアプリケーションマネージャによって管理される複数のビジネスアプリケーションとを含むビジネスアプリケーション環境を構成するための、一実施形態例による、方法を説明するフローチャートである。 複数のビジネスアプリケーション全体における手続き欠陥または違反を検出するための、一実施形態例による、方法1300を説明するフローチャートである。 本明細書で説明された方法のいずれか1つまたは複数をマシンに実行させる1組の命令がその内部で実行され得るコンピュータシステムの形態例をとるマシンのブロック図である。

符号の説明

100 システム
102 ビジネスアプリケーションマネージャ
104、106、108 ビジネスアプリケーションサブシステム
111 ストレージ

Claims (30)

1. 複数のビジネスアプリケーション全体からデータを抽出する複数のデータエクストラクタを取り出すステップと、
   複数の個別結果セットを生成するために、前記複数のデータエクストラクタを実行するステップと、
   組合せ結果セットにするために、前記複数の個別結果セットを組み合わせるステップと、
   前記複数のビジネスアプリケーション全体における手続き欠陥を検出するために、前記組合せ結果セットにルールを適用するステップと、を含む方法。
2. 前記複数のデータエクストラクタを実行する前記ステップが、前記複数のデータエクストラクタの各々を、前記複数のビジネスアプリケーションの各々に関連付けられたそれぞれのリアルタイムエージェントとインタフェースさせるステップを含む、請求項1に記載の方法。
3. 前記複数のビジネスアプリケーション全体における前記手続き欠陥の検出を選択的に報告するステップを含む、請求項1に記載の方法。
4. 前記複数のビジネスアプリケーション全体における前記手続き欠陥の前記検出に応答して、改善アクションを選択的に実行するステップを含む、請求項1に記載の方法。
5. 前記改善アクションの前記実行が、指示された受け手に通知を提供すること、前記手続き欠陥の発生を記録すること、前記改善アクションを実施するためにヒューマンワークフローを引き起こすこと、および指定されたイベントの発生を防止するために自動手続きを起動すること、から成る1群のアクションのうちの少なくとも1つを含む、請求項4に記載の方法。
6. 前記ビジネスアプリケーションが、企業資源計画ソフトウェア、政府規制遵守ソフトウェア、および物理的プロビジョニングソフトウェア、から成る群に属するものうちの少なくとも1つである、請求項1に記載の方法。
7. 前記手続き欠陥が、会社方針、政府規制、法律、職業規則、会計規則、公正な商慣行の声明、契約によって課される条件、および企業定款、のうちの少なくとも1つの違反から成る1群の欠陥のうちの少なくとも1つである、請求項1に記載の方法。
8. 複数のビジネスアプリケーションのうちの少なくとも1つからデータを抽出するために、前記複数のデータエクストラクタの各々をカスタマイズするステップを含む、請求項1に記載の方法。
9. 前記複数のデータエクストラクタの各々をカスタマイズする前記ステップが、前記複数のビジネスアプリケーション全体における異なる技術的アトリビュートに従って、前記複数のデータエクストラクタの各々をカスタマイズするステップを含む、請求項8に記載の方法。
10. 前記複数のデータエクストラクタを取り出す前記ステップが、前記複数のデータエクストラクタの各々を起動するスクリプトを実行するステップを含む、請求項1に記載の方法。
11. 前記複数の個別結果セットを組み合わせる前記ステップが、前記複数のビジネスアプリケーションのうちの少なくとも1つの特徴変数を、前記ルールのルール変数にマッピングするステップを含む、請求項1に記載の方法。
12. 前記複数の個別結果セットを組み合わせる前記ステップが、前記複数のビジネスアプリケーション各々のそれぞれの特徴変数を、前記ルールの前記ルール変数にマッピングするステップを含む、請求項11に記載の方法。
13. 前記複数の個別結果セットを組み合わせる前記ステップが、前記組合せ結果セットを生成するために、join条件を適用するステップを含む、請求項1に記載の方法。
14. 前記ルールが、複数のルールステップを含み、前記ルールを適用する前記ステップが、前記複数のルールステップのうちの少なくとも1つを適用するステップを含む、請求項1に記載の方法。
15. 前記複数のルールステップの各ルールステップを、前記複数のビジネスアプリケーションのうちの少なくとも1つをホストするそれぞれの物理的システムに関連付けるステップを含む、請求項14に記載の方法。
16. 前記複数のルールステップの各ルールステップを、それぞれのスクリプトに関連付けるステップであって、前記それぞれのスクリプトが、前記それぞれの物理的システムによって実行されるステップを含む、請求項15に記載の方法。
17. 前記複数のルールステップの各ルールステップを、少なくとも1つのルールセットに関連付けるステップと、各ルールセットを、前記ルールセットの結果セットに含まれるデータの選択において使用される少なくとも1つの選択ルール変数と、前記ルールセットの欠陥タイプを検出する際に使用される少なくとも1つの条件ルール変数と、に関連付けるステップと、を含む請求項14に記載の方法。
18. 前記ルールを少なくとも1つのコントロールに割り当てるステップであって、前記1つのコントロールが、少なくとも1つの物理ロケーションに関連付けられる、請求項1に記載の方法。
19. 複数のビジネスアプリケーション全体からデータを抽出し、複数の個別結果セットを生成する、複数のデータエクストラクタと、
    前記複数の個別結果セットを統合して統合結果セットにする、統合モジュールと、
    前記複数のビジネスアプリケーション全体における手続き欠陥を検出するために、前記統合結果セットにルールを適用する、ルールエンジンと、を含むシステム。
20. 前記複数のデータエクストラクタが各々、前記複数のビジネスアプリケーションのうちのビジネスアプリケーションに関連付けられたそれぞれのリアルタイムエージェントとインタフェースする、請求項19に記載のシステム。
21. 前記複数のビジネスアプリケーション全体からの前記手続き欠陥の検出を選択的に報告する、ケースマネージャを含む、請求項19に記載のシステム。
22. 前記複数のビジネスアプリケーション全体からの前記手続き欠陥の前記検出に応答して、改善アクションを選択的に実行する、改善モジュールを含む、請求項19に記載のシステム。
23. 前記改善モジュールが、指示された受け手に通知を提供すること、前記手続き欠陥の発生を記録すること、前記改善アクションを実施するためにヒューマンワークフローを引き起こすこと、および指定されたイベントの発生を防止するために自動手続きを起動すること、から成る1群のアクションのうちの少なくとも1つを実行する、請求項22に記載のシステム。
24. 前記複数のビジネスアプリケーションのうちのビジネスアプリケーションが、企業資源計画ソフトウェア、政府規制遵守ソフトウェア、および物理的プロビジョニングソフトウェア、から成る群に属するものうちの少なくとも1つである、請求項19に記載のシステム。
25. 前記手続き欠陥が、会社方針、政府規制、法律、職業規則、会計規則、公正な商慣行の声明、契約によって課される条件、および企業定款、のうちの少なくとも1つの違反から成る1群の欠陥のうちの少なくとも1つである、請求項19に記載のシステム。
26. 複数のビジネスアプリケーション全体からデータを抽出し、複数の個別結果セットを生成する、第1の手段と、
    前記複数の個別結果セットを統合して統合結果セットにする、第2の手段と、
    前記複数のビジネスアプリケーション全体における手続き欠陥を検出するために、前記統合結果セットにルールを適用する、第3の手段と、を含むシステム。
27. 前記第1の手段が、前記複数のビジネスアプリケーションのうちのビジネスアプリケーションに関連付けられた少なくとも1つのリアルタイムエージェントとインタフェースする、請求項26に記載のシステム。
28. 前記複数のビジネスアプリケーション全体における前記手続き欠陥の検出を選択的に報告する、第4の手段を含む、請求項26に記載のシステム。
29. 前記複数のビジネスアプリケーション全体における前記手続き欠陥の前記検出に応答して、改善アクションを選択的に実行する、第5の手段を含む、請求項26に記載のシステム。
30. マシンによって実行されたときに、マシンに、
    複数のビジネスアプリケーション全体からデータを抽出する複数のデータエクストラクタを取り出させ、
    複数の個別結果セットを生成するために、前記複数のデータエクストラクタを実行させ、
    組合せ結果セットにするために、前記複数の個別結果セットを組み合わさせ、
    前記複数のビジネスアプリケーション全体における手続き欠陥を検出するために、前記組合せ結果セットにルールを適用させる、命令を実施するマシン可読媒体。

Images