すべての承認が最後の承認を待つ必要はない

なぜ重要なのか：ガントチャートの錯覚

プロジェクト管理の考え方のほとんどは、ガントチャートによって形成されています。ガントチャートは、作業を時間軸に沿って伸びる一連の棒グラフとして示し、各タスクは前のタスクが終了したところから始まり、プロジェクトは左から右へと直線的に進みていきます。これは、高レベルの計画には便利なツールです。しかし、実際の作業の進め方を表すモデルとしては不適切です。

実際のレビュー作業は、整然とした順序で進むわけではありません。複数の関係者が、同じプロジェクトの異なる部分を同時に作業しています。意思決定は予測不可能な順序で発生します。一部のタスクはすぐに完了しますが、解決に時間を要する複雑な問題が発生することもあります。作業は基本的に並行して行われ、動的です。

ガントチャートの錯覚とは、直線的な計画を描くことで作業が直線的に進むという思い込みのことです。そうではありません。ガントチャートは、ツールに架空のモデルを強制し、チームにその架空の実行を強制するだけです。レビュー担当者は、実際には必要のない引き継ぎを待つことになります。

プロジェクト マネージャーは、実際の、並行した、複雑なプロセスを、クリーンで順序立てられた図に無理やり当てはめようと日々奮闘しています。サイクル タイムは長くなり、スループットは低下します。計画は壁にはきれいに見えますが、実際にはうまくいきません。

これは、コンプライアンス レビューやあらゆるクリエイティブ承認ワークフローで最も痛ましい形で現れます。典型的な小売プロモーション資産を考えてみましょう。

• クリエイティブ チームはレイアウトを承認する必要があります。
• ブランドは視覚的な一貫性を確認する必要があります。
• 法務は開示を承認する必要があります。
• 規制は管轄区域のコンプライアンスを確認する必要があります。
• 価格設定は価格を確認する必要があります。
• マーチャンダイジングは掲載されている製品を確認する必要があります。

シーケンシャル ワークフローでは、これらのレビューはそれぞれ前のレビューを待ちます。クリエイティブ チームが完了すると、ブランド、法務、規制、価格設定、マーチャンダイジングへと進みます。各ハンドオフで遅延が発生します。各レビュー担当者は自分の番を待ちます。壁に貼られたガントチャートには、こうあるべきだと書いてある。しかし、実際の作業は、そうする必要がないことを物語っている。

これらのレビューのほとんどは、ほぼ独立して行われる。ブランドの一貫性は、法務部門が最初にレビューを行うかどうかに依存しない。価格設定の正確さは、規制当局が承認するかどうかに依存しない。唯一の真の依存関係は、全員が承認するまで生産を開始できないことかもしれない。それ以外はすべて、ツールによって押し付けられた誤った順序、つまりガン​​トチャートの錯覚である。

Parallel Approval Flowsは、この錯覚を取り除く。ブランド、法務、規制、価格設定、マーチャンダイジングの各チームは、すべて同時にレビューを開始し、それぞれのペースで作業を進め、完了した時点で完了する。プロジェクトは、すべてのパスを順次加算した合計ではなく、最も遅い実際のパスだけを待つ。

あらゆる規模のコンテンツプログラムを実行している組織にとって、その効果は増幅される。5日かかっていた逐次的なワークフローは、1日か2日に短縮される。キャンペーンのスループットを制限していたサイクルタイムは、キャンペーンのスループットを増幅する要因となる。

並列フローの仕組み

単一の Aproove プロジェクト内で、並列承認ワークフローは複数の同時実行パスに分岐できます。各パスは、以下の独自のワークフロー ステップのシリーズです。

• ステップごとに設定可能なレビュー担当者とステークホルダー。
• ステップごとに設定可能な決定ルール (全員一致、多数決、単一承認者)。
• ステップごとに設定可能な期限。
• ステップごとに設定可能なエスカレーション ルールと競合マネージャーの割り当て。
• パス自体に決定駆動型のサブ ルートが含まれる内部分岐ロジック。

プラットフォームは並列タスク リリースをサポートしており、複数の同時実行ステップのタスクはシリアル化されるのではなく、同時に実行されます。マルチ バッチ ワークフロー ロジックにより、プロジェクト内の異なるコンテンツを異なるペースで進めることができます。フロー バッチ セクション分割アクションを使用すると、定義された境界 (セクション、コンポーネント、またはメタデータ駆動値) に沿ってプロジェクトを独立した処理パスに分割できます。各パスは、設計が収束ステップに呼び戻すまで、独自のワークフローとして進行します。

プロジェクト レベルの監査証跡は、すべての並行パスにわたるアクティビティを 1 つのレコードに記録します。必要なすべてのパスが完了すると、プロジェクトが進みます。順序は関係ありません。

並行フローを使用するタイミング

顧客が一般的に使用する 3 つのパターン:

単一のアセットに対する多機能レビュー。 ブランド、法務、規制、および運用レビュー担当者は、出荷前にアセットを承認する必要があります。いずれも開始に他の担当者を必要としません。すべて並行して実行されます。すべてのチェーンが完了すると、アセットが出荷されます。

同じプロジェクトにわたる複数バージョンのレビュー。 単一のプロジェクトには、アセットの複数のバリアント (異なる市場、異なる顧客セグメント、異なる製品ライン) が含まれる場合があります。各バリアントは、すべて並行して実行される独自の承認チェーンを持つことができます。 12 の市場向けのキャンペーンでは、12 の並行レビュー チェーンがあり、各市場のレビュー担当者は自分のバージョンに集中できます。

1 つのドキュメントで複数のチームが並行して作業します。 異なるチームが、大きなドキュメントの異なるセクションを担当します。各セクションには独自のワークフロー チェーンがあり、関連するチームは自分のセクションのみをレビューします。すべてのセクションがクリアされると、ドキュメントの準備が整います。

どのパターンでも、原則は同じです。何が本当に何を待つ必要があるかを特定し、残りを並行して実行します。

実際の依存関係と誤ったシーケンス

並行とは、構造化されていないという意味ではありません。Aproove のワークフロー エンジンは、実際の依存関係を、並列パスを処理するのと同じ方法で、構成によって処理します。あるチェーンが別のチェーンに実際に依存している場合 (法的承認が製品リリースに先行する必要がある)、その依存関係はワークフロー設計にエンコードされます。別のチェーンに依存するチェーンは、その前のチェーンが完了するまで待機します。それ以外のすべては並行して実行されます。

規律は設計にあります。どの依存関係が実在し、どの依存関係が偽りであるかを識別することです。実在する依存関係は保護されます。偽りの順序は削除されます。その結果、ツールの想定速度ではなく、作業速度で実行されるワークフローが実現します。

メリット

• サイクルタイムが短縮されます。 直列化すると数日かかるレビューが、並列化すると数時間で完了します。
• チームは各自のペースで作業できます。 自分たちに影響のない作業が終わるのを他のチームが待つ必要がなくなります。
• 誤った条件がなくなります。 プラットフォームは、作業に実際には存在しない順序を強制しなくなります。
• 実際の依存関係が維持されます。 依存関係が実際のものである場合、ワークフローは引き続き直列化できます。並列処理は非構造化を意味するものではありません。
• 各チェーンは独立して構成されます。決定ルール、期限、エスカレーション、およびコンフリクトマネージャーは、各チェーン内のステップごとに調整されます。
• プロジェクトダッシュボードには全体像が表示されます。すべてのチェーンの状態が一目でわかります。‍
• コンフリクト解決はチェーンごとに行われます。1つのチェーンでのコンフリクトは、他のチェーンをブロックしません。

対象者

• サイクルタイムが重要な指標となるレビュープログラムを実施しているマーケティングオペレーションリーダー。
• 複数の専門家によるレビューでアセットを承認する必要があり、現在、連続レビューがボトルネックとなっているコンプライアンスおよび規制プログラム。
• 多くの市場、地域、または同じキャンペーンのバリエーションにわたるレビューを管理しているブランドガバナンスチーム。
• レビューの厳格さを損なわずにサイクルタイムを短縮しようとしているプロジェクトおよびプログラムマネージャー。‍
• 「これは誤った順序を強制しないか」という観点からワークフロープラットフォームを評価しているオペレーションリーダー。

内部構造

並列承認フローは、Aprooveのワークフローエンジンによって実装されています。このエンジンは、分岐ワークフロー、マルチバッチ処理、およびセクションレベルのワークフロー分割をネイティブにサポートしています。ワークフローは、複数のパスを同時に実行するように構成でき、各パスには独自のステップ、ステップグループ、決定ルール、およびステップレベルでの競合マネージャの割り当てがあります。マルチバッチワークフロー設定により、異なるコンテンツバッチが単一のロックされたユニットとして移動するのではなく、ワークフローを独立して進めることができます。フローバッチセクション分割アクションを使用すると、ワークフローは定義された境界（セクション、コンポーネント、またはメタデータ駆動値）に沿ってコンテンツを並列処理パスに分割できます。並列タスクリリースは、複数の同時実行ステップのタスクを直列化するのではなく、同時に実行します。パスレベルの依存関係は、必要に応じてワークフローアクションによって構成され、あるパスの開始を別のパスの完了時にゲートします。監査証跡は、パス固有のイベントとプロジェクトレベルのイベントをキャプチャし、パスごと、または統合されたプロジェクトレコードとして決定チェーンを再構築できるようにします。