設計思想から違う。次の時代に向けても違う。

このページの内容は、サードパーティサービスによって自動翻訳されています。

製品ライフサイクル管理の業界に携わって約30年になりますが、その経験を通じて学んだことの一つは、PLMは決して立ち止まらないということです。

私はシーメンスで15年、PTCで10年働き、Arasに入社してからは2年になります。その間、PLMがいくつもの異なる時代を経て進化していく様子を見てきました。それぞれの時代は、新たなビジネス要件、製品の複雑化、そしてその時々に利用できたテクノロジーによって形づくられてきました。

もともとは主にエンジニアリングファイルを管理するための仕組みだったものが、今では企業がますます複雑化する製品を設計、製造、保守し、継続的に改善していくうえで欠かせない基盤となっています。

業界は大きな進歩を遂げました。一方で、複雑さも蓄積してきました。現在、多くの製造業では、分散した製品情報、高度にカスタマイズされたシステム、分断されたプロセス、そして複数のシステムやアプリケーションにまたがって蓄積された何十年分もの貴重なエンジニアリング知識を抱えています。

そして現在、人工知能が、また新たな大きな転換点を生み出しています。

本当に考えるべきことは、PLMにAI機能を追加することだけではありません。長期的な価値は、基盤となるPLM環境が、AIに必要なつながったコンテキスト、適応性、ガバナンスを提供できるかどうかにかかっています。だからこそ私は、「違うこと」に意味があると考えています。

PLMは、エンジニアリングの目の前の課題を解決することから始まった

現代のPLMの起源は、非常に現実的なニーズにさかのぼることができます。CADツールを導入した企業は、エンジニアリングファイルを確実に保存、管理、制御するための方法を必要としていました。

デジタル設計が普及するにつれ、製造業では、どの図面が最新版なのか、誰が変更したのか、どのバージョンがリリースされたのかを把握する必要が生じました。急速に増加するデジタルエンジニアリング情報を秩序立てて管理するために、製品データ管理が登場しました。

そこから、その対象範囲は広がっていきました。

企業は、部品表、製品構成、文書、リビジョン、承認、設計変更などを管理するようになりました。PLMは単なるファイル保管の仕組みを超え、製品定義を管理するためのシステムへと進化しました。

これは重要な進歩でしたが、この時代に作られたシステムは、当然ながら当時の課題や技術的制約の影響を受けていました。

多くの場合、それらはエンジニアリング部門、CAD環境、高度に構造化された製品データを中心に構築されていました。また、プロセスを標準化し、厳格な管理を維持することを目的とした、大規模でモノリシックな実装として導入されることも少なくありませんでした。

当時の課題に対しては、このアプローチは合理的でした。

PLMは企業全体へと広がった

製品や組織が複雑になるにつれて、企業はPLMに、より多くの役割を求めるようになりました。

エンジニアリングチームは、もはや一つの拠点や一つの専門分野だけで仕事をする存在ではありません。企業は、世界各地の開発拠点、事業部門、サプライヤー、製造拠点、サービス組織をまたいで連携する必要がありました。

PLMは、要件管理、品質、製造計画、サプライヤーとの協業、構成管理、システムズエンジニアリング、サービスなど、より幅広いプロセスを支援するようになりました。

PLMと他のエンタープライズシステムとの関係も、ますます重要になりました。製品開発は、ERP、MES、サプライチェーン、品質、その他の業務システムから独立して機能することはできなくなりました。

企業は、どこでも設計し、どこでも製造できることを求めるようになりました。世界中に分散したチームを支援しながら、製品構成や変更を適切に管理できるフェデレーテッド環境が必要になったのです。

製品ライフサイクルという考え方は、エンジニアリング部門の枠を大きく超えるようになりました。

しかし、PLMの対象範囲が広がるにつれ、実装も複雑になることが少なくありませんでした。非常に固有性の高いプロセスに対応するためにシステムがカスタマイズされ、統合の数も増えていきました。アップグレードは難しくなりました。場合によっては、導入したシステムを維持することに多くの労力を費やすあまり、新たなビジネス要件に適応させること自体が大きなプロジェクトになっていました。

変化を管理するためのシステムそのものが、必ずしも簡単には変えられなかったのです。

SaaSは提供モデルを変えたが、そこに至る道のりは容易ではなかった

次の大きな業界の転換は、クラウドとSaaSへの移行でした。

その価値は明確でした。企業はインフラ管理の負担を減らし、運用を簡素化し、アクセス性を高め、新しい機能をより頻繁に導入できるようになります。多くの企業にとって、SaaSはエンタープライズソフトウェアの将来を象徴するものでした。

しかし、従来のオンプレミスPLMからSaaSへの移行は、その目的地そのものよりもはるかに困難な道のりとなりました。

多くの既存PLM環境は、何年、あるいは何十年もかけて構築されてきました。そこには、各企業がどのように製品を設計し提供してきたかを反映した、大規模なカスタマイズ、統合、データ構造、プロセスが含まれていました。こうした環境をSaaSへ移行することは、既存の環境をそのままクラウドへ移すほど単純ではありませんでした。

多くの場合、ベンダーはSaaSに対応するために、自社製品のアーキテクチャを大幅に再設計する必要がありました。その結果、顧客は実質的に新規導入とも言える状況に直面しました。データを移行し、統合を再構築し、プロセスを再設計し、ユーザーを再教育し、長年にわたるカスタマイズのうち何を引き継げるのか、あるいは引き継ぐべきなのかを判断しなければなりませんでした。

SaaSのメリットは魅力的であっても、そこに到達するためのコスト、業務への影響、組織的な負担は大きくなり得ます。

これにより、従来型PLMモデルの重要な課題が明らかになりました。企業はSaaSへ移行する戦略的価値を理解していても、既存環境の複雑さに制約されることがあります。テクノロジーは進化していても、顧客は事実上ゼロからやり直さなければ、その進歩を活用できない場合があったのです。

ソフトウェアをクラウドに移すだけで、従来型PLMに伴うすべての制約が自動的に解消されるわけではありませんでした。

柔軟性のないシステムは、SaaSとして提供されても柔軟性のないままです。標準化されたアプリケーションは運用しやすいかもしれませんが、一方で企業に対し、自社の差別化された製品開発や顧客へのサービス方法に合わないプロセスへの適応を求めることもあります。

そのため、ソフトウェアがどこでホストされるか以上に、次の根本的な問いが重要になりました。

企業は、何年もかけて築いてきた製品知識、プロセス、統合、ビジネス価値を手放すことなく、どのようにPLM環境をモダナイズできるのか。

この問いが特に重要なのは、製品開発が決して変化を止めないからです。企業買収が起こります。規制は変化します。新たなエンジニアリング分野が加わります。製品には、より多くのソフトウェアや電子技術が組み込まれるようになります。サプライチェーンも変化します。新しいビジネスモデルも登場します。

エンタープライズテクノロジーが新しい時代に入るたびに、製造業が再び高額な再実装を行わなければならないようであってはなりません。

私たちはAIの時代に入った

現在、業界はまた新たな大きな転換期を迎えています。

人工知能には、エンジニアが情報を見つけ、代替案を評価し、リスクを特定し、反復作業を行い、製品ライフサイクル全体で意思決定を行う方法を変革する可能性があります。

しかし、AIは、分断され適切にガバナンスされていない情報から、信頼できる結果を生み出すことはできません。

AIシステムは、技術的にはもっともらしい回答を生成できるかもしれません。しかし、産業環境では「もっともらしい」だけでは不十分です。エンジニアは、その回答がどの製品構成に適用されるのか、基になる情報が最新かどうか、誰が承認したのか、どの要件が適用されるのか、そして提案されたアクションが製造、品質、コンプライアンス、コスト、サービスにどのような影響を及ぼす可能性があるのかを把握する必要があります。

産業AIにはコンテキストが必要です。

そのコンテキストは、要件、部品、文書、ソフトウェア、シミュレーション、変更、サプライヤー、製造計画、品質記録、物理資産の間の関係から生まれます。

言い換えれば、AIにはデジタルスレッドが必要なのです。

だからこそ私は、AIの時代を、PLMに新たな機能を追加するだけの機会とは考えていません。これは、PLMの基盤が情報をつなぎ、ガバナンスを維持し、変化するプロセスを支援し、製品知識を人とインテリジェントシステムの双方に提供できるかどうかを試すものです。

Arasが設計思想から違う理由

私がArasに魅力を感じたのは、単に別のPLMアプリケーション群があったからではありません。そこには異なる設計思想がありました。

Arasは、ビジネス要件は変わり続けるという前提で構築されています。

モデルベースのアーキテクチャにより、企業は、あらゆる変更を従来型のソフトウェアカスタマイズとして扱うことなく、データモデル、ワークフロー、関係性、アプリケーションを進化させることができます。オープンなアプローチにより、企業はより広範なエンタープライズ環境全体で情報をつなぐことができます。また、アップグレードに対する考え方は、顧客がこれまで構築してきたものを維持しながら、新たなプラットフォーム機能を継続的に導入できるよう支援することを目的としています。

これらは単なる技術的な違いではありません。

その違いは、企業が数年にわたる置き換えプロジェクトを開始することなく、新しい規制に対応できるかどうかに影響します。買収した企業を共通のデジタルスレッドに組み込めるかどうかにも影響します。エンジニアリング、製造、品質、サプライヤー、サービスの各チームが、つながった製品コンテキストを基盤として業務を進められるかどうかにも関わります。

そして今では、AIを分断された実験として運用するのではなく、実際の製品ライフサイクルプロセスに統合できるかどうかにも、ますます大きく影響するようになっています。

Arasでは、すべての製品情報を単一のリポジトリにコピーする必要はありません。既存のシステムをまたいで情報をつなぎ、ガバナンスしながら、製品をライフサイクル全体で理解するために必要な関係性とコンテキストを提供できます。

このアプローチは、今日存在する分断されたエンタープライズ環境において特に重要です。

違いは、差別化された価値につながらなければならない

違うというだけでは、それ自体に価値があるわけではありません。

価値は、その違いによって顧客が何を実現できるかによって生まれます。

何度もゼロからやり直すことなく、モダナイズできます。

ニーズの変化に応じて、PLMを新しいビジネスプロセスへと拡張できます。

すべてのアプリケーションを置き換えることを前提とせず、既存のシステムや情報をつなぐことができます。

新しいテクノロジーを導入しながら、何十年にもわたって蓄積してきたエンジニアリング知識を維持できます。

そして、インテリジェントシステムに必要な、つながりがあり適切にガバナンスされた製品コンテキストを確立することで、AIへの準備を進めることができます。

これが、私にとっての「設計思想から違う」という意味です。単にソフトウェアアーキテクチャについて述べているのではありません。顧客が進化し続けられるよう支援するという約束なのです。

AIが最後の時代ではない

AIは今この瞬間を象徴するテクノロジーの波ですが、これが最後ではありません。

新しいテクノロジー、運用モデル、規制、そして新たな形の製品の複雑さは、これからも生まれ続けます。10年後、製造業は、現在ではまだ完全には予測できない要件に直面しているでしょう。

したがって、最も重要な能力は、将来のあらゆるニーズを事前に予測することではないのかもしれません。

その未来が訪れたときに、適応できることなのかもしれません。

PLMはCADデータの管理から始まりました。その後、製品構成や企業プロセスを管理するようになりました。そして、グローバルなコラボレーション、つながったエコシステム、デジタルスレッド、そして今ではAIを支援するまでに進化しました。

次の時代には、また新たな要件が生まれるでしょう。

業界が新たな段階に入るたびに、企業が何十年もかけて築いてきた製品知識、プロセス、デジタル基盤を手放さなければならないようであってはなりません。

企業に必要なのは、自社とともに進化できるよう設計されたプラットフォームです。

だからこそ私は、Arasは設計思想から違うと考えています。

違うからこそ、これから先に訪れる変化にも適応できるのです。