Blog

モジュラーシステムの

最適なバリアント数について

By Tobias Martin 

オーバースペック仕様のモジュール部品の複雑さに起因するコストを、どのようにしたら削減できるのでしょうか

お客様の顧客は、製品の利用状況や好みに応じて製品のパフォーマンスや仕様に対するニーズが異なります。パフォーマンスに対するニーズと、これに対してどれくらい支払えるかというパラメータが、異なるパフォーマンスレベルと価格で製品を提供するビジネスをドライブしています。個々の顧客の好みに合わせてパフォーマンスを調整すると、製品ラインアップの中での差異が多くなり、複雑さに起因するコストが高くなります。

The cost of complexity increases with the number of variants offered提供されるバリアントの数に伴って複雑さのコストが増加

 

モジュラー化は、製品の性能特性を特定のモジュールに分離して持たせることで、製品の差異と複雑さのコストとの間の直接的な接続を断ち切ることができます。このようにして、他のバリエーションを作成することなく、この特定のモジュールのバリアント数を最適化することができます。

しかし、どのようにして必要なバリアント数を見つけることができるでしょうか?

複雑さに起因するコストの計算用テンプレート

重要な点は、企業がハードウェアの実際のパフォーマンスステップよりも多くのパフォーマンスレベルを販売することを決定する可能性を持っているということです。 顧客が求める性能を示すラベルを製品に貼付することで、ソフトウェア制御など内部に持った可能性を使用して、市販されているよりも高いパフォーマンスが可能な(一部の)コンポーネントまたはモジュールを備えた製品を販売することができます。 理論的には、少なくとも、製品の価格レベルは市場でのパフォーマンスに関係しています。 対照的に、コストレベルは、直接コストと複雑さのコストの組み合わせに関係しています。 内部の複雑さ(モジュールバリアントの数)を減らしながら、より多くの製品バリアントを市場に出すというこの概念は、オーバースペック(最小公倍仕様)と呼ばれ、コンポーネントまたはシステムは、特定の製品に実際に必要なものよりも高い仕様を持っています。

 

complexity 1 ラベルによるコントロールの例

 

オーバースペック(最小公倍仕様)は、固有のコンポーネントまたはモジュールバリアント(PNCまたは部品番号カウントと呼ばれることが多い)の数を減らすことにより、複雑さのコストを削減する方法です。 ただし、同時に、オーバースペックは直接材料費や直接労務費などの直接コストを増加させます。 この方式が有利な場合は、オーバースペックを選択することをお勧めします。

極端なケースとして、モジュールバリアントを1つだけ標準化するとします。これは最も要求の厳しい製品に応じて実行できる設計を使用するということを意味しています。これは同時に、他のすべての製品の材料費が必要以上に高くなることを意味します。モジュールバリアントを追加するたびに、パフォーマンスの低い製品バリアントの設計を最適化できるため、要求の 少ない 製品で代わりにこのモジュールバリアントを使用することができます。直接コストを概略的に見ると、モジュールバリアントの追加により、それぞれのバリアントのコストは減少する方向性が見られます。しかしながら最終的には、サプライヤの複雑なコストが加算され始め、最終的には原材料費で削減されたコストを上回り、購入した材料コストが再び上がり始める段階に達する可能性があります。バイヤーとサプライヤの関係におけるボリューム割引は多くの場合、このタイプのメカニズムに基づいています。

Direct cost is a function of the number of variants of a module.※直接コストは、モジュールのバリアント数に関連しています。バリアント数が増えるとボリュームディスカウントのメリットが失われるため、コストが右端で増加し始めることに注意してください

直接コストと複雑さのコストのバランスをとることは、複雑さを軽減するために節約されたコストに加えて、オーバースペック(最小公倍仕様)の直接コストの合計を探していることを意味します。 この時点で、設計の総コスト効果は最小限に抑えられます。

Picture2.2-1複雑さの合計コストと直接コストの合計として総コスト効果を最小限に抑えるために、バリアントの数のバランスを取ります

各コンポーネントに対して可能な限り最適化された各顧客の要求を満たすことは最適ではない可能性があり、進化した既存のコンポーネント範囲は理想的ではない可能性があります。これらを踏まえると、以下のような疑問が出てくるのではないでしょうか。

  • モジュールバリアントは何種類持つべきでしょうか?
  • どのような種類のモジュールバリアントを持つべきでしょうか?

これから、これらの質問に答えるために数学的アプローチについてご説明します。

 

モジュラー化、標準化、およびオーバースペック仕様

多くの企業は、標準化によって製品の品揃えの複雑さを軽減しようと取り組まれてきました。この標準化は、少量または利益率の低いと思われる製品バリアントを削除することを意味します。このようにしてスリム化された製品の品揃えは、より薄いカタログまたは同じカタログを意味し、すべてのバリエーションを持ち、時にはパフォーマンスを低下させるラベリング、ダンピング、またはソフトウェアを備えた高性能のバリエーションを持つものとして販売されています。私は最初の概念を標準化と呼び、2つ目の概念をオーバースペックと呼んでいます

製品の品揃えの標準化

標準化、別名「Cut the Tail」手法は、しばしばビジネスを傷つける可能性があります。絞り込まれた製品の品揃えは、カタログ上で一致する製品を見つけにくくなり、顧客が必要以上の性能(オーバースペック)を選択せざるを得なくなった場合はマイナスと見なされてしまいます。競合他社の提案の方が要求に適していれば、顧客はそちらに移ってしまうでしょう。Product Standardization and "Cut the tail"

製品のオーバースペック仕様 - パフォーマンスの向上

一方、製品レベルのオーバースペック仕様は、サプライヤが標準化のコストペナルティを受けるということです。これは、少量製品による心理的なコスト高許容によるマージンを押し下げる可能性があり、後にこれが標準化につながる可能性があります。このマージンの減少は、製品の意思決定における複雑さのコストを考慮するための知識や制御メカニズムがほとんどない場合に発生する可能性があります。最適化されていない製品は、バリューチェーン全体で複雑化コストを大幅に削減したとしても、収益性が低いと思われます。

モジュールレベルのオーバースペック仕様 - モジュラー化の力

一方、モジュラー化は、製品レベルからモジュールレベルに決定ポイントを押し下げます。この変更により、複雑性の低下に関する利点が追加された直接コストよりも高いモジュールを 1 つのモジュールに過剰に指定できます。原材料のコストが高い別のモジュールの場合、決定は反対にすることができます - 常にできるだけ少ない材料を使用し、例えば、パラメータ化または構成可能な設計によって、複雑さを処理するためのプロセスを最適化します。

私は今、これが直接材料コストとボリュームの関数で定義できる理由を示したいと思います。その効果は、少量製品は通常、モジュールレベルでのオーバースペック仕様の方が良いケースを持ち、最終製品レベルに近い製品は最適化されたモジュールバリアントを正当化する場合が多いということです。

 

モジュールの分散を最適化するための数学的モデリング

合計コストを複雑化コストと直接コストの合計としてバランスを取る関数を作成するには、次の関連関数を理解する必要があります。

  • 範囲全体のパフォーマンスの関数としての需要、すなわち、各バリアントのユニットをいくつ販売しますか?
  • パフォーマンスの関数としての直接コスト
  • 範囲内で設計および維持されるパフォーマンスステップの数の関数としての複雑さのコスト

各モジュールバリアントの需要のモデリング - 例

例を考えてみましょう:家電製品の多くの種類を作る会社。ハンドミキサーから大型冷凍庫、食器洗い機まで、多くのカテゴリーを考えると、家電製品の種類数が非常に多いケースです。各アプライアンスが過電流などから装置を保護するためにサージ保護を必要とし、サージプロテクタの仕様は、そのエネルギー定格(故障することなく所定の時間内にどれだけのエネルギーを消費できるか)によって記述されていると仮定します。サージプロテクタはオペレーショナルエクセレンスモジュール(コスト、供給などを重視するモジュール)であり、顧客価値をあまり生み出さない、安定した技術が知られており、製品バリアントやカテゴリー間で調和すれば、調達のスケール効果と組み立て中の簡素化された材料処理を活用することで利益を得ることができます。

アプライアンスのカテゴリの数を考えると、サージプロテクタのエネルギー定格が非常に多く使用できます。基本的には、100Jから2000Jまで、100Jのステップで準備されています。

各エネルギー評価を使用する製品を分析することで、各サイズの理論的需要の表を作成することができます。

Modeling demand of a module as a function of performanceモジュールバリアントの直接コストのモデリング

グローバルなオペレーションを持つ実際のケースでは、選択した品揃えと複数のサプライヤーに重複が存在する可能性があります 。これは、顧客価値の低い部分に対する大幅な複雑さのコストを促進する品揃えです。

 

モジュールバリアントの直接コストのモデリング

この例では、仕入先とは異なるモジュールバリアントの価格表があります。単位あたりの価格は、エネルギー評価に伴って増加しています。ただし、特定のバリアントで購入された 20ユニットごとにそのバリアントの価格に対して 1% の割引が適用されます。

Picture6モジュールバリアントのパフォーマンスステップ数の関数としての複雑化コストのモデル化

Complexity costs(複雑さがもたらすコスト)に関する私の以前のブログを参照すると、これらのコストは、少なくともビジネス、運用モデル、および製品の技術的な複雑さの規模の中で、バリアントの数に比例して増加すると定義づけています。

この例では、サージ プロテクタ モジュールの各追加バリアントが 3.000 USD の追加コストを押し上げると仮定します。

The annual cost of complexity is modeled as proportional to the number of module variants

複雑さの年間コストは、モジュールバリアントの数に比例してモデル化される

 

バリアント数の関数としての直接原価の計算

オーバースペックの適用が可能であると仮定すると、バリアント数の関数として、年間直接コストが何であるかを分析することができます。ここには複数のソリューションがあり、各ポイントに対して、可能な限り低い直接コストを見つけたいと考えています。バリアントを置く需要曲線の大量のポイントから遠く離れるほど、オーバー仕様のコストが高くなります。ボリュームを失わないには、すべてのケースで最大のバリアントを含める必要があります。バリアントの数ごとにこの最適な選択を見つけるには、さまざまな可能性をテストするか、計算することによって、何らかの最適化方法が必要です。

Picture8各バリアントの種類数の最適解を見つけるためには、さまざまな可能性をテストするか、計算することによって、最適化のいくつかの方法を行う必要がある

直接コストと複雑化のコストを追加して総コストを計算する

バリアントの数ごとに直接コストと複雑さのコストの合計を計算することで、総コストがどのように変化するかを把握できます。

Total cost of a function of number of Variants

この場合、4つのバリエーションで最適な値を見つけることにより、年間コストの約10%を節約できることを示しています。これは、すべてのサイズを使用する場合と比較すると、1つのサイズのみを使用する場合と比較して20%となっています。

総コスト関数を記述し、最適化を一般化することができます。

Optimization of complexity cost

 

結論: バリアント最適化は直接的なコストと複雑さのコストのバランスを取る

この例で示したように、モジュールの最適範囲のバリアントを見つけることは、直接のコストと複雑さのコストのバランスをとることの問題と置き換えることができます。このモデルは理論上のものであり、パフォーマンス(および顧客価値)がオーバースペック仕様によって悪影響を受けるかどうかなど、いくつかの重要な要素を考慮に入れることはありません。しかし、いずれにせよ、このような理論的なモデリングは、事実に基づく意思決定の意思決定モデルを設定する際に大きなメリットをもたらします。

このトピックの数十年の経験から学ぶことの1つは、万能のルートを行くことはめったに最適ではないということです。同時に、各ケースの最適化は、通常、ボリュームが非常に多い場合(少量のバリエーションがない場合)に適した選択肢です。

More Information

こののブログ記事に関係するその他のブログや動画をご紹介します。ぜひご確認ください。

ブログ

複雑さに起因するコストとは?- そのコストを計算する方法

動画

Part 1: From Pain to Profit - シェアと利益を両立する方法


モジュラーシステムを作成する方法については、ぜひこちらの資料もご覧ください。

MMJ Premium contents 5 steps to develop modular system Large CTA

 

Tobias Martin-1

著者

Tobias Martin

Vice President & Partner

 +46 8 456 35 00
 tobias.martin@modularmanagement.com

 

 

もっと知りたいですか?

このブログで取り上げたトピックについて話し合いたい場合や、モジュール性と戦略的製品アーキテクチャに関するフィードバックをご希望の場合は、以下の連絡先へご連絡お願いいたします。

 

モジュラー・マネジメント・ジャパン

info@modularmanagement.com