結論から先に言う。倉庫のネットワーク障害には2種類ある。RFハンディとWMSをつなぐ回線が落ちる――これは「骨折」。WMSサーバーそのものが死ぬ――これは「心停止」だ。骨折はハンディのオフラインモードで対処できる。心停止は紙の緊急伝票と事後の照合でしのぐしかない。ピッキングと入荷にはオフライン時のコンティンジェンシーが必須だ。ダッシュボードやレポートは賭けてもいい――負けたところで後から見れば済む。貨物はちゃんと出ていく。
2021年、私はカリフォルニア州オンタリオにある90,000平方フィートの3PL倉庫でWMSの本番稼働を担当していた。現場にはZebra TC52のハンディが30台、ピーク期は1日4,000件以上の出庫オーダー、すべてをRFスキャンで回していた。ある午後、サーバールームの空調が故障し、コアスイッチが過熱して再起動、WiFiが40分間停止した。すべての端末に「接続失敗」が表示され、ピッカーたちは通路で手持ち無沙汰に立ち尽くした。40分間、倉庫は実質ストップ――貨物がないからではない。何をピックしてどこに置くか、誰も分からなくなったからだ。あの日以来、オフライン時のコンティンジェンシーは、私が関わるすべてのWMSプロジェクトの受入チェックリストに入る。コンティンジェンシーなしで本番稼働なし。
ネットワークが落ちてもRFハンディはスキャンを続けられるか
答えはイエス――ただし、ハンディアプリに本物のオフラインモードがある場合に限る。営業資料が言うような「なんちゃって」ではダメだ。
WMSベンダーの多くがオフライン対応をうたっているが、実際はモバイルアプリがキャッシュしているのはログイン画面だけで、タスクデータは端末にまったく保存されていない。デモを額面通り受け取ってはいけない。受入時には電源プラグを抜いてテストする。ネットワークを落とした状態で、スキャンピッキング、スキャンによる棚入れ、棚卸しカウントができ、すべてのスキャンが端末に保存されるか。できれば、それがオフラインモードだ。
動作には2つの条件が揃わなければならない。シフト開始前に、その日の波動タスク（wave）、ロケーションマスタ、商品バーコードライブラリを各端末にプッシュしておくこと――Zebra TC52クラスのAndroid端末なら数万件のタスクレコードは余裕で持てる（正確な上限はベンダーのドキュメントで確認）。ネットワークが落ちたら、すべてのスキャンにタイムスタンプを付けて端末内でキューイングし、回線復旧後に順番どおりアップロードする。この2つが揃わなければ、ただの見せかけだ。
ここには私がまんまとハマった落とし穴がある。オンタリオでの話だが、回線が復旧した瞬間、30台の端末が溜め込んだスキャンを一斉にサーバーに送りつけ、WMSのデータインターフェースがタイムアウトに陥った。レコードの約半分は書き込まれず、残りの半分は二重に書き込まれた。対策は2つの設定で決着した。端末側のアップロードスロットリング――洪水ではなく、時間をずらしたバッチ送り。そしてサーバー側の冪等性チェック――端末のシリアル番号＋タイムスタンプを一意キーにし、重複は到着時点で破棄する。この2つが受入チェックリストに入っていなければ、そのオフラインモードは飾りにすぎない。
中断箇所からの再開（resume-from-breakpoint）は、同じ考え方をタスクに適用したものだ。波動ピッキングが切断の途中で死ぬ。回線が戻ったら、波動全体を再ダウンロードするのではなく、中断した行から続行すべきだ。そのためには、タスクの進捗をリアルタイムで端末に書き込み、アップロードに「完了行数」マーカーを付ける。受入時には明示的にテストする。20行目でネットワークを切断し、残りをオフラインで完了させ、復旧後、システムがその20行を正当に認めるかを確認する。認めなければ、差し戻しだ。
サーバーが本当に死んだら、紙運用をどう混乱なく回すか
サーバーが死んだらオフラインモードの出番ではない――端末にキャッシュされたわずかなデータでは、1シフトまるごと持たない。そのときは紙の緊急伝票が引き継ぐ。ただし、いい加減な紙運用は立ち止まるより始末が悪い。帳簿がぐちゃぐちゃになったら、復旧後の3日間はほつれを解く作業に費やすことになる。
災害が来る前に準備しておくべきことが3つあり、いずれも譲れない。あらかじめ印刷した緊急ピッキング伝票を、スーパーバイザーのオフィスのキャビネットに保管する。テンプレートの各行にバーコード欄を付ける――ロケーションバーコード、商品バーコード、数量欄――必ず「バーコード＋人にも読める数字」のセットにする。なぜか。事後入力のときに、担当者がSKUを手で打ち込むのではなく、紙をスキャンすれば済むからだ。速いし、ミスは格段に少ない。オンタリオでの事後サンプリングでは、完全手書きのSKU伝票は、入力エラー率が通常の3～5倍だった（当プロジェクトでの実測値、おおよそ）。バーコード付き伝票はほぼエラーなしだった。
2つ目は伝票の採番だ。緊急伝票にはすべて一意の番号が必要――EMRG-日付-連番のような形にする。どの伝票を誰に渡し、どれが戻ってきたか、スーパーバイザーが手で台帳に記録する。番号のない紙は、照合のときに伝票の紛失に気づく術がない。1枚の紛失は、解決不能な混乱1件だ。
3つ目は事後入力の「二人組ルール」だ。ネットワーク復旧後、1人が紙のデータをWMSに入力し、もう1人が約10％を抜き取りチェックする（おおよその目安――自社の許容値を決めておく）。事後入力が終わるまで、対象ロケーションはロックしたままにする。ライブの移動は一切禁止だ。ライブ取引と事後入力を混ぜたら、帳簿は永遠に合わない。
紙運用でよく見落とされる部分がある。入荷だ。サーバーが死んでいるとASNが来ないので、入ってきた貨物はそのままステージングエリアに置き、トレーラーのナンバープレート、個数、荷印を紙に記録して、写真も撮る。入荷トランザクションはシステム復旧まで待つ。ステージングエリアは事前に区画しておく――危機の最中に床面積を探しに行くな。
回線復旧後、最初に照合すべきものは何か
ネットワークが戻ったからといって、通常業務ではない。私は3つのことを決まった順序で進める。順序が重要だ。
まずタイムスタンプだ。オフラインで記録されたタイムスタンプがサーバー時刻と整合しているかどうかが、在庫台帳の順序を決める。端末とサーバーはどちらもNTPソースに同期させなければならない。数分のズレでオフライン記録とオンライン記録が正しくインターリーブされず、出てきた棚卸差異に頭を抱えることになる。オフライン設計の受入では、意図的に1台の端末の時計を10分ずらし、ネットワークを切断して、システムがそれを検知できるか見る。検知できない設計は受入不合格だ。
次に重複と取りこぼしだ。オフラインキューのアップロードログをエクスポートし、WMSの在庫トランザクションテーブルと1行ずつ突き合わせる。二重に書き込まれたスキャンはないか（冪等性の抜け）。消えたスキャンはないか（アップロードのタイムアウト）。まずピッキングと棚入れをチェック――高頻度の動きだからだ。入荷と棚卸しカウントは後回しでいい。
最後に紙の締めだ。緊急伝票を1枚ずつ処理していく。発行した伝票、戻ってきた伝票、入力した伝票――この3つの数字が一致するまで終わりにしない。1枚足りなければ、スーパーバイザーの手書き台帳をたどって追いかける。オンタリオの40分の障害は、照合にまるまる1午後かかった（当プロジェクトでの実測）。40分の停止に4時間の照合――この比率は事前に経営層に伝えておく。さもないと、WiFiのアンテナマークが戻った瞬間に「もう大丈夫」と思われてしまう。
そして照合レポートにサインが入るまで、「復旧しました」と報告してはいけない。私のルールはこうだ。そのサインが入るまで、倉庫のステータスは対外的に「制限付き運用」のままだ。
今週できる3つのこと
- プラグを抜くテストをやってみる。オフピークの時間帯を選び、ピッキングゾーンのAPを1台止める――ハンディを機内モードにするだけでもいい――アプリが波動をオフラインで完遂し、再接続後にデータが無事かを確認する。20分で、自社のWMSのオフラインモードが本物かどうかが分かる。
- 緊急ピッキング伝票のテンプレートを50枚印刷する。上記の「バーコード＋数字」形式で作り、スーパーバイザーのオフィスに施錠して保管する。次のサーバー障害のとき、少なくとも紙はある。
- すべての端末とサーバーのNTPを同期させる。各ハンディにログインして時計をサーバーと比べ、1分以上ずれているものを修正する。これまでで最も安いコンティンジェンシー投資だ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
