次の方法で共有

製品構成の概要

  • [アーティクル]

特別な条件を満たすために製品をコンフィギュレーションする必要は、企業間および企業と顧客間の関係、両方において例外ではなくルールになってきました。

コンフィギュア ツー オーダーのシナリオをサポートするメーカーは、顧客のニーズにより慎重な傾向の営業案件があります。 また、完成品の代わりに半完成品を一般コンポーネントのフォームで保管するなら, メーカーは目録と結びつく資本を減らすことができます。

マニュファクチャー ツー ストックの設定からコンフィギュア ツー オーダーの設定への移動に成功するには、製品の構造の注意深い分析、製品ファミリーの ID およびコンポーネント化が必要になります。 プロセスの中で部品の数を削減および商品の数を縮小するためには、製品のインターフェイスを理解し、再利用できるように設定することが重要です。

ルール ベース、分析コードベースおよび制約ベースモデルなどのようなモデルとなる複数の製品コンフィギュレーションの原則があります。 研究によれば、制約ベース方法は他のモデルの原則と比較してモデルの明細行を 50% 削減できることを示しています。 したがって、この方法により総保有コスト (TCO) を削減できます。 [X++ コード] に基づいたルール ベース モデルから制約ベース モデルへの移動により、今後製品モデルを管理するために開発者ライセンスの必要はありません。

製品コンフィギュレーション

産業化期間により高品質で豊富な機能の製品を手頃な価格で生産する点で大きな成果を得ています。 規模の経済は先進国の、ほとんどの人が日常生活の一部として必要だと考えている自動車、TV、家庭電化製品およびその他の製品の購入を可能にしています。

多くの製品が必需品になるにつれて、それらを区別する必要が発生しました。 この課題に対するメーカーの迅速な反応は各製品の相違を作り出し、顧客が多くの選択肢を得られるようになりました。 この戦略により予測の課題が増加し、在庫原価も増加し、売れ残った製品が古くなります。

コンフィギュア ツー オーダーの理念を採用することにより、メーカーは古い在庫品目を減少もしくは削除しつつ、独特な製品を求める顧客の需要に応じた営業案件を持つことになります。 マニュファクチャー ツー ストック理念がコンフィギュア ツー オーダー理念にシフトされると、直ちに発生する１つの課題は短いリード タイムと低い在庫レベルの間で均衡を保つ必要があるということです。

ここでの成功のカギは、注意深く製品のポートフォリオを分析し、製品の機能およびプロセスの両方のパターンを見つけることです。 目標は同じ設備で製造でき、すべてのバリアントで使われる一般コンポーネントを識別することです。

新しい製品のコンフィギュレーション機能セットには、製品コンフィギュレーション モデル構造の視覚概要を提供するユーザーインターフェイス (UI) およびコンパイルされる必要のない宣言制約構文も含まれます。 したがって、コンフィギュレーション プラクティスをサポートしたい会社が容易に始めることができます。 次のセクションで説明するように、製品デザイナーは製品コンフィギュレーション モデルを構築し、テストし、販売組織にリリースするために開発者のサポートを必要としません。

製品コンフィギュレーション モデルの構築

製品コンフィギュレーション モデルを構築するのにユーザーが取ることができる選択肢が複数あります。 1 つのオプションは、最初に、製品マスター、特徴的製品、業務資源など、すべての参照データを作成し、それらをコンポーネント、部品表 (BOM) の行、工順工程および製品コンフィギュレーション モデルの他の要素として含みながら、連続したフローに従うことです。 また、最初にモデルを作成し、必要に応じて参照データを追加するというより反復的な方法を選択できます。

コンポーネント

製品コンフィギュレーション モデルはサブコンポーネントの関係を通して結びつく 1 つ以上のコンポーネントで構成されます。 コンポーネントは 1 回定義すれば、1 つ以上の製品コンフィギュレーション モデルに何度でも使用できます。 コンポーネントは、製品コンフィギュレーション モデルの主要な構成要素で、モデルに関するほぼすべての情報は、それらに関連付けられます。

属性

各コンポーネントにはプロパティを識別する 1 つ以上の属性があります。 属性は、ユーザーがコンフィギュレーション プロセス中に選択します。 属性は、制約または計算の算入を通してインター コンポーネントとイントラ コンポーネントの両方の関係を制御します。 BOM 明細行に適用される条件を通して、属性はコンフィギュレーション済製品がどの現物パーツで構成されるかを決定するために使用できます。 また、属性はマッピング メカニズムを通して BOM 明細行のプロパティを制御できます。 同様の機能は、包含およびプロパティ設定の両方に関する工順工程にあります。

メモ

属性タイプを作成する場合、属性タイプのドメインに対して大きい値を作成することは避けてください。 そうすることで、製品コンフィギュレーターの処理速度が低下する可能性があります。

式の制約

制約ベースの製品コンフィギュレーション モデルを使用するという事は、ユーザーがさまざまな属性の値を選択する際にいくらかの制限があることを意味します。 そのような制限は [Optimization Modeling Language (OML)] を使用することにより式の制約と同じように実装されます。 または、制約はテーブル制約の形式で実装されます。

テーブル制約

テーブルの制約は、ユーザーまたはシステムに定義されます。

ユーザー定義のテーブル制約は、ユーザーによって構築されます。 ユーザーは属性タイプの組み合わせを選択して、テーブルの列を表し、選択した属性タイプのドメインから値を入力して、テーブル制約の行を作ります。

システム定義のテーブル制約は参照として使用するテーブルを選択することによって定義され、このテーブルからフィールドを選択して、制限の列を作ります。 テーブル制約の行は、コンフィギュレーション時に存在する Supply Chain Management テーブルの行です。

テーブル制約は、テーブル制約定義を参照し、モデルの中で該当する属性をテーブル制限の列へマッピングすることによって製品コンフィギュレーション モデルに含まれます。

計算

計算はコンフィギュレーション モデルで実行する算術演算のしくみを表します。 たとえば、計算は、原材料の特定の部分の長さ、または研磨工程の処理時間を決定できます。 計算は必須で、計算式に含まれるすべての属性値が使用可能になってから、ターゲット属性の値を設定します。

サブコンポーネント

サブコンポーネントは、製品コンフィギュレーション モデルの構造のノードを表わします。 各サブコンポーネントの関係に対して、バリアント コンフィギュレーション テクノロジを制約ベースのコンフィギュレーションに設定した製品マスターへの参照を指定する必要があります。

ユーザーの要件

ユーザーの要件にはサブコンポーネントのすべての要素があります。 唯一の違いは、ユーザーの要件が製品マスターに縛られないということです。 この違いによる実質的な効果はユーザー要件のコンテキストで定義される、BOM 明細行また工順工程がみな、親コンポーネント BOM 構造または工順の中へ折りたたまれることです。 この動作はファントム BOM の動作に似ています。

BOM 明細行

BOM 明細行には、各コンポーネントの製造 BOM を識別する事が含まれます。 BOM 明細行は品目を参照する必要があり、すべての品目のプロパティが固定値に設定されるか、または属性にマップされます。

工順工程

工順工程には、製造工順を識別する事が含まれます。 工順工程は、定義された工程を参照する必要があり、すべての工程プロパティは、固定値に設定できます。 リソース要件を除くすべてのプロパティは値ではなく、属性にマップすることができます。

製品コンフィギュレーション モデルの検証およびテスト

製品コンフィギュレーション モデルの検証は、モデルの複数のレベルで行われるので、さまざまな範囲をカバーできます。 最下位レベルは、1 つの式の制約になります。 この場合、検証は通常、製品デザイナーによって式の構文が正しいことを確認するために実行されます。

同様に、BOM 明細行の条件または工順工程は分離して検証できます。

ユーザー定義テーブル制約の定義に対して検証できます。 この場合、ユーザーは各フィールドに入れられる値が対応する属性タイプのドメインの中にあることを確認できます。

最後に、完成した構文が正しい事、すべての名前付けおよびモデリングの規則が遵守されてきたかを確認するために、完成した製品コンフィギュレーション モデルで検証が行われます。

テスト

モデルをテストすることは、実際のコンフィギュレーション セッションを実行するのと似ています。 ユーザーがコンフィギュレーションのページでモデル構造がコンフィギュレーション プロセスをサポートすることを確認できます。 ユーザーは、属性値が正しいこと、属性の説明がユーザーに正しい値を選択させられることを確認できます。 最後に、テストのセッションが完了した後、システムは BOM および選択した属性値に対応する工順の作成を試み、何か間違いがあればエラー メッセージが表示されます。

コンフィギュレーション ページ

コンポーネントの間を移動するには次へを選択するか、フォーカスするために製品コンフィギュレーション モデルのツリーでコンポーネントを選択します。

コンフィギュレーション モデルの完成

製品コンフィギュレーション モデルをコンフィギュア ツー オーダーのシナリオで使用する準備が整ったら、バージョンを作成する必要があります。 ただし、モデリング経験を豊かにできる複数のオプションがあります。

ユーザー インターフェイス

コンフィギュレーションの UI は、1 つ以上のサブコンポーネントの属性グループを導入することによって変更できます。 このようにグループ化することは、特定の属性同士の関係を強調し、コンフィギュレーション ユーザーが現在フォーカスしている製品の範囲を識別する事を助けます。

テンプレート

コンフィギュレーション プロセスの処理速度を上げるために 1 つ以上のコンフィギュレーション テンプレートを作成できます。 また、販売キャンペーンで特定の一連の製品機能を絞り込む時のように、特定の属性の組み合わせを促進するためにテンプレートを作成できます。

翻訳

製品が異なる国 / 地域で販売される場合、コンフィギュレーションの UI に表示されるすべてのテキストのために翻訳を作成できます。 このテキストは、名前や説明フィールドだけでなく、属性テキスト値も含みます。

バージョン

最後に完了プロセスの最も重要な手順は、製品コンフィギュレーション モデルのバージョンを作成することです。 バージョンは注文または見積明細行の構成および製品コンフィギュレーション モデルのために選択できる製品マスター同士の関係を表します。 バージョンはコンフィギュレーション セッションで使用できるよう、あらかじめ承認および有効化しておく必要があります。

API による製品コンフィギュレーション モデルの拡張

開発者ライセンスがあるパートナーと他のユーザーが製品コンフィギュレーション モデルの処理能力を拡張できるように、専用のアプリケーション プログラミング インターフェイス (API) が実装されてきました。 主な目的は、既存の [プロダクト ビルダー] を使用するパートナーや顧客に [プロダクト ビルダー] モデルに埋め込まれたコードを [API] へ移行させるメカニズムを確立していくことです。 これにより、モデルを [プロダクト ビルダー] から製品コンフィギュレーションに移行することができます。 ただし、新しいパートナーや顧客は、新しい製品コンフィギュレーション モデルを拡張して API を使用して利益を得ることもできます。

製品コンフィギュレーション モデルのデータ構造を公開する一連の PCAdaptor クラスの使用により API　が実装されます。 PCAdaptor クラスのインスタンスは拡張される各モデルごとに作成する必要があります。 コンフィギュレーション セッションの完了後、システムはこのクラスのインスタンスをチェックし、見つければ実行します。

次の API フロー ダイアグラムは、プロセスの概要を示します。

フロー図。

製品のコンフィギュレーション

1 つ以上の製品のコンフィギュレーション

製品は、次の場所からコンフィギュレーションできます。

  • 販売注文明細行
  • 販売見積明細行
  • 発注書明細行
  • 製造オーダー明細行
  • 在庫品目要求明細行 (プロジェクト)

コンフィギュレーションの目的は、顧客の要求を満たす製品の特徴的なバリアントを作成することです。 固有のコンフィギュレーション ID が新しいコンフィギュレーションにごと作成されます。 この ID で、在庫の追跡ができます。

複数のサイトと会社の考慮事項

生産が行われるサイトまたは会社とは異なるサイトもしくは会社でコンフィギュレーションが実行される場合、BOM および工順が供給会社の仕入先サイトに対して作成され、そこに置かれます。 製品バリアントは、サプライ チェーンに関わるすべての会社にリリースされます。