2023年7月号
特集
特集
事例で学ぶWMS導入プロジェクトの進め方
ＷＭＳの役割と導入効果
日本企業の多くはこれまでＷＭＳ（Warehouse Management System：倉庫管理システム）に大規模な投資を行わず、一度導入したＷＭＳや在庫管理の仕組みを時代に合わせて少しずつ改修しながら利用してきた。
しかしながら従来の場つなぎ的な対応は限界に来ており、物流拠点の新設や自動化機器の導入に併せてＷＭＳの導入・刷新を迫られるケースが増えている。
ここでおさらいをしておくと、ＷＭＳは文字通り倉庫内の業務を管理するためのシステムだ。
入荷や出荷の作業を現場に指示・記録したり、どこに何があるかを管理したりするのが基本的な機能である。
ＷＭＳを導入すると、これまで紙で行っていた管理業務をシステムで行えるようになり、管理作業の工数が大きく削減される。
人的作業によるミスを防ぐ効果もある（図表１）。
ＷＭＳは倉庫内のさまざまな機器と連携してデータを送受信する機能も備えている。
ハンディターミナル（ＨＴ）などを利用して入荷・検品・棚入・ピッキングなど倉庫業務の効率化を図る場合にはＷＭＳが必須となる。
近年は人手不足の影響から自動倉庫・ＡＧＶ（無人搬送車）などの自動化機器を導入する企業が増えているが、これらの制御システムもＷＭＳと接続することが前提となっている。
ＷＭＳの導入効果は倉庫内だけにとどまらない。
ＷＭＳ上には倉庫内の活動に関するさまざまなデータが蓄積される。
これを在庫回転日数や保管効率などのＫＰＩ（重要業績評価指標）に可視化して経営判断に役立てることができる。
近年、物流業界では、複数の企業が協力して荷物の保管や輸配送を行う共同物流の動きが活発化している。
インターネットのパケット交換の仕組みを物流に適用する「フィジカルインターネット」も注目されている。
複数の企業が倉庫や車両などを共有し、規格化された荷姿の貨物を共同で輸送しようとする仕組みであり、共同物流の究極的な姿と言える。
これらの取り組みも荷主企業や物流事業者などそれぞれの企業がＷＭＳ上で自社の物流データを管理していることが前提となる。
ＷＭＳ導入を阻む三つのハードル 既にＷＭＳが広く普及している昨今でも、ＷＭＳの導入をためらっている、あるいはＷＭＳの更改をなかなか進められない企業は少なくはない。
ＷＭＳの導入に際して多くの企業が頭を悩ませるハードルとして以下の３点が挙げられる（図表２）。
①投資の承認 ②システム連携 ③導入プロジェクト推進体制 以下に一つ一つ確認していこう。
①投資の承認 ＷＭＳに限らず、システムを導入する際には、その必要性について社内の合意をとる必要がある。
導入プロジェクトの開始からシステムが稼働するまでの費用に加え、稼働後の運用保守や改修の費用もある。
ＷＭＳの導入に併せて新しくプリンターやＨＴなどの機器が必要になる場合があり、その費用も相当な額になる。
従来から日本企業は物流部門に低コストで運用することを求める傾向があり、物流に関する投資はなかなか理解を得られにくい。
しかしながら、ＷＭＳの導入効果は前述の通り単なるコスト削減にとどまらない。
今やＷＭＳは一定規模以上の倉庫であれば必要不可欠なインフラである。
当社の顧客にも、業務効率化の観点では費用を回収する見込みは低いものの、あえてＷＭＳの導入を決断した企業はある。
人手不足の状況下で今後も物流を維持していくためにはＷＭＳは必要との合意を得た。
実際、ＷＭＳは業務効率化による残業時間の短縮だけでなく、それに伴う従業員満足度の向上、作業の簡略化による高齢者・外国人作業員の活用、共同物流の利用拡大などを期待できる。
そのような金額だけでは測れない効果をあらかじめ明確にしておくと、社内の合意を得る上での一助となるだろう。
②システム連携 ＷＭＳは他のシステムとデータ連携を行う。
多くの場合、ＥＲＰ・基幹システムと連携しており、入出荷の指示を自動で受け取れる。
ＴＭＳ（輸配送管理システム）や倉庫内の自動化機器など、その他のシステムとも連携する（図表３）。
先述の共同物流やフィジカルインターネットでも自社物流データを他社に連携する必要が出てくるなど、ＷＭＳと他システムの連携は今後さらに拡大していくと想定される。
システム同士がつながっているということは、新システムの導入や入れ替え、機能追加などを行う際には、つながっている他のシステムすべてについて変更の影響が出ないように準備しなければならないということである。
従ってＷＭＳの導入を進める前に、社内にどのようなシステムが存在し、そのうちどのシステムがＷＭＳと連携するかを把握しなければならない。
しかし、多くの企業で、情報システム部門でさえ、社内にあるシステムの全貌は把握できていない。
そのため、ＷＭＳ導入推進チームが主導して周辺システムの構成を把握する必要がある。
この作業はＷＭＳに関わるメンバーの知見だけでは難しいため、通常は社内のＩＴ人材や、必要に応じて外部の専門家の力を借りることになる。
③導入プロジェクト推進体制 ＷＭＳを導入する際は、システム自体の設計・開発は専門知識を持った外部のベンダーに任せるのが一般的だが、ベンダーなどのパートナー企業の選定や、プロジェクト管理は自社で行わなければならない。
どのような役割・機能を持ったシステムにするかという要件定義についても、社内メンバーによる意思決定が求められる。
複数の倉庫拠点がある場合には、それぞれの拠点の役割や特性・業務を確認しておく必要がある。
しかし、長期にわたって物流協力会社に運営を外部委託している拠点では、手順書などの業務を定義した文書が揃わないことが多い。
その場合には現状の把握から着手しなければならない。
これらの役割をこなすには、システムに詳しい人材だけでなく、現場業務に詳しい人材にもプロジェクトに参画させる必要がある。
しかし、現業との兼任でプロジェクトに参画させると通常業務に追われてしまい、プロジェクトに十分な時間を割けなくなる。
この問題については後ほど詳述する。
各導入プロセスにおけるポイント ＷＭＳ導入プロジェクトは通常、「①企画・構想」「②要件定義」「③構築」「④展開」というプロセスで進められる。
各プロセスにおけるポイントについて事例を交えながら説明する（図表４）。
①企画・構想 企画・構想のプロセスでは、ＷＭＳ導入の目的、目的を達成するための導入方針、導入の範囲など、プロジェクトの根幹に関わる検討を行う。
この検討が不十分だと、要件定義以降のプロセスで想定外の要件を取り込む必要に迫られる。
開発工数の増加、それに伴うコストの増加、スケジュールの遅延といった問題を招く。
そうした事態を避けるには以下の点に留意が必要だ。
⃝サプライチェーン全体においてＷＭＳが担うべき役割／機能を定義する ＷＭＳが担う役割は近年多様化している。
自社が目指すサプライチェーンにおいて、倉庫業務・ＷＭＳはどのような役割と機能を担うことになるのか、その将来像に向けてどのように変わっていくのかを明確にしなければならない。
食品メーカーＡ社では、全社的に「トレーサビリティ向上」に取り組んでおり、原材料の入荷から生産、製品の出荷に至るまで、従来よりも細かい単位でロット情報をトレースすることを目指していた。
従って本来であれば、トレーサビリティ向上のために倉庫内ではどのような情報を取得する必要があるのかを明確にした上で、ＷＭＳの役割・機能を定義する必要があった。
しかし、ＷＭＳの役割・機能の定義があいまいなまま開発は進んだ。
その結果、倉庫で取得できるデータはＷＭＳ導入後も導入前と同じという状態になった。
結局、システムの稼働後に改めて機能改修することを余儀なくされた。
同社だけでなく広く見られる典型的な失敗事例である。
⃝パッケージのメリットを最大限に享受する それぞれの企業には固有の業務が存在する。
日本企業にはそれが特に多い。
物流業務も同様だ。
倉庫ごと、製品カテゴリーごとなど、さまざまな軸で固有の業務フローが追加されて、年月をかけて複雑化・属人化している。
そのため、企業間で協業しようとする際などに障壁となる。
共同物流の拡大、さらにはフィジカルインターネットの動きを踏まえると物流の標準化が求められている。
固有の業務を削減して業務のバリエーションを減らすことは、現場の人手不足対策という点からも必要である。
データの種類・仕様なども業界標準に合わせるべきである。
ＷＭＳパッケージの導入は、オペレーションの標準化を進める有効な手段である（図表５）。
ＷＭＳパッケージはベストプラクティス、つまり多くの企業が採用する効率的な業務方法やデータの持ち方を体現している。
それを実装することで短期間で標準化が実現する。
パッケージを利用するメリットは他にもある。
ＷＭＳは、会計や生産、販売など、社内の他システムと連携する。
社外の配送業者や業界ＶＡＮなどの情報基盤と連携することも多い。
パッケージは一般的に想定される社内外のシステムとの連携機能を標準でカバーしている。
開発にかかる時間・コストを抑制できる。
加えてパッケージには、法規制の変更や業界動向に合わせた追加機能の提供を期待できる。
導入後も最新のベストプラクティスに継続的にアップデートできるということである。
そのためパッケージの選定にあたっては、自社と同じ業界の導入実績が豊富なものを選ぶと良い。
⃝〝標準に合わせる〟を徹底して業務を再検討する ＷＭＳパッケージを採用したら、追加開発は極力避け、パッケージの標準機能をベースにした標準業務フローに合わせる〝Fit to Standard（標準に合わせる）〟を基本方針として、現行の業務を見直すべきである（図表６）。
システムを業務に合わせようとしてアドオン（新規機能の追加）やカスタマイズを増やせば、それだけ標準から離れてしまう。
開発が長期化してコストも増加する。
さらには追加開発した機能が邪魔をしてＷＭＳベンダーから提供されるアップデートを適用できない場合がある。
⃝倉庫・システム数に応じ段階措置も視野に入れる 倉庫が複数あると、倉庫ごとに使用しているＷＭＳが違ったり、委託している３ＰＬが違ったりして、標準化の難易度は上がる。
しかし、その場合でも倉庫機能（ＴＣ／ＤＣ）や取扱製品などの観点から、可能な限り業務パターン数を減らすことが標準化の第一歩である。
倉庫運営を委託する３ＰＬ業者を共通化することも、業務フローを標準化する一つの方法である。
複数の倉庫を持つ企業が共通のＷＭＳを導入すれば、業務の標準化に加え、情報の集約・蓄積・分析がやりやすくなる。
ただし、ＷＭＳを横展開するのは時間がかかる。
拠点数によっては、情報の集約・蓄積・分析ができるようになるのは何年も先ということにもなりかねない。
過去に当社がＷＭＳ導入を支援した卸売企業Ｂ社は約30カ所の倉庫で異なるＷＭＳを使っていた。
自社のＷＭＳもあれば、庫内作業を委託している３ＰＬのＷＭＳを使用している倉庫もあった。
そこで全ての倉庫に新しい同一のＷＭＳを導入する方針を打ち出した。
しかし、システムの入れ替えが完了するまでには長い年月がかかることが予想された。
そこで新ＷＭＳが一部の拠点で稼働するのに合わせて、新・旧含む全ＷＭＳの上位に、物流関連情報を集約する統合物流管理システムを導入した。
これにより全倉庫の一元管理が可能になった。
ＷＭＳの在庫情報を統合物流管理システムで変換してＥＲＰシステムと連携させることで、システム間のインターフェースを減らすこともできた。
Ｂ社のように拠点数の多い企業が、〝標準に合わせる〟を実現しようとする場合に、暫定的にこのようなシステム構成にするのは有効である（図表７）。
⃝〝標準に合わせる〟を推進できるプロジェクト体制をつくる ＷＭＳの企画・構想プロセスにおいて多くの企業が頭を悩ませるのが、プロジェクト体制である。
現場の同意が得られず、システムを現行業務に合わせる追加開発が増えてしまうのを避けるには、〝標準に合わせる〟の方針決定後、直ちに業務に精通したキーパーソン（将来のキーパーソンも含め）を巻き込み、取り組みを主導させることである。
ただし、現業との兼務でメンバーに選任すると、プロジェクトに十分な時間を割けないことになる。
また、キーパーソンがプロジェクトに貢献しても、それが本業ではないために人事評価に反映されないということでは、モチベーションが希薄になる。
従ってキーパーソンはプロジェクト専任とし、かつ 〝標準に合わせる〟の推進が人事考課に直結するよう本人の年間目標を設定する。
業務の標準化を推進する上で重要なのは、特定業務の利害を優先する意見を排除して、全体最適を図ることである。
公平な立場で全体を見渡すことができる人材によって、各プロセスが標準化の方針から外れていないかをチェックする体制を築くことが鍵である。
プロジェクトリーダーには全体最適の視点を持ち、部門（業務）間を調整できる人材が望ましい。
しかし、適任者が社内には見当たらないこともある。
そうした場合には、外部リソースを活用するのも一つの方法である。
②要件定義 要件定義は、「業務要件定義」と「システム要件定義」から構成される。
業務要件定義では、新ＷＭＳをベースにした業務の流れ、業務処理を定義する。
システム要件定義では、業務要件を基にＷＭＳに実装すべき機能を洗い出し、非機能要件とあわせて整理した「システム要件定義書」を作成する。
〝標準に合わせる〟の方針に基づく業務要件定義では最初に自社の標準業務フローを作成する。
システムベンダーがパッケージの標準業務フローを用意している場合はそれを利用すればよい。
それがない場合はＷＭＳパッケージの標準機能から自社の標準業務フローを作成する（図表８）。
企画・構想時に〝標準に合わせる〟という方針を定めたにも関わらず、業務要件定義を行った結果、追加開発要件が膨らんで、導入スケジュールとコストが肥大化してしまうケースは非常に多い。
顧客納品時の包装・加工方法や送付状・納品書といった末端の仕様に至るまで事細かに規定して、追加開発で機能を作り込んでしまう。
これを避けるにはまず、将来あるべき姿として標準業務フローを作成して、「現在は行っているが、標準業務フローからは外れる業務」を明らかにする。
そして標準業務フローから外れた業務を、追加開発を行っても新ＷＭＳに機能として盛り込むべきなのか、費用対効果の面から検討する。
その際に社内外の関係者との調整を必要に応じて実施することが肝要である。
専門商社Ｃ社は、すべての倉庫拠点のＷＭＳを刷新・統一するプロジェクトを発足した。
しかし、事業部ごとに取り扱う商材が大きく異なるため、要件定義を開始してすぐに、各倉庫を担当する業務部門から現行業務に合わせた追加開発の要求が殺到した。
そこで企画・構想時の〝標準に合わせる〟の方針に基づき、各部門の業務のキーパーソンを中心にして、全社標準の業務フロー策定に取り組んだ。
その上で現行業務の標準化の検討を徹底した。
業務を標準化できない部分、すなわちシステム追加開発が必要になる業務については、その要否を判断する評価軸を細かく定め、それに沿って１件ずつ評価した。
その結果、追加開発を自社の競争力の源泉となる物流機能に絞ることができた。
基本方針に則ったハイレベルな標準化が実現した。
③構築／④展開 「構築～展開」のプロセスでは、システムベンダーによるシステム開発・テストの状況を管理して、導入に向けたユーザー受け入れテスト、社内外とのシステムインターフェーステスト（連携テスト）、ユーザートレーニング、旧システムから新システムへのデータ移行などの複数のタスクを同時並行的に計画・実施することが求められる。
それぞれ依存関係があるため、あるタスクの遅延が全体スケジュールに影響してしまう。
新ＷＭＳの導入と同時に新しい倉庫拠点が稼働する場合や、在庫管理方法を変更する場合には、倉庫間のモノの移動や棚卸作業も発生する。
入出荷業務で外部業者とやり取りする帳票や連携データの変更があれば、外部業者との調整も必要だ。
トラブルによるプロジェクトへの影響を最小限に抑えるために、これらのタスクをまずは網羅的に整理する。
その上で、業務に支障の出ない移行計画を立案して、物流部門と関連する部門が協力して進捗を細かく管理する。
検討対象は広範囲にわたるため、倉庫業務および在庫管理業務に関わる購買、生産、経理、輸配送などの関係者を巻き込み、進捗管理要員を増員して、領域別に担当を明確に振り分けておくことが肝要である。
しかしながら従来の場つなぎ的な対応は限界に来ており、物流拠点の新設や自動化機器の導入に併せてＷＭＳの導入・刷新を迫られるケースが増えている。
ここでおさらいをしておくと、ＷＭＳは文字通り倉庫内の業務を管理するためのシステムだ。
入荷や出荷の作業を現場に指示・記録したり、どこに何があるかを管理したりするのが基本的な機能である。
ＷＭＳを導入すると、これまで紙で行っていた管理業務をシステムで行えるようになり、管理作業の工数が大きく削減される。
人的作業によるミスを防ぐ効果もある（図表１）。
ＷＭＳは倉庫内のさまざまな機器と連携してデータを送受信する機能も備えている。
ハンディターミナル（ＨＴ）などを利用して入荷・検品・棚入・ピッキングなど倉庫業務の効率化を図る場合にはＷＭＳが必須となる。
近年は人手不足の影響から自動倉庫・ＡＧＶ（無人搬送車）などの自動化機器を導入する企業が増えているが、これらの制御システムもＷＭＳと接続することが前提となっている。
ＷＭＳの導入効果は倉庫内だけにとどまらない。
ＷＭＳ上には倉庫内の活動に関するさまざまなデータが蓄積される。
これを在庫回転日数や保管効率などのＫＰＩ（重要業績評価指標）に可視化して経営判断に役立てることができる。
近年、物流業界では、複数の企業が協力して荷物の保管や輸配送を行う共同物流の動きが活発化している。
インターネットのパケット交換の仕組みを物流に適用する「フィジカルインターネット」も注目されている。
複数の企業が倉庫や車両などを共有し、規格化された荷姿の貨物を共同で輸送しようとする仕組みであり、共同物流の究極的な姿と言える。
これらの取り組みも荷主企業や物流事業者などそれぞれの企業がＷＭＳ上で自社の物流データを管理していることが前提となる。
ＷＭＳ導入を阻む三つのハードル 既にＷＭＳが広く普及している昨今でも、ＷＭＳの導入をためらっている、あるいはＷＭＳの更改をなかなか進められない企業は少なくはない。
ＷＭＳの導入に際して多くの企業が頭を悩ませるハードルとして以下の３点が挙げられる（図表２）。
①投資の承認 ②システム連携 ③導入プロジェクト推進体制 以下に一つ一つ確認していこう。
①投資の承認 ＷＭＳに限らず、システムを導入する際には、その必要性について社内の合意をとる必要がある。
導入プロジェクトの開始からシステムが稼働するまでの費用に加え、稼働後の運用保守や改修の費用もある。
ＷＭＳの導入に併せて新しくプリンターやＨＴなどの機器が必要になる場合があり、その費用も相当な額になる。
従来から日本企業は物流部門に低コストで運用することを求める傾向があり、物流に関する投資はなかなか理解を得られにくい。
しかしながら、ＷＭＳの導入効果は前述の通り単なるコスト削減にとどまらない。
今やＷＭＳは一定規模以上の倉庫であれば必要不可欠なインフラである。
当社の顧客にも、業務効率化の観点では費用を回収する見込みは低いものの、あえてＷＭＳの導入を決断した企業はある。
人手不足の状況下で今後も物流を維持していくためにはＷＭＳは必要との合意を得た。
実際、ＷＭＳは業務効率化による残業時間の短縮だけでなく、それに伴う従業員満足度の向上、作業の簡略化による高齢者・外国人作業員の活用、共同物流の利用拡大などを期待できる。
そのような金額だけでは測れない効果をあらかじめ明確にしておくと、社内の合意を得る上での一助となるだろう。
②システム連携 ＷＭＳは他のシステムとデータ連携を行う。
多くの場合、ＥＲＰ・基幹システムと連携しており、入出荷の指示を自動で受け取れる。
ＴＭＳ（輸配送管理システム）や倉庫内の自動化機器など、その他のシステムとも連携する（図表３）。
先述の共同物流やフィジカルインターネットでも自社物流データを他社に連携する必要が出てくるなど、ＷＭＳと他システムの連携は今後さらに拡大していくと想定される。
システム同士がつながっているということは、新システムの導入や入れ替え、機能追加などを行う際には、つながっている他のシステムすべてについて変更の影響が出ないように準備しなければならないということである。
従ってＷＭＳの導入を進める前に、社内にどのようなシステムが存在し、そのうちどのシステムがＷＭＳと連携するかを把握しなければならない。
しかし、多くの企業で、情報システム部門でさえ、社内にあるシステムの全貌は把握できていない。
そのため、ＷＭＳ導入推進チームが主導して周辺システムの構成を把握する必要がある。
この作業はＷＭＳに関わるメンバーの知見だけでは難しいため、通常は社内のＩＴ人材や、必要に応じて外部の専門家の力を借りることになる。
③導入プロジェクト推進体制 ＷＭＳを導入する際は、システム自体の設計・開発は専門知識を持った外部のベンダーに任せるのが一般的だが、ベンダーなどのパートナー企業の選定や、プロジェクト管理は自社で行わなければならない。
どのような役割・機能を持ったシステムにするかという要件定義についても、社内メンバーによる意思決定が求められる。
複数の倉庫拠点がある場合には、それぞれの拠点の役割や特性・業務を確認しておく必要がある。
しかし、長期にわたって物流協力会社に運営を外部委託している拠点では、手順書などの業務を定義した文書が揃わないことが多い。
その場合には現状の把握から着手しなければならない。
これらの役割をこなすには、システムに詳しい人材だけでなく、現場業務に詳しい人材にもプロジェクトに参画させる必要がある。
しかし、現業との兼任でプロジェクトに参画させると通常業務に追われてしまい、プロジェクトに十分な時間を割けなくなる。
この問題については後ほど詳述する。
各導入プロセスにおけるポイント ＷＭＳ導入プロジェクトは通常、「①企画・構想」「②要件定義」「③構築」「④展開」というプロセスで進められる。
各プロセスにおけるポイントについて事例を交えながら説明する（図表４）。
①企画・構想 企画・構想のプロセスでは、ＷＭＳ導入の目的、目的を達成するための導入方針、導入の範囲など、プロジェクトの根幹に関わる検討を行う。
この検討が不十分だと、要件定義以降のプロセスで想定外の要件を取り込む必要に迫られる。
開発工数の増加、それに伴うコストの増加、スケジュールの遅延といった問題を招く。
そうした事態を避けるには以下の点に留意が必要だ。
⃝サプライチェーン全体においてＷＭＳが担うべき役割／機能を定義する ＷＭＳが担う役割は近年多様化している。
自社が目指すサプライチェーンにおいて、倉庫業務・ＷＭＳはどのような役割と機能を担うことになるのか、その将来像に向けてどのように変わっていくのかを明確にしなければならない。
食品メーカーＡ社では、全社的に「トレーサビリティ向上」に取り組んでおり、原材料の入荷から生産、製品の出荷に至るまで、従来よりも細かい単位でロット情報をトレースすることを目指していた。
従って本来であれば、トレーサビリティ向上のために倉庫内ではどのような情報を取得する必要があるのかを明確にした上で、ＷＭＳの役割・機能を定義する必要があった。
しかし、ＷＭＳの役割・機能の定義があいまいなまま開発は進んだ。
その結果、倉庫で取得できるデータはＷＭＳ導入後も導入前と同じという状態になった。
結局、システムの稼働後に改めて機能改修することを余儀なくされた。
同社だけでなく広く見られる典型的な失敗事例である。
⃝パッケージのメリットを最大限に享受する それぞれの企業には固有の業務が存在する。
日本企業にはそれが特に多い。
物流業務も同様だ。
倉庫ごと、製品カテゴリーごとなど、さまざまな軸で固有の業務フローが追加されて、年月をかけて複雑化・属人化している。
そのため、企業間で協業しようとする際などに障壁となる。
共同物流の拡大、さらにはフィジカルインターネットの動きを踏まえると物流の標準化が求められている。
固有の業務を削減して業務のバリエーションを減らすことは、現場の人手不足対策という点からも必要である。
データの種類・仕様なども業界標準に合わせるべきである。
ＷＭＳパッケージの導入は、オペレーションの標準化を進める有効な手段である（図表５）。
ＷＭＳパッケージはベストプラクティス、つまり多くの企業が採用する効率的な業務方法やデータの持ち方を体現している。
それを実装することで短期間で標準化が実現する。
パッケージを利用するメリットは他にもある。
ＷＭＳは、会計や生産、販売など、社内の他システムと連携する。
社外の配送業者や業界ＶＡＮなどの情報基盤と連携することも多い。
パッケージは一般的に想定される社内外のシステムとの連携機能を標準でカバーしている。
開発にかかる時間・コストを抑制できる。
加えてパッケージには、法規制の変更や業界動向に合わせた追加機能の提供を期待できる。
導入後も最新のベストプラクティスに継続的にアップデートできるということである。
そのためパッケージの選定にあたっては、自社と同じ業界の導入実績が豊富なものを選ぶと良い。
⃝〝標準に合わせる〟を徹底して業務を再検討する ＷＭＳパッケージを採用したら、追加開発は極力避け、パッケージの標準機能をベースにした標準業務フローに合わせる〝Fit to Standard（標準に合わせる）〟を基本方針として、現行の業務を見直すべきである（図表６）。
システムを業務に合わせようとしてアドオン（新規機能の追加）やカスタマイズを増やせば、それだけ標準から離れてしまう。
開発が長期化してコストも増加する。
さらには追加開発した機能が邪魔をしてＷＭＳベンダーから提供されるアップデートを適用できない場合がある。
⃝倉庫・システム数に応じ段階措置も視野に入れる 倉庫が複数あると、倉庫ごとに使用しているＷＭＳが違ったり、委託している３ＰＬが違ったりして、標準化の難易度は上がる。
しかし、その場合でも倉庫機能（ＴＣ／ＤＣ）や取扱製品などの観点から、可能な限り業務パターン数を減らすことが標準化の第一歩である。
倉庫運営を委託する３ＰＬ業者を共通化することも、業務フローを標準化する一つの方法である。
複数の倉庫を持つ企業が共通のＷＭＳを導入すれば、業務の標準化に加え、情報の集約・蓄積・分析がやりやすくなる。
ただし、ＷＭＳを横展開するのは時間がかかる。
拠点数によっては、情報の集約・蓄積・分析ができるようになるのは何年も先ということにもなりかねない。
過去に当社がＷＭＳ導入を支援した卸売企業Ｂ社は約30カ所の倉庫で異なるＷＭＳを使っていた。
自社のＷＭＳもあれば、庫内作業を委託している３ＰＬのＷＭＳを使用している倉庫もあった。
そこで全ての倉庫に新しい同一のＷＭＳを導入する方針を打ち出した。
しかし、システムの入れ替えが完了するまでには長い年月がかかることが予想された。
そこで新ＷＭＳが一部の拠点で稼働するのに合わせて、新・旧含む全ＷＭＳの上位に、物流関連情報を集約する統合物流管理システムを導入した。
これにより全倉庫の一元管理が可能になった。
ＷＭＳの在庫情報を統合物流管理システムで変換してＥＲＰシステムと連携させることで、システム間のインターフェースを減らすこともできた。
Ｂ社のように拠点数の多い企業が、〝標準に合わせる〟を実現しようとする場合に、暫定的にこのようなシステム構成にするのは有効である（図表７）。
⃝〝標準に合わせる〟を推進できるプロジェクト体制をつくる ＷＭＳの企画・構想プロセスにおいて多くの企業が頭を悩ませるのが、プロジェクト体制である。
現場の同意が得られず、システムを現行業務に合わせる追加開発が増えてしまうのを避けるには、〝標準に合わせる〟の方針決定後、直ちに業務に精通したキーパーソン（将来のキーパーソンも含め）を巻き込み、取り組みを主導させることである。
ただし、現業との兼務でメンバーに選任すると、プロジェクトに十分な時間を割けないことになる。
また、キーパーソンがプロジェクトに貢献しても、それが本業ではないために人事評価に反映されないということでは、モチベーションが希薄になる。
従ってキーパーソンはプロジェクト専任とし、かつ 〝標準に合わせる〟の推進が人事考課に直結するよう本人の年間目標を設定する。
業務の標準化を推進する上で重要なのは、特定業務の利害を優先する意見を排除して、全体最適を図ることである。
公平な立場で全体を見渡すことができる人材によって、各プロセスが標準化の方針から外れていないかをチェックする体制を築くことが鍵である。
プロジェクトリーダーには全体最適の視点を持ち、部門（業務）間を調整できる人材が望ましい。
しかし、適任者が社内には見当たらないこともある。
そうした場合には、外部リソースを活用するのも一つの方法である。
②要件定義 要件定義は、「業務要件定義」と「システム要件定義」から構成される。
業務要件定義では、新ＷＭＳをベースにした業務の流れ、業務処理を定義する。
システム要件定義では、業務要件を基にＷＭＳに実装すべき機能を洗い出し、非機能要件とあわせて整理した「システム要件定義書」を作成する。
〝標準に合わせる〟の方針に基づく業務要件定義では最初に自社の標準業務フローを作成する。
システムベンダーがパッケージの標準業務フローを用意している場合はそれを利用すればよい。
それがない場合はＷＭＳパッケージの標準機能から自社の標準業務フローを作成する（図表８）。
企画・構想時に〝標準に合わせる〟という方針を定めたにも関わらず、業務要件定義を行った結果、追加開発要件が膨らんで、導入スケジュールとコストが肥大化してしまうケースは非常に多い。
顧客納品時の包装・加工方法や送付状・納品書といった末端の仕様に至るまで事細かに規定して、追加開発で機能を作り込んでしまう。
これを避けるにはまず、将来あるべき姿として標準業務フローを作成して、「現在は行っているが、標準業務フローからは外れる業務」を明らかにする。
そして標準業務フローから外れた業務を、追加開発を行っても新ＷＭＳに機能として盛り込むべきなのか、費用対効果の面から検討する。
その際に社内外の関係者との調整を必要に応じて実施することが肝要である。
専門商社Ｃ社は、すべての倉庫拠点のＷＭＳを刷新・統一するプロジェクトを発足した。
しかし、事業部ごとに取り扱う商材が大きく異なるため、要件定義を開始してすぐに、各倉庫を担当する業務部門から現行業務に合わせた追加開発の要求が殺到した。
そこで企画・構想時の〝標準に合わせる〟の方針に基づき、各部門の業務のキーパーソンを中心にして、全社標準の業務フロー策定に取り組んだ。
その上で現行業務の標準化の検討を徹底した。
業務を標準化できない部分、すなわちシステム追加開発が必要になる業務については、その要否を判断する評価軸を細かく定め、それに沿って１件ずつ評価した。
その結果、追加開発を自社の競争力の源泉となる物流機能に絞ることができた。
基本方針に則ったハイレベルな標準化が実現した。
③構築／④展開 「構築～展開」のプロセスでは、システムベンダーによるシステム開発・テストの状況を管理して、導入に向けたユーザー受け入れテスト、社内外とのシステムインターフェーステスト（連携テスト）、ユーザートレーニング、旧システムから新システムへのデータ移行などの複数のタスクを同時並行的に計画・実施することが求められる。
それぞれ依存関係があるため、あるタスクの遅延が全体スケジュールに影響してしまう。
新ＷＭＳの導入と同時に新しい倉庫拠点が稼働する場合や、在庫管理方法を変更する場合には、倉庫間のモノの移動や棚卸作業も発生する。
入出荷業務で外部業者とやり取りする帳票や連携データの変更があれば、外部業者との調整も必要だ。
トラブルによるプロジェクトへの影響を最小限に抑えるために、これらのタスクをまずは網羅的に整理する。
その上で、業務に支障の出ない移行計画を立案して、物流部門と関連する部門が協力して進捗を細かく管理する。
検討対象は広範囲にわたるため、倉庫業務および在庫管理業務に関わる購買、生産、経理、輸配送などの関係者を巻き込み、進捗管理要員を増員して、領域別に担当を明確に振り分けておくことが肝要である。