最初に結論：ロケーションコードの末尾1桁はチェックデジットにすべきだ。私はこの失敗を3回見てきたが、3回とも結末は同じだった。盗難はなく、ただシステムが在庫を見つけられなかったのだ。1桁追加するコストはほぼゼロで、これらの「行方不明」在庫の大部分を検出できる。

直近の案件は数か月前に決着した。中国東部の自動車部品のクライアント、新設DCは約20,000平方メートル、カットオーバーから3か月後。初の全面棚卸で、どうしても合わない在庫が2,000,000円を超えた。盗難なし、誤出荷なし——40を超えるパレットが間違ったロケーションに格納されていた。ロケーションB-12-03-4がB-12-08-4と読み間違えられたのだ。フォークリフト運転手のスキャンが汚れたラベルで失敗し、手入力したところ3が8になった。WMS上では40パレットはB-12-03-4に「ある」ことになっていたが、実際にはB-12-08-4に置かれていた。丸2週間、営業は画面上で在庫を見て、ピッカーは現場で見つけられず、カスタマーサービスは顧客から、倉庫は営業からのクレームを受けた。最終的に2人で5日間かけて全ロケーションを開けて回り、ようやく見つかった。1桁の読み間違いが原因で、2,000,000円が2週間「行方不明」になったのだ。

2件目のプロジェクトはさらに痛かった。2024年初頭、中国南部の3PL倉庫が安いラベル業者に切り替えた。新しいテンプレートの余白がずれ、右端が2ミリメートル切り落とされた——ちょうどチェックデジットのある位置だ。ラベルの半数が切り詰められたコードとしてスキャンされ、現場はチェックデジットによるエラー検出なしの手入力に戻り、誤格納率が急上昇した。ラベルで節約した分では、1つの行方不明パレットを探す人件費すらまかなえなかった。2つのプロジェクト、1つは人間の読み間違い、もう1つは業者の印刷ミス——根本原因は同じだった。コード設計が、エラーに検出される機会を与えていなかったのだ。

チェックデジットがこれを防ぐ仕組み

一文で言えば：答えを内包する数字を1桁追加し、システムがすべての入力を検証できるようにすることだ。

ロケーションB12034（数字のみ、区切り文字を除去）を例に取る。WMSではLuhnアルゴリズム——クレジットカード番号と同じもの——でチェックデジット1桁を計算し、ロケーションはB12034-7となる。以降、すべてのスキャンや手入力は先に検証される。前の数字から末尾の7を再計算できるか。できなければハードストップ、赤いエラー表示、パレットが間違ったスロットに行くことはない。

魔法ではない。計算を一歩ずつ説明する。すべて再現可能だ。ロケーションの数字が417203だとしよう。

  1. 末尾にプレースホルダーとして0を付ける：4172030。
  2. 右から2番目、4番目、6番目の数字を2倍にする：3は6に、2は4に、1は2になる。（2倍して10以上になったら2桁を足す——8の2倍は16なので、1足す6で7とする。）
  3. すべて足す：0足す6足す0足す4足す7足す2足す4は23に等しい。
  4. チェックデジットは、23を10で割った余りを10から引いたもの——10引く3、つまり7。

完全なロケーションコード：4172037。運転手が417203ではなく417208と入力したとしよう。システムは4172087を検証し、計算が7にならず、パレットがドックを出る前に画面にエラーが表示される。これがすべてだ。「間違い」を検出可能にする1桁、それだけだ。

パレットラックの前でPDAスキャナーを持つ倉庫作業員

どのアルゴリズムか。自作は禁物——比較表はこちら。

| アルゴリズム | 仕組み | 検出できるもの | 弱点 | | Luhn | 1桁おきの数字を2倍して合計、mod 10 | 1桁の誤り、ほとんどの隣接転位 | 検証ロジックのWMSサポートが必要 | | 加重合計 | 各桁に固定の重みを掛けて合計、mod 10 | 1桁の誤り | 重みが間違えば保護はゼロ | | GS1チェックデジット | 奇数/偶数桁に3と1を掛ける | 1桁の誤り | 商品バーコード用に作られたもの。ロケーションに流用するには現場全体の一貫性が必要 |

私の結論：ロケーションコードにはLuhnを使え。それだけだ。「自家製チェックルール」は私が3回見た失敗だ——毎回、次のコンサルタントが古いルールを解読できず、現場は倉庫全体のラベルを貼り替えることになった。

WMSでの設定：4ステップ、どれも省略不可

  1. ラベルを1枚も印刷する前にコードルールを確定する。3つの文：ロケーションコードはゾーン-通路-レベル-ベイにチェックデジット1桁を加えたもの。区切り文字は表示用のみで計算から除外する。チェックデジットは常に末尾。これを後回しにして先に印刷すれば、貼り替えになる——私は3回見た。
  2. WMSのロケーションマスタに2つのフィールドを追加する：チェックデジットとアルゴリズム名。チェックデジットを印刷ラベルだけに残すな。システムが保存・設定する場所がなければ、ラベル業者を切り替える日が惨事の日になる。
  3. 3つのタッチポイントで検証を強制する：格納、移動、循環棚卸の調整。すべてのスキャン・手入力ロケーションを検証し、失敗はブロックして記録する。格納時だけの強制は、強制しないのと同じだ——私のプロジェクトでは、誤格納のほとんどは移動と棚卸調整で起きた。
  4. スクリプトで履歴を一括補完する：既存の全ロケーションのチェックデジットを一度に計算し、一括で貼り替える。現場に手計算させるな。30,000ロケーションの新設現場なら、カットオーバー前夜にバッチジョブを回す。

検討すべきトレードオフ：ハードブロックか警告のみか。ハードブロックは作業を遅くする——エラーごとに運転手が確認で止まる。警告のみは無視される、つまり何もないのと同じだ。私の使い分け：格納と移動はハードブロック（ここの1つのエラーはパレット1つ丸ごとの行方不明を意味する）、棚卸調整は警告＋当日レビュー（棚卸は時間に敏感で、エラーは当日中に表面化する）。どちらかの極端も間違いだ。

カットオーバー前夜のチェックリスト：5つのうち1つでも不合格なら、カットオーバーしない

  1. ラベルが切れていないか。チェックデジットは末尾にある——幅の狭い台紙やテンプレート余白の設定ミスで半分切れるとスキャンできない。10枚のラベルを1枚ずつスキャンする。サンプリングはしない。
  2. PDAの入力は固定されているか。一部のAndroid PDAはデフォルトで中国語入力になっており、全角と半角の数字はシステムにとって別の文字だ——検証がすべて失敗する。カットオーバー前に全端末を半角英数入力に固定し、1台ずつ確認する。
  3. 読み間違い対策はできているか。0とO、1とI、5とS——高所や暗い照明の下では、人間の目はこれらを常に混同する。私のルール：ロケーションコードは数字のみ、スラッシュ付きゼロの等幅フォント、0とOを同じラベルに載せない。
  4. ブロックロッグを誰か読んでいるか。誰も見ないエラーブロックは見せかけだ。初週は毎日ブロックロッグを出力する——本当のエラーかルールの設定ミスかを見極め、2週目に緩める。
  5. 旧ロケーションは補完済みか。新旧コードの混在は惨事だ。すべて補完するか、すべて置き換えるか。「既得権コード」の抜け道はなし。

直感に反する結論：作業員のせいでは決してない

30回を超えるカットオーバーで、これが起きるたび、経営層の最初の反応は「もっと教育」と「ミスへの罰則」だった。しかし長い数字列の読み間違いは人間らしさそのものだ——「気をつけろ」では何も直らず、罰金はさらに直らない。選択肢は2つある。人間は間違えるものと受け入れてシステムに検出させるか、人間は絶対に間違えないと賭けて毎月何日も「行方不明」の貨物を探すか。前者は1桁のコスト、後者はあるクライアントに帳簿上2,000,000円を失わせた。この計算は自分でできるはずだ。

明日からできること：今夜WMSのロケーションマスタを開き、チェックデジットのフィールドがあるか確認する。なければ上の5項目チェックリストを印刷して壁に貼り、次のカットオーバー前に実行する。

Lin Xiao（WMS導入コンサルタント）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。