製品・サービス パートナーシップ
顧客企業がソフトウェア製品を購入する場合、通常はそれらをインストールするための熟練したスタッフが必要です。このスタッフは通常、ソフトウェア製品ベンダーが独自のサービス部門を構築することがビジネスとして妥当ではないと考えるため、サービスプロバイダー企業によって提供されます。顧客は、製品ベンダーとサービスプロバイダーの関係を認識し、協力関係にある相手からその関係の透明性を求める必要があります。クラウドベンダーの台頭により、これらのパートナーシップがますます重要になるにつれて、透明性はますます重要になっています。
2020年2月13日
大企業(シェル、ユナイテッド航空、ウォルマートなど)のシニアITエグゼクティブであれば、ビジネスを管理するために大規模なソフトウェアシステムを導入する必要があります。多くの場合、このようなシステムを多くの企業に販売する *製品ベンダー*(SAP、オラクル、SalesForceなど)から購入することを選択するかもしれません。しかし、このような大企業向けのソフトウェアパッケージの購入は、クレジットカードを持ってアプリストアに立ち寄るほど簡単ではありません。このようなシステムは、インストール、設定、カスタマイズに多くの作業が必要です。自社のスタッフを訓練することもできますが、おそらく時間がかかりすぎるため、より経験豊富な別の企業のスタッフを利用する方が良いでしょう。そのため、大規模なソフトウェア *サービスプロバイダー*(アクセンチュア、ウィプロ、IBMなど)と協力する可能性が高いでしょう。
この記事では、ビジネス関係を単純な3つの役割モデルとして表現しています。この記事でこれらの名称を使用する場合、それらはこれらの種類の役割を指します。例として挙げている企業はすべて大企業ですが、中小企業もこれらの役割を担っています。
顧客
運用成果を向上させるために製品と関連サービスを購入する企業
ウォルマート、サウスウエスト航空、シティバンク
製品ベンダー
ソフトウェア製品を構築して販売する
SAP、オラクル、SalesForce
サービスプロバイダー
熟練したスタッフを通じて、ソフトウェアシステムの構築と設定を行う能力を販売する
アクセンチュア、インフォシス、Thoughtworks
このやり取りは非常に一般的であるため、製品ベンダーとソフトウェアサービス企業は、特定のインストールをサポートしたり、より広範なビジネスセグメント全体で顧客企業を追求したりするために協力することに合意するパートナーシップ契約を結ぶことがよくあります。
これらの取り決めは一般的ですが、十分に理解されているとは思いません。主にカスタムソフトウェア開発に従事しており、これらの影響がそれほど大きくないため、私は相対的な無知のリストに自分も含まれています。その無知は、それらを少し探求する理由の1つです。それらをよりよく理解するもう1つの理由は、クラウドコンピューティングへの移行に伴い、これらの種類の取り決めがカスタムソフトウェアの世界でより重要になっていることです。クラウドベンダーとの同様のパートナーシップ契約が、Thoughtworksのようなカスタムソフトウェアデリバリーに焦点を当てている企業に大きな影響を与えているのが現在見られます。
製品サービスのパートナーシップの最も単純なケースは、パートナーシップが単一の顧客エンゲージメントのために形成される場合です。この状況では、顧客が製品ベンダーに顧客が好むサービスプロバイダーと協力するように指示することによって、パートナーシップが形成される可能性があります。または、サービス企業と製品企業は、競合する製品サービスの組み合わせと競合する可能性のある機会を見つけたときに、パートナーシップを形成する可能性があります。
サービスプロバイダーと製品企業が長期的なパートナーシップ契約に合意した場合、事態はさらに複雑になります。ここでは、グローバルである場合も、特定のビジネスセクター(航空会社、銀行など)または地域(東アジアなど)に限定される場合もある、複数の顧客に有効な契約に合意します。
これらの取り決めに違いが生じる重要な要因は、関係する企業の規模です。小規模なサービスプロバイダーは、SAPとの関係がWiproとは異なります。まず、2つの大企業を想定してから、規模が異なる場合の相違点について説明します。
大企業には、パートナーシップに特化した部門があります。
両方の企業が大きい場合、パートナーシップ契約は通常、非独占的です。アクセンチュアのような企業は、SAPとオラクルの両方でERP作業を行い、実際には両方でかなりの作業を行います。それぞれに世界中の複数の顧客が関わっています。これらのパートナーシップの規模は、サービスプロバイダーが特定のパートナーのために組織全体を構築することがよくあることを意味します(2000年代半ば、IBMグローバルサービスには、SAPとの作業に特化した約20,000人のスタッフがいました)。
そのため、サービスプロバイダーには、そのセクターに焦点を当てた銀行部門と、オラクルのビジネスソフトウェアプラットフォームに焦点を当てたオラクル部門(これはデータベースソフトウェアとは全く異なるものです)がある可能性があります。銀行が人事システムの改革を検討している場合、銀行部門の担当者と話し合います。サービス企業のその部分の人々は、ソフトウェアベンダーから比較的独立しているように努めています。顧客がPeopleSoft(人事ソフトウェアを扱うオラクルの子会社)の実装を決定した場合、銀行の担当者は、作業の一部としてサービス企業のオラクル部門の人々を紹介するでしょう。
製品ベンダーの組織では、大規模なベンダーもパートナーとの作業に特化した組織を設けています。これにより、教育や製品ニュースの提供、営業活動の支援、デリバリー作業の調整が行われます。
どちらの場合も、パートナーシップ契約は単なる交渉と契約の締結だけではないことを覚えておくことが重要です。それは、維持するために継続的な努力を必要とする継続的な関係です。
製品ベンダーはなぜ独自のサービス部門を構築しないのですか?
製品ベンダーの観点から見ると、サービスプロバイダーは主にデリバリー組織として機能し、複雑なソフトウェア製品に必要なインストール、設定、カスタマイズを行うスタッフを提供します。製品ベンダーは、いくつかの理由から独自のデリバリー組織を構築することを好まない傾向があります。まず、作業は製品の販売と比較して利益率がはるかに低い傾向があるため、ベンダーは製品の改善と営業およびマーケティングのサポートに投資する方が良いでしょう。第二に、大規模なソフトウェア製品をインストールするプロジェクトは多くのリスクを伴う傾向があるため、製品ベンダーにとって、デリバリープロジェクトとの距離を置くことが重要です。このようにして、問題が発生した場合、責任を負うのはサービスプロバイダーです。
さらに財務上の理由は、収益認識の複雑な問題です。これは、貸借対照表にいくらかの収益を認識できるときに適用される法的および会計上の原則です。ソフトウェアを販売する場合、すぐに収益として計上されます。しかし、サービスを販売する場合、たとえ今日6ヶ月後の作業を行う契約を締結したとしても、その作業が6ヶ月後に完了するまで、その収益を会計に表示することはできません。ソフトウェアサービスと製品販売をバンドルした取引を販売する場合、ソフトウェア販売からの収益も6ヶ月間認識されないことを回避するのは困難です。これは、ソフトウェア販売とデリバリー作業の間に明確な境界線があることを製品ベンダーが確保するための相当なインセンティブであり、独立したサービスプロバイダーがいることでその境界線を明確に保つのに役立ちます。
デリバリー部門の成長の複雑さは、そのデリバリー組織が複数の企業からの製品を統合する必要がある場合に増幅します。ここで製品ベンダーは、自社のよく知られた製品に関連するすべてのリスクがあるだけでなく、他の企業からの追加のリスクがあり、その中には競争関係にある企業も含まれることに気づきます。
確かに、製品ベンダー企業は、顧客との関係を深めるために、サービス部門の構築を試みることはよくあります。そして、ほとんどの顧客は、問題が発生した場合に製品ベンダーへのより直接的な連絡手段があるため、製品ベンダーと直接作業する方が良いでしょう。しかし、一般的なパターンは、製品ベンダーが先に説明した問題に遭遇し、努力を中止するため、そのような努力は通常長続きしないように思われます。(IBMはこのパターンに対する顕著な例外です。)
もちろん、サービスプロバイダーは、専門家の時間に対する請求書発行のビジネスモデルに慣れているだけでなく、プロジェクトと顧客関係の管理の複雑さにも慣れています。彼らにとってパートナーシップの魅力は、より防御的なものです。製品インストールエンゲージメントの競争において、顧客は自然にソフトウェア製品の専門知識と接続を探します。パートナーシップ契約は、その保証を提供し、それが欠けていると疑問が生じます。
製品ベンダーは、認定資格を持つ専門スタッフを探しています。
製品に特化したサービスプロバイダーのスタッフの数は、関係の重要な部分です。ほとんどの製品ベンダーには、何らかの種類の製品認定トレーニングプログラムがあります。これらのプログラムの質はしばしば低いため、多くの認定を取得しても、当面の作業能力に対応するとは限りません。うまく運営されているトレーニングコースであっても、通常はより重要な幅広い技術原則ではなく、個々の製品の癖に焦点を当てる傾向があります。ソフトウェアの構築には多くの意思決定が必要であり、この種のトレーニングでは、ベンダーの製品を伴わない優れたアプローチについて話し合う可能性は低いです。認定目標は、パートナーシップ契約に頻繁に現れ、サービスプロバイダーの何人のスタッフがさまざまなレベルの認定を受けているかを示しています。認定トレーニングは製品ベンダーにとって収益であり、サービスプロバイダーのその関係へのコミットメントの指標であり、一般的な欠陥のすべてがあっても、これらのスタッフが少なくとも製品機能の基本的な知識を持っていることを保証します。
一部のパートナーシップには、手数料が含まれます。
一部のパートナーシップ契約には手数料が含まれており、どちらの方向にも進む可能性があります。作業(最初のプロジェクトまたは追加モジュールまたはプロジェクトをインストールするためのフォローアップ作業)を販売するサービスプロバイダーは、ソフトウェア販売について販売手数料を得る場合があります。同様に、サービス会社を紹介する製品ベンダーは、サービス会社の請求時間について手数料を得る場合があります。一部のサービスプロバイダーは、顧客中心のアドバイザリーサービスを維持するために、手数料を受け取らないことを約束しています。これは、複数の競合するソフトウェアベンダーと協力して作業を行っている場合、維持しやすくなります。
しかし、明示的な手数料がなくても、財務上のインセンティブは存在します。ソフトウェアベンダーは、サービスプロバイダーが影響を与えたと考える収益を配分することにより、通常、サービスプロバイダーをランク付けします。このランキングは、彼らの紹介や、サービスプロバイダーへの製品計画と技術サポートへのアクセス(そしておそらく影響力)の提供に影響を与えます。同様に、製品ベンダーと連携するサービスプロバイダー部門のリーダーは、売上がいくらで、その仕事の利益率がどれだけ高いかによって評価されます。
デリバリー業務に加えて、パートナーシップには、両社の製品ポジションを活用して両社の売上増加を図るための共同販売およびマーケティングキャンペーンが含まれることがよくあります。しかし、これらの努力は通常、あまり成果を生まないようです。最初の取引が成立するまでは、誰もゴー・トゥ・マーケット計画を信じません。たとえそうなったとしても、組織間の信頼はほとんどありません。このような取引がうまくいく場合、それは通常、特異な状況、多くの場合、関係者間の特に良好な協力関係に基づいています。両者は、パートナー組織の一部分しか扱っていないことを認識しなければなりません。サービスプロバイダーの他の部門は、製品ベースのデリバリー業務を販売するためだけに顧客関係を危険にさらしたくありません。製品会社の他の部門も、他のサービスプロバイダーとの関係を損ないたくありません。ビジネスの多くの場合と同様に、パートナーシップがどの程度円滑に機能するかは、主にパートナー組織の関係者間の個人的な関係の機能です。
サービスプロバイダーは利益相反に直面していますか?
サービスプロバイダーは、実装作業の実施とアドバイスの提供の両方のために雇われます。このアドバイスには、複雑なシステムのどのモジュールを実装するか、およびビジネス機能をサポートするためにどの製品を選択するかが含まれます。プロバイダーがこのアドバイスを提供する際はいつでも、顧客の最善の利益を考慮する必要があります。しかし、製品ベンダーとのパートナーシップは、利益相反をもたらします。この競合は、販売手数料が関与する場合に最も顕著です。年間業績評価でその放棄された収益が取り上げられる場合、コンサルタントが収益をもたらす製品に反対することを助言するのは困難です。
明示的な販売手数料がなくても、パートナーシップは影響を与える可能性があります。ベンダーは、サービスパートナーがどのくらいの収益に影響を与えたかに基づいて、サービスパートナーをランク付けします。顧客にパートナーの製品を勧めないことは、パートナーシップのレベルを低下させ、他の場所での販売の見込みを損なう可能性があります。
大規模なサービスプロバイダーと協力した私の情報筋は、これはほとんど問題ではないと感じていました。彼らは、この種のほとんどのアドバイザリー業務は、パートナーシップを管理するサービスプロバイダーの部門とは異なる部門によって行われていると指摘しました。サービスプロバイダーが複数の競合する製品ベンダーとパートナーシップを結んでいる場合、アドバイスを歪める傾向は大幅に減少します。
大手サービスプロバイダーは、中小規模の製品ベンダーとの独占契約を求めています。
これまで、大規模なサービスプロバイダーが大規模な製品ベンダーと提携する場合に焦点を当ててきました。異なる規模の企業を検討し始めると、いくつかの変化が現れます。最大の変化は排他性です。より小さいパートナーは、より大きなパートナーにとって重要性が低いため、少なくとも全体市場のサブセット(ビジネスセクターまたは地理的地域)については、そのパートナーと独占的に協力することに同意することがよくあります。
少なくともサービスプロバイダーにとっては、取引の目的も変化します。市場の力によって、小規模な製品ベンダーがサービスプロバイダーにとって必須になることはありません。したがって、パートナーシップを結ぶ理由は、製品がサービスビジネスにおいて重要な優位性を与えると考える場合です。その優位性への独占的なアクセス権を持つことで、その市場セグメントにおける他のサービスプロバイダーに対してより競争力を持つことができます。サービスプロバイダーは多くの場合、小規模な製品のスイートを構築し、多くの顧客との統合における経験を販売しようとします。
大規模なサービスプロバイダーは、製品戦略にさらに大きな影響力を及ぼし、サービスプロバイダーが顧客にとって重要と考えている機能を優先することもできます。彼らはまた、技術サポートの優先順位を高めることができます。
製品ベンダー側では、パートナーシップの理由は大企業と似ていますが、販売とマーケティングの側面の重みが大きくなります。特に大企業に販売する場合、販売およびマーケティング組織を設立することは高価です。サービスプロバイダーはすでに適切な連絡先を持っているので、独自の能力で彼らを感銘させることができれば、彼らはあなたのためにこの作業を行います。これらの顧客への直接アクセスを失い、サービスプロバイダーのサポートには多くの作業が必要になる可能性がありますが、ほとんどの企業にとって、そうする方がより良い取引です。顧客は、存続しない可能性があることを懸念しているため、小規模な製品ベンダーを警戒することがよくあります。大規模なサービス会社と提携することで、そのリスク(または少なくともその認識)を軽減できます。
同様に、大手製品ベンダーも中小規模のサービスプロバイダーとの独占契約を求めています。
不平等な規模は、逆にも機能します。小規模なサービスプロバイダーは大企業が持っている既存のリーチを持っていない一方で、製品ベンダーはサービス会社からはるかに高いレベルの整合性を得ることで利益を得ることができます。この整合性には、サービス会社が製品の擁護者であることを保証する独占が含まれることがよくあります。サービスプロバイダーの従業員が製品を批判することを解雇事由とする条項が含まれる場合もあります。この緊密な関係は、サービス会社からのより活発な販売努力と、製品ベンダーが顧客を紹介するためのコンサルティング料金のより大きな部分を占める能力につながる可能性があります。
クラウドの影響
大規模なクラウドベンダー(Amazon、Google、Microsoft)の台頭は、サービスプロバイダーとのパートナーシップの範囲を拡大しています。これは、カスタムソフトウェアを開発している企業にとって特に関連性があります。このセクターでは、パートナーシップ契約がしばらく前から存在していました。特に、開発スタックの使用におけるMicrosoftとのパートナーシップ、および大規模なデータベースベンダーとのパートナーシップです。しかし、オープンソースツールを使用するためのかなりの余地もあり、言語やフレームワークに関するベンダーとのパートナーシップの必要性を回避しました。
大規模なクラウドでは、これはもはや当てはまりません。カスタムソフトウェアは、クラウドベンダーのスタック上で実行するように設計されることが増しており、利用可能なサービスとその効果的な使用方法に関する詳細な知識が必要です。インフラストラクチャ管理をそれを得意とする企業に移行することで多くのメリットがありますが、その影響はソフトウェアに関わるすべての人に及びます。サービスプロバイダーが少なくともこれらのベンダーの1社とのパートナーシップを結ぶ必要性を回避することはほとんど不可能です。
クラウドビジネスモデルは、パートナー評価の財務面に追加のひねりを加えます。ソフトウェアベンダーの場合、収益は主にライセンスから得られ、ライセンス料金が支払われると、収益の側面は確定します。しかし、クラウドは従量制モデルを提供します。手数料がなくても、サービスプロバイダーは生成する収益によって評価されるため、いくつかの難しいインセンティブを設定します。多くのセンサーからのアラートを処理するシステムを設計する場合、クラウドベンダーとのパートナーシップがすべての信号を送信するように促しているときに、処理コストを削減するためにセンサーがクラウドにのみアラートを送信するようにプログラムしますか?
顧客にとっての意味
サービスプロバイダーまたは製品ベンダーの顧客である場合、これらのパートナーシップ契約の仕組みを理解する必要があります。実際、それはあなたに期待されています。サービスプロバイダーが顧客にアドバイスを提供する場合、ベンダーとのサービスプロバイダーのパートナーシップが利益相反であるかどうかについて、ある情報源に質問しました。彼らは、顧客のCTOがこのゲームのやり方を理解しているため、そのような競合について心配する必要はないと答えた。
透明性は、重要な最初のステップです。顧客は、パートナーがパートナーシップの条件を明確にすることを要求する必要があります。そうすることで、顧客はパートナーシップが顧客の利益にどのように合致するのかを判断できます。販売手数料が含まれている場合は、顧客に開示する必要があります。そうすることで、パートナーからの発言をどのように解釈するかを知ることができます。これは、サービスプロバイダーが製品ベンダーの商品導入と範囲に影響を与えるアドバイザーとして機能している場合に不可欠です。
大規模なサービスプロバイダーで働いていた私の情報筋は、複数の競合するベンダーと提携していたため、パートナーシップが利益相反につながるとは考えていませんでした。もし私が顧客なら、懐疑的でしょう。特に、さまざまな製品ベンダーとのパートナーシップ契約の性質を知る必要があり、パートナーと競合する非パートナー製品ベンダーに関するアドバイスには注意する必要があります。
パートナーが一緒にプロジェクトに取り組んでいる場合、各パートナーがそれぞれ何に責任があるか、そして紛争をどのように解決するかを明確にすることが重要です。この責任の割り当ては、顧客にも明確にする必要があります。そうすることで、顧客は問題の解決に誰に連絡すればよいかを知ることができます。責任の明確な範囲がない場合は、警告信号です。これらのことが早期に解決されなければ、後で努力が困難に遭遇した場合、事態は悪化するだけです。
製品会社からの、サービスプロバイダーのスタッフに認定トレーニングへの参加を義務付ける圧力は、製品の表面的な機能には精通しているが、基礎となる技術原理には精通していないスタッフにつながる可能性があります。これは、表面的な能力につながり、結果として効果の低いデリバリーにつながる可能性があります。顧客は、認定資格によって能力を判断することに警戒し、代わりに、技術的な問題をより深く理解しているスタッフを探る必要があります。適切な状況で製品の代替手段を構築できるほど深く理解しているスタッフです。
賢明なサービスプロバイダーまたは製品ベンダーは、作業の長期的な成功を確実にするためには、単に製品を出荷したり、人々の時間を販売したりするのではなく、顧客のパフォーマンスの向上に焦点を当てる必要があることに気づいています。現在の時代の精神として、彼らは成果をアウトプットよりも重視する必要があるのです。しかし、組織をこのように構築するのは困難です。サービスプロバイダーは通常、従業員時間(アウトプット)で請求しますが、これは顧客の成果とはあまり一致しません。これが起こる理由は、成果に結びついた財務指標を考案すること、ましてやベンダーの貢献をそれに割り当てることははるかに困難であるためです。これが直接的な顧客関係の問題である場合、製品とサービスのパートナーシップではさらに困難です。避けられない結果は、パートナーシップ取引の成功の中核となる評価が製品とサービスのアウトプットに基づいており、顧客の成果がさらに背景に押しやられることです。パートナーがパートナーシップの管理を心配するにつれて、パートナーのいずれかが顧客の成果を理解することに投資する可能性のあるエネルギーは減少します。
サービスと製品のパートナーシップは、ITの世界では数十年前から存在していますが、クラウドコンピューティングの台頭により、その重要性が増しています。ソフトウェアサービス企業は、主要なクラウドベンダーとどのように連携するかを検討する必要があり、通常はパートナーシップ契約が締結されます。顧客はこれを認識し、サービスプロバイダーとクラウドベンダーの両方から透明性を求める必要があります。企業のデジタル化が進むにつれて、重要なサプライヤーがどのように機能しているかを明確に理解する必要があります。
謝辞
この記事の作成にあたり、パートナーシップ、特に以前の雇用主とのパートナーシップにおいて、より直接的な経験を持つThoughtworksの同僚の協力を得ました。Aschwin Beurskens氏、Gagan Madan氏、Gavin Ni氏、George Earle氏、Paul Sagar氏、Stuart Deignan氏には、経験を共有していただきました。Alexandre Goedert氏、Gabriel Gavasso氏、Ian Cartwright氏、Jayesh Ghatge氏、Mike Mason氏、Rebecca Parsons氏、Unmesh Joshi氏には、社内メーリングリストで記事のドラフトについて議論していただきました。
重要な改訂
2020年2月13日: 初版公開