製品構成プロセスにおける重要なアクティビティは、BOMと呼ばれる部品表の作成です。従来の静的な製品の場合、BOMは製品に対して一度だけ作成され、保存され、再利用されます。
このBOMは、注文との関係では静的なものであり、例えば、事前に完全に準備され、特定の注文に対して変更されることはありません。考えられるすべての製品の組み合わせを事前に準備できるとします。この場合、静的なBOMは構成可能な製品にも使用することができます。ただし、本当の意味で構成されているとは言えません。構成プロセスでは、あらかじめ定義されたカタログから製品を選択します。
真に構成された製品の場合、製品のBOMは製品が構成された後に生成されます。このダイナミックBOMは、複雑さやシステムのセットアップに応じて、複数の方法で処理することができます。多くのシステムでは、可能なすべての構成に対して事前に定義された行を持つBOMである、いわゆるスーパーBOMしか使用できません。しかし、このブログでさらに説明するように、この作業方法はエンドツーエンドの製品構成には必ずしも実用的ではありません。プロセスのさまざまな関係者が、BOM構造に対して異なる要件を持っている可能性があります。
シームレスなエンド・ツー・エンドの構成を設定する際、重要な点の一つは、異なる目的のために製品構造を再構築する必要性を定義することです。エンジニアリングや製造などの異なる機能には、製品をある方法で構成するための異なるニーズや理由があります。これらのニーズは、通常、E-BOMS（Engineering Bill of Material）とM-BOM/P-BOM（Manufacturing or Production Bill of Material）と呼ばれる異なるBOMSの作成と保守につながります。これらのニーズや理由の中には、以下のリストにあるように、それほど強くないものもあります。しかし、バリューチェーン全体で同じ構造を持つことが不可能になるほど、これらのニーズや理由は多いのです。
動的なスーパーBOMが構成され、エンジニアリングと製造のために再構築されます。
それぞれの再構築作業には、メンテナンスと検証が必要な変換機能が必要です。
もちろん、BOMの再構築の必要性は、フロー内のシステム数の関数です（上の図を参照）。システムが1つしかない場合は、再構築の必要はありません。しかし、すべての機能のニーズを満たすには大きな課題があります。システムの数が増えれば、それぞれのニーズを満たすことが容易になりますが、その分、再構築が必要になります。
この質問は、製品構造が各下流のシステムでどのように作られるかについて言及しています。これには2つの明確に異なるアプローチ方法があります。
モジュラーBOMと呼ばれる1つ目の方法では、受け取る下流システムでは完全な構造が事前に準備されていません。受け取り側のシステムは、構造の中のアイテムだけを知っていますが、そのアイテムが構造の中でどのように配置されているかは知りません。つまり、断片は知っていても階層は知らないということです。
スーパーBOMとも呼ばれる2つ目の方法では、下流プロセスシステムで構造が事前に定義されます。下流プロセスシステムでは、事前にあるべき構造が定義されています。
モジュラーBOMは、スーパーBOMよりもマスターデータの構造が明確で、複数の構造を維持・更新する手間を省くことができます。製品構造の管理と更新は1か所で済みます。ただし、他にも考慮しなければならない点がいくつかあります。
お客様のシステムと必要な機能がそれを可能にするならば、モジュラーBOMアプローチは、時間の経過とともに最も低い総コストになる可能性が高いと思われます。しかし、システムや機能の要件によっては、この方法が使えない場合もあります。そのような場合、2番目に良い方法は、1つのシステムを製品構造のマスターとして使用し、すべての変更をそのシステムから転送することです。複数の構造を手動で更新して同期させようとすると、複数のシステムが適切に調整されていない場合、高い作業負荷と品質リスクが発生するため、お勧めできません。
まず、プロダクトマスターとは何を指すのでしょうか。
エンド・ツー・エンドのシームレスな製品構成は、場当たり的に行われるものではありません。各プロセスステップは、テンプレートに基づいて十分に準備されている必要があります。このテンプレートをプロダクトマスターと呼んでいます。
営業部門では、構成モデルを使用したコンフィグレータが、お客様の特定のニーズに合わせて独自のソリューションを提供することを目指す企業にとって、しばしば最適なソリューションとなります。真に構成された製品には、価格設定のためのマスターも必要です。収益管理をしっかり行いたいのであれば、原価計算用のマスターも必要になるでしょう。また、納期管理のためのマスターも必要になるかもしれません。これらの機能のほとんどは1つの構成で解決できますが、レガシーな機能や特殊な機能要件のために、すでに複数のシステムが使用されている場合があります。
また、エンジニアリングや製造業では、エンドツーエンドの製品構成をシームレスに行うために、複数のプロダクトマスターが必要になるのが一般的です。
先に述べたように、これらの間の統合を簡素化するために、できるだけ少ないシステムを使用するべきです。1つのシステムで解決できることが多ければ多いほど、統合の観点からは優れていると言えます。しかし、前述したように、レガシーで特殊な機能要件があると、複数の特殊なシステムが必要になることがよくあります。
エンド・ツー・エンドのシームレスな製品構成は、単にシステムをつなぐだけではありません。情報の流れの中では、異なるプロダクトマスターを接続することです。そして、すぐに多くのプロダクトマスターが必要であると結論付けます。これでは、構築するにも維持するにも、たくさんのモデルが必要である事に気付かされるはずです。
プラットフォームと機能のニーズに固有のプロダクトマスターを使用すると、
モデルの数が圧倒的に増える可能性があります。
しかし、プラットフォームや機能ごとに特定のマスターを用意する必要はないかもしれません。
まず、フロントエンドのセールスコンフィグレータでは、すべての「組換可能な」製品に対して1つのマスターだけを持つべきです。顧客や営業担当者としては、要求される性能のわずかな変化によってマスター1から2への切り替えが必要になったからといって、新しいコンフィグレータを放棄してまた最初からやり直すようなことは絶対に避けたいものです。
第二に、機能ごとのプロダクトマスターの数を最小限にすることを常に心がけるべきです。この最小化により、マスターの作成と維持にかかる労力が軽減され、システムの流れに沿った統合と同期が簡素化されます。真にモジュール化された製品は、製品アーキテクチャを調和させ、幅広い製品で部品の再利用を最適化することでこれを達成します。
理想的には、システムの次元（水平方向）と製品の次元（垂直方向）の両方で調和を図った後、将来のプロダクトマスターの設定は次のようになります。
システムと製品ディメンションのプロダクトマスターを調和させることで、
作成と保守の両方を簡素化できます。
最後に、以下をマージして、プロダクトマスターの数を最小限に抑えるようにすることをおすすめします。
会社の機能やシステムを水平方向に横断するもの
最終製品のより大きな範囲を垂直に横断するもの
このブログシリーズでは、「エンド・ツー・エンドの製品構成」シリーズの4回目となる最終章をお届けしました。重要なのは、フロントエンドで製品をどのように販売するかを決め、バックエンドのシステムとマッチさせて、効率的に作業を進めることです。バックエンドでは静的な製品を扱いながら、フロントエンドでは無制限のバリエーションを販売するというのは、失敗の元です。フレキシブルなフロントエンドと、エンドツーエンドのダイナミックなBOMをシームレスに処理できるように設定されたバックエンドをマッチさせることができれば、製品のバリエーションは真の競争力となります。
私がこのブログの執筆を楽しんだように、皆さまもブログをお楽しみいただけましたら幸いです。ご意見、ご感想などがありましたら、ぜひお寄せください。
弊社は過去数十年にわたり、世界中の企業が製品の構成やコンフィギュラビリティを向上させることに100％注力してきました。
お客様のお話を伺い、現在の状況からどのように改善できるかを議論したいと考えています。
ぜひお気軽にお問い合わせください。