フロントエンドエンジニアリング設計：次のプロジェクトを計画する方法
設計エンジニアリングには、細心の注意を払い、系統だったプロセスで取り組む必要があります。考えられるすべての解決策を十分に考慮せずに初期の開発に突入し、問題を一般的に理解すると、上流の開発とプロジェクトのコストの問題につながる可能性があります。フロントエンドエンジニアリング設計は、技術要件に焦点を当てるために使用されるアプローチです。これは、プロジェクト提案の主要なコストを認識することを目的としています。この記事では、プロセスが次のプロジェクトを支援し、潜在的なリスクを評価するのにどのように役立つかを段階的に説明します。
フロントエンドエンジニアリング設計：概要
フロントエンドエンジニアリング設計は、問題/製品開発の特徴に基づいています。これは必ずしも問題である必要はありませんが、概念的なアイデアまたは可能な発明です。これには、ターゲット仕様を持つ一連の目標があり、現在、フロントエンドエンジニアリング設計プロセスには8つのカテゴリがあります。
1。 初期問題の説明
2。 設計パラメータ
3。 チーム管理
4。 市場評価とベンチマーク
5。 ユーザーニーズの評価
6。 製品の調査
7。 開発計画
8。 ターゲット仕様
このプロセスは、適切に行われていることを確認するために設計レビューを通じて評価されます。その後、ソリューション開発段階が続き、最後に重要な設計レビューが実行されます。これらの段階を通じて、設計プロセスと検証は、設計を反映的でよく計画されたプロセスとして示すために、継続的にレビューされます。
設計上の考慮事項
設計者は、問題の発生を見落とし、特定の概念的な解決策に修正されることがよくあります。この解決策は、後で元々設計された問題/問題に対処できない可能性があります。この時点でさえ、新しい設計と製図の提案を検討する代わりに、欠陥を解決するためにソリューションを再設計しようとする人もいます。初心者の設計者は、問題の開発よりもソリューションの開発に重点を置く傾向があることがわかっています。
投資収益率（ROI）の向上
フロントエンドエンジニアリングデザインを使用する人はプロジェクトを時間どおりに完了する傾向があることを示すために調査が実施されました。これは、投資収益率が設計プロセスによって向上することを意味します。米国ワシントンD.C.にある国立研究評議会は、製品開発と製造のコストの少なくとも70％が設計の初期段階で決定されると見積もっています。
フロントエンドエンジニアリングデザインの使用
フロントエンドエンジニアリングデザインはさまざまな方法で使用できますが、ここでは、企業が基礎として使用できる標準的なアプローチについて説明します。
1。チーム管理
a。 同僚は、タスクの優先順位に基づいて実行する作業のスケジュールを作成します
b。 作業分解と各メンバーへのタスクの割り当て
c。 次に、労働者は彼らのプロジェクトのリスクを評価するように求められます
d。 ドキュメントを共有できる、共通のアクセス可能なファイリング場所を作成します
e。 個々の課題の開発について報告するための毎週の進捗ログ
構造化されたスケジュールを作成して効果的に実装するには、適切なプロジェクト計画が不可欠です。プロジェクトがタイムリーなスケジュールに従うためには、チームはプロジェクトの成果物とそれらに割り当てる適切な時間を正確に測定する必要があります。各成果物の全体的なタイムスケジュールを決定する際には、予想外の遅延や問題の予測を組み込む必要があります。
部品表は、プロジェクトのために物事を動かすために必要であり、コスト見積もりが行われるため、早い段階で構築する必要があります。チームの各メンバーは、プロジェクトに必要なものに取り組み、詳細に述べる必要があります。必要な資料を理解することは不可欠であり、この時点で他の可能な項目を予測することで、プロジェクトの進行を妨げることなく、将来の時間を節約できます。部品表に記載されていない予期しないアイテムが発生することは間違いありません。製品の最適なオプションを決定する際には注意して処理する必要があります。
毎週の進捗ログは必要ありませんが、特にリーダーが各メンバーがプロジェクトのどこに立っているかを理解する必要がある場合は、チームにとって有益です。簡潔で的確な毎週のブリーフィングは、プロジェクトがどのように進んでいるか、そして何かが遅れを引き起こしているかどうかをリーダーが測定するための洞察を提供します。これにより、リーダーが各メンバーと進捗状況について話し合う必要がなくなります。
プロジェクトのエラーを最小限に抑えることが理想的であり、適切に対処しないと、遅延やプロジェクトの一時的な停止を引き起こす可能性があります。プロジェクト中にエラーが消費する合計時間は、完了時にのみ決定できます。残念ながら、これにより、どの成果物が最も時間とお金を消費したかを理解できます。これは、同様の点で将来のプロジェクトの見通しを提供します。実際の結果を最初のタイムラインと比較し、進行を妨げた状況を見ると、十分に考えられていなかった項目またはタスクが明らかになります。予期しないイベントは、将来のプロジェクトのベンチマークとなるため、同様のミスが発生することはありません。
2。プロジェクト計画
進行フローを視覚的に評価するための構造化された設計プロセス。通常、フローチャートは、スケジュールを通じて割り当てられたタスクに基づいて作成されます。
3。初期分析と設計上の考慮事項
管理活動が完了した後、労働者は、問題を述べた予備文書と初期の設計上の考慮事項を含む、問題の初期分析を検討するように求められます。問題の説明は、フロントエンドのエンジニアリング設計プロセスが進むにつれて進化し、完了すると、ソリューション開発段階で問題が完全に特定されます。
最初の分析では、問題ステートメントに関するクライアントと利害関係者に関する質問にも対処します。これは、最初の設計上の考慮事項に対処する必要がある段階でもあります。考慮事項には、問題の説明、設計の目的、および設計の持続可能性、耐久性、保守性などが設計にどのように影響するかが含まれます。製品の調査中にすべてが徹底的に調べられます。
4。ベンチマークと市場評価
これは、チームが市場で入手可能な最高の製品、使用されているテクノロジー、および市場シェアを妨げる可能性のあるテクノロジーのデータとテクノロジーの傾向を収集する必要がある段階です。これは、利用可能な今後のトレンドへのアクセスが、独自の製品開発のベンチマークを提供する場所です。
市場規模を見ると、積極的に存在する潜在的な買い手と売り手についての見通しが得られます。これにより、市場に出す前にビジネスを準備できる数値的または定量的な測定値を得ることができます。
テクノロジーのトレンドを観察することで、会社は自社のタイプの製品が他のテクノロジーと比較してどのように機能しているかを確認できます。これは、同様のテクノロジーを調べたり、同様の機能を持つテクノロジーの傾向を観察したりするのと同じくらい簡単なことかもしれません。これは、製品が市場に出る前にどのように機能するかを予測するために必要です。
レギュレーター環境は、すべての製品が何らかの形で順守しなければならない形式です。これらは、既存の学部が特定のカテゴリに分類される製品に課す規制です。これは、自動車の排出規制、または化学薬品の洗浄に使用される溶剤の規制である可能性があります。それはすべて、会社の製品とそれがどのタイプのカテゴリーに分類されるかによって異なります。市場に出ることが期待される場合、地方自治体によって設定された基準に準拠する必要があります。
製品を市場に投入する前に、潜在的な競合他社を調べることは常に良いことです。マーケティング戦略を観察し、顧客の忠誠心を評価し、コストを比較することは、企業が取るべき最善のアプローチを理解するのに役立ちます。効果的なものは、競合他社に良い戦いを提供し、彼らに会社の存在に気付かせるでしょう。
市場構造は、製品リリースの責任者を評価するのに適しています。これにより、類似または密接に関連する製品を使用する競合他社に関する必要な情報が提供されます。これはまた、市場に存在する企業、その数、および市場シェアがそれらの間でどのように分配されているかについても説明します。
将来の市場動向を見越してトレンド調査が必要です。企業は、その製品が現在および将来どのように公正になるかを理解する必要があります。市場寿命が短い製品は、近い将来、ほとんどまたはまったく返品なしで終了します。これは、短期間で顧客の注目を集めない製品を製造するための時間とお金の無駄になります。
5。ユーザー/顧客のニーズの評価
製品設計の現在および将来のすべてのユーザーについて考慮事項に対処する必要があります。ここでは、製品の使用方法と使用者に関するアンケートや調査を通じて情報を収集します。これは、ユーザーの行動を評価するのに役立ちます。
6。 製品の調査
この段階は、機能分析、設計の検討、リスク評価、計画、および使用されているシステムの観点からの製品探索を理解することを目的としています。これは、プロジェクト全体の概念的な表現であるマインドマッピングのツールを使用して実行できます。
機能分析では、製品の機能要件と、ユーザーに必要な要件が考慮されます。この時点で、製品とコンポーネントの統合、または製品のシステムへの統合が考慮されます。この段階では、製品開発、サプライチェーン、設計、テスト、および製品の製造のためのテクノロジーが存在するかどうかも検討します。
これで、市場、顧客のニーズ、および機能をよりよく理解した上で、設計の2回目の反復でその主な目的に対処します。意図しない結果、未知数、およびその他の不確実性を考慮することに加えて、生産段階の前に発生する問題の可能性についてより良い先見性を提供します。
7。 開発計画
これは、収集されたすべての情報と資料が収集され、設計のミッションステートメントが作成されるときです。ミッションステートメントは、設計レビューの開始に続くソリューション開発へのインプットを提供します。この段階の主なポイントは、ユーザーのニーズを変換し、それを製造できる予測可能なパフォーマンスのために設計することです。
8。 重要な設計レビュー
初期の設計レビューは、メンバーがこれまでに完了したことをレビューし、不足している可能性のあるものや新しい開発について反映する、十分に文書化されたチーム会議である必要があります。重要な設計レビューは、ソリューション開発プロセスを除いて、同じ目標を達成します。これは、問題の理解と複数のソリューションの開発に注力するために使用されます。プロセスコストが低いため、これは最も重要な決定について話し合うのに最適な時期です。生産前の早期計画には複数のオプションがあり、コスト、製造ニーズ、および労働力の考慮事項に基づいて、各ソリューションのメリットを効果的に評価します。プロジェクトの進行中にソリューションを選択すると、将来的に遅延や問題が発生する可能性があります。問題の開発により多くの時間を費やすと、ROIが向上し、創造的な設計の進歩がより効果的になります。
問題ステートメントの開発と検討に余分な時間をかけることで、エンジニアリング設計で不十分な結果に遭遇する可能性を排除できます。これは、無駄な時間が減り、製造コストの増加が回避されるためです。
チームが積極的に共有してアクセスできる、1つのタイプのプログラム内のすべての重要なドキュメントを収集するための良い方法はありますか？
産業技術