物流よもやま話 Blog

猫も杓子もJANコード

カテゴリ: 信条

長年言い続けていることのひとつに「商品コードと商品マスターの作成規格を標準化する」というのがある。
現状なら、全部JANにしてマスターは直列型の共通仕様に準拠すればどうか、ということだ。
流通云々やらNET専売品なので、、、などの個別事情は承知している。
それでも物流が発生する可能性のある物品にはすべてJANを付与するべきだと考えている。
なぜなら、「それが一番低コストで合理的で究極の全体調和を生む」と確信しているからだ。

物流現場の業務フローは商品マスターが支配している。
したがって、支配者たる商品マスターに不備があると、そのシモベたる物流業務はまどろっこしく、ミスの危険性が高く、結局はコストまで高くなってしまう。
商品マスターは物流部門だけで規定・運用するものではなく、仕入から販売に至るまで、企業の物販には不可欠な存在である。
デジタルか否かなどは関係ない。手書きの商品台帳に記された品名と色や大きさや数も、基幹システムに収納された詳細データが記憶された商品マスターコードも、その優劣は記述論理と極限までの簡素化のバランスによって決定される。
昭和中期の商品台帳や現場台帳が現在の優れた諸台帳に遜色ないどころか、その工夫と機転に唸ること数知れず、という実例が「つくりかた」の重要性を表している。

いつの時代も、どこの国であろうと、どのような物品に、どのような機器やシステムを用いようとも、商品仕入・在庫管理・商品販売には何らかの一貫した「キー」を維持し続ける仕組と記録がなくてはならない。
なので、それが出世魚のように次々と名を変えつつ、社内や顧客を回遊するような状態は異常にもかかわらず、結論としては不可抗力だという説明がまかり通る業務運営の方法論も理解を得ることはできないはずだ。
「Aという名のS123というコード番号の商品を仕入れ、Aという名のままS123というコード番号で在庫表に載せ、Aという名でS123というコード番号記載の見積書を発行し、Aという名でS123というコード番号の商品を販売したので、Aという名のS123というコード番号の商品在庫は一個減った」
という一連の流れに異論のある方はいるだろうか?
異論がなく、「こんなことは書くまでもないことだ」とあきれ顔の方も多いと思う。
では、改めて質問を差し上げる。

「貴社の商品コードは仕入れから販売完了まで完全にユニークであり、商品マスターには仕入から販売完了までの間に一切の追加や変更、補助コードや〇〇〇専用コードなどという影武者のような存在は皆無ですね?」

私の知る限り、そんな会社は半分にも満たない。額面通りに「単一コード」で業務完結しているのは物流屋がよく使う “ オールJAN ” という品番管理とその運用が行われているか、“ オールユニーク ” で同様、の場合だけだ。
極めて簡素で単純な内容のハナシであり、誰が聞いても具体的な実物の画像や業務映像が思い浮かぶ。
なのに、なぜかそうなっていない企業が数多存在しているし、その状態で今も営業している。
珍しくもないよくある事例をなるべく簡略化して書いてみる。

仕入先の「メーカーJAN」とJANなし特注品用の「メーカー独自品番」を仕入のタイミングで自社の仮番たる「仕入用コード」に振りなおして、入荷計上時に再度変換する「商品在庫コード」に紐づけておく。
「商品在庫コード」には3種類あり、ひとつは国内特注品用の「自社独自のユニークコード」であり、もうひとつは輸入商品に付与する「自社JANコード」、そして国産既製品用の「仕入先JANコード」である。
コード発行付与については、在庫管理ソフトが自動生成するので、新しい「仕入用コード」を打ち込んでやれば、ソフトが勝手に新しい「商品在庫コード」を発行して、在庫計上する。
「仕入用コード」にはユニークとJANを区分する記号が含まれており、在庫管理ソフトはその記号を識別することで「自社独自のユニークコード」と「自社JANコード」「仕入先JANコード」の生成判断を行っている。
商品部や物流部はこの「商品在庫コード」を共通語として社内連絡を行うが、商品部が仕入先と会話する際には相手が常用している「仕入先JAN」やJANなし特注品の「メーカ独自品番」を用いる。
さらに営業部では「顧客コード」に紐づけて、見積作成時に商品原価と顧客への販売価格から算出された販売粗利が自動表示される内部システムを使用するため、「顧客コード」と「商品在庫コード」の双方に紐づいた「販売管理コード」を毎度自動生成して使用している。
販売のたびに新しいユニークコードを発行する理由は、営業上のミス、たとえば売価変更や販売可能ロットの変動などの情報対応の属人化を防ぐためである。
また、顧客特注品や特別価格、取り置き処理による実在庫引当後の仮伝処理、交換による赤黒の際の、通常コード外し処理など、営業マターでの特別販売コードは数種類存在し、中分類以下の数は3桁に達する。
営業が使用している売上伝票の販売コードによっては、それが倉庫内のどの商品であるかの判別が当該品の仕入担当者と販売担当者でなければ不可能なケースも珍しくない。
社内での共通語は「商品在庫コード」であるはずだが、営業部では顧客向けカタログに掲載された商品名と顧客発注用品番(顧客コードと紐づけると、売価と粗利率が見積書の内部者用画面に表示される)で日常業務を行っているため、物流部や商品部とのやり取りの際には通訳とも呼べる「品番コード早見表」が必需品である。
現在、その早見表を自動変換できるようにシステム加工できないかを検討中だ。

打つのに一苦労である。
実際にはこれより数倍多いローカルルールが社内に存在していることなど珍しくもない。
会社によっては、さらに商品在庫データと財務データを「最新の管理ソフト」によって連動させるために、在庫データと財務データの橋渡しとなる「相互紐づけ専用変換コード」を作成して、そいつがソフト内で働いている、表コードと裏コード、みたいな呼び方をすることが多いのだが、後付けや無理やり加工の痕跡としていびつな奇形業務が存えている。

声を上げる者はいないのだろうか?
と思うのは私だけではないはずだ。
事実各社の様々な部門から不備や煩雑の解消を求める声は後を絶たないのだとか。
しかし、すぐには解決しない。
莫大な金額をかけて導入し、毎年メンテナンスやオプション加工費に相当の金額を投じてきた基幹システムをおいそれとは改廃できないのだ。
安価なパソコンでもできそうな業務管理が、億の単位のものすごいシステムではなかなか安定しない。
予算組だけでも実現が遠いのに、さらに業務を止める必要まで。
「使えないわけではないので、当面はこのままで」という結論に落ち着く。
というのがほとんどの企業内事情である。

そこで提案なのだが、物流が発生するすべての企業はJANを使用したらどうだろうか。
必要の度合いに差があることは承知しているが、製造物や輸入品など、全ての企業が取扱い品にJANを付せば、仕入から販売完了までの識別コードは共通規格の「完全ユニーク」となる。
北海道から沖縄までどころか、「商品コード」が存在する世界中の国でその物品は完全に「ユニーク」となり、唯一無二の存在としてあらゆる場面や場所で識別ができる。もちろん物流業務にも使用できる。

JAN登録のコストやシールや下げ札等の発行・取付コストはかかるかもしれないが、年額に換算すればためらうほどの金額ではないはずだ。
年に何回も転んでケガして、弁償したり、二度手間、三度手間かけたり、大人数の上に少なくない残業代まで払って煩雑で面倒な業務をこなしたり、、、が軽減もしくは解消できるかもしれないのだから、決して高い買い物ではないはずだと確信している。
費用に関しては、流通システム開発センターWEBに詳細があるので、一度ご参照あれ。

もしモノを扱う全社が、それぞれの商材にJANコードを付与したとする。
まず第一に現在世の中に存在する「商品管理にかかわるすべてのソフト」が簡略化されて、単純明快な操作手順となる。
第二に、全社の商材は誕生から消費まで終生を「固有名」で過ごすことができる。
第三に、デジタル化とそのメリット享受の最短で最安なルートをたどることができる。

仕入・営業・財務の業務をもれなく把握していないゆえ、それらへの言及は最小限に止めるが、物流に関して言えば業務フロー設計の基本となる前提条件のひとつが完全に満たされる。
倉庫の入口から出口まで「同じ名前」で存在し、到着と出発も同様の同名で告知される。
入荷情報と在庫情報と出荷指示と出荷明細に記載されているコードが同一。
これさえあれば、業務フロー設計の半分以上は終わったも同然である。
「ミスしたくてもできない」業務フローとOJTが生み出せることを約束できる。
さらに並列化している業務フローを直列化して、現場を簡素化できる。
図面やチャートでの説明が必要ないほど単純なハナシだと思う。

蛇足かもしれないが、すでにJANコードがあるから推奨しているだけで、一定以上の情報を持つことが可能な統一コードの規格ならなんでもよい。
今現在の目先足下では無用で不要かもしれないが、まわりまわって自社にも恩恵が巡る。
問題はその広報と啓発だが、どこか影響力のある組織が旗振りしてくれないものだろうか。
拙文で訴えても微動だにしない世間の動きであることはあたりまえ。
読者諸氏のご理解とご賛同を願う次第だ。

著者プロフィール

永田利紀(ながたとしき)
大阪 泉州育ち。
1988年慶應義塾大学卒業
企業の物流業務改善、物流業務研修、セミナー講師などの実績多数。

最近の記事

アーカイブ

カテゴリ

お問い合わせ Contact

ご相談・ご質問等ございましたら、
お気軽にお問い合わせください。

お問い合わせフォーム