ホーム Supply Chain and Component Sourcing

Supply Chain and Component Sourcing

Optimize component sourcing with real-time supply chain insights, helping designers choose reliable parts and avoid shortages or obsolescence.

Filter
found
Sort by
Role
Software
Clear Filters
BOMエラーを減らし、コンプライアンスを確保するためのヒント BOMエラーを減らし、コンプライアンスを確保するためのヒント 1 min Blog Engineering Managers PCB設計者 Procurement Managers +1 Engineering Managers Engineering Managers PCB設計者 PCB設計者 Procurement Managers Procurement Managers Manufacturing Engineers PCB組み立てにおける遅延や追加コストの最も一般的な理由の一つは、BOM内の部品情報の誤りです。BOM内で誤りが生じる理由は多岐にわたり、単純な部品番号の間違いから環境適合性データの欠落やDNPとして部品をマークすることまで、その範囲は広がっています。このデータを省略することは、製造業者に新たな責任を生じさせ、調達チームによる誤った部品の発注につながる可能性があります。 スケジュールを守ることは、これらの誤りを早期に発見するプロセスとツールを持つことについてです。ここでは、そのようなプロセスを実装する方法と、設計ツールを使用してBOMの問題を発見する方法についてのヒントをいくつかご紹介します。 部品を注文する前にこれらのBOMエラーをキャッチしましょう BOMの誤りは設計者にとってコストがかかり、スケジュールの遅延を引き起こしますが、部品データに簡単な変更を加えることで避けることができます。重要なのは、PCBのレイアウトが完成するのを待つのではなく、設計プロセスの早い段階でこれらの誤りをキャッチすることです。 そこで、最も厄介（そしてコストがかかる）BOMの誤りと、それらを防ぐために取ることができる手順をいくつか紹介します。 部品番号とパッケージの不一致 問題： PCBレイアウトに配置されたパッケージとフットプリントが、BOM内の部品番号と一致しません。 この問題はほとんどの場合、PCB組み立て時に発見され、その時点であなたは本当に困難な状況に陥っています。PCBを廃棄してプロジェクトを最初からやり直しますか？それとも、既存のランドパターンに合う代替部品を探しますか？ ここでの選択肢は多くないことがありますが、一般的な解決策は、同じ部品番号ファミリー内で異なるパッケージオプションを持つ別の部品を見つけることです。最悪の場合、カスタムのインターポーザPCBを製作するか、PCBを廃棄する必要があるかもしれません。 解決策は？設計者は、PCBが生産に入る前にこの問題を発見できる部品作成およびライブラリレビュープロセスを持つ必要があります。一部のサブスクリプションCAMツールは、DFM/DFAレビュー中にこの問題を半自動的なプロセスで捕捉することもできます。大企業では通常、ライブラリアンのタスクを担当する人がいますが、小規模な企業は信頼できる部品ソースに依存して、コンポーネントのCADデータを見つけるべきです。 DNP部品の誤った呼び出し 問題： DNP部品が、実装された部品と同じ行に記載されているか、まったく記載されていません。 理想的には、DNPパーツはBOMやピックアンドプレースファイルに現れるべきではありません。もしDNPパーツがBOMに現れた場合、組み立て業者はそれがピックアンドプレース機をプログラムする際に手動で取り除かれることを確認する必要があります。これは、組み立て業者がBOMの手動レビューを行い、提出物全体で一貫性があるかをチェックするときに起こります。 DNPパーツを適切に指定せずにBOMをエクスポートすると、または少なくともDNPパーツを指定する際に一貫したアプローチを使用しないと、物事は混乱します。例えば、下の画像では、黄色でハイライトされた単一行にDNPパーツがあります。次の行にもDNPパーツがリストされていますが、前のパーツと同じ列にはありません。組み立て業者は自然に何が起こっているのか疑問に思うでしょうし、このパーツがDNPとしてマークされるべきかを確認するためにプロジェクトの文書を参照する必要があります。 解決策は？ Altium Designerの「バリアント」のような機能を使用して、バリアントを定義し、DNPパーツを呼び出すための回路図マークアップを適用し、これをBOMマネージャーのDNPコールアウトと照合します。部品にDNPマーキングの正しい存在をチェックするプロセスを実装できない限り、これを行わず、代わりに組み立てバリアントを使用してBOMとピックアンドプレースの配置を同時に制御します。 受動部品の未知の部品番号 記事を読む
設計から調達までのBOM管理 BOM管理：設計から調達までの説明 1 min Blog Procurement Managers Engineering Managers +2 Procurement Managers Procurement Managers Engineering Managers Engineering Managers Product Managers Manufacturing Engineers 部品表（BOM）は、製品を製造するために必要なすべての部品、組み立て品、およびサブアセンブリの包括的なリストです。これは、伝統的に分断されていた設計と生産チームの間のギャップを埋め、製品ライフサイクル全体を通じて正確性、効率性、およびコスト効果を維持するのに役立つ、絶対に不可欠な文書です。 BOMの重要性を理解する それを念頭に置くと、BOMが製品開発ライフサイクルで重要な役割を果たすことは明らかですが、実際にどのチームに影響を与え、なぜ影響を与えるのでしょうか？ 調達： 必要な部品とサプライヤーの特定。 製造： 組み立てプロセスの指導と正しい部品の使用の確保。 品質管理： 製品の整合性と仕様への準拠の検証。 コスト計算： 生産コストの見積もりと予算の管理。 これらのチームそれぞれにとって、十分に管理されたBOMは、操作の効率化、エラーの削減、および全体的な製品品質の向上を助けます—これらはすべて、製品が期待を超え、要求の厳しい消費者に迅速に市場に出る必要がある時点で、ますます重要な要素です。 部品選択と仕様 最終製品の品質は、その設計に使用されるコンポーネントの良さによってのみ決まります。それらを選択する際には、次の要因を考慮することを忘れないでください。 コスト：異なるオプションの コスト効果を評価し、バルク割引、リードタイム、潜在的な隠れたコストなどの要因を考慮します。 入手可能性：特に重要な部品や需要がピークに達する期間に、コンポーネントを確実かつ迅速に調達できることを確認します。 性能：必要な仕様を満たすかそれを超えるコンポーネントを選択し、消費電力、動作温度範囲、信頼性などの要因を考慮します。 信頼性：特にダウンタイムが重大な結果を招く可能性がある重要なアプリケーションにおいて、コンポーネントの実績と故障までの平均時間（MTBF）を考慮します。 互換性：ピン配置、電力要件、信号の整合性など、設計内の他のコンポーネントとの互換性を確認します。 記事を読む
電子部品の陳腐化の管理 エレクトロニックコンポーネントの陳腐化管理：エンジニアリングマネージャーのための実践的な洞察 1 min Blog Procurement Managers Engineering Managers Procurement Managers Procurement Managers Engineering Managers Engineering Managers 技術革新の加速、グローバルサプライチェーンの複雑さ、新たに出現する環境および安全規制が、製品のライフサイクル中に重要なコンポーネントが陳腐化する可能性を劇的に高めています。原材料の不足やサプライヤーの倒産も、コンポーネントの陳腐化を増加させる一因となっています。エンジニアリングマネージャーにとって、これらのリスクを積極的に管理することは、高額な再設計、サプライチェーンの崩壊、システムの故障を避けるために不可欠です。 コストとサービスへの影響に加えて、陳腐化したり陳腐化しつつあるコンポーネントを使用することは、品質と性能を損なう可能性があります。 高い信頼性と安全性を要求される防衛や航空宇宙のようなセクターでは、そのような失敗がミッションクリティカルな結果や国家安全保障へのリスクをもたらす可能性があります。長い製品ライフサイクルにわたって高品質な部品へのアクセスを維持することは、さらなる複雑さを加えます。 以下では、この複雑さを管理し、陳腐化した部品から来る物流上の課題とリスクを避けるための戦略とベストプラクティスを提供します。 1. 積極的なライフサイクル管理の実施 コンポーネントのライフサイクルを管理する積極的なアプローチは、 陳腐化のリスクを軽減するために不可欠です。PCBデザイナーは、高額な再設計を避けるために、設計プロセス全体を通じてサプライチェーンの可視性を維持する必要があります。 しかし、リスクの軽減と積極的な意思決定に必要な部品の膨大な量とサプライチェーンの可視性を考えると、企業は必要なデータに簡単にアクセスし、調達から製品寿命終了（EOL）までの部品のライフサイクル状況を監視できる ツールを採用する必要があります。 AltiumのActiveBOMのような専門的なソフトウェアソリューションは、部品の陳腐化を管理するプロセスを合理化し、エンジニアリングマネージャーが部品の選択をライフサイクル管理と 統合するのを助けることができます。これにより、部品の可用性、価格、ライフサイクル状態に関するリアルタイムの更新を提供し、潜在的な陳腐化の問題を早期に特定できるようになります。 ActiveBOMのようなツールは、設計プロセスとシームレスに統合され、エンジニアが陳腐化のリスクにある部品を特定し、代替オプションを提供するのに役立ちます。また、特定の部品が複数の製品でどこに使用されているかを追跡することを可能にし、製品ポートフォリオ全体での陳腐化リスクを管理することを容易にします。 ActiveBOM（部品表管理） ActiveBOMは Altium Designer内の機能であり、エンジニアが部品表（BOM）をリアルタイムで管理するのを助け、以下を提供します： リアルタイム部品データ：ActiveBOMは、供給元から直接、部品の在庫状況、価格、ライフサイクルステータスなどの最新情報を自動的に取得します。 リスク軽減：廃止予定または入手困難になるリスクのある部品を警告し、先手を打つことができます。 代替品と調達：ActiveBOMは、現在の市場状況に基づいて代替部品を提案し、コストとサプライチェーンのリスクを最適化するのに役立ちます。 記事を読む
調達専門家のためのBOM管理におけるコスト削減テクニック 調達専門家のためのBOM管理におけるコスト削減テクニック 1 min Blog Procurement Managers Procurement Managers Procurement Managers 電子部品業界において、企業とその内部チームが利益を上げ、今日の非常に競争の激しい市場で競争力を維持したい場合、部品表（BOM）を効果的に管理する方法を見つけ出す必要があります。この感覚は、特に調達専門家にとって真実であり、BOM管理はコストの最適化と 部品の効率的な調達を確実にする努力に大きな影響を与えます。 BOMの構造とデータの理解 BOMは、製品を製造するために必要なすべての部品、アセンブリ、および材料の包括的なリストであり、調達、生産計画、および在庫管理にとって重要な文書です。企業がBOM管理を通じてコストを効果的に管理するためには、BOMの主要な要素とデータの正確性および一貫性の重要性を理解する必要があります。 BOMの主要な要素 典型的なBOMには、次の要素が含まれます： アイテム： 製品を構成する個々の部品またはアセンブリ。 数量： 製品の単位ごとに必要な各アイテムの数。 属性： 各アイテムに関する追加情報、例えば部品番号、説明、供給業者、およびコスト。 データの正確性と一貫性の重要性 正確で一貫したデータは、効果的なコスト分析と最適化にとって基本です。BOMのエラーや不一致は以下のような問題を引き起こす可能性があります： 過剰在庫または在庫不足： 不正確な数量は、余剰在庫や不足を引き起こし、コストの増加や潜在的な遅延につながります。 誤った価格設定： 不正確なコストデータは、部品の過払いや製品の総コストの過小評価につながる可能性があります。 サプライチェーンの混乱： BOMのエラーは、調達と生産の遅延を引き起こし、納期と顧客満足度に影響を与える可能性があります。 記事を読む
先取りして部品の陳腐化に対処するための積極的なソリューション 先取りして部品の陳腐化に対処するための積極的なソリューション 1 min Blog Electrical Engineers Procurement Managers Electrical Engineers Electrical Engineers Procurement Managers Procurement Managers 新しいボードの設計において、設計者や製造業者は定期的に部品の陳腐化という問題に直面します。これは技術の進化や市場の需要の変化によって引き起こされる大きな課題であり、残念ながら製品開発、生産、保守において潜在的な中断を引き起こす可能性があります。陳腐化に関連するリスクを軽減するためには、企業は積極的な対策を講じておく必要があります。 企業が直面する陳腐化にはさまざまなタイプがあり、それぞれがいくつかの要因によって引き起こされます。企業が陳腐化リスクを管理するための効果的な戦略を開発するためには、これらの各要因を理解することが重要です。以下の表をご覧ください。 要因 説明 技術の進歩 技術の急速な進歩は、古い部品を陳腐化させることがよくあります。例えば、新しい、より効率的なマイクロプロセッサの導入は、古いモデルを望ましくなくさせることがあります。 市場需要の変化 消費者の好みや業界のトレンドの変化は、特定の部品への需要の減少につながることがあります。例えば、従来のハードドライブからの移行は、ハードドライブ部品の市場に影響を与えました。 サプライチェーンの混乱 自然災害、地政学的な出来事、製造上の課題など、サプライチェーンの混乱は、部品の不足や陳腐化に寄与することがあります。 陳腐化のタイプ 定義 例 商業的 製造または購入が経済的に実行不可能になるコンポーネント、例えば製造コストの高さや需要の低さなどの要因による。 限定された市場需要のある特殊なコンポーネント；製造コストが高い時代遅れのコンポーネント。 製品寿命終了（EOL） コンポーネントがもはや製造されたり、サプライヤーによってサポートされなくなった時。 古いマイクロプロセッサー；CRTテレビ。 機能的 記事を読む
アジャイル・ハードウェア開発 カバー写真 原則が健全である理由、しかし戦術は再考が必要である 1 min Blog Mechanical Designers Engineering Managers +8 Simulation Engineers Mechanical Designers Mechanical Designers Project Leads Test Engineers Engineering Managers Engineering Managers 私たちの「アジャイルを解明する」シリーズの最終回では、ハードウェア開発がアジャイル手法と交差する複雑な風景をナビゲートします。アジャイルの基本原則は確かな基盤を提供しますが、 電子ハードウェアのユニークな課題に適用される場合、戦術の再評価が不可欠になります。探求の旅で、アジャイルの共通の要素と儀式を解き明かし、それらを具体的な製品開発の文脈で変革する方法を探ります。 アジャイルマインドセットを採用し、一貫して育むことから始める ハードウェア開発における日々のソフトウェアアジャイル実践を強力な利点に高めるための戦術的調整に深く潜る前に、アジャイルマインドセットの基本的な原則をまず受け入れることが重要です。良いスタート地点は、 アジャイル宣言の意図を考慮し、ハードウェア開発のニーズに合わせて言語を修正することかもしれません。以下の表は、ハードウェア開発のための一つの潜在的な宣言を提供します。 各マニフェストの意図の簡単な要約は、 「協力して反復的な開発と学習のアプローチを用い、顧客が本当に価値を見出すものを発見し、提供しましょう。」となるでしょう。もちろん、これはほぼすべてのプロジェクトにとって理にかなっており、チームが日々の開発戦術に没頭する中で、これらの基本的な原則を念頭に置くことが重要です。 方向性計画の重要な役割 アジャイルの反復的な性質は、時に初期計画が後回しにされ、とにかく始めることに重点が置かれるような印象を与えることがあります。しかし、物理的および電子製品の設計と開発の複雑なプロセスをナビゲートするためには、ある程度の事前計画が不可欠です。徹底的な事前計画ではなく、反復的な学習と実行を通じてチームを開発の旅に導くロードマップと考えてください。 アジャイルハードウェア開発の初期計画には、明確な目標の設定、マイルストーンの定義、そして熟考されたプロトタイピングと フィードバック戦略を通じたリスク評価の軽減が含まれます。これにより、チームはアジャイルの適応性と成功したハードウェア開発に必要な構造化された計画の間のバランスを取ることができます。 ユーザーストーリーと作業項目の分離 このシリーズの前の記事で議論したように、 アジャイル「専門家」はしばしば、ハードウェアチームにタスクを定義するためにバックログをユーザーストーリーで埋めるよう促します。ハードウェアのユーザーストーリーを考えてみましょう。新しいフォークリフトの開発を計画していると仮定します。次のようなユーザーストーリーを書きます： "ユーザーとして、素材をすぐに取り出せるようにしたいので、在庫の移動にかかる時間を節約できます。" ハードウェア開発者は何をすべきか知っていますか？おそらく知りません。解決すべき問題の側面が多すぎます。実装には、フォークリフトの速度、フォークアタッチメントの精度、インテリジェントな在庫感知、在庫の向き、その他多くの要因が関わるかもしれません。これらのユーザーストーリーは、具体的な機能やタスクではなく、 製品要件や作業項目というよりも、顧客の目標になるべきです。 ユーザーストーリーは、アジャイルなハードウェア設計フローにおいて、顧客のニーズに焦点を当て、顧客が達成しようとしている結果を明確にするための場所があります。しかし、物理製品のユーザーストーリーは直接的に機能、属性、またはタスクに翻訳できないため、それらはタスクバックログを開発するための出発点となり、バックログアイテム自体にはなりません。 実証可能な進捗と成功のためのプロトタイピング戦略 計算されたプロトタイピングは、ハードウェア開発における要であり、その重要性は過大評価できません。アジャイルの伝道師は、迅速なソフトウェアリリースの美徳を説きますが、ハードウェアの領域では、 記事を読む
アジャイル・ハードウェア開発に関する一般的な誤解のカバーフォト 多くのアジャイル「グル」がハードウェア開発について誤解していること 1 min Blog Mechanical Designers Engineering Managers +8 Simulation Engineers Mechanical Designers Mechanical Designers Project Leads Test Engineers Engineering Managers Engineering Managers アジャイル手法は、ソフトウェア開発の世界に根ざしており、技術業界において変革的な力として称賛されています。しかし、ハードウェアおよび電子機器の開発に進出するにつれて、アジャイル原則の見かけ上スムーズな適応は、課題と誤解の迷宮に直面します。この3部構成の探求の第1回目では、 ハードウェアとソフトウェア開発の違いから生じるアジャイルの課題を分析しました。この記事では、アジャイル「専門家」によって広められた神話を検証します。 電子ハードウェア開発におけるアジャイルの複雑さに踏み込む前に、アジャイルのコーチやコンサルタントを非難することが私たちの意図ではないことを明確にすることが重要です。私たちは、彼らの善意と、顧客がアジャイル手法の利点を享受するための熱意を認識し、評価しています。批判が生じることもありますが、それはハードウェアの微妙な違いを十分に理解していないことから来るものであり、批判することが目的ではありませんが、アジャイル原則を効果的に適応させ、ハードウェア開発の特定の要求を満たすことが目的です。私たちの焦点は、このユニークな文脈でその利点を活用するためにアジャイル戦術を調整し、アプローチを変更しつつも原則を保持することです。 神話＃1：柔軟で適応し続ける必要があります アジャイルの専門家は、反復的な実行、フィードバックループ、そしてソフトウェアのデジタル領域で栄えている迅速な適応性の長所を正しく賞賛しています。しかし、これらの原則をハードウェアや電子機器の具体的な風景に移行することは、純粋なデジタルスペクトラムにはない複雑さの層を導入します。物理的な解決策は、そのソフトウェアの対応物とは異なり、「完成」する必要があります。部品を注文し、金型を製造し、厳格な製造ニーズを満たすためです。アジャイルの絶え間ない変化への呼びかけは、ゲームの遅い段階でさえ小さな変更が必要な場合、ハードウェアの容赦ない性質と衝突します。 これに対応して、ハードウェア開発にアジャイルを適用するには、パラダイムシフトが必要です。それは絶え間ない変更についてではなく、 プロトタイピングと、時間、予算、リソースの制約内で価値を最大化することを目指す、迅速な学習と実行サイクルに基づく、情報に基づいた戦略的な適応についてです。アジャイルの機敏さと物理製品の最終性の要求との間のダンスは、より良心的なイテレーション計画と、プロジェクト全体を通じてリスク削減への深いコミットメントを必要とします。 神話＃2：毎スプリントで動作するプロトタイプを開発する必要があります アジャイルの純粋主義者がよく唱える、2〜3週間ごとに完全に機能するプロトタイプを開発する 「スプリント」はアジャイルであるための普遍的な「必須」項目とされていますが、このアプローチの実用性は、ハードウェアおよび電子機器の開発（および予算）の現実に直面して崩れます。何かを構築し、進捗を示し、この結果を使用して貴重な技術的および商業的フィードバックを得て、次のイテレーションに役立てるという考え方は正しいです。しかし、各ハードウェアプロジェクトは、独自の目標、依存関係、リードタイムの制約、必要なイノベーションの領域、およびリスクを持つ独立したエンティティです。そして、各プロジェクトは、プロトタイピングと学習に対する独自のアプローチを受けるに値します。 アジャイルなハードウェア製品開発を真に受け入れるためには、チームはワンサイズフィットオールの考え方を捨てる必要があります。代わりに、プロジェクトのニーズを慎重に検討し、創造的で学習とプロトタイピングの戦略を導き出すために協力する必要があります。"プロトタイプ"は、予備的なパンフレットから、スティーブ・ジョブズの有名な「ポケットに1000曲を入れる」iPodモックアップのような泡のモックアップ、部分的または完全に機能するプロトタイプまで、あらゆる実証可能な成果物であることを認識することが重要です。 神話＃3：バックログにストーリーを追加して、ただ始める アジャイル手法の固有の強みは、従来のウォーターフォールアプローチよりもプロジェクトをはるかに迅速に開始できる能力にあります。実際、アジャイルハードウェア電子プロジェクトにおいては、概念の特定から開発の開始までの期間が大幅に短縮されていることがわかっています。この期間は、従来の段階的アプローチの下では多くの場合、数ヶ月または数年に及ぶことがありましたが、アジャイル方法では数週間または数日にまで短縮されています。もちろん、この劇的な結果の一部は、私たちが「開発の開始」と定義する方法にあります。 ソフトウェアにとって、これは簡単です。アジャイルの専門家は、ソフトウェア機能を定義するためのユーザーストーリーの作成、それらをバックログに優先順位付けし、スプリントを開始することを推奨しています。しかし、ハードウェアでは、少なくともプロジェクトを正しい方向に導くために、アーキテクチャ、重要な望ましい属性、制約、およびその他の要因の理解を伴う最低限の事前計画が必要です。この事前の努力は、「動作するソフトウェアが進捗の主要な尺度である」と「開発の遅い段階でさえ、変更される 要件を歓迎する」というアジャイルの原則と明らかに衝突するように見えるかもしれません。 和解は、製品開発の前段階に一般的に理解されているアジャイルの戦術を適応させることによってバランスを見つけることにあります。ハードウェアのアジャイルプロジェクト管理は、プロジェクトの戦略的意図に沿って迅速に開始し、従来のアプローチよりもはるかに多くの未知数を受け入れることを可能にします。その後、チームはアジャイルの反復学習を使用して最適な解決策を定義し、スケジュールとリソースの制約内で製品価値を高める戦略的変更に対して開かれた心を持って協力することができます。 神話＃4：すべての作業項目をユーザーストーリーとして定義する 多くのアジャイルの専門家が唱える重要な指示の一つは、すべての開発作業をユーザーストーリーとして定義すべきだということです。このアドバイスは、システムコンポーネント、インターフェース、他のエンジニアなども「ユーザー」として扱うべきだと続けています。このアドバイスにより、ほとんどの電子機器およびハードウェア開発者は頭を悩ませ、遵守に苦労しています。 ソフトウェアチームがアジャイルの実践をすんなりと採用している主な理由の一つは、顧客のニーズを伝統的な要件文書や詳細なユースケースで文書化することが非常に無駄であり、チームにほとんど価値を加えなかったからです。なぜユーザーが何をしようとしているのかを宣言し、その機能を文書化するためにユーザーストーリーを書き、それを開発タスクとして扱わないのでしょうか？これは自己文書化するだけでなく、これらのストーリーが一貫して優先され、顧客との検証が行われれば、変化に対応し価値を最適化するための完璧なクローズドループシステムを持つことになります。素晴らしいですね！ ハードウェア開発のためにユーザーストーリーを直接作業項目として書き、それらを価値ある顧客の成果に追跡するこの試みは、多くのハードウェアチームにとってアジャイルの限界点であることがよくあります。ハードウェアを定義することは、ソフトウェアを定義することとは異なります。従来の製品要件文書（PRD）や機能仕様は、ハードウェア開発者にとって安心感を提供するだけでなく、彼らの作業を分解して提供するために必要な詳細を提供します。開発者に「処理ユニットとして、クリーンな入力を保証するために電圧調整が必要です...」のようなユーザーストーリーを書かせることは、ユーザーストーリーを通じて顧客価値を捉える目的を無効にし、ソフトウェア開発者がアジャイル原則で取り除こうとした非価値の無駄を追加します。 記事を読む