マルチベンダーのパッケージ組み合わせを成功させる方法

最近よくあるベンダー提案プレゼン

「弊社の販売管理パッケージとB社の経費精算パッケージの組み合わせを提案いたします」

あるベンダー提案プレゼンで、ベンダーのA社とB社が一堂に会し、それぞれの営業担当者が説明しました。

体制図を見ると、A社とB社が横並びで連携し、提供する業務領域によって、担当が分かれています。

実は、このような複数ベンダーによる提案は珍しくありません。

近年では、基幹システムのパッケージは出揃っています。それぞれのパッケージの強みを組み合わせて、システムを構築する手法は、もはや常套手段といえます。

実際に、私もこの「販売管理システム＋経費精算システム」の組み合わせは、実に4回目となります。

しかし、この複数ベンダーでのプロジェクトは、難易度が少し上がります。

正直に言えば、痛い目にあってきました。

この複数ベンダーならではのリスクとは何でしょうか？

連携不足による悪循環

お互いのベンダーは、まったく別の会社です。アサインされたメンバーは「今回初めて一緒にやる」方がほとんどでしょう。

そのため、お互いがどのように進めるかもわからない中、信頼関係の構築もこれから、という状況です。

この状況で発生する問題は、次の1点に集約されます。

ベンダー間の横連携が薄い。

これが、次々と具体的な課題に発展していくのです。

① 自社の打ち合わせ工数がふくれ上がる

「えっ？A社から聞いてないの？」
「そこはベンダー同士で決めればいいのに、なぜウチに聞くの？」

ベンダー間の横連携が薄いと、自発的にベンダー間でコミュニケーションをとりません。

すると、自社を通じて伝言ゲームのような状況が発生します。

自社がいる場でしか、ベンダー同士が会わないことも増えてきます。

そのため、ベンダー間の連携を増やそうと、自社が頑張って打ち合わせを設定します。自社がいないと、ベンダー間の連携ができない悪循環に陥ります。

こうして、自社は打ち合わせ三昧となり、打ち合わせだけで1日が終わっていきます。それ以外のタスクが滞っていき、夜遅くまで残業が慢性化し、疲弊していきます。

② サブシステム間連携で品質が不足する

それぞれのパッケージシステムは、お互いがサブシステムとしてデータ連携が欠かせません。

マスタデータの連携やトランザクションの連携、設定の引継ぎなどは、きちんとベンダー間で仕様をすり合わせしないと、データ連携でバグが発生します。

コード値の統一、桁数、初期値の相違などは、その代表例です。

③ システム全体の操作性が悪くなる

システム全体として設計しないと、マスタデータや設定の二重入力が発生します。

本来であれば、システム間でデータ連携を行えばよいだけです。

また、画面への入力ポリシーの違いや、項目名の相違など、細かい部分でシステム間の相違が発生します。

そうなると、ユーザー側で項目名を読み替えたり、操作方法を意識して変えたりしないといけなくなります。

システム全体としてきちんと設計されていないと、ユーザーにとって操作性が悪くなり、大きなストレスを与えてしまいます。

④ グレーゾーンの対応で追加費用が増える

お互いのベンダーが自分たちのサブシステムだけで進めていると、その境界線で考慮が漏れ、グレーゾーンが発生します。

受け入れテストでグレーゾーンのバグが発生し、ベンダーとしては「仕様変更」を主張してきます。ベンダー間でも責任をなすり合い、「要件定義書」を承認したユーザー側にも飛び火してきます。

ベンダー間で信頼関係があれば、協力して解決策を模索できるのですが、もはやそのような関係は望めません。

結果として、ユーザーが承認した要件定義書に書いていなかった追加対応となり、追加費用が発生します。

⑤ 相談窓口があいまいとなり、さらに遅れる

どちらのベンダーに聞いてよいか微妙な課題というのも、多く発生します。

そのたび、どちらのベンダーに確認したらよいか曖昧で、たらい回しとなり、解決までに時間を要します。

その結果、進捗がどんどん遅れていきます。

＊＊＊

ベンダー連携不足が末期状態になると、自社がいる場で仲裁しないとコミュニケーションがとれなくなります。

こうなると、自社が2つの異なるプロジェクトを「掛け持ち」しているようなものです。

自社の負担は2倍どころか、そこに起因する問題を解決するために、3倍、4倍とふくれ上がってしまうのです。

まず仕組みをつくり、その上に関係を構築する

これらの解決策は以下の通りです。

① 進捗会議は合同で行う

　ベンダーそれぞれでの「進捗会議」開催を許してはいけません。「合同開催」とし、お互いの進捗状況や課題の共有を行う場を作っていきます。

② ベンダー間でどう連携をとるのか明確なルールをつくる

　ユーザーが介入しなくても、横連携される仕組みを促します。具体的には、ユーザーが参加しないベンダー内部の定例会を開催させ、情報連携と関係性構築を行ってもらいます。

③ 最終責任と窓口をどちらか1本に絞ってもらう

　システム全体の設計に関する「責任」と「窓口」を一本化してもらいます。サブシステム間の考慮もれ、設計ミスはどちらかのベンダーに責任を帰属させ、全体設計に当事者意識をもってもらいます。

④ 問題発生時は両PMを集められるように関係構築する

　自社がそれぞれのベンダーPM（プロジェクトマネージャー）といつでも相談できる関係を構築します。そうすることで、何かあった場合に、両方のPMを集めて一気に「相談 → 解決」の流れにもっていけます。

＊＊＊

プロジェクトの終盤、受け入れテストで不具合が多発し、究極に苦しいときに頼れるのはベンダーのPMです。

やはり人間は「感情」に左右される生き物。

日々の関係性が悪ければ、苦しいときに助けてもらえません。

あえてグレーゾーンを拾いにきてはくれません。

一方で、お互いがリスペクトし合い、信頼し合っていれば、何か問題が発生したときに、グレーゾーンであっても当事者として対応してもらえます。

では、どうすればリスペクトしてもらえるのでしょうか？

それは、自社がベンダーに「丸投げ」しないことです。

丸投げするから、蚊帳の外に置かれます。

ベンダーは当事者意識のない人に構っている暇もなく、メリットもありません。

自社が当事者意識を丸出しで、プロジェクトを自ら推進していこうとするからこそ、ベンダーに頼られ、コミュニケーションが活性化し、その献身的な姿勢にリスペクトが生まれるのです。

そうなると、自社を助けるために、自発的にベンダー同士で話し合い、解決策を協議し、その選択肢を自社に提示してもらえます。

そもそも、マルチベンダーを統率するのは他でもなく自社です。

自社がリーダーシップを発揮して、率先してコミュニケーションをとっていくのは当然の話ではないでしょうか。

お互いがフォローし合うプロジェクト体制

「また後で相談してもよいですか？」

ある別の現場では、ベンダー2社と自社が集まっての3社による「合同進捗会議」を開催しています。その中で、A社のPMからB社のPMに相談を持ちかけています。

それを聞いた私も「その相談に私も混ぜてください！」と言いました。

「じゃあ、いつものURLで」とA社のPMが返します。

私はこの2人のPMをすごくリスペクトしていています。

打ち合わせしていると楽しいです。

脱線しまくって、なかなか仕事の話に入らないときもあります。

でも、お互いの連携で失敗するイメージはまったくありません。

お互いがフォローし合えば、何でも解決できる。そう感じさせてくれます。

複数ベンダーとのプロジェクトは、いつもこの状態を目指したいものです。

貴社のマルチベンダープロジェクトは、うまく横の連携がとれていますでしょうか？