Chapter 3

18第3章 WMSを導入しよう！

　基幹システムと倉庫管理用のシステム(WMS)を分ける場合、WMS側で持っておくべき機能はおおまかには決まっています。これはパッケージシステム、自社開発システムとも同様です。WMS側で行う機能、及びそれに付随してWMS側に必要となる機能を図表7に示しました。

●パッケージはどのような基準で選ぶのか?　既に多くのベンダーからWMSパッケージが提供されています。パッケージの良いところは、複数社における導入経験に基づき、必要と思われる機能が標準装備されていることが多い点にあります。そのような標準装備されている機能を活用すると、開発費用の削減、導入期間の短縮化が図られるばかりか、物流センターの高度化ノウ八ウも同時に得られることになります。　意外と知られていないのですが、物流センター業務への要件は業種により大きく違いがあります。例えば食品ですと賞味期限管理は必須になりますし、大型機械製品や精密機器の場合は出荷時の機番記録が必要になります。したがって、パッケージシステムも、どこの業種を中心に導入経験があるのかによって、組み込まれている標準機能の内容や使い勝手が大きく異なっできます。つまり、標準機能に組み込まれているから安心というわけではなく、その中身が重要になってくるのです。導入する物流センターで要求される機能を詳細に洗い出し、それに適したパッケージを選定することが望まれます。　パッケージの価格体系も、ベンダーによって大きく異なります。導入する拠点の数、使用者数など詳細の使用条件を提示し、ランニングコストも含めて正確に見積もることが重要になります。

第3章 WMSを導入しよう！

●WMSの基本機能を知ろう！

さて、いよいよWMSの導入です。しかし、いざ導入とは言っても、まず、どのような業務にWMSの機能を適応していくか?WMS選定のポイントは?基幹システムとの切り分けによる管理手法など検討すべき要素はまだまだ山積みです。さらに、導入後の最適運用のためにはWMSの運用に則した新たな業務体制や社内ルールを確立する必要があります。そこで第3章では、導入決定後のプロジェクトの進行をスムーズに行うための秘訣を解説します。

パッケージ選定のポイント

①要求仕様と標準機能とのFlT&GAP②導入・開発費用③ランニングコスト④同業または類似業種での導入経験

Chapter 3

19第3章 WMSを導入しよう！

●パッケージと自社開発システムはどう違うのか?　標準化されたパッケージシステムを使用して業務を改善するのか、それとも自社の運営に合わせたシステムを独自開発して運用をスムーズに行うのか、という判断で悩むケースもあるでしょう。パッケージシステムの場合と自社システムの場合のメリット・デメリット・注意点などの観点で比較表（図表8参照）を作成しました。システム導入の際には、これらの基準で選択・構築することをお勧めします。

図表7：ＷＭＳの基本機能

入荷予定入力入荷予定修正未入荷管理入荷実績入力入荷実績修正

ロケーションメンテナンス在庫照会在庫調整循環棚卸(部分棚卸)一斉棚卸(期末棚卸)定期補充定期補充

商品マスタ取引先マスタ仕入先マスタ社員マスタロケーションマスタ配送コースマスタ

ロケーション在庫引当出荷指示データ作成出荷先別ピックトータルピック摘み取り仕分け種まき仕分け(アソート)得意先返品受付仕入先返品出荷

基本機能 作業明細入荷予定データ(ASN情報)ASN=AdvancedShippingNotice「事前出荷情報」ともいいます。送り元が出荷検品データを事前に送信します。ASNが無い場合は、一般的には発注データを元に入荷検品を行います。

入荷商品・製品が物流センターに到着した段階を指します。

入庫(棚番(ロケーション)登録)フリーロケーション管理の商品の場合、棚番(ロケーション登録)を行います。固定ロケーション管理の場合は事前に登録します。

棚卸在庫チエツクを行います。

返品得意先からの返品受付と・仕入先への返品とがあります。

振替商品・製品のステータス変更(良品・不良品やA品・B品・C品など)を行い、出荷の可否等に使用します。

廃棄不良品を在庫から落とす処理を行います。

流通加工値札付け、セット組み、梱包などの付加作業指示やラベル発行などがあります。

ロケーション別在庫管理棚番(ロケ一ション登録)単位での商品在庫を管理します。在庫調整は理由がわかるように区分を付けて履歴をとります。

補充作業の効率化のために・商品の配置をエリアで分けて管理する場 合、ケースエリアからバラエリアへの移動や、リザーブエリアからピッキングエリアへの移動を行うといった意味があります。

出荷作業を効率よく行うために、ロケーシヨン順での指示データを作成します。また、出荷先数・出荷量に応じて、最適なピッキング方法を構築します。

マスタ管理商品マスタ基幹システム(３PLの場合は荷主システム)との整合性が必ず必要なマスタは、商品マスタ・取引先マスタ・仕入先マスタです。社員マスタは、出来れば全社統一の者が望ましいのですが、センター固有でも構いません。ロケーションマスタ・配送コースマスタ、 は物流独自のマスタとなります。

1

2

3

4

5

6

7

8

9

10

11

12

Chapter 3

20第3章 WMSを導入しよう！

●ERPとWMSの関係は?　ERP(EnterpriseResourcePlanning)とは統合型パッケージシステムのことを指します。SCMの中でもSCP(SupplyChainPlanning;計画系(需要予測システム・生産計画システム な ど ) ) の 下 位 で 商 流 管 理 を 行 うシ ス テ ム で す 。そ れ に 対 し 、W M S はSCE(SupplyChainExecution)という実行形を担当するシステムです(図表9参照)。　ERPにWMSモジュールを持つものもありますが、同一フレームワークで動作する完全なパッケージシステムの一部で日本で販売されているものはあまりありません。ERPを導入済みの場合、及びこれから導入する場合に、WM Sを E R P モジュールの一部として導入する

比較項目 パッケージシステム 自社開発ジシステム標準機能として用意されているものを使用する場合は作成不要。

標準機能として用意されている場合は対応が容易。独自のインタフェースを持つERPに対しては構築必要。但し、今後はXML(世界標準手川頁)での連携がグローバルスタンダードになっていく。

RFP(現状分析・要件定義)とFIT&GAPの大きさに左右される。パッケージシステムに業務を合わせる場合は短期間での導入も可能。業務にパッケージを合わせる場合は、改造・検証期間が長くなる。ライセンス費用は、拠点数やクライアント数で体系化されたものが多い。開発費用はパッケージシステムの標準機能の改造度に依存する。機能を後で使用する場合、標準機能にあれば追加開発は不要。

モジュールの追加で対応可能な場合もある。新規システムについては自社開発システムと同様。パッケージの構造により、追加の工数（難易度）が異なる。ハードウェア構成の変更のみで対応可能な構造になっているシステムの場合は対応可能。サーバの機種や構造に依存するシステムの場合は対応不能。パッケージシステムの設計思想に依存するが、多数の導入先をカバーしたシステムの場合、標準化された機能を持つ場合が多い。

現状システムから大きな運用変更を行う場合は、要件定義の期間が長くなることから、費用が増える結果になることもある。

同左

同左

構築必要。

該当しない

新たな開発で対応。システムの構築方法によっては拡張性の取れない場合もある。

パッケージ標準機能には使用しないものが多く、またカスタマイズが大きい場合は、自社システムとして個別作成する方が一次費用としては抑えられる。但し、その後の機能追加に関しては一から構築する費用がそのままかかる。

標準機能として用意されているものを使用する場合は作成不要。

ED1・印刷システムのパッケージシステムとの連動必要。連動先のシステムの構造により可否決定。

システムの構造とカスタマイズ内容に依る。改造不可能な場合は、システム全体の作り直しの場合もある。

作り込み必要。複数拠点管理

グローバル対応

ERP連動・基幹システム連動

外部システム連係・EDI、印刷等

導入スピード

価格

カスタマイズ柔軟性

システム拡張性

スケーラビリティ（データ量・物量増加への対応性）

業務標準化・効率化への寄与

対応言語用にローカライズが必要。各言語でのOS環境での検証作業が繁雑。

要件定義の長さに左右される。導入効果を主眼とせず、現状システムのそのままの焼き直しであれば短期間での導入が可能。

10

9

8

7

6

5

4

3

2

1

図表8　パッケージと自社開発システムの違い

Chapter 3

21第3章 WMSを導入しよう！

か、ERPとインタフェースを取って個別に導入するのかの判断基準が議論となることがあります。ERPの導入メリットとは別にして、WMSはERPと同じ考え方・判断基準で導入しても良いのか、という点が1つの判断ポイントとなります。　前述の通り、商流(基幹システム)と物流(WMS)は効率化の考え方の点では大きく異なります。物流作業の効率化を考慮して商流システム(ERPモジュール)を導入する場合、システムの処理過程がWMS単独システムの場合より多くなることで、処理速度の確保のためにより大きなサーバスペックやインフラ(回線)が必要となることもあります。　これに対し、グローバル物流の効率化を主眼としてERPモジュールを導入する場合など、集中処理が必要であることや、物流管理を分散化出来ない(原材料・部品物流・調達物流などの)場合は、現場作業性を重視する必要性がなく、WMSを導入してまで解決すべき問題は少ないと言えます。　導入目的や、現場作業性(端末のレスポンス速度・ラベル印刷スピードなど)を確保す必要性があるか否かが、ERPで実行系(WMS)までカバーするのか、それとも外部WMS接続するのかの選択基準となると言えます。　また、商流の慣習や営業側でのルールで、出荷日基準で請求書を出さないとのいった商慣習に左右されるイレギュラー処理が有る場合、WMSからの実績データを販売管理システム側で調整するのか、WMS側で実績データを調整するのか、問題となることがあります。基幹システムはERPを使用し、WMSについてはERPと別のパッケージで運用することでその問題の解決を行っている企業も有ります。例えば、ERPのモジュールで物流までを管理した場合、出荷実績で自動的に請求書を出してしまうことから、これを回避するため、WMS側に「手動(人判断)で実績をERP側に送る」という調整機能を持たせ、ERPとWMSを自動連動させない形にすることもあります。本来、業務の標準化(＝イレギュラー処理を極力減らす)という意味ではERP及びWMSの本質とは相反するものですが、取引先とのルール・日本の商慣習までを自社のERPの構造に合わせることは事実上難しく、WMS側でコントロールせざるを得ないということのようです。

図表9

Chapter 3

22第3章 WMSを導入しよう！

●基幹システムとの切り分けによるWMSでの管理ポイント1.マスタ管理　商品マスタ・取引先マスタ・仕入先マスタなどは会社運営上重要なマスタとなりますので、商流(基幹システム)と整合性を取る必要があります。一般的には基幹システムからデータを転送し、常に同一のものを使用します。実は、商品マスタの整備がWMS導入成功の鍵となることが往々としてあります。商品知識が無い作業者でも間違わずに確実に作業を行うためには、商品マスタ管理は重要なポイントになるのです。重複JAN(新製品が出た場合にも同一のJANが振られている場合)の処理や、単品管理をどこまで行うか、取引先・グループ企業との商品コードの共有化、などがその例となります。重複JANをはじめとするバーコードの扱い方については本章で後述します。また、商品マスタの不整合の問題でWMSの稼働がうまく行かなかった事例を第5章で紹介しています。　商品の重量・容積情報については、棚の容積計算で空き棚検索を行ったり、梱包容積計算で梱包数を算出したりなど、物流を効率化するために必要となることがあります。一般的にこれらは商流には不必要な情報のため、基幹システムの商品マスタに登録が無いことがしばしばです。その場合、WMS側で登録・メンテナンスをする必要がありますが、基幹システムから転送された商品マスタをメンテナンスする場合は、整合性の取り方が問題となります。WMS側で基幹システムとの不整合を起さないマスタ構造になっているかを導入前に調査する必要があります。　これに対してロケーションマスタやルート(配送コース)マスタなど、WMS側でのみ必要となるマスタについてはWMS側で管理(登録・メンテナンス)を行うことが一般的です。2.入荷残管理　発注行為(販売管理)と密接ですが、分納対応や出荷残(先日付出荷)管理との関係で商流にて管理するのか、WMS側で管理するのか判断が難しい部分です。一般的には、発注コントロールを行う商流で発注残管理=入荷残管理を行い、当日入荷予定データのみを商流からWMSに毎日渡し、その日分の入荷予定のみをWMSで管理します。販売とも絡む発注取り消しの判断は、物流側では出来ないからです。3.在庫管理・在庫引当　商流では総数の在庫管理(論理在庫管理)を行い、WMSではロケーション別在庫管理(物理在庫管理)を行います。「物理在庫」については、「実際に有る商品の在庫」という意味で「現物在庫」とも呼びます。取引先の出荷優先順位や在庫戦略をもつシステムの方で優先順位の引当を行いますので、一般的には商流で一次引当を行い、その指示に基づいてWMSでロケーション引当(出荷作業の効率化と鮮度管理を図った引当指示)を行います。　論理在庫管理は、前述の通り、基幹システムでの伝票の処理を基本としたデータになりますので、伝票基準の在庫管理となります。商流だけで管理する場合は、入荷伝票の入力時点で在庫計上し、出荷伝票(納品書)の出力時点で在庫を引き落とします。さらには、入荷予定データを引当用の在庫(論理在庫)に算入し、先日付の出荷予定を作成することもあります。これに対し、物理在庫管理では、入庫(出荷可能な状態=ロケーション在庫計上)時点で引当可能な在庫として計上し、出荷実績を作成した時点(検品時)に引当用の在庫を引き落とします。この結果、論理在庫と物理在庫はデータの受け渡しタイミングによっては在庫数がずれることも生じます。　棚卸時に論理在庫と物理在庫を合わせる場合には、物理在庫を正として論理在庫を修正する方式が一般的です。

Chapter 3

23第3章 WMSを導入しよう！

●WMSのシステム構成にはどのような種類があるのか?1.集中管理・拠点分散管理　集中管理とは、WMSの管理サーバ(データベースサーバ、アプリケーションサーバなど)を1ヶ所に置き、複数の物流センターの管理を行う構成を指します。　拠点分散管理とは、個々の物流センターにサーバを置いて管理する構成を指します。以下、それぞれのメリット・デメリットを簡単にまとめました。

2.WEB方式と非WEB方式　WEB方式と非WEB方式のシステムの大きな違いとは、入出力や紹介画面用の端末(PC)に専用のシステムをインストールして使用する必要があるのか、それとも、WEBの画面(インターネットエクスプローラーなどのブラウザ)を使用し、特別なシステムを必要としないのかという点にあります。

●WMS導入前の作業システムの設計　まずロケーションと棚の種類・数を決定します。物流センターが1層なのか、2層(それ以上)なのかで作業の組み立てが大きく変わります。入荷から保管、出荷までに至る動線を効率化す

集中管理メリット デメリット

拠点分散管理

①サーバ管理者を複数拠点に置く必要が　無い。 ②システムのバージョンアップや保守作業　を1拠点でメンテナンス出来る。

①ネットワーク費用(回線・セキュリティ構築　など)がかかる。②拠点の障害(天災でのサーバ障害・回　　線障害など)が発生すると全拠点で使　　用出来なくなる。①システムの管理が統一的に出来ないた　め、システムのバージョン管理工数や　システム管理者の工数が増える。②バックアップシステムの構成を、拠点単　位で構築する必要がある。

①個々の拠点の特性に応じたシステム構　築が柔軟に出来る②大規模なネットワーク構築の必要性が　　ない。

システム構成 拡張性 構築の際の留意点①サーバとして、データベースサー　バ・アプリケーションサーバの他　に、WEBサーバが必要。②大きく分けて、「 J A V A 」と「.NET」の2種類で構築。それぞれフレームワーク(基盤システム)やミドルウエアが異なる。

①サーバ構成として、データベース　サーバ・アプリケーションサーバ　が必要。②開発言語や通信プロトコルは多　様。

①拠点単位でシステムのイン　ストールなど個別の作業が　必要。②他システムとのデータ連携;　低～高　オープンシステムであれば、　容易に取りやすいが、そうで　ない場合は、個別開発が必　要となることもある。

①拠点拡張性;高社内ネットワークを構築した拠点には、通常のPC(ブラウザ)を置くだけで、使用可能。②他システムとのデータ連携;高

①セキュリティの構築。②他システムとのデータ連携;高　使用感が影響を受ける。③マテハン機器用のサーバについては、別途個々の拠点に設置の必要性有り。

①単一拠点の場合は、単純な　クライアント・サーバ型で良　いが、複数拠点管理を行う　場合は、エミュレーションソ　フト等のミドルウエアが別　途必要となる。e.g.MetaFrame②システムのライフサイクルの　検証が必要。マイクロソフト社　のサポート期間やその他のシ　ステムベンダーの保証期間を　勘案して構築。

Chapter 3

24第3章 WMSを導入しよう！

るため、仮置きエリア・リザーブエリア・ピッキングエリアの決定を行い、ロケーションを考慮します。1層でも数千坪を超える場合は、歩行距離が大きくなりますので、特に動線の最短化が必要となります。複層の場合は、上下の商品の移動を最小にするようロケーションを考慮します。棚の種類は保管予定量(入出荷量・在庫量)と在庫回転率によって軽量棚・中量棚・重量棚・フローラックなどの選択とその容積で数量を決定します。　マテ八ン機器の導入状況で、作業の組み立てが変わります。作業の組み立てを柔軟に変更できるようにするために、可能な限り固定的なマテハン機器を使用しない物流センター作りが大切なことは前述しました。

●WMS導入前の商品マスタの整備○1つの商品コードに複数の商品が登録されているケース　いわゆる重複JANと呼ばれるケースがあります。1日製品から新製品へ切り替わる際に、パッケージなど外装が変更になったにも拘わらず、メーカー側でJANコードが変更されず、そのまま使用されているような場合です。客先からの注文は新製品であったとしても、旧製品でバーコード検品を行った際に誤出荷とはならず、間違って出荷する結果となることもあります。これを回避するために、新製品が出た際には別の社内コードを振り、その商品の棚にはバーコードを印刷して貼り、新製品のみはこれで検品するという運用ルールで回避することも有ります。　但し、この商品もいずれ定番となりますので、現場のイレギュラー処理を減らすためにも状況に応じて適時マスタメンテナンスをすることが必要です。○1つの商品に複数の商品コードが存在するケース　社内コードとJANコード、ボールJANコード、ケースITFなど1つの商品で幾つかコードを持つ場合などがありますが、棚配置や入荷の時の荷姿などで使用方法が異なることがあります。入荷の際に、外装にバーコードが無い場合、ケースを開封して商品を取り出す手間が生じますが、外装にITFコードが有る場合は、これをマスタ登録し、入荷検品時に用いることで作業の効率化が図れます。　また、出荷検品については、バラ出荷エリアとケース出荷エリアを分けた棚配置の場合、ケースを出荷する際にはケースコードで出荷検品出来る方が効率的ですが、ケースとバラを同時に出荷するような商品の棚配置の場合は、JANコードで出荷検品出来る方が効率的と言えます。　また、上記のように、バーコード検品する際に、重複JANの問題を解消するために特定の商品だけ社内コードのバーコードシールを作成し、検品するケースもあります。

●WMSだけで全ては解決出来ません～運用ルールとPDCA　センター業務の効率化や問題解決は、適切な人員や商品の配置と、入荷・出荷の動線の考慮など、システム以外で実現すべきものがあります。どんなに素晴らしいシステムを導入しても、システムを導入することでどのような効果を実現するのか、そのためにはどのような作業をしなければならないのかを理解し、システムがスムーズに稼働する環境でなければ、WMSは「絵に描いた餅」になってしまいます。ですので、WMSの導入に先立ち、事前に庫内作業のルール化を行い、全体最適化を主眼として業務の標準化を行うことが重要です。　例えば、「ロケーション管理を行う」ということは、「ロケーション登録を行う」という作業が適切なタイミングに必要です。この作業を忘れたため商品が出せず作業がストップし、作業者が手待ち状態(ボトルネックになる)ことで、出荷が出来なくなってしまうことにもなりかねません。さらには在庫が合わなくなり不要な棚卸作業が発生してしまうなど、庫内作業全体の基本が崩れていく可能性もあります。

Chapter 3

25第3章 WMSを導入しよう！

　ですので、物流コスト低減化においてのWMSの役割は、「業務を標準化・単純化し、商品知識を有しない作業者での運用を可能にする」というプロセスの実行とチェック(PDCA:PlanDoCheckAction)にあると言えますが、「何故その作業が必要なのか」は作業者にも必ず理解されなければなりません。　WMSの導入失敗例にもあるように、業務効率化やさらには業務改革においては、会社内での理解がなければうまく進みません。作業者から管理者に至るまで、全員が「何故この作業は必要なのか」「何故この作業はやってはいけないのか」を理解したセンター運営が重要なのです。　但し、「人は間違う」ことを前提として、可能な限り「間違わないシステム」にすることがポイントです。WMSは作業実績だけではなく、誤作業と未作業のチェック機能を持つことが必要となります。　以下に、WMS導入までに行う前準備および運用ルールを列挙しました。

　効率的なセンター運用は、過剰なシステム化でもなく、人海戦術に頼り過ぎるのでもなく、長期的な目で全体最適化を数値化し、費用対効果を取りながら実現することが重要です。分析から実行に至る一連の過程では、常にシステムと運用のどちらで解決していくのかを峻別しながら検討していくことが必要です。　そのようなシステム構築の際には、外部コンサルタントやシステムベンダーに依存しがちですが、実際に実行する自社の力で管理できる体制を作ることが成功の秘訣となります。その際には、経営者層の決断力・実行力が鍵となります。トップの決断なくしては、会社の運営はス

自社の状況・実態を理解する ・競合状況、取引先状況、社会情勢 ・社内組織・システム

1

2

3

4

5

6

789

自社の目標を定める ・物流サービスレベル ・顧客サービスレベル ・物流経費 ・環境対策

目標達成のための具体的方策を作成する ・WMS要件定義 ・運用の標準化・運用フロー作成

実態と目標の差異を分析する

具体的方策を実行する為のWMS研修を行う

具体的方策の実行(WMS実行)実行状況の進捗管理る為のWMS研修を行う実行状況に応じた軌道修正

目標達成のための社内組織を構築する ・効率的な組織構成 ・管理者の役割分担と責任の明確化 ・問題発生時の解決フローの作成 ・部署間と部署内の連絡・調整

◎

◎

◎ :主導者　 ○ :参加必須者　 △ :可能であれば参加が望まれる

◎

◎

◎

◎◎◎◎

○○○

○

△

△

○

○

○

○準備作業・運用ルール 経営者層 管理者層 作業者

Chapter 3

26第3章 WMSを導入しよう！

ムーズに動きません。また、状況に応じた軌道修正に加えて、会社状況の変化に対応すべく、1から9までの過程を反復(PDCA)し、常に改革・改善の意識を保つことも必要です。

知っておきたい「物流におけるトレーサビリティ」ワンポイント

　BSEや食品の偽装表示問題、食の安全性への意識の高まりから、食品のトレーサビリティが話題になっています。原材料の生産地表示、畜産物における餌や生育方法などに感心が高まっていますが、真のトレーサビリティとはこのような原材料の安全性確保の話だけではありません。また、トレーサビリティが必要なのは食品ばかりではありません。　トレーサビリディは日本語では追跡可能性と訳されます。商品・製品には2つの方向での追跡可能性が要求されます。一つは、消費者や流通業など川下側から遡って、この商品・製品、さらには原材料が、いつ、どこで作られ、どのような経路で手元に届いたのかを追跡でぎることです。消費者が購入した商品について原材料の安全性を知りたいという場合がこれにあたります。もう一つは、川上側の立場で、あるロットの原材料を含む製品が、現在どこにあるのかを追跡できることです。メーカーが製品の特定ロットについて不具合が見つかり回収したい場合は、この方向でのトレーサビリティが必要になり宏す。その意味で、家電製品でも、自動車製品でも、トレーサビリティは必要なのです。　トレースが必要なのは原材料だけではありません。どの工場のどの設備で作られたものなのか、どの倉庫にいつからいつまで保管され、何月何日のどのトラックで輸送されたのかという情報もあった方が望ましいのです。数年前にあった乳製品による集団食中毒では、このトレーサビリティが確保されていなかったために原因究明に長い時間がかかりました。この例ほど大きなものではなくても類似する問題は、例えばある倉庫の温度調整装置が故障した、ある車両の保冷設備が故障したという場合でも起こりうるのです。　真のトレーサビリティとは、原材料供給業者、メーカー、卸、小売、および物流事業者にとっては、トラブルが発生したときに迅速に原因を究明し、回収が必要な場合はそれを短期間かつローコストで行うための仕組みなのです。また常日頃からこれを徹底することにより、従業員にリスクを低減させることについての意識を高める効果も生み出します。

どの原材料を使い、どのロット、トラック、倉庫を経たものがどこに行ったかがわかるか？

どの原材料を使い、どの製造設備、トラック、倉庫を経たかがわかるか？