変更プロセスの柔軟性の利点
このサマリーでは、変更プロセスの柔軟性 (拡張リリースロジック)変更プロセスの追加の柔軟性 (段階)という 2 つのプロセスを使用して変更タスクを個別に管理およびリリースする効率性を高めるために設計された、さまざまな利点と新機能について説明します。
シーケンスを使用した変更タスクの実装 (段階化なし)
シーケンスを使用して段階化なしで変更タスクを実装した場合の利点は次のとおりです。
新しく開始する変更タスクに実績開始日を設定して、実装を開始できます。
シーケンスは数値順で連続的に実行され、それと並行して空白 (ゼロ) のシーケンスが実行されます。
キャンセルされた変更タスクは実装が開始されなくなり、スキップされます。これにより、ワークフロー全体がより効率的になります。
* 
状態設定オプションを使用して、変更タスクの実装をキャンセルできます。
シーケンスと段階を使用した変更タスクの実行
シーケンスと段階を使用して変更タスクを実装した場合の利点は次のとおりです。
段階のサポート - 段階を使用するように変更通知ワークフローを設計できます
プリファレンス: 「順序制御付き計画の実行順序」「段階的計画の実行」
段階とシーケンスのオプションを設定することで、変更タスクを実装できます。これらのプリファレンスでは実装オプションを、シーケンスのみ、段階のみ、またはその両方から選択できます。
同期ロボットを使用して 1 つの段階を実行するようにワークフローを設計できます。
これらのプリファレンスは、空白 (ゼロ) シーケンスと並行して番号順で変更タスクを実装することをサポートしています。
実績開始日は、変更タスクの実装が開始されると設定されます。
拡張リリースロジック
拡張リリースロジックを使用して変更タスクを実装した場合の利点は次のとおりです。
段階に対する変更対象オブジェクトをリリースするために使用される新しい releaseChangeable2 API。
releaseChangeable2 API には、段階における未採用の変更の承認が組み込まれています。
段階に割り当てられた変更タスク (特殊なケースでは空白) のみがリリース処理の対象になります。
段階内で個別にリリースされた変更タスクはスキップされます。
最終段階である「リリース後」リリースでは、releaseChangeable2 API を使用して変更通知全体がリリースされます。
API によって残りのすべての変更タスクがリリースされ、変更タスクと変更通知の実績終了日が設定されます。
保留中のエフェクティビティは、単一の段階に対して処理されます。
変更タスクの検証
検証は、単一の変更タスク、変更通知の段階、または変更通知全体に対して実行できます。拡張リリースロジックの有効化:
変更通知ワークフローは、ワークフロー変数を使用して、拡張リリースロジックを有効にします。
以前にリリースされた変更タスク (実績終了日が設定されているもの) またはキャンセルされた変更タスクは、検証中はスキップされます。
変更タスクのリリース
拡張リリースロジックを使用して変更タスクをリリースした場合の利点は次のとおりです。
実績終了日は、リリース方法 (個別、段階、または完全な変更通知) にかかわらず、リリースされるすべての変更タスクに対して設定されます。
releaseChangeable2 API は、変更タスクをリリースする際に実績終了日を設定します。
releaseChangeable2 API には、未採用の変更の承認が組み込まれています。
保留中のエフェクティビティの処理
拡張リリースロジックを使用して保留中のエフェクティビティを処理した場合の利点は次のとおりです。
処理は、単一の変更タスク、変更通知の段階、または変更通知全体のコンテキストで実行できます。
変更タスクがリリース (実績終了日が設定) されると、保留中のエフェクティビティを適用できるようになります。
キャンセルされた変更タスクはスキップされます。
以前に適用された保留中のエフェクティビティは、再度処理されることはありません。
解決日の設定
拡張リリースロジックを使用して、変更タスクと変更通知の解決日を設定できます。
解決日は、変更通知と単一の変更タスク、または段階にスケジュールされているすべての変更タスクに対して設定できます。
解決日が以前に設定されている場合、その設定が上書きされることはありません。
解決日は、変更通知の新しいリビジョンおよび改訂された変更タスクではリセットされます。
実績終了日は、変更通知の新しいリビジョンおよび改訂された変更タスクではリセットされます。
これは役に立ちましたか?