シリーズ：【元ベンダーが教える】小売システム導入 成功の法則 第六回
～きれいな提案書ほど、書かれていない部分に注意する～
前回は、
という、少し耳の痛い話をしました。
プロジェクト責任者が決まっていない。
現場が置き去りになっている。
要望に優先順位がない。
意思決定が何度もひっくり返る。
そして、
「問題が起きたらベンダーが何とかしてくれる」
と思っている。
こうした状態では、どんなに優秀なシステムを選んでも、導入がうまくいかない可能性があります。
では、実際にベンダーを選ぶ段階では、何を見ればいいのでしょうか。
今回取り上げたいのが、
「ベンダーの提案書」
です。
小売業のシステム導入では、複数のベンダーから提案書が提出されます。
何十ページ、場合によっては百ページを超えることもあります。
会社概要。
システム構成。
機能一覧。
導入スケジュール。
体制。
費用。
導入実績。
サポート体制。
どの提案書も立派です。
そして、どの会社も、
「当社なら御社の課題を解決できます」
という内容になっています。
しかし、元ベンダーの立場から言わせてもらうと、
提案書は「書いてあること」だけを読んではいけません。
むしろ、
「何が書かれていないのか」
を見ることが重要です。
今回は、私なら必ず確認する5つのポイントについてお話しします。
そもそも、提案書は何のためにあるのか
最初に、提案書について少し考えてみましょう。
RFPをベンダーに渡す。
↓
ベンダーが内容を確認する。
↓
自社の製品やサービスを組み合わせる。
↓
「当社ならこう解決できます」という提案を作る。
これが基本的な流れです。
つまり提案書とは、
「この会社に発注してください」とお願いする営業資料
でもあります。
ですから、当然ですが、
ベンダーは自社の良いところを強調します。
これは悪いことではありません。
営業活動なのですから、当然です。
しかし、買い手である小売企業側は、
提案書を「営業資料」として読むだけでは不十分です。
「この会社に任せた場合、本当にプロジェクトは成立するのか？」
という視点で読まなければなりません。
1．まず見るべきは「自社の課題を本当に理解しているか」
私が最初に見るのは、
機能一覧ではありません。
「課題認識」です。
提案書の最初の方に、
「お客様の課題」
「今回の導入目的」
「現状分析」
などが書かれていると思います。
ここをよく読んでください。
そして、
「このベンダーは、本当に私たちの会社のことを理解しているのだろうか？」
と考えてみます。
例えば、食品スーパーがRFPを出したとします。
課題として、
「発注業務の効率化」
「在庫精度の向上」
「店舗作業時間の削減」
などを挙げたとします。
それに対して提案書が、
「AIを活用した自動発注機能」
「最新のクラウド基盤」
「スマートフォン対応」
「豊富な分析機能」
ばかりを説明していたら、少し注意が必要です。
なぜなら、
「その機能を使って、あなたの会社の何を解決するのか」
が見えていないからです。
「AIがあります」ではなく「何が変わるのか」
例えば、
「AIによる需要予測を搭載しています。」
これは機能の説明です。
しかし、本当に知りたいのは、
「そのAIによって、店舗の発注担当者の仕事がどう変わるのか？」
です。
例えば、
「発注時間を1店舗あたり1日30分削減できます。」
「欠品率を○％改善することを目指します。」
「発注担当者は、AIが提案した数量を確認する仕事に変わります。」
ここまで説明されていれば、
「なるほど。この機能を導入する意味がある。」
と分かります。
つまり、
機能 → 業務 → 効果
がつながっているかを見るのです。
2．「標準機能」と「カスタマイズ」を必ず分けて見る
これは非常に重要です。
提案書には、
「対応可能」
「実現可能」
「標準対応」
「追加開発」
など、さまざまな表現が出てきます。
しかし、
「できる」と「標準でできる」は全く違います。
例えば、
「現在利用しているシステムと同様の発注処理が可能です。」
と書いてある。
一見すると、
「今と同じことができるんだ。」
と思います。
ところが実際には、
「標準機能ではできません。個別開発が必要です。」
という可能性があります。
これを契約前に確認しておかないと、
後になって、
「この機能は追加費用になります。」
という話になります。
「できます」の後ろに何が隠れているか
ベンダーに、
「この機能は標準機能ですか？」
と聞いてください。
さらに、
「標準機能でなければ、追加開発費はいくらくらいですか？」
と聞きます。
そしてもう一つ、
「将来のバージョンアップで、そのカスタマイズ部分はどうなりますか？」
と聞いてみてください。
ここまで聞くと、
「できる」という言葉の意味がかなり明確になります。
3．提案書の「前提条件」を見逃さない
私が提案書を見るときに、かなり注意していたのが、
「前提条件」
です。
提案書の最後の方や、細かい注記に、
「○○を前提とします。」
「○○はお客様にてご準備いただきます。」
「○○については対象外となります。」
といった記述が入っていることがあります。
これは非常に重要です。
なぜなら、
ここに「追加費用」や「お客様側の作業」が隠れていることがある
からです。
例えばデータ移行
新しいシステムに移行するとき、
「既存データを移行します。」
と書かれていたとします。
ここだけ見ると安心です。
しかし、
「データのクレンジングはお客様側で実施するものとします。」
と書かれていたらどうでしょう。
商品マスターが10万件ある。
取引先マスターもある。
店舗マスターもある。
過去の売上データもある。
そのデータを整理するのは誰でしょうか。
当然、人手が必要です。
場合によっては、
何か月もかかります。
だから、
「データ移行対応」
という一言だけで安心してはいけません。
「どこまでがベンダーの仕事なのか」
を確認する必要があります。
4．スケジュールは「日付」ではなく「作業」を見る
提案書には、
立派なスケジュール表が載っています。
例えば、
4月 要件定義
5月 設計
6月 開発
7月 テスト
8月 教育
9月 本稼働
という具合です。
見た目は非常に分かりやすい。
しかし、私は、
「この日付で本当にできるのか？」
を考えます。
例えば、
「店舗教育：2週間」
と書いてあったとします。
100店舗ある会社で、
2週間で本当に教育できるでしょうか。
店舗の店長だけなのか。
発注担当者も含むのか。
パート・アルバイトも含むのか。
教育資料は誰が作るのか。
問い合わせ対応は誰がするのか。
ここまで考えなければ、
「2週間」という数字だけでは何も分かりません。
「テスト期間」が短すぎないか
小売システムで特に重要なのが、
テストです。
商品マスター。
価格。
発注。
入荷。
売上。
在庫。
棚卸。
請求。
EDI。
会計。
など、
システム同士がつながっている場合、
一つの機能だけテストしても意味がありません。
実際の業務の流れを通して確認する必要があります。
それなのに、
「テスト期間：2週間」
などとなっていたら、
私はかなり気になります。
もちろん、システムの規模や対象範囲によります。
しかし、
「このテスト期間で、何を確認するのですか？」
と質問してみるべきです。
5．一番重要なのは「リスクと課題」が書いてあるか
ここが、今回の記事で一番伝えたいところです。
提案書を見て、
「素晴らしいシステムですね。」
「これなら何でもできそうですね。」
と思ったら、
最後に一度、
「このプロジェクトのリスクは何ですか？」
と考えてみてください。
そして、提案書の中に、
リスクについて書かれているか
を見てください。
完璧な提案書は存在しない
システム導入には、
必ずリスクがあります。
データ移行が難しい。
既存システムとの連携が複雑。
店舗ごとに業務が違う。
現場教育に時間がかかる。
古い機器との接続が必要。
ネットワーク環境に問題がある。
こうした問題があるのに、
「当社のシステムならすべて問題ありません。」
と書かれていたら、
むしろ私は心配になります。
なぜなら、
リスクを認識していないのか、認識しているけれど書いていないのか
分からないからです。
私なら「一番難しいところ」を聞く
コンペの場で、私はこう質問することをおすすめします。
「今回のプロジェクトで、御社が一番難しいと考えている部分はどこですか？」
これは非常に良い質問です。
ベンダーが、
「特にありません。」
と言うのか。
それとも、
「商品マスターの移行が一番難しいと考えています。」
「店舗ごとの運用差が大きいので、ここがポイントです。」
「既存EDIとの接続に注意が必要です。」
と具体的に答えるのか。
ここに、
そのベンダーがどれだけ案件を理解しているか
が表れます。
提案書を「比較表」だけで評価してはいけない
小売企業では、ベンダー選定のために評価表を作ることがあります。
例えば、
| 評価項目 | A社 | B社 | C社 |
|---|---|---|---|
| 機能 | 90 | 85 | 80 |
| 価格 | 80 | 90 | 85 |
| 実績 | 95 | 80 | 90 |
| 提案内容 | 90 | 85 | 80 |
| サポート | 85 | 80 | 90 |
こうして点数をつける。
これは非常に分かりやすい方法です。
しかし、
数字だけでは見えないものがあります。
例えば、
A社は、
「機能が多い」
「価格が安い」
「実績も豊富」
でも、
「カスタマイズが多い。」
B社は、
「機能は少し劣る」
「価格も少し高い」
でも、
「標準機能中心で導入できる。」
どちらが良いでしょうか。
ここは、
5年後、10年後まで考える必要があります。
提案書の「ページ数」に惑わされない
もう一つ、
意外と重要なのが、
提案書のページ数です。
100ページあるから優れている。
20ページだから手抜き。
そんなことはありません。
むしろ、
「何でも説明しようとして、非常に分厚い提案書になっている」
こともあります。
逆に、
「重要なポイントだけを簡潔にまとめている」
提案書もあります。
大切なのはページ数ではありません。
「自社の課題に対して、何をどう解決するのかが明確か」
です。
私が提案書を見るなら、この5つを確認する
ここまでの話をまとめると、私なら次の5つを重点的に見ます。
① 自社の課題を正しく理解しているか
「機能の説明」ではなく、
「自社の何を解決するのか」
を見る。
② 標準機能とカスタマイズが明確か
「できます」だけではなく、
「標準なのか、追加開発なのか」
を確認する。
③ 前提条件・対象外が明確か
特に、
データ移行、教育、機器、ネットワーク、他システム連携
などは要注意です。
④ スケジュールに無理がないか
日付だけではなく、
「その期間で何をするのか」
を見る。
⑤ リスクを正直に書いているか
これが非常に重要です。
問題点を認識しているベンダーの方が、私は信用できます。
そして、もう一つ「提案書に書いていないこと」を聞く
実は、ここまで確認してもまだ足りません。
最後に、
「提案書に書かれていないけれど、今回のプロジェクトで注意すべきことはありますか？」
と聞いてみてください。
これはかなり本質的な質問です。
提案書は、正式な営業資料です。
当然、表現にも制約があります。
だからこそ、
口頭で何を説明するのか
が重要になります。
ここでベンダーから、
「実は一つ気になっていることがあります。」
と話が出てきたら、
そこを掘り下げてください。
「都合の悪いこと」を説明するベンダーは信用できる
例えば、
「この機能は他社製品の方が優れています。」
「この部分は標準機能では対応できません。」
「このスケジュールは少し厳しいです。」
「現場の業務を一部変えていただく必要があります。」
こんな話が出てくる。
私は、
こういうベンダーを信用します。
なぜなら、
契約を取ることだけを考えているのではなく、
導入後のことまで考えている可能性が高い
からです。
ベンダー側からすると、提案書は「約束」に近い
これは、発注側にもぜひ知っておいてほしいことです。
ベンダーが提案書に書いたことは、
契約や要件定義の中で、
「言った」「言わない」
の話になることがあります。
だから、ベンダー側も、
提案書に何を書くかは非常に慎重です。
逆に言えば、
提案書に書かれている内容は、後で必ず確認すべきもの
でもあります。
「この機能は提案書に書いてありますよね。」
「この作業は御社の範囲ですよね。」
という話にならないよう、
契約前に、
何が含まれていて、何が含まれていないのか
を明確にしておくことが大切です。
「提案書」だけでなく「見積書」も一緒に見る
そして、もう一つ。
提案書だけを読んではいけません。
見積書とセットで見る
ことをおすすめします。
例えば提案書には、
「店舗教育を実施します。」
と書いてある。
ところが見積書を見ると、
教育費用が含まれていない。
これは確認が必要です。
あるいは、
「データ移行を支援します。」
と書いてある。
でも、
見積書では、
「データ移行費：別途」
となっている。
こういうことがあります。
どちらが正しいのか。
契約前に確認しておかなければなりません。
「安い提案書」が一番安いとは限らない
ベンダー選定では、
価格も重要です。
しかし、
見積金額だけを比較するのは危険です。
A社：1億円
B社：1億2,000万円
C社：9,000万円
だったとします。
一見すると、
C社が一番安い。
しかし、
C社は、
データ移行が別料金。
店舗教育が別料金。
追加開発が別料金。
本稼働後のサポートも別料金。
という可能性があります。
一方、
A社は、
それらがすべて含まれている。
すると、
「9,000万円」が本当に安いのか分かりません。
だから、
総額だけではなく、何が含まれているのか
を見る必要があります。
提案書は「完成品」ではない
ここも大切です。
RFPに対する提案書は、
まだプロジェクトのスタート地点です。
契約後には、
要件定義があります。
詳細設計があります。
データ移行設計があります。
テストがあります。
そして、
実際の店舗運用を詰めていきます。
つまり、
提案書に書かれていることが、そのまま最終仕様になるわけではありません。
だからこそ、
「提案書に書いてあるから安心」
ではなく、
「提案書の内容を、契約後にどう具体化していくのか」
まで確認しておく必要があります。
良い提案書とは「夢」を見せるだけではない
ベンダーの提案書には、
未来の店舗の姿が描かれています。
AI。
クラウド。
スマートフォン。
自動発注。
リアルタイム分析。
データ活用。
どれも魅力的です。
もちろん、
未来を描くことは大切です。
しかし、
本当に良い提案書は、
「夢」だけではありません。
「そこに到達するまでに何が必要なのか」
まで書かれています。
例えば、
「AI発注を導入します。」
だけではなく、
「そのためには商品マスターを整備します。」
「過去データを整理します。」
「店舗の発注ルールを統一します。」
「最初は人が確認しながら運用します。」
ここまで書かれていれば、
かなり現実的です。
まとめ
ベンダーの提案書を見るとき、
つい、
「どんな機能があるのか？」
「価格はいくらなのか？」
「どんな最新技術が使われているのか？」
に目が行きます。
もちろん、それも大切です。
しかし、元ベンダーとして私がおすすめしたいのは、
「本当にこの会社は、私たちのプロジェクトを理解しているのか？」
という視点で読むことです。
そのために、
提案書で必ず見る5つ
① 自社の課題を正しく理解しているか
② 標準機能とカスタマイズが明確か
③ 前提条件・対象外が明確か
④ スケジュールに無理がないか
⑤ リスクを正直に書いているか
この5つを確認してみてください。
そして、最後にもう一つ。
ベンダーに、
「今回のプロジェクトで、一番心配していることは何ですか？」
と聞いてみてください。
その答えには、
提案書だけでは分からない、
ベンダーの本音
が隠れているかもしれません。
提案書を読んで、
「すごいシステムだな」
と思ったら、そこで一度読むのを止めてください。
そして、
「で、私たちの会社の仕事は、明日から何が変わるんだろう？」
と考えてみてください。
システムの機能が100個増えても、
店舗の仕事が楽にならなければ意味がありません。
最新のAIが搭載されていても、
現場が使えなければ意味がありません。
立派なクラウドシステムでも、
商品マスターがぐちゃぐちゃなら、期待した結果は出ません。
システム導入で大切なのは、
「何を買うか」ではなく、「導入した結果、会社の仕事をどう変えるのか」
です。
提案書は、その答えを見つけるための資料として読んでみてください。
そして、
「書いてあること」だけではなく、「書いていないこと」にも目を向けてください。
そこに、ベンダー選定の大きなヒントが隠れていることがあります。
次回は、
「デモを見て感動してはいけない理由」
です。
ベンダーが行うデモを見ると
「おお、すごい！」
「今のシステムよりずっと便利そうだ。」
「これなら現場も喜びそうだ。」
と思ってしまいます。
しかし、元ベンダーの立場から一つだけ言わせてもらうと、
デモを見て感動しただけで、ベンダーを決めてはいけません。
なぜなら、
デモは「うまくいく場面」を見せるためのものだからです。
では、デモでは何をどのように見てベンダーの本当の実力を
判断すれば良いのかについて
元ベンダーの視点からお話ししたいと思います。
コメント