購入に至るシナリオは画一的ではありません

購入を考えている方は、製品の購入を検討する際に、柔軟性、価格、入手のしやすさなど、さまざまなニーズや期待を持っています。それに基づいて、購入者はこれらの期待に応えることができる販売者を探します。それは、標準的な製品を販売する販売者であるかもしれないし、ビルディングブロックのカスタムコンビネーションを構成する販売者であるかもしれないし、個々の顧客に合わせて製品を作る販売者であるかもしれません。

商品を購入する最も分かりやすい方法は、小売店に足を運び、棚から商品を選んだり、店員に選んでもらったり、選んでもらったりすることかもしれません。それが現在では、Webページが棚の代わりとなり、倉庫でオーダーピッキングが行われ、物流サービスが商品を配送するオンラインショッピングへと徐々に移行しています。商品のデザインからお客様が購入するまでのプロセスをイラストで説明すると、下図のようになります。完成品の数量やバリエーションによって、在庫品を作る場合と受注品を作る場合があります。いずれにしても、市場のニーズを予測して規格化された製品でなければなりません。

既製品（量産品）ベースの販売プロセス

個々の製品をお客様のニーズにより適合させるために、代わりにコンフィグレーション可能（構成可能）な製品を提示する企業もあります。お客様は、自分のニーズや必要な仕様を説明したり、好みの部品を選んだりして、カスタマイズされた製品を構成します。製品が個々のお客様向けにカスタマイズされているとはいえ、それらを構築するためのモジュールは、従来の小売製品のようにあらかじめ用意されています。つまり、倉庫とお客さまの間に、最終的な組み立ての段階を設けるということです。このようにして、お客様は、工業化された製品の利点（短納期、高品質、高いコスト効率）を享受しつつ、オーダーメイド製品の利点も得ることができます。同じイラストを使って表現すると下図のようになります。

コンフィグレーションベースのプロセス

B2CよりもB2Bでよく見られるような、よりカスタマイズが必要な製品では、特定のお客様のために製品を完全にカスタマイズしています。例えば、ビルの建設では、建築家がお客様のニーズと敷地の潜在的なメリットの両方に合わせてビルを設計します。建築家が設計を終えると、エンジニアが構造部品の技術的なソリューションを選択し、プロジェクトの特定のニーズに合わせて寸法を調整します。伝統的な建設プロセスは、最大限のカスタマイズに対応できるように設定されていますが、同時に、納期、品質、コスト効率といった産業上のメリットを得るための課題も抱えています。もう一度、同じイラストを使ってこのプロセスを表現すると次のイラスト図のようになります。

フロントエンドとバックエンドの分離

上記の3つの例の企業は、製品プラットフォームを利用することで大きなメリットを得ることができます。しかし、市場に対するアプローチが大きく異なるため、製品プラットフォームのメリットや使い方が異なる可能性があります。なぜ3つの例の企業が製品プラットフォームや製品コンフィグレーションを利用できるのかを説明するために、オペレーティング・モデルをフロントエンド部分とバックエンド部分に分けて説明します。

エンド・ツー・エンドの製品構成は、誰にとっても同じ意味を持つわけではありません。製品の状況と種類に応じて、さまざまな解決レベルとソリューションを適用する必要があります。企業が製品の品揃えを運用する方法は、フロントエンドとバックエンドの運用モデルを見ることで説明できます。

フロントエンド： 品揃えをどのようにしてお客様に提示し、販売するか。
バックエンド： R&Dとエンジニアリングでは、どのように品揃えを準備するのか。より具体的には、個々の注文ごとに異なるBOM（Bill of Materials）をどのように作成しているか。

フロントエンドでは、先ほどの例に倣って、3つの主要なオペレーション・モデルがあります。

バックエンドには、注文を受ける前にBOMを作成し、それを繰り返すのか、それとも注文ごとに個別に構築するのかによって、主に2つのオペレーションモデルがあります。この2つのグループの下に、実際のバックエンドのオペレーションモデルが6つありますが、これらについては後述します。

フロントエンドとバックエンドは強く結びついているので、特定の組み合わせではうまくいくが、他の組み合わせでは確実にうまくいかないことがあると言われています。

Front-end フロントエンド製品の品揃え オペレーションモデル

現実は白黒はっきりしないものですが、エンド・ツー・エンドの製品構成におけるさまざまな前提条件、機会、困難さを示す良いモデルとなっています。多くの企業が1つの製品群に対して様々なオペレーティング・モードを組み合わせて適用していますが、一般的にはどちらかのオペレーティング・モデルが強く支配しています。私たちはまず、製品ベースとプロジェクトベースの両サイドのケースから考察をしていきます。

Front-end（量産生産: 製品ベース）

製品ベースは、各製品のバリエーションが完全に事前に定義され、それを繰り返し販売するもので、最もよく使われるアプローチです。

• 白物家電などの小型で大量生産される製品
• 生命維持を目的とした医療機器など、独自の製品バリデーションや認証が必要な機器（認証が複雑で厳格なので事前認証が必要）。

エンド・ツー・エンドの製品コンフィグレーションという観点からすると、製品ベースのアプローチには明らかな利点があります。注文の時点では、組合せなどの実際の設定は行われません。すべての製品のバリエーションの中から最適なものを探します。ベストマッチを選択した後、製品識別子（製品型番やSKU（Stock Keeping Unit））を使用して、すべての関連情報を見つけます。選択に関連する情報には、製品仕様書、EBOM（Engineering Bill of Material）、MBOM（Manufacturing Bill of Material）などがあります。

しかし、製品ベースのアプローチには大きな限界と欠点もあります。

まず、お客様が新しい組み合わせを求めても、それに対応する製品バリエーションが見つからない事があります。多くのお客様のニーズには、おおよそのマッチングしかできません。完璧にマッチすることはめったにありません。第二に、新しい製品バリエーションを導入するには、GO/NOの決定プロセスと必要な情報の完成のために、リードタイムとコストがかかります。第三に、各製品バリエーションが個別に定義され、文書化されているため、それを維持・更新しなければなりません。これらの制限により、製品の複雑さが増し、製品の品揃えが増えれば増えるほど、複雑さの負担が重くなります。最後に、製品ベースのアプローチでは、製品のカタログに価値を付加しない焦点を当て、段階的な新製品導入/旧製品廃止の判断を難しくし、生産における不必要な切り替えを行い、すべてをバッチで生産することになります。したがって、製品ベースのアプローチは、戦略に基づいているか、低価格と短納期に対する市場の期待が非常に高いかなど、品揃えラインアップ規模が限られている製品にのみ使用すべきです。

Front-end: プロジェクトベース（受注生産）

プロジェクトベースとは、製品ベースとは逆の意味です。受注のための必要な情報のごく一部だけが事前に検討され準備されています。個々の販売案件や製品納入のための情報のほとんどは、プロジェクトとして組織された販売およびプロジェクトエンジニアリングの段階で作成されます。この運用モデルは、EtO（Engineer to Order）とも呼ばれ、ビルやプラント、船舶、大型で少量生産の重機など、スケール大きな製品によく用いられます。プロジェクトベースのアプローチは、大規模な製品を多種多様に提供できるようにするために使用され、しばしばケースバイケースのテーラーリングが適用されます。

このようなアプローチをとる理由は、必要なすべてのバリエーションや組み合わせを設計して製品ラインアップを完成させることは、あまりにも困難で、コストがかかると考えられているからです。その代わり、基本的なデザインやサプライチェーンの検討作業は、製品開発段階で事前に行われますが、細部を含めたほとんどの作業は、引合い時やプロジェクト仕様確認打合せにおいて、お客様とサプライヤーが対話をしながら要求される製品のバリエーションを定義し、完了させようとしています。

エンド・ツー・エンドの製品構成という観点から見ると、プロジェクトベースは最も困難なアプローチといえます。なぜなら、その無限の柔軟性のために、顧客仕様書、見積書、製品設計、製造、購買情報を完成させ、検証するための多くの手作業が必要だからです。

このアプローチでは、売れないかもしれない製品を開発するという「不必要な」先行製品開発を省くことができますが、品質が安定せず、納期も長く、バリューチェーン全体で高い直接・間接コストが発生すると思われます。

Front-end: コンフィグレーションベース

最後に、コンフィグレーションベースのアプローチについて洞察します。これは、すべての販売事例や注文に対して、事前に定義されたモジュールのユニークな組み合わせを作成することを意味します。このアプローチは、過去数十年にわたって自動車業界で頻繁に使用され、他の業界にも影響を与えてきました。コンピュータ業界では、Dellなどの企業が、構成済み製品のオンライン販売の先駆者となっているのがその好例です。

ある組合せは、過去に作られた構成である可能性はありますが、基本的に、新しい組み合わせを効率的に作るためのオペレーティング・モデルとプロセスが設定されているため、問題になりません。過去の納入品の中から一致するものを探すのではなく、それぞれの構成が唯一無二のものとして扱われるため、プロセスが統一され、品質・納期・コストのばらつきが最小限に抑えられるというメリットがあります。また、常に最新の製品モデルマスターを使用する必要があるため、旧式の仕様、デザイン、アイテム、ルーティングなどをコピーして再利用するリスクを回避することができます。

ここで重要なことは、コンフィグレーションベースのアプローチとは、必ずしも営業がCPQ（Configure, Price, Quote）を使ってソリューションや顧客への提案を行うことを意味しないということです。つまり、製品設計とプロセスは、注文ごとにあらかじめ定義された部品から独自の組み合わせを作り出すように構築されているということです。コンフィグレーションベースのアプローチを成功させるには、製品とプロセスをそれに合わせて設計する必要があります。フロントエンドのCPQソリューションはもちろん重要な要素ですが、それ以上に重要なのはバックエンドのサポートです。製品がモジュラーデザインで、個々のモジュールを交換してさまざまな顧客の要求に応えることができ、バリューチェーン全体が毎回新しい組み合わせを効率的に作成して提供するように設定されていることです。

コンフィグレーションベースのアプローチでは、製品アーキテクチャをライフタイムで管理するために、製品ベースよりも複雑なシステムセットアップが必要になるかもしれませんが、いったんそれが確立されれば、非常に幅広く機動的な品揃えが可能になり、長期にわたって効率的に管理することができます。

さらに、アジャイルな開発による組合せ品揃えができれば、アップデートや新しい機能、特徴、性能レベルを、すべての製品ラインアップに迅速に導入し顧客に提供することができます。

Back-end バックエンドでの商品品揃え オペレーションモデル

すでに述べたように、バックエンドでの最初のオペレーションモデルは、製品がアップデートされるか廃番になるまで繰り返し使用ができる固定の部品表を作成することです。第2の主要なバックエンド・オペレーティング・モデルは、注文や納品のたびに新しい部品表を追加作成することになります。

それぞれのバックエンドオペレーションモデルごとに、どのように標準BOMとカスタムBOMが作成されるかについて説明をしていきたいと思います。

Back-end: Copy-paste-change standard product  標準製品のコピー＆ペーストと変更で固定BOMを使い回す

新製品のバリエーション（SKU）の開発は、通常、最も類似した現行製品から始めて、新製品とそのBOMに到達するために必要な部品を追加、削除、変更することで行われます。時には、全く新しい製品を作る必要がある場合もあるかもしれません。しかし、その後、製品レンジを拡大するための新製品のバリエーションは、最も類似した製品をコピーして変更することで再び作成されることになります。

標準品をコピーペーストと設計変更を行い固定BOMを使いまわす

このオペレーションモデルは、最終製品のバリエーションの数が限られている、規模の小さな製品群に対してのみうまく機能するでしょう。しかし、カバレージが大きくなり、品揃えが増えてくると、製品間の調和が取れなくなるため、このオペレーションモデルは機能しなくなります。

ほとんどの製品は同じオリジナルソースから派生しているので、設計思想などの背景情報の同期がとれているはずだと思うかもしれません。しかし、それぞれの派生のコピーペーストと設計変更の操作は独立しており、各製品は独立して管理されているので、これらの同期は取れていないかもしれません。

R&D、エンジニアリング、そしてすべての下流工程部門は、同期・調和のとれていない製品構造や部品の共通性の欠如に悩まされることになります。新製品の開発、製品の保守、すべての部品の調達、すべての製品バリエーションの生産に関連する困難さと複雑なコストは、製品ポートフォリオが大きくなればなるほど指数関数的に増大することになります。

Back-end: Repeat Fixed BOM by Platform Based Standard Product プラットフォームベースの標準製品による固定BOMの使いまわし

多くの企業は、幅広い製品の品揃えが必要であると同時に、研究開発やサプライチェーンにおいてスケールメリットによる利益を得るために、製品構造を調和させ、部品の共通化を図る必要があることに気づいています。

この考え方では、独立した個別の製品を開発するのではなく、製品プラットフォームを開発し、そこからさまざまな製品を生み出すことができます。各プラットフォームは、交換可能な部品の集合体と製品構造テンプレートで構成されており、この2つの資産を用いて、製品構造テンプレートに組み込まれた部品の新しい組み合わせにより、新しい製品バリエーションを作成します。最終的には、各製品バリエーション（SKU）は固定BOMタイプで仕様構造が書かれていることになります。

競争力を維持するためには、新しい機能や特徴、性能レベルが求められることがよくあります。既存の部品を改造したり、互換性のある部品を新たに開発したりして、インターフェースを維持すれば、多くの新製品のバリエーションを生み出すことができます。しかし、新しい要求や新しい技術が既存のプラットフォームでは吸収できず、新しいプラットフォームをゼロから、あるいは既存のプラットフォーム（の一部）を発展させて開発しなければならないこともあります。

製品プラットフォームをベースにした新しい固定SKUの作成

製品プラットフォームという言葉は曖昧で、標準化されたシャーシとそれ以外のパーツが製品ごとに異なるものから、すべてのインターフェースが標準化され、パーツの交換が可能な完全なモジュラー型の製品プラットフォームまで、さまざまな意味で使われていることに注意が必要です。前者の場合、シャーシにのみプラットフォームの利点があり、他のすべての部品にはプラットフォームの利点がないかもしれません。

最後に、プラットフォームベースであっても、標準的な製品のカタログを作成して維持することについての3つの主要なデメリットの認識の必要性について述べます。

• 品揃えを維持するためのコスト。常に増え続けるリュックサックのような製品を維持する必要があるからです。新しい機能が追加されただけですぐに増えてしまう
• カタログ以外の製品を提供する柔軟性がない。
• 新製品のTTM（Time-to-Market）が比較的長い。ほとんどの場合、コピーペーストで変更した同業他社よりも早くできたとしても、追加されたSKUのためにすべてのドキュメントを完成させ、すべてのリリース手続きを行う必要があります。

Back-end: Create new BOM by Start-From-Blank 白紙の状態から新規BOMを作成

Start-from-blank（白紙の状態から）とは、毎回の受注開始時に紙面が基本的に空っぽであることを意味します。あまり好ましいオペレーティング・モデルではありませんが、建設業界をはじめ、周辺環境、製品、設計・エンジニアリングチーム、サプライチェーンのセットアップ、組み立て組織など、ほとんどがケースバイケースで作成される業界では頻繁に使用されています。

エンド・ツー・エンドの製品コンフィグレーションの観点からすると、このオペレーションモードは互換性がないため、これ以上コメントすることはありません。セカンダリーバックエンドとなる製造の工程モデルを変更する気がないのであれば、限定的な部品に関するな設定はできるかもしれませんが、製品の主要部分を設定することはできません。

Back-end: Create new BOM by Copy-Paste-Change Historic Delivery 過去に納品した製品のコピーペースト編集による新しいBOM定義

この運用モデルでは、過去の納入実績のすべてを検索し、最適なものを探します。稀に幸運なケースとして、エンジニアリングを必要とせずにそのままコピーできる完璧な一致があるかもしれません。しかし、一般的には、エンジニアリングが必要な、いわゆるETO(Engineering to Order)です。過去の納入実績を検索するツールがあるかもしれませんが、ほとんどの場合、ベストマッチを見つけるには個人の知識に頼ることになります。なぜなら、ベストマッチとは、最も類似した仕様とは限らないからです。また、納品した時期要素も重要です。というのも、納品後に設計仕様や製造・調達工程の変更があった場合、古い部品が多く含まれる製品をコピーしたくはないからです。

過去に納入した製品（案件）をコピー・ペースト・変更して新規BOMを作成

この運用モデルは、標準製品のコピー＆ペーストと変更で固定BOMを使い回す「Copy-paste-change standard product」のバックエンド工程と似ていますが、大きな違いがあります。標準製品のバックエンドでは、これらは常に最新の状態に保たれ、すぐに注文を受け入れる状態になっていると考えられます。過去の納入品をコピーする場合、これらは更新されていないと考えられ、実際には、その後発覚した課題を修正されているにもかかわらず、旧式の部品をコピーするリスクがあります。

フロントエンド（営業）の観点から見ると、過去に納品された製品をコピーすることは、通常、どれだけマッチするかが事前にわからないはずです。

• 手動で調整ができる程度の近似的な一致であるかどうか
• 過去の製造物は、現在の仕様や製造環境に対して、その適用性を分析する必要があるかどうか（サプライヤーの変更、旧式のコンポーネント、品質の修正）

これでは、セールスプロセスが非常に属人的なものになり、ツールでサポートすることは困難となります。

また、お客様の要求に変更があった場合には、その影響を把握するために結果分析を行う必要があります。その結果、過去の重要な納品物のコピーを変更しなければならなくなることもあります。一見小さな変更が、製品、価格、納入条件に大きな影響を与えることになれば、お客様にも社内にもフラストレーションが溜まります。

このオペレーションモデルは、エンド・ツー・エンドの製品コンフィグレーションとは多かれ少なかれ相容れないものでもあります。仕様の順守と部品の経年変化や陳腐化のバランスを取るためのアルゴリズムを適用して、ベストマッチを見つけるためのツールを導入することができます。しかし、新しい注文と過去のエンド・ツー・エンド間の技術的な影響の理解を自動化したり、真に合理化することは難しいと思われます。

Back-end: Create new BOM by Incomplete Platforms半完成プラットフォームによる新規BOMの作成

「白紙の状態から新規BOMを作成」や「伝統的な製造方法であるコピーペースト編集による新しいBOM定義」のデメリットを克服するために、製品のコア部分は安定させつつも、その他の部分は個々のケースに合わせて柔軟に対応できるようにしている企業もあります。

• 環境の変化への適応
• さまざまなスコープ変化への対応（ターンキーな製品では無理）
• 技術的な知識が豊富で、実際のソリューションに対して強い意見をお持ちのお客様
• ローカルまたはその他の特定の規制や規範への対応が可能

製品のコアとなるのは、柔軟性と保守性に優れたモジュラー方式の製品プラットフォームであり、そこから様々な異なる納品物を生み出すことができます。製品プラットフォームは、周辺部品からの影響を受けないようにされていなければなりません。たとえば、さまざまなレイアウトなど、必要なすべてのバリエーションは、柔軟な製品プラットフォームによって可能となるようにセットされている必要があります。 最後に、コア製品は通常、常に必須の納品範囲に含まれている必要があります。

「半完成プラットフォーム」を使ったオペレーションモデルでは、白紙の状態から始めたり、過去の納入品をコピーしたりする場合に比べて、製品プラットフォームの開発と管理に労力がかかります。しかし、このような投資を行った後の中核製品は、製品の構造や部品が再現可能な安定した製品プラットフォームであり、品質の安定化、納期の短縮、バリューチェーン全体の効率とコストの改善につながります。プロジェクトベースの企業の中には、製品の性質や市場の期待から、「半完成プラットフォーム」がバックエンドで達成可能な最高レベルの目標となっているところもあります。

しかし、納品の際のケースバイケースのテーラーメイド部分に関する課題が残っています。ここでは、品質、納期、効率の問題が依然として存在し、規模が小さくなっても、プロセスのばらつき、難しい価格設定、マージンの低下に悩まされることになります。

Back-end: Create new BOM by Complete Platforms コンプリートプラットフォームによる新規BOM作成

最高の目標レベルでは、製品のすべてのパーツが柔軟なモジュラー製品プラットフォームに含まれています。これは、カスタマイズされた製品のフロントエンドからバックエンドまで、エンド・ツー・エンドでシームレスに製品を構成するために必要な状態です。

プラットフォームベースの標準製品と同様に、全体像を把握し、プラットフォーム間の調和を図ることが必要です。時間が経つにつれて、プラットフォームが多すぎて、プラットフォーム間の調和が取れていないという状況になるのが一般的です。製品の構造が異なり、プラットフォーム間で共通または交換可能な部品が少なすぎるのです。

フロントエンドとバックエンドの融合

エンド・ツー・エンドの製品コンフィグレーション、特にシステムをエンド・ツー・エンドで統合してシームレスにする場合には、フロントエンドとバックエンドは密接に結びついています。フロントエンドとバックエンドの組み合わせと、それぞれの組み合わせにおける代表的な欠点や注意すべき点をナビゲーターとしてまとめました。

すべての企業が製品コンフィグレーションと製品プラットフォームの充実による恩恵を受けることができます

標準化された製品を作っているか、特定の要求に向けて製品をコンフィグレーションしているか、あるいはプロジェクトとして受注しているかにかかわらず、製品プラットフォームと製品コンフィグレーションを考慮して、現在の状況を把握し、そこからどのように改善できるかを理解することで、大きな利益を得ることができます。

ある人は、フロントエンドのアプローチを変更したり、別のブランドやチャネルを追加してフロントエンドのアプローチを追加することで、親しみやすい市場が増え、製品に対する評価が高まるという発見があるかもしれません。また、フロントエンドはきちんとやっているが、バックエンドのオペレーションがフロントエンドと一致していないため、製品レベルでの維持やレガシーが非常に複雑になっているという人もいます。また、身軽な新たな競合他社に追い越されてしまうこともあります。

もちろん、すでにフロントエンドとバックエンドが一致しているという企業もあるでしょう。ほとんどの企業は、プラットフォームを統合・統一してさらなるレバレッジとスケールを生み出したり、製品の開発・管理・販売のためのより効率的なシステムやプロセスのサポートを追加したりすることで、改善を図ることができます。

次回のブログエンド・ツー・エンドの製品構成を実現するエンタープライズ・アーキテクチャでは、最も一般的なアプローチにおける中核的なニーズと関連するシステムの概要を紹介したいと思います。

製品コンフィグレーションについてお問い合わせください

弊社は過去数十年にわたり、世界中の企業が製品の構成やコンフィギュラビリティを向上させることに100％注力してきました。お客様のお話を伺い、現在の状況からどのように改善できるかを議論したいと考えています。

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