第141回 設計部門BOM改善コンサルの現場から～その70～開発・試作専用品目コード体系という考え方 ～品目コード体系の「無駄遣い」を防ぐために～

有限資源となった品目コード体系を無駄遣いしないために

品目コード体系の「無駄遣い」とは、どのような時に発生するのでしょうか？

「設計部門を二階建てにする」というコンセプトは何度も述べていますが、今回のコラムの主旨である、無駄遣いの発生源を認識するために下図を添付します。

品目コード体系の無駄遣いの原因は、2階からアウトプットされる設計成果物にあるのです。ここを「例外出図」と呼んでいます。私はこの部分の設計成果物は、あえてBOMとしての体裁を整えての出図は難しいと考えています。

特に試作開発、開発個別設計の場合、できるだけ流用化設計は試みるものの、限られた設計時間で「やってみなければ分からない」というリスクを抱えて、多くの新規の自社設計部品、購入部品、ソフトウェア（モジュール）が発生します。

当然、これらは品目コードを新たに消費することになります。手配表（買い物リスト）にせよ、五月雨出図にせよ、ドンドン新規コードが発行されるわけです。

さらに組立ステージになれば、不具合解消のための設変（設計変更）が追われるように繰り返され、新規コードが消費されていきます。このこと自体は責められるべきではないのですが（新規開発チャレンジ）、残念ながら、新規に採番されたコードが最終的にどの程度「生き残るか？」ということなのです。

「いずれの新品目コードも開発・試作完成まで分かりません」というのが本音でしょう。それはそうでしょう、やったことのない新たなチャレンジをしているわけですから……。

結果、「ボツった」部品の数だけ品目コードが「欠番」となるわけです。この欠番数が年間、数十点であれば無視もできますが、数百～数万となれば何らかの方策を考える必要があります。

開発・試作専用品目コード体系

考え方として、生き残るか否か分からない品目コードに対して、「使い捨て品目コード」というコンセプトの導入です。正規品目コードは使わずに開発・試作専用品目コード体系を設定するというやり方です。

前回のコラムで、保守事業を支えるための品目コード体系の話をしましたが、同様に

に対して、以下のコード体系を新設します。

ここには、自社設計や購入品という仕分けは存在しません。モノとして存在する全ての総称として付番されます。

特徴としては年度（西暦）が畳み込まれている点です。例えば、「3年経過したら全て消去する」というルールを作っておけば、「ごみコード」が蓄積されることもありません。ただし、そのためには大変重要な設計ルールを必要とします。

上図にもありますが、
「試作完成した時に、最終形設計成果物を必ず正規品目コード体系によってBOM構築する」
ということです。

「やれやれ何とか開発・試作品は完成した！」
「ご苦労さまでした」と言いたいのですが、その達成感に酔いしれている暇はなく、買い物リスト、緊急手配リスト、メカ系・エレキ系の赤修正図面、パッチだらけのソフトウェア等々、全てに開発・試作専用品目コードが付番されているわけで、それらを正規品目コードに置換して「最終完成品と一致したBOM構築」を完成させる必要があるのです。

設計者として「なんだか仕事が増える感じだな？」という声も聞こえてきそうですが、これを実行しないと「同じものを2度作れる製造業にはなれません」と申し上げています。

設計者が繁忙にかまけて、「そのうち設変しよう」と放置した結果、開発・試作製品の再受注があると生産現場が前回同様、いや、それ以上大混乱することになります。結果、開発・試作時に発生した経費の上塗りをすることになり、経営的視点から見ても無駄な経費を積み上げてしまいます。

その意味で、

は必須なのです。何より「同じものが2度作れる製造業になれる」のですから。

これら設計部門の2階における設計ルールが確立・理解されれば、正規品目コードの無駄遣いを防ぐための「開発・試作専用コード体系」がうまく機能することになります。

以上

次回は9月1日（金）の更新予定です。