受注管理をカートから分ける判断 — OMSが必要になる境目

「受注管理システム（OMS）を入れるべきか」という相談は、たいてい すでに運用が壊れかけてから 来ます。壊れる前に境目を知っておくと、判断が前倒しできます。

カート内蔵で足りる状態

次の条件が揃っているうちは、カートの受注機能で回ります。

• 販売チャネルが自社ECだけ
• SKUが少ない（単品〜数点）
• 出荷が1拠点
• 定期の契約管理がカート側で完結している
• 受注から出荷指示までを手作業で回せる件数

ここで無理にOMSを入れると、連携の維持コストだけが増えます。

分ける必要が出る境目

次のどれかに当たると、カート内蔵では苦しくなります。

1. 販売チャネルが増えた

自社ECに加えてモール、卸、実店舗が入ると、在庫を1か所で見る必要が出ます。チャネルごとに在庫を持つと、必ず売り越しか機会損失のどちらかが起きます。

2. 出荷拠点が複数になった／外部倉庫を使う

倉庫（3PL）と連携するなら、受注データを倉庫のフォーマットに変換する層が要ります。カートから直接出せる範囲を超えたところで、OMSかミドルウェアが必要になります。

3. 同梱物の出し分けが必要になった

「初回の人にはA、3回目の人にはB」といった条件分岐が入ると、出荷指示に契約情報が必要です。カートと倉庫のあいだで、この判断をどこがやるかを決めなければなりません。

4. 手作業の時間が件数に比例し始めた

これが最も分かりやすい境目です。受注処理の時間を件数で割って、1件あたりの分単位を出してください。 その値が下がらないまま件数だけ増えているなら、仕組みで解いていない証拠です。

5. 定期の契約管理が複雑になった

スキップ、周期変更、商品変更、数量変更が日常的に発生し、それが出荷計画に影響するようになると、契約と受注を分けて持つ必要が出ます。

分けるときの設計

OMSを入れる場合、どこが何を持つかを先に決めます。曖昧なまま繋ぐと、二重管理が生まれます。

「顧客対応の履歴」を決めないまま進むと、CSがどこを見ればよいか分からなくなります。

定期通販に固有の論点

一般的なOMS選定の記事に書かれていない、定期通販ならではの確認点です。

• 次回配送予定の変更が、出荷計画にどう反映されるか。 顧客がスキップした情報が倉庫まで届くタイミング
• 決済失敗時に出荷を止められるか。 決済が通らないまま出荷される事故を防ぐ
• 回数に応じた同梱物の出し分けができるか
• 解約後の在庫引当を解除できるか

1つ目と2つ目は、実際に事故が起きてから気づかれることが多い項目です。デモの段階で通してもらってください。

判断の順序

1. 1件あたりの受注処理時間を測る（件数で割る）
2. その値が件数の増加とともに下がっているかを見る
3. 下がっていないなら、どの作業が比例して増えているかを特定する
4. その作業がカート側の設定で解けるかを先に検討する
5. 解けないなら、OMSかミドルウェアの検討に入る

4を飛ばさないでください。 カート側のマイページ機能や自動化設定で解ける作業を、システムを増やして解こうとすると、連携の維持コストが乗るだけになります。

システム選定全体の考え方はカート・基幹システムをどう選ぶかにまとめています。

よくある質問

何件くらいからOMSが必要ですか

件数の閾値では決まりません。1件あたりの受注処理時間を測り、件数が増えても下がっていないかで判断してください。チャネルが1つで単品なら、かなりの件数までカート内蔵で回ります。

カート一体型とOMS分離型はどちらがよいですか

チャネルが自社ECだけなら一体型が有利です。モール・卸・店舗が入って在庫を統合する必要が出た時点で、分離型の価値が出ます。

倉庫（3PL）を使うと必ずOMSが要りますか

必ずではありません。倉庫側が受け取れる形式でカートから出せるなら、当面は不要です。同梱物の出し分けなど条件分岐が入ると、変換する層が必要になります。

決済失敗のときに出荷を止められますか

システムによります。止められないと、決済が通っていない注文が出荷される事故が起きます。選定時に必ず確認し、デモで実際に通してください。