製品開発戦略を「これからのPLM」に落とし込む例
次に、源流における製品開発プロセス・フローの重要な流れと、やや詳細化した業務プロセスを挙げ、それらを業務プラットフォームへと落とし込んでいく（関係付けていく）ところの概要を述べる。
▼その仕様を受けて、機構、エレキ、制御などの要素担当部門や、品質保証などの支援部門が、自部門として盛り込むべき技術戦略などを反映させた商品化戦略とし、ベース機種（群）の基本仕様の構想を策定する。
▼機構、エレキ、制御などの要素担当部門間で、その構想仕様を互いに擦り合わせながら、継続性も考慮した上で、個別仕様・インタフェース仕様を確定する。
これが、モジュラー・アーキテクチャを決定するフェーズに相当する。戦略上の製品・技術の世代を考慮しつつ、全体のアーキテクチャ体系の下に、個別要素の仕様体系までを擦り合わせることになる。本連載第7回の「川上力強化」で述べたが、アーキテクチャ・仕様を、徹底して“上流フェーズで擦り合せ”、戦略的に体系化することが必要であって、生産工程などの“下流フェーズで技術を擦り合せる”ことは何としても避けたい。擦り合わせが下流になればなるほど、製品やサービスの生涯コスト上のロスの発生要因が増える。“下流フェーズでの技術の擦り合せ”が許されるのは、1品1仕様でも利益を出せる究極のブランド品か、標準化を全く必要としなくても利益が出せる究極の個別受注品くらいだろうと筆者は思う。
これらを、もう少し業務的視点で整理すると、下記のようになる。
（2）企画仕様を受けて、機構系、エレキ系、制御系などで「取り合い・擦り合わせ・調整」しながら体系化する（全体構想と分担）
（3）要素別に、個別仕様の実現のためのアイデアを出す
（4）それを議論し、具体的なモデルとする（設計する）
（5）単体試作をし、部分評価・検証をする
（6）全体を組み合わせて総合検証を実施
（7）仕様を満たすまで理論検証と実機検証を繰り返して、収束させる
以上のようなプロセスを経て、区分［1］の業務層では、戦略と関係付けた「創造的な情報生成」がなされ、ベース機種が確立されていくが、それをPLMと関係付けるものが、「源流のP3LM（業務プラットフォーム）」＊である。
上述の（1）～（7）は、1次試作（設計～試作・評価～DR（Design Review））、2次試作（設計修正～試作・評価～DR）などを経て最終的に収束するまで、各社QMSの仕組みによって、業務プロセス、プロセス間のマイルストーンとその成果物としての体裁などは、ほぼ標準化されている。しかし、現場の業務手順（Procedure）を標準化することは、源流のフェーズが非構造的な業務であるために、まずできてはいない。
ただし、例えば混沌とした構想段階の思考でも、“どのような順番に考えるのが良いか”という手順や、過去の関連する知見・ノウハウなどをどのように生かすべきか、といった「考え方の手順やコツ」を標準化することは可能である。これらを業務遂行のプラットフォームとして要件定義し、ICTを活用した仕掛けとしてP3LMに落とし込むことを推奨している。
本連載第12回で述べたが、この源流プロセスは、混沌とした状況から、通常は数回の設計～試作～検証の繰り返しを経て収束させていく高度な創造プロセスなので、その過程で捨てられるデータ・情報も多い。しかし、そんなデータにこそ貴重なノウハウが埋め込まれているものなので、P3LMとしてはさまざまな帳票・実験資料・報告資料などを、できるだけ自然な形（フリーワードなど）で蓄積する方法を採り、ICTの力を借りた検索・活用、あるいは知見としての体系化などを実現しようとしている。
ちなみに、「業務プラットフォーム」をどのような単位で構築するかは、目的次第である。企画業務、要素別開発業務（例えば「機構系」「電気系」）などの単位でもよいし、もっと個別要素のユニット単位で構築するとか、支援業務としてのシミュレーション業務など、小さなプロセス単位でも構わない。むしろ小さめな単位として作るほうが効果を出しやすく、変化にも対応しやすい、と筆者は考えている。
