間違いだらけのベンダー・マネジメント ～ユーザとベンダーが築く「いい感じの関係」とは？
こんにちは。製造業の情シスマネージャーの「まさ」です。
ユーザー企業の情シスの方でベンダー企業とトラブルになった経験をお持ちの方はいませんか？私も過去何度も経験しました。
ベンダー選定やベンダー企業との関係性は、情シスやDX推進者が頭を悩ませるテーマの一つです。特に自社システムを内製オンリーで構築してきた（ウチのような）ユーザー企業では、ベンダー選定の方法や役割分担、付き合い方のノウハウがなく、ベンダーとトラブルになり、プロジェクト自体が頓挫することが良くあります。
今回は、ユーザー企業側から見た「ベンダーとの付き合い方」と、ベンダー企業側から見た「付き合っていきたいユーザ企業/こんなユーザー企業とは付き合いたくない」という観点を踏まえ、「ベンダー・エンゲージメント」という理想的な関係性について考えてみました。
※この記事は、自分の経験（IT業界と情シスの両方）を元に、両者がハッピーでいい感じの関係になるにはどうしたら良いか？というゴールに向けた考察をしながら、同じ想いを持った情シスの方に「なるほどね」と共感していただきたくて書いたものです。ベンダーとユーザーの対立を煽ったり、どちらが正しいかを論じるつもりは全くありませんので悪しからず！
▶ベンダーが本気で提案したい企業
まずはベンダー企業側の視点から。自分がIT業界にいた頃、ユーザー企業に対して何百枚何千枚という提案書を作ってプレゼンしてきました。
そんな中で、ベンダー企業の立場で「こんな企業に導入してもらい、一緒に課題解決のお手伝いをしたい」と本気で思ったユーザー企業のプロフィール、担当者の方の思考や行動を挙げてみました。
ネームバリューがあり世の中から信頼されている大企業
小規模でも業界内でニッチな製品やサービスを提供している企業
経営課題や業務課題が明確で、変革に対する意識がある
必要な情報はちゃんと開示してくれるオープンな雰囲気である
ダメなものはダメとはっきり言ってくれる。変な駆け引きをしない
1～2は、ある程度WebサイトやIRレポートなどの公開情報で収集できます。その情報から営業さんは案件の優先順位をつけるために次のような判断基準を付けます。パッケージやクラウドサービスのベンダーであれば、名の通った企業の採用事例は喉から手が出るほど欲しく、提案の優先順位が上がるのも当然ですね。
その企業がどの程度IT投資に積極的か？
売上含めた経営状況は好調か？
その会社のシステム状況や導入済の製品やソリューションは何か
また、Web会議や訪問をを通じて3～5について有無を確認します。ユーザー企業の皆さんは、ベンダー・ヒアリングを通じて次のような「ベンダーが案件の優先順位をつけるための判断材料」を提供していることを認識しておくと良いでしょう。
会社としての本気度はどれくらいか？
予算は取られているのか？
提案しようとしている商材は本当の意味で課題解決に適しているか？
出入りのベンダーが競合製品を扱っていないか？
これは一般的にベンダー企業が実施している事です。 これらがクリアされたときに晴れて「ベンダーが本気で提案したいと思うユーザ企業」にリストアップされるのです。
情シスの皆さん、あなたの会社や依頼した提案は「ベンダーにとって優先順位が低いリスト外の存在」になっていませんか？
もうその時点でベンダー企業からは有益な情報は引き出せなく、自社にとってメリットのある提案など受ける事すらできないことを理解しましょう。
▶ベンダーが距離を置きたい企業
次に、そういった第一関門をクリアした案件には第2の関門が待ち受けるのです。
例え十分な予算がなくても、企業の業績が多少悪くても、それでもベンダー企業の営業さんは、提案内容に工夫を凝らし、様々なメリットを考えたうえでコンペに参加します。
ところが、そのコンペの対応で「いやもう、この案件は撤退しよう」「このユーザー企業とは距離を置こう」と思われてしまう事もあります。 続いて、自分が営業やプリセールスSEをしていた時の経験をもとに、ベンダー企業が距離を置きたくなる、ユーザー企業のNGな思考や行動を挙げてみました。
1.ITの知識がなくリテラシーが低い。要件を言語化、文書化できない
2.窓口の方の発言が二転三転する。何度も見積もりを出させる
3.発注側だぞという上から目線の態度が表に出ている
4.約束されない「ウチと付き合う将来的なメリット」を語る
5.事務手続きがお役所的で異様に煩雑
・---------
「1.ITの知識がなくリテラシーが低い。要件を言語化、文書化できない」は結構多かったです。このタイプは「稟議を通すためにその資料作成を無償でベンダーに作らせよう」という魂胆が見え隠れします。プロジェクト開始後の追加見積も同様です。ベンダー提案やユーザーが本来作成すべきドキュメントの作成は無償サービスではないです。ユーザー企業の皆さん、システム企画書、稟議書、現状システムの課題や構成、ユーザ要求仕様は自分で作りましょうね。
・---------
「2.窓口の方の発言が二転三転する。何度も見積もりを出させる」これも多かったです。窓口の方は礼儀正しくてとても感じの良い人なんです。でも権限が全くないんです。プロジェクト開始後に顧客要求仕様が二転三転し、いつまで経っても仕様確定しないのもこれに関連する事象です。ユーザー企業側のスキルと体制が問われています。
・---------
「5.約束されない「ウチと付き合う将来的なメリット」を語る」
かなりの高等戦術です。ネゴが大好きなやり手の部長課長が窓口の時にさく裂します。「この案件を踏み台にしてもっと大きな基幹システムの案件に関われるぞ」なんてことを言います。これは裏を返すと「最初は利益最小限でやってね」の値引きアピールです。利益放棄でもやりたいベンダーさんはどうぞ、と言う感じになります。
以下のnoteに書かれていることくらいはユーザー側でやりましょう。
▶ユーザーが付き合いたくないベンダー
今度は、ユーザー企業や情シスの目線からのお話です。
ITのプロジェクトを成功させるためには、ユーザー企業とベンダー企業の良好な関係が不可欠です。しかし、残念ながら、ユーザー企業から見て「お付き合いしたくない、安心してお願いできないベンダー企業」も存在します。私は、そういったベンダー企業の特徴や行動を、自分の経験に基づいていくつか挙げさせていただきました。
1.ユーザ企業の課題に寄り添うことなく「線引き」からはいる
プロジェクトで課題が出たときには、プロとしての経験値や他企業での事例をもとにアドバイスや選択肢を与えてほしいのですが、そうではなく、最初から役割分担や契約条件、自社パッケージの仕様や制限事項などを強調するベンダー企業がいます。ユーザー企業からしたら「いやそんなこと知ってますから」と言いたくなりますね。ユーザー企業の課題に対してできる範囲で寄り添ってほしいのに。
2.見積根拠や仕様を説明できない、伝言役でしかない営業マン
ベンダー企業の営業マンは、自社の製品やサービスについて詳しく知っていると思いがちですが、そうではない場合もあります。見積もりや仕様書を渡されても、その内容や根拠を説明できない、技術者や上司に聞いてからでないと回答できないという営業マンがいます。
3.電話とメールだけ？昔ながらのプロジェクト進行スタイル
プロジェクト開始後に発覚するあるあるですが、定例会という名の資料説明とエビデンス承認をもらうためだけの1時間の会議を行ったり、Teamsなど効率的なコミュニケーションツールを避けて電話とメールに固執したりするケースがあります。ユーザー側がコミュニケーションツールを用意しているにも関わらず、営業さんが電話で事前ネゴを必ずしてきたり、関係者を外してメールで個別に要件確認をしてくるベンダーさんには「もっと効率良くオープンに議論しましょう」と優しく突っ込みを入れてます。
▶間違いだらけのベンダー・マネジメント
繰り返しますが、プロジェクトを成功させるためには、ユーザー企業とベンダー企業の良好な関係が不可欠です。しかし残念ながら、ユーザー企業側にも「ベンダー・マネジメント」という言葉にとらわれ、自分の立ち位置やメンツを守りたいためだけにベンダー企業に対して不適切な態度や圧力をかける人もいます。私は、そういった、ユーザ企業とベンダー企業間のねじ曲がった力関係や不要なトラブルをなくしたいのです。
・--------
「CIO／IT責任者が語る、DX時代を打ち勝つための30の提言」という本を紹介します。この本は、大手企業のCIO（最高情報責任者）がDXを推進するために必要な取り組みを「30の提言」としてまとめています。第7章では「ベンダー・マネジメントの重要性」について、次のような提言があります。
①提案やソリューションの選定では、ユーザーの過度の期待や思い込みは禁物。実物を確認しながら「何ができるか」と「何がしたいか」を詰めること
②「技術的にできる」と「自社で運用できる」「予算内でできる」は別物であることをユーザー側は認識すること
③ベンダーは、役割分担という盾を過剰に使わず、顧客目線で対応すること
④最終的には、ユーザーは、ベンダーを「マネジメントする」のではなく、対等な「ベンダー・エンゲージメント」の関係を構築すること
▶ベンダー・エンゲージメントを目指そう！
私は、この本に書かれている「ベンダー・エンゲージメント」が、ユーザ企業の情シス/IT部門がベンダー企業と信頼関係を築きWin-Winの関係になるために必要な考え方だと思います。
ベンダー・エンゲージメントでは、ユーザーとベンダーは対等です。
そこで、私は「ベンダー・エンゲージメント」に基づいて、情シスがやるべきことや振る舞いを考えてみました。
①プロジェクトでは対等。丸投げ無茶ぶりはNG。ユーザーの役割を果たせ
書籍の提言の通りですので解説は省略します。
（①提案やソリューションの選定では、ユーザーの過度の期待や思い込みは禁物。実物を確認しながら「何ができるか」と「何がしたいか」を詰めるこ②「技術的にできる」と「自社で運用できる」「予算内でできる」は別物であることをユーザー側は認識すること）
②ユーザコミュニティなどでベンダーと情報交換する
パッケージやクラウドサービスには「ユーザ会」や「ユーザコミュニティ」があります。ユーザー企業は、そこでベンダーの考えや製品の将来像を理解し、自社の課題解決のヒントを探るべきです。
③導入後はサポートを利用し、ベンダーのナレッジ蓄積に貢献する
課題やトラブルに対して、情シスが自力解決するのではなく、ベンダーに伝えることで、製品やサービスの改善につながります。ベンダーと一緒に製品やサービスを育てる感覚が大切です。ベンダー企業もそれを望んでいます。
いかがでしょうか？
IT技術が高度化かつ多様化している現状、情シスはベンダーとコミュニケーションをとり、自己開示をして「ベンダーとの良好な関係」を構築しましょう。
そのためには、情シス部門同士が横のつながりを持ち、ベンダー企業を紹介したり、ベンダー企業が主催するユーザーコミュニティに参加したりすることが必要です。
そして何よりも、情シス部門自身が考え方や働き方を変革していかなければいけない時代になったことを認識しましょう。他社の情シス部門との情報交換やベンダー企業との積極的な関係作り、コミュニティへの参加など、働き方をアップデートして社内の課題解決に貢献しましょう！
この記事が気に入ったらサポートをしてみませんか？