多くの企業は、BOMを「設計が終わると自動的に出てくる表」と捉え、まずﾃﾝﾌﾟﾚｰﾄや列数、ﾌｫｰﾏｯﾄを検討する。しかし実際には順序が逆である。誰がBOMを使うかを先に決め、必要なﾌｨｰﾙﾄﾞと不要なﾌｨｰﾙﾄﾞを選別し、その後にｼｽﾃﾑとﾃﾞｰﾀ構造を決める方がよい。そうしなければ、表は完成して見えても、購買、生産、在庫、組立で発生する問題は後工程まで残る。
本稿では、機械・工業企業向けに、BOMを「手作業で維持するExcel」ではなく「定義・抽出・追跡が可能なﾃﾞｰﾀﾋﾞｭｰ」にする方法を整理する。属性、ﾌｧｲﾙｶﾃｺﾞﾘ、ﾀｸﾞ抽出、Prodﾘｽﾄ、生産ﾌｧｲﾙ出力が、実行可能な一つの流れになる仕組みも説明する。
ﾃﾝﾌﾟﾚｰﾄではなく利用者から始める
BOMの代表的な利用者は購買部門だが、購買だけが利用者ではない。購買は標準部品、加工部品、板金部品、ｱｾﾝﾌﾞﾘ、在庫品を区別する。生産は工程と納品内容を必要とする。在庫は素材、既製ｺﾝﾎﾟｰﾈﾝﾄ、払出対象を区別する。組立は、製品を構成するﾌｧｲﾙと部品を把握する必要がある。
図面を出した時点で設計の対応が終わるわけではない。購買、供給者、加工者がﾌｧｲﾙの用途や範囲を理解できなければ、質問は設計へ戻ってくる。設計が対応すべき相手の種類と数が、必要なBOMﾋﾞｭｰの数を決める。
BOMは単に部品を並べる表ではない。部門ごとに異なる結果を、同じ一意なﾃﾞｰﾀ源から得られるようにする必要がある。従来の方法では総BOMを作成し、各部門が複製、抽出、削除を繰り返す。複製が始まった時点で、版の不一致、数量誤り、再確認が発生しやすくなる。
下流工程をBOM分類で支える
下流部門によって必要な情報は異なる。総BOMは保管と全体確認に適する。生産は溶接、射出成型、加工などの工程を重視する。購買は購入部品と標準部品を重視する。在庫は素材と既製ｺﾝﾎﾟｰﾈﾝﾄを重視する。組立は納品構成を重視する。
部門ごとに無関係なﾃﾞｰﾀﾍﾞｰｽを作ることではない。同じ基礎ﾃﾞｰﾀを、各部門の業務条件で抽出できるようにする。基礎ﾌｨｰﾙﾄﾞが安定していれば、業務変更に合わせてﾋﾞｭｰだけを変更でき、表全体を再作成する必要はない。
ﾌｨｰﾙﾄﾞの範囲は企業が定義する
「Make or Buy」は二値で表されることが多いが、実際の調達方法は二種類に限らない。加工と購買だけの企業もあれば、試作、印刷、射出成型、鋳造まで扱う企業もある。ｿﾌﾄｳｪｱが20種類を用意していても、すべての企業が20種類を必要とするわけではない。固定された分類では、すべての生産方式を表現できない。
選択肢は企業の管理者または設計規則が定義する方がよい。必要な項目を残し、不要な項目を削除する。ﾌｨｰﾙﾄﾞ名、選択肢、初期値は、実際の工程、部門、納品方法を反映すべきであり、企業がｿﾌﾄｳｪｱのﾃﾝﾌﾟﾚｰﾄに合わせる必要はない。
ﾌｧｲﾙｶﾃｺﾞﾘも同じ原理である。塗装工場が12色、不動態化工程が3種類の酸化色しか扱わないなら、設計者はその範囲から選択する。管理者が範囲を定義し、設計者は範囲内で実行する。自由入力による名称の揺れを防ぎ、後工程の抽出、集計、生産ﾌｧｲﾙ出力を安定させる。
SWTDOでは、板金表面工程、表面工程、塗装、熱処理、ｿﾘｯﾄﾞﾌﾟﾛｾｽ、ﾌｧｲﾙｶﾃｺﾞﾘ、部品分類などを企業側で定義できる。管理者が選択範囲を管理し、設計者は正しい値を選ぶ。口頭説明だけに依存するより信頼性が高い。
ﾌｨｰﾙﾄﾞを増やすことが、そのまま高品質なBOMになるわけではない。ﾌｨｰﾙﾄﾞが増えれば、未入力、誤入力、解釈違いの機会も増える。現在の業務を過不足なく表現する最小限の集合が必要であり、永遠に埋めきれない汎用ﾃﾝﾌﾟﾚｰﾄは適切ではない。
不要なﾌｨｰﾙﾄﾞは削除する
板金企業が熱処理を行わない場合や、小規模な工場が部品名と数量だけを必要とする場合もある。ｿﾌﾄｳｪｱに20個のﾌｨｰﾙﾄﾞがあるからといって、20個すべてを入力させる必要はない。無関係なﾌｨｰﾙﾄﾞは、口頭で「入力しない前提」と説明するのではなく、削除または非表示にする。
ﾌｨｰﾙﾄﾞ数はｺｰﾄﾞで固定せず、過去のﾃﾝﾌﾟﾚｰﾄからそのまま引き継ぐべきでもない。自社の工程と納品範囲を最も理解している管理者が取捨を決める。業務が変わった時に追加し、価値を生まないﾌｨｰﾙﾄﾞは削除する。
属性は部品ﾌｧｲﾙに属するﾃﾞｰﾀである。一方、数量は同じ部品でもｱｾﾝﾌﾞﾘごとに変わるため、ｱｾﾝﾌﾞﾘから取得する。小計や質量合計は計算結果であり、部品の固定属性ではない。構成は仕様差を区別するために必要だが、不要な場面では非表示にできる。
製造現場で「版」という言葉は曖昧になりやすい。10人の設計者に「版」と伝えれば、10通りの解釈が返る可能性がある。SWTDOでは、同一ﾓﾃﾞﾙの仕様違いを「構成」、SolidWorks図面のBOMと区別する一覧を「Prodﾘｽﾄ」と呼ぶ。用語が明確になって初めて、部門間の会話が一致する。
例えば一つの靴棚ｱｾﾝﾌﾞﾘに異なる靴ｻｲｽﾞが含まれる場合、ｻｲｽﾞは構成であり、ﾌﾞﾗﾝﾄﾞだけでは対象を特定できない。BOMのﾌｧｲﾙ名、構成、ｸﾞﾛｰﾊﾞﾙ主ｷｰ、数量も同じ問題を解決する必要がある。一意性を人の記憶に任せてはいけない。
ﾌｨｰﾙﾄﾞをﾃﾞｰﾀ源で分類する
BOMのﾌｨｰﾙﾄﾞは同じ種類のﾃﾞｰﾀではない。属性、数量、演算、構成、ｸﾞﾛｰﾊﾞﾙ主ｷｰ、判定式、添付に分類できる。属性は部品ﾌｧｲﾙ、数量はｱｾﾝﾌﾞﾘ、演算は集計、構成は仕様差、ｸﾞﾛｰﾊﾞﾙ主ｷｰは保存と検索、判定式は形状や工程から生成する値、添付は納品や組立に必要だが図面本体ではない対象を表す。
判定結果は形状や生産特性から生成できる。板金、溶接、複数ｿﾘｯﾄﾞ、複数構成などの条件を基礎側で属性化し、BOMで共通利用する。各部門が表の中で同じ判断を繰り返すより、一度生成した結果を使う方が安定する。
添付も見落としやすい。家具に付属する工具、組立治具、設置治具は図面本体ではないが、納品時には必要である。添付は業務や規則で作られる固定ﾚｺｰﾄﾞ、部品属性はﾌｧｲﾙ更新に追従する活ﾚｺｰﾄﾞである。同じBOMﾋﾞｭｰに表示できても、取得元は区別する必要がある。
総表からﾀｸﾞ式ﾋﾞｭｰへ
各ﾌｧｲﾙに安定した属性ﾀｸﾞがあれば、総BOMを複製して不要行を削除する必要はない。例えばﾌｧｲﾙｶﾃｺﾞﾘで板金を選ぶと、該当する全ﾌｧｲﾙが同じﾋﾞｭｰに入る。塗装色やｱｾﾝﾌﾞﾘ種別を選び、別のﾋﾞｭｰも作成できる。
ﾀｸﾞ抽出は単なる検索機能ではない。一つの一意なﾃﾞｰﾀ源を、設計、購買、生産、在庫、組立で同時に利用できるようにする。ﾋﾞｭｰは必要に応じて作成し、並べ替えと抽出はﾌｨｰﾙﾄﾞで処理する。複数のExcelを手作業で維持する必要はない。
Excel中心の方法との違いは次の通りである。
- ﾌｨｰﾙﾄﾞは一意なﾃﾞｰﾀ源に従い、設計の二次加工を必要としない。
- 各BOMﾋﾞｭｰを独立して保存し、再利用できる。
- ｸﾗｳﾄﾞﾃﾞｰﾀを他部門へ公開し、部門間連携に利用できる。
- 属性書込み対応のBOMは、複製ではなくﾃﾞｰﾀ源そのものを変更する。
- ﾃﾞｰﾀの追加、編集、削除を同じﾃﾞｰﾀ源から後続工程へ反映できる。
関連設定は、SWTDOのﾌﾟﾛﾊﾟﾃｨﾌｫｰﾏｯﾄ説明とProd中央庫説明を参照。既存Excelが多い企業は、汎用ｲﾝﾎﾟｰﾀで段階的に移行できる。
BOM階層は納品対象で設計する
一つのﾌﾟﾛｼﾞｪｸﾄには複数のｱｾﾝﾌﾞﾘ、一つのｱｾﾝﾌﾞﾘには複数のBOMを作成できる。階層表は構造表示に適するが、購買と納品の表現に常に適するとは限らない。設計ﾂﾘｰの認識に合っていても、数量を拡大した場合、複数人で編集する場合、同一部品が複数回登場する場合に人的誤りが増える。
構造ﾋﾞｭｰと納品ﾋﾞｭｰを分ける。構造ﾋﾞｭｰは親子関係を保持し、製品理解を助ける。納品ﾋﾞｭｰは各部門が何を必要とするかを直接示す。属性とﾃﾞｰﾀ源がﾌｧｲﾙ側に固定されていれば、BOMは手作業で維持する総表ではなく、抽出結果として扱える。
総BOMは保管と全体確認に引き続き利用できるが、すべての納品問題を一つの表で解決する必要はない。総表を削除して作り直すのではなく、必要なBOMを必要な時に作成する。
Excelより簡単に変更できるｸﾗｳﾄﾞBOM
普及を左右するのは機能の先進性より、既存習慣より簡単に使えるかである。Excelの変更は速い。ﾌｧｲﾙを開き、数ｾﾙを変更して保存するだけで済む。BOMを変更するたびにSolidWorksを起動し、ｱｾﾝﾌﾞﾘを開き、図面表を探す必要があれば、基礎ﾃﾞｰﾀが正確でも利用者は抵抗を感じる。
ｸﾗｳﾄﾞの利点は、ﾛｰｶﾙﾓﾃﾞﾙの読込みを省略できることにある。既存のﾃﾞｰﾀ表を直接検索、変更し、すべての部品やｱｾﾝﾌﾞﾘを開く必要をなくせる。属性変更とﾓﾃﾞﾙ出力を分離し、結果を一意なﾃﾞｰﾀ源へ戻せる。Excel編集と同等以上に簡単なら、より一貫した方法を選ぶ理由が生まれる。
ﾜｰｸﾍﾞﾝﾁは、同期、検証、ﾌｧｲﾙ生成を単純な業務画面の背後に隠すべきである。利用者は業務判断を行い、ｼｽﾃﾑが一貫性を担保する。
生産ﾌｧｲﾙを規則で自動出力する
下流部門から求められる形式は多様に見えるが、実際にはDWG/DXF、PDF、STEP、Excel、少数のJPGで大部分をｶﾊﾞｰできる。ﾓﾃﾞﾙ形式は自動保存できる。図面は版面と更新確認が必要だが、それ以外の生産ﾌｧｲﾙは規則で自動出力できる。
BOM変更のたびに設計者が手作業で書き出すなら、一意なﾃﾞｰﾀ源の価値は半分しか実現しない。BOM変更後、納品規則に従って必要ﾌｧｲﾙを生成し、各部門が自分のBOMﾋﾞｭｰから必要ﾌｧｲﾙを取得できる状態が望ましい。100枚の図面から各担当者が探す必要はない。
SWTDOは、ﾌｧｲﾙ種別、命名規則、出力場所、BOMﾋﾞｭｰを接続する。設計は判断が必要な図面工程を担当し、残りの生産ﾌｧｲﾙ工程は設定規則に従って実行する。
導入前の確認項目
- ﾃﾝﾌﾟﾚｰﾄより先に、各BOMﾋﾞｭｰの実際の利用者を明確にする。
- 管理者がﾌｨｰﾙﾄﾞ範囲と選択肢を定義する。
- 業務判断に寄与しないﾌｨｰﾙﾄﾞを削除する。
- 部品属性、ｱｾﾝﾌﾞﾘ数量、構成、主ｷｰ、演算、添付をﾃﾞｰﾀ源で区別する。
- 各ﾌｧｲﾙに一意な識別子を与え、ﾀｸﾞからBOMﾋﾞｭｰを作成する。
- 構造階層と納品階層を分ける。
- ｸﾗｳﾄﾞ検索と書込みで重複作業をなくす。
- 生産ﾌｧｲﾙを自動化し、人の判断が必要な図面確認は残す。
BOMは列数を増やすための表ではない。企業が下流部門と協力する方法を表現するﾃﾞｰﾀ構造である。ﾌｨｰﾙﾄﾞ範囲、一意性、納品ﾋﾞｭｰが正しければ、購買、生産、在庫、ﾌｧｲﾙ出力の基盤が安定する。設計から購買、組立までの一意なﾃﾞｰﾀ源については、設計・出図・購買・組立で最も負担が大きい作業も参照。