ホーム > ライブラリー > Teradata Insight > 分類コードの考え方とその実践 > 「第7回」手順1：コード体系の設計（その1）
分類コードの考え方とその実践
岡本 正昭 （おかもと まさあき）
流通ソリューション事業部
エグゼクティブ・コンサルタント
「第7回」手順1：コード体系の設計（その1）
今回は、手順 1. コード体系の設計 に関する解説の「その1」である。「その1」は「コード体系設計のポイント」で、「その2」（次回掲載）はコード体系設計の具体例として、百貨店の場合を取り上げてさらに細かくポイントを指摘する。
先ずは図1 を見てほしい。
コード体系とビジネス方針
例えば GMS や百貨店といった小売業態内で、各社にコード体系の共通点が見られることは、連載「第5回」小売業の業態とコード体系で述べた。しかし、最終的には各社各様にビジネスの方針が存在し、組織や業務規定も各社各様であるから、コード体系は自社のビジネス方針に、その時点で最適なものである必要がある。その結果、コード体系には独自性が生まれ、更に言えば、その独自の部分を良く見ると、逆にその企業のビジネス方針が読み取れるものとなる。
利益管理を充実させたいと思う企業は、原価率をコード体系上に組み込むかもしれないし、売場の運営管理の充実を考える企業では、「ブロック」をコード体系に入れる可能性がある。単品管理をきちんとしようとする企業では、「単品コード」やその直上位の「スタイル番号」をコード体系に当然組み入れる。
コード体系設計のために…
（1）これからの経営に必要な情報の見通しを持つ。
経営者はコード体系の設計者には、大げさに言うと、経営陣の考えている明日のビジネス方針を伝え、将来必要となる情報を考えさせる必要がある。
例えば、
「3年後にはグループ各社を統合的にコントロールできるようにするのだ」
「各店のブランドは共通的に見られないといけない」
「個別原価法的に正確な売買益を見たい」
などといった、経営者の意志を伝えないといけない。
（2）営業面、マーチャンダイジング面、マーケティング面で仕事上重要な判断業務を考える。
経営陣の考えの吸収ができたら、次には現場レベルでの判断業務を検討することになる。ただし、これも現在の業務をベースにするのではなく、明日の業務を前提にする。各現場は、その役割（ロール）に応じて必要とされる判断業務を持つはずである。
そしてその判断業務のためには次の情報 3要素を押さえておく必要がある。
「キーとなる分類」
「キーとなる情報サイクル」
「キーとなる情報項目」
「キーとなる分類」
判断業務では、必ずある範囲の中で情報を見て、判断して、実行して、結果検証する。この範囲がまさに分類コードで規定される。つまり、キーとなる分類をコード体系で設計する際には取り込んでおかないといけない。例えば、品揃え計画という判断業務がブランド別でも行われ、商品分類別でも行われるのなら、「ブランド」や「クラス」が必要となる。また、品切れ防止という判断業務をしたいのなら「単品コード」が必要となる。
当然ながら、判断業務に使いもしない分類コードを組み込む必要はない。
「キーとなる情報サイクル」
次には、その情報は月次で欲しいのか、週次で欲しいのか、日次で欲しいのか、即時欲しいのか…である。この中でも特に週次の場合、何曜日で切るのかも含め検討しないといけない。この情報サイクルは一般的に、情報の有り方を検討する上で極めて重要なポイントである。やたらに短いサイクルで情報を出力し、無駄なコストと無駄な時間を消費しないように設計しないといけないし、一方で、必要なタイミングで必要な括りのものが手に入らないと仕事にならない。
「キーとなる情報項目」
最後に決めないといけないのは、情報項目である。売上金額、売上数量、粗利額、粗利率、回転率、在庫日数、在庫金額、在庫点数……これらの本年実績、前年実績、予算、計画、予測売上…。
コンピュータ化された当初は、考えられる多くの項目を横に並べた時代があったが、今や KPI（キー・パフーマンス・インジケータ）、つまり重要な実績指標に限定すべきだと、考え方が変わってきた。つまり出来るだけ少ない項目で、出来るだけ判断業務に密着した項目で情報出力すべきだとなっている。もちろん、補助項目も出力されるが、本物はどれか…をはっきりさせておかないといけない。
（3）コードグループの適切な「定義」と「呼び名」を考える。
- 「デプト」とは何か、「ライン」とは何かを言葉で定義することは重要である。新入社員にもわかる形で定義しようとする過程で、従来なんとなく使ってきた言葉に問題が見つかるかもしれない。
- 例えば「品番」のように百貨店では売場や売価還元単位を示すが、チェーンストアでは単品やスタイル番号を示す用語は、特に定義の明確化が必要である。
- 呼び名は軽視されがちであるが、その呼び名を見ただけで内容が想像できれば、コードの運用がやりやすくなる。例えば、百貨店で「品番とは売場のことで、元来は品別番号から来ている…」と説明するくらいなら、はじめから「品番」でなく「売場」と呼んだほうが良い。「品番」と呼ぶと商品の番号と誤解してしまうかもしれない。
（4）他社事例にこだわらない。自分で考える。
- コード体系全体はあくまでも自社で考え、作り出すものである。設計時には他社事例を参考にすることもあろうが、それは他社の事例をいくつか見ていると、今の流れ、今後の流れなど、本質的なコードに関する知識を得ることが出来るという期待があるからである。
- 往々にしてあるケースは、A社の「クラス」と B社の「クラス」と自社の「クラス」が実は三者三様の別の意味で使われているといったようなことである。自分の知った名称である場合には、特に当該事例企業の使い方に注意する必要がある。
