ゴーライブから8か月後、品目マスタには1,700件以上の重複した説明文が溜まり、ピッキング精度は99.6%から97.1%に低下していた。昨年、Rancho Cucamongaにある3PL倉庫のオーナーがこの数字を私の前に突き出し、「WMSの選定を間違えたのか？」と尋ねてきた。
一緒にシステムログを調べた。システムに問題はなかった。問題はデータだった。あるSKUは3回も作成されていた。営業が受注を早く入れるために「Bluetooth earbuds - black」と登録し、カスタマーサービスがバックオーダーの処理に追われて「BT earbud blk」として再作成し、受領リーダーが急いでいたために3つ目のコードを作ってしまった。3人、3つの説明文、1つの物理的な商品。ピッカーたちはハンディターミナルを持ってロケーションの前に立ち、画面に表示された3つの名前を見て、どれを取ればいいのか分からなくなっていた。
ゴーライブ時点ではデータはクリーンだった。プロジェクトチームは2か月かけてデータを洗浄し、導入コンサルタントが全SKUレコードをレビューした。しかし6か月後には、誰も所有者ではなくなっていた。ITは「マスタデータは事業側の仕事」と言い、オペレーションは「システムはITの仕事」と言った。結果、誰の仕事でもなくなった。データは毎週少しずつ劣化し、システムは月を追うごとに使いにくくなり、オーナーは金を無駄にしたのではないかと思い始めた。
金は無駄ではなかった。足りなかったのは「役割」だった。
まずルールから：誰が作成し、誰が編集し、誰が入るのか
中小規模の倉庫の多くには、マスタデータの管理者が存在しない。SKU作成権限は十数人に分散している。営業は受注を早く入れるためにSKUを作り、カスタマーサービスは補充を急がせるために作り、受領リーダーは頼むより早いから作る。権限が広く分散すればするほど、誰も責任を感じなくなる。
私のアドバイスは率直だ。作成権限を2〜3人に絞り、そのうち1人をデータスチュワードに任命すること。最良の候補者は通常、WMSのスーパーユーザー、あるいは第二の帽子をかぶった受領スーパーバイザーだ。彼は一日中現物を触っており、説明文が間違っていると最初にピッカーたちから怒られるのは彼だ。だから正しくやるための自然な動機がある。
3つのことを書き出して壁に貼る。新しいSKUを作成できるのは誰か。ロケーション属性やロットルールの変更を承認するのは誰か。過去の汚いデータを誰が、どのスケジュールで掃除するのか。紙に書くこと。口約束の賞味期限は約3か月だ。
よく聞かれる。「うちは30人の小さな会社だが、専任の役割はやりすぎではないか？」フルタイムである必要はない。二足のわらじで構わない。ただし「二足のわらじ」は「気が向いたときに」ではいけない。職務記述書に書かれていなければならず、月半日をそのために確保しなければならない。職務記述書にない仕事は実行されない。
門番のいないスチュワードは勘に頼るしかない。だから受入チェックリストも必要だ。私たちのリストはこうだ。SKUコードはルールで生成し、「仮」として手入力しない。説明文にはブランド、仕様、単位を必ず含める。「青いやつ」「大きな箱」は不可。縦・横・高さ・重量は必須で、実測の秤から取ること。サプライヤー提供のカートン寸法は10回に9回間違っているからだ。バーコードルールは固定で、1SKUに1コード、新しい包装は新しいコード。ABC分類は最初に仮判定し、3か月の流動データで見直す。ロットと有効期限の要件は初日に決める。後から追加するのが最も痛い手戻りになるからだ。保管戦略も受入時に決める。パレットフル保管かピースピックか。それがどのゾーンに置くかを決める。
チェックリストは細かすぎるように見える。実際には5分ほどしか追加されない。だが考えてみてほしい。1つの悪いSKUが受領・保管・ピッキング・循環棚卸という4つの下流工程を汚染する。後から直すコストは、受入時に正しくやるコストの100倍になる。難しい計算ではない。
最も制御が難しいのは「仮SKU」だ。繁忙期に突入し、営業が特急受注を取り、SKUがまだ存在せず、トラックはすでにドアの前にいる。私のルールはこうだ。仮コードは許可するが、30日以内に本物のSKUに変換しなければならず、期限切れにはシステムがリマインドする。変換時には、欠けているフィールドをすべて一度に埋める。仮は構わない。腐るのはダメだ。
第一の防御線：システムにブロックさせる
人は怠ける。だから第一の防御線はシステムに担わせる。
WMSで検証ルールをロックする。必須フィールドは空のまま保存できない。説明文フィールドには類似度チェックを付け、重複に近いものに警告を出す。バーコードはデータベース全体で一意で、重複はその場で却下。重量や寸法がゼロ、あるいは明らかにおかしい値はブロックする。これらの設定は小さく見える。低レベルのエラーの約80%を、発生する前に止める。
もう一歩踏み込んだ手がある。SKUの作成と「販売可能」を分離することだ。新しく作成されたSKUはデフォルトで「レビュー待ち」となり、データスチュワードの承認後に初めて有効になる。営業がどれほど急いでいても、この5分は待つ。この5分は、データ品質と事業スピードのトレードオフだ。私の結論は、この5分には価値があるということだ。腐ったSKUを野に放てば、下流にトラブルしか生まないのだから。
第二の防御線：人が抜き打ちチェックする
システムは悪いフォーマットをブロックできる。しかし正しいフォーマットに入った間違った内容——仕様が間違った完全な説明文——はブロックできない。それには人が必要だ。
方法はサンプリングで、全数監査ではない。全数監査は現実的でない。毎週、新規作成または変更されたSKUを20件抜き出し、スチュワードが現物と照合してチェックする。説明文は正しいか、寸法は正確か、バーコードは読み取れるか。間違いがあれば、誰が作成したかを追跡し、その場で修正する。
さらに月次のロケーション属性サンプリングを加える。ロケーション属性は最も早く劣化する。パレットフル専用とされたロケーションが6か月後にはバラ物で埋め尽くされる。「繁忙期立入禁止」のロケーションは、先月雇われたフォークリフト運転手には何の意味も持たない。50か所をサンプリングし、現実と合わないものを直し、なぜそうなったかを書き留める。最初から設定が間違っていたのか、後から誰かが誤用したのか。この2つは、対策も異なる別の問題だ。
サンプリングの危険は形骸化だ。私の荒っぽい対策はこうだ。サンプリングログには、見つかった問題数を必ず記録する。3か月連続で「問題ゼロ」というのは、サンプリング自体が壊れているということだ。実際の倉庫で問題ゼロというのは、まず起こらない。
第三の防御線：給与に結びつける
最初の2つの防御線が機能していて、それでもデータが劣化するなら、理由はただ1つだ。悪いデータを作っている人が、その痛みを感じていない。
だから第三の防御線は説明責任だ。マスタデータ精度を部門KPIに入れる。あるいはもっと直接的に、マスタデータの問題に起因するピッキングエラーや誤出荷を、データを作成した人に帰属させる。罰金ではない。業績評価に影響するエラー記録だ。誰かの生活に結びつくまでは、データ品質は優先順位リストを上がらない。
スチュワードにもニンジンが必要だ。彼は月半日かけてデータを掃除し、誰も気づかず、年末の評価は「何もしなかった場合」と同じ——次はもうやらないだろう。私は彼のために「マスタデータ精度」を独立したボーナス項目にしている。データがきれいなほど、数字が大きい。ニンジンは大きくなくていい。存在することが大事だ。
3つの防御線を合わせる。システムが80%をブロックし、人のサンプリングが漏れを拾い、説明責任が動機を正す。単独で銀の弾丸になるものはない。組み合わせれば機能する。
明日の朝、2つのことをやろう。まず、WMSのSKU作成権限を十数人から2〜3人に絞る。次に、受入チェックリストを印刷して、受領事務所の壁に貼る。この2つだけ。まずはそれ以外は何もしない。1か月後にピッキングエラー率を確認する。数字が物語るだろう。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
