デジタル庁への提言？とは大きく出てしまい恐縮です。
しかしながら、デジタル化の最大の目的は個別最適では無く
全体最適でのデジタルの民主化が最大の目的で、その上で
各企業が独自運用では限界もあり、全体最適でのDXについて
「まちの総務」的な立場での提言には大きな意義があると信じております。
前回は「デジタル庁に期待する所」としての序論を書きました。
今回は具体的な内容について言及してみます。
企業間商取引の汎用化と中小企業版JANコード化
中小企業間に商取引の汎用化になります
それを実行するための施策としての中小企業版JANコード化です。
先ずは現状の整理からです、各種製造業（B2B）の商取引について大手企業などであればそれなりの
受発注システム等を導入して運用している状況ではありますが
地方の中小製造業などではシステム化が追い付いていない所が多々あります。
- 過去の慣習に則り、現在でも受発注は紙（FAX）で行い
- 受領した社内の事務担当が手入力で紙情報から転記作業
- 生産作業後に納品伝表（Excel等）を発行し、その後請求書（Excel等）で郵送 or FAX送付
- 一件の製品受発注に対して見かけ上の電子化情報（紙）の相互やりとり
この作業には手間はかかれど、何の生産性も無く只々人海戦術で
昔ながらの方法で以前と日々行われております。
最近では、SaaS系の受発注伝表作成などの仕組みも出て来ておりますが
まだまだ現場では限定的です。
一旦、基本に帰ります。
B2Bと言うと何故か複雑に感じますが、これをB2C、C2Cに置き換えた場合
Amazonを想像して下さい。
- 企業が自社の製品（加工品）の情報をネット上に限定公開します。
※限定公開とは相手先との関係性を重視するため - 発注側は商品の中から条件を選び、個数、サイズ等を入力して「発注」します。
- 受注側はWeb発注の「注文書」情報より、社内展開して生産を開始します。
- 生産完了後に「納品書」発行し配送、その「請求書」発行して入金で完了
こんな仕組みで良くないですか？
この様なB2Bの枠組みを超えての汎用ECの仕組みが出来たら便利では無いですか？
と、ここまでは誰でも気付く（感じる）内容かと思います。
では、何故実現していないのか？
頭の中で整理して考えて見ます。
- 相手先顧客に寄って値段（見積金額）が違う
- 製品加工の種類が多く商品登録が困難
まだまだ色々ありそうですが…相手先デジタル環境や知識など
これらは既に解決しております、多くの方は既に通販利用していますよね。
ここを基準に、上記のネガティブな要素を分解して解説します。
相手先顧客に寄って値段（見積金額）が違う
これは、Web上で全ての情報の公開の必要はありません。
B2Bの場合は、相手先が見える必要がありますのでログインでコントロールします。
許可された企業のみログイン出来、その企業との約束事項としての金額幅を持たせる事も出来ます。
（値引率などは係数で管理）
ログインで企業を管理しますので、製品購入履歴からのリピートも可能になります。
新規取引の場合なども営業が介入して金額交渉結果を反映させる事も可能になります。
B2B専用の汎用システムを活用しながらも、ログイン種別を変える事で柔軟な企業間取引も可能になります。
明確な数値までは掴んでおりませんが、通常の企業間取引（B2B）の場合は
新規よりも固定客での取引が多いのが一般的になります。
逆を返すと、先ずは8割強の固定客、固定製品取引の実績企業から導入して行くのも良いと思います。
製品加工の種類が多く商品登録が困難
実は地味にこの部分の問題点が多いのが実情です。
例えば、商品（長物）を商社から購入して、自社で加工（裁断）して販売している企業を想像して下さい。
「商品名、厚さ、幅、長さ」これら一つ取っても、莫大な商品数になります。
単純に裁断とは言っても、加工する機材の質や加工機によっても値段が変動します。
その数は幾何学的な商品数になります（と、事務担当者は主張します）
この辺が事をややこしくして、一歩汎用化が進まない部分でもあります。
しかし、一度冷静になって下さい。
顧客は何らかの商品情報を元に発注しています、その情報を持って受注しています。
と言う事は、上記の例ですと「商品名、厚さ、幅、長さ、＋α」の情報があれば金額確定しますよね。
その情報に注文数を付加するだけで、商品確定と値段も確定出来ます。
もっと言うと、お互いの会社では何らかの仕組み（システム）で製品コードなどを付けて
管理しているかもですよね。これが無いとお互いの伝表確認も出来ない訳ですから。
そうなると、ここでの課題は「共通の商品コード化」になります。
JANコード（Japanese Article Number）とは、「どの事業者の、どの商品か」を表す国際標準の商品識別
コードです。通常、バーコードリーダーで読み取れるように、バーコードによって商品パッケージに表示
されます。
スーパーなどのレジで「ピィ」とするバーコード化された情報ですね。
これは大手企業の商品に付いて、とある機関に登録を行い、世界中でユニーク（唯一）の
コードとして認識されて使用される訳です。
JANコードの標準タイプの構成は以下の様な取決めであります。
・事業者コード（9桁、10桁または7桁）
・商品アイテムコード（3桁、2桁または5桁）
・チェックデジット（1桁）
この取決めをもう少し柔軟にして、多少の桁数を増やして中小製造業の商品コードとして
あわよくば国際標準化（又は国内標準化）して運用出来れば良い訳です。
この標準化機関をデジタル庁主導で動いて頂けると良い訳です。
・各中小製造業はまず事業者コードを登録（工場別も含め）
・製品に関してはある一定の条件（規約）を作りその範囲で製品名を確定してコード申請を行います。
・その際の備考欄には製造条件（素材、厚み、長さ、幅、＋a）
・この条件は発注先のお客様が商品選択の判断材料になれば良い訳です。
・その情報が確定した段階で、発注先企業別に金額（係数込み）を登録すれば完了です。
後は、前述のB2B受発注システムに連携する流れになります。
ここでのポイントはB2B受発注システム自体の開発は特段難しくはありません。
Amazonや楽天、モノタロウなどで既に基本実績はあります。
企業間取引を行うための「コード化」をデジタル庁に期待
難しいのは、企業間取引を行うための「コード化」になります。
これは一企業や民間で行うのは片手落ちです
全体最適を行うためにも、国や国の外郭団体が舵取りをすべき内容です。
これこそがデジタル庁の手腕に期待したい内容です。
既にこの様な動きがあるのかも知れませんが…早期の実現を期待します。
これぞ「最適化DXの本丸」部分になろうかと思います。
「レッツDX」
- デジタル庁に期待する所
- 企業間商取引の汎用化と中小企業版JANコード化 ⇦今ここ
- 個別会計処理の統合化
- 個別給与計算の統合化
- 企業提出情報のDB化（紙の電子化NG）
- 番外編 SaaS情報のWebAPI連携の標準化
- 番外編 情報セキュリティ管理は独自運用では無い
次回に続く
