受発注・在庫の作業は、渡していいものと人が持つものに分かれます。渡していいのは判断を伴わない転記・仕分け・集計、人が持つのは例外対応と「在庫数の正本をどこにするか」の決定です。着手は、頻度が高く、間違えても取り返せる作業から。順番を逆にすると、自動化はミスを増幅させます。
- 渡していい: 受注メールの仕分け、台帳への転記、在庫数の集計。判断が一切入らない作業
- 人が持つ: 欠品時の代替提案、取引先ごとの例外ルール、在庫数の正本をどこに置くかの決定
- 着手順: 「頻度が高い × 1回あたりが短くない × 間違えても取り返せる」の3条件が揃う作業が最初
受発注と在庫の作業は「転記」「判断」「例外」に分かれる
ここで扱うのは、モールと自社ECに入る受注の処理と、卸や仕入先への発注の両方だ。中身は三つに分解できる。入力と出力の形が決まっていて解釈が入らない転記、入力を見て何かを決める判断、そもそも入力がそろっていない例外だ。この三つをひとくくりにしたまま自動化すると、例外で止まる。
転記はどこまで渡していいのか
解釈が入らないものは全部渡してよい。受注データのCSV出力と取り込み、CSVの列の並べ替え、伝票番号（お問い合わせ番号）の書き戻し、日次の在庫数の集計。どれも「どこからどこへ運ぶか」しか決まっていない作業だ。
転記の中でも、まずメールの仕分けから始めるのが軽い。受信箱の手前だけを整えるので、失敗しても元のメールが残る。受発注メールの仕分けをノーコードで自動化した記録がこの一段目にあたる。
判断を渡すには何が足りないのか
判断の基準が、担当者以外が読める文章になっていないものは渡せない。判定は三つだ。
- 入力が毎回そろっているか。そろわない前提の作業は判断ではなく例外だ
- 判断の基準を、担当者以外が読める文章で書けるか
- 間違えたときに元に戻せるか
三つ目が満たせない作業は、精度が高くても渡さない。この基準を当てると、見た目と中身が逆転した作業が出てくる。「入金が確認できたら出荷指示に進める」は判断に見えて、数字と条件で書き切れるので転記の側だ。逆に、住所を見て届くかを決める、旧型番と新型番が混ざる商品名の突き合わせは、転記に見えて判断であり、渡すと事故る。
例外はなぜ自動化に向かないのか
例外は1件で完結しないからだ。番地以降が抜けた住所、注文確定後のお届け日指定の変更、セット商品で構成品の一部だけ欠品、取引先ごとに違う締め時間。どれも調べて連絡し、返信を待って再開する往復が入り、作業は中断して保留リストに積まれる。定型を自動化しても、担当者が抱える保留件数は減らない。
渡す前に決めるのは「在庫数の正本はどこか」
判別は一つの問いでできる。在庫数が食い違ったとき、あなたはどの数字に合わせますか。即答できないなら、正本は決まっていない。候補はそう多くない。
- 倉庫の実数: 最も正しいが反映が遅く、売り越しの検知が出荷時まで遅れる
- 手元のスプレッドシート: 担当者が更新している間だけ正しく、休むと止まる
- 一元管理の仕組み側: 取り込みが定期実行なら、その間隔ぶんずれる
- モール側の在庫数を各チャネルでそれぞれ管理: 正本が複数あるのは実質「正本なし」だ
どこに置くのが正解かは、倉庫の運用と扱う商品で変わる。ただし1か所に決めること自体は前提だと考えていい。正本を決める作業は、担当者の頭の中にある判断を外に出す作業でもある。在庫管理の「勘」を言語化しておくべきことと地続きの話だ。
なぜ在庫連携ツールを入れてもずれるのか
原因はツールの外側に残っていることがある。先に見るのは次の五つだ。
- 在庫数の正本が決まっていない
- 更新のタイミングが揃っていない。連携の定期実行、受注の締め時間、倉庫の入出庫登録が別の時計で動いている
- SKUや商品コードがチャネル間で一致せず、対応表が最新になっていない
- 連携の対象外の在庫変動がある。予約分、セット商品の構成品、返品戻しの再入庫
- 引き当て（仮押さえ）の考え方が場所ごとに違う
販売可能在庫を「実数−（引き当て済み＋安全在庫）」として分けず実数をそのまま流すと、数字は正しいのに売り越す。
どこから手をつけ、止まったらどう気づくか
優先度の軸は、頻度、1回あたりの所要時間、間違えたときの被害の三つ。効くのは三つ目だ。
頻度が高く取り返せる作業が最初になる。受注メールの仕分け、伝票番号の書き戻し、CSVの整形。一方、取り返せないものは三つに絞れる。出荷してしまったもの、顧客に送ってしまった連絡、売り越した在庫だ。在庫数の一括更新、出荷指示、キャンセル処理はここに触るので、人の確認を一段挟む半自動から始める。頻度が低く1件が長い例外対応は、自動化より手順書化が先に効く。
自動化が止まったことに、誰がどう気づくのか
成功の通知ではなく、件数の一致で見る。自動化の失敗は「動かなかった」という形で現れるので、成功時に通知を出す仕組みでは検知できない。気づくのはたいてい外からだ。顧客からの「発送されない」という問い合わせ、倉庫からの「出荷指示が来ていません」という確認連絡。受注の件数と出荷指示の件数を日次で突き合わせれば、外から言われる前に気づける。
組んだ本人しか中身を知らない仕組みは、止まったときに直せる人がいない。渡す作業を決める過程で言語化した判断基準は、そのまま引き継ぎの材料になる。
よくある質問
受発注を全部自動化することはできますか
例外処理が残るため現実的ではない。住所の不備や注文確定後の変更は入力がそろわない状態から始まるので、判断を渡す前提が満たせない。定型を自動化し、例外を人に寄せる形が到達点だ。
在庫連携ツールを入れたのに在庫がずれるのはなぜですか
正本が決まっていないか、更新のタイミングが揃っていないかを先に疑う。ツールを替える前にこの二つだ。SKUの対応表が最新かも同時に見ておく。
まず何から手をつけるべきですか
頻度が高く、間違えても取り返せる転記作業だ。受注メールの仕分けと台帳への転記。元のデータが残るので、動かしながら直せる。
あわせて読みたい：EC担当者がAI時代に学ぶべきスキルは、業務を3つに分けると決まる
あわせて読みたい：ECの手作業をつなぐ：GAS・API・ノーコードの選び分け
コメント