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

システムが稼働したら、プロジェクトは終わり？

小売システムの導入プロジェクトでは、長い準備期間を経て、ようやく本番稼働の日を迎えます。

何度も打ち合わせを重ね、要件を決め、プログラムを開発し、テストを繰り返す。

ユーザー企業もベンダーも、相当な時間と労力を費やします。

そして、無事に本番稼働を迎えると、関係者からこんな言葉が聞こえてきます。

「やっと終わった！」

その気持ちは、よく分かります。

長いプロジェクトが一区切りついたのですから、ほっとするのも当然です。

しかし、元ベンダーの立場から言わせてもらうと、ここで一つ、考えておきたいことがあります。

小売システムが稼働したことと、小売システム導入が成功したことは、同じではありません。

本当に大切なのは、新しいシステムが現場で使われ、業務が改善され、会社にとって意味のある成果が出ることです。

ところが、導入前にはあれほど熱心に取り組んでいた会社が、稼働した途端にシステムへの関心を失ってしまうことがあります。

そして、数カ月後、こんな声が聞こえてきます。

「思っていたほど便利にならなかった」

「前のシステムの方が使いやすかった」

「こんなに手間がかかるとは思わなかった」

なぜ、こうしたことが起きるのでしょうか。

今回は、小売システム導入後に後悔する会社に共通するポイントを考えてみたいと思います。

---

1．本番稼働をゴールにしてしまう

最初の共通点は、本番稼働をプロジェクトの最終目的にしてしまうことです。

システム導入では、どうしても稼働日が大きな目標になります。

「○月○日に新システムを稼働させる」

この目標に向かって、関係者が一生懸命に作業を進めます。

もちろん、稼働日は重要です。

しかし、稼働すること自体が目的になってしまうと、少し問題があります。

例えば、こんなケースです。

• 操作方法を十分に理解していない社員がいる
• 現場での運用ルールが曖昧なままになっている
• 一部の機能が使いこなされていない
• 現場から出ている問題が十分に整理されていない
• システム導入によって何を改善するのか、誰も確認していない

それでも、予定日にシステムが動けば「プロジェクト成功」と判断されてしまう。

しかし、現場では毎日、使いにくさや不便さと向き合うことになります。

これでは、何のためにシステムを導入したのか分かりません。

大切なのは、稼働日をゴールにするのではなく、稼働後に目指す状態を明確にしておくことです。

例えば、

• 発注業務にかかる時間を減らす
• 在庫の精度を高める
• 店舗から本部への問い合わせを減らす
• 集計作業を効率化する
• 売上や粗利益を迅速に把握できるようにする

こうした目的が達成できて初めて、導入の効果を実感できます。

---

2．社員教育を「一度説明すれば終わり」と考える

二つ目は、社員教育の問題です。

新しい小売システムを導入すると、操作方法も業務の進め方も変わります。

そのため、導入前に説明会や操作研修を行います。

ところが、研修を終えた段階で、

「一通り説明したから大丈夫だろう」

と考えてしまう会社があります。

私は、ここに落とし穴があると思います。

研修で操作方法を理解することと、実際の業務で迷わず使えることは違います。

例えば、店舗の担当者が研修を受けたとします。

研修では、通常の商品を発注する方法を学びました。

ところが、実際の店舗では、

• 商品がマスタに登録されていない
• 発注数量を間違えた
• 納品数と発注数が一致しない
• 特売商品の扱いが分からない
• 返品や訂正の方法が分からない

といった問題が起こります。

こうした例外的な場面こそ、現場では困るものです。

しかも、店舗の仕事はシステム操作だけではありません。

接客、品出し、レジ対応など、ほかにも仕事があります。

分からない操作があっても、ゆっくりマニュアルを読む時間がないこともあります。

その結果、詳しい社員に聞いたり、独自のメモを作ったり、場合によってはシステムを使わずに処理したりすることになります。

そして、いつの間にか店舗ごとに違うやり方が広がってしまうのです。

だからこそ、教育は一度で終わりではありません。

稼働後に出てきた疑問を集め、繰り返し教育する仕組みが必要です。

特に、店舗の担当者が気軽に質問できる窓口を用意しておくことをおすすめします。

---

3．現場の不満を「慣れれば解決する」と片づける

三つ目は、現場から出てくる不満への対応です。

新しいシステムを導入すれば、最初は戸惑いが出るものです。

今までと操作方法が違うのですから、多少の不便を感じることもあるでしょう。

そのため、現場から不満が出たときに、

「新しいシステムだから、慣れれば大丈夫」

と考えてしまうことがあります。

確かに、慣れることで解決する問題もあります。

しかし、すべての問題がそうとは限りません。

例えば、以前は数回の操作で終わっていた作業が、新システムでは何度も画面を切り替えなければならない。

毎日行う作業なのに、以前より時間がかかる。

必要な情報が画面のどこにあるのか分かりにくい。

こうした問題は、単に慣れればよいという話ではありません。

一つひとつは小さな不便でも、店舗数が多く、毎日繰り返される作業であれば、会社全体では大きな負担になることがあります。

もちろん、現場の要望をすべて受け入れる必要はありません。

しかし、現場から出てくる声には、システム改善のヒントが含まれていることがあります。

大切なのは、不満をそのまま受け流すのではなく、

「何に困っているのか？」

「どの作業に時間がかかっているのか？」

「業務のやり方を変えれば解決できるのか？」

を確認することです。

現場の声を、単なる不満ではなく改善の材料として扱うこと。

これが、導入後の小売システムを育てる第一歩になります。

---

4．問題が起きたとき、誰が対応するのか決まっていない

四つ目は、責任の所在が曖昧になっていることです。

システム稼働後には、さまざまな問い合わせや問題が発生します。

例えば、店舗から、

「発注データが送信できません」

という連絡が入ったとします。

その原因は何でしょうか。

システムの不具合でしょうか。

店舗での操作ミスでしょうか。

マスタの設定でしょうか。

ネットワークの問題でしょうか。

ほかのシステムとの連携に問題があるのでしょうか。

原因によって、対応する人や部署は変わります。

ところが、問い合わせ窓口や対応手順が決まっていないと、こんなことが起こります。

店舗は本部に連絡する。

本部は情報システム部門に連絡する。

情報システム部門はベンダーに問い合わせる。

ベンダーは別の担当者に確認する。

その間、店舗では問題が解決しません。

こうした状態が続くと、現場は新しいシステムに不信感を持つようになります。

導入後に必要なのは、システムそのものだけではありません。

問題が起きたときに、誰が受け付け、誰が判断し、誰が解決するのかという運用体制です。

例えば、次のような役割を明確にしておくとよいでしょう。

• 店舗からの問い合わせを受け付ける窓口
• 業務上の判断を行う担当部署
• システムの技術的な問題を調査する担当者
• ベンダーへの問い合わせやエスカレーションを行う担当者
• 緊急時に判断する責任者

また、稼働直後は通常時よりも問い合わせが増える可能性があります。

そのため、導入前から、稼働後のサポート体制についてベンダーと相談しておくことが重要です。

---

5．導入後の改善を考えていない

五つ目は、システムを導入した後の改善計画がないことです。

導入前には、さまざまな要望が出てきます。

しかし、予算やスケジュールの都合で、すべての要望を実現できるとは限りません。

そこで、優先順位をつけて、必要な機能から導入していきます。

これは合理的な進め方です。

問題は、導入しなかった要望や、稼働後に見つかった改善点を、そのまま放置してしまうことです。

例えば、

「この帳票は、次の段階で改善しよう」

「この業務は、稼働後に見直そう」

「店舗から出てきた要望は、後で整理しよう」

という話があったとします。

ところが、本番稼働を迎えると、関係者は日常業務に戻ります。

すると、導入前に話していた改善事項が、いつの間にか忘れられてしまうことがあります。

その結果、使いにくい部分が残ったまま、何年も使い続けることになります。

私は、導入後の改善について、最初から計画しておくことをおすすめします。

例えば、稼働後1カ月、3カ月、6カ月といった節目で、次のことを確認します。

• 現場で困っていることは何か
• 当初の目的は達成できているか
• 手作業が残っている部分はないか
• 問い合わせが多い機能は何か
• 改善すべき業務は何か
• 追加対応の費用や効果はどうか

こうした確認を行い、改善する項目と優先順位を決めていきます。

小売システムは導入して終わりではなく、使いながら改善していくものです。

---

6．「前のシステムの方がよかった」という声に向き合わない

六つ目は、以前のシステムと比較する声への対応です。

新しいシステムを導入すると、必ずといっていいほど、

「前のシステムの方がよかった」

という声が出てきます。

これは、ある程度仕方のないことです。

長年使ってきたシステムなら、社員は操作方法を熟知しています。

どこに何があるのかも分かっています。

多少の不便があっても、慣れているため、それほど苦にならないこともあります。

一方、新しいシステムでは、今までと違う操作や考え方を覚えなければなりません。

そのため、導入直後は以前のシステムの方が便利に感じることがあります。

ただし、ここで大切なのは、以前のシステムに戻すかどうかという話ではありません。

「前の方がよかった」という声の中身を確認することです。

例えば、

「前のシステムでは、商品を検索するのが簡単だった」

という意見があったとします。

その場合、単に新しいシステムに慣れていないだけなのかもしれません。

あるいは、実際に検索方法が分かりにくくなっているのかもしれません。

また、前のシステムでは便利だった機能が、新しいシステムでは別の方法で実現できる場合もあります。

大切なのは、以前のシステムを無条件に否定することでも、新しいシステムを無理に正当化することでもありません。

何が不便なのかを具体的に把握し、解決方法を考えることです。

そのためには、現場の声を聞く姿勢と、問題を整理する仕組みが必要になります。

---

7．導入効果を測定していない

最後に、もう一つ重要な問題があります。

それは、システムを導入した効果を測定していないことです。

例えば、発注システムを新しくしたとします。

導入前には、

「発注業務を効率化したい」

という目的がありました。

では、導入後に、本当に効率化できたのでしょうか。

発注にかかる時間は短くなったのでしょうか。

発注ミスは減ったのでしょうか。

在庫は適正化されたのでしょうか。

欠品や過剰在庫は減ったのでしょうか。

こうしたことを確認しなければ、導入効果があったのかどうか分かりません。

もちろん、すべての効果を数字で正確に測れるわけではありません。

しかし、導入前と導入後を比較するための指標を、できるだけ用意しておくことは大切です。

例えば、

• 作業時間
• 入力ミスの件数
• 問い合わせ件数
• 在庫差異の発生状況
• 欠品や過剰在庫の状況
• 月次集計にかかる時間

などです。

ただし、注意したいことがあります。

導入効果を測る目的は、単にシステムの成績をつけることではありません。

期待した効果が出ていない場合に、原因を見つけて改善するためです。

システムそのものに問題があるのか。

運用方法に問題があるのか。

社員教育が不足しているのか。

導入前の目標設定が適切でなかったのか。

原因を整理することで、次に何をすべきかが見えてきます。

---

導入後に後悔しないために、稼働前から考えておくこと

ここまで、導入後に後悔する会社の共通点を見てきました。

では、そうならないためには、どうすればよいのでしょうか。

私がおすすめしたいのは、稼働後のことを、システム導入の計画に最初から組み込んでおくことです。

具体的には、次の5つを確認しておきましょう。

① 稼働後の目標を決めておく

何を改善するためにシステムを導入するのか。

その目標が達成できたか、どうやって確認するのか。

これを明確にします。

② 教育と問い合わせ対応の仕組みを作る

操作方法を説明して終わりではなく、稼働後に質問できる窓口や、追加教育の方法を用意します。

③ 問題が起きたときの役割分担を決める

ユーザー企業とベンダーのどちらが何を担当するのか。

緊急時には誰が判断するのか。

こうしたルールを明確にします。

④ 改善要望を管理する

稼働後に出てきた要望を、場当たり的に対応するのではなく、一覧にして優先順位をつけます。

⑤ 定期的に導入効果を確認する

稼働してから1カ月、3カ月、6カ月など、節目を決めて振り返ります。

この5つを準備しておくだけでも、導入後の対応は大きく変わると思います。

---

元ベンダーだからこそ思うこと

ベンダー側にとって、本番稼働は大きな節目です。

長い間取り組んできたプロジェクトが、ようやく形になる瞬間です。

ユーザー企業から、

「無事に稼働できました。ありがとうございました」

と言われれば、うれしいものです。

しかし、私が本当に大切だと思うのは、その後です。

店舗の社員が問題なく使えているか。

本部の業務が改善されているか。

導入前に目指していた姿に近づいているか。

そして、困ったときに相談できる相手がいるか。

こうしたことが、長い目で見たシステム導入の評価につながります。

もちろん、すべての問題を一度に解決することはできません。

稼働後に初めて分かることもあります。

だからこそ、問題が起きたときに、

「誰の責任なのか」

だけを追及するのではなく、

「どうすれば解決できるのか」

を一緒に考えられる関係が大切です。

第12回では、ベンダー選定で重要なのは相性だとお話ししました。

その相性が本当に問われるのは、実はシステムが順調に動いているときではありません。

問題が起きたとき、導入後に改善が必要になったときこそ、本当の関係が見えてくるのです。

---

まとめ

今回は、「システム導入後に後悔する会社の共通点」についてお話ししました。

主なポイントを整理すると、次のとおりです。

• 本番稼働をゴールにしてしまう
• 社員教育を一度で終わらせてしまう
• 現場の不満を「慣れれば解決する」と片づける
• 問題が起きたときの責任や役割が曖昧
• 導入後の改善を考えていない
• 「前のシステムの方がよかった」という声に向き合わない
• 導入効果を測定していない

そして、今回、一番お伝えしたいことは次の言葉です。

システム導入は、本番稼働で終わりではない。
本当に価値が生まれるのは、稼働したシステムを現場で使い、改善し続けてからです。

システムを導入すること自体が目的になってしまうと、せっかくの投資を十分に生かせません。

導入前に何を実現したかったのか。

導入後に何が変わったのか。

そして、これから何を改善していくのか。

この3つを継続して考えていくことが大切だと思います。

---

---

次回予告

次回、第14回は、導入後のシステムを支える「保守契約」について考えてみたいと思います。

システムを導入すると、多くの場合、ベンダーとの間で保守契約を結びます。

しかし、保守契約の内容を、十分に理解しているでしょうか。

障害が起きたとき、どこまで対応してもらえるのか。

問い合わせには、どのくらいの時間で回答してもらえるのか。

システムを変更したいとき、追加費用はどうなるのか。

こうしたことを曖昧にしたまま契約してしまうと、導入後に困ることがあります。

次回は、

第14回「保守契約は『保険』ではなく『パートナー契約』である」

として、保守契約を単なる維持費ではなく、システムを長く活用するための大切な関係として考えてみたいと思います。