シリーズ：【元ベンダーが教える】小売システム導入 成功の法則 第七回
～「すごい！」と思ったシステムが、現場では使われないこともある～
前回は、
というテーマで、提案書を見るときには、機能や価格だけではなく、
- 自社の課題を理解しているか
- 標準機能とカスタマイズが明確か
- 前提条件は何か
- スケジュールに無理がないか
- リスクを正直に書いているか
を見ることが大切だというお話をしました。
今回は、その続きです。
ベンダーの提案を受けると、次に行われるのが、
「デモ」
です。
実際のシステム画面を見せてもらい、
「この画面から発注できます。」
「在庫もリアルタイムで確認できます。」
「AIが自動的に発注数量を提案します。」
「スマートフォンからでも操作できます。」
そんな説明を聞きながら、実際にシステムを操作してみる。
すると、
「おお、すごい！」
「今のシステムよりずっと便利そうだ。」
「これなら現場も喜びそうだ。」
と思ってしまいます。
もちろん、システムの進化を実際に目で見て確認することは重要です。
しかし、元ベンダーの立場から一つだけ言わせてもらうと、
デモを見て感動しただけで、ベンダーを決めてはいけません。
なぜなら、
デモは「うまくいく場面」を見せるためのものだからです。
デモは「一番うまくいくところ」を見せている
少しベンダー側の事情をお話ししましょう。
ベンダーがコンペでデモをするとき、
当然ですが、何度も練習します。
どの画面を見せるか。
どの順番で説明するか。
どこで実際に操作してもらうか。
どんな質問が来るか。
あらかじめ想定します。
そして、
一番システムの良さが伝わるシナリオ
を作ります。
これは悪いことではありません。
自社の商品を説明するのですから、当然です。
家電メーカーがテレビを紹介するときに、
一番きれいな映像を流すのと同じです。
自動車メーカーが、
一番気持ちよく走れる道路で試乗してもらうのと同じです。
問題は、
それが実際の業務のすべてではない
ということです。
デモでは「失敗する場面」が見えない
例えば、
発注画面のデモを見せてもらったとします。
商品を選ぶ。
発注数量を入力する。
「発注」ボタンを押す。
完了。
非常にスムーズです。
しかし、実際の店舗ではどうでしょう。
発注しようとしたら、
「この商品、今日は欠品している。」
「昨日の特売の影響で数量がおかしい。」
「この店舗だけ発注単位が違う。」
「商品マスターが間違っている。」
「昨日の入荷数が合っていない。」
そんなことが起こります。
つまり、
正常な状態のデモだけでは、実際の現場の大変さは分からない
のです。
小売業のシステムには「例外」がたくさんある
小売業のシステムを難しくしているもの。
私は、その一つが、
「例外の多さ」
だと思っています。
通常の商品。
通常の発注。
通常の入荷。
通常の売上。
これだけなら、システムはそれほど難しくありません。
ところが現場では、
「今日は特売。」
「この商品だけ発注単位が違う。」
「この店舗だけ納品曜日が違う。」
「急に欠品した。」
「予定より多く入荷した。」
「返品になった。」
「価格が変更された。」
「新商品が急に追加された。」
といったことが次々に起こります。
だから私は、
「通常の処理」よりも「例外が起きたときにどうなるか」
を見てほしいと思っています。
デモでは「例外処理」を見せてもらおう
例えば、こんな質問をしてみてください。
「この処理でエラーが起きた場合はどうなりますか？」
あるいは、
「入力を間違えた場合、どこから修正できますか？」
さらに、
「店舗側で想定外のことが起きた場合、どうやって復旧しますか？」
と聞いてみる。
すると、
ベンダーの説明が変わってきます。
「この場合は、こちらの画面から修正できます。」
「この処理は店舗では変更できないので、本部側で対応します。」
「このケースでは一度キャンセルして、再登録します。」
このような具体的な説明が出てくれば、
かなり参考になります。
「3クリックで発注できます」に惑わされない
デモでは、
「わずか3クリックで発注できます！」
という説明もあります。
確かに便利です。
でも、考えてみてください。
本当に重要なのは、
「3クリックでできること」でしょうか？
それとも、
「発注する前に、必要な情報を正しく確認できること」
でしょうか。
店舗の発注担当者にとっては、
クリック数が1回少ないことより、
「なぜ、この数量が推奨されているのか」
が分かる方が重要かもしれません。
あるいは、
「この商品は昨日から販売数が急増している。」
「この店舗では在庫が多すぎる。」
といった情報が、一目で分かる方が便利かもしれません。
つまり、
操作の速さだけではなく、「仕事そのものが楽になるか」を見る
必要があります。
「画面がきれい」は重要。でも、それだけではない
最近のシステムは、
昔に比べて画面がきれいになりました。
スマートフォンのように直感的に操作できる。
グラフもきれい。
色分けもされている。
アイコンも分かりやすい。
これは非常に良いことです。
しかし、
「きれいな画面」と「使いやすい画面」は同じではありません。
例えば、
発注担当者が毎日1000商品を確認する。
その人にとって、
きれいなグラフより、
必要な情報が一画面で確認できる方が便利かもしれません。
店長なら、
細かな分析より、
「今日、何か問題が起きている店舗はどこか」
がすぐ分かる方が重要かもしれません。
つまり、
誰が、何のために使う画面なのか
を見る必要があります。
「実際の業務をやってみる」のがおすすめ
私が小売企業側だったら、
デモをただ見るだけではなく、
実際の業務をベンダーにやってもらいます。
例えば、
「では、昨日売上が急増した商品を10品選んで、今日の発注数量を決めるところまでやってみてください。」
とお願いする。
あるいは、
「新商品が登録されたところから、発注できる状態になるまでを見せてください。」
「欠品が発生した場合の処理を見せてください。」
「返品が発生した場合はどうなりますか？」
こうすると、
単なるデモでは見えなかった部分が見えてきます。
自社のデータを使ってみる
さらに可能なら、
自社のサンプルデータを使ったデモ
をお願いしてみるのもおすすめです。
ベンダーが用意したデータでは、
当然、きれいに動きます。
商品名もきれい。
マスターも整っている。
データの欠損もない。
しかし、実際の会社のデータは、
そうとは限りません。
商品コードが複雑。
店舗によって登録方法が違う。
古い商品が残っている。
取引先コードが統一されていない。
過去データに不整合がある。
こうしたデータを入れてみると、
システムの本当の姿が見えてきます。
もちろん、正式なデモ段階でどこまでできるかはベンダーとの相談になります。
それでも、
「可能なら自社に近いデータで確認したい」
と伝える価値はあります。
「速いシステム」より「迷わないシステム」
システムの性能を評価するとき、
処理速度を気にする人も多いと思います。
「この処理は何秒ですか？」
もちろん重要です。
しかし、店舗の仕事では、
人が迷う時間
も大きな問題です。
「このボタンでいいのかな？」
「この数量で合っているのかな？」
「エラーが出たけど、どうすればいい？」
こうした時間が積み重なると、
システムが速くても、
仕事全体は速くなりません。
だから、
「処理が速いか」だけではなく、「人が迷わず使えるか」
も見てください。
デモで「操作している人」を見てみる
もう一つ、面白い見方があります。
システム画面ではなく、
デモを操作している人を見る
のです。
ベンダーのSEが操作する。
当然、操作が速い。
どこに何があるか分かっている。
ショートカットも知っている。
だから、
「すごく使いやすいシステムだ。」
と思ってしまいます。
でも、それは当たり前です。
その人は、
そのシステムを何百回、何千回と操作しているのですから。
そこで、
「初めて使う人が操作するとしたら、どうなりますか？」
と聞いてみてください。
そして可能なら、
実際の店舗担当者に触ってもらう。
これが一番分かりやすいです。
「現場の人」に触ってもらう
例えば、
ベテランの情報システム担当者ではなく、
実際の店舗で発注を担当する人に触ってもらう。
そして、
「分かりやすいですか？」
ではなく、
「これなら、今の仕事より楽になりそうですか？」
と聞いてみる。
こちらの方が重要です。
システム担当者が、
「操作性は問題ありません。」
と言っても、
店舗の人が、
「毎日使うなら今の方が楽です。」
と言ったら、
そこには大きなギャップがあります。
「できないこと」をデモで聞いてみる
前回の提案書の記事でも、
「できないことを聞く」
という話をしました。
デモでも同じです。
例えば、
「このシステムで、できないことは何ですか？」
と聞いてみてください。
さらに、
「標準機能では難しいことは何ですか？」
と聞いてみる。
ここで、
「ほとんどありません。」
という回答より、
「この部分は標準ではできません。」
「この処理は運用で対応します。」
「この部分はカスタマイズになります。」
と説明してくれる方が、
私は信頼できます。
「デモで見せなかった部分」に注目する
これも大切です。
デモが終わった後に、
「ありがとうございました。」
で終わらないでください。
そこで、
「今日見せてもらっていない機能で、今回のプロジェクトに重要なものはありますか？」
と聞いてみる。
すると、
「実は、もう一つ重要な機能があります。」
という話が出るかもしれません。
あるいは、
「そこは標準機能では対応していません。」
という話になるかもしれません。
これも、
ベンダーを評価する材料になります。
「すごい！」より「これなら使える」
デモを見たとき、
「すごい！」
と思うことは悪くありません。
むしろ、
新しいシステムを見る楽しさでもあります。
ただ、
「すごい」と「使える」は違います。
例えば、
AIが需要を予測してくれる。
すごい。
しかし、
その予測結果を誰が確認するのか。
外れたとき、誰が修正するのか。
店舗ではどのように使うのか。
これが決まっていなければ、
「すごい機能」で終わってしまいます。
デモで必ず聞いてほしい10の質問
ここで、実際のコンペで使える質問をまとめてみます。
① この機能は標準機能ですか？
カスタマイズとの区別を確認します。
② この処理でエラーが起きたらどうなりますか？
正常系だけでなく異常系を見る。
③ 入力を間違えた場合、どうやって修正しますか？
現場では必ず間違いが起こります。
④ 初めて使う人でも操作できますか？
ベテランSEではなく、初心者の視点で見る。
⑤ 大量の商品を扱う場合、操作方法は変わりますか？
小売業ならではの視点です。
⑥ 店舗によって運用が違う場合、どう対応しますか？
現実の小売現場では非常に重要です。
⑦ システムが使えなくなった場合はどうしますか？
障害時の運用を確認します。
⑧ このシステムの弱点は何ですか？
ベンダーの正直さを見る質問です。
⑨ 今のデモで見せていない重要な機能はありますか？
隠れた重要ポイントを確認します。
⑩ 実際の店舗担当者に操作してもらえますか？
これができれば、かなり実践的な評価ができます。
デモは「試験」ではなく「会話」にする
ベンダーのデモというと、
「ベンダーが説明する。」
「お客様が見る。」
という一方向になりがちです。
私は、
もっと会話にしていい
と思っています。
「こういう場合は？」
「この場合はどうなる？」
「今の業務ではこうしています。」
「それなら、この方法があります。」
こうやって話をしていく。
すると、
単なるシステム紹介ではなく、
「自社の業務をどう変えるか」という話
になっていきます。
実は、ここでの会話こそ、
ベンダーを見極める重要なポイントです。
デモで「質問にどう答えるか」を見る
第3回でも、
「答えそのものより、答え方を見る」
という話をしました。
デモでも同じです。
少し難しい質問をしてみる。
すると、
「できます！」
と即答する会社。
「それは確認が必要です。」
と答える会社。
「標準では難しいですが、別の方法があります。」
と答える会社。
私は、
最後のような会社を高く評価します。
なぜなら、
「何でもできます」
と言うのではなく、
システムの限界を理解した上で提案している
からです。
デモの最後に「逆質問」をしてみる
最後に、少し面白い質問をおすすめします。
「今日のデモを見て、私たちが見落としている点はありますか？」
です。
これは、
「自社のことをどれだけ考えてくれているか」
を見る質問です。
単なる営業なら、
「特にありません。」
で終わるでしょう。
しかし、
本気で提案しているベンダーなら、
「一点あります。」
「御社の場合、この部分は今のうちに整理した方がいいと思います。」
と話してくれるかもしれません。
それは、
システムの説明ではありません。
プロジェクトを成功させるためのアドバイス
です。
まとめ
システムデモは、
ベンダーを選ぶ上で非常に重要な機会です。
しかし、
**「画面がきれい」
「機能が多い」
「操作が速い」
「最新技術が使われている」**
というだけで判断してはいけません。
本当に見るべきなのは、
「自分たちの仕事がどう変わるのか」
です。
そして、
「うまくいっているとき」だけではなく、「うまくいかなかったときにどうなるのか」
を見ることです。
エラーが起きたら？
入力を間違えたら？
商品マスターがおかしかったら？
店舗によって運用が違ったら？
システムが止まったら？
こうした質問をしてみてください。
そして、
可能なら、
実際にシステムを使う店舗担当者に操作してもらってください。
そこで、
「これなら使えそう。」
という声が出るのか。
それとも、
「今の方が簡単です。」
という声が出るのか。
それは、コンペ会場で見る「すごいデモ」よりも、はるかに価値のある情報です。
デモを見て、
「すごい！」
と思ったときこそ、
一度立ち止まってください。
そして、こう考えてみてください。
「このシステムを、明日から私たちの店舗の人が使ったら、本当に仕事は楽になるだろうか？」
さらに、
「このデモで見せてもらっていない、面倒な場面ではどうなるのだろう？」
と考えてみる。
この二つの質問をするだけでも、
デモを見る目はかなり変わります。
システムデモは、
「ベンダーのシステムがどれだけすごいかを見る場」ではありません。
「そのシステムが、自社の仕事に本当に合っているかを確かめる場」
です。
そして、もう一つ。
デモで、
「それはできません。」
「そこはカスタマイズが必要です。」
「その運用なら、別の方法をおすすめします。」
と言ってくれるベンダーがいたら、
ぜひ、その言葉を大切にしてください。
何でも「できます」と言う会社より、
できないことを正直に伝えてくれる会社の方が、導入後に頼れるパートナーになる可能性があります。
次回は、
「営業マンではなくSEを見るべき理由」
です。
コンペでは、どうしても営業担当者の印象が強く残ります。
説明が上手。
話が分かりやすい。
レスポンスが速い。
人柄もいい。
もちろん、それも大切です。
しかし、契約した後に毎日のように付き合うのは、営業マンではなくSEやプロジェクトマネージャーです。
では、ベンダー選定のときに、SEのどこを見ればいいのか。
これは、元ベンダーだからこそお話しできるテーマだと思います。
コメント