中小企業DXできたらな計画

中小企業DX失敗例 失敗しないシステム更新 ~価格よりデータ移行~

業務システムの更新って面倒ですよね?

できればそのまま使い続けたいけど、値上がりがあったり、上から相見積もりをとるように指示を受けたり、他候補を探さなければならなくなることも多いと思います。

他候補を探しているうちに、

「こっちのシステムは安いな!」

「こんな機能があるのか!?」

など目移りしてしまうケースもよくあることです。

この記事では元上場企業SEの私がシステム更新のコツについて解説します。

この記事はこんな方にオススメ!

  • 業務システム更新が迫る管理担当者の方
  • システム更新を指示している上層部の方

f:id:matsublog2021:20220418225713p:image

 

システム更新の費用は参考程度

システム更新について、一番気になるのはやはり費用ではないでしょうか。
とりわけ中小企業においては費用を押さえることが優先度が高く、
比較表の一番上には費用を記載されることが多いのではないでしょうか。

私が現在勤める中小企業ももれなく費用重視です。
比較表を作成するときには初期費用とランニングコストが一番上の項目です。

表の一番左に現行システム、2列目に現行システムの後継品、3列目以降に他社製品が並びます。

レガシーからの更新は安くなって当然

こういう表を各システムで作ると、
ある傾向が見えてきます。

現行システムとその後継品、そのランニングコストは安くなることが多いです。

それはレガシーシステムの多くはオンプレミス型、
後継のソフトの多くはクラウド型だからです。

オンプレミスとは自社でサーバーも用意して自社だけでシステムを使う形式です。
そのため、サーバーのレンタル代や管理費などが必要になります。

一方でクラウド型はメーカーが管理するサーバーにあるシステムをみんなでシェアするものです。
そのため、サーバーの管理費はみんなで出し合う形になるのでオンプレミスよりも必然料金は安くなります。

オンプレミスは一棟買い、クラウドは賃貸のようなものです。

また、メーカーの立場から見ても、オンプレミス型のサポートはユーザーの数だけサーバーの面倒を見ないといけないので手間です。
後継にクラウド型があるなら、そちらに乗り換えて欲しくなります。
そのため、更新が近づくと料金をあげたり、新しいOSには対応させなかったりして、後継への移行を促します。

ちなみに、初期費用もあってないようなものです。
これから例えば5年間毎月支払いが発生するユーザーを確保するには初期費用のサービスくらいたいした値引率ではありません。
なので、多くのシステムで初期費用無料キャンペーンが展開されています。
他社から乗り換えてもらえるなら、キャンペーン期間を延長するなんて大したサービスではないので、変更時には初期費用は交渉の余地大いにあり、です。

要らない機能は要らない

お金が参考レベルにしかならないのなら、重要な指標は何でしょうか。

機能面で言えば、各社色々な特徴を持ったソフトを持っており、目移りしてしまうこともあるでしょう。
しかし、運用で使わない機能はあくまでも過剰な機能です。
カレーを作るためにスーパーに行ったら刺身が美味しそうだったのでついでに買ったとして、でもカレーには使わないしカレーにも合わない刺身は余計な買い物でしかない、ということです。
つまり、運用にあった機能さえ備えていれば、それ以上に余計な機能は必要ないので、要らないものは要らない、と割りきることが大事です。
詳細はこちらの記事を参照してください。

 

matsublog2021.hatenablog.com

 

データはお金では買えない

システム更新の重要な指標、

「過去データの移行」はその代表的なものです。

例えば勤怠管理システムの場合、有給取得率、何月に有給は取られることが多いのか、平均残業時間など、現行システムから集計できるデータが蓄積されています。
5年使ったら5年分、10年使ったら10年分のデータがあります。

このデータ、捨てても大丈夫ですか?

システムを使う目的は効率化とデータ蓄積です。

過去の勤怠データをもとに、有給取得率が低い部署に原因をヒアリングして取得率が上がる施策を検討したり、残業時間の推移を監視して、過去平均対比で跳ね上がった部署があれば原因を調べて対策したり、勤怠状況の改善をするにはデータが必要です。

そのため、新しいシステムを選ぶ際には過去データが移行できるかを確認しましょう。

現行システムの後継品への移行はできるケースが多いです。
一方で他社製品への移行はハードルが高いです。
単純にCSVで移せればいいですが、そもそもの設計仕様がまるで違う製品への移行だと、かなりの工夫が必要か、出来ないケースも多いです。

また、現行システムが移行を許さない、あるいは難しい設計になっている可能性もあります。

私は前職で他社製品のデータを分析して自社製品用にコンバートする仕組みを開発していたことがありますが、製品によっては項目名がランダムな英数字だったりで、意地悪されている気分でした。。。

そのため、他社製に乗り換える際には過去データを捨てる覚悟をしましょう。

一つの良い機能を手に入れるには過去データが引き換えになる可能性があるということです。

蓄積されたデータというのはお金では変えません。

自社の過去5年の勤怠状況や販売実績、顧客情報を販売してくれる企業はありません。自社のデータは自社でしか持ち得ないので、過去データの移行については十分慎重に検討してください。

データ移行失敗例

私の勤め先では顧客管理システムをkintoneに変更しました。

現行システムはCSVを作成できましたが、kintoneで作成したアプリとはデータの持ち方がかなり異なり、CSVインポートでは移管できなくなってしまいました。

移行後1年くらいたった今でも、手作業でExcelで修正して移行できるように調整しています。何とか移行はできそうですが、手作業なので手間がかかりすぎているのと、制度にも疑問が残ります。

Kintoneなので簡単に移管できる形でアプリを作れればよかったのですが、担当者はデータ移行の必要を認識しておらず、作りたいようにアプリを作ってしまいました。

後から他部署より過去データを移すべきだという意見が出ましたが、そのときにはもう後の祭り、手作業での修正が発生することになってしまいました。

 

まとめ

システム更新で重要なこと!

  1. 安くなることは気にしすぎない
  2. 余計な機能に目移りしない
  3. 過去データの移行を意識する