生産革新のためのBOM（部品表）再構築入門(2)
生産革新のためのBOM（部品表）再構築入門(2) （2013/11/11）
＜設計部品表（E-BOM）と製造部品表（M-BOM）の乖離＞
BOM再構築の課題の中でも、もっとも多く見られる悩みが「設計部品表と製造部品表の乖離」だ。ふつう、前者はEngineering
BOMを略してE-BOMと呼び、後者をManufacturing
BOMの略でM-BOMと呼ぶ。
設 計部品表（E-BOM）とは、設計部門が作成する部品表のことで、最終製品を構成する全部品をリストアップしたものである。製品の構成図（断面図）の各部
品に①②③・・といった番号をつけ、その右側に番号・部品名称のリストをつけたものを、誰しも見たことがあると思う。この部品構成リストがE-BOMの原
型である。
たとえば、『冷し中華』という製品を考えてみよう。冷し中華一人前は、図１左に示すように、茹で麺・たれ・錦糸玉子・チャーシュー細切・きゅうり細切から組み立てられる。
機械・電気など組立加工系の業種におけるE-BOMは、最終組立に使う部品のリストであるため、伝統的にはしばしば、部品間の階層構造を持たない「サマリー型部品表」の形をしていた。もっとも、現代のインテリジェントなCADシステムは、自動的に部品リストをE-BOMとして出力する機能もある。さらに必要ならば、製品→モジュール→サブモジュール→部品、という階層構造を定義することもできる。
と ころが、工場はこのE-BOMだけでは仕事ができない。冷し中華の例で端的にいえば、材料の手配はどうしたらいいのか？ まさか茹でたての麺を毎回買って
くるわけにも行くまい。購買には、図１右に示すような購入材料リストが必要である（これを購買BOMと呼ぶこともある）。
E-BOMから、購入材料リストを作成するためには、それぞれの部品をどんな材料からどのよ うな手順で製造するかを示す表が必要になる（図２）。これを製造部品表（M-BOM）と呼ぶ。製造部品表は、通常は生産技術部門による工程設計の結果とし
て作成され、主に製造現場において生産管理で用いる。
M-BOMの特徴は、部品の親子関係を示す「ストラクチャー型部品表」
の形になることだ。また、工順（Routing＝加工順序）の情報が付加される。生産管理にＭＲＰシステムを用いている企業では、さらに親子関係に「標準
リードタイム」を設定し、生産スケジューリングに利用する。このM-BOMは、生産技術部門がE-BOMを元に作成するケースが多い。
それでは、なぜ多くの企業がE-BOMとM-BOMの乖離に悩んでいるのか。その理由は、大きく４つある。
（１）品目コードの不統一
本 社設計部門では、部品コードを定めずに「部品の図番」や「部品規格番号」や「名称」だけで済ませる場合がある。一方、工場では購買先を決めてから品目マス
タを登録するケースが多い。その段階で、はじめて部品に品目コード（Part Number）がふられる。この品目コードは、本来であれば本社設計部門に伝達され、図面やCADの属性に登録されるべきだが、部品点数は多いし、マスタ
登録のタイミングはバラバラだし、おまけにしばしばマイナーチェンジが行われたりするので、実際にはなかなか簡単ではない。
その結果、全社で品目のコード体系の統一がとれなくなり、E-BOMからM-BOMへの「翻訳」作業が必要になってしまう。しかし、これでは手間がかかるし、誤りが入り込みやすくなる。
（２）代替部品の使用
材料手配の都合上、工場では一時的な代替部品を使用することがある。サプライヤー側や購買・外注の都合で素材・品番が変わることもある（この事情は、とくに海外工場に多い）。そのため、設計と現物に食い違いが生じてくるのである。
（３）副資材や包装材料の追加
製品設計図には、副資材や包装材料はふつう記載されないため、E-BOMにないことが多い。したがって、工場では手配が必要になる。したがって、独自にM-BOMに追加せざるを得ない。
（４）設計変更の発生と在庫切替タイミングの食い違い
設 計部門において仕様改訂や品質改善のため設計変更が発生した場合、本来はM-BOM側も同期して修正すべきである。しかし、工場は仕掛りや部品在庫のため
に、M-BOMをすぐには切り替えられない。「手元にある在庫を使い切ってから修正しよう」などと考えている内に、次の設計変更通知が来たりする。
こうして、いったんE-BOMとM-BOMが乖離しはじめると、問題点がいろいろ発生してくる。まず、新製品導入スピードが遅くなる。また、品質クレームやアフターサービス対応が難しくなる。どのロットはどんな部品構成で作ったか、トレースできなくなるからだ。
中でも、もっとも深刻なのは（１）の品目コードの不統一である。企業のマテリアル・マネジメントが混乱し、モノが有り余っているのに必要なモノがない、という状態が生じてくる。コードが無ければ設計の標準化も困難だ。モジュール化や、前回述べたATO生産方式（Assemble to Order＝受注組立生産）の実現は夢物語になる。
それでは、どうすべきか。この背景には、開発設計と生産現場の乖離がある。マネジメント・レベルで、まず問題認識が必要であろう。その上で、BOM維持体制と責任分担の確立、品目コード体系の統一、そして適切なBOMプロセッサの導入などの施策が必要になるのである。
＜BOM再構築プロジェクトのために＞
市場が回復中の機をとらえ、今日、多くの企業が生産の革新にチャレンジしている。その鍵がBOMの再構築にあることを、これまでの話でご理解いただけたと思う。
需 要は増えてきたのに、思ったように増産できない企業がある。第一の理由は、仕様の個別対応の手間が多くて、設計部門がボトルネックになっためである。第二
の理由は、部品マスタの無秩序な増大や変更で、資材購買と在庫管理が混乱するからだ。材料が無ければ工場はモノを作れない。第三の理由は、標準モジュール
化の欠如で、工場の負荷平準化が困難なことにある。これらはすべて、BOMに関わる問題だ。
BOMの問題は、生産のグローバル展開の 足かせにもなってきた。なぜ、国ごとに違う図番体系や品目コードになってしまうのか？ マスタが欠如していたからである。あの自動車産業でさえ、国別仕様
と供給可能部品によって生じたバラエティに悩んできた。いまから10年近く前、トヨタは社内に4種類のBOMをかかえており、その一元化と再構築のため
に、驚くほど巨額の費用と工数をかけてとりくまざるをえなかった。
ちあみに、正確に言うとBOMは『部品表』ではない。部品表という日本 語は、何となく組立加工産業のみを連想させる。しかし「部品」に縁のない食品・素材・化学・電子材料・医薬品・アパレル業界などでも、BOM（Bill
of Material＝マテリアルの集計表）は存在するし、同じように重要なのである。
それでは、どうしたらBOMの再構築が進められるのか。
まず、第一に、これは情報技術だけの問題ではない、 と強調しておきたい。複数のデータベースをつなぐツールや、ERP・PDMパッケージ等の導入で、事足れりと考えないこと。むしろ、BOMの運用ルールこ
そ問題なのだ。誰が、何をいつ登録するのか。どうメンテしていくのか。いつ廃止にするのか。いかに標準化をはかるのか。設計（E-BOM）と製造（M-
BOM）の乖離をどう防ぐのか。運用ポリシーがあって初めて、必要なITツールが決まる。
もうひとつ重要なことは、あるべきBOMのマスタと、現実のBOM履歴データを区別することだ。設計はBOMのあるべき姿を規定する。これ
はマスタだ。しかし、製造の現実では、様々な理由から代替部品を使ったり、歩留りのために予定以上の材料を使ったりする。顧客サービスや在庫管理のために
は、個別の履歴をとっておく必要がある。つまり、製造指図や製造報告に付随したBOMのトランザクション・データを、マスタとは別に持つべきなのだ。
そして、何よりも大事なことは、中心となる『マテリアル・マスタ』の再統一だ。これを部品マスタ、あるいは品目マスタなどと呼ぶ会社もある。呼び名はどうあれ、設計･購買・生産技術・工務・製造・物流・・すべての部門が使用し関係している基準データだ。これがバラバラの状態を放置してはいけない。
BOM 再構築プロジェクトのあり方は企業の状況や生産形態によって様々だが、その流れの一例を、図４に示す。いずれの場合でも、最初に着手すべきは、何のために
BOMを再構築するのか、どのような問題を解決し、どんな能力を得るために行うのかを明確化する事である。これを、経営トップや企画部門が中心になって社
内に宣言する。そして、遂行体制を確立する。
いうまでもなく、BOM再構築には、クロス・ファンクショナルな活動＝プロジェクト・チーム体制での取り組みが必要になる。プロマネを任命し、スタッフと時間と費用を与えて、これを推進していくべきだ。誰かの片手間で済む仕事ではないのだから。
[図３ BOM再構築プロジェクトの流れ（例）]
つぎに、BOM活用の現状と課題を、関連する各部門（製造業ならば営業を含むほとんど のライン部門が関係すると思っていい）で調査し、把握する。そこから、あるべきBOMデータの設計に進む。マテリアルのコード体系、BOMに付随すべき属
性項目等を整理するのである。このとき、主要ユーザ部門を相手に、テスト収集を行い、実用に耐えるデータ設計となっているかを検証しながらすすめる方がい
いだろう。
そして、BOMデータの収集と整理のフェーズに進んでいく。データを、マテリアル、マテリアルの親子（階層）関係、工順（＝加
工手順、レシピ）にしたがって整理していく。このとき活躍するツールがBOMプロセッサだ。またモジュール化設計を進めている場合は、モジュールの組合せ
で実現できる製品仕様・性能との関係を定めていく。これは受注用コンフィギュレータの基礎になるから、営業部門の参画も望ましい。
データが収集できたら、クレンジング作業や整合性チェックを経て、ターゲットとなる情報システムのデータベースに登録する作業となる。ここは特にIT部門に活躍してもらうべきステップだ。
そして最後に、BOMの運用フローと保守体制の構築を行う。BOMは生き物である。今後も長い間、データを維持・登録・修正しながら使っていかなければならない。その体制と責任分担を決めて実行するのである。
そ して、ひとつ助言させてもらえるなら、このプロジェクトには外部の目を取り入れた方が良い。さもないと声の大きい部署の「部分最適」で終わる可能性が大だ
ろう。BOMを再構築し、生産システム全体を生まれ変わらせる仕事を成功させるためにも、全体最適を目標に高く掲げるべきだ。そうして、日本のより多くの
企業が、活気と余裕を取り戻すことを祈ってやまない。
＜参考図書＞
Follow me!
