PLMが実際にどのようにエンジニアリングチームの迅速な業務遂行に役立つのか
エンジニアリングチームに私たちが求めるスピードで動いてもらうには、その業務に影響を与える人、製品データ、プロセスが常に完全に整合していなければなりません。
設計変更が発生するたびに、その影響は上流および下流のチーム全体に波及し、全員が同じ情報に基づいて作業し続けることが難しくなります。
そこで役立つのが製品ライフサイクル管理（PLM）です。最新の PLMソフトウェアは、アイデア段階から量産まで製品情報を管理します。
PLMは、バージョンの混乱、BOMの不一致、文書化されていない変更、手作業による引き継ぎで生じるエラーの防止に役立ちます。
では、日々の業務の中で、実際にどのようにエンジニアリングチームのスピード向上に貢献するのでしょうか。
エンジニアリングの時間が本当に失われる場面
製品がより複雑になり、チームが分散していることも多くなる中で、エンジニアは情報の検索、判断内容の確認、正しいリビジョンで作業しているかの確認に、より多くの時間を費やしています。
エンジニアリングチームは日常的に、次のような問いに対するリアルタイムの答えを必要としています。
- 現在有効なBOMはどれか？
- この部品は承認済みか？
- この変更を承認したのは誰か？
- なぜこのコンポーネントが選定されたのか？
- 製造部門にはどのリビジョンが渡されたのか？
こうした質問への回答が、エンジニアリング作業を中断させるべきではありません。情報を見つけにくいと、チームは手戻り、手動確認、不必要なやり取りに時間を奪われます。
今日の PLMツールは、エンジニアが必要な情報に簡単にアクセスできるようにし、情報探しに費やす時間を減らして、設計により多くの時間を使えるようにします。
エンジニアリングチームには信頼できる単一の製品記録が必要
信頼できる製品記録は、製品開発の全期間を通じて、エンジニアリング、調達、製造に単一の信頼できる情報源を提供します。これにより、すべてのチームが正しいリビジョンで作業しているという確信を持てます。
調査によれば、PLMユーザーの85%が、これらの システムによって情報をより簡単に見つけられるようになったと回答しており、約75%がデータ精度の向上を報告し、3分の2以上が設計情報によりタイムリーにアクセスできるようになったと答えています。
信頼できる単一の製品記録があれば、エンジニアリングは自信を持って設計をリリースでき、調達は承認済み部品や代替部品を確認でき、製造は正しいリビジョンに基づいて生産でき、経営層は定例のステータス会議に頼らずに進捗を把握できます。
エンジニアリング変更が影響するのは、1つの部品だけとは限りません。アセンブリ、サプライヤー、図面、試験計画、製造プロセス、コンプライアンス文書にまで影響が及ぶことがあります。
PLMがない場合、こうした影響はしばしばメールのやり取り、チャットメッセージ、共有スプレッドシート、暗黙知によって管理されます。製品、チーム、サプライチェーンが拡大するにつれて、こうした変更を手作業で管理することははるかに困難になります。
今日の変更管理は、もっと 「GitHubに着想を得た」ものであるべきです。つまり、部品、図面、BOMのリビジョンを追跡し、誰が何を、なぜ変更したのかを確認し、ECOを承認ワークフローに回し、レビュアーに通知し、データ不足によって却下される変更指示の件数を減らせる必要があります。
変更指示が完全で、可視化され、 自動的にルーティングされるようになれば、チームは承認の追跡に費やす時間を減らし、エンジニアリング上の課題解決により多くの時間を使えるようになります。
PLMは調達判断をより早い段階でエンジニアリングに取り込む
Octopartユーザーにとって、これはPLMの最も重要なスピード面での利点の1つです。つまり、 部品選定が後から高コストな変更になる前に、エンジニアリングと調達が連携できるよう支援することで、そうした選択が 変更コストの高いものになる前に対処できます。
たとえば、ワークフローにDuro PLMを統合すると、エンジニアリングチームは、DuroのOctopartへのAPIアクセスを活用することで、 コンポーネントデータを手作業でコピー＆ペーストするのにかかる何時間もの作業時間を削減できます。
さらに、コンポーネントが追加されると、価格データ（およびその他のデータ）をPLM内から直接更新できるため、チームは常に最新かつ正確な情報を利用できます。これにより、手作業による価格確認に費やす何時間もの時間も節約でき、コストが許容できなくなった場合や、さらに悪いことに入手不能になった場合に、別のコンポーネントへ切り替えるための意思決定により多くの時間を充てられます。
これがOctopartユーザーにとってのPLMのROIです。部品が入手できない、廃止されている、高価すぎる、または調達が難しい場合、製品の立ち上げは困難になります。調達レビューが設計の大部分が完了した後に行われると、チームは後工程でのトレードオフを迫られ、スケジュールの遅延や、プレッシャー下での再設計につながります。PLMは、立ち上げまでの時間を短縮する意思決定に必要なデータを、はるかに早い段階でチームが取得できるよう設計されています。エンジニアは、設計の文脈の中で、サプライヤー、ライフサイクル、コスト、供給状況、代替部品のデータを確認できます。
PLMは部門横断のコラボレーションを改善する
製品開発のスピードを妨げる最大の障壁の1つが、順次的な引き継ぎです。エンジニアリングが設計を完了し、それを調達に送る。調達が問題を見つけ、また差し戻す。
PLMにより、部門横断のチームは設計をレビューし、より早い段階で 開発プロセスに関与できるようになります。
製造部門はリリース前に設計を確認でき、調達部門はBOMがまだ進化している段階でリスクのある部品を指摘でき、品質部門はリリースパッケージが完成する前に要件を検証できます。
これは特に分散チームにとって重要です。PLMは共有された製品記録を提供するため、絶え間ない会議や手動の進捗更新に頼らなくても開発を継続できます。
PLMはエンジニアリング上の判断の「なぜ」を保持する
長年にわたって使われるハードウェア製品には、製品の記憶が必要です。特に、エンジニアの離職、サプライヤーの変更、コンポーネントの廃止が起こる中ではなおさらです。
判断の背景が誰かの記憶、古いメールのやり取り、あるいは ローカルのスプレッドシートに保存されているだけでは、チームはいずれその設計の根拠を失ってしまいます。
PLMは「何を」だけでなく、「なぜ」を一緒に保持するのに役立ちます。優れた製品記録は、次のような問いに答えられるべきです。
- なぜこのコンポーネントが選定されたのか？
- なぜこの代替案は却下されたのか？
- なぜこの公差は変更されたのか？
- どのサプライヤーがこのリビジョンを承認したのか？
- どのECOでこの要件が導入されたのか？
- この部品が変更された場合、どのアセンブリが影響を受けるのか？
製品は、それ自体が記憶を持つべきです。そうすれば、同じ疑問が再び持ち上がるたびに、チームが毎回同じ問題を解き直す必要はありません。
Related Technical Documentation
関連リソース
Thank you, you are now subscribed to updates.
