STEP 01
受注管理システム（OMS）とは何か
OMSはOrder Management Systemの略で、複数のECモールや自社ECから入る注文を集め、確認、在庫引当、出荷指示、ステータス更新などの受注処理をまとめる仕組みです。製品ごとに在庫、商品、発注、売上、アプリ拡張などの範囲は異なります。『一元管理』という名称だけで判断せず、自店で自動化したい工程が標準機能か個別連携かを確認します。
STEP 02
カート・OMS・WMS・発送代行を分ける
ECカートは商品を掲載し、買い物かごと注文受付を担う販売窓口です。OMSは受けた注文を複数チャネル横断で処理します。WMSは入庫、保管、棚、ピッキング、検品、梱包など倉庫内作業を管理します。発送代行は倉庫設備と人員を含む物流実務の委託です。LOGILESSのようにOMSとWMSを一体化するサービスもあれば、オープンロジのように物流業務を委託するサービスもあり、比較する対象を混同しないことが重要です。
STEP 03
導入時期は店舗数ではなく負荷で決める
2店舗になっただけで必ずOMSが必要になるわけではありません。注文データの転記回数、在庫差、出荷締切超過、誤出荷、キャンセル反映漏れ、担当者しか処理できない例外、繁忙日の未処理件数を4週間測ります。手順の整理で減らせる問題と、システム連携がないと減らせない問題を分けてから導入候補を絞ります。
STEP 04
現状の注文を要件表へ変える
販売チャネル、月間・最大日の注文件数、SKU数、倉庫数、在庫更新頻度、出荷締切、同梱、予約、取り寄せ、分割配送、キャンセル、返品、交換、後払い、ギフトなどを一覧にします。各工程で入力元、出力先、担当、締切、判断条件、失敗時の手順を記録し、『自動化必須』『人が確認』『対象外』の3つへ分けます。
STEP 05
機能表は連携と運用条件まで確認する
公式の対応先一覧だけでなく、自店のプラン、注文項目、更新方向、同期頻度、API・CSV、オプション費、保守窓口を確認します。受注・在庫・商品管理を掲げるネクストエンジン、GoQSystem、CROSS MALLでも、料金体系と標準範囲、アプリ・個別見積もりの条件は異なります。デモでは自店の注文データを使い、できるかどうかではなく誰が何分で処理するかを測ります。
STEP 06
通常注文より例外注文を先に試す
通常の単品注文だけでは差が見えません。住所変更、欠品、同梱、分割配送、一部キャンセル、一部返金、予約商品、セット品、複数倉庫、出荷後キャンセルを試します。元チャネル、OMS、倉庫、顧客通知、在庫、会計の各状態が一致するか確認し、自動処理できない注文は検知方法、担当、処理期限を決めます。
STEP 07
費用対効果を人件費だけにしない
初期設定、月額、受注従量、店舗・商品追加、アプリ、連携開発、保守、教育、並行稼働を12か月総額へそろえます。効果は削減時間だけでなく、誤出荷、在庫差、販売機会損失、繁忙期の臨時人員、締切超過、問い合わせの減少を記録します。ただし削減時間が別の売上活動や休暇へ変わらないなら、金額効果として過大評価しません。
STEP 08
導入は一括切替より並行検証する
商品・在庫・受注のどこから連携するか、基準データの正本を決めます。代表注文と例外注文を旧手順と並行処理し、件数、金額、在庫、出荷、通知が一致してから範囲を広げます。切替日、停止条件、切戻し、未処理注文、データ出力、権限停止、障害時の手動手順を文書にし、繁忙期直前の全面切替を避けます。