まず結論から：WMSの権限設定ミスでデータが壊れるとき、原因はほぼ決して単一のチェックボックスではない。3つの漏れが同時に作用しているのだ――役割に広すぎる権限を与えること、顧客を無視したロケーション範囲、そして誰もロックダウンしない伝票ステータスである。どれか一つでも見逃せば、エラーメッセージ一つ出ないまま不良データがシステムを流れ続け、在庫実査や顧客からのクレームで解きほぐす羽目になるまで気づかない。
私はこのまったく同じ失敗を3回、3つの異なる倉庫で、3つの異なる症状とともに見てきた。根本原因は毎回同じだった。本番開始時に、時間を節約しようと誰かがある役割から別の役割へ権限テンプレートをコピーし、その後誰も削り戻さなかったのだ。
漏れ1：広すぎる役割の付与
2024年9月、中国東部のサードパーティ・ロジスティクス倉庫が新しいWMSを本番開始した。期限のプレッシャーの中、導入チームは在庫管理者の権限テンプレートをコピーしてピッカーの役割を作り、名前を変えた。コピーの中で一つ設定が生き残った。ピッカーが在庫数量を手動で調整できるという設定である。
本番開始から3週間後、循環棚卸の差異が増え始めた。調査の結果、割り当てられたロケーションで在庫が見つからないピッカーが、目の前にあるものに合わせるようシステム数量をこっそり編集していたことが判明した。在庫はたいてい隣のベイにあったのだが、システムは今や数量が正しいと言っていた。1か月以内に、帳簿在庫と実在庫の間で120を超えるSKUがずれ込み、2件の注文が誤出荷され、倉庫は全量実地棚卸のために丸々1週末を失った。
解決策は機能ではなく規律である。権限は職名ではなくアクション単位で付与すること。ピッカーに必要なのは、ピッキング確定、例外報告、スキャン検証である。ピッカーに在庫調整、伝票の無効化、マスターデータ編集は不要である。在庫管理者は調整を申請してよいが、その申請は承認を経なければならない。スーパーバイザーは承認してよいが、同じ取引を入力して承認してはならない。アクションのリストを書き出し、1行ずつチェックすれば、役割名が隠すものが見えてくる。
| 役割 | できること | 決してしてはならないこと |
|---|---|---|
| ピッカー | ピッキング確定、例外報告、スキャン検証 | 在庫調整、伝票の無効化、ロケーションマスターデータの編集 |
| 入庫作業員 | 入庫確定、ロケーションのスキャン、差異報告 | 顧客をまたいだ作業、商品マスターデータの編集 |
| 在庫管理者 | 調整の申請、棚卸の実施 | 自分の調整を承認すること |
| スーパーバイザー | 調整の承認、倉庫全体のレポート閲覧 | 同じ伝票の入力と承認 |
漏れ2：顧客を無視したロケーション範囲
2つ目の漏れはもっと微妙で、マルチクライアント倉庫で最も痛い目に遭う。2025年3月、中国南部の倉庫は2つの化粧品ブランドにサービスを提供していた。ロケーション権限は顧客別ではなくゾーン別にのみ設定されていた。ブランドAの作業員はブランドBのロケーションを見ることができ、リストから間違ったロケーションを選んでもシステムは止めなかった。
ブランドAのフェイスクリーム1バッチがブランドBのピックフェースに置かれてしまった。帳簿在庫はブランドAを示し、実在庫はブランドBの棚にあった。両ブランドの棚卸が失敗し、在庫移動など起きていないのに互いに相手のせいにした。段ボールを探すのに棚を1つずつ4日間かかり、遅れた注文をカバーするための緊急航空便も必要になった。
マルチクライアントの運用では、ロケーション権限は2つのことを同時にロックしなければならない。ユーザーが何を見られるか、そしてユーザーが何に触れられるかである。可視性だけをロックしても不十分だ。作業員はロケーションコードを記憶から入力できるからだ。アクションだけをロックしても不十分だ。他の顧客のデータを漏らすレポートやクエリが、結局は判断を誤らせるからだ。正しい設定は、各役割を顧客スコープに紐づけ、そのスコープでロケーションピッカー、タスクプール、あらゆるレポートをフィルタリングする。顧客をまたぐ操作は、表示されてからエラーを出すのではなく、そもそも表示されてはならない。
漏れ3：誰もロックダウンしない伝票ステータス
3つ目の漏れは伝票の中にある。2025年6月、中国北部の自動車部品倉庫には長年の欠陥があった。承認済みの出庫伝票を編集のために差し戻し、明細を変更し、新たな承認なしにピッキング用にリリースできてしまったのだ。承認がカバーしていたのはバージョン1である。実際に出荷されたものを誰も承認していなかった。
損害は具体的だった。承認後に86行の出庫伝票が編集された。3行の数量が増やされ、倉庫は編集後の数量をピッキングし、顧客は注文より多く受け取った。元の注文との照合は失敗し、監査ログには編集者、ピッカー、承認者がすべて区別のない「倉庫作業員」グループにまとまって表示された。責任の所在を再構築することは不可能だった。
伝票権限は信頼ではなくステータスマシンで強制しなければならない。伝票タイプごとに状態――下書き、承認済み、リリース済み、出荷済み――を対応付け、各状態でどのフィールドを変更できるかを正確に定義する。状態が変われば、編集可能フィールドは即座に締まる。重要フィールドが変われば、伝票は承認待ちに差し戻される。そのルールは運用マニュアルではなくシステム設定に属する。人はマニュアルを忘れる。システムは忘れない。
WMS権限設定ミスの本番開始夜チェックリスト
これは私が本番開始の夜に毎回実行するチェックリストであり、すべて緑になるまで承認しない。
- すべての役割について権限リスト全体をエクスポートする。各役割を「できること／決してしてはならないこと」リストと照合し、在庫調整、伝票の無効化、マスターデータ編集に特に注意する。
- テスト用ピッカーとしてログインする。在庫数量を1件調整し、伝票を1件無効化し、他の顧客のロケーションを開こうとする。3つの試みすべてがブロックされなければならない。1件でも成功すれば、それが漏れである。
- 顧客をまたぐエラーをシミュレーションする。ブランドAのテストアカウントにブランドBのロケーションコードをスキャンさせる。システムはそれを拒否するか、そのロケーションをそもそも表示してはならない。
- 編集された承認をシミュレーションする。承認済み伝票の重要フィールドを1件変更し、ステータスが承認待ちに差し戻されること、そして編集者と承認者が同一アカウントになれないことを確認する。
- 承認チェーンをチェックする。すべての調整・無効化タイプについて、承認者リストはその取引を入力した人物を除外しなければならない。緊急オーバーライドでも監査証跡を残さなければならない。
- レポート権限をチェックする。1顧客に限定された役割が、レポートを通じて他の顧客のデータをエクスポートできてはならない。
直感に反する部分はここだ。権限を与えすぎることは、与えなさすぎることより危険である。与えなさすぎれば大きく失敗する――作業員は初日にエラーにぶつかり、ギャップは修正される。与えすぎれば静かに失敗する。作業員はスムーズに働き、エラーは静かに蓄積し、在庫実査や顧客からのクレームで問題が表面化する頃には、設定一つではなく何か月分もの壊れたデータを修復していることになる。
本番開始チームへのもう一つの警告：権限設定は一度きりの作業ではない。新しい顧客、新しいゾーン、新しい職務の役割のたびに、同じチェックリストを回すべきである。ほとんどの倉庫は、権限を一度の大きなミスで壊すのではない。「一時的にこれだけ追加して」という小さな便宜の積み重ねで壊し、誰もそれを取り消さない。3か月後には、なぜそのアクセスが存在するのか誰も覚えていない。
その静かな失敗パターンこそ、WMSの権限設定ミスに一度きりのレビューではなくチェックリストが必要な理由である。システムは決して文句を言わないのだから、チェックリストが代わりに文句を言わなければならない。
権限を正しく設定すれば、システムは真実を語る。間違えれば、毎日、完全な自信を持ってエラーを記録し続けるだろう。
Lin Xiao（WMS導入コンサルタント）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
