ホーム > ライブラリー > Teradata Insight > 分類コードの考え方とその実践 > 「最終回」分類コードの周辺課題

分類コードの考え方とその実践

「最終回」分類コードの周辺課題

いよいよ連載の最終回である。前回に引き続き、分類コードの周辺課題をいくつか取り上げる。同一商品複数売場、コードマスター管理、標準コード、論理データモデルの4テーマである。

同一商品複数売場

百貨店や GMS のように、広い売場面積で多くの売場から構成されている店舗では、同じ単品が複数の売場で扱われているケースがある。例えば、百貨店ではパナソニックの単三乾電池が玩具売場、文具売場、家電売場など複数売場に置かれている。また、GMS では 1F食品売場に置かれたペットフードのある単品が、2F のペット・コーナーにも置かれている。かつての商品をベースにした売場展開から、ライフスタイル的売場作りへと変わってくるのは時代の趨勢であるから、今後ますます同一商品複数売場という傾向は強まると思われる。このように同じ商品が複数売場にあるときには、JANソースマークコードから自社の上位コードをヒモ付けることが困難になる。単三乾電池は玩具売場なら玩具のセールスマネジャーの成績になるし、文具売場なら文具のセールスマネジャーの成績にならねばならない。どの売場で売れても全て家電のセールスマネジャーの成績に計上されてしまうのでは困る。ということで、この同一商品複数売場への運用やシステムでの対応が必要となってくる。

よく、フロアコードや POSターミナルの番号で区別できるのではないか、と言われることがあるが、現実問題としては例えば催事場で文具と玩具が並んでいることもあり、これでは解決しない。筆者は特に百貨店向けに対応策 5案ほどを用意して、かつて検討用に使っていたことがある。この場合も 5つの案の中にスマートな解決策があるわけではなく、どの案も苦労が伴う。百貨店・GMS ともに使える解決策はメインの売場以外では、JANソースマークに代えてインストアマーキングで JANタイプのコードを上貼りすることである。しかし、この案もどこをメイン売場にするかまず誰かが判断しないといけないが…といった点から検討しないといけない。

コードマスター管理…特にマスター削除

当然のことながら、一般的にコードはコンピュータ上で管理される。コンピュータ内の各種コードマスターである。このコードマスターに一件ずつを初期登録し、後日必要な修正をかけて、最終的には使用終了し削除する。ここで大事なのは誰がその判断をし、誰が登録操作するか？を明確にしておくことである。つまり、コード管理者と登録オペレーターの明確化である。意外にこのコード管理者を明確に決めていないケースが多い。その結果、NO と言う人がいないので、どんどんコードが増えていってしまう。そのうち、本来の使い方でない使い方をされたコードも増えていってしまう。さらに都合の悪いことに、コードの使用が終了し、もう削除して良い頃になっても誰もその決断を下さないので、どんどんコードが増えていってしまう。しまいにはコードの空きが足りなくなって、またもや本来的でない使い方をしてしまうという悪循環に陥っていく。

通常、コード登録時には使用終了日を入力するのであるが、それさえも実際には 99/12/31 などと無期限的入力をしてしまう。一方で、気軽にコードを消すのも問題である。売上がたたなくなって、在庫が無くなっても、明日返品があるかもしれないので、消してしまうと困ることになる。

色々な常識を働かせた上で、不正なコード使用に NO と言える、また削除の判断を下せるコード管理者は不可欠なのである。

標準コード

色々な業界で標準コードといわれるものが存在する。実際に小売業でコードを設計する際にはこの標準コードを採用すべきは採用し、自社コードを採用すべきものは自社でコード管理しないといけない。例えば、同一商品複数売場のような例外を除き、JANソースマークコードや取引先口座はなるべく標準そのままを使うべきである。こうした対外的なコミュニケーションのキーとなる部分は、なるべく標準に準拠するのが合理的である。一方で自社の中を管理し、また自社独特の方針のあらわれである「売場」コードや「ブロック」コードは自社で管理すべきである。その中でも、PB（プライベートブランド）を含んだ「ブランド」コードは自社／自グループ内で標準化しないといけない。「商品分類」コードについての私のお勧めは、標準を極少しだけ参考にして、大部分はライフスタイル的配慮に基き自社用に考えることである。

論理データモデル

ビジネスの構造化と、その構造のシステム具体化への橋渡しをするものに論理データモデル（LDM：Logical Data Model）というものがある。ビジネスと IT の橋渡しともいえるものである。LDMの全体体系図はデータやマスターを論理的にまとめ上げたもので、コード体系の相互関係を整理し明示したものと密接な関係にある。LDMは、当該企業のビジネスを熟知している者が見ればビジネスの仕組みを構造化したものとして見えるので、システムに詳しくなくとも、「なるほど、当社のビジネスはこういう構造になっているのか…」とわかるものである。一方、LDMは IT面ではデータウェアハウス構築の原点となり、それに続く物理データモデルのベースともなるものである。つまり企業 IT化のバイブルとなるものである。これからは、ビジネスの専門家とIT の専門家が、LDM を共同作成することが、その企業の良き将来のための欠かせない作業となる。

まとめ

連載の最後にあたり、分類コードの重要性を以下に再度レビューしたい。

次回からは新しい連載を予定しているが、内容は「1回目を、乞うご期待…」である。

ページの先頭に戻る

Teradata Corporation　│　サイトマップ　│　プライバシー　│　リーガル