製造業のDXプロジェクトはなぜ失敗してしまうのか？（前編）：DX時代のPLM／BOM導入（12）（4/4 ページ）

[三河進／株式会社グローバルものづくり研究所，MONOist]

（4）体制や役割責任を定義しない

次はプロジェクトの体制について、「体制や役割責任を定義しない」です。プロジェクト開始に当たって十分な体制を構築せずに、推進メンバーや情報システム部門だけで実施している例が多いです。

弊社でもそのようなプロジェクトは多いのですが、どのような問題が発生しますか？

プロジェクトの体制は改革できる範囲とスピードを決定します。体制不備のために改革が企画倒れに終わることもあります。

何かご紹介可能な事例はありますか？

そうですね。「改革できる範囲」に関しては、3D設計改革のプロジェクトを思い出しました。そこでは2D設計を全面的に3D設計に移行するプロセス改革を、製品開発部門主体で実施しようとしていました。改革の目玉は、開発部門のアウトプットが2D図面から3Dモデルに変わることです。しかし、このプロジェクトは、製造部門が参画していなかったので、変革実行の段階でそれが受け入れられず、結果的に断念することになりました。

そうなることは予想できたようにも思うのですが、なぜこのような事態になったのでしょう？

なんとかなるだろう、という意識の低さがあったのだと思います。PLMのプロジェクトでは、部門に閉じない改革が多くなります。なぜなら、図面、BOM、品番など、開発設計部門が作成した情報を、会社のあらゆる部門が利用するからです。そこを改革する場合には、最初から関係部門を巻き込んでおく必要があります。

そうか、PLMのDXプロジェクトでは、関係部門の巻き込み不足が致命的になることがあるのですね。スピードについてはどうでしょうか？

これについても同じことが言えます。例えば、プロジェクトが品番（部品番号）ルールを変える改革施策を提案したとします。品番は世界中の工場やサービスの現場で使用されています。これから発行する品番を変える場合だけでなく、既存の品番を変える場合、業務やITへのインパクト分析を行い、全社レベルの意思決定が必要となります。

この場合も、関連する工場やサービス部門を体制に巻き込んでおかないと、その準備や調査、実施に非常に多くの調整時間を要することになります。また、内容によっては意思決定のレベル（本社の経営幹部や現地法人の社長クラス）が変わります。

つまり改革プランを実現するために、どんな部門、役職レベルに参画してもらうかを設計しておくことが重要ということですね。

その通りです。体制が改革できるスコープを決めるといっても過言ではありません。

企画フェーズの体制と役割／責任の例［クリックして拡大］

次回に向けて

鹿追さん、今日はありがとうございました。テーマがそれぞれずっしり重く、お腹がいっぱいになりました。この他、あと幾つくらい失敗パターンがあるのですか？

残り3つ、これについてはまた次回話をしてまとめていきたいと思います。

分かりました。今日教えていただいたことを復習して、自社ではどうかも確認しておきます。次回もよろしくお願いします！

⇒連載「DX時代のPLM／BOM導入」バックナンバー
⇒製造マネジメントフォーラム過去連載一覧
⇒特集「製造業DX 事例集」はこちら

著者プロフィール

三河 進
株式会社グローバルものづくり研究所 代表取締役

大阪大学基礎工学部卒業。

大手精密機械製造業において機械系エンジニアとして従事後、外資系コンサルティングファーム、大手SI会社のコンサルティング事業を経て、現職に至る。
専門分野は、製品開発プロセス改革（3D設計、PLM、BOM、モジュラー設計、開発プロジェクトマネジメントなど）、サプライチェーン改革、情報戦略策定、超大型SIのプロジェクトマネジメントの領域にある。また、インターナショナルプロジェクトにも複数従事経験があり、海外拠点のプロセス調査や方針整合などの実績もある。

主な著書

・「図解DX時代のPLM/BOMプロセス改善入門」，日本能率協会マネジメントセンター（2022）

・「5つの問題解決パターンから学ぶ実践メソッド BOM（部品表）再構築の技術」，日本能率協会マネジメントセンター（2018）

・「製造業の業務改革推進者のためのグローバルPLM―グローバル製造業の課題と変革マネジメント」，日刊工業新聞社（2012）

・「BOM/BOP活用術」，日経xTECH（2016）

・「グローバルPLM〜世界同時開発を可能にする製品開発マネジメント」，ITメディア社MONOist（2010）など多数