部品表（BOM）

Joannes Vermorel による、2020年3月

A BOM (部品表) とは、最終製品を製造、組み立て、または修理するために必要な原材料や部品、その数量の一覧です。BOM は最終製品に関連する要件を在庫ベースでコンパクトに表現することを目的としており、そのため、enterprise software 製品、例えば ERPs や MRP に見られ、replenishment 発注などの反復作業を自動化するために使用されます。実際、BOM は分野によって様々な目的を持つ包括的な用語です。

BOMの概要

部品表は、供給チェーンにおいて広く利用される情報アーティファクトであり、SKUs（在庫管理単位）や MOQs（最小発注量）に類似しています。最も単純な形態、すなわち シンプル BOM では、部品表は材料とそれに伴う数量の一覧です。一方、CAD（コンピュータ支援設計）ソフトウェアから取得される高度な形態では、製品の技術図面や部品の配置情報が含まれます。BOM に関連する意図は、対象となる業界により異なります：

製造業では、BOM は通常、部品やコンポーネントが組み立てられるプロセスを反映しています。テープ、塗料、オイル、インクなどの消耗品は、しばしば製造BOMには含まれません。BOM は主に、原材料、仕掛品、最終製品の相対的な割合の流れの一貫性を維持するために使用されます。
小売業では、BOM は通常、バンドル、キット、またはパックと呼ばれます。これは、顧客の購入点数を増加させることにより割引を与える 価格設定 メカニズムを反映しています。場合によっては、バンドルは単に利便性のため、例えばおもちゃとその電池を一緒に販売する、といったケースもあり、BOM は純粋に抽象的な見方に留まることもあります。
再製造および保守において、BOM は修理に必要となる可能性のある材料を示します。このような状況では、BOM に記載される数量は最終的に必要となる材料の上限にすぎません。修理可能な部品の状態に応じて、修理に必要なのは BOM のごく一部であることが多いですが、正確な数量は修理完了まで判明しないのが通例です。

BOM の管理は マスターデータ 管理の領域に属しており、そのため ERP や MRP といった資産管理システムには何らかの形でBOMが組み込まれています。在庫補充などの多くの日常業務は、正確で最新のBOM維持に依存しています。

多層BOM

多層BOMは、BOM と同様の一覧ですが、その中の項目がさらに自身のBOMを持つ場合があります。多層BOMは基本的にBOMの 再帰的 視点を表しています。一見、より 高度な 構造に見えるかもしれませんが、実際にはBOMをサポートするソフトウェアは偶発的にでも多層BOMを取り扱うため、必ずしも高度なものとは限りません。実際、ソフトウェア上でBOMがサポートされれば、供給チェーンの担当者がシステム内で「仮想」部品を作成し、それらにBOMを設定することを妨げるものは通常ありません。システムが多層BOMを扱うための標準的な方法を提供していない場合、これらの仮想部品は多層BOMを表現するためだけに存在することになります。

多層BOMに関連する主な注目点は次のとおりです：

入力データの検証、たとえば部品がその内部要件として自らを参照する循環依存を未然に防ぐこと。
操作性の向上、すなわち、複数のレベルが関与する複雑なBOM管理を容易にするために、最終製品に含まれるすべての内部BOMを展開できる機能など。
データの充実化、例えば製造のリードタイムをBOM構造に関連付けることで、BOMによってモデル化された基礎プロセスをより詳細に把握できるようにすること。

BOMとサービスレベル

BOM が関与する最終製品のサービス品質（多くの場合、service levelsで測定される）を確保することは、通常、やや困難な統計問題です。BOM を扱うほとんどの企業は、多くの最終製品に共通の内部部品を供給しており、同じ部品が複数の最終製品に寄与するため、複数のBOMに登場します。そのような状況下では、内部部品のサービスレベルが実測または意図的に管理されていたとしても、最終製品の_結果としての_サービスレベルを算出する閉じた解は存在しません。

企業が単一の最終製品のみを扱う場合、その最終製品のサービスレベルは、構成部品の中で最も低いサービスレベルとして 合理的に 近似できることが多いです。同条件下では、内部部品のストックアウトは高い相関をもって発生し、safety stocksも唯一の最終製品に合わせて調整されると考えられます。しかし、サプライヤーのリードタイムが異なる場合や、最終製品の将来需要以外にも不確実性が存在する場合、この近似は当てはまらない可能性があります。

企業が多数の最終製品を扱い、いずれも他を圧倒しない場合、各最終製品のサービスレベルは、そのすべての部品のサービスレベルの積として 合理的に 近似できることが多いです。この場合、内部部品の入手可能性は独立していると仮定され、最終製品の組立て条件となります。ただし、内部部品の消費がごく一部の最終製品に支配される場合、この近似は成り立たない可能性があります。

上記の二つの状況、すなわち 単一最終製品 と 均一最終製品 は、それぞれ最終製品のサービスレベルが構成部品のサービスレベルに対して取り得る上限と下限を示しています。最良の場合、最終製品のサービスレベルは最も弱い部品のサービスレベルを下回ることはなく、最悪の場合、全ての部品のサービスレベルの積を上回ることはありません。

再製造BOM

再製造においては、通常航空と呼ばれる MRO（メンテナンス・リペア・オーバーホール）の分野で、最終製品（例：航空分野のロータブル部品）が修理可能となり、BOM は修理に関与する可能性のある材料の全一覧を示します。しかし、最終製品を分解し検査した結果、実際に修理を行うために必要なのは元のBOMリストのごく一部であることがほとんどです。なお、修理作業を完遂するために必要な正確な内部部品と数量は、事前に判明することはありません。

再製造BOMは、本質的に 業務の履歴管理 の領域に属するため、従来のBOM（マスターデータ の領域に属する）とは異なります。各修理作業が消費した部品まで追跡可能なため、関与するデータエントリの数は格段に多く、不確実性は通常、解消不可能です。

再製造BOMが存在する状況下でのサービス品質（通常は TAT（ターンアラウンドタイム）で測定される）の確保は、修理の将来需要だけでなく、各修理に関連する要件も不確実であるため、従来のBOMを扱う場合以上に複雑です。再製造の場合のサービス品質のモデリングと最適化は、通常、probabilistic forecastingを用いたモデリングによって行われます。

コンフィギュラブルBOM

自動車や電子機器をはじめとする多くの業界では、最終製品の仕様を顧客が定義できるよう、高度なコンフィギュラビリティが提供されています。すべての構成に対して個別のSKUを割り当て管理するのが困難になる場合、企業は通常、許容可能な構成の集合を定義するコンフィギュラブルBOMの概念に頼ります。

コンフィギュラブルBOMは、一連の課題を提示します：

すべての可能な構成を包含するだけでなく、実現不可能な構成を除外できる十分な表現力を持つ comprehension を定義すること。例えば、ワークステーション（パーソナルコンピュータ）の場合、特定の電源アダプターの適合性は、搭載されているコンポーネントの一覧に依存します。計算機科学では、comprehension の目的は、ブール式（低い表現力）よりも高く、一般的なプログラム（最大の表現力）よりも低い中間レベルの表現力を提供することです。コンフィギュラブルBOMに用いられる comprehension は、しばしば企業特有のニーズに合わせて調整され、競合他社でさえ同じ要件を持たない場合があります。
コンフィギュレーターを操作する顧客や営業スタッフに優れたユーザー体験を提供すること。コンフィギュレーターは、二度と現れないかもしれない製品の構成に対してオーダーメイドの注文をサポートする piece of software です。
販売された各ユニットは本質的にユニークです。再製造の状況と同様に、BOM は各構成に確率を割り当てる確率的視点から評価されなければなりません。しかし、再製造の場合と異なり、コンフィギュラブルBOMは通常、はるかに多くの制約があり、各制約は supply chain optimization プロセス内で活用できる情報となります。例えば、ワークステーションにおいて、どのコンポーネントが選択されても必ず一つ以上の電源アダプターが存在します。
コンフィギュラブルBOMが関与する供給チェーンでは、通常、オーダーメイドの数値モデルが必要とされます。なぜなら、time-seriesや、“クラシック”な供給チェーン最適化と呼ばれるほとんどのモデルは適用できないためです。

LokadのBOMに対する見解

一見、BOMはシンプルに見えます。しかし、その単純さは欺瞞的です。通常、BOMの管理は容易ですが（特に、常に複雑なコンフィギュラブルBOMを除く場合）、BOMが関与する際の在庫レベル、サービスレベル、リードタイム等の最適化は非常に困難になります。多くのソフトウェアベンダーはBOMをサポートしていると主張しますが、実際には BOMの管理 のみを提供しており、最適化 の面では何も提供していません。

モデリングの観点から、BOMはグラフであり、効率的に処理するためにはグラフ指向の機能やモジュールが必要です。Lokadはそのような供給チェーンの状況に対応するための独自機能を大幅に開発してきました。また、我々の見解では、BOMを含む供給チェーンの最適化は、多層ネットワーク最適化に向けた最初の論理的ステップとなります。