インテグレーション税：ツールを繋ぎ合わせることの本当のコスト

断片化したレベニュースタックを持つすべての企業は、誰も申し込んだ覚えのない税金を払っています。請求書もベンダーも更新日もないため、予算レビューで話題に上ることは決してありません。しかしそれは、どんなサブスクリプションにも劣らず現実のものであり、私たちが見てきた多くのチームにとって、それはソフトウェア支出そのものより大きなものです。これがインテグレーション税、つまり断絶したツールをあたかも1つのシステムであるかのように振る舞わせ続けるための、継続的なコストです。

CRM、エンゲージメントプラットフォーム、エンリッチメントベンダー、アトリビューションツール、CSプラットフォームがそれぞれ異なる言語を話すとき、誰かが翻訳しなければなりません。あるときはそれがミドルウェアとカスタムコードであり、あるときは誰かがタブ間でフィールドをコピーする作業です。いずれにせよ、それは継続的にお金と時間と信頼性を消費し、その額はスタックがどれだけ断片化しているかに比例します。

その起源

この税には、見た目以上に悪化させる数学的な根っこがあります。ツールを接続することは線形の問題ではありません。むしろ組み合わせ的な問題に近く、システム間の可能な接続の数は、システムの数よりもはるかに速く増加するからです。数個のツールであれば、ホワイトボードに描けるようなウェブになります。10数個になると、それを構築した本人であるオペレーション担当者を含め、誰も完全には理解できないもつれになります。

それらの接続の1つひとつは、構築され、テストされ、監視され、修理されなければなりません。これは、なぜ自社のレベニュースタックは分断しているのかの直接的な帰結です。新しいポイントソリューションを1つ追加するたびに、それ自体が加わるだけでなく、既存のツールへの接続もすべて追加されるのです。

その請求書の内訳

この税は4つの場所で支払われており、そのほとんどは公式な予算の外側にあります。

ミドルウェアとツーリング。システム間でデータを移動させるiPaaSプラットフォーム、コネクタ、ワークフロー自動化ツールには、それ自体のサブスクリプションコストがあります。これは税を減らすために払う税であり、接続の数に応じて拡大します。

エンジニアリング時間。カスタムインテグレーションを構築するには開発者が必要であり、さらに費用がかかるのは、それを動かし続けることです。APIは変わり、スキーマはずれ、エッジケースは増殖します。最初の構築は安い部分です。本当のコストは永続的な保守にあり、それは同期ジョブを所有する誰かの肩にのしかかります。

脆さ。継ぎ接ぎされたインテグレーションは壊れます。ベンダーがエンドポイントを更新し、同期が静かに失敗し、フィールドマッピングがずれ、突然案件が流れなくなり、データが古びます。フォーキャストが間違うまで、誰も気づきません。見逃されたシグナルと悪い意思決定という形でのこれらの失敗のコストは、直接的な保守コストの上に積み重なります。

人間によるフォールバック。自動化されたインテグレーションが高すぎるか脆すぎる場合、フォールバックは人間になります。レップとオペレーションスタッフが手作業でデータを移動させます。これは最も純粋で最も高くつく形のスイベルチェア問題です。また、ソフトウェア監査には決して現れないツール乱立コストの見えない大部分でもあります。

なぜ複利的に増えるのか

厄介なのは、ツールを追加するのをやめても、この税が時間とともに増え続けることです。インテグレーションは劣化します。すべてのAPIバージョンアップ、すべてのスキーマ変更、すべてのベンダー買収が、あなたがすでに構築した接続を脅かします。じっとしているだけでも、既存の配管が漏れないようにするために継続的な投資が必要になります。

そして、インテグレーションはデータを移動させるだけで、その意味を統一しないため、根本的な断片化はそのまま残り、ただそれを覆い隠す速度が上がるだけです。「案件」を異なる方法で定義する2つのシステムは、どれだけ確実に同期させても、食い違い続けます。これが、この税が根強いデータサイロと共存し続ける理由です。あなたは、実質を得ることなく、連携しているように見せかけるためにお金を払い続けることになります。

ツールを削るだけではない削減方法

分かりやすい対応策は、ツールを取り除きウェブを縮小することです。ツールが減れば、インテグレーションが減り、税も下がります。それが正しい場合もあります。しかし私たちの経験では、統合だけでは通常、ある問題を別の問題に置き換えるにすぎません。柔軟性を、6つのことをそこそこにこなすスイートと引き換えにするだけです。より深い解決策は、インテグレーション問題の形そのものを変えることです。

ポイントツーポイントのインテグレーションはメッシュです。すべてのツールが他のすべてのツールと接続し、複雑性が爆発的に増加します。オーケストレーションレイヤーはそのトポロジーをハブに変えます。すべてのツールは、単一の統合されたモデルを維持する共有の調整レイヤーに一度だけ接続すればよく、組み合わせ的な爆発は線形なものへと収束します。新しいツールを追加することは、10数個の接続ではなく、1つの接続を意味するようになります。

この転換こそが、永遠にインテグレーション税を払い続けることと、それを構造的に削減することの違いです。これは統合対オーケストレーションという問いが重要である大きな理由であり、なぜオーケストレーションが通常、力任せのツール削減に勝るのかという理由でもあります。

主なポイント

• インテグレーション税とは、断絶したツールを1つのシステムであるかのように振る舞わせ続けるための、継続的かつ予算外のコストである。
• それは組み合わせ的に増加する。接続はツールよりもはるかに速く増殖する。
• 請求書は4つの部分から成る。ミドルウェア、エンジニアリング時間、脆さ、そして手作業を行う人間である。
• インテグレーションは劣化し、データを同期させてもシステムが物事を異なる方法で定義しているという事実は決して解決されないため、この税は複利的に増える。
• ポイントツーポイントのメッシュからハブへ移行することで、増分的にではなく構造的に税を削減できる。

ツール間の配管を動かし続けることに、Go-to-Marketのモーションそのものを改善するより多くのエネルギーを費やしているなら、トポロジーを見直す価値があります。レベニューオーケストレーションプラットフォームは、脆いポイントツーポイントの同期を、すべてが一度だけ接続する1つのレイヤーに置き換えます。