第133回 設計部門BOM改善コンサルの現場から～その62～ExcelによるBOM構築の限界～BOM構築の重要性は理解しているがExcel運用の限界に悩む～

ExcelでBOMを構築するとは？

BOM構築することが必要だと設計部門で認識した場合、必ず「どうやって？」ということになるでしょう。
「誰かBOM構築のトライアルをやってほしい」ということになって、白羽の矢が当たったスタッフは「では、どうやって構築するか？」に悩むこととなります。

今、存在するアプリケーションでBOM表現が最もたやすそうに見えるのがExcelです。どう考えてもWordでもパワポ（PowerPoint）でもなさそうです。もっとも、この時点でDB（データベース）の必須性に気付くケースは今回のコラムの対象になりませんが、多くの事例を眺めてみるとやはりExcelでの展開となってしまうのです。「まずは手元にあるアプリでやってみるか」という発想は、結果の共有しやすさという現実も含めて理解できます。

机上のイメージから、まずは設計部門全体で共有（閲覧）できるExcel上でのトライアルは、BOM構築の「はじめの一歩」として良いプロセスと考えています。

しかし、問題は「ではこのままExcelで運用しよう！」となってしまうことです。
ここからExcelで構築された「BOMのような」設計成果物が生産管理システムの有無に関わらず展開され、そのままExcel設計成果物が蓄積されていきます。

そのようなことを繰り返していくと「BOMを構築しているのに共有化が進まない、似て非なるユニットができている、共有してもいろいろな不具合が生じ、重ねて生産側の混乱が生じている」などなどの問題発生に悩み、おのずと全社効率も落ちていくわけです。

ExcelによるBOM構築の事例を見ると……

今まで多くの事例を見てきましたが、典型と思われる例を挙げてみたいと思います。まずはトップの行に並ぶ「項目」です。これを眺めていると上流側・下流側でどのような「やり取り」が行われているのかが見えてきます。

なぜExcelでBOM構築してはいけないのか？

結論から言えば、ExcelはDBではないからです。
2項のLV（階層）情報を使って親子関係を表現しても、その親子関係は情報として保存されません。その意味では平面的に羅列した「部品表」と何ら変わりはありません。

従ってBOMの正・逆展開などのご利益にはあずかれません。つまりBOM構築の目的が果たせないということです。

DBによって構築されたBOMはDBのテーブルに品目コードによって保存された「モノ」が製品やユニットの階層情報とともに自分の親や子の情報がそれぞれひも付けられている状態ですから、Excel上に表現されたBOMとは全く異なるわけです。

次は最新版管理ができないということです。特に複数の設計者が勝手にダウンロードして勝手に作業して上書きすることが予想され、どれが最終E-BOMなのか？ ということになります。

もう一つ、ダウンロードが際限なくできてしまうということは、似て非なるユニットが設計不具合を持ったまま増殖してしまう可能性もあります。

最後に、流用設計としてユニットを流用しようとした場合、DBであればそのユニットの親品目コードのみを引用してくれば良いのですが、Excelではユニット全体をコピペ（コピー＆ペースト）して持ってくる必要があります。部品構成の多いユニットの場合、コピペを忘れた部品やコピペ範囲がはみ出して余計な部品を構成してしまい、下流側が大混乱する事例をたくさん見ています。

BOM構築の必要性を感じ、手短なExcelというアプリでトライアルすることを否定するわけではありませんが、Excelの限界をしっかり認識して、設計成果物として本番使用する前にDBとしての仕組みである流用化・標準化設計プラットフォームの検討を進めてください。

以上

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