AACテーマ別特集頁(PLM編、PLMシステムを導入済、導入中、導入予定の製造業様へ)
目次
4 PLM導入について
5 PLM製品の選び方
6 PLM導入で失敗しない為に
*1 クリックしたら該当箇所に移動します。
*2 一部建設業も含んでいます。
---------------------------
PLMとはProduct Lifecycle Management(製品ライフサイクル管理)の略で、製品の企
画・見積から再利用・廃棄までの一連の業務プロセスで情報共有する仕組のことです。
本書は以下の方々を対象にしています。
(1) PLMを勉強したい方
(2) 新たにPLMを導入する会社様
(3) 既に導入・運用しているが課題もある会社様
(4) 購入しているが、充分に運用されていない会社様
(5) 導入に失敗して、次のPLMシステムを検討中の会社様
(6) PLMシステム構築中だが、進め方の妥当性を顧みたい会社様
(7) 自社PLMシステムやPLMプロジェクトを検証したい役員クラス様
などです。
当社では製造業の組織を8つの機能部門に分けて考えており、各機能部門、部門間連
携等のPLMシステムを想定しています。
8つの機能部門とは、
(1) 企画・見積(量産品か一品物によって異なる)
(2) 設計
(3) 調達
(4) 生産(生産技術含む)
(5) 物流
(6) 販売・納品(量産品か一品物によって異なる)
(7) 保守
(8) 再利用・廃棄
を指します。(下記”DX概念図”参照)
昨今、DXと呼ばれているデジタル変革、感染症対策やカーボンニュートラル等、製造
業特有課題以外の人類共通の課題にも対応する必要があります。
下図は当社の考えるDX概念図ですが、元々はPLM概念図でした。
DXを考えた時、運用時にはPLMとの連携が必要になると考えた為、DX概念図として
拡張したものです。
当社のDX概念図(DXと連携するPLMを弊社ではDXPLMと呼んでいます)
DX概念図の説明
(1) 8つの機能部門を想定しています。(茶色)
(2) 中心のDBはPLMとIoT、AI、XR等DX要素と連携します。(赤色)
(3) 各部門で想定される機能は黄色部分です。(黒文字)
(4) カーボンニュートラルは全機能部門での対応になります。(緑色)
(5) 関連する技術は輪の外の四角内です。(青色)
当社の製造業様ご支援では、このDX概念図をベースに考えています。
これ以外にPLMシステムやDXPLMシステムの構築についてはまとめ役
として要になる情報システム部門があります。
更に外部のコンサルティング会社、PLMベンダー、システム構築会社等
が登場する場合もあります。
本書では、これらのうち、PLMに焦点を絞って深堀させて戴きます。
(実際の導入時には個別状況やご予算都合もありますが、ここでは除きます)
また、当社はPLM有識者(元大手SI会社でのPLM構築経験者、元大手製造業での
PLM構築経験者、PLM利用経験者)が中心であり、本書でも
れて完成させています。
当社PLM有識者には複数の有力なPLM製品経験者も含んでいる為、有力なPLM製
品を視野に入れた上での解説書として完成させました。
補足ですが、本書の図は殆どを従来の当社ホームページに掲載していますが、ここで
は詳細に解説致します。
2022年10月22日 初版
2023年 1月15日 改訂
2 本書の目的
本書の目的は、PLMを正しく理解し、様々な課題に対応してQCDVSG追及の為に、製
造業の背骨であり、心臓部分でもあるPLMシステムをどのように構築するのかのヒント
をご提供させて戴くことです。
”QCDVSG”は当社の造語で、以下用語の頭文字を取ったものです。
Q: Quality(品質)
C: Cost(コスト)
D: Delivery(納期)
V: Value(付加価値)
S: Service(サービス化)
G: Green(環境対策)
を意味します。
QCDは従来からある言葉ですが、そこに製造業がこれから目指すべきVSGを追加した
ものです。
3 PLMのありたい姿
PLMの目的は部門間で必要な情報を共有し、QCDVSGを追及して企業活動に貢献す
ることです。
ありたいPLMシステムとは、QCDVSG追及を実現出来るPLMシステムということにな
ります。
DXを想定したPLMは従来のCAD/CAM/CAEやドキュメント管理との連携だけでなく、
IoT、AI、XR等DX活用に必要な技術分野との連携も必要と考えています。
理由は、如何なる新技術も自社製品に関わるものであり、その製品情報管理をしてい
るのがPLMシステムだからです。
これらを図にしたものが、当社HPにも掲載されている、上図DX概念図であり、業務改
革を反映した下図DXグランドデザイン例です。
4 PLM導入について
PLMという言葉は2000年頃から使われ始め、それまでは設計部門でクローズしてい
たPDMが事業部門全体で共有する仕組に進化したものです。
(”PDM”を”PLM”に読み替えた使い方をする人達もいますが)
1980年代は生産部門を中心とした部品表(BM、今で言うMBOM)をメインフレームでス
クラッチ開発もしていましたが、その後、主に設計部門の部品表(EBOM)を中心に情報
共有するPLM製品が登場しました。
(今は殆どの機器にソフトウエアが組み込まれており、ソフトウェアBOMとも言います)
製造業ではこれらPLM製品を導入し、業務をPLM製品に合わせたり、Fit&Gapを経て
不足機能をカスタマイズして来ました。
あるPLM製品を導入して浸透せずに(失敗して)別のPLM製品を導入し直すことも多々
あります。
当社では、このような失敗を回避する為に、PLM製品選定をどのように進めるべきかに
ついてもご説明させて戴きます。
業務要件にはPLM製品に関係なく必要になる機能、PLM製品も意識した業務要件があ
り、PLM製品に依存する機能、GUI、DB、API、ローコード、ノーコードを意識した基本
設計につながります。
下図”PLM構築アプローチ”はそれらを図にしたものであり、開発工程に応じてシステム
構築をして行きます。
一般的に情報システム部門はシステムに詳しくて、ユーザ部門は業務に精通していま
す。
PLMに限らずですが、業務システムを導入するには、業務とITの両方がわかる技術者
が必要で、どちらか一方で単独に進めると、目的を達成する為のPLMシステムは実現
出来ません。
そこで重要なことは情報システム部門とユーザ部門が協力して行う導入準備です。
社内のプロジェクトオーナ/マネージャ等の選出も必要になります。
導入準備については最低でも以下の工程が必要です。
(1) 背景(どのような背景でPLM導入するのか)
(2) 目的(何の為にPLMを導入するのか)
(3) 基本方針(PLM構築における基本方針は?)
(4) WBSの作成(大工程、中工程、・・・、要件定義含む)
(5) 体制、マスタースケジュール(中工程レベル以上)、成果物、ゴール等
(6) 経営課題定義、業務課題・システム課題抽出、整理、分析等
(7) 課題解決協議
などです。
これらの準備無しで下記要件定義以降に着手してしまうと、要件定義や基本設計時に
迷路に入り込んでしまいます。
個々の要件の採用判断時に判断基準がない為です。
全部門の要件を満たす答えがない場合もありますが、その場合は調整作業が必要で
す。スモールスタートとしてアジャイル開発で肉付けする方法もあります。
導入準備が整った後、開発工程として
(1) 要件定義(業務内容・業務フローの見直し、帳票類、Fig&Gap含む)
(2) 基本設計
(3) 詳細設計以降(詳細設計、実装、総合・運用テスト、文書)
(4) テスト(結合テスト、総合テスト、運用テスト
(5) 運用開始
(6) 課題解決検証
につながります。
これらを図にしたものが、下図”AAC V字モデル”です。
特色は、コンサルティングエリアとSIエリアに分けて、SIにつなげる為のコンサルティン
グであることです。またコンサルティングエリアには検証工程も入っています。
AAC V字モデル
コンサルティングエリアは上記”導入準備”に相当し、SIエリアは上記”開発工程”に相
当します。BPRとIT化検討は同時並行で進めることも多いです。
PLMシステムの導入は他のアプリケーション導入と違って業務とITの両方の知見が特
に重要であり、情報システム部門とユーザ部門の密連携が必要となります。
現在、世界で主要なPLM製品は以下の通りです。
(1) Aras Innovator(米Aras社製)
(2) TeamCenter(独シーメンス社製)
(3) Windchill(米PTC社製)
(4) ENOVIA(仏ダッソー社製)
(5) ENTERPRISE PDM(現在は仏ダッソー社製)
です。
日本国内ではそれ以外にも
(6) Obbligato(日本電気製)
(7) PLEMIA(富士通製)
などがあります。
PLM製品の選び方には様々な方法がありますが、一番多いのはCADを先に導入して
いて、特にPLM製品としての評価作業をせずに同じメーカのPLM製品を導入するケー
スです。
先のPLM製品も殆どが同じメーカでCADも開発・販売しています。
しかし、PDM導入は設計部門だけの運用でしたのでCADの延長でも良かったのです
が、PLM導入は設計部門やCADの都合だけを考える訳には行きません。
特定のCADに属していないのはArasですが、何を優先するかによって選び方も変わり
ます。
CADメーカとPLMメーカが同じ会社の場合、CAD機能を最大限生かすことには優れて
いますが、
その機能は本当に必要なのか
代替方法はないのか(特にCADの仕掛管理)
複数CADを使っていたらどれに合わせるのか
取引先との情報共有が必要な場合はどこからどんな情報を出すのか
などの課題が残ります。
当社では、一旦CADの都合は保留にして、PLMに何を求めるのかを明確にして、客観
的視点でPLM製品を選ぶべきと考えます。
(最悪はCAD用PDMとPLMを分けて導入し、内部で連携させます)
そのような視点に立った時、特定CADに依存しないArasも選定候補に上がって来ること
になります。
また、Arasはライセンスフリーであり、サブスクリプション契約をしないうちは無料で
使うことが出来る為、本格導入の前に大金をかけずにPLM製品評価作業を行うことが
可能なので、正しい手順さへ踏めば、比較的失敗は少ないと思われます。
PLMシステムの導入は失敗を繰り返す傾向(特に大手製造業)がありますが、何故失
敗したのかを分析し、その失敗経験を最大限に生かして、最低でも2度目のPLM製品
では成功させたいものです。
失敗したからと言って、必ずしもPLM製品が原因だったとは限らず、上記のような導入
準備に問題がなかったか、プロジェクトの進め方に問題がなかったかなど、PLM製品以
外の原因も見極める必要があります。
ここでは、PLM製品選定でどのような失敗ケースがあるかについて、例として10個程ピ
ックアップして、回避方法についても解説してみたいと思います。
(失敗を回避すれば、成功への道に近付きます。)
(1) 使用CADの延長上で選定する場合
殆どのCADには同じメーカが提供しているPLM製品があります。
(PDMと呼んでいた製品含む)
PDMの範囲(設計部門内)であればそれでも良いケースはありますが、PLMは
生産部門、調達部門、営業部門など、関連する部門の要件をも取り入れる必要
があります。
この場合、PDMの延長で選んだPLM製品では対応困難なケースもあります。
結果として、カスタマイズが巨大になり、スクラッチ開発に近づいてしまい、
そのPLM製品から抜け出せなくなります。
回避方法としては、一旦PDMとPLMを分けて考え、使用CADの延長で選んだ
PDM製品が、PLMシステムとしても対応可能かどうかを判断してPLM製品選定
の見直しをすることです。
構築上の注意事項としても、CADで設計してCADBOMをEBOMにするのか、先に
EBOMを定義してからCADで設計するのか等の課題もあります。
(2) PLM製品の評価作業をせずに選定する場合
PLM製品選定の経緯として、自社の業務プロセスや業務内容を把握せずに選定
してしまうケースがあります。
「導入すれば何とかなる」、「導入して走りながら考えれば良い」など、見切り
発車して導入するケースです。
PLMは製造業の背骨であり心臓部分でもある為、安易な選定をしてしまうと、幾
らお金があっても、無駄な導入費を払うことになりかねません。
回避方法としては、安易な決め方をせず、自社業務に焦点を当てて、現状の業
務プロセスや業務内容を整理、分析して、業務改革をも想定したグランドデザイ
ンを導いて、あるべき業務プロセスや業務内容を整理した上でマッチするPLM製
品を選定することです。
既に導入(購入)している場合は、一旦PLMシステムの構築を保留にして、自社
業務が整理出来た時点で再開する方が良いと考えます。
(3) 他社実績を優先して選定する場合
どのようなシステムでも共通ですが、製品選定する場合に他社実績を優先して
選定するケースです。(自社のものさしがない)
他社実績を参考にすること自体は問題ないのですが、その実績が自社業務にマ
ッチするのかの判断を飛ばして”実績有”で導入してしまうと「こんな筈じゃなかっ
た」となります。
回避方法としては、個別の他社実績と自社業務との合致度を判断することです
が、それだけでは不充分で、矢張り自社業務を見直す必要があります。
(4) 情報システム部門・ユーザ部門間で偏重して選定する場合
一般的に、情報システム部門はユーザ部門業務のことを詳しく知らない、ユーザ
部門は「システムに何が出来るかわからない、PLMで何が出来るかわからない、
CADで設計出来ているのでPLMはいらない」となりかねません。
この状態で情報システム部門が上司から「PLM導入を検討すべし」と言われてし
まうと、PLM製品を導入することが目的になってしまい、本来の目的である部門
間連携によるQCD追及は視野から除外され、VSGには全く対応出来ません。
回避方法としては、自社の共通の上司や役員クラスがリーダーシップを取り、
PLMを導入しなかったらどうなるか、導入したらどんなメリットがあるのか、会社
としての方向性にPLMが必要であること等を解き、情報システム部門とユーザ部
門に指示を出して進めることに他なりません。
ユーザ部門においても、PLMがなかったら人依存になり、過去モデルや過去図
面の流用が困難になり、「作った方が早い」となって無駄な作業を繰り返すことに
なったり、トラブルが発生した時のトレースが出来ないこと等の課題を知ることも
大切で、トップダウンだけでなく、ボトムアップの課題解決も必要です。
(他にも承認状況不明、設計変更管理不可等多数の課題有)
(5) 自社の業務分析(Fit&Gap含む)をせずに選定する場合
PLMシステム導入のきっかけにもよりますが、自社の業務分析無しにPLM製品
を選定してしまうと、何の為にPLMをやるのか、何故そのPLM製品を選定したの
かなど、ユーザ部門の賛同が得られずに、抵抗勢力が発生して導入に協力され
なくなります。
回避方法としては、PLMシステムの必要性を解いた上で、情報システム部門とユ
ーザ部門が協力して進めることに他なりません。
(6) PLM導入が前提になって製品比較のみで選定する場合
どんなシステムでも同じですが、指揮命令系統によっては製品導入が目的にな
り、導入後の議論が為されずに仕事(義務)として導入するケースです。
回避方法としては、前記の”導入準備”を経てから、関係部署と協議して足並み
合わせて進めることに他なりません。
(7) ユーザ部門を設計部門に特定して選定する場合
PLMはPDMが進化したものであり、設計部門が中心になるケースが多いです。
PDMの世界であれば設計部門だけで完結しても良いのですが、PLMの目的は
関連部署との情報共有や業務連携である為、設計部門内だけにしてしまうと部
分最適にはなっても、事業部門内、全社としての全体最適につながりません。
(業務が寸断されます)
回避方法としては、PLM導入目的に立ち返って、誰の、何の為のPLMなのかを
再認識して、前記”導入準備”を経てから関係部署と協議して足並み合わせて
進めることに他なりません。
(8) 共通辞書を作成しないで選定する場合
PLMシステム導入やPLM製品選定の登場人物は情報システム部門、ユーザ部
門、場合によっては導入コンサル会社等です。
協議というものは、これら関係者が特定用語を特定の意味で使用して成り立ち
ます。
常識と思われる用語でも、取引先会社間や社内でも部署間で意味が異なる場合
もあり、万が一意味を違えて使ってしまうと、違った解釈で次のステップに進んで
しまい、収拾がつかなくなる場合もあります。
複数の会社が統合したり、別会社になって共存したり、同じ会社でも作る物が違
っている部署同士だと更に注意が必要です。
回避方法としては、情報システム部門がリードして共通辞書を作成し、関係者で
共有し、最低でもプロジェクト関係者は同一の意味で解釈し、議論することです。
(9) 各種課題(経営課題、業務課題、システム課題)が曖昧な場合
自社の経営課題、ユーザ部門の業務課題、導入済・関連するシステムのシステ
ム課題が曖昧なままPLM製品選定をしてしまうと的外れな製品選定、システム
構築になりかねません。
回避方法としては、自社の経営課題を理解し、PLMがどのような解決方法をもた
らし、各種業務課題をどのように解決し、もし既存システムがある場合にはどの
ようなシステム課題があるのかを事前に明確にしてPLM製品選定やPLMシステ
ム導入を図るべきと考えます。
(10) 失敗システムの失敗原因を見極めずに選定する場合
導入済の既存システムがあって失敗(ユーザが使わない、想定以上に費用がか
かる、・・・)した場合、初回の失敗はやむを得ない場合もありますが、2度
目の失敗は許されない場合もあります。
回避方法として重要なことは、PLMシステム導入の失敗原因を明確にして次の
システム導入の”導入準備”に生かすことです。
以上、失敗ケースと回避方法を述べて参りましたが、導入する側ではどうしようもない
こともあります。
それは、PLM製品の開発元に異変が発生した場合です。
開発元が他社と統廃合するとか、PLM製品の取扱がなくなったり、製品戦略が変わっ
て今まで通りに使えなくなるなどです。
PLMシステム導入側には責任はないのですが、今日現在残っているPLM製品は、比較
的統廃合された結果であることも事実です。(若干気になるPLM製品もありますが)
対応方法としては、開発元の企業調査は無論ですが、構築するPLMシステムのアーキ
テクチャーを出来るだけ柔軟なものにし、PLM製品側の機能の明確化、カスタマイズ部
分の明確化や低減化をし、不幸にも導入したPLM製品に異変があった場合でも、機能
要件やGUIを出来るだけ変えずに、最低限の移行作業量で済むように、出来るリスクヘ
ッジをすること位でしょうか。
7 さいごに
弊社では、CAD、PLM、IoT、AI、XR等を含む製造業のエンジニアリング系システムの
導入について、コンサルティングからSIまでをご支援させて戴いています。
PLMについては特定のPLM製品の販売をしていない為、CADを含む関連ツールの諸
事情も考慮し、総合的かつ中立的な視点でお客様にとって最適解となるようなPLMシ
ステムを想定しています。
弊社の”最適解”は”ハーフスクラッチ”(弊社用語、概念・実装は2006年から、下図
参照)ですが、お客様個々のご事情もある為、360度視点(あらゆる選択肢を想定)
でご支援させて戴きます。
また、PLMだけでなく、関連システムとの連携を含む、グランドデザイン視点でも業務
改革と共に対応させて戴きます。
導入済の既存PLM製品やPLMに関連する既存システムがある場合は、先ずは既存
システムを最大限に有効活用する方針とさせて戴きます。
弊社は大手SI会社でPLMを含む製造業IT/DXをやっていた技術者、大手製造業で
ユーザ業務や情報システム導入に関与したメンバー等が中心であり、
弊社AACは製造業(業務)とIT/DXがわかることが強み
ですので、弊社にご相談の際は弊社お問合せ先にお問合せ下さいますようお願い申し
上げます。
弊社がPLM含めて製造業の皆様のQCDVSG向上の一助になれば幸甚でございます。