システムズエンジニアリングを取り入れる重要性

システムズエンジニアリングをBusiness of Engineering(ものづくりのビジネス全体を効率化)に組み込むことが重要であると感じています。開発プロセスとビジネスシステムが別々の「島」になっている - これが多くの企業が抱えている問題です。どのチームも、自分たちだけの緑のカーテンの後ろで、自分たちだけのシステムを使って、自分たちだけのやり方で物事を進めています。データの共有で使われるのはExcelやEメール、Dropboxです。これらはどれも地下に潜むPLMの一部です。globe-island-1000x872x96dpi-300x262

それに加えて、今や誰もがデジタルスレッドが必要だと声をそろえます。つまり、製品開発をさかのぼって以前のバージョンや意思決定、変更などが見られるようになることです。どれも優れた情報とコンテキストを伴っています。

しかし、皆さんのチームとシステムが完全に分離していて、データ共有の手段として認められたものがDropboxといった状態で、デジタルスレッドらしきものが何か期待できるのでしょうか?

システムズエンジニアリングとは何か?

システムズエンジニアリング (SE)は、この分離された状態に該当します。INCOSEはシステムズエンジニアリングを次のように定義しています。

システムズエンジニアリングとは・・・開発サイクルの初期段階において顧客ニーズと必要な機能を定義し、要件を明文化し、その後、完全な問題を考慮しながら設計の統合とシステムの検証を実行することに焦点を当てるものです。

システムズエンジニアリングは、部門や専門グループを全て1つのチームの取り組みに統合し、コンセプトから製造、オペレーションまでを実行する体系化された開発プロセスを作り上げていきます。ユーザーの望む高品質な製品を提供するという目標のもと、システムズエンジニアリングは全顧客のビジネスと技術両方のニーズを検討します。

聞き慣れた言葉が多く出てきます。予想通り、それらはすべてPLMの一部なのです。それならば、システムズエンジニアリングはBusiness of Engineeringの範疇にどのように当てはまるのでしょう?

ビジネスとのつながりPLM-process-simple-SysEng-768x647

システムズエンジニアリングの目的やタスクを一般的なPLMプロセスに重ね合わせると、ビジネスの役割とのつながりが明らかになります。システムズエンジニアリングのチーム、プロダクトマネージャー、チーフエンジニアは、新たなコンセ
プトや技術に共に取り組みます。製品アーキテクチャを構築し、システム分析を行って、高いレベルの特性を評価します。これらのコンセプトは市場の動向に照らし合わせて評価され、製品のフィージビリティ(実現可能性)を判断します。

コンセプトが選択され、詳細設計が始まると、システムズエンジニアリングチームにもその状況が共有されます。詳細設計から発生する変更は、それがメカ、エレキ、あるいはソフトウェアいずれにしても、システムアーキテクチャの再評価が必要になるかもしれません。おそらくサブシステムではコスト削減の動きもあります。システムズエンジニアリングチームはまた、荷重条件やテスト要件を設計分析や試験チームに与え、製品が確実にパフォーマンスと品質を達成できるようにします。

エンジニアリング担当バイスプレジデントはこの一連の動きを監督します。製品にコンセプトが正しく反映されているかを確認し、リソースを分配し、必要に応じてコスト削減の努力を促します。プラスの価値(例えば収益性)につながるよう、大きな方程式における変数のすべてのバランスを取らなければなりません。ご存知の通り、私たちはすべてについてビジネスのコンテキストに立ち返ることができます。しかし、もしデジタルスレッドを実現したいのであれば、ドメインごとのデータをつなぐ必要があります。その「島」から開放されなければなりません。

データの「島」をなくすために

製造業に携わる企業は、業界を問わずほぼ全て、ますます複雑になる最新製品の管理に悪戦苦闘しています。これらの製品設計にハードウェア、ソフトウェア、エレクトロニクス、ファームウェアが絡み合ってくることは間違いありません。ドメイン特有の機能を正しく組み合わせて優れた製品を設計するには、システムズエンジニアリングが必ず必要になります

システムズエンジニアリングは一般的に、NoMagic社のCameoIBM社のRhapsodyといったモデルベース・システムズエンジニアリング(MBSE)ツールを使って実行されます。これらのツールはCADと似た方法でPLMへ統合されます。CADでは、3DモデルはPLMの一部もしくはCADアイテムに書き込まれるメタデータやプロパティに取り込まれます。これには多くの場合、質量、体積、サーフェスエリア、境界ボックスディメンジョン、アセンブリ構造といった情報が含まれます。

MBSEも多くの点で同様に取り扱われます。MBSEの要素(つまり、機能ブロック、ロジックブロック、ダイアグラムなど)はPLM内で例示可され、もともとのSysML定義(SysMLとは多くのMBSEツールによって活用されているシステムモデリング言語のこと)に基づいてそれらの要素をお互いに関連づけるメタデータを含んでいます。このアプローチによって、PLMの構成管理機能がカバーする管理すべてがMBSEモデルの対象となり、製品設計の現状の構成に影響を与えうる設計変更のエラーを防ぐことにつながります。

皆さんの会社にはシステムズエンジニアリングのチーム、あるいはシステムズエンジニアリングを実行する担当者がいらっしゃるでしょうか?本当に彼らのスキルを活用し、彼らを常に製品開発プロセスに関わらせていますか? もしそうでないとすれば、皆さんは自社のリソースを十分に活用しているとは言えず、製品やプロセスに問題がある可能性があります。

システムズエンジニアリングはBusiness of Engineeringのもう一つの構成要素なのです。皆さんのシステムチームを地下からひっぱり出してものづくりというテーブルにつかせ、彼らにもっと関わってもらいましょう!

MBSE統合に関する詳細については以下もご覧ください。
MBSE-PLM統合
Aras とIBM: Rhapsody統合
MBSEとBusiness of Engineering

最後までお読みいただきありがとうございました。

Aras PLMの詳細・ダウンロードはこちらから
Aras_Logo_2013
広告