独自ドメインのECサイトでも、ショッピングモールでも、有料のショップ構築サービスでも。どうしても付いてこないものがあります。
顧客管理・在庫管理のシステムです。
「あって当然では」と思われるかもしれませんが、実はそうではありません。この記事では、なぜECサイトに在庫管理機能がないのか、そして何と組み合わせればよいのかをご説明します。
ECサイトは「売るため」のシステムです
ECサイトが担っているのは、次の流れです。
商品を並べる → お客様がカートに入れる → 注文する → 支払う → 注文情報がショップに届く → 入金を確認する → 発送する
つまり「注文」と「受注」に特化したシステムです。売る場所であって、倉庫を管理する場所ではありません。
在庫数を持ってはいますが、それは「販売可能な数を表示するための数字」であって、倉庫のどこに何があるかを管理するためのものではありません。
技術的にも、事情があります
ECサイト構築ソフトのプラグインや拡張機能は、多くがWebサイト向けの技術で作られています。
一方、在庫管理や顧客管理のように、大量のデータを扱い、複雑な計算をし、複数人が同時に更新するようなシステムは、性質が異なります。同じ土台の上に載せようとすると無理が出ます。
加えて、機能を増やせばそれだけ費用がかかります。気軽に使えるサービスに本格的な在庫管理を組み込むことは、価格面でも現実的ではありません。
簡単な請求書や領収書の発行、受注一覧の出力といった範囲であれば対応できますが、そこから先は別のシステムの領域になります。
3つの層に分けて考える
通販事業のシステムは、役割ごとに3つの層に分けると整理しやすくなります。
- 販売の層（ECサイト、モール）……商品を見せて、注文を受ける
- 受注管理の層（ネクストエンジン、CROSSMALLなど）……複数の販売経路の注文を集約し、在庫数を各モールへ反映する
- 倉庫の層（WMS）……棚のどこに何があるかを管理し、検品して出荷する
1つのシステムですべてを賄おうとすると、どこかが手薄になります。それぞれが得意な範囲を担当し、データで連携するのが現実的な形です。
どの層から必要になるか
すべてを最初から揃える必要はありません。事業の状況によって、必要になる順序があります。
- 1店舗のみ、出荷が少ない……ECサイトの機能だけで回ります
- 複数モールに出店した……在庫数の同期が手作業では追いつかなくなり、受注管理システムが必要になります
- 出荷が増え、誤出荷や在庫差異が出てきた……倉庫の層（WMS）が必要になります
順序としては、受注管理が先、倉庫が後になることが多くなります。ただし自社倉庫で自社出荷をしている場合は、早い段階で倉庫側の課題が出てきます。
入れ替えではなく、足す
WMSを検討されるとき、「いまのシステムを入れ替えることになるのでは」と心配される方がいらっしゃいます。
その必要はありません。ECサイトも受注管理システムも、いまお使いのものをそのまま継続できます。ゼータロジが担当するのは倉庫の中だけです。
連携はCSVまたはAPIで行います。CSVの場合、いま出力している形式のまま取り込めるため、既存の運用を作り直す必要もありません。
連携でつまずきやすい点
層を分ける方式には利点がありますが、つなぎ目には注意が必要です。
在庫数を、どちらが持つか
受注管理システムも在庫数を持ちますし、WMSも在庫数を持ちます。両方が別々に管理すると、必ずずれます。
どちらを正とするかを最初に決めてください。倉庫の実物に基づく数字を正とするなら、WMSからモール側へ反映する流れになります。
商品コードを揃える
モールごとに違う商品コードを使っていると、どのシステムでも突き合わせに苦労します。社内で一貫したコードを決めておくと、連携が一気に楽になります。
セット商品の扱いを決める
セット販売をしている場合、倉庫側に渡すデータをセット品番のままにするか、構成品に展開するかで運用が変わります。展開して渡すのが基本です。
連携のタイミング
リアルタイム連携が必要か、1日数回の取り込みで足りるか。出荷の締め時間と、モールの在庫更新頻度から判断します。多くの場合、1日数回で十分に成立します。