JP2008542872A - アクセス・エンフォーサー - Google Patents

Abstract

コンピュータ駆動のリソースマネージャー（１２２）は、ユーザ起動のタスク（１１３）についてのユーザのアクセス許可を定義する確立されたルール（１１２）に従ってそのようなタスクを選択的に実行する。ワークフローエンジン（１１６）はルールの再定義を管理する。ルールを変更する要求の受信に応答して、エンジンは要求を処理する。これは、要求を検査し、対応する承認経路を選択することを含む。また、ワークフローエンジンは選択された経路によって定義される一連のステージを通して順次進み、各ステージにおいてワークフローエンジンは選択された承認経路によって示される１つまたは複数の承認者からの承認を電子的に要請する。少なくとも１つの拒否または必要とされる全ての承認を受信するまで、エンジンはステージを通して継続する。必要とされる全ての承認の受信に応答して、ユーザ要求に従ってルールの修正を指示する電子的メッセージが送信される。

Description

本発明は、ＥＲＰ（enterprise resource planning）システムにおけるユーザの作業を規制するためにルール集合を使用するコンピュータ駆動のＥＲＰシステムに関する。より詳しくは、本発明は、それらのルールの再定義を管理する、各種のコンピュータ実装される方法および装置に関する。

本願は、米国特許法第１１９条に基づいて、先に出願された次の米国仮出願の利益を主張する。２００５年５月２３日に出願された米国仮出願第６０／６８３，９２８号明細書。上記出願の全体は引用してここに組み込まれる。

ＥＲＰシステムは、企業の多くのビジネス業務を統合し、自動化し、追跡し、規制する管理情報システムである。ＥＲＰシステムは、会計、販売、請求、製造、輸送、流通、在庫管理、生産、出荷、品質管理、情報技術、人事管理のような、企業活動の多くの場面に取り組むことができる。ＥＲＰシステムは、横領のような内部犯罪とともに、産業スパイのような外部犯罪の両方に対して防護するためにコンピュータセキュリティを含むことが可能である。ＥＲＰシステムは、様々な個々の詐欺、過ち、または悪用の発生を検出、防止、および報告するように構成することが可能である。

焦点を合わせる以外の領域の中では、ＥＲＰシステムは、企業が顧客（“フロントエンド”活動）、品質管理、企業の他の内部作業（“バックエンド”活動）とどのように交流するか、および、企業が供給業者および輸送業者（“サプライチェーン”）とどのように交流するかに取り組むことができる。

“サーベンス・オクスリー”、“Public Company Accounting Reform and Investor Protection Act of 2002”（上場企業会計改革および投資家保護法）、“ＳＯＸ”のような他の名称によっても知られる“The Sarbanes-Oxley Act of 2002”（Pub. L. No. 107-204, 116 Stat. 745, July 30, 2002）（米国企業改革法）のような最近の法律を考慮して企業がＥＲＰシステムを使用することは、ますます有益となっている。サーベンス・オクスリーは、企業の情報開示の正確さおよび信頼性を向上させることによって投資家を保護することを求める。この法令は、公開会社会計監視委員会（public company accounting oversight board）、監査人の独立性、企業の責任、強化された財務開示のような論点を取り扱う。

とりわけ、ＳＯＸは、ＣＥＯ（chief executive officer（最高経営責任者））およびＣＦＯ（chief financial officer（経理担当役員））が財務報告を認証することを要求する。さらに、ＳＯＸは、正確な財務開示を保証するように意図された一連の内部手続きを命じる。

近頃のＥＲＰシステムは、企業がよりよく組織化されることを助け、サーベンス・オクスリーのような規制条件の難題に取り組むが、ＥＲＰシステムを管理することは、非常に複雑であり得る。実際、企業内の幅広い適用範囲のために、ＥＲＰソフトウェアシステムは、今までに書かれたソフトウェアの最大の本体のいくつかを利用する。

ＥＲＰシステムは、従業員の活動を規制および追跡するために複雑なルールのフレームワークを活用する。これらのルールを設定することは、そのようなシステムの設計および運用とは離れた全く別個の事項である。システム管理者の労力を要する作業を要求するので、ＥＲＰシステムを構成および更新する作業は、複雑で、時間を消耗し、高価で、誤りがちであり得る。さらに、企業がＥＲＰシステムを構成することにおいて遅れを取るならば、ＥＲＰシステムの運用は、誤りがちで、労働集約的、または非効率にすぎない可能性がある。

概して、コンピュータ駆動のリソースマネージャーは、ユーザ起動のタスクについてのユーザのアクセス許可を定義する確立されたルールに従ってそのようなタスクを選択的に実行する。ワークフローエンジンは、ルールの再定義を管理する。ルールを変更する要求の受信に応答して、エンジンは要求を処理する。これは、要求を検査し、対応する承認経路を選択することを含む。また、ワークフローエンジンは、選択された承認経路によって定義される一連のステージを通して順次進み、各ステージにおいて、ワークフローエンジンは、選択された承認経路によって示される１または複数の承認者からの承認を電子的に要請する。少なくとも１つの拒否または必要とされる全ての承認を受信するまで、エンジンはステージを通して継続する。必要とされる全ての承認の受信に応答して、ユーザ要求に従ってルールの修正を指示する電子的メッセージが送信される。

この開示の教示は、方法、装置、ロジック回路、信号搬送媒体、または、これらの組み合わせとして実現することが可能である。この開示は、多数の他の効果および利点を与え、それらは続く説明から明らかである。

本発明の特徴、目的、効果は、添付図面に関する続く詳細な説明を検討した後、この技術分野の当業者に、より明らかになる。

＜＜ハードウェア構成要素および相互接続＞＞
＜全体構成＞
この開示の１つの態様は複数ユーザが共有するリソースコンピューティングシステムであり、各種のハードウェア構成要素および相互接続によって実現可能である。一例は、図１Ａのシステム１００である。

図１Ａにおいて、ワークフローエンジン１１６、ＥＲＰマネージャー１２２、等のような各種のデータ処理構成要素が存在する。これらは、１つまたは複数のハードウェア機器、ソフトウェア機器、１つまたは複数のハードウェアまたはソフトウェア機器の一部、または、上記の組み合わせによって実現することが可能である。これらのような下位の構成要素の構成は、図２〜図４を参照して、より詳細に以下で説明される。

システム１００は、デジタルデータ記憶装置１０２、１０３を含む。記憶装置１０３はＥＲＰマネージャー１２２に結合され、記憶装置１０２はワークフローエンジン１１６に結合されている。ワークフローエンジン１１６はさらに記憶装置１０３に接続されている。記憶装置構成要素１０２、１０３は以下でより詳細に説明される。

概して、ＥＲＰマネージャー１２２は、ユーザ起動されるタスクについてのユーザのアクセス許可を定義する確立されたルールに従って、そのようなタスクを監視および選択的に実行する。以下で説明されるように、ルールは１１２に記憶される。一例において、マネージャー１２２は、SAP社によるSAP R/3またはmySAP、Oracle社によるPeopleSoftまたはOracle Financials、SSA Global Technologies社によるBPCS、Made2Manage Systems社によるEnterprise Business System、NetSuite社によるNetERP、Microsoft（登録商標）社のビジネス部門によるMicrosoft（登録商標） Dynamics、Ramco Systems社によるRamco e.Applications、SYSPRO社によるSYSPRO ERPソフトウェア、等のような企業ソフトウェア製品である。ワークフローエンジン１１６はルール１１２の再定義を管理する新規な製品であり、雇用、解雇、昇進、システム再構成、吸収合併、企業再編、等を受け入れるために時々必要である。

構成要素１１６、１２２は、任意の数のユーザインタフェースによってアクセス可能である。２つのユーザインタフェース１１８、１２０は、一例として表されている。この例において、１つのインタフェース１１８は承認者（ある人）によって使用され、他のインタフェース１２０は要求者（ある人）によって使用されている。しかし、インタフェース１１８、１２０は入れ替え可能であり、エンジン１１６、マネージャー１２２、またはその両方にログオンするために使用されるユーザ認証シーケンスが異なるのみである。インタフェース１１８、１２０は、キーボード、ビデオディスプレイ、コンピュータマウス、または限定しない他のインタフェースのような、ここで説明される目的のために適切な任意のヒューマンマシンインタフェースを備える。特定の例において、インタフェース１１８、１２０は、エンジン１１６およびマネージャー１２２にウェブベースのインタフェースを提供する。

構成要素１１６、１２２、１１８、１２０は、ローカルエリアネットワーク、広域ネットワーク、インターネット、企業イントラネット、ポータル、トークンリング、等のような適切なリンクを介して相互接続されている。

＜記憶装置の概要＞
記憶装置１０２、１０３の各モジュールは、ここで説明される目的のために適切な任意の種類の装置読み取り可能なデジタルデータ記憶装置を使用するように実装することができる。ある例は、磁気、光、テープ、ディスク、メインフレームコンピュータ、分散記憶装置、大容量記憶装置、サーバ、スーパーコンピュータ、パーソナルコンピュータ、または限定しない任意の他の記憶装置を含む。モジュール１０２、１０３は、（図示するように）分離され、または１つの統合することが可能である。

記憶装置１０２は下位の構成要素１０４、１０８、１１０を含み、記憶装置１０３は下位の構成要素１１２〜１１５を含む。いずれの場合においても、これらの下位の構成要素は、同一のまたは異なる物理的装置、論理的装置、記憶セクタまたは他の領域、レジスタ、ページ、リンクリスト、関係データベース、または限定しない他の記憶装置によって実現することが可能である。

１つの特定の実施形態において、記憶装置１０３の内容、相互接続、動作は、SAPによるSAP R/3またはmySAP ERPのようなシステムを含む。この製品についての追加の情報は、次のような情報源から入手可能であり、これらは引用してここに組み込まれる。１９９９年４月に出版されたISBN 0764503758の“SAP R/3 Administration for Dummies”、Anderson他による２００３年５月に出版されたISBN 0789728753の“SAP Planning: Best Practices in Implementation”、Hurst他による２０００年４月に出版されたISBN 0782125972の“Configuring SAP R/3 FI/CO: The Essential Resource for Configuring the Financial and Controlling Modules”、Mazzullo他による２００５年７月に出版されたISBN 0131860852の“SAP R/3 for Everyone: Step-by-Step Instructions, Practical Advice, and Other Tips and Tricks for Working with SAP”。

記憶装置１０２、１０３の下位の構成要素は、以下でより詳しく説明する。

＜リソース＞
記憶装置１０３において、リソース１１５は、記憶されたデータ、処理、サブルーチン、アプリケーションプログラム、または、マネージャー１２２によるＥＲＰサービスの目的である他のアクションまたはデータを表わす。例えば、リソース１１５は、調達、現金化、集金、財務報告、および他のビジネスプロセスを自動化するように動作可能なＥＲＰシステムの構成要素を含むことが可能である。選択的に、リソース１１５は、ファイルサーバ、ディレクトリシステム、ファイル共有システム、データリポジトリ、データライブラリ、等のような非ＥＲＰリソースを含むことが可能である。さらにもう１つの例において、リソース１１５は、以下で別個に説明される物理的プロビジョニングシステムの構成要素を含むことが可能である。

＜タスク＞
記憶装置１０３はタスク１１３のリストも含み、これはマネージャー１２２がユーザに代わって実行することが可能なトランザクションを定義する。ある例は、販売会社マスタデータの維持管理、支払いの実施、請求書の作成、請求書の発行、受領した現金の記入、仕訳帳への記入、請求書の記録、賃金処理、および関連する会計および財務の項目を含む。

＜人員＞
人員データベース１１４は、システム１００によって認識される人のリストである。例えば、システム１００がその企業主体に代わって動作する、企業主体の従業員および請負業者が存在し得る。人員データベース１１４は、ＥＲＰタスク１１３の管理者またはユーザについての情報を含むことが可能である。例として、データベース１１４は、各々の人の名前、従業員ＩＤ、その人に対応付けられた“ロール”、等を列挙することが可能である。エンジン１１６は、ワークフローステージ１１０の必要な階層を通してユーザ要求を渡す処理の間に、要求者および承認者についての情報を収集することを含む目的のために、人員データベース１１４へのアクセスを有する。

＜ルール＞
ルール１１２は、誰が、いつ、タスク１１３を実行することができるかを示す。言い換えると、ルール１１２は、ＥＲＰマネージャー１２２にタスク１１３を実行させるために、ユーザが有さなければならない必要なアクセス許可を示す。以下で説明するように、エンジンはルール１１２の変更を管理および実現するので、エンジン１１６はルール１１２へのアクセスを有する。これらの変更は、ＥＲＰマネージャー１２２が、雇用、解雇、昇進、システム再構成、企業再編、等のような通常のイベントに従って、システム１００を運用する組織によって指図された変更への必要に応じて適合させることを可能とする。

一例において、ルール１１２は、予め定められた“ロール”の仕様から作成される。ルール１１２またはデータベース１１４のいずれかは、どのロールがどの人に割り当てられているかのマッピングを含む。ロールは、ユーザが実行を許可されたタスク１１３の集合である。また、複合ロールが存在し、これは単一のロールのグループである。言い換えると、ロールは、請求書の作成、請求書の支払い、等のような、機能的なタスクとして定義することが可能なジョブ負担のグループである。

＜ワークフローおよびイニシエーター＞
記憶装置１０２において、ワークフロー１１０は各種の予め定められた承認経路を定義し、各経路は１つまたは複数のステージを含む。各ワークフローはパターンまたは経路とも呼ばれる。概して、ワークフローは、エンジン１１６がルール１１２を変更するユーザ要求を処理するステージの順序付けられた集合である。

また、ワークフローステージは、適切な承認者を決定するために（以下で説明する）アクセス要求フィールド値を使用することが可能である。例として、ワークフローステージは、承認のために要求者のマネージャーに要求をルーティングするためにアクセス要求フィールド値を使用することが可能である。一例として、各ワークフローステージは決定を行うために必要な全ての情報およびツールを含むので、ワークフロー１１０は包括的である。選択的に、あるワークフローは複数の経路を使用するように設計することができる。複数の経路は、１つより多くのワークフローステージが同時に実行されることを可能とする。また、ワークフロー経路は迂回経路を含むことが可能であり、迂回経路は１つのワークフローから他のワークフローへ要求を転送する処理である。迂回は、特定のワークフローステージにおいて行われる決定に基づく。ワークフロー１１０のさらなる詳細は、以下でより詳細に説明される。

ルール１１２への要求された変更を実現する前に、エンジン１１６は全ての必要な承認を集めることを確実にし、これは適切なワークフロー経路およびその規定されたステージによって誘導される。一般に、承認を要請するとき、エンジン１１６は個々の“承認者”に通知を送信し、これらの通知は１０８によって規定された形式および／または内容を有する。

エンジン１１６は、どのワークフロー１１０を選択すべきか決定するためにイニシエーター１０４を使用する。各イニシエーターは、ユーザ要求の属性の種々の組み合わせを含む。各イニシエーターは、要求書式からのいくつかのまたは全てのフィールド値を使用することができる。従って、エンジン１１６が、与えられた属性の集合を有する（すなわち、１つの特定のイニシエーターを規定する）ユーザ要求を受信すると、エンジン１１６はワークフロー１１０の特定の１つを起動する。これに関して、イニシエーター１０４は、さらにマッピング１０４Ａ、１０４Ｂを含む（またはマッピング１０４Ａ、１０４Ｂへのアクセスを有する）ことが可能である。１つのマッピング１０４Ａは、ユーザ要求の属性とイニシエーターとの間をマッピングする。言い換えると、このマッピング１０４Ａは、どのユーザ要求の属性の集合が“イニシエーター”を選定するかを定義する。他のマッピング１０４Ｂは、イニシエーター１０４とワークフロー１１０との間をマッピングする。言い換えると、このマッピング１０４Ｂは、１０４Ａによって定義された各イニシエーターについて開始されるべき適切なワークフロー１１０を識別する。この例において、イニシエーター１０４は、（図示しない）システム管理者によって生成および維持管理される。

どのような限定も意図しないが、いくつかの典型的なユーザ要求の属性は、次のように列挙される。要求の種類（例えば、新規、変更、ロック、ロック解除）、要求の優先度（例えば、重要、高い、中間、低い、等）、職務領域（例えば、財務、調達、人事（HR）、等）、企業アプリケーション（SAP生産（Production（PRD））、SAP品質保証（Quality Assurance（QA））、レガシー、等）、物理的アクセス。

この同じ例を続けると、以下はイニシエーター１０４のいくつかの例である。第１のイニシエーターの例は、財務ユーザタイプについてSAP生産システムにおいて生成される新たなアカウントの要求であり、この要求は高い優先度である。第２のイニシエーターの例は、人事（HR）ユーザについてのロールを削除または追加するように既存のレガシーアプリケーションアカウントを変更する要求であり、重要な優先度を有する。第３のイニシエーターの例は、SAP生産システムにおける既存の調達ユーザをロックする要求であり、重要な優先度の要求を有する。第４のイニシエーターの例は、HR SAPからの終了イベントの通知を受信するマネージャー１２２に応答して、財務ユーザのアクセスを削除するために、自動化された、ＥＲＰマネージャー１２２による低い優先度の要求（または、ワークフローエンジン１１６によって自身で生成した要求）である。

そして、与えられたイニシエーター１０４の存在は、与えられたユーザ要求の処理において、ワークフローエンジン１１６によってどのワークフロー１１０が使用されるべきかを効率的に指図する。概して、各ワークフローはステージのパターンであり、各ステージは、１または複数の“承認者”が検査を承認し、ユーザ要求（またはその一部分）を承認することを要求する。各ステージは、さらに、その承認者が、職務分離または他のリスク分析の実行することのような必須の処置を実行すること（または、推奨される処置を助言すること）を要求することが可能である。どのステージにおいても、要求処理を通して、承認が与えられる前に、リスク分析を必須とすることが可能である。それが完了すると、ユーザからの他の既存のアクセスを除去することによって、および／または、処理が許可される前に、承認された管理を軽減する代替がユーザに割り当てられることを指定することによって、全ての問題が解決されることを確実にする手段が存在する。職務分離のリスクのために適切な代替の管理が存在しないならば、もう１つの代替が、要求とともに転送を継続する前に、管理を軽減する要求を生成し、承認を求めることが可能である。

ワークフロー１１０は、分岐、迂回、複数の並列経路、分枝、または、固定された、または、１つのステージまたは他からの出力、ユーザ要求の内部情報、要求者または承認者についての外部情報、または他の要因、等に条件的に基づく、任意の他の規定されたルーティングを含むことが可能である。１つのステージから次への進行において、選択されたワークフロー経路は、第１の承認者による入力、第１の承認者によって実行された分析の結果、他の設計者による入力、または他の関連する事実、選択、または入力のような、各種の条件に依存することが可能である。上記において、ワークフローパターンは、ワークフロー設計者の創作力によってのみ制限される。

＜ワークフローの例＞
図１Ｂはいくつかの典型的なワークフローを表わす。ワークフロー１５１は、直列に３つのステージ１５２、１５４、１５６を含む。この例において、ワークフロー１５１は承認者による承認（ステージ１５２）、次に、承認者による承認（ステージ１５４）、最後に、承認者による承認（ステージ１５６）を必要とする。いずれかの承認者が拒否するならば、ワークフロー１５１は破綻し、“拒否”である最終的な回答とともに早期に完了する。

ワークフロー１５７は異なる例を表わす。このワークフローは３つのステージ１５８、１６０、１６１を含み、ここでステージ１６０は２つの構成要素１６０Ａ、１６０Ｂを含む。まず、ステージ１５８において、第１ステージの承認者は要求を承認しなければならない。次に、２つの第２ステージの承認者（下位の部分１６０Ａ、１６０Ｂ）のいずれか一方が承認しなければならない。最後に、第３ステージの承認者が要求を承認しなければならない（ステージ１６１）。

上記の例に表わされているように、ワークフローの各ステージは、承認または拒否を出すように承認者に要求することが可能である。ワークフローは、各ステージにおいて異なるまたは追加のアクションを用いて設計することが可能である。例えば、ステージは、承認者が、コンピュータ生成されたリスク分析を実行し、手動で算出されまたは調査された情報を入力する、等を要求または推奨することが可能である。この形態において、ワークフロー１６５は、一例のまたはより複雑なワークフローを与える。ここで、第１ステージ１６６は、その承認者がある情報を入力するように要求する。この情報が十分に送信されることができないならば、ワークフローは１６６Ａおよび終了（１６８）を介してステージ１６６を抜け出る。関連した情報が利用可能となると、ユーザ要求が新たに送信されなければならない。しかし、承認者が全ての要求された情報を入力するならば、ステージ１６６は１６６Ｂを介して次のステージ１７０に進む。その承認者の入力に基づいて、ステージ１７０は承認者１７２、１７４の一方に分岐する。例えば、ステージ１７０の承認者がある情報を見つけることができないならば、このステージ１７０は、最後のステージ１７４に入るために要求される条件として、この情報を取得するためにステージ１７２の人に自動的にワークフローをルーティングする。

＜動的なワークフローの変更＞
上述のように、各ワークフローパターンは、線、分岐、循環、並列経路、分枝、等のような各種の異なる予め設定されたパターンを含むことが可能である。しかし、ワークフローの設計された配置を超えて、単純なまたは複雑なワークフローは、ある動的な変更に従うことが可能である。ワークフローステージへの変更は、そのステージの承認者の指示において行われ、それゆえに、これらの変更は“動作中に”行われると言える。これは、図６に関して以下でより詳細に説明される。しかし、いくつかの例を与えるために、ここで図１Ｃを参照する。

基本的に、基本のワークフロー経路／パターンは固定なので、承認者は、動作中のワークフローへの制限された種類の変更を行うことができる。承認者は、側線に入れる（sidetrack）（１７９）、委任し、報告が戻される（１８３）、経路変更する（１８７）のようなアクションを実行することができる。図１Ｃは、（図示しない関連のないステージを有する）各種の部分的なワークフローの場面におけるこれらのアクションを表わす。

例１７９において、ワークフローパターンは１８０Ａ、１８０Ｂを介してステージ１８０を通して進む。ここで、ステージ１８０の承認者は、さらなる作業がまだ行われる必要があると認識し、承認者はもう１人の人（ステージ１８２）があるアクションを行うことを要求し、その後、ある人が新たな要求を提示する。特定の例として、承認者が要求の適切さについて他の人からの助言を求めるとき、要求を側線に入れること（sidetracking）が生じ得る。例は、要求者が有する既存のアクセスのいくつかがまだ必要かどうかを調べるために、承認者が以前のマネージャーに問い合わせたい場合である。応答に基づいて、マネージャーはアクセスを除去するように選択することが可能である。または、承認者が彼の知識の外の領域について要求されたアクセスに自信がなく、承認および処理における継続のために、または、彼に助言し、彼の承認および拒否のために要求を戻し、そして処理において転送するために、他の人に要求を転送する場合であり得る。

例１８３において、ステージ１８４の承認者は、もう１人の行為者（ステージ１８６）に、アクションを行い、承認者１８４に報告を戻すことを要求する。従って、ワークフローは承認者１８４から（１８４Ａを介して）委任１８６に進み、委任された者がアクションを行った後、（１８４Ｂを介して）承認者１８４に戻る。例えば、承認者１８４は他の人からのさらなる情報を要求するが、承認者が承認の決定を行う管理権を留保することを望むとき、この場面は有効であり得る。シナリオ１８３のいくつかの例は、承認または拒否の決定を与える前に、新たな承認者が技術的な助言を求め、セカンドオピニオンが欲しい場合を含む。この管理を軽減する割り当ては、この場面のために適切なアクションであるか？承認者の多くは管理の知識を有さないので、彼らは管理の専門家からそれを求める。

例１８７において、ステージ１８８の承認者は通常の経路１８８Ｂからワークフローを経路変更する。例えば、承認者は彼／彼女の承認の職権を他の行為者（ステージ１９０）に割り当て、１８８Ｂの代わりに、１８８Ａ、１９０Ａを介して次のステージ１９２にワークフローが進む。例えば、承認者１８８はユーザの要求を時間どおりに決定する時間がなく、または他の人は決定を行うためにより適任であると認めているとき、この場面は有効であり得る。このワークフロー１８７のもう１つの実施形態において、承認者１８８は、承認者１８８に入手可能でない情報を収集するために行為者１９０にフローをルーティングし、最後のステージ１９２にルーティングする。さらに、物理的プロビジョニングのシナリオ（すなわち、リソース１１５は物理的な資産である場合）において、承認者は、実際、ある方法で物理的な処理をサポートする外部システムとすることが可能である。例えば、サイトへの人の物理的なアクセスの一部は、訓練の範囲の認証を完了する必要があり得る。この場合において、ワークフローは訓練の承認者に進むことが可能であり、または、それは、実際、サイトへのアクセスの要求を受け入れ、未処理の訓練の要求を自動的に予約し、サイトにアクセスするためにその人に利用可能な最も早い完了または承認の日付を通知する訓練システムと統合されることが可能である。

＜典型的なデジタルデータ処理装置＞
上述したように、（ワークフローエンジン１１６およびマネージャー１２２および他のような）データ処理の実体は、各種の形態で実現することが可能である。

ある例は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、または他のプログラム可能なロジックデバイス、離散ゲートまたはトランジスタロジック、離散ハードウェア構成要素、またはここで説明した機能を実行するように設計されたそれらの任意の組み合わせを含む。汎用プロセッサはマイクロプロセッサとすることが可能であるが、その代わりに、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械とすることが可能である。また、プロセッサは、コンピューティングデバイスの組み合わせ、例えば、ＤＳＰおよびマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと結合した１つまたは複数のマイクロプロセッサ、または任意の他のそのような構成として実現することも可能である。

より詳細な例として、図２はデジタルデータ処理装置２００を表わす。装置２００は、マイクロプロセッサ、パーソナルコンピュータ、ワークステーション、コントローラ、マイクロコントローラ、状態機械、または他の処理装置のような、デジタルデータ記憶装置２０４に結合されたプロセッサ２０２を含む。この例において、記憶装置２０４は、不揮発性記憶装置２０８とともに、高速アクセス記憶装置２０６を含む。高速アクセス記憶装置２０６は、例えば、プロセッサ２０２によって実行されるプログラム命令を記憶するために使用することが可能である。記憶装置２０６および２０８は、図３および図４に関してより詳細に説明されるように、各種の装置によって実現することが可能である。多くの代替が可能である。例えば、構成要素２０６、２０８のうち一方が除去され、さらに記憶装置２０４、２０６、および／または２０８はプロセッサ２０２上に設けることが可能であり、または、装置２００の外部に設けることも可能である。

また、装置２００は、コネクタ、ライン、バス、ケーブル、バッファ、電磁的リンク、ネットワーク、モデム、または、プロセッサ２０２が装置２００の外部の他のハードウェアとデータを交換するための他の手段のような、入力／出力２１０を含む。

＜信号搬送媒体＞
上述したように、デジタルデータ記憶装置の各種の例は、例えば、記憶装置１０２、１０３（図１）のようなシステム１００によって使用される記憶装置を提供する、記憶装置２０４および２０８（図２）を実現する、等のために使用することが可能である。この応用に応じて、このデジタルデータ記憶装置は、データの記憶、または装置読取り可能な命令の記憶のような各種の機能のために使用することが可能である。これらの命令は、各種の処理機能の実行においてそれら自身を補助し、または、コンピュータ上にソフトウェアプログラムをインストールするために役立つことが可能である。そのようなソフトウェアプログラムは、この開示に関する他の機能を実行するように実行可能である。

どのような場合においても、信号搬送媒体は、装置読取り可能な信号をデジタルで記憶するためのほぼ全てのメカニズムによって実現することが可能である。一例は、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＷＯＲＭ（Write Once Read Many）、ＤＶＤ（Digital Versatile Disk）、デジタル光テープ、ディスク記憶３００（図３）、または他の光記憶装置のような光記憶装置である。もう１つの例は、従来の“ハードドライブ”、“ＲＡＩＤ（redundant array of inexpensive disks（レイド））”、または他の“ＤＡＳＤ（direct access storage device（直接アクセス記憶装置））”のような直接アクセス記憶装置である。もう１つの例は、磁気または光テープのようなシリアルアクセス記憶装置である。デジタルデータ記憶装置のさらに他の例は、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable Read Only Memory）、フラッシュＰＲＯＭ（Programmable Read Only Memory）、ＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）、メモリレジスタ、バッテリーバックアップされたＲＡＭ（Random Access Memory）、等を含む。

典型的な記憶媒体はプロセッサに結合されるので、プロセッサは記憶媒体から情報を読み出し、および記憶媒体に情報を書き込むことができる。その代わりに、記憶媒体はプロセッサに統合することが可能である。もう１つの例において、プロセッサおよび記憶媒体は、ＡＳＩＣまたは他の集積回路に搭載することが可能である。

＜ロジック回路＞
（上述した）装置実行可能な命令を収容する信号搬送媒体とは対照的に、別の実施形態は、ワークフローエンジン１１６およびシステム１００の任意の他の処理機能を実現するためにロジック回路をする。速度、価格、工具費のような領域における応用の特定の条件に応じて、このロジックは数千の小さな集積されたトランジスタを有するＡＳＩＣを構築することによって実現することが可能である。そのようなＡＳＩＣは、ＣＯＭＳ（Complementary Metal Oxide Semiconductor（相補性金属酸化膜半導体））、ＴＴＬ（Transistor-Transistor Logic）、ＶＬＳＩ（Very Large Scale Integration）、または他の適切な構成を用いて実現することが可能である。他の代替は、デジタル信号処理チップ（ＤＳＰ）、（抵抗器、コンデンサ、ダイオード、コイル、およびトランジスタのような）離散回路、ＦＰＧＡ、ＰＬＡ（Programmable Logic Array）、ＰＬＤ（Programmable Logic Device）、等を含む。

図４は集積回路４００の形態のロジック回路の例を表わす。

＜＜動作＞＞
この開示の構成の特徴を説明したが、ここで開示の動作の形態を説明する。ここで開示される方法、処理、またはアルゴリズムのステップは、ハードウェア、ハードウェアによって実行されるソフトウェアモジュール、または２つの組み合わせにおいて直接に実現することが可能である。

＜全体の動作シーケンス＞
図６は、この開示の方法の形態の一例を表わすためのシーケンス６００を表わす。このシーケンスは、コンピュータ駆動のリソースマネージャーが監視し、ユーザ起動のタスクについてのユーザのアクセス許可を定義する確立されたルールに従ってタスクを選択的に実行するシステムにおいて実行され、特に、このシーケンスはそれらのルールの再定義を管理する方法に関する。概して、要求者はルールを変更するために要求を送信し、エンジン１１６は繰り返し全ての適切な人から承認を集め、最終的に、コンピュータ読み取り可能なメッセージの形態で要求者に最終結果を送信する。

好ましくは、シーケンス６００は、要求を承認するための意思決定プロセスの標準化を助け、情報に基づいて決定を行うために必要な情報の包括的な観点を提供する。さらに、シーケンス６００は、各ワークフローにおける権限を与えられた承認者を自動的に識別し、要求をルーティングすることによって、適切な部門が要求承認プロセスに含まれることを保証する。

説明を簡単にするために、しかし、限定を意図するものではなく、図６の例は、上述した（図１Ａ〜１Ｃ）システム１００の特定の場面において説明される。

ワークフローエンジン１１６がルール１１２を変更する要求を受信すると、ステップはステップ６０２において開始する。要求６０２はユーザ生成され（すなわち、人間のユーザから生じ）、またはシステム生成される（すなわち、ＥＲＰマネージャー１２２の処理から生じる）ことが可能である。

ルール１１２の変更を求める人または処理を要求者（requestor）と呼ぶ。要求は、要求者自身または他のいずれかのために、ロールを追加、削除、変更、または生成する要求に関する。言い換えると、要求は、要求者が、一連のセキュリティアクセスおよびアクセス許可の変更、従ってルール１１２の変更を求める手段である。

一例において、要求者は、エンジン１１６によって提供される予め定められた書式に記入し、送信するために、ウェブベースのインタフェース１２０を使用することによって要求を送信する。例えば、ユーザは、エンジン１１６の知られたＵＲＬ（uniform resource locator）をウェブブラウザに入力することによって、エンジン１１６へのアクセスを取得することが可能である。要求処理６０２の一部として、エンジン１１６は、ユーザ名、パスワード、等のような予め定められた認証処理を充足することを要求者に要求することが可能である。図９は、要求書式の一例９００を表わす。要求の記入において、要求者は、要求者の識別子、適用可能なマネージャーの識別子、ユーザに割り当てられるロール、適用可能なビジネスユニット、アクセスが求められるアプリケーション名、要求理由、従業員のカテゴリー、ロールまたはトランザクションまたはオブジェクトのいずれにアクセスが求められるか、等のような情報を入力する。ある典型的な要求は、ＮＥＷ、ＣＨＡＮＧＥ、ＬＯＣＫ、ＵＮＬＯＣＫ、ＤＥＬＥＴＥ、等のようなアクションを含む。また、ユーザは、高い、中間、または低い、のような要求の優先度を入力することが可能である。

ＮＥＷ要求は新たなロールを求め、ＣＨＡＮＧＥ要求はロールの変更を求める。ＬＯＣＫはユーザアカウントのロックを求めるので、そのユーザアカウントは使用することができず、ＵＮＬＯＣＫは再びユーザアカウントを有効にする。ＤＥＬＥＴＥ要求は、目的のシステムからのユーザアカウントの削除を求める。物理的プロビジョニングシステムにおいて、ＬＯＣＫ要求は、物理的な場所およびその構成要素への人の全てのアクセスを無効にする。この状況において、ＵＮＬＯＣＫ要求は、以前に無効にされ、または、ＵＮＬＯＣＫが承認および処理されたときに記録においてその人が有する全てのアクセスを再び有効する。

ステップ６０４において、エンジン１１６は、１１０からワークフロー経路の適切な１つ（または複数）を決定するために要求の内容を分析する。一例において、それは、要求を解析し、解析された構成要素がイニシエーター１０４の１つを選定するか否かを決定するためにマップ１０４Ａを調べ、そして、どのワークフロー１１０がこの特定のイニシエーターに対応するかを決定するためにマップ１０４Ｂを調べるエンジン１１６によって実行される。選択的に、どのイニシエーター１０４がユーザ要求によって提示されたかの決定において、人員データベース１１４から要求者（および／または要求）についての関連する情報を能動的に収集するために、エンジン１１６はさらなるステップを実行することが可能である。これは、エンジン１１６および要求を正確に判断するために将来の承認者に大部分の最新情報が利用可能であることを保証する。

上述したように、各ワークフロー経路は、多数のステージ、および、ステージを通して１つまたは複数の規定された進行の順序を有する。従って、ステップ６０４において適切な経路を識別したので、ルーチン６００の次の動作は、第１ステージの処理（６０５）を開始することである。すなわち、ステップ６１０において、エンジン１１６は、６０４において選択されたワークフロー経路の現在のステージに関する第１承認者を識別する。

第１ステージを共有する２つ（またはより多く）の承認者が存在し得る。その場合、ステップ６１０において全ての承認者を識別する。実装に応じて、承認者（approver）は、ロール、職種、または特定の人とすることが可能である。ロールオーナー承認者、セキュリティ承認者、マネージャー承認者、物理的アクセスレベル承認者、等の異なるアクセス許可を有する異なる種類の承認者が存在し得る。

ステップ６１０は、関連するロール（承認者）を最初に識別する選択されたワークフロー経路を検査し、そして、与えられたロールを誰が占有しているかを見つけ出すために人員データベース１１４に対してこの情報を相互参照するエンジン１１６によって実行される。言い換えると、ユーザ情報は、ワークフロー処理における各ステージを通して要求が移動するときに、（１１４のような）ステージからユーザ情報が抽出され、ワークフローサイクルの各ステップにおいて大部分の最新情報が利用可能であることを保証する。

したがって、次のステップ（６１２）において、エンジン１１６は識別された承認者に電子的通知を送信する。これらの通知は、フォーマット、構文、言語、主題、または予め定められた通知１０８によって特定される他のガイドラインを利用する。説明を簡単にするために、この例は、現在のステージにおいて１つの承認が存在する場合を使用する。通知は、電子メールが一例である、任意の種類の装置によって送信される通知において実現することが可能である。一例において、各々の承認者の通知（６１２）は、承認者にワークフローエンジン１１６にログインすることを促す電子メールである。現在のステージの承認者は図８において説明されるように応答し、これは以下で別個に説明される。

ステップ６１２の後、ステップ６１４はステップ６１２において通知された承認者によるアクションを待つ。例えば、現在のステージの承認者は、要求を承認または拒否することが可能である。または、要求が個々の部分要素を有するならば、承認者はいくつかを承認し、他を拒否することが可能である。さらに、承認者は、側線に入れる、委任し、報告が戻される、および／または、経路変更する、のような各種の動的な修正をワークフローに行うことが可能である。潜在的な承認者のアクションのメニューは、図８の場面において以下でより詳細に説明する。選択的に、ステップ６１４はタイムアウト規定を適用することが可能であり、この場合において、与えられた時間内に与えられた承認者またはステージの全てのアクションが受信されないならば、エンジン１１６は要求を拒否する。

ステップ６１６は、現在のステージが完了したとき発生する。ステップ６１６は、エンジン１１６が、現在のステージに必要とされる全ての承認を受信したが、現在のワークフローがまだ未完了のステージを含むことを発見したとき、６１６Ａを介してステップ６２０に進む。ステージが異なるオーナーを有するいくつかのロールの承認を必要とする場合において、エンジン１１６は、次のステージに進む（６２０）前に、全てのロールからの承認を必要とする。同様に、ステージが複数の項目の承認を必要とするならば、エンジン１１６は、次のステージに移る前に、全ての必要とされる応答の収集を確実にする。

一般に、次のうち１つが発生したことをステップ６１６が発見するまで、動作６１０〜６１６はループで繰り返す。（１）ユーザ要求の全ての構成要素が拒否され、この場合において、ステップ６１６は６１６Ｃを介して６１８に進み、または、（２）エンジン６１６が全てのステージの全ての承認を収集し、この場合において、ステップ６１６は６１６Ｂを介して６１８に進む。

ステップ６１６が６１８に移った後、エンジン１１６は要求者に拒否（または承認）の電子的通知を送信する。承認の場合において、ステップ６１８は、適切な人、または、要求され承認されたルール１１２への変更を実現するコンピューティング装置に命令を送信する追加のステップを行う。一例において、ステップ６１８はシステム管理者に命令を送信し、システム管理者は、以下でより詳細に説明するように、図７におけるルール変更を実現する。

＜承認者のアクション＞
上述したように、エンジン１１６は、承認者がワークフローエンジン１１６にログインすることを促す電子メールのような通知（ステップ６１２、図６）を各承認者に送信する。言い換えると、各承認者は、彼／彼女に彼／彼女の承認を求める新たな要求を通知するシステム生成されたメッセージを受信する。一例において、（図示しない）通知は、例えばハイパーリンクによって、エンジン１１６によって提供されるウェブページにログインするように、承認者に指示する。エンジン１１６はその承認者のためにこのウェブページを具体的に適応させる。

承認者がこのウェブページにログインすると、これは一連の動作を開始し、それによって、ワークフローエンジン１１６は、この要求を処理し、それらのオプションについて決裁するための各種のオプションを提示する。このシーケンスは、一例において、図８の動作８００によって説明される。限定することなく、このシーケンス８００は、図１Ａ〜１Ｃのシステム１００の場面において説明される。この例において、シーケンス８００は主としてワークフローエンジン１１６によって実行され、あるステップはＥＲＰマネージャー１２２によって実行される。

ステップ８０２において、承認者は、ワークフローエンジン１１６によって提供される承認者に固有のウェブページにログインする。図１０は、このウェブページの例を表わす。この例において、ウェブページは承認者の承認を求める各々の要求を自動的に識別し、要求の種類、優先度、要求の日付、要求者、期限、等のような要求についての各種の情報を提示する。この画面は、明示的に、または、黙示的に、承認者に未決定の要求のうち１つを選択するように促すことが可能である。ある場合において、ステップ８０２はログオンを回避することが可能であり、この場合において、エンジン１１６はログオン画面を通過する必要なく直接に承認者を要求の情報に向けさせる。

ステップ８０４において、エンジン１１６は、リストされた未決定の要求のうち１つの承認者の選択を受信し、その要求に関する詳細な画面を提示する。言い換えると、承認者はその要求について決裁するために所望の要求をクリックし、エンジン１１６は選択された要求に固有の続く画面を提示する。図１１は、サンプルの要求についての要求の詳細画面の例を表わす。要求の詳細画面は、承認者が選択された要求について決裁するために各種の選択肢を提示する。１つのオプションにおいて、表示された要求に隣接するＧＵＩ（graphical user interface）ボタンとして提示される、標準の承認者のアクションの集合が存在する。エンジン１１６は、処理されるワークフローのステージに従ってそれらの機能へのアクセスを承認者が許可されていないならば、いくつかまたは全てのボタンを隠すことが可能である。

この例において、承認者は次の選択肢を有する。承認８０６、拒否８０８、保留８１０、ロールの選択８１２、ロールの割り当て８１４、動的なワークフローの変更８１６、および／または、リスク分析の実行８１８。リスク分析動作８１８の選択的な続きとして、エンジン１１６は、向上した分析８２０、ミティゲーション（mitigation）８２２、およびシミュレーション８２４を提示する。動作８０６〜８２４は以下でより詳細に説明される。

ステップ８０６、８０８において、エンジン１１６は要求されたアクションの承認者の承認または拒否を受信する。いずれかの場合において、これはシーケンス８００を終了し、承認者の作業が完了する。現在の要求が実際に要求の束を含む場合において、承認者は各々の要求を個々に承認または拒否するように決裁する（８０６、８０８）ことが可能である。他の要求の拒否を伴う１つまたは複数の束ねられた要求の承認を“部分的な”承認または拒否と呼ぶ。

ステップ８１０において、エンジン１１６は、現在の要求のいくつかまたは全てを“保留”する、または、以前に決定された保留を解除する承認者の選択を受信する。一実施形態において、承認者は完全な保留を決定することが可能であり、これは、承認者が保留を解除するまで処理６００を停止する。もう１つの実施形態において、承認者は保留／遅延を決定し、その結果、エンジン１１６は、処理の状況を維持し続け、最終的にステップ６１６からステップ６１８まで進む前に、承認者の決定を得るために後に戻ってくる。これは、例えば、承認者がある理由のための彼の決定を遅らせることを期待するが、要求についての決裁の全体の処理を遅らせたくないならば、有効であり得る。複数の束ねられた要求の場合において、承認者はある要求についての保留（“部分的な”保留）を決定し、他の要求をすぐに決裁することが可能である。

ステップ８１２は、１つまたは複数のロールを選択する承認者の選択を受信する。ロールの“選択”は、形成すること、モデル化すること、複製すること、構築すること、または、要求者に割り当てられる（８１４）ロールを準備することを含む。選択的に、ワークフローエンジン１１６は、承認者の指示のもとで、１つのユーザプロファイルからもう１つへロールを複製するために、および、ロールのセキュリティアクセスを複製するために、ロールのモデル化を実行することが可能である。ステップ８１２はＥＲＰマネージャー１２２によって、より詳細な例において、接続されたSAPシステムまたは目的のシステムからのロール、または、遠隔のサイトからアップロードされたロールを選択することによって実現される。

ロールの選択（８１２）の後、ステップ８１４において、承認者はロールを所定の人に割り当てる（または所定の人からロールを削除する）ことができる。より詳しくは、ステップ８１４は、エンジン１１６が、ロールを要求者（または要求者に代わって役割を果たす人またはロール）に割り当てる承認者の選択を受信することを含む。ロールはモデル化を通して手動で割り当てることが可能である。“直接的な”割り当ては、特定の人にロールを割り当て、“間接的な”割り当ては職種または業務にロールを割り当て、ユーザに職種または業務を割り当てさせる。ロールがユーザに割り当てられると（８１４）、対応するタスク１１３が自動的に割り当てられる。一例において、ステップ８１４はＥＲＰマネージャー１２２によって、より詳細な例において、SAPシステムのある機能を使用することによって、実現される。

ロールが割り当てられる前に、ルーチン８００は選択的に許可し、または、ワークフローの詳細に関して必須とすることが可能であり、承認者は選択されたロールについてリスク分析（８１８、以下で説明される）を実行する。リスク分析の必須または任意の内容は、状況に基づいて可変とし、システム１００の実装により固定とし、または、現在のワークフローステージによって規定されるように設定することが可能である。

ステップ８１２への代替または追加の特徴として、ステップ８１２は、承認者にロールの集合を提案し、必須とし、フィルタリングし、または、示唆することが可能である。一例において、ＥＲＰマネージャー１２２は、システム１００を運用する組織のビジネスに関連する一群のユーザ定義された職務領域を認識する。ある例は、Production Ops、Accounting JV、California Development、等とすることが可能である。この例において、要求において要求者が識別する職務領域に基づいて、ステップ８１２は、選択する承認者に依存するよりも、（指定された職務領域に適切な）予め定められたロールの集合をワークフローに組み込むことが可能である。詳細には、ステップ８１２は、職務領域と全ての対応付けられたロールとの間の予め定められたマッピングを調べ、承認者へのロールの提案を、ユーザ要求に関連する職務領域に具体的に対応付けられたロールに制限する。さらに、ステップ８１２は、要求者またはロール選択者によって選択されたロールに加えて、要求に追加することが必要な他のデフォルトロールを識別することが可能である。すなわち、ステップ８１２は、ユーザの要求または承認者の選択に適切なさらなるデフォルトロールの追加を提案するために予め定められたリストを使用する。例えば、承認者がAP Clerkロールの生成を提案したならば、ステップ８１２は追加のロール“ディスプレイ読み出し”および“プリント”が含まれることを提案することが可能である。

ステップ８１６において、エンジン１１６は、対象の要求について決裁する承認者の権限を委任または経路変更する承認者の選択を受信する。例えば、要求を検討する時間がないので承認者が変更を開始するならば手動で、または、承認者が休暇中である場合または他の理由において自動で、動的なワークフローの変更が発生し得る。委任を用いて、承認者が社内の他の人またはロールを指定し、指定された人またはロールに承認者の決定を行わせるための責任を委任する。一例において、ワークフローエンジン１１６は、承認者が休暇中、長期出張中、長期不在、等であるという情報を（承認者または他から）受信すると、ワークフローエンジン１１６は、承認者の決定を他の人に自動的に委任することが可能である。経路変更を用いて、承認者は、入力のために現在の要求を他の人にルーティングし、その後、フローは要求についての決定を完了するために承認者に戻る。これは、現在の要求について最終的な決定を行う前に、承認者が、他の人の経験、見識、または意見を得るために有効であり得る。ワークフローの動的な変更のための他のオプションは、図１Ｃの場面において上述した。

動的なワークフローの変更に入るとき、ワークフローエンジン１１６はこのステージをワークフローに追加し、上述したステップ６１０、６１２と同様に委任を識別および通知することによって継続する。

ステップ８１８において、エンジン１１６はリスク分析を実行する承認者の選択を受信する。一例において、ステップ８１８および続くステップ８２０〜８２４は、Virsa System社のCompliance Calibratorバージョン5.0製品のソフトウェア機能を組み込むことによって実現することが可能である。リスク分析において、エンジン１１６は、職務分離の分析を通して潜在的なコンフリクトまたは監査の例外（audit exception）についてロールを評価することによって、承認者の要求に応答する。言い換えると、ステップ８１８は、要求を満たすことが規制準拠、監査規則、企業ポリシー、または他の規則、法律、または予め定められたガイドラインに違反するかどうか決定するためにユーザ要求を分析する。リスク分析は、ロールのアクセスにおける違反が存在しないことを保証するために実行され、コンフリクトを防止するために事前のアクションを生ぜしめる。リスク分析８１８は、例えば、コンプライアンスおよび監査の開示のために、予期されるロールまたはセキュリティのアクセス許可の集合を検査することを含む。リスク分析は、アクセス要求へのロールの割り当て（８１４）の前または後に、割り当てられたロールが手動で、または、既存のプロファイルについてのモデル化のいずれを通して生成されても（８１２）実行することが可能である。

リスク分析動作８１８の選択的な続きとして、エンジン１１６は、向上した分析８２０、ミティゲーション８２２、およびシミュレーション８２４を提供する。ミティゲーション８２２において、エンジン１１６はリスク開示を取り扱うために、承認者にミティゲーション管理の生成を容易にする。ミティゲーションは、定義されたルールに基づく違反に対処するためのアクションである。ミティゲーション管理は、識別されたリスクまたは予期される監査の例外を取り除きまたは無効にし、それが１つまたは複数のルール１１２に違反してもそれが生じることを許可する。特定の職務分離の違反を選択すると、承認者は、監査証跡を維持管理するためにシステムにおいて捕捉される管理の承認を用いて違反を無効にすることができる。

シミュレーション８２４において、承認者は仮定的な状況を提示し、エンジン１１６は、リスクを有するか決定するためにシナリオを検査する。これは、提示されたロールが職務分離の違反を生成するか否かを識別する処理を含む。職務分離の違反が生成されると、承認者は戻り、１つずつロールを非選択にし（８１２）、その修正されたプロファイルの影響を再シミュレーションする（８２４）ことができる。これは、承認者が、提示されたロールが職務分離の違反を有し続けるか否か、および、どの時点で停止したかを検査することを可能とする。このようにして、承認者は、どの特定のロールまたはロールの組み合わせが職務分離の違反を引き起こすかを識別することもできる。

一実施形態において、リスク分析（８１８）が行われた後、ワークフローエンジン１１６は、承認（８０６）の選択肢を選択する承認者の能力を自動的に制限する。例えば、リスク分析８１８が、軽減されていない職務分離の違反、リスク、または他の露見を明らかにしないならば、ワークフローエンジン１１６は、承認（８０６）のみ許可することが可能である。

＜事前動作＞
図５は、シーケンス６００のための準備において実行される動作のシーケンス５００を表わす。これらの動作５００は、システム１００のインストール、構成、再構成、更新、譲受け、または他の適切な時において実行することが可能である。一例において、動作５００はシステム管理者によって手動で実行され、より詳しくは、これは、セットアップ、修正、更新、アップグレード、または、イニシエーター１０４、ワークフロー１１０、および／または、通知１０８の変更における管理者のアクションを含む。システム管理者の代わりとして、動作５００は、エキスパートシステム、ニューラルネットワーク、または他のソフトウェアプログラムのような自動化されたシステムによって実行することが可能である。しかし、残りの説明において、動作５００はシステム管理者によって実行される。

ステップ５０２において、システム管理者はイニシエーターを定義する。ここで、システム管理者は各種のイニシエーター１０４およびマップ１０４Ａ〜１０４Ｂを設計する。これらの動作は、例えば、リスト、データベース、テーブル、または他の任意の適切なデータ構造、コンピュータアルゴリズム、ハードウェア装置、またはユーティリティを取り込むシステム管理者によって実行することが可能である。

ステップ５０４において、システム管理者はワークフロー５０４を定義する。これは、動作５０２と同様に実行することが可能である。各々のワークフローについて、ステップ５０４はステージの数、ステージ間の関係および経路、分岐／分枝の条件、ステージにおける動的なワークフローの変更（変更しない）の可能性、および、どのロールまたは人が各々のステージについての正しい承認者であるかを定義する。

＜続く動作＞
図７は、ルール１１２の修正に関してワークフローエンジン１１６からの命令（図６の６１８を参照）に応答して実行される動作７００を表わす。特に、命令に応答して、ルール１１２の修正を実現するためにシステム１００のソフトウェア設定を再構成するアクションがとられる。一例において、これらのアクション（７００）は、必要なユーザアカウントを生成または修正し、実行するロールを割り当てる、等を行うシステム管理者によって実行される。SAPリソース１１５の典型的な場合において、ステップ７００は、ロールを生成、削除、または修正し、または承認された要求を充足するために他のアクションを実行するSAPソフトウェアを使用するシステム管理者によって充足されることが可能である。

システム管理者による手動操作の代わりとして、動作７００は、ワークフローエンジン１１６のような自動化されたシステムによって実行される自動プロビジョニングのアクションを含む。これは、承認されたならば、要求されるアクションが実質的にリアルタイムで実行されることを可能とする。一例において、プロビジョニングは、ユーザアカウントの追加を実行するか、または、ロールを要求において記入されたユーザアカウントに割り当てることを含む。例として、動作（７００）を実現することは、指定された人に非ＥＲＰシステム要求を送信し、彼／彼女に手動で要求を実行することを求めることを含む。ステップ７００の実現の一例は、ユーザがリソース１１５の外部に存在するメインフレームシステムにおけるあるデータをアクセスする要求の承認である。もう１つの例は、ＨＲ部門における新たな雇用のために、ある人が新たな従業員のパケットを記入する要求である。

＜＜物理的プロビジョニング＞＞
上述したリソース１１５の一例は、各種の記憶されたデータ、処理、サブルーチン、アプリケーションプログラム、またはマネージャー１２２によるＥＲＰ管理の対象である他のアクションまたはデータを含む。リソース１１５の例は、調達、支払い、取立て、財務報告、および他のビジネスプロセスを自動化するために、SAP、Oracle Financials、PeopleSoft、または他のシステムにおいて使用されるＥＲＰおよび類似の機能によって使用される情報を含むと言える。

異なるまたは追加の実施形態において、リソース１１５は、データ、処理、コンピュータハードウェア、電子機器、装置、または、建造物のセキュリティに関するアクション、または、いわゆる“物理的プロビジョニング”を含むことが可能である。この実施形態において、リソース１１５は、ドアロック、警報システム、アクセスゾーン、コントローラ、ブームゲート、エレベーター、ＨＶＡＣ（暖房、換気、空調）システムおよび構成要素、読み取り器（カード、バイオメトリクス、ＲＦＩＤ（Radio Frequency Identification）等）、能動型ＩＤリーダ（ＰＩＲ）、および、これらの構成要素によって生成されるイベントおよび警報のような、各種の遠隔操作される設備セキュリティ構成要素を含む。また、写真複写機、ＰＯＳシステム、輸送アクセス（チャージ）ポイント、および、スマートカードまたは他の物理的アクセス技術に組み込むことが可能な他のシステムのような他の装置を含むように拡張することが可能である。

物理的プロビジョニングの場面において、タスク１１３は、ドアロックを開け、警報システムを非活動状態にし、物理的領域へのアクセスを許可および無効とする、等の動作を含む。これらのタスクの進行において、ＥＲＰマネージャー１２２は、１１８、１２０のようなインタフェースからの個々のユーザ認証を受信および評価する。ユーザ認証は、キーパッドのパスコード、バイオメトリクス識別（例えば、指紋、虹彩／網膜スキャン）、ユーザ名およびパスワードの提示、磁気ストライプカードの提示、近接カード、スマートカード、ＲＦＩＤの使用、等を利用することが可能である。ＥＲＰマネージャー１２２は、ユーザに代わって要求されたタスク（１１３）を実行するか否かを決定するために（１１２、１１４から）ユーザのロールおよび他の特性のような情報を考慮する。

建造物のセキュリティの態様に関する限り、ＥＲＰマネージャー１２２は、CARDAX、GE、Honywell、または他の商業的に入手可能な製品のような技術を利用することが可能である。上述したようにルール１１２と同様に、物理的プロビジョニングについてのルールは、職務分離の違反を防止するように設計される。例えば、同一の人が、接続された設備において空港の滑走路へのアクセスだけでなく、薬品貯蔵エリア（例えば硝酸アンモニウム）の両方へのアクセスを有する場合にリスクを有し得る。物理的態様の追加とともに、ＥＲＰマネージャー１２２は、同時に物理的および論理的な全景にわたって職務分離の違反を防止するように設計されたルールを実現することも可能である。例えば、ある人が在庫貯蔵エリアへのアクセスを有し、同時に、ＥＲＰシステムにおいて在庫償却の実行を可能とするロールに属する場合にリスクを有し得る。また、物理的態様は、長過ぎる１つの継続した時間間隔について、ある場所に物理的に存在しているか否か、または、ある人が物理的な訪問の間に作業場所から離れる十分な時間がなかったかどうか、または、ある人が例えば有毒または放射性の物質へのある規制露出限界をどこで超えたか、について、ルール１１２を参照することを可能とするためにＥＲＰマネージャー１２２にデータを送出する。

これらの例において、ワークフローエンジン１１６は上述した説明と同様に動作する。すなわち、エンジン１１６は、マネージャー１１２が建造物のセキュリティを管理するルール１１２を変更するユーザの要求の処理において助けるために構成要素１０２を利用する。例えば、ユーザの要求は、ルール１１２がアクセスを許可しない部屋または建造物へのアクセスを求めることが可能である。また、ユーザ要求は、ＥＲＰマネージャー１２２によって管理される建造物のセキュリティ機能へのアクセスを削除、拡張、変更または修正することを求めることが可能である。

＜他の実施形態＞
上記の開示は多数の説明的な実施形態を示したが、この技術分野の当業者には、特許請求の範囲によって定義される本発明の範囲を逸脱せずに、様々な変更および修正を行うことができることは明らかである。従って、開示された実施形態は、本発明によって幅広く意図する要旨の代表例であり、本発明の範囲は、この技術分野の当業者に明らかとなり得る他の実施形態を全て包含し、従って、本発明の範囲は特許請求の範囲以外によっては限定されない。

既知の、または、この技術分野の当業者に後に周知となる上述した実施形態の構成要素の全ての構造的および機能的な均等物は、引用してここに明示的に組み込まれ、本願の特許請求の範囲に包含されることを意図する。さらに、装置または方法が、本発明によって解決することが求められる各々のおよび全ての課題に取り組む必要はなく、それは本願の特許請求の範囲に含まれる。さらに、この開示におけるいずれの構成要素、または方法のステップも、その構成要素、または方法のステップが特許請求に明示的に記載されているか否かに関係なく、公に提供することを意図する。ここでのいずれの請求項の構成要素も、構成要素が“のための手段（means for）”または方法の請求項の場合においては“のためのステップ（step for）”という語句を使用して明示的に記載されているのでなければ、米国特許法第１１２条第６段落に該当するとはみなされない。

さらに、本発明の構成要素は、単独で説明または特許請求することが可能であるが、単独での構成要素への言及は、明示的にそのように記載されていないならば、“１つ、かつ、ただ１つ”を意味することを意図せず、“１つまたは複数”を意味する。さらに、この技術分野の当業者は、動作シーケンスは、説明および特許請求の目的のためにある特定の順序で記載しなければならないが、本発明はそのような特定の順序以外に各種の変更を意図すると認識する。

さらに、関連する技術分野の当業者は、情報および信号は、各種の異なる技術を使用して表わすことが可能であることを理解する。例えば、ここで言及されるデータ、命令、コマンド、情報、信号、ビット、符号、および、チップは、電圧、電流、電磁波、磁界または磁性粒子、オプティカルフィールドまたは光学粒子、他の単位体、または上記の組み合わせによって表わされることが可能である。

さらに、この技術分野の当業者は、ここで説明される説明的な論理的ブロック、モジュール、回路、および処理ステップは、電子的ハードウェア、コンピュータソフトウェア、または両者の組み合わせとして実現することが可能であることを理解する。ハードウェアおよびソフトウェアのこの互換性を明瞭に説明するために、各種の説明的な構成要素、ブロック、モジュール、回路、およびステップが、大部分はそれらの機能に関して上記で説明された。そのような機能がハードウェアまたはソフトウェアのいずれとして実現されるかは、全体のシステムに課される特定の応用および設計の制限に依存する。この技術分野の当業者は、各々の特定の応用のために様々な形態で、説明した機能を実現することが可能であるが、そのような実現の決定は本発明の範囲から逸脱させるものとして解釈されるべきではない。

開示された実施形態の上記説明は、この技術分野の当業者が本発明を生産および使用することを可能とするように提供される。これらの実施形態への各種の修正は、この技術分野の当業者に容易に明らかであり、ここで定義された汎用の原理は本発明の思想および範囲を逸脱することなく他の実施形態に適用することが可能である。従って、本発明はここで表わされた実施形態に限定することを意図せず、ここで開示された原理および新規な特徴と一致した最も広い範囲が与えられるべきである。

複数ユーザが共有するリソースコンピューティングシステムのハードウェア構成要素および相互接続のブロック図である。 いくつかの典型的なワークフローのブロック図である。 いくつかの動作中のワークフロー変更のブロック図である。 デジタルデータ処理装置のブロック図である。 典型的な信号搬送媒体を表わす。 典型的なロジック回路の斜視図である。 図６の典型的な事前動作のフローチャートである。 共有されたコンピューティングリソースにおいて実行されるユーザの作業を規制するソフトウェアルールの再定義を管理する典型的な動作のフローチャートである。 図６に続いて行う典型的な動作のフローチャートである。 続いて起こる典型的な承認者のフローチャートである。 いくつかの典型的な場面の画面を表わす。 いくつかの典型的な場面の画面を表わす。 いくつかの典型的な場面の画面を表わす。

符号の説明

１００ システム
１０２、１０３ 記憶装置
１０４ イニシエーター
１０８ 通知
１１０ ワークフロー
１１２ ルール
１１３ タスク
１１４ 人員データベース
１１５ リソース
１１６ ワークフローエンジン
１１８ ユーザインタフェース（承認者）
１２０ ユーザインタフェース（要求者）
１２２ ＥＲＰマネージャー

Claims (30)

1. コンピュータ駆動のリソースマネージャーがユーザ起動のタスクについてのユーザのアクセス許可を定義する確立されたルールに従って前記タスクを選択的に実行するシステムにおいて、前記ルールの再定義を管理する方法であって、
   コンピュータ駆動のワークフローエンジンが前記ルールを変更する要求を受信する過程を有し、前記要求は要求者によって記入された予め定められた電子的書式の送信を含み、
   前記要求の受信に応答して、前記ワークフローエンジンが、
   前記記入された電子的書式内のデータを検査し、複数の予め定められた承認経路のうち対応する１つを選択する過程と、
   前記選択された承認経路によって規定された順序で、
   前記選択された承認経路によって定義される一連の１つまたは複数のステージを通して順次進み、各ステージにおいて、前記選択された承認経路によって示される１または複数の承認者からの承認を電子的に要請し、
   少なくとも１つの拒否、または、前記選択された承認経路によって必要とされる全ての承認、のうち一方を含む完了イベントを受信するまで、前記ステージを通して継続する過程と、
   前記選択された承認経路によって必要とされる全ての承認の受信に応答して、前記要求に従って前記ルールの修正を指示する電子的メッセージを送信する過程と、
   を有する動作を実行することによって前記要求を処理する過程をさらに有する方法。
2. 各々の完了イベントの電子的通知を前記要求者に送信する過程をさらに有する請求項１に記載の方法。
3. 前記ルールの修正を指示する電子的メッセージの受信に応答して、前記ルールの修正を実現するために、人間のシステム管理者が、前記リソースマネージャーのソフトウェア設定を再構成する過程をさらに有する請求項１に記載の方法。
4. コンピュータ駆動の装置が、前記ルールの修正を指示する電子的メッセージを受信し、それに応答して、前記ルールの修正を実現するために、前記リソースマネージャーのソフトウェア設定を再構成する過程をさらに有する請求項１に記載の方法。
5. イニシエーターの集合を確定する過程をさらに有し、前記イニシエーターは、前記予め定められた電子的書式のそれぞれ異なる可能性のある記入を含み、前記イニシエーターと前記予め定められた承認経路との間の関係を定義し、
   前記要求内のデータを検査し、複数の予め定められた承認経路のうち対応する１つを選択する動作は、
   対応するイニシエーターを識別するために前記記入された電子的書式内のデータを検査する過程と、
   どの予め定められた承認経路が前記識別されたイニシエーターと対応付けられているかを決定する過程と、
   前記対応付けられた承認経路を選択する過程と、
   を有する請求項１に記載の方法。
6. 人間のシステム管理者が、前記予め定められた承認経路を定義し、コンピュータ駆動の装置に前記予め定められた承認経路の装置読み取り可能な記録を作成するように指示する過程をさらに有し、
   前記記録は前記ワークフローエンジンによってアクセス可能である請求項１に記載の方法。
7. 前記予め定められた承認経路には、並列経路、条件分岐が存在する請求項１に記載の方法。
8. 前記予め定められた承認経路には、承認者からの入力に条件的に基づくルーティング、前記要求の内部情報に基づくルーティング、前記要求の特性に関する前記要求の外部情報に基づくルーティング、承認者の指示において実行された分析の結果に基づくルーティング、承認者の指名した人による入力に基づくルーティングが存在する請求項１に記載の方法。
9. 予め定められた承認経路によって示される各々の承認者は、人、現在その職種に従事する人を識別する外部情報を必要とする職種、のうち一方を含む請求項１に記載の方法。
10. 前記ワークフローエンジンに応答して、前記選択された承認経路を動的に変更するために、前記選択された承認経路によって示される承認者の１または複数から指示を受信し、前記動的な変更を実現する過程をさらに有する請求項１に記載の方法。
11. 前記ステージの１つまたは複数において、前記選択された承認経路を動的に変更するために、前記選択された承認経路によって示される承認者の指示を受信および実行する過程をさらに有し、
    前記指示は、承認を側線に入れる、報告が戻されるように委任する、承認を経路変更することを含む請求項１に記載の方法。
12. 前記ステージの１つまたは複数において追加の動作をさらに含み、
    該動作は、リスク分析のオプションの承認者の選択に応答して、その実行が職務分離、規制準拠、または監査規則に関する予め定められたガイドラインに違反するかどうか決定するために、コンピュータ駆動の装置が、前記要求者から受信し、または、前記承認者によって修正または提案された要求を分析する過程を有する請求項１に記載の方法。
13. 前記ステージの１つまたは複数において前記ワークフローエンジンが動作を実行する過程をさらに有し、
    該動作は、前記選択された承認経路によって示される１または複数の承認者が、前記要求者から受信し、または、前記承認者によって修正または提案された要求を実行することが、職務分離、規制準拠、または監査規則に関する予め定められたガイドラインに違反するかどうか決定するために、コンピュータ駆動の分析を起動することを要求する過程を有する請求項１に記載の方法。
14. 前記ステージの１つまたは複数において追加の動作をさらに含み、
    該動作は、前記要求者から受信し、または、前記承認者によって修正または提案された要求の実行が、職務分離、規制準拠、または監査規則に関する予め定められたガイドラインに違反するかどうか決定するために、コンピュータ駆動の装置が、該要求を分析する過程と、
    違反に応答して、分析された前記要求によるルールの修正を阻止する過程と、
    を有する請求項１に記載の方法。
15. 前記ステージの１つまたは複数において前記ワークフローエンジンが動作を実行する過程をさらに有し、
    該動作は、前記選択された承認経路によって示される１または複数の承認者が、コンピュータ駆動の処理である、予め定められたロールの割り当て、予め定められたロールの削除、新たなロールの定義および割り当て、のうち少なくとも１つを起動することを要求する過程を有する請求項１に記載の方法。
16. 前記要求に適切なルール変更を識別し、前記識別されたルール変更を前記選択された承認経路によって示される１または複数の承認者に提案するコンピュータ駆動の動作、
    前記要求に適切なルール変更を識別し、不適切なルール変更を除外するために前記選択された承認経路によって示される１または複数の承認者の潜在的なルール変更をフィルタリングするコンピュータ駆動の動作、
    のうち少なくとも１つをさらに含む請求項１に記載の方法。
17. 前記選択された承認経路によって示される承認者または前記要求による１つまたは複数の予め定められたロールの指定に応答して、１つまたは複数の追加のロールの割り当てを識別および提案するコンピュータ駆動の動作、
    のうち少なくとも１つをさらに含む請求項１に記載の方法。
18. 前記ステージの１つまたは複数において、前記ワークフローエンジンが、前記選択された承認経路によって示される承認者に、前記要求者から受信し、または、前記承認者によって修正または提案された要求の目的とされる特性を軽減する基準を作成することを含むコンピュータ駆動のミティゲーション処理を利用可能とする過程をさらに有し、
    前記目的とされる特性は、職務分離、規制準拠、または監査規則に関する予め定められたガイドラインに違反するリスクを表わす請求項１に記載の方法。
19. 前記ルールを変更する要求は、
    ユーザ記入された電子的書式の送信を含む前記ルールを変更するユーザ起動の要求、
    前記電子的書式の装置生成を含む前記ルールを変更する装置起動の要求、
    のうち１つを含む請求項１に記載の方法。
20. 前記ルールは、設備への物理的アクセスに関するユーザ起動のタスクについてのユーザのアクセス許可を定義する請求項１に記載の方法。
21. 前記ルールは、設備である、ドアロック、警報システム、アクセスゾーン、コントローラ、ブームゲート、エレベーター、ＨＶＡＣ（暖房、換気、空調）構成要素、識別情報読み取り器、磁気カード読み取り器、無線周波数識別システム、および物理的アクセス技術の動作を含むユーザ起動のタスクについてのユーザのアクセス許可を定義する請求項１に記載の方法。
22. 前記ルールは、ドアロックを開けること、警報システムを非活動状態にすること、および物理的領域へのアクセスを許可および無効とすることを含むユーザ起動のタスクについてのユーザのアクセス許可を定義する請求項１に記載の方法。
23. コンピュータ駆動のリソースマネージャーがユーザ起動のタスクについてのユーザのアクセス許可を定義する確立されたルールに従って前記タスクを選択的に実行するシステムにおいて適用される、動作を実行するためにデジタル処理装置によって実行可能な装置読み取り可能な命令のプログラムを有形に包含する１つまたは複数のコンピュータ読み取り可能な記憶媒体であって、前記動作は前記ルールの再定義を管理し、
    前記動作は、
    コンピュータ駆動のワークフローエンジンが前記ルールを変更する要求を受信するステップを含み、前記要求は要求者によって記入された予め定められた電子的書式の送信を含み、
    前記要求の受信に応答して、前記ワークフローエンジンが、
    前記記入された電子的書式内のデータを検査し、複数の予め定められた承認経路のうち対応する１つを選択するステップと、
    前記選択された承認経路によって規定された順序で、
    前記選択された承認経路によって定義される一連の１つまたは複数のステージを通して順次進み、各ステージにおいて、前記選択された承認経路によって示される１または複数の承認者からの承認を電子的に要請し、
    少なくとも１つの拒否、または、前記選択された承認経路によって必要とされる全ての承認、のうち一方を含む完了イベントを受信するまで、前記ステージを通して継続するステップと、
    前記選択された承認経路によって必要とされる全ての承認の受信に応答して、前記要求に従って前記ルールの修正を指示する電子的メッセージを送信するステップと、
    を含む動作を実行することによって前記要求を処理するステップをさらに含む記憶媒体。
24. コンピュータ駆動のリソースマネージャーがユーザ起動のタスクについてのユーザのアクセス許可を定義する確立されたルールに従って前記タスクを選択的に実行するシステムにおいて適用される、動作を実行するためにデジタルデータ処理装置によって実行可能な装置読み取り可能な命令の第２プログラムをインストールするために、デジタル処理装置によって実行可能な装置読み取り可能な命令の第１プログラムを有形に包含する１つまたは複数のコンピュータ読み取り可能な記憶媒体であって、前記動作は前記ルールの再定義を管理し、
    前記動作は、
    コンピュータ駆動のワークフローエンジンが前記ルールを変更する要求を受信するステップを含み、前記要求は要求者によって記入された予め定められた電子的書式の送信を含み、
    前記要求の受信に応答して、前記ワークフローエンジンが、
    前記記入された電子的書式内のデータを検査し、複数の予め定められた承認経路のうち対応する１つを選択するステップと、
    前記選択された承認経路によって規定された順序で、
    前記選択された承認経路によって定義される一連の１つまたは複数のステージを通して順次進み、各ステージにおいて、前記選択された承認経路によって示される１または複数の承認者からの承認を電子的に要請し、
    少なくとも１つの拒否、または、前記選択された承認経路によって必要とされる全ての承認、のうち一方を含む完了イベントを受信するまで、前記ステージを通して継続するステップと、
    前記選択された承認経路によって必要とされる全ての承認の受信に応答して、前記要求に従って前記ルールの修正を指示する電子的メッセージを送信するステップと、
    を含む動作を実行することによって前記要求を処理するステップをさらに含む記憶媒体。
25. コンピュータ駆動のＥＲＰオーソリティーがユーザ起動のタスクを起動するためにユーザのアクセス許可を定義する確立されたルールに従って前記タスクを選択的に実行するシステムにおいて適用される、動作を実行するためにデジタル処理装置によって実行可能な装置読み取り可能な命令のプログラムを有形に包含する１つまたは複数のコンピュータ読み取り可能な記憶媒体であって、
    前記動作は、
    予め定められたワークフローのリストを記憶するステップを含み、各ワークフローは、１つまたは複数の既存のロールを変更し、または、１つまたは複数の新たなロールを追加する与えられたユーザ要求を処理するための必須のアクションの進行を定義し、前記進行は前記ワークフローにおいて指定された１または複数の承認者によって実行されるアクションを含む規定された順序のアクションを含み、前記アクションは、ユーザ要求されたロールの変更または追加の承認、ユーザ要求されたロールの変更または追加の修正、前記ユーザ要求に適合するロールの指定を含むグループから選択され、
    前記ロールを変更するための可能性のあるユーザ要求の特性の各種の予め定められた集合に前記ワークフローを関係付ける１つまたは複数のマップを記憶するステップと、
    ロールを変更するユーザ要求に応答して、対応するワークフローを識別するために前記ユーザ要求に前記マップを適用し、その後、前記規定された順序で、前記識別されたワークフローの指定された承認者によって前記アクションの実行の通知および達成に進み、前記識別されたワークフローの成功した完了においてのみ、前記ユーザ要求において記入され、または、前記承認者によって修正または起動されたロールへの変更の実現を前記承認者によって許可するステップと、
    をさらに含む記憶媒体。
26. 前記必須のアクションは、前記ロールにおける提案された変更が、職務分離、規制準拠、または監査規則に関する予め定められたガイドラインに違反するか否か決定するために、承認者の１または複数がリスク分析を実行するステップをさらに含む請求項２５に記載の記憶媒体。
27. 前記ワークフローの１つまたは複数は、複数のステージおよび代替の経路を含み、１つの代替の経路または他の代替の経路は、より早いステージからの結果に従って自動的に決定される請求項２５に記載の記憶媒体。
28. 前記アクションのグループは、
    所定の承認者が、特定の作業について前記順序を他へ経路変更し、前記特定の作業の完了の後、前記所定の承認者に戻すステップと、
    所定の承認者が、決裁することを拒み、その代わりに他の承認者が代わりをするステップと、
    を含む前記ワークフローへの動的な変更をさらに含む請求項２５に記載の記憶媒体。
29. コンピュータ駆動のリソースマネージャーがユーザ起動のタスクについてのユーザのアクセス許可を定義する確立されたルールに従って前記タスクを選択的に実行するシステムにおける、前記ルールの再定義を管理するための装置であって、
    複数の予め定められた承認経路の集合と、
    要求者によって記入された予め定められた電子的書式の送信を含む、前記ルールを変更する要求の受信に応答して、
    前記記入された電子的書式内のデータを検査し、複数の予め定められた承認経路のうち対応する１つを選択するステップと、
    前記選択された承認経路によって規定された順序で、
    前記選択された承認経路によって定義される一連の１つまたは複数のステージを通して順次進み、各ステージにおいて、前記選択された承認経路によって示される１または複数の承認者からの承認を電子的に要請し、
    少なくとも１つの拒否、または、前記選択された承認経路によって必要とされる全ての承認、のうち一方を含む完了イベントを受信するまで、前記ステージを通して継続するステップと、
    前記選択された承認経路によって必要とされる全ての承認の受信に応答して、前記要求に従って前記ルールの修正を指示する電子的メッセージを送信するステップと、
    を含む動作を実行することによって前記要求を処理するステップを含む動作を実行するようにプログラムされたコンピュータ駆動のワークフローエンジンと、
    を備える装置。
30. コンピュータ駆動のリソースマネージャーがユーザ起動のタスクについてのユーザのアクセス許可を定義する確立されたルールに従って前記タスクを選択的に実行するシステムにおける、前記ルールの再定義を管理するための装置であって、
    複数の予め定められた承認経路の集合と、
    要求者によって記入された予め定められた電子的書式の送信を含む、前記ルールを変更する要求の受信に応答して、
    前記記入された電子的書式内のデータを検査し、複数の予め定められた承認経路のうち対応する１つを選択するステップと、
    前記選択された承認経路によって規定された順序で、
    前記選択された承認経路によって定義される一連の１つまたは複数のステージを通して順次進み、各ステージにおいて、前記選択された承認経路によって示される１または複数の承認者からの承認を電子的に要請し、
    少なくとも１つの拒否、または、前記選択された承認経路によって必要とされる全ての承認、のうち一方を含む完了イベントを受信するまで、前記ステージを通して継続するステップと、
    前記選択された承認経路によって必要とされる全ての承認の受信に応答して、前記要求に従って前記ルールの修正を指示する電子的メッセージを送信するステップと、
    を含む動作を実行することによって前記要求を処理するステップを含む動作を実行するためのワークフローエンジン手段と、
    を備える装置。

Images