「A001」と「000001」が同じ商品だと、誰が保証するのか？
—物流マスタの統合と維持
・マスタを整備した後に、なぜズレが再発するのか
・コード変換テーブル・名寄せ・廃番改番を運用し続けるための考え方
・マスタの更新をいつ反映させるかで、過去の数字がどう変わるのか
データ基盤の構築で、多くの場合まず手をつけるのがマスタの整備です。商品コード、拠点コード、作業区分、設備の機番。システムごとにバラバラだったコードを突き合わせ、対応表を作る。ここを通過すると、第3回で扱ったIDによる関連付けが成立するようになります。
問題は、その後です。半年後、こういう報告が上がってきます。
「先月から、一部の商品が集計に出てこなくなっています」
「新しく扱い始めた商品が、まだ対応表に入っていないようです」
「あと、B拠点が独自に付けている枝番のルールが変わったみたいで、そこも合っていません」
マスタの整備は「終わった」はずでした。にもかかわらず、ズレが再発している。これは作業が不十分だったからではありません。現場が動き続けているからです。
1. マスタは、作った瞬間から古くなる
商品は追加され、廃番になり、コードが振り直されます。拠点は増え、統合され、名前が変わります。設備は入れ替わり、作業区分は見直されます。倉庫が動いている限り、マスタが指し示す対象そのものが変わり続けます。
必要なのは「整備」ではなく「更新が続く前提の設計」です。
この前提を置くかどうかで、設計が変わります。一度きりの整備作業として捉えると、対応表はExcelで作られ、担当者の手元に置かれ、更新は気づいた人が思い出したときに行われます。更新が続く前提で捉えると、誰が・いつ・どうやって更新するのかが仕組みの中に入ります。
言い換えると、マスタの品質は更新の運用の品質とほぼ同じ意味になります。
2. コード変換テーブルを「持つ」だけでは足りない
「A001」と「000001」を結びつけるのは、コード変換テーブル——システムごとのコードの対応を記録した表です。ここが基盤の中で果たす役割は大きく、加工の土台になります。
ただし、テーブルを持つこと自体は出発点です。運用として決めておくべきことがいくつかあります。
対応表が個人のファイルにある状態では、その人が不在のときに更新が止まります。基盤側で加工に使うのであれば、対応表も基盤が参照できる場所に置き、更新履歴が残る形にしておく必要があります。
もっとも危ないのは、対応表に載っていないコードのデータが黙って集計から落ちることです。集計結果は出るので、一見して問題がありません。しかし数字は実態より小さくなります。
対応先が見つからなかったデータを別に取り置き、件数を確認できるようにしておくと、「対応表の更新漏れ」が数字として見えます。
新商品の取り扱いが決まったとき、拠点が追加されたとき、対応表に行を足すのは誰なのか。業務側の担当者なのか、基盤を運用する側なのか。ここが決まっていないと、「誰かがやると思っていた」という状態になります。
どんな項目を持つべきか、コード体系をどう設計するかは、8月の「物流データ収集入門」および「物流データ収集の技術」で扱っています。本記事はその先——設計された後、それをどう維持するかに限定しています。
3. 名寄せは、一度で終わりません
コードが存在しない場合、名称で突き合わせることになります。「東京第二センター」「東京DC」「TKY-2」。「株式会社ABC」「ABC(株)」「ABC株式会社」。こうした表記の違いを同じものとしてまとめる作業が名寄せです。
名寄せの難しさは、精度そのものよりも継続性にあります。
| 起きること | 運用として決めておくこと |
|---|---|
| 新しい表記が現れる | 既知のどれとも一致しない名称が来たとき、自動で寄せるのか、人が判断するのか |
| 寄せ方を間違える | 似ているが別物（例：同名の別拠点）を誤って統合したときに、後から分離できるか |
| 過去の判断が分からなくなる | 「なぜこれを同じと判断したか」を記録に残すか |
| 担当者が変わる | 寄せ方のルールが個人の頭の中だけにない状態にできているか |
名寄せを完全に自動化しようとすると、判断が難しいケースで精度が落ちます。逆に全件を人が見るのは続きません。実務的には、自動で寄せられるものは寄せ、判断が必要なものだけを人に上げるという切り分けが現実的です。そして、人に上げる件数が増えていないかを見ておくことです。
4. 更新をいつ反映するかで、過去の数字が変わる
ここは見落とされやすく、しかし影響が大きい論点です。マスタが更新されたとき、その更新をいつの時点のデータに適用するかという問題があります。
例を挙げます。ある商品が9月1日にカテゴリAからカテゴリBへ変更されました。このとき、8月のデータを集計したらどうなるべきでしょうか。
どちらが正しいという話ではありません。用途によって答えが違います。
「先月出したレポートと、今月出した同じ期間のレポートで数字が違う」という現象の原因の一つが、この反映タイミングです。データが変わっていないのに数字が変わると、現場はその数字を信用しなくなります。どちらの見方を採るかを決め、その方針を明示しておくことが必要です。
実務上は、マスタにいつからいつまで有効だったかを持たせておくと、後から選べるようになります。これは第2回で触れた「加工後の数字だけを残すのでは足りない」という話と同じ構造です。情報を落とさずに持っておけば、後から用途に合わせられます。
5. 拠点ごとの独自運用を、どう吸収するか
複数拠点を持つ場合、マスタの維持が一段難しくなります。本社が定めたコード体系があっても、拠点の現場では独自の運用が生まれるからです。
ここでの判断は、統一するか、変換して吸収するかです。
| 方針 | 向いている場合 | コスト |
|---|---|---|
| 統一する | これから立ち上げる拠点。運用変更の合意が取れる場合 | 現場の作業手順の変更が必要。定着まで時間がかかる |
| 変換して吸収する | 既存の運用が定着していて、変えると現場の負荷が上がる場合 | 拠点ごとの変換ルールを維持し続ける必要がある |
現場の運用を尊重して変換で吸収する場合、その変換ルール自体が維持の対象になります。拠点が5つあれば、変換ルールも5つ分の更新が発生します。「変換で逃げる」ことはできますが、逃げた分の運用負荷はどこかに残ります。
取り扱う商材、庫内のレイアウト、荷主の要求が違えば、運用が違うのは自然です。問題は違いそのものではなく、違いが記録に残っていないことです。「B拠点の作業区分はこう対応する」という取り決めが明文化されていれば、比較は可能になります。
6. 廃番・改番の扱いを決めておく
マスタの維持でとくに扱いが難しいのが、廃番と改番です。
マスタから消してしまうと、過去のデータが名前を失います。「コード〇〇の商品」としか表示されなくなり、過去の分析ができません。
そのため、消すのではなく「現在は扱っていない」という状態として残すのが基本になります。同時に、現在の在庫や作業の一覧には出てこないようにする必要があります。
旧コードと新コードが同じものを指していることを、対応関係として残しておく必要があります。これがないと、改番の前後でデータが分断され、「この商品の1年間の推移」が追えなくなります。
逆に注意が必要なのは、旧コードが別のものに再利用された場合です。使わなくなったコードを新しい商品に割り当てると、過去のデータと現在のデータが同じコードで別物を指すことになります。集計上はもっとも厄介な状態です。
廃番・改番の扱いは、基盤側だけでは決められません。どのタイミングで廃番にするか、コードを再利用するかしないかは、業務側のルールです。だからこそ、基盤を作る側と業務側で取り決めておく必要があります。
7. 維持のために決めておくこと
ここまでを、運用として決めるべき項目に整理します。
| 決めること | 決まっていないと起きること |
|---|---|
| 誰が更新するか | 「誰かがやると思っていた」状態で更新が止まる |
| いつ更新するか | 新商品の取り扱い開始からしばらく、その商品が集計に出てこない |
| 対応先がないデータの扱い | 集計から黙って落ち、数字が実態より小さくなる |
| 更新をいつの時点に適用するか | 同じ期間のレポートを出し直すと数字が変わる |
| 廃番・改番のルール | 過去のデータが名前を失う。改番前後で推移が追えない |
| 拠点独自運用の変換ルール | 拠点間の比較ができない、または誤った比較になる |
| 更新漏れに気づく方法 | ズレたまま数か月が経ち、遡って直せない |
いずれも技術的に難しい項目ではありません。決めておくかどうかの問題です。そして決まっていない場合、その影響は数か月後に、数字のズレとして現れます。
まとめ：マスタの品質は、更新の運用の品質
「A001」と「000001」が同じ商品だと保証しているのは、システムではありません。対応表を更新し続ける運用です。その運用が止まれば、システムは何も知らないまま、集計から一部のデータを落とし続けます。
マスタ整備をプロジェクトとして完了させることはできます。しかし、維持を完了させることはできません。現場が動き続ける限り、マスタは追いかけ続けるものです。
だから、整備の完了ではなく更新の継続を設計する。
今回、更新漏れに「気づく方法」を決めておく必要があると述べました。実はこれ、マスタに限った話ではありません。欠損、遅延、異常値——昨日まで正しかったデータが、今日から間違っていることがあります。次回は、蓄積した後のデータ品質をどう監視し続けるのか、そして誰が異常を受け取るのかを扱います。
拠点ごとに異なるコード運用をどう吸収するか、更新をどのタイミングで反映するか、対応先のないデータをどう扱うか——分析結果の信頼性は、こうした運用の取り決めに左右されます。現状の運用を整理し、どこにズレが生まれやすいかを洗い出すところからご一緒できます。
「一度マスタを整備したが、また合わなくなってきた」という段階からでもご相談いただけます。
お問い合わせはこちら