Oracle Internal Controls Managerインプリメンテーション・ガイド リリース11i B25733-01 | ![]() 目次 | ![]() 戻る | ![]() 次へ |
Oracle Internal Controls Managerの「懸案管理」には、次のエンティティが含まれます。
「調査結果」。監査プロセス中には、確立された標準に対する非遵守が組織でしばしば検出されます。この種の非遵守は「調査結果」として識別され、通常は会計慣行やアカウンタビリティなどに違反する重大な懸案項目です。調査結果に有効に対処して改善する必要があります。
「懸案」。「調査結果」に似ていますが、プロセスの認証中に開始されます。
「改善」。「改善」は、問題領域を改善するための計画および処理であり、「調査結果」と「懸案」のクローズに使用されます。
「修正要求」。職務分掌違反が検出された場合は、違反を修正するために正式な修正要求を開始できます。この要求を特定のユーザーに割り当ててアプリケーションで追跡できます。
「開示委員会」。監査委員会のニーズを管理するために構造化されたフレームワークを提供します。
この章では、Oracle Internal Controls Managerを使用して、前述のエンティティを設定して作成するために必要なすべての情報について説明します。
注意: 「調査結果」エンティティの設定と実装については詳細に説明します。その他のエンティティの設定は、「調査結果」に関して説明した内容と同様です。
調査結果には、内部監査および保証システムの様々な側面に発生する非遵守情報が含まれます。これらの非遵守は、監査プロジェクトやランダムな観察では扱われません。プロセス・オーナーまたは監査人は識別された調査結果をシステムに記録し、他の担当に割り当てることもできます。調査結果を記録して追跡する機能は、認証や監査所見に重大な影響を及ぼしかねない情報を取得する上で不可欠です。
このデータは、以降のプロセスの作業や監査計画活動にも不可欠です。矛盾や改善の機会が検出された場合は、修正および改善を加える必要があります。したがって、監査プロセスを組織全体の改善のきっかけとして使用でき、修正処理の実施と有効性を検証するためにフォローアップ監査を実行します。
Oracle Internal Controls Managerには、調査結果の記録と解決に役立つ豊富な機能セットが用意されています。
調査結果を個々のユーザーに割り当てたり割当てを変更できます。また、事前定義済のルーティング・テンプレートに基づいて、調査結果をフォローアップのためにエスカレートすることもできます。
調査結果フレームワークには豊富なシード済属性セットが用意されており、調査結果の記録時に入力できます。また、管理者は新規属性を定義して、その他の情報を取得することもできます。
スレッド化された議論機能を使用すると、監査人とサポート・スタッフが調査結果に対して共同作業を実施できます。
改善(問題領域を改善するための計画および処理)を作成してから、調査結果にリンクできます。目標は、監査人およびプロセス・オーナーが調査結果をクローズして認証を勧告できるように、発生する問題に対処することです。監査人は、クローズするかわりに認証を「懸案ありで認証済」として発行することもできます。
注意: 改善の詳細は、「調査結果クローズ時の改善の使用」を参照してください。
調査結果と改善のメリット
調査結果は、プロセスと財務諸表を認証する前に解決する必要のある重要な疑問点を見いだす上で役立ちます。
調査結果と改善は、監査の終了時に発行される監査レポートの一部となります。
調査結果と改善は、会社の監査委員会、経営者およびその他の利害関係者に対する情報伝達の基礎となります。
監査プロジェクトからの調査結果により、すべての関係者に問題領域が伝達されます。
改善処理により、問題領域が解決されます。
調査結果は、組織、プロセス、リスク、統制、監査手順および監査プロジェクトの評価中に記録されます。これらの領域における業務の様々な側面を調査結果に取り込むことができます。
Oracle Internal Controls Managerでは、作成可能な各種の調査結果が調査結果タイプを使用して区別されます。このモジュールには次のシード済タイプが用意されており、「調査結果タイプ」ハイパーリンクをクリックするとリストを表示できます(「調査結果の設定」->「基本情報の定義」を参照)。
調査結果タイプ名 | 説明 |
---|---|
ProjAP | 監査手順調査結果 |
ProjCtrl | 統制調査結果 |
ProjOrg | 組織調査結果 |
ProjProc | プロセス調査結果 |
ProjRisk | リスク調査結果 |
ProjStep | 監査手順ステップ |
プロジェクト | プロジェクト調査結果 |
調査結果を作成すると、作成時のコンテキストに基づいて自動的に前述のいずれかのタイプとして記録されます。
注意: 調査結果タイプはOracle Internal Controls Managerで事前シード済です。他のタイプの調査結果は認識されません。
次に社内の調査結果の例を示します。
組織調査結果: 組織体系では、監査のための情報と面接を容易に取得することはできません。
プロセス調査結果: 「調達-支払」プロセスには、購入決定権限が従業員以外に付与されているという未確認のリスクが存在します。
リスク調査結果: 盗難というリスクは、物理的なセキュリティ不足が原因で複数のプロセスに影響します。
統制調査結果: 購入権限を持つマネージャの統制が一部の購入時に軽視されたり、この統制の有効性に対する適正な監査チェックが存在しない可能性があります。
調査結果タイプにより、調査結果に関連する複数のパラメータが導出されます。調査結果タイプにドリルインして次の情報を設定します。
デフォルト割当先情報
承認経路
属性グループ
以降の各項では、Oracle Internal Controls Managerでの調査結果の実装について説明します。
調査結果の設定
調査結果の記録
調査結果の問合せおよび表示
調査結果クローズ時の改善の使用
Oracle Internal Controls Managerで調査結果を作成および使用するためには、この項の説明に従って調査結果を設定する必要があります。特定の調査結果タイプに対してこれらの設定を行うと、そのタイプに関連付けられたすべての調査結果でその設定が表示されることに注意してください。調査結果タイプごとに次の項目を定義します。
基本情報
属性と値セット
調査結果優先度および理由
承認経路テンプレート
構成
ここに示すステップはすべてオプションであり、これらの機能を使用しない調査結果も作成できます。
調査結果タイプに関連付けられたすべての調査結果で、この情報がデフォルトとして使用されます。基本情報には、その調査結果で有効な日付および採番や、デフォルトの「割当先」情報が含まれます。
トピック | ナビゲータ・パス |
---|---|
調査結果タイプの基本情報の定義 | 「内部監査人」(またはそれに相当する)職責を使用して「設定」タブをクリックし、「懸案管理」サブタブをクリックします。 「カテゴリおよびタイプ」ハイパーリンクを選択します。 「カテゴリ:調査結果」で「タイプ」をクリックして適切な調査結果タイプにドリルインし、「基本情報」ハイパーリンクをクリックします。必要に応じてこの情報を更新します。 |
「自動採番」が「生成済順序」に設定されている場合は、適切なプリフィクスを指定できます。
Oracle Internal Controls Managerでは、様々な属性(ディメンション)を作成して異なる調査結果タイプに添付できます。属性値は「値セット」でシードできます。これは強力な機能であり、タイプに基づいて調査結果にユーザー定義要素を追加できます。
次のような例を考えてみます。いずれも特定のコンテキストにおける調査結果の作成に関連しています。
リスク・コンテキストで調査結果を作成する場合は、事前定義レベルで「エクスポージャ」属性を追加できます。
監査手順のコンテキストで調査結果を作成する場合は、事前定義レベルで「実行の容易さ」属性も設定できます。また、開始者がこのディメンションに関する自由形式のテキストを入力できるように、テキスト・ボックスを提供することもできます。
プロジェクトのコンテキストで調査結果を作成する場合は、値「Yes」または「No」を使用する「連邦」属性を追加できます。
属性を定義して調査結果タイプに添付するには、次の4つのタスクを実行する必要があります。
a. 値セットと値の定義
b. 属性グループと属性の定義、属性への値セットの関連付け
c. 調査結果タイプへの属性グループの関連付け
d. 属性グループ表示ページの定義
a. 値セットと値の定義
トピック | ナビゲータ・パス |
---|---|
値セットの定義 | 「内部監査人」(またはそれに相当する)職責を使用して「設定」タブをクリックし、「値セット」サブタブをクリックします。 値セットの保守ウィンドウで「作成」ボタンをクリックします。このウィンドウで適切な値も定義できます。 |
b. 属性グループと属性の定義、属性への値セットの関連付け
トピック | ナビゲータ・パス |
---|---|
属性グループの定義 属性の定義 | 「内部監査人」(またはそれに相当する)職責を使用して「設定」タブをクリックし、「懸案管理」サブタブをクリックします。 「属性」ハイパーリンクを選択します。 「検索: 属性グループ」ウィンドウで「作成」ボタンをクリックします。 属性グループの作成後に、「属性の追加」ボタンをクリックします。作成した各属性を、ステップaで定義した値セットにリンクできます。 |
次の表に、属性グループの作成ページの各選択フィールドの詳細を示します。
名前 | 説明 |
---|---|
複数行 | 属性グループは複数行または単一行に設定できます。複数行の属性グループでは、同じオブジェクト・インスタンスに複数の属性値セットを関連付けることができます。 たとえば、エクスポージャが複数行属性の場合、調査結果でこの属性に複数のエクスポージャ・レベルを関連付けることができます。単一行の属性グループについては、属性ごとに1つの値のみを入力できます。 |
c. 調査結果タイプへの属性グループの関連付け
トピック | ナビゲータ・パス |
---|---|
調査結果タイプへの属性グループの関連付け | 「内部監査人」(またはそれに相当する)職責を使用して「設定」タブをクリックし、「懸案管理」サブタブをクリックします。 「カテゴリおよびタイプ」ハイパーリンクを選択します。 「カテゴリ:調査結果」で「タイプ」をクリックして適切な調査結果タイプにドリルインし、「属性グループ」ハイパーリンクをクリックします。最後に「属性グループの追加」ボタンをクリックして関連付けます。 |
d. 属性グループ表示ページの定義
トピック | ナビゲータ・パス |
---|---|
調査結果タイプ詳細 | 上記のcで説明したように適切な調査結果タイプにドリルインし、「ページ」ハイパーリンクをクリックします。 最後に、「ページの作成」ハイパーリンクをクリックし、「別の行の追加」ボタンをクリックして1つ以上の属性グループをページに関連付けます。 |
注意: 属性を作成して調査結果に添付するには、最初はOracle Product Lifecycle Managementモジュールで作成された機能を使用します。
値セット、属性グループおよび属性の作成の詳細は、『Oracle Advanced Product Catalog Implementation Guide』の次の項を参照してください。
第4章「変更管理の管理」
第7章「属性および機能の管理」
調査結果に事前定義した優先度および理由を関連付け、調査結果のシード値を作成または更新できます。後で調査結果を作成する際に、これらの事前定義済値の1つに関連付けるように選択できます。
トピック | ナビゲータ・パス |
---|---|
調査結果優先度 | 「内部監査人」(またはそれに相当する)職責を使用して「設定」タブをクリックし、「懸案管理」サブタブをクリックします。 「優先度」または「理由」ハイパーリンクをクリックして、調査結果に関連付けることのできる優先度または理由値を作成します。 「懸案管理」サブタブで「カテゴリおよびタイプ」ハイパーリンクを選択します。 「カテゴリ:調査結果」で「タイプ」をクリックして適切な調査結果タイプにドリルインし、「コード」を選択して、その調査結果タイプに使用する優先度または理由のサブセットを作成します。システムに調査結果を入力する際に、このサブセット内の優先度または理由に関連付けることができます。 |
事前定義済の経路に基づき、フォローアップまたは承認(あるいはその両方)のため、調査結果をエスカレートすることができます。たとえば、監査手順のコンテキストで記録される調査結果を詳細調査のために特定の担当に割り当てることができる一方で、監査リスクについて記録される調査結果ではまったく異なる承認階層を使用できます。
Oracle Internal Controls Managerでは、承認経路テンプレートを作成し、1つの調査結果タイプに1つ以上のテンプレートを関連付けることができます。テンプレートにより調査結果の経路が指定されます。これにより、ワークフロー・プロセス全体が自動化されます。
承認経路を実装するには、次の2つのステップを実行します。
a. 承認テンプレートの作成
トピック | ナビゲータ・パス |
---|---|
承認経路テンプレートの設定 | 「内部監査人」(またはそれに相当する)職責を使用して「設定」タブの「承認」サブタブにナビゲートします。 「承認テンプレート」ハイパーリンクをクリックし、「作成」ボタンをクリックします。 |
このウィンドウで、テンプレートのタイプを次のように選択します。
承認: 「承認」ワークフロー・テンプレート・タイプは、ステータス・タイプが「承認」であるライフ・サイクル内のワークフローのみで有効です。
定義: 「定義」ワークフロー・テンプレート・タイプは、ステータス・タイプが「オープン」であるライフ・サイクル内のワークフローに主に使用されます。
定義と承認: 「定義と承認」ワークフロー・テンプレート・タイプは、ステータス・タイプが「承認」であるライフ・サイクル内のワークフロー内で主に使用されます。
一般: 「一般」ワークフロー・テンプレート・タイプは、他のすべてのライフ・サイクル・ステータス・タイプに使用されます。
注意: これらのテンプレートは下記のb.で説明するようにライフ・サイクル・ステータスで使用されます。ライフ・サイクル・ステータスの詳細は、「ライフ・サイクル・ステータスの追跡」を参照してください。
次に、要件に基づいて次の承認ステップを1つ以上追加します。各ステップに次のパラメータが必要です。
ワークフロー・プロセス: 「承認の要求」、「要求注釈」、「FYI」。
「担当者」: テンプレート設定に基づく割当て(「導出」)または「ユーザー入力」。
「応答必須」: 「すべて」を承認するかまたは「1つ」を承認するかのいずれか。また、「必須担当者」オプションを選択する場合は、担当者が必須かオプションかを指定する必要があります。「FYI」プロセスの担当者からの応答は必要ありません。
応答日数: 応答が必要な日数(このステップが実行されてからの日数)を入力します。
最後に、「担当者」(調査結果の受取人)を選択します。アプリケーションでは「グループ」、「担当」または「ロール」を選択できます。受取人が「ユーザー入力」の場合は「担当者」を選択する必要はありません。
b.調査結果タイプ内のライフ・サイクル・ステータスへの承認テンプレートの関連付け
「懸案管理」内のライフ・サイクルは、該当するエンティティに対する一連のステータスとみなすことができます。
注意: ライフ・サイクル・ステータスの詳細は、「ライフ・サイクル・ステータスの追跡」を参照してください。
テンプレートを使用する前に、調査結果タイプ内のライフ・サイクル・ステータスに関連付ける必要があります。
トピック | ナビゲータ・パス |
---|---|
調査結果タイプへの承認テンプレートの関連付け(およびライフ・サイクルの設定と完了) | 「内部監査人」(またはそれに相当する)職責を使用して「設定」タブをクリックし、「懸案管理」サブタブをクリックします。 「カテゴリおよびタイプ」ハイパーリンクを選択します。 「カテゴリ:調査結果」で「タイプ」をクリックして適切な調査結果タイプにドリルインし、「ワークフロー」ハイパーリンクをクリックします。 |
シードされた「オープン」ステータスと「完了」ステータスの間に「承認」ステータス(または他の必要なステータス)を追加します。
その後、各ステータスのプロパティを次のように更新します。
ワークフロー・ステップの「昇格・昇進」および「降格」に対して有効なステータスを選択します。特定のステータスである必須の担当者および承認が調査結果によってすべて渡された後、次の調査結果に進むことができます。
ステータスを上記の(a)で設定したテンプレートに関連付けます。ステータス内で、このテンプレートに従って調査結果の経路が指定されます。「承認」タイプのワークフロー・テンプレートは、それ自体のステータス・タイプが「承認」であるライフ・サイクル・ステータスのみにリンクできることに注意してください。
懸案管理設定における構成とは、調査結果の要約に表示されるセクションおよび主要属性を指します。
トピック | ナビゲータ・パス |
---|---|
調査結果タイプの表示構成の定義 | 「内部監査人」(またはそれに相当する)職責を使用して「設定」タブをクリックし、「懸案管理」サブタブをクリックします。 「カテゴリおよびタイプ」ハイパーリンクを選択します。 「カテゴリ:調査結果」で「タイプ」をクリックして適切な調査結果タイプにドリルインし、「構成」ハイパーリンクをクリックします。 |
選択肢は、「依存関係」、「処理ログ」、「添付文書」です。
注意: 調査結果におけるこれらのセクションの使用の詳細は、「Oracle Internal Controls Managerにおける調査結果の記録」を参照してください。
主要属性には、「摘要」、「割当先」、「優先度」、「理由」、「ステータス」などがあります。主要属性は「調査結果要約」画面に表示されます。
アプリケーションの複数ウィンドウで調査結果を入力できます。該当するウィンドウで「オープン調査結果」アイコンをクリックし、「作成」ボタンをクリックします。
デフォルトの調査結果タイプは、常にその調査結果が記録されるコンテキストに基づいています。たとえば、監査プロジェクトの「統制詳細」ページから調査結果を入力すると、調査結果タイプは自動的に「ProjCtrl」に設定されます。
次の表に、様々なタイプの調査結果を作成できる各種コンテキストへのナビゲータ・パスを示します。
調査結果タイプ | 作成に使用するウィンドウ |
---|---|
監査手順調査結果 | 監査プロジェクトの「監査タスク詳細」ウィンドウ。プロジェクト・タスクにドリルインし、監査手順に関連付けられている「調査結果」アイコンにアクセスする必要があります。 |
統制調査結果 | 監査プロジェクトの「統制詳細」ウィンドウ。 |
組織調査結果 | 監査プロジェクトの「組織およびプロセス詳細」ウィンドウ。 |
プロセス調査結果 | 監査プロジェクトの「組織およびプロセス詳細」ウィンドウ。 |
リスク調査結果 | 監査プロジェクトの「リスク詳細」ウィンドウ。 |
監査手順ステップ | 監査プロジェクトの「監査タスク詳細」ウィンドウ。プロジェクト・タスクにドリルインして「ステータス」をクリックし、監査手順の各ステップに関連付けられている「調査結果」アイコンにアクセスします。 |
プロジェクト調査結果 | 監査プロジェクトの「調査結果詳細」ウィンドウ。 |
調査結果を作成すると、前の項で説明した設定に基づいていくつかのフィールドにデフォルト値が表示されます。次に例を示します。
調査結果番号は、調査結果タイプの基本情報の設定に基づきます。
「ワークフロー承認」サブタブの経路情報も、調査結果タイプの設定からデフォルト設定されます。このサブタブのビューは特定のライフ・サイクル・ステータス用であることに注意してください。すべてのステータスの簡潔ビューを開くには、「調査結果要約」ページ(次の項で説明)を表示します。
その他のパラメータは、設定時にシードされた値を使用して入力できます。次に例を示します。
「優先度」および「理由」は、設定時にシードされた値を使用して入力されます。
属性グループが表示されるページはサブタブとして表示されます。これらのウィンドウの属性は、関連する値セットについてシードされた値を使用して入力されます。
注意: 「調査結果の作成」ウィンドウのサブタブ・セクションの詳細は、「Oracle Internal Controls Managerにおける調査結果の使用」を参照してください。
このアプリケーションでは調査結果の問合せに2つのレベルがあります。メニュー・パス「監査業務」->「関与」->「監査関与」を使用してアプリケーションにアクセスし、各種の詳細ウィンドウで調査結果を開始または表示する場合は、特定のプロジェクト内の特定のタイプの調査結果が使用されます。
これに対して、メニュー・パス「監査業務」->「調査結果」(「ビジネス・プロセス」タブと「財務諸表」タブにもあります)を使用してアプリケーションにアクセスすると、複数のプロジェクト間で任意の種類の調査結果を問い合せることができます。たとえば、社内の全プロジェクトにまたがって、過去3か月間の特定の統制に関する調査結果を表示するように選択できます。
調査結果の作成後、その調査結果にドリルインして「調査結果要約」ページにアクセスできます。 この要約ページを使用して、調査結果に関する情報を記録するとともに、承認経路などの処理を開始できます。
処理ログの文書化
「処理ログ」セクションは掲示板として機能し、監査チームおよび経営者の間で議論スレッドを開始できます。次の操作ができます。
コメントの転記
特定のユーザーからのコメントを要求し、このセクションからこれらのコメントを追跡することができます。Oracle Internal Controls Managerでは、このウィンドウで変更内容とコメントの詳細履歴が保守されます。
依存関係の表示および更新(存在する場合)
「依存関係」コンテナには、調査結果にリンクされたすべてのエンティティが表示されます。「調査結果クローズ時の改善の使用」の項を参照してください。
属性値の記録
「調査結果要約」ページのこのコンポーネントの表示名は、属性グループの組込みに使用されたページの名称に基づきます。
注意: ページの作成の詳細は、「2. 属性と値セットの定義」を参照してください。
前述のように、調査結果に関連付けられた属性は、関連する調査結果タイプの設定に基づきます。
「懸案管理」内のライフ・サイクルは、該当するエンティティに対する一連のステータス(フェーズ)とみなすことができます。各ステータスは、そのステータスを次のステータスに進める前に評価する必要のあるフェーズを表します。たとえば、プロジェクト」調査結果タイプのライフ・サイクル・ステータスには「オープン」、「承認」、「完了」などを使用できます。ライフ・サイクルにより、「懸案管理」の各種エンティティのステータスを追跡および管理できます。
エンティティ・カテゴリのタイプごとにライフ・サイクル・ステータスのセットを指定できます。したがって、「プロジェクト」調査結果タイプには、「ProjStep」調査結果タイプとは異なるライフ・サイクル・ステータスのセットを使用できます。同様に、各懸案タイプにもライフ・サイクル・ステータスを固有に実装できます。
ライフ・サイクルの設定は、承認経路テンプレートの定義中に行います。
注意: 詳細は、「4. 承認経路テンプレートの定義」を参照してください。
「調査結果要約」ウィンドウの「ワークフロー」セクションで承認経路を開始します。例として、最初のライフ・サイクル・ステータスが「オープン」である新規調査結果を想定します。この調査結果を次のステータス(「承認」ステータスなど)に推進すると、ワークフロー・プロセスが開始されます。すべてのワークフロー承認が正常に完了すると、ライフ・サイクル・ステータスが推進後のステータスに変更されます。
「改善」機能を使用すると調査結果のクローズ時に役立ちます。改善では、監査プロジェクト中に発生した調査結果に対処するために開始されている計画、および処理に関する情報がカプセル化されます。
改善は、属性、承認経路などを使用して設定できます。設定内容は、調査結果について前に説明した内容を反映しています。
注意: 詳細は、該当する調査結果の設定を参照してください。適切なメニュー・パスで、「カテゴリおよびタイプ」を「改善」として使用します。
改善の作成
改善は特定の調査結果の「調査結果要約」ページで作成されるため、自動的にその調査結果にリンクされます。
トピック | ナビゲータ・パス |
---|---|
改善の作成 | 「内部監査人」(またはそれに相当する)職責を使用して「監査業務」タブをクリックし、「調査結果」サブタブをクリックします。 関連する調査結果について、「調査結果要約」ページにドリルダウンし、「改善の作成」ボタンをクリックします。 |
調査結果に関連する全改善の表示
Oracle Internal Controls Managerでは、「調査結果」サブタブにおける調査結果の表示書式をパーソナライズできます。
トピック | ナビゲータ・パス |
---|---|
調査結果に関連付けられた依存関係(改善と同様)の表示 | 「内部監査人」(またはそれに相当する職責)を使用して「監査業務」タブをクリックし、「調査結果」タブをクリックします。 「表示書式」に関連付けられた「パーソナライズ」ボタンをクリックします。「依存関係」コンテナを開示します。 |
このコンテナにドリルダウンして、調査結果に関連付けられたすべての改善(および修正要求、事故レポートなどの他のエンティティ)を表示します。「依存関係」ウィンドウでは、「依存の追加」値リストにより追加エンティティ(別の改善など)を選択して調査結果にリンクすることもできます。
この方法で、改善を修正要求、事故レポート、懸案および開示委員会エンティティにリンクすることもできます。
調査結果などの懸案は、認証プロセスのコンテキスト内で作成されます。これらの懸案は、プロセスの実行中に確立した標準に対する非遵守項目として定義できます。通常、非遵守項目は、手順やアカウンタビリティなどに違反する重大な懸案項目です。
懸案は、プロセス・オーナーによるプロセス認証中に記録されます。Oracle Internal Controls Managerの実装(設定、記録、表示およびクローズ)は、調査結果に関して前の項で説明した内容を反映しています。
注意: 詳細は、該当する調査結果の設定を参照してください。適切なメニュー・パスで、「カテゴリおよびタイプ」を「懸案」として使用します。
Oracle Internal Controls Managerでは、調査結果タイプと同様、作成できる各種の懸案は懸案タイプを使用して区別されます。認証中に懸案が作成されると、アプリケーションにおける作成時のコンテキストに基づき、これらのタイプの1つとして自動的に記録されます。
懸案タイプ名 | 説明 | ナビゲータ・パス |
---|---|---|
CertIssue | プロセス認証懸案 | 「ビジネス・プロセス・オーナー」(またはそれに相当する)職責を使用して「ビジネス・プロセス」タブをクリックし、「認証」サブタブをクリックします。 認証にドリルダウンして「懸案」サブタブを選択します。 |
ProcIssue | プロセス懸案 | 「ビジネス・プロセス・オーナー」(またはそれに相当する)職責を使用して「ビジネス・プロセスタブをクリックし、「認証」サブタブをクリックします。 認証にドリルダウンして「自分のプロセス」サブタブを選択します。 |
注意: 懸案タイプ「OrgIssue」はこのアプリケーションでは使用されません。
認証の実行中には、(懸案にリンクする)改善を作成できないことに注意してください。改善は調査結果のコンテキスト内でのみ作成できます。ただし、次のように改善を懸案にリンクすることはできます。
トピック | ナビゲータ・パス |
---|---|
改善の表示と懸案へのリンク | 「ビジネス・プロセス・オーナー」(またはそれに相当する)職責を使用して「ビジネス・プロセス」タブをクリックし、「懸案」タブをクリックします。 「表示書式」に関連付けられた「パーソナライズ」ボタンをクリックして表示書式をパーソナライズし、「依存関係」コンテナを表示します。 |
このコンテナにドリルダウンして、現在懸案に関連付けられているすべての改善(および修正要求、事故レポートなどの他のエンティティ)を表示します。「依存関係」ウィンドウでは、「依存の追加」値リストにより追加エンティティ(別の改善など)を選択して懸案にリンクすることもできます。
同様に、メニュー・パス「ビジネス・プロセス」タブ->「改善」サブタブを使用して、改善に関連付けられたすべての懸案を表示することもできます。
職務分掌の違反が検出された場合は、違反を修正し、組織内で非互換タスクへのアクセス権を持っているユーザーからのリスクを軽減するステップを開始できます。
修正要求を開始するには、特定のユーザーに割り当ててアプリケーションで追跡できる正式な修正要求の形式を使用します。フォローアップ処理の必要な懸案を記録することもできます。
修正要求のステップは、調査結果について説明した内容と同様です。アプリケーションでは、修正要求のタイプは「DutyViolat」のみです。
注意: 詳細は、該当する調査結果の設定を参照してください。適切なメニュー・パスで、「カテゴリおよびタイプ」を「修正要求」として使用します(「修正要求」を表示するには、第2のカテゴリ・セットに進む必要がある場合もあります)。
また、「3. 修正要求の開始(およびそれに続くユーザー職務の変更)」も参照してください。
内部監査の整合性を保証するには、懸案管理エンティティ(調査結果、懸案、修正要求および改善)と関連データを記録、表示および更新できるユーザーを、適切な承認済ユーザーのみに限定することが重要です。たとえば、調査結果を作成したり、それに対する応答を入力できるのは、承認済ユーザーのみにする必要があります。調査結果に対する応答は、調査結果に関するコメントの要求または転記、ステータスの更新、承認経路の開始などの形式で行うことができます。
次の各項では、Oracle Internal Controls Managerにおける懸案管理に使用されている、セキュリティ・モデルの設定と実装について説明します。このセキュリティ・モデルを適切に実装すると、監査中に検出されて解決を要する項目を開始し、フォローアップの信頼性を確保するのに役立ちます。
Oracle Internal Controls Managerでは、割当済の職責に基づく新規懸案管理エンティティの作成を、許可または禁止できます。
スーパーユーザーは、あらゆる懸案管理エンティティを作成できます。
内部監査人は、調査結果と修正要求を作成できます。
オーナーまたはレビュー担当者のアクセス・レベル値(詳細は後述)を使用して調査結果にアクセスできるユーザーは、改善を作成できます。
グローバル業務管理者は懸案を作成できます。
プロセス・オーナーまたは組織マネージャ(定義は前述)は懸案を作成できます。
前述した5つ以外の職責を使用するユーザーは、アプリケーションで懸案管理エンティティを作成できません。
システム内の既存の懸案管理エンティティに対するアクセスを制御するため、Oracle Internal Controls Managerには次の職責レベルのプロファイル・オプションが用意されています。
AMW: 改善アクセス
AMW: 懸案アクセス
AMW: 調査結果アクセス
AMW: 修正要求アクセス
これらの各プロファイルは、各種懸案管理エンティティへのアクセスを制御する次の3つの値のいずれかに設定できます。
なし: 最下位のアクセス・レベル、アクセス禁止
レビュー担当者: 読取り専用アクセス
オーナー: 読取りおよび更新アクセス
次の表に、プロファイル・オプション、職責および事前シード値を示します。
プロファイル・オプション | 「内部監査人」職責 | 「ビジネス・プロセス・オーナー」職責 | 「グローバル業務管理者」職責 | 「署名役員」職責 | スーパーユーザー職責 |
---|---|---|---|---|---|
調査結果(AMW_FINDING_ACCESS) | オーナー | なし | レビュー担当者 | レビュー担当者 | オーナー |
懸案(AMW_ISSUE_ACCESS) | レビュー担当者 | なし | オーナー | レビュー担当者 | オーナー |
改善(AMW_REMEDIATION_ACCESS) | オーナー | なし | オーナー | レビュー担当者 | オーナー |
修正要求(AMW_CORRECTIONREQ_ACCESS) | オーナー | なし | なし | なし | オーナー |
注意: この表のシード値は、要件にあわせて構成できます。また、独自に作成したカスタム職責についても、表示されるプロファイルごとに適切な値を使用できます。
アプリケーションのユーザーは、懸案管理エンティティに対して複数レベルのアクセス権を取得できます。ユーザーが特定の懸案管理エンティティについて(様々なアクセス・ルールにより)複数レベルのアクセス権を取得する場合は、最上位のアクセス・レベルが表示されます。詳細は後述します。
監査中に作成される懸案管理エンティティは常に1人のユーザーに割り当てられるため、複数のアクセス・レベルが発生する可能性があります。担当者のアクセス・レベルはOracleによりシードされ、変更はできません。
調査結果の割当て: レビュー担当者・アクセス(調査結果の担当者はその調査結果に対する改善の作成もできます)
懸案の割当て: オーナー・アクセス
改善の割当て: オーナー・アクセス
修正要求の割当て: オーナー・アクセス
例: 「ビジネス・プロセス・オーナー」職責でアプリケーションにログインするユーザーUが調査結果Fの担当者であるとします。
「ビジネス・プロセス・オーナー」についてシードされる職責レベルのプロファイルに基づいて、調査結果に対するユーザーのアクセス・レベルは「なし」となります。ただし、ユーザーUは調査結果Fの担当者であるため、アクセス・レベルは「レビュー担当者」でもあります。この2つのレベルのうち上位は「レビュー担当者」であるため、ユーザーUは調査結果Fに対する「レビュー担当者」アクセスを取得します。
ユーザーUが「内部監査人」職責を使用してログインした場合は、「オーナー」アクセスを取得します。これは、職責レベルでの「オーナー」アクセスの方が担当者レベルでの「レビュー担当者」アクセスよりも上位アクセス・レベルであるためです。
ユーザーは、懸案管理エンティティの作成中または応答中には様々な個別ロールを使用できるため、複数のアクセス・レベルが発生する可能性もあります。これらのロールは次の形式をとります。
作成者: 懸案管理エンティティを作成したユーザー
プロセス・オーナー: 懸案管理エンティティが記録されるプロセス(またはその親プロセス)を所有するユーザー
組織マネージャ: 懸案管理エンティティが記録される組織(または親組織)のマネージャであるユーザー
次の表に、懸案管理エンティティ、ロールおよび事前シード値を示します。これらの値は変更できません。
懸案管理エンティティ | 「作成者」ロール | 「プロセス・オーナー」ロール | 「組織マネージャ」ロール |
---|---|---|---|
調査結果 | オーナー | レビュー担当者 | レビュー担当者 |
懸案 | オーナー | オーナー | オーナー |
改善 | オーナー | オーナー | オーナー |
修正要求 | オーナー | なし | なし |
例: 「ビジネス・プロセス・オーナー」職責でログインするユーザーUが、調査結果Fが記録されるプロセスのオーナーであるとします。
「ビジネス・プロセス・オーナー」についてシードされる職責レベルのプロファイルに基づいて、調査結果に対するユーザーのアクセス・レベルは「なし」となります。ただし、ユーザーUは調査結果Fが記録されたプロセスのプロセス・オーナーであるため、アクセス・レベルは「レビュー担当者」でもあります。この2つのレベルのうち上位は「レビュー担当者」であるため、ユーザーUは調査結果Fに対する「レビュー担当者」アクセスを取得します。
ユーザーUが「内部監査人」職責を使用してログインした場合は、「オーナー」アクセスを取得します。これは、職責レベルでの「オーナー」アクセスの方がプロセス・オーナー・レベルでの「レビュー担当者」アクセスよりも上位アクセス・レベルであるためです。
注意: アプリケーション内の懸案管理エンティティに対する最低アクセス・レベルは、サイト・レベルのプロファイル「ENG: 変更に対する内部ユーザーのデフォルト・ロール」で設定されます。前項で説明したセキュリティを有効にするには、このプロファイル・オプション値を「なし」に設定する必要があります。
デフォルト値は「レビュー担当者」です。この値を「なし」に変更しないと、ユーザー全員がすべてのエンティティに対して「レビュー担当者」以上のアクセスを取得し、事実上は「レビュー担当者」が最下位アクセス・レベルとなります。