« 「売上伝票」を問い直す | トップページ | 売上計上基準の設計と実装 »

2013.05.25

「品番変換」のモデリング

 顧客からの注文を受け取ったときの課題のひとつが、客先品番を当社品番に置き換えることだ。簡単そうに思えるかもしれないが、意外とややこしい。問題の様相を説明するとともに、「フィーチャ・オプション」を用いた対処法を紹介しよう。

 顧客側の品目マスターに、品番"A001"として"20%酢酸溶液500mlボトル入り"が定義されていたとする。顧客がこの商品を当社に注文したとすれば、注文書やEDIデータにはそれらが客先品番やその品名として記載され、当社側の品番(当社品番)はふつうは示されない。ゆえに、客先品番に対応する当社品番を決定するのはこちら側の仕事である。

 ところが、そもそも客先品番"A001"に対応する当社品番が1個だけとは限らない。いろいろなケースがあるが、まずは当社品番が1個だけ対応するケースを見よう(i)。

(i)1客先品番→1当社品番
20130517_1

 どんな客先品番にもつねに当社品番が1個だけ対応するのであれば、何も難しいところはない。つぎのような品番変換テーブル(契約販売品)を用意すればよい(*1)。1件の当社品番に複数件の客先品番が対応したとしても、このモデルで対処できる。なぜならこの場合の変換は、基本的に「客先品番から当社品番を特定する」という一方向の問題だからだ。

(モデル1)
[品目]品番, 品名,...
+ RX123456 20%酢酸溶液500ml(ボトル)

└─…
   [契約販売品]顧客ID,客先品番,品番
┌─∈      002567 A001  RX123456


[顧客]顧客ID,顧客名,...
   002567 大日本帝国産業株式会社

 ただしこれはラッキーな例であって、現実はもっとややこしい。しばしば、客先品番1件に対応する当社品番が1件以上存在する(ii)。

(ii)1客先品番→1..n当社品番
20130517_2

 なぜこういうことになるかというと「興味の対象となる商品概念の粒度」が企業毎に異なるためだ(*2)。それぞれの企業はそれぞれの業態に応じた「商品観」を持っている。ちなみにこの問題は、JANコード等のユニバーサルな品番体系を導入するだけでは解決しない。企業間で品番のコード体系を合わせることと、両者の商品概念を一致させることとは別の話だからだ。

 話を戻そう。(ii)の場合、品番変換テーブルはモデル2のようになる。こうしておけば、受注入力時に選択可能な当社品番をリスト表示したり、やろうと思えば在庫状況にしたがって当社品番を動的に対応させるといった芸当もできる。

(モデル2)
[品目]品番, 品名,...
+ RX123456 20%酢酸溶液500ml(ボトル)

└─∈
   [契約販売品]顧客ID,客先品番,品番
┌─∈      002567 A001  RX12345S
|        002567 A001  RX12345T
|        002567 A001  RX12345U

[顧客]顧客ID,顧客名,...
   002567 大日本帝国産業株式会社

 とくに問題もなさそうだが、実際に使ってみれば、データのセットアップにひどく手間がかかることに気づくはずだ。とくに顧客が多いうえに1顧客がさまざまな品番を注文する場合、客先品番と社内品番の組み合わせは膨大で、品番変換テーブルのメンテナンス作業はほとんど苦行である。

 さて、複数件対応するのはまだマシで、途方に暮れることに当社品番が1件も対応しないケースもある(iii)。

(iii)1客先品番→0..n当社品番
20130517_3

 この場合の当社品番"RX234567/20%酢酸溶液"は、タンクにロットやバッチ(釜)の単位で在庫されていると考えられる。つまり、顧客が言う"20%酢酸溶液500mlボトル入り"に対応する品目概念は、こちら側には存在しない。それはせいぜい出荷時の「荷姿(にすがた)の違い」としてしか現れない。

 以上の問題に対処するために、何度か取り上げた「フィーチャ・オプション」の考え方を利用できる。まず(iii)の"20%酢酸溶液"の製品概念に対して、次のようなフィーチャ・オプションの体系を添わせてみる。

順序 FEATURE   桁数 OPTION 摘要
――――――――――――――――――――――
01  小分け量    4
                 0500  500ml
                 0750  750ml
                 1000  1000ml
02  ボトルタイプ  1
                  S   S型
                  T   T型
                  U   U型

 こうしたうえで、システムに「FOコード」の概念を組み込む。たとえば、品番"RX234567"向けに、FOコード"0500S"が指定されていれば、それは"20%酢酸溶液500mlのS型ボトル入り"の商品概念を表す。それまでは「荷姿の違い」としてややインフォーマルに扱われていた商品仕様の違いが、DBレベルで定義される。

 この場合、小分け量とボトルタイプの組み合わせは9=3×3なので、9種類の仕様のバリエーションを1品番で内包できたことになる。フィーチャやオプションの数を増やせば、1品番で表せるバリエーションは等比級数的に増える。結果的に、システムが抱える品番の数を大幅に減らせる。

 品番を減らせるだけでなく、品番変換データのセットアップ作業も軽減できる。そのためには、モデル3のようにFOコードのマスキング条件(FOマスク)を使って客先品番を対応させるためのテーブルを用意すればよい。この例では「ボトルタイプ」のフィーチャが"*"でワイルドカード指定されているが、仮にボトルタイプのS型が営業上もっとも有利であるとすれば、ワイルドカード指定せずにあえてS型を指定するといった設定も可能だ。

(モデル3)
[品目]品番, 品名,...
+ RX234567 20%酢酸溶液

└─∈
   [契約販売品]品番,顧客ID,FOマスク,客先品番,検索順序(*3)
┌─∈     RX123456 002567 0500*  A001   00


[顧客]顧客ID,顧客名,...
   002567 大日本帝国産業株式会社

 これで当社品番と客先品番の対応付けがしやすくなる。品番相当の品目概念だけでなく、任意のフィーチャをマスキングすることによって得られる仮想的な品目概念を持ち込めるからだ。今でも多くのシステムが、モデル2のように素朴な品番変換テーブルの一本槍で対処している。改善のヒントとして、フィーチャ・オプションを参考にしてほしい。


*1.本来であれば、当社品番や客先品番のような「ナチュラルキー」を一次識別子に含めるやり方は不適切であるが、ここではモデルが煩雑になるのを避けるためにそのようにしてある。
*2.ここらへんの指摘は、今年3月に開催された生産管理システムの勉強会で、畏友の佐藤知一氏によってなされた。本記事をまとめたのもそれがきっかけである。
*3.同一品番・同一顧客の中でFOマスクが複数件並んだ場合の読取順序。与えられたFOコードに該当する客先品番を決定するための優先順位となる。

|

« 「売上伝票」を問い直す | トップページ | 売上計上基準の設計と実装 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「品番変換」のモデリング:

« 「売上伝票」を問い直す | トップページ | 売上計上基準の設計と実装 »