前回のブログ「製品コンフィグレータはすべてのユーザーのためですか？」では、コンフィグレーション可能な製品を効率的に活用するためには、フロントエンドとバックエンドのオペレーティングモデルを整合させることが重要であると説明しました。
フロントエンドとバックエンドの整合性が取れていれば、エンド・ツー・エンドの構成を可能にするITシステムを構築することができます。
ここでは、製造業の3つの基本機能（セールス＆マーケティング、エンジニアリング、サプライ＆プロダクション）と、それらが利用するエンド・ツー・エンド・コンフィグレーションの中核となるITシステムのそれぞれ（CRM＆CPQ／コンフィグレータ、CAD＆PLM、ERP）について簡単に説明します。
エンド・ツー・エンドで製品を構成するためには、さまざまなITシステムのセットアップが考えられます。このブログでは、最も一般的なアプローチについて、コアとなるニーズと関連するシステムの概要を説明します。
まず、当たり前のように見える2つの基本的な前提条件があります。しかし、社内の各機能やシステムがサイロ化しているため、大きな問題となっています。
会社のすべての機能を網羅する確固たるマスターデータのアプローチを持つ明確なデータモデル（またはインフォメーションアーキテクチャ）が必要です。各インフォメーションデータセットは、1つのシステムだけが「オーナー」であり、1つのシステムだけが各インフォメーションデータセットを編集（追加、削除、変更）できるようにする必要があります。他のシステムは、このインフォメーションデータセットの読み取り専用であるスレーブ状態とすべきです。同じデータを複数のシステムで編集可能にする必要がある場合は、システム用の共有データベースを使用することで、優れたマスターデータの設定を放棄することなく、複数のシステムからの編集を可能にすることができます。
製品バリエーションの在り方についての統一された方針は、企業のそれぞれの組織での品揃えの説明や扱い方の違いにより、意外にも欠けていることが多いと言われています。製品バリエーションは、顧客や販売の視点から見たパフォーマンスレベル、機能、特徴によって表現されるべきです。弊社はこれらを製品プロパティ(Product Property)と呼んでいます。各製品プロパティには1つまたは複数の目標値があります。しかし、BOM（部品表）や実装の観点からは、部品の追加、削除、入れ替えによって差異が生じます。弊社はこれを代表してモジュールと呼び、実際のバリエーションを（コンポーネント、パーツ、サブアセンブリ）であるモジュールバリアントと呼んでいます。これをもう少し具体的に説明するために、実際の例を見てみましょう。
電気機械式または油圧式の供給装置を備えた機器を想像してみてください。 機器には、電気機械式または油圧式の変速装置が付いている場合と付いていない場合があります。 電気機械式供給装置を油圧式変則装置と組み合わせることができますが、油圧式供給装置を電気機械式変速装置と組み合わせることができません。 機能と機能の選択は、この可能な組み合わせのルールによってリンクされるようになりました。 供給装置を変更してデバイスを変更すると、主要な機能部品だけが影響を受けるわけではありません。 制御および油圧供給システムと同様に、ケーブル配線と配管を適合させる必要があります。 したがって、目標値を持つ製品プロパティとモジュールバリアントを持つモジュールは共存する必要があり、制約は次のようなマトリックス形式で記述できます。
Matrix from PALMA Software
もし、組織全体でこのようなデータを同期させるような動きが無ければ、シームレスであるかどうかにかかわらず、エンド・ツー・エンドの構成は不可能です。
この2つの基本的な前提条件に加え、さらに6つの重要な問いについて説明します。この問いの答えは企業によって異なります。
最初の3つはシステムレベルに関するもので、このブログで紹介します。後半の3つはデータ構造に関するもので、このシリーズ最後となる次のブログ「Chapter4：製品構成の製品マスターとBOM構造」にて紹介します。
この質問に答えるためには、まず、機能性とシンプルな統合性のバランスを認識する必要があります。私たちは常に、可能な限り少ないシステムを使って統合したいと考えていますが、対外的にも内部的にも効率を維持するために必要な機能は維持したいと考えています。
すべてのフローを1つのシステム（一般的には設定機能を備えたERPシステム）に組み込むことができれば、最もシンプルなセットアップが可能となり、長期的には最も低いシステム維持費で済むことになります。
このシンプルな設定は、主に製品ベースのフロントエンドで使用され、コンフィグレーション機能が実質的に、すでに定義されたカタログ製品的な選択ツールとなっている場合に使用されます。
フロントエンドが構成可能なコンフィグレーションベースの場合、一般的にコンフィグレーションモデルの複雑さが増し、必要な機能をすべて提供できるすぐに使えるERPシステムを見つけることは難しくなります。これらの複雑さの中には、技術的に構成可能なものに加えて、異なるチャネルや市場向けの価格モデル、ブランドの制約、異なる市場向けの販売パッケージなどがあります。コンフィグレーションベースのフロントエンドを採用している企業は、競争力のあるトータルコスト（ITシステムと統合のコスト、コンフィグレータのメンテナンスコスト、失注のコスト、間接労働のコスト、製品開発のコスト、直接労働のコストなど）で、必須かつ必要な機能を備えたシステムを見つけるためには、専門のコンフィグレータ・プロバイダーに頼らざるを得ないくなるでしょう。
2番目に簡単な設定は、外部のコンフィグレータがERPと直接データ通信できる場合です。
この設定は、真の CTO(Configure to Order) にのみ使用できます。コンフィグレータで発注されたすべての注文は、すでに設計された部品を構成することで実現されます。情報の流れがエンジニアリングシステムを経由していないため、BOMをカスタマイズする必要がありません。
もう一つ評価しなければならないのは、サービスやアップグレードなどのアフターマーケットのニーズのために、各納入品のBOMを維持する必要があることです。製品の複雑さやライフサイクルに応じて、PLMの機能が必要になることもあります。
結論として、このシンプルなERPとコンフィグレータのセットアップは、複雑なコンフィグレーションモデルの要件を持つ製品ベースのフロントエンドを持つ企業や、完全なプラットフォームのバックエンドを持つ構成ベースのフロントエンドを持つ企業に対して良いと思われます。ただし、情報の流れの中でPLMの機能を必要とするすべての企業のために、PLMとの連携も加えなければなりません。
3つ目のセットアップでは、PDM/PLMをフローに組み込み、アフターマーケットや規制などの要求に応じて管理できるよう、構成ごとにEBOMが作成されるようにしています。
EBOMの作成に加えて、オーダー固有または顧客固有のパラメーターを変更できます。
この設定は、コンフィグレーションベースのフロントエンドとプロジェクトベースのフロントエンドの両方で、注文ごとに新しいBOMが生成されるバックエンドのケースに柔軟に適用できます。ただし、このフローにはCADが含まれていないため、オーダーに対する設計やエンジニアリングの量と複雑さには限界があると考えられます。製品の一部を特定のケースに合わせて調整する必要がある場合は、情報フローにCADを統合する必要があるかもしれません。
この設定は最も複雑ですが、最も柔軟性があります。下の図は、CADとPLMを双方向に統合した例です。
PLMとCADの統合により、エンジニアリング部品表と、図面の元となる経常的な表現（3Dモデル、系統図など）との間で、より効率的な同期が可能になります。
このセットアップは、バックエンドの運用モデルにおいて、設計/エンジニアリングを検討してから注文までの期間がかなり長い場合には、注文ごとに新たなBOMを作成することが必要です。これは、コンフィグレーションベースのフロントエンドでも、プロジェクトベースのフロントエンドでも同じことが言えます。複雑ではありますが、多くの企業ではすでにCADとPLMの統合が行われており、エンド・ツー・エンドの製品構成のケースにも利用することができます。
5つ目のセットアップは、主に幾何学的な構成が問題となる製品に特化したものです。この設定では、CAD環境から製品の設定を行うことができます。Configuratorプラグイン（別名：Design Automation）を備えたCADシステムと、CADに詳しくないユーザーでも設定できるように設定されたCADモデルが必要です。
これまでのケースでの図示表現では、エンド・ツー・エンドのシームレスな流れをシステム間のシーケンシャルなものとして図示してきましたが、これは必ずしも必要ではなく、また最善の方法でもありません。もちろん、これは3つ以上のシステムが関係している場合にのみ問題となります。
シーケンシャルな設定とは、システムを順番に並べることです。
しかし、製品が完全に安定している場合、つまりフルコンフィグ・トゥ・オーダーと呼ばれる場合は、システムを並列に配置することができます。
この設定では、設定されたエンジニアリング表現（EBOM）と製造ドキュメント（MBOM）の両方を同時に得ることができます。
並列化の大きな欠点は、変更の処理です。変更が遅れた場合、更新された正しいEBOMとMBOMを同期させるために、最初からプロセスを再実行する必要があります。もう1つの方法は、片方のBOMを手動で更新してから手動で同期させることです。これは、2つ目のシステムを正しく更新できないリスクがあるため、効率と品質が低下します。
並列設定の主な利点は、並列性は常に感度が低いということです。1つのシステムや統合が動作不能になったとしても、必ずしもフロー全体が停止するわけではありません。また、よりシンプルで安価なシステム統合が可能になります。
属性やオブジェクトの双方向からの統合は、通常であれば、マスターデータのアプローチがすぐれていれば必要がないはずです。もし同じ属性を複数のシステムで編集可能とする場合、すべてのシステムで最新の状態を維持するためには、堅牢で高速な双方向統合が必須となります。簡単な例としては、部品の材料費をPLMとERPの両方で編集できるケースがあります。
異なる属性やオブジェクトにまたがる双方向の統合（各項目が単方向である）がより一般的に必要とされます。このニーズは、エンド・ツー・エンドの製品構成のセットアップにおいて、どの程度の機能性が求められているかによって異なります。
このブログでは、エンド・ツー・エンドの製品構成に必要なITシステムと、フロントエンドとバックエンドのオペレーションモデルの異なるケースでの注文情報の流れを概観してきました。適切なセットアップを選択することは、パフォーマンスと柔軟性、コストとリスクのバランスを取りながら、実現可能な道筋を見つけるために慎重に検討する必要があるタスクです。
次回のブログ「Chapter4：製品構成の製品マスターとBOM構造」では、エンド・ツー・エンドのプロセスにおける次の3つの主要なデータ管理の問題、すなわち、BOMの再構築、オンザフライでの製品構造の作成、製品マスターモデルについて詳しく説明します。柔軟なフロントエンドと、エンド・ツー・エンドの動的なBOMをシームレスに処理するように設定されたバックエンドをマッチさせることができれば、製品のばらつきは真の競争力となります。
弊社は過去数十年にわたり、世界中の企業が製品の構成やコンフィギュラビリティを向上させることに100％注力してきました。お客様のお話を伺い、現在の状況からどのように改善できるかを議論したいと考えています。
ぜひお気軽にお問い合わせください。