WMS要件定義・3PL選定 設計

概要

EC・通販事業者が倉庫管理システム(WMS)を導入する、または3PL（物流アウトソース）へ委託する際の要件定義・RFP作成を支援するスキル。現状業務を棚卸しし、必須/任意要件を切り分け、自社WMS/クラウドWMS/3PL委託の比較軸とRFP項目を整理する。「何を求めるか」を曖昧にしたまま製品やベンダーを選ぶと、導入後に連携不足・運用崩れが起きる。本スキルは判断軸づくりに特化し、特定製品は推奨しない。

最重要原則

「現状業務を先に可視化／必須要件と任意要件を分ける／データ連携(受注・在庫・送り状)を要件の中心に／KPI(誤出荷率・出荷リードタイム)で評価／自社開発・クラウドWMS・3PL委託を同じ軸で比較」。要件が固まる前のデモ巡りは時間を浪費する。連携とKPIを軸に据えると比較がぶれない。

知識ベース

要件の主要カテゴリ：

カテゴリ	要件例
入荷	入荷予定・検品・棚入れ、ロット/賞味期限/シリアル管理
在庫	ロケーション管理、引当、棚卸（循環/一斉）
出荷	ピッキング(シングル/トータル)、梱包、送り状連携、同梱物
返品	返品入荷・検品・再販可否・在庫戻し
連携	受注（モール/カート/受注管理）、在庫連携、送り状(配送会社API)
マルチチャネル	複数モール・複数倉庫、引当優先
KPI/運用	誤出荷率、出荷リードタイム、生産性、当日出荷締め

選定の三択：

• 自社WMS（自由度高・コスト/保守重い）
• クラウドWMS（早く始めやすい・カスタム制約）
• 3PL委託（運用を外部化・コスト構造と柔軟性に注意）

製品名・価格・機能対応は変化が速い。本スキルは要件と比較軸を作り、実機評価はRFP回答とデモで行う。

処理フロー

Step 1：現状業務の可視化

• 取扱SKU数・出荷件数・チャネル・倉庫数・現行の管理方法（Excel/既存WMS）・課題 不明時は「複数モール・1倉庫・出荷数百件/日・Excel管理に限界」を仮置きし明示。

Step 2：要件の洗い出しと切り分け

• 上記カテゴリで要件を列挙し、必須(Must)/任意(Want)に分類。ロット/期限/シリアルの要否を確定。

Step 3：データ連携要件

• 受注・在庫・送り状の連携方式（API/CSV）と、既存の受注管理/カートとの接続点を定義。

Step 4：選定方式の比較

• 自社/クラウドWMS/3PL を、初期/運用コスト・柔軟性・スピード・KPI担保で比較表化。

Step 5：RFP項目とKPI

• ベンダーに問う項目（機能・連携・SLA・費用・サポート）とKPI目標をまとめる。

出力フォーマット

# WMS要件定義・3PL選定：[事業者]

## 0. 前提（規模/チャネル/現状・仮定）
## 1. 現状業務マップと課題
## 2. 要件一覧（Must/Want）
   | カテゴリ | 要件 | Must/Want |
## 3. データ連携要件（受注/在庫/送り状）
## 4. 方式比較（自社/クラウドWMS/3PL）
   | 観点 | 自社 | クラウド | 3PL |
## 5. RFP項目とKPI目標

品質ゲート

• 要件がMust/Wantに切り分けられているか
• データ連携（受注・在庫・送り状）が要件に含まれるか
• KPI（誤出荷率・リードタイム）を評価軸に置いたか
• 特定製品の推奨でなく判断軸を提示したか

注意事項

• 製品/価格は環境で異なる。最終判断はRFP回答・デモ・PoCで行う。
• 食品・医薬部外品等はロット/期限管理・許認可の要件を別途確認。
• 移行時の在庫差異・締めタイミングのリスクを計画に含める。

参考公式情報源

• 各WMS/3PLベンダーの公式仕様、配送会社のAPI/送り状仕様