この記事の結論: BOM管理システムの導入成否は、設計部品表(E-BOM)と製造部品表(M-BOM)の変換ルールや設計変更(ECO/ECN)の運用を要件定義でどこまで自社の実態に即して具体化できるかで決まります。
製品の一覧から探したい方は、先にBOM管理の比較記事(製造業向けBOM管理20選)もあわせてご覧ください。本記事はその「比較の前段」にあたる内容です。
BOM管理システムの要件定義とは
BOM管理システムの要件定義とは、製品構成情報をどの粒度・採番ルールで一元管理し、E-BOMからM-BOMへどう展開・変換するか、設計変更や品番改訂をどのワークフローで統制するかを、PLM・CAD・ERP・生産管理との連携も含めて文書化する工程です。単なる部品リストの電子化ではなく、構成管理と変更管理の業務ルールを定義することが核心です。現行の手作業(Excel BOMや図面台帳)に潜む暗黙ルールを言語化し、システム要件として明文化します。
なぜ要件定義でBOM管理システム導入の成否が決まるのか
BOMは設計・調達・製造・原価のすべての起点となるマスタであり、ここでの定義の曖昧さが下流の全部門に波及します。要件定義で構成の粒度や変更管理のルールを詰め切れないまま導入すると、現場が結局Excelに逃げて二重管理に陥ります。
- E-BOMとM-BOMの変換ルール(中間品・工程順序・歩留り・代替部品)を要件化せず、設計BOMをそのまま製造で使おうとして現場が破綻する
- 品番採番ルールと改訂(リビジョン)管理の方針を決めないまま導入し、同一部品の重複登録や旧版手配が多発する
- 設計変更(ECO/ECN)の影響範囲展開とワークフローを定義せず、変更が調達・製造へ伝わらず仕掛品ロスや手配ミスを招く
- オプション・派生品の構成バリエーション(150%BOM・コンフィグレーション)を考慮せず、受注生産・多品種に対応できない
要件定義で決める5つの範囲
- 構成管理 — 親子の階層構造、品番採番、リビジョン・有効日付(エフェクティビティ)管理の対象範囲を定義する
- BOM種別の連携 — E-BOM・M-BOM・サービスBOM・販売BOMのどれを管理し、相互の変換・同期をどこまで自動化するか線引きする
- 変更管理 — 設計変更(ECO/ECN)の起票から承認、影響部品の展開、切替日設定までのワークフロー範囲を定める
- 外部連携 — CAD・PLM・ERP・生産管理・購買とのBOM受け渡しのうち、システム化する連携と手運用で残す部分を切り分ける
- 原価・調達連携 — BOM展開による所要量計算(部品表展開)と原価積上げをどこまで本システムで担うか範囲を確定する
BOM管理システムは単独で完結せず、CAD・PLM・ERPとの責任分界点(どのシステムがBOMのマスタか)を最初に定めないと多重管理の温床になります。
要件定義の進め方:5ステップ
| ステップ | 内容 | アウトプット |
|---|---|---|
| ① | 現状のBOM運用棚卸し。Excel BOM・図面台帳・部品マスタの実態と採番・改訂の暗黙ルールを洗い出す | 現行BOM運用一覧、品番体系・改訂ルールの整理表 |
| ② | 対象BOM種別と構成粒度の決定。E-BOM/M-BOMの範囲、階層深さ、購入品・中間品の扱いを定義する | BOM管理方針書、構成粒度・採番ルール定義書 |
| ③ | 業務フロー設計。設計変更(ECO/ECN)と品番改訂のワークフロー、承認経路、有効日付運用を設計する | 変更管理フロー図、承認ルール定義書 |
| ④ | 機能・非機能・連携要件の整理。CAD/PLM/ERP連携と必要機能を要件項目に落とし込む | 機能要件一覧、連携要件定義書、非機能要件書 |
| ⑤ | RFP化と評価基準策定。要件を提案依頼書にまとめ、ベンダー評価軸と重みを設定する | RFP、評価基準表、移行計画ドラフト |
KPIには「部品マスタ重複率」「設計変更リードタイム(ECO起票から製造反映まで)」「旧版図面・旧BOMによる手配ミス件数」「BOM作成工数」など、構成管理と変更管理の精度を測る指標を設定します。
機能要件チェックリスト(BOM管理システムの核心)
BOM管理システムに求める代表的な機能要件です。自社の状況に照らして「必須/任意/不要」を判断してください。
| 大分類 | 主な要件項目 |
|---|---|
| 構成・階層管理 | 多階層BOMのツリー表示・編集, 親子展開とサマライズ(合計員数算出), ユニット/モジュール単位の流用・参照構成, 単一/複数構成の管理 |
| 品番・マスタ管理 | 品番採番ルール(自動採番・体系チェック), 部品マスタの一元管理と重複検知, 図面・3Dモデル・仕様書の添付管理, 単位・購入区分・調達先の属性保持 |
| リビジョン・改訂管理 | 部品とBOMのリビジョン管理, 有効日付(エフェクティビティ)による新旧切替, 改訂履歴の世代管理と差分表示, 旧版凍結(リリース後ロック) |
| 設計変更管理(ECO/ECN) | 変更要求(ECR)から変更指示(ECO/ECN)への起票, 影響部品・上位構成の影響範囲展開(Where-Used), 承認ワークフローと電子承認, 切替日・在庫消化(ランアウト)指示 |
| E-BOM/M-BOM変換 | 設計BOMから製造BOMへの変換ルール定義, 工程順序・中間品(仕掛品番)の挿入, 製造拠点別BOM・歩留り設定, ファントム品(仮想部品)の展開制御 |
| BOM比較・差分 | リビジョン間・E-BOMとM-BOM間の構成比較, 追加・削除・員数変更の差分抽出, 多階層での差分一括確認, 比較結果のレポート出力 |
| 構成バリエーション管理 | オプション・派生品のコンフィグレーション(150%BOM), 仕様選択ルール(依存・排他条件), 受注仕様からの構成自動生成, 共通部品の流用管理 |
| 所要量・原価展開 | BOM展開による部品所要量計算, 標準原価の積上げ計算, 員数×単価のロールアップ, 調達リードタイム加味の手配情報生成 |
| 検索・Where-Used | 部品からの上位構成逆引き(使用先検索), 構成内全展開・単一階層展開の切替, 代替部品・互換品の検索, 廃番・代替指定部品の影響確認 |
| 権限・セキュリティ | 設計/製造/調達など役割別の参照・編集権限, リリースステータス別の編集制御, 操作ログ・変更履歴の保持, 拠点・プロジェクト単位のアクセス制御 |
見落としがちな要件: 見落としがちなのは、ファントム品(中間まとめ部品)や代替部品・サプレッション(条件付き不使用)の扱い、有効日付による切替運用、そして同一部品が複数製品で使われる際のWhere-Used(使用先逆引き)です。これらが要件から漏れると、設計変更時の影響調査が手作業に戻り、改訂のたびに混乱します。
非機能要件で見落としがちなポイント
機能だけに目が向きがちですが、非機能要件こそ稼働後の満足度を左右します。
| 区分 | 確認すべき要件(目標値の例) |
|---|---|
| 性能 | 数千〜数万部品の多階層BOMでも全展開・サマライズが数秒で完了(1万行展開で3秒以内が目安) |
| 可用性 | 設計・製造の業務時間帯で稼働率99.5%以上、リリース処理や夜間連携バッチが業務に支障を与えないこと |
| 拡張性 | 製品系列・拠点・取扱品目の増加に対し、BOM件数やリビジョン世代が増えても性能劣化しないデータ構造であること |
| セキュリティ | 図面・構成情報の機密保持に対応し、役割別権限・操作ログ・外部連携時の暗号化(TLS)を備えること |
| 運用保守 | 品番採番ルールや変更ワークフロー、E-BOM/M-BOM変換ルールを情報システム部門が画面設定で変更できること |
| 移行 | 既存ExcelBOM・旧PDM/PLMからの構成・品番・図面の一括移行と、移行後の構成整合性チェックができること(重複品番の名寄せ含む) |
| コンプライアンス | RoHS・REACH等の含有化学物質情報や輸出管理該非情報をBOM属性として保持・出力でき、トレーサビリティを確保できること |
BOMは長期にわたり世代が蓄積するため、改訂履歴・有効日付を保持したまま性能を維持できるデータ設計と、変換ルールを内製で保守できる柔軟性が特に重要です。
基幹・周辺システムとの連携要件
どのシステムと、何を、どの方式(API/CSV/EDI)で、どの頻度で連携するかを定義します。
| 連携先 | 主な連携内容 |
|---|---|
| CAD(3D/2D・ECAD) | 設計時の部品構成・図面・モデルをE-BOMとして取り込み、図面リビジョンと部品改訂を同期する |
| PLM/PDM | 製品ライフサイクル全体の文書・構成を連携し、設計変更(ECO/ECN)情報とリリースステータスを受け渡す |
| ERP(生産・販売) | 確定したM-BOMと品番マスタを連携し、所要量計算(MRP)・購買・在庫の基礎データとして提供する |
| 生産管理システム | 製造BOMと工程情報を連携し、製造指示・工順・仕掛品番の展開に用いる |
| 購買・調達システム | 部品の調達先・単価・リードタイム情報を連携し、BOM展開から手配・発注へつなぐ |
| 原価管理システム | BOM構成と標準単価から原価積上げ結果を連携し、見積・原価差異分析に活用する |
| 含有化学物質管理(chemSHERPA等) | RoHS/REACH対応の含有情報を部品単位で連携し、製品単位の含有量集計・調査回答に用いる |
連携設計の要は「どのシステムがBOMの正(マスタ)か」を一つに定めることで、CAD→BOM管理→ERPの一方向同期にするか双方向にするかで運用難易度が大きく変わります。
RFP(提案依頼書)に盛り込むべき項目
要件が固まったら、ベンダーへの提案依頼書(RFP)にまとめます。最低限、次の項目を含めます。
- 自社の製品構成と生産形態(個別受注/繰返し量産/派生品の多さ)、対象BOM種別(E-BOM・M-BOM)と現行のExcel運用の課題
- 必須機能の優先度(多階層構成管理、リビジョン・有効日付管理、ECO/ECNワークフロー、E-BOM/M-BOM変換、Where-Used検索など)
- CAD・PLM・ERP・生産管理との具体的な連携要件と、BOMマスタの責任分界点に関する考え方
- 既存ExcelBOM・旧システムからのデータ移行範囲(構成・品番・図面・改訂履歴)と名寄せ・整合性チェックの方針
- 非機能要件(性能の目標値、利用ユーザー数・拠点数、含有化学物質などコンプライアンス対応、権限・ログ)
- 想定スケジュール・予算枠と、保守体制・変換ルールやワークフローのカスタマイズ可否
RFPでは自社のBOM運用の特殊性(採番ルール、派生品の構成パターン、変換時の暗黙ルール)を具体的に開示するほど、ベンダーから的確で実現性の高い提案を引き出せます。
ベンダーを横並び比較する評価マトリクス
評価軸は製品特性に応じて重みを変え、多品種・受注生産が中心なら構成バリエーション(コンフィグレーション)管理とE-BOM/M-BOM変換の柔軟性を重視し、量産・グローバル製造が中心なら設計変更(ECO/ECN)の統制力と多拠点・多言語対応、ERP連携の堅牢性を重視します。機能適合度・連携実現性・同業種導入実績・移行支援・総保有コスト(TCO)を重み付けして総合評価します。
デモでは自社の実際の製品構成と設計変更シナリオ(影響範囲展開と切替)を持ち込み、変換ルールやWhere-Usedが自社運用で機能するかを必ず実機確認します。
BOM管理システム導入でよくある失敗と回避策
| よくある失敗 | 原因 | 回避策 |
|---|---|---|
| 設計BOMをそのまま製造に流用し現場が混乱 | E-BOMとM-BOMの違い(工程順序・中間品・歩留り・代替部品)を要件で区別しなかった | 要件定義段階でE-BOM/M-BOMの変換ルールを明文化し、両BOMを別管理して変換機能を必須要件に据える |
| 同一部品が重複登録され在庫・原価が乱れる | 品番採番ルールと重複検知の方針を定めず、各設計者が独自に登録した | 採番体系と自動採番・重複チェックを要件化し、移行時に既存BOMの名寄せ(重複統合)を実施する |
| 設計変更が調達・製造に伝わらず手配ミス・仕掛ロスが発生 | ECO/ECNの影響範囲展開と承認ワークフロー、切替日運用を要件に含めなかった | Where-Usedによる影響部品自動展開と承認フロー、有効日付による切替・在庫消化指示を必須機能とする |
| 導入後も現場がExcel BOMを併用し二重管理が残る | 現行の暗黙ルールや派生品の構成パターンを棚卸しせず、現場業務に合わない仕様で導入した | 現状業務の棚卸しを①で徹底し、構成バリエーションや帳票要件を現場と合意のうえ要件へ反映する |
チェックリストの使い方
本記事内の機能要件・非機能要件・連携要件・評価マトリクスの各表は、要件整理のたたき台として使えます。表をコピーして自社に必要な項目の「要否」「優先度」を記入し、ベンダー回答を並べて比較してください。
- 各表で自社に必要な項目の要否(必須/任意/不要)と優先度を記入する
- 不足する自社固有の要件を追記する
- ベンダー回答(○標準/△設定・追加開発/×不可)を記入する
- 評価マトリクスで重みと評点を入れ、加重スコアで横並び比較する
本記事は、記事内の表をコピーして利用する形式です。ダウンロード用Excelファイルの配布はありません。
関連記事
製品を比較したい方へ:製造業向けBOM管理20選
生産管理の全体像から理解したい方へ:生産管理システムとは?機能・要件定義・選び方
要件定義の進め方(他システムの例):生産管理システムの要件定義 / 在庫管理システムの要件定義
よくある質問(FAQ)
E-BOMとM-BOMは必ず分けて管理すべきですか
設計部門と製造部門で構成の見方が異なるため、原則は分けて管理し変換ルールで橋渡しするのが安全です。組立工程が単純で工程展開が不要な場合は単一BOM運用も選択肢ですが、その判断は要件定義で生産形態を踏まえて行います。
BOMのマスタはCAD・PLM・ERPのどれに置くべきですか
唯一の正解はなく、設計起点ならCAD/PLM、生産・原価起点ならERPがマスタになりがちです。重要なのは責任分界点を一つに決め、同期方向を片方向に統一して多重管理を防ぐことです。
既存のExcel BOMからの移行で最も注意すべき点は何ですか
品番の重複・表記ゆれの名寄せと、階層構造・員数の整合性チェックです。改訂履歴をどこまで移行するかも論点で、現行リビジョンのみ移行し過去履歴は参照保管とする割り切りも有効です。
設計変更管理(ECO/ECN)はどこまでシステム化すべきですか
起票・承認・影響範囲展開・切替日設定までを一連でシステム化すると効果が大きいです。最低限、Where-Usedによる影響部品の自動展開と承認の電子記録は要件に含めることを推奨します。