販売管理システムが古い。でも動いているから替えられない

――20年以上使い続けた先に起きること
「もう20年以上使っている販売管理システムなんですが、特に困っていないんです」
長年使われているシステムのお客様とお話ししていると、こうしたケースがあります。
毎日の受注、発注、仕入、売上、在庫管理は問題なく動いている。
担当者も操作に慣れていて、中には、
「目をつむっていても操作できる」
と言えるくらい使い込んでいる方もいます。
そうなると、
「動いているのに、なぜわざわざ新しいシステムへ替える必要があるの?」
というのは当然の疑問です。
新しいシステムに替えた結果、今まで一瞬でできていた操作に何回もクリックが必要になったら、むしろ仕事が遅くなってしまいます。
私たちも、古いからという理由だけでシステムを入れ替える必要はないと考えています。
しかし、長く使い続けていると、画面からは見えにくいところで少しずつ問題が出てきます。
今回は、20年以上使われているような販売管理システムで、実際にどんな問題が起きるのか。そして、どこまで使い続け、いつ入れ替えを考えるべきなのかについて書いてみます。
「使える」と「維持し続けられる」は違う
毎日の業務だけを見ていると、古いシステムでも問題なく使えることがあります。
受注入力もできる。
売上も入力できる。
請求書も発行できる。
在庫も確認できる。
しかし、そのシステムを支えている技術まで見てみると、少し状況が違います。
例えば、Excelへデータを出力できても、古いExcelのファイル形式にしか対応していない。
データベースには、古いバージョンのSQL Serverを使っている。
SQL Serverとは、販売管理システムの受注・売上・在庫などのデータを保存しているデータベース管理システムです。
さらに問題になるのが、開発環境です。
古い販売管理システムを修正するために、開発会社側で古いWindows環境そのものを残しておかなければならないこともあります。
つまり、利用者から見ると、
「今日も普通に動いている」
のですが、開発側から見ると、
「この環境をあと何年維持できるだろうか?」
という別の問題が発生しています。
ここで重要なのは、
「今使えるか」と「これからも維持できるか」は別の問題
だということです。
古いシステムでも、新しいサービスとは連携できる
では、古い販売管理システムでは、新しいことは何もできないのでしょうか。
必ずしもそうではありません。
実際には、
- ShopifyなどのECサイト
- スマレジなどのPOS
- クラウドサービス
- API連携
- メール送信
- Web在庫照会
など、新しく必要になった部分だけを新しい開発環境で作る方法があります。
APIとは、異なるシステム同士でデータをやり取りするための仕組みです。
古い販売管理システム本体を大きく変更するのではなく、新しいプログラムから既存のデータベースへ直接データを読み書きする。
そうすることで、
古い販売管理システムを残しながら、新しいサービスを追加する
ことができます。
「全部入れ替える」か「そのまま使う」かの二択ではない
これは、長年使っているシステムでは重要な考え方だと思います。
選択肢は、
① 古いシステムをそのまま使い続ける
または、
② すべて新しいシステムへ入れ替える
の二つだけではありません。
③ 今のシステムを活かしながら、必要な部分だけ新しくする
という方法もあります。
20年間使い続けて現場に定着しているシステムには、それだけの理由があります。
無理にすべてを変更するより、使いやすい部分は残して、新しく必要になった部分だけ追加する。
この方法で、システムの寿命を延ばせるケースもあります。
では、いつまで延命できるのか?
問題はここです。
新しい機能を外側に追加していけば、古いシステムでもかなり長く使うことができます。
しかし、いつまでも続けられるわけではありません。
私たちが一つの境界だと考えているのが、
古い開発環境そのものを維持できなくなったとき
です。
そして、もう一つあります。
新しく追加したい機能の方が、既存システムの機能より多くなってきたとき
です。
最初は一つだった外部連携が、
ECと連携したい。
POSとも連携したい。
Webから在庫を見たい。
メールも自動送信したい。
クラウドサービスともつなぎたい。
と増えていく。
気がつけば、
古いシステムを残すために、新しいシステムを周りにたくさん作っている
という状態になることがあります。
ここまで来ると、古いシステムへ機能を継ぎ足し続けるよりも、システム全体を見直した方がよい時期に入っている可能性があります。
システムより先に「分かる人」がいなくなる
もう一つ、長期間使っているシステムで無視できない問題があります。
人です。
20年以上前に作られたシステムでは、現在あまり使われなくなった開発言語や技術が使われていることがあります。
そして、そのシステムを作った技術者も年齢を重ねます。
古い開発言語を理解している技術者が定年を迎えれば、
システムは動いているのに、修正できる人がいない
という状態になる可能性があります。
これは、ある日突然システムが動かなくなる問題とは違います。
少しずつ、
「この部分を直せる人が少ない」
「この仕様を知っている人がいない」
という状態になっていきます。
技術の老朽化だけではなく、技術を知っている人の高齢化も、システムを長く使ううえでは考えておく必要があります。
そして、社内にも「全部分かる人」がいなくなる
問題は開発会社側だけではありません。
20年間同じシステムを使っていると、その間に何度も機能追加や改修が行われます。
最初はシンプルだった画面に、
「この項目を追加してほしい」
「この得意先だけ処理を変えてほしい」
「この帳票だけ特別な計算をしてほしい」
といった要望が少しずつ追加されていきます。
20年後には、かなり複雑なシステムになっています。
すると、
「なぜ、この機能があるのか?」
を誰も説明できないことがあります。
以前の担当者から引き継いだから、そのまま使っている。
昔からこのボタンを押すことになっている。
なぜ必要なのかは分からない。
長年の追加改修によって、誰もシステム全体の仕様を把握していないという状態になることがあります。
新しいシステムにすれば解決……とは限らない
では、最新のシステムへ入れ替えればすべて解決するのでしょうか。
ここにも注意が必要です。
システムを入れ替えたときに、現場からよく出るのが、
「前のシステムの方が使いやすかった」
という声です。
これは当然だと思います。
20年間使ってきたシステムなら、担当者は操作を完全に覚えています。
どの画面を開いて、
どこに入力して、
どのキーを押せばいいのか。
考えなくても操作できます。
それを突然、新しい画面へ変更する。
どれだけ新しい技術を使っていても、操作が増えたり、今までできていたことができなくなったりすれば、現場にとっては「使いにくいシステム」です。
新しい=使いやすい、ではありません。
リプレイスするとき、最初に「画面の目的」を考える
では、長年使ったシステムをリプレイスするとき、何を大切にすればいいのでしょうか。
リプレイスとは、古いシステムを新しいシステムへ置き換えることです。
私たちが特に注意しているのが、
「この画面は、何のためにあるのか?」
を一つずつ明確にすることです。
例えば、20年前から使っている「受注照会」という画面があったとします。
新しいシステムを作るときに、
「今の受注照会画面を、そのまま新しい技術で作り直そう」
と考えるのではありません。
まず、
「この画面を使って、担当者は何を知りたいのか?」
を考えます。
納期を確認したいのか。
在庫を確認したいのか。
出荷状況を確認したいのか。
受注残を確認したいのか。
目的が分かれば、20年前と同じ画面である必要はありません。
逆に、現場にとって非常に使いやすい操作なら、新しいシステムでもその考え方を残した方がいい場合があります。
「古いシステムを再現する」のではなく「今の仕事を作り直す」
20年間で仕事のやり方も変わっています。
昔はなかったECがあります。
POSとの連携があります。
Webがあります。
APIがあります。
メール送信があります。
そして、これからはAIとの連携も増えていくと思います。
そう考えると、システムのリプレイスは、
古いシステムを新しい技術でそっくり作り直すこと
ではないと思います。
20年間積み重なった機能を一度整理して、
今でも必要なもの
もう使っていないもの
これから必要になるもの
を見直す。
そのうえで、
「今の仕事に必要なシステムとは何か?」
をもう一度考える。
これがリプレイスの大きな意味ではないでしょうか。
「まだ動いている今」が考えるタイミングかもしれない
古い販売管理システムだからといって、すぐに入れ替える必要はありません。
問題なく動いている。
現場も使いやすい。
必要な新機能は外付けで対応できる。
それなら、今のシステムを活かすという選択肢もあります。
一方で、
古い開発環境を維持することが難しくなってきた。
新しく追加したい機能の方が増えてきた。
古い技術を理解している人が少なくなってきた。
こうした変化が重なってきたら、一度立ち止まって考えるタイミングだと思います。
システムが完全に動かなくなってからでは、選択肢が限られます。
まだ問題なく動いているうちなら、
残すもの、変えるもの、捨てるもの
を時間をかけて考えることができます。
販売管理システムの入れ替えで大切なのは、
「何年前のシステムか」ではなく、「これから先も維持し、変化させていけるシステムか」
を見ることなのかもしれません。
インネット株式会社では、アパレル企業の現場で実際に起きている課題をもとに、販売管理・在庫管理・受発注・EC連携・業務自動化などについて発信しています。
