PCBA RFQ を送信した後: レビュー、説明、見積もり、ビルド リリース

概要

PCBA RFQ を送信するとレビューが開始されます。これは、プロジェクトを見積もる準備ができているという意味ではなく、工場を建設する準備ができているという意味でもありません。

EMS プロバイダーが RFQ を受け取ると、仕事が変わります。営業、エンジニアリング、調達、テスト、および商業チームは、同じ仮定の下で同じビルドを評価していることを確認する必要があります。

ここで、規律ある PCBA RFQ プロセスが重要になります。

RFQ は、バイヤーが評価したい内容をサプライヤーに伝えます。見積書には、どのような前提に基づいて価格が設定されているかが記録されます。製造を開始する前に、ビルドに影響を与える決定を現在のリビジョンに対する明確な指示にする必要があります。

プロジェクトは、製造にリリースする準備が整う前に見積もることができます。

この 2 つのギャップが、実際の RFQ 作業の多くが行われる場所です。

RFQ、見積、ビルド リリースは異なる役割を果たします

同じファイルの多くが RFQ 段階と本番リリース段階の両方で出現する可能性がありますが、それぞれの時点で異なる目的を果たします。{0}

BOM、PCB データ、プログラミング情報、テスト要件、およびその他のプロジェクト入力が 3 つの段階すべてに現れる可能性があるため、この区別は見落とされがちです。

本当の問題は、それらのファイルが存在するかどうかではありません。

重要なのは、全員が同じビルド、同じリビジョン、同じ合意された範囲でそれらを使用しているかどうかです。

見積作成中

PCB アセンブリの見積もりが、1 人で BOM を開いて価格を計算することによって得られることはほとんどありません。

いくつかのレビューが並行して行われる場合があり、各チームは異なるものを探しています。

まず、全員が同じビルドをレビューしていることを確認してください

RFQ が到着したら、最初の実際的なタスクは、作成中の見積にどの情報が適用されるかを確立することです。

この段階では、購入者が提出する必要があるファイルのチェックリストをもう一度繰り返す必要はありません。それは RFQ の前のものです。

さて、質問は異なります。

PCB と BOM のリビジョンは一緒に属しますか?

CPL または配置データは現在のアセンブリ リビジョンと一致していますか?

要求された数量は、実際の最初のビルド、パイロット数量、または将来のボリューム シナリオですか?

プロジェクトはターンキーですか、部分ターンキーですか、顧客が用意したものですか、それとも混合ですか?{0}}

プログラミングと機能テストは現在の範囲の一部ですか?

RFQ がすでにレビューされている間に、ECN またはその他の設計変更が到着しましたか?

これらの状況はどれも珍しいものではありません。プロトタイプおよび NPI プロジェクトが変更されます。

問題は、エンジニアリング部門があるバージョンをレビューし、調達部門が別のバージョンの価格設定を行っており、購入者が別のバージョンを期待しているときに始まります。

新しいリビジョンが到着した場合は、影響を受けるエンジニアリング、調達、テスト、商業上の前提を再度チェックする必要があります。マイナーな改訂では、自動的に RFQ 全体をやり直す必要はありませんが、見積もりの​​根拠は明確にしておく必要があります。

エンジニアリング: 引用されているものを構築できますか?

RFQ 段階では、エンジニアリング部門は通常、見積範囲に重大な影響を与える可能性のある製造条件とテスト条件を探します。

プロジェクトによっては、次のものが含まれる場合があります。

• 組み立ての実現可能性。
• パッケージ-またはプロセス-の機密コンポーネント。
• パネル化または製造上の仮定。
• DFM または DFT に関する懸念。
• プログラミングへのアクセス。
• テストアクセス;
• 特別な組み立て作業。
• プロトタイプ、パイロット、またはその後の本番への影響。{0}}

これは重要な境界線です。

RFQ エンジニアリング レビューは、自動的に完全な製品設計監査になるわけではありません。{0}

その仕事は、製造可能性、準備作業、テスト範囲、コスト、またはリードタイムを変える可能性がある問題を、それらの仮定が見積もりの​​一部となる前に表面化することです。

調達: 見積条件で BOM を調達できますか?

調達チームは別の問題を解決しています。

ターンキーおよび部分的なターンキー PCB アセンブリの場合、レビューでは次の点を考慮する必要がある場合があります。{0}

• コンポーネントの入手可能性。
• ライフサイクルステータス。
• MOQ または MPQ エクスポージャ。
• 長い-リードまたは割り当て-に敏感な部分。
• 承認された代替ルール。
• お客様が用意したコンポーネント-。
• 価値の高い-または単一のソース アイテム。-
• 要求されたスケジュールに影響を与える可能性のある調達条件。

BOM は、すべての行が入力されたからといって、調達できる状態ではありません。

サプライヤーは、どの部品に価格が設定されているのか、どのソースが受け入れられるのか、正確に要求されたコンポーネントが計画されたビルドをサポートできない場合はどうなるのかを知る必要があります。

材料条件は、RFQ レビューと発注の間で移動することもあります。したがって、重要な調達の前提条件については、購入を約束する前に再度確認する必要がある場合があります。

テストとプログラミング: 現在の範囲には何を含める必要がありますか?

テストにより、PCB 設計を変更せずに商用範囲を変更できます。

定期的な製造検査を必要とするビルドは、以下を必要とするものと同じ RFQ ではありません。

• 顧客固有の機能テスト。-
• プログラミング;
• 専用の治具。
• ユニット固有の構成。{0}
• 特別なテスト記録。
• 追加の検証作業。

ファームウェアにも同じことが当てはまります。

プログラミングが含まれる場合、EMS チームは、どの製品バージョンが適用されるか、どのようにロードされるか、構成データがユニット固有であるかどうか、プログラミング後にどのような検証が行われるかを把握する必要がある場合があります。{0}

テスト範囲は単純な場合もあれば、広範囲にわたる場合もあります。 RFQ 段階で重要なことは、双方が現在の見積もりに何が含まれているかを理解していることです。

引用の背後にある仮定はどうなりますか?

答えのない質問すべてが引用を中止する必要があるわけではありません。

一部の項目は明示的な仮定として残る場合があります。

これらについて考える実際的な方法は次のとおりです。

確認済み

この点は検証されており、現在の見積書または構築手順の一部を構成することができます。

交換されました

買い手と供給者が異なる条件に合意したため、元の仮定は適用されなくなりました。

開ける

まだ決断が必要だ。

オープンアイテムには所有者が必要であり、関係者全員がそれが何に影響するかを理解する必要があります。

最後の部分が重要です。

未解決のパッケージ詳細は、未解決の PCB リビジョン、承認された代替品、プログラミング リリース、またはテスト方法と同じ作業をブロックすることはできません。

優先順位は、すべての質問を同様に緊急なものとして扱うのではなく、プロジェクトへの影響に従う必要があります。

明確化は決定を終了させるものであり、電子メールのトラフィックを発生させるものではありません

EMS 業務では明確化は通常のことです。

説明が不十分ではありません。

弱い RFQ プロセスでは、1 つの質問をし、答えを待ってから、別の無関係な質問を送信し、購入者はどの問題が実際に重要なのかを理解しようとしてしまいます。

より良いアプローチでは、関連する質問をグループ化し、その理由を可視化します。

単純な RFQ の場合は、電子メールで十分かもしれません。

より複雑なプロジェクトの場合は、短い技術会議の方が、別の長い電子メール スレッドよりも早く、複数の関連アイテムを閉じることができます。

会議そのものが目的ではない。

この問題は決定に達する必要がある。

見積書が購入者に返されるとき

プロジェクトの価格設定が十分に明確になると、仕事の種類が再び変わります。

サプライヤーはプロジェクトを理解することから、その理解に反して商業的なオファーをすることに移行しました。

見積もりでは、誰もがレビューしているのと同じビルドの価格が設定される必要があります

見積もりでは、将来の生産の詳細をすべて最終決定する必要はありません。

それには信頼できる根拠が必要です。

プロトタイプの場合、最初のビルドでエンジニアリング チームにさらに多くのことを教えるまで、一部の決定は合理的に未解決のままになる可能性があります。

パイロットまたは繰り返しの本番プロジェクトでは、ツール、テスト、調達戦略、プログラミング、再現性がすでにより重要であるため、より厳密な定義が必要になる場合があります。{0}

重要なのは、エンジニアリング、調達、テスト、販売、バイヤーが依然として同じプロジェクトについて話しているということです。

あるチームがリビジョン A をレビューし、別のチームがリビジョン B の価格を検討し、購入者がリビジョン C を期待している場合、迅速な見積もりは特に役に立ちません。

見積を今後に進めるために必要なもの

RFQ ワークフローの場合、重要なのは、プロジェクトを進めた場合に影響を与える前提を見積書が引き継いでいるかどうかです。

プロジェクトによっては、次のものが含まれます。

• 引用された改訂ベース。
• 調達モデル。
• 重要な代替仮定。
• 数量または数量の区切り。
• プログラミングとテストの範囲。
• ツールまたは NRE の仮定。
• 関連するリードタイムの​​依存関係。-
• お客様が提供した材料条件。-
• 実行を変更する可能性のある除外。

この引用には、現在の商業上の理解が記録されています。

生産指示そのものとして扱ってはなりません。

有益なフォローアップには理由がある-

見積もりが送信された後、沈黙してもプロジェクトが停止した理由はサプライヤーに伝わりません。

購入者は次のような場合があります。

• エンジニアリング担当者による見積書のレビュー。
• サプライヤーを比較する。
• 予算の確認。
• 調達の仮定を検証する。
• サプライヤー監査の準備。
• プロトタイプまたはパイロットビルドのどちらを開始するかを決定します。
• 内部プログラムの決定を待っています。

このような状況では、すべてが同じフォローアップを受ける必要はありません。-

「何かアップデートはありますか？」どちらの側にも多くを語ることはめったにありません。

有益なフォローアップには理由があります。-

例えば：

見積もられたパイロット数量は、計画されている最初のビルドとまだ一致していますか?

または：

承認された 1 つのソース仮定は、材料コストとスケジュールの両方に影響します。{0}引用した情報源をそのまま使用しますか、それとも別のオプションを検討しますか?

または：

商用範囲が許容される場合、次のステップは通常、サンプルの構築、サプライヤーの監査、または内部の PO レビューですか?

連絡を増やすことは、購入者の次の決定がより明確になる場合にのみ役立ちます。

商用承認が実際のビルドに変わるとき

お見積りも承ります。 POの発行が可能です。このプロジェクトは商業的に獲得できる可能性があります。

製造にはさらにもう 1 つのレベルの管理が必要になる可能性があります。

PO は、ビルドを開始する準備ができたことを自動的に意味するものではありません

注文書は、合意された商取引を承認します。

ファクトリには、現在のビルドの明確なターゲットがまだ必要です。

プロジェクトによっては、次の最終制御が必要になる場合があります。

• PCB および BOM のリビジョン。
• 承認された代替者。
• お客様が提供した材料のステータス。-
• ファームウェアまたはプログラミングのリリース。
• テスト範囲と合格条件。
• ツーリングまたは治具の準備。
• 特別な組み立て説明書。
• ラベルと包装の要件。
• 承認された逸脱。
• ビルドに関連する配信要件。

単純なリピート注文であれば、この問題のほとんどをすでに制御できている可能性があります。

初期のプロトタイプでは、まだ正当なエンジニアリング変更が行われる可能性があります。

そのため、NPI について「すべてを凍結する」という考え方が常に正しいとは限りません。

より有益な質問は次のとおりです。

このビルドではどのリビジョンと条件がリリースされますか?

製品は後から進化し続けることができます。

工場には、製​​造しようとしているボード用の制御ターゲットがまだ 1 つ必要です。

構築を開始する前に、前提を指示に変える必要がある

引用-ステージでの会話には便利な省略表現がたくさんあります。

代替可能。

プログラミングも含まれます。

更新されたテスト手順を使用してください。

サンプルと同じように梱包します。

これらの発言は、営業とエンジニアリングが RFQ について話し合っているときに完全に明らかになる可能性があります。

後で本番環境で全員が意図したものを再構築する必要がある場合、それらはあまり役に立ちません。

ビルドを開始する前に、製造に影響を与える前提を、現在のビルドに対する明確な指示にする必要があります。

重要な仮定は次のような結果になる可能性があります。

• 確認済み;
• 新しい合意条件に置き換えられます。
• 必要な決定が下されるまで公開されたままになります。

正確なドキュメント名は EMS プロバイダーによって異なります。

原理は簡単です。

本番環境では、何を構築するかを知るために、見積もりの​​会話を再構築する必要はありません。

優れた RFQ であっても、NPI ハンドオフでは問題が発生する可能性がある

これは、適切なプロジェクト情報が最も失われやすい場所の 1 つです。

エンジニアリングが特別なプロセス条件にフラグを立てた可能性があります。

調達側が代替品の承認を得ている可能性があります。

購入者はテスト要件を明確にしている可能性があります。

営業担当者が梱包について合意している可能性があります。

見積書には設備の仮定が含まれている可能性があります。

すべての決定はそれ自体で正しい可能性があります。

これらの決定が電子メール、見積書、会議メモ、個人の記憶に散在したままであれば、プロジェクトには依然としてリスクが伴います。

-NPI から-NPI への有効な RFQ 引き継ぎにより、現在の決定が引き継がれます。

最初のビルドでは、次のように接続される可能性があります。

現在のリビジョン → 承認された材料規則 → エンジニアリングアクション → プログラミングおよびテスト要件 → 工具または治具のステータス → 梱包および配送要件。

制作には決断が必要です。

RFQ 履歴全体を受信して​​、それを再度解釈することを期待すべきではありません。

リリース チェックはプロジェクトの段階と一致する必要があります

すべての注文に同じ深さのフロントエンド制御が必要なわけではありません。{0}}

プロトタイプ

最初のビルドにはエンジニアリングの学習がまだ含まれている可能性があります。

現在のリビジョンと製造指示は、構築するために十分に明確である必要がありますが、将来の設計変更が不可能であるかのように振る舞う理由はありません。

パイロットビルド

多くの場合、次のようなことに注意が移ります。

• 再現性;
• テストの実行。
• 物質的な戦略。
• ツーリング;
• プロセスの一貫性。
• 次の量レベルの準備。

リピート生産または大量生産

重点はさらに次の点に移ります。

• 安定したリビジョン管理。
• 承認された変更管理。
• 物質的な継続性。
• 一貫したテスト。
• プロセスの再現性。
• 配送計画。

基本的なワークフローは同じです。

コントロールの量はプロジェクトの段階に応じて変化します。

購入者が見るべきもの

バイヤーは、すべての社内ワークシート、調達に関する会話、またはエンジニアリングに関するディスカッションにアクセスする必要はありません。

プロセスはまだ理解できるはずです。

RFQ が注文に向けて進むまでに、購入者は次のような質問に答えられるようになっている必要があります。

• 現在の見積書はどの改訂に基づいていますか?
• まだ未解決の重要な仮定はどれですか?
• 重大なリスクまたは代替案は承認を待っていますか?
• プログラミングとテストは現在の範囲に含まれますか?
• 次に必要な決断は何でしょうか?
• PO が発行された場合、ビルドを開始する前に何が必要ですか?
• どの見積段階の決定が NPI に反映されますか?{0}

それは単に次のように言われるよりも有益です。

あなたの見積もりは検討中です。

STHL がワークフローを構築するための RFQ に適合する場所--

Shenzhen STHL Technology Co., Ltd. (STHL) は、RFQ とファイル レビューから、エンジニアリングと材料の準備、アセンブリの準備、生産、プロジェクト固有のテストと納品に至るまで、PCB アセンブリと EMS プロジェクトをサポートしています。-

正確なレビューの深さは、プロジェクト、その調達モデル、テスト要件、改訂ステータス、数量、および生産段階によって異なります。

アクティブなプロジェクトを評価しているバイヤーは、STHL をレビューできます。PCB組立サービスより幅広い製造範囲に対応します。

プロジェクトのサプライヤーレビューの準備ができたら、次のことができます。プロジェクトの詳細を送信してください.

プロジェクト固有の質問については、{0}STHL までお問い合わせください。info@pcba-china.com.

結論

有用な PCBA RFQ プロセスは、次のような単純なものではありません。

ファイルイン→価格アウト。

RFQ、見積もり、および現在のビルド リリースにはそれぞれ異なるジョブがあります。

RFQ は、EMS プロバイダーに評価の対象を与えます。

見積書には、どのような前提条件の下で何が提供されているかが記録されます。

プロジェクトが前進する場合、製造に影響を与える決定は、NPI への引き継ぎ後も存続し、現在のビルドで使用可能な指示になる必要があります。

その過程で明確化が行われ、実際の決定が終了するはずです。リビジョンの変更は、重要な箇所でレビューをトリガーする必要があります。フォローアップは、単にスレッドに別のメールを追加するのではなく、購入者の次の決定を特定するのに役立ちます。-

そして、PO が到着すると、問題はプロジェクトが正しく見積もられたかどうかだけではなくなります。

それは、プロジェクトが合意されたときにバイヤー、営業、エンジニアリング、調達、およびテストのチームが持っていたのと同じ理解を現在工場が持っているかどうかです。

これが、PCBA RFQ が送信された後の実際の移行です。

情報→商業契約→管理された実行へ。