【前編】誰も書かなかったPLMの不都合な真実～PLM導入を失敗しないために～

はじめに

筆者は、長年に渡り多くの製造業企業におけるPLMおよび関連するシステムの導入の支援を行ってきた。古くは、PLMがまだPDMと呼ばれていた1990年代の大手自動車メーカー様向けのPDM導入提案に始まり、以来30年以上の長きに渡り、SIerの立場で、パッケージベンダーの立場で、近年はコンサルタントの立場でPLM導入をご支援してきた。

振り返ってみると、はたして何社のお客様がPLM導入でハッピーになれたであろうか？もちろん、プロジェクトであるので、紆余曲折がありながら、最終的には所定の目標を達成し、無事稼働に辿り着けてはいるが、本当にPLMのコンセプト（これについては後述する）通りの成果を出せたプロジェクトは数少ない。本書では、その反省も込めて、何故PLMの導入は「大成功」に終わらないのか、また、どうすれば成功裏に導入することができるのか、紐解いて行きたいと思う。

本書の対象読者は、PLMに関する基礎知識はお持ちで、これからPLMを導入する企業、PLMを導入はしたが、あまりうまく行ったと実感できておらず、第２弾を企画している企業、また実際にPLMを開発・提供しているパッケージベンダーや、導入を支援するSIerの皆さんを想定している。

執筆者 板東 司 プリンシパル PLMマイスター

PLM/BOMシステム導入を中心としたコンサルティングのキャリアを25年以上持つPLMマイスター。開発・設計・生産準備・製造領域における構想策定からシステム導入等のプロジェクト経験を多数有し、IT企画から導入・運用までのシステム導入ライフサイクル全般におけるコンサルティングとプロジェクトマネジメントを得意とする。

PLMは、Product Life-cycle Managementの略で、直訳すれば、製品ライフサイクル管理ということになる。Wikipediaによれば、「製品（プロダクト）には『企画→開発→調達/生産準備→製造/生産→販売→保守→終売』といった生涯すなわちライフサイクルを見出せる。ライフサイクル全体を1つの管理対象とみなし、一元的に管理する取り組みが商品ライフサイクルマネジメント（PLM）である。PLMの目的にはコスト削減、市場投入期間の短縮、品質向上、環境負荷軽減などが挙げられる。PLMの特徴はライフサイクルにわたる全体最適化である。」とある。PLMという言葉には、文字通り製品のライフサイクル全体を管理する概念、という広い意味もあれば、そのためのシステム（パッケージ）を指す狭い意味もある。今後、システムを指す場合は「PLMシステム」、またその構築のための市販パッケージを指す場合は「PLMパッケージ」と記すことにする。

さて、今日のPLMパッケージは、その名の通り製品ライフサイクル全体を管理することができるものなのであろうか？答えは「否」である。筆者の知り得る限り、代表的なPLMパッケージでは、設計・開発部門の範囲、いわゆるエンジニアリング・チェーン・マネジメント（ECM）の領域はカバーしているが、製造/生産・販売の範囲、いわゆるサプライ・チェーン・マネジメント（SCM）の範囲は、SAPに代表されるERP（Enterprise Resource Planning）パッケージの守備範囲として、「住み分け」が行われている（図表1参照）。

歴史を紐解くと、PLMパッケージの前身であるPDM（Product Data Management）パッケージでは、当初は図面管理や、CADデータ管理の域を出なかったものが、徐々にその適用範囲を拡げて、パッケージベンダーはPLMと名付ける（標榜する）ようになったが、現実は前述のとおり、サプライ・チェーンをERPに押さえられているために、本当の意味でのPLM足り得ていないのである。

また、今日ではDX（Digital Transformation）を実現するための大事な要素として、設計対象の3D化が重要となっているが、3Dデータを、企業活動のライフサイクル全体で、シームレスにフル活用できている企業は稀であり、その活用範囲は限定的で、しかも“つながっていない”のが多くの企業の現状である。 筆者の理解する、PDM/PLMの進化の歴史と、各企業の利用レベルを図表2に示した（各社ポジションについては私の経験した事例ベースでの理解であり、詳細なアセスメントをした結果ではありません）。これからは、「モノづくり」のための「モノ(製造対象物および製造プロセス)」の管理だけでなく、「コトづくり」のための「コト(サービスや稼働情報まで)」の管理も必要となってくる、と考えている。

今日の一般的なPLMパッケージの持つ機能を図表3に示した。PLMパッケージには、エンジニアリング・チェーンにおける重要な情報（部品表（BOM）、CADデータ、ドキュメント、日程、仕様、コスト、など）を管理できる、多様な機能が準備されている。また、 多くの製造業では、PLMシステム構築により、図表4のような姿を目指している。

コンセプトは素晴らしいPLMシステムであるが、何故多くの企業ではPLM導入に失敗するのであろうか？本章では、筆者の経験を元に典型的な失敗事例を紹介する。

１章でも述べたように、PLMシステムの歴史を見ると、元はPDM（Product Data Management）システムから発展して今の姿となっているが、未だにユーザーの頭がPDMの域を出ていない顧客が多く見られる。例えば、筆者が提案を担当したA社の事例を示そう。

なお、「導入方法」の「従来方式」とは、一般的なシステム開発手法であるウォーターフォール開発（企画・構想～要件定義～パッケージ選定～システム実装～導入・運用）を指す。他に、「OOTB（Out Of The Box）方式：パッケージを正として、パッケージ機能に業務を合わせる」や、「アジャイル導入：部分導入→評価→微修正を繰り返す」などもある。それらについての詳細は、後述する。

A社では、IT部門が主導して、ユーザーからの要件（やりたいこと）をヒアリングして、PLMシステム導入の基本方針を定めた。その主な要件は、

①CADとPLMの連携（3D CADデータをローカル管理からPLM管理に）

②E-BOM（設計部品表）と生産準備BOM（生産準備BOMはERPのM-BOM（製造部品表）に連携）の連携

③図面をはじめとする設計成果物の管理

としていた。A社から筆者への依頼内容は、上記をベースにRFP（Request For Proposal：提案依頼書）を作成し、PLMパッケージベンダーに提示し、PLMパッケージベンダーを選定することだった。A社でまとめた基本方針を見て、筆者は真っ先にそのスコープの狭さを指摘させて頂いた。すなわち、今日のPLMパッケージは図表3で示したように、企業活動全般にまつわる多様な機能を持っているが、これら３点だけでPLMシステムの導入を進めて良いのか、また、費用対効果が得られるのか、という点だった。そのため、図表6を作成し、もっと広い視点で検討すべきとして、依頼を差し戻させて頂いた。

もう一つ、スコープの狭さが問題となった事例を示そう。

B社では、長年の課題であった、目的別に存在する各種BOM（E-BOM：設計部品表、M-BOM：製造部品表、S-BOM：サービス部品表、等）を統合し、一元管理することを実現するためにPLMシステム導入を企画した。それまでも、当然、設計部門が作成するE-BOMから、製造部門が利用できる形のM-BOMへの変換（具体的には、ERP上のM-BOMの登録）や、そこからサービス部門が管理するS-BOMへの変換は、業務上は実現していたが、それは手作業によるものだったため、非効率でミスの可能性も排除できなかったものを、PLMシステムを導入して、できるだけ自動的に、間違いなく実施できるようにすることを狙ったものだった。狙い自体は悪くなかったのだが、情報の源流であるE-BOMを管理するシステムが巨大なレガシーシステムであり、そこまで一気に踏み込んで見直そうとするとプロジェクトが大きくなり過ぎる（システム部門ではハンドリングできなくなる）ことと、E-BOMの主幹部門である設計部門が業務多忙でプロジェクトに本格的に参画できない、という政治的理由により、E-BOMはノータッチとし、E-BOMが作成されて以降を管理するシステムとしてしまった（図表8）。

このため、本来であれば部品表統合により受けるはずの多くの恩恵（後工程でのビューワーデータの活用、等）や、PLM利用の主役であるべき設計部門の改革が議論されないまま導入が進み、巨額の投資をしたにも関わらず、その名の通り単なる「統合部品表」システムになってしまった。B社ではその後、E-BOMの再構築にも着手し、既設の「統合部品表」と連結するプロジェクトが進められている（進行中）と聞いている。

次の事例は、「PLMパッケージ導入」ありきで失敗した事例である。
PLMシステムの導入費用は、パッケージのライセンス費用を含め、企業規模にもよるが、数億から数十億かかるものなので、決して安いものではない。にも関わらず、
「（他社もやっているので、）我が社もそろそろPLMを」
「DXのためにはPLMが必要」
といった安易な動機でシステム導入に着手してしまう例が少なからずある。確かに、PLMは製造業がDXを実現するための必要条件のひとつではあるが、決して十分条件ではない。DXについても、まず「D（Digital化）」ではなく、まず「X（Transformation：業務改革）」があり、それを実現する手段としてDigitalを用いる、と考えるべきだ（図表9）。

例えば、科学機器メーカーC社の場合、自分達で企画構想を行い、要件をRFP（Request For Proposal：提案依頼書）にまとめたので、提案して欲しい、と依頼があった。そのRFPを一読して、「これではうまく行かない」と直感し、その理由と共に提案を丁重にお断りさせて頂いた。その主な理由は以下のようなものだった。

①業務の課題解決を突き詰めて考えられていなかった（掘り下げ不足）。例えば、「設計図面のあいまいさ」が問題点として挙げられていたが、その本質的な原因が何なのかが突き詰められていなかった。

②PLMパッケージを入れて、そこに業務をフィットさせれば、業務改善ができる、と考えられているふしがあった。RFP上は機能の羅列だけで、何時・誰が・どのようにデータを登録し、利活用するのかが描かれていなかった。

③当面のPLMパッケージ導入（既存PDMパッケージの置き換え）が優先され、最終形のPLM-ERPが立ち上がった時の姿が描けていなかった。特に、基幹データであるBOMをどのように登録・連携させるのかのシナリオがなかった。

私どもとしては、上記のような課題を解決するために、改めて業務/システム/データの全体像を描く、グランドデザインのフェーズを実施させて頂きたい、と申し入れたが、すでにスケジュールも設定し、デッドラインに向けて動き出しているから、と聞き入れてはもらえなかった。本件は、グランドデザインの必要性が理解されない限り、責任を持った結果を出せないため、お断りさせて頂いていた。

同様のケースとしては、図表11の事例もある。こちらの場合も、既存PDMパッケージのサポート切れ期限が迫っていたため、「先ずはパッケージ入れ替えを優先」させ、その後業務改革に取り組もう、というストーリーであったが、費用対効果の説明が付かず、社内決裁の段になり頓挫してしまい、現在作戦を練り直しているところである。

D社の事例で特徴的なのは、導入方法が「OOTB方式」という所である。これは、グループを統括するホールディングス社の意向もあり、全グループで統一されたPLMパッケージを、カスタマイズすることなく、ほぼそのままSaaS導入しようという意欲的な取り組みであった。その取り組み姿勢自体は良かったのだが、D社への展開では、業態の違い（ホールディングスとしてのメイン事業はB2Cの量産型、D社はB2Bの個別受注型）や、使用しているCADの違いや3D化の進みの違いもあり、そのままではうまくコストメリットを出せないという結論に至った。このプロジェクトについては、現在グランドデザインから見直そうとしている。

次の事例は、PLMシステムを魔法の箱だと幻想を抱いたE社のケースである。E社では、既存PLM（レベルとしてはPDM）パッケージを新PLMパッケージに置き換えるのを機に、PLMパッケージに備わっている世の中のベストプラクティスの業務に自分達の業務を合わせ、最先端のモノづくりを目指そうとしていた。この考え方は、ERPの世界では良くある話で、実際にそのような導入を行い、成功した企業も多くあるが、PLMシステムでも同様にうまく行くかは、筆者は疑問を持っている。

PLMパッケージベンダーの多くは、「弊社のPLM導入でベストプラクティスの実現を」と良くセールス活動の場で説明するが、筆者は、PLMパッケージ自体は極論してしまえば「ただの情報の箱」であり、そこには業務プロセスは存在しないと思っている。すなわち、ERPであれば、ある製品を製造・販売するためには、リードタイムを考慮していついつまでに部材を発注する必要があり、その個数はいくつで、単価はいくらで、使用する発注書はこの形式で、と定型的な業務を定義できるが、PLMが対象とする開発・設計の世界は定型化が非常に難しいため、機能の定義はあっても、標準の業務プロセスを定義し難い、ということだ。極端に言えば、定型化できるのは、例えば図面を承認してもらう承認ワークフローや設計変更時の変更ワークフローなど、限られた範囲でしかない。その限られた範囲をつなぐ開発・設計全体の業務の流れは、それこそ千差万別で、作る対象が異なれば、流れは無限に存在する。もちろん、PLMの世界でも想定業務フローは存在するが、設計行為そのものは創作活動である以上、定型化できないのが現状だ。

最も分かり易く、端的な例で言えば、開発・設計のアウトプットとしてのBOMを考えると良い。図表13は、端的なE-BOM/M-BOM問題であり、設計者が純粋な機能構成を登録すべきか、製造を意識した構成を登録すべきかであるが、その企業の文化もあり、どちらにすべきかは、一概には決められない（BOMのあるべき姿については、4-2節で詳述する）。PLMパッケージを導入すれば、世のほとんどの製造業で必要とされるBOMを定義することは可能だが、どんなBOMにすれば良いかをPLMパッケージが決めてくれる訳ではない。BOMをどんな単位で定義し、（履歴含めて）品番をどう表現するかや、バリエーション（色違い等）や製造の都合（工程や材料：M-BOMの範疇）をどう表現するかは企業文化そのものであり、一概に「これがベストプラクティスだから、この通りに登録しなさい」と言えないのが実情だ。

もちろん、PLMパッケージベンダーが推奨する「ベストプラクティス」は、これまでにそのPLMパッケージを使う上でうまく行った成功事例なので、参考にはなる。ただし、あくまで参考で、実運用に当たっては、自社に合ったデータモデルやプロセスをデザインし、共通認識の上で使用する必要がある。

また、いわゆるPLMの全ての機能をPLMパッケージベースで実装しよう、というのも無理がある。例えば、開発段階での開発・設計部門のドキュメントを全てPLMシステムに格納し、参照できるようにする、というのはある意味「あるべき姿」ではあるが、それをPLMパッケージで実現してしまうと、開発・設計部門のドキュメントを参照する全ての部門でPLMパッケージのライセンスが必要となってしまう。PLMパッケージのライセンス費は、お世辞にも安いものとは言えないので、費用対効果を考えたシステム構成を考える必要がある（注：例えば、BOMやドキュメントの参照のみの機能に限定し、比較的値ごろ感を出した「参照ライセンス」のようなものを用意するパッケージベンダーもいる）。

良く見る事例として、過去の自分達の仕事のやり方に拘り、その通りに使えないと現場で受け入れられない、として、現状追従で要件を盛り込み過ぎ、カスタマイズのお化けとなり、開発期間・費用が膨大となり、さらにパッケージのバージョンアップの際に多大な工数・費用が必要となる（もしくは、バージョンアップが現実的に不可能なため、あるバージョンにロックされる）というケースだ。

F社では、複数ある事業部門毎にユーザーの要望を聞き、個別のカスタマイズを実施した結果、せっかく同じPLMパッケージを導入したにも関わらず、事業部専用カスタマイズ群となってしまい、保守負荷に耐え切れず、PLM刷新に至ってしまった。PLM刷新に当たっては、既に実施していた個別カスタマイズが、ユーザーの利便性を上げるきめ細かい対応だったことが仇になり、OOTB導入を基本方針とした新PLMの要件決めに苦労することになった。エンドユーザーは、自分の日々の仕事のやり易さ（手数が少ないこと）に目が行きがちで、会社全体最適の視点（自分達が多少苦労してでも、後工程の利便性を上げる）を持て、と言われても難しいことが多々ある。

先に紹介したB社の設計部品表システム再構築プロジェクトでも、同様のことが発生した。すなわち、既存の設計部品表システムは図面ベースでの業務を前提として最適化されており、かつ、技術部が担当するあらゆる業務（設計そのものだけでなく、試作の手配や、原価の管理）を詰め込んだものであったため、これを3Dベースの最新のPLMパッケージに置き換えようとしたときに、「あの機能はどうなる、この機能は継承されるのか」という議論が噴出し、本来行われるべき議論（3Dベースでいかにコンカレント化／業務のフロントローディングを進めるか？）に集中できない事態となってしまった。

これもPLMパッケージを導入しようとしたとき、陥りやすい事態だ。G社では、PLMシステム刷新に当たり、上位方針もあり、「自分達に適したPLMパッケージを公平に選定する」こととした。これ自体は決して悪いことではなく、当たり前のことではあるが、あまりに真面目にやり過ぎたため、多くの工数・期間を要し、挙句に「機能では大差なし。最終的には価格勝負」となってしまった。

図表16で、一般的なウォーターフォール型でのパッケージベースの開発プロセスを示した。これ自体は、昔ながらの開発の進め方で、誰も「間違っている」とは指摘できないものだろう。しかし、ビジネス環境が早い周期で変化する現在において、このやり方は本当にあるべき進め方なのであろうか？システム企画も、要件定義も、必要とする期間は、対象とする業務範囲や、取り組むスコープによって大きく変化するが、筆者の経験上、PLMシステム構築であれば、システム企画で3～4ヶ月、要件定義で4ヶ月～8ヶ月かかってしまう。その上で、RFPを作成し、精緻な評価表を作成し、パッケージベンダー複数社にプレゼンしてもらい、評価を行い、マネジメントにも納得できる評価結果とともにパッケージベンダーおよびパッケージを選定することに、どれだけの労力を要するかは、経験した方なら想像できるだろう。そして、このようなことをしている間にビジネス環境が変わり、要件そのものが陳腐化してしまっては、かけた労力は大いなるムダとなってしまう。また、ユーザーの要望通り要件定義してしまうと、要件が膨らみ、パッケージ機能だけで吸収し切れず、カスタマイズ量が多くなってしまうことは、2-4節でも紹介した通りだ（必ずしも、要件定義を行い、それに沿ったシステムを構築することが良くない、という訳ではない。例えば、筆者の担当したあるお客様では、「社員一人一人に寄り添ったシステム構築」をIT方針とし、徹底したユーザー中心のシステム構築を行い、自分達のビジネスモデルを達成する最適なシステム化を行っている。もちろん、それを実現するには、確たるIT方針と、それに沿ったITガバナンス体制の構築が必要となる）。

私たちも、顧客の要望により、公平な立場でのパッケージベンダーおよびパッケージ選定をお手伝いすることもある（図表17参照）が、最終的には顧客が「何を重点に選定したいのか？（CADとの連携度合いが重要なのか、分かり易さや操作性が重要なのか、価格が重要なのか、将来の拡張性が重要なのか、等）」の意志を明確に持っていないと、迷走してしまうことがある。

少なくともハイエンドに属するメジャーなPLMパッケージであれば、どれを選んでも大して変わらないと筆者は思っている（もちろん、それぞれのパッケージで、使い勝手、得意な領域や特徴、目指す世界の違いはある）。大事なのは、意志を持って、必要最小限の工数でクイックに決めることではないだろうか。例えば、いわゆる3大PLMパッケージは、元々は自社のCADデータを管理するために生まれたものであり、CADとの密連携（CAD BOMとE-BOMの連携）については、それぞれ「マルチCAD対応」を謳ってはいるものの、もちろん自社CADとの連携が一番スムースであることは自明である。CADとの密連携を重要ポイントとするのであれば、メインとしているCADのベンダーのPLMパッケージを選択することには合理性がある。

２章では、導入失敗の事例を見てきたが、ではどうすればPLM導入に成功するのか？この章では、筆者の経験からのコツを紹介したい。

まず、PLMについて論じる前に、国内におけるDXの現状や課題を経済産業省発行の『DXレポート』や、IPA（独立行政法人情報処理推進機構）発行の『DX白書』などから概観しておく。ご存知のように、2018年に経済産業省により『DXレポート』が発行され、海外に比べてDXが立ち遅れていること、また、そのまま放置すると、いわゆる「2025年の崖（日本全体で2025年に年間12兆円の損失）」が発生することに警鐘が鳴らされた。それから5年が経過し、国内企業のDXへの取り組みの現状はどうであろうか？ちなみに、DXの定義については、DXレポートで図表18のように示されている。DXの本質は、内部エコシステムの変革だけでなく、外部エコシステムを含めて変革し、企業としての競争優位性を確立することであるという点に留意すべきであろう。

経済産業省『DXレポート』P3より引用

また、DXの構造については、図表19のように示されている。デジタイゼーションもしくはデジタライゼーションだけを目指してDXプロジェクトと呼び、推進している企業が多いが、上記のように、それだけでは本質的なDXとは言えない。

経済産業省『DXレポート2』P34より引用

さて、DX取り組みの実態については、経済産業省発行の『DXレポート（2018年9月版）』、『DXレポート2（2020年12月版）』、『DXレポート2.1（2021年8月版）』、『DXレポート2.2（2022年7月版）』および、IPA発行の『DX白書2023（2023年2月版）』に詳しく報告されている。それによると、IPA調査の「DX推進指標（DXの取り組み具合を5段階で自己診断可能としたもの）」を集計した結果、自己診断を提出した企業（2020年で223社）の中で、約95%の企業はDXにまったく取り組んでいないレベルにあるか、DXの散発的な実施に留まっているに過ぎない段階であり、全社的な危機感の共有や意識改革の推進といったレベルにはいたっていない（『DXレポート2』、P8より引用）、とのことである。さらに、この数字は自己診断に協力した企業における数値であり、水面下には診断結果を提出していない多数の企業があるので、実質はさらに取り組みが進んでいないと推察できる。

経済産業省『DXレポート2』P8より引用

さらに、大企業と中小企業における指標の詳細を見ると、その差が大きいのは、「経営トップのコミットメント」、「推進・サポート体制」「推進体制」「ロードマップ」「プライバシー、データセキュリティ」の５項目となっている。すなわち、中小企業では、これらの点が主なネックとなり、DXが大企業よりも立ち遅れている実態が見て取れる。

本節の最後に、DXの取り組み領域毎の成果（「十分な効果」と「ある程度の効果」の合計）について見てみると、「アナログ・物理データのデジタル化（76.1%）」や「業務の効率化による生産性の向上（78.4%）」では、すでにある程度成果が出ているが、「新規製品・サービスの創出（24.8%）」や「顧客起点の価値創出によるビジネスモデルの根本的な変革（21.5%）」ではまだ成果に結びつけられておらず、米国と比べても見劣りしている。

IPX『DX白書2023』P14より引用

２章で見てきたように、PLMシステム構築が目的化してしまい、構築したシステムの上でどういう業務としたいのか、が描けていないケースが見受けられる。3-1節でもDXの号令がかかりながら、デジタイゼーションのレベルで留まっているケースが多いことを示した（図表22）。そういった事態を避けるためにも、PLMシステムありきでなく、先ずは業務上、何を変えたいのか、何を実現したいのか、それによりどういう効果を得たいのか、を明確にし、社内で共有するグランドデザインのフェーズが必要と考える。本来のDXの意味で言えば、ITを活用したビジネスプロセスの変革までデザインできると良い。 例えば、精密部品メーカーのH社では、「設計せずに造る」をコンセプトに、設計ルールをPLMとCADに実装し、設計工数の抜本的な改革を実現し、浮いた人材を新規事業の開発にリソースシフトすることを企画した（図表23、図表24）。

なお、「PoC方式」とは、小さな単位で効果の検証（PoC：Proof Of Concept）を確認しながら、漸近的にゴールを目指す方式のことを指す。

設備メーカーのI社では、「簡単なものは簡単に、難しいものは丁寧に」をコンセプトに、製品の標準化を実施し、標準品もしくは標準品＋オプション品である範囲の受注は営業のみで受注活動を行い、短納期・低価格で販売を行い、顧客特注仕様の場合はエンジニアが介して丁寧な対応（カスタマイズ）ができる仕組みを企画した（図表25、図表26）。

この取り組みでは、トランザクション（案件毎のBOM）しかなかったそれまでのBOM管理の仕組みに、PLMの持つ製番BOMの機能を用いて、マスタ（標準）とトランザクション（案件毎）のBOMを明確にするとともに、トランザクションのBOMをそのままサービスのBOM（図中では「④トランザクションS-BOM」。いわゆる「As-Maintained BOM」）に連携し、この会社の大きな収益源であるサービス業務の効率化および質向上を目指した。

機械メーカーのJ社では、業務プロセスや設計思想を大幅に見直し、事業のあるべき姿、業務のあるべき姿を決めた上で、改革・システム導入を推進することで大幅な効果を獲得することができた。

医療機器メーカーのK社では、PLM導入を機に、３工場でバラバラだった業務プロセスを標準化し、「共通業務プロセス（モデルプロセス）」を合意した上で、その業務プロセスを実現するに最適なPLMを選択/導入することで、工場毎個別カスタマイズをなくすとともに、工場間で、どこに行っても、同じ言葉、同じプロセスとすることで、人材流動性も高めることができた。なお、改革案の検討・合意は事業部門で、事務局はシステム部門で推進した。

一般的に、PLMは情報共有基盤であるため、DXのXは描きにくいかも知れないが、適切なグランドデザインのフェーズを設けることで、これまで見てきたような姿を描くことが可能である。PLMでの典型的な効果は、情報を部門毎に囲い込むのではなく、適切なステータスとアクセスコントロールの元に早期に開示し、後工程業務をフロントローディングすること、言い換えれば、コンカレントエンジニアリングを実現することであると筆者は考えている（図表４参照）。また、最近では3D設計が進んでおり、PLMは3Dデータを共有/活用する良い基盤となっている。3Dを起点に顧客接点やサプライヤを含めたエコシステム全体を改善する事例も多数ある（図表31）。その上で、さらに企業毎の特性に合わせて、DXに相当する改革を描くことが肝要である。

さて、このようなDXのX（目的）優先のＤ（手段）を描くグランドデザインは具体的にはどのように進めれば良いのだろうか？図表32に、我々の標準的なグランドデザインの進め方を示す。経営・業務・システムの３つの視点で現状把握と、あるべき姿を描く。この進め方で、体制にもよるが、概ね3ヶ月～4ヶ月のプロジェクトとなることが多い。

あるべき姿の定義においては、業務（プロセス）/データモデル/データ生成ルールのトータルデザインが重要であると考えている（図表33）。グランドデザインの結果を受けて、業務テーマ（例えば、設計の標準化や、受注活動のフロントクローズ化）を引き受ける業務改革の流れと、システムテーマを引き受けるIT導入の流れと、枝分かれして進んで行く（図表34）。スコープをどこまでに設定するか、また、取り組みの順番を業務テーマとシステムテーマを並行で進めるのか、直列で進めるのか、など、描いたグランドデザインと企業毎の予算や優先度により異なることになる。

システムテーマとして、PLMシステムの構築が必要/適切であれば、グランドデザインで定めた目指す姿を実現するのに最もフィットするPLMパッケージを選択し、PLMシステム構築プロジェクトにつなげる。

図表35に、2章の失敗事例の一覧を示した。これを見て分かるように、これらの事例は全てシステム部門主導で導入を推進し、結果的に失敗している。システム部門主導で進めると必ず失敗する、という訳ではないが、やはりシステム部門主導であると、D先行となることが一因でないかと思っている。

筆者が数多くのお客様のPLM導入を支援させて頂いてきている中で、システム部門がプロジェクトを取り仕切っていると、どうしてもシステム部門＝推進者、事業部門＝お客様のような構図ができてしまい、事業部門の色々なエクスキューズ（例えば、業務多忙、例えば、その企業にとっての顧客事情）を受けて、プロジェクトが停滞したり、スコープがシュリンクしがちに見える。やはり、最終的なシステムの受益者（＝ユーザーである事業部門）が主役となって、主体的なプロジェクト推進を行うことが重要と考える。

また、プロジェクトへの経営層の参画が必須とも考える。図表３２でも示したように、グランドデザインには、経営の意志、ビジネスの方向性のインプットが必要となる。また、プロジェクトであるので、必ずどこかで「想定外のこと（費用超過、部門間の軋轢、等）」が起こるが、その時に決断できるのは誰か？を考えると、その必要性は自ずと明らかである。弊社の調べではあるが、図表３６に、カスタマイズをする際の意思決定者とカスタマイズ規模には相関があり、プロジェクトの方針としてOOTBを掲げるケース（図表３６で「プロジェクト方針」として表現）や、役員クラス/プロジェクト責任者が意思決定するケースではカスタマイズ規模が小さくなる傾向がある（カスタマイズが多いことが悪いことかどうかはプロジェクト方針にもよるが、少なくとも、費用へのインパクトはあることは確かである）。

ここで言う「ベンダー」は、自社のパートナーとして、何らかの契約を取り交わしてプロジェクト推進を支援してくれる企業のことを言う。具体的には、「コンサルタント」、「SIer（自社配下のシステム開発会社も含む）」、「パッケージ提供会社」に分類できる。

まず、グランドデザインで、業務のあるべきを描く主体は、当然のことながら自分達（経営、事業部門、システム部門）であるが、他社の事例を提示しながらリードしてもらう役割として、我々のようなコンサルタント会社をうまく利用すると、社内合意を形成しやすく、ゴールに効率良く到達できる。また、このフェーズでパッケージ提供会社が示す、いわゆる「ベストプラクティス（グローバルワイドでうまく行っている事例）」も大いにヒントにできるので、うまく活用すると良い。

図表37に、大まかなフェーズ毎に、寄与可能なベンダー種別を提示した。コンサルタントは、基本的にシステム実装までは主戦場とはしないが（SIer機能を持つコンサルタント会社もある）、システム実装の場面まで、PMO的に関与し、最終的に運用を立上げ、グランドデザインで描いた効果の刈り取りをするところまで確認することも可能なため、カバー範囲とした。また、パッケージ提供会社は、前述のようにベストプラクティスを提示しながらグランドデザインに寄与できるが、一般的には経営戦略や商品戦略に関わる所の支援はターゲットとしていないため、少し範囲を狭めさせてもらった。

図表37にグローバル市場におけるPDM/PLM導入の傾向（実績）を示した。パッケージ機能の充実（ベストプラクティスの標準機能への取込み）と、バージョンアップ性確保の観点から、パッケージ売り切り（31.5%）／サブスクリプション（30.5%）と、世界市場ではカスタマイズを抑えた導入が主流となっている。このような、基本的にパッケージを買ってきて、ほぼそのまま吊るしの状態で使うことを、「OOTB（Out Of The Box）」や、「Fit to Standard」と呼んだりする。2-4節で示したように、自社要件に合わせてカスタマイズすることの弊害を反省し、そのような方針をプロジェクト方針として掲げる企業も増えている。例えば、家庭用ロボットで有名なiRobotであるが、OOTBでWindchillを導入し、企業成長に伴い範囲を拡大しながら、うまく使いこなしを行っていると報告されている（図表39）。

さて、これからのPLM導入はどうあるべきか？を考えた時、2-4節、2-5節で示したような、従来型のウォーターフォール型の開発ではなく、PLMパッケージを前提とした、OOTB導入を目指すべき、と考える。従来型と同様、システム企画（ITグランドデザイン）は必要だが、そこから業務要件定義に入るのでなく、その企画内容にフィットするPLMパッケージをその時点で選択し、その機能を前提に、どう使い倒すかを検討する「運用定義」のフェーズを設けるということを提唱したい（図表40）。なお、システム企画後に、RFPを作成してパッケージとベンダーを選定するフェーズを設けるかどうかは、必ず複社見積りを必要とするなど、各企業の方針・判断に委ねる（何らかの決定要因で一択にできるならば、その分の期間と工数を低減できる）。

パッケージおよびベンダー（パッケージベンダーとSIer。両方の機能を１社に委ねることも考えられる）を選定した後でやるべきことは、選定したパッケージの機能を良く理解した上で、いかに自社の業務をそのパッケージの想定運用に載せるかを検討する「運用定義」である。その中では、現場からは「ここがこれまでのシステムと使い勝手が違い、使いにくい」、「手数が増えた」といった操作面での不満が出がちであるが、「どうしてもこれに対処しないと、業務上多いに支障が出る」というものに限定して対応を考えよう。オペレーションレベルの不満は、言い方は悪いかも知れないが、「そのうち慣れる」ものである。また、ユーザーから出た要件に対応するにしても、PLMパッケージのパラメタ設定で回避するのか、エクセル出力やRPAもしくはノーコード（NC）/ローコードツール（LC）などを活用して外付けで対応するのか、PLMパッケージ自体をカスタマイズするのか、選択肢があるので、やはり業務への影響とかけるコスト（対応費用、維持費用、等）の利害得失を考えて決定する必要がある（図表41）。

運用定義の具体的事例としては、3D CADのBOM（D-BOM）から、設計BOM（E-BOM）、製造BOM（M-BOM）をどう生成し、連携・保持させるのかは、PLMパッケージを入れれば自ずと決まるものではなく、導入企業毎にその登録単位や誰が何時どんな情報を入力/参照するのか千差万別であるため、おのおのが運用ルールを決めなければならない（図表42）。逆に、しっかりした運用ルールがないと、情報や組織や人によりバラバラになり、大事な資産であるはずの過去の機種の情報などが参照・流用できなく（しにくく）なってしまう。PLMパッケージにとってのベストな登録方法や運用は、パッケージベンダーが過去のベストプラクティスベースに示唆してくれるが、最終的に決めるのは、ユーザー自身である（もしくは、私たちのような経験豊富なコンサルタントを使うのも良い）。

後編はこちらから