シリーズ：【元ベンダーが教える】小売システム導入 成功の法則　第九回

～「システムの値段」だけで導入費用を判断してはいけない～

前回は、

「営業マンではなくSEを見るべき理由」

というテーマで、ベンダー選定では会社や営業担当者だけを見るのではなく、実際にプロジェクトを担当するSEやプロジェクトマネージャーを見ることが重要だ、というお話をしました。

そして今回から、第3章です。

第3章　導入プロジェクトで失敗しないために

ここからは、

「ベンダーを選んだ後、どうすれば導入で失敗しないのか」

という話に入っていきます。

その第1回目が、

「見積書では見えない導入コスト」

です。

システム導入を検討するとき、当然ですが、

まず気になるのは、

「いくらかかるのか？」

ですよね。

ベンダーから見積書が出てきます。

例えば、

• システム費用　5,000万円
• 導入費用　1,000万円
• ハードウェア　2,000万円

合計8,000万円。

「なるほど、8,000万円か。」

となります。

ところが、実際にプロジェクトが始まると、

「この作業には別途費用が必要です。」

「このデータの整理はお客様側でお願いします。」

「この機能は標準では対応できないので追加開発になります。」

「店舗教育には別途費用がかかります。」

といった話が出てくる。

そして、

「最初の見積もりと話が違うじゃないか！」

となる。

もちろん、本当にベンダーの見積もりが甘かったケースもあります。

しかし、元ベンダーの立場から見ると、

最初の見積書に書かれていないコストは、決して珍しいものではありません。

そして、その中には、

ベンダーが隠していたのではなく、

そもそも小売企業側が「コスト」と認識していなかったもの

もかなりあります。

今回は、そこを掘り下げてみたいと思います。

---

「システムの値段」と「導入にかかるお金」は違う

まず最初に、

ここを分けて考えてください。

システムそのものの価格

と、

システムを会社で使える状態にするまでの費用

は別物です。

例えば、新しいPOSシステムを導入するとします。

POS端末を買った。

ソフトウェアも買った。

これで終わりでしょうか。

もちろん、終わりではありません。

商品マスターを登録する。

価格を設定する。

店舗を登録する。

従業員を登録する。

既存システムからデータを移行する。

ネットワークを準備する。

レジ担当者を教育する。

店舗でテストする。

本番稼働する。

問題が起きたら対応する。

つまり、

「買ったシステムを、実際の仕事で使える状態にする」

までに、さまざまな作業が必要なのです。

---

見積書の「導入費用」に何が含まれているのか

ここで注意してほしいのが、

見積書にある、

「導入支援費用」

という項目です。

例えば、

導入支援費用　1,500万円

と書いてあったとします。

これだけでは、

何をしてくれるのか分かりません。

要件定義なのか。

設定作業なのか。

データ移行なのか。

テスト支援なのか。

店舗教育なのか。

本番稼働支援なのか。

障害対応なのか。

すべて含まれているのか。

一部だけなのか。

だから、

「導入支援費用には、具体的にどこまで含まれていますか？」

と聞く必要があります。

---

見積書の「一式」は要注意

私がベンダー側にいた頃、

見積書にはよく、

「○○費　一式」

という書き方がありました。

これは見積書を簡潔にするためには便利です。

しかし、

発注する側からすると、

かなり分かりにくい。

例えば、

データ移行費　一式　500万円

と書かれていたとします。

では、

• 何件まで？
• どのデータが対象？
• データの加工は？
• データのクレンジングは？
• 検証は？
• 移行リハーサルは？
• 本番移行は？

どこまで含まれているのでしょうか。

ここが重要です。

---

① データ移行という「見えないコスト」

システム入れ替えで、

非常に大きな問題になるのが、

データ移行

です。

例えば、

商品マスターが10万件ある。

取引先マスターが5,000件ある。

店舗マスターが500店舗ある。

さらに、

過去の売上データ、

在庫データ、

発注データ、

顧客データなどがある。

「これを新システムに移してください。」

と言えば、

簡単そうに聞こえます。

しかし、実際には、

データをそのまま移せるとは限りません。

---

古いシステムのデータは、きれいとは限らない

例えば、

旧システムの商品コードが、

「12345」

だったとします。

新システムでは、

「A-12345」

という形式になっているかもしれません。

すると、

変換が必要です。

さらに、

「もう販売していない商品」

が大量に残っているかもしれません。

「同じ商品なのに、登録方法が違う。」

ということもあります。

こうしたデータを整理する作業を、

データクレンジング

と呼びます。

そして、この作業には、

かなりの人手がかかります。

---

データを「移す」より「整理する」方が大変

元ベンダーとして、

何度も見てきたのがこれです。

「データ移行って、コピーするだけじゃないんですか？」

違います。

実際には、

コピーする前の整理の方が大変

なのです。

古いデータを確認する。

不要なデータを削除する。

コードを変換する。

重複を確認する。

新システムの形式に合わせる。

テストする。

エラーを修正する。

再度テストする。

そして本番移行。

これだけの作業があります。

---

② 現場の人件費というコスト

次に見落とされやすいのが、

自社社員の人件費

です。

これは、

見積書にはほとんど出てきません。

例えば、

プロジェクトメンバーとして、

本部の社員が10人参加するとします。

毎週2回、3時間の会議。

さらに、

資料確認。

業務整理。

テスト。

店舗との調整。

教育。

これが半年間続いたらどうでしょう。

その人たちは、

当然、

普段の仕事もあります。

つまり、

システム導入によって、

通常業務に使える時間が減る

のです。

---

「無料の社内作業」は存在しない

これは非常に重要です。

会社の社員だから、

「社内作業は無料」

と思ってしまいがちです。

でも、

その人がシステム導入に100時間使えば、

100時間分、

別の仕事ができなくなります。

店舗の店長が、

システムテストに20時間使えば、

20時間分、

店舗運営に使える時間が減ります。

つまり、

社内の人件費も立派な導入コスト

なのです。

---

③ 店舗教育のコスト

小売業では、

ここが特に大きいと思います。

本部だけなら、

まだ人数は限られます。

しかし、

店舗が100店舗、200店舗、500店舗となると、

話が変わります。

新しいシステムの操作を教える必要があります。

店長。

副店長。

発注担当者。

レジ担当者。

場合によっては、

パート・アルバイトまで対象になります。

---

「マニュアルを作れば終わり」ではない

教育用のマニュアルを作る。

それだけでは、

現場は使えるようになりません。

実際に操作してもらう。

質問を受ける。

間違った操作を修正する。

もう一度やってもらう。

そして、

店舗ごとの疑問に答える。

これが必要です。

さらに、

「新しいシステムを覚える時間」

そのものが、

現場の負担になります。

だから、

教育費用だけでなく、教育に使う時間もコスト

として考える必要があります。

---

④ 店舗側の「二重運用」というコスト

新システムへの移行期間には、

旧システムと新システムを、

一時的に並行して使うことがあります。

例えば、

旧システムで発注。

新システムでも発注。

両方を確認する。

という運用です。

これは、

かなり大変です。

単純に、

仕事が2倍になります。

もちろん、

本番稼働前の検証として必要な場合もあります。

しかし、

長期間続くと、

店舗の負担は非常に大きくなります。

---

⑤ ハードウェア・ネットワークのコスト

システム本体だけを見ていると、

意外と忘れてしまうのが、

周辺機器やネットワーク

です。

例えば、

• POS端末
• ハンディ端末
• バーコードスキャナー
• プリンター
• 無線LAN
• ルーター
• ネットワーク回線
• バックアップ回線
• UPS

などです。

店舗によっては、

電源工事や、

ネットワーク工事まで必要になることがあります。

---

⑥ 本番稼働時の「立ち会いコスト」

システム導入では、

本番稼働の日が、

非常に重要です。

特に小売業では、

店舗を止めるわけにはいきません。

夜間に切り替える。

早朝から確認する。

場合によっては、

複数店舗に担当者を配置する。

こうした作業があります。

当然、

ベンダー側にも人件費がかかります。

しかし、

お客様側にも、

立ち会う人が必要です。

つまり、

ここにもコストがあります。

---

⑦ 「本番稼働後」の対応コスト

システムが稼働した。

これで終わり。

……ではありません。

むしろ、

ここからが本当のスタートです。

実際の店舗で使い始めると、

必ず質問が出ます。

「この操作はどうするの？」

「昨日までできたことができない。」

「この帳票はどこにある？」

「この商品だけ発注できない。」

こうした問い合わせが、

一気に増えることがあります。

これを、

稼働後支援

としてどこまでベンダーが対応するのか。

これも事前に確認しておく必要があります。

---

⑧ カスタマイズ費用

これは皆さんも想像しやすいでしょう。

「この機能を追加してほしい。」

「今のシステムと同じ画面にしてほしい。」

「この帳票も必要。」

こうした要望が増えると、

当然、

開発費用が増えます。

しかし、

本当に怖いのは、

初期費用だけではありません。

カスタマイズした部分は、

将来のバージョンアップにも影響します。

つまり、

導入時に払うお金だけではなく、将来の保守コストまで増える可能性がある

のです。

---

⑨ システム導入に伴う「業務改革」のコスト

新しいシステムを入れると、

業務そのものを変える必要が出てくる場合があります。

例えば、

今まで紙で行っていた作業を、

システムに変更する。

店舗ごとに違っていた発注ルールを、

統一する。

商品マスターの登録方法を、

本部で統一する。

こうした改革には、

社内での話し合いが必要です。

つまり、

システム導入費用とは別に、「会社を変えるためのコスト」

が発生します。

---

「ベンダーに払うお金」だけがコストではない

ここまでの話を整理すると、

システム導入には、

大きく分けて、

ベンダーに支払うコスト

• ソフトウェア
• ハードウェア
• 導入支援
• 開発
• データ移行
• 教育
• 保守

などがあります。

一方、

自社が負担するコスト

• プロジェクトメンバーの時間
• 現場のテスト時間
• 店舗教育
• データ整理
• 業務変更
• 会議
• 本番稼働対応

などがあります。

この両方を考えないと、

本当の導入コストは分かりません。

---

「一番安いベンダー」が本当に安いとは限らない

例えば、

A社　8,000万円

B社　9,000万円

C社　1億円

という見積もりが出たとします。

普通なら、

「A社が一番安い。」

と思います。

しかし、

A社は、

データ移行が一部別料金。

店舗教育が別料金。

追加開発が別料金。

稼働後支援が別料金。

だったとします。

一方、

C社は、

それらがほぼ含まれている。

すると、

単純な見積金額だけでは、

比較できません。

---

「総額」ではなく「総コスト」で考える

私は、

「総額」と「総コスト」は違う

と思っています。

総額とは、

ベンダーから出てきた請求金額。

総コストとは、

会社がそのシステム導入のために負担する、

すべてのコスト

です。

例えば、

ベンダーへの支払いが1億円。

社内人件費が3,000万円。

教育や店舗対応が1,000万円。

機器やネットワークが2,000万円。

すると、

会社としての総コストは、

1億6,000万円です。

もちろん、これは単純な例です。

しかし、

こうした視点で考えることが大切なのです。

---

では、見積段階で何を確認すればいいのか

では、

「後から費用が増えるのを防ぐにはどうすればいいのか？」

という話です。

私は、

見積書をもらったら、金額だけではなく「範囲」を確認する

ことをおすすめします。

例えば、

データ移行

「どのデータが対象ですか？」

教育

「何店舗、何人まで含まれますか？」

カスタマイズ

「どこまでが標準で、どこからが追加ですか？」

本番稼働

「稼働当日は何名来てもらえますか？」

稼働後支援

「何日間、どのような体制で支援してもらえますか？」

こうした質問をしてください。

---

「含まれていないもの」を聞く

そして、

一番おすすめしたい質問があります。

それは、

「この見積金額に含まれていない作業は何ですか？」

です。

これは非常に重要です。

ベンダーに、

「含まれているもの」

を説明してもらうのは普通です。

しかし、

「含まれていないもの」

を聞く。

すると、

「ネットワーク工事は別です。」

「データクレンジングはお客様側です。」

「店舗教育は基本的な説明のみです。」

「追加帳票は別途です。」

など、

今まで見えていなかった部分が出てきます。

---

「もし○○だったら？」と聞いてみる

さらに、

シナリオで質問してみるのもおすすめです。

「もしデータ移行で不整合が見つかったら、追加費用になりますか？」

「もし店舗教育を追加でお願いしたら、いくらですか？」

「もし本番稼働が1か月延期になったら、費用はどうなりますか？」

「もし標準機能では対応できないことが分かったら、どうなりますか？」

こうした質問をしておけば、

後から、

「そんな話は聞いていません。」

ということが減ります。

---

重要なのは「追加費用をゼロにすること」ではない

ここは誤解しないでほしいところです。

私は、

「追加費用が発生するベンダーは悪い」

と言いたいわけではありません。

システム開発では、

途中で新しい要件が出ることがあります。

当初想定していなかった問題が、

データ調査で見つかることもあります。

それに対応するための追加費用が発生することは、

当然あります。

問題なのは、

何が追加になるのかが、最初から分からないこと

です。

だから、

追加費用をゼロにするのではなく、

「追加費用が発生する条件を明確にする」

ことが重要なのです。

---

ベンダー側も「見積もり」を作るのは難しい

ここで少し、

ベンダー側の事情もお話ししましょう。

実は、

契約前の段階で、

すべての作業量を正確に見積もることは、

かなり難しいのです。

まだ要件が固まっていない。

データも詳しく調べていない。

現場の運用も全部見えていない。

それなのに、

「導入費用はいくらですか？」

と聞かれる。

ベンダーは、

限られた情報の中で、

見積もりを作らなければなりません。

だから、

初期見積もりが100％正確であることを期待するのは難しい

のです。

---

だからこそ「見積もりの前提」が重要

ベンダー側が、

「この見積もりは、○○を前提にしています。」

と書いていたら、

そこをよく読んでください。

例えば、

「既存データが新システムの形式に整備されていることを前提とします。」

と書いてある。

これは、

非常に重要な条件です。

もし実際には、

データが整理されていなかったら、

追加作業が必要になります。

つまり、

見積金額を見るときは、その金額だけではなく「その金額になる条件」を見る

ことが大切です。

---

私なら「5年間の総コスト」で考える

システムは、

導入して終わりではありません。

5年、

10年と使うことになります。

だから、

私は、

初期導入費用だけでなく、5年間くらいの総コスト

で比較することをおすすめします。

例えば、

• 初期導入費
• ソフトウェア利用料
• 保守費
• クラウド利用料
• ハードウェア更新
• バージョンアップ
• 追加開発
• 教育
• 運用人件費

などです。

もちろん、

すべてを正確に予測することはできません。

それでも、

「最初の金額だけで決めない」

という意識は非常に重要です。

---

見積書は「価格表」ではなく「プロジェクトの設計図」

私は、

見積書を見るとき、

こう考えると分かりやすいと思っています。

見積書は、

「いくら払うか」だけを見る資料ではありません。

その金額の中に、

「何を、どこまでやるのか」

が表れています。

だから、

見積書を見れば、

そのベンダーが、

今回のプロジェクトを、

どこまで理解しているのかも、

ある程度分かります。

---

まとめ

システム導入では、

「一番安い会社を選ぶ」

という考え方だけでは、

失敗する可能性があります。

重要なのは、

「何に、いくらかかるのか」

を理解することです。

そして、

「ベンダーに支払う費用」だけでなく、「自社が負担する費用」も含めて考える

ことです。

特に注意したいのは、

• データ移行
• データクレンジング
• 店舗教育
• 社内プロジェクトメンバーの人件費
• テスト
• 店舗での二重運用
• ハードウェア・ネットワーク
• 本番稼働対応
• 稼働後支援
• カスタマイズ

などです。

そして、

見積書を受け取ったら、

ぜひ、

「この金額に含まれていない作業は何ですか？」

と聞いてみてください。

さらに、

「この金額が増える可能性があるのは、どんな場合ですか？」

と聞いてください。

この二つの質問だけでも、

見積書の見方がかなり変わると思います。

---

次回は、

『できます』という言葉を信じてはいけない理由

についてお話しします。

コンペや打ち合わせで、

「その機能はできますか？」

と聞くと、

営業担当者から、

「はい、できます。」

と答えが返ってくる。

これは、

とても安心する言葉です。

しかし、

その「できます」には、

実は、

「標準機能でできます」

という意味の場合もあれば、

「追加開発すればできます」

という意味の場合もあります。

さらに、

「技術的にはできますが、あまりおすすめしません」

というケースまであります。

次回は、

この「できます」という言葉の裏側を、

元ベンダーの視点から掘り下げてみたいと思います。