WMSのリニューアルの進め方/やり方/流れや方法/手法/工程/手順

WMSのリニューアルは、企画と要件定義、データ移行、並行稼働と本番切替の順に進めるのが基本です。この流れを守ることで、在庫精度の向上と業務効率化を目指せます。

特に、失敗の約7割はデータ移行に起因すると言われるため、この工程での判断が成否を左右します。

▼全体ガイドの記事
・WMSのリニューアルの完全ガイド

WMSリニューアルの全体像と進め方の前提

WMSリニューアルの5フェーズを企画・現状分析から本番稼働まで順に並べた図。
後半の稼働準備まで見通して、前工程の計画を立てられます。

WMSのリニューアルは、次のフェーズで進むのが一般的です。

  • 企画・現状分析
  • 要件定義・ベンダー選定
  • 設計・開発
  • データ移行・テスト
  • 並行稼働・本番稼働

期間の目安は、クラウドSaaSで3〜6ヶ月、パッケージのカスタマイズやスクラッチ開発では半年から1年以上です。方式によって差が大きいため、切替日から逆算して早めに見通しを立てておくことが大切です。

各フェーズで判断をぶらさないには、「なぜ今リニューアルするのか」という目的をKPIの数値で示しておくことが欠かせません。目的が数字で決まっていれば、各フェーズで何を優先するかを判断しやすくなります。

リニューアルすべきサインの見極め

刷新を判断するときは、現行システムの限界と、業務の変化への対応状況を確認します。まず、次のような限界の兆候が出ていないかを見ます。

  • 保守の限界:ベンダーのサポート終了(EOSL)が告知された。
  • 属人化:改修できる技術者が社内外に一人しかいない。
  • 性能の限界:出荷ピーク時にレスポンスが極端に遅くなる。

限界の兆候が一つでも当てはまると、使い続けるほど保守費とリスクが膨らみます。さらに、刷新の際には移行の難易度も上がります。

もう一つの判断軸は、業務の変化に現行システムが追いついているかどうかです。EC化による出荷件数の増加、オムニチャネル化、多品種少量への対応といった変化のなかで、手作業の補完運用やExcel管理が常態化しているなら、業務に合わなくなったサインです。

課題を箇条書きで洗い出したうえで、「現状維持のコスト」と「リニューアルの投資効果」を並べて示します。そうすると、予算化の議論を前に進める材料になります。

全体ステップとスケジュールの組み立て方

切替日から逆算し、繁忙期を避けて各フェーズの期限を決めます。計画では、次のとおりに組み立てます。

  • 切替時期:出荷が落ち着く閑散期を選ぶ。
  • 逆算する工程:並行稼働、テスト、データ移行、開発、要件定義の順に、後ろから期限を置いていく。
  • 避ける期間:年末商戦、セール、決算期の出荷ピークを、カレンダー上で先に除外しておく。

方式は、クラウドSaaSへの移行、パッケージの再導入、フルスクラッチでの作り替えから選びます。近年は、AI駆動開発によるスクラッチ開発も現実的な選択肢になっています。実際に、AI駆動開発では工期とコストを3割から7割ほど圧縮できるケースがあります。

従来は難しかった100%フィットの自社専用WMSも、パッケージに近い費用で狙える時代になりました。

ポイント

期間は方式によって大きく変わるため、切替時期を先に決めて各フェーズの期限を逆算すると、どの工程を優先するかの判断がぶれにくくなります。方式選びと期限決めは、同じ打ち合わせで進めるのが目安です。

企画・要件定義フェーズの進め方

企画・要件定義では、現行業務の実態を正確に捉えたうえで、数値目標とあわせてあるべき姿を描きます。ここで決めた内容は後工程すべてに影響するため、焦って開発へ進まず、現場の声と数字を積み上げます。

As-Is/To-Be分析とKPI設定

まず、現行業務(As-Is)を棚卸しし、入荷・格納・ピッキング・出荷・棚卸の流れを例外処理まで含めて図にします。現場独自の運用も、漏れなく拾い上げる必要があります。

  • 返品処理:セット品をばらで返品する運用。
  • 破損品:傷んだ商品を隔離する手順。
  • サンプル品:倉庫から持ち出す際のやり方。

システム化されていない暗黙の運用は、後で在庫差異を生む原因になります。特に、現場の「良かれ」と思う独自運用も、確認の対象にします。

あるべき姿(To-Be)では、誤出荷率0.1%以下、在庫精度99.5%以上、ピッキング生産性1.3倍などをKPIとして設定します。

数千万円規模の投資を承認してもらうには、定量的な目標がROIの根拠になります。KPIが曖昧なままだと、稼働後に成果を評価することも難しくなります。

RFP作成とベンダー選定・撤退条件の確認

To-Beが固まったら、RFP(提案依頼書)を作成します。自社固有の条件を明示しておくと、各社の提案を比べられます。

  • 現状と要件:課題、必須要件(Must)、希望要件(Want)。
  • 業務規模:想定出荷件数と拠点数、繁忙期のピーク件数。
  • 連携・計画:ERPやOMSとの連携、予算、スケジュール。
  • 固有業務:自社特有の例外処理。

RFPを丸投げにすると、各社の提案が似通い、実力を見抜きにくくなります。また、ベンダーを選ぶ前に、旧システムの解約条件と、旧データベースへ自社が直接アクセスできるかを確認しておきます。

アクセス権を旧ベンダーに依存していると、移行テストやリハーサル用の抽出に、1回あたり数十万円かかる場合があります。新ベンダーとの契約では、将来の乗り換え時にデータを引き上げる対応を含められるかも確認します。

ポイント

現場から挙がった要望は、KPIにどう効くかで要件に入れるかを決めると、後工程で評価がぶれにくくなります。要望の数より、目標との結びつきを優先するのが目安です。

データ移行を成功させる進め方(失敗の7割はデータに起因)

移行前のマスタクレンジング項目として、12ヶ月ルール、休止ロケーション、重複の解消を3枚のカードで示した図。
対象を絞り、使われていない情報と表記ゆれを整理します。

WMSリニューアルの失敗の約7割は、システム不具合ではなくデータ移行に起因すると言われます。新システムがどれほど高機能でも、移行したマスタデータが汚れていれば在庫は合わず、現場が混乱します。そのため、開発と並行して早めに着手し、十分な検証期間を確保しておきます。

マスタクレンジングの基準(12ヶ月ルールと名寄せ)

長年使ってきた旧システムには、不要なデータが溜まっているものです。移行前に対象を絞っておくと、検索の遅延や誤った引当を防げます。

  • 12ヶ月ルール:過去12ヶ月間に入出荷実績がない商品マスタを外す。
  • 休止ロケーション:使われていないロケーションは移行対象から除く。
  • 重複の解消:取引先コードや商品コードの表記ゆれを統一し、一意のマスタに集約する。

どのマスタを残すかは、業務の知識がないと判断できません。そのため、情シスとベンダーだけで進めず、現場の担当者も巻き込みます。

在庫の時点整合性(差分移行と業務停止一括の選択)

倉庫は24時間動き続けるため、データを抽出した瞬間から在庫数は変わります。そのため、時点整合性をどう担保するかがWMS移行の難所になります。移行の方法は、業務停止一括と差分移行の大きく2つから選びます。

  • 業務停止一括:週末や連休に業務を止めて在庫を確定し、一括で移行する。
  • 差分移行:基準データ抽出後の入出荷を差分として反映する。

一括方式は整合性を取りやすい一方で、出荷を止められる業態でなければ採用できません。差分移行は出荷を止めずに切り替えられます。ただし、取りこぼしを防ぐための運用設計と検証が複雑になります。

どちらの方式でも、切替直前には実地棚卸を行います。理論在庫と現物を一致させてからカットオーバーに臨むと、後の在庫差異を防ぎやすくなります。

ポイント

マスタを残すかどうかは、業務を知る現場担当者と一緒に決めると判断がずれにくくなります。移行データの検証は、開発と並行して早く始めるのが目安です。

並行稼働と本番切替の進め方

旧システムを中心に、出荷エラー率、棚卸差異率、特定業務をロールバックの判断基準として示した図。
出荷・在庫・業務の状態を切り戻し判断に結びつけます。

並行稼働はリスクを抑える有効な手段ですが、プロジェクトのなかで最も緊張する局面でもあります。進め方を誤ると現場が崩れやすく、二重入力によって工数が1.5〜2倍に膨らみます。そのため、開始前に終了条件と切り戻しの基準を明確にしておきます。

指示系統の一本化とExit Criteriaの設定

並行稼働中の混乱を防ぐには、現場への指示元と旧システムの役割を分けて決めておきます。

  • 現場への指示:出荷指示書やピッキングリストは新システムからのみ出力する。
  • 旧システム:新システムの結果を裏側で照合するための検証用途。

新旧両方から指示書が出ると、二重ピッキングや誤出荷が起きてしまいます。そのため、物理的な指示書の出力も新システムだけに絞ります。

Exit Criteria(終了条件)は、数値で定義しておきます。たとえば、出荷エラー率0.5%未満の連続達成などが条件例です。ほかにも、ERPとのAPI連携が4週間以上安定して稼働し、棚卸差異率が基準内に収まっていることも挙げられます。

条件を満たしてから旧システムを停止する、という内容を事前に合意しておきます。基準がないと、並行稼働が長引き、入力ミスも増えます。

ロールバック基準と旧環境の保持期間

本番稼働後に問題が起きたときは、旧システムへ戻すロールバック(切り戻し)の判断を行います。

  • 出荷:出荷エラー率が一定の閾値を超える。
  • 在庫:棚卸差異率が許容範囲を逸脱する。
  • 業務停止:特定業務が一定時間以上停止する。

各条件について、誰が最終判断するかも書面に残しておきます。そうしておけば、トラブル時の迷いを減らし、判断の遅れを防げます。

旧システムのライセンスと旧ハンディ端末は、本番稼働後も最低3ヶ月保持することをおすすめします。旧端末を早々に破棄してしまうと、切り戻しの際に旧システムへ再接続できず、業務が止まるおそれがあります。保持にかかるコストは月数万円程度ですが、業務停止の損失と比べれば、安価な保険といえます。

新システムで繁忙期を一度乗り越え、Exit Criteriaを安定して満たしたあとに、旧環境を撤去します。

ポイント

並行稼働を終えるかどうかは、Exit Criteriaの数値を満たしたかどうかで判断します。基準を満たす前に旧システムを止めると、切り戻しの手段が失われるおそれがあります。

WMSリニューアルでよくある失敗と回避策

WMSリニューアルには、多くの企業が共通して陥る失敗パターンがあります。事前に知っておくことで、回避できるトラブルもあります。そこで、在庫精度に関わる例外処理と隠れコスト、倉庫移転を伴う場合の注意点を確認します。

倉庫移転を伴う場合には、旧倉庫の費用も含めて検討することが欠かせません。

例外処理の漏れが生むゴースト在庫

在庫を正しく合わせるには、例外処理をシステムにきちんと反映させる必要があります。反映されないままだと、ゴースト在庫が発生します。

  • 破損品:物理的に隔離しても論理ステータスを変えないと、出荷可能在庫として残る。
  • セット品:2個1セットの商品を1個だけ返品すると、単位の食い違いが起きる。
  • サンプル品:無記録で持ち出すと在庫差異が生じる。

出荷可能な在庫に見える破損品は引当に使われ、そのまま欠品クレームにつながります。

そこで、要件定義の段階で例外処理を洗い出し、業務フローに組み込みます。現場ヒアリングの精度は、稼働後の在庫精度を左右します。

リニューアルを機に例外処理そのものを整理し、標準化しておく方法も有効です。

見積もりに出てこない隠れコストと5年TCO

見積もりと実費の差を防ぐには、端末、保守、倉庫移転に伴う費用を予算に含めておく必要があります。

  • ハンディ端末:1台5万〜30万円に台数を掛けた購入費。
  • 保守費:オンプレやスクラッチでは、初期構築費の15〜20%が毎年かかる目安。
  • 倉庫移転費:旧倉庫の出庫作業費、早期解約違約金、割増保管料、棚卸費。

旧ベンダーへのデータ抽出では、スポットの費用も発生します。また、倉庫移転時には、月額賃料の3〜6ヶ月分が追加になる場合があります。

SaaSは「初期費用無料」でも、月額の従量課金が積み上がるため、中長期ではオンプレやパッケージより割高になることがあります。たとえば、初期0円で月20万円の場合は5年で1,200万円、初期100万円で月10万円の場合は5年で700万円になります。

この例では、5年時点で初期費用無料のほうが高くなります。そのため、単年ではなく複数年で比べます。

まとめ

WMS刷新では、企画・要件定義でKPIと撤退条件を固めます。データ移行では、12ヶ月ルールによるクレンジングと在庫の時点整合性を担保します。

並行稼働では指示系統を一本化し、Exit Criteria(終了条件)を明確にします。本番切替に備えて、切り戻し基準と旧環境の保持期間も決めておきます。

在庫精度は例外処理と現場ヒアリングに左右されます。隠れコストは5年TCOで確かめ、切替は閑散期に行います。これらの手順を一つずつ着実に進めれば、在庫精度の向上と業務効率化に近づけます。

▼全体ガイドの記事
・WMSのリニューアルの完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。