Oracle Internal Controls Managerインプリメンテーション・ガイド リリース11i B25733-01

目次

戻る

次へ

プロセス承認と変更管理

Oracle Internal Controls Managerのプロセス承認

OICMでプロセスを作成およびインポートする方法は、前の章で説明しました。これらのプロセスは「草案」ステータスで作成され、次の承認メカニズムで承認される必要があります。

プロセスは「草案」ステータスで作成されます。承認のために発行されると、プロセスのステータスは「承認保留」に変更されます。「承認保留」ステータスの間は、プロセスの属性およびその子プロセスは変更できません。プロセスが承認されるとステータスは「承認済」となり、そのプロセスはアプリケーション内で使用できるようになります。

注意: 前述の一般的な承認メカニズムの例外として、次の条件を満たしている場合、Web ADIを使用し、承認済としてプロセスをインポートできます。

• WebADIで入力された「プロセス承認ステータス」が「承認済」であること。

• OICMプロセス・パラメータ「承認が必要」（この項で後述）が「No」に設定されていること。

プロセス検証

組織のビジネス・プロセスの検証は、内部監査機能の重要な部分です。ビジネス・プロセスは、急激な環境の変化や法律、他のプロセスにおける変更など様々な理由で、（手動および自動の両方で）変更されます。プロセスの変更は、そのプロセスのリスク・エクスポージャー（リスクにさらされる度合い）およびそのプロセスに対する内部統制の設定に悪影響を及ぼす恐れがあるため、検討と承認メカニズムを必要とします。

また、内部監査部門では、プロセス変更を評価して、付加的な統制リスクをもたらすかどうかを判断する必要があります。付加的な統制リスクは、主要なリスク、統制およびビジネス設定に対する変更を検討することで把握できます。このため、ビジネス・プロセスのバージョン情報と履歴データを表示することはきわめて重要です。

Oracle Internal Controls Managerは、このドメイン内に豊富な機能を備えており、直観的なワークベンチを使用して次のような機能とメリットを提供します。

• すべてのプロセスおよびプロセス改訂は「草案」ステータスで作成され、システムで使用する前に承認が必要です。変更通知はすべての関係者（プロセス・オーナーなど）に送信されます。変更通知の受信者は、変更されたプロセスを検討した上で承認できます。

• このアプリケーションでは、エンティティ内のすべてのプロセス（非標準プロセスなど）に関する詳細な改訂履歴が保守されます。したがって、監査人には、組織内およびリスク・ライブラリ内で行われたすべての変更について全監査証跡を表示する機能があります。

• プロセス変更を承認する前に、改訂済プロセスを前回のバージョンと比較して、変更が受入可能かどうかを決定できます。比較は、関連プロセスに関する変更または例外が与える影響を決定する上で重要です。階層ビューワを使用して、その変更の影響を受ける関連ビジネス・プロセスを表示することもできます。

  注意: このプロセス検証方法は、リスク、統制および監査手順オブジェクトの承認には適用されません。これらのオブジェクトの改訂管理にはOracle Approvals Managementを使用します。

  詳細は、「リスク・ライブラリの変更統制」および『Oracle Approvals Management Implementation Guide』を参照してください。

プロセス承認の設定 - プロセス・パラメータ

OICMには、このアプリケーションのプロセス・パラメータの値に基づいて様々な発行環境と承認環境が設定されています。これらのパラメータにより、リスク・ライブラリおよび組織内でプロセス承認がどのように機能するかが決定され、プロセスをフレキシブルに作成および変更できます。

リスク・ライブラリのパラメータの更新

OICMのプロセス承認メカニズムを使用するには、次のパラメータを設定しておく必要があります。

承認オプション

1. 下位の承認ステータスに関係のない承認

   このオプションによって、階層内の下位にある他のプロセスのステータスに関係なく、プロセスを個別に承認できるようになります。このため、未承認のサブプロセスを持つプロセスであっても発行および承認できます。

2. すべての下位の自動承認

   プロセスを承認すると、そのプロセスのすべてのサブプロセス（子、孫など）も承認されます。

3. すべての下位を承認する必要があります

   このオプションが選択された場合、すべての下位プロセスが承認されているプロセスのみが承認のために発行されます。

階層内の上位レベルのプロセスが承認のために発行されると、「承認オプション」の設定によって、その下位レベルのプロセスに対して実行される処理の選択を効果的に制限できます。たとえば、「すべての下位の自動承認」オプション値を選択した場合、発行したプロセスが承認されるまで下位階層での変更はできなくなります。

注意: 「承認オプション」設定の変更は、システム内で承認待ちになっている発行済プロセスがない場合、つまり「承認保留」ステータスのプロセスが存在しない場合にのみ許可されます。この場合、システム内で現在ロックされているプロセスはありません。

承認が必要

このパラメータでは、プロセスの発行にOracle Workflowを使用するかどうか、またはプロセスの自動承認を行うかどうかを指定します。

「承認が必要」を「No」に設定し、「承認オプション」を「下位の承認ステータスに関係のない承認」に設定した場合、プロセスの承認はただちに実行されます。「承認が必要」を「Yes」に設定した場合は、プロセスが承認のために発行されるとワークフロー承認経路が起動します。

注意: OICMでの承認にWorkflowを使用する方法の詳細は、「承認のためのプロセスおよびプロセス改訂の発行」を参照してください。

プロセス・コード・プリフィクス

プロセス・コード命名体系で接頭辞として使用されるコードを入力します。この設定はリスク・ライブラリ内でのみ有効ですが、組織コンテキストではプロセスとともに継承されます。

組織パラメータの更新

特定の組織をOICMに登録すると、それらの値はOICMリスク・ライブラリの値からデフォルト設定されます。

このウィンドウで、特定の組織に関する設定（前項で説明）を保守できます。たとえば、「リスク・ライブラリ」の「承認が必要」パラメータが「Yes」に設定されていても、組織Bの同じパラメータを「No」に設定できます。そのため、プロセスの承認はリスク・ライブラリでは必要ですが、組織Bでは不要です。

プロセス階層

OICMでは、プロセスを承認済階層と最新階層という2通りの階層で表示できます。OICMでは、この2つの階層を次のように区別します。

承認済階層

リスク・ライブラリ内でも組織内でも、プロセスの主要ビューには承認済階層が表示されます。

このビューでは、次の条件を両方とも満たしていないプロセスは表示されません。

• プロセスが承認済であること。

• 特定のプロセスから「全プロセス」まで、すなわち階層の最上位のプロセス・ノードまでの承認済パスがあること。つまり、該当するプロセスの上位に他のプロセスが存在する場合は、それらのプロセスも承認済であること。

  注意: 最上位プロセスである「全プロセス」の動作は、その他のプロセスとは異なります。「全プロセス」は常に「承認済」ステータスと改訂番号1を持つプロセスとみなされます。また、多くの場合単に「すべて」という名称で示されます。

すべてのプロセスが承認済であるため、このビューにはステータス列はありません。また、システム内に承認済プロセスが存在しない場合は、承認済階層に「全プロセス」ノードのみが表示されます。

最新階層（および「プロセス階層ワークベンチ」）

結果のビューには、そのプロセスの最新の階層が表示され、最新階層と呼ばれます。

この階層にはすべてのステータスのプロセスが表示され、工程管理のビューの場合と似ています。このウィンドウでは、プロセスの追加または更新、あるいはその両方が可能です。たとえば、特定のプロセスに関連付けられているプロセス属性と子プロセス、および一連のリスク・ライブラリ・オブジェクトとそれらの属性も変更できます。

注意: プロセスを変更する方法の詳細は、次の項の「Oracle Internal Controls Managerのプロセス改訂」を参照してください。

ここでの変更は、最初に承認を受ける必要があるため、リスク・ライブラリの現在の承認済階層に即時には反映されません。

承認済階層と最新階層の例として、次に示すプロセス階層について検討します。この階層が最新階層であるとします。P(A/D,1,X)は、プロセスPのステータスがA（「承認済」）またはD（「草案」）で、改訂番号が1、属性がXであることを示します。

「全プロセス」

|

|----P1(A,2,X)

| |

| |----P2(D,2,X)

| |

| |----P3(A,1,X)

|

|----P4(A,1,X)

この例の承認済階層は次のように表示されます。

「全プロセス」

|

|----P1(A,2,X)

|

|----P4(A,1,X)

プロセスP3は、それ自体は承認済プロセスですが、プロセスP2が「草案」ステータスであるためにルート・ノードである「全プロセス」までのパスが承認されていません。したがって、プロセスP3は承認済階層には表示されません。

注意: 前述の例では、ユーザーが社内の全プロセスに対するアクセス権を持っていることを前提としています。詳細は、「プロセス階層のビュー」および「OICMにおけるロールと権限」を参照してください。

改訂されたプロセスの場合、最新の承認済改訂は「承認済」ステータスで承認済階層と最新階層の両方に表示され、未承認の改訂は「草案」ステータスで最新階層にのみ表示されます。

組織に割り当ててアプリケーション内で使用できるプロセスは、承認済のプロセス（承認済階層に表示されるプロセス）のみである点に注意してください。

プロセス階層のビュー

これまでの例では、「全プロセス」ノード下の承認済階層と最新階層について詳しく説明しました。

ただし、OICMの一般的なユーザーには「自分のプロセス」タブの下に自分がオーナーとして表示されるプロセスのみが表示されます。その場合、「全プロセス」ノードにアクセスできない（つまり、スーパーユーザーではない）ユーザーは、「自分のプロセス」という名前で表示されるダミーの最上位レベルのプロセス・ノードにアクセスします。このノードには、そのユーザーの全プロセスが階層形式で表示されます。

例1

この例では、最新階層が次のような階層であるとします。

すべて

|

|----X(D,1,X)

|

|----P(A,2,X)

|

|----Q(D,1,X)

プロセスPのオーナーが承認済階層を表示する場合、そのビューは次のようになります。

自分のプロセス

これ以上表示するプロセスはありません。

これは、プロセスXが未承認であるため、プロセスPには「全プロセス」ノードへの承認済パスがないことによるものです。そのため、プロセスPはまだ「すべて」の承認済階層には追加されていません。

一方、プロセスPのオーナーが最新階層を表示する場合、そのビューは次のようになります。

自分のプロセス

|

|---P(A,2,X)

|

|---Q(D,1,X)

ここで、プロセスXが承認されたとします。プロセスPのオーナーに表示される承認済階層のビューは次のようになります。

自分のプロセス

|

|---P(A,2,X)

さらに、Pのオーナーに表示される最新階層のビューは次のようになります。

自分のプロセス

|

|---P(A,2,X)

|

|---Q(D,1,X)

例2

次のような最新階層があるとします。

すべて

|

|-------------------X(D,1,X)

| |

|---Q (A,1,X) |---P(A,2,X)

|

|---Q(A,1,X)

プロセスPのオーナーが承認済階層を表示する場合、そのビューは次のようになります。

自分のプロセス

|

|---Q(A,1,X)

これは、プロセスPのオーナーが同じ階層内のプロセスQのオーナーでもあることによります。ただし、プロセスXが未承認のためプロセスPはまだ承認済階層に表示されません。

プロセスPのオーナーが最新階層を表示する場合、そのビューは次のようになります。

自分のプロセス

|

|---P(A,2,X)

|

|---Q(A,1,X)

プロセスQはプロセスPとの関連においてのみ表示されます。

プロセス承認の例

次の例では、OICMでのプロセス承認機能の概要を説明します。プロセス承認メカニズムの大半は「承認オプション」のパラメータ値に基づいて決定されます。

次に示す例では、特に記載のないかぎり「承認オプション」パラメータが「下位の承認ステータスに関係のない承認」に設定されているとします。P(A/D,1,X)は、プロセスPのステータスがA（「承認済」）またはD（「草案」）で、改訂番号が1、属性がX[n]であることを示します。

承認オプションはA1、A2、A3で表します。

A1: すべてのプロセスが個別に承認されます。

A2: 承認済プロセスの下位にあるすべてのプロセスが、自動的に承認されます。

A3: 該当のプロセスの下位にあるすべてのプロセスが承認済の場合にのみ、承認のために発行できます。

例1

次のような最新階層があるとします。

すべて

|

|-- P1 (D,2,X)

| |

| | --- P4(A,1,X)

|

|-- P2(D,1,X)

|

|--P3(A,1,X)

この例では、承認済階層は、次のように表示されます。

すべて

ここでプロセスP1が承認されたとします。これにより、プロセスP4はルートまでの承認済パスを持つため、承認済階層にプロセスP1とプロセスP4の両方が追加されます。

承認済階層のビューは、次のようになります。

すべて

|

|-- P1 (A,2,X)

| |

| --- P4(A,1,X)

プロセスP3は承認済プロセスですが、ルートへの承認済パスがまだないため表示されません。「承認オプション」パラメータにどの値が設定されていても、前述の例と同様の結果になります。

例2

この例では、「承認オプション」パラメータにA2の値が設定されているものとします。

最新階層のビューは、次のとおりです。

すべて

|

|-- P1 (D,2,X)

| |

| | --- P2(D,1,X)

| |

| |---P3(D,1,X)

| |

| | --- P4(A,1,X)

|

|-- P2(D,1,X)

|

|--P3(A,1,X)

プロセスP1が承認のために発行され、その後承認されたとします。「承認オプション」パラメータにはA2が設定されているため、プロセスP1の下位にあるすべてのプロセスがただちに承認されます。したがって、プロセスP2とプロセスP3も承認されます。

その結果、最新階層と承認済階層のビューは、次のようになります。

すべて

|

|-- P1 (A,2,X)

| |

| | --- P2(A,1,X)

| |

| |---P3(A,1,X)

| |

| |---P3(A,1,X)

|

|--P2(A,1,X)

|

|--P3(A,1,X)

「承認オプション」パラメータの値がA3の場合、プロセスP1は承認のために発行することはできません。これは、プロセスP1に未承認の下位プロセスがあるためです。

プロセスの否認

プロセスが否認されると、ステータスは「草案」に戻されます。「承認オプション」が「すべての下位の自動承認」に設定されている場合にプロセスが否認されると、そのプロセスの下位階層に対するすべてのロックが解除されます。

必要に応じて、否認されたプロセスに変更を加えて、再び承認のために発行できます。

Oracle Internal Controls Managerのプロセス改訂

次の場合、プロセスは改訂されたものとみなされます。

• そのプロセスの属性のいずれかが変更された場合。プロセスの添付が変更された場合も、プロセス改訂となります。

• 子プロセスの変更。子プロセスとは、調査対象プロセスの直下にある一連のプロセスです。それ以外のレベルのプロセスが変更されても、プロセス改訂とはなりません。

• 関連リスクの変更。

• 関連統制の変更。

改訂されると、新規のプロセス改訂が「草案」ステータスで作成されるため、これを承認のために発行する必要があります。すべてのプロセス改訂は、前項で説明したものと同じ承認メカニズムで処理される必要があります。次に、改訂は承認または否認できます。否認された場合、「草案」ステータスのまま保持され、前回承認されたバージョンがそのまま最新の承認済プロセスとなります。

承認済プロセス（承認済プロセスのバリエーションおよび例外など）は、リスク・ライブラリおよび個々の組織の両方で改訂できます。

リスク・ライブラリ内のプロセスの改訂: パート1

承認済プロセスの改訂は、「リスク・ライブラリ」の「プロセス階層ワークベンチ」で行います。

注意: プロセスとそのサブプロセスの順序（「プロセス階層ワークベンチ」の「オーダー: 子」ボタンをクリック）を変更しても、プロセス改訂とはみなされないため、承認を受ける必要はありません。

草案プロセスおよび前回承認されたプロセスの、任意またはすべての内容を更新できます。プロセスに関連するリスク・ライブラリ・オブジェクトを更新することもできます。「更新」ドロップダウン・メニューを選択し、変更する内容に応じて「勘定科目」、「リスク」、「統制」などの該当するサブタブにナビゲートします。

リスク・ライブラリ・オブジェクトを追加するための値リストには、草案オブジェクトと承認済オブジェクトの両方が表示されます。ただし、プロセスに関連付けられたすべてのオブジェクトのステータスが承認済になるまで、また承認済でない場合、そのプロセスは承認のために発行できません。

変更が完了すると、そのプロセスの発行または承認ができるようになります。

リスク・ライブラリ内のプロセスの改訂: パート2（プロセス・バリエーション管理）

OICM設定の主要タスクは、企業のビジネス・フローを正確に反映したプロセスを作成することです。これらのプロセスを、自社の組織体系にマップする必要があります。リスク、統制機能および監査手順は、ビジネス・プロセスのドメイン内で作成および実行されます。

注意: OICMでプロセスを設定する方法の詳細は、「Oracle Internal Controls Managerのプロセス設定の概要」を参照してください。

アプリケーションでサポートされる組織体系の詳細は、「Oracle Internal Controls Managerにおける組織」を参照してください。

会社がビジネス・プロセスを組織および地理上の区間にまたがって標準化することには、様々なメリットがあります。たとえば、共通するプロセスの方法論、規模の経済性および学習などがあります。

ただし、社内の営業単位は、固有の環境にあわせて標準プロセスの派生形を実行している場合があります。このようなプロセス代替を処理するために、OICMではプロセス・バリエーションとプロセス例外を作成できます。Oracle Internal Controls Managerでは、この2つの職責を次のように区別します。

• プロセス・バリエーションは、アプリケーションのリスク統制ライブラリ内で作成された標準プロセスに対する変更です。プロセス代替は、プロセスの設計コンテキスト内で実行されます。バリエーションの理由付けは、標準プロセスを基準とした設計変更に関して行います。プロセス・バリエーションは後でいずれかの組織に関連付けることができます。

• これに対して、プロセス例外は特定の組織における標準プロセスと非標準プロセスの両方に対する変更です。プロセス代替と理由付けの両方が、特定の組織のコンテキスト内でのみ実行されます。プロセス例外の作成は、プロセスおよび対応するリスクと統制が社内の組織間で異なる場合にきわめて役立つ機能です。

注意: プロセス例外を作成する方法の詳細は、「組織内のプロセスの改訂」を参照してください。

どちらの場合も、プロセス代替は検討と承認を必要とします。内部監査部門は、変更内容も評価して、付加的なプロセス・リスクをもたらすかどうかを判断する必要があります。付加的なリスクは、補足または変更された統制および監査手順により軽減できます。プロセス代替には次の形式があります。

• ビジネス・プロセス階層でのプロセスの追加、削除または置換

• プロセス・バリエーションまたはプロセス例外に関連するリスクおよび統制の追加、削除または置換

• 関連リスク・ライブラリ・オブジェクトの属性の変更

プロセス・バリエーションの設定

プロセス・バリエーションを作成する手順は、次のとおりです。

1. リスク・ライブラリで非標準プロセスを作成します。

2. 標準プロセスのバリエーションとして非標準プロセスを定義します（オプション）。標準プロセスの代替理由も指定する必要があります。

たとえば、薬品の標準調達プロセスと非標準バリエーションを考えてみます。この例では、標準資材調達プロセスに次の2つのサブプロセスがあるとします。

• 標準分析および承認

• 標準ビッド

危険物を調達する場合は、前述のプロセスのバリエーションが使用されます。したがって、非標準プロセス｢非標準薬品調達」が非標準プロセスとして作成されます。このプロセスには、次の3つのサブプロセスがあります。

• 非標準分析および承認

• 標準ビッド（標準資材調達に使用される標準サブプロセスと同じ）

• 検査

1. リスク・ライブラリにおける非標準プロセスの作成

アプリケーションのリスク・ライブラリに非標準プロセスを作成するか、またはインポートします。リスク・ライブラリに作成したプロセスまたはプロセス階層は、社内のすべての組織に添付できます。

注意: リスク・ライブラリ内のプロセスの作成とインポートの詳細は、「Oracle Internal Controls Managerのプロセス設定の概要」を参照してください。

次の表に、前述の例に示したプロセスをインポートするためのスプレッドシートを示します。

このスプレッドシートは、プロセス・インポート・スプレッドシートに表形式で表示されるプロセス属性のサブセットを示しています。プロセスを非標準にするために、OICMでは単純な「Yes」/「No」オプションを使用します。

注意: このスプレッドシートの全フィールドの詳細は、「プロセスの属性」を参照してください。

2. 標準プロセスのバリエーションとしての非標準プロセスの定義（オプション）

「バリエーション」ページで、このプロセスを標準プロセスのバリエーションとして設定できます。そのためには、「標準プロセス」で「No」を選択し、ページの「バリエーション」リージョンに標準プロセス名を入力します。これで、非標準プロセスが標準プロセスのバリアントとなります。標準プロセスとして設定されたプロセスのみが「標準プロセス」フィールドの値リストに表示されることに注意する必要があります。

この例では、「非標準薬品調達」および「非標準分析および承認」が標準プロセス「標準薬品調達」および「標準分析および承認」のバリエーションとして設定されています。最後に、バリエーションの理由を入力します。

標準プロセスとバリアント・プロセスの比較

非標準プロセスの「プロセス詳細」ウィンドウで、「バリエーション例外」ボタンをクリックして標準プロセスをそのバリエーションと比較します。

標準プロセスのバリアントである非標準プロセスの数には制限がないことに注意してください。ただし、常に現行の非標準プロセスとその関連標準プロセスとの比較のみです。

注意: リスク、統制および監査手順は、通常の方法で非標準（バリアント）プロセスに関連付けられます。詳細は、「Oracle Internal Controls Managerでのリスクの設定」、「Oracle Internal Controls Managerでの統制の設定」および「Oracle Internal Controls Managerでの監査手順の設定」を参照してください。

組織内のプロセスの改訂

前述のように、企業には標準化されたビジネス・プロセスで作業できるというメリットがあります。プロセスを会社全体で正式に標準化できても、様々な組織での実行方法が異なる場合があります。これは、非標準プロセスとして設計されたプロセスの場合も同様で、この種のプロセスを組織ごとに異なる方法で実装できます。国別仕様を考慮した変更や、プロセスの環境の相違などが存在する可能性があります。

注意: 非標準プロセスの詳細は、「リスク・ライブラリ内のプロセスの改訂: パート2（プロセス・バリエーション管理）」を参照してください。

Oracle Internal Controls Managerでは、このような相違点を考慮してプロセスまたはプロセス階層のバリエーションをそのつど複数作成するのではなく、社内の各組織のプロセスを個別に変更できます。変更は1組織に固有であり、他の組織には反映されません。したがって、1つの標準プロセスを複数の組織に関連付けてから、それぞれを個別にカスタマイズできます。これにより、リスク・ライブラリ内のプロセスとそれが関連付けられている組織内のプロセスには相違が生じます。つまり、組織内に標準プロセスに対する固有の例外を作成できます。

注意: プロセスを組織に関連付ける方法の詳細は、「Oracle Internal Controls Managerにおける組織」を参照してください。

組織にリスク・ライブラリ・オブジェクトを追加または置換するには、そのオブジェクトがOracle Internal Controls Managerのリスク・ライブラリに存在する必要があるので注意してください。

組織内のプロセスの改訂

組織プロセスの改訂は、「プロセス階層ワークベンチ」（組織のコンテキスト内）で行います。

草案プロセスおよび前回承認されたプロセスの任意のまたはすべての内容を更新できます。組織プロセスに関連するリスク・ライブラリ・オブジェクトを更新することもできます。「更新」ドロップダウン・メニューを選択し、変更する内容に応じて「勘定科目」、「リスク」、「統制」などの該当するサブタブにナビゲートします。

組織内の「プロセス階層ワークベンチ」では、そのプロセスとリスク・ライブラリ内のオリジナル・プロセスとの同期化を選択することもできます。

次の表に、同期化を行う場合のオプションの詳細を示します。オプションは組み合せて使用できます（オプション2と3は併用する必要があります）。

注意: サブプロセスの改訂

組織のプロセスの初期ビューは、Oracle Internal Controls Managerのリスク・ライブラリから取り込まれます。

注意: 詳細は、「Oracle Internal Controls Managerにおける組織」を参照してください。

「リスク」または「統制」ハイパーリンクをクリックすると、プロセスに関連付けられているリスクまたは統制の詳細ビューにドリルダウンできます。詳細ページにドリルダウンする場合は、数について次のことに注意してください。

• 親プロセスに関連付けられているリスクの数は、子プロセスに添付されているリスクの合計数に対応します。

• 詳細ページには個別の統制のみが表示されるため、親プロセスに関連付けられている統制の数が子プロセスの合計に対応するとはかぎりません。

関連プロセスの「サブプロセスの追加」アイコンを選択し、この組織に改訂を作成します。前述のように、この変更は他の組織には反映されません。次のサブプロセスを追加できます。

1. 組織内の既存のプロセス

2. アプリケーションのリスク・ライブラリ内のプロセス

   アプリケーションのリスク・ライブラリ内のプロセスの場合、OICMでは、必要に応じて既存のサブプロセスの同期化または「RCMの適用」を選択できます。

   注意: これらのオプションの詳細は、「プロセスと組織のリンク」を参照してください。

組織におけるプロセス改訂作成の注意事項は、次のとおりです。

• 組織内で追加または置換できるプロセスの値リストは、プロセス・リスク・ライブラリ内の全プロセスのサブセットです。これは、階層に循環関連を作成するようなサブプロセスの追加がアプリケーションで防止されているためです。

• 組織内でプロセス・オーナーなどのプロセス属性を変更すると、組織内でそのプロセスの全発生箇所に反映されます。

プロセス改訂の例

次の例では、OICMでのプロセス改訂機能の詳細を説明します。また、これらの例は改訂番号の増分規則を理解する上でも役立ちます。特に記載のないかぎり、「承認オプション」パラメータは「下位の承認ステータスに関係のない承認」に設定されているとします。

また、これらの例では、P(A/D,1,X)は、プロセスPのステータスがA（「承認済」）またはD（「草案」）で、改訂番号が1、属性がX[n]であることを示します。

プロセス改訂番号の採番規則: プロセス属性の改訂番号は各プロセスに関連付けられたカウンタで、そのプロセスに対して行われた改訂の回数が記録されます。OICMで最初に作成またはインポートされたプロセスには改訂番号1が割り振られます。その後は改訂が行われるたびに番号が1ずつ追加されます。最上位レベルのプロセスである「すべて」は常に「承認済」ステータスを持ち、改訂番号の採番規則は適用されず改訂番号は1となります。

プロセスPは、次のような子プロセスP1とプロセスP2を持つ承認済のプロセス（2回目の改訂）です。

P(A,2,X)

|

|--P1(A,1,X)

|

|--P2(D,1,X)

例1

プロセスPの属性値XをX1に変更するとします。これにより、プロセスPは改訂されたとみなされ、ステータスは「草案」に変更されます。

P(D,3,X1)

|

|--P1(A,1,X)

|

|-- P2(D,1,X)

例2

プロセスPに子プロセスP3を追加したとします。これによって、階層は次のようになります。

P(D,3,X)

|

|--P1(A,1,X)

|

|-- P2(D,1,X)

|

|--P3(D,1,X)

次に、プロセスPが承認のために発行され、その後承認されたとします。これによって最新階層は次のようになります。

P(A,3,X)

|

|--P1(A,1,X)

|

|-- P2(D,1,X)

|

|--P3(D,1,X)

この承認後にプロセスP3を削除したとします。OICMでは、改訂は承認済プロセスに対してのみ実行できるため、この変更はプロセスPの新規改訂とはみなされません。したがって、最新階層は次のようになります。

P(A,3,X)

|

|--P1(A,1,X)

|

|-- P2(D,1,X)

このプロセスの改訂番号は変更されません。

一方、プロセスP3ではなくプロセスP1（前回承認された改訂を持つ）を削除した場合は、プロセスPの改訂とみなされます。したがって最新階層は次のようになります。

P(D,4,X)

|

|-- P2(D,1,X)

|

|--P3(D,1,X)

プロセスの削除（削除および関連付け解除）

OICMにおけるプロセスの削除は、プロセス階層からの削除または関連付け解除という方法で行われます。削除はリスク・ライブラリおよび組織の両方のコンテキストで実行できますが、関連付け解除は組織についてのみ実行できます。

この2つの方法の機能的な違いは次のとおりです。階層からの削除では、（リスク・ライブラリまたは組織のプロセス階層内で）対象プロセスとその親プロセス間のリンクが解除されますが、関連付け解除では、対象プロセスの全インスタンスが組織のプロセス階層から削除されます。どちらの場合も、対象プロセス自体はシステム内に残ります。

削除および関連付け解除は、いずれも「プロセス階層ワークベンチ」で行います。

リスク・ライブラリ内のプロセスの削除

削除機能では、プロセス階層内で特定のプロセスとその親プロセス間のリンクが解除されます。

組織内のプロセスの関連付け解除

プロセス階層の特定のノードからサブプロセスを関連付け解除するのは、そのプロセスを組織から削除するのと同じことです。つまり、サブプロセスはその特定のノードのみでなく組織の他のすべてのノードからも切り離されます。したがって、組織のプロセス階層のいずれかのノードから親プロセスを関連付け解除すると、階層内の全ノードからその親プロセスとすべてのサブプロセスが削除されます。

プロセス削除の例

例1: リスク・ライブラリからの削除

リスク・ライブラリ内に次のような承認済階層があるとします。

「全プロセス」（承認済階層）

|

P1(A,2,X)

| |

| |----P2(A,2,X)

| |

| |----P3(A,1,X)

|

|----P3(A,1,X)

プロセスP2の子プロセスであるプロセスP3を削除した場合、この階層は次のように変更されます。

「全プロセス」（最新階層）

|

P1(D,3,X)

| |

| |----P2(A,2,X)

|

|----P3(A,1,X)

プロセスP2の子プロセスであるプロセスP3のインスタンスのみが削除されています。ただし、プロセスP3はプロセスP1の階層内に残ります。

その結果、承認済階層に表示されるのは「全プロセス」のみとなります。

「全プロセス」（承認済階層）

例2: 組織からの関連付け解除

組織内に次のような承認済階層があるとします。

「全プロセス」（承認済階層）

|

P1(A,2,X)

| |

| |----P2(A,2,X)

| |

| |----P3(A,1,X)

|

P3(A,1,X)

プロセスP3をこの階層から関連付け解除すると、この階層は次のように変更されます。

「全プロセス」（最新階層）

|

P1(D,3,X)

|

|----P2(A,2,X)

この関連付け解除によって、プロセスP3の全インスタンスがプロセスP1の階層から削除されました。

新しい承認済階層は、次のようになります。

「全プロセス」（承認済階層）

プロセスP3は承認済階層および最新階層のいずれにも表示されませんが、プロセスP3のオーナーは、必要に応じてプロセスP3を表示および変更できます。

例3

次のようなプロセス階層があるとします。

P(A,3,X)

|

|--P1(A,1,X)

|

|-- P2(D,1,X)

この階層からプロセスP2を削除したとします。OICMでは、改訂は承認済プロセスに対してのみ実行できるため、この変更はプロセスPの新規改訂とはみなされません。

したがって、最新階層は次のようになります。

P(A,3,X)

|

|--P1(A,1,X)

一方、プロセスP3ではなく（前回承認された改訂を持つ）プロセスP1を削除した場合は、プロセスPの改訂とみなされます。したがって最新階層は次のようになります。

P(D,4,X)

|

|-- P2(D,1,X)

承認のためのプロセスおよびプロセス改訂の発行

プロセスの変更が完了すると、そのプロセスを発行または承認できるようになります。

プロセス承認の設定

プロセス承認に関するOracle Internal Controls Managerアプリケーションの設定ステップは、次のとおりです。

1. プロセス承認テンプレートの作成

2. 作成したテンプレートを、有効なプロセス承認経路テンプレートとしてOICM内にシードします。

プロセス承認テンプレートの作成

プロセスの承認に関しては、次の2つのワークフロー・テンプレートを設定する必要があります。

• プロセス承認テンプレート: OICMリスク・ライブラリのプロセス承認に適用されます。

• 組織プロセス承認テンプレート: すべての組織のプロセス承認に適用されます。

プロセス承認テンプレートの説明を、次に示します。

注意: 組織プロセス承認テンプレートの作成ステップは、ここで説明するステップと同様です。

プロセスの承認には、シードされたテンプレートを使用する方法と、テンプレートをコピーして変更（「更新」ボタンをクリック）する方法があります。

シードされた「プロセス承認テンプレート」によるプロセス承認は、次のように行われます。

• リスク・ライブラリ内の該当するプロセスのオーナー（1名または数名）による承認は、オプションです。これらのオーナーには、該当するプロセスに関する「リスク・ライブラリ・プロセス・オーナー」ロールが割り当てられています。

• プロセスの承認は、リスク・ライブラリ内の該当するプロセスの変更承認者が行う必要があります。これらの変更承認者には、該当するプロセスに関する「リスク・ライブラリ・プロセス変更承認者」ロールが割り当てられています。

プロセス承認ワークフローは、特定のステップが正常に終了すると次のステップの要件に進みます。ユーザーは、ワークフロー・テンプレートのほぼすべての内容を変更できます。たとえば、特定のワークフロー・ステップで、担当者のリスト、「1人の担当者」/「全担当者」/「必須担当者」のいずれからの承認が必要か、「応答日数」などを変更できます。

注意: シードされたテンプレートは必要に応じて変更できます。ワークフローの設定の詳細は、Oracle Workflowのマニュアルを参照してください。

OICMへのプロセス承認テンプレートのシード

次の2つのステップを実行して、テンプレートを有効なプロセス承認経路テンプレートとしてOICM内にシードできます。

1: ワークフローにアクセスし、「リスク・ライブラリ・プロセスの承認」カテゴリおよび「プロセス(リスク・ライブラリ)」タイプを表示します。組織プロセスの承認の場合は、「組織プロセス承認」カテゴリおよび「プロセス(組織)」タイプにアクセスします。

注意: 「プロセス承認(リスク・ライブラリ)」タイプおよび「プロセス承認(組織)」タイプは内部使用のみです。

まず、OICM内の「プロセス承認」（または「組織プロセス承認」）タイプにアクセスします。

2: ワークフローを変更します。

「プロセス(リスク・ライブラリ)」タイプにドリルダウンし、プロセス承認ワークフローにアクセスします。組織プロセスの場合は、「プロセス(組織)」タイプにドリルダウンします。

該当するワークフロー・ステップに対して、「プロパティの更新」アイコンをクリックし、そのステップのプロセス承認テンプレート（作成済）をシードします。プロセス承認テンプレートは、ステップごと、つまりステータスが変更される段階ごとにシードする必要があります。

たとえば、「承認」と「完了」という2つのフェーズを持つワークフローについて考えます。（ステップ1で作成され、このステータスに対してシードされたテンプレートに基づいて）このワークフロー経路が、完全に実行され、発行済プロセスのステータスが「承認」から「完了」に変更されます。

注意: その他の設定（「属性グループ」、「ページ」など）は、「Oracle Internal Controls Managerにおける調査結果」に説明されています。

ビジネス・イベント処理の有効化

プロセス承認は、ビジネス・イベントを利用して機能します。プロセス承認に関与するイベントが有効化されていることを確認することは重要です。

Oracle Workflowで次のタスクを実行します。

必要に応じて、イベント・サブスクリプションのステータスを「使用可能」に変更します。このタスクを実行するには、「システム管理者」または「更新」権限を持つユーザーとしてログインする必要があります。

承認のためのプロセスの発行

「プロセス階層ワークベンチ」ですべての変更が終了すると、そのプロセスを承認のために発行できます（組織プロセスの承認のための発行も、これと同様です）。

注意: 「自動承認」を「Yes」に設定した場合、「レビューおよび発行」のかわりに「公開」オプションが使用可能になり、プロセスは自動的に承認されます。

プロセスの発行時には要約ウィンドウが表示されるので、ユーザーはそのプロセスに対して行われた変更を確認し、発行処理を続行するかどうかを判断できます。プロセスへの変更は、次の3種類に分類されます。

• プロセスの変更、または関連リスク・ライブラリ・オブジェクトの値の変更

• プロセスに関連付けられているリスク・ライブラリ・オブジェクトの追加

• プロセスの関連リスク・ライブラリ・オブジェクトの削除

最後に、この項の冒頭でプロセス承認の設定および承認の発行を基に作成された変更要求（「ワークフロー」、「ページ」、「依存関係」、「属性グループ」など）のパラメータを検討します。

注意: これらの変更要求パラメータの詳細は、「Oracle Internal Controls Managerにおける調査結果」を参照してください。

プロセスの履歴

OICMでプロセスを変更すると、プロセス改訂となります。ただし、前回のバージョンはシステム内に残るため、そのプロセスの以前の改訂をプロセスの履歴の一部としていつでも表示できます。

プロセス改訂番号およびプロセス階層のリンク

プロセスの改訂番号をクリックし、そのプロセス改訂の詳細な設定値を表示します。

プロセスの履歴には、そのプロセスの属性および関連リスク・ライブラリ・オブジェクトに対する変更と、そのプロセス階層に対する変更も含まれています。個々の改訂は1つのプロセス階層のリンクに対応しているため、このリンクを使用して、改訂に対して有効な階層の詳細を表示できます。

中間日付

第1レベルの子よりも下位にあるプロセスにおける階層変更は、プロセス改訂とはなりません。ただし、「中間日付」フィールドに日付を入力し、改訂の「開始日」と「終了日」の間の任意の日付における詳細な階層を表示できます。

Copyright © 2003, 2005, Oracle. All rights reserved.