統合対オーケストレーション：本当にツールを減らす必要があるのか？

レベニューリーダーがようやく肥大化したスタックを真剣に見つめたとき、最初の本能はほぼ常に削減です。重複したツールを取り除き、一つのスイートに標準化し、ベンダーリストを縮小し、予算を取り戻す。統合は決然としているように感じられます。ログインが減り、請求書が減り、壊れるものが減る。それが正しい判断であることもあります。しかし私たちは、いくつかのチームが徹底的に統合を行い、結果として、置き換えた肥大化したスタックと同じくらい機能不全なままの、より軽量なスタックにたどり着くのを見てきました。

「どうすればツールを減らせるか」よりも重要な問いは、「どうすれば持っているツールを一つのシステムのように振る舞わせられるか」です。この二つは似ているように聞こえます。しかし、まったく異なる計画につながります。統合は数の話です。オーケストレーションは連携の話です。

統合が解決するもの、しないもの

統合はツールの数を減らします。通常は複数のカテゴリーをカバーするスイートを採用するか、重複するポイントソリューションを廃止することによってです。そのメリットは本物です。管理するベンダーが減り、ライセンスの無駄が減り、統合ポイントが減り（これはインテグレーション税を実際に削減します）、それを使う人々にとってより標準化された体験になります。

しかしそれには上限があり、コストもあります。単一のスイートがすべてのカテゴリーでベストインクラスであることはめったにないため、利便性と引き換えに一部のケイパビリティを犠牲にすることになります。より大きな問題は、統合が連携を保証しないということです。あるベンダーのスイート全体を購入しても、モジュール同士がきれいにデータを共有しないことに気づくかもしれません。単一のプラットフォームの中でもデータサイロが存続するのを見ることになるかもしれません。たまたま同じロゴを共有しているだけの、貧弱に接続された画面の間を担当者が行き来し続けることもあり得ます。ツールの数が少ないことは、まとまりのあるシステムであることと同じではありません。

ロックインの問題もあります。モノリシックなスイートは適応させるのが難しいものです。あなたの動きが変わる必要があるとき、あなたは一つのベンダーのロードマップを待つことになります。分断のカオスを、囲い込まれた庭園の制約と交換したことになり、私たちの経験では、人々はそれが2年後にどれだけ痛むかを過小評価しています。

代わりにオーケストレーションが行うこと

オーケストレーションは異なる問いから始まります。ツールはどれだけうまく連携しているか、そして、よりうまく連携させるために何が欠けているか。オーケストレーション層はツールの上に位置し、それらのデータを一つの共有モデルに引き込み、それらをまたいでアクションを動かします。スタックの中にいくつの製品があろうと、それは一つのシステムとして振る舞います。

この転換は、その形にあります。分断されたスタックはメッシュであり、すべてのツールが他のすべてのツールと接続し、インテグレーション税は組み合わせ的に増大します。オーケストレーション化されたスタックはハブです。すべてのツールは連携層に一度だけ接続し、複雑さは線形のままです。ツールを追加することは、十数個の接続ではなく一つの接続を意味します。

そして専門化されたツールを手放す必要はありません。これこそがベストオブブリードが最悪のカオスに変わることを防ぐものです。カテゴリーをリードするケイパビリティを維持しながら、その全体にわたる一貫性を得るのです。それはまた、統一されたデータを実際に有用なものにし、散らばったシグナルをネクストベストアクションへと変え、実際に仕事が行われる場所でそれを提示します。

正しいレバーを選ぶ

この2つは互いに排他的ではなく、ほとんどの優れたスタック戦略は両方を使います。しかし、それぞれが異なる問題を解決するので、レバーを症状に合わせてください。

明らかな重複があり、複数のツールが同じ仕事をしているなら統合しましょう。ゾンビライセンスや使われていないソフトウェアに支払っているなら統合しましょう。重複するツールが意味のある違いを持たず、一方を失っても何もコストがかからないなら統合しましょう。

ツールが個々には価値があるのにデータやワークフローを共有していないならオーケストレーションしましょう。担当者が一日中システムを手作業で調整しているスウィーベルチェア問題にあるならオーケストレーションしましょう。ギャップを埋めるためにシャドウスプレッドシートが湧いて出ているならオーケストレーションしましょう。そして、柔軟性を保ちたく、一つのベンダーのロードマップに動きを賭けたくないならオーケストレーションしましょう。

たいていうまくいく順序はこうです。まず真の重複と無駄を取り除くために統合し、次に残ったものが一つとして機能するようにオーケストレーションする。連携させずに削減すれば、同じ分断のより小さなバージョンが残るだけであり、それはしばしば、そもそもあなたのレベニュースタックが分断していく本当の根本原因です。

目標はツールを減らすことでは決してなかった

一歩下がってみれば、かなりシンプルです。誰もツールの数を減らすこと自体を望んではいません。データが流れ、チームが数字に合意し、意思決定が速く信頼でき、担当者がソフトウェアの子守ではなく販売をするレベニューエンジンを望んでいるのです。ツールの数は手段です。

統合は死重を取り除くことで助けになります。連携こそが実際にまとまりのあるエンジンを実現するものであり、それこそがレベニューオーケストレーションです。スタックを最小化すべき製品の山としてではなく、運用すべきシステムとして扱うことです。

主なポイント

• 統合は数を減らす。オーケストレーションは連携を改善する。それぞれ異なる問題に対する異なる解決策である。
• 統合は支出と重複を削減するが、単一のスイートの中にもサイロが存在しうるし、一つのロードマップにロックインされることになる。
• オーケストレーションはツールの上に連携層を追加し、すべてのツールが一度だけ接続することで複雑さを線形に保つ。
• まず統合して本当の重複を取り除き、次に生き残ったものをオーケストレーションする。
• 目標はまとまりのあるレベニューエンジンである。ツールの数が少なくなることは、せいぜい副次的な効果にすぎない。

ツールを削減すべきか接続すべきか迷っているなら、より本質的な問いは、スタックをどう一つのシステムとして振る舞わせるかであり、それこそがレベニューオーケストレーションの目的そのものです。