OMSは複数の販売チャネルから入る受注や販売上の在庫を管理し、WMSは倉庫・バックヤードの現物在庫と入出荷作業を管理するシステムです。両者を連携する場合は、在庫数量だけでなく、受注・出荷指示・出荷実績・例外処理まで含めて設計します。
本記事では、OMSとWMSの役割、理論在庫と実在庫の違い、連携時のデータフローを整理します。さらに、一体型と分離・連携型の選び方、導入前に確認すべき項目まで、受注と倉庫業務を担当する立場から判断できるように解説します。
OMSとWMSの違い：受注・販売在庫と倉庫の現物在庫を分けて考える
OMSは、Order Management Systemの略で、受注管理システムを指します。自社ECやECモール、実店舗など複数の販売チャネルから受注を取り込み、受注内容、商品情報、販売チャネル上の在庫などを一元管理する仕組みです。
一方、WMSは、Warehouse Management Systemの略で、倉庫管理システムを指します。入荷、保管、ピッキング、検品、出荷、棚卸といった、倉庫やバックヤードで発生する現場作業を管理・支援します。WMSの基本機能や導入メリットを詳しく知りたい場合は、WMSの機能・導入メリットの解説も参考になります。
両者はどちらも「在庫管理」という機能を持ちますが、管理する対象と目的が異なります。
| 比較項目 | OMS | WMS |
|---|---|---|
| 主な対象 | 受注、商品情報、販売チャネル、販売上の在庫 | 倉庫内の入荷、保管、出荷、棚卸、現物在庫 |
| 在庫の性質 | 理論在庫など、データ上の在庫 | 倉庫やバックヤードで確認する実在庫 |
| 主な利用者 | EC担当、受注担当、販売管理担当 | 倉庫担当、物流担当、3PL事業者 |
| 得意な課題 | 複数チャネルの受注・在庫更新の一元化 | 検品、誤出荷、ロケーション、ピッキングの改善 |
| 単体で対応しにくい課題 | 現物の検品や倉庫内の作業進捗 | 複数販売チャネルの受注処理や商品情報更新 |
複数のモールや自社ECを運営している場合、OMSを使うと、チャネルごとに受注を確認したり在庫数を更新したりする作業をまとめやすくなります。いずれかのチャネルで売れた際に、他のチャネルへ販売在庫を反映する運用も可能です。ただし、実際に商品がどこにあり、出荷できる状態なのかを確認する機能は、OMSだけでは十分とは限りません。
反対に、誤入荷や誤出荷、検品ミス、ピッキングの移動距離などが課題なら、WMSの検討が中心になります。倉庫内のロケーションや作業実績を管理し、現物を基準に作業を進めるためです。OMSは受注の流れを整える仕組み、WMSは現場で商品を正しく扱う仕組みと考えると、役割を区別しやすくなります。
理論在庫と実在庫の違い、販売可能数の基準
理論在庫とは、仕入れ、入荷、受注、出荷などの記録をもとに計算される、帳簿上・データ上の在庫です。OMSで販売チャネルへ表示する在庫は、基本的にこのデータ上の在庫をもとに管理します。
実在庫とは、倉庫やバックヤードに現物として存在し、実際に数えて確認できる在庫です。入荷記録上は商品が存在していても、検品時に破損や汚損が見つかったり、作業中の数量差異が発生したりすると、理論在庫と実在庫は一致しません。
差異があるときに理論在庫をそのまま販売すると、データ上は注文を受けられても、倉庫には出荷できる商品がないという欠品中の受注につながります。そのため、販売可能数は、現物を確認できる実在庫を起点に判断するのが基本です。WMSで確認した実在庫をOMSへ反映し、販売チャネルの表示を調整します。
ただし、実在庫の全量がそのまま販売できるとは限りません。引当済みの商品、検品保留品、返品確認中の商品、破損品、販売停止品、安全在庫などをどう扱うかは、事業者の業務ルールによって異なります。導入時には「実在庫のうち、どの状態を販売可能とみなすか」を明文化しておくことが重要です。
在庫差異が生じた場合は、実在庫を正として販売を一時停止するのか、数量を調整して販売を続けるのかも決めておきます。OMSとWMSの在庫を連携するだけでは、品質区分や保留状態まで自動的に同じ意味になるとは限りません。商品状態と販売可否の対応関係を、システム設定と現場運用の両方で確認する必要があります。
OMSとWMSを連携する際のデータフローと運用設計
OMSとWMSの連携は、単にデータ入力を減らすための仕組みではありません。販売側の受注と倉庫側の現物・作業実績をつなぎ、販売可能在庫を更新しながら、欠品中の受注や在庫差異を抑えることが主な目的です。
WMSの実在庫や作業実績がOMSへ反映されれば、販売チャネルが古い在庫数を表示し続けるリスクを抑えられます。日常的な差異を小さくできれば、棚卸時に大きな差異をまとめて調整する負担も軽くなります。ただし、連携の成否は同期のタイミングや対象データ、業務ルールに左右されます。
受注から出荷実績・在庫反映までに受け渡すデータ
基本的な流れは、次のようになります。
販売チャネル
↓ 受注情報
OMS
↓ 出荷指示・出荷対象データ
WMS
↓ 在庫情報・出荷実績・送り状番号
OMS
↓ 在庫数・出荷状況・配送情報
販売チャネル・顧客
主な受け渡しデータとタイミングは、以下のとおりです。
- 受注時：販売チャネルからOMSへ、注文者、届け先、商品、数量、配送方法などの受注情報を取り込む
- 出荷指示時：OMSからWMSへ、出荷対象、数量、届け先、同梱条件などを渡す
- 倉庫作業時：WMSで入荷、引当、ピッキング、検品、出荷の進捗や在庫状態を更新する
- 出荷完了時：WMSからOMSへ、出荷実績や送り状番号などを返す
- 販売状況更新時：OMSが実在庫や引当状況をもとに販売チャネルの在庫・注文ステータスを更新する
受注条件に問題がなく、在庫も確保できる注文であれば、OMSからWMSへの出荷指示までを自動化できる場合があります。出荷後の実績登録や顧客への発送通知まで自動化できる構成もありますが、どこまで自動化できるかは製品の連携仕様と設定した業務ルールによって変わります。
たとえば、決済確認が必要な注文、住所に不備がある注文、同梱条件に該当する注文、在庫が不足している注文は、自動出荷の対象から外して人が確認する設計にします。自動化する範囲を広げるほど、例外時に自動処理を止める条件や、担当者へ通知する方法も重要になります。
例外時に「正しいデータ」と復旧担当を決める
連携システムでは、通常処理だけでなく、欠品、注文取消、返品、連携遅延、送信エラー、重複登録などを想定します。両方のシステムが別々のデータを持つ分離・連携型では、データの反映タイミングによって一時的に数量やステータスが合わないこともあります。
導入前に、少なくとも次のルールを決めておきます。
- 在庫の正データ：現物数量や品質状態はWMS、販売チャネルへの表示や受注状態はOMSなど、項目ごとにどのシステムを正とするか
- 突合の方法：どの項目を、どの頻度で、誰が照合するか
- エラー時の処理：再送、手動登録、処理保留、販売停止のどれを選ぶか
- 復旧担当：EC担当、倉庫担当、荷主側の管理者、システム保守担当のどこが一次対応するか
- 販売再開の判断：在庫差異や連携停止を解消したあと、誰の承認で販売を再開するか
「在庫はWMSを正とする」と決めても、受注の引当やキャンセルの確定までWMSが担うとは限りません。商品数量、在庫状態、受注ステータス、出荷実績など、データ項目ごとに責任範囲を切り分ける必要があります。
また、すべてを自動化するのではなく、例外だけ人が確認する運用にすると、通常処理の効率と安全性を両立しやすくなります。荷主・EC担当・倉庫担当・保守担当が、どの状態を見て何を判断するのかを手順化しておくことが、復旧時間の短縮につながります。
一体型と分離・連携型の選び方
OMSとWMSの構成には、両方の機能を一つのシステムで扱う一体型と、別々の製品を連携して使う分離・連携型があります。どちらが常に優れているわけではなく、既存システムを活用する自由度と、連携を維持する負荷のどちらを重視するかで判断します。
| 比較項目 | 一体型 | 分離・連携型 |
|---|---|---|
| システム選択 | OMSとWMSを個別に選ぶ自由度は限られやすい | 業務ごとに製品を選びやすく、既存システムも活用しやすい |
| データ連携 | システム内部で完結し、受け渡しの設計が少ない | 受注、在庫、出荷実績などの連携設計が必要 |
| データ整合性 | 正データの切り分けや突合が発生しにくい | システム間の差異、再送、遅延への対応が必要 |
| 拡張・変更 | 一体型の仕様に合わせる必要がある | 特定の機能やシステムだけを入れ替えやすい場合がある |
| 保守・障害対応 | 連携部分の保守負荷を抑えやすい | 連携仕様の変更、原因切り分け、復旧を継続的に担う必要がある |
| 向いている状況 | 運用を一元化し、連携維持の負担を抑えたい | 既存資産や専門製品を活かし、選択の自由度を確保したい |
自由度・データ整合性・保守負荷で比較する
一体型の利点は、OMSとWMSの間でデータを受け渡す仕組みを別途設計・保守する必要が少ないことです。受注、在庫、出荷実績が同じ仕組みの中で扱われるため、「どちらのデータが正しいか」を切り分ける場面も抑えやすくなります。連携を担当する社内人材が少ない場合や、障害時の原因切り分けを簡素化したい場合は、一体型を優先して検討しやすいでしょう。
一方で、一体型はOMSとWMSをそれぞれ自由に選べるわけではありません。既存のECモール、カート、基幹システム、倉庫運用との適合性が低い場合、業務を製品側に合わせる必要が生じることがあります。
分離・連携型は、すでに使っているOMSやWMSを活かしやすく、受注管理と倉庫管理をそれぞれ得意な製品で構成できます。倉庫を追加したり、特定の販売チャネルへの対応を拡張したりする際も、該当するシステムだけを変更できる可能性があります。
ただし、分離・連携型では、連携仕様の維持、データの突合、エラー時の原因切り分けが継続的な運用業務になります。連携先の仕様変更や倉庫切り替えがあったときに、誰が改修を管理し、テストし、障害対応するのかを決めておかなければなりません。
受注・在庫データを経営分析などに使う場合は、更新時刻や在庫状態の意味がそろっているかも確認します。分析の前提となるデータがシステムごとに異なると、集計結果の解釈を誤る可能性があるためです。
ロット・賞味期限など、在庫の属性で出荷判断する場合
SKU単位の数量だけを同期すればよい業務と、ロット、賞味期限、品質区分などの属性によって出荷可否や引当順が変わる業務は分けて考えます。
たとえば、同じ商品コードの商品でも、賞味期限が異なる在庫を別々に管理し、期限の近いものから出荷する必要がある場合、単純な「商品Aが何個あるか」という数量連携だけでは判断できません。WMSが持つロット・期限・状態の情報を、OMSの出荷判断まで正確な粒度で渡す必要があります。
この要件がある場合は、次の点を確認します。
- ロットや賞味期限を、OMSとWMSのどちらで管理するか
- 出荷指示時に、属性情報をどの粒度で受け渡せるか
- 引当順や出荷可否のルールを、システムで自動判定できるか
- 在庫状態の変更を、どのタイミングで相手システムへ同期するか
- 分離・連携型の場合、その連携開発と継続保守を担えるか
一体型が唯一の実現方法とは限りません。分離・連携型でも対応できる場合はありますが、SKU単位の数量連携よりも開発・テスト・保守の負荷が大きくなりやすいため、候補製品の実データで確認することが重要です。
SKU単位の在庫管理で足り、社内や委託先に連携を設計・保守する体制があるなら、分離・連携型が適する可能性があります。反対に、属性別の出荷判断や複雑な受注条件があり、連携運用を継続的に担う体制を持ちにくい場合は、一体型を優先して比較するとよいでしょう。
導入・製品選定前に確認する項目
製品名や初期費用だけで比較すると、導入後に連携できない販売チャネルや、現場で処理できない例外が見つかることがあります。候補製品には、現在の業務だけでなく、注文量の増加、モール追加、倉庫変更まで含めて確認しましょう。
- 連携先とデータ範囲：利用中・追加予定のECモール、自社カート、POS、基幹・在庫管理システム、OMS、WMSが連携対象に含まれるかを確認します。対応可否だけでなく、受注、在庫、出荷指示、出荷実績、送り状番号、キャンセル、返品のどこまでを連携できるかも重要です。非対応の連携先があると、手作業や個別開発、別製品へのリプレイスが必要になる場合があります。
- 注文量と処理能力：通常時だけでなく、セールや繁忙期を含む注文量を前提に、受注の取り込み、在庫引当、出荷指示、ステータス更新が滞りなく処理できるかを確認します。注文数、販売チャネル数、SKU数、倉庫数が増えた場合の上限や処理遅延も、候補製品の説明だけでなく実際の運用条件に照らして評価します。
- 現場での操作性：EC担当と倉庫担当が日常的に行う操作を洗い出し、候補製品で試します。受注の保留・変更、例外注文の確認、在庫調整、検品、出荷完了処理など、頻度の高い操作が分かりやすいかを確認してください。利用端末、権限設定、複数拠点での運用、教育に必要な時間も評価対象です。
- 例外処理と移行：欠品、キャンセル、返品、誤出荷、連携停止、重複登録が発生したときの処理方法を確認します。既存データの移行範囲、切り替え時の二重管理、過去の受注・在庫履歴の扱い、倉庫を変更する場合の移行手順も、導入前に整理しておく必要があります。
- 自動化と人の確認範囲：どの注文を自動で出荷指示へ進め、どの条件で人の確認に回すかを決めます。決済未確認、住所不備、在庫不足、同梱、配送方法の指定など、例外条件を製品が扱えるかだけでなく、担当者への通知や保留解除まで確認します。
- 総コストと運用体制：初期費用や月額費用に加え、連携開発、カスタマイズ、データ移行、機器、教育、テスト、保守の費用を見積もります。連携型では、仕様変更への対応費用や障害時の原因調査も考慮が必要です。問い合わせ窓口、対応時間、障害時の一次対応者、導入後に設定を変更する担当者まで決めておきます。WMSの導入費用を検討する際は、初期費用・月額費用・連携開発費の内訳も確認項目になります。
- 将来の拡張性：受注件数、販売モール、SKU、倉庫、BtoB・BtoCの業務が増えたときに対応できるかを確認します。将来の倉庫切り替えや既存システムとの入れ替えを想定し、データを取り出せるか、移行支援があるか、追加連携をどのように保守するかも確認してください。
通販で起きやすい誤出荷や在庫差異を、WMSの活用によってどのように抑えるかを検討したい場合は、EC物流におけるWMSの課題と選び方も補足になります。
まとめ
OMSは複数販売チャネルの受注や理論在庫を、WMSは倉庫・バックヤードの現物在庫と入出荷作業を主に管理します。理論在庫と実在庫に差異がある場合、販売可能数は実在庫を起点にし、引当済み・保留・破損などを含む販売可否のルールを明文化することが重要です。
OMSとWMSを連携すると、受注、出荷指示、在庫、出荷実績をつなぎ、欠品中の受注や在庫差異を抑えやすくなります。ただし、連携できる範囲は製品仕様と業務ルールによって異なるため、自動化する処理と人が確認する例外を分け、正データ・突合方法・復旧担当まで事前に決めておく必要があります。
一体型は、データ整合性と連携保守の負荷を重視する場合に向いています。分離・連携型は、既存システムを活用し、OMSとWMSを個別に選ぶ自由度を重視する場合に適します。ロット・賞味期限など属性単位の出荷判断が必要なら、連携するデータの粒度と保守体制を確認したうえで、現在の業務だけでなく将来の受注増・販路追加・倉庫変更まで見据えて構成を選びましょう。