じつは、BOMに登録すべき品目には原則があるのだ。BOMに(いいかえればマテリアル・マスタに)登録するすべき品目とは、在庫管理の対象となるマテリアルである。つねに一貫した工程なら、途中段階の品目登録は不要である。途中段階の品目は一時的に出現しても、すぐに次工程に消費されてしまうからだ。材料dを切削→研磨した後、用途別にいろいろな表面加工で品種が別れたりする場合には、研磨後の中間部品Dをいったん保管したくなるだろう。中間部品DをBOMに登録するべきである。した製造工程上の都合は、設計部門では分からないのが普通だ。BOMの定義も、生産技術や製造部門の判断になる。業務系の情報システムでは、データの作成者がそのデータの登録者となり、オーナーシップをもって管理すべきだと一般に信じられている。この原則にしたがえば、BOMのマスタデータの登録作業は、複数部門によって分担されることになる。情報源(作成者)と、マスタへの登録者を誰にすべきかは別問題という考え方もある。設計部門からのデータを生産技術部門が受けて、BOM全体の登録は生産技術がまとめて担当する、という取り決めだって可能ではある。ここに一つの問題が生じる。場所が離れているのだ。両者は、別々の情報システムを使っていることが多い。サーバもデータベースも、物理的に別である。E-BOMとM-BOMは統合不可能なのか?答えは、単純だ。システムは物理的に別々でも良い。同じマテリアルは同じコードでよばれなければいけない。これが「BOM統合の原則」である。本社と工場が、同じモノを別々のコードでよんだり、モノの同一性について意見が分かれたりする状態があってはいけない。同じマテリアルの親も、同一でなければならない(そうでなければ構成管理の一貫性が崩れてしまう)。このような形で、複数のシステム間のマスタデータ整合性が担保されているなら、BOMは統合されているといっていい。少なくとも、E-BOMとM-BOMの乖離問題は起きていない。Management)的機能が増えている。設計部門はその中で、「E-BOM」を管理維持したいと考えるだろう。部品共通化や設計情報の再利用などをはかりたい、とも望むだろう。E-BOMに登録される品目コードは全社共通のものを使うべし、が原則だ。この話を推し進めていくと、異なる部門間で、モノの同一性について意見がくい違い、論争が生じるケースが出てくる。設計部門は、「これは内径X、外径Yの○○部品じゃないか」といい、製造部門は「いや、同じ形状の○○部品といっても、材質強度的に区別が必要なものが2種類あるんですよ」とか「仕入れ先が3社あって区別したいんです」とかいう要望が出てくる。この種の論争をどう解決するかが、じつはBOM統合にとって大切なのだ。長くなりすぎたので、この問題は項を改めて論じよう。technology.。