ARTICLE SUMMARY
システムは、現場の作業を助けるためのものです。
小規模ECでは、大型の一元管理システムをそのまま導入しても、現場に合わず、かえって業務が重くなることがあります。弊社の経験では、商品IDなどの土台を整理し、毎日発生する一番面倒な作業から小さく改善し、実際に使いながら機能を育てる方法が現実的です。
ALL-IN-ONE SYSTEM
最初から大型のEC一元管理システムを入れるのが難しい理由
大型システムには受注、在庫、出荷、商品、売上管理など多くの機能があります。しかし、多くの会社で使えるように作られているため、自社独自の商品ID、配送会社の使い分け、返品対応、納品書形式などに完全に合うとは限りません。
- 自社専用に作られたシステムではない
- 操作を理解するまでに時間がかかる
- 独自業務に必要な細かい機能が不足する
- 投資が大きく、業務変化に合わせにくい
市販システムが悪いわけではありません。重要なのは、自社の規模、業務内容、作業人数、今後の成長に合う方法を選ぶことです。
PRODUCT ID
商品IDの定義は、システム化の土台になる
商品IDにハイフンやアンダーバーをその場の判断で入れていると、後からシステムで処理する際に、どこまでが商品本体のIDで、どこからがSKU属性なのか判断しにくくなります。
| 不統一な例 | 起きやすい問題 |
|---|---|
| abc-001 / abc_001 / abc001 | 商品本体IDとSKU属性を判定しにくい |
| モールごとに異なる商品ID | 在庫、販売数、発注データを対応付けにくい |
| セット商品のルールがない | 構成商品の在庫を正しく減らせない |
商品IDのルールが乱れていると、在庫管理、SKU分解、セット商品、モール別ID、発注管理へ問題が広がります。開発を始める前に、まずこの土台を整える必要があります。
STEP BY STEP
すべてを一度に開発せず、一番困っている作業から始める
EC業務には、商品企画、仕入れ、在庫管理、商品登録、受注処理、配送判定、納品書、送り状、ピッキング、梱包、返品対応など多くの工程があります。最初から全部をシステム化すると、開発が大きくなり、仕様が実際の運用に合わないリスクも高まります。
| 段階 | 改善内容 |
|---|---|
| 1 | 商品IDとSKUのルールを整理する |
| 2 | 複数モールの注文CSVを共通形式にする |
| 3 | 配送会社用CSVを作成する |
| 4 | 住所不備、重複注文、配送方法をチェックする |
| 5 | 納品書、送り状、ピッキングを効率化する |
| 6 | 在庫、発注、仕入れ管理へ広げる |
ORDER TO SHIPPING
弊社は複数モールの注文CSVと配送CSVの変換から始めました
弊社で最初に大きな負担になっていたのは、複数モールの注文処理でした。モールごとに注文CSVの形式が異なり、配送会社ごとのCSV形式も違うため、毎日同じ変換作業が発生していました。
- 複数モールの注文CSVを取り込む
- 自社で使いやすい共通形式へ変換する
- 配送会社ごとの形式へ変換する
- 複数の配送会社で送り状を発行する
DECISION FUNCTIONS
基本処理が安定した後に、判断機能を追加する
注文CSVの取り込みと配送CSVの作成に慣れた後、住所不備や配送方法などの判断機能を追加しました。基本処理が安定してからチェックと判断を増やすことで、現場も無理なくシステムに慣れていきます。
TAILORED SYSTEM
自社に合うシステムは、服のように少しずつ合わせて作る
既製品の服が体型や動き方に完全に合わないことがあるように、市販のECシステムも、自社の商品、配送方法、人数、在庫管理、出荷速度に完全に合うとは限りません。
- 現在の業務を先に確認する
時間がかかる場所、ミスが起きやすい場所、毎日発生する作業を整理します。
- 現場の作業速度を落とさない
確認項目を増やしすぎず、少人数でも業務を回しやすい状態を目指します。
- 例外処理を考える
住所変更、キャンセル、返品、同梱、分納などをどう扱うか決めます。
- 一度で完成させようとしない
小さく作り、実際に使い、次の改善点を見つけながら育てます。
CONSULTATION
現在、一番時間がかかっているEC業務から見直しませんか？
注文CSV、配送CSV、納品書・送り状PDF、商品ID、在庫・発注管理など、現在の業務フローに合わせて、小さく始められる改善方法をご提案します。
お問い合わせ方法を見る