リリース12
E05616-01
目次
前へ
次へ
| Oracle Product Information Managementインプリメンテーション・ガイド リリース12 E05616-01 | 目次 | 前へ | 次へ |
この章には次の項があります。
重要: アイディアおよび懸案のシード済変更管理カテゴリを使用できるのは、Product Lifecycle Managementのライセンスを取得した顧客のみです。Product Information Management Data Librarianのライセンスでは使用できません。
変更カテゴリと関連するタイプを定義するには、次のタスクを実行する必要があります。
| タスク | 必須? |
| 変更カテゴリの定義 | |
| 変更タイプの定義 | Yes |
| ライン・タイプの定義 | |
| 変更タイプ属性グループの定義 | |
| 変更ライン属性グループの定義 | |
| 変更属性グループ・セキュリティの設定 | |
| 変更タイプ属性のユーザー定義関数の実装 | |
| 変更タイプ属性の関連付け | |
| 変更管理ワークフローのカスタマイズ | |
| 承認経路テンプレートの定義 | Yes |
| ユーザー定義優先度コードの作成 | Yes |
| ユーザー定義事由コードの作成 | |
| ユーザー定義ステータスの作成 | |
| 変更カテゴリ基準テンプレートの定義 | |
| 変更カテゴリ結果書式の定義 | |
| 変更レポートの定義 |
キーワード検索、関連語句検索、曖昧検索など、Oracle Textの検索機能を利用するには、コンカレント・プログラム「品目カタログ・テキスト索引作成」を実行します。開発マネージャ職責を持つユーザーは、「要求の発行」ウィンドウからこのコンカレント・プログラムを発行できます。要求を発行するときに、コンカレント要求パラメータAction=CREATEを選択します。
関連項目
『Oracle Product Lifecycle Management User's Guide』の変更管理テキスト索引の最適化に関する項
変更カテゴリを使用すると、企業で必要な変更を定義および管理できます。シード済変更カテゴリ（アイディア、懸案、変更要求、変更通知、変更オーダー）以外に、ビジネス・ニーズに固有の変更カテゴリを作成できます。たとえば、変更カテゴリ「拡張要求」を作成すると、顧客の製品拡張要求を追跡できます。シード済変更カテゴリは削除できませんが、使用不可にはできます。
カテゴリのビジネス目的に基づいて、各変更カテゴリが改訂品目または要求明細を持つように構成できます。たとえば、改訂品目により変更オーダーが品目関連変更を実装可能なため、変更オーダーで改訂品目を保持できます。要求明細を使用すると、変更を要求したり、品目に関連するタスクを指定して、個人またはグループに割り当てることができます。基準テンプレートと結果書式を、頻繁に実行される検索基準の変更カテゴリに関連付けることができます。
シード済の変更カテゴリは次のとおりです。
懸案: 製品またはプロセスに関連する様々な懸案を追跡、管理および解決します。
変更要求: 変更を要求し、要求された変更の承認を取得します。
変更オーダー: 要求された変更を実装し、品目を改訂します。
アイディア: 顧客および内部ユーザーから提案、技術革新、改善などを取得します。
新規品目要求: 新規品目の定義と承認の正式なプロセスを提供します。
変更通知: 複数の受信者に文書とファイルを配布します。
ファイル・レビュー: 添付のレビューおよびフィードバックについて非公式のプロセスを許可します。
ファイル承認: 添付のレビューと承認の正式なプロセスを許可します。
変更カテゴリ・オブジェクトを表示および作成できるユーザーを制御するフォーム機能を指定できます。フォーム機能は、変更管理セキュリティ・メニュー（EGO_CHGMGMT_USER_SECURITY）に追加する必要があります。追加したフォーム機能は、ユーザー職責（開発マネージャ、開発エンジニアなど）で参照されます。「品目カタログ」ワークベンチでタブを使用可能にし、コンテキスト内の品目の変更カテゴリの全インスタンスを表示することもできます。
品目カタログで使用可能になっている新規変更カテゴリの拡張要求
変更カテゴリ機能セキュリティと「品目変更カテゴリ」タブの有効化
変更カテゴリ機能と品目変更カテゴリ・タブを有効にする手順
「品目拡張要求」タブのフォーム機能を作成します。
「摘要」タブ
機能
EGO_ITEM_ENH_REQ
ユーザー機能名
「EGOユーザー品目拡張要求」タブ
摘要
「EGOユーザー品目拡張要求」タブ
「プロパティ」タブ
タイプ
SSWA JSP FUNCTION
保守モード・サポート
なし
コンテキスト依存
職責
「Web対応 HTML」タブ
HTMLコールOA.jsp?page=/oracle/apps/ego/item/eu/webui/EGOTEMCHANGEMGMTLISTPGL=431=RP=EGO_USER_WORKBENCH_HOMEPAGE=EGO_ITEM_ENH_REQ=ENHANCEMENT_REQUEST
重要: 太字の文字は、それぞれ変更カテゴリのフォーム機能と内部名を表します。
拡張要求セキュリティのフォーム機能を作成します。機能名は、「ENG_CREATE_」（ENG_CREATE_ENHANCEMENT_REQUESTなど）にする必要があります。
「摘要」タブ
機能
ENG_CREATE_ENHANCEMENT_REQUEST
ユーザー機能名
設計拡張要求作成
「プロパティ」タブ
タイプ
SSWA JSP FUNCTION
保守モード・サポート
なし
コンテキスト依存
職責
「Web対応 HTML」タブ
HTMLコールOA.jsp?page=/oracle/apps/eng/changemgmt/webui/SelectChgTypePG=ENHANCEMENT_REQUEST
注意: 太字の文字は、変更カテゴリの内部名を表します。
変更カテゴリ・セキュリティと品目変更カテゴリ・タブのフォーム機能の作成
変更管理ナビゲーション・メニューに「拡張要求の作成」機能を追加します（メニューEGO_CHANGE_MGMT_MENUを参照してください）。
プロンプト
拡張要求の作成
機能
設計拡張要求作成
変更管理メニューへの機能の追加
変更管理セキュリティ・メニューに「拡張要求」セキュリティ機能を追加します（メニューEGO_CHGMGMT_USER_SECURITYを参照してください）。
機能
設計拡張要求作成
変更管理セキュリティ・メニューへの機能の追加
品目変更管理タブ・メニューに「品目拡張要求」機能を追加します（メニューEGO_USER_CHANGE_MANAGEMENT_TABを問い合せてください）。
プロンプト
拡張要求
機能
「EGOユーザー品目拡張要求」タブ
重要: EGO_USER_CHANGE_MANAGEMENT_TABなどの変更管理メニューに機能を追加する場合、プロンプトを入力する必要があります。
既存の変更カテゴリを複製することで、拡張要求の新しい変更カテゴリを追加します。新しい拡張要求変更カテゴリに表示されている例は、懸案カテゴリを複製することで定義されています。
内部名
ENHANCEMENT_REQUEST
名称
拡張要求
摘要
拡張要求
複数名称
拡張要求
ソート順序
9
開始日
システム日付にデフォルト設定
番号生成
生成済順序
プリフィクス
ER-
次有効番号
0001
既存の変更カテゴリの複製による新規変更カテゴリの追加
注意: 前述の設定タスクを完了した後、JservおよびApacheリスナー中間層ポートを停止してから再起動することをお薦めします。
関連項目
『Oracle Product Lifecycle Management User's Guide』または『Oracle Product Information Management Distribution Librarian User's Guide』の変更カテゴリの作成に関する項
優先度コードを使用すると、懸案または変更の緊急度を追跡できます。様々な優先度（高、中または低など）を取得する優先度コードを作成できます。
優先度コードは、すべての変更カテゴリとそのタイプに適用できます。
シード済優先度コードは削除できません。ただし、シード済優先度コードを使用不可にして、ユーザー固有の新規コードを定義することはできます。「無効日」フィールドに日付を指定することで、指定した日付に優先度を使用不可にできます。
事由コードを使用すると、懸案または変更が作成された事由を追跡できます。懸案または変更の事由（品質改善、設計改善、コスト低減、テスト失敗、非適合など）を取得するには、事由コードを作成します。
事由コードは、すべての変更カテゴリとそのタイプに適用できます。
シード済事由コードは削除できません。ただし、シード済事由コードを使用不可にして、ユーザー固有の新規コードを定義することはできます。「無効日」フィールドに日付を指定すると、指定した日付に事由を使用不可にできます。
分類では、会社で変更オーダーのカテゴリ化を自動化し、さらに変更オーダーが生産に与える影響をユーザーに正確に示すメカニズムが提供されます。オラクル社では、2つのタイプの分類が提供されます。
導出
導出分類コードは、ユーザー定義関数から導出されます。たとえば、Visionオペレーションのある会社部署は、変更オーダーに特定の分類コードが割り当てられるプロセスを自動化する必要があります。自動分類プロセスを作成するために、Visionでは、変更オーダーを、ユーザー入力時に特定の分類またはワークフロー経路へ分類する一連の属性が作成されています。ユーザー指定の属性は、ユーザー定義関数にマップされます。関数では属性で指定されたデータが取得され、有効な分類コードが導出されます。導出分類コードは、読取り専用データとしてユーザーに表示されます。ユーザー定義属性および関数の詳細は、「ヘッダー/ライン・タイプ属性と属性グループの定義」および「ユーザー定義関数の定義」を参照してください。変更タイプ属性のユーザー定義関数の設定の詳細は、「例: 変更タイプ属性のユーザー定義関数の実装」を参照してください。
有効
有効な分類コードは、値リストからユーザーが選択します。有効な値は、変更ヘッダー・タイプで指定されます。分類を使用できるのは、ベース・カテゴリが「変更オーダー」の変更カテゴリのみであることに注意してください。
ステータスを使用すると、ライフサイクルを通じて懸案または変更を管理できます。懸案または変更の様々な状態を示すステータス（オープン、保留中、完了、取消済など）を定義します。
ステータスは、すべての変更カテゴリとそのタイプに適用できます。
シード済ステータスは削除も使用不可にもできません。ただし、ビジネス・プロセスに固有の新しいステータスを定義できます。「無効日」フィールドに日付を指定すると、指定した日付にユーザー定義ステータスを使用不可にできます。
ワークフロー・テンプレートを使用すると、ビジネス承認プロセスを事前に定義できます。懸案、変更要求、変更オーダーなどの変更カテゴリを承認できるのは、承認経路が正常に終了した場合のみです。ワークフローは、変更ヘッダーおよびライン・レベルでサポートされます。「変更管理ワークフロー」タブの「設定」ワークベンチにリストされているワークフロー・テンプレートを使用して、変更タイプごとにヘッダーおよびライン・ワークフロー・テンプレートを作成して保持できます。
新しいワークフロー・テンプレートの作成
ワークフロー・テンプレートの作成中に、「タイプ」を指定する必要があります。
重要: 特定のタイプでワークフロー・テンプレートを作成した後は、そのタイプは変更できなくなります。
現在サポートされているワークフロー・テンプレート・タイプは次のとおりです。
承認
承認ワークフロー・テンプレート・タイプは、ステータス・タイプが「承認」のワークフローに対してのみ有効です。
定義
定義ワークフロー・テンプレート・タイプは、ステータス・タイプが「オープン」の新規品目要求内にあるワークフローに主に使用されます。定義と承認ワークフロー・テンプレート・タイプは、ステータス・タイプが「承認」の新規品目要求に主に使用されます。
一般
一般ワークフロー・テンプレート・タイプは、その他のすべてのステータス・タイプに使用されます。
特定のワークフロー・タイプを特定のステータスに関連付けることができます。ステータス・タイプとワークフロー・タイプの関連を次に示します。
| ステータス・タイプ | 有効なワークフロー・タイプ |
| Approval/Review | 承認 |
| その他 | 一般 |
| ステータス・タイプ | 有効なワークフロー・タイプ |
| オープン | 定義 |
| Approval/Review、定義と承認、または承認 | 承認 |
| その他 | 一般 |
基本的に、ワークフロー・テンプレートは承認ステップで構成されます。各承認ステップはワークフロー・プロセスを表し、担当者を指定します。たとえば、承認の要求、コメントの要求またはFYI通知の送信のステップを作成できます。
ワークフロー・テンプレートでは、次のシード済ワークフロー・プロセスを使用できます。
承認の要求
承認の要求ワークフローを使用すると、個人またはグループから承認を要求できます。
FYI
FYIワークフローを使用すると、個人またはグループにFYI通知を送信できます。
コメントの要求
コメントの要求ワークフローを使用すると、個人またはグループからコメントを要求できます。
定義
定義ワークフローは、主に新規品目要求プロセスで使用され、品目属性グループがステップ担当者によって定義されるように、新規品目要求プロセスで品目属性グループの関連を許可します。
定義と承認
定義と承認ワークフローは定義ワークフローに似ていますが、ステップ担当者による承認も必要です。詳細は、「新規品目要求の定義」を参照してください。
企業での特定のタイプの変更に必要な承認プロセスを計画および文書化する必要があります。これらのプロセスを事前に計画すると、ビジネス・プロセスに従ったワークフロー・テンプレートを定義できます。
複数の担当者またはグループを経路ステップに割り当てるか、個別の担当者またはグループを各経路ステップに割り当てると、パラレルおよびシリアルの承認を管理できます。特定のロール、個人またはグループを経路ステップに割り当てることができます。変更の作成時に個人またはグループが確実に割り当てられるようにするため、承認経路ステップで割当済の変更ロールに品目ロールをマップする必要があります（変更ロールへの品目ロールのマッピングの詳細は、「ロールの定義」を参照してください）。
「設定」ワークベンチでは、複数のワークフロー・テンプレートを指定した変更タイプに関連付けることができます。アイディア、懸案、変更要求、変更通知または変更オーダーのヘッダー・レベルで、複数のワークフロー・テンプレートをワークフロー・ステータスに関連付けます。ロール、グループおよび個人のフィルタに基づいて、アドホック・ステップ担当者をワークフローに追加することもできます。これによりユーザーはステータス内のワークフローを中止し、そのステータスの別のテンプレートを選択できます。
これらの関連付けが行われると、そのタイプ内における個別の変更オブジェクトの作成時に様々なワークフロー・オプションを選択できます。これにより、変更の承認担当者とは異なる、特定の変更を承認する必要がある担当者に連絡するための特殊化ワークフローを選択できます。
懸案、変更要求または変更オーダーの承認要求あるいはレビュー要求時に使用するワークフロー・テンプレートを設定できます。これにより、レビュー担当者と承認者は、ロール、グループおよび個人のフィルタに基づいて、ニーズを十分に満たすステップと特定の担当者を含むテンプレートを選択できます。任意のステータスで複数のテンプレートを設定できます。
「承認」ステータスに移動する前にテンプレートを変更する手順
変更単純検索ページに移動します。
問合せECR%を使用して、変更要求レコードを検索します。
特定の変更要求の番号を選択します。
「変更要求要約」ページで、「変更要求番号」を選択します。
「ワークフロー」タブ・リージョンを選択し、「承認」ステータスを選択します。
「承認」ステータス・リージョンで、「スイッチ・テンプレート」を選択します。
「ワークフロー」フィールドで、プルダウン・リストを使用して別のテンプレートを選択します。選択したテンプレートのワークフロー・ステップが表示されます。
「適用」を選択して作業内容を保存します。
選択したワークフロー・テンプレートは、この特定の変更オブジェクトの「承認」ステータス上で使用できるようになります。ワークフローを再起動すると、変更オブジェクトは「承認」ステータスでこのテンプレートのステップを通過します。
新しいワークフロー・テンプレートに基づいて新しい担当者を指定することもできます。
「承認」ステータスの処理中にテンプレートを変更する手順
「ワークフローの中止」ページに移動します。
「ワークフローの中止」を選択します。
「スイッチ・テンプレート」を選択します。
「ワークフロー」フィールドで、プルダウン・リストを使用して別のテンプレートを選択します。選択したテンプレートのワークフロー・ステップが下に表示されます。
「適用」を選択します。
「ワークフローの開始」を選択します。
必要に応じて、「担当者のリフレッシュ」を選択して、新しいワークフローを開始する前に新しい担当者を指定します。
オラクル社ではワークフローの拡張をサポートしています。拡張には、既存のシード済プロセスを使用した新しいワークフロー・プロセスの作成と、プロセス・ロジックを変更しないアクティビティのパラメータの変更（承認経路の中止サブプロセスでのカスタム・ロジックの追加など）が含まれます。
変更管理シード済ワークフローがビジネス・プロセスのニーズを満たしていない場合、独自のプロセスの作成、シード済プロセスの変更、シード済プロセスへの新規アクティビティの追加、またはカスタム・フックPL/SQLプロシージャの変更により、シード済変更管理ワークフロー・プロセスをカスタマイズまたは拡張できます。
シード済ワークフローを変更するのではなく、優先度変更のために新しいワークフロー・プロセスを作成する場合は、「ワークフローの開始」でコールされるカスタム・フックでカスタム・ワークフローを開始する独自のカスタム・ロジックを作成する必要があります。
変更承認経路ステップ（ENGCSTEP）で新しいワークフロー・プロセスを追加すると、プロセスは「承認経路」ページの承認経路ステップ・ワークフローとして使用可能になります。ワークフロー・プロセスは、承認経路ワークフローから自動的にコールされます。
アクティビティは複数のオブジェクト・プロセスで共有されるため、「ENG: 標準」（ENGWFSTD）品目タイプでアクティビティを作成します。それ以外の場合は、適切なオブジェクトの品目タイプでアクティビティを作成します。
ワークフロー通知を変更するのではなく、新しいメッセージを作成する必要があります。Oracle Workflow Builderでは、品目タイプ、品目タイプ属性、メッセージおよび参照タイプなどのオブジェクトのバージョン情報は保持されません。これらのオブジェクトでは、最新の定義が常に適用されるため、これらのオブジェクトの変更の下位互換性を維持するかどうかを考慮する必要があります。変更が既存のプロセスに影響する場合、既存のオブジェクトを編集するのではなく、新しいオブジェクトを作成する必要があります。
重要: オラクル社では、このマニュアルで説明されている拡張のシード済アクティビティ、プロセスおよびタイプのみをサポートしています。カスタム・アクティビティおよびプロセスはサポートしていません。
タスク・テンプレートは、変更オーダーについて完了する必要がある様々なタスクを定義します。タスク・テンプレートを作成できるのは、基本変更カテゴリが変更オーダーのカテゴリのみです。
タスク・テンプレートの作成
タスク・テンプレートは特定の組織に対して作成されます。したがって、複数のタスク・テンプレートを変更オーダー・タイプに関連付けることができます。変更オーダーが作成される組織に応じて、変更オーダーに関連付けられた組織に定義済のタスク・テンプレートが適用可能になります。
タスクが「必須」として指定されている場合、変更オーダーを次のステータスに進める前にタスクを完了する必要があることを示します。タスク・テンプレートを作成した後、そのタスク・テンプレートを使用して変更オーダー・ヘッダー・タイプの組織ポリシーを定義できます。詳細は、「ヘッダー・タイプの定義」を参照してください。
属性および属性グループを定義すると、懸案、変更要求および変更オーダーに関連する追加情報を取得できます。検証ロジックを持つユーザー定義属性を作成し、属性グループ内にある属性の集合として変更タイプに関連付けることができます。
属性は名前と値によって定義され、属性グループ内に保存されます。属性グループを変更ヘッダー・タイプまたは変更ライン・タイプに関連付けることができます。ヘッダー・タイプとライン・タイプに個別の属性グループを定義する必要があります。異なる変更カテゴリとその変更タイプ間で同じ属性グループを再使用できます。ユーザーは、変更タイプごとに作成したページに属性の値を入力します。有用性を向上するために、変更オブジェクトの属性の表示方法を定義することもできます。
属性に索引を付けると、検索のパフォーマンスを高速化できます。数値または日付データ型の場合、Bツリー索引を使用すると、値の範囲を検索したり、特に「より小さい」、「より大きい」などの関係演算子を使用できます。テキスト属性の場合、Oracle Text索引を使用すると柔軟なキーワード検索を実行できます。
ユーザー定義属性を作成する前に、次の操作を実行します。
同じ属性グループ内で関連する属性をグループ化します。次の表に、属性グループの例を示します。
| 属性グループ | 属性 | データ型 |
| 顧客優先度 | 顧客 | Char |
| 優先度 | Char | |
| 日付 | 標準日 | |
| レビュー | Char | |
| 実施原価 | 製造 | Number |
| 設計 | Number | |
| 仕入先価格など | Number |
必要に応じて、属性グループ・セキュリティを定義するカスタム権限を持つオブジェクト・ロール（変更）を作成します。編集/表示権限を設定すると、属性グループを保護できます。後で、特定のロールを持つユーザーのみがその属性を表示または編集できます。
属性のデータ型（Number、Char、Dateなど）を決定します。
重要: 属性を保存した後は、データ型は編集できません。
単位区分（通貨など）および単位（USドルなど）を設定します。
各属性の検証ルールを設定し、対応する値セットを作成します。詳細は、「ユーザー定義属性の値セットの定義」を参照してください。
属性グループの表示方法を決定します。
「単一行」には、値を含むテキスト・フィールドが表示されます。
「複数行」には、表内の同じ属性（列）について複数の値（行）が表示されます。
重要: 属性グループを複数行として表示する場合は、レコードの一意性を維持する属性または属性の組合せを定義します。
次の図は、異なる属性に対して表示オプションを設定する方法を示しています。「変更属性タイプの定義」の図は、これらの表示オプション設定の結果を示しています。たとえば、属性「顧客」がテキスト・フィールドとして表示するように設定され、実際にそのように表示されることを確認できます。属性「顧客」は値セット「顧客」を使用します。この値セットは、実際には値リスト（LOV）テキスト・フィールドとして表示される表です。属性「顧客」は、一意キーの一部としても保持されます。一意キーの追加または編集により既存のレコードの一意性が損なわれないかぎり（複製の作成）、一意キーを追加または編集できます。
次の図では、「会社名」属性の「使用可能」パラメータが「No」に設定されていることにも注意してください。これは、この属性が変更ページに表示されないことを示します。属性をいつでも使用不可にできますが、属性グループが変更タイプにすでに関連付けられている場合、属性は削除できません。
変更属性および属性グループの定義
変更タイプ属性の定義（属性値の設定）
関連項目
『Oracle Product Lifecycle Management User's Guide』または『Oracle Product Information Management Distribution Librarian User's Guide』の品目属性および属性グループの定義に関する項
変更タイプを使用すると、企業はビジネス・プロセスに合わせて変更カテゴリ内にある変更のタイプを分類できます。たとえば、企業内の様々なタイプの懸案を取得するために、品質の懸案、製品の懸案、パフォーマンスの懸案など、様々な懸案タイプを定義できます。
次の機能を持つ変更タイプを設定できます。
番号の自動追跡
入力、生成済順序または生成済関数に使用する自動採番スキーマを指定できます。生成済順序スキーマでは、プリフィクスと順序の次有効番号を指定できます。たとえば、「設計変更」タイプがプリフィクスDSGNを持つように設定できます。
デフォルト割当ロール
特定の個人またはグループのデフォルト割当ロールとして品目ロール（デザイン・エンジニアなど）を指定できます。たとえば、「デザイン・エンジニア」を選択すると、変更が作成される対象品目のデザイン・エンジニア・ロールを持つ個人またはグループがその変更に割り当てられます。変更が割り当てられるのは1つの個人またはグループのみであるため、目的の個人またはグループのみに確実に割り当てられるようにします。複数の個人が指定のロールを持つ必要がある場合は、グループを作成し、同じロールを持つ全ユーザーをそのグループに入れ、そのグループにデフォルト割当を指定することをお薦めします。複数の個人がデザイン・エンジニア・ロールを持つ場合、変更はそれらのユーザーの1人にランダムに割り当てられます。
属性グループ/ページ
ヘッダーに定義されている属性グループを変更タイプに関連付けることができます。これらの属性グループを使用すると、作成される変更のタイプ、または変更の処理に必要なビジネス・プロセス固有の属性に関する追加情報を取得できます。変更タイプのページを作成し、その変更タイプに関連付けられた属性グループを論理的に編成できます。
有効なコードの設定
変更タイプの優先度、事由および分類に対して有効なコードを指定できます（分類コードは、変更オーダー・カテゴリに基づいて使用可能な唯一の変更タイプです）。これにより、ユーザーが使用できる値を、これらのコードに対して選択された値に制限できます。これらの値を異なるコードに対して作成する方法は、この章の前半で説明しました。
基準属性グループとセクションの設定
ビジネス・プロセスに応じて、変更タイプの特定の基準属性とセクションのみを使用可能にできます。たとえば、マーケティングの懸案の場合、「プロジェクト名」および「プロジェクト・タスク名」属性は使用されない可能性が高いため、使用可能にしない選択もできます。同様に、仕入先要求の懸案の場合、組織内で誰がどのロールを持つかを仕入先に表示しないように、「個人」セクションを使用不可にできます。
ワークフロー
ワークフロー・タブで変更タイプの様々なステータスを定義できます。各ステータスに関連付けると、促進と後退の有効なステータスを指定し、ワークフローを各ステータスに関連付けることができます。「承認」ステータスの場合、承認タイプ・ワークフローのみを選択できます。必要に応じて、承認のデジタル署名を有効にすることもできます。ワークフローがステータスに関連付けられている場合、自動促進と自動後退を有効にすることもできます。これにより、ワークフローの正常完了時に変更を選択済ステータスへ自動促進したり、ワークフローの否認時に変更を選択済ステータスへ自動後退できます。複数のワークフローを変更ステータスに関連付け、その1つをデフォルトとして指定できます。ユーザーは関連付けられたワークフローの1つを実行時に使用できます。
変更オーダーの組織ポリシーとタスク・テンプレート
変更オーダーの場合のみ、組織別にタスク・テンプレートと伝播ルールを指定できます。変更タイプのワークフローにおける特定のステータス間に実行されるように、一連の変更タスク（タスク・テンプレートで定義済）をグループ化できます。これらのタスクがすべて必須か、一部のみ必須かを指定することもできます。
組織ごとのタスク・テンプレートの関連付け
変更オーダーの伝播ルール
各組織のタスク・テンプレートを関連付ける以外に、このタイプの変更オーダーを他の組織に伝播するための伝播ルールを指定できます。伝播ルールを使用すると、関連付けられたすべての改訂品目やタスクなど、変更オーダーを伝播する組織階層を指定できます。変更オーダーが特定のステータスになったときに、伝播ルールを自動的に実行できます。伝播するステータスを指定すると、変更の自動伝播を選択できます。さらに、伝播された変更をただちに計画することも選択できます。
注意: このオプションを使用できるのは、変更タイプが「計画済」ステータスをサポートしている場合のみです。
伝播ルールの定義
変更ライン・タイプを使用すると、品目に対する特定の変更または変更に関連するタスクを取得できます。たとえば、品目関連の変更（品目属性変更、構成部品再設計変更、添付変更、部品廃止など）を取得するために異なるライン・タイプを定義できます。
変更ライン・タイプ
ライン・タイプの作成は、変更ヘッダー・タイプの作成に似ています。各ライン・タイプには、デフォルト担当者および関連する件名を指定できます。
変更ライン・タイプの定義
ライン・レベルでワークフローを関連付けることができます。一般および通知ワークフロー・タイプはラインではサポートされていません。承認ワークフローはラインではサポートされていません。複数のワークフローをライン・タイプに関連付け、そのワークフローの1つをデフォルトとして設定できます。
属性、値、値セットおよび属性グループを作成した後、属性グループを変更タイプまたはライン・タイプに関連付けます。関連付けられた属性グループを表示するページを定義できます。
注意: 異なる変更カテゴリに属する変更タイプ間で同じ属性グループを再使用できます。
属性グループを変更タイプに関連付ける手順
属性グループを、その変更タイプ（変更オーダーまたは懸案）の「属性グループ」リストに追加します。
たとえば、変更カテゴリ「変更オーダー」には変更タイプ「設変」があります。次の図は、属性グループ「実施原価」および「単価」は、ヘッダー・タイプ「設変」に関連付けられていることを示します。
変更タイプ属性の関連付け
関連付けられた属性グループの変更ページを定義します。ページで1つ以上の属性グループを検索するか、属性グループごとに個別のページを作成できます。次の図は、変更オーダー・タイプ「設変」に「分類」と「影響分析」の2つのページがあることを示しています。図「属性のページの作成」は、2つの属性グループが変更オーダーの単一ページにレンダリングされる方法の例を示しています。
属性のページの作成
変更オーダー概要ページの属性の変更ページ
属性グループまたはページを使用するようにライン・タイプを設定できます。ラインに定義されていた属性グループを変更タイプに関連付けることができます。これらの属性グループを使用すると、作成される変更のタイプ、または変更の処理に必要なビジネス・プロセス固有の属性に関する追加情報を取得できます。ライン・タイプのページを作成し、そのライン・タイプに関連付けられた属性グループを論理的に編成できます。
変更ライン・タイプの属性グループ
ロール・ベースの変更管理セキュリティを実装するときに、特定の変更管理属性グループの表示および編集権限を制御する権限を設定できます。特定の権限を付与するロールを割り当てることで、変更オブジェクトの特定の属性グループを表示または編集できるユーザーを制御できます。デフォルトでは、変更ロールの変更基本情報の表示権限および変更の編集/削除権限は、属性グループ・レベルで特に制御されない属性をユーザーが表示または編集できるかどうかを制御します。つまり、変更管理セキュリティを実装するときに、各属性グループの表示または編集権限を指定する必要はありません。
会社が仕入先と共同で次世代のデスクトップ・コンピュータ用の新しいマザーボードを設計しているとします。マザーボードの設計変更に関する仕入先との連絡を改善するために、仕入先および契約製造業者と変更要求情報を外部で安全に共有できるようにします。仕入先エンジニアは、特定の属性グループのみを表示できます。
変更管理の属性グループ・セキュリティを実装する手順
アプリケーション開発者職責を選択し、「フォーム機能」フォームにナビゲートして、属性グループの表示および編集権限を制御する各権限のフォーム機能を作成します。各フォーム機能の「オブジェクト」フィールドで、「変更」または「変更ライン」を指定します。
開発マネージャ職責を選択し、「設定」ワークベンチにナビゲートします。各属性グループの「属性グループ詳細」ページの「データ・セキュリティ」セクションで、「参照権限」および「編集権限」を指定します。
「変更ロール詳細」ページで、前のステップでフォーム機能として定義した権限を付与します。
変更管理の属性グループ・セキュリティの設定の詳細は、次のトピックおよび『Oracle Product Lifecycle Management User's Guide』または『Oracle Product Information Management Distribution Librarian User's Guide』を参照してください。
品目属性グループ・セキュリティの設定
カスタム権限の作成
ユーザー定義属性
ロールの管理
既存の変更ページにユーザー定義関数および処理を追加することで、独自のカスタム・ロジックを定義できます。このような場合、ページ全体をカスタマイズする必要はありません。
顧客固有のビジネス・ルールと計算を実行するためのユーザー定義関数を登録できます。これらの関数は、JavaまたはPL/SQLで作成できます。URL関数は、特定のパラメータの値をURL文字列に渡し、ユーザーを安全なページにリダイレクトします。関数ごとに、パラメータのリスト、データ型、およびパラメータ・タイプの指定による値の取得方法を登録する必要があります。
処理は関数のトリガー・ポイントであり、ボタンまたはリンクとして表示できます。ボタンまたはリンクの条件付き表示を決定し、ユーザーの入力に基づいてプロンプトを表示することもできます。
例: 変更タイプ属性のユーザー定義関数の実装
次の例は、属性グループ「実施原価」を使用して合計原価を計算する方法を示しています。
| 順序 | 属性グループ: 実施原価 | 属性グループ: 実施原価 | 属性グループ: 実施原価 | PL/SQL関数: 原価の計算 | PL/SQL関数: 原価の計算 | PL/SQL関数: 原価の計算 |
| 順序 | 属性名 | データ型 | マッピング属性とパラメータ | パラメータ名 | データ型 | パラメータ・タイプ |
| 1 | 仕入先価格 | Number | --à ---à ---à | 原価1 | Number | 入力 |
| 2 | 製造 | Number | --à ---à ---à | 原価2 | Number | 入力 |
| 3 | 設計 | Number | --à ---à ---à | 原価3 | Number | 入力 |
| 4 | フィールド/修理 | Number | --à ---à ---à | 原価4 | Number | 入力 |
| 5 | 実施原価合計 | Number | --à ---à ---à | 原価結果 | Number | 戻り値 |
まず、PL/SQLパッケージに存在するPL/SQLプロシージャに基づいて、PL/SQL関数「原価の計算」を全必須パラメータとともに登録します。
次に、「設変」変更オーダー・タイプにナビゲートし、「処理の更新」をクリックして属性グループ「実施原価」に処理を追加します。変更ページで関数が実行されます。処理を作成した後、関数パラメータを対応する属性にマップします。
「処理詳細」ページのマッピング・セクションには、関数パラメータのマッピング情報が表示されます。関数のパラメータをオブジェクトの主キー値（変更オブジェクトのCHANGE_IDなど）にマップすることもできます。
処理を設定する場合
処理を保護するロール・ベースの権限を指定します。
処理ボタンまたはリンクの表示前に満たす必要がある特定の条件が存在する場合は、動的表示制御関数（Javaでのみ記述）を処理に追加します。たとえば、1つまたはすべてのフィールドが空の場合、ユーザーには処理を実行するためのボタンまたはリンクは表示されません。
特定の条件に応じてボタンまたはリンクのラベルを変更する必要がある場合は、動的プロンプト関数（Javaでのみ記述）を処理に追加します。たとえば、「実施原価合計」属性が空の場合、ボタン・ラベルは「適用」になります。それ以外の場合、ボタン・ラベルは「変更の適用」になります。
重要: 動的プロンプト関数および動的表示制御関数のパラメータも、対応する属性にマップする必要があります。
関数を実行するための属性グループへの処理の関連付け
変更タイプ属性ページに表示される処理ボタン
関連項目
『Oracle Product Lifecycle Management User's Guide』または『Oracle Product Information Management Distribution Librarian User's Guide』の品目のユーザー定義関数の実装に関する項
基準テンプレートを使用すると、頻繁に使用する検索基準を保存し、特定の属性および属性値の保存済リストとして使用できる方法が基本的に提供されます。管理者が作成する基準テンプレートは、すべてのユーザーで使用可能であり、懸案、変更要求および変更オーダーの検索が迅速化されるため、検索基準の指定および頻繁な変更管理検索の実行に要する時間を節約できます。
ユーザーは私用目的で基準テンプレートを作成することもできます。実際には、ユーザーと管理者の両方が特定の変更カテゴリのデフォルト基準テンプレートを定義すると、ユーザー定義基準テンプレートが優先されます。
基準テンプレートにはユーザー定義属性が含まれているため、常に変更カテゴリのコンテキストで定義する必要があります。必要な数の基準テンプレートを定義し、最もよく使用されるものをデフォルト基準テンプレートとして表示することもできます。たとえば、未処理の変更要求、自分の懸案または計画済変更オーダーをすばやく検索する基準テンプレートを定義できます。
結果書式を使用すると、変更カテゴリごとに検索結果ビューを事前定義できます。これらのビューを使用すると、検索によって返される変更オブジェクト（懸案、変更要求、変更オーダーなど）ごとに異なる属性のセットを参照できます。管理者とユーザーの両方が結果書式を作成できます。管理者が作成した結果書式は、すべてのユーザーが使用できます。ユーザーが作成した結果書式は、作成したユーザーのみが使用できます。必要な数の結果書式を定義し、最もよく使用されるものをデフォルト結果書式として表示することもできます。
結果書式定義に基本属性またはユーザー定義属性を含めることができます。検索結果のセクションに直接リンクする表示セクションを結果書式に含めることができます。これにより、ユーザー定義変更タイプ・ページ（原価情報など）へのリンクを検索結果に表示できます。「ライン」、「添付」、「処理ログ」、「承認」、「承認履歴」、「依存」、「改訂」および「個人」の標準表示セクションのいずれかを表示することもできます。
原価情報結果書式を使用した変更要求検索結果
変更管理レポートは、基本的にはユーザーが保存、参照、Eメール送信または印刷できる検索基準と表示書式です。すべての変更管理カテゴリのレポートを作成できます。レポートを順に、または要約ビューを使用して参照することもできます。レポートを順に参照すると、レポート内の各変更オブジェクトを順に実行できます。要約ビューには、表の列形式でレポートが表示されます。登録済仕入先と顧客を含む他のユーザーにレポートを送信できます。
管理者は、システムのユーザーが実行した最も一般的または頻繁な検索のレポートを作成できます。これは、実装されるビジネス・プロセスに基づきます。これらの管理者定義レポートにより、一般ユーザーは、変更カテゴリ、検索基準および表示書式を選択し、同じ検索を何度も繰り返す時間を節約できます。レポートに意味のある名前を付けることもできます。たとえば、高優先度の未処理懸案をすべて検索すると、多数の懸案が作成される可能性があり、各懸案は懸案名と番号で識別されます。次の図に示すように、これらの検索結果のレポートに「高優先度の未処理懸案レポート」という名前を付けることができます。
レポート・セキュリティは検索セキュリティと一致します。ユーザーは、必要なロールを持っている変更オブジェクトにのみアクセスできます。管理者が作成したレポートはすべてのユーザーが使用できますが、これらのレポートを編集できるのは管理者のみです。
高優先度の懸案レポート
