出荷ミスを工程別に防ぐ｜どの段階でバーコードをスキャンすべきか

ゼータロジが担っている役割は、大きく4つあります。

• 入庫と出庫を確実に行う
• 在庫管理を確実に行う
• バーコードによる商品管理を行う
• 注文どおりの出荷を間違いなく行う

この記事では、最後の「注文どおりの出荷を間違いなく行う」を取り上げます。出荷までの工程を分解し、どの段階でバーコードをスキャンすべきかという設計の話です。

出荷までの5つの工程

楽天市場やAmazonから入った注文データをWMSに取り込むところから、出荷までの流れを見てみます。

1. 受注データの取込……CSVまたはAPIで注文情報を取り込む
2. 引当……どの棚のどの在庫を、その注文に割り当てるかを確定する
3. ピッキング……ピッキングリストに従って商品を集める
4. 出荷検品……集めた商品が注文と一致するかを照合する
5. 送り状の貼付・出荷

それぞれの工程に、ミスが入り込む余地があります。

引当の段階で、事故は構造的に防げる

引当とは、注文に対して在庫を割り当てる処理です。単に「在庫がある」ことを確認するのではなく、どの棚のどのロットを使うかまでを確定させます。

この処理があることで、次のようなことが起こらなくなります。

• 同じ在庫を2つの注文に割り当ててしまう
• 在庫があると思って出荷準備を進めたら、実際にはなかった
• 先に処理した注文と後の注文で、在庫の取り合いになる

引当ができなかった注文は、欠品として抽出されます。出荷できない注文が、出荷作業の列に混ざらないという状態を作れます。

ピッキング時にスキャンしない、という設計

ここからが、ゼータロジの設計上の特徴です。

数十年前のWMSでは、ピッキングのときにもバーコードをスキャンし、出荷のときにもスキャンするのが一般的でした。二重に確認するという考え方です。

ゼータロジは、ピッキング時のバーコードスキャンを必須にしていません。理由は2つあります。

理由1：ピッキング作業の効率

棚の前で1点ずつスキャンする動作は、積み重なると無視できない時間になります。1日数百件の出荷であれば、その分だけ作業時間が増えます。

理由2：梱包時のスキャンのほうが確実

ピッキング時にスキャンして正しく集めたとしても、梱包の段階で入れ間違えれば誤出荷になります。最後の工程を通過するものが、実際にお客様へ届くものです。

逆にいえば、ピッキングで間違った商品を持ってきたとしても、出荷検品のスキャンで確実に弾かれます。最後に一度、確実に止める。これで十分に防げます。

二重チェックが、かえって危ないことがある

ピッキング時と出荷時の両方でスキャンしている場合、次の心理が働きやすくなります。

• ピッキング担当「出荷のときに気づいてくれるだろう」
• 出荷担当「ピッキングでスキャンしているから大丈夫だろう」

自動車教習所で習う「だろう運転」と同じ構図です。確認する人が増えるほど、一人あたりの責任感は薄まります。

チェックポイントを増やすことと、精度が上がることは同じではありません。どこで確実に止めるかを1か所決めて、そこを徹底するほうが、結果として精度は上がります。

ピッキング時にもスキャンしたほうがよい場合

とはいえ、例外もあります。次のような場合は、ピッキング段階での記録が有効です。

• 1件あたりの点数が非常に多い……どこまで集めたかを記録しながら進める必要があります
• 複数注文をまとめて集める……グロスピッキングでは、集めた総数の確認が必要です
• 複数のフロアや担当者をまたぐ……工程ごとに責任範囲を確定させたい場合です
• ロット・期限の指定がある……どのロットを取ったかを確定させたい場合です

ゼータロジはピッキング実績のスキャン入力にも対応していますので、必要な現場では使えます。必須にしていないだけで、できないわけではありません。

送り状の貼り間違いは、別の対策が要る

出荷検品で商品の精度が上がっても、残るのが送り状の貼り間違いです。この工程だけは、依然として目視のまま残っていることが多くあります。

送り状に印字されたバーコードをスキャンして照合すれば、この工程も機械の判定に置き換えられます。詳しくはテレコ出荷とは？送り状の貼り間違いが起きる原因と防ぎ方をご覧ください。

まとめ

• 引当の段階で、在庫の重複割り当てや欠品出荷は構造的に防げる
• スキャンは「最後に確実に一度」が基本。工程を増やすほど責任は薄まる
• 点数が多い、工程をまたぐといった条件がある場合は、ピッキング時の記録も併用する
• 送り状の貼付は別工程なので、別の対策が必要になる