画像素材:Funtap/PIXTA
<目次>
倉庫管理システム(WMS)は今や物流センターの必需品です。各社のパッケージソフトの導入実績数も年々増えて積み上がり、完成度もあがっています。しかし、WMS導入時の混乱や導入トラブルは減るどころかむしろ増えており、時には深刻なトラブルに発展することもあります。特に近年は初期費用0円で利用できる安価なクラウド型のサービスなども登場しており、多くのタイプのWMSが市場に溢れていることから、ユーザー企業が自社にあったWMSを選択することが非常に難しくなっています。
第一次WMSブームの頃は、クライアントサーバー型で1000万円~3000万円するようなシステムに限られており、提供ベンダーも今ほど多くはなかったので、選択肢はそれほど多くはありませんでした。しかし、WMS提供ベンダーが急増し、様々なタイプのWMSが市場に溢れたことで、自社の運用や物流規模に合わないWMSを選定してしまい、失敗してしまうケースが増えているのです。そこで今回はWMS導入の基礎知識として、ベンダーとシステムの選定方法について解説したいと思います。
2.パッケージかスクラッチか?
パッケージをカスタマイズするのか、それとも自社の要件定義に合わせたシステムをゼロから構築するのか。いわゆるパッケージかスクラッチかの迷いは、WMS選定時に誰もが最初に通る道でしょう。よほどの特殊性やこだわりがない限り、もしくは開発したWMSで版権を持って外部販売するつもりでもない限り、私はパッケージの採用をお勧めします。実績を積み上げた完成度の高いパッケージが既にいくつも製品化されています。WMSのパッケージを選定する際は、大きく2つに分けて考えると良いでしょう。
1.外資系 or 国内系
2.オンプレミスかASPか
将来的に海外進出を計画しているような企業であれば、あらかじめ外資系パッケージを選んでおくと安心でしょう。ただし、外資系パッケージは日本の細かい仕様に関するカスタマイズの要請に柔軟に対応できない場合が多いです。開発ベンダーを通して海外本社に問い合わせを入れても適切な返事が戻ってくるとは限りませんし、レスポンスはどうしても悪くなります。つまり、パッケージに実務を合わせるという基本方針としなくてはなりません。
その点はやはり、国産パッケージの方が直接コミュニケーションが取れる分だけ柔軟性は高いです。また外資系パッケージと比較するとライセンス料なども低額です。ただし、カスタマイズをやり過ぎるとせっかくのパッケージの完成度という面でのメリットが薄れてくるのでやり過ぎには注意が必要となります。
3.オンプレかASPか?
近年、最も多い失敗ケースがクラウド型のASPサービスのWMSを選択して、自社の運用に合わずに結局は使えなかったというものです。本稿では、”オンプレミス”は自社専用のサーバー(クラウドの場合も有り)に自社専用のパッケージを導入すること、ASPは共有のサーバーとシステムを月額利用(サブスクリプション)で利用する場合として説明します。
ASPは何よりイニシャルコスト(導入の初期費用)が低額かつ、月額の利用で導入をスタートできる点が大きな魅力です。例えばECのスタートアップ企業などであれば、WMSにいきなり数千万円の初期投資は困難です。しかし、アナログで出荷作業を行っていたのでは、事業を適切にスケールさせることができません。そういった場合、月額で利用できるASPサービスのWMSは強い味方になってくれるでしょう。
しかし、ある程度の物流規模や、長年運営されているような物流センターの場合、システムの本稼働後も取り扱いアイテムのバリエーションが増えたり、在庫引当や入出荷のルールが変更になったり、倉庫を増床するなど、環境が変化する場合も多く、それに応じてWMSを柔軟に改修する必要があります。このような企業では、ASP型のサービスを導入する際に以下のリスクを予め検討する必要があります。
検討リスク1:カスタマイズが柔軟に行えない
ASPサービスは基本的に1台のサーバーと1本のプログラムソースを複数のユーザー企業が共同で利用します。賃貸マンションのようなイメ-ジですね。その分、低コストで利用が可能です。しかし、複数のユーザーが共同でリソースを利用するため、自社専用のカスタマイズは基本的にNGです。どうしても自社専用のカスタマイズしたい場合、サーバーもソースも自社専用になるので、途端にコストが跳ね上がります。もともとASP型のサービス提供ベンダーは個別にカスタマイズをする開発体制を持ち合わせていないため、要件定義、設計、カスタマイズといった請負型のプロジェクト運営が苦手です。よって、コストが跳ね上がるのですが、苦手な作業ということもあってカスタマイズ作業で混乱が生じることも少なくありません。作業を標準化することを目的として、パッケージ機能に無理やりでも合わせるという覚悟があれば、ある程度の物流規模でも導入は可能ですが、その場合はトライアル運用をするなど、十分に機能と運用のFit&Gapを行ってから進めることをお勧めします。
検討リスク2:データ量が増えると動かない
先に説明した通り、ASPサービスは1台のサーバーを複数のユーザーが共同利用するため、データ量の制限が自社の専用サーバーで運用するより厳しく設定されています。よって、1日の出荷行数が1000行を超えるような場合は、途端に処理が遅くなり、場合によっては途中で処理が止まって動かなくなるといったケースが散見されます。そのような場合、自社専用のシステムであれば、サーバーのスペックを上げたり、プログラムソースをチューニングしたりすることで改善することが可能ですが、ASPサービスはそのような個別ニーズに対して融通が利きません。仕方なく、1回に取り込むデータ件数を減らし、3回に分けて取り込む運用に変えて回避するといったことが起こります。自社の物流規模やデータ量を現状と数年後で試算した上で、ASPにするのか、オンプレミスにするのか検討することが大事です。
検討リスク3:物流の基本的機能や知識の不足
ASPサービス型のWMSの多くはここ数年でリリースされた商品も少なくありません。よって、基本的なWMSに必要な機能が備わっていなかったり、ベンダー側の物流の基礎知識が不足しているといった不満が多くのユーザーから上がっています。例えば、出荷指示データを基幹システムから取り込んだ際に、在庫を引当(在庫予約のようなもの)して、引当された在庫をピッキングリストとして出力するといったWMSの一般的な機能があります。このとき、まだピッキング処理前であれば倉庫に在庫はあるのですが、WMS側では在庫がゼロになってしまうといったことがありました。
ベンダー側に確認をすると、これは基本仕様という回答です。小さなスタートアップであれば問題ありませんが、例えば複数の荷主の在庫を預かっているような物流センターだと、そもそもこの基本仕様だと使い物になりません。ユーザー企業からすると当たり前の機能だと思っていたので、そこまではベンダーに確認は取らなかったとのこと。利用して初めてそうした基本仕様の不備に気付いても、ASPは基本的にカスタマイズ不可ですし、そのような根幹の基本仕様を変更するとなると、膨大なコストと時間を要することになります。
検討リスク4:数を捌くビジネスモデル
ASPサービス型のWMSは基本的には1つのソースをより多くの企業に利用してもらうことで事業成長するビジネスモデルです。1社単位の利用額は小さくても、数を集めることでストック収益を確保します。よって、必然的に回転率を上げることが目的となります。できるだけ手間とコストをかけずにシステムを導入したい企業とは相性が良いと言えます。しかし、自社の事業戦略と物流戦略を関連付けさせたり、中長期的に物流システムに投資したいような企業だと、そもそもベンダーとユーザー企業の目的が一致しません。どんどん新規ユーザーを獲得して回転率を上げていきたいベンダー企業と、じっくりと腰を据えて物流システムを構築したいユーザー企業とでは、価値観や意見が合わずにお互いにフラストレーションをためることになってしまいます。この”お互いに”というのが実はポイントであり、こうしたミスマッチによって不満を感じるのはユーザー企業だけではなく、ベンダー企業も同じだということです。
こうしたギャップはプロジェクトがスタートする前はなかなか気づけないので、あらかじめ自社のWMS導入の目的や方針をしっかりと理解した上で、価値観や方針が合うベンダーを探すことは、WMSの価格や機能以上に重要な要素となります。
4.WMS選定ミスはユーザー企業だけの問題ではない
社内の人材やリソースだけでWMSを構築できる物流センターは稀です。まずは誰に相談すべきか?その答えは自社の企業規模、物流規模、今後の事業戦略によって変わってきます。単純にWMSを導入するだけ、安く早く導入したいというだけであれば、ネットで検索して実績がありそうなASPサービスを取り扱うベンダーを選択するやり方もあながち間違いではありません。時間をかけていられないという場合もあると思います。
しかし、それではやはり不安だという場合、あるいはWMSだけではなく物流全般の見直し、マテハン機器の導入も同時にするような場合には、物流全体をしっかりとコーディネートできる専門家に支援を仰ぐ必要が出てきます。WMS選定のミスマッチ問題は、ユーザー企業側だけの問題ではありません。提案する側のベンダー企業の営業担当者も、ただ契約を取り付ければ良いのではなく、自社のWMSの特徴に合ったユーザーをしっかりと選定することでお互いがハッピーになれるのだと思います。