Blog

製品構成のプロダクトマスターとBOM構造

By Alex Ginsburg

はじめに

今回のブログは、「End to End Product Configuration」シリーズの第4章です。これまでの背景については、こちらでご覧ください。第1回目のブログはこちらから参照することができます:「エンド・ツー・エンドを考慮された製品コンフィグレーションとは?」、第2回目のブログはこちらです:「製品コンフィグレータはすべてのユーザーのためですか?」、第3回目のブログはこちらです:「エンドツーエンドの製品構成のためのエンタープライズアーキテクチャ」


コンフィグレーション可能な製品の部品表

製品構成プロセスにおける重要なアクティビティは、BOMと呼ばれる部品表の作成です。従来の静的な製品の場合、BOMは製品に対して一度だけ作成され、保存され、再利用されます。

このBOMは、注文との関係では静的なものであり、例えば、事前に完全に準備され、特定の注文に対して変更されることはありません。考えられるすべての製品の組み合わせを事前に準備できるとします。この場合、静的なBOMは構成可能な製品にも使用することができます。ただし、本当の意味で構成されているとは言えません。構成プロセスでは、あらかじめ定義されたカタログから製品を選択します。

真に構成された製品の場合、製品のBOMは製品が構成された後に生成されます。このダイナミックBOMは、複雑さやシステムのセットアップに応じて、複数の方法で処理することができます。多くのシステムでは、可能なすべての構成に対して事前に定義された行を持つBOMである、いわゆるスーパーBOMしか使用できません。しかし、このブログでさらに説明するように、この作業方法はエンドツーエンドの製品構成には必ずしも実用的ではありません。プロセスのさまざまな関係者が、BOM構造に対して異なる要件を持っている可能性があります。 

ete 4-1ver.02コンフィグレーション可能な製品のBOMを生成するさまざまな方法

BOM再構築の必要性

 シームレスなエンド・ツー・エンドの構成を設定する際、重要な点の一つは、異なる目的のために製品構造を再構築する必要性を定義することです。エンジニアリングや製造などの異なる機能には、製品をある方法で構成するための異なるニーズや理由があります。これらのニーズは、通常、E-BOMS(Engineering Bill of Material)とM-BOM/P-BOM(Manufacturing or Production Bill of Material)と呼ばれる異なるBOMSの作成と保守につながります。これらのニーズや理由の中には、以下のリストにあるように、それほど強くないものもあります。しかし、バリューチェーン全体で同じ構造を持つことが不可能になるほど、これらのニーズや理由は多いのです。

  •  コンフィグレータには、論理的につながったもの、つまり、存在するもの、存在しないもの、同じ理由で変化するものがグループ化され、グループとして一緒にオン・オフや変更が行われる論理的な構造が必要です。
  • エンジニアリングには、専門家チームが機能的なシステムやサブシステムを開発し、部品同士の衝突をなくし、組み立て、メンテナンス、サービスの作業を設計によって可能にするような、機能的または配置的な構造が必要です。
  • 製造およびサプライチェーンには、サプライチェーンの設定方法を反映したフロー指向の構造が必要です。各購入品や、メインの組立フローの外にある製造品や予備組立品には、特定のアイテム(部品や組立品)があります。このようにして、購買、および内部の生産オーダーが作成され、実行が行われたことが報告されます。

ete 4-2 ver02 ll

ete 4-3

動的なスーパーBOMが構成され、エンジニアリングと製造のために再構築されます。

それぞれの再構築作業には、メンテナンスと検証が必要な変換機能が必要です。

 

もちろん、BOMの再構築の必要性は、フロー内のシステム数の関数です(上の図を参照)。システムが1つしかない場合は、再構築の必要はありません。しかし、すべての機能のニーズを満たすには大きな課題があります。システムの数が増えれば、それぞれのニーズを満たすことが容易になりますが、その分、再構築が必要になります。

Dynamic BOM: モジュラー型 or 事前定義構成型?

この質問は、製品構造が各下流のシステムでどのように作られるかについて言及しています。これには2つの明確に異なるアプローチ方法があります。

モジュラーBOMと呼ばれる1つ目の方法では、受け取る下流システムでは完全な構造が事前に準備されていません。受け取り側のシステムは、構造の中のアイテムだけを知っていますが、そのアイテムが構造の中でどのように配置されているかは知りません。つまり、断片は知っていても階層は知らないということです。

ete 4-4

ete 4-5

スーパーBOMとも呼ばれる2つ目の方法では、下流プロセスシステムで構造が事前に定義されます。下流プロセスシステムでは、事前にあるべき構造が定義されています。

ete 4-6

ete 4-7

モジュラーBOMは、スーパーBOMよりもマスターデータの構造が明確で、複数の構造を維持・更新する手間を省くことができます。製品構造の管理と更新は1か所で済みます。ただし、他にも考慮しなければならない点がいくつかあります。

  • ほとんどの場合、モジュラー構造は、システム間の統合を開発するためのコストが高くなります。これは特に、Modular BOMを扱うための準備ができていないシステムに当てはまります。
  • 下流プロセスシステムの一部の機能では、製品構造にマッピングされたCADオブジェクトなど、事前に製品構造の知識を必要とする場合があります。
  • 再構築の必要性も重要です。
    • モジュラー方式では、再構成は2つのシステムの統合の中では起こりません。2つのシステムのうちの1つ、通常は上流のシステムの内部で行われなければなりません。上流のシステムは、その構造を管理し、下流のシステムで再構築された第2の階層を管理する能力を持っていなければなりません。
    • 事前に定義された構造を持つ上流のシステムとは異なる構造を下流のシステムで持つことが可能です。システム間の統合により、下流のシステムでは適切なアイテムが適切な場所に配置されます。

お客様のシステムと必要な機能がそれを可能にするならば、モジュラーBOMアプローチは、時間の経過とともに最も低い総コストになる可能性が高いと思われます。しかし、システムや機能の要件によっては、この方法が使えない場合もあります。そのような場合、2番目に良い方法は、1つのシステムを製品構造のマスターとして使用し、すべての変更をそのシステムから転送することです。複数の構造を手動で更新して同期させようとすると、複数のシステムが適切に調整されていない場合、高い作業負荷と品質リスクが発生するため、お勧めできません。

プロダクトマスターを整理する方法

まず、プロダクトマスターとは何を指すのでしょうか。
エンド・ツー・エンドのシームレスな製品構成は、場当たり的に行われるものではありません。各プロセスステップは、テンプレートに基づいて十分に準備されている必要があります。このテンプレートをプロダクトマスターと呼んでいます。

営業部門では、構成モデルを使用したコンフィグレータが、お客様の特定のニーズに合わせて独自のソリューションを提供することを目指す企業にとって、しばしば最適なソリューションとなります。真に構成された製品には、価格設定のためのマスターも必要です。収益管理をしっかり行いたいのであれば、原価計算用のマスターも必要になるでしょう。また、納期管理のためのマスターも必要になるかもしれません。これらの機能のほとんどは1つの構成で解決できますが、レガシーな機能や特殊な機能要件のために、すでに複数のシステムが使用されている場合があります。

また、エンジニアリングや製造業では、エンドツーエンドの製品構成をシームレスに行うために、複数のプロダクトマスターが必要になるのが一般的です。

先に述べたように、これらの間の統合を簡素化するために、できるだけ少ないシステムを使用するべきです。1つのシステムで解決できることが多ければ多いほど、統合の観点からは優れていると言えます。しかし、前述したように、レガシーで特殊な機能要件があると、複数の特殊なシステムが必要になることがよくあります。

エンド・ツー・エンドのシームレスな製品構成は、単にシステムをつなぐだけではありません。情報の流れの中では、異なるプロダクトマスターを接続することです。そして、すぐに多くのプロダクトマスターが必要であると結論付けます。これでは、構築するにも維持するにも、たくさんのモデルが必要である事に気付かされるはずです。

ete 4-8

プラットフォームと機能のニーズに固有のプロダクトマスターを使用すると、

モデルの数が圧倒的に増える可能性があります。

 

しかし、プラットフォームや機能ごとに特定のマスターを用意する必要はないかもしれません。

まず、フロントエンドのセールスコンフィグレータでは、すべての「組換可能な」製品に対して1つのマスターだけを持つべきです。顧客や営業担当者としては、要求される性能のわずかな変化によってマスター1から2への切り替えが必要になったからといって、新しいコンフィグレータを放棄してまた最初からやり直すようなことは絶対に避けたいものです。

第二に、機能ごとのプロダクトマスターの数を最小限にすることを常に心がけるべきです。この最小化により、マスターの作成と維持にかかる労力が軽減され、システムの流れに沿った統合と同期が簡素化されます。真にモジュール化された製品は、製品アーキテクチャを調和させ、幅広い製品で部品の再利用を最適化することでこれを達成します。

理想的には、システムの次元(水平方向)と製品の次元(垂直方向)の両方で調和を図った後、将来のプロダクトマスターの設定は次のようになります。

ete 4-9

システムと製品ディメンションのプロダクトマスターを調和させることで、

作成と保守の両方を簡素化できます。

 

最後に、以下をマージして、プロダクトマスターの数を最小限に抑えるようにすることをおすすめします。

  • 会社の機能やシステムを水平方向に横断するもの

  • 最終製品のより大きな範囲を垂直に横断するもの

エンド・ツー・エンドの製品コンフィグレーションを成功させるためには、バックエンドがフロントエンドと一致している必要があります

このブログシリーズでは、「エンド・ツー・エンドの製品構成」シリーズの4回目となる最終章をお届けしました。重要なのは、フロントエンドで製品をどのように販売するかを決め、バックエンドのシステムとマッチさせて、効率的に作業を進めることです。バックエンドでは静的な製品を扱いながら、フロントエンドでは無制限のバリエーションを販売するというのは、失敗の元です。フレキシブルなフロントエンドと、エンドツーエンドのダイナミックなBOMをシームレスに処理できるように設定されたバックエンドをマッチさせることができれば、製品のバリエーションは真の競争力となります。

私がこのブログの執筆を楽しんだように、皆さまもブログをお楽しみいただけましたら幸いです。ご意見、ご感想などがありましたら、ぜひお寄せください。

製品コンフィグレーションの方法についてのご相談

弊社は過去数十年にわたり、世界中の企業が製品の構成やコンフィギュラビリティを向上させることに100%注力してきました。

お客様のお話を伺い、現在の状況からどのように改善できるかを議論したいと考えています。

ぜひお気軽にお問い合わせください。