2019 年、私はフォンタナにある EC 倉庫を訪れた。棚卸差異は 1.8%。オーナーは夜も眠れなかった。一週間かけて原因を探した。盗難ではなかった。システムのバグでもなかった。根本原因は、作業員がロケーション B-14-06 を B-14-09 と聞き間違えていたことだった。手書きのピッキングシート、口頭での読み上げ、そして 6 は 9 にそっくりだ。一文字違いの誤ピッキングが年間数千件。
結論はシンプルだ。ロケーションコードの末尾にチェックディジットを付けるのは、倉庫全体で最も安いエラー防止策だ。新しいスキャナの 100 分の 1 のコストで、監査員を増やすより 10 倍確実だ。
チェックディジットが実際にやること
発想はバーコードから借りたものだ。商品バーコードの最後の桁はランダムではない——前のすべての桁から計算された、組み込みの検証コードだ。ロケーションコードにも同じことをする。固定のアルゴリズムで残りの部分から計算した一文字を末尾に追加する。作業員がロケーションを入力またはスキャンすると、システムが再計算し、一致しないものは却下する。タスクはその場で止まる。
例を見てみよう。ロケーション A-03-12 のチェックディジットは 7 と計算されるので、フルコードは A-03-12-7 になる。作業員が打ち間違えて A-03-21 と入力した。システムは再計算し、7 ではなく 4 を期待して、即座にエラーを投げる。ミスは発生したその瞬間に死ぬ。棚卸カウントで表面化することはない。
アルゴリズムを発明する必要はない。主力は重み付きモジュラス 10 だ。各桁に交互の重み（1, 3, 1, 3…）を掛け、合計し、最後の桁を取り、10 から引く。ほとんどの WMS は設定可能なチェックルールをサポートしている。対応していなければ、数十行のコードで済む。唯一の要件は一貫性だ——一つのアルゴリズムを、至る所で。
先にコーディング体系を直せ。そうでなければチェックディジットは無意味だ
チェックディジットは打ち間違いを防ぐ。混乱した体系は直せない。だから桁を追加する前に、ロケーションコーディングのルールを整える。私が顧客に渡す体系は四つのセグメントで構成される。ゾーン-通路-段-列だ。たとえばゾーン A、通路 3、段 2、列 12 を A-03-2-12 のように書く。
いくつかの鉄則がある。
数字を先に、文字はゾーンのセグメントだけにし、紛らわしいものは禁止する。I と 1、O と 0、S と 5、Z と 2——すべて却下だ。ゾーンコードに B と 8 を使っている倉庫を見たことがある。作業員が毎日混同し、全部が改名されるまで続いた。
セグメントごとに桁数を固定する。通路番号は常に二桁（3 ではなく 03）、段は一桁、列は二桁。桁数を固定すればチェックアルゴリズムが安定し、作業員が欠けた文字を一目で見つけられる。
ピンインや人の名前、商品名をロケーションに使ってはならない。親しみやすく感じて大惨事だ。「王さんのゾーン」「売れ筋ゾーン」は次の新入社員には何も意味しないし、検証できるシステムは存在しない。ロケーションコードは機械とプロセスのためにある。郷愁のためではない。
古い倉庫の改修は怖くない。手順はこうだ。新ロケーション表を丸ごと生成し、新旧変換シートを印刷して通路の入り口に掲示する。一か月間はデュアルモードで運用する——両方のコードが使えるが、システムに記録されるのは新しい方だ。一か月後、旧コードを廃止し、スキャナが新しいコードだけを受け入れるようにする。移行期間の印刷費は惜しむな。それだけの価値はある。
WMS で設定し、スキャナで捕まえる
検証は早ければ早いほどいい。理想はスキャナ本体でのリアルタイム検証だ。作業員がロケーションのバーコードをスキャンすると、デバイスがその場でチェックディジットを検証する。間違ったコードには振動と赤いランプだ。スキャン→同期→エラーより勝り、棚卸カウントで問題が発覚するより勝る。
WMS 側の手順は三つだ。ロケーションマスタにチェックディジットのフィールドを追加し、一括で生成する。ピッキング、入庫、棚卸カウントのタスクの確認ステップに検証ロジックを追加する。例外フローを定義する——検証に失敗したらタスクを停止し、スーパーバイザーに回す。スーパーバイザーは強制承認できるが、理由の入力は必須だ。
このオーバーライドは存在しなければならない。ラベルは傷むし、臨時ロケーションもあるからだ。だが理由のフィールドは必須だ。私はデータを見たことがある。強制オーバーライドが 5% を超える倉庫では、10 回中 8 回、根本原因はラベルの印刷品質の悪さだ——プリンタを交換すれば問題は消える。データは語る。記録していれば、だが。
ほとんどの人が見落とす点がある。棚卸カウントにも桁が必要だ。間違ったロケーションをスキャンしたカウンターは、他人のスロットにカウントを記録してしまい、差異は複利で増える。チェックディジット導入後、カウント差異は通常三分の一以上減る。
計算：誤ピッキング一件の本当のコスト
誤ピッキングのコストは、再ピッキングの人件費だけではない。全請求書はこうだ。作業員が気づいて歩いて戻す、15 分の人件費。気づかれなければ顧客に届く——20 分のカスタマーサービス、再発送の運賃、返品の運賃、そして商品は二度と戻ってこないかもしれない。EC の小口貨物では、誤ピッキング一件の平均は $15 から $35 だ。
月 20,000 オーダーの倉庫で誤ピッキング率 0.3% なら、月 60 件の誤ピッキング——直接コストだけで年間 $10,000 超。失った顧客は数に入っていない。
そしてチェックディジットは？ ハードウェアはゼロだ。新倉庫は初日から組み込む。既存倉庫は週末を使ってコードを生成し、ラベルを印刷するだけだ。唯一の実コストは WMS 設定の半日と、30 分の作業員トレーニングだ。倉庫におけるこれ以上の ROI を私は思いつかない。
注意リスト：
- アルゴリズムを共有ドライブに文書化する。新入社員トレーニングでは 30 分かけて必ずカバーする。IT だけが分かるブラックボックスにさせない。
- 臨時ロケーションにもコードが必要だ。「臨時」こそミスが起きる時だ——検証の対象外にしてはならない。
- 特殊文字は使わない。ダッシュが多すぎるとスキャナが混乱する。セグメント間のハイフンは一つで十分だ。
- ゴーライブ後の最初の週は、検証失敗ログを毎日読む。特定のロケーションに失敗が集中していたら、ラベルの貼り間違いの疑いが濃い——歩いて見に行く。
今夜できること
ロケーションテーブルをエクスポートしてフィルタする。一文字違いの「双子ロケーション」はないか。A-03-16 と A-03-19、B-14-06 と B-14-09 のように。あればまず改名して距離を作り、それからチェックディジットを追加する。この二つのステップを踏めば、誤ピッキング率は半減する。夕食をおごってもいい。
ロケーションコーディングは、壊れるまで誰も気にしないものだ。チェックディジットはコーディング体系の保険だ——保険料はほぼゼロで、請求の時が来たら加入しておいてよかったと思う。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
