コンベヤシステムを見積る、エンジニアリングが各セクションを検証する前に

ならない。エンジニアリングは引き続き、どの組み合わせが有効か、どのドライブが何の荷重で使えるか、どのコンポーネントが特定の環境で除外されるかを定義する。CPQは、標準構成のたびにエンジニアリングに電話しなくて済むよう、それらのルールを見積時点に適用する。非標準レイアウト、カタログ外の用途、定義されたルールの範囲を超えるものは、引き続きエンジニアリングへ回す。

違う。ERPは購買注文、製造、請求の正式システムとして残る。構成が承認されると、再入力なしに製造へ渡せる。そのつなぎは本番環境で設定する。CPQは製造システムにはならない。

繰り返し可能な判断が存在する限り、CPQは役立つ。主にカスタム設計の会社でも、ベースのコンベヤ種類、標準セクション長、既知のベルト・ドライブの組み合わせ、オプションリストはたいてい一定だ。CPQはその繰り返し可能な層を担う。それより上はエンジニアリングプロセスのまま。本当にすべてがゼロからのユニーク品なら、カタログとERPで十分かもしれない。

地域・用途要件は構成の条件にできる。食品環境では汎用と異なるベルトと表面のオプションが表示され、ATEXゾーンでは特定のドライブが制限される。営業が早い段階で用途と環境を選ぶと、CPQはオプションリストをそれに応じて絞り込む。これは自動コンプライアンス認証ではない。それはエンジニアリングが担う。

営業が技術確認に回す。カタログ標準セクション、既知のドライブ組み合わせ、定義されたオプション範囲はCPQに残る。特注製造は既存のエンジニアリングプロセスに従う。得るもの: 標準構成がエンジニアリングの時間を消費しなくなり、本物の特注作業に余力が生まれる。

各ラインやゾーンを、同じ見積内の個別の構成にできる。制御盤、設置、保守などの共有要素は、ラインごとに重複するのではなく、見積レベルで一度記載する。これは初期設定で決めるモデリングの判断だ。Mercuraの新製品は不要。